TL; DR: Haiku is een besturingssysteem dat speciaal is ontworpen voor pc's, dus het heeft verschillende trucs die de desktopomgeving veel beter maken dan andere. Maar hoe werkt het?
Ik ontdekte Haiku, een onverwacht goed systeem. Ik ben nog steeds verbaasd over hoe soepel het werkt, vooral vergeleken met Linux-desktopomgevingen. Vandaag ga ik een kijkje nemen onder de motorkap. Waar nodig voor een diepgaand begrip zal ik vergelijkingen maken met de originele Macintosh-, Mac OS X- en Linux-desktopomgevingen (XDG-standaard van freedesktop.org).
Bronnen in ELF-bestanden
Gisteren heb ik geleerd dat IconOMatic pictogrammen in rdef-bronnen in ELF-uitvoerbare bestanden kan opslaan. Vandaag wil ik zien hoe het echt werkt.
Bronnen? van , de oorspronkelijke auteur van de Macintosh Finder en de "vader" van de Macintosh Resource Manager:
Ik maak me zorgen over het rigide karakter van traditionele codering. Voor mij is het idee van een applicatie die bevroren is in code, zonder de mogelijkheid om iets dynamisch te veranderen, de wildste wreedheid. Het moet mogelijk zijn om tijdens runtime zoveel mogelijk te wijzigen. Natuurlijk kan de applicatiecode zelf niet worden gewijzigd, maar er kan toch zeker iets worden gewijzigd zonder de code opnieuw te compileren?
Op de originele Macintosh hebben ze ervoor gezorgd dat deze bestanden een 'gegevenssectie' en een 'bronnensectie' hebben, waardoor het ongelooflijk eenvoudig werd om zaken als pictogrammen, vertalingen en dergelijke op te slaan. in uitvoerbare bestanden.
Op Mac wordt dit gebruikt , een grafisch programma voor het - ineens - bewerken van bronnen.
ResEdit op de originele Macintosh
Hierdoor werd het mogelijk om iconen, menu-items, vertalingen, etc. te bewerken. eenvoudig genoeg, maar ze ‘reizen’ nog steeds met de applicaties.
Hoe dan ook had deze aanpak een groot nadeel: het werkte alleen op Apple-bestandssystemen, wat een van de redenen was waarom Apple de 'bronnensectie' achterwege liet toen hij overstapte naar Mac OS X.
Op Mac OS X wilde Apple een bestandssysteem-onafhankelijke oplossing, dus adopteerden ze het concept van pakketten (van NeXT), mappen die door de bestandsbeheerder als "ondoorzichtige objecten" worden behandeld, zoals bestanden in plaats van mappen. Elk pakket met een applicatie in het formaat .app beschikt onder meer over een dossier Info.plist (in een soort Apple-equivalent van JSON of YAML) met metadata van applicaties.
Sleutels voor het bestand Info.plist uit het Mac OS X-toepassingspakket.
Bronnen, zoals pictogrammen, UI-bestanden en andere, worden als bestanden in het pakket opgeslagen. Het concept ging eigenlijk terug naar zijn roots in NeXT.
Mathematica.app op NeXTSTEP 1.0 in 1989: verschijnt als een map met bestanden in de terminal, maar als een enkel object in de grafische bestandsbeheerder.
Laten we terugkeren naar BeOS, de concepten waarop Haiku is gebaseerd. Toen de ontwikkelaars overstapten van PEF (PowerPC) naar ELF (x86) (hetzelfde als gebruikt op Linux), besloten ze een resource-sectie toe te voegen aan het einde van de ELF-bestanden. Het gebruikte geen eigen ELF-sectie, het werd eenvoudigweg aan het einde van het ELF-bestand toegevoegd. Als resultaat van het programma strip en anderen van binutils, die zich hiervan niet bewust waren, sneden het gewoon af. Daarom is het beter om bij het toevoegen van bronnen aan een ELF-bestand op BeOS het niet met Linux-tools te manipuleren.
Hoe is het nu met Haiku? In principe min of meer hetzelfde.
In theorie zou het mogelijk zijn om middelen in de gewenste sectie van het ELF te plaatsen. Volgens de ontwikkelaars op het #haiku-kanaal op irc.freenode.net:
Met ELF zou de sectie logischer zijn... de enige reden waarom we het niet op die manier doen is omdat we het in BeOS deden."
En het heeft geen zin om dit nu te veranderen.
авление есурсами
Bronnen worden geschreven in een gestructureerd ‘bronformaat’: in wezen een lijst met bronnen met de grootte en vervolgens hun inhoud. Ik herinnerde het me .
Hoe bronnen in Haiku controleren? Bestaat er zoiets als ResEdit?
Volgens :
Om de bronnen in het toepassingspakket te bekijken, kunt u het uitvoerbare bestand naar een programma als slepen . U kunt ook naar de terminal gaan en de opdracht uitvoeren
listres имя_файла.
Resourcer is beschikbaar in HaikuDepot, maar bij mij crasht het gewoon.
Hoe bronnen in ELF-bestanden beheren? Gebruik makend van rsrc и rdef. rdef bestanden worden verzameld in rsrc. Bestand rdef wordt opgeslagen in platte tekst, dus het is veel gemakkelijker om mee te werken. Bestandsformaat rsrc toegevoegd aan het einde van het ELF-bestand. Laten we proberen te spelen:
~> 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 licenseJe kunt het programma gebruiken xres voor controle en controle:
/> 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.
(...)Oké, 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 bronnen en format rdef jij kunt lezen .
Standaard resourcetypen
Hoewel u van alles in resources kunt stoppen, zijn er een paar gedefinieerde standaardtypen:
app_signature: MIME-toepassingstype, voor het openen van bestanden, starten, IPC, enz.app_name_catalog_entry: Omdat de applicatienaam meestal in het Engels is, kunt u de plaatsen opgeven waar de vertaalde namen zich bevinden, zodat gebruikers van verschillende talen desgewenst de vertaalde applicatienaam kunnen zien.app_version: precies wat je dachtapp_flags: duidt opregistrarhoe u de aanvraag moet verwerken. Ik denk dat er meer aan de hand is dan op het eerste gezicht lijkt. Dat is er bijvoorbeeldB_SINGLE_LAUNCH, waardoor het systeem wordt gedwongen een nieuw applicatieproces te starten telkens wanneer de gebruiker daarom vraagt (hetzelfde principe wordt gebruikt voor de meeste applicaties op Linux). EtenB_MULTIPLE_LAUNCH, waardoor het proces wordt uitgevoerd elk bestand. Eindelijk is dat zoB_EXCLUSIVE_LAUNCH, waardoor het systeem wordt gedwongen slechts één proces tegelijk te starten, ongeacht hoe vaak gebruikers het starten (dit is bijvoorbeeld hoe Firefox op Linux draait; hetzelfde resultaat kan worden bereikt in Qt-applicaties met behulp van de functie ). Toepassingen metB_EXCLUSIVE_LAUNCHkrijgen een melding wanneer de gebruiker ze opnieuw probeert uit te voeren: ze ontvangen bijvoorbeeld het pad van het bestand dat de gebruiker met zijn hulp wil openen.vector_icon: Vectorapplicatiepictogram (BeOS had geen vectorpictogrammen, de meeste applicaties hadden in plaats daarvan twee rasterpictogrammen in hun uitvoerbare bestanden).
Natuurlijk kunt u bronnen toevoegen met elke gewenste ID en type, en deze vervolgens in de applicatie zelf of in andere applicaties lezen met behulp van de klasse BResources. Maar laten we eerst eens kijken naar het fascinerende onderwerp iconen.
Vector iconen in Haiku-stijl
Natuurlijk heeft niet alleen Haiku het beste pictogramformaat gekozen; in dit deel is de situatie met Linux-desktopomgevingen 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.cacheAls je hiernaar kijkt, voel je al wat voor een stuk het is.
Natuurlijk is er schaalbaar, dat, zoals u begrijpt, vectorpictogrammen bevat. Waarom is er dan nog iets anders? Omdat het resultaat van het tekenen van vectorafbeeldingen in kleine formaten misschien niet ideaal is. Ik zou graag verschillende opties willen hebben, geoptimaliseerd voor verschillende formaten. In Linux-desktopomgevingen wordt dit bereikt door pictogrammen van verschillende groottes over 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 bestaat geen concept van verschillende versies van Firefox. Het is dus niet mogelijk om op een elegante manier om te gaan met de situatie waarin meerdere versies van een applicatie op het systeem staan.
Verschillende Firefox-pictogrammen in verschillende versies. Het is momenteel onmogelijk om dit onder Linux aan te pakken zonder verschillende krukken.
Mac OS X gaat er wat subtieler mee om:
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.icnsU kunt zien dat er één bestand is firefox.icns in het pakket Firefox.app, met alle formaten, zodat verschillende versies van dezelfde applicatie verschillende pictogrammen hebben.
Veel beter! Pictogrammen reizen met de applicatie mee, alle bronnen staan in één bestand.
Laten we terugkeren naar Haiku. Een verbluffende oplossing, geen uitzonderingen. Volgens :
Er werd een speciaal HVIF-formaat ontwikkeld, sterk geoptimaliseerd voor kleine formaten en snelle weergave. Daarom zijn onze iconen voor het grootste deel veel kleiner dan in raster- of in het veelgebruikte SVG-formaat.
En ze zijn nog steeds geoptimaliseerd:
Pictogramgroottes in HVIF vergeleken met andere formaten.
Het verschil is een orde van grootte!
Maar de magie eindigt hier niet. Dezelfde HVIF kan verschillende detailniveaus weergeven, afhankelijk van de weergegeven grootte, ook al is het een vectorformaat.
Verschillende detailniveaus (LOD), afhankelijk van de rendergrootte
Nu over de nadelen: je kunt SVG niet in ImageMagick gooien en er dan mee stoppen; je moet verschillende cycli doorlopen om een pictogram in HVIF-formaat te maken. uitleg. IconOMatic kan SVG echter tamelijk onvolkomen importeren; ongeveer 90% van de SVG-details wordt met enige waarschijnlijkheid geïmporteerd, de resterende 10% zal handmatig moeten worden geconfigureerd en gewijzigd. Lees meer over hoe HVIF zijn magie doet op de blog
Een pictogram toevoegen aan de applicatie
Nu kan ik een pictogram toevoegen aan het gemaakte pakket , rekening houdend met alle ontvangen informatie.
Nou, omdat ik er nu niet echt zin in heb om mijn eigen pictogram te tekenen voor mijn “Hallo, Wereld” QtQuickApp, haal 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:ICONZiet er goed uit, maar hoe komt het dat wanneer het nieuwe pictogram wordt gekopieerd, het niet verschijnt?
De gekopieerde VICN:101:BEOS:ICONs wordt nog niet gebruikt als applicatiepictogram in bestandsbeheer
Wat heb ik gemist?
Commentaar van de ontwikkelaar:
We moeten een bestand maken
rdefmet alle bronnen en voer vervolgens de opdracht uitrc имя.rdef, hierdoor wordt het bestand gemaakt.rsrc. Vervolgens moet u de opdracht uitvoerenresattr -o имя_бинарника имя.rsrc. Ik gebruik minimaal dit soort opdrachten om pictogrammen aan mijn scripts toe te voegen.
Nou, ik wilde een hulpbron maken, geen attribuut. Ik ben erg in de war.
Slimme caching met behulp van het bestandssysteem
Het openen en lezen van ELF-attributen gaat langzaam. Zoals ik hierboven schreef, wordt het pictogram als een bron in het bestand zelf geschreven. Deze methode is betrouwbaarder en zorgt ervoor dat u het kopiëren naar een ander bestandssysteem kunt overleven. Het wordt dan echter ook bijvoorbeeld naar het bestandssysteemattribuut gekopieerd BEOS:ICON. Dit werkt alleen op bepaalde bestandssystemen, zoals BFS. De iconen die het systeem toont (in Tracker en Deskbar) worden uit dit uitgebreide attribuut gelezen, omdat deze oplossing snel werkt. Op sommige plaatsen (waar snelheid niet belangrijk is, bijvoorbeeld in een typisch 'Over'-venster) ontvangt het systeem het pictogram rechtstreeks van de bron in het bestand. Maar dit is niet het einde. Onthoud dat gebruikers op Mac iconen van applicaties, mappen en documenten kunnen vervangen door hun eigen iconen, omdat het op Mac bijvoorbeeld mogelijk is om deze "belangrijke" dingen te doen . Op Haiku moet je de bron (in het bestand) zien als het originele pictogram dat bij de toepassing wordt geleverd, en het attribuut (in het BFS-bestandssysteem) als iets waarmee de gebruiker naar believen wijzigingen kan aanbrengen (hoewel, hint: de GUI voor het invoegen van een aangepast pictogram bovenop het pictogram is optioneel (nog niet standaard geïmplementeerd).
Bestandssysteemkenmerken controleren
Met resaddr Het is mogelijk om bestandssysteemkenmerken 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.
(...)Het is in wezen de "lijm" die de conversie tussen (betrouwbare) bronnen en (snelle) bestandssysteemattributen uitvoert. En aangezien het systeem bronnen verwacht te ontvangen en het kopiëren automatisch uitvoert, hoef ik me er verder geen zorgen meer over te maken.
De magie van hpkg-pakketten
Momenteel worden (meestal) pakketten gebruikt om programma's op Haiku te verkrijgen .hpkg. Laat je niet misleiden door de simpele naam: het .hpkg-formaat werkt compleet anders dan andere formaten met vergelijkbare namen die je bent tegengekomen, het heeft echte superkrachten.
Met traditionele pakketformaten was ik lange tijd boos vanwege dit feit: je downloadt het ene (pakket) en het andere wordt op het systeem geïnstalleerd (bestanden in het pakket). Het is vrij moeilijk om bestanden te beheren (bijvoorbeeld te verwijderen) wanneer u een pakket op de traditionele manier installeert. En dat allemaal vanwege de inhoud van het pakket verspreid over het bestandssysteem, inclusief plaatsen waar de gemiddelde gebruiker mogelijk geen schrijftoegang heeft. Dit geeft aanleiding tot een hele reeks programma's - pakketbeheerders. Maar het overbrengen van reeds geïnstalleerde software naar bijvoorbeeld een andere machine, verwisselbare schijf of bestandsserver wordt zelfs nog moeilijker, zo niet volledig onmogelijk. Op een typisch Linux-gebaseerd systeem kunnen er gemakkelijk enkele honderdduizenden tot miljoenen individuele bestanden zijn. Het is onnodig om te zeggen dat dit zowel kwetsbaar als langzaam is, bijvoorbeeld bij de eerste installatie van een systeem, bij het installeren, bijwerken en verwijderen van reguliere pakketten, en bij het kopiëren van het opstartvolume (rootpartitie) naar een ander medium.
Ik werk aan het AppImage-project, een gedeeltelijke steunpilaar voor eindgebruikersapplicaties. Dit is een softwaredistributieformaat dat een applicatie en al zijn afhankelijkheden verzamelt in één enkel bestandssysteemimage dat wordt aangekoppeld wanneer de applicatie start. Vereenvoudigt de zaken aanzienlijk, omdat dezelfde ImageMagick plotseling verandert in een enkel bestand, beheerd in een bestandsbeheerder door gewone stervelingen. De voorgestelde methode werkt alleen voor software, zoals blijkt uit de naam van het project, en heeft ook zijn eigen problemen, aangezien mensen die betrokken zijn bij het leveren van software voor Linux altijd de pijl op mij richten.
Laten we terugkeren naar Haiku. Is het mogelijk geweest om de optimale balans te vinden tussen traditionele pakketsystemen en op afbeeldingen gebaseerde softwarelevering? Haar pakketten .hpkg feitelijk gecomprimeerde bestandssysteemafbeeldingen. Wanneer het systeem opstart, mount de kernel alle geïnstalleerde en actieve pakketten met ongeveer de volgende kernelberichten:
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, ja? Houd vol, het wordt nog cooler!
Er is een heel speciaal pakket:
KERN: package_daemon [16040020: 924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"Het bevat een zeer minimalistisch besturingssysteem, inclusief de kernel. Geloof het of niet, zelfs de kernel zelf wordt niet verwijderd van het opstartvolume (rootpartitie), maar wordt zorgvuldig vanuit het pakket op zijn plaats geladen .hpkg. Wauw! Ik heb al gezegd dat ik denk dat een deel van Haiku's algehele verfijning en consistentie voortkomt uit het feit dat het hele systeem, van de kernel en de kerngebruikersruimte tot pakketbeheer en runtime-infrastructuur, gezamenlijk door één team is ontwikkeld. Stel je voor hoeveel verschillende groepen en teams er nodig zijn om zoiets op Linux te draaien [Ik stel me het PuppyLinux-project voor - ongeveer. vertaler]. Stel je dan eens voor hoe lang het zal duren voordat deze aanpak in de distributies wordt toegepast. Ze zeggen: neem een eenvoudig probleem, verdeel het over verschillende artiesten, en het wordt zo ingewikkeld dat het niet langer mogelijk is het op te lossen. Haiku opende in dit geval mijn ogen. Ik denk dat dit precies is wat er nu onder Linux gebeurt (Linux is in dit geval een verzamelnaam voor de Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu-stack).
Systeem terugdraaien met hpkg
Hoe vaak komt de volgende situatie voor: de update is gelukt, en dan blijkt dat iets niet naar behoren werkt? Als u conventionele pakketbeheerders gebruikt, is het moeilijk om de status van het systeem terug te brengen naar een punt in de tijd voordat nieuwe pakketten werden geïnstalleerd (bijvoorbeeld in het geval dat er iets misging). Sommige systemen bieden oplossingen in de vorm van snapshots van het bestandssysteem, maar deze zijn behoorlijk omslachtig en worden niet op alle systemen gebruikt. Haiku lost dit op met behulp van pakketten .hpkg. Telkens wanneer pakketten in het systeem veranderen, worden de oude pakketten niet verwijderd, maar in het systeem opgeslagen in submappen zoals /Haiku/system/packages/administrative/state-<...>/ voortdurend. Onvoltooide bewerkingen slaan hun gegevens op in submappen /Haiku/system/packages/administrative/transaction-<...>/.
Inhoud /Haiku/system/packages/administrative. De mappen “state...” bevatten tekstbestanden met de namen van actieve pakketten, en de mappen “transactie...” bevatten de pakketten zelf.
"Oude actieve status", d.w.z. lijst .hpkg pakketten die actief zijn vóór de wijzigingen worden na elke bewerking in Bestandsbeheer vastgelegd in een tekstbestand /Haiku/system/packages/administrative/state-<...>/activated-packages. Op vergelijkbare wijze wordt een nieuwe “actieve status” in een tekstbestand geschreven /Haiku/system/packages/administrative/activated-packages.
Adresboek /Haiku/system/packages/administrative/state-<...>/ bevat alleen een tekstbestand met een lijst met actieve pakketten van deze status (in het geval van installatie van pakketten zonder verwijdering), en als pakketten zijn verwijderd of bijgewerkt - bevat de statusmap oude versies van pakketten.
Wanneer het systeem opstart, wordt op basis van de lijst met pakketten een beslissing genomen om pakketten te activeren (mounten). Het is zo simpel! Als er iets misgaat tijdens het downloaden, kunt u de downloadmanager vertellen een andere, oudere lijst te gebruiken. Probleem opgelost!
Haiku-downloader. Elk toegangspunt geeft een overeenkomstige "actieve status" weer
Ik hou van de aanpak om eenvoudige tekstbestanden te hebben als de "actieve status"-lijst, met namen die gemakkelijk te begrijpen zijn .hpkg. Dit staat in schril contrast met het feit dat het gebouwd is voor machines en niet voor mensen. van OSTree of Flatpak in het bestandssysteem (op hetzelfde niveau als Microsoft GUID).
Lijst met actieve pakketten voor elk tijdstip
Configuratiegegevens
Blijkbaar in de catalogus /Haiku/system/packages/administrative/writable-files bevat configuratiebestanden voor pakketten, maar ze zijn beschrijfbaar. Immers, zoals u zich herinnert, .hpkg alleen-lezen gemonteerd. Deze bestanden moeten dus uit de pakketten worden gekopieerd voordat ze worden geschreven. Heeft de betekenis.
GUI-integratie voor .hpkg-systeem
Laten we nu eens kijken hoe deze glimmende tassen .hpkg omgaan met integratie in de werkomgeving van de gebruiker (UX). Haiku is immers bedoeld voor persoonlijk gebruik. Persoonlijk leg ik de lat hoog bij het vergelijken van gebruikerservaring met pakketten .app op Macintosh met dezelfde ervaring .hpkg. Ik zal de situatie niet eens vergelijken met werkomgevingen op Linux, omdat deze absoluut verschrikkelijk is vergeleken met andere.
De volgende scenario's komen voor de geest:
- Ik wil de inhoud van een pakket bekijken
.hpkg - Ik wil een pakket installeren
- Ik wil het 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 binnengekomen
- Ik wil alle afhankelijkheden van een pakket downloaden, dat mogelijk geen deel uitmaakt van elke Haiku-installatie (ik heb bijvoorbeeld een fysiek geïsoleerde machine zonder internettoegang).
- Ik wil mijn pakketten (of een deel ervan) afzonderlijk naar een andere locatie verplaatsen, los van het opstartvolume (rootpartitie) (omdat ik daar bijvoorbeeld niet genoeg ruimte op heb).
Dit zou de meeste van de belangrijkste zaken uit mijn dagelijkse werk moeten bestrijken. Laten we beginnen.
Pakketinhoud controleren
Op een Mac Ik klik eenvoudig met de rechtermuisknop op het pakket om het te openen en de inhoud in Finder te bekijken. In werkelijkheid is het immers slechts een verkapte map! (Ik weet dat er pakketten zijn .pkg voor een deel van het systeem dat geen applicaties is, maar gewone gebruikers hebben er meestal geen interactie mee).
Op Haiku Ik klik met de rechtermuisknop op het pakket en klik vervolgens op "Inhoud" om te zien wat er in zit. Maar hier is slechts een lijst met bestanden zonder de mogelijkheid om ze te openen door te dubbelklikken.
Het zou veel beter zijn als er een manier was om het pakket (tijdelijk) te monteren .hpkg te bekijken via een bestandsbeheerder, en de gebruiker hoeft zich geen zorgen te maken over implementatiedetails. (Je kunt trouwens opengaan .hpkg inpakken Expander, die het net als elk ander archief kan uitpakken).
Met de interface van HaikuDepot kunt u een lijst met pakketbestanden bekijken, maar er is geen manier om de inhoud te bekijken door bijvoorbeeld te dubbelklikken op README.md
De Mac wint in deze categorie, maar het toevoegen van de gewenste HaikuDepot-functionaliteit zou niet al te moeilijk moeten zijn.
Een pakket installeren via GUI
Op een Mac, de meeste schijfkopieën .dmg pakketten bevatten .app. Dubbelklik op de schijfkopie en kopieer vervolgens het pakket, bijvoorbeeld door het naar /Applications in Vinder. Voor mij is dit vanzelfsprekend, maar ik heb gehoord dat sommige nieuwelingen dit misschien niet aankunnen. Standaard "suggereert" Apple een systeembrede directory /Applications (op NeXT was het zowel netwerk- als individueel), maar u kunt uw applicaties eenvoudig op een bestandsserver of in een submap plaatsen $HOME/Applications, als je het zo leuk vindt.
Op Haiku, dubbelklik op het pakket en klik vervolgens op "Installeren", 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 echt niet wat ze in deze situatie moeten doen, maar de oplossing ligt voor de hand: vraag de gebruiker of hij afhankelijkheden moet downloaden en installeren. Precies wat Haiku doet.
Ik heb het 'sanity'-pakket handmatig gedownload en erop geklikt. De pakketbeheerder weet waar hij de afhankelijkheden vandaan moet halen (ervan uitgaande dat de repositories al op het systeem zijn geregistreerd). Niet elke Linux-distributie kan dit doen.
Een andere manier is om bestandsbeheer te gebruiken, gewoon slepen en neerzetten .hpkg pakket of in /Haiku/system/packages (standaard voor een systeembrede installatie), of in /Haiku/home/config/packages (voor individuele installatie; niet beschikbaar bij dubbelklikken - ik erger me nog steeds aan het woord "config" op deze plek, wat voor mij in dit geval synoniem is met "instellingen"). En het concept van meerdere gebruikers is nog niet eens beschikbaar voor Haiku (daarom is het waarschijnlijk zo eenvoudig - ik weet het niet, misschien zullen de mogelijkheden voor meerdere gebruikers de zaken onnodig ingewikkeld maken voor een desktop-desktopomgeving).
Haiku wint in deze categorie omdat het niet alleen met applicaties kan werken, maar ook met systeemprogramma's.
Een pakket uit de GUI verwijderen
Op een Mac, je moet het applicatiepictogram naar de prullenbak slepen, en dat is alles. Gemakkelijk!
Op Haiku, ten eerste moet u uitzoeken waar het pakket zich op het systeem bevindt, omdat u het zelden op de juiste plaats installeert (het systeem doet alles). Meestal moet je naar binnen kijken /Haiku/system/packages (met een systeembrede standaardinstallatie), of in /Haiku/home/config/packages (Heb ik al gezegd dat “config” een verkeerde benaming is?). Vervolgens wordt de applicatie eenvoudigweg naar de prullenbak gesleept, en dat is alles.
Gemakkelijk! Dat zou ik echter niet zeggen. Dit is wat er echt gebeurt:
Dit is wat er gebeurt als u een applicatie vanuit de prullenbak naar de prullenbak sleept /Haiku/system/packages
Ik heb zojuist geprobeerd mijn "Hello World"-applicatie van gisteren op QtQuickApp naar de prullenbak te verplaatsen. Ik heb niet geprobeerd de systeemmap te verplaatsen, en aangezien alle pakketten in de systeemmap zijn geïnstalleerd, is het onmogelijk om het pakket te verwijderen .hpkg zonder verandering "De inhoud". Een gewone gebruiker zou bang worden en op de standaard “Annuleren”-knop drukken.
Legt uit :
Dit bericht is ruim 10 jaar oud. Hoogstwaarschijnlijk moeten we het zo configureren dat de waarschuwing alleen verschijnt als het pakket zelf wordt verplaatst. Reguliere gebruikers hoeven dit sowieso niet te doen.
Oké, misschien moet ik dit doen met HaikuDepot? Ik dubbelklik op het pakketje /Haiku/system/packages, wachtend tot de knop "Verwijderen" verschijnt. Nee, er is (alleen) “Installeren”. "Verwijderen", waar ben je?
Voor de lol probeerde ik te zien wat er zou gebeuren als ik op “Installeren” zou klikken op een reeds geïnstalleerd pakket. Het komt zo uit:
Dit gebeurt als u een reeds geïnstalleerd pakket probeert te installeren.
Vervolgens verschijnt:
Als u in het vorige venster op “Wijzigingen toepassen” klikt, ziet het er zo uit
Ik neem aan dat dit een softwarefout is; de link naar de applicatie is er al. [de auteur heeft geen link opgegeven - ca. vertaler]
Snelle oplossing: voeg een knop "Verwijderen" toe als het pakket al binnen is
/Haiku/system/packages, of in/Haiku/home/config/packages.
Wanneer ik de lijst met pakketten bekijk die in HaikuDepot zijn geïnstalleerd, zie ik mijn pakket in de lijst en kan ik het verwijderen.
De Mac wint in deze categorie. Maar ik kan me voorstellen dat met de juiste configuratie de gebruikerservaring op Haiku beter zal zijn dan op Mac. (Een van de ontwikkelaars beoordeelde het als volgt: “Minder dan een uur om de gespecificeerde functionaliteit aan HaikuDepot toe te voegen, als je een beetje C++ kent”, vrijwilligers?)
Iets uit een pakket verwijderen
Laten we proberen de applicatie zelf te verwijderen, niet het pakket .hpkg, waar het vandaan kwam (ik betwijfel of er voor “gewone stervelingen” enig verschil is).
Op een Mac, werkt de gebruiker meestal met het bestand .dmgwaar komt het applicatiepakket vandaan .app. Meestal afbeeldingen .dmg worden verzameld in de downloadmap, en pakketten worden door de gebruiker gekopieerd /Applications. Er wordt aangenomen dat veel gebruikers zelf niet weten wat ze doen, deze hypothese wordt bevestigd door een voormalige Apple-medewerker. (Een van de dingen die ik niet leuk vind op Mac. En met AppImage is er bijvoorbeeld geen verschil tussen de applicatie en het pakket waarin deze zich bevond. Sleep het pictogram naar de prullenbak = dat is alles. Gemakkelijk!)
Op Haiku, er is ook een scheiding tussen apps/ и packages/, dus ik betwijfel of dit het voor gebruikers duidelijker heeft gemaakt. Maar wat gebeurt er als je een applicatie van apps/ Voeg toe aan winkelkar:
Dit is wat er gebeurt als u een toepassing uit een bestand probeert te verwijderen .hpkg
Technisch gezien is het correct (de applicatie wordt immers in de eerste plaats gehost op een alleen-lezen bestandssysteem), maar het is niet bijzonder nuttig voor de gebruiker.
Snelle oplossing: stel voor om in plaats daarvan GUI te gebruiken om te verwijderen
.hpkg
Voor de lol probeerde ik de applicatie te dupliceren door op Alt+D te drukken. Ik heb het bericht ontvangen: "Kan objecten op een alleen-lezen volume niet verplaatsen of kopiëren." En dat allemaal omdat /system (daarnaast /system/packages и /system/settings) is het aankoppelpunt van packagefs (onthoud hoe het in de uitvoer verschijnt df?). Helaas is de uitvoer van het commando mount verduidelijkt de situatie niet (zoals gezegd in een van de vorige artikelen), mountvolume laat niet zien wat je zoekt (blijkbaar zijn pakketten gemonteerd via loop .hpkg worden niet als "volumes" beschouwd, en ik ben ook de alternatieve commando's vergeten.
Niemand heeft in deze categorie gewonnen behalve AppImage (maar dit is, om helemaal eerlijk te zijn, een bevooroordeelde mening). Je kunt je echter voorstellen dat na het aanpassen de gebruikerservaring op Haiku beter zal zijn dan op Mac.
Let op: je moet uitzoeken wat een “volume” is in relatie tot een “sectie”. Dit lijkt waarschijnlijk op de relatie tussen "map" en "map": de meeste mappen verschijnen als mappen in bestandsbeheer, maar niet allemaal (pakketten die bijvoorbeeld als bestanden worden behandeld). Maakt dit soort uitstallingen mij tot een officiële nerd?
Het kopiëren van de inhoud van een pakket naar een ander systeem
Op een Mac, Ik sleep het pakket dom .app, en aangezien de afhankelijkheden zich binnen het pakket bevinden, verplaatsen ze zich samen.
Op Haiku, Ik sleep de applicatie, maar de afhankelijkheden worden helemaal niet verwerkt.
Snelle oplossing: laten we in plaats daarvan voorstellen om het volledige `.hpkg-pakket te slepen, samen met eventuele afhankelijkheden, indien aanwezig.
De Mac wint duidelijk in deze categorie. In ieder geval voor mij, een liefhebber van hun paradigma. Ik zou het naar Haiku moeten kopiëren .hpkg in plaats van een applicatie, maar het systeem biedt mij dit niet...
Download een pakket met al zijn afhankelijkheden
Niet elke machine is altijd met het netwerk verbonden. Integendeel, sommige machines (ja, ik kijk naar jou, moderne Windows, Mac en Linux) vergeten dit. Het is belangrijk voor mij dat ik bijvoorbeeld naar een internetcafé kan gaan, software op een verwisselbare schijf kan downloaden, deze schijf in mijn thuiscomputer kan plaatsen en er zeker van kan zijn dat alles werkt [riskante kerel, dit op Windows doen... - ca. vertaler].
Als gevolg hiervan heb ik de neiging om iets vaker dan normaal te eindigen met onvervulde afhankelijkheden van Windows en Linux.
Op een Mac dit is meestal één bestand, het enige wat u hoeft te doen is downloaden .dmg. Meestal heeft het geen andere afhankelijkheden dan die welke standaard door MacOS zelf worden geleverd. Een uitzondering vormen complexe applicaties die een geschikte uitvoeringsomgeving vereisen, bijvoorbeeld Java.
Op Haiku pakket downloaden .hpkg want bijvoorbeeld dezelfde toepassing in Java is mogelijk niet voldoende, aangezien Java wel of niet aanwezig kan zijn op de doelmachine. Is er een manier om alle afhankelijkheden voor een bepaald pakket te downloaden? .hpkg, anders dan degene die standaard in Haiku zijn geïnstalleerd en daarom op elk Haiku-systeem zouden moeten staan?
De Mac wint deze categorie met een kleine marge.
Opmerkingen Dhr. waggelplons:
Een programma schrijven dat alle afhankelijkheden van een applicatie verzamelt als een set pakketten
.hpkgvoor iemand die bekend is met de innerlijke werking van Haiku is ongeveer 15 minuten voldoende. Het toevoegen van draagvlak hiervoor is niet zo moeilijk als daar echt behoefte aan is. Maar voor mij is dit een zeldzame situatie.
Laten we onze adem inhouden tot het volgende artikel in deze serie.
Pakketten verplaatsen naar een aparte locatie
Zoals ik al eerder schreef wil ik mijn pakketjes plaatsen .hpkg (nou ja, of een deel ervan) naar een speciale plaats, gescheiden van de gebruikelijke plaatsing op het opstartvolume (rootpartitie). In het gebruikelijke (niet zo theoretische) geval is de reden hiervoor dat ik voortdurend onvoldoende vrije ruimte heb op mijn (ingebouwde) schijven, hoe groot ze ook zijn. En meestal sluit ik externe schijven of netwerkshares aan waar mijn applicaties zich bevinden.
Op een Mac Ik verplaats alleen pakketjes .app naar een verwisselbaar station of netwerkmap in Finder, en dat is alles. Ik kan nog steeds dubbelklikken om de applicatie te openen zoals ik normaal zou doen vanaf het opstartvolume. Zojuist!
Op HaikuZoals mij werd verteld, kan dit worden bereikt door mijn .hpkg pakketten naar een verwisselbaar station of netwerkmap, maar dan moet u enkele ongedocumenteerde opdrachten in de console gebruiken om ze op het systeem te koppelen. Ik weet niet hoe ik dit moet doen met alleen de GUI.
De Mac wint in deze categorie.
Volgens dhr. waggelplons:
Dit is een optimalisatie op basis van normaal gebruik. Als er vraag is van meer dan één gebruiker, zullen wij dit implementeren. In ieder geval is er de mogelijkheid van implementatie door derden.
We zullen hierover in het volgende artikel praten.
Over netwerkmappen gesproken: het zou geweldig zijn (ik vermoed LAN-partijen) om eenvoudige, vindbare, netwerkbrede applicaties (zoals Zeroconf) te hebben die naar de lokale computer kunnen worden gekopieerd of rechtstreeks vanaf het lokale netwerk kunnen worden uitgevoerd. Uiteraard hebben ontwikkelaars de mogelijkheid om zich af te melden via app_flags.
Eindrapport over de integratie van het hpkg-systeem met de GUI
Ik denk dat dit vooral te wijten is aan de relatieve nieuwheid van de integratie .hpkg de GUI laat nog steeds veel te wensen over. Hoe dan ook, er zijn een paar dingen die verbeterd kunnen worden op het gebied van UX...
Nog één ding: Kernel Debug Land
Het zou geweldig zijn om bijvoorbeeld opdrachten te kunnen invoeren tijdens kernelpaniek syslog | grep usb. Welnu, op Haiku is het mogelijk dankzij Kernel Debug Land. Hoe kun je deze magie in actie zien als alles werkt zoals het zou moeten, zonder dat je in een kernelpaniek terechtkomt? Eenvoudig door op Alt+PrintScn+D (Debug-ezelsbruggetje) te drukken. Ik herinner het me onmiddellijk , waardoor de oorspronkelijke Macintosh-ontwikkelaars de debugger konden invoeren (als die geïnstalleerd was, natuurlijk).
Conclusie
Ik begin te begrijpen dat de verfijning van het Haiku-systeem voortkomt uit het feit dat het werk wordt uitgevoerd door één klein team met een duidelijke focus op de werkomgeving, waarbij alle lagen van het systeem toegankelijk zijn.
Een scherp contrast met de wereld van Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, waar alles zo in kleine stukjes wordt opgedeeld dat abstractie op abstractie zit en met krukken voortdrijft.
Er was ook inzicht in hoe het systeem werkte .hpkg combineert de best practices van traditionele pakketbeheerders, Snappy, Flatpak, AppImage en zelfs btrfs, en combineert deze met de "gewoon werkt"-aanpak van de Mac.
Het was alsof er iets in mijn hoofd ‘schakelde’ en ik begreep hoe het systeem werkte .hpkg weet hoe hij weg moet rollen, alleen al door naar haar te kijken. Maar het ligt niet aan mij, maar aan de schoonheid en eenvoud van het systeem. Veel hiervan is geïnspireerd door de geest van de originele Mac.
Ja, browsen in de browser kan schokkerig zijn en als een slak werken, applicaties ontbreken mogelijk (geen Gtk, Electron - de ontwikkelaars concludeerden dat ze niet goed samengaan met verfijning), video en 3D-versnelling zijn misschien volledig afwezig, maar ik heb nog steeds leuk dit systeem. Deze dingen kunnen immers worden gecorrigeerd 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 het vanaf nu zal beginnen jaar van Haiku op desktop.
Willekeurige problemen
Misschien zijn er al verzoeken, of moet ik ze openen?
- BeScreenCapture zou naar GIF zoals Peek moeten kunnen exporteren. Dit kan gedaan worden met behulp van ffmpeg, al beschikbaar voor Haiku. .
- Screenshot-software slaagt er niet in een modaal venster vast te leggen, maar legt in plaats daarvan het volledige scherm vast
- U kunt schermafbeeldingen niet bijsnijden met de bijsnijdtool van WonderBrush en het resultaat vervolgens opslaan in een bestand
- Ik hou niet zo van de handcursor in Haiku, maar ik denk dat het te maken heeft met het warme, nostalgische gevoel. Dit is vooral vervelend bij het gebruik van het bijsnijdgereedschap in Krita, omdat het resulteert in onnauwkeurig bijsnijden (zie schermafbeeldingen van modale dialoogvensters in dit artikel). Een draadkruiscursor zou geweldig zijn. .
Probeer het zelf! Het Haiku-project levert immers gegenereerde afbeeldingen voor het opstarten vanaf dvd of USB . Om te installeren hoeft u alleen maar de afbeelding te downloaden en deze naar een flashstation te schrijven met behulp van
Heb je nog vragen? Wij nodigen u uit voor de Russischtalige .
Foutoverzicht:
Van vertaling: dit is het zesde artikel in de serie over Haiku.
Lijst met artikelen:
Bron: www.habr.com