GNOME Blogs

The sheer petulance of the Xorg developers is really quite stunning, not to mention the obsession they demonstrate with the politics of their enemies (the ones they make on political grounds). For example, here's Jordan Petridis:

https://mastodon.social/@alatiera/114661446785833161

Imagine proposing that people who fork an open source project, out of frustration that you don't maintain it, are thereby doing something wrong. Imagine publicly celebrating "killing" an open-source project that your(?) community somehow "owns".

Imaging going on at length about everything you can dig up about the politics of someone who has wronged you; now imagine feeling wronged because the other party exercised the rights granted under the MIT license. A reminder here that the definition of Open Source, as curated by the OSI, requires "The license must not discriminate against any person or group of persons." (https://opensource.org/osd). Not for any reason, including not liking their politics. Not even if you think they'll discriminate against someone else (I see no actual reason to believe this of Weigelt). As long as they follow the license you grant them.

And then there's this blog post about how X11 support is being dropped from GNOME:

https://blogs.gnome.org/alatiera/2025/06/08/the-x11-session-removal/

Try to imagine a right-winger signing off a blog post with something analogous, completely unrelated to the technical content of the post. I can't. (I'm not quoting it because a) I'm…

In my opinion, three basic things are needed:

- Device emulation: uinput covers this; requiring root is reasonable for what it does.

- Input injection. Like XTEST, but ideally with permissions and more event types (i.e. tablet and touch events.) libei is close but I think it should be a Wayland protocol.

- UI automation: Right now I think the closest you can get is with AT-SPI2, for apps that support it. This should also be a Wayland protocol.

None of these are actually easy if you want to make a good API. (XTEST is a convenient API, but not a particularly good one. Win32 has better input emulation and UI automation features IMO.)

Also the tangent about how crazy the compatibility layers are is weird. Yes, funny things are being done for the sake of compatibility. XWaylandVideoBridge is another example, but screen sharing is an area where Wayland is arguably better (despite what NVIDIA has to say) because you can get zero copy window and screen contents through PipeWire thanks to dmabufs.

Some of the lack of progress comes down to disagreements. libei mainly exists, by my best estimate, because the GNOME folks don't like putting things in Mutter, and don't want to figure out how to deal with moving things out of process while keeping them in protocol. (Nevermind the fact that this still has to go through Mutter eventually, since it is the guy sending the events anyways...) However, as far as I know, lack of progress on UI automation and accessibility entirely comes…

This opinion of "Gnome is killing customization" is something I see quite a lot, but which I think people take the wrong way. It's absolutely true that Gnome is designed to be less themeable than other DEs like KDE, or individual WMs - and by extension, GTK apps and apps designed to be used on Gnome are harder to customize/break more when you do theme them. But I disagree that "customization of Linux [being] half-dead" is a bad thing; on the contrary, I support the lack of theming options, and I like that there's someone on the Linux desktop that pushes this hard for consistency.

To make my biases clear: I'm a software developer that uses Gnome daily, and is developing a GTK/Adwaita app. I used to rice a lot back in the i3 days, but I don't particularly care about that nowadays, and stick to the defaults when I can. For my purposes, GNOME and Adwaita is perfect since it's very opinionated by default, and you can make good looking apps with minimal effort. Since all Adwaita apps are supposed to look similar and follow the same HIG, most of my desktop apps have the same look - but more importantly, the developers of the apps can also be confident that their apps look correct on my desktop. This is something that developers in the GTK space generally want, and for good reason[0].

One argument is that you as a user of the desktop should be able to have the final say on how your apps look, which is a totally valid take! And there are DEs, WMs, and apps which give you this…

The best treatment I've read that explains what seperates the Linux desktop from others is still here: https://blogs.gnome.org/tbernard/2019/12/04/there-is-no-linux-platform-1/

In a nutshell, and in my words, the Linux ecosystem consists of a loose collection of related, but fragmented, software, devices, documents and practices. This is fine, as long as you understand what you're dealing with.

Much longer version (I don't have a blog where I can post this):
Consumer devices are more than that though. They are finished, supported products engineered and designed for specific use cases or demographics of users. Consumer devices like these sound great for most people but for some people, it's not what they want. If a consumer device on the market doesn't meet the needs of their application, for example, they need to go elsewhere like commission a custom design or build it themselves. Again, you have to understand what your needs are and what offerings are out there.

You have to be honest about what you're looking at. I have a MacBook and an iPhone. I have certain expectations from these devices, in terms of features and limitations. And a lot of what I expect from these devices is inspired by where they come from: Do they come from a company? What type of company is it? What are the company's values and goals? What does the company think of me, the customer? From the answers to these types of questions I use the devices accordingly. You don't even need to get into the…

I have recommended SUSE Linux Enterprise Desktop in contexts where people have talked about supporting desktop openSUSE financially. I have also previously mentioned SUSE as an option in other forums.

As an engineer-centric Linux distribution vendor, they are also well-equipped to do engineering work upstream (and have an upstream-first mentality, which I appreciate). Red Hat and SUSE engineers often work hand-in-hand upstream in many communities, including desktop ones like GNOME and KDE.

They're a perfectly fine option if you want to go that way.

But in this context, we're talking about Red Hat's ability to invest in desktop Linux. And that is directly mapped to RHEL Workstation sales and (to a lesser extent) adoption of Fedora Linux (as a halo driving RHEL server/cloud and OpenShift adoption).

People also seriously underestimate how much work Red Hat puts into virtually every sphere of the Linux space[1], including the desktop. Many engineers spend a lot of time working in projects that don't directly pay off for RHEL because it either benefits the larger community or feeds into something they do care about in RHEL. It continues to surprise me how remarkably altruistic Red Hat is for a company. But that can only go so far. People still need to live and eat.

To give an idea of something that wouldn't have been possible without Red Hat: NVIDIA opening up their drivers last year[2][3]. Red Hat has been furiously working to rework Nouveau to take advantage of the…

A year ago, libav developers introduced a tool to translate a subset of C99 syntax in order to build libav with Visual Studio* . At the time Microsoft famously recommended that developers wanting modern C language features simply use C++ instead* . For a long time, up until earlier this year* , it was thought that C in MSVC had been permanently relegated to legacy support. Even for those of us who don't develop for Microsoft platforms, the attitude towards adoption of newer C standards has ostensibly had a negative impact. Which is why, even in lieu of full conformance, it's refreshing and a good sign to see this tool become unnecessary with the public release VS2013 today.

* http://blogs.gnome.org/rbultje/2012/09/27/microsoft-visual-studio-support-in-ffmpeg-and-libav

* http://www.infoq.com/news/2012/05/vs_c99_support

* http://msdn.microsoft.com/en-us/library/vstudio/hh409293.aspx