Noe annet: Haiku-apppakker?

TL; DR: Kan Haiku få riktig støtte for applikasjonspakker, for eksempel applikasjonskataloger (som .app på Mac) og/eller applikasjonsbilder (Linux AppImage)? Jeg tror dette vil være et verdig tillegg som er enklere å implementere riktig enn andre systemer siden det meste av infrastrukturen allerede er på plass.

En uke siden Jeg oppdaget Haiku, et uventet bra system. Vel, siden jeg lenge har vært interessert i kataloger og applikasjonsbilder (inspirert av enkelheten til Macintosh), er det ikke overraskende at en idé kom til meg...

For full forståelse er jeg skaperen og forfatteren av AppImage, et Linux-applikasjonsdistribusjonsformat som tar sikte på Mac-enkelhet og gir full kontroll til applikasjonsforfattere og sluttbrukere (hvis du vil vite mer, se wiki и dokumentasjon).

Hva om vi lager et AppImage for Haiku?

La oss tenke litt, rent teoretisk: hva må gjøres for å få AppImage, eller noe lignende, på Haiku? Det er ikke nødvendig å lage noe akkurat nå, fordi systemet som allerede eksisterer i Haiku fungerer utrolig, men et tenkt eksperiment ville vært fint. Det demonstrerer også sofistikeringen til Haiku, sammenlignet med Linux-skrivebordsmiljøer, hvor slike ting er fryktelig vanskelige (jeg har rett til å si det: Jeg har slitt med feilsøking i 10 år).

På Macintosh System 1 var hvert program en separat fil "administrert" i Finder. Ved å bruke AppImage prøver jeg å gjenskape den samme brukeropplevelsen på Linux.

For det første, hva er et AppImage? Dette er et system for utgivelse av tredjepartsapplikasjoner (f.eks. Ultimaker Cure), slik at applikasjoner kan utgis når og hvordan de vil: det er ikke nødvendig å vite spesifikasjonene for ulike distribusjoner, byggepolicyer eller bygge infrastruktur, ingen vedlikeholdsstøtte er nødvendig, og de forteller ikke brukerne hva (ikke) de kan installere på datamaskinene deres. AppImage skal forstås som noe som ligner på en Mac-pakke i formatet .app inne i diskbildet .dmg. Hovedforskjellen er at applikasjoner ikke kopieres, men forblir inne i AppImage for alltid, omtrent det samme som Haiku-pakker .hpkg montert, og aldri installert i vanlig forstand.

I løpet av mer enn 10 års eksistens har AppImage fått en viss appell og popularitet: Linus Torvalds selv støttet det offentlig, og vanlige prosjekter (for eksempel LibreOffice, Krita, Inkscape, Scribus, ImageMagick) har tatt det i bruk som hovedmåten å distribuere kontinuerlige eller nattlige bygg, uten å forstyrre installerte eller avinstallerte brukerapplikasjoner. Linux-skrivebordsmiljøer og -distribusjoner klamrer seg imidlertid oftest fortsatt til den tradisjonelle, sentraliserte vedlikeholdsbaserte distribusjonsmodellen og/eller markedsfører sin egen bedriftsvirksomhet og/eller ingeniørprogrammer basert på Flatpak (RedHat, Fedora, GNOME) og Snappy (Canonical, Ubuntu). Det kommer latterlig.

Hvordan virker det

• Hvert AppImage inneholder 2 deler: en liten dobbeltklikk ELF (såkalt. runtime.c), etterfulgt av et filsystembilde SquashFS.

• SquashFS-filsystemet inneholder nyttelasten til applikasjonen og alt som trengs for å kjøre det, som med riktig sinn ikke kan betraktes som en del av standardinstallasjonen for hvert ganske nyere målsystem (Linux-distribusjon). Den inneholder også metadata, for eksempel applikasjonsnavn, ikoner, MIME-typer, etc., etc.

• Når den kjøres av brukeren, bruker runtime FUSE og squashfuse for å montere filsystemet, og håndterer deretter å kjøre et inngangspunkt (aka AppRun) inne i det monterte AppImage.
  Filsystemet demonteres etter at prosessen er fullført.

Alt virker enkelt.

Og disse tingene kompliserer alt:

• Med en slik variasjon av Linux-distribusjoner kan ingenting "med riktig sinn" kalles "en del av standardinstallasjonen for hvert nytt målsystem." Vi jobber rundt dette problemet ved å bygge ekskluderingsliste, slik at du kan bestemme hva som skal pakkes i AppImage og hva som må tas med et annet sted. Samtidig savner vi noen ganger, til tross for at alt generelt fungerer utmerket. Av denne grunn anbefaler vi at pakkeskapere tester AppImages på alle målsystemer (distribusjoner).
• Applikasjonsnyttelaster må kunne flyttes på tvers av filsystemet. Dessverre har mange applikasjoner hardkodede absolutte veier til for eksempel ressurser i /usr/share. Dette må fikses på en eller annen måte. I tillegg må du enten eksportere LD_LIBRARY_PATH, eller fikse rpath slik at lasteren kan finne relaterte biblioteker. Den første metoden har sine ulemper (som overvinnes på komplekse måter), og den andre er ganske enkelt tungvint.
• Den største UX-fallgruven for brukere er det angi kjørbar bit AppImage-fil etter nedlasting. Tro det eller ei, dette er en reell barriere for noen. Behovet for å angi kjørbarhetsbiten er tungvint selv for erfarne brukere. Som en løsning foreslo vi å installere en liten tjeneste som overvåker AppImage-filer og angir kjørbarhetsbiten deres. I sin rene form er det ikke den beste løsningen, siden det ikke vil fungere ut av esken. Linux-distribusjoner gir ikke denne tjenesten, derfor har brukere en dårlig opplevelse rett ut av esken.
• Linux-brukere forventer at en ny applikasjon har et ikon i oppstartsmenyen. Du kan ikke fortelle systemet: "Se, det er en ny applikasjon, la oss jobbe." I stedet, i henhold til XDG-spesifikasjonen, må du kopiere filen .desktop til rett plass i /usr for en systemomfattende installasjon, eller i $HOME for individuelle. Ikoner av visse størrelser, i henhold til XDG-spesifikasjonen, må plasseres på bestemte steder i usr eller $HOME, og kjør deretter kommandoer i arbeidsmiljøet for å oppdatere ikonbufferen, eller håper at arbeidsmiljølederen vil finne ut av det og automatisk oppdage alt. Samme med MIME-typer. Som en løsning foreslås det å bruke samme tjeneste, som i tillegg til å sette kjørbarhetsflagget vil, hvis det er ikoner mv. i AppImage, kopier dem fra AppImage til de riktige stedene i henhold til XDG. Når den slettes eller flyttes, forventes tjenesten å fjerne alt. Selvfølgelig er det forskjeller i oppførselen til hvert arbeidsmiljø, i grafiske filformater, deres størrelser, lagringsplasseringer og metoder for oppdatering av cacher, noe som skaper et problem. Kort sagt, denne metoden er en krykke.
• Hvis det ovennevnte ikke er nok, er det fortsatt ikke noe AppImage-ikon i filbehandleren. Linux-verdenen har ennå ikke bestemt seg for å implementere elficon (til tross for diskusjon и gjennomføring), så det er umulig å bygge inn ikonet direkte i applikasjonen. Så det viser seg at applikasjoner i filbehandleren ikke har sine egne ikoner (ingen forskjell, AppImage eller noe annet), de er kun i startmenyen. Som en løsning bruker vi miniatyrbilder, en mekanisme som opprinnelig ble utviklet for å tillate skrivebordsadministratorer å vise forhåndsvisning av miniatyrbilder av grafikkfiler som ikoner. Følgelig fungerer tjenesten for innstilling av kjørbarhetsbiten også som en "miniaturizer", og lager og skriver ikonminiatyrbilder til de riktige stedene /usr и $HOME. Denne tjenesten utfører også opprydding hvis AppImage slettes eller flyttes. På grunn av det faktum at hver skrivebordsadministrator oppfører seg litt annerledes, for eksempel i hvilke formater den godtar ikoner, i hvilke størrelser eller steder, er dette veldig smertefullt.
• Applikasjonen krasjer ganske enkelt ved kjøring hvis det oppstår feil (for eksempel er det et bibliotek som ikke er en del av basissystemet og ikke leveres i AppImage), og det er ingen som forteller brukeren i GUI hva som skjer. Vi begynte å komme rundt dette ved å bruke varsler på skrivebordet, noe som betyr at vi må fange opp feil fra kommandolinjen, konvertere dem til brukerforståtte meldinger, som deretter må vises på skrivebordet. Og selvfølgelig håndterer hvert skrivebordsmiljø dem litt annerledes.
• For øyeblikket (september 2019 - oversetterens notat) har jeg ikke funnet en enkel måte å fortelle systemet at filen 1.png må åpnes med Krita, og 2.png - ved å bruke GIMP.

Lagringssted for spesifikasjoner på tvers av skrivebord brukt i GNOME, KDE и Xfce er freedesktop.org

Å oppnå det sofistikerte nivået som er dypt vevd inn i Haiku-arbeidsmiljøet er vanskelig, om ikke umulig, på grunn av spesifikasjonene XDG fra freedesktop.org for cross-desktop, samt implementeringer av desktop managers basert på disse spesifikasjonene. Som et eksempel kan vi sitere et systemomfattende Firefox-ikon: tilsynelatende trodde ikke forfatterne av XDG engang at en bruker kunne ha flere versjoner av samme applikasjon installert.

Ikoner for forskjellige versjoner av Firefox

Jeg lurte på hva Linux-verdenen kunne lære av Mac OS X for å unngå å ødelegge systemintegrasjonen. Hvis du har tid og er interessert i dette, sørg for å lese hva Arnaud Gurdol, en av de første Mac OS X-ingeniørene, sa:

Vi ønsket å gjøre installasjonen av applikasjonen like enkel som å dra applikasjonsikonet fra et sted (server, ekstern stasjon) til datamaskinens stasjon. For å gjøre dette, lagrer applikasjonspakken all informasjon, inkludert ikoner, versjon, filtype som behandles, type URL-skjemaer som systemet trenger å vite for å behandle applikasjonen. Dette inkluderer også informasjon for 'sentral lagring' i Icon Services og Launch Services-databasen. For å støtte ytelsen 'oppdages' applikasjoner på flere 'velkjente' steder: system- og brukerprogramkatalogene, og noen andre automatisk hvis brukeren navigerer til Finder i katalogen som inneholder applikasjonen. I praksis fungerte dette veldig bra.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 økt 144 - Mac OS X: pakkeapplikasjoner og utskrift av dokumenter.

Det er ingenting som denne infrastrukturen på Linux-stasjonære datamaskiner, så vi ser etter løsninger rundt de strukturelle begrensningene i AppImage-prosjektet.

Kommer Haiku til unnsetning?

Og en ting til: Linux-plattformer som grunnlag for skrivebordsmiljøer har en tendens til å være så underspesifisert at mange ting som er ganske enkle i et konsistent fullstacksystem er frustrerende fragmenterte og komplekse i Linux. Jeg viet en hel rapport til problemer knyttet til Linux-plattformen for skrivebordsmiljøer (kunnskapsrike utviklere bekreftet at alt vil forbli slik i veldig lang tid).

Min rapport om problemene med Linux-skrivebordsmiljøer i 2018

Til og med Linus Torvalds innrømmet at fragmentering var grunnen til at arbeidsromsideen mislyktes.

Hyggelig å se Haiku!

Haiku gjør alt utrolig enkelt

Mens den naive tilnærmingen til å "portere" AppImage til Haiku er å ganske enkelt prøve å bygge (hovedsakelig runtime.c og service) komponentene (noe som kanskje til og med er mulig!), vil ikke dette gi mye nytte for Haiku. For faktisk er de fleste av disse problemene løst i Haiku og er konseptuelt forsvarlige. Haiku gir nøyaktig de systeminfrastrukturbyggesteinene jeg har lett etter i Linux-skrivebordsmiljøer så lenge og kunne ikke tro at de ikke var der. Nemlig:

Tro det eller ei, dette er noe mange Linux-brukere ikke kan overvinne. På Haiku gjøres alt automatisk!

• ELF-filer som ikke har en kjørbarhetsbit får en automatisk når de dobbeltklikkes i filbehandlingen.
• Apper kan ha innebygde ressurser, for eksempel ikoner, som vises i filbehandlingen. Det er ikke nødvendig å kopiere en haug med bilder til spesielle kataloger med ikoner, og derfor ikke nødvendig å rydde opp etter at du har slettet eller flyttet programmet.
• Det er en database for å koble applikasjoner med dokumenter, det er ikke nødvendig å kopiere noen filer for dette.
• I lib/-katalogen ved siden av den kjørbare filen, søkes biblioteker som standard.
• Det finnes ikke mange distribusjoner og skrivebordsmiljøer; uansett hva som fungerer, fungerer det overalt.
• Det er ingen egen modul å kjøre som er forskjellig fra Applications-katalogen.
• Applikasjoner har ikke innebygde absolutte baner til ressursene sine; de ​​har spesielle funksjoner for å bestemme plasseringen ved kjøring.
• Ideen om komprimerte filsystembilder har blitt introdusert: dette er en hvilken som helst hpkg-pakke. Alle er montert av kjernen.
• Hver fil åpnes av programmet som opprettet den, med mindre du eksplisitt spesifiserer noe annet. Hvor kult er dette!

To png-filer. Legg merke til de forskjellige ikonene som indikerer at de vil bli åpnet av forskjellige programmer når de dobbeltklikkes. Legg også merke til rullegardinmenyen "Åpne med:" der brukeren kan velge en individuell applikasjon. Hvor enkelt!

Det ser ut til at mange av krykkene og løsningene som kreves av AppImage på Linux blir unødvendige på Haiku, som har enkelheten og sofistikasjonen i kjernen som gjør at den håndterer de fleste behovene våre.

Trenger Haiku apppakker tross alt?

Dette leder til et stort spørsmål. Hvis det var en størrelsesorden enklere å lage et system som AppImage på Haiku enn på Linux, ville det vært verdt å gjøre det? Eller har Haiku, med sitt hpkg-pakkesystem, effektivt eliminert behovet for å utvikle en slik idé? Vel, for å svare må vi se på motivasjonen bak eksistensen av AppImages.

Brukerens perspektiv

La oss se på sluttbrukeren vår:

• Jeg ønsker å installere en applikasjon uten å be om et administrator (root) passord. Det er ikke noe konsept for en administrator på Haiku, brukeren har full kontroll da det er et personlig system! (I prinsippet kan du forestille deg dette i flerspillermodus, jeg håper utviklerne holder det enkelt)
• Jeg ønsker å få de nyeste og beste versjonene av applikasjoner, uten å vente på at de skal vises i distribusjonen min (oftest betyr dette "aldri", i det minste med mindre jeg oppdaterer hele operativsystemet). På Haiku er dette "løst" med flytende utgivelser. Dette betyr at det er mulig å få de nyeste og beste versjonene av applikasjoner, men for å gjøre dette må du hele tiden oppdatere resten av systemet, og effektivt gjøre det til et "bevegelig mål".
• Jeg vil ha flere versjoner av samme applikasjon side om side, siden det ikke er mulig å vite hva som ble ødelagt i den nyeste versjonen, eller for eksempel, jeg som nettutvikler må teste arbeidet mitt under forskjellige versjoner av nettleseren. Haiku løser det første problemet, men ikke det andre. Oppdateringer rulles tilbake, men kun for hele systemet, det er umulig (så vidt jeg vet) å kjøre for eksempel flere versjoner av WebPositive eller LibreOffice samtidig.

En av utviklerne skriver:

Begrunnelsen er i hovedsak dette: brukstilfellet er så sjeldent at det ikke gir mening å optimalisere for det; å behandle det som et spesielt tilfelle i HaikuPorts virker mer enn akseptabelt.

• Jeg må beholde appene der jeg liker dem, ikke på oppstartsstasjonen. Jeg går ofte tom for diskplass, så jeg må koble til en ekstern stasjon eller nettverkskatalog for å lagre programmer (alle versjoner jeg har lastet ned). Hvis jeg kobler til en slik stasjon, trenger jeg at applikasjoner startes ved å dobbeltklikke. Haiku lagrer gamle versjoner av pakker, men jeg vet ikke hvordan jeg skal flytte dem til en ekstern stasjon, eller hvordan jeg skal starte applikasjoner derfra senere.

Utviklerkommentar:

Teknisk sett er dette allerede mulig med mount-kommandoen. Vi vil selvfølgelig lage en GUI for dette så snart vi har nok interesserte brukere.

• Jeg trenger ikke millioner av filer spredt over filsystemet som jeg ikke kan håndtere manuelt selv. Jeg vil ha én fil per applikasjon som jeg enkelt kan laste ned, flytte, slette. På Haiku løses dette problemet ved hjelp av pakker .hpkg, som overfører for eksempel python fra tusenvis av filer til én. Men hvis det for eksempel er Scribus som bruker python, så må jeg forholde meg til minst to filer. Og jeg må passe på å beholde versjoner av dem som fungerer med hverandre.

Flere versjoner av AppImages kjører side ved side på samme Linux

En applikasjonsutviklers perspektiv

La oss se fra en applikasjonsutviklers synspunkt:

• Jeg ønsker å kontrollere hele brukeropplevelsen. Jeg vil ikke være avhengig av et operativsystem for å fortelle meg når og hvordan jeg bør utgi programmer. Haiku lar utviklere jobbe med sine egne hpkg-depoter, men dette betyr at brukerne må sette dem opp manuelt, noe som gjør ideen "mindre attraktiv."
• Jeg har en nedlastingsside på nettstedet mitt hvor jeg distribuerer .exe for Windows, .dmg for Mac og .AppImage for Linux. Eller kanskje jeg vil tjene penger på tilgang til denne siden, alt er mulig? Hva skal jeg legge der for Haiku? Filen er nok .hpkg med avhengigheter kun fra HaikuPorts
• Programvaren min krever spesifikke versjoner av annen programvare. For eksempel er det kjent at Krita krever en lappet versjon av Qt, eller Qt som er finjustert til en spesifikk versjon av Krita, i det minste inntil lappene skyves tilbake i Qt. Du kan pakke din egen Qt for applikasjonen din i en pakke .hpkg, men mest sannsynlig er dette ikke velkomment.

Vanlig applikasjonsnedlastingsside. Hva skal jeg legge ut her for Haiku?

Vil bunter (eksisterer som applikasjonskataloger som AppDir eller .app i Apple-stil) og/eller bilder (i form av svært modifiserte AppImages eller .dmg fra Apple)-applikasjoner et nyttig tillegg til Haiku-skrivebordsmiljøet? Eller vil det utvanne hele bildet og føre til fragmentering, og derfor legge til kompleksitet? Jeg er revet: på den ene siden er skjønnheten og sofistikeringen til Haiku basert på det faktum at det vanligvis er én måte å gjøre noe på, i stedet for mange. På den annen side er det meste av infrastrukturen for kataloger og/eller applikasjonssuiter allerede på plass, så systemet roper på at de resterende få prosentene skal falle på plass.

Ifølge utvikleren MR. waddleplash

På Linux de (kataloger og påføringssett, - ca. oversetter) er mest sannsynlig en teknisk løsning på systemiske problemer. Hos Haiku foretrekker vi å bare løse systemproblemer.

Hva tror du?

Før du svarer...

Vent, la oss gjøre en rask realitetssjekk: faktisk applikasjonskataloger - allerede en del av Haiku:

Applikasjonskataloger finnes allerede på Haiku, men støttes ennå ikke i filbehandleren

De er bare ikke like godt støttet som for eksempel Macintosh Finder. Hvor kult ville det vært hvis QtCreator-katalogen hadde et "QtCreator"-navn og -ikon i øverste venstre hjørne, og starter programmet når det dobbeltklikkes?

Litt tidligere har jeg allerede spurte:

Er du sikker på at du kan kjøre dine tiår gamle apper i dag når alle appbutikker og distribusjonslagre har glemt dem og deres avhengigheter? Er du sikker på at du fortsatt vil kunne få tilgang til din nåværende jobb i fremtiden?

Finnes det allerede et svar fra Haiku, eller kan kataloger og applikasjonspakker hjelpe her? Jeg tror de kan.

I følge mr. waddlesplash:

Ja, vi har svaret på spørsmålet: vi vil ganske enkelt støtte disse applikasjonene så lenge det er nødvendig til noen kan lese filformatene deres på riktig måte eller tilby en-til-en-funksjonalitet. Vår forpliktelse til å støtte BeOS R5-apper på Haiku er et bevis på dette...

Det er sikkert!

Hvilken handling bør Haiku ta?

Jeg kan forestille meg den fredelige sameksistensen av hpkg, kataloger og applikasjonsbilder:

• Systemprogramvare bruker .hpkg
• For den mest brukte programvaren (spesielt de som trenger å planlegge rullende utgivelser), bruk .hpkg (omtrent 80 % av alle tilfeller)
• Noen installert via .hpkg, vil applikasjoner dra nytte av å flytte til en applikasjonskataloginfrastruktur (f.eks. QtCreator): de vil bli distribuert som .hpkg, som før.

MR. waddlesplash skriver:

Hvis alt du trenger er å se applikasjoner i /system/apps, i stedet bør vi gjøre katalogene i Deskbar mer håndterbare for brukere, siden /system/apps er ikke ment å bli regelmessig åpnet og sett av brukere (i motsetning til MacOS). For slike situasjoner har Haiku et annet paradigme, men dette alternativet er i teorien akseptabelt.

• Haiku mottar infrastrukturen for å kjøre applikasjonsbilder, nattlig, kontinuerlig og testbygging av programvare, samt for tilfeller der brukeren ønsker å "fryse den i tide", for privat og intern programvare, og andre spesielle brukstilfeller (ca. 20 % av alle). Disse bildene inneholder filene som er nødvendige for å kjøre programmet .hpkg, montert av systemet, og etter at applikasjonen er fullført - avmontert. (Kanskje en filbehandler kan legge inn filer .hpkg inn i applikasjonsbilder, automatisk eller på brukerens forespørsel - vel, som når du drar en applikasjon til en nettverkskatalog eller ekstern stasjon. Det er bare en sang! Eller rettere sagt, poesi - haiku.) På den annen side kan brukeren ønske å installere innholdet i bildet i form av filer.hpkg, hvoretter de vil bli oppdatert og behandlet på samme måte som om de ble installert gjennom HaikuDepot... Vi må brainstorme).

Sitat fra mr. waddlesplash:

Å kjøre applikasjoner fra eksterne stasjoner eller nettverkskataloger kan potensielt være nyttig. Og å legge til muligheten til å konfigurere flere "soner" for pkgman ville definitivt være en fin funksjon.

Et slikt system vil dra nytte av hpkg, kataloger og applikasjonsbilder. De er gode hver for seg, men sammen vil de bli uovervinnelige.

Konklusjon

Haiku har et rammeverk som gir en enkel og sofistikert brukeropplevelse for PC-en, og går langt utover det som vanligvis tilbys for Linux-PCen. Pakkesystem .hpkg er et slikt eksempel, men resten av systemet er også gjennomsyret av raffinement. Imidlertid vil Haiku ha nytte av riktig katalog- og programbildestøtte. Hvordan dette best kan gjøres er verdt å diskutere med folk som kjenner Haiku, dens filosofi og arkitektur mye bedre enn meg. Jeg har tross alt brukt Haiku i litt over en uke. Likevel tror jeg at Haikus designere, utviklere og arkitekter vil dra nytte av dette friske perspektivet. Jeg vil i det minste gjerne være deres «sparringspartner». Jeg har over 10 års praktisk erfaring med Linux-applikasjonskataloger og -bunter, og jeg vil gjerne finne en bruk for dem i Haiku, som jeg tror de passer perfekt for. De potensielle løsningene jeg har foreslått er på ingen måte de eneste riktige for problemene jeg har beskrevet, og hvis Haiku-teamet bestemmer seg for å finne andre, mer elegante, er jeg helt for det. I utgangspunktet tenker jeg allerede på ideen om hvordan man lager et system hpkg enda mer fantastisk uten å endre måten det fungerer på. Det viser seg at Haiku-teamet hadde tenkt på applikasjonsbunter lenge da de implementerte et pakkehåndteringssystem, men dessverre (tror jeg) ideen ble "foreldet". Kanskje det er på tide å gjenopplive det?

Prøv det selv! Tross alt gir Haiku-prosjektet bilder for oppstart fra DVD eller USB, generert daglig.
Har du noen spørsmål? Vi inviterer deg til den russisktalende telegramkanal.

Feiloversikt: Hvordan skyte deg selv i foten i C og C++. Haiku OS-oppskriftssamling

Fra forfatter oversettelse: dette er den åttende og siste artikkelen i serien om Haiku.

Liste over artikler: første Den andre tredje fjerde femte sjette Syvende

Kun registrerte brukere kan delta i undersøkelsen. Logg inn, vær så snill.

Er det fornuftig å portere hpkg-systemet til Linux?

• Ja

• Ikke

• Allerede implementert, vil jeg skrive i kommentarene

20 brukere stemte. 5 brukere avsto.

Kilde: www.habr.com