🥇Qualcos'altro: pacchetti di applicazioni Haiku?

TL;DR: Haiku può ricevere un adeguato supporto per pacchetti applicativi, come ad esempio cataloghi di applicazioni (come .app su Mac) e/o immagini applicative (Linux AppImage)? Mi sembra che sarebbe un'aggiunta degna di nota, più facile da implementare rispetto ad altri sistemi, dato che gran parte dell'infrastruttura è già presente.

Una settimana fa ho scoperto Haiku, un sistema sorprendentemente valido. E poiché ho a lungo avuto interesse per i cataloghi e le immagini applicative (ispirati dalla semplicità del Macintosh), non è sorprendente che mi sia venuta in mente un'idea…

Per completezza: sono il creatore e autore di AppImage, un formato di distribuzione per applicazioni Linux, progettato per la semplicità del Mac e che fornisce il pieno controllo agli autori delle applicazioni e agli utenti finali (vuoi saperne di più — vedi il wiki e documentazione).

Cosa accadrebbe se creassimo AppImage per Haiku?

Discutiamo un po', puramente teoricamente, di cosa servirebbe per ottenere AppImage, o qualcosa di simile, su Haiku? Non è necessario creare qualcosa proprio ora, poiché il sistema già presente in Haiku funziona sorprendentemente bene, ma un esperimento concettuale sarebbe interessante. Inoltre, dimostra la raffinatezza di Haiku rispetto agli ambienti di lavoro Linux, dove tali operazioni sono estremamente complesse (lo posso dire: da 10 anni mi affliggo con il debugging).

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

Prima di tutto, che cos'è AppImage? È un sistema per il rilascio di applicazioni di terze parti (per esempio, Ultimaker Cura), che consente di rilasciare applicazioni quando e come si desidera: non è necessario conoscere le peculiarità dei vari distribuzioni, le politiche di build o l'infrastruttura di build, non è necessaria la supporto di accompagnamento, e non indicano agli utenti cosa (non) possono installare sui loro computer. AppImage può essere inteso come qualcosa di simile a un pacchetto per Mac nel formato .app all'interno dell'immagine del disco .dmg. La principale differenza è che le applicazioni non vengono copiate, ma rimangono sempre all'interno di AppImage, più o meno come i pacchetti Haiku .hpkg si installano e mai vengono configurati nel senso tradizionale.

Nel corso di oltre 10 anni di esistenza, AppImage ha guadagnato un certo fascino e popolarità: lo stesso Linus Torvalds lo ha approvato pubblicamente e progetti conosciuti (come LibreOffice, Krita, Inkscape, Scribus, ImageMagick) lo hanno adottato come principale metodo di distribuzione delle versioni continui o notturne, senza interferire con le applicazioni installate o non installate degli utenti. Tuttavia, gli ambienti di lavoro e le distribuzioni Linux tendono ancora a mantenere il tradizionale modello di distribuzione centralizzato basato su assistenti e/o promuovono i propri programmi aziendali e/o ingegneristici. Flatpak (RedHat, Fedora, GNOME) e Snappy (Canonical, Ubuntu). Si arriva al ridicolo.

Come funziona tutto

Ogni AppImage contiene 2 parti: un piccolo eseguibile ELF (chiamato anche runtime.c), seguito da un'immagine del file system SquashFS.

Il file system SquashFS contiene il payload sotto forma di applicazione e tutto il necessario per il suo avvio, il quale non può essere ragionevolmente considerato parte di un'installazione predefinita su ogni sistema target sufficientemente recente (distribuzione Linux). Include anche metadati, come il nome dell'applicazione, le icone, i tipi MIME e altro ancora.

Quando un utente avvia il runtime, utilizza FUSE e squashfuse per montare il file system, dopodiché gestisce l'avvio di un certo punto di ingresso (il cosiddetto AppRun) all'interno dell'AppImage montato.
Il file system viene smontato dopo che il processo termina.

Sembra tutto semplice.

Ma queste cose complicano tutto:

