Linux Mint Dumps Ubuntu Snap
zdnet.com
zdnet.com
That said I hate their dirty ways. I find it even morally wrong. How can "sudo apt install chromium-browser" not install the apt package but install instead a snap? How I, as a user and also as a professional, trust Ubuntu if when I use their package manager I'm being tricked?
I don't use Windows for a reason, more than one actually. I've been using Ubuntu even with all the "weird" stuff Canonical has been doing over the years but I think this is the nail in the coffin.
Right now I'm using 20.04 but as soon as I finish some work I have left I'll install a fresh new distro.
Example rolling out pulseaudio when it didn't work well. One version I recall went from acceptable font rendering to can't stand to start at it levels of horribleness. The release of gnome 3.0 the release of KDE 4.0.
Fedora was also the only thing that worked on my new laptop, because every other distro runs a super old kernel. I'm a super happy Fedora user :)
This is even still a thing based on Centos 7 and running gnome 2 not a gnome 2 derivative but actual gnome 2.
I agree what you say is presumably so however Ubuntu LTS/Debian or arch update cadence, pick one, are still better than updating every 6 months for most users. If I want really up to date software I would like to have it now not months from now. If I have to wait I would like actual stability.
Fedora is optimized for testing new tech to be rolled out by red hat not for usage by end users. As it stands you can benefit from the sweat of their brow while not actually using fedora by using something that actually is.
Also note that if you install software from additional repos updates between versions may not be as smooth between versions. If you don't package choice is certainly going to be substantially inferior compared to arch or ubuntu.
Depends on what you need. CentOS Stream is rolling release.
> Updates in place have historically been less than awesome and it adopts new tech before it is ready with no practical way to run either the old version of fedora or the old version of the software.
There's Modularity for different software versions.
See, I'd like to use LXDE, and right now I use Lubuntu. I'm interested in switching to Debian, but then I read someone say Debian testing is "more stable than the name would suggest, as long as you follow a few reasonable best-practices" [2]. Then I look at these best practices [3] and I'm like, I don't really have time for all that...
But maybe that person is just overly cautious. So I look at Debian's page [1] for best practices and it wants me to use btrfs or LVM snapshots in case an update puts the system into an unrecoverable position. I... don't think I have time for that.
Maybe I can use Debian stable and just get software not available in Debian stable via... snap [4]. Ok, they also list Flatpak and docker, but this is getting frustrating... Is that really the best way to go about this? Because other than snap auto-updating on my machines behind my back, Lubuntu's been working great up to now.
So basically, is there a Ubuntu / Lubuntu that just doesn't have snap auto-updates? If anyone knows, I'd really appreciate it!
[1]: https://wiki.debian.org/DebianUnstable#What_are_some_best_pr... [2]: https://news.ycombinator.com/item?id=23038222 [3]: https://news.ycombinator.com/item?id=23044878 [4]: https://wiki.debian.org/DontBreakDebian#Snap
At least a few years ago, Ubuntu's LTS releases were derived from Debian Testing, while Ubuntu's standard releases were derived from Debian Unstable.
sudo apt update && sudo apt upgrade
sed -i 's/buster/testing/g' /etc/apt/sources.list
sudo apt dist-upgrade
1. Pin unstable lower than testing.
2. Configure apt/debsecan as outlined here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725934
EDIT: I was mostly wrong about the "breaking changes", but this seems like a breaking change: https://www.debian.org/releases/stable/amd64/release-notes/c...
Anyway, those release notes are huge, I'd say it is less painful to maintain an Arch system for personal use because of that. You should update/upgrade more often, but the required interventions, if any, are easy.
(yes I know there are ways to use another package manager on a given Linux distro, even homebrew, but I'd rather see a strong distro built around that idea, not even trying to provide every-friggin'-thing in the distro's software repos)
So I suppose that rules out Debian (?)
[1] https://developer.nvidia.com/cuda-downloads?target_os=Linux&...
(That's why your question sounds like a joke :) Or maybe it was a joke?)
I’ve used Ubuntu since the 2000s and never really branched out to explore different distros. I’ve added LWN’s Distributions List [1] to my reading list to lessen my ignorance.
Sure the daunting setup process would fall into the "a hobby" category but once it runs it tends to just keep running as long as you update it from time to time.
Using it now for ~5 Years and in that time I had two times problems one was that the new kernel version didn't work with my laptop and another which was fully my fault by doing some "special" boot setup with some custom self written package and not maintaining it. Oh and the only reasons they where problems was because I never setup recovery boot or boot prev. kernel version.
Besides that I remember having more work with maintaining Ubuntu when I used it ~8 years ago.
Also disclaimer I had some more work like setting up edurom with network manager without using any proper UI for it (nmtui...). It's doable but not properly documented. But non of this is a problem if you "just" use Gnome or KDE or at last part of the tooling from Gnome/KDE.
EDIT: But Fedora is probably what you are looking for. Widely used, well maintained and normally up to date.
https://www.archlinux.org/packages/core/any/netctl/
Why in the fuck is dialog an optional dependency?
Which sort of ties into my next problem which is that Arch simply isn't opinionated enough. Which is fine for people who want that kind of experience, but if you used Ubuntu before and you want a similar "install and go" experience, Arch really isn't the right answer. It is if your goal is to tinker with Arch, but that isn't what everybody wants.
Not all people who use netctl want wifi-menu.
> it isn't mentioned anywhere in the documentation
It sure is. https://wiki.archlinux.org/index.php/Installation_guide -> https://wiki.archlinux.org/index.php/Network_configuration -> https://wiki.archlinux.org/index.php/Netctl And there on the top of the netctl page it lists in a table dialog as a dependency of wifi-menu.
> Which sort of ties into my next problem which is that Arch simply isn't opinionated enough.
Maybe, but not all people have the same opinions...
> Maybe, but not all people have the same opinions...
Yes. And that's fucking fine. Arch Linux isn't opinionated. Which is great, but not what I (or others) might be looking for in a distro.
# cfdisk /dev/hda && mkfs.xfs /dev/hda1 && mount /dev/hda1 /mnt/gentoo/ && chroot /mnt/gentoo/ && env-update && . /etc/profile && emerge sync && cd /usr/portage && scripts/bootsrap.sh && emerge system && emerge vim && vi /etc/fstab && emerge gentoo-dev-sources && cd /usr/src/linux && make menuconfig && make install modules_install && emerge gnome mozilla-firefox openoffice && emerge grub && cp /boot/grub/grub.conf.samp le /boot/grub/grub.conf && vi /boot/grub/grub.conf && grub && init 6
That's the first one... http://bash.org/?464385
Sure, if you want to remain a Linux beginner forever, the Arch docs would be terrible.
> Don't worry about getting all the packages you want - you can easily install more of them once the basic system boots by itself. The only exception to this rule is installing any packages you need for setting up internet connectivity. These packages usually are:
> dhcpcd
> wvdial
I had fresh install recently, rebooted three times in LiveUSB to pick wifi-menu, wpa_supplicant, dialog (rechecked with pacman -Qe). That's fine, I still use Arch. And it is good Manjaro provides another set of defaults.
> DON'T PANIC!
> The Arch Linux system is assembled by the user, from the shell, using basic command line tools. This is The Arch Way.
I miss it much http://web.archive.org/web/20080720082349/http://wiki.archli...
I find arch refreshing.
by the way, I like yad.
Arch is pretty much exactly as opinionated as I want a distro to be. Hell, there are LOTS of folks who think it's too opinionated for forcing you to use systemd. The real installer is pacstrap, and it installs, I think, 300+ megs of stuff. That's all someone's opinion. And keeping it to just 300 megs is an opinion too, I guess.
EDIT: Okay, re-reading, and it sounds like installing 20 packages is a pain. But when I used Ubuntu I had to go through way more to get it how I liked it (and OS X is a nightmare 2 hours of clicking menus and buttons, and installing from web pages). I don't remember all of it now, but I had to get rid of the weird mini-vim and replace it with neovim, strip out Libre Office (nothing against them, I just have no use and it's a pain to wait for the giant updates all the time), my printer drivers were on a webpage somewhere, not the repo like Arch, etc. Ubuntu is WAY more work for me to get set up with just because removing and replacing is more work than installing.
To clarify, I doubt that Manjaro is more debuggable than Arch, considering it's just Arch+added complications.
EDIT:
> I'm tired of all the tinkering. I'm tired of the additional cognitive load of all the things I have to make sure is configured right. I already waste hours of my day just getting tooling to work for whatever god awful language I have to work with that day. I just want things to work. Manjaro just works.
I definitely understand that, but I feel that if I went to Manjaro or Debian or whatever the added complexity would make debugging much more annoying.
People say this, but I've found plenty of reason to reinstall Arch (none of it necessarily having to do with Arch, and more trying different distros out of curiosity and Arch remaining my main distro). I always have these discussions with Arch veterans who seem so incredulous about my frustrations with Arch. And I sort of chalk it down to the fact that I ended up installing Arch anew more often than once a year and the last time you or some other vet installed Arch was years ago. I think there's a fundamental disconnect between Arch vets and beginners (or even intermediates), which is clearly shown by the scrapping of the excellent beginner's guide.
I gather that you simply want something more opinionated than Arch, and that is OK, even the BSDs have a more opinionated install procedure than Arch.
But FTR scrapping the "Beginner's guide" was done for really good reasons: it duplicated the content of other Wiki articles, which is a maintainability nightmare, and was too opinionated for Arch. All the content should still be accessible by wiki links to other Arch wiki articles.
Yes, this is why I emphasized the "install and go" aspect of Manjaro. It requires a certain amount of "opinionatedness" by the maintainers, which of course isn't a priority for Arch, which is also fine.
I saw and understood the reasons for scrapping the beginner's guide. I still disagreed with it. All I saw was that the Arch community was unwilling to provide for beginners. Yes, it's a lot of effort and it is to a degree duplication, but it's duplication in the same way that Simple Wikipedia is a duplication of Wikipedia. It sort of is, but it sort of isn't.
It's duplicated effort, definitely, and if you don't prioritize onboarding beginners, then it's also wasted effort. But as somebody who personally used the guide a lot, as somebody who takes no pleasure in scouring through 5 different 30 page long wiki pages to find an answer to something trivial, the documentation as is simply isn't an adequate replacement for the beginner's guide. I've accepted that the Arch community has decided that it's the best solution, but I won't stop criticizing them in discussions like this for sacrificing such a great resource just because we happen to have different priorities.
Ubuntu gave me simple install. Once I've started tinkering it become broken. Following Installation guide and Beginners guide I got stable system with internet connection without Gnome toolbar widget. I could build on top of it.
These days I stick with Arch because of fresh packages, rolling release, makepkg and AUR. Just looking at https://wiki.archlinux.org/index.php/Network_interface is enough to stick with wifi-menu / wpa_supplicant.
It can get really technical really quickly, and you end up making decisions almost randomly if you have shallow or no knowledge of a subject.
It's like ending up at the voting booth, and knowing what president you want, but then your momentum fades and you want to vote along party lines and get out.
I wonder for example, how many people are technically prepared to choose EFI vs BIOS boot, and if they want a bootloader, which one.
I think the thing to keep in mind is that by making the decision, even the wrong one, you build up a valuable pattern in your mind and you are growing.
That said, it's harder on arch to do more involved things like encrypted boot, selinux or virtualization. But when you do it, you can consider yourself a post hole digger.
I miss Arch though, I learned a lot about Linux through it, but every hour spent fixing something is an hour less spent on actual work.
FWIW I switched from Ubuntu to Arch recently and to me the setup was a breeze. Just follow the instructions. I'm kicking myself for not doing it sooner.
> If you have linux experience Arch Linux can be a good idea
Something doesn’t add up there...
If not, what other distro allows this (other than Nix)?
This is the main feature I'm looking for.
https://developer.nvidia.com/cuda-downloads?target_os=Linux&...
Been using it for years, including one installation of their rolling release, Tumbleweed, which is surprisingly stable for a bleeding edge distro.
Until I started using FreeBSD on my desktop a few months ago, I had run Debian on most of my personal machines for ~15 years, and often on work machines. For the most part, I was able to track the testing repo and "apt-get dist-upgrade" once a month, and not really worry about anything. Very few breaking changes, and when there were, it was usually related to proprietary drivers (thank you NVIDIA).
IME with Ubuntu on work computers, staying up to date is a much bigger hassle. Besides some of the out of the box settings being brain dead (IMO, of course), upgrading between releases is a pretty big deal with major changes and a lot of breakage.
I don't use Gnome or KDE (on either OS), so that probably helps, but I still always plan for Ubuntu upgrades to break stuff on me.
With Debian, I configure it how I want, and then it just stays out of the way. With Ubuntu, I feel like Canonical is always trying to change my mind and push things on me.
That's very ironic, because I've found that Ubuntu's shenanigans always end up requiring more time and effort from the user than, say, install Debian and just get on with your life.
There’s also not as much screening before an update is allowed, as there would be for the default Ubuntu repos (considering that 1-2 years into a LTS release you’re probably bringing in dependencies from PPAs anyway, I don’t know if this matters much).
sort of like df -t ext4 -t ext3 -t vfat ...
Simple: they decided that maintaining the chromium .deb takes too much effort, and that snap is making that easier. So they moved it to Snap.
But there are many users out there with existing installations who have selected chromium as one of their installed packages. And so as not to keep said users without updates, they decided to migrate them over the best way they found.
I'm not completely sold on the snap ecosystem because of some technical issues, as well as the issues of fully automatic updates. But this particular question has been given a lot more air than it deserves.
Their whole distribution is copied from Debian. Is it too much effort to just copy and distribute the upstream package, like they have been doing from the very start?
If you don't like that, use Debian directly. It's a good distro that has stood the test of time.
The process for installing proprietary drivers like NVIDIA is the same for both. I just added an extra buster-backports channel then apt installed it. I chose KDE[1] as the default desktop at install time and I was off to the races for my workstation. It was also easy to install Debian on my Dell laptop too, I just had to use the special firmware-ISO to have the Intel WiFi driver built into the image.
All of that's to say: one of the reasons to use Ubuntu for a while has been that they made installing proprietary drivers easy, and that could be a serious pain-point worth alleviating. But now it's just as easy on other distros too, perhaps due to the relevant drivers being better packaged/supported for Linux by hardware companies.
[1] I was also really surprised how nice and smooth the latest KDE experience is after being on tiling window manager setups for years. It's fast, looks good, can configure absolutely everything, which I like, and it is really complete in terms of application coverage.
This happens for a technical reason: without it, an upgrade from the older Debian that shipped MySQL will not transition you to MariaDB, but leave your database broken because Debian no longer ships MySQL. The package was adjusted to provide the upgrade path. apt provides no alternative. This mechanism is called a "transitional package".
I'm providing the MySQL/MariaDB example not because I think it's wrong, but because hopefully you'll see that it's the same pattern being used by an entity you perhaps better trust, and that might give you some confidence that it's technically the best approach available.
The same is going on here. Users who have Chromium installed on Bionic, upgrading to Focal, expect to still have Chromium. This is why installing "chromium-browser" in apt results in the snap being installed.
It's not a dirty way, and it's not morally wrong. It's being done for a purpose.
When you install Ubuntu you are consenting to receive the choices that Ubuntu has made for you.
If you insist on using Ubuntu but never using a snap, you can configure apt to never install snapd. See apt_preferences(5).
I've got to disable global keybinds that shadow shortcuts for fucking readline and basic text editors.
Fix their broken themes to shut up warnings that will drown out logs of applications that couldn't care less about themes.
Fix XDG settings to remove turd directories in home directories that nobody on earth has ever used and applications ignore.
Search the three or four different places they put configuration to fix whatever new setting has screwed things up, whether that be to move the close window button back where it always should have stayed, remove hot corners, or something new.
And yes, remove snap so I have usable output from mount and similar.
Not to mention how broken their LTS and distro upgrade process is. I shouldn't need to edit files to upgrade distros, and it shouldn't break basic applications or drivers.
Aside from the philosophical concerns I ran into a lot of glitches with various snap packages, frequently resulting in lost or corrupted data. And the sandbox approach prevented certain filesystem tweaking I previously took for granted. Overall I didn’t see the benefit and didn’t have time to futz with it.
I’m curious if there are any distros with a recent version of Gnome and also a sane package manager.
Samsung has followed suit w/ Android. Once an update is available, the user can defer it three times before the phone is rebooted. Not even Apple pulls this crap.
In the long term, just avoid samsung products that don't respect your authority as the owner.
And yes, Arch takes in the upstream vanilla packages, though there are testing phases before updates reach stable repos. I'm not sure any of this is a bad thing. It also means you don't have to wait 6-12 months for the newest version.
Updates are only installed when you run pacman (or a pacman wrapper/replacement). But I guess you mean changes to a package in the repository with "package upgrades straight from the developers".
There are two sources for arch packages:
- The official repository, - The AUR repository
The later one does indeed allow maintainers to arbitrary update or remove packages. It provides just a way for _users_ to provide custom packages to other users. The responsibility for reviewing them lies with the person using them. This is clearly communicated. Also most AUR packages do not contain any code but just install instructions which pull the code/binaries from their original source (e.g. github/github releases/the website of the project for which the package is). So reviewing them is normally quote doable. The only annoying to review AUR package I can remember is tor-browser.
With regard to the official package thinks are actually pretty similar as far as I know (but I don't rally know) except that not everyone can publish thinks there and you have a group of "trusted" core maintainers.
In the end arch is a distro by the "experienced" Linux user for the "experienced" Linux user without to much financial backing.
Not that there still are thinks like a security group which tracks CVE's and similar but it's fully based on volunteers.
This makes it quite a fascinating choice as any choices wrt. maintenance comes from some dev wanting to use it on their system.
But yes if you don't trust the core maintainers don't use it.
Also it might not be appropriate to be used on cooperate systems due to company policies wrt. legal liability reasons.
Still you also trust many other software maintainers solely based on a good reputation and for arch it's in the end the same.
Also besides pacman and probably some other minor thinks Arch doesn't do any code. It's just provides code other people wrote (sometimes with publicly known patches) to the user, sometimes pre-compiled.
No.
> “peer review”
I am not sure what you mean, and I don't know that much about Arch developer and Arch maintainer protocols; but the whole thing is more transparent than Debian: everything, including the PKGBUILDs and the rare patch is accessible through public git repos very accessibly and visibly linked from the web page of each Arch package. Debian also has public git repos AFAIK, but finding them and navigating the directory hierarchy is more difficult.
> alias df='df -x tmpfs -x squashfs -x devtmpfs'
function df { OUTPUT=$(/usr/bin/df $@) snaps=$(echo ${OUTPUT} | rg "^.+/snap/(.+)/.+$" -r '$1' | tr '\n' ' ') printf "\x1b[33m\x1b[1mFILTERING SNAP MOUNTPOINTS:\x1b[0m\x1b[33m\n$snaps\x1b[0m\n\n" >&2 echo $OUTPUT | grep -v "/snap/" }
Reading the thread with the discussion on it, seems there was real contempt towards letting the user decide not to update their packages.
"After a refresh, the next refresh can be delayed by up to 60 days, after which a refresh will be performed regardless of the refresh.hold value."
Not sure if that would work with Ubuntu though ;)
When you create a snap package and post it to the Snap Store, you only get the default limited rights for your snap. For example, your application is not able to access external disks. But if your application has a real case to do so, then you need to request to have that access added to your snap.
Just learnt from this thread that apt-install will install snap! I'm running Ubuntu 18.04 + i3 (Dell Developer Edition) but will change to Debian.
The argument about "latest == safest" may have some validity when it comes to browsers, but for everything else a notification that there is a new version would be more than enough.
Although apparently they are considering[2] adding the option to disable auto-updates.
[1] https://news.ycombinator.com/item?id=22972661 [2] https://forum.snapcraft.io/t/re-visiting-update-control-on-t...
Taking a leaf right out of Microsoft's book, I see.
Snaps have been my preferred method of installation for a few years now. I really like how I know where the files are being installed to and if I uninstall the software it will be removed cleanly. I also like how for most software snaps contain the latest release of the software which has not been my experience with distro specific apt repos. I can even install beta, nightly or previous releases very easily using snap store channels. I've never experienced any package manager on any OS that has made it this easy.
I've also developed about a half dozen snaps, some of them were open source contributions to existing software, others were my closed-source projects and one was some contract work for a third party who wanted to snap their existing software for easier distribution. And although there were some pain points, I found the process and YAML based manifest file to be far better than most tools.
My only gripe with snaps at this time is that there is no system like PPAs so if you want to use snaps for your privately distributed app then you need to do it through Canonical and more advanced control features will cost you extra.
Docker was a complete mess, .net Core was complete hell trying to figure out paths. Certainly stuff not meant for the just-slightly-above dummy, and even less for the actual dummies.
Also Telegram was really buggy a few versions back and it took several releases for notifications to start working again. It would have been nice if I could roll back and pin while they went through the first few 2.0 releases.
It is actively being worked on.
Granted, you need to pay for your own separate Snap Store, unless someone makes the effort to create a third-party implementation.
Basically if you have multiple millions of dollars you would be able to distribute your software to probably nobody.
Compare this to making a repo for any platform that allows multiple repos where this is fantastically trivial.
I don't know the Apple ecosystem, but adding a 3-second-delay to every opened app because of a questionable sandbox whose security benefits are hypothetical doesn't sounds like “caring about usability” at all…
Appimage is a better solution than snap overall, and it solves your issue with having yo go through canonical, but the whole point of snap is forcing you going through canonical…
But that's exactly like the Apple ecosystem![0]
[0] https://sigpipe.macromates.com/2020/macos-catalina-slow-by-d...
The philosophy they mirror is the "Walled Garden" and "complete control over user devices" though I'm not sure if even Apple is doing the latter. I don't see any practical reason for denying experienced user the choice. Snap may be technologically most advanced software distribution solution (it is not) but it benefits only those who control it, and in case of Snap, that is not you, the user, but Canonical.
Snap breaks this. A snap package can update itself whenever it wants and then you the user are just screwed when things don't work together anymore. So in effect, snap breaks the main benefit of Linux for deployment and the reason why I use Linux in the first place.
Every since they started with ads and affiliate links, I've been sceptical of Ubuntu. But Ubuntu 18 is still used as the base image for many docker deployments. I predict that this will change with Ubuntu 20, exactly because the snaps have made Ubuntu 20 unusable for reliable docker deployments.
I'm glad that mint is stepping in to provide a viable alternative.
Plus I want my workstation to be as similar as possible to the deployment container to make debugging easier. So if I feel uncomfortable using Ubuntu 20 for my workstation, I should probably switch my deployment docker base image, too.
They started building it for IoT, whereas Flatpaks were designed for the desktop from beginning.
It is immutable systems that help you with reproducibility.
There is no actual change between the snapd setup in Ubuntu 18.04 and Ubuntu 20.04. Where do you get info on unreliable docker deployments?
It looks to me that the dislike is emotional in nature.
It is too fragile to install yourself all the pieces.
It's just that I know that I cannot update it to Ubuntu 20 without snap breaking things for me.
A dirty workaround would be to get the `.snap` package from the store, then install directly from the local file.
$ snap download hello-world
Fetching snap "hello-world"
Fetching assertions for "hello-world"
Install the snap with:
snap ack hello-world_29.assert
snap install hello-world_29.snap
$ snap install hello-world_29.snap --dangerous
hello-world 6.4 installed
$ hello-world
Hello World!
$
>
> There are four system-wide options that manage how updates are handed:
> - refresh.timer: defines the refresh frequency and schedule
> - refresh.hold: delays the next refresh until the defined time and date
> - refresh.metered: pauses refresh updates when network connection is metered
> - refresh.retain: sets how many revisions of a snap are stored on the system"
>
I think people would be much happier with snap if there was a `refresh.off` option.
If that's too over-the-line for Canonical, a `refresh.prompt` with a dismissible nag-message would be better.
There is no option to permanently disable auto-updates which is the problem being discussed.
If I install a docker image with version A and it auto-updates tomorrow to version B then the docker container is no longer reproducible.
But people seem to like flatpaks, so I don't think it's emotional. More a poor implementation.
Dev Ides and similar are done just fine by normal package managers as they tend to find enough voluntary work and dev tend to not like thinks like auto updates and similar for them as long as they do get updated.
Only for 3rd party non developer tools does it make sense like office tooling, music apps and similar. Ironically not necessarily for many games.
But for this we have alternatives, like flatpack which seems to be less prone to business bias due to being fully open source with a clear statement against any form of vendor lock-in. Its endorsed by Read Hat, adopted by Clear Linux and the last time I looked at it I remember that I preferred the way they did it over snaps. Also it's not a "Ubuntu thing" but a "for all distributions Linux thing" and seems to be slowly become the standard for "packed/distro decoupled" apps...
Also just to become clear I could imagine that at some point Flathub will have some commercialization, but even if it does so and fails it wouldn't kill flatpack (while the Ubuntu app store not being much trustable kinda partially killed snap for desktop users).
- Linux Mint
- ElementaryOS
- Pop!_OS
Take a hint, Canonical. You guys made some great strides towards being less silo'd by dropping Unity and Mir in favor of vanilla GNOME + Wayland, but you're still all-in on snaps for some reason. Are the handful of proprietary software companies that want an easier installer for Linux really worth it?
Snap packages are good, and such efforts may help get the Linux desktop rise over the 3%.
Lenovo announced they are fully supporting Ubuntu desktop for two lines of computers.
https://fedoramagazine.org/coming-soon-fedora-on-lenovo-lapt...
If you're suggesting that we all need to rally behind everything Canonical does because Ubuntu has the best shot of propelling Linux into the mainstream, I would say that's all the more reason to hold them accountable for decisions that the Linux community finds unpopular. Many don't like snaps. Don't force snaps on us through duplicitous means like the chromium installer. Why is that bad for open source?
Source: https://news.lenovo.com/pressroom/press-releases/lenovo-brin...
What I see on HN is perpetual bitching and anti-Ubuntu sentiment. As if the Linux desktop is a zero-sum game. One wins and the rest are gone. In the harsh reality, if the Linux desktop gets like 5% or more, it will signal other companies to start supporting.
The chromium issue has been around since October 2019, https://snapcraft.io/blog/chromium-in-ubuntu-deb-to-snap-tra... Ubuntu cannot support a deb package because Chromium is huge in their dependencies and cannot provide timely updates. Therefore, there is only a snap package. And, what happens if the end-user tries the chromium browser? The system transparently installs the snap package instead of presenting an essay to explain the full background.
Is it so difficult to say respectfully, "everyone do your thing to increase the marketshare of desktop Linux so that it eventually opens the floodgates of support".
You cannot increase the Linux desktop marketshare by staying within the 2.7% of the Linux desktop. You just need to attract new Windows users, not steal Ubuntu users.
A lot of people recommended Ubuntu and that I believe is a problem. I got it wrong too. Ubuntu does a lot of experiments on its users - Pulse Audio, Unity, now Snaps. Each time a lot of fuss. It means technology is not ready.
It would be fine if rolled in separate distribution Exbuntu (experimental Ubuntu) and rolled to masses once feature becomes popular, but no. Those who listened to my recommendation would see bugs and that is zero-sum game.
But we can easily resolve it - recommend no nonsense distros - Linux Mint, ElementaryOS, Pop!_OS, Debian. And that's already happening on this page. Ubuntu may even encourage that. Everyone would be happy.
So what is wrong with silent snaps Chromium install? Those who use apt are sophisticated enough to chose. And "issue has been around", have you red The Hitchhiker's Guide to the Galaxy? “But the plans were on display…”
> You just need to attract new Windows users, not steal Ubuntu users.
That's gross. Have you red what people say? Those who switched to Linux because of such moves from Microsoft. I'm fine with Ubuntu destroying itself. I do not use it. No one steals Ubuntu users, that's Ubuntu who destroy its userbase.
Isn't it possible to ship a simple deb that handles the system part (menu, icons, etc) and a single static executable?
Can't they just replace the Chromimum package with the one in Debian?
There is no deb package in Ubuntu, so the system is setup to transparently install the snap package.
Then they would need to review all Ubuntu packages for snap injection and overlay them. Sure that might be doable automatically but is a bit brittle.
It also means the user wouldn't learn what is going on.
It will upgrade a running application without telling the user. Then it will remount all folders in use by the running application in read only mode. As such, your chromium will start misbehaving, crashing, extensions will start failing, it won't save cookies or remember tabs after restart. DBeaver won't be saving your .sql scripts. Snap developers think users are precogs. That users without any foreshadowing will close application before snap silently upgrades it behind the scenes.
Also Snap does really weird things as a container. I run multiple VPNs each within own network namespace. So something as simple as :
as root: ip netns exec myVPN chromium fails with execv failed: Permission denied
Both of these problems exists for years.
There are keys to configure when, and if, you get updates, https://snapcraft.io/docs/keeping-snaps-up-to-date
The total Linux desktop installation base is around 2.7%. Without automation, the Linux desktop does not look like it will attract any significant number of Windows users.
One gets a maximum of 60 days, that is all. Through a snap proxy it's possible to hold off longer, but then the proxy needs to talk with the snap store periodically.
Why people are upset is, I believe, that Canonical forces people to accept any and all changes to the installed software, without being able to guarantee perfect backwards compatibility for all upgrades. Obviously, neither Canonical nor anyone else can make that kind of promise for all software out there.
Canonical should not force updates on people; let people take care of backwards compatibility; let users turn the auto-update on and off and allow users also to freeze package versions (and their system configuration), if the users so please.
Also, not sure I understand the point about automation. There is automation already today in Ubuntu through autoupdating .deb packages. It is nothing inherently new in Snaps.
One problem with measuring Linux desktop installation base is that Linux users are often the people who turn off telemetry, call-home, employ DNT, run ad blockers, run third party script blockers, and so on. I wonder how much this skews the results.
You can "snap download" and "snap install" to bypass any updates.
Do you mean the obvious `sudo snap set system refresh.hold="$(date --date=+100years +%Y-%m-%dT%H:%M:%S%:z)"`? (no error)
edit: Ah, that silently stops working after 60 days, nvm.
So we're the beta testers for Snap. Awesome. Nothing I want to do more on my day-to-day desktop than to be an outsource QA team to debug Ubuntu's software. Thanks for making 'beta test' the default, just like with pulseaudio and systemd. I look forward to the one day in the future when snap doesn't suck too. Except, nope. No more Ubuntu.
I guess tossing Windows in there is some ad homen attempt to deflect, because the comment doesn't otherwise make any sense. Is "we'll screw our users until our software works reliably" somehow an answer to the M$ hegemony?
https://forum.snapcraft.io/t/snapped-app-not-loading-fonts-o...
I'm not sure whether Linux Mint is also affected by this issue, but it's clear that Canonical doesn't perform quality assurance for Snap on any Linux distribution other than Ubuntu.
With snap packages you get companies like Microsoft to deliver a native package for Skype, Jetbrain to deliver their whole developer portfolio, Spotify their music thing, etc. They can do so because they are basing the work in a common, stable runtime.
Okay, but... It is a backdoor. A user trying to install a deb get snap shoved down their throat.
> They can do so because they are basing the work in a common, stable runtime.
And none of that requires taking control from the user.
Did you switch to the snap package yourself?
That said, the update auto-restore almost always works in my experience. I've been running the nightly channel for a while (which updates once or twice a day) and it rarely eats tabs.
I think the Ubuntu 20.04 runtime should be better than Ubuntu 18.04. More fixes, new features and updated versions of packages.
> "In the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. Applications in this store cannot be patched, or pinned. You can't audit them, hold them, modify them, or even point snap to a different store. You've as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it installs itself without asking you."
The chromium transition was announced in October 2019, https://snapcraft.io/blog/chromium-in-ubuntu-deb-to-snap-tra...
Ubuntu was not able to maintain chromium as a deb package, and chromium is not the default browser in Ubuntu. Therefore, it has been packaged as a snap package. Since there is no longer an apt package, what should happen when you "sudo apt install chromium-browser"? The usable decision was to install the snap package of Chromium instead, https://snapcraft.io/blog/chromium-in-ubuntu-deb-to-snap-tra...
The snap package of Chromium has been in testing for two years already. The snap package page is https://snapcraft.io/chromium You can view the installation log, with the list of operating systems that have installed it.
Those aren't the only two options :) .
That's not to say that the alternatives have no merit. They do, because they're driven by developers who do have valid differences of opinion from Canonical's approach and want to do things differently. That's always going to be the case because different people are always going weigh things differently and take different directions on things.
But the rhetoric usually becomes louder than the valid discourse.
Take this headline for example. This is entirely about the politics. The technical merit of the Chromium packaging being a snap doesn't apply - because the alternative would be a deb provided and maintained by a distribution, and Mint aren't doing that. Ubuntu switched to a Chromium snap because maintaining the Chromium deb is no longer practical. Many snap critics will tell you that distribution debs are better for curation and trust reasons. That's not an option here, because Mint is not even providing that as an alternative.
Snaps are fully controlled by Ubuntu - for me it's a non-starter.
I'm very pleased with their developer centric approach. They also apply very nice UI tweaks, a tiling WM and a useful set of gnome extensions. Loving it.
Kind of like in Windows, where your computer suddenly shuts down to apply a service pack while you were in the middle of an important World of Warcraft raid that you were planning for weeks.
There's always a trade-off between keeping your system secure and being available. Most people don't like to trade off availability, and it makes sense.
Worse yet, when you update ahead of time and drivers or other parts of update are incompatible. Stable configurations are important to a lot of people.
I have however, lost count of how many times some piece of technology has failed because someone didn't read the manual.
As someone that administrates a small handful of workstations and a server or two, I just don't get what these tools buy me. It seems that usually installing an application via one of these methods has negative externalities (e.g. some things not working out of box, like access to user file, or ability to play audio), or most often the applications simply don't work at all.
If snaps were able to work properly out of the box, they could be good if they reduce the work for the packagers. That said, I've burned enough of my time trying to debug broken snaps that I won't entertain ever using them again.
I guess if it works for someone else's use case though, that's nice. However it sure seems pretty grubby to install a snap when the user clearly intended to install an DEB package via aptitude.
I will say, I've had very positive experiences with AppImage. I haven't really dug into the technical details of how these different approaches work yet, since I haven't had any reason to, but every AppImage I've wanted to use has always worked perfectly.
https://snapcraft.io/blog/chromium-in-ubuntu-deb-to-snap-tra...
Ubuntu could not maintain a deb package, and keep it up to date. Therefore, there is only a snap package. When you try to install with `apt`, you get chromium installed transparently instead of getting a message that describes what I already explained. The breakage would be bad if there was nothing installed when you did a "sudo snap install chromium-browser".
AppImages are monolithic images, with no or minimal protection of your computer. I think they are the equivalent of the Windows packages in the 90s and 00s, that were distributed with CDs with little idea where they came from.
Nothing. They buy control over you for the distro publisher though.
Mint had already pretty-much committed to flatpak years ago, so this came as no surprise. Clem's said there'll be a way to install Chromium. Tempest in a dongle.
And this is why it's a double edged sword. I like packages to be validated by maintainers. I don't want a new Telegram app update every day. Just now it broke and I have to wait until the developer pushes the new build to the snap repo.
It's like it's suddenly okay that everything needs to be rolling release.If I want that, I'll use arch.
1. Using platform or app flatpak extensions, one can plugin compilers and runtimes so they are available inside the sandbox.
2. One can add shims that launch programs outside the sandbox using flatpak-spawn --host.
ls -l /var/lib/snapd/snaps snap list
The directory `/var/lib/snapd/snaps/` shows the cached .snap packages, including the recent versions in case you want to revert to a previous version.
I see in the comments a complaint that you don't want the developers upgrading their apps whenever they want ... really? Because that's my number one complaint for debs/rpms too. You can't install specific versions, you can't install multiple versions side by side and installing a newer version of one package can break your system due to its dependencies. Snaps can't possibly be worse than this and they aren't.
And on the server-side I understand wanting to review each updated package, but on your laptop, how often does one do that anyway?
For the general population automatic upgrades are a net win. The same moaning happened when Firefox switched, following Chrome, to automatic updates and fast releases and people now love that, including me. You trusted the app developers as soon as you installed that app on your computer with full privileges. And most apps don't have reproducible builds, even if the app is open source, trusting the binary you're installing is also a leap of faith. Unless the OS can sandbox that app, installing any app is about trust in a brand and faith. And debs aren't sandboxed.
When I switched to MacOS, 6 years ago, I missed Ubuntu's repository, I hated Homebrew, I hated installing apps by copying them from volumes mounted from .dmg files. But not anymore. I rarely have issues now. Experience could be improved of course, I sometimes want versioning, I want reproducible environments, which is why I'm experimenting with Nix (see https://nixos.org/). The first thing I did on a fresh Ubuntu 18.04 LTS box, couple of months back? I searched for "Firefox Developer Edition" and failed to find a PPA for it or a beta channel that seems to be up to date.
Speaking of which, people complain about Snap being insecure, however I've never seen an Ubuntu/Debian workstation that doesn't make use of insecure PPAs.
Also packaging apps via DEB files is hard. I tried building DEBs for my server-side apps, but unless the process is automated via tools that are not language/platform agnostic, I found it hard, with documentation severely lacking.
---
This is one big reason for why Docker is now the preferred distribution mechanism for self-hosted apps on Linux servers. It's very easy to create a Dockerfile and the result won't infect your system with crap.
I have yet to try out Snaps, maybe some of the critiques are warranted, but it can't possibly be worse than the status quo. The only problem, a major one, is that yet again we've got no agreement between vendors. But that's sadly the Linux ecosystem, a genuine Tower of Babel.
No, I don't.
First, most apps' code won't run as root. Only install scripts, written my distribution's maintainers, run as root (except for core applications, of course).
And secondly, I trust app developers to write their app properly (to a certain extent), but not to write install scripts that won't mess with my system, because it's outside their domain of expertise.
This brings up another drawback of deb/rpm packaging, though: you need root access to install anything. I'm not sure about Snap, but Flatpaks can be installed and used by an individual user.
snap login
echo 'alias sudo="sudo touch /evil && sudo' >> ~/.bashrc
Install Chromium on Linux Mint and you'll have code run as root that is not written by your distribution's maintainers. Because Mint won't ship the snap, and nor are they shipping a deb that they maintain. You'll have to install a third party deb or equivalent.
The "universe" repository has tens of thousands of packages. Do you know that a majority of them are not maintained because it is too much effort and not many helping hands?
And we "solve" it by allowing the inclusion of different, incompatible, versions of packages into even bigger packages. Sorry, but that's not a solution. It's the technical debt equivalent to payday lenders.