Edizione straordinaria

Riccardo Cagnasso ha lasciato un commento sul post Ubuntu e il suo ciclo semestrale. Per rispondere a questo commento, mi vedo costretto a postare una "edizione straordinaria" tutta dedicata a lui:

Secondo me c'e' un baco di fondo in quello che dici. Il fatto e' che ubuntu e' una distribuzione fatta per essere mantenuta up to date. E' chiaro che tutti dipende dagli usi, infatti esiste ubuntu LTS, ma per l'uso generico uno vuole avere una serie di cose aggiornate (firefox, vlc, flash etc etc) senza considerare driver e patch di sicurezza.

Possibilissimo che ci sia un baco, in fondo è solo una mia teoria basata su una serie di considerazioni nate dalla valutazione nel corso del tempo di un fenomeno praticamente costante.
Da che mi ricordo io (ovvero dai tempi di Dapper), sul forum di ubuntu-it (in particolare, ma non solo) in occasione di ogni rilascio di versione (quindi ogni 6 mesi) è sempre stato un continuo passaggio da uno stato di attesa spasmodica nella speranza di ottenere un qualcosa di assolutamente perfetto, a uno stato di rabbia nella constatazione che la nuova versione aveva ancora un certo numero di problemi che talvolta obbligavano molti a reinstallare la vecchia.
Tra le richieste di assistenza nei forum e le problematiche che ho riscontrato personalmente nelle varie versioni provate, ho elaborato la mia teoria delle “versioni autunnali e primaverili” (che peraltro pare essere condivisa abbastanza anche da vari utenti del forum ufficiale, a giudicare da certe discussioni che ho letto).

Mantenere aggiornati pacchetti al di fuori della versione del repository attuale e' quello che io chiamo "scardinare la distribuzione con un piede di porco" e alla fine ti dara' piu' problemi di quanti te ne diano gli aggiornamenti. Senza contare che fare un aggiornamento ogni due e' il modo piu' semplice per far incatastare l'aggiornamento quando lo fai. (perche' e' uno scenario molto meno testato)

