อย่างอื่น: ชุดแอป Haiku?

TL; DR: ไฮกุสามารถรับการสนับสนุนที่เหมาะสมสำหรับแพ็คเกจแอปพลิเคชัน เช่น ไดเร็กทอรีแอปพลิเคชัน (เช่น .app บน Mac) และ/หรืออิมเมจแอปพลิเคชัน (Linux AppImage)? ฉันคิดว่านี่จะเป็นส่วนเสริมที่คุ้มค่าและง่ายต่อการนำไปใช้อย่างถูกต้องกว่าระบบอื่นๆ เนื่องจากโครงสร้างพื้นฐานส่วนใหญ่มีอยู่แล้ว

สัปดาห์ที่ผ่านมา ฉันค้นพบไฮกุ ระบบที่ดีอย่างคาดไม่ถึง เนื่องจากฉันสนใจไดเร็กทอรีและอิมเมจแอปพลิเคชันมานานแล้ว (ได้รับแรงบันดาลใจจากความเรียบง่ายของ Macintosh) จึงไม่น่าแปลกใจที่จะมีแนวคิดหนึ่งเข้ามาในใจของฉัน...

เพื่อความเข้าใจที่สมบูรณ์ ฉันเป็นผู้สร้างและผู้แต่ง AppImage ซึ่งเป็นรูปแบบการเผยแพร่แอปพลิเคชัน Linux ที่มีจุดมุ่งหมายเพื่อความเรียบง่ายของ Mac และให้การควบคุมเต็มรูปแบบแก่ผู้เขียนแอปพลิเคชันและผู้ใช้ปลายทาง (หากคุณต้องการทราบข้อมูลเพิ่มเติม โปรดดู วิกิพีเดีย и เอกสาร).

จะเป็นอย่างไรถ้าเราสร้าง AppImage สำหรับ Haiku?

ลองคิดตามทฤษฎีสักหน่อย: สิ่งที่ต้องทำเพื่อให้ได้มา AppImageหรืออะไรที่คล้ายกันในไฮกุ? ไม่จำเป็นต้องสร้างอะไรขึ้นมาตอนนี้ เพราะระบบที่มีอยู่แล้วในไฮกุทำงานได้อย่างน่าอัศจรรย์ แต่การทดลองในจินตนาการคงจะดี นอกจากนี้ยังแสดงให้เห็นถึงความซับซ้อนของไฮกุเมื่อเปรียบเทียบกับสภาพแวดล้อมเดสก์ท็อป Linux ซึ่งสิ่งเหล่านี้เป็นเรื่องยากมาก (ฉันมีสิทธิ์ที่จะพูดเช่นนั้น: ฉันดิ้นรนกับการดีบักมาเป็นเวลา 10 ปี)

บน Macintosh System 1 แต่ละแอปพลิเคชันจะเป็นไฟล์ "จัดการ" แยกต่างหากใน Finder การใช้ AppImage ฉันกำลังพยายามสร้างประสบการณ์ผู้ใช้แบบเดียวกันบน Linux

ก่อนอื่น AppImage คืออะไร นี่คือระบบสำหรับการปล่อยแอปพลิเคชันบุคคลที่สาม (เช่น เครื่อง Ultimaker Cura) ช่วยให้แอปพลิเคชันได้รับการเผยแพร่เมื่อใดและอย่างไรตามที่พวกเขาต้องการ: ไม่จำเป็นต้องทราบข้อมูลเฉพาะของการแจกจ่ายต่างๆ สร้างนโยบายหรือสร้างโครงสร้างพื้นฐาน ไม่จำเป็นต้องได้รับการสนับสนุนจากผู้ดูแล และพวกเขาไม่ได้บอกผู้ใช้ว่าสามารถติดตั้ง (ไม่) อะไรได้บ้าง บนคอมพิวเตอร์ของพวกเขา AppImage ควรเข้าใจว่าเป็นสิ่งที่คล้ายกับแพ็คเกจ Mac ในรูปแบบ .app ภายในดิสก์อิมเมจ .dmg. ข้อแตกต่างที่สำคัญคือแอปพลิเคชันจะไม่ถูกคัดลอก แต่จะยังคงอยู่ใน AppImage ตลอดไป เช่นเดียวกับแพ็คเกจ Haiku .hpkg ติดตั้งและไม่เคยติดตั้งตามปกติ

