POSSE è passato anche da Bologna

POSSE ovvero Professors' Open Source Software Experience è una sorta di linea guida per aiutare i professori universitari e, di riflesso, gli studenti ad avvicinarsi al mondo dell'Open Source. L'idea è abbastanza semplice: i professori devono arrivare ad insegnare agli studenti come collaborare in un progetto HFOSS (Humanitarian Free Open Source Software - software che abbia impatto sociale) attraverso l'apprendimento loro stessi degli strumenti e delle metodologie alla base della cultura Open Source.
POSSE si fonda su tre livelli, chiamati stage:

1. in questa fase preliminare si prende conoscenza con gli strumenti e le licenze, nonché si inizia a valutare obbiettivi semplici e raggiungibili sui quali far lavorare gli studenti;
   
2. in questa fase face-to-face si lavora tutti assieme in un workshop di due giorni per mostrare i risultati della fase 1, le esperienze, nonché valutare ed inserire obbiettivi di maggior impatto pratico per la fase successiva;
   
3. in questa fase l'applicazione ad un progetto Open Source dovrebbe trovare risvolto pratico e dare soddisfazione a studenti e docenti che, nel frattempo, sono diventati membri effettivi della comunità Open Source.
   

Pur non avendo mai partecipato ad uno schedule POSSE mi immagino che gli stage possano essere così schematizzati:

1. apprendimento di strumenti quali canali IRC, mailing list, revisione del codice, test;
   
2. condivisione di esperienze e modalità di insegnamento degli strumenti di cui alla fase precedente, nonché loro applicazione pratica nei corsi di laurea;
   
3. sviluppo di una o piu' patch per un progetto prescelto.
   

Francamente ritengo che i tempi per gli stage siano abbastanza lunghi, si parla ad esempio di 6 mesi per il solo stage 1!
Tuttavia occorre ricordare che si parla di didattica accademica, e quindi occorre anche avere il tempo di introdurre gli strumenti nel corso di laurea, e questo potrebbe spiegare la necessità di un simile periodo temporale.

Ma perché questa digressione su POSSE?

A Luglio si è svolto lo stage 2 dell'anno 2017 presso l'Università di Bologna, ma ahimé i partecipanti erano tutti stranieri e non leggo nessun nome italiano delle università limitrofe. Questa è secondo me una pessima notizia che dimostra ancora una volta l'arretratezza culturale alla quale sono sottoposti gli studenti delle università della mia zona.

Mi auguro che molti altri docenti e ricercatori italiani possano unirsi all'idea POSSE o a simili iniziative e possano mettere a frutto una maggiore esperienza nel mondo Open Source e nelle community ad esso collegate.

Pervasività dei linguaggi di programmazione: l'esempio di Python

Chi mi conosce sa che non mi interesso di Python.

Il linguaggio è sicuramente notevole, e secondo me ha alcuni punti di forza, in particolare la sintassi "blindata" che rimuove in partenza molte discussioni (chi pensa a style(9)?).

Ad ogni modo fa molto piacere vedere a che livello di pervasività tecnologica si sta giungendo, se addirittura Walt Disney sponsorizza pesantemente PyCon 2017! 

KDE @ school

Articolo molto interessante sull'adozione di KDE nelle scuole.
Come spiega l'articolo, al giorno d'oggi gli studenti non sono molto interessati all'interfaccia grafica che gli si presenta, basta che funzioni e gli permetta di essere connessi in modo veloce ed efficiente. Ma il risparmio per l'amministrazione può risultare importante.
Perché almeno le nostre università non prendono esempio?
Perché i professori, per primi, continuano a scrivere articoli con strumenti proprietari?

Josh Berkus lascia il core team di PostgreSQL

E' di ieri la notizia che Josh Berkus, uno dei membri del core-team di PostgreSQL, si dimette dal core team stesso, e in effetti come diretta e rapida conseguenza non appare piu' il suo nome nell'elenco dei contributor (si veda il suo annuncio ufficiale qui.

