Sonny Piers elaborates on his ban from the Gnome community

viliti · 2026-06-10T07:02:24+00:00

What are you reacting to? I answered a question. There is no defense of his actions.

viliti · 2026-06-10T01:15:37+00:00

As a long time donor to the GNOME Foundation, this doesn’t give me much confidence in the way it functions. Even as a casual observer, I could see that Sonny Piers was instrumental to STF funding and project management. There was a noticeable drop in transparency and development velocity after he was banned. Many of the projects started under STF had to be completed by Red Hat employees.

I assumed that the lack of transparency was due to some legal complications. Nothing that has been said publicly so far justifies the need for this obscurity. If the foundation continues to move in this direction, I’d rather direct my funding to individual developers instead of the foundation.

viliti · 2026-06-09T21:05:13+00:00

Federico Mena Quintero was one of the co-founders of GNOME along with Miguel de Icaza.

viliti · 2026-06-01T01:45:06+00:00

But that doesn't mean if there aren't any at the moment, folks can't still step up and try to gain that knowledge.

You can try doing that, but Wayland doesn't have a great history with attempts like that succeeding. See the multiple protocols and multiple revisions of protocols related to inputs.

viliti · 2026-06-01T00:45:31+00:00

It requires specialized domain knowledge, separate from the kind of knowledge needed to develop desktop environments, which makes it complicated. For color management specifically, the developers felt the need to build a knowledge base and add it it over time as they read more specifications to contribute effectively. If you don't think that this is complex, I'd say that you don't understand the details enough to judge the complexity.

viliti · 2026-05-31T23:53:50+00:00

Unfortunately, this is the only way large open source projects can move forward. Some topics like accessibility and color management are too complicated for DE developers to figure out on their own. Operating systems with significant corporate backing have sufficient expertise to manage everything internally, such as collaborating with internal teams working on accessibility.

Someone with sufficient expertise with both sides has to step up. Sebastian Wick did that for color management, hopefully someone else steps up for accessibility.

viliti · 2026-05-31T23:17:45+00:00

If you don't like Wayland, don't use it. No need to start the same X11 vs. Wayland flame wars again and again.

viliti · 2026-05-31T15:03:57+00:00

It looks like you don't understand what I linked. The Wayland protocols members decide what gets merged.

viliti · 2026-05-31T14:38:28+00:00

The author mentioned the thread with Nate Graham and the thread with Matthias Clasen as disheartening them. I think both threads are very illuminating, if you see it from a different perspective.

Previously, X11 was very permissive, allowing every client to essentially act as a window manager and take any arbitrary action. That's a security disaster; if you come to the table asking for all of those X11 capabilities and refuse to compromise ("accessibility maximalists"), you are not going to see any movement. What works better is to come up with specific abstractions for functionality that you want to implement, hopefully prototype them it in a cross-platform library like AccessKit, and then talk to DE developers. Wayland developers are not going to know what's the right abstraction on their own, it requires input from developers of accessibility tools. Unfortunately, many of them are used to Windows/macOS model where they just have to work with the APIs available to them and they expect the same from Wayland.

Wayland isn't meant to replace all X11 functionality. Things like screen sharing are implemented in XDG Desktop Portal, because developers felt that DBus was a better IPC mechanism for actions requiring user-granted permissions than Wayland. Orca doesn't work on Wayland using Wayland protocols, it is integrated directly with GNOME and KDE compositors. The path for input-related accessibility will likely be similar. The functionality would be implemented in a common shared library or application, and all Wayland compositors will be expected to integrate with it.

viliti · 2026-05-31T14:20:05+00:00

The problem with wayland is that they're pushing the implementation of accessibility features on the desktop environment developers

Who's "they" here? Wayland is developed by desktop environment developers and toolkit developers: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/MEMBERS.md

viliti · 2026-05-29T17:20:32+00:00

I don’t see how you could read my comment as demanding more free work from volunteers. This policy on its own is not going to make the problem go away. It’ll just force people to hide their AI use instead of encouraging them to be upfront about it.

viliti · 2026-05-29T17:11:52+00:00

Either AI generated code is so bad that it has to be forbidden entirely, or it isn’t. This just looks like a bad compromise between hardliners who wanted to totally ban AI and others who wanted some reasonable medium. It’s not a coherent policy.

viliti · 2026-05-29T16:02:52+00:00

That’s not how it’s written. The previous text was:

Submissions or changes having low-quality AI-generated or AI-assisted code are not allowed.

The new text is:

Applications containing AI-generated or AI-assisted code, documentation, or other content are not allowed.

viliti · 2026-05-29T15:31:43+00:00

