this post was submitted on 01 May 2025
49 points (93.0% liked)

Linux

53840 readers
1341 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 6 years ago
MODERATORS
nooter692@lemmy.ml
AgreeableLandscape@lemmy.ml
MarcellusDrum@lemmy.ml
cypherpunks@lemmy.ml
cyclohexane@lemmy.ml
d3Xt3r@lemmy.nz
49
The Future of Flatpak | Sebastian Wick @ LAS 2025 (www.youtube.com)
submitted 2 days ago by that_leaflet@lemmy.world to c/linux@lemmy.ml
18 comments fedilink hide all child comments
 

Warning: the audio is bad and will occasionally get very loud

top 18 comments
sorted by: hot top controversial new old
[–] TMP_NKcYUEoM7kXg4qYe@lemmy.world 2 points 21 hours ago* (last edited 21 hours ago)

Haven't seen the video, I'm only commenting based on the summary in the comments.

It's good that flatpak is switching to OCI containers. Hopefully that will end the flatpak's dependency hell. This week I was looking at flatpak as a way to publish my app and found the user experience (user is the app publisher in this context) quite bad. Could be skill issue obviously.

I thought I could just look into a database of flatpak runtimes, pick the one with the software I need, add additional packages and be done with it. Unfortunately it is not that simple. First of all as far as I know, there is no "database" like archlinux.org/packages. You have to download the runtime and then search /usr/include/ or /usr/bin/ to check if particular piece of software exists in it. Adding additional packages is also quite difficult. There are these runtime extensions which are like "baby runtimes" for special software like ffmpeg, java, etc. They kinda suffer from issues similar to the issues of the runtimes. And unlike in regular distros where you can get a package for almost anything, here you don't have the luxury and have to bundle that not so popular dependency.

I hope that with OCI I will be able to just provide the binary, a link to the base image and a list of dependencies to install and be done with it.

[–] AnUnusualRelic@lemmy.world 13 points 1 day ago (1 children)

Warning: the audio is bad and will occasionally get very loud

Interestingly, that's never a problem with text files.

[–] Cyber@feddit.uk 10 points 1 day ago

** SOMETIMES IT IS **

