I'm not complaining about old-school sysadmins. They know how to keep
systems running, manage update and upgrade paths.

This rant is about containers, prebuilt VMs, and the incredible mess they
cause because their concept lacks notions of "trust" and "upgrades".

Consider for example Hadoop. Nobody seems to know how to build Hadoop
from scratch. It's an incredible mess of dependencies, version requirements
and build tools.

None of these "fancy" tools still builds by a traditional make
command. Every tool has to come up with their own, incomptaible, and
non-portable "method of the day" of building.

And since nobody is still able to compile things from scratch,
everybody just downloads precompiled binaries from random websites.
Often without any authentication or signature.

NSA and virus heaven. You don't need to exploit any security hole
anymore. Just make an "app" or "VM" or "Docker" image, and have people
load your malicious binary to their network.

The Hadoop Wiki Page of
Debian is a typical example. Essentially, people have given up in 2010 to
be able build Hadoop from source for Debian and offer nice packages.

To build Apache Bigtop, you apparently first have to install puppet3.
Let it download magic data from the internet.
Then it tries to run sudo puppet to enable the NSA backdoors
(for example, it will download and install an outdated precompiled
JDK, because it considers you too stupid to install Java.)
And then hope the gradle build doesn't throw a 200 line useless backtrace.

Note that it doesn't even install the package properly, but extracts
it to your root directory. The download does not check any signature, not even
SSL certificates. (Source:
Bigtop puppet manifests)

Even if your build would work, it will involve Maven downloading
unsigned binary code from the internet, and use that for building.

Instead of writing clean, modular architecture, everything these days
morphs into a huge mess of interlocked dependencies. Last I checked, the
Hadoop classpath was already over 100 jars. I bet it is now 150, without
even using any of the HBaseGiraphFlumeCrunchPigHiveMahoutSolrSparkElasticsearch
(or any other of the Apache chaos) mess yet.

Stack is the new term for "I have no idea what I'm actually
using".

Maven, ivy and sbt are the go-to tools for having
your system download unsigned binary data from the internet and run it on your
computer.

And with containers, this mess gets even worse.

Ever tried to security update a container?

Essentially, the Docker approach boils down to downloading an
unsigned binary, running it, and hoping it doesn't contain any backdoor
into your companies network.

Feels like downloading Windows shareware in the 90s to me.

When will the first docker image appear which contains the Ask
toolbar? The first internet worm spreading via flawed docker images?

Back then, years ago, Linux distributions were trying to provide you
with a safe operating system. With signed packages, built from a web of trust.
Some even work on reproducible builds.

But then, everything got Windows-ized. "Apps" were the rage, which you
download and run, without being concerned about security, or the ability to
upgrade the application to the next version. Because "you only live
once".

Update: it was pointed out that this started way before Docker:
»Docker is the new 'curl | sudo bash'«. That's right,
but it's now pretty much mainstream to download and run untrusted software
in your "datacenter". That is bad, really bad. Before, admins would try hard
to prevent security holes, now they call themselves "devops" and happily
introduce them to the network themselves!

First let me note that I am using systemd, so these things here are
untested by me. See e.g. Petter's and
Simon's blog entries on the same overall topic.

According to the Debian installer maintainers, the only accepted way
to install Debian with sysvinit is to use preseeding. This can either be
done at the installer boot prompt by manually typing the magic spell:

preseed/late_command="in-target apt-get install -y sysvinit-core"

or by using a preseeding file (which is a really nice feature I used for
installing my Hadoop nodes) to do the same:

If you are a sysadmin, using preseeding can save you a lot of typing. Put all
your desired configuration into preseeding files, put them on a webserver (best
with a short name resolvable by local DNS). Let's assume you have set up
the DNS name d-i.example.com, and your DHCP is configured such that
example.com is on the DNS search list. You can also add a vendor
extension to DHCP to serve a full URL. Manually enabling preseeding then
means adding

auto url=d-i

