Linux向けアプリ開発

 (makealinux.app)
1 ポイント 投稿者 GN⁺ 2023-12-11 | 1件のコメント | WhatsAppで共有
  • Linuxデスクトップ・モバイルには新しいソフトウェアへの需要があるが、アプリストアやリポジトリのアプリケーション数が不足しているため、新しいディストリビューションよりもアプリ開発に注力しようというメッセージ
  • 個人の必要から始まったアプリでも、公開開発を経れば学習資料やコミュニティとなり、Linuxエコシステムの拡大につながる可能性がある
  • 数百ものディストリビューションという多様性は負担でもあるが、文書化されたパッケージング・配布システムを活用すれば、さまざまな環境のユーザーにアプリを届けられる
  • GNOME、KDE Frameworks、elementary OS、Electron、Ubuntu Touchは、Gtk、Qt、Vala、JavaScript・HTML・CSS、QMLなど、それぞれ異なる開発パスを提供する
  • AppCenter、AppImage、Flatpak、Open Build Service、Snapcraftといった配布手段があり、有料アプリ・サービスや投げ銭型アプリストアを通じた収益化の可能性もある

Linuxにさらに多くのアプリが必要な理由

  • デスクトップとモバイルのLinuxユーザーには新しいソフトウェアへの需要がある
  • Linuxのアプリストアやリポジトリは、独占的なプラットフォームに比べてアプリケーションが不足している
  • 技術愛好家には、新しいLinuxディストリビューションをこれ以上作るよりも、Linuxユーザー向けの新しいアプリケーションに情熱と創造性を注ぐよう促す声がある
  • 核心的なメッセージは「Linuxディストリビューションを作るのはやめて、アプリケーションを作れ」ということ

アプリ開発がエコシステムにもたらす効果

  • 個人的に必要なアプリのアイデアがあるなら、同じような必要を持つほかのユーザーもいるかもしれない
  • 公開でアプリケーションを作れば、より新しい開発者も学び、始められるようになり、次世代のLinuxアプリ開発の助けになる
  • アプリケーション開発は創造的な作業であり、プロジェクトを完成させたときの達成感も報酬になり得る
  • アプリ開発はコミュニティ形成を助け、Linuxコミュニティは開発者が成功するのを支援したいと考えることが多い
  • ソフトウェア開発スキルは需要のある技術であり、無料の学習リソースも多い
  • Linuxユーザーは開発者を金銭的に支援しないという考えは誤解であり、人気の有料アプリやサービスによって新たな収益源を作れる

多様なLinuxディストリビューションを対象にする

  • Linuxはほかのプラットフォームと違って非常に多様な対象であり、数百のディストリビューションが存在する
  • アプリケーションは一度公開されれば、一般に複数の環境で動作できる
  • 文書化されたパッケージング・配布システムがあり、開発者はユーザーにアプリを届けられる
  • 各開発フレームワークとLinuxディストリビューションには、ユーザーへアプリを届けるための推奨ルートがある
  • アプリを共有する準備ができたら、開発ドキュメントで推奨パッケージングガイドを確認できる

開発を始められるルート

  • GNOME

    • GNOMEプロジェクトはGNOME Shellデスクトップを作っており、GjsとGtkベースの開発を支援する
    • GtkではPython、C、C++、Rust、JavaScriptなど一般的な言語を使える
    • GNOME Developer Center

  • KDE Frameworks

    • KDEはPlasmaデスクトップとアプリケーション制作ツール・フレームワークを提供する
    • KDE Frameworksは多様なデスクトップアプリケーション開発に使われてきた
    • 主にQtツールキットとC++プログラミング言語を活用する
    • KDE Frameworks Getting Started

  • elementary OS

    • elementary OSはWindowsやmacOSの代替となる、高速でオープンかつプライバシーを尊重するオペレーティングシステムを目指している
    • 開発者たちはアプリ開発のためのデスクトップとエコシステムを構築している
    • 開発者ガイドはValaとGtkを推奨している
    • elementary OS Developer Guide

  • Electron

    • ElectronはJavaScript、HTML、CSSでクロスプラットフォームのデスクトップアプリを作れるようにする
    • 開発者は膨大なnodeモジュールライブラリを活用し、Web技術ベースのアプリを作れる
    • Electron Documentation

  • Ubuntu Touch

    • Ubuntu Touchは、スマートフォン、タブレット、PCなど多様なデバイスで動作するよう設計されたオープンソースのオペレーティングシステム
    • ネイティブのUbuntu TouchアプリはQMLまたはHTMLで作り、動作はJavaScript、C++、Python、Rust、Goで定義する
    • Ubuntu Touch Documentation

