Ubuntu Flavors Agree to Stop Using Flatpak
omgubuntu.co.uk
omgubuntu.co.uk
NixOS has official GUI installer now https://nixos.org/download.html#nixos-iso
Ubuntu has been making some interesting choices lately.
[0] https://forum.snapcraft.io/t/disabling-automatic-refresh-for...
I think OpenSUSE and Alpine have it in their repos as not-snaps now.
[1] https://wiki.debian.org/LXD
Interesting like the Chinese Curse...true ;)
https://en.wikipedia.org/wiki/May_you_live_in_interesting_ti...
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.
sed -e 's/agree/comply/g'
Debian has a lot of annoying defaults unfortunately so I always have to tweak it to suit my preferences. Still better than dealing with snaps though.
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 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.
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.
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.
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.
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()`.
https://developer.nvidia.com/blog/drop-in-acceleration-gnu-o...
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'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).
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.
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.)
#!/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"
fiIt's version 4.29.129. No idea if it updates itself.
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.
[0]: https://pop.system76.com/
[1]: https://blog.system76.com/post/more-on-cosmic-de-to-kick-off...
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?
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 do prefer RPMs, though.)
Yayy!!!
> And to focus their efforts exclusively on deb,
Yayyy!!!
> and snap.
... oh.
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).
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.
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.
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.
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.
* 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.
This is no longer true. You can disable updates for a snap indefinitely:
https://snapcraft.io/docs/keeping-snaps-up-to-date#heading--...
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.
Acknowledged and being fixed.
Thanks, good to know. I had this issue with Bitwarden. I'm testing it now and it seems to be much faster than some weeks ago so that's nice.
Part of the design, snaps are a compressed disk image that has to be decompressed the first time it's started after a reboot.
I prefer stability over novelty, thus the transition was nearly transparent for me.
(to use firefox without snap, I wrote the instructions here: https://ploum.net/2022-04-05-firefox-ubuntu.html )
>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.
https://www.reddit.com/r/Ubuntu/comments/118w7hb/ubuntu_flav...
https://discourse.ubuntu.com/t/ubuntu-flavor-packaging-defau...
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 don't know why they'd follow Ubuntu, as long as the Canonical philosophy exists in this space, Linux will never grow an inch.
I'm thankful to canonical for bringing Ubuntu where it is today but let's be honest, they've constantly been making weird decisions.
Please stop and go take a look at ZorinOS, that's what a mainstream distro should look like!
It's ridiculous and the complete wrong way to survive in the the Opensource space. The only thing they have at that point is the name Ubuntu.
Suse does not use dnf and in fact libsolv was originally written by Suse and only then adopted by RH.
I just don't see how RH forces them on anybody that isn't a user of Fedora, RHEL and derivatives.
So yeah totally on your side here.
No it means a ->approximation<- of what Google and Apple is doing -> Snapstore/Appstore
Literally the first line of the article says they are official Ubuntu flavors:
>Flatpak will no longer be available “out-of-the-box” in any of Ubuntu’s official flavors.
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.