🥇Nog iets: Haiku-applicatiepakketten?

TL;DR: kan Haiku de juiste ondersteuning voor applicatiepakketten krijgen, zoals applicatiecatalogi (zoals .app op Mac) en/of applicatie-templates (Linux AppImage)? Ik denk dat dit een waardevolle aanvulling zou zijn, die gemakkelijker te implementeren is dan in andere systemen, omdat het meeste van de infrastructuur al aanwezig is.

Een week geleden ontdekte ik Haiku, een verrassend goed systeem. Aangezien ik al lange tijd geïnteresseerd ben in catalogi en applicatie-templates (geïnspireerd door de eenvoud van Macintosh), is het niet verwonderlijk dat het idee in me opkwam…

Voor de duidelijkheid: ik ben de maker en auteur van AppImage, een distributieformaat voor Linux-applicaties, gericht op de eenvoud van Mac en dat volledige controle biedt aan applicatieontwikkelaars en eindgebruikers (wil je meer weten - zie wiki en documentatie).

Wat als we AppImage voor Haiku maken?

Laten we even theoretisch overleggen: wat moet er gedaan worden om AppImage, of iets dergelijks, op Haiku te krijgen? Het is niet nodig om meteen iets te creëren, want het systeem dat al in Haiku bestaat, werkt verbazingwekkend goed, terwijl het denkexperiment een goede uitkomst zou zijn. Bovendien toont het de verfijning van Haiku aan vergeleken met Linux-dektopomgevingen, waar dit soort dingen vreselijk moeilijk zijn (ik heb het recht om dit te zeggen: ik worstel al 10 jaar met debugging).

Op Macintosh System 1 was elke applicatie een apart bestand, 'beheerd' in Finder. Met AppImage probeer ik dezezelfde gebruikerservaring op Linux opnieuw te creëren.

Ten eerste, wat is AppImage? Het is een systeem voor het uitbrengen van applicaties van derden (zoals Ultimaker Cura), waarmee applicaties kunnen worden uitgebracht wanneer en hoe ze willen: je hoeft niet op de hoogte te zijn van de bijzonderheden van verschillende distributies, buildbeleid of buildinfrastructuur, supportmedewerkers zijn niet nodig, en zij vertellen gebruikers niet wat ze (niet) op hun computers kunnen installeren. AppImage moet worden begrepen als iets dat lijkt op een pakket voor Mac in formaat .app binnen een schijfbeeld .dmg. Het belangrijkste verschil is dat applicaties niet worden gekopieerd, maar altijd binnen AppImage blijven, ongeveer zoals Haiku-pakketten .hpkg worden gemonteerd en nooit in de gebruikelijke zin worden geïnstalleerd.

AppImage heeft in meer dan 10 jaar bestaan enige aantrekkingskracht en populariteit verworven: Linus Torvalds heeft het publiekelijk goedgekeurd en veelgebruikte projecten (zoals LibreOffice, Krita, Inkscape, Scribus, ImageMagick) hebben het aangenomen als de belangrijkste manier om continue of nachtelijke builds te verspreiden, zonder de geïnstalleerde of niet-geïnstalleerde applicaties van gebruikers te verstoren. Echter, werkomgevingen en Linux-distributies blijven vaak vasthouden aan het traditionele, gecentraliseerde model van distributie dat gebaseerd is op gepaard aanbod en/of bevorderen hun eigen commerciële business- en/of engineeringprogramma's. Flatpak (RedHat, Fedora, GNOME) en Snappy (Canonical, Ubuntu). Het gaat zelfs tot het belachelijke.

Hoe alles werkt

Elke AppImage bevat 2 onderdelen: een klein dubbelklikbaar uitvoerbaar bestand in ELF-formaat (ook wel runtime.c), gevolgd door een afbeeldingsarchief van het bestandssysteem SquashFS.

