ทำไม Debian จึงเป็นอย่างที่เห็นในปัจจุบัน?
(blog.liw.fi)- แนวปฏิบัติที่เป็นเอกลักษณ์ของ Debian มาจากทางเลือกที่ ระบบปฏิบัติการอเนกประสงค์ขนาดใหญ่ที่มีอายุ 30 ปี สั่งสมมาเพื่อรักษาคุณภาพ ความปลอดภัย และหลักการซอฟต์แวร์เสรีในระยะยาว
- Debian ไม่ได้มุ่งเป็นดิสทริบิวชันสำหรับการใช้งานเฉพาะทาง แต่เป็น ดิสทริบิวชันอเนกประสงค์ ที่เหมาะกับคนและวัตถุประสงค์ส่วนใหญ่ โดยเกณฑ์หลักในการตัดสินใจว่าจะรวมแพ็กเกจหรือไม่คือความเป็นซอฟต์แวร์เสรีและคุณภาพในการดูแลรักษา
- รัฐธรรมนูญ สัญญาทางสังคม และ DFSG เป็นกลไกที่เกิดขึ้นหลังจากการดำเนินงานแบบหลวม ๆ ในยุคแรกเผยให้เห็นข้อจำกัด โดยทำให้ การตัดสินใจแบบประชาธิปไตย และอำนาจผู้นำที่จำกัดกลายเป็นระบบทางการ
- หลักการบิลด์แบบพึ่งพาตนเองและการหลีกเลี่ยงไลบรารีที่ bundle มา เป็น กลยุทธ์การดูแลรักษา ที่ทำให้สามารถแก้ไขความปลอดภัยเร่งด่วน รีบิลด์ และพอร์ตไปยังสถาปัตยกรรมใหม่ได้ โดยไม่ถูกคลังภายนอกหรือ dependency ซ้ำซ้อนครอบงำ
- กระบวนการตรวจสอบสมาชิก ชื่อรหัสของรีลีส และจังหวะการเปลี่ยนแปลงที่ช้า เป็นวิธีที่โปรเจกต์ซึ่งมีแพ็กเกจนับพันและฐานการติดตั้งหลายสิบล้านเครื่องใช้จัดการความเชื่อถือ ต้นทุนการ mirror และต้นทุนในการสร้างฉันทามติ
ระบบปฏิบัติการที่ Debian มุ่งหวัง
- Debian มุ่งเป็นระบบปฏิบัติการที่มี คุณภาพสูง ปลอดภัย และใช้งานได้อเนกประสงค์ โดยต้องการประกอบขึ้นจากซอฟต์แวร์เสรีและโอเพนซอร์สเท่านั้น และทำงานได้บนคอมพิวเตอร์ส่วนใหญ่ที่มีการใช้งานอย่างแพร่หลาย
- เป้าหมายของการเป็นระบบปฏิบัติการอเนกประสงค์หมายความว่า Debian ควรเหมาะกับคนส่วนใหญ่ในวัตถุประสงค์ส่วนใหญ่
- แม้จะเหมาะกับทุกสถานการณ์ไม่ได้ แต่ก็เป็นเป้าหมายที่ควรยึดถือ
- เป้าหมายนี้นำไปสู่การตัดสินใจที่ต่างจากดิสทริบิวชันที่เน้นวัตถุประสงค์เฉพาะ เช่น เดสก์ท็อป เซิร์ฟเวอร์ เกม หรือการวิจัยทางวิทยาศาสตร์
- การจะแพ็กเกจซอฟต์แวร์หรือไม่นั้นขึ้นกับเกณฑ์ต่อไปนี้มากกว่าประโยชน์ใช้สอยของซอฟต์แวร์
- ซอฟต์แวร์นั้นเป็น ซอฟต์แวร์เสรี หรือไม่
- Debian สามารถดูแลให้เป็น แพ็กเกจคุณภาพสูง ได้หรือไม่
รัฐธรรมนูญและธรรมาภิบาล
- Debian มีลักษณะใกล้เคียงกับองค์กรโอเพนซอร์สที่เป็นประชาธิปไตยอย่างชัดเจน
- มีขั้นตอนการตัดสินใจที่นิยามไว้อย่างดี
- มีการเลือกตั้ง Debian Project Leader ทุกปี
- อำนาจของผู้นำโปรเจกต์ถูกจำกัดอย่างเข้มงวด และอำนาจจำนวนมากที่โดยทั่วไปมักเชื่อมโยงกับภาวะผู้นำถูกมอบหมายอย่างชัดเจนให้ผู้อื่น
- Debian Project Leader ในยุคแรก ๆ แทบจะเป็นเผด็จการที่มีอำนาจเต็มจนกว่าจะลงจากตำแหน่งเอง
- หลังจากผู้นำโปรเจกต์คนหนึ่งล้ำเส้นและลาออกเพราะแรงต่อต้าน จึงมีการนำระบอบประชาธิปไตยเข้ามา
- Debian กำหนดกฎของโปรเจกต์ไว้ใน รัฐธรรมนูญ อย่างเป็นทางการ
- ระบบกฎในปัจจุบันมีที่มาจากประสบการณ์ในช่วงต้นของประวัติศาสตร์ว่า กฎที่น้อยกว่า และ ระบบราชการที่น้อยกว่า ไม่ได้ทำงานได้ดีใน Debian
สัญญาทางสังคมและ Debian Free Software Guidelines
- ช่วงกลางทศวรรษ 1990 เป็นช่วงก่อนที่คำว่า “open source” จะถูกนำมาใช้ ส่วน “free software” นั้น Free Software Foundation เป็นผู้ให้นิยาม แต่ยังมีช่องให้ตีความได้มาก
- Debian ต้องการกฎที่ชัดเจนขึ้น จึงสร้าง Debian Free Software Guidelines(DFSG) และทำให้เป็นส่วนหนึ่งของ สัญญาทางสังคม
- สัญญาทางสังคมเป็นเอกสารพื้นฐานที่ Debian ใช้ประกาศคำมั่นว่า Debian คืออะไรและทำอะไร ทั้งต่อตัวเองและต่อโลก
- DFSG เป็นส่วนหนึ่งของเอกสารนั้น
- รัฐธรรมนูญของ Debian ตั้งใจทำให้การแก้ไขสัญญาทางสังคมเป็นเรื่องยาก
- กฎที่ละเอียดขึ้นช่วยให้ชัดเจนว่า Debian จะยอมรับอะไร และทำให้การถกเถียงที่เกี่ยวข้องง่ายขึ้น
- ต่อมา DFSG กลายเป็นพื้นฐานของ Open Source Definition
หลักการบิลด์แบบพึ่งพาตนเอง
- Debian ยึดมั่นในหลักการ พึ่งพาตนเอง(self-contained)
- ทุกสิ่งที่ Debian แพ็กเกจต้องบิลด์โดยใช้เฉพาะ dependency ภายใน Debian เท่านั้น
- ทุกสิ่งภายใน Debian ต้องถูก Debian บิลด์เองโดยตรง
- หลักการนี้อาจสร้างงานเพิ่มเติมจำนวนมาก
- เครื่องมือภาษาโปรแกรมในปัจจุบันมักสมมติว่าจะดาวน์โหลด dependency จากคลังออนไลน์ในช่วงบิลด์
- ใน Debian วิธีนั้นไม่ถูกอนุญาต
- เหตุผลหลักคือ dependency ภายนอกอาจหายไปในภายหลัง
- Debian ไม่ได้ควบคุมคลังแพ็กเกจของบุคคลที่สาม
- หากแพ็กเกจหรือทั้งคลังหายไป Debian อาจไม่สามารถบิลด์แพ็กเกจนั้นใหม่ได้
- การอัปเกรดคอมไพเลอร์ใหม่ การแก้ปัญหาความปลอดภัย การพอร์ตไปยังสถาปัตยกรรมใหม่ และการนำการแก้บั๊กเข้ามา ล้วนต้องอาศัยการรีบิลด์
- หากไม่พึ่งพาตนเอง ในเวลาที่ต้องแก้ความปลอดภัยเร่งด่วน แพ็กเกจนับหมื่นและ dependency ทั้งหมดจะต้องพร้อมใช้งาน Debian จึงเลือกแพ็กเกจ dependency ทั้งหมดเอง
เหตุผลที่หลีกเลี่ยงไลบรารีแบบ bundle
- Debian หลีกเลี่ยงการใช้สำเนาไลบรารีหรือสำเนา dependency อื่น ๆ ที่รวมมากับซอฟต์แวร์ที่จะนำมาแพ็กเกจ
- โปรเจกต์ upstream จำนวนมากมองว่าการรวม dependency มาด้วยหรือจัดการแบบ vendor นั้นง่ายกว่า
- ในมุมของ Debian อาจเกิดสำเนาของไลบรารียอดนิยมหลายชุด
- หากไลบรารีนั้นมีปัญหาความปลอดภัยหรือปัญหาร้ายแรง ต้องค้นหาและแก้ไขสำเนาทั้งหมด
- ในกรณีปัญหาความปลอดภัยเร่งด่วน งานนี้ทำให้เสียเวลาอันมีค่า
- ในกรณีของ zlib Debian พบสำเนา zlib ที่ bundle อยู่ภายใน archive หลายสิบชุด และทุ่มความพยายามอย่างมากเพื่อทำให้แพ็กเกจ Debian ใช้เฉพาะเวอร์ชัน zlib ที่ถูกแพ็กเกจไว้ใน Debian
- ดังนั้น Debian จึงทำงานล่วงหน้าในขั้นตอนการแพ็กเกจก่อนเกิดเหตุฉุกเฉิน เพื่อให้แพ็กเกจใน Debian ใช้เวอร์ชันของไลบรารีที่ถูกแพ็กเกจไว้ใน Debian
- นักพัฒนา upstream บางครั้งต้องการดูแลเฉพาะเวอร์ชัน bundle ที่ตนตรวจสอบแล้ว วิธีนี้จึงก่อให้เกิดความขัดแย้งกับ Debian เป็นครั้งคราว
กระบวนการตรวจสอบสมาชิก
- เนื่องจาก Debian เป็นระบบปฏิบัติการที่มีขนาดใหญ่ ซับซ้อน และถูกใช้งานอย่างแพร่หลาย จึงต้องไว้วางใจสมาชิกของตน
- ความไว้วางใจต่อผู้ที่อัปโหลดแพ็กเกจใหม่มีความสำคัญเป็นพิเศษ
- เนื่องจากข้อจำกัดทางเทคนิคของ Linux ในทศวรรษ 1990 แพ็กเกจ Debian ทุกแพ็กเกจมีสิทธิ์เข้าถึง root เต็มรูปแบบระหว่างขั้นตอนติดตั้ง
- นักพัฒนา Debian ทุกคนอาจกลายเป็นผู้ใช้ root บนเครื่องใดก็ตามที่รัน Debian ได้
- เมื่อคำนึงว่า Debian ทำงานอยู่บนเครื่องหลายสิบล้านเครื่อง นี่คืออำนาจที่ใหญ่มาก
- สมาชิกใหม่ถูกตรวจสอบได้หลายวิธี
- ตามอุดมคติ ควรมีส่วนร่วมในชุมชนนักพัฒนา Debian มานานพอจนเป็นที่รู้จักของผู้อื่น
- ต้องสร้างความเชื่อถือภายในชุมชน
- กระบวนการนี้อาจทำให้ผู้ที่ต้องการเข้าร่วม Debian โดยเฉพาะผู้ที่คุ้นเคยกับโปรเจกต์โอเพนซอร์สขนาดเล็กกว่า รู้สึกอึดอัดพอสมควร
ชื่อรหัสของรีลีส
- Debian ตั้ง ชื่อรหัส ให้กับรีลีสหลักแต่ละรุ่น
- แนวปฏิบัตินี้เดิมเกิดขึ้นเพื่อลดต้นทุนการ mirror archive แพ็กเกจ Debian
- ช่วงกลางทศวรรษ 1990 ขณะเตรียมรีลีส Debian 1.0 มีการสร้างไดเรกทอรีด้วยชื่อเวอร์ชันโดยไม่ใช้ชื่อรหัส
- เนื่องจากการพัฒนารีลีสใหม่ต้องใช้เวลา ไดเรกทอรี “1.0” จึงถูกสร้างไว้ล่วงหน้า
- ผู้จัดพิมพ์ CD-ROM รายหนึ่งผลิตดิสก์จำนวนมากตั้งแต่เนิ่น ๆ โดยระบุว่าเป็น “1.0” ก่อนที่ Debian 1.0 จะเสร็จสมบูรณ์
- ผลคือผู้ที่ได้รับ CD-ROM Debian 1.0 ได้รับสิ่งที่ไม่ใช่ 1.0 จริง
- วิธีแก้ที่เรียบง่ายคือเตรียมงานในไดเรกทอรีอย่าง “1.0-not-released” แล้วเปลี่ยนชื่อเป็น “1.0” หลังรีลีสเสร็จ
- แต่หากชื่อไดเรกทอรีเปลี่ยน mirror ทุกแห่งจะต้องดาวน์โหลดรีลีสใหม่ทั้งหมด ซึ่งในขนาดของ Debian ตอนนั้นมีต้นทุนสูง
- ขนาดในตอนนั้นอยู่ระดับ “แพ็กเกจหลายร้อยรายการ” และ “หลายสิบ MB”
- ต่อมามีการเพิ่ม โครงสร้าง pool เข้าไปใน archive ของ Debian
- ไฟล์ของทุกรีลีสอยู่ใน tree ไดเรกทอรีเดียวกัน และไฟล์ metadata เป็นตัวระบุว่าไฟล์ใดเป็นของรีลีสใด
- โครงสร้างนี้ทำให้การ mirror ง่ายขึ้น
- ปัจจุบันอาจเป็นไปได้ที่จะเลิกใช้ชื่อรหัสแล้วใช้เฉพาะเวอร์ชัน แต่ไม่อาจรู้ได้ว่า Debian จะสนใจหรือไม่
เหตุผลที่ Debian เปลี่ยนแปลงช้า
- Debian เป็นโปรเจกต์ขนาดใหญ่มาก และโปรเจกต์ขนาดใหญ่ย่อมเปลี่ยนแปลงช้า
- การเปลี่ยนแปลงที่ส่งผลต่อแพ็กเกจจำนวนมากอาจต้องให้อาสาสมัครหลายร้อยคนทำงาน จึงเดินหน้าได้ยากอย่างรวดเร็ว
- งานบางอย่างสามารถให้คนจำนวนน้อยจัดการได้ และ Debian มีกระบวนการที่ทำให้สิ่งนี้เป็นไปได้
- ตัวอย่างเช่น เมื่อมีการอัปโหลด GNU C compiler เวอร์ชันใหม่ งานค้นหาสิ่งที่ต้องแก้ในแพ็กเกจอื่น ๆ โดยปกติสามารถทำได้โดยคนจำนวนน้อย
- อีกเหตุผลที่การเปลี่ยนแปลงใช้เวลานานคือจำเป็นต้องสร้างฉันทามติ
- ฉันทามติต้องอาศัยการอภิปรายอย่างกว้างขวาง
- การอภิปรายแบบนี้ใช้เวลา และแทบจะย่นเวลาได้ไม่บ่อยนัก
- นักพัฒนา Debian มักมีแนวทางอนุรักษนิยมในการตัดสินใจทางเทคนิค
- หลายครั้งพวกเขาชอบทางออกที่ไม่ต้องการการเปลี่ยนแปลงขนาดใหญ่
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
Self-contained และ ไม่มีไลบรารีแบบบันเดิล เป็นแนวคิดสำคัญที่บางส่วนของระบบนิเวศมองข้ามไปเพราะเห็นว่ายุ่งยากเกินไป
หลังจากต้องเจอกับปัญหาที่เกิดจากผลลัพธ์นั้นอีกครั้ง จึงค่อยตั้งคำอย่าง “ซัพพลายเชนซอฟต์แวร์” ขึ้นมา แต่ Debian ทำมาในแนวทางที่หลีกเลี่ยงปัญหาเหล่านี้ตั้งแต่แรก จึงเจ็บปวดน้อยกว่า
หากต้องกระจายซอฟต์แวร์ข้ามหลายดิสโทรและหลายระบบปฏิบัติการ การบันเดิล dependency ก็สมเหตุสมผล ส่วนในมุมของผู้ดูแลดิสโทร shared library ที่ทำให้แพตช์ความปลอดภัยได้เพียงครั้งเดียว ย่อมดีกว่าอย่างชัดเจน
ในระดับระบบปฏิบัติการมีกระแสอย่าง Nix และ Silverblue ส่วนในระดับแอปพลิเคชันก็มี Snaps และ Flatpak ผมไม่รู้ทางแก้ แต่ดูเหมือน Debian เองก็คงต้องทำอะไรบางอย่างในเร็ว ๆ นี้
หากจะใช้เวอร์ชันอื่นก็ต้องทดสอบอย่างรอบคอบและแก้บั๊กที่พบ แต่ไม่แน่ใจว่า Debian มีทรัพยากรพอทำแบบนั้นหรือไม่ สุดท้ายก็เท่ากับใช้ ชุดไลบรารีที่ยังไม่ได้ผ่านการตรวจสอบ แล้วหวังว่าจะทำงานได้ดี ซึ่งดูไม่น่าจะเป็นเช่นนั้น
มานานแล้วที่เฟิร์มแวร์เปิดจากคลัง linux-firmware ถูกนำมาแจกจ่ายเฉพาะไบนารีโดยไม่ได้ build จากซอร์ส และใน archive ก็น่าจะมีกรณีคล้ายกันอีก
Debian ก็ไม่ได้ลบไฟล์ที่ถูกสร้างขึ้นจาก tarball ทุกตัวอย่างเป็นระบบแล้วสร้างใหม่เสมอไป โดยเฉพาะฝั่ง AI/ML ที่อาจไม่ได้แม้แต่ข้อมูลสำหรับฝึก และต้นทุนการฝึกก็ยากจะรับไหว
https://wiki.debian.org/EmbeddedCopies
องค์กรซอฟต์แวร์โอเพนซอร์สบางแห่งไม่ได้แค่ยอดเยี่ยมเล็กน้อย แต่ถึงขั้นน่าทึ่งพอจะแสดงให้เห็นว่า วิธีที่ผู้คนร่วมมือกันอาจเหนือกว่าโมเดลองค์กรแบบบริษัททั่วไปได้มาก
ผมใช้ Debian มานานมาก แต่ไม่ค่อยรู้เรื่ององค์กรของมัน บทความนี้จึงเป็นบทนำที่ดี
IETF ก็เป็นองค์กรที่แทบจะสร้างอินเทอร์เน็ตขึ้นมา แต่ไม่มีแม้แต่สมาชิก แค่ดำเนินไปได้เอง และน่าประหลาดใจที่องค์กรแบบนี้ไม่ค่อยเป็นที่รู้จัก
Protocol Wars ที่โลกธุรกิจพยายามเข้าควบคุมวิธีการทำงานของอินเทอร์เน็ตด้วยการแข่งกับ IETF ก็น่าสนใจ: https://en.wikipedia.org/wiki/Protocol_Wars
เคยมีช่วงที่ OSI ประกาศโครงการทุกเดือนว่าจะเอาโปรโตคอล X. มาแทนที่บางส่วนของอินเทอร์เน็ตอย่าง TCP แต่สิ่งที่รอดและเติบโตได้จริง ๆ ก็มีราว ๆ X.509
ผมสงสัยว่าองค์กรความร่วมมือแบบประชาธิปไตยเช่นนี้เหนือกว่าโมเดลองค์กรธุรกิจแบบดั้งเดิมจริง ๆ มากแค่ไหน
ถ้ามองในแง่ขนาดเศรษฐกิจ รายได้ของ IETF หรือ Debian เทียบกับบริษัทไม่ได้เลย แต่ในมุมของผู้ร่วมสนับสนุนและผู้สร้างสรรค์ ก็ต้องถามว่า “ใครได้ประโยชน์?” และผู้ร่วมสนับสนุนก็อยู่กันแบบพอประคองตัว
ดูคุ้มค่าที่จะทดลองว่าโมเดลแบบ IETF หรือ Debian จะแข่งขันกับโมเดลบริษัทได้หรือไม่ และใน Protocol Wars มันก็เคยได้ผลจริงมาแล้วครั้งหนึ่ง
ในคณะทำงานของ IETF มีวิศวกรจากผู้ขายภาคธุรกิจจำนวนมากที่ต้องการร่วมมือกันเพื่อให้เกิด interoperability ขณะที่ ISO ใกล้เคียงกับองค์กรแบบบนลงล่างที่รัฐนำตามแบบดั้งเดิมมากกว่า
ใช้ Ubuntu มาราว 13 ปี แล้วปีนี้ย้ายมา Debian และค่อนข้างชอบ
เมื่อก่อนมองว่าโมเดลแพ็กเกจแบบอัปเดตทั้งระบบทำให้รู้ได้ยากว่าเกิดอะไรขึ้น และบางครั้งก็มี version conflict จึงไม่ใช่วิธีที่มั่นคงที่สุดในเชิงเทคนิค
แต่เมื่อเวลาผ่านไป ก็เริ่มให้คุณค่ากับ ความเสถียรของ Debian และเจตนาดีของโปรเจกต์มากขึ้น
บางครั้งวัตถุประสงค์และเป้าหมายของโปรเจกต์ก็สำคัญกว่าความเหนือชั้นทางเทคนิค
แม้จะไม่พอใจกับตัวเลือกเชิงเทคนิคบางอย่าง เช่น วิธีที่ daemon เริ่มทำงานอัตโนมัติหลังติดตั้ง แต่ประโยชน์จาก ความสม่ำเสมอ ของแพ็กเกจและการอัปเกรดโดยรวมมีมากกว่า
Apt ก็เป็น package manager ที่ยอดเยี่ยมจริง ๆ
แม้ในสถานะพื้นฐานก็เร็ว และยังรองรับสถานการณ์ที่ค่อนข้างจุกจิกได้ เช่น ใช้ระบบเป็น stable แต่ใช้เฉพาะ Nginx เวอร์ชันใหม่จาก backports
ชอบความรู้สึกที่ได้ฟีเจอร์ใหม่เฉพาะหนึ่งหรือสองแพ็กเกจที่ใส่ใจ ส่วนที่เหลือปล่อยให้เสถียรและน่าเบื่อต่อไป
เหตุผลหลักคือใช้ เทคโนโลยีที่น่าเบื่อและเก่า แต่ทำงานได้ดี และไม่ต้องเห็น netplan, snapd, systemd-resolver อีกต่อไป
ตราบใดที่ไม่ได้ดึงมาจาก Sid หรือทำอะไรสนุก ๆ อย่างอัปเกรด libc6 ถ้าทุกอย่างติดตั้งผ่าน apt ปกติแล้วไม่ควรเห็น version conflict
LIW ลืมส่วนสำคัญไปอย่างหนึ่ง: Debian เป็น องค์กรอาสาสมัคร ดังนั้นไม่มีใครบังคับให้อาสาสมัครทำสิ่งที่ไม่อยากทำได้
ผู้คนที่ไม่ได้ถูกบังคับสร้างโครงสร้างประชาธิปไตยแบบหลวม ๆ และหมุนเวียนกันเพื่อการตัดสินใจ และการพึ่งพาตนเองที่เกิดจากการใช้ทรัพยากรอย่างระมัดระวังดูเป็นแกนหลักขององค์กร
สำหรับผม ความขัดแย้งนั้นเปลี่ยนแนวคิดว่า “Debian คืออะไร” ไปอย่างถาวร และมันดีหรือไม่ดีก็ขึ้นอยู่กับว่าคุณฟังใคร
แม้ในองค์กรแบบนี้ หากไม่ทำตามที่คนอื่นบอก แน่นอนว่าสุดท้ายก็ต้องออกไปนอกประตู
บางครั้งก็จินตนาการว่ามีเงินก้อนใหญ่พอจนไม่ต้องกังวลเรื่องเงินเลย
เวลาแบบนั้นผมมักจะวางแผนเสมอว่าจะบริจาคให้โปรเจกต์โอเพนซอร์สไหนบ้าง และ Debian ก็มักอยู่ในกลุ่มตัวเลือกแรก ๆ เสมอ
ตอนนี้ก็เหลือแค่ต้องมีเงินเท่านั้น แน่นอนว่าระหว่างนี้ผมก็ยังบริจาคให้ Debian อยู่
แบบนั้นสนุกกว่ากันเยอะ
Debian อาจยอดเยี่ยมก็ได้ แต่มีปัญหาเรื่อง การรองรับไดรเวอร์ และดูเหมือนจะยอมรับเรื่องนี้แบบไม่ค่อยเต็มใจนัก
https://www.reddit.com/r/debian/comments/paxj85/why_debian_w...
“เรายอมรับว่าผู้ใช้บางส่วนจำเป็นต้องใช้โปรแกรมที่ไม่สอดคล้องกับ Debian Free Software Guidelines เราจึงสร้างพื้นที่ contrib และ non-free ในคลัง FTP สำหรับซอฟต์แวร์เหล่านี้”
เมื่อ 1–2 ปีก่อนผมเคยรัน Debian บนเครื่องหลายเครื่อง แล้วพอมีอัปเดต WiFi เข้ามาก็ใช้งานไม่ได้ พอลองดูเรื่อง rollback และวิธีต่าง ๆ สุดท้ายก็เปลี่ยนไปใช้ Ubuntu หรือจริง ๆ คือ Kubuntu แล้วทุกอย่างก็ทำงานได้ดี ไม่มีปัญหา
Debian 12 ถึงขั้นสร้าง repository non-free-firmware แยกต่างหาก เพื่อให้สาย free software แบบเคร่ง ๆ สามารถยอมผ่อนปรนเฉพาะ ไดรเวอร์ที่ไม่เสรี เพื่อให้ใช้ฮาร์ดแวร์ได้
ถ้าเป็นระบบที่ติดตั้งไปแล้ว ก็น่าจะแก้ได้ด้วยการเปิด repository non-free แล้วติดตั้ง linux-firmware หรือแพ็กเกจ firmware-* ที่เฉพาะเจาะจงกว่าสำหรับฮาร์ดแวร์นั้น ๆ
เคยทำงานร่วมกับ Ian Murdock ที่ Purdue ช่วงรีลีสแรก ๆ
เขาเป็นทั้งผู้ดูแลระบบและนักพัฒนา ส่วนผมเป็นเว็บดีไซเนอร์ของห้องสมุด
เขาเชื่อในแนวทาง GNU/Linux และซอฟต์แวร์ “เสรีภาพแบบเสรีภาพในการพูด” อย่างจริงใจ
แรงขับเคลื่อนช่วงแรกมาจากความยากของการทำแพ็กเกจและการจัดการแพ็กเกจ และนี่อาจเป็นผลงานสำคัญที่สุดของเขา
เขายังมีความสนใจในแนวคิดคล้ายโครงสร้างพื้นฐาน P2P ที่ชื่อ Network-of-Workstations หรือ NOW แต่ก็ไม่เคยตั้งหลักได้จริง
คนที่เขาส่งไม้ต่อให้คือ Bruce Perens ซึ่งเป็นผู้นำแบบใช้อำนาจตามที่บทความกล่าวถึง
ผมชอบเขานะ เป็นสไตล์การบริหารแบบ old guard คล้าย Linus Torvalds และสไตล์แบบนั้นใช้ได้ผลกับโปรเจกต์ใหญ่และซับซ้อนที่มีอาสาสมัครจำนวนมาก
ยุค Linux และ Debian สมัยก่อนสนุกมากจริง ๆ แม้ผมจะไม่ได้ลงลึกเท่าคนอื่น ๆ แต่ก็คิดถึงช่วงเวลานั้น
เดี๋ยวนี้มีคนที่ได้กลิ่นเงินเข้ามามากเกินไป ก็เป็นไปตามนั้นแหละ
แถลงการณ์ของ Ian อธิบายทุกอย่างไว้แล้ว: https://www.debian.org/doc/manuals/project-history/manifesto...
ผมไม่เคยได้ยินเรื่องนี้มาก่อน และ Google ก็ไม่ค่อยช่วยอะไร
เส้นทางของเขาหลังลงจากตำแหน่งจนถึงเสียชีวิตดูค่อนข้างไม่มั่นคง
เป็นข้อความที่เก่ากว่าผมเสียอีก
Debian เหมือน Toyota
เชื่อถือได้แต่น่าเบื่อ แถมยังสร้างโดยอาสาสมัครด้วย
เพราะนโยบายของ Debian บางครั้งจึงมี RetroArch เวอร์ชันที่ถูกจำกัดไว้มาก แทนที่จะเป็นเวอร์ชันจริง
RetroArch มีฟีเจอร์จัดการแพ็กเกจของตัวเองชื่อ “Core Updater” ใช้ดาวน์โหลดและติดตั้งอีมูเลเตอร์ในรูปไฟล์ไลบรารี แต่ Debian ห้ามไว้เพราะมองว่านี่เป็นการเลี่ยงระบบจัดการแพ็กเกจทั้งหมด
อย่างไรก็ดี ถ้าติดตั้ง dependency ของซอร์สแพ็กเกจ Debian แล้วบิลด์จากซอร์สโค้ดต้นฉบับ ก็สามารถบิลด์ RetroArch ที่มีฟีเจอร์ครบได้เอง
ผมได้บทเรียนแบบยาก ๆ ตอนพยายามรัน Kodi กับ RetroArch แต่นอกเหนือจากนั้นก็เป็นระบบปฏิบัติการที่ยอดเยี่ยม
โดยส่วนตัวแล้วชอบและใช้งาน Debian เพราะหลักการและความเสถียรของมัน
เคยได้ยินผู้ใช้ดิสโทรอื่นหรือบางโปรเจกต์ต้นน้ำบ่นว่า Debian “แก้ไข” แพ็กเกจ
อยากฟังคำอธิบายว่าจริงหรือไม่ และถ้าใช่ก็น่าจะมีเหตุผลที่ดีแน่ ๆ
ประเภทแรกคือแพตช์ที่ทำให้ซอฟต์แวร์ทำงานในแบบที่ Debian ต้องการ เช่น เก็บการตั้งค่าไว้ใน /etc/ ไม่ดาวน์โหลดเพิ่มเติมระหว่างรัน และใช้ไลบรารีของระบบแทนไลบรารีที่บันเดิลมาด้วย
ประเภทที่สองคือ security backport
Debian จะตรึงฟีเจอร์ไว้ตอนออกรุ่นและให้เฉพาะอัปเดตความปลอดภัย แต่ทุกวันนี้ซอฟต์แวร์จำนวนมากมักรวมการแก้ไขความปลอดภัยไว้ในรีลีสใหม่พร้อมกับฟีเจอร์ใหม่
เมื่อสองประเภทนี้รวมกัน ความแตกต่างระหว่าง 1.2 ของ Debian กับ 1.2 “ตัวจริง” ก็จะมากขึ้น และทำให้การจัดการรายงานบั๊กยากขึ้น
เช่น ได้รับรายงานบั๊กของ 1.2-Debian แต่โปรเจกต์ต้นน้ำรองรับแค่ 1.4 “ตัวจริง” ที่มาพร้อมชุดไลบรารีที่อัปเดตแล้ว เป็นต้น
ประเภทที่สามเป็นแนวทางที่ทุกวันนี้หายไปมากแล้ว คือกรณีที่ Debian ตัดสินว่าแก้แพตช์แล้วจะทำให้ซอฟต์แวร์ดีขึ้น
สิ่งนี้เคยก่อให้เกิดปัญหาอย่างการตัดความสุ่มออกจากคีย์ SSH: https://github.com/g0tmi1k/debian-ssh
แบบหนึ่งคือแนวทาง เวอร์ชันแบบค่อยเป็นค่อยไป เหมือน Chrome ที่แทบไม่มีรีลีสแก้บั๊กแยกต่างหาก และการแก้บั๊กจะถูกรวมอยู่ในเวอร์ชันใหม่
อีกแบบคือแนวทางที่ยึดเวอร์ชันหลักเป็นศูนย์กลาง เช่น semantic versioning ที่มีเวอร์ชัน 1 และ 2 และแม้หลังจากเวอร์ชัน 2 ออกแล้ว ก็ยังมี 1.1 ที่นำเฉพาะการแก้บั๊กไปใช้กับเวอร์ชัน 1
โดยพื้นฐานแล้ว Debian ทำงานได้ดีกับแนวทางที่สองเท่านั้น
เพราะ Debian รักษาเสถียรภาพของ API จึงไม่เข้ากับซอฟต์แวร์ที่พัฒนาด้วยแนวทางแรก
เพื่อเลี่ยงปัญหานี้ Debian จึง backport “การแก้ไข” จากเวอร์ชัน 3 ไปยังเวอร์ชัน 1 แล้วสร้าง 1.debian-2 ของตัวเอง
ปัญหาคือตอนนี้โปรเจกต์ต้นน้ำจะได้รับบั๊กที่เกี่ยวกับพฤติกรรมซึ่งตัวเองไม่เคยรีลีสมาก่อนเลย
Debian มีเสรีภาพที่จะทำเช่นนั้นก็จริง แต่โปรเจกต์ต้นน้ำก็มีเสรีภาพที่จะไม่พอใจกับภาระงานเพิ่มเติมที่ Debian โยนมาให้เช่นกัน
หากจำเป็นก็จะแพตช์โปรเจกต์ต้นน้ำที่ไม่สอดคล้องกับความคาดหวังนั้น และการที่สามารถทำเช่นนั้นได้ทันทีนี่แหละคือหัวใจของซอฟต์แวร์เสรี
ดู https://www.debian.org/security/2008/dsa-1571 ได้