2025年 8月 29日

CassetteOS

オープンソース CassetteOS Orcinus

おごちゃん

Orcinusのリリースエントリの第三弾です。

Orcinusプロジェクトでは、OSを作りました。

まぁ「OS」と言ってもkernelを作ったわけではないのですが、アプリケーションの実行環境としてのOSです。また、スクラッチから作ったわけではなくて、CasaOSからのforkです。

今回はなぜOSを開発するに至ったかということと、その目的、またどうしてforkなのかという点について書こうと思います。

背景

Orcinusは「ウェブアプリが動くサーバをサーバ管理の手間を極力少なくして提供する」という側面があります。

現代、多くのアプリケーションはウェブ上に存在していますし、その方が使う環境を選ばずに済むわけですから、多くのアプリがこの方向に進化しました。もちろんそれには限界があって… というような話はここでは省きます。とにかく「手軽にローカルでアプリを色々使う」ことをポータブルにやろうと思えば、必然的に「ローカルサーバにアプリを入れて運用する」ということになり、それを「民主化(*1)」するためにはいかに手軽にサーバ管理をさせるかということになります。

実は現代ではそれはある程度実現されていて、たとえばQNAPのNASにはそのような機能があったりします。

システム管理もアプリインストールもクリックするだけでできるようです。

こういったものが手元のサーバで使えれば、サーバについての高度な知識や能力なしで「自分のサーバ」が構築できるじゃないか… と、かつては横目で見ていました。

最近になってCasaOSやTipiを見て、「この応用の先に作れるんじゃないか？」ということを思うようになりました。

細かい技術的な話をすれば、QNAPのそれとCasaOSやTipiのそれは実現方法が異なります。

"CasseteOS"に求めるもの

こういったことを考えてCasseteOSに何を求めるか、それによって何を追加するべきかを考えてみました

必要そうなことを雑に列挙してみます

ハードウェアや実行環境の管理
アプリケーションのインストール、運用
バックアップ等のシステム作業
アプリケーションやシステム全体の保守

要するに「サーバ管理」ですね。

このうちハードウェアの管理については、用途を限定してしまえばある程度しなくて済みます。たとえば、ディスクの増設とかは、考えれば考えるほど難しいものになりますが、ある程度の割り切りをしてしまうことで手間を減らせますし、「業務サーバ」という割り切りをしてしまえば、増設そのものが不要になるかも知れません(業務システムで使うデータは現代のストレージから見るとごく小さいものでしかありません)。

今回考慮に入れたものは、

バックアップデバイス
ネットワーク(Wi-Fi)

あたりです。

ということで、全ての問題を正面から解決する必要はなかったりしますが、それでもCasaOSやTipiでは不足を感じます。

ポリシーの問題

弊社がOrcinusに求めているものは、

21世紀のオフコン

です。

と書いても、そもそも「オフコン」が20世紀末に絶滅したコンピュータなので、要説明ですね。

オフコン(オフィスコンピュータ)について

総花的な説明はWikipediaの

オフィスコンピュータ

を見ると良いと思うのですが、これだけではニュアンスが伝わりにくいだろうと思います。

もうちょっと簡単に説明すると

中小零細の会社のバックオフィスシステムが主に動いていた
主にはパッケージシステムを動かしていた
運用はスイッチのオンオフとかバックアップデバイスの準備というような簡単なもの

というコンピュータです。規模はそれ程大きなものではありませんでしたが、下位メインフレームに匹敵する規模のものもありましたので、ハードウェア規模で呼ぶ名称(「ミニコン」とかはそうですね)ではなくて用途で呼ばれるカテゴリーです。ちょっと前(になった気がしますが)の「Windowsサーバー」がその地位を代替していたと思えば、だいたい当っていると思います。

一見汎用コンピュータの一種に見えますし、ハードウェアはだいたいそんな感じなのですが、OSや販売運用形態は「事務処理専用機」という位置づけでした。パッケージシステムのバイナリしか動かないのは当たり前で、ちょっと汎用性があるものでもCOBOLが動く程度。そのCOBOLも水準の低いもので… というのは私の当時の経験です。

コンピュータ屋から見ればCOBOLを更に煮詰めたような面白くも何ともないとも言えるものですが、エンドユーザは

事務処理が捗る
運用に工数がいらない
現場の省力化になる

ということで重宝されたものです。似たような規模の下位メインフレームは運用工数が随分必要だったりしましたから、それを思えば中小零細企業にとってはとても良いIT化でした。

もっとも今と違って「オープン」という思想はどこにもなかったので、便利に使うためにはベンダーの「シリーズもののアプリ」を購入するしかなかったのですし、データを外に持ち出すのは大変で… というのは、某レセシステムの初期にあった問題ですが、まさにそんな問題はありました。

