snap แบบพกพาข้าม UNIX อื่น ๆ (เช่น macOS)?

ฉันชอบความคิดที่อยู่เบื้องหลัง snap และเล่นกับมันบน Ubuntu VM

ภาพรวม Snapcraft

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

แพ็คเกจ. snap สำหรับระบบ Ubuntu Core มีการขึ้นต่อกันทั้งหมด นี่เป็นข้อได้เปรียบสองสามประการเกี่ยวกับการจัดการอ้างอิงแบบเด ธ หรือ rpm แบบดั้งเดิมสิ่งสำคัญที่สุดคือผู้พัฒนาสามารถมั่นใจได้เสมอว่าไม่มีการถดถอยที่เกิดจากการเปลี่ยนแปลงของระบบภายใต้แอพของพวกเขา

Snapcraft ทำให้การรวมกลุ่มการพึ่งพาเหล่านี้เป็นเรื่องง่ายโดยให้คุณระบุว่าเป็น "ส่วน" ในไฟล์ snapcraft.yaml เร็ว

Snappy Ubuntu Core เป็นแอพพลิเคชั่นใหม่ของ Ubuntu ที่มีการอัพเดตทรานแซคชั่น - อิมเมจเซิร์ฟเวอร์ขั้นต่ำที่มีไลบราเดียวกันกับ Ubuntu ทุกวันนี้ แต่แอพพลิเคชั่นมีกลไกที่เรียบง่ายกว่า

แอพ Snappy และ Ubuntu Core นั้นสามารถอัปเกรดเป็นอะตอมและย้อนกลับได้ถ้าต้องการ แอพจะถูก จำกัด และเข้มงวดเพื่อปกป้องข้อมูลและระบบของคุณ

IoT› สร้างแอป

เทคโนโลยีใดที่ใช้ snap? สถาปัตยกรรมและชุดเครื่องมือมีลักษณะอย่างไร snap ขึ้นอยู่กับคุณลักษณะของเคอร์เนล Linux หรือไม่

ฉันถามเพราะฉันสงสัยว่าในอนาคตฉันจะสามารถใช้แพ็คเกจ snap เดียวกันกับ macOS ได้หรือไม่?

ชี้แจงหลังจากความคิดเห็นแรก:

ฉันรู้ว่า macOS และ Ubuntu ไม่รองรับไบนารี ต้องการคอมไพล์ใหม่ มีเกือบทุกที่มาเปิดอยู่แล้วสำหรับ MacOS กับHomebrew ผู้พัฒนาสามารถพัฒนาบน macOS และปรับใช้บน Ubuntu เมื่อ snap (ในอนาคต) พร้อมใช้งานสำหรับ macOS

ใช่ต้องขอบคุณความเสถียรของส่วนต่อประสาน syscall ของ Linux จึงเป็นไปได้

หนึ่งในภาระผูกพันที่ยอดเยี่ยมของ Linus Torvalds สำหรับผู้ใช้ Linux คือชุดของอินเตอร์เฟสที่เคอร์เนลเสนอนั้นมีความเสถียร หลายคนไม่เห็นคุณค่าของสิ่งนี้หรือความท้าทายในฐานะที่เป็นผู้นำของโครงการเปิดเพื่อบรรลุข้อตกลงนั้น ลองพิจารณาตัวอย่างว่าการเปลี่ยนแปลงที่ไม่สามารถคาดเดาได้ใน API ของ GNOME นั้นตรงกันข้ามกัน! เมื่อคุณได้ยินเกี่ยวกับ Linus ที่เพิ่มขึ้นอย่างรุนแรงในรายชื่อผู้รับจดหมายมักจะเป็นเพราะผู้ที่ส่งไปยังเคอร์เนลตัดสินใจเปลี่ยนอินเทอร์เฟซเช่นนั้น Linus บอกว่าคุณสามารถสร้างสรรค์สิ่งใหม่ ๆ ภายในเคอร์เนลได้ แต่โปรดอย่าทำลายแอป 'userspace' ซึ่งขึ้นอยู่กับ syscalls ที่มีอยู่

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

ตัวอย่างหนึ่งคือโครงการ Joyent Triton ซึ่งเสนอ syscalls ที่เข้ากันได้กับ Linux ในคอนเทนเนอร์บน SmartOS (สืบทอดมาจาก IllumOS ซึ่งเป็นสืบทอดของ Solaris)

ตัวอย่างที่รู้จักกันมากขึ้นกันอย่างแพร่หลายเป็นใหม่ระบบย่อยลินุกซ์ใน Windows

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

แต่พวกเขาจะมาทันเวลาและฉันคิดว่า snaps จะสามารถใช้ได้ในหลากหลายบริบท

