TL; DR: Haiku เป็นระบบปฏิบัติการที่ออกแบบมาสำหรับพีซีโดยเฉพาะ ดังนั้นจึงมีเคล็ดลับหลายประการที่ทำให้สภาพแวดล้อมเดสก์ท็อปดีกว่าระบบอื่นๆ มาก แต่มันทำงานอย่างไร?
ฉันค้นพบไฮกุ ระบบที่ดีอย่างคาดไม่ถึง ฉันยังคงประหลาดใจกับความราบรื่นของมัน โดยเฉพาะเมื่อเปรียบเทียบกับสภาพแวดล้อมเดสก์ท็อป Linux วันนี้ผมจะมาดูใต้ฝากระโปรงครับ ในกรณีที่จำเป็นสำหรับการทำความเข้าใจเชิงลึก ฉันจะทำการเปรียบเทียบกับสภาพแวดล้อมเดสก์ท็อป Macintosh, Mac OS X และ Linux ดั้งเดิม (มาตรฐาน XDG จาก freedesktop.org)
ทรัพยากรในไฟล์ ELF
เมื่อวานฉันได้เรียนรู้ว่า IconOMatic สามารถบันทึกไอคอนในทรัพยากร rdef ในไฟล์ปฏิบัติการของ ELF ได้ วันนี้ฉันอยากจะเห็นว่ามันทำงานอย่างไรจริงๆ
ทรัพยากร? จาก ผู้เขียนดั้งเดิมของ Macintosh Finder และ "บิดา" ของ Macintosh Resource Manager:
ฉันกังวลเกี่ยวกับลักษณะที่เข้มงวดของการเขียนโค้ดแบบดั้งเดิม สำหรับฉันแล้ว ความคิดที่ว่าแอปพลิเคชันค้างอยู่ในโค้ดโดยไม่มีความสามารถในการเปลี่ยนแปลงอะไรแบบไดนามิกนั้นถือเป็นสิ่งที่ป่าเถื่อนที่สุด ควรเป็นไปได้ที่จะเปลี่ยนแปลงให้ได้มากที่สุด ณ รันไทม์ แน่นอนว่ารหัสแอปพลิเคชันนั้นไม่สามารถเปลี่ยนแปลงได้ แต่บางสิ่งสามารถเปลี่ยนแปลงได้โดยไม่ต้องคอมไพล์รหัสใหม่
ใน Macintosh ดั้งเดิม พวกเขาทำให้ไฟล์เหล่านี้มี "ส่วนข้อมูล" และ "ส่วนทรัพยากร" ซึ่งทำให้การบันทึกสิ่งต่างๆ เช่น ไอคอน คำแปล และอื่นๆ ที่คล้ายกันเป็นเรื่องง่ายอย่างเหลือเชื่อ ในไฟล์ปฏิบัติการ
บน Mac จะใช้สิ่งนี้ , โปรแกรมกราฟิกสำหรับ - แก้ไขทรัพยากรโดยฉับพลัน
ResEdit บน Macintosh ดั้งเดิม
เป็นผลให้สามารถแก้ไขไอคอน รายการเมนู การแปล ฯลฯ ได้ ง่ายพอ แต่พวกเขายังคง “เดินทาง” กับแอปพลิเคชัน
ไม่ว่าในกรณีใด วิธีการนี้มีข้อเสียเปรียบอย่างมาก: ใช้ได้กับระบบไฟล์ของ Apple เท่านั้น ซึ่งเป็นสาเหตุหนึ่งที่ทำให้ Apple ละทิ้ง "ส่วนทรัพยากร" เมื่อย้ายไปใช้ Mac OS X
บน Mac OS X นั้น Apple ต้องการโซลูชันที่ไม่ขึ้นกับระบบไฟล์ ดังนั้นพวกเขาจึงนำแนวคิดของแพ็คเกจ (จาก NeXT) มาใช้ ซึ่งเป็นไดเร็กทอรีที่ตัวจัดการไฟล์ถือว่าเป็น "วัตถุทึบแสง" เหมือนไฟล์มากกว่าไดเร็กทอรี แพ็คเกจใด ๆ ที่มีแอปพลิเคชันในรูปแบบ .app มีไฟล์ Info.plist (ในบางประเภทที่เทียบเท่ากับ JSON หรือ YAML ของ Apple) ที่มีข้อมูลเมตาของแอปพลิเคชัน
คีย์สำหรับไฟล์ Info.plist จากแพ็คเกจแอปพลิเคชัน Mac OS X
ทรัพยากร เช่น ไอคอน ไฟล์ UI และอื่นๆ จะถูกจัดเก็บไว้ในแพ็คเกจเป็นไฟล์ แนวคิดนี้กลับไปสู่รากฐานของมันใน NeXT จริงๆ
Mathematica.app บน NeXTSTEP 1.0 ในปี 1989: ปรากฏเป็นไดเร็กทอรีของไฟล์ในเทอร์มินัล แต่เป็นออบเจ็กต์เดี่ยวในตัวจัดการไฟล์แบบกราฟิก
กลับมาที่ BeOS ซึ่งเป็นแนวคิดที่เป็นพื้นฐานของไฮกุ นักพัฒนาซอฟต์แวร์เมื่อเปลี่ยนจาก PEF (PowerPC) เป็น ELF (x86) (แบบเดียวกับที่ใช้บน Linux) ได้ตัดสินใจเพิ่มส่วนทรัพยากรที่ส่วนท้ายของไฟล์ ELF มันไม่ได้ใช้ส่วน ELF ที่เหมาะสมของตัวเอง แต่เพียงต่อท้ายไฟล์ ELF อันเป็นผลมาจากโปรแกรม strip และโปรแกรมอื่นๆ จาก binutils ที่ไม่ทราบเรื่องนี้ เพียงแค่ตัดมันออก ดังนั้นเมื่อเพิ่มทรัพยากรลงในไฟล์ ELF บน BeOS จะเป็นการดีกว่าที่จะไม่จัดการมันด้วยเครื่องมือ Linux
เกิดอะไรขึ้นกับไฮกุตอนนี้? โดยพื้นฐานแล้วเหมือนกันไม่มากก็น้อย
ตามทฤษฎีแล้ว มันเป็นไปได้ที่จะวางทรัพยากรไว้ในส่วนที่ต้องการของ ELF ตามที่นักพัฒนาในช่อง #haiku บน irc.freenode.net:
สำหรับ ELF ส่วนนี้จะดูสมเหตุสมผลมากขึ้น... เหตุผลเดียวที่เราไม่ทำแบบนั้นก็เพราะว่ามันเป็นสิ่งที่เราทำใน BeOS”
และไม่มีประโยชน์ที่จะเปลี่ยนแปลงสิ่งนี้ในตอนนี้
การจัดการทรัพยากร
ทรัพยากรถูกเขียนในรูปแบบ "ทรัพยากร" ที่มีโครงสร้าง โดยพื้นฐานแล้วคือรายการทรัพยากรที่มีขนาดและเนื้อหา ผมจำได้ .
จะตรวจสอบทรัพยากรในไฮกุได้อย่างไร? มีบางอย่างเช่น ResEdit หรือไม่?
ตามที่ :
หากต้องการดูทรัพยากรที่ให้ไว้ในแพ็คเกจแอปพลิเคชัน คุณสามารถลากไฟล์ปฏิบัติการไปยังโปรแกรมที่ต้องการได้ . คุณยังสามารถไปที่เทอร์มินัลแล้วรันคำสั่งได้
listres имя_файла.
ทรัพยากรมีอยู่ใน HaikuDepot แต่มันขัดข้องสำหรับฉัน
จะจัดการทรัพยากรในไฟล์ ELF ได้อย่างไร? โดยใช้ rsrc и rdef. rdef ไฟล์จะถูกรวบรวมไว้ใน rsrc. ไฟล์ rdef ถูกจัดเก็บในรูปแบบข้อความธรรมดา ดังนั้นจึงง่ายต่อการใช้งานมาก รูปแบบไฟล์ rsrc ต่อท้ายไฟล์ ELF มาลองเล่นกัน:
~> rc -h
Haiku Resource Compiler 1.1To compile an rdef script into a resource file:
rc [options] [-o <file>] <file>...To convert a resource file back into an rdef script:
rc [options] [-o <file>] -d <file>...Options:
-d --decompile create an rdef script from a resource file
--auto-names construct resource names from ID symbols
-h --help show this message
-I --include <dir> add <dir> to the list of include paths
-m --merge do not erase existing contents of output file
-o --output specify output file name, default is out.xxx
-q --quiet do not display any error messages
-V --version show software version and licenseคุณสามารถใช้โปรแกรม xres สำหรับการตรวจสอบและควบคุม:
/> xres
Usage: xres ( -h | --help )
xres -l <file> ...
xres <command> ...The first form prints this help text and exits.The second form lists the resources of all given files.The third form manipulates the resources of one or more files according to
the given commands.
(...)เอาล่ะ มาลองกันไหม?
/> xres -l /Haiku/system/apps/WebPositive/Haiku/system/apps/WebPositive resources:type ID size name
------ ----------- ----------- --------------------
'MIMS' 1 36 BEOS:APP_SIG
'APPF' 1 4 BEOS:APP_FLAGS
'MSGG' 1 421 BEOS:FILE_TYPES
'VICN' 101 7025 BEOS:ICON
'VICN' 201 91 kActionBack
'VICN' 202 91 kActionForward
'VICN' 203 300 kActionForward2
'VICN' 204 101 kActionStop
'VICN' 206 243 kActionGoStart
'MSGG' 205 1342 kActionGo
'APPV' 1 680 BEOS:APP_VERSIONข้อมูลเพิ่มเติมเกี่ยวกับทรัพยากรและรูปแบบ rdef คุณอ่านได้ .
ประเภททรัพยากรมาตรฐาน
แม้ว่าคุณจะสามารถใส่อะไรก็ได้ลงในทรัพยากรได้ แต่ก็มีประเภทมาตรฐานที่กำหนดไว้อยู่สองสามประเภท:
app_signature: ประเภทแอปพลิเคชัน MIME สำหรับการแมปการเปิดไฟล์ เรียกใช้ IPC ฯลฯapp_name_catalog_entry: เนื่องจากชื่อแอปพลิเคชันมักจะเป็นภาษาอังกฤษ คุณจึงสามารถระบุตำแหน่งที่มีชื่อที่แปลได้ เพื่อให้ผู้ใช้ภาษาต่างๆ สามารถดูชื่อแอปพลิเคชันที่แปลได้หากต้องการapp_version: ตรงตามที่คุณคิดapp_flags: บ่งชี้registrarวิธีการประมวลผลแอปพลิเคชัน ฉันคิดว่ามันมีอะไรมากกว่าที่ตาเห็น เช่นก็มีB_SINGLE_LAUNCHซึ่งบังคับให้ระบบเปิดกระบวนการแอปพลิเคชันใหม่ทุกครั้งที่ผู้ใช้ร้องขอ (หลักการเดียวกันนี้ใช้กับแอปพลิเคชันส่วนใหญ่บน Linux) กินB_MULTIPLE_LAUNCHส่งผลให้กระบวนการดำเนินไป แต่ละไฟล์. ในที่สุดก็มีB_EXCLUSIVE_LAUNCHซึ่งบังคับให้ระบบเปิดทีละกระบวนการเท่านั้น ไม่ว่าผู้ใช้จะเปิดใช้งานบ่อยแค่ไหนก็ตาม (เช่น นี่คือวิธีที่ Firefox ทำงานบน Linux ผลลัพธ์เดียวกันนี้สามารถทำได้ในแอปพลิเคชัน Qt โดยใช้ฟังก์ชันนี้ ). แอพพลิเคชั่นด้วยB_EXCLUSIVE_LAUNCHได้รับแจ้งเมื่อผู้ใช้พยายามเรียกใช้งานอีกครั้ง เช่น ได้รับเส้นทางของไฟล์ที่ผู้ใช้ต้องการเปิดด้วยความช่วยเหลือvector_icon: ไอคอนแอปพลิเคชันเวกเตอร์ (BeOS ไม่มีไอคอนเวกเตอร์ แอปพลิเคชันส่วนใหญ่จะมีไอคอนแรสเตอร์สองไอคอนในไฟล์ปฏิบัติการแทน)
แน่นอน คุณสามารถเพิ่มทรัพยากรด้วย ID และประเภทที่ต้องการ จากนั้นอ่านในแอปพลิเคชันเองหรือแอปพลิเคชันอื่นโดยใช้คลาส BResources. แต่ก่อนอื่น เรามาดูหัวข้อที่น่าสนใจของไอคอนกันก่อน
เวกเตอร์ไอคอนในสไตล์ไฮกุ
แน่นอนว่า ไม่เพียงแต่ไฮกุเท่านั้นที่เลือกรูปแบบไอคอนที่ดีที่สุด ในส่วนนี้ สถานการณ์กับสภาพแวดล้อมเดสก์ท็อป Linux ยังห่างไกลจากอุดมคติ:
me@host:~$ ls /usr/share/icons/hicolor/
128x128 256x256 512x512 index.theme
160x160 28x28 64x64 scalable
16x16 32x32 72x72 symbolic
192x192 36x36 8x8
22x22 42x42 96x96
24x24 48x48 icon-theme.cacheเมื่อมองดูสิ่งนี้ คุณจะรู้สึกได้เลยว่ามันคืออะไร
แน่นอนว่ามีการปรับขนาดได้ซึ่งประกอบด้วยไอคอนเวกเตอร์ตามที่คุณเข้าใจ แล้วทำไมมีอะไรอีกล่ะ? เพราะผลของการวาดภาพกราฟิกแบบเวกเตอร์ที่มีขนาดเล็กอาจจะน้อยกว่าอุดมคติ ฉันต้องการมีตัวเลือกต่างๆ ที่ปรับให้เหมาะกับขนาดต่างๆ ในสภาพแวดล้อมเดสก์ท็อป Linux สามารถทำได้โดยการกระจายไอคอนที่มีขนาดต่างกันทั่วทั้งระบบไฟล์
me@host:~$ find /usr/share/icons/ -name 'firefox.*'
/usr/share/icons/HighContrast/16x16/apps/firefox.png
/usr/share/icons/HighContrast/22x22/apps/firefox.png
/usr/share/icons/HighContrast/24x24/apps/firefox.png
/usr/share/icons/HighContrast/256x256/apps/firefox.png
/usr/share/icons/HighContrast/32x32/apps/firefox.png
/usr/share/icons/HighContrast/48x48/apps/firefox.png
/usr/share/icons/elementary-xfce/apps/128/firefox.png
/usr/share/icons/elementary-xfce/apps/16/firefox.png
/usr/share/icons/elementary-xfce/apps/22/firefox.png
/usr/share/icons/elementary-xfce/apps/24/firefox.png
/usr/share/icons/elementary-xfce/apps/32/firefox.png
/usr/share/icons/elementary-xfce/apps/48/firefox.png
/usr/share/icons/elementary-xfce/apps/64/firefox.png
/usr/share/icons/elementary-xfce/apps/96/firefox.png
/usr/share/icons/hicolor/128x128/apps/firefox.pngโปรดทราบ: ไม่มีแนวคิดเกี่ยวกับ Firefox เวอร์ชันที่แตกต่างกัน ดังนั้นจึงเป็นไปไม่ได้ที่จะจัดการกับสถานการณ์ของการมีแอปพลิเคชันหลายเวอร์ชันบนระบบได้อย่างสวยงาม
ไอคอน Firefox ที่แตกต่างกันในเวอร์ชันต่างๆ ขณะนี้เป็นไปไม่ได้ที่จะจัดการสิ่งนี้ใน Linux หากไม่มีไม้ค้ำยันต่างๆ
Mac OS X จัดการอย่างละเอียดยิ่งขึ้นอีกเล็กน้อย:
Mac:~ me$ find /Applications/Firefox.app | grep icns
/Applications/Firefox.app/Contents/MacOS/crashreporter.app
/Contents/Resources/crashreporter.icns
/Applications/Firefox.app/Contents/MacOS/updater.app/Contents/Resources/updater.icns
/Applications/Firefox.app/Contents/Resources/document.icns
/Applications/Firefox.app/Contents/Resources/firefox.icnsจะเห็นได้ว่ามีไฟล์เดียว firefox.icns ในแพ็คเกจ Firefox.appซึ่งมีทุกขนาดเพื่อให้เวอร์ชันที่แตกต่างกันของแอปพลิเคชันเดียวกันมีไอคอนที่แตกต่างกัน
ดีขึ้นมาก! ไอคอนเดินทางไปพร้อมกับแอปพลิเคชัน ทรัพยากรทั้งหมดอยู่ในไฟล์เดียว
กลับมาที่ไฮกุกันเถอะ โซลูชันที่น่าทึ่งไม่มีข้อยกเว้น ตาม :
มีการพัฒนารูปแบบ HVIF พิเศษซึ่งได้รับการปรับให้เหมาะสมที่สุดสำหรับขนาดที่เล็กและการเรนเดอร์ที่รวดเร็ว ดังนั้น ไอคอนของเราโดยส่วนใหญ่จึงมีขนาดเล็กกว่าในรูปแบบแรสเตอร์หรือในรูปแบบ SVG ที่ใช้กันอย่างแพร่หลาย
และยังคงได้รับการปรับปรุงให้เหมาะสม:
ขนาดไอคอนใน HVIF เทียบกับรูปแบบอื่น
ความแตกต่างคือลำดับความสำคัญ!
แต่ความมหัศจรรย์ไม่ได้สิ้นสุดเพียงแค่นี้ HVIF เดียวกันสามารถแสดงรายละเอียดในระดับที่แตกต่างกันได้ ขึ้นอยู่กับขนาดที่แสดง แม้ว่าจะเป็นรูปแบบเวกเตอร์ก็ตาม
ระดับรายละเอียดที่แตกต่างกัน (LOD) ขึ้นอยู่กับขนาดการเรนเดอร์
ตอนนี้เกี่ยวกับข้อเสีย: คุณไม่สามารถใช้ SVG ได้โยนมันลงใน ImageMagick แล้วเรียกมันวันละครั้ง คุณต้องผ่านหลายรอบเพื่อสร้างไอคอนในรูปแบบ HVIF คำอธิบาย อย่างไรก็ตาม IconOMatic สามารถนำเข้า SVG ได้ค่อนข้างไม่สมบูรณ์ รายละเอียด SVG ประมาณ 90% ได้รับการนำเข้าโดยมีความน่าจะเป็นอยู่บ้าง ส่วนอีก 10% ที่เหลือจะต้องได้รับการกำหนดค่าและเปลี่ยนแปลงด้วยตนเอง อ่านเพิ่มเติมเกี่ยวกับวิธีการที่ HVIF สร้างความมหัศจรรย์ ในบล็อก
การเพิ่มไอคอนให้กับแอปพลิเคชัน
ตอนนี้ฉันสามารถเพิ่มไอคอนลงในแพ็คเกจที่สร้างขึ้นได้ โดยคำนึงถึงข้อมูลที่ได้รับทั้งหมด
เนื่องจากฉันไม่ค่อยกระตือรือร้นที่จะวาดไอคอนของตัวเองสำหรับ QtQuickApp “Hello, World” ของฉันในตอนนี้ ฉันจึงดึงมันออกจาก Qt Creator
/Haiku/home> xres /Haiku/system/apps/QtCreator/bin/Qt Creator -o /Haiku/home/QtQuickApp/QtQuickApp -a VICN:101:BEOS:ICON /Haiku/system/apps/QtCreator/bin/Qt Creatorตรวจสอบว่าได้คัดลอกไอคอนแล้ว:
/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- --------------------
'VICN' 101 152238 BEOS:ICONดูดี แต่ทำไมเมื่อคัดลอกไอคอนใหม่แล้วมันไม่แสดงขึ้นมา
VICN:101:BEOS:ICONs ที่ถูกคัดลอกยังไม่ได้ใช้เป็นไอคอนแอปพลิเคชันในตัวจัดการไฟล์
ฉันพลาดอะไร?
ความคิดเห็นของผู้พัฒนา:
เราจำเป็นต้องสร้างไฟล์
rdefด้วยทรัพยากรทั้งหมด จากนั้นจึงดำเนินการคำสั่งrc имя.rdefสิ่งนี้จะสร้างไฟล์.rsrc. จากนั้นคุณต้องรันคำสั่งresattr -o имя_бинарника имя.rsrc. อย่างน้อยที่สุด ฉันใช้คำสั่งเช่นนี้เพื่อเพิ่มไอคอนให้กับสคริปต์ของฉัน
ฉันต้องการสร้างทรัพยากร ไม่ใช่คุณลักษณะ ฉันสับสนจริงๆ
แคชอัจฉริยะโดยใช้ระบบไฟล์
การเปิดและอ่านคุณลักษณะของ ELF ทำได้ช้า ตามที่ฉันเขียนไว้ข้างต้น ไอคอนจะถูกเขียนเป็นทรัพยากรในไฟล์นั้นเอง วิธีนี้มีความน่าเชื่อถือมากกว่าและช่วยให้คุณสามารถคัดลอกไปยังระบบไฟล์อื่นได้ อย่างไรก็ตาม มันจะถูกคัดลอกไปยังแอตทริบิวต์ระบบไฟล์ด้วยเช่นกัน BEOS:ICON. ใช้งานได้กับระบบไฟล์บางระบบเท่านั้น เช่น BFS ไอคอนที่แสดงโดยระบบ (ใน Tracker และ Deskbar) จะถูกอ่านจากแอตทริบิวต์เพิ่มเติมนี้ เนื่องจากโซลูชันนี้ทำงานได้อย่างรวดเร็ว ในบางตำแหน่ง (ซึ่งความเร็วไม่สำคัญ เช่น หน้าต่าง "เกี่ยวกับ" ทั่วไป) ระบบจะได้รับไอคอนโดยตรงจากทรัพยากรในไฟล์ แต่นี่ไม่ใช่จุดสิ้นสุด โปรดจำไว้ว่าบน Mac ผู้ใช้สามารถแทนที่ไอคอนของแอปพลิเคชัน ไดเร็กทอรี เอกสารได้ด้วยตัวเอง เนื่องจากบน Mac คุณสามารถทำสิ่งที่ "สำคัญ" เหล่านี้ได้ . ใน Haiku คุณควรคิดว่าทรัพยากร (ในไฟล์) เป็นไอคอนดั้งเดิมที่มาพร้อมกับแอปพลิเคชัน และแอตทริบิวต์ (ในระบบไฟล์ BFS) เป็นสิ่งที่ช่วยให้ผู้ใช้ทำการเปลี่ยนแปลงได้ตามต้องการ (แม้ว่าจะเป็นคำใบ้ก็ตาม GUI สำหรับการแทรกไอคอนที่กำหนดเองที่ด้านบนของไอคอนเป็นทางเลือก) ยังไม่ได้ใช้งานตามค่าเริ่มต้น)
การตรวจสอบแอ็ตทริบิวต์ระบบไฟล์
ด้วย resaddr สามารถตรวจสอบและตั้งค่าแอ็ตทริบิวต์ระบบไฟล์ได้
/> resattr
Usage: resattr [ <options> ] -o <outFile> [ <inFile> ... ]
Reads resources from zero or more input files and adds them as attributes
to the specified output file, or (in reverse mode) reads attributes from
zero or more input files and adds them as resources to the specified output
file. If not existent the output file is created as an empty file.
(...)โดยพื้นฐานแล้วมันคือ "กาว" ที่ทำการแปลงไปมาระหว่างทรัพยากร (เชื่อถือได้) และแอตทริบิวต์ระบบไฟล์ (เร็ว) และเนื่องจากระบบคาดว่าจะได้รับทรัพยากรและทำการคัดลอกโดยอัตโนมัติ ฉันจึงไม่ต้องกังวลอีกต่อไป
ความมหัศจรรย์ของแพ็คเกจ hpkg
ปัจจุบัน (บ่อยที่สุด) มีการใช้แพ็คเกจเพื่อรับโปรแกรมในไฮกุ .hpkg. อย่าหลงกลกับชื่อง่ายๆ เพราะรูปแบบ .hpkg ทำงานแตกต่างไปจากรูปแบบอื่นๆ โดยสิ้นเชิงที่มีชื่อคล้ายกันที่คุณเคยพบมา เนื่องจากมันมีพลังวิเศษอย่างแท้จริง
ด้วยรูปแบบแพ็คเกจแบบดั้งเดิม ฉันรู้สึกเสียใจเป็นเวลานานเพราะความจริงข้อนี้: คุณดาวน์โหลดสิ่งหนึ่ง (แพ็คเกจ) และอีกสิ่งหนึ่งได้รับการติดตั้งในระบบ (ไฟล์ภายในแพ็คเกจ) การจัดการไฟล์ (เช่นลบไฟล์เหล่านั้น) ค่อนข้างยากเมื่อติดตั้งแพ็คเกจด้วยวิธีดั้งเดิม และทั้งหมดเป็นเพราะเนื้อหาของแพ็คเกจ กระจายไปทั่วระบบไฟล์รวมถึงสถานที่ที่ผู้ใช้โดยเฉลี่ยอาจไม่มีสิทธิ์ในการเขียน สิ่งนี้ทำให้เกิดโปรแกรมทั้งคลาส - ผู้จัดการแพ็คเกจ. แต่การถ่ายโอนซอฟต์แวร์ที่ติดตั้งไว้แล้ว เช่น ไปยังเครื่องอื่น ดิสก์แบบถอดได้ หรือไฟล์เซิร์ฟเวอร์จะยิ่งยากขึ้น หากไม่ได้เป็นไปไม่ได้เลย บนระบบที่ใช้ Linux ทั่วไป อาจมีไฟล์หลายแสนถึงล้านไฟล์ได้อย่างง่ายดาย ไม่จำเป็นต้องพูดว่า สิ่งนี้ทั้งเปราะบางและช้า เช่น เมื่อเริ่มติดตั้งระบบ เมื่อติดตั้ง อัปเดตและถอนการติดตั้งแพ็คเกจปกติ และเมื่อคัดลอกวอลลุมสำหรับบูท (พาร์ติชันรูท) ไปยังสื่ออื่น
ฉันกำลังทำงานในโปรเจ็กต์ AppImage ซึ่งเป็นส่วนเสริมบางส่วนสำหรับแอปพลิเคชันสำหรับผู้ใช้ปลายทาง นี่คือรูปแบบการแจกจ่ายซอฟต์แวร์ที่รวบรวมแอปพลิเคชันและการขึ้นต่อกันทั้งหมดไว้ในอิมเมจระบบไฟล์เดียวที่จะติดตั้งเมื่อแอปพลิเคชันเริ่มทำงาน ลดความซับซ้อนของสิ่งต่าง ๆ ลงอย่างเห็นได้ชัด เนื่องจาก ImageMagick เดียวกันนั้นก็กลายเป็นไฟล์เดียว จัดการในตัวจัดการไฟล์โดยมนุษย์ธรรมดา วิธีที่เสนอนี้ใช้ได้กับซอฟต์แวร์เท่านั้น ดังที่แสดงในชื่อของโครงการ และยังมีปัญหาอยู่ด้วย เนื่องจากผู้ที่เกี่ยวข้องกับการส่งมอบซอฟต์แวร์สำหรับ Linux มักจะชี้ลูกศรมาที่ฉัน
กลับมาที่ไฮกุกันเถอะ เป็นไปได้ไหมที่จะค้นหาความสมดุลที่เหมาะสมที่สุดระหว่างระบบแพ็คเกจแบบเดิมและการส่งมอบซอฟต์แวร์ที่ใช้รูปภาพ แพ็คเกจของเธอ .hpkg อิมเมจระบบไฟล์ที่ถูกบีบอัดจริง ๆ เมื่อระบบบู๊ต เคอร์เนลจะเมาต์แพ็คเกจที่ติดตั้งและใช้งานอยู่ทั้งหมดโดยมีข้อความเคอร์เนลต่อไปนี้โดยประมาณ:
KERN: package_daemon [16042853: 924] active package: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023: 924] active package: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232: 924] active package: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405: 924] active package: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611: 924] active package: "llvm_libs-5.0.0-3-x86_64.hpkg"เจ๋งใช่มั้ย? อยู่ตรงนั้นมันจะเจ๋งกว่านี้อีก!
มีแพ็คเกจสุดพิเศษดังนี้
KERN: package_daemon [16040020: 924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"มันมีระบบปฏิบัติการที่เรียบง่ายมาก รวมถึงเคอร์เนลด้วย เชื่อหรือไม่ว่าแม้แต่เคอร์เนลเองก็ไม่ได้ถูกลบออกจากโวลุ่มสำหรับบูต (พาร์ติชันรูท) แต่ถูกโหลดอย่างระมัดระวังจากแพ็คเกจ .hpkg. ว้าว! ฉันได้กล่าวไปแล้วว่าฉันคิดว่าส่วนหนึ่งของความซับซ้อนและความสม่ำเสมอโดยรวมของ Haiku มาจากข้อเท็จจริงที่ว่าระบบทั้งหมด ตั้งแต่เคอร์เนลและพื้นที่ผู้ใช้หลักไปจนถึงการจัดการแพ็คเกจและโครงสร้างพื้นฐานรันไทม์ ได้รับการพัฒนาร่วมกันโดยทีมเดียว ลองนึกภาพว่าต้องใช้กลุ่มและทีมจำนวนเท่าใดจึงจะสามารถดำเนินการเช่นนี้บน Linux [ฉันจินตนาการถึงโครงการ PuppyLinux - ประมาณ นักแปล]. จากนั้นลองจินตนาการว่าจะต้องใช้เวลานานเท่าใดในการนำแนวทางนี้ไปใช้ในการแจกแจง พวกเขาพูดว่า: เอาปัญหาง่ายๆ มาแบ่งระหว่างผู้แสดงที่แตกต่างกัน และมันจะซับซ้อนมากจนไม่สามารถแก้ไขได้อีกต่อไป ไฮกุในกรณีนี้ทำให้ฉันลืมตาขึ้น ฉันคิดว่านี่คือสิ่งที่เกิดขึ้นบน Linux ในตอนนี้ (Linux ในกรณีนี้เป็นคำรวมสำหรับ Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu stack)
การย้อนกลับระบบโดยใช้ hpkg
สถานการณ์ต่อไปนี้เกิดขึ้นบ่อยแค่ไหน: การอัปเดตสำเร็จแล้วปรากฎว่ามีบางอย่างไม่ทำงานอย่างที่ควรจะเป็น? หากคุณใช้ตัวจัดการแพ็คเกจแบบเดิม เป็นการยากที่จะคืนสถานะของระบบไปยังจุดเวลาก่อนที่จะติดตั้งแพ็คเกจใหม่ (ตัวอย่างเช่น ในกรณีที่มีบางอย่างผิดพลาด) บางระบบเสนอวิธีแก้ปัญหาชั่วคราวในรูปแบบของสแน็ปช็อตระบบไฟล์ แต่วิธีเหล่านี้ค่อนข้างยุ่งยากและไม่ได้ใช้กับทุกระบบ ไฮกุแก้ปัญหานี้โดยใช้แพ็คเกจ .hpkg. เมื่อใดก็ตามที่แพ็คเกจมีการเปลี่ยนแปลงในระบบ แพ็คเกจเก่าจะไม่ถูกลบ แต่จะถูกเก็บไว้ในระบบในไดเร็กทอรีย่อยเช่น /Haiku/system/packages/administrative/state-<...>/ อย่างสม่ำเสมอ. การดำเนินการที่ยังไม่เสร็จสิ้นจะจัดเก็บข้อมูลไว้ในไดเรกทอรีย่อย /Haiku/system/packages/administrative/transaction-<...>/.
เนื้อหา /Haiku/system/packages/administrative. ไดเร็กทอรี "state..." มีไฟล์ข้อความที่มีชื่อของแพ็คเกจที่ใช้งานอยู่ และไดเร็กทอรี "transaction..." มีแพ็คเกจเหล่านั้นด้วย
"สถานะใช้งานเก่า" เช่น รายการ .hpkg แพ็คเกจที่ใช้งานก่อนการเปลี่ยนแปลงจะถูกบันทึกหลังการดำเนินการแต่ละครั้งในตัวจัดการไฟล์ในไฟล์ข้อความ /Haiku/system/packages/administrative/state-<...>/activated-packages. ในทำนองเดียวกัน "สถานะใช้งานอยู่" ใหม่จะถูกเขียนลงในไฟล์ข้อความ /Haiku/system/packages/administrative/activated-packages.
ไดเรกทอรี /Haiku/system/packages/administrative/state-<...>/ มีเพียงไฟล์ข้อความที่มีรายการแพ็คเกจที่ใช้งานอยู่ในสถานะนี้ (ในกรณีของการติดตั้งแพ็คเกจโดยไม่มีการลบออก) และหากแพ็คเกจถูกลบหรืออัพเดต - ไดเร็กทอรีสถานะจะมีแพ็คเกจเวอร์ชันเก่า
เมื่อระบบบู๊ต การตัดสินใจเปิดใช้งาน (เมานต์) แพ็คเกจขึ้นอยู่กับรายการแพ็คเกจ มันง่ายมาก! หากมีสิ่งผิดปกติเกิดขึ้นระหว่างการดาวน์โหลด คุณสามารถบอกให้ตัวจัดการดาวน์โหลดใช้รายการอื่นที่เก่ากว่าได้ แก้ไขปัญหา!
โปรแกรมดาวน์โหลดไฮกุ แต่ละจุดเริ่มต้นจะแสดง "สถานะใช้งาน" ที่สอดคล้องกัน
ฉันชอบวิธีการมีไฟล์ข้อความธรรมดาเป็นรายการ "สถานะใช้งาน" โดยมีชื่อที่เข้าใจง่าย .hpkg. สิ่งนี้แตกต่างอย่างสิ้นเชิงกับการสร้างมาเพื่อเครื่องจักรไม่ใช่เพื่อผู้คน จาก OSTree หรือ Flatpak ในระบบไฟล์ (ในระดับเดียวกับ Microsoft GUID)
รายการแพ็คเกจที่ใช้งานอยู่ในแต่ละช่วงเวลา
ข้อมูลการกำหนดค่า
เห็นได้ชัดว่าอยู่ในแคตตาล็อก /Haiku/system/packages/administrative/writable-files มีไฟล์การกำหนดค่าสำหรับแพ็คเกจ แต่สามารถเขียนได้ ท้ายที่สุดแล้วอย่างที่คุณจำได้ .hpkg ติดตั้งแบบอ่านอย่างเดียว ดังนั้นจะต้องคัดลอกไฟล์เหล่านี้จากแพ็คเกจก่อนเขียน มีความหมาย.
การรวม GUI สำหรับระบบ .hpkg
มาดูกันว่ากระเป๋าแวววาวเหล่านี้เป็นอย่างไร .hpkg รับมือกับการบูรณาการเข้ากับสภาพแวดล้อมการทำงานของผู้ใช้ (UX) ท้ายที่สุดแล้ว ไฮกุก็มีไว้สำหรับการใช้งานส่วนตัว โดยส่วนตัวแล้ว ฉันตั้งค่ามาตรฐานไว้สูงเมื่อเปรียบเทียบประสบการณ์ผู้ใช้กับแพ็คเกจ .app บน Macintosh ด้วยประสบการณ์เดียวกันบน .hpkg. ฉันจะไม่เปรียบเทียบสถานการณ์กับสภาพแวดล้อมการทำงานบน Linux ด้วยซ้ำ เพราะมันแย่มากเมื่อเทียบกับที่อื่น
สถานการณ์ต่อไปนี้อยู่ในใจ:
- ฉันต้องการดูเนื้อหาของแพ็คเกจ
.hpkg - ฉันต้องการติดตั้งแพ็คเกจ
- ฉันต้องการถอดแพ็คเกจออก
- ฉันต้องการลบบางสิ่งที่เข้ามาในระบบโดยเป็นส่วนหนึ่งของแพ็คเกจ
- ฉันต้องการคัดลอกสิ่งที่เข้ามาในระบบโดยเป็นส่วนหนึ่งของแพ็คเกจ
- ฉันต้องการดาวน์โหลดการขึ้นต่อกันทั้งหมดของแพ็คเกจ ซึ่งอาจไม่ได้เป็นส่วนหนึ่งของการติดตั้ง Haiku ทุกครั้ง (เช่น ฉันมีเครื่องที่แยกออกมาทางกายภาพโดยไม่มีการเชื่อมต่ออินเทอร์เน็ต)
- ฉันต้องการย้ายแพ็คเกจของฉัน (หรือบางส่วน) แยกกันไปยังตำแหน่งอื่น โดยแยกจากวอลลุมสำหรับบูท (พาร์ติชั่นรูท) (เพราะว่าฉันมีพื้นที่ว่างไม่เพียงพอในนั้น)
สิ่งนี้ควรครอบคลุมกรณีสำคัญส่วนใหญ่จากการทำงานในแต่ละวันของฉัน เอาล่ะ มาเริ่มกันเลย
การตรวจสอบสิ่งของในบรรจุภัณฑ์
บน Mac ฉันเพียงคลิกขวาที่แพ็คเกจเพื่อเปิดและดูเนื้อหาใน Finder ที่จริงแล้วมันเป็นเพียงไดเร็กทอรีปลอมตัวเท่านั้น! (ฉันรู้ว่ามีแพ็คเกจ .pkg สำหรับส่วนหนึ่งของระบบที่ไม่ใช่แอปพลิเคชัน แต่ผู้ใช้ทั่วไปส่วนใหญ่มักไม่โต้ตอบกับพวกเขา)
ในเรื่องไฮกุ ฉันคลิกขวาที่แพ็คเกจ จากนั้นคลิกที่ "เนื้อหา" เพื่อดูว่ามีอะไรอยู่ข้างใน แต่นี่เป็นเพียงรายการไฟล์ที่ไม่สามารถเปิดได้ด้วยการดับเบิลคลิก
จะดีกว่ามากหากมีวิธีติดตั้งแพ็คเกจ (ชั่วคราว) .hpkg เพื่อดูผ่านตัวจัดการไฟล์ และผู้ใช้จะไม่ต้องกังวลกับรายละเอียดการใช้งาน (ยังไงก็เปิดได้. .hpkg บรรจุใน Expanderซึ่งสามารถแตกไฟล์ได้เหมือนกับไฟล์เก็บถาวรอื่นๆ)
อินเทอร์เฟซของ HaikuDepot ช่วยให้คุณสามารถดูรายการไฟล์แพ็กเกจได้ แต่ไม่มีวิธีใดในการดูเนื้อหาโดยการดับเบิลคลิก README.md
Mac ชนะในหมวดหมู่นี้ แต่การเพิ่มฟังก์ชัน HaikuDepot ที่คุณต้องการไม่น่าจะยากเกินไป
การติดตั้งแพ็คเกจผ่าน GUI
บน Mac, ดิสก์อิมเมจส่วนใหญ่ .dmg มีแพ็คเกจ .app. คลิกสองครั้งที่ดิสก์อิมเมจ จากนั้นคัดลอกแพ็คเกจ เช่น โดยการลากเข้าไป /Applications ในเครื่องมือค้นหา สิ่งนี้ดำเนินไปโดยไม่ได้บอกฉัน แต่ฉันได้ยินมาว่ามือใหม่บางคนอาจไม่สามารถจัดการสิ่งนี้ได้ ตามค่าเริ่มต้น Apple "แนะนำ" ไดเรกทอรีทั้งระบบ /Applications (บน NeXT เป็นแบบเครือข่ายเช่นเดียวกับรายบุคคล) แต่คุณสามารถวางแอปพลิเคชันของคุณบนเซิร์ฟเวอร์ไฟล์หรือในไดเร็กทอรีย่อยได้อย่างง่ายดาย $HOME/Applicationsถ้าคุณชอบแบบนั้น
ในเรื่องไฮกุดับเบิลคลิกที่แพ็คเกจ จากนั้นคลิกที่ “ติดตั้ง” ไม่มีอะไรง่ายไปกว่านี้แล้ว ฉันสงสัยว่าจะเกิดอะไรขึ้นหากแพ็คเกจมีการขึ้นต่อกันที่มีอยู่ใน HaikuPorts แต่ยังไม่ได้ติดตั้ง บน Linux พวกเขาไม่รู้จริงๆ ว่าต้องทำอย่างไรในสถานการณ์นี้ แต่วิธีแก้ปัญหานั้นชัดเจน - ถามผู้ใช้ว่าจำเป็นต้องดาวน์โหลดและติดตั้งการขึ้นต่อกันหรือไม่ ตรงกับสิ่งที่ไฮกุทำ
ฉันดาวน์โหลดแพ็คเกจ 'สติ' ด้วยตนเองแล้วคลิกแพ็คเกจนั้น ตัวจัดการแพ็คเกจรู้ว่าจะรับการขึ้นต่อกันได้จากที่ไหน (สมมติว่าที่เก็บบันทึกไว้ในระบบแล้ว) ไม่ใช่ทุกการแจกจ่าย Linux ที่สามารถทำได้
อีกวิธีหนึ่งคือการใช้ตัวจัดการไฟล์ เพียงลากและวาง .hpkg แพ็คเกจหรือใน /Haiku/system/packages (สำหรับการติดตั้งทั้งระบบตามค่าเริ่มต้น) หรือใน /Haiku/home/config/packages (สำหรับการติดตั้งแต่ละรายการ ไม่สามารถใช้งานได้เมื่อดับเบิลคลิก - ฉันยังรู้สึกรำคาญกับคำว่า "config" ในที่นี้ ซึ่งสำหรับฉันในกรณีนี้มีความหมายเหมือนกันกับ "การตั้งค่า") และแนวคิดเรื่องผู้ใช้หลายคนยังไม่พร้อมใช้งานสำหรับไฮกุ (นั่นอาจเป็นเหตุผลว่าทำไมมันถึงง่ายมาก - ฉันไม่รู้ บางทีความสามารถของผู้ใช้หลายคนอาจทำให้สิ่งต่าง ๆ ซับซ้อนสำหรับสภาพแวดล้อมเดสก์ท็อปเดสก์ท็อปโดยไม่จำเป็น)
ไฮกุชนะในหมวดหมู่นี้เนื่องจากสามารถทำงานได้ไม่เพียงกับแอปพลิเคชันเท่านั้น แต่ยังรวมถึงโปรแกรมระบบด้วย
การลบแพ็คเกจออกจาก GUI
บน Macคุณต้องลากไอคอนแอปพลิเคชันไปที่ถังขยะ เท่านี้ก็เรียบร้อย อย่างง่ายดาย!
ในเรื่องไฮกุประการแรก คุณต้องค้นหาตำแหน่งของแพ็คเกจบนระบบ เนื่องจากคุณไม่ค่อยติดตั้งมันในตำแหน่งที่ถูกต้อง (ระบบทำทุกอย่าง) ปกติแล้วจะต้องเข้าไปดูครับ /Haiku/system/packages (ด้วยการติดตั้งเริ่มต้นทั้งระบบ) หรือใน /Haiku/home/config/packages (ฉันบอกไปแล้วว่า “config” เป็นการเรียกชื่อผิดหรือเปล่า?) จากนั้นแอปพลิเคชันก็จะถูกลากไปที่ถังขยะเท่านั้นเอง
อย่างง่ายดาย! อย่างไรก็ตามฉันจะไม่พูดอย่างนั้น นี่คือสิ่งที่เกิดขึ้นจริง:
นี่คือสิ่งที่จะเกิดขึ้นหากคุณลากแอปพลิเคชันไปที่ถังขยะ /Haiku/system/packages
เพิ่งพยายามย้ายแอปพลิเคชัน "Hello World" เมื่อวานของฉันบน QtQuickApp ไปที่ถังขยะ ฉันไม่ได้พยายามย้ายไดเร็กทอรีระบบ และเนื่องจากแพ็คเกจทั้งหมดได้รับการติดตั้งในไดเร็กทอรีระบบ จึงไม่สามารถลบแพ็คเกจได้ .hpkg โดยไม่มีการเปลี่ยนแปลง "เนื้อหาของมัน". ผู้ใช้ทั่วไปจะกลัวและกดปุ่ม "ยกเลิก" ที่กำหนดโดยค่าเริ่มต้น
อธิบาย :
กระทู้นี้มีอายุเกิน 10 ปีแล้ว เป็นไปได้มากที่เราจะต้องกำหนดค่าเพื่อให้คำเตือนปรากฏเฉพาะเมื่อมีการย้ายแพ็คเกจเท่านั้น ผู้ใช้ทั่วไปไม่จำเป็นต้องทำเช่นนี้อยู่แล้ว
โอเค บางทีฉันควรทำสิ่งนี้โดยใช้ HaikuDepot ใช่ไหม ฉันดับเบิลคลิกที่แพ็คเกจใน /Haiku/system/packagesโดยรอให้ปุ่ม “ถอนการติดตั้ง” ปรากฏขึ้น ไม่ มี (เท่านั้น) “ติดตั้ง” "ถอนการติดตั้ง" คุณอยู่ที่ไหน?
เพื่อความสนุก ฉันพยายามดูว่าจะเกิดอะไรขึ้นหากฉันคลิก “ติดตั้ง” บนแพ็คเกจที่ติดตั้งไว้แล้ว ปรากฎดังนี้:
สิ่งนี้จะเกิดขึ้นหากคุณพยายามติดตั้งแพ็คเกจที่ติดตั้งไว้แล้ว
ถัดไปปรากฏขึ้น:
หากคุณคลิก “ใช้การเปลี่ยนแปลง” ในหน้าต่างก่อนหน้า จะมีลักษณะเช่นนี้
ฉันคิดว่านี่เป็นข้อผิดพลาดของซอฟต์แวร์ ลิงก์ไปยังแอปพลิเคชันอยู่ที่นั่นแล้ว [ผู้เขียนไม่ได้ให้ลิงค์ - ประมาณ. นักแปล]
วิธีแก้ปัญหาด่วน: เพิ่มปุ่ม "ถอนการติดตั้ง" หากมีแพ็คเกจอยู่แล้ว
/Haiku/system/packagesหรือใน/Haiku/home/config/packages.
เมื่อดูรายการแพ็คเกจที่ติดตั้งใน HaikuDepot ฉันเห็นแพ็คเกจของฉันในรายการและสามารถลบออกได้
Mac ชนะในประเภทนี้ แต่ฉันสามารถจินตนาการได้ว่าด้วยการตั้งค่าที่เหมาะสม ประสบการณ์ผู้ใช้บน Haiku จะดีกว่าบน Mac (นักพัฒนารายหนึ่งให้คะแนนด้วยวิธีนี้: “ใช้เวลาน้อยกว่าหนึ่งชั่วโมงในการเพิ่มฟังก์ชันการทำงานที่ระบุให้กับ HaikuDepot หากคุณรู้จัก C++ เพียงเล็กน้อย” มีอาสาสมัครคนใดบ้าง)
การนำบางสิ่งออกจากแพ็คเกจ
ลองลบแอปพลิเคชันออก ไม่ใช่แพ็กเกจ .hpkgซึ่งมันเกิดขึ้นมา (ฉันสงสัยว่าสำหรับ “มนุษย์ปุถุชน” นั้นมีความแตกต่างกันบ้างไหม)
บน Macโดยปกติแล้วผู้ใช้จะทำงานกับไฟล์ได้จริง .dmgแพ็คเกจแอปพลิเคชันมาจากไหน .app. โดยปกติแล้วรูปภาพ .dmg ถูกสะสมไว้ในไดเร็กทอรีดาวน์โหลดและผู้ใช้คัดลอกแพ็คเกจไปยัง /Applications. เชื่อกันว่าผู้ใช้หลายคนไม่รู้ว่ากำลังทำอะไรอยู่ สมมติฐานนี้ได้รับการยืนยันจากอดีตพนักงานของ Apple (สิ่งหนึ่งที่ฉันไม่ชอบบน Mac และตัวอย่างเช่น AppImage ไม่มีความแตกต่างระหว่างแอปพลิเคชันและแพ็คเกจที่มีอยู่ ลากไอคอนไปที่ถังขยะ = ง่ายๆ เลย!)
ในเรื่องไฮกุนอกจากนี้ยังมีการแบ่งแยกระหว่าง apps/ и packages/ดังนั้นฉันจึงสงสัยว่าสิ่งนี้จะทำให้ผู้ใช้เข้าใจได้ชัดเจนยิ่งขึ้น แต่จะเกิดอะไรขึ้นหากคุณลากแอปพลิเคชันมา apps/ เพิ่มลงตะกร้า:
นี่คือสิ่งที่เกิดขึ้นเมื่อคุณพยายามลบแอปพลิเคชันที่นำมาจากไฟล์ .hpkg
ในทางเทคนิคแล้ว มันถูกต้อง (ท้ายที่สุดแล้ว แอปพลิเคชันนั้นโฮสต์อยู่บนระบบไฟล์แบบอ่านอย่างเดียวตั้งแต่แรก) แต่ก็ไม่ได้มีประโยชน์กับผู้ใช้เป็นพิเศษ
วิธีแก้ปัญหาด่วน: แนะนำให้ใช้ GUI เพื่อลบแทน
.hpkg
เพื่อความสนุกสนาน ฉันลองทำซ้ำแอปพลิเคชันโดยกด Alt+D ฉันได้รับข้อความ "ไม่สามารถย้ายหรือคัดลอกออบเจ็กต์บนโวลุ่มแบบอ่านอย่างเดียวได้" และทั้งหมดเป็นเพราะ /system (นอกจาก /system/packages и /system/settings) เป็นจุดเมานต์ packagefs (จำไว้ว่ามันจะปรากฏอย่างไรในเอาต์พุต df?) น่าเสียดายที่ผลลัพธ์ของคำสั่ง mount ไม่ได้ชี้แจงสถานการณ์ (ดังที่ได้กล่าวไว้ในบทความก่อนหน้านี้) mountvolume ไม่แสดงสิ่งที่คุณกำลังมองหา (เห็นได้ชัดว่าแพ็คเกจเมานต์ผ่านการวนซ้ำ) .hpkg ไม่ถือเป็น "วอลุ่ม" และฉันก็ลืมคำสั่งทางเลือกด้วย
ไม่มีใครชนะในหมวดหมู่นี้ยกเว้น AppImage (แต่พูดตามตรงว่าเป็นความคิดเห็นที่มีอคติ) อย่างไรก็ตาม ใครๆ ก็สามารถจินตนาการได้ว่าหลังจากปรับแต่งแล้ว ประสบการณ์ผู้ใช้บน Haiku จะดีกว่าบน Mac
หมายเหตุ: คุณต้องค้นหาว่า "ปริมาตร" เกี่ยวข้องกับ "ส่วน" ใด นี่อาจคล้ายกับความสัมพันธ์ระหว่าง "โฟลเดอร์" กับ "ไดเร็กทอรี": ไดเร็กทอรีส่วนใหญ่ปรากฏเป็นโฟลเดอร์ในตัวจัดการไฟล์ แต่ไม่ใช่ทั้งหมด (เช่น แพ็คเกจที่ถือเป็นไฟล์) การแสดงแบบนี้ทำให้ฉันกลายเป็นเด็กเนิร์ดอย่างเป็นทางการหรือเปล่า?
การคัดลอกเนื้อหาของแพ็คเกจไปยังระบบอื่น
บน Macฉันลากแพ็คเกจอย่างโง่เขลา .appและเนื่องจากการขึ้นต่อกันนั้นอยู่ภายในแพ็คเกจ พวกเขาจึงย้ายไปด้วยกัน
ในเรื่องไฮกุฉันลากแอปพลิเคชัน แต่การขึ้นต่อกันไม่ได้รับการประมวลผลเลย
วิธีแก้ไขด่วน: ขอแนะนำให้ลากแพ็คเกจ `.hpkg ทั้งหมดแทน พร้อมทั้งการอ้างอิงใดๆ ถ้ามี
Mac ชนะอย่างชัดเจนในหมวดหมู่นี้ อย่างน้อยสำหรับฉัน ผู้รักกระบวนทัศน์ของพวกเขา ฉันควรคัดลอกไปที่ไฮกุ .hpkg แทนแอปพลิเคชัน แต่ระบบไม่เสนอสิ่งนี้ให้ฉัน...
ดาวน์โหลดแพ็คเกจที่มีการขึ้นต่อกันทั้งหมด
ไม่ใช่ทุกเครื่องจะเชื่อมต่อกับเครือข่ายตลอดเวลา ในทางตรงกันข้าม บางเครื่อง (ใช่แล้ว ฉันกำลังดูคุณอยู่ Windows, Mac และ Linux สมัยใหม่) ลืมเรื่องนี้ไป เป็นสิ่งสำคัญสำหรับฉันที่ฉันสามารถไปที่ร้านอินเทอร์เน็ตดาวน์โหลดซอฟต์แวร์ลงในไดรฟ์แบบถอดได้ ใส่ไดรฟ์นี้ลงในคอมพิวเตอร์ที่บ้านของฉัน และตรวจสอบให้แน่ใจว่าทุกอย่างจะทำงานได้ [คนที่มีความเสี่ยง ทำสิ่งนี้บน Windows... - ประมาณ นักแปล]
เป็นผลให้ฉันมักจะจบลงด้วยการพึ่งพาที่ไม่ได้รับการตอบสนองบน Windows และ Linux บ่อยกว่าปกติเล็กน้อย
บน Mac โดยปกติจะเป็นไฟล์เดียว สิ่งที่คุณต้องทำคือดาวน์โหลด .dmg. โดยส่วนใหญ่แล้วจะไม่มีการขึ้นต่อกันอื่นใดนอกจากที่ MacOS จัดเตรียมไว้ให้ตามค่าเริ่มต้น ข้อยกเว้นคือแอปพลิเคชันที่ซับซ้อนซึ่งจำเป็นต้องมีสภาพแวดล้อมการดำเนินการที่เหมาะสม เช่น java
ในเรื่องไฮกุ ดาวน์โหลดแพ็คเกจ .hpkg สำหรับเช่นแอปพลิเคชันเดียวกันใน java อาจไม่เพียงพอ เนื่องจาก java อาจมีหรือไม่มีอยู่บนเครื่องเป้าหมาย มีวิธีดาวน์โหลดการอ้างอิงทั้งหมดสำหรับแพ็คเกจที่กำหนดหรือไม่ .hpkgนอกเหนือจากที่ติดตั้งตามค่าเริ่มต้นใน Haiku และดังนั้นจึงควรอยู่ในทุกระบบ Haiku?
Mac ชนะหมวดหมู่นี้ด้วยอัตรากำไรเล็กน้อย
ความเห็น นาย. เดินเตาะแตะ:
เพื่อเขียนโปรแกรมเพื่อรวบรวมการขึ้นต่อกันของแอปพลิเคชันทั้งหมดเป็นชุดแพ็คเกจ
.hpkgสำหรับคนที่คุ้นเคยกับการทำงานภายในของไฮกุประมาณ 15 นาทีก็เพียงพอแล้ว การเพิ่มการสนับสนุนสำหรับสิ่งนี้ไม่ใช่เรื่องยากหากมีความจำเป็นจริงๆ แต่สำหรับฉันนี่เป็นสถานการณ์ที่หายาก
กลั้นหายใจไว้จนถึงบทความหน้าในชุดนี้
การย้ายพัสดุไปยังตำแหน่งอื่น
อย่างที่ฉันเขียนไว้ก่อนหน้านี้ ฉันต้องการวางพัสดุของฉัน .hpkg (ดีหรือบางส่วน) ไปยังสถานที่พิเศษ แยกจากตำแหน่งปกติบนโวลุ่มสำหรับบูต (พาร์ติชันรูท) ในกรณีปกติ (ไม่ใช่ตามทฤษฎี) เหตุผลก็คือฉันมีพื้นที่ว่างบนดิสก์ (ในตัว) ของฉันหมดอย่างต่อเนื่องไม่ว่าจะมีขนาดใหญ่แค่ไหนก็ตาม และฉันมักจะเชื่อมต่อไดรฟ์ภายนอกหรือการแชร์เครือข่ายที่มีแอปพลิเคชันของฉันอยู่
บน Mac ฉันแค่กำลังขนย้ายพัสดุ .app ไปยังไดรฟ์แบบถอดได้หรือไดเร็กทอรีเครือข่ายใน Finder เท่านี้ก็เรียบร้อย ฉันยังสามารถดับเบิลคลิกเพื่อเปิดแอปพลิเคชันได้ตามปกติจากวอลลุมสำหรับบูท แค่!
ในเรื่องไฮกุอย่างที่ฉันบอกไปแล้วว่าสิ่งนี้สามารถทำได้โดยการย้ายของฉัน .hpkg ไปยังไดรฟ์แบบถอดได้หรือไดเร็กทอรีเครือข่าย แต่คุณจำเป็นต้องใช้คำสั่งที่ไม่มีเอกสารในคอนโซลเพื่อติดตั้งบนระบบ ฉันไม่รู้วิธีการทำเช่นนี้โดยใช้เพียง GUI
Mac ชนะในประเภทนี้
ตามที่นาย. เดินเตาะแตะ:
นี่คือการเพิ่มประสิทธิภาพตามการใช้งานปกติ หากมีความต้องการจากผู้ใช้มากกว่าหนึ่งราย เราจะดำเนินการดังกล่าว ไม่ว่าในกรณีใด มีความเป็นไปได้ที่บุคคลที่สามจะนำไปใช้
เราจะพูดถึงเรื่องนี้ในบทความถัดไป
เมื่อพูดถึงไดเร็กทอรีเครือข่าย คงจะดีไม่น้อย (ฉันเดาว่าเป็นฝ่าย LAN) ที่จะมีแอปพลิเคชันที่เรียบง่าย ค้นพบได้ ทั่วทั้งเครือข่าย (เช่น Zeroconf) ที่สามารถคัดลอกไปยังเครื่องคอมพิวเตอร์เฉพาะที่หรือเรียกใช้โดยตรงจากเครือข่ายท้องถิ่น แน่นอนว่านักพัฒนามีตัวเลือกในการยกเลิกผ่านทาง app_flags.
รายงานขั้นสุดท้ายเกี่ยวกับการรวมระบบ hpkg เข้ากับ GUI
ฉันคิดว่าสาเหตุหลักมาจากความใหม่ของการบูรณาการ .hpkg GUI ยังคงเป็นที่ต้องการอีกมาก อย่างไรก็ตาม มีบางสิ่งที่สามารถปรับปรุงได้ในแง่ของ UX...
อีกสิ่งหนึ่ง: Kernel Debug Land
คงจะดีไม่น้อยหากสามารถป้อนคำสั่งระหว่างที่เคอร์เนลตื่นตระหนกได้ เป็นต้น syslog | grep usb. ในไฮกุเป็นไปได้ด้วย Kernel Debug Land คุณจะมองเห็นความมหัศจรรย์นี้ได้อย่างไรหากทุกอย่างทำงานได้ตามปกติโดยที่ไม่เกิดอาการตื่นตระหนกกับเคอร์เนล? ง่าย ๆ โดยการกด Alt+PrintScn+D (ช่วยจำ Debug) ฉันจำได้ทันที ซึ่งอนุญาตให้นักพัฒนา Macintosh ดั้งเดิมเข้าสู่ดีบักเกอร์ได้ (หากติดตั้งไว้แน่นอน)
ข้อสรุป
ฉันเริ่มเข้าใจว่าความซับซ้อนของระบบไฮกุนั้นมาจากการที่งานนี้ดำเนินการโดยทีมงานเล็กๆ ทีมเดียวที่ให้ความสำคัญกับสภาพแวดล้อมการทำงานอย่างชัดเจน โดยที่ทุกชั้นของระบบสามารถเข้าถึงได้
ความแตกต่างที่ชัดเจนกับโลกของ Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu ซึ่งทุกอย่างถูกแบ่งออกเป็นชิ้นเล็กๆ จนถึงขอบเขตที่นามธรรมตั้งอยู่บนนามธรรมและขับเคลื่อนด้วยไม้ค้ำ
อีกทั้งยังมีความเข้าใจถึงวิธีการของระบบด้วย .hpkg รวมแนวทางปฏิบัติที่ดีที่สุดของผู้จัดการแพ็คเกจแบบดั้งเดิม Snappy, Flatpak, AppImage หรือแม้แต่ btrfs และผสมผสานเข้ากับแนวทาง "ใช้งานได้" ของ Mac
มันเหมือนกับว่ามีบางอย่าง "เปลี่ยน" ในหัวของฉัน และฉันก็เข้าใจว่าระบบเป็นอย่างไร .hpkg รู้วิธีที่จะม้วนตัวออกไปเพียงแค่มองเธอ แต่ไม่ใช่ฉัน แต่เป็นความสวยงามและความเรียบง่ายของระบบ สิ่งเหล่านี้ส่วนใหญ่ได้รับแรงบันดาลใจจากจิตวิญญาณของ Mac รุ่นดั้งเดิม
ใช่การท่องเว็บในเบราว์เซอร์อาจกระตุกและทำงานเหมือนหอยทากแอปพลิเคชันอาจขาด (ไม่มี Gtk, Electron - นักพัฒนาสรุปว่าพวกเขาทำงานได้ไม่ดีกับความซับซ้อน) วิดีโอและการเร่งความเร็ว 3 มิติอาจขาดหายไปโดยสิ้นเชิง แต่ฉันยังคง ชอบระบบนี้. ท้ายที่สุดแล้วสิ่งเหล่านี้สามารถแก้ไขได้และจะปรากฏไม่ช้าก็เร็ว มันเป็นเพียงเรื่องของเวลาและอาจจะตาแดงเล็กน้อย
ฉันไม่สามารถให้ความช่วยเหลือได้ แต่ฉันคิดว่ามันจะเริ่มตั้งแต่นี้เป็นต้นไป ปีแห่งไฮกุบนเดสก์ท็อป.
ปัญหาสุ่ม
อาจมีคำขออยู่แล้วหรือฉันควรเปิดมัน?
- BeScreenCapture ควรส่งออกเป็น GIF เช่น Peek ได้ ซึ่งสามารถทำได้โดยใช้ ffmpeg ซึ่งมีอยู่แล้วใน Haiku .
- ซอฟต์แวร์ภาพหน้าจอไม่สามารถจับภาพหน้าต่างโมดอล แต่จะจับภาพทั้งหน้าจอแทน
- คุณไม่สามารถครอบตัดภาพหน้าจอโดยใช้เครื่องมือครอบตัดของ WonderBrush แล้วบันทึกผลลัพธ์ลงในไฟล์
- ฉันไม่ชอบเคอร์เซอร์มือในไฮกุเป็นพิเศษ แต่ฉันคิดว่ามันเกี่ยวข้องกับความรู้สึกคิดถึงเรื่องอันอบอุ่น สิ่งนี้น่ารำคาญอย่างยิ่งเมื่อใช้เครื่องมือครอบตัดใน Krita เนื่องจากส่งผลให้การครอบตัดไม่ถูกต้อง (ดูภาพหน้าจอของกล่องโต้ตอบโมดอลในบทความนี้) เคอร์เซอร์เล็งจะยอดเยี่ยมมาก .
ลองด้วยตัวเอง! ท้ายที่สุดแล้ว โปรเจ็กต์ Haiku ได้จัดเตรียมอิมเมจสำหรับการบูทจาก DVD หรือ USB ที่สร้างขึ้น . หากต้องการติดตั้ง เพียงดาวน์โหลดอิมเมจแล้วเขียนลงในแฟลชไดรฟ์โดยใช้
คุณมีคำถามใดๆ? เราขอเชิญคุณเข้าร่วมการพูดภาษารัสเซีย .
ภาพรวมข้อผิดพลาด:
จาก การแปล: นี่เป็นบทความที่หกในซีรีส์เกี่ยวกับไฮกุ
รายการบทความ:
ที่มา: will.com