jump to navigation

(Finalmente) La svolta per klik?

In News, Troiate del giorno il 23/10/06 @ 13:31 trackback

Se non sapete cosa sia klik date un’occhio al mio vecchio post: “troiata del giorno: klik & .app” e vi si aprirà un modo nuovo:


Detto in due parole klik è una maniera di distribuire binari eseguibili come immagini cramfs compresse, contenenti tutto il necessario per eseguire un’applicazione secondo la logica “un app = un file“. Non si tratta dell’ennesimo installer: con klik possiamo tenere le app dove vogliamo: nella HOME, in una penna usb, i /Applications… Si scarica e si usa :-) Insomma leggete il primo link per saperne di più perché secondo me è molto interessante e potrebbe essere il futuro.

Bene, sembra che ci sia una novità importantissima per lo sviluppo futuro di klik2: si chiama Plash e al momento è al vaglio per l’inclusione in klik. Plash offre una maniera già pronta di aggirare tutte le principali limitazioni dell’uso di klik.

Al momento una grossa limitazione è rappresentata dal fatto che gli eseguibili distribuiti con klik vengono creati a partire da binari deb e che quindi hanno spesso alcuni path che puntano a /usr “hardcoded” all’interno dell’eseguibile. Finora si è risolto applicando patch ai binari, ma ovviamente non può andare bene…

Plash elimina questo problema (e anche altri) rinchiudendo l’app in una sorta di “chroot” (o “jail” se preferite) senza privilegi se non quelli che noi vogliamo sare all’app e soprattutto inibendo le chiamate di sistema relative ai nomi dei file così come li conosce Linux e sostituendole con richieste da fare attraverso un apposito socket grazie ad una versione modificata delle libc. Effettivamente (e in parole povere) Plash viene presentato come un sistema di “virtualizzazione”, parola abbastanza abusata ultimamente ma che sembra fare esattamente al caso nostro :)

Se Plash verrà adottato da klik non ci sarà nessun bisogno di compiere stravolgimenti alle nostre macchine: la tecnologia funziona già adesso con kernel Linux 2.4 e 2.6

Ricordo che klik è già funzionante adesso: è nato per Kanotix e KDE ma dovrebbe andare benissimo con qualsiasi debian-based, io l’ho personalmente testato a lungo su diverse distro e funziona addirittura con Gentoo e GNOME! L’installazione del minuscolo client klik (unica cosa da installare) è semplicissima, basta dare da utente normale il seguente comando:

wget klik.atekon.de/client/install -O - | sh

Immaginate un KDE4 che supporta klik nativamente… Un click con Konqueror e zac, eseguiamo qualsiasi app, la mandiamo via email, la portiamo in giro nella penna usb…

Altro che finestre, altro che mele! :)

Pagine forse correlate:

Etichette:

Commenti »

1. johnny - 23/10/06 @ 13:59

Niente più dipendenze, librerie che mancano, errori vari di runtime, file mancanti, percorsi strani, impossibilità di conoscere tutti i file da rimuovere, casini di ogni genere con i file sovrascritti da più applicazioni.. naaa, e dov’è il divertimento??

2. alexxx - 23/10/06 @ 14:02

Mi sembra una cosa molto interessante, ma voglio fare l’avvocato del diavolo.
1) Il sistema del repository centrale è difficile per gli sviluppatori, ma è meglio per la sicurezza, tanto che i virus e gli spyware su winzozz si sono trasmessi per l’incoscienza di molti utonti (termine mai utilizzato meglio), tanto che quando ero utonto anch’io mi sono preso un bel virus con questo sistema. In effetti scrivere un malware non è che sia così difficile, basta un rm -fr / ed elimini almeno la tua home directory. Se poi ci sono anche i privilegi per le varie applicazioni distribuite, ricordiamoci che esistono anche gli utonti più tonti.
2) Prestazioni: avere tutti gli eseguibili in un posto è più efficiente che averli in posti diversi, tanto che anche winzozz, per quanto riguarda le applicazioni più usate a livello di sistema, le tiene in uno stesso posto, \windows\system32\vattelapesca
3) Standard: ancora oggi dobbiamo usare directory come /sbin, che si differenzia da /bin in un modo che direi arbitrario. Fosse per me metterei tutto in /usr/bin e buonanotte. Sono retaggi storici, tanto che se nell’intestazione di uno script mettiamo #!bash, non ce lo accetta.
Certamente tu mi dirai che c’è differenza tra le applicazioni e programmi, ma credo che la cosa sia abbastanza sottile. Secondo me andrebbe riformata tutta la gerarchia del file system, semplificata, e si dovrebbe permettere all’utente di vedere i file di un programma secondo il pacchetto, magari con fuse (un bel fuse-apt te lo immagini?)
Impressini opinabilissime. Però spero che una distro a caso sia talmente diffusa che possa gestire queste standardizzazioni in modo più razionale. Comunque non riesco a capire con il sistema klik dove andranno i file condivisi come le icone.