Het SquashFS-bestandssysteem bevat de payload in de vorm van de applicatie en alles wat nodig is om deze uit te voeren, wat in een helder hoofd niet als een standaardinstallatie voor elke relatief nieuwe doelsysteem (Linux-distributie) kan worden beschouwd. Het bevat ook metadata, zoals de naam van de applicatie, pictogrammen, MIME-types, en meer.

Bij het starten gebruikt de runtime FUSE en squashfuse om het bestandssysteem aan te mappen, waarna het een ingangspunt (de zogenaamde AppRun) binnen de aangekoppelde AppImage uitvoert.
Het bestandssysteem wordt ontkoppeld nadat het proces is voltooid.

Klinkt allemaal eenvoudig.

Maar deze dingen compliceren het allemaal:

met zo'n diversiteit aan Linux-distributies kan niets 'in een helder hoofd' nog worden beschouwd als 'deel van de standaardinstallatie voor elk recent doelsysteem'. We omzeilen dit probleem door een excludelistsamen te stellen, die bepaalt wat in de AppImage wordt verpakt en wat ergens anders vandaan moet worden gehaald. Daarbij missen we soms het doel, hoewel alles over het algemeen prima werkt. Om deze reden raden we pakketmakers aan om AppImages op alle doelsystemen (distributies) te testen.
Applicaties als payload moeten verplaatsbaar zijn binnen het bestandssysteem. Helaas hebben veel applicaties hardcoded absolute paden naar bijvoorbeeld resources in /usr/share. Dit moet op de een of andere manier worden opgelost. Daarnaast moet ofwel LD_LIBRARY_PATHworden geëxporteerd, of rpath worden gecorrigeerd. zodat de loader de bijbehorende bibliotheken kan vinden. De eerste methode heeft zijn nadelen (die met complexe oplossingen worden omzeild), terwijl de tweede simpelweg omslachtig is.
De grootste UX-valstrik voor gebruikers is dat ze moeten de uitvoerbare bit aan het AppImage-bestand na het downloaden. Geloof het of niet, maar voor sommigen is dit een echte drempel. De noodzaak om de uitvoerbaarheid in te stellen is omslachtig, zelfs voor ervaren gebruikers. Als omweg hebben we een kleine service voorgesteld die de AppImage-bestanden monitort en ze de uitvoerbaarheid toekent. In pure vorm is het geen ideale oplossing, omdat het 'uit de doos' niet zal werken. Linux-distributies leveren deze service niet, daardoor is het voor gebruikers 'uit de doos' problematisch.
Linux-gebruikers verwachten dat een nieuwe applicatie een pictogram in het startmenu heeft. Je kunt tegen het systeem niet zeggen: "Kijk, daar is een nieuwe applicatie, laten we aan de slag gaan". In plaats daarvan moet, volgens de XDG-specificatie, het bestand .desktop op de juiste plaats in /usr voor een systeeminstallatie, of in $HOME voor persoonlijk gebruik. Bepaalde pictogramgroottes moeten, volgens de XDG-specificatie, op specifieke plaatsen in usr of $HOMEworden geplaatst, waarna opdrachten in de werkomgeving moeten worden uitgevoerd om de pictogramcache bij te werken, of je moet hopen dat de desktopomgeving het automatisch zal ontdekken. Hetzelfde geldt voor MIME-types. Als omweg wordt voorgesteld om dezelfde service te gebruiken, die naast het instellen van de uitvoerbaarheid ook, indien pictogrammen en dergelijke in de AppImage aanwezig zijn, deze uit de AppImage op de juiste plaatsen volgens XDG zal kopiëren. Bij verwijdering of verplaatsing zal de service vermoedelijk alles opruimen. Natuurlijk zijn er verschillen in het gedrag van elke desktopomgeving, in de indelingen van grafische bestanden, hun afmetingen, opslaglocaties en manieren om caches bij te werken, wat het probleem veroorzaakt. Kortom, deze methode is een oplossing.
Als het bovenstaande niet genoeg is, is er in de bestandsbeheerder nog steeds geen AppImage-pictogram. In de wereld van Linux is er nog steeds geen beslissing genomen over de implementatie van elficon (ondanks de discussie en implementatie), waardoor het onmogelijk is om het pictogram rechtstreeks in de toepassing in te bedden. Dus zijn toepassingen in de bestandsbeheerder niet voorzien van hun eigen pictogrammen (ongeacht of het AppImage of iets anders is); ze zijn alleen zichtbaar in het startmenu. Als omweg gebruiken we miniaturen—een mechanisme dat oorspronkelijk is ontwikkeld zodat desktopomgevingen verkleinde afbeeldingen konden weergeven ter preview van grafische bestanden als hun pictogrammen. Bijgevolg fungeert de service voor het instellen van uitvoerbaarheid ook als 'miniaturizer', die miniatuurpictogrammen maakt en opslaat op de juiste locaties. /usr en $HOME. Deze service zorgt ook voor opruiming wanneer AppImage wordt verwijderd of verplaatst. Aangezien elke desktopomgeving zich net iets anders gedraagt, bijvoorbeeld in welke formaten pictogrammen worden geaccepteerd, in welke afmetingen of op welke locaties, is dit allemaal behoorlijk pijnlijk.
De applicatie crasht gewoon tijdens uitvoering als er fouten optreden (bijvoorbeeld als er een bibliotheek is die niet deel uitmaakt van het basissysteem en niet wordt geleverd met AppImage), en niemand zegt de gebruiker in de GUI wat er precies aan de hand is. We zijn dit begonnen te omzeilen door meldingen op het bureaublad, wat betekent dat we fouten uit de opdrachtregel moeten opvangen, ze moeten omzetten in begrijpelijke berichten voor de gebruiker, die dan ook nog op het bureaublad moeten worden weergegeven. En natuurlijk behandelt elke werkomgeving dit een beetje anders.
Op dit moment (september 2019, — opmerking van de vertaler) heb ik geen gemakkelijke manier gevonden om het systeem te vertellen dat het bestand 1.png moet worden geopend met Krita, en 2.png met GIMP.

