It's actually worked well for me. But, I never want to see a program on my Linux boxes automatically running root over a network connection for any reason without my specific say so, never mind just to install Chromium.
The dislike on snap packages looks to be too emotional.
It resembles the issue with people feeling that 5G affects their health. Obviously, it does not. But the belief is so intense that they get actual observable symptoms.
I dumped Ubuntu over Snap. Maybe I’m just ignorant but it seems like allowing developers to push software updates without any review invites the same sorts of issues we’ve seen on npm, with very high risks for certain use cases. I don’t want that kind of relationship with my OS, forced updates are why I ditched Windows in the first place.
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.
> forced updates are why I ditched Windows in the first place
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.
As a short term solution, you can use netguard and always have it run in lockdown mode. It works on most phones and doesn't require root. You can use it to whitelist app access to the internet (inc. blocking samsung and google play updates). It's also open source.
In the long term, just avoid samsung products that don't respect your authority as the owner.
Doesn’t arch also allow arbitrary package upgrades straight from the developers? Again I’m pretty ignorant but my impression looking at it previously was there isn’t any sort of “peer review” by repo maintainers.
You're never forced to update. I'm don't even think Arch natively supports automatic updates. You can also tell pacman to skip a package from being updated if you're aware of a problematic update but you want to update the rest of your system.
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.
I think what he/she means is that core maintainers (or AUR maintainers) might be able to change a package without another core maintainer (or AUR maintainer) reviewing it.
Afaik, upstream packages aren't changed by Arch maintainers. It's the whole point of using Arch. And if you're using AUR, you'd better be checking the PKGBUILD (because no, it isn't verified by anybody). At the very least, you need to be checking where the package is being downloaded from.
Arch is kinda the I can do everything reliably distros if you know how to set me up.
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.
> Doesn’t arch also allow arbitrary package upgrades straight from the developers?
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.
Manjaro is simply fantastic. I switched when upgrading Ubuntu failed again. Hardware detection is great, defaults are sane, and pacman is a great package manager. The AUR is also amazing.
Cluttering up df and mount output is a real problem. They are useful tools - cluttering their output makes them much less convenient / more time-consuming to use. I have about 8 mounts for snap and like 15 for cgroups here. And actually about 10 others that I don't remember seeing before at all. pstore? securityfs? tracefs? debugfs?
I've been using Manjaro for about a year now, after also getting fed up with Ubuntu. It is based on Arch, but just as easy to set up and get running as Ubuntu. I find its package management sane enough for my day-to-day use, and though I install packages from all over I have yet to have anything break on me. I can definitely recommend it.
I dumped snapd because of the maintainers absolutely refusing to allow the users to customize the update schedule, or even disable automatic updates at all.
Reading the thread with the discussion on it, seems there was real contempt towards letting the user decide not to update their packages.
With windows update the trick since MS enforced a similar update policy is to change the user the Windows Update service runs under to an account that doest have the required permissions.
i am surprised that this is possible under windows. for ubuntu, it should be possible to disable the daemon that runs the update checks. at worst by hacking a script where the process is started.
> Maybe I’m just ignorant but it seems like allowing developers to push software updates without any review
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.
It could be worse. Software push is how browser distribute extensions. And they are ridden with spyware [0]. Pull by maintainers, deferred rollout, veto and rollback might what saves us yet.
I personally don't packaging apps in a sandbox, its a violation of the basic idea of writing tools that do one thing well. Still, snap gets lots of flack, but I don't see the same for flatpak. Is there some advantage to flatpak that I am missing, or is it just than Ubuntu has pushed snaps too hard?
It sounds like the objection isn't technical -- sandboxed apps are perfectly fine -- but rather to how Canonical is trying to change package behavior alongside the transition. Specifically, they're forcing you to use them for some packages behind the scenes, and restricting what you can do with those packages as a result:
> "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."
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.
Every time Canonical comes up with something to improve the state of things, there's a contingent of vocal Canonical opponents who focus on putting their weight behind an alternative. These voices will back the alternative, no matter what, because it's not Canonical.
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.
Yes, flatpak supports multiple upstream repositories, so anyone can release packages. I am going to start a repo soon for packaging AUR packages so they can be used on other distros.
Snaps are fully controlled by Ubuntu - for me it's a non-starter.
I can understand Canonical pushing for snaps. It's their product and they want it to succeed.
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.
Replacing the chromium apt with an empty package installing a random self-updating snap. In other words, pinning a specific chromium version, for example for selenium automation, is now broken.
Centos is too slow moving to be suitable for desktop use. Fedora updates to a new version every 6 months. 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.
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.
I didn't fully give up on the red hat ecosystem for years after that I even ran stella based on centos and rebuilt rpms to have software that wasn't packaged for same.
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.
> Centos is too slow moving to be suitable for desktop use.
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.
The latest POP!_OS release integrated Flatpak instead of Snap into their package manager. It's very well done in that you can choose if you want the deb or the flatpak version and it defaults to the deb as long as one is available.
Seconding the recommendation for Debian. I switched from Ubuntu Mate to Debian (buster) and the experience is quite smooth; most everything works the same, which is no surprise.
My issue with Debian that I don't want a rolling release, and Debian Stable feels more like "Debian Obsolete" to me (at least it was years ago, maybe now it is different...)
It's an LTS, upgrading every two years. No different than many other distros. If you want a more frequently-upgraded distro, consider OpenSuSE Leap (yearly upgrades) or Fedora (upgrades every 6 months).
Debian testing is basically my distro of choice: if sid is the rolling release, and stable is the LTS version, testing is roughly equivalent to non-LTS Ubuntu: the packages have been tested so you don’t usually get breakage, but they aren’t stale.
The packages are somewhat tested, but "you are participating in the development of Debian when you are tracking testing or unstable" [1]. My feeling is Debian testing is a little less stable than non-LTS Ubuntu.
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!
Good to know. I felt that way about Ubuntu / Lubuntu for that time too, until now. This gives me some confidence about Debian to put some time into trying it out. Thanks!
I have the perception (maybe just uneducated guess) that Debian is strictly worse than, say, Arch for personal use. One has to deal with constantly outdated packages, but also with required breaking changes in case of an upgrade from one version to another.
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.
What I really want is a really stable base OS that's managed totally separately from the individual packages I install. It's the experience one gets with MacOS + Homebrew and it's way better than an "... and the kitchen sink" distro that manages your kernel and basic interface-providing software with the same tool & process that installs and updates Super Tux.
(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)
Yes, the OS is separate from the rest and the experience much more streamlined than Linux... but it doesn’t support WiFi beyond 802.11n which is too slow for me. If BSD supported modern WiFi I’d have switched to it on my daily laptop long ago!
On sid, I've never had any such issue. I get pretty updated packages and haven't experienced any serious breaking changes, but I also don't do anything that's particularly sensitive or touchy to updates.
In case you are unsure what the sibling means: Debian is primarily a server OS (one of the best). When people talk about Debian, they mostly think about server use.
(That's why your question sounds like a joke :) Or maybe it was a joke?)
Thank you for clarifying! Not intended as a joke :) #noob
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.
If you have linux experience Arch Linux can be a good idea.
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.
Ugh, no. Manjaro is the no-nonsense "I really don't want to waste time troubleshooting my own shit" version of Arch Linux. I stopped using Arch when I found Manjaro and I'm so glad I did. Arch just requires way too much fiddling for it to ever feel "complete" and or finished.
Does Manjaro do pretty well with wireless and graphics drivers. I honestly want something I can live boot, install and use immediately. I dont mind customizing later, but I've had my fun fighting with getting linux set up.
The cost of Arch over anything else is 100% in the installation. After that, it IS Manjaro except you are using the real thing, not a derivative. I've had to trouble shoot Arch far less than any other distro I've ever used.
My main problem with Arch is that there's rarely a point where I feel like I've finished installing. There's always something missing or something not configured right. Shit, dialog still isn't a default package in 2020, which you need to use wifi-menu during the install process. So if you happen to forget to install that (and it isn't mentioned anywhere in the documentation), you're going to have to reboot into the live media, chroot into your install, install dialog, then reboot again.
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.
Please tell me you're fucking joking. You can't be serious. This ties into one of my other comments about how god awful the documentation is for beginners (or even intermediates) after scrapping the beginner's guide.
> 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.
On the other hand, it’s the RTFM approach of Arch documentation that forced me and others I know to actually learn Linux, and step up from beginner use to power user status.
Sure, if you want to remain a Linux beginner forever, the Arch docs would be terrible.
Well, my point was just that yes, Arch takes longer to install, and requires work, but it doesn't become a "hobby" _after_ that. Then people got into a flame war about how hard it is to install, which it is, and I freely acknowledge. :shrug:
> 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 used to be when I was younger. I used to spend days and weeks on this stuff and enjoyed it. But nowadays I have more important (and interesting) things to do (from my perspective).
Ditto, have downloaded sources from kernel.org and mirrors and predecessors probably hundreds of times, wrestled endlessly with xf86config, window manager configs, installed slackware, gentoo... it got old, real old.
Hmm... not my experience. Not discounting yours at all, I promise, but I have a 20-package one-liner install script that I run on new systems and it's ready to go. After I pull in my dotfiles and symlink them into place, I can't even tell it's a different install.
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.
My experience with Arch a few years ago was if you miss a few updates things tend to get REALLY broken. More than once I would have to hard reset some things because pacman + aurget would break something. If you update every day it’s okay, but it wasn’t my daily driver and I ran into that problem a lot!
I'm inclined to think that complexity in the installation is to put away random impatient users to keep the community cleaner. Of course many cloud providers provide a pre installed OS image too though.
From my perspective Manjaro seems like Arch+added nonsense. I honestly don't see what are you trying to say regarding Manjaro with "I really don't want to waste time troubleshooting my own shit" or "Arch just requires way too much fiddling". On the other hand I could understand if you just wanted something that requires less knowledge to set up the first time, but then why not go with Debian or something?
To clarify, I doubt that Manjaro is more debuggable than Arch, considering it's just Arch+added complications.
Manjaro is install and go. Arch Linux is ... well, if you haven't done it before, you're going to waste at least an hour going through the awful documentation trying to piece together what the installation flow is supposed to be. The beginner's guide was scrapped and the replacement is awful. So if you're new, it's going to be painful. And if you aren't new, it's still painful if you just want to install your OS and get working on things that actually have anything to do with things that interest you. You like Arch Linux, fine. But don't pretend everybody wants to install and configure everything manually, then mess around with whatever seems to be not working because the moons aren't aligned just right that day. I'm tired of Arch Linux. 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 agree that installation requires more learning than other distros, but once you get past that I don't understand the problem. I think Arch "just works", too, and I don't see how Manjaro could be better in that regard considering it is closely related to Arch. BTW, you do know you don't ever need to reinstall Arch (on a single machine)?
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.
> BTW, you do know you don't ever need to reinstall Arch (on a single machine)?
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.
> 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.
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.
Sorry, I can't agree about scrapping "Beginners guide".
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.
I think what you're describing is decision fatigue, which is the hard part of your first Arch install.
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.
Before switching to Arch, check if packages you rely on for your job are not in the AUR. It became "a hobby" really quick for me to rebuild my entire dev stack because of the bleeding edge approach and "let's update every week and fix source code while we're at it".
Do you have any examples of such packages that were missing? I've been using arch for maybe five years at this point and am an embedded developer. I had maybe oneor two times that I had to install something that was not in the aur.
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.
Mint. It's Ubuntu without the nonsense. I switched when the Unity thing happened, and haven't looked back. This news about snaps reaffirms my confidence in Mint.
I've switched from Ubuntu to Mint a few years back at home, at work I have to use Ubuntu. Functionally, the two are identical for my use case.
I love Mint, it just works and there are no surprises as far as I can tell.
Echoing others here: use Pop_OS or Manjaro. Pop_OS is really the best of Ubuntu, but with sane defaults that respect you. Manjaro just works, every time, every install I try.
Just wanted to chime in here and say Zorin is good too. It's based on Ubuntu 18.04 + Gnome + some extensions (which make it really beautiful to look at). It's fast and gets out of the way immediately when you want it to.
But my laptop (ThinkPad X1 extreme) isn't charging anymore. That happened with other distros too (on MSI prestige). I can't figure out what the problem is.
For some AMD hardware openSUSE has been more stable for me than Ubuntu, Debian and Fedora.
And off course the best KDE support of the bunch is also a plus.
I believe you, but I've better luck with other Debian.
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.
> What distro? I use Ubuntu because I just want an OS, not a hobby.
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.
I highly recommend looking at Fedora. I used Ubuntu for years and put up with obnoxious things. I took a job where the deployment target was RHEL so most devs used Fedora. There was a bit to learn (such as apt v. yum) but overall thinks pretty much "just work" if you are using Fedora Workstation. If you don't want Gnome there are spins available and most are pretty solid, but if you really want a "just works" go with the official Workstation.
Back in 2015 I had installed and used Elementary OS - supposed to be a functional Linux distro (inspired by OSX UI 'd say). It wasn't stable at that time. Maybe it's better now.
The really annoying thing about snaps is that they pollute the mountpoints on the system. I’ve had as many as 100 mounts on a box after installing just a few snaps, which is super annoying if you ever want to try to get an idea of disk usage. God forbid you want to figure out what lvm volume can get shrinked.
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).
> How can "sudo apt install chromium-browser" not install the apt package but install instead a snap?
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.
> Simple: they decided that maintaining the chromium .deb takes too much effort, and that snap is making that easier. So they moves it to Snap.
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?
I started using Ubuntu in 2006 and really appreciated the ideals of "Linux for Human Beings" and accessibility (I get a bit nostalgic at that drum sound lol). Over the last several years though I have been migrating my systems to Debian. I like the greater commitment to free software and, nowadays at least, it's just as easy to install. A lot of knowledge carries over too, not surprisingly, and you can get away with most of the same troubleshooting solutions. I'd really recommend giving it a shot!
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.
On Debian, "sudo apt install mysql-server" will get you MariaDB(tm), not MySQL(tm).
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).
Ubuntu keeps making the setup work to go from install to a clean and usable linux system more and more work.
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.
I've been using Mint now for several years and been satisfied with it. I was afraid that the Ubuntu's snap mishegas would force me to move elsewhere, but this is the message I was hoping to hear from the Mint team.
The Mint maintainer was really unprofessional in his announcement.
It is OK to feel strongly about something, but using words like `backdoor` is really bad.
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.
"I'm the HN shill for snap, posting dozens of times about how awesome snap is in a single thread, and since the Mint maintainer doesn't think snap is as awesome as I do, I'll call him unprofessional". FTFY.
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
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.
Please correct me if I'm wrong, but one cannot hold off updating the snaps indefinitely. Thus there is no "if".
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.
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?
It'll still update behind your back after 60 days. It's deliberately designed so that the users does not have complete control over what their devices run. It's designed in a way that even experienced sysadmins will have hard time taking back control of their devices. Ultimately these knobs are just farce. What they are doing could be easily achieved by cron or any other task scheduler, but that would not allow Canonical to keep control of user devices.
The main reason why I use Linux for some of my work is reproducibility. A docker image with the same apt packages installed in it will work the same every time.
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.
I agree in principle, but it's worth pointing out that Snap is designed for end-user applications, so it's unlikely to be used on a server or in a Docker image built for deployment.
I agree in general, but my work involves website automaton, meaning the now empty chromium package.
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.
Makes sense, I personally don't mind snaps for proprietary applications (mostly Slack and Spotify) which are otherwise hard to discover and keep up to date on Linux, but I don't understand why Canonical would force this for Chromium which is already packaged and open source.
Have a look at LXD.
It creates system containers that are based on runtimes of most Linux distributions.
You can stick to specific versions and are certain that those do not change.
I use chromium and firefox inside the docker with selenium to automate website tests. So them replacing the chrome apt with snap was exactly what broke my deployment.
What I miss most is the ability to pin a version. For example, not every Firefox plugin is compatible with every Firefox update. Especially not if you have custom-developed plug-ins using private APIs.
Honestly for everything but desktop non dev usage linux containers (e.g. docker) do all the thinks you need and potentially better.
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).
Snap for me means Firefox suddenly says “I won’t open a new tab until you update me and I will drop all tabs on restart”. It also means cached content and configs in many new obscure places. It doesn’t mean any visible improvement so far. So hey, kudos Mint and hey, Ubuntu stop that already.
That should only happen if you update from underneath it by doing an upgrade though, which is entirely at your discretion with apt. The snap equivalent is obligatory.
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.
It doesn't auto-restore my session either, but I can usually (always?) get it back using the "Restore previous session" item from the menu. (Also, like the siblings say, that's not a snap thing. If I understand it right, snap might just auto-restart without the courtesy "I can't open a new tab" message.)
I learned a long time ago to block firefox from contacting mozilla related domains. It does too much unwanted stuff in the background. I update it on my schedule.
> Mint never shipped snapd, Snap's daemon program or any snaps, but moving ahead, in Linux Mint 20, "Chromium won't be an empty package which installs snapd behind your back. It will be an empty package, which tells you why it's empty and tells you where to look to get Chromium yourself." Further, APT will forbid snapd from installing.
Can't they just replace the Chromimum package with the one in Debian?
They are already doing a special case for Chromimum to tell the user why its empty and where to get it. Instead they could provide a working copy based on the debian deb package.
Ubuntu 18.04 LTS is currently super popular for servers. Any thoughts on whether 20.04 is a worthy upgrade for servers, or just a pain? Snaps in particular sound good for desktops but not servers.
I disagree. I like having Nextcloud auto-update, even if it results in a service restart. I just schedule that for a time of day that isn't very disruptive. As for LXD, restarting the LXD daemon doesn't effect the containers (they continue running).
Oh hey, I get it. That wasn't the point of the parent to which I was responding, though. I was merely trying to share that snaps are just as useful for server as for desktop, that's all.
Hundreds of organizations, including ours, rely on Rocket.Chat for their internal messaging. It all went down when a release was pushed and snap decided to auto-update [1] I can imagine it resulted in a huge loss of productivity at all these orgs in the Covid era.
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.
But that's just part of the problem though. I want to be able to rely on my system and not have a chance 4 times a day for random things to break (the default frequency based on your link).
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.
You can turn it off by replacing your operating system with another Linux distribution. As of 20.04 you also still have the option of removing Snap outright[1], as long as you don't need the software that is only provided via snap.
Although apparently they are considering[2] adding the option to disable auto-updates.
Thanks, I did this on my 20.04 systems and it worked fine. Simply uninstall snapd. I lost LXD (no way I'd use this now anyway if its distributed via snap), and chromium browser (but discovered the far superior Ungoogled version anyway)
apt cannot revert, not even in principle. snap can in principle, and it should just be one command. It looks like it didn't work in this case because of a bug in Rocket.Chat's snap packaging. But bugs happen in everything despite their packaging format, and most users are affected by regressions in apt package updates anyway.
I noticed that Mint is working on LMDE which uses Debian as its base directly without using Ubuntu; I wonder if this is one of the reasons motivating that project and what the other reasons are.
While I understand the concerns over Snap, you can't blame Canonical for trying, because lets be honest, rpm/deb packages are a mess.
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.
> You trusted the app developers as soon as you installed that app on your computer with full privileges.
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.
On a personal computer, you are giving a whole lot of trust to anything you run un-sandboxed as your normal user - it will likely have access to your most interesting files, browser cookies, maybe saved passwords. XKCD covered it years back: https://xkcd.com/1200/
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.
> Only install scripts, written my distribution's maintainers, run as root (except for core applications, of course).
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.
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.
The discussion pinpoints the issue in the fontconfig cache files. It is being worked on.
The issue is not "snap packages only show tofu characters" but rather in some cases snap packages cannot access the system fonts, hence the squares.
This bug has not been addressed for almost a year, which is completely unacceptable when the Snapcraft homepage advertises that "Snaps work across Linux on any distribution or version."
This appears to be an unpopular opinion, but I like snaps and Canonical's philosophy in some ways mimics that of Apple's where they care about usability over configurability.
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.
Absolutely. The server-side implementation of Snap is closed source and the Snap Store is a single instance controlled solely by Canonical. Flatpak repositories are decentralized and can be hosted on private servers with flat-manager, which is FOSS:
I don't think I met a functional snap package so far. Granted, I only had the displeasure of dealing with two.
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.
I like snaps too but snap has a habit of killing my open apps when it wants to update, rather than waiting. Especially Telegram.
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.
My understanding is that you want to distribute via your own store you need to develop your own distro, reverse engineer their backend, develop your own backend. Develop your own forked client that actually searches in more than one store and then you can distribute to only those people running at minimum your forked client.
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.
> Apple's where they care about usability over configurability.
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…
Most people are not rejecting snaps as a concept but the way ubuntu decided to implement it (e.g. forced updates, closed back-end, stealth snapd/snap reinstalls, etc).
> Canonical's philosophy in some ways mimics that of Apple's where they care about usability over configurability.
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.
My number one complaint about Snaps is that they're not portable (despite being labelled "universal packages for Linux"): they start to work less well outside of Ubuntu, and they don't work at all unless you're running systemd. I find this slightly ridiculous given that Flatpaks really do work more universally - they don't require systemd - and they come out of Red Hat - the home of systemd.
From reading the other comments, people just don't like having security updates done automatically - they'd like to have more control when they are performed.
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.
I've seen more than one twitch streamer going into a big stream, get screwed by this. Of course, they should've known. But we've all made that mistake during a demo or presentation at some point or another.
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.
Unless you're on a corporate machine where they have some Group Policy to force updates, you absolutely can control when updates are performed. You might have to actually learn how to do that, but it's not like M$ makes it impossible.
I've seen all sorts of times I've run into a Windows thing that crashed for unknown reasons. I can't think of a single time I think I've ran into a Windows powered kiosk / info screen that was stuck in the middle of a forced update.
I have however, lost count of how many times some piece of technology has failed because someone didn't read the manual.
I have found flatpaks to be much better (they are much faster to startup), except that flatpak doesn't have an unconfined or "classic" mode like snaps. THis is especially annoying if you wanted to install vscode to access the system compiler, python, etc.
"apt" packages are handmade. And they depend on hand-made dependencies. It becomes increasingly difficult to maintain packages like chromium, because they have too many dependencies, that have to be packaged individually.
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?
So we have an automation problem. Building packages is needlessly inconvenient and the few hands we have are overwhelmed by the number of packages that need maintaining.
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.
Do not pretend that "apt" (.deb) packages require un-bundling dependencies. That's just policy decision of Debian. You could just create Chrome package and put everything in /opt/google-chrome or whatever root path you choose. Ubuntu could have lifted this policy.
It's interesting how many distros built on top of Ubuntu are explicitly dropping snaps or throwing their support behind flatpaks:
- 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?
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?
Lenovo, in their announcement, they start by saying that they made the move because the Linux desktop stands at 2.7%.
And they want in, in this 2.7% market.
If the Linux desktop becomes a 5% market, or a 8% market, then it will open the floodgates to other companies offering support to desktop Linux.
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.
Ubuntu definitely done a lot of good. 6.06 LiveCD and Theme, installation in Windows partition, these we good.
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.
It's quite a gamble, but if desktop Linux got more popular and Snap was the default way to get applications for it, I'd imagine that running the app store would be a pretty good revenue stream.
Pop OS [1] does something similar. Based on Ubuntu, but replaces snap with flatpak. You can apt-get packages like chromium from their PPA [2].
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.
While I'm not super up on these newfangled app distribution systems, I've had mostly negative experiences with both Snaps and Flatpaks.
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.
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.
296 comments
[ 3.0 ms ] story [ 321 ms ] threadThe dislike on snap packages looks to be too emotional.
It resembles the issue with people feeling that 5G affects their health. Obviously, it does not. But the belief is so intense that they get actual observable symptoms.
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.
[1] https://blocked.cdn.mozilla.net/
> "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.
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.
https://docs.fedoraproject.org/en-US/modularity/
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.
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.
[1]: https://lwn.net/Distributions/
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://guix.gnu.org/
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.
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.
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?
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.
[0] https://packages.ubuntu.com/focal/lxd
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.
No updates.>
> 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).
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.
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.
I think the Ubuntu 20.04 runtime should be better than Ubuntu 18.04. More fixes, new features and updated versions of packages.
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.
[1]. https://github.com/RocketChat/Rocket.Chat/issues/17628
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.
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.
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.
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.
https://snapcraft.io/
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.
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.
https://github.com/flatpak/flat-manager
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.
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.
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.
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.
- 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?
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.
[1] https://pop.system76.com/
[2] https://launchpad.net/~system76/+archive/ubuntu/pop/
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.