ดิสโทรที่สร้างบน Arch เปลี่ยนอะไรบ้าง แยกดูทีละชั้น

ลองถามใน subreddit ของ CachyOS ว่าควรติดตั้ง CachyOS หรือ Omarchy แล้วสองคำตอบที่ได้คะแนนสูงสุดไม่ใช่คำแนะนำเลย คำตอบหนึ่งเขียนว่า "Asking this in related to CachyOS sub…bruh" อีกคำตอบเปรียบว่าเหมือนเดินเข้าฟอรัม Honda แล้วถามว่าควรซื้อ Accord หรือ Camry

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

เวอร์ชันสั้น

• สำหรับดิสทริบิวชันที่เปรียบเทียบในบทความนี้ ความแตกต่างที่มีประโยชน์ส่วนใหญ่ตกอยู่ในห้าชั้น ได้แก่ ตัวติดตั้ง เคอร์เนลและเป้าหมายการคอมไพล์ คลังแพ็กเกจ เชลล์เดสก์ท็อปและการตั้งค่า นโยบายการอัปเดตและย้อนกลับ
• โครงการหนึ่งสามารถเปลี่ยนแค่ชั้นเดียวแล้วปล่อยอีกสี่ชั้นไว้ตามเดิม ซึ่งเป็นเหตุผลว่าทำไมสองดิสทริบิวชันถึงเป็น "สร้างบน Arch" ทั้งคู่ แต่แทบไม่มีอะไรเหมือนกันเลย
• CachyOS เปลี่ยนชั้นเคอร์เนล/การคอมไพล์และชั้นคลังแพ็กเกจอย่างหนัก คัดสรรตัวติดตั้ง และไม่บังคับเชลล์เดสก์ท็อปใดๆ คุณเลือกเองตอนติดตั้ง
• Omarchy เปลี่ยนชั้นเชลล์เดสก์ท็อปและชั้นนโยบายการอัปเดตอย่างหนัก มีช่องทางแพ็กเกจของตัวเอง และไม่แก้ไขเคอร์เนลหรือเป้าหมายการคอมไพล์เพื่อประสิทธิภาพ
• แต่ละชั้นนำไปใช้แยกกันได้ CachyOS มีเอกสารสำหรับการเพิ่มคลังแพ็กเกจของตนลงในการติดตั้ง Arch ที่มีอยู่ และมีคนลองเส้นทางนี้บน Omarchy แล้วได้ผลลัพธ์ปะปนกัน

สิ่งที่บทความนี้ไม่ได้ตัดสิน

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

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

ห้าชั้นที่การเปรียบเทียบนี้ติดตาม

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

ตัวติดตั้งคือเส้นทางจากเครื่องเปล่าไปสู่ระบบที่บูตได้ และเป็นชั้นที่โครงการตัดสินใจว่าจะยกทางเลือกให้คุณมากแค่ไหน Arch ดั้งเดิมมีเอกสารเส้นทางติดตั้งด้วยมือ และยังรวมตัวติดตั้งแบบมีตัวช่วย archinstall ไว้ใน ISO แบบ live ด้วย แต่ดิสโทรลูกก็ยังแทนที่ประสบการณ์นั้นด้วยค่าเริ่มต้นแบบมีตัวช่วยของตัวเองได้ สิ่งสำคัญคือตัวติดตั้งนั้นตัดสินใจอะไรแทนคุณบ้าง ระบบไฟล์ บูตโหลดเดอร์ การเข้ารหัส ไดรเวอร์ เดสก์ท็อป ค่าเริ่มต้นแต่ละอย่างคือจุดยืนที่ใครสักคนเลือกไว้

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

