The LINUX DISTRO model is BROKEN

Рет қаралды 74,845

Күн бұрын

Stream any OS, desktop, or app to your browser, now with translations: kasmweb.com/docs/develop/deve...
Grab a brand new laptop or desktop running Linux: www.tuxedocomputers.com/en#
👏 SUPPORT THE CHANNEL:
Get access to a weekly podcast, vote on the next topics I cover, and get your name in the credits:
KZfaq: www.youtube.com/@thelinuxexp/...
Patreon: / thelinuxexperiment
Liberapay: liberapay.com/TheLinuxExperim...
Or, you can donate whatever you want: paypal.me/thelinuxexp
👕 GET TLE MERCH
Support the channel AND get cool new gear: the-linux-experiment.creator-...
🎙️ LINUX AND OPEN SOURCE NEWS PODCAST:
Listen to the latest Linux and open source news, with more in depth coverage, and ad-free! podcast.thelinuxexp.com
🏆 FOLLOW ME ELSEWHERE:
Website: thelinuxexp.com
Mastodon: mastodon.social/web/@thelinuxEXP
Pixelfed: pixelfed.social/TLENick
PeerTube: tilvids.com/c/thelinuxexperim...
Discord: / discord
#Linux #linuxdistro #operatingsystem
00:00 Intro
00:35 Sponsor: Stream any OS, desktop or app to any PC
01:29 The Classic Linux Distro Model
02:57 Why it's broken
04:25 Distros are moving away
05:52 The new model isn't perfect, but still better
08:31 All other OSes do this
09:22 Why distros package apps in the first place
10:14 Universal Packages
11:40 You don't have a choice
13:32 Sponsor: Get a PC made to run Linux
14:27 Support the channel
This video was inspired by the following blog post, which echoed my sentiment and ideas exactly: www.ypsidanger.com/the-distri...
The distro packages the software for their users. Not the developers of the software, the distro itself. So the distro has a decent amount of control over what they offer, but the users of the distro don't, and the developers of the apps also don't. And this model doesn't really work.
On the surface, for users, it does work. You get a lot of applications from a central repo, and the system is generally pretty stable, depending on the distro you pick.
But in the background, you have the thousands of orphaned packages that are still in the repos but aren't maintained. The old apps that can't be packaged at all anymore. The maintainers spending a lot of time repackaging and recompiling software that has already been packaged.
One might not like Ubuntu's snap packages, or Flatpak, or AppImages, but it's undeniable that most distros are moving towards them.
When Ubuntu moves Firefox and Chromium from a deb package to a snap, it's a GOOD THING. For Ubuntu. Because instead of having to package each new version of Firefox or CHromium for all currently supported versions of Ubuntu, they only have to package them once.
Same thing when Red Hat drops the LibreOffice RPM in favor of the Flatpak. Not having to package that behemoth of an app will free up time for Red Hat developers to work on HDR, improving Wayland, and supporting color management.
And moving the packaging of an app from the distro to the app developer means less time spent debugging stuff, and more time spend on improving the app.
So why did Linux distros start packaging software instead of app developers?
It was because there were so many different systems using the same packaging formats, deb or RPM or whatever else, but different libraries, kernels, drivers, and everything else, that app developers simply did not have a way to distribute their own software to every distro.
But nowadays, we DO have formats that let you distribute applications everywhere with one single package.
They lack some features, especially due to the sandboxing they tend to use, that limits how they can interact with other apps. Thing is, these formats are still under heavy development.
But the real question is: do you prefer staying on the current model where we stagnate, duplicate work, and where developers and users have no control over which version of the software is used, or would you rather face a few teething issues, but let developers improve their apps, and the whole of the Linux software ecosystem?
I know what I choose, and it's not these old packages. And presumably, if you stick to mainstream distros, like Fedora, Ubuntu, or their main derivatives, chances are you're not going to have a choice either. Because whether you like it or not, we're moving to Flatpak or Snap on most distros.
It's more efficient, and their current problems can and will be fixed. The duplication of work that legacy packaging creates is unfixable, it's a structural problem.
And of course, if you hate these universal packaging formats, I'm sure you'll still be able to find a lot of distros that will not move to them even in the future. You'll just be running the non official version of an app, just like what you're doing right now when using a distro's package.

Пікірлер: 977

@TheLinuxEXP Жыл бұрын

Stream any OS, desktop, or app to your browser, now with translations: kasmweb.com/docs/develop/developers/builds.html

