Last october a bug was filled against the Debian’s Technical Committee requesting a vote on the next default init system.

Vote is expected at the end of this month. Based on vote intentions there is a draw at the moment (ctte membership is here): systemd, 4; upstart, 4; openrc, 0

• Bdale Garbee (bdale) – systemd.
• Russ Allbery (rra) – systemd (supplement).
• Don Armstrong (don) – systemd.
• Andreas Barth (aba) – upstart.
• Ian Jackson (iwj) – upstart.
• Steve Langasek (vorlon) – upstart.
• Keith Packard (keithp) – systemd.
• Colin Watson (cjwatson) – upstart.

Can’t find vorlon’s conclusion mail. Not sure if he hasn’t posted yet or if I missed the mail (the thread is +1000 messages). Anyway his vote is obvious given that he is the upstart package maintainer and upstart position maintainer in the init debate.

Other stuff on the matter:

• Kay Sievers states that systemd is in part consequence of the Canonical CLA.
• Spotify, as a Debian user, expresses his preference for systemd.
• A Hurd porter claims that sysvinit is not portable.

Update: As per Debian Constitution § 6.3.2, the chairman has an extra tie-breaker vote. That looks to me like a 5-4 in favor of systemd.

Update: LWN has published an article (subscriber link) with more details about the potentials outcomes. Constitution § 6.1.4 might apply as well and that requires a majority vote of 3:1. Also a General Resolution seems likely.

Update: A ballot was posted on January, 25. Actual votes:  Bdale Garbee, Russ Allbery, Keith Packard, Ian Jackson, Don Armstrong, Steve Langasek, Andreas Barth.

Update: An ammended ballot has been drafted to include the possibility of the project deciding the default init(1) by means of a GR.

Update: Conclusion messages 1 and 2. Result: Further Discussion.

Update: Resolution ballot draft published.

Update: Call for votes with final ballot announced. Did I said final? Nah.

Update: Analysis of casted votes and an amendment to it. systemd has high chances of winning. But, for second time, Further Discussion was the end result.

Update: Bdale Garbee, the chair, suddenly called for vote. Basicly the same ballot he posted weeks ago. Votes from Bdale himself, Russ Allbery, Steve Langasek, Don Armstrong, Keith Packard, Colin Watson, Ian Jackson and Andreas Barth. systemd wins by chair casting vote (analysis).

The process went very emotional though. This mail from Russ Alberry worth a read.

Update: Official resolution message on debian-devel-announce.

The process took 3 1/2 months from bug to resolution. There are 2738 messages in #727708 as of February 12.

Ubuntu’s BDFL shows real love in San Valentin day: Losing graciously.

Excerpt from a message I sent to tmux-users mailing list:

I just began to use the recently added zoom feature and came across an
anoying thing.

You have panes A and B. A is zoomed, if you switch to pane B, then A is
forcibly unzoomed. This is expected, of course, otherwise B would remain
invisible.

If you switch back to pane A I expect to get A zoomed again because it
wasn’t me who unzoomed it.

I submitted a patch implementing this and upstream liked it, I hope it will be merged before next release.

See it in action:

Update: “send a patch” is something like “I’d try this” and anything else. Upstream actually disliked it. I admit that a secretly zoomed pane somehow will violates the rule of least surprise.

I’m just another user who loves GNOME and suffers the blessing of its developers.

I’ve had the close button in the left since it was set by default in Ubuntu 10.04 and I liked it, and the button stayed in the left until GNOME 3.8.

GNOME 3.10 introduced Client Side Decoration (CSD), ie, now the application can paint the window border and buttons. Quoting from the linked site above:

A disadvantage of CSD is the inconsistency that brings between Apps that support them (mostly GNOME Apps) and Apps that don’t (3rd party Apps, like Firefox). However this is mostly in theory, because in practice, you won’t really be bothered from it.

A new widget called GtkHeaderBar was added in the process, and it was decided that the GtkHeaderBar will forcibly put the close button in the right, and then bug 706708 was filled, of course.

A fix was commited a month after the bug was filled and it entered in GTK+ 3.10.3. Now I can set the placement of the close button again, so Iet’s create a ~/.config/gtk-3.0/gtk.css with the following content:

and see what happens.

Clocks

this is gnome-clocks, honoring the setting.

Nautilus

and this is nautilus, not honoring the setting. It turned out that it isn’t using a GtkHeaderBar after all. You can see in the source code that a separator an a close button are manually added to the end of the top bar.

Gnome Tweak Tool

and this is gnome-tweak-tool, honoring the setting, only that it has two GtkHeaderBar. The one to the left is not displaying the close button.

Inconsistency they said?

Interesting stuff about the guts of computers:

• Elliptic curves and their implementation.
• The First Few Milliseconds of an HTTPS Connection.
• Improving the security of your SSH private files.
• Memory Layout of C Programs.
• SO: What is Branch Prediction?.
• SO: Why is one loop so much slower than two loops?.
• SO: What is the reason for performing a double fork when creating a daemon?.
• SO: Address invariance vs. data invariance.

Ansible 1.2 is out of the door. Go and check the changelog to see how many new features and fixes this version brings, my favorites being the new {{ }} syntax for variable substitution and support for roles. This version also includes a patch I submitted for adding encryption support to password lookup plugin.

In case you weren’t aware, ansible 1.1 gained support for generating random passwords as a lookup plugin. A useful trick that allowed to generate a random password in any point of a playbook without losing idempotence. An example of its use (taken from official docs):

but there are some modules, most notably user, that expect an encrypted password. For such modules the password lookup was unusable because it always returned plaintext.

With ansible 1.2 you can pass the encrypt parameter to password lookup to get an encrypted password instead of a plain one. In this mode the salt will be save along the password itself to ensure the same hash is returned each time a lookup is requested. An example:

I expect the main use case for this feature is feeding user module for defining users. If this is the case, you should use one of the standard unix schemes of passlib, I personally recommend sha256_crypt or sha512_crypt.

Update 20140212: Ansible documentation URLs updated.

Old and trivial, just fixing a build error, but anyway it made me proud at the time.

Years ago I acquired a TV-Tuner. When I bought it I was aware that both is wasn’t working in Linux and a driver was being written for it.

Having not enough knowledge and free time for anything besides testing the driver, and needing the device working, I began to pull, compile and see-if-it-works in a daily basis. One day the building was failing, I fixed it and submitted the patch and the patch got merged by the maintainer. Two years later it entered mainline.

At the end I couldn’t get the device fully working and gave it to a friend who had a supported OS so all I’ve left from that tuner was another fun experience of contributing to free software.

I’ve been playing lately with git-buildpackage for managing IPv6 attack toolkit packaging.

It turned out that another folk was trying to package the same software. He got in touch and we decided to join efforts.

After facing my first real experience of shared packaging two questions have arisen regarding the workflow:

1. should the patch-queue branch be published?
2. should the content of debian/patches be included in master?

The patch-queue branch is intended to be rebased again and again and you know what they say about rebasing a published branch, on the other hand if this branch is not shared, patch regeneration will be out of sync.

Given that debian/patches content is directly derivable from branch patch-queue/master, commits in master for  adding, refreshing or removing patches seem history pollution to me.

</thinking-out-loud>

I was reading What makes Python Awesome? presentation and saw the following construction in slide 22:

This construction is more concise without being less readable than the typical try ... catch ... pass. I had never seen that ignore before and got curious about where is it defined. It isn’t a CPython keyword neither part of the contextlib module.

After some search I found that an ignored (note the trailing d) context manager was recently added to the upcoming python 3.4. Nice!