オフコンの衰退と絶滅

現代ではオフコンはほぼ絶滅しています。

個人的にはこれはあまり技術的な問題ではないだろうと思っています。そもそも当時のオフコンの後継としてちゃんと使えるものは実在していないからです。

確かに「Windowsサーバ」が普及してそれによって押された結果の衰退という表面的な現象はありますが、「運用工数」の問題はあまり省みられなかったように思います。その傍証がクラウド(SaaS)の普及とも言えますし、クラウドが普及したタイミングがちょうどそうであったとも言えます。

そんなわけでオフコンのニッチは現代では「Windowsサーバ」と「クラウド」が埋めています。そして、それが十分じゃないだろうと言うのがOrcinusをを考え始めたきっかけです。

この辺の詳しい話はいずれ「技術閑話」にでも書こうかなと思います。

OrcinusとCasaOS(Tipi)とのポリシーの違い

gdgd書くと面倒臭いのでまず要点を列挙します。

「オフィス」を想定する必要
エンドユーザが簡単に使える必要
システムを意識しないシステム管理が必要

CasaOSやTikiは「パーソナルクラウド」を構築するものとして作られました。「パーソナルクラウドとは何ぞ？」という本質の問いは置いておくとしても、少なくとも「パーソナル」です。つまり、「個人が使うもの」という前提に立っています。ですから、

何でもrootアカウントで実行
アプリに認証がない(ものが多い)
共有という視点が皆無

です。

もちろんアプリによってはグループやコミュニティを意識したものがあったりしますが、そうでないものも大量にあります。

たとえばCasaOSにしてもTipiにしても、「メモアプリ」はいくつも用意されているのですが、「複数利用者で情報共有」という観点のものはありません。 SiYuan(思源)とか素敵なアプリなのですが、情報共有について全く考慮されていません。個人で使うには良いのですが、オフィスで使うのには向いていません(内容の受け渡しが実質的に不可能)。

「エンドユーザが簡単に使える」という点に関してはどちらもある程度は良いのですが、CasaOSは背後にZimaOSがあって、そのせいもあって色々な制約があります。これについては改めて書きたいと思います。 Tipiはそういったものはないのですが、エンドユーザ目線だとちょっととっつきが悪い面があります。具体的な商品の話を聞いたことがないので、そのせいかなと思います。

またどちらにも言えることなのですが、中途半端にオープンになっているので、アプリストアが無法地帯になっています。比較的マイナーな世界ですからスパイウェア的なものがあったりはしてないと思うのですが、同じアプリが複数のベンダーから公開されていたり、説明が十分でないものが大量にあって、ある程度「わかった人」でないと手が出せなくなっています。

この辺の主な原因は、何かが良い悪いではなくて「ポリシー」の問題だろうと思います。

CassetteOSプロジェクト

このような背景があって、CasaOSをそのまま採用することはやめて、あらためてCassetteOSとしてプロジェクトを始めました。

実は当初はCasaOSを修正してとか、upstreamにとか考えたのですが、

ポリシーがまるで違う
CasaOSにはZimaOSがある
そもそも反応してくれなかった

ということで、forkさせることにしました。

また、TipiではなくてCasaOSをベースにしたのは、CasaOSの方が完成度と扱いやすさが上だと判断した結果です。正直言えばTipiはサーバがNode.jsで書かれていた(CasaOSはGo)ので、Tipiの方が楽そうにも思えたのですが、

Goに入りてはGoに従え

だということで、CasaOSをそのままforkすることを選びました(つまりあまり考えてない)。

ポリシーの違い

CasaOSにしてもTipiにしても、あくまでも「パーソナル」を意識したもので「オフィス」を意識していません。この問題は既に書いたとおりです。

また、いずれもオープンソースのプロジェクトであり、「アプリストア」と言っても「フリーダム」になっています。これ自体はオープン真理教的立場としては悪いことではありません。と言うか素晴しいことだと思います。

他方、その「自由」には常に「自己責任」がセットとなります。技術者であれば「自由をもらったんだからそれくらい頑張れよ」でいいと思うのですが(それがオープンソースというものです)、非IT業の人、あるいはIT業であっても「そこ自分のフォーカスと違うから」な人にとっては面倒臭いだけのことです。

そういったこともあって、弊社から提供するアプリストアに関しては

用途と目的で厳選
必要十分な解説やレビュー
継続的なメンテナンス

が可能なものだけを掲載するようにしました。

当然これはオリジナルのポリシーとは異なりますから袂を分つこととなります。

ZimaOSのこと