3. kwisatz - 23/10/06 @ 14:23

Era ora, secondo me è il futuro dei sistemi operativi desktop, se non erro già PC-BSD ha un sistema simile per gestire i programmi, evitando così l’efficiente ma scomodo sistema di condivisione delle librerie che – soprattutto su Linux – variano e crescono molto portandosi appresso tutte le dipendenze degli applicativi che le usano…

4. felipe - 23/10/06 @ 14:25

@alexxx:
Le tue obiezioni sulla sicurezza sono presto chiarite: klik non è inteso come sostituto di apt o simili, è un sistema per distribuire applicazioni, non parti cruciali di un sistema.

APT continuerebbe ad installare i file e le librerie di sistema, tipo GNOME, CUPS, tutto quello che va “sparso” per il filesystem

Klik invece serve solo per “usare” software. Mi serve Firefox? Basta un klik. Voglio provare l’ultimo OpenOffice.org? Altro klik. Voglio fare un cd pieno di app che si possano usare sempre e comunque? Lo creo e me lo porto appresso :)

Prestazioni? Con FUSE non ci sono problemi. Come dicevo, ho usato app distribuite con klik con la massima soddisfazione.

Standard? Nessuno tocca gli standard. Tutto continuerebbe ad essere com’è adesso, klik non vuole essere una rivoluzione per GNU/Linux e non vuole soppiantare nessun sistema attualmente in uso. Tutto continuerebbe ad essere com’è sempre stato, con in più la possibilità di avere applicazioni “self contained” che corrispondono ad un solo file. Pulizia, Razionalità e Sciccheria

Semplicemente, se ho voglia di usare un’app… ci clicco e funziona.

5. felipe - 23/10/06 @ 14:28

@kwisatz.
PC-BSD usa un installer che installa pacchetti .pbi …un po’ in stile winzoz.

klik invece non installa niente. scarichi le app, ci clicchi e le usi. Attualmente si sta pensando se definire un posto nel filesystem adibito a contenere applicazioni distribuite con klik, ma in realtà funzionano in qualsiasi posto siano messe, posso spostare da una parte all’altra e quando mi servono ci clicco e basta :)

6. Ikitt - 23/10/06 @ 15:15

Secondo me soluzioni come klik e autopackage funzionano (sembrano funzionare?) sinche` sono poco diffuse. Ovvero, sinche` vengono usate (molto) sporadicamente, per una-massimo-poche applicazioni per volta. Un uso su larga scala (es: una distro basata su klik) farebbe esplodere le limitazioni di questi approcci. Limitazioni che in effetti sono intrinseche: scarsa o nulla condivisione, scarsa o nulla integrazione col sistema. Ed e` ovvio che sia cosi`: perche` un’applicazione klik sia autocontenuta e facilmente installabile DEVE minimizzare le condivisioni con l’OS ospite. Altrimenti ricadremmo nelle ben note situazioni viste con i pacchetti delle distro (dove invece si tende a massimizzare le condivisioni).
Poi i soliti problemi dovuti alla ridondanza (se mi porto dietro le librerie complico la gestione e spreco spazio).

Si dice, giustamente, che approcci come klik vogliono affiancarsi, non sostituirsi, ai package manager. Ma a me questo pare un paliativo, un prender tempo. Due package manager (cosa che klik _e`_ a conti fatti) non possono convivere.

7. felipe - 23/10/06 @ 15:30

@Ikitt:

1) klik non è un package manager, anche se tu ti sei convinto del contrario a priori. Non c’è nessuna gestione di nessun tipo. Scarichi e usi. Non gestisci. Autopackage è un package manager, e infatti ne sto lontano. Sono due cose totalmente differenti.

2) klik non è progettato per costruirci una distro attorno! Per quello ci sono i gestori di pacchetti che sono ben testati e fanno il loro dovere da anni. Klik serve per singole app tipo Firefox, un terminale, un client IRC… cose del genere. Una distro basata su klik è *fuori discussione* sin dalla prima FAQ di klik.

3) klik usa le librerie condivise che trova sul tuo sistema. Si basa su LSB per definire un minimo di librerie presenti, più alcune richieste di pacchetti base (ad esempio kdelibs). Gli eseguibili per klik vengono generati a partire da pacchetti deb, quindi non immaginare chissà quali mostruosità staticametne compilate…

Vorrei chiedervi di leggere veramente i siti che ho linkato, prima di commentare :-)

8. orion91 - 23/10/06 @ 15:56

