Xfwl4’s Second Preview Release

August 10, 2026
Brian Tarricone | Xfce

I’m pleased to announce the second preview release of xfwl4, Xfce’s Wayland compositor, version 4.21.1.

Thank you to all who provided feedback and filed issue reports on the first preview. I’ve fixed a lot of issues and added quite a few missing features.

Here are the essentials:

Source tarball. Build and install instructions are in the README. Please pay careful attention to build and runtime prerequisites.

Issue tracker. Search the issue tracker first in case someone else has already filed a similar issue. If not, and you file a new one, be sure to fill out every part of the issue template.

Git repository. If you’ve found an issue, it would be helpful if you could ensure it’s still present on git main. You can also try any fixes and features I’ve added since the release. Be sure to clone it with --recursive.

Again, please take a look at the README for runtime dependencies. xfwl4 will build and start without those runtime dependencies met, but some functionality may not work if you have older versions of some Xfce components and libraries. That list has been updated with newer versions since the first preview release.

You can check out the list of closed issues in this release. Note that there are more changes and fixes than are reflected there, as not everything I’ve done has an associated issue (and there are some issues filed and closed in other Xfce components that enabled some of this work). The NEWS file has the full list of commits and translation updates.

Anyhow, enjoy, and let me know how it goes.

LLMs and xfwl4

July 28, 2026
Brian Tarricone | Xfce

I was planning to write a little about my usage of LLMs while building xfwl4 as a small section of a larger blog post, but I decided I’d rather get it out of the way on its own.

While LLM usage can be polarizing in the context of open source, I don’t really see it that way. It’s a tool, like any other. It has good parts and bad parts. On the bad parts, there are three things that stick out for me:

Training Data and Copyright

Among other sources, LLMs were trained on publicly-available data, without the permission of any of the rightsholders of that data. That especially smarts since I have a lot of open source code out there, much of it licensed under the GPL. Is training an LLM on my code copyright infringement? If someone gets output from an LLM that looks substantially similar to my code, and they don’t know and don’t follow my license terms, is that copyright infringement?

And if it goes the other way, if output I get from an LLM looks very much like someone else’s code, did I infringe on their copyright?

I’m not sure! US law seems to suggest that training is fair game, as long as the entity doing the training has legal access to the data they’re training on. As for the rest of it, I’m not sure that’s legally settled yet.

On top of that, it sometimes feels icky that companies like OpenAI and Anthropic are making money off of all this when all that data out there – for which they mostly paid nothing – makes it possible.

I don’t, however, think the best response for myself is to just pretend none of it exists. It’s a tool, and a useful one.

LLMs need a lot of space, electricity, and water. Communities where data centers are being built, along with the associated power plant upgrades, are often getting stuck with some of the bill for those improvements, which is disgusting.

The secret deals between datacenter companies and utility companies, often with municipalities complicit, are often leaving regular ratepayers out to dry. That’s a local problem, and I hope those local people vote in representatives who will take better care of them.

Supply Chain

I don’t need to remind anyone how expensive GPUs and RAM are right now. I was planning to upgrade the mainboard in my laptop this year, which would require new RAM (my current board has DDR4 in it), but the cost of 64GiB of LPCAMM2 DDR5 makes my eyes water.

The consumer RAM market has been hollowed out; several companies have either stopped making consumer-grade RAM entirely, or have severely restricted supply in order to make more money selling to datacenters and AI labs. That’s capitalism at work for you, at the expense of regular folks who need to buy computing hardware for personal use.

But here I am, with a Claude Max 5x subscription for the past year and a half. I’m not comfortable with it, but the utility is just too great for me to take a principled stance here. I like it, and I want it, so I’m using it. Maybe that’s morally questionable, or worse. But, as I said: here I am.

xfwl4 and LLMs

So yes, I use Claude quite a bit while developing xfwl4. I don’t vibe-code, ever, and I probably use the LLM to generate less code than most people do. After all, building things with code is my hobby and passion (and I’m lucky I got to do it professionally for a quarter century), and driving an LLM is kinda boring.

Research and Planning

Most of my time with Claude Code is research and planning. One great match for LLM use here is helping me understand the finer details of xfwm4, since xfwl4 needs to duplicate all of its behavior. One common prompt of mine:

1
2
3

look at the xfwm4 source in detail and determine everything there is to
know about $FEATURE.  write up a plan for how to implement it in xfwl4
to notes/$FEATURE.md.

I go do something else for a while, and when it’s done, I read the doc, and then spend a while asking Claude questions about it, and telling it the things I don’t like and what I’d like to be done differently, and it updates the doc.

Implementation

Most of the time I’ll start working from the notes doc myself, writing the implementation by hand. My guidelines for plan-writing to Claude are to do things in phases, and so I’ll complete a phase at a time, and then ask Claude to validate what I’ve done. Often, while I’m working, I’ll decide to deviate from the plan, and I’ll have to tell Claude to do the validation based on the outcome I want, not based on adherence to the plan.

