解決策 1:
いくつかの異なる分野で技術者として働いた経験を共有します...
(注意:これは Red Hat と、私がどのように Red Hat と共にプロとして成長したかについての話です)
私は 2000 年から 2002 年にかけて専門的に Linux を扱い始めました。これは、Red Hat と Red Hat Professional Edition (6.x、7.x、8.0) が広く採用されていた時期でした。これらは、無料でダウンロードできるほか、箱入りのパッケージ セットも入手できました。コンピュータ小売店で簡単に見つけることができます。
私にとって、これは愛好家や家庭のユーザーを 同じ に引き付けるという利点がありました 企業に現れ始めた製品。このときの私の仕事は、顧客のサーバー システムを商用 Unice (HP-UX、AIX、および SCO) から Red Hat プラットフォームに移行することでした。
大幅なコスト削減になりました！ 10 万ドル以上の HP9000 PA-RISC サーバーを 4 万ドルの Compaq ProLiant Intel サーバーに置き換えることは、コストとパフォーマンスの点で絶対的な勝利でした。
では、なぜ Red Hat なのですか?
Red Hat はこの市場に参入した最初の企業であり、重要なビジネス、ベンダー、およびハードウェアのサポートを獲得しました。大規模なアプリケーション ベンダーが Red Hat をターゲット プラットフォームとして使用しているのを見て、契約が成立しました。私のような愛好家のユーザーは、自宅で磨いたスキルを職場環境に簡単に移すことができました.コミュニティは成長していました。 Slashdot、Freshmeat、LAMP スタックが支配しました! Linux にとって良い時期でした。
この時点で、私は独自の ERP ソフトウェア ソリューションのプラットフォームとしての Linux ディストリビューションの開発と評価を担当していました。私はレッドハットに固執しました。時々、別のディストリビューション (Mandrake、SuSE、Debian、Gentoo) を試してみましたが、パッケージング、ハードウェア サポート (サーバーまたは周辺機器)、(のサイズ) に問題がありました。 コミュニティまたはその他の契約違反者。
例:私は、Digi Serial 拡張 PCI-X カードと Esker VSIfax プロダクション ファックス ソフトウェアを装備した Compaq/HP ProLiant ハードウェアを使用していました。後者の 2 つは、Red Hat オペレーティング システムのドライバー サポートのみを備えていました。場合によっては、ソフトウェアがバイナリまたは RPM 形式でのみ提供され、他の Linux バリアントで簡単に使用できなかった.
情報技術の世界では勢いが重要
誰も負けを推奨する人になりたくない 最終的に孤立するソリューションまたはプロジェクトであるため、安全な選択に固執します。私は、確実に機能し、複数のサポート層を持つ必要があるテクノロジー スタックを管理していました。その時点で別のディストリビューションを選択すると、ちょうどいいでしょう。その間。無責任。
私にとっての Red Hat ハネムーンは、2003 年にソフトウェアのプロフェッショナル エディションが廃止されたことで終わりを迎えました。 Red Hat Enterprise Linux は代替品であり、かなりの荷物がありました... コスト (高価なサブスクリプション ベースのモデル)、アクセシビリティ (ユーザー ベースとコミュニティの縮小)、そして将来についての一般的な混乱...
私は代替案を探し始め、Gentoo、Debian、SuSE を再評価しました。テクノロジー スタックのすべてのコンポーネントについて適切なサポートを受けることができませんでした。 Red Hat のエコシステムに固執することを余儀なくされました... Red Hat Enterprise Linux に関連する大幅なコスト シフトにより、大幅に変更された Red Hat 8.0 を 年 実行することになりました 寿命を過ぎています。 RHEL クローンが成熟するまで (Whitebox Linux とその後の CentOS)、私は自分の標準から真に移行する準備ができていませんでした。
Red Hat の派生製品の主な利点は is でした 有料の RHEL バージョンとのバイナリ互換性。 RHEL と CentOS の間でインプレース変換を実行することも、その逆も可能です。次の転職まで、RHEL のようなシステムで働き続けました...
その後、高頻度の金融取引業界に身を置き、重要な自動取引システムの研究開発と Linux エンジニアリングを担当していました。この世界で強調されたのはスピードでした 、慎重なテストとチューニングによって。ここでも、ハードウェア サポートが重要でした。 RHEL または RHEL に似たシステムに対してのみ認定された、特定のネットワーク カード、特殊なハードウェア、サーバー ハードウェア、またはアプリケーション ライブラリが必要です。他の Linux バリアント用にコンパイルできる場合でも、コミュニティ要因が発生しました。問題を調査する必要があるときは、多くの場合、Red Hat Bugzilla レポートのメモやコメントにたどり着くことができる問題でした。または、単純にパッチを送信したり、次のリリースのリクエストを送信したりすることもありました。 .
低レイテンシーのネットワークとカーネルのチューニングを掘り下げ始めたので、ストック RHEL カーネルと RHEL MRG Realtime カーネルを分析し始めました。リリースに入ると、どれだけの作業が行われるかに気付きました... バニラの kernel.org カーネルへの 200 以上のパッチ。コメントを読み、メモをコミットします。 sysctl のような小さなものがあるかもしれません パラメータが公開されるか、より適切なデフォルトが適用されます。 Red Hat は、これらの問題にパッチを適用し、テストし、修正するために人々に支払います。 他の Linux ディストリビューションでは同じ取り組みは見られませんでした... エンタープライズ プラットフォームは、年 の間、実際のセキュリティ、バグ修正、およびバックポートのサポートが保証されているという事実を追加します .
そこで私は最終的に、サーバー上でほぼすべてが Gentoo である別の金融会社に移りました そして デスクトップ...それは私にとって惨事でした。 Red Hat と CentOS の世界から来た私は、Gentoo のセットアップで多くの安定性と管理の問題に遭遇しました。バージョン管理が最大の問題でしたが、コミュニティ サポートの減少と実際のテストの欠如も懸念事項でした。 RHEL を環境に導入し始めたのは、一部のサードパーティ ソフトウェアで RHEL が必要だったからです...
しかし、問題がありました... 私の開発者は Gentoo に慣れていて、コア ライブラリとアプリケーション バージョンの比較的簡単なアップグレード パスを持っていました。彼らは、Red Hat Enterprise Linux が標準化する固定メジャー バージョンに適応できませんでした。開発とリリースのプロセスは、GLIBC 2.7 を RHEL 5.x に移植できない理由や、特定のコンパイラまたはライブラリのバージョンが利用できない理由についての疑問に悩まされていました。 RHEL/CentOS のメジャー バージョン間のアップグレードには、基本的に完全な再構築が必要であると言われたとき、彼らはソリューションに対する多くの信頼を失いました.
この時点で、Red Hat の動きは、最先端を行きたいと考えている開発者にとって遅すぎることに気付きました。 RHEL 6.x は待望の歓迎すべきアップグレードでしたが、DevOps の原則に賛同しているスタートアップや企業とのインタビューを開始すると、このテーマはより明確になりました。
今日...
非 Red Hat、非 SuSE、非エンタープライズ Linux 環境からの開発者と Linux ユーザーの数が増えています。
- 彼らは Ubuntu または Debian を使用しています...
- 旧式のハードウェアや大手ベンダーのサポートに対処する必要はありませんでした。
- 彼らはゼロから独自のアプリケーションを作成しています (自己サポート)。
- 仮想化とクラウド コンピューティングはハードウェア レイヤーを抽象化するため、ファンキーな RAID コントローラー ドライバー、PCI-X 周辺機器、またはバイナリ分散管理エージェントについての心配はレーダーにさえありません。
- これらのユーザーは、使い慣れたツールとユーザーランドを望んでいます。
競合が発生しています... これらのユーザーは、アプリケーションまたはライブラリのバージョンが制限される理由を理解していません。古い学校の管理者は、まだ新しいパラダイムに順応しています。 思われる議論 宗教に根ざすことは、実際には、人々がそれぞれのスキルセットをどのように開発したかの機能にすぎません.
今日、非常に上級の DevOps Linux エンジニアの求人広告を見ました。
<ブロック引用>Debian ベースの Linux ディストリビューションに精通している必要があります (Ubuntu とそのバリアントは問題ありません。Red Hat は合格 可 、しかしそうではない 推奨)
両方の方法で機能すると思います...私が管理する800台のCentOSサーバーがUbuntuに変換される予定だったため、仕事の機会から離れました。確かに、Linux は Linux です... しかし、自分ができるほど効果的であるとは思いませんでした... Debian のインストールに手こずり、RPM ベースのディストリビューションが使用されていることを望みました。私はさまざまなプラットフォームのメリットについて激しい議論をしてきました (通常は Gentoo をリストの一番下に置きます)。
では、あなたの環境には何が適切でしょうか?場合によります。私は、システム エンジニアが意思決定を行う企業や、開発者が王様である組織に所属してきました。開発者とシステムを支える人がプラットフォームで合意するのが最良の取り決めだと思います。しかし、それ以外では、長期的なサポート、使いやすさ、コミュニティ、およびアプリケーション スタックを最も適切な方法で収容するものについて考えてください。
有能な開発者は、RHEL や Debian に似た環境で作業できる必要があります。そして、開発プラットフォームは本番環境を反映する必要があります。そこから...
解決策 2:
私は現在、Linux を 10 年以上使用している環境で働いています。オフィスの全員が、デスクトップとサーバーで異なるディストリビューションを使用しています。そのため、配布の選択は、順不同で多くのことを中心に展開する傾向があります:
<オール>これらは、各システムが選択された理由について頭に浮かんだほんの一部です。この決定において、あるディストリビューションが別のディストリビューションよりも優れているという指針や好みは見当たりません。多様性と選択肢は素晴らしいものであり、プロジェクトを迅速に開始するための非常に優れたオプションを提供しますが、それはあなたを吊るす縄でもあります.何が必要になるかを事前に考えておきましょう。システムのニーズと、システムをいつアップグレードまたは廃止するかを計画します。あなたが常にそれを維持していると思い込まないでください。