เป้าหมายการคอมไพล์คือระดับไมโครสถาปัตยกรรมที่แพ็กเกจถูกสร้างมาให้ x86-64 คือฐานที่โปรเซสเซอร์ x86-64 ทุกตัวรองรับ x86-64-v3 เพิ่มคุณสมบัติอย่าง AVX, AVX2, BMI1, BMI2 และ FMA ส่วน x86-64-v4 เพิ่มข้อกำหนด AVX-512 ต่อยอดจาก v3 แพ็กเกจที่สร้างสำหรับระดับใดระดับหนึ่งจะไม่เริ่มทำงานบนโปรเซสเซอร์ที่ขาดชุดคุณสมบัติที่ต้องการ ตัวจัดตารางตัดสินว่างานที่พร้อมรันตัวไหนจะได้โปรเซสเซอร์เป็นตัวถัดไป และตัวจัดตารางแต่ละตัวชั่งน้ำหนักระหว่างปริมาณงานกับการตอบสนองแบบโต้ตอบต่างกัน ดิสโทรลูกอาจเปลี่ยนทั้งสามอย่าง อย่างเดียว หรือไม่เปลี่ยนเลยก็ได้

ชั้นคลังแพ็กเกจเป็นเรื่องของที่มา คุณได้บิลด์ของแพ็กเกจจากใคร ใหม่แค่ไหน และใครควบคุมช่องทางที่มันส่งมาถึง Arch ดั้งเดิมดึงไบนารีจาก core, extra และ multilib โดยมี AUR อยู่ข้างๆ ในฐานะสูตรบิลด์ที่คุณคอมไพล์เอง ดิสโทรลูกอาจซ้อนคลังของตัวเองไว้ด้านบน ใส่ความล่าช้าโดยตั้งใจไว้หน้าคลังของ Arch หรือทำทั้งสองอย่าง

ชั้นเชลล์เดสก์ท็อปและการตั้งค่าคือสิ่งที่ปรากฏบนหน้าจอและวิธีจัดวาง และเป็นจุดที่คำศัพท์ทำให้คนสะดุด สภาพแวดล้อมเดสก์ท็อปอย่าง KDE Plasma หรือ GNOME เป็นชุดครบ ทั้งการจัดการหน้าต่าง แผง ตัวจัดการไฟล์ การตั้งค่า แอปพลิเคชัน ส่วนตัวจัดการหน้าต่างแบบเรียงต่อกันอย่าง i3 หรือคอมโพสิเตอร์ Wayland แบบเรียงต่อกันอย่าง Hyprland จัดการการวางหน้าต่างโดยไม่ให้ชุดเดสก์ท็อปครบชุด ปล่อยให้แถบ ตัวเรียกใช้ การแจ้งเตือน และหน้าจอล็อกเป็นชิ้นส่วนแยกกัน ดิสโทรลูกอาจบังคับเชลล์ เสนอเมนูให้เลือก หรือไม่แสดงจุดยืนเลย

ชั้นการอัปเดตและย้อนกลับครอบคลุมว่าระบบเดินหน้าอย่างไรและคุณกลับมาได้อย่างไรเมื่อมันเดินไปผิดทาง บน Arch ดั้งเดิมทั้งสองอย่างเป็นของคุณ pacman -Syu เมื่อคุณตัดสินใจ กู้คืนผ่านแคชแพ็กเกจหรือระบบสแนปช็อตที่คุณสร้างเอง ดิสโทรลูกอาจห่อคำสั่งนั้น ตั้งด่านกั้น หรือปล่อยไว้ และอาจทำให้การกู้คืนเป็นค่าเริ่มต้นด้วยการจัดวางระบบไฟล์ให้สแนปช็อตมีต้นทุนต่ำ นั่นคือสิ่งที่การจัดวางซับวอลุ่ม Btrfs ให้มา สแนปช็อตคือสำเนา ณ จุดเวลาหนึ่งของซับวอลุ่มหนึ่ง และเมื่อผสานกับบูตโหลดเดอร์ ดิสโทรลูกสามารถแสดงสแนปช็อตเหล่านั้นเป็นตัวเลือกกู้คืนได้

CachyOS เปลี่ยนอะไร

