TL; DR: Kan Haiku de juiste ondersteuning krijgen voor applicatiepakketten, zoals applicatiemappen (zoals .app op Mac) en/of applicatie-images (Linux AppImage)? Ik denk dat dit een waardige toevoeging zou zijn die gemakkelijker correct te implementeren is dan andere systemen, aangezien het grootste deel van de infrastructuur al aanwezig is.
Ik ontdekte Haiku, een onverwacht goed systeem. Nou, aangezien ik al heel lang geïnteresseerd ben in mappen en applicatie-images (geïnspireerd door de eenvoud van de Macintosh), is het niet verrassend dat er een idee in me opkwam...
Voor een volledig begrip ben ik de maker en auteur van AppImage, een Linux-applicatiedistributieformaat dat streeft naar eenvoud op de Mac en volledige controle geeft aan applicatie-auteurs en eindgebruikers (als je meer wilt weten, zie и ).
Wat als we een AppImage voor Haiku maken?
Laten we een beetje, puur theoretisch, nadenken: wat er moet gebeuren om te krijgen , of iets dergelijks, op Haiku? Het is niet nodig om nu iets te creëren, omdat het systeem dat al in Haiku bestaat verbazingwekkend werkt, maar een denkbeeldig experiment zou leuk zijn. Het demonstreert ook de verfijning van Haiku, vergeleken met Linux-desktopomgevingen, waar zulke dingen vreselijk moeilijk zijn (ik heb het recht om dat te zeggen: ik worstel al 10 jaar met debuggen).
Op Macintosh Systeem 1 was elke applicatie een afzonderlijk bestand dat werd "beheerd" in de Finder. Met AppImage probeer ik dezelfde gebruikerservaring op Linux te creëren.
Ten eerste, wat is een AppImage? Dit is een systeem voor het vrijgeven van applicaties van derden (bijvoorbeeld ), waardoor applicaties kunnen worden vrijgegeven wanneer en hoe ze willen: het is niet nodig om de details van verschillende distributies te kennen, beleid te bouwen of infrastructuur te bouwen, er is geen ondersteuning van onderhouders nodig, en ze vertellen gebruikers niet wat ze (niet) kunnen installeren op hun computers. AppImage moet worden opgevat als iets dat lijkt op een Mac-pakket in het formaat .app binnen de schijfkopie .dmg. Het belangrijkste verschil is dat applicaties niet worden gekopieerd, maar voor altijd in de AppImage blijven staan, net zoals Haiku-pakketten .hpkg gemonteerd en nooit in de gebruikelijke zin geïnstalleerd.
In de loop van meer dan 10 jaar van zijn bestaan heeft AppImage enige aantrekkingskracht en populariteit verworven: Linus Torvalds zelf heeft het publiekelijk onderschreven, en gemeenschappelijke projecten (bijvoorbeeld LibreOffice, Krita, Inkscape, Scribus, ImageMagick) hebben het als de belangrijkste manier aangenomen om continue of nachtelijke builds te distribueren, zonder de geïnstalleerde of niet-geïnstalleerde gebruikersapplicaties te verstoren. Linux-desktopomgevingen en -distributies houden echter meestal nog steeds vast aan het traditionele, gecentraliseerde, op beheerders gebaseerde distributiemodel en/of promoten hun eigen bedrijfs- en/of engineeringprogramma's op basis van (RedHat, Fedora, GNOME) en (Canoniek, Ubuntu). Het komt .
Hoe het allemaal werkt
- Elke AppImage bevat 2 delen: een kleine dubbelklik-ELF (zogenaamde.
runtime.c), gevolgd door een bestandssysteemimage .
- Het SquashFS-bestandssysteem bevat de payload van de applicatie en alles wat nodig is om deze uit te voeren, wat bij de volle verstand niet kan worden beschouwd als onderdeel van de standaardinstallatie voor elk redelijk recent doelsysteem (Linux-distributie). Het bevat ook metagegevens, zoals de applicatienaam, pictogrammen, MIME-typen, enz., enz.
- Wanneer runtime door de gebruiker wordt uitgevoerd, gebruikt het FUSE en squashfuse om het bestandssysteem te koppelen, en wordt vervolgens een toegangspunt (ook wel AppRun genoemd) binnen de gekoppelde AppImage uitgevoerd.
Het bestandssysteem wordt ontkoppeld nadat het proces is voltooid.
Alles lijkt eenvoudig.
En deze dingen maken alles ingewikkeld:
- Met zo’n verscheidenheid aan Linux-distributies kan niets “met de juiste geest” “onderdeel van de standaardinstallatie voor elk nieuw doelsysteem” worden genoemd. Wij omzeilen dit probleem door te bouwen , zodat u kunt bepalen wat er in de AppImage wordt verpakt en wat ergens anders mee naartoe moet worden genomen. Tegelijkertijd missen we soms, ondanks het feit dat alles over het algemeen prima werkt. Om deze reden raden we aan dat pakketmakers AppImages testen op alle doelsystemen (distributies).
- Applicatiepayloads moeten verplaatsbaar zijn binnen het bestandssysteem. Helaas hebben veel applicaties hardgecodeerde absolute paden naar bijvoorbeeld bronnen in
/usr/share. Dit moet op de een of andere manier worden opgelost. Bovendien moet u exporterenLD_LIBRARY_PATH, of reparerenrpathzodat de lader gerelateerde bibliotheken kan vinden. De eerste methode heeft zijn nadelen (die op complexe manieren kunnen worden overwonnen), en de tweede is eenvoudigweg omslachtig. - De grootste UX-valkuil voor gebruikers is dat AppImage-bestand na het downloaden. Geloof het of niet, dit is voor sommigen een echte barrière. De noodzaak om de uitvoerbaarheidsbit in te stellen is zelfs voor ervaren gebruikers omslachtig. Als tijdelijke oplossing hebben we voorgesteld een kleine service te installeren die AppImage-bestanden controleert en hun uitvoerbaarheidsbit instelt. In zijn pure vorm is het niet de beste oplossing, omdat het niet out-of-the-box zal werken. Linux-distributies bieden deze service niet, daarom hebben gebruikers standaard een slechte ervaring.
- Linux-gebruikers verwachten dat een nieuwe applicatie een pictogram in het opstartmenu heeft. Je kunt niet tegen het systeem zeggen: “Kijk, er is een nieuwe applicatie, laten we aan de slag gaan.” In plaats daarvan moet u volgens de XDG-specificatie het bestand kopiëren
.desktopnaar de juiste plek binnen/usrvoor een systeembrede installatie, of in$HOMEvoor individu. Pictogrammen van bepaalde afmetingen moeten volgens de XDG-specificatie op bepaalde plaatsen worden geplaatstusrof$HOME, en voer vervolgens opdrachten uit in de werkomgeving om de pictogramcache bij te werken, of hoop dat de werkomgevingmanager dit zal uitzoeken en alles automatisch zal detecteren. Hetzelfde met MIME-typen. Als tijdelijke oplossing wordt voorgesteld om dezelfde service te gebruiken, die, naast het instellen van de uitvoerbaarheidsvlag, ook als er pictogrammen zijn, enz. in AppImage kopieert u ze vanuit AppImage naar de juiste plaatsen volgens XDG. Wanneer het wordt verwijderd of verplaatst, wordt van de service verwacht dat alles wordt gewist. Natuurlijk zijn er verschillen in het gedrag van elke werkomgeving, in grafische bestandsformaten, hun grootte, opslaglocaties en methoden voor het bijwerken van caches, wat een probleem veroorzaakt. Kortom, deze methode is een kruk. - Als het bovenstaande niet genoeg is, is er nog steeds geen AppImage-pictogram in Bestandsbeheer. De Linux-wereld heeft nog niet besloten om elficon te implementeren (ondanks... и ), dus het is onmogelijk om het pictogram rechtstreeks in de applicatie in te sluiten. Het blijkt dus dat applicaties in bestandsbeheer geen eigen iconen hebben (geen verschil, AppImage of iets anders), ze staan alleen in het startmenu. Als oplossing gebruiken we thumbnails, een mechanisme dat oorspronkelijk is ontworpen om desktopmanagers in staat te stellen miniatuurvoorbeelden van grafische bestanden als pictogrammen weer te geven. Bijgevolg werkt de service voor het instellen van de uitvoerbaarheidsbit ook als een “miniaturizer”, waarbij pictogramminiaturen worden gemaakt en geschreven naar de juiste locaties
/usrи$HOME. Deze service voert ook een opschoning uit als de AppImage wordt verwijderd of verplaatst. Vanwege het feit dat elke desktopmanager zich iets anders gedraagt, bijvoorbeeld in welke formaten hij pictogrammen accepteert, in welke maten of op welke plaatsen, is dit allemaal erg pijnlijk. - De applicatie crasht eenvoudigweg tijdens de uitvoering als er fouten optreden (er is bijvoorbeeld een bibliotheek die geen deel uitmaakt van het basissysteem en niet wordt geleverd in AppImage), en er is niemand die de gebruiker in de GUI vertelt wat er precies gebeurt. We begonnen dit te omzeilen door gebruik te maken van op het bureaublad, wat betekent dat we fouten vanaf de opdrachtregel moeten opvangen en deze moeten omzetten in door de gebruiker begrepen berichten, die vervolgens op het bureaublad moeten worden weergegeven. En natuurlijk verwerkt elke desktopomgeving ze een beetje anders.
- Op dit moment (september 2019 - opmerking van de vertaler) heb ik geen eenvoudige manier gevonden om het systeem te vertellen dat het bestand
1.pngmoet worden geopend met Krita, en2.png- GIMP gebruiken.
Opslaglocatie voor cross-desktop specificaties gebruikt in , и is freedesktop.org
Het bereiken van het niveau van verfijning dat diep verweven is met de Haiku-werkomgeving is moeilijk, zo niet onmogelijk, vanwege de specificaties voor cross-desktop, evenals implementaties van desktopmanagers op basis van deze specificaties. Als voorbeeld kunnen we één systeembreed Firefox-pictogram noemen: blijkbaar dachten de auteurs van XDG niet eens dat een gebruiker meerdere versies van dezelfde applicatie geïnstalleerd kon hebben.
Pictogrammen voor verschillende versies van Firefox
Ik vroeg me af wat de Linux-wereld van Mac OS X zou kunnen leren om te voorkomen dat de systeemintegratie in de war zou raken. Als je tijd hebt en hierin geïnteresseerd bent, lees dan zeker wat Arnaud Gurdol, een van de eerste Mac OS X-ingenieurs, zei:
We wilden het installeren van de applicatie net zo eenvoudig maken als het slepen van het applicatiepictogram van ergens (server, externe schijf) naar uw computerstation. Om dit te doen, slaat het applicatiepakket alle informatie op, inclusief pictogrammen, versie, bestandstype dat wordt verwerkt en het type URL-schema's dat het systeem moet kennen om de applicatie te verwerken. Hieronder valt ook informatie voor ‘centrale opslag’ in de database Icon Services en Launch Services. Om de prestaties te ondersteunen, worden applicaties op verschillende 'bekende' plaatsen 'ontdekt': de mappen met systeem- en gebruikersapplicaties, en enkele andere automatisch als de gebruiker naar de Finder navigeert in de directory die de applicatie bevat. In de praktijk werkte dit heel goed.
Apple WWDC 2000 sessie 144 - Mac OS X: applicaties verpakken en documenten afdrukken.
Er gaat niets boven deze infrastructuur op Linux-desktops, dus we zijn op zoek naar oplossingen voor de structurele beperkingen in het AppImage-project.
Komt Haiku te hulp?
En nog één ding: Linux-platforms als basis van desktopomgevingen zijn vaak zo ondergespecificeerd dat veel dingen die vrij eenvoudig zijn in een consistent full-stack-systeem, in Linux frustrerend gefragmenteerd en complex zijn. Ik heb een heel rapport gewijd aan problemen met betrekking tot het Linux-platform voor desktopomgevingen (deskundige ontwikkelaars hebben bevestigd dat alles nog heel lang zo zal blijven).
Mijn rapport over de problemen van Linux-desktopomgevingen in 2018
Zelfs Linus Torvalds gaf toe dat fragmentatie de reden was waarom het idee van de werkruimte mislukte.
Leuk om te zien Haiku!
Haiku maakt alles verbazingwekkend eenvoudig
Hoewel de naïeve benadering van het "porteren" van AppImage naar Haiku bestaat uit simpelweg proberen de componenten ervan te bouwen (voornamelijk runtime.c en service) (wat misschien zelfs mogelijk is!), Zal dit Haiku niet veel voordeel opleveren. Omdat in feite de meeste van deze problemen in Haiku worden opgelost en conceptueel verantwoord zijn. Haiku biedt precies de bouwstenen voor de systeeminfrastructuur waar ik al zo lang naar op zoek ben in Linux-desktopomgevingen en waarvan ik niet kon geloven dat ze er niet waren. Namelijk:
Geloof het of niet, dit is iets dat veel Linux-gebruikers niet kunnen overwinnen. Op Haiku gebeurt alles automatisch!
- ELF-bestanden die geen uitvoerbaarheidsbit hebben, krijgen er automatisch een wanneer u dubbelklikt in Bestandsbeheer.
- Applicaties kunnen ingebouwde bronnen hebben, zoals pictogrammen, die worden weergegeven in Bestandsbeheer. Het is niet nodig om een hele reeks afbeeldingen naar speciale mappen met pictogrammen te kopiëren, en dus ook niet om ze op te ruimen na het verwijderen of verplaatsen van de applicatie.
- Er is een database voor het koppelen van applicaties aan documenten, hiervoor hoeft u geen bestanden te kopiëren.
- In de map lib/ naast het uitvoerbare bestand worden standaard bibliotheken doorzocht.
- Er zijn geen talloze distributies en desktopomgevingen; wat werkt, werkt overal.
- Er is geen aparte module om uit te voeren die verschilt van de map Toepassingen.
- Applicaties hebben geen ingebouwde absolute paden naar hun bronnen; ze hebben speciale functies voor het bepalen van de locatie tijdens runtime.
- Het idee van gecomprimeerde bestandssysteemafbeeldingen is geïntroduceerd: dit is elk hpkg-pakket. Ze worden allemaal door de kernel aangekoppeld.
- Elk bestand wordt geopend door de toepassing die het heeft gemaakt, tenzij u expliciet anders aangeeft. Hoe cool is dit!
Twee png-bestanden. Let op de verschillende pictogrammen die aangeven dat ze door verschillende toepassingen worden geopend als er dubbel op wordt geklikt. Let ook op het vervolgkeuzemenu "Openen met:", waarin de gebruiker een individuele applicatie kan selecteren. Hoe eenvoudig!
Het lijkt erop dat veel van de hulpmiddelen en oplossingen die AppImage op Linux nodig heeft, overbodig worden op Haiku, dat de eenvoud en verfijning in de kern heeft waardoor het in de meeste van onze behoeften kan voorzien.
Heeft Haiku toch app-pakketten nodig?
Dit leidt tot een grote vraag. Als het een orde van grootte eenvoudiger zou zijn om een systeem als AppImage op Haiku te maken dan op Linux, zou het dan de moeite waard zijn? Of heeft Haiku met zijn hpkg-pakketsysteem de noodzaak om een dergelijk idee te ontwikkelen effectief geëlimineerd? Om dit te kunnen beantwoorden moeten we kijken naar de motivatie achter het bestaan van AppImages.
Het perspectief van de gebruiker
Laten we eens kijken naar onze eindgebruiker:
- Ik wil een applicatie installeren zonder om een beheerderswachtwoord (root) te vragen. Er is geen concept van een beheerder op Haiku, de gebruiker heeft volledige controle omdat het een persoonlijk systeem is! (In principe kun je je dit voorstellen in de multiplayer-modus, ik hoop dat de ontwikkelaars het simpel houden)
- Ik wil de nieuwste en beste versies van applicaties krijgen, zonder te wachten tot ze in mijn distributie verschijnen (meestal betekent dit “nooit”, tenminste tenzij ik het hele besturingssysteem update). Op Haiku wordt dit "opgelost" met zwevende releases. Dit betekent dat het mogelijk is om de nieuwste en beste versies van applicaties te krijgen, maar om dit te doen moet je de rest van het systeem voortdurend updaten, waardoor het in feite een “bewegend doelwit” wordt..
- Ik wil verschillende versies van dezelfde applicatie naast elkaar, omdat er geen manier is om te weten wat er in de nieuwste versie kapot is, of ik, bijvoorbeeld, als webontwikkelaar mijn werk moet testen onder verschillende versies van de browser. Haiku lost het eerste probleem op, maar niet het tweede. Updates worden teruggedraaid, maar alleen voor het hele systeem; het is (voor zover ik weet) onmogelijk om bijvoorbeeld meerdere versies van WebPositive of LibreOffice tegelijkertijd te draaien.
Een van de ontwikkelaars schrijft:
In wezen is de redenering deze: de use case is zo zeldzaam dat het optimaliseren ervan geen zin heeft; het behandelen ervan als een speciaal geval in HaikuPorts lijkt meer dan acceptabel.
- Ik moet apps bewaren waar ik ze leuk vind, niet op mijn opstartschijf. Ik heb vaak onvoldoende schijfruimte, dus moet ik een externe schijf of netwerkmap aansluiten om applicaties op te slaan (alle versies die ik heb gedownload). Als ik zo'n schijf aansluit, moet ik applicaties starten door te dubbelklikken. Haiku bewaart oude versies van pakketten, maar ik weet niet hoe ik ze naar een externe schijf moet verplaatsen, of hoe ik daar later applicaties moet starten.
Commentaar van de ontwikkelaar:
Technisch gezien is dit al mogelijk met het mount-commando. Uiteraard maken wij hiervoor een GUI zodra we voldoende geïnteresseerde gebruikers hebben.
- Ik heb geen miljoenen bestanden nodig die verspreid zijn over het bestandssysteem en die ik niet zelf handmatig kan beheren. Ik wil één bestand per applicatie dat ik eenvoudig kan downloaden, verplaatsen en verwijderen. Op Haiku wordt dit probleem opgelost met behulp van pakketten
.hpkg, die bijvoorbeeld Python van duizenden bestanden naar één overzet. Maar als er bijvoorbeeld Scribus is die Python gebruikt, dan heb ik te maken met minstens twee bestanden. En ik moet ervoor zorgen dat versies ervan behouden die met elkaar werken.
Meerdere versies van AppImages draaien naast elkaar op dezelfde Linux
Het perspectief van een applicatieontwikkelaar
Laten we eens kijken vanuit het standpunt van een applicatieontwikkelaar:
- Ik wil de volledige gebruikerservaring beheersen. Ik wil niet afhankelijk zijn van een besturingssysteem dat mij vertelt wanneer en hoe ik applicaties moet vrijgeven. Met Haiku kunnen ontwikkelaars met hun eigen hpkg-repository's werken, maar dit betekent dat gebruikers deze handmatig moeten instellen, wat het idee "minder aantrekkelijk" maakt.
- Ik heb een downloadpagina op mijn website waar ik distribueer
.exevoor ramen,.dmgvoor Mac en.AppImagevoor Linux. Of misschien wil ik inkomsten genereren met de toegang tot deze pagina, alles is mogelijk? Wat moet ik daar voor Haiku zetten? Het bestand is voldoende.hpkgmet alleen afhankelijkheden van HaikuPorts - Mijn software vereist specifieke versies van andere software. Het is bijvoorbeeld bekend dat Krita een gepatchte versie van Qt vereist, of Qt die is afgestemd op een specifieke versie van Krita, tenminste totdat de patches terug naar Qt worden geduwd. U kunt uw eigen Qt voor uw toepassing verpakken in een pakket
.hpkg, maar hoogstwaarschijnlijk is dit niet welkom.
Reguliere downloadpagina voor applicaties. Wat moet ik hier posten voor Haiku?
Zullen bundels (bestaand als applicatiemappen zoals AppDir of .app in Apple-stijl) en/of afbeeldingen (in de vorm van sterk aangepaste AppImages of .dmg van Apple) applicaties een nuttige aanvulling op de Haiku-desktopomgeving? Of zal het het hele plaatje verwateren en tot fragmentatie leiden, en daardoor de complexiteit vergroten? Ik ben verscheurd: aan de ene kant zijn de schoonheid en verfijning van Haiku gebaseerd op het feit dat er meestal één manier is om iets te doen, en niet veel. Aan de andere kant is het grootste deel van de infrastructuur voor catalogi en/of applicatiesuites al aanwezig, dus het systeem schreeuwt om de resterende paar procent.
Volgens de ontwikkelaar
Op Linux zij (catalogi en applicatiekits, - ca. vertaler) zijn hoogstwaarschijnlijk een technische oplossing voor systemische problemen. Bij Haiku lossen we systeemproblemen het liefst simpelweg op.
Wat denk je?
Voordat je antwoordt...
Wacht, laten we een snelle realiteitscheck doen: in feite applicatiemappen - maakt al deel uit van Haiku:
Applicatiemappen bestaan al op Haiku, maar worden nog niet ondersteund in Bestandsbeheer
Ze worden gewoon niet zo goed ondersteund als bijvoorbeeld de Macintosh Finder. Hoe cool zou het zijn als de QtCreator-map een "QtCreator"-naam en een pictogram in de linkerbovenhoek had, waardoor de toepassing zou worden gestart als er dubbel op werd geklikt?
Iets eerder heb ik al :
Weet u zeker dat u uw tien jaar oude apps vandaag nog kunt gebruiken als alle appstores en distributiebronnen ze en hun afhankelijkheden zijn vergeten? Heeft u er vertrouwen in dat u in de toekomst nog steeds toegang zult hebben tot uw huidige baan?
Is er al een antwoord van Haiku, of kunnen catalogi en applicatiebundels hier helpen? Ik denk dat ze dat kunnen.
Volgens dhr. waggelplons:
Ja, wij hebben het antwoord op de vraag: wij ondersteunen deze applicaties gewoon zo lang als nodig is, totdat iemand zijn bestandsformaten op de juiste manier kan lezen of één-op-één functionaliteit kan bieden. Onze inzet om BeOS R5-apps op Haiku te ondersteunen is hiervan het bewijs...
Dat klopt!
Welke handelwijze moet Haiku volgen?
Ik kan me het vreedzaam naast elkaar bestaan van hpkg, mappen en applicatie-images voorstellen:
- Systeemsoftware gebruikt
.hpkg - Gebruik voor de meest gebruikte software (vooral software waarvoor rollende releases moeten worden gepland).
.hpkg(ongeveer 80% van alle gevallen) - Sommige geïnstalleerd via
.hpkg, zullen applicaties profiteren van het verhuizen naar een applicatiedirectory-infrastructuur (bijv. QtCreator): ze zullen worden gedistribueerd als.hpkg, zoals eerder.
Dhr. Waddlesplash schrijft:
Als u alleen maar applicaties wilt bekijken in
/system/apps, in plaats daarvan zouden we de mappen in Deskbar beter beheersbaar moeten maken voor gebruikers, sindsdien/system/appsis niet bedoeld om regelmatig door gebruikers te worden geopend en bekeken (in tegenstelling tot MacOS). Voor dergelijke situaties heeft Haiku een ander paradigma, maar deze optie is in theorie acceptabel.
- Haiku ontvangt de infrastructuur voor het uitvoeren van applicatie-images, nachtelijke, continue en testbuilds van software, maar ook voor gevallen waarin de gebruiker het op tijd wil bevriezen, voor privé- en interne software, en andere speciale gebruiksscenario's (ongeveer 20% van allemaal). Deze afbeeldingen bevatten de bestanden die nodig zijn om de applicatie uit te voeren
.hpkg, aangekoppeld door het systeem, en nadat de applicatie is voltooid: ontkoppeld. (Misschien kan een bestandsbeheerder bestanden.hpkgin applicatie-images, automatisch of op verzoek van de gebruiker - nou ja, zoals wanneer u een applicatie naar een netwerkmap of externe schijf sleept. Het is maar een lied! Of beter gezegd, poëzie - haiku.) Aan de andere kant wil de gebruiker misschien de inhoud van de afbeelding installeren in de vorm van bestanden.hpkg, waarna ze op dezelfde manier worden bijgewerkt en verwerkt alsof ze via HaikuDepot zijn geïnstalleerd... We moeten even brainstormen).
Citaat van dhr. waggelplons:
Het kan nuttig zijn om toepassingen uit te voeren vanaf externe schijven of netwerkmappen. En het toevoegen van de mogelijkheid om meer "zones" voor pkgman te configureren zou zeker een leuke functie zijn.
Een dergelijk systeem zou profiteren van hpkg, mappen en applicatie-images. Individueel zijn ze goed, maar samen zullen ze onoverwinnelijk worden.
Conclusie
Haiku heeft een raamwerk dat een eenvoudige en geavanceerde gebruikerservaring voor de pc biedt, en veel verder gaat dan wat doorgaans voor de Linux-pc wordt geboden. Pakketsysteem .hpkg is zo'n voorbeeld, maar de rest van het systeem is ook doordrenkt van verfijning. Haiku zou echter profiteren van de juiste ondersteuning voor directory- en applicatie-images. Hoe je dit het beste kunt doen, is het waard om te bespreken met mensen die Haiku, zijn filosofie en architectuur veel beter kennen dan ik. Ik gebruik Haiku tenslotte al iets meer dan een week. Niettemin geloof ik dat de ontwerpers, ontwikkelaars en architecten van Haiku zullen profiteren van dit frisse perspectief. Ik zou op zijn minst graag hun ‘sparringpartner’ zijn. Ik heb meer dan 10 jaar praktische ervaring met Linux-applicatiecatalogi en -bundels, en ik zou er graag een toepassing voor willen vinden in Haiku, waarvoor ik denk dat ze perfect passen. De mogelijke oplossingen die ik heb voorgesteld zijn zeker niet de enige juiste voor de problemen die ik heb beschreven, en als het Haiku-team besluit andere, elegantere oplossingen te vinden, ben ik er helemaal voor. Eigenlijk denk ik al na over het idee hoe ik een systeem kan maken hpkg nog verbazingwekkender zonder de manier waarop het werkt te veranderen. Het blijkt dat het Haiku-team al lang aan applicatiebundels dacht bij de implementatie van een pakketbeheersysteem, maar helaas (denk ik) werd het idee "achterhaald". Misschien is het tijd om het nieuw leven in te blazen?
Probeer het zelf! Het Haiku-project levert immers gegenereerde afbeeldingen voor het opstarten vanaf dvd of USB .
Heb je nog vragen? Wij nodigen u uit voor de Russischtalige .
Foutoverzicht:
Van vertaling: dit is het achtste en laatste artikel in de serie over Haiku.
Lijst met artikelen:
Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. , Alsjeblieft.
Heeft het zin om het hpkg-systeem naar Linux te porten?
-
Ja
-
Geen
-
Al geïmplementeerd, ik zal in de reacties schrijven
20 gebruikers hebben gestemd. 5 gebruikers onthielden zich van stemming.
Bron: www.habr.com