20 ms·

Fedora Workstation: Our Vision for Linux Desktop

vondur 5y 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.
hollerith 5y 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.
- curt15 5y 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.
  - hollerith 5y ago
    That's a very good sign! Do they mostly use Chrome (as opposed to something based on Chromium)?
  - Barrin92 5y ago
    out of interest are Google employees still on their own version of Debian? I remember them switching from Ubuntu a while ago.
    - codemac 5y ago
      Yup
  - pjmlp 5y ago
    Yet at Google IO is almost only macs at the sessions.
    - sprayk 5y ago
      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.
    - curt15 5y ago
      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.
    - smoldesu 5y ago
      I hate to be rude, but IO doesn't exactly bring to mind the most clever or dedicated programmers.
      - pjmlp 5y ago
        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.
- SahAssar 5y 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 5y 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?
    - SahAssar 5y ago
      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.
- georgyo 5y 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.
  - BrightGlow 5y 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.
  - hollerith 5y 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 5y 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 5y 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.
- georgyo 5y ago
  Pipewire is now the default for many distributions including Ubuntu, Archlinux, NixOS, and Fedora.
- WhatIsDukkha 5y 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 5y 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 5y 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 5y 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.
    - juangacovas 5y ago
      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-metal-server-backup-restore-migrate-linux-guide-sshfs-centos https://devblog.juangacovas.info/relax-and-recover-bare-meta...
    - scns 5y ago
smoldesu 5y 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.
- BrightGlow 5y 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.
  - smoldesu 5y 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!
rasengan 5y ago
We now have flatpak, appimage, snaps, among other things. It’s yet another layer of confusion.
- input_sh 5y ago
  I wouldn't put appimage on the same level as snap and flatpak. It's more like a random compiled .exe that you just run, it doesn't have an integrated update mechanism, you're supposed to download a new one with every update. And between snap and flatpak, flatpak sure seems like a winner. For one, other distros can run it their own store instead of Flathub, while snap is pretty much limited to Ubuntu and Snapcraft. Even Ubuntu's forks like Mint and elementary are ignoring snap and going all in on flatpak.
  - padraic7a 5y ago
    In terms of range of applications available though Snaps far outnumber Flatpaks. Probably because on terms of installs Ubuntu far out numbers every other Linux distro.
    - TingPing 5y ago
      Its because Canonical hired employees to do packaging and outreach, as well as supporting a wider range of application types (cli, server tools), and lastly having no QA so all packages make it in (barring basic automated checks).
mongol 5y ago
I have never heard of pet containers before. Have I been living under a rock or is this something new?
- wmf 5y 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.
  - mongol 5y ago
    In this context it seems to be something else
  - infogulch 5y 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.
    - wmf 5y ago
      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.
georgyo 5y 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.
- sprayk 5y 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 5y 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.
  - georgyo 5y 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/ 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/nixos/stable/ https://nixos.org/manual/nixpkgs/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.
Jasper_ 5y 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/packages.txt https://people.gnome.org/~walters/docs/ https://people.gnome.org/~walters/docs/
jgb1984 5y ago
Uh yeah no thanks, I'll just stick with Debian. Served me well 20+ years so far!
WhatIsDukkha 5y 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 5y 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 5y 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.
- TingPing 5y ago
  These are odd bugs and not my experience. They include thumbnailers they are licensed to do so for.
- teddyfrozevelt 5y 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.

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.

hollerith 5y 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.

curt15 5y 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.
- hollerith 5y ago
  That's a very good sign! Do they mostly use Chrome (as opposed to something based on Chromium)?
- Barrin92 5y ago
  out of interest are Google employees still on their own version of Debian? I remember them switching from Ubuntu a while ago.
  - codemac 5y ago
    Yup
- pjmlp 5y ago
  Yet at Google IO is almost only macs at the sessions.
  - sprayk 5y ago
    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.
  - curt15 5y ago
    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.
  - smoldesu 5y ago
    I hate to be rude, but IO doesn't exactly bring to mind the most clever or dedicated programmers.
    - pjmlp 5y ago
      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.
SahAssar 5y 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 5y 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?
  - SahAssar 5y ago
    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.
georgyo 5y 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.
- BrightGlow 5y 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.
- hollerith 5y 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 5y 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 5y 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.

georgyo 5y ago
Pipewire is now the default for many distributions including Ubuntu, Archlinux, NixOS, and Fedora.
WhatIsDukkha 5y 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 5y 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 5y 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 5y 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.
  - juangacovas 5y ago
    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-metal-server-backup-restore-migrate-linux-guide-sshfs-centos https://devblog.juangacovas.info/relax-and-recover-bare-meta...
  - scns 5y ago

smoldesu 5y 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.

BrightGlow 5y 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.
- smoldesu 5y 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!

rasengan 5y ago

We now have flatpak, appimage, snaps, among other things. It’s yet another layer of confusion.

input_sh 5y ago
I wouldn't put appimage on the same level as snap and flatpak. It's more like a random compiled .exe that you just run, it doesn't have an integrated update mechanism, you're supposed to download a new one with every update. And between snap and flatpak, flatpak sure seems like a winner. For one, other distros can run it their own store instead of Flathub, while snap is pretty much limited to Ubuntu and Snapcraft. Even Ubuntu's forks like Mint and elementary are ignoring snap and going all in on flatpak.
- padraic7a 5y ago
  In terms of range of applications available though Snaps far outnumber Flatpaks. Probably because on terms of installs Ubuntu far out numbers every other Linux distro.
  - TingPing 5y ago
    Its because Canonical hired employees to do packaging and outreach, as well as supporting a wider range of application types (cli, server tools), and lastly having no QA so all packages make it in (barring basic automated checks).

mongol 5y ago

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

wmf 5y 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.
- mongol 5y ago
  In this context it seems to be something else
- infogulch 5y 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.
  - wmf 5y ago
    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.

georgyo 5y 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.

sprayk 5y 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 5y 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.
- georgyo 5y 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/ 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/nixos/stable/ https://nixos.org/manual/nixpkgs/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.

Jasper_ 5y 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/packages.txt https://people.gnome.org/~walters/docs/ https://people.gnome.org/~walters/docs/

jgb1984 5y ago

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

WhatIsDukkha 5y 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 5y 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 5y 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.

TingPing 5y ago
These are odd bugs and not my experience. They include thumbnailers they are licensed to do so for.
teddyfrozevelt 5y 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.