Windowsメールのサポートは2024/12/31をもって完全に終了し、送受信共に不可能になったと思われます。こちらの環境では既に、Outlook (new)に置き換えているので追試は不可能ですがそうなったと思います。今までWindowsの標準的なメールは以下のものがありました。
Windowsメールの終了で、基本的にはOutlookに集約されたと思います。Outlook(new)はモダンな実装ですが一方で、COMベースのアドインの実装は無くなっています。Outlook(old)のサポートは2029年まではされると聞いていますが対応は速い方がいいでしょうね。
WindowsのHot Patch機能は、システムの稼働時間を最大限に維持し、セキュリティの向上を図るために設計された重要なツールです。本記事では、Windows Hot Patchの導入方法とその利点について詳しく解説します。Windows Hot PatchはIgnite 2024で紹介されました。
Windows Hot Patchは、システムの再起動を必要とせずにソフトウェアのパッチを適用する技術です。これにより、システムの稼働時間を最大化し、業務の中断を最小限に抑えることができます。
Hot Patchを適用する際にはいくつかの技術的課題があります。特に、実行中のファイルへのロックが挙げられます。
Windowsはシステムの安定性を維持するために、実行中のファイルにロックをかけます。このロックにより、ファイルが予期しないタイミングで変更されることを防ぎ、システムの予測不可能な挙動を回避します。しかし、このロック機能があるため、Hot Patchの適用は技術的に難しいものとなります。
実行中のデータを書き換えることがどれだけ危険であるかを示すために、過去に発生した事故を紹介します。
実際に、京都大学のスーパーコンピュータでは、不注意により実行中のスクリプトが書き換えられた結果、77TBものデータが消失する事故が発生しました。このような事故は、システムの運用における細心の注意が必要であることを示しています。
単にファイルを書き換えるだけでは不十分であり、実行中のプロセスを適切にリロードする必要があります。これにより、変更が正しく反映され、システムの安定性とセキュリティが保たれます。
Hot Patch技術は、ファイルロックとプロセスリロードを考慮した上で、システムを再起動せずにパッチを適用する方法を提供します。これにより、ダウンタイムを最小限に抑えつつ、セキュリティ更新を迅速に行うことが可能です。
Windows Hot Patchを導入する手順は以下の通りです。
Hot Patchを利用することで、企業は以下のような効果を実感しています。
金融業界では、システムの停止が許されないため、Hot Patchを導入することで24時間体制の運用を実現しています。
医療機関では、患者データの保護とシステムの稼働時間が重要です。Hot Patchを活用することで、セキュリティと運用効率の両立が可能になりました。
Windows Hot Patchは、システムの稼働時間を最大化し、セキュリティを強化するための有力なツールです。導入することで、業務の中断を最小限に抑え、安定した運用を維持することができます。
今、LLMは一つの岐路にあると思っている、現状の認識としてはスケーリング則に限界が見受けられること。スケーリング即とはモデルの大規模化によって、モデルの精度、アウトプットの品質が高まるという経験則を指す。しかし、スケーリング即に現状、限界が見えていて、モデルの大規模化が必ずしもアウトプットの深化に結び付かない例が観測されている。
最近の事例から、私は今後の有望な方向性として二つのアプローチを見出しています。
MoE (Mixture of Experts)：比較的歴史の長い発想で、Gradient Boostingなどもその考え方と考えられます。複数のモデルを組み合わせ、それぞれに重み付けを行うことで高精度なモデルを構築する手法です。
BitNet：比較的新しい考え方で、ニューラルネットワークは発火しているか否かという状態を表すため、ビットレンジを極限まで圧縮できるはずという理論に基づきます。このアプローチでは、計算リソースの使用を大幅に削減することが可能です。
これまでは、モデルの大規模化競争が主流でしたが、これは妥当な方向性でしょうか。ビッグプレイヤーは結果的に原子力発電にまで進んでいますが、これがよい方向性だとは思えません。したがって、モデルの効率化が今後のゲームチェンジャーとなり得ると考えています。
イーロン・マスクが最近このようなことを言っています:
しかし、以下の発言も彼のものです:
XユーザーのElon Muskさん: 「𝕏 is the PvP of social media」 / Twitter
イーロン・マスクがTwitterを買収し、私物化してPvP（プレイヤー対プレイヤー）ソーシャルメディアに変えたのは周知の事実です。なぜこのようなことが起きたのでしょうか？
単純な理由があります。H-1Bビザを擁護したからです。アメリカのIT業界は、H-1Bビザで入国してくる海外の優秀な労働者に大きく依存しています。H-1Bビザがなくなると、業界にとっては死活問題となります。しかし、PvPソーシャルメディアとなった「𝕏」上で、イーロン・マスクのような経営者は多数派ではありません。そして、マスクが焚きつけた対立感情により、海外からの安価な労働者の流入を止めたいと考える人が増えています。
結果、「𝕏」は暴言の坩堝と化しました。しかし、その引き金を引いたのはイーロン・マスク本人であることを忘れてはなりません。
さらにウィットに富んだ良い返しを紹介します:
日本では良い言葉がある。「人を呪わば穴二つ」
WebAssemblyに特化した言語「MoonBit」のコンパイラがGitHubで公開 － Publickey WebAssemblyに特化した言語が公開されたそうです。WebAssemblyとはasm.jsなどの流れの延長上に、実行可能コードをWebでホストできるものです。現時点でも、SQLiteをWeb上にホストしたりなどの実装が見受けられます。
現状では、WebAssemblyに特化した言語はかなり珍しいです。今のところ、WebAssembly使用の実例としてはTensorflow.jsやUnityなどの例になります。
https://wired.jp/2019/11/22/the-apple-card-didnt-see-genderand-thats-the-problem で記されている古い問題ではあるが、今にもつながる問題を提起している。たしか、記憶してる限りだと、Apple Cardの極度額がある夫婦で夫と妻とで極端な差があったので問題になったはずです。同じ家計の夫婦であれば、リスクはほぼ同じになるはずが、そうなっていなかったというので問題になったはずです。
そして、これが性別を与信モデルに含んでいれば、ある種単純だったんですが、この事業では性別を見ていなかったのです。したがって、逆に、性別で差別をしていないという立証が困難になりました。
性別に限りませんが、ある変数が別の変数に関連しているのはよくある話です。例えば、今回の話でならば、女性の身長の平均が男性のそれより低いというのは、事実であり、身長というフィールドがあったならば性別を書いているのと同じことです。
そして、OECD AI五原則と言うルールがあります。
1. AIは持続可能な成長や開発、幸福促進に利益をもたらすべき。
(以下省略)
また、個人情報についてOECDには以下の八原則があります。
1. 個人データの収集目的を明確にし、データ利用は収集目的に合致するべきである。
(以下省略)
この二つを鑑みると、モデルを作るにあたっては収集目的に見合ったデータを集めモデルを作るべきとなります。
つまり、与信であれば、貸し倒れ等のリスクを見るのに、見合った項目によりモデルを作るべきということになります。
従って、これらの原則を援用すれば、適当にデータセットを作って、後はStep-wiseを含め機械に変数選択をやらせてなんとなく、精度高めのモデルできましたはOECDの各種原則に従ってるかと考えればかなり微妙となります。
実際、産総研の高木さんなんかは、OECDの原則に照らせば、こういう安易なモデルはもってのほかと考えているのは、Twitterでの発言を考えればわかる感じです。
https://gigazine.net/news/20241224-openai-gpt5-orion-delays/ でGPT-5が苦戦中というのが出ているが。
僕の理解では、現状のLLMは古典的な自然言語処理では字句解析、構文解析、意味解析と下から順に階層的に処理して最終的にある問題の回答を求めようとしていたのを、LLMの隠れ層に中間的な工程を委ねていると思っている。古典的な自然言語処理がうまくいかなかったのは階層的な処理だと、例えば字句解析が90%の精度で、構文解析が80%の精度だと仮定すると、構文解析のところで実際の精度は72%になる。そして、工程を経るごとに精度は下がり続け決して上がることはない。
故に実際の問題のところに至るまでに実用的なラインを割り込んでしまう、実際、LLMの登極前の時点で、字句解析、構文解析、意味解析を実用的な精度できちんとやり切っているシステムを私は聞いたことがない。多くの場合は、Eliza的なパターンマッチングなどで動いていたと思う。
LLMはEnd to endで入力されたものと、出力とを完全に結びつけることで初めて、一つのブレイクスルーを得たと思う。途中を隠れ層に押し込むことで、精度低下を不可視化したと思う。勿論、技術的には活性化関数などや、もちろん計算機の進化によって、深層学習が実用になったこと、そして、Attention機構のようにRNN的な成果を実用的なパフォーマンスで得られるようになったことが大きい。
しかし、根本的には、人間はLLM内で何が起きているかを理解できていないし、結果的にフレーム問題なども前進したかどうかすらわからない。この辺に今のLLMを考える難しさがある。
最近、Fooocusでもa1111と同じバグがあることに気づきました。この問題は、patch_clip.py内のpatched_encode_token_weightsの実装に起因しています。
z = z * (original_mean / new_mean)上記のコードで、時折 new_mean が非常に小さい値を取るため、重みが跳ね上がり、正常な描画ができなくなっています。
実際に確認された値は以下の通りです：
| original mean | 0.0004 |
| new mean | 3.7944e-05 |
この場合、z は約10.54倍されることになり、結果として描画が大きく乱れる可能性があります。
以下の画像は、実際に乱れた描画結果の一例です：
GitHubのissueにもこの不具合を報告しましたが、Fooocus の issues は現在あまり動いていないようです。open な issue が積み上がる一方なので、自分でフォークした mashb1t 版のベースで対応を進める予定です。ただし、z の計算ロジックの適切な修正方法についてはまだ結論が出ていません。
元々のコードの出所はこちらです：Stable Diffusion XLで生成画像の破綻が起きる問題の解析と対策
Ledgerなるおそらくウォレットを騙る、メールが来ました。Ledger Data Breachなるタイトルでアカウントの確認依頼になっていますが、ログイン先と主張しているアドレスがAmazon S3のアドレスでそもそも、私はLedgerなるサービスのアカウントは持っていないので十中十、フィッシングでしょう。
怪しいので、Windows Sandboxを使用し、メールで参照しているAWS S3のアドレスからダウンロードしてみたところ、中身は https://ledgerprotecthub.com/ にリダイレクトしていることがわかりました。 そして、このドメインをwhoisしてみたところ、以下のような内容でした。
Domain Name: LEDGERPROTECTHUB.COM
Registry Domain ID: 2935890219_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.registrar.amazon.com
Registrar URL: http://registrar.amazon.com
Updated Date: 2024-11-21T07:05:15Z
Creation Date: 2024-11-20T21:58:13Z
Registry Expiry Date: 2025-11-20T21:58:13Z
Registrar: Amazon Registrar, Inc.
Registrar IANA ID: 468
Registrar Abuse Contact Email: trustandsafety@support.aws.com
Registrar Abuse Contact Phone: +1.2024422253
Domain Status: ok https://icann.org/epp#ok
Name Server: SARAH.NS.CLOUDFLARE.COM
Name Server: YADIEL.NS.CLOUDFLARE.COM
DNSSEC: unsigned
URL of the ICANN Whois
Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2024-11-21T11:57:21Z <<<
まず、真正のドメインと考える理由はゼロです。RegistrarをAmazon Registrarにして、連絡先などを伏せている時点で真っ黒です。
https://ledgerprotecthub.comはWindows Sandbox上から、wgetを使ってアクセスしてみたところ、403ではじかれたので、Windows Sandboxから仕方なくEdgeでアクセスしてみたところ、少なくとも、24語のセキュリティワードを要求しているページと確認が取れたので、黒と判断しました。
OpenSSHに脆弱性、CVE-2024-6409が発覚しています。
シグナル関連が鬼門となっている印象。脆弱性としては、CVE-2024-6387よりはマシな印象。LoginGraceTime 0による緩和策は有効。-eによる緩和策は本件には無効。UbuntuにおいてはUpstreamには影響。