Mengapa Linux tidak dianut sebagai kernel resmi GNU?


128

Sementara saya tahu cukup lama tentang keberadaan Hurd , dan misinya sebagai kernel resmi Sistem Operasi GNU, saya bertanya-tanya bagaimana bisa Linux tidak dianut sebagai kernel GNU resmi selama bertahun-tahun, mengingat bahwa itu berada dalam keadaan yang jauh lebih baik dari pada Hurd?

Linux telah, kurang lebih, melayani peran ini 20+ tahun sejauh ini, namun orang dapat melihat bahwa Proyek GNU menjaga jarak ketika datang ke Linux. Mengapa ini terjadi? Apakah karena mimpi bahwa Hurd akan (pada titik tertentu di masa depan) berada pada tingkat kualitas produksi? Apakah itu karena proyek GNU tidak melihat misinya tercermin sebanyak yang diinginkan di Linux? Apakah karena alasan politik lainnya?


20
Jenis pertanyaan "ilegal" di sini tetapi menarik. Dengan sedikit keberuntungan ia akan dilindungi untuk "signifikansi historis", diberikan jawaban yang cukup cemerlang ... ;-)
Hauke ​​Laging

2
@HaukeLaging Pasangan Thanx. Saya juga merasa seperti ini adalah pertanyaan yang bagus, dan mungkin menghasilkan jawaban yang menarik, dan tidak bisa benar-benar mengerti mengapa seseorang akan memberikan suara yang dekat. Saya yakin ini adalah sesuatu yang ingin diketahui banyak orang.
NlightNFotis

1
Oh, itu sederhana: Seseorang hanya perlu menunjuk pada FAQ dan berteriak "di luar topik" DAN "terlalu luas" ...
Hauke ​​Laging

5
@ HaukeLaging Anda sangat benar, dan saya berharap orang-orang lebih pragmatis dan bisa mengenali pertanyaan dengan beberapa nilai, alih-alih hanya menunjuk ke FAQ dan berteriak. Orang dapat dengan mudah melihat di SO pertanyaan-pertanyaan paling menarik yang ditutup, hanya untuk bertanya-tanya ...
NlightNFotis

4
Saya baru saja membaca kembali FAQ. IMHO ini pada topik di sini. Meskipun ini adalah meta-pertanyaan, tetapi pertanyaan itu sendiri berkaitan dengan Linux / Unix dan cukup jelas.
Nils

Jawaban:


151

GNU tidak akan mengadopsi sesuatu sebagai proyek kecuali jika pengembang menyetujui ketentuan tertentu yang mengikat semua proyek resmi GNU.

Saat ini kernel Linux mungkin tidak sesuai dengan batasan ini, dan tidak ada apa pun untuk Linus Torvalds, kernel.org, dkk. untuk mendapatkan dari menempatkan diri mereka di bawah payung GNU, dan banyak yang hilang - perjanjian mengikat yang disebutkan sebelumnya, dan persepsi publik bahwa kernel sekarang menjadi proyek GNU, yang sebagian besar akan berdampak negatif. Organisasi induk GNU, Free Software Foundation (FSF), adalah organisasi politik dan Torvalds telah membuat berbagai kritik publik terhadapnya dan pemimpin / pendiri seumur hidup ikonoklastik yang agak kontroversial, pendiri GNU dan FSF, Richard M. Stallman.

Lebih lanjut, kernel Linux tidak membutuhkan ruang pengguna GNU lebih dari ruang pengguna GNU membutuhkan kernel Linux. Kemandirian ini harus dianggap sebagai hal yang baik oleh prinsip-prinsip dasar rekayasa perangkat lunak, yang mendukung modularitas dan kopling yang lebih longgar sebagai kebalikan dari yang berlawanan (hal-hal monolitik dengan kopling ketat).

