Η έκτη μέρα μου με το Haiku: κάτω από την κουκούλα των πόρων, των εικονιδίων και των πακέτων

Η έκτη μέρα μου με το Haiku: κάτω από την κουκούλα των πόρων, των εικονιδίων και των πακέτων

TL? DRΑ: Το Haiku είναι ένα λειτουργικό σύστημα ειδικά σχεδιασμένο για υπολογιστές, επομένως έχει μερικά κόλπα για να το κάνει πολύ καλύτερο περιβάλλον επιφάνειας εργασίας από άλλα. Πώς λειτουργεί όμως;

Πρόσφατα Ανακάλυψα το Haiku, ένα απροσδόκητα καλό σύστημα. Εξακολουθώ να εκπλήσσομαι με το πόσο ομαλά εκτελείται, ειδικά σε σύγκριση με περιβάλλοντα επιφάνειας εργασίας Linux. Σήμερα θα ρίξω μια ματιά κάτω από την κουκούλα. Όπου χρειάζεται για εις βάθος κατανόηση, θα κάνω συγκρίσεις με τους αρχικούς υπολογιστές Macintosh, Mac OS X και Linux (πρότυπο XDG από το freedesktop.org).

Πόροι σε αρχεία ELF

Χθες ανακάλυψα ότι το IconOMatic μπορεί να αποθηκεύσει εικονίδια σε πόρους rdef σε εκτελέσιμα αρχεία ELF. Σήμερα θέλω να δω πώς λειτουργεί πραγματικά.

Πόροι? Παραθέτω από Μπρους Χορν, ο αρχικός συγγραφέας του Macintosh Finder και ο πατέρας του Macintosh Resource Manager:

Ανησυχώ για την άκαμπτη φύση της παραδοσιακής κωδικοποίησης. Για μένα, η ίδια η ιδέα μιας εφαρμογής παγωμένης σε κώδικα, χωρίς τη δυνατότητα να αλλάξω τίποτα δυναμικά, είναι η πιο άγρια ​​φύση. Θα πρέπει να είναι δυνατή η αλλαγή όσο το δυνατόν περισσότερο κατά το χρόνο εκτέλεσης. Φυσικά, ο ίδιος ο κωδικός της εφαρμογής δεν μπορεί να αλλάξει, αλλά μπορεί να αλλάξει κάτι χωρίς να γίνει εκ νέου μεταγλώττιση του κώδικα;

Ο αρχικός Macintosh έκανε αυτά τα αρχεία να έχουν μια "ενότητα δεδομένων" και μια "ενότητα πόρων", γεγονός που καθιστούσε εξαιρετικά εύκολη την αποθήκευση πραγμάτων όπως εικονίδια, μεταφράσεις και ούτω καθεξής. σε εκτελέσιμα αρχεία.

Σε Mac, αυτό ισχύει Επανεπεξεργασία, ένα γραφικό πρόγραμμα για - ξαφνικά - επεξεργασία πόρων.

Η έκτη μέρα μου με το Haiku: κάτω από την κουκούλα των πόρων, των εικονιδίων και των πακέτων
Επανεπεξεργασία σε αρχικό Macintosh

Ως αποτέλεσμα, κατέστη δυνατή η επεξεργασία εικονιδίων, στοιχείων μενού, μεταφράσεων και ούτω καθεξής. αρκετά εύκολα, αλλά και πάλι «ταξιδεύουν» με εφαρμογές.
Σε κάθε περίπτωση, αυτή η προσέγγιση είχε ένα μεγάλο μειονέκτημα: λειτούργησε μόνο σε συστήματα αρχείων της Apple, κάτι που ήταν ένας από τους λόγους για τους οποίους η Apple εγκατέλειψε το "τμήμα πόρων" όταν μετακόμισε στο Mac OS X.
Στο Mac OS X, η Apple ήθελε μια λύση ανεξάρτητη από το σύστημα αρχείων, γι' αυτό υιοθέτησε την έννοια των πακέτων (από το NeXT), καταλόγων που αντιμετωπίζονται ως "αδιαφανή αντικείμενα" από τον διαχειριστή αρχείων, όπως αρχεία, όχι καταλόγους. Οποιοδήποτε πακέτο με εφαρμογή στη μορφή .app διαθέτει, μεταξύ άλλων, το αρχείο Info.plist (σε κάποιο ανάλογο του JSON ή του YAML από την Apple) που περιέχει μεταδεδομένα εφαρμογής.

