เหตุผลไม่ใช่เหตุผลเชิงประวัติศาสตร์ แต่เป็นเหตุผลเชิงปฏิบัติ มีหลายโปรแกรมมากมายที่รันบนเคอร์เนล Linux; ถ้าส่วนต่อประสานเคอร์เนลทำลายโปรแกรมเหล่านั้นทุกคนจะต้องอัพเกรดโปรแกรมเหล่านั้น
ตอนนี้มันเป็นความจริงที่โปรแกรมส่วนใหญ่ไม่ได้ขึ้นอยู่กับอินเทอร์เฟซของเคอร์เนลโดยตรง (การเรียกของระบบ ) แต่ขึ้นอยู่กับอินเตอร์เฟสของไลบรารีมาตรฐาน C (ตัวห่อ C รอบการเรียกระบบ) โอ้ แต่ห้องสมุดมาตรฐานอะไร glibc? uClibc? Dietlibc? ไบโอนิค? คิดถึง? เป็นต้น
แต่ก็มีหลายโปรแกรมที่ใช้บริการเฉพาะระบบปฏิบัติการและขึ้นอยู่กับอินเตอร์เฟสของเคอร์เนลที่ไม่ได้เปิดเผยโดยไลบรารีมาตรฐาน (บนลินุกซ์หลายเหล่านี้ถูกนำเสนอผ่าน/proc
และ/sys
.)
จากนั้นก็จะมีการรวบรวมไบนารีแบบคงที่ หากการอัพเกรดเคอร์เนลแตกหนึ่งในนั้นทางออกเดียวเท่านั้นที่จะคอมไพล์ใหม่ หากคุณมีแหล่งที่มา: Linux จะสนับสนุนซอฟต์แวร์ที่เป็นกรรมสิทธิ์ด้วย
แม้ว่าจะมีแหล่งที่มา แต่ก็รวบรวมได้ทั้งหมดอาจเจ็บปวด โดยเฉพาะอย่างยิ่งเมื่อคุณอัพเกรดเคอร์เนลเพื่อแก้ไขข้อบกพร่องด้วยฮาร์ดแวร์ของคุณ ผู้คนมักจะอัพเกรดเคอร์เนลเป็นอิสระจากระบบอื่น ๆ เพราะพวกเขาต้องการการสนับสนุนฮาร์ดแวร์ ในคำพูดของ Linus Torvalds :
การทำลายโปรแกรมผู้ใช้ไม่สามารถทำได้ (…) เรารู้ว่าผู้คนใช้ไบนารีเก่ามานานหลายปีและการสร้างรุ่นใหม่ไม่ได้หมายความว่าคุณจะสามารถกำจัดทิ้งได้ คุณสามารถไว้วางใจเรา
นอกจากนี้เขายังอธิบายด้วยว่าเหตุผลหนึ่งที่ทำให้กฎข้อนี้แข็งแกร่งคือการหลีกเลี่ยงการพึ่งพานรกซึ่งคุณไม่เพียง แต่ต้องอัพเกรดโปรแกรมอื่นเพื่อให้เคอร์เนลใหม่บางตัวทำงาน แต่ยังต้องอัพเกรดอีกโปรแกรมหนึ่งและอีกอันและอีกอันหนึ่ง เพราะทุกอย่างขึ้นอยู่กับรุ่นทุกอย่าง
มันค่อนข้างโอเคที่จะมีการพึ่งพาทางเดียวที่กำหนดไว้อย่างดี มันเศร้า แต่ก็หลีกเลี่ยงไม่ได้บางครั้ง (…) สิ่งที่ไม่เป็นไรคือการพึ่งพาสองทาง หากรหัสพื้นที่ผู้ใช้ HAL ขึ้นอยู่กับเคอร์เนลใหม่ก็โอเคแม้ว่าฉันสงสัยว่าผู้ใช้จะหวังว่ามันจะไม่เป็น "เคอร์เนลของสัปดาห์" แต่สิ่งที่ "เคอร์เนลของไม่กี่เดือนที่ผ่านมา"
แต่ถ้าคุณมีการพึ่งพาแบบสองทางคุณจะเมา นั่นหมายความว่าคุณต้องอัพเกรดในขั้นตอนการล็อคและนั่นก็ไม่ได้รับการยอมรับ มันเป็นเรื่องที่น่ากลัวสำหรับผู้ใช้ แต่ที่สำคัญยิ่งกว่านั้นก็เป็นเรื่องที่น่ากลัวสำหรับนักพัฒนาเพราะนั่นหมายความว่าคุณไม่สามารถพูดว่า "มีข้อผิดพลาดเกิดขึ้น" และทำสิ่งต่าง ๆ เช่นพยายาม จำกัด ให้แคบลง
ใน userspace การพึ่งพาซึ่งกันและกันเหล่านั้นมักจะถูกแก้ไขโดยทำให้ไลบรารีต่าง ๆ แต่คุณจะเรียกใช้เพียงหนึ่งเคอร์เนลดังนั้นจึงต้องสนับสนุนทุกสิ่งที่ผู้คนอาจต้องการทำกับมัน
อย่างเป็นทางการ ,
ความเข้ากันได้แบบย้อนหลังสำหรับ [สายระบบประกาศมั่นคง] จะรับประกันอย่างน้อย 2 ปี
ในทางปฏิบัติแม้ว่า
อินเทอร์เฟซส่วนใหญ่ (เช่น syscalls) คาดว่าจะไม่มีการเปลี่ยนแปลงและพร้อมใช้งานเสมอ
สิ่งที่เปลี่ยนแปลงบ่อยขึ้นคืออินเทอร์เฟซที่ใช้สำหรับโปรแกรมที่เกี่ยวข้องกับฮาร์ดแวร์/sys
เท่านั้น ( /proc
ในทางกลับกันซึ่งนับตั้งแต่การเปิดตัว/sys
ถูกสงวนไว้สำหรับบริการที่ไม่เกี่ยวข้องกับฮาร์ดแวร์มันค่อนข้างจะไม่เข้ากันได้ในทางที่ไม่เข้ากัน)
สรุป,
การแบ่งพื้นที่ผู้ใช้จะต้องมีการแก้ไขในระดับแอปพลิเคชัน
และนั่นก็ไม่ดีเพราะมีเพียงเคอร์เนลเดียวซึ่งผู้คนต้องการอัพเกรดโดยไม่ขึ้นกับส่วนที่เหลือของระบบ แต่ก็มีแอพพลิเคชั่นมากมายที่มีการพึ่งพาซึ่งกันและกัน มันง่ายกว่าที่จะรักษาเสถียรภาพของเคอร์เนลที่จะทำให้แอพพลิเคชั่นนับพันเป็นปัจจุบันในการตั้งค่าต่างๆ