@thexepe Жыл бұрын

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 clamored for software to just use one format, and now that it does, they complain 😅

@tejasraman6913 Жыл бұрын

@@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

@mobilelegendsaccount3275 Жыл бұрын

@@tejasraman6913 and ssds are cheap now.

@gigalodon14 Жыл бұрын

@@tejasraman6913i mean SSD are like 40$ per TB here, that should not be a reason in 2023

@johndododoe1411 Жыл бұрын

@@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 .

@guy_autordie Жыл бұрын

With Gentoo *YOU* compile your package! That way it become your problem! Amazing! X)

@vk3fbab Жыл бұрын

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.

@SADXGamer4 Ай бұрын

Yeah, no thanks. I don’t want to spend 3 days compiling chromium

@prussianjger7050 Жыл бұрын

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.

@TheLinuxEXP Жыл бұрын

Oh yeah. The command line for Flatpak is annoying

@someonehere4380 Жыл бұрын

yes!! that's my only complaint about flatpaks like why can't i use the name of the package

@foznoth Жыл бұрын

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.

@T1Oracle Жыл бұрын

I think the URL is good for preventing name collisions. Maybe flatpak needs a way to query for them?

@christopheriman4921 Жыл бұрын

@@T1Oracle They have a way to query for them using the flatpak search command it is just annoying to have to use that.

@Fenrasulfr Жыл бұрын

I am all for a universal packaging system as long as it is not snaps since that is not fully open source.

@bertnijhof5413 Жыл бұрын

You must like Windows, where every hacker can distribute any exe file. Every hacker can also distribute any flatpak.

@ok-tr1nw Жыл бұрын

@@bertnijhof5413 but who is forcing you to use a repo that doesnt have public build repos/build logs

@bertnijhof5413 Жыл бұрын

@@ok-tr1nw Nobody forces Windows users either, but they get hacked like that.

@themadoneplays7842 Жыл бұрын

@@bertnijhof5413 Yeah but the same can be said about .rpm and .deb packages.

@ok-tr1nw Жыл бұрын

@@bertnijhof5413 yeah, im only saying it since their argument only works on inexperienced users

@ronobvious1785 Жыл бұрын

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.

@niksaysit Жыл бұрын

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.

@rtsa4633 Жыл бұрын

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.

@NorbiPeti Жыл бұрын

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.

@flemtone Жыл бұрын

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.

@tomv3999 Жыл бұрын

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.

@TheLinuxEXP Жыл бұрын

That’s really good, yeah!

@DMSBrian24 Жыл бұрын

that is nice, but impossible to deal with on a large scale due to version mismatches/dependency conflicts, unless you static-link everything

@MixedVictor Жыл бұрын

I might take another look at the BSD's, it got me interessed in some parts

@guy_autordie Жыл бұрын

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.

@fcolecumberri Жыл бұрын

That on Linux is called Gentoo

@pdr. Жыл бұрын

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.

@TheJackiMonster Жыл бұрын

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.

@ped7g Жыл бұрын

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.

@emptydata-xf7ps Жыл бұрын

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.

@pdr. Жыл бұрын

@@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.

@emptydata-xf7ps Жыл бұрын

@@pdr. yea I can agree with that. Didn’t think about vulnerability in older dependencies.

@MyReviews_karkan Жыл бұрын

I never use it, but "I use arch, btw" has never been more fitting. 😂

@Dmytro-Tsymbaliuk Жыл бұрын

Arch is really good ecosystem

@proctoscopefilms Жыл бұрын

Flatpaks rise to prominence is insane. Seems like a couple years ago that the universal package format war was still unsettled. Now the Steam Deck relies on it. Red Hat has done SO MUCH to improve desktop Linux and it's ecosystem. They were so easy to root for. Now a lot of that good will is toast. Wild how things change so quickly!

@linuxstreamer8910 Жыл бұрын

i use mostly arch repos/aur but some flatpaks + a handful of appimages

@proctoscopefilms Жыл бұрын

@@linuxstreamer8910 that's what I'm working with too. Very rarely do I have theme issues anymore either. I have programs installed that I never knew were flatpaks, never needed to!

@Megalomaniakaal Жыл бұрын

Far as I can tell, nothing has gone closed source and people are making a mountain out of a mole hill. But with the linux community I guess it's a par for the course.

@proctoscopefilms Жыл бұрын