De opslagplaats voor cross-desktop specificaties die worden gebruikt in GNOME, KDE en Xfce is freedesktop.org

Het bereiken van een niveau van verfijning, dat diep verweven is in de Haiku-werkomgeving, is moeilijk, om niet te zeggen 'onmogelijk', vanwege de specificaties XDG van freedesktop.org voor cross-desktop, evenals de implementaties van desktopbeheerders op basis van deze specificaties. Een voorbeeld hiervan is één systeemwijde pictogram voor Firefox: het lijkt erop dat de auteurs van XDG niet aan de gedachte kwamen dat een gebruiker meerdere versies van dezelfde applicatie kan hebben geïnstalleerd.

Pictogrammen van verschillende versies van Firefox

Ik vroeg me af wat de wereld van Linux zou kunnen leren van Mac OS X om te voorkomen dat er fouten optreden bij systeemintegratie. Als je tijd hebt en hierop gefocust bent, lees dan zeker wat Arno Gurdol, een van de eerste ingenieurs van Mac OS X, te zeggen had:

We wilden dat het installeren van de applicatie net zo eenvoudig was als het slepen van het pictogram van de applicatie ergens vandaan (server, externe schijf) naar de schijf van je computer. Daarom bevat het applicatiepakket alle informatie, inclusief pictogrammen, versie, verwerkte bestandstype, het type URL-schema dat het systeem moet weten voor het verwerken van de applicatie. Dit omvat ook informatie voor 'gecentraliseerde opslag' in de database Icon Services en Launch Services. Om de prestaties van de applicatie te ondersteunen, worden ze 'ontdekt' op verschillende 'bekende' locaties: in de systeem- en gebruikersdirectory Apps, alsook in sommige andere automatisch, als de gebruiker naar de map gaat die de applicatie bevat in de Finder. In de praktijk heeft dit zeer goed gewerkt.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 sessie 144 — Mac OS X: applicaties verpakken en documenten afdrukken.

