Nixos and Guix are the (my) future.

Same here. Reproducibility and declarative configuration are the future!

art
link
fedilink
52Y

That’s correct. Flatpak is the present. It’s happening right now.

Is it though? is it integrated by default in your desktop environment? Can you easily add 3rd party repos from GUI? Can you finely edit the sandboxing settings for an app from GUI?

Hell, i can’t even find how to make flatpak apps respect my keymap for keybindings. Inside a flatpak run’ed app, typing respects AZERTY but pressing Ctrl+A will trigger quit dialog (Ctrl+Q) as if i used QWERTY keymap.

@pinknoise@lemmy.ml
link
fedilink
2
edit-2
2Y

is it integrated by default in your desktop environment?

It creates .desktop files what more ahould it do?

Can you easily add 3rd party repos from GUI?

Why would GUI users need to do that?

Can you finely edit the sandboxing settings for an app from GUI?

https://flathub.org/apps/details/com.github.tchx84.Flatseal

art
link
fedilink
02Y

Your response was far more accurate that I could do. 👍

There are two problems these are “solving”: API incompatibility and isolation. Both of this issues are a real problem when you want to run proprietary software.

When you have a source code of all applications and libraries you can compile them and otherwise patch them to get things working together most of the time. This way we don’t have to worry about changing libraries that much.

When you can trust your software you don’t need isolation. For programs like Firefox things are a bit different since it is, by default, running untrusted software and it’s sandbox will never be perfect. You can get isolation without duplicating all dependencies using process isolation (what Android does) or even using namespaces where you share your root files system but not your home directories.

So for open source software these systems are creating more problems then solving. For running potentially malicious system on Linux I don’t think we have a good solution yet, or if we even should waste time solving it. There are better OS designs that would make this easy (Plan9, object-capability bases security, etc.)

As for Windows the business model that MS is trying to support is vendor locking combined with licensed closed source binaries. In such case the long term backward compatibility is a must. And consequences of such models we are all aware of.

@ganymede@lemmy.ml
link
fedilink
0
edit-2
2Y

if needed, whats wrong with static linking?

You can statically link binaries. Plan9 does only that, Rust and Go only support static linking (by default). The problem is that you need a good meta-data system that will allow you to track what was linked into each binary, so that if there is a security issue you know exactly what needs to be rebuilt. I don’t think we have such a system yet. If I have a bug in OpenSSL I just update that, restart servers using TLS and it is patched.

The problem is that you need a good meta-data system that will allow you to track what was linked into each binary

Fantastic idea! This would be a really important project to see developed!

@pinknoise@lemmy.ml
link
fedilink
4
edit-2
2Y

Imo they’re right, but theres some weird (pro proprietary software) claims in there.

If I ship an app for Windows I don’t have to include the entire Win32 or .NET runtimes with my app. I just use what’s already on the user’s system.

Those cases are rare on windows, most apps package their own versions of dependencies just like with snap/flatpak/appimage (just not so neatly organized) and it sucks.

Backwards compatibility is a major part of why Windows is still the dominant desktop OS.

But thats also a major part in why it sucks and is insecure. Microsoft knows that and has started to break stuff with higher frequency too. You should only freeze interfaces when there is a consensus that there isn’t anything to be improved anymore. You can only build this consensus when you have a clear use case.

I’d argue, that this is impossible for operating systems with desktop and all. So best you can do for backwards compatibility is to only put breaking changes in major versions and still maintain older ones. Of course that means you can’t have major versions to often and now people will complain that your software sucks because it can’t even do X.

Microsoft does this too, but they often release a whole new product instead of version bumps. And by that they accumulate even more technical debt.

Businesses actually care about this! They use ancient proprietary software that is critical to their business whose source code has long been lost to the sands of time.

This isn’t a case that should be handled by FOSS developers, but by courts fining them for putting their employees, customers and business partners at risk! Running software that isn’t maintained by you or a third party is a liability.

I find those points of theirs to be pretty weak.

  1. With Flatpak most of the runtime stuff is packaged separately, so on Flathub for example you have most of the applications using common runtime components. Sometimes you need multiple versions of one of them, but the same goes for a lot of Microsoft’s stuff.
  2. I don’t find Windows to be any more backwards compatible than Linux is. On Linux you get the advantage of having access to the source more often, so source is going to be compatible for longer than binaries will. Source can be updated for compatibility too, giving it infinite life. (Of course, binaries could have infinite life if you take into account all the compatibility methods like virtualization.)
  3. Yeah I’m sure business just love using ancient proprietary software and not being able to upgrade their systems. Oh wait, I thought compatibility was strong on Windows. (Not that all such software runs on Windows, but of course a major chunk of it does.) Businesses will eventually have to replace that old stuff, whether it’s sooner or later. It would have been better if they had the source code in the first place and could use that to help them upgrade or replace it.

With Flatpak most of the runtime stuff is packaged separately

They mentioned that not all flatpaks use the same separate runtime. Ideally they could just use the one my distro packages.

I don’t find Windows to be any more backwards compatible than Linux is. On Linux you get the advantage of having access to the source

You can run (a lot of) really old (late 90s) windows binaries with the modern libraries. You can also probably run really old linux binaries, but only if they use syscalls directly, not if they are (dynamically) linked against e.g. libc or x-stuff. Of course if the source is open, you can make it work.

Meh, I’ve been using the official Firefox flatpak, and I love that my web browser has no access whatsoever to my ~/.ssh private keys, or anything else I don’t want it to be able to read

