- 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
sudo tee <<EOF /etc/apt/preferences.d/firefox-no-snap >/dev/null
Package: firefox*
Pin: release o=Ubuntu*
Pin-Priority: -1
EOF
sudo add-apt-repository ppa:mozillateam/ppa
sudo apt update
sudo apt install firefox
Alternately, I could shill for NixOS. It's also really nice. Eventually.
I can't move work off of Ubuntu; it's too embedded now, but I'm looking for something else for home. Switching distro-base isn't so easy when you've been using it for decades though; I tried NixOS but it wasn't comfortable (Nix is a steep learning curve), though their community is top notch, and everything I do is deb based.
Looking for a way to get a modern debian (something akin to non-LTS Ubuntu) or just go all out and switch to something Arch based like EndeavourOS.
Here's how to properly install firefox on ubuntu
https://www.omgubuntu.co.uk/2022/04/how-to-install-firefox-d...
and, once you're done:
apt-get purge snapd1: https://fostips.com/ubuntu-21-10-two-firefox-remove-snap/
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".
> When will these system designers realize that the system shouldn't do anything observable without me telling it to?
My vehicle changes gears without asking me. If someone makes a broad statement like "when are these vehicle designers going to realize that a vehicle shouldn't do anything observable without me telling it to?" I'm just going to laugh at them.
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.
Immediately formatted and switched to pop OS and I've never been happier.
I'm on Ubuntu for now because Snaps can be disabled but it does make me wonder since they also dumped Unity Desktop a few years back. It almost seems like they don't care about Linux Desktop users any more.
I’ve switched all my laptops and workstations from Ubuntu to Arch.
There are rough edges here too, but on overall I’m much happier. I feel like I know how my machine works again. Ubuntu lately has been giving me that windowsy feeling with lots of things running for god knows what reason.
Also in arch the repos seems to not only contain more current versions of things. They seem to bundle more things altogether.
These days it's looking like Fedora holds that crown.
Next server though. Not Ubuntu for sure. Probably Debian?
On a bit older desktop I have seen it take 5-10 seconds just to start Chromium. And not the initial start after fresh install, it happens every single time. Meanwhile Flatpak or local packages start instantly on the same machine.
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.
The old model works for established software, but breaks down a little now that it becomes easier to write software applications.
Personally I use my distro packages for foundational stuff (DE, systemd, tools and utilities) but I use an alternative package manager (flatpak) for most other applications.
What Flatpak, Snap and AppImage try to achieve is to limit the packaging burden for both distro maintainers and application developers, so that end-user applications can become immediately available on a wide variety of distros.
Quite a few maintaining teams are the exact same people in Debian and Ubuntu.
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).
This is one of the points they are missing with snaps and flatpaks.
These formats might be OK for desktops, but are absolutely awful for servers, containers, etc., which, incidentally, are where Linux dominates.
Do I want to spend my time worrying about setting up a package cache, because a handful of updates are costing me a small fortune in transfers? Why would I need to think about what snap is doing in my small instance with a 16GB volume, when I use it to run a certainly small application?
Snaps are an absolute nightmare in these scenarios.
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.
1) a unified database for package names (it's all unnecessarily ad-hoc right now, with different distros having different policies for capital letters, whether libraries are prefixed with "lib", whether python packages have "py" or "python" or "py3" etc...
2) a standard format for declaratively describing how to build a package.
Basically, we have FreeBSD ports, Arch PKGBUILDs, Void templates, Gentoo ebuilds - they all do more or less the same thing in the same way, they all work really well, and they're all incompatible for sheerly incidental reasons. I'd like to see these incompatibilities papered over in such a way that I can write one template and generate all the others.
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.
Care to expand on this? I'm not in Ubuntu-land but can't imagine how a service with an open protocol and multiple clients forces you onto Snap.
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.
(I'm not the guy who wrote that comment but I would very much like this)
https://conveyor.hydraulic.dev/7.2/outputs/#linux
It works by downloading the Ubuntu package index and using it to look up ELF dependencies, devs can also extend the inferred list with other package names if they like. The deb installs an apt sources file and public key so users can stay entirely in the GUI. The control scripts are auto-generated but can have extra code appended to them via the config file if the developer so wishes.
It works pretty well. Conveyor is used primarily for cross-platform apps that use {Electron, JVM, Flutter, C++/Rust} and those don't normally have very complex Linux specific dependencies. Also, in practice Ubuntu and Debian and its various forks are close enough that package metadata is compatible in basically all cases.
People do ask us for Flatpak sometimes. Probably RPM is a higher priority though. Those two get most Linux users, they're stable, there are portable libraries that can make them and they can package anything without code changes. Flatpak requires mastering a new file format and the mandatory sandboxing is guaranteed to cause problems that will end up in the support queue of the deployment tool.
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.
..wait a minute
> (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.
Wouldn't this solve the same problem without adding snap/etc?
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.
I have an Arch Linux desktop (KDE + AMD), I update it every few days, and it's always fine.
I also have a shell VM that runs IRC etc that often isn't updated in months, and I run `pacman -Syyu` and everything works fine.
I've never had the infamous 'Arch updates are unreliable' issue. Is it certain packages that are more prone to it, or something?
It's just a convention not to, no? IIRC the Steam .deb comes with pretty much everything statically linked. Works fine.
If you wanted to run a 2 year old version of SomeApplication, that would work just fine. Is that what you really want? Is that what most users want?
If you instead install a snap/flatpack of the latest version of SomeApplication, you are installing also new libraries instead of the good old stable libraries your distro provides. So what's the point then?
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.
That means you need three builds to cover Ubuntu and its derivatives (20.04, 22.04, 22.10). Two to cover Debian (10 and 11). Three to cover RHEL (7,8,9) and also a few more if you want to support Fedora. If you want to support multiple architectures you get at least twice as much builds.
No matter how you put it, that's a lot more work than maintaining a simple flatpak manifest, which allows you to target all those platforms with one automated build for each architecture. And you also get the benefit of being placed in the app store and not being hold back by whatever API is the lowest-common-denominator between all those platforms or having to clutter your code base with `ifdef`s; if you want your app to use an API which was only added in GLib 2.74, then you can just do that and it'll work.
The system package manager is convenient when it works, because it's already there. But that's about it. Using it to install any random apps is a recipe for disaster, it leads to fragmentation since everyone on a different distro uses different commands/workarounds to fuck up their systems in different ways when trying to install poorly packaged software.
If everyone just used Debian, we wouldn't need Flatpak, but obviously that's not the case. Whenever you find a "linux app" that's packaged for distroA, but you're on distroB, there's a chance that it will work. That is 100% luck and coincidence, because most linux distros just so happen to ship the same family of system software/libs, sometimes even with the same versions.
Rather than leave it up to the undefined behavior lottery, a standardized non-system packaging format can guarantee that things will work across any distro. That's better for everyone involved: users, sysadmins, distro maintainers, and developers. Whether Flatpak is that format idk, but IMO it's the best overall out of the three main contenders (Flatpak, Snap, AppImage)
I don’t think building MSI installers is especially difficult; it’s kind of a set-it-and-forget-it thing. Configure Wix or Inno Setup once and then you’re good to go (on every Windows machine, no need to worry about multiple distros).
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.
Flatpaks/Snaps are almost exactly the same, conceptually, as apps on MacOS. Go look inside something in /Applications/... The .app is a folder, with all of its deps.
> 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.
"Power users" have a history of complaining about distro maintainers abandoning useful, well-understood techology because the "power users" don't actually understand the technology, nor do the understand the enormous headaches it causes distro maintainers to put a sane face on 30 year old design philosophies and continue moving forward.
The goal of distro maintainers is to STOP investing endless man hours in trying to make X work with high DPI displays, scaling, high refresh rates, a fundamentally insecure design model, and so on. The goal of systemd is/was for distro maintainers to STOP wasting endless man hours on edge cases because sysvinit didn't have reasonable mechanisms for "if anything in this dependency chain is restarted or changed, re-evaluate it" or "don't try to start this service if the mount isn't available so systems stop hanging on startup if some NFS server isn't available" or whatever.
> In the time of Jenkins et al the burden of creating bistro-specific packages is negligible.
Under the assumption that they are ABI stable, which is a bad one. Otherwise, it's the same old kaleidoscope of mapping out whether it's `libfoo-dev`, `libfoo-devel` for build requirements, whether it's a distro with a completely different naming system, dissecting the ELF header or reversing depchains in Python/Node/whatever to try to find deps and what THOSE are named in some distro, or whether they're even packaged at all, then building for every possible supported version of RHEL, Debian, Ubuntu, Fedora, SuSE, and down the line.
This is why "power users" aren't an important user model. Arch, Gentoo, Nix, and others exist if you want to be a "power user". Otherwise, extremely naive assumptions about the amount of effort expended by distro/package maintainers hand-wave the complexity away with "duh, just put it in Jenkins."
Flatpak/Snap are essentially a re-invention of putting things in /opt and using LD_LIBRARY_PATH or chrooting. Disk space is much less of a concern than it was before, and sacrificing a little space to AVOID the mess of shit above is a good investment.
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.
$ sudo aptitude install wine-stable
62) wine32:i386 [Not Installed]
Leave the following dependencies unresolved:
65) wine64 recommends wine32 (= 3.0-1ubuntu1)
Accept this solution? [Y/n/q/?]
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.
Canonical has quite a history of the behavior you're dinging Red Hat for: Mir, Unity, LXD, Juju/Charms, Launchpad, and I'm sure I'm forgetting several.
Also it’s Orwellianly named “Harmony” effort to popularize CLAs because Canonical has long sought to control upstream technologies - and consistently failed because they do not play well with others.
Read this thread:
https://web.archive.org/web/20140928104327/https://plus.goog...
Here, Upstart author and former Canonical employee Scott James Remnant wrote:
Had the CLA not been in place, the result of the LF Collab discussions would have almost certainly been contributions of patches from +Kay Sievers and Lennart (after all, we'd all worked together on things like udev, and got along) that would have fixed all those design issues, etc.
But the CLA prevented them from doing that (I won't sign the CLA myself, which is one reason I don't contribute since leaving Canonical - so I hold no grudges here), so history happened differently. After our April 2010 meeting, Lennart went away and wrote systemd, which was released in July 2010 if memory serves.
You can use any container registry (including self hosted) with docker and it will work. Last I checked, you cannot use any other repo at all with snap without recompling it to add support for your snap repo.
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.
IOW, if RH wanted to "join in", there was a cheaper path forward.
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.
For my own sanity I began avoiding Canonical's software years ago, but to me they always built stuff with shiny UI that demoed well but with performance seemingly a distant afterthought. Their software aspirations always seemed much larger than the engineering resources/chops/time they were willing to invest.
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.
I think you're right that Canonical creates and releases projects and assumes they are in charge of them, but I disagree about Red Hat (honestly not sure what you mean by "rough ideas and code"), I think they tend to see whats already out there and then throw their weight behind that, then only if there isn't do they create their own and even then they are more open about how the project runs. That difference means Red Hat gets more momentum behind its projects, and that is what counts. (of course RH can throw more engineers at stuff as well, and that also helps a lot)
Its not some sort of conspiracy, nothing Canonical has ever done has had the same amount of hate as systemd has, its just a difference in approach.
Or rather because they're proprietary, often closed-source, like Snap server.
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.
- Gnome
- KDE
- Xfce
- Cinnamon
- Mate
- LXDE/LXQt
- Several *box stacked and assorted tiling window managers and assorted glue scripts
That's a fairly solid base of "support" even if the distributions don't provide live CDs with any particular setup preinstalled.
The only exception I've seen are the "we took an existing distro, threw away half the repository, patched 2 packages and slapped our own logo on top" wannabe hipster distributions that last an entire two years before folding due to being pointless.
It's as simple as
apt-get install $DEThrough 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.
When there's a package manager / runtime that does both then I'm extremely interested.
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.
Would I rather have the deb package be up-to-date? Sure. But when I've used distributions that try to stick closer to the bleeding edge everywhere, I've had bad experiences with stuff breaking. This lets me keep a stable, well-tested distribution for everything except for the one package I want to be newer.
I can't compare to Flatpak or AppImage because I've never used them.
I really wonder how i can have such a different experience to theirs apart from really esoteric parts/apps. Not saying it's not happening.
While i'd prefer just using apt, they let me work without being a pain so i don't really care.
Is there another option for that than Snap, or Docker which is a bit too complicated to set up? (that’s not rhetorical, I would like to know if there is)
I think the argument over flat pack versus snaps may expressed in technological terms but in reality, it's just your damn ego. Let it go, it's really not worth arguing over. Use what solves your work problem and then go have a life away from computers.
@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.
I try to give the new release about a month to bake
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.
The Firefox deb (such as in 20.04) became unusable and tabs crashed when the deb was updated without a restart.
It's really down to each individual app as to whether it will work being updated in the background or not.
AIUI the new snap implementation gets everything ready in the background, so the update on closing it and re-opening it is quick.
They also still haven't fixed that disgusting ~/snap folder.
It's very obvious by now how little Canonical cares about their users.
You can disable auto-updates with eg. "snap refresh --hold firefox". See: https://snapcraft.io/docs/keeping-snaps-up-to-date#heading--...
Though not taking security updates for Firefox seems like a very dangerous thing to do.
I'm sure their enterprise side is fine, but their consumer side is disappearing rapidly.
It's useful for things I can't manage otherwise. Though I'll admit I'm in an incredibly small niche -- I maintain RPMs on COPR for fun... and at work.
I part with an anecdote! We weren't too careful on some Ubuntu systems and ended up with critical networking services in Snap.
The saving grace was: these systems are completely offline, so it couldn't sneak in updates. Note: this usually shouldn't be a big worry, but we have some debt
Not saying you're wrong, but this is surprising to me, and not my own reaction as a full-time Linux user.
">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 ;)
But during this time they regularly update packages. My kernel is always the latest version.
But I trust it because Fedora has a massive testing automated update and testing system. Every package is thoroughly tested for regressions and other things. https://bodhi.fedoraproject.org/ to look for yourself.
It is also integrated into their bug and other systems so it's a very well oiled machine.
It's been rock solid stable for me and I've been running it since 35. And upgrades are super easy.
There is also COPR which is their AUR/PPA hybrid system that lets them provide a way for users to setup their own repos but build using Fedoras learnings and systems. It's pretty cool.
Also with `dnf` RPMs are as easy as DEBs. And some of the commands are similar.
I find dnf is even smarter and better at managing dependencies.
I only ever run 2-3 commands. `dnd install` `dnf update` and `dnf remove`. Update handles the repo refresh and actually updating packages. And force refreshing repos you just add `--refresh` to the command. Otherwise it does it every few hours on its own (the refreshing of repos, not installing updates)
Fedora is a breath of fresh air after decades of Ubuntu, and then Manjaro. I wouldnt go back and I have used Ubuntu since 5.04 til 22.04
There are better packages/attempts at handling it, but I still find myself switching it to an LTS kernel if I have Nvidia or ZFS involved.
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
Here's Mark Shuttleworth in 2010:
The next major transition for Unity will be to deliver it on Wayland, the OpenGL-based display management system.
We came to the conclusion that any such effort would only create a hard split in the world which wasn’t worth the cost of having done it. There are issues with Wayland, but they seem to be solvable, we’d rather be part of solving them than chasing a better alternative. So Wayland it is.
https://www.markshuttleworth.com/archives/551
Then in 2013, Unity 8 was released with Mir.
Snap was largely developed in parallel with FlatPak (called xdg-app initially).
There was a talk about the plans at GUADEC 2013:
https://www.superlectures.com/guadec2013/sandboxed-applicati...
https://www.msn.com/en-us/news/technology/ubuntu-flavors-to-...