Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd 250 Released

lwn.net

Post reply on HN
Print view View original

191–200 of 204 posts

Re: Systemd 250 Released

#191

Post by lmm »

IshKebab wrote: post #187
lmm wrote: post #159

Earlier quoted context omitted.

> Where's the "hard dependency on libc" list? There are multiple libc implementations. libc independence is important and valuable. You'll probably find a "hard dependency on glibc" list in the documentation of e.g. Alpine. > Or "hard dependency on Bash"? Ubuntu will have a list from when they switched to ash as /bin/sh. Again, multiple implementations and independence are important, and something the linux community…

> There are multiple libc implementations You could make another SystemD implementation if you really wanted. The point is that there are plenty of APIs - even ones with a single implementation - that nobody bats an eye about programs having a "hard dependency" on, but suddenly for SystemD it's apparently a big issue? It's bullshit technical excuses to hide the real reasons people object to SystemD, which are more em…

> You could make another SystemD implementation if you really wanted.

No you can't, because they don't offer stable interfaces as a matter of deliberate policy.

Re: Systemd 250 Released

#192

Post by IshKebab »

lmm wrote: post #191
IshKebab wrote: post #187

Earlier quoted context omitted.

> There are multiple libc implementations You could make another SystemD implementation if you really wanted. The point is that there are plenty of APIs - even ones with a single implementation - that nobody bats an eye about programs having a "hard dependency" on, but suddenly for SystemD it's apparently a big issue? It's bullshit technical excuses to hide the real reasons people object to SystemD, which are more em…

> You could make another SystemD implementation if you really wanted. No you can't, because they don't offer stable interfaces as a matter of deliberate policy.

That seems to be completely untrue: https://systemd.io/PORTABILITY_AND_STABILITY/

Re: Systemd 250 Released

#193

Post by esarbe »

p_l wrote: post #188
esarbe wrote: post #172

Earlier quoted context omitted.

This is simply not true[0]. To quote: > This is really unfortunate, but GNOME 3.8 does not require logind. I discussed the non-dependency of logind+systemd on #gentoo-desktop and why they thought different. Apparently GDM 3.8 assumes that an init system will also clean up any processes it started. This is what systemd does, but OpenRC didn’t support that. Systemd was adopted because it was (and still is) simply super…

