GoboLinux ดิสโทรลินุกซ์เชิงทดลองที่ใช้ไฟล์ซิสเต็มเป็นฐานข้อมูลแพ็กเกจ

 (gobolinux.org)
3 คะแนน โดย GN⁺ 2024-03-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นดิสโทรเชิงทดลองที่ปรับเปลี่ยนธรรมเนียมไดเรกทอรีของลินุกซ์แบบเดิมอย่างมาก เพื่อให้เข้าใจโครงสร้างระบบโดยยึด ไดเรกทอรีตามโปรแกรม เป็นศูนย์กลาง
  • แทนที่จะใช้ฐานข้อมูลแพ็กเกจแยกต่างหาก จะใช้ ตัวไฟล์ซิสเต็มเองเป็นฐานข้อมูล โดยโปรแกรมจะถูกจัดวางตามเวอร์ชันในพาธอย่าง /Programs/Nano/8.3
  • รีลีสล่าสุด 017.01 เป็นอัปเดตแก้บั๊กที่ออกมาหลังจากรีลีส ISO ก่อนหน้าราว 5 ปี และจัดการปัญหาสำคัญบางส่วนที่เกิดขึ้นในช่วงนั้น
  • ผู้ก่อตั้ง Hisham Muhammad ถอนตัวจากการดูแลหลังดำเนินโครงการมา 25 ปี และโปรเจ็กต์ถูกรับช่วงต่อโดยผู้ใช้ GitHub @fyrak1s
  • สามารถรันแบบตรง ๆ ในสภาพแวดล้อม Live หรือจะติดตั้งลงฮาร์ดไดรฟ์ก็ได้ เพื่อทดลอง โครงสร้างไฟล์ซิสเต็ม ที่แตกต่างจากดิสโทรทั่วไปด้วยตนเอง

วิธีจัดการแพ็กเกจด้วยไฟล์ซิสเต็ม

  • GoboLinux เป็นดิสโทรลินุกซ์เชิงทดลองที่นิยามลำดับชั้นของไฟล์ซิสเต็มใหม่ทั้งหมด
  • แกนหลักคือโครงสร้างที่ไม่ใช้ฐานข้อมูลแพ็กเกจแยก แต่ใช้ ไฟล์ซิสเต็มเป็นฐานข้อมูล
    • แต่ละโปรแกรมจะอยู่ในไดเรกทอรีของตัวเอง
    • ตัวอย่างคือ /Programs/Nano/8.3, /Programs/GCC/14.2.0
  • เนื่องจากมีโครงสร้างต่างจากดิสโทรลินุกซ์ทั่วไป ผู้ใช้ที่เพิ่งพบครั้งแรกควรอ่านเอกสารก่อน

