Systemd ได้รับการตอบรับที่หลากหลายแม้จะมีการนำไปใช้อย่างแพร่หลาย ขณะที่ชุมชน Linux ถกเถียงเรื่องประสิทธิภาพและความซับซ้อน

ทีมชุมชน BigGo
Systemd ได้รับการตอบรับที่หลากหลายแม้จะมีการนำไปใช้อย่างแพร่หลาย ขณะที่ชุมชน Linux ถกเถียงเรื่องประสิทธิภาพและความซับซ้อน

ชุมชน Linux ยังคงต่อสู้กับบทบาทของ systemd ในดิสทริบิวชันสมัยใหม่ แม้ว่าระบบ init นี้จะกลายเป็นตัวเลือกเริ่มต้นสำหรับดิสทริบิวชัน Linux หลักส่วนใหญ่ในช่วงทศวรรษที่ผ่านมา ในขณะที่ผู้ใช้บางส่วนได้ยอมรับความสามารถของมัน แต่คนอื่นๆ ยังคงวิพากษ์วิจารณ์ปรัชญาการออกแบบและลักษณะประสิทธิภาพของมัน

ความกังวลด้านประสิทธิภาพของระบบบันทึก Journald

หนึ่งในแง่มุมที่ถกเถียงกันมากที่สุดของ systemd คือระบบบันทึกแบบไบนารี journald การอภิปรายในชุมชนเผยให้เห็นปัญหาประสิทธิภาพที่สำคัญซึ่งส่งผลต่อการดำเนินงานประจำวัน ผู้ใช้รายงานว่าการสืบค้น journald อาจช้ากว่าวิธีการบันทึกแบบข้อความดั้งเดิมอย่างมาก โดยบางคนประสบกับประสิทธิภาพที่ช้ากว่า 40 เท่าเมื่อเปรียบเทียบกับการดำเนินการ grep แบบง่ายๆ บนไฟล์ข้อความธรรมดา สิ่งนี้ทำให้ผู้ดูแลระบบหลายคนปิดใช้งาน journald ทั้งหมดเพื่อใช้ไฟล์บันทึกข้อความแบบหมุนเวียนดั้งเดิมแทน

รูปแบบไบนารีของระบบบันทึกยังสร้างความท้าทายด้านความเข้ากันได้กับเครื่องมือจัดการบันทึกที่มีอยู่ บริการยอดนิยมหลายรายการเช่น AWS CloudWatch ขาดการสนับสนุน journald แบบเนทีฟ ทำให้ผู้ดูแลระบบต้องใช้วิธีแก้ไขปัญหาหรือรักษาระบบบันทึกคู่

ปัญหาด้านประสิทธิภาพของ Systemd ที่ผู้ใช้รายงาน:

  • การค้นหาข้อมูลใน Journald: ช้ากว่าการใช้ grep กับไฟล์ข้อความถึง 40 เท่า
  • ความเข้ากันได้ของรูปแบบ binary log: การรองรับที่จำกัดในเครื่องมือหลักอย่าง AWS CloudWatch
  • พฤติกรรมการ boot/shutdown: มีรายงานการค้างแบบสุ่มและปัญหา race conditions
  • การใช้หน่วยความจำ: ใช้ทรัพยากรสูงกว่าระบบ init แบบดั้งเดิม

การจัดการบริการได้รับการยกย่องแม้จะมีการวิพากษ์วิจารณ์ในวงกว้าง

ในขณะที่ journald เผชิญกับการวิพากษ์วิจารณ์ ฟังก์ชันการจัดการบริการหลักของ systemd ได้รับการยกย่องอย่างกว้างขวางจากผู้ดูแลระบบ การเปลี่ยนผ่านจากสคริปต์ init แบบเชลล์ที่ซับซ้อนไปสู่ไฟล์กำหนดค่าแบบประกาศได้ทำให้การสร้างและจัดการบริการง่ายขึ้นอย่างมาก ผู้ใช้เน้นคุณสมบัติต่างๆ เช่น การทำความสะอาดกระบวนการอัตโนมัติผ่านกลุ่มควบคุม การจัดการการพึ่งพาที่ปรับปรุงแล้ว และตัวเลือก security sandboxing ในตัว

ผมทำงานเป็น sysadmin/devops มาเป็นจำนวนปีสองหลัก ตลอดบริษัทต่างๆ งานต่างๆ และผู้ร่วมงานที่เป็นนักสะสม - ผมไม่เคยพบใครที่ไม่ชอบ systemd อย่างน้อย หากไม่ได้ร้องเพลงสรรเสริญมัน

ฟังก์ชัน timer ซึ่งทำหน้าที่เป็นการทดแทน cron สมัยใหม่ ยังได้รับความคิดเห็นเชิงบวกสำหรับความยืดหยุ่นและการผสานรวมกับระบบนิเวศ systemd ที่กว้างขึ้น

