L’altro giorno quella magnifica risorsa di notizie interessanti che è OMG! Ubuntu ha riproposto in un suo articolo un vecchio tema di cui ignoravo l’esistenza.

Il tema in questione si chiama Willibex e devo ammettere che fa la sua bella figura.

Ecco uno Screen del mio Desktop, così vi fate un'idea..

Nel caso vi piacesse, ecco com’è composto e dove trovare il tutto:

Peccato che…

Eh, mancava il peccato che… Per la serie “Non è oro tutto quel che luccica” e “Non sempre le ciambelle vengono col buco”, bisogna sottolineare che questo tema ha i suoi non ignorabili difetti.
Provate ad aprire OpenOffice o Virtualox, a leggere il testo nella barra dello svuotamento del cestino, o a rinominare una cartella e capirete…

Certo, sono difetti a cui ci si può abituare, ma sarebbe davvero carino se qualcuno che ne capisce qualcosa di temi ci mettesse le mani per risolvere questi pochi bugs: chissà che questo tema non possa guadagnare visibilità e prendersi così una meritata rivincita.


A voi piace? Avete qualche altro tema semi-sconosciuto da porre all’attenzione di tutti?

Ormai è notizia “vecchia”: Plymouth vedrà la sua introduzione nella prossima release di Ubuntu, Lucid Lynx.

E’ stato già scritto e detto molto a riguardo (a dire il vero questo articolo lo scrissi un paio di settimane fa, quando le informazioni erano molto più incerte), ma cerchiamo di capire assieme cosa questo significhi e come mai il team di Ubuntu ha preso questa decisione.

Cosa sono Usplash, Xsplash e Plymouth? C’è qualche differenza o sono progetti simili con nomi diversi?

Allora, iniziamo dicendo che tutti e tre sono dei programmi per lo Splash Screen (schermata di caricamento), cioè atti a “coprire” quelle antiestetiche scritte che normalmente si susseguivano durante la fase di boot fino a qualche anno fa.
Detto questo, bisogna sottolineare che, malgrado lo scopo comune, i tre lavorano in maniera differente:

  • Uspalsh: questo software non fa altro che avviare un X server che gestisce l’interfaccia di splash fino alla fine della fase di boot, dopo la quale viene chiuso per avviare un altro server X che verrà usato per il login e per il desktop environment.
  • Plymouth: invece di avviare un server X, come fa Usplash, Plymouth sfrutta il KMS (Kernel Mode Setting) per “disegnare” direttamente sullo schermo utilizzando risoluzione e profondità del colore native del pannello del monitor. Una volta completato il boot, il server X non fa altro che “sostituirsi” a Plymouth, eliminando così anche quel fastidioso sfarfallio tipico dell’avvio e della modifica del server X.
  • Xsplash: a differenza delle due soluzioni precedenti, avvia un unico server X, usato prima per lo splash screen e poi per il sistema. E’ integrato in GDM (Gnome Display Manager), cioè il gestore grafico di login di GNOME che solitamente si occupa anche dell’avvio del server X.

Attualmente Ubuntu Karmic come funziona?

In Karmic convivono Usplash ed Xsplash. Il primo è quel logo di Ubuntu bianco su sfondo nero che appare all’inizio della fase di boot, mentre il secondo è rappresentato dalla barra di caricamento che appare subito dopo.

Perché gli sviluppatori di Ubuntu hanno fatto questa scelta? Perché non usare Plymouth?

Perché la priorità è la velocità di boot, e condizione necessaria affinché il boot sia rapido è il caricamento del server X all’inizio, e non alla fine, del processo, in modo da poter caricare tutti i servizi che richiedono la presenza di un display.
Che Uspalsh sia stato comunque mantenuto dipende dal fatto che, prima dell’avvio del server X vero e proprio, sono necessarie alcune dipendenze, come il mount del filesystem. Nel caso questo processo non avvenga in maniera silenziosa (come ad esempio nel caso di un filesystem criptato che richiede l’inserimento di una password), Usplash torna utile per gestirlo graficamente.
La scelta di preferire Xsplash a Plymouth è spiegata chiaramente da Scott James Remnant (Ubuntu Developer Manager) in un articolo di questo Settembre sul suo blog . Scott illustra, appunto, come la priorità sia quella di un boot il più rapido possibile, e per far questo non ha senso affidarsi ad una soluzione come Plymouth o Usplash, che altro non fanno che “riempire” lo schermo in attesa che il server X venga caricato, ma è necessario avviare subito quest’ultimo, permettendo così il caricamento di una buona parte di quei servizi che altrimenti dovrebbero attendere.

Cosa aspettarsi quindi dal futuro? Sembra che non ci sia spazio per Plymouth in Ubuntu, ed invece…

