fidzu : KDE

I regularly read questions from new users on Reddit and KDE's discussion forum asking what Linux-based operating system they should start out with, or asking for help after choosing an unsuitable one.

Inspired by a recent example on Reddit, I decided to write this post for them.

Not for you, O advanced reader who is happily using NixOS, Gentoo, or Hannah Montana Linux! If you're content, I'd encourage you to do something more useful with the next five minutes of your life. These minutes are for for your friend who's currently using Windows.

A major problem our corner of the world faces is that there's absolutely terrible information about which Linux-based operating system to choose when you're ready to make the move:

https://distrowatch.com/ shows approximately five billion options and provides no real guidance for making a decision.

Asking "what Linux distro should I use" to a search engine, an AI, or YouTube returns a veritable graveyard of bad advice, link-spam blog posts, and interactive "help me choose a distro" websites that will steer you wrong 100% of the time.

Famous YouTuber Linus Sebastian has probably made tens of thousands of dollars repeatedly and somewhat hilariously choosing bad options in front of a camera.

With so little to go on, people can be forgiven for making bad choices. So today I'd like to share my personal recommendations - at least for KDE-centric options! KDE maintains https://kde.org/distributions/, which includes four pretty good ones. But I'm going to be bold and recommend only two of them:

Choose Fedora KDE or Kubuntu

Both Fedora KDE and Kubuntu share a lot of positive traits:

1. Secure Boot is supported, so you can install them on devices that ship with secure boot enabled (which is most sold in the 15 years or so).
2. Included software repositories are large, so you'll probably be able to get most or all of the apps you need without having to add third-party sources.
3. Software from their built-in repositories is updated reasonably quickly, meaning newer hardware and software are generally well-supported. For Kubuntu, this is only the case if you upgrade every 6 months rather than sticking with the LTS versions, so do that!
4. Their developer communities do real QA to ensure that users are protected from most short-term and major regressions from upstream.
5. Their user communities are large, with good documentation and support resources.
6. KDE software is well-integrated and offers a good experience, with nothing obviously missing or broken.
7. Their core package management systems are robust and integrated well into KDE's Discover software center app.
8. Popular proprietary software and media codecs are easy to make available during initial installation or setup, and don't de-stabilize the system as a result of doing so.

There's just a lot to like here.

But are Fedora KDE and Kubuntu perfect? No. In particular, both are made from mutable packages assembled on your system. This means:

• If a system upgrade gets gets interrupted in the middle by a power cut or hardware failure, the system can end up unbootable without intervention by an expert.
• Without manual maintenance, long-term installations can end up drifting out of sync with what a new installation would provide, introducing weird issues that are hard to debug.
• Adding third-party software repositories is tempting but unsafe, and can introduce package conflicts that render the system unable to update without intervention by an expert.
• If you tinker too deeply without knowing what you're doing, you can accidentally damage these systems in a way that requires intervention by an expert to repair.
• Major system upgrades take a long time to complete, with multiple reboots (as long as you keep the "offline updates" feature turned on, which is at least a bit safer than in-place updates).

So, not perfect. But, I think, good enough.

What about the immutable OSs? They solve those problems!

Indeed they do! For whose who aren't familiar, there's a new crop of operating systems on the horizon, so-called "immutable" OSs - a terrible term since it implies they're completely locked down and unchanging, which are not the case.

These operating systems offer some form of a read-only core OS, plus various mechanisms for overlaying software on top of it while preventing the core from being damaged over time. This improves safety around system updates in particular.

Practical options here include Aurora, Fedora Kinoite, Bazzite, openSUSE Kalpa, and KDE's own in-progress KDE Linux. Valve's highly-successful SteamOS is also in this category, though as of early 2026, it's not yet intended for general-purpose usage on arbitrary hardware the way the others are.

I feel as strongly that this model of operating system represents the future as I do that said future has not yet fully arrived for everyone.

The truth is, while these OSs solve many longstanding problems in traditional package-based operating systems, they also also introduce a plethora of difficult-to-avoid rough edges and paper cuts for general use. Those who work on these OSs need to smooth out those rough edges before their work can go mainstream. I'm personally involved in an effort to do so for KDE Linux, and I'll be the first to admit it's not there yet.

But I don't like Fedora KDE or Kubuntu!

If you already have a preferred OS, you're not in the target audience for this article. You're opinionated and competent enough that you can probably make anything work, and whatever you've ended up using likely perfectly suits your own personal tastes.

New users have none of your skills or opinions; they need a general recommendation for something that's good enough, safe enough, and not too weird. That's what I'm writing about here.

To be clear, I'm not saying other Linux-based OSs are bad. On the contrary, many are great, and better in a lot of ways than the two I've mentioned. Fedora KDE and Kubuntu have other annoyances beyond just "being made of packages" that I wrote about earlier: neither sets up any kind of emergency rollback system by default; their tentative forays into the realm of Snap and Flatpak as additions to their traditional packages complicate things unnecessarily; and I don't love their goofy wallpapers. These operating systems could be even better for sure.

But whaddaya gonna do, nothing's perfect. What I'm saying here is that I think these two are good enough to be the best choices for new users in the KDE world.

Well OK, but why should I listen to you, anyway!?

Ideally you shouldn't; you should do your own research and make your own decisions. But that can be hard if you're starting from square one and you don't know what to look for!

So I'd say the important part is to look for other options out there that share the same traits I wrote in bold text in the "Choose Fedora KDE or Kubuntu" section. Those are what will make a Linux-based OS easier and more comfortable to adopt.

But no matter what you choose, have fun and see it as an adventure! Switching your operating system out for another one is something most people will never do; you're automatically an interesting person for even making the effort.

If you run into problems, ask humans for help. Don't ask AI, and don't go looking for personal workarounds that will only benefit you and might break in the future. Be a part of the community; learn and grow, and help others do the same.

Good luck!

16 May 2026 10:15pm GMT

---

TL;DR: this post presents an introspectable action runtime for AI-enabled Qt applications, where selected QObject instances are exposed through a smart-object registry, translated into a bounded planning context, and mutated through previewable, validated plans. The approach relies on Qt's existing meta-object system, using Q_PROPERTY, Q_INVOKABLE, object registration, recursive type discovery, and structured operations to keep LLM-generated actions constrained to the actual runtime object graph. The Smart Shapes QML and C++ examples show promising results with both a self-hosted qwen3-coder:30b model and OpenAI's gpt-5.4, while also exposing practical challenges around prompt refinement, context size, multi-action requests, operations versus JavaScript fallback, and domain-specific instructions. Future work points toward larger applications, stronger validation and permissions, better context management, and possibly a generic reflective MCP server for Qt applications.

---

Developing AI-enabled Qt applications often starts with a deceptively simple idea: let users describe what they want, then translate that intent into concrete changes in the running application. However, moving from a natural-language prompt to safe mutations over live QObject instances is not straightforward. The application needs to decide which objects are available, what properties and methods can be used, how to represent the intended changes before applying them, and how to keep LLM-generated output constrained to the actual runtime object graph. Given that, I've been working on designing an introspectable action runtime for Qt applications: selected objects are exposed through a smart-object registry, an LLM provider turns user prompts into previewable plans, and an applier executes validated operations or controlled scripts against those objects. In this article, I'll explore how these modules work together to transform prompts into structured, introspectable, and executable actions over Qt applications.

Given this, such action runtime platform should satisfy three key requirements:

• First, it must be generic and non-intrusive enough to be applied to a wide range of Qt applications, regardless of whether the UI is implemented with Qt Widgets, Qt Quick, or a combination of both. This means the infrastructure should rely on Qt's existing object model, meta-object information, properties, methods, and object ownership rules, instead of requiring application-specific adapters for every use case.
• Second, it must be accurate when translating a user prompt into effective application behavior: natural-language requests should be converted into explicit, previewable, and validated plans that only reference exposed objects and supported operations.
• Finally, performance should remain a first-class concern. The planning context sent to the provider must be rich enough to avoid ambiguous actions, but compact enough to keep latency under control, avoid unnecessary traversal of large object hierarchies, and preserve UI responsiveness while plans are generated and applied.

Architecture Overview

Figure 1 presents the major components of our introspectable action runtime platform.

QSmartObjectRegistry is the bridge to the live Qt object graph. It exposes selected QObject instances, assigns stable references, and describes classes, properties, methods, and collections. QSmartObjectPlanner turns a prompt into a bounded planning context. It combines the user command with registry metadata, sends that context to a provider, and converts the response into a validated QSmartObjectPlan. QSmartObjectProvider is the AI backend abstraction. QLLMSmartObjectProvider is the concrete HTTP implementation, supporting OpenAI-compatible and Ollama-style chat endpoints. QSmartObjectPlan is the previewable contract between planning and execution. It stores the summary, confidence, issues, mode, structured operations, or fallback script. QSmartObjectApplier executes accepted plans. It either applies structured operations directly through Qt meta-object APIs or runs script fallback through QJSEngine. QSmartObjectExecution reports the final outcome, including success state, summary, errors, and script console output.

For an application to be endowed with an intelligent prompt, its relevant runtime state and behavior must be made visible through Qt's meta-object system. In practice, this means modeling the objects that the prompt should control as QObject-derived classes, exposing editable state as Q_PROPERTY, and exposing safe actions as Q_INVOKABLE methods or slots (many Qt application are already implemented as such). Properties define what the system can inspect and mutate, while invokable functions define the operations that can be requested explicitly by the user. This is an important constraint: the prompt should not operate over arbitrary implementation details, but over a deliberate application surface that the developer decided to expose. The better this surface is named, typed, and organized, the more accurately a natural-language request can be translated into an effective application action.

Object registration and type discovery build on that exposed surface. The application registers selected live objects with QSmartObjectRegistry, optionally giving them stable semantic identifiers and human-readable labels. From there, the registry assigns internal references to these objects and uses Qt meta-object introspection to discover their readable and writable properties, invokable methods, class names, and QObject-based collections. This metadata becomes the planning context consumed by QSmartObjectPlanner: it tells the provider which objects exist, which types can be created or modified, and which operations are actually legal. In other words, registration selects the live objects that participate in prompting, while type discovery describes what the prompt is allowed to do with them.

Type discovery follows the QObject surface exposed by the application. Starting from the objects registered in QSmartObjectRegistry, the implementation inspects their meta-objects and recursively discovers QObject-derived types referenced by Q_PROPERTY declarations, including direct QObject* properties and supported QObject collections such as QObjectList or QList<T>. It also walks readable runtime property values to find live child objects and collection items, so the planning context can include not only the explicitly registered object, but also the relevant object graph reachable from it. This keeps discovery aligned with Qt's meta-object system: arbitrary C++ implementation details remain hidden, while declared properties, invokable methods, and QObject relationships become available for planning. This enables registering central components, such as a Core object, which can end up registering all important objects in the application, such as controllers. Of course, developers can also define a more limited exposure model by individually registering only the desired objects or by turning off recursive type discovery.

Prompt Engineering

One of the main challenges in this approach is that a fully generic prompt can describe the mechanics of object discovery, planning, validation, and execution, but it cannot always capture the application's domain semantics. The same property names and methods may have different meanings depending on the example, and some user requests require contextual rules that are not obvious from the meta-object data alone. For this reason, the generic smart-object prompt may be complemented by example-specific instructions. These instructions explain how the exposed objects should be interpreted in that particular application, which coordinate system is being used, how collections should be handled, which operations are preferred, and how ambiguous commands should be resolved. In practice, the generic prompt provides the execution contract, while the example-specific prompt gives the model the domain knowledge needed to produce accurate plans.

These are the most important fragments of currently adopted generic prompt:

You translate natural-language editing requests into a smart-object mutation plan. Return only a JSON object. Do not wrap it in markdown. The JSON object contains either structured operations or a JavaScript script that will run against live QObject wrappers. The planning context contains two authoritative sections: availableClasses and instances. Use availableClasses as an exhaustive class catalog for all exposed objects and QObject-derived member types, and instances for live objects, aliases, and collection membership. Prefer operations mode. Use script mode only when the request cannot be represented with the supported operation vocabulary.
...
Supported operations are setProperty, adjustProperty, callMethod, createObject, and destroyObject. Operation targets are direct object refs, created ids, or collection selections. Collection sources can use ownerRef for one owner, owner for a target resolving to one owner, or owners for a target resolving to many owners, including nested selection targets.
...
For setProperty and adjustProperty, the property field must exactly match a writable property listed in availableClasses for the target object's class. For collection predicates, the predicate property must exactly match a readable property listed in availableClasses for the collection item class.
...
Treat the planning context as authoritative. Do not invent members that are not explicitly listed there.
...
If the request cannot be satisfied with the available classes, objects, properties, methods, or collection relations, do not approximate it. Return confidence 0.0, at least one issue, empty operations, and an empty script.
...
The result must have this structure: {"summary":"short summary","confidence":0.0,"issues":["optional issue"],"mode":"operations","operations":[{"op":"setProperty","target": {"type":"object","ref":"registry-ref"},"property":"propertyName","value":"value"}],"script":""}
...
For script fallback, set mode to script, operations to [], and script to the JavaScript statements. If the request is ambiguous, return an issue and the safest minimal plan.

Example Application

The current implementation includes both QML and C++ examples built around the same shape-editing scenario. In the QML example, the application uses the QtActionRuntime.SmartObjects QML API directly: shapes are created in a Qt Quick scene, exposed through SmartObjectRegistry, and controlled through LLMSmartObjectProvider, SmartObjectPlanner, and SmartObjectApplier objects declared from QML. The C++ example implements the same workflow with a Qt Widgets interface and a SmartObjectsDemoController, wiring the registry, provider, planner, and applier from C++ and reflecting the generated plan back into the UI before it is applied. Both examples expose shape objects with properties such as position, size, color, and type, then allow prompts like moving a circle or changing its color to be translated into validated smart-object plans, as described in Figure 2.

Results

We tested the Smart Shapes example with both a self-hosted Ollama backend running qwen3-coder:30b and OpenAI's gpt-5.4 model, and both produced good results for a range of natural-language commands. The prompts covered simple creation and editing requests, such as "create a new yellow circle", "rename the yellow circle to myCircle", and "move myCircle to the right of rectangleOne", as well as destructive and spatial operations like "remove the red circle" and "arrange all circles evenly around rectangleOne, using a radius of 200 and the rectangle's center as the arrangement center". These tests helped validate that the exposed object model, generated planning context, and structured operation format were expressive enough for both local and hosted models to translate user intent into effective changes in the scene.

0:00

/0:13

1×

The next step was to investigate object collection traversal and object discovery in more complex object graphs. The Smart Shapes example already exercises a simple collection through the scene's list of shapes, but real applications usually expose deeper hierarchies: controllers own models, models expose collections, and collection items may reference other domain objects. The goal is to verify how well the planner can discover these relationships from registered root objects, follow QObject-valued properties and supported collections, and still generate accurate operations without requiring every object to be registered manually.

0:00

/0:13

1×

No example-specific instructions were required, so far, for this example because the exposed QObject properties and invokable methods already provided enough semantic information for the planner to generate accurate operations.

Next, we want to try prompts involving multiple objects and multiple actions in a single request. Simple commands are useful to validate the basic planning pipeline, but real user interaction will often combine several intentions at once, such as creating an object, positioning it relative to another one, changing its visual attributes, and updating its identifier in the same prompt. These scenarios are important because they test whether the planner can decompose a compound request into a complete sequence of operations, preserve the correct order of execution, and avoid summarizing changes that were not actually represented in the generated plan. At this point, qwen3-coder:30b occasionally started producing incorrect plans, while gpt-5.4 performed quite well.

0:00

/0:13

1×

Notice that the circles are not actually distributed around rectangleOne's center. This happens because gpt-5.4 has no way to infer how shape centers are computed from the exposed properties alone. The issue was easily fixed by adding example-specific planning instructions, such as: "In this shape demo, x and y are top-left coordinates. Object centers are computed as (x + width / 2, y + height / 2)".

Challenges and Future Work

The implementation also showed that the hard part is not simply calling an LLM, but defining a stable contract between the model and the Qt object graph. The implementation moved from an initial JavaScript-oriented approach to an "operations first, JavaScript after" architecture, then added asynchronous plan generation, cancellation, richer registry metadata, collection predicates, runtime property values, and several rounds of prompt refinement. Prompt design became a central concern because the model must not invent properties, confuse planning metadata with writable object properties, skip parts of multi-action requests, or summarize mutations that were not actually emitted.

Context window sizing is another practical issue: the planning context must include enough classes, instances, collection relations, and runtime values to make accurate decisions, but not so much that local models lose reliability or exceed their useful context. The operations mode gives a safer and more introspectable path for common mutations such as setting properties, calling methods, creating objects, destroying objects, and selecting collection items. JavaScript remains useful as a fallback, but it is harder to validate and has a larger execution surface. Other important challenges include handling provider differences between Ollama-style and OpenAI-compatible endpoints, validating JSON responses, resolving object references safely, and deciding how much of the live object graph should be exposed to the prompt.

A natural direction for future work is to package this infrastructure as a generic reflective MCP server for Qt applications. Instead of each application embedding its own prompt-to-object bridge, a Qt MCP layer could expose selected QObject instances, properties, invokable methods, object collections, and runtime state through a standard protocol, allowing external agents to inspect and operate on live Qt applications in a controlled way. Beyond that, there are several interesting extensions: better permission models for deciding which objects and operations are visible, richer schema generation for enums and value types, configurable recursive discovery policies, stronger plan validation before execution, undo/redo integration, transaction support for multi-step plans, visual plan previews, and model-independent test suites for comparing local and hosted providers.

Another promising direction is to improve context management, so large applications can expose only the subset of the object graph relevant to a given prompt while still preserving enough semantic information for accurate planning.

Last but not least, this solution must be tested in larger and more complex applications. The Smart Shapes example is useful because it makes the core ideas easy to see, but real Qt applications have deeper object graphs, richer domain rules, long-lived controllers, asynchronous operations, permissions, and state that changes while the user is interacting with the system. Those are the scenarios that will really test whether reflective discovery, bounded planning contexts, structured operations, and fallback scripting can scale beyond a controlled demo. If this approach continues to work there, it opens an interesting path: Qt applications that can expose their own runtime capabilities and let users interact with them through intent, not just through predefined UI controls. What about including API documentation, in a Retrieval-Augmented Generation (RAG)-like approach?

That's all for now. Lots of fun happening over here. 😉

16 May 2026 5:58pm GMT

Welcome to a new issue of This Week in Plasma!

This week we released a public beta of Plasma 6.7, ready for testing. A last-minute virtual keyboard feature snuck in… and with that, it's now frozen for further features, and focus will shift to polishing and bug-fixing for the next month or two.

So let's have a look:

Notable new features

Plasma 6.7

You can now configure what triggers Plasma's virtual keyboard to appear. (Kristen McWilliam, Xaver Hugl, and Yelsin Sepulveda, kwin MR #9206 and plasma-workspace MR #6548)

The per-window "Hide from Screencast" feature now also hides the window from static screenshots, too. It's been renamed accordingly. (Elliot Flint, kwin MR #9171)

You can now allow an app that's controlling input devices to do it every time it asks, instead of having to authorize it each time. (David Redondo, xdg-desktop-portal-kde MR #496 and flatpak-kcm MR #175)

Plasma 6.8

Plasma's virtual keyboard now has a dedicated layout and mode of operation for the Amharic language! (Abenezer Wesenseged, plasma-keyboard MR #118)

System Settings' Networks page now lets you configure wireless access points to automatically select a channel. (Mickaël Thomas, plasma-nm MR #523)

Notable UI improvements

Plasma 6.6.6

Made a couple of buttons on System Settings' Fonts page readable by the Orca screen reader. (Nicolas Fella, KDE Bugzilla #519471)

Plasma 6.7

Discover now groups items on its "Installed" page into categories by default! This makes it much easier to find what you're looking for. (Tobias Fella, KDE Bugzilla #423344)

Plasma notifications now slide in from off-screen, rather than fading in. It looks really good, and helps draw attention to new notifications without being too attention-grabbing. (Vlad Zahorodnii, kwin MR #9139)

Improved the Kickoff Application Launcher's ability to launch the item you searched for with a very fast press of the Enter key after some very fast typing. (Christoph Wolk, KDE Bugzilla #519579)

Gwenview is now set to be Plasma's default SVG viewer, so these files won't open with GIMP by default anymore. (Darafei Praliaskouski, plasma-desktop MR #3712)

Made multiple improvements to the workflow around unlocking the session using a smart card. (Andreas Lundqvist, kscreenlocker MR #310)

Moved the "Keep Above Others" window tweak to the top level of the titlebar context menu so you can reach it more easily. We reasoned that this is likely to be one of the more frequently-used items, so it ought to be faster to access. (Vlad Zahorodnii, kwin MR #9201)

Notable bug fixes

Plasma 6.6.6

Fixed an issue that made Plasma crash when restarted using systemctl restart --user plasma-plasmashell.service on systems with multiple screens and multiple panels. (Nate Graham, KDE Bugzilla #515234)

Fixed an issue that made Plasma crash when switching Activities using the Activity Pager widget on systems with multiple screens. (Marco Martin, KDE Bugzilla #520065)

Cloning a panel now successfully copies any standalone launcher icons, too. (Marco Martin, KDE Bugzilla #519502)

The System Monitor app and sensors no longer continue to report phantom network activity while the system isn't connected to any networks. (Kartikeya Tyagi, KDE Bugzilla #508516)

Typing on the desktop to invoke KRunner now works when pressing keys on the number pad, too. (Marco Martin, KDE Bugzilla #504304)

App reviews in Discover no longer get duplicated if you install, uninstall, and re-install the app while Discover remained open. (Tobias Fella, discover MR #1325)

Frameworks 6.27

Fixed a layout issue that could sometimes break Discover completely when the system language was set to Arabic, Chinese, or Japanese. (Akseli Lahtinen, KDE Bugzilla #517091)

The Breeze Icons repo no longer inappropriately uses copyrighted third-party icons. (Nate Graham and Martin Sh., KDE Bugzilla #487595)

Fixed a subtle issue in the common icon browser dialog that made it impossible to select a standard icon from the active icon theme after first selecting an icon from a specific location on disk. (Christoph Wolk, KDE Bugzilla #520007)

Notable in performance & technical

Plasma 6.7

Implemented support for "progressive encoding" for Plasma's built-in remote desktop server, which can be used when a client doesn't support H.264 encoding, or codecs for it aren't available, or when progressive encoding would be more bandwidth-efficient. (David Edmundson, krdp MR #165 and krdp MR #173)

Improved performance and reduced latency for Plasma's built-in remote desktop server. (David Edmundson, krdp MR #170)

Implemented support for version 3.2 of the Wayland Text Input protocol. (David Edmundson, kwin MR #8970)

How you can help

KDE has become important in the world, and your time and contributions have helped us get there. As we grow, we need your support to keep KDE sustainable.

Would you like to help put together this weekly report? Introduce yourself in the Matrix room and join the team!

Beyond that, you can help KDE by directly getting involved in any other projects. Donating time is actually more impactful than donating money. Each contributor makes a huge difference in KDE - you are not a number or a cog in a machine! You don't have to be a programmer, either; many other opportunities exist.

You can also help out by making a donation! This helps cover operational costs, salaries, travel expenses for contributors, and in general just keeps KDE bringing Free Software to the world.

To get a new Plasma feature or a bug fix mentioned here

Push a commit to the relevant merge request on invent.kde.org.

16 May 2026 12:00am GMT

Let's go for my web review for the week 2026-20.

---

EU calls VPNs "a loophole that needs closing" in age verification push

Tags: tech, surveillance, vpn, europe, politics

Urgh… That was only a matter of time before they notice I guess. That'll go straight in the authoritarian playbook if they make a real move on it.

https://cyberinsider.com/eu-calls-vpns-a-loophole-that-needs-closing-in-age-verification-push/

Linux Compromises, Broken Embargoes, and the Shrinking Patch Window

Tags: tech, linux, security

We've seen a stream of those security issues lately. It says something about the security practice in the industry right now. Things need to be improved.

https://www.askbaize.com/blog/linux-compromises-broken-embargoes-and-the-shrinking-patch-window

Can Someone Please Explain Whether Cloudflare Blackmailed Canonical?

Tags: tech, cloud, cloudflare

Honestly the whole situation was bizarre… And yes it feels like Cloudflare actions were not exactly transparent here.

https://www.flyingpenguin.com/can-someone-please-explain-whether-cloudflare-blackmailed-canonical/

Why I'm leaving GitHub for Forgejo

Tags: tech, github, trust

The GitHub exodus continues. Looks like Forgejo is really benefiting from it, I wonder how far this will go.

https://jorijn.com/en/blog/leaving-github-for-forgejo/

Use Protocols, Not Services

Tags: tech, protocols, resilience, self-hosting, politics, decentralized

A good reminder of why this is the protocols which matter. People got too accustomed to centralised platforms.

https://notnotp.com/notes/use-protocols-not-services/

The BeBox: BeOS Hardware, Photos, and the Apple Deal That Wasn't

Tags: tech, hardware, system, history

This was definitely an interesting operating system and the hardware was fun too. Of course it was lacking quite a bit in applications availability. This was likely too radical for its time and not mature enough when it needed to.

https://www.jdhodges.com/blog/bebox-beautifully-overbuilt-computer/

Hey you, start communicating!

Tags: tech, blog, communication, learning

We collectively should reach out more to blog authors indeed. Not for kudos but to feed each other through conversations. That's how we collectively learn and improve.

https://forkingmad.blog/hey-you-start-communicating/

Easy is Overrated

Tags: tech, ai, machine-learning, gpt, research, quality

As if research wasn't already having a quality problem in submitted papers… now thanks to people jumping on LLMs to churn out papers faster, this quality is cratering.

https://calnewport.com/easy-is-overrated/

Local AI Needs to be the Norm

Tags: tech, ai, machine-learning, nlp, ethics, performance, architecture

Which means simpler models: and this is fine for most use! It's also easier to have more ethical options with the smaller and more specialised models. Let's not forget they exist even though the big industrial complex would like people to forget.

https://unix.foo/posts/local-ai-needs-to-be-norm/

Pyrefly v1.0 is here!

Tags: tech, python, type-systems

Another type checker for Python gets stabilised. So many options and fragmentation in this space. This is odd.

https://pyrefly.org/blog/v1.0/

Just Fucking Use Go

Tags: tech, backend, go

Kind of a rant but it makes sense for the most part. Back end systems could be much simpler than they tend to be. I think this particular piece is willingly ignoring some of the weaknesses in Go error handling though.

https://blainsmith.com/articles/just-fucking-use-go/

The limits of Rust, or why you should probably not follow Amazon, Cloudflare and Discord

Tags: tech, rust, ecosystem, maintenance

As usual with this author it feels a bit too much like advertising toward the end. Still this is an important post, it shows quite well why you can't limit yourself at only the language used when picking a stack. You definitely need to look at the standard library and the wider ecosystem as well. Rust is no different there and has its own issues.

https://kerkour.com/the-limits-of-rust

C++26: Standard library hardening

Tags: tech, c++, standard, reliability, memory

It's about time such a thing gets standardised in C++!

https://www.sandordargo.com/blog/2026/05/13/cpp26-library-hardening

Let's Build a Regex Engine

Tags: tech, regex

Still a work in progress, but it'll likely turn out into a nice resource on how to implement regex engines.

https://kean.blog/post/lets-build-regex

Floating point from scratch: Hard Mode

Tags: tech, floats, cpu, hardware, mathematics

Nice exploration of floating point arithmetic all the way down to the silicon.

https://essenceia.github.io/projects/floating_dragon/

On Rendering the Sky, Sunsets, and Planets

Tags: tech, graphics, shader, 3d, physics

Everything you wanted to know about atmosphere rendering but didn't dare ask. Very good piece, makes me want to write a live wallpaper for Plasma. :-)

https://blog.maximeheckel.com/posts/on-rendering-the-sky-sunsets-and-planets/

I learned something about GPUs today

Tags: tech, gpu, 3d, shader, mathematics

Huh! Indeed I'd have fallen in this trap too. Totally unexpected behavior, and of course not all GPUs interpolate the same, so it can stay hidden until too late.

https://foon.uk/blackshift-sand-bug/

Getting peak TOPS on a Ryzen AI 7 350 NPU

Tags: tech, cpu, npu, hardware

Wondering about NPUs architecture and how they work? This is a good in depth reference article I think.

https://destevez.net/2026/05/getting-peak-tops-on-a-ryzen-ai-7-350-npu/

The Hard Parts.dev

Tags: tech, engineering

Looks like an interesting reference of patterns in software engineering.

https://thehardparts.dev/

Be a Multiplier: Lead by Guiding Others

Tags: tech, engineering, leadership

This is a short one but a good one I think. Helping others to do rather than doing directly is the needed shift to get into technical leadership. It's not an easy leap though, been helping some people getting there and it's quite the effort.

https://estherderby.com/tech-leadership-be-a-multiplier/

---

Bye for now!

15 May 2026 3:45pm GMT

This is the release schedule the release team agreed on

https://community.kde.org/Schedules/KDE_Gear_26.08_Schedule

Dependency freeze is in around 7 weeks (July 2) and feature freeze two weeks
after that. Get your stuff ready!

14 May 2026 4:31pm GMT

Here are the new modules available in the Plasma 6.7 beta:

• plasma-bigscreen
• union

Some important features and changes included in 6.7 beta are highlighted on KDE community wiki page.

Help stress-test the Union theming system

This releases marks the first public tech preview of the new Union theming system! In the beta, it is used to style all apps using QML and Kirigami when the union package is installed.

The intention is for these apps to look as similar as possible to how they look without Union.

To help the dev team ensure that's the case, look for visual issues in apps using QML and Kirigami (for example: System Settings, System Monitor, Discover, Spectacle, NeoChat, Haruna, Plasma widget config dialogs).

If you find any issues, make sure they're Union-specific by running the app with the QT_QUICK_CONTROLS_STYLE=org.kde.desktop variable set; this uses the old styling system so you can compare the two.

If you've found a Union-specific issue, report it here.

Everything else

View full changelog

14 May 2026 12:00am GMT

I just realized it has been a full year since I blogged last. Time flies and I will try to do (much much) better this year.

My last entry was about foss-north 2025 and now foss-north 2026 has just passed. It was a successful event and Tobias really helps bringing new energy to the event - including a whole crew of volunteers.

During the foss-north events all talks are recorded. These are then made available on YouTube and on a peertube instance. Historically this has been conf.tube which was provided by a kind supporter to the cause. However, now the costs has exceeded what is reasonable, so it was migration time.

We've looked at taking over the full peertube instance, but quickly realized the costs were too high for us as well. Instead we took over the domain (thank you!) and one of our speakers offered to host us on his instance. Thus, all past foss-north videos, and the new ones for 2026, have been migrated to https://peertube.anduin.net/c/fossnorth/videos .

So, what about migration? The intra peertube transfer failed - much because the aging conf.tube setup did not want to produce the 360GB export. So we had to take another path.

What path you ask? Python scripts! (of course)

So first, we created a Python script storing all URLs from conf.tube. Both for playlists and videos. Then we created a script collecting the corresponding links from YouTube.

Since the new peertube instance does not have direct import from YouTube enabled, the script downloads the video file, metadata and cover picture from YouTube, and then uploads the video to the peertube instance with the metadata and cover picture. As this is a fully automated flow, it is very convenient.

(for 2026 I adapted the script to sync a YouTube playlist, which is very convenient)

The final output from the migration scripts was a set of redirection statements for nginx which is now deployed to the conf.tube server. This means that all old links to foss-north material at conf.tube should redirect to the corresponding video at peertube.anduin.net, so hopefully no links are dead.

13 May 2026 9:01am GMT

We are happy to announce the release of Qt Creator 19.0.2!

The release fixes switching to English as the UI language in Qt Creator on systems with a non-English locale as well as a few other issues.

13 May 2026 8:52am GMT

Qt Design Studio 4.8.2 ships a major upgrade to the AI assistant, transforming it into a fully agentic AI and taking AI-assisted design to the next level. It now has access to your entire QML project and can autonomously read, write, and refactor your files to complete tasks end to end.

13 May 2026 5:16am GMT

Big Tech's disregard for privacy laws and individuals' personal data has become a matter of national security. As news of willful mismanagement fill the headlines on an almost daily basis, the world is beginning to turn away from expensive and insecure spyware-riddled software imposed by the likes of Microsoft, Google, Meta, Apple, et al.

KDE offers the world a better way.

For 30 years, KDE has been providing the free and open-source software essential for digital sovereignty in personal, corporate, and public infrastructures: operating systems, desktop environments, document viewers, image and video editors, software development libraries, and much more.

KDE's software is competitive, publicly auditable, and freely available. It can be maintained, adapted, and improved in-house or by local software companies. And modifications (along with their source code) can be freely distributed to all users and departments within an organization.

As a non-profit, KDE has no shareholders to serve, no quarterly earnings to grow. KDE charges nothing for its software or its licensing. There are no subscriptions, no spying on users, no disclosure or resale of data that users choose to voluntarily share with KDE, and no secret training of AI models with said data.

KDE will use Sovereign Tech Fund's investment to push its essential software products to the next level, providing every individual, business, and public administration with the opportunity to regain their privacy, security, and control over their digital sovereignty.

"We have long invested in desktop technologies for a reason: they are the primary way people access and use digital services in everyday life" says Fiona Krakenbürger, Technical Director at the Sovereign Tech Agency. "The desktop holds personal data and mediates nearly every service we depend on, from booking the next medical appointment, to education, to the way we work. We are investing in KDE because it is one of the two major desktop environments used across Linux and plays a key role in how millions of people experience open technology. Strengthening KDE's testing infrastructure, security architecture, and communication frameworks is how we invest in the resilience and reliability of the core digital infrastructure that modern society depends on."

Read more about Sovereign Tech Fund's investment in KDE.

13 May 2026 12:00am GMT

How a Documentation MCP Tool Saves LLM Token Usage

Every time an AI agent searches the web for Qt documentation today, it receives full HTML pages loaded with navigation chrome, cookie banners, related-article sidebars, and search-engine snippets that have nothing to do with the answer - burning thousands of LLM tokens before a single line of useful content appears. Qt's new official Model Context Protocol (MCP) tool for Qt documentation solves this directly.

12 May 2026 6:29am GMT

Today KDE releases a bugfix update to KDE Plasma 6, versioned 6.6.5.

Plasma 6.6 was released in February 2026 with many feature refinements and new modules to complete the desktop experience.

This release adds a month's worth of new translations and fixes from KDE's contributors. The bugfixes are typically small but important and include:

View full changelog

12 May 2026 12:00am GMT

Recently I went on the Linux User Space show to talk about KDE Linux, business, and everyone's favorite topic: AI. It was a pretty interesting conversation; check it out:

11 May 2026 7:20pm GMT

So… while doing some work on Oxygen I noticed there was no camera-video icon.

No Oxygen one.
Wille there was already a recently done symbolic one.

Which honestly felt a bit odd considering cameras are one of those objects designers historically cant resist over designing heee… (but then again i got a bit 2 distracted about the future and forgot to look behind me at what was still pretty good)

So I ended up making both versions almost back to back.

Now… I already knew exactly what was going to happen.

I have been doing Oxygen style icons for long enough to know the amount of work involved. Big reflections, materials, shadows, details nobody consciously notices just to change how the icon feels. And to hide my incompetence as a simple designer

It was not just "camera" and realy not a video one but….. It was trying to be a camera. A object. Somthing with texture and personality. Still …. Probably 3 days of work.

The symbolic one on the other hand took minutes.

And honestly… I like symbolic icons. This is not one of those "flat design killed civilization" posts

But it did make me think again about something I keep repeating over and over:
"Less is a bore." as Robert Venturi said.

People usually read that as a attack on minimalism. But I don't.

Reduction is useful. Clarity is useful. Symbolic icons are useful. You also cant hide your design failures as easily, and they can work really well.

The problem for me starts when simplification becomes emotionally neutral. Copy of a copy of a copy of a nothing.

Because thats the thing I care about the most when designing anything. Not beauty exactly… beauty is subjective and honestly kinda impossible to define in any meaningful way.

What interests me more is emotional impact.

How does it make you feel?

Not stricly rationally. But mostly Emotionally.

The Oxygen/old\new/skeo\etc icon is probably excessive and maybe even a little ridiculous. Tiny fake reflections, fake materials, dramatic shadows… but then again thats also what gives it character I think??. It tries to create an "atmosphere" instead of just identifying a function.

And to me atmosphere matters.

Humans are not rationalist grid systems no matter how much "modern" design sometimes pretends we are. We remember things emotionally first. Movies, music, old game menus, interfaces…

Nowdays many interfaces and design languages just feel efficient. Functional. Fast. But also weirdly interchangeable.

And I think thats why so many modern interfaces evaporate from memory so quickly. Perfectly boring floating in UI space. Visually correct but emotionally silent.

Which to me always felt ironic because modernism originally was full of emotion. Optimism. Utopianism. The future as a aesthetic project. Somewhere along the way people kept the reduction but forgot the passion behind it.

Anyway… making these two icons back to back ended up being more interesting than I expected.

They will both be available in PlasmaShell near you….

P.S. welcome to my new home, I'm still alive

I'm probably gona make a video with some crazy ideas for a over the top theme in QML, kinda as a exercise on the sort of things that should be possible in theme engines. Because even with QML giving us allot more creative freedom people still somehow end up making mostly the same thing over and over again.

11 May 2026 2:18pm GMT

Hey everyone! This is my first post and Week 1 status report.

I started this week by setting up:

• The project and configuring jj, a local version control system that has been a lifesaver for testing, simulating, and keeping my commits organized.

• The first step was to build and refactor Plasma NM in parallel while setting up a bare-bones folder structure. Here is the Commit I made.

• After creating the initial folder structure, I started refactoring the main backend service for WifiSecurities, which includes creating separate components for the Enterprise section, authentication, and Wi-Fi security options.

This week, I learned a lot of new things about local version control, architecture for Qt Widgets, and QML.

10 May 2026 1:48pm GMT

Image by: Nuno Pinheiro Following posts on specific work being done on Oxygen, this post is going to try to go beyond the manifest work and look at the bigger picture driving it. The motivation for writing it came when I was listening to a music artist who had completely rebranded himself by appending "Frutiger"...... Continue Reading →

10 May 2026 7:30am GMT