რაღაც სხვა: ჰაიკუს აპლიკაციების ნაკრები?

TL; DR: შეუძლია თუ არა ჰაიკუს მიიღოს შესაბამისი მხარდაჭერა აპლიკაციის პაკეტებისთვის, როგორიცაა აპლიკაციების დირექტორიები (როგორიცაა .app Mac-ზე) და/ან აპლიკაციის სურათები (Linux AppImage)? მე ვფიქრობ, რომ ეს იქნება ღირსეული დამატება, რომლის სწორად დანერგვა უფრო ადვილია, ვიდრე სხვა სისტემები, რადგან ინფრასტრუქტურის უმეტესობა უკვე არსებობს.

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

სრული გაგებისთვის, მე ვარ AppImage-ის შემქმნელი და ავტორი, Linux აპლიკაციის განაწილების ფორმატი, რომელიც მიზნად ისახავს Mac-ის სიმარტივეს და აძლევს სრულ კონტროლს აპლიკაციის ავტორებსა და საბოლოო მომხმარებლებს (თუ გსურთ მეტი იცოდეთ, იხ. ვიკი и დოკუმენტაცია).

რა მოხდება, თუ შევქმნით AppImage-ს ჰაიკუსთვის?

მოდით, ცოტა, წმინდა თეორიულად დავფიქრდეთ: რა უნდა გაკეთდეს იმისათვის, რომ მივიღოთ AppImageან რამე მსგავსი ჰაიკუზე? არ არის საჭირო ახლა რაღაცის შექმნა, რადგან სისტემა, რომელიც უკვე არსებობს ჰაიკუში, საოცრად მუშაობს, მაგრამ წარმოსახვითი ექსპერიმენტი კარგი იქნებოდა. ის ასევე აჩვენებს ჰაიკუს დახვეწილობას Linux-ის დესკტოპ გარემოსთან შედარებით, სადაც ასეთი რამ საშინლად რთულია (მაქვს ამის თქმის უფლება: 10 წელია ვცდილობ გამართვას).

Macintosh System 1-ზე, თითოეული აპლიკაცია იყო ცალკე ფაილი "მართული" Finder-ში. AppImage-ის გამოყენებით მე ვცდილობ ხელახლა შევქმნა მომხმარებლის იგივე გამოცდილება Linux-ზე.

პირველ რიგში, რა არის AppImage? ეს არის მესამე მხარის აპლიკაციების გამოშვების სისტემა (მაგალითად, ულტიმაიკერი კურა), საშუალებას აძლევს აპლიკაციების გამოშვებას, როცა და როგორ უნდათ: არ არის საჭირო იცოდეთ სხვადასხვა დისტრიბუციის სპეციფიკა, შექმნათ პოლიტიკა ან შექმნათ ინფრასტრუქტურა, არ არის საჭირო დამხმარე მხარდაჭერა და ისინი არ ეუბნებიან მომხმარებლებს რა (არა) შეუძლიათ დააინსტალირონ. მათ კომპიუტერებზე. AppImage უნდა გავიგოთ, როგორც Mac პაკეტის მსგავსი ფორმატში .app დისკის გამოსახულების შიგნით .dmg. მთავარი განსხვავება ისაა, რომ აპლიკაციები არ კოპირდება, მაგრამ სამუდამოდ რჩება AppImage-ში, ისევე როგორც Haiku პაკეტები. .hpkg დამონტაჟებულია და არასოდეს დაინსტალირებულია ჩვეულებრივი გაგებით.

არსებობის 10 წელზე მეტი ხნის განმავლობაში AppImage-მა მოიპოვა გარკვეული მიმზიდველობა და პოპულარობა: თავად ლინუს ტორვალდმა მას საჯაროდ დაუჭირა მხარი, ხოლო საერთო პროექტებმა (მაგალითად, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) მიიღეს ის, როგორც მთავარი გზა. უწყვეტი ან ღამის ნაგებობების გასავრცელებლად, დაინსტალირებული ან დეინსტალირებული მომხმარებლის აპლიკაციებში ჩარევის გარეშე. თუმცა, Linux-ის დესკტოპის გარემო და დისტრიბუციები ყველაზე ხშირად მაინც ეკიდებიან ტრადიციულ, ცენტრალიზებულ შემანარჩუნებელზე დაფუძნებულ განაწილების მოდელს და/ან ხელს უწყობენ საკუთარ საწარმოს ბიზნესს და/ან საინჟინრო პროგრამებს. ბინაპაკეტი (RedHat, Fedora, GNOME) და გართული (კანონიკური, Ubuntu). მოდის სასაცილოდ.