È possibile trovare la risposta a questa domanda sul wiki di Ubuntu, nella pagina del Boot Experience Team.
A quanto pare l’implementazione di Plymouth in Ubuntu 10.04 sembra esser stata presa in seria considerazione, ma non come sostitutivo a Xsplash, bensì come sostitutivo a Usplash. Il vantaggio sembrerebbe esser quello di prevenire lo sfarfallio del monitor sfruttando il KMS. E’ interessante notare come anche Usplash potrebbe permettere questo, ma viene preferito Plymouth perché maggiormente sviluppato e già capace di soddisfare questa esigenza (cito testualmente “While usplash can render to the framebuffer provided by those drivers, plymouth is far more developed and capable and gives us the wanted experience out of the box.”).

Quindi, morale della favola, a quanto pare il team di Ubuntu non ha (giustamente) intenzione di tornare sui suoi passi, portando avanti Xsplash e la sua politica atta a velocizzare il più possibile la fase di boot, cercando di raggiungere l’obiettivo dei 10 secondi che si prefisse tempo addietro.
Se poi riuscirà nel suo intento lo scopriremo solo tra 5 mesi.

Python è un linguaggio di programmazione dalla curva di apprendimento molto rapida, grazie alla sua sintassi semplice, alla vastissima libreria integrata ed al fatto che ti costringe, sin dalle prime linee di codice, ad adottare una forma pulita e lineare.
Python è un linguaggio Object Oriented, ma permette anche un iniziale approccio funzionale, in modo da elaborare con calma il più complesso approccio ad Oggetti.

Se vi affacciate per la prima volta al mondo della programmazione, Python è il linguaggio che fa per voi! Ed i motivi sono diversi:

  • Come ho già detto ha una rapida curva di apprendimento iniziale
  • Permette di metter in pratica rapidamente quello che imparate (insomma, non passerà molto tempo prima di creare la vostra primissima applicazione)
  • E’ interpretato: non serve compilare il codice per eseguirlo (trasformarlo in una serie di 0 e 1 per intenderci), ma il vostro codice viene letto da un interprete che esegue all’istante quello che gli date. Questo vi farà risparmiare comunque tempo e noie, soprattutto all’inizio.
  • E’ multipiattaforma, quindi non importa se state utilizzando Linux, Windows o OSX… C’è un pitone per tutti!
  • E’ parecchio diffuso e sembra diventarlo sempre di più, quindi in rete troverete non solo molta documentazione in merito, ma anche parecchi esempi, snippet, mini-guide, ecc
  • La libreria integrata e vastissima e vi mette a disposizione moduli per quasi qualsiasi cosa vogliate fare, senza la necessità di usare librerie esterne.
  • E’ Potente e Versatile (ad esempio potete utilizzarlo anche per creare Applicazioni Web con Django)
  • Sicuramente ci sono altri motivi, ma sono le 3 di notte e io sono stanco :P

Ora siete convinti che Python è il linguaggio di programmazione che volete imparare? Benissimo, allora vediamo da dove iniziare.

Per prima cosa procuratevi tutto il necessario: se state utilizzando una qualsiasi distribuzione Gnu/Linux probabilmente avrete già Python installato (altrimenti basterà installarlo dal vostro gestore pacchetti); se invece state utilizzando Windows o OSX semplicemente scaricate la versione 2.6 dal sito ufficiale.

Ora dovete studiare (si, vi capisco, sarebbe più bello fare che studiare, ma innanzitutto vi servono le basi teoriche, non solo dello specifico linguaggio, ma soprattutto per quanto riguarda la programmazione in generale).
I testi più utili potete trovarli proprio tra la documentazione proposta sul sito ufficiale, ma, se volete accettare un consiglio, leggetevi soprattutto ‘Pensare da informatico: Imparare con Python’: il testo è un po’ vecchiotto (2002-2003), ma ha il pregio di condurvi per mano, un passo dopo l’altro, verso una maggior comprensione non solo della sintassi di Python, ma anche di quale sia il modo migliore di ragionare.

Bene, ora che avete letto il libro non sapete quasi niente e, soprattutto, non sapete fare quasi niente: non preoccupatevi, è normale, come quando avete preso la patente e siete usciti dalla motorizzazione incapaci come lo eravate prima di aver in tasca quel fogliettino rosa.

E’ il momento di imparare facendo!

