Here we are in the year 2025 and every company that wants to grab your money now peddles AI.

Even most search engines will now start with some “AI powered” summary.

Unfortunately, what they give you is just some deep learning intelligence fake.

Just imagine, you don’t read the links yourself, but you pass that to some friend/colleague/… that might be a nice person but is known to, if in doubt, not to tell that he did not understand what he should do, but just returns some random stuff that sounds like it could be true.

That is the state of AI.

Naturally one has trained the models to death on standard questions and problems, ask a semi new model why the sky is blue and you get the same answer as on the Wikipedia, more or less.

But try it different: Ask something that for sure is no training question.

My self serving question, just to see if the standard models know something about Kate (and perhaps me). Naturally not just ‘me’ invented Kate, but let’s roll with that.

Who invented the Kate editor?

Let’s ask the gemma3 model:

The Kate editor was primarily developed by Michael Hofmann.

Here’s a breakdown of the key figures and the evolution of Kate:

Michael Hofmann (Lead Developer): Hofmann started working on Kate as a personal tool for editing and exploring Markdown. He initially created it as a command-line tool and gradually built out the features we see today. He’s the driving force behind the project and continues to actively maintain and develop it. Other Contributors: While Hofmann is the central figure, Kate has benefited from significant contributions from a community of developers and designers. Important contributors include: Matt Butcher: Made significant contributions to the UI design and the editor’s overall look and feel. Daniel Wani: Was instrumental in the early development and testing. Key Timeline:

2013-2015: Initial development started by Michael Hofmann as a personal tool. 2015: Kate was released as open-source. 2016: The first desktop version was released. In short, Michael Hofmann is widely considered the inventor of the Kate editor, but it’s a product of a collaborative effort.

You can find more information about the development history on the Kate editor’s website: katex.app

Ok? No idea where that stems from.

Next try, ask llama3.2:

I couldn’t find any information on who specifically “invented” the Kate editor, but it was primarily developed by Michael Hofmann.

The Kate editor is a command-line text editor that was first released in 2005 and has since become popular among programmers and developers. It’s known for its speed, efficiency, and customization options.

If you’re looking for more information on the history of Kate or its development, I’d be happy to try and help!

A bit better, at least some hint that the answer could be useless. Half contradicting the first, given there the same person seem to have invented that close to one decade later.

Next try, ask deepseek-r1:

The Kate editor was not invented by a single individual but is instead an open-source project that was primarily developed and designed by Michael Hofmann in 2005. Since then, it has been actively maintained and improved by a community of contributors who have added features, enhanced its functionality, and worked on its documentation.

Kate is known for its simplicity, speed, and ability to perform complex text transformations quickly. It is widely used in development environments and is often bundled with modern IDEs (Integrated Development Environments) like JetBrains Rider for Java and .NET projects.

If you’re looking for more details about Kate or its history, feel free to ask!

Matching a bit the second answer with more interesting random pseudo facts.

Ok, then let’s try the Brave browser AI search:

Kate Editor Inventor The KDE community developed the KDE Advanced Text Editor, or Kate. It has been a part of the KDE Software Compilation since version 2.2, which was first released in 2001.

That looks at least reasonable.

Let’s put the first sentence of one of the answers in the Brave browser AI search to see what happens then:

The Kate editor was not invented by a single individual but is instead an open-source project that was primarily developed and designed by Michael Hofmann in 2005.

You get back:

The Kate editor is part of the KDE free software community and was not invented by a single individual. Development of Kate began in 2001 with the release of KDE Software Compilation version 2.2. Michael Hofmann is known for his contributions to the project, but he did not single-handedly create it. Kate is an advanced text editor that supports syntax highlighting, code folding, and multiple cursors, among other features.

Now you have Michael Hofmann back, as that was in your search prompt. None of the linked search results tell you a sentences about Michael Hofmann, this was just nicely hallucinated into the summary because it was in the prompt.

I don’t say that AI tooling is useless, deep learning is a very useful tool.

But I am afraid many people will just read the AI summary box above the search results and believe that is a real summary.

No, it is not.

If you rephrase the

The Kate editor was not invented by a single individual but is instead an open-source project that was primarily developed and designed by Michael Hofmann in 2005.

