Yesterday I picked up my new KDE Slimbook. It comes with KDE Neon pre-installed. Of course it also works well with openSUSE, and Manjaro, and Netrunner Linux (some things I’ve at least booted the Live CD for). But for me, “will it run FreeBSD” is actually the most important bit.

Yes. Yes it does, and it does so beautifully.

That is at least one advantage of choosing a Free Software friendly laptop, one designed for GNU/Linux: it is likely to be supported by many more operating systems that you might like. No, I have not tried OpenSolaris / Illumos on it .. there’s really no desktop distro in that corner anymore.

So, here’s how to breakupgrade your  Slimbook to FreeBSD (no warranty implied):

• Resize the installed partition to make space for FreeBSD. I chopped 40GB off the end of the main Linux partition. This may break various crypt-setup things, be careful. For resizing, I actually used the Manjaro installer, and told it to resize an existing partition, then cancelled the install during unsquash, and then deleted the partition it had made. You can probably use resize2fs and gparted with good effect, too.
• Install FreeBSD 12-CURRENT. I went for UFS on a single partition, no swap: that’s the easiest to get right, and avoids weirdness like zpools on a partition. It ended up in ada0p4, or sda4, or (hd0, gpt4) depending on what nomenclature you use for naming disks.
• Oh, yeah .. don’t install a boot manager for FreeBSD. We’ll let the existing GRUB deal with it.
• Reboot and let GRUB start Linux again. We’ll configure GRUB to (also) start FreeBSD. Add an OS entry for FreeBSD, by adding /etc/grub.d/40_custom:
  

  
menuentry "FreeBSD" --class freebsd --class bsd --class os {
insmod ufs2
insmod bsd
set root=(hd0,gpt4)
chainloader /boot/boot1.efi
}


  Also recommended: set timeouts so you can actually pick an OS, in /etc/grub.d/custom.cfg:

  
set timeout=5
set timeout_style=menu


• Reboot, hit escape at the right moment to get the GRUB menu, and choose FreeBSD. Boot into FreeBSD.
• Configure wireless networking on FreeBSD for the Slimbook. I have one with an Intel 7265 wireless card, so I needed to set that up. Since the firmware comes from the filesystem, I ended up following the quick-start guide and futzing with rc.local to load the driver. Here’s my rc.local:
  

  
#! /bin/sh
/sbin/kldload if_iwm
/sbin/ifconfig wlan0 create wlandev iwm0
:


  and this is a bit of my rc.conf:

  
# Wireless
wlans_iwm0="wlan0"
ifconfig_wlan0="WPA SYNCDHCP"


  Bear in mind that NetworkManager and other fancy bits are not available: configure wpa_supplicant.conf by hand and add SSIDs and PSKs there.

• Right now, Intel IGP after Broadwell (and the Slimbook is a Skylake) isn’t fully supported by the xf86-video-intel driver, so instead use scfb. This loses acceleration and some other features, but it gives you X11 right now, as opposed to sometime later when the newer drivers are merged.
  

  pkg install xf86-video-scfb

  Add some explicit, manual, X.org configuration:

  
Section "Device"
Identifier "Card0"
Driver "scfb"
EndSection


• After that, follow my earlier Plasma 5 on FreeBSD HOWTO, including adding the Area51 repo. However, since this is 12-CURRENT, you need to use a different pkg repository URL.

This concludes my laptop-futzing-about at Akademy this year: I have a laptop that dual-boots Linux and FreeBSD, and gives me an up-to-date Plasma 5 Desktop and KDE Applications on both — but that leaves me free to hack on whatever my work requires in the OS best suited to it each day of the week.

Books, badges and new functionalities are coming!

Hey WikiToLearn-ers! It has been a while, but now “What’s going on?” is back.

This last period was really difficult for all of us but we never forgot of WikiToLearn. In spite of personal commitments and exams, the members of our community kept working day after day and now we see the results!

Electromagnetism is now ready!

In the first episode of “Meet the authors” we have come to know Dan, a long term contributor of ours. It is now a pleasure to announce that his book about electromagnetism is ready! Dan is one of the most active editors in our community and on our website he wrote several books on the italian portal: analysis, physics I, mechanics and electromagnetism! Kudos Daniele for your strong dedication to the project and for your contributions!

We have badges!

