แนะนำระบบ Linux แบบ Immutable

 (dataswamp.org)
3 คะแนน โดย GN⁺ 2023-09-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ดิสโทร Linux แบบ Immutable มีแนวทางการทำงานที่เตรียมการอัปเกรดไว้นอกระบบที่กำลังรันอยู่ แล้ว นำไปใช้ในการบูตครั้งถัดไป ทำให้สามารถย้อนกลับได้เมื่อเกิดความล้มเหลว
  • แม้จะใช้ชื่อว่า “Immutable” แต่หลายส่วนของระบบยังคงเปลี่ยนแปลงได้ และจุดร่วมที่แท้จริงใกล้เคียงกับ transactional update และการ rollback มากกว่า
  • NixOS·Guix วางการกำหนดค่าแบบ declarative และพื้นที่จัดเก็บแบบอ่านอย่างเดียวไว้เป็นแกนหลัก ส่วนสาย OSTree·MicroOS·Vanilla OS เข้าหาด้วย /usr, สแนปช็อต btrfs, และพาร์ทิชัน root แบบ A/B ตามลำดับ
  • ข้อดีคือทำให้ระบบยังคงเสถียรระหว่างการเปลี่ยนแปลงแพ็กเกจ และสามารถย้อนกลับเมื่อมีปัญหาได้ แต่ยังมีข้อจำกัดเรื่องความจำเป็นในการรีบูต, ความขัดแย้งกับเครื่องมือจัดการคอนฟิก, และความยากในการติดตามการเปลี่ยนแปลง
  • สิ่งที่ใหม่ไม่ได้อยู่ที่สแนปช็อตเองเท่าไร แต่อยู่ที่การ นำการเปลี่ยนแปลงไปใช้กับสภาพแวดล้อมที่ไม่ใช่ live และผสานเข้ากับ bootloader รวมถึงเครื่องมือผู้ใช้เพื่อให้ใช้งานง่ายขึ้น

ขอบเขตที่แท้จริงของชื่อ “Immutable”

  • เดิมที immutability หมายถึง อ็อบเจกต์ที่ไม่เปลี่ยนแปลง แต่เมื่อนำมาใช้กับระบบปฏิบัติการ นิยามก็คลุมเครือขึ้นทันที
  • Linux LIVE-CD ดูเหมือน immutable ในแง่ที่บูตขึ้นมาด้วยโปรแกรมชุดเดิมทุกครั้ง และสื่อดิสก์เป็นแบบอ่านอย่างเดียว แต่ระหว่างรันก็ยังสร้างไฟล์และไดเรกทอรี หรือติดตั้งแพ็กเกจได้
  • หากจะเรียกว่าเป็นดิสโทร Linux แบบ Immutable ในปัจจุบัน โดยทั่วไปต้องมีเงื่อนไขสามข้อ
    • ไม่ทำการอัปเกรดระบบโดยตรงบน ระบบ live
    • นำการเปลี่ยนแปลงแพ็กเกจไปใช้ใน การบูตครั้งถัดไป
    • สามารถ rollback กลับไปยังสถานะก่อนหน้าได้
  • ฟีเจอร์เพิ่มเติมแตกต่างกันไปตามแต่ละการนำไปใช้งาน แต่สามข้อนี้ใกล้เคียงกับเงื่อนไขขั้นต่ำของดิสโทร “Immutable” ในปัจจุบัน

