this post was submitted on 20 Aug 2023
250 points (88.6% liked)
linuxmemes
21281 readers
189 users here now
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack members of the community for any reason.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
- These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudo in Windows.
- No porn. Even if you watch it on a Linux machine.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.
Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't fork-bomb your computer.
founded 1 year ago
MODERATORS
The point is still that you distribute a OS with your application, that's just silly and lazy.
Aside from the kernel you still need most libs, including glibc so it's a OS without the kernel.
Next evolution will then be to use flatpak from within flatpak or what?
Using the word OS puts across my point, because when you start packaging your toolchain with glibc and whatever libs you need for your application, you end up with a good part of the Linux file system. Yes there's missing services and so on but they could run if needed.
It's not a virtualization joke, it's more of a "we put flatpak in your flatpak so you can flatpak while you flatpak" recursion joke.
Most system libraries are included in runtimes that are shared among applications.
Sounds more and more like flatpak is a distribution atop of a distribution.
Good you can share libs, although I can't see sense in sharing more than the absolute basic libs, and even then some applications will need different versions of the basic libs.
What is your opinion on Nix?
From what I gather nix is more of a next generation package manager than a application container/sandbox which means potential security problems with old libs could be less, or rather they are probably at the same level as rpm/deb.
I don't see any problems with rpm/deb/etc. ending up getting the boot by nix or another package manager just because they are better, that's just evolution.
As someone said about flatpak/snap that their 'hidden' strength is distribution of proprietary software, that's fine by me if that's the main usage of them.
The sandbox feature can be solved by SELinux/docker/and several other ways depending on usecase.
Sandboxing is not the main feature of Flatpak/Snap, being able to ship an app for various distributions without having to configure them separately is. Docker/Podman can do that, but then you would actually be shipping an entire distro.
Regarding docker/podman that's why I wrote depending on usecase, for servers it makes sense to distribute because of scalability, on a single user OS it does not.
From what you write I guess that nix does the distribution part of flatpak, so that seems fine, there's probably a catch/limitation somewhere, there usually is, but it could be an acceptable one.
This is Docker's whole shtick, and look how popular that is 🤷♂️
Docker is made for servers, it's totally a different usecase.
I am not anti VM and docker, I just don't think we need more levels of indirection in the OS, I also don't think a distro based heavily on flatpak will be any good, one thing is sure it will be using a lot of diskspace and memory, as there's no sharing of libs. And if flatpak starts sharing libs it just re-invented the GNU linker.
I mostly agree with those points.
Flatpak does support sharing 'libraries' (although not in the way you mean), however from my perspective the main problem is developers referencing
Kde-Framework-420.69.1, and others referencingKde-Framework-420.69.1-rc1or various other variations of very similar dependencies, which tends to eat up additional disk space. I'm personally not too bothered by it, but that's only because I have the storage space for that.With flatpak's shtick being isolation and a consistent runtime environment, I doubt there'll be true sharing of linked libraries and the associated memory space, so excess RAM usage and disk space as you've mentioned.
The distros based on Flatpak (can't remember the names right now sadly) are mostly immutable ones, where the base system remains untouched, and in that scenario I think it makes the most sense, particularly in education.
The instances I use flatpak are slightly similar to that, with the difference being the libraries available in the base system may be too old to run the application natively
I believe the immutable distros you're referring to are Fedora Silverblue and Fedora Kinoite.