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.
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.
A binary file avoids the need to have a bloated text parsing engine.
It doesn't do that, because all the data is interpreted by humans as text, and has to be presented to them as such. It also has to be understood as text, so if the journal processing tools do any of the things that systemd proponents claim they do, they will need a "bloated" text parsing engine.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
We are systemd. Lower your MBR protection and surrender your init system. We will add your daemons, libraries, and utilities to our own. Your code will adapt to service us. Resistance is futile.
Get free satoshi (Bitcoin) and Dogecoins
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...)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
all we need is a nice little bomb... We know when and where they will be - take out their leaders and we can move on to something useful!
I am currently porting multiple RHEL 5/6 servers over to other distros without systemd. Going to RHEL7 is just not a viable option for us.
Similar for workstations, where we have stopped ordering Dell N systems with Red Hat, and instead order them with Ubuntu (which we then wipe out - Ubuntu just because it's the cheapest option).
We have multiple in-house daemons, devices and mounts that need to start, stop, and yes, crash without an overseer interfering. Not handing off control is a must. Humanly readable logging is a must. No chance of a buggy startup process taking out the entire startup is a must. Not having buggy software auto-restarted is a must - if we wanted that, we'd use inittab. That we don't mean that we don't.
The amount of red hat subscriptions we have has gone down by around half since RHEL7 was releaseds. This is not a coincidence. Red Hat seems to still be on the cloud bandwagon and thinks that we'll eventually buy their cloud services. Sorry, but disregarding your customers' explicit requirements does not make that exceedingly likely.
Even IBM has abandoned ship, and gotten out of the business of selling RH systems. That this occurred when RH switched to systemd is not only a coincidence. They saw the devil on the wall and pulled out of the certified midrange market at the right time.
They will not invite someone to speak on that, but that is something I'm working on.
In brief, the good:
* Systemd makes it easier for distro maintainers to write startup scripts, which is something a lot of them wanted.
The bad:
* Poor understanding of interfaces by the lead developers.
* Poor understanding of portability by the lead developers.
* Poor understanding of separation of concerns.
* Scope creep (there is no reason Gnome should depend on systemd).
* Binary files are a symptom of idiocy......more specifically, binary/text is not something that should be decided by the init system.
"First they came for the slanderers and i said nothing."
>* 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 conference -- you're going whether you want to or not.
There are actual good technical reasons why systemd is made like it is and why systemd-logind is part of the systemd project.
There are no good technical reasons. Having a window manager depend on a particular startup manager is poor design, there's no way around that.
You are misinformed. CK2 and systemd-shim are alternative implementations of the systemd-logind API (or at least the subset of the API Gnome/KDE actually need).
I discuss that here. If you think I am misinformed, I will look into it more deeply.
"First they came for the slanderers and i said nothing."
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?
It seems to me that a systemd conference wouldn't be much different from a BDSM convention.
The BDSM convention will have a higher percentage of protected sex, and nearly everyone getting screwed will be doing so consensually. Most of them will have a good sense of humor about what they are doing, heavy D/S tops aside.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Whew, it's a good thing that you're posting your full real name, "Microlith", and not some sort of a pseudonym! Otherwise we'd have to think that you're posting anonymously, like some sort of a coward.
That aside, the problems with systemd are well-known. There's nothing "knee-jerk" about standing against it.
We really shouldn't have to rehash the problems with systemd each and every time it comes up. We know what the problems are. Its philosophy is backward. Its architecture is full of bad ideas (binary logging being a huge one). Its implementation and the integration of it with distros, especially Debian, has been rife with severe problems. Many, many people have had many hours of time wasted fixing utterly stupid problems caused by systemd. Other software developed by many of the same people, notably PulseAudio and Avahi, have caused similar severe problems for most of their users. It has been forced upon unwilling victims, which in the case of Debian has caused significant damage to the social structure of the project. It has caused many Linux users and admins to lose trust in the major Linux distros that have switched to it. And that's just a high level overview of just some of its problems!
We're past the point of identifying problems with it. We know what they are, and we know that there are too many of them. We also know that some of them are impossible to fix. You can't "fix" binary logging. You just have to get rid of it completely! That's essentially the only way that systemd as a whole can be "fixed": by totally discarding it.
Until the major Linux distros get their shit together and stop using systemd, it just won't be an option for many long-time Linux users. These users aren't in a position to deal with the problems that systemd has caused. They need software that's robust and reliable to an extent that systemd has so far not been able to come anywhere close to. So these people are moving, or have moved, their workstations and servers to the *BSDs, to Solaris, and some have even moved to Windows. You know things are bad when staunch Linux supports have come to the conclusion that Windows is actually a better option!
C'mon, this shindig will be the perfect place to showcase systemd's conference-room booking module.
Just cruising through this digital world at 33 1/3 rpm...
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.
'I need you to prevent something horrible from happening in the future, Steve.' He then nodded at the TV. There was a game on and along the bottom of the screen was a stock ticker. After reading from his tablet for a moment he said, 'Jackson is gonna score on a third-down pass in a minute.'
We watched three plays and sure enough, he was right. He proceeded to call the next series exactly. 'Nice trick.' I said, 'But this broadcast must be delayed.'
'That stock ticker isn't though, is it? Check your timepiece. The market closes in ten minutes.' He then showed me the closing price for both exchanges and bought me another stout.
It must have been a wild day on Wall Street because prices were feverishly swinging up and down. But he got the final numbers, right down to the penny. 'I'm from the future.' he said.
Now you hear all sorts of crazy talk at the Z-80 Lounge. And San Francisco IS the golden cultural capital in the hearts of hippie hackers everywhere. So I figured he hacked my tablet. "You have to stop it. It's called system..." But just then, a big hand clamped over his mouth and two big guys in suits grabbed him and dragged him out so I never knew until now what he was talking about.
Sorry.
Fifty years of Yippie! 1968-2018
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.
"(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
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.
I admit I enjoy wordplay like systemd.conf, but since systemd uses binary log files shouldn't the conference be called systemd.bin?
ok, so now I'm interested. You are clearly a strong proponent of systemd (some might even say 'fanboy'). What is it about systemd that you like so much? What are the features that really help you? What inspires your advocacy?
Not really a fan boy. Actually I don't care at all what other people use as init-system. I am cool with Slackware going their own way, and I respect P. Volkerding's Linux vision, even though it isn't the same as mine.
The main reasons why I am going into the systemd debate was that I frankly was tired of all the stupid misinformation spread about it. Some of it deliberate lies, but most often it is misinformation copied from some swivel-eyed loony and then repeated again and again until people take it as truth.
My favorite example on this was the often repeated claim that Gnome had "hard dependencies on systemd" and these where "pushed/forced" into Gnome by Poettering. Just because Gnome support systemd for session management, doesn't mean it can't support an alternative too.
And in fact, Gnome did exactly that, despite that ConsolKit was dead and unsupported upstreams, they still supported it years afterwards, while pleading on various blogs and mailing lists (including Debian's) that some should either maintain CK or make an alternative. Nobody did that and the non-systemd camp can only blame themselves for that.
Perhaps one of the reasons why nobody started to make an alternative could be that so many people claimed that Gnome had hard dependencies on systemd, making it look like Gnome only cared for systemd support, so why bother. A self fulfilling prophecy.
I have been a Linux user since Slackware came on 40 floppies. I like Linux, I like the technical progress it has experienced since, and I actually remember technical discussions before year 2000 on the problems with SysVinit, and syslog and the lack of coordination of the Linux plumbing layer.
To me systemd was an answer to my prayers with what I didn't like with Linux: SysVinit (it is only simple when doing simple things, and it is only simple because it outsources complexities into daemons etc, the complexities are still there.), service management; new and inconsistent tools among each distro, and lets not forget the time wasted on grafting some service management system on top. Logging too. I had high hopes for Rsyslog when they started in 2005, and while I really respect their work, they didn't solve several of the problems they set out to solve (perhaps not incidentally many of the same problems systemd have actually solved). The reason wasn't lack of will, but total lack of coordination in Linux between userland, the OS layer (where Rsyslog belongs) and kernel.
I have always played with new tech, including ones I didn't have a need for at the moment. So when systemd came out, I actually sat down one afternoon and just started to read, and read the documentation. I then started to play around with it. It really convinced me how good systemd was, and how much potential it has.
systemd is different, and it really does require some serious studying in order to use it. You just can't wing it, even if you have loads SysVinit/Upstart experience.
There are several technical things I like about systemd and I find superior to similar solutions, especially security. But perhaps what I really like about _using_ systemd is how much the developers care for the end users. It is in the small details like awesome bash-completion, sane defaults, how everything us documented in the man-pages, there is even a manpage containing a list of all the systemd man-pages (man systemd.index ) and a reverse list of every file, config option, CLI option etc (man systemd.directives) and overview pages like "man bootup" that shows and explain the boot process. And the way they abstract away all the difficult bits into simple declarative statements that goes into structured text files. And tools like "systemd-delta" that instantly gives an overview of changed service files.
Systemd conference -- you're going whether you want to or not.
Oh for fuck sakes, you neckbeards never give up, do you?
First off, it's not a conference at all. We're just putting a few hundred people into the same room and giving talks. Just because you think that's a conference doesn't make it one. It's actually a confluence, which is something completely different that we just made up right now.
Second, nobody's forcing you to go. We're just relocating your office there for the week. If you have a problem with that, take it up with your boss. We didn't force anyone to move; we only changed the location of the building you're presently occupying.
Third, it's not one conference at all. It's just a collection of independent sessions in which a sentence is started in one session
and finished in another. But they're complete
ly independent of one another.
And why do you hate Dear Lead—er, Lennart so much? I find his work inspiring, a triumph of the will... if you will. His Kamp—er, his struggle— has been an inspiration for everyone who loves the discipline and honour of coding in der recht*cough*sorry in the Right Way. It's merely historical necessity that you unterprogrammers must be dealt with. No mercy for the dirty hippies! You cannot continue harming the purity of the FatherCode! Hail SystemD! Lebensraum for SystemD!
Crumb's Corollary: Never bring a knife to a bun fight.
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."