to the installer boot command line (d-i is the hostname I suggested
to set up in your DNS before, and the full URL would then be
http://d-i.example.com/d-i/jessie/./preseed.cfg. Preseeding is
well
documented in Appendix B of the installer manual, but nevertheless will
require a number of iterations to get everything work as desired for a fully
automatic install like I used for my Hadoop nodes.

Since I don't intend to use sysvinit anymore, I will not be
pursuing this option further. It is, as far as I can tell, still untested.
If it works, it might be the least-effort, least-invasive option to allow
the installation of sysvinit Jessie (except for above command line magic).

If you have interest in sysvinit, you (because I don't use sysvinit)
should now test if this approach works.

Build an installer CD with this tasksel (maybe
this
documentation is helpful for this step).

Test whether the patch works. Report results to above bug report, so
that others interested in sysvinit can find them easily.

Find and fix bugs if it didn't work. Repeat.

Publish the modified ("forked") installer, and get user feedback.

If you are then still up for a fight, you can try to convince the maintainers
(or go the nasty way, and ask the CTTE for their opinion, to start another
flamewar and make more maintainers give up) that this option should be added to
the mainline installer. And hurry up, or you may at best get this into Jessie
reloaded, 8.1. - chance are that the release manager will not accept such
patches this late anymore. The sysvinit supporters should have investigated
this option much, much earlier instead of losing time on the GR.

Again, I won't be doing this job for you. I'm happy with systemd.
But patches and proof-of-concept is what makes open source work, not GRs
and MikeeUSA's crap videos spammed to the LKML...

(And yes, I am quite annoyed by the way the Debian installer
maintainers handled the bug report. This is not how open-source
collaboration is supposed to work. I tried to file a proper wishlist bug
reporting, suggesting a solution that I could not find discussed anywhere
before and got back just this "No. Shut up." answer. I'm not sure if I will
be reporting a bug in debian-installer ever again, if this is the way they
handle bug reports ...)

I do care about our users, though. If you look at popcon "vote" results,
we have 4179 votes for sysvinit-core and 16918 votes for
systemd-sysv(graph) indicating that of those already testing jessie and beyond - neglecting 65 upstart votes, and assuming that there is no bias to not-upgrade if you prefer sysvinit - about 20% appear to prefer sysvinit (in fact, they may even have manually switched back to sysvinit after being upgraded to systemd unintentionally?). These are users that we should listen to, and that we should consider adding an installer option for, too.

Because it says: Debian will remain Debian, as it was the last 20 years.

For 20 years, we have tried hard to build the "universal operating
system", and give users a choice. We've often had alternative software
in the archive. Debian has come up with various tool to manage alternatives
over time, and for example allows you to switch the system-wide Java.

You can still run Debian with sysvinit. There are plenty of Debian
Developers which will fight for this to be possible in the future.

The outcome of this resolution says:

Using a GR to force others is the wrong approach of getting
compatibility.

We've offered choice before, and we trust our fellow developers to
continue to work towards choice.

Write patches, not useless GRs. We're coders, not bureocrats.

We believe we can do this, without making it a formal MUST requirement.
Or even a SHOULD requirement. Just do it.

The sysvinit proponents may perceive this decision as having "lost". But
they just don't realize they won, too. Because the GR may easily have
backfired on them. The GR was not "every package must support sysvinit". It was
also "every sysvinit package must support systemd". Here is an example:
eudev, a non-systemd fork of
udev. It is not yet in Debian, but I'm fairly confident that someone will
make a package of it after the release, for the next Debian. Given the text of
the GR, this package might have been inappropriate for Debian, unless it also
supports systemd. But systemd has it's own udev - there is no reason to force
eudev to work with systemd, is there?

Debian is about choice. This includes the choice to support different init
systems as appropriate. Not accepting a proper patch that adds support for
a different init would be perceived as a major bug, I'm assured.

A GR doesn't ensure choice. It only is a hammer to annoy others. But it
doesn't write the necessary code to actually ensure compatibility.

If GNOME at some point decides that systemd as pid 1 is a must, the GR
only would have left us three options: A) fork the previous version, B) remove
GNOME altogether, C) remove all other init systems (so that GNOME is compliant).
Does this add choice? No.

Now, we can preserve choice: if GNOME decides to go systemd-pid1-only, we
can both include a forked GNOME, and the new GNOME (depending on systemd, which
is allowed without the GR). Or any other solution that someone codes and packages...

Don't fear that systemd will magically become a must.
Trust that the Debian Developers will continue what they have been doing the
last 20 years. Trust that there are enough Debian Developers that don't run
systemd. Because they do exist, and they'll file bugs where appropriate. Bugs
and patches, that are the appropriate tools, not GRs (or trolling).

Vincent Bernat blogged on using Netfilter rulesets, pointing out that
inserting the rules one-by-one using iptables calls may leave your firewall temporarily incomplete, eventually half-working, and that this approach can be slow.

He's right with that, but there are tools that do this properly. ;-)

Some years ago, for a multi-homed firewall, I wrote a tool called
Pyroman. Using rules specified
either in Python or XML syntax, it generates a firewall ruleset for you.

But it also adresses the points Vincent raised:

It uses iptables-restore to load the firewall more efficiently
than by calling iptables a hundred times

It will backup the previous firewall, and roll-back on errors (or
lack of confirmation, if you are remote and use --safe)

It also has a nice feature for the use in staging: it can generate
firewall rule sets offline, to allow you reviewing them before use,
or transfer them to a different host. Not all functionality is supported
though (e.g. the Firewall.hostname constant usable in python
conditionals will still be the name of the host you generate the rules on - you
may want to add a --hostname parameter to pyroman)

pyroman --print-verbose will generate a script readable by
iptables-restore except for one problem: it contains both the
rules for IPv4 and for IPv6, separated by #### IPv6 rules. It
will also annotate the origin of the rule, for example:

indicates that this particular line was produced due to line 82 in file
/etc/pyroman/02_icmpv6.py. This makes debugging easier. In particular
it allows pyroman to produce a meaningful error message if the rules are
rejected by the kernel: it will tell you which line caused the rule that
was rejected.

For the next version, I will probably add --output-ipv4 and
--output-ipv6 options to make this more convenient to use. So far,
pyroman is meant to be used on the firewall itself.

Note: if you have configured a firewall that you are happy with, you can
always use iptables-save to dump the current firewall. But it will
not preserve comments, obviously.

Overregulation is bad, and the project is
suffering from the recent Anti-Systemd hate campaigning.

There is nothing balanced about the original GR proposal. It is bullshit
from a policy point of view (it means we must remove software from
Debian that would not work with other inits, such as gnome-journal, by
policy).At the same time, it uses manipulative language like "freedom to
select a different init system" (as if this would otherwise be impossible) and
"accidentally locked in". It is exactly this type of language and behavior
which has made Debian quite poisonous the last months.

In fact, the GR pretty much says "I don't trust my fellow maintainers
to do the right thing, therefore I want a new hammer to force my opinion on
them". This is unacceptable in my opinion, and the GR will only
demotivate contributors. Every Debian developer (I'm not talking about
systemd upstream, but about Debian developers!) I've met would accept a patch
that adds support for sysvinit to a package that currently doesn't. The
proposed GR will not improve sysvinit support. It is a hammer to kick
out software where upstream doesn't want to support sysvinit, but it won't
magically add sysvinit support anywhere.

