I'm Zack, and this is my blog. Have a look at the most recent posts below, or browse the tag cloud here on the right.
Archives are available as well.
- 2014:        
- 2013:        
- 2012:            
- 2011:          
- 2010:            
- 2009:            
- 2008:            
- 2007:            
- 2006:    
You can leave comments on my posts by following the relevant link associated to each post. You can also mail me comments; note that unless otherwise requested, I will add mailed comments in the comment feeds.
on perceived hysteria and silent sanity
As you probably already know by now, the results of the Debian init system coupling general resolution (GR) look like this:
Some random thoughts about them:
The turnout has been the highest since 2010 DPL elections and the 2nd highest among all GRs (!= DPL elections) ever. The highest among all GRs dates back to 2004 and was about dropping
non-free. In absolute terms this vote scores even better: it is the GR with the highest number of voters ever.
Clearly there was a lot of interest within the project about this vote. The results appear to be as representative of the views of project members as we have been able to get in the second half of Debian history.
There is a total ordering of options (which is not always the case with our voting system). Starting with the winning option, each option in the results beats every subsequent option. The winning option ("General resolution is not required") beats the runner-up ("Support for other init systems is recommended, i.e., "you SHOULD NOT require a specific init") by a large margin: 100 votes, ~20.7% of the voters. The winning options wins over further options by increasingly large margins: 173 votes (~35.8%) against "Packages may require specific init systems if maintainers decide" (the MAY option); 176 (~36.4%) against "Packages may not require a specific init system" (the MUST NOT option); 263 (~54.5%) against "Further discussion" (the "let's keep on flaming" option).
While judging from Debian mailing lists and news sites you might have gotten the impression that the project was evenly split on init system matters, at least w.r.t. the matter on the ballot that doesn't seem to be the case.
The winning option is not as crazy as its label might imply (voting to declare that the vote was not required? WTH?). What the winning option actually says is more articulated than that; quoting from the ballot (highlight mine):
Regarding the subject of this ballot, the Project affirms that the procedures for decision making and conflict resolution are working adequately and thus a General Resolution is not required.
With this GR the Debian Project affirms that the procedures we have used to decide the default init system for Jessie and to arbitrate the ensuing conflicts are just fine. People might flame and troll
debian-develas much as they want (actually, I'm pretty sure we would all like them to stop, but that matter wasn't on the ballot so you'll have to take my word for it). People might write blog posts and make headlines corroborating the impression that Debian is still being torn apart by ongoing init system battles. But this vote says instead that the large majority of project members thinks our decision making and conflict-arbitration procedures, which most prominently include the Debian Technical Committee, have served use "adequately" well over the past troubled months.
That of course doesn't mean that everyone in Debian is happy about every single recent decision, otherwise we wouldn't have had this GR in the first place. But it does mean that we consider our procedures good enough to (a) avoid getting in their way with a project-wide vote, and (b) keep on trusting them for the foreseeable future.
[ It is not the main focus of this post, but if you care specifically about the implications of this GR on systemd adoption in Debian, I recommend reading this excellent GR commentary by Russ Allbery. ]
My take home message is that we are experiencing a huge gap between the public perception of the state of Debian (both from within and from without the project) and the actual beliefs of the silent majority of people that make Debian with their work, day after day.
In part this is old news. The most "senior" members of the project will remember that the topic of "vocal minorities vs silent majority" was a recurrent one in Debian 10+ years ago, when flames were periodically ravaging the project. Since then Debian has grown a lot though, and we are now part of a much larger and varied ecosystem. We are now at a scale at which there are plenty of FOSS "mass-media" covering daily what happens in Debian, inducing feedback loops with our own perception of ourselves which we do not fully grok yet. This is a new factor in the perception gap. This situation is not intrinsically bad, nor there is blame to assign here: after all influential bloggers, news sites, etc., just do their job. And their attention also testifies of the huge interest that there is around Debian and our choices.
But we still need to adapt and learn to take perceived hysteria with a pinch (or two) of salt. It might just be time for our decennial check-up. Time to remind ourselves that our ways of doing things might in fact still be much more sane than sometimes we tend to believe.
We went on 10+ years ago, after monumental flames. It looks like we are now ready to move on again, putting The Era of the Great systemd Histeria™ behind us.
Jingjie Jiang selected as OPW intern for Debsources
I'm glad to announce that Jingjie Jiang, AKA sophiejjj, has been selected as intern to work on Debsources as part of the FOSS Outreach Program (formerly known as Outreach Program for Women, or OPW). I'll co-mentor her work together with Matthieu Caneill.
I've just added sophiejjj's blog to Planet Debian, so you will soon hear about her work in the Debian blogosphere.
I've been impressed by the interest that the Debsources proposal in this round of OPW has spawned. Together with Matthieu I have interacted with more than a dozen OPW applicants. Many of them have contributed useful patches during the application period, and those patches have been in production at http://sources.debian.net since quite a while now (see the commit log for details). A special mention goes to Akshita Jha, who has shown a lot of determination in tackling both simple and complex issues affecting Debsources. I hope there will be other chances to work with her in the future.
OPW internship will begin December 9th, fasten your seat belts for a boost in Debsources development!
Debian participation in Italy's CAD68 committee
(The initial policy change discussed in this document is a couple of years old now, but it took about the same time to be fully implemented, and AFAIK the role Debian played in it has not been documented yet.)
In October 2012 the Italian government, led at the time by Mario Monti, did something rather innovative, at least for a country that is not usually ahead of its time in the area of information technology legislation. They decided to change the main law (the "CAD", for Codice dell'Amministrazione Digitale) that regulates the acquisition of software at all levels of the public administration (PA), giving an explicit preference to the acquisition of Free Software.
The new formulation of article 68 of the CAD first lists some macro criteria (e.g., TCO, adherence to open standards, security support, etc.) that public administrations in Italy shall use as ranking criteria in software-related calls for tenders. Then, and this is the most important part, the article affirms that the acquisition of proprietary software solutions is permitted only if it is impossible to choose Free Software solutions instead; or, alternatively, to choose software solutions that have already being acquired (and paid for) by the PA in the past, reusing preexisting software. The combined effect of these two provisions is that all new software acquisitions by PAs in Italy will be Free Software, unless it is motivated—in writing, challengable by a judge—that it was impossible to do otherwise. Isn't it great?
It is, except that such a law is not necessarily easy to adhere to in practice, especially for small public administrations (e.g., municipalities of a few hundred people, not uncommon in Italy) which might have very little clue about software in general, and even less so about Free Software. This is why the government also tasked the relevant Italian agency to provide guidelines on how to choose software in a way that conforms with the new formulation of article 68. The agency decided to form a committee to work on the guidelines (because you always need a committee, right? ).
To my surprise, the call for participation to be part of the
committee explicitly listed representatives of Free Software
communities as privileged software stakeholders that they wanted to
have on the committee—kudos to the agency for that. (The
Italian wording on the call was:
Costituirà titolo di preferenza
rivestire un ruolo di […] referenti di community del software a
codice sorgente aperto.) Therefore, after various prods
by fellow European Free Software activists that were aware of the
ongoing change in legislation, I applied to be a volunteer CAD68
committee member, got selected, and ended up working over a period
of about 6 months (March-September 2013) to help the agency writing
the new software acquisition guidelines.
Logistically, it hasn't been entirely trivial, as the default meeting place was in Rome, I live in Paris, and the agency didn't really have a travel budget for committee members. That's why I've sought sponsorship from Debian, offering to represent Debian views within the committee; Lucas kindly agreed to my request. So what did I do on behalf of Debian as a committee member during those months?
Most of my job has been some sort of consulting on how community-driven Free Software projects—like Debian—work, on how the software they produce can be relied upon and contributed to, and more generally on how the PA can productively interact with such projects. In particular, I've been happy to work on the related work section of the guidelines, ensuring they point to relevant documents such as the French government guidelines on how to adopt Free Software (AKA circulaire Ayrault). I've also drafted the guidelines section on Free Software directories, ensuring that important resources such as FSF's Free Software Directory are listed as starting points for PAs that looking for software solutions for specific needs.
Another part of my job has been ensuring that the guidelines do not end up betraying the principle of Free Software preference that is embodied in article 68. A majority of committee members came from a Free Software background, so that might not seem a difficult goal to accomplish. But it is important to notice that: (a) the final editor of the guidelines is the agency itself, not the committee, so having a "pro-Free Software" majority within the committee doesn't mean much per se; and (b) lobbying from the "pro-proprietary software" camp did happen, as it is entirely natural in these cases. In this respect I'm happy with the result: I do believe that the software selection process recommended by the guidelines, finally published in January 2014, upholds the Free Software preference principle of article 68. I credit both the agency and the non-ambiguity of the law (on this specific point) for that result.
All in all, this has been a positive experience for me. It has reaffirmed my belief that Debian is a respected, non-partisan political actor of the wider software/ICT ecosystem. This experience has also given me a chance to be part of country-level policy-making, which has been very instructive on how and why good ideas might take a while to come into effect and influence citizen lives. Speaking of which, I'm now looking forward to the first alleged violations of article 68 in Italy, and how they will be dealt with.
Abundant popcorn will certainly be needed.
Links & press
If you want to know more about this topic, I've collected below links to resources that have documented, in various languages, the publication of the CAD68 guidelines.
- official material:
- press releases:
- press/blog coverage:
- on Joinup (en), European Commission blog dedicated to Free Software adoption in Europe, with comments by yours truly and Carlo Piana
- on OpenSource.com (en), popular blog for FOSS-related topics
- by Carlo Piana (it), fellow member of the CAD68 committee, representing KDE and FSFE
- on Punto Informatico (it), popular Italian tech blog
- on Apogeo online (it), blog of a popular Italian publisher of IT books
- on Agenda Digitale EU (it), blog dedicated to digital innovation in the Italian PA
- by Simone Aliprandi (en), lawyer who followed closely the work of CAD68 committee
je.code(); — promoting programming (in French)
jecode.org is a nice initiative by, among others, my fellow Debian developer and university professor Martin Quinson. The goal of jecode.org is to raise awareness about the importance of learning the basics of programming, for everyone in modern societies. jecode.org targets specifically francophone children (hence the name, for "I code").
I've been happy to contribute to the initiative with my thoughts on why learning to program is so important today, joining the happy bunch of "codeurs" on the web site. If you read French, you can find them reposted below. If you also write French, you might want to contribute your thoughts on the matter. How? By forking the project of course!
Pourquoi codes-tu ?
Tout d'abord, je code parce que c'est une activité passionnante, drôle, et qui permet de prouver le plaisir de créer.
Deuxièmement, je code pour automatiser les taches répétitives qui peuvent rendre pénibles nos vies numériques. Un ordinateur est conçu exactement pour cela: libérer les êtres humains des taches stupides, pour leur permettre de se concentrer sur les taches qui ont besoin de l'intelligence humaine pour être résolues.
Mais je code aussi pour le pur plaisir du hacking, i.e., trouver des utilisations originelles et inattendues pour des logiciels existants.
Comment as-tu appris ?
Complètement au hasard, quand j'étais gamin. À 7 ou 8 ans, je suis tombé dans la bibliothèque municipale de mon petit village, sur un livre qui enseignait à programmer en BASIC à travers la métaphore du jeu de l'oie. À partir de ce jour j'ai utilisé le Commodore 64 de mon père beaucoup plus pour programmer que pour les jeux vidéo: coder est tellement plus drôle!
Plus tard, au lycée, j'ai pu apprécier la programmation structurée et les avantages énormes qu'elle apporte par rapport aux GO TO du BASIC et je suis devenu un accro du Pascal. Le reste est venu avec l'université et la découverte du Logiciel Libre: la caverne d'Ali Baba du codeur curieux.
Quel est ton langage préféré ?
J'ai plusieurs langages préférés.
J'aime Python pour son minimalisme syntactique, sa communauté vaste et bien organisée, et pour l'abondance des outils et ressources dont il dispose. J'utilise Python pour le développement d'infrastructures (souvent équipées d'interfaces Web) de taille moyenne/grande, surtout si j'ai envie des créer une communauté de contributeurs autour du logiciel.
J'aime OCaml pour son système de types et sa capacité de capturer les bonnes propriétés des applications complexes. Cela permet au compilateur d'aider énormément les développeur à éviter des erreurs de codage comme de conception.
J'utilise aussi beaucoup Perl et le shell script (principalement Bash) pour l'automatisation des taches: la capacité de ces langages de connecter d'autres applications est encore inégalée.
Pourquoi chacun devrait-il apprendre à programmer ou être initié ?
On est de plus en plus dépendants des logiciels. Quand on utilise une lave-vaisselle, on conduit une voiture, on est soigné dans un hôpital, quand on communique sur un réseau social, ou on surfe le Web, nos activités sont constamment exécutées par des logiciels. Celui qui contrôle ces logiciels contrôle nos vies.
Comme citoyens d'un monde qui est de plus en plus numérique, pour ne pas devenir des esclaves 2.0, nous devons prétendre le contrôle sur le logiciel qui nous entoure. Pour y parvenir, le Logiciel Libre---qui nous permet d'utiliser, étudier, modifier, reproduire le logiciel sans restrictions---est un ingrédient indispensable. Aussi bien qu'une vaste diffusion des compétences en programmation: chaque bit de connaissance dans ce domaine nous rende tous plus libres.
Vale più il dolce o la ricetta?
Sul numero 21 del mensile BBC Science Italia, in edicola questo (in Italia) questo Ottobre, Alberto Agliotti ha scritto un bel pezzo divulgativo sul software libero a tutto tondo. Tra gli intervistati per l'articolo anche Angelo Raffaele Meo ed il vostro affezionatissimo.
Il PDF dell'articolo è disponibile anche qua.
debsources debbugs oh
I've migrated bug reports from the previous ad-hoc text file in the Git repo to the Debian BTS, under the umbrella of the
From now on this is the recommended (and documented) way of reporting bugs against http://sources.debian.net.
Look ma, it also has one of those newfangled short URLs: http://deb.li/debsrcbugs!
While at it, I've also properly tagged the current easy hacks on Debsources using the gift tag. There are definitely opportunities for new contributors there, and there might be more if you submit your own Debsources' pet peeves to the BTS.
Again, mandatory mnemonic/short URL: http://deb.li/debsrceasy.
What's your excuse for not contributing to Debsources, again?
my setup, take #1
Among the various things I've catched up with during the summer, I've finally managed to set aside some time to answer a pending interview request for The [GNU/]Linux Setup: a blog run by Steven Ovadia that collects interviews about how people use GNU/Linux-based desktops.
In the interview I discuss my day to day work-flow, from GNOME Shell to Mutt, from Emacs to Notmuch, and the various glue code tools I've written for integrating them.
Feedback is most welcome.
Debsources now has a HACKING file
After the talk, various DebConf participants have approached me and started hacking on Debsources, which is awesome! As a result of their work, new shiny features will probably be announced shortly. Stay tuned.
When discussing with new contributors (hi Luciano, Raphael!), though, it quickly became clear that getting started with Debsources hacking wasn't particularly easy. In particular, doing a local deployment for testing purposes might be intimidating, due to the need of having a (partial) source mirror and whatnot. To fix that, I have now written a HACKING file for Debsources, which you can find at top-level in the Git repo.
Happy Debsources hacking!
Debsources: Live and Historical Views on Macro-Level Software Evolution
The paper entitled Debsources: Live and Historical Views on Macro-Level Software Evolution, which I've co-authored with Matthieu Caneill, has been accepted at ESEM 2014: the 8th international symposium on Emprical Software Engineering and Measurement.
In the paper we have described Debsources as a software platform for monitoring the evolution of Free Software through the lenses of Debian, and used the main Debsources instance (http://sources.debian.net) to replicate and extend a former study on macro-level software evolution.
Now we "just" have to integrate all the nice charts and data we
have extracted for the paper into Debsources' stats page...
moar, and moar, and moar debsources stats
A while ago I've announced the availability of several stats about Debian source code on http://sources.debian.net. Since then the statistical basis of those stats has increased a lot, and now includes all Debian historical releases, from hamm (July 1998) onward. This allows to appreciate macro-level evolution trends in Free Software, over a period of more than 15 years, through the eyes of a distro that sits at the nice intersection of the eldest, largest, and most reputed distros.
To get there I've added support for sticky suites to the plumbing layer of debsources, and then injected historical releases from http://archive.debian.org. The injection process took about a week (without any sort of parallelism, pretty slow disks, and computing sha256 checksums, ctags, and sloccount on all source files) and has been an "interesting" experience.
When you go back decades in technology time, bit
rot is just around the corner, and I've found my
sources.d.n. In both cases the respective maintainers
(Guillem and Ganneff, kudos) have been positive about and helpful
in improving the situation, despite the low impact of the bugs I've
found on the average user. That's quite important for the
long-term preservation of digital information in
general, and for the perennity of access to Free Software in the
specific case of Debian.
While we are it, I'm now maintaining a list of
sources.d.n but belonging to other
packages, in case you fancy helping out but are not a Python
hacker. Interestingly enough, quite a bit of those bugs are related
to the fact that tools debsources uses (e.g. ctags, sloccount) are
also starting to show their age.
You might wander why buzz, rex, and bo are still missing from
sources.d.n. That's in fact for similar reasons.
Before hamm Debian didn't have complete archive coverage in terms
Sources indexes and
.dsc files. Given
that debsources rely on both to extract source packages, it first
needs to grow an additional abstraction layer that can cope with
their absence. It's SMOP, and planned.
And now let's have fun with ctags bombs.
Stefano “Indiana” Zacchiroli
See the archives for previous posts.