Flatpak เตรียมพึ่งพา systemd

 (osnews.com)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Flatpak เคยชูจุดเด่นว่าเป็น “การสร้างแอปสำหรับทุกดิสโทร” แต่ในเวอร์ชันหลักถัดไปมีแนวโน้มสูงว่าจะเกิด การพึ่งพา systemd
  • Flatpak Next หรือ Flatpak 2.0 เป็นงานที่ใกล้เคียงกับการเขียนใหม่เพื่อก้าวข้ามข้อจำกัดของสถาปัตยกรรมเดิมใน 1.x ที่มีอายุ หลายสิบปี และยังอยู่ในขั้นวางแผน
  • บริการใหม่ systemd-appd จะรับบทบาทสำคัญในการเก็บตัวระบุแอปและสิทธิ์การใช้งาน ให้คอมโพเนนต์อื่นเรียกดูได้ และทำให้เกิดการแซนด์บ็อกซ์ย่อยได้
  • สำหรับดิสโทรที่ไม่ใช้ systemd เดิมยังพอมีช่องทางให้ทำเดมอนอิสระอย่าง elogind ได้ แต่หลังข้อถกเถียงขยายตัว ดูเหมือนความตั้งใจของนักพัฒนาที่จะรองรับกรณีนี้จะลดลง
  • หากการพึ่งพา systemd เข้มงวดขึ้น ดิสโทรอย่าง Void, Guix และ Alpine อาจใช้งาน Flatpak ได้ยากขึ้น และความเป็น กลางต่อดิสโทร ก็อาจอ่อนลง

ความเป็นไปได้ที่ความเป็นกลางต่อดิสโทรของ Flatpak จะเปลี่ยนไป

  • เว็บไซต์ Flatpak ชูข้อดีข้อแรกว่า “Build for every distro: create one app and distribute it to the entire Linux desktop market.” และในรายชื่อดิสโทรที่รองรับก็มี Void Linux, Guix, Alpine ซึ่งใช้ระบบ init ที่ไม่ใช่ systemd รวมอยู่ด้วย
  • ปัจจุบัน Flatpak ยังไม่ทำให้ผู้ใช้ต้องสนใจว่าตนใช้ระบบ init แบบใด แต่ในเวอร์ชันหลักถัดไปมีแนวโน้มสูงว่าจะเกิด การพึ่งพา systemd
  • หากการเปลี่ยนแปลงนี้ถูกนำมาใช้จริง ประเด็นสำคัญคือดิสโทรที่ไม่ใช้ systemd จะยังสามารถให้บริการ Flatpak ต่อไปได้หรือไม่

Flatpak Next และทิศทางการออกแบบใหม่

  • Arian Vovk และ Sebastian Wick ได้บรรยายเกี่ยวกับอนาคตของ Flatpak ในงาน Linux App Summit ผ่านการนำเสนอ
  • แม้ Flatpak เวอร์ชันปัจจุบันจะยังคงได้รับการปรับปรุงต่อไป แต่ก็ยากขึ้นเรื่อย ๆ ที่จะหลบข้อจำกัดของสถาปัตยกรรมเดิมที่มีอายุ หลายสิบปี
  • งานที่ถูกเรียกว่า Flatpak Next หรือ Flatpak 2.0 นั้นแทบจะใกล้เคียงกับการเขียนใหม่ โดยสะท้อนประสบการณ์ที่สะสมมาตั้งแต่ Flatpak 1.x
  • การออกแบบใหม่นี้ถูกวางแผนให้ใช้เทคโนโลยีและแนวคิดสมัยใหม่ที่เกิดขึ้นหลังการออกแบบ Flatpak ยุคแรก
  • เนื้อหาในการบรรยายยังอยู่ในขั้นวางแผน และยังไม่มีการเขียนโค้ดแม้แต่บรรทัดเดียว ดังนั้นผลลัพธ์อาจเปลี่ยนแปลงได้มากระหว่างการพัฒนาในอีกหลายปีข้างหน้า

