Posts

AlexandriteOS 3.00の正式なシステム要件が決まったのでお知らせします。そもそも何で今まで決めてなかったのかとお叱りを受けそうなので弁解しておくと手元のデバイスのみでシステム要件を決定するのは難しかったからです。今回、複数のユーザーの報告や手元の環境での検証、他のディストリビューションのシステム要件などから総合的に判断しました。 なお「必須」を満たしていない場合、実用的な動作の保証はできません。またこの要件を満たしていても使い方や環境次第では不十分です。逆に満たしていないのにある程度快適に動く場合もあります。PCには非常に多様な構成があるためこれはあくまでも参考程度にしてください。 注意 AlexandriteOSは仮想化ソフトウェアでの動作を正式にはサポートしていません。一部の仮想化ソフトウェアはデフォルトで非常に低い解像度とCPUレンダリングを強制するため画面が正常に描画されない可能性があります。 仮想化ソフトウェアのみで発生する不具合について、AlexandriteOSは原則として対応しません。 仮想化ソフトウェアベンダーに修正を依頼してください。 まともにOSが作動する仮想化ソフトウェアを作成するのは仮想化ソフトウェアベンダーの仕事です。 CPU 必須 これらの条件を満たさない場合、動作が著しく困難になります ・ amd64アーキテクチャの2つ以上の物理コア（HSTによるスレッドは除く）を搭載したAMD、もしくはIntel製プロセッサー 推奨 以下の条件のいずれかを満たしているデバイスで使用することを推奨します ・ AMD FX-9830P 以上の性能を持つAPU ・ デスクトップ向け第2世代Core i5以上の性能を持つプロセッサー + AMD radeon R5-230以上の性能を持つGPU ・ 第3世代以降のモバイル向けCore i5以上の性能を持つプロセッサー RAM 必須 これらの条件を満たさない場合、動作が著しく困難になります ・ 2GB以上の物理メモリー ・ DDR3以上の転送速度を持つメモリー 推奨 以下の条件のいずれかを満たしているデバイスで使用することを推奨します ・ 4GB以上の物理メモリー ・ swap含めて8GB以上のメモリー グラフィックス 実はAlexandriteOSの動作の快適さはGPUにかなり影響されます 必須 これらの条件を満たさない場合、動作が著しく困難になります ・ デスクトップ向けIntel HD 3000、もしくはモバイル向けIntel HD Graphics 4000以上のグラフィックス性能 ・ nvidia社製以外のGPU (性能に関わらず、nvidia製のGPUを使用するとグラフィカルシェルの動作が極めて不安定になります。詳しくは ここ を参照してください。) 推奨 以下の条件のいずれかを満たしているデバイスで使用することを推奨します ・ AMD FX-9830P 以上の描画性能を持つAPU ・ AMD radeon R5-230以上の性能を持つGPU ディスク 必須 これらの条件を満たさない場合、動作が著しく困難になります ...

この記事では新しくなったAlexandriteOSのソースコードの構造について書こうと思います。 AlexandriteOSのモジュール構成 isoイメージ ↑ ↑ ↑ openSUSEパッケージ ↑ 独自パッケージ ↑ ↑ ↑ ファーストパーティモジュール ↑ サードパーティモジュール isoイメージ: 完成品のイメージファイルです。各種のパッケージから構成されbeaverレシピを使用しビルドされます。 パッケージ: AlexandriteOSの独自のパッケージとopenSUSEのパッケージに分かれます。 openSUSEのパッケージはopenSUSEのリポジトリからそのままインストールするパッケージのことです。大半のソフトウェアはここから提供されます。 独自パッケージはAlexandriteOSのインフラを使用して配信されるAlexandriteOS固有のファイルを含むパッケージのことです。AlexandriteOS独自の機能やAlexandriteOSの不具合に対するアップデートはここから提供されます。 モジュール: AlexandriteOS独自のパッケージはモジュールという単位から成り立ちます。これはエンドユーザーには関係ありませんがビルドの際はこのモジュールという単位を使用します。例えば alexandrite-shell (新名 mriya-shell) というパッケージは以下のモジュールから成り立っています。 https://git.sda1.net/alexandrite-os/mriya-shell なぜわざわざモジュールに分けるのか。これには理由があります。AlexandriteOSは様々なファイルが複雑に依存しあっています。また上流のものに少し手を加えたものが多くこれらを通常の個別のパッケージとして配布すると様々な不具合や誤解の原因になります。そこで一つのパッケージにまとめる必要があるのです。 しかしここで問題が発生します。パッケージを一つにまとめた場合そのパッケージのメンテナンスの手間が大幅に上がります。そこで新たにモジュールという単位を作りリポジトリを分割している訳です。 以上小ネタなのか備忘録なのか開発記なのかよく分からない記事になってしましたが色々工夫があるのだと知っていただければ幸いです。

