そこの「育成単層林」とあるのが、杉の人工林など、産業としての林業用地です。現況は、それが1,010万haであると（杉林は400万ha強なので、以下の数値に４掛けすれば概ね杉固有の推計になりますが、話の大枠は変わらないので全体の話で進めます）。別途「人工造林面積」を検索すると、近年は約３万ha／年植林されているので、植林が全部花粉が少ないタイプだったとして、300余年後に植え替えが終わることになります。300年以上かかるプロジェクトなんだから数年単位ではほとんど進まないよね、とお考えの方々、事態はそんなに甘くありません。

再び「ポイント」の６ページに戻ります。左下に、「指向する森林の状態に向けた誘導の内訳」という表があります。現在1,010万haの育成単層林は、永続的な姿としては約2/3の660万haは育成単層林のままですが、約1/3の340万haは「育成複層林」なるものに移行すると。育成複層林とは何か、身も蓋もなく言うと、急傾斜地である等の理由で管理・伐採・搬出コストがかかるので、産業としての林業が成り立たない森林です。産業として成り立たないから放っておくと杉林等のままですが、それではまずいので杉等を適当に間引き、広葉樹等を植えて自然林に近い形に持っていこうとするわけです。

「ポイント」６ページでは、20年で80万haの育成複層林を増やす姿が描かれています。既述の「内訳」によると育成複層林の元となる育成単層林と天然生林の比率は約６：４なので、この期間に育成複層林化される育成単層林はプロラタで50万ha弱。340万haの最終目標には140年ぐらいかけて到達することになります。が、これらの林は伐るだけでも赤字なので、地主が経営的判断をすれば放置一択。補助金などを突っ込まない限り、育成複層林化は進みません。「ポイント」にも「望ましい森林の整備・保全が行われた場合に見込まれる」数字と明記されていて、実際にはそんなに進まないんじゃないか、というのが下振れ要因その一。

下振れ要因その二は、660万haも育成単層林が維持できるのか、というものです。既述のとおり、現在の主伐（間伐ではなく全部の木を伐ること）後の再植林面積は年３万ha。60年サイクルを前提とすると、持続可能な育成単層林は自然体では200万ha弱にしかなりません。算数としてはサイクルを長くすればよいのですが、現在の効率的林業とは、例えば↓のハーベスタなどを使って伐り、トラックで運び出して製材工場で加工する工程となりますが、大きく育った大径木はこれに合わないので効率が格段に落ち、一部の高値がつく高級材を除くと、結局は育成単層林としての維持が困難です。その目安がだいたい樹齢60年で、200万haは悲観的予測だとしても（現状からの改善をゼロとしているので）、660万haは逆に楽観的過ぎるんじゃないかなあと。

https://m.youtube.com/watch?v=ngQMT0kRGEI

↑のハーベスタは、当然ながら平地や緩傾斜地でないと使えないわけでして、こういった重機が使えない条件の森林は、その多くが放置されざるを得ず、いつまでたっても植え替えなんか期待できないんじゃないかと思うわけです。結局、人工林のうち３～４割は５～60年ペースで植え替えられるかもしれませんが、残る半分以上はお察しを。

なお、再植林される杉の半分以上は従来タイプで、花粉が少ないものではないようです。

Permalink | 記事への反応(0) | 18:57

■anond:20230512180741

Dockerは、開発から運用まで一貫した環境を提供することで、開発者の作業負担を減らすという大きな利点があります。また、仮想マシンと比較してリソースの使用効率が高いため、エコとも言えます。

ただし、確かに Dockerには一定のオーバーヘッドが存在します。これは、Dockerがゲスト OSを持たずに、ホスト OSのカーネルを共有して動作するためです。それにより、アプリケーションの実行に必要なリソースが追加で必要になり、パフォーマンスに影響を及ぼす場合があります。

また、Dockerを利用する際の設定や構成によってもパフォーマンスは大きく変わります。例えば、Dockerのネットワーキングやストレージの設定、またホスト OSとの互換性など、考慮すべき要素は多数存在します。

あなたの現在の状況について具体的に述べると、FESSのクローリングが重いという問題は、Dockerのオーバーヘッドだけが原因ではない可能性があります。Docker コンテナ内のFESSやJVMの設定、ホストマシンのリソース割り当て、ネットワークやストレージの設定など、様々な要因が絡んでいるかもしれません。

また、Dockerのログ出力が多いと感じる場合も、実際のところはFESSやDockerの設定によるものかもしれません。ログの出力レベルを調整することで、必要な情報だけを出力するように設定することも可能です。

しかし、これらの設定を調整するためには一定の知識と経験が必要で、それがなければ素直にネイティブ環境での構築が良い選択かもしれません。結局のところ、どの方法が最善かは具体的な要件や状況によります。

このような状況に直面した際には、パフォーマンスの問題を具体的に分析し、適切な解決策を見つけるためにパフォーマンスモニタリングやロギングツールを使用することをお勧めします。それにより、問題の原因を特定し、適切な対策を講じることが可能になります。

たとえば、Dockerが高いCPU使用率を示している場合、それはコンテナ内のアプリケーション（この場合はFESS）が高いリソースを消費している可能性があります。その場合、アプリケーションの設定や実行パラメータを調整することで改善できるかもしれません。

また、Docker コンテナのリソース制限を調整することも検討できます。Dockerは、コンテナに割り当てるCPUやメモリの量を制限する機能を提供しています。これにより、他のプロセスに影響を与えることなく、特定のコンテナのリソース使用量を管理することが可能です。

さらに、Dockerのボリュームやネットワーク設定が適切であるかを確認することも重要です。不適切な設定はパフォーマンスに悪影響を及ぼす可能性があります。たとえば、ファイル I/Oのパフォーマンスは、ホスト OSとコンテナ間でデータを共有する方法に大きく依存します。そのため、適切なボリュームの設定や、パフォーマンスを向上させるための最適化オプションが適用されていることを確認することが重要です。

最後に、Docker 自体のアップデートもパフォーマンス改善に寄与する場合があります。最新のDocker エンジンには、パフォーマンスを改善するための修正や改善が含まれていることがあります。

これらの要素を考慮に入れ、Dockerのパフォーマンスを最適化する方法を探すことができます。ただし、これらすべてを試してもパフォーマンスが改善しない場合や、必要な知識や時間が不足している場合は、Dockerを使用しないネイティブな環境での構築が最善の選択であるかもしれません。

Permalink | 記事への反応(1) | 18:26

■発達障害に悩む親や事件につくコメント

うるさくなーーーい？？？？

親が頑張ってもどうしようもないことがあるってわかんない？だって本人言ってわかんないんだもん。

てか、親が頑張って改善するなら発達障害なんて問題になってないのよ。

親と本人の特性との相性とかもあるしさ。

「親が〜」とか「残された子供たちのことを〜」とか、お前が面倒見てみろよ。本人も癇癪起こすし、周りも「ちゃんと教育してください」って言ってさ。「こういう風に育てればこうならない」とか言われてみろよ。

親としてちゃんと生きれるようにしてあげなきゃって責任感じてるから思い悩んで悲しい事件が起きてるんだよ。対岸の火事だからってなんでも言っていいわけじゃないんだぞ。

って最近のニュース見て思いました。

Permalink | 記事への反応(1) | 17:51