According to the Free Software Foundation, the Debian distribution is not a Free System Distribution. While I, as a Debian Developer, disagree with that point of view, it should be obvious that the opinion of an organization that engages in politics (or, at the very least, in political lobbying) and of which I am not a member should not be my concern. However, it has long irked me the wrong way that these claims exist.

A few weeks ago, I found the System distribution commitments page on Wikipedia. This does change the situation somewhat; I cannot say that a page explaining an opinion of the FSF is wrong; but if that opinion is copied nearly verbatim to a website which claims neutrality as one of its "Core content policies", then the situation is significantly different.

When I originally found that page, it was immediately obvious where the content came from, but there was no reference listed, so I added a "citation needed" tag, the first time I ever did so on Wikipedia.

Now, a few weeks later, a reference has been added, and the "citation needed" tag removed. However, as expected, the only reference which has been added is the highly opinionated document on the FSF's website, which is hardly neutral.

I've added another tag (this time a "which" tag, asking for more clarification) and added a Talk page listing my concerns with the article. But I can't really explain in Wikipedia why I think the whole premise is wrong; that's what a blog is for.

So, here goes.

The FSF lists two reasons why they do not endorse Debian:

1. The non-free and contrib repositories
2. An unsubstantiated claim that "the installer in some cases recommends [...] non-free firmware files for the peripherals on the machine."

Let's have a look at them, each in turn.

Non-free and contrib

It is true that Debian provides non-free software in separate repositories, and that software in these repositories does not comply with either the Debian Free Software Guidelines (DFSG) or the FSF's Free Software Definition. However, the non-free and contrib repositories are fairly small:

wouter@carillon:/var/lib/apt/lists$ awk -F':' 'BEGIN{total=0}/^Size/{total+=$2}END{print total}' ftp.be.debian.org_debian_dists_sid_non-free_binary-amd64_Packages
4398812934

That is, the non-free repository contains just over 4G of software (after installation). Contrib is even smaller:

wouter@carillon:/var/lib/apt/lists$ awk -F':' 'BEGIN{total=0}/^Size/{total+=$2}END{print total}' ftp.be.debian.org_debian_dists_sid_contrib_binary-amd64_Packages 
306578636

While, combined, this is approximately the same size as some other distributions, free and non-free together, it pales in comparison with the "main" repository:

wouter@carillon:/var/lib/apt/lists$ awk -F':' 'BEGIN{total=0}/^Size/{total+=$2}END{print total}' ftp.be.debian.org_debian_dists_sid_main_binary-amd64_Packages
60025033622

i.e., the "main" repository contains just shy of 60G of software.

Of course, whether non-free is large or not should not matter at all; the fact that it exists in the first place is a problem for free software advocates. But of those 4 gigabytes, what exactly is the non-free repository used for?

For that, the Debian popularity contest has a page specifically for the non-free section. Looking at this page, and ignoring the packages that are listed as "Not in sid" (which either means they were installed from third-party suppliers and therefore cannot be attributed to Debian, or were only available in older distributions so should not be held against the Debian of today anymore), we see three main uses of non-free:

1. Various implementations of non-free algorithms (unrar, libfaac0, etc)
2. A lot of packages containing non-free firmware
3. A number of packages containing non-free documentation

The first package which does not fit any of those descriptions is iozone3, currently on the 64th position of the popularity contest (including packages "Not in sid").

The first item in this list is something which most free software advocates will try to avoid. After all, for all of those algorithms, alternatives exist, and so there is no real reason why one would want to use such software, other than "someone sent me a file encoded according to that algorithm, and I want to decode it". Debian gives you the option to do so, but a valid case could be made for not doing so.

The second item in that list is really an alternate version of "the installer recommends non-free software", so I'll come back on that in the next section.

The 3rd item in the above list deserves some special attention. Just over 10 years ago, Debian clarified its position where it clearly specified that documentation and programs (as both are interpreted as "software") should follow the same set of guidelines regarding freedom. The FSF disagrees with this position, and chose to release some of its documentation under the GFDL with invariant sections, which Debian decided is a non-free license in 2006. Since then, such GNU documentation would no longer be available were Debian to ditch the non-free repository.