ความแตกต่างตามการนำไปใช้งาน

  • NixOS / Guix

    • NixOS และ Guix พึ่งพาการนำไปใช้งานในตระกูลเดียวกัน โดย Nix ปรากฏครั้งแรกในปี 2003 และตัวจัดการแพ็กเกจ Guix ถูก fork จาก Nix ในช่วงต้นทศวรรษ 2010 โดยมีเป้าหมายเป็นซอฟต์แวร์เสรี 100%
    • ทั้งสองระบบแตกต่างจากระบบตระกูล Unix แบบดั้งเดิมอย่างมาก และใช้ immutability เป็นหลักการสำคัญ
    • แพ็กเกจทั้งหมดและไฟล์ที่ build แล้วจะถูกเก็บเป็นรายการเฉพาะในไดเรกทอรีแบบอ่านอย่างเดียวพิเศษที่มีเพียงตัวจัดการแพ็กเกจเท่านั้นที่เขียนได้
    • ตัวระบบปฏิบัติการเองเป็นผลลัพธ์ของตัวจัดการแพ็กเกจ และผู้ใช้เขียนสถานะระบบที่ต้องการเป็น การกำหนดค่าแบบ declarative
    • การกำหนดค่าครอบคลุมผู้ใช้, shell, แพ็กเกจที่ติดตั้ง, บริการที่รันและการตั้งค่า, พาร์ทิชันที่จะ mount และตัวเลือกต่าง ๆ
    • โมดูลมีค่าเริ่มต้นให้ ดังนั้นเมื่อสร้างผู้ใช้จึงไม่จำเป็นต้องกำหนด UID, GID, shell และ home directory เองทั้งหมด
    • ไฟล์อย่าง /etc/fstab หรือ /bin/sh ก็เป็นแบบอ่านอย่างเดียวเช่นกัน และหากต้องการเปลี่ยนต้องผ่านตัวจัดการแพ็กเกจ
    • การสลับคอนฟิกใกล้เคียงกับการเปลี่ยน symbolic link จึงทำได้ทันที และสามารถเลือกคอนฟิกก่อนหน้าในตอนบูตเพื่อ rollback ได้
    • /home, /etc, /var เป็นต้น ยกเว้นไดเรกทอรีพื้นที่จัดเก็บพิเศษ สามารถเปลี่ยนแปลงได้ และแม้จะสามารถแทนที่ symbolic link ของระบบด้วยอย่างอื่นได้ แต่ไม่สามารถแก้ไขซอร์สต้นฉบับได้
    • NixOS ได้รับการประเมินว่าเป็นการนำไปใช้งานที่ดี แต่แตกต่างจากระบบเดิมมากเกินไป ทำให้อัตราการนำไปใช้ต่ำแม้จะมีข้อดี

  • Endless OS

    • Endless OS เป็น OS แบบ Immutable รุ่นแรก ๆ ที่ออกมาเพื่อผู้ใช้ทั่วไป โดยมุ่งเป็นระบบที่ทนทานซึ่งใช้งานได้แม้ในประเทศที่อินเทอร์เน็ตหรือโครงข่ายไฟฟ้าครอบคลุมไม่ดี
    • แม้จะอิง Debian แต่ใช้ OSTree เพื่อทำ immutability
    • OSTree จัดการอิมเมจระบบหลัก และเพิ่มเลเยอร์คล้ายแพ็กเกจไว้ด้านบน รวมถึงเตรียมอิมเมจระบบใหม่สำหรับการบูตครั้งถัดไปได้
    • การเปลี่ยนแปลงแพ็กเกจจะถูกนำไปใช้กับเวอร์ชันระบบใหม่ที่จะใช้ในการบูตครั้งถัดไป และสามารถย้อนกลับไปยังเวอร์ชันก่อนหน้าในตอนบูตได้
    • โดยทั่วไปพาร์ทิชันเขียนได้ แต่ /usr ซึ่งเป็นพื้นที่แพ็กเกจที่ OSTree ดูแลจะถูก mount เป็นอ่านอย่างเดียว
    • /etc ไม่มี rollback
    • โปรแกรมสำหรับผู้ใช้ติดตั้งผ่าน Flatpak เพื่อลดความจำเป็นในการรีบูตทุกครั้งที่ติดตั้งแพ็กเกจใหม่
    • เดสก์ท็อป GNOME ที่ปรับแต่งแล้วมีหน้าตาคล้ายเมนูสมาร์ตโฟน โดยมุ่งให้เป็นรูปแบบที่ผู้ใช้ที่ไม่ใช่สายเทคนิคคุ้นเคย
    • การติดตั้งเครื่องมือ DevOps ไม่ได้สะดวกนัก แต่ก็ไม่ใช่ว่าทำไม่ได้

  • Fedora Silverblue

    • Fedora Silverblue อยู่ในสายต่อเนื่องจาก Project Atomic ที่พยายามทำให้ Fedora / CentOS / RHEL เป็นแบบ Immutable
    • ใช้ rpm-OSTree ซึ่งนำการเปลี่ยนแปลงของแพ็กเกจ RPM ไปใช้บน OSTree
    • ระบบประกอบด้วยอิมเมจหลักเดียวต่อรีลีส และเลเยอร์แพ็กเกจที่เพิ่มไว้ด้านบน
    • สามารถแสดงรายการเลเยอร์แพ็กเกจที่ติดตั้งได้ และเมื่อถอนแพ็กเกจ ระบบจะสร้างสแต็กทั้งหมดใหม่ ทำให้ไม่เหลือเศษตกค้างหลังถอนออก
    • กระบวนการสร้างใหม่นี้ช้ามาก
    • แม้ติดตั้งแพ็กเกจแล้ว ก็จะยังไม่ถูกนำไปใช้กับระบบที่บูตอยู่ในปัจจุบัน ดังนั้นโดยพื้นฐานต้องรีบูต และสามารถเลือกเวอร์ชันระบบก่อนหน้าในตอนบูตได้
    • rpm-OSTree มีฟีเจอร์ที่รวมการเปลี่ยนแปลงสำหรับการบูตครั้งถัดไปเข้ากับระบบ live ชั่วคราวด้วย tmpfs overlay
    • นโยบายการ mount เป็นแบบอ่านอย่างเดียว ยกเว้น /etc, /root, /var และ home directory จะอยู่ที่ /var/home โดยค่าเริ่มต้น ซึ่งอาจไม่ตรงกับที่คาดไว้
    • /etc ไม่ได้ถูกจัดการโดย rpm-OSTree จึงไม่ถูก rollback
    • /usr/local เป็น symbolic link ที่ชี้ไปยังไดเรกทอรีภายใน /var จึงทำให้ใส่การเปลี่ยนแปลงของผู้ใช้ได้ง่ายแม้ไม่มีไฟล์ RPM
    • เนื่องจากการติดตั้งแพ็กเกจช้าและต้องรีบูต จึงแนะนำให้ใช้ Flatpak หรือ toolbox
    • toolbox สร้างคอนเทนเนอร์ Fedora แบบไม่มีสิทธิ์ root เพื่อให้ใช้ไลบรารีหรือเครื่องมือสำหรับการพัฒนาจากเทอร์มินัลได้

  • OpenSUSE MicroOS / Aeon

    • OpenSUSE MicroOS เป็น spin แบบ Immutable ของ OpenSUSE Tumbleweed ที่เป็น rolling-release และใช้การนำไปใช้งานของตัวเอง
    • ทั้งระบบ ยกเว้นบางไดเรกทอรีอย่าง /home, /var อยู่บน สแนปช็อต btrfs
    • เมื่อจำเป็นต้องเปลี่ยนแปลงระบบ จะ clone สแนปช็อตปัจจุบันเป็นสแนปช็อตใหม่ แล้วนำการเปลี่ยนแปลงไปใช้กับสแนปช็อตใหม่นั้นเพื่อใช้ในการบูตครั้งถัดไป
    • ต่างจากระบบที่อิง OSTree ตรงที่ /etc ก็เป็นส่วนหนึ่งของสแนปช็อต จึง rollback ได้
    • สามารถใช้ shell ภายในสแนปช็อตใหม่เพื่อแก้ไขไฟล์ใดก็ได้ในไฟล์ซิสเต็ม จึงมีประโยชน์กับงานอย่างการใส่ไฟล์เพื่อแก้ปัญหา driver
    • อย่างไรก็ตาม การเปลี่ยนแปลงแบบนี้ไม่ได้ถูกติดตาม ทำให้ยากที่จะรับประกันว่าระบบอยู่ในสถานะ “บริสุทธิ์” หรือไม่
    • การเปลี่ยนแปลงทำผ่านคำสั่ง transactional-update โดยสามารถเพิ่ม·ลบแพ็กเกจ หรือเปิด shell ในสแนปช็อตใหม่เพื่อปรับแก้ตามต้องการได้
    • /etc รวมอยู่ในสแนปช็อต แต่ยังอ่านได้เสมอ ดังนั้นหากแก้ /etc ในสถานะ live แล้วสร้างสแนปช็อตใหม่ การเปลี่ยนแปลงนั้นจะถูกสืบทอดทันที
    • แนวทางพื้นฐานคือวางแผนให้รีบูตทุกวันหลังอัปเดต และเนื่องจากเป็น rolling-release จึงมีอัปเดตทุกวัน และก่อนรีบูตจะยังไม่ได้ประโยชน์จากแพ็กเกจใหม่
    • สามารถปิดการรีบูตอัตโนมัติได้
    • ฟีเจอร์นำการเปลี่ยนแปลงไปใช้กับระบบ live แบบเดียวกับ Silverblue ยังเป็นขั้นทดลองในขณะนี้ และยังใช้งานไม่ได้
    • แนะนำให้ใช้ distrobox แทน เพื่อใช้งานคอนเทนเนอร์แบบไม่มีสิทธิ์ root จากหลายดิสโทรในการติดตั้งเครื่องมือผู้ใช้

  • Vanilla OS

    • Vanilla OS อิง Ubuntu และเป็นระบบตระกูล Immutable ใหม่ที่มีแผนจะย้ายไปอิง Debian ในเร็ว ๆ นี้
    • immutability ถูกทำด้วย ABroot
    • ABroot มี root partition A, root partition B และพาร์ทิชันสำหรับข้อมูลถาวรอย่าง /home หรือ /var
    • ลำดับการบูตและการเปลี่ยนแปลงเป็นดังนี้
      • การบูตครั้งแรกทำจาก A และ A ถูก mount เป็นอ่านอย่างเดียว
      • การเปลี่ยนแปลงระบบ เช่น แพ็กเกจใหม่หรือการแก้ไฟล์ /etc จะถูกนำไปใช้กับ B และยังสามารถนำไปใช้กับระบบ live ผ่าน tmpfs overlay ได้ด้วย
      • หลังรีบูต จะบูตจาก B และหากสำเร็จ ABroot จะสแกนความแตกต่างระหว่าง A กับ B แล้วนำการเปลี่ยนแปลงของ B ไปใช้กับ A
      • เมื่อไม่มีการเปลี่ยนแปลงใหม่ A และ B จะเหมือนกันเสมอ
    • ข้อเสียคือสามารถ rollback ได้เฉพาะก่อนบูตเข้าสู่เวอร์ชันใหม่เท่านั้น
    • เมื่อบูตเข้าสู่เวอร์ชันใหม่แล้ว การเปลี่ยนแปลงจะถูกนำไปใช้กับพาร์ทิชันบูตก่อนหน้าด้วย ทำให้ rollback ไม่ได้อีก
    • แนวทางนี้มีประโยชน์หลัก ๆ สำหรับย้อนกลับการอัปเกรดที่ล้มเหลว หรือการเปลี่ยนแปลงที่ทดลองแบบ live
    • Vanilla OS มีตัวจัดการแพ็กเกจ apx
    • apx เป็นเครื่องมือที่สร้างโดยผู้เขียน distrobox และช่วยให้ผู้ใช้ที่ไม่ใช่ root ติดตั้งแพ็กเกจจากหลายดิสโทร เช่น Arch Linux, Fedora, Ubuntu, Nix และผสานให้เหมือนติดตั้งในเครื่องได้
    • Vanilla OS, ABroot และ apx ยังใหม่และมีจุดที่ยังไม่เรียบร้อยอยู่

  • Alpine Linux with LBU

    • Alpine Linux สามารถสร้างคอนฟิกที่ใกล้เคียง immutability ได้ด้วยคำสั่ง lbu
    • ใช้ตัวติดตั้ง Alpine เป็นระบบบูตพื้นฐาน และสร้าง tarball “การตั้งค่าที่บันทึกไว้” เพื่อนำไปใช้โดยอัตโนมัติขณะบูต
    • ทุกครั้งที่บูต ไดเรกทอรีจะถูกแตกใหม่และแพ็กเกจจะถูกติดตั้งใหม่ โดยทุกอย่างในหน่วยความจำ live สามารถเขียนได้ทั้งหมด
    • เริ่มต้นจากสถานะสะอาดเสมอแล้วนำการเปลี่ยนแปลงไปทับ และสามารถ rollback การเปลี่ยนแปลงแล้วเริ่มใหม่ได้
    • ไม่ได้ตอบโจทย์ immutability ตามนิยามข้างต้นทั้งหมด เพราะการเปลี่ยนแปลงถูกนำไปใช้บนระบบพื้นฐาน
    • เนื่องจากทั้งระบบอยู่ในหน่วยความจำ และต้องจัดการเองว่าจะบันทึก·กู้คืนอะไร จึงต้องมีความเข้าใจสูง และ archive อาจมีขนาดใหญ่ขึ้นได้
    • เอกสารก็ยังไม่เพียงพอ