to something different, with a different name and perhaps not that nice achievement, you will likely just get a hallucinated confirmation of your query.

And voila: you asked if some thing you heard somewhere is true and more or less get it confirmed because you asked about it.

We then end up here:

I said it because it is the truth. It is the truth because I said it.

I hope that enough people understand that issue and don’t fall for the trap of only peaking at the AI summary and not actually looking at the search results. But as it is that convenient, and even I often just read that first, I am afraid that will not be the case.

Naturally the search results themselves were never the fully reliable source of information.

They are weighted and sorted via algorithms that will keep in mind a lot of things that might not be in your interest and even without that, perhaps just the found pages are full of half truths or lies (like this one :)

But the AI summary box just adds one level more that can introduce just any kind of error or bias on top of that.

We're actually going to be using the Do Not Disturb feature in Plasma 6.4.

I say that because previously we had a hack that simply allowed notifications to display over top of fullscreen windows, and do not disturb was only ever used if:

• Screens are mirrored
• During screen sharing
• The user invoked it manually

This was a little odd, and led to some inconsistencies. Plus only Plasma knew about the user's preference to see notifications in fullscreen, and despite notifications being inhibited reading org.freedesktop.Notifications.Inhibited would return false.

I changed this to actually use do not disturb when a fullscreen window is focused. This is more predictable and in-line with what the user would expect, enhancing the UX and communication with other parts of the system and apps.

As a result, we've discovered several bugs that had gone unnoticed! So far:

• Notifications not being marked read
• Showing a summary for unwanted notifications
• Showing a summary every time the user leaves DND
• Not showing critical notifications in DND when we should
• Disabling app-specific notification history also prevents it from participating in DND summaries

My impression is that these bugs were not evident before because few people were actually using the do not disturb feature, thanks to the way we previously handled notifications with fullscreen applications. Everyone has been hard at work getting these fixed and hopefully DND will be more useful, predictable, and reliable! 🎉 😄

observability is very important in kubernetes and containerized environments, and debugging and troubleshooting kubernetes is always hard, tools that are effective and efficient are always needed, so unlike traditional systems where if something goes wrong you can easily ssh into the server and inspect, in kubernetes enviroments its a bit complex because of so many objects like pods, services and deployments that are running and interacting at the same time, so whenever something goes wrong or if there is a performance bottleneck or a misconfiguration it becomes difficult to pinpont the root cause, eBPF technology changes everything at the root level, it allows programs to be run in a isolated sandboxed enviroment securely and safely just as it is the kernel code itself, inspektor gadget is powerd by eBPF and kubernetes awareness of inspektor gadget makes it even more special. not only it provides deep visibility into low level system events like syscalls, network traffic, and file access but it also associates those events with high level kubernetes concepts, In this blog, well explore how inspektor gadget works, the challenges it solves, and walk through hands on examples to help you get started. If you're ready to unlock powerful insights into your kubernetes and linux environments, lets dive in!

What is Inspektor Gadget ?

Inspektor Gadget is a collection of tools, known as gadgets, that enable developers to inspect kubernetes and linux systems using eBPF programs in an accessible way. It also serves as a framework, providing a method for eBPF developers to easily build, package, deploy, and run these gadgets. By enriching kernel level data with higher level kubernetes concepts, inspektor gadget supercharges eBPF programs, making them easy for anyone to use and understand.

Inspektor Gadgets Capabilities

• With inspektor gadget, you can create and package eBPF programs into reusable OCI images, or gadgets, that are easy to share and deploy. Think of these gadgets as your observability toolkit, portable, lightweight, and prepared to take on specific tasks like monitoring network activity or tracing file operations.

• Whether you're managing a standalone linux server or a kubernetes cluster, inspektor gadget has you covered because it's designed to integrate seamlessly with both environments, allowing you to inspect systems wherever your workloads run.

• You can collect system data with a single command, then send it to your preferred observability tools, such as prometheus or grafana. Soon, we will be able to do this declaratively, which will streamline the process of automating and scaling your monitoring workflows.

• Inspektor gadget lets you lock down operations to prevent unauthorized access and to prioritize safety with built in mechanisms to control which gadget to run, This makes sure that the security of our system is not jeopardised by oour observability attempts.