The tech team never stops, the platform is always at his best and our sysadmins work hard to provide you great services. When we had problems we were able to solve them very quickly and to get back on our feet! In this period

our devs worked on a long-term requested feature for our website: badges! Yeah, now WikiToLearn has badges! Since our project was born we were asked a way to certify an imported or reviewed book and to give its author/reviewer the proper merit. We are very happy to announce that this feature is now ready! When you donate a book to be imported, a proper tag will be associated to it on the website.

Professors always asked us a tag to certify their books authority. To accommodate this request now we have the “Reviewed” tag. Are you the author of a specific book and you would like it to be certified? Now with WikiToLearn you can! One step further to guarantee high-quality content and to monitor revisions on our dynamical textbooks!

Let’s celebrate!

We never forget where we belong: that’s why we remind you that during this week Akademy2017 is taking place in Almeria! Akademy is the annual conference of the KDE community. WikiToLearn was born under the KDE umbrella and still today we fell part of the KDE family. This year WikiToLearn is represented at Akademy by Vasudha, a GSoC student of ours working on Ruqola. Today we remember Akademy with extreme pleasure: two years ago, during Akademy2015 our project was officially born!

Since the first official announcement to the public, so much happened. We can consider ourselves satisfied for the hard work we did and for the initial outreach we had. People feedbacks pushed us to work better and better to improve functionalities and to satisfy users’ needs. In this period we had the occasion to spread the word about WikiToLearn and we could obtain substantial involvement in our projects. We are extremely grateful to all the members of our community for events organized, books donated for importation, reviews and creation of new material on the platform.

For us now it’s time to work even harder. During these two years we came up to realize what we were doing properly and what has to be modified. In the next few months we are working on communication and style improvements to enlarge our community.

Content creation and usability are the two main issues we are facing right now.  Any kind of user should be aware of what the platform offers and should be encouraged to write on it. WikiToLearn collects dynamical textbooks and in the incoming future this innovative feature of our product has to become our strength point!

We are working for you, WikiToLearn-ers! Stay tuned, spread the word, join.wikitolearn.org and start sharing your knowledge in a completely innovative way!

L'articolo Wiki, what’s going on? (Part 24-Badges and books) sembra essere il primo su Blogs from WikiToLearn.

Hello, this is the report for the second phase of the GSOC. The last month was not easy. Some things had to be re-written because they were not very well written. For example, I wrote a system of “sensors”, the logic of which was laid in the destructors of objects....

It has been more than a month since I last blogged. This is not really a good situation. Nevertheless, for the remaining period of GSOC I will try to be more regular.

In this post I intend to report the whereabouts of my project. First of all me not posting any updates about my project was due to two problems that showed up when I was two weeks into the coding period. One, which I had anticipated, was to decide from where to show a warning dialog during the brief period of time when privileges are elevated. The problem was that showing the prompt from KIO::Slave resulted in repetition and to show it from KIO::JobUiDelegate permissions of destination folder was needed beforehand which required additional computation. So for this I decided to add a signal in KIO::Slave and all the necessary code for additional prompts in KIO::Job. This way the KIO slave emits the signal whenever it encounters ACCESS DENIED error and then job decides whether or not to show the prompt. The other problem was to figure out how to modify files created by a privileged process by an underprivileged one. By the way the latter was completely uncalled-for and it took me around two weeks to decide on a solution. To send data between processes I tried every possible IPC mechanism involving shared memory, pipes and sockets. At last I decided on sharing file descriptor between the privileged and under-privileged process and to accomplish that I used Unix local domain sockets.

Now fast-forward to today, I have found solutions to my problems and I can say I have finally made some real progress. To be precise with my current state of project dolphin’s context menu is very much usable inside a read-only folder. Most of the action in dolphin’s context menu, which includes copy/cut/paste, rename, creating new file, creating new folder, creating links, trash and delete, are working without any issues whatsoever. The actions that are not working are Creating desktop files, Creating Link to Application (technically both involves creating desktop files but have two separate menu options), Compressing files, Drag and Drop, Undoing and Renaming multiple files in one go. The first two need changes in KIO::KPropertiesDialog in order to work. For compressing to work changes have to be done from ark’s side. DnD requires changes in KIO::DropJob. Undoing and renaming many files kind of challenge my current solution but I have explained their case and the possible workaround in the end of post.

