Professional Life

I work as a Senior Software Engineer at AbsInt Angewandte Informatik GmbH.

My work is focused on static program analysis on both binary and source level.

For binary programs, the worst-case stack usage or execution time are computed.

For source programs, coding rules or run time errors are checked and a formally verified C compiler is offered.

Open Source Projects

In my spare time, I work on various open source projects. The most work goes into Kate, the GUI text editor I maintain since two decades.

For more details take a look at the Projects page.

Contact Information

My contact information can be found on the Impressum page.

Cartoon-like Me :P

Might be useful for others, but in the end just a pile of stuff I don’t want to search over and over again.

The libraries linked below will in most cases be for C or C++.

Programming News/Information

• News, Status & Discussion about Standard C++: https://isocpp.org

Multi-Purpose Libraries

• Qt: https://www.qt.io

• BOOST: https://www.boost.org

Compression Libraries

• Zstandard compression: https://facebook.github.io/zstd/

• LZ4 compression: https://lz4.github.io/lz4/

XML Libraries

• light-weight C++ XML processing: https://pugixml.org

JSON Libraries

• fast JSON parser/generator: http://rapidjson.org

Fonts

• Geist & Geist Mono - used on this page for everything: https://vercel.com/font

• MonoLisa - a commercial coding font: https://www.monolisa.dev/

• LucasFonts - small fonts studio in Germany: https://www.lucasfonts.com/

Mail Server Stuff

For my mails, I use postfix & dovecot, here some links about documentation and more.

• postfix documentation: http://www.postfix.org/documentation.html

• dovecot 2.x documentation: https://doc.dovecot.org/

• blacklist performance monitoring: https://www.intra2net.com/en/support/antispam/

HHKB Resources

• HHKB Reddit: https://www.reddit.com/r/HHKB/

• HHKBs compared (Pro 2 vs. Classic vs. Hybrid Type-S): https://seongminpark.com/hhkbs-compared/

• HHKB Professional Hybrid review: https://materialjournal.com/blog/hhkb-hybrid-review

Personal stuff like this web site or my QMK config are hosted on this server:

• https://git.babylon2k.com/cullmann/

KDE

I work on various projects that are under the KDE umbrella.

The Kate editor, a full-featured text editor

• https://kate-editor.org
• https://invent.kde.org/utilities/kate

The KTextEditor framework, a versatile text editor component

• KTextEditor API documentation
• KTextEditor Git repository

The KSyntaxHighlighting framework, > 300 languages supported

• KSyntaxHighlighting API documentation
• KSyntaxHighlighting Git repository

Random other stuff

Other KDE related contributions can be found on my invent.kde.org profile.

Contributors to these projects are welcome.

If you wish to sponsor the work done by KDE in non-technical ways, please think about donating.

GitHub

Contributions to projects hosted on GitHub can be seen in this account:

• https://github.com/christoph-cullmann/

I studied computer science at Saarland University.

I finished my Diploma thesis “Statische Berechnung sicherer Schleifengrenzen auf Maschinencode” in 2006.

In February 2013, I successfully defended my PhD thesis about “Cache Persistence Analysis for Embedded Real-Time Systems”. The official publication can be found here.

Publications

Lists of my publications can be found online at:

• Google Scholar

• dblp computer science library

• ACM digital library

Angaben gemäß § 5 TMG

Dr.-Ing. Christoph Cullmann Lessingstrasse 61 66121 Saarbrücken Deutschland

Kontakt / Contact

Telefon/Mobile/Signal: +49 176 235 467 98 E-Mail: christoph@cullmann.dev

Datenschutzerklärung

Verantwortliche Stelle im Sinne der Datenschutzgesetze, insbesondere der EU-Datenschutzgrundverordnung (DSGVO), ist:

Dr.-Ing. Christoph Cullmann Lessingstrasse 61 66121 Saarbrücken Deutschland

Ihre Betroffenenrechte

Unter den angegebenen Kontaktdaten unseres Datenschutzbeauftragten können Sie jederzeit folgende Rechte ausüben:

• Auskunft über Ihre bei uns gespeicherten Daten und deren Verarbeitung (Art. 15 DSGVO),
• Berichtigung unrichtiger personenbezogener Daten (Art. 16 DSGVO),
• Löschung Ihrer bei uns gespeicherten Daten (Art. 17 DSGVO),
• Einschränkung der Datenverarbeitung, sofern wir Ihre Daten aufgrund gesetzlicher Pflichten noch nicht löschen dürfen (Art. 18 DSGVO),
• Widerspruch gegen die Verarbeitung Ihrer Daten bei uns (Art. 21 DSGVO) und
• Datenübertragbarkeit, sofern Sie in die Datenverarbeitung eingewilligt haben oder einen Vertrag mit uns abgeschlossen haben (Art. 20 DSGVO).

Sofern Sie uns eine Einwilligung erteilt haben, können Sie diese jederzeit mit Wirkung für die Zukunft widerrufen.

Sie können sich jederzeit mit einer Beschwerde an eine Aufsichtsbehörde wenden, z. B. an die zuständige Aufsichtsbehörde des Bundeslands Ihres Wohnsitzes oder an die für uns als verantwortliche Stelle zuständige Behörde.

Eine Liste der Aufsichtsbehörden (für den nichtöffentlichen Bereich) mit Anschrift finden Sie unter: https://www.bfdi.bund.de/DE/Infothek/Anschriften_Links/anschriften_links-node.html

Erfassung allgemeiner Informationen beim Besuch unserer Website

Art und Zweck der Verarbeitung

Wenn Sie auf unsere Website zugreifen, d.h., wenn Sie sich nicht registrieren oder anderweitig Informationen übermitteln, werden automatisch Informationen allgemeiner Natur erfasst. Diese Informationen (Server-Logfiles) beinhalten etwa die Art des Webbrowsers, das verwendete Betriebssystem, den Domainnamen Ihres Internet-Service-Providers, Ihre IP-Adresse und ähnliches.

Sie werden insbesondere zu folgenden Zwecken verarbeitet:

• Sicherstellung eines problemlosen Verbindungsaufbaus der Website,
• Sicherstellung einer reibungslosen Nutzung unserer Website,
• Auswertung der Systemsicherheit und -stabilität sowie
• zu weiteren administrativen Zwecken.

Wir verwenden Ihre Daten nicht, um Rückschlüsse auf Ihre Person zu ziehen. Informationen dieser Art werden von uns ggfs. statistisch ausgewertet, um unseren Internetauftritt und die dahinterstehende Technik zu optimieren.

Rechtsgrundlage

Die Verarbeitung erfolgt gemäß Art. 6 Abs. 1 lit. f DSGVO auf Basis unseres berechtigten Interesses an der Verbesserung der Stabilität und Funktionalität unserer Website.

Empfänger

Empfänger der Daten sind ggf. technische Dienstleister, die für den Betrieb und die Wartung unserer Webseite als Auftragsverarbeiter tätig werden.

Speicherdauer

Die Daten werden gelöscht, sobald diese für den Zweck der Erhebung nicht mehr erforderlich sind. Dies ist für die Daten, die der Bereitstellung der Webseite dienen, grundsätzlich der Fall, wenn die jeweilige Sitzung beendet ist.

Bereitstellung vorgeschrieben oder erforderlich

Die Bereitstellung der vorgenannten personenbezogenen Daten ist weder gesetzlich noch vertraglich vorgeschrieben. Ohne die IP-Adresse ist jedoch der Dienst und die Funktionsfähigkeit unserer Website nicht gewährleistet. Zudem können einzelne Dienste und Services nicht verfügbar oder eingeschränkt sein. Aus diesem Grund ist ein Widerspruch ausgeschlossen.

SSL-Verschlüsselung

Um die Sicherheit Ihrer Daten bei der Übertragung zu schützen, verwenden wir dem aktuellen Stand der Technik entsprechende Verschlüsselungsverfahren (z. B. SSL) über HTTPS.

Information über Ihr Widerspruchsrecht nach Art. 21 DSGVO

Einzelfallbezogenes Widerspruchsrecht

Sie haben das Recht, aus Gründen, die sich aus Ihrer besonderen Situation ergeben, jederzeit gegen die Verarbeitung Sie betreffender personenbezogener Daten, die aufgrund Art. 6 Abs. 1 lit. f DSGVO (Datenverarbeitung auf der Grundlage einer Interessenabwägung) erfolgt, Widerspruch einzulegen; dies gilt auch für ein auf diese Bestimmung gestütztes Profiling im Sinne von Art. 4 Nr. 4 DSGVO.

Legen Sie Widerspruch ein, werden wir Ihre personenbezogenen Daten nicht mehr verarbeiten, es sei denn, wir können zwingende schutzwürdige Gründe für die Verarbeitung nachweisen, die Ihre Interessen, Rechte und Freiheiten überwiegen, oder die Verarbeitung dient der Geltendmachung, Ausübung oder Verteidigung von Rechtsansprüchen.

Empfänger eines Widerspruchs

Dr.-Ing. Christoph Cullmann Lessingstrasse 61 66121 Saarbrücken Deutschland

Änderung unserer Datenschutzbestimmungen

Wir behalten uns vor, diese Datenschutzerklärung anzupassen, damit sie stets den aktuellen rechtlichen Anforderungen entspricht oder um Änderungen unserer Leistungen in der Datenschutzerklärung umzusetzen, z.B. bei der Einführung neuer Services. Für Ihren erneuten Besuch gilt dann die neue Datenschutzerklärung.

Fragen an den Datenschutzbeauftragten

Wenn Sie Fragen zum Datenschutz haben, schreiben Sie uns bitte eine E-Mail oder wenden Sie sich direkt an die für den Datenschutz verantwortliche Person in unserer Organisation:

Dr.-Ing. Christoph Cullmann Lessingstrasse 61 66121 Saarbrücken Deutschland

Generiert von Datenschutzerklärungs-Generator der activeMind AG (Version 2018-09-24).

Haftungsausschluss

Haftung für Inhalte

Als Diensteanbieter sind wir gemäß § 7 Abs.1 TMG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 TMG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen.

Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben hiervon unberührt. Eine diesbezügliche Haftung ist jedoch erst ab dem Zeitpunkt der Kenntnis einer konkreten Rechtsverletzung möglich. Bei Bekanntwerden von entsprechenden Rechtsverletzungen werden wir diese Inhalte umgehend entfernen.

Haftung für Links

Unser Angebot enthält Links zu externen Websites Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft. Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar.

Eine permanente inhaltliche Kontrolle der verlinkten Seiten ist jedoch ohne konkrete Anhaltspunkte einer Rechtsverletzung nicht zumutbar. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Links umgehend entfernen.

Urheberrecht

Die durch die Seitenbetreiber erstellten Inhalte und Werke auf diesen Seiten unterliegen dem deutschen Urheberrecht. Die Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechtes bedürfen der schriftlichen Zustimmung des jeweiligen Autors bzw. Erstellers. Downloads und Kopien dieser Seite sind nur für den privaten, nicht kommerziellen Gebrauch gestattet.

Soweit die Inhalte auf dieser Seite nicht vom Betreiber erstellt wurden, werden die Urheberrechte Dritter beachtet. Insbesondere werden Inhalte Dritter als solche gekennzeichnet. Sollten Sie trotzdem auf eine Urheberrechtsverletzung aufmerksam werden, bitten wir um einen entsprechenden Hinweis. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Inhalte umgehend entfernen.

Quelle: https://www.e-recht24.de/muster-disclaimer.html

This includes my fixes (or workarounds) for Konsole & Kate window activation on Wayland.

If you now start Kate or Konsole inside Konsole, the new processes will properly activate their windows to come on top of Konsole.

This works both for just starting new instances and for re-using already running ones.

For more details, see my older post about the implementation.

At the moment that only works for Konsole & Kate.

If that works nicely for our users, perhaps somebody will come up with a more generic way for that or we can move that workaround to some lower level of the stack.

:) For me that is already a nice Christmas present, I disliked that this was broken for years :)

Btw., thanks again for the amazing end of the year fundraiser results! €280k and counting :)

