🥇Qualcos'altro: pacchetti di applicazioni Haiku?

TL;DR: Haiku può avere un adeguato supporto per i pacchetti delle applicazioni, come ad esempio cataloghi di applicazioni (come .app su Mac) e/o immagini delle applicazioni (Linux AppImage)? Mi sembra che sarebbe un'aggiunta dignitosa, che sarebbe più semplice implementare rispetto ad altri sistemi, poiché gran parte dell'infrastruttura è già presente.

Una settimana fa ho scoperto Haiku, un sistema inaspettatamente buono. Dato che mi sono sempre interessato ai cataloghi e alle immagini delle applicazioni (ispirato dalla semplicità del Macintosh), non sorprende che mi sia venuta in mente l'idea...

Per completezza: sono il creatore e l'autore di AppImage, un formato di distribuzione delle applicazioni Linux, orientato alla semplicità di Mac e che fornisce pieno controllo agli autori delle applicazioni e agli utenti finali (se vuoi sapere di più — vedi. wiki e la documentazione).

E se creassimo AppImage per Haiku?

Facciamo un po' di riflessioni teoriche: cosa sarebbe necessario fare per ottenere AppImage, o qualcosa di simile, su Haiku? Non è necessario creare qualcosa immediatamente, poiché il sistema che già esiste su Haiku funziona sorprendentemente bene, ma un esperimento immaginario sarebbe interessante. Inoltre, dimostra la raffinatezza di Haiku, rispetto agli ambienti desktop Linux, dove cose simili sono terribilmente difficili (ho il diritto di dirlo: lotto con il debug da 10 anni).

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

Prima di tutto, cos'è AppImage? È un sistema per il rilascio di applicazioni di terze parti (ad esempio, Ultimaker Cura), che permette di rilasciare applicazioni quando e come si vuole: non è necessario conoscere le peculiarità dei vari distribuzioni, delle politiche di build o dell'infrastruttura di build, non è necessaria la supporto per i pacchetti, e non dicono agli utenti cosa (non)possono installare sui loro computer. AppImage deve essere visto 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 vengono montati e non vengono mai installati nel senso tradizionale.

AppImage ha acquisito una certa attrattiva e popolarità in oltre 10 anni di esistenza: lo stesso Linus Torvalds lo ha approvato pubblicamente, e progetti diffusi (come LibreOffice, Krita, Inkscape, Scribus, ImageMagick) lo hanno adottato come metodo principale per distribuire versioni continue o notturne, senza interferire con le applicazioni installate o non installate dagli utenti. Tuttavia, gli ambienti di lavoro e le distribuzioni Linux continuano spesso a tenere fede al tradizionale modello centralizzato di distribuzione basato su pacchetti 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 due parti: un piccolo eseguibile ELF (cioè il cosiddetto runtime.c), con l'immagine del file system SquashFS.

Il file system SquashFS contiene il payload sotto forma di applicazione e tutto il necessario per avviarlo, che a mente sana non si può considerare parte dell'installazione predefinita per ogni sistema target sufficientemente aggiornato (distribuzione Linux). Contiene anche metadati, ad esempio il nome dell'applicazione, le icone, i tipi MIME e altro.

All'avvio, l'runtime utilizza FUSE e squashfuse per montare il file system, dopodiché gestisce l'avvio di un certo punto d'ingresso (il cosiddetto AppRun) all'interno dell'AppImage montato.
Il file system viene smontato dopo la conclusione del processo.

Sembra tutto semplice.

Ma queste cose lo complicano:

con una tale varietà di distribuzioni Linux nulla può essere considerato "parte dell'installazione predefinita per ogni sistema target aggiornato". Superiamo questo problema costruendo una excludelist, che consente di determinare cosa sarà impacchettato nell'AppImage e cosa dovrà essere preso altrove. Tuttavia, a volte sbagliamo, nonostante il fatto che tutto funzioni perfettamente. Per questo motivo, raccomandiamo ai creatori di pacchetti di testare gli AppImage su tutti i sistemi target (distribuzioni).
Le applicazioni come payload devono essere trasferibili all'interno del file system. Sfortunatamente, molte applicazioni impongono percorsi assoluti per, ad esempio, le risorse in /usr/share. Questo deve essere sistemato in qualche modo. Inoltre, è necessario esportare LD_LIBRARY_PATH, oppure sistemare rpath affinché il caricatore possa trovare le librerie correlate. Il primo metodo ha i suoi svantaggi (che vengono risolti con metodi complicati), mentre il secondo è semplicemente ingombrante.
La trappola UX più grande per gli utenti è che devono impostare il bit eseguibile per il file AppImage dopo il download. Credeteci o no, ma per qualcuno questo è un vero ostacolo. La necessità di impostare il bit eseguibile è ingombrante anche per gli utenti esperti. Come soluzione alternativa, abbiamo proposto di installare un piccolo servizio che monitora i file AppImage e imposta loro il bit di eseguibilità. In pura forma, non è la migliore soluzione, poiché non funzionerà "out of the box". Le distribuzioni Linux non forniscono questo servizio, quindi per gli utenti è "out of the box" tutto difficile.
Gli utenti Linux si aspettano che una nuova applicazione abbia un'icona nel menu di avvio. Non si può dire al sistema: "Guarda, ecco una nuova applicazione, vai avanti". Al contrario, secondo le specifiche XDG, è necessario copiare il file .desktop nel posto giusto in /usr per l'installazione di sistema, o in $HOME per quella individuale. Le icone di determinati formati, in base alle specifiche XDG, devono essere posizionate in luoghi specifici in usr o $HOME, dopo di che bisogna eseguire comandi nell'ambiente di lavoro per aggiornare la cache delle icone, o sperare che il gestore dell'ambiente di lavoro riesca a riconoscerle e le scopra automaticamente. Lo stesso vale per i tipi MIME. Come soluzione alternativa, viene proposto di utilizzare lo stesso servizio che, oltre a impostare il bit di eseguibilità, copierà, se ci sono icone e quant'altro nell'AppImage, da AppImage nei luoghi appropriati secondo XDG. In caso di eliminazione o spostamento, il servizio presumibilmente ripulirà tutto. Certamente, ci sono differenze nel comportamento di ogni ambiente di lavoro, nei formati dei file grafici, nelle loro dimensioni, nei luoghi di archiviazione e nei modi di aggiornare le cache, il che genera il problema. In breve, questo metodo è un ripiego.
Se quanto sopra non è sufficiente, nel gestore di file non c'è comunque icona AppImage. Nel mondo Linux non si è ancora presa una decisione per l'introduzione di elficon (nonostante il discussione e realizzazione), quindi non è possibile incorporare l'icona direttamente nell'applicazione. Ne risulta che le applicazioni nel gestore di file non hanno icone proprie (indipendentemente dal fatto che siano AppImage o altro), ma sono presenti solo nel menu di avvio. Come soluzione alternativa, utilizziamo miniature: un meccanismo originariamente progettato affinché i gestori di desktop potessero mostrare immagini in miniatura per l'anteprima di file grafici come loro icone. Di conseguenza, il servizio per impostare il bit di eseguibilità funge anche da «miniaturizzatore», creando e registrando le miniature delle icone nei luoghi corrispondenti. /usr e $HOME. Inoltre, questo servizio esegue una pulizia se AppImage viene eliminato o spostato. Poiché ogni gestore di desktop si comporta in modo leggermente diverso, ad esempio, nei formati in cui accetta le icone, nelle dimensioni o nei luoghi, tutto ciò risulta davvero problematico.
L'applicazione semplicemente si arresta 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 nessuno informa l'utente nell'interfaccia utente grafica su ciò che sta accadendo. Abbiamo iniziato a aggirare questo problema utilizzando notifiche sul desktop, il che significa che dobbiamo catturare gli errori dalla riga di comando, convertirli in messaggi comprensibili per l'utente, che devono poi essere visualizzati sul desktop. E naturalmente, ogni ambiente desktop li gestisce in modo leggermente diverso.
Attualmente (settembre 2019, - nota del traduttore) non ho trovato un modo semplice per dire al sistema che il file 1.png deve essere aperto con Krita, e 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 desktop di Haiku è difficile, per non dire «impossibile», a causa delle specifiche XDG di freedesktop.org per l'interoperabilità cross-desktop, oltre alle implementazioni dei gestori di desktop basati su queste specifiche. Ad esempio, una delle icone di sistema di Firefox: evidentemente, agli autori di XDG non è nemmeno venuto in mente che un utente potrebbe avere installate più versioni della stessa applicazione.

Icone di diverse versioni di Firefox

Ero curioso di sapere cosa il mondo Linux potesse imparare da Mac OS X per non avere problemi nell'integrazione di sistema. Se hai tempo e ti occupi di questo, ti consiglio di leggere cosa ha detto Arno Gurdol, uno dei primi ingegneri di Mac OS X:

