世界を動かす技術を、日本語で。

Apple Siliconに甘やかされているけれど、Frameworkも愛している

概要

Apple Silicon搭載のMacBookは、長期間スリープ状態でもバッテリー残量が高い。 Framework 13(AMD Ryzen 7840HS)は、数日間スリープでバッテリーがほぼ空。 Linuxディストリビューションを変更しても、バッテリー問題は解決せず。 Apple Siliconの省電力性能とARM64アーキテクチャの優位性。 Frameworkの今後のARMメインボードへの期待と現状の悩み。

Apple Silicon搭載MacBookのバッテリー持続力

  • MacBook M1 Pro は、 Apple Silicon 搭載による高効率なバッテリー管理
  • 3週間スリープ状態でも 90%のバッテリー残量 を維持
  • ARM64アーキテクチャ による低消費電力設計
  • ハードウェアとOSの 緊密な統合 による最適化
  • モバイルワークや長期の持ち運びに最適なノートPC

Framework 13(AMD Ryzen 7840HS)のバッテリー課題

  • Framework 13 は、 AMD Ryzen 7840HS を搭載
  • 2~3日スリープ状態で バッテリーがほぼゼロ
  • Fedora Workstationや Fedora Silverblue など、Linuxディストリビューションを変更しても改善せず
  • サスペンド中に毎時3~4%消費 という報告も
  • 頻繁に使用しない場合、 充電切れのストレス

Apple Siliconと他のx86アーキテクチャの違い

  • Apple Silicon(ARM64) は、 省電力設計 が特徴
  • x86アーキテクチャ (Intel/AMD)は、サスペンド時の消費電力が高い傾向
  • Linuxカーネルやドライバの最適化不足 も要因
  • Appleは ハードウェア・ソフトウェア両面での徹底的な最適化 を実現
  • WindowsやLinux搭載ノートPCでは、同等のバッテリー効率は難しい現状

Frameworkの今後とARMメインボードへの期待

  • Framework の理念や技術革新性への共感
  • 現状は バッテリー性能の課題 が愛用度に影響
  • ARMメインボード へのアップグレードが将来的な解決策に
  • ただし、 ARM64移行は単純な置き換えではない 複雑さ
  • 当面は 電源接続による運用 が現実的な対応

まとめと今後の展望

  • Apple Silicon搭載MacBook は、圧倒的なバッテリー持続力
  • Framework 13 は、現状ではバッテリー課題が顕著
  • ARMアーキテクチャの普及と最適化 が今後のノートPC市場の鍵
  • Frameworkの進化 に引き続き期待
  • しばらくは 充電を確保しつつ愛用 する選択

Hackerたちの意見

Linuxユーザーとして、あなたの気持ちわかります。MacのデスクトップはLinuxの世界に比べてパワーユーザーには全然劣ってるけど、ハードウェアは本当に素晴らしいです。私にとっては、完全に静かな環境が大事なんです。うるさいファンに戻るのは本当に辛い。Asahi Linuxが頑張ってくれることを願ってます。そうすれば、両方の良いところを享受できるから。

MacのデスクトップはLinuxの世界に比べて全然劣ってる 仕事でMac、Linux、Windowsのデスクトップを使ってるけど、それぞれに良いところと悪いところがあるよね。Macのデスクトップ体験がLinuxに比べて全然劣ってるとは言えないな。 編集:たくさんのダウンvoteをもらってるけど、ほとんどのコメントは誰かのカスタマイズされたLinuxデスクトップと完全にノーマルなMacデスクトップの比較についてだね。私は、標準的な箱から出した状態のものか、利用可能なツールやモッドでカスタマイズされたものの比較をしてるんだ。カスタマイズされたLinuxデスクトップを、他のツールやユーティリティを使わずに全くカスタマイズされていないMacのセットアップと比較するのは面白くないよ。それは単にあなたの現在の好みについての声明に過ぎない。

MacのデスクトップはLinuxの世界に比べて全然劣ってる ちょっと興味本位で聞くけど、どうしてそう思うの?Macで足りない機能って何?

デスクトップのMacにはファンがあるから完全に静かではないけど、ファンがないと思ってたなら、それは調整がうまくいってる証拠だね。私の知る限り、MacBook Airが唯一のパッシブ冷却のMacだよ。

