皆さん、
非常に簡略化された、最小限の「ミニ」Discourseを構築することに興味がある人はいますか?これはどのディストリビューションでも簡単に構築でき(私の優先順位はFedoraとAlpineになります)、ここで議論されているチャット/ソーシャル機能の一部を実験できるものです。
皆さん、
非常に簡略化された、最小限の「ミニ」Discourseを構築することに興味がある人はいますか?これはどのディストリビューションでも簡単に構築でき(私の優先順位はFedoraとAlpineになります)、ここで議論されているチャット/ソーシャル機能の一部を実験できるものです。
私の経験では、このような技術的な理由で機能性を犠牲にするのは、しばしば悪い決断です。
DiscourseをフォークしてDockerなしで実行したいのですか?それは良い結果をもたらしません。
うーん。この記事はFlatPakに関するものですが、コンテナに関する一般的なコメントも含まれています。
Linuxデスクトップ向けアプリのデプロイは難しい。
この記事は、コンテナ化されたアプリケーションがユーザーのデスクトップでどれほど役立つかについてです。Discourseは、ブラウザと並んでラップトップでローカルに実行することを想定して作られたものではなく、チーム/コミュニティ全体がアクセスできるサーバーで実行することを想定しています。
そのため、Discourseにとってどのように関連するのか理解できません ![]()
この機能によってどのようなユースケース/シナリオが可能になるか教えてください。
フォークは必要ありませんが、最初に思いついたのは次のとおりです。Discourse on a Raspberry Pi | Blog
一方で、Discourseをテストするために小さなVPSを起動することは、それほど違いはなく、実験には大いに役立ちます。![]()
これを思いついたのは素晴らしいと思いますが、率直に言って、Discourse は、特に DigitalOcean を中心に、いくつかの場所で試すのが比較的簡単だと思います。PHP ベースのフォーラムと比較すると、いくつかのコア要件があり、それほど簡単ではありませんが、それはここでは触れる価値のない別の問題です。
しかし、Discourse のテストは、DigitalOcean で実験する意欲がある人にとっては、かなりアクセスしやすいと思います。参入障壁はありますが、Discourse のコア開発とホスティングのアプローチ(RoR、Docker など)を考えると、それを解決する良い方法を想像することはできません。
私が抱いているより大きな疑問は、これが Discourse が「最新の」コミュニティプラットフォームに関する「会話」でそれほど話題にならない根本的な理由の 1 つに触れているかどうかということです。私の感覚では答えはノーであり、おそらくより大きな要因となっている基本的な設計と機能の問題がいくつかあると思います。しかし、あなたが違うと感じているなら、私は興味があります。
問題はサイトではなく、Ubuntu以外のLinux上で構築することです。
しかし、「ミニ」Discourseをゼロから構築する場合、実験できるグリーンフィールドがあります。
小規模なLANでは、ワークステーションとサーバーの間に違いがほとんどないことがよくあります。
ホストOSをUbuntu以外のものにして、標準のDockerコンテナを使用したいということですか? それほど難しくないと思います。
この記事はLinuxデスクトップアプリに関するものであり、Discourseはデスクトップアプリではないという点が重要です。
まあ、あなたにとってはそうかもしれませんが、私はFedora Devバージョンをセットアップするのにしばらく時間を費やしましたが、Productionバージョンで行き詰まってしまいました。
しかし、私の「ミニ」提案はまさにそれ、つまりゼロから始めることです。おそらくAlpineから始めて、Dockerイメージではなくディストリビューションパッケージを作成することです。
私の主張がうまく伝わっていないことは明らかです。他の回答でも述べたように、「しかし、私の「ミニ」提案はまさにそれのためです。ゼロから始めて、おそらくAlpineから始め、Dockerイメージではなくディストリビューションパッケージを作成します。」
なるほど、そういうことでしたか。おっしゃる通り、作成、保守、サポートが困難なものになるでしょう。それを最新の状態に保つには、ほぼ専任の人員が必要になるはずです。複雑なnginxの設定(これはそれほど難しくないかもしれませんが)から画像処理の部分まで、追跡しなければならない要素が非常にたくさんあります。これらは明白な要素にすぎません。
しかし、BitnamiのDockerイメージはそれを行っており、異なるRails Webエンジンを使用しているため、可能ですが、Bitnamiと同様に、サポートはご自身で行っていただくことになります。
なぜこれが良い考えだとお考えなのでしょうか?システム要件を何らかの形で削減できるとお考えですか?
まあ、私のアイデアがそれほど支持されるとは思っていませんでしたが、以前のDiscourseが一部の状況で考慮されていないという議論を踏まえると、再評価と実験が役立つかもしれないと思いました。そのため、投稿する価値はあると思いました。しかし、そのような努力はゼロから始めることしかできないと思っていました。ただし、既存の開発者から、コアで最小限のアプリに必要なものについての意見を得ることができれば。
私は、より小さく、より軽く、よりシンプルなアプリ/パッケージが小規模な店舗に役立つ可能性があると感じています。
他の人がこのアイデアを追求する価値があると思ったというありそうもない状況では、もちろんできる限り演習を手伝います!
この問題は、これが継続的に変化していることだと思います。
DockerバージョンはRaspberry Piで動作します。「小規模な店舗」が何をターゲットにしたいのかはっきりしません。
どうすればいいのか全く見当もつきません。わかっていると思っていたのですが、ますます混乱しています。
「ゼロから始める」とも「簡略版」とも言っています。どのディストリビューションでも簡単に構築でき、同時にシンプルにしたいと考えています。そして、Linuxデスクトップへのアプリのデプロイがいかに難しいかについて論じている記事を引用していますが、それらは私にはまったく無関係なように思えます。
今のところ、最初の返信(これまでは無視されています)に従います。
そして、@pfaffman が言っていることは確かに真実です。
それでもこれです:
Discourse はデスクトップ アプリケーションではなく、サーバーにインストールされ、ブラウザ経由でリモート クライアントから接続されることを意図しています。Discourse をどのように簡略化できるかについては説明を続けていますが、なぜそうしたいのかについてのユースケースは提供されていません。
デスクトップ ディストリビューションに Discourse をインストールする目的は何ですか。現在のインストールではサポートされていないシナリオは何ですか?
Discourse は月額 5 ドルの VPS または 35 ドルの SBC で、ほとんどの国内インターネット接続で実行できます。実際にどのくらい小さくする必要があるのでしょうか?
この作業は、「会話でディスコースが言及されない」という問題に対処する方法として提案されているのでしょうか(例えば、より多くの人が試せるようにアクセスしやすくすることで)?それとも、意図はそれとは異なりますか?「ディスコースを複数のディストリビューションに簡単にセットアップできるようにする」という目的とは別に、あなたの実際の目的を完全には理解できていないと言わざるを得ません。つまり、それが達成するより大きな目標、満たされるより大きなニーズが何であるかが理解できていません。実験の可能性を高めることでしょうか?