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.
It does seem a bit much, but the systemd transition is a slow one. Many packages are still using init.d startup scripts, which means we can't take advantage of systemd's features with them.
Systemd isn't really a startup management subsystem. It's a full blown service manager. It can be set, at the user's choice, to restart services when there's a problem. It can provide detailed logs from each service.
The best part is the service descriptor files follow a standard. If all people did at this conference was convert package init scripts to systemd I would be ecstatic.
So lets pretend that we've just completed writing this code, as opposed to having just completed sabotaging it -Altera
FreeBSD has had its new binary package system for over 2 years now.
pkg install kde4
done.
Also, if you want a Fedora like experience, use PCBSD (FreeBSD + gui installer and a full set of packages by default)
But... FreeBSD by far makes the best server OS, with OpenBSD a close second. I've seen FreeBSD servers run circles around Linux servers running on identical hardware. FreeBSD has an uncanny ability to handle loads that bring Linux to its knees. Were I to run my own business, I have often said it would be Free/OpenBSD on the servers and Linux on the desktop. I've seen this setup before and it works a treat.
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.'"
You could refute that trivially by clearly stating what problem it actually solves. Yet you chose not to do that.
A Pirate and a Puritan look the same on a balance sheet.
its the systemd project, not just the service management program "systemd" - from the announcement
Call for Presentations We’d like to invite presentation proposals for systemd.conf 2015. We are looking for talks including, but not limited to the following topics: - Use Cases: systemd in today’s and tomorrow’s devices and applications, - systemd and containers, in the cloud and on servers, - systemd in distributions, - Embedded systemd, - systemd on the desktop, - Networking with systemd, - D-Bus and kdbus IPC systems, - and everything else related to systemd.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
it also solves the problem with fossilized development of subsystems like init and logging,
Not a problem, and also not actually a thing. Several competing init systems which didn't bring baggage with them already existed, but Lennart is a real NIH kind of guy so he didn't start with one of those. Stable init and log daemons are features, not bugs.
Yes, it is a "thing". The problem with the fossilization of the Linux plumbing layer meant that crucial progress was being held back. All the init-systems in use at the time where just "slightly improved SysVinit" style init-systems. They all relied on executable config scripts to manage daemons, and none of them tried to step up an take proper responsibility for the boot and init process.
Upstart was a nice pioneering effort, but not a good solution as it were. But there are still other problems; crond fx. Why can't it handle hibernation properly? Probably because it was made when Unix servers where hand grafted out of shell scripts an always on. But there is no "cron" upstream developer group that takes RFE's, and no coordination between the many fragmented crond forks and userland developers, making all new development practically impossible. It would have been freaking nice if crond could have been dragged into the modern world 10-15 years ago, but as of now, we have to use crond+at+whatever instead.
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
You do realize that cgroups is a thing you diddle with very small commandline programs, right?
You are probably thinking of the old cgroups interface, but that is being deprecated in the near future in favor of the "single writer"/"unified hierarchy" that requires a writer that abstract away the kernel cgroup API so userland doesn't use it directly.
http://www.linuxfoundation.org...
The point is that system already comes with such an abstraction layer for capabilities, namespaces and cgroups, making it trivially easy for the admin to harness their power without coding, by simply setting the value "ProtectSystem=true" in the service file, or using similar features (see man systemd.exec). Better yet, distro maintainers can lock down the daemon per default, giving "out-of-the-box" security.
There is nothing else that even comes close to the power of systemd when it comes to such security integration. The systemd security framework for these kernel technologies are not only easy for humans to read and understand, but it is machine parsable and scalable too.
To my knowledge nobody in the non-systemd camp is even working on similar ideas, or even on an alternative cgroups single writer implementation.
Not tying it to a specific log daemon is the really important part, though!
Which is _exactly_ what journald _doesn't_! You can use it together with any "syslog(3)" daemon. So if you have a legacy setup, you can use with journald and it will even enhance it by providing logging info syslog normally can't get.
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!
On the other hand, I keep hearing that systems administrators who use cloud services and are thus "administering" umpty-hojillions of "machines" enjoy systemd because reasons, but I never see a citation for that, either.
"Spotify", the music streaming service directly voiced their support for systemd on the Debian mailing list when they discussed switching to systemd.
https://lists.debian.org/debia...
Spotify have doubled the number of paying customers to 20 million (75 million users in total) since then.
Pantheon were running 500.000 systemd units in 2013:
https://pantheon.io/blog/panth...
Here is how they used systemd to patch Heartbleed without rebooting (they were running 5000 nginx instances on one box):
https://pantheon.io/blog/how-w...
And for people who don't follow every distribution's MLs, systemd sort of snuck up on us. We didn't imagine that debian would convert to systemd, for fuck's sake. Statistically nobody even imagined that until it was happening. Who would have ever thought that the one time Debian moved quickly on something, it would be something contentious?
Debian was an early systemd adopter, it just wasn't the default init-system.
I think it was pretty clear that SysVinit was dead years ago (last I looked they haven't released for 5 years, probably because the developers doesn't even have a build and test system, so only way to test a patch is to boot with it. RH and later Debian had been defacto Upstream for SysVinit for years).
Upstart was never going to be an option for Debian as long as Canonical insisted on the CLA. This left systemd as the only serious and mature init-system and Debian developers had long worked towards it being the new default init-system when some people suddenly started to make noise about it, which lead to the CTTE decision, which lead to the GR that showed how overwhelming the systemd support was among Debian Developers.
The point is that Debian had long been on its way to become a systemd distro, what the Debian Developers decided on the GR was to keep status quo and continue to work towards systemd. It was never a sudden decision, it had been years in the making.
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.