CachyOS เปลี่ยนชั้นเคอร์เนลและเป้าหมายการคอมไพล์กับชั้นคลังแพ็กเกจอย่างหนัก คัดสรรตัวติดตั้ง และไม่บังคับเชลล์เดสก์ท็อปใดๆ มันส่งมอบบิลด์เคอร์เนลของตัวเองและคอมไพล์แพ็กเกจของ Arch ใหม่สำหรับระดับคุณสมบัติ CPU ที่ใหม่กว่า แล้วปล่อยให้สิ่งที่ปรากฏบนหน้าจอเป็นเรื่องของคนที่ติดตั้ง

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

เคอร์เนล linux-cachyos เริ่มต้นสร้างด้วย Clang ThinLTO และการทำโปรไฟล์ AutoFDO และตระกูลนี้มี BORE, EEVDF และ BMQ เป็นตัวจัดตารางที่เลือกได้ แยกต่างหาก มันรองรับ sched-ext ซึ่งเป็นเฟรมเวิร์กสำหรับโหลดตัวจัดตาราง BPF จากพื้นที่ผู้ใช้โดยไม่ต้องสร้างเคอร์เนลใหม่ สองอย่างนี้ต่างกัน sched-ext สลับตัวจัดตารางขณะรันไทม์ ไม่ใช่รายการที่สี่ในรายชื่อนั้น

CachyOS ยังคอมไพล์แพ็กเกจของ Arch ใหม่สำหรับ x86-64-v3, x86-64-v4 และ Zen4+ และวิกิของโครงการอ้างว่า x86-64-v3 เร็วขึ้น 5% ถึง 20% เมื่อเทียบกับฐาน นั่นคือตัวเลขของ CachyOS เองสำหรับงานของตัวเอง ไม่ใช่การวัดอิสระ แพ็กเกจที่สร้างใหม่อยู่ในคลังของ CachyOS ที่ซ้อนอยู่บน core, extra และ multilib ของ Arch แทนที่จะแทนที่มัน การซ้อนแทนการแทนที่ทำให้ที่มายังอ่านออก แพ็กเกจใดก็ตาม คุณยังบอกได้ว่าช่องทางไหนเป็นคนสร้าง

เชลล์เดสก์ท็อปคือชั้นที่ CachyOS ไม่บังคับ คุณเลือกสภาพแวดล้อมเอง แม้หลายตัวเลือกจะมาพร้อมการตั้งค่าหรือ dotfiles ที่ CachyOS ดูแล ตัวติดตั้งออนไลน์มีสภาพแวดล้อมให้เลือกสิบเจ็ดแบบขึ้นไป รวมถึง KDE Plasma, GNOME, Hyprland, Niri, Sway และ Xfce และการเลือกเป็นของคุณ CachyOS Hello และ Kernel Manager เป็นยูทิลิตีจัดการระบบ ไม่ใช่เชลล์

CachyOS ไม่บังคับใช้ตัวห่อการอัปเดตของตัวเอง pacman -Syu โดยตรงยังคงเป็นเส้นทางที่มีเอกสารรองรับ ควบคู่กับเครื่องมือเสริมอย่าง Shelly, Octopi และการอัปเดตแบบออฟไลน์ เมื่อติดตั้งบน Btrfs CachyOS จะจัดวางซับวอลุ่มแยกกันและใช้ Snapper สำหรับสแนปช็อตกู้คืน การตั้งค่าบูตโหลดเดอร์ที่รองรับสามารถแสดงสแนปช็อตเหล่านั้นสำหรับการกู้คืนได้

อ่าน

CachyOS เร็วกว่าจริงหรือ? ประสิทธิภาพที่เพิ่มขึ้นมาจากไหนกันแน่

Omarchy เปลี่ยนอะไร

Omarchy เปลี่ยนชั้นเชลล์เดสก์ท็อปและชั้นนโยบายการอัปเดตอย่างหนัก มาพร้อมช่องทางแพ็กเกจของตัวเอง และไม่แก้ไขเคอร์เนลหรือเป้าหมายการคอมไพล์เพื่อประสิทธิภาพ มันติดตั้งเดสก์ท็อปตายตัวหนึ่งเดียวและเข้าควบคุมคำสั่งอัปเดตแทนที่จะปล่อย pacman ให้คุณ

