Il grande switch

micampe — Thu, 22 Jun 2006 05:03:00 -0700

Nonostante il mio breve recente post fosse poco più che riportare un paio di link, ha avuto l’effetto di stimolare un po’ la discussione anche intorno a me e mi sento in dovere di espandere un po’ quello a cui ho pensato leggendo queste discussioni.

Credo che ci siano due filoni distinti, che sono stati raccolti da persone diverse: Mark Pilgrim ha cambiato sistema operativo da Mac OS X a Ubuntu Linux (primo filone) perché vuole avere la sicurezza di poter conservare a lungo e intatti i propri dati (secondo filone).

Entrambi i filoni possono prendere strade diverse, una, comune tra i due, è quella che riguarda la libertà del software e dei formati che usiamo, un’altra è quella più pratica, che riguarda più il software che usiamo e il modo in cui produciamo e trattiamo i nostri dati. Credo che una delle più grandi qualità di Mark e il motivo per cui è così efficace in quello che scrive, è che riesce a collegare direttamente l’importanza della libertà alle applicazioni pratiche, invece che concentrarsi su astratta filosofia che difficilmente convince chi il computer lo usa per risolvere i problemi pratici.

Ludo sceglie di commentare l’abbandono di OS X e mi chiama direttamente in causa, Stephen O’Grady sullo stesso argomento si concentra di più sul perché Mark ha scelto Ubuntu e sul perché questo è successo ora.

Io fondamentalmente concordo con Stephen sul fatto che questa discussione sia arrivata ora perché Ubuntu ha alzato lo standard delle distribuzioni Linux, cosa appunto dimostrata dal fatto che Mark la considera sufficientemente buona da sostituire Mac OS X nonostante la sua più che ventennale esperienza su Mac. Come conseguenza, anche Tim Bray è stato portato a considerare nuovamente la possibilità di usare Linux.

A Ludo ho risposto direttamente nei commenti, ma riporto qui la mia considerazione puramente pratica: Windows non riesco ad usarlo, nel senso che non sono capace. Quando lo uso sono lento, mi scontro con problemi (chi mi dice se e come posso far funzionare il deploy remoto da uno script ant su Tomcat su un server Windows?) che non capisco e non so da dove iniziare per risolvere. Alle partite non sono molto interessato quindi mi accontento di vederle in TV :).

Riguardo invece alla questione della conservazione dei dati non penso ci sia molto da dire, sta diventando sempre più importante man mano che la nostra vita diventa più digitale. L’esempio più semplice sono le foto: tra vent’anni quale sarà il corrispondete della scatola di cartone dove mia mamma tiene le foto di quand’era piccola?

Mi è piacuto molto anche il post di Tantek Çelik (uno dei pochi incentrato direttamente sulla questione dei dati), in cui riflette sul fatto che al momento il modo più sicuro per salvare i propri dati è ancora il testo ASCII, ma che è ora di trovare qualcosa di nuovo e più evoluto. La sua idea che XHTML e i microformati possano essere questo nuovo modo e garantire lo stesso grado di affidabilità del semplice testo è sicuramente interessante e ragionevolmente plausibile. É una soluzione limitata però al testo che, nonostante sia sicuramente il metodo più utilizzato per la trasmissione della conoscenza, non fa i conti con il fatto che musica e video, di nuovo grazie al “digital lifestyle”, se mi si passa il termine, e a nuove formule per la distribuzione della conoscenza, sono sempre più alla portata di tutti.

Torno quindi all’inizio: la riflessione di Mark, come il tema dell’incontro a cui ho partecipato ieri sera ha moltissime diramazioni e personalmente penso che la strada sia quella dell’apertura. Citando l’articolo di John Gruber, Record industry executives refuse to believe what is patently obvious to anyone with a clue — they are never ever going to regain complete control over the distribution of recorded music. Credo che questo non si applichi solo alla musica.

Choosing the Wrong Rule Number 1

micampe — Fri, 22 Apr 2005 04:11:00 -0700

I was reading through Textpattern support forum and found mention of a weird Rule Number 1 TXP developers are sticking to:

Rule Number 1: Never promise a release date.

I was going to reply directly in the forum, but then I figure this would be a better place.

The Rule Number One is so old-school development process.

Just look at Gnome, Fedora, Ubuntu or others that have adopted the “stable release every six months” policy, they are all healty projects, rapidly gaining traction and respect in the community and growing as stable, solid solutions.

Now look at Debian that instead still follows the rule number 1: nobody uses its stable version, wich is three years old now and many people are getting tired of the development version and are migrating to other distributions.

Well, I also think (and hope) everybody writing code for a living breaks that rule almost every day. You can’t say to your customer you’re going to release “when you’re done”. You say: “on 36 setnuary 2036 we will release a stable release” if by that date you have some feature which isn’t stable, you delay that single feature not the entire project.

A better Rule Number One could be for example ”release early, release often”.

By using this rule, you could avoid the problems Alex mentions to explain why Rule Number One is correct:

[…] The things left till last are likely to be intermittent bugs, issues that only occur on certain platform configurations, Heisenbugs, and all of the minor niggling problems that you’ve forgotten about. They are, by definition, elusive and unpredictable, and hence impossible to estimate.

Right. I totally agree, but my conclusion is different: just because those bugs are elusive and unpredictable, you can never fix them all, so just release, quickly fix them when they come up and release a bugfix.

This way everybody has the latest code without playing with the Subversion repository or other weird tricks, and third-party developers don’t need to worry about giving support to people installing their plugin in last week’s revision.

Michele Campeotto: Tag opensource

Il grande switch

Choosing the Wrong Rule Number 1