Feedback

You can provide feedback on the matching Reddit post.

Beside that Plasma will show some small popup to ask if you want to sponsor us with a donation.

It looks like this year that is already going well, below the state as of today, 7th December 2025.

I want to say to all that already donated: Thanks a lot!

I will not personally get any money from that, but I will benefit largely from the stuff KDE e.V. funds with it, like the infrastructure, some people working on our stuff and the very important sprints and conferences!

Keep the money flowing, money is not everything, but if you can not contribute in another way and you have some spare money, please consider a donation.

I wish you all a good end of the year :)

Discussion

Feel free to join the discussion at the Linux reddit.

Unfortunately, not all projects survive the test of time, be it because the developers leave or technology moves on and stuff gets less relevant.

The same happens for our communication channels or web sites. 20 years ago, mailing lists and IRC were still kind of common place, today more people hang around on stuff like discuss.kde.org or in our Matrix channels.

Unfortunately our community is not that good at cleaning dead stuff up or deciding that the zombie state of some things hurt.

Dead Web Sites

A no longer updated website might be a small issue, that just looks bad, but most people will see that stuff with news from 2010 will likely be not alive.

Still, I think it makes sense to remove such sites and just redirect them (if there is any follow up information online).

It is no good state if we have stuff up that rots away since a few years, at least if it contains no other valuable info, like documentation or howtos.

Zombie Git Projects

Worse than dead web sites are zombie Git repositories that still get merge requests but nobody takes a look as all people are just gone but the stuff is not clearly marked as archived.

People waste their time and will likely be upset their contributions are not even looked at.

If a project is really dead, that should be archived, one can still resurrect it with easy later on, it is not gone, just clearly marked as dead.

Blackhole Mailing Lists

Even worse are in my eyes dead mailing lists.

People will drop questions there, in worst case that will even already hang for days in moderation or then forever without answer on the list.

That turns away people, you have a question or contribution and it ends in a black hole? No good first contact.

Solutions? Gardening!

What can we do?

We not just need to create new stuff and maintain what we have, we need to do some house cleaning or gardening.

We did that in the past, we can do it again :)

If you want to help, or just turn up and tell that your old project, web site or list it dead, show up on one of these issues:

• Repository & Bugzilla Cleanup

• Mailing List Cleanup

• Website Cleanup

Discussion

Feel free to join the discussion at the KDE reddit.

Given my first PC was some Pentium 100 with 16 MB of main memory and Windows 95, that was my first dive into open source software.

Seems I went in less than 2 years from starting on Windows to at least trying out Linux.

A few years later I joined the great KDE community and stayed there :)

:) Now I feel old.

Feedback

reddit - Do you still remember your first Linux distribution?

In short: for some actions you want to activate your application window. How to do that differs from platform to platform.

Some weeks ago there was a post by Kai about window activation on Wayland.

It explains nicely how the XDG Activation protocol works and how the different parts of the KDE & Qt stack implement it to correctly allow to activate the right windows in your KDE Plasma Wayland session.

What’s the issue?

For the most parts this works now flawlessly, but there is some corner case not handled that well at the moment: stuff launched by our terminal emulator Konsole.

This is no large issue for many users, but I rely in my usual workflow with Kate a lot on just being able to do

❯ kate mycoolfile.cpp

in my Konsole window and if Kate is already running to have the existing window activated.

That worked just fine on X11, but on Wayland the safeguards to avoid misuse of window activation stopped that. There I just get some flashing of the Kate icon in the task switcher.

After some years of ignoring that issues myself and hoping a solution would just materialize, I now gave that some try to fix it myself.

The hack (solution)

In the most cases it is easy to get the application that launches stuff to export a new XDG_ACTIVATION_TOKEN environment variable for the new process and all stuff just works.

Unfortunately that is not that easy for a terminal emulator.

Naturally Konsole could create and export one before starting the shell, but that is an one-time use token. In the best case the first launched Kate or other application could use it once.

The current solution is to allow applications to query a XDG_ACTIVATION_TOKEN via DBus from Konsole, if they can prove they got started inside the shell session by passing a KONSOLE_DBUS_ACTIVATION_COOKIE that got exported by Konsole to the shell.

This leads to the following client code in Kate/KWrite and Konsole itself.

    // on wayland: init token if we are launched by Konsole and have none
    if (KWindowSystem::isPlatformWayland()
        && qEnvironmentVariable("XDG_ACTIVATION_TOKEN").isEmpty()
        && QDBusConnection::sessionBus().interface()) {
        // can we ask Konsole for a token?
        const auto konsoleService = qEnvironmentVariable("KONSOLE_DBUS_SERVICE");
        const auto konsoleSession = qEnvironmentVariable("KONSOLE_DBUS_SESSION");
        const auto konsoleActivationCookie
            = qEnvironmentVariable("KONSOLE_DBUS_ACTIVATION_COOKIE");
        if (!konsoleService.isEmpty() && !konsoleSession.isEmpty()
            && !konsoleActivationCookie.isEmpty()) {
            // we ask the current shell session
            QDBusMessage m =
                QDBusMessage::createMethodCall(konsoleService,
                    konsoleSession,
                    QStringLiteral("org.kde.konsole.Session"),
                    QStringLiteral("activationToken"));

            // use the cookie from the environment
            m.setArguments({konsoleActivationCookie});

            // get the token, if possible and export it to environment for later use
            const auto tokenAnswer = QDBusConnection::sessionBus().call(m);
            if (tokenAnswer.type() == QDBusMessage::ReplyMessage
                && !tokenAnswer.arguments().isEmpty()) {
                const auto token = tokenAnswer.arguments().first().toString();
                if (!token.isEmpty()) {
                    qputenv("XDG_ACTIVATION_TOKEN", token.toUtf8());
                }
            }
        }
    }

The KONSOLE_DBUS_SERVICE and KONSOLE_DBUS_SESSION environment variables did already exist before, the only new one is the secret KONSOLE_DBUS_ACTIVATION_COOKIE that is filled by Konsole with some random string per shell session.

The org.kde.konsole.Session has now a new activationToken method to retrieve a token. That method will only work if the right cookie is passed and if Konsole itself is the current active window (else it will not be able to request a token internally).

As it easily visible alone from the naming, that is some Konsole only interface and one needs own code in applications that want to make use of it.

Therefore this is more of a hack than a proper solution.

If it inspires others to come up with something generic, that would be awesome!

I will happily help to implement that in Kate and Co., but until that happens, at least my workflow is back working in my Wayland session.

Feedback

You can provide feedback on the matching Lemmy and Reddit posts.

Wayland, what?

Since years (or let’s say a decade now) Wayland based compositors are promoted as the successors to the venerable X.org X11 display server.

If you want to have some more high level overview about what is different to good old X11 see the Wayland Architecture overview.

But my Xeyes…

And yes, X11 will not just vanish in the next years and Xwayland will allow to run legacy applications for even longer without relying on the full low-level X11 stack.

But poor Xeyes will not be able to watch Wayland windows, evil security, I want my global key logger in no time!

My experience in 2025

Since my last post in 2021 I use Wayland more or less exclusive on all my private machines.

The latest newcomer to that is a M2 Macbook Air, even there it works just fine for me in general. For more details, here is my NixOS configuration for that machine, many thanks to the Asahi Linux team to make that feasible!

At work we use Arch Linux since some time and there Waylands works just fine for my needs, too.

I must confess I stay away from NVIDIA hardware and the AMD, Intel & Apple M2 GPUs I use work nicely with the open source drivers. Therefore, if you are a NVIDIA user, your mileage might vary.

Same if you are stuck on some older distribution, but as said, X11 is not gone. Before my 2021 switch I did keep using X11 due to driver issues, too, and I think that will still be feasible for years.

For day to day tasks I face no bugs that block me on either NixOS or Arch Linux.

For Kate itself, we had some persistent issues with bad parents of popups, that should now be fixed in the latest Frameworks 6 and some upcoming Qt 6.9.2 or higher patch release. That should remove the last logging spam on the terminal about Wayland issues like seen below.

