メンテナンスモードは「このリポジトリはもうメンテナンスされていません」とは全然違うからね。

俺の経験から言うと、Garageは開発環境でMinIOの代わりに使うには最高の選択だと思う。自動セットアップがMinIOよりも簡単にできるかなり良いCLIを提供してる。ただ、プロダクション環境では、やっぱりCephが一番だと思う。だって、あれはかなり有名だからね。

いろんなブロックストレージの実装のトレードオフを理解できたら面白いよね。俺はシングルマシン用のS3互換ストレージとしてSeaweedFSを使ってるけど、すごくいい感じ。とはいえ、管理面での便利な機能（簡単なアクセスコントロールや、容量と使用量、エラーレートの理解など）が欠けてるのが残念かも…これ、もしかしたら自分の使い方の問題かもしれないけど。Cephも使ったことがあるけど、分散性にかなりこだわってる印象がある。ストレージ用のホストが4台未満だと、セットアップ時にバカにされてる気がする。パフォーマンスもイマイチだったけど、正直K8S/RookをFlannel CNIの上で使ってたから、簡単に使えるCNIではあったけど、パフォーマンス重視のシステムには向いてなかったかも。それでも、データの整合性に関してはCephのデプロイメントを信頼できると思う。なんか、「これを作った人は分散システムを本当に理解してるな」って感じがするんだよね。でも、その感覚を具体的なデータに落とし込むのは難しい。

自宅ラボ用に簡単にセットアップできる分散S3クラスターのためにGarageを使ったけど、めっちゃ良い体験だったよ。友達が運営するいくつかのラボをTailscaleやHeadscaleで繋いで、共有クラスターにしてるんだ。彼らは「最終的な整合性」モードを提供していて（設定はconsistency_mode = dangerousだから、7ナインのSaaSには使わない方がいいかも）、ローカルのS3ノードがリクエストを喜んで受け入れて（すぐに処理してくれる）、後で他のサーバーに複製する仕組みになってる。全体的に自己ホスティングや独立を目指す哲学があって、メンテナンスも分かりやすくて簡単。特別なことはしてないし、アーキテクチャや設計、運用の指示も理解しやすいよ。

rustfsとGarageの違いについてちょっと書いたよ。ここにあるよ https://buttondown.com/justincormack/archive/ignore-previous... それ以来、rustfsは私が見つけた問題を修正したみたい。用途が全然違うからね。rustfsはminioの書き直しに近いよ。

いいリストだね。minioのリポジトリにこれらを代替案のリストに追加するためのプルリクエストを開いたよ。https://github.com/minio/minio/pull/21746

Minioの他に、GarageとCephも試してみたよ。S3 APIを使ってインターフェースする何かが必要だと思うけど、裏ではシンプルなファイルシステムになってるものがローカルやテスト、小規模なデプロイメント用に必要だよね。それが存在するかは分からないけど。もちろん、S3にいろんなものが追加されてて、最初に言われてたほどシンプルじゃないからね。

別のオプションの作者なんだけど、S3ゲートウェイを持ってて、S3サーバーとして自分を公開するけど、実際にはS3のリクエストをSFTP、ローカルFS、FTP、NFS、SMB、IPFS、Sharepoint、Azure、gitリポジトリ、Dropbox、Google Drive、別のS3などに転送するプロキシなんだ。完全にステートレスで、接続されているものにS3の呼び出しを翻訳するプロキシとして機能するよ。

簡単なユースケースにはruftfsを使ってる。minioの代わりにね。すごく軽量で、めっちゃ速いよ。

ちなみに、AIStorはMinIOチームが作ったもので、これは単なるアップセルだよ。

私の経験から言うと、rustfsには可能性があるし、たくさんの機能をサポートしてる。自分の秘密鍵やアクセスキーを持ち込むこともできるから、クレデンシャルを変更せずに移行したい時には便利なんだ。ただ、まだ開発中で、コードにはバイトアンドスイッチの準備もされてるみたい（https://github.com/rustfs/rustfs/blob/main/rustfs/src/licens...）。機能的にはCephが実際のS3に最も近いけど、セットアップには手間がかかるよ。ローカルサーバーがいくつか必要で、別のサイトにレプリケートもできるけど、各サイトはストレージサーバー間でかなりレイテンシに敏感なんだ。他にもいろんな機能があるけど、S3は彼らのオブジェクトストアの上に構築されていて、VMストレージやFUSE互換のFSにも使える。Garageは素晴らしいけど、あくまで「物を保存するため」って感じで、S3側の機能（S3には多くの高度なACLがあって、代替品はサポートしてないことが多い）や管理面（例えば、「特定のパスにアクセスできるアクセスキーを許可する」みたいなのが不可能）では機能が不足してる。クラスター機能もWANに敏感で、Cephとは違って、レプリケーションをしたいなら同じラックにストレージサーバーを置かなきゃいけないんだ。

複雑だけど、Cephのストレージとコンセンサスレイヤーは実績があって、真剣に使うにはもっとしっかりした基盤だよ。ただ、ノードがフルにならないように気をつけてね！

