普遍的にクロスプラットフォームのC ++コードを作成し、すべてのOS向けに製品を出荷するのはそれほど簡単ではないことを説明するにはどうすればよいですか?


15

私たちの会社はWindows向けにさまざまなデスクトップ製品を出荷しており、多くのLinuxユーザーはフォーラムで何年も前にLinux向けの製品のバージョンを書いておくべきであると不満を述べています。

  • 私たちは貪欲な会社です
  • 私たちの技術スペシャリストはすべて、資格のない馬鹿です

私たちの平均的な製品は、300万行のC ++コードのようなものです。

私と私の同僚の分析は次のとおりです。

  • クロスプラットフォームのC ++コードを書くことはそれほど簡単ではありません
  • 多くのディストリビューションパッケージを準備して、Linuxのすべての普及バージョン用に維持するには時間がかかります
  • 私たちの推定では、Linux市場は全ユーザーの5〜15%程度であり、それらのユーザーはおそらく私たちの努力にお金を払いたくないでしょう。

これが提起されたときの応答は、私たちが貪欲な不十分なバカだということです。

クロスプラットフォームコードを記述し、多数の配布パッケージを維持するのに多大な労力がかかるという事実の評価はどれほど合理的ですか?疑いの影を越えて、正確にどれだけの労力がかかるかを示す実際のストーリーで、簡単で詳細な分析をどこで見つけることができますか?


3
なぜWINEをターゲットにして、完了を宣言しないのですか?
btilly

1
@btilly:すでにWINEで動作しますが、WINEは正しくありません
sharptooth

2
多くの場合、WINEは苦痛であり、アプリケーションの種類にもよりますが、通常はネイティブアプリほどパフォーマンスが良くないか、きれいではありません。しかし、Linuxである広大な世界全体できれいに見えるネイティブLinuxアプリを作成することは、それ自体がタスクです。
マシューシャーリー

4
「Linuxユーザーは支払いたくない」というのは間違った仮定だと思います。エンドユーザーにとっては、おそらく著作権に関心があり、他の多くのユーザーが行っているように、Windowsの海賊版を単純に使用しないでください。
-ziggystar

3
言いたい奴には言わせとけ。フォーラムの泣き言に対する唯一の応答は、(a)それらを無視するか、(b)それらに近づいて顔を真っ直ぐに振るだけです。(a)通常、はるかに実用的です。
トムアンダーソン

回答:


8

大部分の人々は従業員であり、したがって彼らが利益を上げることを気にする必要がある世界に住んでいないことに留意してください。彼らは職場に現れ、自分のことをし、家に帰りますが、プロセス全体がどのように機能するかについては本当に考えていません。そして、非常に賢い一方で、多くの技術者はビジネスについて積極的に無知であり、しばしば教義によって盲目にされます。

もちろん、その規模のXプラットフォームソフトウェアを作成するのは簡単なことではありません。特に、何十人もの開発者と何百万人ものユーザーがいる会社を退社するときです。そして、その技術的な制限だけではありません。そのすべてがコスト対利益です。はい、来年はアプリをLinuxにポーティングするのに費やすことができます(お気付きのように、既にWINEで実行可能です)。もちろん、その年の開発時間は無料ではありません。そして最後に、おそらくあなたをネットします追加の5〜15%のユーザー(見積もりに基づく)。または、同じお金/努力を払って、それを新しいバージョンとしてWindows開発に集中させるか、すべてをマーケティングに投入して、ユーザーベースに50%を追加することができます。賢い選択のように聞こえますか?(明らかに、あなたの会社に合わせて数値をカスタマイズする必要があり、最終結果は移植を支持するかもしれません)。

それが「真の信者」を説得するのに役立つかどうかはわかりませんが、賢明なビジネスの動きです。そして、あなたが賢いビジネスの動きをしてはいけないなら、あなたは廃業しています。そして、確かにLinuxバージョンはありません。


16

ここで考慮すべきことが2つあります。