Η έκτη μέρα μου με το Haiku: κάτω από την κουκούλα των πόρων, των εικονιδίων και των πακέτων
Κλειδιά αρχείου Info.plist από το πακέτο εφαρμογών Mac OS X.

Πόροι, όπως εικονίδια, αρχεία διεπαφής χρήστη και άλλα, αποθηκεύονται στο πακέτο ως αρχεία. Η ιδέα στην πραγματικότητα επέστρεψε στις ρίζες της στο NeXT.

Η έκτη μέρα μου με το Haiku: κάτω από την κουκούλα των πόρων, των εικονιδίων και των πακέτων
Το Mathematica.app στο NeXTSTEP 1.0 το 1989: εμφανίζεται ως κατάλογος αρχείων στο τερματικό, αλλά ως ένα μεμονωμένο αντικείμενο στη διαχείριση αρχείων γραφικών.

Ας επιστρέψουμε στο BeOS, στο οποίο βασίζεται το Haiku. Οι προγραμματιστές του, όταν μετακινήθηκαν από το PEF (PowerPC) στο ELF (x86) (το ίδιο που χρησιμοποιείται στο Linux), αποφάσισαν να προσθέσουν μια ενότητα πόρων στο τέλος των αρχείων ELF. Αυτό δεν χρησιμοποίησε τη δική του κατάλληλη ενότητα ELF, απλώς προστέθηκε στο τέλος του αρχείου ELF. Ως αποτέλεσμα του προγράμματος strip και άλλοι με μπινουτίλ που δεν το ξέρουν απλά το έκοψαν. Επομένως, μετά την προσθήκη πόρων σε ένα αρχείο ELF στο BeOS, είναι καλύτερο να μην εργάζεστε μαζί του με εργαλεία Linux.

Και τι συμβαίνει τώρα με τα Χαϊκού; Βασικά, πάνω κάτω το ίδιο.

Θεωρητικά, θα ήταν δυνατό να τοποθετηθούν πόροι στο επιθυμητό τμήμα του ELF. Σύμφωνα με τους προγραμματιστές στο κανάλι #haiku στο irc.freenode.net:

Με το ELF, η ενότητα θα είχε πιο νόημα... ο μόνος λόγος που δεν το κάνουμε αυτό είναι επειδή το κάναμε στο BeOS."
Και δεν χρειάζεται να αλλάξει τώρα.

Έλεγχος των αναγκών

Οι πόροι είναι γραμμένοι σε μια δομημένη μορφή "πόρων": στην πραγματικότητα, αυτή είναι μια λίστα πόρων με μεγέθη και στη συνέχεια το περιεχόμενό τους. θυμήθηκε μορφή ar.
Πώς να ελέγξετε τους πόρους στο Haiku; Υπάρχει κάτι σαν το 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_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 στα εκτελέσιμα αρχεία τους).

Φυσικά, μπορείτε να προσθέσετε πόρους με τα επιθυμητά αναγνωριστικά και τύπους και στη συνέχεια να τους διαβάσετε στην ίδια την εφαρμογή ή σε άλλες εφαρμογές χρησιμοποιώντας την τάξη BResources. Αλλά πρώτα, ας επικεντρωθούμε στο συναρπαστικό θέμα των εικονιδίων.

Διανυσματικά εικονίδια σε στυλ χαϊκού

Φυσικά, όχι μόνο το Haiku επέλεξε την καλύτερη μορφή εικονιδίου, σε αυτό το μέρος η κατάσταση με τους επιτραπέζιους υπολογιστές 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. Έτσι, δεν είναι δυνατός ο χειρισμός της κατάστασης με την παρουσία πολλών εκδόσεων της εφαρμογής στο σύστημα.

Η έκτη μέρα μου με το Haiku: κάτω από την κουκούλα των πόρων, των εικονιδίων και των πακέτων
Διαφορετικά εικονίδια 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, που περιέχει όλα τα μεγέθη, έτσι ώστε διαφορετικές εκδόσεις της ίδιας εφαρμογής να έχουν διαφορετικά εικονίδια.
Πολύ καλύτερα! Τα εικονίδια ταξιδεύουν με την εφαρμογή, όλοι οι πόροι βρίσκονται σε ένα αρχείο.

