Flatpak 2.0 seems to depend on systemd

[-]

Zettinator@reddit

Standardizing on systemd as the system layer is perfectly fine. Linux desperately needs more standardization.

[-]

Damglador@reddit

Not when your main selling point is being compatible with all distros

[-]

Given some distros are fully headless wasn't it always not compatible with all distros given it is for gui software.. There has to be some ability to rely on some things as standard, a lot of software assumes some level of bash compatible shell, pulse audio/pipewire.

[-]

Damglador@reddit

Flatpak claims to be universal for all desktop distros. Some desktop distros don't have systemd.

[-]

InfiniteSheepherder1@reddit

So? It also requires dbus if I have a distro without dbus is that a problem that flatpak does not support my niche distro.

Flatpak does not work on things based on the Linux kernel with drastically different user space like Android. Same thing with dbus and systemd that is going to be the user space it needs.

[-]

Damglador@reddit

The difference is that: 1. dbus is already somewhat of a dependency for any desktop 2. dbus isn't... how to say that, hard to get? Like systemd is. You can have only one init system, but you can have multiple IPCs and I reckon you can also run dbus on Android (in Termux). So it's not comparable.

[-]

ScratchHistorical507@reddit

*all distros of any relevance. Nobody gives a damn about morons that insist on not using systemd just because. Sure, it's their decision not to use it, but then it's also their burden to bear the consequences of that decision. Absolutely nobody should feel pressured in any kind to cater to these people stuck somewhere in the 90s and that will eventually just die out.

[-]

Damglador@reddit

Build for every distro

Create one app and distribute it to the entire Linux desktop market.

Straight from flatpak.org

[-]

ScratchHistorical507@reddit

Straight from flatpak.org. And from my knowledge of English, entire means entire, not excluding 1%

They aren't excluding even a single percent. And if you stuck with the truth, they aren't excluding anyone, as absolutely nobody stops them to make Flatpaks work on their distros.

rude of you btw

Rude of those morons to expect the world to revolve around them. They want to cause lots of additional effort, they have to do the work.

[-]

mattias_jcb@reddit

weren't Linux supposed to be about choice

In the sense that you get to build your own thing and take full maintenance responsibility of all the choices you make: yes.

In the sense that you imply: No. That's never been there case.

[-]

NDCyber@reddit (OP)

Relying on it for something as big as flatpak can be rather problematic, because competition will just fail by default and you will get stuck on one way in the future, when it might no longer be the best option

Not to forget that flatpak gives instructions on how to install flatpak on distros not using systemd themselves at the moment, so the people using that have the potential to just be left behind

I agree that it isn't a big thing for something like KDE login manager, but something as universal as flatpak is more problematic if you ask me

[-]

Business_Reindeer910@reddit

i think the systemd primitives it requires will be abstracted just liek they were before.

[-]

NDCyber@reddit (OP)

Hopefully, but still the responses and how it got treated there is a bit odd. i will wait to see how it will actually end up, but for something like flatpaks relying on systemd just leaves a bad taste in my mouth

[-]

mattias_jcb@reddit

Hopefully, but still the responses and how it got treated there is a bit odd.

I wish you could understand how tiring it becomes having to deal with a very loud and small minority that demands that you cater for their needs even though you never targeted their use case to begin with.

Like: yes! If Flatpak decides to hard-depend on systemd some users doesn't get a free lunch any more. The polite thing would be to say "Okay! Thanks for all that we got in the mean time" and leave it at that or if you're a programmer and you think reimplementing systemd (instead of just using it) is worthy of your time you could do that.

[-]

NDCyber@reddit (OP)

Thing is, Linux community in general is in my experience also seen as a rather loud minority that demands that you cater for their needs. There you then see the same argument

And if flatpak didn't want to have that kind of responsibility they shouldn't have marketed themselves as "Create one app and distribute it to the entire Linux desktop market", because as they say themselves there. Like I get that it is annoying and costs money, but at the same time, that was their promise, and it seems like possible lie. And especially that rubs me the wrong way

Like they build a program to work on the entire Linux desktop market, and halfway through they just throw a lot of people who rely on them under the bus

[-]

mattias_jcb@reddit

Thing is, Linux community in general is in my experience also seen as a rather loud minority that demands that you cater for their needs. There you then see the same argument

Yes, and I agree when game developers for example doesn't publish for Linux because not only are we horrible at presenting them with a solid platform to target you also get to deal with a community so toxic we're putting Star Wars fans to shame.

And if flatpak didn't want to have that kind of responsibility they shouldn't have marketed themselves as "Create one app and distribute it to the entire Linux desktop market", because as they say themselves there. Like I get that it is annoying and costs money, but at the same time, that was their promise, and it seems like possible lie. And especially that rubs me the wrong way

The issue here is that you take this literally to the point of absurdity. The user base we're talking about is a rounding error.

Also the statement "Create one app and distribute it to the entire Linux desktop market" if interpreted maliciously was never true. I can easily make it untrue by choosing one of the dependencies of Flatpak, hacking together a distribution using Buildstream and add a policy decision that "This dependency in particular is banned!!". This would obviously be an even more absurd endeavor than what you're doing but it plays in the same ballpark.

Like they build a program to work on the entire Linux desktop market, and halfway through they just throw a lot of people who rely on them under the bus

We don't have the data necessary to be sure so I'm going to speculate (just like you) and say that we're not throwing "a lot of people" under the bus. I doubt you can count these users by a fraction of a percent.

[-]

NDCyber@reddit (OP)

The issue here is that you take this literally to the point of absurdity. The user base we're talking about is a rounding error.

Or do I just take it to the same point flatpak 1 was at? Flatpak works fine under non systemd systems. It also has instructions on how to get flathub working

And if you don't understand how it is a problem that those people will just get thrown under the bus then i don't think a conversation between the two of us will result in and useful outcome and we should let it be

[-]

mattias_jcb@reddit

And if you don't understand how it is a problem that those people will just get thrown under the bus then i don't think a conversation between the two of us will result in and useful outcome and we should let it be

I am aware. My point was more that lets say there would be two systems like that, I could imagine people just choosing 1 instead of 2 for some application and 2 having no real chance, just because it isn't 1

But that is a whole different topic

[-]

mattias_jcb@reddit

You can't build upon something so fundamental as systemd being replaceable. Well you can but you're building an entirely different system comparable to Android or ChromeOS. Like Linux is great because you can build things like that but we needed to move towards a more consolidated view of what desktop- and server Linux is twenty years ago. And we did! And ten years ago we were arguing about all this stuff a lot and I just don't understand why we haven't gotten past this. It's extremely frustrating if you care about Linux succeeding.

[-]

ScratchHistorical507@reddit

because competition will just fail by default and you will get stuck on one way in the future

If competition can't be bothered to get the basics right, it can't really be considered competition to begin with. And if there's something better to ever come around, who says it won't be supported? Right now there is just no need to waste any resources to support anything else. If people think they need to not use systemd, they as well should carry the burden of keeping everything compatible with their niche solution.

so the people using that have the potential to just be left behind

And it's high time to leave those people behind just like it's time to leave everyone behind that still insists on using the X windowing system over Wayland just because. They have held back progress for too long already, no resources should be wasted on this infinitesimally small niche within a small but growing niche.