როგორ მუშაობს ეს ყველაფერი

• თითოეული AppImage შეიცავს 2 ნაწილს: მცირე ორმაგი დაწკაპუნებით ELF (ე.წ. runtime.c), რასაც მოჰყვება ფაილური სისტემის სურათი SquashFS.

• SquashFS ფაილური სისტემა შეიცავს აპლიკაციის დატვირთვას და ყველაფერს, რაც საჭიროა მისი გასაშვებად, რაც არ შეიძლება ჩაითვალოს ნაგულისხმევი ინსტალაციის ნაწილად ყველა საკმაოდ ბოლოდროინდელი სამიზნე სისტემისთვის (Linux დისტრიბუცია). ის ასევე შეიცავს მეტამონაცემებს, როგორიცაა განაცხადის სახელი, ხატები, MIME ტიპები და ა.შ.

• მომხმარებლის მიერ გაშვებისას, Runtime იყენებს FUSE-ს და squashfuse-ს ფაილური სისტემის დასამონტაჟებლად, შემდეგ კი ამუშავებს შეყვანის წერტილს (ანუ AppRun) დამონტაჟებული AppImage-ში.
  პროცესის დასრულების შემდეგ ფაილური სისტემა იხსნება.

ყველაფერი მარტივი ჩანს.

და ეს ყველაფერი ართულებს ყველაფერს:

