ჩემი მეექვსე დღე ჰაიკუსთან ერთად: რესურსების, ხატებისა და პაკეტების ქვეშ

TL; DRპასუხი: Haiku არის ოპერაციული სისტემა, რომელიც სპეციალურად შექმნილია კომპიუტერებისთვის, ამიტომ მას აქვს რამდენიმე ხრიკი, რათა ის ბევრად უკეთესი დესკტოპის გარემო იყოს, ვიდრე სხვები. მაგრამ როგორ მუშაობს?

ცოტა ხნის წინ მე აღმოვაჩინე ჰაიკუ, მოულოდნელად კარგი სისტემა. მე ჯერ კიდევ მიკვირს, რამდენად შეუფერხებლად მუშაობს ის, განსაკუთრებით მაშინ, როდესაც შევადარებთ Linux დესკტოპის გარემოს. დღეს მე გადავხედავ კაპოტის ქვეშ. სადაც საჭიროა სიღრმისეული გაგებისთვის, მე გავაკეთებ შედარებებს ორიგინალურ Macintosh, Mac OS X და Linux დესკტოპებთან (XDG სტანდარტი freedesktop.org-დან).

რესურსები ELF ფაილებში

გუშინ გავიგე, რომ IconOMatic-ს შეუძლია შეინახოს ხატები rdef რესურსებში ELF შესრულებად ფაილებში. დღეს მინდა ვნახო, როგორ მუშაობს სინამდვილეში.

რესურსები? Quote საწყისი ბრიუს ჰორნიMacintosh Finder-ის ორიგინალური ავტორი და Macintosh რესურს მენეჯერის მამა:

მე მაწუხებს ტრადიციული კოდირების ხისტი ბუნება. ჩემთვის, კოდით გაყინული აპლიკაციის იდეა, არაფრის დინამიურად შეცვლის შესაძლებლობის გარეშე, ყველაზე ველურია. შესაძლებელი უნდა იყოს რაც შეიძლება მეტი შეცვლა გაშვების დროს. რა თქმა უნდა, თავად აპლიკაციის კოდი არ შეიცვლება, მაგრამ შესაძლებელია თუ არა რაიმეს შეცვლა კოდის ხელახალი კომპილაციის გარეშე?

ორიგინალურმა მაკინტოშმა ამ ფაილებს ჰქონოდა "მონაცემთა განყოფილება" და "რესურსების განყოფილება", რამაც გააადვილა ისეთი ნივთების შენახვა, როგორიცაა ხატები, თარგმანები და ა.შ. შესრულებად ფაილებში.

Mac-ზე ეს ეხება ხელახალი რედაქტირება, გრაფიკული პროგრამა - უეცრად - რესურსების რედაქტირებისთვის.

ხელახალი რედაქტირება ორიგინალ Macintosh-ზე

შედეგად შესაძლებელი გახდა ხატების, მენიუს ელემენტების, თარგმანების და ა.შ. საკმაოდ მარტივია, მაგრამ ისინი მაინც "მოგზაურობენ" აპლიკაციებით.
ნებისმიერ შემთხვევაში, ამ მიდგომას დიდი ნაკლი ჰქონდა: ის მხოლოდ Apple-ის ფაილურ სისტემებზე მუშაობდა, რაც იყო ერთ-ერთი მიზეზი იმისა, რომ Apple-მა მიატოვა „რესურსების განყოფილება“ Mac OS X-ზე გადასვლისას.
Mac OS X-ზე Apple-ს სურდა ფაილური სისტემისგან დამოუკიდებელი გადაწყვეტა, ამიტომ მათ მიიღეს პაკეტების კონცეფცია (NeXT-დან), დირექტორიები, რომლებიც განიხილება როგორც "გაუმჭვირვალე ობიექტები" ფაილების მენეჯერის მიერ, როგორიცაა ფაილები და არა დირექტორიები. ნებისმიერი პაკეტი აპლიკაციით ფორმატში .app აქვს, სხვა საკითხებთან ერთად, ფაილი Info.plist (Apple-ის JSON-ის ან YAML-ის ზოგიერთ ანალოგში), რომელიც შეიცავს აპლიკაციის მეტამონაცემებს.