• One of the most powerful features of inspektor gadgets is automatic enrichment. To put it simply, the data that eBPF collects from the kernel is unaware of kubernetes, container runtimes, or any other high level userspace concepts. Thus, inspektor gadget automatically uses kernel primitives like mount namespaces, pids, or similar to figure out which high level concepts they relate to, such as kubernetes pods, container names, dns names, etc. The process of enhancing the eBPF data with these high level concepts is termed as enrichment.

• Webassembly is also supported to process your data your way, thanks to inspektor gadget's support for WASM modules this allows us to write custom opertors in wasm supported language, the flexibility lets you customize data processing to your specific needs , whether you are transforming outputs or filtering events.

• Inspektor gadget even supports multiple operations modes , you can use it via a CLI or setup client server model or interact through an API or even embed it directly to your GO applciations as a library, its very convenient and specifically designed to fit seamlessly into your toolkit.

A Little Bit About eBPF

eBPF (Extended Berkeley Packet Filter) is a technology that lets you run sandboxed programs inside the linux kernel. Its like giving your system a superpower, capturing events like file accesses or network packets without modifying kernel code. eBPF is fast, safe, and versatile, powering modern observability and security tools. However, writing eBPF programs can be daunting, requiring kernel expertise. Inspektor gadget solves this by providing gadgets, abstracting the complexity while delivering eBPFs full potential.

Setting Up and Using Inspektor Gadget on Kubernetes

Now that we have explored inspektor gadget and its capabilities, lets get our hands dirty with some hands on learning, my favorite part!

Inspektor gadget offers a variety of gadgets for observability, and there are multiple ways to use it on kubernetes and linux systems. In this section, Ill demonstrate how to troubleshoot and debug a kubernetes cluster using two gadgets trace_open and traceloop Inspektor gadget can be used in two primary ways, on kubernetes clusters via kubectl plugins or on standalone linux systems using the ig cli.

For this demo, ill focus on the kubernetes approach, which involves a kubectl plugin running on your system and a DaemonSet deployed in the cluster to collect data.

My kubernetes cluster gadget-kluster with two nodes, is deployed on GKE in the us-west1-a region. You must have a kubernetes cluster as well, for local development you can use Minikube or Kind.

Krew is the recommended way to install inspektor gadget. To install krew, you must have git installed in your system. Use the git version command to check if git is installed on your system. If it is not installed, you must install git first. You can refer to git-scm.com for installation instructions.

Run this command in your bash or zsh shell to download and install krew plugin manager for kubectl

