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.
[1] https://forum.snapcraft.io/t/is-there-any-protection-against...
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.
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 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.
> 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.
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.
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.
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.
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 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.
You can view package info prior to installing, but if we're talking about a typosquatting issue here, that doesn't really help.
I didn't go through this process so I don't really know.
I think that is how it has worked so far for all of the 1st party snaps I have seen.
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.
https://forum.snapcraft.io/t/squashfs-is-a-terrible-storage-...
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.
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.
It's not really an issue with snap itself.
Flatpack on the other hand, does support that structure out of the box, and a few projects are already using there own repos.[2]
[1] https://forum.snapcraft.io/t/external-repositories/176 [2] https://docs.flatpak.org/en/latest/repositories.html
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:
https://people.canonical.com/~ubuntu-security/cve/universe.h...
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.
I was just trying to pick a random example.
My concern is really more about the command-line, as that's how I (and probably most technical users) install packages.
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.
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.
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.
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.
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.
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.
Progress goes on is just the general point. Nothing else intended. Should be clear enough.
https://news.netcraft.com/archives/2020/04/08/april-2020-web...
https://news.netcraft.com/archives/2019/04/22/april-2019-web...
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:
https://github.com/cies/kubuntu-setup#remove-snap
I found a way to use Debian packages reliably on buntus with a trick that is shown here for Chromium:
https://github.com/cies/kubuntu-setup/tree/master/chrome
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.
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.
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.
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.
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.
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.
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 don't know of other benefits, though.
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.
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.
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.
"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 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
I dont care packaging got easier. I care for a smooth working system I can understand and instrument, and that does not hog resources.
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.
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.
sudo snap remove gnome-calculator
sudo apt install gnome-calculator
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
I hope they smooth these rough edges further before they push more snaps onto the world.
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.
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.
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.
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.
Exactly!
I found a way to remove snap[1] and get Chromium from Debian[2]. But I'm close to leaving the buntus over this drama.
[1] https://github.com/cies/kubuntu-setup#remove-snap
[2] https://github.com/cies/kubuntu-setup/tree/master/chromium
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.
[1] https://github.com/cies/kubuntu-setup#remove-snap
[2] https://github.com/cies/kubuntu-setup/tree/master/chromium
Oh THAT'S why that happens sometimes. I never bothered debugging it.
I used Spotify, VS Code and some PS2 emulator from Snap and haven't seen this behaviour. Which snap package does that for you ?
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.
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.
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).
[org/gnome/desktop/interface]
text-scaling-factor=1.5edit: Nevermind, seems that it got even worse for my case:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1...
https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/187340...
_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.
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 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).
I find it much superior wrt Gnome, but that's a matter of preferences of course.
That was the main reason that after more than a decade I turned to Gnome. HiDPI and fractional scaling just works since then. Highly recommended!
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?
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.
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?
What should I and shouldn't be using it for?
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.
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.
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.
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.
https://packages.ubuntu.com/search?keywords=lxd&searchon=nam...
At that point, there's no reason to not run debian instead.
I use free software to own my computer, if it decides on its own when to update like snaps do that defeats the purpose.
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.
I use WPS Office (not open source) on Ubuntu mainly because it supports Asian/Complex script much, much better (as in, almost identical to MS Office).
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.
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.
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.
Great quote, I'll try to remember that.
Also, folks forget how times change. Ten years ago most were still trapped on Windows. Today a lot fewer are.
Excel is arguably the most successful programming language ever, or at the very very least second most successful after JavaScript.
(Note to future commenter: I said "most successful", not "best".)
Looking forward to handle being a terminal app to install all of those things. Throw us some games too.
No manual entry for handle
Edit: here's the procedures to activate a flight sim in excel 97 as I understand https://kb.iu.edu/d/agqw
You can fly around using your mouse or the arrow keys. The monolith lists Excel 97's developers.
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.
Word is nice too, although that I could probably change that rather quickly (word processing is not hard to get right).
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".
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.
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.
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.
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
The bank I used to work for moved to cloud exchange already.
Since edge has moved closer to chromium, chromium on Linux should be decently supported there.
https://github.com/cies/kubuntu-setup/tree/master/chrome
I also use FF primarily, but sometimes I need Chrome (chromium actually, I should fix that).
URL is now https://github.com/cies/kubuntu-setup/blob/master/chromium for the curious.
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.
[1] https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053
Xfce is a nice alternative to GNOME 3 that reminds me a lot of GNOME 2.
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.
You can `apt` to install `.deb` files on the local file system using:
apt install ./path_to_the.debWhere did you hear about this?
> 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 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.
Google Docs is simply not capable of business level work. Sorry.
I thought you were talking about Office 365, which is significantly better, but still not up to par with the native applications.
There's another way?
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.
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!