Quattroにカーネル選択機能とデスクトップの修正がマージ、Surface対応も進展

01Updateメニューから起動時の既定カーネルを選択可能に

dhhがomacom/omarchy#15966を作成し、Quattro開発ブランチにマージした。複数のカーネルをインストールしている場合、UpdateにKernelメニューが表示されるようになった。認証後にLimine's default（Limineの既定の起動先）を変更し、選択したカーネルを再構築して、再起動を促す通知を表示する。Direct Bootでは切り替えを拒否し、切り替えに失敗した場合は以前の起動設定への復元を試みる。

議論の結果、ある制限を意図的に残すことで決着した。起動順序を手動で編集し、先頭をワイルドカードにしていると、現在のカーネルを示すチェックマークが付かない場合がある。dhhは、標準設定と選択コマンドでは正確なカーネル名を使っていると説明した。greptile-apps[bot]はこの判断を受け入れ、omacom/omarchy#15966:discussion_r4339204956で指摘を取り下げた。

02モニターの再有効化とフローティングワークスペースで個人設定のレイアウトを維持

dhhが、zihaomuによる2件の修正をQuattro開発ブランチにマージした。omacom/omarchy#16147では、ディスプレイを再び有効にした際、そのモニター名に対する既存ルールのモード、位置、スケールが維持される。omacom/omarchy#16143では、保存済みのワークスペースモードより後に登録された個人設定のフローティングウィンドウルールが、最初の対象ウィンドウが開く前に適用される。これにより、意図しないサイズ変更や、その後にタイル配置へ変わる問題を防ぐ。

omarchybotは、使い捨てのOmarchy検証環境で両方の問題を再現し、修正を確認したと報告した。ディスプレイのレビューでは、対応範囲の限界も指摘している。ワイルドカードや説明文字列を使って独自に設定したモニタールールでは、依然としてレイアウトが失われる可能性がある。フローティングワークスペースの変更は、設定の管理主体と除外処理を正すもので、ウィンドウの初期サイズ調整全般を解決するものではない。

03Surface Pro 11のパッケージが取り込まれる一方、ボード設定は判断待ち

turbineBMW's Surface Pro 11ボード対応案は、omacom/omarchy#14390で引き続き検討中だ。関連コミットはパッケージリポジトリのmasterブランチに取り込まれ、Wi-Fi、音声、カメラのルーティング、Flex Keyboardのペアリング、復帰時の動作、ペン入力、環境光の検知に対応する。パッケージリポジトリのmaster（package repository's master）に入ったこれらのコミットにはedgeへの公開が記されているが、ボード設定の採用とは別の話だ。

birkskyum's reviewでは、ARM専用パッケージをx86_64のオフラインミラーから除外することと、公開済みパッケージを使ってインストールを完了することが求められた。ミラーからの除外は、ISOリポジトリのQuattroブランチ（ISO repository's Quattro branch）にomacom/omarchy-iso@886f2899f1bbとしてコミットされた。また、turbineBMWはomacom/omarchy#14390:issuecomment-6323783042で、Surfaceへの新規インストールに成功したと報告した。

その後、omarchybotは、作者側で満たすべき前提条件はそろったものの、分類と、競合する対応方式のどちらを選ぶかについては、なおメンテナーの判断が必要だと述べた。提案された設定はOLEDモデルを対象としており、LCDモデルとX Plusモデルは検証対象に含まれていない。

04複数ユーザー対応案でディスクの鍵とアカウント削除の安全対策を強化

osbase77's proposalとして検討中のomacom/omarchy#16100は、ローカルの管理者アカウントと権限を制限したアカウント、個別のログインIDに加え、ユーザー数が1人から複数、またはその逆に変わる際のrootアクセスと自動ログインの変更を提案している。すべてのアカウントに管理者権限を与えずに、1台のマシンを共有できるようにするものだ。

10月21日のレビューで、greptile-apps[bot]は、ユーザーが操作できる復旧メモによってアカウントの削除が妨げられる問題を指摘した。osbase77はこのチェックを、自動ログインを復元する前にディスクのキースロットを確認する処理に置き換えた。その後、本物の復旧メモを削除してしまう懸念が示され、標準パスにそのメモがあるホームディレクトリは削除しない保護措置が加わった。osbase77は、所有者のアカウントを削除した後の復旧には、依然として手作業が必要になる場合があると認めている。

CappieGoldは、SSSDを使った構成でのActive Directoryとの互換性問題として、セッションのロック解除やディレクトリグループの権限などを挙げた。osbase77は今回の提案をローカルアカウントに限定し、omacom/omarchy#16100:issuecomment-6320386855でディレクトリ連携は別途実装することを提案した。

05Podman標準採用案、移行と復旧の対応範囲を明示

acrogenesisはomacom/omarchy#16173を提出し、Podmanを標準のコンテナエンジンにして、Docker互換機能を任意で利用できるようにすることを提案した。開発用データベースをrootlessのユーザーサービスで管理し、条件を満たすDockerからの移行ではデータを保持する。また、Windowsランチャーはディスクと認証情報を維持したまま、認証付きのrootful Podmanへ移行する。提案は引き続き検討中だ。

greptile-apps[bot]は、パッケージの問い合わせでDockerの代替プロバイダーを検出できるか疑問を呈した。acrogenesisは、隔離したパッケージデータベースと実際のpacmanバイナリで検証し、それらのプロバイダーも正しく解決されたと報告した。omacom/omarchy#16173:discussion_r4337709418では、この指摘を誤検知と判断している。作者はまた、今回の対象を絞ったテスト群の結果と、以前の実環境での検証結果を区別している。更新した今回の提案では、インストール全体とエンジン移行の検証はやり直していない。

06キャプティブポータル対応案、サインイン中はTailscaleの出口ノードを一時停止

