Snappy เกี่ยวข้องกับ Nix และ Guix อย่างไร

ฉันค้นหาการเปรียบเทียบ แต่พบว่าไม่ใช่และฉันไม่ค่อยทราบดีพอที่จะทำเองตอนนี้

พวกเขาทั้งหมดให้การปรับปรุงการทำธุรกรรม แต่ระดับที่แตกต่างกันของการบรรจุ

• Snappy รวบรวมแบบคงที่ในไลบรารีเพื่อจัดเตรียมการอ้างอิงไบนารีหลายเวอร์ชัน มันประกาศให้บริการ (และจำเป็น?) เป็นข้อมูลเมตา แพคเกจมีให้ในรูปเดียว?
• ระวังจะจัดการกับการเชื่อมโยงแบบไดนามิกเพื่อให้การอ้างอิงไบนารีหลายรุ่น? มันประกาศให้และบริการที่จำเป็นในฐานะข้อมูลเมตา แพคเกจมีให้ผ่านที่เก็บจัดการกับการอ้างอิง
• Guix เป็นเหมือนห้าม แต่มีการรวม GNU

การเปรียบเทียบเชิงลึกระหว่าง Nix และ Guix นั้นมอบให้โดยSander van der Burgซึ่งฉันไม่ได้ศึกษาอย่างละเอียด ฉันเดาว่ามีคนที่ Canonical ได้ทำการวิเคราะห์โซลูชันที่มีอยู่แล้ว มีระบบการปรับใช้อื่น ๆ ตามภาพเช่น CoreOS ฉันบอก

ดังนั้น Snappy Ubuntu เกี่ยวข้องกับ Nix และ Guix อย่างไร? อะไรคือความแตกต่างที่สำคัญ?

เมื่อเร็ว ๆ นี้ฉันทำการประเมินตัวเอง จริง ๆ แล้วฉันเป็นผู้สนับสนุน Nix / NixOS และอดีตนักวิจัยสนใจเทคโนโลยีการปรับใช้

ฉันพยายามที่จะยึดติดกับข้อเท็จจริงให้มากที่สุดเท่าที่จะเป็นไปได้ แต่อาจเป็นไปไม่ได้เลยที่จะคงความเป็นกลางเอาไว้ เพื่อสรุปสิ่งที่ฉันค้นพบ:

• ทั้งสองวิธีการแพคเกจร้านค้าในการแยก Snappy ปพลิเคชันร้านค้าและกรอบในโฟลเดอร์โดยใช้การประชุมชื่อต่อไปนี้: ในขณะที่ใช้ห้าม/app/name/version.vendor/nix/store/hash-name-version

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

• ในการอนุญาตให้แพคเกจที่จะหาพึ่งพาห้ามผูกพวกเขาแบบคงที่เพื่อปฏิบัติการ (เช่นโดยการปรับเปลี่ยนRPATHของไบนารี ELF) หรือโดยการตัดพวกเขาในสคริปต์ที่กำหนดตัวแปรสภาพแวดล้อมที่เหมาะสม (เช่นCLASSPATH, PYTHONPATH, PERL5LIBฯลฯ )

  Snappy ประกอบด้วยคอนเทนเนอร์ที่ไฟล์ปฏิบัติการสามารถค้นหาการขึ้นต่อกันของมันในตำแหน่งที่ตั้ง FHS ทั่วไปเช่น/libและ/bin

  อย่างไรก็ตามห้ามยังรองรับวิธีการเก็บของ Snappy แต่จะใช้เฉพาะในกรณีที่หายากมาก แพคเกจ Nix ที่โดดเด่นที่สุดที่ใช้วิธีการบรรจุเป็น Steam ใน NixOS เนื่องจาก Steam เป็นเครื่องมือปรับใช้ที่มีคุณสมบัติที่ขัดแย้งกัน

• Snappy Ubuntu Core ใช้รูปแบบการแบ่งพาร์ติชัน "A / B" เพื่ออัพเกรด (และย้อนกลับ) ระบบฐาน รองรับเฉพาะรุ่นที่ จำกัด เท่านั้น (โดยทั่วไปจะเป็นสองรุ่น) ในขณะนั้น

  ในทางตรงกันข้าม NixOS (ลินุกซ์ที่ใช้ระบบปฏิบัติการ Nix) จะรวบรวมระบบฐานออกจากแพ็คเกจ Nix ในร้าน Nix ด้วยเช่นกันและมีประสิทธิภาพมากกว่า คุณสามารถย้อนกลับไปยังการกำหนดค่าก่อนหน้านี้ที่ยังไม่ได้รวบรวมขยะ นอกจากนี้แพคเกจระบบที่คล้ายกันในรุ่นสามารถแบ่งปัน

• เครื่องมือทั้งสองรองรับการติดตั้งผู้ใช้ที่ไม่มีสิทธิพิเศษ อย่างไรก็ตาม Snappy เก็บไฟล์ทั้งหมดไว้ในโฮมไดเร็กตอรี่ของผู้ใช้ หากผู้ใช้สองคนติดตั้งแพคเกจเดียวกันพวกเขาจะติดตั้งสองครั้งในระบบ

  ในทางตรงกันข้ามแพ็คเกจ Nix ยังอนุญาตให้ผู้ใช้ทั่วไปสามารถติดตั้งแพ็กเกจในร้าน Nix ส่วนกลางเพื่อให้สามารถแชร์แพ็กเกจที่เหมือนกันระหว่างผู้ใช้ ส่วนหนึ่งเป็นเพราะการตั้งชื่อ (โดยใช้การแฮช) สิ่งนี้สามารถทำได้อย่างปลอดภัย

• Snappy จำกัดการทำงานแบบรันไทม์ของแพ็กเกจที่ไม่อยู่ในกล่องขณะที่ห้ามใช้

• Snappy ดูเหมือนจะไม่ช่วยให้ผู้ใช้สร้างแพ็คเกจจากซอร์สโค้ด อย่างไรก็ตามห้ามมี DSL ที่อนุญาตให้ผู้ใช้ทำสิ่งนี้ได้อย่างง่ายดายและติดตั้ง buildtime dependencies ทั้งหมดโดยอัตโนมัติ (คอมไพเลอร์, สร้างเครื่องมือ, ไลบรารี ฯลฯ ) เมื่อจำเป็น

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

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

โพสต์บล็อกแบบเต็มสามารถพบได้ที่นี่: http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-comparison-of-snappy.html

หวังว่าคุณจะพบว่ามันน่าสนใจในการอ่านและอาจมีบางอย่างในนั้นที่คุณคิดว่าคุ้มค่ากับการคิด