Omarchy ติดตั้งจาก ISO ของตัวเอง แบบเต็มดิสก์หรือลงในพื้นที่ว่างข้างระบบปฏิบัติการอื่น และเข้ารหัสดิสก์เป็นค่าเริ่มต้น ตัวติดตั้งไม่ถามเรื่องเดสก์ท็อป เพราะมีคำตอบเดียว

ชั้นเคอร์เนลและเป้าหมายการคอมไพล์แทบไม่ถูกแตะต้อง คู่มือของ Omarchy เองอธิบายว่ามันเป็นดิสทริบิวชันที่สร้างบน Arch โดยมี Hyprland และ Quickshell เป็นแกนกลาง และตลอดหน้าตัวติดตั้ง การอัปเดต dotfiles และ CLI ไม่มีเอกสารเกี่ยวกับเคอร์เนลกำหนดเอง เป้าหมายการคอมไพล์ หรือการเลือกตัวจัดตารางเลย บนฮาร์ดแวร์ทั่วไป Omarchy รันแพ็กเกจเคอร์เนล Arch ดั้งเดิม ซึ่งมาถึงจากมิเรอร์ของ Arch เหมือนส่วนที่เหลือของระบบ การแทนที่เคอร์เนลเพียงอย่างเดียวที่คู่มือระบุไว้เป็นเรื่องการรองรับฮาร์ดแวร์ บน Mac Intel ที่มีชิป T2 ตัวติดตั้งจะตั้งค่าเคอร์เนล linux-t2 ที่แพตช์แล้ว

ชั้นคลังแพ็กเกจนั้นมันเปลี่ยนจริง แต่ในแกนที่ต่างจาก CachyOS Omarchy ติดตั้งเป็นแพ็กเกจ pacman ธรรมดาจาก Package Repository ของตัวเอง และช่องทาง stable เริ่มต้นติดตามมิเรอร์ Arch ที่ตามหลังเวอร์ชันล่าสุดหนึ่งเดือน เพื่อให้ปัญหาความเข้ากันไม่ได้โผล่ที่ต้นน้ำก่อน อีกสามช่องทาง (RC, edge และ dev) แลกกันชนนั้นกับความสดใหม่

Hyprland และ Quickshell มาด้วยกันโดยไม่มีทางเลือกปฏิเสธ Hyprland คือคอมโพสิเตอร์ Wayland แบบเรียงต่อกัน ส่วน Quickshell คือชุดประกอบที่ใช้สร้างแถบ ตัวเรียกใช้ เมนู การแจ้งเตือน และหน้าจอล็อก ซึ่งเป็นเหตุผลว่าทำไม Omarchy จึงแทนที่เชลล์ทั้งหมดได้ในรุ่นเดียวแทนที่จะแค่ปล่อยธีม การแยกส่วนนี้ให้ Omarchy มีฐานที่ทำซ้ำได้ซึ่งโครงการเป็นผู้กำหนด ในขณะที่เก็บการปรับแต่งของคุณเองแยกไว้ การตั้งค่าแบ่งเป็นสองส่วน dotfiles ของคุณอยู่ใน ~/.config ส่วนค่าเริ่มต้นของโครงการอยู่ใน /usr/share/omarchy ซึ่งเป็นของแพ็กเกจและถูกเขียนทับเมื่ออัปเดต อะไรก็ตามที่คุณอยากให้รอดจากการอัปเดตต้องอยู่ฝั่งของคุณในการแบ่งส่วนนั้น

