Isn't XFCE doomed to have many of the issues inherited by GTK 3 and now 4? Do they fork things or just accept their fate? Even more so with Wayland in mind.
Yes there are a good amount of people who genuinely enjoy GNOME but what that GNOME is I don't really know. Ubuntu is heavily customized. Pop!_OS too and they are even going to release their own version of it, maybe like a fork I don't know the details. Fedora patches GNOME and their applications. When I see comments from their own developers more often than not they are using extensions, patches and tweaks outside the settings app. How many people would manage to tolerate actual vanilla GNOME I have no idea.
Their UX research is like Lucky Strike paying someone to find the health benefits of tobacco. They will ask the right questions. I remember two posts about UX testing, one a developer asked like a few random people they knew before making heavy changes. The second one looked promising from a scientific point of view and made me genuinely interested but a couple of paragraphs in and you could already see that it was full of shit.
Repo owners can do whatever they want because they can't afford to lose a single maintainer so leaders just quietly accept that and move on. Source: GNOMErs comments on reddit.
So lots of politics, not a lot of money to be made in the desktop, people are spread too thin. You don't have to deliver a good product when there's no big expectations or your job is on the line.
Is this comment too harsh? I don't know. Red Hat (right they don't own GNOME) is great and did/does so much for Linux/desktop, but many people like me who abandoned GNOME and GTK after v3 have to deal with their bullshit on a daily basis because they control a lot of unrelated stuff. So it's really hard not to be.
I've been using vanilla GNOME on debian and it's fine to me. But, I am personally not really picky when it comes to GUIs. From what I understand with Ubuntu and Pop!_OS, those distros are somewhat interested in creating their own branding, and don't seek to upstream everything that they do. I don't think there is anything that upstream can do about that, besides maybe make it easier for them to add more patches and tweaks. Some of the upstream developers I've talked to are not particularly happy that there are so many forks, but it all comes back to the manpower issue.
>have to deal with their bullshit on a daily basis because they control a lot of unrelated stuff.
Can you please elaborate what you mean here? If there are some bugs that are causing issues, you should consider reporting those.
Not interested in discussing merits and validity here but some bugs I have are US-age-of-consent-old. Some could be called features or are just UX changes or bad integration with WMs and KDE.
Well, outside my personal opinion that GTK applications became worse in UX and looks (by nature just by following their abstract HIG or peer pressure to be a "GNOME app"). The most common issue is the terrible filepicker (alien UX, no large thumbnails) that at least now you can use Portals when it's supported. Same could be said about other components like color chooser, modal dialogs, fonts that are barely readable even after KDE patches. Integration issues with Flatpak I only have with GTK applications like fonts and dbus. Some issues with Wayland, SDL, that I can't remember, maybe it was SSD, lack of window controls, abandoning system tray, I don't keep track of things that make my day worse now I just find an alternative until they come back to haunt me.
Bug fixes in GNOME are driven by volunteers, so if no one shows up to fix them after years, they are probably low priority and don't affect many people compared to the effort that it takes to fix them. Sorry, I don't know what else can be done about that, besides putting more strain on already strained open source maintainers. I don't know what you mean peer pressure to be a GNOME app. The file chooser and color chooser are unlikely to be changed unless somebody with a lot of UI/UX design experience volunteers to work on them, and makes them better in a way that benefits all GTK apps. The bugs with flatpak integration should probably be reported if they aren't already, the issue may be that some flatpak packages need to update their SDK version so they get a bug fixed version of GTK. Regarding your last sentence, issues in GNOME's wayland implementation won't affect users of other desktops.
Does that help? I don't think those are issues where you're being controlled into an unfixable situation, so I can try to help offer some solutions.
This discussion happens literally every week on reddit and other places. Same arguments and same conclusions from both "sides", not worth having it, nothing is gained.
>GNOME's wayland implementation won't affect users of other desktops.
Affects developers, and GTK itself when used. Or not if you don't think they are issues of course.
I agree, I've seen lots of open source projects get stuck and suffer from this issue where it's hard to get certain things done, it's hardly anything new, that's why I tend to focus on how to reach solutions to the problem. If you know someone who is capable of fixing these issues who needs some support, or if you have some technical insights here, let's talk about that. Otherwise, the issue is not one of being controlled -- the issue is actually because nobody has enough control to get the thing done. So let's see what we can do to give the right people a handle on the situation and empower them to do the right thing.
>Affects developers, and GTK itself when used.
I'm not sure what you mean, the developers of other wayland implementations don't have to worry about GNOME's implementation, unless they are aiming for feature parity. GTK can of course receive patches to support other implementations.
Nix and similar projects are all going to be eaten alive by immutable distributions, Flatpak and new projects - that might work just like Nix but get the user experience right, and make packaging and maintenance easier. And no I'm not saying they do the exact same thing, have all the same features or target the same type of users.
For the developer tools side I like what Shopify did but I would never recommend that to my employer. Too many moving parts and not enough people using it that I would feel safe about it.
As a new NixOS user currently set up with home manager and flakes - i'd probably switch in a heartbeat if someone gave me a nice nix-like package manager that also handled dotfiles.
As much as i love the feeling of NixOS, i really want something like a Lockfile as seen in Rust (and other languages).
Ie if i could define a `Cargo.toml`, which includes versions of packages or `*` if i don't care - and then it gets built into a `Cargo.lock`, i'd be in heaven. Combine that with a great language backing the distro and i'd switch immediately.
As it stands, I hate nixlang, and while flakes is amazing i still dislike the single primary input approach to NixOS _(ie all the packages bundled together)_.
As an example of why i dislike that, i'm stuck on an old version of NixOS currently because when i tried to update the repo date - lots of packages changed in difficult to manage ways. X was crazy slow, Firefox was being wonky, XFCE was janky, etc. All my flakes.lock told me was that the hash of the repo was different.. yay.. hundreds of dependencies were different i'm sure, but no clue which ones, and no easy way to isolate the problems and just incrementally update.
Luckily flakes allowed me to rollback perfectly. Well, i still had some userland state from the newer applications that i needed to nuke, but i'm ignoring that for now.
Being able to more easily incrementally update specific dependencies would be amazing for me. As it stands i have no clue when or how i'll update my NixOS input version. Which is not a promising sign for my continued usage of NixOS.
I don’t really understand your problem as in NixOS it is precisely the easiest to handle some packages from this repo and anothers from another. You can just add a single line of an alternative repo like altNixpkgs = “reference repo either by url or path” in the let in “block” and instead of pkgs.something just use altNixpkgs.pkgs.something.
Also, I usually manage my home packages separately from my global config. The easiest way to do that is probably by adding a different channel/path to your user’s nix-channels. I believe home-manager uses that. Alternatively you can also do the trick I mentioned in your home.nix file.
> I don’t really understand your problem as in NixOS it is precisely the easiest to handle some packages from this repo and anothers from another. You can just add a single line of an alternative repo like altNixpkgs = “reference repo either by url or path” in the let in “block” and instead of pkgs.something just use altNixpkgs.pkgs.something.
Yea, i actually do that for a couple of my dependencies. My problem is there are dozens or hundreds in my OS that instantly upgrade if i change my `nixpkgs` ref. And i have no clue what version _any_ of those are at, off hand.
Eg lets say i want to fix my X - because when i updated my `nixpkgs` pointer Xorg was using a lot of CPU for some reason. There's no lockfile that says what version X is at, or what dependencies X is using or associated with. Is it one package? Is it a half dozen? I could open the repo and dig through the configs to locate it and _try_ to infer what the hell version it's at, and what dependencies it has.. and then find what they're at and so forth - but it's convoluted imo. Much easier in Cargo.lock, for example - something i've done dozens of times before.
In short, basically everything in my OS broke when i updated my nixpkgs ref, and it's non-obvious and maybe non-trivial to understand what versions everything is at. To incrementally try to un-screw my system when i change my nixpkgs.
As i move forward, any packages i install i'm tempted to bind them to very specific inputs. So that when i want to upgrade one thing, only that one thing changes. But this workflow seems difficult in NixOS. Despite it being the workflow that i want.
Well, maybe not difficult - but lots of LOC. Adding dozens of inputs just to change versions of stuff without breaking other things seems like a lot of work for a dependency management system.. imo.
Thank, I get it now. Not a solution but perhaps try git bisecting the working and non-working version. It’s never a good thing to hunt down a bug but when one has to, the immutable nature of nixos actually makes it a very handy process.
Given that you already have flakeified everything, it's not that hard to pull in a different version of nixpkgs and cherry-pick packages from it. I have a (somewhat complex) setup utilizing this: https://github.com/casept/nixos-config
Yea, i actually do that now. My problem is the dozens of packages i didn't hand pick all broke. So basically i need to hand pick everything. And in doing so, it feels like a lot more work than simply specifying what versions i want during the package install.
I’m not too afraid of a niche being eaten alive by a slightly larger niche :D
Also, I don’t really see the value of flatpaks, they don’t solve the dependency hell problem (nix does) nor they are adequate sandboxes (be honest, linux has non-existent user-space security, it’s frankly terrible. And for some reason even flatpak is written in goddamn C in 2000+ something)
> For the developer tools side I like what Shopify did but I would never recommend that to my employer. Too many moving parts and not enough people using it that I would feel safe about it.
I'm not sure I understand you. In their case this became the standard dev environment. Everyone in the company is using it and the true benefit is that it makes development predictable. You only need one command to set up dev environment. He also mentioned that it is much faster than the old way.
I think they wanted to avoid having people build on it before they stabilize its interfaces, since they still had some big changes planned. As I understand it, the plan is supposedly still to publish it at some point.
I hope that if that's true, they publish it soon, because its design is very relevant to ongoing changes in the ecosystem, and it could be a useful reference point. :(
Pretty sure 99% of regular people would be happy if there was a desktop with GNOME 2 feature parity but with a good Wayland compositor and probably some modern features that would come from that (multimonitor, VRR, ...).
I just can't understand how anyone could defend GNOME 3. Their own staff have to use extensions (that break every update), even Fedora (!!!) has to patch GNOME packages now.
They kept fighting that their workflow is superior and now they are going to change it all over next release. They keep butchering their toolkit, I can only use Qt applications now. Hell I'll take even Electron over GTK.
For me the Linux desktop with a WM is the perfect balance of exposing the internals and UX. It could be better but that's true to every OS, at least here I have my freedom. I'm keeping my eye on KDE, seems like they rewrote their less than ideal compositor (legacy X11 is a burden) and maybe in a year I could be using that.
I've once heard someone say that GNOME is Microsoft's favorite DE. You can guess why.
Up until 2020, I didn't use screen sharing all that much, so the lack of support for that wasn't a big deal with using Wayland.
Now days though... this is a problem. I feel sorry for the folks running some Linux desktop that don't know why the option to start screen sharing just doesn't exist in various apps. I can imagine another Linux user saying "but it is right there!" to them, also not understanding why they have it but the person they're talking to does not have screen sharing.
To be fair, that's rather a problem of the applications not supporting Wayland. You can share within Xworld and Waylandworld, but not between them. I assume that's a non trivial problem and inherent to Wayland's design.
You can screenshare just fine through xdg-desktop-portal. It has nothing to do with whether the DE / compositor providing the implementation of xdp uses X or Wayland or something else, and it has nothing to do with whether the application doing the screenshare has an X window or a wayland window or any window at all.
I don't use a DE myself but I do package software that's meant to run on "normal" Linux distros and the lack of a desktop on modern Gnome is absolutely baffling. I make industrial software so these machines are really single-use so it makes sense to put shortcuts where they won't be missed by somebody who may not be super familiar with the Linux desktop (especially since said shortcut will often be used when something goes wrong and speed is of the essence).
I remember thinking "what on earth were they thinking" the first time I realized that none of the usual way of putting things on the desktop worked on modern Gnome. Absolutely baffling. Breaking such a well established convention is pure hubris in my book.
I'd be perfectly fine if this was a niche DE that you'd have to go out of your way to install but this is bloody Gnome, the de-facto standard DE for Linux. Absolute insanity.
I've been running Cinnamon on a few machines for years, and it mostly works fine, which for a Linux desktop is high praise. The file picker has thumbnails (although it only has a list view, so they're ant-size).
I haven't used MATE. My understanding is that MATE started life as Gnome 2, whereas Cinnamon started life as Gnome 3 reskinned to look like Gnome 2. Both have grown considerably from their starting points.
My desktop user experience with Mint Cinnamon was as close to delightful as I've ever had on Linux. All the GUI stuff worked without me having to fiddle around in the terminal like a "hacker", the UX was generally high-quality, and the default theming was pretty and consistent.
My overall impression was that it was definitely and surprisingly usable for non-technical people like my mom, grandma, etc. who don't use their computer for anything sophisticated but also don't have the time/energy/wherewithal to debug and configure things.
I can't speak highly enough about the Mint Cinnamon experience, and I recommend that everyone involved in the "Desktop Linux" world try it (at least in a VM) so they can get a sense of what "good defaults" actually look and feel like.
> All the GUI stuff worked without me having to fiddle around in the terminal like a "hacker"
This was also my experience.
The only customisation i've done is:
1. Moving the panel, depending on what my feelings about proper panel placement are at the time.
2. Removing all the default shortcuts, because they collide with IntelliJ and/or are useless, and defining a few of my own
3. Setting up custom compose key sequences
Removing the shortcuts was done in the UI, but i really wish i could do it in a config file instead, because it's a pain to spend ten minutes clicking around. I had to hit the command line to set up compose keys, although i think this is an X problem, not a Cinnamon problem.
Maybe I have reading comprehension problems but this article sounds so conflicting and presumptuous. Is it a sales pitch or not? If it is, even when it says it isn't, I would start by looking at Arcan's bus factor, and what refactoring and architectural changes were necessary along the years.
Having no expertise in this field I have no patience for people who write in this style but never got involved in the process. But if they did then I would be more interested in reading why their proposal was better and what can be done now in the living code. Also IIUC protocols are exactly that, places to experiment and learn from mistakes until they get stable and anyone can propose them.
There are many developers who could write a good technical solution but it's the ones who can deal with the ugly politics that make a real difference. There's a phrase about that there but as always if you don't send code your opinion won't do any good.
I was feeling the same! I came away from this article even more confused as to what's been going on.
I used to be a maintainer on Xfce (though it's been a decade since I was active), and I've been worried (as a user) about the "upgrade path". Porting (if you can call it that) from X11 desktop environment to Wayland compositor (etc.) is a huge step to take, it seems, and Xfce's current core team doesn't seem interested in going in that direction (I don't blame them).
As a user, I want to just keep using Xfce until the heat death of the universe. As someone who might get involved in Xfce development again, I worry that any work I'd be doing on the X11-based things might be wasted time in the long run.
I wouldn't do that. Only move to Wayland when there is a real path for what you want and need. And it does it without hacks.
About porting I would look at what MATE is doing or at the code of Wayland shells, protocols or things like Waybar at GitHub. You don't have to write an entire compositor if you don't want to. Even better get in touch with the people who know what they are talking about, I think they have a wayland IRC channel.
There are a lot of unmaintained WMs that work well and are amusing for historical value or retro computing, and probably some of them have a small number of real world users too. I like the idea of a compatibilty layer for those.
Maybe not for a big project with ongoing development. But as a last resort to run some cool stuff.
It seems it would be difficult to do that without combining both protocols into one server. (This is not quite what xwayland, xweston, xwlnest do. They run the server X out of process and can't manage wayland windows because they don't know anything about the internal wayland state)
To that point, you would have to decide if it's more worth it to fork xwayland and merge with an existing wayland compositor, or to fork xfree86 and add wayland.
I bet you could achieve it with three layers. First, run a "top level" Wayland compositor. Then, use XWayland to run an X session (with your favorite window manager). Then, use Weston's X client mode to run Wayland applications inside the X session.
As silly as that sounds, it might actually be a good solution. Red Hat gets to push their shiny new display server protocol, and I still get to make screen recordings and use my favorite window manager. I wonder how well it works in practice...
That would sort of work too, but it comes with its own set of issues. Keep in mind that there is very little reason you would actually want to do it that way when either way you're dealing with the same impedance mismatch. In other words, you will have to solve the same issues in the display server you're running into now with screen recordings and strange window manager behavior. It's not something that you'll just get for free. If it was, the other Wayland implementations would have it fixed by now. There's no magic solutions to this without any brokenness or workarounds—the crux of the problem is that you have two protocols you're trying to match up that are compatible in some ways and incompatible in others.
Also I think it's a stretch to say the push behind Wayland is coming from Red Hat. Maybe within GNOME, but there are other implementations with no connection to Red Hat.
I don't think the impedance mismatch is the same either way. The Wayland protocol is much more restrictive than X's -- things like screen capture and window managers don't work because the APIs they need aren't present. Conversely, there are X APIs for everything a Wayland application is able to do, so a Wayland-app-in-X shim would probably work a lot better.
The outermost layer, where you run the X session inside a Wayland compositor, would probably work alright too because it just needs to send pixels to the screen and accept mouse/keyboard input. Wayland is able to do both of those things!
>Wayland protocol is much more restrictive than X's -- things like screen capture and window managers don't work because the APIs they need aren't present
This is not quite true. There are protocols for these things in some implementations. You'd want to keep compatibility with these because otherwise you'd have no reason to be supporting Wayland. Keep in mind either way you're talking about using a specific compositor—it doesn't matter if the APIs aren't present in the protocol. In this situation you'd re-use one from another implementation or add another private protocol extension. That's always been what individual compositors are encouraged to do. It's no different here.
> This is not quite true. There are protocols for these things but they live in multiple places.
Every Wayland window-manager-compositor-hybrid invents their own protocols for these things. This basically means that you can't write a program that does these things -- you need three different versions of every API call you make, and that's just to support the popular desktop environments that people happen to be using this week. So no one has, so the only Wayland protocol features you need to support are the basic ones to open a window, draw into it, and get mouse and keyboard input.
> Keep in mind either way you're talking about using a custom compositor
No, I suspect the "top-level compositor" could be any off-the-shelf Wayland compositor that supports XWayland and can make a window full-screen.
Here is the thing: it's trivial to map those basic features back to X. That's already mostly been done. If you continue with that solution you'll have the same problem in reverse—assuming X support ever gets removed from the toolkits, then in that situation you'll get Wayland apps that depend on some Wayland functionality that doesn't work. See what I mean?
(IMO we're pretty far off from X support being removed if it ever even happens, so I wouldn't worry too much about that right now)
And I actually don't think it's a big deal that there are separate implementations. You can absolutely still write programs that do these things, and people do. Usually you start with targeting just one implementation and then you port it to the others. All you need is an API to abstract the custom protocols. A lot of those differences are already abstracted in the portals API which has those three separate implementations so you may not even need to do any porting if that fits. Worst case, if something isn't in the portals API then you have some three clause switch statements when you make protocol requests. Then after you stabilize it, move those switch statements into a library and then other people can use it as an abstraction layer, and nobody needs to write the switch statements again. Yeah it's work, but for an app developer it's actually easier to do that than getting all the upstreams to standardize everything.
Here's the thing about Xwayland: Xwayland is Xorg. If you look in the xorg code base, you will find that it's separated into components called DDX and DIX. DIX (Device-Independent X) handles protocol and server state; DDX (Device-Dependent X) does the drawing. One of the back ends in the DDX code is for Wayland; when you compile Xorg with just this back end, you get Xwayland.
So if Xorg gets abandoned -- oops! There goes Xwayland as well. I do believe that this was the plan all along: keep Xwayland around as a solution for "legacy applications" for a while, then stop supporting X altogether to make it less attractive as a back end for new applications and toolkits.
Yes, I am familiar with the Xorg code base :) The point I was getting at is that if you want to keep using an old protocol far into the future, someone from the community has to step up and maintain something. That's true of any old technology faced with waning influence over time.
It is a compromise for how Xorg and Wayland can have a shared graphics backend that improves both sides and the part that the Xorg maintainer wants gone can go away.
Arcan has had its own fork of Xorg for many years, as well as a Wayland implementation. Nothing here will change that trajectory.
The library mentioned is about ~2kloc, decoupled from the rest of the project (100+kloc) and the relevant subset has not changed significantly for several years.
It came a long way, it's very impressive what they managed to do in a short period of time. Not only Valve but the community in general even if they weren't directly involved with the gaming part.
Manage your expectations, I would treat it like a console, you won't be able to play 100% of "PC" games but you will have a very large selection of games including AAA. And in comparison by raw numbers Linux have many more games than regular consoles, not to mention all the emulators you can use.
Performance wise Source engine games run better than on Windows for me and a few Proton (Wine) games runs better too, but that's not the rule as there is a small penalty from the "translation" layers. Vulkan games run very well.
If you try to run all games even the ones that Valve didn't approved to run with Proton ("1-click in the UI and it just works") you will have to tinker and do nerd stuff like using different versions or compiling from source. Don't blame the platform if you go that route without proper knowledge and patience. Also in the same line of thinking don't try to use Wayland yet, specially if you have a NVIDIA card because there's no support from them, and I hope they do something about that but I wouldn't hold my breath.
>Wayland won't be production ready in a long time.
With NVIDIA it will never be production ready because NVIDIA doesn't support the Linux standards for Wayland and they don't allow developers to write/use good open drivers and all functionality. Even with X11 and their closed drivers it's a bad experience with glitches in the desktop, but at least the games run.
NVIDIA closed source drivers are supported by at least KWin, and IIRC GNOME, on Wayland. Furthermore they are working with the wlroots/sway maintainer to develop a new way for compositors and graphics card drivers to communicate effectively.
I was talking about XWayland and the other problems Wayland devs have mentioned like Pipewire, poor performance, current and future issues FLOSS developers can't fix on their own without being able to patch and only NVIDIA can fix them. A big waste of time for that extra path (even if initially sent by them) that I wish they didn't had to maintain and triage bugs.
The experience with glitches and problems that the user above just describe to you and I see every day on social media. And the blame went to Wayland. I don't claim to know how it works deep down I can only comment about the smell and it's not pleasant.
They promised many things years ago and we are still in the same situation. I will be the first to congratulate NVIDIA if they fix this issue and change their practices. I'm sure they have legit grievances with Linux developers but their behavior is awful if you're a user or want the desktop to succeed.
Canonical announced Mir out of nowhere in an attempt to gain control just like they are trying now with Snap. After the announcement of Mir their developers went to IRC and made abundantly clear they had no idea how Wayland works and that Mir was useless. Where is Mir now? Using Wayland.
People who were in the fence about supporting Wayland were now even more convinced they should ignore it. That's one of the reasons a decade later you still have this much FUD.
Nice ignore the part where they realized Mir was useless. They even went on an edit spree in their wiki page.
If Mir was so good and superior they would just keep developing it. Isn't that obvious? If the company who already spent all this dev time aka money on Mir doesn't believe in it, why would anybody else? They were even eating their own dog food and had some major industry pull at their disposal. The answer is they fucked it up.
> If Mir was so good and superior they would just keep developing it. Isn't that obvious? If the company who already spent all this dev time aka money on Mir doesn't believe in it, why would anybody else?
Not that I care or know a lot about Mir, but do you seriously believe that it was always the best technology that became successful and triumphed over its competitors?
> Nice ignore the part where they realized Mir was useless.
> If Mir was so good and superior they would just keep developing it. Isn't that obvious?
No, that's an arbitrary conclusion you've made. There are multiple reasons why a project might be killed, even if it's a good one. Canonical killed Ubuntu Touch but now it's gaining traction again because we have things like the Librem5 and PinePhone. Premature if you ask me but it makes sense as a business decision.
If we look across industry, would you say killing Google Reader was because it was inferior to others? I wouldn't.
A good lesson for the anti-FLOSS crowd so heavily present in this website.
I'll be the first to admit Linux desktops are full of flaws (although there are other options), just like every other OS but they could be fixed given enough money or maybe you could be the one that write that code.
But an OS that is not FLOSS will always work against their users and restrict their freedom. It's also a big joke that they have so many ads talking about privacy, when they are just as bad as their rivals. I do understand that not everyone has a choice because specialized software that they need for professional use could be available only in other platforms and that's unfortunately.
I don't expect an utopic world where everything is FLOSS but the OS is too important to be closed. It will only get worse with time.