1つは、ある意味、彼らは正しいということです。クロスプラットフォームC ++を書くことは、最初から計画していればそれほど難しくありません。これはほとんど間違いなくあなたが見ている問題です。ほとんどのオープンソースアプリケーション(Linuxユーザーが平均的に触れるアプリケーションのほとんど)は、ばかばかしいクロスプラットフォームです。CまたはC ++で記述され、WindowsおよびLinuxだけでなく、x86、x86-64、ARM、SPARCなどのMacOS、BSD、Solarisなどで実行される、平均的なLinuxユーザーが毎日操作するアプリケーションの数について考えます。これは、一部は、システムで実行するコードをスクラッチポーティングする必要があるだけでなく、慣例がクロスプラットフォームの移植性を計画するためでもあります。

第二に、市場はあなたが思っているよりも実行可能性が高いかもしれません。Linuxのユーザーはソフトウェアにお金を払いたくないという大きな誤解があります。本当かもしれませんが、Linuxを使用している人は大勢います(ほとんどの人はそう思います)。また、あなたの会社が主にプロフェッショナルな環境で使用される製品を生産している場合、企業はLinuxシステムで実行するソフトウェアの支払いによく慣れています。

他の人が言ったように、パッケージについてあなたが主張する点に関しては、あなたは本当に本当に主要なディストリビューションの最新バージョン用のパッケージを作成する必要があります。実際にパッケージを作成するのはそれほど難しくなく、ほとんどの主要なディストリビューションはdebianパッケージ(debian、ubuntuなど)またはRPM(fedora、suse、centos、mandrake)を使用しているため、一部のスクリプトを変更することは非常に少ないベースラインの.debとベースラインの.rpmから複数のパッケージを作成し、他のすべての人がバイナリとreadmeでtarballを投げるだけで、それをインストールする方法がわかります。または、すべてのパッケージングをスキップし、bashまたはperlスクリプトを使用して単一のtarballをポストするだけでインストールを実行できます。

Joe Internetが言ったように、あなたのフォーラムのユーザーにどのように対処するかについては、彼らは何があっても文句を言う人の割合に過ぎないかもしれませんが、私が最初にすべきことはあなたがクロスプラットフォームサポートを考慮して設計されていない大量のレガシーコード。第二に、Linuxの移植を行うことが財政的に支援されるかどうかを正直に確認し、その結果を公開してください。最後に、ポートが財政的に実現可能でない場合は、プログラムをWINEで適切に動作させるための作業を行うことを参照してください。WINEは最初の解決策ではありませんが、Linuxでアプリを使用したい人を楽しませてくれるだけでなく、フルポートよりも安価なプロジェクトになります。実際、プロジェクトの一部としてコードをWINEコードベースに追加すると、新しい市場に参入できるようになるだけでなく、


真のクロスプラットフォーム配信の苦痛を最小限に抑えることで、あなたの答えは実際に間違っていると思います-特にこれらのプラットフォームで商用製品をテストする問題にまったく言及しなかったからです。複数のプラットフォームをサポートするコストについても言及していません。
-davidbak

10

アドビ、あなたですか?

しかし、真剣に、ある種の賞金をかけ、Linuxバージョンを事前注文できるようにします。時間内に納める価値のある港を作るために十分な注文を受け取った場合、そうでなければ払い戻しをすれば、それだけの価値があるために人々が気にかけないという証拠が得られます。

何かを移植する場合は、最新のUbuntu LTSリリース、RHEL、SLEDをターゲットにし、おそらくtar.gzを提供してください。これにより、3つのパッケージを心配することになります。おそらく、tar.gzバージョンを使用するのに十分なことを他の誰もが知っているでしょう。


多くの企業はバイナリのみを配布することを望んでいるため、.tar.gzメソッドはおそらく使用できません。
デビッドソーンリー

4
@David Thornley:それがtarballであるからといって、それがソースパッケージである必要があるとは限りません。関連するバイナリ、ドキュメント、およびREADMEファイルをtarballにパッケージ化してから、ユーザーに任せて、バイナリとライブラリをインストールする場所に任せ、システムを構成してアプリを動作させることができます。
セルセリラ

