Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Comment Re:Free speech zone (Score 1) 281 281

So have 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.

You will find he has read all the classic Unix books, and unlike most others actually studied Unix variants and Unix code beside Linux.

All the systemd tools are made with regards to classic Unix philosophy, they only do one thing and they do it it well, they aren't chatty when scripted, doesn't report success (error code 0) as default, aren't interactive, etc. You often see Poettering quoting directly or indirectly from Ken Thomson et al. on the systemd mailing list. systemd closely follows classic Unix tradition where it actually makes sense.

You are severely underestimating his abilities; making a program like Pulseaudio, a middle-ware layer between the kernel/ALSA stack and userspace, was insanely difficult, but an instant success that solved many real world problems that especially DE developers had, and that made it default on all major Linux distros early on.

Yeah, I know some people likes to claim that PA doesn't work on their broken distro, but the fact is that no one has ever even tried to replicate what PA does, even now where all the ALSA/kernel driver bugs have been shaken out.

The fact is that PA was both well done and brilliantly pulled off. And it wasn't a "lets rewrite everything from scratch, including every sound card driver in the kernel" solution, but a solution that maximized existing work and with a smooth transition with no "flag day".

Same with systemd; using Fedora the transition from Upstart to systemd was really smooth; no "flag day" where either only systemd or sysvinit scripts worked, all the usual commands like telinit or "shutdown -h now" still worked, and all the SysVinit scripts worked too.
It really is impressive how smooth the technical transition to systemd went on RHEL, Fedora, Suse, Arch and Debian, despite it replacing several different init-systems and rather different environments.

Then sometimes he makes amusing rookie mistakes. So that's where he is as a programmer: good code, poor design.

systemd is really portable across architectures, which is the important bit for Linux. That you can't easily port it to BSD is totally irrelevant : systemd is GPL/LGPL so it can't be close sourced and therefore it will never be adopted by BSD since close sourcing software is what pays their developers.

Anyway, you can't port BSD system software to directly Linux either; it isn't made that way, neither are official system software from Unices like Solaris. The "Unix wars" are over; Linux and Open source won, the proprietary Unices have been delegated to tiny niche domains. It makes no sense whatsoever to make systemd portable to SCO Unix, or AIX.

I saw an interesting comment from Poettering regarding OpenSSL code pre-Heartbleed; he found it abysmal. And it is exactly "Heartbleed" style bugs they want to avoid, where someone drops a turd of a patch into the repo that circumvent security measures, just so some proprietary close source Unix can avoid upgrading its libraries.

Anyway, I think you are severely underestimating his abilities as software architect; he has at least 3 major projects under his belt that now all are part of every major Linux distro. Two of those projects so inherently hard that many developers had given up trying to solve the problems.

Comment Re:Free speech zone (Score 1) 281 281

SysVinit style scripts will hang around for at least a decade more.

Enterprise systemd adaptation will probably be slow in the beginning. Still, it is interesting that RHEL 7.2 will be rebased on systemd 219 simply because customers are demanding newer OS container support and systemd networking.

While some shops never upgrade (I once found a MicroSoft Xenix (Unix) server at a customer a decade after it was deprecated), I think systemd's security features and OS container technology will make it dominate every aspect of the future enterprise market.

Comment Re:Free speech zone (Score 1) 281 281

My advice to you is to stop running with the anti-systemd pack; they won't help pay your bills if getting a new job is difficult because your skills are outdated, and since 100% of all commercial distros are going systemd, that is core skill to master.

I can read code. When systemd writes good code, I'll support it.

Don't give me that crap; the systemd developers are proficient and experienced Linux developers. Poettering has a CS degree and has coded Linux for +10 years now, he really knows his stuff. I have yet to see a single named OSS developer with the proper domain knowledge saying systemd is badly coded. What the systemd developers are doing is seriously hardcore too, from OS containers to session management. Btw, if you are looking for code documentation, don't just stare at the code, read the man pages too (like man sd_notify) and the systemd homepage too; it also contains developer information.

As I said, I have seen many people commit professional suicide before, refusing to learn new stuff. I guess people burn out and wants to stop the world.

Not studying systemd is simply professional suicide when it comes to Linux. Sure there will be SysVinit/Upstart gigs for years to come, but the choices will be fewer, the pay lower for every year, and suddenly you are out of work and have no experience with modern Linux management or development. Good luck telling the prospective employer at a job interview, that you "refuse to learn systemd, because you don't like the coding style/Once read a blog post claiming it wasn't designed the Unix way etc."

Comment Re:Free speech zone (Score 3, Informative) 281 281

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 is seriously good stuff with awesome technology. It is not that I haven't experienced resistance to change over the years in tech: networking guys who trash talked twisted pair ethernet ("It got no collision detection, it will never scale"), tcp/ip ("It isn't an OSI stack, it will never scale, use ATM/whatever instead"), OO-programming, desktop GUI's. I have seen people clinging to DOS, Win 3.11WfG, OS/2 (which was a nice OS) whatever technology long after it was obsolete, ranting about how the new stuff was bad.