ข้อดีและข้อจำกัดด้านการปฏิบัติการ

  • ข้อดี

    • หากเกิดปัญหา สามารถ rollback การเปลี่ยนแปลง ได้
    • transactional update ช่วยให้ระบบยังรันได้อย่างถูกต้องระหว่างการเปลี่ยนแปลงแพ็กเกจ

  • ข้อเสีย

    • การผสานกับ เครื่องมือจัดการคอนฟิก อย่าง Ansible, Salt, Puppet แย่มาก
    • แม้เครื่องมือจะถูกอัปเดตให้รู้วิธีนำการเปลี่ยนแปลงแพ็กเกจไปใช้แล้ว แต่ถ้าพยายามจัดการเหมือนระบบทั่วไป ส่วนใหญ่จะชนกำแพง
    • การที่ต้องรีบูตหลังเปลี่ยนแปลงเป็นเรื่องน่ารำคาญ แต่ NixOS และ Guix ไม่จำเป็นต้องรีบูตทุกครั้งที่มีการเปลี่ยนแปลง
    • ระบบที่อิง OSTree ไม่ยืดหยุ่น
      • ตัวอย่างเช่น ในเน็ตบุ๊กที่ต้องการไฟล์เพิ่มเติมในไดเรกทอรี ALSA เพื่อให้เสียงทำงาน จะเพิ่มไม่ได้หากไม่สร้างแพ็กเกจที่แจกจ่ายไฟล์นั้น
    • rollback ใกล้เคียงกับ blind rollback ทำให้ยากที่จะรู้ว่าแต่ละเวอร์ชันของระบบมีการเปลี่ยนแปลงอะไรบ้าง
    • โปรแกรมอย่าง Nix/Guix ที่ต้องมีไดเรกทอรีใน root filesystem หรือการติดตั้งซอฟต์แวร์ที่ไม่ได้แพ็กเกจไว้แบบทั้งระบบ อาจทำได้ยาก

