A few days ago I wanted to update an Ubuntu laptop that hasn't been turned on for over a year. I had steam and brave browser installed using snap. Updating these two took as much time as updating everything else in the system (1.6Gb of downloads). Then I uninstalled brave, which took about 6-8 minutes. The laptop has NixOS today.
I found lxd very appealing in the beginning, but when they favoured snap as distribution channel, where, apparently, updates and restarts could only be blocked using the firewall [0], I moved away from it. And Ubuntu in general.
Honestly, I could have packaged it myself, but it eroded my trust in the ecosystem. They seem to target a different use case. Which is fine by me, I just won't be in for the ride.
Not true any longer. Debian has been officially [1] supporting LXD Debian packages [2] since September last year. And you can add this APT repo [3] — which follows the same Debian recipes - into your sources.list to install LXD natively with APT.
Yeah updating flatpaks on the Steam Deck takes ages, and because of the way the SteamOS is set up - you really are incentivized to use flatpaks over actual packages (which could break with updates).
Updating Flatpaks takes a few seconds. The standard Discover application that comes with the KDE desktop environment is awfully slow, though.
Running flatpak update or whatever the exact command line is in the terminal will be much faster than trying to go through the GUI. I've seen this happen before on a Kubuntu install and on an Arch VM, I think it may just be a Discover bug.
which kind of packs takes ages. I don't have this issue. There is no could break with updates. It is they will be wiped by an update. Install packages with distrobox.
I think Steam specifically does quite a bit more complicated stuff that can affect the rest of the system just to support games than most other pieces of software. It has its own built-in update mechanism, which I think makes it one of the few pieces of software I'd avoid using the package manager for.
Not too surprising to see that these changes were the result of coercion from Canonical. I don't know why any FOSS distro maintainer would voluntarily stop including Flatpak (which supports multiple repos and has FOSS server and client implementations) only to replace it with Snap (which only supports Canonical's closed source Snap Store server).
I switched to Arch a few years ago and I regret not having done it sooner.
All the things I was assuming about stability being a problem or having to muck around with complex settings, were all wrong. It works extremely well. My OS and all my apps update once a day - no reboots, no loaders. The AUR is great.
When I use my macbook or boot into windows the user experience feels outdated by comparison.
I always hear this and really want to jump in, and then I wasted a full week trying to get Arch to dual-boot on my Framework laptop and just couldn't get it to work. The Arch wiki installation instructions regularly were out of date with the current installer and told you to use flags that didn't exist when setting up your disks.
I assume I'd love it once I got it installed, but for everything I hear about how good the AUR and the Arch Wiki are, it's been nothing but trash to get set up in my multiple attempts.
That's true, it was hard so set it up the first time and get all the details right. However, since then, my Arch Boxes have been an absolute breeze to work with (and my history includes Suse, Debian, Ubuntu, Gentoo, even LFS, ...)
Installation when you're not working from a completely bare hard drive seems to stymie so many Linux distros. I keep finding myself back on Ubuntu and Fedora because they seem to be the only two that put any effort at all into making sure you can dual-boot without spending hours reading manpages and hoping a wrong flag won't destroy your bootloader and other OS.
Was the problem specific to dual booting? I booted off the USB and installed GRUB. I've had issues with dual booting too occasionally, but most seem to be caused by Windows
The issue was more around me already having a bootloader and boot partition set up (rEFInd) that worked fine, but trying to get Arch to be bootable from that pre-existing one while still setting up swap and the other partitions it wanted.
I also spent a really long time dealing with the fact that my motherboard clock was out of sync, so when I was setting up pacman, it couldn't validate certs because of the clock issue, but not being able to install packages made it really hard to fix the clock sync issue.
I've been curious about that. Any time I ask about it, a lot of Arch folks come out to explain why Manjaro is terrible and makes all kinds of bad choices similar to the ones TFA is about. How much of that is real vs. overblown purism about Arch?
If you want Arch with a simple installer, use EndeavourOS.
Manjaro has a history of DDoSing the AUR, letting various website certs expire multiple times and holding back any package updates for two weeks (even security updates), but also shipping WIP github patches without notifying users properly.
Yea, that's an interesting lead. I only just learned about Endeavor today but may give it a try. In theory, I really like the idea of the pure "build it yourself" of Arch, but when the docs aren't good enough to get a professional developer through doing it correctly in under 10 hours, I'm not sure what to do. Kernel/Driver stuff isn't my forte, but if your target user has to be, that's rough.
That mostly aligns to what I'd hear about Manjaro before. I'd successfully installed it before, but when part of the point of Arch is how good the AUR/Pacman is, hearing that it seems to mess up both of those is a big turnoff.
As a computational biologist, I've been struggling with performance issues on Ubuntu for months, which have made it difficult to work efficiently. Despite Ubuntu's popularity in academia, R runs much slower on Ubuntu than on my personal computer running Arch. This has forced me to do my work at home, where I have better performance. It's disappointing that Ubuntu's limitations are often assumed to be universal to Linux in academia, which can be a problem for those who require a more efficient system. I've tried troubleshooting the issue, but haven't found a solution yet, but just chock it up to Ubuntu just being more and more terrible
> I've tried troubleshooting the issue, but haven't found a solution yet
That is very strange. I assume you’re not using the same hardware in your home computer. Without knowing your setup, it’s hard to say anything. Are you using the same BLAS and LAPACK libraries? You can check with `sessionInfo()`.
I read about it before.[1] There is also a BLAS library made by Nvidia that makes use of CUDA. This post is about how to hook it up to GNU Octave but it also works with R:
What sibling says about compiling R on your work computer so that it can make full use of your CPU can help too. I am curious if that closes the performance gap for you.
I’ll give it a shot when I make it back to campus. I’m snowed in at home, but I’ll let you know soon. Also, this really does look like the issue. Thanks for the insightful comments.
These tips speed up my Arch Linux R even more, but my Ubuntu setup is still just as slow, even with these optimizations. Somewhere along the journey I did see that Xeons have problems with R, but I can't seem to find where I saw that. Darn.
I've personally tried building the software I need for source before, but getting all the BLAS/LAPACK and MPI libraries with it has been annoying and time consuming. Your supercomputer cluster may offer pre-built optimized binaries for your CPU. For mine, I've been using prebuilt software offered by compute canada over CVMFS[1]. I assume something similar is available for wherever you get your supercomputing resources from.
> I've been struggling with performance issues on Ubuntu for months
I've run Ubuntu on various hardware and in VM's since 2006 running a wide variety of applications, there are no performance issues I've seen. Perhaps R is different to all other software I've run (which is a lot).
I think the Linux Desktop community needs to stop promoting Ubuntu as the "default" distribution. In 2008 it was certainly the obvious choice, but anymore Canonical seems to have done their best to burn any goodwill they generated back then.
Of course, that means picking a new "default". Personally, I think SteamOS v3 might end up being a great choice, should it ever be officially released for general consumption. But until that happens my personal favorite is Fedora Kinoite.
This made me even more happy to have moved to Debian 11 after 14 years of Ubuntu. Snap made me sick, then this. Not that I ever used Flatpack, apt and docker are good enough, but this is too much.
Yeah, I go back and forth between Ubuntu and Debian on various machines and I usually hardly notice the difference in terms of my day-to-day. I just have in the past treated Ubuntu as a Debian with a fancier installer and default desktop. But the push towards snap is frustrating me.
Unfortunately Ubuntu pushing Snap means that 3rd parties that would have produced debian-compatible packages before are now moving to just shipping snaps instead.
e.g. I went to install Slack the other day and saw they only have RPM and Snap options now, they removed the deb entirely from their site (but still mention it in their Linux-install instructions).
(And yeah, this could push me to the end of my 25+ years of debian usage, I could be tempted to switch over to NixOS.)
Slack still has .deb files you just need to scroll down and find the small button for it. https://slack.com/intl/en-gb/downloads/linux search for "Download .DEB app". Last I checked they also have an Ubuntu only dependency that has a Debian equivalent but they don't list it so it won't install unless you modify the dependency list. I used the following script to do so, but I haven't updated in a while.
#!/bin/sh
if [ "$#" -eq 1 ]; then\
tmp_dir="$(mktemp -d)"
dpkg-deb -R "$1" "${tmp_dir}" && sed -i 's/libappindicator3-1/libayatana-appindicator3-1/g' "${tmp_dir}/DEBIAN/control" && dpkg-deb -b "${tmp_dir}" slack-fixed.deb
else
echo "Read it"
fi
In terms of packages, Pop!_OS has the flatpak over Snap, which I believe is not installed by default. Their distro is also known for a brand new tiling window manager on top of GNOME [0]. They have also recently made a notable contribution to improving the "Linux on the desktop" experience (e.g. [1]).
I would not oversimplify it as just "repo added on top". For many years we could say the same about Ubuntu and Debian, but I don't agree with this generalisation.
It may walk like a duck, but if it doesn't quack like a duck, it might not be a duck.
What does that even mean? Is Ubuntu just Debian with another repo on top? Either way, it doesn't change the fact that Pop ships with different functionality and is controlled by a different company that has made a lot fewer user-hostile choices than Canonical in recent years.
Ubuntu tends to fork Debian's unstable branch then freeze it, patch it, rebuild it and call it their own. Pop_OS! is simply adding some software on top of Ubuntu.
If Debian makes a change, Ubuntu is unaffected until they resync. They then have time to patch it and test. If Ubuntu changes a package, that change is immediate in Pop_OS! unless they ship their own version of the package.
I agree that Pop_OS! is doing a great job with their DE modifications and other defaults, but I don't view that as them being in control. Unless a lot has changed since I used it last, Ubuntu and their infrastructure is still building most of the distribution.
A lot of this is really where you want to draw lines in the sand. What makes a distro a distro and not just another derivative?
Unlike Ubuntu, Pop doesn't really have full control over their users' experience, because their users are configured to consume directly from Ubuntu's repositories.
They are clearly trying to build a walled garden. The Pro stuff, making security package updates subscriber-first, clearly makes everyone else a target.
I can see why they are doing it, commercially, but it seems misguided. There are so many other ways they could bring value for corporate customers without trying to copy Apple/Microsoft/Red Hat.
I really wish Pop!_Os were based on Arch. I like the UI improvements and such that they've made, but I haven't had a good experience whenever I need to install something or update the system.
Well, Ubuntu got me to move to Fedora because of their decision to ship Firefox as a snap, so… I guess they’ll just keep losing desktop users, because Flatpak has been a vastly superior experience to snaps in almost every way.
Me too! I've been really impressed with Fedora's performance and stability. I haven't had to spend any time configuring it since I installed it. It just works.
Honestly I avoid flatpak/snap/etc like the plague. Every time I've used them, some sort of device or file can't be accessed, or something isn't working. If I need anything that isn't covered by apt repositories, I just compile from source now, and have my own system for detecting updates which works pretty well. (https://github.com/tpapastylianou/misc-updater if anyone's interested).
On the other hand, I repeatedly recommend that ordinary users do not install software from third party apt repositories unless they really really have to.
Fundamentally they're a hack, don't work right, and often result in latent packaging problems that cause future release upgrades to explode. People then unfortunately attribute those failures to the distribution rather than the broken hacks they themselves installed from third parties.
It is fundamentally impossible for a third party deb to correctly declare the necessary metadata to avoid breakages on a future upgrade. In distribution packaging this kind of thing is dealt with in metadata provided by the distribution packages being upgraded to, but third party debs don't have that luxury, even when using a third party apt repository. For example, a "Breaks" metadata declaration can only declared from one direction, so if a newer distribution package Breaks a third party package, then it cannot be declared on the third party side so ends up just not getting declared, resulting in breakage.
So apt/deb only really works in the curated distribution model where all your software comes from the distribution.
This doesn't work when users want software newer than their distribution release, or want to install proprietary software that cannot be curated by a Free Software distribution.
Further, third party debs have root on your system, which is terrible for modern security. Installing software from third party sources which aren't sandboxed should really be unacceptable from a security perspective nowadays. For example: do you really want some game to have access to your online banking session? How secure is that game's development infrastructure that will stop a bad update from resulting in you losing money?
On the other hand Snaps and Flatpaks actually provide app sandboxing.
That's the use case for these packaging formats. If you don't need them yourself, then that's fine. But it's disingenuous to declare that there's no need for them.
> But it's disingenuous to declare that there's no need for them
I didn't say there is no need for them. They are just horrible solutions.
> I repeatedly recommend that ordinary users do not install software from third party apt repositories unless they really really have to
Fair enough, I wasn't making the case for third-party repositories specifically; I was indeed making the case for distribution-curated repositories.
In general if a version of a particular piece of software in the distribution's curated repository is older than the version I require, what I'm saying is that I will generally go to the project's website "a la windows style", and either download whatever binary they provide, or preferably if possible compile from source. My misc-updates package then simply checks for available updates, which is the main functionality missing when manually installing packages.
Obviously this may not be the best solution for everyone else, but for my own needs I found it far more functional and usable than either flatpak or snap.
> what I'm saying is that I will generally go to the project's website "a la windows style", and either download whatever binary they provide, or preferably if possible compile from source.
That is dangerous from a security perspective though. That third party binary, or your built binary, has permission to everything your user can, including exfiltration of your online banking sessions and so on. That's not appropriate in the modern computing environment. Apps that haven't otherwise been curated really need to be sandboxed, and if you have to go out of your way to arrange a sandboxed environment, well, that's what snaps do out-of-the-box, and we can't expect users to be able to stand that up manually any more than we can expect them to compile from source.
This. I cannot stand that an app comes bundled with it's own os. I already have an os, and I only use containers and vms when I specifically need to.
The sales pitch advantages exist, but are not more valuable than the disadvantages.
If an app has such an insane build setup that the only possible way to ship the app is just ship the entire system, then the problem is the developers of that app, and perhaps it's only correct that people just avoid that app in favor of one that is built more thoughtfully, instead of papering over and hiding the hideous spaghetti monster by stuffing the whole mess into a box and pretending the box is the app.
It's a response to a problem, it's just a shit response.
What about "it's easier for developers to ship updates"?
I do no want every random developer who are mostly none of them thoughtful systems engineers and integrators to be able to update my system. I'll pull down the same updates from their git or my distro, and in either case have some form of downstream sanity check rather than give them essentially a key to my system that I wouldn't have given any other rando. Also this plea of being easier for developers to ship is akin to "everything would be much smoother and more efficient if everyone else would just do what I say" It would be, for them, but I'm not sympathetic that tgey can't be assed to make their software generic and portable.
I speak these opinions as all 3 of user, sysadmin, developer myself.
A bundled system is fine for a reference implementation, not something you're supposed to require every user to run in a container.
Docker snap is basically broken out of the box and you need to uninstall it and install a Docker deb from Docker itself to get a working Docker installation. (Insert facepalm)
Personally, I'm not a fan of the way Canonical have integrated snaps into apt without complete transparency, i.e. you can be running along not even aware of what's going on under the covers, which seems like a bad idea for everyone from sysops to devops to devs. Is there anyone running Ubuntu that wants a package running transparently under the covers without knowing what's actually going on?
Isn't it possible to improve Snap? What are the blocking points?
- Apps installed as Snaps are slow to start-up. Why?
- Snap from time to time asks to close a Snap-installed app to be able to update and often it seems it cannot update anyway. What is going on with this?
Another issue with Snap is that it is locked to Canonical's closed source Snap Store server. Canonical can start fixing Snap by releasing the Snap Store server source code under a FOSS license and supporting multiple software sources in the Snap client. It makes no sense for the FOSS Linux ecosystem to regress to a system in which software is obtained from a single proprietary app store controlled by a single company.
* The infamous forced updates are a business decision, not a technical one. Canonical took a page from Microsoft by taking control away from the user only to sell it back in an "enterprise" edition of the product (see their Brand stores).
* Applications installed as snaps are slow to start up because they are always stored in compressed form and must be decompressed to run.
I don't understand what technical limitation prevents Snap from installing newer versions of an application in parallel with the old one, like how Flatpak updates work.
> * The infamous forced updates are a business decision, not a technical one. Canonical took a page from Microsoft by taking control away from the user only to sell it back in an "enterprise" edition of the product (see their Brand stores).
This is no longer true. You can disable updates for a snap indefinitely:
> Apps installed as Snaps are slow to start-up. Why?
Apparently this is fixed, though I think only on new snap package builds. Benchmarks are available that demonstrate that slow snap load times are no longer an issue (but the grapevine persists in saying that it is).
> Snap from time to time asks to close a Snap-installed app to be able to update and often it seems it cannot update anyway.
That's only part of the story. There's other reasons, many of which have been improved over the years. For example the font cache would be generated on first launch, which was a slow operation. This was moved to happen when the snap is installed, which meant the install took longer, but first launch was much faster. For me, today, the Firefox snap and the Firefox deb take pretty much exactly the same amount of time.
And don’t forget to first uninstall every snap correctly and be sure that every snap virtual disks is unmounted else you will be left with random undeletable crap on your hard disk.
For what's it's worth, here's some more context from a canonical employee:
>This post has been flaired "misleading title" because it implies that Ubuntu is removing support for Flatpak software.
>Instead, Ubuntu and Ubuntu flavors are focusing on a single, out-of-the-box experience for users: Ubuntu and flavors provide Debian packages and snap packages, and any deb or snap package provided in a default install has been built on the same Canonical infrastructure used to build Ubuntu itself. This sets an expectation for what users can expect Canonical and Ubuntu to support.
>Flatpak support is available in the Ubuntu repositories as an optional experience, and any user who wants to work with Flatpaks can run sudo apt install flatpak in a terminal and have full access to the tools necessary to work with Flatpaks. This is and will not be installed by default, but Ubuntu has committed to maintaining it in the universe repository.
>I was present when the flavor leads met to discuss this change (among quite a few others to unify the Ubuntu experience across flavors), and this was something that they all felt could be a positive change. It was not a requirement from Canonical. The only mandate from Canonical was that they committed to maintaining the flatpak package as an opt-in choice for users. The rest of the meeting was focused on fun things like the new Flutter-based installer and flavors coordinating what projects they were working on that could be coordinated together to maximize their efforts.
>Ubuntu cannot support third-party software, be it via source code, tarball, PPA, Flatpak, or AppImage. An out-of-the-box install will focus on Debian packages and snap packages. Tools to work with source code, tarballs, PPAs, Flatpaks, and AppImages are part of the Ubuntu repositories and are simple to enable if you wish to use them, and that's part of what makes Ubuntu adaptable for your computing needs.
>An official statement (that I provided feedback on) is available here.
Which I guess makes sense, but I'm wondering how (if?) they were supporting flatpack before this announcement if Ubuntu doesn't usually support 3rd party software.
I see Canonical as a slightly worse Red Hat - they both do their own thing for the sake of it being theirs (NIH syndrome to the max), Canonical just occasionally use a proprietary component as an upsell (compared to Red Hat that rely only on an Enterprise sticker as a differentiator). But fundamentally, what exactly is the difference? Both force their newly decided stuff on everyone and all associated distros - be it systemd, podman, dnf, regardless if it's ready or not (podman is still not feature compete with docker, and has regular breaking changes making it hard to for associated tooling to keep up, but it is forced down everyone's throats regardless).
What was being asked is whether you're aware that the correct term is "walled garden" (and saying "wallet-garden" as a play on words), or if "wallet-garden" is a mondegreen[1] for you (also recently referred to as a "bone apple tea" thanks to the popularity of a certain subreddit[2]).
Official flavor does not mean that canonical is having a separate special team for them. Official distros also include Ubuntu Unity and other community maintained distros.
NixOS has official GUI installer now https://nixos.org/download.html#nixos-iso