After a year (a bit more actually!), I’ve decided to give a chance again to this 20 years old new-kid-on-the-block¹ that is Wayland on my Plasma desktop, and give my previous entry on this topic a follow-up.

The good surprise

Actually, a lot happened during 2025! Some issues and shortcomings I had previously documented have been fixed:

• Firefox (since release 146) now natively supports fractional scaling, including sharp text rendering, save for the occasional right-click popup menu which sometimes still is a bit blurry.
• Qt 6.11 (newly released) finally fixes the abysmal scrolling performance issues in LibreOffice which had made it previously unusable on 4K displays.

In general, Plasma now feels pretty snappy when ran on Wayland on my discrete nvidia GPU (and even snappier than on X11 !) while it was stuttering a lot before.

It is (still) not all rosy

There is however still a major regression I experience on Wayland, which is admitedly caused by those deliciously crappy proprietary NVIDIA drivers: VRAM management is AWOL.

This particular issue is being discussed since 2023 (!!) on NVIDIA forums (here for instance) and is tracked by instance through this egl-wayland issue.

What does it mean in practice? Whenever an application requests some GPU buffers, as long as there is still dedicated VRAM available, everything runs fine. But when VRAM becomes full, any such request will fail, meaning any application can randomly crash. This is not how thinkg are supposed to work! Whenever there is some VRAM pressure going on, the driver is supposed to move buffers to host RAM instead to make room for the new request. This degrades performances for sure, but it’s still a vastly better alternative to crashing an entire desktop session … and this is exactly how it is working on frigging X11 … or cough cough Windows for that matter.

Now, you’re going to tell me, this must surely be a corner case occurence. Who in his right mind fills up its VRAM in such a way? Probably some daft gamer dual screening some browsers and video players (hmm …). But there is a totally legit way to trigger it! I’m a big fan of running LLM inference locally, for privacy and ethical concerns, and the rule of the game is to maximize GPU usage to get acceptable performances. And oh boy how many times have I crashed my desktop by being a bit too eager when loading up some models too large for my own good …

Conclusion (for now?)

This nvidia issue is certainly super annoying (I guess my next GPU will be from team red …). But I must admit the whole Wayland situation is actually getting better by the day, and I was a bit too pessimistic previously; I have been running a Plasma Wayland session for a few weeks now, and overall have been pretty happy about it.

I’m a nobody having an uneducated opinion on matters exceeding by far the reach of my comprehension skills. Because we’re on the Internet (c), I’m therefore more than fully qualified to express it!

So what’s happening?

The Mozilla Corporation has just hired a new CEO who immediately expressed his vision for a bold and bright future where Firefox development effort will be refocused on building a AI platform supporting an ecosystem of AI products.

Of course, Firefox marketshare has dwindled in recent years, and its remaining users are a militant group of free software afficionados, privacy activists, and worse of all, Linux users. Let’s just say this “new direction” is not warmly received. And it’s also quite uninnovative and lazy: that’s just what everyone and their dog are doing. How to gain back marketshare be being an also ran? And why the hell does marketshare matter so much?

Even believing that Generative AI is indeed unavoidable (or let’s be crazy: that it can be a useful new tool when implemented responsibly), and if privacy and trust were indeed core values of Mozilla Corporation, then they should clearly take that direction in their engineering: research and build small models that can be run on-device, integrate them into local agents executing inside the browser sandbox to perform specialized tasks in an efficient manner, and all in a private way by construction. But of course, that’s not what is announced. Instead we are served a mumbo-jumbo of corporate speak about trust and choice.

It’s about Google (of course)

Fundamentally, there is a strong disconnect between Mozilla Corporation users and customers (the ones actually paying the bills), or should I say customer (singular): Google.

85% of Mozilla Corporation revenue comes from their Google Search partnership, which for Google acts as an insurance against antitrust procedures. Eventually, by ballbootlicking enough the current US administration, this threat for Google will definitely go away, and Mozilla Corporation will soon lose their sole income source. So they must do something to ensure their survival.

It’s also the explanation behind all past failed attempts at deversifying revenues: Firefox OS or Pocket to name a few. And they all failed because of a fundamental misalignment of the interests of users and customers (which are the OEM integrating Firefox OS in their TV or their phones). The Google Search deal is the exception, because everyone needs a search engine, and Google is the obvious/default choice.

So the plan is simple in the current AI-fueled economy, replace Google Search revenue with ChatGPT/Perplexity/Gemini revenue, by giving them a direct access to the data they crave and can’t access today with their crawling bots: everything that happens behind a login box. Local model execution is out of the picture.

And of course, this plan is bound to fail for the same fundamental reason.