Once it’s done, I’ll use /code-review and let Claude spawn sub-agents to do a full review of the new code. This usually finds some problems, even problems that the “main” Claude instance didn’t find during its validation. I usually keep running /code-review again and again after finding and fixing issues, until there aren’t any left. I actually haven’t been doing /code-review for very long, maybe 6-8 weeks, as I didn’t know about it. I wish I’d done it from the start, as it’s very useful.

Sometimes I will have Claude write some code for me. Usually it’s when there’s a lot of boilerplate, or if there’s work that feels repetitive and tedious. Claude is generally a great fit for that, and I can both manually review the output and have a subagent do an independent review. I’ll usually keep CC in manual mode and approve every edit after reading it, but for some more mechanical changes, I’ll let it sit on auto for a while, and review when it’s done.

Occasionally I’ll have it write more substantial code for me, usually for bug fixes, and occasionally for small features. I find it does a pretty decent job here, but I keep it on manual mode and often ask it to write the code in a different way, or take a different approach.

Bug Fixing

Whenever there’s a bug, I’ll start looking into the code myself (I want to keep my debugging skills from atrophying), but in parallel I’ll also ask Claude to look into it, either by describing the problem, or pointing it to a Gitlab issue, if there is one.

I’ll admit that it’s rare for me to find the issue faster than Claude does, and there were some issues where I was completely lost, and Claude figured out something in 10 minutes that probably would have taken me days.

Tests

xfwl4 doesn’t have many unit tests, but I’d like to improve that at some point. Of the unit tests that do exist, they were al written by Claude. I’ve always found testing to be tedious, and never did a very good job of it. Claude’s tests are generally much more comprehensive than tests I’d write myself.

I’ve heard stories of people saying that Claude will change or delete failing tests instead of actually fixing the problem that makes the test fail, but that hasn’t (yet) happened to me.

xfwl4 also has a test-clients sub-crate that has a bunch of Wayland and X11 client apps for manual testing of various compositor features. I wrote the first Wayland test, using smithay-client-toolkit, but for the rest of them, I told Claude to write them for me, using my first test as a template.

My LLM Strategy

I don’t really have one. I just run the best model available for everything (Opus 5, at the time of this writing¹). I don’t write skills or other bits of automation. I expect some of that is indeed valuable, but I’m just not interested in it, so I don’t do it.

My usage isn’t high enough to ever hit my 5-hour or weekly limits on the Max 5x plan, so I just don’t worry about it. I started out with the Pro plan, but very quickly started hitting limits in the first 1-2 hours of the 5-hour windows, so I eventually upgraded after trying out extra usage for a bit and deciding I’d be spending more going down that route.

As I said above, I don’t vibe-code. I care about code quality and about understanding what I’ve built. I care about being able to maintain it in the future, manually, without needing an LLM to do everything for me.

And That’s It…

That’s it, I guess. I don’t think I would have made anywhere near as much progress with xfwl4 without an LLM. It’s easily saved me months of time, not in writing code (for non-trivial things, I can usually write it just as fast or faster), but in tracking down problems and helping me figure out solutions, whether that’s in Claude reading and reasoning about my code to find something that’s wrong, or in adding tons of targeted debugging prints to gather the information we need, and then sifting through the log file for me to do analysis.

I know this blog post is a tiny drop in an ocean of people writing about their LLM use, but I expect some folks might be curious about the development process behind xfwl4, so I figured a sort of disclosure was in order.

It’s been a little over a month since the first preview release of xfwl4, and I’ve fixed many issues and added new features since then. Hopefully I should have a new preview release in the next week or so, but you can clone the git repository to check out the current state of things for yourself, whenever you want.

Yes, I know Fable exists. I was hesitant to start using Fable as it felt like Anthropic could pull the rug out and require API pricing for it at any time. It seems now they might leave it available to Max plan users indefinitely, but the usage terms (only allowing 50% of usage to go toward it) make me feel like I’ll get limit anxiety. ↩

Xfwl4’s First Preview Release

June 21, 2026
Brian Tarricone | Xfce

I’m pleased to announce the first preview release of xfwl4, Xfce’s Wayland compositor.

After close to six months of work, I feel like it’s ready to get some wider use, even though of course there will be bugs and missing features. Think of this as an alpha release.

First off, I’d like to give a big thanks to the rest of the Xfce core team for offering to sponsor this work. I’ve been an on-again off-again Xfce developer since 2004 (more “off” than “on”, I suppose), and I consider it a great privilege to have this work sponsored, giving me the opportunity to focus solely on this project since the beginning of the year. This is also a huge thank-you to all the supporters who have generously donated to Xfce over the years.

Here are the essentials:

Source tarball. Build and install instructions are in the README. Please pay careful attention to build and runtime prerequisites.