What some supporters of the GR may not have realized - it may as well
backfire on them. Some packages that don't yet work with systemd would
violate policy then, too... - in my opinion, it is much better to make
the support on a "as good as possible, given available upstream support and
patches" basis, instead of a "must" basis. The lock-in may come even faster
if we make init system support mandatory: it may be more viable to drop
software to satisfy the GR than to add support for other inits - and since
systemd is the current default, software that doesn't support systemd are
good candidates to be dropped, aren't they? (Note that I do prefer to keep
them, and have a policy that allows keeping them ...)

For these reasons I voted:

Choice 4: GR not required

Choice 3: Let maintainers do their work

Choice 2: Recommended, but not mandatory

Choice 5: No decision

Choice 1: Ban packages that don't work with every init system

Fact is that Debian maintainers have always been trying hard to
allow people to choose their favorite software. Until you give me an example
where the Debian maintainer (not upstream) has refused to include sysvinit
support, I will continue to trust my fellow DDs. I've been considering to
place Choice 2 below "further discussion", but essentially this is a
no-op GR anyway - in my opinion "should support other init systems" is
present in default Debian policy already anyway...

He has not contributed anything to the open source community. His songs
and "games" are not worth looking at, and I'm not aware of any project that
has accepted any of his "contributions". Yet, he uses several sock puppets
to spread his hate.

The anti-systemd "crowd" (if it acually is more than a few
notorious trolls) has lost all its credibility in my opinion.
They spread false information, use false names, and focus on hate instead of
improving source code. And worse, they tolerate such trolling in their
ranks.

A particularly annoying troll has been on his hate crusade against systemd for months now.

Unfortunately, he's particularly active on Debian mailing lists (but apparently also on Ubuntu and the Linux Kernel mailing list)
and uses a tons of fake users he keeps on setting up. Our listmasters have a hard time blocking
all his hate, sorry.

Obviously, this is also the same troll that has been attacking Lennart Poettering.

There is evidence
that this troll used to go by the name "MikeeUSA", and has quite
a reputation with anti-feminist hate for over 10 years now.

Even if you don't like the road systemd is taking or Lennart Poetting personall -
the behaviour of that troll is unacceptable to say the least; and indicates
some major psychological problems... also, I wouldn't be surprised if he is also
involved in #GamerGate.

See this example (LKML)
if you have any doubts. We seriously must not tolerate such poisonous people.

If you don't like systemd, the acceptable way of fighting it is to write good alternative software (and you should be able to continue using SysV init or openRC, unless there is a bug, in Debian - in this case, provide a bug fix). End of story.

Google Earth for Linux appears to be largely abandoned by Google,
unfortunately. The packages available for download cannot be installed
on a modern amd64 Debian or Ubuntu system due to dependency issues.

In fact, the adm64 version is a 32 bit build, too. The packages
are really low quality, the dependencies are outdated, locales support
is busted etc.

So here are hacky instructions how to install nevertheless.
But beware, these instructions are a really bad hack.

These instructions are appropriate for version 7.1.2.2041-r0.
Do not use them for any other version. Things will have changed.

Install lsb-core, and try to install the i386 versions of
these packages, too!

Download the i386 version of the Google Earth package

Install the package by forcing dependencies, via

sudo dpkg --force-depends -i google-earth-stable_current_i386.deb

As of now, your package manager will complain, and suggest to remove
the package again. To make it happy, we have to hack the installed
packages list. This is ugly, and you should make a backup. You can
totally bust your system this way... Fortunately, the change we're doing
is rather simple. As admin, edit the file /var/lib/dpkg/status.
Locate the section Package: google-earth-stable. In this section,
delete the line starting with Depends:. Don't add in extra
newlines or change anything else!

Now the package manager should believe the dependencies of Google
Earth are fulfilled, and no longer suggest removal. But essentially this
means you have to take care of them yourself!

Some notes on using Google Earth:

Locales are busted. Use LC_NUMERIC=en_US.UTF-8 google-earth
to start it. Otherwise, it will fail parsing coordinates, if you are in a
locale that uses a different number format.

You may need to install the i386 versions of some libraries, in particular
of your OpenGL drivers! I cannot provide you with a complete list.

Search doesn't work sometimes for me.

Occassionally, it reports "unknown" network errors.

If you upgrade Nvidia graphics drivers, you will usually have to
reboot, or you will see graphics errors.

Some people have removed/replaced the bundled libQt* and
libfreeimage* libraries, but that did not work for me.

It has been all over the place. The Debian CTTE has chosen systemd over
upstart as default init system by chairman call. This decision was
overdue, as it was pretty clear that the tie will not change, and thus it will
be up to chairman. There were no new positions presented, and nobody was being
convinced of a different preference. The whole discussion had been escalating,
and had started to harm Debian.

Some people may not want to hear this, but another 10 ballots and options
would not have changed this outcome. Repating essentially the same decision
(systemd, upstart, or "other things nobody prefers") will do no good, but turn
out the same result, a tie. Every vote counting I saw happen would turn out this
tie. Half of the CTTE members prefer systemd, the other half upstart.

The main problems, however, are these:

People are not realizing this is about the default init for jessie,
not about the only init to support. Debian was and is about
choice, but even then you need to make something default... If you
prefer SysV init or openRC, you will still be able to use it (it will be just
fewer people debugging these startup scripts).