Ας επιστρέψουμε στο Haiku. Μια συγκλονιστική απόφαση, χωρίς εξαιρέσεις. Σύμφωνα με τεκμηρίωση:

Αναπτύχθηκε μια ειδική μορφή HVIF, εξαιρετικά βελτιστοποιημένη για μικρά μεγέθη και γρήγορη απόδοση. Επομένως, τα εικονίδια μας είναι ως επί το πλείστον πολύ μικρότερα από τα bitmaps ή τη μορφή SVG που χρησιμοποιείται συνήθως.

Και εξακολουθούν να είναι βελτιστοποιημένα:

Η έκτη μέρα μου με το Haiku: κάτω από την κουκούλα των πόρων, των εικονιδίων και των πακέτων
Μεγέθη εικονιδίων σε HVIF σε σύγκριση με άλλες μορφές.

Μια τάξη μεγέθους διαφορά!

Αλλά η μαγεία δεν τελειώνει εδώ. Το ίδιο HVIF μπορεί να εμφανίζει διαφορετικά επίπεδα λεπτομέρειας ανάλογα με το μέγεθος που εμφανίζεται, παρόλο που είναι διανυσματική μορφή.

Η έκτη μέρα μου με το Haiku: κάτω από την κουκούλα των πόρων, των εικονιδίων και των πακέτων
Διαφορετικά επίπεδα λεπτομέρειας (LOD) με βάση το μέγεθος απόδοσης

Τώρα σχετικά με τα μειονεκτήματα: δεν μπορείτε να πάρετε SVG, να το ρίξετε στο ImageMagick και να το ολοκληρώσετε, πρέπει να περάσετε από αρκετούς κύκλους για να δημιουργήσετε ένα εικονίδιο σε μορφή HVIF. Εδώ εξηγήσεις. Ωστόσο, το IconOMatic μπορεί να είναι αρκετά ατελές στην εισαγωγή SVG. περίπου το 90% των στοιχείων SVG εισάγονται με κάποια πιθανότητα, το υπόλοιπο 10% θα χρειαστεί να ρυθμιστεί και να αλλάξει χειροκίνητα. Διαβάστε περισσότερα για το πώς το HVIF κάνει τα μαγικά του μπορεί κανείς να στο blog Lea Ganson

Προσθήκη εικονιδίου σε μια εφαρμογή

Τώρα μπορώ να προσθέσω ένα εικονίδιο στο πακέτο που δημιουργήθηκε τελευταία φορά, λαμβάνοντας υπόψη όλες τις πληροφορίες που λαμβάνονται.
Λοιπόν, δεδομένου ότι δεν είμαι ιδιαίτερα πρόθυμος να σχεδιάσω το δικό μου εικονίδιο για το "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

Φαίνεται καλό, αλλά γιατί όταν αντιγράφεται το νέο εικονίδιο, δεν εμφανίζεται;

Η έκτη μέρα μου με το Haiku: κάτω από την κουκούλα των πόρων, των εικονιδίων και των πακέτων
Το αντιγραμμένο 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 πάντα δείχνουν προς εμένα.

Ας επιστρέψουμε στο Haiku. Βρήκατε τη σωστή ισορροπία μεταξύ των παραδοσιακών συστημάτων συσκευασίας και της παράδοσης λογισμικού που βασίζεται σε εικόνες; Τα πακέτα της .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"

Cool, ναι; Υπομονή, θα γίνει ακόμα χειρότερο!

Υπάρχει ένα πολύ ιδιαίτερο πακέτο:

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).

Επαναφορά συστήματος με χρήση hpkg