Er is niets dergelijks in deze infrastructuur op Linux-werkomgevingen, dus zoeken we naar alternatieve manieren om de structurele beperkingen in het AppImage-project te omzeilen.

Is Haiku echt op weg om te helpen?

En bovendien: Linux-platforms dienen als basis voor werkomgevingen, zijn doorgaans zo slecht gedefinieerd dat veel dingen die heel eenvoudig zijn in een samenhangend systeem met een volledige stack, tekortschieten door de fragmentatie en complexiteit in Linux. Ik heb een hele lezing gewijd aan de kwesties die samenhangen met het Linux-platform voor werkomgevingen (ervaren ontwikkelaars bevestigden: dit zal nog heel lang zo blijven).

Mijn presentatie over problemen met Linux-werkomgevingen in 2018

Zelfs Linus Torvalds heeft erkend dat de fragmentatie de reden is waarom het idee van werkomgevingen niet is gelukt.

Wat leuk om Haiku te zien!

Met Haiku wordt alles ongelooflijk eenvoudig

Hoewel de naïeve benadering van het "overzetten" van AppImage naar Haiku zou kunnen inhouden dat men simpelweg probeert de onderdelen (voornamelijk runtime.c en de service) te bouwen (wat zelfs mogelijk zou kunnen zijn!), zal dit niet veel nut hebben voor Haiku. Want in werkelijkheid zijn de meeste van deze problemen al opgelost op Haiku en conceptueel onderbouwd. Haiku biedt precies die bouwstenen voor de systeeminfrastructuur die ik zo lang heb gezocht in werkomgevingen op Linux en ik kon niet geloven dat ze daar niet waren. Namelijk:

Of je het nu gelooft of niet, veel Linux-gebruikers kunnen dit niet overwinnen. Op Haiku gebeurt alles automatisch!

ELF-bestanden zonder uitvoerbaarheid-bit krijgen dit automatisch bij een dubbele klik in de bestandsbeheerder.
Toepassingen kunnen ingebouwde bronnen hebben, zoals pictogrammen, die in de bestandsbeheerder worden weergegeven. Je hoeft geen stapel afbeeldingen te kopiëren naar speciale pictogramdirectories, en dus hoef je ze ook niet op te schonen na het verwijderen of verplaatsen van de toepassing.
Er is een database voor het koppelen van toepassingen aan documenten, je hoeft geen bestanden te kopiëren hiervoor.
In de lib/ directory worden bibliotheken standaard gezocht naast het uitvoerbare bestand.
Er zijn geen talrijke distributies en desktopomgevingen, alles wat werkt, werkt overal.
Er is geen aparte module voor het draaien die verschilt van de Applications-directory.
In applicaties zijn er geen ingebouwde absolute paden naar hun bronnen, er zijn speciale functies om de locatie tijdens runtime te bepalen.
Het idee van gecomprimeerde bestandssysteemafbeeldingen is geïmplementeerd: dit is elk hpkg-pakket. Ze worden allemaal door de kernel gemonteerd.
Elk bestand wordt geopend door de toepassing die het heeft aangemaakt, tenzij expliciet anders aangegeven. Hoe geweldig is dat!

Twee png-bestanden. Let op de verschillende pictogrammen, die laten zien dat ze door verschillende toepassingen worden geopend bij een dubbele klik. Let ook op het dropdownmenu "Openen met:", waar de gebruiker een specifieke toepassing kan kiezen. Hoe eenvoudig!

Het lijkt erop dat veel van de hulptroepen en omwegen die nodig zijn voor AppImage op Linux overbodig worden op Haiku, dat zijn basis eenvoud en verfijning heeft, waardoor het aan de meeste van onze behoeften voldoet.

Zijn Haiku-applicatiepakketten uiteindelijk nodig?

