Tag - debian

Entries feed - Comments feed

Last entries

Tue 02 Feb 2016

"Software Aging"

In 1994, David L. Parnas published a provocative paper called "Software Aging". I recently read this paper and found it remarkably accurate!

Software is digital, so how could it age? Parnas identified two different causes for software getting "older" when time passes:

  • "Lack of Movement", i.e. the inability for the software to match evolving user or environment expectations. A computer environment evolves constantly; language and compiler changes, operating system and library changes. But this is also true for user expectations: in the 70' people expected a text interface, in the 90' a graphical interface and now they want a web interface accessible from any device or an App usable on their mobile devices;
  • "Ignorant Surgery", i.e. the inability to correctly adapt the software as time passes. When somebody modifies the software, probably not the original developer(s), she/he won't probably understand its design and probably modify it as she/he understand the software. At this point understanding the software means understanding the original design as well as the introduced new design. After several of such modifications, nobody can understand the software and in some cases it should be rewritten from scratch.

Although this idea of Software Aging was proposed 22 years ago (and appeared 47 years ago, the famous "Software Crisis", according to Parnas), it is striking to see that it is still true. When I see it takes nearly one year to make a new release of the Debian system, I view it at software aging at work: the environment evolves in unexpected ways and each software should be adapted to match its new environment. And sometimes, applying those changes can be very difficult and lead to Ignorant Surgery, like the famous Debian OpenSSL bug.

How to avoid this software decay? Parnas gives some advises, I just summarizes them here:

  1. Design for change, i.e. apply usual Software Engineering principles like Information Hiding, abstraction, separation of concerns, proper use of object orientation, etc.
  2. Document! Document your design, your choices and document for the people who'll come after you work on the software.
  3. Review! Review the design, code or other software artifacts by other members of your team, by experts in the domain on which your software is applying, etc.

Even for actual software, above principles can be applied, retro-actively. Parnas gives some advises.

All current software are aging. Hopefully, 22 years ago, Parnas gave some very good advises on how to develop and maintain software to limit this phenomenon. Listen to him, apply them.

Mon 25 Aug 2014

Améliorations des sauvegardes

J'ai récemment acheté un petit NAS pour faire mes sauvegardes en remplacement de mon vieux PC qui prenait une place folle et consommait comme une vache : un QNAP TS-112P. Plusieurs raisons pour ce choix:

  • un bon WAF (Wife (& husband! ;-) ) Acceptance Factor) car il est petit, joli et blanc ,
  • son aspect écologique, consommation de 7W seulement, peut-être un peu plus en fonction du disque dur, un Toshiba DT01ACA200 2 To,
  • et surtout un bon support Debian!

J'ai donc installé une Debian Wheezy 7.6 dessus en suivant les instructions de Martin Michlmayr pour les QNAP TS-11x/TS-12x (le TS-112P n'est pas officiellement listé, mais Martin m'a confirmé que cela marche sans problème). Grâce à un version récente de qcontrol, (quasiment) tout le matériel est pris en charge : les leds, la vitesse variable du ventilateur, etc.

J'ai ensuite installé BackupPC, mon logiciel de sauvegarde préféré. Et refait la configuration pour sauvegarder mon serveur sur Internet, un autre NAS et un PC Portable Windows.

Tout semble marcher correctement, on se sent plus tranquille avec une bonne sauvegarde. :-)

Sat 04 Jan 2014

Server upgrade to Wheezy: beware of Dovecot!

Yesterday I upgraded my Debian server from Debian 6 (Squeeze) to Debian 7 (Wheezy). Overall it went fairly well, most probably because I don't use that much software. Another reason is that two main packages I use, Nginx and PostgreSQL, were drawn from Squeeze backports so they were close to Wheezy version.

Having the important upgrade notes of all packages at the very beginning of the upgrade was very helpful.

I had nonetheless two big issues with Dovecot and PHP as CGI.


I had to upgrade from Dovecot 1.x to 2.0 configuration file. Dovecot 2 is supposed to be able to read Dovecot 1 configuration file but it did not work for me. First of all, I had to fix the import of the SSL certificates (easily done with help from README.Debian.gz). Secondly, I use non-standard ports and I was not able to easily fix it.

Overall, it was much easier to write a new Dovecot 2 configuration file from scratch. Using doveconf -c -n (also mentioned in README.Debian.gz) was very helpful to get the items to modify/add.

I don't see what Debian developers could have done better, the issue was at least well documented.


