Իմ վեցերորդ օրը Հայկուի հետ. ռեսուրսների, սրբապատկերների և փաթեթների տակ

TL. DRHaiku-ն օպերացիոն համակարգ է, որը հատուկ նախագծված է համակարգիչների համար, ուստի այն ունի մի քանի հնարքներ, որոնք նրա աշխատասեղանի միջավայրը շատ ավելի լավն են դարձնում, քան մյուսները: Բայց ինչպես է դա աշխատում:

Վերջերս Ես հայտնաբերեցի Հայկուն՝ անսպասելիորեն լավ համակարգ։ Ես դեռ զարմացած եմ, թե որքան սահուն է այն աշխատում, հատկապես Linux աշխատասեղանի միջավայրերի համեմատ: Այսօր ես կնայեմ գլխարկի տակ: Երբ անհրաժեշտ է խորը հասկանալու համար, ես համեմատություններ կանեմ բնօրինակ Macintosh, Mac OS X և Linux աշխատասեղանի միջավայրերի հետ (XDG ստանդարտ freedesktop.org-ից):

Ռեսուրսներ ELF ֆայլերում

Երեկ ես իմացա, որ IconOMatic-ը կարող է պահպանել պատկերակները rdef ռեսուրսներում ELF գործարկվող սարքերում: Այսօր ես ուզում եմ տեսնել, թե ինչպես է այն իրականում աշխատում:

Ռեսուրսներ. Մեջբերում - ից Բրյուս Հորն, Macintosh Finder-ի բնօրինակ հեղինակը և Macintosh Resource Manager-ի «հայրը».

Ինձ անհանգստացնում է ավանդական կոդավորման կոշտ բնույթը: Ինձ համար կոդով սառեցված հավելվածի գաղափարը, առանց որևէ բան դինամիկ փոխելու հնարավորության, ամենադաժան վայրենությունն է: Այն պետք է հնարավոր լինի հնարավորինս շատ փոխել գործարկման ժամանակ: Իհարկե, հավելվածի կոդը ինքնին հնարավոր չէ փոխել, բայց անշուշտ ինչ-որ բան կարելի է փոխել առանց ծածկագիրը նորից կազմելու:

Բնօրինակ Macintosh-ում նրանք այս ֆայլերը դարձրեցին «տվյալների բաժին» և «ռեսուրսների բաժին», ինչը աներևակայելիորեն հեշտացրեց իրերի պահպանումը, ինչպիսիք են պատկերակները, թարգմանությունները և այլն: գործարկվող ֆայլերում:

Mac-ում սա օգտագործվում է Վերափոխել, գրաֆիկական ծրագիր՝ անսպասելիորեն խմբագրելու ռեսուրսները։

Կրկին խմբագրել բնօրինակ Macintosh-ում

Արդյունքում հնարավոր եղավ խմբագրել սրբապատկերներ, ցանկի տարրեր, թարգմանություններ և այլն։ բավական հեշտ է, բայց նրանք դեռ «ճանապարհորդում» են հավելվածներով:
Ամեն դեպքում, այս մոտեցումը մեծ թերություն ուներ՝ այն աշխատում էր միայն Apple ֆայլային համակարգերի վրա, ինչը պատճառներից մեկն էր, որ Apple-ը հրաժարվեց «ռեսուրսների բաժնից»՝ Mac OS X տեղափոխվելիս։
Mac OS X-ում Apple-ը ցանկանում էր ֆայլային համակարգից անկախ լուծում, ուստի նրանք ընդունեցին փաթեթների հայեցակարգը (NeXT-ից), դիրեկտորիաներ, որոնք ֆայլերի կառավարչի կողմից դիտվում են որպես «անթափանց օբյեկտներ», ինչպես ֆայլերը, այլ ոչ թե տեղեկատուները: Ձևաչափով հավելվածով ցանկացած փաթեթ .app ունի, ի թիվս այլ բաների, ֆայլ Info.plist (Apple-ի JSON-ի կամ YAML-ի մի տեսակ համարժեքով), որը պարունակում է հավելվածի մետատվյալներ:

Mac OS X հավելվածի փաթեթից Info.plist ֆայլի բանալիներ:

Ռեսուրսները, ինչպիսիք են պատկերակները, UI ֆայլերը և այլն, պահվում են փաթեթում որպես ֆայլեր: Հայեցակարգը իրականում վերադառնում էր իր արմատներին NeXT-ում:

Mathematica.app-ը NeXTSTEP 1.0-ում 1989 թ.-ին. հայտնվում է որպես տերմինալի ֆայլերի գրացուցակ, բայց որպես մեկ օբյեկտ գրաֆիկական ֆայլերի կառավարիչում:

Վերադառնանք BeOS-ին, այն հասկացություններին, որոնց վրա հիմնված է Հայկուն։ Նրա մշակողները, PEF-ից (PowerPC) ELF (x86) անցնելիս (նույնը, ինչ օգտագործվում է Linux-ում), որոշեցին ELF ֆայլերի վերջում ավելացնել ռեսուրսների բաժինը։ Այն չէր օգտագործում իր սեփական ELF բաժինը, այն պարզապես կցվեց ELF ֆայլի վերջում: Ծրագրի արդյունքում strip իսկ մյուսները բինուտիլներից, այս մասին չգիտակցելով, պարզապես կտրեցին այն: Հետևաբար, BeOS-ում ELF ֆայլին ռեսուրսներ ավելացնելիս ավելի լավ է այն չշահարկել Linux գործիքներով:

Հիմա ի՞նչ է կատարվում Հայկուի հետ։ Հիմնականում քիչ թե շատ նույնը։

Տեսականորեն հնարավոր կլիներ ռեսուրսներ տեղադրել ELF-ի ցանկալի հատվածում: Ըստ irc.freenode.net-ի #haiku ալիքի մշակողների.

ELF-ի դեպքում բաժինն ավելի իմաստալից կլիներ... միակ պատճառը, որ մենք այդպես չենք անում, այն է, որ դա այն է, ինչ մենք արել ենք BeOS-ում»:
Եվ հիմա սա փոխելու իմաստ չկա։

Ռեսուրսների կառավարում

Ռեսուրսները գրված են կառուցվածքային «ռեսուրսների» ձևաչափով. ըստ էության, ռեսուրսների ցանկը չափերով և այնուհետև դրանց բովանդակությամբ: Ես հիշեցի ar ձևաչափով.
Ինչպե՞ս ստուգել ռեսուրսները Հայկուում: Կա՞ ResEdit-ի նման մի բան:
Ըստ փաստաթղթավորում:

Հավելվածի փաթեթում նախատեսված ռեսուրսները դիտելու համար կարող եք գործարկվող ֆայլը քաշել այնպիսի ծրագրի վրա, ինչպիսին է Ռեսուրսոր. Կարող եք նաև գնալ տերմինալ և գործարկել հրամանը listres имя_файла.

Resourcer-ը հասանելի է 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_signatureMIME հավելվածի տեսակը, ֆայլի բաց քարտեզագրման, գործարկման, IPC-ի և այլնի համար:
• app_name_catalog_entryՔանի որ հավելվածի անունը սովորաբար անգլերեն է, դուք կարող եք նշել այն վայրերը, որտեղ գտնվում են թարգմանված անունները, որպեսզի տարբեր լեզուների օգտատերերը ցանկության դեպքում տեսնեն թարգմանված հավելվածի անունը:
• app_version: Հենց այն, ինչ մտածում էիր
• app_flags: ցույց է տալիս registrar ինչպես մշակել դիմումը: Կարծում եմ՝ դրանում ավելին կա, քան երևում է: Օրինակ, կա B_SINGLE_LAUNCH, ինչը ստիպում է համակարգին գործարկել նոր հավելվածի գործընթաց ամեն անգամ, երբ օգտատերը դա պահանջում է (նույն սկզբունքն օգտագործվում է Linux-ի հավելվածների մեծ մասի համար): Ուտել B_MULTIPLE_LAUNCH, որի պատճառով գործընթացը շարունակվում է յուրաքանչյուր ֆայլ. Վերջապես կա B_EXCLUSIVE_LAUNCH, որը ստիպում է համակարգին միաժամանակ գործարկել միայն մեկ պրոցես, անկախ նրանից, թե որքան հաճախ են օգտվողներն այն գործարկում (օրինակ՝ այսպես է աշխատում Firefox-ը Linux-ում. նույն արդյունքը կարելի է հասնել Qt հավելվածներում՝ օգտագործելով ֆունկցիան։ QtSingleApplication) Դիմումներ հետ 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

Նայելով սրան՝ արդեն կարող ես զգալ, թե ինչ կտոր է դա։

Իհարկե, կա scalable, որը պարունակում է, ինչպես հասկանում եք, վեկտորային պատկերակներ: Ինչո՞ւ այդ դեպքում ուրիշ բան կա: Քանի որ փոքր չափերով վեկտորային գրաֆիկա նկարելու արդյունքը կարող է իդեալականից պակաս լինել: Ես կցանկանայի ունենալ տարբեր տարբերակներ, որոնք օպտիմիզացված են տարբեր չափերի համար: 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-ի համար հենց հիմա, ես այն հանում եմ 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-ում հնարավոր է անել այս «կարևոր» բաները, օրինակ. փոխարինելով նոր Slack պատկերակը նախորդով. 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 փաթեթների կախարդանքը

