「Appleのせいじゃない」というのは議論の余地があるね。Electronがこんなことをするべきじゃないとしても、Appleもユーザーが使ってるソフトウェアに問題を引き起こすアップデートを出すべきじゃないと思う。

小さなプラットフォームの違いを許容して、うまくやっていく方がいいっていうのはいい意見だね。すべての細かい部分を管理して、プラットフォーム間の一貫性や完璧なモックアップへの準拠を強制しようとするよりも。

いや、これはAppleのせいだよ。主要なアプリに対して回帰テストをしないのは純粋に無能だと思う。あと、コメントにあったこれね：> [あるユーザー] Appleのエンジニアに連絡を取る方法を試してみてください。プロジェクトとして、私たちはあなたよりAppleとのつながりが良くないです。> > 一つのアプローチとしては、上でリンクされてたBlueskyの投稿に返信したエンジニアに連絡することかも。純粋に無能だよ。大きなプロジェクトは、ソーシャルでランダムな人に連絡するしかない。

あるコードがメソッドをプライベートにしても、別のコードがそれをオーバーライドしたり、修正したり、呼び出したりするのは、カプセル化の考えに対する侮辱だね。これは現在のコンピュータがメモリを管理する方法に内在してる。カプセル化を保証するための損失を補うほどの利点があるかは分からない。静的解析を試みることもできるけど、それはマシンのアセンブリにいくつかの制限を課すことを意味する。多分、それは価値がある。> コードの一部は関数のアイデンティティによって異なる動作をする。俺は「スタック上でプロパティXを持つ最新の呼び出し元を見つけて、それがアクセスできるか確認する」っていうのをいろんな言語でやってきた。時には、関数が単なる関数になれないこともある。

ほんとにひどいね。問題(1)について、なんでその言語がそれを許してるの？ なんでこんなやり方をしてるの？ Appleは公式な方法を提供しなかったのかな？

(2) コードの挙動は関数のアイデンティティによって異なるから、拡張性の原則に反してるよね。ほとんどの拡張性の定義では、結果を得るためのステップ数は観察可能な特性として考慮されてないけど、実際にはそうなんだよね。

プライベートAPIの乱用は、パブリックAPIが不完全であることを意味する。そして、システムの挙動があまりにも嫌われているから、内部をいじりたくなるってことだね。

そうかもしれないけど、この特定のケースはElectron側のプライベートAPIの（悪）用に関係してるみたいだね。

Electronアプリに対するデファクトの不満だってわかってるけど、メモリ使用量を除けば、主要なElectronアプリでラグの問題に遭遇したことはないな。

これまで気づかなかったけど、ネイティブアプリよりパフォーマンスが悪いのは確かだと思う。Mシリーズは今のところ余裕がありすぎて、結構なんでもいけちゃうね。

ランタイム仕様に書いてあると思うよ。「アプリケーションは全コアと全メモリを使うべき」って。ここ数年、メモリ使用量が異常になってたアプリは、もちろんElectronベースのものだけだった。ただ、これはMac OSの問題で、「ユーザーがコントラストを強くしすぎたから、台無しにした」っていう26 Tahoeの件もあるから、早期採用者の体験の一部なんだよね。

いや、通常はOSレベルでパフォーマンスに干渉することはないよ。限られたリソース（CPU/GPU/RAM/IO）を無駄に使うことはあるけど、システムの機能に干渉するのは普通のブloatwareの問題じゃないね。

検索は僕には問題なく動いてるよ。君のマシンで壊れたのは残念だけど、みんながMicrosoftのレベルに合わせるためには壊れてる必要があるんだ。

Spotlightのファイル検索が完全に壊れてる。インデックスを再構築しても効果なしで、ウェブ結果しか返ってこない。俺も同じ問題があったけど、Spotlightのプロセスを終了させたら直ったよ。（再起動でも多分大丈夫だと思う。）

M4は俺にはめっちゃ調子いいよ。M1 Maxで64GBのメモリを積んでるけど、常に問題が出る。

Macの壊れたSpotlightインデックスを修正するための指示がすごく良かった。実は今年の初めにやろうと思ってたんだけど、手動でやることが多すぎて無理だと思ったんだ。で、数ヶ月壊れてたのに、突然また動き出したんだよね。

ハードウェアの性能が問題を隠してる可能性が高いね。2020年のIntel 13インチMBP（16GBのRAM、4コアi5）から16インチのM4 Proにアップグレードしたんだけど、MacOSの基本的なプロセスが原因で、日中に何度も操作できなくなることがあったんだ。古い方は彼女にあげたんだけど、何もしてないのにインデックス中にファンが回る音がアパートの反対側から聞こえてくるよ。インデックス処理が終わるまで待たなきゃいけないのが本当にイライラしてたのを覚えてる。何が起こってるのか分からないけど、ゲームやDocker以外では、これほどシステムに負担をかけるものはないと思う。ProToolsも、悪いプラグインやレンダリングが行われていない限り、音が出ないみたいだし。設定メニューのメモリリーク（または問題の正体）は、古いMacの方が新しいのよりもずっと目立つけど、再現性はあるよ。どちらのコンピュータもまだTahoeを使ってないけど、これらの問題はすでに存在してた。あなたのコメントを基にすると、今は機能的に悪化してるかもしれないし、パフォーマンスやユーザー体験に関しては冗談みたいな状態だね。新しいMacはハードウェア的には素晴らしいけど、これらの問題は効率コアでバックグラウンドプロセスを処理できることで補われてるみたい。でも、フロントラインのプロセスやアプリのもたつきや不十分さは、もっと賢いエンジニアたちにとって恥ずかしいことだと思う。特にXcodeやSwiftUIにも大きな問題があるし、Macは比較的小さな市場だから、時間やエネルギーを問題解決に割けないのかもね。

フェアに言うと、M4 Maxはすごくパワフルなマシンだから、いろいろ間違ったことをしても気づかないことが多いよね。

不思議なことに、WindowServerの問題は私の個人用MacBook Proでは常に発生するけど、同じモデルの仕事用MacBook Proでは見たことがないんだ。問題を引き起こすために必要な他の要因があるみたいだね。

hxxps://x.com/ian_mcdowell/status/1967326413830472191 （Twitterリンクごめんね、でもAppleの社員だから） https://xcancel.com/ian_mcdowell/status/1967326413830472191 修正したよ :)

GPU負荷バグとオートフィルバグは、別々の全く無関係な問題だよ。

これが修正かもしれないね： https://github.com/ghostty-org/ghostty/pull/8625/commits/431...

GPU負荷バグとオートフィルバグは、別々の全く無関係な問題だよ。

Safariがウェブアプリの「インストール」をサポートするようになってから、SlackのElectronラッパーはすぐに使わなくなったよ（ファイル > ドックに追加…）。Appleの中でも似たようなことをしてる人がいるんじゃないかな。

各企業に対して、予算に少なくとも1,000万ドル追加して、2年のリードタイムが必要って話だよね。