The systemd team didn't create those dependencies, the DE maintainers did. All of these DEs ran just fine without systemd and they still could if someone was interested in doing so.
The systemd developers have been active in the DE mailing lists, encouraging them to make systemd a dependency. See here for an example.
And I've personally compiled and installed non-init parts of systemd.
Which parts? Do tell.
LOL no amount of trolling the links will get me interesting in reading your slashdot journal, and no, writing an essay does not replace discussion. Nobody is going to go read that shit. You're generally expected to type in new comments as part of a discussion, and to formulate them for the current context.
Are you capable of discussing things without insulting? So far the answer is no.
If you don't use systemd as your init system, you can't use other parts of systemd, like logind. So you can call it whatever you want, the init system is inseparable.
Is it not possible to just write a standard interface that would have it working with any init system?
That's the right idea, because the interfaces are more important than the code. It's more complex than just an "init interface," but clearly there needs to be a division between the init system and the "system manager demon."
For the average user, don't worry about the difference.;)
The average user is happy with Windows, let's be honest.
Also, if you read the article, you absolutely do not need the systemd init system to use the new features.
I don't know what article you're talking about specifically, but it looks like to get it to work, you need to use an older version of uPower. And it isn't a new feature, it's a feature that's been there for a while a long time, but now depends on systemd.
using non-init parts of systemd to allow the desktop environment to monitor the user inputs
You're right. KDE is not depending on an init system.
You're wrong......the "system management" portions don't work without the init system. For example, logind depends on systemd quite clearly, look at the function execute_shutdown_or_sleep().
People have tried to separate the system management portions from the init portions of systemd, but it was rather more difficult than you'd expect and they gave up.
It's not clear what you mean by "tight integration."
But it's not necessary to have a monolithic system in order to make something good.....to avoid it you need to make clear interfaces.
As mentioned, the kernel has to deal with much more integral and disparate pieces than systemd does, and yet it is still relatively simple to swap one kernel for another. If the kernels can do it, then there is no excuse for systemd.
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.
kde or gnome as they are desktop environments not window managers.
What difference does that make to the current discussion? I'll happily concede that point if you stay on topic. Neither KDE nor Gnome should depend on a particular init system.
"I
think we need to ask ourselves the question if we do ourselves any good
if we continue to support all kinds of kernels that simply cannot keep
up with Linux anymore."
Die Systemd! I prefer my log files in text format.
The problem isn't binary logging. Some people prefer that, it's ok, they should be able to have binary logs on their system.
The problem is we already have a system for that.....syslogd. Instead of completely redoing the way logging works, if they wanted binary logging, then they could make small modifications to syslogd, and then everyone is happy. Switching between binary logs and text logs would be simple.
Instead, they made a completely new haphazard interface, trying obsolete the system that was already in place.
Correct. Systemd is not about a modern init system. There are tons of modern init systems being worked out now.
Systemd is pretty clearly an init system. It's just that if you don't use that system, you can't use a lot of other stuff.
The kernel is much more complex than an init system, and we've mostly figured out how to swap that out without difficulty. Swapping out an init system should be relatively simple in comparison.
Slashdot Mirror
I guess we'll see how writing non-portable *nix code as a strategy works out in the long run.
Overall it hasn't worked well in the past. I discuss one reason why I think that is here: in short, code doesn't last, but interfaces do.
Systemd is a set of many intertwined packages.
That's the problem. You can't run those systems without using the init system, therefore they depend on the init system.
They never seemed to complain about X the same way though.
Pay more attention. People have called X a cludge for many years.
So Apple went 1st and everyone but Linux followed.
Solaris and HP went before Apple, and their init systems drew a lot of criticisms.
The systemd team didn't create those dependencies, the DE maintainers did. All of these DEs ran just fine without systemd and they still could if someone was interested in doing so.
The systemd developers have been active in the DE mailing lists, encouraging them to make systemd a dependency. See here for an example.
And I've personally compiled and installed non-init parts of systemd.
Which parts? Do tell.
LOL no amount of trolling the links will get me interesting in reading your slashdot journal, and no, writing an essay does not replace discussion. Nobody is going to go read that shit. You're generally expected to type in new comments as part of a discussion, and to formulate them for the current context.
Are you capable of discussing things without insulting? So far the answer is no.
If you don't use systemd as your init system, you can't use other parts of systemd, like logind. So you can call it whatever you want, the init system is inseparable.
Is it not possible to just write a standard interface that would have it working with any init system?
That's the right idea, because the interfaces are more important than the code. It's more complex than just an "init interface," but clearly there needs to be a division between the init system and the "system manager demon."
For the average user, don't worry about the difference. ;)
The average user is happy with Windows, let's be honest.
Also, if you read the article, you absolutely do not need the systemd init system to use the new features.
I don't know what article you're talking about specifically, but it looks like to get it to work, you need to use an older version of uPower. And it isn't a new feature, it's a feature that's been there for a while a long time, but now depends on systemd.
using non-init parts of systemd to allow the desktop environment to monitor the user inputs
The non-init parts of systemd aren't separable from the init parts. I discussed part of the issue here.
As many skilled people as possible need to start thinking about the init problem, so we end up with something good.
You're right. KDE is not depending on an init system.
You're wrong......the "system management" portions don't work without the init system. For example, logind depends on systemd quite clearly, look at the function execute_shutdown_or_sleep().
People have tried to separate the system management portions from the init portions of systemd, but it was rather more difficult than you'd expect and they gave up.
It's not clear what you mean by "tight integration."
But it's not necessary to have a monolithic system in order to make something good.....to avoid it you need to make clear interfaces.
As mentioned, the kernel has to deal with much more integral and disparate pieces than systemd does, and yet it is still relatively simple to swap one kernel for another. If the kernels can do it, then there is no excuse for systemd.
You'll have to ask the GP, I was quoting him/her.
I guess the point is: KDE isn't a "window manager" - instead it's a desktop environment, which includes functionality for power management
Yes, I think you are right.
And it's reasonable architecture for power management controls to depend upon power managing daemons.
But it's not reasonable for it to depend on a particular init system.
That point has been discussed and is irrelevant to the discussion.
If any other init system + provided the features necessary for the modern desktop environments, then I'm sure they would not hesitate to support it
The init system should not be providing those features. That is entirely the problem.
and no one other then systemd has bothered to create a viable solution to the destkop environments problems.
What was wrong with Powerdevil and pm-utils?
So why can't there be other systems that do the various parts that aren't init but systemd is doing?
There were until recently, apparently. Powerdevil and pm-utils. Apparently KDE preferred the systemd way, for whatever reason.
Again, the point under discussion is neither KDE nor Gnome should depend on a particular init system.
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.
kde or gnome as they are desktop environments not window managers.
What difference does that make to the current discussion? I'll happily concede that point if you stay on topic. Neither KDE nor Gnome should depend on a particular init system.
So now there's no Gnome or KDE on anything but Linux.
That is Lennart's plan. Here's what he says::
"I think we need to ask ourselves the question if we do ourselves any good if we continue to support all kinds of kernels that simply cannot keep up with Linux anymore."
Die Systemd! I prefer my log files in text format.
The problem isn't binary logging. Some people prefer that, it's ok, they should be able to have binary logs on their system.
The problem is we already have a system for that.....syslogd. Instead of completely redoing the way logging works, if they wanted binary logging, then they could make small modifications to syslogd, and then everyone is happy. Switching between binary logs and text logs would be simple.
Instead, they made a completely new haphazard interface, trying obsolete the system that was already in place.
Correct. Systemd is not about a modern init system. There are tons of modern init systems being worked out now.
Systemd is pretty clearly an init system. It's just that if you don't use that system, you can't use a lot of other stuff.
The kernel is much more complex than an init system, and we've mostly figured out how to swap that out without difficulty. Swapping out an init system should be relatively simple in comparison.
I don't do much init-fiddling although I do like the text based init/runlevel thing,
It's pretty clear that if KDE depends on one particular init system, that systemd is no longer just an init system.
If you're allergic to trimming your neckbeard and running a modern init,
There's no reason a Window Manager should depend on a particular init system. Doing so is a clear sign of bad software architecture.
Conservative media teaches distrust of the mainstream
? Do you trust the mainstream?
Right now, the barrier to increasing use of space is the cost of launch.
Reports are that SpaceX has reduced the cost to launch by an order of magnitude (or more).