It might be because people did report on in trying to run GNOME 3.8 without logind, and reported massive faults? And no, not in "GDM doesn't clean up after itself", which was given as explanation for the infamous "systemd now defaults to destroying everything in a session on logout" change few years later. (Which GDM could require anyway earlier, but apparently somehow it wasn't enough) There is a lot of good ideas t…

> It might be because people did report on in trying to run GNOME 3.8 without logind, and reported massive faults?

If you by 'it' mean the fact that the distributions switched to systemd, I would be declined to discount the speculation that 'it was because people did report in trying to run GNOME 3.8 without logind [...]'. Do you honestly think that Fedora, Arch or any of the other distributions would not try to evaluate other strategies of getting GNOME 3.8 to run? Replacing the process manager and PID0 is not an endeavor chosen lightly - it is a massive undertaking that every distribution would have weight very carefully. "Oh, there are people having trouble running GNOME 3.8 without systemd present" seems not to be enough reason to go through all the pain of switching to systemd.

It's rather that systemd offered something that systemd offered something that the preceding mess of shell scripts and conventions didn't offer; consistency and reliability, as much as you might doubt that. Have a look at the Debian general resolution with regards to systemd and the provided arguments by the proponents[0].

> I've been tinkering at alternative

I would be very glad if your alternative implementation were even modestly successful. And I'd be thoroughly thankful if it managed to replace systemd.

Not because I think systemd is badly implemented (I've yet to see any actual evidence in that regard from any detractor) but because systemd needs competition and I would prefer to see some well established and stable protocols between the individual parts of systemd. That will only happen if said protocols get also provided by alternative implementations.

With regards to you re-using the systemd configuration format; that's probably a smart move. Systemd is at this point a well established fact and anyone trying to best it at its game will have to make is as easy to migrate as possible. Hurdles like a new file format might well be too much for an indifferent user.

[0] https://www.debian.org/vote/2019/vote_002

Re: Systemd 250 Released

#194

Post by lmm »

IshKebab wrote: post #192
lmm wrote: post #191

Earlier quoted context omitted.

> You could make another SystemD implementation if you really wanted. No you can't, because they don't offer stable interfaces as a matter of deliberate policy.

That seems to be completely untrue: https://systemd.io/PORTABILITY_AND_STABILITY/

That's changed then, now that the competition has been killed off; at the time certainly logind and the cgroup integration had no stable interface.

Re: Systemd 250 Released

#195

Post by rektide »

guywhocodes wrote: post #180
esarbe wrote: post #170

Earlier quoted context omitted.

> in fact it at first pushed us back A LOT That argument I don't quite follow. Would you consider rephrasing it? My question is; how did PA set back Linux sound if it did expose all those flaws in the audio driver in the first place?

Not everyone is a power user. At this time I was in university and Linux went from a reasonable choice to an unreasonable due to sound not working again. If you care about real world usage, PA set us back years when Ubuntu made it default.

Alsa is fine, if you needed absolutely no features whatsoever. This weird glamorization of alsa as sufficient or at all adequate feels like itcs true, for only rhe most basic basic basic of users.

Anyone who has ever plugged in a usb headset or connected a bluetooth headset or plugged an hdmi output into their laptop knows the value of pulseaudio. It's role as a modular, pluggable, controllable audio intermediary layer is invaluable: it has a great control panel that lets you say, ok app, start sending your output somewhere else now. Even if you only have one soundcard ever: it let you adjust per app volume! Utterly basic need. To propose that users ought have been fine without these basic capabilities is insanity. Alsa was insanity.

Alsa was a dead, impotent, lifeless husk. It let apps output audio to a device, if you knew to try various hardcoded strings like hw:1.0, hw:2.0, hw:2.1. But that was all alsa was good for. One couldnt open a control panel & change the volume of an app. One couldnt send an app to a new output (bluetooth, hdmi, usb audio). Trying to get a sound card to pick between various output modes, for optical output for example, was hell: i spent literally days getting optical audio going. Everything required careful scripting in a shitty awful .alsarc dsl to do anything good.

Pulseaudio made it all much easier.

I have no clue why anyone would valorize alsa. It was incredible finnicky, super hard to configure. It feels like certain sects just want to spread poison against linux & freedesktop. There have always been reactive, outraged camps. Eternally dismayed at progress, at better. I just can't take seriously the thought that alsa was an appropriate & adequate tool for end users, in any way though. It's ridiculous: nothing worked without careful careful delicate scripting & trial by error, and the system was utterly static, unable to respond to change. Alsa was not an end user system, unlike pulseaudio: it was an api for software. Pulseaudio changed the game. I am so tired lf hearing pretenses that alsa was ok or enough. It never was amything remotely adequate. The nonsense hate has to die. Progress was required. I saw it work flawlessly on many systems even in the earliest days. It wasn't & still usually isn't required. I don't see what anyone could be asking for. It just seems like a need to sow doubt.

Re: Systemd 250 Released

#196

Post by rektide »

lmm wrote: post #67
sjansen wrote: post #47

Earlier quoted context omitted.

There is so much truth to what you say. I used Linux exclusively from January 2000 until April 2012. A lot has changed in that time, but out of all the changes the three I'm most thankful for are: (1) Xorg replacing XFree86 and making video "just work" (2) Pulse Audio replacing OSS and making audio "just work" (3) systemd replacing the dog's breakfast of scripting madness each distro built from scratch instead of col…

The thing is, you used to be able to fix something and have it stay fixed. You used to be able to find a config that worked - which, sure, might have required some manual experimentation and customization - but then you could back it up and keep it. Maybe pulseaudio and systemd only breaks 2% of the time rather than 3% of the time. But when they do break, you can't understand what's happened and you can't fix them, a…

No idea what you are talking about. Pulseaudio nor systemd have wild crazy "it just stopped running" issues, like you suggest.

If something critical launched by your init system isnt coming up, I'd way way rather be using systemd. There's know wwys to inspect, check out what ran, what didnt, see what dependencies are failing. Check the common logging system. In the dark old days it was a nightmare of different daemons, each with their own custom init scripts, & little common reporting. Every problem was unique & required unique diagnosis.

I dont get what the complaints are. Things work great now. There's great diagnostic tools. Most of them with json/machine readible output. Distros sometimes do break various daemons but systemd and pulseaudio are pretty much bulletproof, and if they worked yesterday, i absolutely have faoth they'll work today. I detest so much that this kind of casual easy convenient Fear Uncertainty g Doubt shade throwing persists, that we so casually malign while making no assertions that could be refuted. There's a spectre of doubt that sabotages the good, that seeds disbelief, and it's never justified, never backed up by anything concrete or real or debateable: it's all just this haunting image that it's not going to work. It's seditious.

Re: Systemd 250 Released

#198

Post by fragmede »

mst wrote: post #52
42jd wrote: post #30

Earlier quoted context omitted.

As someone who has learned Linux/Unix just the past few months using a systemd based distro, I find it a breeze to use. Great documentation, FOSS, and really easy to pick up. I just don’t understand why there is so much dislike thrown around when that energy can be focused elsewhere on truly bad behavior/software. And from my understanding, there are distros out there that don’t use systemd for those who dislike it t…

I'm an old school unixhead who's nonetheless made his peace with systemd because, honestly, it makes lots of things work way better than most previously available solutions did. Thing is, it also forcibly changed a bunch of things by introducing defaults that were not at all what people expected. They might have been better overall, but it still caused some nasty surprises. Let me try and explain a bit more concretel…

ILOM/iDRAC/etc largely solved that sort of thing, but there was always a chance that grub config became corrupted eg when upgrading kernels, leaving you with a 4-hour drive. Pid 1 is critical, and it's ridiculous that it took until systemd for it to stop being something that was just hacked together instead of a well-supported (if surprising at time) software package. It was a real "cobbler's son has no shoes" moment when I first realized back in the RHEL 4 days that the /etc/init.d/ scripts I was looking at were the actual implementation and not some abstraction.

Re: Systemd 250 Released

#200

Post by p_l »

esarbe wrote: post #193
p_l wrote: post #188

Earlier quoted context omitted.

It might be because people did report on in trying to run GNOME 3.8 without logind, and reported massive faults? And no, not in "GDM doesn't clean up after itself", which was given as explanation for the infamous "systemd now defaults to destroying everything in a session on logout" change few years later. (Which GDM could require anyway earlier, but apparently somehow it wasn't enough) There is a lot of good ideas t…

> It might be because people did report on in trying to run GNOME 3.8 without logind, and reported massive faults? If you by 'it' mean the fact that the distributions switched to systemd, I would be declined to discount the speculation that 'it was because people did report in trying to run GNOME 3.8 without logind [...]'. Do you honestly think that Fedora, Arch or any of the other distributions would not try to eval…

Fedora and Arch are literally the early adopters of systemd, long before GNOME 3.8. GNOME 3.8 made hard dependencies on logind because it was default in Fedora - Arch similarly was working full tilt on implementing all proposed things from systemd long before GNOME 3.8 release (I know, I had lost my only on-hand system due to one of those changes applying badly and making it unbootable)

As for supporting configuration format - it's an obvious move, though more as "import" rather than only source of truth (different internal data models), and the format... is not exactly good (mostly due to lack of sane defaults that start to hit you once you wander beyond functionality that can be summarised as "SysV initd plus dependencies")

Post reply on HN