I am using Nginx web server so I had a custom init.d script to launch PHP as Fast CGI, Nginx and PHP communicating through a Unix socket. I don't know why but my PHP as CGI set-up was broken after the upgrade.

I easily fixed this issue by installing php5-fpm package and using the proper socket (/var/run/php5-fpm.sock) for the Nginx to PHP link. My server configuration is thus more standard and easy to maintain. Good! :-)

Feature wish for Debian 8

For next Debian, it would be useful to have a script that scans the installed packages and prints some notes telling if the upgrade can be done automatically or need manual intervention (and why, pointing to some further documentation to read). It would be very useful to know issues before starting the upgrade.

Sun 01 Dec 2013

The day I left GMail

On Saturday 2013-11-30 at 16:06 I left GMail. Now all (or at least most of them) of my emails are sent to my own email server based on Postfix, Dovecot and a Debian server.

It is increased burden to have to manage such a server. It was much easier for me to let Google administrators handle all the issues. But now at least I know where my emails are stored (in France) and how they are handled. I will less fear to see my Google GMail emails read by American spy agencies through PRISM program. Or at least, it will be a little more difficult for those agencies to access them. Hopefully, I won't have too many administration issues with this server.

Sun 26 May 2013

Issues with distributions, not only a Debian specific problem

Some time ago, I blamed Debian for not looking enough at its users. Apparently, I'm not the only one to make such remarks. Ingo Molnar, a famous Linux kernel developer working for Red Hat made similar remarks. He even proposed some technical solutions.

Other solutions are already available. For example, for OCaml specific software, OPAM, an OCaml specific package system, seems very interesting to work around the freshness issue of OCaml Debian packages.

I'm not sure Ingo's answers or OPAM are THE answers, but they at least open interesting perspectives. Handling of security and licensing issues are very difficult and not yet solved. Distributions are making an heavy work of integration that is currently not done by anybody else.

It is nonetheless refreshing to see people thinking at those issues and proposing new solutions. I find Ingo's proposal of sandboxing, flat dependencing and not forcing people to upgrade very interesting. If you read French, you can also read this LinuxFR article that makes a small review of current proposals.

Sun 27 Jan 2013

The failures of Debian (and its derivatives)

I am a long term Debian user. I have used Debian since probably the mid 90' up to now. I use latest Debian stable on my personal server or at work, and Ubuntu on my desktop and laptop machines at home. Using it does not mean I am entirely satisfied with it to say the least. I think the distribution is not making enough efforts for its users and I'll try to explain why. Of course, YYMV. ;-)

  • Debian packaging is made for developers, not users. Debian has too many packages. To take just one example, the OCaml compiler is packaged into the main compiler, its libraries, the native compiler and the byte code one, etc. Why so many packages? If I am an OCaml developer, I want all of them so why do I need to manually find (the naming is far from being obvious, at least for beginners) and install so many packages? I have heard of several reasons: it allows to factorise common parts between the different binary architectures, it allows to install the command line only parts without the graphics parts, it allows to install only what the user wants, etc. For me, those reasons are just plain wrong. We have more and more disk capacity on our machines so disk usage is no longer a limitation. The package should be able to dynamically activate the graphic parts automatically if the X server is available. And the factorisation of shared parts between Debian architectures should be done on the servers storing the packages, not trough the packaging system.
  • Debian has out-dated software. Debian Wheezy is about to be released and it will have GNOME 3.4. But GNOME 3.6 is already out and GNOME 3.8 is on its way. And I am taking GNOME as an example, it is the same issue for lot of software within Debian. I have heard this is for stability issues. But software packaged in Debian is already stable! It should take 10 or 15 days to integrate a new software into Debian stable, not months or even years (the time between successive stable releases). I acknowledge that some packages have complex interdependencies between each others. For example, when a new release of the OCaml compiler is out, one needs to recompile all OCaml packages. But this constraint is only for OCaml packages. Why should I wait for a new stable version of Debian to get the newly released OCaml compiler? For me this sounds just plain wrong.
  • Nobody uses plain Debian stable. Debian developers are using unstable. Debian users are using Debian stable, but enriched with backports because of out-dated software. Or derivatives like Ubuntu. The fact the Debian developers are not using what they recommend to users is bogus. I know they do that for technical reasons, but that should not be a good reason. Debian developers should use what they are providing to their users, except maybe for a few packages they are working on.
  • There are too many dependencies between packages. The dependency system of Debian is a nice piece of work, it was ahead of its time when it was created. But the use of dependencies has been perverted. The dependencies are manually computed (thus source of errors and bugs) and at the same time any software can write to about any part of the file system. Due to too many dependencies and lack of clean interfaces between sub-systems, the installation of a recent user software can trigger a ton of packages down to a new kernel or libc. Why is it so? I think the sub-systems of Debian (e.g. the X graphical infrastructure, the kernel and base C libraries, the OCaml system, ...) should be isolated the one from the others. It would allow them to be updated without waiting for the others. Having dependencies between 29,000 packages is just not scalable. It is even more true if those dependencies are manually computed.
  • Debian packaging is lacking automation. I am a developer. Debian packagers are developers. It always astonished me how much manual work should be done to make and maintain a Debian package. All developers know that if they want to be efficient, they need to automate their work as much as possible, so as to be able to focus their manpower on the complex parts. Everything should be automated in Debian packages, starting from a minimal description file. Automation should be the default (package creation, test, static analysis, ...), not the exception.
  • One cannot install simultaneously several versions of the same software. As a user or developer, I want to use the stable version of a piece of software and maybe the latest stable version that just have been released in order to do a few tests or check that my software still compiles with the new shiny compiler. Debian does not allow me to do that. And if I install a newer package, downgrading to the previous version is complex and error prone.
  • Debian is undocumented. I am not talking about the installation guide which is nice, I am talking about the modifications made to software by Debian developers. Doing modification on the "standard" (for the software) way of configuring or using it has always seemed suspect to me, even if I agree that having harmonized configuration is a real advantage (all configuration files in /etc for example). But all of those modifications should be documented in README.Debian file. To take an example, the last time I tried to install the dokuwiki Debian package, I was unable to configure it! The way to add new users had been changed compared to a regular dokuwiki (the web interface was disabled), and those changes were undocumented. It should be a release critical bug! Without proper documentation, the user cannot use the software. And, of course, the reason behind those changes should be questioned, even for security reasons (a very secure but unusable software is superfluous. Security is a trade-off).