นโยบายการอัปเดตคือจุดที่จุดยืนของ Omarchy คมชัดที่สุด คำสั่ง omarchy update รันการย้ายข้อมูลที่ค้างอยู่และการอัปเดตแพ็กเกจในปฏิบัติการเดียว โดยถ่ายสแนปช็อตก่อน การย้อนกลับหมายถึงการเลือกสแนปช็อตนั้นในบูตโหลดเดอร์ ถ้าหันไปใช้ pacman -Syu แทน จะเจอด่านกั้น Omarchy จะหยุดการอัปเกรดระบบโดยตรงและชี้คุณไปที่คำสั่งของมันเอง แม้คู่มือจะบอกว่าด่านกั้นจะบอกวิธีข้ามสำหรับธุรกรรมเดียว ประเด็นคือการผูกรวม การย้ายข้อมูลเดินทางไปพร้อมกับการอัปเดตแพ็กเกจ

อ่าน

ทำไม Omarchy ถึงถูกยกย่องและถูกเกลียดด้วยเหตุผลเดียวกัน

ทำไมกระทู้เปรียบเทียบไม่เคยได้ข้อสรุป

CachyOS และ Omarchy แตะชั้นเดียวกันหลายชั้น แต่วางการเปลี่ยนแปลงที่แรงที่สุดไว้คนละที่ CachyOS มุ่งที่เคอร์เนล เป้าหมายการคอมไพล์ และบิลด์แพ็กเกจ ส่วน Omarchy มุ่งที่เชลล์เดสก์ท็อปและเวิร์กโฟลว์การอัปเดต "ตัวไหนดีกว่า" บีบคำถามที่แยกจากกันเหล่านั้นให้เหลือคำถามเดียว

ทั้งคู่ทับซ้อนกันในชั้นตัวติดตั้ง คลังแพ็กเกจ และการกู้คืน แต่ไม่ใช่ในแบบเดียวกัน คลังของ CachyOS เปลี่ยนวิธีที่แพ็กเกจของ Arch ถูกสร้าง ส่วนของ Omarchy เปลี่ยนว่ามันมาถึงเมื่อไร CachyOS ปล่อยให้ใช้ pacman อัปเดตโดยตรงได้และเพิ่มสแนปช็อตรอบๆ ส่วน Omarchy ผูกการอัปเดตแพ็กเกจ การย้ายข้อมูล และสแนปช็อตไว้หลังคำสั่งอัปเดตของตัวเอง

สองคำตอบบนสุดของกระทู้ CachyOS นั้นบีบอัดสิ่งนี้ไว้พอดี การวินิจฉัยที่ถูกต้อง ส่งมาโดยไม่มีห้าชั้นที่อยู่เบื้องหลัง

ชั้นต่างๆ ผสมกันได้

ห้าชั้นนี้นำไปใช้แยกกันได้ ไม่ได้กีดกันกันและกัน CachyOS เผยแพร่เส้นทางที่มีเอกสารสำหรับการเพิ่มคลังของตนลงในการติดตั้ง Arch และสำหรับการถอดออกอีกครั้ง Omarchy คือการติดตั้ง Arch ดังนั้นเส้นทางเดียวกันสามารถย้ายคลังที่ปรับแต่งแล้วของ CachyOS มาไว้บนมันได้

มีคนทำแบบนี้จริง ผู้แสดงความคิดเห็นในกระทู้บน r/linux_gaming พูดตรงๆ ว่า "There's nothing stopping you from installing the cachyos kernel and repositories on omarchy" มีคนเขียนสคริปต์ติดตั้งสำหรับการผสมนี้และโพสต์ไว้บน Hacker News

ความเป็นอิสระในหลักการไม่ใช่ความน่าเชื่อถือในทางปฏิบัติ ในกระทู้ r/omarchy เกี่ยวกับการย้ายไปมาระหว่างสองตัวนี้ ผู้แสดงความคิดเห็นคนหนึ่งรายงานว่า "All of the install scripts and such to do this are currently not working for many people" และการแทรกแซงด้วยมือก็ทำให้มันทำงานไม่ได้เช่นกัน นั่นคือคนหนึ่งคนในกระทู้เดียว และเป็นปัญหาแบบที่ควรวางแผนรับมือไว้

