[HN Gopher] Fedora Workstation: Our Vision for Linux Desktop
___________________________________________________________________
Fedora Workstation: Our Vision for Linux Desktop
Author : lycopodiopsida
Score : 59 points
Date : 2021-09-25 19:44 UTC (3 hours ago)
(HTM) web link (blogs.gnome.org)
(TXT) w3m dump (blogs.gnome.org)
| Jasper_ wrote:
| 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/
| BrightGlow wrote:
| 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_ wrote:
| 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.
| BrightGlow wrote:
| 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.
| WhatIsDukkha wrote:
| 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.
| curt15 wrote:
| >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.
| vbezhenar wrote:
| 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 wrote:
| 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 wrote:
| 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.
| smoldesu wrote:
| 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.
| viraptor wrote:
| > 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.
| BrightGlow wrote:
| 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.
| rasengan wrote:
| We now have flatpak, appimage, snaps, among other things. It's
| yet another layer of confusion.
| input_sh wrote:
| 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.
| Klasiaster wrote:
| 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.
| mongol wrote:
| I have never heard of pet containers before. Have I been living
| under a rock or is this something new?
| wmf wrote:
| 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 wrote:
| In this context it seems to be something else
| jgb1984 wrote:
| Uh yeah no thanks, I'll just stick with Debian. Served me well
| 20+ years so far!
| georgyo wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| BrightGlow wrote:
| 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.
| hollerith wrote:
| "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 requires a massive learning
| investment. 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.
| dystopiabreaker wrote:
| No normal users are ever going to edit a configuration file,
| complete with its own specific syntax, in order to install
| apps.
| vondur wrote:
| 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 wrote:
| 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 wrote:
| >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 wrote:
| That's a very good sign!
|
| Do they mostly use Chrome (as opposed to something based on
| Chromium)?
| Barrin92 wrote:
| out of interest are Google employees still on their own
| version of Debian? I remember them switching from Ubuntu a
| while ago.
| codemac wrote:
| Yup
| pjmlp wrote:
| Yet at Google IO is almost only macs at the sessions.
| sprayk wrote:
| 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 wrote:
| 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.
| georgyo wrote:
| 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 wrote:
| 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 wrote:
| 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?
| BrightGlow wrote:
| If this is working correctly on other apps, then it's
| probable that Chrome's Wayland support is not complete yet.
| hollerith wrote:
| 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.
| [deleted]
| BrightGlow wrote:
| 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...
| SahAssar wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| hawski wrote:
| 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.
| WhatIsDukkha wrote:
| 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!
| all2 wrote:
| 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.
| WhatIsDukkha wrote:
| 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.
| georgyo wrote:
| Pipewire is now the default for many distributions including
| Ubuntu, Archlinux, NixOS, and Fedora.
___________________________________________________________________
(page generated 2021-09-25 23:01 UTC)