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 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.