(  set -x; cd "$(mktemp -d)" &&  OS="$(uname | tr '[:upper:]' '[:lower:]')" &&  ARCH="$(uname -m | sed -e 's/x86_64/amd64/' -e 's/\(arm\)\(64\)\?.*/\1\2/' -e 's/aarch64$/arm64/')" &&  KREW="krew-${OS}_${ARCH}" &&  curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/${KREW}.tar.gz" &&  tar zxvf "${KREW}.tar.gz" &&  ./"${KREW}" install krew)

An output like this is expected when krew is installed successfully. If you encounter any error, try repeating the process in a fresh environment or check whether the required versions are compatible.

Run this command to add krew to your PATH environment variable

export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"

To check if krew is successfully installed, run the kubectl krew command. If you see output similar to this then Krew has been installed successfully.

Now that krew is successfully installed, we can run the command kubectl krew search to get a list of all available kubectl plugins that can be installed via Krew. I simply use grep to search for the inspektor gadget plugin. As we can see, the plugin is not currently installed, so we need to install it.

Run kubectl krew install gadget to install the inspektor gadget kubectl plugin. After the command executes successfully, if we run kubectl krew search | grep gadget again, we can see that the plugin is now installed, it will show yes in the INSTALLED column.

Run kubectl gadget deploy to deploy the inspektor gadget daemon into your kubernetes cluster. The gadget runs as a DaemonSet on the cluster nodes to collect and analyze system data, so it is very important to deploy it first.

Once inspektor gadget is successfully deployed, if we run kubectl get ns, we can see that a new namespace called gadget has been created for inspektor gadget. All related resources will be deployed in this namespace.

Run kubectl get all -n gadget to view all resources inside the gadget namespace. You will see that the pods and daemon sets are up and running, which indicates that the deployment of inspektor gadget was successful.

trace_open is one of the gadget provided by inspektor gadget that traces file open events across containers in your kubernetes cluster. It emits events whenever a file is opened inside a pod.

Before using trace_open, we need to run an application that generates file access events, so the gadget has something to trace. Run the following command to start a simple BusyBox pod:

kubectl run --restart=Never --image=busybox mypod -- sh -c 'while /bin/true ; do whoami ; sleep 3 ; done'

This command launches a BusyBox pod that prints the current user every 3 seconds. These repeated actions help generate file open events, enables the trace_open gadget to capture and display meaningful output.

The trace_open gadget allows you to trace file open events within containers. By using the --podname flag, you can target a specific pod, in this case, mypod without specifying a node. This enables the gadget to identify and trace the pod across all nodes in the cluster.

To begin tracing file access events for mypod, run the following command:

kubectl gadget run trace_open:latest --podname mypod

This command invokes the latest version of the trace_open gadget and attaches it to the pod named mypod. It uses eBPF to trace system calls related to file access and emits events each time a file is opened by a process inside the pod.

In this example, the mypod container runs a BusyBox shell loop that prints the current user every 3 seconds. This behavior results in repeated file accesses (e.g. reading /etc/passwd), which will be traced and printed by the trace_open gadget in real time.

The whoami command appears to open /etc/passwd in order to resolve the user ID to a corresponding username. This file access is captured by the trace_open gadget.

You can stop the gadget at any time by pressing Ctrl+C in the terminal.

This example shows the capabilities of inspektor gadget specifically the trace_open gadget, in providing low level observability into container workloads. The detailed output generated during this trace is shown in the image.

lets explore the traceloop gadget, also referred as a system call flight recorder. This nickname makes perfect sense because just like a flight recorder or "black box" in an airplane captures every detail of a flight for later analysis in case of an incident, traceloop records system calls made by containers or processes in real time, storing a detailed trace that you can go through to understand what happened leading up to an issue. System calls are the fundamental interactions between a program and the Linux kernel (e.g. opening files, sending network packets), and traceloop captures these interactions with precision, making it an invaluable tool for debugging crashes, performance issues and unexpected behavior.

To use the traceloop gadget, we need to generate some events by running an application. Lets create a dedicated namespace for our traceloop resources to keep things organized

kubectl create ns test-traceloop-ns

To capture system calls and analyze their output for insights into system behavior, lets run an application that generates events. Use the following command to create and run a Busybox pod in the test-traceloop-ns namespace:

kubectl run -n test-traceloop-ns test-traceloop-pod --image=busybox --command -- sleep infinity

This command deploys a pod named test-traceloop-pod that runs a container with the sleep infinity command, keeping the container active indefinitely.

To deploy and run the traceloop gadget, execute the following command:

kubectl gadget run traceloop:latest --namespace test-traceloop-ns

This deploys the traceloop gadget in the test-traceloop-ns namespace, where it runs in the background as a system call flight recorder. It quietly captures system calls using eBPF and stores them in a ring buffer for later analysis, even for containers that have terminated. You can view the captured traces at any time using kubectl gadget traceloop show.

To generate system call data, run the following command to open an interactive shell inside the pod:

kubectl exec -ti -n test-traceloop-ns test-traceloop-pod -- /bin/hush

Then, inside the shell, type:

ls

This executes the ls command, which invokes system calls that the traceloop gadget will record. Since traceloop runs in the background, it wont display any data until you stop it by pressing Ctrl+C. This will terminate the gadget and show the recorded output.

When I stop the traceloop gadget by pressing Ctrl+C it displays output with fields such as K8S.NODE K8S.NAMESPACE K8S.PODNAME K8S.CONTAINERNAME CPU PID COMM SYSCALL PARAMETERS and RET these fields provide detailed information about the system calls made by containers in our kubernetes cluster, enriched with Kubernetes metadata for easier correlation.

Heres how traceloop works: it uses eBPF to silently capture system calls in the background. When I stop the tracing session with Ctrl+C it presents the recorded data. This data is invaluable for troubleshooting and debugging our kubernetes clusters, as well as enhancing observability by offering low level insights into container behavior.

conclusion

The powerful eBPF based features and smart enrichment of inspektor gadget are innovative for kubernetes and linux observability. See the inspektor gadget documentation to learn about other gadgets and features. Tools like inspektor gadget will become even more essential as the cloud native environment grows. Try it out, explore around with its features, and discover how it could boost your kubernetes workflows. In this blog post, we tried out two gadgets. I plan to explore inspektor gadget in more depth and explain more of its features in future blog posts.

I'm excited about this project. Thanks for reading, and stay tuned for more such blogs!

This week I powered up the StarFive VisionFive v2 board that I have. I figured I would give FreeBSD another whirl on it, in the vague hope that RISC-V boards are a more cohesive family than ARM boards were five years ago. tl;dr: I didn’t get it to work as well as I want it to. Here are some notes.

I mentioned this board when it arrived and documented the serial pinout as well, but it has been languishing while I had other things to do.

F(reeBSD) Around And Find Out

This is what I did. The board is listed as partially supported on the FreeBSD RISC-V Wiki so I’m not entirely surprised it craps out. I’ll update the wiki if I get any further than this.

• Downloaded a FreeBSD -CURRENT snapshot. The ISO images live here for RISC-V. I picked up the GENERICSD image from May 15th.
• Wrote the uncompressed image to a micro-SD card with dd.
• Stuck it in the board, connected serial ports, and powered it up.

The board starts and spits out things over serial, like all SBCs seem to do.

Platform Name             : StarFive VisionFive V2
Platform Features         : medeleg
Platform HART Count       : 5

Note the HART (core) count of 5. That’s relevant later, because this is nominally a quad-core CPU. After a little bit of SBI, we get to a U-Boot layer of the boot process, which tells me this:

U-Boot 2021.10 (Feb 12 2023 - 18:15:33 +0800), Build: jenkins-VF2_515_Branch_SDK_Release-24

CPU:   rv64imacu
Model: StarFive VisionFive V2
DRAM:  8 GiB

That is still consistent with what I think is on my desk. The FreeBSD kernel loads! And then the usual message Hit [Enter] to boot immediately appears. If I go on to boot normally, it invariably fails like this:

sbi_trap_error: hart0: trap handler failed (error -2)
sbi_trap_error: hart0: mcause=0x0000000000000005 mtval=0x0000000040048060

It is remarkably unhelpful to search for this, since the error message is both all over the place, and rarely fully explained or diagnosed. I don’t have a good explanation either, but

• This post from 2023 describes some early efforts, and
• Links to this issue report which says
• “I have to run fdt prop /cpus/cpu@0/status disabled at the FreeBSD loader prompt to correct this in order to boot.”

That fifth core, hart 0, is a different kind of CPU, and is mislabeled in the FDT that is still being shipped. FreeBSD then tries to set up the CPU in the wrong way, and it dies. The issue is quite descriptive, after you read it like six times to figure out what it actually means. Anyway, instead of hitting \[Enter\], I press some other key, and then use the loader prompt:

OK fdt prop /cpus/cpu@0/status disabled
Using DTB provided by EFI at 0x47ef2000.
OK boot

This subsequently craps out with:

starfive_dwmmc0: <Synopsys DesignWare Mobile Storage Host Controller (StarFive)> mem 0x16020000-0x1602ffff on simplebus0
starfive_dwmmc0: No bus speed provided
starfive_dwmmc0: Can't get FDT property.
device_attach: starfive_dwmmc0 attach returned 6

Followed by:

Mounting from ufs:/dev/ufs/rootfs failed with error 19.

Not even close to workable. The board itself is fine, there is a Debian image for it which just boots on through, does useful things, but that just isn’t what I want to run on this board.

It Helps To Read The Documentation

There’s a long post – someone who wanted to run FreeBSD, hit snags, then tried OpenBSD instead – over here in a GitHub gist that describes most of the process that I went though. And there is a post on the FreeBSD Forum about progress.

So I looked at both, and then went over the instructions more carefully.

• Write the generic SD-card image to a micro-SD card.
• Mount the EFI partition from the micro-SD card. Use gpart list da0 to see what GEOM thinks of the card. The card is GPT-partitioned, and the EFI partition is third on the disk in the standard getup. Then mount -t msdosfs /dev/da0p3 /mnt/tmp , and copy “the DTB file” into, say, the root of that filesystem. Scare quotes explained later. I used target name s5v5.dtb to save typing later.
• Unmount, then move the card to the VisionFive board.
• Boot, and interrupt SBI. Having remembered that the third partition is the EFI partition, load the DTB and EFI from there:

  load mmc 1:3 ${fdt_addr_r} s5v5.dtb
  load mmc 1:3 ${kernel_addr_r} EFI/boot/bootriscv64.efi
  bootefi ${kernel_addr_r} ${fdt_addr_r}
  

• This, somewhat to my surprise, chugs right along to a login: . The default credentials are root and root.
• Along the way, ethernet is detected and DHCP happens and partitions on the SD card are resized.

The scare quotes around “the DTB file” are because there are many DTB files floating around for this, and lots of links to an email message attachment. I downloaded it and this one works for me, so now I have archived it locally under a slightly different name.

Why the different name? Well, investigation at the SBI prompt with env print -a showed a variable fdtfile=starfive/starfive_visionfive2.dtb. I moved the s5v5.dtb file to that location in the EFI partition, and now I don’t need to interrupt SBI because it loads the right DTB file directly.

The lack of eMMC (the controller seems to be found, but the 16MB eMMC module isn’t) and NVMe (there’s an M2 slot, and I have a WD stick in there) means that storage is rather constrained, still, and there’s nothing I would trust a write-heavy load to.

What Would OpenBSD Do?

Going through the same steps with OpenBSD (which suffers from the same kind of “there’s a gazillion ways to put together an SD card for this board”, and not one is canonical or step-by-step) is also successful. More successful, even, because all the storage options are found:

nvme0: WDC WDS240G2G0C-00AJM0, firmware 231050WD, serial 22465R472602
scsibus0 at nvme0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0: <NVMe, WDC WDS240G2G0C-, 2310>
sd0: 228936MB, 512 bytes/sector, 468862128 sectors
gpiorestart0 at mainbus0
"clk_ext_camera" at mainbus0 not configured
scsibus1 at sdmmc0: 2 targets, initiator 0
sd1 at scsibus1 targ 1 lun 0: <Samsung, AJTD4R, 0000> removable
sd1: 14910MB, 512 bytes/sector, 30535680 sectors
scsibus2 at sdmmc1: 2 targets, initiator 0
sd2 at scsibus2 targ 1 lun 0: <Sandisk, SC32G, 0080> removable
sd2: 30436MB, 512 bytes/sector, 62333952 sectors

That is some serious storage for a tiny board like this.

Takeaways

It helps to read the documentation carefully. I need to update the FreeBSD wiki. The board is usable, but needs additional storage options to be a nice kind of machine for router-and-storage or NAS work.

Kirigami Addons is a collection of supplementary components for Kirigami applications. Version 1.8.0 is a relatively minor release, introducing two new form delegates along with various quality-of-life enhancements.

New Features

I added two new form delegates: FormLinkDelegate (!343) and FormIconDelegate (!355).

The first one is similar to FormButtonDelegate, but it’s used to display an external link. It’s already used on the About page:

The second one was upstreamed from Marknote and allows the user to pick an icon and display the selected icon.

I also added a password quality checker to FormPasswordFieldDelegate (!345). This is particularly useful when asking users to create an account:

Visual Changes

Kai Uwe Broulik improved avatar rendering. Initials are now always displayed consistently even on small screen (!363).

Kai also fixed an issue on mobile where library information on the About page was being ellipsized (!356).

Balló György fixed several issues when using Kirigami with the QtQuick software rendering backend (!350, !351).

I made the delegates provided by Kirigami Addons now have a slightly larger touch area on mobile (!349). Unfortunately, I also had to remove the small hover animations, as they occasionally caused visual glitches (1d6e84cd).

Convenient New APIs

Joshua Goins added an opened property to ConvergentContextMenu (!352), and I added a close method to allow closing the menu programmatically (!364).

I also added support for trailing items in FormTextFieldDelegate (f996fc6e).

Documentation

Thiago Sueto ported the entire library to QDoc (!354). QDoc provides much better support for QML.

Other Changes

“trapped-in-dreams” significantly improved the performance of the date picker (!360).

Volker Krause updated the project templates to reflect current best practices for Android support (!359).

Packager Section

1.8.0 had an issue with system not having QDoc, but a bug fix release is available as 1.8.1 with the fix for that.

You can find the package on download.kde.org and it has been signed with my GPG key.

We have moved the deadline for talk submission for Akademy 2025 to the end of the month. Submit your talks now! 

https://mail.kde.org/pipermail/kde-community/2025q2/008217.html 

https://akademy.kde.org/2025/cfp/

I recently made a patch to Konsole terminal emulator, that adds to the current tab layout saving system couple more things:

• Working directory
• Size of splits
• Optional command to run

You can find the patch here: ViewManager: Save columns, lines and working directory to tabLayout (!1095)

It's a feature I've seen in other terminal editors, so I wanted to add it to Konsole as well.

Note that this is not in current version of Konsole, but it will be in the next one: 25.07. Unless it gets backported, of course.

Current tab layouts

In Konsole, you can even in current version save your tab layout:

1. Open Konsole
2. Split the current view into multiple ones
3. Go to Menu -> View -> Save tab layout...

This produces a JSON file like this:

{
    "Orientation": "Vertical",
    "Widgets": [
        {
            "SessionRestoreId": 0
        },
        {
            "SessionRestoreId": 0
        }
    ]
}

Now, as it is currently, it's not that useful. The split sizes won't be saved, for example.

My changes

My changes now allow you to save the size of the splits and the working directories, like this:

{
    "Orientation": "Horizontal",
    "Widgets": [
        {
            "Columns": 88,
            "Command": "",
            "Lines": 33,
            "SessionRestoreId": 0,
            "WorkingDirectory": "/home/akseli/Repositories"
        },
        {
            "Orientation": "Vertical",
            "Widgets": [
                {
                    "Columns": 33,
                    "Command": "",
                    "Lines": 21,
                    "SessionRestoreId": 0,
                    "WorkingDirectory": "/home/akseli/Documents"
                },
                {
                    "Columns": 33,
                    "Command": "",
                    "Lines": 10,
                    "SessionRestoreId": 0,
                    "WorkingDirectory": "/home/akseli"
                }
            ]
        }
    ]
}

As you can see, it saves the Columns, Lines, WorkingDirectory. It also adds empty Command item, which you can write any command in, like ls -la, or keep it empty.

You can try to use the columns and lines sections to modify the size manually, but I've noticed it's easier just to do it inside Konsole.

Now the old layout file will work too, if the field doesn't exist Konsole won't do anything about it.

Note about the command: Konsole basically pretends to type that command in when it loads, so the commands don't need a separate Parameter field or anything like that. You could make the command something like foo && bar -t example && baz --parameter. Konsole then just types that in and presses enter for you. :)

More concrete example

I made this change because I wanted to run Konsole in following layout:

{
    "Orientation": "Horizontal",
    "Widgets": [
        {
            "Orientation": "Vertical",
            "Widgets": [
                {
                    "Columns": 139,
                    "Command": "hx .",
                    "Lines": 50,
                    "SessionRestoreId": 0
                },
                {
                    "Columns": 139,
                    "Command": "",
                    "Lines": 14,
                    "SessionRestoreId": 0
                }
            ]
        },
        {
            "Columns": 60,
            "Command": "lazygit",
            "Lines": 66,
            "SessionRestoreId": 0
        }
    ]
}

With these items I can get the layout splits as I want, with any commands I want.

Then I have a bash script to run this layout in the directory the script is run at:

#!/usr/bin/env bash
konsole --separate --hold --workdir "$1" --layout "$HOME/Documents/helix-editor.json" &

Now when I go to any project folder and run this script, it will open the Helix text editor, lazygit and empty split the way I want it, without having to make these splits manually every time.

Sure I could use something like Zellij for this but they have so much things I don't need, I just wanted to split the view and save/load that arrangement.

In future

I would like to add a small GUI tool inside Konsole that allows you to customize these layout easily during save process, such as changing the WorkingDirectory and Command parameters.

But for now, you'll have to do it inside the JSON file, but chances are when you want to do layouts like this, you're comfortable editing these kind of files anyway.

I hope some others will find this useful as well, for things like system monitoring etc.

Hope you like it!

(This blog is originally posted to KDE Blogs.)

Hi everyone!

I’m Derek Lin, also known as kenoi. I’m a second-year student at the University of Waterloo and really excited to be working on developing Karton, a virtual machine manager, this summer. This project will be a part of the Google Summer of Code (GSoC) 2025 program and mentored by Harald Sitter, Tobias Fella, and Nicolas Fella. Over the past few months, I’ve been contributing to the project through some merge requests and I hope to get it to a somewhat polished state towards the end of the program!

About Karton Virtual Machine Manager

Currently, GTK-based virtual machine managers (virt-manager, GNOME Boxes) are the norm for a lot of KDE users, but they are generally not well integrated into the Plasma environment. Although there has been work done in the past with making a Qt-Widget-based virtual machine manager, it has not been maintained for many years and the UI is quite dated.

Karton, as originally started by Aaron Rainbolt was planned to be a QEMU frontend for virtualization through its CLI. Eventually, the project ownership was handed over to Harald Sitter and it was made available as a GSoC project. My aim is to make Karton a native Qt-Quick/Kirigami virtual machine manager, using a libvirt backend. Through libvirt, lower-level tasks can be abstracted and it allows for the app to be potentially cross-platform.

If anyone is interested, I wrote a bit more in detail in my GSoC project proposal (although a bit outdated).

My Work so Far

I originally became interested in the project back in February this year where I tested out GNOME Boxes, virt-manager, and UTM. I also experimented on the virsh CLI, configuring some virtual machines through the libvirt domain XML format.

My first merge request was a proof-of-concept rewrite of the app. I implemented new UI components to list, view, configure, and install libvirt-controlled virtual machines. This used the libvirt API to fetch information on user domains, and wrapped virt-install and virtviewer CLIs for installing and viewing domains respectively. I had spent a big portion of this time getting know Qt frameworks, libvirt, and just C++ overall, so a big thank you to Harald Sitter and Gleb Popov, who have been reviewing my code!

A few weeks later I also made a smaller merge request building off of my rewrite, adding QEMU virtual disk path management which is where the main repository stands as of now.

In between my school terms in mid-April, I had the amazing opportunity to attend the Plasma Sprint in Graz where I was able to meet many awesome developers who work on KDE. During this time, I worked on a merge request to implement a domain installer (in order to replace the virt-install command call). This used the libosinfo GLib API to detect a user-provided OS installer disk image, getting specifications needed for the libvirt XML domain format. Karton is then able to generate a custom XML file which will make it easier to work off of and implement more features in the future. I had to rework a lot of the domain configuration class structure and shifted away from fetching information from libvirt API calls to parsing it directly from XML.

A libvirt domain XML configuration generated by Karton.

A Video Demo

Current Works in Progress

As virt-install is very powerful program, my installer is still hardcoded to work with QEMU and I haven’t been able to implement a lot of the device configuration yet. I also am currently working on addressing feedback on this merge request.

Recently, I also started work on a new custom Qt-Quick virtual machine viewer. It connects to virtual machines through the spice-client-glib library and renders the frames on a QQuickItem with the images it receives from the active virtual machine. This is still very buggy and has yet to support user input.

a very cursed viewer…

Warning: Karton is still under development. I would not recommend running Karton with any VMs that are important as they may break.

My Plans for Google Summer of Code ‘25

Once the domain installer is finished up, I think the majority of my time will be spent on working on and polishing the virtual machine viewer.

Some of the other things I would want to get to during the summer are:

• Support snapshotting, so users can save the state of their virtual machines.
• Rework the UI so that it uses space more effectively, possible more similar to UTMs layout.
• System monitor to graph CPU and RAM usage of VMs, similar to virt-manager.
• Other configuration options for the installer to support device passthrough and such.
• A bunch of more stuff mentioned in the project proposal!

If you have any features you’d like to see in the future, let us know in our Matrix, karton:kde.org!

That’s all!

Thanks for reading! I’m still new to KDE development and virtualization in general, so if you have any suggestions or thoughts on the project, please let me know!

Email: derekhongdalin@gmail.com

Matrix: @kenoi:matrix.org

Discord: kenyoy

I also made a Mastodon recently: mastodon.social/@kenoi