I have created a phabricator task in which I have listed all the related revisions and also tried to explain how everything is going to work. If anyone has a kde build environment set up and is interested to try out the changes then apply the patches listed in this repo. Unlike my previous patches which required separate branch for every file operation, all of my current patches can be applied at once and changes can be tested without having to checkout to a new branch.

Now coming back to the issue with undoing and renaming files. My design assumes one top-level parent job and many sub-jobs. However while undoing changes and renaming files, jobs are created in a loop. This means creation of many top-level jobs (like KIO::CopyJob) and that many sub jobs (like KIO::SimpleJob). So a possible workaround is to introduce a new KIO::Job that can be placed outside the loop body and would serve as a parent job for all the jobs created inside the loop. But I will consider this only after my current changes are reviewed by KIO developers.

Till then cheers.

I started to implement multiple cursor and selection support in KDE’s famous text editor kate a while ago, but eventually didn’t quite have the time to finalize it. I am currently at Akademy in Spain, KDE’s annual developer conference, and decided that would be a good time to pick it up again and make it actually work. Here it is in action:

Multiple cursors in kate

What does it do?

It allows you to have an arbitrary amount of cursors and selections in KTextEditor. They all mirror what you do with the primary one — text input, text removal, navigation, text selection, …

Features include:

• Place any amount of cursors with mouse and keyboard shortcuts.
• Have any amount of (disconnected, i.e. non-continuous) selections. Each selection has exactly one cursor at either its start or its end, but the selection for a cursor is allowed to be empty. Selections do not need to have the same size.
• Freeze and unfreeze your secondary cursors, allowing you to move only the primary cursor, or all of them simultaneously.
• Perform most editing, text selection and text navigation features on all cursors simultaneously.

What is it good for?

You decide.

Multiple selections of different sizes

How do I use it?

Usage is relatively simple; the shortcut for controlling multicursors is currently Ctrl+Meta (Meta is the key with the Windows icon on it). Press Ctrl+Meta and click in your document to place a secondary cursor. Then, just do whatever you would normally do with the keyboard. Press Esc to clear all secondary cursors.

You can place cursors with just the keyboard by pressing Ctrl+Meta+D (“toggle secondary cursor at current position”). Doing that will freeze all secondary cursors, and the keyboard now only moves the primary cursor until you unfreeze them again with Ctrl+Meta+F.

You can also create multiple and additional selections by pressing Ctrl+Meta, and then just using the mouse to select text.

Multiple cursors in a Kate document

What’s the state?

Most things work, there will be some issues I’m not aware of. What is at the moment completely broken is persistent selection, and the block selection mode. Both just do random things. I will need to fix that — or do you want to help? Assistance is very welcome.

If you want to test things, I’m sure you can find issues around static and dynamic word wrap, and folding.

How do I try it?

Check out the “multicursor” branch in the ktexteditor repo and build it, then start kate or any other application using the katepart editor component. Or, get a kate AppImage with multicursor support from here: http://files.svenbrauch.de/kate-linux/multicursor/

Please leave feedback in the comments if you try it out!

Yesterday I picked up my new KDE Slimbook from the Slimbook.es stand at Akademy.

First thing I did, of course, was boot it with my FreeBSD 11.0 SD card, to see if it works with my favorite operating system (with Plasma 5 desktop, of course). Nope: 11.0 hangs after finding acpi_ec0, so I will write about that later this week.

Second thing I did was boot KDE Neon (pre-installed) on it, to see how it works out-of-the-box. I collected a bunch of tiny-little-irritations, papercuts if you will, from the basic installation — which have disappeared after an update and reboot.

It’s a really nice and slick machine. I wanted a machine that would still fit in the train or plane, for work, but a little larger than my Thinkpad x121e. I bought that machine in 2012(?) from Hettes, a Dutch shop specializing in hardware with Linux preinstalled (now gone, since they could no longer source hardware without a Windows license). So I’m really happy to buy a new machine from a Free Software supporting shop in 2017.

There’s a bit of a weird-ass dongle in the box for wired ethernet, SD card slot, HDMI and two USB ports on the sides, and a DC in — I don’t think I will miss USB-C at all, although that would be neat for a refresh. I have not tried the webcam, which is in the bezel at the top of the screen (no nostril shots like some Dell machines). Speaking of bezels, they’re pretty wide compared to current “design” laptops, Not any wider than the x121e, so relatively more narrow.