Linuxアプリエコシステムに関する開発者の意見

  • GNOME FoundationのNeil McGovernは、Linuxを大衆に広めるには繁栄するアプリエコシステムが必要で、誰もがLinux向け開発をできるべきだとし、それによってオープンデスクトップという目標に近づくと見ている
  • KDE e.V.のAleix Polは、Linuxを望まれるオペレーティングシステムにするには優れたアプリが必要で、開発ツールを通じて想像したものを作れると語る
  • elementary創設者のDaniel Foréは、デスクトップLinuxで優れたアプリを作るだけでなく、プラットフォームAPIを作り、デスクトップの方向性に影響を与える機会があると見ている
  • UBports Foundation理事会メンバーのJan Sprinzは、Linuxアプリ開発は閉じたエコシステムとはまったく異なり、技術的に競争していても、より大きなビジョンのために協力すると語る

アプリを共有し配布する方法

  • AppCenter

    • 独立開発者向けの公開型pay-what-you-wantアプリストア兼ビルドサービス
    • AppCenter DashboardはGitHubと統合され、リリースと課題追跡を支援する
    • AppCenter Dashboard

  • AppImage

    • デスクトップLinuxアプリケーションをAppImage形式で配布し、一般的なLinuxディストリビューションのユーザーに届けられる
    • 一度パッケージングすればどこでも実行できる方式を掲げる
    • AppImage Packaging Guide

  • Flatpak

    • Linuxデスクトップアプリケーション配布のためのフレームワーク
    • Linuxデスクトップに長く携わってきた開発者たちが作り、独立したオープンソースプロジェクトとして運営されている
    • Flatpak Documentation

  • Open Build Service

    • openSUSE Build ServiceはOpen Build Serviceの公開インスタンス
    • openSUSEディストリビューションの開発とともに、Fedora、Debian、Ubuntu、SUSE Linux Enterpriseなど複数のディストリビューション向けパッケージを同じソースから提供するために使われている
    • openSUSE Build Service Help

  • Snapcraft

    • Snapcraftはsnapを作成するためのコマンドラインツール
    • snapはデスクトップ、クラウド、IoT向けのアプリパッケージで、インストールが容易で、安全かつクロスプラットフォームで、依存関係が不要だと紹介されている
    • Snapcraft Documentation

関連記事