I agree that it isn't a big thing for something like KDE login manager, but something as universal as flatpak is more problematic if you ask me

Neither is any kind of problematic. You insist on refusing to use what has been established to be the common best solution for everything? You do the work this causes yourself, simple as that.

[-]

dontquestionmyaction@reddit

Good job immediately making a massive drama with large maintainer hostility out of one guy voicing an opinion not even officially announced by the project.

[-]

NDCyber@reddit (OP)

Good job not understanding the point of the post. I posted this to one see how people would react and second get more information than I was able to get on my own, especially because it was late in the night. Which I did. Like said in Edit 3 "in the Linux App Summit 2026 the flatpak presentation had a slide talking about systemd-appd dependencies https://youtu.be/1AXBfsiaQNk?t=16218"

There was also of any form of hostility planned or made by this post

It is also not just a guy. Here something a GNOME Contributer (blackcain) said "Sebastian Wick is the flatpak maintainer. Both he and Jorge were at the same conference and likely had plenty of opportunity to talk directly with each other."

[-]

mattias_jcb@reddit

I posted this to one see how people would react

You knew exactly how people would react...

[-]

NDCyber@reddit (OP)

No. I would have never expected people being like the comment section here. I mostly saw things against it on mastodon, nothing for it, and I was interested who and why someone would be for it. Plus I got information from people here I did not have before. Shocking isn't it

So please don't act like I am a devil who just wanted to see chaos or like you know me.

[-]

mattias_jcb@reddit

All I see is someone spreading and proliferating drama that was based on a misunderstanding to begin with.

So please don't act like I am a devil who just wanted to see chaos or like you know me.

Please don't assign me views I don't hold.

[-]

NDCyber@reddit (OP)

"All I see is someone spreading and proliferating drama that was based on a misunderstanding to begin with."

What do you call a misunderstanding?

Something where a lot of things point towards something relying on systemd and people talking about that is not a misunderstanding in my book. Would they now come out with specific things I would agree, but at the moment it points into that direction and that is the whole reason why this post existed. I did not think people would make a drama of people using other things than systemd. Neither did I think that people like you come in and tell me I had bad intend, even if in a subtle way

[-]

mattias_jcb@reddit

What do you call a misunderstanding?

People in the replies to Jorge assumed he was a Flatpak maintainer or part of their development team, further they assumed that there was a discussion about and a decision made with regards to a systemd dependency that he was referring to. That's not the case as I understand it.

What he was getting at (to the best of my knowledge) is that "systemd or not?" is a non-question today and has been since a decade at least. People doing real work obviously can't be held back by this crap and everyone knows it. Jorge was just being more honest than most.

This is a tangent but I think it's important so I'm going to take the time and write it anyways: People do avoid speaking truth in part because of the absolute cess pool that is the Linux community. Things you say or even pull requests you send will get dissected, misinterpreted and in the end you might see yourself doxed or getting death threats for just doing your job. This obviously must stop and part of that is to not try to gather a storm on r/Linux and other platforms to gank up on developers just speaking truth.

[-]

NDCyber@reddit (OP)

Please look at the links provided in the edits. There are actual information from flatpak themselves in there, including appd and systemd dependency and not just from that one guy

[-]

mattias_jcb@reddit

I read the stuff on Mastodon and watched all of LAS before you posted to Reddit.

[-]

NDCyber@reddit (OP)

Then I have the question on why you felt like bringing it up far after we left talk of just that one person talking about it?

There has been more clear information from multiple sources specifically about it, so my mind basically left the mastodon conversation at the time you entered the conversation

So that was the biggest part on my mind at that point, plus I will be honest I got so many messages from you at once that I just got tired as it just felt like spam, and I should have taken more time to read what you said here specifically, as I gave you a reply

[-]

mattias_jcb@reddit

You asked this: "What do you call a misunderstanding?" And I answered what the misunderstanding was. I don't really understand what your reply is about to be honest.

[-]

Venylynn@reddit

I'm waiting for them to fix the nested sandbox security problem with browsers in flatpak

[-]

Marce7a@reddit

Zypack exist for chromium browsers

[-]

Which dependency?

[-]

Venylynn@reddit

Libfuse2

[-]

Marce7a@reddit

Appimages don't need for libfuse2 for long time already

https://github.com/ivan-hc/AM#2-appimagetool

https://github.com/AppImage/appimagetool

[-]

Venylynn@reddit

They don't ship an AppImage because AppImage relies on an unmaintained insecure dependency.

snap has its own problems, like being partially proprietary. It is not a replacement to flatpak

[-]

blackcain@reddit

But it is indeed a solution. There is also just going back to packaging the projects you want or using AppImage.

[-]

NDCyber@reddit (OP)

"Snap is a software packaging and deployment system developed by Canonical for operating systems that use the Linux kernel and the systemd init system."

"To ensure this, Snap relies on systemd for features such as running socket-activated system services in a Snap. This causes Snap to work best only on distributions that can adopt that init system."

https://en.wikipedia.org/wiki/Snap_(software)

AppImages are also not available for every program. Discord as example, while it is available on flathub from discord directly

Here are other programs that I use that aren't available as AppImage but from what I know officially supported on flathub or having flatpaks: BoxBuddy, ProtonPlus, Bottles, Alpaca, Boxes, OBS, PeaZip, OnlyOffice and there are probably a good amount of programs that I just use from the AUR, that I would get from flathub on other distros

Infinity-of-Thoughts@reddit

Fedora Atomic ships the repository version, not the Flatpak version.

It's vile how these people weaponized "Code Of Conduct" into a "Mods are Gods" discord-tier masturbatory bullshit. These people are evil.

[-]

anomaly256@reddit

That's how I feel as well

[-]

NDCyber@reddit (OP)

Why is someone like that still part of something like flatpak? Like there is a chance he knows more than we do, and if he is right it would be problematic

I don't put complete trust in it either at the moment and hope for official informations

[-]

anomaly256@reddit

Sometimes people just like to assume authority on an open source project they contribute to, even when they don't have it. I've seen it a lot over the years. I think in this case though he's just stating something he believes to be obvious even if it's not concrete

[-]

NDCyber@reddit (OP)

I really hope you are right, because I would personally find it problematic to have something like flatpaks limited to systemd

[-]

Marce7a@reddit

I wonder if appd will be able do be integrated to non systemd distros

[-]

Damglador@reddit

One more reason to not use flatpak.

AppImages prove to be superior once again.

[-]

ScratchHistorical507@reddit

Sure, superior in being the most inferior packaging format ever😂

[-]

samuerusama@reddit

the most inferior packaging format ever

Because?

I can take this AppImage and run it on ubutnu 14.04: https://imgur.com/a/6pwP2AR

It also works on NixOS and non glibc systems.

It has no dependency to FUSE (which flatpak has), it will run even if your kernel has that totally disabled.

It's internal sandbox works perfectly unlike flatpak, or the hack they plan on doing that will only work on systemd.

The AppImage runtime itself only needs a kernel newer than 2.6 to work, the payload depends, but you can get like 50% of modern apps to run on kernel 3.0, meanwhile flatpak has a hard dependency on bubblewrap and that needs PR_SET_NO_NEW_PRIVS which is only found on kernel 3.5 and newer.

[-]

mikeymop@reddit

I thought AppImage requires FUSE? That's the whole reason you cannot run AppImages from Steam flatpak.

