Become a fan of Slashdot on Facebook


Forgot your password?
Slashdot Deals: Deal of the Day - Pay What You Want for the Learn to Code Bundle, includes AngularJS, Python, HTML5, Ruby, and more. ×

Comment Re:Duh (Score 1) 674

> That is a good thing to keep in mind, since nobody is running systemd except by choice.

I'm afraid that's nonsense. systemd has been a penalty in work I do. If I could have more contemporary versions of Linux based daemsns and packages without systemd, such as entire LAMP stacks, I'd accept them in a moment. Debugging failed daemon startups with systemd has repeatedly proven painful, due to the binary log formats and the difficulty of deducing the actual daemon startup commands to run them in a debugger.

What you say can only mean two things: either you're making up things, or you're incompetent at what you try to do.
The fact that you're very vague about your problems, not at all like a sysadmin would be, makes me lean towards the second option.

Comment Re:David Edmundson answers your questions (Score 1) 674

changing the system time & date without root or sudo? HELLO? How is that a good idea? ntpdate then ntpd for that and the user can set the TZ environment variable in .profile if they want to.

not that the old ways are perfect, how many years have we gone without support for UTC or just no daylight savings adjustment?

Really, you people are a joke. We're talking about changing the local time through a DE, and your answer is: there is no problem, just change an environment variable (so not in the DE and the DE's session won't be aware of it) that need you to restart the DE session to be effective, or just let ntpdate then ntpd do the thing (so has nothing to with the DE, requires elevated privilege and knowledge far outside manipulating a DE UI).
HELLO? Are you understanding what people are asking here?
Oh OK, your answer to the DE is that we've gone many years without support for UTC (what nonsense is that?) so they don't need any of the thing they're asking for, you know better than them of course.

Comment Re:David Edmundson answers your questions (Score 1) 674

It doesn't matter how many pieces something is if the pieces are more or less inseparable. There's a reason all of those things are developed under the "systemd" banner. If you decide that you absolutely must have systemd without the crap you don't want, your only option is to configure and compile it yourself. If that's "modular" or "not monolithic", then I guess Windows is too.

If it were truly not monolithic, then I'd be able to install systemd's non-init stuff on a sysvinit system and vice-versa.

Thanks a lot, I just realized everything I compile on my OS is monolithic. Actually, there's not a single package on a Linux system that is not monolithic.
I'm not even talking about my DE which combine several monolithic packages. Even sysvinit was monolithic actually.
So systemd actually merges perfectly in all this monolithic mess of a system that Linux is.
Or perhaps you're wrong, because I can install systemd non-init stuff on a sysvinit system just fine.

Much, much easier solution to this problem:

1. You press suspend button

2. DE's hotkey handler catches this, tells screen locker to lock

3. Screen locker reports back that the screen is locked

4. DE then puts the computer to sleep.

Same strengths and weaknesses without ever going outside the DE except to tell the system to suspend.


Oh my god, reading the various links would have told you that your 2, 3 and 4 points are kludges today that don't work well, if at all.
Systemd solves every single one of the problems listed in points 2, 3 and 4.

Comment Re:Duh (Score 1) 674

This lets the desktop environments have more advanced features then they would with init systems that don't do this delegation.

First, is it the regular user account or the DE itself which essentially gets its privileges escalated? Either way, that sounds inherently dangerous -- if you want the DE to be all powerfull, just login as root (there are good reasons not to login as root of course, but if systemD is doing it for you anyway, why even bother with the distinction between root and user accounts).

Because what is being talked about flew right above your head. Ironically, the mechanism you describe was the one used until systemd appeared.
Which is ironic because you weren't even aware of how insecure your sysvinit setup was.
Systemd does it better: it does not escalate your priviledges, it keeps control of how the function is executed, you never gain control of the how. You only gain the rights to ask for a system change to be made.
For example, you can be given the right to change the server hostname (which can break your DBUS and DE) or the desktop clock. But you are not actually executing setuid binaries. Or another example, you can be a step above allowing every user to use the sound card when you have multi seat or multi sessions setups (like I do).
If you can't understand the distinction between the two ways of doing things, as is apparent in your post, try not to talk about it, your post made me cringe with the cluelessness.

Comment Re:Duh (Score 1) 674

> Yes, it is too hard for the actual whiners we have, but it would be easy, beyond simply "trivial," for any Jr Sysadmin or even a Jr Software Developer if they've ever used make

