I think they just realized it gives them a way to package proprietary apps like Skype, Spotify, and Slack a bit more simply than would be required to apt-ify/dpkg-ify them. I really think that's the primary motivation.
Spotify is too. Their deb repo is just outdated compared to their snap (which itself is outdated compared to what's available on macOS and Windows). I think it's fair to say they don't care much.
And it's a pretty good one since the experience with having a large catalog of useful software in Flatpaks has been awesome and largely seamless. I just wish Canonical wasn't off doing their own thing or had started out in the open from the start so it would have a chance of being a useful standard instead of the weird Canonical store.
The number one reason why I don't like snap is: it puts Canonical in control.
Only Canonical can run a store. Once you install something, Canonical decides, when packages on your computers will upgrade. Wrt control, it goes way beyond Apple store/Google Play/Microsoft Store.
No thanks. Flatpak can preserve the benefits of decentralized repositories and upgrade under user control, with all the ease of packaging and sandboxing of the new toys.
I can never figure out Canonical's logic with going off to do their own thing. They don't do it with everything, so clearly it's not a complete rejection of things not made in-house.
It seems like they also often end up going back to the community solutions/standards eventually, so what benefit do they see in doing this over and over again?
Does it force the community solution to improve? If the options are community or Canonical does that competition have benefits to both? Not sure Canonical are thinking that explicitly but maybe it’s just hedging their bets if the community solution doesn’t work out.
I'm speaking in general, this would also include the Gnome churn a few years ago. Canonical seems to build their own thing then abandon it in favor of what the community was doing before or during the development of the Canonical thing. I'm just spitballing why that may happen.
FlatPak is a project initially hosted on freedesktop.org infrastructure with distributed copyright ownership under a copyleft license. It was initially founded by Red Hat employees but has attracted substantial support and contributions by companies such as Endless and Collabora, not to mention volunteer contributors.
The sandboxing part was spun off to the bubblewrap project, which has been adopted by the community for other purposes, such as Gnome's Epiphany browser.
SnapCraft on the other hand is a project that requires copyright assignment to Canonical Ltd for contributions, which presumably has the intended effects of keeping non-Canonical contributions close to zero.
Considering that Flatpak was essentially a hostile fork of the AppImage project motivated by Red Hat's insatiable hunger for control, I find it ironic when Flatpak supporters complain about Canonical "doing their own thing".
AppImage only solves the easy part of the generic-linux-app problem, namely running the packaged appimage; it does nothing to solve the hard parts: how do you build the application so that it will actually run on generic Linux distributions, and sandboxing.
Life, indeed. Reading the (excellent, mind you) documentation and, especially, the wiki is fun, I know, but sometimes I want to focus on something else (like getting things done).
Totally agree, just have to report back that it's no huge'er job in terms of systems management. But am on your page. I guess it's relative, I was Ubuntu, too, because I liked the next-next-next ideology, but, when it comes to it, either system-types can be as maintenance free as any other. Rolling releases has the convenience of not being so difficult to upgrade, as you just roll along, you sometimes end up having to reinstall, on these systems like here, like Ubuntu and co I mean. But yeah work is what's most important. I've been a happy Ubuntu user for ages, glad you're getting your work done. It's all that matters relatively speaking. Thanks
The AUR is so transparent. If I want to see how the AUR package is getting built, ez, read the PKGBUILD linked right from the packages page. I was immediately turned off to using Snap because I couldn't find how the Snap was built and really who built it. No Thanks, that's not how I install software on my personal computer anymore, it's one of the main reasons I exited windows as soon as I started to learn about infosec and trust.
Happy Arch and AUR user chiming in, a custody, or emigrant, from the F snap hell Ubuntu caused, and it's easy to verify and vet AUR content, if you care enough, the scripts are legible, readable, so it's just a matter of caring about your system. I agree, I am so happy about the Arch system since Ubuntu bit, ate wholehartedly, the snap bullshit. Thank fuck for AUR.
If it's to avoid this kind of aberrations https://news.ycombinator.com/item?id=22864985 it's totally understandable, but in practice, it doesn't work that smoothly unfortunately, not to mention the potential vendor lockdown, or as the Mint team phrased it:
> If you’re a Fedora user and you want to install Spotify, you’re told to go to https://snapcraft.io/spotify. Spotify doesn’t distribute RPM packages, appimage, Flatpak or anything useful to a Fedora user who wants to download it, or to a Fedora maintainer who wants to add it to a repository. Fedora users are told to go to what is essentially a commercial store operated by a RedHat competitor where stats tell them their distribution is only 7th best.
> We’re in luck, we can still download the .deb. If Spotify stops caring, what do we do? We move to snap because we have to? Will the snap store continue to let people download actual .snap files in the future or will that get locked down ? Will the snap store continue to operate without an Ubuntu One account or will we get vendor-locked ?
In all your examples, it is their respective company that does the packaging. Skype is packaged by Microsoft, and so on. Here is the Skype snap page, https://snapcraft.io/skype
Canonical provides the tools and several companies are providing their software as snap packages.
Another example is JetBrains that provide all their development environments as snap packages.
Snaps have benefits. Canonical sells 5 year service subscriptions in addition to the 5 years they already offer for free on LTS. Snaps enable a way to get the latest VSCode and other apps on very old versions of Ubuntu. Snaps allowed me to try out Debian and Fedora with minimal issues and easily integrate them into my dotfile manager with Ansible.
It's super super nice to have a real system for dealing with "pet" applications that users want to be updated outside of the distribution release cycle.
That works with Flatpak/AppImage too though, right? For me Snap has always had that Canonical smell of not-invented-here, just like Mir, Unity and Upstart. All of those were eventually replaced with what a majority of similar linux distros settled on. I'm not saying it was wasted development or that nothing was learned but ultimately they joined the rest of the ecosystem instead of the ecosystem joining them.
It seems that canonical does best when they embrace the ecosystem and not try to replace it.
Upstart actually preceded systemd and was adopted by Fedora, Red Hat, openSUSE and ChromeOS. ChromeOS still seems to use it, interestingly. It probably paved the way to systemd and probably fulfilled a need that no other init system could. Ubuntu was also fast to switch to systemd when it appeared.
Canonical cannot be accused of NIH for Upstart, it was a widely adopted clean init system at the time and made many distro's boot times great again. Service configuration files were also very easy and clean.
Unity was a desktop environment that both was liked by many people and reused many components from Gnome, I don't really see a problem here.
Just like with Upstart (which existed well before systemd did), Snap existed before Flatpak, and in fact existed in another form (Click) for two years before that.
So it's wrong to say Canonical is guilty of NIH-syndrome with these two items, when their versions were out first.
I spent just as long fighting snap when I wanted to use a custom font with ligatures. User-installed fonts don't work with snap, apparently. I would've spent substantially less time figuring out the problem, but I didn't even know I had the snap version - I typed `apt install code` and transparently got a snap package instead of a deb.
I'm honestly kind of confused because it's really easy to install VS Code on Fedora through the officially provided RPM package, and there is an automatically-installed repository so that it's kept up to date.
Snaps (and Flatpak) are the app store pipe dream all over again, about 11.. 12? years too late. If anything treat them as early indicators of the future financials of these distros, if attempting this all over again is central to their future business model. Snap to me is synonymous with desperate.
While I don't like the tech, the real reason Snap pushes me away from Ubuntu is the fear of this future where the app store dream turned out to be a failure again. What happens to the distro then?
/var/snap is a subvolume. Purging snapd wants to remove the /var/snap directory, but it being mounted subvolume, it will fail. Purging snapd will therefore also fail.
Destroy (-r) the /var/snap subvolume before apt purge snapd.
Similarly, if using flatpak, create a new subvolume for /var/lib/flatpak before installing the first one. You don't need to snapshot your flatpaks together with the /.
Interesting but it raises the question of what the effects of removing those snap packages are? I note that he doesn't mention installing anything to replace them, so it's probably not serious but still...
Those snaps are just, if I remember correctly, the dependencies for snap-store
So removing all of this only removes the snap store, which you don't need anymore ;)
A stock installation of Ubuntu 20.04 only has very few snaps. I think the only important one is the Snap Store/Ubuntu Software. If you can put up with the Snap Store, you can avoid (if you really want that) installing further snap packages.
Kudos to the OP, I'm glad this got posted on hacker news because Snap is so ridiculously broken.
Since 16.04, Snaps have been a huge pain for me with running LXC in production environments.
By default, Snap applies updates and restarts Systemd services anytime it likes, and there's no way to turn this behavior off! The only way to get around it is to download the Snap package binary and install that directly. Then Snap won't "know" where to get updates.
(Caveat emptor: "Workarounds" like this can easily lead to a bad security scenario, since any critical security patches won't be installed by any standard system update process)
Did I mention that a fair percentage of the time the Snap updates would leave LXC in a completely broken state? In production (and development, too)!
The final nail in the coffin in this scenario comes in the form of Snap being the official recommended way to install LXC. I don't know if Stéphane and friends even publish Debian packages anymore.
I get the idea behind snap and appreciate it, but the lack of configurability and no clear definition of what stable really even means . . .
But wait for the user to have a week-long job running for three days before you do it. That way they have to explain to their boss why there is now a 3 day delay.
I’m not sure how they’re trying to bill it these days, but certainly actions speak louder than words. All of Canonical’s design decisions seem to be aimed at making a consumer OS rather than a workstation or server one.
I think automatic updates on all platforms are probably an immense net benefit to the world given the huge degree of security vulnerabilities it avoids.
Ubuntu users may be more tech proficient than average users but even for developer machines, I think it takes a lot of concern out of the equation if the software is up-to-date.
As far as I'm concerned this doesn't deserve an '/s'.
The option to have automatic updates (whether it is enabled by default or not) is an entirely different issue than the obligation to have automatic updates. The first one is a blessing, the second one is a nightmare.
An important clarification: You never upgrade across major versions in place, or you never `apt-get upgrade`? I understand not jumping versions, but never applying security updates seems... imprudent.
The Snap team has some experience with this, seeing as how 20.04 has released and you still can't move the fricking ~/snap folder. Creating some generically named top-level folder in the users home directory is a straightforward fuck you to all users.
Dang, that really sucks. I was planning on updating my desktop to 20.04 but after reading about Canonical pushing snaps and now this thread basically claiming that moving or renaming the directory is impossible because what is in my opinion a design flaw in the entire system design, I think I'll switch to Manjaro or Arch for my desktop instead.
I am on the rolling releases already but I'm not going to install an LTS version that is so deeply integrated with the distributor while at the same time ignores the directory standards so incredible blatantly.
I agree, I'm using Manjaro on my laptop and it works like a treat. I have read the horror stories of a botched Arch upgrade so I think I'll stick to the slightly-more-stable Manjaro but the ecosystem itself is very nice for the moderately familiar Linux user.
I develop software that tries to target as many distros as possible, and I really don't see how Manjaro is in any way better than Arch. Botched upgrades aside, Manjaro is the only distro that couldn't produce a valid iso to boot on KVM/qemu. It has a very weird kernel config, sometimes users don't seem to have modules that are found on literally any other distro. Which is very sad because Arch just works.
In my experience the Manjaro config tends to work better on some of the hardware I've tried it on, requiring less tweaking to get it to run properly.
I'll also admit that I can't for the life of me get Arch to properly install with all the tools and features that are normally built-in to desktop environments to work on first boot. I'm sure I can make it work if I give it another try now that I've gotten more used to using Manjaro, but the Arch installation experience is not something I want to go through again any time soon.
I understand that most Arch users will want to decide exactly how they set up their system and all, but for my personal (non-work) machine I just want an operating system that works, allows me to mess with the standard Linux stuff and manages to install itself without me holding its hand. I'd much rather tick a box that says "enable full disk encryption" than manually configure cryptsetup and LUKS parameters. It's just too much effort for what I get out of it.
I think the (not that bad) manual installation process might keep some folks from installing it, but it makes you learn to choose from the very beginning.
After the initial install, update it on your schedule, and install things as you decide they are needed.
Ubuntu is the opposite -- install the world, then go madly trying to disable and remove the phone-home, forced-update, bloat.
This. Came here to post the same bug. I've been following the thread for the last 3 years, and it's an absolute mess.
I feel bad for the maintainers; it must be difficult to deal with all the rude and borderline disrespectful comments -- and particularly for something you're donating your time for free after all. But I must say that the architectural decision of creating a ~/snap was a colossal mistake.
Are they really donating their time, aren't they Canonical employees? Canonical being a company that is paid mostly by companies that use their distro in production?
I guess users have been sufficiently beaten into submission that many of them will put up with software randomly quitting on them, but the idea that daemons should be snaps is doubly crazy. "Oh, Tomcat just updated itself, that's why we were down."
I really have no idea what people are thinking sometimes.
I always resisted running Ubuntu in production, even when it was much easier to install the necessary software. When you pick a distro, you're picking their packaging and maintainer culture. I've always prefered CentOS for that reason. Even the little things, like installing a new package won't start/enable the services (because you should have a chance to configure it first) always came off as more pragmatic for system administration.
I run Debian on my workstation and laptops but still prefer to use CentOS/RHEL on my servers.
The automatic startup of newly installed services (before you even have the opportunity to configure them) on Debian (and derivatives) has always bothered me and is a (small) factor in my decision.
Fortunately, there are a few "workarounds" to prevent newly installed services from being automatically started!
First, there's the brute-force / heavy-handed approach -- override the systemd presets [0] to set all services to disabled by default:
Alternatively, as a one-time thing, you can "mask" the service before installing the package but this requires you to manually create the symlink (instead of using "systemctl mask") -- and requires you to know the name of the service unit beforehand:
Finally, there's the old, "sloppy" (IMO) method of "hacking" the /usr/sbin/policy-rc.d script to immediately exit with a status code of 101 ("action forbidden") [1].
(I'd recommend avoiding the latter entirely and going with whichever of the first two options better suits your needs.)
---
EDIT: Just remembered another method but I'm not sure if it still works:
> A cultural acceptance of WIP software seems common, in free software communities, in my experience.
On the one hand, yeah it's harder to complain when something is only built in someone's spare time for free. On the other hand... is non-FOSS really any better? Has Windows yet managed to re-merge the old and new control panels?
I've got an ansible playbook that modifies my ~/.config/lxc/config.yml for certain deployment scenarios.
Due to LXC now being a snap, the file is simply not there.
I guess it's 5 layers deep in namespaces, overlayfs and other stuff.
I was so fed up with this that I removed Ubuntu (and replaced it with Gentoo).
Editing a config file for a program should not be more complicated than opening the file in your preferred editor, no matter your distro.
Snaps break that.
I can't understand why they would break such fundamental thing and seemingly don't care about it.
LXC (and LXD, by extension) is packaged on Arch Linux as a binary, not a snap. I'm really grateful that the packagers worked with upstream to make this possible, as I heavily utilise LXC in my workspace.
I don't know how must be installed on your version, but on 19.10, snap can be completely removed: the only draw back is that pulseaudio depends on it, but I guess that for a server it's not that much of a problem.
Is Pulseaudio no longer viable using APT alone? One of the first things I do is excise Snap from the system entirely and install Flatpak. I had been planning to upgrade my daily driver to 20.04 in the very near future (I prefer LTS versions) but audio problems would be a complete deal breaker.
My god! Being unable to use snaps when you have “non-standard” home directory is ridiculous. What’s even more ridiculous is a response from snap developers - they marked this issue as “Won’t Fix”.
Dear snap developers, don’t make false assumptions that every user in Linux has to have home directory as /home/username just because standard Ubuntu installer does this. Only thing that you should care about here is $HOME
People will ditch snap and they'll end up using flatpak or something else just like the rest of the world. It happened with upstart and it then it happened with mir and unity.
I uninstalled it on all my Ubuntu systems and put it on hold. No new Ubuntu installs, switched to Debian.
What the actual fudge?
So my Asad AD trust users, whose home directories are /home/example.com/sam-account-name, are going to run into trouble when they upgrade to 20.04?
I think I am going to have to start figuring out a plan to migrate them all over to RHEL...
Hear hear. I imagine for dogfooding, LXD is only packaged in snap, so we can't use apt as the source anymore. After migrating, an upstream push to a 'stable' LXD snap channel introduced a regression that borked our environments, and there was no way to:
1. prevent machines in the fleet from pulling the broken LXD update
2. rollback broken machines to the previously working LXD version on the same channel, since it no longer existed in the Snap Store™.
I've been looking forward for this work to come to something working for some time already, but it's been already 3 years I've eyed on it, is it now coming to something working "soon"?
Debian is a bad choice if you want to package go applications (or rust apps, for that matter). Debian requires that all those little static dependencies be individually packaged. Common container software like lxd, podman, and umoci are not found in Debian.
The following distributions package LXD (that I know of):
* Void Linux
* Alpine Linux
* Arch Linux
* Gentoo
Some of those are more suitable for production installs than others, but if you know what you are doing and manage your deployments well, all of them could work.
I was not aware. Too late to edit now, but that is indeed a great option! Rolling release is a bit ambitious for a hyperlink without nixos like features.
Do you happen to know _why_ Debian decided to require that for Go projects? It's so absurdly complicated.
I've been looking into .deb packaging for Caddy but it really feels like they require us to jump through too many hoops to make it happen. I'd much rather just ship a prebuilt binary.
Security. Dynamically linking stuff is always going to be better than statically linking. Do you trust upstream to keep track of security issues and rebuild in the absurd dependency tree that is Golang software? Or the multi-year old effort which is the current Debian security team?
The reason why it's absurdly complicated is solely on the Golang team, not Debian.
Funny. I have been working on a blogpost detailing the silly things I encountered while packaging LXD properly for Arch Linux. Should probably finish it up one of these days.
Without too much details. But I personally got into LXD while bootstrapping kubeadm clusters with salt. LXD profiles made it very easy to work with compared to alternatives.
It's clearly not production stuff, but it works very well for a quick test bed before production deployments.
Same! Unfortunately we have a system is more or less tethered to use of LXD. While other workloads have moved to CentOS or Red Hat systems, LXD is supremely broken on those systems (or any distro that uses SELinux). It's extremely frustrating to be tied to Ubuntu for this one reason. It's even more frustrating when one of the key selling points from Canonical is "cross distribution!" Which appears to only be true for basic cases, or in the sense of, "Sure it's cross distro if someone other than us is willing to put in the work for their distro!"
YEP. For various reasons, we want to run Ubuntu on a server. Reboots and autoupdating are hazards and bugs for us. Upgrades & fixes mean patching our containers and starting fresh servers. Instead of rebooting a running server, we delete it. Trying to use Ubuntu environments means having to add custom disable-reboot-upgrade-downtime init scripts that we do not trust across updates: will bumping a minor version break them 5 days later? Super bad for reputation. I rather be updating Ubuntu more frequently, not less!
(Same-but-different for enforcing non-interactive mode on installs.)
I'm using LXC from ubuntu packages for that very reason, got burned when a cluster upgraded automatically. I guess I must be very out of date if the debs no longer exist.
I actually really like snaps and that's the only bad experience I've had. I don't know why LXC would come in that form, very weird.
I get the idea behind snaps is that someone recognized that configuration management was a problem but didn't yet appreciate just how deep that problem goes.
It is a seriously difficult thing to get right. I always applaud people to take on difficult problems and try to solve them, but I would not expect it to have any sort of robustness for another 5 years at least.
On top of all of this bad behavior... I did try Snap to install Opera browser. Opera is written such that you need to put widevine libs in a certain directory for it to work. After tons of hacking and Googling, there is zero way to inject files into the file system of a Snap. I understand the security precautions, but that feels ridiculous. I left Ubuntu after more than a decade over their obsession with Snap.
Snaps also are completely broken for NFS mounted home and data directories with automount. Which is the classic corporate Linux deployment. Of course, systemd doesn't even support wildcard automount....
Snap developer responses are hilarious. No matter what your use case is, Snap developers know better than you, you silly irresponsible sysadmin/user. Snap is basically just another App store.
> Switching to another browser to fix a packaging problem with the first browser is using a sledgehammer to crack a nut.
Sure, but some people just want to have their problem fixed and they only have a sledgehammer in front of them. If it works, is it really that bad?
> a browser wrapped in a cryptocurrency promotional wallet thing
I think you have it the wrong way around. It's a browser containing an integration with a cryptocurrency wallet, not the other way around. You'd still be able to use it as a normal browser if you ignore the cryptocurrency stuff.
I installed keepassxc using a snap, but because it was in a snap browser integration didn't work with my browser because of the snap isolation, rendering it useless. Also it's kind of weird that hey Damon has to run just so that I can install snaps and one Daemon per snap, too. I'm pretty sure I don't like that.
Keepass as a snap because security right /s. This is an actual piece of software that has a history of being modded by attackers to steal credentials. Why would you put that in a snap?
Any Keepass (or similar) software, it should run as predictable as possible. I know this software was once offered with a trojan loaded on some download website, but just searched around and could not find anything about it. Maybe the maintainers remember.
It seems like on recent Ubuntu installations some packages are provided by snaps (ie. "apt install XXX" will install a snap). I'd be interested in disabling this behaviour, if anyone knows.
I think that this is just the case with LXD.
LXD used to be distributed as a DEB package in Ubuntu 18.04.
Therefore, to make it to upgrade from DEB to snap in newer versions of Ubuntu, there is this dummy 'lxd' DEB package in the repositories that in fact installs the snap package of LXD.
Other than that, I do not think other packages are affected.
If gnome-3-34-1804 and
gtk-common-themes are a snap, what happens when we remove them? I expect to be able to install them using apt but I went to https://launchpad.net/ubuntu/focal/ and I couldn't find them. So "a snap-free Ubuntu" seems to be a really a different kind of Ubuntu. (Unless there are also other versions of Gnome in 20.04.)
These are resources/dependencies for other snaps. The .deb packages for Gnome and your GTK themes stick around. You can safely remove the snaps and not see any real noticeable difference.
I really like the idea of snaps. I really don't like a lot of the execution decisions around them.
Snaps break debain's stable release model. They allow upstream to ship updates outside of the normal 6 month ubuntu releases. There are times when you might want this, but it should be opt in not mandatory. I thinking specifically of lxd which is only shipped via snaps.
The snap store's trust model is confusing. Its hard to tell who is making the packages and how they are sandboxed. If I'm going to install a proprietary piece of software I want to know exactly what it can and can't do. Lately I've been using firejail when I need to run things like this.
And now for a minor complaint that also feels most user hostile to me: why do the snap developers think its ok to require a non hidden directory in $HOME? Seriously my home directory is MINE, if you have to store application state there at least have the decency to do it in a hidden directory.
I've always liked OS X's concept of the Library folder, particularly back in Snow Leopard when it wasn't hidden by default.
Applications need a place to save state, and you don't really want it to be hidden, because sometimes I as a user do need to change it manually for any number of obscure reasons. So you make a subfolder that's designated for apps to write to.
There's no good way to put this into the existing Linux model though. All you'd do is add yet another standard a la https://xkcd.com/927/
You can press cmd-shift-g to open a "Go to folder" prompt which has some basic tab completion. This also works in file selection dialogs. Hopefully this saves someone as much time as it has saved me over the years.
I get into the Library folder by doing: cmd-shift-g -> ~/Library -> enter
Well, that's a symlink. It's a good idea, and something I should remember if I ever do start using Linux again—but the downside is that if I do need to temporarily enable hidden files, I'll see the same directory twice.
I'm being picky, I know! But I still think the Library approach is cleaner. (Again, back when it wasn't hidden by default!)
And the problem is gigantic, programs in general are completely broken - why does my entire system have to be compromised because I decided to play Catan. We need the iOS/Android model for permissions on desktop.
Thats one thing that snaps are trying to do. I personally prefer firejail for application sandboxing and permissions but then you have to be extra careful how you install the application (dpkg post-install scripts have been known to do sketchy things) and you have to make sure you never accidentally run the application without firejail.
> We need the iOS/Android model for permissions on desktop.
This model is terrible. OS asks up-front: program wants permissions to do A, B, C, X, Y, Z: grant/refuse? You the user decide that the program should not be allowed to do X, so you refuse. Now the program will not run at all.
That's about the worst design possible. A 10 year old can brainstorm a better design within a few minutes.
At least on recent Android versions the apps only ask for permissions when they actually need them, not on install time, and you can grant/refuse individual permissions.
This is also how iOS has worked since forever. I think it's helpful, but not that helpful.
In practice, apps that want access to my contacts usually keep asking for access every time I try to do anything, until I eventually either relent to make the prompts go away or click allow by accident.
And that's me as a computer-enthusiast. I would bet money most normal people just hit allow always. Because it's easier.
The missing piece is "refusing" permission should instead give dummy data: an empty address book, a random location, etc. Better would be profiles: Full, Basic, Public, Anonymous, etc
I'm not necessarily against this but there are some pretty major UX implications for non-tech users who don't understand what's going on. "Who is Foo Smith and why does this app think I know them?"
In Android 10 you "only" need to deny a permission 3 times until it is auto-rejected without a prompt.
Some apps even try to circumvent this system by showing a "help" screen with instructions on how to re-enable the permission manually, but I only saw this twice.
> At least on recent Android versions the apps only ask for permissions when they actually need them, not on install time, and you can grant/refuse individual permissions.
Still, this is not practical enough. A true user-centric strategy would be to offer "mock-permissions" to an app, so that if an app says that it needs to read your home dir, you grant mock permission to the app, and it sees an empty home dir, not yours. From the point of view of the app, it should be impossible to know if it has been granted the real permission or just a mock permission.
People still just click "allow" on everything. They get tired of getting questions asked, and just want the program to work, so they don't even read anything and just tap tap tap until it lets them through.
Access your files? Sure. Access your documents? Whatever. Send data off to our corporate data vacuum? Whatever, I need to see what my face will look like with an AR moustache!
Also, are you running Catan as root or something? How is it able to compromise your whole system?
I agree with you on everything but the last two sentences. An unprivileged user account still has a ton of power in a modern Unix or Windows system, because the security model doesn't really solve this problem: https://xkcd.com/1200/
I don’t have any experience with snaps so this is all new to me. Snaps install software at a system level right? Why on earth would there be anything in a user home directory? What if you have multiple users? Does snap get confused?
Most likely they download some things when you first run the software. This pretty common but usually opaque to the user due to it being in .local or .cache.
Snap stores user-specific application data in /home/user/snap/ folder. Like when packaged application wants to write into $HOME, snap gives it some sub-folder inside /home/user/snap.
Ah ok I understand now. Sibling comments reference the MacOS Library and *NIX ~/.local approaches. Both of those seem to make a lot more sense. Is there a config for Snaps to store user data in a different path, like ~/.local/snap/?
No; they use some magic with security policies and mounts so $HOME/snap is hard coded. Some of the early comments in that "4 year old bug" linked here explain it.
Snaps run out of a squashfs partition, but the app may save app config in the user's home directory (if they request the HOME interface, I believe).
After fighting with node, vlc and ffmpeg snaps not working reliably, I had to add a warning for my PhotoStructure users on Ubuntu to avoid those packages (and how to install them via apt).
I agree with a bunch of people here: snap promises some great features, but in practice the horrible performance, additional resource consumption, and spotty reliability led to me actively avoiding snap packages and looking for an alternative installation.
>And now for a minor complaint that also feels most user hostile to me: why do the snap developers think its ok to require a non hidden directory in $HOME? Seriously my home directory is MINE, if you have to store application state there at least have the decency to do it in a hidden directory.
Unrelated to Snap, but on Windows, trying to use the My Documents folder for your actual documents is frustrating, because a huge number of apps and games like to use the folder for all sorts of nonsense, instead of using %appdata% like they're supposed to.
The problem in Windows' case is that there never was a clear specification regarding what kinds of files should go where. The directory structure and environment in every version of Windows is a little different, and it's hard to write an app (or an installer) that does the right thing on all of them.
I think the combination of complexity and obscurity of those two links reinforces my point more than it refutes it. There's a reason why basically no one gets this stuff 100% right, including some of Microsoft's own first-party applications.
I feel like in 2000 or before, My Documents was the "home" folder and you were supposed to put your own subdirectories inside of that. Might be wrong about that though.
The issue is that you have to continue "fixing" lots of individual utilities. In addition to your file manager and `ls`, what about tools like `fd`/`rg`/`ag` (requires adding `snap` to `~/.ignore` or `~/.gitignore`), `fzf` navigation in the terminal (may require updating `FZF_DEFAULT_COMMAND`), "open file" and "save file" dialogs in non-GNOME apps (like Zotero), and so on. The `snap` directory keeps popping up in new places, and discovering all the different ways to hide a non-dot-file is exhausting. In contrast, adding that initial dot to the `snap` directory would avoid the problem entirely.
I have still been using `snap` for the past year, and have mostly been happy with it. It works well for apps like `spotify` and `zotero`, it's a better solution than `ppa` for third-party software, and I like that it tries to introduce a permission model. But not following the dotfile convention is annoying, and not prioritizing a search-and-replace of `~/snap` to e.g. `~/.snap` in the code after four years is strange when this is their most upvoted bug.
dot prefixed files is a kludge that is now a standard rather than an actual hidden attribute like on Windows/NTFS.
The actual heritage is when `ls` was written to exclude .. (dot dot) directories from it's listing the code literally just had the logic to exclude any files which had a dot/period as its first character. Later operators exploited that bug/feature to create items with a dot prefix to make those files and folders hidden. Eventually this became convention.
Whereas systems released more recently understood the need to have a hidden file attribute so made it a first class property.
I do love POSIX and often the first to defend some of Linux or BSDs idiosyncrasies but if there was ever anything that was worth someone saying "I know we've always done it this way but it's shit and it's about time we implemented a proper solution", it would be the dot prefix kludge. (I also know it's easier said than done and would take years for all the tooling to catch up)
This would be nice if it was easy to toggle showing hidden files and hidden files wouldn't show up by default in all folder listings.
Of course you do have system files, which are hidden from all standard folder listings, but aren't usually used by software, presumably because they're too damn difficult to find again (although I really hope google drive realizes at some point that desktop.ini is supposed to be a system file, not merely hidden).
Does anybody know why lxd is shipped via snaps? It's kind of confusing, because it seems like snap should be built on top of lxd. If you're running a container inside of lxd inside of snap, does that mean it's two layers of sandboxing?
My understanding is that the actual features needed to provide containers are part of the Linux kernel. What LXD provides is tooling and a daemon running as root that are used to manage containers. There's no reason why these can't be part of a snap, it doesn't introduce another layer of sandboxing for the actual containers.
(That said, I would still prefer that they not be.)
> Snaps break debain's stable release model. They allow upstream to ship updates outside of the normal 6 month ubuntu releases.
In fairness, I think that's the point, just like RHEL streams.
> There are times when you might want this, but it should be opt in not mandatory. I thinking specifically of lxd which is only shipped via snaps.
Yeah, decent idea, poor execution. Especially for system/infrastructure software like LXD. I want a stable kernel, a stable glibc, a stable LXD/Docker/k8s/whatever, and then on top, bleeding-edge applications that will not break the world if they autoupdate at random to a less-tested version.
Packaging and maintaining microk8s is a significant effort to do with apt. You are asking if someone managed to do all the work to package microk8s and keep managing it as a deb package.
So I've used ubuntu (Xubuntu, xfce) for quite a while and would rather not deal with this, are there any distros that aim to be ubuntu but without snap?
Because hearing things like `sudo apt install chromium` actually aliases to using snap is disconcerting to say the least if true.
Pop!_Os is basically just Ubuntu but better. They will have flatpak integration with the store app with 20.04, but the official stance is to use the deb packages first, and then fall back to flatpak if there is no deb available.
I think Pop_Os is becoming the next Ubuntu. It's already captured a huge percentage of the gaming community. If you read r/linux_gaming a huge amount seem to be using it.
But I'd like to throw in a recommendation for Fedora. It includes Flatpak by default (which to me as always been the least objectionable sandboxing system) but nothing comes as a flatpak by default. You have to explicitly choose to use it.
Fedora's hardware support is second to none, and even supports in-OS BIOS updates.
tl;dr -> HashiCorp's various tools exist as snaps but none are published by HashiCorp. All are out of date. Some have incorrect metadata. Few provide any clue as to who or where the upstream is. There's usually not even a way to contact the snap author to submit patches or ask for an upstream link. eg https://snapcraft.io/nomad
Yep, it's a massive smell. When I looked at installing a snap I wanted to audit the build script but I couldn't find that anywhere. That's a big NO from me.
I wanted to like snaps (and flatpaks before then), because trying to ease packaging and deployment of apps on Linux is a noble goal, but in both cases I eventually gave up on non-trivial use of them because they were always broken in some annoying way because of their sandboxing.
The latest snap I had to get rid of was Visual Studio Code, because I was trying to work on an open source game with it, and I found out that if I launched the game from inside Visual Studio Code, my game wouldn't play sounds because it couldn't communicate with PulseAudio, and attempting to use ALSA just straight up gave me an error.
On the other hand, I've only had positive experiences with AppImage. Gives you an all-in-one image that you can directly execute if you like, and no sandboxing nonsense.
AppImages are definitely the best, I just wish they had an easier way to integrate with the system. I know about appimaged, but I had problems settings it up, and it's just not as easy as integrating Flathub into Discover, or getting your packages from the CLI by accessing your distro's repositories.
It used to work, with the latest update audio doesn't work anymore in Chromium (although it does see the device), I'll have to report a bug. (snap connections does show audio-record connected)
AppImages are a disaster waiting to happen. They are like Windows MSI installation files just downloaded from somewhere, running without any confinement.
Sounds like a perfect addition to a -- preferable, but sometimes too heavyweight -- repository-based solution like apt. Basically a more powerful binary tarball.
I realize I have to soon upgrade from Ubuntu 16.04, so a while ago I installed 19.10 to see what to roughly expect from 20.04, as there are quite a few changes. Trying things out, I installed VS Code from the Ubuntu Store; I was quite disappointed to see things going south right on the Welcome page, as the snap version of vscode couldn't even open a web browser (instead, Firefox promptly crashed every time).
Of course, being able to open a web browser from VS Code isn't a necessity, but for some reason for me it just seemed like the install was rather broken by default, and surely almost no one could have used it much not to notice a simple thing like that right away – and the thought that even if the problem was noticed and simply shrugged at didn't really make me want to see what else did not work.
Gnome-Builder, the official Gnome IDE, builds flatpaks. I'm not sure how good it works, but idea is that one should imagine this brave new world of Linux sandboxed apps similarly how IDEs could work on smartphones. In the end the IDE must be either blessed with special powers or it must build packages for the sandboxing system. Gnome-Builder seems to take the latter direction.
I had run it via X11Forwarding (I had a contusion and used a puny laptop to connect to my desktop) and it was not a smooth ride, so it's not an entirely representative experience, but it shows that it's not all painless, yet.
Canonical always has tried to differentiate themselves, and they just can't execute. Remember Unity, Mir, Juju, upstart and all the other failed shit they've come out with? Snap is just more of the same. I don't want to run that garbage on my desktop. I don't need more daemons and forced auto-updates and all the baggage.
I strongly recommend anyone similarly frustrated to check out debian, which is a fantastic distro. Thanks to Kevin for posting this, but if you're using Ubuntu and disabling snap, you're fighting against the current and I have to imagine it's going to be increasingly difficult with subsequent releases.
That’s a bit rich: are they not the #1 consumer distro, which hardly implies they are failing to execute. A successful product has missteps, so what.
> I don't want to run that garbage on my desktop.
So don’t. Why complain that others do? I use Ubuntu because it works and I can mostly find information about how to do what I want. There are major aspects of Ubuntu I don’t like (Gnome, Snap) but selecting a distro is all about choosing your compromises. I have tried Debian and other distros, but I tend to go back to Ubuntu because it works best for me.
> That’s a bit rich: are they not the #1 consumer distro, which hardly implies they are failing to execute
All the hard work to make it a viable OS is done by Debian. Canonical just adds some polish and then wrecks it all with poor design decisions over and over again.
Because it's popular it gets 3rd party support. So people use it making it popular. Vicious/virtuous circle depending on whether you're looking at it from above or below.
Just like windows Shuttleworth admires and seeks emulate so very much.
It's called a network externality. Microsoft achieved this with piracy based market penetration of dos and it worked great for them and they've built on it ever since.
Shuttleworth understood the importance of getting established as being popular when he launched and would press install disks, as many as you asked for, and ship them to you at his own cost. As one example of nakedly going after market share and spending resource to do so.
Bug #1 in the ubu bug tracker is literally "windows is the most popular os."
Separate to the marketing, which is worth discussing on this site because some of us actually care about what works and why so wish to discuss it, let's talk engineering decisions.
Between 2 choices that are technically about equal. Choose the one that is more popular. Many feet trample more bugs. Better support. More likely to be around after $time_period. If it needs to work with something else, the managers of the something else project will likely suppor the more popular first etc. Obviously popularity is not the only concern but it really does count for something, ignore it as a dimension in your decision process at your peril. I use linux, and ubuntu as it happens on this laptop. I'm aware windows and osx are more popular and that popularity makes certain things easier. For /my/ purposes and to /my/ taste linux and ubuntu are worth paying that cost to have installed here and I'm very comfortable with that decision.
Just quietly, perhaps people who don't care for business decisions and engineering decisions are on the wrong website? There's plenty of places "boosters" can go to do that.
Ubuntu has been marketed as a beginner friendly distro, with communities easily accessible using a Google search (thinking about the likes of askubuntu, omgubuntu, ...). So I'd say online presence and beginner-friendliness.
Similarly, Mint is also one of the most popular distros, and its marketing, at least for a long time, has been that it's even more user-friendly than Ubuntu.
Debian has its own set of problems. Like the Chromium package maintainer deciding unilaterally several years ago that installing extensions remotely shouldn't be allowed and gated that standard functionality behind a command ling flag.
There was zero documentation on the change and the error you received attempting to install an extension was basically "operation failed". I discovered the cause only because there was an open bug about it on the Debian bug tracker where the maintainer refused to acknowledge the problem. Eventually, sane minds prevailed and that stupid patch was reverted.
So, unfortunately - you'll end up having to deal with people that refuse to look at things from the user's perspective no matter what distro you use.
There is also the ffmpeg kerfuffle a few years back when Debian decided to replace the ffmpeg package with an incompatible and inferior fork. You can imagine the amount of confusion that ensued.
That said, I think Debian's occasional messups are far less egregious and damaging than Ubuntu's though.
There was also that time many, many years ago they decided to remove the ability to load binary firmware blobs for things like network cards in the kernel because of an interesting interpretation of the GPL. :-/
Maybe when they tought that none-free drivers opt-in was a good idea, also old kernel / packages.
LTS on Ubuntu was always better than Debian, I mean saying that Ubuntu is just a repackage of Debian is very short sighted, especially on the security side, Canonical security team is top notch.
Canonical is at a disadvantage here because Red Hat directly employs or has significant established relationships with many of the people who make kernel release decisions. Plus, RHEL is the de facto standard enterprise distribution, which means any decision the kernel community makes regarding what they believe "enterprise" requires will often be a reflection of Red Hat's plans.
But what benefits Red Hat in the enterprise world is to their detriment in the consumer world. There's a reason the Debian/Ubuntu package ecosystem is richer and more featureful than RPM, and this is why Ubuntu dominates in the container space--because almost any piece of software that one could expect to have been packaged has been packaged as a .deb and already exists in the default package archives. I can't count the number of times I couldn't find an RPM--certainly not in the default repositories (RHEL, CentOS, or even Fedora), but not even in the third-party community repositories. And those that do exist are of lesser quality than the comparable .deb, for various reasons. (That is, the long-tail of packages is of higher quality for Debian.)
By pushing Snap, Canonical is definitely going astray. Ubuntu's competitive advantage is the Debian package ecosystem. Both Canonical and Red Hat seem to underestimate the role and importance of their respective packaging ecosystems. How many projects to revolutionize or replace RPM/Yum/whatever at Red Hat have crashed and burned? Many, though it's hard to count because half-way through they often realize what they're trying to do is functionally or even technically impossible (as with their aborted 2017 plans for RPM package streams), and scale things back to iterative improvements.
Containers are a security nightmare, and pretty much the only reason to pay Canonical and Red Hat licensing fees is for security and bug fix maintenance of their package archives. On our large Kubernetes clusters at work there are thousands of open CVEs for the containers that are being run, and we'll have to boil the oceans to get them all updated, let alone keep them updated. But updating packages is as simple as an apt-get/yum upgrade[1], and rarely do you have to worry about anything breaking, especially relative to the pain that updating containers regularly brings.
[1] If the container uses Ubuntu, Red Hat, etc you can sometimes just rebuild the container to get the newer packages. But that assumes you control the container image. Most containers come from third-party, decentralized sources (that's the point!). But Docker Hub doesn't cajole and coordinate container owners to update their crappy images. It's no substitute for the orchestration of people that are traditional package repositories.
Did a large numbers of people use those? Legitimate question—it always struck me as a cool initiative for a very small number of people, but only that.
I'd expect most people tech-savvy enough to install Ubuntu would also have a decent enough internet to download a ~700mb file.
Back in the day, not much of my country, or even the US, had particularly fast internet. Nor did everybody have a disc burner in the days before USB booting being supported by the majority of computers' firmware.
If my memory serves correctly, this was 2004/2005, around the time I was discovering my home burnt CDs and DVDs were going bad.
This was also around the time I would often brick my primary (only) workstation for whatever reason. Having a properly mastered Live CD was super useful.
I would order at least two with every release cycle for a few years at least.
Thankfully, I saw the light early with Ubuntu-server, and stayed with Debian. Ubuntu-desktop makes for a good enough live / recovery / troubleshooting environment, but not sure I’d use it for anything more.
The free LiveCDs were great marketing. As a teenage computer geek, it was way easier to convince casual computer users to try it out when I could lend them a nicely printed CD. And it looked way better than handing them a sketchy CD-R with some marker scribbles on it.
> All the hard work to make it a viable OS is done by Debian
You could equally say that all the hard work to make a viable OS is done by Linux, so screw Debian? Last I hurd, the GNU developed OS is unviable (no 64 bit, no SMP).
Or equally say that all the hard work to make the majority of end-user programs (you know, the raison d’être for an OS) is done by other open source projects, not Debian, so screw Debian...
These are open source projects, with cross-pollination everywhere, each with their own opinions on licensing. Ubuntu mostly helps the ecosystem, and certainly isn’t a parasitic player (although like all, they are not perfect).
Why bag on Ubuntu just because it happens to be popular? Should we also cancel all the other Debian based distros?
PS: complaining about upstart shows you are just being biased (or perhaps misinformed). Canonical were developing upstart before systemd was developed - and systemd was developed by RedHat. The main con given against upstart was not technical, but due to licensing. “In terms of overall feature[s] there is really rather little to distinguish upstart from systemd” https://wiki.debian.org/Debate/initsystem/upstart
> You could equally say that all the hard work to make a viable OS is done by Linux, so screw Debian?
No, you couldn't say that. Without toolchains, userlands, and packaging, a kernel is pretty worthless. The barest bones you can go is still gcc, linux, uclibc, and busybox. There is more code that goes into a computer running linux, then there is in the linux kernel. By a wide margin.
If it had to be done, GNU programs could all be replaced. Port BSD tools or improve busybox tools, use KDE instead of Gnome, and there is a variety of great packaging solutions that aren’t .deb. AFAIK GCC is already being replaced by clang due to the GCC codebase, amongst other reasons. Distros mostly use GNU programs for historical convenience. Given incentive, GNU could be dropped by Ubuntu for the desktop. The most popular Linux distro Android has moved away from GNU already.
FSF does fabulous work, which we are all appreciative of, but some decisions are peeing in the open source pool.
I think RMS creates unnecessary division against Linux and Linus for what I feel are poor reasons. I went to a lecture by him where he spent half his time being negative towards Linux and Linus (that felt like he was just pissed off because Linux was popular) and a bit because Linus had used the GPL2 (not trivial to change, and you don’t get change by attack). Being negative towards the people who are on your own side is wrong IMHO. It could equally be argued that Debian should be called Debian/Linux. Edit: I just found a quote from Linus about RMS that summarises what I wished to say here: “It's not passion for something, it becomes passion against something else.“ - http://torvalds-family.blogspot.com/2008/11/black-and-white....
PS: I totally admire RMS and his relentless idealism. He has given so much to the world, and the faults I see in him are interwoven with the strengths I see: I’m not sure the faults could be mitigated without badly weakening the virtues.
Sorry, you are quite correct about both. I jumped to a conclusion about GNOME because I did do a quick check and saw the “G” stood for GNU, but I didn’t check more deeply. I have no excuse for confusing Debian with GNU/FSF, and the comments will stand to remind me of my shame.
Those people can choose another DE with legacy features like desktop icons. Tradition isn't a reason to keep up bad habits and I'm thankful to Gnome for daring to take tough decisions for the greater good.
I wouldn't use any other DE, at this point.KDE has always been cluttered and XFCE is buggy and not particularly intuitive.
They're not "legacy features" merely because your tastes have changed. They're still just "features." Calling them mean names doesn't change that, it just makes it harder to take your argument in good faith -- same as calling desktop icons "bad habits." I'm a happy GNOME user but ascribing moral judgements to common computer functionality is kind of weird.
GNOME is great as long as you use it the way that GNOME devs want you to (this year). If you want extensions, themes, customization, to use software the way it worked last year, or tray icons, it becomes... less supported.
I tried it recently and went back to i3. For me, Gnome didn't work well for multi-monitor setups and seems surprisingly lacking in customisations. It did seem very polished though.
Most of HN is shitting on popular things with a hot take and a smug condescending tone, usually erroneously. If Conical hadn’t tried new projects and failed, the poster would complain that they never innovate.
People complain like this because they have no real control of their own lives. It makes them feel smart, if only they were in control, then things would be better. It would be so easy, the people in charge must be stupid. It comes from a lack of experience and the inability to understand the challenges in those positions.
The shortcomings of snap are well documented. I assumed anyone reading the comments would have been aware of them. But apparently some people will jump on any chance to virtue-signal.
Yep this hits the nail on the head. There was some kind of fundamental shift around that time. Running other GUIs has been a bandaid, but the underlying thought processes that led to unity are still clearly at work. Im going to stop even trying out new ubuntu releases anymore.
I think this is ok though. If ubuntu were better thought out, the linux ecosystem might be less vibrant than it is. I would like to think other distros are learning from these failures. Personally ive had excellent luck with scientific linux (CentOs based).
Unity was very good in a lot of respects. Both its UI elements and its performance. Unfortunately, Unity 7 depended on Compiz somewhat heavily, and when it came to writing a replacement of the full stack, Canonical didn't manage to execute.
But have you been following last year's improvements to GNOME's performance and responsiveness? A lot of it is Canonical's devs bringing their experience from Unity.
Gnome 3 runs like an absolute dog on my Skylake notebook using Ubuntu 19.10. I don't know what metrics you have been looking at, but as a regular user I "feel" that the UI is constantly lagging during regular use. I didn't think it was this bad when I was using Fedora in the past, but that was a wayland based installation.
Enabling the BFQ scheduler reportedly boosted the responsiveness https://bugzilla.redhat.com/show_bug.cgi?id=1738828 and I can't remember where I saw someone saying it had a positive impact on Gnome in particular.
Weird. I'm on a ThinkPad x230 Ivy Bridge and Gnome (3.36) is butter smooth for me (Ubuntu 20.04, fresh install). I did the minimal installation though.
it's not a fair comparison, but for many years i have been running i3wm+dmenu+xterm as my desktop environment (and dwm instead of i3wm before that), and not even once i had given as much as a thought about performance of that. it just responds to my commands... instantaneously?
there is no need for latency-hiding animations and subsequently trying to make them run smoothly on the gpu if there's no perceptible latency.
> Unity was very good in a lot of respects. Both its UI elements and its performance.
I hear a lot of praise for Unity and I'm the kind of person who enjoy trying out new stuff and Linux Desktops is no exception.
For me, Unity was broken because of alt-tab (behavior and lack of configurability).
It might work for everyone else but when I want to switch back to the last or second last thing I worked with I want that done now.
I don't want to look at the tab switcher to ponder what to do next, just alt-tab, done.
This has worked consistently in every Windows since at least 3.1 (the first my family owned), and in every Linux desktop environment I've used except Unity and Gnome 3. And in Gnome 3 it was at least configurable.
This might seem trivial to a lot of you but to keep focus I keep one application maximized most of the time. I don't use them side by side. Then when I need to reference something (Jira, vendor documentation etc) I alt-tab. Same goes for slack.
> I strongly recommend anyone similarly frustrated to check out debian, which is a fantastic distro.
It is true that the Debian people are doing a great job.
> [...] if you're using Ubuntu and disabling snap, you're fighting against the current and I have to imagine it's going to be increasingly difficult with subsequent releases.
Actually, snap was harder to remove in the previous release: you had to rebuild certain packages (actually, just pulseaudio, so it only matters for desktops) to get rid of the dependency, but it seems now that it's just a couple of apt commands, so you have to give Canonical credits for making it easier.
Any of these packages is going to pull snapd in if installed. Soon after writing the above comment, I decided to install chromium, and ... snapd got installed as well as a result. I guess I should double check each claim I am about to make, BEFORE making it.
sigh...
Edit: Please note that many of these are "leaf" packages, by which I mean that no other packages depend on them.
I recently hit the wall with Ubuntu too. I'll still run -server in the cloud, but each time over the last 5-7 years I did point-samples of "is Linux viable as a desktop other than ChromeOS", it was always Ubuntu/Gnome. It turns out that that was my problem all along!
I tossed Gentoo and KDE (this is not a Gentoo endorsement, it was just a "hey I wonder what Gentoo's been up to in the last dozen years since I last used it") on a spare laptop. It turns out that KDE is amazing now. It's seriously the best DE I've ever used, and I'm a Mac user! (Half of the utilities I install out of the box on a fresh macOS are built in, and the annoying stuff that used to be editing arcane files is now easy preference settings. It's actually great.)
What the hell are Ubuntu doing shipping Gnome (with the ugliest custom theme known to man, to boot)? Admittedly it was my own ignorance, for which they are not responsible, but their mindshare and bad choice tainted my whole view of the state of the art for a long time.
It's interesting how underrepresented KDE is in the "big distros". While it makes sense that Fedora and Ubuntu ship GNOME, and there are "spins" of each that include different desktops out of the box, it still surprises me.
>[...] To show our commitment to this dual licensing model, the KDE Free Qt Foundation was founded in 1998. It is a non-profit foundation ensuring that Qt will always be available under open source licensing terms. The agreement that governs this foundation has stayed mainly unchanged over the last 17 years. As a lot of things have changed during these years, we have been working with KDE over the last year to create a new and updated agreement that takes todays realities better into account.[...]
In my opinion KDE has always been way less polished than gnome and is currently not financially backed in any meaningful way. They also have problems focusing on the core product and won't stop shipping half-assed programs nobody asked for.
> Half of the utilities I install out of the box on a fresh macOS are built in, and the annoying stuff that used to be editing arcane files is now easy preference settings
That's been the case with KDE for 15-20 years now. KDE 3.5 was a great environment (and Trinity (TDE) is a modernized fork of it).
Note that, this year, KDE added telemetry to their Plasma desktop environment. Of course, it's opt-in, so it must be acceptable, right? Well, of course, users who objected to the telemetry found bugs that caused data to be recorded even when disabled.
KDE's response was to ban said users from reddit.com/r/kde and call them "paranoid schizos." (The mods there are KDE members wearing "KDE developer" flair, not random Redditors.)
So, despite using and recommending KDE for almost 2 decades, it's hard for me to do so any longer. I wholeheartedly recommend checking out TDE instead.
Thanks for letting me know. It looks like the telemetry (kuserfeedback) isn’t even a dep of the Gentoo plasma-meta metapackage, so I don’t think it was even built on my system (but will double check when not on mobile).
If I dabble with debian or kubuntu I will make sure to mitigate it, thank you for making it known, keep up this kind of good work!
It’s a real shame that they found it necessary to even build a telemetry client. I switched to free software after years on macOS (I remember upgrading to System 7) because of all the phone-home that Catalina STILL does even with iCloud, Siri, analytics/crashes, Screen Time, iMessage/FaceTime, Location Services, ntp, App Store, and software update all disabled.
iOS apps in the App Store are all allowed to phone-home like mad, too, and Apple permits this on the basis of you “opting in” to it in the App Store TOS, as if we have any sort of choice on iPhones. It’s totally endemic, and entirely undermines the credibility of Apple’s claims to caring about user privacy.
Seems like spying on users is getting heavily normalized these days. :(
> all the phone-home that Catalina STILL does even with iCloud, Siri, analytics/crashes, Screen Time, iMessage/FaceTime, Location Services, ntp, App Store, and software update all disabled.
I have a bunch of Little Snitch screenshots around here somewhere, but it is easy to reproduce: do a fresh install on spare machine or VM (opt out of all services like iCloud, Siri, Location, MAS, et c), install Little Snitch, and then disable the built-in Little Snitch silent allow rules for “system services/iCloud” or whatever it’s called. Reboot and observe.
The recording is local, on the hard disk. I think people are worried that by producing the files, there is just one layer of bug (accidental upload) keeping them private.
I agree. The data should not even be generated if the analytics are not opted-in-to.
I do give them credit for making the system opt-in. They deserve that.
Not really. I wasn't aware of this. The only thing I found on reddit regarding the situation was the link I sent above which didn't have any controversy.
I put arch/gnome on a system right next to an ubuntu box.
It was like a different gnome - quickly reaching the desktop and lots of nice differences (like the privacy menu wasn't crafted by marketing and legal)
Unity was a good DE, and I have come to appreciate their design, which even today differentiates from standard GNOME. Also recall that it was made to be one DE for all: Phone, tablet, desktop. The idea was that you would have an Ubuntu phone, dock it, and use it as your PC!
And that is doable now, considering Thunderbolt. Hell, Oneplus should try to push OxygenOS to be tablet-like and this would set them apart from everyone.
Upstart was started alongside or even before systemd, if I recall correctly.
The one I'm currently fighting server-side is netplan. I want to use systemd-networkd directly, since it exposes a lot more features than netplan, but getting netplan to stop intervening is a ballache. Like, it's not a systemd service, it has to be disabled on the kernel command line?!
I've found that if you delete /etc/netplan (just making sure this is at least empty seems to be the most important part) and /var/run/systemd/network netplan doesn't really seem to do anything. My org has been using systemd-networkd directly after doing that for about a year and it's working fine for us.
Yes I've done that and it definitely works, though I've still got "netcfg/do_not_use_netplan=true" in my cmdline for good measure, not sure if it does anything though, or even when I got that from, come to think of it.
But still, emptying a directory is not how I expect to disable what is a system service. It should be systemctl disable netplan...
I think emptying would be better than deleting the directory since it'll probably just get recreated on an update.
It's because netplan uses a system generator /lib/systemd/system-generators/netplan, to parse the files in /etc/netplan and generate systemd-networkd configs from them on boot (Like how /etc/fstab gets parse into systemd mount units). It would be nice if there was a flag file or something you could touch to disable it though.
Yeah I was trying to get systemd-networkd to handle hotplugging, and I spent about a day trying to figure out how to describe a computer with one Ethernet port to netplan before giving up and removing the whole package. At which point systemd-networkd started working beautifully as-expected. For a system administration tool netplan is wonderful at making the simple things needlessly complicated.
Unity had a rough start, but grew to be a pretty nice DE. I actually remember it warmly every time I see how Gnome3 eats 3 horizontal bars of screen space, placing a freaking WATCH on the center of the top bar.
Seriously, a whole bar for a WATCH? How come good old Gnome2 did it better 15 years ago, and had a terrific hierarchical menu, to add?
I recommend Debian too, but potential switchers should be aware that it has a very particular update model. You get (non-security!) software updates once every two years, and that is the version you will be on for the next two years. There are sometimes workarounds (namely backports), but they're less well tested and sometimes break.
I think this model is underrated, for all that it can sometimes be annoying. Consistency is valuable. Constant change is not good, even when the changes themselves are positive. But it does mean you'll sometimes be left with out-of-date software.
Edit: Oh, I should mention that you can also use Debian testing to get frequent updates. Primary issue here there is Debian Testing actually gets security updates later than Debian Stable.
I despise the bug, it causes so much trouble without a way to turn it off. Plus the switch to snap happened exactly during a critical vuln which meant people were running on critically vulnerable chromium for weeks.
Except that chromium under snaps is pretty unusable unless your home directory is structured exactly the magic way Canonical expects, if you have symbolic links, stuff on other disks, suddenly you can't upload your customer orders, or your PCB CAD designs to be made, you can't save files into /tmp anymore, even if you've been doing that for 3 decades. And it all fails silently, mysteriously, no error messages explaining why stuff has suddenly stopped working.
I'm not against stuff changing, but tell us up front, explain what's changed and make sure that you're not breaking existing things or provide a way for people to keep their existing stuff work, a flag that says that following symbolic links is OK ... and put that UI in Chromium itself, not in some other box somewhere
In looking at some of the other entries about 20.04 on Mr. Custer’s site I’m wondering if it would’ve been simpler to just start with mini.iso to make an actual barebones installation and then install only what is actually desired. If you truly want a lean install then building your own custom mix is possible in Ubuntu and a relatively blank slate is available.
You'd be surprised. Whenever my helm snap updates it breaks all the authentication I previously set up. And I get a weird error. That's not me needing fine grained control. It's just snaps being awful.
You can have pretty much the same with the tar.gz package, just unpack at a location, execute the setup to create the desktop file and some symlinks and you're set, plus you're notified upon a new update, no need to use Snap for that.
JetBrains has their own tool called 'Toolbox' to install and update their software (and Android Studio). With Toolbox you are in control when and what to update and you can install multiple versions at the same time.
It's distributed as AppImage for Linux. Very much recommended.
> I lean more toward Flatpak as it is more performant
What is "performant" supposed to mean here?
Is Flatpak faster than Snap? more compact? simpler? more reliable/secure? easier to use? more efficient in terms of cpu/memory/communication/power/etc.? all of the above?
I always had problems with both of them. I use Docker a lot and Flatpak/Snap are intended to be a type of Docker for desktop apps. I know with Flatpak it has some shims to integrate with your system UI libraries so themes try to match up, but there are issues with that too (and flatpak apps just not starting up half the time).
I really hate Snap/Flatpak conceptually. Use the package manager. That's what it's there for. FPM is a way to make package building easier.
Snap/Flat tools feel like they're about the same as Electron cancer; and I bet we'll see more closed source commercial stuff pushed to the Linux world via them as well.
Flatpak is marketed as a better Snap (it surely has some advantages: no vendor lockdown), but at the end of the day, the system integration is not that good, I tried to use the Flatpak of Wireshark back in the day when I tried Fedora Silverblue, I ended up regretting that experiment.
can you elaborate? I can google for "docker sucks" blogposts, but I trust the HN opinion to be a bit more thoughtful. Any specific pain points you can identify?
The most commonly mentioned flaw was/is the root daemon. That can be worked around with other tools. The command line and docker files are a bit clumsy as well. Many images have security flaws. It didn’t clean up after itself for a looong time, etc.
It doesn’t “suck,” and many of the ideas are compelling. But, the design and implementations could be better. I was interested in rkt until it was acqui-abandoned.
Desktop apps are not designed to operate in isolated fs namespace/network/etc from the host. So the user experience won't be seamless unless there are standards that enable desktop apps to be aware of how they are dockerized. Which there aren't afaik
Consider any other operating systems out there for a moment. A new upgrade comes along that contains unwanted features. How often is it possible to revert that by uninstalling a few packages?
There is a level of care here which I think is great. Some engineer somewhere made sure that the system would still work without snaps. This is a very Debian attitude which Ubuntu inherits from and which I would like to celebrate for a bit :-)
Have you ever tried Void? I've used it on my routers for years, had a media PC with it and recently setup my dedicated server with it. It's really nice, but it is certainly more hands on and missing the management layers found in other Linux distros.
The issue I had with snap was my server was going down. I thought it had run out of disk space like the last few times, but it seemed to be out of memory. Then I looked in htop and something related to snap or lxc was using most of the RAM. I think this is Ubuntu 18. Don't remember what I installed that used snap. But I had to remove snap to prevent my server from running out of memory periodically making my program crash.
One of the very annoying consequences of the Chromium move to snap on 20.04 is that it will silently fail to launch most external links (e.g. Slack, Zoom).
It basically breaks xdg-open. This is crucial for a lot of flows with desktop software and I'm honestly baffled why it isn't fixed. Any URI with a custom scheme is horribly and completely broken with a browser installed as a snap. Even basic stuff like file uris are broken in browsers installed as a snap.
It's extremely weird to see this kind of thing when it happens too, you usually trust Firefox to work!
436 comments
[ 3.2 ms ] story [ 274 ms ] threadOnly Canonical can run a store. Once you install something, Canonical decides, when packages on your computers will upgrade. Wrt control, it goes way beyond Apple store/Google Play/Microsoft Store.
No thanks. Flatpak can preserve the benefits of decentralized repositories and upgrade under user control, with all the ease of packaging and sandboxing of the new toys.
It seems like they also often end up going back to the community solutions/standards eventually, so what benefit do they see in doing this over and over again?
The sandboxing part was spun off to the bubblewrap project, which has been adopted by the community for other purposes, such as Gnome's Epiphany browser.
https://github.com/containers/bubblewrap
https://blogs.gnome.org/mcatanzaro/2020/03/11/epiphany-3-36-...
SnapCraft on the other hand is a project that requires copyright assignment to Canonical Ltd for contributions, which presumably has the intended effects of keeping non-Canonical contributions close to zero.
https://github.com/snapcore/snapd/blob/master/CONTRIBUTING.m...
https://blogs.gnome.org/alexl/2018/06/20/flatpak-a-history/
AppImage only solves the easy part of the generic-linux-app problem, namely running the packaged appimage; it does nothing to solve the hard parts: how do you build the application so that it will actually run on generic Linux distributions, and sandboxing.
> If you’re a Fedora user and you want to install Spotify, you’re told to go to https://snapcraft.io/spotify. Spotify doesn’t distribute RPM packages, appimage, Flatpak or anything useful to a Fedora user who wants to download it, or to a Fedora maintainer who wants to add it to a repository. Fedora users are told to go to what is essentially a commercial store operated by a RedHat competitor where stats tell them their distribution is only 7th best.
> We’re in luck, we can still download the .deb. If Spotify stops caring, what do we do? We move to snap because we have to? Will the snap store continue to let people download actual .snap files in the future or will that get locked down ? Will the snap store continue to operate without an Ubuntu One account or will we get vendor-locked ?
https://blog.linuxmint.com/?p=3766
Canonical provides the tools and several companies are providing their software as snap packages.
Another example is JetBrains that provide all their development environments as snap packages.
It seems that canonical does best when they embrace the ecosystem and not try to replace it.
Canonical cannot be accused of NIH for Upstart, it was a widely adopted clean init system at the time and made many distro's boot times great again. Service configuration files were also very easy and clean.
Unity was a desktop environment that both was liked by many people and reused many components from Gnome, I don't really see a problem here.
A point could be made for Mir.
So it's wrong to say Canonical is guilty of NIH-syndrome with these two items, when their versions were out first.
Whether the tech is any good is another matter.
https://blogs.gnome.org/alexl/2018/06/20/flatpak-a-history/
According to https://en.wikipedia.org/wiki/Snappy_(package_manager), Snap was publicly revealed on 9 December 2014, whereas the design of xdg-app (FlatPak's old name) was already discussed publicly at GUADEC 2013.
https://www.superlectures.com/guadec2013/sandboxed-applicati...
While I don't like the tech, the real reason Snap pushes me away from Ubuntu is the fear of this future where the app store dream turned out to be a failure again. What happens to the distro then?
/var/snap is a subvolume. Purging snapd wants to remove the /var/snap directory, but it being mounted subvolume, it will fail. Purging snapd will therefore also fail.
Destroy (-r) the /var/snap subvolume before apt purge snapd.
Similarly, if using flatpak, create a new subvolume for /var/lib/flatpak before installing the first one. You don't need to snapshot your flatpaks together with the /.
Since 16.04, Snaps have been a huge pain for me with running LXC in production environments.
By default, Snap applies updates and restarts Systemd services anytime it likes, and there's no way to turn this behavior off! The only way to get around it is to download the Snap package binary and install that directly. Then Snap won't "know" where to get updates.
(Caveat emptor: "Workarounds" like this can easily lead to a bad security scenario, since any critical security patches won't be installed by any standard system update process)
Did I mention that a fair percentage of the time the Snap updates would leave LXC in a completely broken state? In production (and development, too)!
The final nail in the coffin in this scenario comes in the form of Snap being the official recommended way to install LXC. I don't know if Stéphane and friends even publish Debian packages anymore.
I get the idea behind snap and appreciate it, but the lack of configurability and no clear definition of what stable really even means . . .
Even if people should be updating regularly, forcing them feels completely antithetical to the Linux ethos of users having control over their devices.
Ubuntu users may be more tech proficient than average users but even for developer machines, I think it takes a lot of concern out of the equation if the software is up-to-date.
As far as I'm concerned this doesn't deserve an '/s'.
With Ubuntu I just wait until the next LTS.
Since 2017: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053
I am on the rolling releases already but I'm not going to install an LTS version that is so deeply integrated with the distributor while at the same time ignores the directory standards so incredible blatantly.
I'll also admit that I can't for the life of me get Arch to properly install with all the tools and features that are normally built-in to desktop environments to work on first boot. I'm sure I can make it work if I give it another try now that I've gotten more used to using Manjaro, but the Arch installation experience is not something I want to go through again any time soon.
I understand that most Arch users will want to decide exactly how they set up their system and all, but for my personal (non-work) machine I just want an operating system that works, allows me to mess with the standard Linux stuff and manages to install itself without me holding its hand. I'd much rather tick a box that says "enable full disk encryption" than manually configure cryptsetup and LUKS parameters. It's just too much effort for what I get out of it.
I think the (not that bad) manual installation process might keep some folks from installing it, but it makes you learn to choose from the very beginning.
After the initial install, update it on your schedule, and install things as you decide they are needed.
Ubuntu is the opposite -- install the world, then go madly trying to disable and remove the phone-home, forced-update, bloat.
(see pages of stuff you don't need running)I feel bad for the maintainers; it must be difficult to deal with all the rude and borderline disrespectful comments -- and particularly for something you're donating your time for free after all. But I must say that the architectural decision of creating a ~/snap was a colossal mistake.
It's not an argument. It's freeness is a completely irrelevant property.
I really have no idea what people are thinking sometimes.
The automatic startup of newly installed services (before you even have the opportunity to configure them) on Debian (and derivatives) has always bothered me and is a (small) factor in my decision.
Fortunately, there are a few "workarounds" to prevent newly installed services from being automatically started!
First, there's the brute-force / heavy-handed approach -- override the systemd presets [0] to set all services to disabled by default:
Alternatively, as a one-time thing, you can "mask" the service before installing the package but this requires you to manually create the symlink (instead of using "systemctl mask") -- and requires you to know the name of the service unit beforehand: Finally, there's the old, "sloppy" (IMO) method of "hacking" the /usr/sbin/policy-rc.d script to immediately exit with a status code of 101 ("action forbidden") [1].(I'd recommend avoiding the latter entirely and going with whichever of the first two options better suits your needs.)
---
EDIT: Just remembered another method but I'm not sure if it still works:
---[0]: https://www.freedesktop.org/software/systemd/man/systemd.pre...
[1]: https://people.debian.org/~hmh/invokerc.d-policyrc.d-specifi...
A cultural acceptance of WIP software seems common, in free software communities, in my experience.
On the one hand, yeah it's harder to complain when something is only built in someone's spare time for free. On the other hand... is non-FOSS really any better? Has Windows yet managed to re-merge the old and new control panels?
The first is a fact of life. The second is bad judgement.
Due to LXC now being a snap, the file is simply not there. I guess it's 5 layers deep in namespaces, overlayfs and other stuff. I was so fed up with this that I removed Ubuntu (and replaced it with Gentoo).
I can't understand why they would break such fundamental thing and seemingly don't care about it.
I don't know how must be installed on your version, but on 19.10, snap can be completely removed: the only draw back is that pulseaudio depends on it, but I guess that for a server it's not that much of a problem.
Dear snap developers, don’t make false assumptions that every user in Linux has to have home directory as /home/username just because standard Ubuntu installer does this. Only thing that you should care about here is $HOME
I uninstalled it on all my Ubuntu systems and put it on hold. No new Ubuntu installs, switched to Debian.
I think I am going to have to start figuring out a plan to migrate them all over to RHEL...
1. prevent machines in the fleet from pulling the broken LXD update
2. rollback broken machines to the previously working LXD version on the same channel, since it no longer existed in the Snap Store™.
What a joke! Now we're burnt on snap _and_ LXD.
Some developers are trying to package for Debian. The work is in progress at https://wiki.debian.org/LXD
The following distributions package LXD (that I know of):
* Void Linux
* Alpine Linux
* Arch Linux
* Gentoo
Some of those are more suitable for production installs than others, but if you know what you are doing and manage your deployments well, all of them could work.
I've been looking into .deb packaging for Caddy but it really feels like they require us to jump through too many hoops to make it happen. I'd much rather just ship a prebuilt binary.
Security. Dynamically linking stuff is always going to be better than statically linking. Do you trust upstream to keep track of security issues and rebuild in the absurd dependency tree that is Golang software? Or the multi-year old effort which is the current Debian security team?
The reason why it's absurdly complicated is solely on the Golang team, not Debian.
It's clearly not production stuff, but it works very well for a quick test bed before production deployments.
(Same-but-different for enforcing non-interactive mode on installs.)
The idea with LTS is to be predictable and stable.
Put another way:
- desktop people want ALL UPDATES NOW.
- server people want NOTHING TO CHANGE EVER.
(yes, not exactly that, but kind of)
I actually really like snaps and that's the only bad experience I've had. I don't know why LXC would come in that form, very weird.
It is a seriously difficult thing to get right. I always applaud people to take on difficult problems and try to solve them, but I would not expect it to have any sort of robustness for another 5 years at least.
For context: https://forum.snapcraft.io/t/disabling-automatic-refresh-for...
Snap developer responses are hilarious. No matter what your use case is, Snap developers know better than you, you silly irresponsible sysadmin/user. Snap is basically just another App store.
https://github.com/cies/kubuntu-setup/tree/master/chromium
It's also disingenuous to suggest a browser wrapped in a cryptocurrency promotional wallet thing as a comparable alternative.
Sure, but some people just want to have their problem fixed and they only have a sledgehammer in front of them. If it works, is it really that bad?
> a browser wrapped in a cryptocurrency promotional wallet thing
I think you have it the wrong way around. It's a browser containing an integration with a cryptocurrency wallet, not the other way around. You'd still be able to use it as a normal browser if you ignore the cryptocurrency stuff.
So shortly after the Mir fiasco, why does Canonical feel it necessary to come up with the next dumb idea?
They give the suggestion to remove via
And make sure it never installs again:Other than that, I do not think other packages are affected.
Snaps break debain's stable release model. They allow upstream to ship updates outside of the normal 6 month ubuntu releases. There are times when you might want this, but it should be opt in not mandatory. I thinking specifically of lxd which is only shipped via snaps.
The snap store's trust model is confusing. Its hard to tell who is making the packages and how they are sandboxed. If I'm going to install a proprietary piece of software I want to know exactly what it can and can't do. Lately I've been using firejail when I need to run things like this.
And now for a minor complaint that also feels most user hostile to me: why do the snap developers think its ok to require a non hidden directory in $HOME? Seriously my home directory is MINE, if you have to store application state there at least have the decency to do it in a hidden directory.
Applications need a place to save state, and you don't really want it to be hidden, because sometimes I as a user do need to change it manually for any number of obscure reasons. So you make a subfolder that's designated for apps to write to.
There's no good way to put this into the existing Linux model though. All you'd do is add yet another standard a la https://xkcd.com/927/
Especially when a . is used to make the directory hidden, because I can't unhide that specific directory without changing the name apps expect.
I get into the Library folder by doing: cmd-shift-g -> ~/Library -> enter
In Catalina, it's now Cmd-shift-fn-.
https://discussions.apple.com/thread/250756110
$ ln -s .hidden not_hidden
It's that easy. Really.
I'm being picky, I know! But I still think the Library approach is cleaner. (Again, back when it wasn't hidden by default!)
This model is terrible. OS asks up-front: program wants permissions to do A, B, C, X, Y, Z: grant/refuse? You the user decide that the program should not be allowed to do X, so you refuse. Now the program will not run at all. That's about the worst design possible. A 10 year old can brainstorm a better design within a few minutes.
Investigate prior art:
In practice, apps that want access to my contacts usually keep asking for access every time I try to do anything, until I eventually either relent to make the prompts go away or click allow by accident.
And that's me as a computer-enthusiast. I would bet money most normal people just hit allow always. Because it's easier.
Some apps even try to circumvent this system by showing a "help" screen with instructions on how to re-enable the permission manually, but I only saw this twice.
Still, this is not practical enough. A true user-centric strategy would be to offer "mock-permissions" to an app, so that if an app says that it needs to read your home dir, you grant mock permission to the app, and it sees an empty home dir, not yours. From the point of view of the app, it should be impossible to know if it has been granted the real permission or just a mock permission.
People still just click "allow" on everything. They get tired of getting questions asked, and just want the program to work, so they don't even read anything and just tap tap tap until it lets them through.
Access your files? Sure. Access your documents? Whatever. Send data off to our corporate data vacuum? Whatever, I need to see what my face will look like with an AR moustache!
Also, are you running Catan as root or something? How is it able to compromise your whole system?
After fighting with node, vlc and ffmpeg snaps not working reliably, I had to add a warning for my PhotoStructure users on Ubuntu to avoid those packages (and how to install them via apt).
I agree with a bunch of people here: snap promises some great features, but in practice the horrible performance, additional resource consumption, and spotty reliability led to me actively avoiding snap packages and looking for an alternative installation.
4 years old now.
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053
https://docs.microsoft.com/en-us/archive/blogs/patricka/wher...
https://docs.microsoft.com/en-us/windows/win32/shell/csidl
.NET has its own set which is also very old and goes back to .NET 1.0 (as old as Win98) https://docs.microsoft.com/en-us/dotnet/api/system.environme...
I have still been using `snap` for the past year, and have mostly been happy with it. It works well for apps like `spotify` and `zotero`, it's a better solution than `ppa` for third-party software, and I like that it tries to introduce a permission model. But not following the dotfile convention is annoying, and not prioritizing a search-and-replace of `~/snap` to e.g. `~/.snap` in the code after four years is strange when this is their most upvoted bug.
The actual heritage is when `ls` was written to exclude .. (dot dot) directories from it's listing the code literally just had the logic to exclude any files which had a dot/period as its first character. Later operators exploited that bug/feature to create items with a dot prefix to make those files and folders hidden. Eventually this became convention.
Whereas systems released more recently understood the need to have a hidden file attribute so made it a first class property.
I do love POSIX and often the first to defend some of Linux or BSDs idiosyncrasies but if there was ever anything that was worth someone saying "I know we've always done it this way but it's shit and it's about time we implemented a proper solution", it would be the dot prefix kludge. (I also know it's easier said than done and would take years for all the tooling to catch up)
Of course you do have system files, which are hidden from all standard folder listings, but aren't usually used by software, presumably because they're too damn difficult to find again (although I really hope google drive realizes at some point that desktop.ini is supposed to be a system file, not merely hidden).
(That said, I would still prefer that they not be.)
In fairness, I think that's the point, just like RHEL streams.
> There are times when you might want this, but it should be opt in not mandatory. I thinking specifically of lxd which is only shipped via snaps.
Yeah, decent idea, poor execution. Especially for system/infrastructure software like LXD. I want a stable kernel, a stable glibc, a stable LXD/Docker/k8s/whatever, and then on top, bleeding-edge applications that will not break the world if they autoupdate at random to a less-tested version.
Because hearing things like `sudo apt install chromium` actually aliases to using snap is disconcerting to say the least if true.
But I'd like to throw in a recommendation for Fedora. It includes Flatpak by default (which to me as always been the least objectionable sandboxing system) but nothing comes as a flatpak by default. You have to explicitly choose to use it.
Fedora's hardware support is second to none, and even supports in-OS BIOS updates.
I highly recommend it.
However, if you want to use chromium-browser you are out of luck. It is no longer available as a .deb package.
tl;dr -> HashiCorp's various tools exist as snaps but none are published by HashiCorp. All are out of date. Some have incorrect metadata. Few provide any clue as to who or where the upstream is. There's usually not even a way to contact the snap author to submit patches or ask for an upstream link. eg https://snapcraft.io/nomad
The latest snap I had to get rid of was Visual Studio Code, because I was trying to work on an open source game with it, and I found out that if I launched the game from inside Visual Studio Code, my game wouldn't play sounds because it couldn't communicate with PulseAudio, and attempting to use ALSA just straight up gave me an error.
On the other hand, I've only had positive experiences with AppImage. Gives you an all-in-one image that you can directly execute if you like, and no sandboxing nonsense.
I expect you needed to do something like that for the VS Code snap.
https://firejail.wordpress.com/documentation-2/appimage-supp...
> Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
Both AppImage and Firejail do one thing and do it well, you can easily combine both and get what you want.
I realize I have to soon upgrade from Ubuntu 16.04, so a while ago I installed 19.10 to see what to roughly expect from 20.04, as there are quite a few changes. Trying things out, I installed VS Code from the Ubuntu Store; I was quite disappointed to see things going south right on the Welcome page, as the snap version of vscode couldn't even open a web browser (instead, Firefox promptly crashed every time).
Of course, being able to open a web browser from VS Code isn't a necessity, but for some reason for me it just seemed like the install was rather broken by default, and surely almost no one could have used it much not to notice a simple thing like that right away – and the thought that even if the problem was noticed and simply shrugged at didn't really make me want to see what else did not work.
I had run it via X11Forwarding (I had a contusion and used a puny laptop to connect to my desktop) and it was not a smooth ride, so it's not an entirely representative experience, but it shows that it's not all painless, yet.
Repositories with dependencies only annoy anyone rather than core linux fans.
I use linux more than 10 years and still hate them. Yes, apt install package1 package2 is good, but dependency hell is so 2005!
Users just need one simple package format without any fancy security and virtualization nonsense.
It's hilarious when you can't update MPV on debian or ubuntu, because of some dependency. WAT 2020
But ofcource we cant have so much platform fragmentation without dependencies and different package formats, it is just "good tradition" now.
I strongly recommend anyone similarly frustrated to check out debian, which is a fantastic distro. Thanks to Kevin for posting this, but if you're using Ubuntu and disabling snap, you're fighting against the current and I have to imagine it's going to be increasingly difficult with subsequent releases.
That’s a bit rich: are they not the #1 consumer distro, which hardly implies they are failing to execute. A successful product has missteps, so what.
> I don't want to run that garbage on my desktop.
So don’t. Why complain that others do? I use Ubuntu because it works and I can mostly find information about how to do what I want. There are major aspects of Ubuntu I don’t like (Gnome, Snap) but selecting a distro is all about choosing your compromises. I have tried Debian and other distros, but I tend to go back to Ubuntu because it works best for me.
All the hard work to make it a viable OS is done by Debian. Canonical just adds some polish and then wrecks it all with poor design decisions over and over again.
Just like windows Shuttleworth admires and seeks emulate so very much.
It's called a network externality. Microsoft achieved this with piracy based market penetration of dos and it worked great for them and they've built on it ever since.
Shuttleworth understood the importance of getting established as being popular when he launched and would press install disks, as many as you asked for, and ship them to you at his own cost. As one example of nakedly going after market share and spending resource to do so.
Bug #1 in the ubu bug tracker is literally "windows is the most popular os."
Separate to the marketing, which is worth discussing on this site because some of us actually care about what works and why so wish to discuss it, let's talk engineering decisions.
Between 2 choices that are technically about equal. Choose the one that is more popular. Many feet trample more bugs. Better support. More likely to be around after $time_period. If it needs to work with something else, the managers of the something else project will likely suppor the more popular first etc. Obviously popularity is not the only concern but it really does count for something, ignore it as a dimension in your decision process at your peril. I use linux, and ubuntu as it happens on this laptop. I'm aware windows and osx are more popular and that popularity makes certain things easier. For /my/ purposes and to /my/ taste linux and ubuntu are worth paying that cost to have installed here and I'm very comfortable with that decision.
Just quietly, perhaps people who don't care for business decisions and engineering decisions are on the wrong website? There's plenty of places "boosters" can go to do that.
There was zero documentation on the change and the error you received attempting to install an extension was basically "operation failed". I discovered the cause only because there was an open bug about it on the Debian bug tracker where the maintainer refused to acknowledge the problem. Eventually, sane minds prevailed and that stupid patch was reverted.
So, unfortunately - you'll end up having to deal with people that refuse to look at things from the user's perspective no matter what distro you use.
And yes - I'm still bitter. :-/
That said, I think Debian's occasional messups are far less egregious and damaging than Ubuntu's though.
LTS on Ubuntu was always better than Debian, I mean saying that Ubuntu is just a repackage of Debian is very short sighted, especially on the security side, Canonical security team is top notch.
They need to, for a long time, Ubuntu has been shipped with EOL Kernel versions https://ubuntu.com/kernel/lifecycle
But what benefits Red Hat in the enterprise world is to their detriment in the consumer world. There's a reason the Debian/Ubuntu package ecosystem is richer and more featureful than RPM, and this is why Ubuntu dominates in the container space--because almost any piece of software that one could expect to have been packaged has been packaged as a .deb and already exists in the default package archives. I can't count the number of times I couldn't find an RPM--certainly not in the default repositories (RHEL, CentOS, or even Fedora), but not even in the third-party community repositories. And those that do exist are of lesser quality than the comparable .deb, for various reasons. (That is, the long-tail of packages is of higher quality for Debian.)
By pushing Snap, Canonical is definitely going astray. Ubuntu's competitive advantage is the Debian package ecosystem. Both Canonical and Red Hat seem to underestimate the role and importance of their respective packaging ecosystems. How many projects to revolutionize or replace RPM/Yum/whatever at Red Hat have crashed and burned? Many, though it's hard to count because half-way through they often realize what they're trying to do is functionally or even technically impossible (as with their aborted 2017 plans for RPM package streams), and scale things back to iterative improvements.
Containers are a security nightmare, and pretty much the only reason to pay Canonical and Red Hat licensing fees is for security and bug fix maintenance of their package archives. On our large Kubernetes clusters at work there are thousands of open CVEs for the containers that are being run, and we'll have to boil the oceans to get them all updated, let alone keep them updated. But updating packages is as simple as an apt-get/yum upgrade[1], and rarely do you have to worry about anything breaking, especially relative to the pain that updating containers regularly brings.
[1] If the container uses Ubuntu, Red Hat, etc you can sometimes just rebuild the container to get the newer packages. But that assumes you control the container image. Most containers come from third-party, decentralized sources (that's the point!). But Docker Hub doesn't cajole and coordinate container owners to update their crappy images. It's no substitute for the orchestration of people that are traditional package repositories.
So, LTS/stable.
I'd expect most people tech-savvy enough to install Ubuntu would also have a decent enough internet to download a ~700mb file.
This was also around the time I would often brick my primary (only) workstation for whatever reason. Having a properly mastered Live CD was super useful.
I would order at least two with every release cycle for a few years at least.
Thankfully, I saw the light early with Ubuntu-server, and stayed with Debian. Ubuntu-desktop makes for a good enough live / recovery / troubleshooting environment, but not sure I’d use it for anything more.
we installed ubuntu with friends in freakin junior high school. it's not like it's rocket science...
OTOH the village where I grew up as a child only got DSL > 512k around 2008 iirc.
So yeah, lot of people got those.
You could equally say that all the hard work to make a viable OS is done by Linux, so screw Debian? Last I hurd, the GNU developed OS is unviable (no 64 bit, no SMP).
Or equally say that all the hard work to make the majority of end-user programs (you know, the raison d’être for an OS) is done by other open source projects, not Debian, so screw Debian...
These are open source projects, with cross-pollination everywhere, each with their own opinions on licensing. Ubuntu mostly helps the ecosystem, and certainly isn’t a parasitic player (although like all, they are not perfect).
Why bag on Ubuntu just because it happens to be popular? Should we also cancel all the other Debian based distros?
PS: complaining about upstart shows you are just being biased (or perhaps misinformed). Canonical were developing upstart before systemd was developed - and systemd was developed by RedHat. The main con given against upstart was not technical, but due to licensing. “In terms of overall feature[s] there is really rather little to distinguish upstart from systemd” https://wiki.debian.org/Debate/initsystem/upstart
No, you couldn't say that. Without toolchains, userlands, and packaging, a kernel is pretty worthless. The barest bones you can go is still gcc, linux, uclibc, and busybox. There is more code that goes into a computer running linux, then there is in the linux kernel. By a wide margin.
FSF does fabulous work, which we are all appreciative of, but some decisions are peeing in the open source pool.
I think RMS creates unnecessary division against Linux and Linus for what I feel are poor reasons. I went to a lecture by him where he spent half his time being negative towards Linux and Linus (that felt like he was just pissed off because Linux was popular) and a bit because Linus had used the GPL2 (not trivial to change, and you don’t get change by attack). Being negative towards the people who are on your own side is wrong IMHO. It could equally be argued that Debian should be called Debian/Linux. Edit: I just found a quote from Linus about RMS that summarises what I wished to say here: “It's not passion for something, it becomes passion against something else.“ - http://torvalds-family.blogspot.com/2008/11/black-and-white....
PS: I totally admire RMS and his relentless idealism. He has given so much to the world, and the faults I see in him are interwoven with the strengths I see: I’m not sure the faults could be mitigated without badly weakening the virtues.
GNOME history: https://unix.stackexchange.com/questions/141114/what-is-the-...
To return to topic: “How to install Flatpak apps on Ubuntu 20.04 LTS”: https://jatan.blog/2020/04/25/how-to-install-flatpak-apps-on...
FWIW the whole GNU/Linux pedantry bothers me too.
Android went from non GNU absolutism to GNU LGPL for its standard java library a few years ago:
https://arstechnica.com/tech-policy/2016/01/android-n-switch...
> That’s a bit rich: are they not the #1 consumer distro, which hardly implies they are failing to execute.
No, that's Debian doing almost all the work.
90% of the packages in Ubuntu are simply taken from Debian without significant modification.
Snaps may be a pain sometimes, but Gnome seems to be working like a charm...
I wouldn't use any other DE, at this point.KDE has always been cluttered and XFCE is buggy and not particularly intuitive.
Nothing as big as a DE is perfect, thankfully it's broadly moving in the right direction.
Like a Juju one? :)
Ok bro cope however you want. Your defeatist attitude and worthless comment really make a strong case for using ubuntu.
People complain like this because they have no real control of their own lives. It makes them feel smart, if only they were in control, then things would be better. It would be so easy, the people in charge must be stupid. It comes from a lack of experience and the inability to understand the challenges in those positions.
The shortcomings of snap are well documented. I assumed anyone reading the comments would have been aware of them. But apparently some people will jump on any chance to virtue-signal.
I'm seriously considering not taking the 20.04 LTS release and either using 18.04 until it's untenable or switching to something else.
I think this is ok though. If ubuntu were better thought out, the linux ecosystem might be less vibrant than it is. I would like to think other distros are learning from these failures. Personally ive had excellent luck with scientific linux (CentOs based).
But have you been following last year's improvements to GNOME's performance and responsiveness? A lot of it is Canonical's devs bringing their experience from Unity.
20.04 should be better still (I've yet to upgrade).
And Void Linux/ i3-gaps before that.
And Linux BBQ / OpenBox before that.
there is no need for latency-hiding animations and subsequently trying to make them run smoothly on the gpu if there's no perceptible latency.
I hear a lot of praise for Unity and I'm the kind of person who enjoy trying out new stuff and Linux Desktops is no exception.
For me, Unity was broken because of alt-tab (behavior and lack of configurability).
It might work for everyone else but when I want to switch back to the last or second last thing I worked with I want that done now.
I don't want to look at the tab switcher to ponder what to do next, just alt-tab, done.
This has worked consistently in every Windows since at least 3.1 (the first my family owned), and in every Linux desktop environment I've used except Unity and Gnome 3. And in Gnome 3 it was at least configurable.
This might seem trivial to a lot of you but to keep focus I keep one application maximized most of the time. I don't use them side by side. Then when I need to reference something (Jira, vendor documentation etc) I alt-tab. Same goes for slack.
It is true that the Debian people are doing a great job.
> [...] if you're using Ubuntu and disabling snap, you're fighting against the current and I have to imagine it's going to be increasingly difficult with subsequent releases.
Actually, snap was harder to remove in the previous release: you had to rebuild certain packages (actually, just pulseaudio, so it only matters for desktops) to get rid of the dependency, but it seems now that it's just a couple of apt commands, so you have to give Canonical credits for making it easier.
That being said, it's not as bright as I thought it was - see my other comment.
sigh...
Edit: Please note that many of these are "leaf" packages, by which I mean that no other packages depend on them.
Not at my computer now, but that cannot be correct. Could recommended packages be included in that list?
I did apt-purge snapd on my xubuntu 20.04 and it did not pull out anything unrelated.
When you install something later an it tries to pull in something later you can always try --no-install-recommends.
In the worst case there is eqivs https://wiki.debian.org/Packaging/HackingDependencies but it has been 3+ years that I needed to use that the last time.
I tossed Gentoo and KDE (this is not a Gentoo endorsement, it was just a "hey I wonder what Gentoo's been up to in the last dozen years since I last used it") on a spare laptop. It turns out that KDE is amazing now. It's seriously the best DE I've ever used, and I'm a Mac user! (Half of the utilities I install out of the box on a fresh macOS are built in, and the annoying stuff that used to be editing arcane files is now easy preference settings. It's actually great.)
What the hell are Ubuntu doing shipping Gnome (with the ugliest custom theme known to man, to boot)? Admittedly it was my own ignorance, for which they are not responsible, but their mindshare and bad choice tainted my whole view of the state of the art for a long time.
>[...] To show our commitment to this dual licensing model, the KDE Free Qt Foundation was founded in 1998. It is a non-profit foundation ensuring that Qt will always be available under open source licensing terms. The agreement that governs this foundation has stayed mainly unchanged over the last 17 years. As a lot of things have changed during these years, we have been working with KDE over the last year to create a new and updated agreement that takes todays realities better into account.[...]
From: https://www.qt.io/blog/2016/01/13/new-agreement-with-the-kde...
The updated contract mentioned in that blog post is available here: https://kde.org/community/whatiskde/Software_License_Agreeme...
https://news.ycombinator.com/item?id=22821050
That's been the case with KDE for 15-20 years now. KDE 3.5 was a great environment (and Trinity (TDE) is a modernized fork of it).
Note that, this year, KDE added telemetry to their Plasma desktop environment. Of course, it's opt-in, so it must be acceptable, right? Well, of course, users who objected to the telemetry found bugs that caused data to be recorded even when disabled.
KDE's response was to ban said users from reddit.com/r/kde and call them "paranoid schizos." (The mods there are KDE members wearing "KDE developer" flair, not random Redditors.)
So, despite using and recommending KDE for almost 2 decades, it's hard for me to do so any longer. I wholeheartedly recommend checking out TDE instead.
It sounds a bit hyperbolic, but I can't recall a time when telemetry was added to a system and then later dialed back in any way. It always increases.
If I dabble with debian or kubuntu I will make sure to mitigate it, thank you for making it known, keep up this kind of good work!
It’s a real shame that they found it necessary to even build a telemetry client. I switched to free software after years on macOS (I remember upgrading to System 7) because of all the phone-home that Catalina STILL does even with iCloud, Siri, analytics/crashes, Screen Time, iMessage/FaceTime, Location Services, ntp, App Store, and software update all disabled.
iOS apps in the App Store are all allowed to phone-home like mad, too, and Apple permits this on the basis of you “opting in” to it in the App Store TOS, as if we have any sort of choice on iPhones. It’s totally endemic, and entirely undermines the credibility of Apple’s claims to caring about user privacy.
Seems like spying on users is getting heavily normalized these days. :(
Do you have examples of what you mean?
1. KDE's telemetry is opt-in (as you mentioned)
2. All data is anonymized
3. You can select which information you're comfortable to share
4. If you have it turned off, the data is recorded on your hard disk.
5. That data was always recorded in order to enable other features like "Recently used documents".
Here's some explanation:
https://www.reddit.com/r/kde/comments/fmgyy9/kuserfeedback/
Honestly, KDE has been one of the most open, privacy aware and idealistic communities out there. The criticism is quite unfair.
(I used to be a KDE contributor)
> users who objected to the telemetry found bugs that caused data to be recorded even when disabled.
> KDE's response was to ban said users from reddit.com/r/kde and call them "paranoid schizos."
I agree. The data should not even be generated if the analytics are not opted-in-to.
I do give them credit for making the system opt-in. They deserve that.
It was like a different gnome - quickly reaching the desktop and lots of nice differences (like the privacy menu wasn't crafted by marketing and legal)
And that is doable now, considering Thunderbolt. Hell, Oneplus should try to push OxygenOS to be tablet-like and this would set them apart from everyone.
Upstart was started alongside or even before systemd, if I recall correctly.
But still, emptying a directory is not how I expect to disable what is a system service. It should be systemctl disable netplan...
I think emptying would be better than deleting the directory since it'll probably just get recreated on an update.
Seriously, a whole bar for a WATCH? How come good old Gnome2 did it better 15 years ago, and had a terrific hierarchical menu, to add?
I think this model is underrated, for all that it can sometimes be annoying. Consistency is valuable. Constant change is not good, even when the changes themselves are positive. But it does mean you'll sometimes be left with out-of-date software.
Edit: Oh, I should mention that you can also use Debian testing to get frequent updates. Primary issue here there is Debian Testing actually gets security updates later than Debian Stable.
upstart was pretty good. It just lost the popularity contest with systemd. I'm not sure if there's really anything serious to complain here about.
Please read the HN guidelines: "Please don't post shallow dismissals, especially of other people's work". Link at the bottom-left.
Do you know Red Hat and google were using upstart? This companies must be hyper incompetent if they run garbage.
https://github.com/cies/kubuntu-setup#remove-snap
This is needed because an every growing number op packages is "dependant" on it.
Here I show how to install Chromium as a DEB package from Debian (on a buntu):
https://github.com/cies/kubuntu-setup/tree/master/chromium
I despise the bug, it causes so much trouble without a way to turn it off. Plus the switch to snap happened exactly during a critical vuln which meant people were running on critically vulnerable chromium for weeks.
I'm not against stuff changing, but tell us up front, explain what's changed and make sure that you're not breaking existing things or provide a way for people to keep their existing stuff work, a flag that says that following symbolic links is OK ... and put that UI in Chromium itself, not in some other box somewhere
In this month only I had to give up using firefox because uglyBar and ubuntu because of snaps.
There won't be anywhere to run soon.
I think most users will be fine. Those of us who need more fine grained control, can have it.
Annoying but harmless: it's start time has multiplied.
Workflow-breaking: Chromium now can't see my NFS mounts anymore.
It's not just about having a pretty home directory.
It's distributed as AppImage for Linux. Very much recommended.
What is "performant" supposed to mean here?
Is Flatpak faster than Snap? more compact? simpler? more reliable/secure? easier to use? more efficient in terms of cpu/memory/communication/power/etc.? all of the above?
I really hate Snap/Flatpak conceptually. Use the package manager. That's what it's there for. FPM is a way to make package building easier.
Snap/Flat tools feel like they're about the same as Electron cancer; and I bet we'll see more closed source commercial stuff pushed to the Linux world via them as well.
By the way, what is it with Docker that makes it hard or impossible for it to be used for this exact purpose?
It doesn’t “suck,” and many of the ideas are compelling. But, the design and implementations could be better. I was interested in rkt until it was acqui-abandoned.
Snap suffers from the overhead of having to decompress a squashfs on program launch: https://forum.snapcraft.io/t/squashfs-is-a-terrible-storage-...
My experimetsn on the same laptop showed that..
Launching Skype installed from deb is almost instant.
From snap it takes around 10sec to get anything to show.
This is on quite fast nvme disk.
Yes, Flatpak is just bind mounts and namespaces. It doesn't have the overhead of the squashfs images.
There is a level of care here which I think is great. Some engineer somewhere made sure that the system would still work without snaps. This is a very Debian attitude which Ubuntu inherits from and which I would like to celebrate for a bit :-)
A workound is posted at https://bugs.launchpad.net/snapd/+bug/1776873/comments/29 (simple patch & recompile). May be worth making a PPA for the fixed snapd if we can't get the Canonical dev team to fix the core issue.
It's extremely weird to see this kind of thing when it happens too, you usually trust Firefox to work!
I prefer the isolation of snaps so I’m willing to put a little work into it, but understand not everyone cares to do that.
It also causes data loss: https://bugs.launchpad.net/snapd/+bug/1616650