Πόσο συχνά συμβαίνει η ακόλουθη κατάσταση: η ενημέρωση ήταν επιτυχής και, στη συνέχεια, αποδεικνύεται ότι κάτι δεν λειτουργεί όπως θα έπρεπε; Εάν χρησιμοποιείτε κανονικούς διαχειριστές πακέτων, είναι δύσκολο να επαναφέρετε την κατάσταση του συστήματος σε ένα χρονικό σημείο πριν από την εγκατάσταση νέων πακέτων (για παράδειγμα, όταν κάτι πήγε στραβά). Ορισμένα συστήματα προσφέρουν λύσεις με τη μορφή στιγμιότυπων συστημάτων αρχείων, αλλά αυτές είναι επαχθή και δεν ισχύουν σε όλα τα συστήματα. Στα χαϊκού αυτό λύνεται με πακέτα .hpkg. Κάθε φορά που αλλάζουν πακέτα στο σύστημα, τα παλιά πακέτα δεν αφαιρούνται, αλλά αποθηκεύονται στο σύστημα σε υποκαταλόγους όπως /Haiku/system/packages/administrative/state-<...>/ συνεχώς. Οι εκκρεμείς λειτουργίες αποθηκεύουν τα δεδομένα τους σε υποκαταλόγους /Haiku/system/packages/administrative/transaction-<...>/.

Η έκτη μέρα μου με το Haiku: κάτω από την κουκούλα των πόρων, των εικονιδίων και των πακέτων
Περιεχόμενο /Haiku/system/packages/administrative. Οι κατάλογοι "κατάσταση ..." περιέχουν αρχεία κειμένου με τα ονόματα των ενεργών πακέτων, "συναλλαγή ..." - τα ίδια τα πακέτα.

«Παλιά ενεργή κατάσταση», δηλ. λίστα .hpkg Τα πακέτα που είναι ενεργά πριν από τις αλλαγές εγγράφονται μετά από κάθε λειτουργία στη διαχείριση αρχείων σε ένα αρχείο κειμένου /Haiku/system/packages/administrative/state-<...>/activated-packages. Ομοίως, μια νέα "ενεργή κατάσταση" γράφεται σε ένα αρχείο κειμένου /Haiku/system/packages/administrative/activated-packages.

Κατάλογος /Haiku/system/packages/administrative/state-<...>/ περιέχει μόνο ένα αρχείο κειμένου με μια λίστα ενεργών πακέτων αυτής της κατάστασης (σε περίπτωση εγκατάστασης πακέτων χωρίς την κατάργησή τους) και εάν τα πακέτα αφαιρέθηκαν ή ενημερώθηκαν, ο κατάλογος κατάστασης περιέχει παλιές εκδόσεις πακέτων.

Κατά την εκκίνηση του συστήματος, με βάση τη λίστα των πακέτων, λαμβάνεται απόφαση για την ενεργοποίηση (προσάρτηση) των πακέτων. Είναι τόσο απλό! Εάν κάτι πάει στραβά κατά τη λήψη, μπορείτε να πείτε στον διαχειριστή λήψεων να χρησιμοποιήσει μια διαφορετική, παλαιότερη λίστα. Το πρόβλημα λύθηκε!

Η έκτη μέρα μου με το Haiku: κάτω από την κουκούλα των πόρων, των εικονιδίων και των πακέτων
Φορτωτής εκκίνησης Haiku. Κάθε σημείο εισόδου εμφανίζει μια αντίστοιχη "ενεργή κατάσταση"

Μου αρέσει η προσέγγιση της χρήσης αρχείων απλού κειμένου ως λίστα "ενεργών καταστάσεων" με ευνόητα ονόματα .hpkg. Αυτό έρχεται σε πλήρη αντίθεση με το χτισμένο για τη μηχανή-όχι-για-ανθρώπους δέσμη από το OSTree ή το Flatpak στο σύστημα αρχείων (στο ίδιο επίπεδο με το Microsoft GUID).

Η έκτη μέρα μου με το Haiku: κάτω από την κουκούλα των πόρων, των εικονιδίων και των πακέτων
Λίστα ενεργών πακέτων για κάθε χρονικό σημείο

Δεδομένα διαμόρφωσης

Προφανώς ο κατάλογος /Haiku/system/packages/administrative/writable-files περιέχει αρχεία ρυθμίσεων για πακέτα, αλλά εγγράψιμα. Άλλωστε, όπως θυμάστε, .hpkg είναι τοποθετημένα μόνο για ανάγνωση. Επομένως, αυτά τα αρχεία πρέπει να αντιγραφούν από τα πακέτα πριν γραφτούν. Έχει το νόημα.

Ενσωμάτωση GUI για σύστημα .hpkg