The touchpad is a big change for me personally, since I am — or shortly will have been — an IBM TrackPoint™ fan. On the other hand, the touchpad is solid and clicky. The keyboard is nice, with perhaps a little too much flex in the right-hand alt and delete keys. The arrow keys are arrowy, not the fat-left-and-right that (I think) HP uses.

So!

Having discovered that the machine is shiny and nice and fast and works well .. my next step is to try to break it. With the blessing of Alejandro and César — it’s good to have the best possible tech support right at hand.

(Oh, I forgot to mention: I’m pleased as punch with the ordering process, too, for instance the special “deliver to Akademy” shipping option, and the fact that I got email informing me of progress as the laptop was assembled and installed.)

Hey people,

The second phase of Google summer of code evaluation is near!!. And I have started to work on the second part of my project. That is, I have completed the first part of my project. Yeayy!

What’s on hand right now?

Started working on the Bundle Manager, creating the UI which was decided to be done. Creating addition features like deleting the bundles created and creating a search functionality too at the moment.

Deleting the bundles

In Krita, we cannot delete the bundle created just like that. The Bundles created are saved as the KisResource in a QList. We have to remove it from that list, then obviously, we have to remove it from the list widget where this bundle is shown. Then we have to BlackList the file. Then from there, we can remove the blacklisted bundles as we empty a recycle bin ;).

Searching the bundles.

I was reading the code of tag management most of the time, So I haven’t gone deep, this week coding. Other than these two functionalities. But I have a mere idea how to do this, Since this is a QList, I would think of implementing some search algorithms based on the bundle’s name. Or else, I will be tracing a way out using Hashing method.

I was reading the code for the tagging management and have to look out for things which need fixes. After understanding the codebase I will start implementing features and fixing bugs.

Planned works for next week.

• Get Second phase review done.
• Implement features/fix bugs of Tag management.
• Fix bugs/Implement features of Resource Manager.
• Document/test if necessary.
• Get more inputs on the tag management from the community.

Hope to hack in again in better ways.

Cheers.

Docker can help you to quickly set up a development environment for working on a software project. This is great for getting new contributors up to speed quickly. I've recently discovered how nice this is and want to share how I use Docker.

KDE projects often have desktop services, mimetypes and plugins. Ideally, these are installed system-wide. During development it is not convenient to change your main environment just to test your software. This is where Docker comes in. Docker is the most popular Linux container system. It gives you a system that is separate from your main system and which you can rewind when you break it.

Dolphin in KDE neon

The simplest way to get going is to run a fresh Plasma system. KDE neon provides Docker images.

After installing Docker, you can get a system going like this;

# give the docker application access to X
xhost +si:localuser:$USER
# run a throwaway session with dolphin
docker run --rm \
    -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix \
    -ti \
    kdeneon/plasma:dev-stable dolphin

--rm

cleans up the container after use.

-ti

makes the session interactive.

-e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix

gives the container access to your X session.

Dolphin running in a throwaway Docker container. No home directory was set up.

Dolphin in openSUSE

Instead of kdeneon/plasma:dev-stable you might want to use a different distribution. You can build you own images by creating your own Dockerfile. Here is a simple Dockerfile for a Docker image for dolphin based on openSUSE.

FROM opensuse

# opensuse image is minimal, so add plasma and dolphin
RUN zypper --non-interactive install plasma5-desktop dolphin \
  && zypper clean

# set up an environment for a user
RUN useradd --create-home user
USER user
ENV KDE_FULL_SESSION=true
ENV XDG_RUNTIME_DIR=/run/user
WORKDIR /home/user

CMD ["bash", "-l"]

To create a docker image, write this text into a file name Dockerfile and run

xhost +si:localuser:$USER
docker build -t opensuse-dolphin .
docker run --rm \
    -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix \
    -ti \
    opensuse-dolphin dolphin

Now a docker image called opensuse-dolphin was created and run. At each uppercased commands like RUN a snapshot is created. The last step is to tag the final snapshot with the name opensuse-dolphin. That name can be used to run a throwaway container with dolphin.

