Most reviews are very positive. Faster, better, Amazon removed, maybe the best Ubuntu release until now.
The only 'con' is the pushing of Snap packages. It looks like deb files only can be installed via the terminal.
Ubuntu is also researching if they can get Adobe on board. I doubt this would ever happen, but that would be huge. Most people stick on Windows and MacOS because Adobe software is not available on Linux.
Personally I switched back from Xubuntu to Ubuntu. And I must say: Ubuntu is back on track!
> The only 'con' is the pushing of Snap packages. It looks like deb files only can be installed via the terminal.
My main concern with Snap is security.
Using the default Ubuntu Apt repositories, I can `apt install` pretty much anything I want and it's almost guaranteed to not be malicious/dangerous, as only trusted/well-established developers can get their package into the Apt repos.
However, with Snap, everybody in the world can publish any old rubbish in the Snap Store, including packages that typosquat the names of others.
Snap's current 'protections' for this are mainly reactionary rather than preventative, which is far from satisfactory [1].
For me, the absolute key selling point of Linux over Windows/Mac is the secure-by-default and natively integrated package management. Pushing Snaps as the main package management method goes too close to the Windows way of just downloading random EXEs from the internet.
I personally would like to see Apt remain as the default system package manager for all common/well-known software, with Snap existing purely as a 'community' repository for software that is known to be untrusted/unknown.
The amount of cases for malicious snaps was about 1 with the cryptominer that was addressed within 3 days. Those snaps that are published go through static analysis and unless manually vetted will not have access to the rest of your system. You install it, at worst it will cryptomine that is it. Oh and you can remove it completely with all traces unlike deb equivalents.
Snaps come with a tick against verified snaps coming from first party. Such as those from Jetbrains, Mozilla, Microsoft, Amazon, Spotify etc..
If you are downloading from a software center this would all be handled for you and typo squatting will not be a problem.
In contrast with debs, the person who owns the PPA for those third party packages do have unfetted, root access to the system. The most popular PPA to this day is a closed down Java PPA run by 3rd party dev. That could easily turn malicious easily.
> You install it, at worst it will cryptomine that is it.
Last time I looked, snaps still had access to the X server. They were therefore perfectly capable of logging and inserting keystrokes, capturing whatever sensitive information is on screen, etc. Has this changed?
I don't think Wayland would solve this, because even if Ubuntu switches to Wayland, variants like Xubuntu (which inherit snap from the base distribution) still use Xorg.
This sort of thing is often overlooked when we talk about linux sandboxing technologies. People see the word "sandbox" and assume safety, but the fact is that most of these sandboxes are leaky in one way or another. Does it protect X11 abuse? DBus abuse? Shared memory? Microphone access? Device node access? The list is long, and the leaks are different in each of the sandboxes.
You are right, there are still issues and vulnerabilities present with using X. That is the case with every distribution mechanism ever in existence.
You would have to be a complete numpty to download and install such a thing as it wouldn't come from anything with first party support. Enough of a numpty that you shouldn't be trusted with root to begin with.
Wouldn't be surprised if this specific thing was scanned for and flagged with their static analysis tool. It seems like something that would be flagged.
> DBus abuse?
When I added the dbus slot for the firefox snap, Canonical wouldn't push to the store until it was manually reviewed. So yes, asking for new permissions/unusual permissions would probably need review.
Note that it should be possible for X server to pretend there is no other client connected to a particular program and AFAIK it already does this for remotely connected clients. Snaps could (if they're not doing this already) use this functionality to isolate themselves from the rest of the system.
I was specifically talking about the default, trusted Ubuntu Apt repositories, not custom PPAs which are of course inherently untrusted.
> You install it, at worst it will cryptomine that is it.
If that happens then I have no choice but to assume a full system compromise and nuke my machine. It's not a risk I'm willing to take, as there's essentially no way to definitively prove that that's all the malicious Snap was doing.
> Oh and you can remove it completely with all traces unlike deb equivalents.
Snap sandboxing is rarely utilised in a meaningful way, and the permissions for a particular app are controlled by the author by default. In most cases there's nothing explicitly preventing a malicious Snap from gaining persistence even after it is removed.
In other words, Snap sandboxing is in no way comparable to a 'proper' solution like a well-configured Firejail or a VM.
>If that happens then I have no choice but to assume a full system compromise and nuke my machine. It's not a risk I'm willing to take, as there's essentially no way to definitively prove that that's all the malicious Snap was doing.
You can be rest assured that the problematic snaps were tackled and addressed within 3 days, there are no cryptominers on the store anymore. That and it was actively searched for.
Why are you downloading random crap from teh snap store to begin with?
People always take extreme perspectives over this and I find it weird. No you probably shouldn't be installing hello-world snap from Davind1923232. I wouldn't expect you to do that on Android or any other manufacturer. It probably is safe, in that it has had as much vetting as any other store owner.
Downloading firefox, vscode, intellij, vlc, nodejs, spotify and all of these other first party snaps is perfectly fine.
>Snap sandboxing is rarely utilised in a meaningful way, and the permissions for a particular app are controlled by the author by default. In most cases there's nothing explicitly preventing a malicious Snap from gaining persistence even after it is removed.
Snap permissions aren't controlled just by the author. I have disconnected plenty of plugs that don't magically reappear. Especially for sandboxing internet facing programs from my home directory.
Snaps can't magically persist that is a load of FUD. The files needed are stored on squashfs, home config and configuration in it's own isolated directory. On removal, the squashfs is removed and that is gone.
>In other words, Snap sandboxing is in no way comparable to a 'proper' solution like a well-configured Firejail or a VM.
Why do you comment on things you really don't seem to understand. This is the entire point of snap plugs/connections which are enforced permissions based model.
> Why are you downloading random crap from teh snap store to begin with?
I'm not, but the fact that there's the potential for junk to exist on the store in the first place is the problem, especially when there isn't adequate protection against typosquatting like I mentioned originally.
As long as I only use the default repositories, I can `apt install` a package I've never even heard of and it's pretty much guaranteed to not be malicious/actively dangerous. With Snap, this guarantee doesn't exist to the same level.
Sure, there is moderation and review in place, but this puts the Snap Store in the same realm as other stores and 'community maintained' package managers, almost all of which have issues with junk/dangerous packages.
> Snaps can't magically persist that is a load of FUD.
Yes, in many cases this is right, but some of the most common Snap interfaces (multiple of which can auto-connect) would provide enough leverage on a system to gain persistence or actively interact with things outside of the sandbox.
For example, the `home` interface is enough to compromise an average personal computer and probably gain persistence, as everything of value is usually within the home directory. (I do like the fact that `home` disallows access to hidden files though.)
The `x11` interface can even be auto-connected, and this potentially allows the Snap to read the graphical output of other applications.
I agree that these scenarios are quite theoretical, but as foresto says in this thread, 'sandbox' implies 'safe', and sandboxed Snaps are quite leaky compared to other sandboxes such as Firejail or a full-blown VM.
Perhaps this is just a terminology problem? I would say that Snap sandboxing is far more comparable to permission management on an Android phone.
>I'm not, but the fact that there's the potential for junk to exist on the store in the first place is the problem, especially when there isn't adequate protection against typosquatting like I mentioned originally.
If you are that concerned about typing the wrong thing then use a software center. I have never even seen one and I have been using snaps since their inception. I am using 38 snaps and I have never once installed something i didn't intend to do. I also tend not to run sudo commands without knowing what i am doing.
It's not like launchpad, or universe isn't full of junk software too. I think you can download an open source rootkit via apt as if that matters.
> For example, the `home` interface is enough to compromise an average personal computer and probably gain persistence, as everything of value is usually within the home directory. (I do like the fact that `home` disallows access to hidden files though.)
You can't gain 'persistence' just from the home interface. In fact the only way of getting 'persistence' AFAIK, is through creating a systemd snap like ufw. Again, I am fairly certain that stuff requires manual vetting before being published to teh snap store.
X11 vulnerability applies to everything, and will apply to everything until wayland is usable. Connecting it automatically means that users actually have a functioning browser. That is a sane policy because users shouldn't have to mess with configuration files to get their programs to work (unlike firejail profiles).
All you are describing are permissions which are generally needed to actually run useful programs. Yes, programs automatically connect them. I do suggest reviewing software permissions before executing it, and you can do that with snap.
>sandboxes such as Firejail
You are talking about leakyness and mention Firejail? Firejail has historically had the most severe CVE vulnerabilities partly because of how usernamespaces/network namespaces work. It was basically a setuid binary and proved a easy mechanism to get root.
Snap is built using the same tech as namespaces, but doesn't act as a setuid binary (I think because it uses mounted namespaces rather than creating a usernamespace). It uses the same seccompf, and same browser sandboxing. The bonus of snap is that it actually comes with working apparmor profiles unlike firejail.
I'm not talking about gaining persistence via a legitimately-installed system service. Instead I'm talking from a malware point of view.
If a malicious Snap has read/write access to non-hidden files within someone's home directory, you can almost certainly gain a level of persistence, e.g.:
* Edit a desktop shortcut file so that it points to your malware
* Edit a script or program so that when the user runs it, it runs your malware
* Edit a non-hidden configuration file in a malicious way
I am talking very theoretically here, and I agree that this is taking security concerns to the extreme, but these are important considerations that aren't really present with Apt (when using default repositories).
At the end of the day, despite my security concerns, I do like Snap and the technology it uses.
However, at the moment at least, I will always prefer Apt with default repositories as it provides that extra level of safety/guarantee of authenticity.
Finally, I use a script to install the Chromium Snap to remove the risk of typosquatting, which sufficiently mitigates this risk for me.
I don't know much about the Snap system - regarding 3rd parties and the "tick", is this using domain verification, or some other means? Do 3rd parties have to pay for this?
I read something the other day about needing to pay Canonical $15k/y for a branded Snap store, but I'm not sure if that was about private stores, this, or something else.
Another point is that when installing Snap packages from the command-line, the verification tick only appears after the install has finished, by which point it is already too late.
You can view package info prior to installing, but if we're talking about a typosquatting issue here, that doesn't really help.
>However, with Snap, everybody in the world can publish any old rubbish in the Snap Store, including packages that typosquat the names of others.
This is why I don't bother installing snaps unless the developer themselves are actually providing(or at least promoting) the snap. There's been a couple of occasions where I went to install the snap and it turned out to either be an old or broken version of the software.
I don't have too many technical quibbles with snaps, it's just the way Ubuntu has the ecosystem setup now.
There's an even bigger security hole with Snaps. If a library is compromised on apt, they'll push the update and your applications will be updated. With a Snap, every single snap developer must somehow come across the error (which could be in a sub-dependency), find the fix, then deploy again. Very few (if any) dev teams are that well connected to the development of their dependencies. In contrast, the developers of those dependencies will be very well connected.
> If a library is compromised on apt, they'll push the update and your applications will be updated. With a Snap, every single snap developer must somehow come across the error (which could be in a sub-dependency), find the fix, then deploy again.
Snaps compete with third party apt repositories, not distribution-provided packages (but see below). I've seen a general trend in complex upstreams _bundling_ their dependencies even in builds destined for apt/deb -based distribution via third party apt repositories - because handling differing dependency versions across every distribution release is too complex. In this case, your distinction is moot. In both situations it is up to the upstream developers to update their dependencies. Only that with snaps, their sandboxing security model provides some mitigation.
It is true that some packages traditionally shipped by the distribution are moving to snaps, such as Chromium. This is because these packages are moving to bundling anyway, because updating them during the lifetime of a stable distribution release has become impossible any other way, due to the same dependency pain.
I can `apt install` pretty much anything I want and it's almost guaranteed to not be malicious/dangerous, as only trusted/well-established developers can get their package into the Apt repos.
Maybe not malicious, but packages in the universe repos only have 'community maintenance', meaning that they are not updated with security fixes in any systematic manner. Given that you need universe to have a somewhat useful system, most people's systems are full of known holes:
> meaning that they are not updated with security fixes in any systematic manner.
Interestingly, that exact thing was always my worry about Snap (or Flatpack) as well.
Sure, big-name software such as Spotify will keep their Snap package well in order; they've got both the incentive and manpower to do so. (Incidentally, they could also use this manpower to build distro-specific packages).
But what about all the little open-source hobby projects? They'll be packaged with whatever library version happens to be latest at the time. And then, be updated whenever the hobbyist dev finds the time and inclination.
So on my system I might have a huge zoo of different versions of the same library, with various bugs or vulnerabilities.
If they all used the same system-wide library, at least they would all be fixed at the same time (when the library maintainers publish an updated .deb).
To me, Snap and the like feel like they're essentially the same as static linking, except more opaque.
Spotify aren't doing a great job with their Snap, it's been a few versions behind Mac and Windows for a while now. They could do with more dev manpower.
I understand the hate for snap (and flatpak) and I personally use deb as much as I can, but they are the right move.
Yes, right now it's a subpar experience.
But you need to deploy it now to be able to improve on it and have it as the default in the future.
And I believe it's a better future, because:
- packaging a deb is difficult. I've done it, and it's a lot of complicated hard work you get to repeat for every release for anything that is not a simple program. Snap and flatpak are very easy to build and support accross releases. This will increase the number of software that will be provided to Linux. In fact, it already has.
- the permissions model we have on our phones is very hard to replicate on Linux, yet something like this proves more and more necessary. SELinux and Apparmor are too low level. Snap and flatpak make it easy to make sandboxed app and request permissions by abstracting those. What's more, they make it ovious for the user to know that the apps it uses are sandboxed and the permissions they use.
It will take a few years before we get a streamlined experience with snap and flatpak, and it will be at the cost of a bit of performance and disk space. For now they feel bloated, are not necessarily more secure, and are less well integrated.
But in the end, it will make the Linux ecosystem more user friendly.
I think Snap is a great way forward. I get the argument that shared libraries let you update one package to get a fix for the entire system without relying on any number of maintainers to independently stay on top of security issues, but in practice it doesn't work all that well and makes things more complicated. Maybe Nix improves this; I've been meaning to play with it for years.
From a distributor perspective, I love that it was simple and publishing at https://snapcraft.io/cyph gets us on every distro with no hassle. The alternative was likely not supporting Linux at all right away, or at best supporting a couple distros and requiring more work on the user end.
> packaging a deb is difficult. I've done it, and it's a lot of complicated hard work you get to repeat for every release for anything that is not a simple program
Right, but the point of a high-quality distribution is that this complicated hard work only needs to be done once (per package, updated for upstream changes obviously) by your distribution's package maintainer. Then it scales for free. That's the beauty.
> Right, but the point of a high-quality distribution is that this complicated hard work only needs to be done once (per package, updated for upstream changes obviously) by your distribution's package maintainer.
Sure it works for a sysadmin, but it's not matching at all how regular people are using their computer.
It means you can only use packages that are part of the official repo and:
- it's hard to get in those official repo
- it takes a lot of time
- it assumes free software
- if your app embeds its own dependancies, it's usually rejected by default
- it's a bottleneck for publication (the repo team is limited in resources)
- you have no control over updates
- you can't make people pay for software that are in those repos
- you may want/need to package the software yourself or for yourself
On my computer I have a huge number of softwares that I have not installed from the repos:
puslsms, vscode, telegram, dynalist, veracrypt, signal, discord, antidote, bitwarden firefox developper, guitar, stremio, pop corn time, dukto, photoflare, sublime text, table plus and sublime merge
I think using the simple act of spreading this argument is a demonstration of how remote one can get from the vast diversity of the user base.
Snaps solve the problems caused by users installing from third party apt repositories. Users do that today. Comparing against the virtues of distribution-provided packages is a strawman.
The exception is distribution packages like Chromium and Firefox. These don't work well in deb format, because users expect the latest upstream updates after the distribution releases, but upstreams add dependencies creating dependency hell for packagers. Snaps work better for this case.
Deveroper/packager productivity matters a lot, as people will then bother to package more nice things and keep those packages up to date. It's bad for everyone if packaging is needlessly hard.
Also the sw engineering world is clearly moving away from packaging as "integate application into distro X version set of library versions by continuously expending a lot of integration engineering effort" and more towards things like docker images, snap/flatpak/appimage that sidestep the problem of host platform component dependencies as much as possible.
But your distribution's package maintainer has limited bandwidth, there's only so much software they can support. At some point you need a way for developers to do it themselves.
I agree with almost everything you say, and, yes, people used IIS, windows, as webservers, only not-long ago, so, let's hope for progress. Totally agreed.
I'll enlighten you. About twenty years ago people used IIS for web-servers, encumbered in costly licenses, for everything, and progress goes on. That's the point man. Time goes on, and things gets better. Hope you see now. That was the point, anyways. I really hope it helps.
Progress goes on is just the general point. Nothing else intended. Should be clear enough.
parent is joking around but I got curious and wanted some data on this and found rather surprisingly that IIS isn’t doing so well these days and seemed to have dropped even more in the last year:
It makes my system less predictable, increases load times, makes UI stuff look ugly, obfuscates process monitoring, hogs memory, cannot deal with files in /tmp (and I happen to use /tmp a lot), makes if hard to do audio (like connecting a mic to Chromium)... I can go on.
But in 2019 versions of buntu it could still be removed:
If this snap thing continues to invade the *buntus I will move away from them. For now I still like the combination of stable + up-to-date + familiar (Debian based), but --as others have said-- the snap thing goes against why I choose to use open source.
Have not tried that. Maybe I should, but im on Debian-style distros for so long (and use 'm on servers and such) that I dont really want to learn the basics again.
Also, from my RPM days I remember essential (pgk mgmt) tools changing way too often for my taste. Also I'm a KDE/Qt kinda person, and the RPM ecosystem was mostly GTK based.
You can install flatpaks on many distros, including Debian, Ubuntu, Mint, Kubuntu, et cetera.
I have some flatpaks on a Kubuntu laptop I maintain for a family member and installation was about as smooth as it is on my own fedora machine.
I use cli exclusively though so ymmv if you prefer gui(Edit: Exclusively use CLI for sysadmin).
Flatpaks, according to Wikipedia, were first released in 2015. I don't about the current situation, but initially a bunch of features that are considered necessary for snaps were out of scope of the Flatpak project, such as IoT support.
So it wasn't so much that Ubuntu selected snaps over Flatpak. Flatpaks came along later, and Ubuntu had already invested considerable resources developing snaps.
Well for one they control it. But a good advantage that it has over flatpak is that flatpak cannot run on servers while Snap can, though it doesn't sound like it's enabled for servers in this release?
Just my guess work, but I think they are afraid that THE ONE AND ONLY compatible Linux package format will be owned by RedHat. And that "auto updating" packages in that format will usually roll through RH's servers/repos. They want to be in on the action when a standard emerges and therefor push very hard for it, ship a crap product and experience backlash.
I don't get why they're doing that. Snaps have mostly created problems for me, like they don't scale when other apps do, or the styling is off, or they don't show up properly in the software manager. The snap daemon on one of my laptops always blocks the shutdown by 30 seconds. Generally a rather confusing experience.
I'm on Fedora where the equivalent is called Flathub/Flatpaks. There are definitely some rough edges still, but the possible upsides are amazing for me.
It makes it way easier for a developer to release for different Linux-flavors. The applications get sandboxed and there is much less risk to mess up your system. Stuff like permission, similar to Android/iOS becomes possible.
There for sure is problems to: it makes it way easier for a lazy developer to ship ancient libraries without security fixes, the "packages", now images, are much larger and the quality check of the packager gets sidestepped. And, as always when you try something new, it gets worse before it gets better.
But I think the idea is good and I hope for the best.
The way i see it, software which is truly part of the distribution can and should still be packaged the traditional way. But snap/flatpak creates a standard way to install software which is not really part of the distribution. It replaces all the random tarballs and unpacking things in /opt that you occasionally had to do when installing third-party software. It makes sense for VS Code, IntelliJ, Slack, Chrome, etc, to be in snap/flatpak.
It doesn't make sense for open-source software built with traditional tools by the distribution maintainers themselves to be in snap/flatpak.
I note that on Ubuntu 18, snapd itself is distributed as a snap, which seems like a very poor idea to me.
> snapd itself is distributed as a snap, which seems like a very poor idea to me
I took this as a "vote of confidence" that snap could self-host snapd.
Hosting via snap means they can push updates and not have to wait for users to `apt update; apt upgrade`, as snaps auto-upgrade without user intervention.
> I'm on Fedora where the equivalent is called Flathub/Flatpaks. There are definitely some rough edges still, but the possible upsides are amazing for me.
Except Ubuntu and Fedora each use their own container format. The entire reason we're in this place is that RedHat went with .rpm and Debian/Ubuntu with .deb. There's no-one winning in this format war, and no-one is winning by putting yet another layer of abstraction either. Like with Docker, the problem that container app images are trying to solve (that of incompatible 3rd party shared libs) cannot be solved by containers, because the reason for shared libs to exist in the first place is so that eg. security vulnerabilites in old shared lib versions can be transparently fixed by having the OS install newer libs; but (as you say yourself) with containerized apps this is impossible. You might as well ship statically linked apps instead.
> The applications get sandboxed and there is much less risk to mess up your system.
Apparently snaps are also sandboxed between versions of the same application. My very first experience of snaps was Vuze getting updated overnight and all my configuration and torrents just vanising.
I ended up rolling back the version (to restore everything that disappeared) and, upon discovering snaps are designed to never be able to lock a version number, shot it in the head by killing the daemon and chmod'ing its executables to not be executable.
I assume Vuze's snap was misconfigured, but it really turned me off of them and I've since decided to stick to nix instead of snap whenever I can.
My understanding is snap and flatpak are not equivalent at all because snap is more permissive whereas flatpak is sandboxed.
Specifically, it is not possible to do gpg signed commits from flatpak (e.g., jetbrains idea) without tweaks upstream.
I agree with the overarching idea though: it gets worse before it gets better. See wayland and how we still can’t capture display in obs.
I am a little torn on this. Should the onus to “fix” be on jetbrains and obs? I personally think no where possible. Replacements should be drop in without effort or at least with clear guidance and not too much effort on behalf of individual applications.
Snaps are sandboxed. They can be granted extra privileges, such as access to $HOME, camera, bluetooth etc. Some of these interfaces such as $HOME can be gained automatically by any snap. Others need to be granted by Canonical (to automatically grant access on install), or manually granted by the user post install. There is also a 'classic' mode where the app is unsandboxed, which again needs to be granted by Canonical and in addition requires explicit acceptance by the user when being installed.
"classic" snaps are not sandboxed, and you have to acknowledge that when installing them.
"modern" snaps are sandboxed, and you can change their permissions in the Settings/Control-Panel app. You might argue with the choice of permission granularity, but it IS there.
It's still work in progress but snaps genuinely make packaging easier. There are rough edges, especially on the desktop, but those are all being worked on, in collaboration with flatpak actually.
It will take a while but in the future it will not be any worse at runtime and it will be much, much easier to package and run apps across releases and OSes
Snap and flatpak are great fallback methods. I first try installing software natively, but sometimes it's not available/compatible and you really need it to work, so flatpak is great to just get it running at all.
I'm not a fan of using it as the default though, and flatpak isn't immune to issues either, for example I use a flatpak package which regularly can't be updated for months because of some incorrect metadata if the error message can be believed.
I still think it's a good step forward for increasing compatibility especially across different Linux distributions.
They may be fallback methods, but snap is for sure not "great" (not a finished product as other have pointed out). As you also understood, snap is sadly not promoted as a fallback method.
This stuff is pushed with corporate power. Not adopted because great great fallback method it provides.
The compatibility is also balkanized for the start with the flatpack/snap split. Pfff, what a mess.
Oh! Is _that_ why the calculator is nigh unusable now? Sheesh, this just shot snap's credibility right out the window. It's faster for me to boot up the node executable and do my calculations there.
The more complete solution is entirely removing snap. I did that long ago, but my process was a little painful. From my logs, it went something like this:
snap list
snap remove <copy-paste packages from above>
sudo service snapd restart # core is tricky to get rid of
sudo snap remove core
snap list # check it's empty
sudo apt install gnome-calculator gnome-characters gnome-logs gnome-system-monitor
sudo apt purge snapd squashfs-tools gnome-software-plugin-snap
rm -r ~/snap
And some times, on some systems, the calculator got all transparent, and unusable, so, I left Ubuntu after that. Granted I was on LTS'es almost all of the time, so, this might be highly circumstantial and subjective. But I've been there as you apparently also have. I hope snap improves for the best of all, it seems amateurish to push snap-apps, at their then-current state, in LTS releases. I left basically after Ubuntu 14.04, and even that, 14.04, was a let-down from 12.04, and so on. In my experiences.
Also not yet possible to install a snap using a chroot yet : https://bugs.launchpad.net/snappy/+bug/1609903 (the bug has been open for 3 years). Chroots are a key mechanism to building any customized Linux image.
I hope they smooth these rough edges further before they push more snaps onto the world.
Yeah, snaps are pretty much a disaster if you don't have a simple home directory, put some directories on different volumes with a symbolic link (because they are so large and you don't have room), or use /tmp as a temporary directory to save files into and chrome becomes useless (and fails quietly without explaining why) - I must admit if they haven't fixed this stuff I'm likely jumping ship
I think this is the wrong way to look at it. You still have access to the same packages as before without snap. If you're using snap, that means you either explicitly chose it, or the package is not available in the repo.
The choice here isn't between a package or a snap most of the time. It's between: not using the app, packaging it on your own, or using a snap which is not perfect.
But certain packages are migrating to Snap-only, e.g. Chromium.
I understand why they're doing this (primarily to save on build times), but the way they've gone about it (using a transitional Apt package that just installs the Snap) is messy and inconsistent.
If I type `apt install` then I want an Apt package. Under no circumstances should this install a Snap.
> using a transitional Apt package that just installs the Snap
You need a migration path from an existing package. It's also nice not to invalidate every post on the web which describes the installation.
Chrome is special... it already doesn't really belong in the repository and was handled in a special way. It bundles tens of libraries in its binary without relying on the system/repo deps. It's actually more natural for it to live with all the other "include all deps" applications.
That's because Chromium is hell to keep updated in a stable distribution release apt archive. Upstream adds new dependencies that aren't packaged in the distribution's stable releases, for example. It's not practical to do anything but a whole load of bundling (in debs) to solve the problem. This then isn't much different to a snap any more anyway, and packaging a snap takes a fraction of the effort.
Anyone is welcome to maintain chromium as an apt package for your distribution release of choice, and you're welcome to point apt to that repository instead. The reason it's not happening is that it's increasingly impractical to do while also maintaining Ubuntu's quality standard for debs.
Yep, and the chromium migration broke my webex meetings.
First I had to research and find out how to give it microphone permissions. That worked, but the mic works for about one minute then stops.
So frustrating, I had to move meetings to Firefox which is where I do most of my work. I like to have two browsers to split the work to that which is most appropriate.
That's f'd up. Some people say the default settings for sandboxing [in respects of basic snap defaults or setups] etc are basically disabled some places. Hope that works. Bet the skin looks great. Most snaps I used long ago looked like a un-made-up pig to be frankly. I don't hate on snap, I obviously love it, or either I'd not wasted the time. Let's hope it improves. All improvements are great, obviously.
The problem is, from a user perspective, when simple things as the included calculator is a snap package. I am biased and it's been a long time since I used Ubuntu or snap, but, you shouldn't need to be a hostage to sloppy snap-early-experiments, for the _calculator_, on an LTS release. This is long ago, and, let's hope these things have improved. And will improve. All progress is progress, let's hope for the best. Freedom is good, long live Ubuntu and snap. Right.
These "statically linked" packages can solve certain problems very well. Packaging or installing Steam for non-Ubuntu platforms can be very tricky. I'm using the Steam flatpack version on Arch and it saved me a ton of hassle.
I don't think it's from a specific package. It's just the Daemon. I didn't really dig into why or what, don't have the time, and don't have the energy. I just get the message on the console when shutting down my laptop. Maybe it's updating something? Who knows.
So far, I'm very impressed with 20.04 on my personal laptop (a Thinkpad L390). HiDPI works better out-of-the-box (I didn't actually need to enable scaling manually, but did have to add a Chrome and Teams .desktop file with --force-device-scale-factor=1.2). Power management is much better out-of-the-box too (I've gone from 2-3h battery to 4-8h depending on workload, rivalling what I see under Windows).
But you're right about Snaps. I love the concept (easier distribution, fewer dependency issues especially if you're a few years into the lifecycle of an LTS release) but they're not, in my opinion, production-ready yet so it's frustrating to see them pushed by Ubuntu. The main issues we have are the slow startups compared to non-snap apps (which is felt more acutely on old hardware with spinning disks) and the fact that they don't work if /home lives on an NFS server. That rules out their use for many academic and enterprise deployments.
oh, I am suprised you praise HiDPI support. I could not make emacs work resonably. It does not react on the widely documented Xft and GDK_DPI_SCALE settings as in other distros.
I am on Xubuntu though if that makes a difference. And I have not tried for a couple of weeks. There have been many package updates since I tried last.
I actually tried installing xubuntu-desktop first (and then plain old xfce) as I fancied switching back to them after a few years using Gnome. But you're definitely right that out-of-the-box, XFCE HiDPI support was lacking. Widgets (panels, icons, etc) and fonts all scaled fairly independently, and I gave us after manually resizing a few elements.
On Ubuntu 20.04 (with Gnome), it just worked (with the exception of Chromium/CEF/Blink based applications like Chrome and Teams, which needed the aforementioned command line argument to scale them). I actually had to undo most of the scaling changes that came across with my restored home folder. The one other thing I had to change was the Terminal font as the default was a little too small to use comfortably on my laptop screen - I opted for Liberation Mono Regular, 12pt (px?) with 1.10x height.
As a former long-time XFCE proponent, I recommend you give Ubuntu + Gnome a try. It's the best it's been since the Gnome 2 days, and is no-where near as power hungry as it has been in recent years. The most power-hungry application I'm running is Evolution, where the webkit process that renders HTML email frequently gets out of control and burns 40% CPU until I restart it (I'd use Thunderbird but the Lightning plugin https://github.com/ExchangeCalendar/exchangecalendar to handle Exchange calendar stopped working with recent versions of Thunderbird some months ago).
I hope the HiDPI support is improved now. Right now, when I use fractional scaling on 19.10, none of the display settings get saved and so after a restart, I have to readjust all of the layout, orientation and scaling for displays. Pretty annoying for a dual-boot triple display system.
edit: Nevermind, seems that it got even worse for my case:
Try using mixed DPI displays. My main display is 27 inch 4K display, and on the sides I have old 19 inch 1280x1024 displays, used for IRC, music player, process monitor, email etc. Stuff I glance at from time to time.
_NOTHING_ supports this setup properly. Even Windows has bugs galore as soon as you mix high and low DPI displays. I don't believe anyone ever tests this scenario. I've learned to tolerate and work around the Windows bugs, but I've never gotten it to work at all in any Linux desktop environment I've tried.
I use a 1440p display at 100% and a 4k display at 175% on Windows and it works fine. The only bug that I see is that if a window is spanned across two monitors, it picks the scaling based on which monitor contains more of the window. I'm not even sure that's a bug, it's just how it has to be done. (My first mixed DPI setup was actually on ChromeOS. That got around the issue by not letting a window span monitors. Actually a somewhat elegant workaround, since it didn't let you do that before HiDPI support ;)
Windows and the applications I use even handle the different refresh rates of my monitors pretty well. I have a 165Hz main monitor and a normal 60Hz monitor. Apps are aware of the framerate differences when I move them around.
It wasn't always good, but as time goes forward applications and Windows itself handles HiDPI better and better.
(FWIW, I haven't had any problems on Ubuntu... except that letting the monitors go into power saving mode resets the display scaling override. That was with 18.10, though. I use an Ubuntu VM under Hyper-V now... begrudgingly.)
Having said that, I am not a GUI power user by any means. On Linux, all I ever use are a browser, terminal, and Emacs. On Windows, I use CAD software and games (and a browser, terminal, and Emacs). It all works well enough for me.
I am using a 1200p, a 1800p and a 2160p monitor side-by-side on MacOS and it works fine. The 2160p monitor is rotated to portrait mode for reading/writing text documents. I can hotplug a monitor and it will automatically switch to the right layout, remembering the correct location for all open windows.
I am using a 1080p and a 2160p on ArchLinux/Wayland/Gnome3. It's not perfect, but it's not unusable either (compared to X11, which was completely broken).
The graphical "gnome software" software installer was replaced in the default install by a snap-only fork named "Snap Store" with no support for Flatpak (see https://bugs.launchpad.net/snap-store/+bug/1871944). Were there some technical reasons for this move or was it a business decision to kneecap the other package format?
It's not true. GNOME Software still ships Snap plugin. It's Canonical that decided to fork gnome-software and provide it under different name without competition plugins enabled.
> The only 'con' is the pushing of Snap packages. It looks like deb files only can be installed via the terminal.
Another solution to this (aside from synaptic, command line, other clients) is to use Kubuntu (which has an apt based package manager called Discover, much improved in this release over prior versions). KDE still doesn't work great on tablets, but in all other respects it's a lot nicer than Gnome. Spend 30 minutes tweaking it to your preferences after install (apt install kubuntu-desktop) and you'll have a desktop that does exactly what you need it to. (You could also install KDE Neon, which packages latest stable KDE with a LTS Ubuntu core.)
* Installed VScode. The terminal in VScode was in a different environment from the system terminal, so used different Python environments. Took me a while to figure out why installing a package was not working.
* Installed Slack. When I click a link in Slack it opens a new Firefox process that does not have access to my normal profile, saved logins, etc. and is not shown as a Firefox window in the sidebar.
In both cases I uninstalled the Slack version and installed the "real" version.
The new firefox on link click in slack can be guided by going to `about::profiles` or something like that, and making sure there's only one profile, and that it's default.
I've not used Snap, Flatpack, Appimage and all the other types of app packaging tools before.
What are the benefits? Are they effectively like bundling an application with all its dependencies?
Is it a way of running "native" apps instead of in a docker container?
The negatives, of snap, at least, was that most apps became 'un-skinned,' and looked like unthemed things you'd launch directly in an X11-session so they look like their base-worst, and so on, in my experience. - The first Ubuntu LTS I tried that had snap even had problems with the [snap-packed] calculator, which for some dumb reason was a snap-app instead of a .deb, I'm talking the main included/internal calc-app, and the VLC snap-package I tried was totally unskinned, due to being snap'ped I suppose, as the ppa and etc .deb versions of VLC certainly was and looked better.
Now I am on EndeavourOS, an arch-based distro, easy to use and set up, and this is due to snap being introduced in Ubuntu directly, plus not wanting the ppa chase-game, and et cetera. It's just an/my opinion(s), and certainly not a pointer. Just being objective from my own perspectives, here. Got nothing against Ubuntu or anything, it's a free world, thankfully, still.
Tell me about it df -m was like myles long. And it [meaning snap] had separate auto-update procedures and janitorial daemons, which I had a hell of a time removing and disabling etc. I guess the best thing about snap is that you can uninstall all of them, I hope, and find the alternatives of the same features either in the main repositories or through every-lovable ppa. I loved 12.04 LTS, 14.04 LTS, even, but, this is too much. I had to leave man. Had to be there to know it.
There is sandboxing to protect the security of your computer.
An application that runs as a snap does not see the system-wide "/tmp". They get their own /tmp. If the snap is chromium, it has /tmp/snap.chromium/
The chromium snap would not be able to view files outside your $HOME. Also, it would not be able to read any dot files in your $HOME. Any configuration it makes, is separated into $HOME/snap/chromium/
There are a few rough edges, but the end of the discussion is that you get better security if something goes wrong, and it makes it cheaper for maintainers to created updated packages, and distribute them.
They claim that it does sandboxing, which to my knowledge was never actually activated in any meaningful way.
I have used flatpaks on fedora which was nice, and I also built some which was quite painless. I hate that I can't launch them from the terminal like usual though.
You're right regarding the sandboxing. Snaps use 'plugs' to add sandbox exceptions that can be configured by the package author and enabled at install time, e.g. to allow access to your home area or the network.
Even if the sandboxing may technically prevent the package escalating to root or whatever, this is a fairly moot point on a personal computer as everything valuable is probably in your home area.
Common packaging layer between distros and independent packaging. You don't end up in a situation where the software is packaged for Ubuntu, but not RedHat for example.
> Are they effectively like bundling an application with all its dependencies?
Kind of. Some dependencies, yes. But there are many layers which apps can depend on, so for example I've got an app which depends on "GNOME Application Platform version 3.36" - that is shared between apps which need it.
> Is it a way of running "native" apps instead of in a docker container?
Pretty much. Docker is more convenient for server software. For GUI apps, flatpak/snap/appimage provide nicer interface and more targeted sandboxing. For example flatpak allows to limit which DBus interfaces are reachable - which is not doable in docker. It also allows things like "filesystems=xdg-download;home:ro;" which protects your home directory files from being overwritten.
This, for me, marks the release when (somewhat unfortunately, 18.04 LTS has been good) I will not use Ubuntu for any new installations - desktop or server. I can see how snaps are beneficial for novice desktop users who want an AppStore-like experience, but how do they see people adopting this for Ubuntu Server?
A couple of packages (specifically which slip my mind) that either were only available as snaps and not in the main apt repos, or had way older versions in the apt repos.
At that point, there's no reason to not run debian instead.
I'd like to understand which packages, I've had no packages I need disappear. I'm skeptical that the packages are actually missing to favour snaps, and not simply renamed or replaced.
No, fedora Mate has no flatpaks by default. I do use them on my machine though. They are not as integrated to the system as snaps on Ubuntu but they update only when I tell them to and I like the additional security benefits of the flatpak project overall.
I think security wise it got worse. With traditional package repos someone still does some due diligence. Also it's not clear what's going on, and that is a huge prerequisite for security.
The only thing that holds back my Employer to switch to Linux for 6500+ Desktops is Microsoft Office and full MS Exchange compatibility. The Collegues who need Adobe Products just have to work with Apple Machines anyway.
Just switch to LibreOffice. The dependency on .docx/.xlsx is an overblown propaganda.
I personally had a business in 2007..2011 that replaced windows for Linux. All that time I heard that same old song again: "But but MS Office is so essential!". Turned out, not so much, on over 5000 PCs in several dozen companies.
Update: business eventually failed, for one simple reason - Ubuntu Linux is too freaking stable. The idea was transferring customers to Ubuntu, and have them pay a monthly service fee to do maintenance and fixes. And we have soon discovered that a properly configured GNU/Linux desktop PC can run for YEARS without maintenance at all. Customers had it figured out too and opted to do one-time fees when something goes wrong, and it just wasn't sustainable.
Well, it's a matter of preference and tastes. I can't stand the ribbon interface introduced in MS Office 2007.
I'm not familiar enough with Asian/Complex Script language, but I once was in China and have installed a few Ubuntu 10.04 (brand new at the time) to a class of PCs where students were struggling greatly with Chinese version of Windows. On Ubuntu they were quite happy with how pinyin support worked in OS and LibreOffice.
I don't do Asian scripts, just latin and cyrillic, but I still use WPS office, since a lot of the options are in exactly the same place as they would be in MS Office, it's so nice not to have to go searching for things.
Have you ever tried to open an Excel Sheet from 2002, that one that is existencially important for the whole success of the company :), with makros as big as the Windows Codebase itself, in Libre Office? I can tell MS Office will not leave the field.
Don't you even get me started on xls from 2002. That pathetic standard was poorly supported even my MS itself, files were opening with great difficulties and differences even on same version of Excel on different PCs, and sometimes newer versions could not open them properly at all. Once I have discovered that one .XLS file could internally have different types of encoding within one same document.
Anyway. It is clear that MS Office will not leave the field, like FORTRAN, but the key principle is the same: if you want to get out of the pit, you should stop digging. DO NOT create new spreadsheets in XLSX format. DO NOT ever send out MS Office documents. That's it, simple rules. Follow them for 5 years and you'll wonder, how little you depend on MSOffice.
Recently got some UX whiplash after being in engineer world for years and long ago migrated to .md/.rst over rich text editors. To quote the Matrix, "I don't even see the markdown anymore, I just see bold, italic, header..."
Then I started working with some folks on a Covid mask project and they are massively struggling with MS office docs, dropbox, file versioning, web deployment, wordpress, for something that needs both high uptime and fast updates. I'm like why not just use git, github, and jekyll static sites? Add better looking pages in time.
...
Lets just say they weren't thrilled with that idea.
Sticking to open formats (flat text, odf) is a great start for the individual but it's still a workflow shift for everyone else, which is painful. It was a start reminder for me of the frustration I experienced when shifting my workflow to more open standards. Add to that some serious Hyrum's law when it comes to excel usage.
Yes! Im with you on that. But it is not the tech or IT "Poeple" that we are talking about here. This Discussion is going on for many years now and there will be another 10 Years of "simple" solutions.
I will be honest here. As a Programmer and Application Supporter (for 17 Years now) i earn Money with that kind of Problems. I dont like MS and it would be a joy to switch to GNU/Linux. But i think i will see someone standing on Mars before MS Office will be replaced.
> The dependency on .docx/.xlsx is an overblown propaganda.
It depends on the company. One will use it as a glorified letter composer. Another has a sharepoint integration with version control and documents with ActiveData integration into SQL servers and (literally) thousands of lines of scripting.
Nothing, not LibreOffice, not Google Sheets, not Excel for Mac can replace Excel for me. It's wonderful, they keep adding features and I know all the quirks like the back of my hand. If I ever swap to Linux on the desktop, I'll keep a VM around just for Excel.
Word is nice too, although that I could probably change that rather quickly (word processing is not hard to get right).
This speaks only that you are so used to MSOffice that you don't want to study different app, not that it is really better.
When I switched to OpenOffice.org in 2006 it took me some time to switch, and you know what? I have found that OOo was way more stable, predictable and logical in how things are done. It was also really free as in freedom, and I could run it on any OS of my choice. Now, I know LibreOffice like the back of my hand and it's wonderful.
People who used MS Office all their life usually do this: launch LibreOffice,see different interface, and like "nah... I don't want any changes, I'd rather keep myself and the world vendorlocked into proprietary software".
> _"nah... I don't want any changes, I'd rather keep myself and the world vendorlocked into proprietary software"_
People don't have a problem changing if the change doesn't break their work(flows). The fact that Internet Explorer is pretty much dead proves it - everyone switched to Chrome although is different.
MS Office document format support is simply not good enough on any alternative (of which Libre Office is the only serious contender).
I have tried to switch to Libre Office on multiple occasions over the years, but every time I gave up after couple of weeks of frustration, because I couldn't collaborate on shared documents. Either the stuff I created in Libre Office looked different when others open it in MS Office, or I was breaking the documents for other people.
I don't consider MS Office to be better - it's simply that the alternatives are not compatible.
> MS Office document format support is simply not good enough on any alternative
This is a key fault in your logic. You SHOULD NOT judge the alternative by how it supports the document format that is specifically created in such a way to block competition from effectively supporting it. The company that did it also corrupted the international standards organization to get it an official 'standard' status.
But the truth is, you don't really need MS Office document format support at all. The company I've founded in 2007 never ever sent out any document in MS Office format, never owned any copy of MS Office, and we survived since then just fine.
If you want an electronic spreadsheet, use an open, documented and well supported standard - OpenDocument, and get on with it. Oh, and it is supported just fine on Ubunut 20.04 that we discuss here, as is on a Mac and Windows. The only thing it lacks is a proper online collaborative editor, that's true.
> The company I've founded in 2007 never ever sent out any document in MS Office format, never owned any copy of MS Office, and we survived since then just fine.
It's great that it worked out for you, but that's just not the case in the most business environments I have been dealing with. When a person sends out a document to a customer, and it turns out that customer didn't see the content as intended, alternatives get deleted and MS Office gets reintroduced.
Just to be clear, I'm not a proponent of MS Office. As a matter of fact I run on Mac and Linux and don't have much touching points with Windows, but MS Office is simply a necessity in most business environments.
> but MS Office is simply a necessity in most business environments.
My experience says otherwise. Most businesses can replace it with alternatives without too many difficulties. Definitely 95% of SMB can, I have led many transition projects myself, where companies moved 90% of their computers to Ubuntu and 100% of their computers to OpenOffice.org / LibreOffice
Ignoring format issues, LibreOffice just feels extremly slugish for me. I get little freezes all the time, the UI is laggy and startup time is pretty bad too. I came to dislike it so much that i prefer to edit things in Google Docs over LibreOffice .
I haven't tried it but some people say 'OnlyOffice' is a better branch than libreoffice, it seems to support MS-Office standards better, but, as I said I've never tried it. Only trouble these people had was with certain fonts, but I guess the remedy would be to choose embed all fonts upon saving and sharing, if that helps, then perhaps OnlyOffice, desktop version, is an option, for some. I plan to try it, although I use my old office-versions, in a vm, for now.
I love OnlyOffice along with WPS Office, but they're not "branches" of libreoffice at all, completely different products. You might be confusing LibreOffice branching from Sun OpenOffice.org/Star Office.
It's most likely that I am totally wrong, they just told me it was some "Latvian" branch, Lituanian, so I don't know. I might be confused overall but it's good someone knows. Thank you.
It's always felt slow (I mean, since early in the OpenOffice days). I've assumed it has something to do with its Java dependencies. Back when I used linux I'd stick to Abiword and Gcalc and such when I didn't need Microsoft compatibility, for that reason. On Mac, Pages and Numbers and such are nice and light. Google Docs is too input-laggy and glitchy for me.
I personally didn't experience any problems with LibreOffice performance, but things happen probably. Maybe you'll feel better about it since that sluggishness you experience is compensated by the fact that you can run LibreOffice on a proper OS, not slowed down by necessary antivirus software and the likes
I use Ubuntu at work. Chromium is now snap only, and snap crapped itself with some error messages that didn't immediately lead to a solution when thrown into Google. Firefox was my main browser anyways so not too a great loss but oh man...
> It looks like deb files only can be installed via the terminal.
That's a good thing! I can't wait for Deb installers to stop mucking about dumping random files all over my system. I also can't wait for the whole ppa nightmare which is the only way to get cutting edge versions of software by giving the right to muck about with the system to random packages on the internet to end.
I am disappointed that snap still forcibly clutters everyone's $HOME with an extra directory[1] that cannot be moved or renamed. It was reported four years ago, and nearly a thousand people have joined the bug report. The glacial pace at which they're addressing this problem makes me hesitant to embrace snap.
Idk, since 10.04 I've appreciated that Ubuntu is as far as a mainstream Linux desktop distro as it gets and just works (I used to run various distros including RH/CentOS, Debian, Suse, Gentoo, and also FreeBSD). But I'm on the brink to leave (maybe towards Void Linux, Debian/Devuan, or back-to-Slackware) because the things I care about have atrophied (lightweight DE, real Unix environment) while crap (snap, systemd, gnome-shell, invasive command-line suggestions) has taken over. On 19.10 gnome-shell really gets in the way for me. And Unix command line utilities I'm using all the time stopped working for me (for example, even vim on Ubuntu 19.04 comes with broken syntax highlighting OOTB, and annoingly and incompetently inserts tabs and spaces where there must be none, something I haven't seen any vi implementation doing for over 30 years; also, awk rejects complex regexpes all of a sudden on 19.04). I know there are other 'buntus shipping with alternatives for gnome-shell but for me the point is/was that there is a large installed base eliminating glitches, which however isn't the case for alternate 'buntus any more than it is for non-'buntus. I also don't see the benefit of yet another packaging format; the point of a desktop distro should be to deliver a consolidated set of shared libs rather than going nuclear and ship everything in fscking containers, especially when there are exactly zero new desktop apps coming out these days (with the exception of Chrome which I'd rather install containerized, and which I only use for website testing, my main browser being FF anyway).
> It looks like deb files only can be installed via the terminal.
Oh, I did not even notice that during 4+ weeks on the unreleased Xubuntu Focal because I never use anything else but the command line to install software. But the target audience Ubuntu is wider, so I think that is a very bad change. One might think they have learned from https://bugs.launchpad.net/ubuntu/+bug/1 , but obviously not. Well, formally they declared bug #1 solved, but few would agree that the Linux desktop has won.
How does the snap "repo" compare to the Ubuntu repos in terms of count? I would have guessed it's orders of magnitude. Even if many of the packages might not be useful for those requiring an installation GUI.
One can dpkg -i , but, how about dependencies? I always had a problem with that. Whenever the app-store didn't work, which usually pulled-in all deps, I just naively used dpkg -i pkg.deb, and chased all the deps manually, through google. I have done that at least. Thank god for arch. No politics/"religion(s/*)" intended.
huh how well does that work with individual downloaded *.deb packages? You're probably right, but, the included repos are usually full of outdated versions, if you get a too-new deb, from some experimental site, in terms of Ubuntu freshness, and then no pkgs in the repo will have a new enough version. (In terms of dependencies for the local exteriorally-gotten base pkg.deb and it's deps,) I guess ppa's are a thing, but, yeah, good to be off this train, no disrespects to Ubuntu, if it picks up I will surely be glad, and even, chances are slim, ever use it again. We're all friends, let's say yes to progress, in general, in the right directions.
And it will take care of all dependencies? What if the repo packages are version < 2.4 or something, I have ran into that a tons of times. Yeah rather the AUR than the ppas to be frankly these days. I love Ubuntu though, as a general idea. Let's just hope it works sometime. Bit disappointing the last few releases. If it ever truly wasn't. Just gave up after 14.04. Tried to like it but I failed.
> Adobe Photoshop (Illustrator®, Acrobat and Creative Cloud®) were asked for over a hundred times. (...) bringing these kinds of tools and applications to Linux is an ongoing effort.
I've been using 20.04 since the early betas and Ubuntu since the first release. I haven't been this impressed with an Ubuntu release since that first install.
Snaps are significantly safer for users and easier for publishers to produce. The styling issues and so forth occur because of a security-first mindset. [Disclaimer: work for Canonical, but not on the Snapcraft team]
I would believe you here if snap was not an auto-updating system. This is about the least security-first mindset that it can be; it has a single, gaping, point of failure, after which an attacker may get hold of millions of user's computers without action by their part.
As a user I do not care about publisher's convenience. They should solve their own problems without making users the victims of said convenience. As for "safer" - I'll buy this argument when you get rid of slow startup, bloat and other problems associated with snap.
I don't know if they've removed the ability to do it. I don't think you've ever had to do it. You can just hit space, or just start typing your password from the lock screen.
Yeah you can just start typing your password, last time I tried Ubuntu, at least. Or press any key, and the prompt should appear. Even pressing ctrl could work. But any character-key should be the key, in my experience.
I don't believe my 19.04 login manager does that. I do recall that being annoying because my first keystroke would actually just move that up. Now it starts up to the user list by default.
Sort of, and only really starting in the last year or so, and still limited from the real version, but the market for adobe products among anyone who wants to use Linux is pretty much zero.
Even as a Windows guy, I was wondering: Why would you use anything else than the terminal? When you understand deb packages then you only want the terminal. Everyone else, will want to use a UI and will have no idea what a deb file is.
Everyone understands the paradigm of double clicking an icon to launch the program or an installer. Many aren't going to understand the exact command they need to type into a terminal to get it to do what they want. This is almost always the answer for why people don't want to resort to using a terminal, discoverability. You can look it up, of course, but there's no good reason imo to not include GDebi for users unfamiliar with that workflow. Other distributions have it by default, but Cannonical is favoring their own tech here over the needs of the users. One more useless roadblock.
My dad runs Ubuntu at home. He's completely computer-illiterate. When I need to help him install something over the phone, it's really nice to be able to have him download a .deb, double-click on it, and it just works. I've done this numerous times over the phone with him... it would take me an hour just to get him to type apt install properly.
Oh yeah, used to be at least two more ways. Not sure which one of these are not possible but anymore, but you used to be able to do:
1) Synaptic package manager which is a GUI for searching and installing .debs. My first exposure to a package manager when I first installed Ubuntu some 12 years ago.
2) Simply double-clicking on the file, opening the Gdebi (I think?) UI for installing that specific .deb file.
In my experience, simply double clicking on the file never actually worked for installing debs. The UI would pop up, give me a nice pleasant "Install" button, but clicking it would either no-op, crash the UI, show a progress bar that stalled out, or act like everything worked perfectly but not actually install it. Command line install works flawlessly every time.
Judging by your other comment (https://news.ycombinator.com/item?id=22954061) you were using Software Center for the installing. Gdebi was working fine back before Software Center.
I was using whatever popped up in a default Ubuntu VM when I double clicked a .deb file. If they've chosen to make that not the best software for installing .deb's... lets just say I can see why people say Linux distributions tend to be user-unfreindly.
Ok, great story, but not really relevant to the conversation around the difference ways you can install a .deb, which is the subject of this particular sub-thread.
Synaptic should still work at least for the X session. I haven't used it in a while, but it is a really good package manager. They got it right a decade ago.
This almost never actually worked in my experience. It was more of an annoyance than not even pretending to work, because I'd take time trying to get things to install in the UI and they wouldn't work before I eventually needed to revert to CLI.
My experience mirrors yours. Could never get double-click on .deb to work, same symptoms, and Software Center was always buggy/frustrating. dpkg -i all the way, but that's definitely a ux hit for broader adoption of Ubuntu.
Ah... I want to like Linux. I really do. But I regularly install software across MacOS, Windows, Debian, and CentOS, and the only time I have trouble installing is for .deb/.rpm/.snap.
Installing on Windows is run the installer and click through the guided wizard. Annoying, but it works and it’s foolproof so whatever.
Installing on MacOS is unzip and click and the application is already running. Drag over to ~/Applications if I want to. Easy as fuck.
Installing on Linux is trying to remember what apt-get/snap/dpkg/etc. I need, then on top of that what --dangerous or --classic or I don’t even know what all else I need, and cross my fingers and hope it works. It’s honestly aggravating.
The only 'con' is the pushing of Snap packages. It looks like deb files only can be installed via the terminal.
Ubuntu is also researching if they can get Adobe on board. I doubt this would ever happen, but that would be huge. Most people stick on Windows and MacOS because Adobe software is not available on Linux.
Personally I switched back from Xubuntu to Ubuntu. And I must say: Ubuntu is back on track!