開発

AlexandriteOS 3.00を先日リリースしました。見ての通りUIが完全に新しくなっています。このUIがどういう経緯で実装されたのかを紹介したいと思います。 2.00での最大の課題はタスクバーの全ての要素が下に配置されているせいで画面が小さいデバイスだと表示しきれないときがある点と全体的にデスクトップ以外で使いにくいという点でした。 そこで考案されたのがこんなUIです。 このUIは画面の要素の大半を小さくしトップバーに配置しました。 しかしこれは小さすぎます。じゃあ大きさを変えないで上下に分散すればいいじゃんということで次にこんなUIが実装されました。スタートメニューは廃止され検索ボタンを代わりに配置しキーボードで主にアプリケーションを起動させる仕組みに変えました。 どうせならアイコンも新しくしようということで新アイコン（kora-icon-theme）が実装されました。 これはi3wmのようにキーボードでソフトを起動させることを好むユーザーには良いUIですがやはり一般的なスタートメニューの方を使うユーザーの方が圧倒的だろうということでこれにスタートメニューが実装されたのがこのUIです。 キーボードで検索するような人はわざわざマウスで検索ボタンを押さないだろうということで検索ボタンは葬られました。アイコンは様々な問題があったため新しく変更されました。 あらゆるデバイスでの使いやすさの両立をできるように設計されたのが新しいUIです。 右上には古典的なスタートメニューがあります。これはデスクトップユーザーのためのものです。クリックするだけで見慣れたスタートメニューが出てきます。 しかしこれには大きなマウスの移動が伴います。やはりタブレットやラップトップではタッチパッドのジェスチャーで操作するのが最適です。実はデスクトップの何もないところを3本指で上にスクロールすると、アクティビティ画面から全画面のアプリケーションリストが表示されます。これは画面が小さいデバイスに最適化されたリストです。 これで満足しているわけではありません。i3wmのようにキーボード操作のみでアプリケーションを起動することを好むニッチなユーザーがいることを知っているからです。私もその一人です。 幸いこれらの人々のためにGnomeは高度な検索機能を有しています。これを活用しない訳にはいきません。superキーを押すとアクティビティ画面に移動します。任意のキーをタイプして検索を開始できます。例えばキーボードのみで素早くFirefoxを起動させたい場合、superキーを押して"f" “i” “r” “e” と順番にタイプすれば起動できます。 これは慣れると実に快適なのでオススメです。長いリストからの選択や面倒なマウス移動無しでアプリケーションを起動させられます。また計算式を入力することで簡単な計算も行えます。 AlexandriteOS 3.00のUIはMacのパクりのように見えてそうではないとお分かりいただけたでしょうか？ なにか感想や要望などあればTwitterやコメントに気軽に投稿してください。

この記事では新しくなった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は様々なファイルが複雑に依存しあっています。また上流のものに少し手を加えたものが多くこれらを通常の個別のパッケージとして配布すると様々な不具合や誤解の原因になります。そこで一つのパッケージにまとめる必要があるのです。 しかしここで問題が発生します。パッケージを一つにまとめた場合そのパッケージのメンテナンスの手間が大幅に上がります。そこで新たにモジュールという単位を作りリポジトリを分割している訳です。 以上小ネタなのか備忘録なのか開発記なのかよく分からない記事になってしましたが色々工夫があるのだと知っていただければ幸いです。

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をプリインストールしているディストリビューションは少ないのでなんとも言えませんが標準状態でのカスタマイズ性が大きく低下する変更であることには変わりないのでそれなりに悩みました。 しかしログインループは致命的な問題ですしセキュリティ上のリスクも大きくなります。あくまでも拡張機能は非公式の機能でありリスクを伴い自己責任であるということを強調するという意味も含めて廃止しました。 もちろん、安定した信頼できる拡張機能はユーザーに大きな利益をもたらします。しかしくれぐれもコマンドラインから修復できる自信がない限り、無闇に競合する拡張機能や不安定な拡張機能をインストールしないようにしてください。