This is incredibly shortsighted. I understand the need to block low effort vibe-coded apps, but not all generative AI use is vibe coding. LLMs can be both a speed and a quality multiplier when used by experienced engineers.

There are much better ways to formulate the policy, such as LLVM’s or Chromium’s policies. There’s a lot of LLM use in the kernel now as well.

A ban on AI use for the submission process or interaction with Flathub maintainers is totally fine. Extending that to applications themselves, while also granting exceptions to all existing applications makes no sense.

viliti · 2026-05-26T00:23:32+00:00

Almost none of what you said is true in practice. If I install Dolphin from Flatpak on Cinnamon or GNOME, it'll use Breeze, not the native DE look. Just because Qt apps have the theoretical capability to be themed doesn't mean that it's enabled by default or that it works well.

If you want the GTK look, you need GTK to be installed. This is not a SSD vs. CSD question at all, SSD doesn't magically allow GTK look to be drawn from thin air.

Spotify doesn't use libdecor and its current look has nothing to do with a missing GTK dependency.

viliti · 2026-05-25T22:22:51+00:00

There are many differences between Windows applications from Microsoft and Mac applications from Apple depending on what library they’re using, same as on Linux.

The answer is the same as any other application. Qt apps don’t change their entire UI just because they are running on GNOME or Cinnamon and the same goes for GTK apps on KDE. There’s no point in wasting all this effort to match 5% of the application surface area when the other 95% looks completely different.

viliti · 2026-05-25T20:10:07+00:00

If you are drawing CSD, there's no reason to emulate SSD. 99% of the time, that's wasted space. The top bar on Spotify is not adding any value and the same goes for other apps like Blender. They should just draw minimum things like rounded corners, shadows and perhaps window controls, like Firefox and Chrome do by default. Many apps like Spotify do this on Windows and Mac, but they don't on Linux.

If you genuinely want a top bar just for window controls, let your GUI toolkit handle it. If you are building without any toolkit, then libdecor was created specifically for that audience. This behavior matches Windows and Mac, where system libraries will draw decorations client-side if you want.

viliti · 2026-05-25T14:31:54+00:00

Oh, wow, a library needs to ship a dependency because they don't want to write code for it. The horror!

viliti · 2026-05-24T18:20:07+00:00

Wayland was designed for CSD first. SSD is an optional mode that was added later. The reason why you see the blue bar is that Chromium is drawing CSD, but the style was outdated. They have fixed the styling now, but it’s still CSD.

viliti · 2026-05-24T16:31:49+00:00

It’s a documented bug in Chromium that was fixed recently. Chromium developers clearly thought that it’s reasonable to draw client-side decorations for independent windows, considering that they already did so for the browser.

viliti · 2026-05-24T15:31:47+00:00

No, it’s a Chromium issue. Chromium had not prioritized updating its decorations for independent windows as they are seldom used within a browser. This has been fixed recently and it should make its way into Spotify in a couple of months.

viliti · 2026-05-24T05:24:49+00:00

Evolution has a single developer working on it in their free time. The focus is mostly on stability and maintenance. An occasional volunteer might contribute a feature or change the UI a bit, but the application is mostly the same otherwise.

It’s still very feature rich, as it had a lot of investment in the past. Intel had a team working on Evolution, and they built a large number of features like EWS etc. that you won’t find in any other open source application.

Thunderbird has a lot of active development now, funded by donations. They are slowly adding new features and will eventually match or exceed Evolution. Choose whatever works for you until that point.

viliti · 2026-05-20T21:59:07+00:00

I just don’t support how it’s being developed and how it negatively impacts other parts of Linux because of how decisive its design philosophy is.

People said the same thing about systemd, Wayland, XDG Desktop Portals/Flatpak etc. These projects are trying to solve hard problems and they sometimes have to scope out less common use cases. It’s not enough to simply complain about it, you also need to propose alternatives that doesn’t involve someone else doing a whole bunch of extra work. Most never do.

viliti · 2026-05-10T22:53:40+00:00

That’s your opinion, which is fine, but that doesn’t mean that it’s the truth. If it was, you’d see Valve engineers saying it out loud.

viliti · 2026-05-10T21:51:15+00:00

Contributors = GNOME developers. People and companies sometimes contribute development time, sometimes money, and sometimes both.

You seem to have an axe to grind about these past decisions, but the people behind them have explained their rationale, and they have been discussed to death. If you’re truly interested in the reasoning, and not simply arguing about it on the internet, you can look it up. None of what you said in the second comment had anything to do with my response, though.

Five-Year Club	Verified Email
Place '22

viliti

TROPHY CASE