@@Megalomaniakaal I feel you. Personally I wouldn't say that RHEL is closed source but it's less open and that's not what anyone wants right? There's so much great work done at Red Hat by very talented people. They improve your desktop experience even if you're not on RHEL or its derivatives. This won't wipe all of that away, but they're gonna get a lot of deserved criticism if they continue closing things up.

@glebglub Жыл бұрын

@@proctoscopefilms eh, you can still get access to the code on a free dev account, or if you're a non-profit/open source business. from what I can tell it's mostly because the downstream distros (Rocky, CentOS) offer cheaper support whilst never giving anything back to Red Hat itself both money and code wise. Red Hat only makes its money on support, so yeah, I'm kinda on their side, since they're the ones that actually code & maintain it

@Winnetou17 Жыл бұрын

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.

@dfs-comedy 11 ай бұрын

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.

@Winnetou17 11 ай бұрын

@@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 ?

@dfs-comedy 11 ай бұрын

@@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.

@ransan Жыл бұрын

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.

@-aexc- Жыл бұрын

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

@FlorinArjocu Жыл бұрын

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.

@ezequielpartida5846 Жыл бұрын

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..

@andrewvirtue5048 Жыл бұрын

But snaps are better than flatpak.

@mfb9482 Жыл бұрын

it's the same crap, snaps and flataks

@guilherme-freire Жыл бұрын

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.

@Tn5421Me Жыл бұрын

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

@bob-wong Жыл бұрын

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.

@mglsj Жыл бұрын

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.

@johndododoe1411 Жыл бұрын

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 .

@katrinabryce Жыл бұрын

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.

@BulukEtznab Жыл бұрын

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...

@mglsj Жыл бұрын

@@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.

@fulconandroadcone9488 Жыл бұрын

@@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.

@1Raptor85 Жыл бұрын

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.

@GutnarmEVE Жыл бұрын

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...

@veruthas Жыл бұрын

If I wanted a rolling distro, I'd go with Arch. I like having the stability of packages being locked to a release.

@xAffan 11 ай бұрын

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.

@veruthas 11 ай бұрын

@@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

@xAffan 11 ай бұрын

@@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.

@veruthas 11 ай бұрын

@@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.

@xAffan 11 ай бұрын

@@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.

@MaryamMaqdisi Жыл бұрын

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.

@tomaszgasior772 Жыл бұрын

Themes are a thing from the past. Don't use themes, keep defaults. Your life will be easier.

@godfist314 Жыл бұрын

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.

@summerishere2868 Жыл бұрын

@@tomaszgasior772 Themes are great (one of the pros of linux). Defaults are boring.

@Nk-ti4st Жыл бұрын

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.

@AyushGupta-wn6zd Жыл бұрын

@@summerishere2868 yeah. What's this arguement, "I want to do this" "well, it's old school. Don't do it anymore"

@Reiikz Жыл бұрын

I think multi library version support is something that Linux has needed for a long time.

@SpeedKreature Жыл бұрын

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.

@friedrichhayek4862 Жыл бұрын

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 Жыл бұрын

Sorry OSS Nazi, but you should not be against distributing Propietary software. PD: SUSE also does it.

@MaryamMaqdisi Жыл бұрын

@@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

@friedrichhayek4862 Жыл бұрын

@@MaryamMaqdisi Nazi, Stalinism, Maoist, Social Democrat all of the are the same

@christopheriman4921 Жыл бұрын

@@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.

@JungledG Жыл бұрын

Flatpack FTW!!! 📦📦

@flavioluis8218 Жыл бұрын

The GOAT

@raptag7114 Жыл бұрын

Period. Just that.

@kathleendelcourt8136 Жыл бұрын

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.

@lennihein Жыл бұрын

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.

@thelakeman2538 Жыл бұрын

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.

@FlorinArjocu Жыл бұрын

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.

@RogueRen Жыл бұрын

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

@cameronbosch1213 Жыл бұрын

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.

@webxorcist Жыл бұрын

I can't believe I still can't give arguments when starting a Flatpak application.

@bjugler Жыл бұрын

This!

@BrianHarkness Жыл бұрын

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

@adog_6484 Жыл бұрын

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.

@talkysassis Жыл бұрын

System tools should be GUI apps too, so no problem here.

@Aras14 Жыл бұрын

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).

@doragonmeido Жыл бұрын

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 Жыл бұрын

@@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

@doragonmeido Жыл бұрын

@@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

@Theinvalidmusic Жыл бұрын

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.