dhhはomacom/omarchy#16186を提出し、接続確認先をOmarchy独自のエンドポイント（Omarchy's own endpoint）に移して、キャプティブポータルへのサインインを改善することを提案した。提案されたportalコマンドは、利用中のTailscaleの出口ノードを一時停止し、接続状態を監視して、サインイン後に元に戻す。また、インターネットに接続できない間は、ネットワークパネルに誤解を招くパケット損失の測定値を表示しないようにする。

greptile-apps[bot]は、ロケールに依存する完了判定によって出口ノードが停止したままになる可能性と、翻訳カタログを経由しない通知文を指摘した。提案は引き続き検討中だ。dhh's descriptionには、ブラウザーにキャッシュされたHSTSが既知の障害として記されている。また、実際の出口ノードの一時停止と、実際のキャプティブポータルでの一連の操作は、まだ検証していないとされている。

07パーティションテーブルの読み取り失敗から既存データを守るインストーラーの安全対策案

emirbは、空き領域へのインストール処理で、最初のパーティションテーブルの読み取りに失敗すると、既存のパーティションを新規作成したものと誤認する可能性を見つけ、omacom/omarchy-iso#307を提出した。この場合、既存のOmarchyのEFIパーティションがフォーマットされたり、ロールバック時に削除されたりするおそれがある。

検討中の提案では、作成前後のパーティションテーブルを正常に読み取れ、パーティションがちょうど1つ増えていることを必須とする。作成結果を安全に特定できなければ、推測で処理を進めずインストールを停止する。github-actions[bot]はomacom/omarchy-iso#307:issuecomment-6322688377で、x86_64とaarch64の両方でインストールテストに合格したと報告した。

08Live ISOで、そのPCに実際にインストールするカーネルを起動する案

emirb's proposalである未マージのomacom/omarchy-iso#310は、一般的なPCのライブ環境ではlinux-omarchyを起動し、製造元としてAppleを報告するマシンでは引き続きlinux-t2を使うことを提案している。狙いは、ブートローダーとディスクのロック解除画面を経た後で初めてそのカーネルを使うのではなく、インストール前に、実際にインストールするカーネルを動かして確認できるようにすることだ。

この提案ではx86_64イメージに両方のカーネルを追加し、イメージサイズの増加は約3％と見積もっている。github-actions[bot]はomacom/omarchy-iso#310:issuecomment-6328144501で、x86_64とaarch64のインストールテストに合格したと報告した。提案はまだマージされていない。

09Agent Voice、安全でない読み取り、Gitフック、非公開録音へのアクセスを修正した更新版を公開

github-actions[bot]はomacom/omarchy-plugin-marketplace#12442:issuecomment-6327088335で、メンテナーのレビューを経たAgent Voice更新版の公開を確認した。この更新では、音声入力したプロンプトの先頭にあるマイナス記号も保持するようになり、負の数が正の数に変わったという報告に対応した。

HANCORE-linux's reviewでは、エンドポイントの応答サイズに上限がないこと、権限確認中にリポジトリで設定されたGitのファイルシステム監視フックが実行されること、話者モデルや過去の録音へのアクセス権限が緩いことが指摘された。duaneocaは、これらの問題を再現して修正し、デーモン起動時に既存の非公開データの権限も修復するようにしたと報告した。HANCORE-linuxは別途、応答サイズに上限を設けた修正をソースコードで確認した。その後Git関連の修正も確認し、続いて権限の問題を指摘した。

メモリ使用量の測定と実行時の再現結果は、duaneoca's reportsとして報告されたものだ。マーケットプレイスでの検証は、公開されたその時点のスナップショットのみを対象としており、セキュリティ監査に相当するものではない。

10Omardeck、レビューでの修正を経てウィンドウ一覧・ドック・通知を一体化

github-actions[bot]はomacom/omarchy-plugin-marketplace#12449:issuecomment-6323100584で、QuokeCola's Omardeckの公開を確認した。このプラグインは、ウィンドウ一覧、ドック、通知センターを一体化する。申請時の説明では、同じジェスチャーを登録するため、機能が重複するウィンドウ一覧、通知、ドックのプラグインを無効にするよう勧めている。

HANCORE-linuxは、ウィンドウタイトルがリッチテキストとして描画され、シェルからネットワークリクエストが発生する可能性を指摘した。QuokeColaは、ドックのテキストをプレーンテキストに変更し、タイトルに関連するアイコン処理も制限したと報告した。その後、HANCORE-linuxは任意のタッチパッドアクセスルールを承認し、レビュー対象のリビジョンでタイトルがプレーンテキストになっていることと、通知履歴へのアクセスが非公開に制限されていることを確認した。基本的なインターフェースは、この任意のジェスチャー設定なしでも動作する。

11パッケージの更新追跡に認証付き取得と回数制限付きリトライを導入

不安定な上流の更新追跡に対処するため、emirbに関連するパッケージ保守のコミットがmasterに取り込まれた。omacom/omarchy-pkgs@4f04db9a0506はGitHub APIへの認証付きリクエストを追加し、問題のある取得処理でHTTP/1.1を強制する。コミットの説明では、最近の失敗の多くは匿名アクセスで共有されるAPIの利用上限に起因し、それ以外にはHTTP/2のエラーがあるとしている。

omacom/omarchy-pkgs@b4c15a6898b2は、一時的な失敗に対する回数制限付きリトライを追加し、ダウンロード内容を一時保存してから出力するようにした。これにより、再試行後に不完全な応答がつなぎ合わされるのを防ぐ。関連する別のコミットでは、毎時のブランチ追跡についての一般的な失敗メッセージをBasecampから削除する一方、失敗したActionsの実行記録とパッケージごとのログは残している。