それってI（インディゴ）それともl（ラマ）？Lだと思ってた、笑

フランス語では形容詞が名詞の後に来るから、AIは実際にはIAになるんだ。AWS S3には「Infrequent Access」っていうストレージレベルがあって、どこでもIAって略されてる。数週間前、ある顧客に「いや、私たちのデータをAIに渡すつもりはない」って説明するのに、めっちゃ時間がかかっちゃった。私のレポートではコスト削減のためにS3 IAに頼るって話をしてたのにね…。

自分の製品に対して料金を取ること自体は全然悪くないと思う。ただ、みんなにあなたの製品がFOSSだと信じ込ませて、彼らがインフラに統合するためにたくさんの作業をするのを待ってから、バイトアンドスイッチをするのは問題だと思う。最初から、あなたの製品が最終的にFOSSライセンスを放棄することになるって正直に言えばいいんだ。そうすれば、みんなが情報に基づいた決定をできるから。もしそれをしてないなら、正しいことをして、最初に約束したことを守り続けてほしい。

結局、あなたの製品にお金を払わない人たちと関わるのは楽しくない。逆に感じるな。自分が作ったソフトウェアを買ってくれた人たちと仕事をするのは、ちょっと恥ずかしいしストレスも感じる。お金を払ってない人たちとのやり取りは、全体的に人類や公共のために何がベストかって話になるから、特別扱いされるべきじゃないし、誰も相手を見下す権利はないからね。

全然違う状況だよ。MinIOチームは誰も無償で働いてない。MinIOはCOSS企業（商業オープンソースソフトウェア）で、基本バージョンを無料で提供して、企業の人たちがプレミアム機能にお金を払いたくなることを期待してるんだ。MinIOがクローズドソースになるのはビジネスの決断で、それ自体は悪いことじゃないよ。SeaweedFSを強くおすすめする。私はWasabiと提携する前に、長い間プロダクションで使ってた。今でも1GiB/sの超高速なコロケーションオブジェクトストレージにSeaweedFSを使ってるけど、今はWasabiが私たちの主力オブジェクトストレージだよ。

全然そんなことないよ。数年間オープンソースのストレージシステムを維持してきたけど、好きなんだ。ほんとに大好き。TidesDBっていうストレージエンジンを維持してる。背中が痛いけど、それが好きなことをやれない理由にはならないよ。

人気のオープンソースプロジェクトを作ったり維持したりする主な動機が金儲けなら、オープンソースの精神を理解してないよ。

オープンソースの開発者は、自分が無料で提供するものを「製品」と考えるのをやめるべきかもね。私は小さなオープンソースライブラリを維持してるけど、全然お金にはならないし、これからもならないだろう。人々は自由に使ったり使わなかったりできるし、私がリポジトリを維持する方法が気に入らないなら、フォークしてもいいんだ。

オープンソースプロジェクトが収益化できないと誤解している人が多いのは驚きだね。ビジネスモデルとオープンソースは直交するけど、互換性のある概念なんだ。ただ、オープンソースプロジェクトを維持する主な目的が金銭的な利益を得ることなら、インセンティブが歪んでるよ。もしそう感じるなら、他のオープンソースプロジェクトを使うのもやめた方がいいよ、支援もしない限りね。腰痛には気をつけて。

そもそも、ログ用のデータベースにオブジェクトストレージに対する非自明な依存関係が必要なのはなんで？クラウドで管理されていて、耐久性、可用性、低コストで「無限」のストレージスペースが証明されている場合、オブジェクトストレージは通常のブロックストレージよりも利点があるよ。AmazonのS3やGoogleのGCSみたいにね。自分で運用する場合、オブジェクトストレージは通常のブロックストレージに対して全く利点がないんだ。- 「無限」のストレージスペースを提供しない - 定期的に監視して、新しい物理ストレージを手動で追加する必要がある - 高い耐久性と可用性を提供しない。ネットワーク越しにストレージノード間でオブジェクトストレージの状態を調整するのが複雑だから、ローカルに接続されたブロックストレージよりも可用性が低いことが多い。 - DIYオブジェクトストレージによって、基盤となるハードウェアストレージでデータが破損したり失われたりした場合、適切に自動回復される可能性は低い。 - ローカルに接続されたブロックストレージと比べてオーバーヘッドが高く、（おそらく、半端なレプリケーションのために）コストが高くなる。 - ネットワークの遅延が高いから、ローカルストレージにアクセスする時の遅延と比べて遅くなる。遅延の違いは1000倍で、オブジェクトストレージは100ms、ローカルブロックストレージは0.1ms。 - ブロックストレージよりも設定、運用、トラブルシューティングが難しい。だから、大規模なプロダクション環境でオブジェクトストレージが必要ないログ用の他のデータベースを見てみることをおすすめするよ。例えば、VictoriaLogs。単一ノードで数百テラバイトのログにスケールできて、クラスターモードではペタバイトのログにスケールできる。どちらのモードもオープンソースで無料で使えるよ。注意：私はVictoriaLogsのコア開発者だよ。

Duolingoは無給の労働を使ってリソースを構築した。今はプレミアムにお金を取ってるよ。