AblazeのHPを新しくなりました！！ https://ablaze.one からアクセスできます 今回はリニューアルに至った経緯や変更点を書いていこうと思います 何故、リニューアルすることになったのか 旧サイトは一年ほど前に自分がササっと作ったもので、色々とコンテンツを追加していくことによってアクセシビリティやパフォーマンスが落ちていました。なので今回はNext.js, tailwindcssを利用してサイトを新調しました。 Website3はどこいった 色々と試行錯誤しているようなのでお披露目はもう少しかかりそうです。旧サイトはsimple_website(Website2)で作成していてこれはWebsite2系列のサイトになります。Website3に関してはつきみさんが進めてるのでそのうち発表があると思います。 今後の更新予定について News欄がまだないので実装予定 プライバシーポリシーの移動

皆様お久しぶりです。 kr-tukimiです。 これまでAblazeでは Freshworks 社の FreshStatus を使用していました。 ですが、管理の難しさ、デザイン、カスタマイズ性などを考慮し、 Instatus 社が提供するステータスページに切り替えました。 また、Instatus 社に直接問い合わせ、協議の結果 Instatus Proを無償で提供いただけることになりました！！ 🎉🎉 なぜ Instatus を？ デザインが美しく、Next.jsなどのモダンなシステムを採用しているから 過去のインシデントは？ 削除されます。 リダイレクトはありません。 Instatus 公式サイト Ablaze Status

Floorp レガシーブラウザーのアップデート、ありがとうございます！！ Floorp では安定したリリースと機能更新をできるように、最新の Firefox に追従しています。8.6.2では Firefox カーネルの更新といくつかのバグ修正や仕様の変更のみを行います Linux は Flatpak によって更新が配信されます。ターミナルに flatpak update と入力すると更新できます。 Windows 版は、Floorp アップデーターによって配信されます。ブラウザを再起動時に、自動で更新の有無を Floorp がチェックします。 なお、内容は予定です。正式版とは異なる場合があります。ブラウザーに実際に実装された機能が正式版です。 また、Floorp for Linux は、8.6.1 はリリースしなかったため、8.6.2 をもって安定版になります。 ?Firefox の更新 1. Firefox カーネルは、Firefox 99.0 の最新リリース版に更新されました。このアップデートにはセキュリティーフィックスが含まれています。 なんとなく Firefox カーネルと言う呼び方はやめました。復活するかもしれませんが? また、ブラウザーの内部ではバージョンが Firefox 99.01 になっていますが、実際には 99.0 です。 ℹ️変更点 1. Floorp で、 Google によるセーフブラウジング の機能が有効になりました。 運営は、Google による URL送信を危惧したいたため、実装していませんでしたが、安全性が確認されたたため、有効になっています。 ただし、それ以外の ロケーションAPI等 は無効になっています。今後有効化する可能性はあります。 2. ブラウザーとウェブサイトの境目の線を削除しました。サイドバーとツールバーも一体化しているように見えるはずです。 これによってマテリアルライトのテーマには変更が入っています。 3. about:license にいくつかの変更を実装しました。 ✘バグ修正 1. コンテナータブが初期化される問題を修正しました。 2. Floorp のダイヤログのリンク先の URL が間違えている問題を修正しました。 ...