@prizrak420 Жыл бұрын

Having a bajillion packages and package repos is messy BUT it also gets rid of single point of failure.

@niksaysit Жыл бұрын

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

@knoplef Жыл бұрын

Correct, it creates MULTIPLE points of failure 😁

@Chimera-jz7pm Жыл бұрын

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"... :)

@kacperrutkowski6350 Жыл бұрын

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 Жыл бұрын

@@kacperrutkowski6350there is always NixOS

@kacperrutkowski6350 Жыл бұрын

@@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.

@zapyvr Жыл бұрын

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 Жыл бұрын

What kind of features do you lose because of sandboxing?

@johanngambolputty5351 Жыл бұрын

@@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.

@zapyvr Жыл бұрын

@@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.

@friedrichhayek4862 Жыл бұрын

THere is no real sandboxing is flatpaks, they are as insecure as running the app directly outside of a flatpak.

@AndresChoqueLopez Жыл бұрын

@@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.

@manemobiili Жыл бұрын

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

@WillStrickland Жыл бұрын

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.

@hammer86_ Жыл бұрын

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.

@shatterstone3045 Жыл бұрын

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.

@wombatdk Жыл бұрын

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.

@formbi Жыл бұрын

@@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?).

@wombatdk Жыл бұрын

@@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.

@formbi Жыл бұрын

@@wombatdk yes, I fixed the comment now

@wombatdk Жыл бұрын

@@formbi Typoese, the official language of the Interwubz :)

@jerryferreira8960 Жыл бұрын

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.

@deno1122 Жыл бұрын

I prefer deb packages over snap or flatpak

@merakli2022 Жыл бұрын

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

@TheJackiMonster Жыл бұрын

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.

@1Raptor85 Жыл бұрын

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 Жыл бұрын

@@TheJackiMonsterI would argue NixOS is better than Arch, simply due to the fact that packages tend to be more up to date

@TheJackiMonster Жыл бұрын

@@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.

@MaartenT Жыл бұрын

@@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.

@zyten Жыл бұрын

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.

@Tachi107 Жыл бұрын

What weird flags are you referring to?

@chuctanundaspiderbone5407 Жыл бұрын

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.

@nitrogenez Жыл бұрын

Nick is a real modernity fanboy.

@TheLinuxEXP Жыл бұрын

Yep

@Fiachra9357 11 ай бұрын

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.

@janTelo Жыл бұрын

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.

@C0SSTY Жыл бұрын

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.

@LtSich Жыл бұрын

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...

@Gramini Жыл бұрын

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).

@Ateshtesh 11 ай бұрын

that is why I use Archlinux, you get every new update super fast.

@3lH4ck3rC0mf0r7 Жыл бұрын

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.

@ThePythonicCow Жыл бұрын

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.

@the-boss-98 Жыл бұрын

I agree, flatpaks and snaps would make more sense for graphical applications

@FlorinArjocu Жыл бұрын

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.

@linuxstreamer8910 Жыл бұрын

depends on the added features on the latest stable version if the version ubuntu ships works & does what i need do i need to update to that?

@balorvalorbus 3 ай бұрын

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.

@abrotherinchrist Жыл бұрын

When your operating system and packages demand more time than the actual work you perform with your applications, there's a problem.

@rightwingsafetysquad9872 Жыл бұрын

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.

@matthiasbendewald1803 Жыл бұрын

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.

@RepChris Жыл бұрын

I keep forgetting that compiling almost everything myself is neither normal nor sane

@user-ox8mx8we7r Жыл бұрын

Is it possible for certain desktop environments, such as "GNOME", to work with certain packers?; that we don't have to change "DISTRO", but only desktop environments, which are specialized to work with certain packers. Are there "LIGHT" versions of the desktop environment for "LIGHT" "distros"? Any converter-"decoder" between "standalone"-"downloaded" packages for multiplatform popular applications?

@someoneelse3876 Жыл бұрын

I noticed that many flatpak apps are missing features, one example is 1Password that is missing the ssh-agent feature. Stuff like that makes me not want to use Flatpak.

@TheLinuxEXP Жыл бұрын

That’s being worked on :)

@johnwestervelt1525 Жыл бұрын

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.

@anonymous_opinions1924 Жыл бұрын

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.

@little_forest Жыл бұрын

