Solusi 1:
Saya akan membagikan pengalaman saya bekerja sebagai teknolog di beberapa bidang berbeda...
(Perhatian:ini adalah cerita tentang Red Hat dan bagaimana saya tumbuh secara profesional dengannya)
Saya mulai bekerja dengan Linux secara profesional pada tahun 2000-2002. Ini terjadi selama pengadopsian luas Red Hat dan Red Hat Professional Editions (6.x, 7.x, 8.0). Ini tersedia untuk diunduh gratis serta set paket kotak. Mereka dapat dengan mudah ditemukan di toko ritel komputer.
Bagi saya, ini bermanfaat untuk melibatkan penghobi dan pengguna rumahan dengan yang sama produk yang mulai muncul di perusahaan. Pekerjaan saya saat ini adalah memindahkan sistem server pelanggan dari Unix komersial (HP-UX, AIX dan SCO) ke platform Red Hat.
Penghematan biaya sangat besar! Mengganti server $100k+ HP9000 PA-RISC dengan $40k Compaq ProLiant Intel server adalah kemenangan mutlak dalam hal biaya dan kinerja.
Jadi, mengapa Red Hat?
Red Hat adalah yang pertama ke pasar ini, mendapatkan dukungan bisnis, vendor, dan perangkat keras yang penting. Melihat vendor aplikasi besar menggunakan Red Hat sebagai platform target menyegel kesepakatan. Pengguna penghobi seperti saya dapat mentransfer keterampilan yang diasah di rumah ke lingkungan kerja kami dengan mudah. Komunitas itu berkembang. Tumpukan Slashdot, Freshmeat, dan LAMP diatur! Itu adalah saat yang tepat untuk Linux.
Pada titik ini, saya bertanggung jawab atas pengembangan dan evaluasi distribusi Linux sebagai platform untuk solusi perangkat lunak ERP berpemilik. Saya terjebak dengan Red Hat. Seringkali, saya mencoba distro lain (Mandrake, SuSE, Debian, Gentoo), tetapi akan menemukan masalah dengan pengemasan, dukungan perangkat keras (server atau periferal), (ukuran) komunitas atau pemecah kesepakatan lainnya.
Contoh:Saya menggunakan perangkat keras Compaq/HP ProLiant yang dilengkapi dengan kartu PCI-X ekspansi Digi Serial dan perangkat lunak faks produksi Esker VSIfax. Dua yang terakhir hanya memiliki dukungan driver untuk sistem operasi Red Hat. Dalam beberapa kasus, perangkat lunak hanya dikirimkan dalam bentuk biner atau RPM, menghalangi penggunaan yang mudah pada varian Linux lainnya.
Momentum penting dalam Dunia Teknologi Informasi
Tidak seorang pun ingin menjadi orang yang merekomendasikan kalah solusi atau proyek yang akhirnya menjadi yatim piatu, jadi Anda tetap dengan pilihan yang aman. Saya mengelola tumpukan teknologi yang perlu bekerja dengan andal dan memiliki beberapa lapisan dukungan. Memilih distribusi yang berbeda pada saat itu akan adil. pernah. tidak bertanggung jawab.
Bulan madu Red Hat berakhir untuk saya pada tahun 2003 dengan penghentian perangkat lunak edisi profesional. Red Hat Enterprise Linux adalah penggantinya dan dilengkapi dengan banyak bagasi... Biaya (model berbasis langganan yang mahal), aksesibilitas (menyusut basis pengguna dan komunitas) dan kebingungan umum tentang masa depan...
Saya mulai mencari alternatif, mengevaluasi kembali Gentoo, Debian dan SuSE. Saya tidak bisa mendapatkan dukungan yang tepat untuk semua komponen kumpulan teknologi kami. Saya terpaksa tetap menggunakan ekosistem Red Hat... Karena perubahan biaya yang liar terkait dengan Red Hat Enterprise Linux, saya akhirnya menjalankan Red Hat 8.0 yang sangat dimodifikasi selama tahun melewati akhir hidupnya. Baru setelah klon RHEL matang (Whitebox Linux, dan kemudian, CentOS), saya menyiapkan langkah nyata yang jauh dari standar saya.
Keuntungan utama turunan Red Hat adalah dan adalah kompatibilitas biner dengan versi RHEL berbayar. Bahkan dimungkinkan untuk melakukan konversi di tempat antara RHEL dan CentOS, dan sebaliknya. Saya terus bekerja dengan sistem mirip RHEL sampai saya membuat langkah karier berikutnya...
Saya kemudian menemukan diri saya dalam industri perdagangan keuangan frekuensi tinggi, di mana saya bertanggung jawab atas R&D dan rekayasa Linux untuk sistem perdagangan otomatis yang kritis. Penekanan di dunia ini adalah kecepatan , melalui pengujian dan penyetelan yang cermat. Sekali lagi, dukungan perangkat keras adalah kuncinya. Saya akan memiliki kartu jaringan khusus, perangkat keras khusus, perangkat keras server, atau pustaka aplikasi yang hanya disertifikasi untuk sistem RHEL atau mirip RHEL. Bahkan dalam kasus di mana sesuatu dapat dikompilasi untuk varian Linux lainnya, faktor komunitas muncul. Ketika saya berada di titik di mana saya perlu meneliti suatu masalah, sering kali masalah tersebut dapat ditelusuri ke catatan atau komentar di laporan Bugzilla Red Hat, atau kadang-kadang, saya hanya mengirimkan tambalan atau permintaan untuk rilis berikutnya .
Ketika saya mulai mempelajari jaringan latensi rendah dan penyetelan kernel, saya mulai membedah kernel RHEL stok dan kernel RHEL MRG Realtime. Saya perhatikan betapa banyak pekerjaan saat memasuki rilis ... 200+ tambalan ke kernel vanilla kernel.org. Baca komentar dan komit catatan. Anda mungkin memiliki hal-hal kecil seperti sysctl parameter terbuka atau standar yang lebih waras diterapkan. Red Hat membayar orang untuk menambal, menguji, dan memperbaiki masalah ini. Saya tidak melihat komitmen yang sama dari distribusi Linux lainnya... Tambahkan fakta bahwa platform perusahaan dijamin memiliki keamanan nyata, perbaikan bug, dan dukungan backport selama tahun .
Jadi saya akhirnya pindah ke perusahaan keuangan lain yang hampir semuanya Gentoo di server dan desktop... Itu adalah bencana bagi saya. Berasal dari dunia Red Hat dan CentOS, saya mengalami banyak masalah stabilitas dan manajemen dengan pengaturan Gentoo. Kontrol versi adalah masalah terbesar, tetapi berkurangnya dukungan komunitas dan kurangnya pengujian nyata juga menjadi perhatian. Saya mulai memperkenalkan RHEL ke lingkungan karena beberapa perangkat lunak pihak ketiga kami memerlukannya...
Tapi ada masalah... Pengembang saya terbiasa dengan Gentoo dan memiliki jalur pemutakhiran yang relatif mudah untuk pustaka inti dan versi aplikasi. Mereka tidak dapat menyesuaikan untuk memiliki versi utama tetap yang menjadi standar Red Hat Enterprise Linux. Proses pengembangan dan rilis diganggu dengan pertanyaan tentang mengapa GLIBC 2.7 tidak dapat dicangkokkan ke RHEL 5.x atau mengapa versi kompiler atau pustaka tertentu tidak tersedia. Ketika diberi tahu bahwa pemutakhiran antara versi utama RHEL/CentOS pada dasarnya memerlukan pembangunan kembali penuh, mereka kehilangan banyak kepercayaan pada solusinya.
Pada titik ini, saya menyadari bahwa Red Hat bergerak terlalu lambat bagi pengembang yang ingin menjadi yang terdepan. RHEL 6.x adalah peningkatan yang sangat dibutuhkan dan disambut baik, tetapi tema ini menjadi lebih jelas setelah saya mulai mewawancarai perusahaan rintisan dan perusahaan yang menganut prinsip DevOps.
Hari ini...
Semakin banyak pengembang dan pengguna Linux yang berasal dari lingkungan Linux non-Red Hat, non-SuSE, dan non-perusahaan.
- Mereka menggunakan Ubuntu atau Debian...
- Mereka tidak harus berurusan dengan hardware jadul atau dukungan vendor besar.
- Mereka menulis aplikasi mereka sendiri dari bawah ke atas (didukung sendiri).
- Virtualisasi dan komputasi awan mengabstraksi lapisan perangkat keras, jadi kekhawatiran tentang driver pengontrol RAID yang funky, periferal PCI-X, atau agen manajemen yang didistribusikan biner bahkan tidak ada dalam radar.
- Pengguna ini menginginkan alat dan area pengguna yang biasa mereka gunakan.
Jadi ada konflik... Para pengguna ini tidak mengerti mengapa mereka dibatasi pada versi aplikasi atau pustaka. Administrator sekolah lama masih menyesuaikan diri dengan paradigma baru. Argumen yang tampak berakar pada agama sebenarnya hanya fungsi dari bagaimana orang mengembangkan keahliannya masing-masing.
Saya melihat iklan pekerjaan hari ini untuk posisi insinyur DevOps Linux yang sangat senior yang bertuliskan:
Harus mahir-untuk-ahli dalam distribusi Linux berbasis Debian (Ubuntu dan varian oke. Red Hat lumayan , tetapi tidak disukai)
Jadi saya kira itu bekerja dua arah ... Saya telah meninggalkan peluang kerja karena 800 server CentOS yang akan saya kelola dijadwalkan untuk dikonversi ke Ubuntu. Tentu, Linux adalah Linux ... tetapi saya tidak merasa bahwa saya akan seefektif yang saya bisa ... Saya telah meraba-raba instalasi Debian dan berharap distro berbasis RPM sedang digunakan. Saya memiliki perdebatan sengit tentang manfaat berbagai platform (biasanya menempatkan Gentoo di bagian bawah daftar).
Jadi apa yang tepat untuk lingkungan ANDA? Tergantung. Saya pernah berada di perusahaan tempat insinyur sistem mengarahkan keputusan, serta organisasi tempat pengembang adalah raja. Saya pikir pengaturan terbaik adalah ketika pengembang dan orang-orang yang mendukung sistem menyepakati platform. Namun di luar itu, pikirkan tentang dukungan jangka panjang, kegunaan, komunitas, dan apa yang mengakomodasi tumpukan aplikasi Anda dengan cara yang paling tepat.
Pengembang yang berbakat harus dapat bekerja di lingkungan seperti RHEL atau seperti Debian. Dan yah, platform pengembangan harus mencerminkan lingkungan produksi. Anda pergi dari sana...
Solusi 2:
Saat ini saya bekerja di lingkungan yang telah menggunakan Linux selama lebih dari satu dekade. Semua orang di kantor menggunakan distro yang berbeda di desktop mereka dan juga di server. Dengan demikian, pilihan distribusi cenderung berkisar pada sejumlah hal tanpa urutan tertentu:
- Sejarah - Jelas sistem seperti RedHat dan Debian sudah ada sejak lama. Dengan demikian, pepatah "jika tidak rusak, jangan perbaiki" dapat digunakan untuk ini. Upgrade menjadi lebih mudah jika perangkat lunak didukung dengan baik di distro.
- Keakraban - Mirip dengan Sejarah, namun kita semua memiliki favorit kita. Saya berhenti menggunakan Debian, dan bermigrasi ke Ubuntu (keputusan yang sulit saat itu karena saya cenderung berkomitmen pada komunitas). Sebaliknya, sulit untuk mengingat cara melakukan berbagai hal di selusin distro yang berbeda (belum lagi yang dibuat dari awal).
- Dukungan - Saya bermigrasi ke Ubuntu terutama karena saya menghargai apa yang mereka lakukan sejauh menawarkan dukungan berbayar. Itu adalah nilai jual jika klien memiliki kekhawatiran tentang menjalankan sistem jangka panjang. Mirip dengan pendekatan RedHat (tetapi RPM sedang terjadi saat itu). Kami juga memiliki sejumlah server RedHat karena alasan ini.
- Dependensi - Beberapa perangkat lunak lebih mudah digunakan pada beberapa distro hanya karena paket dependen lebih mudah diperoleh atau dibuat. Sebagai contohnya adalah oVirt di RedHat. Tidak ada paket untuk beberapa software di beberapa distro. Dan Anda dapat mengompilasinya, tetapi mengapa jika paket tersebut ada di distro lain?
- Perincian - Distro seperti Gentoo menawarkan kontrol yang lebih baik atas pembuatan versi dan perincian peralihan perangkat lunak. Distro lain memiliki "pinning" dalam berbagai bentuk, tetapi itu masih belum dapat dikontrol atau diandalkan.
- Mengikat - Meskipun mungkin untuk mengkompilasi dari sumber di sebagian besar distro, beberapa distro lebih baik daripada yang lain. Hal ini dapat berpengaruh, misalnya, jika proyek Anda menambal pustaka yang ada untuk fungsionalitas tambahan.
- Kecantikan - Beberapa distro terlihat lebih baik. Setiap geek tahu itu hanya omong kosong (dan Anda mungkin bisa melakukannya sebagai aplikasi web akhir-akhir ini) tetapi beberapa klien kagum dengan hal ini, dan kita semua mengetahuinya.
- Stabilitas - Beberapa distro mengalirkan versi perangkat lunak "stabil" sebagai lawan dari "pengujian", "eksperimental", dll. Ini bisa sangat berarti jika Anda tahu bahwa versi yang Anda buat pada akhirnya akan mencapai konsensus tentang stabilitas. Anda dapat mengembangkan "eksperimental" dengan mengetahui bahwa pada saat proyek Anda selesai, proyek tersebut akan mencapai "stabil" dan bagus untuk diandalkan.
- Pengelolaan paket - Jika Anda mengembangkan sesuatu setiap hari, dan itu akan menjangkau 1000 mesin sekaligus, Anda mungkin menginginkan sesuatu yang memudahkan pembuatan, pemeliharaan, dan pelacakan paket di seluruh sistem tersebut.
- Konsistensi - Ini lebih merupakan argumen untuk sama distro. Lebih sedikit kesalahan yang dibuat (dan lebih sedikit kesalahan dalam keamanan) ketika orang dapat fokus pada satu distro daripada beberapa distro.
- Jadwal rilis yang dapat diprediksi - Jika Anda ingin memastikan perangkat lunak Anda tetap didukung, pemutakhiran terencana menawarkan jenis stabilitas tertentu.
- Keamanan - Beberapa distro memiliki tim keamanan aktif yang bertugas untuk segera merespons risiko keamanan asli dalam paket apa pun yang disetujui.
Itu hanya beberapa hal yang muncul di kepala saya mengenai alasan mengapa setiap sistem dipilih. Saya tidak melihat satu pun petunjuk atau preferensi dari satu distro di atas yang lain dalam keputusan ini. Keanekaragaman dan pilihan bisa menjadi hebat dan menawarkan Anda beberapa opsi yang sangat bagus untuk memulai proyek dengan cepat, tetapi itu juga merupakan jeratan yang dapat membuat Anda tertahan. Pastikan Anda memikirkan terlebih dahulu apa yang akan Anda butuhkan. Rencanakan apa kebutuhan sistem serta kapan sistem akan ditingkatkan atau dipensiunkan. Jangan berasumsi bahwa Anda akan selalu menjadi orang yang memeliharanya.