Floorp のベータ版のリリースノートです。安定版とは関係ありません。 安定版から、ベータ版に移行するには、以下の記事を読んで下さい。また、Firefox がバージョン１以上異なる場所へのダウングレードはできません。ご注意ください。 ?Firefox の更新 1. Firefox は、Firefox 100.0 BETA に更新されました。 このバージョンの Firefox はいくつかの CSS に @import が使用できるようになり、ブラウザーの UI やコンテキストメニューやブラウザー内部サイトのCSSの書き直しを行いました。 また、Firefox のテーマの解釈も変更されているため、テーマが意図しない動作をする可能性があります。 ?新機能 Floorp のテーマに新機能です！！Floorp はユーザーによる、CSSを搭載したテーマのインストールを許可するようになりました。 これによって以下の機能がテーマで使用可能になります 1. カスタムCSSを含んだテーマがインストールできるようなったことで、テーマのCSSの上にさらにCSSを上書きできるようになりました。 2. ブラウザーを再起動せずとも、ブラウザーのデザインを切り替えられ、自作したテーマとCSSを組み合わせることが可能になります。 また、今後登場予定の Floorp アドオンストアでは、これらのテーマを取り扱う予定です。お待ちください！ このテーマの作成方法は Firefox のドキュメント、Chrome のドキュメントにも存在しないので Floorp 側で用意する予定です。 3. Floorp アップデーターの設定を、about:preferences サイトの Floorp アップデーターの設定から変更できるようになりました。 ただし、この設定の適用に再起動は必要ありません。 Floorp や Ablaze とは関係のないグループのコラボテーマを同封する予定です。これは現状含まれていません。 ?実験的な機能 about:preferences（設定サイト） に Floorp の設定を実験的に追加しました。追加された設定は以下の通りです。現状適用には再起動が必要です。 1. 現在テーマに実装されている二つのカスタムCSSテーマを他のテーマと併用可能にするため、垂直タブに最適化・水平タブ位置移動のCSSをブラウザーに適用するか選択できるような設定を追加しました。 2. 新機能として、マウスサイドボタン操作に最適化するという設定も追加しました。これをオンにするとツールバーからいくつかのボタンが削除されます。 3. 更に新機能として、Floorp の水平タブの表示をするかしないかの設定も追加されました。 4. 垂直タブに最適化するCSSに含まれるツリー型垂直タブの挙動を変更するCSSは分離され、通常時も適用可能になりました。 5. ツールバーにマウスをフォーカスした際に、ブックマークバーの自動開閉を行う設定を追加しました。 Floorp が今世代である以上、CSSテーマを削除する予定はありません。次世代ではテーマの仕様自体を変更予定です。また、いくつかの設定は併用不可です。カスタムCSSテーマとの併用も推奨されません。今後、設定項目は増える予定です。 ...