Poin lain yang menentang gagasan ini adalah bahwa walaupun HURD mungkin tidak menarik bagi banyak orang seperti Linux, para pengembang dan pengguna HURD mungkin keberatan jika proyek mereka secara efektif dikeraskan dalam kontes popularitas. Dan bagus untuk mereka; "Persaingan" semacam ini adalah hal yang positif, sedangkan tunduk pada monopolisasi tidak - Anda berakhir dengan entitas besar yang menghambat kreativitas sebagian karena mereka rentan terhadap kontrol monolitik / meglomaniacal. Linux Foundation sudah merupakan organisasi independen, mungkin juga tetap seperti itu.


13
Terima kasih untuk jawaban yang fantastis. +1 dari saya, dan 2 catatan: 1) Jangan salah paham: Saya memiliki pendapat yang tinggi tentang Hurd. Saya sendiri adalah pengembang yang sangat tangguh. Namun (saya percaya itu) tidak dapat diperdebatkan bahwa Linux adalah keadaan yang lebih baik. 2) Saya dapat melihat mengapa Linux tidak ingin digabungkan dengan GNU, tetapi dari apa yang saya lihat adalah Proyek GNU yang menunjukkan keberatan terbesar untuk ini. Bisakah Anda menjelaskan hal ini?
NlightNFotis

14
@NlightNFotis: Apakah Anda yakin sebagian besar keberatan GNU? Baru saja membaca ini: torvalds-family.blogspot.ca/2008/11/black-and-white.html . Bagi saya tampaknya semua orang yang terlibat jauh lebih bahagia tanpa hubungan formal.
goldilocks

Terima kasih untuk posting blog ini. Lebih masuk akal sekarang. Saya akan membiarkan pertanyaan terbuka untuk beberapa waktu untuk melihat apakah orang menguraikan dengan jawaban yang lebih fantastis, dan jika tidak, pertanyaan Anda akan dipilih sebagai "jawaban" untuk pertanyaan ini. Hanya satu "petisi" terakhir. Maukah Anda, mengulangi jika saya bisa mengatakan, "Anda mungkin tidak memiliki pendapat yang tinggi tentang KEKERINGAN" karena itu membuat saya merasa agak tidak nyaman dan membuat saya merasa buruk tentang diri saya.
NlightNFotis

4
Saya sangat menyukai ide di balik Hurd. Apa yang baru saja terlintas di benak saya: Kecenderungan virtualisasi yang sedang berlangsung mungkin berubah menjadi bantuan besar bagi Hurd untuk melihat setidaknya sebagian dari dunia nyata. Anda tidak perlu OS lengkap untuk membuat seseorang menggunakannya. Jika Anda memiliki beberapa aplikasi yang memiliki keuntungan yang jelas dari menjalankan di bawah Hurd maka Anda cukup memasukkannya ke dalam Hurd VM. Mirip dengan chrooting, lxc atau apa pun.
Hauke ​​Laging

2
@NlightNFotis diulang :)
goldilocks

77

Ada banyak dokumentasi dan diskusi tentang ini di internet.

Jawaban singkat bahwa ada perbedaan ideologis yang mendalam antara proyek GNU dan proyek-proyek kernel Linux, yang menghalangi kemungkinan penyatuan.

Fokus FSF, organisasi di balik Proyek GNU, adalah pada kemurnian ideologis sehubungan dengan gagasan perangkat lunak bebas. Ini sebagian besar memimpin dari pandangan pendiri FSF / GNU, Richard Stallman. Selain itu, seperti yang disebutkan goldilocks, FSF sekarang sebagian besar merupakan organisasi advokasi politik. Untuk waktu yang lama sekarang, FSF belum menempatkan sumber daya yang signifikan ke dalam Proyek GNU, meskipun mereka menyediakan infrastruktur pendukung.

Proyek kernel Linux memiliki sikap yang lebih pragmatis pada kebebasan perangkat lunak, sekali lagi sebagian besar berasal dari pendirinya, Linus Torvalds. Proyek kernel Linux pada dasarnya adalah proyek perangkat lunak bebas, yang terdiri dari pengembang perangkat lunak yang berspesialisasi dalam pengembangan kernel / OS, dan dalam hal apapun organisasi advokasi politik.