OK, what to do now?

The Fediverse is now chokeful of strongly worded vows to uninstall Firefox immediately and burn any device having remotely touched some Mozilla software at the stake, along with passionate calls to switch to LibreWolf, Waterfox, Seamonkey, Zen or Floorp (and I’m probably forgotting a dozen more).

Except that even with the best intentions of the world, those light Firefox forks only add a couple of privacy-related patches on top of upstream Firefox, and most of the time by removing code. There are no organizations behind with sufficient funding and manpower to do the heavy-lifting: the actual maintenance (let alone evolution) of such a complex piece of software as a browser engine. If the Mozilla Corporation folds, all those forks immediately become useless. So long for “punishing” them … and don’t get me started with Vivaldi or any other Chromium/Blink based browsers.

There is also a belief that browsers are a solved problem and maintaining Firefox should be cheap and can be done in best-effort mode by a self-organizing volunteer community. Threat actors and vulnerability classes are constantly evolving. Client devices/platforms as well, and it’s already hard today to keep up with current level of funding: Firefox has only got actually working fractional scaling on Wayland in 146 release which took literally years of bug fixing efforts to get there, and it’s still based on GTK3. And because Google (with Blink) completely controls web standard evolutions, staying relevant means spending precious resources to follow their shenanigans without any way to actually influence them.

I remember reading somewhere that a ballpark cost estimate of Firefox software development is around 100M$ / year, so the real question is: how to (collectively) foot that bill? Through donations to the Mozilla Foundation? A transfer of Firefox to the Linux Foundation or Apache?

Update 18/12/2025: It appears donations to Mozilla Foundation never get invested into funding Firefox development, but nowadays seems centered around building voice & text datasets to train LLM (but no open source locally executable models though?), community building, and lobbying. I stand corrected, thank you @bohwaz@mamot.fr!

Right after deciding to act on my new year’s resolution to start a blog, my first primal reaction was to google how to deploy and run a containerized Wordpress. Yikes. Recalling Matt Mullenweg’s unsavory meltdown and ensuing drama thankfully made me pause for a second …

Did I really need to run hundred of MB of PHP scripts to render a couple of pages everytime some AI bot would crawl this blog? Did I really need the dozens of fancy plugins to perform SEO, track visitors, inject ads and generate affiliate links?

Here is what actually matters to me:

• Markdown files in a git repo as source of truth. I’m a developer.
• Efficient usage of resources. In this day and age, this should be on everyone’s mind.
• No possibility for tracking or identifying visitors. Yes, privacy is a feature.
• Simplicity: easy to secure and maintain, both for content generation and publication.

The solution was writing itself: nothing can beat nginx running on bare metal and serving a bunch of static html files.

Picking the right tools for the job

There are plenty of markdown-based static site generators, such as Jekyll or Eleventy. I wanted something simple and low-maintenance, so I settled on Hugo, because it’s a single static binary written in Go, and I didn’t want to bother with npm or virtualenv. A strong community has formed around it, and a bunch of cool themes are available.

The markdown sources for this blog (as well as few hugo configuration files) are stored in a single git repo. I use Zed as a text editor because it’s the new kid on the block, with two tasks configured for testing (hugo server -D) and publishing (hugo && rsync).

Integrating with the Fediverse (or how to not reinvent the wheel)

But not everything can be static on a blog, right? What about user-submitted content such as comments?

I first got the idea to leverage the Fediverse from @jwildeboer@social.wildeboer.net’s blog, which happend to also be fully static. The idea immediately clicked: no need to reinvent the wheel, a decentralized way to engage with anyone exists, and I’m even already running my own personal Mastodon instance!

Because I’m lazy, I’ve simply ripped off an existing Hugo implementation straight from this article. I just have to manually create a toot for each article, and link back its id. All the magic happens client-side thanks to a small JavaScript snippet.

Is this really only about technical efficiency and security?

While I was initially driven by purely technical considerations, reading about the small web resonated with me. Technology is not (always?) neutral, it can be biased and shaped by the interests of large actors. Maybe my futile quest for simplicity, privacy and efficiency is really about taking back control?

In any case, the small web is beautiful.

Like lots of my basement-dwelling geek comrades, I have a home-made NAS hooked to my LAN. I’m a man of simple tastes, easily satisfied with:

• SMB/NFS/rsync
• Jellyfin, including some transcoding for ‘difficult’ files
• Various containers, such as the Unifi Network Application controller for my wireless AP

