15 years ago when I was using Ubuntu, I would never thought that there would be a format that would work on every distro, back then the closest thing to a "universal" package were .debs I remember people would dream of an unified linux format for packages so that companies would be more open to the idea of providing linux support. I find it weird that nowadays there are people that are against distros moving to flatpaks by default.
@@TheLinuxEXP People wanted (and still want) a universal format. The people who complain more about the fact that Flatpaks are sandboxed and each app ships with all the libraries it needs, leading to apps that take up a LOT of space. This model eliminates dependency hell (shudders) and each distro shipping its own version of packages. I guess the complainers just need to get a larger SSD :D
@@gigalodon14Infinite disk space is never a thing across all systems . I just wasted over 1 TB because one upstream developer insists on making every niche feature mandatory and the dist repackaging didn't fix that .
One thing flatpak really needs to do is change their terminal format to just be the application’s name, not a long and obtuse URL. It would make it much more terminal-friendly; snap already works this way, so it is possible.
Very good point, though it does do it's best a guesstimating what you put in when installing. It can be a bit annoying on occasion having to pull up a browser to find the link etc.
I was going to say the same thing about FreeBSD ports. The thing against both of these is that general desktop users don't want to compile an application even if it's as simple as make and make install. The move to Universal packaging will really make distros have to work hard on their core value propositions to users.
A particularly painful "niche" use case where Flatpaks bring headaches for the user is in IDE's. That sandboxing keeps them from (easily) finding the local installs of Java, or Python, or whatever else you happen to be developing for.
I have jetBrains IDEs in flatpak only because most of my apps are in docker containers, and I can pass the docker socket into flatpak using flatseal. If it wasn't the case, pacman -S all the way.
Yeah this was nearly always a headache for me although I kinda fixed it through giving access to distrobox containers to the ide. Code has a dedicated containers extension which is cool. That way I still have my dev env.
I had this problem with JetBrains IDEs in Flatpaks. Set up host-spawn and whatnot so I get a native-like experience but it was annoying so I switched to their Toolbox app which... made my desktop freeze each time I updated an IDE. Not sure what was up with that. So I might return to Flatpaks. They do have nice WSL integration so they cooould integrate with Flatpak too but oh well.
I really wish that Canonical would drop snaps and start supporting Flatpak instead, and any missing features they could easily help work on adding them.
There's something that irks me. Many years ago we had fully contained programs. Then, we decided to use libraries, that is, use parts of other programs so we can focus on our stuff. And programs became more feature rich and small, since the libraries were separated. Also, neatly, the libraries can be SHARED by multiple programs. Maximum efficiency! Then, also, the libraries can receive updates like that critical vulnerability bugfix independently. How awesome is that ? But then we got into the dependency hell. Which was mentioned in this video. Libraries don't have an immortal, immovable, unchanging API. So from one version to another, some apps might not be compatible anymore. This is when the "must have everything updated, must update every week OR ELSE" trend started to appear. And also the problematic older softwares that didn't receive updates anymore, basically got stuck to a specific version range of the libraries it uses. Now here comes AppImages, Snaps and Flatpaks. They solve this by having a container, and inside having the exact libraries needed, no more, no less, and the versions that are supported by the app. Awesome, now everything works again. But these have major downsides. Mainly because of the container. A lot of extra space and indirections and overhead. Modern CPUs are quite powerful and the normal user does quite little, so it's hard to notice in those cases. But the inefficiences are there. I'm not happy with this becoming the standard, to be frank. But, if having this become accepted, I JUST HAVE TO ASK, why can't we simply have programs with all the dependencies compiled statically then ? It's still a duplication of libraries, but, at least you still have the native app, with its 100% uses cases working. It will still have the native speed. So the overhead is really minimal. And it will reduce a lot of problems that currently appear because of weird library versions configurations. I mean, you do get the "now it works in most cases" and "easier to debug because it's the same for all users" part, but without the container downsides. And, yes, I know that the container route has upsides too, mainly the sandboxing. Neat, but, frankly, for a desktop, a personal computer, I couldn't care less. Give me FOSS and I'll have my security by having good practices and not being stupid. I don't need to throw half of my computer performance and space by having security. I'm not running a server where some weirdo from the other part of the world can upload and run anything. Alternatively, why is it so hard to have native apps and support for multiple libraries versions at once ? Like Guix does it. I like that solution more.
Statically-linked apps don't just use more disk space. They use more memory too. If you have three apps running that link against a shared library, there's only one copy of that shared library's code mapped into memory. If they were statically linked, you'd have three copies of the library. You'd very quickly complain about the incredible bloat. Shared libraries do include versions and it is possible in theory for multiple library versions to coexist peacefully on a system. However, this requires careful planning on the part of the library developer. The standard C library is well-maintained in this regard; other libraries... not so much.
@@dfs-comedy Yeah, true. I'd hope that the extra RAM requirements won't be big, but I'd complain nevertheless :D Still, when compared with flatpaks and such, I don't think it's worse. From what I know, they don't use shared libraries. Regarding versions, is it just from the library developer, or is it from the developers who use it too ? I mean, I don't know how this link is defined, how easily is to set/overwrite the version/library file ?
@@Winnetou17 I'm not 100% sure how Flatpaks work. I believe Appimages package their own copies of shared libraries, so multiple processes in an Appimage can share libraries, but not with anything outside the Appimage. Library versioning is controlled by the author of the library. Shared libraries have a soname that specifies the version, and there are even ways to keep multiple different versions of an API within the same shared library using ELF symbol versioning. There is absolutely *no* excuse for DLL Hell on Linux.
Two corrections. Firstly, before distros, we would install software by downloading a source tarball with ftp and then work out how to compile and install it. Secondly, while it's true that rpm and deb formats are basically equivalent in functionality, the main difference between packages for each distro is the way the software gets set up, not just the versions available. I would also like to argue with the idea that in general users want to use the latest stable version of all their software. If I have a workflow that works for me, I don't want to have that change. I really really appreciate stability of user interface because computers are a means to an end, not the end themselves. I also know that programmers don't go to very much effort to follow things like the FHS or packaging their software to be nicely configured and running out of the box, or caring to make sure their software plays well with other software you might have running, or care about making sure to monitor security updates in the libraries used. This is the main reason to use a distro and why container-based installers and things like NixOS are a really bad idea. These encourage a "works for me" development model, with little respect for the end user's preferences.
I would argue there are differences in users and differences in use cases. Some users prefer rolling-release while others prefer stable releases. There's also a difference in each use case. For example when you want to use/try the latest feature of some application, you would pick a rolling-release of it. However when you just want it to work as every day before in the last weeks to get things done, you would pick a stable release. I don't think one can replace the other. I use four different distros with different package policies at the moment and they just work as intended. I don't see why everybody would want to have rolling-release all the time. It might completely break your workflow some day.
what pdr wrote. Plus packaging well written SW is not that hard, if some package is very difficult to build or requires frequent changes to package building script, it's usually due to developer of the SW. Plus debian packages have usually also their source counterpart, so you can build the binary yourself, which may be handy if you want to patch the code yourself a bit or to build for unsupported HW platform or just verify the packager integrity and check if the binary is really matching the source code. I have no idea how much snaps/flatpaks care about providing also build recipy to rebuild them yourself. But without the source code and ability to patch the SW yourself the stuff will deteriorate over years to the point where you will be in binary-only distribution world unable to verify/patch anything without actually reverse engineering the binary itself.
I’d argue NixOs is the path businesses would take if linux was used in the workplace. Managing hundreds to thousands of computers is monotonous and usually done with scripting, but still requires petty user initial setup. NixOs allows the it department to buy the computer, pull the config file, insert specific user, run nix build switch. Done. No scripting, just done.
@@emptydata-xf7ps Can't say I agree. For production systems, it's important to know what libraries you use to ensure you aren't using anything with known vulnerabilities. Nix (and for that matter, containerised deployment systems) makes this very difficult. Using a stable distro in combination with a good CM system provides security, compliance and agility with the greatest of ease. Very little custom scripting is needed, maybe only when it's required to package internal software.
As a Fedora user, I would embrace having apps like Firefox, LibreOffice and Thunderbird shipped as Flatpaks. I would only really be against such a move if I got Snaps instead of Flatpaks.
i would hate if fedora dropped the Firefox rpm. i have bound firefox to a key shortcut and when another Firefox window is open the shortcut takes a couple of seconds with flatpak but it's instant with the rpms
Viceversa for others. But as long as flatpacks are limited by design (unlike snaps), they simply cannot distribute what a snap can (drivers for instance), so they will never be a full replacement, .rpm or so will need to stay for some types of apps. This is not ideal when you go on that path.
I once installed Firefox as flatpak and I could not import my bookmarks from chrome or other browsers, on apps like Steam I could´nt even move my games to another partition only in it´s sandbox..
I think there's a security aspect of it which is sometimes forgotten: Who do you trust? There are some points to be made: 1. Trusting 1 vs MANY entities: When you choose a linux distro, you are effectively trusting the organization and maintainers behind them (even if you didn't even realize). They are who build you distribution, compiles your software, chose what goes and what does not go in the repos. Be it a company (like RedHat or Canonical) or a community (like Debian or Arch), you rely your trust in them. But now think about when using this universal packages available to every distro and more, submitted and compiled by the developer - which is the suggestion this video makes (correct me if I'm wrong). Now you don't have someone to trust and effectively you need to trust every single developer that you download a software from. And there are A LOT. Instead of trusting 1 (most of the time) big, well known project, you need to trust many unknown (to you maybe) developers. I am not saying that small, independent or unknown developers are a bad thing, actually I am one of those, but I doubt you are familiar with every developer that wrote all your applications. But now you might ask: "Aren't I already trusting the developer, I'm using his code, what else to trust?" or "It has a lot of eyes in the source code, its fine". But is it? Thats the second implication. 2. Source Code != Binaries (packages) Usually you would be right in those questions, but in rare (but existing) scenarios there is a catch. There is an open source code. There is a binary. What assures you that the binary is from the public available unmodified code? What is stopping a malicious developer to apply a patch adding something undesirable - be it malware, tracking, telemetry, whatever - or even just a third party (closed source) dependency without the user consent? Nothing. Actually, you will only be sure if you compile it yourself. Welcome to source based distros like Gentoo. But most people don't want that hassle like me, and there is where the trust enters the play. If you don't want to do it, trust somebody else. The previous argument discoursed about who to trust. 3. The linux security and malware-free fame: There is a fame where linux based OSes are more secure and do not have virus. While this is not entirely true, it can be said it actually is more safe than other OSes. There are many reasons for that, but the obvious one, and probably the leading factor, is that it has a small market share, so bad actors develop malware to Windows (and sometimes MacOS, etc) instead. But there is another reason: the way users behave in these operating system. Windows users typically download software from the internet, browse, search, download then click-click install. In comparison linux users typically installs software from the distro's repos, be it using the command-line or a graphical application. This lead to the obvious security difference and concern. Downloading from untrusted sources on the internet is a BIG potential on having something going sideways. Now, getting your software from a well-known trusted organization is fairly safe and has gone well in many decades (can't be said about windows). But here is the deal, how different is the said Windows way of downloading programs than downloading an app in which (in this case study) a unknown developer packaged? How different is it than copying and pasting a shell command from stack overflow into your terminal ("RED ALERT DO NOT DO IT", security linux experts, i think). Of course it has its differences, but I cannot not see the similarities. 4. But Flakpak is secure, it is sandboxed by default. Yes! Thats a great thing. In fact, it does stop many possible "attack vectors", but not all problems are solved. What about privacy? What about telemetry? All the examples in the 'Source Code != Binaries' can be given here. So yes, it is sandboxed, but it is not a silver bullet. 5. WoW, what a DRAMA. This would never happen! Do you think so? There have been cases of Trojans in linux. There is existing ransomwares for linux. There has even been a case of injecting security bugs in the linux kernel on purpose. Yes, it is VERY RARE, but not nonexistent. --- Now that I have played the devils advocate, I should say that I enjoyed the video a lot and haven't thought about this matter in this point of view. Very interesting. I personally would say that I am 50% 50% on specific distro packaging and universal packages. Just wanted to point out somethings to think when pondering this.
flatpak """sandboxing""" literally doesn't exist by default because everything has filesystem=home privelege, which makes escaping the sandbox trivial. They'd be better off completely removing that functionality altogether and focusing on giving operating systems ways to more tightly integrate
Totally agree. I know a similar situation about the core.js and faker.js. The author deleted the original repo on the Github, which was not a big deal, but then he submitted a version with vulnerability behavior to npm, many users were affected. If it’s a regular package in the official repo, it won’t happen since the maintainer will do some test about the new upstream version. Another drawback of it is the mutilarch support. Since it’s packaging by the author himself,there is a high chance that he or she will only package for the mainstream architecture even if the software itself doesn't require any architecture-specific cpu command. For example, now Debian community is trying to support RISC-V, but many developers don’t have a RISC-V computer. In fact, they may don‘t know the architecture itself! So in conclusion, no silver bullet, we don’t have one universal solution to all problems.
I don't know why every package manager out there keeps ignoring that portage (or even ports) exists, it's had these problems solved FOREVER with package slotting (when you need multiple versions of the same lib), ability to pull in newer than supported versions automatically, etc.
Microsoft/ Google are also somewhat doing similar things like moving parts of OS to be a store "app" which can be updated separately using the store. Especially helpful in Android where major updates were made by the OEM and latest security fixes for small things wouldn't reach the users. Now most of android components can be updated for way long after the device is discontinued.
What Google is doing with that is using the non-sandbox package manager for some system apps, including some where Google updates are the wrong thing to install, such as apps that decide how much of your calls and text messages go through Google servers .
Which is kind-of how FreeBSD has always done things. The base image of the operating system and the ports collection are separate, and a lot of FreeBSD variants have their own separate base image, but use the same ports collection.
Windows just launched its own Package Manager though - which makes it easier to administrate apps (updates and installation) through the Terminal there, too. So, if you think about ease-of-use for Enterprises, that makes sense, too. As long as Flatpack also supports easy Updates via the Command Line, it might be good *enough* for most users. The only disadvantage of Flatpack-Apps I found when researching the topic and looking at people who did some Benchmarks for performance of a couple of Apps on Flatpack, native Distro-Packs and App-Images, the performance was usually a bit better on native Installations and some weirdly even on App-Images, but not on FlatPacks. I suspect it has to do with the Libraries used by the apps and how they perform running in the sandboxed environments instead of the native system ones. But that's just a guess on my part, which might also be wrong entirely. Nevertheless, there are pros to running apps natively - even though they might not be as "secure" then. But Linux as an Operating System is relatively hard to compromise thanks to how the whole system/foundation is designed - why many servers run so reliably with native code, too... Though, I do see the more "comfort" Flatpack offers in addition to the security for personal use. If I remember correctly, Ubuntu designed the Snaps to be used on Servers, too - and it's not exactly been working so well? But, all in all - I think we'll need to see how things develop - meaning: how developers prioritize working out the issues with either source...
@@BulukEtznab As long as the app is not very intensive I don't think the performance will matter much. It saves us from compatibility mismatch, like most windows apps package mostly all of the required libraries to reduce dll hell.
@@johndododoe1411 I absolutely love google for those things. I can't tell you how stupid it is to hear that iPhones have there browsers version locked to the OS. Things should be easier to updated, not harder.
That's the stupidest take I've ever heard. You don't need outdated packages unless you are running a server. You've been brainwashed if you think Arch is not stable or it breaks frequently.
@@xAffan stability here means packages and programs not changing. If i like the functionality of a program and it gets changed, it becomes ridiculously annoying to manually have to lock versions down. And I've been an arch user for years. Even with using ARM (since renamed) you're completely out of luck if you are using AUR packages
@@veruthas There are programs that can downgrade packages on Arch Linux. Anyways, you do need the latest functionality if you're using Linux as a home desktop.
@@xAffan absolutely not, like i literally said in my comment, it is frustrating and annoying to figure out which packages need to be locked down vs them being all locked down to the distro version, especially when needing to reinstall. And you absolutely do not need the latest functionality on a home desktop. Not sure where you got that from. If my OS allows me to do the work i need to, releasing new ones doesnt magically break functionality if the packages are being maintained until a certain date (and even then it will usually still work) I get it, you really like Arch, but that is irrelevant to this conversation.
@@veruthas It's incredibly stupid to use outdated software. I get it you're one of the people using office 2007 on windows 11 just because "it works". But the vast majority of the people want new features and any improvements that come with it.
Ideally, the OS model should look something like this (via GUI): - Pick a deployment model: reproducable or "traditional" - Pick your kernel: LTS or latest. - Pick your persistance model: atomic or dynamic - Pick your pacakge delivery mechanism...I tend to think traditional RPM/DEB/TGZ methods are fine for the OS. User-facing apps probably should be using something else. I'm not conviced flatpak (which I like) or AppImage (as typically deployed, there are FOSS projects that assist and make this more viable) are good answers. RPM was designed to accommodate proprietary software license agreements (so why was anyone surprised by RedHat's move?) so I tend to steer away OS's that use it by default. TGZ dependency resolution can be a little unreliable and lends itself to more technically savvy users. To each there own. - Pick your filesystem; the usual candidates... - Pick your interface: tty, i3, Plasma, etc Now do your thing, whatever that is. This is effectively what the Linux distribution model achieves but in a more chaotic way. Cathedral vs Bazaar. Community based systems tend to be organic and appear chaotic. They achieve organization through emergence. This becomes less sustainable (more energy intensive) the larger and more complex an organization/organism becomes. Either size or complexity have to give. E.g. Fungal network: Huge, but simple (they have few options to survive) For each, there ought to be an "I don't care" option which prioritizes end-user usability, flexibility and (where reasonable) stability. E.g. Traditional, LTS kernel, atomic (if well managed), DEB + ?, Ext4, GNOME Shell or Plasma Desktop, and you're off to the races. This approach allows all the collective developers to act as a collective rather than wasting resources being semi-competitive. This lowers monetary cost and effort, precious resources in the FOSS community. If that model doesn't work for you, you're probably a Linux nerd and Arch, Gentoo or LSF would suite you better. Go ham! From a business use case it completely makes sense why an application version would get pinned, and the latest stable would not be used. As applications update, dependencies and behavior can change. This needs to be tested, documented, and the deployment managed. Ugh. And Nix is not (quite) ready for large scale corporate deployments; it can be done, but requires more work than one would initially imagine.
SUSE has a new kind of persistence model called transacional, you can edit /etc fitles wihtout unlocking the root, and make any kind of installations that survive the update
@@friedrichhayek4862 The nazi's were fascists, and social democrats are just those who want reform of capitalism, as for stalinism or maoism I don't know much about the specifics of those ideologies to say much about them other than they were ideologies that emerged under the communist movement, and communism is not fascist since by its very nature the idea is organizing the economy under a democratic system and not a more authoritarian one like capitalism.
thing is: if there's a vetted package for, like, debian or fedora (I almost said redhat), you can assume it's working (as in, "it did for the past 20+ years"): it might not be the most up to date, but it does it's job 24/7 in tandem with all the other stuff you've got running. plug upcoming security holes as you go. going flat or snap, you're back on the random train again, getting the "(almost) latest and greatest" potentially half-baked things thrown your way - that might very well work on the newest pop!os or manjaro -- or not. (while eating away at your disk space: it might not bother you at home, or if you've got petabytes of storage at work, but: renting a cheap dev VPS, those 50-80gb of allocated storage melt quickly if every app installs a copy of all their required libraries, instead of making sure to link the existing ones. every time. going the microsoft way, basically.) tl,dr: IMHO, both routes are quite essential: the stable base, and access to the 'cutting edge', providing feedback to the devs. trying to force-merge them, I'd consider a major step back...
I like the hybrid solution. Native distro repositories for core applications and Flatpaks/AppImages for bigger and more specific software. Universal packages are a key element to bring formerly "expert" distros to broader audiences, Debian 12 wouldn't be as good without them for instance. I recently switched from "normal" Mint to LMDE and it was totally painless thanks to Flatpaks and AppImages. These two formats can still be perfected (size and performance for Flatpaks, and a better update/install management system for AppImages) but they're already a massive leap forward.
Flatpak and co. are a really weird way to fix the problem though. They are not only universal, they are also portable (which we don't need) and sandboxed (which has advantages, but should not be the default). Portability makes them bloated in size, sandboxing has practical issues. I've not used Flatpaks and co enough to speak on performance. Nix, to me, is the concept to the actual solution to the universal package problem. It eliminates dependency hell, it works on every Linux system (plus on Mac OS), but stays optimised (deduped dependencies) and native. Flatpak and co. are the solution to different problem.
I definitely prefer the flatpaks and snaps as a more streamlined experience makes it easier for users and also as you stated it makes it easier for devs to develop and free time to improve other things. I also feel it could make it more attractive to even mainstream companies to provide Linux support as they could also target every operating system in the Linux sphere
As soon as FirefoxPWA add-on works on flatpak, I won't need the deb built personally. Flatpak has been great and something like 1/3 of all my packages are flatpak now
That's why I just use Brave. It has PWA support natively, it completely FOSS, and will continue to have Manifest v2 support even when Google will attempt to kill it.
I’m a fan of the concept of universal packages but they’re still too hacky compared to native packages, I had to copy and paste a command to tell flatpaks to use my themes for example (when it should ideally be configured to automatically detect it from the get go), some apps have unwanted behaviors (such as title bars that are not present on native packages or opening multiple instances when it makes no sense, example of the latter: Slack). And of course the sandboxing unfortunately gets in the way of the normal use of the app (ex: code editors / IDEs). I use flatpaks and AppImages daily because they’re useful but there’s a way to go until they behave closer to what we expect from native packages. I just want to be lazy and enjoy my system without much thought lol.
It's not 'lazy' though. It's called using your software in a way that keeps your mental health stable. Linux is becoming more complicated, demanding more attention more often and hence elevating stress levels for more people. You come home from a hard, grueling 12 hour shift at your job and the LAST THING you need is more stress when you just need your PC to work! 'well it's not going to change. Deal with it!'. Yeah, well some people can't deal with it, period. Our technology has failed us.
You can open a bug report for that particular flatpak. Also there is flatseal to manage flatpak permissions. I think in flatpak setup section of every distro, they should also include a section about flatseal at the end.
This is why I like the *BSD model. The ports/packages come from the developers, not the *BSD team. They're untouched. The installation process is the same for every port / pkg.
Also *BSD is clean, everything is at its place, nothing is throw in one directory and good luck to find what you search when you're not sure of what you need to find. With *BSD, you always find, within minutes alone, not hours with some internet help.
I think having traditional repositories is still a good idea, and I wouldn't want them to go away altogether for things like system configuration utilities and things that sit 'beneath' the desktop. For that stuff, having the distro have overall control of what gets audited, tested and shipped makes sense. But for anything on the desktop? Yeah, Flatpak all the way. I use Flatpaks for near enough everything and will in a lot of cases not even use software that _doesn't_ come as a Flatpak. It's less work for distro maintainers, less work for developers and less hassle for me as an end user. It's a win-win-win.
I agree. Flatpak is probably the good ending for graphical apps. However, for system tools and things like that, I think distros should and almost have to keep packaging them. Something just feels off about installing a window manager with flatpak.
Things on the level of wm, will probably stay as distro packages, but there are also other terminal programs (for programming for example), I only know nix as an option (installable on basically any distro, no dependency hell, can be relatively simple, but also has expert uses).
Aah Dumbing down technology I see You probably don't know the horrors of having 100s of toggle switches, radio buttons, check boxes and drop down menus Almost every system application is better off on the cli with basic settings available on some qt or gtk gui
@@talkysassis huh? It's pretty much universal that all the system config files are on /etc/ all the user configs are either in your home directory or in the .config directory in the home, just use an editor of choice and edit them while referring the wiki or docs, what's the difficulty? It should be the norm for system application and it is It's fine for user applications to have gui settings and stuffs while also providing a config file for backup purpose. And also using too much gui reduces my reading comprehension, well that's my specific reason
The same point of error is excluded as soon as there's a team that hosts their own flatpak remote (no such possibility for snap). For example the fedora mirrors or some less "rolling release" more "stable" flatpak remote for people who want more stability even in flatpak
I used to see distro repackaging as critical to providing the "many eyes" to find bugs and independent verification you need to trust open source systems. However, I think Heartbleed showed the model isn't working in this respect. In rare cases distros might even make things worse like debian did in 2006 by "fixing" uninitialized data and weakening the PRNG seed for OpenSSL. I think funding independent verification projects is a better strategy and it seems like log4j has gotten some moving that direction.
It's no so simple as you said. Flatpak, AppImage and similar packages formats take a lot more disk space and more ram due to duplication of libraries and resources, and in most cases, original developers are not so quick to apply security patches to all used libraries (understandble because theyt are focused on their software). Only a distro or some big project (Firefox, LibreOffice, ecc..) can have a security team that can constantly follow security risk updates. So, if you want a stable and secure system these solutions are not so great. Probably this tecnology have more sense applied to rolling distros where users are more "adventurous"... :)
There is GNU Guix which does both well. Sadly it updates kinda slowly and currently lacks software in repositories (20k packages vs 90k for Debian for example).
@@zackbecker2117 which isn't user friendly enough to became a new industry standard imo. It might be a top 'elite' distro just like Arch is/was, but I don't see it as a good choice for beginners and casual PC users.
Perfectly good universal package management systems existed long before Flatpak and Snap, for example Autopackage and Zero Install, but they never got any attention from developers. I was partial to Zero Install and used it to install Rox Filer back in the day. One nice thing about it is that you don't need root privileges to install software.
The only app I currently use that I cannot replace with it's flatpack is VSCodium, I loose some features due to the sandboxing (But I would really like to be able to switch to the flatpack at some point, it would remove the need to add the VSCodium Repo)
@@sweetmelon3365 I'm guessing he needs to call an external binary, I remember not been able to call pdflatex in the flatpak version. Come to think of it you probably also cannot call any compiler or interpreter or binary you have compiled either, so defeats the point for an ide, can only edit configs haha.
@@sweetmelon3365 maybe I just don't know how to do, but a few examples are : - I use zsh as my shell but in the VSCodium terminal when using the flatpack it doesn't let me use zsh - I work sometimes in Go and have it installed, but flatpack VSCodium doesn't detect it. There might be other ones but I haven't pushed my tests further once I ran into those issues.
@@zapyvr If you need to run commands or tools from outside the sandbox, then you need (for example) set "flatpak-spawn --host zsh" instead of just "zsh". Iirc that what is written in the readme file that opens at the first startup.
I am all for Flatpak taking over the desktop application space, which it hopefully will (outside of Ubuntu), as long as we have applications like Flatseal that allow us to also manage permissions, levels of sandboxing, and theming within the app. I think the ideal future for the Linux desktop has all distros using Flatpak for all the desktop packages, with the core packages, the lower-level components of major desktops (like Mutter and gnome-shell for GNOME) and packages used by Tiling users, being the only programs still packaged as native packages. As well as that, this ideal future I envision will have people split between regular and immutable systems and everyone will use Wayland, including Tiling users who would have switched to River, Hyprland, DWL, Sway, and others that might emerge in the future. In this future, Wayland has taken over from X11, and Flatpak has taken over desktop packaging from native package formats. I can't wait for such a future, and genuinely hope and believe that it will happen within the next 5-10 years.
The problem I have with many of the more "modern" systems like Snap, Flatpak and Wayland is that they are functional regressions. Because of the increased isolation, many advanced features just break. Wayland was supposed to simplify things, instead it just made everything an unholy API mess with ugly workarounds for e.g. screensharing or injecting keystrokes/mouse for automation. I blame the devs, who long ago stopped caring about the user experience. Which is why Linux will never be a viable desktop OS. It's for geeks with way too much time on their hands, and for servers where security is up to the admins - not dictated by moron devs.
@@wombatdk Unskippable permission systems are the worst. A real-life example: the camera app on my Android phone sometimes says «camera unavailable, locked by another app» for no reason and I can't do anything about it. As for the desktop viability - I'm a geek and I would much prefer a program which does stupid stuff but can be reconfigured to not do it than one that I would have to rewrite to act properly. I just don't wanna bother with stuff like the aforementioned API cluster of Wayland (maybe it will get unified and improved in the future?).
@@formbi I'm guessing you meant "unskippable permission systems"? Other than that, totally agreed. Considering the history of Linux I have a hunch that unification isn't in Waylands future. The best we can hope for is, I think, that one will become dominant and the rest will die off.
I have had nothing but issues with Flatpaks for most of the applications I use, there are theme issues, certain features are broken (such as notifications). Personally I have had less issues with Linux 5 years ago, compared to now with these universal package managers, and other ways in which Linux developers are trying to reinvent the wheel. So for me Debian, Arch, and NixOS with no Flatpaks are the distros which are actually usable for me on a daily basis without any issues. Personally I think that Nix is the universal package manager that just works, but is often overlooked. The new user experience must also be something that is just confusing before you just had to learn the package manager that came with the distro, now there is the traditional package manager, flatpaks, snaps, etc. which all work in different ways and one method does not work for all situations (no cli flatpaks) , which I believe is something that can put a new user off from Linux all together, this does more harm than possible good.
The thing I‘m missing the most is things like compilers and other libraries. Ubuntu for example does set some weird default compiler flags both on GCC and LLVM and while we in our team are able to work around that by building the compilers ourselves, users who use our software might just use the system compiler and miss out on features or run into bugs because of that. There are things like Easybuild for that, but that isn’t necessarily maintained by the developers and despite the name not easy for users to setup and use.
Containerised apps use a lot more disk space than native apps, and until developers are forced to use shared runtimes they will be far less efficient. I agree that it is a work in progress, but for now my preference is for distro packages or something like the AUR.
Great information! I never realized that time would be saved all around. That would be great to concentrate on other things like sound, display, or network issues.
I think that there is another reason why Linux distros packaged apps. Disk space. Back in prior decades, disk space was sufficiently expensive and limited that it was important to have all applications run off a single suite of shared libraies for the commonly shared code. Having each major app ship with its own collection of libraries would have taken too much disk space. That worked, if there was an iron hand at the core of the overall system configuration, as with older commercial distributors, or as with Microsoft, Android and Apple now. Application developers know what they have to work with, and can target that base operating and shared library system. Unless your name was "Lotus", and your arch-enemy's name was "Gates", whose motto was (alledgely) "Windows doesn't ship until Lotus doesn't work", you were in good shape. That led to decades of mismatched libraries and applications and headaches for system configuration developers, but that was the necessary tradeoff, back in the day of widely shared libraries and smaller disks. Now the trade-off is different. Disks (and network bandwidth!) are sufficiently massive and cheap that it makes more sense to ship major applications with all their own copy and versions of libraries, except perhaps for one or a handful of core system libraries (e.g. libc). A similar argument could be made for the cost and size of main memory. Shared libraries for Unix at least were born inside Bell Labs, when RAM was too precious to reasonably fit multiple different variants and versions of the same library, statically linked into each running executable. Just as we are now migrating to snap and flatpak packaging for major apps, so also is static linking coming back into more common usage (e.g. in Zig), to reduce application loading and dynamic linking times and to reduce strange errors from depending on dynamically linked foreign shared libraries of uncertain vintage and version.
If you want rolling-release, Arch is pretty close to perfect, not gonna lie. It's also one of the distros which is easiest to support by developers because its package format is just writing a shell script and every user is able to fix those scripts in case they don't work.
snaps and flatpaks also NEED to make certain assumptions about the underlying system, lots of them make explicit calls to dbus services and it causes some wonderful crashes if your distro doesn't provide those by default. People call them "universal" but that's really only true if you're in a gnome or kde environment w/ systemd and a good list of running services. Another annoyance I found with them is since they have to be compiled to be generic a lot of optimizations and instruction support is turned off so they run significantly slower than their native counterparts.
@@zackbecker2117 I haven't packaged anything for NixOS yet though and packaging anything for Arch takes me about 20 minutes on average. Also it heavily depends on the package. I know certain software which is completely out of date in the NixOS packages.
@@zackbecker2117 They are certainly not as new from what I can see. The kernel for NixOS is (on the unstable branch) on 6.1.36 and 6.1.37 on the stable branch (which is weird) and on Arch on 6.4.1. And I understand that the NixOS kernel is the LTS kernel (which is also 6.1.37 on Arch), but I have seen the same thing for other packages as well. At the moment the difference isn't as big because they dropped their new version in May, but it will get bigger the longer ago their release was (I think they update every 6 months?), even on the unstable branch. I have used the Nix package manager on an arch system a while ago to try it out and their packages are not at all as new as the arch packages from what I can see. I am not saying one is better than the other in any way, I personally enjoy using arch but I think NixOS is a really cool concept and I can totally see why so many people love using it. But from an up-to-date/bleeding edge perspective, it's not even close. Arch packages are (generally?) newer, sometimes by a lot. The only thing I couldn't test is if the Arch packages are more bleeding edge (so higher version numbers), but not updated as quickly as far as bug fixed go, that might be what you were saying. If so, that might be true.
Linus Torvalds was very clear picking out what the original problem is. He very quickly called out the practice of core library developers like glibc to break ABI compatibility. This is the reason old codebases don't build on Linux, and old dynamically-linked binaries break, and the reason distros and package managers originated in the first place. The Linux kernel thus has a policy of, in all caps, "NEVER BREAK USERSPACE!" it's a real classic of computer science, back at it again, say hello to your old pal, Dependency Hell! Even the more recent approaches to generalize package management across distros don't solve this core issue. Even when the kernel ABI remains stable and static binaries (and any given set of libraries fully compatible with each other) always work on Linux regardless of kernel version, userspace often breaks itself, which forces software distribution networks to keep old versions of system libraries around, or keep rebuilding all packages against the new versions every time, and fixing them when they break. Most distros lock the library versions every release cycle to reduce complexity, and maintain packages for a series of specific, locked, sets of system library versions. What universal packaging formats do solve is library and software incompatibilities. Their ability to dynamically mount, unmount and isolate discrete sets for each major userspace library means that software will always see the libraries it expects to see, even if they could never coexist on the same system at the same time normally. As the sandbox is refined and xdg-desktop-portal matures, these apps will get better and better integrated across DEs. Well, Snaps and Flatpaks try to be smart about managing and deduplicating library sets where possible, at least. AppImages just bundle an entire distro's worth of system libs with every app, lack of redundancy be damned.
I agree with your points. It's kinda frustrating to read/hear about all the nice new features of Gnome and KDE apps (and other things) and then realize that it's taking at least a few months before I get access to those new versions because Ubuntu/Debian/Whatever-Distro doesn't ship the update. Using Flatpaks on my SteamDeck and my KDE Neon VM is great so far. There are still some hick-ups (my "favorite" being the poor CLI usage for Flatpaks), sure, but I'm sure that those will get ironed out over time. As those stumbling stones are eliminated piece-by-piece over time I'm using more Flatpak apps over time as well (falling back to system packages when stumbling upon such problem).
I have several complaints about Flatpak: 1. It takes up a lot of space. And there's a double problem here: a) Libraries are packaged into applications statically; b) Flatpak uses some very heavyweight platforms for applications. 2. The way applications are launched from the console is very inconvenient. I believe that all these problems can be solved, but until they are, I usually prefer the good old package formats to Flatpak.
You've made an excellent and very important point: How does the Linux community want to spend its limited resources? Packaging a bazillion old apps, or prioritizing new development, like improved Wayland support, multi-monitor support and better shell integration for Flatpak, etc. When I was a Windows user, I used portable apps for my most important programs. Since they didn't get tangled up with the OS, Windows instability issues became less of a problem. When I switched to Linux (Pop OS,) I thought I would have to do without the portable app concept, but I found almost all my favorite programs available in Flatpak format. The only drawback is uneven support for shell integration. I would love to see more developer time focused on improving Flatpak integration than repackaging & testing 50 or so duplicative clock, calendar, etc. etc. apps.
Almost all users and even most developers really have no clue the time and effort spent packaging software. Most devs don't even have any experience in packaging.
That's why I exclusively use flatpaks for everything. I use one app which has no flatpak, but they do have appimage. Currently on Linux Mint, but I'm waiting to hop to Vanilla OS 2.0 when it comes out. When Steam OS comes out, I will definitely try it and decide which is better for my use case. I used Silverblue/Kinoite, but it wasn't polished enough for me. That was some time ago, so it probably changed, but I don't feel the need to revisit them. I really like what Vanilla OS is doing with distrobox, atomic updates and What Steam OS is doing with nix packages. I would rather wait for one of those 2.
I will give a try to vanillaOS 2 too... Or just stick with debian testing as base os, and use all of my app through flatpack... And I'm slowly thinking to do the same with server, but with container and podman... Debian stable as baseOS with few tools, and everything else in container...
Distro side packaging is still gonna be very important for command line utils unless you wanna use snaps. It's gonna be same for WM users using something like dmenu I'd assume, but snaps would work fine. But yeah I don't see any issue with making stuff like libreoffice a flatpak/snap by default. I think appimages have a lot of potential if they were made as convenient to use as the other formats. I doubt a community distro like arch would ever shift away from packaging everything either in repos or as AURs, same with debian, so that model is not going anywhere.
And even more, imagine you could have drivers as snaps. Actually Ubuntu has this kind of work for Steam gamers, they offer better performance and compatibility.
This is unhinged but I think theoretically the best solution is for gnu/linux to become gnu/linux/nix and for all distros to become nix derivatives. Flatpaks have fundamental flaws like in system integration, and package size. They're great for some software but not everything. On the other hand if theoretically every distro used the nix package manager and repositories this will mean no more repackaging the same software, no more duplicated libraries, still having the ability to have multiple versions for whatever needs it, plus native speeds. This of course won't happen but I just had the realization that it might be the perfect theoretical solution
It's almost like automated compilation+packaging+testing doesn't exist, like we ain't using superior systems capable of that, or we lack the ppl who can make the scripts, or that the scripts can't be reused ...
I really like what Fedora does where they package the base system as its own normal repository, but many (most?) of the apps in the GNOME Software store are packaged as FEDORA Flatpaks. Flathub is helpful, but for security, stability, and choice I really hope that distributions don't start relying on it.
For Ubuntu, the list of supported distros is way longer, as you also have the flavors, each with multiple versions. It is a hell more work istead of snap or something else that simply works on all.
... Honestly, for most stuff, I just build from source now. Like Emacs, version 29 has pure GTK support so it can run on Wayland, but somehow it's not officially released yet so you've gotta grab it and build it. It's really not difficult. Slightly easier on Arch because someone made an AUR package that stays up to date with Emacs' main branch. IMO the problem isn't package managers but software that's so complex that no one wants to maintain packages. We need to better teach people how to do so and directly contribute to their OS.
I agree. Linux is feeling the pinch to find a way to pay the bills. Almost every distro is looking for efficiency. As for me, once I went to OpenSUSE Aeon, I was hooked. It's so fast and stable. Snappy. And, as a lazy man, I have loved how this is pretty much "set it and forget it." Nice.
Yesterday my wife had steam glitch out on her. She had steam as a linux mint package from the software library, and something broke when steam updated. Switching to the version from valve's website fixed the problem. Standards are a good thing, and one that I am more than happy to see. Everyone's life is easier.
Distro packaging probably made a lot more sense in a time when memory and disk space was more limited. Unless I'm mistaken, Flatpack, Snap, and AppImage all duplicate every library for each application installed.
You are wrong for flatpaks. At least the base packages are reused. For appimages it is true however. Those have other very serious issues, just use flatpaks... I can't speak for snaps as I don't like the proprietary parts of it.
The reason for this legacy model orf packaging is efficiency for the end user. With packaging formats like Apple, Microsoft, and Flatpak/Snaps/etc., you end up with each aapplication packaging all of its dependencies. So you wind up with as many different varriants of OpenSSL or GTK as you have applications. When you use the distro's legacy repos, you get exactly ONE copy of OpenSSL that is then shared with all apps in the system using it.. This not only saves disk space, but it saves memory since the Linux kernel will only load one copy of a shared library. That's why an old laptop can run Linux well, but be slow as hell running Windows.
there needs to be a universal solution that works for every type of app. flatpak doesn't respect CLI tools well enough. docker/podman are the only Real solutions for server-side apps. the bias is so heavy on desktop facing apps that it's painful i want to be wrong here, because i've tried to make using flatpak from a terminal work, but it's so clear the devs want you to use a .desktop file for everything. "no, long namespaced package names are good!" "no, you're weird if you want to run this app from a terminal!" "what do you mean you don't want to map an alias to every flatpak you install, by hand?" "why would you want to run a program just by calling its name?"
I completely understand why Flatpaks are desirable, but my biggest worries about them are the centralization around Flathub for app distribution, which of course could be mitigated if other "flatpak repos" pop up, and the fact that neglected Flatpaks could lead to security vulnerabilities in your system, since you can't just upgrade one vulnerable dependency and have it apply to all your Flatpaks like you can with native packages.
Nobody talks about the near perfection Homebrew (for both mac & linux) and Nix (this has 20 years of work behind it) package managers Homebrew was first released in 2009 and Nix in 2003 ( my b-year btw :) )
Immutable distribution like Fedora Silverblue I am currently sitting on, look like the way to solve it Edit: this video is exactly about it, lol. I thought it would be just a list of all flaws Linux Distros have
The only thing I would like, besides having packaged applications from a centralized store, is the ability to run those packaged application even if I get them "outside" of the store, a bit like app bundles for macOS, you can get them signed and notarized from the app store, but you can also just download it from a website and it will run anyway.
Just use Arch or a derivative of Arch (Manjaro, Garuda, etc) You won't have to worry about outdated stuff ever again and the AUR has basically ANYTHING that exists on the internet. There is a good reason why Steam OS chose Arch as their upstream base.
AUR isn’t official packages. They’re still maintained by users, they’re not something I would trust. And they are often broken, or unmaintained as well. They only solve the « old version » problem, they don’t solve the Linux distro model ;)
@@TheLinuxEXP Flatpaks and AppImages are equally maintained by random users. The only difference is that Flatpaks and AppImages are binaries so you have no idea what is inside them whereas in the AUR it's just source-code openly readable by anyone. If some shenanigans are going on in open source code, someone will notice it pretty quickly. Way more safe and trustworthy method.
I agree with everything in this video. One quick note: (around 3:20 you talk about "stable versions") "Stable" version and version stability are different things. For GUI apps its not really often the case, but a new update may change the behavior of the app in a way that breaks my workflow. Usually those are features for more advanced users, or those that use the CLI of a gui app to automate processes.
I cannot stress how important Flatpack is for normally windows based applications like Discord. However, they are buggy as hell for things that are made for Linux itself, it just works more efficiently to use packages.
@@TheLinuxEXP I've had issues with plasma integration not working with browsers under flatpak, I will say that flatpaks are the future, but I need that plasma integration
Hate to say it, but I use snap discord, although it does seem to work on my pc. I haven't gotten into flatpak yet other than gnome-builder, that worked well also. I prefer just using apt overall
Yes, I prefer the better control of having flat packs for a user. But there are times it's just nice to have everything ready and bundled for new users, especially those coming over from windows.
Flatpaks' size makes them completely impractical. As an extreme example of how insane it can sometimes get: FreeFileSync's deb package is 27MB. The flatpak is 1.4GB. No one is going to convince me that's a practical solution.
@@JorgeCastro - I checked just before this reply and at this very moment it's listed in the Linux Mint 21.1 software manager at 1.4GB. As you can imagine, I'm not even starting an install listed at 1.4GB when the deb weighs in at only 27MB, so I didn't test to see if that's the actual size.
No, packages used to come as tarballs and they were self configurable, meaning they examine the installed libs on your machine and compile accordingly. Shipping 100s of versions of the same lib installed on my machine just makes those packages a bloatware. GNU/Linux had a great advantage in it's packaging model, that the packages were really small and included just the code the developer contributed on top of a preset requisite. Now of course the current OS compatibility bugs would be fixed in time. Maybe in time those formats will become more resource aware and there will be attempts to share resources (become more modular). Until I see them minimizing the footprint of the installed binaries (executables or libs), I will stick to the old packaging formats (even if that means, I will need to compile and configure a package manually). Another point against Flatpaks will be the demise of a single UI/UX for the GNU/Linux OS. It is hard as it is to standardize the Linux Desktop right now with all the DE toolkits: GTK/QT/whatever... Now imagine including all those web based apps like Discord, VS Code, etc... Consistent native desktop environment will be dead forever. Moreover they might be driven to fit their app to the Mac OS/Windows standards, therefore making the job of Gnome/KDE, etc teams even harder to create a unified app ecosystem.
I just spent an hour removing all the default apps from Debian 12 so I could reinstall them from Flatpak. I prefer the OS without any apps so I can choose what to install myself.
I hope that Flatpak and Snap will add some option to not sandbox the app, like for example it annoys me a lot that I have to give the Steam Flatpak explicit permission to access my external hard drive and the installation directory of apps I want to be able to start through Steam.
@@fabiandrinksmilk6205 That's basically what I mean. It uses libraries it has packaged into its container (to prevent dependency hell) but has access to everything like a binary directly running on the host system.
I'm a Gentoo user, yesterday i recompiled audacity because of a flag change which i needed. Obscure compilation error, spended 10 minutes to solve it without success, so i installed the flatpak which is buggy, but works.
I use a mix of Flatpak & pkg, with a lean towards Flatpaks, and this is coming from an Arch user with quite a minimalist viewpoint. WM>DE 😂 There have been a few Flatpaks with errors, and probably a hell of a lot more pkgs. We shouldn't damn a technology due to a few bad experiences, but try to work towards making them better. Then let people decide which they prefer. As the historical user of more OSes than most, I've seen the ebb & flow of this technology set. Each new idea seems strange for a while, and will live or die on it's usefulness.
I think in the current situation we should not completely rely on any type of package. I just download the software from the official site and use the official package provided by the developer whether it's appimage, flatpack, deb or even snap
I think that Flatpak etc are the future for a lot of Applikations. But there is some software that I don't want in that Format, for example my primary Browser. That one has to start fast and not take up too much resources, so containerization destroys that. Also, a lot of things you said are not issues with all distros. e.g. The need to maintain multiple versions of packages for different releases of the distros goes away with a rolling release distro. TBH I never fully understood why things like Ubuntu ever made sense like that. I mean, for some users it's evidently nice enough, but as a dev I'd never be satisfied with having to support the lazy ass of these users, that at some point have to update anyways. Beyond a certain release duration the benefits that you get by not having to learn some short lived inconveniences is far outlived by the herculean task it is to learn all new systems all at the same time. So I'd rather get the changes piecemeal.
I am mixed on this as currently both snap and flatpak dont offer full integration and some things just dont work. Having the old standard package formats will still be needed for drivers and such too, thus why I dont see a point in using "immutable" flavors.
I am in favor of flatpaks, but I am cautious with centralized systems. We never know when flathub turns coat and does something against the community's interest *cought* red hat *cough* I will switch to using flatpak software when the edge cases I need are fixed
@@lordkordus8139 Yes, that is why I am not against it. But the biggest repo, flathub, could hinder the community if they really wanted. I know someone somewhere would lift another hub and continue. Snap is just garbage and I refuse to use it. Just hoping flathub does good gor the community!
You just spoke my mind. Also as a new to Linux user it always annoyed me that why do I need to use an older version of a graphical app rather than the latest stable version.
My biggest grip with flatpacks, snaps etc is the potential for copycat/unofficial apps in the app stores and the vetting of those apps. Windows, Android and Apple all have this problem. There needs to be some form of digital signature on the official apps and copycats should not be able to use same/similar names/icons.
I think there already is a verification system for Flathub that shows a checkmark under packages from developers themselves or developer approved maintainers.
This kind of vetting and digital signing already exists in the Snap Store. The caveat is that any 3rd party can package an application as a Snap. If the packager is provably identified, they get a "verified" flag, and if reputable or the original app developer, they get a "star" flag.
What's the difference to regular open source apps? Getting the sourcecode is usually a piece of cake, so copycats are just as easy now as they would be with flatpacks and other formats.
@@stephanhuebner4931 Copycats are more prevalent in app stores vs curated repos. I don't have a problem with someone creating their own version. I just want them to be marked as such in the app store and not be allowed to use deceptively similar icons/names.
Something that has _really_ bugged me about Linux package managers is that, going from one distro to another, you're going to get different versions of things. When I was first venturing into Linux as a daily driver, I needed packages like Maven, and I'd get told by Linux-shills "just apt install maven", except that I'd get a different version from apt than from dnf, so builds of the exact same commit would fail on my laptop but work on my desktop. It's only when we switched to using the Maven wrapper that we got around this problem... and in a sense, isn't that just an AppImage?
I couldn't disagree more. Sandboxing is the bane of my existence. I hate mobile apps because they are all sandboxed. Now we are bringing this problem to the desktop... what joy... Also, the latest stable version is not synonymous with the best version. Sometimes developers REMOVE features. Sometimes things break. Sometimes the "new feature" is now there are add banners everywhere and you have to endure a timed pop-up every 20 minutes to keep using the application. Sometimes I don't want to have to re-learn a new version of an app that I've used the way it was to do productive work for months or years and suddenly fined that somebody moved my cheese. Newer isn't always better.
people hate on flatpaks too much, I didn't use them until I heard you saying how great they are and now I'm hooked, no more weird graphical errors bugs and frequent crashes, I hope they switch to flatpaks exclusively and put that work toward making other things better
On my system what i often get is instability from flatpaks, crashes from nowhere. Still i do hope they not only get better but are the default for most Graphical Apps
Really excellent video and importsnt conversation, Nick! (as usual) A few observations: - FOSS world is source oriented and based, and has a philosophy of DIY. Sources are far more portable. Now, commercialized and consumer FOSS can't handle this (easily). Of course, commercialized and consumer FOSS is not an evil, quite the oposite, but it also have "consumerism" behaviours. Lotfs of different apps, lots of opinions, about the same things, instead of a common source based tool that gets updated and adopted based on needs and engineering. Again, not a bad thing, but a different thing. And certainly a challenge for the DIY and community tool building spirit of the original FOSS. - Biggest issue these days and for the next few decades is SBOM. Software Bill of Material. For security audits if not for compatibility and interop. packaging format do help solve this issue in 2 ways, as you've mentionned: focus on 1 object to audit, sign, distribute (time). and focus on 1 object binary (resources and interop). -The next evolution can be Nix and Guix: Minimal GNU/Linux offering just container tools and drivers, everything else runs as containers, docker images, virtual machines etc. This can be great for productivity tools, as they are going tobe isolated, better audited, self-contained and can free the market for their creators, and great for gaming and hardware intensive apps, and these could just request from the kernel full attention turning literally the machie into a console with a minimal viable set of OS and drivers to run. These ideals of isolation are literally why CPU protected mode and memory management units were invented, then virtualization instructions (in the 60s on IBM mainframes!). The greatest example of great engineering using this isolated computing are again IBM mainframes: they are still backward compatible decades back, they can be rebooted and updated and distributed without affecting the running software. I really hope that .deb format uses its weight and leverages guix, or at least nix.
Either you stop calling it distribution, or you should be fine with them putting all these packages up. If you want Linux with just Flatpak, you'll probably just want the OS. I however, would want the distribution. The All-in approach.
You do know that they’d still distribute everything else, right? And they’d distribute Flatpak or snaps instead of packages. That’s still a distribution, with choices, configurations, app selections and various subsystems. The packaging format doesn’t matter to what a distro does.
I'm certain that eventually someone will try to put the core system into a flatpak set. It will happen eventually since every standard that has some adoption on Linux gets a bunch of extra stuff shoved in that was never intended.
@@TheLinuxEXP I thought the way it was meant to work, was that flatpaks would be provided Windows style, as downloads on websites that anyone has their own reign over. That's what I thought you meant in the video. Sorry, if I misunderstood. At that point, in my mind, it ceased to be a distribution, and became, like Windows - just the OS, and we would go to various sources to get the flatpaks.
No, that’s backwards. Sure the user chooses what they run. But the developer then could say « I don’t support you, because you’re not using the latest version. »
I’m still looking for a way to build packages from source that is easy and straightforward. Like arch tries. On a newer and powerful machines it’s not an issue but older or just less powerful systems other options are welcome.
Nix or some new kind of declarative configuration is the future of Linux. It solves some of the thorniest problems related to reproducibility and configurability and is a holistic solution that makes even patching the kernel yourself or applying kernel patches, modules and configurations a breeze. It's also a pain in the ass to use in its current form, thus the adoption has been slow (although picking up lately) so focus should be on making declarative configuration more user friendly. Any "distro" could be offered as a custom configuration of Nix.
There are wrappers for Nix package manager, like Devbox. Basically allows to specify which packages you want to install in a small array in a JSON file. Is way more limited than Nix itself, but an option way more user-friendly for the average person.
@@TheLinuxEXP Nix could also exist one layer underneath and on top of it there's a more traditional user experience. In it's current form it's definitely too complex even for most hardcore users (I use it for work to build secure hardened OS), but the underlying idea is solid. When it becomes more mature and mainstream I think the complexity can be reduced a lot to something that's actually less complex to administer than a normal distribution.
@@user-rd5qf4oh6u I think the key could be this as in Nix exists one layer underneath the normal user experience and is configured through a more traditional interface.
@@TheLinuxEXP nix is the only one (beside guix) bringing configuration together with packaging. Flatpack/Snap/Appimage are not for kernels and system basics. I do not want X package formats and managers, I want one that works everywhere. Nix is not that complex for a consumer, maybe it just lacks a gui to be usable for everyone.
Stream any OS, desktop, or app to your browser, now with translations: kasmweb.com/docs/develop/developers/builds.html
15 years ago when I was using Ubuntu, I would never thought that there would be a format that would work on every distro, back then the closest thing to a "universal" package were .debs
I remember people would dream of an unified linux format for packages so that companies would be more open to the idea of providing linux support. I find it weird that nowadays there are people that are against distros moving to flatpaks by default.
People clamored for software to just use one format, and now that it does, they complain 😅
@@TheLinuxEXP People wanted (and still want) a universal format. The people who complain more about the fact that Flatpaks are sandboxed and each app ships with all the libraries it needs, leading to apps that take up a LOT of space. This model eliminates dependency hell (shudders) and each distro shipping its own version of packages. I guess the complainers just need to get a larger SSD :D
@@tejasraman6913 and ssds are cheap now.
@@tejasraman6913i mean SSD are like 40$ per TB here, that should not be a reason in 2023
@@gigalodon14Infinite disk space is never a thing across all systems . I just wasted over 1 TB because one upstream developer insists on making every niche feature mandatory and the dist repackaging didn't fix that .
One thing flatpak really needs to do is change their terminal format to just be the application’s name, not a long and obtuse URL. It would make it much more terminal-friendly; snap already works this way, so it is possible.
Oh yeah. The command line for Flatpak is annoying
yes!! that's my only complaint about flatpaks like why can't i use the name of the package
Very good point, though it does do it's best a guesstimating what you put in when installing.
It can be a bit annoying on occasion having to pull up a browser to find the link etc.
I think the URL is good for preventing name collisions. Maybe flatpak needs a way to query for them?
@@T1Oracle They have a way to query for them using the flatpak search command it is just annoying to have to use that.
I am all for a universal packaging system as long as it is not snaps since that is not fully open source.
You must like Windows, where every hacker can distribute any exe file. Every hacker can also distribute any flatpak.
@@bertnijhof5413 but who is forcing you to use a repo that doesnt have public build repos/build logs
@@ok-tr1nw Nobody forces Windows users either, but they get hacked like that.
@@bertnijhof5413 Yeah but the same can be said about .rpm and .deb packages.
@@bertnijhof5413 yeah, im only saying it since their argument only works on inexperienced users
With Gentoo *YOU* compile your package! That way it become your problem! Amazing! X)
I was going to say the same thing about FreeBSD ports. The thing against both of these is that general desktop users don't want to compile an application even if it's as simple as make and make install. The move to Universal packaging will really make distros have to work hard on their core value propositions to users.
Yeah, no thanks. I don’t want to spend 3 days compiling chromium
A particularly painful "niche" use case where Flatpaks bring headaches for the user is in IDE's. That sandboxing keeps them from (easily) finding the local installs of Java, or Python, or whatever else you happen to be developing for.
I have jetBrains IDEs in flatpak only because most of my apps are in docker containers, and I can pass the docker socket into flatpak using flatseal. If it wasn't the case, pacman -S all the way.
Yeah this was nearly always a headache for me although I kinda fixed it through giving access to distrobox containers to the ide. Code has a dedicated containers extension which is cool. That way I still have my dev env.
I had this problem with JetBrains IDEs in Flatpaks. Set up host-spawn and whatnot so I get a native-like experience but it was annoying so I switched to their Toolbox app which... made my desktop freeze each time I updated an IDE. Not sure what was up with that. So I might return to Flatpaks. They do have nice WSL integration so they cooould integrate with Flatpak too but oh well.
I really wish that Canonical would drop snaps and start supporting Flatpak instead, and any missing features they could easily help work on adding them.
There's something that irks me. Many years ago we had fully contained programs.
Then, we decided to use libraries, that is, use parts of other programs so we can focus on our stuff. And programs became more feature rich and small, since the libraries were separated. Also, neatly, the libraries can be SHARED by multiple programs. Maximum efficiency! Then, also, the libraries can receive updates like that critical vulnerability bugfix independently. How awesome is that ?
But then we got into the dependency hell. Which was mentioned in this video. Libraries don't have an immortal, immovable, unchanging API. So from one version to another, some apps might not be compatible anymore. This is when the "must have everything updated, must update every week OR ELSE" trend started to appear. And also the problematic older softwares that didn't receive updates anymore, basically got stuck to a specific version range of the libraries it uses.
Now here comes AppImages, Snaps and Flatpaks. They solve this by having a container, and inside having the exact libraries needed, no more, no less, and the versions that are supported by the app. Awesome, now everything works again.
But these have major downsides. Mainly because of the container. A lot of extra space and indirections and overhead. Modern CPUs are quite powerful and the normal user does quite little, so it's hard to notice in those cases. But the inefficiences are there. I'm not happy with this becoming the standard, to be frank.
But, if having this become accepted, I JUST HAVE TO ASK, why can't we simply have programs with all the dependencies compiled statically then ? It's still a duplication of libraries, but, at least you still have the native app, with its 100% uses cases working. It will still have the native speed. So the overhead is really minimal. And it will reduce a lot of problems that currently appear because of weird library versions configurations. I mean, you do get the "now it works in most cases" and "easier to debug because it's the same for all users" part, but without the container downsides. And, yes, I know that the container route has upsides too, mainly the sandboxing. Neat, but, frankly, for a desktop, a personal computer, I couldn't care less. Give me FOSS and I'll have my security by having good practices and not being stupid. I don't need to throw half of my computer performance and space by having security. I'm not running a server where some weirdo from the other part of the world can upload and run anything.
Alternatively, why is it so hard to have native apps and support for multiple libraries versions at once ? Like Guix does it. I like that solution more.
Statically-linked apps don't just use more disk space. They use more memory too. If you have three apps running that link against a shared library, there's only one copy of that shared library's code mapped into memory. If they were statically linked, you'd have three copies of the library. You'd very quickly complain about the incredible bloat.
Shared libraries do include versions and it is possible in theory for multiple library versions to coexist peacefully on a system. However, this requires careful planning on the part of the library developer. The standard C library is well-maintained in this regard; other libraries... not so much.
@@dfs-comedy Yeah, true. I'd hope that the extra RAM requirements won't be big, but I'd complain nevertheless :D
Still, when compared with flatpaks and such, I don't think it's worse. From what I know, they don't use shared libraries.
Regarding versions, is it just from the library developer, or is it from the developers who use it too ? I mean, I don't know how this link is defined, how easily is to set/overwrite the version/library file ?
@@Winnetou17 I'm not 100% sure how Flatpaks work. I believe Appimages package their own copies of shared libraries, so multiple processes in an Appimage can share libraries, but not with anything outside the Appimage.
Library versioning is controlled by the author of the library. Shared libraries have a soname that specifies the version, and there are even ways to keep multiple different versions of an API within the same shared library using ELF symbol versioning. There is absolutely *no* excuse for DLL Hell on Linux.
Two corrections. Firstly, before distros, we would install software by downloading a source tarball with ftp and then work out how to compile and install it. Secondly, while it's true that rpm and deb formats are basically equivalent in functionality, the main difference between packages for each distro is the way the software gets set up, not just the versions available.
I would also like to argue with the idea that in general users want to use the latest stable version of all their software. If I have a workflow that works for me, I don't want to have that change. I really really appreciate stability of user interface because computers are a means to an end, not the end themselves. I also know that programmers don't go to very much effort to follow things like the FHS or packaging their software to be nicely configured and running out of the box, or caring to make sure their software plays well with other software you might have running, or care about making sure to monitor security updates in the libraries used. This is the main reason to use a distro and why container-based installers and things like NixOS are a really bad idea. These encourage a "works for me" development model, with little respect for the end user's preferences.
I would argue there are differences in users and differences in use cases. Some users prefer rolling-release while others prefer stable releases. There's also a difference in each use case. For example when you want to use/try the latest feature of some application, you would pick a rolling-release of it. However when you just want it to work as every day before in the last weeks to get things done, you would pick a stable release.
I don't think one can replace the other. I use four different distros with different package policies at the moment and they just work as intended. I don't see why everybody would want to have rolling-release all the time. It might completely break your workflow some day.
what pdr wrote.
Plus packaging well written SW is not that hard, if some package is very difficult to build or requires frequent changes to package building script, it's usually due to developer of the SW.
Plus debian packages have usually also their source counterpart, so you can build the binary yourself, which may be handy if you want to patch the code yourself a bit or to build for unsupported HW platform or just verify the packager integrity and check if the binary is really matching the source code. I have no idea how much snaps/flatpaks care about providing also build recipy to rebuild them yourself. But without the source code and ability to patch the SW yourself the stuff will deteriorate over years to the point where you will be in binary-only distribution world unable to verify/patch anything without actually reverse engineering the binary itself.
I’d argue NixOs is the path businesses would take if linux was used in the workplace. Managing hundreds to thousands of computers is monotonous and usually done with scripting, but still requires petty user initial setup. NixOs allows the it department to buy the computer, pull the config file, insert specific user, run nix build switch. Done. No scripting, just done.
@@emptydata-xf7ps Can't say I agree. For production systems, it's important to know what libraries you use to ensure you aren't using anything with known vulnerabilities. Nix (and for that matter, containerised deployment systems) makes this very difficult. Using a stable distro in combination with a good CM system provides security, compliance and agility with the greatest of ease. Very little custom scripting is needed, maybe only when it's required to package internal software.
@@pdr. yea I can agree with that. Didn’t think about vulnerability in older dependencies.
As a Fedora user, I would embrace having apps like Firefox, LibreOffice and Thunderbird shipped as Flatpaks. I would only really be against such a move if I got Snaps instead of Flatpaks.
i would hate if fedora dropped the Firefox rpm. i have bound firefox to a key shortcut and when another Firefox window is open the shortcut takes a couple of seconds with flatpak but it's instant with the rpms
Viceversa for others. But as long as flatpacks are limited by design (unlike snaps), they simply cannot distribute what a snap can (drivers for instance), so they will never be a full replacement, .rpm or so will need to stay for some types of apps. This is not ideal when you go on that path.
I once installed Firefox as flatpak and I could not import my bookmarks from chrome or other browsers, on apps like Steam I could´nt even move my games to another partition only in it´s sandbox..
But snaps are better than flatpak.
it's the same crap, snaps and flataks
I think there's a security aspect of it which is sometimes forgotten: Who do you trust? There are some points to be made:
1. Trusting 1 vs MANY entities:
When you choose a linux distro, you are effectively trusting the organization and maintainers behind them (even if you didn't even realize). They are who build you distribution, compiles your software, chose what goes and what does not go in the repos. Be it a company (like RedHat or Canonical) or a community (like Debian or Arch), you rely your trust in them. But now think about when using this universal packages available to every distro and more, submitted and compiled by the developer - which is the suggestion this video makes (correct me if I'm wrong). Now you don't have someone to trust and effectively you need to trust every single developer that you download a software from. And there are A LOT. Instead of trusting 1 (most of the time) big, well known project, you need to trust many unknown (to you maybe) developers. I am not saying that small, independent or unknown developers are a bad thing, actually I am one of those, but I doubt you are familiar with every developer that wrote all your applications.
But now you might ask: "Aren't I already trusting the developer, I'm using his code, what else to trust?" or "It has a lot of eyes in the source code, its fine". But is it? Thats the second implication.
2. Source Code != Binaries (packages)
Usually you would be right in those questions, but in rare (but existing) scenarios there is a catch. There is an open source code. There is a binary. What assures you that the binary is from the public available unmodified code? What is stopping a malicious developer to apply a patch adding something undesirable - be it malware, tracking, telemetry, whatever - or even just a third party (closed source) dependency without the user consent? Nothing. Actually, you will only be sure if you compile it yourself. Welcome to source based distros like Gentoo. But most people don't want that hassle like me, and there is where the trust enters the play. If you don't want to do it, trust somebody else. The previous argument discoursed about who to trust.
3. The linux security and malware-free fame:
There is a fame where linux based OSes are more secure and do not have virus. While this is not entirely true, it can be said it actually is more safe than other OSes. There are many reasons for that, but the obvious one, and probably the leading factor, is that it has a small market share, so bad actors develop malware to Windows (and sometimes MacOS, etc) instead. But there is another reason: the way users behave in these operating system. Windows users typically download software from the internet, browse, search, download then click-click install. In comparison linux users typically installs software from the distro's repos, be it using the command-line or a graphical application. This lead to the obvious security difference and concern. Downloading from untrusted sources on the internet is a BIG potential on having something going sideways. Now, getting your software from a well-known trusted organization is fairly safe and has gone well in many decades (can't be said about windows). But here is the deal, how different is the said Windows way of downloading programs than downloading an app in which (in this case study) a unknown developer packaged? How different is it than copying and pasting a shell command from stack overflow into your terminal ("RED ALERT DO NOT DO IT", security linux experts, i think). Of course it has its differences, but I cannot not see the similarities.
4. But Flakpak is secure, it is sandboxed by default.
Yes! Thats a great thing. In fact, it does stop many possible "attack vectors", but not all problems are solved. What about privacy? What about telemetry? All the examples in the 'Source Code != Binaries' can be given here. So yes, it is sandboxed, but it is not a silver bullet.
5. WoW, what a DRAMA. This would never happen!
Do you think so? There have been cases of Trojans in linux. There is existing ransomwares for linux. There has even been a case of injecting security bugs in the linux kernel on purpose. Yes, it is VERY RARE, but not nonexistent.
---
Now that I have played the devils advocate, I should say that I enjoyed the video a lot and haven't thought about this matter in this point of view. Very interesting. I personally would say that I am 50% 50% on specific distro packaging and universal packages. Just wanted to point out somethings to think when pondering this.
flatpak """sandboxing""" literally doesn't exist by default because everything has filesystem=home privelege, which makes escaping the sandbox trivial. They'd be better off completely removing that functionality altogether and focusing on giving operating systems ways to more tightly integrate
Totally agree. I know a similar situation about the core.js and faker.js. The author deleted the original repo on the Github, which was not a big deal, but then he submitted a version with vulnerability behavior to npm, many users were affected. If it’s a regular package in the official repo, it won’t happen since the maintainer will do some test about the new upstream version. Another drawback of it is the mutilarch support. Since it’s packaging by the author himself,there is a high chance that he or she will only package for the mainstream architecture even if the software itself doesn't require any architecture-specific cpu command. For example, now Debian community is trying to support RISC-V, but many developers don’t have a RISC-V computer. In fact, they may don‘t know the architecture itself! So in conclusion, no silver bullet, we don’t have one universal solution to all problems.
I never use it, but "I use arch, btw" has never been more fitting. 😂
Arch is really good ecosystem
I don't know why every package manager out there keeps ignoring that portage (or even ports) exists, it's had these problems solved FOREVER with package slotting (when you need multiple versions of the same lib), ability to pull in newer than supported versions automatically, etc.
Microsoft/ Google are also somewhat doing similar things like moving parts of OS to be a store "app" which can be updated separately using the store.
Especially helpful in Android where major updates were made by the OEM and latest security fixes for small things wouldn't reach the users. Now most of android components can be updated for way long after the device is discontinued.
What Google is doing with that is using the non-sandbox package manager for some system apps, including some where Google updates are the wrong thing to install, such as apps that decide how much of your calls and text messages go through Google servers .
Which is kind-of how FreeBSD has always done things. The base image of the operating system and the ports collection are separate, and a lot of FreeBSD variants have their own separate base image, but use the same ports collection.
Windows just launched its own Package Manager though - which makes it easier to administrate apps (updates and installation) through the Terminal there, too.
So, if you think about ease-of-use for Enterprises, that makes sense, too. As long as Flatpack also supports easy Updates via the Command Line, it might be good *enough* for most users.
The only disadvantage of Flatpack-Apps I found when researching the topic and looking at people who did some Benchmarks for performance of a couple of Apps on Flatpack, native Distro-Packs and App-Images, the performance was usually a bit better on native Installations and some weirdly even on App-Images, but not on FlatPacks.
I suspect it has to do with the Libraries used by the apps and how they perform running in the sandboxed environments instead of the native system ones. But that's just a guess on my part, which might also be wrong entirely.
Nevertheless, there are pros to running apps natively - even though they might not be as "secure" then. But Linux as an Operating System is relatively hard to compromise thanks to how the whole system/foundation is designed - why many servers run so reliably with native code, too...
Though, I do see the more "comfort" Flatpack offers in addition to the security for personal use. If I remember correctly, Ubuntu designed the Snaps to be used on Servers, too - and it's not exactly been working so well?
But, all in all - I think we'll need to see how things develop - meaning: how developers prioritize working out the issues with either source...
@@BulukEtznab As long as the app is not very intensive I don't think the performance will matter much.
It saves us from compatibility mismatch, like most windows apps package mostly all of the required libraries to reduce dll hell.
@@johndododoe1411 I absolutely love google for those things. I can't tell you how stupid it is to hear that iPhones have there browsers version locked to the OS. Things should be easier to updated, not harder.
If I wanted a rolling distro, I'd go with Arch. I like having the stability of packages being locked to a release.
That's the stupidest take I've ever heard. You don't need outdated packages unless you are running a server. You've been brainwashed if you think Arch is not stable or it breaks frequently.
@@xAffan stability here means packages and programs not changing. If i like the functionality of a program and it gets changed, it becomes ridiculously annoying to manually have to lock versions down.
And I've been an arch user for years. Even with using ARM (since renamed) you're completely out of luck if you are using AUR packages
@@veruthas There are programs that can downgrade packages on Arch Linux. Anyways, you do need the latest functionality if you're using Linux as a home desktop.
@@xAffan absolutely not, like i literally said in my comment, it is frustrating and annoying to figure out which packages need to be locked down vs them being all locked down to the distro version, especially when needing to reinstall.
And you absolutely do not need the latest functionality on a home desktop. Not sure where you got that from. If my OS allows me to do the work i need to, releasing new ones doesnt magically break functionality if the packages are being maintained until a certain date (and even then it will usually still work)
I get it, you really like Arch, but that is irrelevant to this conversation.
@@veruthas It's incredibly stupid to use outdated software. I get it you're one of the people using office 2007 on windows 11 just because "it works". But the vast majority of the people want new features and any improvements that come with it.
Ideally, the OS model should look something like this (via GUI):
- Pick a deployment model: reproducable or "traditional"
- Pick your kernel: LTS or latest.
- Pick your persistance model: atomic or dynamic
- Pick your pacakge delivery mechanism...I tend to think traditional RPM/DEB/TGZ methods are fine for the OS. User-facing apps probably should be using something else. I'm not conviced flatpak (which I like) or AppImage (as typically deployed, there are FOSS projects that assist and make this more viable) are good answers. RPM was designed to accommodate proprietary software license agreements (so why was anyone surprised by RedHat's move?) so I tend to steer away OS's that use it by default. TGZ dependency resolution can be a little unreliable and lends itself to more technically savvy users. To each there own.
- Pick your filesystem; the usual candidates...
- Pick your interface: tty, i3, Plasma, etc
Now do your thing, whatever that is. This is effectively what the Linux distribution model achieves but in a more chaotic way. Cathedral vs Bazaar. Community based systems tend to be organic and appear chaotic. They achieve organization through emergence. This becomes less sustainable (more energy intensive) the larger and more complex an organization/organism becomes. Either size or complexity have to give. E.g. Fungal network: Huge, but simple (they have few options to survive)
For each, there ought to be an "I don't care" option which prioritizes end-user usability, flexibility and (where reasonable) stability. E.g. Traditional, LTS kernel, atomic (if well managed), DEB + ?, Ext4, GNOME Shell or Plasma Desktop, and you're off to the races.
This approach allows all the collective developers to act as a collective rather than wasting resources being semi-competitive. This lowers monetary cost and effort, precious resources in the FOSS community.
If that model doesn't work for you, you're probably a Linux nerd and Arch, Gentoo or LSF would suite you better. Go ham!
From a business use case it completely makes sense why an application version would get pinned, and the latest stable would not be used. As applications update, dependencies and behavior can change. This needs to be tested, documented, and the deployment managed. Ugh. And Nix is not (quite) ready for large scale corporate deployments; it can be done, but requires more work than one would initially imagine.
SUSE has a new kind of persistence model called transacional, you can edit /etc fitles wihtout unlocking the root, and make any kind of installations that survive the update
Sorry OSS Nazi, but you should not be against distributing Propietary software. PD: SUSE also does it.
@@friedrichhayek4862 can you maybe not use “nazi” in this way? It kinda downplays what nazis did, if the person is not making a genocide just don’t
@@MaryamMaqdisi Nazi, Stalinism, Maoist, Social Democrat all of the are the same
@@friedrichhayek4862 The nazi's were fascists, and social democrats are just those who want reform of capitalism, as for stalinism or maoism I don't know much about the specifics of those ideologies to say much about them other than they were ideologies that emerged under the communist movement, and communism is not fascist since by its very nature the idea is organizing the economy under a democratic system and not a more authoritarian one like capitalism.
thing is: if there's a vetted package for, like, debian or fedora (I almost said redhat), you can assume it's working (as in, "it did for the past 20+ years"): it might not be the most up to date, but it does it's job 24/7 in tandem with all the other stuff you've got running. plug upcoming security holes as you go.
going flat or snap, you're back on the random train again, getting the "(almost) latest and greatest" potentially half-baked things thrown your way - that might very well work on the newest pop!os or manjaro -- or not. (while eating away at your disk space: it might not bother you at home, or if you've got petabytes of storage at work, but: renting a cheap dev VPS, those 50-80gb of allocated storage melt quickly if every app installs a copy of all their required libraries, instead of making sure to link the existing ones. every time. going the microsoft way, basically.)
tl,dr: IMHO, both routes are quite essential: the stable base, and access to the 'cutting edge', providing feedback to the devs. trying to force-merge them, I'd consider a major step back...
I like the hybrid solution. Native distro repositories for core applications and Flatpaks/AppImages for bigger and more specific software. Universal packages are a key element to bring formerly "expert" distros to broader audiences, Debian 12 wouldn't be as good without them for instance. I recently switched from "normal" Mint to LMDE and it was totally painless thanks to Flatpaks and AppImages. These two formats can still be perfected (size and performance for Flatpaks, and a better update/install management system for AppImages) but they're already a massive leap forward.
Flatpak and co. are a really weird way to fix the problem though. They are not only universal, they are also portable (which we don't need) and sandboxed (which has advantages, but should not be the default). Portability makes them bloated in size, sandboxing has practical issues. I've not used Flatpaks and co enough to speak on performance. Nix, to me, is the concept to the actual solution to the universal package problem. It eliminates dependency hell, it works on every Linux system (plus on Mac OS), but stays optimised (deduped dependencies) and native. Flatpak and co. are the solution to different problem.
I definitely prefer the flatpaks and snaps as a more streamlined experience makes it easier for users and also as you stated it makes it easier for devs to develop and free time to improve other things. I also feel it could make it more attractive to even mainstream companies to provide Linux support as they could also target every operating system in the Linux sphere
As soon as FirefoxPWA add-on works on flatpak, I won't need the deb built personally. Flatpak has been great and something like 1/3 of all my packages are flatpak now
That's why I just use Brave. It has PWA support natively, it completely FOSS, and will continue to have Manifest v2 support even when Google will attempt to kill it.
I’m a fan of the concept of universal packages but they’re still too hacky compared to native packages, I had to copy and paste a command to tell flatpaks to use my themes for example (when it should ideally be configured to automatically detect it from the get go), some apps have unwanted behaviors (such as title bars that are not present on native packages or opening multiple instances when it makes no sense, example of the latter: Slack). And of course the sandboxing unfortunately gets in the way of the normal use of the app (ex: code editors / IDEs).
I use flatpaks and AppImages daily because they’re useful but there’s a way to go until they behave closer to what we expect from native packages. I just want to be lazy and enjoy my system without much thought lol.
Themes are a thing from the past. Don't use themes, keep defaults. Your life will be easier.
It's not 'lazy' though. It's called using your software in a way that keeps your mental health stable. Linux is becoming more complicated, demanding more attention more often and hence elevating stress levels for more people. You come home from a hard, grueling 12 hour shift at your job and the LAST THING you need is more stress when you just need your PC to work! 'well it's not going to change. Deal with it!'. Yeah, well some people can't deal with it, period. Our technology has failed us.
@@tomaszgasior772 Themes are great (one of the pros of linux). Defaults are boring.
You can open a bug report for that particular flatpak. Also there is flatseal to manage flatpak permissions. I think in flatpak setup section of every distro, they should also include a section about flatseal at the end.
@@summerishere2868 yeah. What's this arguement, "I want to do this" "well, it's old school. Don't do it anymore"
This is why I like the *BSD model. The ports/packages come from the developers, not the *BSD team. They're untouched. The installation process is the same for every port / pkg.
That’s really good, yeah!
that is nice, but impossible to deal with on a large scale due to version mismatches/dependency conflicts, unless you static-link everything
I might take another look at the BSD's, it got me interessed in some parts
Also *BSD is clean, everything is at its place, nothing is throw in one directory and good luck to find what you search when you're not sure of what you need to find. With *BSD, you always find, within minutes alone, not hours with some internet help.
That on Linux is called Gentoo
I think multi library version support is something that Linux has needed for a long time.
I think having traditional repositories is still a good idea, and I wouldn't want them to go away altogether for things like system configuration utilities and things that sit 'beneath' the desktop. For that stuff, having the distro have overall control of what gets audited, tested and shipped makes sense. But for anything on the desktop? Yeah, Flatpak all the way. I use Flatpaks for near enough everything and will in a lot of cases not even use software that _doesn't_ come as a Flatpak. It's less work for distro maintainers, less work for developers and less hassle for me as an end user. It's a win-win-win.
I agree. Flatpak is probably the good ending for graphical apps. However, for system tools and things like that, I think distros should and almost have to keep packaging them. Something just feels off about installing a window manager with flatpak.
System tools should be GUI apps too, so no problem here.
Things on the level of wm, will probably stay as distro packages, but there are also other terminal programs (for programming for example), I only know nix as an option (installable on basically any distro, no dependency hell, can be relatively simple, but also has expert uses).
Aah
Dumbing down technology
I see
You probably don't know the horrors of having 100s of toggle switches, radio buttons, check boxes and drop down menus
Almost every system application is better off on the cli with basic settings available on some qt or gtk gui
@@doragonmeido I just know that using the regedit app is way easier than searching things on config files and using 30 programs in the terminal
@@talkysassis huh?
It's pretty much universal that all the system config files are on /etc/
all the user configs are either in your home directory or in the .config directory in the home, just use an editor of choice and edit them while referring the wiki or docs, what's the difficulty?
It should be the norm for system application and it is
It's fine for user applications to have gui settings and stuffs while also providing a config file for backup purpose.
And also using too much gui reduces my reading comprehension, well that's my specific reason
I can't believe I still can't give arguments when starting a Flatpak application.
This!
Having a bajillion packages and package repos is messy BUT it also gets rid of single point of failure.
The same point of error is excluded as soon as there's a team that hosts their own flatpak remote (no such possibility for snap). For example the fedora mirrors or some less "rolling release" more "stable" flatpak remote for people who want more stability even in flatpak
Correct, it creates MULTIPLE points of failure 😁
Flatpack FTW!!! 📦📦
The GOAT
Period. Just that.
I used to see distro repackaging as critical to providing the "many eyes" to find bugs and independent verification you need to trust open source systems. However, I think Heartbleed showed the model isn't working in this respect. In rare cases distros might even make things worse like debian did in 2006 by "fixing" uninitialized data and weakening the PRNG seed for OpenSSL. I think funding independent verification projects is a better strategy and it seems like log4j has gotten some moving that direction.
It's no so simple as you said. Flatpak, AppImage and similar packages formats take a lot more disk space and more ram due to duplication of libraries and resources, and in most cases, original developers are not so quick to apply security patches to all used libraries (understandble because theyt are focused on their software). Only a distro or some big project (Firefox, LibreOffice, ecc..) can have a security team that can constantly follow security risk updates.
So, if you want a stable and secure system these solutions are not so great. Probably this tecnology have more sense applied to rolling distros where users are more "adventurous"... :)
There is GNU Guix which does both well.
Sadly it updates kinda slowly and currently lacks software in repositories (20k packages vs 90k for Debian for example).
@@kacperrutkowski6350there is always NixOS
@@zackbecker2117 which isn't user friendly enough to became a new industry standard imo.
It might be a top 'elite' distro just like Arch is/was, but I don't see it as a good choice for beginners and casual PC users.
Perfectly good universal package management systems existed long before Flatpak and Snap, for example Autopackage and Zero Install, but they never got any attention from developers. I was partial to Zero Install and used it to install Rox Filer back in the day. One nice thing about it is that you don't need root privileges to install software.
I love source based distros in this regard.
1. Easier to maintain
2. Programs are built for whatever version x, y and z you have
The only app I currently use that I cannot replace with it's flatpack is VSCodium, I loose some features due to the sandboxing
(But I would really like to be able to switch to the flatpack at some point, it would remove the need to add the VSCodium Repo)
What kind of features do you lose because of sandboxing?
@@sweetmelon3365 I'm guessing he needs to call an external binary, I remember not been able to call pdflatex in the flatpak version. Come to think of it you probably also cannot call any compiler or interpreter or binary you have compiled either, so defeats the point for an ide, can only edit configs haha.
@@sweetmelon3365 maybe I just don't know how to do, but a few examples are :
- I use zsh as my shell but in the VSCodium terminal when using the flatpack it doesn't let me use zsh
- I work sometimes in Go and have it installed, but flatpack VSCodium doesn't detect it.
There might be other ones but I haven't pushed my tests further once I ran into those issues.
THere is no real sandboxing is flatpaks, they are as insecure as running the app directly outside of a flatpak.
@@zapyvr If you need to run commands or tools from outside the sandbox, then you need (for example) set "flatpak-spawn --host zsh" instead of just "zsh". Iirc that what is written in the readme file that opens at the first startup.
I am all for Flatpak taking over the desktop application space, which it hopefully will (outside of Ubuntu), as long as we have applications like Flatseal that allow us to also manage permissions, levels of sandboxing, and theming within the app. I think the ideal future for the Linux desktop has all distros using Flatpak for all the desktop packages, with the core packages, the lower-level components of major desktops (like Mutter and gnome-shell for GNOME) and packages used by Tiling users, being the only programs still packaged as native packages. As well as that, this ideal future I envision will have people split between regular and immutable systems and everyone will use Wayland, including Tiling users who would have switched to River, Hyprland, DWL, Sway, and others that might emerge in the future. In this future, Wayland has taken over from X11, and Flatpak has taken over desktop packaging from native package formats. I can't wait for such a future, and genuinely hope and believe that it will happen within the next 5-10 years.
The problem I have with many of the more "modern" systems like Snap, Flatpak and Wayland is that they are functional regressions. Because of the increased isolation, many advanced features just break. Wayland was supposed to simplify things, instead it just made everything an unholy API mess with ugly workarounds for e.g. screensharing or injecting keystrokes/mouse for automation.
I blame the devs, who long ago stopped caring about the user experience. Which is why Linux will never be a viable desktop OS. It's for geeks with way too much time on their hands, and for servers where security is up to the admins - not dictated by moron devs.
@@wombatdk Unskippable permission systems are the worst. A real-life example: the camera app on my Android phone sometimes says «camera unavailable, locked by another app» for no reason and I can't do anything about it.
As for the desktop viability - I'm a geek and I would much prefer a program which does stupid stuff but can be reconfigured to not do it than one that I would have to rewrite to act properly. I just don't wanna bother with stuff like the aforementioned API cluster of Wayland (maybe it will get unified and improved in the future?).
@@formbi I'm guessing you meant "unskippable permission systems"? Other than that, totally agreed. Considering the history of Linux I have a hunch that unification isn't in Waylands future. The best we can hope for is, I think, that one will become dominant and the rest will die off.
@@wombatdk yes, I fixed the comment now
@@formbi Typoese, the official language of the Interwubz :)
I prefer deb packages over snap or flatpak
I have had nothing but issues with Flatpaks for most of the applications I use, there are theme issues, certain features are broken (such as notifications). Personally I have had less issues with Linux 5 years ago, compared to now with these universal package managers, and other ways in which Linux developers are trying to reinvent the wheel. So for me Debian, Arch, and NixOS with no Flatpaks are the distros which are actually usable for me on a daily basis without any issues.
Personally I think that Nix is the universal package manager that just works, but is often overlooked. The new user experience must also be something that is just confusing before you just had to learn the package manager that came with the distro, now there is the traditional package manager, flatpaks, snaps, etc. which all work in different ways and one method does not work for all situations (no cli flatpaks) , which I believe is something that can put a new user off from Linux all together, this does more harm than possible good.
The thing I‘m missing the most is things like compilers and other libraries. Ubuntu for example does set some weird default compiler flags both on GCC and LLVM and while we in our team are able to work around that by building the compilers ourselves, users who use our software might just use the system compiler and miss out on features or run into bugs because of that. There are things like Easybuild for that, but that isn’t necessarily maintained by the developers and despite the name not easy for users to setup and use.
What weird flags are you referring to?
Containerised apps use a lot more disk space than native apps, and until developers are forced to use shared runtimes they will be far less efficient. I agree that it is a work in progress, but for now my preference is for distro packages or something like the AUR.
Great information! I never realized that time would be saved all around. That would be great to concentrate on other things like sound, display, or network issues.
I think that there is another reason why Linux distros packaged apps.
Disk space.
Back in prior decades, disk space was sufficiently expensive and limited that it was important to have all applications run off a single suite of shared libraies for the commonly shared code. Having each major app ship with its own collection of libraries would have taken too much disk space.
That worked, if there was an iron hand at the core of the overall system configuration, as with older commercial distributors, or as with Microsoft, Android and Apple now. Application developers know what they have to work with, and can target that base operating and shared library system. Unless your name was "Lotus", and your arch-enemy's name was "Gates", whose motto was (alledgely) "Windows doesn't ship until Lotus doesn't work", you were in good shape.
That led to decades of mismatched libraries and applications and headaches for system configuration developers, but that was the necessary tradeoff, back in the day of widely shared libraries and smaller disks.
Now the trade-off is different. Disks (and network bandwidth!) are sufficiently massive and cheap that it makes more sense to ship major applications with all their own copy and versions of libraries, except perhaps for one or a handful of core system libraries (e.g. libc).
A similar argument could be made for the cost and size of main memory. Shared libraries for Unix at least were born inside Bell Labs, when RAM was too precious to reasonably fit multiple different variants and versions of the same library, statically linked into each running executable. Just as we are now migrating to snap and flatpak packaging for major apps, so also is static linking coming back into more common usage (e.g. in Zig), to reduce application loading and dynamic linking times and to reduce strange errors from depending on dynamically linked foreign shared libraries of uncertain vintage and version.
I don't really like snaps or flatpaks, which are space-hogs. I am totally happy with my arch linux and its wonderful and fast packaging tools
If you want rolling-release, Arch is pretty close to perfect, not gonna lie. It's also one of the distros which is easiest to support by developers because its package format is just writing a shell script and every user is able to fix those scripts in case they don't work.
snaps and flatpaks also NEED to make certain assumptions about the underlying system, lots of them make explicit calls to dbus services and it causes some wonderful crashes if your distro doesn't provide those by default. People call them "universal" but that's really only true if you're in a gnome or kde environment w/ systemd and a good list of running services.
Another annoyance I found with them is since they have to be compiled to be generic a lot of optimizations and instruction support is turned off so they run significantly slower than their native counterparts.
@@TheJackiMonsterI would argue NixOS is better than Arch, simply due to the fact that packages tend to be more up to date
@@zackbecker2117 I haven't packaged anything for NixOS yet though and packaging anything for Arch takes me about 20 minutes on average.
Also it heavily depends on the package. I know certain software which is completely out of date in the NixOS packages.
@@zackbecker2117
They are certainly not as new from what I can see. The kernel for NixOS is (on the unstable branch) on 6.1.36 and 6.1.37 on the stable branch (which is weird) and on Arch on 6.4.1. And I understand that the NixOS kernel is the LTS kernel (which is also 6.1.37 on Arch), but I have seen the same thing for other packages as well. At the moment the difference isn't as big because they dropped their new version in May, but it will get bigger the longer ago their release was (I think they update every 6 months?), even on the unstable branch.
I have used the Nix package manager on an arch system a while ago to try it out and their packages are not at all as new as the arch packages from what I can see. I am not saying one is better than the other in any way, I personally enjoy using arch but I think NixOS is a really cool concept and I can totally see why so many people love using it. But from an up-to-date/bleeding edge perspective, it's not even close. Arch packages are (generally?) newer, sometimes by a lot. The only thing I couldn't test is if the Arch packages are more bleeding edge (so higher version numbers), but not updated as quickly as far as bug fixed go, that might be what you were saying. If so, that might be true.
Linus Torvalds was very clear picking out what the original problem is. He very quickly called out the practice of core library developers like glibc to break ABI compatibility. This is the reason old codebases don't build on Linux, and old dynamically-linked binaries break, and the reason distros and package managers originated in the first place. The Linux kernel thus has a policy of, in all caps, "NEVER BREAK USERSPACE!"
it's a real classic of computer science, back at it again, say hello to your old pal, Dependency Hell!
Even the more recent approaches to generalize package management across distros don't solve this core issue. Even when the kernel ABI remains stable and static binaries (and any given set of libraries fully compatible with each other) always work on Linux regardless of kernel version, userspace often breaks itself, which forces software distribution networks to keep old versions of system libraries around, or keep rebuilding all packages against the new versions every time, and fixing them when they break. Most distros lock the library versions every release cycle to reduce complexity, and maintain packages for a series of specific, locked, sets of system library versions.
What universal packaging formats do solve is library and software incompatibilities. Their ability to dynamically mount, unmount and isolate discrete sets for each major userspace library means that software will always see the libraries it expects to see, even if they could never coexist on the same system at the same time normally. As the sandbox is refined and xdg-desktop-portal matures, these apps will get better and better integrated across DEs.
Well, Snaps and Flatpaks try to be smart about managing and deduplicating library sets where possible, at least. AppImages just bundle an entire distro's worth of system libs with every app, lack of redundancy be damned.
I agree with your points. It's kinda frustrating to read/hear about all the nice new features of Gnome and KDE apps (and other things) and then realize that it's taking at least a few months before I get access to those new versions because Ubuntu/Debian/Whatever-Distro doesn't ship the update. Using Flatpaks on my SteamDeck and my KDE Neon VM is great so far. There are still some hick-ups (my "favorite" being the poor CLI usage for Flatpaks), sure, but I'm sure that those will get ironed out over time. As those stumbling stones are eliminated piece-by-piece over time I'm using more Flatpak apps over time as well (falling back to system packages when stumbling upon such problem).
that is why I use Archlinux, you get every new update super fast.
I have several complaints about Flatpak:
1. It takes up a lot of space. And there's a double problem here:
a) Libraries are packaged into applications statically;
b) Flatpak uses some very heavyweight platforms for applications.
2. The way applications are launched from the console is very inconvenient.
I believe that all these problems can be solved, but until they are, I usually prefer the good old package formats to Flatpak.
You've made an excellent and very important point: How does the Linux community want to spend its limited resources? Packaging a bazillion old apps, or prioritizing new development, like improved Wayland support, multi-monitor support and better shell integration for Flatpak, etc. When I was a Windows user, I used portable apps for my most important programs. Since they didn't get tangled up with the OS, Windows instability issues became less of a problem. When I switched to Linux (Pop OS,) I thought I would have to do without the portable app concept, but I found almost all my favorite programs available in Flatpak format. The only drawback is uneven support for shell integration. I would love to see more developer time focused on improving Flatpak integration than repackaging & testing 50 or so duplicative clock, calendar, etc. etc. apps.
Almost all users and even most developers really have no clue the time and effort spent packaging software. Most devs don't even have any experience in packaging.
I agree, flatpaks and snaps would make more sense for graphical applications
That's why I exclusively use flatpaks for everything. I use one app which has no flatpak, but they do have appimage. Currently on Linux Mint, but I'm waiting to hop to Vanilla OS 2.0 when it comes out. When Steam OS comes out, I will definitely try it and decide which is better for my use case. I used Silverblue/Kinoite, but it wasn't polished enough for me. That was some time ago, so it probably changed, but I don't feel the need to revisit them. I really like what Vanilla OS is doing with distrobox, atomic updates and What Steam OS is doing with nix packages. I would rather wait for one of those 2.
I will give a try to vanillaOS 2 too...
Or just stick with debian testing as base os, and use all of my app through flatpack...
And I'm slowly thinking to do the same with server, but with container and podman...
Debian stable as baseOS with few tools, and everything else in container...
Distro side packaging is still gonna be very important for command line utils unless you wanna use snaps. It's gonna be same for WM users using something like dmenu I'd assume, but snaps would work fine. But yeah I don't see any issue with making stuff like libreoffice a flatpak/snap by default. I think appimages have a lot of potential if they were made as convenient to use as the other formats. I doubt a community distro like arch would ever shift away from packaging everything either in repos or as AURs, same with debian, so that model is not going anywhere.
And even more, imagine you could have drivers as snaps. Actually Ubuntu has this kind of work for Steam gamers, they offer better performance and compatibility.
This is unhinged but I think theoretically the best solution is for gnu/linux to become gnu/linux/nix and for all distros to become nix derivatives.
Flatpaks have fundamental flaws like in system integration, and package size. They're great for some software but not everything.
On the other hand if theoretically every distro used the nix package manager and repositories this will mean no more repackaging the same software, no more duplicated libraries, still having the ability to have multiple versions for whatever needs it, plus native speeds.
This of course won't happen but I just had the realization that it might be the perfect theoretical solution
When your operating system and packages demand more time than the actual work you perform with your applications, there's a problem.
It's almost like automated compilation+packaging+testing doesn't exist, like we ain't using superior systems capable of that, or we lack the ppl who can make the scripts, or that the scripts can't be reused ...
Nick is a real modernity fanboy.
Yep
I really like what Fedora does where they package the base system as its own normal repository, but many (most?) of the apps in the GNOME Software store are packaged as FEDORA Flatpaks. Flathub is helpful, but for security, stability, and choice I really hope that distributions don't start relying on it.
For Ubuntu, the list of supported distros is way longer, as you also have the flavors, each with multiple versions. It is a hell more work istead of snap or something else that simply works on all.
... Honestly, for most stuff, I just build from source now. Like Emacs, version 29 has pure GTK support so it can run on Wayland, but somehow it's not officially released yet so you've gotta grab it and build it. It's really not difficult. Slightly easier on Arch because someone made an AUR package that stays up to date with Emacs' main branch.
IMO the problem isn't package managers but software that's so complex that no one wants to maintain packages. We need to better teach people how to do so and directly contribute to their OS.
I agree. Linux is feeling the pinch to find a way to pay the bills. Almost every distro is looking for efficiency. As for me, once I went to OpenSUSE Aeon, I was hooked. It's so fast and stable. Snappy. And, as a lazy man, I have loved how this is pretty much "set it and forget it." Nice.
Yesterday my wife had steam glitch out on her. She had steam as a linux mint package from the software library, and something broke when steam updated. Switching to the version from valve's website fixed the problem. Standards are a good thing, and one that I am more than happy to see. Everyone's life is easier.
Distro packaging probably made a lot more sense in a time when memory and disk space was more limited. Unless I'm mistaken, Flatpack, Snap, and AppImage all duplicate every library for each application installed.
You are wrong for flatpaks. At least the base packages are reused.
For appimages it is true however. Those have other very serious issues, just use flatpaks...
I can't speak for snaps as I don't like the proprietary parts of it.
The reason for this legacy model orf packaging is efficiency for the end user. With packaging formats like Apple, Microsoft, and Flatpak/Snaps/etc., you end up with each aapplication packaging all of its dependencies. So you wind up with as many different varriants of OpenSSL or GTK as you have applications. When you use the distro's legacy repos, you get exactly ONE copy of OpenSSL that is then shared with all apps in the system using it.. This not only saves disk space, but it saves memory since the Linux kernel will only load one copy of a shared library. That's why an old laptop can run Linux well, but be slow as hell running Windows.
there needs to be a universal solution that works for every type of app.
flatpak doesn't respect CLI tools well enough.
docker/podman are the only Real solutions for server-side apps.
the bias is so heavy on desktop facing apps that it's painful
i want to be wrong here, because i've tried to make using flatpak from a terminal work, but it's so clear the devs want you to use a .desktop file for everything.
"no, long namespaced package names are good!"
"no, you're weird if you want to run this app from a terminal!"
"what do you mean you don't want to map an alias to every flatpak you install, by hand?"
"why would you want to run a program just by calling its name?"
Yeah Flatpak is really meant for graphical apps launched with a graphical launcher. We still need a good solution for command line apps
I keep forgetting that compiling almost everything myself is neither normal nor sane
I completely understand why Flatpaks are desirable, but my biggest worries about them are the centralization around Flathub for app distribution, which of course could be mitigated if other "flatpak repos" pop up, and the fact that neglected Flatpaks could lead to security vulnerabilities in your system, since you can't just upgrade one vulnerable dependency and have it apply to all your Flatpaks like you can with native packages.
The point about vulnerabilities in packaged dependencies is a good one.
Nobody talks about the near perfection Homebrew (for both mac & linux) and Nix (this has 20 years of work behind it) package managers
Homebrew was first released in 2009 and Nix in 2003 ( my b-year btw :) )
Immutable distribution like Fedora Silverblue I am currently sitting on, look like the way to solve it
Edit: this video is exactly about it, lol. I thought it would be just a list of all flaws Linux Distros have
The only thing I would like, besides having packaged applications from a centralized store, is the ability to run those packaged application even if I get them "outside" of the store, a bit like app bundles for macOS, you can get them signed and notarized from the app store, but you can also just download it from a website and it will run anyway.
Just use Arch or a derivative of Arch (Manjaro, Garuda, etc)
You won't have to worry about outdated stuff ever again and the AUR has basically ANYTHING that exists on the internet.
There is a good reason why Steam OS chose Arch as their upstream base.
AUR isn’t official packages. They’re still maintained by users, they’re not something I would trust. And they are often broken, or unmaintained as well. They only solve the « old version » problem, they don’t solve the Linux distro model ;)
And then end up with unbootable system or broken glibc. :D
@@TheLinuxEXP Flatpaks and AppImages are equally maintained by random users. The only difference is that Flatpaks and AppImages are binaries so you have no idea what is inside them whereas in the AUR it's just source-code openly readable by anyone. If some shenanigans are going on in open source code, someone will notice it pretty quickly. Way more safe and trustworthy method.
I agree with everything in this video. One quick note: (around 3:20 you talk about "stable versions")
"Stable" version and version stability are different things. For GUI apps its not really often the case, but a new update may change the behavior of the app in a way that breaks my workflow. Usually those are features for more advanced users, or those that use the CLI of a gui app to automate processes.
I cannot stress how important Flatpack is for normally windows based applications like Discord. However, they are buggy as hell for things that are made for Linux itself, it just works more efficiently to use packages.
That hasn’t been my experience. I only use flatpaks these days, and I have yet to find a single use case where’m the package is better!
@@TheLinuxEXP I've had issues with plasma integration not working with browsers under flatpak, I will say that flatpaks are the future, but I need that plasma integration
I thought it might just be me but in my experience Flatpak apps are slower than native Linux packages.
Hate to say it, but I use snap discord, although it does seem to work on my pc. I haven't gotten into flatpak yet other than gnome-builder, that worked well also. I prefer just using apt overall
@@mathman0569 I get pretty good integration on 5.27 man
Yes, I prefer the better control of having flat packs for a user. But there are times it's just nice to have everything ready and bundled for new users, especially those coming over from windows.
Flatpaks' size makes them completely impractical. As an extreme example of how insane it can sometimes get: FreeFileSync's deb package is 27MB. The flatpak is 1.4GB. No one is going to convince me that's a practical solution.
The freefilesync flatpak is 36.2MB and an additional 6.2MB in a locale package.
@@JorgeCastro - I checked just before this reply and at this very moment it's listed in the Linux Mint 21.1 software manager at 1.4GB. As you can imagine, I'm not even starting an install listed at 1.4GB when the deb weighs in at only 27MB, so I didn't test to see if that's the actual size.
No, packages used to come as tarballs and they were self configurable, meaning they examine the installed libs on your machine and compile accordingly. Shipping 100s of versions of the same lib installed on my machine just makes those packages a bloatware. GNU/Linux had a great advantage in it's packaging model, that the packages were really small and included just the code the developer contributed on top of a preset requisite.
Now of course the current OS compatibility bugs would be fixed in time. Maybe in time those formats will become more resource aware and there will be attempts to share resources (become more modular). Until I see them minimizing the footprint of the installed binaries (executables or libs), I will stick to the old packaging formats (even if that means, I will need to compile and configure a package manually).
Another point against Flatpaks will be the demise of a single UI/UX for the GNU/Linux OS. It is hard as it is to standardize the Linux Desktop right now with all the DE toolkits: GTK/QT/whatever... Now imagine including all those web based apps like Discord, VS Code, etc... Consistent native desktop environment will be dead forever. Moreover they might be driven to fit their app to the Mac OS/Windows standards, therefore making the job of Gnome/KDE, etc teams even harder to create a unified app ecosystem.
I just spent an hour removing all the default apps from Debian 12 so I could reinstall them from Flatpak. I prefer the OS without any apps so I can choose what to install myself.
That’s the goal for me too! Having a solid base with packages, and all apps are flatpaks
Is there no way to install a more minimal install for this use case? I’m comfortable with debs so I never looked into this
compiling from source will always come out on top /s
Everyone knows that the ultimate evolution model is the crab. Gotta have a crustacean Linux fork then, logically. Enter Crabuntu!
It Crabuntu doesn’t adopt snaps I’m down
Also, flatpaks are sandboxed which has many benefits.
And many drawbacks
I hope that Flatpak and Snap will add some option to not sandbox the app, like for example it annoys me a lot that I have to give the Steam Flatpak explicit permission to access my external hard drive and the installation directory of apps I want to be able to start through Steam.
Can't you allow it access to the full filesystem already though? I think it is better if there way just the option to allow full access to all files.
@@fabiandrinksmilk6205
That's basically what I mean. It uses libraries it has packaged into its container (to prevent dependency hell) but has access to everything like a binary directly running on the host system.
I'm a Gentoo user, yesterday i recompiled audacity because of a flag change which i needed. Obscure compilation error, spended 10 minutes to solve it without success, so i installed the flatpak which is buggy, but works.
I am new in Linux and what you said here makes sooo much sens for me. Great work!
Thank you!
Maybe thats why time shift uses 20gigs for 1 save.
The Linux desktop distribution model has been broken for many years but, the users do not want it to change so, it is what it is.
Yeah 'm perfectly fine with things how they are right now.
I know a guy who recently added a vi ebuild (it got replaced with vim in 2020), so they're not going away any time soon.
I use a mix of Flatpak & pkg, with a lean towards Flatpaks, and this is coming from an Arch user with quite a minimalist viewpoint. WM>DE 😂
There have been a few Flatpaks with errors, and probably a hell of a lot more pkgs. We shouldn't damn a technology due to a few bad experiences, but try to work towards making them better. Then let people decide which they prefer.
As the historical user of more OSes than most, I've seen the ebb & flow of this technology set. Each new idea seems strange for a while, and will live or die on it's usefulness.
I think in the current situation we should not completely rely on any type of package. I just download the software from the official site and use the official package provided by the developer whether it's appimage, flatpack, deb or even snap
I think that Flatpak etc are the future for a lot of Applikations.
But there is some software that I don't want in that Format, for example my primary Browser. That one has to start fast and not take up too much resources, so containerization destroys that.
Also, a lot of things you said are not issues with all distros. e.g. The need to maintain multiple versions of packages for different releases of the distros goes away with a rolling release distro. TBH I never fully understood why things like Ubuntu ever made sense like that. I mean, for some users it's evidently nice enough, but as a dev I'd never be satisfied with having to support the lazy ass of these users, that at some point have to update anyways. Beyond a certain release duration the benefits that you get by not having to learn some short lived inconveniences is far outlived by the herculean task it is to learn all new systems all at the same time. So I'd rather get the changes piecemeal.
I am mixed on this as currently both snap and flatpak dont offer full integration and some things just dont work.
Having the old standard package formats will still be needed for drivers and such too, thus why I dont see a point in using "immutable" flavors.
It’s a work in progress!
I am in favor of flatpaks, but I am cautious with centralized systems. We never know when flathub turns coat and does something against the community's interest *cought* red hat *cough*
I will switch to using flatpak software when the edge cases I need are fixed
@@lordkordus8139 Yes, that is why I am not against it. But the biggest repo, flathub, could hinder the community if they really wanted. I know someone somewhere would lift another hub and continue. Snap is just garbage and I refuse to use it. Just hoping flathub does good gor the community!
You just spoke my mind. Also as a new to Linux user it always annoyed me that why do I need to use an older version of a graphical app rather than the latest stable version.
My biggest grip with flatpacks, snaps etc is the potential for copycat/unofficial apps in the app stores and the vetting of those apps. Windows, Android and Apple all have this problem. There needs to be some form of digital signature on the official apps and copycats should not be able to use same/similar names/icons.
I think there already is a verification system for Flathub that shows a checkmark under packages from developers themselves or developer approved maintainers.
This kind of vetting and digital signing already exists in the Snap Store. The caveat is that any 3rd party can package an application as a Snap. If the packager is provably identified, they get a "verified" flag, and if reputable or the original app developer, they get a "star" flag.
What's the difference to regular open source apps? Getting the sourcecode is usually a piece of cake, so copycats are just as easy now as they would be with flatpacks and other formats.
@@stephanhuebner4931 Copycats are more prevalent in app stores vs curated repos. I don't have a problem with someone creating their own version. I just want them to be marked as such in the app store and not be allowed to use deceptively similar icons/names.
Something that has _really_ bugged me about Linux package managers is that, going from one distro to another, you're going to get different versions of things. When I was first venturing into Linux as a daily driver, I needed packages like Maven, and I'd get told by Linux-shills "just apt install maven", except that I'd get a different version from apt than from dnf, so builds of the exact same commit would fail on my laptop but work on my desktop. It's only when we switched to using the Maven wrapper that we got around this problem... and in a sense, isn't that just an AppImage?
I couldn't disagree more. Sandboxing is the bane of my existence.
I hate mobile apps because they are all sandboxed. Now we are bringing this problem to the desktop... what joy...
Also, the latest stable version is not synonymous with the best version. Sometimes developers REMOVE features. Sometimes things break. Sometimes the "new feature" is now there are add banners everywhere and you have to endure a timed pop-up every 20 minutes to keep using the application.
Sometimes I don't want to have to re-learn a new version of an app that I've used the way it was to do productive work for months or years and suddenly fined that somebody moved my cheese.
Newer isn't always better.
In this case it is better though
I am using debian 12 with flatpaks. It is so good experience.
people hate on flatpaks too much, I didn't use them until I heard you saying how great they are and now I'm hooked, no more weird graphical errors bugs and frequent crashes, I hope they switch to flatpaks exclusively and put that work toward making other things better
Yep!
On my system what i often get is instability from flatpaks, crashes from nowhere. Still i do hope they not only get better but are the default for most Graphical Apps
@@justcatu9107 what distro do you have?
Really excellent video and importsnt conversation, Nick! (as usual)
A few observations:
- FOSS world is source oriented and based, and has a philosophy of DIY. Sources are far more portable.
Now, commercialized and consumer FOSS can't handle this (easily). Of course, commercialized and consumer FOSS is not an evil, quite the oposite, but it also have "consumerism" behaviours. Lotfs of different apps, lots of opinions, about the same things, instead of a common source based tool that gets updated and adopted based on needs and engineering. Again, not a bad thing, but a different thing. And certainly a challenge for the DIY and community tool building spirit of the original FOSS.
- Biggest issue these days and for the next few decades is SBOM. Software Bill of Material. For security audits if not for compatibility and interop. packaging format do help solve this issue in 2 ways, as you've mentionned: focus on 1 object to audit, sign, distribute (time). and focus on 1 object binary (resources and interop).
-The next evolution can be Nix and Guix: Minimal GNU/Linux offering just container tools and drivers, everything else runs as containers, docker images, virtual machines etc.
This can be great for productivity tools, as they are going tobe isolated, better audited, self-contained and can free the market for their creators, and great for gaming and hardware intensive apps, and these could just request from the kernel full attention turning literally the machie into a console with a minimal viable set of OS and drivers to run.
These ideals of isolation are literally why CPU protected mode and memory management units were invented, then virtualization instructions (in the 60s on IBM mainframes!). The greatest example of great engineering using this isolated computing are again IBM mainframes: they are still backward compatible decades back, they can be rebooted and updated and distributed without affecting the running software.
I really hope that .deb format uses its weight and leverages guix, or at least nix.
Either you stop calling it distribution, or you should be fine with them putting all these packages up. If you want Linux with just Flatpak, you'll probably just want the OS. I however, would want the distribution. The All-in approach.
You do know that they’d still distribute everything else, right? And they’d distribute Flatpak or snaps instead of packages. That’s still a distribution, with choices, configurations, app selections and various subsystems. The packaging format doesn’t matter to what a distro does.
I'm certain that eventually someone will try to put the core system into a flatpak set. It will happen eventually since every standard that has some adoption on Linux gets a bunch of extra stuff shoved in that was never intended.
@@TheLinuxEXP I thought the way it was meant to work, was that flatpaks would be provided Windows style, as downloads on websites that anyone has their own reign over. That's what I thought you meant in the video. Sorry, if I misunderstood. At that point, in my mind, it ceased to be a distribution, and became, like Windows - just the OS, and we would go to various sources to get the flatpaks.
I still remember compiling my first kernel over 25 years ago. I had no idea what I was doing :)
Switch to Nix :p
it's not broken, it's evolving in a way that closed systems never could
The developer should have exactly zero control over what version of their software the users are running. That's a feature, not a bug.
No, that’s backwards. Sure the user chooses what they run. But the developer then could say « I don’t support you, because you’re not using the latest version. »
And neither should the distro. But doing your own way next to the distro just to use a newer version almost always causes problems.
@@TheLinuxEXP That's how that works usually
bug reports:
I’m still looking for a way to build packages from source that is easy and straightforward. Like arch tries. On a newer and powerful machines it’s not an issue but older or just less powerful systems other options are welcome.
Nix or some new kind of declarative configuration is the future of Linux. It solves some of the thorniest problems related to reproducibility and configurability and is a holistic solution that makes even patching the kernel yourself or applying kernel patches, modules and configurations a breeze. It's also a pain in the ass to use in its current form, thus the adoption has been slow (although picking up lately) so focus should be on making declarative configuration more user friendly. Any "distro" could be offered as a custom configuration of Nix.
Nix is awesome, but I’m afraid it looks too complex for most users
There are wrappers for Nix package manager, like Devbox. Basically allows to specify which packages you want to install in a small array in a JSON file.
Is way more limited than Nix itself, but an option way more user-friendly for the average person.
@@TheLinuxEXP Nix could also exist one layer underneath and on top of it there's a more traditional user experience. In it's current form it's definitely too complex even for most hardcore users (I use it for work to build secure hardened OS), but the underlying idea is solid. When it becomes more mature and mainstream I think the complexity can be reduced a lot to something that's actually less complex to administer than a normal distribution.
@@user-rd5qf4oh6u I think the key could be this as in Nix exists one layer underneath the normal user experience and is configured through a more traditional interface.
@@TheLinuxEXP nix is the only one (beside guix) bringing configuration together with packaging. Flatpack/Snap/Appimage are not for kernels and system basics. I do not want X package formats and managers, I want one that works everywhere. Nix is not that complex for a consumer, maybe it just lacks a gui to be usable for everyone.