• Linux-ის დისტრიბუციის ასეთი მრავალფეროვნებით, ვერაფერს „სწორ გონებაში“ არ შეიძლება ეწოდოს „ნაგულისხმევი ინსტალაციის ნაწილი ყოველი ახალი სამიზნე სისტემისთვის“. ჩვენ ვმუშაობთ ამ საკითხის გარშემო სამშენებლო გზით გამორიცხვის სია, რომელიც საშუალებას გაძლევთ განსაზღვროთ, რა იქნება შეფუთული AppImage-ში და რისი გადაღება საჭირო იქნება სხვაგან. ამავდროულად, ხანდახან გვენატრება, მიუხედავად იმისა, რომ, ზოგადად, ყველაფერი მშვენივრად მუშაობს. ამ მიზეზით, ჩვენ გირჩევთ, რომ პაკეტის შემქმნელებმა შეამოწმონ AppImages ყველა სამიზნე სისტემაზე (დისტრიბუცია).
• აპლიკაციის დატვირთვა უნდა იყოს გადატანილი ფაილურ სისტემაში. სამწუხაროდ, ბევრ აპლიკაციას აქვს მყარი კოდირებული აბსოლუტური გზები, მაგალითად, რესურსებისკენ /usr/share. ეს როგორმე უნდა გამოსწორდეს. გარდა ამისა, თქვენ უნდა გაიტანოთ ექსპორტი LD_LIBRARY_PATH, ან გაასწორონ rpath რათა ჩამტვირთველმა შეძლოს დაკავშირებული ბიბლიოთეკების პოვნა. პირველ მეთოდს აქვს თავისი ნაკლოვანებები (რომლებიც რთული გზებით არის გადალახული), მეორე კი უბრალოდ შრომატევადი.
• ყველაზე დიდი UX პრობლემა მომხმარებლებისთვის არის ის შესრულებადი ბიტის დაყენება AppImage ფაილი ჩამოტვირთვის შემდეგ. დაიჯერეთ თუ არა, ეს ზოგიერთისთვის ნამდვილი ბარიერია. შესრულებადობის ბიტის დაყენების აუცილებლობა რთულია გამოცდილი მომხმარებლებისთვისაც კი. გამოსავალად, ჩვენ შემოგთავაზეთ მცირე სერვისის დაყენება, რომელიც მონიტორინგს უწევს AppImage ფაილებს და ადგენს მათ შესრულებადობის ბიტს. მისი სუფთა სახით, ეს არ არის საუკეთესო გამოსავალი, რადგან ის არ გამოდგება ყუთიდან. Linux-ის დისტრიბუციები არ გთავაზობთ ამ სერვისს, შესაბამისად, მომხმარებლებს ცუდი გამოცდილება აქვთ.
• Linux-ის მომხმარებლები მოელიან, რომ ახალ აპლიკაციას ექნება ხატულა გაშვების მენიუში. სისტემას ვერ ეტყვით: „აი, არის ახალი აპლიკაცია, ვიმუშაოთ“. ამის ნაცვლად, XDG სპეციფიკაციის მიხედვით, თქვენ უნდა დააკოპიროთ ფაილი .desktop სწორ ადგილას /usr სისტემის მასშტაბით ინსტალაციისთვის, ან შიგნით $HOME ინდივიდუალურისთვის. გარკვეული ზომის ხატები, XDG სპეციფიკაციის მიხედვით, უნდა განთავსდეს გარკვეულ ადგილებში usr ან $HOMEდა შემდეგ გაუშვით ბრძანებები სამუშაო გარემოში, რათა განაახლოთ ხატულას ქეში, ან იმედი გქონდეთ, რომ სამუშაო გარემოს მენეჯერი გაერკვევა და ავტომატურად აღმოაჩენს ყველაფერს. იგივე MIME ტიპებთან. როგორც გამოსავალი, შემოთავაზებულია იგივე სერვისის გამოყენება, რომელიც გარდა შესრულებადობის დროშის დაყენებისა, იქნება, თუ არის ხატები და ა.შ. AppImage-ში დააკოპირეთ ისინი AppImage-დან სწორ ადგილებში XDG-ის მიხედვით. წაშლის ან გადატანისას, მოსალოდნელია, რომ სერვისი გაასუფთავებს ყველაფერს. რა თქმა უნდა, არსებობს განსხვავებები თითოეული სამუშაო გარემოს ქცევაში, გრაფიკული ფაილის ფორმატებში, მათ ზომებში, შენახვის ადგილებსა და ქეშის განახლების მეთოდებში, რაც პრობლემას ქმნის. მოკლედ, ეს მეთოდი ყავარჯენია.
• თუ ზემოთ ჩამოთვლილი არ არის საკმარისი, ფაილ მენეჯერში ჯერ კიდევ არ არის AppImage ხატულა. Linux სამყაროს ჯერ არ გადაუწყვეტია elficon-ის დანერგვა (მიუხედავად დისკუსია и განხორციელება), ასე რომ შეუძლებელია ხატის პირდაპირ აპლიკაციაში ჩასმა. ასე რომ, გამოდის, რომ ფაილ მენეჯერის აპლიკაციებს არ აქვთ საკუთარი ხატები (არავითარი განსხვავება, AppImage ან სხვა რამ), ისინი მხოლოდ დაწყების მენიუშია. გამოსავალად, ჩვენ ვიყენებთ ესკიზებს, მექანიზმს, რომელიც თავდაპირველად შეიქმნა იმისათვის, რომ დესკტოპის მენეჯერებს აჩვენონ გრაფიკული ფაილების ესკიზების წინასწარი გადახედვის სურათები მათ ხატებად. შესაბამისად, შესრულებადობის ბიტის დაყენების სერვისი ასევე მუშაობს როგორც „მინიატურიზატორი“, ქმნის და წერს ხატის ესკიზებს შესაბამის ადგილებში. /usr и $HOME. ეს სერვისი ასევე ახორციელებს გაწმენდას, თუ AppImage წაიშლება ან გადატანილია. იმის გამო, რომ დესკტოპის თითოეული მენეჯერი ოდნავ განსხვავებულად იქცევა, მაგალითად, რა ფორმატში იღებს ხატებს, რა ზომებში ან ადგილებში, ეს ყველაფერი მართლაც მტკივნეულია.
• პროგრამა უბრალოდ იშლება შესრულებისას, თუ მოხდა შეცდომები (მაგალითად, არის ბიბლიოთეკა, რომელიც არ არის საბაზისო სისტემის ნაწილი და არ არის მოწოდებული AppImage-ში), და არავინ ეუბნება მომხმარებელს GUI-ში, რა ხდება ზუსტად. ჩვენ დავიწყეთ ამის თავიდან აცილება გამოყენებით შენიშვნა სამუშაო მაგიდაზე, რაც ნიშნავს, რომ ჩვენ უნდა დავიჭიროთ შეცდომები ბრძანების სტრიქონიდან, გადავიყვანოთ ისინი მომხმარებლის მიერ გასაგებ შეტყობინებებად, რომლებიც შემდეგ უნდა გამოჩნდეს სამუშაო მაგიდაზე. და რა თქმა უნდა, თითოეული დესკტოპის გარემო მათ ოდნავ განსხვავებულად უმკლავდება.
• ამ დროისთვის (2019 წლის სექტემბერი - თარჯიმანის შენიშვნა) მე ვერ ვიპოვე მარტივი გზა, რომ სისტემას ვუთხრა, რომ ფაილი 1.png უნდა გაიხსნას Krita-ს გამოყენებით და 2.png - GIMP-ის გამოყენებით.

მეხსიერების ადგილმდებარეობა ჯვარედინი სამუშაო მაგიდის სპეციფიკაციებისთვის, რომლებიც გამოიყენება GNOME, KDE и Xfce არის freedesktop.org