(Sorry, couldn't resist)

[–] nycki@lemmy.world 18 points 2 days ago (1 children)

is this available in text form?

[–] that_leaflet@lemmy.world 37 points 2 days ago* (last edited 2 days ago) (2 children)

Don't believe so, best that's currently available is skimming through the video to look at the slides.

Here's my short summary of the presentation, I tried to denote what's being worked on (open PR), what's kinda being done (WIP), and things stuff they'd like to be done in the future (wishlist). May be somewhat wrong.

  • Flatpak is stagnant
  • Red Hat is working on a better way to preinstall flatpak apps (open PR)
  • Flatpak should is slowly moving towards OCI and away from ostree (more tooling available, don't need to maintain their own tools)
  • Better permission handling that is more backwards compatible (open PR)
  • Should directly use Pipewire instead of Pulseaudio (WIP)
  • Allow user namespaces in flatpak sandbox (WIP)
  • Move dbus proxying into dbus brokers (wishlist)
  • Improve network sandboxing (wishlist)
  • Improve drivers handling, currently drivers need to be built for each runtime, could cause issues if using EOL app on new hardware (wishlist)
  • Work on portals directly improves flatpak
[–] poinck@lemm.ee 3 points 2 days ago (1 children)

Why is it stagnant?

[–] that_leaflet@lemmy.world 5 points 1 day ago

Major people of the project had moved on. It’s being maintained, getting security fixes, but pull requests are slow to be merged.

[–] drwankingstein@lemmy.dbzer0.com 3 points 2 days ago* (last edited 2 days ago) (1 children)

Should directly use Pipewire instead of Pulseaudio

I hope they plan on keeping pulse for the foreseeable future. Pipewire is great and all but pulse is very entrenched, I still maintain quite a bit of systems that are pulse only.

[–] that_leaflet@lemmy.world 2 points 1 day ago

That is planned. But pulse is not secure, so exposing it is not great.

[–] pmk@lemmy.sdf.org 3 points 1 day ago (2 children)

About a year ago I started experimenting with the whole container-based workflow thing. I don't know how much time I've spent on setting up various programming environments, and there's always hurdles like getting a flatpak editor have access to java and actually be able to run javafx programs. And with distroboxes, what if my code needs access to a database that is started in a docker container on the host system, do I install docker inside the distrobox? I've had so many configuration issues. Every time I try I come back to debian stable and it feels like home.

[–] gencha@lemm.ee -3 points 19 hours ago

Containers are over hyped. They are so stupid for home use. People put init systems in containers, then run the entire pile of shit in Docker as root, and talk to me about security and resource isolation. And then all these shit Alpine containers with that MUSL joke. You really can't take any of it seriously anymore. These people want Windows or a mobile phone.

Flatpack is using OCI so they can publish their shit on any registry. Just another way to pollute an existing ecosystem with garbage nobody really needs. Easing the installation of crap onto your system is not a goal worth pursuing

[–] that_leaflet@lemmy.world 5 points 1 day ago (1 children)

Flatpak's usefulness for programming depends on the IDE and language. IDEs like VSCode largely suck because they are not designed to work in flatpak. But some languages still do work well in them, such as Rust, since Flathub provides the Rust SDK and dependency management is done with cargo. But it sucks for C++, where you typically install dependencies using your system package manager.

IDEs like Gnome Builder are pretty good. It's designed to work within the flatpak sandbox. Even when running as a flatpak, you can choose to build things using containers or your host system. And of course also build using the Freedesktop runtimes.

I recently setup JavaFX with the flatpak version of VSCodium and have it working pretty well. You first need to install the Java SDK from Flathub, set an env variable to tell VSCode to load the SDK. The more annoying part was JavaFX since it's not part of the JDK anymore. I just downloaded the JavaFX tar, extracted to a directory called JavaFX, and set $JAVAFX_HOME to point to it. Since VSCode has host filesystem access, it can access it. Few more steps than traditional Linux, sure, but still easier than MacOS and Windows.

Not sure about your database situation though.

[–] pmk@lemmy.sdf.org 2 points 1 day ago (1 children)

For JavaFX I ended up putting both JDK and JavaFX in my home dir and pointed vscodium to the right paths, I could get programs to compile but for some reason it would not let me open windows from inside, complaining that DISPLAY was not set or available iirc, even though I did set the env variable inside. Either way, I'm not ready for this container work-flow. Though I suspect that I could get used to better practices. Do you install git and your editor of choice separately in all dev containers? Like, how much of the tooling should be inside or on host?

[–] that_leaflet@lemmy.world 3 points 1 day ago

Ah I had the same issue. JavaFX still uses X11. By default VSCode only lets X11 be used if Wayland is not available (this is the X11 fallback permission). Disabling X11 fallback will let VSCode use Wayland and let JavaFX use X11. I might make an issue for this on the flatpak’s GitHub asking for this change.

Honestly, the truth is that setting up containers for development will always be a hassle. My low tech way is just to make a distrobox container with its own home folder, install an IDE in it, and install packages. The more proper way to do it would create your own containerfile to build your container for developing.

VSCode also has its DevContainers extension but that doesn’t work in VSCodium and does some weird things.

[–] that_leaflet@lemmy.world 14 points 2 days ago* (last edited 2 days ago)

Unfortunately, it's not in a great situation. Flatpak is stagnant. There's a lot of cool things in the works, like a stronger sandbox, preinstalling flatpaks more effectively, etc, but merging things is hard.

[–] drwankingstein@lemmy.dbzer0.com 5 points 2 days ago

until they give us android like permissions handling and always off by default with a proper request when needed, meh.

[–] WalnutLum@lemmy.ml 2 points 1 day ago

pre installing flatpaks

Did the room just get a bit colder or is it just me

[–] koala@programming.dev 0 points 1 day ago

My crazy idea is: write software so that Flatpaks can run on Windows and macOS. Plus, make high-quality Flatpak-building templates available for as many programming languages, UI toolkits, etc. as possible.

Because everything that Flatpaks provide is OSS, making shims for Windows and macOS compatibility would be tedious, but doable.

Same with crosscompiling Flatpaks, compared to the difficulties of crosscompiling for Windows or macOS from any other OS, multiplatform Flatpaks should be doable to crosscompile.

So this would lead to a world where a very convenient way to package for Windows and macOS... is creating a Flatpak that works on Linux!