Ho avuto poche occasioni di vedere Josh dal vivo, e quello che mi ha sempre colpito è la sua capacità come speaker, oltre alle sue competenze tecniche dettate da una grande esperienza. Ma un'altra cosa mi ha sempre colpito: Josh si è sempre dimostrato (nelle sue apparizioni nonché nelle sue comunicazioni nelle varie mailing list) una persona corretta e aperta, in una sola parola mi ha sempre dato l'impressione di essere una persona "pura" per quanto riguarda il progetto stesso.

Questo perché, a differenza di altri membri del progetto, si sono viste anche reazioni molto piu' business-oriented e meno community-centric.

Ritengo che Josh abbia svolto un ruolo molto importante per l'advocacy e la qualità del progetto PostgreSQL e, anche se il team è composto da persone piu' che valide, penso sarà difficile rimpiazzare pienamente un simile personaggio.

Haiku: quando root non è root!

Sicuramente ero già inciampato in questa specificità, ma non la ricordavo, e un utente molto piu' devoto di me di questo sistema operativo mi ha riportato alla mente che in Haiku l'utente "user" è equivalente a "root".

Eclipse: un bell'esempio OpenSource da oltre 15 anni!

Eclipse è un pezzo fondamentale della storia di qualunque programmatore, non importa il linguaggio o il sistema operativo, non conosco nessun developer che non abbia mai provato almeno una volte questo IDE.

Certo, IDE è riduttivo, Eclipse segue la filosofia di tanti progetti ambiziosi (es. Emacs) di creare veri e propri ecosistemi estendibili da parte dell'utente (sviluppatore) e che possono essere utilizzati come base per applicazioni e sistemi complessi.

Io stesso ho usato nel tempo Eclipse come ambiente di sviluppo e piattaforma per la costruzione di alcune applicazioni.

A parte la mia storia personale con questo strumento, che forse è diventato un po' troppo complesso ed enorme, Eclipse festeggia un importante ricorrenza: sono ormai 15 anni che il codice sorgente è diventato di pubblico dominio.

In un periodo nel quale l'OpenSource sembra un po' "passato di moda" questo è un buon promemoria di come una politica Open Source sia tutt'altro che sorpassata o sorpassabile.

Mozilla logo contest

Mozilla sta pensando di cambiare logo e ha pubblicato una serie di proposte (e relative spiegazioni) qui.

Non voglio influenzare in alcun modo nessuno, quindi non pubblico qui la lista dei loghi, anche se non ne trovo uno che mi piaccia. Forse quello che mi mi dispiace meno è il protocol, ma secondo me non è necessario il cambio di logo. Dopotutto per me Mozilla è il dinosauro rosso dalla testa squadrata, e rimarrà sempre quello!

Respect the developers time and wills!

I believe there is a strong understimation of Open Source work today: people complains more and more everyday without taking into account that who does Open Source is donating her time and efforts to the whole community.

Having stated that, it is really simple, in my very own opinion, that developers have the rights to work on what make them happy, not on what will make the users' happy.

Most of the time, the two side of happiness coincide.

In this scenario, before expressing rage against a group of developers without providing help, it is better to remember that you, the final user, did not hire the developers themselves, and therefore they are free to ignore you.

For a pratical example, see here  and if you have a little respect for yourself, never reply like this!

A few ridicolous (to me) Perl requests

Usually I don't get personal on blogging and commenting: everyone is free to express herself on the net about pretty much any subject. And I'm not getting personal on this set of entries too, but I have to spend a few words on a Perl blogger that is requesting loudly for a set of shortcuts in the language that make no sense at all.

One is about the versioning of the Perl language: stating that Perl 6 is a different beast from Perl 5 is quite easy. But pretending to have different numbering of both versions is awkward. For external developers Perl 6 is the new version of the Perl language, and this is the thruth. The fact that Perl 6 has evolved as a more complex beast than a "simple language improvement" is another fact, but having to number them independently will cause a lot of confusion.

Another issue is about enabling use warnings; silently when specifying use 5.x;. While I understand that it would be much more easy to use a single line pragma, the author does not realize that there is a lot of legacy code that do not explicitly negates warnings since they were not enabled by default. And keeping backward compatibility is really important.

