- cross-posted to:
- linux@programming.dev
- cross-posted to:
- linux@programming.dev
You must log in or register to comment.
Artix, Devuan, Void, Alpine Linux are the way to go
and Guix
Gentoo LET’S GO
You’re absolutely right, I absolutely forgot about Gentoo although it’s my daily driver
No fuckin thanks
No.
Well… Poettering will eventually work his way up to browser engines and then we’ll get something efficient… Here’s the announcement:
"There’s a new component in systemd, called “engined”. Or actually, it’s not a new component, it’s actually the long existing “WebKit” engine now done properly. The engine is also a lot more fun to use than “WebKit” or “Blink” because you can finally have hundreds of tabs open in your browser without running out of RAM.
Coming soon in Coming for systemd 981.
Fuck off Poettering!
Can’t see how this could go wrong
Glad to see PoetteringOS has still not infected the *BSD family members /s And I’ll gladly use Doas on Linux if need be, thank you.
What version of doas though? Opendoas is hardly maintained.
However, distributions like Fedora will definitely be in the lead, judging by previous experiences and stories of adapting new Linux technologies and Systemd components.
I wonder if this is still true, now that he no longer works for RedHat, but Microsoft.
I wonder if this is still true, now that he no longer works for RedHat, but Microsoft.
Why wouldn’t Fedora do that? Decisions are decided by multiple people, they are not forced through or just decided unilaterally by one person.
Enough people in Fedora try to improve the low level stuff. I’m looking forward to that homedir systemd stuff. Don’t care about this sudo alternative.
Decisions are decided by multiple people, they are not forced through or just decided unilaterally by one person.
Unless you’re talking about GrapheneOS, but that’s an horror story for another night 🤣
sudois already an optional component (yes, really—I don’t have it installed). Don’t want its attack surface? You can stick withsuand its attack surface instead. Either is going to be smaller than systemd’s.systemd’s feature creep is only surpassed by that of emacs.
Or you can use a
doasimplementation like OpenDoas, or maybesudo-rs…Though a Rust clone of sudo that operates in the same way will still have the same problems.
But systemd is modular. They make an offer and distro maintainers and admins get to choose which parts to use
The problem is that those modules are packaged by the developers as opt-out rather than opt-in. It’s a variation on Microsoft’s old embrace-extend-extinguish playbook, only the “extinguish” part hasn’t worked so well because there are some stubborn distros whose needs don’t align with what systemd provides and have maintainers that go out of their way to provide alternatives.
(By contrast, although we may joke about emacs, it’s the myriad of third-party extensions that cause it to just about be its own operating system—it doesn’t all ship with the core.)
systemd’s feature creep is only surpassed by that of emacs.
Tomorrow’s headline: emacs wants to expand to include a Sudo replacement
And after that: emacs wants to include a systemd replacement
:wq
I’d take that over systemd.
I’m not a fan of having root be able to actually login.
Even more so in a true multiuser env where I would rather have privilege escalation be more granular (certain user/groups can esculate certain actions but not others, maybe even limit options of a cmd).
Granted, in a true multiuser environment with an admin who’s carefully tailoring /etc/sudoers to make sure everyone has the least possible privileges that will allow them to still do what they need,
sudois more secure. There’s no doubt of that.On a machine that has only one human user who’s also the admin, and retains the default sudo-with-user-passwords configuration,
suvssudois pretty much a wash, security-wise.surequires a second password to get root access, butsudotimes out and requires the password to be re-entered while a shell created bysucan stay open indefinitely. Which is more easily broken will depend on other details of your situation.(If you’re running an incorrectly configured ssh server that allows direct root login with only password authentification, having a root password could contribute to problems, but the correct fix there is to reconfigure the ssh server not to do something so stupid. I hope there’s no distro that still ships that way out of the box.)
And there’s also doas which is a nice substitute.
Don’t we already have polkit and pkexec for that?
invoking them is kind of a pain, my sole experience with it was meson/ninja using it but then that default was removed and I’ve never been able to put it back to satisfy my curiosity of how it’s done
I’m not surprised. Not surprised at all. (scope creep)
Not that I’m opposed to a better sudo alternatives, but I find it rather ironic that one of the reason stated is the large attack surface, considering systemd is a massive attack surface already.
This isn’t exactly a “new” attack surface, so removing the attack surface that
sudo(and alternatives) is, is probably a net positive.That attack surface is not vanishing. It’s would be relocating the same attack surface to something that might have an xz library in memory.
- The attack surface is there either way, this is just functionality repackaged that existed already before (
systemd-run, which is calling into PID1) - all compression libraries (actually most libraries at this point) are
dlopened on demand (which was planned even before the attack, which is speculated that the attack was accelerated in timeline because he was on a timer before the change was released)
- The attack surface is there either way, this is just functionality repackaged that existed already before (
As Microsoft and Poettering intended.
So I don’t even use systemd myself I run OpenRC. Yet honestly I find the idea quite intriguing, having the service manager (PID 1) invoke the command seems like a cool idea to me.
It’s not really a sudo alternative as much as it is another way of doing something similar.
This is why people don’t like systemd…
Systemd monolith - worst thing to have ever happened to Linux
Wayland monolith - best thing to have ever happened to Linux
I think wayland has potential but in it’s current state it’s just half baked. Once more protocols get merged,
maybe in a decades timeWayland should be quite flexible and robust.More like over baked but still only half done.
It does have potential. I think anyone denying that is simply wrong. the issue with wayland is purely how slowly it moves and the fragmentation. Now the fragmentation is actually in large part due to how slowly it moves. There are numerous WIP protocols that will greatly decrease fragmentation when all are merged.
I can’t wait because it seems like it will happen in the short future of one or two decades xD
That’s how I feel as well. IMO it’s ridiculous that Fedora wants to remove xorg completely from the repos in the next version.
It is ridiculous. Nothing like says f you to a large percentage of your user base like pushing out a solution that doesn’t work for them.
The wildest thing is that current xorg package is maintained by the community and they’re still removing it completely because “xorg is taking up too much dev time”.
hey, many of us dislike both equally! (specially the push to become the only alternative)
Oh you had me going in the first half. Sly devil you. Wayland still doesn’t work on the fleet of equipment we have.
If they had named it systemd-x11 people would hate it.
Wayland monolith
There seems to be misunderstanding about what Wayland is.
Wayland is set of protocols. They are implemented by wayland servers (compositors) and wayland clients (applications) themselves. There is no single “wayland binary” like in the X11 days. Servers or clients may choose to implement or not implement a specific protocol.
I think what they meant is that there are people that think: “Wayland is too fragmented, there should be 1 ‘Wayland Compositor’ and the rest should be window managers”
Nope, I meant that the wayland compositors are inflexible monoliths that are so tightly integrated into a DE that they can’t be replaced. Xorg might be bloated, but it follows the UNIX philosophy closely enough that each part of the stack above xorg can be trivially replaced.
I guess my interpretation was too charitable.
Nothing in the protocol prevents you from splitting the server from the window manager, just everyone implementing the wayland server protocol didn’t see any benefit in splitting it out.
X11 is a protocol too. Xorg is the binary you are talking about
Sure, but that doesn’t change the fact that Wayland compositors are forced to be inflexible monoliths that need to be so tightly integrated into a DE that they can’t be replaced.
In xorg the server, wm, and compositor all do their own thing and can be replaced trivially. It took me like 5 minutes to replace xfwm4 with i3, and that included the research.
They’re also all shit and dysfunctional as hell. Xorg forever. Systemd good too.
MacOS 7 forever, in the same way
Wayland is set of protocols.
Oh my god! It’s like hearing the same on hold greeting again and again. WE KNOW!
A lot (and I mean a lot) of criticism can be leveled at systemD. One of the upsides of it becoming popular is the standardization of much of things from the developers’ perspective. It’s easier to target multiple distros when you can rely on systemD’s single implementation of the feature. Over the next decade, I forsee systemD eating more and more of the userspace, until you are only left with managing the differences between DEs and which display server they are using. We’re already headed towards immutable base systems with apps shipping with their own dependencies, which we reduce the differences between distros even further.
until you are only left with managing the differences between DEs
Maybe they’ll add a DE as well?
Just kidding!
SystemDE
systemde
Don’t give them ideas 😂
If Canonical and RedHat weren’t backing different horses (Snap vs Flatpak), I could see the app containerization system coming under systemD as well fairly soon. The Cosmic DE project uses functionality from systemD to overlay changes onto the system that are reversible, so that alpha versions of Cosmic can be tested without permanently changing the base system. Imagine apps shipping on whatever container runtime, and dynamically overlaying system-level changes as needed for things that tap into the host system via systemd-sysext.
gross!