macOSのデスクトップがLinuxデスクトップに比べて全然劣ってるなんて言うのは本当におかしい。親戚にLinuxデスクトップを使わせようと何度も試みたけど、数週間後には完全にうまくいかなくなってWindowsを再インストールする羽目になった。普通の(またはそれ以下の)ユーザー向けには作られてないから、macOSのように使いやすくて洗練されたものに比べてどうして「全然劣ってる」と言えるのか理解できない。

これっていわゆる「モダンスタンバイ」のことかな?(確かS0とS3の違いだったと思う)。前に「モダンスタンバイ」搭載のThinkPadを買ったんだけど、夜間にサスペンドしても持たなくて、ファンがうるさくて起こされることが多かったし、サスペンド中もすごく熱くなってた。BIOSで「モダンスタンバイ」を無効にしたら、数週間充電が持つように戻った。Frameworkのノートパソコンでも同じことが起きてるのかはわからないけど、「モダンスタンバイ」はPCハードウェアで見た中で一番バカな変更の一つだと思う。私の理解では、ノートパソコンをスマホみたいに動作させるためのものだけど、S0とS3のサスペンドの挙動において意味のある違いを感じたことはない。

Frameworkのノートパソコンのスタンバイ問題(少なくとも初期のものについては、最近のことは知らないけど)はよく知られた問題だったね。前にノートパソコンを探している人にFrameworkを勧めたんだけど、スタンバイ時のバッテリー消耗の問題に悩まされてた。そんな基本的な問題が解決されていると思って勧めたから、申し訳ない気持ちになったよ。

俺は11世代のIntel NUCを持ってたんだけど、EFIのバグのせいで1年近くスリープできなかったんだ… 結局、リグレッションは修正されたけど、ほんと信じられないよ。EFIをちゃんと実装できるのはIntelだけだと思うんだけどね!これが「モダンスタンバイ」と関係あるのかは分からないけど(その頃だった気がする)、あんまり役に立たなかったな。デスクトップなのに、なんで本物のスタンバイを廃止しようとするのか理解できない… * 実はまだ持ってるけど、今はホームサーバーになっちゃったから、スリープする必要もなくてラッキーだよ。

モダンスタンバイのアイデアは、正しく実装されれば良いものなんだけど(MacBookのやり方みたいに)。残念ながら、ほとんどのPCはひどい実装で、熱くなってバッテリーを一晩で消耗しちゃうんだ。

サスペンド時の電力消費に関する不満は特に悲しいね。これはノートパソコンのLinuxにとってほぼ共通の問題だから。ここでの状況がそうかはわからないけど、私のFrameworkで見る数字とほぼ一致してる。基本的に、セキュアブートを使いたいなら、カーネルロックダウンモードも必要になることが多くて、ロックダウンされたカーネルはハイバネートできないんだ。少なくとも、外部のパッチなしではね。私の意見では、これは大きな問題だよ。ハイバネート(つまりディスクにサスペンド)できないと、電力消費を低く抑えることは絶対にできないし、セキュアブートやロックダウンを使わないように言うのも良い答えではないよね。特にデフォルトのインストーラーがすでにそれらを設定しているから。ノートパソコンの「Linux」は、適切な修正を受けるほどの優先事項ではないのはわかるけど、解決が簡単な問題でもない。今の状態は本当に悲しい。

もしハイバネート(ディスクにスリープ)できないなら、電力消費を低くすることは絶対に無理だよ。これは言い訳だね。Apple SiliconのMacbookは、エネルギーを節約するためにブロックデバイスにスリープする必要がない(バッテリーが空のときだけやる)。ChromeOSはハイバネートを全く提供してない。Frameworkが良いバッテリーライフを持てない唯一の理由は、誰も細かいところに注意を払ってないからだよ。

俺の個人用マシンはFramework 13 AMD(彼らにとっての初代AMD)で、仕事用はMB Pro M4。MacBookはスリープ中にバッテリーがずっと持つけど、Framework(Ubuntu 24を実行中)はスリープ中に1時間で約1%減るんだ。1時間で1%は俺にとっては許容範囲だけど、MacBookのパフォーマンスに対する電力比はほんとにクレイジーだよ。もちろんFrameworkを責めることはできない。修理にオープンな新興ノートパソコンメーカーと、何年もハードウェアやバッテリーを最適化してきたテックジャイアントの違いだよ。とはいえ、これから数年でAppleエコシステムの外で、より良いバッテリーやスリープソフトウェア/ハードウェアサポート、より効率的なモバイルプロセッサが出てくることに期待してる。MシリーズのAppleプロセッサは、確実に業界の他のメーカーを刺激してるね。

Hacker Newsで議論の続きを見る