I don't want my programs to behave strangely just because a future version of Perl let me write simpler code: I just want to write simpler code in the future, without having to constantly refactor old code.

On the same mindset if the request to have package to return automatically a true value. Again, the point is valid and I believe in the future could be a reasonable way of programming, but it is not the right choice for legacy code. And moreover, it does not make sense at all when developers will use /package/ multiple times within the same file (because Perl is not Java, right?).

FreeBSD and Whatsapp

La FreeBSD Foundation ha ricevuto una grande donazione dal CEO di Whatsapp. Fa molto piacere vedere che le aziende stiano riconoscendo, sempre piu', il valore ai grandi progetti Open Source che hanno permesso il loro business.
E il mio personale invito è anche quello di valutare altri progetti, forse piu' detro le quinte, ma che movimentano molti piu' dati come OpenBSD (mai fatto un login ssh?).

Richard Stallman a Modena

Richard Stallman non ha certo bisogno di presentazioni.

Ne è convinta anche l'Università di Modena, presso la quale il prossimo 24 Novembre, Stallman terrà un discrso sulla libertà digitale.

Resto un po' deluso dal vedere come l'incontro di Stallman sia riportato da una misera nota sul portale universitario, con anche evidenti errori di battitura. Fra le altre cose, nemmeno un link all'evento ufficiale della FSF, che richiede anche una registrazione anonima (cosa non richiesta dal sito dell'università)...

OpenWebMail ?

OpenWebMail e' una piattaforma di email web.

Non e' particolare, ce ne sono tante come OpenWebMail. Non dispone di un calendario e di nessuno strumento evoluto per essere classificata come una vera applicazione PIM (Personal Information Management), e' una semplice e funzionale applicazione di posta elettronica.

Perche' allora parlare di OpenWebMail?

In passato sono stato costretto ad utilizzare questa interfaccia come client di posta per un'azienda. Ebbene, seppur di semplice e intuitivo utilizzo, OpenWebMail non viene piu' sviluppato attivamente da diverso tempo.

Eppure ci sono ancora aziende che utilizzano OpenWebMail come unico client di posta per i loro dipendenti, e quel che e' peggio, ci sono anche fornitori di servizi che forniscono installazioni di OpenWebMail beta in produzione!

Atom vs Emacs

Atom.io e' un nuovo editor di testo, in fase di sviluppo.

E' promettente: un editor totalmente personalizzabile da parte degli utenti che possono scrivere facilmente moduli ed estensioni per cambiarne il comportamento e l'aspetto.

Ok, ricorda qualcosa....se non fosse per il "semplicemente" direi che e' esattamente identico ad Emacs. Eccetto che Emacs puo' essere ancora piu' semplice!

A parte le battute dovute piu' che altro alla religione degli editor, Atom appare veramente un clone moderno di Emacs.

Non solo Emacs e' di fatto l'unico vero editor totalmente personalizzabile che io abbia mai visto e usato, ma alcune delle feature di Atom sono identiche a quelle di Emacs.

Ad esempio, il modulo  Zen fa esattamente quello che il mio Emacs fa con poche righe di codice lisp, e soprattutto senza dover installare una estensione.

La possibilita' di avere i suggerimenti sui nomi dei file da editare e' esattamente quello che fa il mio Emacs con IDO.

Sort Lines  fa esattamente quello che il comando sort fa, solo che Emacs permette di eseguire gia' tutti i comandi disponibili su un buffer o una regione, e quindi risulta ancora una volta vincente.