I had an old rig based on a venerable Xeon E5472 and a 2007-ish Gigabyte motherboard (with its amazing PCI slots !), which while suprisingly still very functional, was not terribly energy efficient at 100W+ power draw. Unfortunately, the proverbial writing was on the wall, as EL9 (and therefore its derivatives Rocky Linux and Alma Linux) dropped support for everything earlier than x86-64-v2 architecture, and my goold old Xeon chap didn’t make the cut …

Time for replacement it is then!

The Hardware

I don’t want to use OTS offerings from Synology/QNAP/Asustor et al., as I prefer to fully control the software running on my NAS. In particular, I despise the planned obsolescence tactics permeating the industry.

I therefore set out on a journey to find the perfect motherboard, and established the characteristics I was looking for:

• Something standard-ish, x86 or ARM-based
• Fast enough to support transcoding with Jellyfin, special bonus point if hardware acceleration is available
• Low power draw
• Loads of SATA ports, plus M.2 NVME for the boot disk
• Compact format ie. mini-ITX (so that I could install it in a small case in the future, even if for now I will reuse an old ATX tower I’ve already got)

Alas, the journey quickly met a dead-end. It turned out there were no options available on the local online retailers available in my region, nor on Amazon, for mobos meeting those criteria. However, there are some interesting ones on AliExpress based on low-power N100/N305 Alder Lake CPU, with a (respective) TDP of 6W/15W!

While there are a multitude of sellers over there, most products come from a couple OEM, notably:

• BKHD 1264 NAS MB, only available with N100
• CWWK CW-NAS-ADLN-KV10, available with a full lineup of N100/N150/N305/N355 CPU and a fancy purple PCB. It is also sometimes listed under the Topton brand, but my understanding is that they’re only reselling (see below for hardware characteristics)

I first ordered the BKHD as it was generally cheaper. Unfortunately, I experienced spurious reboots with it, and while mobos like that are known to be quite finicky with RAM and I expected it, I couldn’t find a single SODIMM able to succeed at even a single memtest86+ pass. So I definitely do not recommend that one.

I then bought the CWWK (more precisely its N305 variant), and paired with a Crucial 16GB DDR5 SODIMM it works beautifully.

Edit 05/02/2025

Here is a picture of the motherboard assembled in my cheapo mid-size tower in its full glory:

The only actual difficulty I encountered is that the ATX 12V connector sits uncomfortably close to the CPU heatsink. By chance, after trimming a bit the connector (who needs all this extra insulating plastic anyway??) it fits exactly between two heat pipe tips … so don’t be me, chose carefully your cooler and don’t go with the default one offered by most AliExpress sellers 😄

Nerd alert

First, the OEM indeed appears to be CWWK (and not Topton):

# dmidecode -s baseboard-manufacturer
CWWK

So what actually is this N305 CPU?

# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 190
model name      : Intel(R) Core(TM) i3-N305
stepping        : 0
microcode       : 0x1a
cpu MHz         : 800.000
cache size      : 6144 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 8
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 32
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l2 cdp_l2 ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdt_a rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d arch_capabilities
vmx flags       : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs ept_violation_ve ept_mode_based_exec tsc_scaling usr_wait_pause
bugs            : spectre_v1 spectre_v2 spec_store_bypass swapgs rfds bhi
bogomips        : 3609.60
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:
# ... repeat 7 more times ...

So it’s a honest-to-god 8 cores CPU (no HT shenanigans there), with 6MB of cache (still twice less than my 2007-era Xeon 😞). It supports AVX2, AES, and VT-x. And of course it features all the sexy Intel security bugs such as spectre 😁

What does lspci show then?

# lspci
00:00.0 Host bridge: Intel Corporation Device 4617
00:02.0 VGA compatible controller: Intel Corporation Alder Lake-N [UHD Graphics]
00:0d.0 USB controller: Intel Corporation Alder Lake-N Thunderbolt 4 USB Controller
00:14.0 USB controller: Intel Corporation Alder Lake-N PCH USB 3.2 xHCI Host Controller
00:14.2 RAM memory: Intel Corporation Alder Lake-N PCH Shared SRAM
00:16.0 Communication controller: Intel Corporation Alder Lake-N PCH HECI Controller
00:1c.0 PCI bridge: Intel Corporation Device 54b9
00:1c.2 PCI bridge: Intel Corporation Device 54ba
00:1c.3 PCI bridge: Intel Corporation Device 54bb
00:1c.6 PCI bridge: Intel Corporation Device 54be
00:1f.0 ISA bridge: Intel Corporation Alder Lake-N PCH eSPI Controller
00:1f.3 Audio device: Intel Corporation Alder Lake-N PCH High Definition Audio Controller
00:1f.4 SMBus: Intel Corporation Alder Lake-N SMBus
00:1f.5 Serial bus controller: Intel Corporation Alder Lake-N SPI (flash) Controller
01:00.0 Non-Volatile memory controller: MAXIO Technology (Hangzhou) Ltd. NVMe SSD Controller MAP1202 (DRAM-less) (rev 01)
02:00.0 SATA controller: ASMedia Technology Inc. ASM1166 Serial ATA Controller (rev 02)
03:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
04:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)