Dit leidt tot een grote vraag. Als het gemakkelijker zou zijn om een systeem zoals AppImage op Haiku te creëren dan op Linux, zou het dan de moeite waard zijn om dit te doen? Of heeft Haiku met zijn hpkg-pakketbeheersysteem eigenlijk de noodzaak voor een dergelijke ontwikkeling geëlimineerd? Laten we de motivatie voor het bestaan van AppImages bekijken voor een antwoord.

Perspectief van de gebruiker

Laten we kijken naar onze eindgebruiker:

Ik wil een applicatie installeren zonder dat er om een beheerderswachtwoord (root) wordt gevraagd. Op Haiku bestaat het concept van een beheerder niet, de gebruiker heeft volledige controle, omdat dit een persoonlijk systeem is! (In principe is het ook mogelijk om dit in een meervoudig gebruikersscenario te zien, ik hoop dat de ontwikkelaars de eenvoud behouden)
Ik wil de laatste en beste versies van toepassingen ontvangen, zonder te wachten tot ze in mijn distributie verschijnen (wat meestal betekent 'nooit', tenzij je het hele besturingssysteem bijwerkt). Op Haiku wordt dit 'opgelost' met zwevende releases. Dit betekent dat je de mogelijkheid hebt om de laatste en beste versies van toepassingen te krijgen, maar daarvoor moet je ook de rest van het systeem voortdurend bijwerken, waardoor het feitelijk een 'bewegend doel' wordt..
Ik wil meerdere versies van dezelfde applicatie naast elkaar hebben, omdat ik niet kan weten wat er is gebroken in de laatste versie, of bijvoorbeeld, als webontwikkelaar moet ik mijn werk testen in verschillende versies van de browser. In Haiku is het eerste probleem opgelost, maar het tweede niet. Updates kunnen worden teruggedraaid, maar alleen voor het gehele systeem; het is (voor zover ik weet) niet mogelijk om bijvoorbeeld meerdere versies van WebPositive of LibreOffice gelijktijdig uit te voeren.

Een van de ontwikkelaars schrijft:

Essentie van de rechtvaardiging: het gebruiksscenario is zo zeldzaam dat optimalisatie daarvoor niet logisch is; het behandelen als een speciaal geval in HaikuPorts lijkt meer dan acceptabel.

Ik wil applicaties opslaan waar ik wil, en niet op de opstartschijf. Vaak heb ik niet genoeg ruimte op de schijven, dus ik moet een externe schijf of netwerkmap aansluiten voor het opslaan van applicaties (alle versies die ik heb gedownload). Als ik zo'n schijf aansluit, moeten de applicaties met een dubbelklikken worden gestart. Haiku bewaart oude versies van pakketten, maar ik weet niet hoe ik ze naar een externe schijf kan verplaatsen en hoe ik vervolgens applicaties daar vanaf kan aanroepen.

Reactie van de ontwikkelaar:

Technisch gezien is dit al mogelijk met het mount-commando. Natuurlijk zullen we hier een GUI voor maken zodra er genoeg geïnteresseerde gebruikers zijn.

Ik heb geen miljoenen bestanden verspreid over het bestandssysteem, waarmee ik handmatig niets kan doen. Ik wil één bestand per applicatie dat ik gemakkelijk kan downloaden, verplaatsen of verwijderen. Op Haiku is dit probleem opgelost met pakketten .hpkg, die bijvoorbeeld Python uit duizenden bestanden in één bestand verplaatsen. Maar als er bijvoorbeeld Scribus is dat Python gebruikt, dan moet ik met minimaal twee bestanden omgaan. En ik moet ervoor zorgen dat ik de werkende versies van beide bestanden behouden.

Talrijke versies van AppImages, die naast elkaar draaien op één Linux

Een kijk vanuit het perspectief van de applicatieontwikkelaar

Laten we eens kijken vanuit het perspectief van de applicatieontwikkelaar:

Ik wil de gebruikerservaring volledig beheren. Ik wil niet afhankelijk zijn van het besturingssysteem dat me vertelt wanneer en hoe ik applicaties moet uitbrengen. Op Haiku kunnen ontwikkelaars werken met hun eigen hpkg-repositories, maar dit betekent dat gebruikers ze handmatig moeten instellen, wat deze idee 'minder aantrekkelijk' maakt.
Ik heb een downloadpagina op mijn website waar ik .exe voor Windows, .dmg voor Mac en .AppImage voor Linux verspreid. Misschien wil ik toegang tot deze pagina monetiseren; alles is mogelijk? Wat moet ik daar voor Haiku plaatsen? Een enkel bestand is voldoende .hpkg met alleen afhankelijkheden van HaikuPorts
Mijn software heeft bepaalde versies van andere software nodig. Bijvoorbeeld, het is bekend dat Krita een aangepaste versie van Qt nodig heeft, of Qt die precies is afgesteld op een specifieke versie van Krita, althans totdat de correcties weer terug in Qt komen. Je kunt je eigen Qt voor de applicatie in het pakket verpakken .hpkg, maar dit wordt waarschijnlijk niet aangemoedigd.

Een gewone downloadpagina voor applicaties. Wat moet hier voor Haiku worden geplaatst?