5

クロスプラットフォームのC ++コードを書くことはそれほど簡単ではありません

まったく逆です。クロスプラットフォーム作業を計画し、使用するプラットフォーム固有のAPIの抽象化を提供する場合、コードの大部分はすでにクロスプラットフォームです。Boost、Qt、NSPRなどの人気のあるライブラリを既に使用している場合は、すでにクロスプラットフォームビルドが機能していることに近いでしょう。

開発サイクルの後半に移植を行うときに最もよく発生する問題は、プログラムの一部にプラットフォーム固有のAPIに依存するコードの重要な部分があり、直接使用する必要がなく、おそらくまったく使用すべきではないことです。(優れた設計ではモジュールが強力に分離され、クラスのグループは自由に書き換えられた置換と交換できます。これが特定のモジュールに当てはまらない場合は、強力なコード臭です。)

簡単な解決方法は、多くの場合、「ユーティリティ」クラスを記述し、そこにプラットフォーム固有のものをすべて投げ込むことです。それは「簡単で痛みがない」わけではありませんが、あなたが思っているほど難しくはありません。

多くのディストリビューションパッケージを準備して、Linuxのすべての普及バージョン用に維持するには時間がかかります

これは残念な誤解です。複数のプラットフォーム用のビルドを維持するには追加の労力が必要になるのは事実ですが(専用の毎日のビルドサーバーを設定し、特定のディストリビューション用にパッケージ化する方法を学習する場合)、 ]。」まったく逆です。ほんの一握りのパッケージ(たとえば、Ubuntu、Fedora、および単一のLSB互換tarball)を維持するだけでよく、さまざまなLinuxコミュニティが残りの作業を引き受けます。特に、お使いのソフトウェアが人気がある場合、HOWTOはすべてのディストリビューションで発生し、必要なセットアップ手順を提供します。または、ソフトウェアを自由に配布できる場合(無料の製品でなく実行できます)(ライセンスで許可されている場合)、より人気のあるディストリビューションには、ソフトウェアのコピーを保持する何らかの代替リポジトリがあります。

コミュニティは一般にこれについて非常に優れており、経験豊富なユーザーは、許可すればあなたのためにこのレッグワークの多くを喜んで行います。

私たちの推定では、Linux市場は全ユーザーの5〜15%程度であり、それらのユーザーはおそらく私たちの努力にお金を払いたくないでしょう。

別の不幸な、そして非常に誤った誤解。

Linuxユーザーがオペレーティングシステムを無料で入手したからといって、ソフトウェアにお金を払わないというわけではありません。ソフトウェアは非常に良好であり、そのための幅広い需要があれば、Linuxユーザは、多くの場合になりますより多くのあなたのWindowsユーザーがなるよりも、自分のお金で一部に喜んで。Humble Indie Bundlesを見てください。Linuxユーザーは、Windowsユーザーに比べて平均してユーザーあたり2倍以上の支払いをしています。

また、その分野にある既存のソフトウェアの種類によっては、製品が他のプラットフォーム(Linuxの製品を知らないとわからない)よりもLinuxユーザーの間で大きな需要がある可能性があります。あなたが思っているよりも大きな潜在的な市場があるかもしれません。


4

そのような態度で、私はそれらを無視します。それらはXのセグメントのように聞こえます。Xは何でもよく、あなたがをしても文句を言うでしょう。Linuxバージョンをリリースするかどうか、それはあなたの選択であり、彼らのものではありません。


1

Nvidiaで働いている場合...

神の愛のために、それを吸い上げて、すでにいくつかのまともなドライバーを書いてください。

それ以外の場合、通常のビジネスアプリケーションを実行している場合は、C#で実行する将来のプロジェクトをターゲットにします。

Monoは.NET 3.5まで完全に準拠しており、winforms GUIも使用できます。注意が必要なモジュールはOS固有のものだけですが、それらはほとんどありません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.