ჰაიკუს სამუშაო გარემოში ღრმად ჩაქსოვილი დახვეწილობის დონის მიღწევა რთულია, თუ არა შეუძლებელი, სპეციფიკაციების გამო. XDG freedesktop.org-დან ჯვარედინი დესკტოპისთვის, ისევე როგორც დესკტოპის მენეჯერების განხორციელებისთვის ამ სპეციფიკაციების საფუძველზე. მაგალითად, შეგვიძლია მოვიყვანოთ Firefox-ის ერთი სისტემური ხატულა: როგორც ჩანს, XDG-ის ავტორებს არც კი უფიქრიათ, რომ მომხმარებელს შეეძლო ერთი და იმავე აპლიკაციის რამდენიმე ვერსიის დაყენება.

ხატები Firefox-ის სხვადასხვა ვერსიებისთვის

მაინტერესებდა, რისი სწავლა შეეძლო Linux-ის სამყაროს Mac OS X-ისგან, რათა თავიდან აიცილოს სისტემის ინტეგრაცია. თუ დრო გაქვთ და გაინტერესებთ, აუცილებლად წაიკითხეთ რას ამბობს არნო გურდოლი, Mac OS X-ის ერთ-ერთი პირველი ინჟინერი:

ჩვენ გვინდოდა, რომ აპლიკაციის ინსტალაცია ისეთივე მარტივი გაგვეკეთებინა, როგორც აპლიკაციის ხატის გადატანა სადღაც (სერვერი, გარე დისკი) თქვენს კომპიუტერის დისკზე. ამისათვის აპლიკაციის პაკეტი ინახავს ყველა ინფორმაციას, მათ შორის ხატებს, ვერსიას, ფაილის ტიპს, რომელიც მუშავდება, URL სქემების ტიპს, რომელიც სისტემამ უნდა იცოდეს განაცხადის დასამუშავებლად. ეს ასევე მოიცავს ინფორმაციას „ცენტრალური შენახვის“ შესახებ ხატულათა სერვისებისა და გაშვების სერვისების მონაცემთა ბაზაში. მუშაობის მხარდასაჭერად, აპლიკაციები "აღმოჩენილია" რამდენიმე "ცნობილ" ადგილას: სისტემისა და მომხმარებლის აპლიკაციების დირექტორიაში, და ზოგიერთ სხვა ავტომატურად, თუ მომხმარებელი ნავიგაციას გაუწევს Finder-ს აპლიკაციის შემცველ დირექტორიაში. პრაქტიკაში ეს ძალიან კარგად მუშაობდა.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 სესია 144 - Mac OS X: აპლიკაციების შეფუთვა და დოკუმენტების ბეჭდვა.

ამ ინფრასტრუქტურის მსგავსი არაფერია Linux დესკტოპებზე, ამიტომ ჩვენ ვეძებთ გამოსავალს AppImage პროექტში სტრუქტურული შეზღუდვების გარშემო.

ჰაიკუ მოდის სამაშველოში?

და კიდევ ერთი რამ: Linux პლატფორმები, როგორც დესკტოპის გარემოს საფუძველი, როგორც წესი, იმდენად დაუზუსტებელია, რომ ბევრი რამ, რაც საკმაოდ მარტივია თანმიმდევრული სრული სტეკის სისტემაში, არის იმედგაცრუებული ფრაგმენტული და რთული Linux-ში. მე მივუძღვენი მთელი ანგარიში Linux პლატფორმასთან დაკავშირებულ საკითხებს დესკტოპის გარემოებისთვის (მცოდნე დეველოპერებმა დაადასტურეს, რომ ყველაფერი ასე დარჩება ძალიან დიდი ხნის განმავლობაში).

ჩემი მოხსენება Linux დესკტოპის გარემოს პრობლემებზე 2018 წელს

ლინუს ტორვალდმაც კი აღიარა, რომ ფრაგმენტაცია იყო მიზეზი იმისა, რომ სამუშაო სივრცის იდეა ჩავარდა.

სასიამოვნოა ჰაიკუს ნახვა!

ჰაიკუ ყველაფერს საოცრად მარტივს ხდის

მიუხედავად იმისა, რომ გულუბრყვილო მიდგომა AppImage-ის ჰაიკუზე „პორტირებისთვის“ არის უბრალოდ მისი კომპონენტების (ძირითადად runtime.c და სერვისის) აშენების მცდელობა (რაც შეიძლება იყოს შესაძლებელი!), ეს დიდ სარგებელს არ მოუტანს ჰაიკუს. რადგან სინამდვილეში, ამ პრობლემების უმეტესობა მოგვარებულია ჰაიკუში და კონცეპტუალურად გამართლებულია. Haiku უზრუნველყოფს ზუსტად სისტემის ინფრასტრუქტურის სამშენებლო ბლოკებს, რომლებსაც ამდენი ხანი ვეძებდი Linux-ის დესკტოპის გარემოში და ვერ ვიჯერებდი, რომ იქ არ იყო. კერძოდ:

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