Con una tale varietà di distribuzioni Linux, nulla può essere ragionevolmente considerato "parte di un'installazione predefinita per ogni sistema target recente". Affrontiamo questo problema attraverso la costruzione di excludelist, che permette di determinare cosa sarà imballato nell'AppImage e cosa dovrà essere preso da altrove. Tuttavia, a volte falliamo, nonostante in generale tutto funzioni perfettamente. Per questo motivo, raccomandiamo ai creatori di pacchetti di testare le AppImages su tutti i sistemi target (distribuzioni).
Le applicazioni come payload devono essere portabili nel file system. Sfortunatamente, molte applicazioni hanno percorsi assoluti fissi per, ad esempio, le risorse in /usr/share. Questo deve essere corretto in qualche modo. Inoltre, è necessario esportare LD_LIBRARY_PATH, o correggere rpath in modo che il loader possa trovare le librerie collegate. Il primo metodo ha i suoi svantaggi (che richiedono approcci complessi), mentre il secondo è semplicemente ingombrante.
La trappola UX più grande per gli utenti è che è necessario impostare il bit di esecuzione nel file AppImage dopo il download. Vuoi crederci, vuoi no, ma per alcuni è un vero ostacolo. La necessità di impostare il bit di esecuzione è ingombrante anche per gli utenti esperti. Come soluzione alternativa, abbiamo proposto di installare un piccolo servizio che monitora i file AppImage e imposta il loro bit di esecuzione. Così com'è, non è la soluzione migliore, poiché non funzionerà "out of the box". Le distribuzioni Linux non forniscono questo servizio, quindi gli utenti hanno problemi "out of the box".
Gli utenti di Linux si aspettano che la nuova applicazione abbia un'icona nel menu di avvio. Non puoi dire al sistema: «Guarda, c'è una nuova applicazione, fai il tuo lavoro». Invece, secondo le specifiche XDG, è necessario copiare il file .desktop nella posizione corretta in /usr per un'installazione di sistema, oppure in $HOME per installazioni individuali. Le icone di determinate dimensioni, secondo le specifiche XDG, devono essere collocate in posizioni specifiche in usr o $HOME, dopodiché bisogna eseguire comandi nell'ambiente di lavoro per aggiornare la cache delle icone, oppure sperare che il gestore dell'ambiente di lavoro riesca a capirlo e scopra tutto automaticamente. Lo stesso vale per i tipi MIME. Come soluzione alternativa, si suggerisce di utilizzare lo stesso servizio che, oltre a impostare il flag di eseguibilità, copierà, se presenti icone ecc. nell'AppImage, da AppImage nelle posizioni corrette secondo XDG. Durante la rimozione o lo spostamento, il servizio presumibilmente pulirà tutto. Ovviamente, ci sono differenze nel comportamento di ogni ambiente di lavoro, nei formati dei file grafici, nelle loro dimensioni, nei luoghi di archiviazione e nei metodi di aggiornamento delle cache, il che genera il problema. In breve, questo metodo è un ripiego.
Se quanto sopra non è sufficiente, nel gestore file non c'è nemmeno l'icona AppImage. Nel mondo Linux non è ancora stata presa una decisione sull'implementazione di elficon (nonostante discussione e implementazioni), quindi non è possibile integrare direttamente l'icona nell'applicazione. Così risulta che le applicazioni nel gestore file non hanno le proprie icone (indipendentemente dal fatto che siano AppImage o altro); esse esistono solo nel menu di avvio. Come soluzione alternativa, utilizziamo le miniature: un meccanismo originariamente progettato affinché i gestori desktop potessero mostrare immagini ridotte per l'anteprima di file grafici come le loro icone. Pertanto, il servizio per impostare il bit di esecuzione funziona anche come "miniaturizzatore", creando e registrando miniature delle icone nei luoghi appropriati /usr e $HOME. Inoltre, questo servizio esegue una pulizia se l'AppImage viene eliminata o spostata. Poiché ogni gestore desktop si comporta in modo leggermente diverso, ad esempio, quali formati accettano e quali dimensioni o posizioni considerano, tutto questo è realmente problematico.
L'applicazione si chiude semplicemente durante l'esecuzione se si verificano errori (ad esempio, ci sono librerie che non fanno parte del sistema di base e non sono fornite nell'AppImage) e nessuno informa l'utente tramite GUI su cosa stia succedendo. Abbiamo iniziato a superare questo problema usando notifiche sul desktop, il che significa che dobbiamo estrarre gli errori dalla riga di comando, convertirli in messaggi comprensibili per l'utente, che poi devono essere visualizzati sul desktop. E, naturalmente, ogni ambiente desktop li gestisce in modo leggermente diverso.
Al momento attuale (settembre 2019, nota del traduttore), non ho trovato un modo semplice per dire al sistema di aprire il file 1.png con Krita, mentre 2.png con GIMP.

Il luogo di archiviazione delle specifiche cross-desktop utilizzate in GNOME, KDE e Xfce è freedesktop.org.

Raggiungere un livello di raffinatezza, profondamente intrecciato nell'ambiente di lavoro Haiku, è complicato, per non dire "impossibile", a causa delle specifiche XDG di freedesktop.org. per cross-desktop e anche per le implementazioni dei gestori di desktop basati su queste specifiche. Un esempio è la famosa icona di sistema di Firefox: evidentemente, agli autori di XDG non è venuto in mente che l'utente potrebbe avere più versioni della stessa applicazione installate.

Icone di diverse versioni di Firefox

Ero curioso di sapere cosa il mondo Linux potesse imparare da Mac OS X per evitare errori nell'integrazione di sistema. Se avete tempo e vi occupate di questo, leggete assolutamente cosa ha detto Arno Gourdol, uno dei primi ingegneri di Mac OS X:

Volevamo che installare l'app fosse facile come trascinare l'icona dell'app da qualsiasi luogo (server, disco esterno) sul disco del computer. A tal fine, nel pacchetto dell'app sono memorizzate tutte le informazioni necessarie, comprese le icone, la versione, il tipo di file elaborato e il tipo di schema URL, che il sistema deve conoscere per gestire l'app. Questo include anche le informazioni per il 'memorizzazione centralizzata' nel database Icon Services e Launch Services. Per ottimizzare le prestazioni, le applicazioni vengono 'individuate' in diversi luoghi 'ben noti': nella cartella delle Applicazioni di sistema e degli utenti, nonché automaticamente in alcuni altri casi, se l'utente accede al Finder nella cartella contenente l'app. In pratica, questo ha funzionato molto bene.

https://youtu.be/qQsnqWJ8D2c
Sessione 144 di Apple WWDC 2000 — Mac OS X: imballaggio di applicazioni e stampa di documenti.

Niente di simile a questa infrastruttura esiste negli ambienti di lavoro Linux, quindi stiamo cercando soluzioni alternative alle limitazioni strutturali nel progetto AppImage.

Davvero Haiku arriva in soccorso?

Inoltre: le piattaforme Linux come base per gli ambienti di lavoro sono spesso così mal specificate che molte cose, che sono piuttosto semplici in un sistema coerente con un stack completo, risultano deludenti per la frammentazione e la complessità in Linux. Ho dedicato un'intera presentazione alle questioni relative alla piattaforma Linux per ambienti di lavoro (i sviluppatori esperti hanno confermato: sarà così ancora per molto tempo).

La mia presentazione sui problemi degli ambienti di lavoro Linux nel 2018

Anche Linus Torvalds ha riconosciuto che proprio a causa della frammentazione l'idea degli ambienti di lavoro non ha avuto successo.

È bello vedere Haiku!

Con Haiku tutto diventa incredibilmente semplice

Sebbene l'approccio naive per 'portare' AppImage su Haiku consista in un semplice tentativo di costruire (principalmente runtime.c e il servizio) i suoi componenti (il che può anche essere possibile!), non porterà particolare aiuto a Haiku. Perché, in realtà, la maggior parte di questi problemi è già risolta su Haiku e ha una base concettuale. Haiku fornisce proprio i mattoni per l'infrastruttura di sistema che ho cercato a lungo negli ambienti di lavoro su Linux e non potevo credere che non fossero lì. Vale a dire:

Credeteci oppure no, ma molti utenti Linux non riescono a superare questo. Su Haiku tutto avviene in modo automatico!

I file ELF, privi del bit eseguibile, acquisiscono questo automaticamente con un doppio clic nel gestore di file.
Le applicazioni possono avere risorse incorporate, come le icone, che vengono visualizzate nel gestore di file. Non è necessario copiare molte immagini in directory specifiche per le icone, quindi non è necessario pulirle 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 all'eseguibile, le librerie vengono cercate per impostazione predefinita.
Non ci sono numerose distribuzioni e ambienti desktop, tutto ciò che funziona funziona ovunque.
Non esiste un modulo separato per l'esecuzione, diverso dalla directory Applications.
Nelle applicazioni non ci sono percorsi assoluti incorporati per le proprie risorse, esistono funzioni speciali per determinare la posizione durante l'esecuzione.
È stata introdotta l'idea delle immagini compresse dei file system: qualsiasi pacchetto hpkg. Tutti vengono montati dal kernel.
Ogni file si apre con l'applicazione che lo ha creato, a meno che non venga specificato diversamente. È davvero fantastico!

Due file png. Nota le diverse icone che indicano che verranno aperti con applicazioni diverse con un doppio clic. Osserva anche il menu a discesa 'Apri con:', dove l'utente può scegliere un'applicazione specifica. È così semplice!

Sembra che molti workaround e soluzioni necessarie per AppImage su Linux diventino superflui su Haiku, che si basa su semplicità e raffinatezza, permettendo di soddisfare la maggior parte delle nostre esigenze.

Servono davvero i pacchetti di applicazioni su Haiku, alla fine?

Questo porta a una grande domanda. Se creare un sistema simile a AppImage su Haiku fosse notevolmente più semplice che su Linux, varrebbe la pena farlo? O Haiku, con il suo sistema di pacchetti hpkg, ha effettivamente eliminato la necessità di sviluppare un'idea simile? Beh, per rispondere, dobbiamo esaminare la motivazione dietro l'esistenza degli AppImages.

Uno sguardo dalla prospettiva dell'utente

Diamo un'occhiata al nostro utente finale:

Voglio installare un'applicazione senza richiedere la password dell'amministratore (root). Su Haiku non esiste il concetto di amministratore, l'utente ha il pieno controllo poiché si tratta di un sistema personale! (In linea di principio, è possibile immaginarlo anche in modalità multiutente, spero che gli sviluppatori mantengano la semplicità)
Voglio ricevere le ultime e migliori versioni delle applicazioni, senza dover aspettare che arrivino nella mia distribuzione (nella maggior parte dei casi, ciò significa 'mai', a meno che non si aggiorni l'intero sistema operativo). Su Haiku questo è 'risolto' grazie ai rilasci fluttuanti. Ciò significa che c'è la possibilità di ottenere le ultime e migliori versioni delle applicazioni, ma per farlo è necessario aggiornare costantemente anche il resto del sistema, trasformandolo di fatto in un 'bersaglio in movimento'..
Desidero avere diverse versioni della stessa applicazione affiancate, poiché non è possibile sapere cosa sia stato rotto nell'ultima versione, oppure, ad esempio, come sviluppatore web, ho bisogno di controllare il mio lavoro su più versioni del browser. In Haiku è stata risolta la prima, ma non la seconda problematica. Gli aggiornamenti possono essere annullati, ma solo per l'intero sistema, non è possibile (per quanto ne so) eseguire, ad esempio, più versioni di WebPositive o LibreOffice contemporaneamente.

Uno degli sviluppatori scrive:

Fondamentalmente, la giustificazione è questa: lo scenario d'uso è così raro che ottimizzarlo non ha senso; gestirlo come un caso speciale in HaikuPorts sembra più che accettabile.

Ho bisogno di conservare le applicazioni dove voglio, e non sul disco di avvio. Spesso lo spazio sui dischi finisce, quindi devo collegare un'unità esterna o una directory di rete per conservare le applicazioni (tutte le versioni che ho scaricato). Se collego un'unità di questo tipo, vorrei che le applicazioni si avviassero con un doppio clic. Haiku mantiene le vecchie versioni dei pacchetti, ma non so come spostarle su un'unità esterna, né come richiamare le applicazioni da lì.

Commento dello sviluppatore:

Tecnicamente, è già possibile con il comando mount. Naturalmente, realizzeremo un'interfaccia grafica per questo, non appena ci saranno abbastanza utenti interessati.

Non ho bisogno di milioni di file sparsi nel file system, che non posso gestire manualmente da solo. Vorrei un file per applicazione, che posso facilmente scaricare, spostare ed eliminare. In Haiku questo problema è risolto tramite i pacchetti. .hpkg, che importano, ad esempio, Python, da migliaia di file in uno solo. Ma se c'è, per esempio, Scribus, che utilizza Python, allora devo gestire almeno due file. E devo preoccuparmi di mantenere le loro versioni funzionanti tra loro.

Numerose versioni di AppImages, eseguite affiancate su un Linux

Uno sguardo dal punto di vista dello sviluppatore di applicazioni

Esaminiamo dal punto di vista dello sviluppatore di applicazioni:

Voglio gestire l'esperienza utente nel suo complesso. Non voglio dipendere dal sistema operativo che mi dice quando e come devo rilasciare le applicazioni. In Haiku, gli sviluppatori possono lavorare con i propri repository hpkg, ma questo significa che gli utenti dovranno configurarli manualmente, rendendo questa idea 'meno attraente'.
Ho una pagina di download sul mio sito web, dove distribuisco .exe per Windows, .dmg per Mac e .AppImage per Linux. E magari vorrò monetizzare l'accesso a questa pagina, tutto è possibile? Cosa devo mettere lì per Haiku? Basta un file .hpkg con dipendenze solo da HaikuPorts
Il mio software richiede versioni specifiche di altri software. Ad esempio, è noto che per Krita è necessaria una versione corretta di Qt, o Qt che sia ottimizzata per una particolare versione di Krita, almeno fino a quando le correzioni non verranno reintegrate in Qt. È possibile impacchettare la propria Qt per l'applicazione nel pacchetto .hpkg, ma probabilmente non è visto di buon occhio.

Una pagina di download standard per l'applicazione. Cosa dovrebbe contenere qui per Haiku?

I pacchetti (disponibili come cataloghi di applicazioni, come AppDir o .app nello stile Apple) e/o le immagini (sotto forma di AppImages pesantemente modificate o .dmg di Apple) delle applicazioni saranno un'aggiunta utile per l'ambiente di lavoro di Haiku? Oppure questo frammenterà il tutto, rendendo la situazione più complessa? Sono diviso: da un lato, la bellezza e la raffinatezza di Haiku si basano sul fatto che c'è solitamente un modo per fare le cose, non molti. D'altra parte, gran parte dell'infrastruttura per cataloghi e/o pacchetti di applicazioni è già presente, quindi il sistema chiede a gran voce che anche i restanti pochi percento trovino il loro posto.

Secondo lo sviluppatore mr. waddlesplash

Su Linux essi (cataloghi e set di applicazioni, — nota del traduttore) sono probabilmente una soluzione tecnica per problemi di sistema. Su Haiku preferiamo semplicemente risolvere i problemi di sistema.

E voi, cosa ne pensate?

Prima di rispondere…

Aspettate, facciamo un rapido controllo della realtà: di fatto cataloghi di applicazioni — sono già parte di Haiku:

I cataloghi delle applicazioni esistono già su Haiku, ma non sono ancora supportati nel file manager

Sono semplicemente meno supportati rispetto, ad esempio, al Macintosh Finder. Quanto sarebbe bello se il catalogo di QtCreator avesse in alto a sinistra il nome e l'icona di «QtCreator», avviando l'applicazione con un doppio clic?

Poco prima ho già chiesto:

Siete sicuri di poter avviare le vostre applicazioni risalenti a un decennio fa oggi, quando tutti i negozi di applicazioni e i repository delle distribuzioni le dimenticheranno insieme alle loro dipendenze? Siete sicuri di poter ancora accedere al vostro lavoro attuale in futuro?

C'è già una risposta da parte di Haiku, oppure i cataloghi e i set di applicazioni potranno aiutare qui? Penso che possano.

Secondo mr. waddlesplash:

Sì, abbiamo una risposta alla domanda: continueremo a supportare queste applicazioni finché non ci sarà qualcuno in grado di leggere i loro formati di file in modo corretto o di garantire una funzionalità uno a uno. La nostra determinazione nel mantenere le app BeOS R5 operative su Haiku ne è una chiara dimostrazione...

Esatto!

Quale piano d'azione dovrebbe adottare Haiku?

Posso immaginare una coesistenza pacifica tra hpkg, cataloghi e immagini delle applicazioni:

Il software di sistema utilizza .hpkg
Per il software più comunemente usato (soprattutto per quello che richiede rilascio programmato) si usa .hpkg (circa l'80% di tutti i casi)
Alcuni, installati tramite .hpkg, le applicazioni trarranno vantaggio dal passaggio a un'infrastruttura con cataloghi di applicazioni (ad esempio, QtCreator): saranno distribuite come .hpkg, come prima.

mr. waddlesplash scrive:

Se tutto ciò che serve è la visualizzazione delle applicazioni in /system/apps, invece si dovrebbero rendere i cataloghi nella 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, Haiku ha un'altra paradigma, ma questa opzione è, in teoria, accettabile.

Haiku fornisce un'infrastruttura per eseguire immagini di applicazioni, build notturne, continuative e di test, e per i casi in cui l'utente desidera 'congelarlo nel tempo', per software privato e interno, e altri usi speciali (circa il 20% di tutti). Queste immagini contengono i file necessari per eseguire l'applicazione .hpkg, montati attraverso il sistema e smontati dopo il completamento dell'applicazione. (Forse il gestore di file potrebbe collocare i file .hpkg nelle immagini delle applicazioni, automaticamente o su richiesta dell'utente — proprio come quando trascini un'applicazione in una cartella di rete o su un'unità esterna. È semplicemente una canzone! O meglio, una poesia — un haiku.) D'altra parte, l'utente potrebbe voler installare il contenuto dell'immagine come file.hpkg, dopo di che verranno aggiornati e gestiti esattamente come se fossero stati installati tramite HaikuDepot… È necessario fare un brainstorming).

Citazione di mr. waddlesplash:

Avviare applicazioni da dischi esterni o directory di rete può essere particolarmente utile. Inoltre, offrire la possibilità di configurare più "zone" per pkgman sarebbe senza dubbio una funzionalità vantaggiosa.

Un sistema del genere trarrà vantaggio da hpkg, directory e immagini di applicazioni. Questi sono buoni singolarmente, ma insieme diventeranno imbattibili.

Conclusione

Per Haiku c'è un'infrastruttura che fornisce un'interfaccia utente semplice e raffinata per PC, superando di gran lunga ciò che è normalmente offerto per i PC Linux. Il sistema dei pacchetti .hpkg — un esempio di questo tipo, ma anche le altre parti del sistema sono permeate di raffinato design. Tuttavia, un adeguato supporto per i cataloghi e le immagini delle applicazioni gioverebbe a Haiku. Come farlo nel modo migliore è qualcosa di cui discutere con persone che conoscono Haiku, la sua filosofia e architettura molto meglio di me. Dopo tutto, uso Haiku da poco più di una settimana. Tuttavia, credo che questo nuovo punto di vista possa risultare utile per i designer, gli sviluppatori e gli architetti di Haiku. Almeno, sono felice di essere per loro un "partner di allenamento". Ho oltre 10 anni di esperienza pratica con cataloghi e insieme di applicazioni per Linux, e mi piacerebbe trovare un'applicazione per Haiku, per la cui concezione ritengo che siano perfettamente adatti. Le soluzioni potenziali che propongo non sono affatto le uniche valide per i problemi che ho descritto, e se il team di Haiku decidesse di trovare altre soluzioni più eleganti, sarei completamente d'accordo. In linea di massima, sto già pensando all'idea di come realizzare il sistema. hpkg ancora più straordinaria, senza modificare il modo in cui funziona. Sembra che il team di Haiku stesse pensando a dei pacchetti di applicazioni nell'implementazione del sistema di gestione dei pacchetti, ma sfortunatamente, (mi sembra) l'idea sia andata in "disuso". Forse è giunto il momento di farla rinascere?

Provatelo voi stessi! Infatti, il progetto Haiku fornisce immagini da scaricare su DVD o USB, generate quotidianamente.
Avete domande? Vi invitiamo a unirvi al nostro canale Telegram in lingua russa.

Panoramica sugli errori: Come spararsi un colpo al piede in C e C++. Raccolta di ricette Haiku OS

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

Elenco degli articoli: Primo La seconda Terzo Quarto Quinto Sesto Settimo

Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.