Issue tracker. Search the issue tracker first in case someone else has already filed a similar issue. If not, and you file a new one, be sure to fill out every part of the issue template.

Git repository. If you’ve found an issue, it would be helpful if you could ensure it’s still present on git main. You can also try any fixes and features I’ve added since the release. Be sure to clone it with --recursive.

The end goal of xfwl4 is to behave as closely as possible to an Xfce desktop running on an X server. Ideally a user could switch between the two without even knowing there’s a difference. In reality, of course, it won’t be quite that seamless, and there’s still more work to be done to get as close as possible to that ideal. This is a first solid cut at it, at the very least.

The issue tracker will give you a decent idea of things that are not implemented yet or are known to be broken, but here is a list of notable things that won’t work, so you aren’t surprised:

The “Mouse and Touchpad” settings dialog (but whatever settings you’ve set under X11 will be applied under xfwl4) (issue).
The “Workspaces” settings dialog (issue).
Screen margins (issue).
xfdesktop’s minimized window icon view, and the middle-click window menu (issue and issue).
Pager thumbnails in the panel (no tracking issue yet).
Taskbar apps can only change maximize/minimize/fullscreen state (issue and issue).
Keyboard shortcuts for application/application-window switching (regular all-window cycling works fine) (issue).
Most (all?) apps will not be able to restore their window positions or workspace on startup (issue and issue).

(This is not an exhaustive list, just a few things I thought worth calling out.)

Over the coming weeks and months, I plan to write a blog series on how I built xfwl4. I’ll update this to link each new post here as they’re published. Anyhow, give it a spin!

Google TV and Native Libraries

October 5, 2012
Brian Tarricone

The Google TV runs a fairly unusual flavor of Android (at least the 2nd-gen ARM-based devices). I have a Sony Internet Player (not the Blu-Ray version), so what I’m about to write applies to that device, but maybe not any other, though it stands to reason that the other ARM-based GTVs are the same.

Phone-and-tablet Android doesn’t look much like a Linux desktop or server system. It uses the Linux kernel, to be sure, but a lot of the userspace libraries are custom. It even does not use Glibc, but a C library that Google wrote called Bionic. It’s fairly stripped down and lightweight, and while it implements most things you might need out of a standard libc, it does not pretend to be POSIX compliant.

Due to this, a Native Development Kit (NDK) is not yet available for the GTV. So the question remains: can we hack one together that works? The answer is… sorta.

From some simple investigation, I’ve learned that the Sony GTV is running a EGlibc 2.12.2, and probably a mostly-unmodified version of it. Someone with an @google.com email address stated that the reason for this was that they couldn’t get Chrome running against the Honeycomb version of Bionic.

With this knowledge in hand, I built a relatively standard arm-linux-gnueabi toolchain using crosstool-ng. Then I ‘adb pull’-ed the contents of /system/lib from my GTV and merged them with the new toolchain’s sysroot, copied some headers out of a stock NDK, and ended up with a sysroot that approximates what you’d find in platforms/ in a stock NDK, just without Bionic, and with EGlibc.

I didn’t get to modifying the NDK’s build system (it would need to be changed to find the new toolchain), so I built my native library manually, and got a simple “hello world” type app with a native lib. (It just calls a native method that returns a string, and displays the string on a label.)

One annoying thing is that the ABI string in the Sony GTV is set to “none”, so you have to unpack the APK, rename lib/armeabi-v7a/ to lib/none/, and repack and resign it. All of this means that this would be strictly hobbyist for now: no chance that you could distribute something in the Play Store. Not only does Google have to release an officially-working NDK, but they need to decide on an ABI string, and get Sony (etc.) to push updates out to their customers that update build.prop on the devices with the new ABI string.

There’s also the possibility that Google doesn’t want to create and officially support that much native drift between phone-and-tablet Android and GTV Android, and will wait until manufacturers are running a more-stock Android 4.x on GTV (that uses the 4.x version of Bionic) before releasing an NDK that works… in which case we’re at the mercy of Sony for updates, unless XDA or CyanogenMod wants to take a crack at it. My money’s on this scenario, unfortunately.

One of the main things people have been screaming for is a version of XBMC that runs on GTV. I have been able to get it to build using my hacked-together toolchain, but not actually to run. I ran into problems with runtime linking: the built binaries depend on a shared libstdc++ and libgcc_s, neither of which appear to be included on the GTV’s filesystem. I tried including them in the APK, but, weirdly, when the GTV unpacks the native libs from the APK at install time, it discards those two libraries. Static linking of those two may not be possible since XBMC’s APK includes a bunch of native libs. A possible solution would be to build all of libxbmc.so’s dependencies as static libs, and then just make one big static library.

But I haven’t had time to work on this over the past couple weeks…

Google TV and Native Libraries

October 5, 2012
Brian Tarricone