Point 2, my segmenter and my pulse in support got merged by Michael when they were still a draft in my github, other funny lumps of not so perfectly working pieces of code could be the pink-tinted j2k decoder.

Point 3, we have a strict review process, it is not perfect for sure, but gives us a good layer to avoid a number of mishaps, features are usually discussed and from the people feedback they get refined and improved. Currently we are splitting the dsputil little by little so we could cut down the compile time on multicore systems, make easier convert the asm optimization to yasm for the delight of the poor souls needing to use msvc, and make adding codecs such dirac not a partial hack. It is taking lots of time, but we are making it happen.

I’m so glad there is so much discussion going on, as a user, it makes me feel like the developers actually really do care about the result and how the end user will feel about it. Not common in all distributions.

This is only a consequence of libav developers not caring about FFmpeg but FFmpeg trying to be API and ABI compatible IMHO. We’d be in great trouble if both projects simply ignored each other when it comes to the API.

- FFmpeg follows adding bits here and there to “diversify”
- FFmpeg goes by leaps to add MORE features, no matter what (including picking wip branches from my personal github and merging them before they are ready…)
- Libav is more careful, thus having less fringe features and focusing more polishing before landing new stuff.

I’m interested in these three: Could you please add some links and explanations?

I’m typing this on a Thinkpad T400 laptop on kernel 3.2.1 and KDE 4.7 with Gentoo stable and am delighted in how well it works.

The whole discussion about systemd, udev versions above 173, and the need to use initrd’s has taken on the tenor of the debate around health-care reform here in the United States. Those on either side of the question focus their main attention on aspects that the debate that people on the opposite side find to be rather unimportant. There is a lot of name-calling all the way around, and the whole question has now come before the Supreme Court. I certainly am not trying to bring that debate to this forum, so please refrain from taking up a position on it here! My whole point is that we have become that intensely vitriolic about these system-initialization issues, and we don’t have a Supreme Court to hear any appeals. We have to work it out for ourselves.

Now to the discussion at hand. Yes, I misidentified the position of the init task; it is indeed PID 1, not 0. That said, it is *still* the process with no backstop. I’ve not been suffering from random crashes of the init task and I’m hoping that life continues like that.

When I first read some of Lennart Poettering wrote about systemd, I was pretty intrigued by the idea of having the daemons quietly block during their initializations as a way to let them all start in parallel but with systemd mediating things so that they would all sort themselves out without needing any explicit declarations of what depends on what else. I even started to make a suggestion for patching the kernel to support the special handling of sockets. (Incidently, contrary to Fickmaus’ point (h), Mr. Poettering, from his very first blog post on systemd, often points to fast boot times as a motivation behind systemd.)

It was when I looked more deeply into the details that I got concerned. There have to be odd tricks involved to pass sockets around between systemd and daemons. (Yes, the suggestion I started to make would fall in that category.) Because now systemd wants to be able to restart services that crash without data loss, it has to listen on the sockets all the time. So far as I can tell, for certain services it is necessary for systemd to create secondary sockets to pass to daemons and then copy data from one socket to another as the daemons handle requests. It handles mounting filesystems and setting user quotas. It wants to be your crond and do logging. Yes, I can follow the logic for adding each of these capabilities. It is when I look back on it and realize how large and all-encompassing the project becomes, things get very worrisome. Also, as systemd development runs up against things like shutdown problems, odd corner cases in daemons, or being confused by the absence of udev inside of LXC guests, it grows ever more complicated. I don’t know about you, but long experience has taught me that software systems that try to do too much are prone to failure.

(One note: so far as I have been able to tell from the examples of process listings on Mr. Poettering’s 0pointer.de site, there is only a single systemd process. There are lots of entries contained in CGroups in the /systemd-1/ tree, but those are for the spawned daemons, not actual systemd processes. So, One Task to crash them all, One Task to bind them.)

The Linux kernel is also a very large and comprehensive project, but it has a careful development process, hundreds of developers, a great deal of oversight and testing, and very importantly, a long track record. Systemd hasn’t gone even two years since its first release and more than half of its work is the product of a single developer. This might not be such an issue except for the very large risk-exposure surface the software presents.

What compounds the worry about systemd is that the /usr-move proposal is coming at the same time. Though neither of these initiatives depend on the other, it sure seems like the people leading the charge for the one are also very enthusiastic about the other.

I’ve never had to worry much about system initialization, or crons, or logging, or the operation of the mounter, which is great because I have other fish to fry. What I can see, though, are the looming headaches I’d rather avoid. I keep trying to work out issues with things like LXC, KDE, PHP, and Apache; I *don’t* want also to have to figure out why fundamental systems have gone south. Look at KDE: finally, by version 4.7, things that were uprooted after the 3.5 series are settling down and working pretty well, and that’s after four years of sweat by dozens of developers (well, there are more issues, but those aren’t for this thread either). Now here comes a new system making many promises yet it takes over so much of the system and wants everyone to be assimilated. With desktop environments there are choices, as there have been for system services. We like our choices.

As Luca points out, the push with systemd and the /usr move would take away our choices: move now or be swept behind.

Here’s an odd suggestion about the /usr move. I don’t claim expertise about it, and I certainly don’t have any idea about how it would work out in practice. It might be completely unworkable, but here it goes: have Portage be able to override the build prefix on a per-package basis. For those special packages you need to have in /bin or /sbin to boot without an initrd and thus you don’t want moved into /usr (or indeed you would like to move out of /usr for the same reason), you could set the prefix for that package. This is not a shove-it-down-your-throat suggestion: the individual Gentoo administrator could choose to use this depending on his or her needs.