New 'Ubuntu Flatpak Remix' Has (Unofficial) Flatpak Support Preinstalled (9to5linux.com) 37
An anonymous reader shares this report from 9to5Linux:
After Canonical's announcement that future Ubuntu releases won't include Flatpak support by default, someone already made an unofficial Ubuntu flavor that ships with support for Flatpak apps preinstalled and working out of the box, called Ubuntu Flatpak Remix.
Meet Ubuntu Flatpak Remix, an unofficial Ubuntu derivative that doesn't feature support for Snap apps and comes with support for Flatpak apps working out of the box. Several key apps are preinstalled in the Flatpak format rather than as a Snap app, including the Mozilla Firefox web browser, Mozilla Thunderbird email client, and LibreOffice office suite.... Support for the Flathub portal is installed as well, so you'll be able to install more apps with just a few clicks.
Meet Ubuntu Flatpak Remix, an unofficial Ubuntu derivative that doesn't feature support for Snap apps and comes with support for Flatpak apps working out of the box. Several key apps are preinstalled in the Flatpak format rather than as a Snap app, including the Mozilla Firefox web browser, Mozilla Thunderbird email client, and LibreOffice office suite.... Support for the Flathub portal is installed as well, so you'll be able to install more apps with just a few clicks.
Why a new distro? (Score:4)
All you need to do is:
apt install flatpak
That's all. What's the big deal?
Re: (Score:1)
Or just use debian and that snapd shit isn't installed by default.
Re: (Score:2)
But Flatpack may be. Try installing something like gedit on a host with no desktop and see what else gets installed...
Before you ask, I accessed that one over X from somewhere else. This was supposed to be a bare host but had some configuration to do so I thought gedit might make life easier. Nope.
Re:Why a new distro? (Score:5, Interesting)
>"That's all. What's the big deal?"
The big deal is that they are, AGAIN, pushing their own somewhat semi-proprietary environment, showing hostility to other formats. Plus, that roadmap of hostility is likely to take the form of nonsense- like not offering native packages. Many see this as a rerun of Mir and Unity...
Snap is a single point of failure (Score:2)
Snap, included with Ubuntu, is structured to have one global Snap Store whose application review process and hosting infrastructure are single points of failure for Snap developers and users. Flatpak, by contrast, is designed to have Flathub coexist with other stores.
Re: (Score:1)
Re: Why a new distro? (Score:2)
It seems a weird strategy to counter snaps though.
Ubuntu as a distribution is basically working towards being nothing but snaps. So a downstream distribution going away from snaps is getting less and less value as Ubuntu deletes non snap content.
So why bother starting from Ubuntu versus Debian? Before it was to leverage their cadence in bringing in Debian testing packages on a more desirable cadence, but with Ubuntu deleting more and more Debs and replacing them with stubs to install snaps, its just more
Re: (Score:2)
Which may be compelling if you want to go the snap way. But if explicitly not going the snap way as a distribution, then your upstream would be a bit anemic and you are having to provide your own maintenance for a lot of stuff during the desired LTS window anyway. That is my point that the non-snap part of Ubuntu is inadequate and unless Canonical changes their mind, it will only get less adequate with time.
Re: (Score:2)
>"So why bother starting from Ubuntu versus Debian?"
That is why Mint is already starting the process of re-basing.
https://linuxmint.com/download... [linuxmint.com]
Re: (Score:2)
Depends on your definition of "disappear" I guess - given "Its goal is to ensure Linux Mint can continue to deliver the same user experience if Ubuntu was ever to disappear." - if Ubuntu goes wholly Snap-based (or significantly enough to affect the ability to build Mint at all) then does that count?
Re: (Score:2)
Re: (Score:2)
and it has all the disadvantages that shipping half an operating system would have - multiple copies of libraries in RAM, massive storage use increases, artificial walls between applications that may on occasion need to work together, etc.
I don't know about snaps, but I looked into flatpack for possibly packaging some things. They actually address the multiplied libraries concern, and how they did it probably ALSO addresses the binaries that need to cross communicate.
One advantage of flatpack is if there are a whole bunch of apps from the same developer you can install a single "runtime library" flatpack. You install say the KDE runtime library, and any KDE binary flatpack gets all of its libraries from that runtime flatpack.
That means it's
Re:Why a new distro? (Score:4, Informative)
All you need to do is: apt install flatpak
That's all. What's the big deal?
It looks like the "big deal" is that is *doesn't* come with Snap support/apps baked in, like in the stock Ubuntu flavors where several application are only available via snaps -- like Firefox, Gnome, Emacs, etc ...
Ubuntu derivative that doesn't feature support for Snap apps ...
Personally, I'm not a fan of Snap (or Flatpak, AppImage either) and my next Linux upgrade will be to Mint which also doesn't have Snap forced upon you. Unfortunately, it seems that Authy for Linux is delivered as a Snap (fucking sigh), so I may have to install it anyway for that. Debian is my second choice, but the standard baseline is slow to progress...
Major apps should not be containerized (Score:5, Insightful)
>"Meet Ubuntu Flatpak Remix, an unofficial Ubuntu derivative that doesn't feature support for Snap apps and comes with [...] preinstalled in the Flatpak format [...] Mozilla Firefox web browser, Mozilla Thunderbird email client, and LibreOffice office suite"
Or you could use Linux Mint (or some other distro) and have Flatpak support *and* proper, native packages for Firefox, Thunderbird, and LibreOffice "preinstalled". It is mostly ridiculous for the default to use any container formats for the major/main applications in the distro. You end up with tons of wasted disk space (and backup space) and/or wasted RAM, and/or security "gotchas", and/or lower performance, and/or configuration complications.
Things like Flatpak/Snap/Appimage are more appropriate for fringe or third-party applications. Just because a tool is useful in some cases, and "neat" in others, doesn't mean it is a great idea to build everything else around it.
Re: (Score:2)
I agree. I run Ubuntu with Snaps disabled, Flatpak enabled, and I take a "PPA > Flatpack" approach.
Re: (Score:2)
I think flatpak has it backwards. Compile in the container, then static compile all non-glibc libraries/deps. There, now you just distribute the binary and you're good. If you MUST have an installer, don't use overly complicated crap like RPM or DEB, instead use something dead simple like makeself. Unless you used a pile of shit language like Java that requires a fat runtime, in which case you just plain fucked up. AOT compile that shit, or better yet, get rid of it.
Re: (Score:2)
Flatpak has been discarded by every major distributor. Why spend time preserving an unpopular fad?
Re: Major apps should not be containerized (Score:3)
As far as I've seen, the only distributions to discard flatpak were the ones you by Ubuntu that they can't do flatpak anymore.
If the ecosystem demands either snap or flatpak, I'd rather see flatpak. My ideal is usually traditional packaging with apt or yum repositories.
Re: (Score:2)
Debian Stable/Testing focus on LTS stability, e.g with ESR releases of Firefox.
As you point out, Mint build their own 'upstream' pool of bleeding edge, something Ubuntu are reluctant to maintain.
In any case, I am not sure why a new derivative distro is required when Snap and flatpak are both options for Debian:
https://wiki.debian.org/Firefo... [debian.org]
Re: Major apps should not be containerized (Score:2)
For flatpak and snap, they do at least preserve the idea of common, shared dependency layers. Constructed sanely, multiple gnome based flatpaks will share common dependency in a layer. In this way it's just a bit less awkward to have coinstalled applications based on different generations of dependency with poor versioning in the filesystem. Properly disciplined c libraries can be coinstalled, but most other content is not so well equipped
Contrast with docker/podman/k8s where images are always hopelessly
Ubuntu is a services company now (Score:3, Interesting)
Ubuntu is now in the service business. Yes, the client is open source, but you need to pay up for actually using enterprise software.
I don't entirely fault them. They still give something to the community. However they also steer you into their service subscriptions.
Want to enable multi-user access in MAAS? Candid is right there.
Live patching? Subscription
Access to long term patch support? Subscription
Don't want to pay, and want a custom setup? You need to spend time veering off default path.
Re: (Score:2)
Live patching? Subscription
Access to long term patch support? Subscription
From what I recall unless you're a corporate multi-seat customer both of those subscriptions are "free". But yes I do get your point.
Re: (Score:2)
For how long? The first taste is always free.
Re: Ubuntu is a services company now (Score:1)
Great idea (Score:4, Insightful)
Replacing Canonical's terrible system with gnome's even worse one that explicitly doesn't even work on servers, and will doubtless become gnome-only and/or systemd-dependent as soon as they think they can get away with it, isn't really progress. Good thing there are so many Linux desktops out there to take advantage of this wonderful new packaging format that only occupies 10x-20x the disk space of a .deb...
"Less bad than snap, in some ways, sort of" is a pretty low bar to clear, but Flatpak only barely manages even that - despite what is now well over a decade of prior art showing how to solve the problem competently. When your "solution" to something is objectively outclassed on every front by freaking Windows, you've managed to screw up to a truly impressive degree.
Ego-driven development and attempts to create ecosystem lock-in are bad enough for users as it is, but failing hopelessly in even the most basic technical aspects on top of that is both user-hostile *and* farcical. It's not stopping either IBM or Canonical at this point though, so apparently we might as well get used to the idea. "Non-conforming" distros will be buried by the maintenance burden once IBM "persuades" enough project maintainers to only produce .fku or whatever in the first place, just as they were by the "it's only an init system, and anyway, it's modular" shenanigans.
(For anyone academically curious how to handle "app packaging" reasonably well, take a look at Nix; or SxS; or, given the audience here, think about apt for about 15 seconds and you'll probably work it out yourself).
Re: (Score:2)
>"Non-conforming" distros will be buried by the maintenance burden once IBM "persuades" enough project maintainers to only produce .fku or whatever in the first place, just as they were by the "it's only an init system, and anyway, it's modular" shenanigans.
+1 Bingo.....
Re: (Score:1)
I agree with the sentiment that we could do better than Snap or Flatpak, and Nix is a technical inspiration. But Nix is 20 years old and has minimal adoption, whereas Flatpak has added a small city’s worth of users in the last year through the Steam Deck alone.
I think it’s useful to compare with a category where “good” package managers have already lost: servers. When I look at r/selfhosted [reddit.com] almost everyone is using Docker. Developers love using Docker for their own server applicati
I've been living under a rock... (Score:2)
... so I had no idea about this controversy. I found this two-year old page has some useful background on why flatpak is dumb: Flatpak is not the future [ludocode.com]
If even half of what the linked article says is true then I don't see how these package installers ever got any traction, even inside the companies that spawned them.
Re: (Score:3)
One word answer to your question:
Laziness
(But, seriously, there ARE cases where containers make a lot of sense. However, not as a replacement for mainline native packages).
AppImage (Score:1)
KCalc AppImage is 152 MB (Score:2)
Just use AppImages: a) they don't clutter your system
"Flatpak Is Not the Future" [ludocode.com] states that KCalc in AppImage form has a 152 MB file size. How is that not clutter?
Re: (Score:2)
Because the equivalent is to ap-get install KCalc and pull in several GB of KDE+libraries+any other dependencies, because your distro marked them all as interdependent? 99% of which aren't actually needed to run KCalc...
Seriously, if you only want a SINGLE application, a couple hundred MB is a lot cheaper than pulling in all the shared libs even. Why install all of KDE just for KCalc? Or Kate? Or any single KDE application that you personally might find works better than stand alone alternatives.
Linux (Score:2)