- Extremely slow at doing anything, even the most basic commands.
- Ridiculous auto-update mechanism (you can't even disable it wtf).
- Random, nonsense limitations (why can't I open dot files and dot directories???).
So terrible that for most apps that I installed with snaps I end up installing the deb version later on.
What an abomination, it is a devil that's hurting the Linux desktop everyday.
Guess what I got?
A freaking snap. Yes, try it.
I’m done with Ubuntu
When will these system designers realize that the system shouldn't do anything observable without me telling it to?
Imagine if a kitchen oven decided to perform a self-clean without any human interaction "because it hadn't performed one in awhile".
Arch is customizable, simple (in the sense that there are no surprises; things work as expected), and has a great community. Folks here can argue about snaps or flatpaks, and I can happily use AUR to install nearly anything. If it’s not there, I can publish it.
I’m not forced to adopt whatever GUI Canonical thinks is best for me in a given year or whatever their trendy new craze is. I can enjoy i3, tmux, vim, and ignore the rest.
These days it's looking like Fedora holds that crown.
They take bizarre risks and insist on reinventing things badly.
Security, infrastructure ecosystem integration, and defaults that don't work with reality.
The advantage of RHEL/Cent and sometimes Fedora server-side is it's boringly-reliable. The kernel especially. For development, the userland isn't great and the desktop is mediocre.
Qubes is interesting for security, containerization, and running apps isolation where Fedora, Cent, and Debian (possibly Ubuntu and Windows) are all side-by-side choices as app substrates.
I should've done it a long time ago but until recently Ubuntu has been "debian but with some nice little extra bits of effort here and there to help make it smoother". Now it's "debian but with a lot of spicy canonical opinions dumped on it".
However this seems pretty silly when what actually changed is the default OS installs will not have flatpak installed. Easily fixed with "apt install flatpak". It's just a default they are changing, not purging flatpaks or preventing them from working well.
Security improvements are welcome, but that was a feature that seemed important and reasonable to keep working. (Maybe it works now, but based on that experience, I gave up on Snaps until I heard more positive reports).
- Violates XDG Base Directory Specification
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053
I ended up with Debian because I like stable but not ancient (CentOS?) and it comes with a release cadence similar to Ubuntu LTS.
We've been here before, of course - they pushed their own DE (the original Unity, not the current GNOME theme) for a while as a competitor to GNOME, and they also pushed Upstart over systemd. There are probably other cases I'm missing.
Eventually they gave up on those pet projects for pragmatic reasons, but Snaps seem to be the hill they want to die on (presumably for internal political reasons and/or some weak attempt at lockin).
The original Unity DE was released in 2010 prior to the release of Gnome 3.0 in 2011. Upstart was originally included in Ubuntu in 2006 to replace sysvinit, and writing upstart scripts was a huge breath of fresh air. Systemd was released in 2010.
As a developer and user, I hate snaps _and_ flatpak. Both are user-hostile and constant source of problems requiring hours of Googling (especially the Flatpak sandbox!). I ended up purging both from my system a month ago and have been much happier since.
Don't you just remove it if you're using Ubuntu, never install it if you use Debian/Fedora/Arch, and pretend it doesn't exist? I've never run into an app I want that is only packaged for Snap.
Canonical has money to do lots of good, too bad they waste it on terrible engineers and terrible projects.
I tried about 10 times to get mysql workbench running, but it depends on some key store backend through dbus, I haven't be able to get the conncetions working through snap so i cannot access a database since, for whatever reason, it has to go through the keystore.
The failure message? 'dbus-launch' does not exist.
You install chromium-browser through apt
Chromium gets installed through snap
You go to a PWA to install locally (like M$ Teams)
The desktop entry is saved with a path hardcoded to /snap/chromium/1234/... (1234 is the id)
You update chromium, either intentionally or automatically, the ID changes
Now you can't access your PWA anymore unless you edit the desktop entry and change the id or replace it with `current`.
Bad user experience, bad implementation, bad decisions, and bad reputation to the wrong target, just because Canonical's Ubuntu is the "default" Linux.
They worked fine, and I don't feel like having multiple types of containers and update methods and mounted image file systems really made anyone's life better.
I have some experience with packaging, and if we talk about standalone applications, dependencies aren't a big deal; producing deb packages for different targets is not difficult. The last (only) breaking change across different targets I can remember was old graphic libraries (I think it was gtk2-based WxWidgets, removed in newer Ubuntu versions).
Sure, packaging software is a bit of a thankless task, but with enough automation, packaging thousands of bits of software on every git commit should be doable by just a few volunteers.
While I wouldn't call Flatpak "popular" with users per se, it's probably one of the least-worst alternatives that have come out. The horse Ubuntu has backed (Snap) may be the most used by virtue of being rammed down user's throats by projects with existing user capture (e.g. LetsEncrypt), but that's not going to make the debate go away: it just strengthen's the argument to return to distro packaging.
That's exactly what I want. Developers and Linux distribution maintainers should be working more closely with one another instead of reinventing static linking with "snaps" or whatever just to avoid working with the community.
Two specific examples:
(1) For some reason a lot of Debian distros decided to rename and/or re-version-number OpenSSL for no good reason (pedantry is not a good reason), meaning if you depend on OpenSSL/libcrypto your packages will mysteriously break all over the place because you're not using the versioning scheme or naming convention. We're not doing it now but we may switch to statically linking this.
(2) We use a UPnP library called miniupnp in the current version. We have to statically link it because of issues like (1) and also because some distros were for a time stuck on a version that had security bugs that they would not upgrade because it would break other packages.
So imagine (1) and (2) ad infinitum times a hundred little distributions and Debian forks and... it's completely untenable. Static linking solves many of the problems but that defeats some of the purpose of package management.
We do it for all the major Debian and Ubuntu distributions by using a qemu-chroot based build farm that builds on each distribution+architecture combo with actual qemu binary emulation. It's over 200 gigabytes of chroots and takes two hours on a 64-core Threadripper to build all the artifacts. We tried cross compilation and had too many problems: it builds fine, seems to run fine, then users complain that some mysterious glibc symbol was missing on their system. We switched to building on actual chroots and most of those problems went away. Most of them.
Snap, FlatPak, and Docker are all variations on the same basic conclusion that many developers reached long ago: "fuck it, just distribute software in the form of tarballs of entire Linux installs."
The only thing worse is Windows MSI installers and Windows drivers, though with those at least there's less platform variation so once you battle those horrors the result mostly works on most systems. Mostly. But whoo boy is the Windows installer system horrific. I shall quote Pinhead: "I have such sights to show you..."
Apple is the easiest because they have less legacy baggage than Windows and only one "distribution." They do have some horrors around signing and notarization and we don't distribute in the Mac App Store (yet?).
A major reason SaaS delivered through browsers is eating the world is the immense and totally unnecessary pain of distributing apps for major OSes. Even Apple is quite a bit harder than making a web site that you visit in a browser. All this pain is 100% the fault of OSes not caring about developer experience and in the case of Linux the multiplication of endless "vanity distributions" to no benefit to the community.
If you want packages instead of tarballs of OSes, Linux distributions could (1) consolidate and (2) invest some time in the very boring totally un-sexy work of massive amounts of clean-up and standardizing things as much as possible. But it's more fun to make another vanity distribution I guess. You'll get it right this time and everyone will switch to your distribution.
Look at Arch Linux, we just write a short AUR script and the package is integrated. Once the script is written, everyone can use it. This is possible because Arch always ships recent libraries.
It's just a convention not to, no? IIRC the Steam .deb comes with pretty much everything statically linked. Works fine.
Apt should be used only for system software (like init system, system libraries) but not for applications.
Also apt allows to run scripts as root during installation and this is not secure.
As for root requirements, what you are asking for are (non privileged) user installable packages. Packages that install only to the user account. This feature doesn't exist, but it'd be a much saner approach than snap/flatpak.
Linux distros have a history of abandoning useful, well-understood technology for fads that then cause power users all kinds of headaches later-on (e.g. by cluttering output of useful tools like mount). Eventually, power users just lose the will to adapt, and move on.
Could I have just switched distros, or compiled my own stuff? Sure. But I am no longer a student. I am become a mid-40s guy who is becoming aware his lifetime is not unlimited and can be spent better than learning the ropes of a new system.
In the time of Jenkins et al the burden of creating bistro-specific packages is negligible.
And this is just one example. Many devs warn you out right about package manager's versions on their websites.
Would their apt repo suddenly disappear? Probably not, but who knows.
The developer experience on Linux I find is much better than Windows and macOS. But putting my 'user' hat on, the experience on Linux in general is still pretty poor, despite all the progress that's been made over the decades. And package management is one example of this. I don't think it's fair to ask users to work with a new paradigm of maintaining software, even for a "free" OS, and despite how hard it is on developers to maintain distro packages.
And make sure it keeps a log of everything it did so it can be rolled back if it doesn't work as promised.
But, I'm all for competition, long may it continue. The only real negative here is that some apps will only release Snaps, others will only release Flatpaks and people will end up having to just revert to copr/AUR like before.
Choosing a distro is basically choosing a DE and package manager these days anyway - a single unified packaging format that works everywhere is more frustrating than an alternative DE or windowing system.
Basically, Ubuntu phones were using click packages (predecessor to snaps) back in 2011 and 2012, with snapcraft shipped in January 2013, whereas xdg-app (later renamed to Flatpak) was started in December 2014.
Another thing to consider is that Canonical is orders of magnitude smaller than RedHat, and they do have a problem getting the community involved, but part of that is the size and limited time their developers have.
Now, even as a long time Ubuntu fan, I'll probably be switching to Debian just because I dislike the snap upgrade model.
Basically, Canonical will start at a project first, but RedHat specifically will look for ways to not join them, and start their own project instead.
Part of that is certainly due to Canonical itself, but I can't help but think a lot of it is RH making a call and then throwing more developers at something.
https://en.wikipedia.org/wiki/Snap_(software)
So I don't see how RedHat or any other FOSS distributor could have been happy with Snaps.
https://web.archive.org/web/20071012194830/http://www.gnome....
There was also glick2 in 2011.
https://web.archive.org/web/20111022070435/http://people.gno...
You may have heard of Alex Larsson as author of xdg-app.
I think the oldest related project was Klik, started in 2004 (and later renamed to AppImage).
This is his blog about the history of Flatpak.
https://blogs.gnome.org/alexl/2018/06/20/flatpak-a-history/
Also, the reason why Canonical have "a problem getting the community involved" is that they put a KEEP OUT sign on every one of their projects in the form of a CLA requiring copyright assignment.
A tiny inconsequential part. The bigger one is their refusal to give a shit about usage outside of Ubuntu with Canonical-controlled servers and their insistence on CLAs. Canonical has noone but themselves to blame for Red Hat to continously win the community for their solutions even when they were late to the party.
This. Also bzr. They seem to want to control their projects completely and so even when they have good tech they lose out to more open, community developed, equivalents that build wide engagement and momentum.
I honestly don't understand it, you would have thought they would have learned by now that they don't have the engineering resources to do everything by themselves.
Compare that to Red Hat who always try (and sometimes even succeed!) at developing projects with the community and are far more successful at getting their projects adopted (I know people don't like them, but you cant deny they are effective at it)
The simple answer is that the company culture really, really wants to be "the Apple of Linux", with all that it entails. Whereas RedHat wants to be the Linux of Linux, they've learnt how the opensource game really works and they play it every day.
Bzr "lost" because git had GitHub, whereas Launchpad was one too many things and slow to optimize for modern sensibilities.
(And Linux used a different VCS before git, so that didn't matter in adoption)
Imagine a world without GitHub, and I don't think git would be our go-to VCS. Though maybe not even Baazaar, but there are things like Mercurial too.
I'm struggling to find a way to characterize the difference between Red Hat/IBM and canonical's approach to the community. The most succinct I can come up with is that canonical releases projects and assumes that they are the one responsible for their creation., Red Hat releases rough ideas and code. There also seems to be a heavy political/disinformation campaign going on tearing down any solutions by canonical.
In either case, none of us can resolve the conflict. It's a pissing contest between canonical and IBM/Red Hat. I will keep choosing solutions that let me get my job done and get paid which is all that matters.
What distribution doesn't support at least half a dozen desktop environments these days?
Most usually come out of the box with official support for only 2 DEs. Of course they can theoretically support every one out there if you manually install them.
Through nix-env it even already has the idea (albeit discouraged) of imperative package management like apt.
Having spent a while with NixOS, running containers for user applications seems like using a cannon to kill a fly. The 'simple' alternative is to drop FHS altogether - which containerization is kind of doing in a roundabout way by isolating the app filesystem from system fhs.
As for it being for developers only... I get that perspective. Debian/Ubuntu packaging is also hard, AUR packaging has its quirks. A lot of this is hidden behind the package manager, wheras with NixOS it is more obvious.
The killer idea for NixOS would be to make package management for Joe Q Public as easy to use as apt while. Tools like MyNixOS[1] are emerging which might bridge that gap.
The only outcome this leads to is monetisation attempts through their store and other OS integrations to try and turn free users into a source of revenue. If you’re using Ubuntu for desktop I’d urge you to start exploring alternatives.
@bluesabre@floss.social "[…] Ultimately, each of the current flavor leads agreed to the change. […]"
@wimpy@fosstodon.org "@bluesabre Did we agree? I think we complied with the requested change. You and I both played our part in ensuring this was clearly and openly communicated."
- - -
https://nelsonaloysio.medium.com/installing-ubuntus-snap-on-...
> […] As Ubuntu’s snap requires access to the root file system in order to create a symlink in /snap to /var/lib/snapd/snap, successfully installing it requires a few extra steps. Besides, $HOME directory in Silverblue defaults to the more traditional path /var/home/$USER, and since snap expects it to be on its modern location /home/$USER, this must be worked around as well. […]
Snaps drove me off Ubuntu, and I'm glad I landed on Fedora.
Really is a joy to use.
P.S. Bonus for people using fedora who "discover" Silverblue :)
Turns out snapd.apparmor, whatever that is, wasn't running. (I ran `vlc` on the cli to figure it out)
I love snaps, they're so convenient for the end user..
To begin with: It would be nice if the data of the containerized applications were stored in one place and one place only. Each application should simply be a single directory in /snaps/ or something.
At first I thought snap would be like that. But no. When I did some tests, the data of a snap seems to be splattered across various places on the file system.
/usr/share/bash-completion/completions/snap
/usr/bin/snap
/home/izkata/snap
/var/snap
/snap cd /etc/apt/preferences.d/
cat nosnap.pref
# To prevent repository packages from triggering the installation of Snap,
# this file forbids snapd from being installed by APT.
# For more information: https://linuxmint-user-guide.readthedocs.io/en/latest/snap.html
Package: snapd
Pin: release a=*
Pin-Priority: -10> Let's say it's "Pre-alpha", as in "It kinda works on my computer".
We can very easily mimic flatpak and snap by wrapping a nix closure in bwrap.
You can have the choice to sandbox it or not with Nix. And you can easily compose it with other software.
I choose to use Ubuntu at work for a bunch of stuff, but snaps are making me consider whether it's worth migrating over to Debian instead.
As an example I wanted to download some pictures from a webpage , for each picture I was forced to select the destination folder because each time it defaulted to some snap related folder(I forgot).
The browser feature where it remember that downloads from site A goes in folder Fa and downloads from be go to Fb is a big time saver. I got the Firefox tar.gz file and using that/
The fix for this is currently being tested: https://bugs.launchpad.net/snapd/+bug/1980271
> before removing alternatives
Alternatives remain available for install. They weren't removed.
You're technically correct (the best kind) about them not removing alternatives, but you have to do some manual intervention to get them back, so I consider it being removed when compared to the previous behaviour of having them available by default.
They also still haven't fixed that disgusting ~/snap folder.
It's very obvious by now how little Canonical cares about their users.
I'm sure their enterprise side is fine, but their consumer side is disappearing rapidly.
">This adds fuel to the fire that Canonical is doing this largely to further its own interests."
What a surprise, companies (excluding rare exceptions) are there to make money, not to give it out. Interests of the customers are taken into account only as far as it helps to increas income and satisfy legal obligations.
It was rather cathartic to see
And honestly, I get it. I avoided it for years (it's 20 years old now!!) mostly because the nix language and words like "derivations" scared me*, until a year ago after hopping distros for quite a while (hmmm Elementary, Pop_OS, Ubuntu, Manjaro, Arch...) and after a month where I had both a bricking AND a seemingly-unsolvable interdependency build problem, I got mad and decided to take a deep breath and check out https://nixos.org/
* here, let me immediately solve that fear: Nix interactive language tour, it's like JSON with syntax sugar and pure functions: https://nixcloud.io/tour/ . And a "derivation"? That's basically a "lockfile" for a particular package, if you know what that is (and you probably do). Except it existed before the concept of "lockfiles", so it got that name.
https://www.forbes.com/sites/jasonevangelho/2022/01/17/what-...
https://www.techrepublic.com/article/zorinos-16-is-exactly-w...
https://www.zdnet.com/article/zorin-os-puts-on-a-master-clas...
Copy-pasting my comment from reddit:
- Interface is amazing. Possibly the most polished and modern UI in any distro.
- Nvidia drivers provided by default.
- Biggest App store library in any Ubuntu-based distro. Comes with Ubuntu + Zorin + Flatpak + Snap repositories.
- Made for newbies and pros alike.
- Wine pre-installed, so you can even use some Windows programs without doing any extra configuration.
- Has great hardware compatibility and is always on latest LTS kernel.
- Great performance.
- Extremely stable because it's based on Ubuntu.
- Works great for gaming.
- Has extra proprietary drivers pre-installed for example, Intel WiFi chipsets.
- Multiple layouts, Windows like shortcuts.
- Good amount of customization.
- Since it's based on Ubuntu, most articles and tutorials available online also will apply to ZorinOS.
- Did I mention that the UI is very polished?
ZorinOS is a no-brainer choice if you want a 'Just Works™' system that also looks highly polished. Ubuntu's focus is not the user, but corporate. Just compare their home pages and you'll know what I'm talking about. It's ubuntu but better, why would you use Ubuntu ;)
I wouldn't want it to be a very common solution really because it's not that efficient and means you get updates for security when that vendor feels like it.
I'm happiest with MOST software being in the distribution.
Anyhow I know there are lots of ways to look down on Arch/Pacman (Artix in my case - dinit instead of systemd) but I have to say that it is simply much more enjoyable to use than Ubuntu or Fedora or even Debian IMO. Perhaps one day some terrible thing will happen to make me regret it but I just cannot imagine going back to the horrible burdens of those distros - upgrading from one version to another (especially on Fedora - groan), selinux, snap Firefox etc
I was outspoken in my interview about snaps. Of course this is the path to success in a monoculture.
The obvious consequence is that anybody who doesn't get paid by Canonical and wants to work in the area decides to contribute to the community based CLA-free competitor project (systemd, Wayland, Gnome/KDE/..., Flatpak), which eventually becomes more powerful/flexible/reliable due to lots of companies and individuals contributing.
(The oldest of the CLA projects was the "Bazaar" distributed version control system, almost completely forgotten now)
It does! It'd be even simpler and more consistent if they dropped snaps and only used debs!
There we are.
A shame, since ubuntu got me into linux desktop back then, but in the end they keep screwing things up needlessly.
I mean, first thing I do is install Emacs, which should, but doesn't, come pre-packaged with Linux. vim, sure. gedit, ok.
It's not some tinfoil stuff. Community oriented or driven (entirely community driven like Arch) always listens to the community. This snap and flatpaks wouldn't happen in the first place.
Use Linux Mint if you don't have time to initially set it up. Else use Arch Linux if you have initial time and patience to read. Arch is not scary like community is bad. There is a wall of text and it is intimidating. It needs time like a couple of days when you do it for the first time. But it is just about RTFM.
Flatpak and Snap are unneccessary abstractions which adds a hell a lot of bloat and for what? To make a point release distro work similar to rolling release. Nothing else. So just use a rolling release distribution like Arch or OpenSuse Tumbleweed (which I haven't used but have been hearing good things. Especially since last week here in HN).
But but, point release is bleeding edge and unstable!
NO! They are stable versions of packages and not development streams.
We seriously need to clear this confusion between a Linux distro's stable, testing, unstable repos and upstream's development branches. These two things are completely different.
When you say for eg; Firefox v222222.1 with a serious security patch is in testing branch for your distro, it means it is not tested with YOUR distro which did some hacks to make it work cos it is a point release and froze your package for a point release. *AND NOT BECAUSE OF THE UPSTREAM DEVELOPMENT BRANCH HAS BUG.* Majority of the time, it is fixed already in upstream. And even if it is a bug which is new, your package needs to be an important one. Otherwise you will have to wait till your next point release update or version bump before receiving the update. This backporting and picky patching on point releases is creating a huge amount of unneccessary overhead on upstream because hacks/patching differ on each distro.
Use any rolling release, Arch, Open Suse Tumbleweed, PCOSLinux, Void or a point release which uses unstable/testing branches (which ever is closest to upstream) like Debian unstable (Or whatever is being the distro's repo which is closest to upstream stable versions) which is essentially closer to upstream.
These are for desktop users. AND NOT SERVERS. FYI.
Just pick one. Arch, Debian, CentOS, Fedora, any niche little distro, and if you're opinionated about something theres devuan, alpine, void, NixOS.
About the only ones I don't recommend anymore are Ubuntu and Manjaro.
fedora
debian, maybe debian Sid
https://www.msn.com/en-us/news/technology/ubuntu-flavors-to-...