อันไหนเจ๋งมากแพทช์ต้อนรับ :)

ในขณะที่ฉันหาข้อมูลเกี่ยวกับ macOS ไม่ได้OMG อันนี้! บทความUbuntuมีคำพูดที่น่าสนใจจาก Mark Shuttleworth:

สำหรับการใช้งาน Snaps บน Windows 10? “ มันเป็นไปได้อย่างแน่นอน” Shuttleworth กล่าว

“ Snaps ใช้คุณสมบัติที่ทันสมัยในเคอร์เนล Linux เพื่อทำการรักษาความปลอดภัยตั้งค่าการเข้าถึงระบบไฟล์และอื่น ๆ ทั้งหมดที่เกี่ยวข้องกับการใช้กลไกที่ทันสมัยในเคอร์เนล และ Canonical เป็นผู้นำ [งานนี้] มากมาย Microsoft จะใช้เวลาสักครู่ในการ [ขอติดตั้ง]

ถ้าเป็น "น่าเชื่อถือ" ที่จะให้มันทำงานบน Windows ได้ฉันจะพูดแบบเดียวกันกับ macOS ยกเว้นว่า Microsoft ดูเหมือนจะร่วมมือกับ Canonical ซึ่งไม่ใช่สิ่งที่ฉันได้ยินเกี่ยวกับ Apple

เอกสารเกี่ยวกับนโยบายความปลอดภัยของ Snap และ sandboxingและรายการ Arch Wiki บน snapdเป็นข้อมูล:

จาก Arch Wiki:

โปรดทราบว่า snap-confine ถูกสร้างขึ้นด้วยตัวเลือก --disable-confinement การคุมขังเต็มรูปแบบอาศัยเคอร์เนลที่เปิดใช้งาน AppArmor และโปรไฟล์ที่เกี่ยวข้องสำหรับ snap

จากนโยบาย:

ภายใต้ประทุนตัวเรียกใช้งาน:

• ตั้งค่าตัวแปรสภาพแวดล้อมต่าง ๆ : […]
• เมื่อฮาร์ดแวร์ถูกกำหนดให้กับ snap ให้ตั้งค่า cgroup ของอุปกรณ์ด้วยอุปกรณ์เริ่มต้น (เช่น / dev / null, / dev / urandom ฯลฯ ) และอุปกรณ์ใด ๆ ที่กำหนดให้กับ snap นี้
• เซ็ตอัพ private / tmp โดยใช้เนมสเปซการเมาท์ส่วนตัวต่อคำสั่งและการเมาท์ไดเร็กทอรีต่อคำสั่งบน / tmp
• เซ็ตอัพคำสั่ง devpts อินสแตนซ์ใหม่
• ตั้งค่าตัวกรอง seccomp สำหรับคำสั่ง
• ดำเนินการคำสั่งภายใต้โปรไฟล์ AppArmor เฉพาะคำสั่งภายใต้ค่า nice ที่เป็นค่าเริ่มต้น

การรวมกันของโปรไฟล์ AppArmor ที่ จำกัด นี้ (ซึ่งเป็นสื่อกลางในการเข้าถึงไฟล์, การใช้งานแอพพลิเคชั่น, ความสามารถของลินุกซ์ (7), mount, ptrace, IPC, สัญญาณ, เครือข่ายหยาบ), กำหนดระบบไฟล์ / tmp, อินสแตนซ์ devpts ใหม่และกลุ่มอุปกรณ์ให้การ จำกัด และการแยกแอปพลิเคชันที่แข็งแกร่ง

ในขณะที่ AppArmor และ seccomp เป็น Linux เท่านั้นดูเหมือนว่าการกักตัวสามารถทำให้เป็นตัวเลือกได้ดังนั้นเราจึงสามารถเพิกเฉยได้ จากนั้นมีการใช้งาน devpts, cgroups และ mount namespaces หากมีการปิดกั้นใด ๆ ฉันคิดว่าน่าจะเป็นสิ่งเหล่านั้น ฉันไม่คุ้นเคยกับ BSD ที่จะพูดสิ่งที่เทียบเท่า

snapdการประยุกต์ใช้ตัวเองเป็นลายลักษณ์อักษรในไปซึ่งจะทำให้มันสมเหตุสมผลข้ามแพลตฟอร์ม อันที่จริงบางไฟล์มีเป้าหมายการสร้างที่น่าสนใจมาก :

osutil/group_other.go:

// -*- Mode: Go; indent-tabs-mode: t -*-
// +build !linux,!darwin,!freebsd

osutil/group_linux.go:

// -*- Mode: Go; indent-tabs-mode: t -*-
// +build darwin freebsd linux
// +build cgo

ดูเหมือนว่าบางคนมีความสนใจในเรื่องนี้