AlexandriteOS 3.00開発記の第二弾です。 AlexandriteOSにはGnomeデスクトップが採用されています。安定性や統一感の点で優れているDEでKDEと同じく歴史あるデスクトップです。 2.00での最大の問題の一つは拡張機能でした。デフォルトのGnomeデスクトップはかなりクセが強く正直に言って使いにくいのでAlexandriteOSでは幾つかのGnome拡張機能に多少の変更を加えたものをプリインストールし標準で適用しています。 しかし本来拡張機能はGnomeやopenSUSEから見ればあくまでもハックであり正式なものではありません。これを安定してデスクトップとして提供するためにAlexandriteOS 3.00では追加の工夫をしています。 AlexandriteOSの開発者は、Gnome拡張機能がたまに起動時に無効になることがあるという不具合にかなりの間悩まされ続けていました。 AlexandriteOS 3.00ではログイン毎にGnome拡張機能を有効にするというコマンドを実行することでこれを可能な限り回避しています。なんとも原始的に聞こえますがコマンド実行の負荷は少なく確実な解決策です。 これで安心していましたがGnome42がリリースされ新たな機能が実装されました。それは拡張機能が一つでもクラッシュすると次の再開時に全ての拡張機能が無効になるという機能です。 https://github.com/home-sweet-gnome/dash-to-panel/issues/1581#issuecomment-1088263998 安定性の観点からは素晴らしい実装ですが拡張機能に依存しているユーザーからすれば迷惑でもあります。幸い、先程の回避策はこれもバイパスしてくれます。 一見全てが収まったように見えますが、大問題が発生することに気づきました。これを適用したことでログインループが発生する可能性が高いことです。具体的にはユーザーがシェルをクラッシュさせる不具合を持った拡張機能をインストールした場合、次のようなことが起こります。 不具合を持った、もしくはAlexandriteOSでプリインストールされている拡張機能と競合する拡張機能をインストールします。 有効にした途端、シェルがクラッシュしたと仮定します。（これは普通発生しないように見えますが、競合する拡張機能をインストールした場合、もしくはgnome自体にバグがある場合に発生しやすいことです） シェルが異常終了し、ログイン画面に戻されます。 ユーザーが再度ログインすると、gnome-shellは拡張機能を無効にして再開しようとします。 しかし先程適用した回避策が拡張機能を有効にしてしまいます。 再び途端にシェルがクラッシュします このループに陥った場合、残念ながらGUIのみでシステムを回復することは不可能です。上級ユーザーであればコマンドラインモードからdconfの設定値を書き換え修復できますが、これにはそれなりの技術が必要ですし正直に言って面倒です。 さらに悪いことにこれはセキュリティ上の欠陥でもあります。だれでも有効化した途端にシェルをクラッシュさせる拡張機能をインストールさせれば自動的にGUIを利用不可能な状態にすることができるからです。 拡張機能をインストールする際、ブラウザからインストールすれば確認ダイアログが出ますがそれ以外の場合は出ません。裏でファイルをコピーしコマンドを一つ実行するだけで拡張機能は通知なしに有効になります。 さらに Gnomeの拡張機能では驚くべきことに署名どころかハッシュでのチャックですらされません。 つまり既にインストールされた拡張機能の中身を差し替えるだけでこの攻撃が成り立ちます。（正直に言って、かなりの権限を持つデスクトップの拡張機能に対してこの甘さは改善すべきというかあり得ないと思っています。） gnome-extensionをプリインストールソフトから消すことになった理由は実はこの2つです。消したと言ってもコマンド一つでインストールできることには変わりません。 そもそも言ってしまうと拡張機能を標準で使用しているディストリビューションは多くても、gnome-extensionをプリインストールしているディストリビューションは少ないのでなんとも言えませんが標準状態でのカスタマイズ性が大きく低下する変更であることには変わりないのでそれなりに悩みました。 しかしログインループは致命的な問題ですしセキュリティ上のリスクも大きくなります。あくまでも拡張機能は非公式の機能でありリスクを伴い自己責任であるということを強調するという意味も含めて廃止しました。 もちろん、安定した信頼できる拡張機能はユーザーに大きな利益をもたらします。しかしくれぐれもコマンドラインから修復できる自信がない限り、無闇に競合する拡張機能や不安定な拡張機能をインストールしないようにしてください。