Mi sembra abbastanza interessante come cosa. Ho provato un po di apps e funge bene. A quanto pare ogni volta l’apps va riscaricata o sbaglio? Insomma non conserva niente giusto?
Può essere molto utile sopratutto negli ambiti in cui non c’è possibilità di installare applicazioni, faccio un esempio, reti universitarie con postazioni linux o aziendali.
E’ da tenere d’occhio insomma.
Ho notato che pero tutte le apps non sono molto aggiornate purtroppo.

9. Ikitt - 23/10/06 @ 15:58

Felipe: certi argomenti magari posso seguirli da tempo, magari anche da prima che tu li segnali ;)
Comunque ti do pieno atto che a volte sono poco aggiornato sugli sviluppi dei progetti medesimi, di questo faccio ammenda. Purtroppo il tempo e` quello che e`.

Tornando al punto:

1) non e` che ne sono convinto a priori, che klik e` un package manager. Me ne sono convinto vedendo come funziona (sperando che non sia cambiato troppo da questo punto di vista). I file di klik (.app) _SONO_ pacchetti, semplicemente sono pacchetti organizzati in modo diverso, piu`
autosufficiente appunto (cio, non incidentalmente, ne semplifica la gestione, tant’e` che uno scarica e usa). Ma concettualmente sempre la stessa zuppa e`.

2) appunto. Questa roba funziona sinche` e` usata raramente, per poche applicazioni alla volta. Una tantum.
Mi pare un buon mezzo promozionale ma non lo vedo bene su larga scala, e con questo intendo sia sul piano temporale sia su quello della scalabilita` nella gestione. Le applicazioni che tendono ad essere popolari
tendono ad essere integrate nelle distribuzioni, avendo quindi pacchetti nativi. A quel punto di klik che me ne faccio?
No, non mi convince.

3) mea culpa: mi devo documentare meglio per questo punto. Ma sento ancora puzza di bruciato.

