https://www.garagebandapp.net/This is a great post. I like this topic. I found many interesting things from this site. Thanks for posting this again
Flatpak Is Not the Future
361–370 of 410 posts
Re: Flatpak Is Not the Future
#362Earlier quoted context omitted.
Any application that depends on either of those indirectly depends on libpng and dozens of others. Its a dependency tree, just cutting it of after the first dependency does not make sense in any context and even less so in a context that claims to measure package reuse.
The KDE and GNOME platforms contain all of those indirect packages. They contain basically everything generic that you need to build a GUI app. Then when you go off in to the specific little tools you need, you bundle those in.
Oh, I thought that the claim was that there was zero package reuse with linux package managers. Not that there was zero package reuse with flat pack.
Re: Flatpak Is Not the Future
#363Earlier quoted context omitted.
There are plenty of drawbacks: - Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever. Most do not provide security updates at all. - Privacy: distros like Debian spot and patch out trackers, telemetries and similar things. - Long term maintenability: your desktop becomes a random mashup of applications with increasing complexity that you have…
So basically all the same drawbacks as in Windows, when you install third-party software?
Haven't used Windows in a decade, but third party apps on Windows don't even have the framework for some sort of package management, do they? At least with snap/flatpak/AUR/PPA you got an aggregated updating interface and optionally sandboxing for snaps and flatpaks.
I think, something like Appimages are the better fitting equivalent to Window's normalized madness, no?
Re: Flatpak Is Not the Future
#364Earlier quoted context omitted.
Look into Flatpak portals. I'm not sure how they work wrt bubblewrap, but they pass limited interfaces to various things into the container. Things on the host side then prompt the user for which webcam/etc the app should get access to. I think they are similar to Android intents in that the app can't ask for access to a specific thing, just for access to certain kind of things and then it is up to the user to choose…
Yes, I am familiar with portals and what they do: I was exactly wondering if bubblewrap contains something similar — it's been ages since I was involved with Linux system architecture (let's say I am stuck in the SysV init world, and I still go for "service apache2 restart" :)), so it'd be great if there was a quick introduction for someone wanting to use flatpak/snap style sandboxing without the dependency managemen…
bubblewrap can bind-mount paths from outside the container inside the container. I haven't verified this but I'm assuming portals are just sockets bind-mounted into the container. I suggest you maybe install Fedora in a VM and run a flatpak app there that uses portals and try to inspect what files are passed into the container.
Re: Flatpak Is Not the Future
#365Earlier quoted context omitted.
> if it worked very well there wouldn't be a need for flatpak / snap / appimage / etc. Exactly: There isn't. > How do I install an older or newer inkscape / ardour / krita in the latest debian stable / ubuntu / fedora / whatever without recompiling stuff ? You don't. Or if you have to, do it on Gobo (or perhaps Guix or NixOS?).
That's a ridiculous answer. "You don't" means people go back to windows or Mac OS where they can do that easily because it's an actual need people have. That's the worst outcome by far as it leads to less support on Linux.
No, "you don't" is a valid answer. You use what is in the distribution. You chose the combination of archives (stable, stable+backports, and so on...) as you need.
Then you use what the distro provides.
(The same way as you use the default, tested and guaranteed engine computer on your car rather than installing one bought in a dark alley.)
Like the car, distribution work when you use the whole set of components bundled and tested together.
If upstreams make it difficult to package new version you can help by asking them to step up their game or switch to a better software.
If you want to build a Frankenstein bundle of software you are free to do so but you'll be on your own when things start to break.
Re: Flatpak Is Not the Future
#366Earlier quoted context omitted.
> they are definitely more secure against malicious apps than Linux with apt-get Not at all.
Unless you're running something like Firejail on your system, yes they are. There are a metric ton of holes to plug in the Linux security model, Linux security is a dumpster fire. But... run Wayland, use Flatpak (and check your permissions), check file access/network access -- these are steps in the right direction, they are security improvements over apt-get. We know that isolation/sandboxing (and in particular file…
> Unless you're running something like Firejail on your system, yes they are.
Which I am, but this is besides the point.
> There are a metric ton of holes to plug in the Linux security model, Linux security is a dumpster fire.
Please don't spread FUD. Perfection does not exist in this world but Linux is used in most security critical environments in the world, from banks to military applications to security devices like firewalls.
> But... run Wayland, use Flatpak (and check your permissions), check file access/network access -- these are steps in the right direction, they are security improvements over apt-get.
Sandboxing and installation tools like apt-get are completely orthogonal topics. Flatpak blurs the line and people get confused.
Furthermore, sandboxing can be effective only if the whole UX is designed and tested centrally.
Applications need access files in ways that are compatible with each other and useful for the end users.
Policies need to be written and reviewed by a trusted organization.
You can't rely or random upstream authors to configure sandboxes for different applications independently from each other.
Sample the sandbox settings on some flatpak applications and you'll find they range from too strict to completely lax.
> Android/iOS's model of app isolation is unambiguously more secure than an apt-get free-for-all
And yet the phones are full of spyware/telemetries antifeatures.
> I would not today assume that Flatpak is secure or battle-tested
It's not.
Re: Flatpak Is Not the Future
#367There is a deep trend happening in software development. As the number of dependencies for building an application grows, it becomes exponentially harder to shake the tree. This used to be the role of Linux distributions, they were acting as a push-back force, asking projects to support multiple versions of C libraries. This was acceptable because there is not C package manager. Now that each language has their own p…
I watched a great rant by Linus T himself on how distributing code for Linux is a "pain in the arse", but is comparatively easier on Windows and MacOS: https://www.youtube.com/watch?v=Pzl1B7nB9Kc
Something I took away from that is that it is Linus himself, personally, that is responsible (in a way) for Docker existing.
Docker depends on the stable kernel ABI in order to allow container images to be portable and "just work" stably and reliably. This is a "guarantee" that Linus gets shouty about if the kernel devs break it.
Docker fills a need on Linux because the user-mode libraries across all distributions are a total mess.
Microsoft is trying to be the "hip kid" by copying Docker into Windows, where everything is backwards to the Linux situations:
The NT kernel ABI is treated as unstable, and changes as fast as every few months. No one ever codes directly against the kernel on Windows (for some values of "no one" and "ever".)
The user-mode libraries like Win32 and .NET are very stable, papering over the inconsistency of the kernel library. You can run applications compiled in the year 2000 today, unmodified, and more often than not they'll "just work".
There just isn't a "burning need" for Docker on Windows. People that try to reproduce the cool new Linux workflow however are in for a world of hurt, because they'll rapidly discover that the images they built just weeks ago might not run any more because the latest Windows Update bumped the kernel version.
I read all the way through this and wept: https://docs.microsoft.com/en-us/virtualization/windowsconta...
Re: Flatpak Is Not the Future
#368Earlier quoted context omitted.
You misunderstand. I am saying that all that effort was spent chasing the long tail of compatibility, which is valuable if compatibility is one of your big selling points. However, one need not go to such extremes to get a good amount of compatibility, just don't have a policy of breaking ABIs constantly the way Linux Desktop does.
And let me address the "policy of breaking ABIs constantly the way Linux Desktop does." As you probably know, there is no policy, and no "Linux Desktop" either. You've got Linux distribution releases that are supported for up to 10 years (like RHEL and Ubuntu LTS) by teams a couple of orders of magnitude smaller than either of MacOS or Windows. They usually get HWE kernel updates too (hardware enablement) from newer…
> As you probably know, there is no policy, and no "Linux Desktop" either.
Yes, a common refrain.
> You've got Linux distribution releases that are supported for up to 10 years (like RHEL and Ubuntu LTS) by teams a couple of orders of magnitude smaller than either of MacOS or Windows.
Yes, and they're not really equivalent because they keep everything stable. An OS like Windows or MacOS keeps the platform stable and allows applications to be bleeding edge or not as desired. This way applications are typically distributed on Linux make this very difficult, hence things like Flatpak.
Regarding the team size, I can only say that if everyone worked on the same "distribution", that gap would be significantly reduced. Instead the Linux Desktop world delights in duplicating effort, so here we are.
> But it's in the nature of free software world to want to mix and match, so the idea of a singular Linux Desktop does not exist. You should treat each one of them as a separate OS, which is unfortunate, but realistic.
If that is the policy, then no one should be surprised when developers choose not to target a non-platform that doesn't exist.
Re: Flatpak Is Not the Future
#369Earlier quoted context omitted.
You misunderstand. I am saying that all that effort was spent chasing the long tail of compatibility, which is valuable if compatibility is one of your big selling points. However, one need not go to such extremes to get a good amount of compatibility, just don't have a policy of breaking ABIs constantly the way Linux Desktop does.
Ok, I see your premise now. I am not sure I agree: do you know of a system that has seen less investment on backwards compatibility yet successfully maintains it? Of course, not "frozen" like TeX, but seeing active feature development too.
Pretty sure HaikuOS runs software originally compiled for BeOS in 1995. They have a very small development team and they are quite active today.
...for that matter WINE is even able to make Linux compatible with Windows applications to a great extent, and they certainly aren't backed with Microsoft's wealth of resources.
Re: Flatpak Is Not the Future
#370Earlier quoted context omitted.
I don't think this is really true. There is a fairly stable core set of C libraries present on virtually any Linux distro with a desktop environment that does most of what any application needs in terms of system services. The basic problem is more what the parent was discussing: these are C libraries, and rather than using the FFI for their app language of choice and using these pre-installed libraries, developers w…
There is no common/stable set of c libs. libc on one distro is different than libc on another (even just within glibc). It's why you generally can't run an app compiled on one distro on different one. You also at times cannot do this on a newer version of a distro and run it on an older version. When a piece of software lists an rpm targeting Fedora or a deb targeting Debian, these are not just repackaging of the sam…
> There is no common/stable set of c libs. libc on one distro is different than libc on another (even just within glibc). It's why you generally can't run an app compiled on one distro on different one
Pretty much everything uses glibc and distros that are to be used by end users (instead of specialized uses like embedded) also tend to have glibc versions. If someone uses a non-glibc distro it'd be out of their choice so they know what they're getting into.
And glibc has been backwards compatible since practically forever. You can compile a binary on a late 90s Linux and it'll work on modern Linux as long as all libraries it depends on have a compatible and stable ABI. I've actually done this[0] with a binary that uses a simple toolkit i hack on now and then, this is the exact same binary i compiled inside the VM running Red Hat from 1997 (the colors are due to lack of proper colormap support in my toolkit and the X in the VM using plain VGA) running in my -then- 2018 Debian. This is over two decades of backwards compatibility (and i actually tested it again recently with Caldera OpenLinux from 1999 and my current openSUSE installation). Note that the binary isn't linked statically but dynamically links to glibc and Xlib (which is another one with strong backwards compatibility).