Agreeing on the central points, but there are things to add and clarify: - stable means not (only) „not crashing“, but also stable in regards to the features aka the features do not change in a stable app. - if ubuntu would only use snaps because of the reasons you provided, then it would make way more sense for them and the would save so much more time, if ubuntu were using flatpaks. Since they don’t, there definitely are additional reasons one can only speculate what they are. - what can be called an OS is an arbitrary definition. You base yours on the differences between macos and windows, distros commonly seem to agree on the fact, that the (smaller) differences between them are enough to call it an OS. There is no law of nature that states that one can only speak of different OSs if their kernel is (completely) different.

@RedBlueProductions1 Жыл бұрын

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?"

@TheLinuxEXP Жыл бұрын

Yeah Flatpak is really meant for graphical apps launched with a graphical launcher. We still need a good solution for command line apps

@kittenfrompicture Жыл бұрын

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

@trapexit Жыл бұрын

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.

@abuttandahalf Жыл бұрын

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

@ChamberOfTimeLover Жыл бұрын

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.

@eDoc2020 Жыл бұрын

The point about vulnerabilities in packaged dependencies is a good one.

@errorsofmodernism7331 Жыл бұрын

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.

@TheLinuxEXP Жыл бұрын

That’s the goal for me too! Having a solid base with packages, and all apps are flatpaks

@MaryamMaqdisi Жыл бұрын

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

@themadoneplays7842 Жыл бұрын

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.

@TheLinuxEXP Жыл бұрын

It’s a work in progress!

@paolozago6123 Жыл бұрын

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.

@an-eios7125 Жыл бұрын

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.

@TheLinuxEXP Жыл бұрын

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 ;)

@JahidulIslam Жыл бұрын

And then end up with unbootable system or broken glibc. :D

@an-eios7125 Жыл бұрын

@@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.

@ukaszpalczewski7588 Жыл бұрын

I am new in Linux and what you said here makes sooo much sens for me. Great work!

@TheLinuxEXP Жыл бұрын

Thank you!

@jeremsgarage 10 ай бұрын

Question for you. What mobile phone should I use in tandem with Linux. My preferred desktop is Linux. My mobile phone is iPhone. Thanks! Appreciate the videos.

@krtirtho Жыл бұрын

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 :) )

@Lampe2020 Жыл бұрын

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 Жыл бұрын

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.

@Lampe2020 Жыл бұрын

@@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.

@9SMTM6 Жыл бұрын

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.

@rautamiekka Жыл бұрын

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 ...

@colbyboucher6391 Жыл бұрын

... 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.

@dudarafa- Жыл бұрын

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

@dudarafa- Жыл бұрын

@@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!

@Schlumpsha Жыл бұрын

Everyone knows that the ultimate evolution model is the crab. Gotta have a crustacean Linux fork then, logically. Enter Crabuntu!

@MaryamMaqdisi Жыл бұрын

It Crabuntu doesn’t adopt snaps I’m down

@aaRept Жыл бұрын

I already try to use the flatpak version of apps if it's available. I love the idea and I want to see it develop and succeed.

@sebtheanimal 10 ай бұрын

Love your channel and Linux and all toils associated with it. As a long time Linux user, since about 1998, I can tell you one thing surely - Slackware and Slackware.

@foznoth Жыл бұрын

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.

@josephnorris4095 Жыл бұрын

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.

@Jammet Жыл бұрын

Yeah 'm perfectly fine with things how they are right now.

@FreeManFreeThought Жыл бұрын

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.

@locatemarbles Жыл бұрын

And the war of the corporations against repo packages goes on. I will be very blunt: we already have a universal package system on Linux. Its called a deb file. If your distro can't handle deb files you are running the wrong distro.

@vram1974 Жыл бұрын

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.

@fabiandrinksmilk6205 Жыл бұрын

I think there already is a verification system for Flathub that shows a checkmark under packages from developers themselves or developer approved maintainers.

@JonathanHartley Жыл бұрын

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.

@stephanhuebner4931 Жыл бұрын

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.

@vram1974 Жыл бұрын

@@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.

@rebokfleetfoot Жыл бұрын

it's not broken, it's evolving in a way that closed systems never could

@stephenlopiano1599 Жыл бұрын