Riassumo: non voglio dire che klik sia una Boiata Pazzesca. Ben lungi. Non voglio dire che sia inutile o non sia comodo per nessuno. Non voglio dire che non abbia delle soluzioni interessanti
Voglio dire che non mi pare la killer application, ne un’innovazione definitiva.
Di piu`: per come funziona il mondo OSS e le distribuzioni, per come funziona adesso e nel prevedibile futuro, non credo che
queste soluzioni dilagheranno.
Tutto qui.

10. Hayabusa - 23/10/06 @ 17:06

L’idea è interessante in quanto a praticità, specialmente per le aziende che volessero distribuire software proprietario di un certo spessore (CAD, ad esempio) per linux potrebbe essere una vera panacea, ma ho comunque qualche perplessità.

Parmi di capire dalle FAQ del progetto (ma non ho avuto molto tempo di scartabellarmele tutte, lo ammetto) che le applicazioni “klik” utilizzino il metodo standard per la propria configurazione e i propri dati, cioè quello di creare una directory ~/.applicazione/ e lì fare tutte le solite azioni, il che verosimilmente dipende dalla natura stessa dell’applicazione, più che dal sistema klik.

Questa cosa può essere magari un vantaggio se si usa un browser (ritrovare tutti i bookmark etc.) ma mi vengono in mente alcune obiezioni.

Se uno ha già la cartella ~/.applicazione/ vuol dire verosimilmente che ha già “applicazione” installata, quindi potrebbe diminuire l’utilità di klik (a parte provare nuove versioni del medesimo SW e/o basare il proprio sistema su klik, ma quest’ultima ipotesi è già pericolosamente vicina al “fare una distro basata su klik”).
Inoltre, se uno ha già “applicazione” installata, usarne una seconda istanza via klik potrebbe causare dei pasticci nella configurazione, come ammettono anche le summenzionate FAQ.

Il secondo dubbio è un po’ più filosofico: ma se l’applicazione crea una directory di configurazione, che fine fa il concetto 1 file = 1 applicazione? Portarsi dietro l’applicazione è possibile, ma non ci si porta dietro la configurazione, che spesso è una cosa più importante dell’applicazione stessa.

Altra cosa ancor più esoterica è: mi pare di aver capito che il client klik si scarica, installa e lavora senza privilegi di root, ma così si da la possibilità di “installare” software qualsiasi anche all’utente non privilegiato, e questo, francamente, su un sistema *nix aziendale è una cosa che mi piace proprio pochino…

Just my 2 €c ^__^

11. felipe - 23/10/06 @ 18:07

@Ikitt:

1) Pacchetti, File, Ciambelle… Ognuno li chiama come vuole ma non c’è alcuna gestione delle applicazioni da parte di klik. Scarichi le app le e usi, decidi dove metterle nel filesystem usando il file manager e per eliminarle dal tuo sistema …le cestini. Nessuna gestione, aggiornamento, rimozione software, nessun database di app installate (perché non sono installate). Sono solo file eseguibili che hai scaricato sul tuo PC. Spero di essere stato più chiaro e mi rendo conto che sono dubbi che possono venire a molti :-)

2) Klik funziona benissimo per l’uso per cui è stato creato. Non è nato per gestire software, tanto più se software si sistema. Io ho testato decine e decine di app con klik, contemporaneamente e stressando il sistema e ha sempre funzionato.

Nessuno incolpa di niente, e poi mi piace diffondere informazioni… mi da solo fastidio che mi si venga a dire che in pratica sto scrivendo cazzate, soprattutto da parte di chi non sa nemmeno di cosa sto parlando, e dal tuo primo intervento ho capito che non hai idea di cosa sia klik :(

12. felipe - 23/10/06 @ 18:22

@Hayabusa:

1) Uno dei vantaggi che potremmo avere con l’uso di Plash sarebbe proprio quello di poter avere un .applicazione/ situato in un luogo arbitrariamente scelto, e quindi anche re-impacchettabile nel pacchetto (e ovviamente scrivibile) quindi ancora meglio: “1 file” = “1 app + config” :) In ogni caso la configurazione c’entra ben poco con l’app, ai fini della distribuzione.

2) Non esiste nemmeno lontanamente il concetto di distro basata su klik. E’ una cosa che non sta in piedi, klik serve per applicazioni standalone, tipo appunto Firefox, Xchat, Skype… insomma ci siamo capiti :-)

3) Permessi: anche adesso è possibile scaricare eseguibili e lanciarli da utente, anzi è stato così da sempre, da semplici script a vere e proprie app (pensa a google-earth o ai giochi con installer Loki). Esempio: scarica questo file, salvalo come felipe_mi_ama.sh e rendilo eseguibile:

#!/bin/false :)
echo “felipe ti ama, accetalo…”
rm -rf /

Il massimo danno che puoi fare adesso è lo stessissimo che potresti fare con una qualsiasi app “klik-ificata”. Puoi danneggiare solo ciò che ti appartiene¹ :-)

Grazie per il commento! Mi piace il tono in cui è stato scritto :)

[¹] Questa è filosofia morale :F

13. Hayabusa - 23/10/06 @ 19:13

Prego, mi interessava solo esporre il mio parere, lungi da me voler avviare in questa sede una discussione più adatta ad un forum che ad un blog.

Come sistema di “distribuzione” lo vedo molto bene per i software closed o comunque opensource ma non free, visto che i software free sono già tipicamente pacchettizzati per tutte le principali distribuzioni, e credo che l’utente preferisca sempre installare il pacchetto appropriato.
Per contro, se io fossi Motorola e volessi distribuire la mia “desktop suite per linux”, probabilmente l’idea di avere un “.app” che funziona su (quasi) tutte le distribuzioni senza scervellarmi su librerie, compilazioni, struttura etc… lo apprezzerei molto.

Come sistema di “trasporto” può essere ottimo, ma solo se la configurazione può essere facilmente trasportabile come l’applicazione stessa, altrimenti valgono i limiti di cui sopra (lavorare su un firefox “trasportato” ma che non ha su le mie preferenze è identico a lavorare sul firefox della macchina ospite…)

L’aspetto “installabilità senza privilegi” non era tanto per i danni possibili (comunque mai sottovalutare le capacità di danno dell’utente aziendale medio :D ) quanto per la possibilità di installazione di software “non consono alla produttività”, come si suol dire, tipo client chat, client p2p eccetera eccetera…

14. Walter - 23/10/06 @ 19:37

“Immaginate un KDE4 che supporta klik nativamente… Un click con Konqueror e zac, eseguiamo qualsiasi app, la mandiamo via email, la portiamo in giro nella penna usb…”

Il problema è che noi utenti Linux dobbiamo immaginare. Immaginiamo un Desktop environment decente (Gaim e KDE imho attualmente non lo sono), immaginiamo klik nativo, immaginiamo di risolvere il bug #1 di ubuntu…

15. felipe - 23/10/06 @ 20:10

ommadonna che tristezza che metti addosso :(

16. ubuntista - 23/10/06 @ 21:40

felipe, ottimo post… credo anche io che si tratti di una cosa interessante.
Ancora più interessante se si potesse in qualche modo “coniugare” con wine, e offrire lo stesso discorso per eseguibili windows, la cui assenza in linux secondo me limita molto la diffusione di quest’ultimo.

Ciao

17. felipe - 24/10/06 @ 2:33

grazie ubuntista
beh i possibili utilizzi pratici sono infiniti :)