ข้อเท็จจริงและความเข้าใจผิดเกี่ยวกับระบบ Immutable

  • หากพูดอย่างเคร่งครัด immutability ใกล้เคียงกับคำกล่าวที่ไม่จริง เพราะหลายส่วนของระบบยังคงเปลี่ยนแปลงได้
  • Immutable ไม่ได้หมายถึง stateless
  • NixOS และ Guix ติดตามทั้งระบบด้วยตัวจัดการแพ็กเกจที่เสถียร และสามารถใช้ระบบควบคุมเวอร์ชันกับซอร์สได้ จึงถูกมองว่าเป็นการนำไปใช้งานที่มีปรัชญาถูกต้องมาตั้งแต่แรก
  • immutability มักถูกเชื่อมโยงกับข้อดีด้านความปลอดภัย แต่ผู้โจมตีที่ได้สิทธิ์ root สามารถแก้ไขระบบ live และแตะต้องพาร์ทิชัน /boot ได้ด้วย
  • ไม่มีอะไรป้องกันการติดตั้ง backdoor สำหรับใช้ในการบูตครั้งถัดไป
  • immutability ต้องการ วินัยและการบำรุงรักษา
    • ต้องใส่ใจกับการควบคุมเวอร์ชัน
    • โปรแกรมเพิ่มเติมอย่าง apx, distrobox, devbox ต้องอัปเดตแยกจากระบบ
    • NixOS และ Guix รวมส่วนนี้ไว้แล้ว

