他に何か: Haiku アプリバンドル?

TL; DR: Haiku は、アプリケーション ディレクトリ ( .app Mac の場合) および/またはアプリケーション イメージ (Linux の場合) AppImage）？ これは価値のある追加機能であり、インフラストラクチャのほとんどがすでに導入されているため、他のシステムよりも正しく実装するのが簡単だと思います。

XNUMX週間前 Haiku という思いがけない良いシステムを発見しました。 まあ、私はディレクトリとアプリケーション イメージ (Macintosh のシンプルさに触発されて) に長い間興味を持っていたので、あるアイデアが頭に浮かんだのは驚くべきことではありません...

完全に理解していただくために、私は AppImage の作成者であり、Mac の簡素化を目的とした Linux アプリケーション配布形式であり、アプリケーション作成者とエンド ユーザーに完全な制御を提供します (詳細を知りたい場合は、を参照してください)。 ウィキ и ドキュメンテーション).

Haiku 用の AppImage を作成したらどうなるでしょうか?

純粋に理論的に少し考えてみましょう。 AppImage、またはそれに似たものを俳句で？ Haiku にはすでに存在するシステムが驚くほどうまく機能するため、今すぐ何かを作成する必要はありませんが、空想の実験をしてみるのもいいでしょう。 また、このような作業が非常に難しい Linux デスクトップ環境と比較して、Haiku の洗練性も示しています (私にはそう言う権利があります。私は 10 年間デバッグに苦労してきました)。

Macintosh System 1 では、各アプリケーションは Finder で個別のファイルとして「管理」されていました。 AppImage を使用して、Linux 上で同じユーザー エクスペリエンスを再現しようとしています。

