Fedora Workstation: Our Vision for Linux Desktop

https://blogs.gnome.org/uraeus/2021/09/24/fedora-workstation-our-vision-for-linux-desktop/

74 84 5 years ago

blogs.gnome.org

vondur• 5 years ago

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.

hollerith5• 5 years ago

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.

curt153• 5 years ago

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.

hollerith5• 5 years ago

That's a very good sign!

Do they mostly use Chrome (as opposed to something based on Chromium)?

Barrin92• 5 years ago

out of interest are Google employees still on their own version of Debian? I remember them switching from Ubuntu a while ago.

pjmlp2• 5 years ago

Yet at Google IO is almost only macs at the sessions.

SahAssar2• 5 years ago

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.

kaladin-jasnah• 5 years ago

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?

georgyo4• 5 years ago

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.

BrightGlow15• 5 years ago

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.

hollerith5• 5 years ago

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?

hawski• 5 years ago

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.

all2• 5 years ago

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.

georgyo4• 5 years ago

Pipewire is now the default for many distributions including Ubuntu, Archlinux, NixOS, and Fedora.

WhatIsDukkha4• 5 years ago

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.

vbezhenar• 5 years ago

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.

peakaboo• 5 years ago

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.

suby• 5 years ago

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.

phendrenad2• 5 years ago

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". :(

smoldesu8• 5 years ago

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.

BrightGlow15• 5 years ago

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.

smoldesu8• 5 years ago

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!

viraptor• 5 years ago

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.

TingPing3• 5 years ago

It's both... nobody wants to make 5 packages.

mongol2• 5 years ago

I have never heard of pet containers before. Have I been living under a rock or is this something new?

wmf2• 5 years ago

It's an obscure concept because most people either did away with pets when they adopted containers or they run pet workloads in VMs.

mongol2• 5 years ago

In this context it seems to be something else

infogulch• 5 years ago

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.

georgyo4• 5 years ago

This mostly sounds pretty scary.

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.

sprayk2• 5 years ago

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.

evil-olive• 5 years ago

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.

georgyo4• 5 years ago

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.

BrightGlow15• 5 years ago

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.

dystopiabreaker• 5 years ago

No normal users are ever going to edit a configuration file, complete with its own specific syntax, in order to install apps.

effie• 5 years ago

No normal users are going to use Linux or MacOS. They are going to use Windows.

hollerith5• 5 years ago

"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.

smoldesu8• 5 years ago

"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.

georgewsinger• 5 years ago

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.

Jasper_2• 5 years ago

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/

BrightGlow15• 5 years ago

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.

Jasper_2• 5 years ago

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.

curt153• 5 years ago

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.

azalemeth• 5 years ago

My experience has always been that pure Debian is far more stable than Ubuntu. I know it shouldn't be, but...it is.

jgb1984• 5 years ago

Uh yeah no thanks, I'll just stick with Debian. Served me well 20+ years so far!

WhatIsDukkha4• 5 years ago

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!

Klasiaster• 5 years ago

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.

devwastaken• 5 years ago

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.

TingPing3• 5 years ago

These are odd bugs and not my experience. They include thumbnailers they are licensed to do so for.

teddyfrozevelt• 5 years ago

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.

Fedora Workstation: Our Vision for Linux Desktop

Related Stories