Mind you, I am not talking about end users, but allegedly professionals who where making a living in tech. In the end they all ejected themselves out of the tech industry because the old gigs dried up and their skills where obsolete.

My advice to you is to stop running with the anti-systemd pack; they won't help pay your bills if getting a new job is difficult because your skills are outdated, and since 100% of all commercial distros are going systemd, that is core skill to master.

Even if your present Linux job doesn't seem to require systemd, some day the boss will come and say; "We need RHEL 7.3 with systemd because of OS containers, and we need it yesterday".

The smart ones of you colleagues have foreseen that scenario, and secretly boned up on systemd, so they can say "Yes sir! Can do! I am a systemd expert, so how about a promotion and bonus?".

Comment Re:People who like systemd (Score 2) 281 281

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.
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:

Here is how they used systemd to patch Heartbleed without rebooting (they were running 5000 nginx instances on one box):

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.

Comment Re:Startup management subsystem (Score 1) 281 281

I wonder which Berlin is in November? I've never been there myself.

Berlin is always worth a visit. Late November in German cities are nice, since you will find small booths selling "Glühwein" and various food (like sausages) everywhere.
While Berlin is nice in the summer with its biergartens, trees and sailing on the Spree, they have top notch museums too, like everything in the "museumsinsel/ Museum Island".

Comment Re:Free speech zone (Score 1) 281 281

You simply can't get the same features such as multi-seat without such integration.

There was multi-seat X before there was systemd. How can it be that you can't have multi-seat without such integration?

multi-seat X haven't worked securely for decades. The main problem is actual in the Linux kernel, especially the way it handles devices in a multi-user environment. That is the same reason that while it has been possible to run root-less X on Linux for many years, it wasn't safe in a multi-user environment until systemd made it possible.
There isn't a "revoke privileges" kernel feature either despite years of trying (it is a hard problem).

That means userspace have to have a sophisticated session manager like logind with kernel integration in order to keep the multi-seat sessions safe.

Comment Re:Free speech zone (Score 1) 281 281

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.

The DE's really do depend on the OS layers below, there is no way around that. And systemd is exactly such an OS layer, or plumbing system if you like. It is exactly meant to provide service to userland programs like Gnome/KDE/LXQt. And having multi-seat capabilites and proper session management really require deep OS integration like cgroups.

It is poor design _not_ to provide such a unified and coherent OS layer for userland.

I discuss that here. If you think I am misinformed, I will look into it more deeply.

You are. Check out CK2, or the history of Ubuntu's shim. It was originally Canonical who was handed over the CK project, but they apparently thought the same as the CK2 maintainer, that the CK API sucked and Poettering's logind API didn't, and therefore cloned it into "systemd-shim" instead.

Sure, none of the API alternatives are full replacements since that would require a level of kernel and system integration only systemd provides, so no multi-seat etc. But the latest I read from Gnome's Olav Vitter's was that they would try to support the subset of features that the alternatives could support.
So in the future Gnome will support the systemd-API, not the CK API, just like CK2, systemBSD's logind etc does.

The latter of course depend on somebody doing some actual work instead of just complaining or spreading misinformation.

Comment Re:Startup management subsystem (Score 4, Informative) 281 281

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.

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.

Comment Re:Free speech zone (Score 1) 281 281

Yes it does. You can't separate logind from systemd (although that would be good software engineering, if they were separable). The systemd-logind API is deeply integrated into systemd. It shouldn't be, but it is.

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). The CK2 developers abandoned the old CK API in favor of the systemd API, simply because the systemd-logind API developed by Lennart Poettering is much nicer

There are actual good technical reasons why systemd is made like it is and why systemd-logind is part of the systemd project. You simply can't get the same features such as multi-seat without such integration.

The problem seems to be that you didn't read any of my posts that I linked to earlier. From what you've written, it doesn't even seem like you understand systemd very well. Yet somehow you are a huge proponent of systemd. I don't know. What do you like about it? That's a serious question.

systemd is a massive security increase compared to any other init-system out there, simple because it integrates Namespace isolation, Cgroups and Capabilities(7).

Daemon service files are in structured text format, instead of spaghetti code in executable files like Sysvinit/OpenRC.

Daemon service management vastly superior to anything else on Linux/Unix.

Comment Re:Free speech zone (Score 3, Informative) 281 281

>* 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.

Comment Re:Startup management subsystem (Score 2, Insightful) 281 281

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.

Comment Re:Startup management subsystem (Score 0) 281 281

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

Sure, all progress is bad; Linux should be a 1986 Unix clone, there should be no new code blah blah blah.

There is nothing wrong with open source developers meeting up, talk and code. You probably agree to that, but your irrational emotionally driven hatred to systemd makes you post snarky remarks like the above.

What is really funny though, is that you systemd-opponents never realized how your hurt your own cause by negative campaigning; You are trying to "poison the systemd well", but you end up poisoning your own well too; From now on, the non-systemd developers can't make a conference working for non-systemd init-systems, because according to you, it isn't needed.

You guys are dragging yourself down with all the negative attitudes towards developers making progress.

1.79 x 10^12 furlongs per fortnight -- it's not just a good idea, it's the law!