[-]

samuerusama@reddit

AppImage actually never had a hard dependency on FUSE since the type2-runtime has existed, you are likely confused with libfuse2 (which was also fixed).

The issue is that the current type2-runtime will fail if it can't use FUSE, but you can still run without FUSE by setting the env var APPIMAGE_EXTRACT_AND_RUN=1

Upstream does not want to make this happen automatically as a fallback, because when you run the AppImage without FUSE you pretty much double the ram usage of the application, I disagree that with that decision, AppImage is about downloading and fucking running the app, we should not put limits just because it uses more resources.

We use the uruntime instead of the type2-runtime, it has multiple automatic fallback mechanism in case the host has no FUSE.

It will fallback to mount namespaces if FUSE is not possible (not a feature in the type2-runtime), this is better since it will not increase the ram usage.
It will fallback to extract-and-run automatically if neither is possible.

The Steam flatpak can't run AppImage because the flatpak sandbox does not allow it.

It turns out you can do this and allow them to use FUSE, you just need to patch bwrap, we do that with the Steam-AppImage and it is mentioned in the README

[-]

mikeymop@reddit

Thank you, for the comprehensive explanation, and for the further reading!

[-]

ballsannihilator@reddit

It does require FUSE to run as intended(you execute it and it runs) and no real person uses such old kernel versions on their PC

[-]

samuerusama@reddit

It does require FUSE to run as intended(you execute it and it runs)

No!

and no real person uses such old kernel versions on their PC

Well you are wrong, a while back I saw someone make this AppImage of nvim becasue they needed it to run on a system with kernel 3.10

[-]

Damglador@reddit

Fair enough ¯\_(ツ)_/¯

[-]

icywind90@reddit

"Depend on" is not the same as "requires"

[-]

NDCyber@reddit (OP)

From the sources I saw so far and the way it seems they plan it, it seems to require systemd. This could of course be wrong, and I hope so, but from the sources I have seen so far it seems to go into that direction

[-]

themuthafuckinruckus@reddit

Jeez, the good faith questions do not necessitate the amount of snark being given.

"If you're objecting to it, then don't use it or do your own solution. But that's where the rest of us are going"

Saying something like this has no other use than deflect and ignore criticism, a problematic stance for such a big project

[-]

I didn't try to show that it is popular, just that it is well known and people are interested in it

Should have worded that better

And Jorge didn't reply in a way he wouldn't have to deal with bs, he reacted in a bs way, while people asked simple questions first

[-]

deviled-tux@reddit

People are not really interested in MX Linux. It’s a niche distro. Distrowatch is completely irrelevant because it only tracks links within itself.

I’ve been using Linux for 20 years and never once have I been past the homepage.

Using distrowatch to demonstrate anything is hilarious and futile.

I read Jorge’s reply as “are you really wasting my time on this?”.

Anyway feel free to fork flatpak or create a systemd-appd replacement. Talk is cheap. Patches are not.

[-]

NDCyber@reddit (OP)

"People are not really interested in MX Linux. It’s a niche distro. Distrowatch is completely irrelevant because it only tracks links within itself."

I am aware. But it gives some idea on what people who are going on something like distrowatch are interested in

"Anyway feel free to fork flatpak or create a systemd-appd replacement if it bothers you so much. Talk is cheap. Patches are not."

You guys really can't think that that is a valid argument. Criticism is good, Criticism is needed. Saying "hey this is bad, please don't do it, here is why" is important. You can't just ignore every criticism, because technically people could fork it. Then there is also the problem of people actually switching to the fork, which would be hard to achieve. And it would create even more solutions for a problem that should only have one https://xkcd.com/927/

[-]

RangerNS@reddit

Then stop using his stuff.

The systemd debate was played out 10 years ago.

You continue to have permission to use versions that make you feel 3l33t, and/or contribute to those versions.

You have no right to demand others so work for you.

[-]

NDCyber@reddit (OP)

Flatpaks: Market itself as "Create one app and distribute it to the entire Linux desktop market."

I mean yeah there are explenations on why he could think like that, doesn't make it better in my opinion. And every conversation he has that I see goes in the same direction on how he acts. He could have explained it in a normal matter, but instead went with "Are you serious? Of course." or "I don't know, ask them?" after being asked about non systemd distros, and it just keeps going. He did not even try to give a real answer most of the time

[-]

mattias_jcb@reddit

It was pretty weird of the person asking about non-systemd distributions to not just ask them directly? Like the only one who could possibly know what they are going to is them?

[-]

Isofruit@reddit

I don't know, I mostly care as to why somebody gives the response they do and unless that comes from a malicious place, I don't care too much.

"Then don't use it."

Good old weapon to deflect every criticism. And with the way the Linux space is going it doesn't really seem like systemd will be that optional if you want to be able to use your Distro without issues soon

I use systemd myself as a user and find it easier to use than other init systems, but having important and big programs rely on a single program like systemd brings potential issues, like if systemd would start falling apart it would still mean you would have to use it, because your programs wouldn't work otherwise. Same thing that happens with a lot of people and windows right now

So from that point alone I find it risky to do so

And that is ignoring how flatpaks are kinda meant as a universal solution. And it gets even worse with a distro like MXLinux taking the third place on distro watch and not relying on systemd for a lot of their spins. MX-25.1_Xfce_x64 defaults to sysvinit, but gives the option for systemd

[-]

Dangerous-Report8517@reddit

To be fair, there's likely a very strong overlap between systemd critics and Flatpak critics because they both introduce a lot of complexity in exchange for advanced features. Even in my case, I like and use both widely (including directly interacting with systemd, not just happening to use systems that run it), and in situations where I don't want systemd I can't think of any reason I'd still want Flatpak because it's almost universally going to be a situation where I want something that's as lean as possible, like a container environment.

[-]

NDCyber@reddit (OP)

a lot of points on why people want flatpak and not systemd seem to be that flatpak helps them get the software their repos wouldn't have

My bigger problem is also depending on something like systemd to host such a crucial part of linux distribution. If flatpaks can fix the issues they seem to fix I could imagine them getting even more important, for something like browser, because it means the devs need to put less work into hosting their own distro specific version. And having something locked behind something so replaceable seems problematic to me

Especially because if systemd ever goes to shit we might be locked to it and would have to fight a lot to get out of it

[-]

Dangerous-Report8517@reddit

