Slashdot Mirror
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.
Nobody needs it.
If a startup management subsystem needs its own conference, it is doing too much.
This fight is not over. From all the error-reports on the mailing-lists of the distros that have started using systemd, at the moment the only thing the opponents need to do is watch the fireworks and occasionally remind people that there are superior init systems and service managers.
We will see how this plays out. I expect there will be some rather quiet reversal in several distros in the not too distant future. And if not, there is no real need to have a Linux kernel under a GNU system. I also see no really serious problems keeping SYSVinit going. The only hurdle seems to be udev, but there is eudev and if that does not work out, I never really had any need of udev in the first place. Overall, it probably cost me more time than it saved. I may just go back to ultra-reliable static device files.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
>* 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.
I really don't get the fetish for text file configuration that Linux has.
And that's why you, and people like you, persist in trying to ruin Linux. You don't understand why it's successful.
The ones I hated the most were init scripts that were common a few years ago which every source on the internet said "they're just like shell scripts," but they clearly weren't as there were commands in there about dependancies and somehow the same script managed starting a service and stopping it, but no one had documented the syntax anywhere because they thought it was too easy, and as a result, it was an init system I never used.
Just admit it: you don't understand shell scripts. Once you admit that, life will become a lot easier. You'll pick up a book on the subject, perhaps, or you'll read some websites. Then you'll learn how to read the scripts, and figure out where they're getting those "commands" that don't appear in the filesystem, not even when you use find instead of which. You'll see that they source a library at the top of the init script, and you'll follow up and read that library and you'll figure out how those variables at the top of the script which handle dependencies work. And then you'll see that there is really no need for systemd; cgroups support could have been added to those shell scripts, for example.
but nearly all text configurations suck, e.g. if you want to change a setting for which there isn't an example, you then have to spend hours reading the manual and testing ideas to figure out how to type something up which the software will parse as commands to make it do what you want. If the software had a GUI configuration tool like virtually every piece of modern software has, you could just look through a few logically-named tabs until you found the option you need, then just check the box beside it
Binary configuration files don't solve this problem! They don't magically make GUI configuration dialogs appear! Many Unix programs have complicated configuration files with no GUI to configure them because what they do is complicated, and a GUI capable of fully configuring them would also be very complicated. You're not going to automagically get GUI config tools for all those programs. If you outlawed ASCII, human-readable config files tomorrow, what you would actually have is a hodgepodge of different binary configuration file formats, each with their own inscrutable command-line tool for manipulating them.
It's also worth noting that many if not most windows programs have text configuration files! So, are you trolling, or do you really not understand that this is not the point of contention? It's over binary log files, not config files! Even systemd has ASCII configuration files! For now, anyway...
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
systemd has proven itself to be the best init system for FreeBSD.
The use of systemd by default in Debian, along with pretty much every other major Linux distro (sorry, Slackware, you're a relic; Gentoo, you're impractical) has driven away the best Linux admins and developers there are.
These are the men and women who run important servers that must fully boot each and every time. They're the people who develop critical software that always needs to work. The kinds of bugs that systemd has shown to have just aren't acceptable for these users.
After seeing the quality standards of so many Linux distros drop to unacceptable levels all thanks to systemd, these people have been forced to find better alternatives.
FreeBSD, and to a lesser extent OpenBSD, have been where they've fled. These are robust systems that are often equal in capability to Linux, but with much greater stability, and a team of developers who have their priorities straight. They will not compromise their software like so many Linux distros have done.
FreeBSD now boasts some of the best sysadmins and users among its ranks. It's seeing more and more use by people who know what they're doing, and who are doing very demanding work.
The future is brighter than ever for FreeBSD, while the future is looking dimmer and dimmer for Linux. It didn't have to be this way; Linux would still be a perfectly fine option for these users, had so many distros not been infected by systemd.
Historians will note that it wasn't Microsoft or SCO or any other external attacker that destroyed Linux. The Linux distros destroyed themselves, and their usability, by including systemd.
Maturity isn't really about age, but of total development hours. Popularity matters, because it helps to attract contributing developers, and more can be done in a shorter amount of time. Because of it's popularity, I think it's probably fair to say that Linux has matured faster than FreeBSD. As a counter-example, GNU/Hurd has been in development for fifteen years and is still not ready for prime time at version 0.6.
Irony: Agile development has too much intertia to be abandoned now.
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.
Irony: Agile development has too much intertia to be abandoned now.
Don't give me that crap;
STFU? Anyone can insult, it doesn't make your point stronger.
Poettering has a CS degree and has coded Linux for +10 years now,
So have I......so what? When Poettering writes straight code, it's pretty good. I would be happy to have him as a coworker. The problem is when he starts architecting, that's where he lacks skill. He would be wise to read some basic documents on the topic.
Then sometimes he makes amusing rookie mistakes. So that's where he is as a programmer: good code, poor design.
Not studying systemd is simply professional suicide when it comes to Linux.
Thanks, I appreciate the concern. I don't make money based on my ability to use whatever software, I make my money designing good software. Although I've spent plenty of time studying systemd, so my career is safe.
btw, that points to the difference between people who like systemd, and people who don't. Those who favor it tend to look at the features, and say they are decent. Those who dislike it tend to look at the design, and say, "that's kind of wonky." A person can hold both opinions, they are not logically inconsistent. Unit files clearly fill a need people have.
"First they came for the slanderers and i said nothing."