CHEF-KOCH
creator
link
fedilink
-22Y

You could store it via KeePass and ~/.ssh can only read out by your Browser if you are using the same user account to run both, so I would recommend storing ssh-keys in the home directory of another user account. Another way would be to encrypt ~/.ssh if you store your keys there.

There has never been a better time to ship a binary app that targets the Linux desktop. And I don’t mean targets its own bundled runtime; I mean truly targets the user’s runtime environment. The time is now.

I have my doubts. If I compile something for Linux today, I don’t believe the chances are great, that this binary will run on an arbitrary Linux.

If that is true, am I able to download some binaries from any distributing package repository unpack it, and run it? Can I just run an Arch-Linux KCalc and run it on an Ubuntu 20.04? Will it be able to run in 25 years?

I think this is the one thing that those package managers will be able to solve.

I understand the critics, but I do not see an alternative as of now.

poVoq
link
fedilink
12Y

In my experience they usually do work cross distribution if you build them on relatively standard and not bleeding edge system. But sure, they will probably not work 25 years from now, but that is really only a problem for software without the source available, which I consider the bigger issue.

The distro packages are not distro-agnostic. But a linux release tarball is distro-agnostic, although some system settings can affect it.

We’ve been doing release tarballs for literally decades now and there’s nothing wrong with them, but package managers help with updates, GUI, and dependency management. AppImage in particular supports PGP signatures and differential upgrades, which is pretty cool. Flatpak has interesting approach about “portals” for sandboxing, although it’s far from user-friendly or secure so far. Snap has really nothing going on for it and there’s absolutely 0 reason to use it. [0]

[0] Yes there’s one reason, as always, it’s pushed by a big corp. So leap.se project for example packages bitmask only for snap because that’s where their userbase is. Such a shame.

Dessalines
link
fedilink
22Y

As a user of arch btw for many years, does anyone have any link to anything that fully goes into why a lot of distros such as arch don’t have this problem? Packages, runtimes, and dependencies have been a non-issue on arch (and I’m sure other distros with proper package managers) for a long time.

Dependencies can absolutely be a problem. Let’s say you have a Python program that relies on an older version of a package due to a breaking change. With Arch those packages are installed in a per-Python interpreter global namespace. So if two applications have conflicting version requirements for a package, you’re kind of screwed. Yes, there are ways around the issue, but it’s not customarily used in Arch.

This is just not a problem with Flatpak. The dependencies can be installed directly with no fears about causing a conflict. Even if the Flatpak itself uses a runtime, that runtime allows the Flatpak to add its Python dependencies as a simple layer on top. This happens independently of any other Flatpaks.

Just in case you are not a native English speaker, the correct way to write your title is, “Flatpak and Snap are not the future”

This is because the subject of the sentence, Flatpak and Snap, is plural. I have some students who get confused with this since the subject is made of two singular nouns.

Portage

Mass containerization and alternate runtimes cannot possibly be the future of desktop apps on Linux. If this is really the direction it’s going, the future will be so shitty that we’ll all end up back on macOS or Windows.

This posts features great complaints but really shitty reasoning. Very immature perspective on things.

If you are so upset about it, name the perfect alternative, contribute to one, or go make one. This post barely approaches solutions and spends all of it’s time whining about the outcome of technology choices without even touching on what they would change.

There’s more precise criticism in the article. For example, that the “portals” system tries to be transparent to applications instead of exposing an explicit API. Or that maintaining multiple huge runtimes makes it likely you’ll need a lot of storage just to run new apps (contrary to a system like guix/nix where only specific deps would have to be duplicated). Or that the drivers/graphics stack should be part of the OS for consistency, not be bundled with applications. Or that layering many forms of containerization is not sustainable/debuggable.

There’s an entire “Is Flatpak Fixable?” section full of recommendations.

@daojones@lemmy.ml
link
fedilink
1
edit-2
2Y

deleted by creator

Right. .appimages are the future.

They are even worse, since they don’t come with an update mechanism builtin.

poVoq
link
fedilink
12Y

Flatpacks don’t update themselves either, you need a system service to do that. Something similar exists for Appimages, called AppimageUpdate without requiring an appstore for it.

@daojones@lemmy.ml
link
fedilink
1
edit-2
2Y

AppImages don’t integrate into the system at all and AppImageUpdate sucks.

Also flatpak update go brrrr

poVoq
link
fedilink
0
edit-2
2Y

Appimages are well integrated in Manjaro for example. You click on it to and you automatically get the choice to have it installed with menu links and all.

I can only assume you never properly used Appimages as they are surely better then installing a full Fedora runtime environment just to run a basic app as in the case of Flatpack.

AH really? What DE? I guess everyone should use Manjaro. For me, I have to right click, run as executable. Firefox doesn’t work, Pling icon looks like shit, can’t update them without using a poorly made updater program. No thanks!

poVoq
link
fedilink
-12Y

KDE.

Why on earth would you run Firefox via an Appimage? All these container formats are only good for apps that are not up to date / available in the distribution’s repository, and Firefox certainly is.

That’s the main thing I don’t like about app images. It is just like windows where everything needs to be updated independently.

What if they made a package manager for appimages?

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

  • Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
  • No misinformation
  • No NSFW content
  • No hate speech, bigotry, etc

Related Communities

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

  • 0 users online
  • 5 users / day
  • 20 users / week
  • 27 users / month
  • 16 users / 6 months
  • 20 subscribers
  • 684 Posts
  • 1.7K Comments
  • Modlog