qt.qpa.wayland: Creating a popup with a parent, QWidgetWindow(0x559ddf4cf3c0, name=“MainWindow#1Window”) which does not match the current topmost grabbing popup, QWidgetWindow(0x559de00644b0, name=“goWindow”) With some shell surface protocols, this is not allowed. The wayland QPA plugin is currently handling it by setting the parent to the topmost grabbing popup. Note, however, that this may cause positioning errors and popups closing unxpectedly. Please fix the transient parent of the popup.

The stuff did in principle work before, but that output still was unsettling and in rare cases could lead to totally misplaced popups or other issues with them.

One thing that I myself underestimated a lot in the past is, that Wayland is just a different thing than X11. It is a totally different platform in many aspects and just because stuff works as wanted on X11, if they are very low level, they might not work the same way on Wayland. Thankfully a lot of people helped to fix the issues we had!

All done?

No, naturally not. One could ask: but a lot of people worked on that a decade? How can that be?

Wayland is as said above really different to X11 in design (for good reasons, we no longer live in the 80ties and requirements have changed), it is expected that this will take time given the amount of code we have.

The currently known significant issues that still not work looks reasonable small to me. Naturally that might be different for others, one must be transparent that some stuff is working differently now and that some things still just not work (and some never will work by design).

My personal biggest issue I still have with Kate is the missing way to raise my existing windows if I open a new file via the terminal shell. All works fine if you do that via Dolphin and Co. as I get some activation token, that is at the moment just not feasible via the terminal with the shell.

With virtual desktops we miss some way to pick the right window or decide if we need to open a new one (even if we get a activation token from Dolphin), see bug 503519.

My current KDE Plasma Wayland session

Like in the last post, let’s take a look at how my current session looks.

Try it out!

I can encourage all to give Wayland a try, if you are on some up-to-date distribution. To hunt the last bugs, we need more adopters. That more and more distributions default to Wayland naturally helps in that respect. But one must manage the expectations, the currently known issues will not just disappear over night.

Help out!

If you encounter issues, please report them as bug reports to the respective upstream projects. And naturally, any help in fixing them would be welcome, too. For Kate/KTextEditor beside the above mentioned window activation, I got all stuff that bothered me fixed. Naturally there will still be things that annoy others, patches welcome, scratch your own itch!

Feedback

You can provide feedback on the matching Reddit post.

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.

This means I look at user bug reports for over 20 years now.

The statistics tell me our team got more than 9000 bugs since around 2001 (just for Kate, this excludes the libraries like KTextEditor that we maintain, too).

That is a bit more than one bug per day for over two decades.

And as the statistics show, especially in the last years we were able to keep the open bug count down, that means we fixed a lot of them.

Given we are a small team, I think that is a nice achievement.

We not just survived over 20 years, we are still alive and kicking and not just a still compiling zombie project.

Thanks a lot to all people that are contributing to this success!

Let’s keep this up in the next year and the ones following.

Let’s start with looking at what I mean with KDE applications and what the current state is, up to KDE Frameworks 6.2 and current KDE Gear 24.02. Then let’s see what will be improved in future releases.

What do I mean with ‘KDE Applications’

If I speak about ‘KDE Applications’ here I talk about applications like Kate, Dolphin, Okular and others like that.

This means applications developed with Qt and KDE Frameworks that integrate well with the KDE Plasma desktop but are not restricted to it.

Many of this applications not just aim to work well on Linux & BSD or other open source operating systems but are ported and working well on the rather different Windows and macOS desktop. Some even are successful since years in the official Windows Store.

The above applications are part of the KDE Gear releases, but the described issues and solutions naturally are not restricted to stuff released with that.

What most of these applications have in common is that they rely on rather large parts of our Frameworks. With that they depend at least indirectly on an icon set that covers large parts of what our default icon set Breeze provides. Even if you use no icons from that icon set yourself in your application, just using the standard actions or many widgets/dialogs from Frameworks will rely on some subset of Breeze.

Current State of Icons per Desktop or Platform

When talking about the current situation of icons that depends largely on the desktop or platform you are running the KDE application on.

Let’s take a look at some (I for sure miss some that are common or loved, that doesn’t mean I disregard them, I just want to limit the scope).

KDE Plasma on Linux/BSD with Wayland/X11

If you just aim to run on the KDE Plasma desktop with your Qt and KDE Frameworks based application, all is fine with icons, there is no problem.

The KDE project did their job, at least for Kate I never did have any issues with icons on Plasma.

Below a screenshot of Kate 24.02 running on Plasma 6. All icons are there, they are properly re-colored for the dark theme, too, including not just the used Breeze icons but for example the small Git icons in the left sidebar that Kate has bundled.

This is the vanilla state each user will get if Kate is installed on Plasma (and the dark theme is used). There are no patches done during building to achieve that nor is there any extra user configuration necessary.

Microsoft Windows

If you run Kate on Windows, the icon situation is good, too, if you use our Windows Store variant or get at build done via Craft.

See below what the current nightly of Kate looks like in some Windows 11 VM (I just started it from the unpacked ZIP, no setup needed).

In the Craft build descriptions we do some patches to ensure the Breeze icons are bundled as library and the application links with that. In addition we ensure with some more patching that our own icon engine is used to allow for the proper recoloring.

If you don’t do that patching you will end up with close to no icons or for dark theme black on black icons.

Apple’s macOS

The situation on macOS is the same as on Windows.

If you go with a Craft build of Kate, you will end up with something like below.

All icons are there and even application provided icons like our Git one are properly recolored.

Without the Craft patches Kate has more or less no icons like on Windows.

Haiku

After covering Plasma and the two large closed-source desktop operating systems, as a small excursion, look how Kate (the KF5 based version) looks if installed on Haiku with the package they provide.

Kate looks ok, system icons intermixed with Breeze as fallback icons.

GNOME

For testing this, I installed the latest Fedora Workstation in a VM. I have done no user configuration beside what the installer and initial setup wizard asked and then just installed the Kate package. The shell was even helpful to ask to do that after you just tried to start the not installed Kate.

Most icons not there, not that nice. For details about that read this post, we don’t need to re-iterate this again.

If you think: that is just Kate, let us just try Okular.

One thing that can be at least solved easily is that the icons are gone, we just install the Breeze icon set as package.

Looks ok, system icons intermixed with Breeze as fallback icons just like on Haiku. Not stylish but usable.

I was unable to trigger Kate or Okular to adjust to the dark mode GNOME provides, therefore I can not test if we end up with black on black icons there, but it is likely, as the fallback is just Breeze.

MATE

Kate and Dolphin 24.02 on MATE with dark mode on NixOS, normal system packages, Breeze icons is installed.

System icons intermixed with Breeze as fallback icons, looks not that nice. Breeze icons not readable, as recoloring is not working.

Xfce

Kate and Dolphin 24.02 on Xfce with dark mode on NixOS, normal system packages, Breeze icons is installed.

Same mix and unreadable state as on MATE.

Enlightenment

Kate 24.02 on Enlightenment with dark mode on NixOS, normal system packages, Breeze icons is installed.

Just unreadable icons, beside out own Git icon and the few colored ones.

Summary: What’s up with Icons today

The icons in KDE applications do look perfect on KDE Plasma. That should be no real surprise as many people working on these applications will test them there and KDE Frameworks and Qt are well tested on Plasma, too.

The icons look fine on Windows and macOS, too, at least for applications that got properly ported, but only thanks to patches we do in Craft. If you just grab e.g. Kate’s and the needed frameworks sources from our normal repositories, you don’t get that.

If the maintainers of the port for some OS do care, like the Haiku people, KDE applications can look fine there.

On other desktop environments it doesn’t look that great out of the box.

Unlike for the other operating systems, there the same packages without extra patches are running.

Whereas that works perfect on Plasma, we rely too much that the desktop environment running provides an icon set that has a similar coverage and naming as Breeze. As we don’t hard depend on the Breeze icons for our applications, it can even happen that just no fitting icons are there per default.

Even if that can be solved with some better package dependencies, you still end up with a patchwork look and without a Qt platform theme plugin that handles the needed recoloring to make dark mode feasible.

Getting it fixed

Fortunately, just because the status quo is not that nice, it must not stay that way.

We have more or less all needed parts to fix the situation, we did already fix it during the porting to Windows and macOS.

We just never pushed to get this stuff done on Linux and Co.

How did we solve it there?

• We have the Breeze icon set as Qt resource inside a library and link with that. That makes them a hard build and runtime dependency and easy to deploy.
• We ensure the icon engine we have in our KIconThemes framework is there and used.
• We enforce the Breeze Qt style. (this is not really icon related, but ensures an usable look’n’feel, too)

The first and the last thing are easy to do on Linux and Co., too, even with still allowing the user to override the icon set and style, but still defaulting to Breeze.

The second point is harder, as that requires at the moment a few hacks and is not 100% as good as going the Qt platform theme plugin route we use inside Plasma.

For KDE Frameworks 6.3 we worked to get that done.

See our meta issue on our GitLab instance covering that topic.

All is not perfect, we will need to get some Qt API to fully do that, but the current state is already usable.

Here a comparison with the state as we have it now in our released software compared to with the state in the current master branch on an Cinnamon desktop.

The left side is the current Kate 24.02, the right side the current master build of Kate with master Frameworks.

The hard dependency to the Breeze icon library is done in KIconThemes, if you link to that, you are guaranteed that you have Breeze icons. You can naturally just link to only the Breeze icon library on your own.

The ensuring that the proper icon engine is done with some new API in KIconThemes that application developers must opt-in for. The same for the Qt style setup, there we have API in KConfigWidgets.

For Kate the concrete changes can be found here. They are minimal and even remove some platform specific code for the style setup.

Including fallback code for pre 6.3 Frameworks compatibility of the style setting, the basic idea is:

#include <KIconTheme>

#define HAVE_STYLE_MANAGER __has_include(<KStyleManager>)
#if HAVE_STYLE_MANAGER
#include <KStyleManager>
#endif

int main(...)
{
    /**
     * trigger initialisation of proper icon theme
     */
#if KICONTHEMES_VERSION >= QT_VERSION_CHECK(6, 3, 0)
    KIconTheme::initTheme();
#endif

    QApplication yourAppInstance(...);

#if HAVE_STYLE_MANAGER
    /**
     * trigger initialisation of proper application style
     */
    KStyleManager::initStyle();
#else
    /**
     * For Windows and macOS: use Breeze if available
     * Of all tested styles that works the best for us
     */
#if defined(Q_OS_MACOS) || defined(Q_OS_WIN)
    QApplication::setStyle(QStringLiteral("breeze"));
#endif
#endif

    ...
}

In the long run, once 6.3 is the minimal version the application depends on, this is just:

#include <KIconTheme>
#include <KStyleManager>

int main(...)
{
    /**
     * trigger initialisation of proper icon theme
     */
    KIconTheme::initTheme();

    QApplication yourAppInstance(...);

    /**
     * trigger initialisation of proper application style
     */
    KStyleManager::initStyle();

    ...
}

At the moment KIconTheme::initTheme() is still a bit hacky until we have proper Qt API, but that is not visible for the API user.

If we get this properly done in our applications, that will not just solve the current issue for running them in other desktop environments.

With that API in use and the now already upstreamed patches, one can build vanilla Frameworks and Kate on Windows and macOS and the icons will just work in the resulting application bundles and you get an usable style out of the box if Breeze is there.

Help Wanted!

We have now some API to help our applications to be more usable on non-Plasma installations and Windows and macOS.

We still need to make use of it and we need to improve the implementation and upstream to Qt the needed extra API to make it a real 100% replacement to what we do with the Plasma integration plugin.

If you have time to help us, show up on our meta issue.

Not just coding is needed, we for example have still a few icons that don’t recolor well, help to fix that is wanted, too.

Feedback

You can provide feedback on the matching KDE Social or reddit post.

Linux & BSDs

Windows

macOS

State on Fedora 40 Workstation & XFCE Spin…

Screenshots taken from the GNOME bugtracker, copies to not stall their GitLab instance.

I think that is rather unpleasant and for e.g. the left icon-only border just an unusable insult.

Why? The Adwaita Icon Theme no longer follows the FDO icon naming spec

There was no information that they want to break away from the icon naming ’the world’ does assume (given there is a spec). And now we have that state for our users there, at least on these spins.

That is not that nice, we did spend a lot of work to get our applications working cross-desktop and even cross-platform and now that…

I feel rather infuriated, finding this before going to sleep, even more after reading the feedback in the GNOME bugtracker and that this is just closed as ‘so be it’.

They added now at least a hint to the README:

Private UI icon set for GNOME core apps.

Ok, I assume that is then all fine.

No, it is not.

Then please don’t install it as FDO icon theme and break all FOSS apps that rely on the naming spec…

If you care for non ‘GNOME core apps’ to work per default properly on distributions like that, please either get them to fix it (hints are given in the linked issue) or get the distributions to install a compliant theme.

We can plan to work around this mess in the future on our side, but that will not un-break the application versions that are now already shipped to our users and non-KDE frameworks based stuff that will just run into the same issues.

Feedback

You can provide feedback on the matching KDE Social, reddit or Hacker News post.

All Unix like systems with either X11 or Wayland are well supported since ever.

Linux with X11 and now Wayland is for a long time the primary system on that Kate work happens.

Over the years it was, like most of the KDE applications, ported to various BSD variants.

Be it some mainstream Linux distribution like Fedora or a niche one like NixOS, Kate is available as binary package. You love BSD? From FreeBSD to OpenBSD, you can get a Kate package via your normal package system.

And in the normal case, you can just build it from source on your own, all needed patches should be in our repositories upstream. If that is not the case for your system, please help to upstream them.

Below the current state of the master branch compiled on NixOS unstable with Wayland.

How to compile Kate on your own on a Unix like system and start to help to develop it can be found out here.

Windows

Since several years there are activities in the KDE community to provide our libraries and applications for Windows.

Even if that is a non-free platform, we can reach out to new users and developers that might later be then even interested to switch a full open platform.

Progress is slow, but steady. We have Kate and some other applications in the official Windows Store and nightly build for more of them. With reasonable effort you can develop Kate on Windows with Craft.

Below the current state of the master branch running on Windows 11 inside VirtualBox.

If you like to try that, use the nighly installer linked on the Kate website.

macOS

Beside Windows, the major other non-free platform Kate tries to support is macOS.

We have nighly build available for that and you can, like on Windows, develop Kate with the help of Craft.

Below the current state of the master branch running native on my M2 ARM Mac Mini.

Same as for Windows, if you like to try that, use the nighly installer for either ARM or Intel Macs linked on the Kate website.

Other Platforms

Naturally there are more than the above mentioned operating systems around.

Beside the mobile ones like Android and iOS that are not that interesting for Kate, many other desktop operating systems exist.

Even if the Kate team itself doesn’t put active work it them, that doesn’t mean Kate can’t run there.

Without any active work on our side, for example a Kate port for Haiku was done. Some one-liner patches for that got even upstreamed.

If you work on some port of our stuff and need to upstream stuff, please contact us. Even if you work on a non-mainstream system, as long as the patches are not too intrusive, we are interested to have them.

Help us!

Naturally the most of our developers are working on the Linux or some BSD.

That means the other systems are always in need of more people to help out, both on the programming and testing side.

For Kate, testing should be easy, grab a nighly build for Windows or macOS on the Kate website. Or even better, get Craft running, that will make it easier to contribute, too.

One recent topic that needs love is the removal of DBus for Windows/macOS/Android and other systems that don’t use it normally.

If you are up to help with that, here that is coordinated. The current state is already sufficient that the nightly builds of Kate no longer hang on e.g. macOS, but still some frameworks like KIO will need more work.

Just don’t get that wrong, DBus is great on the Linux or BSD systems that use it natively, but it is a pain on systems that have no notion of DBus and leads there to hangs or the spawning of unwanted processes. Beside that, the usefulness is low there, as there are no services on the bus to communicate with anyways.

Feedback

You can provide feedback on the matching KDE Social, reddit or Hacker News post.

Already many things including Plasma and several applications, like Kate, have working KF6 based development versions.

KDE contributors did meet this week online for planning the final release time-frames.

We came up with this current plan:

Frameworks / Plasma/ Gear Release Schedule Plan

Following on from the last Akademy we checked where we were with our development progress in a meeting and settled on the following plan for all 3 major parts:

• In KDE Gear master will be open for Qt6 code to land for those ready to move. Not all apps need to port.

• The KDE Gear release will move by 2 months to allow for the extra time needed for testing initial Qt6 changes

• An Alpha will be made in November (a soft freeze in Plasma terms)

• Betas/RCs will be made throughout December and January (3 releases, 3 weeks apart)

• Final release of all 3 major parts in sync in February

Due to the delay of KDE Gear by an additional patch release of 23.08 will be made.

This is still up for discussion, but if no objections come up, we will see a triple release of a first stable KF6, KF6 based Plasma and KF6 based Gear next February.

There is still a lot to do, help is welcome!

Over the past two years I tried out a few different keyboards for fun.

I started with common form factors like TKL boards, went over 75% boards like the Q1 and then to a 60% HHKB.

For typing feel, the HHKB is really amazing, but unfortunately the programmable features of a stock HHKB board are very limited.

Now that I went down to 60%, I will give a more extreme keyboard a chance, the 40% Planck ortholinear keyboard.

This one is fully open-source, you can even produce your own PCBs and Co. You find more or less all stuff freely at GitHub.

Given that the Plank designer funded QMK, too, naturally you can fully customize the Planck boards.

Unlike for my tries with the Q1, this time I just went the plain QMK route, without any UI like the closed VIA or the open VIAL.

The Planck board offers a nice platform for experiments, given the plain grid layer that allows really to freely shuffle all your keys and experiment with extreme layouts.

Install QMK on NixOS

As I use at the moment NixOS at home, here the needed steps to get going with QMK on that distribution.

Install the qmk package. This will install the needed cross compile tool chains, too.

Ensure the udev rules are setup, e.g. add to your configuration.nix

services.udev.packages = [ pkgs.qmk-udev-rules ];

Run qmk setup, here with some own firmware location

qmk setup -H ~/install/qmk/firmware

Configure QMK to use the Planck as default

qmk config user.keyboard=planck/rev6_drop

Use my github name as keymap name

qmk config user.keymap=christoph-cullmann

Create own keymap based on default

qmk new-keymap

Compile the firmware

qmk compile

Put the keyboard in boot loader mode (e.g. trigger RESET)

Flash the firmware

qmk flash

Now the keyboard should auto-restart with the new firmware.

Have fun :)