Zullen sets (die bestaan in de vorm van applicatiecatalogi, zoals AppDir of .app in de stijl van Apple) en/of beelden (in de vorm van sterk gemodificeerde AppImages of .dmg Is it useful to have applications from Apple as an addition to the Haiku working environment? Or will it dilute the overall picture and lead to fragmentation, thus adding complexity? I’m torn: on one hand, the beauty and sophistication of Haiku are based on the fact that there is usually one way to do something, rather than many. On the other hand, most of the infrastructure for catalogs and/or application packages is already in place, so the system calls for the remaining few percent to fall into place.

According to the developer mr. waddlesplash

On Linux they (catalogs and application packages — translator's note) are most likely a technical solution to systemic problems. At Haiku, we prefer to simply address systemic issues.

What do you think?

Before you answer…

Wait, let's do a quick reality check: in fact application catalogs — are already part of Haiku:

Application catalogs already exist on Haiku but are currently not supported in the file manager

They are just not as well supported as, say, in the Macintosh Finder. How cool would it be if the QtCreator catalog had the name and icon 'QtCreator' in the upper left corner, launching the application with a double click?

Earlier I already asked:

Are you sure you will run your decade-old applications today when all the app stores and distribution repositories forget about them and their dependencies? Are you sure you will still be able to access your current work in the future?

Is there already an answer from Haiku, or can catalogs and application packages help here? I think they can.

According to mr. waddlesplash:

Yes, we have an answer to the question: we will simply support these applications as long as necessary until someone can appropriately read their file formats or provide one-on-one functionality. Our commitment to supporting BeOS R5 applications on Haiku is a direct proof of that…

That’s for sure!

What course of action should Haiku take?

I can envision a peaceful coexistence of hpkg, catalogs, and application images:

System software uses .hpkg
For the most commonly used software (especially for those that need to schedule floating releases) it uses .hpkg (about 80% of all cases)
Some, installed through .hpkg, applicaties zullen profiteren van de overstap naar infrastructuur met applicatiecatalogi (bijvoorbeeld QtCreator): ze zullen worden verspreid in de vorm van .hpkg, zoals altijd.

mr. waddlesplash schrijft:

Als het enige dat nodig is, het bekijken van applicaties is in /system/apps, dan moeten de catalogi in de Deskbar beheersbaarder worden gemaakt voor gebruikers, omdat /system/apps dit niet is bedoeld zodat gebruikers het regelmatig openen en bekijken (in tegenstelling tot MacOS). Voor dergelijke situaties heeft Haiku een andere paradigma, maar dit alternatief is in theorie acceptabel.

Haiku krijgt infrastructuur om applicatiebeelden te draaien, nachten, continue en testsoftware-builds, evenals voor situaties waarin de gebruiker het 'in de tijd wil bevriezen' voor privé- en interne software, en andere speciale gebruikssituaties (ongeveer 20% van alles). Deze beelden bevatten de bestanden die nodig zijn om de applicatie uit te voeren, .hpkg, gemonteerd door het systeem, en worden na het beëindigen van de applicatie weer gedemonteerd. (Misschien zou de bestandsbeheerder bestanden kunnen plaatsen .hpkg in applicatiebeelden, automatisch of op verzoek van de gebruiker — net zoals wanneer je een applicatie naar een netwerfcatalogus of externe schijf sleept. Dat is gewoon muziek! Of beter gezegd poëzie — haiku.) Aan de andere kant kan de gebruiker willen dat de inhoud van het beeld als bestanden wordt geïnstalleerd,.hpkg, waarna deze worden bijgewerkt en verwerkt zoals als ze via HaikuDepot waren geïnstalleerd… We moeten brainstormen).

Citaat van mr. waddlesplash:

Het starten van applicaties vanaf externe schijven of netwerfcatalogi kan potentieel nuttig zijn. En het toevoegen van de mogelijkheid om meer 'zones' voor pkgman in te stellen, zou zeker een goede functie worden.

Een dergelijk systeem zal profiteren van hpkg, catalogi en applicatiebeelden. Ze zijn goed afzonderlijk, maar samen zullen ze onverslaanbaar zijn.

Conclusie

Voor Haiku is er een infrastructuur die een eenvoudige en verfijnde gebruikersinterface voor pc's biedt, en ver boven wat doorgaans voor Linux-pc's wordt aangeboden. Het pakketsysteem .hpkg — een van dergelijke voorbeelden, maar de andere delen van het systeem zijn ook doordrenkt met verfijning. Toch zou Haiku profiteren van de juiste ondersteuning voor catalogi en applicatiepakketten. Hoe dit het beste te doen — dat zou ik graag bespreken met mensen die Haiku, haar filosofie en architectuur veel beter kennen dan ik. Uiteindelijk gebruik ik Haiku nog maar iets meer dan een week. Maar toch denk ik dat dit frisse perspectief nuttig zal zijn voor de ontwerpers, ontwikkelaars en architecten van Haiku. Tenminste, ik ben meer dan bereid om als 'sparringpartner' voor hen te dienen. Ik heb meer dan 10 jaar praktische ervaring met catalogi en applicatiepakketten voor Linux, en ik zou graag zien hoe ze kunnen worden toegepast op Haiku, een concept waarvoor ze naar mijn mening perfect zijn. De potentiële oplossingen die ik voorstel zijn geenszins de enige juiste voor de problemen die ik heb beschreven, en als het Haiku-team besluit andere, elegantere oplossingen te vinden — dan juich ik dat alleen maar toe. In principe overweeg ik al een idee over hoe het systeem hpkg nog verbazingwekkender te maken, zonder de manier van werken te veranderen. Blijkbaar heeft het Haiku-team al lang nagedacht over appliciepakketten bij de implementatie van het pakketbeheersysteem, maar helaas, (het lijkt me) is het idee in de vergetelheid geraakt. Misschien is het tijd om het nieuw leven in te blazen?

Probeer het zelf! Het Haiku-project biedt imagebestanden voor opstarten vanaf DVD of USB, die dagelijks worden aangemaakt. dagelijks.
Heb je vragen? We nodigen je uit in ons Russischtalige telegramkanaal.

Foutoverzicht: Hoe je jezelf in de voet schiet met C en C++. Een verzameling recepten voor Haiku OS.

Vanaf auteur vertaling: dit is het achtste en laatste artikel in de serie over Haiku.

Lijst van artikelen: Eerste Tweede Derde Vierde Vijfde Zesde Zevende

Alleen geregistreerde gebruikers kunnen deelnemen aan de enquête. Log in, alstublieft.