ขอบเขตที่สองคือการผสมนี้คุ้มค่าแค่ไหน การเปรียบเทียบประสิทธิภาพที่เผยแพร่แสดงให้เห็นว่า FPS เฉลี่ยในเกมแทบไม่ต่างกัน ขณะที่ประโยชน์ในวงกว้างจากเคอร์เนล ตัวจัดตาราง และเป้าหมายการคอมไพล์ของ CachyOS ยังขึ้นกับประเภทงาน ไม่ได้เกิดขึ้นเองโดยอัตโนมัติ

ส่วนที่ว่างานด้านเคอร์เนลและเป้าหมายการคอมไพล์ของ CachyOS ให้ประโยชน์ที่มีความหมายในวงกว้างกว่านั้นหรือไม่ และกับงานประเภทใดบ้าง ตั้งอยู่บนฐานหลักฐานคนละชุด ไม่ใช่ชุดที่บทความนี้ตัดสิน

พัฒนาบน Linux VPS พร้อมสิทธิ์รูท, NVMe และพลัง AMD EPYC

ดูแพ็กเกจ Linux

EndeavourOS และ Manjaro อยู่ตรงไหนบนชั้นเดียวกัน

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

EndeavourOS อธิบายตัวเองว่าเป็นระบบ Arch ที่เบาและเน้นเทอร์มินัล และสิ่งที่มันเพิ่มเข้ามาคือตัวติดตั้งแบบมีตัวช่วย ชุดแพ็กเกจที่คัดสรรมาสั้นๆ (Firefox, Yay, FirewallD, Pipewire) และเครื่องมือของตัวเองสำหรับไดรเวอร์ GPU และ VM ไม่มีเคอร์เนลกำหนดเอง ไม่มีการสร้างคลังทั่วไปของ Arch ใหม่แบบเจาะจง CPU ไม่มีเดสก์ท็อปที่บังคับ มันยังคงใกล้เคียง Arch ดั้งเดิมที่สุดในบรรดาดิสโทรลูกที่เอ่ยถึงในบทความนี้

กรอบคิดของ Manjaro คือแนวทางเสถียรภาพแบบเรียงลำดับชั้น แพ็กเกจเคลื่อนผ่านสาขา unstable, testing และ stable ในคลังของ Manjaro เอง แทนที่จะติดตามคลังของ Arch โดยตรง ซึ่งเป็นเหตุผลว่าทำไมแพ็กเกจ Manjaro อาจเก่ากว่าแพ็กเกจ Arch ชื่อเดียวกัน ตัวติดตั้งให้เลือกเดสก์ท็อปจากรุ่นทางการ Plasma, GNOME และ Xfce รวมถึงบิลด์ชุมชน Cinnamon, i3 และ Sway

มันยังมีเครื่องมือจัดการเคอร์เนลด้วย และความแตกต่างตรงนี้สำคัญ Manjaro Settings Manager เพิ่มและถอดเคอร์เนลได้ ทำให้คุณรันเคอร์เนลเวอร์ชันสำเร็จรูปตัวอื่นได้ การเลือกเวอร์ชันเคอร์เนลที่แพ็กเกจไว้แล้วไม่ใช่ปฏิบัติการเดียวกับการสร้างแพ็กเกจใหม่สำหรับชุดคำสั่ง CPU ที่ใหม่กว่า แม้ทั้งสองอย่างจะอยู่ในชั้นเคอร์เนลและเป้าหมายการคอมไพล์ก็ตาม

โมเดลสาขานั้นยังเป็นสิ่งที่แยก Manjaro ออกจากโลกของรุ่นตายตัวด้วย โมเดลแบบโรลลิงของ Manjaro เทียบกับ Ubuntu คือคำถามเรื่องคลังแพ็กเกจและนโยบายอัปเดตเดียวกันที่ถามนอกตระกูล Arch วิธีคิดแบบเดียวกันใช้ได้เลยตระกูลนั้นออกไปด้วย Ubuntu สืบทอดมาจาก Debian และต่างจากมันในเรื่องจังหวะการปล่อยรุ่น นโยบายการแพ็กเกจ และเดสก์ท็อปเริ่มต้น

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

คำถามที่พบบ่อย