systemd-appd และการย้ายการจัดการสิทธิ์

  • การเปลี่ยนแปลงสำคัญในทิศทางการพัฒนา Flatpak คือการย้าย การจัดการสิทธิ์ ออกจากภายใน Flatpak ไปอยู่ที่ชั้นบริการ
  • บริการใหม่ systemd-appd จะทำหน้าที่กำหนดตัวระบุให้แอปพลิเคชัน จัดเก็บสิทธิ์ และเปิดให้คอมโพเนนต์อื่นของระบบเรียกดูข้อมูลนี้ได้
  • โครงสร้างนี้เปิดทางให้เกิดความสามารถหลายอย่าง โดยเฉพาะ การแซนด์บ็อกซ์ย่อย(subsandboxing) ที่ถูกยกให้เป็นฟีเจอร์สำคัญ
  • แผนปัจจุบันคือการนำความสามารถนี้มาใส่ใน Flatpak เวอร์ชันปัจจุบัน ซึ่งจะทำให้ Flatpak เกิดการพึ่งพา systemd ตามไปด้วย

ช่องทางสำหรับดิสโทรที่ไม่ใช้ systemd

  • ตามคำอธิบายของ Vovk เดิมมีเจตนาที่จะ “คำนึงถึง” ดิสโทรและผู้ใช้ที่ไม่ใช้ systemd อย่างมาก
  • โมเดลที่พอคาดได้คือแนวทางคล้าย systemd-logind ที่ถูกแยกออกเป็นเดมอนอิสระ elogind ทำให้ดิสโทรที่ใช้ระบบ init อื่นยังสามารถใช้เดสก์ท็อปเอนไวรอนเมนต์ที่พึ่งพา systemd-logind ได้
  • ดูเหมือนนักพัฒนา Flatpak ก็พยายามเปิดช่องทางที่ใช้งานได้จริงไว้มากที่สุด เพื่อให้ systemd-appd สามารถมีอิมพลีเมนเทชันเดมอนอิสระแบบคล้ายกันได้
  • หากแนวทางนี้ยังคงอยู่ Flatpak ก็อาจยังสามารถให้บริการบนดิสโทรที่ไม่ใช้ systemd ต่อไปได้

ข้อถกเถียงที่ลุกลามและการเปลี่ยนแปลงในการตอบสนองของนักพัฒนา

  • ผู้ใช้ดิสโทรอย่าง Void หรือ Alpine แสดงความกังวลว่า หาก Flatpak พึ่งพา systemd อย่างมาก มันอาจไม่สามารถทำงานบนระบบของพวกเขาได้อีกต่อไป
  • คำถามจำนวนมากกลับไปตกที่คนซึ่งไม่ได้มีส่วนทางเทคนิคกับการพัฒนา Flatpak และคำตอบของเขาก็มีทั้งแบบไม่ค่อยช่วยอะไร ดูหมิ่น และยั่วยุ
  • เมื่อมีคนจำนวนมากเข้าใจผิดว่าเขามีส่วนร่วมกับการพัฒนา Flatpak สถานการณ์ก็ยิ่งแย่ลง เพราะคำถามจริงจังและเป็นมิตรปะปนกับปฏิกิริยารุนแรงจากฝั่งต่อต้าน systemd
  • ผลคือ นักพัฒนา Flatpak เริ่มมีท่าทีว่าไม่อยากใช้เวลาไปกับการคำนึงถึงดิสโทรและผู้ใช้ที่ไม่ใช้ systemd
  • หากกระแสนี้ดำเนินต่อไป การพึ่งพา systemd ก็อาจเข้มงวดยิ่งขึ้น และการทำเดมอนอิสระที่จำลองความสามารถของ systemd-appd ก็อาจยากกว่าที่คาดไว้แต่แรกมาก