Sebagai contoh spesifik tentang bagaimana ideologi ini bermain dalam praktik, pertimbangkan

1) Yang dianggap Stallman sebagai fakta yang tidak dapat diterima bahwa proyek Debian "mengiklankan" perangkat lunak tidak bebas dengan mempertahankan bagian arsip perangkat lunaknya yang tidak bebas. Ini ironis, karena proyek Debian memiliki fokus pada kebebasan perangkat lunak yang sangat mirip dengan FSF, sementara tidak terlalu kaku secara ideologis.

2) Bahwa kernel Linux memungkinkan modul kernel biner (tidak bebas) digunakan dengan kernel. Walaupun pengembang kernel tidak antusias dengan hal ini, mereka mentolerirnya, tetapi sulit membayangkan FSF melakukannya.

Perlu juga dicatat bahwa upaya Stallman untuk menamai sistem operasi berdasarkan kernel Linux sebagai GNU / Linux mungkin tidak meningkatkan hubungan antara FSF dan komunitas kernel Linux, meskipun saya tidak memiliki data spesifik tentang ini.

Selain dari hal lain, seperti yang disebutkan goldilocks, FSF memiliki berbagai aturan yang harus dipatuhi oleh proyek GNU. Ini termasuk penugasan hak cipta dari semua kode ke FSF. Ini dengan sendirinya akan menjadi pemecah kesepakatan, karena Linus Torvalds tidak pernah meminta penugasan hak cipta tersebut. Oleh karena itu, jika kernel Linux ingin menjadi bagian dari proyek GNU, semua kontribusi signifikan ke kernel Linux harus memiliki hak cipta mereka ditetapkan ke FSF. Mengingat usia dan ukuran proyek, dan jumlah kontributor, ini pada dasarnya tidak mungkin. Proyek yang jauh lebih kecil dan lebih muda (misalnya Mercurial) telah menemukan perangkat lunak melepaskan tugas yang menakutkan.

Harap dicatat bahwa jawaban ini sama sekali tidak dimaksudkan sebagai kritik terhadap FSF atau pengembang kernel Linux. Kedua belah pihak memiliki sudut pandang yang valid. Namun, kenyataan dari situasi ini adalah bahwa mereka sampai batas tertentu tidak cocok dengan sudut pandang.


4
+1 Saya suka jawaban ini. Informasi yang solid tentang masalah ini. Saya menghargai masukan Anda.
NlightNFotis

1
Perlu dicatat bahwa di banyak negara di Eropa 'penugasan hak cipta' tidak memungkinkan secara hukum. Ada kemungkinan lain (perjanjian kontributor) tetapi penetapan hak cipta mungkin tidak memungkinkan secara hukum - tidak hanya secara teknis.
Maciej Piechotka

1
@FaheemMitha, bukan oleh definisi GNU karena gumpalan biner adalah bagian dari kernel; mereka didistribusikan dalam kode sumber kernel, dan dibangun ke dalam binari kernel dan diperlukan agar berfungsi.
psusi

8
Ahh, driver berpemilik adalah hal lain yang GNU keberatan. Ini adalah salah satu alasan untuk GPLv3; untuk melarang modul berpemilik dari yang terkait dengan kode gratis, bahkan saat runtime, dan mengapa Linux memilih untuk tetap menggunakan GPLv2.
psusi

1
@vonbrand, apakah Anda setuju atau tidak tidak relevan; itu adalah posisi FSF dan karena itu, Linux tidak pernah bisa menjadi proyek GNU.
psusi

35

Saya mengutip komentar Richard Stallman , tentang keputusan untuk menggunakan Hurd daripada Linux.

Orang-orang kadang bertanya, `` Mengapa FSF mengembangkan kernel gratis baru alih-alih menggunakan Linux? '' Ini pertanyaan yang masuk akal. Jawabannya, secara singkat, adalah bukan itu pertanyaan yang kita hadapi.

