KDE and GNOME seeks $100k to turn Flathub into a Store for the Linux desktop(github.com)
github.com
KDE and GNOME seeks $100k to turn Flathub into a Store for the Linux desktop
https://github.com/PlaintextGroup/oss-virtual-incubator/blob/main/proposals/flathub-linux-app-store.md
426 comments
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.
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.
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.
> 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.
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 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? 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.
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.
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...
ETA: and maybe one of the workspaces...
Come to think of it I can probably prune one of the windows...
ETA: and maybe one of the workspaces...
I'm almost sure this is an excerpt straight from https://youtu.be/7Nj9ZjwOdFQ
I'm flattered you think I achieve perfect window placement.
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 did that on xubuntu too. Used xdotool, wmctrl and something else I can't recall.
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.
Aren't downgrades heavily discouraged in Arch?
Been running this same setup for eight or nine years now, extremely pleased with it
> But flatpak has it sandboxed so the worst you could do is maybe steal my Spotify session token.
It has access to X11 <https://github.com/flathub/com.spotify.Client/blob/0856c7641...>, so it could also be running a keylogger.
It has access to X11 <https://github.com/flathub/com.spotify.Client/blob/0856c7641...>, so it could also be running a keylogger.
Which is an issue of the X architecture less of flatpack. Wayland is there for a reason
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.
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.
[1]: https://itsfoss.com/downgrade-flatpak-packages/
[1]: https://itsfoss.com/downgrade-flatpak-packages/
> it is actually possible to downgrade a flatpak
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+...
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 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.
> But flatpak has it sandboxed so the worst you could do is maybe steal my Spotify session token
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.
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 flatpak has it sandboxed
With an open sandbox by default for many apps…
With an open sandbox by default for many apps…
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.
> Some flatpaks have $HOME wide-open, but Flatpak itself has no mechanism to completely bypass the sandboxing
The first one is the second one.
The first one is the second one.
We're obviously using extremely different definitions of the word "completely". Flatpak sandboxes more than just file system access.
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.
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.
In that case can you please at least stop advertising flatpak for its security until it happen to be secure eventually…
We shall see. "And then, we add security" has so far never won.
I totally agree about letting applications determine their own defaults being a bad idea.
If every application is properly sandboxed, and the sandbox has zero holes, then it's fine. I don't believe either.
> But flatpak has it sandboxed so
Sandboxing should be a separate tool independent of packaging systems and anything else .
Sandboxing should be a separate tool independent of packaging systems and anything else .
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.
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.
> 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.
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.
i gotta say, if chrome stands out to you as a shining beacon of quality, i'd hate to hear about what software you consider bad
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.
Plenty to criticise about it from a product perspective but from an engineering one it is kind of a marvel.
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.
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.
> On my GFs computer Chrome starts in about 7 minutes after fresh boot, no other programs running, yet.
There is something wrong with your GF’s computer. I have no idea what but a seven minute start time is absolutely atypical.
There is something wrong with your GF’s computer. I have no idea what but a seven minute start time is absolutely atypical.
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.
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.
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.
Maybe it’s extensions.
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.
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.
Chrome wasn't built for 1000 tabs. You need firefox for that.
I think there's a strong argument to be made that modern web browsers are a good deal more complex than operating systems -- or at least most kernels.
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?
Chrome doesn’t have to be a beacon of quality for Firefox to look bad in comparison.
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.
>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.
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.
I do love the sandboxing, granted. But "let's just hope the app maintainers keep up with our rolling platform deprecations" is a horrible idea.
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...
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...
[deleted]
That’s what the whole container revolution was about: “fuck it, we’ll just tar up entire Linux file system images to distribute stuff.”
Multiple copies of openssl is an problem that updates will hopefully solve.
Multiple versions of openssl is a security problem that merely updating cannot solve.
Multiple versions of openssl is a security problem that merely updating cannot solve.
> 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)
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)
I suppose it shouldn't surprise me that the sarcasm of my comment wasn't apparent to everyone.
Poe's law strikes again.
> if you sweep the problems of software management under a big enough rug, they go away and never bother you again.
...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.
...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.
Until openssl has another vulnerability.
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.
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.
> It's a problem of the many-distros model for Linux
No, it is not. If you want security you need dependency management and software lifecycle management on all OSes and platforms.
No, it is not. If you want security you need dependency management and software lifecycle management on all OSes and platforms.
Freedom bad.
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?
- 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?
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.
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.
How are people keeping their AppImages updated?
How are people keeping their AppImages updated?
I, on the other hand, want exactly that. I've never used a desktop file, and I want to control when and if I upgrade.
You can control when, if, and what, as a feature of a good package manager, no need to throw the baby of convenience with it
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.
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.
> How are people keeping their AppImages updated?
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
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
It's been several years since I created an AppImage, but I think these were already available back then:
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.
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.
Plus, it relies on system libraries like glibc. You can’t even use it on distros like Void and Alpine.
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
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
AppImage has no sandboxing. A properly packaged (unfortunately, still a big qualifier) Flatpak is safer to run.
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.
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.
[deleted]
> 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.
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.
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.
they are adding a "verified publisher" feature very soon I think. I saw screenshots of the beta for it.
> Zoom, Slack, Spotify, Steam, Discord, Obsidian
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.
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.
If you are not on a rolling distro, it's a major pain to install latest versions of even open source apps.
> 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?
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?
Red Hat offers a runtime that has a 10 year lifecycle for applications. Beyond that, I don't know of anything quite like that.
https://developers.redhat.com/blog/2020/08/12/introducing-th...
https://developers.redhat.com/blog/2020/08/12/introducing-th...
>Zoom, Slack, Spotify, Steam, Discord, Obsidian
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.
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 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.
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 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 have seen this, if I recall correctly, on an NVIDIA system. I suspect the Flatpak had trouble working with the (proprietary) driver.
I think it was MESA-related, but strangely only some games were having issues.
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.
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.
I feel like you'd end up going full circle back to apt and npm and ...
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)
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.
It will depend how an app has been packaged, but when well done the sandboxing is invisible.
[deleted]
No, most that I tried do not integrate well at all.
integrate with what?
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.
I really like the idea.
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.
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.
If it's just a config file and the package is installed under a user, check .var/lib/flatpak/app
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.
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.
Do you use an IDE, and if so, which?
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.
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.
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.
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.
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.
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.
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.
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.
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.
[deleted]
> As we also open the ability for applications to be uploaded in binary form, which is essential for low-friction compatibility with popular language-specific build systems such as Electron/Node, Rust, Go, etc - we also reduce the ability for users to scrutinise the source in the Flathub build system that was used to build their application.
...and their solution is running an antivirus scanner rather than stepping back and realizing that they're shooting their own feet clean off. And it's based on an absurd premise! Seriously:
> binary form, which is essential for low-friction compatibility with popular language-specific build systems
What? No it's not! Worst case, build in a container with the official tools. Best case, package the build tools like every other distro and enforce source availability and build reproducibility. I mean, NixOS is a bunch of volunteers doing (a better version of) what you're claiming is impossible!
(Granted, I assume the claimed reason is a lie and the real reason is to support proprietary software, which is... maybe reasonable, but pretending otherwise isn't.)
...and their solution is running an antivirus scanner rather than stepping back and realizing that they're shooting their own feet clean off. And it's based on an absurd premise! Seriously:
> binary form, which is essential for low-friction compatibility with popular language-specific build systems
What? No it's not! Worst case, build in a container with the official tools. Best case, package the build tools like every other distro and enforce source availability and build reproducibility. I mean, NixOS is a bunch of volunteers doing (a better version of) what you're claiming is impossible!
(Granted, I assume the claimed reason is a lie and the real reason is to support proprietary software, which is... maybe reasonable, but pretending otherwise isn't.)
Is NixOS a cult? Every time someone posts about Linux packaging, there's a "you should just use NixOS" comment.
Although it provides its own solution to the Linux packaging problem, it's a single solution that comes with a whole load of baggage with it. It is not the panacea its proponents wants us to believe it is.
Although it provides its own solution to the Linux packaging problem, it's a single solution that comes with a whole load of baggage with it. It is not the panacea its proponents wants us to believe it is.
I think in conversation we don't separate the fundamental concepts that Nix implements from the particular implementation.
The fundamental idea is this: Every package is built in a "hermetic" environment that guarantees that the only inputs are the ones you have explicitly specified. Those inputs include tools, source files, compilers, build instructions etc., all specified by a hash. Those inputs themselves can then be packages build in this way, such that everything in your system forms a big Merkle tree.
This approach enables a number of excellent things - you get excellent build reproducibility, you can cache any step you want etc. A lot of the concerns you get with a more conventional system just go away.
People have objections to Nix(OS) - the language, the sporadic documentation, some of the design decisions made, the learning curve etc. But I think those (very reasonable) objections obscure the more interesting debate about the underlying approach and value.
The fundamental idea is this: Every package is built in a "hermetic" environment that guarantees that the only inputs are the ones you have explicitly specified. Those inputs include tools, source files, compilers, build instructions etc., all specified by a hash. Those inputs themselves can then be packages build in this way, such that everything in your system forms a big Merkle tree.
This approach enables a number of excellent things - you get excellent build reproducibility, you can cache any step you want etc. A lot of the concerns you get with a more conventional system just go away.
People have objections to Nix(OS) - the language, the sporadic documentation, some of the design decisions made, the learning curve etc. But I think those (very reasonable) objections obscure the more interesting debate about the underlying approach and value.
Indeed; GNU Guix is essentially the same thing, but with a different language and CLI (the two main source of complaints about Nix).
Similar to how Git has a notorious CLI; but that doesn't invalidate the idea of DVCS (with alternative implementations in Mercurial, Bazaar, Darcs, etc.)
Similar to how Git has a notorious CLI; but that doesn't invalidate the idea of DVCS (with alternative implementations in Mercurial, Bazaar, Darcs, etc.)
I use nix as my package manager, but I would use Guix instead if it would support macs. Nix is a great idea but it has a huge amount of ground to cover in reducing onboarding friction.
The lack of mac support is tragic. It means I can't use guix at work, where I might benefit from it the most.
The problems with NixOS are not the only ones you highlighted. The baggage it brings in the name of reproducibility is not justified in my eyes.
Because a) They're not the only ones working towards it, but they like to paint it that way and b) Their implementation is not the only correct way, and again they like to paint it that way.
The main people behind it may not feel like that, but the hype creates a very repulsive aura around the project for some of us. I just don't want to touch NixOS just because of the community and hype around it.
There are many ways to achieve this reproducibility, and the old school ways are not very behind when compared to NixOS. Some things are achieved differently, but it's perfectly achievable with Debian and RedHat packaging infrastructures.
Because a) They're not the only ones working towards it, but they like to paint it that way and b) Their implementation is not the only correct way, and again they like to paint it that way.
The main people behind it may not feel like that, but the hype creates a very repulsive aura around the project for some of us. I just don't want to touch NixOS just because of the community and hype around it.
There are many ways to achieve this reproducibility, and the old school ways are not very behind when compared to NixOS. Some things are achieved differently, but it's perfectly achievable with Debian and RedHat packaging infrastructures.
I don't use NixOS, but from what I've read, you should just use NixOS.
All kidding aside, I installed NixOS (it installs like any other distro, it's just that after that you are completely lost), but it's a real paradigm shift.
I'm just hoping for Ubuntu Declarative Donkey at this point and hope someone addresses the learning curve and the specialist language and tools used. I'd hate to invest all this time and then all other distros finally respond and it was not really worth it after all. I mean it looks to me like one can just put a Yaml file at the heart of Ubuntu and make that work. At least as step 1. Why is there no response from the classic Linux vendors? There are atomic distro's yes (ie Fedora Silverblue), but no real NixOS-like product. I want my personal system to live in Git.
Maybe I should just use NixOS.
All kidding aside, I installed NixOS (it installs like any other distro, it's just that after that you are completely lost), but it's a real paradigm shift.
I'm just hoping for Ubuntu Declarative Donkey at this point and hope someone addresses the learning curve and the specialist language and tools used. I'd hate to invest all this time and then all other distros finally respond and it was not really worth it after all. I mean it looks to me like one can just put a Yaml file at the heart of Ubuntu and make that work. At least as step 1. Why is there no response from the classic Linux vendors? There are atomic distro's yes (ie Fedora Silverblue), but no real NixOS-like product. I want my personal system to live in Git.
Maybe I should just use NixOS.
I don't use NixOS, or have any great interest in it tbh. But this podcast featuring Martin Wimpress (of Linux Mate and other projects) does a decent job of describing what NixOS is, and previews some ongoing and upcoming efforts to address the learning curve and lingo around it.
https://linuxdowntime.com/category/podcast/
https://linuxdowntime.com/category/podcast/
Great suggestion, I find Martin Wimpress to always be very clear and insightful. I myself listen to most Jupiter Broadcasting podcasts [0]. On their "Linux Unplugged" show [1] they did a NixOS challenge recently. There is an accompanying Matrix channel for noobs which can also be a great resource! See an overview of resources here: [2]. It's a fun community.
[0] https://www.jupiterbroadcasting.com/
[1] https://www.jupiterbroadcasting.com/show/linux-unplugged/
[2] https://github.com/JupiterBroadcasting/nixos-challenge
[0] https://www.jupiterbroadcasting.com/
[1] https://www.jupiterbroadcasting.com/show/linux-unplugged/
[2] https://github.com/JupiterBroadcasting/nixos-challenge
[deleted]
Every distro has its cult(s).
I think NixOS tends to be mentioned more often than others because it provides a lot of clean solutions to common problems. Especially when some people claim these common problems are unsolvable, but NixOS does offer some sort of solution (that of course comes with it's own set of tradeoffs, every solution does).
If someone says "It's impossible to run a popular website with client-side analytics" and you frequently hang out on popular websites without client-side analytics, wouldn't you share those examples to show that the person might not know about those and could further their understanding?
I think NixOS tends to be mentioned more often than others because it provides a lot of clean solutions to common problems. Especially when some people claim these common problems are unsolvable, but NixOS does offer some sort of solution (that of course comes with it's own set of tradeoffs, every solution does).
If someone says "It's impossible to run a popular website with client-side analytics" and you frequently hang out on popular websites without client-side analytics, wouldn't you share those examples to show that the person might not know about those and could further their understanding?
It’s more like people trying to fly but the best they can do is glide off some hills. And then someone with a helicopter flies by them.
Package managers before nix simply didn’t solve the problem properly - they left behind garbage, couldn’t properly deal with multiple versions of the same package, etc. Easy way to check whether the package manager you have in mind is “sufficient” is to install the gnome group and the plasma group and remove them. How many orphan packages will you have as a result?
It is not a cult, people just like proper solutions to problems, and nix is unique in this regard.
Package managers before nix simply didn’t solve the problem properly - they left behind garbage, couldn’t properly deal with multiple versions of the same package, etc. Easy way to check whether the package manager you have in mind is “sufficient” is to install the gnome group and the plasma group and remove them. How many orphan packages will you have as a result?
It is not a cult, people just like proper solutions to problems, and nix is unique in this regard.
Sure there is no silver bullet. However, I don't know about anything which would since this flathub problem as well as Nix:
* Works on all (most) distros * Builds the packages from sources, binaries are only a cache to speed things up. * Bonus: already has a lot of software packaged
And proprietary works in the system too, the build step can just download the binary from internet. It's not a preferred way to do it, but you don't have to build a broken system just because of few packages without source access
* Works on all (most) distros * Builds the packages from sources, binaries are only a cache to speed things up. * Bonus: already has a lot of software packaged
And proprietary works in the system too, the build step can just download the binary from internet. It's not a preferred way to do it, but you don't have to build a broken system just because of few packages without source access
I mean you can't wander into a discussion about packaging without coming across a solution that does it well. Disclaimer, I do use NixOS as a daily driver now and it's not a panacea but after years on other distributions, it really is a breath of fresh air, so I'm not suprised it has many advocates.
No, there's way too much and too deep open disagreement among Nixers for NixOS to be a cult. :)
More seriously, people who run NixOS are, generally and historically, people who have a lot of experience with package management and people who choose their Linux distro based on the tooling rather than based on defaults.
The Nix approach is conservative in some wonderful ways that are likely to appeal to longtime Linux users who appreciate the strengths of old-school system package managers as well as the defect of those systems, which makes Nix people want to cry out in response to container-based package management:
> You don't have to go that far! You can have all these benefits but keep fine-grained library sharing! The choice between static and dynamic linking is a false dichotomy!
because if you love what's great about traditional package management, that's really exciting.
More seriously, people who run NixOS are, generally and historically, people who have a lot of experience with package management and people who choose their Linux distro based on the tooling rather than based on defaults.
The Nix approach is conservative in some wonderful ways that are likely to appeal to longtime Linux users who appreciate the strengths of old-school system package managers as well as the defect of those systems, which makes Nix people want to cry out in response to container-based package management:
> You don't have to go that far! You can have all these benefits but keep fine-grained library sharing! The choice between static and dynamic linking is a false dichotomy!
because if you love what's great about traditional package management, that's really exciting.
> Is NixOS a cult?
Rather than being a cult in itself, there's a crowd of very vocal fanboys similar to the RIIR stike force. Pestering people with "why don't you use $thing" is not good advocacy.
Rather than being a cult in itself, there's a crowd of very vocal fanboys similar to the RIIR stike force. Pestering people with "why don't you use $thing" is not good advocacy.
Point of order: I didn't say "you should use nix", I said "oi, nix is actively doing that thing you said was impossible", and suggested that they should do that themselves.
I didn't say "you are acting like a fanboy", I said "some vocal minorities are fanboying" and suggested that they should not do it.
Indeed the communication factor is critical. I've been around long enough to see plenty of good tech fail simply because backers are not very good communicators and I think the top level comment is a great example of this. I am just a lowly end user, I just want to be able to install and run the latest version of PrusaSlicer or Zoom on whatever Linux distribution I am using. I don't obviously see how to do that with nix and I don't really want to spend the time to figure it out, while the folks behind flatpak seem to have made it a trivial experience.
> I don't obviously see how to do [install the latest version of Zoom] with nix and I don't really want to spend the time to figure it out
(For proprietary software like Zoom, I think Flatpak might be preferable even to many Nix users like me.)
nix-env -iA nixpkgs.zoom-us
nix profile install nixpkgs#zoom-us
(For proprietary software like Zoom, I think Flatpak might be preferable even to many Nix users like me.)
I have a quote I like throwing around about nix/nixos
"the nix ecosystem is like a cult. Not because it tries to be, but because the ideas are so good you cannot deny them."
"the nix ecosystem is like a cult. Not because it tries to be, but because the ideas are so good you cannot deny them."
This is something charismatic youth pastor would say in a weird denomination that encourages getting tattoos.
You say that like its a bad thing?
Now do you want "nix rocks'" in black, red or blue ink?
/s
/s
It really pretty much is the panacea people say it is, which is why watching everything else go by is so frustrating
Your comment is unrelated too the parents comment.
> Is NixOS a cult?
I think it kinda is, but in a good way.
It's the church of reproducible builds, which is a good cause.
I think it kinda is, but in a good way.
It's the church of reproducible builds, which is a good cause.
There is reportedly a chapter of the Chaos Computer Club which has been jokingly nicknamed 'the church of NixOS'. ;)
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.
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.
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.
[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/
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/
I see what you mean. I suppose these particular existing standards come from inner-views on technicals.
As opposed to, say, standards that are based on general user experience aspects. Does the control panel offer printer settings yet, for example.
As opposed to, say, standards that are based on general user experience aspects. Does the control panel offer printer settings yet, for example.
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.
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.
> 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.
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.
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.
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.
and now pipewire...
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 mean, that's what they always say right? OSS replaced Alsa replaced arts replaced pulseaudio replaced pipewire or did I get that backwards?
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.
> 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"?
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"?
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.
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.
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.
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.
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.
Because I might want to developer a new DE/toolkit/whatever and having one checklist I can refer to would really help.
I think that's what Freedesktop does, and why Flatpak heavily relies on XDG variables.
Where is this chart for levels in Freedesktop? I'm only vaguely familiar with the project.
[deleted]
I think its some kind of standards body for the Linux desktop.
>...working together on one definitive GNU/Linux DE
No thanks. GNOME dev hubris is the reason I use KDE
No thanks. GNOME dev hubris is the reason I use KDE
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.
</vent>
0. https://extensions.gnome.org/extension/2/move-clock/
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/
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.
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.
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]).
1.: https://github.com/thestinger/termite
1.: https://github.com/thestinger/termite
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.
That's just abhorrent behavior.
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.
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.
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.
>convergence, which is incredibly popular among users
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.
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.
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.
Gnome used to have a polished interface for editing the positioning of top bar widgets circa 2001.
thaumasiotes(1)
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.
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.
> 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.
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.
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.
At least in GNOME, I can turn off the laptop screen without closing the lid
...you can't compare minimalism/configurability in this way
...you can't compare minimalism/configurability in this way
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 :/
Maybe there's no RSI in Palo Alto?
https://github.com/koekeishiya/yabai
https://github.com/koekeishiya/skhd
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
> 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.
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.
> actually works
Yeah. Without proper window management, middle click and other things I need 3rd party apps for.
Yeah. Without proper window management, middle click and other things I need 3rd party apps for.
afaik applications menus still do exist and are available out of the box.
> LXDE/LXQT/Mate/Enlightenment/Cinammon
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.
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.
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.
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.
What were your issues? What was the distro?
What were your issues? What was the distro?
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.
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!
Either way I think that still sounds better than the old 3->4 migration, and hopefully 5->6 can be better still!
Plasma 5 was so broken for me, I've been on Budgie while waiting for KDE to return to its glory days.
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.
...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.
I indeed waited several months before adopting Plasma 5
To me recently, Cinnamon feels like they took GNOME technologies and built the default Plasma desktop in them.
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.
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.
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.
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'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?
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?
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.
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.
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.
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.
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.
I dual boot with Windows 11 and Debian on a couple of systems and don't even notice secure boot.
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.
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.
I started using Ubuntu for the opposite reason: getting compiz working on Debian was a nightmare, but on Ubuntu, desktop effects just worked.
This was well over a decade ago though :)
This was well over a decade ago though :)
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.
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.
That’s interesting, do you have unusual hardware?
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.
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.
> do you have unusual hardware?
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!"?)
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!"?)
Spot on. In robotics it's pretty much the only standard framework there is and guess which one is the only distro with Tier 1 support? Yep.
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.
you would indeed be better off with pop or mint. ubuntu is gonna move more and more towards snaps.
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
Ubuntu packages get updated on a much faster cadence then Debian in my experience.
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.
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.
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?
https://news.ycombinator.com/item?id=31643316
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
> Does Debian not have a vibrant PPA community to fill the gaps like Ubuntu?
Yeah, it does: the Ubuntu PPA community. (See https://wiki.debian.org/CreatePackageFromPPA, and similar.)
Yeah, it does: the Ubuntu PPA community. (See https://wiki.debian.org/CreatePackageFromPPA, and similar.)
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.
Debian Sid makes a pretty good "rolling release" distro for home/hobby use at least, although I prefer OpenSUSE Tumbleweed for this.
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.
Sid is unstable (by definition and design)b wouldn't recommend as a daily driver. Testing is a decent rolling release distro, though.
Testing isn't rolling release. Every 2 years, testing becomes stable, and stable becomes oldstable.
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.
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.
Sure, if you find Gnome to your tastes. I can (just barely) live with systemd, but I am very allergic to Gnome.
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.
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.
If you are using Ubuntu Pro(free or not) Debian isn't really an alternative.
Also I am not sure if Debian is as fast as Canonical in patching CVEs.
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.
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.
Would you please like to explain why it is better? Thanks!
Free kernel livepatching, the whole Ubuntu universe is supported(more than 20 thousand packages), 10 years of support, compliance help.
Its also much easier to install on cloud servers than RHEL.
Its also much easier to install on cloud servers than RHEL.
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).
"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).
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.
(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.
Yeah definitely, I think that the availability of information for Ubuntu makes it very attractive.
I meant more so for people who are somewhat active on these discussions but still go with Ubuntu.
I meant more so for people who are somewhat active on these discussions but still go with Ubuntu.
I’m a Fedora user and I consult ArchWiki all the time.
no, this is not true. Debian requires manual configuration for some major parts to this day.
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.
> 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.
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 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).
well, systemd “services” are just bunch of scripts and init files.
How exactly does systemd turn Linux into Windows? Does it...
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?
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?
This has been re-hashed many times.
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.
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.
Edit: I said “attempt”. Linux doesn’t have those extreme stupidities you mentioned, and probably never will.
How exactly many? Can you name them?
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.
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.
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.
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)
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)
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.
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)
People used Ubuntu for years before they came out with snap. Why use something faddish and potentially unstable.
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.
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.
ZorinOS is Ubuntu but better.
I also have an Ubuntu desktop which I've ripped snap out of.
In my case, it's because my options are pretty much Ubuntu or Windows for this machine, and there's no contest there.
In my case, it's because my options are pretty much Ubuntu or Windows for this machine, and there's no contest there.
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.
like mastazi, I also remove snapd immediately. I get all the benefits of ubuntu and lose absolutely nothing by removing snapd
zfs is a single `apt install` away.
I thought Ubuntu lost interest in that and is letting it die?
https://www.omgubuntu.co.uk/2023/01/ubuntu-zfs-support-statu...
https://www.omgubuntu.co.uk/2023/01/ubuntu-zfs-support-statu...
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.
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.
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 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 harassed them nearly 6 years ago about this. https://forum.snapcraft.io/t/external-repositories/1760
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
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.
I remove snap then do the following to make sure it doesn't come back:
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.
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.
The "absolutely not, never run a machine I manage" thing of uncontrollable updates is only a problem with snap.
I'm very in favour of improving the state of application distribution on Linux. Targeting an abstraction like Flatpack seems like a no-brainer if there are no regressions in experience to the end user.
I am not sure if this is the case, but in theory I love the idea that the app sandboxing can allow the Flatpak engine to be a source that can prompt users for permissions access (e.g. "app would like to access your location").
Last time I tried Flatpack I experienced a lot of integration issues, from GTK theming issues to applications missing features due to sandboxing.
Would love to see a high level medium-dive explainer on how Flatpack works to alleviate some of my concerns; predominantly around the limitations of sandboxing.
e.g.
Can OBS have unimpeded screen recording access? How does OBS compare in Flatpak compared to natively installed.
Can VSCode access any part of the FS without any performance overhead, what about language servers and that sort of thing?
Can applications like Discord that feature a voice-activated mic work? Can Discord access what game you're currently playing on Steam and set that as its status?
Originally, I thought Flatpack was much like old win32 applications where if you put a dll dependency next to the executable, it will use that rather than the system one. I got really scared of Linux app sandboxing engines when I tried Snapd and it started making virtual network devices and my system theme wasn't applied to the application - seemed very convoluted.
I am not sure if this is the case, but in theory I love the idea that the app sandboxing can allow the Flatpak engine to be a source that can prompt users for permissions access (e.g. "app would like to access your location").
Last time I tried Flatpack I experienced a lot of integration issues, from GTK theming issues to applications missing features due to sandboxing.
Would love to see a high level medium-dive explainer on how Flatpack works to alleviate some of my concerns; predominantly around the limitations of sandboxing.
e.g.
Can OBS have unimpeded screen recording access? How does OBS compare in Flatpak compared to natively installed.
Can VSCode access any part of the FS without any performance overhead, what about language servers and that sort of thing?
Can applications like Discord that feature a voice-activated mic work? Can Discord access what game you're currently playing on Steam and set that as its status?
Originally, I thought Flatpack was much like old win32 applications where if you put a dll dependency next to the executable, it will use that rather than the system one. I got really scared of Linux app sandboxing engines when I tried Snapd and it started making virtual network devices and my system theme wasn't applied to the application - seemed very convoluted.
Flatpak used to have a lot of issues with sandboxing, but in recent years the situation has gotten better because of two things:
1. A strong push to help package maintainers fix sandboxing mistakes, expose the APIs that need to be exposed and lock down the APIs that are not needed. It used to be pretty bad but it's pretty rare to see sandboxing problems nowadays.
2. You can now use a tool called Flatseal, or in KDE a new builtin settings interface in Plasma 5.27, to modify sandboxing settings for applications in an intuitive way. If you're trying to use an IDE and just want to expose every permission to it, you can easily do that now.
3. Unrelated to Flatpak, Wayland is now getting a lot of the video capture and screen recording APIs that are needed.
1. A strong push to help package maintainers fix sandboxing mistakes, expose the APIs that need to be exposed and lock down the APIs that are not needed. It used to be pretty bad but it's pretty rare to see sandboxing problems nowadays.
2. You can now use a tool called Flatseal, or in KDE a new builtin settings interface in Plasma 5.27, to modify sandboxing settings for applications in an intuitive way. If you're trying to use an IDE and just want to expose every permission to it, you can easily do that now.
3. Unrelated to Flatpak, Wayland is now getting a lot of the video capture and screen recording APIs that are needed.
> Can OBS have unimpeded screen recording access? How does OBS compare in Flatpak compared to natively installed.
I'm livestreaming on a regular basis, and moved from OBS as compiled by Arch Linux to OBS Flatpak. Everything just works (esp. the browser source that uses an embedded Chromium, which I never got to work with the Arch packages). Most likely that particular Flatpak is very liberal in its sandboxing, because it was even able to write into $HOME/obs-recordings/ without any permission prompt. I don't care about the sandboxing part of Flatpak too much in this particular case, so I didn't dig further.
I'm livestreaming on a regular basis, and moved from OBS as compiled by Arch Linux to OBS Flatpak. Everything just works (esp. the browser source that uses an embedded Chromium, which I never got to work with the Arch packages). Most likely that particular Flatpak is very liberal in its sandboxing, because it was even able to write into $HOME/obs-recordings/ without any permission prompt. I don't care about the sandboxing part of Flatpak too much in this particular case, so I didn't dig further.
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.
I do hope the command-line UX around flatpaks (installing, updating, etc) improves a lot though as currently it leaves much to be desired.
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.
https://fosdem.org/2023/schedule/event/containerised_apps/
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/
AppImage still just works, just like tarball bundles without dependency on 3rd party infrastructure and overengineered solutions like snap and flatpak.
The talk I linked suggest this isn't the case.
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.
> ometimes have to write the .desktop yourself if you want it launchable through the UI
I even don't have to manually write them, KDE has kmenuedit.
I even don't have to manually write them, KDE has kmenuedit.
> This leads to Linux desktop having far fewer applications available to them compared to windows and mac.)
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.
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.
I mean, it's probably both.
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.
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.
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.
Boy, do I have something to show you: https://silverblue.fedoraproject.org/about
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.
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.
>relevant xkcd comic on standards inserted here
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.
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.
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
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
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.
> 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.
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.
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.
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).
>b) just don't release a Linux version.
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).
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).
I feel like one thing that is still holding Linux Desktop and any initiative like this back is that we don't have really high quality linux laptops on the market.
We have some people like System76 doing great things, but not in Europe and for all their great work its not the highest quality stuff from China with some serious limitations.
For all the things the European Union funds, from chip manufacture, HPC and many other project from large to medium to small. Why have we not seen a made in Europe Laptop/Desktop/Phone for the bureaucrats and engineers who do things like running states and building weapons and so on.
A fair amount of EU money goes into a lot of these distributed system and internet projects. And I'm not complaining, but we are spending a lot of time trying to make our system secure from everything other then direct attack. The fireware in the new notebook doesn't seem better then in the one before, in fact worse in some way.
We have most of the software, we have most of the things needed to do these things. An Open-Source computer for Europe (and anybody) would be a real counter-point to most of the other models out there.
In such an environment a real AppStore for Open Linux desktop could actually be a really good thing.
We have some people like System76 doing great things, but not in Europe and for all their great work its not the highest quality stuff from China with some serious limitations.
For all the things the European Union funds, from chip manufacture, HPC and many other project from large to medium to small. Why have we not seen a made in Europe Laptop/Desktop/Phone for the bureaucrats and engineers who do things like running states and building weapons and so on.
A fair amount of EU money goes into a lot of these distributed system and internet projects. And I'm not complaining, but we are spending a lot of time trying to make our system secure from everything other then direct attack. The fireware in the new notebook doesn't seem better then in the one before, in fact worse in some way.
We have most of the software, we have most of the things needed to do these things. An Open-Source computer for Europe (and anybody) would be a real counter-point to most of the other models out there.
In such an environment a real AppStore for Open Linux desktop could actually be a really good thing.
https://www.tuxedocomputers.com/
https://www.notebooksbilliger.de/
https://www.lenovo.com/pt/pt/d/portateis-linux
https://linuxsi.com/
https://www.skroutz.gr/c/25/laptop/f/526320/Linux.html
The problem isn't the hardware per se, rather lack of focus on a single desktop experience like the competition.
For non-technical users and app developers.
https://www.notebooksbilliger.de/
https://www.lenovo.com/pt/pt/d/portateis-linux
https://linuxsi.com/
https://www.skroutz.gr/c/25/laptop/f/526320/Linux.html
The problem isn't the hardware per se, rather lack of focus on a single desktop experience like the competition.
For non-technical users and app developers.
What is the base data for your analysis? Is this data available?
And how did you come to the conclusion that "missing high quality linux desktops" are the thing "holding back" Linux?
Is this based on some statistical work you did?
If we talk about feelings - did you ever have the feeling that corruption, lobbying and blackmailing could play a role?
BTW - why do you think Linux is missing high quality desktops? I am working with very high quality Linux desktops since many years and I wonder why people are using such low quality desktop OS that are sold commercially.
And how did you come to the conclusion that "missing high quality linux desktops" are the thing "holding back" Linux?
Is this based on some statistical work you did?
If we talk about feelings - did you ever have the feeling that corruption, lobbying and blackmailing could play a role?
BTW - why do you think Linux is missing high quality desktops? I am working with very high quality Linux desktops since many years and I wonder why people are using such low quality desktop OS that are sold commercially.
I'm not seeking funding, I'm not writing a scientific paper. This is a public forum and I stated an opinion.
> If we talk about feelings - did you ever have the feeling that corruption, lobbying and blackmailing could play a role?
If you want to make the argument make it, I will listen.
I working with Linux desktop for decades and like it. My point is that the hardware is the bigger issue.
> If we talk about feelings - did you ever have the feeling that corruption, lobbying and blackmailing could play a role?
If you want to make the argument make it, I will listen.
I working with Linux desktop for decades and like it. My point is that the hardware is the bigger issue.
Many things are holding Linux on the Desktop,
but its more so that the competition is doing better and the Desktop market shifted
First, Windows caught up, Linux used to have things that windows didnt in the late 90s and early 2000s, not most linux only app have windows ports, you can run any linux app on windows WSL , and now windows also have powershell
Second, apple made a comeback, now many people who dont want windows use apple and get a unix experience if they wanted one
Third, end users shifted to tablets and mobile phone
The combination of all 3, leave little room for linux, no matter how good linux does , linux on the desktop only make sense for people who develop for linux on the server and want a similar environment on their laptop
First, Windows caught up, Linux used to have things that windows didnt in the late 90s and early 2000s, not most linux only app have windows ports, you can run any linux app on windows WSL , and now windows also have powershell
Second, apple made a comeback, now many people who dont want windows use apple and get a unix experience if they wanted one
Third, end users shifted to tablets and mobile phone
The combination of all 3, leave little room for linux, no matter how good linux does , linux on the desktop only make sense for people who develop for linux on the server and want a similar environment on their laptop
Or for disgruntled slaveware users, who got pushed over the edge by the software companies ("Windows really trying to force you to use a micro$oft account these days", or "Apple rolling out their spyware to scan for photos on your phone and reporting to them despite saying not to"[1]).
1. https://sneak.berlin/20230115/macos-scans-your-local-files-n...
1. https://sneak.berlin/20230115/macos-scans-your-local-files-n...
Ackchyually, apple only wanted to scan photos on your iphone so they can keep them encrypted in the cloud. They want to be compliant with laws, your government (people you never elected and never even seen on TV) constantly evolving to control you.
In 5 years Linux distros will have same scan features because it will be new law that outlaw to own a PC without connected surveillance. It just another regulation. Your car already have eCall spyware mic/gps tracker, so you won’t really care. You just be disgruntled about new AI robocalls inside Windows or new build of “voice control first” GNOME desktop on Ubuntu.
You forgot about people who care about their data and about privacy and those who hate ads.
$100,000 to build up a system that totally ignores the system package manager? Sounds great!
Good. The “system package manager” is good for updating the OS, it’s not good for packaging desktop applications, especially proprietary ones.
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.
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.
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.
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. 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.
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.
I don't even know what I get out of the system package manager these days. Apps are mostly flatpak / appimages, dev tools I'm using Homebrew.
I guess it's mostly the kernel and my DE these days.
I guess it's mostly the kernel and my DE these days.
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
That very incoherence is probably why it rarely works.
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.
> the problem is not unsolvable
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.
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.
A Flatpak proponent would tell you that's the whole point. But that’s not where the cost lies, but staffing and running a store.
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.
Yes, please. The system package manager is not an appropriate tool for installing applications.
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.
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).
https://ftp.fau.de/fosdem/2023/UA2.114%20(Baudoux)/container...
https://ftp.fau.de/fosdem/2023/UA2.114%20(Baudoux)/container...
> security
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
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
Flatpak offers convenience but it could never offer the security that the distros it is circumventing offer. Application bundling is just inherently insecure.
He's still wrong.
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.
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.
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.
> it's indeed time to let the system package management(apt,rpm,etc) just manage a solid BASE system
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.
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.
It's been time for that for a while now.
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.
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.
Like *BSD, with base + ports.
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?
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 is great, definitely the best of the bunch.
Said no one relevant
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..
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.
> Said no one relevant
[Retort insult.]
[Retort insult.]
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.
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.
> we also reduce the ability for users to scrutinise the source in the Flathub build system that was used to build their application
Wow.
Wow.
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?
https://news.ycombinator.com/item?id=34912760
https://news.ycombinator.com/item?id=34912760
Not very well. Canonical learned nothing from Unity's failure.
This fills me with dread. I don't think the app stores we've seen have been good things for a number of reasons.
I hope, if this succeeds, it turns out to be a good thing.
I hope, if this succeeds, it turns out to be a good thing.
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.
Yes, I understand that. That is orthogonal to my opinion of app stores, though.
Are the margins on this website too small to note down your objections? :)
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.
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.
Meanwhile Ubuntu is making sure that none of its flavours has flatpak installed by default.
Smells like that old MS attitude to me.
Smells like that old MS attitude to me.
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.
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.
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.
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.
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.
[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
[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
Ah, refreshingly cynical. RedHat and Canonical would rather protect their smol kingdoms than expand the greater Linux ecosystem.
Flatpak is a solution to package management as Docker is to servers. What's the predominant reason people use Docker? Because it's impossible to get a Python/NodeJS monstrosity working properly without it. On rolling release distributions, you don't ever need Flatpak. Its predominance is found in stable release distributions like Ubuntu and Fedora. Because they stall packages and their dependencies, it'll always be an issue to install new software. If anything, I prefer AppImage a lot more.
> On rolling release distributions, you don't ever need Flatpak.
What if I need older version of some software? Or what if I need multiple versions of the same software at once?
What if I need older version of some software? Or what if I need multiple versions of the same software at once?
I'd say that Nix has solved this problem way better than Flatpak.
Call me when I don't have to learn a new language to use it effectively.
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.
other than that flatpak is amazing.
- 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 think flatpaks are awesome. Especially for commercial software. I do think they are missing an important feature that snap has what snap referes to as classic confinement. For example vscode as a flatpak can't really interact with your normal system libraries/exectuables/etc. That being said I do hope that Flatpaks succeed and becomes the easy go-to option for commercial software to support linux distributions.
>As we also open the ability for applications to be uploaded in binary form, which is essential for low-friction compatibility with popular language-specific build systems such as Electron/Node, Rust, Go, etc - we also reduce the ability for users to scrutinise the source in the Flathub build system that was used to build their application.
This is unacceptable. Open-source apps should always be built from source on a trusted infrastructure and ideally the builds should be reproducible. Otherwise, one of the main benefits of open-source software -- ability to verify its security -- is completely lost.
Fortunately, Flatpak != Flathub. There is also Fedora's flatpak repository and that's what I'm using. It doesn't have as many apps as Flathub, but their number is growing.
I prefer flatpaks to RPMs because of the sandboxing feature. While it's not perfect yet, I like that I can forbid most of my apps to access the network and to limit access to the filesystem and other system parts for apps that require network as much as possible. As a result, the trusted base of my system can be reduced significantly (and the base system can then use other method to confine its processes which on Fedora is SELinux).
Another benefit of Flatpak over traditional packaging systems is that it's a cross-distro package manager and the apps can be installed on any Linux distribution. Even if we end up with multiple Flatpak repositories like Flathub and Fedora Flatpaks with different approaches and philosophies, users of any Linux-based OS can then install apps from any repository they like, and OS developers can focus on the base system.
So in general I like Flatpak and I think it's a step in the right direction, but I can't say the same about Flathub. For me it's unacceptable to install anything from Flathub unless they fix their supply chain security flaws.
This is unacceptable. Open-source apps should always be built from source on a trusted infrastructure and ideally the builds should be reproducible. Otherwise, one of the main benefits of open-source software -- ability to verify its security -- is completely lost.
Fortunately, Flatpak != Flathub. There is also Fedora's flatpak repository and that's what I'm using. It doesn't have as many apps as Flathub, but their number is growing.
I prefer flatpaks to RPMs because of the sandboxing feature. While it's not perfect yet, I like that I can forbid most of my apps to access the network and to limit access to the filesystem and other system parts for apps that require network as much as possible. As a result, the trusted base of my system can be reduced significantly (and the base system can then use other method to confine its processes which on Fedora is SELinux).
Another benefit of Flatpak over traditional packaging systems is that it's a cross-distro package manager and the apps can be installed on any Linux distribution. Even if we end up with multiple Flatpak repositories like Flathub and Fedora Flatpaks with different approaches and philosophies, users of any Linux-based OS can then install apps from any repository they like, and OS developers can focus on the base system.
So in general I like Flatpak and I think it's a step in the right direction, but I can't say the same about Flathub. For me it's unacceptable to install anything from Flathub unless they fix their supply chain security flaws.
I would prefer AppImage or nix than Flatpak. It just seems to be yet another package manager but more difficult to use and much slower.
Linux Mint > Software Manager > Search for "Flatpak" > it's at the bottom of the list of results > Remove
$100K? that's all. Do a kickstarter or a GoFund me and I will contribute too, and I am not a Linux user (yet).
> Outside of the Linux desktop space, actors such as F-Droid provide a home for free and open source Android applications on mobile devices.
Some convergence of desktop and mobile is plausible over the midterm so it might be worthwhile to think how that could be orchestrated
Some convergence of desktop and mobile is plausible over the midterm so it might be worthwhile to think how that could be orchestrated
Flatpak and snap have proven to be ineffective and security theatre. Sandboxing all user apps doesn't work, often the applications are created to not be sandboxed, and the existing sandbox configs are improper.
We don't need yet another store. What we need is a simple registry of applications that are installed with the scripts to uninstall. We already have this, it's a package manager.
For soft that doesn't need a package manager, we have .appimage.
Instead of making it more difficult to package apps for Linux, focus on having few methods that are robustly supported.
We don't need yet another store. What we need is a simple registry of applications that are installed with the scripts to uninstall. We already have this, it's a package manager.
For soft that doesn't need a package manager, we have .appimage.
Instead of making it more difficult to package apps for Linux, focus on having few methods that are robustly supported.
On a Linux system, how to secure a system so that users are not able to run binaries they downloaded from the internet?
How can application whitelisting be achieved?
Does Flathub come with any features that help with that?
How can application whitelisting be achieved?
Does Flathub come with any features that help with that?
Flatpaks are awesome.
If you need to tweak them, Flatseal is a great tool.
https://github.com/tchx84/Flatseal
If you need to tweak them, Flatseal is a great tool.
https://github.com/tchx84/Flatseal
Flatpak has issues (size), but I think I can accept them as a part of the design and believe the other issues (crashes, security) will be solved as adoption grows.
Personally, I still prefer my repos with shared libraries when possible. I'm also able to keep a mirror of the packages to cut down on bandwidth.
I haven't figured out how to mirror the flatpaks yet, mostly due to lack of effort.
I'm excited, it will be good to have a cross-distro app store.
Personally, I still prefer my repos with shared libraries when possible. I'm also able to keep a mirror of the packages to cut down on bandwidth.
I haven't figured out how to mirror the flatpaks yet, mostly due to lack of effort.
I'm excited, it will be good to have a cross-distro app store.
I've asked them about donations but they said it was not possible, a year or so again.
I'd gladly donate or even keep a subscription to keep Flathub running.
I'd gladly donate or even keep a subscription to keep Flathub running.
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?
Which attacks exactly?
The sandboxing features are documented: https://docs.flatpak.org/en/latest/sandbox-permissions.html
The sandboxing features are documented: https://docs.flatpak.org/en/latest/sandbox-permissions.html
Well, the only part of flatpak I honestly like is bubblewrap, the only reason flatpak even makes any sense to me
I don’t think open source needs a walled garden, but I think people want the walls.
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).
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.
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.
Why do we need this bullshit when we have apt, rpm, pacman and everything?
I wish gnu/linux devs would pool their efforts occasionally. We have competing flatpak and snap efforts, with neither being all that good currently. Can we agree on a standard?
Flatpak is the standard, the only distro/company that don't accept it is canonical/ubuntu, every other company and distro ships flatpak as standard(btw snap only work in ubuntu)
I run Linux to avoid shopkeepers (or others in general). I run macOS when I need that help. I run Windows the rest of the time, which is currently not that often.
I wonder when the distros are going to start auto-converting their native package formats to Flatpak so you can use distro Flatpaks alongside Flathub ones.
Maybe Valve could fund them?
Anyone have the connections to make this happen?
Anyone have the connections to make this happen?
I believe Valve already makes contributions to Flatpak and its backend container stack, bubble wrap.
Valve actually uses bubble wrap on the Steam deck for proton.
Valve actually uses bubble wrap on the Steam deck for proton.
> Our previous phase of implementing the Flathub appstore functionality was funded by a 50,000 USD grant from Dalio Philanthropies
as in Ray Dalio?
as in Ray Dalio?
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.
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.
[deleted]
If they can actually prevent piracy, maybe I'll actually package my app for Linux.
> If they can actually prevent piracy, maybe I'll actually package my app for Linux.
... Neither MacOS nor Windows do this; what are you targeting now?
... Neither MacOS nor Windows do this; what are you targeting now?
I mistyped. I should have said "provide a bare-minimum barrier to piracy".
[deleted]
while I like and use flatpaks, each time I try to use gnome software, I need to kill it and restart just too that it loads
Uh no, I wouldn't even hand over a penny to the GNOME project.
Why the hell do you need store when you have pacman/AUR
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.
FreeBSD is actually excellent at this with a traditional package system. Stable OS but rolling packages. That's why I use it.
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.
I disagree with this stance. There's plenty of room for commercial FOSS. Disclaimer -- I have commercial FOSS on the market.
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?
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?
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.
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.
How do I sell my software on pacman?
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.
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.
That's fair but some companies do want to sell their software and it's not particularly easy on Linux platforms.
There's basically Steam or DIY.
There's basically Steam or DIY.
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.
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.
User adoption, I guess
how much to add thumbnails to the file picker?
Looks like there has been some progress on this front - https://gitlab.gnome.org/GNOME/gtk/-/commit/b0f65ead84c1ecd5...
Amazing! Thanks feaneron!
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 think it's just bad design and tech debt, and maybe leadership having trouble getting someone to take the risk to make the change.
Looks like it's getting fixed, though.
Looks like it's getting fixed, though.
GTK4 is getting them.
It's not GTK4, it's nautilus
The recent GTK4 release added them to the file picker.
Apparently changes in GTK4 made it easier to add
Apparently changes in GTK4 made it easier to add
It has been fixed in GNOME 44.
[deleted]