皆さんこんにちは。AlexandriteOS開発者のnexryaiです。 AlexandriteOSの次期バージョンである3.00のおおまかな仕様とロードマップが決まったのでお伝えします。なおこれはあくまで2月11日時点での計画ですので変わる場合もあります。 予定している変更 ・デスクトップ周りの大幅な変更 Gnome42が2022年3月にリリースされる予定です。このGnome42にはかなり大きい変更が入っているのでそれに追従する形です。 まずGnomeコアアプリケーションでのlibadwaitaの導入に合わせAlexandriteOSでは非libadwaitaソフトウェアもlibadwaitaのような見た目で動く変更を導入します。具体的にはlibadwaita風のgtkテーマを採用します。 またUIの一貫性を保つためシェルテーマやアイコンテーマもこれに合う雰囲気のものへ変更します。 今バージョンからMac OS風のUIになります。Gnomeの優れた検索機能と便利な拡張機能を用いてゲームを操作するような感覚で操作できるデスクトップを目指しました。 ・ロールバック機能の実装 デフォルトのFSをbtrfsに変更します。この変更によりシステムをスナップショットを生成した時点に完全に復元できるようになります。もちろん復元しないファイルを個別に選択することも可能です。これはアップデートや設定ミスなどでシステムを破壊した際のリカバリーに非常に役立ちます。 ・ロゴの変更 AlexandriteOSのロゴが新しくなりました。kr-tukimi氏が作ってくれました。非常にモダンで清潔感があるロゴになりました。本当にありがとうございます。 ・GUIターミナルのデフォルトのシェルがfishに GUIターミナル（Gnome terminal）のデフォルトのシェルがbashからfishになりました。優れた補完機能とシンタックスハイライトをデフォルトでお使いいただけます。ログインシェルはbashのままなので互換性周りでトラブルが発生する心配もありません。 ロードマップ 中の人の個人的な事情もありリリースはまだ先になりそうです。 まずGnome42と拡張機能の互換性についてです。3月初旬にGnome42のおおまかな仕様が確定しRC版が出るのでそのバージョンのGnomeで拡張機能の互換性をテストします。そこで問題が発生したら本家にはまだ未適用のパッチを当てるなり上流にPRを出すなりしてGnome42で動作するようにします。 またAlexandriteOS 3.00では独自パッケージで一部の固有のファイルをプリインストールする予定ですがこのインフラの整備にも少し時間がかかりそうです。気長にお待ちいただければ幸いです。 最終的なリリース時期はGnome42の正式公開後を見込んでいます。 最後にAlexandriteOSのlite版ですが開発を一時保留としています。理由は色々ありますがWorkstation版と両方メンテナンスできる自信がなく開発も難航しているからです。いつ再開するかは未定です… AlexandriteOSはさらに実用的で統一感のあるモダンな体験を実現するOSを目指し、進化を続けていきます。今後ともよろしくお願いします。