1件のコメント

 
GN⁺ 2023-12-11
Hacker Newsの意見

  • LinuxにはABIが安定した中核フレームワークのまとまりがまだ存在しないという点で、前提が間違っていると思う
    競合プラットフォームには、CoreImage、CoreAudio、CodeML、SceneKit、AppKitのような基本フレームワークがはるかに多く、壊れる頻度も低い
    Linuxのsnapやflatpakも興味深くはあるが、アプリに使わせるフレームワークやプログラミング言語自体で解決する代わりに、インフラやパッケージ管理で迂回しているやり方に近い

    • Linux愛好家コミュニティは、こうした方向性に積極的に反対する傾向がある。すべてをモジュール式にして、特定のアプリケーション向けに組み合わせたいからだ
      Linuxにも事実上の標準的なまとまりはあるが、変化したり廃止されたりするので安定性はやや低い。それでも見た目ほど悪くはなく、Snapsでいくつかの問題は緩和できる
      ただし、人々がそうした標準のないディストリビューションを選ぶなら、あらゆる奇妙な設定をサポートしない時点で潜在ユーザーの半分を失うことになる
    • 今のLinuxで最も安定したターゲットは、WineやProton経由のWin32だとどこかで読んだことがある
    • その中核はGNOMEやKDEのフレームワークとFreeDesktop標準だったし、少なくとも20年前の計画ではそうだった
      しかし本文でも述べられているように、大半は相変わらずディストリビューション作りに集中しており、当然ながら無数の特殊なディストリビューションすべてに追随できる単一スタックは生まれにくい
      結局GoogleはLinuxカーネルを持ってきて、その上にJavaとJavaScriptベースの中核フレームワークを2組載せ、一般消費者向けにはそれらのLinuxディストリビューションが勝者になった
    • 主な責任はglibc開発者にあると思う。バージョン名の濫用や、最近の新しいELF再配置タイプの追加のようなことが、複数ディストリビューションにまたがるゲームのバイナリ配布を苦痛なものにしている
      通常、ゲーム開発者は最新の主要ディストリビューションでビルドしてSteamに載せるが、そのディストリビューションにglibc 2.36が入っていると、バイナリにもglibc 2.36以上を要求するバージョン名が付いてしまうことが多い
      結局、binutils gasのsymverディレクティブを使って、十分に古いglibcと互換性のあるバージョン名に強制的に合わせる必要がある。個人的には5年、あるいは7〜8年くらいが妥当な基準だと思う: https://sourceware.org/glibc/wiki/Glibc%20Timeline
      普通のゲーム開発者はこうした問題をほとんど知らず、知っていたとしても市場1%のためにそこまで苦しい作業はしないだろう。libgccと、C++ならlibstdc++も静的リンクしないと、そのABI問題は避けられない
      それでもGodotエンジンは、こうした点に配慮したビルドコンテナを提供しているし、Unityもそのあたりはきれいに見える。UT5.xについてはよく分からない
      一方で、Electronベースのゲームのように準備不足のエンジンもある。Enlightenment、Qt、純粋なX11、Waylandといったディストリビューション向けに適切なGTK+バージョンがなければ動かないことがある
      幅広いELF/Linuxディストリビューションを対象に、Google Blinkエンジン全体をきちんとパッケージ化してバイナリ配布するのも容易ではない
      ELF/Linuxは全般的なABI破損のためにバイナリ専用配布に敵対的で、特にSDKと中核ライブラリで深刻だ
      ゲームのバイナリですらこれほど難しいなら、アプリはなおさら厳しいはずだ。開発者が結局「もういい、Microsoft SUSE GNU/Linuxだけ入れて使ってくれ、それ以外はサポートしない」と言い出す未来が見える
    • macOSが提供するレベルのフレームワークの幅広さがLinuxにもあれば、個人プロジェクトでもとっくにLinux向けに作っていただろう
      サポート期間や、どのフォークが良いか、他のサードパーティライブラリとうまく合うかといったことをほとんど気にせず、すぐ取り出して使えるツールが多いのは素晴らしい。摩擦を大きく減らして、とにかく作り始められる
      KDEのQtエコシステムとGNOME/GTK系が最も近いが、まだそのレベルではない

  • パッケージ名で dev や version をいつ付けるべきか、末尾に付く任意の 1 や 0 が何を意味するのかというパターンを知らないのかもしれないが、一貫したパッケージ命名規則を持つ最初の Linux ディストリビューションが支持を集めそうだと思う
    libgnutls-dev
    libgtk-3-0
    libwayland-server0
    libxcb1
    libx11-6
    libffi-dev
    libncurses5-dev

    • -dev はヘッダーを含むので、かなり分かりやすい部類だと思う
      数字は同時に複数バージョンをインストールできる場合のバージョン表記だ。もっとも、xcb1 のようにライブラリ名の一部である場合は例外かもしれない
      たとえばある時点では libgtk-3-0 と libgtk-2-$something を同時にインストールできたのだろう。後で libgtk-2 を削除しても、既存チュートリアルの libgtk-3-0 参照が壊れないように、その名前を残した可能性が高い
      libwayland-server0 の末尾の 0 は自分にもよく分からない。/var/lib に同じライブラリが複数の .$number 接尾辞を付けているのは見るが、それが正確に何を解決しているのかは掘ったことがない
    • バイナリとソースを分けるのは Debian の慣習だ
      ライブラリを使うだけなら -dev ではないパッケージで十分で、そのライブラリ向けに開発するならヘッダーを入れる -dev も必要になる
      末尾の 1 や 0 は特別なものではなく、単にパッケージ名やバージョンの一部にすぎない
    • Arch とその派生ディストリビューションには、こういうものはたいていない
      ただし -dev は、そのライブラリを対象に開発するときだけ必要なものを意味する
      数字はメジャーバージョン番号、つまり互換性番号だ。おかげで、異なるパッケージが依存する複数のメジャーバージョンを衝突なく簡単に共存させられる
    • プログラムをビルドするなら -dev パッケージをインストールすればよい
      番号付きの -dev パッケージは、普通は直接気にする必要がなく、必要なら番号なしのパッケージが橋渡しする形であるべきだ
      ビルド中には、どの番号接尾辞、つまり ABI バージョン が使われたかが記録される。これは .so.N 接尾辞と一致しているはずだが、直接そうやって探すわけではない
      この仕組みによって、互換性のないライブラリのコピーを複数インストールし、適切なものを使えるようにできる。ディストリビューションは通常、大きなリリースごとに古いものを整理する
      インストール時には、ビルド時に記録された依存関係が自動的に使われるようになっているはずだ
    • GoboLinux があり、自分の観点ではあらゆる問題を解決しつつ Nix ほど複雑でもない。だが誰も気に留めなかった

  • これは Linux プラットフォーム全体を悩ませる最大の問題の一つだ。よく長所として語られるが、自分はそうは思わない
    開発者たちは選択肢が多いことを Linux の強みとして持ち上げるが、多くのユーザーにとっては 選択のパラドックス になり、もともと使っていたプラットフォームへ戻る原因になる
    macOS や Windows では選択肢は少ないが、可能な選択肢はずっと磨かれていて、断片化も少ない
    たとえばタイル型ウィンドウマネージャーがいくつ必要なのだろうか。最高のタイル型ウィンドウマネージャーを選んで、より良いドックやアプレットを作れないのだろうか。タイル型ウィンドウマネージャーのパラダイムに統合されるアプリやランチャーはどうだろうか
    その代わりに、タイル型ウィンドウマネージャーが10種類と、その上に載った中途半端な回避策ばかりが残ることが多い

    • 人はすべての選択肢を網羅的に分析して選ぶわけではない。少数の候補を見て、人気や手の届きやすさに応じて一つ選んで使うものだ
      成功したエコシステムは、目立つ選択肢を選んでも十分に良い結果になるようにしてくれる
      Linux ディストリビューションが増えることは、ほとんどの場合、意味のある適合性を下げない小さな違いにすぎず、ディストリビューション選びに特に苦労しなかったごく少数だけが問題視している
      その一方で Wayland のような話では、配管やハードウェアが急に重要になり、使い物になる組み合わせを選ぶには内部構造をある程度知っておく必要があるため、実際の問題になる
      Mac や Windows を Linux と比較するのもあまり意味がない。消費者の 95% にとって、OS はコンピューターの固定的な性質か機能であって、別個の製品ではない
      全体のパッケージが合っていれば、その OS が入ったコンピューターを買うことはあっても、自分の Windows や Mac の機器に別途インストールしようとはしない
      十分な技術知識を持つ人なら、Ubuntu 派生が3つ増え、Arch 派生が2つ増えても、そこまで混乱しないだろう
    • タイル型ウィンドウマネージャーを作るのは楽しい。協業でソフトウェアを作ることは、何かの成果物を得るための手段であるだけでなく、それ自体が目的でもある
      オープンソース開発者であるということは、目標も手段も自分で決められるという意味であり、商用ソフトウェア開発ではそうした自由がないことが多い
      粗い部分は出てくるが、IKEA 効果 が働いて結局は気に入るようになる
    • これはディストリビューションが解決すべき領域だ。選択肢が多いことを望まない人は、多くの選択を代わりに決めてくれるディストリビューションを使えばよく、エコシステム全体から選択肢をなくせと迫る必要はない
      みなが同じソフトウェアを使えば、攻撃により弱い 単一栽培エコシステム になる。Windows がウイルスの標的になりやすかったのも、対象が大きく一貫していたからだ
      ある一般ユーザーの Windows マシンを突破できれば、残りも似たように突破できた。Linux を標的にするなら、はるかに難しい
      そのうえ自由ソフトウェアなのだ。誰かに金を払ってやらせるのでなければ、ほとんどはボランティア活動であり、他人のボランティア時間をどこに使えとこちらが指図することはできない
      これだけ多くのグループがあるのに誰も参加したがらないなら、支配的な社会構造も見直すべきだ。プロジェクト外の行動まで罰せられるようにする行動規範をまずやめてみるのが出発点かもしれない
    • タイル型ウィンドウマネージャーより、ランチャーやドックのほうが多いと思う
      そして何をさらに改善すべきなのかもよく分からない。Ulauncher や Albert のようなものは、他のプラットフォームで可能なものよりずっと強力で、UI をどうすればさらに良くできるのかも分からない
    • 人々が作りたいだけの数のタイル型ウィンドウマネージャーがあればそれでよい

  • ソフトウェアが増えるのは良いこと。ただ、最初から新しく作る前に、すでにあるものに貢献したり、放置されていたり最新のコンパイラやハードウェアでビルド・実行できるよう手を入れる必要があるプロジェクトを選ぶのはどうかと思う
    復活させる価値のある休眠・死亡プロジェクトのデータベースがどこかにあるのかも気になる

    • 既存の何かが、自分の目標とするやり方で作られていない可能性はある
      また別のプロジェクトは、一緒にやっていくのが難しい人が率いていたり、提案やパッチを受け入れないコミュニティかもしれない
      社会的な手続きや行き詰まりは、貢献する動機を失わせかねない。誰もが角のない楽観的なチームプレイヤーになれるわけではない
      自分としては、最初から新しく始めるほうがよい。すべての変数をコントロールでき、既存の社会的・技術的インフラに触れる必要がなく、自分のアイデアが良いと誰かを説得する必要もなく、コードよりも議論や討論に時間を使いたくないからだ
      ソロ開発のほうが経験として良い。政治や社会的手続きに縛られないからであり、チームプレイヤーになろうとした経験は自分に苦痛しか与えなかった
    • ほとんどの分野には低水準の試みが多すぎて、その労力を上位いくつかのプロジェクトに集めれば、素晴らしいアプリがいくつか生まれるはずだ
      協業は気が重く大変に見えるかもしれないが、結局は結果を出すことであり、放棄されるプロジェクトに費やす時間より有意義に使える時間だ
    • 主要な Linux パッケージリポジトリの中で、よく使われているがメンテナンスされていない、あるいは機能が未完成なアプリを検索できる統計を集めている場所があるのか気になる

  • 複数のOSで互換性のあるアプリを作るためのツールが不足しているという不満は多いが、同意しない。Electron 以外の解決策もある
    Telegram は Qt を使って、3つのOSすべてに高性能なネイティブアプリを配布している
    Flutter は3つのOSとモバイル向けにネイティブコードへコンパイルされる
    Kirigami は QtQuick フレームワークで、モバイルとデスクトップの両方を対象に動作するアプリを作れるようにしてくれる
    ただアプリを作ればいい。これを Linux 非難の言い訳にする理由はない

    • Flutter はプラットフォームごとに少しずつ挙動が異なり、すべてのプラットフォームで微妙に良くない体験を与える。Kirigami や Qt Quick も、現実的に可能な選択肢とは見なしにくい
      Windows、macOS、モバイルではコミュニティや本格的なプロジェクトがほとんどない。KDE をけなしたいわけではないが、現実はそうだ
      Qt Quick のライセンスも iOS では扱いが簡単ではなく、商用に進むと非常に高額だ
      一方 Electron には大企業が投資して非常によく磨かれたプロダクション級ツールを提供しており、巨大なコミュニティとライブラリエコシステムがあり、Dart のような馴染みの薄い言語でもない
      Telegram は本当に一段上の努力をしている。クライアントは素晴らしい
    • Qt ベースの Telegram アプリも macOS でうまく動くが、ほとんどの Apple ユーザーは macOS と iOS 向けのSwift/Cocoa クライアントを選ぶ[0]
      [0]: https://github.com/overtake/TelegramSwift

  • 問題は、OSSソフトウェアが市場と競争しようとする試み自体をあまりしていないことにある。
    OSSソフトウェアを使う人たちは、UXが足りないだろうと当然のように受け入れており、実際そういう場合も多い。
    一般的なプロプライエタリソフトウェアは、ユーザーが金を払わないリスクがあるため、最終ユーザー体験を良くするよう適応するが、OSSには普通そうしたリスクがない。オープンソースも最終ユーザーから来るリスクにさらされる必要がある。
    Notes[1]でそれを変えようとしたが、広告だけで食べていくのは難しいと感じた。Kanbanのようなプレミアム機能の課金も入れてみたが、アプリが完全なFOSSなので、誰でもソースから簡単にコンパイルできる。
    次のアプリ[2]は、リリース前は非公開ソースで運用するつもりだ。自分の努力が報われないリスクは負えない。
    お金を受け取れれば、LinuxでUX重視のアプリにもっと投資できるので、Linuxコミュニティにも役立つと信じている。一部はオープンソースとして公開するかもしれないし、遠い将来には全部を公開するかもしれない。
    [1] https://github.com/nuttyartist/notes
    [2] https://www.get-plume.com

    • Linuxユーザーと自由を大切にする人たちの交わる範囲は大きい。多くの人にとって、非オープンソースのノートアプリはベンダーロックインとプライバシーの問題のため、最初から選択肢ではない。
      だから、プログラムをオープンソースにしないなら、オープンソースにして一部が金を払わないリスクを受け入れるよりも、もっと多くを失う可能性が高い。
      プロプライエタリソフトウェアを使おうとする人より、金を払ってでもオープンソースを使おうとする人のほうがずっと多いと思う。
      オープンソースだからといって、全員にコードを配布しなければならないわけではなく、金を取るなら有料ユーザーにだけソースコードを渡すこともできる。ただし、彼らは改変と再配布の権利を持つことになる。
      オープンソースに関心がないなら、NotionやEvernoteを使えばよい。最新世代のオープンソースのノートアプリを探しているなら、Logseqを勧める。
    • 正しい判断をしているように思う。オープンソースで生計レベルの金を稼ぐのは極めて難しく、商用ソフトウェアで食べている人より規模が何桁も小さい。
    • もどかしさは理解できるが、反例もある。けなす意図はない。
      第一に、NotesはStandard Notesとかなり似て見える。コピーレフトのOSSを使ってNotesを作ったのなら、その中に含まれる他のプログラマたちの仕事にロイヤルティを払っていない限り、不満を言うのは難しいと思う。
      第二に、私はおそらく非典型的なユーザーだ。Linuxを20年以上使っているが、BashスクリプトやPerlのワンライナーもまともに書けない。
      それでも、コーディングができず、他人の仕事とそれがもたらす自由に感謝しているからこそ、他のプラットフォームで個人が普通使うよりずっと多くの金をソフトウェアに使ってきた。
      KaisenとDebian、FSFのコアユーティリティとEmacs、KDE、MozillaのFirefox、Betterbird、Syncthing、LaGrange、Joplin、ClipTo、SoulSeekやenvs.netのようなサービスなど、いろいろなところを支援している。
      毎年払うものもあれば、毎月のものもあり、一度きりのものもある。
      Standard Notesが最初に出たときも7年契約を支払ったが、2か月ほど使って満足できずやめた。Alacrittyのようによく使っているのに寄付の方法を見つけられないものもあり、そういうケースは最小限にしようとしている。
    • 個人的には、KDEはmacOSやWindowsよりはるかに先を行っていると思う。
      実際、macOSは人気プラットフォームの中で最悪のウィンドウマネージャの一つだと感じる。きれいで使いやすくはあるが、基本を超えて何かしようとすると、自然には見つけられない魔法の呪文が必要になる。
      もちろん好みは人それぞれだ。
    • いくつか思うところがある。この分野はかなり追っているのに、そのアプリは聞いたことがなく、競争は極めて激しい。
      プレミアム価格を見ようとクリックしたが、年額ベースでは妥当でも月額サブスクリプションの選択肢しか見えず、それは厳しいと感じた。
      こういうアプリでは、プレミアム版の支払いより寄付をする可能性のほうが高い。Obsidianではそのモデルがうまく機能していた。
      機能への早期アクセスには大きな価値はないと思うが、作業を支援するために金を払った人は多い。
      また、閉じたコア製品の周辺に大きなオープンソースのエコシステムがある構造は、人々が金を払う理由を作ってくれると思う。

  • 記事にいくつか例があればよかったと思う。
    ディストリビューションを作っているが、実際にはアプリケーションを作るべき人はあまり思い浮かばない。無理に挙げるならLinuxCNCくらいだろうか。ただ、それは特定のカーネル要件があるので、カスタムディストリビューションのほうが合っているかもしれない。

    • デスクトップ環境は、実際には1、2回のクリックやコマンドで簡単にインストールできるアプリケーションだ。
      派生の派生ディストリビューションが、単に別のデスクトップ環境を載せて配布されるのは、あまり理解できない。

  • 「Linuxディストリビューションを作るのはやめて、アプリケーションを作れ」というより、何をすべきで何をすべきでないかを指図しようとする人たちの話を聞くのをやめたほうがいいと思う。

    • 私もその口調は気に障った。
      それでも、メッセージと情報そのものは良い。
      個人的には、「Linuxユーザーはこれ以上ディストリビューションを望んでいない。ソフトウェアを望んでいる」と言っただろう。少なくとも私はそうだ。
    • 何をすべきで何をすべきでないかを指図しようとする人たちの話を聞くのをやめろと言う人たちの話も、やめて聞くべきだ。すべてが相対的というわけではなく、良い選択と悪い選択はある。

  • 最近 Mac から Linux に移行した。性能の良い中古機材を普段使いのマシンとして使うためだった
    以前にも複数のマシンに Linux を入れたことはあったが、今回は単なる趣味ではない
    Ubuntu は自分のハードウェアや周辺機器をよくサポートしているが、アプリストアは未完成で、無理やり押し込んだような感じがある。それでも、ほとんどすべてが期待どおりに動く
    Mint、Debian、Arch も試してみたいが、Ubuntu を前提に書かれたソフトウェアが多そうなので慎重になっている

    • Linux Mint は Ubuntu ベースなので、Ubuntu パッケージを問題なく使える。実質的に、より良い Ubuntu と見なしてもいい
      Debian ベースの Mint バージョンもあるが、それは Ubuntu 側への致命的な依存を避けるための安全策に近い
      最近では、少し変わったディストリビューションを使っていても大きな問題にはなりにくい。標準のパッケージマネージャーが欲しいアプリを提供していなければ、AppImage、Flatpak、Snap を使えるからだ
    • Ubuntu 向けに書かれたもののうち、Arch や大半の最新ディストリビューションで動かないようなものはほとんどない
      Arch を使うときは、人々が Ubuntu を基準にしている前提に慣れる必要はあったが、たいていは設定ファイルをパッチしたり環境変数を設定したりする程度だった
      そういうのは有用で、ほかの場面にも持ち運べるスキルだ
    • Fedora もぜひ一度は使ってみるといい
      もっと早く試しておけばよかったと思う

  • なぜわざわざそんなことをするのかと思う。より難しくなるし、Linux ユーザーは金を払う価値がないものには金を払わない

    • 世の中には、良いフリーソフトウェアがもっと増えたほうが有益だからだ