Info.plist ფაილის გასაღებები Mac OS X აპლიკაციის პაკეტიდან.

რესურსები, როგორიცაა ხატები, UI ფაილები და სხვა, ინახება პაკეტში ფაილების სახით. კონცეფცია რეალურად დაუბრუნდა თავის ფესვებს NeXT-ში.

Mathematica.app NeXTSTEP 1.0-ზე 1989 წელს: ჩნდება როგორც ფაილის დირექტორია ტერმინალში, მაგრამ როგორც ერთი ობიექტი გრაფიკული ფაილების მენეჯერში.

დავუბრუნდეთ BeOS-ს, რომელზეც დაფუძნებულია ჰაიკუ. მისმა დეველოპერებმა, როდესაც გადავიდნენ PEF-დან (PowerPC) ELF-ზე (x86) (იგივე გამოიყენება Linux-ზე), გადაწყვიტეს დაემატებინათ რესურსის განყოფილება ELF ფაილების ბოლოს. ეს არ იყენებდა საკუთარ შესაბამის ELF განყოფილებას, ის უბრალოდ დაემატა ELF ფაილის ბოლოს. პროგრამის შედეგად strip და სხვებმა ბინუტილში, რომლებმაც ამის შესახებ არ იციან, უბრალოდ გათიშა. ამიტომ, BeOS-ზე ELF ფაილში რესურსების დამატების შემდეგ, უმჯობესია არ იმუშაოთ მასთან Linux ინსტრუმენტებით.

და რა ხდება ახლა ჰაიკუსთან? ძირითადად, მეტ-ნაკლებად იგივე.

თეორიულად, შესაძლებელი იქნებოდა რესურსების განთავსება ELF-ის სასურველ განყოფილებაში. დეველოპერების თქმით, #haiku არხზე irc.freenode.net-ზე:

ELF-ით, განყოფილება უფრო აზრიანი იქნებოდა... ერთადერთი მიზეზი, რის გამოც ამას არ ვაკეთებთ, არის ის, რომ ეს გავაკეთეთ BeOS-ში."
და ის ახლა არ უნდა შეიცვალოს.

Რესურსების მართვა

რესურსები იწერება სტრუქტურირებული „რესურსების“ ფორმატში: ფაქტობრივად, ეს არის რესურსების ჩამონათვალი ზომებით და შემდეგ მათი შინაარსით. გაახსენდა ar ფორმატში.
როგორ შევამოწმოთ რესურსები ჰაიკუში? არის რამე 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 აპლიკაციებში ფუნქციის გამოყენებით. QtSingleApplication). აპლიკაციები B_EXCLUSIVE_LAUNCH ეცნობებათ, როდესაც მომხმარებელი შეეცდება მათ ხელახლა გაშვებას: მაგალითად, ისინი იღებენ ფაილის გზას, რომლის გახსნაც მომხმარებელს სურს მათთან ერთად.
• vector_icon: აპლიკაციის ვექტორის ხატულა (BeOS-ს არ ჰქონდა ვექტორული ხატები, აპლიკაციების უმეტესობას ჰქონდა ორი bitmap ხატულა მათ შესრულებად ფაილებში).

რა თქმა უნდა, შეგიძლიათ დაამატოთ რესურსები ნებისმიერი სასურველი 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 თავის მაგიას შეიძლება ბლოგზე ლეა განსონი

აპლიკაციაში ხატის დამატება

