From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word “Linux” in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
In general, I don’t like the idea of having flatpak, snapcraft and appimage, packages. First, and this is different between them, but in the end they all suffer the same one way or another, there are huge binary dependencies blobs, whether coming with the same app, or having to be installed from the package provider. At some point I tried to install Liri from Flatpak, and it was a nightmare of things having to be installed, when I already had most things natively built by the distro I used.
As opposed to opinions from Linus himself, I prefer SW to be built from the same system libraries and dependencies, rather than each app coming along with their own set of binary dependencies. Getting GNU/Linux to behave like MS-Win, where you can install whatever binary, from whatever source, and perhaps even duplicating a bunch of stuff you already have on your system is crazy. One thing that gets solves easier, when having contained apps, is when depending on same things but from different versions, and that to me is not ideal either. To me, as done by distros, one should avoid as much as possible having different versions of same SW, but if in need, then rename one including the version as part of the name, or something, but mainly avoid having a bunch the same thing with multiple versions all over. Guix handles that more elegantly of course, but I haven’t had the time, neither the guts to go for Guix yet (still in my ist of pending stuff).
The other thing, is that although now a days everything comes with a signature to check, on distros provided packages, which are built from source, besides minimizing the amount of stuff needed, one can always look at how the packages are built (arch and derivatives through the PKGBUILs and companions), tweak and build oneself (eg, currently fluxbox head of master, and from a while back, doesn’t play nice with lxqt, then with the help of fluxbox devs I found the culprit commit, revert it, and still apply the same distro recipe with my own patch, and moved on). No matter being signed, binary packages are not as flexible, that besides the fact several just proprietary, and one might not even be aware, since the move is to be more MS-Win like, even with auto updates and such…
Building having in mind minimal systems and ecosystems, and have mostly free/libre or at least open source SW, makes thing much better for me. One can end up with bloated huge systems, if wanted, but at least not with bunch of duplicates unnecessarily.
They aren’t available for my OS (GNU Guix System), but if they were, I still would refuse them because they are the antithesis of what I consider an ideal free software ecosystem: mystery blobs that may or may not be proprietary that bundle other dependencies that may or may not be proprietary, that auto update themselves because that’s how it’s done on Windows. Add to this the fact that the server side is proprietary and controlled by a for-profit company (and last I checked there was no way to configure multiple repositories or override the default snap server without a recompile) and that’s just more reason to stay away. Flatpak is arguably snap done “the right way” but I still refuse it out of principle, because it shares most of what I consider to be fundamental problems with snaps.
GNU Guix does it the right way for me. Source based reproducible builds that are 100% free software, but have binaries available if you don’t want to/can’t build them yourself. “Channels” (repositories) are just git repositories with package declarations, so anyone with access to git hosting can create them. Package declarations declare every dependency they need so an isolated build environment can be created reproducibly, and any change to a dependency triggers a rebuild of dependent packages.
Is snap even free opensource?
@imgprojts @OptimusPrime It’s somewhat open source - the client “snapd” software that runs on your system is open-source, but the Snap Store server software isn’t AFAIK
I mean that’s basically it. So long as there’s the tiniest bit of proprietary code or dependency, it automatically falls off my radar as potentially good for me. I think of it as candy and in the back of this delicious looking lolipop piece of software, there’s a big white van just waiting for us to take a lick. Once hooked, away we go…into the Nether regions of what should be free but isn’t.
@imgprojts @pmc Good luck running a CPU or GPU then (all of them have proprietary firmware)
You can stop using internet right now. There are closed source bits of code in the JS you run off of websites natively. If you are not using LibreJS and IceCat, you have already been assimilated.
Because snaps are slower than flatpak per my experience. Also there is already many other ways to install software and why bother making things complicated, specially if the community already have a favorite. To install apps I chose distro_repo>flatpak> AUR≈Snaps≈appimage. This because it depends how the app behaves, its limitations and ease of update with everything else.
I prefer distro packages, because they don’t need to install dependencies, which are already installed. But for testing out a program or in need of several versions of one and the same one, it’s a great deal.
But even for testing or running multiple versions, AppImage is the better solution, in my opinion.
I love to have a clean PC, so if everything was flatpack or snaps I would use it but as it is not the case I only use the traditional way of installing apps. But it is a great way for the developpers to share their apps universally on any Linux distro.
I use distro repos or flatpak.
Genuinely my biggest reason to not use them, is that
snap/folder in the home-directory. That is my periodic reminder to uninstall any Snap apps + Snap as soon as I can.
I also don’t like the added layer of indirection. I’ve had to use a proprietary, exclusively-Snap-distributed program for $DAYJOB and unsurprisingly, it stopped working within two weeks of having set it up.
I don’t know, if the Snap-layer caused it to stop working, but it made debugging harder. I couldn’t just start the binary from the CLI or look at the file-tree. There’s probably Snap-commands to do these things, but then I still can’t rule out Snap being at fault.
snap/folder in the home directory is so disrespectful. I absolutely despise these apps that think they’re “too good” to follow proper xdg standard
I don’t even get how they came to place that folder in the home-directory. Was that just a lazy developer entering any folder at all during the earliest prototypes and then they never changed it?
And why did they never change it? Just give
~/snappriority, if it exists, but use
Like, it’s Ubuntu that we’re talking about. The distro once lauded for it’s polished and intuitive desktop experience. And now they have a confusing and useless item in one of the most user-visible places, on every single installation.
sandboxed environment begets namespace shittery when trying to do anything. the command to run my dosboxX install is like 80 chars.
They’re slow, and I don’t need them.
I avoid them like the plague. I don’t want to add another installation method (one of GNU/Linux’ advantages has always been the “exactly one way to install”, instead of dozens of different installers). I don’t want something that not only disobeys XDG (The only Poettering-thing I approve of…), but clutters my home with a visible folder, that happens to contain nothing I ever need to access.
Biggest issue: Free and nonfree packages in the same repository. If you’re on the command line, you have no idea which is which. Goes against the principles of free software. For me to even consider using a package manager it better not have nonfree packages by default, you should need to issue a command to activate a completely separate nonfree repository (so I can avoid that command like the plague), you know, like how apt, dnf, pacman etc do it?
apt is easier (probably only because i’m used to it) and snap takes up a fuck ton of space. at one point it took up like a quarter of my entire hard drive, then i started deliberately avoiding snaps
I’ve only ever used them very casually, but in my very limited experience they were not as unreliable as apt packages.
I also had a really frustrating issue with one snap that had a single channel which published an alpha release. I couldn’t figure out how to roll back, or extract my saved states.
@OptimusPrime because I use :arch: btw, #AUR already suits my need