Volevamo che installare un'applicazione fosse semplice come trascinare l'icona dell'applicazione da qualche parte (server, disco esterno) sul disco del tuo computer. Per questo motivo, nel pacchetto dell'applicazione è conservata tutta l'informazione, comprese le icone, la versione, il tipo di file gestito e il tipo di schema URL che il sistema deve conoscere per gestire l'applicazione. Questa informazione include anche i dati per lo ‘storage centralizzato’ nel database Icon Services e Launch Services. Per supportare le prestazioni delle applicazioni, queste vengono ‘scoperte’ in diversi punti ‘ben noti’: nella directory di sistema e in quella utente delle Applicazioni, e anche in altri luoghi automaticamente, se l'utente si sposta nel Finder in una directory contenente l'applicazione. In pratica, questo ha funzionato molto bene.

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

Non esiste nulla di simile in questa infrastruttura sugli ambienti di lavoro Linux, quindi stiamo cercando soluzioni alternative per aggirare le limitazioni strutturali nel progetto AppImage.

Veramente Haiku sta correndo in aiuto?

Inoltre: le piattaforme Linux come base per gli ambienti di lavoro sono generalmente così poco specificate che molte cose, che sono molto semplici in un sistema coerente con un stack completo, risultano frustranti a causa della frammentazione e della complessità in Linux. Ho dedicato un'intera presentazione alle questioni relative alla piattaforma Linux per gli ambienti di lavoro (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 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 naïf al "trasferimento" di AppImage su Haiku consista in un semplice tentativo di compilare (principalmente runtime.c e servizi) i suoi componenti (cosa che potrebbe anche essere possibile!), non apporterà alcun vantaggio particolare a Haiku. Perché, in realtà, la maggior parte di questi problemi è già risolta su Haiku ed è concettualmente fondata. Haiku fornisce proprio i mattoncini per l'infrastruttura di sistema che ho cercato a lungo in ambienti di lavoro Linux e non riesco a credere che non ci siano. E precisamente:

Credeteci o no, ma non possono affrontarlo molti utenti Linux. Su Haiku tutto avviene in modo magico!

I file ELF che non hanno il bit di eseguibilità lo ottengono automaticamente con un doppio clic nel gestore dei file.
Le applicazioni possono avere risorse integrate, come icone, che vengono visualizzate nel gestore dei file. Non è necessario copiare una marea di immagini in cataloghi speciali per le icone e, quindi, non è necessario pulirle dopo aver eliminato o spostato l'applicazione.
C'è un database per associare applicazioni a 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'avvio, che sia diverso dalla directory Applications.
Nelle applicazioni non ci sono percorsi assoluti integrati per le proprie risorse, ci sono funzioni speciali per determinare la posizione durante l'esecuzione.
È stata implementata l'idea delle immagini compresse dei file di sistema: si tratta di un qualsiasi pacchetto hpkg. Tutti vengono montati dal kernel.
Ogni file viene aperto dall'applicazione che lo ha creato, se non viene specificato diversamente. Com'è fantastico!

Due file png. Nota le diverse icone, che mostrano che verranno aperti da applicazioni diverse con un doppio clic. Nota anche il menu a tendina "Apri con:", dove l'utente può scegliere un'applicazione specifica. Com'è semplice!

Sembra che molti workaround e scorciatoie necessari per AppImage su Linux diventino superflui su Haiku, che si basa sulla semplicità e sull'eleganza, grazie alle quali riesce a soddisfare la maggior parte delle nostre esigenze.

Haiku ha finalmente bisogno di pacchetti per le applicazioni?

Questo porta a una grande domanda. Se creare un sistema simile ad AppImage su Haiku risultasse molto più semplice rispetto a 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? Beh, per rispondere dobbiamo guardare alla motivazione dell'esistenza degli AppImages.