Ας δούμε τώρα πώς αυτές οι γυαλιστερές συσκευασίες .hpkg να αντιμετωπίσουν την ενσωμάτωση στο περιβάλλον εργασίας του χρήστη (UX). Εξάλλου, το χαϊκού προορίζεται για προσωπική χρήση. Προσωπικά, έχω θέσει τον πήχη ψηλά συγκρίνοντας την εμπειρία χρήστη με πακέτα. .app σε Macintosh με την ίδια εμπειρία .hpkg. Δεν θα συγκρίνω καν την κατάσταση με περιβάλλοντα επιτραπέζιου υπολογιστή Linux, γιατί είναι απολύτως τρομερό σε σύγκριση με οποιοδήποτε άλλο.

Μου έρχονται στο μυαλό τα ακόλουθα σενάρια:

  • Θέλω να δω τα περιεχόμενα του πακέτου .hpkg
  • Θέλω να εγκαταστήσω ένα πακέτο
  • Θέλω να αφαιρέσω ένα πακέτο
  • Θέλω να διαγράψω κάτι που μπήκε στο σύστημα ως μέρος ενός πακέτου
  • Θέλω να αντιγράψω κάτι που μπήκε στο σύστημα ως μέρος ενός πακέτου
  • Θέλω να κατεβάσω όλες τις εξαρτήσεις πακέτων που δεν μπορούν να αποτελούν μέρος κάθε εγκατάστασης Haiku (για παράδειγμα, έχω ένα φυσικά απομονωμένο μηχάνημα χωρίς πρόσβαση στο Διαδίκτυο.)
  • Θέλω να μεταφέρω τα πακέτα μου (καλά, μέρος τους) χωριστά σε άλλο μέρος, ξεχωριστά από τον τόμο εκκίνησης (διαμερισμός ρίζας) (γιατί, για παράδειγμα, δεν έχω αρκετό χώρο σε αυτό).

Αυτό θα πρέπει να καλύπτει τις περισσότερες από τις κύριες περιπτώσεις από την καθημερινή μου εργασία. Λοιπόν, ας ξεκινήσουμε.

Έλεγχος των περιεχομένων του πακέτου

Σε Mac Απλώς κάνω δεξί κλικ σε ένα πακέτο για να το ανοίξω και να προβάλω τα περιεχόμενα στο Finder. Είναι πραγματικά απλώς ένας μεταμφιεσμένος κατάλογος! (Ξέρω ότι υπάρχουν πακέτα .pkg για ένα μέρος του συστήματος που δεν είναι εφαρμογές, αλλά οι απλοί χρήστες τις περισσότερες φορές δεν αλληλεπιδρούν μαζί τους).

Στο χαϊκού Κάνω δεξί κλικ στο πακέτο και μετά στο "Περιεχόμενα" για να δω τι υπάρχει μέσα. Αλλά είναι απλώς μια λίστα αρχείων χωρίς τη δυνατότητα να κάνετε διπλό κλικ για να τα ανοίξετε.
Θα ήταν πολύ καλύτερο αν υπήρχε τρόπος να (προσωρινά) τοποθετηθεί ένα πακέτο .hpkg για προβολή μέσω ενός διαχειριστή αρχείων και ο χρήστης δεν θα χρειάζεται να ανησυχεί για τις λεπτομέρειες εφαρμογής. (Με την ευκαιρία, μπορείτε να ανοίξετε .hpkg πακέτο μέσα Expander, το οποίο μπορεί να το αποσυσκευάσει όπως κάθε άλλο αρχείο).

Η έκτη μέρα μου με το Haiku: κάτω από την κουκούλα των πόρων, των εικονιδίων και των πακέτων
Στη διεπαφή του HaikuDepot, μπορείτε να δείτε τη λίστα των αρχείων πακέτων, αλλά δεν υπάρχει τρόπος να προβάλετε τα περιεχόμενα, για παράδειγμα, κάνοντας διπλό κλικ στο README.md

Σε αυτήν την κατηγορία, το Mac κερδίζει, αλλά η προσθήκη της σωστής λειτουργικότητας στο HaikuDepot δεν θα πρέπει να είναι μεγάλη υπόθεση.

Εγκατάσταση πακέτου μέσω του GUI