• ELF ფაილები, რომლებსაც არ აქვთ შესრულებადობის ბიტი, ავტომატურად იღებენ მას, როდესაც ორჯერ დააწკაპუნებთ ფაილ მენეჯერში.
• აპლიკაციებს შეიძლება ჰქონდეთ ჩაშენებული რესურსები, როგორიცაა ხატები, რომლებიც ნაჩვენებია ფაილ მენეჯერში. არ არის საჭირო სურათების თაიგულის გადაწერა სპეციალურ კატალოგებში ხატებით და, შესაბამისად, არ არის საჭირო მათი გაწმენდა აპლიკაციის წაშლის ან გადატანის შემდეგ.
• არსებობს მონაცემთა ბაზა აპლიკაციების დოკუმენტებთან დასაკავშირებლად, ამისათვის არ არის საჭირო ფაილების კოპირება.
• lib/ დირექტორიაში შესრულებადი ფაილის გვერდით, ბიბლიოთეკები იძებნება ნაგულისხმევად.
• არ არსებობს მრავალი დისტრიბუცია და დესკტოპის გარემო; რაც მუშაობს, ყველგან მუშაობს.
• არ არსებობს ცალკე მოდული გასაშვებად, რომელიც განსხვავდება Applications დირექტორიასგან.
• აპლიკაციებს არ აქვთ ჩაშენებული აბსოლუტური ბილიკები თავიანთი რესურსებისკენ; მათ აქვთ სპეციალური ფუნქციები მდებარეობის დასადგენად გაშვების დროს.
• დაინერგა შეკუმშული ფაილური სისტემის სურათების იდეა: ეს არის ნებისმიერი hpkg პაკეტი. ყველა მათგანი დამონტაჟებულია ბირთვით.
• თითოეული ფაილი იხსნება აპლიკაციის მიერ, რომელმაც შექმნა იგი, თუ თქვენ პირდაპირ არ მიუთითებთ სხვაგვარად. რა მაგარია ეს!

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

როგორც ჩანს, Linux-ზე AppImage-ის მიერ მოთხოვნილი ბევრი ხელჯოხები და გამოსავალი ხდება არასაჭირო Haiku-ზე, რომელსაც აქვს სიმარტივე და დახვეწილობა, რაც აიძულებს მას გაუმკლავდეს ჩვენი საჭიროებების უმეტესობას.

ბოლოს და ბოლოს, ჰაიკუს სჭირდება აპლიკაციის პაკეტები?

ეს იწვევს დიდ კითხვას. Haiku-ზე AppImage-ის მსგავსი სისტემის შექმნა რომ სიდიდის რიგით ადვილი იყოს, ვიდრე Linux-ზე, ღირდა ამის გაკეთება? ან ჰაიკუმ თავისი hpkg პაკეტის სისტემით ეფექტურად აღმოფხვრა ასეთი იდეის შემუშავების საჭიროება? კარგად, პასუხის გასაცემად უნდა გადავხედოთ AppImages-ის არსებობის მოტივაციას.

მომხმარებლის პერსპექტივა

მოდით გადავხედოთ ჩვენს საბოლოო მომხმარებელს:

• მსურს აპლიკაციის დაყენება ადმინისტრატორის (root) პაროლის მოთხოვნის გარეშე. ჰაიკუზე არ არსებობს ადმინისტრატორის კონცეფცია, მომხმარებელს აქვს სრული კონტროლი, რადგან ეს არის პერსონალური სისტემა! (პრინციპში, თქვენ შეგიძლიათ წარმოიდგინოთ ეს მულტიმოთამაშის რეჟიმში, იმედი მაქვს, რომ დეველოპერები ამას მარტივია)
• მსურს მივიღო აპლიკაციების უახლესი და საუკეთესო ვერსიები, რომ არ დაველოდო მათ გამოჩენას ჩემს დისტრიბუციაში (ყველაზე ხშირად ეს ნიშნავს „არასდროს“, ყოველ შემთხვევაში, თუ არ ვაახლებ მთელ ოპერაციულ სისტემას). ჰაიკუზე ეს "მოგვარებულია" მცურავი რელიზებით. ეს ნიშნავს, რომ შესაძლებელია აპლიკაციების უახლესი და უახლესი ვერსიების მიღება, მაგრამ ამისთვის საჭიროა მუდმივად განაახლოთ სისტემის დანარჩენი ნაწილი, ფაქტობრივად გადააქციოთ იგი „მოძრავ სამიზნედ“.
• მე მინდა ერთი და იგივე აპლიკაციის რამდენიმე ვერსია გვერდიგვერდ, რადგან არ არსებობს გზა იმის გაგება, თუ რა იყო გატეხილი უახლეს ვერსიაში, ან, ვთქვათ, მე, როგორც ვებ დეველოპერს, მჭირდება ჩემი მუშაობის ტესტირება ბრაუზერის სხვადასხვა ვერსიით. ჰაიკუ წყვეტს პირველ პრობლემას, მაგრამ არა მეორეს. განახლებები უკან დაბრუნდა, მაგრამ მხოლოდ მთელი სისტემისთვის; შეუძლებელია (რამდენადაც მე ვიცი) გაშვება, მაგალითად, WebPositive-ის ან LibreOffice-ის რამდენიმე ვერსიის ერთდროულად.