ベースとしてはCasaOSとTikiを比較してCasaOSを比較してCasaOSを選択することにしました。これについては多くは述べませんが、既に書いたとおりです。

CasaOSを出しているIceWhaleには、もう一つZimaOSというのがあります。このZimaOSこそが現在の彼等のビジネスの中心(ZimaBoardとか)にあります。ですから、CasaOSはそのZimaOSのデモ版みたいな雰囲気があります。 ZimaOSのデモ版はそれとして公開されてはいるのですが、そのフレーバーを感じるオープンなものとしてCasaOSがあるという感じです。

このせいもあって、CasaOSのプロジェクトとしてのアクティビティはかなり低いです。力が入っていません。これは客観的なデータからも伺えます。とは言え、元々が主力製品だったこともあって(ZimaOSはその発展形)、既に十分の機能を持っています。これがこういった位置にあるオープンソースの面白いところですね。

そういった面白さはいいとして、CasaOSは

ちゃんと出しているプロダクト
それでいて力を意図的に抜いている

という、位置になってしまいました。

このため「そのまま使うにはショボいのだけどちゃんと使える」「ここをスタートにforkするには絶妙」という状態となりました。

forkの決定

CasaOSが「良いものだけど微妙」ということがわかったのと、公式(IceWhale)の反応が悪いことがあって、ここをベースにforkさせて我々のポリシーに合致するものを作るということに決めました。

当初は「独自アプリストア」を作るだけで済むと思っていたのですが、どうもそれでは足りないということと、CasaOSのゴールと背反するものを作ることになるということで、「CasaOSとして改良する」ことは不可能であるという判断です。ライセンス的には問題ないはずですが、一応「forkさせるぜ」という仁義は切ってあります。

forkの良いのは、最初からそこそこの完成度があるということですね。お陰で必要な機能だけ実装するという形の開発ができました。

もっともそれだと元のライセンスに縛られるコードが存在しますから、「テセウスの船(あるいは換骨奪胎)」式で独自コードで入れ替えて行こうとしています(CasaOSのGoは面倒臭い)。

現在の改良点

「forkさせて独自の道を歩いてます」とは言え、そんなにマンパワーがあるわけでもないので、出来たことは限られています。今までやったことは

ネットワーク(Wi-Fi)設定のための機能を追加した
理解してないユーザが危険な操作をしないように、危険な操作の機能を外した
独自のアプリストアを用意し、それをdefaultにした
危険そうなコードを発見して無効化(削除)した

あたりです。

ネットワーク設定

ネットワーク設定は有線LANであればDHCPとmDNSにお任せで簡単なのですが、Wi-Fiとなると少なくとも接続まではできるようにしなければなりません。この操作をサーバにディスプレイをつながないで出来るようにするのは、ちょっと厄介です。考え方としてはJar-Gardenでやっていたように「とりあえずAPとして動かし、設定したらSTAとなる」というような処理です。

「危険な操作」の除去

「危険な操作」はいくつもあるのですが、何しろCasaOSはドキュメントもイマイチですから、「それをすると何が起きるか」はコードを読むしかなく、それをエンドユーザに要求するのは無理です。また、こちらでコードを読んで解説を書いたところで危険な操作であることは同じなので、そういった操作は一度消してしまうことにしました。

元々は外付けドライブを追加したら簡単に使えるようにするといった有用な機能なのですが、現在のCasaOSでそれを行うと最悪システムを壊してしまう危険があるので、私自身も使わないことにしています。

この辺の機能はいずれ整理がついて必要になったら、あらためて実装すればいいだろうと考えています。

アプリストア

アプリストアは元々後からいくらでも追加できる仕掛けにはなっていたのですが、あくまでも「追加が可能」なだけで置き換えるようにはなっていません。その辺りがハードコードされていたりするので、修正しました。

ここも当然彼等には彼等の考えや都合があるはずですから、ゴールとしては背反するところでしょうね。

アプリストアをどう考えて構築しているかについては、後で詳しく書きます。

危険そうなコードの除去

「危険そうなコード」は、もうそこらじゅうにあって… とだけ書くとFUDと同じになってしまうのですが、具体的に何があったということを書くためには、あれこれ文書を書いてからでないとダメだと思うので(セキュリティ的に良くない)、ここでは勘弁してください。

一例を挙げるなら、

なんでそんなところにアクセスするの？
そこで何してるの？
開発のための統計収集した時のコードが残ってるだけだよね？？？
なんかクレデンシャルみたいなのあるけど、それ誰の？使っていいの？

みたいなのがあったりするわけです。

そして、その「危険そうなコード」が発動(invoke)されるかどうかも、どうもよくわかりませんでした。時限爆弾なのか盲腸なのか、それもよくわかりません。謎のバイナリコードの読み込みとか、危険な臭いしかしません。