Some people (not part of the CTTE) are just
social
inept trolls, and have rightfully been banned from the list.

The discussion has been so heated up, a number of imporant secondary
decisions have not yet been discussed in a civil manner. For example, we
will have some packages (for example,
Gnome Logs), which are specific
to a particular init system, but not part of the init system.
A policy needs to be written with these cases in mind that states when and
how a package may depend on a particular init system. IMHO, a package that
cannot support other init systems without major changes should be allowed
to depend on that system, but then meta-packages such as the Gnome meta packages
must not require this application.

So please, everybody get back to work now. If there ever is enough reason to
overturn this decision, there are formal ways to do this, and there are people in the CTTE
(half of the CTTE, actually) that will take care of this.

Until then, live with the result of a 0.1 votes lead for systemd. Instead
of pursuing a destructive hate campaign, why not improve your favorite init system instead.

Oh, and don't forget about the need to spell out a policy for init system
support requirements of packages.

As you might be aware, the "deb-multimedia" packages have seen their share of
chaos.

Originally, they were named "debian-multimedia", but it was then decided that they
should better be called "deb-multimedia" as they are not an official part of Debian.
The old domain was then grabbed by cybersquatters when it expired.

While a number of packages remain indistributable for Debian due to legal issues - such as
decrypting DVDs - and thus "DMO" remains useful to many desktop users, please note that
for many of the packages, a reasonable version exists within Debian "main".

So here is a way to prevent automatically upgrading to DMO versions of packages that
also exist in Debian main:

We will use a configuration option known as
apt pinning. We will modify the
priority of DMO package to below 100, which means they will not be automatically upgraded to; but they
can be installed when e.g. no version of this package exists within Debian main. I.e. the packages
can be easily installed, but it will prefer using the official versions.

For this we need to create a file I named /etc/apt/preferences.d/unprefer-dmo with the contents:

As long as the DMO archive doesn't rename itself, this pin will work; it will continue to work if
you use a mirror of the archive, as it is not tied to the URL.

It will not downgrade packages for you. If you want to downgrade, this will be a trickier
process. You can use aptitude for this, and start with a filter (l key, as in "limit") of
?narrow(~i,~Vdmo). This will only show packages installed where the
version number contains dmo. You can now patrol this list, enter the
detail view of each package, and check the version list at the end for a
non-dmo version.

I cannot claim this will be an easy process. You'll probably have a lot of
conflicts to clear up, due to different libavcodec* API versions. If I
recall correctly, I opted to uninstall some dmo packages such as
ffmpeg that I do not really need. In other cases, the naming is
slightly different: Debian main has handbrake, while dmo has
handbrake-gtk.

A simple approach is to consider uninstalling all of these packages. Then reinstall
as needed; since installing Debian packages is trivial, it does not hurt to
deinstall something, does it? When reinstalling, Debian packages will be preferred over DMO packages.

I prefer to use DFSG-free software
wherever possible. And as long as I can watch my favorite series
(Tatort, started in 1970 and airing episode 900
this month) and the occasional DVD movie, I have all I need.

