Flathub could become the killer "app" for the Linux desktop. No need to juggle dependencies and third party repos. The software you need in an instant.
I agree that it is "yet another standard", but I gotta say that Flatpak is pretty sweet, and does actually do a good job of making "one package manager to rule them all".
I think part of the problem with a lot of "selling stuff on Linux" has been mucking around with different dependencies for the thousand different versions of Linux.
Historically, this has led to a couple solutions: either a) Just officially support one distro (usually Ubuntu), or b) just don't release a Linux version.
Flatpak has actually succeeded in making a system that kind of works everywhere, and I think it actually has a shot of being an equivalent to the Mac App Store.
> and I think it actually has a shot of being an equivalent to the Mac App Store.
This I agree with, but not this:
> and does actually do a good job of making "one package manager to rule them all".
That's not its goal. There are no terminal apps in it, so everyone that wants to run custom packages from a terminal is still going to need something like apt/dnf/homebrew.
Maybe I'm speaking a bit too broadly; at least in regards to GUI apps, it's been a pretty nice "unifying force" for me when I ran Linux (which has admittedly hasn't been a few years now).
Is there an actual technical limitation or just because of the binary naming convention? I ask because some of the flatpak apps I have installed I almost always run via the command line by putting "/var/lib/flatpak/exports/bin" in my path and aliasing to the long name, ie: "alias evince=org.gnome.Evince" and they seem to work fine.
As a web developer currently working on a Debian laptop I don't know which software I would want to buy if I was using Windows or a Mac. Everything I was using for free to do this job with Windows in 2008 was also available on Linux for free, that's why I moved to Ubuntu in 2009. I never had to buy any software in all these years but maybe my use cases are pretty simple.
Flatpak is actually made by the same groups of people who make these open source DEs, as well as the various open source stacks we use on the desktop, it’s had the advantage that it’s integration into the desktop is decent and quite cool (hello pipewire).
Regardless of your opinions of GNOME and KDE, it’s hard to argue Flatpak has anything but good intentions, it’s made by people who want the Linux desktop to be better
I am reminded of that one game dev who dropped Linux support because 99% of their bug reports were coming from 1% of their total playerbase (read: the Linux crowd).
It's the closest thing to APKs for Linux. We need an Android for desktop: a signed base image with silo'd applications, application data, and granular permissions.
There's a project called ublue-os (https://ublue.it/) based on Fedora Silverblue & co (rpm-ostree based 'immutable' Fedora variants). It's building signed base images with Nvidia drivers, autoupdates, etc.
You can fork the base repository and just add the packages you want to have installed on your host system. Everything else is handled with flatpaks or with distrobox containers, or you could technically install whatever else package management system you wanted to.
I completely know what you are talking about, I’m used to the Software app virtually never working, although I came back a few months ago and it all seemed to be working perfectly fine. So perhaps there have been some major improvements in this space. At any rate, the problem is not unsolvable, it was mostly just bad UX where underlying errors were not surfaced and the app would get stuck in an endless loading spinner.
Perfectly true, and my comment was the kind of irritated snark about imperfect open source software that I don't like hearing from other people! It just so happened that I had launched Software literally about 5 minutes previously for the first time in months and it .. sat there and did nothing.
I do think it's a good idea though, at least while we have this hopefully transitional period of multiple overlapping packaging/update systems. I get a bit tired of having to think in terms of flatpack and dnf and asdf and cargo and pnpm and .. not to mention all the odd bits and pieces I install & compile from source and forget to update.
Traditional package managers like dnf and apt are probably not even the best way to update the kernel and OS these days. Immutable images like what’s used in Fedora Silverblue (as well as android and iOS) are much more reliable and probably the way distros will move
Having two ways to update the system doesn't either seem great to me. Having the same software that can be installed from two sources neither.
Also as far as I remember flatpack is something more complex than a simple package format, it has a runtime where each application runs in an isolated container where it can access only some of the resources (e.g. the filesystem). This adds to me useless complications to a system.
I think that the best approach to the integration of third party software is the one followed by ArchLinux, that is the AUR: a series of build instructions, maintained by the community, that allow you to package practically any piece of software that exists.
The requirements for something that updates the OS and updates/manages applications/games is extremely different. Traditional package managers work but they are far from ideal.
They are completely inadequate for closed source software like games. Flatpak provides a stable platform you can target and it just keeps working across distros and in to the future while rpm/deb packages require constant maintenance.
Flatpak also provides a long list of essential features like permissions, sandboxing, portals, etc which most other OSs do. The future of linux is likely immutable OS images with something like OSTree, and then flatpak for end user apps.
> They are completely inadequate for closed source software like games
Why? What difference does make the license of the software? The only trouble is that the developer of the proprietary software has to package it in a number of formats and have repositories to download updates (that are HTTP servers with some special files in it). In reality to this day you just have to package a .deb, and if you want .rpm. For other distros these packages can be converted practically automatically (this is what is done with ArchLinux AUR for proprietary packages like Spotify or Chrome that are installed from the deb version).
> working across distros
This doesn't have a lot to do from the packaging format but on how you write the software. If you dynamically link 2000 system libraries you can as well use flatpack but the software will not work since typically on Linux the ABI is not that stable. If you have a single statically linked binary with MUSL libc you can as well package it as a deb and run it on Debian 4 that it will probably work.
> Flatpak also provides a long list of essential features like permissions, sandboxing, portals, etc which most other OSs do
They are not essentials. And they cause more problems to the user than what they solve. And don't talk me about using containers for security, since they don't provide any useful and proven safe isolation. On the other end you have SELinux/AppArmor that you can apply easily on any executable regardless of the packaging format.
> The future of linux is likely immutable OS images with something like OSTree, and then flatpak for end user apps.
This is wanting to go in the direction of what Apple does on macOS/iOS where the / is immutable. I think that people use Linux because it's different, if not they would just buy a MAC. These are complications that gets you in the way.
Linux users wants to be able to build the system by picking the components they want, not the components that Canonical or Red Hat decided that they must be present in their distribution.
The system package manager is useful for updating the underlying system, not necessarily the user's environment. Think of it as a in the classic root/user divide. The system package manager is there for updating the core system and things like flatpaks/toolboxes are there for the users. They don't follow the same updating patterns so it makes sense to keep them separate.
Unfortunately, even after all these years Linux distros couldn't settle on a standardized packaging format so distributing software for N different Linux distros is still a massive PITA. Ignoring distro packaging might be the next best thing.
free desktop "making progress" on something Windows XP had no problems with from the get go is frankly embarrassing and probably a sign of, at best, destructively entitled maintainers, and at worst, controlled opposition.
I'm an Ubuntu user and the first thing I always do in a new system is removing the Ubuntu Store, completely removing snapd, and installing the Flathub Store.
Honest question; why do you still use Ubuntu then?
By now, Snap is such a fundamental part of Ubuntu that it begs the question whether Ubuntu is right for you if you want to avoid it. Why not use a derivative or upstream that makes different choices?
agreed. Ubuntu are trying to hard to differentiate themselves, and it usually just hurts them. I'm guessing they'll drop snap in the future and blame the industry (like they did with systemd and wayland)
Ubuntu is an African word which means "Afraid of Debian"
Seriously though, just install Debian. It's not hard, the netinstaller may be text-mode but it walks you through the simple steps one by one just like Ubuntu's GUI installer. Anybody who's comfortable using Ubuntu in the first place should be able to get through the Debian installer just fine.
If you’re using desktop, then honestly look into fedora or arch (EndeavourOS). I really am not sure why Ubuntu is still being used. I know it’s the main thing people recommend but it is awful for day to day desktop use due to its release cadence and holding packages back.
95% of "here's how to fix that braindead default that's giving you troule" or "here's what that misleading error message means and how to fix it" how-tos or whatever, for servers, are written either for Ubuntu or Red Hat (and friends) and sometimes the exact same steps won't work even on Debian. 3rd party commercial software often supports only Ubuntu or Red Hat, and you're on your own if you use it on something else. I've never liked RPM-based distros and specifically dislike Red Hat as a company, so, Ubuntu it is.
(For work, where I just want something that won't make me "the asshole who chose [non-standard thing]". I prefer Void or FreeBSD or, sometimes, Debian, for my own stuff)
[EDIT] Oh, right, specifically for desktop? Yeah, I'd go Void or Arch probably. Buuuuuut if it were for work, I'd just use Ubuntu, even on the desktop, so it wouldn't be my fault when it misbehaves.
By design, yes. Debian prioritizes stability over being on the cutting edge. If you always want the latest and greatest, Debian isn't the right distro for you.
Not if you explicitly use the word "testing" in your apt config though, no? But yeah, after the hard freeze, changes do slow down until it stable is released, then there is a flood of changes.
But you will still be subjected to Debian crazy rules regarding applied patch sets.
Nowadays you can get a full featured, well integrated and properly working user land on Linux with next to zero customisation with systemd and Gnome. I really recommend using a distribution which stays as close to vanilla as possible.
It's the same with any DE nowadays. Switch Gnome by KDE or any other. The base system is uniform enough that things just fit together.
Debian would still patch far too much to my taste without the integration anyway.
They remove/rebrand what they don't find free enough, want to make things "modular", want to split development and base packages, want to support a ton of architectures upstream doesn't care about and want to integrate things in their historic tooling. It has introduced some severe bugs in the past.
I recently put Tumbleweed on my laptop and am pleasantly surprised. You get new packages very fast thanks to automated testing, built-in btrfs snapshots allow you to undo a problematic update. Will be moving my main Ubuntu desktop to it soon.
Is this still true today? 15 years ago it was a different story, but nowadays I haven't noticed a difference in update cadence between the two.
Edit: I just checked for the classic case of latest Python (3.11), and the answer for Debian is to build from source, which is annoying (not difficult to compile, but then future updates can't be pulled in via apt). Does Debian not have a vibrant PPA community to fill the gaps like Ubuntu?
Ubuntu is cut from Debian testing, not Debian stable. If you want to move upstream, you should be looking at testing, not stable.
In my experience, the stability concerns are overblown, and it makes for a really nice rolling release system. I've had individual systems run for over a decade on a Debian testing install with rolling updates, and it's generally been far less of a headache than Ubuntu releases.
I ran Debian on some of my systems for a while and ran into issues with stable that end up not getting fixed for a long time. I agree if you want to run Debian, run testing.
Ubuntu used to have security support for "main" only. All other software, e.g. in "universe" had patches trickle in from debian but no dedicated support. This is particularly problematic for long or extended LTS when debian has dropped the old stable release that would be pulling from.
"Ubuntu pro" is basically trying to fix this shortcoming compared to debian and to pay for a security team for universe. It is available as a subscription.
TLDR: If you use software from main it is completely irrelevant. If you use stuff from universe it is now as good as debian, if you pay (first 5 devices are free).
GP here. I use some tools that are Ubuntu specific. But I might look at Ubuntu derivatives such as Pop or Mint. As I said in my other comments, these are desktop/HTPC machines so, it's not as straight forward to change distro as it would be with a server.
zorin is another decent distro as well. i was on pop for maybe 3 years and that was great but zorin has won me over for reasons i can't really put my finger on
One reason is 3rd party software. Frequently there is a deb compatible with the last couple of ubu LTS releases. Seems like more frequently than Debian stable releases? There's always things you don't like, are not distro packaged, but have to install for reasons to get work done to get paid. Xilinx vivado being the first example for me that springs to mind but I'm sure there are others and I'm sure I don't know what the next one will be yet. I feel like when it crops up ubu LTS is a better bet than debian stable. I'd love to be shown to be wrong about that.
Running with the crowd has some advantages. Many feet passing on the path before you trample more bugs before you get there etc.
For anyone looking to use debian I highly recommend it and prefer it to any other distro.
Additionally if I recall correctly, Ubuntu is one of the few distros that's set up to handle secure boot correctly out of the box (with the other I know to do this being Fedora).
This is nice if you're dual booting Windows 11. It's also probably going to increase the Ubuntu's representation in desktop Linux by virtue of booting without any EFI setup tinkering, because a lot of people's patience ends exactly where things cease to work as expected.
My problem with Ubuntu is that I can never get it to work right. Debian works right out of the box for me. (By "work right", I mean operate correctly -- I don't mean "work the way I want")
Since there are so many people that don't have this problem, I understand that it's something I'm doing wrong -- but I have never been able to figure out what that is.
But it sounds like you got Debian to work -- you just couldn't get compiz to work, which sucks.
What I mean is that I can't get Ubuntu to work at all. On my luckiest tries, I've managed to get the desktop to show, but everything is still highly unstable and I've never pushed on to trying to install software.
I used to think it was driver issues, except I've had similar symptoms on three different machines. And before people jump down my throat -- I'm not saying this is a problem with Ubuntu. I admit that I must be doing it wrong. But it's a showstopper deal for me anyway.
Admittedly, the last time I tried was a few years back. Eventually, I just had to give up and move on with my life.
As a fairly begrudging Ubuntu user (I put it on a laptop because I didn’t want to screw around with finding drivers, memories of trying to get wifi working on Arch with some dongles haunt me), I have to say I don’t really like it much overall but they’ve got the “getting to the desktop” experience down pretty well.
No. I do tend to use old hardware, but tried it on a mainstream new laptop one time. On that, I couldn't get the WiFi to work with it.
What baffles me is that on all of these machines, Debian works out of the box. In fact, Debian's never failed me on any of the many machines (including laptops) I've put it on.
Ubuntu is based on Debian, so I can't explain the difference. As I said, it's been a while and perhaps they've fixed issues, but I've moved on. My life is no poorer for it.
The only thing is that it means I can't recommend Ubuntu to people (not only because I wouldn't be able to support them if they have trouble, but what am I supposed to say? "I can't make it work, but use this!"?)
Even better, install Devuan, which is Debian without systemd (the attempt to turn Linux into Windows). Many former Debian developers are now working on Devuan.
What you should look at is the difference between Debian and Devuan. Or between Debian and OpenBSD, to understand what the systemd project is doing, and how it’s doing it.
There are many of us that prefer Linux as it was before systemd.
> systemd (the attempt to turn Linux into Windows)
systemd was actually inspired by launchd, not Windows. But I guess systemd, Windows and launchd do share one thing in common which is not having a bunch of bandaid shell scripts hanging the system together.
Presumably they're talking about systemd as a whole, not just the tiny subset of systemd that is used as init system or service manager.
I don't think I've seen anyone complain about systemd's init system or service manager; it's always about the remaining 90% of systemd's scope and its tight coupling between all its parts (the tight coupling being the main problem).
I don't personally remove snaps but if I did I'd still use Ubuntu for the sole reason that it is somehow the only distro that gets fonts right. I don't know what it is but on every other linux distribution font rendering looks horrible, and I could never figure out how to reliably fix it.
It’s most likely not the rendering but the font itself. The Ubuntu font might be the best looking one around. It can be installed on other distros easily. Some have it packaged in their repositories. Switch fonts, turn on full hinting and you’re in business.
I don't think it's just one font. I recently switched away from Ubuntu to OpenSUSE TumbleWeed and on occasional webpages and applications I get these badly rendered fonts. I fixed them to some extent by installing additional fonts, but not completely.
I know what you’re talking about. IIRC, there’s a page in the OpenSUSE docs or in the forums covering the bad browser fonts. That’s an issue that’s specific to them. Haven’t seen it in another distro in many years.
Honestly just inertia. Those are not servers (where you could easily migrate to another distro taking advantage of infra-as-code tools), they are a desktop and a HTPC. I have accumulated a lot of custom dotfiles, Ubuntu-specific utilities and scripts over time, not all of them would work in another distro unchanged.
Removing Snap is not that hard, the "hardest" part is making sure that Firefox is installed from the Mozilla PPA and even that takes just a moment once you have the script saved somewhere.
By the way I had a look at some Ubuntu derivatives like PopOS or Mint and I might take the plunge at some point.
I use it mostly out of ignorance, but also because I’m fairly used to aptitude as a packet manager and kubuntu has a pretty solid distribution put together.
I use Ubuntu and it’s worked fine for years. I have no reason to switch, but I couldn’t really tolerate Snaps anymore.
Unless I have another reason to reinstall Linux, it’s far easier to uninstall Firefox and the other handful of Snap apps and just use Flathub/flatpak exclusively. I just need to be careful I don’t pick the default store app when searching for software.
> I just need to be careful I don’t pick the default store app when searching for software.
In my experience Ubuntu's default store app can be safely uninstalled once you have Flatpack's store app. In fact I recommend doing that as their functionality overlaps quite a bit (e.g. you will get duplicated update notifications if you have both stores installed).
(The above assumes that you got rid of Snap. Otherwise you may still need the default one)
Ubuntu is still a better experience than Debian on the desktop, many many packages are built and tested for Ubuntu and not debian.
Ubuntu also as better hardware integration ( drivers ) and more modern kernels. AS a matter of fact it has many kernel for deferent usage.
People use Ubuntu because it works just fine out of the box, you don't need to install a third party non free drivers to get your wifi card to work. I still have nightmare with debian because they used to not ship proprietary drivers so you would have to cary a USB stick in the datacenter with drivers on it to make network cards working.
That article doesn't provide much context, but Zsys != ZFS. Zsys (and the surrounding effort in Ubuntu) are all about using ZFS as a root filesystem for Desktop Ubuntu and providing convenient features like snapshot on update (to facilitate rolling back a botched upgrade, for instance). To the article's credit, it does look like Canonical is letting this die on the vine (sadly).
But that doesn't change the fact that ZFS itself is in the Ubuntu repos, tested against Ubuntu's kernels (it's a kernel module, so this is important), and _really easy_ to install: `sudo apt install zfsutils-linux`.
Personally on my box, I boot off a small NVMe SSD formatted ext4 (installer defaults) and then have all my hard drives in a ZFS pool to store my data. If /r/zfs is to be believed, this is a common setup.
I get where you are coming from, but my first attempt at setting up nextcloud was with a snap and it made the experience a lot less challenging to a newbie ( though these days, I would likely not do it that way ). What is the benefit of flathub over ubuntu store?
The fact that Flatpak supports multiple repositories whereas Snap only works with Canonical's store. This is because the open-source Snap utility on your Ubuntu install doesn't support adding other repositories; and the server it talks to is closed-source and undocumented. (Oh, and don't get brilliant ideas with DNS redirection in your head, there's digital signing, which means the only way to get Snap to accept other Stores is with a full recompile.)
As for Flathub itself, it's like the Snap Store... but you aren't locked in, and the backend is open-source, and it's not directly owned by a distribution maker (even though it is definitely closer-in-kindred with the Fedora Project), which makes it far more palatable to people with even a modicum of understanding of the Linux and FOSS philosophy.
I feel like the real reason behind the closed snap store is that canonical is aiming for that sweet app store percentage once they get make commercial players on board. It's certainly worked for Apple and Google, being the gatekeeper of a platform is very lucrative.
Here here! In answer to a below question, I use Ubuntu because of the number of sdks that mainly support Ubuntu but don't require the Ubuntu Store (which I personally find annoying). Also I like Synaptic. Though imperfect it's far less annoying, feeling less like a "curated experience" and more like a tool that's trying to get out of my way and let me work.
If you switch to Pop OS it's setup like that out of the box. They have a Pop Store that's autoconfigured with flathub and plain old Ubuntu/Debian apt packages. Zero snaps. Zero config or changes, it's ready to go.
I’m not sure people will ever want to sell apps on a 3rd party store. Especially a Linux one. The entire industry has moved away from buying things directly on a single marketplace and moved to tying a payment or subscription to an account which works across OSs and store platforms.
I’d be happy to pay for Linux software but there is no way I’d want to be tied to a particular distro/repo/storefront.
Windows has existed for most of lifetime without a store or even central package management but it was still the biggest platform for commercial software. And recently the App and Play stores seem to cause more trouble to many companies than it's worth.
If they used the royalties to hire people to audit the packages I might even consider paying for free software, but I'm afraid it will turn into walled gardens where small developers have no say and the big ones just deal with the problems because it's the only option.
I hope it turns out to be better with KDE and Gnome that come from a FOSS background but money makes people greedy.
The OP answers that question pretty throughly. Because pacman is niche and distro-specific and largely distro-controlled, and has no ability to incentivize developers who need to get paid for their work. This leads to Linux desktop having far fewer applications available to them compared to windows and mac.
If payment is your main incentive to work on software you should stay out of the FOSS space. Go write your iPhone/Android app or sell your stuff on Steam. Another little insignificant app store won't convince Adobe or AutoDesk to port their stuff to Linux.
What? That seems crazy to me. You would literally turn away people that want to add value to the FOSS foundational ecosystem, which in turn brings in contributors and donations to keep things going?
Also this seems to be a confusion about what FOSS is. FOSS "freedom" isn't about "free as in beer", it's about "free as in speech." The GPL even welcomes commercial software, provided they include the source. I'd be thrilled to see a category of "paid FOSS" in the store, and I'd buy quite a bit of it if prices are reasonable and the software is useful.
Because traditional packages are running out of steam. IMO people want a stable (not changing) underlying OS with a dynamic set of frequently updating applications on top. Arch nails the second part but completely fails on the first. Debian nails the first but fails on the second. Something new is needed.
I haven't been the biggest fan of flatpak and generally wish software would either be packaged as an rpm or an AppImage, but the OP makes a pretty strong case for why it's a good idea (because existing options are too niche, and have no ability to incentivize developers who need to get paid for their work. This leads to Linux desktop having far fewer applications available to them compared to windows and mac.)
I do hope the command-line UX around flatpaks (installing, updating, etc) improves a lot though as currently it leaves much to be desired.
Yes definitely, it's probably both. Both are in a feedback cycle as well. Less people means less attention. Less attention means less people. It's a hard cycle to break.
AppImage has issues. The guy from Suse who does MicroOS, Richard
Brown, a few years ago was literally walking around giving talk about how bad Flatpak was and how everybody should use AppImage.
In his most recent talk he basically said, he was wrong, the Flatpak people did address most of the issue he had and AppImage was no viable.
AppImage still just works, just like tarball bundles without dependency on 3rd party infrastructure and overengineered solutions like snap and flatpak.
I haven't watched the talk (yet), but I use a number of app images and they have always "just worked" and in remarkable fashion. My only complaint is that you sometimes have to write the .desktop yourself if you want it launchable through the UI, but that's a fairly trivial objection.
I had to use flatpack to install Bottles, I'm on Porteus because it's the only distrib I found that would fit on a 15 year old 512MB USB stick and then in the RAM directly... Let just say it wasn't a seamless experience but I'm glad I managed to run Cinema4D R20 or MPC Software with Bottles without too many bugs. Anyway Bottles is just fantastic, I tried Wine before but it never worked properly, but having to install a package manager (flatpack) on top of another one (slackpkg) just felt absurd...
What about appimage instead, like Krita? To me it's sounds like the best way to distribute a linux app in 202X...
Managing to make things run on Linux gives a sense of accomplissement, at the same time, I can understand why most people won't move to Linux anytime soon given all the complexity involved... or it's just me and there was an easier way to install flatpack at first place?
AppImage solves the packaging problem in a bad way (ugh, loopback mounts), but does not solve the dependency problem, try run AppImages compiled for Ubuntu on Fedora..
The main use case for appimage imo is things you just want to run once quickly and easily. Trying beta builds from github releases for example. It's quite poor for anything you frequently use or want to keep updated. It's also completely lacking security iirc which Flatpak does well.
AppImage is far from great, the great one is having a foundation that doesn't break every 5 years and programs relying on that foundation.
AppImage is just the least bad solution - if nothing else it doesn't need some weird infrastructure to run. As a developer you just upload the binary to your site and as a user you just download the binary and run it.
Opinions on Flatpaks/snaps notwithstanding, it's encouraging to see KDE and GNOME collaborating on projects like this. IMO desktop GNU/Linux has benefited greatly from moving away from offering LXDE/LXQT/Mate/Enlightenment/Cinammon flavors and towards a more digestible subset (GNOME only, GNOME/KDE/XFCE, etc) of polished desktop environments. Pipe dream, but it would be incredible to see all of the passionate, talented folks working together on one definitive GNU/Linux DE.
I'd prefer to see more easily-communicated DE standards and published levels of adherence, rather than moving to the uni-desktop.
Like if you want to select a desktop and are kind of new to desktop environments, maybe aim for the (imaginary example here) DE-5 level of standards-adherence. DE-4 and lower might suck in various ways even though they could have cool new features.
There are way too many benefits from the huge variety of DE approaches, including the benefit that Linux-critics often hide behind critique of a single desktop experience, which is lazy and attempts to steal focus from exactly this open, creative, diverse approach that is the jewel in the Linux ecosystem's metaphorical crown.
It's definitely great to see the groups working together on these projects that benefit everybody.
> I'd prefer to see more easily-communicated DE standards and published levels of adherence, rather than moving to the uni-desktop.
What's the difference? If everything works perfectly with everything else, and the standards adherence is so high that you can't tell the difference which apps are from which organization, then how is that not a "unified DE"?
This depends: Do you care about details, or not? If not, a hand wave in the direction of "everything's the same" will suffice and the discussion's over.
OTOH, if you think there are good, detailed reasons why XFCE is not KDE is not Gnome is not LXDE, then you can probably see why standards are helpful, insofar as they can be designed to be reachable without compromising unique leverage points.
The difference is that one of those sets of standards is actually more of a file system hierarchy and API standardization thing, whereas the uni-desktop would presumably force a particular set of gui widgets along with the filesystem hierarchy and APIs that those widgets are built on.
We of course already have something like this (POSIX, Freedesktop, etc). However neither is abided by very well and neither of them go far enough up the stack to deal with certain very visible issues of desktop application incompatibility.
What I think could be done to fix some of the compatibility issues (like when running QT on gnome or GTK on KDE or applications that eschew them both and have janky window decorations) would be some more serious standardization onto something like Wayland. We would of course need something more than a reference implementation for that, but fundamentally I don't see why that would be too restrictive for projects that still want to make their own widgets.
In my imagined hyper-standardized Linux landscape, there'd be a standard for e.g. the semantics of interpreting metrics in themes, and a shared superset of required icons for a theme to have; such that you could create one theme once, and have it "just work", resulting in pixel-identical widgets, under GTK, QT, Wx, etc.
There'd also be a standard for e.g. IPC-based interoperation with file picker dialogs, such that if you were running GNOME as your DE, QT apps would (tell the DE to) pop the (GTK!) file picker to open a file, which would then signal back to the app through some standard message format for describing picked files (maybe with the file-handles themselves passed over a Unix domain socket, if you want something like macOS's sandbox-piercing file-open-intent tokens.)
There'd be a single "accessibility DOM" standard, so that a GTK screen-reader could read the text out of QT apps.
There'd be a single shell namespace standard, with one common set of abstract data types (with multiple implementations), so that opening some GVFS virtual folder in a KDE app would actually work — probably through D-Bus integration between the KDE app and some libgvfs host runner agent.
And so forth.
The ecosystems of each DE would remain distinct in development, with apps designed to fit well together... but the feeling of DEs being walled gardens would be gone, because the various standards would force each app to be a "chameleon" to whatever DE it's running under.
There are a few tiny attempts at this under FreeDesktop. xdg-open(1) is a good start. But we could be doing so much more.
I really think you are into something here. Some simple rating and standard icon would help users differentiate quickly. I know and love distrowatch and the rest, but it’s definitely inaccessible for most beginners and hard to discover what the best fit is for me.
The FHS[1] and XDG[2] sets the standards for the file system, and EWMH[3] communication between windows and window managers. They are all simple enough that implementing a subset doesn't make much sense. Many desktop environments tend to only list support for stuff that usually are a common problem like screen-sharing or driver support.
I'm using a very minimal system without a lot of the easy to implement features on purpose, but absolutely can not live without some of the more difficult ones. So for me the adherence would be cherry-picked parts from 3, 4 and 5 and impossible to place on a chart. I don't think it would be a good fit for the modular unix philosophy.
Yeah, but the problem and beauty of unix is the modularity and much of those features are out of the desktop environments hands. Control panel for what printer? Which settings? What version of the drivers?
At the lowest level you have the kernels (KDE and Gnome both run on Linux AND BSD) which may or may not have drivers built in. Then comes the distributions which are opinionated in the kernel versions, packages and patches they add.
Some of those packages are desktop environments or window managers and they are opinionated in how they run other packages and their lifecycle. Some full featured others are tiling. Some of them run on both Xorg and Wayland.
Last we have the actual packages, and they need to work in all these different environments, sizes and lately different protocols. They need to support different drivers, permissions and file system hierarchies. They do this by relying on each other, a package handling video focuses on supporting video and sound drivers so other packages can import that package.
KDE might have a very polished and up to date settings panel, checking for all drivers and their features. But in reality it works as intended on Ubuntu, but Debian is behind and doesn't want to patch the drivers because stability, on Arch there was a regression and most of the BSDs don't even support the driver. And one time Linus came along and didn't listen to the warnings and fucked it all with one line.
Nobody controls all of these pieces and they're so spread apart that what might seem as simple as a panel for printer settings quickly gets very complicated. But I wouldn't have it any other way. For those who want the one size fits all there are already options.
This has existed for a long time from freedesktop.org, XDG specs, window manager extended hints, and so on.
And it's gotten better too - did you know KDE3 had it's own sound mixer daemon? It was called ArtsD. Now we have pulseaudio, or whatever, which is great and cross desktop
DBUS made it everywhere as well - I believe initially KDE3 as well did not have DBUS but had something called, DCOP. so - yeah things have improved a lot and many things - even command line tools 'playerctl' interop well based on this.
More fun is also like libreoffice is compiled with many different file pickers, so on KDE you can use the native Qt extended KDE file picker, and on Gnome you get the GTK one.
Which is completely backwards-compatible with PulseAudio. Even in a Pipewire-only world, applications will for the most part be linked against libpulse like they used to, but the PulseAudio server socket is provided by Pipewire.
> I'd prefer to see more easily-communicated DE standards and published levels of adherence, rather than moving to the uni-desktop.
I used to be on this hill. All this leads to is inoperable software where each integration point is liable to break. I want to get away from the spyware that is Windows, the walled garden that is MacOS. If a uni-desktop is the price we pay, so be it.
Of these, I would say that Cinnamon is one that could be comparable to XFCE or even GNOME and KDE. Seriously, it's good. The system settings menu has all of the options one could need and the look and feel of the dektop is very customizable.
I'm a KDE user, but if it ever stopped working/disappeared I would use Cinnamon. In fact I plan to use it whenever KDE Plasma 6 releases to wait out until the it becomes more stable.
> KDE Plasma 6 releases to wait out until the it becomes more stable.
IIRC KDE committed to never break users again like they did with the first releases of KDE 4. It's expect the first releases of Plasma 6 that the distros will actually ship to be stable, and to be mostly a Qt5 → Qt 6 upgrade. You should be able to run a stable version of Plasma (5 or 6) in any case during this period. KDE 3 to 4 was a disaster; last versions of KDE 4 were rock solid. First versions of Plasma 5 were a bit lacking but rapidly became very stable and usable, and you could actually keep using KDE 4 in the meantime. I expect the Plasma 6 transition to be even smoother. I hope I'm not wrong.
But otherwise I agree, Cinnamon seems very good and I tend to recommend it and pick it for people who I install Linux for.
Sorry, but as an early adopter of Plasma 5 (granted, maybe a bit too early), it was terribly broken for a couple of months. I took refuge in Awesome until things stabilized.
I can see that. For me personally about a year~ish ago Plasma Wayland reached the point where it's good enough for me to use as a daily driver...
...though I do lament the loss of Desktop Cube.
Of course, coming from Awesome I am often annoyed at how Plasma doesn't have per-screen (X11 monitor, if I'm not mistaken) tags and per-X11-display workspaces don't really work that well.
Huh. I started using Plasma 5 on a bleeding edge rolling distro and it was just fine. Everything was a mix of KDE4 and KDE5 apps for a while, but they all worked with minor quirks at worst.
I believe I was switching between Arch and OpenSUSE at the time, and I didn't note down specific issues, I seem to recall problems with kwin dying... maybe something to do with multihead? If I'm not mistaken I was still using a PC with a Radeon HD 7770 GPU at the time (for all the Catalyst issues I've had, still one of my favourite pieces of computer hardware I've ever owned), so it could have been iffy interactions between moving parts. I do seem to recall a period when I got many, many panics (or oopses, I dunno, screen went black and nothing reacted to anything), I think that was around the same time.
Forgive the vagueness, but I don't believe in memories and haven't kept a journal. Still, as completely unreliable and untrustworthy human memory is I am inclined to believe I had issues with Plasma 5 during the transition period.
Yeah, I'm sure you did run into real issues. I was trying to figure out if they were distro issues, or if issues that also affected me were more of a problem for your workflow than mine, etc.
Either way I think that still sounds better than the old 3->4 migration, and hopefully 5->6 can be better still!
Agreed, GNOME is so user-hostile that I'm actually a little impressed.
Personal example from trying GNOME out recently: I have an external webcam, which means I need to move the GNOME panel clock since it's in the top middle of the screen (and thus blocked by the base of the webcam). You would _think_ that would be easy, but you have to get an extension just to move the clock! Apparently each panel "widget" (this may or may not be the official term) defines its own position on the panel. So, to move something, you need to either find an extension that does it (Frippery Move Clock[0] in this case) or edit the widget code yourself.
Maybe someone can chime in with a technical explanation, but my cynical take is that the GNOME devs don't even trust users to be smart enough to customize their own panel without breaking things.
They're not really user-hostile, they just have limited development resources and making a polished interface for editing the positioning of top bar widgets would be way too much work. If you want to try things on your own, that's what unofficial extensions and tweaking tools are for.
There are several full time paid developers working on it which is plenty of resources (AFAIK more than KDE). They are not only actively user-hostile but also community-hostile. Every library or project they have under their umbrella receives updates all the time that only serve GNOME and potentially break all software dependent on it that are not part of GNOME (e.g [1]).
What you're saying is simply that GNOME developers don't want to pick up development and maintenance burden that isn't going to directly benefit their project. If you think there's opportunities to share projects or libraries across DE's, the proper venue for that would be freedesktop.org not really GNOME itself. Then the maintenance load can be shared as well.
This has been tried. All you will get is rejected pull requests. What makes it even worse is that GNOME has usurped many projects that were original not part of GNOME but that the community relies on (one example is the "GIMP Tool Kit"). This led to the death of many long tail niche projects which are the actual strength of Linux/FOSS.
The example doesnt seem to support your argument. The rationale the developer gives here is reasonable and looks like good stewardship of a shared library - the patch added a new API that was tightly based on termites' needs and provided little benefit for other terminal programs. What the maintainer wanted was a more complete API for the feature. The termite dev said he did not want to implement this feature in the library. This is also reasonable. Its his code and his time. So we have two people who can't find/commit to a solution everyone is happy with. It doesn't really seem user hostile at all, just that something couldnt be worked out. Sure, its frustrating when its an app you really like, but sometimes interests wont align even when it seems from the outside like they should.
That reading doesn't really agree with the maintainers' responses at all.
They say this is desirable functionality, but that they would want to subsume termites features in VTE and Gnome Terminal, and that was their rationale for rejecting the patch. Then they didn't deliver those features in a timely fashion.
Can’t really blame them for not producing the slick configuration GUI for every option. But it is annoying that they always go for the slick configuration GUI, as if they were a for profit company with a bunch of full time devs. Meanwhile every other open source program, recognizing that it has limited developer time (and interest in boring grunt work), just sets up easier text-centric config first…
The text-centric config for GNOME is dconf/gsettings. But what people like to complain about is graphical configuration, which adds enough maintenance burden that it's only worth doing if it's going to be friendly enough for most novice users.
Dude, please. You're posting a shallow dismissal of a project that's doing a lot of work to make *nix-like OS's more usable for novice and non-technical users. HN deserves a lot better than this.
Nah a bunch of clowns funded by private companies used their salaries to boost their egos to develop stupid anti-user centric desktop software starting after gnome 3 launched. Remove all options, treat everyone like an iPad baby and try to leverage the existing desktop to do a radical paradigm shift, when all people wanted was GNOME2+. This is actually different than KDE3->KDE4 transition, which while it was a total disaster in terms of usability and reliablity, continued to keep the roots of a power desktop in terms of flexibility configuration and software customization.
GNOME2+ is still around, that's what Mate is. GNOME 3 and later releases has great support for convergence, which is incredibly popular among users - while also being very easy to use via the keyboard, for a more traditional workflow. Ubuntu's Unity interface was built with similar goals, so this is quite far from a pure GNOME thing.
Many high-end laptops have touchscreens these days. So the resemblance is quite appropriate. I would like to see a "compact", non-touchscreen mode in case no touch hardware is being used but it should be optional, for users who are okay with that level of fine-grained control.
I used GNOME for a long time, but I didn't like the bloat, among other things, such as the "I know better than you" attitude from the devs. At the same time KDE has a tendency to get me into rabbit holes, and then inevitably something breaks at some point that I don't know how to repair because it is rather too complicated of a system. (This is ~2017, not sure if things have changed). For now, I just use bspwm, polybar and a set of GUI applications. While they are less friendly to set up, they are much easier to understand for me.
Things have changed a lot since 2017. In 2017, I wouldn't touch KDE with a barge pole because I had work to do and it would disassemble itself if I looked at it funny.
Now I'm writing this reply from KDE, quite comfortably, and it's quite stable. Comfortable, even. And it doesn't get stupid and die when I plug/unplug monitors and stuff.
Similarly, nowadays I use XFCE but could have been KDE as well, JavaScript everywhere and having killed design tooling for Gtk4, doesn't really make it appealing, and once upon a time I wrote an article for "The C/C++ Users Journal" advocating for Gtkmm.
There's nothing wrong with Mate, Cinnamon or even LXDE. Especially since desktop environments these days are mostly different frontends built on a fairly unified infrastructure, largely provided by freedesktop.org. We still see divergence between Qt-based and GTK+ based desktops, and other minor differences exist, but the "one definitive" user environment is basically here.
As a long time Linux user I have mixed feelings about that.
I'm not really against it, but I don't use KDE or Gnome (or any of the others in your list) and it concerns me that people might start thinking of those as "being Linux". I'd hate to see a future where "We support Linux" means KDE or Gnome.
On the other hand, I have to admit I'm not really sure what that would mean. I guess only having "Flatpak" as an option would be a bummer, but I don't see that happening with the distros I use.
> but it would be incredible to see all of the passionate, talented folks working together on one definitive GNU/Linux DE.
This would be terrible. Gnome and KDE have pretty conflicting ideologies. Gnome is super opinionated and Mac-like minimalist. KDE is all about user choice.
If they'd collaborate it would end up something in the middle which would suit nobody.
> Gnome is super opinionated and Mac-like minimalist.
The problem with this is that Mac, unlike Gnome, actually works. Gnome just has weird holes where old functionality was removed (like application menus!) and never replaced.
Well, GNOME actually exceeds macOS minimalism… at least in macOS I have the ability to hide the top bar, several ways to launch apps, a systray, graphical configuration for most things, the ability to change keymappings, and so on. In GNOME, I need 3rd party tools for all of that.
Yeah - i make do with yabai and skhd. I'm curious how people use the Mac without having to use a touchpad/mouse for everything without third party additions (that in the case of proper desktop management / multiple monitors needs to disable system integrity protection to work...).
Ed: one minor (but somewhat understandable annoyance) is the lack of a free/reserved for users modifier key. Macos with the adoption of bsd uses both command, option and control (even though it uses command for core things like copy/paste). The windows/super key is a blessing on Linux pcs - as it generally can be used for just that - window management).
I know some rebind caps lock as a super (ed2: I mean "hyper", I think) (aka ALL THE MODIFIERS) key on Mac - but that leaves control in the wrong place :/
All my dealing with GNOME have made me dread the day that happens. We need a polyculture because we will never beat $mega_corp on a polished monoculture.
I used to think Flatpaks were a huge pain the butt, but over the last few years, I moved to using them for all third party software that I run on my Fedora Linux workstation.
Zoom, Slack, Spotify, Steam, Discord, Obsidian all run without issues and they get consistent updates. I am convinced now that they are one of the best ways to ship commercial software on to Linux desktop. Flatpak has been a key part of me becoming 100% Windows free for my PC gaming. Not having to run a desktop KVM to switch between my work workstation and my Gaming PC has been super great.
I think the only issue I ever had with them was the inability to inject files inside. Do you know if that's possible?
I was trying to use a browser, I think Vivaldi, that had instructions for enabling widevine by copying a file to a certain directory, but I couldn't find a clean way to do so.
One big tricky thing is plugins, such as for OBS. ABI incompatibility and sandboxing can make it tricky and confusing for end users. Flatpak itself could theoretically provide answers here.
They'll have to do it at some point. There's just too many apps with plugins to ignore it. (Including basically all of audio production with their VSTs)
Yep. The main way I notice that an app is using FlatPak is it becomes impossible for me to type Japanese in it because the person distributing it hasn't done the complicated stuff you have to do to make IME work with FlatPak.
I really hope Wayland helps here. It has an IME input API, so if that's sufficient, maybe it can displace out-of-band input buses on the application-side.
So these integrate well now?
I normally just use AUR for everything now, and remember having issues with a flatpak for rpcs3 a few years ago, ended up compiling from src
Yes, actually flatpak triggered some interesting projects that are going beyong flatpak now:
- pipewire for audio/video stream management that allows sandboxing
- xdg-desktop portals to integrate the sandboxed apps in the host desktop environment and operating system. It's what allows the host DE ui to grant permissions (like reading/writing a file, accessing screen share, etc...)
It will depend how an app has been packaged, but when well done the sandboxing is invisible.
Last I tried all three of the semi-popular formats like this, AppImage was the only one that didn't feel fundamentally wrong (though what I gather was the closest thing to an official repository for them looked sketchy as hell—somehow they copied the exact CSS vibe as a content-scraped StackOverflow spam site). But that was a couple years ago. I know Snaps still suck, but haven't messed with Flatpacks since then, so maybe they're better now.
How many different versions of OpenSSL are running on my laptop right now? Who can say? That's the beauty of flatpak: if you sweep the problems of software management under a big enough rug, they go away and never bother you again.
It's a problem of the many-distros model for Linux—or, if you prefer, it's a problem of Linux just being a kernel. You can't just target "Desktop Linux 15" and expect to have all the stuff that Desktop Linux 15 has, including a robust set of basic libraries and a unified GUI stack and standard same-on-every-copy-of-Linux-15 multimedia libraries and services and all that good stuff, and let the OS worry about keeping that secure without breaking your program. Programs end up having to be a lot more fiddly about their dependencies, and it causes problems.
Now, maybe the Linux approach is so good and useful in other ways that it's worth putting up with that, but it is a big problem and people are going to solve it, one way or another. If the model can't be changed, then the only solutions available may be bad, but they'll be used, and widely.
Flatpak has a concept of shared base layers, so if you update frequently you might notice 'org.gnome.Sdk' or whatever getting updated. This is a way to handle lots of the most popular shared dependencies.
Besides, sufficiently quality minded projects always wind up vendoring all of their dependencies anyway. There's a reason Chrome has their own fork of everything down to the compiler.
I know “Chrome bad” is a meme-level comment at this point but it’s a hugely impressive piece of software, basically an operating system unto itself at this point. Not to mention the V8 engine etc.
Plenty to criticise about it from a product perspective but from an engineering one it is kind of a marvel.
It all depends on how you draw your Venn diagrams, I suppose. Is Chrome a massively complex browser, or is it some window dressing and bookmark syncing sitting on top of Chromium, that itself is really just a simple UI around the Blink rendering engine. GNU/Chrome, anybody?
Maybe engineers might be enamoured by it. Whatever.
On my GFs computer Chrome starts in about 7 minutes after fresh boot, no other programs running, yet. From a fricking Samsung SSD, 8GiB RAM. All it has to do is show some fake tabs and render a single page content.
Tell about its quality to my GF. She's used to it, but some of these days, I'll check the DNS logs, to see if it's really loading all the 1000 tabs (she keeps open at once), for 0 reason whatsoever, or if it's just that slow to start one page.
They mentioned 1000 tabs which may go some way towards explaining it. If that's not how you're supposed to use Chrome (I'd understand if it wasn't) then I'd imagine some kind of notification to the user would be helpful. Something like: "Chrome may be a little slow, you have 1000 tabs open" including perhaps a table suggesting tabs that could be closed (i.e. if she's opened https://bbc.co.uk/news in 20 different tabs that were last accessed a month ago) and an easy mechanism to quickly do so.
I actually know of quite a few people who use browsers this way, so it may not be a terrible idea to have something like this.
The computer is fine, judging by Firefox starting resonably fast with very many tabs to restore for her on that computer.
Also the same chrome profile starts very fast when she uses the "private browsing mode" which doesn't restore any tabs. So it really just seems like chrome having perf issues with tab restore with many tabs.
But anyway the point still stands: an outlier user with 1000 tabs open had a slow startup time doesn’t mean Chrome is horribly engineered. If it isn’t an extensions issue then it’s a minor bug.
> Besides, sufficiently quality minded projects always wind up vendoring all of their dependencies anyway. There's a reason Chrome has their own fork of everything down to the compiler.
It's not about quality. It's about reproducibility of the exact versions of all dependencies. It's about communications with repos not being subverted to load malicious packages. It's build security not app quality, though app quality is a part.
The SDK is different from the platform itself, but more or less. So I have three versions of Gnome, two of KDE, and three of Freedesktop.org, just based on the apps I run on Silverblue and what version they're at in Flathub. Since I asked specifically about SSL, that's shipped with FDO, meaning I potentially have three versions running right now. Also I have this annoying situation where an app a client uses is using a deprecated FDo runtime and nobody wants to pay to rebuild it.
Why would I care? Ok Spotify has an old package with some vulnerabilities in it. But flatpak has it sandboxed so the worst you could do is maybe steal my Spotify session token. That's more a problem for Spotify than it is for me. They will go and fix their package and I will reset my sessions.
Meanwhile we have distros lagging behind for years to provide a new package because they can't break all the things depending on the old version.
> Meanwhile we have distros lagging behind for years to provide a new package because they can't break all the things depending on the old version.
I'm glad I left this category of problems behind me 5 years ago when I switched both, my personal and my work laptop to arch-linux/i3wm. These two machines have been running for 5 years, almost daily, with almost no issues, with the latest software packages. If the hardware lasts, I will go on like this for another 3 to 5 years and then upgrade hardware and (maybe) switch to wayland. I don't see anything on the horizon which would make me switch away from this setup.
My only complaint about arch/i3 so far is that updating Firefox forces a restart of Firefox, and I've got FF windows scattered over a few workspaces so I need to sift them back to their places.
Come to think of it I can probably prune one of the windows...
Would it be possible to create a script to save the desktop and screen position for each firefox window on close and restore them to the recorded desktops and positions on open? I haven't used i3 much (or arch at all), but I'm fairly certain I did something similar using Xubuntu some years back.
I'm vaguely aware of tools that'll do it for i3 but thus far I've just avoided restarting as much as I can. The call-out to James Mickens is not altogether inaccurate (:
Keep in mind that you can downgrade firefox back after the update with pacman -U /var/lib/something, then just refresh/keep using the open windows with no issue.
My impression is that Arch is not technically unusual among distributions, but is simply well-polished, documented, and very active (and has an easy way to install unvetted community packages). If this impression is correct, you still run the risk of unnoticed outdated software if the amount of volunteers drop, or a particularly critical one no longer has the time.
Which part of Arch's design prevents the issue described in the grandparent post? The issue is "distros lagging behind for years to provide a new package because they can't break all the things depending on the old version", which is solvable either with enough manpower or by sandboxing a la NixOS, where you can keep old versions around indefinitely for the things that need them. Does Arch use such sandboxing now?
>Which part of Arch's design prevents the issue described in the grandparent post?
As a former long-time Arch user, you're correct. It's "just" a distro not unlike the biggest one. The reason Arch repos are fairly well updated and big is the relatively easy to understand PKGBUILD format and the tooling around it, which lessens friction on package management.
The impact of having frictionless package building cannot be understated. I'm publishing Arch Linux packages for all my applications because it takes just a few minutes to write up a PKGBUILD. Then one time, I tried providing a Debian package as well, but I gave up after several hours of trying to get through all the bureaucracy of the tooling.
The difference is that arch doesn't have downstream forks of repositories. They just package the upstream versions which means the dev cycle is much tighter which in turn means they can update more frequently which means they just switch to the next major version and don't worry about breaking their special sauce forks. The downside is that there are people using old distros and stuck with old major versions who use eg. Python 2 by default.
Regardless of the explanations, as an Arch user, I think you have to at least acknowledge that Arch does not have this problem in practice. I am sure there are counter-examples but in almost all cases Arch packages are extremely up to date. If they are not, it is probably a package you are not even going to find on another distro.
Lagging isn't always a bad thing. Users of Debian Stable missed Heartbleed entirely.
But this gets to the mindset that bugs me about Flatpak, the magical thinking that regressions don't happen. It's why Alice can't downgrade a system flatpak because it might introduce a vulnerability she uses to attack Bob, but it's absolutely fine if she upgrades to introduce that vulnerability.
While I generally agree with you with respect to the mindset, it is actually possible to downgrade a flatpak [1]. It is rather involved, but possible. I have done it to downgrade cheese (the webcam app) since newer versions don't have the filters that older ones did, at least not for me.
Only when the version you want to downgrade to happens to be within the last 10 versions! Why 10? Beats me!
Case in point: the flatpak package for the Element messaging client seems to be the preferred installation method for non-debian distros. But for many users, encrypted message search is broken! [1] [2] Some users claim that downgrading can fix the issue, but the flatpak has been updated too many times now for any user to downgrade to an old enough version - tough luck!
It is! I have to do it with Mixxx because of some weird GL bugs they're having in 2.3.3. But it's a privileged operation compared to upgrading, which is crazy.
You are thinking of Snap probably. Some flatpaks have $HOME wide-open, but Flatpak itself has no mechanism to completely bypass the sandboxing, as evidenced by things like Wireshark being unable to actually capture packets and many IDEs being unable to actually call build tools.
And write access to $HOME lets a process climb out of the sandbox.
Trying to make sense of Flatpak's threat model is just near-impossible. It might protect you from something, if the specific app's configuration told it to do so. Starting a random Flatpak app, you have no guarantees, and the UX doesn't communicate anything about this.
We are in a transition period. Starting with getting apps packaged in flatpak even if it doesn’t improve security, and then once that’s all done we can start tightening the restrictions.
>How many different versions of OpenSSL are running on my laptop right now? Who can say?
but that's a problem, too.
i'd rather all things on a system be bottleneck-forced into using the latest version of security libraries that my system is actively updating; yes, this causes issues, but not issues like "There was a huge vulnerability found in X version Y, does it affect me?".
in other words, i'd rather have system breakage than insecurity. That's a personal taste, I admit.
that said, the sandboxing aspect behind 'the new ways' is fantastic.
Why don't you just turny our computer off then? It can't be exploited if it isn't actually running.
Which is to say most people use a computer to run software, so if the software doesn't run the security is pointless anyway.
Sure, if only some software breaks and you can wait for fixes that's a tradeoff, but given that in package maintainer land those fixes could be months or years away...
> How many different versions of OpenSSL are running on my laptop right now? Who can say? That's the beauty of flatpak
And how many of them are critically out of date because the software maintainer didn't update? Who can say? That's the beauty of flatpack (not).
With flatpack you have all the downside of static linking with none of its advantages, how exciting. (and there's nothing as cool as having 7 full linux distros installed on your computer at once, just because software can't agree on which base image to use)
Yeah I didn't realize people would take the joke there seriously. It's basically looking at package management and saying "this is hard so we won't try".
I wanted to like AppImage, but it just didn't seem integrated well enough. Flatpak gives you:
- Installation (no manually moving files from ~/Downloads)
- Launcher integration (no writing .desktop files by hand)
- Auto updating
As far as I saw, AppImage didn't have any of that. Though it was a while ago (and maybe some of this was my distro's fault). Has any of this improved lately?
An AppImage is just a regular binary. Basically if you have a directory containing a binary plus other files it needs (libraries, assets, etc), AppImage packages the whole dir up into a single binary. That's it. Running the AppImage is the same as extracting the dir and running the binary inside it.
Right, it's just a binary. And if I'm installing an app, say Audacity, I would never go to GitHub and download the raw binary, because then I'd have to write the desktop file by hand, and also the app would never get updated when new versions are released. Instead I use a package manager or Flatpak.
If there had been an adopted standard for embedding icons in ELF, and if common Linux launchers had just been a menuized view of a folder structure, this would never have been a problem.
But Linux Desktop has a nasty habit of adopting over engineered solutions instead of simple ones, especially if any other desktop OS is doing it that way.
The only software I run as an AppImage is BitWarden (from the official GitHub repo[1]. It prompts to update itself when there's a new version which works very well.
AppImage now has solutions for all three issues. They all rely on a central daemon, which implies they will only work ootb with support from the distribution. The same is true of snap and flatpack as far as I'm aware, so this isn't strictly a deficiency of the format.
there's a program called 'appimage launcher' or something along those lines, that will show a dialog window anytime you open an appimage and you can choose to just run it once or to integrate it, which copy it into a specified folder where the rest of your appimages are and then also create a desktop shortcut. it doesnt handle updates though
ive been using flatpak more myself these days but i hope the appimage format sticks around because its handy being able to quickly try out some software and then delete it when you are done, or to try out a new version of something and have both running at the same time
What was missing was convenient sandboxing. Firejail was recommended but with the responsibility entirely on the user to install and use it.
Flatpak doesn't limit access by default (or rather it does but apps can just ask more permissions at build time and it's not prevented by default IIRC) but offers the user some options for being more strict without needing extra tools.
The quality of the flatpak's sandbox has been rightfully questioned many times. The most atrocious thing about it is that it's the app publisher who decides what the permissions should be. Little wonder that if you go to flatpak.org, you won't even see the words "sandbox", "safe", or "secure".
Nor is their FAQ describing their sandboxing as a security feature, more like (limited) isolation technique.
But this isn't stopping flatpak zealots who just won't shut up about the "sandbox == secure" falsehood.
I don't know, I'd rather prefer a technology which is upfront about its lack of security than one which has glaring hole in what they call (a false sense of) "security". I treat flatpaks and appimages as mostly equal things and use them to keep and run proprietary stuff so that I know it won't be shitting its guts all over the host system.
I use Fedora and this is how I use Flatpak as well. Some software does have some problems when used through Flatpak. I vaguely recall Blender's Flatpak version having some issues. I would also like to see more transparency with who is publishing the Flatpak on Flathub. Maybe I'm just dumb but it is not immediately obvious to me who the publisher is and whether or not this is an officially supported Flatpak application.
A whole lot of the flatpaks currently are packaged by 3rd parties and they have all kinds of quirks especially around filesystem access. When the projects officially package a flatpak it's generally all working.
I also use it like this. I got into it for the sandboxing, although I know there are a "few" lurking issues on this point. But, some of the sandboxing definitely works, and were I a flatpak engineer I'd want to see some indication of traction to justify working towards goals of completion, and no other project with any packaging base I can think of is anywhere close, so, I use it.
In fact...I think I have all the software packages you have, except Obsidian, but also, Signal, Anki, and Element.
I did consider using it to deploy and update a CLI on (multiple) Linux(es), but found that the design of common shells make that kind of thing uncomfortable, as you need to teach them about autocompletion and the user also has to muck with getting the utility into $PATH. Normal-style packages simply have the privileges to muck with /etc and /usr/bin and that's the end of that, but it is somewhat unsatisfying that this is almost necessarily the case.
> I am convinced now that they are one of the best ways to ship commercial software on to Linux desktop.
Commercial software would like a comprehensive and relatively stable API like what Windows famously provides. Flatpak's analog of the Windows API is the runtime. What level and duration of maintenance do Flatpak runtimes typically receive?
Well yes, these are all closed source binaries. In terms of usage it's not all that different to running them in a VM. In the bad old days we just did it in an XP windows VM instead.
I had issues with certain games crashing when run from Steam installed via Flatpak. It's not permission issues, but seems to be due to the Flatpak version bundled different system libraries. Have you encounter such issue on your end?
I haven’t, but I’m assuming those were (possibly old) Linux native games? Since proton shouldn’t have any dependency issues, especially since Steam installs that itself.
I switched to Fedora Kinoite (KDE spin of Silverblue) to force me to go all in on Flatpaks, and now I love them.
They make so much sense and work so well. I feel like the people who dislike them either never actually used them, or they’re just the type of person who hates change and will never be happy with new things.
Last I checked Flathub shipped with VSCode and IntelliJ, despite both having major broken parts. The VSCode workaround back when I tried Silverblue was to run sshd inside toolbox and remote Flatpak VSCode into it. It was definitely not a frictionless experience. And IntelliJ having the terminal and debugging broken removes most of the useful parts of the IDE for me.
Yeah, Flatpak has some kind of hangup about the idea that some tools need actually real full access to the system. Wireshark is similarly useless because you can't actually capture packets with it.
It is really strange that both this and "it's totally ok for packages to set their own security defaults" are true in Flatpak land.
If Linux starts attracting commercial development and we see an influx of new apps, wouldn't you feel safe knowing that the ones you install as flatpaks aren't allowed to capture packets on your system?
Wireshark is a tool more in the realm of development/sysadminry, whereas flatpaks are designed for more traditional apps, like Discord or Firefox.
I wouldn't want my development tools to come from flatpaks even if they had full access to the system, because I wouldn't have control over dependencies. Traditional system package managers are a better fit for that, and on Silverblue you have Toolbox for that.
> If Linux starts attracting commercial development and we see an influx of new apps, wouldn't you feel safe knowing that the ones you install as flatpaks aren't allowed to capture packets on your system?
See, here's the problem with letting packages determine their own defaults. I want the ability to give a Flatpak those permissions, not that they be able to give them to themselves. As it is, Flatpaks can give themselves permission to $HOME without ever notifying me, which I think is just as silly.
In my opinion, Flatpak should support a user-definable default permissions template that says "always permit", "always deny", and "don't care" for any given permission.
> you have Toolbox for that
Actually I agree that when it comes to these collections of software to build an "environment" something like toolbox/distrobox is a better fit. I have my issues with both[0], but the base concept is sound.
[0] For instance: why is podman required? The container functionality required is built into the kernel and podman has a lot of features that are entirely unused. Even bubblewrap has all that's needed and it is included anyway because of Flatpak. I will probably end up writing my own replacement for these tools.
I use Sublime Text, but I’ve also used VSCode, as well as a lot of other similar editors. I haven’t had a reason to use IntelliJ, but I’m sure it would work the same way.
Flatpaks are kind of like Android APKs, except unlike Android, there’s actually an operating system worth interacting with. An IDE on Android usually needs to include all of the tools it needs. A flatpak is the same, except that’s hard to get right for every development setup, so a toolbox just lets you do whatever you want with it. They’re podman containers with extra features to integrate with the host.
I have all of my development tools installed in a single toolbox, and have .desktop files for the GUI ones so that I can launch them from the KDE app menu as if they were regular apps. With this setup I can use e.g. clangd with the LSP plugin in Sublime Text, execute CMake, use the embedded terminal (Terminus), or the debugger plugin with lldb.
Most of these are proprietary. I view these third-party stores mostly as a way to ship proprietary software. Not sure what else they add, and the downsides of having yet another package manager on top of your system's are obvious. I'm surprised KDE is behind this.
Some sort of packaging standard that works across distributions would be beneficial, but it'd have to be integrated with the system's package manager, not tacked on.
> I used to think Flatpaks were a huge pain the butt, but over the last few years, I moved to using them for all third party software
I am a Nix person who has been a bit obsessed with package management for a long time, and it's probably fair to call me a bit of a 'container skeptic'. I know many good reasons to prefer other means of installing packages, and I agree with most of them. I care about things like the extra storage overhead, the increased app startup time, the additional complexity associated with portals and sandboxing, the extent to which Flatpak applications do or don't support the available sandboxing features, and the orientation of Flatpak towards enabling a larger proprietary software ecosystem I'm not very interested in.
But despite all of that, and despite my interest in— and to some extent, commitment to— competing paradigms... I think Flatpak does what it tries to do pretty well. It seems to me that the engineers working on it have done a pretty good job of mitigating the downsides and risks, like library duplication and difficulty of shared updates, disk usage, etc. Considering what it aims to do, it feels pretty fast, reliable, and neat. And I trust it way more than an apt or dnf or pacman repo hosted by the likes of Zoom, Google, Discord, etc. It's a much better way to manage third-party software than anything else we've got.
I think it's clearly a good thing that the biggest and most popular desktop environments are coalescing around it. This is good news for desktop Linux users in general, and especially good news for those of us who don't run Ubuntu or derivatives. The more things are packaged for Flatpak, the lower the burden for practical usage of distros maintained by small or new communities.
Obsidian without git plugin is pretty much a non-starter for me. What's the point in a folder full of markdown files that can't be checked into git? Only works out of the box for the AppImage, for now. I can't remember why. I suppose I am missing out on 0-click updates of some kind.
I started using Obsidian a few months ago, and my git repo is initialised on the file system outside the Obsidian vault. I'm now realising that I'm not using any of Obsidian's special features other than being a markdown editor with support for tags.
Flatpak is essentially RedHat/IBM tech. Why should Canonical even think about supporting their competitors. Just because multi billion corps like RedHat/IBM have the audacity to ask for donations to develop their products doesn't mean Flatpaks are in any way neutral territory.
Flatpak is supported by Endless [1], SUSE [2], Codethink [3], Collabora [4], Igalia [5] ... none of these businesses have an issue with "supporting their competitors" because that's an inherent part of doing open source as a business.
Ubuntu is Microsoft's "favorite" distro, they do seem rather made for each other.
The Azure dev tools on Linux i have tried are all Snap only, or a tar file and maybe an rpm/deb. At the moment they seem to avoid Flatpak like the plague.
Azure StorageExplorer is one i can recall of the top of my head. Although it's true a lot of dev tools will be CLI and not have too many dependencies (you would hope).
I would argue Microsoft's choice of Ubuntu is one based upon practicality and social inertia.
As far as I'm aware, Ubuntu is still the biggest player in the consumer Linux market not counting Android. Given the need to balance upkeep costs with range of support, I can see why Microsoft chose just Ubuntu and threw the rest to the wind.
It's pretty on-brand for Microsoft to select a consumer Linux distribution when building out their B2B cloud product, instead of (for instance) one of the leading business-oriented distributions.
I'm not sure if PopOs uses flathub by default for its PopShop, but I've always had some issues with it and they prevented me from using it and directly using flatpak CLI.
- I don't know how to see running logs by default (if it's possible even) and it's a must when you have slow internet
- sometimes it just hangs and I need to kill (probably leaving residue along the way)
hopefully my issues are my own OR it will get resolved as well.
Unlike google play, apple's appstore and canonical's Snap, flatpak isn't limited to a single repo, apps from other repos will show up in the store ui just like any other app.
App stores are gatekeepers, and while they certainly can make things more convenient, they also encourage habits that I think are harmful. Such as thinking that app stores are the only way to install applications. I think that it has been a bad thing that users are conditioned to think that if it didn't come from an app store, it's dangerous or wrong somehow.
It forces developers to use the app stores. I understand that many may not see this as a problem, but many developers (including myself) would very much prefer not to have to do that. So it's a disincentive to make software for others, at least for some.
In the case of this one, I also am very nervous about the incorporation of a payment system. I fear that will discourage the creation of quality free software, and I think quality free software is a huge benefit.
In short, I fear that this app store will resemble the Android Play store, or Apple's app store, and encourage the same problems and adverse impacts they have had.
I like Flatpak. I've even flatpaked some apps and made them available on Flathub. The only thing that dissapoints me is the fact that it integrates poorly with CLI apps.
Off topic: An idea that came to my mind a few days ago is that would have been great to add support for desktop apps to Podman by adding some extension or plugin capabilities to it instead of creating a new whole technology. Probably a silly idea though.
You can run generic sandboxes using Bubblewrap (bwrap) which is the underlying infrastructure for Flatpak. It's much lower level than Podman or Docker though, and closer to the basic reality of containerization as a usage pattern for Linux namespaces. You don't get compatibility with OCI specifications, so it's not the kind of containers that most people might be used to.
love to see flatpak flourishing, it's really great.
i like it because it actually solves problem (getting proprietary software like slack) instead of creating ones and/or getting in the way (i'm looking at you snap).
Sad to see so many people treat package management like a gatekeeper. "Oh, you don't have an employee dedicated to maintaining 20 versions of packages for every single distro and release of distro? Well we don't want you on linux"
Flatpak enables people to publish a single package that just works on all distos and doesn't break every 6 months. It's removing the maintenance gatekeeping.
I think it will be interesting to see if tech like WASM results in packages which work across CPU architectures as well as Linux on ARM is very painful currently, let alone more obscure ones like RISC-V.
maybe it's indeed time to let the system package management(apt,rpm,etc) just manage a solid BASE system, and let Flatpak etc to manage their own application sandboxes on top, kind of like dockers.
Appimage is macos flavor, it never needs your sudo to install the package, which is nice.
Flatpak is a redhat flavor(kind of), it needs sudo sometimes, but OK.
Snap is a ubuntu flavor(kind of), it is like systemd that can overtake the whole system, it can install package and even the whole system I was told, too much as a package manager for me.
I don't use Snap. Appimage is not as widely adopted as the rest two? I think Flatpak is a great middle ground.
It will be really cool if KDE and Gnome work together to build this.
> maybe it's indeed time to let the system package management(apt,rpm,etc) just manage a solid BASE system, and let Flatpak etc to manage their own application sandboxes on top, kind of like dockers.
This is kind of how immutable systems like fedora's silverblue, and suse's microos are setup.
The base systems are still built with rpm, but for user packages you either use flatpak or stuff in containers via toolbox or distrobox.
It's still possible to layer stuff on to the base image if necessary though.
Sandboxing and distro-agnostic packaging are definitely the way to go. They have some pain points but it's better to fix those than to go back to the older way of doing things.
Richard Brown, who's been working on this problem for 10 years at Suse, says he was wrong in 2017. Flatpak is now the clear way to go, if you care about security, app updates, licensing, and multi-distro support (runtime dependencies).
Flatpak offers convenience but it could never offer the security that the distros it is circumventing offer. Application bundling is just inherently insecure.
Interesting that this announcement comes concurrently with the news that Ubuntu now expects all official derivatives to drop Flatpak support [0]. Looking forward, can someone tell me how these two policies will play nice together?
Can anyone comment on whether any of these new all-in-one distribution formats actually try to provide secure sandboxing that is designed to resist deliberate attacks from within, or is their sandboxing just docker-style best-effort sandboxing with a ton of holes that can't be relied upon for running untrusted executables securely?
426 comments
[ 3.3 ms ] story [ 323 ms ] threadI think part of the problem with a lot of "selling stuff on Linux" has been mucking around with different dependencies for the thousand different versions of Linux.
Historically, this has led to a couple solutions: either a) Just officially support one distro (usually Ubuntu), or b) just don't release a Linux version.
Flatpak has actually succeeded in making a system that kind of works everywhere, and I think it actually has a shot of being an equivalent to the Mac App Store.
This I agree with, but not this:
> and does actually do a good job of making "one package manager to rule them all".
That's not its goal. There are no terminal apps in it, so everyone that wants to run custom packages from a terminal is still going to need something like apt/dnf/homebrew.
Regardless of your opinions of GNOME and KDE, it’s hard to argue Flatpak has anything but good intentions, it’s made by people who want the Linux desktop to be better
I am reminded of that one game dev who dropped Linux support because 99% of their bug reports were coming from 1% of their total playerbase (read: the Linux crowd).
You can fork the base repository and just add the packages you want to have installed on your host system. Everything else is handled with flatpaks or with distrobox containers, or you could technically install whatever else package management system you wanted to.
If you use the gnome Software app, it merges flatpak, dnf, and the firmware updater in one “updates” page with a single button to update it all.
Perfectly true, and my comment was the kind of irritated snark about imperfect open source software that I don't like hearing from other people! It just so happened that I had launched Software literally about 5 minutes previously for the first time in months and it .. sat there and did nothing.
I do think it's a good idea though, at least while we have this hopefully transitional period of multiple overlapping packaging/update systems. I get a bit tired of having to think in terms of flatpack and dnf and asdf and cargo and pnpm and .. not to mention all the odd bits and pieces I install & compile from source and forget to update.
I guess it's mostly the kernel and my DE these days.
Also as far as I remember flatpack is something more complex than a simple package format, it has a runtime where each application runs in an isolated container where it can access only some of the resources (e.g. the filesystem). This adds to me useless complications to a system.
I think that the best approach to the integration of third party software is the one followed by ArchLinux, that is the AUR: a series of build instructions, maintained by the community, that allow you to package practically any piece of software that exists.
They are completely inadequate for closed source software like games. Flatpak provides a stable platform you can target and it just keeps working across distros and in to the future while rpm/deb packages require constant maintenance.
Flatpak also provides a long list of essential features like permissions, sandboxing, portals, etc which most other OSs do. The future of linux is likely immutable OS images with something like OSTree, and then flatpak for end user apps.
Why? What difference does make the license of the software? The only trouble is that the developer of the proprietary software has to package it in a number of formats and have repositories to download updates (that are HTTP servers with some special files in it). In reality to this day you just have to package a .deb, and if you want .rpm. For other distros these packages can be converted practically automatically (this is what is done with ArchLinux AUR for proprietary packages like Spotify or Chrome that are installed from the deb version).
> working across distros
This doesn't have a lot to do from the packaging format but on how you write the software. If you dynamically link 2000 system libraries you can as well use flatpack but the software will not work since typically on Linux the ABI is not that stable. If you have a single statically linked binary with MUSL libc you can as well package it as a deb and run it on Debian 4 that it will probably work.
> Flatpak also provides a long list of essential features like permissions, sandboxing, portals, etc which most other OSs do
They are not essentials. And they cause more problems to the user than what they solve. And don't talk me about using containers for security, since they don't provide any useful and proven safe isolation. On the other end you have SELinux/AppArmor that you can apply easily on any executable regardless of the packaging format.
> The future of linux is likely immutable OS images with something like OSTree, and then flatpak for end user apps.
This is wanting to go in the direction of what Apple does on macOS/iOS where the / is immutable. I think that people use Linux because it's different, if not they would just buy a MAC. These are complications that gets you in the way.
Linux users wants to be able to build the system by picking the components they want, not the components that Canonical or Red Hat decided that they must be present in their distribution.
Apparently changes in GTK4 made it easier to add
Looks like it's getting fixed, though.
By now, Snap is such a fundamental part of Ubuntu that it begs the question whether Ubuntu is right for you if you want to avoid it. Why not use a derivative or upstream that makes different choices?
Seriously though, just install Debian. It's not hard, the netinstaller may be text-mode but it walks you through the simple steps one by one just like Ubuntu's GUI installer. Anybody who's comfortable using Ubuntu in the first place should be able to get through the Debian installer just fine.
(For work, where I just want something that won't make me "the asshole who chose [non-standard thing]". I prefer Void or FreeBSD or, sometimes, Debian, for my own stuff)
[EDIT] Oh, right, specifically for desktop? Yeah, I'd go Void or Arch probably. Buuuuuut if it were for work, I'd just use Ubuntu, even on the desktop, so it wouldn't be my fault when it misbehaves.
I meant more so for people who are somewhat active on these discussions but still go with Ubuntu.
Nowadays you can get a full featured, well integrated and properly working user land on Linux with next to zero customisation with systemd and Gnome. I really recommend using a distribution which stays as close to vanilla as possible.
Debian would still patch far too much to my taste without the integration anyway.
They remove/rebrand what they don't find free enough, want to make things "modular", want to split development and base packages, want to support a ton of architectures upstream doesn't care about and want to integrate things in their historic tooling. It has introduced some severe bugs in the past.
Edit: I just checked for the classic case of latest Python (3.11), and the answer for Debian is to build from source, which is annoying (not difficult to compile, but then future updates can't be pulled in via apt). Does Debian not have a vibrant PPA community to fill the gaps like Ubuntu?
https://news.ycombinator.com/item?id=31643316
Yeah, it does: the Ubuntu PPA community. (See https://wiki.debian.org/CreatePackageFromPPA, and similar.)
In my experience, the stability concerns are overblown, and it makes for a really nice rolling release system. I've had individual systems run for over a decade on a Debian testing install with rolling updates, and it's generally been far less of a headache than Ubuntu releases.
I like Debian, but after (free)Ubuntu pro, it really became attractive for me as a small server operator, its even better than free RHEL.
Its also much easier to install on cloud servers than RHEL.
"Ubuntu pro" is basically trying to fix this shortcoming compared to debian and to pay for a security team for universe. It is available as a subscription.
TLDR: If you use software from main it is completely irrelevant. If you use stuff from universe it is now as good as debian, if you pay (first 5 devices are free).
Running with the crowd has some advantages. Many feet passing on the path before you trample more bugs before you get there etc.
For anyone looking to use debian I highly recommend it and prefer it to any other distro.
This is nice if you're dual booting Windows 11. It's also probably going to increase the Ubuntu's representation in desktop Linux by virtue of booting without any EFI setup tinkering, because a lot of people's patience ends exactly where things cease to work as expected.
Since there are so many people that don't have this problem, I understand that it's something I'm doing wrong -- but I have never been able to figure out what that is.
This was well over a decade ago though :)
What I mean is that I can't get Ubuntu to work at all. On my luckiest tries, I've managed to get the desktop to show, but everything is still highly unstable and I've never pushed on to trying to install software.
I used to think it was driver issues, except I've had similar symptoms on three different machines. And before people jump down my throat -- I'm not saying this is a problem with Ubuntu. I admit that I must be doing it wrong. But it's a showstopper deal for me anyway.
Admittedly, the last time I tried was a few years back. Eventually, I just had to give up and move on with my life.
As a fairly begrudging Ubuntu user (I put it on a laptop because I didn’t want to screw around with finding drivers, memories of trying to get wifi working on Arch with some dongles haunt me), I have to say I don’t really like it much overall but they’ve got the “getting to the desktop” experience down pretty well.
No. I do tend to use old hardware, but tried it on a mainstream new laptop one time. On that, I couldn't get the WiFi to work with it.
What baffles me is that on all of these machines, Debian works out of the box. In fact, Debian's never failed me on any of the many machines (including laptops) I've put it on.
Ubuntu is based on Debian, so I can't explain the difference. As I said, it's been a while and perhaps they've fixed issues, but I've moved on. My life is no poorer for it.
The only thing is that it means I can't recommend Ubuntu to people (not only because I wouldn't be able to support them if they have trouble, but what am I supposed to say? "I can't make it work, but use this!"?)
Prevent dynamic linking?
Offer strong backwards compatibility?
Add support for a very wide range of hardware?
Put advertisements in the start menu?
Cause unexpected reboots for updates?
Send telemetry to the OS manufacturer?
Force users to get an online account unless they know the secret way to bypass the prompt?
Or is there a differentiator between Windows and Linux I am overlooking?
What you should look at is the difference between Debian and Devuan. Or between Debian and OpenBSD, to understand what the systemd project is doing, and how it’s doing it.
There are many of us that prefer Linux as it was before systemd.
systemd was actually inspired by launchd, not Windows. But I guess systemd, Windows and launchd do share one thing in common which is not having a bunch of bandaid shell scripts hanging the system together.
I don't think I've seen anyone complain about systemd's init system or service manager; it's always about the remaining 90% of systemd's scope and its tight coupling between all its parts (the tight coupling being the main problem).
Removing Snap is not that hard, the "hardest" part is making sure that Firefox is installed from the Mozilla PPA and even that takes just a moment once you have the script saved somewhere.
By the way I had a look at some Ubuntu derivatives like PopOS or Mint and I might take the plunge at some point.
In my case, it's because my options are pretty much Ubuntu or Windows for this machine, and there's no contest there.
Unless I have another reason to reinstall Linux, it’s far easier to uninstall Firefox and the other handful of Snap apps and just use Flathub/flatpak exclusively. I just need to be careful I don’t pick the default store app when searching for software.
In my experience Ubuntu's default store app can be safely uninstalled once you have Flatpack's store app. In fact I recommend doing that as their functionality overlaps quite a bit (e.g. you will get duplicated update notifications if you have both stores installed).
(The above assumes that you got rid of Snap. Otherwise you may still need the default one)
Ubuntu also as better hardware integration ( drivers ) and more modern kernels. AS a matter of fact it has many kernel for deferent usage.
People use Ubuntu because it works just fine out of the box, you don't need to install a third party non free drivers to get your wifi card to work. I still have nightmare with debian because they used to not ship proprietary drivers so you would have to cary a USB stick in the datacenter with drivers on it to make network cards working.
https://www.omgubuntu.co.uk/2023/01/ubuntu-zfs-support-statu...
But that doesn't change the fact that ZFS itself is in the Ubuntu repos, tested against Ubuntu's kernels (it's a kernel module, so this is important), and _really easy_ to install: `sudo apt install zfsutils-linux`.
Personally on my box, I boot off a small NVMe SSD formatted ext4 (installer defaults) and then have all my hard drives in a ZFS pool to store my data. If /r/zfs is to be believed, this is a common setup.
As for Flathub itself, it's like the Snap Store... but you aren't locked in, and the backend is open-source, and it's not directly owned by a distribution maker (even though it is definitely closer-in-kindred with the Fedora Project), which makes it far more palatable to people with even a modicum of understanding of the Linux and FOSS philosophy.
I harassed them nearly 6 years ago about this. https://forum.snapcraft.io/t/external-repositories/1760
cat << EOF > /etc/apt/preferences.d/nosnap.pref Package: snapd Pin: release a=* Pin-Priority: -10 EOF
One thing I don't do is use Flatpack, AppImage or any substitute for snap. If I wanted that functionality, I'd use snap.
I don't like apps installed via snaps (etc.) changing themselves almost seemingly stealthily.
Anyone have the connections to make this happen?
Valve actually uses bubble wrap on the Steam deck for proton.
I’d be happy to pay for Linux software but there is no way I’d want to be tied to a particular distro/repo/storefront.
There's basically Steam or DIY.
If they used the royalties to hire people to audit the packages I might even consider paying for free software, but I'm afraid it will turn into walled gardens where small developers have no say and the big ones just deal with the problems because it's the only option.
I hope it turns out to be better with KDE and Gnome that come from a FOSS background but money makes people greedy.
However, I don't really understand why something like Flathub is needed in order to sell it. That's not been a major issue in my experience.
Is the main point to provide a payment processing service?
Also this seems to be a confusion about what FOSS is. FOSS "freedom" isn't about "free as in beer", it's about "free as in speech." The GPL even welcomes commercial software, provided they include the source. I'd be thrilled to see a category of "paid FOSS" in the store, and I'd buy quite a bit of it if prices are reasonable and the software is useful.
I do hope the command-line UX around flatpaks (installing, updating, etc) improves a lot though as currently it leaves much to be desired.
There's far fewer applications because there's a very tiny market share compared to these two OSes. Not because of the lack of payment systems.
In his most recent talk he basically said, he was wrong, the Flatpak people did address most of the issue he had and AppImage was no viable.
https://fosdem.org/2023/schedule/event/containerised_apps/
I even don't have to manually write them, KDE has kmenuedit.
What about appimage instead, like Krita? To me it's sounds like the best way to distribute a linux app in 202X...
Managing to make things run on Linux gives a sense of accomplissement, at the same time, I can understand why most people won't move to Linux anytime soon given all the complexity involved... or it's just me and there was an easier way to install flatpack at first place?
AppImage solves the packaging problem in a bad way (ugh, loopback mounts), but does not solve the dependency problem, try run AppImages compiled for Ubuntu on Fedora..
[Retort insult.]
AppImage is just the least bad solution - if nothing else it doesn't need some weird infrastructure to run. As a developer you just upload the binary to your site and as a user you just download the binary and run it.
Like if you want to select a desktop and are kind of new to desktop environments, maybe aim for the (imaginary example here) DE-5 level of standards-adherence. DE-4 and lower might suck in various ways even though they could have cool new features.
There are way too many benefits from the huge variety of DE approaches, including the benefit that Linux-critics often hide behind critique of a single desktop experience, which is lazy and attempts to steal focus from exactly this open, creative, diverse approach that is the jewel in the Linux ecosystem's metaphorical crown.
It's definitely great to see the groups working together on these projects that benefit everybody.
What's the difference? If everything works perfectly with everything else, and the standards adherence is so high that you can't tell the difference which apps are from which organization, then how is that not a "unified DE"?
OTOH, if you think there are good, detailed reasons why XFCE is not KDE is not Gnome is not LXDE, then you can probably see why standards are helpful, insofar as they can be designed to be reachable without compromising unique leverage points.
We of course already have something like this (POSIX, Freedesktop, etc). However neither is abided by very well and neither of them go far enough up the stack to deal with certain very visible issues of desktop application incompatibility.
What I think could be done to fix some of the compatibility issues (like when running QT on gnome or GTK on KDE or applications that eschew them both and have janky window decorations) would be some more serious standardization onto something like Wayland. We would of course need something more than a reference implementation for that, but fundamentally I don't see why that would be too restrictive for projects that still want to make their own widgets.
There'd also be a standard for e.g. IPC-based interoperation with file picker dialogs, such that if you were running GNOME as your DE, QT apps would (tell the DE to) pop the (GTK!) file picker to open a file, which would then signal back to the app through some standard message format for describing picked files (maybe with the file-handles themselves passed over a Unix domain socket, if you want something like macOS's sandbox-piercing file-open-intent tokens.)
There'd be a single "accessibility DOM" standard, so that a GTK screen-reader could read the text out of QT apps.
There'd be a single shell namespace standard, with one common set of abstract data types (with multiple implementations), so that opening some GVFS virtual folder in a KDE app would actually work — probably through D-Bus integration between the KDE app and some libgvfs host runner agent.
And so forth.
The ecosystems of each DE would remain distinct in development, with apps designed to fit well together... but the feeling of DEs being walled gardens would be gone, because the various standards would force each app to be a "chameleon" to whatever DE it's running under.
There are a few tiny attempts at this under FreeDesktop. xdg-open(1) is a good start. But we could be doing so much more.
I'm using a very minimal system without a lot of the easy to implement features on purpose, but absolutely can not live without some of the more difficult ones. So for me the adherence would be cherry-picked parts from 3, 4 and 5 and impossible to place on a chart. I don't think it would be a good fit for the modular unix philosophy.
[1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
[2] https://specifications.freedesktop.org/basedir-spec/basedir-...
[3] https://specifications.freedesktop.org/wm-spec/latest/
As opposed to, say, standards that are based on general user experience aspects. Does the control panel offer printer settings yet, for example.
At the lowest level you have the kernels (KDE and Gnome both run on Linux AND BSD) which may or may not have drivers built in. Then comes the distributions which are opinionated in the kernel versions, packages and patches they add.
Some of those packages are desktop environments or window managers and they are opinionated in how they run other packages and their lifecycle. Some full featured others are tiling. Some of them run on both Xorg and Wayland.
Last we have the actual packages, and they need to work in all these different environments, sizes and lately different protocols. They need to support different drivers, permissions and file system hierarchies. They do this by relying on each other, a package handling video focuses on supporting video and sound drivers so other packages can import that package.
KDE might have a very polished and up to date settings panel, checking for all drivers and their features. But in reality it works as intended on Ubuntu, but Debian is behind and doesn't want to patch the drivers because stability, on Arch there was a regression and most of the BSDs don't even support the driver. And one time Linus came along and didn't listen to the warnings and fucked it all with one line.
Nobody controls all of these pieces and they're so spread apart that what might seem as simple as a panel for printer settings quickly gets very complicated. But I wouldn't have it any other way. For those who want the one size fits all there are already options.
And it's gotten better too - did you know KDE3 had it's own sound mixer daemon? It was called ArtsD. Now we have pulseaudio, or whatever, which is great and cross desktop
DBUS made it everywhere as well - I believe initially KDE3 as well did not have DBUS but had something called, DCOP. so - yeah things have improved a lot and many things - even command line tools 'playerctl' interop well based on this.
More fun is also like libreoffice is compiled with many different file pickers, so on KDE you can use the native Qt extended KDE file picker, and on Gnome you get the GTK one.
I used to be on this hill. All this leads to is inoperable software where each integration point is liable to break. I want to get away from the spyware that is Windows, the walled garden that is MacOS. If a uni-desktop is the price we pay, so be it.
Of these, I would say that Cinnamon is one that could be comparable to XFCE or even GNOME and KDE. Seriously, it's good. The system settings menu has all of the options one could need and the look and feel of the dektop is very customizable.
I'm a KDE user, but if it ever stopped working/disappeared I would use Cinnamon. In fact I plan to use it whenever KDE Plasma 6 releases to wait out until the it becomes more stable.
IIRC KDE committed to never break users again like they did with the first releases of KDE 4. It's expect the first releases of Plasma 6 that the distros will actually ship to be stable, and to be mostly a Qt5 → Qt 6 upgrade. You should be able to run a stable version of Plasma (5 or 6) in any case during this period. KDE 3 to 4 was a disaster; last versions of KDE 4 were rock solid. First versions of Plasma 5 were a bit lacking but rapidly became very stable and usable, and you could actually keep using KDE 4 in the meantime. I expect the Plasma 6 transition to be even smoother. I hope I'm not wrong.
But otherwise I agree, Cinnamon seems very good and I tend to recommend it and pick it for people who I install Linux for.
...though I do lament the loss of Desktop Cube.
Of course, coming from Awesome I am often annoyed at how Plasma doesn't have per-screen (X11 monitor, if I'm not mistaken) tags and per-X11-display workspaces don't really work that well.
What were your issues? What was the distro?
Forgive the vagueness, but I don't believe in memories and haven't kept a journal. Still, as completely unreliable and untrustworthy human memory is I am inclined to believe I had issues with Plasma 5 during the transition period.
Either way I think that still sounds better than the old 3->4 migration, and hopefully 5->6 can be better still!
No thanks. GNOME dev hubris is the reason I use KDE
Personal example from trying GNOME out recently: I have an external webcam, which means I need to move the GNOME panel clock since it's in the top middle of the screen (and thus blocked by the base of the webcam). You would _think_ that would be easy, but you have to get an extension just to move the clock! Apparently each panel "widget" (this may or may not be the official term) defines its own position on the panel. So, to move something, you need to either find an extension that does it (Frippery Move Clock[0] in this case) or edit the widget code yourself.
Maybe someone can chime in with a technical explanation, but my cynical take is that the GNOME devs don't even trust users to be smart enough to customize their own panel without breaking things.
</vent>
0. https://extensions.gnome.org/extension/2/move-clock/
1.: https://github.com/thestinger/termite
They say this is desirable functionality, but that they would want to subsume termites features in VTE and Gnome Terminal, and that was their rationale for rejecting the patch. Then they didn't deliver those features in a timely fashion.
That's just abhorrent behavior.
I'm gonna say citation needed on that one. In fact, I have seen many rants about desktop software trying to look like touchscreen software.
Now I'm writing this reply from KDE, quite comfortably, and it's quite stable. Comfortable, even. And it doesn't get stupid and die when I plug/unplug monitors and stuff.
I'm not really against it, but I don't use KDE or Gnome (or any of the others in your list) and it concerns me that people might start thinking of those as "being Linux". I'd hate to see a future where "We support Linux" means KDE or Gnome.
On the other hand, I have to admit I'm not really sure what that would mean. I guess only having "Flatpak" as an option would be a bummer, but I don't see that happening with the distros I use.
This would be terrible. Gnome and KDE have pretty conflicting ideologies. Gnome is super opinionated and Mac-like minimalist. KDE is all about user choice.
If they'd collaborate it would end up something in the middle which would suit nobody.
The problem with this is that Mac, unlike Gnome, actually works. Gnome just has weird holes where old functionality was removed (like application menus!) and never replaced.
Yeah. Without proper window management, middle click and other things I need 3rd party apps for.
...you can't compare minimalism/configurability in this way
Ed: one minor (but somewhat understandable annoyance) is the lack of a free/reserved for users modifier key. Macos with the adoption of bsd uses both command, option and control (even though it uses command for core things like copy/paste). The windows/super key is a blessing on Linux pcs - as it generally can be used for just that - window management).
I know some rebind caps lock as a super (ed2: I mean "hyper", I think) (aka ALL THE MODIFIERS) key on Mac - but that leaves control in the wrong place :/
Maybe there's no RSI in Palo Alto?
https://github.com/koekeishiya/yabai
https://github.com/koekeishiya/skhd
I think the only issue I ever had with them was the inability to inject files inside. Do you know if that's possible?
I was trying to use a browser, I think Vivaldi, that had instructions for enabling widevine by copying a file to a certain directory, but I couldn't find a clean way to do so.
It will depend how an app has been packaged, but when well done the sandboxing is invisible.
Now, maybe the Linux approach is so good and useful in other ways that it's worth putting up with that, but it is a big problem and people are going to solve it, one way or another. If the model can't be changed, then the only solutions available may be bad, but they'll be used, and widely.
No, it is not. If you want security you need dependency management and software lifecycle management on all OSes and platforms.
Multiple versions of openssl is a security problem that merely updating cannot solve.
Besides, sufficiently quality minded projects always wind up vendoring all of their dependencies anyway. There's a reason Chrome has their own fork of everything down to the compiler.
Plenty to criticise about it from a product perspective but from an engineering one it is kind of a marvel.
On my GFs computer Chrome starts in about 7 minutes after fresh boot, no other programs running, yet. From a fricking Samsung SSD, 8GiB RAM. All it has to do is show some fake tabs and render a single page content.
Tell about its quality to my GF. She's used to it, but some of these days, I'll check the DNS logs, to see if it's really loading all the 1000 tabs (she keeps open at once), for 0 reason whatsoever, or if it's just that slow to start one page.
There is something wrong with your GF’s computer. I have no idea what but a seven minute start time is absolutely atypical.
I actually know of quite a few people who use browsers this way, so it may not be a terrible idea to have something like this.
Also the same chrome profile starts very fast when she uses the "private browsing mode" which doesn't restore any tabs. So it really just seems like chrome having perf issues with tab restore with many tabs.
But anyway the point still stands: an outlier user with 1000 tabs open had a slow startup time doesn’t mean Chrome is horribly engineered. If it isn’t an extensions issue then it’s a minor bug.
It's not about quality. It's about reproducibility of the exact versions of all dependencies. It's about communications with repos not being subverted to load malicious packages. It's build security not app quality, though app quality is a part.
Meanwhile we have distros lagging behind for years to provide a new package because they can't break all the things depending on the old version.
I'm glad I left this category of problems behind me 5 years ago when I switched both, my personal and my work laptop to arch-linux/i3wm. These two machines have been running for 5 years, almost daily, with almost no issues, with the latest software packages. If the hardware lasts, I will go on like this for another 3 to 5 years and then upgrade hardware and (maybe) switch to wayland. I don't see anything on the horizon which would make me switch away from this setup.
Come to think of it I can probably prune one of the windows...
ETA: and maybe one of the workspaces...
Which part of Arch's design prevents the issue described in the grandparent post? The issue is "distros lagging behind for years to provide a new package because they can't break all the things depending on the old version", which is solvable either with enough manpower or by sandboxing a la NixOS, where you can keep old versions around indefinitely for the things that need them. Does Arch use such sandboxing now?
As a former long-time Arch user, you're correct. It's "just" a distro not unlike the biggest one. The reason Arch repos are fairly well updated and big is the relatively easy to understand PKGBUILD format and the tooling around it, which lessens friction on package management.
But this gets to the mindset that bugs me about Flatpak, the magical thinking that regressions don't happen. It's why Alice can't downgrade a system flatpak because it might introduce a vulnerability she uses to attack Bob, but it's absolutely fine if she upgrades to introduce that vulnerability.
[1]: https://itsfoss.com/downgrade-flatpak-packages/
Only when the version you want to downgrade to happens to be within the last 10 versions! Why 10? Beats me!
Case in point: the flatpak package for the Element messaging client seems to be the preferred installation method for non-debian distros. But for many users, encrypted message search is broken! [1] [2] Some users claim that downgrading can fix the issue, but the flatpak has been updated too many times now for any user to downgrade to an old enough version - tough luck!
[1] https://github.com/vector-im/element-web/issues?q=is%3Aissue... [2] https://github.com/flathub/im.riot.Riot/issues?q=is%3Aissue+...
It has access to X11 <https://github.com/flathub/com.spotify.Client/blob/0856c7641...>, so it could also be running a keylogger.
Sandboxing should be a separate tool independent of packaging systems and anything else .
With an open sandbox by default for many apps…
The first one is the second one.
Trying to make sense of Flatpak's threat model is just near-impossible. It might protect you from something, if the specific app's configuration told it to do so. Starting a random Flatpak app, you have no guarantees, and the UX doesn't communicate anything about this.
You are cherry-picking the spotify session token while many other applications have valuable personal data.
Also sandboxing is also implemented by the OS. It is not an advantage of flatpak.
but that's a problem, too.
i'd rather all things on a system be bottleneck-forced into using the latest version of security libraries that my system is actively updating; yes, this causes issues, but not issues like "There was a huge vulnerability found in X version Y, does it affect me?".
in other words, i'd rather have system breakage than insecurity. That's a personal taste, I admit.
that said, the sandboxing aspect behind 'the new ways' is fantastic.
Which is to say most people use a computer to run software, so if the software doesn't run the security is pointless anyway.
Sure, if only some software breaks and you can wait for fixes that's a tradeoff, but given that in package maintainer land those fixes could be months or years away...
And how many of them are critically out of date because the software maintainer didn't update? Who can say? That's the beauty of flatpack (not).
With flatpack you have all the downside of static linking with none of its advantages, how exciting. (and there's nothing as cool as having 7 full linux distros installed on your computer at once, just because software can't agree on which base image to use)
...until attackers find a vulnerability in some library, then you are really in trouble.
Just like docker, the bundling of tons of software into opaque blobs is terrible for security.
- Installation (no manually moving files from ~/Downloads)
- Launcher integration (no writing .desktop files by hand)
- Auto updating
As far as I saw, AppImage didn't have any of that. Though it was a while ago (and maybe some of this was my distro's fault). Has any of this improved lately?
How are people keeping their AppImages updated?
But Linux Desktop has a nasty habit of adopting over engineered solutions instead of simple ones, especially if any other desktop OS is doing it that way.
The only software I run as an AppImage is BitWarden (from the official GitHub repo[1]. It prompts to update itself when there's a new version which works very well.
[1] https://github.com/bitwarden/clients/releases
ive been using flatpak more myself these days but i hope the appimage format sticks around because its handy being able to quickly try out some software and then delete it when you are done, or to try out a new version of something and have both running at the same time
Installation, launcher integration:
https://docs.appimage.org/user-guide/run-appimages.html#inte... https://docs.appimage.org/reference/desktop-integration.html
https://docs.appimage.org/user-guide/faq.html#question-how-c...
Updates:
https://docs.appimage.org/packaging-guide/optional/updates.h...
What was missing was convenient sandboxing. Firejail was recommended but with the responsibility entirely on the user to install and use it.
Flatpak doesn't limit access by default (or rather it does but apps can just ask more permissions at build time and it's not prevented by default IIRC) but offers the user some options for being more strict without needing extra tools.
Nor is their FAQ describing their sandboxing as a security feature, more like (limited) isolation technique.
But this isn't stopping flatpak zealots who just won't shut up about the "sandbox == secure" falsehood.
I don't know, I'd rather prefer a technology which is upfront about its lack of security than one which has glaring hole in what they call (a false sense of) "security". I treat flatpaks and appimages as mostly equal things and use them to keep and run proprietary stuff so that I know it won't be shitting its guts all over the host system.
In fact...I think I have all the software packages you have, except Obsidian, but also, Signal, Anki, and Element.
I did consider using it to deploy and update a CLI on (multiple) Linux(es), but found that the design of common shells make that kind of thing uncomfortable, as you need to teach them about autocompletion and the user also has to muck with getting the utility into $PATH. Normal-style packages simply have the privileges to muck with /etc and /usr/bin and that's the end of that, but it is somewhat unsatisfying that this is almost necessarily the case.
Commercial software would like a comprehensive and relatively stable API like what Windows famously provides. Flatpak's analog of the Windows API is the runtime. What level and duration of maintenance do Flatpak runtimes typically receive?
https://developers.redhat.com/blog/2020/08/12/introducing-th...
Well yes, these are all closed source binaries. In terms of usage it's not all that different to running them in a VM. In the bad old days we just did it in an XP windows VM instead.
They make so much sense and work so well. I feel like the people who dislike them either never actually used them, or they’re just the type of person who hates change and will never be happy with new things.
Last I checked Flathub shipped with VSCode and IntelliJ, despite both having major broken parts. The VSCode workaround back when I tried Silverblue was to run sshd inside toolbox and remote Flatpak VSCode into it. It was definitely not a frictionless experience. And IntelliJ having the terminal and debugging broken removes most of the useful parts of the IDE for me.
It is really strange that both this and "it's totally ok for packages to set their own security defaults" are true in Flatpak land.
Wireshark is a tool more in the realm of development/sysadminry, whereas flatpaks are designed for more traditional apps, like Discord or Firefox.
I wouldn't want my development tools to come from flatpaks even if they had full access to the system, because I wouldn't have control over dependencies. Traditional system package managers are a better fit for that, and on Silverblue you have Toolbox for that.
See, here's the problem with letting packages determine their own defaults. I want the ability to give a Flatpak those permissions, not that they be able to give them to themselves. As it is, Flatpaks can give themselves permission to $HOME without ever notifying me, which I think is just as silly.
In my opinion, Flatpak should support a user-definable default permissions template that says "always permit", "always deny", and "don't care" for any given permission.
> you have Toolbox for that
Actually I agree that when it comes to these collections of software to build an "environment" something like toolbox/distrobox is a better fit. I have my issues with both[0], but the base concept is sound.
[0] For instance: why is podman required? The container functionality required is built into the kernel and podman has a lot of features that are entirely unused. Even bubblewrap has all that's needed and it is included anyway because of Flatpak. I will probably end up writing my own replacement for these tools.
Using development tools as a flatpak is usually not a good idea for many reasons. That’s why Silverblue ships with Toolbox (https://docs.fedoraproject.org/en-US/fedora-silverblue/toolb...).
Flatpaks are kind of like Android APKs, except unlike Android, there’s actually an operating system worth interacting with. An IDE on Android usually needs to include all of the tools it needs. A flatpak is the same, except that’s hard to get right for every development setup, so a toolbox just lets you do whatever you want with it. They’re podman containers with extra features to integrate with the host.
I have all of my development tools installed in a single toolbox, and have .desktop files for the GUI ones so that I can launch them from the KDE app menu as if they were regular apps. With this setup I can use e.g. clangd with the LSP plugin in Sublime Text, execute CMake, use the embedded terminal (Terminus), or the debugger plugin with lldb.
Most of these are proprietary. I view these third-party stores mostly as a way to ship proprietary software. Not sure what else they add, and the downsides of having yet another package manager on top of your system's are obvious. I'm surprised KDE is behind this.
Some sort of packaging standard that works across distributions would be beneficial, but it'd have to be integrated with the system's package manager, not tacked on.
I am a Nix person who has been a bit obsessed with package management for a long time, and it's probably fair to call me a bit of a 'container skeptic'. I know many good reasons to prefer other means of installing packages, and I agree with most of them. I care about things like the extra storage overhead, the increased app startup time, the additional complexity associated with portals and sandboxing, the extent to which Flatpak applications do or don't support the available sandboxing features, and the orientation of Flatpak towards enabling a larger proprietary software ecosystem I'm not very interested in.
But despite all of that, and despite my interest in— and to some extent, commitment to— competing paradigms... I think Flatpak does what it tries to do pretty well. It seems to me that the engineers working on it have done a pretty good job of mitigating the downsides and risks, like library duplication and difficulty of shared updates, disk usage, etc. Considering what it aims to do, it feels pretty fast, reliable, and neat. And I trust it way more than an apt or dnf or pacman repo hosted by the likes of Zoom, Google, Discord, etc. It's a much better way to manage third-party software than anything else we've got.
I think it's clearly a good thing that the biggest and most popular desktop environments are coalescing around it. This is good news for desktop Linux users in general, and especially good news for those of us who don't run Ubuntu or derivatives. The more things are packaged for Flatpak, the lower the burden for practical usage of distros maintained by small or new communities.
Smells like that old MS attitude to me.
[1] https://support.endlessos.org/en/apps/flatpak [2] https://fosdem.org/2023/schedule/event/containerised_apps/ [3] https://www.codethink.co.uk/articles/2022/flathub-codethink-... [4] https://www.collabora.com/news-and-blog/blog/2017/08/17/debc... [5] https://github.com/Igalia/webkit-flatpak-sdk
The Azure dev tools on Linux i have tried are all Snap only, or a tar file and maybe an rpm/deb. At the moment they seem to avoid Flatpak like the plague.
As far as I'm aware, Ubuntu is still the biggest player in the consumer Linux market not counting Android. Given the need to balance upkeep costs with range of support, I can see why Microsoft chose just Ubuntu and threw the rest to the wind.
- I don't know how to see running logs by default (if it's possible even) and it's a must when you have slow internet - sometimes it just hangs and I need to kill (probably leaving residue along the way)
hopefully my issues are my own OR it will get resolved as well.
other than that flatpak is amazing.
I hope, if this succeeds, it turns out to be a good thing.
It forces developers to use the app stores. I understand that many may not see this as a problem, but many developers (including myself) would very much prefer not to have to do that. So it's a disincentive to make software for others, at least for some.
In the case of this one, I also am very nervous about the incorporation of a payment system. I fear that will discourage the creation of quality free software, and I think quality free software is a huge benefit.
In short, I fear that this app store will resemble the Android Play store, or Apple's app store, and encourage the same problems and adverse impacts they have had.
Off topic: An idea that came to my mind a few days ago is that would have been great to add support for desktop apps to Podman by adding some extension or plugin capabilities to it instead of creating a new whole technology. Probably a silly idea though.
i like it because it actually solves problem (getting proprietary software like slack) instead of creating ones and/or getting in the way (i'm looking at you snap).
Flatpak enables people to publish a single package that just works on all distos and doesn't break every 6 months. It's removing the maintenance gatekeeping.
I think it will be interesting to see if tech like WASM results in packages which work across CPU architectures as well as Linux on ARM is very painful currently, let alone more obscure ones like RISC-V.
Appimage is macos flavor, it never needs your sudo to install the package, which is nice.
Flatpak is a redhat flavor(kind of), it needs sudo sometimes, but OK.
Snap is a ubuntu flavor(kind of), it is like systemd that can overtake the whole system, it can install package and even the whole system I was told, too much as a package manager for me.
I don't use Snap. Appimage is not as widely adopted as the rest two? I think Flatpak is a great middle ground.
It will be really cool if KDE and Gnome work together to build this.
This is kind of how immutable systems like fedora's silverblue, and suse's microos are setup.
The base systems are still built with rpm, but for user packages you either use flatpak or stuff in containers via toolbox or distrobox.
It's still possible to layer stuff on to the base image if necessary though.
Sandboxing and distro-agnostic packaging are definitely the way to go. They have some pain points but it's better to fix those than to go back to the older way of doing things.
It totally is! Why does a distro maintainer need to pack every known application into the OS and make sure it works? This kind of work does not scale.
https://ftp.fau.de/fosdem/2023/UA2.114%20(Baudoux)/container...
Erm...
> we also reduce the ability for users to scrutinise the source in the Flathub build system that was used to build their application
I don't think so
https://news.ycombinator.com/item?id=34912760
Wow.
The sandboxing features are documented: https://docs.flatpak.org/en/latest/sandbox-permissions.html
Some convergence of desktop and mobile is plausible over the midterm so it might be worthwhile to think how that could be orchestrated