Linux Package Distribution Model Is Changing
Vložit
- čas přidán 8. 09. 2024
- For the longest time every distro packaged and repackaged the exact same software, but we're entering an age where this model is being replaced and that's for the better, allowing this developers to focus on more important problems
==========Support The Channel==========
► $100 Linode Credit: brodierobertso...
► Patreon: brodierobertso...
► Paypal: brodierobertso...
► Liberapay: brodierobertso...
► Amazon USA: brodierobertso...
==========Resources==========
Jorge Castro Blog: www.ypsidanger...
Ubuntu Releases: wiki.ubuntu.co...
=========Video Platforms==========
🎥 Odysee: brodierobertso...
🎥 Podcast: techovertea.xy...
🎮 Gaming: brodierobertso...
==========Social Media==========
🎤 Discord: brodierobertso...
🎤 Matrix Space: brodierobertso...
🐦 Twitter: brodierobertso...
🌐 Mastodon: brodierobertso...
🖥️ GitHub: brodierobertso...
==========Credits==========
🎨 Channel Art:
Profile Picture:
/ supercozman_draws
🎵 Ending music
Track: Debris & Jonth - Game Time [NCS Release]
Music provided by NoCopyrightSounds.
Watch: • Debris & Jonth - Game ...
Free Download / Stream: ncs.io/GameTime
#Linux #Ubuntu #Flatpak #Foss #OpenSource #LinuxDesktop
DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase I may receive a small commission or other compensation.
Glad flatpak is gaining traction, it's really inefficient to have every distro spend time packaging the same software over and over.
And not to mention, think about this. When you hear something is available on Linux,
you also need to check what distros it's available on, while on basically every other system
all the user has to worry about is their OS version not being too old. It's true for Linux sure
but depending on the distro maintainers means that's a shot in the dark
As an end user, I mostly prefer to get flatpak versions of things not just because it's a one size fits any distro application solution, but because I can be sure it ain't touching anything I don't explicitly allow it to in flatseal, and I know it's working because of how many times I have to add a directory to flatseal permissions. That may be an inconvenience at times, but it tells me with certainty things are working as they should be, and gives me more peace of mind with web browsers and chat apps. It also works on immutable distros, so say I wanted to switch to fedora silverblue or steamOS whenever valve decides to officially release it, I'd be able to migrate easily.
Two things keep it from being _perfect_ for me off the top of my head: Sometimes you NEED sudo permissions flatpak just can't get, such as being unable to install SteamVR in steam's flatpak due to inadequate sudo permissions. While I _genuinely_ appreciate the security, I also don't want to be outright blocked from doing things just because I prefer using flatpak, so I hope in the future things get updated a little in that regard so problems like that don't arise anymore. Another thing is I want to be able to install a flatpak and all it's functionality/permissions exclusively to a secondary drive, instead of it occupying space on my root drive partition, to save space. Basically being like appimages in that you can just carry them around like .exes on a separate drive. I'm maybe missing something obvious, but I'm not sure if you can even do that.
*Luke Smith screaming in the distance*
@@RadikAlice Compiling from a source code is available on any distro.
@@finoderi True, and there are a lot of projects that I've compiled from source just to use them because I'm on Slackware. Of course, that also means I can't use anything that's a FlatPak, something which hasn't bothered me enough to get it working yet, but may in the future if everyone shifts to that as the distribution method.
having a universal packaging format would be a huge step for linux desktop adaption as it would simplify many things and streamline it across different distros
That's called Gnome Software /s
@@carlod1605 well im aware, but things arent streamlined yet & on basically any distro you still have to make the choice of using either the flatpak or the distro specific package (which might confuse people who are new to linux)
I much prefer flatpaks but I must admit that snaps has benefits over the others. Snaps actually can be a true universal packaging format. Which includes GUI apps, server apps, cli apps, services and core apps. I don't believe flatpak can do those things. Hopefully at least not yet.
But... Muh gatekeeping
For apps it can make sense, but I've seen people propose distributing GPU drivers in a flatpak which makes no sense
Containerization makes the most sense for desktop and web apps since they rarely integrate with the system and may have conflicting dependencies for the latest versions.
I've always wondered why this wouldn't happen. Every time someone tries something, Joe Blow that doesn't put any money on the table, chest thumping that he doesn't want to pay for software, starts complaining like a madman on any outlet that will take them. I think it's a good thing. Have people concentrate on the fun stuff.
Because flatpacks suck
@@ukyoize "flatpacks"
@@ukyoize Why do they suck?
Any kind of standardization would be welcome. Said something along these lines back in 2008.
@@ukyoize What's the better option?
To be a valid option you need a package that you can make once, and it will run everywhere, forever, and won't break with system updates. So if a get a package made today, it will still install and work for at least 20 years.
So tell me: What's better than a flatpak in that?
You can generate DEBs and RPMs from GNU Guix package definitions. Why people might not want to do that? Because these packages won't follow the way Debian | RHEL | whatever wants its software to be packaged.
Packaging stuff is basically the whole point of a distribution. Yes, some distros are only focused on the base operating system infrastructure and are a-ok with apps being delivered via Flatpaks. That doesn't mean every distro should be like this tho
Every distro *should* be like this. Otherwise you end up with *literally* hundreds of different versions of one app, with each maintainer putting the responsibility onto the application developer. That isn't sustainable. Having one copy of the app for all distros and minimizing the differences in environments is way better, long-term.
@@oro6768 But some people _want_ to use minimal packages Alpine provides. Some people _want_ to use declarative packages NixOS and GNU Guix provide. Some people _want_ to stay on old, non-changing packages (with security backports) that Debian provides. And yes - some people want to use no-hassle Flatpaks on Fedora.
This diversity of choice is beneficial and is here because many people want it.
Yes, there are pointless distros out there. Yes, backporting software to numerous LTS versions of Ubuntu is suboptimal. And yes, new people should stay away from specialized builds. But it's up to distro maintainers to decide what they want to distribute and up to users to choose what distros and tools they want to use.
Trying to forbid this choice is antithetical to Free Software.
@@mskiptr " This diversity of choice is beneficial and is here because many people want it." and you can now have your software support revoked, all because you wanted to run an application in such a way that it broke everything. Just because you can do something doesn't mean you should; constantly repackaging an application natively is one of those things.
@@oro6768 Yes. Freedoms to modify and share Free Software aren't entitling users to free tech support.
Running known-broken builds is a bad idea. The developers shouldn't be forced to fix bugs that surface only in custom builds. But they aren't forced to fix any other bugs either. They choose which bugs to work on on their own and that's fine.
However, it's disrespectful to close high-quality bug reports because the submitter used something custom. When there are reproduction steps, at least check if the bug is present with your officially blessed builds. If the problem really appears only in these custom versions, it's fine to say you're not gonna work on that. But if someone else figures it out and fixes it, do not ignore their work just because the bugs weren't showing up in your version.
@@mskiptr " However, it's disrespectful to close high-quality bug reports because the submitter used something custom. " The user used a custom environment that was explicitly not supported, there is no obligation at all to fix that. Especially when chances are that it's a distribution-specific error.
I've used flatpaks for a few years now for most of my daily apps. They have a lot of potential and I'd love a future Linux desktop where apps can all have permissions managed in a central settings app. Installing and managing apps is one of the most confusing things for average users IMO, something like Flatpak makes Linux easier to recommend to less nerdy friends :)
You mean like, ummm... a registry?
@@kitsuneneko2567 more akin to something that we already have on android (or iOS), where you can give and take any permission that an app might ask for or want
I've been starting to use them a bunch for graphical apps. Pretty much my only reason for doing so is the ease of sandboxing (with Flatseal to finetune the permissions). Pretty much my only major reason not to do so is that stuff aren't built from source and optimized for my machine, but eventually I'll get around to automating that and cloning and building them from source with the manifest file myself, or get a nice Firejail + AppArmor setup and then anyways discard flatpaks to build from source.
Fuck flatpak putting stuff in ~/.var though - .files are fucking horrible, and I don't need yet another stupid dir in my home dir.
Isn't that what flatseal does?
@@juipeltje flatseal has a very limited permissions system. In fact, you can't even e.g. give an app access to a specific camera - but only to that specific camera, not the others. Additionally it only supports raw file paths (with some special ones like xdg-config, but no globbing or other more advanced capabilities), allows you block only all or no "development syscalls", similarly doesn't allow you to allow only specific IPC, etc. You also have to restart an app for changes to take effect which is a huge problem - frequently, I only want to e.g. allow an app to access the internet at a very specific moment or only want to allow it to use my camera when I'm actually doing something with it, and don't want to or can't restart it to disallow that permission from that point onwards. The list of limitations goes on.
"Isn't it lazy?" Well yeah, if you ever meet a programmer or sysadmin who isn't lazy they probably aren't great at their job.
Well.. Yeah, I mean computer programs exist to simplify tasks... Humans invent stuff to make their life easier...
Progress is based on laziness!
No. Lazy programmers make shitty code that bloats up your experience.
@@ukyoize You're talking about bad lazyness aka lack of competence.
Good lazyness = efficiency.
Half of my familiy is in programming (i know it's odd), and they all told me that smart lazyness was essential to be good in this field.
@@ukyoize you're mistaking lazy programmers/sys-admins with lazy coders. Lazy coders copy-paste whatever, often producing stuff even they don't understand. Lazy programmers prefer to spend some extra time and brainpower setting things up the first time they do something, just so the second time and onwards they have a way to do it quickly, safely and effortlessly. Copy-paste habits just don't cut it in that kind of work 😅 .
@@ukyoize I am a lazy programmer... as lazy programmer, i automate everything that could take more than 10 min to do manually in 5 hours....
for example... i worked for l1 ticket triaging for 1 year... i automated most things spending few months, where my non-lazy coworkers still doing manually (yes those people i didn't shared that scripts with)...
I never really saw the value of flatpaks until I got a steamdeck. Same with using docker/podman containers on desktop distributions and not just servers.
Now I'm genuinely considering using an immutable distro to manage the system and doing the bulk of my work within containers and flatpaks. That, or NixOS. It's a tough call.
Meme idea: UNHOLY usage of Linux From Scratch as an immutable distro
I think the NixOS approach is going to end up as *the* alternative for those wanting reduced bloat, especially if Nix gains a way to create a derivation from a Flatpak manifest.
Your meme idea is Not nearly as hard as it seems
It pains me that people argue about distro packaging, flatpaks, snaps and even appimages while Nix is a thing (talking about the package manager, not NixOS).
It's a genius approach to package management. It blows every other package manager out of the water in the amount of packages available, you can have multiple versions living alongside each other, it's distro independent, you don't need to download a 1000mb runtime for a calculator, you can compile your stuff from source...
Flatpak might have the benefit of sandboxing, but the fact that it doesn't atleast get brought up in these discussions is beyond me.
Nix is better suited to power users, not end users. Flatpak works best with end users. Before you try and argue this, yes, I have tried Nix; it is in no way a viable replacement for Flatpak, at least in its current state. When it supports everything Flatpak does, in the simple way Flatpak handles it, it will be a viable replacement for desktop applications. But not before.
Also noting that with Nix, you still have do "download a 1000mb runtime for a calculator", it's just reused across Nix packages.... which is also exactly what Flatpak does for runtimes. It's not as bloated as you think it is.
Agree, it is made to actually deal with packaging issues and not security issue.
I have been waiting for so long for Brodie to even acknowledge the existence of Nix as a package manager that provides much of what Flatpak does and more.
There is also GNU Guix now, which seems like a future for me.
It's more user friendly, than Nix, doesn't use containers, so is more performant then Flatpak and is a part of GNU, so it can easilly became a new standard (usually fully Independent systems are in much worse position here).
@@angeldude101 not having sandboxing by default automatically knocks Nix to the bottom of my "package managers to use" list. I don't want malware to get outside of my app and affect my whole system. The fact that this was close to happening (fractureiser) shows just how important sandboxing is.
I largely agree.
One concern I have... In their attempt to make sure every distribution looks the same and to protect the OS from the application, flatpak used to (and may still, I haven't checked for awhile) make sure /bin and /use/bin were standardized and minimal.
I tried using the PyCharm flatpak. I then discovered that I could no longer use certain tools (like Mercurial) that I'd installed on my system through the distribution package manager.
This model appears to work poorly for handling systems of end-user applications that depend on each other. For Libre Office, this mostly isn't a problem (at least, not for me) but for just about any serious development tool, it very definitely _is_ a problem.
Another problem this creates is a monoculture problem that makes it much easier to target certain commonly used programs with certain kinds of exploits. When you know the exact binary being used, it's much easier to turn a buffer overflow into a usable and broadly applicable exploit.
My only two concerns would be security, like permission annoyance, and the look and feel of apps. As long as they respect my dark theme or have one built-in that's good, the look and feel I'm sure will be fine. The security features aren't always necessary, but as long as it's not too onerous I wouldn't care about that extra overhead.
Yes, you can't use tools from your host system inside of the Flatpak env because they have two completely incompatible sets of libraries. Flatpak isn't really suited to development tools anyways, not unless they actively take the sandbox into account (like GNOME Builder).
And on targeting certain exploits: they would still be harder to abuse inside of a sandbox. Hell, the recent Minecraft/Java malware was completely ineffective inside of Flatpak in the first place because of it. You get the best of both worlds: bug reproducibility and security.
@@oro6768 - It may well be that the monoculture issue is significantly outweighed by the security the sandbox gives you. I'm just saying that it's a consideration.
People have been using Docker for dev stuff over flatpak. Still containerized, but Docker makes intentional considerations for development workloads.
yes you cant access tools from outside of flatpak (this is where we still need to improve like easy extension of flatpak or easy connection of flatpaks together) but simple thing is you should not be able to just have access to any old binary outside of that flatpak. This is all security considerations and the thing you need to weight on the scale to make perfect thing. just like total open world wild west isnt good total lockdown isnt either we all need to balance the scales correctly
extensibility is a great thing about docker/podman its super easy to extend. in theory extending snap by getting into its environment and apt installing things is easier but thats not a workflow we should point other humans at
As long as a flatpak will do everything that a repo package does, then I'm all for it. If you are having to pay people to get work done, you don't want to have them working on menial tasks. Ask any boss and he will tell you, LABOR is the biggest cost of running a business. Around these parts, we tend to like free software, so cost cutting is a big deal.
"As long as a flatpak will do everything that a repo package does, then I'm all for it."
But flatpak already creates more bloat than a repo package does - so you can't be all for it. Unless bloat is something you will make an allowance and exception for.
@@terrydaktyllus1320 Oh no, bloat, we're all gonna die 😱😱😱
@@Blueeeeeee I stopped painting little pictures around words that I write when I got to age seven and first learned joined-up writing. Just saying...
Sonny, not all of us have rich mummies and daddies that buy us a new computer each Christmas just so we can run the next bit of DLC for "Cybersplatt 4044".
Some of us know how to build computers efficiently, that's what "engineering" is.
You're welcome, you can thank me later.
It will never do everything a repo package does. That's not what it's for, at least not flatpak. Flatpak is meant for graphical programs. You can access some CLI tools with it, but its restrictions was built for GUI programs first, everything else second.
On the other hand, it also means that it's focused. It's focused on getting GUI apps shipped across distro, bug-for-bug, in a secure and reliable manner. System packages are always going to be handled by distro maintainers, but for everything else? Developers can just ship directly to flatpak instead of dealing with the headache of figuring out packaging, testing, and shipping to different distro or even _which_ distro.
@@terrydaktyllus1320 Sheesh, chill out dude, Arch and AUR isn't going to disappear tomorrow. People are still going to hack and tinker around for that kind of thing. It's just that some of us don't really want to deal with that and want an option that do work with our setup and hardwares (most of which are probably from the last 10 years, or upgraded with the currently very cheap RAM and storage for modern standards, and can handle the neglible penalties that containerized solution offers).
“Work smarter, not harder.”
"Work lazier, not stupidier"
My biggest concern is putting all of the eggs into one basket. Nothing is more frustrating than being reliant on a single entity and for some reason losing access to their stuff.
The thing is, by design, you *don't* put all your eggs into one basket with Flatpak. The developers should control how their app is packaged, that means having a local build recipe for things like nightlies or CI. If Flatpak didn't support this, then it would just be another Snap.
i made a long post here and this was one of my issues ... EVERYTHING is on Flathub which even if it doesn't fail but just has tech issues ... then "every distro" is in trouble at once.
@@Xmetalfanx that is a good point, although we have had the same thing in the android space with f-droid for a while as well.
@@Xmetalfanx FlatPak supports other distribution channels. I hope app developers all make their Flatpaks available outside of Flathub.
I switched to Linux for several reasons, among other because Windows was much too slow for me (i5-750 up to 2019) and wasted too much memory (480 GB SSD back then). I am not jumping of joy from containers replacing properly packaged software. The software usually starts (much) slower and wastes (much) more memory, if for no other reason because you have the same dependencies installed multiple times on your system. For me it is a nightmare-scenario, Flatpak replacing properly packaged software.
you'll be fine with a 480GB SSD
flatpak is properly packaged software imo its more proper then what you call properly packaged besides 480GB thats plently my laptop has 256GB
@@jaimiepotts7638 Just because they have some space on their drive doesn't mean that they like to waste it. Also, you haven't adressed the speed issue.
@@ukyoize it is a none issue because start up time difference is hardly noticeable
Containerisation on desktop is for many purposes just a worse way of getting the dependency resolution of statically linked binaries without actually linking statically because glibc really isn't static compilation friendly.
There are some other benefits as well. You can deal with glibc without containers by using another libc or another language, but things like opengl, cuda, opencl, etc cant be statically linked. Flatpak for example also provides gpu drivers so it makes it much easier for developers to deal with when all users use the same driver versions, as it can be very hard to test all different driver versions for all different gpus (and some distros like to use very old drivers for some reason, and in such cases you can only tell the user to switch to a more up to date distro or manually install newer driver).
I have seen amd/intel drivers behaving very different in old drivers compared to new drivers. I had to make it work for both because not everybody uses flatpak and some people use distros with old drivers, but I wish I didn't have to do it.
At least, with Flatpak, it can deduplicate the bundled libraries, so it's not really static linking. Static linking is a completely different thing. If you want to call this static linking, then I highly recommend you to look into how it *actually* works.
statically linked can cause license problem with the GPL i think
@@notuxnobux For stuff that uses dlopen-able plugins (such as glibc's NSS) it *might* be possible to statically-link against the plugins by using libtool, a very old GNU utility that was originally intended to simulate the dlopen/dlsym API on operating systems that didn't support shared libraries at all.
However, some APIs/frameworks -- especially large and complex ones -- consist of more than just libraries, but also files of other types (e.g. read-only data files such as graphics or config files, libexec executables, etc.), and filenames of those other things probably don't always change from each minor-version of the API to the next one. That makes it impossible (in the general case) to have every possible combination of different versions of the same dependency present within the same "prefix"-directory at runtime... *unless* the kernel presents different views of the filesystem to different running processes, and Flatpak uses some kernel features (mount-namespaces, tmpfs) to do just that.
Another package manager which aims to solve the parallel-installability problem in the general case is Nix. Unlike Flatpak, Nix installs each built-version of a package into its own separate prefix-directory, with part of that directory's name being a secure-hash of the data from the "source package" used to build that package such as its dependency declarations. This approach requires Nix-specific changes (i.e. patches) to be applied to certain pieces of software in order for them to work correctly when packaged in Nix. (Nix is about 12 years older than Flatpak -- i.e. it's only about 1 year newer than Linux's mount-namespaces kernel feature -- and it also supports some other OSes such as macOS / Darwin. This probably explains why it doesn't have a hard dependency on OS-level virtualization technology in the way that things such as Flatpak, Docker, Podman, etc. do.)
Maybe I don't fully comprehend this move, but it looks like a move away from shared libraries, and toward monolithic packages with libraries contained individually within. If that is the case, it looks like it will be colossally expensive to do very simple things on Linux in the future. Pending more information, count me adamantly against it.
Flatpak doesn't move away from shared libraries entirely. Its concept of a "runtime" can be thought of as a coarse-grained dependency: a collection of multiple shared libraries together with other files (e.g. config files, libexec executables, dlopen-able plugins) needed to use them. (For example, there's one runtime for the entire KDE Frameworks API, another one for the GNOME API, and one more of them is the "Freedesktop" runtime which consists of a smaller set of important libraries such as Gtk3 and libdbus.) To makes things a little more fine-grained, it also has a concept of "runtime extensions" for certain other libraries (such as Mesa and VA-API); the intention for a Flatpak-packaged app to declare a dependency on one "runtime", and on some extensions to that runtime if necessary, and if any other libraries are necessary then bundle them into the app's own package.
The *really nice thing* (from the end user's perspective) is that Flatpak supports having different versions of the same runtime installed simultaneously. That used to be one of the main pain points on Linux: without presenting different views of the filesystem to different running processes (note: certain relatively new things which Flatpak uses, such as mount-namespaces and bubblewrap, have improved Linux's ability to do this kind of thing beyond what the old chroot(2) system-call was capable of doing), it's not possible for every different version of the same dependency to be installed within the same "prefix", so if a user wanted to install a version of some app that was either "too new" or "too old" for their distro, then they'd have needed to manually build and install lots of that application's dependencies along with the application itself into a custom location (e.g. a subdirectory of the user's home directory, or a subdirectory of /usr/local, or a subdirectory of /opt).
(Or, on RPM-based distros from circa 2000 -- e.g. Red Hat Linux 6.x - 7.x, versions of Mandrake from the same time, etc. -- what users who didn't know any better sometimes did instead was to grab a bunch of RPMs off of rpmfind and install them. This was one possible way to get a newer version of some app to run on your system, but at the expense of turning your installed system into a patchwork mess of stuff from different versions of the same distro or even multiple distros, which obviously could cause serious problems!)
See also: the Nix package manager (and NixOS), which uses a more fine-grained dependency model, but also ensures that multiple versions of the same dependency can be installed at the same time -- just like how Flatpak supports having different versions of the same runtime installed at the same time -- without any filename/pathname conflicts.
Packages is also about how to fragment/bundle software. And grouping of packages. There is not always 1-to-1 correspondence of open-source product and package. E.g. packaging bundled plugins separately or keeping them in same package with main app. Or collect multiple products to place in same package.
Flatpak supports application extensions for exactly this use case, and it's utilized by OBS and Steam right now. It's pretty useful for those apps that are plugin-based.
The problem here is that it's going to become harder to find some packages in official repositories without having to install some "muh contaaaaaaainerrrrr" (just imagine someone jumping up and down with mouth agape in excitement) runtime that occupies overhead I probably don't want to include in my system. On one hand, I could just move to Gentoo and compile everything from source, but that is definitely not a trivial way to daily drive a system.
There are better ways to automate deployment to multiple distributions than working with containerization. In fact, many of us have developed ways to do that. The reason why those ways have not been adopted is indeed a level of laziness that has brought us to a present where we have to buy more expensive hardware just to run the exact same software we used to run on top of 3-4 GB of DDR2 memory. Not everyone is incredibly attached to consoomer culture to just shovel out their old system and replace it with a new one every time some application decides to go "shiny," abandoning a perfectly functional GUI for some matte minimalistic (and frankly cool) look that occupies WAY more memory than it really has any right to. Not everyone can afford to buy these new systems every few years, either. We're going to have to wake up to the reality that software should not trade away usability for the sake of making development easier.
Maybe we'll reach a point in the near future (hopefully) where those of us who learned to code for machines that operated under constraints retake the reins.
With respect and love,
~ A driver developer
As someone on the outside of the whole Linux thing because I'm still on windows....it's kind of insane to me that something like flatpack isn't already the standard. I thought that people on Linux liked to optimize things, so why would so many distros waste time doing the same thing when they could be working on far more valuable and important features?
Sometimes Linux has very very odd priorities, but hearing that things are changing in this direction gives me hope that I won't have to deal with Win 11 when Win 10 support ends. Because that's my deadline. Until then I just poke around to see how things are actually going. And this article gives me a lot of hope becuase it's voicing exactly what I've been thinking for a long time
Simplifying user experience and saving developers time are great, but they aren't really "optimization" (at least not of the system itself). The nature of these containerized packages means they're specifically _not_ optimized for a given system, and less efficiently use system resources, however these downsides are less and less noticeable on modern hardware making the trade-off more practical for most users nowadays
Because it's a sledgehammer to a nail solution, over enginering a solution which will bring more issues like it not running as quickly or efficiently like natively run program, which Mac and Windows will continue to do, they won't be using an abstraction layer to run programs.
They bloat and run slower than native.
Win 11 is godlike. I left linux for win 11. The windows terminal in particular is slick.
@@supremespanker For peak irony s/Windows Terminal/conhost.exe/
When I started using Linux 2 years ago, I saw snap as "that annoying peace of software that I need to use besides apt to get discord and firefox".
Fast forward to now, and I am considering switching to an immutable distro. So yeah, I couldn't agree more with the title.
I can't understand why so many people are okay with putting critical display drivers and gimp in the same place. I don't want to break or clutter my system by installing something like gimp, onlyoffice, or whatever. I don't want to worry if my system will boot after updating (talkin to you arch) I am a silverblue user and I use nix, flatpak, and containers for apps while I just install drivers with rpm-ostree.
As a concept, I love the idea of software maintainers and package maintainers having less work to do, or being entirely unnecessary... Flatpak and snap are not ready for me.
My complaints, from first hand observation are:
Delayed Start-Up
Slower Performance
High Resource Utilization
Filesystem navigation issues (i should not have to manually navigate to my Home directory after clicking "Home" in a file dialog, as example)
I'll continue to try them out as time goes on, hopefully things improve, but I paid a lot of money for my computer and I want to squeeze every ounce of performance i can get out of it, which in this case means squeezing out Snaps and Flatpak..
Slower startup is not as big as a problem with Flatpak as with Snap
Slower performance is not really a thing, after launch the app works the same
Hugh resource utilization: yep, shared memory is used less so more RAM is used.
Filesystem navigation is a problem that should be fixed on per-application basis, they should stop using toolkit file picker and switch to using the portals. That would be a good thing even without containers, as you will get KDE file picker on KDE with GTK software and vice versa
C'mon man stop being a diva. Linus uses it, you can too.
In general, I agree that this container thing is probably a Good Thing™. That being said, it is my personal belief that distros should still package a web browser separately from whatever package management solutions they focus on. It doesn't necessarily have to be full-fat firefox or chrome or whatever. Even something as basic as dillo would be fine. Just something that is always there and always available to let you google search in the incredibly rare but actually possible situation that you manged to somehow break snap or flatpak or whatever.
Storytime: Some time ago (last year), I was involuntarily stress-testing my backup solution (read: drive failure, don't buy cheap SSDs - get the name brand stuff from a reputable retailer). Backup successfully restored (yay!). Unfortunately, I had mis-configured my backup solution and through a convoluted series of steps I ended up with a system with broken snap support. All of the snaps were installed, but they weren't installed right. I couldn't install them because the system believed them to be installed already, and I couldn't uninstall them because the system thought they weren't installed. Firefox wouldn't run (Because it's a snap now!). Good old dillo to the rescue... downloading the binary release of firefox for linux. Just got to extract the archive, copy it to /opt/firefox, symlink it to /usr/local/bin and now I have a firefox that doesn't rely on snap. (or flatpak, or even apt!).
Anyways, I eventually figured out how to fix snap. The short version is I manually mounted the squashfs files, removed all my snaps, used apt to remove and purge snaps configuration, then just installed flatpak instead because manually diagnosing and fixing snaps was more frustrating than the time I tried to cross-grade a 32-bit Debian system to 64-bit (pro-tip: don't do that either. Just reinstall, save yourself the time and headache).
The important takeaway from this: snap needs to have a reinstall option that deletes and installed snap and then reinstalls it fresh. Do better, Canonical. Flatpak is okay too.
All Debian derivatives share packaging format yet each maintains own packages for each supported version.
The hard part is dependencies, usual system ships package for each base - flatpak, docker, nix ships dependencies for each package.
As a developer myself, why should I do work that doesn't need to be done? If the Flatpak does the job, why would I make native packages for each distro and its releases. I can spend that time implementing new features.
_You_ shouldn't. That's the job of maintainers for distros that want custom packages.
@@mskiptr Then the maintainers of those distros can provide all the support for the application, don't redirect everything to the application developer. By packaging natively, that's the responsibility you take on. You can't guarantee that the environment will be the same for everyone, so you support your own environment, don't bug upstream.
But OF COURSE people don't follow this and submit bug reports upstream anyways!
@@oro6768 Exactly
A big issue with doing things _like this_ is there is a lot of existing Linux information which demonstrates use of package management commands that will no longer be relevant. This also doesn't bode well for people who are using _extra-small_ partitions for root and / or home.
Then again, I'm old-school. I had been using Ubuntu since '09 and only recently hopped onto Arch because I immensely dislike Ubuntu shoving snaps down my throat. All i see containers doing is making it more difficult to keep Linux working with a 32GB root, which is _just how I like it_ because then it's dead-simple to back up, and any overflow is stuff I can use symlinks to deal with as-necessary until I expand my root. Then again, I also like the idea of having root backed up on inexpensive USB media.
This might be a great video idea Brodie; show the used space difference with _like-for-like_ user software packages. If it's par enough that might be a compelling reason to switch away from shared libraries and native packages.
There will always be special case distros for weird systems like that, I wouldn't be too worried
I don’t understand why this is such a uniquely Linux problem. Why can’t Linux software producers create binaries that work on whatever is the lowest common denominator for Linux distros? Why does containerization need to be the solution?
Because dependencies are incredibly difficult to deal with when you have distros that still support with 4 year old packages and packages from yesterday
@@BrodieRobertson The situation is similar in various other ecosystems like iOS, no? I haven’t done any iOS for years but, the way I remember it, I could tell XCode which range of OS versions I wanted to target and then I’d just write my code so that it didn’t use features that weren’t available in all the iOS versions I wanted to support. One binary was produced and nobody at Apple was doing any building or packaging of the app I produced.
It’s probably because for many packages, there is no lowest common denominator. Software is always changing, and packages are always making breaking changes as they get patched and changed.
At least with flatpak, developers can agree to a set of software versions to target to ensure it works on all platforms.
@@umutsevdi1241 By X11 do you mean the server? Can you package an X server in a flatpack? Can you package systemd in a flatpack?
I'm pretty sure that it *does* happen on other OSes sometimes. Here are some examples:
- One of the most notorious forwards-compatibility problems between different Windows versions: some XP-era games used StarForce's copy-protection scheme, which required its own custom device driver (which runs in the kernel / supervisor-mode, isn't that correct?). According to what I've read, this made the games incompatible with future versions of Windows. (And, even when running on its intended Windows version, it could cause system crashes or other problems, such as, according to one report I read, *hardware damage* to certain CD/DVD drives!)
- A Macintosh backwards-compatibility problem example: there used to be a WebKit-based browser for Mac OS X named Shiira, and I remember being unable at one point to run it on one particular computer because the app required a newer version of the operating system -- or, most likely, one particular library that's part of the "base system" -- but upgrading the operating system wasn't an option because it wasn't my own computer. (By contrast: on some occasions before Flatpak existed, I remember using Debian Stable to run newer versions than were packaged in the distro of certain apps... ISTR that Krita was one of them... by building the app and its dependencies from source and installing them into a user's home directory. Time-consuming, yes, but it least it was *possible*.)
- A Macintosh forwards-compatibility problem example: some Macintosh games circa 1990 (e.g. from around the era of versions 6 and 7 of classic Mac OS and the II, LC, Color Classic hardware models) would display incorrectly unless run in the correct video mode, and later on within classic Mac OS's commercial lifespan (e.g. the era of Mac OS 8 and 9 and the "beige G3" model) the necessary video mode was no longer available.
- In the present day, it's a common practice for Windows apps to bundle any needed library dependencies that aren't part of Windows's "base system" into the app's own installation directory (or, alternately, to statically link to them), but this hasn't always been the case. For example, QuickTime for Windows is (or at least used to be) distributed using its own installer app which would install it systemwide... and I can remember two different Windows games, one from 1994 (Critical Path), the other from 2003 (Escape Velocity Nova), each of which required *a different major version* of QuickTime for Windows. I'm not 100% sure whether or not it was possible to install those 2 different versions of QuickTime on the same PC simultaneously (because I installed the games on separate PCs from each other). ISTR that Adobe AIR was another "systemwide-installed" dependency like this. (On a side note: for commercial native-Linux games from places such as such as Steam / GOG / Itch / Desura before it went out of business, isn't it true that they use a similar library-bundling approach: i.e. except for a few specific system-provided libraries -- maybe just libc and libGL? -- all library dependencies are either statically-linked or bundled into a directory which is then used as the library path when running the game by some mechanism such as rpath, LD_LIBRARY_PATH, or similar. I suppose AppImage-packaged apps do something like this too, though I'm not all that familiar with it...)
EDIT: forgot to mention w.r.t. the last point mentioned above that this problem -- i.e. "DLL hell" -- was especially bad on Windows 3.x (and maybe on 9x/ME too), probably because non-NT Windows didn't have any "unprivileged user versus administrator" file permissions. Back then, it was fairly common that the act of installing one app would install some of its dependencies systemwide (maybe without explicitly telling you that it did that), possibly *replacing* previously-installed versions of the same dependencies, which could break other applications that were installed previously or cause them to behave differently in certain ways. For example, I remember one time when I was using some app, brought up the print dialog box, and saw that it had changed from when I'd first installed that application, even though I hadn't updated that specific application. Similarly, I remember one time when I'd reinstalled Windows 3.11 from scratch, and noticed that this caused a version of Windows Media Player to be installed that was *older* than (and had major UI differences from) than the one that had been preinstalled on that PC... but later on, when I installed some other application, it installed the more recent version of Media Player.
(Side note: Wikipedia mentions that, on Windows XP, " _users by default receive an administrator account that provides unrestricted access to the underpinnings of the system_ "... and PCs in office settings where Active Directory was in use wouldn't have been using that default behavior, but most home users probably did use it. That was probably for backwards compatibility with apps/installers from non-NT Windows versions that assumed they could write files anywhere, and so I suspect that "DLL hell" wasn't entirely a thing of the past even after non-NT Windows was gone. Even on Windows 10, I encountered one archaic app -- Corel WinDVD -- whose installer assumed that it was running with administrator privileges, and didn't support the User Account Control introduced in Vista to prompt for an administrator password, therefore the installation process would fail if you ran it as an unprivileged user.)
This is the traditional space-vs-speed tradeoff. In this case, it is spending extra computer space storing duplicate copies of libraries in exchange for reducing human time spent chasing down dependencies. That tradeoff is generally a good one in a world where TB+ SSDs are $50.
There are two problems. First is what happens when a software stops being made available, likely when the project upstream dies? I can currently grab linux programs from 20 years ago and _usually_ get them running against updated libraries with minimal fuss. Of course, if the source code is available, you can still compile those abandoned things manually, so this isn't _really_ going to make things worse.
The bigger problem is where he says to just report bugs upstream and get them fixed for everyone. I report bugs to two projects: Gentoo and the kernel. Because those projects actually respond to bug reports and address them within a year (may or may not _fix_ them, but you've had eyes on them). With other projects, the vast majority of bug reports languish until the next major version comes out, and are then closed by a bot saying that as part of the re-write they are _guessing_ the problem is solved. If it is not, please reopen or file a new bug report. At that point, it doesn't really matter if the bug reported got fixed or not, if it did so, it did so accidentally. Reporting the bug did nothing. Oh, and in the majority of cases where this has happened to me, the bug wasn't even successfully fixed.
The reason that people report bugs to distros, and that distros apply the fixes locally, is because upstream often has glacial release schedules coupled with terrible bug handling. Fix that and distros will naturally expedite pushing fixes upstream, since they don't want to maintain large patchsets either.
" First is what happens when a software stops being made available, likely when the project upstream dies? " You can, as you already mentioned, build it from source and update the libraries yourself easily. In the event it's a binary-only app and uses an outdated runtime, you can forcefully override that to a newer runtime, though that's more a debug feature and not intended for day-to-day use.
As for bug fixes: if the application developers utilize Flatpak, they can release updates and fixes on their own time. This would knock out quite a few issues in the first place, and make life easier for developers, so you get a better bug reporting experience.
@@oro6768 I trust distro mantainers more than upstream devs.
@@ukyoize why would you? They just take what the upstream devs give them and wrap it in a specific format. A majority of them don't look at the source code unless it doesn't build. There's no vetting that the source code is safe. You can't be sure that the distro maintainers packaged it properly. You can't be sure the distro maintainers have enough manpower to ensure it's up to date.
I've already switched to Arch and flatpacks. I'm able to have the latest kernel and kde without the constant massive update downloads. With less to update natively I should have minimized the chance of problems during updates, at least that's the thought process.
i like the idea of a global, common software repository maintained with the power of all major distributions and communities, but i do not quite like flatpak. I feel like containerizing software makes it a little bit slower. Right now native packages ftw
Muh 0.0000001sec time delay. I fucking swear, you people are the worst
When they first came out, I was like, this is just what we need. I thought it would be solved with app image, but there are valid reasons why that's not working out well that I really don't feel like getting into here. Flatpaks were slow and horrible - so I did prefer native packages early on. As time moved on, flatpak has only gotten better with time. It's gotten to the point where I prefer the flatpak over the packaged version in *most* cases because then I have the most up to date version. The exceptions being flatpaks that aren't well maintained ( usually just ones that are done by a community member rather than the actual software developer ) - or in increasingly rare occaisions, ones that just don't work properly. I actually can't think of the last time I got one that had problems running properly on my system though -- but I'm sure someone out there has run into one that I don't use somewhere so I'm not ready to say they don't exist.
I could see preferring the packaged version over the flatpak version if you need some sort of governmental, medical, or financial institutional security certification - because those have to go through a long process to verify - often on very specific hardware with very specific software versions - but that's not a normal use case for most users.
While in theory I don't like containers, in reality the duplication of effort by maintainers is a waste, and for most distributions it makes total sense to use them. Also, one other benefit of containers is allowing closed source packages, and therefore big money to publish their applications for linux.
why dont you like containers they are probably the best thing since sliced bread
@@bigpodI don't like having two general package managers in one system, especially if they don't work together very well. It will lead to having to remember if you installed a thing using native package manager or flatpak, or having to have copies for use outside and inside flatpak environment.
Also, I have a personal goal to eventually fully know and understand my system, and it's another thing I don't quite understand yet.
@@basilefff but those are no reasons to not move forward, i personally think we should for now relegate apt/dns/... as system package managers and flatpak as application package managers
@@bigpod I agree. I do think containers are practical and awesome, my dislike of them is less about reasons not to use them (since I do use them) and more about real world costs and constrains causing systems to grow more complicated then they theoretically could be. I mean, I would love if every application and library could be installed and updated by one central package manager, but but that doesn't stop me from using steam or flatpak.
My PC I just reinstalled with Fedora 38 I still committed to traditional packages. But my MacBook now without MacOS, I committed to flatpaks, snaps and app-images. I will decide as I go what I will choose
No we do not need flakpack and Co. We need standardize name for programs and libs. The" One size fit all " model is a nonsense when you have a market of 4 cores to 64 cores. Packages is a prehistoric concept. Instead of wasting energy on package, we should improve the support for program to have as successful compilation every time.
i think we should do more like NixOS, but make the config files easier to make and read for non-programmers, NixOS got all the good of Arch with the new software and it is immutable and if a update "break" your system, you can just go back to the working Image, the only problem is the config files, tho .. i and other Devs find it easy, it is why don't do NixOS.
it is perfect for all your needs, maybe you should try it Brodie, maybe more people will use it then.
Whats the breaking point what make you quit NixOS as hard, NixOS need developers and in the future maybe a graphical friend interface to automatically write configuration, in NixOS is very possible, the problem with non programming people is a pressure that will create on our developers and systems costs, we need users and by now a major donator because NixOS older donator Its a institutional what decided to not participate anymore. I Think we are using cost $9000 per Month now, the major cost is building packages in Hidra ( nixpkgs ) if a understanding right its a way to test and build user packages in the cloud and share binary cache for all users( maybe wrong )
100% agree with the message brought by Jeorge. I use Arch (btw) and I like packages for all my applications and libraries. However, if I was working for a distribution, it would be a no-brainer for me to direct the company to switch to Flatpacks. It's just more efficient as a development/work point of view. As a persona point of view, I'm also quite glad Flatpacks exist; they align more nicely with the Windows user perspective of installing application which helps me bring family members and friends to adopt Linux (for their media center for example). I'm all for Flatpacks although I might never use them on my system.
They're just moving for what I developed as OS template in my graduation.
A system repo made for system dependencies, and a app store where the devs publish their products. No need for the OS to take care of user programs. As a dev I don't want them to choose what version of my program their users use.
The repos where a good solution when devs would just not port it by themselves, but now it's clear that we should stop going for a third party to get programs, and start getting a package made by the devs.
The way I see it, we'll always need the base packages for a system to not be containerized or genericized. After the base system is setup, then we'll be good to go for pretty much anything. I just think that one of the things they need to do with packages is to not link to generic names but instead have fully qualified version numbers, or at least partially qualified. Such as not linking to libabc but instead libabc-1.2, presuming that anything to the right of minor revisions won't be API breaking changes. Obviously such infrastructure would require OS support of some kind, but if we can't even agree on an init system that's going to be hard to reconcile. Let's just hope they don't form a committee to explore the possible solutions.
I'm sorry, are you from the past?
This whole versions thing has been solved for a while. Like, as far as the existence of linux is concerned, it's been solved longer than it's been not-solved.
@@Poldovico Nope, still not solved. Plenty of people still get version conflicts. And plenty of people don't upgrade their system in a traditional manner as well, as in piecemeal.
@@anon_y_mousse I'd like to hear more about what you mean by that.
Pretty much all packaging systems I know of declare which versions of dependencies they need, not just the names, and will automatically resolve them if the necessary packages are available in the repos.
@@Poldovico If you use a packaging system and nothing but, and if you update all at once, most will work fine. It's when something isn't available through your package management system that things break. And you may not always be able to cleanly resolve those issues. If you're a normal user, and not a seasoned developer, you're more likely to incur those issues and have no clue how to resolve them.
@@anon_y_mousse That's the whole point of a packaging system, though.
If you're just installing stuff that's not packaged for your distribution, you can't expect the packaging system to fix that for you.
In some cases, the person who made the software you're installing will have made sane assumptions and either given you some way to configure where they should search for their dependencies, or statically linked everything so they run standalone. If that is not the case, no external packaging system will edit joe shmoe's compiled binary to fix it.
The way you solve that in a generic way is a container, be it Docker, snap, Flatpak, or whatever else.
I would love if flatpak would have more cli or server or kernel stuff (i mean, if I am not wrong for example anbox was able to be packaged only as snap and not as flatpak because it needs some kernel modules or something like that). And alongside also I would love to still have something like appimages but better (I don't know much, but I have heard that main dev of appimages was sticking to some wired decisions, requiring to have old version of some package installed in your distro - I don't know if that is still a case).
So that is what I guess I would like to be future of linux.
I am also considering some other options, like gobo linux or nixos file structure. If I am not wrong nixos file structure can be better for some cases than gobo one but gobo linux file structure looks like it is more user friendly (I mean more understandable and easy to navigate for humans).
So I guess best option would be to have some sort of fusion of gobo linux and nixos file structure in main operating system and also this fusion of these two inside flatpak and appimages if possible. But at the same time I wonder if flatpacks and appimages would be needed if this type of filesystem would be adopted by all linux distros.
One other thing I would like to have is ability to have fully portable app and option to install it anywhere I want. So for example it would be possible to choose between saving app configuration inside app folder or saving it in sone standarized place (I guess home directory).
And this should also allow to have app on pendrive (you just plug in you pendrive to PC and you can run app from this pendrive).
These are just random thoughts, but I would like to have one solution for all of these mentioned by me problems that would be adopted as a atandard for all linux distros
I think that I will see in 5 years if Flatpak or others actually adds any value to me as a user. Debian's package repositories are fine for me. I understand the pain of having to do packaging. The only reason I would want to change is that a critical mass of user-facing software depends on something like Flatpak as a distribution medium.
I'm still one step back with flatpaks especially because they still can't package terminal applications as far as I know. So you can't have the whole system using only flatpaks. And I'd rather not rely on snaps either as their backend server code is not available and so you have to rely on that one entity to maintain all your apps.
My favourite package manager is nix, which falls short in difficulty to use and gui interfaces. It uses shared libraries where possible, which means, only when two applications have the same version of it, but each app has its own dependency tree, so it ensures that on build each app has the same environment through environment variables, limiting network access and even filesystem access, but as far as I understand it, after the build process, it is not a containerised application. And the whole packaging system is also open, anyone can contribute or create their own branch of nixpkgs.
The single biggest reason which has always prevented mainstream adoption of Linux on the desktop has been lack of industry-standard commercial software. The two biggest reasons why vendors like Adobe do not port their desktop applications is because:
(1) the low install base and;
(2) the almost complete lack of binary compatibility not just between different distros, but between different versions of the same distro. Vendors do not want to compile and package their application 152 times for every single release they make.
Love it or hate it but Windows does an extraordinarily good job of maintaining binary compatibility across a huge range of their OS versions which is extremely attractive to vendors, even though it comes at a huge cost to Window’s ability to progress and rid themselves of tech debt.
Whatever mechanism to implement the Standard Linux Binary ends up prevailing (containerisation or another solution), this removes one of the major blockers to the adoption of Linux on the desktop as it will provide the assurance vendors need in order to publish Linux versions of their software.
Of course, we may end up up stuck in the same chicken vs egg problem we’ve always faced with regards to desktop adoption (no users means no software and vice versa), but it will be one less roadblock.
The problem I have with things like flatpak is the update cycle. I know projects like OBS tell you to use the flatpak if you are having problems with it running correctly, but then waiting a good 20-30 minutes for it to update while it downloads all it's updated dependencies seems like overkill for an app that is only 28Mb when installed through the native package manager.
There is also the issue I have with some apps where it can't see my system fonts or is unable to see my files in the home directory. Getting it to see these things requires extra fiddling in the system.
I like native packages and use them as preference over containers on the desktop. Containers are used for server applications when I know a lot of people are going to be using a service.
I wish flatpak supports nightly softwares like snap do with channels, also it is easy to get other architecture ports from repo meanwhile firefox flatpak doesn't even have aarch64, but I agree with Jorge Castro that packaging of third party should move to flatpak, so distro devs can work on core part of OS. I seriously want more Unified Developer Experience
If you really want a unified developer experiance, that's Mac and Windows, trying to jam things into a container is a over the top response.
@@devilmanscott It's a perfectly reasonable response, and has been done by developers for years now. Only just now is it getting to be suitable for desktop use.
@@oro6768 It's not getting sutidable for desktop use, it's a hack, like many things sadly on Linux is especially on the desktop environment, this isn't a good idea, everyone knows it, while Mac and Windows can offer first party support for software, Linux offers a basically headless virtual OS to run a BLOODY browser.
Once you actually think about you'll realise how crazy to whole thing is.
It's something maintainers want for themselves, they aren't thinking about end users.
What about shared libraries? With RPM or DEB, if two programs using the same library are running at the same time, only one copy of the library is loaded. With Flatpak, if I understand right, each package has its own copy of the library, and even if they're the same version, the library is loaded twice.
What are you, poor? Just download more ram!! /s
Open up those stingy pockets you peasants! Your awesome repo packages are preventing us from selling you costly beefy hardware. You Linux users with your repo packages escape the rat race.
" _even if they're the same version, the library is loaded twice_ " -- IIUC, it won't be loaded twice *if* it's included in whichever Flatpak "runtime" (or one of the "runtime extensions" of that runtime) the Flatpak-packaged application in question depends on.
(For more information about this, see the "Basic concepts" and "Available runtimes" pages from Flatpak's documentation.)
I'm ok with packaging everything once but can we not containerize?
I fail too see much of a benefit for the hard android style permission containerization however there still needs to be some seperation between distro and packaging if you want one universal package because of wildly different dependency versions
take a look at nix
The kind of containerization that's done by Flatpak (and also by more server-oriented things such as Docker) -- i.e. making the filesystem's contents "look different" to different running applications -- is one way to allow for every possible combination of different versions of *the same* library/framework/API to be installed at the same time.
(For example: if one of the static data files that's part of a "framework" -- e.g. an audio file of one of the KDE system sounds -- hasn't had its file/path name changed between two different minor versions of that "framework", then it would be impossible to have both versions present in the same "prefix"-directory unless you do something like this.)
A different possible solution is to install the different versions into different "prefixes", which is what Nix does, but that approach has some disadvantages compared to containerization; see the thread titled " _Why does nixos patch rather than rely on namespacing?_ " thread from 2019 on NixOS's official forum for more information about that.
That parallel-installability problem has been a major pain point for Linux users for a long time. Windows isn't entirely free of that problem, either; if it were, then the Wikipedia article titled "DLL Hell" would never have existed. (Ironically, by using the WINEPREFIX environment variable, Wine can handle the parallel-installability problem for Windows apps/libraries better than Windows in some situations.)
I would like to use that universal distro for artix for example. But questions asked, will they mostly work out of the box? On artix there's openrc runit and others init systems, would package that came from flathub work for 100%, or they would be in their own environment where they have needed dependencies?
I would like to have flatpak's that are similar to normal distro packages, it's relatively simple to install them through terminal.
Or I just don't understand a thing or two?
There is a reason LTS distros exist. Some people want stable releases so their application doesn't change every few weeks. So if the flatpak model shifts the burden of packaging to the developers of the application we will more likely see the death of the LTS model because the app devs sure don't wanna pick up the burden of packaging/maintaining multiple versions.
Also i chuckled at the thought of a package maintainer trying to do work on something as complicated as adding HDR into mutter/kwin.
The nice thing about flatpaks is you can easily rollback versions, if a distro wants to do something extra on top of it they can
@@BrodieRobertson Nice, now all Flatsnaps need together with the rollback features is a CVE list of what kind of idiocy you're doing to yourself by rolling back
ISTM that having Flatpak as an optional alternative to distro packages makes it *less* frustrating to run an LTS distro. Someone who's afraid that a rolling-release distro might break unexpectedly during any system-update might want to use an LTS distro, but then also run the latest versions of a select few apps on it.
(For example: just last month, there was a serious bug in Mesa which made all GUI software unusable on older AMD GPUs.)
Firefox and LIbreOffice already have LTS versions.
I imagine Richard Stallman isn't impressed. The self-contained universal package model makes selling proprietary software easier and arguably takes away some amount of freedom even from the user of free-as-in-speech software.
I have 2 big issues with flathub. First is there are annoyances with software being isolated from the rest of your system. Yes, it's great for security and probably works well most of the time but I'm an unconventional user and do unconventional things and flatpak gets in my way a lot of times. The second issue I have is it blurs the lines between FOSS and proprietary software. As a debian user who does not enable the non-free repo I can easily guarantee I'm never installing proprietary software...it's simply not packaged or available to me. Flatpak means I have to be even more aware of the little things I install because it's substantially less obvious what's what. It'd be really nice if there was a way to limit flatpak to FOSS only software.
Running applications in container has the advantage of not having to individually vet them since they cannot see other applications' data without special permissions being granted. But the permissions should be more specific. Instead of broad brush permission like "access to home directory", it needs to ask for a specific directory. If it needs to see some other application's data, it should have specify what exact application's data it can see.
the portals are already directory specific
Or you can have good software that doesn't spy on you. That's why I have switched from windows.
@@ukyoize But how do you know if a certain piece of software is good or not? If I'm trying out new software I'd rather it not have the ability to mess anything up.
my #1 biggest problem switchin to flatpaks: the desktop entries in my app launcher all look identical to each other. so i never know whether i am launching the flatpak version or the native version. this is very broken user experience. also the flatpak run fqdn gets terrible after only 3 seconds. that is also an utterly broken user experience for cmdline... an alias or launcher script to point to the flatpak executable binary needs to be auto exported into my global $path shell environment. just fix those 2 simple basic things and i'm all onboard!! - cant be that hard surely can it???? since when, how and why were these never fixed?
Desktop entries should definitely be handled better.
@@eDoc2020 absolutely - i cannot agree 1 million percent enough! but not just for flatpaks... for also quite a few many other categories of software. of which the desktop spec just does not provide necessary metadata field entries, conformance between well. all sorts of application shortcut types. nor any indexing / caching either!
why is it so hard and complicated to compile binaries ?
under arch for firefox the processor at max for hours ( if it's in summer temp is horrific ) to have errors messages that accumulate and at the end not knowing if it works .
c++?
@@jimmyneutron129 I'd argue that it's years-long development debt, project bloat. Eventually every piece of software will become its own OS, see Firefox and Emacs for examples of that in the extreme.
I'll stick with .debs. I've tried the container thing before. It sucks.Snaps especially suck. No thank you to snaps, no thank you to flatpaks, no thank you to appimages.
Ask Prime Video how microservices turned out for them..
You know what we really need? Another layer of inefficiency between the software and the hardware. Thank you flatsnap.
I'm not seeing the connection with Prime Video here
@@BrodieRobertson The incessant need to containerize things that don't need containerization. I could've been more clear on that
Except Firefox and VSCodium i installed everything on my Fedora 38 via Flatpak. The first cause startup times which isn't FF strength and the second cause system integration. I love it cause i know i am bug compatible with more users (at least in future)
Once either we move from typical RW root fs with typical package management to RO immutable one without typical packaging and using containers and flatpaks... or flatpak disagregates itself from the DE tools stack to allow server/CLI software be properly distributed through it... or both happening at the same time, we'll see less packaging for the OS releases taking place. But until that happens, work on both packaging formats, native to OS and 3rd party specific, will need to be continued. Certainly if flatpak offered features for server CLI only types of deployments, without requiring DEs installed, it could potentially take over all the OS software packaging/deployments aspects. Or if all major players switched to immutable root/OS, allowing flatpak and upstream to serve software to all the users...
The """"""issue""""" with flatpak is that there's no support from proprietary applications, like Spotify and Chrome, not even some open source provides a flatpak solution officially. Yeah, there's community packages but then you will need to trust in one more layer.
That's not an issue with flatpak that's an issue with proprietary app devs not using it and instead using snap
I would love to see support for cli apps in faltpak.. flatpak is doing a lot of things right.... but sad to say not there yet..
in that regards, it's snap for the win... not quiet... both suffers for the same issue... those cannot 'see' system libraries and can't communicate with it... which makes it a bit harder to work with...
Flatpack for desktop, nix for console!
"Get in the Flatpak, Shinji. Or else Snap will have to do it."
I'm glad that there is always will be arch/gentoo/whatever distros, so I happy for others containerazation, while I can stay on random aur stuff
Maintained software should compile fine in latest release. It takes skill to backport security patches to 8 years old system.
Absolutely and that takes a lot of effort, so it's important to direct attention away from things that can be ignored.
I still prefer appimages, when they're done right. I'm seeing that a LOT of appimages are no longer maintained, or at least maintained by the original creator of the appimage in question. I'm not using flatpaks yet but will be looking into it.
Why not use flatpaks?
that's the issue with appimages, they're just files without any framework behind them. I guess they have their usecases but distributing apps that need to be updated and maintained isn't one of them.
@@n.m4497 I'm still looking into it. I like the idea of portability with appimages.
Yeeaah, let's introduce more obscure and harder way to just copypaste some files to computer... Containers, wow!..
Why not just put your app to tarball with files in folders like "bin", "share", "lib"?
What about distros that provide wildly different dependency versions
I personally like containers just sad there are issues for desktop use, we need better tools, i use kinoite btw
The cloud is cringe. Of course the guy that loves the cloud will like Flatpaks and containers. The end users LOVE repo packages. The distro that maintains their own repo packages will be the best.
Cloud is cool, Flatsnap is not. Containers are great in corporate environments, but ridiculous and dumb for home use
We can meme about cloud being a dumb term but what don't you like about the tech
Can we juat have a AI which creates a package based on the patches described and continuously compiles until the binary is achieved with said patches or stuff
I can clearly see AutoGPT doing something like that
I wonder how much damage Canonical's attempts to build a walled garden with snap did to the reputation of containers on the desktop in general?
So much that I would consider moving to BSD before ever installing a Flatsnap voluntarily
If it was realistically possible to have _everything_ as a Flatpak I would.
Change is scary, but also kind of exciting. If it works and performance is good enough, then I'm definitely okay with moving to a more containerized package management system.
I really like flatpaks but the one issue have is that its only good for desktop apps. They really need to cover the full spectrum. This is where i believe Snaps are better. Flatpaks should be able to run server applications/cli apps.
Flatpaks aren't meant to cover CLI apps, expecting it to do so will not turn out well. If you want containerized CLI apps, Nix and Podman are much better suited to this task. Flatpak is based around the idea of a sandbox, where applications use portals to access arbitrary resources. The CLI doesn't have that. The CLI assumes, and will always assume, all or nothing access to your system.
Server applications? Sure if it’s on production and need to scale up
Regular command line apps on containers sounds miserable for developers
you should just be using normal docker containers in the CLI
who cares the problem is for GUI applications that are in a niche market where the developer can't afford to make multiple packaging formats.
@@oro6768 That's the point. Flatpak needs to be able to be utilized for All applications including cli. This is why in this regard snaps are better. They can be utilized for all packaging. This reduces lift on maintainers.
I like containers. They make sense and if frees up resources so important work can be sent upstream making Linux more functional, all the better.
What resources are freed up, precisely? Someone still has to "make a package" whether it's the distro developer or a third party?
And what happens in the case of, say, Red Hat who provides commercial Linux solutions to industry in the same way that Microsoft sells Windows?
Both companies (and any provider of goods or services to business) are under very specific SLAs and "Terms of Service" that include a demonstration of "due care" and "due diligence" (yes, there's a big difference between the two).
So if Red Hat currently packages using RPMs that have to be tested before distribution, why's that any different to them using another package format?
Or Red Hat having to fully test a package format from a third party, given that if they pass that package onto a customer who then gets hacked, Red Hat will have to take responsibility?
You liking containers probably because it's less work for you as a single private user does not scale when you look at how business works.
I do wish more people would "take their blinkers off" and think about such topics from a wider perspective.
I have so much to say on this and I will never act like I know everything about everything.on the subject either ... I just hope I don't make a run-on comment here but still get my thoughts across.
I can see it both ways really. I am more of a fan of Flatpaks over snaps (esp since Ubuntu and granted it's spins minus say Linux Mint which is not even really a spin) are the ones using Snaps and "everyone else" is using Flatpaks. Flatpaks make sense for different things, but just watching this, while I get and agree with the points made, I will use my own example the other day. I admit I have not moved my /home content to my data partition lately but ... i only had say 5GB or so of free space on my Mint system. No problem accept for the fact that I had say 4 Flatpaks that needed updating (+ probably FP framework type stuff in the background on top of that) that needed 6+GB of space to download ... maybe 3GB to use but .... THE POINT is the SIZE of the containers is a problem in SOME use cases and "Linux is great on older, lower end hardhard" is going out the window if we go too far in the "containerize everything!" route.
Like my thought for MANY apps and packages is ok .... "Punt them to Flathub" ...but some core apps like Firefox or LO (and I totally understand the drop for the LO RPM... not arguing against that) should still be packaged by certain distros. JUST REALLY SLIM DOWN the number and be selective about which ones .... the apps "everyone uses and/or likely knows" would be the ones i'd consider keeping (SURE have a FP too for those that want it) at the distro level.
Also say Fedora ... not counting Rawhide and some of those ones I haven't looked into ... just say "Fedora 37 and 38" ... that is 2 versions ... (also consider what i said above about distros keeping some core app packages but REALLY slimming the list down too... mix that into my thinking in this paragraph)
Maybe Ubuntu considers just focusing on LTSs with maybe a pre-LTS release for those that want to test "what is coming in the next LTS, and bugfix" ... say getting rid of the 18.10/19.04, 20.10/21.04 type releases that have to be maintained.
Doing a mix of a few of these things (depending ON the distro being talked about) makes sense to me. I am NOT against say Flatpak... I GET what the article writer is saying and they HAVE A VALID POINT.... I rather just think of things from different angles before people jump into the "package nothing at the distro level, put it ALL into Flatpak only" ...... and what happens if something say happens to Flathub resources? .... what if FH goes down? ... then (if things go too far) tons of distro bases have issues all at once.
Also if say resources are a thing @ Canonical ..... is making an entire system for what we know as Snaps now really a better way to spend that limited resourses than just packaging a few apps (example FIrefox ....) ?
I am really annoyed by the Flatpak hype, people coming and wanting something like i3 or rust, even grub to give them a flatpak... For all the criticisms of snaps it at least somewhat works WITH the system instead of just Drifting around on top.
It would be incredibly awesome if we'd magically be able to agree to a universal default binary package system.
Nobody is asking for a Rust flatpak. It doesn't even support it: Flatpak is made for GUI apps
@@computerfan1079 People are still asking and yes it doesn't work and that's why it's annoying.
Flatpak was always intended for GUI?
Unless flatpak deals with the everything that isn't a GUI app problem, I still see a place for distros packaging the core parts of your system, and likely for a long time console utilities like htop
snaps working with the system is great until it provides conflicting binaries that aren't linked against system libraries, but no error message ever comes up and tells you what exactly happened and you're stuck until you figure out someone had for some reason installed a damn snap over a pre-existing system package and the snap f-ed everything up
As someone that knows how these "universal packages" are actually packaged, please no. Stop. I'm happy with gentoo and with the fact that any distro will have packages that share libraries and that don't require repetition of those libraries.
Do you know about deduplication
@@BrodieRobertson Yes, I am aware that many of these universal package solutions now do try to deduplicate. This may not always be guaranteed (depends on the maintainer of the package) and is precisely my objection to Guix. Even if you deduplicate, it will encourage these hybrid containers to just use older libraries by pinning. It ends up cluttering your storage with different versions of the libraries. Also, these multiple versions basically render dynamic linking moot. I do prefer static linking, but still, multiple versions on the same library will be more common due to lazy packaging (pinning versions). This also impacts RAM usage on more limited machines. In today's world where hardware is cheap and powerful it means less, but we should not discard perfectly functional, older machines.
The supposed advantage is that they'll run everywhere and forever. Well, that is until userspace is slightly broken.
These packaging systems are also not truly universal, for example, snap is dependent on systemd and AppImage is unmanaged (I don't think it has dedup, not sure). I'm not particularly familiar with Flatpak, though.
Anyway, diversity drives change. Universal package managers should only be used for some apps that need containerization, or aren't packaged for your distro. The more competition we have on packaging, the best experience users will have, such as parallel download and installation.
Why not move towards something like Nix or Guix instead?
That would be cool as well but that's not where people seem to be going
Somebody has to make a distro running on flatpak foundation, even glibc etc., everything. Otherwise, flatpak will never be the standard, because you need "native" packages (deb, rpm) plus flatpaks. I personally think this is doable.
There will likely always be a place for the core of your system to be packaged by your distro, as it stands flatpaks is not viable for things like glibc
flatpak is only for graphical apps
One of the first things I did when learning about flatpak was to see if it would be viable to basically boot to a Flatpak runtime and only use Flatpak apps.
Basically like Silverblue, but without having to install a runtime on top of what is basically a runtime. Needless to say, that didn't pan out.
If nothing else, I wish the split between system and flatpak was one level down the stack. I would really like to see desktop environments distributed as Flatpaks, but that can't be done as Flatpak relies on a desktop session to work.
@@BrodieRobertson well the core could be a "flatpak runtime" with libc, and glibc could be packaged into every application which needs it. Same with all the other libraries/dependencies.
@@theodiscusgaming3909 no, it's main use is graphical apps. Doesn't mean the packaging format can't be used for anything else.
For binary package based distro's this makes sense, it would streamline as it could also limit the differences between distro's. I could REALLY standardize everything within the Linux ecosystem almost to the point where distro's can be consolidated and not have 50 million respin's of Ubuntu where the only thing that is really changing is the desktop and maybe a few minor packages. It could also make entry into the LInux ecosystem less daunting if there are less distro's to choose from.
Have you considered the possibility that what you might consider to be "standard" could well be not what someone else considers "standard"?
I would draw your attention to the current battle between flatpak, snap, appimage and nix where there appear to be at least four factions with different views of what a "standard" package manager might be.
@@terrydaktyllus1320 Completely get what you are saying as it would roughly the same battle we already have between rpm, deb, etc. The main standardization I was referring to was file system structure as RPM based distro's and DEB based distros have completely different file system structures therefore locations for config files and binaries are in different places. As a Linux admin, that is very frustrating having to deal with systems from both camps and having to write separate code for each base to accomplish the same thing.
As a Gentoo user, I prefer source based distro's, however for large scale deployments its not really feasible/practical.
My point blank statement still stands, all Linux distro's (binary and source based) should have the same file structure AND file locations. There is supposed to be an agreed upon file system standard but it doesn't seem like its being followed, unless that standard only goes as far as the first level folder.
So yes, there should be a standard for the flatpak, snap, appimage and nix'es of the world as well!
Will that ever happen, my guess would be NO!
@@TuxWing "Completely get what you are saying as it would roughly the same battle we already have between rpm, deb, etc."
There's no battle between rpm and deb though. If you're on Red Hat or Fedora, you would have used rpm only, not deb. The reverse for Debian users. They are not package managers in direct competition.
"The main standardization I was referring to was file system structure as RPM based distro's and DEB based distros have completely different file system structures therefore locations for config files and binaries are in different places."
...which is an issue not solved by flatpaks because they are containerised anyway, so "run outside" the OS filesystem.
Anyway, the problem is solved by picking a distro and learning it, rather than constantly distro hopping.
"As a Linux admin, that is very frustrating having to deal with systems from both camps and having to write separate code for each base to accomplish the same thing."
Then learn to be a better admin... or rationalise the number of different distros you administer. There's not just one solution to the problem.
"As a Gentoo user, I prefer source based distro's, however for large scale deployments its not really feasible/practical."
Gentoo has been my sole Linux distro for 20 years, and I am now scratching my head as to why we are having this discussion given that you know it too.
Actually, it is feasible and practical across a large number of systems - I myself look after about 150 machines running Gentoo and it's all about optimisation by platform. If one machine compiles the packages and becomes a binary repository for similar machines, there's huge time saving in that alone.
"My point blank statement still stands, all Linux distro's (binary and source based) should have the same file structure AND file locations. "
No, it does not "stand", it is simply YOUR OPINION versus MY OPINION.
And you're contradicting yourself because if every Linux system had the same filesystem structure, how would Portage in Gentoo work - given it spreads its file across multiple directories?
The solution is DON'T BE LAZY. Learn your craft, be a GOOD sysadmin. If it's too much for you, do something else.
Why does the entire world have to change just to make it easier for you?
I doubt your Gentoo skills at this point, you don't seem to have the right mindset to make a success of it.
"So yes, there should be a standard for the flatpak, snap, appimage and nix'es of the world as well!"
I'm just entering the discussion as an experienced Linux user but I could care less about any of them. Gentoo has stuck with Portage for the 20 years I have used it, I've learnt it and I'm good with it.
Everyone else can go do what they want to.
@@terrydaktyllus1320 Thank you for your criticism, I will take it and apply it as needed. It is possible that I may have over stated things. I currently manage various versions and flavors of RHEL and DEB based systems, while trying to narrow that down as much as possible to simplify and standardize...for work and have used Gentoo since 2006 but only for personal use. I am no Gentoo expert by any means, but I manage fairly well. Yes, I it is *my opinion* that file system structure should be better standardized, no matter what packaging format, source based install, or container format is used. Since most sysadmins work closely with the file system it would allow us to work smarter not harder. My apologies if my opinion(s) bothered you in any way it won't happen again.
@@TuxWing It's not criticism, I can't criticise someone I have never met.
They are simply "observations" based on the words you wrote, nothing more than that - and me as a complete stranger to you then you are perfectly entitled to ignore everything I say anyway.
I can only talk from my own experience - I've been around Linux since 1997 and UNIX about 8 years before that - but I am still learning from people half my age which is why this channel is one that I come to and enjoy.
I wish you every success in your sysadmin career if that is something you do as your day job.
I still hate containers for apps, I hate it then, I hate it now.
I'll never use those in my system.
These flatpacks may be stable but they are sluggish and bloated with isolated redundancies.
Isn't this mainly caused by not maintaining backwards compatibility? If you had a distro that only accepted both libraries and applications that are backward compatible would that solve the problem without a significant performance hit? I'd certainly choose that distro if it existed.
I think the easiest way to do that would be to not setup libraries through symlinks, or at the very least no bare symlinks where it's just the library name and no version number. If all your programs that use libabcxyz link to just abcxyz, then updating any one of them is going to give you a bad time, but if they link to main branches of API changes, say abcxyz-1.2.3 then updating would be a cinch. Even cooler still if the packager maintained a list of these dependencies and could allow you to save space by deleting dependencies you no longer need or even allowing you to update apps that are keeping them alive so you can delete them.
@@anon_y_mousse That's basically what NixOS does.
imo from the start programs should have been self contained and look for dependancies in local context so to say. reason that wasnt the case is because UNIX didnt do it for logical reasons storage was expensive, problem that doesnt exist anymore
@@bigpod I agree. Disk space is not a problem for most systems these days. That's why keeping support for old libraries / APIs doesn't seem like a big stretch to me.
@@bigpod Shared libraries save not only disk space (which is still useful, I need as much of it as I can get) but also memory. But of course, chances are, you are one of those "people" that thinks running programs in web browsers is ok.
I hope supporting flatpak makes it a new standard and forces Canonical to abandon snap v:
Just some unga bunga my football team thinking but whatever :P
But what os should I then move to :(
Like all those snap packages and flatpacks really slows my pc down extremely with snap packages and the same with flat packages because of the extreme overhead from disk iops
Thats literally also why the first package I always uninstall snapd on ubuntu systems as the first so its at least usefull
It's actually sad to see devs literally dont care of people there uses there packages
I don't get why we need Flatpak, couldn't Distros just agree on one packaging format? Why Flatpak, which doesn't even work for terminal apps, instead of one agreed upon universal packaging format?
Yes, but I wish you luck getting distros to agree on that
@@BrodieRobertson If they can agree on flatpak, why can't they agree on a normal packaging format? I don't get whats so special about flatpak that brings them together
@@Cookiekeks there's probably countless factors that lead up to this being the community direction
@@Cookiekeks flatpak is separate from the OS package manager, also distros didn't 'agree' on flatpak, it's just made in a way that lets it be installed on pretty much every distro
@@theodiscusgaming3909 Why couldn't you make a normal packaging format, that is also separate from the OS? Why is it tied to a specific OS in the first place
I wish you wouldn't include Gentoo so "easily" into these discussions because you don't know a lot about it anyway - but kudos to you at least having a go at installing it a while ago.
Gentoo and its user base are not going to suddenly "bow down" to what a lot of the rest of the Linux community is doing - possibly that's the case for Arch and a few other distros too but I can't comment with authority on that because the only Linux distro I use today is Gentoo. But I wouldn't, for example, think that Slackware users want to abandon slackpkg any time soon, I don't see Arch users fully abandoning pacman any time soon, and I've never heard anyone in the Gentoo Forums complain about Portage and demand that something else is used. I've used Gentoo for 20 years and nothing has radically changed in that time - systemd and Wayland, for example, are still only "options" to a default installation that centres on openrc and xorg.
You hear Ubuntu, Fedora and some other distro users complain a lot about package management and I think a lot of it is to do with mindset and Unixporn on Reddit. I think a lot of newer Linux users out there are never going to be happy with a pre-built distro, they spend a lot of time distro hopping because they see a pretty screenshot on Reddit of "someone else's Linux desktop" and decide they want to change to another distro. (I could argue that I was in that place also when I distro hopped between 1997 and 2003 when I finally settled on Gentoo that lets me build my systems how I want to - so I understand that mindset.)
Ultimately, a lot of users want "universal" package management and a lot of them also complain about too many distros to choose from - the natural progression of things from that point will be that those distros that adopt a single package management format will end up being rationalised with some falling by the wayside. After all, if you can have any package configuration that you want from any other distro on Ubuntu, why would you even consider, say, Fedora?
But please don't draw conclusions about "universal" package management being some kind of standardisation across all of Linux because history shows that doesn't really happen - there are still multiple desktop environments and window manaagers to choose from, systemd is popular but by no means universal across all Linux machines, Wayland is making extremely slow progress in replacing xorg, and there is still a demand for non-Intel 64-bit Linux distros that are specific to particular platforms like ARM and 32-bit Intel devices.
Experienced Linux users (and there are a lot of us) aren't the types that hop from distro to distro - they've ended up on less popular "periphery" distros like Gentoo, Arch and Slackware and that's probably where they will stay.
Experienced Linux users don't abandon a distro just because they had one bad upgrade experience from a package manager that "borked" one of their machines - they will already be backing machines up before upgrading and understanding how to implement workarounds until package manager issues are fixed, if and when they occur. So one bad incident isn't going to turn them away from their distro of choice.
Ultimately, Linux is and always will be about choice - and if newbie users want "universal" package management then good luck to them, I hope it gives them what they need.
But let's stop with this standardisation-type rhetoric because those of us on the periphery just get on and use (and enjoy) our systems whilst wondering what all the fuss is about in the newbie community.
Linux is not a "fashion accessory" for me - it has to solve particular computing problems and if the stuff I have already learnt solves those problems, why would I even consider changing to anything else?
I mentioned gentoo as a distro that will always do it's own thing, I'm not sure how you missed that
@@BrodieRobertson Maybe I missed that, then - in which case I take it back.
With that said, I'm not just addressing you directly anyway because there seems to be this mindset, particularly amongst newbies, that less choice is good where the standardisation they think they want may just end up killing of the very distros they use currently.
Then we agree - Gentoo, Arch and Slackware will be immune to those effects anyway.
Flatpak ftw
This is not the future, it's a long and brightly lit corridor with a dead end.
Honestly, as long as they do what they already do and aren't closed off like Snap, I couldn't care less
In fact I welcome them to finally end the "Not available in my distro" problem, I can and would use Distrobox.
But let's be real, only people who love wasting time scoff at the idea of things being more convenient
Less time on a search engine, more time spent _actually_ doing stuff. I'm sure existing problems can be fixed
Hm what does this mean as a NixOS user and nixpkgs, does anything change?
you could stop at five to six stores. Or just one.
>Or just one
ubuntus snapple store
Since he is very imp in flathub thing its no wonder he would suggest you to move away from packages...... Am an old-school guy and will never back down from packages. I want some control in my life and dont want a change
Flatpacks are slow as f*ck now. Using only for things that aren't available otherwise.
The only time I was disappointed with flatpak is with neovim, because of its tight integration with the system tools and inability to make them available inside sandbox. Other than that, flatpak seems like a "right" way for software distribution, at least for my brain, tainted by android and windows
Well... 99.9% of users including devs don't want to use a CLI program. And flatpak was made for GUI programs that everyone wants.
Maybe this will encourage someone to make a "CLI" neovim inside a GUI window to emulate the editor. This would be a Windows or OSX approach for this.
@talkysassis6900 Nah, that's not the case. Neovim flatpak works super fine by itself. But if you start adding plugins, that's when the problems start. Some plugins require node, for it to be available, you have to have flatpak platform that has it (or something along those lines, please forgive my ignorance and gross oversimplification). But what if you want ripgrep for another plugin? You can't just install it inside the flatpak sandbox, and there's no platform that has it as a dependency.
Neovim plugins are too close to the core system to be isolated in a flatpak environment. Or we need a way to customise said environment, like in nix or something. But that goes against the way of a flatpak, where apps are completely self-contained. Maybe we just need a flatpak way of using plugins in apps...
@@Slate245Ivanovo Don't change much. You need extensions for that. If GIMP can use them, so do neovim
I would use flatpak more of it would not consume so much storage and was command line friendly
Use Nix for the command line, Flatpak isn't and will never be suitable for daily command line use. The CLI is simply not compatible with the whole concept of Flatpak.
And on storage: It already consumes very little, for all the benefits you get. Even on a system with a 32GB limit of storage for applications, my core set of applications doesn't even come close to hitting the limit.
Containers are cool and all, but the premise of corporate-controlled-container-bundles is a non-starter for me. Slippery Slope, Bait and Switch. These lazy Redhat+Canonical container bundles for everything is like mandatory forced compliance. Makes no sense for forks or for custom setups. They want the container because it can enforce a monoculture, and it can also ship anti-features that cannot be decoupled. If you don't agree, I have 10 other points to raise. If you don't get it, be thankful, some crazy Gentoo'ers are out there keeping software build freedom alive despite this.
It makes app devs lazy and will quite possibly lead to poor/brittle build systems and lacking configuration - see docker
Flatpaks are fattier but not awful.
I have a slightly different take - but don't disagree with points made. The distributions - almost all of them, persist in making up new releases. The end user doesn't want a new release every 6 months, or 2 years. They don't want this in Linux, in Mac, or in Windows. The majority just want their machine to work, and update. (Cue knashing teeth and endless debate). That long list of Ubuntu releases that maintainers have to face, is a choice. Its not a good choice, and it is indeed a shit ton of work.
It doesn't have to be that way, and everyone knows it.
This is why i believe vanilla OS being the future of linux.
Sorry, is this a future where there is just ONE version of Linux, like there is with Windows? Didn't many people come to Linux in the first place to avoid having a particular OS workflow imposed on them? So ultimately your goal is to turn Linux into Windows?
maybe other immutable OSes but not vanilla IMO because the way it does immutability with 2 root partitions means that it literally takes up 50GB of space. Fedora's immutable distros are much better in this regard, a base Kinoite installation takes up like 7GB.
Credit where it is due though, apx is a really neat 'package manager' and I'd like to see it ported over to other OSes.
@@theodiscusgaming3909 Immutable OSes are just for people who don't trust themselves on a computer - and that's easily solved by just sitting down and doing some learning to gain confidence.
Another gimmick designed to protect idiots from themselves.
@@terrydaktyllus1320 What does having a read-only part of the disk have to do with being an idiot?
@@JorgeCastro I hate to say it but you asking me that question says a lot already... but you have the opportunity to explain to me why you feel a read only part of a disk is not there just to save you from your own stupidity.
I seem to recall Microsoft did something similar to at least "hide" the C:\Windows directory in XP and beyond in order to stop the numbskulls from messing about in it.
As far as I am concerned, it's for people coming over from Windows who are too lazy to learn how Linux learns properly so that they don't make stupid mistakes. They believe (incorrectly) that it is someone else's responsibility to protect them from themselves.
Prove to me otherwise. In your own time...