このリリースには延べ4ヶ月近くに及ぶ作業の成果が組み込まれています。3.00はセキュリティ、パフォーマンス、UI、使い勝手、信頼性などあらゆる点で2.00よりも優れており飛躍的に進化しています。 セキュリティの強化 ・カーネルロックダウンが標準で有効化されています。 ・Yama LSMが新たに標準で有効化されています。 パフォーマンスの向上 ・Gnome42の新機能により基幹部分での処理が改善されました。 ・ブートプロセスが見直され、起動が高速になりました。 ・CPUのマイクロコード（AMD・Intel共に）が追加され、パフォーマンスが改善されました。 ・動画再生時にハードウエアアクセラレータを使用するようになりました。 信頼性の向上 ・PackageKitは標準で無効化されました。PackageKitはユーザーの操作を妨害し時々システムを破壊します。 ・zypperの「パターン」機能を利用してパッケージをプリインストールするのを廃止しました。これによりアップデートで消したはずのプリインストールソフトが復活したり、余計なパッケージがインストールされることが防止されます。 ・GRUBエントリーからリカバリーモードを利用できるようになりました。systemdのレスキューモードで起動します。 ・Btrfsが標準のFSになり、システムのロールバックが可能になりました。 デザインの改善 ・libadwaira風のGtk3テーマを標準にし、非libadwaitaソフトウェアとlibadwaitaソフトウェアの見た目の差を軽減しました。 ・GRUBのテーマと起動画面が進化しました。 ・ロゴが @kr-tukimi さんが作成したエレガントなロゴに変更されました。 ・デスクトップ、ラップトップ、タブレットなどあらゆるデバイスで使いやすいデスクトップへと進化しました。 デスクトップユーザー向けに画面左上には伝統的なスタートメニューが配置されています。 タッチパネルやマウスパッドのジェスチャー（デスクトップの何もない部分を３本の指で下にスクロール）を使うと全画面のアプリ一覧が出てきます。 キーボード派の人間のためにsuperキーからのアプリ検索も使用できます。（スーパーキーを押すとGnome3のアクティビティ画面に移行します。そこで任意のキーをタイプして検索を開始できます。） ・Plymouth表示前に表示されていた余計なメッセージが消され、スッキリとした起動画面になりました。 Gnome42の変更への追従 ・ gedit と gnome-terminal はそれぞれ gnome-text-editor と console に置き換えられました。 ・libadwaitaの導入に伴い、gnome-tweaksを削除しました。後からインストールすることも可能ですが、テーマはレガシーアプリケーションにしか適用されません。これはlibadwaitaソフトウェアとそうでないソフトウェアの見た目に乖離が生じることを意味します。 その他変更 ・ gnome-extensions が削除されました。これはプリインストールされている拡張機能がユーザーがインストールする拡張機能の動作に影響を及ぼし、結果としてグラフィカルシェルが不安定になる可能性があることが理由です。（最悪の場合gnome-shellがクラッシュします） もちろん必要なパッケージをユーザーがインストールすれば拡張機能を追加することも可能です。が動作の保証はできません。 なおセキュリティと使いやすさの観点から、拡張機能を任意に追加したい場合はブラウザのアドオンからではなく以下のソフトを使用することを推奨しています。 https://flathub.org/apps/details/com.mattjakeman.ExtensionManager ・ビルドシステムとインフラの改善により大半の独自ファイルがパッケージ化されたため、積極的なアップデート配布が行えるようになりました。 ・デフォルトのシェルがfishになりました。強力な補完機能が使えます。 既知の不具合 AlexandriteOS 3.00に採用されているGnome42は従来のバージョンと比べかなり大規模な変更が行われています。これが原因となる不具合が多少残っています。アップデートで改善される予定です。 ・ファイルマネージャーのパスのバーを右クリックして「新しいウィンドウで開く」を選択するとファイルマネージャーがクラッシュします。上流に報告済みです。 https://gitlab.gnome.org/GNOME/nautilus/-/issues/2208 ・ファイルマネージャーでsambaサーバーにアクセスした際、パスワードを誤っているとセグメンテーション違反でファイルマネージャーがクラッシュします。既に報告済みのようです。 https://gitlab.gnome.org/GNOME/nautilus/-/issues/2184 ・設定画面の「共有」タブを開くとセグメンテーション違反で設定画面がクラッシュします。gnome-control-centerの仕様上では再開時に前回開いていたページと同じページを開こうとするため、以降セグメンテーション違反で設定画面が開けなくなりますが。デスクトップを右クリックして「ディスプレイの設定」を2回開こうとすることで回復できます。これはgnome-control-centerの不具合で、現在修正パッチが上流で準備されています。 https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1727 https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1270 ・環境によって、インストール時にディスクのパーティション作成に失敗する場合があります。数回試しても駄目な場合、Gpartedとインストーラーで適切なパーティションを手動で作成、選択することで回避できます。 またプログレスバー下の表示（コピーされたファイル数 / 総ファイル数）の総ファイル数が処理が進むのに連動して後から伸びるというクレイジーな不具合があります。これは特に動作に影響を及ぼすことはありません。どちらもcalamaresの不具合ですので、こちらで修正することはかなり難しいです。 不具合ではない仕様 ・ AlexandriteOSでホームディレクトリ下のディレクトリ名が英語なのは仕様です。 これは日本語がパスに含まれていると一部のアプリケーションが正常に作動しないこと、ターミナルでの操作がしにくくなることが理由です。ただし副作用として、ファイルマネージャーのサイドバーが英語になっています。アイコンがある上に簡単な英語なので操作の支障にはならないと判断していますが、このままだと気分がよろしくないので今後なにか対策をする予定です。 ・VirtualBoxなどの仮想化ソフトウェアを使用している場合、画面が正常に描画されません。 これはVirtualBoxなどの一部の仮想化ソフトウェアが標準で非常に低い解像度をデフォルトで強制すること、及びグラフィカルシェルがソフトウェアレンダリングになることが主な理由です。画面が小さすぎる場合、 デスクトップ右クリック→ディスプレイ設定 から解像度を変更できます。 これに関しては私や上流に不具合として報告されてもどうすることもできないので仮想化ソフトウェアのベンダーに問い合わせてください。 ・インストール時に表示されるスライドがぼやけている ...