I'm afraid that's not true. Take a look at the Fedora work going on right now to try to segregate systemd components, described at .

Oh my, you say it's not true, then post a link that proves you wrong.
Are you even understanding what you're talking about?
The problem Fedora faces with their two sub packages, is that they have to add functionalities that then would not be in the default systemd package.
If they were already in the main systemd package, their sub packages would not make sense anymore, it would defat their purpose.

These are components that should never have been integrated into an over sized and aggressive systemd in the first place. I've taken a few stabs at segregating systemd components myself, and it's a very large octopus of dependent code.

You sound like an emotional clueless person, not like a developer. What is an over sized systemd? What is an aggressive systemd?
Systemd reduced the size of my hand made systems (I've removed at least sysvinit + tons of scripts and several binary helpers + xinetd + dhcpcd at least) so to me it is not over sized, and it has never actually been aggressive to me, on the contrary, I've fixed several long time invisible misconfigurations by myself thanks to it.

Comment Re:Duh (Score 1) 674

This lets the desktop environments have more advanced features then they would with init systems that don't do this delegation.

An init system shouldn't be doing that stuff. You know how sometimes people complain that "systemd is monolithic?" That is what they are talking about: you can't get that stuff separately from your init system.

Then people saying that are wrong, as this functionality is not in the init system. It is in several parts (so not monolithic), logind being one, and logind is assisted in the task by dbus and systemd init, which themselves are assisted by the Linux kernel.
This assistance and dependencies are necessary to assure a minimum of security.

Comment Re:It depends on somebody doing the actual work (Score 1) 674

The problem is, for years now, we have been assured that Open Source was the cure for problems.

Wrong, that's you rewriting history from your dreams. Nobody assured that.

Just notify someone, and wait, and your problem will be fixed. I had it happen so many times in the old days. Now, developers apparently have stopped caring about this and care only about developing products for themselves.

It was always developers scratching their own itch. And if you couldn't develop, you could pay someone to do it for you.
It always was this deal, you changed "pay someone" to "notify someone" in your delusions.

Sad, but what are you going to do? The concepts that made Open Source a big hit are being abandoned. Open Source isn't going away but it is definitely becoming less popular. Good news for commercial software companies that listen to their customers.

Oh, I didn't understand right away that you were a proprietary software shill, my bad, it should have been obvious, no true Free Software actor could be so deluded and so clueless.

Comment Re:It depends on somebody doing the actual work (Score 1) 674

It is strange that you talk about "non-systemd distros" as if they were defined until then by this.

What are the "non-systemd distros" that are crumbling? If anything is crumbling, it would be more "systemd distros" that get considerable amount of developers forking, founders resigning, etc, not to mention users looking toward BSDs.

FUD is a proprietary OS shill tactic. If you don't understand why distros are separated in systemd ones and non-systemd ones in this thread, you're hopeless.

Also, was it obvious since years that systemd would go in so many direction and that, wherever it goes, code would be throw away? What is then to support?

It was not obvious, because often, the code thrown away is because the underlying plumbing component is abandoned for years, or not supported anymore by anyone.
systemd devs are actually maintaining lots of code nobody wants to maintain anymore.

Isnt it a joke in the end, to support alternative to systemd that actually have to do exactly what systemd does in order to be actually any good?

Yes, I agree it's really stupid. Besides, the people that say systemd features are useless, or that systemd doesn't have any upside, it makes them look plain stupid and clueless.

pm-utils is the example. Was it obvious that upower would throw support for pm-utils? Why was it discarded? Wasn't it discarded because, as pointed at by Edmunson "adding it [systemd] as an optional extra defeats the main benefit"? So what is the joke about writing alternatives when it is clearly that systemd cannot be optional (meaning that alternative must really be systemd compatible, and not the contrary)

It's not like that at all. It's rather that systemd proposes a systemd API for several things. There are a lot of field where systemd is the sole provider of an API, so is the de facto standard. And why is systemd the sole APi provider in some areas? Because while DE were asking for these API, systemd was listening and providing them, while others were not listening and busy telling systemd these features are useless.

It is not really as if we were in a situation where desktop environment on GNU/Linux mattered much. It is not desktop environment that made GNU/Linux popular. At all. There are practically inexistant, if you really loves facing realities. They have a bunch of users. Nothing else. If they can afford too loose more of this bunch in the name of "reality", why not. I'm not sure it is for their benefit.

See your cop out? This is the problem with non-systemd distro: no problem is solved, only cop out, whining, complaining, but you never solved anything, just wasted time. Systemd opponents are mostly like that, that's why I can't take them seriously. I've followed systemd since the beginning, I've seen the amount of work done and the attitude towards users (DE, sysadmins, distros...), and I've seen the work done by those opposed to it. Given this knowledge, up to this day, I predict complete failure of systemd opponents on Linux.

I started using KDE with KDE 1. But I also used Enlightenment, GNOME 1, WindowMaker, Fluxbox, XFCE and many other, I dont feel tied. There are parts of KDE I like and I'd enjoy being able to continue using it and continue to recommend it to other users.
I'm not sure it will be actually possible because, you see, I'm facing the reality, that systemd alternative right now is another systemd. Hence today topic.
I had hopes that Devuan could be enough. Now, after one year, I'm suspecting it could not. Not because of the "non-systemd distros" people, as you name it. But because if the game is rigged. "In many cases [systemd] allows us to throw away large amounts of code whilst at the same time providing a better user experience. Adding it [systemd] as an optional extra defeats the main benefit": it says it all. Thrown away code, no benefit if optional. It is pretty clear what it implies.

I see we share the same conclusions. "Non-systemd distros" had it coming to themselves by not doing anything when sth needed to be done. Which to me means that they are not actually bothered by systemd, and they're doing a disservice to their users. When they will be forced to migrate to systemd, either because they lose all their users, or because they can't maintain old stuff anymore by lack of resources, the change will be so huge, that I'm not sure if all of them will make it. Stuff like sysvinit compatibility may not even be in systemd anymore.

Comment Re:what should ConsoleKit2, the stop gap, do? (Score 1) 674

And moreover, what to expect from upower? Did they not purposefully removed pm-utils support, that worked until then, in favor of systemd?

They removed pm-utils because it didn't work well and was abandoned since 5 years.
People mostly complain about systemd taking over active management of things long abandoned by everybody else.
It's a dogma it seems, a self destructive one, to bash systemd for good things, which is even worse.

Why removing support for a working solution (pm-utils) and, later, much later, adding support for some ConsoleKit2? What is the exact plan of ConsoleKit2? Providing some systemd-like interface without being systemd? Is that what ConsoleKit2 offers that pm-utils could not?
If so, wow long will it work, to attempt to write a parallel to systemd, in order to make sure that all the software that in the past worked without systemd can now work with the systemd alternative?

Most of the time, it's either removing a useful systemd feature entirely and going back several years in time and functionality, or reimplement in true NIH style what systemd already provides.
Sometimes, the reimplementation fails along the road when the "amount of work required" bar goes above the "hate systemd feeling" bar.

The acknowledged benefit of systemd, as pointed out by Edmunson (link in the article) was to drop code. If ConsoleKit2 and al needs to write code to compensate from all the dropped code, following systemd, that unlikely sustainable. The stop gap project won't do.
And it is really the funny thing now with systemd: if you dont want it, you need to write everything that it does because all the anterior/historical parts, good or bad, are getting deprecated and removed. So in order not to use systemd, you need to clone it. Bonkers.

Which is an exemple of what I said above, with a probable failure as outcome.

Hence the question: will KDE be still usable in 2016 without systemd.

That's actually a very good question.

Comment Re:Much todo about zip--ConsoleKit2 is also suppor (Score 1) 674

So while I'm sure the systemd zealots would love to see KDE, Gnome3, etc. only work with systemd and drop support for all other distros, this doesn't appear to be happening. In the case of KDE, ConsoleKit2 is supported (and therefor Funtoo, Gentoo, Arch with OpenRC, etc. will continue to work just fine).

There lies the problem, you anti-systemd zealot are taking an antagonistic stance to all this, assuming that what you call "systemd zealots" would love to see KDE work only with systemd. That makes no sense at all, and that would mean DE devs are "systemd zealots". But all the DEs communication and actions points to you being completely wrong.
Thay actually work instead of complaining uselessly and spouting antagonist nonsense about systemd.

Comment Re:Systemd "Spec" or RFC? (Score 1) 674

With documentation like that I tend to wonder whether idiot is the correct term, or whether malice should be assumed.

Taking an AC on Slashdot as your source, I wonder whether idiotic is the correct term, or whether malice should be assumed.
A real concerned developer would have already started there and looked at "Documentation for Developers".

"I've finally learned what `upward compatible' means. It means we get to keep all our old mistakes." -- Dennie van Tassel