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, Troll) by novak on Monday August 31 2015, @05:35PM
Long story short: I don't really understand shells but I decided to call them broken and absorb more of linux userland into systemd rather than admit I had a trivial bug and just fix it. Systemd is a replacement for POSIX, but it’s not a good init system, and shouldn’t be mistaken for one.
FTFY, Poettering.
It's pretty clear that this is just one more thing for systemd to ingest and subsume so that they can continue their takeover of userland. Redhat is really winning in a big way, and the losers are all linux users. I wonder how many systemd supporters are having second thoughts when they see stuff like this?
novak
(Score: 2, Funny) by Anonymous Coward on Monday August 31 2015, @06:32PM
Still waiting on the systemd-emacsd to be created, then systemd might actually be useful.
(Score: 0) by Anonymous Coward on Monday August 31 2015, @07:11PM
one step closer for emacs being in the kernel...
(Score: 2) by meisterister on Monday August 31 2015, @11:51PM
Do you understand the gravity of what you just said? The clash between program-that-is-an-OS and program-that-wants-to-be-the-OS would cause all of space and time to just stop cold.
(May or may not have been) Posted from my K6-2, Athlon XP, or Pentium I/II/III.
(Score: 2) by DECbot on Tuesday September 01 2015, @05:21PM
No, as foretold in the Wheel of Time, history will repeat itself. We will return to the age where the program is the OS. Then there will be mainframes to control the users, and then the advent of the personal computer will usher in the dragon^W^W Linus reborn.
cats~$ sudo chown -R us /home/base
(Score: 4, Insightful) by digitalaudiorock on Monday August 31 2015, @06:41PM
More importantly, I wonder how all the distros that have caved to this bullshit are starting to feel.
The really big issue I see coming down the road is the kdbus fiasco. If I understand correctly, kdbus in the kernel will become a requirement in spite of the fact that the kernel devs will have no part of it. They've repeatedly told the freedesktop folks that it's mis-designed bloated userland code that has no place in the kernel, and they just keep sticking their fingers in their ears.
Seems to me this will eventually mean all the distros that have given into this will be stuck with unofficial kernel patches...good fucking luck with that.
(Score: 2) by novak on Monday August 31 2015, @07:52PM
I'm concerned about this too. Linux 4.2 just came out and has no KDBUS. From what I hear, it's expected to merge in 4.3- though I hope it'll be longer than that. The big deal about kdbus is that udev (part of systemd for no reason at all) will become dependent on KDBUS and it will use the sdbus API which is also part of systemd. This could result in major issues for eudev developers.
Thus far I've mainly stuck with linux- linux runs a crapload of tools, and I like to use some of the more obscure ones. My distros of choice are minimal and haven't caved to systemd (though I did use debian a bit), but if the choices are "use systemd," or "write your own systemd and use that," I'll probably stop upgrading linux and move away from it except for legacy versions for embedded development. I've always been impressed with openBSD, so that's probably what I'll have to go unless resistance to systemd stays strong. If at least some distros keep trying to make linux work without systemd or systemd-alikes, I'll probably keep hacking on it for a few more years at least.
novak
(Score: 2) by digitalaudiorock on Monday August 31 2015, @08:40PM
Is there any indication of that from anyone other than the freedesktop.org folks? There's a thread in the Gentoo forums following the kernel mailing list around that topic, and it doesn't sound like any of the kernel developer's concerns and criticisms have even been acknowledged, let alone addressed. Even Linus has totally called out their claims of how they need that in the kernel for performance reasons as total BS. It's actually a bit bizarre. It seems as though they have no plans of changing any of it, and are just hoping that the kernel devs give into pressure from RH and the like.
(Score: 2) by novak on Monday August 31 2015, @08:52PM
I saw a comment somewhere indicating that Greg was planning to fix it prior to resubmitting it for merging, with a lot of pompous feel-goody words in there about making sure everyone was happy with it but I haven't kept too close an eye on it myself. Now you've got my interest though, got a link to that forum thread?
novak
(Score: 3, Informative) by digitalaudiorock on Monday August 31 2015, @09:01PM
Here it is:
https://forums.gentoo.org/viewtopic-t-1004624.html [gentoo.org]
Seems to me that Greg has been spewing non-answers through the entire discussion. I would take anything from him with about 1000 tons of salt.
(Score: 2) by novak on Monday August 31 2015, @09:53PM
Thanks, that's some good reading. Looks like there is some hope that the whole kdbus design and implementation is so bad that Linus will block it, at least for quite a while until they actually solve some of the technical issues (which are apparently even more than I realized- it's a security nightmare). On the other hand, it's fairly clear that the systemd/kdbus supporters' play is to try to ignore the issues and have redhat/greg/poettering/crew try to strongarm the whole thing through as "good enough we'll polish it later." Let's hope that Linus is his usual rude self in the face of such obviously bullshit tactics.
novak
(Score: 2) by Marand on Tuesday September 01 2015, @03:40AM
ignore the issues and have redhat/greg/poettering/crew try to strongarm the whole thing through as "good enough we'll polish it later."
So, basically business as usual for Poettering and company. That's the same argument that led to Pulseaudio's premature adoption to (supposedly) solve problems like software audio mixing, and other features that were already solved in other projects before pulse got released. Release crap, make it a dependency of some other stuff, and then let everyone else deal with making it usable.
The good news is that, ten or so years later, pulseaudio is mostly* usable out of the box, so there's some slim hope for systemd, once Sievers and Poettering get bored and move on.
* Only mostly, I still find that the best "fix" for audio problems in Linux is usually to uninstall pulseaudio and let programs work with ALSA directly.
(Score: 2) by novak on Tuesday September 01 2015, @06:54AM
Yep, I've had problems in userland with audio on linux exactly once since I started using it. A couple years back, I put debian on a machine for my wife. It was fine, but then a month or two later randomly she was having trouble with sound. I assumed that she did something stupid, not being a linux person, but no, it was really broken and apparently in some persistent setting that lasted through a reboot. That was when I realized that I had accidentally installed pulse (the default, I guess) so I nuked it and have had no problems since. Pulse isn't _that_ buggy (anymore), but it's pretty pointless because it runs on top of ALSA and it's buggier than ALSA. I've never used it intentionally because there has never been a point in time where pulse offered me any feature I cared about- just another layer of bloat.
I have less hope for systemd, though, because by design systemd has to keep expanding. First it has to eat linux userland, then it's going to have to add "features." So if the init system part of it is rock solid in a few years- hell, even the webserver might be pretty well debugged by then- then openofficed or emacsd or waylandd or some shit (which urgently has to be written because what it replaces was really broken the whole time, we'll learn) is going to add bugs right back in.
However, while Linus doesn't appear to really care about the changes systemd is making, he is one of the people least likely to tolerate poor code and worse excuses from these guys in the linux kernel. This could be something of a holdup to systemd's proposed takeover- though as I understand it more of a delay than a real show-stopper because systemd can still run over regular dbus- there won't be any unsupported kernel patches over this anytime soon.
novak
(Score: 0) by Anonymous Coward on Wednesday September 02 2015, @02:59PM
The only thing pulse seems to offer that alsa can't do on its own, is dynamic device switching.
This however is only really relevant for the new breed of USB "headphones", where they have a small sound card in the USB end, and some headphones hardwired to that.
(Score: 0) by Anonymous Coward on Wednesday September 02 2015, @08:50PM
It is also relevant for bluetooth headphones. I do love the freedom of using bluetooth headphones, not being tethered to the device the sound is coming from. Now if only bluetooth audio was actually usable on Linux, I've just tried it with the built-in bluetooth on my new laptop and it still suffers from terrible lag and dropouts, like it did the last time I tried it several years ago.
(Score: 0) by Anonymous Coward on Thursday September 03 2015, @03:52PM
Bluetooth is sadly highly dependent on the devices being properly charged.
Be it audio or HID, the device will start to show lag and such long before the "low battery" light turns on.
(Score: 0) by Anonymous Coward on Saturday September 05 2015, @01:40PM
That hasn't been my experience, how well charged my headphones are hasn't been an issue, they have worked well up until they run out of battery. However there is an inherent lag with the A2DP protocol that is used due to encoding for high quality audio, but that lag itself isn't an issue it is consistent and easily compensated for when watching video, that wasn't what I was complaining about.
From my point of view Bluetooth audio works just fine with Android (it also mostly worked on my Nokia N900 which ran Linux, though that had an issue with interference from its WiFi radio), the lag I experience with Bluetooth audio on Linux is rather excessive, but it is the dropouts when I'm right next to the computer that make it unusable for me. The only "solution" I have so far is to use an external Bluetooth transmitter.
(Score: 0) by Anonymous Coward on Tuesday September 01 2015, @02:24AM
I have yet to see Red Hat (Poettering's employer) walk back any of this ridiculousness. Of course, Red Hat already has plenty of fingers in plenty of pies, in terms of Linux subsystems.
If it does come to the point of unofficial kernel patches, I hope Linus Torvalds decides to have some fun on the first merge request where he can stomp on this sideshow. Frankly, it's way past time he did that.
(Score: 0) by Anonymous Coward on Tuesday September 01 2015, @12:26PM
Linus said systemd is fine. Where does linus get his money from. A consortium. Where does that money come from. Guess.
I don't like it.
Maybe Linux needs to be forked by Brad Spengler of Grsec?
(Score: 2) by fnj on Tuesday September 01 2015, @04:38PM
Linux doesn't need to be forked; not by anyone. There are already superb alternate POSIX OSs; the BSDs. FreeBSD and its dependent offshoot PC-BSD come the closest to rivaling the capabilities of linux. NextBSD is just beginning development, and might become another contender. None of these are infected by systemd or ever will/can be. All that is needed is for DE and app developers to stay away from building in any gratuitous dependencies on linux in their code, so they can be readily ported to the BSDs. Mostly, this is only a problem with DEs.
Since the various DEs[*] are being obtuse and obstinate, a fresh DE called Lumina is being developed expressly for PC-BSD. It is lightweight and very promising; already well along in development.
[*] GNOME has gone in whole hog with systemd dependency, and the developers are on the record for only caring about Linux. KDE is catching the disease. Even XFree86 is showing definite signs of infection.
(Score: 3, Informative) by hash14 on Tuesday September 01 2015, @03:01AM
I'm not quite as optimistic. Greg KH is a pretty big fan of systemd and kdbus:
https://lkml.org/lkml/2015/4/13/645 [lkml.org] (long discussion, but it shows that GKH is a big proponent of pulling in kdbus, and _against_ the technical advice of many others on LKML)
http://kroah.com/log/blog/2014/01/15/kdbus-details/ [kroah.com]
https://www.reddit.com/r/linux/comments/13g3ys/greg_kh_mocks_udev_fork_developers/ [reddit.com]
https://www.linux.com/news/featured-blogs/200-libby-clark/771055-fun-photo-greg-kroah-hartman-crowned-at-the-systemd-hack-fest [linux.com]
(Score: 0) by Anonymous Coward on Tuesday September 01 2015, @03:43PM
And Torvalds is overly trusting of GregKH.
Torvalds also seems to think that even with the flaws, kdbus can be pushed into its own little corner of the kernel and forgotten about.
More likely that once the base is accepted, GregKH and others will be pushing to patch it so that various other sub-systems move to talk to userland via kdbus exclusively.
Question is if this will get some "we don't break userspace" rantings from Torvalds, whereupon the recently introduced social contract gets thrown in his face...
(Score: 1) by rtfazeberdee on Thursday September 03 2015, @02:14PM
"More importantly, I wonder how all the distros that have caved to this bullshit are starting to feel." - they know a lot more than you do hence they took this road.
"If I understand correctly, kdbus in the kernel will become a requirement in spite of the fact that the kernel devs will have no part of it. " you don't understand correctly which is indicative of your whole post.
(Score: 2) by digitalaudiorock on Thursday September 03 2015, @02:30PM
Wow...really specific. Seems most people here disagree with you. I guess they don't know anything either right?
I've been coding in unix since the 80s. How the fuck do you know what I know?
(Score: 0) by rtfazeberdee on Friday September 04 2015, @03:28PM
so what if most posters disagree, most are ACs who could be just be a few misinformed people. As most of them didn't understand the article and hence all the crap responses to it, i don't count them as knowledgeable on this particular subject. I don't care if you've be coding since Babbage's time, things move on and sometimes the longer you've been doing the same thing the harder it is to deal with new things. Out of interest, are you still using Linux 0.99 and Motif or CDE (or just cli)?
(Score: 2) by digitalaudiorock on Thursday September 03 2015, @02:39PM
FFS...I just realized that you just joined here to post this shit. Typical. Get a life and go fuck yourself.
(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
(Score: 3, Interesting) by M. Baranczak on Monday August 31 2015, @07:36PM
I wonder how many systemd supporters are having second thoughts when they see stuff like this?
I was on the fence about systemd for a long time, until now. The su command has been around for decades, it only does one thing, and there's no lack of documentation - now this guy is saying its purpose is unclear? Are you fucking serious?
(Score: 0, Offtopic) by rtfazeberdee on Thursday September 03 2015, @02:32PM
read about it before taking an opinion based on a flawed interpretation from a poster. its an additional feature mainly for use with containers and NOT a replacement "su" - "su" is NOT deprecated or removed.