Σε Mac, τις περισσότερες εικόνες δίσκου .dmg περιέχουν συσκευασίες .app. Ανοίξτε το είδωλο του δίσκου κάνοντας διπλό κλικ και, στη συνέχεια, αντιγράψτε το πακέτο, για παράδειγμα, σύροντάς το στο /Applications στο Finder. Για μένα είναι αυτονόητο, αλλά άκουσα ότι κάποιοι αρχάριοι μπορεί να μην μπορούν να το χειριστούν αυτό. Από προεπιλογή, η Apple "προτείνει" έναν κατάλογο σε όλο το σύστημα /Applications (στο NeXT ήταν δικτυωμένο και μεμονωμένο), αλλά μπορείτε εύκολα να τοποθετήσετε τις εφαρμογές σας σε διακομιστή αρχείων ή σε υποκατάλογο $HOME/Applicationsαν σου αρέσει τόσο πολύ.

Στο χαϊκού, κάντε διπλό κλικ στο πακέτο και μετά κάντε κλικ στο "Εγκατάσταση", δεν θα μπορούσε να είναι πιο εύκολο. Αναρωτιέμαι τι συμβαίνει εάν ένα πακέτο έχει εξαρτήσεις διαθέσιμες στο HaikuPorts, αλλά δεν έχει εγκατασταθεί ακόμα. Στο Linux δεν ξέρουν πραγματικά τι να κάνουν σε αυτήν την περίπτωση, αλλά η λύση είναι προφανής - ρωτήστε τον χρήστη εάν χρειάζεται λήψη και εγκατάσταση των εξαρτήσεων. Ακριβώς αυτό που κάνει ο Χαϊκού.

Η έκτη μέρα μου με το Haiku: κάτω από την κουκούλα των πόρων, των εικονιδίων και των πακέτων
Κατέβασα το πακέτο «sanity» με μη αυτόματο τρόπο και έκανα κλικ σε αυτό, ο διαχειριστής πακέτων ξέρει από πού να πάρει τις εξαρτήσεις του (υποθέτοντας ότι τα αποθετήρια είναι ήδη στο σύστημα). Δεν μπορεί κάθε διανομή Linux να το κάνει αυτό.