前回はsystemdに関して色々まとめた何かを書きましたが今回はLinuxデスクトップでのグラフィック周りについてのお話です。これに関しては日本語の情報がほとんどなく間違ってる部分もあるかもしれません。その際は遠慮なく指摘してください。 Linuxデスクトップといっても沢山あるので、今回はAlexandriteOSやFedoraなどで標準のWayland利用のデスクトップの場合について解説します。 ここで一つ理解して置かなければならないのはWaylandはあくまでもただのプロトコルとライブラリであって、従来のXserverのようなものではないということです。要はWaylandはあくまでルールに過ぎないということです。（厳密には違いますがややこしくなるのでこの解釈でここでは問題ありません） いきなり分かりにくい図が出てきましたが、これがAlexandriteOSやFedoraのグラフィックの仕組みの基本的な部分です。一つ一つ見ていきましょう。 この図において一番目につくのはWaylandコンポジターという部分です。このWayland CompositorはDEによって異なります。Gnomeの場合はmutter、KDEの場合はKwinがコンポジターです。 このコンポジターこそがグラフィックの中枢システムです。 ① マウスが動かされたなどのイベントが発生すると、カーネルからwaylandコンポジターに伝わります。 ② コンポジターはイベントを受け取ると、どのウィンドウがそのイベントを受け取るべきかを判断し、適切なクライアントに送信します。 ③ クライアントはコンポジターからの通知を受け取ると、EGLとMesa 3Dを使用してレンダリングを行い、更新された領域を示すリクエストをコンポジターに送ります。レンダリングはlibDRMを通してフレームバッファに行われます。 ④ コンポジターはレンダリングが行われたことを受信すると、先程レンダリングされたフレームバッファ内のコンテンツをテクスチャとして利用し変更された領域を合成します。KMSを通じて画面を再描画し、最終的にディスプレイの内容が更新されます。 しかしこれだけで全てが成り立っている訳ではありません。 グラフィックシステムの最終的な全体像はこうなります。 ・XwaylandとはX11のみに対応しているレガシーアプリケーション（図中のX11-Client）を実行するための仕組みです。この図の通り、Wayland上でXorgを実行することで互換性を維持しています。 ・ゲームなどの高パフォーマンスを要求するソフト（図中の “3D Gmae Engine”）はVulkanやOpenGLなどのAPIを利用してグラフィックメモリバッファに直接レンダリングします。クライアントとコンポジターはバンドラーを利用してこのグラフィックメモリバッファにアクセスします。この手順では間に余計なデータのコピーを挟まないため高速に描画できます。さらにコンポジターは、APIクライアントと同じハードウェアアクセラレーションAPIを使用することで、ディスプレイに表示する最終的な合成をさらに最適化することができます。 LinuxデスクトップはWindowsなどと比べて遅れていますがWaylandやPipewireの導入などで状況が変わりつつあります。AMDの躍進でグラフィックドライバーも整備されつつありますし、Steam Deckの登場でLinuxゲーミングという分野も復活しつつあります。Gnome42でもグラフィック周りの改善が入っていますし、KDEも本格的にWaylandに対応しています。今後の動向を注視する必要がありそうです。