Ketika kami mulai mengembangkan Hurd pada tahun 1990, pertanyaan yang kami hadapi adalah, `` Bagaimana kami bisa mendapatkan kernel gratis untuk sistem GNU? '' Tidak ada kernel seperti Unix gratis saat itu, dan kami tahu tidak ada rencana lain untuk menulis satu. Satu-satunya cara kita dapat berharap untuk memiliki kernel gratis adalah dengan menuliskannya sendiri. Jadi kami mulai.

Kami mendengar tentang Linux setelah dirilis. Pada saat itu, pertanyaan yang kami hadapi adalah, '' Haruskah kita membatalkan proyek Hurd dan menggunakan Linux sebagai gantinya? ''

Kami mendengar bahwa Linux sama sekali tidak portabel (ini mungkin tidak benar hari ini, tapi itulah yang kami dengar kemudian). Dan kami mendengar bahwa secara arsitektur Linux setara dengan kernel Unix; pekerjaan kami mengarah pada sesuatu yang jauh lebih kuat.

Mengingat tahun kerja kami sudah dimasukkan ke dalam Hurd, kami memutuskan untuk menyelesaikannya daripada membuangnya.

Jika kita memang menghadapi pertanyaan yang diajukan orang-orang --- jika Linux sudah tersedia, dan kami sedang mempertimbangkan apakah akan mulai menulis kernel lain --- kami tidak akan melakukannya. Sebaliknya kami akan memilih proyek lain, sesuatu untuk melakukan pekerjaan yang tidak dapat dilakukan oleh perangkat lunak gratis yang ada.

Tapi kami memulai Hurd, dulu, dan sekarang kami telah membuatnya bekerja. Kami berharap arsitektur superiornya akan membuat sistem operasi bebas lebih kuat.


7
Meskipun sudah ada jawaban fantastis untuk pertanyaan itu, saya akan memilih jawaban ini sebagai jawaban kanonik untuk pertanyaan itu karena ini menunjukkan alasan di balik pilihan untuk tetap dengan Hurd, langsung dari pencipta Proyek GNU, Richard Stallman.
NlightNFotis

9
Catatan "ini mungkin tidak benar hari ini" - Pendapat RMS tentang Linux tampaknya didasarkan pada desas-desus, bukan pengetahuan.
Martin Schröder

19
@ Martin: (Balasan Terlambat, tapi :) Ketika Torvalds pertama kali mengumumkan Linux, itu adalah x86 spesifik, dengan nol rencana untuk membuatnya portabel. Di utial thread Linus flat out mengatakan "Saya akan mengatakan bahwa porting tidak mungkin". Dengan demikian, rms tidak punya alasan untuk awalnya percaya bahwa Linux akan tumbuh menjadi seperti sekarang ini. Bukti dari mulut pemimpin proyek sulit dikatakan.
Kevin Cathcart

@KevinCathcart: RMS / FSF seharusnya mempelajari kode itu sendiri daripada mengandalkan yang lain ("kami dengar").
Martin Schröder

21
@ MartinSchröder: Mengapa mempelajari kode ketika Pemimpin Proyek secara eksplisit mengatakan itu tidak akan portabel? Bagaimanapun, Linux diumumkan pada tahun 1991. Butuh waktu hingga April 1994 (rilis 1.1.45) sebelum Linux bahkan menambahkan folder untuk port arsitektur. Butuh waktu lebih lama sebelum port praktis. Jika FSF membuat keputusan untuk melanjutkan Hurd pada tahun 1992 atau 1993, melihat kode hanya akan memperkuat bahwa kode itu non-portabel.
Kevin Cathcart

4

Saya hanya menambahkan 2 sen saya di sini, saya pikir apa yang telah dibahas pada titik ini sangat masuk akal, tetapi ada satu aspek utama yang saya pikir dapat benar-benar mempolarisasi fondasi GNU dan fakta bahwa Linux menjadi semakin lebih banyak tempat di mana korporasi besar menginvestasikan uang dan waktu nyata, gagasan bahwa linux adalah semacam proyek buatan sendiri itu tidak benar, bahkan tidak sedikit, mungkin ada beberapa pria acak yang mencoba untuk mendapatkan perhatian di tempat kejadian sambil memberikan menambal, tetapi untuk sebagian besar linux itu adalah pekerjaan untuk perusahaan.


