this post was submitted on 07 Jul 2025
692 points (92.5% liked)

Linux

56133 readers
875 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
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 19 points 3 days ago* (last edited 3 days ago) (3 children)

I've been working on Linux for 15 years now and I perfectly remember the origin of many concepts. If you look at it through time, what would it be like:

  1. We can build applications with external dependencies or a single binary, what should we choose?
  2. The community is abandoning a single binary due to the increased weight of applications and memory consumption and libraries problems
  3. Dependency hell is coming ...
  4. Snap, flatpack, appimage and other strange solutions are inventing something, which are essentially a single binary, but with an overlay (if the developer has hands from the right place, which is often not the case)
  5. Someone on lemmy says that he literally doesn't care if the application is built in a single binary, consumes extra memory and have libraries problems. Just close all permissions for that application...

Well, all I can say about this is just assemble a single binary for all applications, stop doing nonsense with a flatpack/snap/etc.

UPD: or if you really want to break all the conventions, just use nixos. You don't need snap/flatpack/etc.

[–] [email protected] 5 points 3 days ago

Old guy here too, used un*x before linux existed in the 90s. I still use a Debian based distro (MX) without systemd and no snap/flatpak/whatever. Just build/compile or install .deb and dependencies. Lastly unfortunately I had to install a flatpak to test "deskflow", the first time I installed one, I feel dirty now :-(

[–] [email protected] 7 points 3 days ago (1 children)

Flatpak is not single binary, Flatpaks have shared runtime (For example Freedesktop, GNOME, KDE runtimes)

[–] [email protected] 8 points 3 days ago (1 children)

Provided that flatpack has a common parent container, which is not always the case. More precisely, it almost never does. Because someone updates flatpack to new versions of the parent containers, and someone else does not.

[–] [email protected] 4 points 3 days ago (1 children)

More precisely, it almost never does.

I don't know any flatpak in my system that don't use runtime (I have around 50 flatpak apps installed), or am I misunderstanding your point

[–] [email protected] 6 points 3 days ago* (last edited 3 days ago) (2 children)

runtime have versions too. If one runtime version use only one flatpack than exactly same as just static linking binary. Flatpack have just docker layeredfs and firejail in base.

id: org.gnome.Dictionary runtime: org.gnome.Platform runtime-version: '45' <- here sdk: org.gnome.Sdk command: gnome-dictionary

[–] [email protected] 2 points 2 days ago

for some reason, i have both gnome platform 46 and gnome platform 47 installed in my system. that's probably it

[–] [email protected] 2 points 3 days ago (1 children)

I see problem in that only in unmaintained apps (like org.gnome.Dictionary), I have only GNOME 47 & 48 for example and both of them still updating

[–] [email protected] 5 points 3 days ago

In the initial stage of shared library support, everything was exactly the same. Let's look at it in 5 years... When some soft will archived and die, some stop maintaining, some new crated and brakes old dependencies...

[–] [email protected] 5 points 3 days ago* (last edited 3 days ago) (1 children)

I don't mind other solutions, as long as they have the key features Flatpak offers, namely:

  • Being open-source
  • Having app permission system
  • Having bundled dependencies
  • Integrating decently with the system

Times are changing, and memory constraints for most programs are generally not relevant anymore.

[–] [email protected] 11 points 3 days ago (1 children)

Times are changing, and memory constraints for most programs are generally not relevant anymore.

But there are gaps in the libraries that, unlike distributions with dependencies, can no longer be managed. And all the security of your system depends on a small flatpack access control, which 99% of users do not understand at all and, with any problems simply opens access to the entire home directory.

[–] [email protected] 7 points 3 days ago* (last edited 3 days ago) (1 children)

I'm not saying Flatpak is perfect, but it appears to be the best we have.

I absolutely agree more needs to be done to explain permissions and have sane defaults. Flatseal in particular could introduce more warnings, and this is where non-technical users set their permissions.

In my experience, most Flatpaks do not request full home folder access by default, and making Flatpak access everything everywhere typically requires user intervention.

Native apps, meanwhile, just run with full system-wide access; I get it that they're more vetted and more properly updated, but this is an unhealthy and insecure arrangement.

[–] [email protected] 4 points 3 days ago* (last edited 3 days ago) (1 children)

this is a system for work tasks. Of course, I understand what the developers are going for. that is Android. And it's really nice to read the Internet on android. But try to do something more complicated than that and you'll realize that it's hell. However, I don't mind if such distributions appear. Why not? I just don't understand people who voluntarily limit their abilities. And why you don't just install Android 64?

The flatpack approach automatically remove everything low-level from the equation. Do you want to write directly to the graphics card buffer? Read the input? Do I set the fan rotation parameters directly in the /proc? All these applications will never work in flat pack.

On the other hand, flatpack is superfluous and for convenience. You can simply build an executable file without dependencies and configure firejail for it yourself... That's all. Or run the file from another user. That is so popular exactly bacause RedHat pushed them. Literaly like Canonical pushed snap.

[–] [email protected] 8 points 3 days ago (1 children)

All these applications will never work in flat pack.

They don't have to! Flatpak doesn't remove all other ways to install software. But for 95% of use cases, it will do just fine.

Firejail is good, but it only solves sandboxing part of the equation, and there's so much more to Flatpaks than that. Also, it's more painful to configure and is more sysadmin-oriented.

[–] [email protected] 3 points 3 days ago* (last edited 3 days ago) (1 children)

They don't have to! Flat pack doesn't remove all other ways to install software. But for 95% of use cases, it will do just fine.

Tell this to canonical, they even firefox put in the snap. You know that when choosing "quickly compile something for a flatpack" and "support 10+ distributions", the developers will choose a flatpack. Which in general looks fine, until you realize that everything is just scored on the mainline of libraries and molded on anything. The most striking example of this is Linphone. just try to compile it...

[–] [email protected] 6 points 3 days ago

Snap is cancer, and what Canonical does is insane.

In any case, it is unlikely someone will make an exclusive Flatpak for what doesn't work inside Flatpak. But I understand it means a lot for user choice and ability to compile programs they way you want, so I fully support shipping Flatpaks alongside classical packages and source code.