Linuxを触った方なら一度は「systemd」という名前を聞いたことがあるかもしれません。今日はこいつが何者なのかを紹介しようと思います。 systemdは一言で言えば複雑なシステム（巨大な航空機）を操縦するパイロットのようなものです。 現在のほとんどのディストリビューションは、アンチsystemdを掲げるなどの思想が偏ったディストリビューションでない限りsystemdが標準です。 systemdはRedHatのエンジニアによって開発されました。PluseAudioと同じ開発者であり、この方は後にFlatpakの基礎となる考えを考案した人でもあります。 systemdはカーネルが起動してからシステムを利用可能な状態にするのが主な役割です。ブートローダーがカーネルを読み込み、カーネルの起動が完了するとカーネルは /sbin/init をPID1として実行します。systemdを使用する環境だとこれはsystemdの実行ファイルへのシンボリックリンクとなっているので、systemdがPID1として起動します。 さてここからがsystemdの出番です。カーネルのみが起動している状態ではグラフィカルシェルはもちろん、CLIですら使用できず最低限の機能しか起動していない状態です。 ここでsystemdは必要なサービスやプロセスを次々と起動させシステムを利用可能な状態にします。航空機で例えるのであれば離陸し水平に飛行できるようになるまでの段階です。 ここからがやや複雑な部分です。systemdはユニットと呼ばれる設定ファイルを元にシステムを構成し起動させます。 ユニットには、サービスの起動に関する設定やパーティションのマウントに関する設定などの複数の種類があります。 ここで実際にどんなユニットがあるのかお手元の環境で見てみましょう。 systemctl list-unit-files を適当な環境で実行してみてください。 ここではいくつかのメジャーなユニットの種類を紹介します。 .mount パーティションのマウントに関する設定。一部は /etc/fstab を元に自動生成される。 .path パスの変更を監視する設定。パスのディレクトリやファイルの内容が変わったら実行するコマンドを定義する。 .service プロセス（デーモン）の起動に関する設定 .serviceのユニットファイルには ・そのサービスが何か別のサービスに依存しているのか、どのサービスが起動した段階でそのプロセスを起動させるべきなのか ・そのプロセスを起動させる際に実行するコマンド ・プロセスが異常終了した際にどうするか などが記述されています。 .target ユニットの集まり。複数のユニットをグループ分けにする。詳細は後述 完全なリストは以下のリンクから見れます。 https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/system_administrators_guide/chap-managing_services_with_systemd#tabl-Managing_Services_with_systemd-Introduction-Units-Types この際に役立つのが.targetユニットです。 例えばLiunxディストリビューションを起動させるといっても最終的にグラフィカルシェルを起動させるのか、あるいはコマンドラインモードで起動させサーバーとして使うのかなど様々です。 どのモードで起動させるかを設定するのに.targetは役立ちます。 systemdは /etc/systemd/system/default.target の内容が最終的に起動することを目標に ユニットの設定を解析し起動順序を設定し、それに沿って各サービスを起動させたりファイルシステムをマウントしたりします。 このdefault.targetはデスクトップ環境ではgraphical.targetへのシンボリックリンクになっています。 そしてサーバーなどの環境ではmulti-user.targetへのシンボリックリンクとなっています 他にもpoweroff.target(電源オフ)やrescue.target(レスキューモード)、reboot.target(再起動)など様々なターゲットがあります。 勘が良い方なら気づくかもしれませんがpoweroff.targetはシャットダウン時に、reboot.targetは再起動時に利用されます。忘れられがちですが、システムをシャットダウンするときにもsystemdは仕事をします。サービスやプロセスを順次安全に終了させるのが役割です。航空機で言えば着陸です。 いざ起動やシャットダウンをしたからといって安心できるわけではありません。何らかのプロセスが異常終了し、システムの一部の機能が利用できなくなることがあります。このような際にsystemdは停止したデーモンを再起動しシステムの修復を試みます。（ただしサービスの設定ファイルに異常終了時再起動するという設定がない場合は何もしませんが、重要なサービスの設定ファイルに大体再起動するよう書かれています） 大抵の場合、これで自体は収束します。航空機の例えで言うのであれば飛行中に何らかのアクシデントが発生し、それにパイロット（ここではsystemd）が対応するようなものです。 ここまで見てきたとおり、systemdはLinuxシステムにおいて極めて重要なプログラムであると言えます。それと同時に複雑なシステムの全体像を設定しやすくしてくれています。 systemdが最初から全ての人に歓迎されていたわけではありません。UNIX哲学に反しているなどでGnome3論争と合わさり一時期コミュニティが大荒れ状態になったこともあるそうです。ですがsystemdが現在標準であり、Linuxディストリビューションをより扱いやすいものにしてくれたという事実は変わりません。 普段何気なく使っているディストリビューションでも、こうして掘り下げてみると面白い発見がありました。systemdは現在も進化を続けており、今度時間があったらsystemd-bootやsystemd-homedも試してみたいなと個人的には考えています。 最後まで読んでいただきありがとうございました。