Disabling automatic refresh for Snap from store(forum.snapcraft.io)
forum.snapcraft.io
Disabling automatic refresh for Snap from store
https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707
200 comments
It’s not even remotely close. Snaps take longer to load, still sometimes have theme issues, you have to manually install Snap on almost all non-Snap distributions, you’ll be littered with garbage mountpoints, you’ll have a useless snap folder in your home directory, you can’t add external repositories of any kind, and you get no ability to stop updates easy without going into duct tape solutions.
Snap wants to be a desktop, and server, system. Not with a 10 foot pole - Docker is literally 100x better. Not on my Desktop - Flatpak is superior there.
Snap wants to be a desktop, and server, system. Not with a 10 foot pole - Docker is literally 100x better. Not on my Desktop - Flatpak is superior there.
> Snaps take longer to load
Without fail, on multiple machines, shutdown/restart is stalled for the maximum 2:30 timeout for snapd. It's a useful reminder to uninstall Snap whenever I find myself in the unfortunate situation of using Ubuntu.
Without fail, on multiple machines, shutdown/restart is stalled for the maximum 2:30 timeout for snapd. It's a useful reminder to uninstall Snap whenever I find myself in the unfortunate situation of using Ubuntu.
Don't forget odd permissions problems. From memory, ipfs is distributed as a snap. Try saving a file to another location outside of the snap jail. Almost impossible.
As an Alpine user, Flatpak is invaluable. Snap isn't supported because it requires systemd.
Had not thought about that! I want to set up my old Lenovo X220 with a minimal distro and was thinking of using Alpine + Sway. Using Flatpak for all the "regular" apps more than makes up for the apps not present in Alpines repos.
Solution to what? Personally I think ALL of such package managers exists only for a reason: satisfy commercial software needs, in disguise to being developed for free by a community instead of being neglected and pushed to the place they deserve, witch is /dev/null.
The future of package management is NixOS/Guix System, the future of isolation are cgroups (see FireJail, BubbleWrap). The rest is absurd like full-stack virtualization on x86 to make VMWare profit, HW OEMs profit, consulting profits etc and people who should not, because of ignorance, running infra built by someone else a brick at a time, or the way to create disaster waiting to happen...
I see exactly ZERO good cases for snap, flatpak, appimage etc... ZERO, really.
The future of package management is NixOS/Guix System, the future of isolation are cgroups (see FireJail, BubbleWrap). The rest is absurd like full-stack virtualization on x86 to make VMWare profit, HW OEMs profit, consulting profits etc and people who should not, because of ignorance, running infra built by someone else a brick at a time, or the way to create disaster waiting to happen...
I see exactly ZERO good cases for snap, flatpak, appimage etc... ZERO, really.
Perhaps there's still a way to save snaps. Does somebody knows of a snapd fork that allows control over updates and alternate snap stores?
Users are telling the snap team exactly what they want: give us a way to disable automatic updates. Snappy's vision is to take this control away.
This is why people hate snaps. They don't fit user workflows, make extra work and even cause show stopping problems.
Snaps could be great but the team really needs to listen. For me I'm removing snaps from my configs before I get surprised.
(edit: mobile autocomplete typos)
This is why people hate snaps. They don't fit user workflows, make extra work and even cause show stopping problems.
Snaps could be great but the team really needs to listen. For me I'm removing snaps from my configs before I get surprised.
(edit: mobile autocomplete typos)
It's the nature of creating a currated experience: saying "No" to a lot of things.
Chrome/Google did the same thing.
Snap clearly has a philosophy. And a lot of people clearly disagree with that philosophy.
Thankfully, instead of "advertised from google.com", Snap has less ability to push itself on users, and users have more ability to choose it... or not.
Chrome/Google did the same thing.
Snap clearly has a philosophy. And a lot of people clearly disagree with that philosophy.
Thankfully, instead of "advertised from google.com", Snap has less ability to push itself on users, and users have more ability to choose it... or not.
>Snap clearly has a philosophy. And a lot of people clearly disagree with that philosophy.
Seems like that philosophy is the user is not to be trusted. The problem here is that users in reality, not just philosophically, CANNOT trust snap because it will force updates (or dns trickery to stop it) that may cause a system to stop working.
Seems like that philosophy is the user is not to be trusted. The problem here is that users in reality, not just philosophically, CANNOT trust snap because it will force updates (or dns trickery to stop it) that may cause a system to stop working.
Snap's philosophy appears to be: Given the option to not patch, users will not patch. And this is even worse in IoT land.
Which I can't say is wrong.
Who probably shouldn't use Snap are users with mature patch application skills, who are willing the invest the time to review and patch regularly.
That class of users is far smaller than {all users}.
Which I can't say is wrong.
Who probably shouldn't use Snap are users with mature patch application skills, who are willing the invest the time to review and patch regularly.
That class of users is far smaller than {all users}.
> Snap's philosophy appears to be: Given the option to not patch, users will not patch. And this is even worse in IoT land.
This is true. But there are so many situations where unpatched is better than bricked or bugged. The community's ask was reasonable.
This is true. But there are so many situations where unpatched is better than bricked or bugged. The community's ask was reasonable.
Absolutely, the community's ask was reasonable.
But I think the goals might also be mutually exclusive.
Snap's philosophy, from what I read in the thread, boils down to: if an update bricks devices when it's pushed, the proper time to catch that update is before it's pushed, or as it's pushed, not after.
Which I do see the wisdom in. The majority of users are less well informed and equiped to test and patch than developers.
But I think the goals might also be mutually exclusive.
Snap's philosophy, from what I read in the thread, boils down to: if an update bricks devices when it's pushed, the proper time to catch that update is before it's pushed, or as it's pushed, not after.
Which I do see the wisdom in. The majority of users are less well informed and equiped to test and patch than developers.
[deleted]
Somehow when googling software snap will often come up and try to push users to install snap and the software.
Almost feels like malware on every level. Can't comprehend why they are pushing it so hard.
Ubuntu is on borrowed time.
Almost feels like malware on every level. Can't comprehend why they are pushing it so hard.
Ubuntu is on borrowed time.
I have been a huge fan of Ubuntu for a long time. But the way they push snap is really making me question this choice. The more I learn about snap the less I like it.
I switched to Fedora after ~14 year of using Ubuntu as my daily driver. Three months in, it's been absolutely rock solid.
It seems that sometimes the push is external. A few days ago Canonical announced that they would switch Firefox to snap because that's the only way Mozilla will allow them to redistribute it.
> because that's the only way Mozilla will allow them to redistribute it.
I doubt this is the whole truth, compare https://news.ycombinator.com/item?id=30800957
I doubt this is the whole truth, compare https://news.ycombinator.com/item?id=30800957
Having a user app like Firefox force autoupdate is not that bad IMHO. Having server infrastructure components update themselves automatically can be disastrous. This caught me by surprise, painfully.
Snap for GUI apps, okay, fine. Snap for system infrastructure, no thank you.
Snap for GUI apps, okay, fine. Snap for system infrastructure, no thank you.
It's bad when the user is actively using the application and snapd decides to update the Firefox snap and cause issues.
Yeah, suffered from this last Friday with firefox.
Quite bad timing and since I surf mostly in private mode I'm not so keen on a restart at inopportune times since my state will be completely wiped.
Quite bad timing and since I surf mostly in private mode I'm not so keen on a restart at inopportune times since my state will be completely wiped.
Can someone explain why I'd use snap or flatpak over the distros repo or manual install for something not in the repo or unavailable via adding a repo? Apart from auto-managed updates.
Snap and flatpak are massive compared to "traditional" packages.
Snap and flatpak are massive compared to "traditional" packages.
Snap is terrible in every sense, so you should never use it in my opinion.
As for Flatpak, I'd say use it if you need a more up-to-date version of a piece of desktop software than is in your distro's repository or desktop software that isn't in your distro's repository at all.
For example, I use the Firefox flatpak on Fedora to have the most up-to-date version (98.0.2) since the current version of Firefox on Fedora (98.0.0) was giving me some issues like crashing when downloading something and choppy gifs.
I also use it for some proprietary software like Spotify and a game called Vintage Story. Adjusting their sandbox permissions with Flatseal is useful in this case.
As for Flatpak, I'd say use it if you need a more up-to-date version of a piece of desktop software than is in your distro's repository or desktop software that isn't in your distro's repository at all.
For example, I use the Firefox flatpak on Fedora to have the most up-to-date version (98.0.2) since the current version of Firefox on Fedora (98.0.0) was giving me some issues like crashing when downloading something and choppy gifs.
I also use it for some proprietary software like Spotify and a game called Vintage Story. Adjusting their sandbox permissions with Flatseal is useful in this case.
The big one being - when you install just an application, you don't want it to accidentally pull in the wrong dependency and destroy the rest of your system. This is a big problem when you use ppas or .debs directly from the app developer and accidentally update say libc or gtk. Another example: an application you use brings in a python-xyz package that conflicts with the same package you installed with pip install.
Also updating the system shouldn't accidentally break the application you use either. On rolling release distros this can be a pain. You'd typically want the application that the application developer tested properly (as opposed to relying on your package manager's "testing"). The packagers can introduce bugs while repackaging an application for X distro. My Cura was broken for so long on Arch linux that i gave up and started using their AppImages instead.
Depending on your distro, you also have to deal with headaches like XYZ software is only available on Ubuntu 20.04. Tough luck that you are running 18.04 on your laptops. (last week i had to deal with this problem with clang)
In addition to being self contained with all the dependencies, these solutions offer some level of sandboxing too.
On Arch, AUR usually does a nice job of packaging binary only applications, so i rarely need to use flatpack/snap/appimages but on other distros that can be a pain.
Also updating the system shouldn't accidentally break the application you use either. On rolling release distros this can be a pain. You'd typically want the application that the application developer tested properly (as opposed to relying on your package manager's "testing"). The packagers can introduce bugs while repackaging an application for X distro. My Cura was broken for so long on Arch linux that i gave up and started using their AppImages instead.
Depending on your distro, you also have to deal with headaches like XYZ software is only available on Ubuntu 20.04. Tough luck that you are running 18.04 on your laptops. (last week i had to deal with this problem with clang)
In addition to being self contained with all the dependencies, these solutions offer some level of sandboxing too.
On Arch, AUR usually does a nice job of packaging binary only applications, so i rarely need to use flatpack/snap/appimages but on other distros that can be a pain.
Flatpak's benefits:
- Cross-distro packaging (no need to provide N package formats - this one runs on all distros)
- Faster update cycle for each app, if the package is maintained by the original developers
- Sandboxing
- Better compatibility all around, as the package runs the same on all distros (as opposed to some too-old or too-new module breaking something on X distro)
- Some other goodies, like checking new releases of the source on Github etc
Flatpak's drawbacks:
- Modules are not shared, which can result in somewhat larger packages and potential vulnerabilities
- Many packages are community-maintained by people who are not necessarily experts in the Linux ecosystem. Distro-provided packages usually have tighter requirements
Personally, I use Flatpaks for the sandbox. I restrict all apps very heavily.
- Cross-distro packaging (no need to provide N package formats - this one runs on all distros)
- Faster update cycle for each app, if the package is maintained by the original developers
- Sandboxing
- Better compatibility all around, as the package runs the same on all distros (as opposed to some too-old or too-new module breaking something on X distro)
- Some other goodies, like checking new releases of the source on Github etc
Flatpak's drawbacks:
- Modules are not shared, which can result in somewhat larger packages and potential vulnerabilities
- Many packages are community-maintained by people who are not necessarily experts in the Linux ecosystem. Distro-provided packages usually have tighter requirements
Personally, I use Flatpaks for the sandbox. I restrict all apps very heavily.
> Better compatibility all around, as the package runs the same on all distros (as opposed to some too-old or too-new module breaking something on X distro)
I wish this were the case, but as a Flatpak user on Guix System I don’t think it’s entirely true. Flatpak apps still do seem to rely on some bits of the system, and they break in interesting ways when they aren’t where the app is expecting them to be.
I wish this were the case, but as a Flatpak user on Guix System I don’t think it’s entirely true. Flatpak apps still do seem to rely on some bits of the system, and they break in interesting ways when they aren’t where the app is expecting them to be.
Snaps are an attempt to move away from the distro managed software concept to the windows/android like vendor managed software paradigm. It removes the intermediate distro layer between third party vendors and users. It can also improve security in theory, but there are a lot of caveats to that currently.
Flatpak is incredibly useful for installing proprietary software.
I use it for Spotify, Zoom, Slack among others.
Installing and updating Flatpak apps for proprietary software works very well.
I use it for Spotify, Zoom, Slack among others.
Installing and updating Flatpak apps for proprietary software works very well.
In my experience "manual install for something not in the repo" applies to a whole lot of software, especially if "latest version isn't in the repo" counts, and also usually means "compile it from source yourself". Frankly I think that's a pretty ridiculous ask, and the fact that Linux Desktop hasn't had a good story for installing software outside of the repo has been one of the main factors keeping me from liking it over the past 2 decades.
There have been a lot of 'universal package' standards over the years, and honestly Flatpak isn't the best one, but it is the one that the community finally seems willing to adopt to a degree that actually makes it worthwhile. Snap, however, is the worst of these formats, and by a wide margin, that I can recall ever existing. It's amazingly bad and extremely user-hostile.
There have been a lot of 'universal package' standards over the years, and honestly Flatpak isn't the best one, but it is the one that the community finally seems willing to adopt to a degree that actually makes it worthwhile. Snap, however, is the worst of these formats, and by a wide margin, that I can recall ever existing. It's amazingly bad and extremely user-hostile.
In theory one gets better security. Distribution or manual apps can access and modify everything the user can do. Flatpack and Snap tries to address that with a security model similar to mobile apps.
In practice for many apps the security protection is non-existent or very limited for compatibility reasons. So for now the benefits is indeed mostly a store model and auto updates.
If one really needs to run an untrusted app a VM is probably the only practical way. It is also possible to run apps in various containers, but truly secure setup is rather nontrivial with those.
In practice for many apps the security protection is non-existent or very limited for compatibility reasons. So for now the benefits is indeed mostly a store model and auto updates.
If one really needs to run an untrusted app a VM is probably the only practical way. It is also possible to run apps in various containers, but truly secure setup is rather nontrivial with those.
Flatpak apps usually come with quite open privileges, however the user can completely configure this themselves and restrict the access of an application to quite a reasonable degree. Unless you distrust the sandbox of Flatpak, I don't see a need for containers.
Worth noting that Flatpak's sandboxing is using the same container functionality of the Linux kernel as all the various other container tools. If containers are secure enough than so is Flatpak, assuming you've tweaked the applications sandbox settings to your liking.
Over manual install - snap/flatpak is typically way faster and easier to install and configure. Installing Nextcloud manually if you’re not familiar with the process is an hour or more of setting up all the essential and optional dependencies. It’s a few seconds of snap install nextcloud.
Over distro repos - no dependency version hell.
I don’t really love snap/flatpak (too much “magic”, hard to tweak installs) but I see why they get used.
Over distro repos - no dependency version hell.
I don’t really love snap/flatpak (too much “magic”, hard to tweak installs) but I see why they get used.
Basically because a lot of open source software isn't packaged for each distro. Take Joplin for example: not in the repos and not packaged into a nice .deb file. Distributed as an AppImage.
- disk space (in most cases) is cheap
- they are always up to date and therefore statistically more likely to have security holes fixed
- that are (to an extent) sandboxed by default and give you a lot of control over that.
- for developers it's much easier than maintaining hundreds of fixes for different distro peculiarities. Therefore (for the user) they are able to spend more time on the app itself rather than compatibility
- they are always up to date and therefore statistically more likely to have security holes fixed
- that are (to an extent) sandboxed by default and give you a lot of control over that.
- for developers it's much easier than maintaining hundreds of fixes for different distro peculiarities. Therefore (for the user) they are able to spend more time on the app itself rather than compatibility
I'd be curious to hear a good explanation as well from someone who knows more about this than me. My feeling (and feelings/suspicions are all I've really got) is that there are 2 factors driving it - maintaining repos is mundane work, and containers are fashionable again.
I really don't understand all these "flatpak is better" comments. It's not.
https://ludocode.com/blog/flatpak-is-not-the-future
Maybe it is better than snap, but it's not good and its not better than a traditional package, on either philosophical or technical grounds.
https://ludocode.com/blog/flatpak-is-not-the-future
Maybe it is better than snap, but it's not good and its not better than a traditional package, on either philosophical or technical grounds.
It is better on a "keep it updated by the developer" grounds and that's all I need. I liek to have the latest with things like spotify, libreoffice, qbittorrent, etc. I like the sandboxing. Sure it ain't everybody's cup of tea, but you can't discount other people's opinion as "wrong". They're just opinions. I know other people value the aspects of .deb/.rpm only based system, and I have weighed the pros and cons personally. Don't expect that we haven't looked into it for ourselves by default.
Wow. This thread isn't controversial at all. I haven't found a single comment making a case for Snap. It seems to be universally disliked - at least by this crowd.
It's disliked by the same Linux purists who complain constantly about systemd. Bit odd how the same community hates Canonical considering how it's now the only FOSS commercial entity considering Red Hat was bought by IBM. The community treats them worse than Microsoft for no good reasons. If you don't like snap, fine, use flatpak, apt, AppImages. Nobody is forcing you on ubuntu systems, but they spend their effort and time whining here.
I like snaps, I use them for everything I can.
- They are better confined than flatpaks, and come with a permission based model. Hence why there are some rougher edges. I appreciate the increased security.
- I appreciate the ability that when I remove a snap, the entire thing is removed with no littering.
- They are significantly easier to distribute on ubuntu than dealing with ppas or launchpad.
- They are a one-stop shop for finding the software I care about. I don't need to hit the command line, or add another repo.
- They save time and money because devs only need to support 1 base.
- I can install software on ubuntu without giving root privileges in a self-contained fashion.
Some common complains:
- The store isn't open sourced. Well yes, that is because they wasted time from the same whiny people over launchpad. Nobody else runs and supports launchpad. Hence nobody else would frankly bother running the snap store.
- People can't run their own store. Well yes, that is because Canonical learned from a decade ago with the security nightmare that is PPAs. Yea, it is a bad idea giving devs root access to 100k worth of machines to run arbitrary scripts. Also really bad UX.
-It's slow to startup with theming issues. Well the situation has improved 100x since a few years ago, and also I run an ssd, 32gb of RAM and a 3600, I don't really care for a few seconds in launch time.
I like snaps, I use them for everything I can.
- They are better confined than flatpaks, and come with a permission based model. Hence why there are some rougher edges. I appreciate the increased security.
- I appreciate the ability that when I remove a snap, the entire thing is removed with no littering.
- They are significantly easier to distribute on ubuntu than dealing with ppas or launchpad.
- They are a one-stop shop for finding the software I care about. I don't need to hit the command line, or add another repo.
- They save time and money because devs only need to support 1 base.
- I can install software on ubuntu without giving root privileges in a self-contained fashion.
Some common complains:
- The store isn't open sourced. Well yes, that is because they wasted time from the same whiny people over launchpad. Nobody else runs and supports launchpad. Hence nobody else would frankly bother running the snap store.
- People can't run their own store. Well yes, that is because Canonical learned from a decade ago with the security nightmare that is PPAs. Yea, it is a bad idea giving devs root access to 100k worth of machines to run arbitrary scripts. Also really bad UX.
-It's slow to startup with theming issues. Well the situation has improved 100x since a few years ago, and also I run an ssd, 32gb of RAM and a 3600, I don't really care for a few seconds in launch time.
Thank you for this comment. The Ubuntu/Canonical hate that goes around on this platform is pretty ridiculous.
apexalpha(1)
So... I have been using Ubuntu 18.04LTS for my half-dozen servers and was planning to replace them with 22.04LTS later this year. Bad idea?
I've tended to use every second LTS release, replacing with new (cloud) servers during the overlap in support periods. I use Ansible to configure.
Should I be considering Rocky or straight Debian instead? Something else?
I've tended to use every second LTS release, replacing with new (cloud) servers during the overlap in support periods. I use Ansible to configure.
Should I be considering Rocky or straight Debian instead? Something else?
If you aren't paying Canonical for support you might as well just use Debian.
Never used a snap. Never will.
I use it only for Spotify
You can try https://github.com/jpochyla/psst for Electron-less Spotify. I use the AUR package on Arch. It was crashy some months ago but now works great.
I install Spotify through `apt`. What benefits do you get from installing their snap?
They sometimes forget to update the .Deb version
>@Romario74 That is not the case; while on Snap they packaged v77, if you look here you will find that the Spotify devs have not been updating the .deb releases. Re-packaging Snaps is less convenient than using a .deb tarball, and is being done through scripts by this Github project, which is in turn repackaged by @Edu4rdSHL.
https://aur.archlinux.org/packages/spotify
So i run snapd on system
>@Romario74 That is not the case; while on Snap they packaged v77, if you look here you will find that the Spotify devs have not been updating the .deb releases. Re-packaging Snaps is less convenient than using a .deb tarball, and is being done through scripts by this Github project, which is in turn repackaged by @Edu4rdSHL.
https://aur.archlinux.org/packages/spotify
So i run snapd on system
Can’t you just use the web site?
Both major browsers are Snaps as well. The web site also has a significant additional control latency when playing on a device on your local network.
I tried this but for me closing the browser sometimes means, being done with work or a task and this would always also shut down my music. It's the small things that still drive me to install their client, even though I know it is just another electron app.
The web player only does 128kbit AAC stream
I tried microk8s snap once. Never again
Care to explain why?
constantly high CPU usage. Moved on to k3s and happy since then
That's what I thought, until the other day I realised something I had installed was via snap. I'm afraid the only solution requires stop using Ubuntu :(
sudo apt purge snapdDoes it mean that apt will then install a non-snap version?
I haven't verified that, but considering that nothing suggested that I was installing a snap app (other than me not paying attention to apt's output, I guess), I'm not sure if that's even possible. I was planning to stay with 18.04 LTS and then move to something else, but seems like either snap was there already or it has been added after I upgraded.
I haven't verified that, but considering that nothing suggested that I was installing a snap app (other than me not paying attention to apt's output, I guess), I'm not sure if that's even possible. I was planning to stay with 18.04 LTS and then move to something else, but seems like either snap was there already or it has been added after I upgraded.
I don't think so because some apps are only available as snaps. that is less true for 18.04, but 20.04 and 22.04 use snaps fairly heavily and some like firefox only available through snaps, although there is also PPA and flatpaks available.
No, it removes the entire snap ecosystem from your machine, including the snap backend to apt. It does mean that installing snap-only packages becomes more problematic, but that's a price I'm willing to bear.
I think you have to use snap (I can't recall the incantation, snapctl??) to remove the snap mount points (which I think are made when snap packages get installed) first otherwise they don't get removed by simply removing snapd. Only did it once, so far.
The only thing still keeping me on Ubuntu is the font rendering that somehow looks so much better than any other distro, otherwise I would've already switched to another distro because of snap.
I feel like I've never seen anybody actually like snap.
I feel like I've never seen anybody actually like snap.
Snap is probably that thing that the people who do use it or don't mind it, don't notice it.
Snap was the reason I said goodbye to Ubuntu
One of a number of reasons Ubuntu does not even meet the minimum requirements to tender for a cut of the millions the University I work for invests in Linux systems (research workstations (often packed with NVIDIA GPUs), clients to control specialist equipment, HPC, regular desktops/laptops/servers, network/lustre/backup storage etc).
Check out how long this flatpak bug was on adding a pin function :)
https://github.com/flatpak/flatpak/issues/3078
https://github.com/flatpak/flatpak/issues/3078
The snap thing makes me want to switch distro (for work) from ubuntu. Unfortunately we have some benefits from using ubuntu as the common platform for less divergence from each other
I personally use ubuntu and have used snap enough to get thoroughly burned and annoyed by it. Slow starts, no auto-update controls with bad defaults corrupting running programs, spammed mount points... (edit: see comment below for some limited controls to reduce the frequency of auto-updates)
But, unless I'm missing something about latest or future releases, isn't it still optional? Can't you use apt instead and uninstall snapd altogether?
I'd agree that needing to uninstall instead of opt-in is an annoyance, and that user-hostile actions tend to be a slippery slope..
But, unless I'm missing something about latest or future releases, isn't it still optional? Can't you use apt instead and uninstall snapd altogether?
I'd agree that needing to uninstall instead of opt-in is an annoyance, and that user-hostile actions tend to be a slippery slope..
> But, unless I'm missing something about latest or future releases, isn't it still optional? Can't you use apt instead and uninstall snapd altogether?
There seem to be more and more things that are only delivered as snaps.
I haven't used Ubuntu on the desktop in a while (and even then, it was just trying it out), but I remember that trying to apt install <something> would say "use the snap". I think LXD is in that case, for example.
There seem to be more and more things that are only delivered as snaps.
I haven't used Ubuntu on the desktop in a while (and even then, it was just trying it out), but I remember that trying to apt install <something> would say "use the snap". I think LXD is in that case, for example.
I recommend Fedora to everyone wanting a desktop alternative to Ubuntu. It's a well-balanced distribution that is opinionated enough to work fine as-is but doesn't try to force things on you the way Ubuntu does with snaps.
What DEs are common/supported on Fedora, I use KDE (Kubuntu), I'm not keen on snaps and so it seems expedient to switch distros when I next install (as it seems Ubuntu are all in for snaps).
You want Kinoite: https://kinoite.fedoraproject.org/ it's Fedora's equivalent of Kubuntu. I'm a GNOME user but I've heard good things.
Well, this is a KDE variant of Fedora Silverblue, so there are some quirks. If you want normal Fedora but with KDE, there is a KDE spin available: https://spins.fedoraproject.org/kde/
Whoops! Nice catch, I love Silverblue but forgot this was the Silverblue KDE spin.
Gnome is the default and there's a KDE "spin", but I use Sway myself so I can't really comment on how well KDE works.
I can't do that because I don't want to update every 6 months. If I wanted to do that I'd just move to arch/endeavour.
You don't _have_ to update every 6 months. Each release is supported for around 13 months so you can hop every 2 releases.
> There seem to be more and more things that are only delivered as snaps.
I'm on Ubuntu, and of all the software I use (I count around 20 programs installed not through the Ubuntu apt repositories), fortunately only two are available only on snaps - Chromium and Subsync. The first actually accelerated my move to Firefox.
Regarding Subsync, I had to write a ridicolous script to start/stop all the snap services - ridicolous because Snap has an integrity service that overwrites any change to the Snap system (!!), so one can't even hack the Snap system files without disabling such service. It actually gets worse - Ubuntu has a relatively tight intergration with snap: one can't have the `snapd` serviced disabled (without hacks), because the Ubuntu software upgrade invokes it if present, and if it's disabled, the upgrade will hang.
If Ubuntu will force more software to go through Snap, I'll abandon it (after many, many years).
I'm on Ubuntu, and of all the software I use (I count around 20 programs installed not through the Ubuntu apt repositories), fortunately only two are available only on snaps - Chromium and Subsync. The first actually accelerated my move to Firefox.
Regarding Subsync, I had to write a ridicolous script to start/stop all the snap services - ridicolous because Snap has an integrity service that overwrites any change to the Snap system (!!), so one can't even hack the Snap system files without disabling such service. It actually gets worse - Ubuntu has a relatively tight intergration with snap: one can't have the `snapd` serviced disabled (without hacks), because the Ubuntu software upgrade invokes it if present, and if it's disabled, the upgrade will hang.
If Ubuntu will force more software to go through Snap, I'll abandon it (after many, many years).
Yikes! I fortunately haven't run into this yet. There are very few cases where I would take the easy road and install a snap (maybe a one-time use CLI where performance doesn't matter and I'd uninstall after?). If not in apt I'd probably ignore the suggestion and look for a ppa, binary, or, in rare cases, compile from source.
[deleted]
Firefox is only available as snap now. I gues it's bthe same for other apps.
For VSCode I managed to download a deb from their site IIRC, but from apt it only suggests to download from snap.
For VSCode I managed to download a deb from their site IIRC, but from apt it only suggests to download from snap.
Interesting. Firefox on snap was an absolute nightmare. Not only would New Tab break after an update, fonts would break as they may be (re-)loaded from disk which becomes missing when the app gets remounted at a new mount point after an update. I forget which hoops I had to jump through, but I did finally find a non-snap method that allows me to manually update (or dismiss prompt) to get around these issues while staying up to date (~1 day)
VScode wasn't as bad, as it usually seemed to work (but maybe flaky plugins were actually caused by snap?) but it was certainly annoying to lose the ability to switch between windows of the same app (alt+~, I think this was a custom setting to resemble mac) if the latest window/project was opened as a new version of the app (alt+tab)
VScode wasn't as bad, as it usually seemed to work (but maybe flaky plugins were actually caused by snap?) but it was certainly annoying to lose the ability to switch between windows of the same app (alt+~, I think this was a custom setting to resemble mac) if the latest window/project was opened as a new version of the app (alt+tab)
FF has been driving me crazy lately.
Every other day it blows away all my open tabs and whatever I had going on in them.
I have a bunch of random tabs open, some with essentially "unsaved work", like shopping carts which may be the result of an hour of research, editing files in web interfaces like github or fluidd (web interface to a 3d printer) ... and randomly once every day or 3, I'll go to touch anything, any button in any of those tabs, like edit that config file some more, or try to save it... and kablooey, "firefox needs to restart" and I lose everything I had going.
This is a new thing that didn't used to happen.
Apparently the snap teams response to this story would be "Don't use FF like that."
Every other day it blows away all my open tabs and whatever I had going on in them.
I have a bunch of random tabs open, some with essentially "unsaved work", like shopping carts which may be the result of an hour of research, editing files in web interfaces like github or fluidd (web interface to a 3d printer) ... and randomly once every day or 3, I'll go to touch anything, any button in any of those tabs, like edit that config file some more, or try to save it... and kablooey, "firefox needs to restart" and I lose everything I had going.
This is a new thing that didn't used to happen.
Apparently the snap teams response to this story would be "Don't use FF like that."
I have a similar situation.
The issue here is that the apt update changes firefox program files underneath it which needs a restart. Afaik, using the mozilla release directly is the only solution for this where the program files are changed only after exit.
Edit: This has become more common nowadays due to multiple point releases close to each other, to fix some important bug.
The issue here is that the apt update changes firefox program files underneath it which needs a restart. Afaik, using the mozilla release directly is the only solution for this where the program files are changed only after exit.
Edit: This has become more common nowadays due to multiple point releases close to each other, to fix some important bug.
What, where is firefox only available as snap? I'm on Ubuntu 20.04 so haven't run into that yet.
flatpak is a great alternative and it works well on ubuntu. Although I've just moved wholesale over to pop_os with flatpaks and LTS version.
> no auto-update controls
Maybe not what you want exactly but there are controls and claiming otherwise is misleading.
https://snapcraft.io/docs/keeping-snaps-up-to-date#heading--...
Maybe not what you want exactly but there are controls and claiming otherwise is misleading.
https://snapcraft.io/docs/keeping-snaps-up-to-date#heading--...
Thank you for this. Severely limited controls are certainly better than no controls. Looks like timer can reduce breakages to no more than monthly, hold can prevent breakages for up to 3 months, and metered seems like it may be able to disable updates and subsequent breakages if I can figure how to trick the OS into thinking I'm always on a metered connection (which is actually true, but I'm on LTE via wifi)
We switched over to Fedora, way better
Both Fedora and Mint are touted as the "new Ubuntu." Mint even has a Debian fork experiment going on.
For work, keep in mind that Fedora defaults to SELinux and a firewall. That's is a huge bonus when approaching IT about a switch.
For work, keep in mind that Fedora defaults to SELinux and a firewall. That's is a huge bonus when approaching IT about a switch.
I'm switching to debian my next install. It's similar enough internally
For a personal desktop, I wouldn’t recommend it unless you’re willing to run sid, because while the outdated software collection is no big deal most of the time, it’s a tremendous pain when you really do need a new version of something, and you ultimately just give up and instal the whole thing from source into /usr/local, which in a half-dozen years predictably evolves into a mess.
Running sid is an option, but the amount of fiddly Debian magic you end up needing to learn when it breaks is IME not smaller than the effort of setting up a mostly-unpatched rolling-release like Arch (and I’m sure there are other options). Given that e.g. Arch’s packaging is simple enough it’s no big deal to package even your personal collection of handy scripts (and so the system does not develop funny-looking mold and bits of mystery food all over the place), I don’t really see the point. Just don’t update it when you’re on a deadline.
You can see that my arguments here are to a great extent a matter of preference and personal circumstances, though: do you have a reliable Internet connection for troubleshooting? do you prefer a more solid system that you have to fight and that fails badly but rarely or a less solid one that fails more often but in small ways? does getting locked out of the graphical environment every couple of years count as small?
(Offer not applicable on machines with cursed hardware like nVidia or Broadcom.)
Running sid is an option, but the amount of fiddly Debian magic you end up needing to learn when it breaks is IME not smaller than the effort of setting up a mostly-unpatched rolling-release like Arch (and I’m sure there are other options). Given that e.g. Arch’s packaging is simple enough it’s no big deal to package even your personal collection of handy scripts (and so the system does not develop funny-looking mold and bits of mystery food all over the place), I don’t really see the point. Just don’t update it when you’re on a deadline.
You can see that my arguments here are to a great extent a matter of preference and personal circumstances, though: do you have a reliable Internet connection for troubleshooting? do you prefer a more solid system that you have to fight and that fails badly but rarely or a less solid one that fails more often but in small ways? does getting locked out of the graphical environment every couple of years count as small?
(Offer not applicable on machines with cursed hardware like nVidia or Broadcom.)
I've been using Debian stable on the desktop exclusively since Etch (around 2007). I strongly recommend it for someone who is always busy and doesn't have time to fiddle around. I run Sid in a schroot for the one package I need which is not in backports (a recent R for RStudio. Reference: http://charles.plessy.org/Debian/debi%C3%A2neries/r-4.1/ ). Debian stable relieves all the pain of the frequent breakage (CUPS) from constant unnecessary upgrades.
personally I recommend debian "rolling testing" (rather than pinning to a specific release name) with security updates from sid. this prevents all but the most subtle bugs from reaching you and you still get the new hotness within a few weeks of sid. there is a release freeze for a few months prior to the each stable release, but I've had no major issues from that.
the other subtlety is that security updates come later to testing than they do to either stable or sid, but this can be mitigated: https://gist.github.com/khimaros/21db936fa7885360f7bfe7f116b...
the other subtlety is that security updates come later to testing than they do to either stable or sid, but this can be mitigated: https://gist.github.com/khimaros/21db936fa7885360f7bfe7f116b...
I suggest pop_os if you like ubuntu but are tired of stuff like snaps and such, but still like the idea of an LTS
I switched many years ago. I make heavy use of Flatpaks, which are great, although they have a lot of unlocked potential still. dnf installs regular-old packages, as opposed to Ubuntu, where apt packages now install snap packages.
Debian or Fedora should become the new default recommendation. Debian probably fits better for novices, since Fedora doesn't have non-free packages out of the box.
Debian or Fedora should become the new default recommendation. Debian probably fits better for novices, since Fedora doesn't have non-free packages out of the box.
Debian and Fedora have always been my two recommended distros for people. They are the upstream providers of the packages for most distros, and in the case of Ubuntu it has always been a bad choice.
Even from day one, forking Debian and breaking a bunch of packages as they went off on their own, then years later going oops how do we fix this Daddy Debian? Adding Amazon to their search by default in Unity initially. Creating a new desktop protocol to replace X11 rather than work with the Wayland teams so they could rush to ship their phone that nobody wanted.
Canonical is just a good marketing company. They want to do things their way and screw over as many Linux developers as they can to get their way.
Even from day one, forking Debian and breaking a bunch of packages as they went off on their own, then years later going oops how do we fix this Daddy Debian? Adding Amazon to their search by default in Unity initially. Creating a new desktop protocol to replace X11 rather than work with the Wayland teams so they could rush to ship their phone that nobody wanted.
Canonical is just a good marketing company. They want to do things their way and screw over as many Linux developers as they can to get their way.
If you're a programmer I'd say Arch or Debian then configure as per your needs. As long as you don't do things blindly it will be very stable and blazing fast.
In my experience, Manjaro is a great, user-friendly version of Arch. YMMV, but I highly recommend it!
I used to be a pretty hardcore Manjaro evangelist (and I still recommend it to people who want to quit distro-hopping), but I've been burned a handful of times by it. Arch is obviously a notoriously unstable distro, but Manjaro in particular can lead to some nasty issues. Especially if you're mix-and-matching AUR packages with the Manjaro repository ones; I've had at least 3 or 4 systems get entirely borked because of an untracked dependency or something being too far behind in the Manjaro repo.
I think manjaro suffers breakage too much. These days I tell people to look into endeavour since they still use (mostly) arch repos and thus cause much less breaking with the using AUR packages if you're into those.
Second this!
Pop!_OS is a solid Ubuntu-based distro that uses Flatpak in place of Snap (among many other great decisions).
This is why I don't use it anymore: https://support.system76.com/articles/enable-hibernation/
I really liked my System76 laptop until the AC adapter died. I looked around on their site to buy accessories and it wasn't there. Eventually I found you have to open a support ticket to get a replacement.
Not only did it take multiple days for them to respond (me without laptop), their resolution was to attach an invoice for one despite me asking for two. I didn't want to open a new ticket so I just looked online for an AC that had the same voltage/amp/etc and head, then ordered three. I have multiple desks...
The three arrived approximately a week before the one they sent out.
Also, you can't actually open these the way they've glued them shut inside by attaching the heatsink to the outer case. Might be a manufacturing defect but definitely can't open mine after unscrewing the bottom.
Never buying a System76 laptop again after this thing dies.
Not only did it take multiple days for them to respond (me without laptop), their resolution was to attach an invoice for one despite me asking for two. I didn't want to open a new ticket so I just looked online for an AC that had the same voltage/amp/etc and head, then ordered three. I have multiple desks...
The three arrived approximately a week before the one they sent out.
Also, you can't actually open these the way they've glued them shut inside by attaching the heatsink to the outer case. Might be a manufacturing defect but definitely can't open mine after unscrewing the bottom.
Never buying a System76 laptop again after this thing dies.
That's fine, but my system boots so fast that hibernate is slower. Pop_OS is a very nice distro, particularly the LTS.
Because they support hibernation? I assume the answer here has to be "because it's a PITA to enable", but as far as I know no distro does this correctly by default on an encrypted drive.
> because it's a PITA to enable
I went over the blog post, and it looks like it's a PITA to enable because they went out of their way to make it so by using a weird partition scheme. I've never installed pop OS, but according to that blog they're using LVM on LUKS, which should work fairly well.
> but as far as I know no distro does this correctly by default on an encrypted drive.
What does "correctly" mean here? On my previous laptop I had arch installed on ext4 on LVM on LUKS. Therefore, the swap was on the same LVM. Aside from having to manually set the "resume" kernel parameter, I never had to do anything, and it just worked.
I went over the blog post, and it looks like it's a PITA to enable because they went out of their way to make it so by using a weird partition scheme. I've never installed pop OS, but according to that blog they're using LVM on LUKS, which should work fairly well.
> but as far as I know no distro does this correctly by default on an encrypted drive.
What does "correctly" mean here? On my previous laptop I had arch installed on ext4 on LVM on LUKS. Therefore, the swap was on the same LVM. Aside from having to manually set the "resume" kernel parameter, I never had to do anything, and it just worked.
Because it's a pain in the ass for what should be the default, especially if you want to use it on a laptop and not have the battery die overnight.
Some argue full disk encryption should be the default. Others argue hibernation should be the default. Here they appear to be in conflict, and that the former was prioritized.
But they're not. You can very well have the swap on top of LVM on top of LUKS. And the root and other partitions share that same LVM and LUKS. So now you have FDE and the kernel will know how to assemble it all. The only difference with the default pop OS install is that the swap key isn't changed on every boot. But since the other partitions holding the actual data use persistent keys, that doesn't look like much of an issue to me.
Plus, if you're OK with using a TPM, you can also get waking up from hibernation without having to enter type in your password.
Source: been doing exactly that (without the TPM part) on a laptop for a few years, and it just worked like a charm. No hoop-jumping involved or anything.
Plus, if you're OK with using a TPM, you can also get waking up from hibernation without having to enter type in your password.
Source: been doing exactly that (without the TPM part) on a laptop for a few years, and it just worked like a charm. No hoop-jumping involved or anything.
If I wanted full disk encryption, my memory state in swap would sure as hell be one of the things I wanted encrypted.
Of course, you would. And it is. All the partitions, including swap, are on top of a LUKS volume.
ah, ok. Apologies.
Try one of the variants like Pop_OS! they use flatpaks as a replacement for snaps and it works well. I've moved all my ubuntu systems over to it without any issues. The KDE version is nearly as nice as the stock version (looks-wise) if you're a KDE person, which I am.
I would love to switch to something else (e.g. NixOS) but Ubuntu is the required OS for NVidia's Jetson family of hardware.
You can use the Jetson with Docker! It's a total pain in the ass though. Their drivers and software are horrible.
Ok, thanks. Does it give access to the GPU?
Yes, if you run the container with the right options. This is a little out of date and may not even be required any more, but it gives you the full SDK manager gui in Docker.
https://github.com/raffraffraff/nvidia-sdkmanager
https://github.com/raffraffraff/nvidia-sdkmanager
Maybe look at Mint?
> The issue that makes us resist the idea of simply disabling updates altogether is that very often that will mean never update rather than update at someone’s discretion, and then we’re getting back to some of the problems that got us here in the first place.
I’m sorry, who owns the machine here?
I’m sorry, who owns the machine here?
Isn’t this also the of the main reasons the linux community hates windows. Because windows has a habit of forcing updates and reboots.
The linux community isn't a big fan of Canonical. Everyone starts with Ubuntu, distro hops, installs Debian or Arch configured according to them and tries to bring Ubuntu back from the dark side.
Canonical used to be The Chosen One, the prophesied savior that would decend from the heavens and bring us a reasonable chance at actually having a Year of the Linux Desktop. Then something happened, and they turned to the darkside, started adopting the worst behaviors of Microsoft, and here we are. Sadly they are still promoted as the recommended "generic" distro for the masses.
You will get the updates, and you will be happy.
“The beatings will continue until morale improves.”
I see they're honestly trying to ease life for technically illiterate users (or, put it another way, to chase Apple's "just works" experience). But ignoring the needs of professional users (who are influencers) is a sure way to divert all users.
Many technically illiterate users don't like forced automatic updates either. Having your software behave one way one day and another the next day is user-hostile. The only people it helps are organizations that wish to lower support costs.
I have heard disturbing stories from tech-illiterate windows users complaining about forced upgrades, reboots—even fullscreen Office365 ads. It's a pain to be "the computer guy" for windows users. They need help constantly and for silly things that has changed place or behaviour. I also do support for tech-illiterate linux users on Fedora and they never call or have trouble. It just works, even with auto-updated flatpaks enabled.
I'm not even tech illiterate (I used to work at Microsoft!) and I was thrown off by the fullscreen Office365 ads they added around 2019. The shortcut was just "all of your modifier keys" so it got activated randomly when I picked up my keyboard by the corner and it took me a bit to track that down. Think I had to fix it with a registry key. It's fucking nonsense and it's really no mystery why users don't want automatic updates.
Yeah ton's of memes out there by windows users who were forced to upgrade 5 minutes before a meeting or something. It's a real issue. It's why I leave my office laptop on all night, so they can do their stupid forced upgrades in the middle of the night like they schedule them. I have too many meeting to wait for a 30minute - 1 hour update popping up unexpectedly.
OK but even Apple lets you toggle automatic updates on or off.
And so does Google Play Store. Even windows has the settings buried somewhere
Counter point for general software: some people don't upgrade software for _years_, due to which vendors have two problems -
1. Open security vulnerabilities
2. Necessity to maintain backward compatible infra
To offset this, two channels of releases can be maintained - one for security fixes, another for general features etc. But again here, we run into problems where maintenance of two channels isn't economical, and you end up testing security fixes on various versions.
How can these be addressed if upgrades are not forced, are there standard processes followed that provide the best compromise for both vendors and end users?
To offset this, two channels of releases can be maintained - one for security fixes, another for general features etc. But again here, we run into problems where maintenance of two channels isn't economical, and you end up testing security fixes on various versions.
How can these be addressed if upgrades are not forced, are there standard processes followed that provide the best compromise for both vendors and end users?
> How can these be addressed if upgrades are not forced, are there standard processes followed that provide the best compromise for both vendors and end users?
There is an easy way to solve this problem. Default to auto updates, allow people to turn it off, by acknowledging what that means. Most users use whatever is the default anyways. Vendors gets to push their updates, users who don't want those, can reject them. If someone gets hacked because they turned off auto update, the vendor won't be on the hook for it, because the user said they were aware of it when they turned it off.
I think the core problem here is not that people are asking for auto updates to be off by default, they simply want to have the option. And frankly, for professional use cases, you have to be able to turn off auto updates, as otherwise it'll harm the workflow as you can't control when the update happens.
There is an easy way to solve this problem. Default to auto updates, allow people to turn it off, by acknowledging what that means. Most users use whatever is the default anyways. Vendors gets to push their updates, users who don't want those, can reject them. If someone gets hacked because they turned off auto update, the vendor won't be on the hook for it, because the user said they were aware of it when they turned it off.
I think the core problem here is not that people are asking for auto updates to be off by default, they simply want to have the option. And frankly, for professional use cases, you have to be able to turn off auto updates, as otherwise it'll harm the workflow as you can't control when the update happens.
Yup, makes perfect sense. Thanks!
I'll give you the same answer I gave people when Microsoft started doing the same nonsense with Win10:
I totally agree your average end user is poor at managing updates themselves and thus it is justified to enable auto-updates by default. What that does not justify is totally removing the ability to turn them off. Feel free to make it a little harder to disable: the user has to run a CLI command or something, but the option should be there.
> How can these be addressed if upgrades are not forced, are there standard processes followed that provide the best compromise for both vendors and end users?
If you go through the extra effort to disable updates and don't grab a security fix, that's on you. How is "you have to do exactly what I tell you - wait why is nobody using my software?????" a best compromise for users? What are users expected to do when an upgrade breaks something and they can't downgrade?
I totally agree your average end user is poor at managing updates themselves and thus it is justified to enable auto-updates by default. What that does not justify is totally removing the ability to turn them off. Feel free to make it a little harder to disable: the user has to run a CLI command or something, but the option should be there.
> How can these be addressed if upgrades are not forced, are there standard processes followed that provide the best compromise for both vendors and end users?
If you go through the extra effort to disable updates and don't grab a security fix, that's on you. How is "you have to do exactly what I tell you - wait why is nobody using my software?????" a best compromise for users? What are users expected to do when an upgrade breaks something and they can't downgrade?
Sensible defaults, but built for the power user. Makes sense.
The old argument is that anything a power user can do, a malicious script can do too. So such options must be removed entirely if there is any chance of a less technically inclined user being tricked into doing it.
This argument doesn't hold water. At the point malicious software is already on the machine, an automated update doesn't help. And if someone is inducing you to manually turn off automatic updates for malicious reasons... they could just as easily be inducing you to install malicious software directly.
[deleted]
Make updates that are appealing enough that users want them.
[deleted]
I love Ubuntu, it's been my daily driver for over a decade now but if they continue with going against the community on this nonsense this will be a strong indication for people like me that an era has come to an end and it's time to move on.
It used to be a community focused distro. This bs feels outright user-hostile.
It used to be a community focused distro. This bs feels outright user-hostile.
Just switched to Fedora about a week ago because I was getting fed up with user hostile Ubuntu bs, I like it a lot.
I'm a linux power user (kernel hacking level) and wanted Fedora so much to work for me. Every single time there were severe issues with getting it even installed. First two failed attempts took place on my dell laptop, the last two on my dual socket workstation with Nvidia GPU.
All four times was an exercise in a lot of googling, hacking configurations,etc. Sadly it was always too much work and I eventually gave up.
Hopefully one day the experience is seamless and I never have to go back to Ubuntu.
All four times was an exercise in a lot of googling, hacking configurations,etc. Sadly it was always too much work and I eventually gave up.
Hopefully one day the experience is seamless and I never have to go back to Ubuntu.
I don't like that you have to update it so often. I like the idea of an LTS. On systems I want to update often I just put arch on them so there is never major breakage that I can't roll back easily with snapper.
Each version of Fedora is supported for 14 months, so you can keep it a little behind but still get updates. They also will update the kernel so you’re getting updated hardware new support. With flatpak having up to date desktop applications is not an issue either. For development libraries I’m usually in some kind of a container with a fixed version, so updates shouldn’t much of an issue either.
For example I just installed Fedora 35, I will probably install 36 at some point after 37 comes out, and stay one release behind current. Major upgrades are still relatively safe because of FS snapshots. I just personally prefer a slightly slower pace than “bleeding edge all the time”.
For a server I would just put Alma/Rocky Linux on it.
For example I just installed Fedora 35, I will probably install 36 at some point after 37 comes out, and stay one release behind current. Major upgrades are still relatively safe because of FS snapshots. I just personally prefer a slightly slower pace than “bleeding edge all the time”.
For a server I would just put Alma/Rocky Linux on it.
>Major upgrades are still relatively safe because of FS snapshots.
Also, in general the upgrades are quite reliable. I have a few systems that have been upgraded in-place for years without any issues (regardless of snapshots, since they're using ext4).
Also, in general the upgrades are quite reliable. I have a few systems that have been upgraded in-place for years without any issues (regardless of snapshots, since they're using ext4).
I feel like people who use fedora swear by it. What DE do you use? I prefer KDE but donno if it’s time to retry gnome or something else.
If you're moving to Fedora then Gnome really is the path of least resistance, and highest level of integration and support. But you can make KDE work, or even use a tiling WM like Sway and customize it to your taste. In any case, you get to enjoy the benefits of a really well done distro.
> If you're moving to Fedora then Gnome really is the path of least resistance
Which is really the largest drawback by far that I've found. GNOME 4 is user-hostile garbage made by people who really really wish they were designing for tablets. It's practically useless without third-party extensions, which are of course unsupported. It doesn't even have a system tray FFS.
If Fedora Kinoite worked as well as Fedora Silverblue, I think I could be reasonably content. Immutable base system with Flatpak and Toolboxes is pretty close to how I actually want a system to work.
Which is really the largest drawback by far that I've found. GNOME 4 is user-hostile garbage made by people who really really wish they were designing for tablets. It's practically useless without third-party extensions, which are of course unsupported. It doesn't even have a system tray FFS.
If Fedora Kinoite worked as well as Fedora Silverblue, I think I could be reasonably content. Immutable base system with Flatpak and Toolboxes is pretty close to how I actually want a system to work.
Alright. Will give it another go. Hopefully it’s easier to setup a side bar and top bar than last time I used it.
FWIW, I've used Fedora's KDE spin [1] and its very polished. That said, if I was still using linux on the desktop these days I'd go with OpenSUSE Tumbleweed[2]. With KDE my experience was that they made big improvements with every release, and tumbleweed was a nice way to get a stable-ish rolling release distribution that gets all the nice KDE updates without me having to wait another 6-8 months.
[1] https://spins.fedoraproject.org/en/kde/
[2] https://en.opensuse.org/Portal:Tumbleweed
[1] https://spins.fedoraproject.org/en/kde/
[2] https://en.opensuse.org/Portal:Tumbleweed
I'm coming from Ubuntu so I stuck with Gnome as that is the default recomendation for Fedora as well. I've tried KDE in the past and while I understand why lots of people like it it never really clicked with me.
But while we're on the topic of user hostility, I'm not really a fan of some of the changes the Gnome devs are doing either, so I may switch again in the future but at least for now I'm comfortable using it and they aren't outright antagonizing my system like Ubuntu does with snaps.
But while we're on the topic of user hostility, I'm not really a fan of some of the changes the Gnome devs are doing either, so I may switch again in the future but at least for now I'm comfortable using it and they aren't outright antagonizing my system like Ubuntu does with snaps.
You can use both? I use Mint but also use QTCreator (KDE) for development.
Things like hiDPI support go funny, but that's just Linux for you.
Things like hiDPI support go funny, but that's just Linux for you.
I warned them half a decade ago on a super-long thread (on that forum, it’s called “External repositories”) that having Canonical in charge of everything, having no support for external repositories, and no ability to disable updates was going to be the death of Snap. They would not listen at all to me or anyone on that discussion. It was nothing but double-down.
Well… what, five years later, here we are. They are still trucking on although the Linux community at large has turned against them, yet they remain in their echo chamber of a forum and don’t see it, convinced it will all work out or some crap.
Well… what, five years later, here we are. They are still trucking on although the Linux community at large has turned against them, yet they remain in their echo chamber of a forum and don’t see it, convinced it will all work out or some crap.
If you give people tools to enforce their own policies, you have an adaptable system.
If you create a set of policies that users can choose from, you have limited your usefulness to just those cases that fit in those policies that you have implemented.
If you choose a single policy for everyone, only people who are willing to use that policy will use your system.
These patterns repeat across operating systems, services and applications.
If you create a set of policies that users can choose from, you have limited your usefulness to just those cases that fit in those policies that you have implemented.
If you choose a single policy for everyone, only people who are willing to use that policy will use your system.
These patterns repeat across operating systems, services and applications.
Snap developers have refused to rename $HOME/snap to be less visible for nearly as long, they have and are shipping very broken software, all while using update methods that corrupted people's data unannounced until very recently (the update mechanism made data directories non-writable unless you enable some experimental option).
They very much do not care about the end-user with Snap, only how to appear attractive to potential customers.
They very much do not care about the end-user with Snap, only how to appear attractive to potential customers.
It’s not even $HOME/snap, it’s /home/$USER/snap.
https://snapcraft.io/docs/home-outside-home
> The snap daemon (snapd) requires a user’s home directory ($HOME) to be located under /home on the local filesystem. This requirement cannot currently be changed.
https://snapcraft.io/docs/home-outside-home
> The snap daemon (snapd) requires a user’s home directory ($HOME) to be located under /home on the local filesystem. This requirement cannot currently be changed.
It's a pretty wild switch of power from the usual distro packaging where the packager is a neutral middle ground between the application's and the user's interests, often swinging to the side of being the user advocate.
Of course, compared with other platforms and auto updates, it is clear why app developers prefer and expect to be in charge of updates.
Of course, compared with other platforms and auto updates, it is clear why app developers prefer and expect to be in charge of updates.
This is its most egregious sin, IMHO. Imagine low level system software with such a high opinion of itself that it thinks it deserves a front and center place in your home directory for you to look at every single day.
We don't have ~/ssh or ~/dconf do we? We've had the XDG spec for decades now - this selfish decision makes me so irrationally angry that it's the one reason I'd switch to Fedora to avoid snaps.
We don't have ~/ssh or ~/dconf do we? We've had the XDG spec for decades now - this selfish decision makes me so irrationally angry that it's the one reason I'd switch to Fedora to avoid snaps.
[deleted]
I think auto updates are ok but not for everything, client side app are ok to auto update the rest not so much.
No. No they're not OK. Sometimes I am forced to live on eye-wateringly expensive bandwidth (because dodgy rural DSL and trees falling) and I'd go broke letting things autoupdate during those times.
I don't understand this remark. They charge you more when trees/systems are down? Are you talking about using some backup service (like your cellphone) or something? Your comment is hard to reason out without information like that.
They're saying that sometimes their internet goes out either because of their rural situation or because trees fall and knock out copper lines. When that happens, they have to switch to an expensive internet solution.
Please correct me if I am wrong, but you can simply snap install with a --channel, which could be a specific version. This way it is not auto updating, since it's on that specific channel/version.
You are wrong :) updates are published to channels and anyone following that channel will get the update.
More about how snap channels work here. https://ubuntu.com/blog/controlling-snap-releases-with-chann...
More about how snap channels work here. https://ubuntu.com/blog/controlling-snap-releases-with-chann...
Aren't channels things like "stable" or "bleeding edge" or something like that? Which means that this would only work if the snap vendor cooperates.
But then you can't really blame Canonical and that makes the wole agument moot.
The argument is that "channels" are not "versions". So inside a channel, you cannot disable updates. And that's the way Canonical operates, they regularly push updates to their "stable" channel. There is no "v1.2.3" channel that will forever stay at that particular version until you switch channels.
The point is that you are the mercy of the snap publisher, and as the sysadmin, you cannot prevent the software from updating. Whether you should or not do that is a different debate.
The point is that you are the mercy of the snap publisher, and as the sysadmin, you cannot prevent the software from updating. Whether you should or not do that is a different debate.
Canonical directly maintains only a handful of snaps, and even so it's up to the individual teams to do the relevant QA before publishing a version to the stable.
You'd expect that publishers follow the same process, that a stable channel means it's really stable, whereas version breaking changes really end up in per version channel. Ideally you have the latest/{stable,beta,candidate,edge} which follows the latest version of the software, and eg. v1/{stable,beta,candidate,edge}, v2/{stable,beta,candidate,edge}, v3/{stable,beta,candidate,edge} for individual version. A simple concept but surprisingly hard to follow.
Maybe the publishers are really lazy and don't care about the users or the maintenance cost of keeping n versions around is just too high, in which case it's up to the users to make their effort worth it.
You'd expect that publishers follow the same process, that a stable channel means it's really stable, whereas version breaking changes really end up in per version channel. Ideally you have the latest/{stable,beta,candidate,edge} which follows the latest version of the software, and eg. v1/{stable,beta,candidate,edge}, v2/{stable,beta,candidate,edge}, v3/{stable,beta,candidate,edge} for individual version. A simple concept but surprisingly hard to follow.
Maybe the publishers are really lazy and don't care about the users or the maintenance cost of keeping n versions around is just too high, in which case it's up to the users to make their effort worth it.
I agree with your point, but the issue discussed here is being forced into updating. Sure, that's an issue because some people aren't fully confident that a "minor update" won't break things. They may or may not be right, but that's a separate debate.
The point is that people want to be able to disable automatic updates, even minor ones, and that's not possible.
edit: I can see how my previous comment could have been confusing. To clear it up, I was trying to say that a workaround for the forced updates would be for vendors to publish a "single version channel". So version 1.2.3 would be a dedicated channel, with no updates ever. Version 1.2.4 would be a separate channel, with only that single version. This would of course be impractical, for both the vendor and the user.
The point is that people want to be able to disable automatic updates, even minor ones, and that's not possible.
edit: I can see how my previous comment could have been confusing. To clear it up, I was trying to say that a workaround for the forced updates would be for vendors to publish a "single version channel". So version 1.2.3 would be a dedicated channel, with no updates ever. Version 1.2.4 would be a separate channel, with only that single version. This would of course be impractical, for both the vendor and the user.
AFAIK, selecting a channel doesn't prevent automatic updates, it just limits them to a subset of versions. It doesn't in any way prevent a new version from being published to that channel and automatically installed.
Where Microsoft leads with its bad ideas Linux distros will follow blindly. The sad thing is those who decried a Microsoft for their evilness of doing things like this are the same ones that have turned right around and started defending it in the name of "users are stupid so give them less freedom".
more like "ubuntu will follow blindly" other big guys like redhat, suse, etc have more sane defaults.
[deleted](1)
[deleted]
We use microk8s on our dev clusters and its really great when an automatic upgrade goes sideways. Also using channels didn't help since even a minor upgrade managed to break our setup once.
The last half year or so went ok, but not being able to stop automatic upgrades is ridiculous. In general I like opinionated software, but sometimes it goes to far.
The last half year or so went ok, but not being able to stop automatic upgrades is ridiculous. In general I like opinionated software, but sometimes it goes to far.
Canonical currently has their head in the sand for how Linux users at large see it.
If you try to talk about how Linux distributions don’t like it, they’ll just say, “but Snap is available on all the distributions” or some crap cop-out.
I had a long forum thread about all the issues people are complaining about half a decade ago. They wouldn’t budge, and still won’t budge.
If you try to talk about how Linux distributions don’t like it, they’ll just say, “but Snap is available on all the distributions” or some crap cop-out.
I had a long forum thread about all the issues people are complaining about half a decade ago. They wouldn’t budge, and still won’t budge.
Linux users are some of the most opinionated people. At the end of the day, money/convenience matters. Why exactly would they pay attention to you when they have their own priorities?
Snaps reduce reduce their maintenance burdens, and they have the stats themselves for how popular they are. They are by and far more used than flatpaks from what I remember from the video by Martin Wimpress.
Oh and they have third party buy-in from software vendors like Mozilla, Microsoft, VLC, JetBrains, Spotify, slack etc...
Why would they budge?
Snaps reduce reduce their maintenance burdens, and they have the stats themselves for how popular they are. They are by and far more used than flatpaks from what I remember from the video by Martin Wimpress.
Oh and they have third party buy-in from software vendors like Mozilla, Microsoft, VLC, JetBrains, Spotify, slack etc...
Why would they budge?
So according to a Snap developer, Snap is more popular on Ubuntu, the only distribution that comes with it preloaded. That does not say anything about Snap’s popularity.
Vendor interest they have, community interest they lack. And if it continues, lack of community interest will result in a lack of vendor interest.
Vendor interest they have, community interest they lack. And if it continues, lack of community interest will result in a lack of vendor interest.
They literally have stats for each snap download and install.
https://snapcraft.io/slack
You see the map at the bottom with a list of OSes?
They have the interest, commercial and from the populace. Vendors have already integrated it into their pipelines.
What they don't have is the vocal minority. Frankly I don't get why people care so much, if you don't like it switch to something else. No need to whine about it online. They aren't preventing you from using flatpak.
https://snapcraft.io/slack
You see the map at the bottom with a list of OSes?
They have the interest, commercial and from the populace. Vendors have already integrated it into their pipelines.
What they don't have is the vocal minority. Frankly I don't get why people care so much, if you don't like it switch to something else. No need to whine about it online. They aren't preventing you from using flatpak.
In what world do unlabeled graphs count as stats? There’s also no counter for how many downloads there were, or any other useful statistic. They are just bars of various lengths with no explanation on what the lengths actually mean.
> Frankly I don't get why people care so much, if you don't like it switch to something else. No need to whine about it online. They aren't preventing you from using flatpak.
Then, in that case, by that logic, there’s no reason for you to whine about my whining.
> Frankly I don't get why people care so much, if you don't like it switch to something else. No need to whine about it online. They aren't preventing you from using flatpak.
Then, in that case, by that logic, there’s no reason for you to whine about my whining.
A dev on snapcraft can see the install count (I know).
A dev at Canonical can absolutely see how many install counts are there and if the venture is worth it.
>no explanation on what the lengths actually mean.
>Then, in that case, by that logic, there’s no reason for you to whine about my whining.
They don't care what you say, they don't care about the whining here. You aren't paying to support it either.
Feel free to switch to another packaging solution, or even a new OS. It won't affect Canonical's bottom line.
A dev at Canonical can absolutely see how many install counts are there and if the venture is worth it.
>no explanation on what the lengths actually mean.
>Then, in that case, by that logic, there’s no reason for you to whine about my whining.
They don't care what you say, they don't care about the whining here. You aren't paying to support it either.
Feel free to switch to another packaging solution, or even a new OS. It won't affect Canonical's bottom line.
I have been using Fedora 34/35 the last year or so, and Flatpaks are well integrated and mostly just works without any performance hit. Being able to adjust permissions per app (with Flatseal) has also been a great experience.
I have little experience with Snap, but the few times I have had to deal with it on Ubuntu-based distros, it has left a bad impression from a user perspective.