TL; DR: ไฮกุสามารถรับการสนับสนุนที่เหมาะสมสำหรับแพ็คเกจแอปพลิเคชัน เช่น ไดเร็กทอรีแอปพลิเคชัน (เช่น .app
บน Mac) และ/หรืออิมเมจแอปพลิเคชัน (Linux AppImage
)? ฉันคิดว่านี่จะเป็นส่วนเสริมที่คุ้มค่าและง่ายต่อการนำไปใช้อย่างถูกต้องกว่าระบบอื่นๆ เนื่องจากโครงสร้างพื้นฐานส่วนใหญ่มีอยู่แล้ว
เพื่อความเข้าใจที่สมบูรณ์ ฉันเป็นผู้สร้างและผู้แต่ง AppImage ซึ่งเป็นรูปแบบการเผยแพร่แอปพลิเคชัน Linux ที่มีจุดมุ่งหมายเพื่อความเรียบง่ายของ Mac และให้การควบคุมเต็มรูปแบบแก่ผู้เขียนแอปพลิเคชันและผู้ใช้ปลายทาง (หากคุณต้องการทราบข้อมูลเพิ่มเติม โปรดดู
จะเป็นอย่างไรถ้าเราสร้าง AppImage สำหรับ Haiku?
ลองคิดตามทฤษฎีสักหน่อย: สิ่งที่ต้องทำเพื่อให้ได้มา
บน Macintosh System 1 แต่ละแอปพลิเคชันจะเป็นไฟล์ "จัดการ" แยกต่างหากใน Finder การใช้ AppImage ฉันกำลังพยายามสร้างประสบการณ์ผู้ใช้แบบเดียวกันบน Linux
ก่อนอื่น AppImage คืออะไร นี่คือระบบสำหรับการปล่อยแอปพลิเคชันบุคคลที่สาม (เช่น .app
ภายในดิสก์อิมเมจ .dmg
. ข้อแตกต่างที่สำคัญคือแอปพลิเคชันจะไม่ถูกคัดลอก แต่จะยังคงอยู่ใน AppImage ตลอดไป เช่นเดียวกับแพ็คเกจ Haiku .hpkg
ติดตั้งและไม่เคยติดตั้งตามปกติ
ตลอดระยะเวลากว่า 10 ปี AppImage ได้รับความสนใจและได้รับความนิยม: Linus Torvalds เองก็ให้การรับรองต่อสาธารณะ และโครงการทั่วไป (เช่น LibreOffice, Krita, Inkscape, Scribus, ImageMagick) ได้นำ AppImage มาใช้เป็นวิธีหลัก เพื่อแจกจ่ายบิลด์ต่อเนื่องหรือต่อคืน โดยไม่รบกวนแอปพลิเคชันผู้ใช้ที่ติดตั้งหรือถอนการติดตั้ง อย่างไรก็ตาม สภาพแวดล้อมเดสก์ท็อปและการแจกจ่าย Linux ส่วนใหญ่ยังคงยึดติดกับรูปแบบการแจกจ่ายแบบผู้ดูแลแบบรวมศูนย์แบบดั้งเดิม และ/หรือส่งเสริมธุรกิจองค์กรและ/หรือโปรแกรมทางวิศวกรรมของตนเองโดยอิงจาก
มันทำงานอย่างไร
- AppImage แต่ละอันประกอบด้วย 2 ส่วน: คลิกสองครั้งเล็ก ๆ ELF (ที่เรียกว่า.
runtime.c
) ตามด้วยอิมเมจระบบไฟล์สควอชFS .
- ระบบไฟล์ SquashFS มีเพย์โหลดของแอปพลิเคชันและทุกสิ่งที่จำเป็นในการรัน ซึ่งในทางที่ถูกต้องไม่สามารถถือว่าเป็นส่วนหนึ่งของการติดตั้งเริ่มต้นสำหรับระบบเป้าหมายล่าสุดทุกระบบ (การกระจาย Linux) นอกจากนี้ยังมีข้อมูลเมตา เช่น ชื่อแอปพลิเคชัน ไอคอน ประเภท MIME ฯลฯ เป็นต้น
- เมื่อรันโดยผู้ใช้ รันไทม์จะใช้ FUSE และ squashfuse เพื่อเมานต์ระบบไฟล์ จากนั้นจัดการรันจุดเข้าใช้งานบางจุด (หรือที่เรียกว่า AppRun) ภายใน AppImage ที่ติดตั้ง
ระบบไฟล์จะถูกยกเลิกการต่อเชื่อมหลังจากกระบวนการเสร็จสิ้น
ทุกอย่างดูเรียบง่าย
และสิ่งเหล่านี้ทำให้ทุกอย่างซับซ้อน:
- ด้วยการกระจาย Linux ที่หลากหลายเช่นนี้ ไม่มีสิ่งใดที่ “อยู่ในใจที่ถูกต้อง” ที่จะเรียกว่า “ส่วนหนึ่งของการติดตั้งเริ่มต้นสำหรับระบบเป้าหมายใหม่ทุกระบบ” เราแก้ไขปัญหานี้ด้วยการสร้าง
รายการยกเว้น ช่วยให้คุณสามารถกำหนดได้ว่าสิ่งใดจะถูกบรรจุใน AppImage และสิ่งใดจะต้องนำไปที่อื่น ในขณะเดียวกันบางครั้งเราก็พลาดไปแม้ว่าโดยทั่วไปแล้วทุกอย่างจะทำงานได้ดีก็ตาม ด้วยเหตุนี้ เราขอแนะนำให้ผู้สร้างแพ็คเกจทดสอบ AppImages บนระบบเป้าหมายทั้งหมด (การกระจาย) - เพย์โหลดของแอปพลิเคชันต้องสามารถย้ายตำแหน่งข้ามระบบไฟล์ได้ น่าเสียดายที่แอปพลิเคชันจำนวนมากมีเส้นทางที่แน่นอนแบบฮาร์ดโค้ดไปยังทรัพยากรต่างๆ เช่น
/usr/share
. สิ่งนี้จำเป็นต้องได้รับการแก้ไข นอกจากนี้ คุณต้องส่งออกอย่างใดอย่างหนึ่งLD_LIBRARY_PATH
หรือแก้ไขrpath
เพื่อให้ตัวโหลดสามารถค้นหาไลบรารีที่เกี่ยวข้องได้ วิธีแรกมีข้อเสีย (ซึ่งเอาชนะได้ด้วยวิธีที่ซับซ้อน) และวิธีที่สองนั้นยุ่งยาก - ข้อผิดพลาด UX ที่ใหญ่ที่สุดสำหรับผู้ใช้ก็คือ
ตั้งค่าบิตปฏิบัติการ ไฟล์ AppImage หลังจากดาวน์โหลด เชื่อหรือไม่ว่านี่เป็นอุปสรรคที่แท้จริงสำหรับบางคน ความจำเป็นในการตั้งค่าบิตความสามารถในการดำเนินการนั้นยุ่งยากแม้แต่กับผู้ใช้ที่มีประสบการณ์ วิธีแก้ปัญหาเบื้องต้น เราแนะนำให้ติดตั้งบริการขนาดเล็กที่ตรวจสอบไฟล์ AppImage และตั้งค่าบิตความสามารถในการดำเนินการ ในรูปแบบที่บริสุทธิ์ มันไม่ใช่ทางออกที่ดีที่สุด เนื่องจากมันไม่ได้ผลนอกกรอบ การกระจาย Linux ไม่ได้ให้บริการนี้ ดังนั้นผู้ใช้จึงได้รับประสบการณ์ที่ไม่ดีทันที - ผู้ใช้ Linux คาดหวังว่าแอปพลิเคชันใหม่จะมีไอคอนในเมนูเริ่มต้น คุณไม่สามารถบอกระบบได้: “ดูสิ มีแอปพลิเคชันใหม่ มาทำงานกันเถอะ” ตามข้อกำหนด XDG คุณต้องคัดลอกไฟล์แทน
.desktop
ไปยังสถานที่ที่ถูกต้องใน/usr
สำหรับการติดตั้งทั้งระบบหรือใน$HOME
สำหรับบุคคล ต้องวางไอคอนบางขนาดตามข้อกำหนด XDG ไว้ในสถานที่บางแห่งusr
หรือ$HOME
จากนั้นเรียกใช้คำสั่งในสภาพแวดล้อมการทำงานเพื่ออัปเดตแคชไอคอน หรือหวังว่าผู้จัดการสภาพแวดล้อมการทำงานจะเข้าใจและตรวจจับทุกอย่างโดยอัตโนมัติ เช่นเดียวกับประเภท MIME เพื่อเป็นการหลีกเลี่ยงปัญหา ขอเสนอให้ใช้บริการเดียวกัน ซึ่งนอกเหนือจากการตั้งค่าสถานะความสามารถในการปฏิบัติการแล้ว ถ้ามีไอคอน ฯลฯ จะดำเนินการด้วย ใน AppImage ให้คัดลอกจาก AppImage ไปยังตำแหน่งที่ถูกต้องตาม XDG เมื่อลบหรือย้าย คาดว่าบริการจะล้างทุกอย่าง แน่นอนว่าพฤติกรรมของแต่ละสภาพแวดล้อมในการทำงานมีความแตกต่างกันในรูปแบบไฟล์กราฟิก ขนาด ตำแหน่งที่จัดเก็บ และวิธีการอัปเดตแคช ซึ่งก่อให้เกิดปัญหา สรุปวิธีนี้คือไม้ค้ำยัน - หากสิ่งที่กล่าวมาข้างต้นยังไม่เพียงพอ ก็ยังไม่มีไอคอน AppImage ในตัวจัดการไฟล์ โลกของ Linux ยังไม่ได้ตัดสินใจที่จะใช้งาน elficon (แม้จะ
อภิปรายผล иการนำไปใช้ ) ดังนั้นจึงเป็นไปไม่ได้ที่จะฝังไอคอนลงในแอปพลิเคชันโดยตรง ปรากฎว่าแอปพลิเคชันในตัวจัดการไฟล์ไม่มีไอคอนของตัวเอง (ไม่แตกต่างกัน AppImage หรืออย่างอื่น) แต่จะอยู่ในเมนูเริ่มเท่านั้น วิธีแก้ปัญหาชั่วคราว เรากำลังใช้ภาพขนาดย่อ ซึ่งเป็นกลไกที่เดิมออกแบบมาเพื่อให้ผู้จัดการเดสก์ท็อปสามารถแสดงภาพตัวอย่างภาพขนาดย่อของไฟล์กราฟิกเป็นไอคอนได้ ดังนั้น บริการสำหรับการตั้งค่าบิตปฏิบัติการยังทำงานเป็น "ตัวย่อ" อีกด้วย โดยสร้างและเขียนภาพขนาดย่อของไอคอนไปยังตำแหน่งที่เหมาะสม/usr
и$HOME
. บริการนี้ยังทำการล้างข้อมูลหาก AppImage ถูกลบหรือย้าย เนื่องจากผู้จัดการเดสก์ท็อปแต่ละตัวมีพฤติกรรมที่แตกต่างกันเล็กน้อย เช่น รูปแบบใดที่ยอมรับไอคอน ในขนาดหรือตำแหน่งใด ทั้งหมดนี้เป็นเรื่องที่เจ็บปวดมาก - แอปพลิเคชันหยุดทำงานทันทีหากเกิดข้อผิดพลาด (เช่น มีไลบรารีที่ไม่ได้เป็นส่วนหนึ่งของระบบพื้นฐานและไม่ได้ระบุไว้ใน AppImage) และไม่มีใครบอกผู้ใช้ใน GUI ว่าเกิดอะไรขึ้นกันแน่ เราเริ่มแก้ไขปัญหานี้โดยใช้
การแจ้งเตือน บนเดสก์ท็อป ซึ่งหมายความว่าเราจำเป็นต้องตรวจจับข้อผิดพลาดจากบรรทัดคำสั่ง แปลงเป็นข้อความที่ผู้ใช้เข้าใจ ซึ่งจากนั้นจะต้องแสดงบนเดสก์ท็อป และแน่นอนว่าสภาพแวดล้อมเดสก์ท็อปแต่ละแบบจะจัดการแตกต่างกันเล็กน้อย - ขณะนี้ (กันยายน 2019 - หมายเหตุผู้แปล) ฉันไม่พบวิธีง่ายๆ ที่จะบอกระบบว่าไฟล์นั้น
1.png
จะต้องเปิดโดยใช้ Krita และ2.png
- ใช้ GIMP
ตำแหน่งที่เก็บข้อมูลสำหรับข้อกำหนดข้ามเดสก์ท็อปที่ใช้
การบรรลุถึงระดับของความซับซ้อนที่ถักทออย่างลึกซึ้งในสภาพแวดล้อมการทำงานของไฮกุนั้นเป็นเรื่องยาก หรือเป็นไปไม่ได้ เนื่องจากข้อกำหนดเฉพาะ
ไอคอนสำหรับ Firefox เวอร์ชันต่างๆ
ฉันสงสัยว่าโลก Linux สามารถเรียนรู้อะไรจาก Mac OS X เพื่อหลีกเลี่ยงการรวมระบบที่ผิดพลาด หากคุณมีเวลาและสนใจในเรื่องนี้ อย่าลืมอ่านสิ่งที่ Arnaud Gurdol หนึ่งในวิศวกร Mac OS X คนแรกๆ กล่าวว่า:
เราต้องการทำให้การติดตั้งแอปพลิเคชันเป็นเรื่องง่ายเหมือนกับการลากไอคอนแอปพลิเคชันจากที่ไหนสักแห่ง (เซิร์ฟเวอร์ ไดรฟ์ภายนอก) ไปยังไดรฟ์คอมพิวเตอร์ของคุณ ในการดำเนินการนี้ แพ็คเกจแอปพลิเคชันจะจัดเก็บข้อมูลทั้งหมด รวมถึงไอคอน เวอร์ชัน ประเภทไฟล์ที่กำลังประมวลผล ประเภทของโครงร่าง URL ที่ระบบจำเป็นต้องทราบเพื่อประมวลผลแอปพลิเคชัน นอกจากนี้ยังรวมถึงข้อมูลสำหรับ 'ที่เก็บข้อมูลส่วนกลาง' ในฐานข้อมูล Icon Services และ Launch Services เพื่อรองรับประสิทธิภาพ แอปพลิเคชันจะถูก 'ค้นพบ' ในที่ 'เป็นที่รู้จัก' หลายแห่ง: ระบบและไดเร็กทอรีแอปพลิเคชันของผู้ใช้ และอื่นๆ โดยอัตโนมัติหากผู้ใช้นำทางไปยัง Finder ในไดเร็กทอรีที่มีแอปพลิเคชัน ในทางปฏิบัติสิ่งนี้ได้ผลดีมาก
Apple WWDC 2000 เซสชัน 144 - Mac OS X: แอปพลิเคชันบรรจุภัณฑ์และการพิมพ์เอกสาร
ไม่มีอะไรที่เหมือนกับโครงสร้างพื้นฐานนี้บนเดสก์ท็อป Linux ดังนั้นเราจึงกำลังมองหาวิธีแก้ปัญหาเกี่ยวกับข้อจำกัดทางโครงสร้างในโปรเจ็กต์ AppImage
ไฮกุจะมาช่วยเหรอ?
และอีกอย่างหนึ่ง: แพลตฟอร์ม Linux ซึ่งเป็นพื้นฐานของสภาพแวดล้อมเดสก์ท็อปมีแนวโน้มที่จะได้รับการระบุต่ำเกินไป จนหลายสิ่งหลายอย่างที่ค่อนข้างเรียบง่ายในระบบฟูลสแตกที่สอดคล้องกันนั้นมีการแยกส่วนและซับซ้อนอย่างน่าหงุดหงิดใน Linux ฉันทุ่มเทรายงานทั้งหมดเกี่ยวกับปัญหาที่เกี่ยวข้องกับแพลตฟอร์ม Linux สำหรับสภาพแวดล้อมเดสก์ท็อป (นักพัฒนาที่มีความรู้ยืนยันว่าทุกอย่างจะยังคงเป็นแบบนี้ไปอีกนาน)
รายงานของฉันเกี่ยวกับปัญหาสภาพแวดล้อมเดสก์ท็อป Linux ในปี 2018
แม้แต่ Linus Torvalds ก็ยอมรับว่าการแยกส่วนเป็นสาเหตุที่ทำให้แนวคิดด้านพื้นที่ทำงานล้มเหลว
ยินดีที่ได้เห็นไฮกุ!
ไฮกุทำให้ทุกสิ่งเรียบง่ายอย่างน่าอัศจรรย์
แม้ว่าแนวทางที่ไร้เดียงสาในการ "ย้าย" AppImage ไปยัง Haiku คือการพยายามสร้าง (ส่วนใหญ่เป็น runtime.c และบริการ) ส่วนประกอบต่างๆ (ซึ่งอาจเป็นไปได้ด้วยซ้ำ!) แต่สิ่งนี้จะไม่ให้ประโยชน์แก่ Haiku มากนัก เพราะในความเป็นจริงแล้ว ปัญหาเหล่านี้ส่วนใหญ่แก้ไขได้ในไฮกุและมีแนวคิดที่ดี ไฮกุมีโครงสร้างพื้นฐานของระบบที่ฉันมองหาในสภาพแวดล้อมเดสก์ท็อป Linux มาเป็นเวลานานและไม่อยากจะเชื่อเลยว่าไม่มีอยู่ที่นั่น กล่าวคือ:
เชื่อหรือไม่ว่านี่คือสิ่งที่ผู้ใช้ Linux หลายคนไม่สามารถเอาชนะได้ ใน Haiku ทุกอย่างจะทำโดยอัตโนมัติ!
- ไฟล์ ELF ที่ไม่มีบิตปฏิบัติการจะได้รับหนึ่งไฟล์โดยอัตโนมัติเมื่อดับเบิลคลิกในตัวจัดการไฟล์
- แอปพลิเคชันอาจมีทรัพยากรในตัว เช่น ไอคอน ที่แสดงในตัวจัดการไฟล์ ไม่จำเป็นต้องคัดลอกรูปภาพจำนวนมากไปยังไดเร็กทอรีพิเศษที่มีไอคอน ดังนั้นจึงไม่จำเป็นต้องล้างข้อมูลเหล่านั้นหลังจากลบหรือย้ายแอปพลิเคชัน
- มีฐานข้อมูลสำหรับเชื่อมโยงแอปพลิเคชันกับเอกสารโดยไม่จำเป็นต้องคัดลอกไฟล์ใด ๆ
- ในไดเร็กทอรี lib/ ถัดจากไฟล์เรียกทำงาน ไลบรารีจะถูกค้นหาตามค่าเริ่มต้น
- ไม่มีการกระจายและสภาพแวดล้อมเดสก์ท็อปมากมาย อะไรก็ตามที่ใช้ได้ผล จะทำงานได้ทุกที่
- ไม่มีโมดูลแยกต่างหากให้รันซึ่งแตกต่างจากไดเร็กทอรี Applications
- แอปพลิเคชันไม่มีเส้นทางที่แน่นอนในตัวไปยังทรัพยากร แต่มีฟังก์ชันพิเศษสำหรับระบุตำแหน่งขณะรันไทม์
- มีการแนะนำแนวคิดเกี่ยวกับอิมเมจระบบไฟล์บีบอัด: นี่คือแพ็คเกจ hpkg ใด ๆ ทั้งหมดถูกเมาท์โดยเคอร์เนล
- แต่ละไฟล์ถูกเปิดโดยแอปพลิเคชันที่สร้างขึ้น เว้นแต่คุณจะระบุเป็นอย่างอื่นอย่างชัดเจน เจ๋งขนาดนี้!
PNG สองไฟล์ สังเกตไอคอนต่างๆ ที่ระบุว่าแอปพลิเคชันต่างๆ จะเปิดขึ้นมาเมื่อดับเบิลคลิก นอกจากนี้ โปรดสังเกตเมนูแบบเลื่อนลง "เปิดด้วย:" ซึ่งผู้ใช้สามารถเลือกแอปพลิเคชันแต่ละรายการได้ ง่ายแค่ไหน!
ดูเหมือนว่าไม้ค้ำยันและวิธีแก้ปัญหาหลายอย่างที่ AppImage บน Linux จำเป็นต้องใช้นั้นกลายเป็นสิ่งจำเป็นใน Haiku ซึ่งมีพื้นฐานที่เรียบง่ายและซับซ้อนซึ่งทำให้สามารถรองรับความต้องการส่วนใหญ่ของเราได้
ไฮกุจำเป็นต้องมีแพ็คเกจแอพหรือไม่?
สิ่งนี้นำไปสู่คำถามใหญ่ หากการสร้างระบบอย่าง AppImage บน Haiku ทำได้ง่ายกว่าบน Linux มาก มันจะคุ้มค่าที่จะทำหรือไม่ หรือไฮกุที่มีระบบแพ็คเกจ hpkg สามารถขจัดความจำเป็นในการพัฒนาแนวคิดดังกล่าวได้อย่างมีประสิทธิภาพ? เพื่อตอบเราต้องดูแรงจูงใจเบื้องหลังการมีอยู่ของ AppImages
มุมมองของผู้ใช้
ลองดูที่ผู้ใช้ปลายทางของเรา:
- ฉันต้องการติดตั้งแอปพลิเคชันโดยไม่ต้องขอรหัสผ่านผู้ดูแลระบบ (รูท) ไม่มีแนวคิดของผู้ดูแลระบบใน Haiku ผู้ใช้สามารถควบคุมได้อย่างเต็มที่เนื่องจากเป็นระบบส่วนบุคคล! (โดยหลักการแล้ว คุณสามารถจินตนาการได้ในโหมดผู้เล่นหลายคน ฉันหวังว่านักพัฒนาจะทำให้มันเรียบง่าย)
- ฉันต้องการรับแอปพลิเคชันเวอร์ชันล่าสุดและยิ่งใหญ่ที่สุด โดยไม่ต้องรอให้แอปพลิเคชันเหล่านั้นปรากฏในการเผยแพร่ของฉัน (โดยส่วนใหญ่แล้วจะหมายความว่า "ไม่" อย่างน้อยเว้นแต่ฉันจะอัปเดตระบบปฏิบัติการทั้งหมด) ในไฮกุสิ่งนี้จะ "แก้ไข" ด้วยการเผยแพร่แบบลอยตัว ซึ่งหมายความว่าเป็นไปได้ที่จะรับแอปพลิเคชันเวอร์ชันล่าสุดและยิ่งใหญ่ที่สุด แต่ในการดำเนินการนี้ คุณจะต้องอัปเดตระบบที่เหลืออย่างต่อเนื่อง เพื่อเปลี่ยนให้กลายเป็น "เป้าหมายที่กำลังเคลื่อนที่" อย่างมีประสิทธิภาพ.
- ฉันต้องการแอปพลิเคชันเดียวกันหลายเวอร์ชันเคียงข้างกัน เนื่องจากไม่มีทางรู้ได้ว่าเวอร์ชันล่าสุดมีข้อบกพร่องอะไรบ้าง หรือในฐานะนักพัฒนาเว็บ จำเป็นต้องทดสอบงานของฉันโดยใช้เบราว์เซอร์เวอร์ชันต่างๆ ไฮกุแก้ปัญหาแรก แต่ไม่ใช่ปัญหาที่สอง การอัปเดตจะถูกย้อนกลับ แต่สำหรับทั้งระบบเท่านั้น เป็นไปไม่ได้ (เท่าที่ฉันรู้) ที่จะรันเช่น WebPositive หรือ LibreOffice หลายเวอร์ชันพร้อมกัน
หนึ่งในนักพัฒนาเขียนว่า:
เหตุผลโดยพื้นฐานคือ: กรณีการใช้งานเกิดขึ้นน้อยมากจนการปรับให้เหมาะสมนั้นไม่สมเหตุสมผล ถือว่าเป็นกรณีพิเศษใน HaikuPorts ดูเหมือนจะมากกว่าที่ยอมรับได้
- ฉันต้องเก็บแอปไว้ในที่ที่ฉันชอบ ไม่ใช่ในไดรฟ์เริ่มต้นระบบ ฉันมักจะมีพื้นที่ดิสก์ไม่เพียงพอ ดังนั้นฉันจึงต้องเชื่อมต่อไดรฟ์ภายนอกหรือไดเร็กทอรีเครือข่ายเพื่อจัดเก็บแอปพลิเคชัน (ทุกเวอร์ชันที่ฉันดาวน์โหลด) หากฉันเชื่อมต่อไดรฟ์ดังกล่าว ฉันต้องการให้แอปพลิเคชันเปิดขึ้นด้วยการดับเบิลคลิก ไฮกุบันทึกแพ็คเกจเวอร์ชันเก่าไว้ แต่ฉันไม่รู้ว่าจะย้ายมันไปยังไดรฟ์ภายนอกได้อย่างไร หรือจะเปิดแอปพลิเคชันจากที่นั่นในภายหลังได้อย่างไร
ความคิดเห็นของผู้พัฒนา:
ในทางเทคนิคแล้ว สิ่งนี้สามารถทำได้ด้วยคำสั่ง mount แน่นอนว่าเราจะสร้าง GUI สำหรับสิ่งนี้ทันทีที่เรามีผู้ใช้ที่สนใจมากพอ
- ฉันไม่ต้องการไฟล์นับล้านที่กระจัดกระจายอยู่ในระบบไฟล์ที่ฉันไม่สามารถจัดการด้วยตนเองได้ ฉันต้องการหนึ่งไฟล์ต่อแอปพลิเคชันที่ฉันสามารถดาวน์โหลด ย้าย ลบได้อย่างง่ายดาย ในไฮกุปัญหานี้แก้ไขได้โดยใช้แพ็คเกจ
.hpkg
ซึ่งถ่ายโอน เช่น python จากไฟล์หลายพันไฟล์เป็นไฟล์เดียว แต่หากมี เช่น Scribus ที่ใช้ python ฉันก็ต้องจัดการกับไฟล์อย่างน้อยสองไฟล์ และฉันต้องดูแลรักษาเวอร์ชันที่ทำงานร่วมกันได้
AppImages หลายเวอร์ชันทำงานเคียงข้างกันบน Linux เดียวกัน
มุมมองของผู้พัฒนาแอพพลิเคชั่น
ลองดูจากมุมมองของนักพัฒนาแอปพลิเคชัน:
- ฉันต้องการควบคุมประสบการณ์การใช้งานทั้งหมด ฉันไม่ต้องการพึ่งพาระบบปฏิบัติการเพื่อบอกฉันว่าฉันควรเผยแพร่แอปพลิเคชันเมื่อใดและอย่างไร ไฮกุอนุญาตให้นักพัฒนาทำงานกับที่เก็บ hpkg ของตนเองได้ แต่นั่นหมายความว่าผู้ใช้จะต้องตั้งค่าด้วยตนเอง ซึ่งทำให้แนวคิดนี้ "น่าสนใจน้อยลง"
- ฉันมีหน้าดาวน์โหลดบนเว็บไซต์ของฉันที่ฉันเผยแพร่
.exe
สำหรับวินโดวส์.dmg
สำหรับ Mac และ.AppImage
สำหรับลินุกซ์ หรือบางทีฉันต้องการสร้างรายได้จากการเข้าถึงหน้านี้ อะไรเป็นไปได้? ฉันควรใส่อะไรไว้สำหรับไฮกุ? ไฟล์ก็พอแล้ว.hpkg
ด้วยการพึ่งพาจาก HaikuPorts เท่านั้น - ซอฟต์แวร์ของฉันต้องการซอฟต์แวร์อื่นเวอร์ชันเฉพาะ ตัวอย่างเช่น เป็นที่ทราบกันว่า Krita ต้องการ Qt เวอร์ชันที่มีแพตช์ หรือ Qt ที่ได้รับการปรับแต่งอย่างละเอียดให้เป็นเวอร์ชันเฉพาะของ Krita อย่างน้อยก็จนกว่าแพตช์จะถูกผลักกลับเข้าไปใน Qt คุณสามารถจัดแพ็คเกจ Qt ของคุณเองสำหรับการสมัครเป็นแพ็คเกจได้
.hpkg
แต่มีแนวโน้มว่าสิ่งนี้จะไม่เป็นที่ต้อนรับ
หน้าดาวน์โหลดแอปพลิเคชันปกติ ฉันควรโพสต์อะไรที่นี่เพื่อไฮกุ
จะรวมกลุ่ม (มีอยู่ในไดเร็กทอรีแอปพลิเคชันเช่น AppDir หรือ .app
ในรูปแบบ Apple) และ/หรือรูปภาพ (ในรูปแบบ AppImages หรือ .dmg
จาก Apple) แอปพลิเคชันมีประโยชน์เพิ่มเติมต่อสภาพแวดล้อมเดสก์ท็อปไฮกุหรือไม่ หรือจะทำให้ภาพรวมเจือจางลงจนเกิดความแตกแยกจึงเพิ่มความซับซ้อน? ฉันขาดใจ: ในด้านหนึ่งความสวยงามและความซับซ้อนของไฮกุนั้นขึ้นอยู่กับความจริงที่ว่าโดยปกติแล้วมีวิธีการทำบางสิ่งเพียงวิธีเดียวมากกว่าหลายวิธี ในทางกลับกัน โครงสร้างพื้นฐานส่วนใหญ่สำหรับแค็ตตาล็อกและ/หรือชุดแอปพลิเคชันมีอยู่แล้ว ดังนั้นระบบจึงร้องขอให้ส่วนที่เหลืออีกสองสามเปอร์เซ็นต์เข้าที่
ตามที่นักพัฒนา
บน Linux พวกเขา (แค็ตตาล็อกและชุดแอปพลิเคชัน - ประมาณ นักแปล) น่าจะเป็นวิธีแก้ปัญหาทางเทคนิคสำหรับปัญหาเชิงระบบ ที่ Haiku เราต้องการเพียงแค่แก้ไขปัญหาของระบบ
คุณคิดอย่างไร?
ก่อนจะตอบ...
เดี๋ยว มาตรวจสอบความเป็นจริงกันสักหน่อย: ในความเป็นจริง ไดเรกทอรีแอปพลิเคชัน - เป็นส่วนหนึ่งของไฮกุแล้ว:
ไดเร็กทอรีแอปพลิเคชันมีอยู่แล้วใน Haiku แต่ยังไม่รองรับในตัวจัดการไฟล์
พวกเขาไม่ได้รับการสนับสนุนเช่นเดียวกับ Macintosh Finder จะดีแค่ไหนหากไดเร็กทอรี QtCreator มีชื่อและไอคอน "QtCreator" ที่มุมซ้ายบน ซึ่งจะเปิดแอปพลิเคชันเมื่อดับเบิลคลิก
ก่อนหน้านี้เล็กน้อยแล้ว
คุณแน่ใจหรือไม่ว่าคุณสามารถใช้งานแอปที่มีอายุนับสิบปีของคุณได้ในวันนี้ ในเมื่อ App Store และแหล่งกระจายข้อมูลทั้งหมดลืมเกี่ยวกับแอปเหล่านี้และการพึ่งพาแอปเหล่านั้นไปแล้ว คุณมั่นใจหรือไม่ว่าคุณจะยังคงสามารถเข้าถึงงานปัจจุบันของคุณได้ในอนาคต?
มีคำตอบจากไฮกุอยู่แล้วหรือแคตตาล็อกและชุดแอปพลิเคชันสามารถช่วยได้ที่นี่ ฉันคิดว่าพวกเขาสามารถ
ตามที่นาย. เดินเตาะแตะ:
ใช่ เรามีคำตอบสำหรับคำถาม: เราจะสนับสนุนแอปพลิเคชันเหล่านี้ให้นานเท่าที่จำเป็นจนกว่าผู้อื่นจะสามารถอ่านรูปแบบไฟล์ของตนได้อย่างถูกต้องหรือจัดให้มีฟังก์ชันการทำงานแบบตัวต่อตัว ความมุ่งมั่นของเราในการสนับสนุนแอป BeOS R5 บน Haiku ถือเป็นข้อพิสูจน์เรื่องนี้...
นี้แน่นอน!
ไฮกุควรดำเนินการอย่างไร?
ฉันนึกภาพการอยู่ร่วมกันอย่างสันติของ hpkg ไดเร็กทอรีและรูปภาพแอปพลิเคชัน:
- การใช้ซอฟต์แวร์ระบบ
.hpkg
- สำหรับซอฟต์แวร์ที่ใช้บ่อยที่สุด (โดยเฉพาะซอฟต์แวร์ที่ต้องกำหนดเวลาการเปิดตัว) ให้ใช้
.hpkg
(ประมาณ 80% ของทุกกรณี) - บางส่วนติดตั้งผ่าน
.hpkg
แอปพลิเคชันจะได้รับประโยชน์จากการย้ายไปยังโครงสร้างพื้นฐานไดเร็กทอรีแอปพลิเคชัน (เช่น QtCreator) ซึ่งจะถูกแจกจ่ายเป็น.hpkg
, เหมือนก่อน.
นาย. waddlesplash พิมพ์ว่า:
หากคุณต้องการเพียงแค่ดูแอปพลิเคชัน
/system/apps
แต่เราควรทำให้ไดเร็กทอรีใน Deskbar จัดการได้ง่ายขึ้นสำหรับผู้ใช้แทน/system/apps
ไม่ได้ตั้งใจให้ผู้ใช้เปิดและดูเป็นประจำ (ต่างจาก MacOS) สำหรับสถานการณ์เช่นนี้ ไฮกุมีกระบวนทัศน์ที่แตกต่างออกไป แต่ในทางทฤษฎีแล้ว ตัวเลือกนี้เป็นที่ยอมรับได้
- Haiku ได้รับโครงสร้างพื้นฐานสำหรับการรันอิมเมจแอปพลิเคชันในเวลากลางคืน ต่อเนื่อง และทดสอบบิลด์ซอฟต์แวร์ รวมถึงกรณีที่ผู้ใช้ต้องการ "หยุดการทำงานทันเวลา" สำหรับซอฟต์แวร์ส่วนตัวและภายใน และกรณีการใช้งานพิเศษอื่นๆ (ประมาณ 20% ของทั้งหมด). รูปภาพเหล่านี้มีไฟล์ที่จำเป็นในการเรียกใช้แอปพลิเคชัน
.hpkg
ติดตั้งโดยระบบ และหลังจากแอปพลิเคชันเสร็จสิ้น - ยกเลิกการต่อเชื่อม (บางทีตัวจัดการไฟล์สามารถใส่ไฟล์ได้.hpkg
ลงในอิมเมจแอปพลิเคชัน โดยอัตโนมัติหรือตามคำขอของผู้ใช้ เช่น เมื่อคุณลากแอปพลิเคชันไปยังไดเร็กทอรีเครือข่ายหรือไดรฟ์ภายนอก มันก็แค่เพลง! หรือมากกว่านั้นคือบทกวี - ไฮกุ) ในทางกลับกัน ผู้ใช้อาจต้องการติดตั้งเนื้อหาของรูปภาพในรูปแบบไฟล์.hpkg
หลังจากนั้นก็จะได้รับการอัปเดตและประมวลผลในลักษณะเดียวกับที่ติดตั้งผ่าน HaikuDepot... เราต้องระดมความคิด)
คำคมจากนาย. เดินเตาะแตะ:
การเรียกใช้แอปพลิเคชันจากไดรฟ์ภายนอกหรือไดเรกทอรีเครือข่ายอาจมีประโยชน์ และการเพิ่มความสามารถในการกำหนดค่า "โซน" เพิ่มเติมสำหรับ pkgman จะเป็นคุณสมบัติที่ดีอย่างแน่นอน
ระบบดังกล่าวจะใช้ประโยชน์จาก hpkg ไดเร็กทอรี และอิมเมจแอปพลิเคชัน พวกเขาเก่งเป็นรายบุคคล แต่เมื่อรวมกันแล้วพวกเขาจะอยู่ยงคงกระพัน
ข้อสรุป
Haiku มีเฟรมเวิร์กที่มอบประสบการณ์ผู้ใช้ที่เรียบง่ายและซับซ้อนสำหรับพีซี และไปไกลกว่าที่ปกติจะมีให้สำหรับ Linux PC ระบบแพ็คเกจ .hpkg
ก็เป็นตัวอย่างหนึ่ง แต่ส่วนที่เหลือของระบบก็เต็มไปด้วยความซับซ้อนเช่นกัน อย่างไรก็ตาม ไฮกุจะได้รับประโยชน์จากไดเร็กทอรีที่เหมาะสมและการสนับสนุนอิมเมจแอปพลิเคชัน วิธีที่ดีที่สุดคือควรปรึกษากับผู้ที่รู้จักไฮกุ ทั้งปรัชญาและสถาปัตยกรรมของมันดีกว่าฉันมาก ท้ายที่สุดแล้ว ฉันใช้ไฮกุมาได้ประมาณหนึ่งสัปดาห์แล้ว อย่างไรก็ตาม ฉันเชื่อว่านักออกแบบ นักพัฒนา และสถาปนิกของ Haiku จะได้รับประโยชน์จากมุมมองที่สดใหม่นี้ อย่างน้อยที่สุด ฉันคงจะมีความสุขที่ได้เป็น “คู่ซ้อม” ของพวกเขา ฉันมีประสบการณ์ตรงมากกว่า 10 ปีกับแคตตาล็อกและบันเดิลแอปพลิเคชัน Linux และฉันต้องการค้นหาการใช้งานเหล่านี้ใน Haiku ซึ่งฉันคิดว่าสิ่งเหล่านี้เหมาะสมอย่างยิ่ง วิธีแก้ปัญหาที่เป็นไปได้ที่ฉันเสนอนั้นไม่ได้เป็นเพียงวิธีแก้ปัญหาที่ฉันอธิบายไว้เท่านั้น และหากทีมงานไฮกุตัดสินใจที่จะหาวิธีอื่นที่ดีกว่า ฉันก็พร้อมทำ โดยพื้นฐานแล้วฉันกำลังคิดถึงแนวคิดในการสร้างระบบอยู่แล้ว hpkg
น่าทึ่งยิ่งขึ้นโดยไม่ต้องเปลี่ยนวิธีการทำงาน ปรากฎว่าทีมงาน Haiku คิดเกี่ยวกับ Application Bundles มาเป็นเวลานานในการใช้ระบบการจัดการแพ็คเกจ แต่น่าเสียดาย (ฉันคิดว่า) แนวคิดนี้กลายเป็น "ล้าสมัย" แล้ว บางทีอาจถึงเวลาที่จะฟื้นฟูมันแล้ว?
ลองด้วยตัวเอง! ท้ายที่สุดแล้ว โปรเจ็กต์ Haiku ได้จัดเตรียมอิมเมจสำหรับการบูทจาก DVD หรือ USB ที่สร้างขึ้น
คุณมีคำถามใดๆ? เราขอเชิญคุณเข้าร่วมการพูดภาษารัสเซีย
ภาพรวมข้อผิดพลาด:
จาก
รายการบทความ:
เฉพาะผู้ใช้ที่ลงทะเบียนเท่านั้นที่สามารถเข้าร่วมในการสำรวจได้
มันสมเหตุสมผลหรือไม่ที่จะย้ายระบบ hpkg ไปยัง Linux?
-
มี
-
ไม่
-
ใช้งานแล้วฉันจะเขียนความคิดเห็น
ผู้ใช้ 20 คนโหวต ผู้ใช้ 5 รายงดออกเสียง
ที่มา: will.com