Below the state of a finalized Planck board with some more or less standard first layer layout.

It even plays a nice startup sound on powering up.

My current keymap can be found here.

As the history of this repository shows, I already experimented if some different layouts.

Warning ^^

Yes, the paper on the left of the keyboard is a printout of the lower & raise keyboard layers.

My typing speed is still abysmal on that new layout and I guess I need to build as second one for at work, otherwise I will never get used to the layout if I swap daily between this and a HHKB.

Therefore, if you like to try such a board and are not a lot more experienced with switching between different layouts: you will need some time to get used to this.

Even just the removed row staggering is confusing the first few days.

In my Keyboard Fun post from last year I talked a bit about my interest in mechanical keyboards.

Since then, I played around with a few more keyboards/switches/keycaps/…

Interesting enough, beside the actual hardware, naturally there is some software component to all these keyboards, too.

Whereas most commercial keyboards still come with proprietary firmware, there is the trend within the keyboard enthusiast scene to go for open-source firmware.

This allows you to properly update the firmware even from your Linux machine and do proper configuration of e.g. the keymap, too.

QMK Firmware

A popular project in that area is QMK.

I supports a mass of keyboards out of the box already and is actively extended by both volunteers and some companies.

That means it is deployed not only on main stream products but even in more exotic projects like the “I improve my vintage and modern Model M keyboards” by Eric S. Raymond.

VIA

Whereas QMK provides the open-source firmware part and you can do close to everything with it that is possible, given the features your hardware actually has, it is hard for simple task like “I want that my key x does y”.

Naturally you can change the keymap in your QMK port and compile & flash. But even I would call this a sub-optimal workflow, given a lot of commercial offerings at least provide some GUI to do this on the fly.

Here VIA comes into the picture.

For sure, it is an Electron based monster, but it provides a cross-platform UI for QMK based keyboards that allow on the fly configuration of at least the common things, like keymaps. And it provides trivial things like testing all your keys, which is not that unneeded, given I was too dumb to properly install all my hot-swap switches ;)

Actual Keyboard?

Naturally, after this talk about the software side, all this makes no sense without an actual keyboard using it.

As I use the German ISO layout for typing, I am more limited on product choices than e.g. people using the ANSI layout.

It is really frustrating that where ever you look for some cool keyboard project, in many cases no ISO variant is available. And yes, I don’t want to switch to ANSI, I like to have my umlauts easily accessible and I can’t swap all keyboards I need to use at work with ANSI variants, others would be not amused.

Therefore, if you are in need of some ISO layout keyboard, you might be interested in the information below. If you use ANSI, ignore all this, there are masses of ANSI keyboards out there to buy, with QMK, too. I have done no great research how the keyboard I did choose compares to them, for ISO there were not that many available contenders that were 75%, hot-swap and QMK ready.

After some trial and error I went with a Keychron Q1 75% keyboard. It is available in ISO layout, unfortunately only as bare bone kit, that means you must buy your own switches and keycaps. It naturally comes already with factory installed QMK, nice, above the VIA screenshot was actually from this board on my Linux machine.

For switches, I went with some BOX Navy switches, they are very heavy but have a nice click ;) Even my office neighbor is happy with the sound and hasn’t yet attacked me. I won’t link random reviews of them, you can search for that yourself if you are interested. In any case, yes, they are HEAVY, really, you can believe that from the reviews. And they are loud, but in no bad way.

For keycaps, yeah, same issue with the German ISO layout, there are not many sets that are available.

At work I now have some SA profile set from Signature Plastics, they are able to produce sets with proper legends and no missing German keys, unlike some other vendors I tried (and yes, I tried it with cheap vendors, it seems not to be trivial at all print all the proper German keys at all and not just forget them in the package…). Funny enough, shipping from US did take 4 weeks, even with air express, USPS seems to be not the fasted variant of travel. If others play with the idea to buy there, I must confess the quality is really good, but they are expensive, if you don’t require exotic layouts like German, I would rather go with some cheaper sets, for US ANSI even the cheapest I tried out were ok, without obvious faults.

If you look a bit more around on the picture you will see I have still my good old Nokia rubber ducky, a sole survivor from the time Nokia owned Qt :P And no, I don’t use a Mac, that is just one we use for our compile farm.

At home I went with some MT3 profile set without any legends, that is really cheap and funny enough did take only 4 days from US to Germany with standard UPS.

:=) And no, no second Nokia ducky at home.

So far, the Q1 works nicely, both at work and at home. Having the exact same layout and switches in both places really helps to get used to it.

Using VIA works nicely, too. So far I have not flashed any updated QMK version, therefore no experience how well that works in practice.

I actually even learned a bit more about my use of the different keys. On the work picture you still see on the right the page up/down buttons (with Fn key => home/end). At home I already reprogrammed that to home/end (with Fn key => page up/down), as I use that far more often during editing whereas the page up/down stuff just rarely in the terminal. Actually, I didn’t know I would miss these two keys until they were no longer easy accessible ;=)

Since years Wayland based compositors are promoted as the successors to the venerable X.org X11 display server.

In the embedded space it seems Wayland already has made a lot of progress and some distributions start to use it per default, too.

My experience of the past years

I tried Wayland over the last few years multiple times, but I most often needed to go back to X11 due to random crashes/displaying issues/… (independent of the compositor, I tried a few). I just had always bad luck with the drivers and Wayland. On top of that came issues in the remaining stack, too.

Unfortunately, as long as my setup didn’t run Wayland at all in any stable way, I didn’t really spend a lot of time to actually debug/fix issues even in Kate or KTextEditor. It’s just easier to scratch your own itch then to invest time in stuff you not use yourself at all.

My experience end of 2021

Two months ago, I tried Wayland once more on my Arch Linux machine after some short journey to FreeBSD ;)

And great, it worked out of the box. Not random crashing of the compositor, no strange fractals on my second screen, all fine.

Now that I can use KDE Plasma & Kate on my normal machine on Wayland every day, I started to get more drive to take a look at remaining Wayland issues.

Aleix Pol Gonzalez & David Edmundson did a fantastic job to help out with remaining issues.

Naturally, not all is perfect for Kate on Wayland, e.g. you still get with each start some

qt.qpa.wayland: Wayland does not support QWindow::requestActivate()

indicating not all kinds of window activation work as intended at the moment.

But the 21.12 release of Kate should at least have the most obvious issues fixed.

I use now the KDE Plasma Wayland session as my daily driver since two months without any large issues. I not once had a compositor crash nor any strange displaying issues.

As mentioned above, still small issues remain to be fixed for Kate (and for sure for other applications, too).

But beside Chromium & Wine (even sandboxed as extra user) that still run via XWayland all other parts run native.

Thanks to all people that worked on this to make it happen. I really was impressed after I gave Wayland a try again how well all parts nowadays work together. Let’s continue to improve that in the next years even more!

My current KDE Plasma on Wayland session ;=)

Even Wine based gaming in parallel to coding is possible, awesome!

Try it out!

I can encourage all to give Wayland a try, if you are on some up-to-date distribution like Arch Linux. At least on my mid-class AMD graphics card Wayland works flawless with the open-source driver. Naturally the experience can differ for other setups, like it did for me in the past.

Help out!

If you encounter issues, please report them as bug reports to the respective upstream projects. And naturally, any help in fixing them would be welcome, too. For Kate/KTextEditor I might be able to at least reproduce and try to fix them now myself, given I use it now daily, thought other projects might rely more on external contributors to get the rough edges fledged out.

Feedback

You can provide feedback on the matching Reddit post.

I never used WhatsApp as I try to stay away from the Facebook/Meta/… ecosystem.

Telegram seemed like a good choice as a lot of people I know are there and we e.g. mirror our KDE channels often to Telegram for better outreach, too. And all old messengers like ICQ more or less were abandoned by everybody I know including myself ;=)

Unfortunately, during the current pandemic, I met more and more people that went down into the rabbit hole thanks to totally uncontrolled Telegram groups.

Yes, you can say: this is free speech.

It is.

But on the other side, I think it can’t really be tolerated that people start to live in some parallel universe that completely ignores any science/laws/facts of the real world.

Telegram isn’t interested in even deleting the most obvious lies or hate speech that is spread in masses there. Most other platforms at least try to do so. At least this is the impression I came to in the last few months.

I talked with people in person that live in such state of denial and I can’t any longer use some application/network/service that encourages the spreading of such stuff.

Therefore I abandoned my Telegram account this week.

If you want to stay in touch with me via some messenger and not plain good e-mail, I use Signal now, at least this seems to be not as awful as Telegram looks for me now.

My Signal account is: +49 176 235 467 98

I will participate in the KDE & Kate related channels via Matrix, e.g. thanks to NeoChat and other free clients ;=) Should have started to use that since long anyways, after I somehow went away from IRC years ago.

Therefore, if you fail to contact me via Telegram, that is no accident, that is intended, sorry if that might be inconvenient.

In the recent past, I started to get more interested in the quality of the keyboards I use at work and home. I always hated to use very cheap low-profile boards, but otherwise I more or less always worked with what came stock with my PC in the good old times ;)

TKL boards

A longer time ago I bought some Xtrfy K4 TKL White Edition keyboard, my first keyboard that had no numbers block. I liked it a lot and the red switches were ok for my taste. Thought I didn’t like the keycaps, they feel cheap.

Some weeks ago, I bought the Varmilo Moonlight VA88M, a TKL keyboard with nicer keycaps (both in material and design). I now used it at home for some weeks and the brown switches are fine, keycaps are fantastic, Cherry profile PBT keycaps are really nifty.