Ένας άλλος τρόπος είναι να χρησιμοποιήσετε τη διαχείριση αρχείων, απλώς σύρετε και αποθέστε .hpkg πακέτο ή μέσα /Haiku/system/packages (για εγκατάσταση σε όλο το σύστημα, από προεπιλογή) ή σε /Haiku/home/config/packages (για μεμονωμένη ρύθμιση, δεν διατίθεται με διπλό κλικ - εξακολουθώ να με ενοχλεί η λέξη "config" σε αυτό το μέρος, η οποία για μένα σε αυτήν την περίπτωση είναι συνώνυμο των "ρυθμίσεων"). Και η έννοια των πολλαπλών χρηστών δεν είναι ακόμη διαθέσιμη στο Haiku (ίσως γι' αυτό είναι τόσο απλή - δεν ξέρω, ίσως οι δυνατότητες πολλών χρηστών να περιπλέξουν άσκοπα τα πράγματα για ένα περιβάλλον επιφάνειας εργασίας).

Σε αυτή την κατηγορία, το Haiku κερδίζει, γιατί μπορεί να λειτουργήσει όχι μόνο με εφαρμογές, αλλά και με προγράμματα συστήματος.

Αφαίρεση πακέτου από το GUI

Σε Mac, πρέπει να σύρετε το εικονίδιο της εφαρμογής στον κάδο απορριμμάτων και αυτό είναι. Εύκολα!

Στο χαϊκού, πρώτα, πρέπει να βρείτε πού βρίσκεται το πακέτο στο σύστημα, γιατί σπάνια το εγκαθιστάτε στη σωστή θέση (το σύστημα κάνει τα πάντα). Συνήθως πρέπει να ψάξετε /Haiku/system/packages (σε μια προεπιλεγμένη εγκατάσταση σε όλο το σύστημα) ή σε /Haiku/home/config/packages (Είπα ότι το "config" είναι λάθος όνομα;). Στη συνέχεια, η εφαρμογή απλώς σύρεται στον κάδο απορριμμάτων, και αυτό είναι όλο.
Εύκολα! Ωστόσο, δεν θα το έλεγα. Να τι πραγματικά συμβαίνει:

Η έκτη μέρα μου με το Haiku: κάτω από την κουκούλα των πόρων, των εικονιδίων και των πακέτων
Αυτό συμβαίνει όταν σύρετε μια εφαρμογή στον κάδο απορριμμάτων από /Haiku/system/packages

Μόλις προσπάθησα να μεταφέρω τη χθεσινή μου εφαρμογή "Hello world" στο QtQuickApp στον κάδο απορριμμάτων. Δεν προσπάθησα να μετακινήσω τον κατάλογο του συστήματος, και δεδομένου ότι όλα τα πακέτα είναι εγκατεστημένα στον κατάλογο του συστήματος - είναι αδύνατο να αφαιρέσετε το πακέτο .hpkg χωρίς αλλαγή "το ΠΕΡΙΕΧΟΜΕΝΟ ΤΟΥ". Ένας συνηθισμένος χρήστης θα φοβόταν, θα πατούσε το κουμπί "Ακύρωση" που έχει εκχωρηθεί από προεπιλογή.

Εξηγεί κύριος. παφλασμός:

Αυτή η ανάρτηση είναι πάνω από 10 ετών. Πιθανότατα, πρέπει να το ρυθμίσουμε έτσι ώστε η προειδοποίηση να βγαίνει μόνο όταν μετακινηθεί το ίδιο το πακέτο. Οι απλοί χρήστες δεν χρειάζεται να το κάνουν ούτως ή άλλως.

Εντάξει, ίσως θα έπρεπε να το κάνετε χρησιμοποιώντας το HaikuDepot; Κάντε διπλό κλικ στο πακέτο /Haiku/system/packages, περιμένοντας να εμφανιστεί το κουμπί "Κατάργηση εγκατάστασης". Όχι, υπάρχει (μόνο) "Εγκατάσταση". Απεγκατάσταση, πού είσαι;

Για πλάκα, προσπάθησα να δω τι θα συμβεί αν κάνω κλικ στο "Εγκατάσταση" σε ένα ήδη εγκατεστημένο πακέτο. Αποδεικνύεται ως εξής:

Η έκτη μέρα μου με το Haiku: κάτω από την κουκούλα των πόρων, των εικονιδίων και των πακέτων
Αυτό συμβαίνει εάν προσπαθήσετε να εγκαταστήσετε ένα ήδη εγκατεστημένο πακέτο.

Εμφανίζεται στη συνέχεια:

Η έκτη μέρα μου με το Haiku: κάτω από την κουκούλα των πόρων, των εικονιδίων και των πακέτων
Εάν κάνετε κλικ στο "Εφαρμογή αλλαγών" στο προηγούμενο παράθυρο, θα βγει κάπως έτσι

Υποθέτω ότι πρόκειται για σφάλμα λογισμικού, ο σύνδεσμος προς την εφαρμογή υπάρχει ήδη. [ο συγγραφέας δεν παρείχε σύνδεσμο, - περίπου. μεταφράστης]

Γρήγορη επιδιόρθωση: Προσθέστε ένα κουμπί "Κατάργηση εγκατάστασης" εάν το πακέτο είναι ήδη εντός /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/ Προσθήκη στο καλάθι:

Η έκτη μέρα μου με το Haiku: κάτω από την κουκούλα των πόρων, των εικονιδίων και των πακέτων
Αυτό συμβαίνει όταν προσπαθείτε να αφαιρέσετε μια εφαρμογή που έχει ληφθεί από ένα αρχείο .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 για κάποιον που είναι εξοικειωμένος με τα εσωτερικά του Haiku, περίπου 15 λεπτά είναι αρκετά. Δεν είναι τόσο δύσκολο να προσθέσετε υποστήριξη για αυτό εάν υπάρχει πραγματική ανάγκη για αυτό. Αλλά για μένα αυτό είναι σπάνιο.

Ας κρατήσουμε την αναπνοή μας μέχρι το επόμενο άρθρο αυτής της σειράς.

Μετακίνηση πακέτων σε ξεχωριστή τοποθεσία

Όπως έγραψα νωρίτερα, θέλω να βάλω τα πακέτα μου .hpkg (καλά, ή μέρος τους) σε μια ειδική θέση, ξεχωριστή από τη συνηθισμένη τοποθέτηση στον τόμο εκκίνησης (κατάτμηση ρίζας). Στη συνηθισμένη (όχι και τόσο θεωρητική) περίπτωση, ο λόγος για αυτό είναι ότι οι (ενσωματωμένες) μονάδες μου ξεμένουν συνεχώς από ελεύθερο χώρο, όσο μεγάλοι κι αν είναι. Και συνήθως αντιστοιχίζω εξωτερικές μονάδες δίσκου ή κοινόχρηστα στοιχεία δικτύου όπου βρίσκονται οι εφαρμογές μου.

Σε Mac απλά μετακινώ πακέτα .app σε μια αφαιρούμενη μονάδα δίσκου ή κατάλογο δικτύου στο Finder, και αυτό είναι. Μπορώ ακόμα να κάνω διπλό κλικ για να ανοίξω την εφαρμογή όπως κάνω συνήθως από τον τόμο εκκίνησης. Μόλις!

Στο χαϊκού, όπως μου είπαν, αυτό μπορεί να επιτευχθεί με τη μετακίνηση μου .hpkg πακέτα σε μια αφαιρούμενη μονάδα δίσκου ή κατάλογο δικτύου, αλλά στη συνέχεια πρέπει να χρησιμοποιήσετε ορισμένες εντολές χωρίς έγγραφα στην κονσόλα για να τις προσαρτήσετε στο σύστημα. Δεν ξέρω πώς να το κάνω χρησιμοποιώντας μόνο GUI.

Ο Mac κερδίζει αυτήν την κατηγορία.

Σύμφωνα με τον κ. waddlesplash:

Αυτή είναι μια βελτιστοποίηση που βασίζεται στην κανονική χρήση. Εάν υπάρχει ζήτηση για περισσότερους από έναν χρήστες, θα την υλοποιήσουμε. Σε κάθε περίπτωση υπάρχει η δυνατότητα υλοποίησης από τρίτους.

Θα μιλήσουμε για αυτό στο επόμενο άρθρο.

Μιλώντας για καταλόγους δικτύου: θα ήταν υπέροχο (υποθέτω τα μέρη LAN) να υπάρχουν απλές, ανιχνεύσιμες εφαρμογές σε όλο το δίκτυο (π.χ. από το Zeroconf) που μπορούν να αντιγραφούν σε έναν τοπικό υπολογιστή ή να εκτελούνται απευθείας από το τοπικό δίκτυο. Φυσικά, οι προγραμματιστές έχουν τη δυνατότητα να εξαιρεθούν μέσω app_flags.

Τελική αναφορά για την ενοποίηση του συστήματος hpkg με το GUI

Νομίζω ότι αυτό οφείλεται κυρίως στη σχετική καινοτομία της ολοκλήρωσης .hpkg με το GUI αφήνει ακόμα πολλά να είναι επιθυμητά. Τέλος πάντων, υπάρχουν μερικά πράγματα που θα μπορούσαν να βελτιωθούν όσον αφορά το UX…

Κάτι ακόμα: Kernel Debug Land

Θα ήταν υπέροχο να μπορούμε να εισάγουμε εντολές κατά τη διάρκεια πανικού του πυρήνα, για παράδειγμα syslog | grep usb. Λοιπόν, στο Haiku είναι δυνατό χάρη στο Kernel Debug Land. Πώς μπορείτε να δείτε αυτή τη μαγεία σε δράση εάν όλα λειτουργούν όπως θα έπρεπε για εσάς χωρίς να εμπλακείτε σε πανικό στον πυρήνα; Εύκολα πατώντας Alt+PrintScn+D (Debug mnemonic). Θυμάμαι αμέσως Κλειδί προγραμματιστή, που επέτρεψε στους αρχικούς προγραμματιστές 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, που δημιουργούνται καθημερινά. Για εγκατάσταση, απλώς κατεβάστε την εικόνα και εγγράψτε την σε μια μονάδα flash USB χρησιμοποιώντας Χαράκτης

Έχετε ερωτήσεις; Σας προσκαλούμε στο ρωσόφωνο κανάλι τηλεγραφήματος.

Επισκόπηση σφάλματος: Πώς να πυροβολήσετε τον εαυτό σας στο πόδι σε C και C++. Συλλογή συνταγών Haiku OS

Από ο συγγραφέας Μετάφραση: Αυτό είναι το έκτο άρθρο της σειράς Haiku.

Λίστα άρθρων: Πρώτα Η δεύτερη Третья Τέταρτον Πέμπτο

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο