Qualcos'altro: bundle di app Haiku?

TL; DR: Haiku può ottenere il supporto adeguato per i pacchetti applicativi, come le directory delle applicazioni (come .app su Mac) e/o immagini di applicazioni (Linux AppImage)? Penso che questa sarebbe un'aggiunta degna e più facile da implementare correttamente rispetto ad altri sistemi poiché la maggior parte dell'infrastruttura è già operativa.

Una settimana fa Ho scoperto l'Haiku, un sistema inaspettatamente valido. Ebbene, poiché da tempo mi interessano le directory e le immagini delle applicazioni (ispirate dalla semplicità del Macintosh), non sorprende che mi sia venuta in mente un'idea...

Per una piena comprensione, sono il creatore e autore di AppImage, un formato di distribuzione di applicazioni Linux che punta alla semplicità del Mac e dà il pieno controllo agli autori delle applicazioni e agli utenti finali (se vuoi saperne di più, vedi wiki и documentazione).

E se creassimo un'AppImage per Haiku?

Pensiamo un po ', puramente teoricamente: cosa è necessario fare per ottenere AppImage, o qualcosa di simile, su Haiku? Non è necessario creare qualcosa adesso, perché il sistema già esistente nell'Haiku funziona in modo sorprendente, ma un esperimento immaginario sarebbe carino. Dimostra anche la sofisticatezza di Haiku, rispetto agli ambienti desktop Linux, dove queste cose sono terribilmente difficili (ho il diritto di dirlo: ho lottato con il debug per 10 anni).

Sul Macintosh System 1, ciascuna applicazione era un file separato "gestito" nel Finder. Utilizzando AppImage sto cercando di ricreare la stessa esperienza utente su Linux.

Innanzitutto, cos'è un'AppImage? Si tratta di un sistema per rilasciare applicazioni di terze parti (ad esempio, Cura Ultimaker), consentendo alle applicazioni di essere rilasciate quando e come vogliono: non è necessario conoscere le specifiche delle varie distribuzioni, creare policy o costruire infrastrutture, non è necessario il supporto del manutentore e non dicono agli utenti cosa (non) possono installare sui loro computer. AppImage dovrebbe essere inteso come qualcosa di simile a un pacchetto Mac nel formato .app all'interno dell'immagine del disco .dmg. La differenza principale è che le applicazioni non vengono copiate, ma rimangono per sempre all'interno di AppImage, proprio come i pacchetti Haiku .hpkg montato e mai installato nel senso comune.

Nel corso di oltre 10 anni di esistenza, AppImage ha acquisito un certo fascino e popolarità: lo stesso Linus Torvalds l'ha pubblicamente approvato e progetti comuni (ad esempio LibreOffice, Krita, Inkscape, Scribus, ImageMagick) lo hanno adottato come metodo principale per distribuire build continue o notturne, senza interferire con le applicazioni utente installate o disinstallate. Tuttavia, gli ambienti desktop e le distribuzioni Linux molto spesso si aggrappano ancora al tradizionale modello di distribuzione centralizzato basato sul manutentore e/o promuovono i propri programmi aziendali e/o di ingegneria basati su Flatpak (RedHat, Fedora, GNOME) e Elegante (Canonica, Ubuntu). Viene ridicolosamente.

Come funziona

• Ogni AppImage contiene 2 parti: un piccolo ELF a doppio clic (il cosiddetto. runtime.c), seguito da un'immagine del file system ZuccaFS.

• Il file system SquashFS contiene il payload dell'applicazione e tutto il necessario per eseguirla, che a buon diritto non può essere considerato parte dell'installazione predefinita per ogni sistema di destinazione abbastanza recente (distribuzione Linux). Contiene anche metadati, come il nome dell'applicazione, le icone, i tipi MIME, ecc. Ecc.

• Quando eseguito dall'utente, il runtime utilizza FUSE e squashfuse per montare il filesystem e quindi gestisce l'esecuzione di alcuni punti di ingresso (noti anche come AppRun) all'interno dell'AppImage montata.
  Il file system viene smontato al termine del processo.

Sembra tutto semplice.

E queste cose complicano tutto:

• Con una tale varietà di distribuzioni Linux, nulla che sia “sano” può essere definito “parte dell'installazione predefinita per ogni nuovo sistema di destinazione”. Risolviamo questo problema costruendo listaesclusa, permettendoti di determinare cosa verrà impacchettato nell'AppImage e cosa dovrà essere portato altrove. Allo stesso tempo, a volte ci manca, nonostante, in generale, tutto funzioni alla grande. Per questo motivo, consigliamo ai creatori di pacchetti di testare AppImages su tutti i sistemi di destinazione (distribuzioni).
• I payload dell'applicazione devono essere riposizionabili nel file system. Sfortunatamente, molte applicazioni hanno percorsi assoluti codificati, ad esempio, per le risorse in /usr/share. Questo deve essere risolto in qualche modo. Inoltre, è necessario esportare LD_LIBRARY_PATHo correggere rpath in modo che il caricatore possa trovare le librerie correlate. Il primo metodo ha i suoi inconvenienti (che vengono superati in modi complessi), mentre il secondo è semplicemente macchinoso.
• La più grande trappola UX per gli utenti è questa imposta il bit eseguibile File AppImage dopo il download. Che tu ci creda o no, questa è una vera barriera per alcuni. La necessità di impostare il bit di eseguibilità è scomoda anche per gli utenti esperti. Come soluzione alternativa, abbiamo suggerito di installare un piccolo servizio che monitora i file AppImage e ne imposta il bit di eseguibilità. Nella sua forma pura, non è la soluzione migliore, poiché non funzionerà immediatamente. Le distribuzioni Linux non forniscono questo servizio, pertanto gli utenti hanno una brutta esperienza fuori dagli schemi.
• Gli utenti Linux si aspettano che una nuova applicazione abbia un'icona nel menu di avvio. Non puoi dire al sistema: “Guarda, c’è una nuova applicazione, lavoriamo”. Invece, secondo le specifiche XDG, è necessario copiare il file .desktop al posto giusto /usr per un'installazione a livello di sistema o in $HOME per individuo. Le icone di determinate dimensioni, secondo le specifiche XDG, devono essere posizionate in determinati punti usr o $HOME, quindi esegui comandi nell'ambiente di lavoro per aggiornare la cache delle icone o spera che il gestore dell'ambiente di lavoro lo capisca e rilevi automaticamente tutto. Lo stesso con i tipi MIME. Per ovviare al problema, si propone di utilizzare lo stesso servizio che, oltre a impostare il flag di eseguibilità, se sono presenti icone, ecc. in AppImage, copiali da AppImage nei posti giusti secondo XDG. Quando viene eliminato o spostato, è previsto che il servizio cancelli tutto. Naturalmente, ci sono differenze nel comportamento di ciascun ambiente di lavoro, nei formati dei file grafici, nelle loro dimensioni, nelle posizioni di archiviazione e nei metodi di aggiornamento delle cache, il che crea un problema. In breve, questo metodo è una stampella.
• Se quanto sopra non è sufficiente, non è ancora presente l'icona AppImage nel file manager. Il mondo Linux non ha ancora deciso di implementare elficon (nonostante discussione и implementazione), quindi è impossibile incorporare l'icona direttamente nell'applicazione. Quindi risulta che le applicazioni nel file manager non hanno le proprie icone (nessuna differenza, AppImage o qualcos'altro), sono solo nel menu di avvio. Come soluzione alternativa, utilizziamo le miniature, un meccanismo originariamente progettato per consentire ai gestori di desktop di mostrare immagini di anteprima in miniatura di file grafici come icone. Di conseguenza, il servizio per l'impostazione del bit di eseguibilità funziona anche come “miniaturizzatore”, creando e scrivendo miniature di icone nelle posizioni appropriate /usr и $HOME. Questo servizio esegue anche la pulizia se l'AppImage viene eliminata o spostata. A causa del fatto che ogni desktop manager si comporta in modo leggermente diverso, ad esempio, in quali formati accetta le icone, in quali dimensioni o posizioni, tutto questo è davvero doloroso.
• L'applicazione si blocca semplicemente durante l'esecuzione se si verificano errori (ad esempio, c'è una libreria che non fa parte del sistema di base e non è fornita in AppImage) e non c'è nessuno che dica all'utente nella GUI cosa sta succedendo esattamente. Abbiamo iniziato a risolvere questo problema utilizzando preavviso sul desktop, il che significa che dobbiamo rilevare gli errori dalla riga di comando, convertirli in messaggi comprensibili all'utente, che devono quindi essere visualizzati sul desktop. E, naturalmente, ogni ambiente desktop li gestisce in modo leggermente diverso.
• Al momento (settembre 2019 - nota del traduttore) non ho trovato un modo semplice per dire al sistema che il file 1.png deve essere aperto utilizzando Krita e 2.png - utilizzando GIMP.

Posizione di archiviazione per le specifiche cross-desktop utilizzate in GNOME, KDE и Xfce è freedesktop.org

Raggiungere il livello di sofisticazione profondamente radicato nell'ambiente di lavoro Haiku è difficile, se non impossibile, a causa delle specifiche XDG da freedesktop.org per cross-desktop, nonché implementazioni di desktop manager basate su queste specifiche. Ad esempio, possiamo citare un'icona di Firefox a livello di sistema: a quanto pare, gli autori di XDG non pensavano nemmeno che un utente potesse avere più versioni installate della stessa applicazione.

Icone per diverse versioni di Firefox

Mi chiedevo cosa potrebbe imparare il mondo Linux da Mac OS X per evitare di rovinare l'integrazione del sistema. Se hai tempo e ti interessa, assicurati di leggere ciò che ha detto Arnaud Gurdol, uno dei primi ingegneri di Mac OS X:

Volevamo rendere l'installazione dell'applicazione semplice quanto trascinare l'icona dell'applicazione da qualche parte (server, unità esterna) sull'unità del computer. Per fare ciò, il pacchetto dell'applicazione memorizza tutte le informazioni, comprese le icone, la versione, il tipo di file in elaborazione, il tipo di schemi URL che il sistema deve conoscere per elaborare l'applicazione. Ciò include anche le informazioni per l'"archiviazione centrale" nel database Icon Services e Launch Services. Per supportare le prestazioni, le applicazioni vengono "scoperte" in diversi luoghi "ben noti": le directory delle applicazioni di sistema e dell'utente e alcune altre automaticamente se l'utente accede al Finder nella directory contenente l'applicazione. In pratica ha funzionato molto bene.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 sessione 144 - Mac OS X: confezionamento di applicazioni e stampa di documenti.

Non esiste nulla di simile a questa infrastruttura sui desktop Linux, quindi stiamo cercando soluzioni alternative alle limitazioni strutturali nel progetto AppImage.

L'Haiku viene in soccorso?

E ancora una cosa: le piattaforme Linux come base degli ambienti desktop tendono ad essere così sottospecificate che molte cose che sono abbastanza semplici in un sistema full-stack coerente sono frammentate e complesse in modo frustrante in Linux. Ho dedicato un intero reportage alle problematiche relative alla piattaforma Linux per ambienti desktop (sviluppatori esperti hanno confermato che tutto rimarrà così per molto tempo).

Il mio reportage sui problemi degli ambienti desktop Linux nel 2018

Persino Linus Torvalds ha ammesso che la frammentazione è stata la ragione per cui l’idea dello spazio di lavoro è fallita.

Che bello vedere l'Haiku!

L'Haiku rende tutto sorprendentemente semplice

Sebbene l'approccio ingenuo al "porting" di AppImage su Haiku sia semplicemente provare a costruire (principalmente runtime.c e servizio) i suoi componenti (che potrebbe anche essere possibile!), Ciò non fornirà molti vantaggi ad Haiku. Perché in realtà la maggior parte di questi problemi vengono risolti nell'Haiku e sono concettualmente validi. Haiku fornisce esattamente gli elementi costitutivi dell'infrastruttura di sistema che stavo cercando negli ambienti desktop Linux da così tanto tempo e che non potevo credere che non fossero presenti. Vale a dire:

Che tu ci creda o no, questo è qualcosa che molti utenti Linux non riescono a superare. Su Haiku tutto viene fatto automaticamente!

• I file ELF che non dispongono di un bit di eseguibilità ne ottengono uno automaticamente quando si fa doppio clic nel file manager.
• Le applicazioni possono avere risorse integrate, come le icone, che vengono visualizzate nel file manager. Non è necessario copiare un gruppo di immagini in directory speciali con icone e quindi non è necessario ripulirle dopo aver eliminato o spostato l'applicazione.
• Esiste un database per collegare le applicazioni ai documenti, non è necessario copiare alcun file per questo.
• Nella directory lib/ accanto al file eseguibile, le librerie vengono cercate per impostazione predefinita.
• Non esistono numerose distribuzioni e ambienti desktop; qualunque cosa funzioni, funziona ovunque.
• Non esiste un modulo separato da eseguire diverso dalla directory Applicazioni.
• Le applicazioni non dispongono di percorsi assoluti incorporati per le proprie risorse; dispongono di funzioni speciali per determinare la posizione in fase di runtime.
• È stata introdotta l'idea delle immagini del file system compresso: si tratta di un qualsiasi pacchetto hpkg. Sono tutti montati dal kernel.
• Ogni file viene aperto dall'applicazione che lo ha creato, a meno che tu non specifichi esplicitamente diversamente. Quanto è bello questo!

Due file png. Notare le diverse icone che indicano che verranno aperte da diverse applicazioni quando si fa doppio clic. Da notare anche il menu a tendina "Apri con:" in cui l'utente può selezionare una singola applicazione. Com'è semplice!

Sembra che molte delle stampelle e delle soluzioni alternative richieste da AppImage su Linux diventino inutili su Haiku, che ha al centro la semplicità e la raffinatezza che gli consentono di gestire la maggior parte delle nostre esigenze.

Dopotutto Haiku ha bisogno di pacchetti di app?

Ciò porta a una grande domanda. Se fosse molto più semplice creare un sistema come AppImage su Haiku che su Linux, varrebbe la pena farlo? Oppure Haiku, con il suo sistema di pacchetti hpkg, ha effettivamente eliminato la necessità di sviluppare un'idea del genere? Bene, per rispondere dobbiamo guardare alla motivazione dietro l'esistenza di AppImages.

La prospettiva dell'utente

Diamo un'occhiata al nostro utente finale:

• Desidero installare un'applicazione senza richiedere la password di amministratore (root). Non esiste il concetto di amministratore su Haiku, l'utente ha il pieno controllo poiché si tratta di un sistema personale! (In linea di principio, puoi immaginarlo in modalità multiplayer, spero che gli sviluppatori mantengano le cose semplici)
• Voglio ottenere le versioni più recenti e migliori delle applicazioni, senza aspettare che appaiano nella mia distribuzione (molto spesso questo significa "mai", almeno a meno che non aggiorni l'intero sistema operativo). Su Haiku questo viene "risolto" con release fluttuanti. Ciò significa che è possibile ottenere le versioni più recenti e migliori delle applicazioni, ma per farlo è necessario aggiornare costantemente il resto del sistema, trasformandolo di fatto in un “bersaglio mobile”.
• Voglio diverse versioni della stessa applicazione una accanto all'altra, poiché non c'è modo di sapere cosa non funzionava nell'ultima versione o, ad esempio, io, come sviluppatore web, devo testare il mio lavoro con diverse versioni del browser. L'Haiku risolve il primo problema, ma non il secondo. Gli aggiornamenti vengono ripristinati, ma solo per l'intero sistema; è impossibile (per quanto ne so) eseguire, ad esempio, più versioni di WebPositive o LibreOffice contemporaneamente.

Uno degli sviluppatori scrive:

Essenzialmente la logica è questa: il caso d'uso è così raro che ottimizzarlo non ha senso; trattarlo come un caso speciale in HaikuPorts sembra più che accettabile.

• Devo mantenere le app dove mi piacciono, non sul mio disco di avvio. Spesso esaurisco lo spazio su disco, quindi devo collegare un'unità esterna o una directory di rete per archiviare le applicazioni (tutte le versioni che ho scaricato). Se collego un'unità di questo tipo, è necessario che le applicazioni vengano avviate facendo doppio clic. Haiku salva le vecchie versioni dei pacchetti, ma non so come spostarli su un'unità esterna o come avviare le applicazioni da lì in seguito.

Commento dello sviluppatore:

Tecnicamente questo è già possibile con il comando mount. Naturalmente, creeremo una GUI per questo non appena avremo abbastanza utenti interessati.

• Non ho bisogno di milioni di file sparsi nel file system che non posso gestire manualmente da solo. Desidero un file per applicazione che possa scaricare, spostare ed eliminare facilmente. Su Haiku questo problema viene risolto utilizzando i pacchetti .hpkg, che trasferiscono, ad esempio, Python, da migliaia di file in uno solo. Ma se, ad esempio, Scribus utilizza Python, allora devo occuparmi di almeno due file. E devo fare attenzione a conservarne versioni che funzionino tra loro.

Più versioni di AppImages eseguite fianco a fianco sullo stesso Linux

Il punto di vista di uno sviluppatore di applicazioni

Guardiamo dal punto di vista di uno sviluppatore di applicazioni:

• Voglio controllare l'intera esperienza dell'utente. Non voglio dipendere da un sistema operativo per dirmi quando e come dovrei rilasciare le applicazioni. Haiku consente agli sviluppatori di lavorare con i propri repository hpkg, ma ciò significa che gli utenti dovranno configurarli manualmente, il che rende l'idea "meno attraente".
• Ho una pagina di download sul mio sito web dove distribuisco .exe per Windows, .dmg per Mac e .AppImage per Linux. O forse voglio monetizzare l'accesso a questa pagina, tutto è possibile? Cosa dovrei mettere lì per l'Haiku? Il fascicolo è sufficiente .hpkg con dipendenze solo da HaikuPorts
• Il mio software richiede versioni specifiche di altro software. Ad esempio, è noto che Krita richiede una versione patchata di Qt, o Qt ottimizzato per una versione specifica di Krita, almeno finché le patch non vengono reinserite in Qt. Puoi impacchettare le tue Qt per la tua applicazione in un pacchetto .hpkg, ma molto probabilmente questo non è il benvenuto.

Pagina di download dell'applicazione normale. Cosa dovrei pubblicare qui per Haiku?

I bundle (esistenti come directory dell'applicazione come AppDir o .app in stile Apple) e/o immagini (sotto forma di AppImages fortemente modificate o .dmg da Apple) le applicazioni sono un'utile aggiunta all'ambiente desktop Haiku? Oppure diluirà l’intero quadro e porterà alla frammentazione, aggiungendo quindi complessità? Sono combattuto: da un lato, la bellezza e la raffinatezza dell'Haiku si basa sul fatto che di solito c'è un modo di fare qualcosa, piuttosto che molti. D'altra parte, la maggior parte dell'infrastruttura per i cataloghi e/o le suite di applicazioni è già installata, quindi il sistema chiede a gran voce che la restante piccola percentuale venga messa a posto.

Secondo lo sviluppatore Sig. waddlesplash

Su Linux loro (cataloghi e kit applicativi, - ca. traduttore) rappresentano molto probabilmente una soluzione tecnica a problemi sistemici. Noi di Haiku preferiamo risolvere semplicemente i problemi di sistema.

Cosa ne pensi?

Prima di rispondere...

Aspetta, facciamo un rapido confronto con la realtà: infatti directory dell'applicazione - già parte dell'Haiku:

Le directory delle applicazioni esistono già su Haiku, ma non sono ancora supportate nel file manager

Semplicemente non sono supportati così bene come, ad esempio, il Macintosh Finder. Quanto sarebbe bello se la directory QtCreator avesse un nome e un'icona "QtCreator" nell'angolo in alto a sinistra, avviando l'applicazione quando si fa doppio clic?

Un po' prima ho già ho chiesto:

Sei sicuro di poter eseguire le tue app vecchie di dieci anni oggi, quando tutti gli app store e i repository di distribuzione si sono dimenticati di loro e delle loro dipendenze? Sei sicuro che potrai ancora accedere al tuo attuale lavoro in futuro?

Esiste già una risposta da Haiku o i cataloghi e i pacchetti di applicazioni possono essere d'aiuto in questo caso? Penso che possano.

Secondo il sig. waddlesplash:

Sì, abbiamo la risposta alla domanda: supporteremo semplicemente queste applicazioni per tutto il tempo necessario finché qualcuno non sarà in grado di leggere i formati di file nel modo giusto o di fornire funzionalità individuali. Il nostro impegno nel supportare le app BeOS R5 su Haiku ne è la prova...

Giusto!

Quale linea d’azione dovrebbe intraprendere l’Haiku?

Posso immaginare la pacifica coesistenza di hpkg, directory e immagini delle applicazioni:

• Utilizzi del software di sistema .hpkg
• Per il software utilizzato più frequentemente (in particolare quelli che necessitano di pianificare rilasci continui), utilizzare .hpkg (circa l’80% dei casi)
• Alcuni installati tramite .hpkg, le applicazioni trarranno vantaggio dal passaggio a un'infrastruttura di directory applicative (ad esempio QtCreator): saranno distribuite come .hpkg, come prima.

Sig. waddlesplash scrive:

Se tutto ciò che ti serve è visualizzare le applicazioni in /system/apps, dovremmo invece rendere le directory in Deskbar più gestibili per gli utenti, poiché /system/apps non è destinato ad essere aperto e visualizzato regolarmente dagli utenti (a differenza di MacOS). Per tali situazioni, l'Haiku ha un paradigma diverso, ma questa opzione è, in teoria, accettabile.

• Haiku riceve l'infrastruttura per eseguire immagini di applicazioni, versioni notturne, continue e di test del software, nonché per i casi in cui l'utente desidera "congelarlo nel tempo", per software privato e interno e altri casi d'uso speciali (circa il 20% di tutti). Queste immagini contengono i file necessari per eseguire l'applicazione .hpkg, montato dal sistema e dopo il completamento dell'applicazione - smontato. (Forse un file manager potrebbe inserire file .hpkg nelle immagini dell'applicazione, automaticamente o su richiesta dell'utente, beh, come quando trascini un'applicazione su una directory di rete o su un'unità esterna. È solo una canzone! O meglio poesia - haiku.) D'altra parte, l'utente potrebbe voler installare il contenuto dell'immagine sotto forma di file.hpkg, dopodiché verranno aggiornati ed elaborati come se fossero installati tramite HaikuDepot... Dobbiamo fare un brainstorming).

Citazione del sig. waddlesplash:

L'esecuzione di applicazioni da unità esterne o directory di rete può essere potenzialmente utile. E aggiungere la possibilità di configurare più "zone" per pkgman sarebbe sicuramente una caratteristica interessante.

Un sistema del genere trarrebbe vantaggio da hpkg, directory e immagini delle applicazioni. Sono bravi individualmente, ma insieme diventeranno invincibili.

conclusione

Haiku ha un framework che fornisce un'esperienza utente semplice e sofisticata per i PC, andando ben oltre ciò che viene tipicamente fornito per i PC Linux. Sistema di pacchetti .hpkg è uno di questi esempi, ma anche il resto del sistema è intriso di sofisticatezza. Tuttavia, Haiku trarrebbe vantaggio da un adeguato supporto per le directory e le immagini dell'applicazione. Vale la pena discutere del modo migliore per farlo con persone che conoscono l'Haiku, la sua filosofia e la sua architettura molto meglio di me. Dopotutto, sto usando Haiku da poco più di una settimana. Tuttavia, credo che i designer, gli sviluppatori e gli architetti di Haiku trarranno beneficio da questa nuova prospettiva. Per lo meno, sarei felice di essere il loro “sparring partner”. Ho più di 10 anni di esperienza pratica con cataloghi e bundle di applicazioni Linux e mi piacerebbe trovarne un utilizzo in Haiku, per il quale penso che siano perfetti. Le possibili soluzioni che ho proposto non sono affatto le uniche corrette per i problemi che ho descritto, e se il team Haiku decidesse di trovarne altre, più eleganti, io sono assolutamente d'accordo. In sostanza sto già pensando all'idea di come fare sistema hpkg ancora più sorprendente senza cambiare il modo in cui funziona. Si scopre che il team di Haiku aveva pensato a lungo ai bundle di applicazioni quando implementava un sistema di gestione dei pacchetti, ma sfortunatamente (credo) l'idea è diventata "obsoleta". Forse è giunto il momento di rilanciarlo?

Prova tu stesso! Dopotutto, il progetto Haiku fornisce immagini per l'avvio da DVD o USB, generate quotidiano.
Hai domande? Ti invitiamo alla lingua russa canale telegramma.

Panoramica degli errori: Come spararsi ai piedi in C e C++. Raccolta di ricette del sistema operativo Haiku

Da l'autore traduzione: questo è l'ottavo e ultimo articolo della serie sull'Haiku.

Elenco degli articoli: prima La seconda terzo quarto quinto sesto settimo

Solo gli utenti registrati possono partecipare al sondaggio. AccediPer favore.

Ha senso portare il sistema hpkg su Linux?

• Sì

• No

• Già implementato, scriverò nei commenti

20 utenti hanno votato. 5 utenti si sono astenuti.

Fonte: habr.com