Dolphin running in a throwaway Docker container based on openSUSE.

Adding a home

To do any coding, you'd like to provide files to your container and have the ability to store files. This is possible. You can give a container access to a local folder with the -v flag, for example -v $HOME/calligra-dev/home:/home/user which mounts your folder $HOME/calligra-dev/home to the folder /home/user in the container.

I like to manage this container home with git, so I can start with a clean folder by running git clean -fd.

mkdir -p $HOME/calligra-dev/home
cd $HOME/calligra-dev/home
git init
echo 'git clean -fd' > .bash_profile
echo -e 'src\nbuild\ninstall' > .gitignore
git add .bash_profile .gitignore
git commit -a -m 'Initial commit'

So the development environment is managed by Docker on the system level and by git on the level of work directory.

Developing Calligra in Docker

After this introduction, I'm showing the Dockerfile that I'm using for Calligra with QtCreator or KDevelop and the clazy quality checker. Clazy has not been packaged so the Dockerfile needs to have a build step for it.

FROM kdeneon/plasma:dev-stable

USER root

RUN apt-get update && apt-get dist-upgrade -y

RUN apt-get install -y --no-install-recommends \
  cmake extra-cmake-modules g++ gettext git kdoctools-dev kross-dev \
  libboost-all-dev libeigen3-dev libetonyek-dev libfontconfig1-dev \
  libfreetype6-dev libgit2-dev libgsl-dev libkf5activities-dev \
  libkf5archive-dev libkf5kcmutils-dev libkf5kdelibs4support-dev \
  libkf5notifications-dev libkf5notifyconfig-dev libkf5parts-dev \
  libkf5wallet-dev libkf5xmlgui-dev libodfgen-dev libpoppler-qt5-dev \
  libqca-qt5-2-dev libqt5opengl5-dev libqt5svg5-dev libqt5x11extras5-dev \
  librevenge-dev libwpd-dev libwpg-dev libwps-dev ninja-build pkg-config \
  sudo

# requirements for clazy
RUN apt-get install -y --no-install-recommends \
  clang llvm-dev libclang-3.8-dev

# build and install clazy
RUN git clone git://anongit.kde.org/clazy \
  && cd clazy \
  && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -GNinja \
  && ninja install

# dependencies for development
RUN apt-get install -y --no-install-recommends \
  cmake-curses-gui \
  less vim strace qtcreator kdevelop valgrind gdb

USER neon
CMD ["/bin/bash", "-l"]

docker run -v $HOME/calligra-dev/home:/home/neon \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  -e DISPLAY=$DISPLAY \
  -e XDG_CURRENT_DESKTOP=$XDG_CURRENT_DESKTOP \
  --network none \
  -ti calligra-clazy

Parallel development environments

Docker is easy to set up and lets you have tight control over your development and testing environment. You can have many environments present on your system and reset and start and stop them quickly. Finally, here is a screenshot of my desktop running development environments for Calligra 2 and Calligra 3 in parallel. Both are running in QtCreator. This is a screenshot from my Akademy presentation on Calligra.

Two versions of Calligra running in Docker containers.

Helping contributors to get started

Getting started in KDE can be challenging. Docker images or Dockerfiles for complete development environments can get new contributors started more quickly. In KDE, neon already uses Docker images. Jonathan Riddell is giving a presentation about that this Akademy. Because this is so easy, I predict that we'll see more Dockerfiles being published by KDE projects.

I've used ngrx/store and ngrx/effects for a while, and like the pattern. The new version has been released, and here are some of the changes I had to make in my code.

Pre v4 you built your reducers as follows, passing an object with

stateslice: reducerfunction.

const productionReducer = combineReducers(reducers);
export function reducers(state: any, action: any) {
    return productionReducer(state, action);}

StoreModule.forRoot(reducer),

export interface Action {
  type: string;
}

import {Action} from "@ngrx/store";

import {PrintItem} from "../../../models/print.model";


export const ADD_TO_QUEUE = '[Printing] Add to queue';

export const REMOVE_FROM_QUEUE = '[Printing] Remove from queue';

export const MARK_STATUS = '[Printing] mark status';

export class Print implements Action {
    type = ADD_TO_QUEUE;    

constructor(public payload: PrintItem) {}
}