Thing is that one of the core goals of Flatpak is sandboxing, and most of the systems that don't run systemd also don't provide robust sandboxing, which is in fact part of the issue here (since Lennart Poettering has mentioned that security is a key focus of his so systemd incorporates a lot of security tooling, not to mention that most non-systemd systems don't have a preconfigured MAC either). I do see 4 solutions here though, in decreasing order of likelihood: 1) Port appd to other environments, same as elogind. Depending on appd's architecture this likely requires the least overall effort, and wouldn't require any additional work for Flatpak or downstream developers 2) Develop a system that can ingest a flatpak manifest and build an AppImage of the package. Might be complex to translate dependencies from the full fat runtime images that Flatpak uses into a standard AppImage though 3) Flatpak could support a light/non sandboxed mode, this would require additional effort by the Flatpak project to maintain both modes 4) Use natively built AppImages for those distros, which would work but means more effort for devs to get broad support and would result in some apps not being packaged both ways to everyone's detriment

[-]

NDCyber@reddit (OP)

Yeah I get that it is easier, but for something so big and important to those distros it might be more important to make sure it works with as many things as possible. Especially because they market themselves with "Create one app and distribute it to the entire Linux desktop market."
reminds me of a xkcd comic https://xkcd.com/927/ I know you didn't mean it exactly like that, but that is probably how it would end up being
It would be new to hear that sandboxing on flatpaks doesn't work on distros that use non systemd inits. But yeah some extra work would 100% go into it, which is of course problematic but at the same time kinda in the spirit of flatpak if you ask me
Problem with AppImages is that they are more annoying to update and manage, than something like flatpaks. And there are enough programs that don't have AppImages as option that I wouldn't see it as a great option

[-]

Dangerous-Report8517@reddit

Yeah I get that it is easier, but for something so big and important to those distros it might be more important to make sure it works with as many things as possible. Especially because they market themselves with "Create one app and distribute it to the entire Linux desktop market."

The vast, vast majority of desktop Linux systems are running systemd already, to the point that I'd be willing to bet more systems would fail to run Flatpak 2 because of running out of date systemd than the number that would fail due to not having systemd at all. As a compromise though there's no requirement that the people who port appd aren't also part of the Flatpak project

reminds me of a xkcd comic https://xkcd.com/927/ I know you didn't mean it exactly like that, but that is probably how it would end up being

That's why I didn't suggest a new standard, I'm describing a converter between 2 already existing and widely used standards.

[-]

NDCyber@reddit (OP)

Something about the "not enough user" feels extremely ironic to me, while talking in a Linux sub, because it is the same reasoning you sometimes get while talking about windows and linux and software support. I know you don't mean it in bad faith or so. Just seeing people give the same argument

That's why I didn't suggest a new standard, I'm describing a converter between 2 already existing and widely used standards.

Yeah, I know what you mean, but I question if at that point it wouldn't just be easier to adapt flatpak support for the distros that don't have it

[-]

Dangerous-Report8517@reddit

The entire problem though is that Flatpak currently supporting those niche distros is now creating a barrier to important features that are core to the project's mission, so adapting Flatpak 2 to support those distros either means not addressing that need, or porting appd over anyway

[-]

NDCyber@reddit (OP)

I would honestly be interested in, if appd is a hard requirement for those features, or if it "just" makes development easier and cheaper for them. Which are fair things to want, but at the same time doing those things are also breaking some core selling points flatpak has, aka your software works on every distro

But also again, complaining about supporting niche distros is still kinda ironic to me, while a lot of linux user ask for better software support, like from anti cheat for games

Plus if flatpak would do the work it would mean other devs don't have to do so. Not much of a compensation for flatpak, but it would be extremely helpful to all those programs and devs

[-]

Jumpy-Dinner-5001@reddit

How is something ironic to you?

Why are you doing double standards? Why is systemd as a central component in Linux systems a problem but the kernel isn’t? Why isn’t XServer a problem? Or Wayland? Why can’t they support the compositor that I vibe coded last night? It’s quite ironic that it’s always just systemd where this is seen as a problem.

You can’t really compare it either. Linux is like 4-5% marketshare, that’s correct but within those 4-5% like 99% are using systemd (likely even more). That 1% is then 0.04-0.05% of all users, that’s a huge difference.

Because you mentioned the xkcd comic: Systemd was the first time that things improved there. Systemd is what really brought one standard coming from a dozen of different standards. It’s not fair to give it all to systemd because there was momentum before that but it came at three right time to boost Linux even more. Systemd is what really helped Linux win over other Unix like systems and effectively brought the death of most other Unix (like) systems.

[-]

ztanelesszane@reddit

I think what u/NDCyber is saying is that if it was right to not support something just because it's niche or only a minority of people uses it then absolutely nothing should ever bother supporting Linux. And this is worse than not supporting it, because it *had* support, and then it gets suddenly removed. So all of the people who depend on it and got used to it now have to scramble on what to do. It's comparable to when Rocket League just suddenly removed the Linux version, and I don't remember anyone siding with them because "Linux is only 5% of the gaming marketshare, why are you demanding that they work for you?"

I think your comparison doesn't work, Wayland isn't a problem because it provided a solution to X11 apps that wouldn't or couldn't move: xwayland. Now the majority of Linux can move to wayland but it doesn't lose the apps that rely on X because they're too old or they're unmaintained or they don't like wayland or whatever.

That's all non-systemd distros want. You're acting like they're demanding something massive and incomprehensible, all they want is *A* way. It's really not that hard to just let people still use flatpak 1, or only require the systemd dependency for flatpaks that will have daemons, or isolate the systemd dependency to a separate component that people can write a replacement for, etc etc. I mean we saw an example with this just a few months ago: KDE is moving to PLM yes, but SDDM still works for non-systemd distros. As it stands, "Okay so all of you are not gonna be able to use this anymore, you're on your own, screw you, also you're rude for even asking me to not do this" is not gentlemanly behaviour.

[-]

NDCyber@reddit (OP)

Biggest point people use against supporting Linux is the exact same reason you gave to why flatpak should only support systemd distros

"Why is systemd as a central component in Linux systems a problem but the kernel isn’t?"

I am not saying that systemd being a central part is a problem, but how things rely on it. You can also make the point you made yeah, although there is difference. For linux there exists OpenBSD, but the things are just a bit too different sometimes. XServer and Wayland are also having competition, like with each other, but the most important part you are ignoring the competition to systemd didn't get vibe coded last night

And the irony with numbers is, that People complain that companies don't look out for 5% of the user, but when people on the Linux side could do the same, they do the exact same, while complaining about the other things

I think there is also a misunderstanding here. I am not against systemd, I use it myself and find it useful. But I find programs relying on it that are meant to support nearly all distros problematic, especially if the programs supported those things before. And even more, if they market themselves to work on every distro

[-]

Jumpy-Dinner-5001@reddit

How exactly do you imagine it then? Should flatplak not add features that only work on systemd? Should their developers put in the work to port the functionality over to non systemd systems? If so, what is the threshold of user base?

[-]

NDCyber@reddit (OP)

flatpak should work as good as possible on every system, maybe implement their own things or so, I think like they did either way. But I get that that would maybe be too much for it to be possible. And there are a lot of ways to go with this, either making certain features depending on the init system and what it supports, or working with the devs of those init systems together to find ways. But that is also something I don't think I could influence at the moment

"If so, what is the threshold of user base?"

That is a good question honestly and where I think it would be difficult to find a concrete answer rather than judging individually. But I would say that something that is used by multiple distros that aren't small distros either (Gentoo, void, MXLinux, Alpine Linux and so on) is big enough to consider to work on something meant to be a standard

[-]

Isofruit@reddit

As per their talk, they plan on having a "confined mode" and "unconfined mode", so you can have a flatpak without sandboxing or with sandboxing.

I recommend watching the talk on youtube, it's just 30 minutes and gives a decent idea.

[-]

Jumpy-Dinner-5001@reddit

It’s a valid response. Don’t you realize how entitled that is? Systemd solves a lot of problems for developers and reduces complexity at a lot of points.

You’re not giving valid criticism, you’re acting destructive towards FOSS development and don’t even realize it. What you effectively say is that you don’t care how things work and the benefits that systemd provides but developers of flatpak should still put in the work to fix it for non systemd environments.

There are two valid ways to deal with this: Just don’t use it or contribute yourself.

But doing nothing but complaining about contributors not doing more work for free is not helpful at all.

[-]

NDCyber@reddit (OP)

It is not a valid response to criticism that people should just do it themselves better. it is ignoring the problematic points. It would create even more package systems, that people would have hope to accept. It is just like this comment https://xkcd.com/927/

But it seems like people want that rather than for one standard to evolve and get good over time

"What you effectively say is that you don’t care how things work and the benefits that systemd provides but developers of flatpak should still put in the work to fix it for non systemd environments."

That is for sure not what I am saying. I am saying, that systemd is a good recourse and I get why someone would want to use it. But for something like flatpak it shouldn't be used, as flatpak works on a lot of distros and is a key marketing point on their website. Relying on systemd is breaking that

Stopping criticism from being heard or allowed is even more destructive to any software

There is a point to make that one should support, but does that mean only people with the skill and recourses should be allowed to criticise? What is with normal user? Do they no longer matter?

[-]

Jumpy-Dinner-5001@reddit

You fail to realize that not going with systemd is what brings all those competing standards. That’s quite literally the point of systemd. Systemd came with the idea of having one consistent standard with consistent configuration interfaces and unlike in your xkcd it actually worked, the vast majority, likely more than 99% of all Linux systems use it and it has brought a lot of standardization.

It’s not what you literally said but that’s the logical consequence just think it through.

[-]

NDCyber@reddit (OP)

Damglador@reddit

Perhaps because it's advertised to be portable and universal, while it does the exact opposite of being portable and universal?

With systemd dependency you cut down on non-systemd distros, containers, chroot environments, things like Termux. If they want to say "get fucked" to people who would use flatpak in those environments, sure, go ahead, but they should remove the bullshit about:

Build for every distro Create one app and distribute it to the entire Linux desktop market.

I didn't say it's the same, I said pretty much all the arguments that other posters make about systemd also apply to Linux, particularly in the case of the other poster who just vaguely gestured at the fact that systemd is widely used, which is exactly true of Linux as well, by definition since Linux is in turn a dependency for systemd.

Even your own "you can't use linux without the linux kernel because that's literally what linux is" is a bit missing the point, you can't use KDE apps without the KDE runtime either but no-one complains that Dolphin or Kate is going to end Linux freedom. As does "your linux software that previously didn't need systemd now does,", which, again, also applies to the Linux kernel since software gets updated to use new kernel features and ceases to support older kernels.

It's reasonable to have a discussion about the downsides of this type of integration, it's not reasonable to just complain that it shouldn't happen without considering the clear upsides that motivated the discussion in the first place or the various ways that the downsides can be readily managed. We've been here before, by the way, and most non-systemd users haven't even realised because it was solved - systemd-logind is actually a dependency of a ton of desktop environments, but it's a non-issue because logind just got spun out as elogind and bingo they all work without systemd again because logind is just a separate software component that happened to be developed under the systemd project. There's no reason to think that appd would be any different.

[-]

somethingrelevant@reddit

you can't use KDE apps without the KDE runtime either but no-one complains that Dolphin or Kate is going to end Linux freedom

Because it's very difficult to get people to commit to making something "better" or a viable alternative when a bulk of criticism boils down to "I just don't like it."

You need to have an actual vision and inspire people to walk to dedicate countless hours to something that breaks a paradigm, not just personal grievance.

[-]

Greenlit_Hightower@reddit

I use OpenRC (it's the default in Gentoo btw.) and never saw a reason to use systemd. Also, shouldn't this ecosystem encourage diversity and flexibility over monoculture?

[-]

Dangerous-Report8517@reddit

Nothing wrong with that but if a project needs tooling that systemd provides and OpenRC doesn't then the rational choice for them is to use systemd instead of putting in a ton of extra work to remain init agnostic. It's not like OpenRC can't build the same APIs, multiple platforms already package elogind as a separate system when it was originally built in and for systemd

[-]

tyadel@reddit

If a web needs a feature that only Chrome provides and Firefox doesn't then the rational choice for them is to use Chrome instead of putting a lot of extra work into remaining browser agnostic. It's not like Firefox cannot build the same APIs, multiple webs already package polyfills to provide functionality that was originally built in Chrome.

Google should just ignore the w3c and skip the standardization process, implement whatever they feel like and if the webs want to use it is other browser problems to implement it. I'm sure thst everyone will love going back to the IE days.

[-]

Dangerous-Report8517@reddit

Except of course that Chrome is a proprietary browser while systemd is an open source project with well documented interfaces - using your example it's actually quite common for web services to implement web standards that Firefox hasn't caught up to and usually people point at Mozilla for the blame since Firefox failing to keep up shouldn't bar everyone from accessing new functionality (after all it's not like Chrome and Firefox are the only browsers or even browser engines, WebKit exists and is very widely used for instance and also supports all those web standards including ones that Firefox doesn't)

[-]

tyadel@reddit

Except the part that implements the web engine is open source, that's exactly why you have tens of chromium flavors using it as its base, I just used Chrome because that's the flagship browser that uses it withiut going too deep with blink or v8, which are perfectly open source and available in chromium, the same way as gecko from Mozilla.

Webkit in general is behid Firefox in compatibility, but even if it was ahead it would still lag compared to Blink, it mostly keeps its relevance because Apple uses it in Safari, specially with the browser ecosystem on iOS. But the number of alternatives is irrelevant, you also have openrc or sysvinit for systemd.

"Rule of Modularity: Write simple parts connected by clean interfaces."

There is no reason a userland program should be tied to a specific init system, as a hard dependency.

If there is a reason, it should then be abstracted out, and the init systems can then implement needed interface, thus the userland program depends on the interface NOT the SPECIFIC init system.

[-]

deviled-tux@reddit

You should probably uninstall the Linux kernel. It doesn’t follow unix philosophy.

[-]

Dangerous-Report8517@reddit

They aren't talking about tying anything to systemd-init, they're tying into systemd-appd. I keep seeing critics of systemd blindly parrot the Unix philosophy as some kind of gotcha but if you actually interacted with systemd you'd quickly realise that it is in fact a collection of "simple parts connected by clean interfaces". And there's nothing stopping people from porting appd to other environments, it's even been done before with elogind

[-]

derangedtranssexual@reddit

I don’t care about the Unix philosophy, sometimes it’s good to make stuff small and modular sometimes it isn’t. Systemd is modular tho. Also you can just make a systemd shim for a lot of things, that’s basically what you’re describing with abstracting it out. The issue is a lot of non systemd distros don’t have good alternatives to what systemd does

[-]

powerslave_fifth@reddit

The WHOLE POINT of Linux distribution(s) was/is people gathering around the shared opinion(s) that formed that distribution in the first place

You can't talk about freedom of opinions if you are going to reject the opinion of adding a systemd hard dependency. There's nothing much you can do if the majority of the volunteer devs decide to do so. They have no obligation to cater to OpenRC or Runit.

This particular dependency is about having a system-wide convenient way to have permission management. Rather than flatpak maintaining its own way of identifying apps that only works for flatpaks, systemd-appd allows you to identify any app launched on the system and have e.g. permissions stored related to that app, which services now can query, rather than flatpak having to do that checking itself.

Guess AppImage is superior after all.

[-]

PredictiveFrame@reddit

Even without this being an official stance, the automatic assumption bothers me. I currently use systemd, but I am eternally cautious of the day they inevitably begin the long process of enshittification, if they avoid it, I'll keep using it, so far every single time I've seen this pattern in person or history, it ends in enshittification, regardless of how noble the intentions.

I mean, I'm on the systemd side on that particular topic as well, but imo fairness warrants representing their argument a bit clearer.

The fairest version of that argument I saw was that systemd shouldn't have reacted to the law in the first place made it possible, and rather should've resisted US lawmakers on that front, and that this is just the first step towards mandatory age verification, which systemd just enabled as a first step to be easily implemented by all distros/DEs/browsers.

Now, that argument still falls short imo because that still could've meant distros implement their own mechanisms, somebody gets put in prison or fired depending on the situation and therefore there's little support or reason to take that stand at potentially high personal cost, but it's imo a fairer version of that argument.

[-]

deviled-tux@reddit

who would be getting jailed? literally none of the laws related to this carry criminal penalties, it would only be fines for the OS provider.

At this point it seems everyone has made up their own version and ran with it. There’s no hope of having a level discussion about this anymore lol.

So by your own logic then, surely due to systemd being open-source, it will be forked, and persist in a new, different way. It isn't the first init system and it won't be the final.

To me, enshitiffication is a distinctly different thing than "all things decay". There's a reason it is its own term. It was coined specifically to lend a name to the phenomenon of "shiny new corporate project slowly becomes decroded due to profit incentive taking priority". It is particular to the tech business and product sector; I don't think it's a fair application of the term for what you're describing.

[-]

CmdrCollins@reddit

Even without this being an official stance, the automatic assumption bothers me.

I mean...but it's not just a package manager tho? If it was, that would be a bizarre requirement I agree. Using cgroupsv2 and systemd integration to manage resources, isolation, scheduling, etc of flatpaks at runtime makes a lot of sense. It's essentially doing desktop container orchestration...at runtime it's more similar to docker in many ways than say apt.

Duplicating the effort of something that solves messy lifecycle problems out of the box (like cleanly killing zombie sub-processes when an app closes) just for the sake of unix philosophy purity seems like a strange engineering choice. Especially since cgroups v2 explicitly enforces a strict 'single-writer' rule anyway; systemd is already driving the resource tree on 95%+ of machines, so Flatpak is just using the standard platform API available to it.

Now at the same time I do think it would be an odd choice to leave systemdless distros without an option, but I also think some version of flatpack will obviously come along that supports this, but why make it the main effort?

To be blunt I just don't care about these distributions and the edgy people who want to be difficult by running them. There are legitimate reasins to not use systemd outside of desktop enviroments, but those distros also just don't care about flatpack. it's not the use case for them. Anyone who willfully uses a systemdless distro for desktop is just obnoxious to me ngl. For everyone else this is a solution to problems not the creation of one.

literally I hair don't understand the Linux community for caring about stuff like this. One of the hugest problems in desktop enviroment in Linux is that there's very little standardization and flatpack even exists bc of that problem. Making it more standardized is actively fought lol.

[-]

Damglador@reddit

Build for every distro Create one app and distribute it to the entire Linux desktop market.

-https://flatpak.org/

Should update my dictionary to "every and entire - if talking about Linux distros, only ones that run systemd"

[-]

ibeerianhamhock@reddit

It's funny you just want to be right on principal so badly that you can't have an actual genuine conversation on the merits of such a choice architecturally.

I give exactly 0 fucks about FOSS accommodating edgelords who saw a meme about systemd being bad in 2015 and adopted it as a personality trait.

Linux desktop needs more "use this, it's the best path forward, or you're on your own" type choices to make desktop a better experience for 99% of users. For the folks who want to be difficult, they can enjoy figuring out stuff on their own that's the beauty of Linux.

[-]

Damglador@reddit

So here's a revelation: I use systemd personally. I do not care to not use it. But when you advertise to be universal and then make a dependency that just can't be universal – that's shitty.

It's also shitty to call everyone who has a personal opinion about their init system edgelords or "morons", like some other guy did. As one might also say that every Linux user is an edgelord because they make their operating system a personal trait instead of using Windows like a normal person.

make desktop a better experience for 99% of users

Flatpak is hardly that and instead of focusing on what would make it better, like not letting apps download 2 nearly identical runtimes, or setting permissions to the system icon themes and theme configs by default, it shoots itself in the foot with its "universal" part.

[-]

ibeerianhamhock@reddit

Yeah I don't think they are stupid and there are valid reasons to feel like systemd breaks a lot of unix philosophy itself, it's made by rh (like a lot of Linux is, I mean in general around 85% of kernel contributions are corporate in origin). But also it just works.

At the end of the day tho flatpack is on GitHub. Any distribution is free to adapt it to what they need and set up their own repos right? That's is also the beauty of Linux.

I do stand on the aversion to systemd is not about it being a bad tool and more about feeling icky ahout it.

As a long time tech enthusiasts and developer I just don't feel like I have time for worrying about those kinds of things. I just want a reliable stable system that doesn't feel gross like windows or macos generally. The boundaries people have with their OS tho is personal and I won't pretend that my opinion is a fact even if I hold it strongly.

I call them edgelords bc I find the rhetoric slightly obnoxious but for the record I genuinely don't think anyone using say systemdless configured gentoo is dumb lol. I don't have the patience to use something like gentoo, but I absolutely don't think those are dumb people, if for nothing else bc I don't think a dumb person would be able to set up gentoo in the first place. I do hold the opinion that not using systemd is a choice without much of any benefit.

[-]

Damglador@reddit

Then again the issue is not systemd, the issue is that flatpak imposes a hard dependency on you init system.

And no "just fork it" is not an answer as whoever does that loses any upstream support and has to somehow keep up with all the changes flatpak does while keeping compatibility for the apps and packages. At that point flatpak better change their slogan to "Opinionated containerized app distribution solution".

I personally feel somewhat betrayed as the only thing flatpak was good at, reliably running any package made for it on any distro, no matter the init or libc, will be gone, and we're left with a bloated app packaging method that creates random issues due to its sandboxing (like randomly changing cursor theme if you hover over a flatpak app or flatpak apps not following your desktop theme, or flatpak apps having broken features. All of which I have experienced).

[-]

ibeerianhamhock@reddit

Kind of tangent but isn't that a result of 1. flatpack not being able to see your system themes unless you grant permissions and 2. A flatpack can literally be packaged with gnome if you're on kde or vice versa and it's essentially hit or miss how it's going to render?

And yeah flatpack is not perfect. It kinda solves the distribution problem and I genuinely think in many ways it's superior to windows' solution to software distribution but nothing is ever 100% easy on Linux lol.

Running GUI apps and even the desktop itself has come miles in the 20+ years I've been using Linux though. It's only in the last several years that I've completely abandoned using windows all together even as a backup bc it's got so good for every use case I have (browsing, office work, dev work, gaming).

The only thing I miss is Xbox live games on my PC but that's MS' fault.

[-]

Damglador@reddit

flatpack not being able to see your system themes unless you grant permissions

That's the issue. It should have permissions to the gtk and qt configs by default as well as icon themes, yet it doesn't.

it's superior to windows' solution to software distribution

Everything is superior to that, it's a super low bar. Though I am not sure if flatpak even is, as it's much less space efficient. Like stupidly inefficient.

[-]

mattias_jcb@reddit

A "package manager" is in essence not much more than curl, tar and some fine fine glue. Flatpak is an app distribution and runtime. Decidedly not a "package manager" unless you're really into diluting words. :)

[-]

ScratchHistorical507@reddit

Depending on systemd doesn't really change anything about the universality of it though. Just because every single user that insists on not using systemd feels the need to tell literally everyone doesn't mean they have any kind of relevant marketshare.

[-]

Damglador@reddit

Build for every distro Create one app and distribute it to the entire Linux desktop market.

A quote from flatpak.org. I don't see any "relevancy" mentioned. Entire means entire.

[-]

whosdr@reddit

I'd like to add two more sources to your list, since they seem very relevant.

https://www.phoronix.com/news/systemd-appd-Flatpak-Dev

https://blog.sebastianwick.net/posts/flatpak-happenings/

I especially want to focus on this paragraph:

Adrian and I have made plans for a service which allows querying running app instances (systemd-appd). This provides a new way of authenticating Flatpak instances and is a prerequisite for nested sandboxing, PipeWire support, and getting rid of the D-Bus proxy.

It describes itself as a separate service (as much of systemd is). So I expect it'd be possible to write an alternative for other init systems. Or possibly have it made compatible with other init systems—whichever route people plan to go down.

[-]

piesou@reddit

The issue has never been, that people couldn't write compatible utilities.

It's about violating the philosophy. Stallman didn't die for nothing. He died so everyone of use could use GNU not Unix. What we demand is for Lennart to stop prosecuting our members and apps.

[-]

abotelho-cbn@reddit

Stallman didn't die for nothing

What?

It's about violating the philosophy.

systemd follows the "UNIX philosophy" quote well, actually. All the components people complain about are modular independent services. They each have a task.

[-]

whosdr@reddit

You've made an assumption that I both understand and agree with the philosophy. I'm not part of the old guard and so honestly I don't have the requisite knowledge to respond.

If you have the time to explain things in a little more detail, I would welcome that.

Absolutely. I hope the system remains entirely flexible.

Which I honestly say with no motives outside of the freedom and fairness: Everything I personally run is systemd-based.

[-]

I think it was probably too early to make the thread. I'm struggling to find any real sources on a 2.0 version of Flatpak, so we've got only the word of a single team member who themselves don't want to be taken seriously about it.

I would love to hear from some of the technical members of the team. And maybe I'm wrong: maybe a post like this will stir up enough drama that they'll come forth and make a statement.

But I still don't like the unnecessary and premature stirring of the pot.

[-]

Isofruit@reddit

The only source I'm available of is the talk at LAS in Berlin last week: https://youtu.be/1AXBfsiaQNk?t=16219

Jorge literally held his own talk not 2h later.

[-]

whosdr@reddit

Thanks. It's more than I had before on the matter. :)

[-]

Isofruit@reddit

As they indicate at the end of the talk, that's up in the air. We're in the RFC stages of the topic, nothing is implemented yet.

I can see it being an optional dependency that only gets loaded when an app indicates it requires subsandboxing (like browser flatpaks or the steam flatpak likely would). I can also see that process being too tough and it thus just being a mandatory one.

Either way, I'd imagine you can just re-implement the APIs into a service that isn't managed by systemd. Distros already should have their own reimplementation of dbus, they can reimplement appd to provide a similar API and do similar communications.

[-]

whosdr@reddit

Either way, I'd imagine you can just re-implement the APIs into a service that isn't managed by systemd.

That's my thinking as well. It might be 'designed for systemd', but I can see other implementations existing.

[-]

blackcain@reddit

Drama around the fact that others want their distros supported with the assumption that engineering resources are unlimited and should include them and whatever system they have come up with.

blackcain@reddit

Follow @las@floss.social .. I post content there all the time

[-]

whosdr@reddit

Thanks, I shall. (I did explicitly ask for links for a reason, because I wasn't aware of the summit in question.)

It's not anymore, he was never involved. He believes in flatpak and has centered it for bluefin.

[-]

NDCyber@reddit (OP)

The thing is, now I have two information, once you saying he didn't have anything to do with it, and the interview that I linked before, where they say he is a community manager for flatpak from 2022 "In our Innards section, we have an interview with Jorge Castro, community manager for Flatpak and former community manager for Canonical." https://mintcast.org/386-interview-with-flathub-contributor-jorge-castro/

[-]

Isofruit@reddit

There's no reason to trust, you can verify. Watch the talk: https://youtu.be/1AXBfsiaQNk?t=16218

Doesn't flatpak do too much shifting? It shifts responsibility of dependency managment from developers themselves and runtimes maintainers by just providing gigabyte runtimes with no care whether an app needs it or not. It shifts the responsibility of providing proper backwards and forwards comparability from everyone by just locking apps to an exact down to minor patch version of the runtime. It shifts responsibility of providing a configurable app data directory by just hardcodding ~/.var. It shifts the responsibility of making proper permission prompts by just forcing everyone to bake all the required permissions in the package. Now it shifts the responsibility of being universal, the thing it was supposed to do from the start, to the distro maintainers that are now supposed to make it universal...

[-]

SoilMassive6850@reddit

Doesn't flatpak do too much shifting?

No

It shifts responsibility of dependency managment from developers themselves and runtimes maintainers by just providing gigabyte runtimes with no care whether an app needs it or not.

No because a developer does not need to do downstream packaging. That's the package maintainers problem

It shifts the responsibility of providing proper backwards and forwards comparability from everyone by just locking apps to an exact down to minor patch version of the runtime.

Once again people aren't forced to ship their software with flatpak, they clearly like the solution flatpak provides (as opposed to AppImages for example) so I'm not sure what the problem is.

It shifts responsibility of providing a configurable app data directory by just hardcodding ~/.var.

Thats not shifting anything, that's just a decision

It shifts the responsibility of making proper permission prompts by just forcing everyone to bake all the required permissions in the package.

That's because you need sandbox aware software to handle permission prompting safely, it's not a thing flatpak can solve. Developer problem

Now it shifts the responsibility of being universal, the thing it was supposed to do from the start, to the distro maintainers that are now supposed to make it universal...

Nothing universal about it, plenty of system dependencies exist. Maybe if flatpak was a fully statically linked musl binary trying to actually be universal your argument might hold, but they clearly have no issues with system dependencies, not to mention that any additional systemd dependency would likely be feature flagged anyway.

[-]

Damglador@reddit

Once again people aren't forced to ship their software with flatpak, they clearly like the solution flatpak provides (as opposed to AppImages for example) so I'm not sure what the problem is.

The problem is that flatpak downloads and installs a whole runtime even if an app doesn't need most of it. And then it downloads the same runtime but version X.X.X+1 because the other app declared that in the manifest instead of X.X.X. Now we have a duplicate runtime for no reason which won't be deduplicated completely because technically it's different from the other, but for the purpose of an app, they're identical as they're only a minor patch different.

Nothing universal about it

flatpak.org says

Build for every distro

Create one app and distribute it to the entire Linux desktop market.

[-]

They're adding a dependency to systemd-appd for permission management. If I understood their talk correctly, this allows them to move the entire permission management out of flatpak into the service-layer. Essentially, appd allows apps to have an identifier, thus allowing you to store permissions related to that identifier through systemd, that's what I got from that talk. Inferring from that, I assume that systemd allows services to query that information from wherever the permissions are stored.

It is my understanding that flatpak already is capable of that, but used its own - potentially more error prone - way of doing so, while systemd-appd now allows you to move that entire layer out of flatpak.

[-]

Dangerous-Report8517@reddit

This suggests that systemd would at worst be a soft dependency, and if it's only appd that it needs then presumably someone will build a compatibility layer for other init systems the same way that elogind has been ported to other inits

[-]

novafunc@reddit

Having two systems would be a poor choice for maintainability and consistency between systems.

The point of using systemd-app is to simplify flatpak and permission handling. Having both would just make the system more complicated. At the at point, if compatibility was the primary goal, it wouldn't make sense to use systemd-app at all, just have everyone on the "fallback" method.

[-]

I don’t think he’s qualified to answer that question, but ok.

[-]

unlikely-contender@reddit

what is the significance of the "but ok" in your answer? are you saying you're ok with the systemd dependency?

[-]

jloc0@reddit

I realize this comment may come off as rude or something but I’ve watched streams of his and he’s plainly stated he’s not a developer at that level. There’s teams of people behind him that turn his ideas into working product. While his projects may have some connection or relation to flathub or flatpak itself, as they utilize those technologies, him coming out to say that, I’d take with a grain of salt. It could be optional, it could open up more doors for flatpak, etc. he’s not a flatpak developer, I’m just saying, he’s not the person I’d expect to be hearing news of this nature from.

Bluefin is great and the things they are doing have merit and function and wildly differ from the norm, but flatpak is an ecosystem he utilizes to provide his product. I’m sure there’s been relation between the camps, but he shouldn’t be out there giving news on a project he’s a consumer of.

Anyway, it could be true, it could be optional, it could be many things. We’ll find out eventually, no doubt.

[-]

Isofruit@reddit

I mean, he was at the summit and gave his own talk roughly 2h after 2 devs of flatpak next announced that they'd be depending on systemd in order to allow subsandboxing (which I assume is there to help apps like browsers, steam and other apps that launch processes/applications) and better permission management.

woops didn't realise I didn't copy the mastodon link directly. But yeah that is just mastodon. Here is the same link to mastodon if you care https://mastodon.social/@2something@transfem.social/116618627273919847

Jorge Castro seems to be the maintainer of Bluefin and did have some interviews in connection with flatpak https://mintcast.org/386-interview-with-flathub-contributor-jorge-castro/

wtf is that website 🤣🤣😭 are we deadass

[-]

NDCyber@reddit (OP)

Mastodon. Open source twitter like app, that things like KDE, GNOME, flatpak and so have official accounts on

[-]

amogusdevilman@reddit

Ohh I was wondering about that weird ass domain, isn't bluesky mastodon too? 🤮

[-]

7lhz9x6k8emmd7c8@reddit

Mastodon is a software and a federation of instances.

Anyone can run their own instance and connect it to the wider Mastodon fediverse.

That weird website/domain is an instance.

[-]

NDCyber@reddit (OP)

Not from what I know. I think bluesky is closed source

Appimage ftw

[-]

Literallyapig@reddit

this seems like a sketchy source, but if that's true then it's very dumb, specially for a package format that prides itself in being portable / distro-agnostic. i use systemd, in fact i like systemd and think it's really useful and solves lots of problems, but i'm also a huge fan of alternatives and think we shouldn't limit ourselves to one init system.

[-]

Isofruit@reddit

It is true, you can watch their LAS talk on youtube. They want the module systemd-appd for nicer permission management and subsandboxing which they currently can't do, which if I understand it correctly (so take it with a grain of salt) means it's useful for removing some of the issues with browsers and steam which launch sandboxed processes.

Strictly speaking, as long as you replicate what systemd-appd does, you should be fine. The entire system is modular, so it should be fine focusing on systemd-appd. All the other systems involved any non systemd-distro likely should already have a replacement for (dbus and friends).

DoubleOwl7777@reddit

source is sketchy af. it kinda rubs me in the wrong way that a format thats supposed to be universal depends on systemd. but meh. systemd is still open source so if shit hits the fan i assume someone will fork it.

[-]

NDCyber@reddit (OP)

It is just mastodon, and Jorge Castro seems to be the real person. But I also updated the post to link to have a normal mastodon link in it, so it isn't so confusing. Honestly forgot that the share button uses the server the person that wrote the message is on uses

And yeah it also rubs me the wrong way. If you said pacman is systemd dependent that would be way less of a problem to me and I would just be like "ok". But flatpaks seem like a rather crucial thing to be locked out

[-]

Misicks0349@reddit

As long as flatpak-next has a better permission system and a stronger sandbox I don't much care.

[-]

Isofruit@reddit

I mean, I'd imagine he was making his statements based on what was announced at LAS last week where he also held a talk around 2h after the flatpak devs held theirs about depending on systemd-appd

[-]

Misicks0349@reddit

sure but if that was the case then he should've said that rather than saying vagaries like "I'm just telling you like it is", "You keep acting like I am in some position of authority.", "I am pointing out the obvious".

[-]

Couple of things.

Flatpak already works without systemd. Adding a depending to something that already works without it is bad design.
Reliance on systemd by Snap is one of the reasons some people use Flaptak instead. Removing that benefit means losing some users to alternatives.
Around 20% of all Linux distributions don't use systemd. Linking Flatpak to it would remove the "universal" aspect of Flatpak. Something else will come along to fill the role or non-systemd distributions will end up forking it, which means duplicating work, not saving work.

[-]

Isofruit@reddit

Flatpak currently without systemd-appd does not allow subsandboxing, which if I understand it right means being able to spawn a sandboxed process inside a sandbox. Seems to be fairly relevant for flatpak'ing browser, steam might use its own sandboxing as well and other "launcher-like" applications likely would want it as well.

It also seems to simplify permission storage in general via systemd-appd, as you can now store the permissions in the systemd-layer rather than via your own code, and have the services that an app asks to do something query the permissions from there rather than have the flatpak provide it. That's also if I understood the talk right, it's not like I have an in-depth understanding of things.

[-]

tajetaje@reddit

That is in no way one of the main reasons people avoid snap lol

[-]

Yes indeed! Made me laugh! Musl is actually quite good, not the quickest but very good.

[-]

Venylynn@reddit

They're gonna cry that we're some evil age verification supporting demons even tho we hate the laws too, just because they don't understand Dylan M. Taylor also doesn't support the laws.

Also I see plenty of people whining that they need glibc because they want to protest Stallman.

[-]

NDCyber@reddit (OP)

I would agree for some things, but for a thing meant to work on most Linux distros too help Devs to only have to put it there, is a different thing for me

[-]

BashfulMelon@reddit

The anti-social conspiracy nuts have always been a weight around the neck of free software. They think anybody working together on something they don't personally appreciate is a malicious conspiracy.

No one is going to stop people from using their OpenRC/XLibre/Linux anti-woke pro-woke anarcho-capitalist protest distro, but no one is going to go very far out of their way to develop for a different platform when the only problems with the first platform exist solely in troubled minds.

[-]