Fedora Workstation: Our Vision for Linux Desktop(blogs.gnome.org)
blogs.gnome.org
Fedora Workstation: Our Vision for Linux Desktop
https://blogs.gnome.org/uraeus/2021/09/24/fedora-workstation-our-vision-for-linux-desktop/
90 comments
"The same exact tool" as you refer to it has a very high learning curve and includes for just one example its own functional programming language. If you search the web for a solution to a Linux problem, translating the instructions (and an example of what I mean by an "instruction" would be, "add to this config file these lines of text") into instructions that work on NixOS is impossible unless you know a lot about Nixos. I ran NixOS as my daily driver for 2.5 months earlier this year, and I got nowhere close to learning enough about it so that I had a decent chance of being able to translate a solution published on the web that works on most other Linux distros into something that works on NixOS. (I know enough to know that it is unlikely that I would need to learn the aforementioned Nix-specific functional programming language to do the translation, but there are many other pieces of Nixos I would need to master.)
One thing NixOS has going for it though is currently having many more users than Silverblue has if comments on HN are any indication (and they probably are) which is probably an effect of its having been around a lot longer. Wikipedia claims that NixOS's initial release was in 2003.
One thing NixOS has going for it though is currently having many more users than Silverblue has if comments on HN are any indication (and they probably are) which is probably an effect of its having been around a lot longer. Wikipedia claims that NixOS's initial release was in 2003.
> "The same exact tool" as you refer to it has a very high learning curve and includes for just one example its own functional programming language.
So does Emacs and Vim, good luck arguing against those.
So does Emacs and Vim, good luck arguing against those.
No normal users are ever going to edit a configuration file, complete with its own specific syntax, in order to install apps.
No normal users are going to use Linux or MacOS. They are going to use Windows.
Nix is not mutually exclusive with Flatpaks though. You can easily enable flatpaks on a NixOS install. You don't need to choose between them.
SimulaVR (www.simulavr.com) is leaning towards using NixOS as the basis of its VR distro.
Though it's always been a huge pain to get everything set up (especially things involving graphics), once it's set up it works forever for everyone in the ecosystem.
Though it's always been a huge pain to get everything set up (especially things involving graphics), once it's set up it works forever for everyone in the ecosystem.
> all of these is possible with the same exact tool
This sounds nice, but it's the opposite of the Unix philosophy, which will always rub me the wrong way. I thought of systemd this way at first, but then I saw how it was composed of a bunch of different, optional services that can be swapped out for other things fairly easily while still allowing systemd proper to manage and interact with them.
This sounds nice, but it's the opposite of the Unix philosophy, which will always rub me the wrong way. I thought of systemd this way at first, but then I saw how it was composed of a bunch of different, optional services that can be swapped out for other things fairly easily while still allowing systemd proper to manage and interact with them.
Nix is actually a very simple tool, that in fact only does one thing and does it well.
That one thing is building packages in sandboxes and adding them to the nix store. You can see that manual for Nix is actually fairly short: https://nixos.org/manual/nix/stable/
The properties of Nix allow for everything else. This enables NixOS and nixpkgs to exist, and they have much longer manuals:
https://nixos.org/manual/nixos/stable/
https://nixos.org/manual/nixpkgs/stable/
So nix does one thing and does it very well.
Tangent. The "unix philosophy" isn't very true on Linux, and hasn't been since GNU. The problem with "do one thing and do it well" is that very often you need to do more than one thing. You then need to learn a completely different thing to do another basic operation.
Having one tool do literally everything is also unreasonable. But there are natural boundaries for things to exist. It is not unreasonable for the uniq to have a count tool, or for sort to have uniq.
I've been doing this for 20 years now, so I've very comfortable with Linux/Unix tooling. But I see new comers come on. It's often easier for them to script something completely from scratch in python then figure out how to stitch coreutils together.
That one thing is building packages in sandboxes and adding them to the nix store. You can see that manual for Nix is actually fairly short: https://nixos.org/manual/nix/stable/
The properties of Nix allow for everything else. This enables NixOS and nixpkgs to exist, and they have much longer manuals:
https://nixos.org/manual/nixos/stable/
https://nixos.org/manual/nixpkgs/stable/
So nix does one thing and does it very well.
Tangent. The "unix philosophy" isn't very true on Linux, and hasn't been since GNU. The problem with "do one thing and do it well" is that very often you need to do more than one thing. You then need to learn a completely different thing to do another basic operation.
Having one tool do literally everything is also unreasonable. But there are natural boundaries for things to exist. It is not unreasonable for the uniq to have a count tool, or for sort to have uniq.
I've been doing this for 20 years now, so I've very comfortable with Linux/Unix tooling. But I see new comers come on. It's often easier for them to script something completely from scratch in python then figure out how to stitch coreutils together.
Is this a UNIX tool in the same vein as emacs? I'm not sure a package manager that includes a half baked FP programming language can be described as a tool that "only does one thing and does it well".
I get what you're saying, but I don't think it violates the Unix philosophy in that way, at least not any more than any other package manager like apt or dnf does.
Nix as a package manager is made up of multiple tools that interact, such as nix-env, nix-store, nix-shell, etc.
NixOS additionally has nixos-rebuild and other commands that are layered on top of those core Nix commands.
Nix as a package manager is made up of multiple tools that interact, such as nix-env, nix-store, nix-shell, etc.
NixOS additionally has nixos-rebuild and other commands that are layered on top of those core Nix commands.
I don't want to sound hypocritical, but I prefer good old linux distribution, without flatpaks, without strange immutability stuff. I almost like Fedora, I don't like specifically Workstation flavour, but I was able to build my Linux from Fedora Minimal by adding stuff that I need and it was pretty usable in the end. If they'll spend more time at flatpaks at expense of ordinary packages, I guess it's better to just switch to Arch.
And unfortunately, now that Snaps/Flatpack/Nix are getting popular, the "old way" of having stable dependencies that work across the entire OS is less likely to work going forward. People will just break backward compatibility since "everyone just uses Snaps anyway". :(
Which brings me to the question, how come Arch manages to not cause massive problems for users wiry the massive AUR that is even user maintained?
I've been using Arch for like 7 years or something now and it just works, probably because of some very hard work by the maintainers.
I've been using Arch for like 7 years or something now and it just works, probably because of some very hard work by the maintainers.
To be frank, the answer is that it does cause problems for users. I've read countless anecdotes at this point from both camps, some claiming that Arch never breaks and some saying that updates have broken their install.
I personally tried Arch in 2017 for a period of a few weeks, and updates broke my system twice (in different ways). I was able to fix both issues, but decided I didn't want to deal with that. I suspect the difference between the two camps is that those who claim that it doesn't break don't consider something they can fix a breakage.
I personally tried Arch in 2017 for a period of a few weeks, and updates broke my system twice (in different ways). I was able to fix both issues, but decided I didn't want to deal with that. I suspect the difference between the two camps is that those who claim that it doesn't break don't consider something they can fix a breakage.
I stopped worrying about breaking linux workstations and not-virtualized servers after discovering "Relax and Recover" (ReaR) which allows "Acronis-like" ISO rescue to previous "snapshots". I think it's nice to at least know you can. I wrote a guide to backup using sshfs with ReaR, here[1]
[1] https://devblog.juangacovas.info/relax-and-recover-bare-meta...
[1] https://devblog.juangacovas.info/relax-and-recover-bare-meta...
Manjaro would deliver here. Arch based but the devs test packages for two weeks before adding them to their repos.
A lot of excellent improvements to desktop Linux.
Flatpaks have been awesome, its great seeing the community build on flathub.
Sandboxed and straightforward builds of large packages that may or may not be up to date in debian.
Best way to get packages like Blender or Ardour (I need to package up 1 plugin before I migrate) these days.
Use flatseal to lock things down more or less to your liking.
Pipewire has been a big step up and I look forward to moving to wayland on the rest of my machines with kde 5.24 (vr leasing support).
Great work!
Flatpaks have been awesome, its great seeing the community build on flathub.
Sandboxed and straightforward builds of large packages that may or may not be up to date in debian.
Best way to get packages like Blender or Ardour (I need to package up 1 plugin before I migrate) these days.
Use flatseal to lock things down more or less to your liking.
Pipewire has been a big step up and I look forward to moving to wayland on the rest of my machines with kde 5.24 (vr leasing support).
Great work!
First problem in Linux desktop OS: you download a flatpak, or other file, click it, and "no application found" or it opens in a text editor. On a GUI OS, if a user has to go to the command line your design is wrong.
I chose popos, because the second I wanted discord or Spotify on fedora I had to go through a whole page of commands to do it, and it didn't quite run correctly.
When I installed some GUI apps on fedora, they wouldn't show up on the start menu. Had to manually add them, via command line.
Another is media thumbnails. Include ffmpegthumbmailer by default. Don't make me command line basic functionality.
I chose popos, because the second I wanted discord or Spotify on fedora I had to go through a whole page of commands to do it, and it didn't quite run correctly.
When I installed some GUI apps on fedora, they wouldn't show up on the start menu. Had to manually add them, via command line.
Another is media thumbnails. Include ffmpegthumbmailer by default. Don't make me command line basic functionality.
This isn't a problem on Fedora Workstation. .flatpak, .flatpak-ref, .flatpak-repo, and .rpm files can all be opened directly and installed in GNOME Software. And if an app isn't showing up, then the dev either isn't shipping a .desktop file or isn't installing it correctly.
These are odd bugs and not my experience. They include thumbnailers they are licensed to do so for.
And there are many small innovations tickling into Fedora, activated by default: zram, fstrim, earlyoom/systemd-oomd, systemd-resolved, btrfs+compression, and so on. Also the update GUI works reliable, even for release updates - worth recommending as OS for friends & family, too.
In comparison, Debian in the standard installation feels lacking behind, but I hope it will follow the path.
In comparison, Debian in the standard installation feels lacking behind, but I hope it will follow the path.
As a former member of the Red Hat desktop team who helped kickstart several of these initiatives (I did a huge chunk of Wayland, before I passed the reins off to Jonas Adahl), I believe in the vision, but like many other things in the Linux space, it's fighting a very uphill battle for a vision that I personally believe is good, but I can't ever imagine coming true, and when it does, one that's far too late.
Immutability is good, splitting the OS from the applications is good, but what that should imply is a commitment to not break anything, and that's not something you can really wrangle from open-source contributors, who are more interested in writing v7, v8, v9, etc. and deprecating everything before them (though I note this is not strictly a Linux problem, we've seen it in npm/pypi/rubygems and we're even now seeing it from even big vendors like Microsoft, Apple, and Google, but it tends to be more associated with FOSS/Linux communities). Flatpak is an attempt at a technical band-aid for a social and cultural problem, but that culture only makes the problem worse, and the solution ineffective.
We see this now manifest in 100 different application distribution formats, all of which have giant tables of "pro's" vs. "con's" on their homepage, all which are fighting for an increasingly miniscule userbase, heightening a war which never should have existed in the first place. Much like the sound server debates of the 2000s, applications can't simply choose one without getting into a large political turf war, and so they have to distribute in every format known to man to quell a userbase each interested in their own ideas of technical superiority. LibreOffice lists Flatpak, Snap, AppImage, alongside all of the individual distribution packages, right on their home page.
This is all to a userbase who's more often interested with tinkering than stability. Linux communities tend to be ones who have self-selected that they want their computers to be toys, rather than tools to just get their jobs done. Or they believe in some form of Linux elitism; that Linux is somehow technically superior to other operating systems, and adapting good ideas from those other systems means losing some form of symbolic war, one which they'll fight hard against. Moving the needle from a fun system that's endlessly tinkerable to a boring system that runs the apps you need and is stable is attempting to move the culture in that direction, and honestly a lot of the desktop Linux community is just uninterested in that vision.
Also, while I was at Red Hat, Colin Walters was probably one of the smartest and most influential people I met, and they're the real powerhouse behind a lot of these ideas (I remember when ostree was hacktree, somewhat made out of frustration so they didn't have to break their laptop while testing new OS versions). Their writing and the conversations I had with them was one of the big things to get me out of the "Linux elitism" spell. I highly recommend their writing on these topics: https://people.gnome.org/~walters/docs/packages.txt https://people.gnome.org/~walters/docs/
Immutability is good, splitting the OS from the applications is good, but what that should imply is a commitment to not break anything, and that's not something you can really wrangle from open-source contributors, who are more interested in writing v7, v8, v9, etc. and deprecating everything before them (though I note this is not strictly a Linux problem, we've seen it in npm/pypi/rubygems and we're even now seeing it from even big vendors like Microsoft, Apple, and Google, but it tends to be more associated with FOSS/Linux communities). Flatpak is an attempt at a technical band-aid for a social and cultural problem, but that culture only makes the problem worse, and the solution ineffective.
We see this now manifest in 100 different application distribution formats, all of which have giant tables of "pro's" vs. "con's" on their homepage, all which are fighting for an increasingly miniscule userbase, heightening a war which never should have existed in the first place. Much like the sound server debates of the 2000s, applications can't simply choose one without getting into a large political turf war, and so they have to distribute in every format known to man to quell a userbase each interested in their own ideas of technical superiority. LibreOffice lists Flatpak, Snap, AppImage, alongside all of the individual distribution packages, right on their home page.
This is all to a userbase who's more often interested with tinkering than stability. Linux communities tend to be ones who have self-selected that they want their computers to be toys, rather than tools to just get their jobs done. Or they believe in some form of Linux elitism; that Linux is somehow technically superior to other operating systems, and adapting good ideas from those other systems means losing some form of symbolic war, one which they'll fight hard against. Moving the needle from a fun system that's endlessly tinkerable to a boring system that runs the apps you need and is stable is attempting to move the culture in that direction, and honestly a lot of the desktop Linux community is just uninterested in that vision.
Also, while I was at Red Hat, Colin Walters was probably one of the smartest and most influential people I met, and they're the real powerhouse behind a lot of these ideas (I remember when ostree was hacktree, somewhat made out of frustration so they didn't have to break their laptop while testing new OS versions). Their writing and the conversations I had with them was one of the big things to get me out of the "Linux elitism" spell. I highly recommend their writing on these topics: https://people.gnome.org/~walters/docs/packages.txt https://people.gnome.org/~walters/docs/
I've read some of your old blog posts so I know where you're coming from, and I generally agree with your comment. However it seems they are stuck between a rock and a hard place. Without using a stack like this, the app deployment story on Linux is absolutely atrocious, and would just get worse.
I'd argue: whether using a stack like this or not, the app deployment story on Linux is absolutely atrocious. There are people in this thread who say they're never going to use Flatpak, some for valid technical reasons, others for more ideological reasons. And that remains the case, no however flawed you or I might think those reasons are.
So if an app developer wishes to reach those users, they can't rely on this stack to do it. You could ignore those users, sure, but at this point, why are you making a Linux application? It would be much more attractive to deploy on Windows or Mac. If you're trying to convince people to make Linux applications, you need to make it attractive and painless. But you can't solve social and cultural problems; problems of ideological differences, no matter how much you try to patch around it with new technology.
So if an app developer wishes to reach those users, they can't rely on this stack to do it. You could ignore those users, sure, but at this point, why are you making a Linux application? It would be much more attractive to deploy on Windows or Mac. If you're trying to convince people to make Linux applications, you need to make it attractive and painless. But you can't solve social and cultural problems; problems of ideological differences, no matter how much you try to patch around it with new technology.
Those people are just vocal.
The rest of us like and appreciate flathub.
Linux audio really really needed a better story and pipewire and flathub have really changed that.
I think musicians will suddenly find they can have a reliable quick setup on most any distribution with just these two changes.
The rest of us like and appreciate flathub.
Linux audio really really needed a better story and pipewire and flathub have really changed that.
I think musicians will suddenly find they can have a reliable quick setup on most any distribution with just these two changes.
> Linux audio really really needed a better story
This is true
> pipewire and flathub have really changed that.
Pipewire sure did. Flathub only ate more of my storage, CPU and battery. I see no way that Flathub is responsible for "changing Linux audio", especially not even remotely on the scale that Pipewire did.
This is true
> pipewire and flathub have really changed that.
Pipewire sure did. Flathub only ate more of my storage, CPU and battery. I see no way that Flathub is responsible for "changing Linux audio", especially not even remotely on the scale that Pipewire did.
I've noticed a lot of smaller creativity/productivity apps are not available in distro repos. They're far too niche to get attention from distro packagers. However a lot of them are in Flathub and they work on any distro.
I find it curious you make that comparison about Pipewire because to me, Pipewire is just an incremental improvement for audio, not really changing anything on a giant scale. Most pro audio apps were already using Jack and got all the benefits of that type of system. Pipewire only makes it so they could connect to the odd Pulseaudio app, which is pretty rare. Not meaning to downplay it or anything. It is still a pretty good improvement, but its major contribution is what it does for video, not audio.
I find it curious you make that comparison about Pipewire because to me, Pipewire is just an incremental improvement for audio, not really changing anything on a giant scale. Most pro audio apps were already using Jack and got all the benefits of that type of system. Pipewire only makes it so they could connect to the odd Pulseaudio app, which is pretty rare. Not meaning to downplay it or anything. It is still a pretty good improvement, but its major contribution is what it does for video, not audio.
jack has been a consistent source of pain for musicians and people that need proaudio.
its great useful software but most folks don't have the skills to get it working without drama and breaking pulse etc.
Linux loses many independent minded folks over jack drama. It's a shame but this is a new day I think.
Pipewire gives a great out of box experience that should just work on whatever distribution they choose. That's not incremental improvement for people wanting proaudio.
its great useful software but most folks don't have the skills to get it working without drama and breaking pulse etc.
Linux loses many independent minded folks over jack drama. It's a shame but this is a new day I think.
Pipewire gives a great out of box experience that should just work on whatever distribution they choose. That's not incremental improvement for people wanting proaudio.
I can't agree, ever since jack2 I actually never had any problem getting it to work with pulse. You may be thinking of jack1. Pipewire does make it easier to do this though.
PipeWire handles ALSA much, much better than jack ever did on any of my machines. Oh, and handling audio permissions via Unix groups made me want to rm -rf /
I don't know about alsa, I don't remember what happened when I tried that years ago. Yeah Unix permissions is bad, Pipewire is definitely better there. The security is a big improvement but I also wouldn't say that's anything revolutionary.
> the odd Pulseaudio app, which is pretty rare.
Unless you count Firefox?
Unless you count Firefox?
Well I don't usually need to connect audio from Firefox directly into a DAW or synthesizer. And technically that could still be done with Jack, it's just a bit harder to do because you have to create additional pulseaudio sinks first.
I was just referring to the fact that it is no longer possible to run Firefox on ALSA without PA. And I only mentioned it because it annoys me.
You may want to try this project: https://github.com/i-rinat/apulse
But I don't recommend using only ALSA without a sound server on a desktop, the usability of it is pretty bad.
But I don't recommend using only ALSA without a sound server on a desktop, the usability of it is pretty bad.
Apulse works for Firefox.
I have found ALSA useable, over many years. But I've never understood the config notation, so my configs have always been pretty cargo-cultish.
I have found ALSA useable, over many years. But I've never understood the config notation, so my configs have always been pretty cargo-cultish.
>I've noticed a lot of smaller creativity/productivity apps are not available in distro repos. They're far too niche to get attention from distro packagers.
That's what AUR is for.
That's what AUR is for.
Sure, but that's one distro.
I don't know, I see a lot of smaller apps that are only deployed as Flatpaks or Snaps or whatever. It doesn't seem to make a difference to them that the audience is small.
(And to be honest, none of this stuff is exciting or new to me. It's just a re-packaging of the technology behind Docker but for desktop apps)
Edit: For LibreOffice it's likely that the project is popular enough that different people all contributed all those packaging options, so I don't think it's like a burden on them or anything. If something stops being maintained they'll just drop it.
(And to be honest, none of this stuff is exciting or new to me. It's just a re-packaging of the technology behind Docker but for desktop apps)
Edit: For LibreOffice it's likely that the project is popular enough that different people all contributed all those packaging options, so I don't think it's like a burden on them or anything. If something stops being maintained they'll just drop it.
>Personally, I'm over 30 now. I once watched one of my riends using Ubuntu install security updates and be confused by their patch to firefox to pop up a "I'm broken now" dialog. Screw that. I'm turning the dial towards reliability.
This is a great punchline from your first link.
This is a great punchline from your first link.
My experience has always been that pure Debian is far more stable than Ubuntu. I know it shouldn't be, but...it is.
Note the existence of the included Pipeline audio/video server. The article mentions it should be low enough latency that it could be used in professional audio while also be approachable from the "normal user's" perspective.
I may try Fedora just for that.
I may try Fedora just for that.
Pipewire is really great for pro audio, big upgrade for me with multiple sound inputs handled well now.
Check out flathub for audio apps, do a "flatpak search lv2" to find the plugins for ardour and audacity.
Check out flathub for audio apps, do a "flatpak search lv2" to find the plugins for ardour and audacity.
Pipewire is now the default for many distributions including Ubuntu, Archlinux, NixOS, and Fedora.
Uh yeah no thanks, I'll just stick with Debian. Served me well 20+ years so far!
Cool roadmap, but a focus on Flatpak basically turns me away from ever having a use for the distro now. Really, sandboxed software is nothing but trouble on the Linux desktop right now, and frankly I think it's a distraction from larger issues that could be solved easier. Nothing is less attractive to a user than opening an app to find the ugly Adwaita interface instead of their distro's choice, and then finding that your WM can't map the resize controls properly because the window forwarding isn't working. Does your app use MPRIS? Good luck getting it working! You want configuration files in sane locations? How about we make it a pain in the ass to access your own files instead. It's death by a thousand papercuts with Flatpak, all in exchange for a modicum of developer convenience.
I always lose karma for espousing this opinion, but it's one I'll happily parrot until the Linux desktop is finally dead again: if your software is exclusively available as a Flatpak, good luck getting me to use it.
I always lose karma for espousing this opinion, but it's one I'll happily parrot until the Linux desktop is finally dead again: if your software is exclusively available as a Flatpak, good luck getting me to use it.
Would you consider revising this opinion if I showed you it was based on incorrect information?
>Nothing is less attractive to a user than opening an app to find the ugly Adwaita interface instead of their distro's choice
This is by design and is not fixable in any distro with any packaging system and highlights an underlying problem with any theming. Avoiding flatpak sadly will not fix it :( The only choices really are to disable themes, or patch/remove the package when it breaks with some theme. The first is what flatpak apps will do because they want to work on any distro regardless if the user has a broken theme, the second it seems is what distributions usually do.
>Does your app use MPRIS? Good luck getting it working!
This should be really easy to fix, all you have to do is white list the d-bus path for it. You should consider reporting that as a bug to the flatpak packager also.
>You want configuration files in sane locations? How about we make it a pain in the ass to access your own files instead.
Huh? The config files are just stored in ~/.var/app/. It's not a pain in the ass to access them at all.
>Nothing is less attractive to a user than opening an app to find the ugly Adwaita interface instead of their distro's choice
This is by design and is not fixable in any distro with any packaging system and highlights an underlying problem with any theming. Avoiding flatpak sadly will not fix it :( The only choices really are to disable themes, or patch/remove the package when it breaks with some theme. The first is what flatpak apps will do because they want to work on any distro regardless if the user has a broken theme, the second it seems is what distributions usually do.
>Does your app use MPRIS? Good luck getting it working!
This should be really easy to fix, all you have to do is white list the d-bus path for it. You should consider reporting that as a bug to the flatpak packager also.
>You want configuration files in sane locations? How about we make it a pain in the ass to access your own files instead.
Huh? The config files are just stored in ~/.var/app/. It's not a pain in the ass to access them at all.
> Would you consider revising this opinion if I showed you it was based on incorrect information?
Maybe! Let's see how much of it I agree with, first:
> Avoiding flatpak sadly will not fix it
Werks on my machine. All the apps I use (even the GTK4 ones) adopt my system theme perfectly fine as long as I'm not using Snaps/Flatpaks/containerized distribution.
> The first is what flatpak apps will do because they want to work on any distro regardless if the user has a broken theme
They don't need to do this to prevent breakage. GTK has always had fallback stylesheets for this exact purpose, Flatpak has decided to circumvent them because of the Gnome foundation's wheel-spinning "don't theme our app" movement. There's quite literally nothing stopping the Flatpak devs from referring to your systems default stylesheet for all UI draws.
> This should be really easy to fix, all you have to do is white list the d-bus path for it.
That's more work than I have to do on every other version of every package I use
> You should consider reporting that as a bug to the flatpak packager also.
Wait, so now they have two packages to maintain? One being the true binary copy of their application, and the other being a sandboxed version that is apparently more likely to break? That alone is enough to disqualify Flatpak, because it's really just "another competing standard" a-la XKCD.
> Huh? The config files are just stored in ~/.var/app/.
Ah yes, the classic UNIX config directory '~/.var/app/', a directory that never existed until Flatpak came along and decided it was somehow the new standard. Great stuff!
Maybe! Let's see how much of it I agree with, first:
> Avoiding flatpak sadly will not fix it
Werks on my machine. All the apps I use (even the GTK4 ones) adopt my system theme perfectly fine as long as I'm not using Snaps/Flatpaks/containerized distribution.
> The first is what flatpak apps will do because they want to work on any distro regardless if the user has a broken theme
They don't need to do this to prevent breakage. GTK has always had fallback stylesheets for this exact purpose, Flatpak has decided to circumvent them because of the Gnome foundation's wheel-spinning "don't theme our app" movement. There's quite literally nothing stopping the Flatpak devs from referring to your systems default stylesheet for all UI draws.
> This should be really easy to fix, all you have to do is white list the d-bus path for it.
That's more work than I have to do on every other version of every package I use
> You should consider reporting that as a bug to the flatpak packager also.
Wait, so now they have two packages to maintain? One being the true binary copy of their application, and the other being a sandboxed version that is apparently more likely to break? That alone is enough to disqualify Flatpak, because it's really just "another competing standard" a-la XKCD.
> Huh? The config files are just stored in ~/.var/app/.
Ah yes, the classic UNIX config directory '~/.var/app/', a directory that never existed until Flatpak came along and decided it was somehow the new standard. Great stuff!
Flatpak doesn't get in the way of theming at all. (I wrote support for flatpak to literally help auto installing themes...)
I don't really want to argue with you but I think you're still basing this on false information or on misconceptions, I'll try to clear things up. Of course you are free to use or not use whatever packaging solution you want for whatever reason.
>All the apps I use (even the GTK4 ones) adopt my system theme perfectly fine as long as I'm not using Snaps/Flatpaks/containerized distribution.
That's great for you, unfortunately this cannot be guaranteed for all combinations of themes and apps. There are "tricks" you can do to get your themes to work in a flatpak such as mounting the theme directory into the container but this would probably be considered an unsupported hack, I wouldn't recommend it. The only way this could ever be supported is if somebody tested your theme with every version of every flatpak app and then filed/fixed bugs everywhere, which is really not a reasonable thing to ask of theme developers so it probably won't ever be supported.
>GTK has always had fallback stylesheets for this exact purpose
This is not about the fallback style sheet, this problem is specifically about the style sheet used by the app and how it can conflict with the theme. I'm not sure if you're familiar with CSS, but the way it works is that anything from the theme can override things from the fallback style sheet and that could mess things up if the app expects something different to be there.
>Flatpak has decided to circumvent them because of the Gnome foundation's wheel-spinning "don't theme our app" movement. There's quite literally nothing stopping the Flatpak devs from referring to your systems default stylesheet for all UI draws.
Have you read the "stop theming my app" page all the way to the bottom? Please re-read it if you can, it shows examples of how theming is unreliable and can break apps. That's what would be stopping them. Also this wouldn't really be up to "flatpak devs" to handle either, this would be up to the maintainers of the GNOME SDK and app developers.
>That's more work than I have to do on every other version of every package I use
How? It's a bug, it's not different from any other bug that you would report. Once it's fixed you don't have to worry about it.
>Wait, so now they have two packages to maintain? One being the true binary copy of their application, and the other being a sandboxed version that is apparently more likely to break?
No, I've noticed often the flatpak maintainer and your distro maintainer are different people. There isn't any "true binary copy", unless you consider the binaries that are provided by the developer, which you should check which ones those are. They could be flatpak or they could be something else. And actually the sandboxed version should be less likely to break since the dependencies are pinned and there are less moving parts there.
>it's really just "another competing standard" a-la XKCD
Yes, that's sort of true, you could also use Snaps or AppImage or a similar thing. However these are not the same as distro packages so in that regard they're not "another competing standard". This is a package that you can install on any distro and have a reasonable guarantee that you'll get the exact same version that runs in the exact same environment.
>Ah yes, the classic UNIX config directory '~/.var/app/', a directory that never existed until Flatpak came along and decided it was somehow the new standard. Great stuff!
I don't understand what you mean here. If you're being sarcastic, please don't do that, it doesn't add anything of value to the conversation. These apps are sandboxed, so you probably want them in a separate directory so they don't clobber your home directory. There is no UNIX config directory for sandboxed apps so they had to come up with something new. What exactly is the problem here?
>All the apps I use (even the GTK4 ones) adopt my system theme perfectly fine as long as I'm not using Snaps/Flatpaks/containerized distribution.
That's great for you, unfortunately this cannot be guaranteed for all combinations of themes and apps. There are "tricks" you can do to get your themes to work in a flatpak such as mounting the theme directory into the container but this would probably be considered an unsupported hack, I wouldn't recommend it. The only way this could ever be supported is if somebody tested your theme with every version of every flatpak app and then filed/fixed bugs everywhere, which is really not a reasonable thing to ask of theme developers so it probably won't ever be supported.
>GTK has always had fallback stylesheets for this exact purpose
This is not about the fallback style sheet, this problem is specifically about the style sheet used by the app and how it can conflict with the theme. I'm not sure if you're familiar with CSS, but the way it works is that anything from the theme can override things from the fallback style sheet and that could mess things up if the app expects something different to be there.
>Flatpak has decided to circumvent them because of the Gnome foundation's wheel-spinning "don't theme our app" movement. There's quite literally nothing stopping the Flatpak devs from referring to your systems default stylesheet for all UI draws.
Have you read the "stop theming my app" page all the way to the bottom? Please re-read it if you can, it shows examples of how theming is unreliable and can break apps. That's what would be stopping them. Also this wouldn't really be up to "flatpak devs" to handle either, this would be up to the maintainers of the GNOME SDK and app developers.
>That's more work than I have to do on every other version of every package I use
How? It's a bug, it's not different from any other bug that you would report. Once it's fixed you don't have to worry about it.
>Wait, so now they have two packages to maintain? One being the true binary copy of their application, and the other being a sandboxed version that is apparently more likely to break?
No, I've noticed often the flatpak maintainer and your distro maintainer are different people. There isn't any "true binary copy", unless you consider the binaries that are provided by the developer, which you should check which ones those are. They could be flatpak or they could be something else. And actually the sandboxed version should be less likely to break since the dependencies are pinned and there are less moving parts there.
>it's really just "another competing standard" a-la XKCD
Yes, that's sort of true, you could also use Snaps or AppImage or a similar thing. However these are not the same as distro packages so in that regard they're not "another competing standard". This is a package that you can install on any distro and have a reasonable guarantee that you'll get the exact same version that runs in the exact same environment.
>Ah yes, the classic UNIX config directory '~/.var/app/', a directory that never existed until Flatpak came along and decided it was somehow the new standard. Great stuff!
I don't understand what you mean here. If you're being sarcastic, please don't do that, it doesn't add anything of value to the conversation. These apps are sandboxed, so you probably want them in a separate directory so they don't clobber your home directory. There is no UNIX config directory for sandboxed apps so they had to come up with something new. What exactly is the problem here?
Listen, I don't care if my fonts are 15% less viewable with my custom color scheme. I don't care if I'm manually impeding the accessibility of my system by refusing to use Flatpaks.
THIS is the issue, the issue with almost every paragraph of your comments that I've read.
Your assumption that everyone cares about this is false, there's no "misconceptions" here. The only misconception is the one that GNOME is the center of the Linux universe... which is tacitly untrue. GNOME is an extension of a modular system, one that was also designed to be built upon to create better experiences. GNOME once also shared that sentiment of modularity, and it worked perfectly fine for it: GTK2 and GTK3 both respectively inspired several desktops to exist purely based around their design languages, and worked pretty much flawlessly. If the GNOME team is scaling down their ambition and deciding to be less modular, then fine: let's put the tiger on the table and yell at it. You can publicly say that you're distributing with Flatpak because you're too lazy to debug a native version, I won't take any umbridge. I'll just compile the app myself and use it as normal, no skin off my back.
The ultimate Achilles heel of Flatpak is that it will inexorably always be a second-class package manager. You'll never install it without having another, feature-complete package manager operating alongside it. The UNIX philosophy is to do one thing and do it well: Flatpak tries doing a hundred things, and can't do a single one better than another, dedicated tool. There is no argument here. Flatpak is not, cannot, and will never be considered a real package manager. It's a second-class supplement at best, and abhorrent bloatware when it stops working properly.
THIS is the issue, the issue with almost every paragraph of your comments that I've read.
Your assumption that everyone cares about this is false, there's no "misconceptions" here. The only misconception is the one that GNOME is the center of the Linux universe... which is tacitly untrue. GNOME is an extension of a modular system, one that was also designed to be built upon to create better experiences. GNOME once also shared that sentiment of modularity, and it worked perfectly fine for it: GTK2 and GTK3 both respectively inspired several desktops to exist purely based around their design languages, and worked pretty much flawlessly. If the GNOME team is scaling down their ambition and deciding to be less modular, then fine: let's put the tiger on the table and yell at it. You can publicly say that you're distributing with Flatpak because you're too lazy to debug a native version, I won't take any umbridge. I'll just compile the app myself and use it as normal, no skin off my back.
The ultimate Achilles heel of Flatpak is that it will inexorably always be a second-class package manager. You'll never install it without having another, feature-complete package manager operating alongside it. The UNIX philosophy is to do one thing and do it well: Flatpak tries doing a hundred things, and can't do a single one better than another, dedicated tool. There is no argument here. Flatpak is not, cannot, and will never be considered a real package manager. It's a second-class supplement at best, and abhorrent bloatware when it stops working properly.
>Your assumption that everyone cares about this is false, there's no "misconceptions" here. The only misconception is the one that GNOME is the center of the Linux universe... which is tacitly untrue.
I never said that everyone cares about this, nor did I say that GNOME is the center of the Linux universe, not sure where you got either of those from. I agree those statements are not true. However, developers of some apps do care that their apps are broken by themes. If you want to make your fonts 15% less viewable that's fine, I'll be happy to give you tips on how to do that, but you deserve to know about the technical issues with that and why it causes enough trouble that app developers don't want to support it. Just my opinion: impeding the accessibility of your system and manually compiling all your apps just because of a perceived slight against some developers is a bad idea.
>GNOME is an extension of a modular system, one that was also designed to be built upon to create better experiences. GNOME once also shared that sentiment of modularity
So this is a misconception, theming was always buggy and really badly supported in both GTK2 and GTK3, and considered mostly a hack. It kind of worked if people kept updating the themes constantly but it was a really bad uphill battle. You can continue hacking things that way if you want, but I expect some app developers will try to discourage you from doing it because eventually it really only becomes a source of bugs with no benefit to the user. Personally I also would do discourage you from that if you're trying to accomplish a specific goal with these platforms besides just messing with the font contrast, it could be a lot more productive if you wanted to work on a more robust way of doing things. But it's really up to you, I can only present you an option of what to do and then you have to decide for yourself.
>You'll never install it without having another, feature-complete package manager operating alongside it.
This is true for a lot of distros, but Flatpak isn't just a package manager.
>Flatpak tries doing a hundred things, and can't do a single one better than another, dedicated tool. There is no argument here. Flatpak is not, cannot, and will never be considered a real package manager. It's a second-class supplement at best, and abhorrent bloatware when it stops working properly.
I'd advise against this type of strong rhetoric, it's easy to make these hyperbolic flourishes but what you've said isn't really true and lacks any facts to back it up. The underlying technologies (mostly ostree and bwrap) are pretty generic and are dedicated tools by themselves, Flatpak just puts those together with some repos. You could use those tools alone if you wanted. I'd agree that Flatpak would be pretty redundant if other package managers used ostree and could access its repos, but currently they cannot. It provides something different than your distro package manager.
I never said that everyone cares about this, nor did I say that GNOME is the center of the Linux universe, not sure where you got either of those from. I agree those statements are not true. However, developers of some apps do care that their apps are broken by themes. If you want to make your fonts 15% less viewable that's fine, I'll be happy to give you tips on how to do that, but you deserve to know about the technical issues with that and why it causes enough trouble that app developers don't want to support it. Just my opinion: impeding the accessibility of your system and manually compiling all your apps just because of a perceived slight against some developers is a bad idea.
>GNOME is an extension of a modular system, one that was also designed to be built upon to create better experiences. GNOME once also shared that sentiment of modularity
So this is a misconception, theming was always buggy and really badly supported in both GTK2 and GTK3, and considered mostly a hack. It kind of worked if people kept updating the themes constantly but it was a really bad uphill battle. You can continue hacking things that way if you want, but I expect some app developers will try to discourage you from doing it because eventually it really only becomes a source of bugs with no benefit to the user. Personally I also would do discourage you from that if you're trying to accomplish a specific goal with these platforms besides just messing with the font contrast, it could be a lot more productive if you wanted to work on a more robust way of doing things. But it's really up to you, I can only present you an option of what to do and then you have to decide for yourself.
>You'll never install it without having another, feature-complete package manager operating alongside it.
This is true for a lot of distros, but Flatpak isn't just a package manager.
>Flatpak tries doing a hundred things, and can't do a single one better than another, dedicated tool. There is no argument here. Flatpak is not, cannot, and will never be considered a real package manager. It's a second-class supplement at best, and abhorrent bloatware when it stops working properly.
I'd advise against this type of strong rhetoric, it's easy to make these hyperbolic flourishes but what you've said isn't really true and lacks any facts to back it up. The underlying technologies (mostly ostree and bwrap) are pretty generic and are dedicated tools by themselves, Flatpak just puts those together with some repos. You could use those tools alone if you wanted. I'd agree that Flatpak would be pretty redundant if other package managers used ostree and could access its repos, but currently they cannot. It provides something different than your distro package manager.
[deleted]
> all in exchange for a modicum of developer convenience.
It's really not for the developer convenience. It's actually harder to build for flatpak than not from the dev's point of view. The convenience of the unified distribution is for the consumers.
It's really not for the developer convenience. It's actually harder to build for flatpak than not from the dev's point of view. The convenience of the unified distribution is for the consumers.
It's both... nobody wants to make 5 packages.
I have never heard of pet containers before. Have I been living under a rock or is this something new?
It's an obscure concept because most people either did away with pets when they adopted containers or they run pet workloads in VMs.
I don't know if it's as much "obscure concept" as "failing to adapt to the new system by reimplementing your old system in it". E.g. you could technically run a container by putting everything including code in a mounted volume and set your CMD to call it. That would be awful, you get all the downsides of containers with none of the benefits, etc, but if you refuse to use the new tools 'with the grain' that's the kind of thing you end up with.
In the context of Silverblue I think they have a reasonable use case for pet containers. If your base system and all your containers are immutable that leaves you nowhere to do learning/testing/experimentation.
In this context it seems to be something else
I've seen some videos on using Silverblue as a desktop. I like the idea of it, but it's kind of a pain to use at the moment.
rasengan(1)
No instances of the string "browser" or "brows" on that page. 4 instance of "web", but 2 refer to webcams and the other 2 are part of the page's UI.
I wonder if the author realizes that the biggest threat to Linux on the desktop is the possibility that all of the mainstream browsers will drop support for it. By "mainstream" I mean that the browser can be used to interact with almost all the sites that Safari or Chrome can be used to interact with.
Even if the current crop of mainstream browsers on Linux (namely, Firefox, Chrome and Edge) do not actually announce an end of support of Linux, just neglecting it enough will be enough to get me to leave Linux, and I believe many others currently using Linux feel the same way. It's not like a person can do without daily access to a mainstream browser (and I am saying that as someone who does not even like the web).
I've been using Chrome directly under Wayland (i.e., starting it with the flags -enable-features=UseOzonePlatform -ozone-platform=wayland, because Xorg is definitely going away) and the rate of bugs is definitely higher than the Chrome team would tolerate on Windows or Mac. (I've used Chrome for a cumulative 300 hours or more over the last 2 years on Windows and Mac.)
So far I haven't seen any signs that security bugs in the Linux version get any less attention than the Windows or Mac versions get; that is a good sign.
I wonder if the author realizes that the biggest threat to Linux on the desktop is the possibility that all of the mainstream browsers will drop support for it. By "mainstream" I mean that the browser can be used to interact with almost all the sites that Safari or Chrome can be used to interact with.
Even if the current crop of mainstream browsers on Linux (namely, Firefox, Chrome and Edge) do not actually announce an end of support of Linux, just neglecting it enough will be enough to get me to leave Linux, and I believe many others currently using Linux feel the same way. It's not like a person can do without daily access to a mainstream browser (and I am saying that as someone who does not even like the web).
I've been using Chrome directly under Wayland (i.e., starting it with the flags -enable-features=UseOzonePlatform -ozone-platform=wayland, because Xorg is definitely going away) and the rate of bugs is definitely higher than the Chrome team would tolerate on Windows or Mac. (I've used Chrome for a cumulative 300 hours or more over the last 2 years on Windows and Mac.)
So far I haven't seen any signs that security bugs in the Linux version get any less attention than the Windows or Mac versions get; that is a good sign.
Quite a lot of webdevs use linux, which is a huge reason for browsers to maintain compatibility. Quite a few of the people building the browsers daily-drive linux too, which helps.
If you use a browser with experimental flags don't you expect some bugs? Just the fact that "supporting linux" means dozens of distros, DEs, WMs and two display server protocols (three if you include android and four if you also include some older ubuntu variants) means that the number of bugs is probably expected to be higher.
In short: I expect browsers to be buggier on linux, and I do not think there is a large risk they will stop supporting linux.
If you use a browser with experimental flags don't you expect some bugs? Just the fact that "supporting linux" means dozens of distros, DEs, WMs and two display server protocols (three if you include android and four if you also include some older ubuntu variants) means that the number of bugs is probably expected to be higher.
In short: I expect browsers to be buggier on linux, and I do not think there is a large risk they will stop supporting linux.
> Just the fact that "supporting linux" means dozens of distros, DEs, WMs and two display server protocols (three if you include android and four if you also include some older ubuntu variants)
So five if you use ChromeOS?
So five if you use ChromeOS?
Yeah, didn't even think about chromeOS.
I don't really know how separated the concept of the "application" chrome and the "display server" chromeOS are.
I know chromeOS can run x11 apps, but is that within the chrome runtime or beside it?
EDIT: Seems I need to read up about Freon, which is what chromeOS uses (used?) instead of wayland/x11. So yeah, at least 5.
I don't really know how separated the concept of the "application" chrome and the "display server" chromeOS are.
I know chromeOS can run x11 apps, but is that within the chrome runtime or beside it?
EDIT: Seems I need to read up about Freon, which is what chromeOS uses (used?) instead of wayland/x11. So yeah, at least 5.
>I wonder if the author realizes that the biggest threat to Linux on the desktop is the possibility that all of the mainstream browsers will drop support for it.
This seems unlikely since most Google employees use Linux workstations.
This seems unlikely since most Google employees use Linux workstations.
That's a very good sign!
Do they mostly use Chrome (as opposed to something based on Chromium)?
Do they mostly use Chrome (as opposed to something based on Chromium)?
Yet at Google IO is almost only macs at the sessions.
I've never been to Google IO, but I'd imagine that you see more Macs for presentations/sessions because they just work on the go. Working at a big tech company in the past, I had a beefy Linux workstation and a Thinkpad that ran Windows that I would only ever use for giving presentations/teaching classes, or while travelling for work.
When my friend used to work there, he was issued a macbook pro which was used mainly to ssh into his Linux workstation from a Chrome tab.
I hate to be rude, but IO doesn't exactly bring to mind the most clever or dedicated programmers.
You are only being rude regarding some of the key people working on Android, ChromeOS, Dart, Go and Chrome.
It is a matter of how their lack of cleverness and dedication might affect some of the products you might be using right now.
It is a matter of how their lack of cleverness and dedication might affect some of the products you might be using right now.
It's good you are testing their experimental Wayland support, but there might be reasons it is not default yet.
> Xorg is definitely going away
Are you sure about that? I mean Xorg is going away, but XWayland is not. I've heard alsa is going away too for decades. Pipewire still implements support for it's API.
I don't think XWayland is going anywhere for the foreseeable future.
> Xorg is definitely going away
Are you sure about that? I mean Xorg is going away, but XWayland is not. I've heard alsa is going away too for decades. Pipewire still implements support for it's API.
I don't think XWayland is going anywhere for the foreseeable future.
Use of the term "alsa" is confusing here because ALSA refers to both the kernel interface in /dev and the userspace API in alsalib. The ALSA userspace API is mostly not relevant to applications, new apps probably will not target that and will instead target Pulse, Jack or Pipewire. Of course, Pulse, Jack and Pipewire still use the ALSA kernel API internally, and do implement compatibility for its userspace API just so that older applications still work.
You're correct that XWayland is likely not going away any time soon but I would suggest avoiding it if you can, it's only for compatibility with legacy apps. It still has some of the same security issues as Xorg but they're confined only to other concurrently-run XWayland apps.
You're correct that XWayland is likely not going away any time soon but I would suggest avoiding it if you can, it's only for compatibility with legacy apps. It still has some of the same security issues as Xorg but they're confined only to other concurrently-run XWayland apps.
On my install (Fedora 34, Gnome 40, Chrome Stable) if I run Chrome under XWayland (i.e., if I refrain from giving the flags -enable-features=UseOzonePlatform and -ozone-platform=wayland when starting Chrome) and set Gnome's scaling factor to 200% (gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']", then using the "display" tab of Gnome's Settings app), Chrome is blurry. Probably it is rendering into a framebuffer, then that buffer is being scaled up such that every pixel in the buffer becomes a 2-by-2 square of pixels on my screen, hence my experience of blurriness. I don't own a hi-DPI monitor, but if I did do you know how to avoid everything's being drawn twice as small as usual without blurriness, i.e., without essentially downgrading the hi-DPI monitor to a normal-DPI monitor?
If (as I suspect) a person cannot do what I asked you how to do, i.e., a person cannot currently configure the set of software I described above to be normal sized on a hi-DPI display without blurriness and without "full Xorg" (i.e., not just XWayland, i.e., requiring parts of X11 that definitely aren't being maintained anymore), do you expect XWayland to be improved so that that becomes possible in the future?
If (as I suspect) a person cannot do what I asked you how to do, i.e., a person cannot currently configure the set of software I described above to be normal sized on a hi-DPI display without blurriness and without "full Xorg" (i.e., not just XWayland, i.e., requiring parts of X11 that definitely aren't being maintained anymore), do you expect XWayland to be improved so that that becomes possible in the future?
If this is working correctly on other apps, then it's probable that Chrome's Wayland support is not complete yet.
No, it works on no app (that hasn't been modified and configured to speak the Wayland protocol) because of a fundamental limitation of XWayland.
Sorry I misread your comment, ignore me. Although I will add: It might be possible that someone gets high-DPI working eventually in XWayland. It's unlikely that X11 will ever support multi-DPI in the same way as Wayland. There is an open MR for something like it though: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
[deleted]
ChromeOS is a Linux based OS to run Chrome. Although Freon is not a Wayland compositor, I still think you are mostly safe for the time being. I think in next ten years we can have a few sad surprises in desktop Linux.
Over flatpaks and snaps, I choose Nix. I really don't want to shove everything I do into per application containers.
Actually, every single bullet point they mentioned is solved in NixOS.
Distinct packages? Check
Immutable OS with trivial and guaranteed roll back? Check
Different applications using different libraries? Check
Pipewire? Check
Different libgl support? Check
The best part is that all of these is possible with the same exact tool. It isn't a hodgepodge of different tools to accomplish different tasks.