An even more powerful aptitude filter to review installed non-Debian
software is ?narrow(~i,!~ODebian), or equivalently
?narrow(?installed,?not(?origin(Debian))).
This will list all package versions, which cannot be installed from
Debian sources. In particular, this includes versions that are no longer
available (they may have been removed because of security issues!),
software that has been installed manually from .deb files, or any
other non-Debian source such as Google or DMO. (You should check the output of
aptitude policy that no source claims to be o=Debian that
isn't Debian though).

This filter is a good health check for your system. Debian packages receive a good
amount of attention with respect to packaging quality, maintainability, security and all
of these aspects. Third party packages usually failed the Debian quality check in at least
one respect. For example, Sage isn't
in Debian yet; mostly because it has so many dependencies, that making a reliable and
upgradeable installation is a pain. Similarly, there is no Hadoop in Debian yet. If you look
at Hadoop packaging efforts such as Apache Bigtop,
they do not live up to Debian quality yet. In particular, the packages have high redundancy,
and re-include various .jar copies instead of sharing access to an independently
packaged dependency. If a security issue arises with any of these jars, all the Hadoop
packages will need to be rebuilt.

As you can see, it is usually not because of Debian being too strict or too conservative
about free software when software is not packaged. More often than not, it's because the software
in question itself currently does not live up to Debian packaging quality requirements.
And of course sometimes because there is too little community backing the software in question,
that would improve the packaging. If you want your software to be included in Debian, try to make
it packaging friendly. Don't force-include copies of other software, for example.
Allow the use of system-installed libraries where possible, and provide upgrade
paths and backwards compatibility. Make dependencies optional, so that your software can be
pacakged even if a dependency is not yet available - and does not have to be removed if
the dependency becomes a security risk. Maybe learn how to package yourself, too. This will
make it easier for you to push new features and bug fixes to your userbase: instead of
requiring your users to manually upgrade, make your software packaging friendly.
Then your users will be auto-upgraded by their operating system to the latest version.

Update: If you are using APT::Default-Release or other pins, these may
override above pin. You may need to use apt-cache policy to find out if the
pins are in effect, and rewrite your default-release pin into e.g.

Package: *
Pin: release a=testing,o=Debian
Pin-Priority: 912

for debugging, use a different priority for each pin, so you can see which one is in effect.
Notice the o=Debian in this pin, which makes it apply only to Debian repositories.

The init wars have recently caught a lot of media attention (e.g.
heise, prolinux, phoronix). However, one detail that is often overlooked: Debian
is debating over the default, while all of them are already supported
to a large extend, actually. Most likely, at least two of them will be made
mandatory to support IMHO.

The discussion seems to be quite heated, with lots of people trying to
evangelize for their preferred system. This actually only highlights that we
need to support more than one, as Debian has always been about
choice. This may mean some extra work for the
debian-installer
developers, because choosing the init system at install time (instead of
switching later) will be much easier. More often than not, when switching from
one init system to another you will have to perform a hard reset.

If you want to learn about the options, please go to the
formal discussion page,
which does a good job at presenting the positions in a neutral way.

Here is my subjective view of the init systems:

SysV init is the current default, and thus deserves to be mentioned first.
It is slow, because it is based on a huge series of shell scripts. It can often be
fragile, but at the same time it is very transparent. For a UNIX system
administrator, SysV init is probably the preferred choice. You only reboot your
servers every year anyway.

upstart seems to be a typical Canonical project. It solves a great deal of
problems, but apparently isn't good enough at it for everybody, and they fail at
including anyone in their efforts. Other examples of these fails include
Unity and Mir, where they also announced the project as-is, instead of trying to
get other supporters on board early (AFAICT). The key problem to widespread
upstart acceptance seems to be the
Canonical
Contributor License Agreement that many would-be contributors are unwilling to
accept. The only alternative would be to fork upstart completely, to make it independent
of Canonical. (Note that upstart nevertheless is GPL, which is why it can be used by
Debian just fine. The CLA only makes getting patches and enhancements included in the
official version hard.)

systemd is the rising star in the init world. It probably has the best
set of features, and it has started to incorporate/replace a number of existing projects
such as ConsoleKit. I.e. it not only manages services, but also user sessions. It can
be loosely tied to the GNOME project which has started to rely on it more and more
(much to the unhappyness of Canonical, who used to be a key player for GNOME; note that
officially, GNOME chose to not depend on systemd, yet I see this as the only reliable
combination to get a complete GNOME system running, and since "systemd can eventually
replace gnome-session" I foresee this tie to become closer). As the main drawback,
systemd as is will (apparently) only work with the Linux kernel, whereas Debian
has to also support kFreeBSD, NetBSD, Hurd and the OpenSolaris kernels (some
aren't officially supported by Debian, but by separate projects).

So my take: I believe the only reasonable default is systemd. It has the
most active development community and widest set of features. But as it cannot support
all architectures, we need mandatory support for an alternative init system, probably
SysV. Getting both working reliably will be a pain, in particular since more
and more projects (e.g. GNOME) tie themselves closely to systemd, and would then become
Linux-only or require major patches.

I have tried only systemd on a number of machines, and unfortunately I cannot
report it as "prime time ready" yet. You do have the occasional upgrade problems and
incompatibilities, as it is quite invasive. From screensavers activating during movies to
double suspends, to being unable to shutdown my system when logged in (systemd
would treat the login manager as separate session, and not being the sole user
it would not allow me to shut down), I have seen quite a lot of annoyances
happen. This is an obvious consequence of the active development on systemd.
This means that we should make the decision early, because we will need a lot
of time to resolve all these bugs for the release.

There are more disruptions coming on the way. Nobody seems to have talked about
kDBUS yet, the integration of an IPC mechanism like DBUS into the Linux kernel. It
IMHO has a good chance of making it into the Linux kernel rather soon, and I wouldn't
be surprised if it became mandatory for systemd soon after. Which then implies that
only a recent kernel (say, mid-2014) version might be fully supported by systemd soon.

I would also like to see less GNOME influence in systemd. I have pretty
much given up on the GNOME community, which is moving into a UI direction that I hate:
they seem to only care about tablet and mobile phones for dumb users, and slowly turn
GNOME into an android UI; selling black background as major UI improvements.
I feel that the key GNOME development community does not care about developers
and desktop users like me anymore (but dream of being the next Android), and
therefore I have abandoned GNOME and switched to XFCE.

I don't give upstart much of a chance. Of course there are some Debian developers
already involved in its development (employed by Canonical), so this will cause some
frustration. But so far, upstart is largely an Ubuntu-only solution. And just like Mir,
I don't see much future in it; instead I foresee Ubuntu going systemd within a few years,
because it will want to get all the latest GNOME features. Ubuntu relies on GNOME, and
apparently GNOME already has chosen systemd over upstart (even though this is
"officially" denied).

Sticking with SysV is obviously the easiest choice, but it does not make a lot of
sense to me technically. It's okay for servers, but more and more desktop applications
will start to rely on systemd. For legacy reasons, I would however like to retain
good SysV support for at least 5-10 more years.

But what is the real problem? After all, this is a long overdue decision.

There is too much advocacy and evangelism, from either side. The CTTE isn't
really left alone to do a technical decision, but instead the main factors
have become of political nature, unfortunately. You have all kinds of companies
(such as Spotify)
weigh in on the debate, too.

The tone has become quite aggressive and emotional, unfortunately. I
can already foresee some comments on this blog post "you are a liar, because
GNOME is now spelled Gnome!!1!".

Media attention. This upcoming decision has been picked up by
various Linux media already, increasing the pressure on everybody.

Last but not least, the impact will be major. Debian is one of the largest
distributions, last but not least used by Ubuntu and Steam, amongst others. Debian
preferring one over the other will be a slap in somebodys face, unfortunately.

So how to solve it? Let the CTTE do their discussions, and stop
flooding them with mails trying to influence them. There has been so much
influencing going on, it may even backfire. I'm confident they will find a
reasonable decision, or they'll decide to poll all the DDs. If you want to
influence the outcome provide patches to anything that doesn't yet fully
support your init system of choice! I'm sure there are hundreds of packages which do
neither have upstart nor systemd support yet (as is, I currently have 27 init.d scripts
launched by systemd, for example). IMHO, nothing is more convincing
than have things just work, and of course, contributing code. We are in open
source development, and the one thing that gets you sympathy in the community is
to contribute code to someone elses project. For example, contribute full integrated
power-management support into XFCE, if you include power management functionality.

As is, I have apparently 7 packages installed with upstart support, and 25
with systemd support. So either, everybody is crazy about systemd, or they have
the better record of getting their scripts accepted upstream. (Note that this
straw poll is biased - with systemd, the benefits of not using "legacy" init.d
script may just be larger).

ELKI, the data mining framework I use for all
my research, is coming along nicely, and will see continued progress in 2013.
The next release is scheduled for SIGMOD 2013,
where we will be presenting the novel 3D parallel coordinates visualization we recently developed.
This release will bear the version number 0.6.0.

Version 0.5.5 of ELKI is in Debian unstable since december (Version 0.5.0 will be in the next
stable release) and Ubuntu raring. The packaged installation can share the dependencies with other
Debian packages, so they are smaller than the download from the ELKI web site.

If you are developing cluster analysis or outlier detection algorithm, I would love to see
them contributed to ELKI. If I get a clean and well-integrated code by mid june, your
algorithm could be included in the next release, too. Publishing your algorithms in source
code in a larger framework such as ELKI will often give you more citations. Because it is
easier to compare with your algorithm then and to try it on new problems. And, well, citations
counts are a measure that administration loves to judge researchers ...

So what else is happening with ELKI:

The new book "Outlier Analysis" by C. C. Aggarwal mentions ELKI for visual evaluation of
outlier results as well as in the "Resources for the Practioner" section and cites around
10 publications closely related to ELKI.

Some classes for color feature extraction of ELKI have been contributed to
jFeatureLib, a Java library for feature
detection in image data.

I'd love to participate in the Google Summer of Code, but I need a contact at Google to
"vouch" for the project, otherwise it is hard to get in. I've been sending a couple of
emails, but so far have not heard back much yet.

As the performance of SVG/Batik is not too good, I'd like to see more OpenGL based visualizations.
This could also lead to an Android based version for use on tablets.

As I'm not an UI guy, I would love to have someone make a fancier UI that still exposes all
the rich functions we have. The current UI is essentially an automatically generated command line
builder - which is nice, as new functionality shows up without the need to modify UI code.
It's good for experienced users like me, but hard for beginners to get started.

I'd love to see integration of ELKI with e.g.
OpenRefine / Google Refine
to make it easier to do appropriate data cleaning and preprocessing

There is work underway for a distributed version running on Hadoop/YARN.

I've added IPv6 support to my firewall tool
Pyroman, and uploaded a
package to experimental. But of course you can just checkout the source
code from Subversion and call it as bin/pyroman without installation.

Pyroman will try to produce a consistent set of rules for IPv4 and IPv6.
Originally it was designed for complex firewalls with multiple interfaces,
various rules and NAT. I have so far only tested this version on my single-host
setup at home, in particular NAT might break.

Pyroman has extensive debug functions. You can try --print-verbose
to see why it produced which rules. By invoking pyroman safe you will
tell it to revert any changes unless you type OK at the prompt.

And if it fails to compute firewall rules, or there is some iptables
error, it will also restore the previous state.

So you have plenty of options to give it a try without risking to
produce a mess. Just start with configuring it to the point where you like the
"--print" output. Then give the "safe" mode a try next.

Check the Pyroman homepage
for the features. There is more. Pyroman is a lot faster than most other
firewall tools, because it does not perform hundreds of iptables
invocations but uses iptables-restore to bulk load them. This is the
fastest way to bring the firewall from one configured state into another.
For the 0.6 version of pyroman I plan to offer precomputing the firewall
rules, and use a single iptables-restore call at bootup to setup
your firewall, with dependency tracking to see if the precomputed file is
still up to date.

Beware from upgrading on AMD64. Make sure to avoid version 2.1.3-3, as this will render your system
unbootable and unusable. As simple as the reason is (a missing link) as severe.

Bug report with instructions on
how to recover. If you are lucky you have a root shell open to restore the missing link. Otherwise, you need
to reboot with parameters break=init rw, recover the link with cd root; ln -s lib lib64,
sync, unmount, reboot. It's not really hard to do when you know how. But it is a lot easier to avoid
upgrading to this version. My i386 mirror already has the fixed upload (but
i386 is not affected anyway). So by tomorrow, it should be safe again (depening on your mirrors delay).

On my netbook, I try to keep the amount of installed software limited.
Aptitudes "automatically installed" markers are very helpful here, since they
allow you to differentiate between packages that were deliberately installed
and packages that were manually marked for installation. I quite often browse
through the list of installed packages and recheck those that are not marked as
"A".

However, packages that are "suggested" by some other package (but not
"required") will be kept even when marked as automatically. This is quite sensible:
when you deinstall the package that "suggested" them, they will be removed. So this
is nice for having optional software also automatically removed.

However sometimes you need the core package but not this optional functionality.
Aptitude can help you there, too. Here's an aptitude filter I used to find some
packages for removal:

!?reverse-depends(~i) ~M !?essential

It will display only
packages with no direct dependency from another installed package and that are
marked as automatically installed (so they must be kept installed because of a
weaker dependency.

Some examples of "suggested but not required" packages:

Accessibility extensions of Gnome

Spelling dictionaries

Optional functionality / extensions

Depending on your requirements, you might want to keep some of these and remove others.

Here is also a filter to find packages that you can put on "automatically installed":

~i !~M ?reverse-depends(~i) !?essential

This will catch "installed but not automatically
installed packages, that another installed package depends on". Note that you should not
blindly put all of these to "automatic" mode. For example "logrotate" depends on
"cron | anacron | fcron". If you have both cron and anacron installed, aptitude will
consider anacron to be unnecessary (it is - on a system with 24h uptime). So review this
list, and see what happens when you set packages to "A", and reconsider your intentions.
If it is a software you want for sure, leave it on manual.

The file manager can be set to still draw icons on the desktop, but that
doesn't entirely work yet (it will also open folders as desktop then...)

One machine had lost the keyboard settings. I could not set the fonts I wanted...

There is a tool called dconf-editor that will allow you to manually tweak
some settings such as the fonts. But it doesn't seem to have support for value
lists yet - and the keyboard mappings setting is a string list.

Congratulations to everyone involved in ironing the last few bugs out.

(My own involvement had been a bit limited recently, but I at least kept my few
remaining packages in a ready-to-release state and helped with the occasional bug
report and patch.)

Some people think that Ubuntu is the better Debian - I do NOT. Debian is
a fun place, has great people working on it and is true to its aims at creating a
truly free and high-quality distribution. The long release cycles of Debian are a
feature, not a bug. Stable is for production systems, not toy projects.

The proper way of attributing Debian stable is conservative and
sustainable, but not outdated. It actually can do everything you need - and
will do so in 10 years.

If you have been using Open Source for as long as me (say 15+ years) you will
probably have seen software hypes come and go. The one thing that has been always
the same was Debian: dead reliable. There was a time when everyone was crazy about
enlightement for it's shiny pretty UI. Almost like Compiz-Beryl just two years ago.
It came, as a matter of fact Debian also had it, but it also went.

I also remember how people complained that Debian didn't ship Xgl back in 2006
when this was the latest hype (there was no Debian release in 2006). Well, Xgl died
in 2008. The features remained, but done in a much nicer way, and also found their
way into Debian. In fact, I also ran Xgl at least once, on Debian, but just not on
"stable". One could say that Xgl never was quite "stable", was it?

Debian stable is good the way it is: an administrators choice. Of course,
developers might have different needs, but there also is testing, unstable and
experimental. Just make sure to align your choice with your needs. And sometimes,
also rethink your needs: there is no "latest beta versions" and "stable platform"
at the same time.

I have a new netbook, from work. This model wasn't my choice, but it is
a really good choice by our system administrator. The design is plain, dark
but nice (brushed aluminium), the size is a true netbook. I also like the
keyboard, despite the small size.

Installing Debian squeeze worked like a charm. Essentially, I needed to
build an installer USB stick with the netinstall image, then I could use the
switched LAN connection to a local Debian mirror at the university network.
However you should know that the WLAN connection requires a non-free firmware,
so if you plan to install with WLAN only, you need to get the package on your
install thumbdrive.

The rest worked out of the box, and I directly went to unstable + some
stuff from experimental. The only thing not working I've found so far are some
special buttons (presentation mode, but also toggle wireless!) - but they are
already reported by the kernel als "unknown key", so this will eventually
be added.

As for battery life, GNOME currently says I'll get around 8 hours of
use with wireless, medium (but good) brightness and "blog" use. Charts
indicate I'm at around 6 Watt. (Unless using some OpenGL screensaver, which
seems to cost more than 1 Watt extra!)

So here's my current summary:

+ well supported by Linux

+ 2 GB of RAM

+ battery life, low power consumption

+ wireless much better than on my old laptop

+ good display (gloss free, good brightness, 1024x600)

- the webcam is dead weight, it's completely useless (crappy quality)

- there is no UMTS, which many business people will complain about

- screen resolution could be higher; I really like high resolutions!

- Intel IGP can't do FullHD, but I have a FullHD external monitor

The one thing I really don't get about this laptop is why they added this
ridiciulously bad webcam.

UPDATE: the bug is already fixed after a few hours, and only affected a
minority of users (of a now deprecated, experimental option in the 'unstable'
distribution, and only users that rebooted with the affected version).

The sysvinit version that
hit unstable today has
a grave
bug if you have been running "startpar" or maybe "shell" style parallel
booting. Read this bug report, if you have been using these (they were
not enabled by default, so unless you've been giving parallel boot a try
before, you should be ok.)

How to check if you are affected:

grep CONCURRENCY /etc/default/rcS

If this command says "startpar", then you ARE affected. If it says "shell"
you MIGHT be affected. If you have not set CONCURRENCY or if it's "none"
or "makefile", then you should be ok (according to the bug).

The workaround is as simple: just put either "none" or "makefile" in there,
these are the only two values that are still distinct.

How to recover a broken system:

Boot recovery mode aka "single-user". At some point you should be
asked for the root password. Login.

Run mount -o remount,rw / to enable write mode on your disk.

$EDITOR /etc/default/rcS and change the value of "CUNCURRENCY"

reboot

You should have a working system again.

I can only confirm that changing "startpar" to "none" helped me. I havn't tried
"makefile" yet, and "none" seemed more likely to fix things.

Unless someone drops in as new maintainer, I'll file for removal of
ModLogAn from Debian soon.

The software has been abandoned upstream for, well, a couple of years. It still
works okayish (just the patterns need refreshing), and in fact I'm still
running it. But there is plenty of software to replace it, and it seems as
if many people go the Google Analytics way today.

Please speak up quickly if you care about ModLogAn, otherwise it's gone from
Debian soon.

is a great game, with a unique
mixture of puzzles with mouse skills and action. If you know the discontinued
game Oxyd originally on the
Atari ST in the 90s (also on Amiga and one version on DOS), then you know the
principle of Enigma. Except that it has tons of more levels and is Open Source.

Some weeks ago, I uploaded a 1.10 pre-release (approximately milestone 5) to
Debian experimental. This is the soon-to-be-released new version, using a new
level file format (with a much extended API to make level development even
easier, ~50% less code per level now), new levels (of course), updated
graphics (including support for new graphics modes), ...

Unstable still contains version 1.01; the reason is simple that I knew there
would be another 1.01 maintainance release coming. However I believe it
doesn't offer much against the current unstable version; it largely marks
an upstream release containing patches already in the Debian package (since
communication with upstream is really good).

So I have now two choices: refreshing the Debian unstable package to the
"probably last" 1.01 release upstream, or going straight for the 1.10
milestones to give enigma some extra testing.

So far, we have quite few applications. Deadline is April 3rd, 19:00
UTC. Usually applications arrive rather late, but still I have the impression
that we have much less than the previous years. But less copy & paste, too.

Congratulations to all developers (DDs or not, we have sponsored uploads,
Debian contributors and such, too!) who contributed to the release of Debian
GNU/Linux "lenny" 5.0. I must admit that I've been largely inactive recently,
I just managed to keep the bugs on my remaining packages low. Funnily, just
the day lenny was released I learned about a bug in Enigma on AMD64 that is
probably worth fixing through proposed updates ...

Xorg 1.4 in experimental is supposed to have input device hotplugging.

Does anyone have a Howto for Debian? I tried it, but I couldn't get it to
hot-plug my USB mouse, so I'm back to using the regular mouse driver for it
again, using the /dev/input/mice in-kernel-hack for hotplugging.

P.S. on a recent kernel, you might want to add

blacklist snd_pcsp

to a custom file in /etc/modutils/, in order to avoid your PC speaker
showing up as regular audio device. You don't want your regular apps to
consider your legacy PC speaker as audio device usually.

Today, I uploaded a new version of my firewall configuration tool,
pyroman, to Debian
unstable.

About 4 hours later I googled for "Pyroman Debian" and was surprised to find
the upload notification in the top results. The first hour of this was probably
spent with me doing some package function tests (I don't want to upload broken
packages, after all), then the announcement was distributed to the -changes
mailing list at Debian, which in turn was picked up by Google Groups.

However that might be due to groups.google.com getting special treatment,
though. For this resource, Google can actually trigger an update instead of
having to have a spider frequently re-crawl all the contents.

Still I find it pretty impressive to have such new data already in their
main index. I was used to this e.g. for blog and news search, but not for
regular web search.

[Yes, this post was written on
April 1st and is
not to be taken serious.]

The usability experts of Ubuntu have finally started to handle the single
most mentioned usability issue with Linux: the top level directory names.

Quoting Finn C. Tional from the Ubuntu Usability Group:

It's one of the mysteries of Unix that the directory named "usr" is not for
user data, and the directory named "etc" while looking like random stuff thrown
together stores all the important config files. [...] This is probably the
single most confusing hurdle for new Unix users. [...] We need to finally
tackle this, before people are too used to these odd directory names.

They'll include a patch for the GNU C library as well as for AppArmor to
redirect the old path names to the new ones. Given the existing filename
matching already done by AppArmor the overhead is expected to be neglible at
least for AppArmor enabled systems. SELinux enabled systems will remain
unchanged, since the user won't be allowed to see anything potentially
irritating in the root directory anyway, but will be confined to his user
directory.

Since there are a dozen applications that will need changes to accomodate the
new naming scheme, expect these changes only to be included with
Ubuntu 10.4 (also lovingly named Ubuntu X) scheduled for April 2010.

Other distributions are expected to follow up with these changes in 2011.

P.S. Yeah, the Ubuntu folks really need to think this throuh some more.
Russel pointed out that "My System" is even easier to understand; after all
this is not about someone elses system or some systematic error or whatever.
I figure he's right. How about "My Computer" than this lowercase (pessimistic?) "system" directory they're proposing there!

So far, we have rather few applications - much less than last year. This
doesn't seem specific to Debian, other organizations have also been reporting
fewer applications, and Google is considering a deadline extension. Maybe the
low number is related to Easter holidays. Also at least at my university the
summer term will start only on April 1st, just past the deadline. So many
students probably are still away in holiday.

Anyway: if you are interested in participating in the Google Summer of Code,
chances are still pretty good. We don't have too many applications yet; not
even all of the projects on the
Wiki Ideas page have
received a submission yet, only a few have received more than one; and even
with those a well-written submission standas a good chance. Also some new ideas
have been added in the meantime.

In particular missing from our submissions list are:

MergeMaster port

debexpo

CDD webtools

security policy

(see the Wiki page for details on these projects).

Especially the lack of a submission for the MergeMaster port is surprising.
Many people would love to see a good configuration file merging tool in Debian.
I can only guess that people are thinking "awh, everybody is going to submit
an application for this one, I don't have a chance here". You currenlty DO
have a chance, because there is no single proposal in for this one yet!

If you have any questions, IRC channel #debian-soc in OFTC is pretty useful.

Navigation:

I agreeThis website uses cookies to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners. See details