Le uniche problematiche che mi vengono in mente sono correlate alle difficoltà di compilazione da sorgente (che nel caso citato di openoffice e firefox poi non è nemmeno del tutto vera e sicuramente non ha nulla di complicato), cosa peraltro indispensabile in tutti quei casi in cui non si riesce a trovare un pacchetto adatto nei repository (ovviamente anche questo dipende dall'uso che si fa del computer, ma a me è capitato diverse volte di cercare dei programmi particolari e trovare solo codici sorgente da compilare).
Per il resto, so benissimo che saltare un aggiornamento rende di fatto pressoché impossibile fare i successivi (a meno di non avere competenze eccezionali in materia), ma io parlo di prove su macchina virtuale. In effetti, il passaggio effettivo, quando l'ho fatto (2 volte finora), l'ho sempre fatto da zero mediante installazione, forse con la futura Lince riuscirò a provare un aggiornamento, dato che da LTS a LTS si dovrebbe poter fare senza problemi... forse...

Se vuoi usare un approccio come quello di D. che non aggiorna finche' non ha la necessita' di un aggiornamento invece di seguire le release, fai come D. appunto, usa slackware, o archlinux o gentoo o una qualsiasi altra distribuzione progettata per avere una gestione piu' granulare dei pacchetti che ti permetta di aggiornare o de-aggiornare singoli pacchetti senza dover scardinare tutto.

In effetti, se facessero una versione “rolling” di Ubuntu, credo che sarebbe apprezzata da moltissimi utenti. Finora nell'utilizzo di una rolling mi sono limitato a Debian Sid, controllando accuratamente gli aggiornamenti, tranne un paio di volte... e lì ho apprezzato la stabilità di Ubuntu e l'ottimo lavoro fatto dalla Canonical (anche se quella che usavo all'epoca: 7.04 Feisty, non era una LTS).
Slackware l'ho utilizzata per un po' di tempo (versione 12, quella già più adatta a tipi come me...) ed ero terrorizzato all'idea di provare una distribuzione storicamente “difficile”, ma ho avuto molte meno difficoltà con la “difficilissima” Slackware che con la “facilissima” Mandriva (anche perché con Slackware ho cercato di documentarmi prima di gettarmi a capofitto), poi ho voluto trasgredire alla mia stessa regola e ho aggiornato alla versione 13 appena è uscita... e, per citare D. sono arrivato a Waterloo immediatamente.
Arch finora l'ho provata solo in virtuale e mi sta piacendo davvero: semplice, scattante, facile da configurare e sufficientemente stabile, per essere una rolling. Probabilmente l'affiancherò presto a Ubuntu, tanto per avere l'accoppiata stabile-aggiornata.

Detto questo tenderei a sottolineare che i bug degli aggiornamenti di ubuntu, in fondo, sono dovuti al fatto che in un giorno la distribuzione passa da un testing tutto sommato limitato e con aggiornamenti molto frequenti (e sappiamo che patchare un bug puo' portare a un'altro bug... o a un milione) a un utilizzo su milioni di macchine e quindi tutto salta fuori. Pero' solitamente gia' dopo 15 giorni il 90% dei bug e' stato risolto, quindi basta aspettare qualche settimana. (io in realta' aggiorno e poi al massino fixo il bug, la cosa non mi ha mai richiesto piu' di un paio d'ore e ogni sei mesi mi sembra che si possa fare) (beh io in realta' ora uso mac quindi di tutta sta roba me ne frego altamente)

Infatti la mia politica è sempre stata quella di attendere almeno 15 giorni prima di fare il grande passo, a meno di non voler solo provare le novità, nel qual caso la cosa più semplice è quella di liberare una decina di GB e creare una partizione di prova (che poi, eventualmente, potrà anche diventare la partizione effettiva di lavoro, se il test viene superato a pieni voti, praticamente quello che ho fatto quando sono passato da Feisty a Hardy), ma è la mia politica e non coincide con quella degli altri, dato che nel giro di pochissimi giorni dall'uscita “devo” comunque scaricare e installare (su macchina virtuale) le versioni intermedie, altrimenti non riesco a rispondere a chi è così disperato da chiedere soccorso proprio a me nel forum con cui collaboro (e poi, almeno, mi faccio un'idea di cosa troverò nella prossima versione LTS).

Per il resto, (a parte il discorso sul MAC che sicuramente ti evita tutte queste problematiche), con Ubuntu tu aggiorni semestralmente e poi sistemi le cose che non vanno, ma questo fa desumere che tu sai come muoverti, sai cosa fare e sai dove intervenire, però una distribuzione come Ubuntu si rivolge anche a utenti che non sanno come agire di fronte all'imprevisto, e tante/troppe volte non si prendono nemmeno la briga di consultare la documentazione, prima di gettarsi a capofitto in quella che ritengono essere una procedura normalissima e totalmente sicura.
Questi utenti, sovente, non vogliono capire che la loro scheda grafica (che ha tutti gli effetti strafighi e va benissimo con Vista) è incompatibile con i “cubi rotanti atomici” e le “finestre di gomma spaziali” di “compiz-mazinga”, e sovente sono anche troppo giovani per aver conosciuto il mondo testuale del DOS e sapere che Windows in origine era solo una interfaccia grafica da avviare all'occorrenza (e nemmeno sempre, che la maggior parte dei programmi che usavo io all'epoca non la sopportava proprio), quindi quando dici loro che, per risolvere quel problema particolare, devono aprire un terminale e scrivere dei comandi, al posto di fare una serie di click (che poi si può anche fare, se avessero tutti la stessa identica interfaccia grafica standard senza alcuna personalizzazione) ecco che quegli utenti scappano a gambe levate, piangendo e urlando che Ubuntu fa schifo.
Personalmente non mi faccio problemi in merito (in fondo a me piace, la uso e riesco anche a risolvermi quei piccoli problemi che riscontro ogni tanto), ma quando leggo la storia del bug #1 di Ubuntu, queste cose mi fanno dubitare della possibilità di combattere (non di vincere, che non ci crederà nemmeno Mark Shuttleworth, ma almeno di combattere) tale bug.