ส่วนประกอบสำคัญของการจัดการเซอร์วิสของ systemd ในระบบ Linux
ส่วนประกอบสำคัญของการจัดการเซอร์วิสของ systemd ในระบบ Linux

การกำหนดค่าเครือข่ายและความขัดแย้งในการตั้งชื่อ

แนวทางของระบบนิเวศ systemd ต่อการตั้งชื่ออุปกรณ์เครือข่ายได้สร้างความหงุดหงิดอย่างต่อเนื่องสำหรับผู้ดูแลระบบ คุณสมบัติชื่ออินเทอร์เฟซเครือข่ายที่คาดเดาได้ ซึ่งออกแบบมาเพื่อแก้ปัญหาการตั้งชื่ออุปกรณ์ที่ไม่สอดคล้องกัน กลับนำความซับซ้อนใหม่มาแทน ดิสทริบิวชันต่างๆ ใช้รูปแบบการตั้งชื่อที่แตกต่างกัน ทำให้เกิดความสับสนเมื่อย้ายระหว่างระบบหรือใช้สภาพแวดล้อมกู้ภัยแบบสด

ผู้ใช้ยังรายงานปัญหากับส่วนประกอบเสริมของ systemd เช่น systemd-resolved ซึ่งจัดการการแปลงที่อยู่ DNS ในขณะที่ผู้ดูแลระบบบางคนชื่นชมแนวทางที่เป็นหนึ่งเดียว คนอื่นๆ พบว่าส่วนประกอบเหล่านี้ใช้งานได้เพียงครึ่งเดียวและชอบโซลูชันดั้งเดิมที่พิสูจน์ความน่าเชื่อถือมาหลายทศวรรษ

รูปแบบการตั้งชื่อ Network Interface:

  • แบบดั้งเดิม: eth0, eth1, eth2...
  • รูปแบบ systemd สมัยใหม่:
    • ens123 (จัดลำดับตาม bus)
    • enp17s7f9 (อิงตาม PCI slot)
    • enx8b220b34 (อิงตาม MAC address)
    • ความแตกต่างในการนำไปใช้ขึ้นอยู่กับ Distribution

อิทธิพลขององค์กรและการถกเถียงปรัชญา

นอกเหนือจากความกังวลทางเทคนิค การอภิปรายในชุมชนเผยให้เห็นความไม่เห็นด้วยทางปรัชญาที่ลึกซึ้งเกี่ยวกับการพัฒนาและการนำ systemd ไปใช้ ผู้ใช้บางคนแสดงความกังวลเกี่ยวกับอิทธิพลของ Red Hat (ปัจจุบันคือ IBM ) ต่อส่วนประกอบระบบที่สำคัญนี้ โดยมองว่าเป็นการควบคุมขององค์กรต่อโครงสร้างพื้นฐานหลักของ Linux นักวิจารณ์เหล่านี้โต้แย้งว่าแนวทางแบบ monolithic ของ systemd ขัดแย้งกับปรัชญา Unix ดั้งเดิมของเครื่องมือขนาดเล็กที่มุ่งเน้น

ระบบ init ทางเลือกเช่น OpenRC ยังคงรักษาฐานผู้ใช้ที่ทุ่มเท โดยเฉพาะในหมู่ผู้ที่ชอบแนวทาง Unix ดั้งเดิม อย่างไรก็ตาม ผลกระทบเครือข่ายของการนำ systemd ไปใช้อย่างแพร่หลายทำให้การเปลี่ยนแปลงยากขึ้นเรื่อยๆ เนื่องจากซอฟต์แวร์มากขึ้นสันนิษฐานการมีอยู่ของมัน

ระบบ Init ทางเลือกที่ยังคงใช้งานอยู่:

  • OpenRC: ใช้โดย Gentoo, Alpine Linux, Artix
  • s6: ระบบสมัยใหม่ที่ใช้ daemontools เป็นฐาน
  • runit: ใช้โดย Void Linux
  • BSD init: ระบบ init แบบดั้งเดิมของ Unix
  • Upstart: ระบบเก่าของ Ubuntu (ส่วนใหญ่เลิกใช้แล้ว)

มองไปข้างหน้า

แม้จะมีการถกเถียงอย่างต่อเนื่อง ประโยชน์เชิงปฏิบัติของ systemd ในการปรับใช้ขนาดใหญ่และชุดคุณสมบัติที่กว้างขวางได้รักษาตำแหน่งของมันในระบบนิเวศ Linux การอภิปรายสะท้อนความตึงเครียดที่กว้างขึ้นในซอฟต์แวร์โอเพนซอร์สระหว่างนวัตกรรมและประเพณี การสนับสนุนจากองค์กรและการควบคุมของชุมชน เมื่อ Linux ยังคงพัฒนาต่อไป การถกเถียง systemd ทำหน้าที่เป็นกรณีศึกษาในวิธีที่การเปลี่ยนแปลงระบบพื้นฐานส่งผลกระเทือนผ่านระบบนิเวศทั้งหมด

อ้างอิง: systemd has been a complete, utter, unmitigated success