So, why I am complaining? Why I do not become a Debian Developer, so I can fix it? Because a single developer is not going to change the root causes of those issues. They need a massive development effort, or at least a massive acknowledgement by the Debian Developers. And I don't have ready-made answers to those issues (even if I have some ideas to solve them).

Is the grass greener in the other fields? I don't think so, or at least I am not aware of it. I like Debian for is community approach, its focus on Free Software (even if it is sometimes imperfect) and the wide range of software packaged in it (the OCaml packages are numerous for example). I just hope that the whole Debian community will focus on more user related issues in the future.

How to install Atelier B 4.1 on a Debian-like 64 bits machine

Atelier B 4.1 has just been released. For Linux machines, it is available as a binary packages for 32 bits x86 machines in RPM and DEB format. Unfortunately the DEB package won't work on a Debian-like 64 bits machine, for example an Ubuntu. Here the approach have I used to install the package:

Install Atelier B 4.1 in /opt/atelierb-4.1

  • mkdir /tmp/ab
  • cd /tmp/ab
  • wget http://www.atelierb.eu/atelier-b/4.1/free/AtelierB-4.1.0-free-linux.deb
  • ar xv AtelierB-4.1.0-free-linux.deb
  • cd /
  • sudo tar zxf /tmp/ab/data.tar.gz
  • sudo chown -R YourUserID:YourGroup /opt/atelierb-4.1/ # substitute YourUserID and YourGroup with adequate values

Configure the execution environment on an Ubuntu 12.04

  • sudo apt-get install ia32-libs-multiarch

You can now start Atelier B with:

 /opt/atelierb-4.1/startAB &

The procedure might be different for another Debian-like distribution, including Debian itself. You can add specific procedures for a given distribution in the comments.

Présentation de l'analyse de valeur avec Frama-C

Lundi 18 au matin, je suis intervenu dans un cours de compilation de l'ESIR (anciennement DIIC) pour présenter le framework d'analyse statique Libre Frama-C et en particulier l'analyse de valeur. Les transparents en PDF, les sources au format propriétaire et les exemples sont disponibles dans ce répertoire.

Vous pouvez facilement tester les exemples, il n'y a qu'à installer le paquet frama-c dans une Debian ou une Ubuntu. Si vous comptez venir à ma présentation de lundi 31, ne regardez pas trop en détail, sinon ça manquera de surprises. ;-)

N'hésitez pas à me poser des questions si besoin.