Recommending non-free firmware

As I said above, the FSF's page claims that the Debian installer recommends non-free firmware "in some cases", without going into much detail. Special care should be taken in understanding the word "recommend" here; wiktionary defines it as follows:

recommend (third-person singular simple present recommends, present participle recommending, simple past and past participle recommended)

1. (transitive) To bestow commendation on; to represent favourably; to suggest, endorse or encourage as an appropriate choice.

The board recommends Philips, given his ample experience in similar positions.

1. (transitive) To make acceptable; to attract favor to.

2. (transitive) To advise, propose, counsel favorably

The therapist recommends resting the mind and exercising the body.

1. (transitive, archaic) To commit, confide to another's care, confidence or acceptance, with favoring representations

A medieval oblate's parents recommended the boy for life to God and the monastery

However, according to the FSF, merely showing a firmware filename in unencrypted form counts as a recommendation. I've always found that use of the word "recommendation" to be dubious, at best.

Ignoring that part, we can make the following observations:

The debian-installer module ("udeb") which is responsible for configuring apt is called apt-mirror-setup (code in the apt-setup git repository). The actual debconf templates which allow the user to enable the non-free or contrib repositories are the apt-setup/non-free and apt-setup/contrib templates, and they look like this:

Template: apt-setup/non-free
Type: boolean
Default: false
# :sl1:
_Description: Use non-free software?
 Some non-free software has been made to work with Debian. Though this
 software is not at all a part of Debian, standard Debian tools can be used
 to install it. This software has varying licenses which may prevent you
 from using, modifying, or sharing it.
 .
 Please choose whether you want to have it available anyway.

Template: apt-setup/contrib
Type: boolean
Default: false
# :sl1:
_Description: Use contrib software?
 Some additional software has been made to work with Debian. Though this
 software is free, it depends on non-free software for its operation. This
 software is not a part of Debian, but standard Debian tools can be
 used to install it.
 .
 Please choose whether you want this software to be made available to you.

Note the lines Default: false, which imply that the default answer to these questions is to disable the non-free and contrib repositories. A question which defaults to false isn't a recommendation, nor do I read the text as any form of recommendation to install these repositories (quite the contrary, in fact).

More important than whether the default is to enable or disable these repositories is whether this question is even shown to the user in normal installations. Whether this is the case isn't decided by any template; instead, it is decided by the code that calls the templates. That code currently looks like this:

STATE=1
while true; do
        case "$STATE" in
            1)
                db_input low apt-setup/non-free || true
                ;;
            2)
                # If they chose not to use non-free, ask about
                # contrib, with a default of no. If they chose to
                # use non-free, they get contrib too..
                db_get apt-setup/non-free
                if [ "$RET" = false ]; then
                        db_fget apt-setup/contrib seen
                        if [ "$RET" = false ]; then
                                db_set apt-setup/contrib false
                        fi
                        db_input low apt-setup/contrib || true
                else
                        db_fget apt-setup/contrib seen
                        if [ "$RET" = false ]; then
                                db_set apt-setup/contrib true
                        fi
                fi
                ;;
            *)
                break
                ;;
        esac

        if db_go; then
                STATE=$(($STATE + 1))
        else
                STATE=$(($STATE - 1))
        fi
done

Note the "low" in the db_input lines; it means the question is only shown at low priority, i.e., in "expert" mode. The result is that, unless you enable expert mode, you won't even see the question about the non-free repository, and it will be disabled by default. There won't even be any mention of it in your sources.list file.

Of course, the above isn't about firmware files, which is what the FSF website claims. So, there is a second part to this story. If you run a system with hardware for which there is a non-free firmware package in the non-free repository, and you provided firmware for this hardware to the installer through various means, then the hw-detect module comes into play. This has code which currently looks like this:

# install cached firmware debs
if [ -d /var/cache/firmware ]; then
    for deb in /var/cache/firmware/*.deb; do
            if [ -f "$deb" ]; then
                    cp -a "$deb" /target/tmp
                    # TODO debconf passthrough
                    if ! in-target dpkg -i "/tmp/$(basename "$deb")"; then
                            # dpkg failed, force removal of package
                            in-target dpkg --force-depends --remove "$(deb_package "$deb")" || true
                    fi
                    rm -f "/target/tmp/$deb"
                    need_nonfree=1
            fi
    done
fi

if [ "$need_nonfree" ]; then
    db_set apt-setup/non-free true
fi

As can bee seen, if any firmware .deb files exist under /var/cache/firmware in the installer environment, then these will be installed on the target system and default answer to the apt-setup/non-free question will be changed to enable the non-free repository. How do such packages end up there?

Well, that's done by the same hw-detect udeb, in a different script. The code there is a bit too long to quote in this already far too long blog post, but it boils down to:

• If the installer detects missing firmware, the user is asked whether (s)he wants to install firmware, with the following template:

  Template: hw-detect/load_firmware
  Type: boolean
  Default: true
  # :sl2:
  _Description: Load missing firmware from removable media?
   Some of your hardware needs non-free firmware files to operate. The
   firmware can be loaded from removable media, such as a USB stick or
   floppy.
   .
   The missing firmware files are: ${FILES}
   .
   If you have such media available now, insert it, and continue.
  

• If the user agreed to doing so (and to me, the above template does not read as a recommendation), any firmware .deb files that are provided to the installer are tested for the missing firmware files.

• If any of those files are found, these .deb files are copied to the /var/cache/firmware directory, and the firmware files are made available to the running kernel.

Conclusion

In my opinion, while some of the claims on the FSF website are correct, others are at the very least misleading. Debian does not recommend the use of non-free software; and while providing non-free firmware to the installer isn't too difficult, it isn't documented very well; and as such installing a system with non-free enabled isn't something you can easily do by accident.

Debian and the FSF clearly disagree on certain things, and this disagreement, not any policies by the Debian project, is the main reason why the FSF won't encourage Debian as a free distribution. I don't think the Debian project will easily agree to get rid of the non-free repository while the FSF still produces non-free documentation or while non-free firmware is still a fact of life in this world. However, I do think the following should happen:

1. The FSF should relicense its non-free documentation so it becomes truly free.
2. Once that has happened, Debian should rename its non-free repository to a "hardware-support" repository (or something along those lines), and remove everything that does not exist solely for the support of proprietary hardware (i.e., non-free drivers, non-free firmware, etc).
3. The installer could be clearer on the fact that if non-free firmware is found to be in use for the system, the user is using software that cannot be properly supported by the Debian project.

While the above wouldn't necessarily bring the opinions of the FSF and Debian 100% in line, it would at least bring their positions closer to eachother. Unfortunately, however, I doubt that this will happen; and that's a shame, because in the end, both Debian and the FSF want the same thing: a world where Free Software is the norm, not the exception.

Update

• The first version of this text said that providing firmware is not very easy. As was pointed out to me, it isn't too hard, but it's not very well documented and not part of the 'regular' installer images.
• Add contrib too, when we compare non-free and main
• Clarify when GFDL is non-free

I try to use Debian everywhere. Not because I think it's perfect, but it's close. But if I had to point out one misdesign that I hate, it would be the fact that applications care about the contents of /etc/hosts.

If I don't put the FQDN on the line containing 127.0.0.1 in /etc/hosts, then one set of (proprietary) applications stops working.

If I do put the FQDN on the line containing 127.0.0.1 in /etc/hosts, then another set of (proprietary) applications stops working.

I want to kill people.

I've been considering writing a custom NSS module which changes the return value of gethostbyname() and friends depending on who's calling the function. That would be ugly, but I suppose it could work. But I really, really, really don't want to start doing this.

Grrr.

I've never liked the contents of the bash-completion package. I've found its results to be confusing, mildly buggy, and therefore terribly annoying. As such, for the longest time, one of the first things I used to do when installing a new system was to just remove it entirely -- or add "complete -r" or similar to my .bashrc on systems where I did not have sysadmin powers.

However, that's not to say that I don't understand the reason for programmable completion. Filename completion is nice, but it's great if one can have things like command option completion, etc. As such, I've resolved to give the bash-completion another shot for, say, a month or so, and to actually file bugs when things happen that I think should not.

Of course, it's very well possible that in the time since I last tried it, all those annoyingly small confusing bugs have been fixed. But somehow, I doubt that.

I guess we'll find out.

Yesterday, the Belgian team played against Algeria, and won 2-1. Before the match, there was some criticism about coach Wilmots' decision not to field a number of top players in the team at the start of the match. Today, some journalists -- including, apparently, some Russian journalists -- seem to think that the team didn't play all that well, and that the Belgian team could be beaten by a better team.

I don't think that's the case; I think the strategy of Wilmots was a stroke of genius.

The Algerian coach fielded a wall of 5 defenders, and played a pretty good counter game. When the Belgian team had posession -- for about 65% of the time during the entire match -- the Algerians returned every man to their own half of the field. Whenever one of the Belgian strikers came close to the Algerian penalty area, at least two Algerian players would be near and block them off.

How does one win from a team that doesn't want to give you a millimeter of room? One way is to wear them out, and that's exactly what the team did: by keeping the pressure on the Algerian defense, the Algerian defense had to run a lot. Running a lot makes you tired, and if you're tired you make mistakes, or you can't follow a fresh substitute player.

During half-time, it was reported that Wilmots had relayed the message to his players that "the bench will make the difference". And indeed it did; some time into through the second half, Wilmots substituted three players -- two strikers and one offensive midfielder -- with the top players he'd kept on the bench. Two of these three players made the difference, scoring two goals to end up with 2-1.

Reading some articles today, it seems like many analysts think that this was a spur of the moment thing by Wilmots; but I think it's more likely that this was a deliberate strategy. Making the opposing defense run a lot is certainly a good strategy; but the downside of that is that your own offensive players will need to run a lot, too. If you can swap those out for top players on the bench...

It'll be interesting to see the next matches.

Since about a month, I've been working for a customer whose customer is FedICT, and am now helping out with maintaining the official software for the Belgian electronic ID card (eID). One of the first things I did was revamp the way in which the official Linux binaries are built and distributed, and also made work of the (somewhat overdue) new release for Linux.

Previously, the website contained downloadable packages for a number of distributions: two .deb files (one for i386 and one for amd64, for all .deb-based distributions), and a number of RPM files (one each for fedora 15, 16, and red hat enterprise 5, also for both architectures).

The builds as well as the supported distributions were somewhat outdated. This was a problem in and of itself, as eID cards issued since March 2014 are signed by the new government CA3 certificate rather than the older CA2 one, which required minor updates for the middleware to work. Since the Linux packages available on the website predated the required change, they wouldn't work for more recent cards.

Moreover, the actual distributions that were supported were also outdated—Fedora 16 hasn't been supported in over a year by the Fedora project, for instance—and there was a major gap in our list of supported distributions, in that openSUSE RPMs were not provided.

If you check out the install on Linux pages now, however, you'll see that the installation instructions have been changed somewhat. Rather than links to packages to install, we now pass you an 'eid-archive' package that you can install; this package adds relevant configuration for your distribution, after which you can install the packages you need—eid-mw for the PKCS#11 library and the firefox and chrome plugins; eid-viewer for the graphical viewer application to view and possibly print data from your id card.

Apart from the fact that there are now repositories rather than just single-file downloads, the repositories (and in case of RPM packages, the RPM files themselves) are now also signed with an OpenPGP key. Actually, they are signed with two OpenPGP keys; the first one is for officially released builds (i.e., builds that have seen some extensive testing before they were deemed "working"), while the second one is for automatic builds that are generated through a continuous integration system after each and every commit. These untested packages are also in a separate repository that is disabled by default. In addition, there's also support for openSUSE now—which required more work than I expected, but wasn't a major problem.

Enjoy!

(for clarity: while I now work at FedICT, there's an obvious reason why I'm publishing this on my blog and not on any .belgium.be website—don't assume this is an official Belgian message or anything...)

Twenty years ago, I was sixteen and in high school. The school at the time, if memory serves right, was the "Kunsthumaniora voor muziek en woord van het gemeenschapsonderwijs" in Brussels (which translates approximately to "art high school for music and word of the communal educational branch"... that's not entirely right, but it's late and I'm too tired to look for a dictionary). I was taking drama classes there. No, I'm not making this up. Except maybe the sixteen bit—I might be off by one or two years.

Hey, I did a lot of things during high school. Stop looking at me like that.

At one point in time during my stint in drama, a group of educational interns—the sort of people who would be teaching some sort of stuff somewhere after their graduation—cooperated with our school to come up with a whole day of classes around one subject. I'll never forget the title: "Can art rescue the democracy?" If that sounds pompous and silly, that's because it was. However, I was at art school, fer crying out loud, so I drank it up like it was cool-aid. Which it wasn't. It was worse.

At the end of the day (literally, that is), the educational interns had booked some hot shot art person for a debate. I've since completely forgotten his name. He must've been not that hot shot after all, since I never even once read anything about him in the next few years. Of course I can't exclude the most recent decade, not remembering him and all, but whatever. I also don't remember whether he was a hot shot art critic, a hot shot artist, or just some random hot shot person who writes about art, but doesn't actually do it himself. Whatever.

One of the main topics during the whole day was the point about how artsy people find it extremely difficult to define what art actually is. I mean, it's all they do all day, but they can't come up with a decent definition of the damn thing.

During the afternoon break, just before the debate with this maybe-sortof-semi hot shot art person, I walk around the playground and think about the whole thing. And come up with some personal definition of art. My definition.

As the time of the debate comes up, the hot shot art person sits in the front of the gym behind some table, and the whole school (literally) is sitting in chairs in the rest of the gym. Some questions are asked. Many of those are just shot down.

At some point, I raise my finger when it's asked if anyone has further questions. I walk up to the microphone. I ask him:

"Could we maybe define art as that thing that, though it might be easy to reproduce, in no case is easy to produce?"

He sits (he never got up, really). He thinks. I stand, and wait. After a few seconds of this, he answers. He seems impressed. His reply is something along the lines of "that's not a perfect definition, but it's pretty good. There's a lot to be said for that, and I urge you to write about art when you grow older".

I never followed his advice. I got a bit more interested in art, but quickly found out that art consists of one group of people who spend their time doing things other people find pretty, and another group of people who spend their time doing things that makes other people "think", whatever that is. They may not have a brain, they may be silly as hell, but they still want to "think". It's not for me, it's never been. Art, that is -- not the think bit. That is something I don't mind doing.

Don't get me wrong. I still like art. I like going to museums from time to time; I like the performing arts. I mean, I play the flute. Not the piano, not the guitar, not the flipping drums, the flute. Which I like, for what it's worth.

But if the intent is to make people think, there are better ways to do that. If I want to make people think, I'm not going to make some obscure object that may or may not have a message, in the hope that a millionaire with no better use for his money would buy it just to make his friends jealous, after which he's going to put it in a safe for a few years so he can sell it at a higher value. Without thinking about it. If I want to make people think, I'm not going to write a play or piece of music that's so obscure it will make people all confused, so they can fill their evening afterwards drinking cocktails at a reception, claiming it was all nice and thought-provoking, quoting little parts of it to people they've never met, just so they can make their social status look more than it actually is.

Good thing I never finished drama school, I suppose.

No, if I want to make people think, I'll try doing so where it actually matters. Like, say, in politics. Not that I have any political ambitions, mind you. But I think the answer to that question of twenty years ago should be a firm "no." Art cannot rescue democracy. Not if they don't have a lot of interesting things to say to anyone but themselves. Maybe the reverse is true, though; maybe democracy can rescue art. Not that I care much.

Why is all this relevant today?

A few days ago, as I was driving somewhere, there was some show on the radio relating to the current exploits of the Belgian national soccer team. There are a lot of them these days. Radio shows about that subject, that is—not Belgian national soccer teams. I suppose having a lot of competition makes it hard to find a new angle to come up with, and still keep things interesting. I also suppose having a lot of stuff going on about that squad gets people annoyed if they're not the least bit interested. I suppose that could be a new angle. Presumably that radio host supposed the same, because he'd been looking for, and asking questions of, people who didn't like soccer and who weren't going to watch the match. Most of them said they weren't interested and added one or two words about what they were going to be doing instead.

One of them said that "they" would be better off spending money on "art and culture", rather than on soccer. No, I don't know who "they" were, he didn't say. Never mind that, let me go on now.

I don't know who this dude was; they—the radio people—didn't say. He sounded like someone between 50 and 65, and had a somewhat tenor-y voice. I suspect he had two kids, and a mercedes. Yes, I just made that up. The part about the kids. And the car. No, it doesn't matter. But it's still likely. He sounded like that sort of guy.

Whoever this dude was, though, I'd like to just say one thing: Dude, you're an idiot. There's a time and a place for everything.

The time and place for art is "everywhen", and "in any random art gallery, opera house, or theatre, out of the public eye". Not because the rest of us doesn't want to deal with art, but because artsy people like it that way. They like to feel all pompous and important, and therefore use difficult words. Words that nobody except those along with them in their ivory tower like to use. Words that don't actually mean anything. But in doing so, they make this Art thing uninteresting to look at for people who don't care about their pompous and silly words. And strengthen the walls of their ivory tower. Only to complain later on that nobody ever shows up at art galleries, and that the really good ones keep going out of business.

The time and place for the world championship soccer is "once every four years", and "everywhere". Not because soccer people want to annoy you—although, yes, I'll grant you that the KBVB has gone a little overboard with the merchandising this time around—but rather because it's so simple. You kick the ball, and you hit the goal. There, done. Everyone can do it. Yes, true, there are some pompous people talking about it on TV, too. And yes, true, some people are better at it than others. But nobody claims you can't do soccer unless you're part of the "in" club. There are plenty of people who claim you can't do art unless you are. And if everyone can do it, then everyone can understand it. If you can understand it, it's easier to enjoy it. This is why so few people enjoy cricket or baseball outside of the few countries where it's popular.

That's also why so few people enjoy art: because you make it so difficult. And people just don't care. They want to be entertained.

I'm not saying that soccer is the best sport in the world, or that watching it is the most entertaining thing one can do. It isn't. In fact, beyond the national team, I'm not really following it all that well myself. If through some weird spacial anomaly the world championship would suddenly cease to exist and I would be the only person alive remembering it, I don't think I'd spend a lot of time trying to get it back.

But don't compare it to art. Because, well, in the grand scheme of things, neither of those two really matters all that much.

That is all.

When I took over maintenance of the nbd userland utilities, I decided not to do a full rewrite, even though that might have been a good idea. I've managed to keep things running, but the code isn't very pretty. Unfortunately I've also made a few mistakes. Yes, I know. No, I can't say it won't happen again.

Still, the "design", for lack of a better word, of the nbd-server code was problematic, to the extent that some needed performance improvements could not be done, or would require so much work that it would be better to just throw everything out and start over. The unfortunate result of this has been that those who did want to try to do something new with NBD did just that, rather than contributing back to the reference implementation.

Over the years, I've sometimes tried to come up with ways to improve the way in which things work. Most of these efforts haven't gone very far, either because they turned out to be dead ends, or because I just didn't have the time to finish it, and that by the time I could finally work on the branch again, the main branch had diverged so much that the branch was so outdated that I would almost have to start over if I was ever going to make it useful again.

The most recent of those efforts is the io_transaction branch. This branch has two main goals:

1. Make nbd-server somewhat more modular, so that it would be possible to a different backend per export, if necessary
2. Improve upon the way we handle select() and friends, so that the server can deal with requests more efficiently.

Today, I've reached the (fairly significant) milestone with that branch that on my machine, it seems to pass the "read" part of the test suite. What's more, the second part of the above two means it actually did so at a much higher speed than it does, on average, on the main branch.

Of course, reading is only half of the story, and no, write doesn't seem to work yet. After that, there's also a lot of work still to be done if I want to get this branch "on par" with the main branch, feature-wise.

But there's a light at the end of the tunnel. Finally.