ერთ-ერთი დეველოპერი წერს:

არსებითად დასაბუთება ასეთია: გამოყენების შემთხვევა იმდენად იშვიათია, რომ ოპტიმიზაციას აზრი არ აქვს; HaikuPorts-ში მისი განსაკუთრებული შემთხვევის განხილვა უფრო მისაღები ჩანს.

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

დეველოპერის კომენტარი:

ტექნიკურად, ეს უკვე შესაძლებელია mount ბრძანებით. რა თქმა უნდა, ჩვენ გავაკეთებთ ამისთვის GUI-ს, როგორც კი საკმარისი დაინტერესებული მომხმარებელი გვეყოლება.

• მე არ მჭირდება ფაილურ სისტემაში მიმოფანტული მილიონობით ფაილი, რომლებსაც ხელით ვერ ვმართავ. მე მინდა ერთი ფაილი თითო აპლიკაციაში, რომელიც მარტივად შემიძლია გადმოვწერო, გადავიტანო, წავშალო. ჰაიკუზე ეს პრობლემა მოგვარებულია პაკეტების გამოყენებით .hpkg, რომელიც გადასცემს, მაგალითად, პითონს, ათასობით ფაილიდან ერთში. მაგრამ თუ არსებობს, მაგალითად, Scribus, რომელიც იყენებს python-ს, მაშინ მინიმუმ ორ ფაილთან მაქვს საქმე. და მე უნდა ვიზრუნო, რომ შევინარჩუნო მათი ვერსიები, რომლებიც მუშაობენ ერთმანეთთან.

AppImages-ის მრავალი ვერსია მუშაობს გვერდიგვერდ იმავე Linux-ზე

აპლიკაციის შემქმნელის პერსპექტივა

მოდით შევხედოთ აპლიკაციის შემქმნელის თვალსაზრისით:

• მინდა გავაკონტროლო მომხმარებლის მთელი გამოცდილება. არ მინდა დამოკიდებული ვიყო ოპერაციულ სისტემაზე, რომ მითხრას, როდის და როგორ უნდა გამოვუშვა აპლიკაციები. Haiku საშუალებას აძლევს დეველოპერებს იმუშაონ საკუთარ hpkg საცავებთან, მაგრამ ეს ნიშნავს, რომ მომხმარებლებს მოუწევთ მათი ხელით დაყენება, რაც იდეას "ნაკლებად მიმზიდველს" ხდის.
• ჩემს ვებგვერდზე მაქვს ჩამოტვირთვის გვერდი, სადაც ვავრცელებ .exe ვინდოუსისთვის, .dmg მაკისთვის და .AppImage Linux-ისთვის. ან იქნებ მსურს ამ გვერდზე წვდომის მონეტიზაცია, ყველაფერი შესაძლებელია? რა უნდა დავაყენო იქ ჰაიკუსთვის? ფაილი საკმარისია .hpkg დამოკიდებულებით მხოლოდ HaikuPorts-იდან
• ჩემი პროგრამული უზრუნველყოფა მოითხოვს სხვა პროგრამული უზრუნველყოფის კონკრეტულ ვერსიებს. მაგალითად, ცნობილია, რომ Krita მოითხოვს Qt-ის შესწორებულ ვერსიას, ან Qt-ს, რომელიც სრულყოფილად არის მორგებული Krita-ს კონკრეტულ ვერსიაზე, მინიმუმ მანამ, სანამ პატჩები არ დაბრუნდება Qt-ში. თქვენ შეგიძლიათ შეფუთოთ თქვენი საკუთარი Qt თქვენი განაცხადისთვის პაკეტში .hpkg, მაგრამ, სავარაუდოდ, ეს არ არის მისასალმებელი.

