The text color schema for the website is a bit rough for reading. Gray-on-white isn’t a great combo
Flatpak Will Depend on Systemd
51–60 of 141 posts
Re: Flatpak Will Depend on Systemd
#52Linux Desktop is starting to smell a lot like Android now judging by how vertically integrated it is becoming. With the push for a permissively-licensed (MIT, BSD etc.) userland and concentration of developers within a small group of companies and orgs sponsored by them, they might eventually do what Google is doing and start delaying releases for sourcecode, or stop altogether. (MIT, BSD and other licenses do not ma…
if people want that they will keep using and supporting (and contributing to) Debian. so far it seems that there's quite some trust toward these projects.
the evolutionarily optimal ratio of predator:prey fluctuates based on how close/far are we to ZIRP.
Re: Flatpak Will Depend on Systemd
#53As a Linux normie, I've never understood why systemd is/was so much opinioned about.
It violates the Unix philosophy of 'do only one thing and do it well', but personally, it has never been a problem for me. I had a nightmare last week wherein I read a headline that systemd was writing its own kernel. When I woke up I realized it was a possibility, after all it has replaced GRUB. https://wiki.archlinux.org/title/Systemd-boot
> after all it has replaced GRUB.
With unified kernel images there is no need for grub or any other bootloader anymore. And UKI simplifies boot configuration and helps improving security in some aspects.
Re: Flatpak Will Depend on Systemd
#54Earlier quoted context omitted.
People seem to think it tries and do too much. As a sysadmin I love systemd, especially way more than the init scripts it replaced
It's not that it does too much it's that it's monolithic (you can't necessarily swap out components) combined with the fact that the project is gradually subsuming more and more of the userspace utilities. Having the entirety of the userspace half of the OS under a single umbrella seems like a bad idea.
I think it came from the necessity for rapid integrations between different parts of the OS. And if it is handled as a single project it takes less time to improve it, since you don't have to align with 10 different projects and their release cycles.
Re: Flatpak Will Depend on Systemd
#55There will be more of this going forward, I think. Systemd is really not just an init system, it's a full cohesive management system for Linux distros and they've never pretended otherwise. A modular one but still a comprehensive one. Because of that its mere existence is an affront to many people with traditional opinions on Linux and Unix.
systemd-appd sounds like it could make some inroads in the threat model that Windows and Linux still have in 2026 (and macOS is still reeling from): anything that runs as my user, can access anything running as _my_ user. I don't think this threat model was tenable in 2016, much less in 2026. But moving away from that also breaks with the Unix tradition.
Systemd as the system management layer is becoming a centerpoint for moving Linux forward, on servers but especially so on the desktop, and it does so at the cost of breaking with traditional views. It's kind of hard to watch: I want Linux to move forward, and there's just a lot of good ideas there. But it will be painful for a large Linux community to break with traditions.
Re: Flatpak Will Depend on Systemd
#56> Systemd-appd gives applications an identifier and stores their permissions
Soon systemd will sniff more data - such as the age:
https://github.com/systemd/systemd/pull/40954#issuecomment-4...
And the usual copium aka this is very harmless, nothing evil is done, nothing bad can happen. That'll cover the age.
In the future systemd will sniff for more private data. For those who think this is a conspiracy theory, well - look at the last some decade or so, and query which claims made early on, about systemd, suddenly become true at a later point in time.
The systemd folks are kind of smart, though, because they provide "merely an init system" (right? Or was the comparison always unfair, because e. g. sysinit never was about adding layer of layer on top of layers) and they build on top of it, for other applications to tap into systemd - at the cost of adding a dependency.
Even LFS/BLFS succumbed recently and now only offers systemd-builds. Personally I think this is kind of betrayal to the spirit of LFS, but Bruce gave an objective argument, which is the time investment for maintaining non-systemd and systemd, and on this particular point he is quite correct. Time is a finite ressource.
What we kind of see here is that systemd keeps on growing and growing. It is the ultimate virus. You can't get rid of it. Now flatpak fell for it too, though objectively speaking I fail to see why flatpaks should have a dependency on systemd to begin with. Thankfully I use versioned AppDirs (similar to GoboLinux) so I could not care any less about flatpaks (don't need them, I already use any version of a program I want to), but flatpak also betrayed its original vision. For some reason those grand visions always become worse over time.
But no worries folks - we know one thing is true, and that is that systemd will grow even bigger. It will not stop until it has swallowed EVERYTHING.
Re: Flatpak Will Depend on Systemd
#57Earlier quoted context omitted.
Okay so back in ~2000 the audio system in Linux was ALSA and it kinda sucked so along come a guy named Lennart Poettering who wrote pulseaudio which improved things in a lot of ways but also kinda constantly didn't work. Poettering in those years constantly blamed everything on other software in the stack and became kinda wildly disliked. We all had to use pulseaudio though because everything important decided to int…
Yes, but people learned from issues that pulseaudio had and then came pipewire. Everyone is happy now. I don't know about the philosophical aspects, but from pure technical point of view systemd brought some order into the mess. Before systemd it seemed like most distros were barely holding together with duct tape. Systemd standardized a lot of things. I am fine with a little bit of controversy if the result is a muc…
Important to people being happy now is that Lennart Poettering didn't write pipewire.
Also having a bunch of things barely held together with duct tape is part of the philosophy.
Re: Flatpak Will Depend on Systemd
#58Flatpak project maintainers, please do not do that. Leave Flatpak universally accessible. I like my alternative Linux distros without systemd.
Re: Flatpak Will Depend on Systemd
#59As a Linux normie, I've never understood why systemd is/was so much opinioned about.
Okay so back in ~2000 the audio system in Linux was ALSA and it kinda sucked so along come a guy named Lennart Poettering who wrote pulseaudio which improved things in a lot of ways but also kinda constantly didn't work. Poettering in those years constantly blamed everything on other software in the stack and became kinda wildly disliked. We all had to use pulseaudio though because everything important decided to int…
Well, for ALSA and pulseaudio, the latter more or less just surfaced the tons of bugs in the underlying, at the time very shitty audio drivers. Remember, only pulseaudio is a sound server, so ALSA wasn't even exercising many of the more "advanced" features, and drivers were only supporting the most basic stuff.
Re: Flatpak Will Depend on Systemd
#60As a Linux normie, I've never understood why systemd is/was so much opinioned about.
It is a fantastic init system/service supervisor. My problem with it is basically everything else. I think its developers see systemd as central to the entire system, basically the userspace counterpart to the kernel. I prefer the approach of 'dinit', but I understand why they designed it that way. Due to this design they often have underspecified interaction between the different components, since the assumption is…
I will add this:
if you treat systemd as one trick pony and use for few use-cases which developers envisioned - it run flawlessly, but moment do something not in this path prepare for problems and inferior experience (example of randomly picked tool: timedatectl - no force update date like ntpdate command, you cannot quickly insert ethernet cable update date and disconnect... need to wait for synchronization)