ახლა მე შემიძლია დავამატო ხატულა შექმნილ პაკეტს ბოლოჯერ, მიღებული ყველა ინფორმაციის გათვალისწინებით.
კარგი, რადგან არ მსურს ახლავე დავხატო ჩემი საკუთარი ხატულა ჩემი „Hello World“ 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 ხატის შეცვლა წინათ. ჰაიკუზე, იფიქრეთ რესურსზე (ფაილში), როგორც ორიგინალურ ხატულაზე, რომელიც მოყვება აპლიკაციას, და ატრიბუტი (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-ზე დაფუძნებულ სისტემაზე, ასობით ათასიდან მილიონობით ცალკეული ფაილი ადვილად შეიძლება არსებობდეს. ზედმეტია იმის თქმა, რომ ეს არის მყიფე და ნელი, მაგალითად, სისტემის თავდაპირველი ინსტალაციის დროს, ჩვეულებრივი პაკეტების ინსტალაციის, განახლების და წაშლისას და ჩატვირთვის მოცულობის (root partition) სხვა მედიაზე კოპირებისას.

მე ვმუშაობ 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"

ის შეიცავს ძალიან მინიმალისტურ ოპერაციულ სისტემას, ბირთვის ჩათვლით. გინდ დაიჯერეთ თუ არა, თვით ბირთვიც კი არ არის ამოღებული ჩატვირთვის ტომიდან (root partition), მაგრამ ლამაზად არის ჩატვირთული თავის ადგილზე პაკეტიდან. .hpkg. Ვაუ! ადრე აღვნიშნე, რომ, ჩემი აზრით, ჰაიკუს საერთო დახვეწილობისა და თანმიმდევრულობის ნაწილი გამომდინარეობს იქიდან, რომ მთელი სისტემა, ბირთვიდან და მომხმარებლის სივრციდან, პაკეტის მენეჯმენტამდე და დესკტოპის ინფრასტრუქტურამდე, შემუშავებულია ერთობლივად ერთი გუნდის მიერ. წარმოიდგინეთ რამდენი განსხვავებული ჯგუფი და გუნდი დასჭირდება Linux-ზე მსგავსი რამის გასაშვებად. [წარმომიდგენია PuppyLinux-ის პროექტი, - დაახლ. მთარგმნელი]. მაშინ წარმოიდგინეთ რამდენი დრო დასჭირდება ამ მიდგომის დანერგვას დისტრიბუციებში. ამბობენ: აიღე მარტივი დავალება, გაყავი სხვადასხვა შემსრულებლებს შორის და ისე გართულდება, რომ აღარ მოგვარდებაო. ამ შემთხვევაში ჰაიკუმ თვალები გამხილა. მე ვფიქრობ, რომ ეს არის ზუსტად ის, რაც ახლა ხდება Linux-ზე (Linux ამ შემთხვევაში არის კოლექტიური ტერმინი Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu სტეკისთვის).

სისტემის დაბრუნება 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-ს ყველა ინსტალაციის ნაწილი (მაგალითად, მაქვს ფიზიკურად იზოლირებული მანქანა ინტერნეტთან წვდომის გარეშე.)
• მინდა გადავიტანო ჩემი პაკეტები (ისე, ნაწილი) ცალკე სხვა ადგილას, ჩატვირთვის ტომისგან (root partition) განცალკევებით (რადგან, მაგალითად, მასზე საკმარისი ადგილი არ მაქვს).

ეს უნდა მოიცავდეს ჩემი ყოველდღიური საქმიანობიდან ძირითად შემთხვევებს. აბა, დავიწყოთ.

პაკეტის შინაარსის შემოწმება

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", რომელიც ჩემთვის ამ შემთხვევაში "პარამეტრების" სინონიმია). და მრავალი მომხმარებლის კონცეფცია ჯერ კიდევ არ არის ხელმისაწვდომი ჰაიკუსთვის (შესაძლოა ამიტომაა ასე მარტივი - არ ვიცი, შესაძლოა მრავალმომხმარებლის შესაძლებლობებმა ზედმეტად გაართულოს საქმე დესკტოპის გარემოსთვის).

ამ კატეგორიაში ჰაიკუ იმარჯვებს, რადგან მას შეუძლია მუშაობა არა მხოლოდ აპლიკაციებთან, არამედ სისტემურ პროგრამებთან.

პაკეტის ამოღება GUI-დან

Mac-ზე, თქვენ უნდა გადაათრიოთ აპლიკაციის ხატულა ნაგავში და ეს არის ის. მარტივად!

ჰაიკუზე, პირველ რიგში, თქვენ უნდა იპოვოთ სისტემაში სად მდებარეობს პაკეტი, რადგან იშვიათად აყენებთ მას სწორ ადგილას (სისტემა ყველაფერს აკეთებს). როგორც წესი, თქვენ უნდა მოძებნოთ /Haiku/system/packages (სისტემური ნაგულისხმევი ინსტალაციისას), ან in /Haiku/home/config/packages (მე აღვნიშნე, რომ "config" არასწორი სახელია?). შემდეგ აპლიკაცია უბრალოდ გადაიტანება ნაგავში და ეს არის ის.
მარტივად! თუმცა, მე ასე არ ვიტყოდი. აი, რა ხდება სინამდვილეში:

ეს არის ის, რაც ხდება, როდესაც აპს გადაიტანეთ ნაგავში /Haiku/system/packages

ახლახან ვცადე ჩემი გუშინდელი "Hello world" აპი QtQuickApp-ზე გადატანა სანაგვეში. არ მიცდია სისტემის დირექტორიას გადატანა, და რადგან ყველა პაკეტი დაინსტალირებულია სისტემის დირექტორიაში - შეუძლებელია პაკეტის ამოღება .hpkg ცვლილების გარეშე "მისი შინაარსი". ჩვეულებრივი მომხმარებელი შეშინდებოდა, დააჭერდა სტანდარტულად მინიჭებულ ღილაკს "გაუქმება".

განმარტავს ბატონი. ჭექა-ქუხილი:

ეს პოსტი 10 წელზე მეტია. სავარაუდოდ, ჩვენ უნდა დავაკონფიგურიროთ ისე, რომ გაფრთხილება გამოვიდეს მხოლოდ მაშინ, როდესაც თავად პაკეტი გადატანილია. ჩვეულებრივ მომხმარებლებს ამის გაკეთება მაინც არ სჭირდებათ.

კარგი, იქნებ ეს უნდა გააკეთოთ HaikuDepot-ის გამოყენებით? ორჯერ დააწკაპუნეთ პაკეტზე /Haiku/system/packages, ელოდება "წაშლა" ღილაკის გამოჩენას. არა, არის (მხოლოდ) "ინსტალაცია". დეინსტალაცია, სად ხარ?

გასართობად ვცადე მენახა, რა მოხდება, თუ უკვე დაინსტალირებულ პაკეტზე დავაწკაპუნებ "Install". გამოდის ასე:

ეს მოხდება, თუ თქვენ ცდილობთ დააინსტალიროთ უკვე დაინსტალირებული პაკეტი.

შემდეგ გამოჩნდება:

თუ წინა ფანჯარაში დააწკაპუნებთ "ცვლილებების გამოყენებას", ეს ასე გამოვა

მე ვვარაუდობ, რომ ეს არის პროგრამული შეცდომა, აპლიკაციის ბმული უკვე არსებობს. [ავტორმა ბმული არ მოგვაწოდა, - დაახლ. მთარგმნელი]

სწრაფი გამოსწორება: დაამატეთ ღილაკი "წაშლა", თუ პაკეტი უკვე შეყვანილია /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-ისა (მაგრამ ეს, სრული მართალი გითხრათ, მიკერძოებული აზრია). თუმცა, შეიძლება წარმოიდგინოთ, რომ შესწორების შემდეგ, მომხმარებლის გამოცდილება ჰაიკუზე უკეთესი იქნება, ვიდრე Mac-ზე.

შენიშვნა: თქვენ უნდა გაარკვიოთ რა არის "მოცულობა" "დანაყოფის" მიმართ. ეს ალბათ წააგავს "საქაღალდეს" და "დირექტორიას" ურთიერთობას: დირექტორიების უმეტესობა გამოჩნდება ფაილების მენეჯერის საქაღალდეებად, მაგრამ არა ყველა მათგანი (მაგ. პაკეტები, რომლებიც განიხილება როგორც ფაილები). ასეთი რამ ოფიციალურად ნერდს მაქცევს?

პაკეტის შინაარსის სხვა სისტემაში კოპირება

Mac-ზე, სულელურად ზიდავს ამანათი .app, და ვინაიდან დამოკიდებულებები პაკეტშია, ისინი ერთად მოძრაობენ.

ჰაიკუზე, აპლიკაციას ვათრევ, მაგრამ დამოკიდებულებები საერთოდ არ მუშავდება.

სწრაფი გამოსწორება: ამის ნაცვლად, შემოგვთავაზეთ გადაიტანოთ მთელი "`.hpkg" პაკეტი, დამოკიდებულებებთან ერთად, ასეთის არსებობის შემთხვევაში.

ამ კატეგორიაში Mac აშკარად იმარჯვებს. ყოველ შემთხვევაში ჩემთვის, მათი პარადიგმის მოყვარულისთვის. ჰაიკუ უნდა დაკოპირდეს .hpkg აპლიკაციის ნაცვლად, მაგრამ სისტემა არ მთავაზობს ამას ...

პაკეტის ჩამოტვირთვა მისი ყველა დამოკიდებულებით

ყველა მანქანა არ არის მუდმივად ონლაინ რეჟიმში. პირიქით, ზოგიერთ მანქანას (დიახ, მე გიყურებ, თანამედროვე Windows, Mac და Linux) ივიწყებს ამას. ჩემთვის მნიშვნელოვანია, რომ შემეძლოს ინტერნეტ კაფეში წასვლა, მაგალითად, პროგრამული უზრუნველყოფის ჩამოტვირთვა მოსახსნელ მედიაზე, ჩასვა ეს მედია ჩემს კომპიუტერში და დარწმუნებული ვიყო, რომ ყველაფერი იმუშავებს [რისკის ბიჭი, გააკეთე ეს Windows-ზე ... - დაახლ. . მთარგმნელი].

შედეგად, ჩვეულებრივზე ცოტა უფრო ხშირად, მე ჩვეულებრივ მთავრდება დაუკმაყოფილებელი დამოკიდებულებები Windows-სა და Linux-ზე.

Mac-ზე ეს არის, როგორც წესი, ერთი ფაილი, ყველაფერი რაც თქვენ გჭირდებათ არის ჩამოტვირთვა .dmg. ყველაზე ხშირად, მას არ აქვს სხვა დამოკიდებულებები, გარდა იმ დამოკიდებულებისა, რომლებიც გათვალისწინებულია თავად MacOS-ის მიერ ნაგულისხმევად. გამონაკლისი არის რთული აპლიკაციები, რომლებიც საჭიროებენ შესაბამის გაშვების გარემოს, როგორიცაა java.

ჰაიკუზე პაკეტის ჩამოტვირთვა .hpkg მაგალითად, ერთი და იგივე java აპლიკაცია შეიძლება არ იყოს საკმარისი, რადგან java შეიძლება იყოს ან არ იყოს სამიზნე მანქანაზე. არის თუ არა გზა, რომ გადმოწეროთ ყველა დამოკიდებულება მოცემული პაკეტისთვის .hpkgგარდა მათ, რომლებიც ნაგულისხმევად არის დაინსტალირებული ჰაიკუში და ამიტომ უნდა იყოს ყველა ჰაიკუ სისტემაზე?

ამ კატეგორიაში Mac იმარჯვებს მცირე სხვაობით.

კომენტარი გააკეთა mr. waddlesplash:

პროგრამის დაწერა აპლიკაციის ყველა დამოკიდებულების შესაგროვებლად, როგორც პაკეტების ნაკრები .hpkg ვინმესთვის, ვინც ჰაიკუს ინტერიერს იცნობს, დაახლოებით 15 წუთი საკმარისია. ამის მხარდაჭერის დამატება არც ისე რთულია, თუ ამის რეალური საჭიროება არსებობს. მაგრამ ჩემთვის ეს იშვიათია.

მოდით, სუნთქვა შევიკავოთ ამ სერიის მომდევნო სტატიამდე.

პაკეტების გადატანა ცალკე ადგილას

როგორც ადრე დავწერე, მსურს ჩემი პაკეტების განთავსება .hpkg (კარგად, ან მათი ნაწილი) სპეციალურ ადგილას, ჩატვირთვის მოცულობაზე (root partition) ჩვეულებრივი განლაგებისგან განცალკევებით. ჩვეულ (არც ისე თეორიულ) შემთხვევაში ამის მიზეზი არის ის, რომ ჩემს (ჩაშენებულ) დისკებს მუდმივად ეწურება თავისუფალი ადგილი, რაც არ უნდა დიდი იყოს. მე, როგორც წესი, გარე დისკების ან ქსელის გაზიარების რუქას ვაკეთებ, სადაც ჩემი აპლიკაციებია.

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-ის დეველოპერებს შევიდნენ გამართვის სისტემაში (თუ დაინსტალირებული იყო, რა თქმა უნდა).

დასკვნა

მე ვიწყებ იმის გაცნობიერებას, რომ ჰაიკუს სისტემის დახვეწილობა გამომდინარეობს იქიდან, რომ სამუშაოს ასრულებს ერთი პატარა გუნდი, რომელიც მკაფიოდ არის ორიენტირებული სამუშაო გარემოზე, სისტემის ყველა ფენაზე წვდომით.
მკვეთრი კონტრასტი 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-ის მსგავსად. ეს შეიძლება გაკეთდეს Haiku-სთვის უკვე ხელმისაწვდომი ffmpeg-ით. განაცხადის.
• სკრინშოტის ხელსაწყო ვერ იღებს მოდალური ფანჯრის სკრინშოტს, სამაგიეროდ, მთელ ეკრანს იღებს
• თქვენ არ შეგიძლიათ ამოიღოთ ეკრანის ანაბეჭდები WonderBrush-ის ამოჭრის ხელსაწყოთი და შემდეგ შეინახოთ შედეგი ფაილში
• განსაკუთრებით არ მომწონს ხელის კურსორი ჰაიკუში, მაგრამ ვფიქრობ, რომ მას აქვს თბილი ნოსტალგიური შეგრძნება. ეს განსაკუთრებით შემაშფოთებელია კრიტაში ჭრის ხელსაწყოს გამოყენებისას, რადგან ეს იწვევს არაზუსტ ჩამოჭრას (იხილეთ მოდალური დიალოგების ეკრანის ანაბეჭდები ამ სტატიაში). ჯვარედინი კურსორი კარგი იქნება. განაცხადის.

თავად სცადე! ყოველივე ამის შემდეგ, Haiku პროექტი უზრუნველყოფს სურათებს DVD ან USB-დან ჩატვირთვისთვის, გენერირებული ყოველდღიური. ინსტალაციისთვის, უბრალოდ გადმოწერეთ სურათი და ჩაწერეთ იგი USB ფლეშ დრაივზე გამოყენებით ეტჩერი

გაქვთ შეკითხვები? გეპატიჟებით რუსულენოვანზე დეპეშა არხი.

შეცდომის მიმოხილვა: როგორ გავისროლოთ ფეხში C და C++-ში. Haiku OS რეცეპტების კოლექცია

მდებარეობა ავტორი თარგმანი: ეს არის მეექვსე სტატია ჰაიკუს სერიიდან.

სტატიების სია: პირველი მეორე მესამე მეოთხე მეხუთე

წყარო: www.habr.com