SoylentNews is people
SoylentNews
The Linux Homefront Project reports on Lennart Poettering looking to do away with the good old "su" command. From the article, "With this pull request systemd now support a su command functional and can create privileged sessions, that are fully isolated from the original session. Su is a classic UNIX command and used more than 30 years. Why su is bad? Lennart Poettering says:"
Well, there have been long discussions about this, but the problem is that what su is supposed to do is very unclear. On one hand it’s supposed to open a new session and change a number of execution context parameters (uid, gid, env, …), and on the other it’s supposed to inherit a lot concepts from the originating session (tty, cgroup, audit, …). Since this is so weakly defined it’s a really weird mix&match of old and new paramters. To keep this somewhat managable we decided to only switch the absolute minimum over, and that excludes XDG_RUNTIME_DIR, specifically because XDG_RUNTIME_DIR is actually bound to the session/audit runtime and those we do not transition. Instead we simply unset it.
Long story short: su is really a broken concept. It will given you kind of a shell, and it’s fine to use it for that, but it’s not a full login, and shouldn’t be mistaken for one.
I'm guessing that Devuan won't be getting rid of "su."
(Score: 2) by mr_mischief on Monday August 31 2015, @06:58PM
I actually like the init system part of it. The unit files are nice and declarative, and don't depend on a particular flavor of shell. Everything else that is pulled in to get that, though, is worrisome.
(Score: 4, Informative) by Marand on Tuesday September 01 2015, @03:52AM
I actually like the init system part of it. The unit files are nice and declarative, and don't depend on a particular flavor of shell. Everything else that is pulled in to get that, though, is worrisome.
That's also where a lot of the backlash systemd gets comes from. Linux distros have had alternative init systems for ages without any of this drama, because distros like Debian would let you switch it out without a problem, and changing the init didn't affect other components. There was some backlash with Ubuntu's adoption of upstart, but mostly because they removed the other inits from the repos so you couldn't easily switch back.
With systemd, though, you get stuck with an all-or-nothing scenario. If you like the init part, you better like the binary logging as well, because it's a package deal. This is especially annoying because one of the "arguments" I've seen from systemd proponents is that it's not monolithic, because it has a bunch of separate binaries, so everything isn't crammed into PID1. That's technically true but disinginuous because the pieces of the systemd "suite" are deeply intertwined. You can, at least for now, avoid a lot of it with a shim package Debian provides, but it's a workaround to avoid systemd, not a way to let you cherry-pick the parts of systemd you might want, because systemd itself is hostile to that concept.
(Score: 2) by mr_mischief on Tuesday September 01 2015, @05:51PM
TL;DR: The binaries aren't monolithic but the systemd system and its packages pretty much are.
That's the problem in a nutshell. I think I'd like uselessd. I like the unit files. I like the dependency management in the init system. like having a more or less standard process supervisor for free with my init system. I don't want all the other stuff.
(Score: 1) by rtfazeberdee on Thursday September 03 2015, @02:25PM
if its technically true then its true, how can it be disingenuous? the systemd binary is the ONLY binary at PID1. There are 3 forced dependencies, systemd, udevd and journald, everything else if optional. Do you complain about your binaries being dependent on glibxxx, try breaking that dependency and see how far you get.
You get binary logging (which is a text file with an index) but you can configure the system to continue using syslog etc as per normal. The binary logging starts at boot up and continues to shutdown and syslog cannot do that. If you use the journalctl to read the journal for a while, you'll see the benefits. I'm waiting for the anti-binary group to start tell oracle et al to start using text files.
(Score: 3, Informative) by Marand on Thursday September 03 2015, @10:10PM
if its technically true then its true, how can it be disingenuous? the systemd binary is the ONLY binary at PID1. There are 3 forced dependencies, systemd, udevd and journald, everything else if optional. Do you complain about your binaries being dependent on glibxxx, try breaking that dependency and see how far you get.
It's disinginuous because, while the statement itself may be true, it's addressing a point that wasn't being made in the first place, while also failing to address the actual complaint itself. It's akin to someone complaining about how they don't like the US government's trend toward ubiquitous domestic espionage and then having a politician argue that it's not a problem because the NSA's foreign data collection hasn't changed.
When a person (such as myself) says that a problem the person has with systemd is the massive amount of interconnect between parts in a way that interferes with the traditional and well-accepted interchangeable lego-like design, because it makes it nigh impossible to switch out components, an argument that it technically isn't monolithic because it's really a bunch of separate binaries you can't change may be true but it's also a useless distinction in the context of the complaint.
It's an attempt to steer the discussion into technicalities and semantics to avoid acknowledging the point itself. Kind of like now, in fact; I mentioned the tight interconnect being annoying to some because you can't switch components, and instead of doing anything to allay those concerns (presumably because you can't), you went after a technicality and started arguing about that instead.
You get binary logging (which is a text file with an index) but you can configure the system to continue using syslog etc as per normal. The binary logging starts at boot up and continues to shutdown and syslog cannot do that. If you use the journalctl to read the journal for a while, you'll see the benefits. I'm waiting for the anti-binary group to start tell oracle et al to start using text files.
This is more "steer the complaint away from something I can't disprove" language.
Yes, you can run additional logging, but that doesn't address the tight interconnect complaint still. Nor does suggesting that the logging is better and that if you "use [it] for a while" you'll "see the benefits" . Furthermore, if it's so much better, and so obviously so, it should be able to get adopted on its own benefits instead of being coupled with an init so everyone gets forced into an all-or-nothing deal. Finally, you just tried using an "appeal to authority" logical fallacy in support of binary logging by claiming that Oracle does it too.
It's all weasel language and squirming.
---
Here's the thing: I don't care that systemd (the init) exists. I don't even care that there's a suite of replacement parts for common system components. I don't even generally mind that distros want to use these components, because it sort of mirrors the BSD style of separating the "core" system from third-party pieces.
However, I don't like the interconnected nature of the suite as it stands now, because it's being done in a way that isn't playing nice with "outsiders", such as existing software that has filled the same roles for decades. We shouldn't have to run two syslogs just to get text logging, for example; it should be an optional component that can be switched out. Likewise, if someone wants the binary logging but not systemd-init, that should be possible.
Arguing that "it's better for you" and "you just don't know it yet" and "technically it's not monolithic because..." is grasping at straws. You can say that stuff all you want, but it's not going to make the suite more appealing to people that don't like the tightly intertwined design. (Of course, it's not the only thing; there are other issues with it, but nothing relevant to the discussion that arose from OP's comment)
(Score: -1, Troll) by rtfazeberdee on Friday September 04 2015, @03:21PM
"It's all weasel language and squirming." no its not. Its all open source so you can replace/change what you like.
All the complaints are trivial because for virtually every complaint about systemd there is an example of the same within the rest of the system. Tight dependencies (glibxx), monoliths (kernel) for which no-one complains about. if systemd had been written and designed by LTorvalds instead of LPoettering then it will be celebrated. Its more of a hate campaign against LP using trivial complaints about systemd as an excuse.
"Arguing that "it's better for you" and "you just don't know it yet" and "technically it's not monolithic because..." is grasping at straws." sorry, but its true that the new logging is far better than the current system and systemd is not monlithic - its grasping at straws when people say the opposite.
(Score: 2) by novak on Thursday September 10 2015, @03:13AM
Seems like you genuinely have a misunderstanding about what people are trying to say here.
When they say that systemd is monolithic, they don't mean that it's a single binary file, or that it's all in PID1. Because it's not, obviously. What they are saying is that systemd does not work well with any other programs and it's almost impossible to change out components, which are often connected by unstable APIs. I mean, I guess it's better that there's less complexity in PID1 but it really doesn't help me modify anything.
And the whole binary logging thing- this is just ridiculous. Systemd does not support any form of logging except these binary logs, ok? It can hand the logs off in a different format, but every log goes through journald in a binary format. Claiming otherwise is like saying you can drive from California to your friend's house in Hawaii because you rent a car at the airport.
Its more of a hate campaign against LP using trivial complaints about systemd as an excuse.
It's interesting to note that there have been many, many different init systems which implement at least parts of systemd's design and were improvements on sysVinit from a technical perspective. http://blog.darknedgy.net/technology/2015/09/05/0/ [darknedgy.net] Hardly anyone ever bothered to insult any of them, if anything they just declined to use them. Most of the hate that systemd has managed to generate is because of the way that it integrates with things like udev, making it pretty hard for anyone to use any other init system- in some ways kind of a rude move because udev already worked with other inits but they removed support. This in turn left projects like Gnome which want to integrate with hardware management the choice of requiring systemd or offering worse integration. When people complain about this they are usually instantly flamed as "haters," and publicly insulted, even in cases like Gentoo where all they asked was for systemd not to retroactively remove support in udev for other init systems. Systemd has really worked fairly hard to generate the kind of hatred that it has.
novak