Probabilmente avrete già scritto qualche riga di codice durante la lettura del libro, ma quello che dovete fare ora è pensare ad un programma che vi piacerebbe creare (mi raccomando, puntate bassi: niente interfacce grafiche o cose troppo complicate) e cominciare a scriverlo…
Ogni problema che incontrerete, ogni dubbio che avrete sarà il capito successivo del vostro personalissimo manuale di Python!
Le risposte potrete chiederle a Google, che sarà ben lieto di accontantarvi, oppure, nel caso neppure lui sia in grado di illuminarvi, potrete provare a chiedere sul canale IRC #python.it di irc.freenode.com, dove persone gentilissime e simpaticissime saranno ben felici di dedicarvi qualche minuto (magari io stesso).

Per farvi un esempio, dopo aver letto il libro che vi ho consigliato, ho deciso di creare un programmino che mi permettesse di verificare ‘empiricamente’ il Paradosso di Hall. Se non sapete di cosa sto parlando, vi spiego rapidamente: supponete che, durante uno spettacolo di magia, il prestigiatore vi metta davanti a 3 scatole, sotto una delle quali si nasconde una banconota da 10€; se indovinate la scatola allora vincente ed il premio è vostro. Una volta scelta la scatola il mago apre una delle due rimanenti, mostrandovi che è vuota e chiedendovi se volete cambiare la vostra scelta. Per quanto possa sembrare strano (infondo ogni scatola aveva il 33,(3)% di probabilità di esser quella corretta e, se poi vi trovate a scegliere tra due, dovreste aver il 50% di probabilità di azzeccare), nel caso voi decidiate di cambiarla avrete il 66,(6)% di probabilità di vincere. Non vi spiegherò perché, anche se vi accorgerete che è ovvio ragionandoci un attimo.

Per verificare empiricamente questo paradosso ho creato un semplice script in Python, non usando il paradigma ad Oggetti ma quello Funzionale (oltretutto facendolo anche male), ma quello che conta è che mi sono trovato costretto a cercare in internet come funziona il modulo random per creare numeri semi-casuali, il modulo optparse per far si che si potesse specificare come parametro del programma il numero delle ripetizioni, ecc ecc
Inoltre ho avuto occasione di leggere codice scritto da altri, imparando come utilizzare determinati comandi, come risolvere determinati problemi, come meglio organizzare il mio codice, e via dicendo…

Successivamente basterà alzare il tiro, cercando di creare applicazioni sempre più complesse (o migliorando quella su cui avete cominciato).

Il vero apprendimento, quindi, si fa sul campo, come in ogni cosa. Questo è l’unico modo di imparare davvero: provando!

Buona programmazione a tutti :D

Cosa ne pensate? :)

docky

Ultimamente si possono leggere in rete parecchi articoli riguardo la recentissima scissione tra Docky (la famosa barra tuttofare che tutti amiamo) e Gnome-do (del quale docky faceva parte come tema).
Le motivazioni di tale decisione sembrano dipendere dal fatto che, sin dall’inizio, l’inserimento di Docky all’interno del progetto Gnome-do è stato considerato un “hack”, poco elegante e difficilmente mantenibile.
Gli autori sono pienamente consapevoli che questa decisione porterà alla perdita di alcune funzionalità e che l’integrazione con Do ritornerà alla vita solo in un successivo stadio di sviluppo.
(Potete leggere con i vostri occhi qui se siete interessati)

L’integrazione con Do, quindi, sembra essere in progetto, anche se considerata non prioritaria evidentemente.

La cosa che mi auguro vivamente è che i ragazzi di Docky non si dimentichino che quello che ha sempre reso la loro applicazione qualcosa di unico, ben oltre le normalissime dock come AWN o Cairo, era l’integrazione tra la dock e il launcher: dimenticarsi questo e non dargli la dovuta considerazione potrebbe, almeno per quanto mi riguarda, ad un declassamento di docky ad una dock come tutte le altre (certamente diversa, ma che non porta nulla di nuovo) e, quindi, assottiglierebbe le fila dei suoi affezionati utilizzatori…

Se questo succedesse mi auguro davvero che qualche anima pia porti avanti il progetto di Docky come tema di Gnome-Do, perché io non posso assolutamente rinunciare alla comodità ed ai vantaggi sotto il piano ergonomico e dell’usabilità a cui mi ha viziato :)
Ed, inoltre, non potrei più vantarmi con amici e conoscenti di quanto è facile e comodo avviare programmi, bookmarks, ecc su Linux :P

Voi cosa ne pensate?

In ogni caso, se volete provarla per soddisfare la vostra curiosità, ecco dove cercare:

  • Se volete compilare da sorgenti, trovate una buona guida per Ubuntu (se usate Fedora cercate di ‘tradurre’ le dipendenze) sul blog GreenBit :)
  • Se usate Ubuntu e siete PPA-dipendenti Marco, in un commento sul blog di Bl@staer, ne ha indicato uno che fa proprio al caso nostro (testato io stesso :P)

Alla Prossima ;)