いくつかの異なる分野で技術者として働いた経験を共有します...
（注意：これはRed Hatについての物語であり、私はRed Hatでプロとして育った方法です）
私は2000-2002年に専門的にLinuxを使い始めました。これは、Red HatおよびRed Hat Professional Edition（6.x、7.x、8.0）が広く採用されていた間です。これらは、無料でダウンロードできるほか、パッケージパッケージセットも入手できました。それらはコンピュータ小売店で簡単に見つけることができます。
私にとっては、これは、企業に登場し始めたのと同じ製品を愛好家やホームユーザーに利用できるという利点がありました。この時点での私の仕事は、顧客のサーバーシステムを商用のUnices（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ディストリビューションの開発と評価を担当しました。私はRed Hatにこだわった。時々、別のディストリビューション（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の誘導体の主な利点があっている有料のRHELのバージョンとのバイナリ互換性。RHELとCentOSの間でインプレース変換を実行することもでき、その逆も可能です。次のキャリアを動かすまで、RHELのようなシステムを使い続けました...
後に、高頻度の金融取引業界に就職し、重要な自動取引システムの研究開発とLinuxエンジニアリングを担当しました。この世界での重点は、慎重なテストとチューニングによる速度でした。繰り返しますが、ハードウェアサポートが重要でした。特定のネットワークカード、専用のハードウェアがある、RHELまたはRHELのようなシステムでのみ認定されたサーバーハードウェアまたはアプリケーションライブラリ。他のLinuxバリアント用にコンパイルできる場合でも、コミュニティの要因が生じました。問題を調査する必要があった時点で、Red Hat Bugzillaのレポートのメモやコメントにたどり着くことができる問題であることがよくありました。また、次のリリースのパッチやリクエストを送信することもありました。 。
低遅延ネットワークとカーネルチューニングを詳しく調べ始めたとき、ストックRHELカーネルとRHEL MRG Realtimeカーネルの分析を始めました。リリースに至ると、どれだけの効果があるか気づきました... vanilla kernel.orgカーネルへの200以上のパッチ。コメントを読み、メモをコミットします。sysctlパラメータが公開されたり、より適切なデフォルトが適用されたりするような小さなものがあるかもしれません。Red Hatはこれらの問題にパッチを当て、テストし、修正するために人々に支払います。他のLinuxディストリビューションからも同じようなコミットメントはありませんでした...エンタープライズプラットフォームには、実際のセキュリティ、バグ修正、バックポートサポートが何年も保証されているという事実を追加してください。
だから私は最終的にサーバーとデスクトップ上でほぼすべてがGentooだった別の金融会社に移りました...それは私にとって災難でした。Red HatとCentOSの世界から来て、Gentooのセットアップで多くの安定性と管理の問題に遭遇しました。バージョン管理が最大の問題でしたが、コミュニティのサポートの減少と実際のテストの欠如も懸念事項でした。私たちのサードパーティソフトウェアのいくつかがそれを必要としたため、私は環境にRHELを導入し始めました...
しかし、問題がありました...私の開発者はGentooに慣れていて、コアライブラリとアプリケーションバージョンの比較的簡単なアップグレードパスを持っていました。彼らは、Red Hat Enterprise Linuxが標準化する修正済みのメジャーバージョンに適応することができませんでした。開発とリリースのプロセスは、GLIBC 2.7をRHEL 5.xに移植できなかった理由や、特定のコンパイラーまたはライブラリーのバージョンが利用できなかった理由に関する質問に悩まされていました。RHEL / CentOSのメジャーバージョン間のアップグレードには基本的に完全な再構築が必要であると言われたとき、ソリューションに対する多くの自信を失いました。
この時点で、レッドハットの動きが遅すぎて、最先端を走りたいと思っている開発者には遅すぎることに気付きました。RHEL 6.xは大いに必要で歓迎されるアップグレードでしたが、このテーマは、DevOpsの原則に加入している新興企業や企業とのインタビューを開始すると明らかになりました。
今日...
開発者やLinuxユーザーの数は、Red Hatでも、SuSEでも、エンタープライズでもないLinux環境から来ています。
- 彼らはUbuntuまたはDebianを使用しています...
- 彼らは古い学校のハードウェアや大手ベンダーのサポートに対処する必要はありませんでした。
- 彼らは独自のアプリケーションをゼロから作成しています（自己サポート）。
- 仮想化とクラウドコンピューティングはハードウェアレイヤーを抽象化するため、ファンキーなRAIDコントローラードライバー、PCI-X周辺機器、またはバイナリ分散管理エージェントの心配はありません。
- これらのユーザーは、慣れ親しんだツールとユーザーランドを求めています。
競合があります...これらのユーザーは、アプリケーションまたはライブラリのバージョンが制限される理由を理解していません。古い学校の管理者はまだ新しいパラダイムに適応しています。宗教に根ざしていると思われる議論は、実際には、人々がそれぞれのスキルセットをどのように開発したかという機能にすぎません。
本日、非常に上級のDevOps Linuxエンジニアの求人広告を見ました：
DebianベースのLinuxディストリビューションの専門家である必要があります（Ubuntuおよびバリアントは問題ありません。RedHat可、ただし推奨されません）
だから私はそれが両方の方法で働くと思う...私が管理する800 CentOSサーバーはUbuntuに変換される予定だったので、私は仕事の機会から立ち去った。確かに、LinuxはLinuxです...しかし、私は自分ができるほど効果的だとは感じませんでした... Debianのインストールをいじって、RPMベースのディストリビューションが使用されていることを望みました。さまざまなプラットフォームのメリットについて熱烈な議論がありました（通常、Gentooをリストの一番下に置きます）。
それでは、あなたの環境に最適なものは何ですか？場合によります。私は、システムエンジニアが意思決定を推進している企業や、開発者が王様である組織に在籍しています。開発者とシステムをサポートする人々がプラットフォームについて合意するときが最善の方法だと思います。しかし、それ以外では、長期的なサポート、使いやすさ、コミュニティ、およびアプリケーションスタックを最も適切な方法で収容できるものについて考えてください。
才能のある開発者は、RHELのような環境またはDebianのような環境で作業できる必要があります。そして、開発プラットフォームは本番環境をミラーリングする必要があります。そこから行く...