Uno sguardo dal punto di vista 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 controllo completo, poiché è un sistema personale! (In linea di principio, è possibile immaginarlo anche in modalità multiutente, spero che gli sviluppatori mantengano la semplicità)
Voglio ottenere le ultime e migliori versioni delle applicazioni, senza dover aspettare che compaiano nel mio distributore (nella maggior parte dei casi significa "mai", almeno se non aggiorno l'intero sistema operativo). Su Haiku questo è "risolto" con rilasci fluttuanti. Questo significa che c'è la possibilità di ottenere le ultime e migliori versioni delle applicazioni, ma per farlo è necessario aggiornare continuamente anche il resto del sistema, trasformandolo di fatto in un "obiettivo mobile"..
Vorrei avere diverse versioni della stessa applicazione a fianco, perché non posso sapere cosa è stato rotto nell'ultima versione, oppure, ad esempio, come sviluppatore web devo controllare il mio lavoro su diverse versioni del browser. In Haiku il primo problema è risolto, ma non il secondo. Gli aggiornamenti possono essere ripristinati, ma solo per il sistema nel suo insieme, non è possibile (per quanto ne so) eseguire, ad esempio, diverse versioni di WebPositive o LibreOffice contemporaneamente.

Uno degli sviluppatori scrive:

In sostanza, la motivazione è questa: lo scenario d'uso è così raro che l'ottimizzazione per esso non ha senso; trattarlo come un caso speciale in HaikuPorts sembra più che accettabile.

Ho bisogno di conservare le applicazioni dove mi piace, e non sull'unità di avvio. Su quei dischi spesso mi finisce lo spazio, quindi devo collegare un disco esterno o una cartella di rete per conservare le applicazioni (tutte le versioni che ho scaricato). Se collego un disco del genere, devo fare in modo che le applicazioni possano essere avviate con un doppio clic. Haiku conserva le vecchie versioni dei pacchetti, ma non so come spostarle su un disco esterno, né come poi avviare le applicazioni da lì.

Commento dello sviluppatore:

Tecnologicamente, è già possibile con il comando mount. Certo, realizzeremo un'interfaccia GUI 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. Voglio un file per applicazione che possa scaricare, spostare e cancellare facilmente. Su Haiku, questo problema è risolto tramite pacchetti .hpkg, che raggruppano, 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 assicurarmi di mantenere le loro versioni funzionanti insieme.

Numerose versioni di AppImages, eseguite accanto su una stessa Linux

Una prospettiva 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. Su Haiku, gli sviluppatori possono lavorare con i propri repository hpkg, ma questo significa che gli utenti dovranno configurarli manualmente, il che rende 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 può essere? Cosa devo pubblicare lì per Haiku? Basta un file .hpkg con dipendenze solo da HaikuPorts
Il mio software richiede versioni specifiche di altro software. Ad esempio, è noto che per Krita serve una versione modificata di Qt, o Qt configurata per un'esatta versione di Krita, almeno fino a quando le correzioni non rientrano in Qt. Si può imballare il proprio Qt per l'applicazione in un pacchetto .hpkg, ma probabilmente non è ben visto.

Una normale pagina di download per l'applicazione. Cosa si dovrebbe pubblicare qui per Haiku?

Diventeranno i pacchetti (esistenti sotto forma di directory di applicazioni, come AppDir o .app in stile Apple) e/o le immagini (sotto forma di AppImages fortemente modificate o .dmg Le app di Apple sono un complemento utile per l'ambiente di lavoro di Haiku? O questo andrà a compromettere l'armonia e porterà a una frammentazione, aggiungendo quindi complessità? Sono combattuto: da un lato, la bellezza e la raffinatezza di Haiku si basano sul fatto che c'è generalmente un modo per fare qualcosa, piuttosto che molti. D'altra parte, gran parte dell'infrastruttura per i cataloghi e/o i pacchetti di applicazioni è già in atto, quindi il sistema richiede che anche i rimanenti pochi percento si mettano al loro posto.

Secondo lo sviluppatore mr. waddlesplash

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

E tu cosa ne pensi?

Prima di rispondere...

Aspetta, facciamo un rapido controllo della realtà: in effetti i cataloghi delle applicazioni sono già parte di Haiku:

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

Non sono semplicemente supportati così bene come, ad esempio, in Macintosh Finder. Quanto sarebbe fantastico se il catalogo di QtCreator avesse, nell'angolo in alto a sinistra, il nome e l'icona 'QtCreator', avviando l'applicazione con un doppio clic?

Poco prima ho già chiesto:

Sei sicuro di riuscire ad avviare le tue applicazioni di dieci anni fa oggi, quando tutti i negozi di applicazioni e i repository delle distribuzioni se ne dimenticheranno e dimenticheranno le loro dipendenze? Sei sicuro di poter ancora accedere al tuo lavoro attuale in futuro?

C'è già una risposta da parte di Haiku, o i cataloghi e i pacchetti di applicazioni possono aiutare in questo? Penso di sì.

Secondo mr. waddlesplash:

Sì, abbiamo una risposta alla domanda: semplicemente supporteremo queste applicazioni finché sarà necessario, fino a quando qualcuno non sarà in grado di leggere correttamente i loro formati di file o garantire una funzionalità uno a uno. La nostra dedizione a far funzionare le applicazioni BeOS R5 su Haiku è una prova diretta di ciò...

Esatto!

Quale azione dovrebbe intraprendere Haiku?

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

Il software di sistema utilizza .hpkg
Per il software più utilizzato (specialmente per quello che deve programmare rilascio fluttuanti) si utilizza .hpkg (circa l'80% di tutti i casi)
Alcuni, installati tramite .hpkg, le applicazioni beneficeranno della transizione a un'infrastruttura con cataloghi di applicazioni (ad esempio, QtCreator): saranno distribuite sotto forma di .hpkg, come prima.

mr. waddlesplash scrive:

Se tutto ciò che serve è la visualizzazione delle applicazioni in /system/apps, invece, è necessario rendere i cataloghi nel Deskbar più gestibili per gli utenti, poiché /system/apps non è progettato affinché gli utenti lo aprano e lo controllino regolarmente (a differenza di MacOS). Per tali situazioni, Haiku ha un'altra paradigm, ma questo approccio è, in teoria, accettabile.

Haiku ottiene un'infrastruttura per eseguire immagini di applicazioni, versioni notturne, continui e build di test 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% del totale). Queste immagini contengono i file necessari per l'esecuzione delle applicazioni .hpkg, montati dal sistema, e dopo la chiusura dell'applicazione vengono smontati. (Forse il gestore di file potrebbe inserire i file .hpkg nelle immagini delle applicazioni, automaticamente o su richiesta dell'utente — proprio come quando trascini un'applicazione su un catalogo di rete o un disco esterno. È davvero poesia! O, più precisamente, haiku.) D'altra parte, l'utente potrebbe voler installare il contenuto dell'immagine come file.hpkg, dopo di che verranno aggiornati e trattati esattamente come se fossero stati installati tramite HaikuDepot… Dobbiamo fare un brainstorming).

Citazione di mr. waddlesplash:

Eseguire applicazioni da dischi esterni o cataloghi di rete potrebbe essere potenzialmente utile. Inoltre, l'aggiunta della possibilità di configurare un numero maggiore di "aree" per pkgman sarà sicuramente una buona funzionalità.

Un sistema del genere sfrutterebbe i vantaggi di hpkg, dei cataloghi e delle immagini delle applicazioni. Sono buoni anche separatamente, ma insieme diventeranno imbattibili.

Conclusione

Per Haiku esiste un'infrastruttura che fornisce un'interfaccia utente semplice e sofisticata per PC, ben oltre ciò che è normalmente fornito per i PC su Linux. Il sistema dei pacchetti .hpkg — uno di questi esempi, ma anche le altre parti del sistema sono impregnate di raffinatezza. Tuttavia, Haiku trarrebbe vantaggio da un supporto adeguato per cataloghi e immagini delle applicazioni. Come farlo meglio è qualcosa di cui discutere con persone che conoscono Haiku, la sua filosofia e architettura molto meglio di me. Dopotutto, utilizzo Haiku da poco più di una settimana. Tuttavia, ritengo che questa nuova prospettiva si rivelerà utile per designer, sviluppatori e architetti di Haiku. Almeno, sono felice di fare da hpkg sparring partner". Ho oltre 10 anni di esperienza pratica con cataloghi e set di applicazioni per Linux e mi piacerebbe trovarne un'applicazione per Haiku, per la quale credo siano perfetti. Le soluzioni potenziali che propongo non sono affatto le uniche corrette per i problemi che ho descritto, e se il team di Haiku decide di trovare altre soluzioni più eleganti — sono assolutamente favorevole. Fondamentalmente, sto già considerando l'idea di come rendere il sistema

Provate voi stessi! Infatti, il progetto Haiku offre immagini da scaricare su DVD o USB, generate quotidianamente.
Hai domande? Ti invitiamo nel canale telegram in lingua russa telegram-канал.

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

Da autore di traduzione: questo è l'ottavo e ultimo articolo di un ciclo su Haiku.

Elenco degli articoli: La prima Secondo Terzo Quarto Quinta Sesta Settima

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