Ubuntu 20.04 LTS (Focal Fossa)
wiki.ubuntu.com
wiki.ubuntu.com
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!
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.
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.
I use free software to own my computer, if it decides on its own when to update like snaps do that defeats the purpose.
At that point, there's no reason to not run debian instead.
https://packages.ubuntu.com/search?keywords=lxd&searchon=nam...
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?
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.
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.
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.
edit: 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.
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).
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 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!
Where 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 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.
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 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.
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.
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
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
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.5I 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.
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.
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.
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.
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 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 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.
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.debAnother 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.)
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.
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...
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.
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.
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.
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.
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...
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
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.
My concern is really more about the command-line, as that's how I (and probably most technical users) install packages.
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.
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.
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.
> 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.
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.
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.
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.
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.
* 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.
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
Gnome 3.36
- X11 fractional scaling.
But then further down below:
Fractional scaling does not work with the NVIDIA proprietary driver (bug 1870736, bug 1873403).
I thought of turning the GPU off under Linux, but external displays (through the thunderbolt port) can only be used with the nVidia GPU. I need external displays for my work, so disabling the nVidia GPU is not an option for me.
- Use Nouveau instead of the proprietary driver
- Use a nested X/wayland server, which should then presumably support fractional scaling
- Use non-fractional scaling and adjust font sizes
Ubuntu actually regressed there since switching back to GNOME from Unity. In Unity font scaling was neatly exposed in the same slider as integer scaling and all apps used that setting. Now I have to set one thing for GNOME and another for Firefox to get the same effect. "Proper" fractional scaling is a waste of resources in most situations. It's only really worth it if you want really consistent sizing of things when you have several screens with very different DPIs.
I already felt like that with the switch from Gnome 2 to Unity. I switched to Mate as a result.
Honestly, I don't get how the Ubuntu ecosystem is so much worse at handling something so basic, when other OSes have had almost no issues with it for over a decade..
- 4K laptop screen and 1080p external, just use integer scaling
- 1440p laptop screen and 1080p external, use 1.3x font scaling and everything looks fine
I currently have a 1440p laptop, a 4K external, and a 1280x800 projector in my work-from-home setup. The external screen replaced a 1200p one before. I use sway that supports fractional scaling per screen in whatever setup I want. And yet I prefer to just set 1.3x font scaling for everything and not touch the scaling at all. Everything looks great.
Fractional scaling is a missing feature for some people and Linux desktops are definitely behind. But compared to font scaling I don't see how it's really much more than a little bump in functionality (some controls sized a little better) for a big drop in performance (calculating >2x the pixels in a lot of situations) and even some loss of sharpness.
It's probably a huge preference thing. I've seen people online waiting impatiently for fractional scaling because things were too small in their 1080p laptop screen otherwise. Even though 1080p on a laptop is sort of the definition of 1x.
So not x11/xorg, but Wayland? I recently switched from xorg/i3 to wayland/gnome on 18.04 - and while I miss the tiling, external screens behave a bit better. I'll probably try sway/Wayland when I have the time to upgrade to 20.04.
> And yet I prefer to just set 1.3x font scaling for everything and not touch the scaling at all.
Doesn't fonts end up too big on a typical 21" 1080p display?
So useful for all laptop-users with an external monitor then.
I don't know how it is implemented, but from my understanding, as long as the Intel chiip does the scaling you should be fine.
Am now to leave Ubuntu, that I used for the last 15 years or so. Thanks for helping me out that long. Going to NixOS and hope it will make my life easier, even if the start is more involved.
Looks like 18.04 came for KDE Neon only in August 2018, so that's a bit slower process then I suppose.
I disable it whenever playing video games on steam.
If you boot the live image and modify a source file, you can install to an encrypted ZFS. I've documented what I had to do here: https://linsomniac.gitlab.io/post/2020-04-09-ubuntu-2004-enc...
I have one of these, a Samsung U28E590D which I'm very happy with in every way. That thing cost me 220 € (purchased in Germany), so I don't see what's particularly expensive about 4K 27" displays at this point unless you have some very particular requirements about shortest possible reaction time or precise color calibration.
From wikipedia:
Lubuntu was originally touted as being "lighter, less resource hungry and more energy-efficient", but now aims to be "a functional yet modular distribution focused on getting out of the way and letting users use their computer"
I stopped updating my OS since (I'm on 14).
Does anyone care to suggest an ubuntu-like distribution for someone like me who wants their OS light?
I'm not sure what other changes would be in your sightlines given that you were happy with Ubuntu, but I usually go to the Arch wiki in those times to see what fat I can trim off of my setup.
It comes with sensible default for a good i3 experience but you keep the Ubuntu "universality".
The good stuff from Ubuntu-gnome (easy-to-use common settings GUIs, utilities etc), + the good stuff from i3, well put together and simple to customize, i3-gaps by default, and easy to install.
It also led me to discover i3blocks/i3xrocks which I didn't know I needed.
here's an example of a i3xrocks script for bluetooth status in the tray.
#!/bin/bash
# how hard is it to find a bluetooth symbol in common fonts...
# more icons at https://fontawesome.com/cheatsheet?from=io
LABEL_ICON= #ᛒ # '' # # # ᛒ
LABEL_FONT="Material Design Icons"
LABEL_COLOR=${label_color:-$(xrescat i3xrocks.label.color "#7B8394")}
VALUE_COLOR=${color:-$(xrescat i3xrocks.value.color)}
VALUE_FONT=${font:-$(xrescat i3xrocks.value.font)}
PANGO_START="<span color=\"${LABEL_COLOR}\" font_desc=\"${LABEL_FONT}\">${LABEL_ICON}</span><span color=\"${VALUE_COLOR}\" font_desc=\"${VALUE_FONT}\">"
PANGO_END="</span>"
NCONNECTED=$(expr $(hcitool con | wc -l) - 1)
echo ${PANGO_START}${NCONNECTED}${PANGO_END}
if [ ! -z "$button" ]; then
/usr/bin/i3-msg -q exec /usr/bin/gnome-control-center bluetooth
fiAny pointers for an i3 user moving to Regolith?
So could you clarify for me, what's the relation between being a "tiling windows manager" and being light? Is it that for some technical reason one would expect tiling windows managers in general to be lighter than non-tiling? Or is it that orthogonally to the tiling aspect, i3 specifically aims to be light?
My non-expert take on this is that the sort of person who sees value in the efficiencies from using a tiling WM are also of a kind to use system resources efficiently too, even though they are orthogonal characteristics.
* space splitting for launcher * some sticky displays in multi-display desktops
There is also https://swaywm.org/ if someone thinks they should run wayland.
Something like WM2 is ultra low [1], but watch out if you're running a laptop as you won't get battery monitoring!
But I fully agree with your general sentiment that the best way to use Ubuntu is to go with the Server install and then adding only what you actually want on top of it. I've never had anything but a good and responsive system with that approach.
> fluxbox is highly active, but the last three news items on
> the fluxbox site are from 2015, 2008, and 2006,
> respectively.
Many of these projects are quite old, but still compile fine and are usable. WM2 for example still runs perfectly fine on top of X11.
> I've never had anything but a good and responsive system
> with that approach.
Fast and gives you an appreciation for what is needed for a functioning desktop.
It has been pointed out to me that this produces effectively a reskinned Windows98 experience, I'm not unhappy about that.
NB: Have not tried any 20.04 versions yet.
What about Debian? You staying on 14.04 for so long surely means that the slightly slower moving Debian stable is not an issue for you. It supports lots of window managers. I'm using i3 with a simple xinitrc here, but also XFCE or LXDE are available.
You can install it very very lightweight and as Ubuntu bases of Debian it should be similar enough.
I don't like my system constantly updating (and occasionally breaking) - esp secretly behind my back like snap/flatpak
but occasionally I do need the latest version of some package and i don't want to manage manually installations tucked away in some folder with random bashrc tweaks
This feature request shows some community interest in Debian support, but as far as I know, it hasn't gone anywhere yet. https://bugs.launchpad.net/launchpad/+bug/188564
I wish Debian offered its own equivalent of PPAs.
It is really not an issue in my experience. I currently have the following software installed (and updated) this way: docker, virtualbox, nodejs, yarn, skype, vscode, teamviewer and sublime text.
How behind Ubuntu is Debian, and where can I read this information myself (i.e. is there an official list by either the Debian or the Ubuntu people that says "here's all the stuff that the latest stable Debian is missing from the latest stable Ubuntu"?)
For instance, the current debian stable release entered freeze on 2019-01-12 and was finally released on 2019-07-06. [2]. This means that most software in stable is currently at the latest versions as of the end of 2018. Hence, up until the release announced today, debian stable had more recent (by around 1 year) software than Ubuntu LTS (18.04).
Now and until the next debian stable release (which should happen around summer next year) Ubuntu LTS (20.04) will have newer software than debian stable.
There are a few software packages that do have newer versions in Ubuntu because they are developed by canonical themselves. I can only remember LXC/LXD as examples of these.
I personally run Debian on my personal Desktop, and have no complaints about it at all.
But bigger picture my point was: Lubuntu's focus has changed, so it's not for me any more.
System requirements for Lubuntu 18.04 LTS included a minimum of 1 GB of RAM, although 2 GB was recommended for better performance, plus a Pentium 4, Pentium M, or AMD K8 CPU or newer.[139] The RAM requirements increased from Lubuntu 17.10.
Otherwise, go with a Debian or Devuan based distro like antiX, MX Linux, Q4OS Trinity, Refracta or EXE Linux.
You're going to be delighted.
I’ve been running Lubuntu 16.04 for the past three years but I recently thought I’d update my system. The options I boiled down to were either Debian (the parent and grandparent of so many distributions) or one of the successors to CrunchBang Linux (a light-weight distribution based around the Openbox window manager), BunsenLabs [1] or CrunchBang++ [2].
In the end, I decided that since it was only a few days to wait, I’d try the new LTS version of Lubuntu †. Apparently, its LXQt desktop is just as light as LXDE so I figured it’s worth trying out.
[1] https://www.bunsenlabs.org/
[2] https://crunchbangplusplus.org/
† Not available just yet according to https://wiki.ubuntu.com/FocalFossa/ReleaseNotes#Official_fla...
I forgot to mention in my post above that I had purchased an SSD a while ago and this is what prompted me to consider the available options for updating/changing the OS.
Other options worth looking at - Peppermint is okay (although their focus on web apps is a little odd), or LTS Ubuntu MATE using the minimal install option
Installation on a machine with 2Gb RAM resulted in a system that works just fine, for running scripts, compiling medium-sized projects, running web browsers, media playback, etc -- all on a credit-card sized machine.
The desktop is based on XFCE. The post-installation steps I took are listed below.
# emable swap to compressed RAM
sudo apt-get install zram-config
# log to RAM for speed, less wear on eMMC
echo "deb http://packages.azlux.fr/debian/ buster main" | sudo tee /etc/apt/sources.list.d/azlux.list
wget -qO - https://azlux.fr/repo.gpg.key | sudo apt-key add -
apt update
apt install log2ram
# remove icon generator that hogs machine
sudo apt remove --purge tumbler
# remove powerline garbage
sudo apt remove --purge powerline
# Liquorix kernel, see https://liquorix.net/
sudo add-apt-repository ppa:damentz/liquorix && sudo apt-get update
sudo apt-get install linux-image-liquorix-amd64 linux-headers-liquorix-amd64
## NEEDS linux-firmware from focal distro
## see https://packages.ubuntu.com/focal/all/linux-firmware/download
## for latest link
wget http://mirrors.kernel.org/ubuntu/pool/main/l/linux-firmware/linux-firmware_1.187_all.deb
sudo dpkg -i linux-firmware_1.187_all.deb
rm linux-firmware_1.187_all.deb
sudo apt install powertop iotop
# fix font rendering
cat <<'EOF' > ~/.fonts.conf
<!-- disable embedded bitmaps in fonts to fix Calibri, Cambria, etc. -->
<match target="font">
<edit mode="assign" name="embeddedbitmap"><bool>false</bool></edit>
</match>
EOF
# remove spectre mitigations, make computer fast again
sudo perl -pi.bk -e 's|splash"|splash mitigations=off"|' /etc/default/grub
sudo update-grub
# disable and completely remove AppArmor and snapd
# https://www.simplified.guide/ubuntu/remove-apparmor
sudo systemctl stop apparmor
sudo systemctl disable apparmor
sudo apt remove --purge apparmor snapd
# suppress this language related updates from apt-get
echo 'Acquire::Languages "none";' | sudo tee -a /etc/apt/apt.conf.d/00aptitude
# remove irqbalance
# see https://github.com/konkor/cpufreq/issues/48
sudo apt remove --purge irqbalanceThis time they've removed debian-installer, so it's no longer a matter of a new kernel/initrd/preseed file. On top of that, the automation has only appeared in the last few days.
I've only had 1 issue (other than it never remembering default audio devices which I set manually to resolve)
Snaps break all the time for me. I installed VS Code, after reboot I couldn't launch it, had to uninstall/reinstall. Fixed, reboot, broken. Installed it via terminal. 0 issues.
Same with Slack, Chrome, and Skype, and anything else I tried with Snaps.
Very happy with 20.04 so far.
So I've resorted to removing all the snap apps and installing them from terminal and no longer have any issues.
I'm not sure who the target audience is for Snaps.
This whole security thing is getting really annoying.
[0] https://askubuntu.com/questions/1184774/some-applications-on...
See https://www.python.org/dev/peps/pep-0394/ for details.
And no more including of PPAs of some developer whose apps seems nifty at first glance.
So far, there have been two real pain points: 1. Netplan is a mysterious friend who occasionally rearranges my furniture when I'm not looking. 2. Snap is a young kid who wants to make help me get groceries but borrow my car to drive to the store.
I'll leave netplan aside for a moment and focus on Snap.
I got 20.04 to fail badly under KVM using either the just released version or the nightly build because Snap fails. I can see exactly where it fails thanks to Python (cool). It's in an error handler for a UI view that's reading a property that doesn't exist and it hoses the install (ouch). It appears to be triggered because I was testing an odd network configuration.
Once something goes wrong, after that, every change just results in a one-line "apt-get fails" error message.
But consider the implications...
Canonical apparently doesn't have an automated testing system which checks how Snap behaves under failure conditions but they put it into the install process without protections around it. This feels pretty half baked....
I had to install the properitary NVidia drivers but it kept locking the entire machine, sometimes 30 seconds after booting, sometimes a few minutes. Took hours of restarting and trying to get the drivers installed before it would hang to get it stable.
Since getting them installed it's been solid.
I'd now like to upgrade to 20.04, but not if I need to go through the whole ordeal of racing to get drivers updated before the system crashes.
Ed: i would probably go straight for 20.04 on a fresh install - but heed sibling comment about nvidia drivers. Might run fine on open source drivers until proprietary ones gets an update (fine, but slow).
The biggest issue I can remember was weird issues with the graphics drivers a few times. Not quite sure exactly how it happened, but apparently I had a pretty wonky installion at first. I uninstalled and installed the nvidia drivers through `apt`.
Other than that, I have an unsolved problem of random, occasionally reboots, mostly which conveniently happen when I'm away from the PC. Everything goes back to normal after rebooting and it usually doesnt do it again for a while. I havent managed to solve this, but I'm assuming it's a rather localized problem.
For me; my Razer Nari wireless headphones just don't work. They're not bluetooth; they have their own low-latency USB receiver, and thus their own Razer-supplied drivers, which are not available on Linux. There's been some effort toward getting Razer products working better in Linux, but (last I ran Ubuntu, a few months ago) their headphones are not there yet.
You just have to try it out and see what works, see what doesn't. Chances are, it'll work fantastically for you.
I have no issues except for a driver issue for the audio chip on my mobo (Gigabyte Aorus Master TRX40) that seems to only affect optical audio out.
Cooling solution, RAM, and monitors aren't things that will have OS compatibility issues.
sleep: cannot read realtime clock: Invalid argument
$ sudo apt --fix-broken install
...
Setting up libc6:amd64 (2.31-0ubuntu9) ...
Checking for services that may need to be restarted...
Checking init scripts...
Nothing to restart.
sleep: cannot read realtime clock: Invalid argument
dpkg: error processing package libc6:amd64 (--configure):
installed libc6:amd64 package post-installation script subprocess returned error exit status 1
Update: After fixing that and upgrading everything, now I get this nonsense:
The following packages have been kept back:
libpython3.8 libpython3.8-dev libpython3.8-minimal python3.8 python3.8-minimal
$ sudo apt-get install --upgrade python3.8
...
The following packages have unmet dependencies:
python3.8 : Depends: python3.8-minimal (= 3.8.2-1+bionic1) but 3.8.2-1ubuntu1 is to be installed
Depends: libpython3.8-stdlib (= 3.8.2-1+bionic1) but 3.8.2-1ubuntu1 is to be installed
E: Unable to correct problems, you have held broken packages.
$ sudo apt-get install libpython3.8-stdlib
...
The following packages have unmet dependencies:
libpython3.8-stdlib : Depends: libffi6 (>= 3.0.4) but it is not installable
Depends: libreadline7 (>= 7.0~beta) but it is not installable
They do? I just assume that I have to do a backup of my data, wipe the disk and install they new version.
Ubuntu updates never worked for me.
As you said, server users always upgrade. Enterprise desktop users upgrade. A lot of general users don't - they reinstall.
The upgrade process you should use with Ubuntu is different to Debian. In Debian you'd use apt, in Ubuntu you should use the update manager. Update manager specifically checks for upgradability, it has specific warnings and workarounds that are added for each release following testing and reports from end-users. This makes it much easier to upgrade.
The reason why users think the Ubuntu upgrade process is less reliable compared to Debian is they serve different user segments. Most Debian users are technically advanced, engage with the distribution and they often stay in their stream (e.g. testing). Ubuntu is used by lots of normal users - many may not pay particular attention to how packaging works - this means they often do things that make upgrades complex: install community PPA's that advance packages past the next LTS version, install Node into /usr by wiping out apts package knowledge, etc, etc. The range is just bigger.
For many normal users upgrading may no longer be the best option - it's just faster to reinstall. I personally do upgrades, I still find them magical and it's part of the fun: http://www.futurile.net/resources/ubuntu-upgrades/
I upgraded by grepping for the packages that were breaking resolution and removing them. But I already know the failure mode so that whole thing took a few minutes.
I do have separate mounts for that reason though.
I do not use Linux on my desktop or notebook but I would like to do so in the near future. This means I should strive to keep all my user created data within the home directory at all times? How about program preferences and configs that get saved elsewhere by default?
I imagine having ZFS snapshots of / would be useful for updates going forward.
> This means I should strive to keep all my user created data within the home directory at all times?
Why would the user have privileges to save it outside of the home directory? :) Special cases like databases with storage in /var need to be handled separately.
Nothing goes (should go) elsewhere by default.
If you're wiping the distro and re-installing - you probably don't want to keep /etc anyway.
Fwiw Ubuntu in place lts to lts release upgrade should be solid. But sometimes you want start with new, contemporary defaults, or a different disk layout.
BTW with zfs, you can have a separate home (or home/your_user) filesystem, and not worry about allocating fixed space (thus running out of free space on /, but with more available in /home and vice-versa).
The closest it's ever come to failing was literally yesterday when I realized that my desktop was still on 19.04 and they had closed the old repositories so the GUI upgrade utility failed. The CLI upgrade didn't skip a beat, though.
Not fun with servers, unfortunately.
Microsoft is working on a patch, but until then, you need WSL 2 or stay on the previous release.
sudo do-release-upgrade -d
Does anyone know a robust way to get snapd running properly in WSL2? I would prefer to use whatever package there is than compiling everything that isn't packaged as .deb myself. In the case of ccls it's particularly annoying because I had to install the whole clang toolchain just to build it (which isn't typically on my dev machines, because the work I do is GCC-based).
Is it actually possible to buy an "official" USB/DVD of Ubuntu these days?
When I say buy I mean most of money would go to support Canonical.
There used to be such an option about 10 years ago but I guess there is very little demand.
The world has moved onto mostly online distributions.
For some reason I still do yearn for the world of "touchable" official software - the world of 6 foot long Borland C++ manuals.
PS One of honorable sources - https://www.osdisc.com/ - closed last August
Finally.
The feature is still experimental but has been working well for me during the beta period.
I rely strongly on this tool and would be sad to lose its functionality if everything becomes snap-based.
with rtlsdr (RTL2832U) plugged in, every process gets blocked
with nouveau, as soon as onboard HDMI (Intel) is connected, desktop becomes very sluggish and system locks up in a few minutes
I am impressed it works at all on release day. Previous LTS releases are hardly usable until LTS .03
Maybe in 2022.04 LTS then ...