Interesting video. Will this make running operating systems more vulnerable to malicious attacks or safer? Thinking about this issue when you have packages branching off in many directions it would take someone a lot more time, headaches and different malicious code creations to get to a larger number of users using that package application. With everything turning into a sort of default standard there will be only one malicious code for all different operating systems to create embedded into an application package, seems to me the probability of getting hit increases since more users will be tied into the same way of accessing the same packages and applications. Of course I may simply be a bit too paranoid or ignorant about the details involved? Another issue here that comes to mind from my own personal experience using Linux is how will this effect the ability to have multiple desktops on any particular flavor of Linux? None of the on-line repositories that I have used have the option of installing alternative desktops to the operating system you are using. The workaround has been using a terminal with text input commands to get the desktops or Synaptic Package Manager. If this integration takes place will the user have only the option of whatever the default desktop for that operating system is or will Snap and FlatPak start adding a way to get desktops through their repos? Personally I always install Linux operating systems with a variety of desktops to choose from when logging in; Cinnamon, Gnome, Plasma or Xfce. Again what about display managers such as; lightdm, kdm and gdm, will you still have choice to change or will the user have to settle with whatever the default is? The app images are really nice from my experience over the years, they have allowed continued use of programs that have broken dependencies or conflicts when attempting to access the application package from the repositories, good example would be MyPaint. In addition they are portable allowing the user to install the app on a thumb drive and use it on most different flavors of Linux. Theoretically it may be possible if developers did not find this idea impossible due to the technicalities, you might be able to use a 32gb to 254gb (with all your important created files) thumb drive with all your-app images installed to run on all your flavors of Linux for a multi-operating system desktop or laptop to save some memory space when it is limited for that partition.

@kanecitizen Жыл бұрын

compiling from source will always come out on top /s

@Maxume Жыл бұрын

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 Жыл бұрын

The freefilesync flatpak is 36.2MB and an additional 6.2MB in a locale package.

@Maxume Жыл бұрын

@@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.

@damianateiro Жыл бұрын

a lot of people got mad at canonical for making Firefox a snap when Mozilla itself asked them to xd

@TheLinuxEXP Жыл бұрын

Yep. Saves so much time!

@cameronbosch1213 Жыл бұрын

Because Snaps suck and have a proprietary backend.

@damianateiro Жыл бұрын

@@cameronbosch1213 snaps were made for servers and are widely used there, but you won't find companies like google, microsoft, brave, opera, or even spotify having OFFICIAL versions of snaps while flatpaks are from third parties, the format is open source, snapcraft is proprietary, and if you are going to cry over something proprietary I don't know what you are doing on youtube and using a smartphone or a pc x86 ¯\_(ツ)_/¯

@frederickwood9116 Жыл бұрын

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.

@EHKvlogs Жыл бұрын

I am using debian 12 with flatpaks. It is so good experience.

@truthdoesnotexist Жыл бұрын

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

@TheLinuxEXP Жыл бұрын

Yep!

@justcatu9107 Жыл бұрын

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

@truthdoesnotexist Жыл бұрын

@@justcatu9107 what distro do you have?

@Jammet Жыл бұрын

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.

@TheLinuxEXP Жыл бұрын

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.

@monkev1199 Жыл бұрын

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.

@Jammet Жыл бұрын

@@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.

@rayancarbine6386 Жыл бұрын

With these sponsor transitions, I swear he's turning into a Linux version of Linus tech tips

@yiannisspanos694 11 ай бұрын

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.

@bjugler Жыл бұрын

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.

@TheLinuxEXP Жыл бұрын

In this case it is better though

@UhhStryfe Жыл бұрын

easier =/= better

@TheLinuxEXP Жыл бұрын

In this case, it’s both

@UhhStryfe Жыл бұрын

@@TheLinuxEXP For some use cases, maybe. Respectfully, while I understand that common libraries are shared between Flatpaks via Flatpak runtimes, there are still concerns. Disk space usage is higher. Running apps in a Flatpak sandbox can introduce performance overhead compared to running directly on the host system. Libraries that are included in Flatpaks can potentially be out of date and its possible for updates to the system libraries to not automatically propogate to Flatpak runtimes, introducing security and performance concerns. Flatpak sandboxes can also limit the integration between the application and the host system. All in all, I'm perfectly happy with the rolling release model currently being used by my distro of choice and will not be adopting any of these changes in the near future. This model you're proposing doesn't appeal to every user. While it could make sense for 'just works' distros, I don't believe distros should widely adopt this model moving forward. Love your videos, Nick. Hope you can see where I'm coming from.

@culturedgator Жыл бұрын

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.

@khaledmuhammad9270 Жыл бұрын

It is been two years, and I am watching every single video of you, I really love your videos alot. I am addicted to your videos as I am addicted to Linux. 🥰