But…. The ping… Especially in the middle of the keyboard, each and every key pings. Actually you can get the ping even if you just tap a bit on the backside of the board itself, seems to be no sole switch issue :/

Removing the ping?

All reviews I read didn’t tell a thing about any ugly ping with the stock Varmilo board. Though most reviews naturally did look at the ANSI variant, but I bought the ISO one, given I like the German layout. Perhaps they just altered something in the more recent fabrication, who knows.

I did take some look at the internals of the keyboard to see if some more dampening or taping could help.

See the disassembly and later playing around with stuff and tape below.

Short answer: it didn’t help. You can even stuff the lower parts totally with “anything”, given you screw all things together later it will still ping. Even alone the upper plate does ping if you tick it without any extra parts. I found no way to stabilize it in a way that removes that.

Btw., hint for anyone trying this: Yes, there is some stupid screw below some white seal at the bottom ;) Unlike the one screw that is missing on the top, there is one…

For flexing the case open, even if you are too dumb to remove all screws, my nice old BahnCard and credit cards did help a lot ;=)

The solution?

Now, given I just use one PC, I had one keyboard that has no ugly sounds and is ok, and one keyboard that has really fantastic keycaps and is borked.

Solution? Create one out of both.

Given the red switches and the typing on the Xtrfy board was nice, why not just use the Varmilo keycaps for it?

Varmilo was nice enough to include a keycaps puller anyways, already used for the total disassembly above.

End result

I think the final “product” looks nice. The RGB back-lighting still works, though the new keycaps are not shine-through.

In addition I have now a full shine-through ABS keycaps set as backup parts for more keyboard modding. And some more or less useless Varmilo baseboard. But who knows, if I spill too much coffee or whatever in my board, I can still re-build the Varmilo board to have something that works (and pings).

Naturally that was not the way I meant to use the new keyboard, but good enough ;) And I must confess, a bit modding around on the keyboards was fun!

For any people interested in keyboards: I think both boards mentioned above are ok. Perhaps I just was unlucky with my Varmilo board and other builds of it don’t ping at all, like the most reviews tell.

After two weeks of use, I have now first experiences on the way the incremental backups perform and some additional information how I apply this to backup a virtual FreeBSD server hosting some of my stuff.

Incremental Backup Performance ;=)

I must confess, I am positively impressed.

As told before, my duplicity setup did have a very bad performance (even just in the locally to my NAS). Perhaps I did something wrong, on the other side, I followed the default way as described to setup a encrypted backup.

On the other side, the new BorgBackup powered variant performs well locally (with 1 GBit networking) and remotely (with just between 25-50 MBit upload).

Instead of multi-hours to sync, the new variant runs in minutes.

Naturally, for larger increments, the upload is the restricting part here, this means for the remote backup, some minutes upload are added on top.

Let’s see what happens if I backup my data again after I bought some music album online and the usual stuff that happens in a day:

Time (start): Fri, 2021-09-10 20:38:39
Time (end):   Fri, 2021-09-10 20:39:19
Duration: 40.65 seconds
Number of files: 68984
Utilization of max. archive size: 0%
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
This archive:              256.50 GB            249.26 GB            405.36 MB
All archives:                1.82 TB              1.77 TB            240.18 GB

                       Unique chunks         Total chunks
Chunk index:                  148438              1118042
------------------------------------------------------------------------------

Just the expected, more or less the size of my new album + a bit more given other minor things in my home did change, like this blog post ;=)

More or less the same happens for my remote increment:

Time (start): Fri, 2021-09-10 20:38:32
Time (end):   Fri, 2021-09-10 20:40:52
Duration: 2 minutes 20.11 seconds
Number of files: 68984
Utilization of max. archive size: 0%
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
This archive:              256.50 GB            249.26 GB            405.32 MB
All archives:                2.38 TB              2.32 TB            240.41 GB

                       Unique chunks         Total chunks
Chunk index:                  148994              1454388
------------------------------------------------------------------------------

The backup time is more or less just the local network backup time + the extra time you need for the poor 25-50 MBit upload speed.

This looks reasonable and allows to run this daily via cron or other means without large impact on my local machine.

I have already a few increments online, e.g. for roughly each second day (the data varies here on the remotes, not all have the exactly same backups). Still the combined archives size on both remotes is below the actual size of the raw data I backup.

The Zstandard compression I did choose for the backup has a small impact, most of my stuff is already either compressed or likely not that well suites for further compression. But BorgBackup was able to de-duplicate already in the initial backup a few things that are redundant in my home, like duplicated albums I have by accident in different folders. Good hints what to cleanup if I need again disk space ;=)

Full FreeBSD server backup

I own some virtual FreeBSD server to host various things. I backup that server to a pure backup server without any other services regularly.

Below is the setup to do this via rsync & BorgBackup in some hopefully both secure and usable way.

The below stuff runs as a plain old cronjob without any other fancy stuff around.

First step: Plain rsync

The basic backup is just a plain rsync of more or less all things.

rsync -alHSvh --no-specials --no-devices \
    --delete --force --stats \
    "root@my-cool-server:/" "/some-where/my-backup"

Naturally on the server we pull our backups from, some stuff like databases are dumped to the local disk via cron before this rsync run, to have some consistent data and not relying on good luck that e.g. the database that way on disk during this sync was consistent (that will most likely not be the case).

Using this method, on the actual server, you have no way to get access to the backup server. The backup server will just pull all stuff via rsync. Even if somebody breaks into the actual server running my services, getting to the backup server will still be as hard as without any access to the first server.

If you like to copy this, keep in mind: the above rsync call will rsync all mounted file systems. This is useful for me, as e.g. the FreeBSD machine has ZFS with a bunch of individual mount points (like the standard FreeBSD ZFS setup) and I really just want to have everything.

Second step: History via BorgBackup

This rsync method is easy and fast, but it provides no history. As this sync runs nightly, if I ever delete e.g. some mail on my server by accident and not notice that before the nightly deadline => all hope (and the mail) is lost!

A nice solution for this is to use BorgBackup to backup your synced files once more into a local repository.

This might sound a bit strange, why not just use BorgBackup directly, but it has a few benefits:

• The normal BorgBackup way will need access to the backup server from the server you backup => Once you capture the server, you might be able to do evil things on the backup server or at least mess with the backups.
• There are ways to pull via BorgBackup, but they are complicated and still will rely on BorgBackup to have no exploitable holes, I trust rsync more in that regard (but you can still try the described pull variants if you are less paranoid).
• You have a plain 1:1 copy always available, in the case BorgBackup really screws up. If you have the space for that one copy, I think that extra safety is nice.

Initial preparation of the repository

You need to create once the repository. I use for that no encryption, I have anyways my not encrypted rsync copy on the same backup machine:

borg init --encryption=authenticated "/some-where/my-backup.borg"

The documentation recommends the “authenticated” variant to avoid issues with malicious input data. Given a bit more hashing won’t hurt as I will use compression, too, I just went with that recommendation (without a passphrase). If you like to skip that, use “none”. But better read the documentation yourself.

Create increment after rsync

After each daily rsync, just create a new increment via:

borg create --compression zstd --stats \
    "/some-where/my-backup.borg::{now:%Y-%m-%d}" \
    "/some-where/my-backup"

And that’s it ;=)

Performance

The initial BorgBackup run is slow (single core machine), but the compression actually make at least some visible difference on my server data, not just the de-duplication:

Time (start): Fri, 2021-09-10 21:21:35
Time (end):   Fri, 2021-09-10 22:02:00
Duration: 40 minutes 25.12 seconds
Number of files: 259439
Utilization of max. archive size: 0%
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
This archive:               56.48 GB             45.17 GB             40.61 GB
All archives:               56.48 GB             45.17 GB             40.61 GB

                       Unique chunks         Total chunks
Chunk index:                  252076               278721
------------------------------------------------------------------------------

An increment is a much faster thing, just like for my normal backup:

Time (start): Fri, 2021-09-10 22:16:36
Time (end):   Fri, 2021-09-10 22:19:36
Duration: 2 minutes 59.12 seconds
Number of files: 259624
Utilization of max. archive size: 0%
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
This archive:               56.51 GB             45.18 GB             46.81 MB
All archives:              112.99 GB             90.35 GB             40.66 GB

                       Unique chunks         Total chunks
Chunk index:                  252551               557639
------------------------------------------------------------------------------

Btw., the rsync received size was ~76 MB for the above run, BorgBackup did break this down to just 46 MB for the increment, not that bad.

And just 3 minutes more for the nightly run in addition to the plain rsync, I would say nicely usable even on my single core machine.

Conclusion

As shown above, I think BorgBackup performs well for my use case.

The increments are reasonable small and fast, seems to be no issue to have daily ones.

Naturally, one will later start to expire older backups, I will need to read up more about this in the future, I just skimmed through that parts of the documentation so far.

At least for my personal data and server backup, this seems to be now a rather nice setup.

I hope this is helpful for others, too, but please always do your own research. There are plenty of other open-source backup tools out there, perhaps they fit your requirements better.

But at least from my side: thanks to the BorgBackup developers to provide the world with such an useful piece of software!

At least my backup setup got successfully assimilated .P

My old way of doing backups: rsync & duplicity

So far, I did my backup on my Unix machines by using rsync to a second host and duplicity to archive stuff on my old Synology NAS.

Plain rsync?

Naturally, the rsync method (if you don’t do snapshots/…) is just a 1:1 mirror. If you do by accident delete stuff and don’t notice it, you just will wipe it on the next sync, too, if you don’t do some dry-run first to inspect.

But so far, in the normal case, the rsync copy was always what I used to get my data back after I did really break my system.

It’s the fastest way to migrate from one operating system to another for me, too, without any fear that you might wipe your data disk. It helped my nicely on me journey between different Linux distributions to FreeBSD.

Duplicity?

I started to use duplicity after I did introduce disk encryption at home for all machines years ago.

Given my old NAS has no such concept, duplicity with client side encryption did seem to nicely solve that hole in my data security concept.

Naturally, duplicity allows the normal full/incremental/… backup scheme, that will let you retrieve even older stuff if you by accident deleted stuff locally.

But I never was completely happy with duplicity. Combined with my old slow NAS, the backup process was always a very slow thing and the progress indication actually never worked properly for me. I had just for hours some unknown estimated time and no real feedback. Given I normally don’t let my workstation just run the whole day, that was not that satisfying.

On the other side, so far, restoring did work, which is a good thing ;=) And, like most good open source projects, it works properly on different platforms. I could easily continue to use the same backup destination after switching from Manjaro to FreeBSD, no problem at all. duplicity is just nicely installable via pkg there, too!

The future: BorgBackup?

I investigated a bit more what I could use as duplicity replacement, and ended up giving BorgBackup a try.

The documentation is a nice starting point, beside that, you find plenty of useful tutorial online.

On Linux or FreeBSD some usable BorgBackup version is available with the usual package managers. In my case I am using the version available on FreeBSD 13 via “pkg install py38-borgbackup”.

BorgBackup & Synology

For me, the primary backup target is my old Synology NAS.

Fortunately, you can install BorgBackup on the NAS itself via the package center if you add SynoCommunity as an additional source. There you will find the “Borg” package in a reasonable fresh version. No need to fiddle around with the internals of the Synology distribution on your own.

I then activated ssh access & enabled the home directory service to be able to add some authorized_keys & have my backup repository in the home.

Cloud backup

Given I now start to setup my backup from scratch anyways, I decided to fix a second issue: All my backups are in my flat ;=)

Given either “fire, fire” or “we steal just all stuff, even your crappy NAS”, perhaps nobody might really access my data even if stolen, still I could easily loose it all.

As BorgBackup like duplicity works nicely over ssh, no reason not to use it to push all the data encrypted to some random virtual server somewhere.

There are several companies that even promote their BorgBackup compatibility. But I will not start to promote here cloud/virtual server hosting companies, your search machine will tell you what is available.

BorgBackup repository initialization

