While I think systemd is a great init system (as well as some other components under the systemd umbrella), I really dislike when components up in the stack hard-depend on it. We can't use GNOME, plasma-login-manager, and soon Flatpak without systemd.
Maybe systemd should have been an API + a spec instead of an unportable implementation.
The headline is inflammatory and misleading. IIUC, flatpak is not depending on systemd as a whole, they're depending on a new component called systemd-appd, which does permissions stuff. This will allow alternate implementations, like how elogind grew out of systemd-logind.
IOW, it is an API + a spec, just like what you're asking for. But it's implementation first, because any API + spec designed by committee rather than being driven by an implementation universally sucks.
This avoids the question, apparently because the design of this part makes it certain that when it does come into existence, it will depend on the rest of systemd.
The problem with systemd is that it's purposefully designed to be a viral monolith, without this it's got no purpose. We've been with this long enough to pretend otherwise.
> The problem with systemd is that it's purposefully designed to be a viral monolith
Is it though?
Systemd is a project, not just a piece of software. It's got a lot of libraries that are reused across the different components that the systemd project ships. It's not that different from how most C/C++ projects have their own standard library built on top of stdlib/boost/etc. Any new "systemd project" could be done as a completely standalone piece of software, but it would mean recreating a lot of the libraries that already exist.
The biggest piece of coupling to systemd isn't really specifically systemd itself but how systems rely on how systemd does certain things, namely, cgroups. No one wants to manage cgroups themselves, so they use systemd to start services and put them into the cgroup hierarchy, etc. This is exactly one reason desktop environments "rely on systemd" (among others).
Why does everyone want to use cgroups (and thus systemd)? Because it makes managing groups of processes easier, which is directly tied to handling user sessions, which as it turns out, is something most applications want, since typically they deal with users!
Now, systemd's own sub-projects, (eg appd), are likely to be yet another consumer of systemd for similar reasons.
Using systemd, and building on top of it makes it much easier to implement features without having to do everything yourself.
It's not a monolith, which is obviously true because there is no distribution that ships all of it turned on by default. Fedora comes close, but most other distros pick and choose which parts of systemd to use.
systemd-appd will likely depend on some but not all of the rest of the systemd system.
But the original question is beside the point -- systemd-appd will provide an API that can be implemented by others. I doubt the questioner actually cares much about how much of systemd systemd-appd pulls in, they want none of it.
I'm all for integration of system services if it helps bring a more cohesive OS. Interchangeability is a nice thing when building a system but I don't need it as a user.
No. From your tone it sounds like it's probably not as easy as you'd like. I don't really have a response to that. System customization is not something I'm interested in.
Can you share what was that thing that didn't work with systemd? I've seen pretty crazy setups and can't quite imagine how horrid of a mess those would have been if a large rc.init shell script ridden with sleeps was used instead.
Last time? Getting pppoe to automatically start and restart if it dies. Or not that, but setting up everything for a custom router with proper dns, firewall and all the other crap, without using crippled systemd versions for services that i couldn't even uninstall because of dependencies.
Maybe it's Ubuntu's fault since they seem to want to run in containers not on bare metal lately.
Where none of the desktop environments offer the same feature set. And the more compositors there are the harder it is for apps to use those new protocols, and guaranteeing a ton of bug reports from users using an unsupported compositor. That just hinders Linux desktop app development.
I doubt that. But they clearly thought that people should have a choice. And it is great. But fractured community using different tools for the same task makes slower progress. Each approach has its positives and negatives.
I think it is great that we have wayland and systemd. It will eventually lead to something greater in the future.
> Maybe systemd should have been an API + a spec instead of an unportable implementation.
There's nothing really stopping other init systems from implementing it's unit spec, some hobby ones have done so.
In the case of GNOME, KDE etc depending on it, the reason mainly boils down to "we could implement our own manager for handling desktop daemons etc or just get systemd to do it for us"
But why would they do so? That makes no objective sense.
Systemd never was "merely" only an init system. And it makes no sense for init systems to grow to systemd-size either, in order to solve non-init related issues.
> In the case of GNOME, KDE etc depending on it, the reason mainly boils down to "we could implement our own manager for handling desktop daemons etc or just get systemd to do it for us"
That's not quite true. GNOME always was close to systemd devs due to funding. KDE was less close, but even within KDE some people lobbied for it such as dave edmunson or however you spell the name, and "me-needs-a-donate-daemon" Nate, who you are not allowed to critisize on #kde reddit. But I agree that they could simplify some code by depending on systemd. Of course this now means that KDE is sold in a dead-lock with systemd. I wonder if I can still use konsole without systemd. I tend to use iceWM since it is so much faster than KDE or GNOME, but when konsole depends on systemd I may indeed need to switch to another terminal. That will be painful though, but there is no stopping systemd - it infects and taints.
systemd was a "gift" for people running alternative desktop systems. Previously, many services were bundled with GNOME and you had to go through many hops to use them on a non-GNOME desktop (for example, GNOME Power Manager). systemd replaced many of these GNOME-only piece of software that were constantly breaking when you tried to use them outside of GNOME. Alternative desktop environments didn't need to write their own version of system-related tools.
So, while this may be seen as centralization, I don't think we would have seen so many desktop environments without systemd. In the past (15+ years), systems were simpler and there was not many things to abstract.
That is a good point but it isn't mutually exclusive with the idea that systemd ought to be a standardized API as opposed to a reference implementation without a standard.
Also despite all its convenience it's not without its drawbacks. Among other things you can no longer just launch a daemon from a chroot now you need a full blown container sporting its own init.
FWIW GNOME can be used without systemd, and this is how Guix System does it. I think over time more and more components are depending on systemd, but at the current moment it is still feasible to swap them out for replacements that don't.
Can it still? IIRC Guix still has GNOME 48 while GNOME said they'll be increasing they dependence on systemd after version 49 or 50[1]. I'd be happy if Guix can support future version as this seems like an end game distro for me, and I'm (slowly) looking into moving there but my understanding is I'd need to stay with KDE Plasma in the long-term.
You are right, work on packaging GNOME 49 is still ongoing & may take a while (it is a hard job and not many people are working on it). It is not considered a dead end yet, as far as I can tell:
> Has KDE committed not to hard-depend on systemd in the future? I would be glad to discover that.
I was reading somewhere some KDE developers were saying that while some of the components (like plasma-login-manager) might depend on systemd, the core Plasma will not. They're the only major DE remaining on FreeBSD after all.
A gentoo dev actually showed that GNOME can work without systemd. The gentoo wiki explained it.
I never tested this myself, as I also dislike GNOME3 from a UI view (I am fine with mate-desktop though), but I found this to be epic from the Gentoo folks - a single man flipping a finger to the systemd devs. The underdog winning the fight.
A shame gentoo kind of went into its own hole for years ...
I think we should reserve judgment until this lands in the hands of the people it helps.
My experience is limited to my elderly parents who have trouble seeing. With the text size Apple allows them to set it to, their phones are unreadable. Text runs off the screen in every app, 1st and 3rd party.
In their bill example, the user is told to confirm with the provider. Why not offer to call the number on the bill? Instead of telling them to use text detection, do it for them? Presumably Apple Intelligence would already have that capability. I’m afraid this will be a gimmick at best.
EDIT: Forgot to mention, the grip is good to see. Hopefully they don’t charge the apple tax on it.
Yeah, I used to use iOS with text one step above the default size, and text was often cut off.
I have a problem with astigmatic halation that makes ‘dark mode’ difficult to read. Since iOS 26, multiple aspects of the system have been made dark only, contrary to the system setting. Writing text correctly should be the lowest of low-hanging fruit.
I suspect this is more of a flashy ‘AI’ promotion rather than reflective of any real commitment.
I had to set macOS on high contrast to be able to differentiate ui elements at glance. But most electron-based apps do not get the hint or even provide a high contrast theme.
It's prob why they chose a11y features. They have more pain, so they're willing to tolerate more growing pains. (And prob more motivated to provide feedback.)
I think the above person was making a commentary about the things Apple chooses not to do. Apple strategy is often to be intentionally last to market, after the dust settles.
The dust settled on these accessibility features years ago. Why would Apple choose not to do these things? Live captions in particular is useful even for those who are not hard of hearing because it lets people watch uncaptioned videos in environments that are too noisy or that need to be quiet.
By "dust settled" I don't mean that the technology "exists" -- but rather that feature development has slowed down and most products have stabilized as feature complete and mature.
The on-device ML models that are being used by Google and Apple are both quite new and in active development.
Many of Apple's most successful products have shipped years or even a decade after their competitors. They have tried using first-mover advantage in the past but typically fail when using that strategy.
They're in active development, but they already worked well at launch in English in 2019, serving enough customers to be very useful. I was using it myself.
Yeah, Apple releases most of their products/features long after competitors have useful products/features of the same type. This really isn't any different.
I agree. There seems to be a lot of potential in this space (from my outsider view). I really hope that this issue from an earlier article (https://news.ycombinator.com/item?id=48178378) doesn't become common enough to make useful functionality like this a danger. Seems unlikely in the short term but as use cases grow, so might the bad actors.
Let's be honest, compare the amount of money a corporation can make helping visually impaired people to the amount of money they can make replacing software developers and financial analysts.
Don't get me wrong, Apple using these technologies to help humans who are in need of help is laudable. But let's not pretend we don't know why most corporations don't look into this kind of thing. I think if we're being honest, we all very much know why they leave this sort of thing to the always nebulous "others".
> “When we work on making our devices accessible by the blind,” he said, “I don’t consider the bloody ROI.” It was the same thing for environmental issues, worker safety, and other areas that don’t have an immediate profit. The company does “a lot of things for reasons besides profit motive. We want to leave the world better than we found it.”
Apple's competitors have had these features for years (Android for 7, Windows for 1), so it's really an indictment of Apple. They give lip service to helping the visually impaired, and this press release is good marketing for the non-visually impaired people who don't know this.
Really? I haven't used Android recently, but I very much doubt 7 year old Talkback was any where near as good as Voiceover. I also haven't seen a single accessibility improvement in Windows recently. The most accessible Windows apps are usually based on older toolkits like win32. Edge is very accessible, but 99% of that comes from Chrome.
Aren't the LLM-based features of this announcement catch-up features? Describing the contents of the screen is something Gemini has been doing on Pixel phones for a while. It's a fairly obvious use case for a multimodal AI.
My one hope is that this eventually becomes widespread enough to stop alt text scolds.
The constructed policy is quite strict and expects certain UEFI things to be set up correctly. For example both this https://github.com/canonical/secboot/blob/7434bac27844362ff8... and https://github.com/canonical/secboot/blob/7434bac27844362ff8... are enabled in the policy. The policy choices and various early checks, even as trivial as confirming that the TCG log content is correct after booting into installation system, are enough to rule out a lot of potentially problematic EFI deployments. Effectively making it more strict helps avoid a lot of funny issues where the firmware is clearly buggy and things would fall apart sooner or later.
Strict is probably good. My company started to enable bitlocker this year on win11, and a non trivial amount of initial encryptions seem to be failing, destroying the user data and requiring a full reformat.
For a someone looking to switch from a M-series MacBook to a Thinkpad, which one would you recommend? Preferably not of a diminished quality, so I can daily-drive Ubuntu without missing Apple.
Because Codeberg is a proper non-profit association ("Codeberg e.V.") which makes it more than "just another forge". With that said, I do wish decentralized/distributed forges was used more, git unsurprisingly fits well with it.
Not everyone wants to run their own infra. But at least Forgejo works on the distributed network of projects, so in the future it should be easy to migrate if needed.
My parents didn’t monitor what I was doing on the internet when I was growing up in 00s. I saw a lot of shit and wasted a lot of money on GPRS and WAP portals. I learned from my mistakes and I’m glad I did. I wouldn’t want to monitor everything my children do either.
I do want C++ to be a safer language, but I don't think inheriting the Rust safety model is the way to go. It is in a way revolutionary but has major downsides like inability to deal with cyclic data structures without clumpsy workarounds.
I don't want to play with a plastic sword, just put it in a sheath.
Maybe systemd should have been an API + a spec instead of an unportable implementation.
reply