สิ่งที่ใหม่ขึ้นจริง ๆ

  • ระบบปฏิบัติการแบบ Immutable กำลังได้รับความสนใจในชุมชนระบบโอเพนซอร์ส แต่ภายใต้คำเดียวกันมีการนำไปใช้งานและ use case หลายแบบปะปนกัน
  • ชื่อ “Immutable” สร้างความคาดหวังบางอย่างให้ผู้ใช้ แต่ในความเป็นจริงใกล้เคียงกับ transactional update สำหรับระบบปฏิบัติการมากกว่า
  • transactional update เองไม่ใช่แนวคิดใหม่
    • Solaris และ ZFS สามารถเลือกสแนปช็อตของระบบตอนบูตได้
    • FreeBSD ดูเหมือนจะเคยนำฟีเจอร์คล้ายกันมาใช้เมื่อราว 10 ปีก่อน
    • ดิสโทร Linux ทั่วไปก็สามารถเลือกสแนปช็อตตอนบูตได้หากใช้สแนปช็อต btrfs
  • สิ่งที่ใหม่จริง ๆ คือการนำการเปลี่ยนแปลงแบบ transaction ไปใช้กับ สภาพแวดล้อมที่ไม่ใช่ live ผสานเข้ากับ bootloader และมีเครื่องมือให้ผู้ใช้จัดการได้ง่าย
  • แนะนำให้อ่านเพิ่มเติมจากบทความของ Colin Walters เรื่อง “Immutable” → reprovisionable, anti-hysteresis

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

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

 
GN⁺ 2023-09-19
ความคิดเห็นจาก Hacker News

  • ดีใจที่เห็น Silverblue อยู่ในรายการ แต่เสียดายที่ Fedora CoreOS หายไป
    FCOS เป็น OS ที่เหมาะกับการใช้ในโปรดักชัน และพัฒนาขึ้นมากหลังการเข้าซื้อ CoreOS ดูเหมือนเป็นจุดกึ่งกลางที่ดีเมื่อเทียบกับ Nix คือเรียนรู้ง่ายกว่า ใช้งานสะดวกกว่า แต่ยังคงความไม่เปลี่ยนรูปไว้ได้
    CoreOS Layering ที่ทีมพัฒนา FCOS เพิ่มเข้ามาเป็นฟีเจอร์ทรงพลังที่ให้กำหนดสถานะของระบบด้วย Dockerfile จากนั้น FCOS จะ rebase ไปยังสถานะนั้น และการตั้งค่าเซิร์ฟเวอร์ก็แค่รีบูตเท่านั้น
    ถ้าโปรเจกต์ถัดไปต้องใช้ VM ก็น่าลองใช้ดู ผมยังทำ Bupy ซึ่งเป็นเครื่องมือ CLI บน Python ที่ช่วยให้สร้างไฟล์ Butane แบบโลคัลบน Linux workstation ได้ง่ายขึ้น และมีตัวอย่างการรัน Paperless NGX ด้วย CoreOS Layering ด้วย
    https://github.com/quickvm/bupy
    https://github.com/quickvm/fcos-layer-paperless-ngx
    https://coreos.github.io/rpm-ostree/container/
    https://github.com/coreos/enhancements/blob/main/os/coreos-l...
    https://github.com/coreos/layering-examples

    • อยากรู้ว่าคิดอย่างไรกับ Flatcar ซึ่งเป็นอีกโปรเจกต์ในสาย CoreOS
      สิ่งที่ยากที่สุดคือควรใช้โปรเจกต์แบบนี้อย่างไรในสภาพแวดล้อม bare metal การสร้าง VM image นั้นเจ๋ง แต่ในความเป็นจริง หลายครั้งก็อยากติดตั้งลงไดรฟ์เดิม หรืออยากติดตั้งโดยมี ZFS pool อยู่ข้างใต้
    • CoreOS Layering ดูมีประโยชน์มากจริง ๆ ตอนนี้ผมใช้ openSUSE MicroOS กับ Raspberry Pi หลายตัวและเซิร์ฟเวอร์ x86_64 อยู่ และหนึ่งในเหตุผลที่เลือก MicroOS คือการติดตั้งบน Raspberry Pi ค่อนข้างง่าย
      อยากรู้ว่าการติดตั้ง CoreOS บน Raspberry Pi ยากแค่ไหน คู่มือติดตั้งบางส่วนบนอินเทอร์เน็ตดูค่อนข้างซับซ้อน

  • อีกแกนหนึ่งที่มักขาดหายไปเสมอในการแนะนำระบบแบบไม่เปลี่ยนรูปแบบนี้คือแนวทางแบบ image-based
    ผมกำลังทำงานร่วมกับคนที่เก่งกว่าผมมากที่ https://universal-blue.org/ โดยเราสร้าง OCI container image บน Fedora Silverblue รุ่นพื้นฐานและเดสก์ท็อปเอดิชันต่าง ๆ
    image เหล่านี้สามารถบูตด้วย rpm-ostree หรือพูดให้แม่นกว่านั้นคือ rebase ได้ และเป็นวิธีขยายระบบที่แข็งแรงกว่าการทำ layering อีกทั้งใคร ๆ ก็สามารถสืบทอดหรือใช้การเปลี่ยนแปลงเดียวกันได้ง่าย การสร้าง image เองก็ง่ายมากเช่นกัน
    VanillaOS กับ SUSE ก็น่าจะทำสิ่งคล้ายกัน แต่เราไม่ใช่โปรเจกต์ OS เป็นเพียง downstream ของ Fedora เท่านั้น การสนับสนุนอย่างเป็นทางการจาก Fedora ก็กำลังดำเนินอยู่ และเท่าที่ใช้งานได้แล้วในตอนนี้ จากประสบการณ์มันเป็นหนึ่งในวิธีที่แข็งแรงและง่ายที่สุดสำหรับงานอย่างการจัดหาไดรเวอร์ Nvidia

    • ออกนอกเรื่องนิดหน่อย แต่ราวปี 2009 ผมเคยเห็น hypervisor ขนาดใหญ่ที่รันโฮสต์ Windows Remote Desktop แล้วรู้สึกทึ่งมาก น่าจะเป็น Citrix
      VM บูตจาก image และทั้ง image กับดิสก์ส่วนต่างการเปลี่ยนแปลงอยู่ใน RAM ทั้งหมด โปรไฟล์ผู้ใช้อยู่บนฮาร์ดดิสก์ แต่ desktop host สำหรับ 25 คนบูตจนพร้อมรับ remote login ได้ในราว 4 วินาที
      มันเป็นระบบ Windows ที่แพตช์แล้วเจ็บปวดน้อยที่สุด
    • ผมสับสนว่า Fedora Silverblue ก็เป็นแบบ image-based ไม่ใช่หรือ
      เข้าใจว่าการติดตั้งพื้นฐานไม่ได้ใช้ layering และ layering จะเข้ามาเฉพาะตอนที่อยากติดตั้งแพ็กเกจ RPM เพิ่มเท่านั้น
    • ดูเหมือน UBlue จะ rebuild image เป็นประจำด้วย GitHub Actions เพื่อรวม package update เข้าไป อยากรู้ว่าใครเป็นคนจ่ายค่าใช้จ่าย
      อยากรู้ด้วยว่า image ถูกให้บริการจาก GitHub ด้วยหรือไม่, GitHub คิดค่าทราฟฟิกขาออกหรือเปล่า และถ้าผู้ใช้จำนวนมากพยายามดาวน์โหลด image เดียวกันจะเกิดอะไรขึ้น

  • ผมสนใจ ระบบที่กำหนดค่าไว้ล่วงหน้า มากกว่าระบบแบบไม่เปลี่ยนรูป
    ในจุดนี้ NixOS กับ Home Manager เด่นมาก แต่รูปแบบการตั้งค่าน่ากลัวจริง ๆ ผมอยากใส่การตั้งค่าทั้งหมดไว้ใน source control และรู้ว่าสถานะปัจจุบันของระบบตรงกับการตั้งค่านั้น ส่วนการเปลี่ยนแปลงอื่น ๆ อยากให้ถูกลบทิ้งเมื่อรีบูต ถ้าก่อนรีบูตมีอะไรเปลี่ยนไปก็น่าจะมีการไฮไลต์ให้เห็น
    จากประสบการณ์จำกัดที่เคยลองใช้ของอย่าง Silverblue คือสามารถกำหนดค่าระบบพื้นฐานได้ แต่พอเริ่มเพิ่มแอปอย่าง Firefox ก็จะไปใช้ Flatpak และผมยังไม่ค่อยรู้วิธีประกาศการติดตั้ง Flatpak ทั้งหมดที่ต้องการพร้อมกับการตั้งค่าของมัน
    น่าจะมีวิธีติดตั้ง Flatpak แบบเป็นชุดแล้วจัดการส่วนที่เหลือด้วย dotfile อยู่บ้าง
    https://universal-blue.org/tinker/mindset/#resist-the-urge-t...

    • ถ้าต้องการให้ “สิ่งอื่น ๆ ถูกลบทิ้งเมื่อรีบูต” อยากรู้ว่าเคยลองใช้ Impermanence หรือยัง
      https://nixos.wiki/wiki/Impermanence
    • อยากรู้ว่าเคยลองใช้ nix package manager บน Silverblue หรือยัง
      https://julianhofer.eu/blog/01-silverblue-nix/
      วิธีนี้ช่วยลดส่วนการตั้งค่า Nix ที่เห็นตรงกันว่าน่ากลัวให้เหลือน้อยที่สุด

  • ปัญหาที่เจอทั้งกับ Flatpak และแนวทางแบบไม่เปลี่ยนรูปโดยรวม คือเราแก้ไขในแบบที่นักพัฒนาไม่ได้รองรับไม่ได้
    เช่น ผมซิงก์ปฏิทินด้วย decsync และเท่าที่รู้ เป็นไปไม่ได้ที่จะเพิ่ม ปลั๊กอิน decsync ให้กับ Evolution Flatpak
    จนกว่าระบบแบบไม่เปลี่ยนรูปเหล่านี้จะรองรับการซ้อนระบบไฟล์โอเวอร์เลย์แบบกำหนดเองเป็นฟีเจอร์ระดับหลัก สำหรับกรณีใช้งานที่นักพัฒนาไม่สามารถรองรับหรือไม่รองรับ ผู้คนก็จะยังใช้ระบบแบบเปลี่ยนแปลงได้ต่อไป

    • NixOS ให้การควบคุมแบบนี้อยู่แล้วในหลายวิธี
      แพ็กเกจบางส่วนใน nixpkgs รวมถึงโมดูล NixOS และ Home Manager ส่วนใหญ่ เปิดเผยตัวเลือกจำนวนมากสำหรับตั้งค่าปลั๊กอิน แพ็กเกจเพิ่มเติม ฯลฯ
      Nix ยังมี overlay และ override สำหรับเพิ่มแพ็กเกจแบบกำหนดเองหรือแพ็กเกจเดิมในรูปแบบดัดแปลง และยังเปลี่ยนบางส่วนของแพ็กเกจได้ด้วย หากยังไม่พอ ก็สามารถใส่แพตช์ลงในโค้ดโดยตรง หรือบิลด์จาก fork ของคลัง upstream ได้
      จริง ๆ แล้วนี่เป็นหนึ่งในส่วนที่ผมชอบที่สุดใน Nix เพราะมันทำให้พูดว่า “ตอนบิลด์แพ็กเกจนี้ ให้เปลี่ยน dependency ตัวนี้เป็นเวอร์ชันของฉัน” ได้ง่าย จนทำให้ผมมีส่วนร่วมกับโอเพนซอร์สบ่อยขึ้น
    • เรื่องอย่าง “เพิ่มปลั๊กอิน decsync ให้กับ Evolution Flatpak” เป็นเรื่องพบได้บ่อยมากในซอฟต์แวร์ GUI บน Linux
      นอกพื้นที่นี้ ซอฟต์แวร์ส่วนใหญ่มักมาพร้อมฟังก์ชันที่จำเป็นอยู่แล้ว เช่น Solidworks ไม่เคยบอกให้ผมไปดาวน์โหลด dependency เสริม แต่ FreeCAD ขออะไรสักอย่างแทบจะทุก 15 นาทีจริง ๆ ทุกครั้งที่ขยับไปขั้นตอนถัดไปของโฟลว์ CAD/CAM/ซิมูเลชัน/เรนเดอร์
      https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv... ก็น่าอ่านประกอบ
      ใจความสำคัญคือ “20% ที่ทุกคนใช้” ไม่เคยเป็นชุดเดียวกันเลย ตลอด 10 ปีที่ผ่านมา ผมได้ยินเรื่องบริษัทเป็นสิบ ๆ แห่งที่พยายามออกเวิร์ดโปรเซสเซอร์แบบ “lite” ซึ่งมีแค่ 20% ของฟีเจอร์ แล้วนักข่าวที่กำลังเขียนรีวิวก็ไปหาฟังก์ชันนับจำนวนคำ แต่ฟังก์ชันนั้นดันอยู่ใน “80% ที่ไม่มีใครใช้” สุดท้ายก็เขียนทำนองว่า “โปรแกรมเบาก็ดี ความอืดบวมก็แย่ แต่ของบ้านี่นับจำนวนคำไม่ได้ เลยใช้ไม่ได้” เรื่องแบบนี้เก่าแก่พอ ๆ กับ PC แล้ว
    • ถ้าถึงขั้นจะซ้อนระบบไฟล์โอเวอร์เลย์แบบกำหนดเองเป็นฟีเจอร์ระดับหลัก ผมก็คิดว่าใช้ ระบบแบบเปลี่ยนแปลงได้ ไปเลยไม่ดีกว่าหรือ
      ทำให้นึกถึงเมื่อ 10 ปีก่อนที่ทุกคนวิ่งไปหา NoSQL แล้วไม่นานก็เริ่มประดิษฐ์ schema ขึ้นมาใหม่ในแต่ละโปรเจกต์
    • แอปพลิเคชัน Flatpak ก็เพิ่มปลั๊กอินได้เช่นกัน และปลั๊กอินแบบนี้ทำเป็น แพ็กเกจส่วนขยาย ได้
      OBS เป็นตัวอย่างหนึ่ง บน Flathub มีปลั๊กอิน OBS หลายตัวในรูปแบบ com.obsproject.Studio.Plugin.*

  • ผมคิดว่านิยามควรเป็นแบบนี้: หลังจากติดตั้งแพ็กเกจกี่ตัวก็ได้ แล้วในอนาคตจะลบออก ณ เวลาใดและในลำดับใดก็ตาม ระบบควรกลับไปสู่สถานะที่ เทียบเท่า กับตอนที่ไม่เคยติดตั้งตั้งแต่แรก
    นิยามนี้อาจทำให้บางดิสโทรถูกตัดออกไป แต่ผมมองว่าส่วนสำคัญของแนวคิดนี้ก็คือคุณสมบัตินั้น

    • ประเด็นสำคัญดูเหมือนจะเป็นว่า คุณสมบัตินั้นแทบเป็นไปไม่ได้สำหรับระบบที่ผู้ใช้ใช้งานจริง
      เวลาลบเวิร์ดโปรเซสเซอร์หรือโปรแกรมแก้ไขข้อความ คุณอยากให้ไฟล์ทั้งหมดที่เคยเขียนไว้หายไปด้วยหรือไม่? ถ้าลบเบราว์เซอร์ ไฟล์ที่ดาวน์โหลดมาทั้งหมดควรหายไปด้วยหรือไม่? ถ้าไม่ใช่ ก็ไม่มีวิธีที่เชื่อถือได้ในการแยกแยะว่าไฟล์ไหนเป็นไฟล์ที่โปรแกรมสร้างเองโดยอัตโนมัติ และไฟล์ไหนเป็นไฟล์ที่ผู้ใช้สร้างด้วยโปรแกรมนั้น
      สิ่งที่ถูกสร้างระหว่างการติดตั้งสามารถลบได้ง่าย แต่การเปลี่ยนแปลงทั้งหมดหลังจากนั้นทำไม่ได้
      ลองนึกถึงกรณีที่เปลี่ยน implementation ของ DNS แล้วภายหลังเปลี่ยนเซิร์ฟเวอร์ DNS ค่าเริ่มต้นด้วย เมื่อถอด provider ออกเพื่อกลับไปยัง implementation เดิม ต้องเลือกว่า จะย้อนกลับไปใช้เซิร์ฟเวอร์เดิมด้วยหรือจะคงค่าตั้งเซิร์ฟเวอร์ใหม่ไว้ โดยส่วนตัวผมอยากเปลี่ยนเฉพาะ provider และคงเซิร์ฟเวอร์ใหม่ไว้
      ไดเรกทอรีที่หลายเครื่องแชร์กันก็ทำให้ยากเช่นกัน ถ้าให้ /home/${USER} เป็นเมานต์ NFS หรือ Samba แล้วใช้ไฟล์เดียวกันจากหลายเวิร์กสเตชัน เมื่อโปรแกรมใดโปรแกรมหนึ่งสร้างไฟล์ในไดเรกทอรีตั้งค่า XDG แล้วลบโปรแกรมนั้นออกจากเวิร์กสเตชันหนึ่ง ควรลบไฟล์บนทุกเครื่องด้วยหรือไม่? package manager ของระบบเดี่ยวไม่มีทางรู้ได้ว่าอุปกรณ์ทั้งหมดต้องเหมือนกันหรือแค่โฮมไดเรกทอรีต้องเหมือนกัน
    • ปัญหาคืออยากให้คุณสมบัตินั้นใช้ลึกลงไปแค่ไหน
      ควรลองดู โครงสร้างข้อมูลแบบมีตัวแทนเอกลักษณ์ และ โครงสร้างข้อมูลแบบไม่ขึ้นกับประวัติ
      อุปกรณ์บล็อก เช่น SSD คงต้องใส่ใจเป็นพิเศษให้จัดสรรบล็อกโดยไม่ขึ้นกับประวัติ
    • คุณสมบัตินั้นเรียกว่า ความสามารถในการทำซ้ำได้ และหมายถึงการตั้งค่าเดียวกันจะสร้างสถานะระบบเดียวกันเสมอ
    • ผมชอบนิยามนั้น
      อาจพูดได้ด้วยว่า ชุดของแพ็กเกจประกอบกันเป็น lattice และไม่ว่าจะไปถึงแพ็กเกจบางสับเซตผ่านเส้นทางใด สถานะก็มีเพียงสถานะเดียว

  • ผมใช้ Fedora Silverblue มาตั้งแต่ตอนเปิดตัว และนี่แหละคืออนาคตอย่างแน่นอน
    ผมคิดว่าทุกคนควรใช้ ostree

    • ผมรู้สึกว่า Silverblue ยังไม่ยืดหยุ่นพอสำหรับคอมพิวเตอร์ส่วนตัว
      อาจเป็นเพราะผมใช้ Linux แบบค่อนข้างตามใจไปหน่อย แต่การไม่มีสิทธิ์เขียนในโฟลเดอร์อย่าง /usr หรือ /bin ทำให้ผมหงุดหงิดแทบทุกสองสัปดาห์
      เช่น สคริปต์ที่ผู้ใช้ Ubuntu เขียนไว้กำลังหาไลบรารีตามชื่อและตำแหน่งแบบ Ubuntu แต่ Fedora ใช้ชื่ออื่นสำหรับไลบรารีนั้น ในกรณีแบบนี้ สัญชาตญาณของผมคือสร้าง symbolic link ด้วยชื่อแบบ Ubuntu ให้ชี้ไปยังไลบรารีที่ Fedora RPM จัดการอยู่
      แต่ในความเป็นจริง เพื่อให้มันทำงานได้ ผมต้อง fork สคริปต์ ทำให้ build ในเครื่องได้ แก้ให้หาได้ทั้งสองชื่อไลบรารี รันเทสต์ในเครื่อง ส่ง PR ไป upstream ฯลฯ งานที่ปกติใช้คำสั่ง shell บรรทัดเดียวจบ กลายเป็นงาน 90 นาที
    • ใช้มาครบ 1 ปีแล้วและดีมากจริง ๆ ผมสงสัยว่า Red Hat รู้หรือเปล่าว่าตัวเองมีอะไรอยู่ในมือ ไม่ใช่แค่ Silverblue แต่รวมถึง Fedora เองด้วย
      ผมเคยอ่านคำตอบใน Quora ที่ประเมินงบพัฒนา Windows OS จากฐานเงินเดือนว่าอยู่ราว 18 พันล้านดอลลาร์ ลองจินตนาการว่า Red Hat ลงทุน 2 พันล้านดอลลาร์กับ Fedora แล้วทำให้มันกลายเป็น Firefox แห่งโลกเดสก์ท็อป OS ถ้าแย่งส่วนแบ่งจาก Microsoft ได้แค่ 10% ก็ถือว่าใหญ่มากแล้ว
      Fedora มาได้ไกลถึงขนาดนี้ด้วยทรัพยากรน้อยมาก บนแพ็กเกจโอเพนซอร์สนับพัน ๆ ตัว เงินนั้นสามารถใช้ประคับประคองโปรเจกต์เหล่านี้ให้ดำเนินต่อไปและสนับสนุนระหว่างการพัฒนาได้ พนักงานของ Red Hat ก็มีส่วนเกี่ยวข้องกับโปรเจกต์จำนวนมากในนั้นอยู่แล้ว
    • ผมชอบแนวคิดของ ostree แต่จากที่อ่านผ่าน ๆ มันดูไม่เป็นมิตรกับผู้ใช้ทั่วไปหรือระดับกลางเท่า Docker ผู้ใช้ส่วนตัวสามารถเรียน Docker ได้ภายในบ่ายเดียว
      ผมยังไม่เห็นชัดว่าจะไปถึงจุด “แจกจ่าย Debian distro ในรูป ostree snapshot” ได้อย่างไร
      เลยสงสัยว่านี่ถูกออกแบบมาสำหรับผู้ดูแลระบบมืออาชีพหรือคนสร้างระบบเท่านั้นหรือเปล่า
    • ถ้าเคยใช้ Nix ก็อยากรู้ว่าเทียบกันแล้วเป็นอย่างไร
      ผมยังไม่เคยใช้ Silverblue แต่ Nix ก็ให้ความรู้สึกเหมือนอนาคตเหมือนกัน
    • ตอนนี้ผมใช้ Ubuntu บนเซิร์ฟเวอร์ และเห็นว่ามี ostree อยู่ใน repository แต่ยังไม่ได้ลอง
      ถ้าเป็นไปได้ ผมอยากเริ่มทำ version control กับระบบปัจจุบันทั้งอย่างนั้นเลย ถ้ามันยากเกินไปหรือเป็นไปไม่ได้ สักวันคงย้ายเซิร์ฟเวอร์ไป Silverblue ผมชอบแนวคิดของ ostree มาก

  • ฤดูร้อนนี้ผมติด Tinycore มาก
    มันช่วยเสริมปรัชญาความปลอดภัยแบบ “หนึ่ง OS ต่อหนึ่งฟังก์ชัน” ที่เป็นพื้นฐานของ Qubes, Tails, Whonix ซึ่งเราเพิ่งคุยกันที่นี่เมื่อไม่กี่วันก่อน ได้ดีมาก
    เพราะมันเบามาก จึงเปิด VM หนึ่งตัวสำหรับ mail server, อีกตัวสำหรับ database, อีกตัวสำหรับ firewall/router ได้ภายในไม่กี่วินาที
    Tinycore เองเป็นแบบ immutable อยู่แล้ว ดังนั้นแค่ใส่ “แพ็กเกจ” และการตั้งค่าไว้ใน vdisk แล้วทำเครื่องหมายเป็น read-only ก็พอ มีสคริปต์ Virsh ตัวหนึ่งจัดการการเริ่มและหยุด “service” โดยแต่ละ service คืออินสแตนซ์ของ Tinycore
    สนุกดี และจนถึงตอนนี้ก็ดูแข็งแรง แต่ยังไม่แน่ใจว่าจะเอาไปใส่ production ของใครหรือไม่

    • TinyCore มักถูกมองข้ามเสมอเวลาแนะนำ immutable Linux แบบนี้ ทั้งที่มีมานานแล้วและออกแบบได้ดีมาก
      การ implementation ยังมีจุดที่น่าเสียดายอยู่บ้าง และคงไม่มีบริษัทสปอนเซอร์ที่จะช่วยอธิบายว่าทำไมคนถึงไม่ค่อยรู้จัก
      ต่างจาก immutable Linux distro อื่น ๆ มัน แข็งแรงและเรียบง่าย

  • ผมใช้ Fedora Sericea มาตลอดตั้งแต่เปิดตัว โดยพื้นฐานแล้วคือ Fedora Silverblue แต่ใช้ Sway-wm แทน Gnome-wm
    ใช้งานจริงได้ค่อนข้างดี และไม่จำเป็นต้องรีบูตทุกครั้งหลังใช้คำสั่ง rpm-ostree install ด้วย rpm-ostree live-apply จัดการให้ผ่าน overlay ที่ใช้ systemd

    • ในช่วง 2 สัปดาห์ที่ผ่านมา ผมใช้ Fedora Workstation อยู่ และในฐานะคนที่กลับมาใช้ Linux อีกครั้งหลังห่างไป 20 ปี บอกได้เลยว่าประสบการณ์ดีขึ้นอย่างมหาศาล
      ยังไม่มีเหตุให้ต้องบูตกลับไป Windows เลย ถ้าตลอด 6 เดือนข้างหน้ายังเป็นแบบนี้ ผมคงย้ายมา Linux เต็มตัวและลบพาร์ทิชัน Windows ทิ้ง
    • แต่ถ้าจะใช้ kernel ใหม่จริง ๆ ก็ยังต้องรีบูตอยู่ไม่ใช่หรือ? หรือสงสัยว่ามันเปลี่ยน kernel ด้วยอะไรอย่าง kexec หรือเปล่า

  • สำหรับคำพูดที่ว่า “immutability เป็นเรื่องโกหก และส่วนใหญ่ของระบบยังเปลี่ยนแปลงได้ เพียงแต่ไม่รู้ว่าจะอธิบายตระกูลนี้ด้วยคำอื่นอย่างไรดี อะไรสักอย่างแบบ transaction?” ในกรณีของ Nix ฟังดูเหมือนเน้นที่ reproducibility มากกว่า
    หมายความว่าถ้าเอาไฟล์ตั้งค่า Nix ไปวางในเครื่องอื่น ก็ควรได้ระบบแบบเดียวกัน ยกเว้นประมาณ /home
    ส่วนตัวอื่น ๆ ดูเหมือนใกล้เคียงกับการให้ฟังก์ชัน snapshot และ rollback ที่เครื่องมือเดิมมีอยู่แล้ว แต่ใช้ implementation อีกแบบหนึ่ง

    • คำว่า “immutable” เอามาใช้ตรงนี้แล้วดูแปลก
      ถ้าหมายถึงการไม่อัปเกรดระบบบน live system, การเปลี่ยนแพ็กเกจจะมีผลในการบูตครั้งถัดไป และสามารถ rollback การเปลี่ยนแปลงได้ นั่นใกล้เคียงกับ atomic transaction แบบฐานข้อมูลมากกว่า เพียงแต่การต้องปิดระบบเพื่อ commit นั้นออกจะเกินไปหน่อย
      Microsoft เคยใส่ atomic transaction ลงใน filesystem เมื่อหลายปีก่อน แต่ filesystem transaction ไม่ได้ถูกใช้กันมากนัก
      ระบบติดตั้งควรจะ commit การเปลี่ยนแปลงทั้งหมดพร้อมกัน และถ้ามีปัญหาระหว่างติดตั้ง ก็ rollback กลับไปสถานะเดิมโดยไม่ commit อะไรเลยได้ ตามทฤษฎีแล้วทำได้ด้วย transactional filesystem แต่ในทางปฏิบัติน่าจะมี state อื่นที่ไม่ใช่ filesystem เข้ามาเกี่ยวพันมากเกินไป

  • ฝั่งเซิร์ฟเวอร์มี Bottlerocket OS ของ Amazon
    แนวคิดคือใช้พาร์ทิชัน A/B สำหรับการอัปเกรด และสิ่งที่ไม่ใช่ระบบพื้นฐานทั้งหมดให้รันเป็น container
    การตั้งค่าแบบกำหนดเองตอนบูตใช้ boot container ส่วนบริการที่รันระยะยาวใช้ host-container หรือใน Kubernetes ก็ใช้ DaemonSet
    https://github.com/bottlerocket-os/bottlerocket