რეგულარული განაცხადის ჩამოტვირთვის გვერდი. რა უნდა გამოვაქვეყნო აქ ჰაიკუსთვის?

Will პაკეტები (არსებობს როგორც აპლიკაციის დირექტორიები, როგორიცაა AppDir ან .app Apple-ის სტილში) და/ან სურათები (ძალიან მოდიფიცირებული AppImages-ის სახით ან .dmg Apple-ისგან) აპლიკაციები სასარგებლო დამატებაა Haiku დესკტოპის გარემოში? ან ეს გააზავებს მთელ სურათს და გამოიწვევს ფრაგმენტაციას და, შესაბამისად, დაამატებს სირთულეს? მე მოწყვეტილი ვარ: ერთი მხრივ, ჰაიკუს სილამაზე და დახვეწილობა ემყარება იმ ფაქტს, რომ, როგორც წესი, რაღაცის გასაკეთებლად ერთი გზა არსებობს, ვიდრე ბევრი. მეორეს მხრივ, კატალოგების და/ან აპლიკაციების კომპლექტების ინფრასტრუქტურის უმეტესობა უკვე შექმნილია, ამიტომ სისტემა ტირის, რომ დარჩენილი რამდენიმე პროცენტი თავის ადგილზე დადგეს.

დეველოპერის თქმით ბატონი. ჭექა-ქუხილი

Linux-ზე ისინი (კატალოგები და აპლიკაციების ნაკრები, - დაახლ. მთარგმნელი) დიდი ალბათობით არის სისტემური პრობლემების ტექნიკური გადაწყვეტა. ჰაიკუში ჩვენ გვირჩევნია უბრალოდ გადავჭრათ სისტემის პრობლემები.

Რას ფიქრობ?

სანამ უპასუხებდი...

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

აპლიკაციის დირექტორიები უკვე არსებობს Haiku-ზე, მაგრამ ჯერ არ არის მხარდაჭერილი ფაილების მენეჯერში

ისინი უბრალოდ არ არიან ისეთი მხარდაჭერილი, როგორც, ვთქვათ, Macintosh Finder. რამდენად მაგარი იქნებოდა, თუ QtCreator დირექტორიას ექნება "QtCreator" სახელი და ხატი ზედა მარცხენა კუთხეში, რომელიც გაუშვებს აპლიკაციას ორჯერ დაწკაპუნებით?

ცოტა ადრე მე უკვე იკითხა:

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

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

ბ-ნ. waddlesplash:

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

ეს ნამდვილად არის!

რა ქმედება უნდა მიიღოს ჰაიკუმ?

წარმომიდგენია hpkg-ის, დირექტორიებისა და აპლიკაციების სურათების მშვიდობიანი თანაარსებობა:

• სისტემის პროგრამული უზრუნველყოფის გამოყენება .hpkg
• ყველაზე ხშირად გამოყენებული პროგრამული უზრუნველყოფისთვის (განსაკუთრებით მათ, რომლებსაც სჭირდებათ მოძრავი გამოშვებების დაგეგმვა), გამოიყენეთ .hpkg (ყველა შემთხვევის დაახლოებით 80%)
• ზოგიერთი დაინსტალირებული მეშვეობით .hpkg, აპლიკაციები ისარგებლებენ აპლიკაციის დირექტორიაში ინფრასტრუქტურაში გადასვლით (მაგ. QtCreator): ისინი განაწილდება როგორც .hpkg, როგორც ადრე.

ბატონი. waddlesplash წერს:

თუ ყველაფერი რაც თქვენ გჭირდებათ არის აპლიკაციების ნახვა /system/apps, ამის ნაცვლად, ჩვენ უნდა გავხადოთ დირექტორიები Deskbar-ში უფრო მართვადი მომხმარებლებისთვის, რადგან /system/apps არ არის გამიზნული მომხმარებლების მიერ რეგულარულად გასახსნელად და სანახავად (MacOS-ისგან განსხვავებით). ასეთი სიტუაციებისთვის ჰაიკუს განსხვავებული პარადიგმა აქვს, მაგრამ ეს ვარიანტი, თეორიულად, მისაღებია.