Commenti

  1. >attesa spasmodica nella speranza di ottenere un qualcosa di assolutamente perfetto, a uno stato di rabbia nella constatazione che la nuova versione aveva ancora un certo numero di problemi

    Se gli utenti son stupidi chi se ne frega? Le cose perfette non esistono, Ubuntu ha decisamente migliorato il suo sistema di aggiornamenti che sono piu' solidi e meno problematici anno dopo anno, ma "perfetto" non esiste.

    >Le uniche problematiche che mi vengono in mente sono correlate alle difficoltà di compilazione da sorgente (che nel caso citato di openoffice e firefox poi non è nemmeno del tutto vera e sicuramente non ha nulla di complicato), cosa peraltro indispensabile in tutti quei casi in cui non si riesce a trovare un pacchetto adatto nei repository (ovviamente anche questo dipende dall'uso che si fa del computer, ma a me è capitato diverse volte di cercare dei programmi particolari e trovare solo codici sorgente da compilare).

    Alt. Io pensavo che tu parlassi di usare pacchetti .deb o repository non ufficiali. In questo caso il problema si pone quando aggiorni perche' magari il repository non e' disponibile per la nuova versione o magari salta fuori qualche conflitto fra i .deb vecchi e nuovi o perche' non ti viene aggiornato il pacchetto custom quando magari la nuova distribuzione ha una versione nuova di quella roba che gli server per l'aggiornamento e.. CRACK

    Tu parli di sorgenti. Ok, DI SOLITO compilare un software non e' difficile. DI SOLITO, prova compilare correttamente wine, prova! Software complessi possono necessitare di varie opzioni di ./configure per usare le lib giuste e offrire le giuste feature. Considera anche le varie patch da applicare, se ti compili firefox da sorgenti, col cappero che avrai le integrazioni con ubuntu che che ha la versione pacchettizzata... a meno di non metterti a patchare i sorgenti (buon divertimento), ti ricordo che i pacchetti di debian/ubuntu sono pesantemente personalizzati.

    Inoltre c'e' un altro problema: dove la metti la roba che compili? Nei path standard? Mmh bad idea, la roba nei path standard e' pensata per essere gestita da dpkg e alternatives, ma cosi' facendo gli metti "in casa loro", roba che non conoscono... bad idea. Certo, puoi usare --prefix e fare un tree per i pacchetti custom, ma poi dovrai gestire i path degli utenti , insomma, non certo una soluzione molto agevole, inoltre l'aggiornamento di questa roba sara' strettamente manuale e poco agevole anch'esso.

    RispondiElimina
  2. Più che stupidi, direi che si illudono troppo: in fondo si parla sempre di un sistema operativo, mica della venuta di un qualsiasi messia.

    Hai ragione: non avevo pensato ai pacchetti da repo non ufficiali (visto che non li uso). Comunque so bene che ci sono molte difficoltà a compilare sorgenti, in certi casi (per fortuna Wine è nei repo e non ho dovuto compilarlo).

    Per gli ultimi punti, non mi è chiaro: che intendi con percorsi standard? E con percorsi degli utenti?
    Io di solito ste cose le metto in /opt

    RispondiElimina
  3. nel senso. se tu vai a mettere i binari in /bin o /usr/local/bin vai a pestare i piedi a dpkg e a alternatives che sarebbero felici di sapere quello che c'e' installato li dentro.

    Tu dici che metteresti la roba in /opt, e questo significa che sai quello che fai! ma non che il problema sia risolto. Quando parlo di path degli utenti parlo di $PATH, se decidi di mettere roba in opt dovrai modificare il tuo $PATH e quello di tutti gli altri utenti. Per quelli nuovi c'e' /etc/skel, ma per quelli che gia' esistono? Certo non e' insormontabile ma son problemi che cominciano a impilarsi.

    E poi mica finisce qua'. Intanto non c'e' solo /bin, ma anche /etc, /var e compagnia. Se tu installi l'intero albero di firefox dentro /opt, questo semplicemente non trovera' i plugin (non parlo dei plugin utente, parlo di roba come flash) installati dal package manager di ubuntu, perche' non vengono installati dentro /opt e quindi vai a installare a mano flash, e moonlight e tutto il resto.

    Infine mica esiste solo firefox e i programmi lanciati direttamente dall'utente, per cui $PATH e' l'unica cosa di cui devo preoccuparmi. Se ho bisogno di python3.1 e magari su una vecchia ubuntu LTS non c'e', non basta metterlo in /opt, perche' in cima agli script c'e' #!/bin/python, non #!/opt/bin/python e quindi alla fine torno o a fare un link simbolico in /bin (scassando alternatives) oppure mi metto a smandruppare con alternatives, che pero' non e' una grandiosa idea visto che alternatives dovrebbe essere un coso al servizio di dpkg. E questo non vale solo per python o per gli interpreti.

    RispondiElimina
  4. Capito.

    Per quanto riguarda gli utenti, questo mi lasciava interdetto: io faccio riferimento al caso classico di un computer al quale accedo solo io, come utente, mentre tu evidentemente ti riferisci a una situazione diversa (credo di capire che tu prepari il computer per diversi utenti).

    Per il resto, personalmente non mi faccio particolari problemi a "esportare" il $PATH, o a creare link simbolici, e tutto ha sempre funzionato perfettamente.
    Di che problemi parli?

    RispondiElimina

Posta un commento

Tranquillo, il tuo commento dovrà essere approvato dall'amministratore.
Non preoccuparti se non apparirà immediatamente, non sono sempre online... ;)

Post popolari in questo blog

Presentazione...

Comincia il lavoro

Rivelazioni