ตลอดระยะเวลากว่า 10 ปี AppImage ได้รับความสนใจและได้รับความนิยม: Linus Torvalds เองก็ให้การรับรองต่อสาธารณะ และโครงการทั่วไป (เช่น LibreOffice, Krita, Inkscape, Scribus, ImageMagick) ได้นำ AppImage มาใช้เป็นวิธีหลัก เพื่อแจกจ่ายบิลด์ต่อเนื่องหรือต่อคืน โดยไม่รบกวนแอปพลิเคชันผู้ใช้ที่ติดตั้งหรือถอนการติดตั้ง อย่างไรก็ตาม สภาพแวดล้อมเดสก์ท็อปและการแจกจ่าย Linux ส่วนใหญ่ยังคงยึดติดกับรูปแบบการแจกจ่ายแบบผู้ดูแลแบบรวมศูนย์แบบดั้งเดิม และ/หรือส่งเสริมธุรกิจองค์กรและ/หรือโปรแกรมทางวิศวกรรมของตนเองโดยอิงจาก Flatpak (RedHat, Fedora, GNOME) และ เร็ว (มาตรฐาน, อูบุนตู) มันมา ขัน.

มันทำงานอย่างไร

• 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

ตำแหน่งที่เก็บข้อมูลสำหรับข้อกำหนดข้ามเดสก์ท็อปที่ใช้ GNOME, KDE и Xfce คือ freedesktop.org

การบรรลุถึงระดับของความซับซ้อนที่ถักทออย่างลึกซึ้งในสภาพแวดล้อมการทำงานของไฮกุนั้นเป็นเรื่องยาก หรือเป็นไปไม่ได้ เนื่องจากข้อกำหนดเฉพาะ XDG จาก freedesktop.org สำหรับเดสก์ท็อปข้าม รวมถึงการใช้งานตัวจัดการเดสก์ท็อปตามข้อกำหนดเหล่านี้ ตัวอย่างเช่น เราสามารถอ้างถึงไอคอน Firefox ทั่วทั้งระบบได้: เห็นได้ชัดว่าผู้เขียน XDG ไม่คิดว่าผู้ใช้จะติดตั้งแอปพลิเคชันเดียวกันหลายเวอร์ชันได้

ไอคอนสำหรับ Firefox เวอร์ชันต่างๆ

ฉันสงสัยว่าโลก Linux สามารถเรียนรู้อะไรจาก Mac OS X เพื่อหลีกเลี่ยงการรวมระบบที่ผิดพลาด หากคุณมีเวลาและสนใจในเรื่องนี้ อย่าลืมอ่านสิ่งที่ Arnaud Gurdol หนึ่งในวิศวกร Mac OS X คนแรกๆ กล่าวว่า:

เราต้องการทำให้การติดตั้งแอปพลิเคชันเป็นเรื่องง่ายเหมือนกับการลากไอคอนแอปพลิเคชันจากที่ไหนสักแห่ง (เซิร์ฟเวอร์ ไดรฟ์ภายนอก) ไปยังไดรฟ์คอมพิวเตอร์ของคุณ ในการดำเนินการนี้ แพ็คเกจแอปพลิเคชันจะจัดเก็บข้อมูลทั้งหมด รวมถึงไอคอน เวอร์ชัน ประเภทไฟล์ที่กำลังประมวลผล ประเภทของโครงร่าง URL ที่ระบบจำเป็นต้องทราบเพื่อประมวลผลแอปพลิเคชัน นอกจากนี้ยังรวมถึงข้อมูลสำหรับ 'ที่เก็บข้อมูลส่วนกลาง' ในฐานข้อมูล Icon Services และ Launch Services เพื่อรองรับประสิทธิภาพ แอปพลิเคชันจะถูก 'ค้นพบ' ในที่ 'เป็นที่รู้จัก' หลายแห่ง: ระบบและไดเร็กทอรีแอปพลิเคชันของผู้ใช้ และอื่นๆ โดยอัตโนมัติหากผู้ใช้นำทางไปยัง Finder ในไดเร็กทอรีที่มีแอปพลิเคชัน ในทางปฏิบัติสิ่งนี้ได้ผลดีมาก

https://youtu.be/qQsnqWJ8D2c
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 ที่สร้างขึ้น ประจำวัน.
คุณมีคำถามใดๆ? เราขอเชิญคุณเข้าร่วมการพูดภาษารัสเซีย ช่องโทรเลข.

ภาพรวมข้อผิดพลาด: วิธียิงตัวเองด้วย C และ C++ รวมสูตร Haiku OS

จาก นักบิน การแปล: นี่เป็นบทความที่แปดและเป็นบทความสุดท้ายในซีรีส์เกี่ยวกับไฮกุ

รายการบทความ: เป็นครั้งแรก สอง สาม ที่สี่ ที่ห้า ที่หก ที่เจ็ด

เฉพาะผู้ใช้ที่ลงทะเบียนเท่านั้นที่สามารถเข้าร่วมในการสำรวจได้ เข้าสู่ระบบ, โปรด.

มันสมเหตุสมผลหรือไม่ที่จะย้ายระบบ hpkg ไปยัง Linux?

• มี

• ไม่

• ใช้งานแล้วฉันจะเขียนความคิดเห็น

ผู้ใช้ 20 คนโหวต ผู้ใช้ 5 รายงดออกเสียง

ที่มา: will.com