Ներկայումս (առավել հաճախ) փաթեթներն օգտագործվում են Haiku-ում ծրագրեր ստանալու համար .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...» գրացուցակները պարունակում են տեքստային ֆայլեր՝ ակտիվ փաթեթների անուններով, իսկ «գործարքի...» գրացուցակները պարունակում են փաթեթներ:

«Հին ակտիվ վիճակ», այսինքն. ցուցակը .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 Finder-ում։ Սա ինձ համար անկասկած է, բայց ես լսել եմ, որ որոշ նորեկներ կարող են չկարողանալ կարգավորել դա: Լռելյայնորեն, Apple-ը «առաջարկում է» համակարգային գրացուցակ /Applications (NeXT-ում այն ​​ցանցային էր, ինչպես նաև անհատական), բայց դուք կարող եք հեշտությամբ տեղադրել ձեր հավելվածները ֆայլերի սերվերի կամ ենթագրքում $HOME/Applications, եթե քեզ դուր է գալիս այդպես։

Հայկուի վրա, կրկնակի սեղմեք փաթեթի վրա, այնուհետև կտտացրեք «Տեղադրեք», ավելի հեշտ չէր լինի: Ինձ հետաքրքրում է, թե ինչ է տեղի ունենում, եթե փաթեթն ունի կախվածություններ, որոնք հասանելի են HaikuPorts-ում, բայց դեռ տեղադրված չեն: Linux-ում նրանք իսկապես չգիտեն, թե ինչ անել այս իրավիճակում, բայց լուծումն ակնհայտ է. հարցրեք օգտվողին, արդյոք նրանք պետք է ներբեռնեն և տեղադրեն կախվածությունները: Հենց այն, ինչ անում է Հայկուն։

Ես ձեռքով ներբեռնեցի «sanity» փաթեթը և սեղմեցի դրա վրա, փաթեթի կառավարիչը գիտի, թե որտեղից ստանալ իր կախվածությունները (ենթադրելով, որ պահեստներն արդեն գրանցված են համակարգում): Linux-ի յուրաքանչյուր բաշխում չի կարող դա անել:

Մեկ այլ միջոց է օգտագործել ֆայլերի կառավարիչ, պարզապես քաշել և թողնել .hpkg փաթեթ կամ ներս /Haiku/system/packages (համակարգի ամբողջ տեղադրման համար, լռելյայնորեն), կամ ներսում /Haiku/home/config/packages (անհատական ​​տեղադրման համար. անհասանելի է կրկնակի սեղմելիս - ինձ դեռ նյարդայնացնում է այս տեղում «config» բառը, որն ինձ համար այս դեպքում հոմանիշ է «կայանքներին»): Իսկ բազմաթիվ օգտատերերի հայեցակարգը դեռևս հասանելի չէ Haiku-ի համար (հավանաբար դա է պատճառը, որ այն այդքան պարզ է. չգիտեմ, միգուցե բազմակի օգտատերերի հնարավորությունները անհարկի բարդացնեն գործը աշխատասեղանի աշխատասեղանի միջավայրի համար):

Հայկուն այս անվանակարգում հաղթում է, քանի որ այն կարող է աշխատել ոչ միայն հավելվածների, այլ նաև համակարգային ծրագրերի հետ։

Փաթեթի հեռացում GUI-ից

Mac-ի վրա, դուք պետք է քաշեք հավելվածի պատկերակը դեպի աղբարկղ, և վերջ։ Հեշտությամբ!

Հայկուի վրաՆախ, դուք պետք է գտեք, թե որտեղ է գտնվում փաթեթը համակարգում, քանի որ հազվադեպ եք այն տեղադրում ճիշտ տեղում (համակարգն անում է ամեն ինչ): Սովորաբար դուք պետք է նայեք ներս /Haiku/system/packages (համակարգի լռելյայն տեղադրմամբ) կամ ներս /Haiku/home/config/packages (Ես նշեցի, որ «config»-ը սխալ բառ է): Այնուհետև հավելվածը պարզապես քաշվում է աղբարկղ, և վերջ:
Հեշտությամբ! Այնուամենայնիվ, ես դա չէի ասի։ Ահա թե ինչ է իրականում տեղի ունենում.

Սա այն է, ինչ տեղի է ունենում, եթե հավելվածը քաշում եք աղբարկղից /Haiku/system/packages