E come per Emacs, le estensioni si sprecano e portano fino ad esempi inutili come Editor Stats  (francamente mi interessa sapere di piu' cosa sto editando che sapere 'quanto').

Insomma, a parte per la tecnologia utilizzata e per il fatto che la struttura di Atom mi appare maggiormente a "micro-kernel", direi che di differenze significative con Emacs non ce ne sono.

E questa mi sembra una bella vittoria per Emacs, precursore di molte idee riprese poi negli IDE e negli ambienti moderni.

Non mi e' ancora chiaro se Atom potra' funzionare anche in console e quindi via terminale remoto, cosa che Emacs svolge egregiamente (anzi, Emacs puo' lavorare in modalita' client-server e anche come wrapper di terminale).

Ma sicuramente una cosa e' chiara: Emacs ha una licenza piu' conveniente che quella di Atom.

On bug and bug reporting

A quite well established mindset with Open Source projects is that as much users a code base has, as much it will be tested and, therefore, will produce a continuosly growing quality product.

And it is true, indeed!

But what does it mean to test an Open Source project? Disregarding the low level testing with test suites, it means that true users will install, run and report back application misbehaviors, crashes, problems, and so on. And this is the point of this post: reporting back information to developers so that they could do their work and improve the software. I'm not focusing on how to write a good bug report, you can find a lot of information about in the net and in the project documentation itself. But have you ever thought about the importance to report as less information as possible to allow a developer to do her job? I mean: what do you think a developer will feel like opening the bug tracking system on the Monday morning and finding out tons of bug reports? Therefore, before posting a bug report, please ensure that none before you has openend the same report, and in case append to such report. You will achieve the goal of making the developer feel better and, most notably, to avoid wasting her time in reading just another report that reports the already known problem.

And if you have time, please provide a clear and short way to reproduce the bug, even if you are not the first reporter. Even better, write an automated test for the bug you are interested in: you will grant the developer some extra time to concentrate on the real bug instead of the aside artifacts.

And about testing allow me to spend some extra words: while it is very important to test the produced code, please consider that techniques such as Test Driven Development TDD not only promote the creation of tests ahead the code that implements a feature, but also that a feature should be requested due to a failed test.

In other word, if you want to add feature X to the project Y provide a short and clear test along with the feature request.

Why?

Because again, you are going to give the developer(s) some extra time and will help her better understanding what is your will. And most notably, while writing the test you will become a concrete part of the development and will better think about what you are asking (and why you are needing it). In other words: you will only ask something you can clearly explain and with as less as possible misunderstandings, while the developer(s) will have a concrete case to start developing on.

Fianlly, again on testing, please spend some time reviewing and providing new test cases for existing code, even if you don't have a feature request or a bug to work on.

Why?

Because Open Source developers often, or better almost always, do the hard work on their spare time, and will regret to implement some new code until they do not risk public embarassment. Therefore, if the code base has a strong and reliable test case, developers will be more likely to implement more code without having to worry about awkaward bugs.

Vari linguaggi di programmazioen a confronto

Vi ricordate le pubblicità della Apple per lanciare il Mac? Beh, che abbiano fatto moda si sa, e quindi ecco l'ennesimo risultato: la comparazione dei linguaggi di programmazione! Ma ne manca uno particolare...anzi particolarmente importante, chissà perché....

KDE at work

E' stato pubblicato un interessante post sul planet di KDE che mostra alcuni screenshot del favoloso desktop Unix in azione in ambienti di produzione. Si tratta in particolare di due aziende che realizzano effetti speciali per film e serie televisive: Framestore e di The Mill.

Mostrare questi utilizzi del desktop del drago e' importante al fine di rendere ancora piu' esplicito il livello qualitativo del software OpenSource e del Plasma Workspace.

What do you think about Apple?

Chi mi conosce sa che non sono un fan della Apple, per svariati motivi che prima o poi elencherò. Nel frattempo penso sia interessante sentire cosa ne pensa Larry Wall, inventore di Perl circa Apple e i brevetti sul software.

Bug = $$ ?

Ogni tanto salta sempre fuori, nei progetti OpenSource, l'idea del sostentamento tramite bug bounty.

L'idea e' semplice, e spesso anche molto redditizia sia in termini monetari che di qualita' del codice: qualche investitore, solitamente una grossa azienda che usa il progetto in questione, si propone per versare un bounty (ossia una ricompensa) per ogni bug individuato e corretto nella codebase.

Sembra una buona idea, e in effetti lo e', ma non se il bounty serve a sostenere il progetto. In altre parole la caccia al bug (e alla ricompensa) ha senso solo se viene svolta da persone esterne al progetto.

Si immagini di usare il progetto OpenSource X, e che questo dica chiaramente che intende auto-sostenersi tramite le donazioni fatte dallo sponsor Y per ogni bug trovato nel codice. Che pubblicita' ne ricava X? Che piu' bug ci sono e piu' il progetto acquisisce moneta? E quindi puo' pagare piu' sviluppatori (o pagare meglio quelli che ha), andando quindi a ridurre i bug e quindi i soldi a disposizione? Il progetto X dovrebbe gia' fornire codice libero da bug, o impegnarsi a fondo in quello. Nessuno vuole prendere una code base piena di bug e pagare per rimuoverli.

Discorso diverso se la caccia al bug avviene da fuori al progetto: in questo caso si aumenta veramente la qualita' del codice poiche' si usano risorse esterne e quindi con una visione distaccata e capaci, se presenti, di scovare bug che il team non e' stato in grado di trovare.

Ma se il team del progetto X, che si pone come scopo quello di fornire un codice con meno bug possibili, si auto-finanzia con una caccia al bug, allora chi garantisce che qualche bug non sia stato introdotto per sopperire ad una carenza monetaria?

Insomma, i soldi sono importanti, ma lo e' molto di piu' l'etica del progetto!

If Linux did not existed...

Paul Venezia published an interesting article  where he

analyzes what the history of FLOSS could have been without Linux.

Whilte it is worth reading this article, I have to say that it seems to me the conclusions are quite trivial. In particular, assuming Linux never existed, the article states that all the hackers and developers in the world would have been part of the BSD movement. From this, the natural and easy conclusion is that the BSD operating system family would have been much more advanced than what is today.

Well, I don't agree with the article, and it seems to me this is a quite shallow conclusion. One key point of the Open Source movement is the ability to "fork", that is to create another project on the shoulder of an existing one. Having said that, and considering that, as the author states, Linux developers have reinvented the wheel in the beginning, what would have prevented such developers to fork or even start over and get a new project from scratch?

License is another issue that, in my opinion, invalidates the article conclusions: Linux has been released as a GNU project, while the BSD operating system family is, well of course, BSD license. License is religious aspects to many developers, and therefore I assume that many of them would have never chosen a BSD project, again pushing a fork/scratch with another license.

What about the different BSD distros? I believe all of them would have been existed anyway. After all NetBSD was founded when 386BSD was already running, and OpenBSD was founded from NetBSD controversy, and therefore none of these includes a specific Linux-related issue. Other BSD distros, like PCBSD or FreeNAS and the others would have been the same history as of today.

In the industry marketplace I believe some differences would have been generated: today the market is split between the Linux embedded systems and the (Free)BSD ones. As an example, Apple has based OSX on FreeBSD userland and BSD kernel, while Sony and others are basing their multimedia products on Linux. Since Linux has gained a very strong momentum, the hardware support is better than in other BSD systems, and I'm referring to consumer and commodity hardware, not server and high end devices. Therefore, the choice today is about hardware support, and this leads many vendors to choose Linux instead of a BSD system, even if this could break the license (think about the TiVo). If Linux had never ever existed I believe that hardware support for BSD based system would have been better because vendors would not have been any choice of supporting this kind of platform.

A final note is about numbers: many Linux distributions have a lot of people devoted to quality control, source code management, community and advocacy management, and, of course, development and packaging. BSDs have a lot less people available and this is, in my opinion, a big difference: BSDs systems can assure the today's high quality thanks to ability to keep their staff under control. If Linux never existed and a lot of more developers and members would have joined BSDs projects, would have been the quality be the same of today's? I don't think so, and therefore my final conclusion is that if Linux never existed something in the world would have been happened to create a very similar ecosystem.

Source Code & Films

Ho trovato per caso un interessante sito che riporta diversi esempi (ben documentati) delle apparizioni di codice sorgente nei film piu' svariati. Penso che l'idea di chi usa tale codice sorgente sia quella di rendere il film piu' realistico senza dover fare la fatica di inventare qualcosa che assomiglia a del codice sorgente.

Ovviamente non puo' che trattarsi di codice Open Source!