惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

N
News and Events Feed by Topic
Malwarebytes
Malwarebytes
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
C
Cybersecurity and Infrastructure Security Agency CISA
F
Future of Privacy Forum
C
Cisco Blogs
T
The Exploit Database - CXSecurity.com
A
Arctic Wolf
S
Securelist
K
Kaspersky official blog
S
Schneier on Security
T
ThreatConnect
T
Tenable Blog
Spread Privacy
Spread Privacy
T
True Tiger Recordings
AWS News Blog
AWS News Blog
F
Fox-IT International blog
量子位
T
Threatpost
V
Vulnerabilities – Threatpost
C
CERT Recently Published Vulnerability Notes
Cisco Talos Blog
Cisco Talos Blog
GbyAI
GbyAI
宝玉的分享
宝玉的分享
腾讯CDC
G
Google Developers Blog
aimingoo的专栏
aimingoo的专栏
Cyberwarzone
Cyberwarzone
有赞技术团队
有赞技术团队
S
SegmentFault 最新的问题
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
V
Visual Studio Blog
U
Unit 42
雷峰网
雷峰网
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
Simon Willison's Weblog
Simon Willison's Weblog
O
OpenAI News
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
The GitHub Blog
The GitHub Blog
The Register - Security
The Register - Security
MyScale Blog
MyScale Blog
小众软件
小众软件
A
About on SuperTechFans
Last Week in AI
Last Week in AI
Y
Y Combinator Blog
博客园 - 三生石上(FineUI控件)
美团技术团队
Google Online Security Blog
Google Online Security Blog
P
Proofpoint News Feed
MongoDB | Blog
MongoDB | Blog

Lobsters

abyss * your_dotfiles_are_not_a_distro Vivado Licensing Options How my minimal, memory-safe Go rsync steers clear of vulnerabilities From AFSK to Goertzel the entropy layer of a wavelet codec, on its own 10,000 Lines Later: When a Tool Became a Compiler - Rob Durst - Gleam Gathering 2026 Debian SE Linux and PinTheft fht-compositor: A dynamic tiling Wayland compositor A Network Allow-List Won't Stop Exfiltration — André Graf Does bulk memmove speed up std::remove_if? (No.) What is Git made of? wake up! 16b 声明式部分更新 | Blog | Chrome for Developers Don't Roll Your Own ... Dianne Skoll's Web Site - Remind “Long-Term Support” doesn’t mean what you think The Architecture of Open Source Applications (Volume 1)Berkeley DB Pardon MIE? - ironPeak Blog seriot.ch It's time to talk about my writerdeck hershey Cuneiforth: A Forth for your Chifir z386: An Open-Source 80386 Built Around Original Microcode waylandcraft - Minecraft Mod On the <dl> HP QuickWeb, Singular And Pointless mvm - a fast virtual machine for Go That one time I used Go panics for flow control A new suite of modern tools coming for editing and publishing RFCs From the Tabletop… The Digital Antiquarian .NET (OK, C#) finally gets union types🎉: Exploring the .NET 11 preview - Part 2 Revised^7 Report on Scheme, Large: Procedural Fascicle Draft is now public The Soul of Maintaining a New Machine - Third Draft | Books in Progress
Flatpak will depend on systemd – OSnews
osnews.com v · 2026-05-25 · via Lobsters

 Home > Linux > Flatpak will depend on systemd

If you visit the Flatpak website today, it lists, as the very first advantage of the project: “Build for every distro: create one app and distribute it to the entire Linux desktop market.” If you then move on to the list of supported distributions, you’ll see the usual suspects, but also distributions like Void Linux, Guix, and Alpine. These last three all have one thing in common: they use an init system other than systemd, because Flatpak doesn’t care what init system you use. It seems that for the next major version of Flatpak, however, that’s going to change: systemd will probably become a dependency for Flatpak.

Speaking at the Linux App Summit, Arian Vovk and Sebastian Wick held a great talk about the future of Flatpak. The current version of Flatpak will continue to see a ton of improvements, but at the same time, the limits of what can be done with its decades-old design have become harder and harder to work around. As such, they’re also planning for and working on what they call Flatpak Next, or perhaps Flatpak 2.0, which is effectively a rewrite of Flatpak based on what they’ve learned over the years, making use of modern technologies and ideas that have gained ground since the initial design of Flatpak 1.x.

It’s important to note that everything discussed during the talk is planning, and not a single line of code has been written yet. This means that all of these plans are subject to change, and as the work progresses over the coming years, the end result may turn out very different from what’s been detailed in the talk. In addition, and I can’t stress this enough: if anything in this discussion gives you even the smallest of inklings to go and harass, attack, insult, or otherwise bother anyone involved in Flatpak, systemd, or related technologies, please be so kind as to book an appointment for a yoga class or whatever. It seems like you need it.

Right at the onset of the talk, Vovk and Wick explain that they want to move the permission management from Flatpak into the service layer, through a new service called systemd-appd. Systemd-appd gives applications an identifier and stores their permissions, and then this data can be queried by the rest of the system. In turn, this enables a slew of other features, not least of which is subsandboxing. At the moment, the plan is to introduce this feature in the current version of Flatpak, thereby introducing a dependency on systemd into Flatpak.

From what I understand from Vovk, they were intending to be “super considerate” of distributions and people not using systemd, which I take to mean we’d eventually end up in a situation very similar to systemd-logind, which was extracted from systemd into a separate daemon, elogind, so that distributions using other init systems could still make use of desktop environments depending on systemd-logind. I imagine Flatpak developers wanted to make as many affordances as realistically possible for something similar to happen to systemd-appd, thus ensuring Flatpak would remain available on distributions not using systemd.

Obviously, people who are using distributions like Void or Alpine were concerned about the future of Flatpak on their systems. If Flatpak gains a hard dependency on systemd, Flatpak would no longer work on distributions without systemd, so the talk raised questions – sadly, it seems the questions were directed at someone not technically involved with Flatpak development, and his replies were not particularly helpful and often just downright insulting and inflammatory.

Even though he’s not involved in Flatpak development, enough people assumed that he was, and a toxic brew stirred. Users with genuine, friendly questions about the future of Flatpak on their systems were met with derision and insults, and it spiraled out of control from there, drawing in the rabid anti-systemd Red Hat conspiracy lunatics (and worse). Things got progressively worse for everyone involved, particularly for Flatpak’s developers.

And so we ended up at the situation where everyone’s mad and Flatpak’s developers are “not feeling inclined to spend [their] time on that shit anymore” when it comes to accommodating and making affordances for distributions and people not using systemd. The end result will most likely be that any future Flatpak dependency on systemd will be stricter, and making any independent elogind-like daemon will be much harder than it was going to be. Nobody wins, everybody loses, all because some people thought it necessary and productive to be insulting and inflammatory.

As things currently stands, it’s very likely that over the coming years, Flatpak will gain a dependency on systemd, possibly without any affordances for an independent daemon to replicate systemd-appd functionality on distributions that do not use systemd. In other words, Flatpak would no longer be able to boast that it enables “Build for every distro: create one app and distribute it to the entire Linux desktop market.”, as it would no longer be distribution-agnostic. And that’s a shame, because Flatpak fills a real need for users, regardless of whatever init system they use.

Which is apparently something some people base their entire identity on, because they’re weirdos.

About The Author

Thom Holwerda

Follow me on Mastodon @[email protected]