1
Saya tidak berpikir FSF memiliki masalah dengan dukungan korporat dari proyek perangkat lunak. Fokus utama mereka adalah pada prinsip-prinsip perangkat lunak bebas.
Faheem Mitha

Dominasi perusahaan adalah masalah besar yang ingin ditangani oleh GNU GPL. Perangkat lunak berlisensi permisif sebenarnya prosedur normal di MIT dan Berkeley, tetapi begitu kode dikomersialkan, segera ditutup. Jadi misalnya, saya dapat memeriksa sumber Linux hari ini dan semua perbaikan yang dikembangkan secara komersial akan menguntungkan proyek potensial saya. Atau proyek pribadi kecil saya berikutnya dapat menggunakan hanya beberapa blok, intinya adalah bahwa setiap perbaikan yang dirilis bermanfaat bagi siapa pun yang bekerja dengan kode selanjutnya.
JM Becker

1

Penjelasan lain ditemukan di FAQ gnu.org :

Menjadikan GNU Hurd bekerja cukup baik untuk bersaing dengan Linux akan menjadi pekerjaan besar, dan itu jelas tidak perlu. Satu-satunya hal yang secara etis salah dengan Linux sebagai kernel adalah dimasukkannya firmware “gumpalan”; perbaikan terbaik untuk masalah itu adalah mengembangkan penggantian gratis untuk gumpalan .


-6

Linux tidak dapat menjadi Unix, karena Linux tidak sesuai dengan Posix .

Jadi, bahkan tanpa kerumitan politik, Linux tidak dapat memenuhi tujuan desain untuk Hurd.

Mengutip : "Hurd adalah pengganti proyek GNU untuk UNIX, sebuah kernel sistem operasi yang populer."

Mengagumkan, bahwa ada Debian / Hurd-Projekt . Tapi itu mungkin cerita yang berbeda ...

BTW: Windows (sejak NT / XP) juga didasarkan pada kernel MACH.


8
Jika Anda akan mengklaim bahwa Linux tidak sesuai dengan POSIX, Anda harus sedikit mendukungnya. Termasuk di mana FSF mengatakan mereka membutuhkan kernel yang benar-benar 100% mendukung POSIX. Omong-omong, Unix bukan POSIX. Unix (bermerek dagang) adalah OS proprietary tertentu, sehingga tak usah dikatakan bahwa tidak ada lain OS dapat bahwa OS.
psusi

6
Kutipan untuk kernel Windows yang didasarkan pada MACH? Wikipedia mengatakan mereka berbagi beberapa pilihan desain; tetapi dengan MACH menjadi mikrokernel prototipikal sementara sebagian besar layanan OS Windows berjalan di kernel bukan userland. Satu-satunya komponen OSS utama dalam kernel Windows yang saya ketahui adalah tumpukan jaringan yang dulunya didasarkan pada implementasi BSD; Namun itu robek dan diganti dengan yang lebih baik berinteraksi dengan sisa desain os beberapa versi yang lalu (IIRC di XP atau 2k).
Dan Neely

14
Tapi GNU juga bukan Unix.
Simon

6
@Nils, pertanyaan yang Anda tautkan bertentangan dengan posisi Anda, alih-alih mendukungnya.
psusi

8
@Nils, omong kosong Mach adalah sedikit kesalahpahaman populer lainnya. NT tidak memiliki kesamaan dengan mach. "Server subsistem" -nya tidak berbeda dengan daemon unix, yang tidak membuat microkernel. Awalnya gui diimplementasikan dalam mode pengguna, dan ini hanya memiliki kemiripan yang lewat ke sistem microkernel (meskipun begitu juga Xwindows, yang tidak menjadikan Linux sebagai microkernel), tetapi ini dihapus di NT4 dan dipindahkan ke kernel.
psusi
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.