ただどちらであったにせよ、そういったコードは将来の禍根にしかならないので、どんどん消しました。これも必要になったらあらためて書けばいいだけですし。

余談ですがこういった微妙なコードが大量に残っていることも、「力入ってないな」と感じた理由の一つです。

アプリストアのアプリケーション

CasaOS同様、CassetteOSにもアプリストアがあります。

ここにあるアプリケーションは、ワンクリックでインストールでき、すぐに運用に入れるようになっています。

ここに掲載するアプリケーションは、基本的には

弊社で動作確認以上のことができたもの
そのアプリケーションがどんなものか判断できる程度のドキュメントが提供できるもの
既に十分知られているもの

という基準で厳選したものを掲載する予定でいます。

実はこの辺がCasaOSもTipiも弱いところで、これらのアプリストアを見ると、サードパーティーのアプリストアのみならず、公式のアプリストアも玉石混淆という状態です。また、説明も十分でない上に似たようなアプリが並んでいたりして、「どれを入れたら良いかよくわからない」ものが少なくありません。

有名どころであれば説明不足でもわかりますし、「それしかない」とか「定番」というものであれば迷う余地もないと思うのですが、オープンソースの性質として「流行っている分野には迷うほど同類がある」「品質やプロジェクトのアクティビティがまちまち」「ドキュメントが微妙」といったものが随分とあります。この辺の「わけのわからなさ」がエンドユーザをオープンソースから遠避ける要因の一つであることは、この世界の人はよくわかっていることだと思います。

そういった背景があるので、CassetteOSのアプリストアは上のような基準をパスできたものだけを掲載することにしました。ぶっちゃけた表現をするなら、

推せるもの

だけを掲載するということです。

自由度やオープン度は下がりますが、CasaOSのアプリストアやサードパーティのアプリストアを追加することもできますので、「自己責任でいいから自由が欲しい」という向きはそのようにしてもらえば良いと思います。ただ、弊社からの公式提供のアプリストアは「エンドユーザを迷わせないもの」ということで、「これがいいですよ」とお勧めできるものを掲載するということです。

将来

将来ということでロードマップをちょっとだけ書いておきます。

当面のゴールとしては

スマホの感覚で扱えるサーバ

という方向に育てたいと思っています。つまり、

アプリの追加削除が簡単
システム管理も「素人の常識」の範囲の手間
単独のシステムとして採用できる

といったことです。

その代償として、汎用サーバとして使うことは難しいとは思います。ただ、そもそもそれはターゲットではありません。前述のように「オフコン」のように使うことがターゲットです。あくまでも事前に「それ用」として用意されたアプリケーションの実行環境を提供するというものです。極めて雑なキャッチフレーズを言うなら

サーバのAndroid

を目指すということです。「オフィス環境のためのOS」と言ってもいいですね。

システム管理については、利用者自身が運用することの他に、クラウド側から運用サポートをするための機能を付加し、「完全お任せ運用」ができるようにしたいとも考えています。これは「サービス」という側面もありますから、リリース直後からサービスとしては提供し、だんだんシステムの方で巻き取るようなことを考えています。つまり、リリース後にサポート契約をしていただければ、リモートから運用サポートをするサービスを提供します。

また、CasseteOS自体のライセンスは

CasaOSに由来する部分はApache2ライセンス
弊社で書いた部分はAGPL

でリリースしますが、ビジネス契約を結んでいただければ、OEMとしてAGPLを解除したライセンスでの提供もする予定です。弊社が提供するだけではなくて、広く一般に使われることを期待します。

アプリストアについては、今は弊社の管理下ということになっていますが、いずれはよりオープンで使いやすいものにしたいと考えています。課金とかサブスクとかもあったら嬉しいですし、アプリケーションの評価や人気がわかるのも選択の時の一助になると思います。

まとめ

このような考えで、独自の実行環境を開発し、それを公開することとしました。

これ自体はオープンソースですので、好きに使ってもらって構いません… と言うよりは大歓迎です。

実用本意で作ったものなので、遊戯に使うための機能が搭載されているわけではありません。ですから遊戯で入れてみるという需要には対応できませんが、「便利なものが簡単に動いているのが良い」という視点であれば便利なものだと思います。弊社内では便利なものとして既に使っています。

注

*1 「民主化」の原語はdemocratizationです。 democratizationはdemocracy(民主主義)からの派生語ですが、元々はそれほど政治的なニュアンスを持った語ではありません。これは技術的に開かれた(open)だけでなく、実際に誰もが利用・参加できるよう制度や支援体制を整えることを意味します。