ผลที่คาดว่าจะเกิดขึ้นและความหมาย

  • จากสถานการณ์ปัจจุบัน มีความเป็นไปได้สูงว่าในอีกไม่กี่ปีข้างหน้า Flatpak จะมี การพึ่งพา systemd
  • และก็อาจไม่มีความพยายามเหลืออยู่ในการเปิดทางให้ดิสโทรที่ไม่ใช้ systemd สร้างเดมอนอิสระมาทดแทนความสามารถของ systemd-appd
  • หากเป็นเช่นนั้น Flatpak ก็จะยากขึ้นที่จะอ้างความเป็น กลางต่อดิสโทร ว่าสามารถแจกจ่ายแอปหนึ่งตัวไปยังทุกดิสโทรได้อีกต่อไป
  • เนื่องจาก Flatpak เป็นเครื่องมือที่มีความต้องการใช้งานจริงไม่ว่าผู้ใช้จะใช้ระบบ init แบบใด การเปลี่ยนแปลงนี้จึงส่งผลโดยตรงต่อขอบเขตการแจกจ่ายแอปพลิเคชันบน Linux เดสก์ท็อป

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความคิดเห็นจาก Lobste.rs

  • ไม่ค่อยเข้าใจว่าทำไมหลายคนถึงเกลียด systemd กันนัก ส่วนตัวมองว่ามันให้ความสามารถที่มีประโยชน์ผ่าน API ที่ใช้งานง่ายและการจัดการการพึ่งพาและความขัดแย้งที่สมเหตุสมผล
    ฝั่งที่ไม่ชอบ systemd มักยกเหตุผลคลุมเครืออย่าง “ไม่เป็นแบบยูนิกซ์”, “รวมศูนย์เกินไป”, หรือ “systemd-journald ใช้ไฟล์ฟอร์แมตที่ไม่ใช่ข้อความธรรมดา”
    ถ้าจะคัดค้านก็อยากให้บอกเหตุผลที่เป็นรูปธรรม แนวทางแก้ไข และทำไม init system อื่นถึงดีกว่า แบบนั้นผมก็จะได้อธิบายได้ว่า rc script เป็นแฮ็กที่สกปรกและยุ่งเหยิงแค่ไหน

    • ข้อถกเถียงบน Mastodon ที่ลิงก์ไว้จำนวนมาก โดยแก่นแล้วใกล้เคียงกับการต่อต้านการรวมศูนย์มากกว่าการต่อต้าน systemd เอง ถ้า Flatpak ต้องพึ่ง systemd ก็แปลว่าตระกูล Linux ที่ใช้ init system อื่นจะเข้าถึง flatpak ได้น้อยลง
      อย่างน้อยสำหรับผม ปรัชญาของ Linux คือเรื่องของทางเลือกเป็นหลัก และถ้า Flatpak ต้องการ init system เฉพาะ ก็จะทำให้ผู้ใช้มีตัวเลือกน้อยลงเวลาจัดระบบเพื่อให้ได้ผลลัพธ์ที่ต้องการ
    • ผมใช้ systemd ได้ดีอยู่ แต่ในกรณีของ Flatpak ก็เข้าใจแรงต้านนะ Flatpak โดยเนื้อแท้แล้วคือ “ทำให้รันได้บนดิสโทร Linux ไหนก็ได้” ดังนั้นการพึ่ง systemd จึงลดทอนประโยชน์ของมันลงไปพอสมควร
    • ความไม่พอใจแบบไม่ผ่านการแต่งเติมที่ผมมีต่อ systemd ก็ประมาณนี้: ตัว implementation ของ journald ไม่ค่อยดี แต่แนวคิดโดยรวมโอเค และคิวงานซึ่งเป็น abstraction จริงที่ systemd ใช้จัดการยูนิตนั้น มีกรณีขอบแปลก ๆ ที่ไม่ได้มีเอกสารหรือหาเอกสารได้ยาก
      มันควรใส่ลงใน container image ได้ง่ายกว่านี้ และ user systemd ควรมีสิทธิ์เข้าถึง read API ของ system instance เพื่ออย่างน้อยจะได้จัดตารางยูนิตด้วยอะไรอย่าง After, Requires ได้
      ถึงอย่างนั้นผมก็ยังคิดว่านี่คือสิ่งที่ดีที่สุดที่เกิดขึ้นกับ Linux หลังการถอด HAL ออก และผมเคยจับมือขอบคุณ Lennart สำหรับโปรเจ็กต์นี้ด้วย
    • ฝั่งอย่าง Chimera ที่ลงมือทำ alternative stack ที่เชื่อถือได้จริง ไม่ได้ปล่อย FUD และมีท่าทีสุภาพถ่อมตัว ตรงข้ามกับฝูงความโกรธบนอินเทอร์เน็ตที่ไม่มีทางออกที่ชัดเจน และต่อไปก็คงไม่มีด้วย
      สิ่งที่ “ฝ่ายคัดค้าน” นี้เสนอโดยพฤตินัย ดูจะใกล้เคียงกับการบอกว่าไม่ควรมีวิธีแก้ปัญหาใด ๆ อยู่เลย พวกเขาทำตัวเหมือน HOA ของ Linux และผมมองว่ามันคล้ายการเมืองแบบถ่วงความก้าวหน้า ที่ขัดขวางการพัฒนาของระบบที่แข็งแรง ใช้งานได้จริง และแข่งขันได้พอจะเบียดระบบปฏิบัติการผูกขาดออกไป
    • ถ้าใช้เฉพาะกับระบบที่มีไว้เสิร์ฟเว็บเพจ หรือแสดงเว็บเพจผ่าน GUI browser ผมก็ไม่ได้เกลียด systemd การเขียน systemd unit โดยตรงเพื่อ deploy ลง VPS ก็โอเค และถ้าเป็น SysV init หรือ upstart ผมก็คงไม่ค่อยมีปัญหาเหมือนกัน
      แต่บนโน้ตบุ๊ก ผมต้องการอีกแบบหนึ่ง ผมมีแนวคิดของตัวเองว่าควรให้สภาพแวดล้อมส่วนตัวทำงานอย่างไร ผมยังต้องการฟีเจอร์อำนวยความสะดวกบางอย่างที่ผู้ใช้ Linux ทั่วไปอาจไม่ต้องการ และไม่อยากให้มีอะไรเกิดขึ้นถ้าไม่ได้ขอไว้ชัดเจน ผมเกลียด “ความพยายามที่จะทำให้มันไม่ทำงาน” มากกว่า “ความพยายามที่จะทำให้มันทำงาน” มาก
      เหตุผลหลักที่ผมทิ้ง NixOS เพราะ systemd คือขอบเขตที่ขยายใหญ่ขึ้นเรื่อย ๆ และค่าเริ่มต้นแบบมีความเห็นแรง พอเอาการจัดการพลังงานกับการล็อกอินมารวมกัน มันก็กลายเป็นว่าปิดฝาเครื่องแล้วพักเครื่องเสมอ ต้องคอยแก้ใหม่ทุกครั้ง การเปลี่ยนขอบเขตการอนุญาต linger ก็ทำให้ nohup และ screen ที่ POSIX กำหนดไว้พัง และการจัดการ VT ที่เข้มงวดขึ้นก็ทำให้ต้องออกแบบ “ล็อกอินครั้งเดียวแล้วรัน Xorg หลายอินสแตนซ์” หรือ “ยึด VT” ใหม่ให้เป็นไปตามวิธีของ systemd
      สุดท้ายผมตัดสินใจว่า sinit แบบ minimal init และไม่มี service supervision ดีกว่า แล้วก็เขียน shell boot script เอง โดยทำฟังก์ชันระบบบางส่วนด้วย shell และบางส่วนด้วย Common Lisp บนโน้ตบุ๊ก ถ้าพวก PostgreSQL รันขึ้นมาแล้วก็ปล่อยให้รันต่อไป ถ้ามันดับผมก็สังเกตได้เอง และถ้าการรีสตาร์ตก็พอแล้ว เรื่องมันก็ง่าย แต่ถ้ารีสตาร์ตไม่พอ service supervisor ก็ช่วยอะไรไม่ได้อยู่ดี
      ตัวอย่างที่ทำให้เสียความเชื่อมั่น เช่น ตอนใช้ HDD แล้ว journald ใช้เวลาหลายนาทีโดยไม่แสดงอะไรเลยกว่าจะโชว์ log ในสภาพแคชเย็น, การเจอ https://github.com/systemd/systemd/issues/2913 ด้วยตัวเอง, และท่าทีที่ดูไม่แคร์กับการทำให้ nohup พัง
      ในกระบวนการพัฒนาเองก็มีท่าทีใน https://github.com/systemd/systemd/issues/437 ที่ให้ความรู้สึกว่า “เราให้ค่าเริ่มต้นที่ดี แต่ถ้าค่าเริ่มต้นมันแย่ ดิสโทรก็ไปแก้กันเอง” รวมถึงท่าทีใน http://lists.freedesktop.org/archives/systemd-devel/… ที่ไม่ค่อยอยากให้คำมั่นเรื่อง API ที่เสถียร ซึ่งลดความเชื่อมั่นลงไปอีก
      อย่างไรก็ดี ความไม่พอใจเหล่านี้ก็เป็นเรื่องเก่าแล้ว หลังจากเห็นว่า systemd แก้ปัญหาบางอย่างพร้อมสร้างปัญหาอีกบางอย่างขึ้นมา และทั้งสองอย่างก็ไม่ใช่ปัญหาที่ผมมีตั้งแต่แรก ผมก็ย้ายไปใช้ shell script สำหรับบูตบนโน้ตบุ๊ก และตอนนี้ต้นทุนของการคงสภาพเดิมไว้ต่ำมากจนไม่มีเหตุผลจะลอง systemd ใหม่ บน VPS ผมก็ยังใช้ systemd ภายในขอบเขตที่คุ้นเคยของ Debian

  • ผมหงุดหงิดที่เรื่องนี้เริ่มจากคนที่ไม่ใช่นักพัฒนา Flatpak ปล่อยข้อมูลผิด แล้วกระตุ้นให้เกิดปฏิกิริยาทางอารมณ์ จากนั้นระหว่างที่เธรดต้นทางดำเนินต่อไป ก็มีถ้อยคำที่รุนแรงขึ้นเรื่อย ๆ จนคนพากันกรูไปหาโปรเจ็กต์ Flatpak และชื่อเสียงของนักพัฒนา
    เพราะแบบนั้นจึงไม่น่าแปลกใจที่นักพัฒนา Flatpak ตัวจริงจะได้รับผลกระทบทางอารมณ์และอยากตีตัวออกห่างจากฝูงคนที่กำลังเดือดดาล
    อยากให้ทุกคนใจเย็น ๆ และอย่าทำให้เรื่องนี้บานปลายไปกว่านี้ ถ้ามีข้อสงสัยหรือความกังวล ก็ควรคุยกับผู้ดูแลจริง ๆ แสดงออกว่าคุณสนับสนุนการหาจุดกึ่งกลาง และแสดงให้เห็นว่านี่เป็นเหตุการณ์เฉพาะตัวของบางคน ไม่ได้เป็นตัวแทนของทั้งชุมชน
    เหมือนกับที่แนวคิดเรื่องการพึ่ง systemd ยังไม่ใช่ข้อสรุปสุดท้ายแต่เป็นเพียงไอเดีย ผมคิดว่าความเป็นไปได้ที่ผู้ดูแลจะกลับมาทบทวนการรองรับโปรเจ็กต์ที่หลากหลายกว่านี้ก็ยังไม่ปิดตาย

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

    • ผมใช้ Void อย่างพอใจมานานกว่าสิบปีแล้ว จำไม่ได้ด้วยซ้ำว่าครั้งสุดท้ายที่ต้องกังวลเรื่อง init system หรือการผสานกับ systemd คือเมื่อไร ขอบคุณสำหรับทุกอย่างที่ทำให้กับ Void

  • ฉันใช้ Void บนโน้ตบุ๊กอยู่ ซึ่งทำงานได้มีประสิทธิภาพและเอกสารก็ค่อนข้างดี ขอบคุณสำหรับทุกอย่างที่นักพัฒนาได้ทำมา และหวังว่าการเปลี่ยนแปลงของ Flatpak จะไม่กลายเป็นภาระที่หนักเกินไป

  • "นี่แหละ Linux ยุคปัจจุบัน และมีแต่ systemd"
    มันทำให้นึกขึ้นมาได้อย่างชัดเจนว่าชุมชน Linux คล้าย WeWork มากกว่าจะเป็นชุมชน ในโครงสร้างที่คนรอบข้างต่างก็รับเงินเดือนโดยพึ่งพาการมีอยู่ของ Red Hat ขณะที่ใครบางคนกำลังแฮ็ก GNU readline ให้ใช้ฟรี

    • ยากจะบอกว่าบทความผิดในจุดนี้: ตรงที่พูดถึงการ “ดึงดูดพวกคลั่ง anti-systemd ที่เชื่อทฤษฎีสมคบคิดเกี่ยวกับ Red Hat (และพวกที่แย่กว่านั้น)”

  • ณ จุดนี้ยังเร็วเกินไปที่จะพูดอย่างหนักแน่นว่า “จะกลายเป็นการพึ่งพา” และมันดูเป็นการคาดเดาค่อนข้างมาก

  • น่าสนใจที่พาดหัวดูฟันธงกว่าตัวบทความมาก หลายคอมเมนต์ชัดเจนว่าตอบสนองต่อแค่พาดหัว และแม้โชคดีที่ไม่ใช่ทั้งหมด แต่ปรากฏการณ์นี้ก็ไม่ใช่เรื่องใหม่บนอินเทอร์เน็ต
    ช่วงนี้แม้แต่บน lobste.rs ก็เห็นบ่อยว่าคนตอบสนองแค่พาดหัวหรือประโยคเดียวในคอมเมนต์ยาว ๆ ซึ่งน่ากังวล โดยมากแทบไม่เปิดโอกาสให้มีความเป็นไปได้อื่นนอกจากการตีความแรกที่ตัวเองนึกขึ้นได้ ซึ่งบ่อยครั้งก็เป็นการตีความเชิงโจมตี
    พออ่านบทความแล้ว ดูเหมือนว่าเรื่องคล้ายกันนี้ก็เคยเกิดขึ้นกับกระแสถกเถียง Flatpak 2.0 พวกเขาน่าจะพยายามเปิดช่องไว้สำหรับ init system อื่น ๆ แต่บทสนทนารอบ ๆ เรื่องนั้นกลับเปลี่ยนเป็นศัตรูอย่างรวดเร็วจนดูเหมือนจะยอมเลิกไปโดยปริยาย

  • ในฐานะคนที่ใช้ init system ทางเลือก เรื่องนี้น่าหงุดหงิดมาก ฉันมีโน้ตบุ๊กเครื่องหนึ่งรัน Alpine Linux และใช้ Flatpak เพื่อรันซอฟต์แวร์ที่ทำงานได้เฉพาะบน glibc การเปลี่ยนแปลงนี้จะทำให้ฉันต้องออกจากสภาพแวดล้อมนั้น
    ไม่ได้เกลียด systemd นะ ระบบ Gentoo ของฉันทั้งหมดก็ใช้ systemd แต่ฉันไม่ชอบวิธีที่ systemd ทำให้ซอฟต์แวร์เสรีและโอเพนซอร์สค่อย ๆ พึ่งพา GNU/Linux มากขึ้นเรื่อย ๆ

  • นี่เป็นเรื่องดีอย่างชัดเจน
    systemd ประกอบด้วยเดมอนที่มี API เสถียรและนิยามไว้ชัดเจน ดังนั้นไม่ว่าส่วนไหนของ systemd ที่ Flatpak จะไปพึ่งพา ฉันคิดว่าถ้าใครยอมลงแรง ก็สามารถ reimplement ใหม่อย่างสะอาดตั้งแต่ต้นได้
    นี่คือผลลัพธ์ที่ดีที่สุดเท่าที่จะเป็นไปได้ การแตกกระจายจะลดลง และคนที่มีความต้องการเฉพาะทางก็จะมีเป้าหมายที่เสถียรสำหรับการ reimplement

    • ตอนแรกฉันเริ่มอ่านโดยคิดว่าเป็นการประชด แต่ไม่ใช่
      API ของ systemd มักถูกนิยามแบบกำกวมใน man page และฝั่ง systemd ก็ไม่ได้คาดหวังให้มี implementation อื่นอยู่แล้ว ดังนั้นมันจึงไม่ได้เสถียรหรือมีการจัดการเวอร์ชันสำหรับการทำงานร่วมกันสองทาง
      ในกรณีของ notify socket API มันกลับเสถียรแค่ในทิศทางเดียวด้วยซ้ำ การเพิ่มการรองรับ vsock ทำให้เดมอนที่ถูก implement โดยไม่พึ่ง libsystemd พังไปโดยพฤตินัย ที่เรื่องนี้ไม่เป็นที่รู้จักมากนักก็เพราะ vsock ส่วนใหญ่ใช้สำหรับการสื่อสารระหว่าง systemd ข้ามขอบเขตของ virtualization ถ้าออกแบบมาดี ก็ควรทำให้มันเป็นส่วนขยายที่ใช้เฉพาะตรงขอบเขตนั้น
      เขาบอกว่าเป็น “เดมอนหลายตัว” แต่ในทางปฏิบัติส่วนใหญ่คือ logind และ systemd และสองตัวนี้ก็เป็นผู้เปิดเผยพื้นผิว API แทบทั้งหมด ทำให้ความสามารถในการนำมาประกอบกันมีจำกัด มันทำเช่นนั้นผ่าน DBus interface ไม่กี่ตัว ตอนนี้ก็มี varlink แล้ว และผ่านไลบรารีเดี่ยวตัวหนึ่ง
      ถ้าจะมาแทน systemd คุณต้องแทนทั้งก้อนพร้อมทั้งฝืนให้โมเดลภายในเปิดเผยออกมาเป็น API แบบ systemd หรือไม่ก็ต้องแก้โจทย์ตัวเลือกการออกแบบ API ของ systemd ก่อน แล้วสร้างชั้นกลางที่ให้ backend แบบเสียบแทนได้
      ฉันจัดการปัญหานี้มาหลายปีแล้ว ฉันคิดว่าหลักการออกแบบหลายอย่างของ systemd มีเหตุผล แต่การออกแบบปัจจุบันกลับย้ายความซับซ้อนที่คนส่วนใหญ่ไม่จำเป็นต้องเจอมาไว้ข้างหน้า การออกแบบที่ modular และสลับทดแทนกันได้กว่านี้เป็นไปได้ และการออกแบบ interface แบบเรียบง่ายที่แยกส่วนได้ก็คิดขึ้นใหม่หรือหยิบของเดิมมาใช้ก็ได้ไม่ยากนัก
      แต่ปัญหาคือซอฟต์แวร์ที่เลือกจะพึ่งพา API ของ systemd ถ้าจะให้มันทำงานกับอย่างอื่น คุณต้องส่งแพตช์เข้า upstream เพื่อแยกการรองรับฟีเจอร์ที่ผูกอยู่กับ libsystemd ทั้งก้อน หรือไม่ก็เพิ่มการรองรับ API ใหม่เป็นรายตัว ซึ่งแบบแรกไม่เคยสำเร็จ ส่วนแบบหลังก็มักยากจะยอมรับเพราะภาระดูแล API ใหม่ก่อนออกจริงและ API เฉพาะกลุ่ม
      หรือคุณอาจ implement แค่ API ที่ซอฟต์แวร์นั้นใช้ก็ได้ เช่น ใช้บริการ DBus ของ login1 ที่ไม่ได้ implement API ส่วนใหญ่ แต่พอทำแบบนั้นมันก็จะชนกับ implementation อื่นที่พยายามแทน API ส่วนอื่น และคุณต้อง implement อยู่สามรูปแบบ: API ที่ควรจะสะอาดดั้งเดิม, API ของ logind/systemd บน DBus, และ API สำหรับ varlink
      ในระยะยาว วิธีแก้อาจเป็น router ที่ implement API ของ systemd หรือ logind ทั้งชุด แล้วด้านหลังค่อยเชื่อมไปยัง API ที่แยกส่วนไว้ แต่การออกแบบปัจจุบันมีความซ้ำซ้อนรุนแรงและความเฉพาะตัวต่อ systemd ฝังอยู่ ทำให้สร้างให้ดีได้ยากมาก
      ไม่แน่ใจว่านี่เป็นความตั้งใจหรือไม่ แต่จากคำพูดของนักพัฒนา systemd อย่างน้อยที่สุดมันก็เป็นปัญหาที่จงใจไม่ใส่ใจ การสร้างชั้นกลางที่ซับซ้อนหรือการสร้างตัวแทน systemd โดยไม่เขียน systemd ใหม่ทั้งชุดนั้นยากมาก และต่อให้แอปพลิเคชันจะพึ่งพาเพียงบางส่วนของ API ที่แยกแจกเป็นชิ้น ๆ ได้ ก็แทบเป็นไปไม่ได้เลยที่จะมาแทนเพียงบางส่วนของ systemd อย่างสะอาด
    • ตอนนี้มันยังจริงอยู่ไหมที่บางส่วนของ systemd สามารถถูก reimplement ใหม่อย่างสะอาดตั้งแต่ต้นได้? ในบทความยก elogind เป็นตัวอย่าง

  • ฉันไม่ชอบวิธีที่ Red Hat มีอำนาจควบคุมมากเกินไปในระบบนิเวศ Linux

    • ฉันก็เหมือนกัน แต่ทุกวันนี้ก็ไม่แน่ใจว่า Red Hat ยังควบคุม systemd ได้มากแค่ไหน
    • มันสองด้านจริง ๆ การรวมศูนย์อำนาจควบคุมเป็นเรื่องไม่ดี แต่การจ่ายเงินให้คนสร้างซอฟต์แวร์เสรีและโอเพนซอร์สเป็นเรื่องดี และอำนาจควบคุมส่วนใหญ่ที่พวกเขาได้มาก็มาจากการจ่ายเงินให้คนทำซอฟต์แวร์เสรีและโอเพนซอร์สนี่แหละ
      ถึงอย่างนั้น การที่ Red Hat ยอมรับซอฟต์แวร์เสรีก็ช่วยบรรเทาความกังวลเรื่องอิทธิพลของพวกเขาไปได้ระดับหนึ่ง มองจากเทคโนโลยีที่พวกเขาเข้าซื้อตลอดหลายปีที่ผ่านมา แม้แต่กรณีที่เดิมไม่มี upstream อยู่เลย พวกเขาก็ยังสร้าง upstream แบบเสรีและโอเพนซอร์สขึ้นมาเองได้ Dogtag PKI และ 389 Directory Server เป็นตัวอย่างที่นึกออกทันที
      โดยรวมแล้วฉันคิดว่าพวกเขาไม่ได้แย่ต่อระบบนิเวศนัก และมีกรณีที่ช่วยพัฒนาให้ก้าวหน้ามากกว่ากรณีที่ทำร้ายมัน

  • ฉันไม่ได้มีส่วนได้ส่วนเสียโดยตรงกับข้อถกเถียงนี้ แต่ที่นี่ไม่มีอะไรที่ช่วยลดความกังวลเกี่ยวกับ ความซับซ้อนและชั้นนามธรรมที่ไม่จำเป็น ซึ่งเพิ่มขึ้นเรื่อย ๆ บนระบบ Linux
    Linux กำลังกลายเป็น Java ของระบบปฏิบัติการอย่างรวดเร็ว เป็นเรื่องที่น่าเศร้าจริง ๆ