I recommend their quick start documentation for the initial setup.

For me, it was e.g. for the NAS (see the –remote-path to let it find the borg binary on the Synology):

borg init --remote-path /usr/local/bin/borg \
    --encryption=repokey thecooluser@nas-name-here:borg

and for the cloud server:

borg init --encryption=repokey \
    thecooluser@server-name-here:borg

That command will query some passphrase, use a good one, that is the sole protection of your data. And keep it somewhere you have it, even in the “fire, fire” case ;=)

BorgBackup usage

After you did initialize the repositories like above, you will have on your NAS and/or server some borg directory in the home of the matching user.

You can create a new backup archive of e.g. your home (excluding the .cache directory you might not want) via:

borg create --compression zstd --progress --stats \
    -e "/home/your-user/.cache" \
    "thecooluser@server-name-here:borg::name-of-backup-archive" \
    "/home/your-user"

On the NAS you will need an additional “–remote-path /usr/local/bin/borg” like for the init command.

Does this work?

So far it seems so, but time must tell. As with any backup solution, I will need to test restore again and again and must see how the incremental backups work in practice over time. At least the initial full backup seems to work more fluent than I was used with duplicity.

Naturally, BorgBackup had already bugs in the past and for sure still has some. The cryptography isn’t perfect either, on the other side, I want to protect my personal data against the normal thief, not some government agency.

Shall I use that?

If this post did spark your interest to try this, please do your own research if it really fits your bill. In any case, I still have a plain rsync copy around on a second machine, just in case it doesn’t work like expected. Not that I again loose a decade of flame war mails .-)

The KDE e.V. is for example responsible for paying the servers that run our GitLab instance and all our other web services. The e.V. takes care of sponsoring developer sprints and contributor travel costs, too.

You did participate at some Akademy? This wouldn’t have been possible without the KDE e.V., both by sponsoring and helping to organize the event!

If you are an active KDE contributor, consider to join the e.V. to be able to vote on its future direction. This includes very important things like the KDE Free Qt Foundation.

At the moment, already a lot of our KDE community members are e.V. members, too.

But naturally, as people enter and leave our community, we need to outreach to new contributors to join the e.V.. The e.V. shall stay a representation of the currently active KDE contributors/community and not some club of KDE oldies =)

Just take a look at the 2002 e.V. meeting group photo below:

A few of this people are still active, some of them many of the current active KDE community members have never heard of. The group pictured above isn’t that diverse either. It looks a bit like you take a group photo of some computer science course in a university in Germany of that time. And yes, I am on that photo, too (as usual, wrongly written as Cullman, like my nice county). I actually fished that picture out of my private data storage .P

Let’s take a look at the Akademy 2020 group photo below (CC BY 4.0, created by the Akademy team):

This looks a lot more like the KDE community we all know and love. Therefore it would be fantastic if active people take care to join the e.V., too!

If you want to join, just take a short look at this guide.

You will need some e.V. member that suggests you, I assume you will know someone from the e.V. members list to ask to do so.

The CompCert install I tried uses the GNU/GCC toolchain for preprocessing and linking. That makes the compiler relatively compatible to a GCC, beside that not all command line options are supported.

I was used to CMake projects and there it is normally enough to just set CC=ccomp and you are ready and set (at least if you use the GNU/GCC toolchain). As long as you don’t use special flags in your project, that will just work.

The Picolibc was the first Meson based project I encountered.

There setting CC to ccomp just leads to

 meson.build:1:0: ERROR: Unknown compiler(s): [['ccomp']]

I did assume that the project won’t compile & link without adjustments, as CompCert doesn’t support the full range of command line options like GCC as mentioned above nor the full GNU extensions for C. But that it directly ends at the compiler initialization in the build system itself was astonishing.

I searched a bit in the internet and it seems, if I really want to get this working, I actually need to patch Meson itself :/ (see how to add a new compiler here)

At least I found no other solution, actually, I found no real solution for the above error message at all and the code looks like you need to manually add compilers anyways.

Given I want to spend work on getting the C library to compile and not fix a build system, it seems easier to go with the newlib that uses the old autotools, at least for them the compile starts at all with my CC environment variable and you get to places of interest to fix.

This means for my use case, with a non-standard compiler, I can not see how Meson is an improvement over other existing stuff like CMake or even autotools. But perhaps this area will improve in the future.

After some initial “not a lot works”, if you don’t go the Homebrew or MacPorts way, the Kate port improved over the following years.

I learned a lot about standalone non-Linux deployment of applications and macOS specifics in the process.

As a side-effect of my porting efforts, with the help of others, I was able to improve the deployment of KDE Frameworks in some ways, e.g. by allowing to bundle more stuff inside Qt resources.

For example the KSyntaxHighlighting or KTextEditor frameworks are now just a library you link, you don’t need to deploy any extra data files. This is a huge improvement, if you want to bundle them with your standalone application.

Unfortunately, my initial hope, that we would get more people contributing to the macOS port (and with this to KTextEditor/Kate/…) didn’t really take off.

Beside some minimal help, not a lot happened.

I think my last self-provided bundle update for macOS was in 2016.

The binary factory still churns out new builds, you can grab them via the links on our download page.

I occasionally tried them, but they never got polished in a way like our Windows variants that we now even ship via the Windows Store.

Apple doesn’t make the world a better place with each update of macOS, see for example the now necessary notarized builds and the effort the cause for e.g. Krita (and with necessary I mean: you shall do it, otherwise your users are nagged with “do you really want to execute this…” stuff that makes a very bad impression).

In the last years, I used my MacBook more or less just to either grab some stuff from iTunes or do stuff inside my Linux VirtualBox there.

Given I anyways have a proper Windows 10 VM to take care of the Windows development for Kate (yes, Apple, Microsoft allows that officially, you can just buy a license, you can even get some ‘free’ developer VM images for a fixed time…), I just migrated my seldom used iTunes account to that machine.

With that away, I just installed purely Manjaro Linux on my MacBook last evening, who cares, I anyways don’t use macOS at all beside as VirtualBox startup environment.

I searched for some pointers in the internet, in the past I already had some parallel install. If you search a bit, you will find various hints how to do it.

If people want to do the same as me, a pure Manjaro install without keeping any macOS around, here a minimal how-to for a MacBook Pro Retina 13" (model number MGX82**/A, model id MacBookPro11,1):

• Get the USB installer from their Manjaro Linux homepage, I used the KDE variant ;=)

• Get it on a stick and plug it into your MacBook

• Boot up your MacBook (pressing the ALT key)

• Select the EFI boot option.

• Start the live system, like on any other machine

• If you want to have internet, which is a good idea to e.g. later easily install the Broadcom driver, use your mobile phone with USB-tethering

• Install it normally, I used the “erase my full drive and encrypt it” variant. Be careful, your data is gone afterwards, you got warned!

• Reboot your MacBook, you will boot into your fresh installed Manjaro

• Install the matching Broadcom driver for your kernel, something like “linux54-broadcom-wl”

• Install some fan control like “mbpfan-git” and enable it afterwards with “sudo systemctl enable mbpfan” + “sudo systemctl start mbpfan”

For me this did the job and the stuff is running well enough. The webcam won’t work without additional effort, not that I use it. No idea if Bluetooth or other stuff like the Thunderbolt ports work, but I never used that even on macOS.

Fortunately the HiDPI support on Linux & Qt & KDE has gone a long way since my initial try 2015 and now, with some scaling of 1.5 or 2, it is all nicely usable ;=)

Given I still have some macOS machines available at work, I might still try out some Kate bundles there from time to time, but my personal life is now macOS free.

During some experimenting with the current master version of these libraries, I stumbled on unexpected crashes inside our unit-tests on Windows.

We work with MSVC 2019 on Windows and all worked fine with LLVM 9.x, but with master, close to all my tests did now segfault in aligned_free.

I first thought that might be some current regression in LLVM master, but after tracing it back to having DenseSet/Map crashing during destruction, this seemed unlikely.

On further investigation, the fault is really hilarious: We compiled the LLVM libraries with the default language standard as set there in the CMake tooling: C++14.

On the other side, we compiled our own tools that use these libraries with C++17.

Some months ago, the implementation of DenseMap got improved to use the allocate_buffer/deallocate_buffer functions to use (if possible) aligned allocation.

Unfortunately, this means, during the compilation of the library, the checks there ensure it doesn’t use these code paths, on the other side, during compilation of our tools, it does, as the allocation functions are fully inline in the header including the feature checks.

For operating systems != Windows, this doesn’t hurt that much, as you can use the normal free for stuff allocated with the aligned variants (and vice versa).

Unfortunately (or fortunately, to detect this screw-up), this doesn’t hold for the MSVC run-time on Windows.

If one uses a consistent C++ standard version for the compilation of the whole tool-chain, all is fine.

Therefore, if somebody stumbles on the same kind of crashes, perhaps this blog post can avoid some longer bug hunting.

A usual crash backtrace of such an error would look like:

0x00000000778ca12f - RtlFreeHeap
0x000007fef90ba8b0 - free_base
0x000007fef910ffe2 - aligned_free
0x0000000140113fa7 - llvm::TypeFinder::~TypeFinder

In the past, most displays had (or the OS pretended to have) around 96 PPI, more or less.

If you differed a bit and had too small/large UI elements, you mostly just resized your default font size a bit and were kind of happy.

In the last years, more and more displays arise that have a much higher PPI values, which allows for e.g. very crisp rendering of text.

I arrived late in that era for my Linux machines by now starting to use two 163 PPI displays.

Just tweaking your fonts doesn’t help here, all other things will still be unbearable small, even if you in addition increase e.g. icon sizes.

A solution for this is the current trend to just “scale” your UI by some factor, for my displays some factor of 1.5 leads to the most pleasant sizes.

How does Qt handle that?

A detailed description on how Qt does try to tackle the challenges of such displays can be found here.

More or less the gist of this is: In your application you work on logical pixels (in most cases) and Qt will do the hard work for you to then paint that in real pixels with the right scaling applied.

In practice, this isn’t fully transparent to the programmer. For example, as soon as you work with QPixmap, you will think a bit about where which pixel variant is used. You need to be careful to not mix-up the size() of a QPixmap 1:1 with let’s say layout/widget sizes in such scaled scenarios, see here.

Fine, nice, but what does that mean in practice?

Let’s take a look at how this works out in practice using the latest stable release of KDE & Qt stuff:

• KDE Plasma 5.16.5
• KDE Applications 19.08.1
• KDE Frameworks 5.62.0
• Qt 5.13.1

My setup for the below experiments are two 163 PPI displays with scale factor 1.5.

I use some Manjaro Linux with open-source AMD drivers for some average middle class card.

The screenshots are taken on my second screen. I used PNG to avoid that some JPEG artifacts make the real rendering artifacts unclear, bear with the large size.

Experiments on Kate & Konsole

Let’s show the current state with Kate & Konsole, here how Kate 19.08.1 looks if you start it on the second screen with default configuration with COPYING.LIB of ktexteditor.git as file:

This looks kind of strange. What you see is actually no split screen, even that is a pure rendering artifacts, actually, the whole Kate windows is more or less one artifacts.

A user reported this in Bug 411965 - Rendering issue in dual screen hidpi setup. With my new setup I was able to reproduce that, on every Kate start :/

The user himself investigated this and came to the same conclusion as me, the culprit is some winId() call in KonsolePart. As Kate constructs the KonsolePart widget without a parent first and then insert it into a layout, the code inside the part will call winId() on a non-native widget.

This is now fixed and backported to the 19.08 branch.

This means, with 19.08.2, you will have the following experience:

This somehow looks more like an actual working application.

For people not able to update, a workaround is to disable both project and terminal plugin in your Kate setup, no ideal solution, but makes Kate at least usable again.

Is now all fine with Kate? Unfortunately not, lets change my font size a bit and select things:

I selected both in the text view (KTextEditor) and in the KonsolePart to show the issue is not just a plain “we are too dumb to render things” in KTextEditor. You get equal artifacts with most of our software :(

I spend some time to trace this issues down in the QTBUG-66036 - QTextLayout draw() rendering issues with “some” font sizes.

It came up to not being a text related issue at all.

To give a small outline how KTextEditor and Konsole render stuff:

• All things are in pure integer coordinates inside the applications.
• More or less we render some uniform high lines of text.
• Most background/selection coloring is done via fillRect with integer coordinates/sizes in both KTextEditor/Konsole.
• KTextEditor paints parts of the text background via QTextLayout::setFormats.
• KTextEditor and Konsole rely in some parts on the clipping to avoid over-painting.

Given none of both rendering “engines” work anywhere with non-integer coordinates and sizes, the artifacts seems to be strange. They only occur with fractional scaling, e.g. with 1.5, not with e.g 2.0.

During debugging, three major issues that lead to the artifacts came up, I created separate bugs for them, as they are not text rendering related:

QTBUG-78964 - fillRect + Anti-Aliasing + hi-dpi Scaling => missing filled pixels

If you use fillRect, even for purely integer coordinates and sizes, if the scaling is fractional and you have the render hint “QPainter::Antialiasing” turned on, it will miss to fill one pixel at the border. For KTextEditor/Konsole mostly at the lower part of the filling. A workaround for this, now commited for KTextEditor framework and Konsole is to turn the anti-aliasing off for large parts of the rendering. Only the parts that actually need it, turn if on again, this doesn’t affect e.g. the text anti-aliasing.

QTBUG-78962 - setClipRect misbehavior for hi-dpi scaling with QRect overload vs. QRectF overload

KTextEditor uses setClipRect to avoid overpainting between individual lines. Unfortunately, like fillRect, setClipRect leads to one pixel being clipped away too early for fractional scaling. A workaround for this is to use the QRectF overload of setClipRect. Even thought the passed QRectF has the same pure-integer coordinates, this will avoid the clipping errors due to different internal handling. KTextEditor uses now this workaround.

QTBUG-78963 - Misbehavior of clipping done for ::paintEvent with hi-dpi fractional scaling

Even after all this fixed, Konsole still draws some artifacts. Konsole is more relying on paintEvent to clip correctly than KTextEditor. Unfortunately the internal clipping done for the paintEvent seems to have the same off-by-one rounding issues like the manual setClipRect for QRect instead of QRectF. As we can’t control this clipping region in Konsole, I see no easy workaround, beside more often trigger full widget updates, which are costly.

This leads to this current state of the rendering in the master branch. I did select + deselect a bit text in the terminal to trigger the paintEvent related clipping failure, you can see a few small one pixel high selection leftovers below the selection area. You need to play a bit with the scaling factor and font size, too, to trigger the effects, as like all rounding errors, you need specific values to trigger them.

I hope the Qt bugs linked above can be fixed in the near future, as I doubt we can add workaround to all the applications affected (nor do we want to) and the clipping issue of the paintEvent, if it really is the reason for the last remaining Konsole artifacts, seems not to be really fixable at all in the application code, beside going away from fine grained repaints.

Here are the matching KTextEditor and Konsole bug report for the above issues. The relevant Qt bugs are linked there again, too.

Are that all current issues? I assume not.

I think there are for sure more pitfalls hidden, if you use some fractional scaling and Qt & KDE applications. Some of our applications are even still horrible broken for any kind of scaling :(

We are open-source software, patches to improve the current situation are very welcome.

Perhaps you are able to fix one of the above Qt bugs, that would be great!

P.S. Floating point math is hard!

One thing that disturbed me during trying to get rid of the rendering artifacts, is the bit careless choice of scaling factors people use.

I can understand that you want to have things 20% larger, but unfortunately, a factor of 1.2 leads to rounding errors all over the place, as 1.2 is no the nice number it seems to be in the hardware double precision floats we use.

If you want to avoid running in bad artifacts more than needed, please better scale with some factor that is a nicely representable float, like some multiple of 1/16 or 1/32.

For example some scaling with 1.25 will lead to much less issues than 1.2.

For details, just read up about how stuff like 0.1 or 0.2 is represented ;=)

• Floating Point Arithmetic: Issues and Limitations
• Why 0.1 Does Not Exist In Floating-Point
• Binary Fractions

You can ignore that advice and scale like you want, but I won’t take care of the artifacts that remain for e.g. 1.1 scaling in some corner cases ;=)

Discussion

Feel free to join the discussion at the KDE reddit.

One of the new goals of KDE is to spread the use of the applications created by the KDE community. This doesn’t only include the use of them on Linux & other Unix-like operating systems, but Windows, too.

The Successes :)

The KDE community has some successfully cross-platform applications out there, like Krita and GCompris. The teams behind these applications did some great job to both develop & market them for all operating systems, including Windows.

The Remaining Stuff :(

Wheres many KDE application can already be built on Windows since years, they have not found a wide spread use there.

For example Kate, the text editor I maintain, is there mostly unknown. Actually most of the applications we ship with the KDE Applications releases are not widely known on Windows (nor used).

The Plan!

Already last year we came up with the task to bring more of our applications to the official Microsoft Store to increase their visibility for the average Windows user.

The Building Blocks

Hannah von Reth & Kevin Funk provided the means to achieve this:

• Craft - a meta build system / package manager that can be used on Windows for our stuff
• KDE Binary Factory - a CI that actually even creates fully signed installers and packages for the store!

Without their work, nothing would have happened for the “we publish stuff in the store” task.

More details about that can be found in the wiki and older blog posts:

• Using Craft on Windows
• Tips for streamlining KDE applications for deployment on Microsoft Windows
• CI for Windows installer and macOS bundle generation: KDE Binary Factory

Our Progress :=)

Based on that work, some applications got now published with the KDE e.V. account to the Microsoft Store. The first was KStars and after a long gap Kate & Okular followed.

Direct links to the store entries can be found below (the screenshots are in German, made in a Win10 VM, yes, i18n works on Windows just fine):

• Okular - more than a reader

• Kate - Advanced Text Editor

• KStars - Astronomy Software

Help Wanted!

At the moment, this is the effort of only a few people and it will only be sustainable if we gain more support.

Therefore, if you are interested in bringing more of our applications to Windows and helping to maintain them, join in at this Phabricator task.

The tooling might still be a bit rough to use in some places and the documentation is not perfect, but this can be improved!

Why all that?

I think there is a large user base on Windows that might benefit from our applications and we will benefit from potential more contributors, too.

Some might say: “Why shall we provide our applications on a proprietary operating system? People shall use fully open systems!”

I say: “Why shall we ignore all the people that are stuck with a proprietary operating system out of whatever reason?”

P.S.

And no, the idea is not to publish the stuff exclusively in the Microsoft Store.

The KDE Binary Factory outputs normal installers and portable archives, too.

The Microsoft Store is just a good way to advertise our applications to a broader scope of potential users. The KDE e.V. published applications are there available for free but you can use any other means to install them.

Feel free to join the discussion at the KDE reddit.

KDE e.V. is a registered non-profit organization that represents the KDE Community in legal and financial matters.

For example the KDE e.V. is responsible for paying the servers that run our Phabricator/Bugzilla/Gitlab instances and all our web sites. KDE e.V. takes care of sponsoring developer sprints and contributor travel costs, too.

If you are a KDE contributor, consider to join the e.V. to get some vote about its direction.

If you want to join, just take a short look at this guide.

For the basic question: What the heck is the Language Server Protocol (LSP), I think my first post can help. Or, for more details, just head over to the official what/why/… page.

But easier than to describe why it is nice, I can just show the stuff in action. Below is a video that shows the features that at the moment work with our master branch. It is shown using the build directory of Kate itself.

To get a usable build directory, I build my stuff locally with kdesrc-build, the only extra config I have in the global section of my .kdesrc-buildrc is:

cmake-options -DCMAKE_BUILD_TYPE=RelWithDebInfo -G “Kate - Unix Makefiles” -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

This will auto generate the needed .kateproject files for the Kate project plugin and the compile_commands.json for clangd (the LSP server for C/C++ the plugin uses).

If you manually build your stuff with cmake, you can just add the

-G “Kate - Unix Makefiles” -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

parts to your cmake call. If you use ninja and not make, just use

-G “Kate - Ninja” -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

Then, let’s see what you can do, once you are in a prepared build directory and have a master version of Kate in your PATH.

I hope the quality is acceptable, that is my first try in a long time to do some screen-cast ;)

As you can see, this is already in an usable state at least for C/C++ in combination with clangd.

For details how to build Kate master with it’s plugins, please take a look at this guide.

If you want to start to hack on the plugin, you find it in the kate.git, addons/lspclient.

Feel welcome to show up on kwrite-devel@kde.org and help out! All development discussions regarding this plugin happen there.

If you are already familiar with Phabricator, post some patch directly at KDE’s Phabricator instance.

It will not be shipped with the KDE Applications 19.08 release, but in master it is now compiled & installed per default. You only need to activate it on the plugin configuration page in Kate’s settings dialog to be able to use it.

For details how to build Kate master with it’s plugins, please take a look at this guide.

If you want to start to hack on the plugin, you find it in the kate.git, addons/lspclient.

Feel welcome to show up on kwrite-devel@kde.org and help out! All development discussions regarding this plugin happen there.

If you are already familiar with Phabricator, post some patch directly at KDE’s Phabricator instance.

What is new this week?

The most thing are internal cleanups and minor improvements.

Feature wise, the hover implementation works now more like in other editors or IDEs, you get some nice tool tip after some delay:

Never try to guess again what some auto means ;=)

There is still a lot that can be improved, e.g. a filter for the symbols outline is in work:

• D22592 - port symbols view to model/view concept

To be able to later out-source some parts of the generic LSP client code to a library, if there is demand, we will aim to make the plugin be licensed under the MIT license. This should make it easier for other projects to depend of our code, if wanted.

Reminder: The plugin is not compiled per default, you can turn it on via:

cmake -DCMAKE_INSTALL_PREFIX=“your prefix” -DENABLE_LSPCLIENT=ON “kate src dir”

The code can still be found kate.git master, see lspclient in the addons directory.

What is new?

• Diagnostics support: A tab in the LSP client toolview will show the diagnistics, grouped by file with links to jump to the locations. Issues will be highlighted in the editor view, too.

• Find references: Find all references for some variable/function in your complete program. They are listed like the diagnostics grouped per file in an extra tab.

• Improved document highlight: Highlight all occurrences of a variable/… inside the current document. Beside highlighting the reads/writes/uses, you get a jump list like for the other stuff as tab, too.

A feature I missed to show last time:

• Hover support: Show more meta info about a code location, like the proper type, useful e.g. for almost-always-auto C++ programming.

We even got already two patches for the fresh plugin:

• D22348 - Use the label when insertText or sortText is missing
• D22349 - Don’t send the Content-Type header

Both are aimed to improve the support of the Rust LSP server. As you can see, they got already reviewed and merged.

Feel welcome to show up on kwrite-devel@kde.org and help out! All development discussions regarding this plugin happen there.

If you are already familiar with Phabricator, post some patch directly at KDE’s Phabricator instance.

You want more LSP servers supported? You want to have feature X? You have seen some bug and want it to vanish? => Join!

But the good news is, somebody else did scratch that itch on his own ;=)

We have now a prototype plugin in kate.git master, see lspclient in the addons directory.

It is not compiled per default, you can turn it on via:

cmake -DCMAKE_INSTALL_PREFIX=“your prefix” -DENABLE_LSPCLIENT=ON “kate src dir”

It shares no code with my initial prototype. The author started this without knowing of my work. This might actually be not that bad, as this plugin is composed of a much smaller code base. This allows to get familiar with the code easier as with the code I copied over from Qt Creator for my initial try.

But, even nicer, it does actually work a lot better than my variant, already now!

What does work (tested with clangd and kate.git/work projects) at the moment:

• Auto completion: you get the proper LSP server provided completion items

• Outline view: Get an extra tool view with the symbols of your current view

• Document highlight: highlight all occurrences of a variable/… inside the current view

• Code navigation: jump to the definition/declaration