Պարզապես փորձեցի 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) փաթեթի ամրացման կետն է (հիշեք, թե ինչպես է այն հայտնվում ելքում 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-ը հաղթում է այս անվանակարգում փոքր տարբերությամբ:

Մեկնաբանություններ պրն. waddlesplash:

Ծրագիր գրել՝ հավելվածի բոլոր կախվածությունները որպես փաթեթների հավաքածու հավաքելու համար .hpkg Հայկուի ներքին աշխատանքին ծանոթ մեկի համար մոտ 15 րոպեն բավական է: Դրա համար աջակցություն ավելացնելն այնքան էլ դժվար չէ, եթե դրա իրական անհրաժեշտությունը կա: Բայց ինձ համար սա հազվադեպ իրավիճակ է։

Եկեք մեր շունչը պահենք մինչև այս շարքի հաջորդ հոդվածը:

Փաթեթների տեղափոխում առանձին վայր

Ինչպես ավելի վաղ գրել էի, ես ուզում եմ տեղադրել իմ փաթեթները .hpkg (լավ, կամ դրանց մի մասը) հատուկ տեղ, առանձնացված բեռնախցիկի ծավալի վրա սովորական տեղադրությունից (արմատային միջնորմ): Սովորական (ոչ այնքան տեսական) դեպքում դրա պատճառն այն է, որ ես անընդհատ սպառում եմ իմ (ներկառուցված) սկավառակների ազատ տարածքը, որքան էլ դրանք մեծ լինեն։ Եվ ես սովորաբար միացնում եմ արտաքին կրիչներ կամ ցանցային համօգտագործումներ, որտեղ գտնվում են իմ հավելվածները:

Mac-ի վրա Ես պարզապես տեղափոխում եմ փաթեթներ .app դեպի շարժական սկավառակ կամ ցանցային գրացուցակ Finder-ում, և վերջ: Ես դեռ կարող եմ կրկնակի սեղմել՝ հավելվածը բացելու համար, ինչպես սովորաբար անում էի բեռնման ծավալից: Պարզապես!

Հայկուի վրա, ինչպես ինձ ասացին, դրան կարելի է հասնել՝ տեղափոխելով իմ .hpkg փաթեթներ շարժական սկավառակի կամ ցանցի գրացուցակի մեջ, բայց այնուհետև դուք պետք է օգտագործեք որոշ չփաստաթղթավորված հրամաններ վահանակում, որպեսզի դրանք տեղադրեք համակարգում: Ես չգիտեմ, թե ինչպես դա անել՝ օգտագործելով միայն GUI-ը:

Mac-ը հաղթում է այս անվանակարգում:

Ըստ պրն. waddlesplash:

Սա նորմալ օգտագործման վրա հիմնված օպտիմալացում է: Եթե ​​պահանջարկ լինի մեկից ավելի օգտատերերի կողմից, մենք այն կիրականացնենք։ Ամեն դեպքում, կա երրորդ կողմի իրականացման հնարավորություն։

Այս մասին մենք կխոսենք հաջորդ հոդվածում:

Խոսելով ցանցային դիրեկտորիաների մասին, լավ կլինի (ես ենթադրում եմ, որ LAN կուսակցություններ) ունենանք պարզ, հայտնաբերելի, ցանցային հավելվածներ (ինչպես Zeroconf-ը), որոնք կարող են պատճենվել տեղական համակարգչին կամ գործարկել անմիջապես տեղական ցանցից: Իհարկե, մշակողները հնարավորություն ունեն հրաժարվելու միջոցով app_flags.

Վերջնական զեկույց hpkg համակարգի GUI-ի հետ ինտեգրման վերաբերյալ

Կարծում եմ, որ դա առաջին հերթին պայմանավորված է ինտեգրման հարաբերական նորությամբ .hpkg GUI-ն դեռ շատ բան է թողնում: Ամեն դեպքում, կան մի քանի բաներ, որոնք կարող են բարելավվել UX-ի առումով...

Եվս մեկ բան. Kernel Debug Land

Հիանալի կլինի, օրինակ, միջուկի խուճապի ժամանակ հրամաններ մուտքագրել syslog | grep usb. Դե, Հայկուի վրա դա հնարավոր է Kernel Debug Land-ի շնորհիվ։ Ինչպե՞ս կարող եք տեսնել այս կախարդանքը գործողության մեջ, եթե ամեն ինչ աշխատում է այնպես, ինչպես պետք է առանց միջուկի խուճապի մեջ ընկնելու: Հեշտ՝ սեղմելով Alt+PrintScn+D (Վրիպազերծում մնեմոնիկ): Ես անմիջապես հիշում եմ Ծրագրավորողի բանալի, որը թույլ է տվել Macintosh-ի սկզբնական մշակողներին մուտք գործել վրիպազերծիչ (եթե, իհարկե, մեկը տեղադրված է):

Ամփոփում

Ես սկսում եմ հասկանալ, որ Haiku համակարգի բարդությունը գալիս է նրանից, որ աշխատանքն իրականացվում է մեկ փոքր թիմի կողմից՝ հստակ կենտրոնանալով աշխատանքային միջավայրի վրա՝ հասանելի համակարգի բոլոր շերտերով:
Կտրուկ հակադրություն Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu-ի աշխարհի հետ, որտեղ ամեն ինչ այնքան փոքր մասերի է բաժանված, որ աբստրակցիան նստում է աբստրակցիայի վրա և քշում հենակներով:
Կար նաև հասկացողություն, թե ինչպես է համակարգը .hpkg համատեղում է ավանդական փաթեթների կառավարիչների՝ Snappy, Flatpak, AppImage, նույնիսկ btrfs լավագույն փորձը և միախառնում դրանք Mac-ի «պարզապես աշխատում» մոտեցման հետ:

Կարծես գլխումս ինչ-որ բան «փոխվեց», և ես հասկացա, թե ինչպես է համակարգը .hpkg գիտի, թե ինչպես գլորվել հեռու, պարզապես նայելով նրան: Բայց դա ես չեմ, այլ համակարգի գեղեցկությունն ու պարզությունը: Դրա մեծ մասը ոգեշնչված է բնօրինակ Mac-ի ոգով:

Այո, բրաուզերում զննարկումը կարող է անկայուն լինել և աշխատել խխունջի պես, հավելվածները կարող են բացակայել (ոչ Gtk, Electron - մշակողները եզրակացրեցին, որ դրանք լավ չեն համապատասխանում բարդությանը), տեսանյութը և 3d արագացումը կարող են իսպառ բացակայել, բայց ես դեռ դուր է գալիս այս համակարգը: Չէ՞ որ այս բաները կարելի է ուղղել, և դրանք վաղ թե ուշ կհայտնվեն։ Դա միայն ժամանակի հարց է, և գուցե մի փոքր կարմրել աչքը:

Ես չեմ կարող օգնություն առաջարկել, բայց կարծում եմ, որ այսուհետ կսկսվի Հայկուի տարին աշխատասեղանին.

Պատահական խնդիրներ

Միգուցե արդեն հարցումներ կան, թե՞ բացեմ։

• BeScreenCapture-ը պետք է կարողանա արտահանել GIF, ինչպես Peek-ը: Դա կարելի է անել՝ օգտագործելով ffmpeg, որն արդեն հասանելի է Haiku-ի համար: Դիմում.
• Սքրինշոթի ծրագրակազմը չի կարողանում մոդալ պատուհան նկարել, փոխարենը գրավում է ամբողջ էկրանը
• Դուք չեք կարող կտրել սքրինշոթները՝ օգտագործելով WonderBrush-ի կտրման գործիքը, այնուհետև արդյունքը պահել ֆայլում
• Ես առանձնապես չեմ սիրում ձեռքի կուրսորը Հայկուում, բայց կարծում եմ, որ դա կապված է ջերմ կարոտախտի հետ: Սա հատկապես նյարդայնացնում է Krita-ում մշակման գործիքն օգտագործելիս, քանի որ դա հանգեցնում է ոչ ճշգրիտ կտրման (տես մոդալ երկխոսությունների սքրինշոթները այս հոդվածում): Խաչաձեւ կուրսորը հրաշալի կլիներ: Դիմում.

Փորձեք ինքներդ: Ի վերջո, Haiku նախագիծը տրամադրում է պատկերներ DVD-ից կամ USB-ից բեռնելու համար՝ ստեղծված օրական. Տեղադրելու համար պարզապես ներբեռնեք պատկերը և գրեք այն ֆլեշ կրիչում՝ օգտագործելով Etcher

Հարցեր ունե՞ք։ Հրավիրում ենք ռուսախոս հեռագրային ալիք.

Սխալի ակնարկ. Ինչպես կրակել ձեր ոտքին C և C++-ով. Haiku OS բաղադրատոմսերի հավաքածու

- Ից հեղինակ թարգմանություն. սա Հայկուի մասին մատենաշարի վեցերորդ հոդվածն է։

Հոդվածների ցանկ. Առաջին Երկրորդ Երրորդը Չորրորդ Հինգերորդ

Source: www.habr.com