TL;DR: Haiku — een besturingssysteem dat speciaal is ontwikkeld voor pc's, en het heeft daarom een aantal trucjes die de werkomgeving veel beter maken dan die van andere. Maar hoe werkt het?
ontdekte ik Haiku, een onverwacht goede systeem. Ik ben nog steeds onder de indruk van hoe soepel het draait, vooral in vergelijking met de werkomgevingen op Linux. Vandaag ga ik onder de motorkap kijken. Waar nodig zal ik vergelijken met de originele Macintosh, Mac OS X en de werkomgevingen van Linux (de standaard XDG van freedesktop.org).
Resources in ELF-bestanden
Gisteren ontdekte ik dat IconOMatic in staat is om pictogrammen op te slaan in rdef-resources in uitvoerbare ELF-bestanden. Vandaag wil ik kijken hoe het in werkelijkheid werkt.
Resources? van , de oorspronkelijke auteur van het Macintosh Finder-programma en de 'vader' van de Macintosh Resource Manager:
Ik maak me zorgen over de rigide aard van traditioneel coderen. Voor mij is het idee van een applicatie die vastligt in code, zonder de mogelijkheid om iets dynamisch te wijzigen, een enorme achteruitgang. Er moet zoveel mogelijk gewijzigd kunnen worden tijdens de uitvoeringstijd. Natuurlijk kan de code van de applicatie zelf niet worden gewijzigd, maar is er niet iets wat zonder het opnieuw compileren van de code kan worden aangepast?
Op de originele Macintosh is het zo gedaan dat deze bestanden een 'datasectie' en een 'resourcesectie' hebben, wat het ongelooflijk gemakkelijk maakte om verschillende dingen, zoals pictogrammen, vertalingen, enz., op te slaan in uitvoerbare bestanden.
Op de Mac wordt hiervoor , een grafische applicatie voor — verrassend genoeg — het bewerken van resources, gebruikt.
ResEdit op de originele Macintosh
Maakte het mogelijk om pictogrammen, menu-items, vertalingen, enz. relatief eenvoudig te bewerken, maar ze 'reizen' nog steeds mee met de applicaties.
In elk geval had deze aanpak een groot nadeel: het werkte alleen op Apple-bestandssystemen, wat een van de redenen werd waarom Apple afstapte van de 'resourcesectie' bij de overstap naar Mac OS X.
Op Mac OS X wilde Apple een oplossing die onafhankelijk was van het bestandssysteem, en dus werd het concept van pakketten (van NeXT) toegepast, waarbij mappen door de bestandsbeheerder als 'ondoorzichtige objecten' worden behandeld, net als bestanden en niet als mappen. Elk pakket met een applicatie in het .app formaat heeft, onder andere, een bestand Info.plist (in een soortgelijke structuur als JSON of YAML van Apple), dat de metadata van de applicatie bevat.
Sleutels van het Info.plist-bestand in het Mac OS X-toepassingspakket.
Hulpmiddelen, zoals pictogrammen, UI-bestanden en andere, worden als bestanden in het pakket opgeslagen. Het concept is feitelijk teruggekeerd naar de oorsprong in NeXT.
Mathematica.app op NeXTSTEP 1.0 in 1989: wordt weergegeven als een map met bestanden in de terminal, maar als een enkel object in de grafische bestandsbeheerder.
Laten we teruggaan naar BeOS, waarop Haiku is gebaseerd. De ontwikkelaars hebben bij de overgang van PEF (PowerPC) naar ELF (x86) (dezelfde als die op Linux wordt gebruikt) besloten om een resource-sectie aan het einde van ELF-bestanden toe te voegen. Hiervoor werd geen eigen juiste ELF-sectie gebruikt, deze werd gewoon aan het einde van het ELF-bestand toegevoegd. Hierdoor hebben programma's strip en andere van binutils, die daar niets van weten, deze gewoon weggesneden. Daarom is het beter om niet met Linux-tools te werken als je resources aan een ELF-bestand op BeOS toevoegt.
Wat gebeurt er momenteel met Haiku? In principe is het min of meer hetzelfde.
Theoretisch zou je resources in de juiste ELF-sectie kunnen plaatsen. Volgens de ontwikkelaars op het kanaal #haiku in het netwerk irc.freenode.net:
Met ELF zou de sectie meer zin hebben... de enige reden waarom we dit niet doen, is dat we het in BeOS zo deden.
En dat zou je nu niet moeten veranderen.
Resourcebeheer
Resources worden geschreven in een gestructureerd 'resource'-formaat: dit is in feite een lijst van resources met groottes en daarna hun inhoud. Ik herinner me .
Hoe kun je de resources in Haiku controleren? Is er iets zoals ResEdit?
Volgens :
Om de resources die bij het toepassingspakket worden geleverd te bekijken, kun je het uitvoerbare bestand naar een programma zoals . Je kunt ook de terminal openen en het commando uitvoeren
listres bestandsnaam..
Resourcer is beschikbaar in HaikuDepot, maar bij mij crasht het gewoon.
Hoe kun je resources in ELF-bestanden beheren? Gebruikmakend van rsrc en rdef. rdef de bestanden worden gevestigd in rsrc. Het bestand rdef wordt opgeslagen in een gewoon tekstformaat, waardoor het veel gemakkelijker is om mee te werken. Het bestand in het formaat rsrc wordt aan het einde van het ELF-bestand toegevoegd. Laten we proberen te spelen:
~> rc -h
Haiku Resource Compiler 1.1Om een rdef-script in een resourcebestand te compileren:
rc [opties] [-o ] ...Om een resourcebestand terug te converteren naar een rdef-script:
rc [opties] [-o ] -d ...Opties:
-d --decompile maak een rdef-script van een resourcebestand
--auto-names construct resources namen uit ID-symbolen
-h --help toon dit bericht
-I --include voeg toe aan de lijst van includepaden
-m --merge wis de bestaande inhoud van het uitvoerbestand niet
-o --output specificeer de naam van het uitvoerbestand, standaard is out.xxx
-q --quiet geen foutmeldingen weergeven
-V --version toon softwareversie en licentieJe kunt het programma xres gebruiken. voor controle en beheer:
/> 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.
(...)Nou, laten we het proberen?
/> 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_VERSIONMeer over resources en het formaat rdef kan hier worden gelezen .
Standaard resource types
Hoewel je alles in resources kunt plaatsen, zijn er een paar specifieke standaard types:
app_signature: MIME-type van de applicatie, voor het koppelen van openende bestanden, uitvoeren, IPC, enz.app_name_catalog_entry: Aangezien de naam van de applicatie meestal in het Engels is, kan hier worden gespecificeerd waar de vertaalde namen zich bevinden, zodat gebruikers van verschillende talen desgewenst de vertaalde naam van de applicatie kunnen zien.app_version: precies wat je dachtapp_flags: geeft aanregistrarhoe de applicatie te behandelen. Ik denk dat er meer aan de hand is dan het op het eerste gezicht lijkt. Bijvoorbeeld, er isB_SINGLE_LAUNCH, dat het systeem dwingt om elke keer dat de gebruiker het vraagt een nieuw proces van de applicatie te starten (dezelfde principe wordt gebruikt voor de meeste applicaties op Linux). Er isB_MULTIPLE_LAUNCH, wat een proces start voor elk bestand. Tenslotte is erB_EXCLUSIVE_LAUNCH, dat het systeem dwingt om slechts één proces tegelijk uit te voeren, ongeacht hoe vaak gebruikers het starten (bijvoorbeeld, hetzelfde gebeurt met Firefox op Linux; hetzelfde resultaat kan worden bereikt in Qt-applicaties door de functie ). Applicaties metB_EXCLUSIVE_LAUNCHworden geïnformeerd wanneer een gebruiker probeert ze opnieuw te starten: bijvoorbeeld, ze ontvangen het pad naar het bestand dat de gebruiker wil openen met behulp van hen.vector_icon: Vectoricoon van de applicatie (In BeOS waren er geen vectoriconen, de meeste applicaties hadden in plaats daarvan twee rastericonen in uitvoerbare bestanden).
Natuurlijk kunnen resources met elke gewenste ID en type worden toegevoegd, waarna ze in de applicatie of andere applicaties kunnen worden gelezen met behulp van de klasse BResources. Maar laten we in eerste instantie stilstaan bij het fascinerende onderwerp van iconen.
Vectoriconen in Haiku-stijl
Natuurlijk heeft niet alleen Haiku het beste icontype gekozen, de situatie met desktopomgevingen in Linux is in dit deel verre van ideaal:
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.cacheKijkend naar zoiets kan je al voelen, wat dat stuk is.
Zeker, er zijn schaalbare, die zoals te begrijpen is, vectoricoontjes bevatten. Waarom is er dan nog iets anders? Omdat het resultaat van het renderen van vectorgraphics op kleine formaten slechter kan zijn dan ideaal. Je wilt verschillende varianten hebben, geoptimaliseerd voor verschillende afmetingen. In Linux-werkomgevingen wordt dit bereikt door icoontjes met verschillende groottes in het bestandssysteem te verspreiden.
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.pngLet op: er is geen concept van verschillende versies van Firefox. Het is dus niet mogelijk om de situatie met meerdere versies van de applicatie in het systeem verfijnd te verwerken.
Verschillende icoontjes van Firefox in verschillende versies. Tot nu toe is het onmogelijk om dit in Linux te verwerken zonder verschillende workaround.
Mac OS X verwerkt het iets verfijnder:
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.icnsHet is zichtbaar dat er één bestand is, firefox.icns in het pakket Firefox.app, dat alle groottes bevat, zodat verschillende versies van dezelfde applicatie verschillende icoontjes hebben.
Veel beter! Icoontjes reizen samen met de applicatie, alle bronnen in één bestand.
Laten we teruggaan naar Haiku. Een verbluffende oplossing, zonder uitzonderingen. Volgens :
Er is een speciale, hoog-geoptimaliseerde indeling voor kleine groottes en snelle rendering ontwikkeld, HVIF. Daarom zijn onze icoontjes over het algemeen veel kleiner dan in raster- of in het algemeen gebruikte SVG-formaat.
En ze zijn daadwerkelijk geoptimaliseerd:
Icoonformaten in HVIF vergeleken met andere formaten.
Het verschil is een orde van grootte!
Maar de magie eindigt hier niet. Dezelfde HVIF kan verschillende detailniveaus tonen, afhankelijk van de weergegeven grootte, ondanks dat het een vectorformaat is.
Verschillende detailniveaus (LOD) afhankelijk van de renderinggrootte.
Nu over de nadelen: je kunt SVG niet zomaar in ImageMagick stoppen en klaar zijn, je moet verschillende cycli doorlopen om een icoontje in HVIF-formaat te maken. Uitleg. Echter, IconOMatic kan SVG niet perfect importeren; ongeveer 90% van de details van SVG worden met een zekere kans geïmporteerd, de overige 10% moeten handmatig worden aangepast en gewijzigd. Lees meer over hoe HVIF zijn magie doet in de blog
Een icoon aan de applicatie toevoegen
Nu kan ik een icoon aan het pakket toevoegen dat is gemaakt , rekening houdend met alle verkregen informatie.
Aangezien ik op dit moment niet echt de zin heb om mijn eigen pictogram voor mijn "Hallo, Wereld" QtQuickApp te tekenen - pak ik het uit 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 CreatorLaten we controleren of het pictogram is gekopieerd:
/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- --------------------
'VICN' 101 152238 BEOS:ICONHet ziet er goed uit, maar waarom wordt het nieuwe pictogram niet weergegeven nadat het is gekopieerd?
Gekopieerde VICN:101:BEOS:ICONs wordt momenteel niet gebruikt als pictogram voor de applicatie in de bestandsbeheerder.
Wat heb ik gemist?
Reactie van de ontwikkelaar:
Ik moet een bestand maken
rdefmet alle bronnen, daarna de opdracht uitvoerenrc naam.rdef, dit zal een bestand maken.rsrc. Vervolgens moet ik de opdracht uitvoerenresattr -o naam_binaire naam.rsrc. In ieder geval gebruik ik dergelijke opdrachten om pictogrammen aan mijn scripts toe te voegen.
Nou, ik wilde eigenlijk een bron creëren, geen attribuut. Ik ben echt in de war.
Slimme caching met behulp van het bestandssysteem.
Het openen en lezen van ELF-attributen gaat langzaam. Zoals ik hierboven al heb geschreven, wordt het pictogram als een bron in het bestand geschreven. Deze methode is betrouwbaarder en overleeft het kopiëren naar een ander bestandssysteem. Maar daarna wordt het ook gekopieerd naar het attribuut van het bestandssysteem, bijvoorbeeld BEOS:ICON. Dit werkt alleen op bepaalde bestandssystemen, zoals BFS. De pictogrammen die door het systeem worden weergegeven (in Tracker en Deskbar), worden vanaf dit uitgebreide attribuut gelezen, omdat dergelijke oplossingen snel werken. Op sommige plaatsen (waar snelheid niet belangrijk is, bijvoorbeeld het typische venster "Over"), krijgt het systeem het pictogram rechtstreeks uit de bron in het bestand. Maar dit is nog niet het einde. Vergeet niet, op de Mac konden gebruikers pictogrammen van applicaties, mappen en documenten vervangen door hun eigen, aangezien de Mac de mogelijkheid biedt om deze "belangrijke" dingen te doen, bijvoorbeeld . In Haiku moet je de bron (in het bestand) beschouwen als het oorspronkelijke pictogram dat met de applicatie wordt geleverd, en het attribuut (in het BFS-bestandssysteem) als iets dat de gebruiker in staat stelt om wijzigingen aan te brengen als dat nodig is (hoewel, tip, de grafische interface om een aangepast pictogram boven het standaardpictogram te plaatsen is voorlopig nog niet gerealiseerd).
Controle van de bestandssysteemattributen
Met resaddr er is een mogelijkheid om de bestandssysteemattributen te controleren en in te stellen.
/> 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.
(...)Eigenlijk is dit de 'lijm' die de conversie heen en weer uitvoert tussen (betrouwbare) bronnen en (snelle) kenmerken van het bestandssysteem. Aangezien het systeem echter automatisch bronnen verkrijgt en kopieert, maak ik me daar verder geen zorgen meer over.
De magie van hpkg-pakketten
Tegenwoordig worden programma's op Haiku meestal verkregen via pakketten .hpkg. Laat je niet misleiden door de simpele naam: het .hpkg-formaat werkt heel anders dan andere formaten met vergelijkbare namen waarmee je te maken hebt gehad, en het heeft echte superkrachten.
Bij traditionele pakketformaten was ik lange tijd gefrustreerd door het feit dat je het ene (pakket) downloadt, maar er iets anders (bestanden binnen het pakket) in het systeem wordt geïnstalleerd. Het is behoorlijk lastig om met bestanden om te gaan (bijvoorbeeld ze te verwijderen) wanneer een pakket op de traditionele manier wordt geïnstalleerd. Dit komt omdat de inhoud van het pakket verspreid is over het hele bestandssysteem, inclusief locaties waar de gewone gebruiker mogelijk geen schrijfrechten heeft. Dit creëert een hele klasse programma's — pakketbeheerders. Het verplaatsen van reeds geïnstalleerde software, bijvoorbeeld naar een andere machine, een verwijderbare schijf of een bestandsserver, wordt nog moeilijker, of zelfs onmogelijk. In een standaard Linux-systeem kunnen gemakkelijk enkele honderden duizenden tot miljoenen afzonderlijke bestanden bestaan. Uiteraard is dit zowel fragiel als traag, bijvoorbeeld tijdens de initiële systeeme installatie, bij de installatie, update en verwijdering van reguliere pakketten, en bij het kopiëren van de opstartpartitie (hoofdpartitie) naar een ander medium.
Ik werk aan het AppImage-project, een gedeeltelijke oplossing voor eindgebruikersapplicaties. Dit is een distributieformaat dat de applicatie en al zijn afhankelijkheden bundelt in één bestandssysteemafbeelding die wordt gemonteerd bij het starten van de applicatie. Het vereenvoudigt zaken aanzienlijk, aangezien dezelfde ImageMagick plotseling in één bestand verandert, dat door gewone stervelingen in de bestandsbeheerder kan worden beheerd. De voorgestelde methode werkt alleen voor software, zoals de naam van het project aangeeft, en heeft ook zijn eigen set kwaaltjes, omdat mensen die software voor Linux leveren altijd de schuld naar mij doorschuiven.
Laten we terugkeren naar Haiku. Is het gelukt om de optimale balans te vinden tussen traditionele pakketbeheersystemen en softwarelevering op basis van beelden? Haar pakketten .hpkg zijn in feite gecomprimeerde afbeeldingen van filesystemen. Wanneer het systeem opstart, monteert de kernel alle geïnstalleerde en actieve pakketten met ongeveer de volgende berichten van de kernel:
KERN: package_daemon [16042853: 924] actief pakket: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023: 924] actief pakket: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232: 924] actief pakket: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405: 924] actief pakket: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611: 924] actief pakket: "llvm_libs-5.0.0-3-x86_64.hpkg"Cool, nietwaar? Houd je vast, het wordt nog beter!
Er is een heel speciaal pakket:
KERN: package_daemon [16040020: 924] actief pakket: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"Het bevat een vrij minimalistisch besturingssysteem, inclusief de kernel. Gelooft u het of niet, maar zelfs de kernel zelf wordt niet uitgepakt uit de opstartschijf (rootpartitie), maar wordt netjes op zijn plek geladen vanuit het pakket. .hpkgWow! Ik heb al eerder gezegd dat, naar mijn mening, een deel van de algehele verfijning en consistentie van Haiku voortkomt uit het feit dat het hele systeem, van de kernel en de basis gebruikersruimte tot het pakketbeheer en de infrastructuur van de werkruimte, gezamenlijk door één team wordt ontwikkeld. Stel je voor hoeveel verschillende groepen en teams nodig zijn om iets dergelijks op Linux te realiseren. [ik stel me het PuppyLinux-project voor, — opmerking van de vertaler]. Stel je vervolgens voor hoeveel tijd het zou kosten om deze aanpak in distributies door te voeren. Men zegt: neem een eenvoudige taak, verdeel deze onder verschillende uitvoerders, en het wordt zo gecompliceerd dat het niet meer op te lossen is. Haiku heeft me in dit opzicht de ogen geopend. Ik denk dat dit precies is wat er momenteel met Linux gebeurt (Linux is in dit geval een verzamelterm die de stack Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu aanduidt).
Systeemherstel met behulp van hpkg
Hoe vaak gebeurt de volgende situatie: de update is met succes voltooid, maar dan blijkt dat iets niet werkt zoals het zou moeten? Bij het gebruik van standaard pakketbeheerders is het moeilijk om de status van het systeem terug te brengen naar het moment vóór de installatie van nieuwe pakketten (bijvoorbeeld wanneer er iets misgaat). Sommige systemen bieden alternatieven in de vorm van snapshots van het bestandssysteem, maar deze zijn behoorlijk omslachtig en worden niet in alle systemen toegepast. In Haiku wordt dit opgelost met pakketten. .hpkgElke keer wanneer pakketten in het systeem worden gewijzigd, worden de oude pakketten niet verwijderd, maar opgeslagen in submappen zoals /Haiku/system/packages/administrative/state-<...>/ doorlopend. Onvoltooide bewerkingen bewaren hun gegevens in submappen. /Haiku/system/packages/administrative/transaction-<...>/.
Inhoud /Haiku/system/packages/administrativeDe mappen 'state...' bevatten tekstbestanden met de namen van actieve pakketten, 'transaction...' bevat de pakketten zelf.
De 'oude actieve status', dat wil zeggen de lijst van .hpkg pakketten die actief waren vóór de wijzigingen, wordt na elke bewerking opgeslagen in de bestandsbeheerder in een tekstbestand. /Haiku/system/packages/administrative/state-<...>/activated-packagesOp dezelfde manier wordt de nieuwe 'actieve status' in een tekstbestand opgeslagen. /Haiku/system/packages/administrative/activated-packages.
Map /Haiku/system/packages/administrative/state-<...>/ bevat alleen een tekstbestand met de lijst van actieve pakketten in deze status (in het geval van installatie van pakketten zonder verwijdering), en als pakketten verwijderd of bijgewerkt zijn, bevat de state-map oude versies van de pakketten.
Bij het opstarten van het systeem wordt op basis van de lijst met pakketten beslist over de activatie (mounting) van pakketten. Zo simpel is het! Als er iets misgaat tijdens het opstarten, kan de opstartbeheerder worden gevraagd om een andere, oudere lijst te gebruiken. Probleem opgelost!
De opstartprogramma van Haiku. Elk toegangspunt weerspiegelt de bijbehorende 'actieve status'.
Ik hou van de aanpak met eenvoudige tekstbestanden als lijst van 'actieve status', waarin begrijpelijke namen zijn vastgelegd. .hpkgDit staat in schril contrast met de door machines gemaakte rommel die niet voor mensen bedoeld is. De lijst met actieve pakketten voor elk moment in de tijd.
Configuratiegegevens.
Blijkbaar bevat de map
instellingenbestanden voor pakketten, maar deze zijn bereikbaar voor schrijfbevoegdheden. Immers, zoals je je herinnert, /Haiku/system/packages/administrative/writable-files worden alleen-lezen gemonteerd. Deze bestanden moeten dus worden gekopieerd vanuit de pakketten voordat ze kunnen worden geschreven. Dit heeft zin. .hpkg Integratie van de GUI voor het systeem .hpkg.
GUI-integratie voor het .hpkg-systeem
Laten we nu eens kijken hoe deze schitterende pakketten .hpkg omgaan met integratie in de gebruikersomgeving (UX). Want Haiku is tenslotte bedoeld voor persoonlijk gebruik. Persoonlijk heb ik de lat hoog gelegd door de gebruikerservaring te vergelijken met pakketten .app op Macintosh met een soortgelijke ervaring op .hpkg. Ik ga de situatie met desktopomgevingen op Linux niet eens vergelijken, omdat die absoluut verschrikkelijk is in vergelijking met andere.
De volgende scenario's komen in me op:
- Ik wil de inhoud van een pakket bekijken
.hpkg - Ik wil een pakket installeren
- Ik wil een pakket verwijderen
- Ik wil iets verwijderen dat als onderdeel van een pakket in het systeem is gekomen
- Ik wil iets kopiëren dat als onderdeel van een pakket in het systeem is gekomen
- Ik wil alle afhankelijkheden van een pakket downloaden die misschien geen onderdeel kunnen zijn van elke installatie van Haiku (bijvoorbeeld, ik heb een fysiek geïsoleerde machine zonder internettoegang).
- Ik wil mijn pakketten (nou, of een deel ervan) afzonderlijk naar een andere locatie verplaatsen, apart van de opstartschijf (de rootpartitie) (omdat ik bijvoorbeeld daar niet genoeg ruimte voor heb).
Dit zou de meeste belangrijke gevallen van mijn dagelijkse werkzaamheden moeten dekken. Goed, laten we beginnen.
De inhoud van een pakket controleren
Op de Mac klik ik gewoon met de rechtermuisknop op het pakket om het te openen en de inhoud in Finder te bekijken. Het is immers gewoon een gemaskeerde map! (Ik weet dat er pakketten .pkg zijn voor systeemonderdelen die geen toepassingen zijn, maar gewone gebruikers komen daar meestal niet mee in aanraking).
Op Haiku klik ik met de rechtermuisknop op het pakket en dan op 'Contents' om te zien wat erin zit. Maar hier is gewoon een lijst met bestanden zonder de mogelijkheid om ze dubbel te klikken om ze te openen.
Het zou veel beter zijn als er een manier was om (tijdelijk) het pakket te monteren .hpkg voor weergave via de bestandsbeheerder, zonder dat de gebruiker zich moet bekommeren om de implementatiedetails. (Trouwens, je kunt een .hpkg pakket openen in Expander, dat het kan uitpakken zoals elk ander archief).
In de interface van HaikuDepot kun je een lijst van de bestanden van het pakket bekijken, maar er is geen manier om de inhoud te bekijken, bijvoorbeeld door dubbel te klikken op README.md.
In deze categorie wint de Mac, maar het toevoegen van de benodigde functionaliteit aan HaikuDepot zou niet te veel moeite moeten kosten.
Een pakket installeren via de GUI
Op de Mac, de meeste schijfafbeeldingen .dmg bevatten pakketten .app. We openen de schijfafbeelding met een dubbele klik, waarna we het pakket kopiëren, bijvoorbeeld door het te slepen naar /Applications Finder. Voor mij is dit vanzelfsprekend, maar ik heb gehoord dat sommige nieuwkomers dit misschien niet kunnen begrijpen. Standaard 'suggereert' Apple een algemene systeembibliotheek /Applications (op NeXT was dit netwerkgerelateerd en ook persoonlijk), maar je kunt je applicaties eenvoudig op een bestandenserver of in een submap plaatsen $HOME/Applications, als je dat wilt.
Op Haiku, dubbelklik op het pakket, klik daarna op 'Install', eenvoudiger kan niet. Ik vraag me af wat er gebeurt als een pakket afhankelijkheden heeft die beschikbaar zijn in HaikuPorts, maar nog niet zijn geïnstalleerd. Op Linux weten ze in feite niet wat ze in deze situatie moeten doen, maar de oplossing is duidelijk - vraag de gebruiker of ze de afhankelijkheden willen downloaden en installeren. Precies wat Haiku doet.
Ik heb het pakket ‘sanity’ handmatig gedownload en er op geklikt, de pakketbeheerder weet waar hij de afhankelijkheden kan ophalen (op voorwaarde dat de repositories al in het systeem zijn ingesteld). Niet elke Linux-distributie kan dat.
Een andere manier is het gebruik van een bestandsbeheerder, je hoeft alleen maar het .hpkg pakket te slepen naar /Haiku/system/packages (voor algemene systeeminstallatie, standaard), of naar /Haiku/home/config/packages (voor persoonlijke installatie; niet beschikbaar bij dubbele klik - het irriteert me nog steeds dat het woord 'config' op deze plek staat, wat voor mij in dit geval synoniem is voor 'instellingen'). En de conceptie van meerdere gebruikers is nog niet beschikbaar voor Haiku (misschien is dat de reden waarom alles zo eenvoudig is - ik weet het niet, misschien zullen meergebruikersmogelijkheden de zaken compliceren voor de werkomgeving van een persoonlijke computer).
In deze categorie wint Haiku, omdat het niet alleen met applicaties, maar ook met systeemprogramma's kan werken.
Verwijderen van een pakket uit de GUI
Op de Mac, je hoeft alleen maar het pictogram van de applicatie naar de prullenbak te slepen, en dat is het. Eenvoudig!
Op Haiku, ten eerste moet je vinden waar het pakket zich in het systeem bevindt, omdat je het zelden op de juiste plek installeert (dat doet het systeem). Gewoonlijk moet je zoeken in /Haiku/system/packages (bij een algemene systeeminstallatie standaard), of in /Haiku/home/config/packages (ik heb al gezegd dat 'config' een verkeerde naam is?). Daarna wordt de applicatie gewoon naar de prullenbak gesleept, en dat is het.
Eenvoudig! Maar ik zou dat niet zeggen. Dit is wat er eigenlijk gebeurt:
Dit is wat er gebeurt als je een app naar de prullenmand sleept vanuit /Haiku/system/packages
Ik probeerde gewoon mijn gisterochtend-app 'Hallo, wereld' op QtQuickApp naar de prullenmand te verplaatsen. Ik heb de systeemmap niet geprobeerd te verplaatsen, en omdat alle pakketten in de systeemmap worden geïnstalleerd, is het onmogelijk om een pakket te verwijderen .hpkg zonder wijzigingen aan ‘de inhoud ervan’. Een gewone gebruiker zou zich hiervan angstig voelen en op de standaard ingestelde knop 'Annuleren' klikken.
Geeft uitleg over :
Dit bericht is al meer dan 10 jaar oud. We moeten het waarschijnlijk zo instellen dat de waarschuwing alleen verschijnt bij het verplaatsen van het pakket zelf. Gewone gebruikers hoeven dit in ieder geval niet te doen.
Nou, misschien moeten we dit doen met HaikuDepot? Ik dubbelklik op het pakket in /Haiku/system/packages, in de verwachting dat de knop 'Verwijderen' verschijnt. Nope, er is alleen 'Installeren'. 'Verwijderen', waar ben je?
Uit nieuwsgierigheid heb ik geprobeerd te kijken wat er gebeurt als ik 'Installeren' klik voor een al geïnstalleerd pakket. Het wordt als volgt:
Dit is wat er gebeurt als je probeert een al geïnstalleerd pakket te installeren.
Dan verschijnt:
Als je op 'Toepassen' in het vorige venster klikt, krijg je dit
Ik neem aan dat dit een softwarefout is, er is al een link naar het verzoek. [de auteur heeft geen link gegeven, — opmerking van de vertaler]
Snelle oplossing: Voeg een knop 'Verwijderen' toe als het pakket al in
/Haiku/system/packages, of in/Haiku/home/config/packages.
Wanneer ik de lijst met pakketten in HaikuDepot bekijk, zie ik mijn pakket in de lijst en kan ik het verwijderen.
In deze categorie wint Mac. Maar ik kan me voorstellen dat de gebruikerservaring op Haiku beter kan zijn dan op Mac met de juiste instellingen. (Een van de ontwikkelaars schatte het zo in: 'Minder dan een uur om de genoemde functionaliteit aan HaikuDepot toe te voegen, als je een beetje weet van C++', zijn er vrijwilligers?)
Het verwijderen van iets uit een pakket
Laten we proberen de applicatie zelf te verwijderen, en niet het pakket .hpkg, waaruit het is ontstaan (ik betwijfel of er voor 'gewone stervelingen' een verschil is).
Op de Mac, de gebruiker werkt meestal daadwerkelijk met het bestand .dmg, waaruit het applicatiepakket komt .app. Meestal worden afbeeldingen .dmg opgeslagen in de downloadmap, pakketten worden door de gebruiker in /Applications. Er is de mening dat veel gebruikers zelf niet weten wat ze doen, deze hypothese wordt bevestigd door een voormalig werknemer van Apple. (Een van de dingen die ik niet leuk vind aan Mac. Bijvoorbeeld, met AppImage is er geen verschil tussen de applicatie en het pakket waarin het is verpakt. Slepen naar de prullenmand = dat is het. Makkelijk!)
Op Haiku, er is ook een scheiding tussen apps/ en packages/, dus ik betwijfel of het voor gebruikers duidelijker is geworden. Maar wat er gebeurt als je een applicatie uit apps/ in de prullenmand sleurt:
Dit is wat er gebeurt als je probeert een applicatie te verwijderen die uit een bestand is gehaald .hpkg
Technisch is het juist (want de applicatie is op de alleen-lezen bestandssysteem geplaatst in de eerste plaats), maar het is niet echt nuttig voor de gebruiker.
Snelle oplossing: bied in plaats daarvan aan om via de GUI te verwijderen
.hpkg
Voor de grap heb ik geprobeerd de applicatie te dupliceren door Alt+D in te drukken. Ik kreeg de melding “Kan objecten op een alleen-lezen volume niet verplaatsen of kopiëren”. En dat komt omdat /system (naast /system/packages en /system/settings) een mountpunt is van packagefs (weet je nog, hoe dat verschijnt in de output df?). К сожалению, вывод команды mount maakt de situatie niet duidelijker (zoals al in een van de vorige artikelen werd gezegd), mountvolume toont niet wat je zoekt (waarschijnlijk worden door loop gemounte pakketten .hpkg niet als ‘volumes’ beschouwd), en ik ben ook de alternatieve commando's vergeten.
In deze categorie heeft niemand gewonnen, behalve AppImage (maar dat is, om eerlijk te zijn, een bevooroordeeld oordeel). Maar men kan zich voorstellen dat na aanpassing, de gebruikerservaring op Haiku beter zal zijn dan op Mac.
Opmerking: het moet duidelijk worden wat een ‘volume’ betekent in relatie tot ‘een sectie’. Waarschijnlijk is het verwant aan de relatie van ‘map’ tot ‘catalogus’: de meeste catalogi worden in de bestandsbeheerder als mappen weergegeven, maar niet allemaal (bijvoorbeeld, pakketten die als bestanden worden behandeld). Maakt deze uitspraken me officieel een nerd?
De inhoud van het pakket naar een ander systeem kopiëren
Op de Mac, gewoon het pakket slepen .app, en aangezien de afhankelijkheden binnen het pakket - die worden samen verplaatst.
Op Haiku, ik sleep de applicatie, maar afhankelijkheden worden helemaal niet verwerkt.
Snelle oplossing: laat in plaats daarvan aanbieden om het pakket ‘`.hpkg in zijn geheel te slepen, samen met de afhankelijkheden, indien aanwezig.
In deze categorie wint Mac absoluut. Tenminste voor mij, als liefhebber van hun paradigma. Op Haiku zou er gekopieerd moeten worden. .hpkg in plaats van een applicatie, maar het systeem biedt me dat niet aan…
Het downloaden van het pakket met al zijn afhankelijkheden
Niet elke machine is constant verbonden met het netwerk. Integendeel, sommige machines (ja, ik kijk naar jullie, moderne Windows, Mac en Linux) vergeten dat. Voor mij is het belangrijk dat ik bijvoorbeeld naar een internetcafé kan gaan, software kan downloaden op een verwijderbare schijf, deze schijf in mijn thuismachine kan steken en er zeker van kan zijn dat alles werkt [risicozoekende jongen, zoiets op Windows doen… — vertaler opmerking].
Als resultaat krijg ik iets vaker dan normaal meestal onvervulde afhankelijkheden op Windows en Linux.
Op de Mac het is meestal één bestand, alles wat je hoeft te doen is downloaden .dmg. Meestal heeft het geen afhankelijkheden, behalve die welke standaard door macOS worden geleverd. Een uitzondering hierop zijn complexe applicaties die een specifieke runtime-omgeving vereisen, zoals Java.
Op Haiku download het pakket .hpkg voor bijvoorbeeld dezelfde Java-applicatie kan onvoldoende blijken te zijn, aangezien Java zowel aanwezig als afwezig kan zijn op de doelmachine. Is er een manier om alle afhankelijkheden voor dit pakket te downloaden .hpkg, behalve die welke standaard in Haiku worden geïnstalleerd en die daarom in elk Haiku-systeem aanwezig moeten zijn?
In deze categorie wint Mac met een kleine marge.
Commentaar van mr. waddlesplash:
Om een programma te schrijven dat alle afhankelijkheden van een applicatie verzamelt in de vorm van een set pakketten
.hpkgis voor iemand die vertrouwd is met de interne werking van Haiku zo'n 15 minuten werk. Ondersteuning hiervoor toevoegen is niet zo moeilijk als er een echte behoefte aan is. Maar voor mij is dat een zeldzame situatie.
Laten we de adem inhouden tot het volgende artikel in deze cyclus.
Pakketten verplaatsen naar een aparte locatie
Zoals ik eerder al schreef, wil ik mijn pakketten .hpkg (nou ja, of een deel ervan) op een speciale plek zetten, gescheiden van de gebruikelijke plaatsing op de opstartpartitie (de rootpartitie). Gewoonlijk (niet zo theoretisch) komt dat doordat de vrije ruimte op mijn (ingebouwde) schijven altijd opraakt, ongeacht hoe groot ze zijn. En ik koppel meestal externe schijven of netbronnen waar mijn applicaties staan.
Op de Mac verplaats ik gewoon de pakketten .app naar een externe schijf of netwerklocatie in Finder, en dat is alles. Ik kan de applicatie nog steeds dubbelklikken om deze te openen zoals ik dat gewoonlijk deed met het opstartvolume. Gewoon!
Op Haiku, zoals mij is verteld, kan dit worden bereikt door mijn .hpkg pakketten naar een externe schijf of netwerklocatie te verplaatsen, maar dan moet ik sommige niet-geïndocumenteerde commando's in de console gebruiken om ze in het systeem te koppelen. Ik weet niet hoe ik dit moet doen met alleen de GUI.
In deze categorie wint de Mac.
According to mr. waddlesplash:
Hier is de optimalisatie gericht op normaal gebruik. Als er echter meer vraag is dan van één gebruiker, zullen we dit realiseren. In ieder geval is er de mogelijkheid van een externe implementatie.
Hierover zullen we in het volgende artikel vertellen.
Wat betreft netwerklocaties: het zou geweldig zijn (ik veronderstel een LAN-feest) om eenvoudige, detecteerbare, netwerkapps (bijvoorbeeld via Zeroconf) te hebben die je naar de lokale computer kunt kopiëren of rechtstreeks vanuit het lokale netwerk kunt starten. Natuurlijk hebben ontwikkelaars de mogelijkheid om dit af te wijzen via app_flags.
Eindverslag over de integratie van het hpkg systeem met de GUI
Ik denk dat de integratie vooral vanwege de relatieve nieuwheid .hpkg met de GUI nog te wensen overlaat. In ieder geval zijn er verschillende dingen die verbeterd kunnen worden op het gebied van UX…
Nog een ding: Kernel Debug Land
Het zou geweldig zijn om bij een kernel panic commando's in te voeren, zoals syslog | grep usb. Nou, dat is mogelijk op Haiku dankzij Kernel Debug Land. Hoe zie je deze magie in actie als alles goed werkt zonder dat je in een kernel panic komt? Gemakkelijk, door Alt+PrintScn+D in te drukken (de mnemonische Debug). Ik herinner me onmiddellijk de , die de oorspronkelijke ontwikkelaars van Macintosh in staat stelde om in de debugger te komen (tenzij deze natuurlijk was geïnstalleerd).
Conclusie
Ik begin te begrijpen dat de verfijning van het Haiku-systeem voortkomt uit het feit dat het wordt ontwikkeld door een klein team met een duidelijke focus op de werkomgeving met bereikbaarheid van alle lagen van het systeem.
Een scherp contrast met de wereld van Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, waar alles in zulke kleine stukjes is verdeeld dat abstractie op abstractie zit en met krukken wordt voortgedreven.
Daarnaast is het ook duidelijk geworden hoe het systeem .hpkg de beste praktijken van traditionele pakketbeheerders, Snappy, Flatpak, AppImage, zelfs btrfs combineert, en deze mengt met het principe van 'gewoon werkt' van de Mac.
Alsof er iets in mijn hoofd is 'geschakeld', en ik begreep hoe het systeem .hpkg kan terugvallen, gewoon door ernaar te kijken. Maar het is niet ik, het is de schoonheid en eenvoud van het systeem. Veel hier is doordrenkt met de geest van de oorspronkelijke Mac.
Ja, pagina's bekijken in de browser kan haperen en werken als een slak, er kunnen niet genoeg toepassingen zijn (geen Gtk, Electron - de ontwikkelaars hebben geconcludeerd dat ze slecht samengaan met verfijning), video- en 3D-versnelling kan helemaal ontbreken, maar ik vind dit systeem toch leuk. Want deze zaken kunnen worden opgelost en ze zullen vroeg of laat verschijnen. Het is slechts een kwestie van tijd en misschien een beetje rode ogen.
Ik kan geen hulp bieden, maar ik denk dat vanaf dit moment het jaar Haiku op het bureaublad begint.
Willekeurige problemen
Misschien zijn er al aanvragen, of moet ik ze openen?
- BeScreenCapture zou moeten kunnen exporteren naar GIF, zoals in Peek. Dit kan gedaan worden met ffmpeg, dat al beschikbaar is voor Haiku. .
- Het programma voor het maken van screenshots kan geen screenshot van een modaal venster maken, en in plaats daarvan de hele scherm vastleggen.
- Screenshots kunnen niet worden bijgesneden met de bijsnijdtool in WonderBrush, en daarna - het resultaat opslaan in een bestand.
- Ik hou niet echt van de handcursor in Haiku, maar ik denk dat dit te maken heeft met warme nostalgische gevoelens. Het is vooral vervelend bij het gebruik van de bijsnijdtool in Krita, omdat het resulteert in een onnauwkeurige uitsnijding (zie screenshots met modale dialogen in dit artikel). Een cursor in de vorm van een kruis zou fantastisch zijn. .
Probeer het zelf! Het Haiku-project biedt imagebestanden voor opstarten vanaf DVD of USB, die dagelijks worden aangemaakt. Voor installatie is het voldoende om het image te downloaden en het op een USB-stick te branden met behulp van
Heb je vragen? We nodigen je uit in ons Russischtalige .
Foutoverzicht:
Vanaf vertaling: dit is het zesde artikel uit de cyclus over Haiku.
Lijst van artikelen:
Bron: habr.com