รีลีส 017.01 และการเปลี่ยนผู้ดูแลโครงการ

  • เวอร์ชันปัจจุบันคือ 017.01
    • เป็น สภาพแวดล้อม Live ที่บูตใช้งานได้จาก USB drive และ DVD
    • สามารถติดตั้งลงฮาร์ดไดรฟ์ได้ด้วย
    • ดาวน์โหลด ISO ได้จาก Downloads
  • v017.01 เป็นอัปเดตแก้บั๊กที่ออกมาหลังช่วงว่างยาวราว 5 ปี
    • แก้ปัญหาสำคัญบางส่วนที่เกิดขึ้นหลังรีลีส ISO ก่อนหน้า
    • ดูรายละเอียดการเปลี่ยนแปลงได้ใน release notes
  • การดำเนินโครงการก็มีการเปลี่ยนแปลงเช่นกัน
    • Hisham Muhammad ผู้ก่อตั้งและผู้ที่นำ GoboLinux มาตลอด 25 ปี ได้ถอนตัวอย่างเป็นทางการ
    • โปรเจ็กต์จะดำเนินต่อภายใต้การดูแลของ @fyrak1s
    • Lucas Correia Villa Real หรือ paranoidd ได้ร่วมดูแล GoboLinux กับ Hisham มาจนถึงเดือนมิถุนายน 2021
  • ศูนย์กลางคอมมูนิตี้กระจายอยู่ในแชต ฟอรัม และวิกิ

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

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

 
GN⁺ 2024-03-01
ความคิดเห็นจาก Hacker News

  • ถ้าใครรู้สึก ต่อต้านโดยสัญชาตญาณทันที กับการออกแบบของ GoboLinux เอกสาร “I am not clueless”¹ ที่มีอายุ 20 ปีน่าจะมีทั้งบริบทและเหตุผลอธิบายไว้พอสมควร
    ความรู้สึกต่อต้านนั้นยังไม่ได้หายไปหมด แต่ก็ไม่แรงเท่าเมื่อก่อนแล้ว ;)
    ¹ https://gobolinux.org/doc/articles/clueless.html

    • โทนของบทความให้ความรู้สึกคล้ายเอกสารของ HTMX หรือ Tailwind
      สรุปได้ประมาณว่า “เรารู้ว่าเราแตกต่าง มันเรียบง่ายมาก อาจไม่คุ้นเคย แต่เข้าใจและใช้งานได้ง่าย คุณไม่จำเป็นต้องใช้ก็ได้ เราชอบแบบนี้และพอใจกับมัน”
    • ในส่วน make all programs relocatable ของบทความที่ลิงก์ไว้ มีการพูดถึงการใช้ libprefix เพื่อให้ต้องเขียนแอปทั้งหมดใหม่ เลยสงสัยว่า libprefix หมายถึงอะไรกันแน่
      ลองค้นในเว็บแล้วก็ไม่เจอผลลัพธ์ที่ใช้ประโยชน์ได้
    • สงสัยว่าความรู้สึกต่อต้านแบบอัตโนมัติส่วนใหญ่อาจมาจาก ดีไซน์ภายนอกที่มองเห็น มากกว่าปัจจัยด้านการทำงานหรือเปล่า
      ตัวอย่างเช่น ปฏิกิริยาแรกส่วนหนึ่งมาจากการใช้ตัวพิมพ์ใหญ่ โดย Programs ที่ขึ้นต้นด้วย P ใหญ่ทำให้นึกถึง Program Files ของ Windows เลยเกิดแรงต้านทางอารมณ์
      ถ้าต้องพิมพ์ LibX11 แทน libx11 ก็คงหงุดหงิดนิดหน่อยเหมือนกัน
      ปกติไฟล์ซิสเต็มของ Linux แยกตัวพิมพ์เล็กใหญ่ แต่ชื่อแพ็กเกจก็คงหลีกเลี่ยงชื่อซ้ำที่ต่างกันแค่ตัวพิมพ์อยู่แล้ว และดิสโทรที่มุ่งทำลำดับชั้นให้เป็นมิตรกับผู้ใช้ก็ดูไม่น่าจะวางไดเรกทอรีที่ต่างกันแค่ตัวพิมพ์ไว้ที่รากระบบ
      ถึงอย่างนั้น ถ้าตัวอย่างเป็น /packages/libx11/1.6.9, /packages/gcc/9.2.0 ปฏิกิริยาแรกก็น่าจะน้อยกว่านี้มาก และข้อดีก็ดูจะไม่ได้ลดลงเลยแม้แต่น้อย

  • น่าเสียดายจริง ๆ ที่แนวคิดของ GoboLinux ไม่ได้หยั่งรากในชุมชน Linux กระแสหลัก
    โครงสร้างไฟล์ซิสเต็มของ Linux นั้นยุ่งเหยิงอย่างสิ้นเชิง

    • เห็นด้วย แต่ก็ดีใจที่เห็น Nix, Guix และ Spack ซึ่งเป็นตัวที่ฉันทำงานด้วยมากที่สุด กำลังค่อย ๆ ได้รับแรงสนับสนุนมากขึ้น ทั้งที่โดยพื้นฐานแล้วก็ไปในทิศทางเดียวกัน
      การทำให้มันใช้งานได้อย่างถูกต้องไม่เคยเป็นเรื่องเล็กน้อย และการทำให้มีประสิทธิภาพก็ยิ่งยากกว่า
      รู้สึกว่าเพิ่งจะในช่วงไม่กี่ปีมานี้เองที่โมเดลแบบนี้เริ่มเข้าใกล้ระดับที่ดูแลรักษาได้จริงสำหรับการแจกจ่ายซอฟต์แวร์ส่วนใหญ่
    • Nix กำลังได้รับความนิยมมากขึ้นเรื่อย ๆ
      โมเดลของ GoboLinux ต้องจัดการไดเรกทอรีเวอร์ชันอย่าง /Programs/Xorg/7.0 ด้วยมือ แต่ Nix แก้ปัญหานั้นด้วยการกำหนดพาธติดตั้งของแพ็กเกจจากแฮชของสูตรการบิลด์
    • ตอนนี้สิ่งที่ยังดูสมเหตุสมผลอย่างสม่ำเสมอน่าจะมีแค่ /home กับ /tmp
      นอกนั้นแทบจะเป็นกองของปะปนที่เอาอะไรก็ไปใส่ไว้ที่ไหนก็ได้
    • แนวคิดเหล่านั้นสร้างแรงบันดาลใจให้ฉันอย่างชัดเจน
      GoboLinux เป็นโปรเจ็กต์แรกที่แสดงให้เห็นว่า บน Linux คุณทำในสิ่งที่อยากให้เป็นได้จริง ๆ
    • /opt กับ /srv และถ้าชอบก็รวม /usr/local/opt ด้วย ต่างก็ให้ข้อดีแบบที่ GoboLinux มีอยู่พอสมควรในเรื่องการจัดการองค์ประกอบทีละชิ้น
      จากมุมมองของดิสโทร ทุกอย่างก็มีเหตุผลในแบบของมัน
      ถ้าพิมพ์ dpkg -S this-file คุณก็จะรู้ได้เร็วว่าทำไมไฟล์ใน /usr ถึงอยู่ตรงนั้น และดิสโทรมีหน้าที่คอยวาดภาพรวมของทั้งระบบ
      เลยสงสัยว่าคุณมองว่าส่วนไหนที่ยุ่งเหยิงที่สุด

  • น่าสนใจที่มันแมปพาธแบบดั้งเดิมไปยังพาธคู่กันของ GoboLinux เพื่อรักษา ความเข้ากันได้ กับมรดกของ Unix แบบโปร่งใส
    ไม่มีเวทมนตร์พิเศษอะไรเลย โดย /bin เป็นลิงก์ไปที่ /System/Index/bin และ /usr/bin กับ /usr/sbin ก็เช่นกัน ทำให้ไดเรกทอรี “ไบนารี” ทั้งหมดชี้ไปยังที่เดียวกัน
    ผลคือไม่ว่าจะเข้าถึงผ่านพาธมาตรฐานไหน ไฟล์ก็ยังทำงานได้ ดังนั้นมันอาจเข้ากันได้มากกว่าดิสโทรทั่วไปเสียอีก ที่สคริปต์อาจพังเพราะอ้างถึง /usr/bin/foo ทั้งที่ไฟล์จริงอยู่ที่ /usr/local/bin/foo

  • ขอถามแบบไม่ค่อยรู้เรื่องนักนะ macOS ทำงานในลักษณะคล้ายแบบนี้อยู่ระดับหนึ่งหรือเปล่า?
    วิธีที่แอปพลิเคชันดูเหมือนเป็น “ไฟล์” เดียวที่จัดการได้ด้วยการลากแล้ววางนั้นดีมากจริง ๆ
    เวลาอยากรู้ว่าอะไรอยู่ตรงไหนและถูกติดตั้งไว้ที่ไหนบน Ubuntu มักทำให้ฉันรู้สึกเหมือนตัวเองโง่ไปเลย

    • ปัญหาที่ว่าใน Ubuntu หายากว่าอะไรอยู่ตรงไหนและถูกวางไปที่ไหน ยิ่งแย่ลงเพราะตัวจัดการไฟล์ของ Linux พยายามซ่อนบางส่วนของไฟล์ซิสเต็มที่ไม่ใช่โฟลเดอร์บ้านหรือไดรฟ์ที่เมานต์ไว้
      ก็เข้าใจว่าทำไมถึงทำแบบนั้น
      โครงสร้างไดเรกทอรีของการติดตั้ง Linux ทั่วไปเป็นเขาวงกตที่ชวนสับสนแม้แต่สำหรับคนสายเทคนิค และยิ่งหนักเข้าไปอีกสำหรับผู้ใช้ทั่วไปที่ดิสโทรหลัก ๆ ตั้งเป้าไว้
      แต่สุดท้ายมันก็เป็นการจัดการที่อาการ ไม่ใช่ต้นเหตุ และคิดว่าดิสโทร Linux ควรมีมากกว่านี้ที่จริงจังกับการทำโครงสร้างไฟล์ซิสเต็มให้ทันสมัยแบบที่ Gobo ทำ
      ฉันเองก็อยากลองทำดูเหมือนกัน
      เป้าหมายคือสร้างโครงสร้างที่อธิบายตัวเองได้อย่างสมเหตุสมผล พาผู้ใช้มือใหม่ให้ออกห่างจากพื้นที่อันตราย และทำให้ตัวจัดการไฟล์แทบไม่ต้องซ่อนอะไรเลยก็ยังไม่เป็นปัญหา
    • Bundle ของ macOS เป็นไอเดียที่ดีและยังคงดีอยู่ แต่แอปก็มักยังชอบโปรยอะไรบางอย่างไว้ตามที่แปลก ๆ อย่าง ~/Library อยู่ดี
      กรณีอย่าง Minecraft launcher ที่เก็บทุกอย่างรวมถึงโลกและไฟล์เซฟไว้ใน bundle เองก็ดูน่าสนใจไปอีกแบบ
    • โดยหลักการแล้วฉันเห็นด้วยกับแนวคิดที่ว่าแอปพลิเคชันดูเหมือนเป็น “ไฟล์” เดียว แต่ในความเป็นจริงแล้วหลายแอปก็ยังวางไฟล์หลายอย่างไว้ใน ~/Library และ /Library
      แม้แต่บน macOS ก็ไม่ใช่เรื่องแปลกที่การลบบางแอปต้องทำตามคู่มือการลบด้วยมือหลายขั้นตอน
      โดยเฉพาะถ้าเป็นแอปที่เพิ่มรายการตอนล็อกอินก็ยิ่งสำคัญ
      อย่างน้อยระบบเพิ่ม/ลบโปรแกรมของ Windows ก็ยังมีจุดศูนย์กลางสำหรับเรียกการถอนการติดตั้ง และแอปส่วนใหญ่ก็มักทำตามแนวทางนั้นอย่างถูกต้อง
    • บน Fedora การค้นดู ฐานข้อมูล rpm ทำได้ง่ายมาก
      ใช้ dpkg ทำแบบเดียวกันไม่ได้หรือ?
    • นั่นแหละคือสิ่งที่ฉันไม่ชอบบน Mac มาก ๆ

  • การตั้งชื่อไดเรกทอรีตัวแรกให้ขึ้นต้นด้วยตัวพิมพ์ใหญ่ไม่ค่อยเวิร์ก
    มันให้ความรู้สึกเหมือนมีงานเพิ่มตอนไล่ดูพาธ และการต้องกด Shift คู่กับตัวอักษรหรือตัวเลขทุกครั้งก็น่ารำคาญมากในการใช้งานบรรทัดคำสั่งประจำวัน

    • ตามบทความที่ลิงก์ไว้ข้างบน ในเชลล์ที่ตั้งค่าไว้อย่างเหมาะสม เช่นเชลล์ปริยายของ GoboLinux การพิมพ์ /Programs ใช้จำนวนคีย์กดเท่ากับ /usr ทุกประการ
      แค่สแลช, p ตัวพิมพ์เล็ก, แล้ว Tab ก็พอ
    • เหตุผลที่เวลาท่องไปมาใน PowerShell หรือ cmd.exe แล้วมันไม่ได้น่ารำคาญเลย ก็เพราะเชลล์ช่วยอยู่
      มันไม่ได้บังคับให้คุณเสียสละการใช้งานเพื่อประหยัดคลิกนาฬิกาและหน่วยความจำอันล้ำค่าของ PDP-11
      มันน่าขำเสมอที่แฟน ๆ แนว “แยกพิมพ์เล็กพิมพ์ใหญ่ดีที่สุด!” มองข้ามไปว่านี่เป็นผลลัพธ์จากข้อจำกัดของระบบดั้งเดิมเท่านั้น
      ไม่ใช่ฟีเจอร์
      แถมเรื่องนี้ก็มีการจัดการไว้อย่างชัดเจนแล้ว
      แค่ set completion-ignore-case On ก็ทำให้ชีวิตดีขึ้นมาก
      เพราะถึงไม่ได้ใช้ GoboLinux อย่างน้อยคุณก็ไม่ต้องกด Shift เพิ่มอีกครั้งกับทุกชื่อไฟล์ที่ขึ้นต้นด้วยตัวพิมพ์ใหญ่
      หรือจะใช้ชีวิตต่อเหมือนปี 1977 ก็ได้
      VT100 ของคุณ กฎของคุณ
      เคยเห็นคนพูดทีหลังว่า “ทำไมถึงไม่ใช้ bash เดิม ๆ สำหรับการท่องระบบทั่วไป แต่ไปติดตั้งเชลล์อื่น” ซึ่งก็เท่ากับว่าไม่รู้จักเชลล์ของตัวเองดีพอ
    • ผมชอบมันในฐานะธรรมเนียมที่ช่วยให้แยกได้ทันทีว่าอันไหนเป็นไดเรกทอรีและอันไหนเป็นไฟล์ธรรมดา
      อีกอย่าง ไม่ว่าเชลล์ไหนก็สามารถมีการเติมคำอัตโนมัติแบบไม่สนตัวพิมพ์เล็กพิมพ์ใหญ่ได้ และ Fish ก็มีให้เป็นค่าเริ่มต้น
    • ตัวพิมพ์ใหญ่มีไว้เพื่อหลีกเลี่ยงการชนกับFSH/ไดเรกทอรีแบบดั้งเดิม
    • ไม่ค่อยชอบ
      ให้ความรู้สึกแบบ Windows

  • โปรเจ็กต์นี้มีศักยภาพในการลดภาระทางความคิดของเราได้มากทีเดียว
    หวังว่าจะสำเร็จ
    แก้ไข: เพิ่งเห็นว่ามันเป็นโปรเจ็กต์อายุ 20 ปีแล้ว

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

  • พวกแอปปิดซอร์สที่แย่มาก ๆ มักคาดหวังจากระบบของผู้ใช้มากเกินไป
    Steam client เป็นตัวอย่างแบบนั้น เพราะมันแจกสคริปต์ bash ไม่ใช่สคริปต์ sh และจากข้อกำหนดเรื่องคอนเทนเนอร์ userspace สำหรับ Linux mount ก็ทำให้มันตั้งสมมุติฐานอย่างแรงว่าต้องมีการจัดวางไฟล์แบบ Debian/Ubuntu รวมถึงต้องใช้ตัวเลือกแปลก ๆ ที่มีเฉพาะ GNU ของหลายคำสั่งด้วย
    ยังมีไลบรารี 32 บิตอีกเยอะ
    แต่ดูเหมือนมันยังควบคุม ABI อยู่ และน่าจะใช้คำสั่ง .symver ของ binutils gas
    อย่างน้อยความยุ่งเหยิงในตอนนี้ก็เป็นสิ่งที่ Steam กำลังยัดเยียดเข้าคอเรา และถ้าไม่ใช่ดิสโทรที่ไม่เล่นเกม ก็คงเลี่ยงได้ยาก

    • คนส่วนใหญ่ไม่ได้เล่นเกม และแม้แต่ในหมู่ผู้ใช้ Linux เองก็น่าจะมีหลายคนที่ไม่ใช้แอปกรรมสิทธิ์ตั้งแต่แรก
      ต่อให้ในกลุ่มเกมเมอร์เอง ก็น่าจะมีคนจำนวนมากที่มีพีซีสำหรับเล่นเกมโดยเฉพาะแยกต่างหาก

  • อยากให้คนที่ฉลาดกว่าผมมากช่วยอธิบายว่าทำไมสิ่งนี้ถึงดีกว่า หรือดีกว่าจริงไหม เมื่อเทียบกับดิสโทรอย่างsnap/FlatpakหรือNixOS
    ถ้ามองผิวเผินโดยที่ยังเข้าใจไม่ลึก วิธีนี้ดูเหมือนจะเรียบง่ายที่สุด
    แน่นอนว่านี่พูดบนพื้นฐานว่าผมรู้น้อย

    • ถ้าหมายถึงแค่การเอาแต่ละแอปไปไว้ในโฟลเดอร์ของตัวเอง เท่านั้นอย่างเดียวก็ยังไม่พอสำหรับการแยกกั้น และถ้าผลักแนวคิดนี้สุดทางก็อาจสิ้นเปลืองอย่างมาก
      ที่ Flatpak กับ NixOS ซับซ้อนกว่านั้นก็มีเหตุผลรองรับ
      เช่น มันไม่เก็บ dependency เวอร์ชันเดียวกันเป๊ะซ้ำหลายชุดลงดิสก์
    • snap กับ Flatpak เน้นเรื่องการแจกจ่ายมากกว่าและเป็นแบบ “sandboxed”
      ที่ใส่เครื่องหมายคำพูดก็เพราะมีประเด็นด้านความปลอดภัย
      NixOS ทำให้ความเข้ากันได้กับโปรแกรมเดิมพัง ขณะที่ Gobo ไม่เป็นแบบนั้น
      แต่คลังแพ็กเกจของ NixOS ได้รับการดูแลดีกว่า Gobo แบบเทียบไม่ติด และฝั่ง Gobo เองก็ไม่สมบูรณ์และตามหลังอยู่หลายปี
      ถึงอย่างนั้น สิ่งที่พูดถึงทั้งหมดตรงนี้ก็ยังตามหลังวิธีที่ Android ใช้เก็บแอป
      บน Android สามารถแจกจ่ายแต่ละแอปเป็นไฟล์เดี่ยวที่นำไปแจกจ่ายได้ง่าย มี sandbox ที่เหมาะสม และมีไดเรกทอรีของตัวเอง
      อีกจุดที่แนวทางอื่นมักพลาดคือ แต่ละแอปมีไดเรกทอรีย่อยใต้ไดเรกทอรีของแอปไว้เก็บสถานะของตัวเอง และยังแยกตามผู้ใช้ด้วย

  • นักพัฒนา GoboLinux สร้าง การจัดวาง filesystem ที่มนุษย์เข้าใจได้อย่าง “ชาญฉลาด” จริง ๆ
    มองว่าธรรมเนียม UNIX แบบเก่าที่ใช้อยู่ทุกวันนี้ค่อนข้างเข้าใจยากแล้วในยุคที่ไม่มีข้อจำกัดอย่างชื่อแบบ 8.3, พื้นที่จัดเก็บไม่พอ, หรือปัญหาไฟล์ขนาดเกิน 1GB อีกต่อไป
    เคยรัน GoboLinux 012~015 อยู่หลายปีบนเซิร์ฟเวอร์ที่โฮสต์ซอฟต์แวร์จัดการเวอร์ชัน และโดยรวมถือว่าดีมาก
    จุดติดขัดคือถ้าไม่มีแพ็กเกจที่ต้องการ ก็ต้องเขียน recipe เอง
    ตัวภาษาเขียน recipe ของ GoboLinux เองนั้นเข้าใจง่าย แต่แพ็กเกจหนึ่งมักพึ่งพาไลบรารีเป็นสิบ ๆ ตัวหรือหลายสิบตัว เลยต้องเสียเวลาไล่ตาม dependency ให้ครบ, จับคู่เวอร์ชัน, หา URL ของไลบรารีกับแพ็กเกจ แล้วค่อยสร้าง recipe ใหม่
    สุดท้ายก็ย้ายไป Debian แต่จนถึงตอนนี้พอเห็นว่าไฟล์คอนฟิกยังอยู่ใน /etc และไบนารีไปอยู่ใน /usr/bin หรือ /usr/local/bin ก็ยังสะดุ้งอยู่
    มองว่า systemd ทั้งน่ารำคาญและเหมือนปลาหมึก
    มักต้องใช้ find เพื่อหาไฟล์ .service ที่เกี่ยวข้อง และเชื่อไม่ได้เลยว่าจะอยู่รวมกันในที่เดียว แถม command line ก็ไม่ค่อย intuitive
    ในทางกลับกัน Gobo มีชุดสคริปต์สำหรับจัดการ service ที่เรียบง่ายมากและใช้งานสะดวก
    ถึงอย่างนั้น ความสะดวกที่ติดตั้งสิ่งที่ต้องการได้ทันทีด้วย apt get หรือ dpkg -i ก็เอาชนะการออกแบบอันชาญฉลาดและสมเหตุสมผลกว่ามากของ GoboLinux ได้
    ทุกวันนี้จำนวน Linux distribution ที่รองรับลดลงจากยุคที่มีตัวเลือกมหาศาล จนแทบจะมี Debian หรือ Ubuntu รวมมาให้เป็นพื้นฐานเสมอ ทำให้โอกาสที่จะติดตั้งแพ็กเกจหรือโปรแกรมไม่ได้ แม้อยู่นอก repository ก็มีน้อย
    macOS เองก็ดูจะใช้แนวทางคล้าย GoboLinux อยู่พอสมควร และเพราะแบบนั้น ก่อนจะมีเวอร์ชันหลัง ๆ ที่ค่อนข้างไม่เป็นมิตรกับผู้ใช้ ก็ถือว่าจัดการ macOS ผ่าน command line ได้ค่อนข้างง่าย
    ตัวอย่างเช่น USB drive จะอยู่ที่ /Volumes และไฟล์คอนฟิกของโปรแกรมจะอยู่ใต้ ~/Library

    • เสริมว่า ถ้า service ถูกโหลดอยู่แล้ว แค่รัน systemctl status foo ก็จะบอกได้อย่างชัดเจนตั้งแต่บรรทัดที่สองว่าเกี่ยวข้องกับไฟล์อะไรบ้าง
      เช่น ในผลลัพธ์ของ systemctl status getty@tty1.service จะมี Loaded: loaded (/lib/systemd/system/getty@.service; enabled; preset: enabled) แสดงอยู่ ทำให้รู้ได้ทันทีว่าเป็น /lib/systemd/system/getty@.service