export class PrintDone implements Action {
    type = REMOVE_FROM_QUEUE;    

constructor(public payload: PrintItem) {}
}

export class PrintStatus implements Action {
    type = MARK_STATUS;    

constructor(public payload: PrintItem) {}
}

export type Actions
    = Print
    | PrintStatus
    | PrintDone;

import {PrintState} from "../../../models/print.model";import {ActionReducer} from "@ngrx/store";import * as printingActionTypes from "../actions/printing.actions";

export type Action = printingActionTypes.Actions;
const initialState: PrintState = {
    queue: []
};
export const reducer: ActionReducer = (

    state = initialState, action: Action) => {
    switch (action.type) {

....

In this article, I am outlining an idea for an improved process of deploying software to Linux systems. It combined advantages of traditional, package mangement based systems with containerized software through systems such as Flatpak, Snap, or AppImage. An improved process allows us to make software deployment more efficient across the whole Free software community, have better supported software on users systems and allow for better quality at the same time.

Where we are going

Traditional model of software deployment

• It’s not unusual that software installed on a “supported” Linux system is outdated and not at all supported upstream anymore on the day it reaches the user. Worse, policies employed by distributions (or more generally, operating system vendors) will prevent some software packages from ever getting an update other than the most critical security fix within the whole support cycle.
• Software out in the wild with its problems isn’t supported upstream, bug reports reaching the upstream developers are often invalid and have been fixed in newer versions, or users are asked to test the latest version, which most of the time isn’t available for their OS — this makes it harder to address problems with the software and it’s frustrating for both, users and developers.
• Even if bugs are fixed in a timely fashion, the likelihood of users of traditional distributions actually receiving these updates without manually installing them is small, especially if users are not aware of it.
• Packaging software for a variety of different distributions is a huge waste of time. While this can be automated to some extent, it’s still less than ideal as work is duplicated, packaging bugs do happen simply because distribution packagers do not fully understand how a specific piece of software is built and best deployed (there’s a wide variety of software after all) and software stacks aren’t often well-aligned. (More on that later!)
• Support cycles differ, leading to two problems:
• Distros need to guarantee support for software they didn’t produce
• Developers are not sure how much value there is in shipping a release and subsequent bugfix releases, since it takes usually at least months until many users upgrade their OS and receive the new version.
• Related to that, it can take a long time until a user confirms a bug fix.
• There is only a small number of distributions who can package every single piece of useful software available. This essentially limits the user’s choice because his niche distro of choice may simply not have all needed software available.

The value of downstreams

One argument that has been made is that downstreams do important work, too. An example for that legal or licensing problems are often found during reviews at SUSE, one of KDE’s downstream partners. These are often fed back to KDE’s developers where the problems can be fixed and be made part of upstream. This doesn’t have to change at all, in fact, with a quicker deployment process, we’re actually able to ship these fixes quicker to users. Likewise, QA that currently happens downstream should actually shift more to upstream so fixes get integrated and deployed quicker.

One big problem that we are currently facing is the variety of software stacks our downstreams use. An example that often bites us is that Linux distributions are combining applications with different versions of Qt. This is not only problematic on desktop form-factors, but has been a significant problem on mobile as well. Running an application against the same version of Qt that developers developed or tested it against means fewer bugs due to a smaller matrix of software stacks, resulting in less user-visible bugs.

In short: We’d be better off if work happening downstream happens more upstream, anyway.

Upstream as software distributor

Software directly from its source

Linux distributors supply a base system, but most of the UI layers, so the user-visible parts come from downstream KDE (or other vendors, but let’s assume KDE for now). The user gets to run a stable base that boots a system that supports all his hardware and gets updated according to the user’s flavor, but the apps and relevant libraries come from upstream KDE, are maintained, tested and deployed from there. For many of the applications, the middle-man is cut out.

This leads to

• vastly reduced packaging efforts of distros as apps are only packaged once, not once per distro.
• much, much shorter delays until a bug fix reaches the user
• stacks that are carefully put together by those that know the apps’ requirements best

Granted, for a large part of the user’s system that stays relatively static, the current way of using packaged software works just fine. What I’m talking about are the bits and pieces that the users relies on for her productivity, the apps that are fast moving, where fixes are more critical to the user’s productivity, or simply where the user wants to stay more up to date.

Containerization allows systemic improvements

In practice, this can be done by making containerized applications more easily available to the users. Discover, Plasma’s software center, can allow the user to install software directly supplied by KDE and allow to keep it up to date. Users can pick where to get software from, but distros can make smart choices for users as well. Leaner distros could even entirely rely on KDE (or other upstreams) shipping applications and fully concentrate on the base system and advancing that part.

Luckily, containerization technologies now allow us to rethink how we supply users with our software and provide opportunities to let native apps on Linux systems catch up with much shorter deployment cycles and less variety in the stack, resulting in higher quality software on our users’ systems.

Hey Community!

Long time no see, huh? Yes, I neglected my blog and as such didn't post anything since Akademy 2014... Interestingly this is the last one where my dear Paul Adams held a famous talk. Talk he is referring to in his latest piece. Since his blog aggregation to Planet KDE is broken, I thought it would be a good idea to relay it on my own blog to give it more exposure. It is reproduced below, if you want to read it in its original form, click through the title.

Paul, the mic is yours now!

Retired From KDE, by Paul Adams

Many of you reading this are probably already aware, long-time maintainer of glibc Roland McGrath has recently retired from maintaining that project. Inspired by his words, I wanted to say a few things about why I no longer contribute to KDE; a project I “retired” from some time ago now.

Recently two very good friends of mine, both long-term KDE contributors, inquired if I was going to be attending this year’s Akademy (the annual KDE conference). Neither were particularly surprised when I said I wasn’t.

I was surprised that they asked.

Getting Into KDE

My first experiences of KDE were many moons ago; sometime in the very early 00s I guess. I had installed Linux on an old machine and was not particularly enjoying the desktop experience.

There wasn’t a desktop.

I cannot remember which distro this was. It had come off some magazine’s cover CD. There was X. And the tiling window manager which allowed me to fill my screen with x-term. This, for a long time, was just how I got stuff done. Emacs, Mutt, Lynx and some weird terminal-based MP3 player were my jam.

Some time later I was reading another magazine (Linux Format?) and it had a review of a recent beta of KDE 2. The sources were included on the cover CD. KDE looked kinda nice. Less boxy and purple than the only other *nix desktop I had seen, CDE. Until I finished my undergraduate degree KDE was my go-to desktop.

Getting Deeper

For a while I had reverted to using a tiling window manager and a screenful of x-term. This was just a convenient way for me to get through my PhD and my day job.

During my PhD I was studying Free Software community productivity metrics. I was also working on research into software quality funded by the European Commission. KDE eV (the governance body¹ for KDE) was also taking part in that project. At this time KDE was almost ready to release KDE 4. It was an exciting time to get involved.

So I installed whatever the Debian stable KDE desktop (3.102193393392393²) of the time and really enjoyed the experience. Having rediscovered my love for KDE and having met some of the active community, I dived in deeper.

KDE became high on my list of projects to study during my PhD. The community was going through major changes: not only was KDE 4 on its way in, but KDE SVN was on its way out.

Gitting Ready For Change

Around 2006 I discovered Ade de Groot’s tool for visualising contributions to SVN; it was part of the English Breakfast Network³. His version of this tool utilised Python’s SVN bindings to read the repo data. Git instinct told me this tool would work faster if it parsed SVN logs rather than read the repo data through a library. I turned out to be right and this was a formative moment in my career.

I created a generic SVN log parser for use by this visualisation tool and used the same parser for other purposes; mostly other visualisations and data plotting. The ultimate aim was to expose to the KDE community what we could learn about social interactions within the community from, arguably, its most important communication tool: the version control system.

KDE SVN was⁴ truly enormous. It was pretty much the largest SVN repo in the wild. One very large central repo which represented the entire body of KDE code/artefacts. Around this time the strains of using such a repo with such a huge (and growing) community were prompting discussion about distributed VCS.

These were remarkably mature and structured discussions. Git was, by no means, a foregone conclusion. Other distributed VCS were given headroom and this was the first (and, basically, last) time I played with Mercurial and Bazaar. The discussions were, for the most part, very technical. I raised my voice to talk about the potential social impacts of switching from SVN to distributed VCS. Any distributed VCS.

Joining KDE eV

I spoke at Akademy and other KDE events (including the KDE 4 launch at the Googleplex) about the research I was doing; either my PhD or the EC-funded stuff. I blogged. I dented⁵. My work was positively received and gearheads would actively reach out to me for more-detailed analysis of their corner of KDE.

I was encouraged to join KDE eV and I did. Given that I had made precisely 0 code contributions⁶ to KDE this, to me, felt like an achievement.

Since day one of my involvement, KDE eV had somewhat of an identity crisis. It was really not 100% clear what it did… but anyone who had been involved with KDE for more than 6 months was highly encouraged to join. Before long it had become bloated; lots of members contributing almost nothing and the few people wanting to do something not getting enough support to do it.

KDE has switched to Git and the social changes were a-happenin’. The KDE project was starting to lose its social cohesion. Post KDE 4.0-release blues, the switch to GIT and a lack of care from KDE eV all contributed here. Other things, too. No one thing started the KDE community’s cohesion degradation. But we felt it. We even went though a rebranding… KDE was not a desktop project, it had become a suite of projects and the desktop was just one of them.

KDE had evolved and I had not.

Cohesion Degredation?

One of the metrics I worked on during my PhD was a simple use of graph theory to measure how well-connected a community is. The contribution I made here was intriguing: as project get bigger they become less cohesive, but through careful community management, luck and clever structure, KDE avoided this.

The last time I properly attended Akademy (the KDE community conference) was back in 2014. I’d been frustrated for some time with my inability to drive home the message that the switch to GIT had o be managed properly. I’d been frustrated that nobody seemed to have noticed that my warnings were coming true.

So I gave a talk that year.

Deep down, I knew this was my last public outing on behalf of KDE. It was. After my talk a lot of people came up to discuss the mic I had just dropped. But as the days and weeks passed after the event, the message disappeared. And so did I.

So Why Are You Telling Us This Now?

This year’s KDE conference starts tomorrow. Two of my all-time best buddy KDE community members reached out to see if I was turning up.

They knew I wasn’t.

While we briefly reminisced by email, one of them pointed out that my talk from 2014 had recently come up in conversation on a KDE mailing list. That, 3 years later, the talk was being used as part of a great discussion about change in the project.

I’m really not sure what my emotion about that was. But, I did not feel compelled to join the discussion. I did not feel a need to remind people about what I was trying to achieve all that time ago. Nope. Instead, I went and pushed some changes to a core plan I had been working on for Habitat, the new home for my free time.

The Thanks

To all my friends in KDE:

Enjoy Akademy. Enjoy the opportunity to do some navel gazing. Enjoy the food, the drinks, the sun. Hack. Break shit and put it back together again. Remind yourselves of why KDE is special. Remind yourselves of why it is important. Very important.

I thank you all for the time we spent together.

We were all part of the solution.

Footnotes

• otherwise throw away no feature branches needed when:
• focused team
• effort predictability

experiments and collaboration implies quantum effect branches

in any case lifetime upper bound

I planned on writing about the Present extension this week, but I’ll postpone this since I’m currently strongly absorbed into finding the last rough edges of a first patch I can show off. I then hope to get some feedback on this from other developers in the xorg-devel mailing list.

Another reason is that I stalled my work on the Present extension for now and try to get first my Xwayland code working. My mentor Daniel recommended that to me since the approach I pursued in my work on Present might be more difficult than I first assessed. At least it is something similar to what other way more experienced developers than myself tried in the past and weren’t able to do according to Daniel. My idea was to make Present flip per CRTC only, but this would clash with Pixmaps being linked to the whole screen only. There are no Pixmaps only for CRTCs in X.

On the other hand when accepting the restriction of only being able to flip one window at a time my code already works quite good. The flipping is smooth and at least in a short test also improved the frame rate. But the main problem I had and still to some degree have, is that stopping the flipping can fail. The reason seems to be that the Present extension sets always the Screen Pixmap on flips. But when I test my work with KWin, it drives Xwayland in rootless mode, i.e. without a Screen Pixmap and only the Window Pixmaps. I’m currently looking into how to circumvent this in Xwayland. I think it’s possible, but I need to look very carefully on how to change the process in order to not forget necessary cleanups on the flipped Pixmaps. I hope though that I’m able to solve these issues already this weekend and then get some feedback on the xorg-devel mailing list.

As always you can find my latest work on my working branch on GitHub.