Mon 29 Mar 2010

Status of OCaml packages on Ubuntu Lucid Lynx (10.04 LTS): transition to OCaml 3.11.2 finished

I don't know who are responsible for this but the OCaml packages of Ubuntu Lucid Lynx 10.04 LTS have all transitioned to OCaml 3.11.2 on main architectures (amd64 and i386). A big thank to the mysterious developer(s)! Even for secondary architectures, all packages have transitioned to 3.11.2 except 3 packages on armel: coq, ssreflect and why.

Of course, having a source OCaml package compiled with the correct version of the OCaml compiler does not make it automatically working so I encourage you to test your preferred Ubuntu OCaml packages in Lucid.

If we now compare the set of source packages available respectively on Debian Unstable and Ubuntu Lucid, the situation is not so perfect. On the 145 OCaml packages available in Unstable, 21 are not at the same stage in Lucid.

There are 5 packages simply not available in Ubuntu:

  • clang 2.6-3
  • llvm 2.6-8
  • llvm-snapshot 20100312-1
  • obrowser 1.1+dfsg-4
  • unison2.27.57 2.27.57-2

There are 11 packages that have been updated in Unstable but not upgraded in Lucid:

  • Package Unstable-version Lucid-Version
  • approx 4.2-1 4.1-1
  • camlpdf 0.5-1 0.4-4
  • coccinelle 0.2.2.deb-1 0.2.0.deb-1ubuntu2
  • graphviz 2.26.3-3 2.20.2-8ubuntu3
  • ocaml-csv 1.2.0-1 1.1.7-2
  • ocaml-ssl 0.4.4-1 0.4.3-3
  • ocaml-text 0.3-1 0.2-3
  • ocsigen 1.3.0-4 1.2.2-1
  • pgocaml 1.4-1 1.3-3
  • postgresql-ocaml 1.12.4-1 1.12.1-2
  • unison 2.32.52-1 2.27.57-2ubuntu2

And lastly there are 5 packages that had minor updates or packaging bug fix in Unstable but not in Lucid:

  • Package Unstable-version Lucid-Version
  • nurpawiki 1.2.3-4 1.2.3-3
  • frama-c 20090902+beryllium+dfsg-5 20090902+beryllium+dfsg-4
  • ocamlgraph 1.3+debian-2 1.3+debian-1
  • sks 1.1.1-2 1.1.1-1ubuntu2
  • ssreflect 1.2+dfsg-4 1.2+dfsg-3

I don't know what to do about those packages or if I can even do anything. According to Ubuntu Lucid release schedule, we are reaching Beta 2 Freeze (on April the 1st) where uploads for packages in main and restricted are held in the queue and are subject to manual approval of the release team.

Do you have any advice?

Beside that, we still have 124 OCaml source packages in good shape in Lucid!

Looking for a C software for Formal Verification

As you probably know, I'm a huge fan of Formal Methods: use appropriate Mathematics and tools to ensure a program is correct in all possible situations. In other words, bug free software... well, sort of. :-)

The interesting side of this is that tools to apply Formal Methods have improved a lot and most of them are now Free Software. I'm maintaining a list of Free Software tools for Formal Methods (it is a wiki, you can update it!).

I would like to make an experiment with Frama-C and its plugins, especially Jessie. Frama-C is a framework for static analysis of C programs developed at CEA. Combined with the Why and Alt-Ergo tools, you can prove some properties on real C code (absence of integer underflow or overflow, absence of out-of-bound accesses, absence of NULL pointer de-referencing, program's specific properties, etc.). All those tools are Free Software and are developed in OCaml. And they now are available in Debian and Ubuntu!

I made a simple experiment last year but I would like to make a more elaborated one.

Therefore, I'm looking for a piece of C code with following criteria:

  • Free Software: I'm interested in improving software for the whole humankind; ;-)
  • Pure C code, no C++. If there is some assembly, I could work around for example by re-writting corresponding C function;
  • Code of moderate size, a few thousands line at most. It could be a sub-module or subset of a bigger code;
  • Code using mostly integers and pointers, few strings (aka char *)[1];
  • Verifying some properties on this code would be "interesting". Several possible reasons: for security or safety reasons, because the code is used in an embedded platform on which modifications are difficult once in production or simply because this code is used a lot.

If you know some software that fills those criteria, let me know through a comment or at dmentre@linux-france.org!


[1] Frama-C is a bit slow to handle strings and it can become cumbersome.

page 1 / 3