まず、AppImage とは何ですか? これは、サードパーティのアプリケーションをリリースするためのシステムです (たとえば、 アルティメイカー・キュラ）、アプリケーションをいつでも好きなようにリリースできるようにします。さまざまなディストリビューションの詳細を知ったり、ポリシーを構築したり、インフラストラクチャを構築したりする必要はなく、メンテナのサポートも必要ありません。また、ユーザーに何をインストールできるか（できないか）を指示する必要もありません彼らのコンピュータ上で。 AppImage は、形式的には Mac パッケージに似たものとして理解する必要があります。 .app ディスクイメージ内 .dmg。 主な違いは、アプリケーションはコピーされず、Haiku パッケージとほぼ同じように AppImage 内に永久に残ることです。 .hpkg マウントされており、通常の意味でインストールされることはありません。

10 年以上の存在を通じて、AppImage はある程度の魅力と人気を獲得してきました。Linus Torvalds 自身がそれを公に支持し、一般的なプロジェクト (LibreOffice、Krita、Inkscape、Scribus、ImageMagick など) がそれを主要な方法として採用しました。インストールまたはアンインストールされたユーザー アプリケーションを妨げずに、継続的または夜間のビルドを配布します。 ただし、Linux デスクトップ環境およびディストリビューションは、ほとんどの場合、従来の集中管理メンテナベースのディストリビューション モデルに固執しており、独自のエンタープライズ ビジネスやエンジニアリング プログラムを推進しています。 フラットパック (RedHat、Fedora、GNOME) および 粋な (正規、Ubuntu)。 来る とんでもなく.

どのように機能しますか

• 各 AppImage には 2 つの部分が含まれています: 小さなダブルクリック ELF (いわゆる. runtime.c)、その後にファイル システム イメージが続きます スカッシュFS.

• SquashFS ファイル システムには、アプリケーションのペイロードとその実行に必要なものがすべて含まれています。これは、よく考えれば、かなり最近のターゲット システム (Linux ディストリビューション) のデフォルト インストールの一部であるとは考えられません。 また、アプリケーション名、アイコン、MIME タイプなどのメタデータも含まれます。

• ユーザーが実行すると、ランタイムは FUSE と squashfuse を使用してファイルシステムをマウントし、マウントされた AppImage 内で何らかのエントリ ポイント (別名 AppRun) の実行を処理します。
  プロセスが完了すると、ファイル システムはアンマウントされます。

すべてが単純なようです。

そして、これらのことがすべてを複雑にします。

• これほど多様な Linux ディストリビューションがあるため、「すべての新しいターゲット システムのデフォルト インストールの一部」と呼べるものは、「正しく考えれば」ありません。 この問題を回避するには、次のようにビルドします。 除外リストを使用すると、何を AppImage にパッケージ化するか、何を他の場所に取り込む必要があるかを決定できます。 同時に、一般的にはすべてがうまく機能しているにもかかわらず、時には見逃してしまうことがあります。 このため、パッケージ作成者はすべてのターゲット システム (ディストリビューション) で AppImage をテストすることをお勧めします。
• アプリケーションのペイロードは、ファイル システム全体で再配置可能である必要があります。 残念ながら、多くのアプリケーションには、たとえば次のリソースへの絶対パスがハードコーディングされています。 /usr/share。 これは何らかの方法で修正する必要があります。 さらに、次のいずれかをエクスポートする必要があります。 LD_LIBRARY_PATH、または修正します rpath これにより、ローダーは関連ライブラリを見つけることができます。 最初の方法には欠点があり (これらは複雑な方法で克服されます)、XNUMX 番目の方法は単純に面倒です。
• ユーザーにとっての UX の最大の落とし穴は、 実行可能ビットを設定する ダウンロード後の AppImage ファイル。 信じられないかもしれませんが、これは一部の人にとっては大きな障壁になります。 実行可能ビットを設定する必要があるのは、経験豊富なユーザーにとっても面倒です。 回避策として、AppImage ファイルを監視し、その実行可能ビットを設定する小さなサービスをインストールすることを提案しました。 そのままでは機能しないため、そのままでは最適なソリューションとは言えません。 Linux ディストリビューションはこのサービスを提供していないため、ユーザーはそのままでは使用感が悪くなります。
• Linux ユーザーは、新しいアプリケーションの起動メニューにアイコンが表示されることを期待しています。 システムに「ほら、新しいアプリケーションができたので、作業しましょう」と伝えることはできません。 代わりに、XDG 仕様に従って、ファイルをコピーする必要があります。 .desktop 正しい場所へ /usr システム全体のインストールの場合、または $HOME 個人向け。 XDG 仕様に従って、特定のサイズのアイコンは、次の特定の場所に配置する必要があります。 usr または $HOME, 次に、作業環境でコマンドを実行してアイコン キャッシュを更新するか、作業環境の管理者がそれを理解し、すべてを自動的に検出することを期待します。 MIME タイプも同様です。 回避策として、同じサービスを使用することが提案されています。このサービスでは、実行可能フラグの設定に加えて、アイコンなどが存在する場合にはこれも行われます。 AppImage で、XDG に従って AppImage から適切な場所にコピーします。 削除または移動すると、サービスはすべてを消去することが期待されます。 もちろん、グラフィック ファイルの形式、サイズ、保存場所、キャッシュの更新方法など、各作業環境の動作には違いがあり、それが問題を引き起こします。 要するに、この方法は松葉杖です。
• 上記で十分でない場合は、ファイル マネージャーに AppImage アイコンがまだありません。 Linux の世界はまだ elficon の実装を決定していません (にもかかわらず、 話し合い и 実装) なので、アイコンをアプリケーションに直接埋め込むことはできません。 したがって、ファイルマネージャーのアプリケーションには独自のアイコン（AppImageなどの違いはありません）がなく、スタートメニューにのみあることがわかります。 回避策として、サムネイルを使用しています。サムネイルは、もともとデスクトップ管理者がグラフィック ファイルのサムネイル プレビュー イメージをアイコンとして表示できるように設計されたメカニズムです。 したがって、実行可能ビットを設定するサービスは「ミニチュアライザー」としても機能し、アイコンのサムネイルを作成して適切な場所に書き込みます。 /usr и $HOME。 このサービスは、AppImage が削除または移動された場合にもクリーンアップを実行します。 各デスクトップマネージャーは、アイコンを受け入れる形式、サイズ、場所など、動作が若干異なるため、これはすべて非常に面倒です。
• エラーが発生するとアプリケーションは実行時にクラッシュするだけであり (たとえば、基本システムの一部ではなく、AppImage で提供されていないライブラリがある場合)、何が起こっているのかを GUI でユーザーに正確に伝える人はいません。 私たちはこれを使用してこれを回避し始めました 通知 つまり、コマンド ラインからエラーをキャッチし、ユーザーが理解できるメッセージに変換して、デスクトップに表示する必要があります。 そしてもちろん、各デスクトップ環境ではそれらの処理方法が少し異なります。
• 現時点（2019 年 XNUMX 月 - 翻訳者注）では、ファイルが次のことをシステムに伝える簡単な方法を見つけていません。 1.png Krita を使用して開く必要があります。 2.png - GIMPを使用します。

で使用されるクロスデスクトップ仕様の保管場所 GNOME, KDE и Xfce freedesktop.org です

Haiku の作業環境に深く組み込まれた洗練されたレベルを達成することは、仕様上、不可能ではないにしても困難です。 freedesktop.org の XDG クロスデスクトップ向け、およびこれらの仕様に基づくデスクトップ マネージャーの実装。 例として、システム全体の Firefox アイコンを XNUMX つ挙げることができます。どうやら、XDG の作成者は、ユーザーが同じアプリケーションの複数のバージョンをインストールできるとは考えてもいなかったようです。

Firefox のさまざまなバージョンのアイコン

私は、システム統合の失敗を避けるために、Linux の世界が Mac OS X から何を学べるだろうかと考えていました。 時間があり、これに興味がある場合は、最初の Mac OS X エンジニアの XNUMX 人である Arnaud Gurdol の発言を必ずお読みください。

私たちは、アプリケーションのアイコンをどこか (サーバー、外部ドライブ) からコンピュータのドライブにドラッグするだけで、アプリケーションのインストールを簡単にできるようにしたいと考えました。 これを行うために、アプリケーション パッケージには、アイコン、バージョン、処理されるファイルの種類、アプリケーションを処理するためにシステムが認識する必要がある URL スキームの種類などのすべての情報が保存されます。 これには、Icon Services および Launch Services データベースの「中央ストレージ」の情報も含まれます。 パフォーマンスをサポートするために、アプリケーションはいくつかの「よく知られた」場所 (システムおよびユーザーのアプリケーション ディレクトリ、およびユーザーがアプリケーションを含むディレクトリ内の Finder に移動すると自動的にその他のディレクトリ) で「検出」されます。 実際にこれは非常にうまくいきました。

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 セッション 144 - Mac OS X: アプリケーションのパッケージ化とドキュメントの印刷。

Linux デスクトップにはこのようなインフラストラクチャは存在しないため、私たちは AppImage プロジェクトの構造上の制限を回避する回避策を探しています。

俳句が助けになるでしょうか？

そしてもう XNUMX つ、デスクトップ環境の基盤としての Linux プラットフォームは仕様が不十分になる傾向があるため、一貫したフルスタック システムでは非常に単純である多くのことが、Linux ではイライラするほど断片化され複雑になります。 私はレポート全体を、デスクトップ環境用の Linux プラットフォームに関連する問題に費やしました (知識のある開発者は、すべてが非常に長い間このままであることを確認しました)。

2018 年の Linux デスクトップ環境の問題点についての私のレポート

Linus Torvalds でさえ、断片化がワークスペースのアイデアが失敗した理由であると認めました。

俳句を見るのは嬉しいです！

Haiku はすべてを驚くほどシンプルにします

AppImage を Haiku に「移植」する単純なアプローチは、そのコンポーネント (主に runtime.c とサービス) を単純に構築しようとすることですが (これは可能な場合もあります!)、これは Haiku にあまりメリットをもたらしません。 実際、これらの問題のほとんどは俳句で解決され、概念的には健全だからです。 Haiku は、私が Linux デスクトップ環境で長い間探し求めていて、存在しないことが信じられなかった、まさにシステム インフラストラクチャのビルディング ブロックを提供します。 つまり:

信じられないかもしれませんが、これは多くの Linux ユーザーにとって克服できない問題です。 Haiku ではすべてが自動的に行われます。

• 実行可能ビットを持たない ELF ファイルは、ファイル マネージャーでダブルクリックすると自動的に実行可能ビットを取得します。
• アプリケーションには、ファイル マネージャーに表示されるアイコンなどのリソースが組み込まれている場合があります。 大量の画像をアイコンのある特別なディレクトリにコピーする必要がないため、アプリケーションを削除または移動した後に画像をクリーンアップする必要もありません。
• アプリケーションとドキュメントをリンクするためのデータベースがあり、そのためにファイルをコピーする必要はありません。
• デフォルトでは、実行可能ファイルの隣にある lib/ ディレクトリでライブラリが検索されます。
• 数多くのディストリビューションやデスクトップ環境があるわけではなく、動作するものはどこでも動作します。
• アプリケーション ディレクトリとは異なる、実行する個別のモジュールはありません。
• アプリケーションにはリソースへの絶対パスが組み込まれておらず、実行時に場所を決定するための特別な関数があります。
• 圧縮ファイル システム イメージのアイデアが導入されました。これは任意の hpkg パッケージです。 それらはすべてカーネルによってマウントされます。
• 各ファイルは、明示的に指定しない限り、そのファイルを作成したアプリケーションによって開かれます。 なんてカッコいいんだろう！

png ファイルが XNUMX つあります。 異なるアイコンは、ダブルクリックすると異なるアプリケーションによって開かれることを示していることに注意してください。 ユーザーが個々のアプリケーションを選択できる「プログラムから開く:」ドロップダウン メニューにも注目してください。 なんとシンプルなことでしょう！

Linux 上の AppImage に必要な松葉杖や回避策の多くは、Haiku では不要になるようです。Haiku は、私たちのニーズのほとんどを処理できるシンプルさと洗練性を核にしています。

結局、Haiku にはアプリ パッケージが必要なのでしょうか?

これは大きな疑問につながります。 AppImage のようなシステムを Linux よりも Haiku で作成する方が桁違いに簡単であるとしたら、それを行う価値はあるでしょうか? それとも、hpkg パッケージ システムを備えた Haiku は、そのようなアイデアを開発する必要性を事実上排除したのでしょうか? そうですね、それに答えるには、AppImages の存在の背後にある動機を調べる必要があります。

ユーザーの視点

エンドユーザーを見てみましょう。

• 管理者 (root) パスワードを要求せずにアプリケーションをインストールしたいと考えています。 Haiku には管理者の概念がありません。個人システムであるため、ユーザーが完全に制御できます。 (原則として、これはマルチプレイヤー モードで想像できると思いますが、開発者がシンプルであることを願っています)
• アプリケーションがディストリビューションに登場するのを待たずに、アプリケーションの最新かつ最高のバージョンを入手したいと考えています (ほとんどの場合、これは少なくともオペレーティング システム全体を更新しない限り、「決して」を意味します)。 Haiku では、これはフローティング リリースで「解決」されます。 これは、アプリケーションの最新かつ最高のバージョンを入手できることを意味しますが、これを行うには、システムの残りの部分を常に更新し、実質的にシステムを「動くターゲット」に変える必要があります。.
• 最新バージョンの何が壊れているかを知る方法がないため、同じアプリケーションの複数のバージョンを並べて配置したいと考えています。または、Web 開発者として、ブラウザの異なるバージョンで作業をテストする必要があるとします。 Haiku は最初の問題を解決しますが、XNUMX 番目の問題は解決しません。 更新はロールバックされますが、対象となるのはシステム全体のみであり、たとえば WebPositive や LibreOffice の複数のバージョンを同時に実行することは (私の知る限り) 不可能です。

開発者の一人は次のように書いています。

基本的な理論的根拠は次のとおりです。このユースケースは非常にまれであるため、最適化するのは意味がありません。 HaikuPorts ではこれを特別なケースとして扱うことは十分に許容できるようです。

• アプリは起動ドライブではなく、好きな場所に保存する必要があります。 ディスク容量が不足することがよくあるため、アプリケーション (ダウンロードしたすべてのバージョン) を保存するには、外部ドライブまたはネットワーク ディレクトリに接続する必要があります。 このようなドライブを接続する場合は、ダブルクリックしてアプリケーションを起動する必要があります。 Haiku は古いバージョンのパッケージを保存しますが、それらを外部ドライブに移動する方法、または後でそこからアプリケーションを起動する方法がわかりません。

開発者コメント:

技術的には、これは mount コマンドですでに可能です。 もちろん、興味のあるユーザーが十分に増え次第、このための GUI を作成する予定です。

• 自分で手動で管理できない何百万ものファイルがファイル システム内に散在する必要はありません。 アプリケーションごとに XNUMX つのファイルを簡単にダウンロード、移動、削除できるようにしたいと考えています。 Haiku では、この問題はパッケージを使用して解決されます。 .hpkg、たとえば Python で数千のファイルを XNUMX つに転送します。 しかし、たとえば Python を使用する Scribus がある場合、少なくとも XNUMX つのファイルを処理する必要があります。 そして、相互に動作するバージョンを維持するように注意する必要があります。

同じ Linux 上で複数のバージョンの AppImage を並行して実行する

アプリケーション開発者の視点

アプリケーション開発者の観点から見てみましょう。

• ユーザーエクスペリエンス全体をコントロールしたいと考えています。 アプリケーションをいつどのようにリリースするべきかをオペレーティング システムに依存したくありません。 Haiku を使用すると、開発者は独自の hpkg リポジトリを操作できますが、これはユーザーが手動で設定する必要があることを意味し、このアイデアは「あまり魅力的ではありません」となります。
• 私のウェブサイトにダウンロード ページがあり、そこで配布しています .exe Windowsの場合、 .dmg Mac用と .AppImage Linux用。 それとも、このページへのアクセスを収益化したいのですが、何か可能でしょうか? 俳句には何を入れればいいでしょうか？ ファイルだけで十分です .hpkg HaikuPorts からのみ依存関係がある
• 私のソフトウェアには他のソフトウェアの特定のバージョンが必要です。 たとえば、Krita では、少なくともパッチが Qt にプッシュバックされるまでは、パッチが適用されたバージョンの Qt、または Krita の特定のバージョンに合わせて微調整された Qt が必要であることが知られています。 アプリケーション用に独自の Qt をパッケージ化できます .hpkg, しかし、おそらくこれは歓迎されません。

通常のアプリケーションのダウンロードページ。 ここに俳句として何を投稿すればよいでしょうか?

ウィルバンドル (AppDir や .app Apple スタイルで) および/または画像 (大幅に変更された AppImage の形式で、または .dmg from Apple) アプリケーションは、Haiku デスクトップ環境への便利な追加ですか? それとも、全体像が希薄になり断片化が生じ、複雑さが増すのでしょうか? 私は引き裂かれました。一方で、俳句の美しさと洗練さは、通常、何かを行う方法はたくさんあるのではなく、XNUMX つしかないという事実に基づいています。 一方、カタログやアプリケーション スイートのインフラストラクチャの大部分はすでに導入されているため、システムは残りの数パーセントが導入されるよう要求します。

開発者によると 氏。 よちよちスプラッシュ

Linux では (カタログとアプリケーション キット - 約翻訳者）はおそらくシステム的な問題に対する技術的な解決策です。 Haiku では、システムの問題を単純に解決することを好みます。

どう思いますか？

答える前に...

待って、簡単に現実を確認しましょう。実際のところ アプリケーションディレクトリ - すでに俳句の一部になっています:

アプリケーション ディレクトリは Haiku にすでに存在しますが、ファイル マネージャーではまだサポートされていません

これらは、たとえば Macintosh Finder ほどサポートされていません。 QtCreator ディレクトリの左上隅に「QtCreator」の名前とアイコンがあり、ダブルクリックするとアプリケーションが起動したらどんなに素晴らしいでしょうか?

少し前に私はすでに 尋ねた:

すべてのアプリ ストアと配布リポジトリがアプリとその依存関係を忘れてしまった今でも、XNUMX 年前のアプリを実行できると確信していますか? 将来的にも現在の仕事に就くことができる自信がありますか?

Haiku からの答えはすでにありますか、それともカタログやアプリケーション バンドルがここで役に立ちますか? できると思います。

氏によれば、 よちよちスプラッシュ:

はい、私たちは質問に対する答えを持っています。私たちは、誰かがファイル形式を正しい方法で読み取ることができるか、5 対 XNUMX の機能を提供できるようになるまで、必要な限りこれらのアプリケーションをサポートするだけです。 Haiku で BeOS RXNUMX アプリをサポートするという私たちの取り組みがその証拠です...

それは確かです！

俳句はどのような行動を取るべきでしょうか?

hpkg、ディレクトリ、アプリケーション イメージが平和的に共存している様子が想像できます。

• システムソフトウェアの用途 .hpkg
• 最も頻繁に使用されるソフトウェア (特に、ローリング リリースをスケジュールする必要があるソフトウェア) の場合は、次を使用します。 .hpkg （全体の約80％）
• 一部は経由でインストールされます .hpkg、アプリケーションはアプリケーション ディレクトリ インフラストラクチャ (QtCreator など) に移行することで恩恵を受けます。それらは次のように配布されます。 .hpkg、 従来通り。

氏。 ワドルスプラッシュはこう書いています。

アプリケーションを表示するだけであれば、 /system/apps代わりに、Deskbar のディレクトリをユーザーが管理しやすくする必要があります。 /system/apps (MacOS とは異なり) ユーザーが定期的に開いたり表示したりすることを目的としたものではありません。 このような状況では、Haiku には異なるパラダイムがありますが、このオプションは理論的には許容されます。

• Haiku は、アプリケーション イメージを実行するためのインフラストラクチャ、ソフトウェアの夜間の継続ビルドおよびテスト ビルドに加えて、ユーザーが「時間内にフリーズ」したい場合、プライベートおよび社内ソフトウェア、およびその他の特別な使用例 (約 20%) のためのインフラストラクチャを受け取ります。全部の）。 これらのイメージには、アプリケーションを実行するために必要なファイルが含まれています .hpkg、システムによってマウントされ、アプリケーションの完了後にアンマウントされます。 (おそらくファイルマネージャーがファイルを置くことができます .hpkg アプリケーションをネットワーク ディレクトリや外部ドライブにドラッグするときなど、自動的に、またはユーザーの要求に応じて、アプリケーション イメージに取り込まれます。 それはただの歌です！ あるいは、詩、俳句です。) 一方、ユーザーは、画像の内容をファイルの形式でインストールしたい場合があります。.hpkg、その後、HaikuDepot を通じてインストールされた場合と同じ方法で更新および処理されます...ブレインストーミングが必要です)。

氏からの引用。 よちよちスプラッシュ:

外部ドライブまたはネットワーク ディレクトリからアプリケーションを実行すると、役立つ可能性があります。 そして、pkgman 用にさらに多くの「ゾーン」を構成する機能を追加することは、間違いなく素晴らしい機能です。

このようなシステムでは、hpkg、ディレクトリ、およびアプリケーション イメージが利用されます。 個々でも優れていますが、一緒になれば無敵になります。

まとめ

Haiku には、PC にシンプルで洗練されたユーザー エクスペリエンスを提供するフレームワークがあり、Linux PC に通常提供されるものをはるかに超えています。 パッケージシステム .hpkg はその一例ですが、システムの残りの部分も洗練されています。 ただし、Haiku は適切なディレクトリとアプリケーション イメージのサポートから恩恵を受けるでしょう。 これを行う最善の方法は、私よりも俳句、その哲学、構造に詳しい人々と議論する価値があります。 結局、Haiku を使い始めて 10 週間ちょっとです。 それにもかかわらず、私は、Haiku のデザイナー、開発者、建築家がこの新鮮な視点から恩恵を受けると信じています。 せめて、彼らの「スパーリングパートナー」になれたら嬉しいです。 私は Linux アプリケーション カタログとバンドルに関して XNUMX 年以上の実践経験があり、Haiku での用途を見つけたいと考えています。これらはまさに最適であると考えています。 私が提案した潜在的な解決策が、私が説明した問題に対する唯一の正しい解決策というわけでは決してありません。Haiku チームが他のより洗練された解決策を見つけることにしたのであれば、私はそれに大賛成です。 基本的にはシステムをどう作るかというアイデアはもう考えています hpkg 仕組みを変えることなく、さらに驚くべきものになります。 Haiku チームは、パッケージ管理システムを実装する際に、アプリケーション バンドルについて長い間考えていたことがわかりましたが、残念ながら (私はそう思います)、その考えは「時代遅れ」になってしまいました。 もしかしたら復活させる時期が来たのかも？

あなたも試してみてください！ 結局のところ、Haiku プロジェクトは、DVD または USB から起動するためのイメージを提供します。 日々.
質問がありますか? ロシア語圏へご招待します 電報チャンネル.

エラーの概要: C および C++ で自分の足を撃つ方法。 Haiku OS レシピ集

から 作者 翻訳: これは俳句に関するシリーズの XNUMX 番目で最後の記事です。

記事一覧： 最初の 2番目 Третья 4番目 第5 第六 XNUMX番目

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

hpkg システムを Linux に移植することに意味はありますか?

• はい

• ノー

• すでに実装されているのでコメントに書きます

20 人のユーザーが投票しました。 5名のユーザーが棄権した。

出所： habr.com