The 6 SATA ports are provided by an ASM1166 controller. Contrarily to other terrible options, at least it doesn’t prevent the CPU to reach deeper C-states. In a nutshell, it’s not great, but not terrible.

It also has a PCIe 3.0 x4 port, as well as 2 M.2 NVME slots, for a total TDP of ~25W under full load.

The Software

I slapped an Alma Linux 9 install on that bad boy. Installation process is as uneventful as possible. Everything works out of the box!

Edit 25/02/2025: After a tiny bit of configuration, consisting mainly in installing intel-media-driver (the N305 works with the iHD driver, not the older i915 one) and tinkering the container configuration, transcoding in Jellyfin is completely hardware accelerated, fully supporting H264/HEVC for both decoding & encoding, and AV1 for decoding only.

The Wayland protocol began its life in 2008, with the first stable protocol version (1.0) being finalized back in 2012. Plasma 5.5 was the first release to sport a Wayland session in 2015, with Plasma 6 finally making it the default in February 2024.

Therefore, Wayland is far from being this new experimental toy which would lack a bit of polish due to its young age. Case in point: KWin maintainers had even announced back in 2018 that KWin/X11 would now be feature frozen.

At this point, it’s fair to consider that the Wayland protocol and its implementation in compositors is fairly mature; and the significant remaining issues are probably caused by some fundamental or structural issue with the protocol itself.

The Good

Wayland has improved multi-monitor support (when they have their own distinct refresh rates), HDR/VRR, and mouse gestures.

That’s it.

Sure, I’ve read some horror stories about bad tearing with Xorg, but I’ve never seen or experienced them personally with any app. Fractional Scaling is also often cited as a new Wayland capability, which is really baffling as I’ve been using 150% fractional scaling on Xorg for literally years (??) which leads me to …

The Bad

The Wayland protocol originally didn’t support fractional scaling at all, only integer scaling! This is not really a surprise, the protocol design is almost old enough to drink beers and pay taxes, and HighDPI screens weren’t really a thing back then. Until recently, fractional scaling was implemented at compositor level, requesting all applications to render at the nearest integer (for instance 2x for 150% scaling), and then scaling down the buffer, resulting in a blurry font mess especially with CJK characters, and abandoning all hopes of getting proper font hinting.

In 2022, an additional optional fractional-scale-v1 protocol was added to the standard, so that applications could have access to the actual fractional scale being currently used on a given screen, and having a chance to scale themselves properly without relying on the compositor. It has been pretty much tacked on the base Wayland protocol as an afterthought, and it shows.

For instance, Firefox has a hidden widget.wayland.fractional-scale.enabled flag to enable experimental support for native fractional scaling, but until Firefox 134 it was completely broken. While this particular issue has now been fixed, popups/menus/tooltips are still randomly blurry due to some obscure pixel grid alignment issue. This is caused by GTK3 not natively supporting fractional scaling anyway, plus Firefox trying its best to still do the right thing on top, but there are no concrete plans to move away from GTK3.

By the way, this is exactly how Xorg has supported fractional scaling since the beginning of times: exposing the actual desired DPI (through Xft.dpi property) to apps and letting them do the right thing. Sure, very old toolkits may have been hardcoded to 96 DPI as it was the usage in the 90’s, but Qt, Electron, Chromium or Firefox work perfectly. Gtk only scales the fonts and UI elements (sometimes), but not the icons, because it is broken on purpose: as Wayland only supported integer scaling, this surely means fractional scaling is useless and technically inferior, right?

Is 2025 the year of the Wayland Desktop (c) ?

After 17 years, it obviously won’t. It is kind of ironic that the main reason why is technical debt: at this point the Wayland protocol is too old and not adapted to modern use cases, making its main argument against Xorg moot. Personally, I stopped caring and trying. My desktop has a single large 4k monitor where fractional scaling is essential, and it doesn’t have a touchpad. Therefore, there is strictly nothing Wayland currently brings to the table that the venerable Xorg can’t provide, with less issues and more stability.

An example of such issues is LibreOffice, which is lagging so badly when scrolling that it freezes. This is even documented on Arch Wiki as the current normal state of affairs, with a workaround to force running it on Xwayland.

Xorg still does everything I need, so let’s hope it will be kept somewhat maintained for the years to come.