こんにちは。こまもかです。 今回は僕が普段使っているコマンドツールについて紹介します。 アイキャッチ画像は(おにけもだんすを聞きながら)実際に開発している風景です。DEはi3wm。 紹介するコマンドツールたち lsd PlemolJP broot ranger moc cava tmux StarShip fish bat Neovim lsd https://github.com/Peltoche/lsd 某薬物を彷彿とさせる名前ですが、ディレクトリが見やすくなって開発効率が上がります。 導入にはNerdFont(が含まれているフォント)が必要なので、導入してから使いましょう。 PlemolJP ツールではありませんが、フォントの話になったのでここで紹介を。 僕はいつもPlemolJPというフォントを使っています。日本語にIBM Plex Sans JPを使用しているので日本語表示がとても見やすいです。また、プログラミング時にトラブルになる全角スペースを表示してくれるので、スペース絡みのトラブルの防止にもなります。 https://github.com/yuru7/PlemolJP broot https://github.com/Canop/broot ファイルツリー状のファイルマネージャーです。 ディレクトリ構造を把握しながらファイルを探索する事が出来るので、ディレクトリ構造がごちゃごちゃしているプロジェクトで重宝します。 ranger 有名なCUIファイラです。 CUIファイルマネージャと言えばまずこのソフトが出てくるのではないでしょうか？w3mというテキストブラウザに付属しているw3mimgdisplayを使うと画像のプレビューまでをrangerで完結出来るので便利です。ターミナルで完結はしませんが、eogというコマンドも画像の確認に便利です。 moc https://github.com/jonsafari/mocp CUIミュージックプレビューです。直感的に使えるのでとても使いやすいです。また、mocp-themesを使えば好みの色にカスタマイズ出来るのでオススメです。 cava https://github.com/karlstav/cava よくunixpornに出てくるあのグラフみたいなのです。僕はよく、tmuxで水平分割した下側のペインで走らせてます。 StarShip https://starship.rs/ シェル用の最小限の、非常に高速で、無限にカスタマイズ可能なプロンプトです！ https://starship.rs/ja-JP/ ターミナルのプロンプトを簡単にカスタマイズ出来ます。一通りのシェルに対応していてインストールも簡単なので、ぜひ一度は使ってみて欲しいです。ドキュメントが日本語にも対応しているので英語が苦手という人もぜひ！ fish 言わずと知れたフレンドリーシェルです。Posix互換では無いので、ワンライナーの実行時にやりづらさを感じることもありますがそれを補って余りある使いやすさがあります。 「俺はどうしてもPosix互換じゃないとダメなんだ！」という方はfizshがオススメです。 https://github.com/zsh-users/fizsh bat https://github.com/sharkdp/bat catがつよつよになった様なツールです。デフォルトでシンタックスハイライトが付いていて、lessみたいにjkで移動できたりします。わざわざVimで開くまでもないファイルを開くのに重宝しています。 Neovim https://neovim.io/ これだけで一つの記事がかけてしまうほど奥がブラックホールなので、サラッと説明します。 トリはNeovimです。NeovimはVimのフォークプロジェクトで、Vimと比べて新しい機能が早く実装されたりします。なので最新の技術を使いたい人などにもオススメです。 こう書くと、NeovimはVimを置き換えるプロジェクトなのではと思う方もいますが、このプロジェクトの目的はフォーク元のVimを良くするためです。実際にNeovimで実装されたフローティングウィンドウやターミナルモードがViにも追加されたりしました。 Neovimにはmsgpack-rpcが内蔵されていて、好きな言語でプラグインが作れたりします。さらにLua実行系がビルトインされているので設定ファイルをLuaで書くこともできちゃいます！ まとめ ここまで僕が使っているコマンドツールについて紹介しました。これらのツールをうまく使うことで、ターミナルでの作業効率を上げることが出来るのでぜひ参考にしてみてください！

このブログを見ている人なら一度は聞いたことがあるだろう Google Apps Script（通称：GAS）でAblazeの内部システムを作ってみました！ 名前は「Ablaze Emergency System（通称：AES）」！！ GASで作られたこのAESは最大震度6弱以上の地震が発生した時に、 Ablazeを維持するための自動化スクリプトです。 AES は AEP（Ablaze Emergency Protocol）という、 災害時などの対応方法を記したプロトコルと一緒に 制定・開発が進められました。 使ったシステムとかいろいろ GAS Google Drive™ Cloudflare API Cloudflare Pages™ Realtime Database ( Firebase™ ) SendGrid® ( 構造計画研究所 ) Twitter API Webhook ( Discord ) 地震情報API ( なりかくん ) AESが勝手にやってくれること WebhookでDiscordに災害情報の投函 SendGridを使用した、安否確認メールの一斉配信 Twitter APIを使用した、緊急情報の配信 Cloudfllare APIを使用した、バックアップサーバーへの自動切換え どんなふうに動くの？ 色々やってくれる。 地震情報を定期的に取得 （最大震度6弱地震以上の場合） すでにAESが実行されていないか Realtime Database にアクセスし、確認する （実行してない場合） Realtime Database のステータス状況を「実行済み」にセットする Webhook で Discord の特設チャンネルに地震に関する主な情報を投稿 画像は Google Drive に保存してるため、地震規模により最適な画像を選択 SendGrid で安否確認メールを自動配信 メールアドレスのリストは Google Drive に保存してるので取得 Cloudflare API を使用して「ablaze.one」のAレコードを削除 Cloudflare API を使用して「ablaze.one」のバックアップサーバーへのCNAMEを追加 Twitter APIを使用して、Twitter にて自動的に対応を終わらせたことを公表する 実行結果を Webhook で Discord に自動投稿 作成時間とかなんとか AEP/AES プロジェクト始動開始日： 2021/10/07 AES 製作開始日：2021/10/11 （多分） AEP 草案完成日：2021/10/15 AEP 制定日：2021/10/23 AES 完成日：（まだ作ってる） ...