Lennart Poettering Announces the First Systemd Conference

jones_supa writes: Lennart Poettering, the creator of the controversial init system and service manager for Linux-based operating systems has announced the first systemd conference. The systemd.conf will take place November 5-7, in Berlin, Germany. systemd developers and hackers, DevOps professionals, and Linux distribution packagers will be able to attend various workshops, as well as to collaborate with their fellow developers and plan the future of the project. Attendees will also be able to participate in an extended hackfest event, as well as numerous presentations held by important names in the systemd project, including Poettering himself.

Comments

Startup management subsystem

[QuietLagoon]

If a startup management subsystem needs its own conference, it is doing too much.

Re:Startup management subsystem

[Peter H.S.]

You could refute that trivially by clearly stating what problem it actually solves. Yet you chose not to do that.

systemd solves many old Linux problems; besides the technical ones like proper service management, it also solves the problem with fossilized development of subsystems like init and logging, and solves the old problem of lack of coordination between userland, kernel space, and the plumbing layer between.

systemd, as init and process manager, actually takes on the coordination responsibility that lacked previously. It is way cool how "namespace" isolation and kernel Capabilities(7) are integrated so system admins can turn on such security features just by adding a Boolean value in a text file. It also means that every iteration of systemd distros become ever more hardened per default, making ever more difficult for the the black hats to gain privilege escalation.

By dismissing every systemd feature and everything systemd does as "bad", systemd-opponents like you paint yourself and all your fellow travelers into an ever smaller corner, where "SysVinit/OpenRC" is the pinnacle of evolution without ever needing more features.

Good luck with that.

Re: Piss off systemd

[drinkypoo]

Ah, but with every single major distro adopting it, you better quit crying and get used to it, buddy!

They changed to systemd, they can change away just as well. Oh sure, the systemd cancer has spread to many daemons, but it can be excised from them as well. (Ironically, the daemons need exorcism...)

Re:Free speech zone

[Peter H.S.]

>* Scope creep (there is no reason Gnome should depend on systemd).

Gnome doesn't depend on systemd as such, but on the systemd-logind API. Until recently (perhaps it still does) it also supported the old ConsolKit API as alternative even though CK had been dead for +1½ year with no upstream bug fixing or security support, and no one bothered to maintain it anyway.

The problem seems to be that the systemd-opponents really don't understand how Open Source software works and being developed, something that requires coordination, and positive contributions with either code, documentation, or money.

Claiming that the systemd developers are incompetent and doesn't understand software development will get you nowhere. You have to employ your superior knowledge into actual competing projects in order to be taken seriously. But that is the problem isn't it? The total lack of effort by the systemd-opponents to actually create something useful.

Re: Piss off systemd

[Microlith]

Yeah, it'll be so terrible because... because...

Can you explain why this is a bad thing? Or is this another purely emotional "I don't like it!" tantrum?

Re:Piss off systemd

[Anonymous Coward]

Actually, Debian should have been forked to include systemd, not forked to exclude it!

That's the whole point of forking. You fork, do experimental stuff like integrate systemd in this fork, and then throw the fork away when it becomes clear that the idea was a dumb one.

When done sensibly like that, the source is left unaffected by experimentation that proves to be disastrous.

Debian users could have continued to use a stable, sane, reliable, trustworthy system, like they've been accustomed to for a couple of decades now.

Those who want newfangled and unproven doodads and curiosities could have used the systemd fork of Debian. When they got bored, or suffered from one failure after another, they could always limp back to Debian.

Re:systemd is the best init system for FreeBSD.

[JSG]

"(sorry, Slackware, you're a relic; Gentoo, you're impractical)"

Sorry AC , you don't get it: It doesn't matter whether 1 or 1 billion people use a distro, they are exercising their choice - their ability to choose what they want. That is the most powerful aspect of free software whether it be Gentoo, Slack, Yggdrasil (my first), *BSD or whatever.

YOU GET A FUCKING CHOICE OF WHAT OS TO PUT ON YOUR COMPUTER.

Your insinuation that FreeBSD will somehow slide into the breech to replace Linux is almost as laughable as this being the year of Linux on the Desktop.

BTW I use Gentoo quite a lot (50 odd systems) and they all have pid 1 == systemd ...

Cheers
Jon

Re:Ah, Berlin

[Dutch Gun]

I really don't get the fetish for text file configuration that Linux has.

Text is attractive because it's a least-common-denominator and *universal* format. However inconvenient it may be to parse and organize, you can write a reasonably simple script to do it, and you can pipe it through just about any command to transform or process it in whatever way you want. With text, you never have to worry about a black box of a file, because it's always human-readable, and thus more amenable to hacking.

The downside for log files is that text-based formats are incredibly inefficient as backing stores for any substantial amount of data. And as a configuration format, it's incredibly difficult to write front-end configuration software for scripts, although less so with regular formats like json or xml. Once the configuration is in a script, automated management of that configuration pretty much goes out the window - you're essentially committed to maintaining scripts by hand. This is not a problem for system administrators or advanced users, but horrible for normal users and GUI systems.

There are legitimate points on both sides, and which side you come down on may depend on your primary use case.