Dear google,
About half a decade ago, I created a gmail account (maybe longer—not so sure anymore). After testing it out for a while, I decided that it wasn't for me; but as a gmail account comes with a google account for free, I didn't throw it out.
As time went on, I added a few other things to that account. I try to limit its use a bit, but I do own a few android devices (for lack of a better alternative), and I do use adsense on my website, and all of these are linked to my existing google account; so I don't want to throw it away.
I don't ever read mail sent to my gmail account, though; I prefer to read my mail in a local mail client (I used mutt for about a decade, having switched to thunderbird recently). Since it kept happening that people thought I would read my gmail account (which I do still use for XMPP, in spite of your recent crippling of that service), I configured an autoresponder on gmail to warn people off, and told them to use my main mail address instead of the gmail one. Additionally, I configured my main mail addresses (plural; they're really aliases) as "secondary" addresses on my gmail account, so that people who try to send mail to me could figure out where to actually send it before seeing the autoreply.
Unfortunately, for some reason you seem to have interpreted that as "screw his MX records and DNSSEC, we'll just intercept anything coming from our servers and going to Wouter Verhelst as going to his gmail account".
There's a word for that. I'm not going to use it.
Computer education in Belgium
Today (well, technically yesterday by now), the Media were reporting of an open letter by '5 belgian university professors from the IT field' without calling them by name about how Belgian primary education should introduce programming into the curriculum, starting at age 5.
Unsurprisingly, this did not go well with a majority of the Belgian populace. Arguments like "what should the school drop to make place for that, then" and "why would people ever need to learn programming" were rampant on some internet fora that I had a short look at.
That being said, though, I think these five unnamed professors are correct. Understanding how a tool works is essential to proficient usage of said tool; and while it is possible to teach particular common and popular use cases of a given tool without providing enough background, doing so will only result in confusion when the computer "is acting up"—an oxymoron if there ever was one. After all, a computer can't "act up"; it can only follow instructions. Whenever your seems to be "acting up", what's really happening is that someone (most likely, you) gave it the wrong instructions. Or, perhaps, someone evil on the Internet gave it the right instructions (for their goals, anyway) and infected your computer with a virus. But that's unlikely.
Computer education currently mostly consists of "teaching software": rather than explaining how a computer does what it does, people are taught that if you click this button, the text will be bold, or if you click that button, the printer will start buzzing. That's all nice and dandy, until the actual computer people encounter when off the school bench and at work has this other piece of software, where all the buttons are in other places and look all "wrong". Because then they get all confused about the fact that things aren't where they're supposed to be.
So, yes, it is my opinion that any computer education should help people understand how a computer does the things it does. And what better way to do that than to actually explain things to a computer, the way computer programmers do such things?
Note that programming a computer doesn't have to be hard, and it can be something which kids can understand and will find fun to do. For instance, there's this scratch thing from MIT, which was made for teaching programming in such a context.
Yes, adding programming to the primary school curriculum will require that some other things are dropped instead, and I could see that being a problem. However, in our modern world computers have become so pervasively important that we would be doing our kids a disservice not to explain them how to understand computers, as opposed to just learn how to use them...
Buildbot
I'd set up buildbot at a customer last monday. Since that resulted in me understanding the thing, I also set up an instance for nbd. The need for this had become apparent after the last upload to unstable failed on a disconcertingly large number of architectures.
Apart from the fact that it uses python (and wants me to write python in its config file, grrr), it's a fairly nice system; pretty lightweight (it runs on barbershop, which is a QNAP TS419U, for crying out loud), yet still flexible enough that I don't have to jump through hoops to do normal things which the developer hadn't thought about.
I also just noticed that if you push multiple commits to a git repository at once (put otherwise, if buildbots notices multiple new revisions when it checks), it will make sure that all revisions get built at least once. Of course it would have been nice if it would pick the fastest machines to do the "older" revisions rather than "whoever happens to be first", but that doesn't really matter all that much.
Meanwhile, the bug that makes building 3.6 impossible on some architectures has been fixed. It turned out to be an LFS-issue, which is specific to 32-bit machines; and as my own machine runs amd64, well...
On the init system debate
The decision on which init system to use has plagued Debian for a fairly long time now. We've had people talking about it as early as debconf11 in Banja Luka, and we still haven't got a decision. Instead, the decision has been going round in circles, in a typical bikeshed fashion.
Originally, my opinion on the subject was "sysv-rc is good enough for everyone, and it's portable, which other alternatives aren't". By now, however, I've become convinced that the first part of that statement isn't true, and that as a result a switch of a default init system is indeed appropriate; that we should indeed switch to "something else", at least for our Linux ports.
Once I came to that conclusion, my opinion on what, exactly, we should use turned out to be nonexistent. That is, I don't care. Anything will be fine.
What is bothering me, though, is that things keep dragging on and on and on and on and on and on and on, ad infinitum.
We should just pick one and be done with it, dammit. The fact that sysv-rc is replaced by "something else" does not mean people must stop using sysv init scripts. Even if the maintainer of some random package "foo" refuses to accept patches to support sysv-rc for his package, there's nothing stopping anyone from providing a package "sysv-support" containing init scripts (and nothing else) for sysv-rc.
The same goes for a hypothetical upstart-support or systemd-support package, of course: if you want to continue living in the stone age and keep using sysv-rc forever, then there is nothing stopping you. Even if we decide to use something else for our Linux ports.
Ideally the non-Linux ports would move to something more modern too; but there really really really isn't any reason why it would be a problem if they didn't.
Can we stop painting the bikeshed now? If we don't, soon we'll have to call it "hunk of paint with some bikes inside" rather than "bikeshed".
Thanks.
Whoo
I'm actually doing other things right now, but this was just too much fun to ignore:
Woot.
Off to do other things, now.