• ჰაიკუ იღებს ინფრასტრუქტურას აპლიკაციის სურათების გასაშვებად, პროგრამული უზრუნველყოფის ღამის, უწყვეტ და სატესტო ნაგებობებისთვის, ასევე იმ შემთხვევისთვის, როდესაც მომხმარებელს სურს მისი დროულად გაყინვა, პირადი და შიდა პროგრამული უზრუნველყოფის და სხვა სპეციალური გამოყენების შემთხვევებისთვის (დაახლოებით 20% ყველა). ეს სურათები შეიცავს აპლიკაციის გასაშვებად საჭირო ფაილებს .hpkg, დამონტაჟებულია სისტემის მიერ და აპლიკაციის დასრულების შემდეგ - დემონტაჟი. (შესაძლოა, ფაილის მენეჯერს შეუძლია ფაილების განთავსება .hpkg აპლიკაციის სურათებში, ავტომატურად ან მომხმარებლის მოთხოვნით - ისევე, როგორც მაშინ, როცა აპლიკაციას გადაიტანეთ ქსელის დირექტორიაში ან გარე დისკზე. ეს უბრალოდ სიმღერაა! უფრო სწორად, პოეზია - ჰაიკუ.) მეორეს მხრივ, მომხმარებელს შეუძლია სურათის შინაარსის ფაილების სახით დაყენება..hpkg, რის შემდეგაც მოხდება მათი განახლება და დამუშავება ისე, როგორც HaikuDepot-ის საშუალებით დაინსტალირდა... ჩვენ გვჭირდება ტვინშტორმი).

ციტატა ბატონისაგან. waddlesplash:

გარე დისკებიდან ან ქსელის დირექტორიებიდან აპლიკაციების გაშვება შესაძლოა სასარგებლო იყოს. და pkgman-ისთვის მეტი „ზონების“ კონფიგურაციის შესაძლებლობის დამატება ნამდვილად კარგი ფუნქცია იქნება.

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

დასკვნა

ჰაიკუს აქვს ჩარჩო, რომელიც უზრუნველყოფს მარტივი და დახვეწილი მომხმარებლის გამოცდილებას კომპიუტერისთვის და ბევრად სცილდება იმას, რაც ჩვეულებრივ გათვალისწინებულია Linux კომპიუტერისთვის. პაკეტის სისტემა .hpkg ერთ-ერთი ასეთი მაგალითია, მაგრამ დანარჩენი სისტემაც დახვეწილებით არის გამსჭვალული. თუმცა, ჰაიკუ ისარგებლებს შესაბამისი დირექტორია და აპლიკაციის გამოსახულების მხარდაჭერით. რამდენად უკეთესია ამის გაკეთება, ღირს იმ ადამიანებთან განხილვა, ვინც ჰაიკუს, მის ფილოსოფიასა და არქიტექტურას ბევრად უკეთ იცნობს, ვიდრე მე. ბოლოს და ბოლოს, მე ვხმარობ ჰაიკუს ერთ კვირაზე ცოტა მეტია. მიუხედავად ამისა, მე მჯერა, რომ ჰაიკუს დიზაინერები, დეველოპერები და არქიტექტორები ისარგებლებენ ამ ახალი პერსპექტივით. სულ მცირე, სიამოვნებით ვიქნებოდი მათი „სპარინგ პარტნიორი“. მე მაქვს 10 წელზე მეტი პრაქტიკული გამოცდილება Linux-ის აპლიკაციების კატალოგებსა და პაკეტებში და მსურს ვიპოვო მათი გამოყენება ჰაიკუში, რისთვისაც ვფიქრობ, რომ ისინი იდეალურად ჯდება. ჩემს მიერ შემოთავაზებული პოტენციური გადაწყვეტილებები არ არის ერთადერთი სწორი გადაწყვეტილებები, რომლებიც აღვწერე და თუ ჰაიკუს გუნდი გადაწყვეტს სხვა, უფრო ელეგანტური გადაწყვეტილებების პოვნას, მე ამის მომხრე ვარ. ძირითადად, მე უკვე ვფიქრობ იმაზე, თუ როგორ შევქმნა სისტემა hpkg კიდევ უფრო გასაოცარია მისი მუშაობის შეცვლის გარეშე. თურმე, ჰაიკუს გუნდი პაკეტების მართვის სისტემის დანერგვისას დიდი ხანია აპლიკაციების პაკეტებზე ფიქრობდა, მაგრამ სამწუხაროდ (მგონი) იდეა „მოძველდა“. იქნებ დროა მისი აღორძინება?

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

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

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

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

გამოკითხვაში მონაწილეობა შეუძლიათ მხოლოდ დარეგისტრირებულ მომხმარებლებს. Შებრძანდითგთხოვთ

აქვს თუ არა აზრი hpkg სისტემის ლინუქსის პორტირებას?

• დიახ

• არარის

• უკვე განხორციელებული, კომენტარებში დავწერ

მისცა ხმა 20 მომხმარებელმა. 5-მა მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com