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

 



Forgot your password?
typodupeerror

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

OpenRC already exists, does everything we want it to do and (more importantly) nothing we *don't* want it to do.

Well, it is good to know that OpenRC is "finished" and won't get any new features in the future. Of course parallel boot have been inherently broken on OpenRC for the last 4 years which is why it isn't default and marked "experimental" and still no fix in sight. But who boots their pc anyway, or need service management, or OS containers, or ....

As such our superior knowledge can be spent in direct and vocal opposition to systemd because everything it claims to solve are issues none of its opponents consider to be actual problems.

You are just a tiny minority that have been kicked out of all major Linux distros. In the near future 80-90% of all new Linux installations will be systemd based; from supercomputers, smartphones, IVI and other embedded, to desktops and servers.

Being toxic assholes thread jumping every systemd-thread will at best only get you a shrug from the grown ups that actually make Linux software, while at worst, upstream projects may quickly find a good excuse to dump non-systemd support.

Since the anti-systemd crowd have scared away almost all Linux developers and aren't endearing themselves to upstream projects either, and have been kicked out of all major distros, maybe it is time for a little self reflection on why you lot have lost all the battles and the war too?

Maybe spewing hate against systemd isn't a winning tactic? Maybe it was a bad idea from the start and even worse now that you have to beg for mercy in order to have your non-systemd distros supported from upstream in the future?

You lot have radicalized yourself into an extreme and negative position, so please understand if the rest of the Linux community start to give you the cold shoulder.

Comment Re:People who like systemd (Score 1) 352 352

restarting process / containers and counting processes as servers but claiming to not reboot is cheating.

If you call a container a server and restart the container process you rebooted it. If you count processes as servers... well... its not.

At no point did they restart any OS containers or even physical servers, only the affected services. That meant all other services where available for their customers the whole time. Even for socket activated services that used SSL, connections where available all the time thanks to systemd buffering request on the socket.

They don't call processes "servers", since they run OS containers, not Google style process containers, so each OS containers have a number of running processes. Yeah, "container" can mean a lot of things.

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

Wow fanboy, is there anything Lennart can't do? Is there anything he touches that isn't "brilliant?"

I think the point is that he undeniable have a extremely successful Linux developer career and have now designed and implemented three major Linux subsystems of considerably complexity that is used on all major Linux distros. He really tackled extremely difficult problems head on and actually solved them.

The way he enabled systemd to be backwards compatible while still making radical changes in functionality is worth a close study for every developer group that wants their software adopted in Linux. No "flag day" at all.

All in all I would say his ability to design and architect software and being a project leader is way, way above average, and pretty much proven by his track record.

Here is an example you should be able to understand, though. Your response will show whether you blindly worship at the feet of systemd devs, or if you are capable of thinking. As you know, there were some problems with cron, it didn't handle sleep very well, for example. When you have that problem, is the answer to rewrite cron completely, or to fix cron?

You can't fix cron on Linux, this is why its core problems haven't been solved for +10-15 years. The reasons for this fossilization of an important part of the Linux plumbing system are the usual:

1. The lack of upstream: There is no upstream "cron" developer group that fixes bugs or take RFE's.

2. The recursive problem: "cron" is a collection of fragmented projects often almost abandon ware, bound together with some ancient syntax and a little Posix compliance. If you deviate from that, you new cron version won't be backwards compatible so developers/projects won't support it and distros won't use it.

3. The lack of coordination: There is no or very little cooperation between Linux distros. There are no central decision makers in Linux, that can work towards deprecation of obsolete standards and plan new ones. The latter has its upsides too, but it does mean that sometimes things can't be changed in Linux. In this case working towards a modern cron, even if it meant it wasn't completely backwards compatible.

4. Legacy setups: Deviate from classic cron and userland legacy programs and their work flow may break. Paying customers don't like that, and it means userland won't ship with any cron scripts that uses the new features.

Sure, you can make "cron-like" programs like fcron that fixes some of the problems. But first, it isn't cron, only cron-like, so lots of people will reject it. While it works on many distro's, AFAIK, it isn't default on many. In short, fcron and similar solutions will suffer from the 4 points above. No upstream project can ship a daemon with fcron-specfic scripts.

Another thing is that even improvements of cron tends just to be basic improvements of the most glaring errors. Forget for a moment the archaic "crontabs" behavior and similar: Why can't I schedule cron jobs based on inotify detecting a file change? Or when a certain disk is attached, or schedule a program _not_ to run if certain conditions are met like battery level, another program is running, a certain error-message is written in the log, or similar conditional and non-calendar based scheduling?

"cron" is based on certain assumption like calendar/time scheduling. At what point can you extent cron so it adopts new concepts while still being cron? That is the problem, because you really can't; if you fix cron, it won't be cron anymore. "cron" on Linux have for all intents and purposes been fossilized into a state from which it can never really change.

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

And actually no need for any development, as it is finished and works reliably. Apparently, systemd fanatics do not understand these concepts. But how could they, none of either is to be found in the object of their worship.

I think your attitude is rather typical for a segment of systemd-opponents that takes refuge in denial.
But good for you that you think the non-systemd Linux stack doesn't need any developers, technology progress and new code, because that is exactly what that attitude is getting you.

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

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.

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) 352 352

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) 352 352

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 5, Informative) 352 352

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) 352 352

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.

Comment Re:Startup management subsystem (Score 2) 352 352

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) 352 352

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) 352 352

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) 352 352

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.

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

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.

You will lose an important tape file.

Working...