There is still a lot of stuff missing and this is all prototype quality. For example the document highlight implementation I added has no way to clear the highlighting at the moment beside document reload.

But given I just needed one hour to add the document highlight support, I would say the code base is easy to adjust.

=> If you have time and want a good LSP client, now you can join the fun and have direct results.

As the author was kind enough to move his work on the plugin to the KDE infrastructure, feel welcome to show up on kwrite-devel@kde.org and help out! All development discussions regarding this plugin happen there. We are happy to accept patches, too, if you are a new contributor!

I was astonished that Kate made it into the “Which development environments (IDEs) or editors do you use for C++ development?” results.

;=) Seems not only I use it as my normal editor for working on C++ code.

And heads up, KDevelop is there, too!

This is actually the second survey, I missed to notice the first one last year. The results PDF from last year shows Kate did show up already there.

We shouldn’t be that proud of only having less than three percent usage, but still, we are there at all. I hope we can rise here a bit in the future.

At least we work on supporting modern C++ standards in the highlighting, e.g. see the recent C++20 improvements (Phabricator + Commit). Thanks to Jonathan Poelen for the patch!

Language Server Protocol (LSP) would help, too, but my initial work is far from usable, help appreciated. Beside a hacked “goto definition” nothing works at the moment (and it is hardcoded to just start clangd, no other LSP server).

For developers that report a bugs or wish, the best way to really get it solved is to scratch your own itch and provide some patch.

I know this is not feasible for all bug reporters, as not all are developers nor will even the developers all have either time nor perhaps the right skill set to tackle the issue on their own.

But if you have the time and you are at least a bit familiar with C++/Qt, you should give it a try.

We can help you to get your patch done, that is much easier for e.g. myself than to motivate me to work on a bug or wish that doesn’t concern my normal workflow or lie within my skill set.

For example we have a lot of issues with left-to-right text rendering or related to languages that use complex Unicode surrogates. Given I have zero knowledge of any language using this my motivation to dig into these issues is small (and I will more likely break more things than fix them).

The same holds for issues in our Vi mode. I don’t use this mode myself nor do I really know how Vi commands shall behave in real life. Therefore any fix or enhancement there is beyond me.

A good example for such a “Scratch Your Own Itch” approach is bug 407910.

It is a small request, to have some action/shortcut to reset the font size to the default one. We have since years some zoom in/out actions/shortcuts but nothing to go back to the configured one.

I rarely use the zoom stuff, perhaps once in a month, if I want to show something to a colleague on my screen or projector and it is really not readable with my normal font size. Therefore my motivation to invest any work into yet an other action I will not use regularly is small.

But, in this case, the reporter had the time to invest a bit work into this.

He provided a patch via our KDE Phabricator - D21412.

We needed some iterations to get the patch into a usable shape in the bug report and in Phabricator, but thanks to the persistence of the reporter, it got now pushed to our repository.

If nobody would have stepped up to provide at least some initial patch for this, such a request for sure would have rotted again in our bug database.

This is not the first time such a nice thing happened, this is just a recent example how such things can work out.

Therefore, if you report something and are capable of given it a try on your own, please do so!

Perhaps even some of the existing bugs or wishes are stuff you want to take care of yourself because they concern you!

I think not a lot motivates your more to do something than an issue you have with a tool for your workflow. At least for me that was the reason to at all start the development of Kate (I missed a MDI variant of KWrite) and join the work on stuff like KTextEditor.

If you have time and need an itch to scratch, any help to tackle the currently open bugs would be highly appreciated.

The full list can be found with this bugs.kde.org query.

Easy things anybody with a bit time could do would be:

• check if the bug still is there with current master builds, if not, close it it
• check if it is the duplicate of a similar still open bug, if yes, mark it as duplicate

Beside that, patches for any of the existing issues are very welcome.

I think the best guide how to setup some development environment is on our KDE Community Wiki. I myself use a kdesrc-build environment like described there, too.

Patches can be submitted for an review via our KDE Phabricator.

If it is just a small change and you don’t want to spend time on Phabricator, attaching a git diff versus current master to the bug is ok, too. Best mark the bug with a [PATCH] prefix in the subject.

The team working on the code is small, therefore please be a bit patient if you wait for reactions. I hope we have improved our reaction time in the last months but we still are lacking in that respect.

For example, if you use the CMake Kate project generator and you compile Kate from the “lsp” branch, clangd should pick up the compile_commands.json for a CMake generated Kate project.

;=) Unfortunately not much more than starting and informing clangd about the open workspaces (for the first opened project) works ATM.

If you press ALT-1 over some identifier, you will get some debug output on the console about found links, like below:

qtc.languageclient.parse: content: “{"id":"{812e04c6-2bca-42e3-a632-d616fdc2f7d4}","jsonrpc":"2.0","result":[{"range":{"end":{"character":20,"line":67},"start":{"character":6,"line":67}},"uri":"file:///local/cullmann/kde/src/kate/kate/katemainwindow.h"}]}”

The current ALT-1 handling is a big hack, as then one just adds the current document and triggers the GotoDefinitionRequest. A proper implementation tracks the opened/closed documented of the editor.

But at least in principle Kate is now able to start some language server processes and talk a bit with them, all thanks to the nice code borrowed from Qt Creator.

:=) As my spare time is limited, any help in bringing the branch up-to-speed is highly welcome, just drop us a mail to kwrite-devel@kde.org or mail me in private (cullmann@kde.org). A working LSP integration will help to make Kate more attractive for programmers of many languages.

If one takes a look at some current LSP clients list, a lot of editors and IDEs have joined the LSP family in the last years.

In the past I was always scared away to start implementing this in Kate, as no readily available library was around to do the low-level work for the client. Whereas you get some reference stuff for the JSON based protocol for JavaScript and such, for Qt nothing was around.

Fortunately Qt Creator started to implement an LSP client beginning with the 4.8 release.

Based on this code, I started now to get this into the Kate project plugin. At the moment not much more has happened then some initial import of the Qt Creator LSP infrastructure code into the Kate lsp branch.

If I get this working (help is welcome!), any improvements will be submitted back to the Qt Creator implementation. If it really starts to work well in Kate, one might think about some better code sharing in the long term. But before such plans, first at least some basic things must work for some initial language server like clangd.

This is a nice step for the wider adoption of this MIT licensed part of the KDE Frameworks.

And this is not just an one-way consumption of our work.

The framework got actively patches back that make it more usable for other consumers, too, like Kate ;=)

If you want concrete examples, take a look at:

• D18982: prevent assertion in regex load
• D18996: Fix building with namespaced Qt
• D18997: Add functions returning all definitions for a mimetype or file name
• D19200: Return sorted definitions for file names and mime types
• D19215: Install DefinitionDownloader header

I hope this cooperation will continue in the future. I thank the people working on Qt Creator that made this integration possible. I hope the initial effort will pay of with less code for them to maintain on their own and more improvements of the framework for all users.

What now? Last time I did run into that, I archived the overfull repository to some “rest in peace” space and used git filter-branch to filter out no longer needed and too large objects from a repository copy that then will replace the old one for daily use.

There are a lot of guides available how to use git filter-branch for that. All variants I ever used were complex to do and did take very long. Especially if you need several tries to get a sane set of stuff you want to remove to gain enough space savings.

This time, I searched once more and stumbled on the BFG Repo-Cleaner. And yes, it does what it promises on the web site and it seems to be trusted enough to be advertised by e.g. GitHub, too.

Just following the steps described on their landing page allows to shrink your stuff nicely and without a lot of round-trip time.

If you still are just in the “experimenting” phase to see which space decrease one can archive with which file size filter (or which files you want to purge by removing them from master before running the tool), I recommend to swap the step

git reflog expire --expire=now --all && git gc --prune=now --aggressive

with just

git reflog expire --expire=now --all && git gc --prune=now

to not wait potential hours for the aggressive GC. For me that was good enough to get some estimate of the later size for my experiments before I settled to some final settings and did the real run.

And as always, if you touch your Git history: Do that only if you really need to, keep backups, check carefully that afterwards the repository is in some sensible state (git fsck --strict is your friend) and inform all people using that repository that they will need to do a full new clone.

They actually show pretty nicely how far we have gone since 2005 with our development stack.

The KDE 3 -> 4 transition was a large hassle. It did take weeks of work just to get Kate back into an usable state.

We first started with some trivial KTextEditor container (a mini KWrite) for the porting to get KTextEditor at all doing something. That started out with something that even had no menu or toolbars working:

This evolved after two days into a kind of working KWrite port (icons still randomly missing):

After the KTextEditor part did work “reasonable”, we started with Kate:

And ended up with an initial ported prototype three days later:

And after that a long time of actual polishing for KDE 4.0 did start. Kate was actually one of the first ported applications during the KDE 3 -> 4 transition.

The KDE 4 -> KF5 transition was much nicer, even thought the Frameworks split did cost a lot of time and resources. But the actual changes to the application code bases were not that radical.

And where did we end up with this ~14 years later? Actually, just here:

It is still recognizable the same application, thought I hope some progress is visible :=)

On both servers CentOS 7.x is running, it did always provide a stable foundation for the services these sites use.

As with any server move in the past, I always need to search how to best move the data/config from one server to the other. To document this for me and others, here the quick way to move the basic things needed for web services using just plain Apache & MariaDB.

The following steps assume you have installed the same packages on both machines and the new machine is allowed to ssh as root to the old one. If you have non-system users, you should create them with the same ids as on the old server.

For the following shell commands, the old server address is $SERV and the MariaDB root password is $PASS on both machines. Best use the raw IP as address if you are in parallel updating your DNS entries to avoid confusion (and wrong syncs).

Attention: Wrong syncing of stuff can have disastrous consequences! Check all commands again before executing them, don’t trust random people like me without verification!

• sync your data, assuming it is in /home and /srv/(ftp/www)

rsync --delete -av root@$SERV:/home/ /home
rsync --delete -av root@$SERV:/srv/ftp /srv
rsync --delete -av root@$SERV:/srv/www /srv

• transfer your databases

ssh root@$SERV "mysqldump -u root -p$PASS --all-databases > /root/db.sql"
scp root@$SERV:/root/db.sql /root/
mysql -u root -p$PASS < /root/db.sql

• sync configs (you might need more, this is just apache & vsftp)

rsync --delete -av root@$SERV:/etc/httpd /etc
rsync --delete -av root@$SERV:/etc/letsencrypt /etc
rsync --delete -av root@$SERV:/etc/vsftpd /etc

• get crontabs over for later re-use, store them in the root home

rsync --delete -av root@$SERV:/var/spool/cron /root

Now all things should be there and after some service restarts e.g. WordPress powered pages should be up-and-running again.

I hope this short how-to helps others and allows me to avoid searching stuff in the future once again from scratch.

After creating the privacy page (Impressum), I did take a closer look at the generated HTML code to confirm I didn’t miss to state things there.

I thought, given Hugo generates plain static HTML pages, I would be on the safe side.

But unfortunately, the theme I use includes some external resources, like the Google web fonts…

I now patched that out of the theme and provide local copies on my own server.

The local mirrored files can be found here.

Actually, this shows, for a “normal” user, it is really hard to ensure no privacy violations are on his/her/… website, given you need to control each and every page.

This is already ugly with static pages, like the stuff generated here (and I hope I missed nothing), but with dynamic websites this is…

Unfortunately that needs Hugo in the “extended” version.

The binary one can download on https://github.com/gohugoio/hugo/releases doesn’t run on CentOS 7, unlike the normal variant you get there (too new libstdc++ needed).

One has to recompile it to get that working.

To make it easier for others, to do so, just:

• install golang + gcc-c++ on your CentOS 7
• download https://github.com/gohugoio/hugo/archive/v0.54.0.tar.gz
• execute in the source directory go install -tags extended
• grab the result binary in your ~/go directory

The new website uses zero cookies (yes, no stupid cookie question) and no kind of analytic software.

I hope my Impressum is done well enough to avoid any legal issues.

At the moment the website is still very empty, I hope to fill in more content about my open source projects and academic stuff in the near future.