At the end of my previous post we concluded with yet another question. Indeed, on the 2017 KDEPIM contributor network we found out that Christian Mollekopf while being a very consistent committer didn't appear as centrality as we would expect. Yet from the topology he seemed to act as a bridge between the core contributors and contributors with a very low centrality. This time we'll try to look into this and figure out what might be going on.

My first attempt at this was to try to look into the contributor network on a different time period and see how it goes. If we take two snapshots of the network for the two semesters of 2017, how would it look? Well, easy to do with my current scripts so let's see!

Alright, it still looks similar to the picture we got for the full 2017... Christian is still on the outter rings of our network and bridging toward low centrality nodes. Only difference is that he has a slightly higher centrality value than during the whole year. Needless to say just that semester doesn't learn us much. Time to look at the second semester then.

Ah-Ah! Now we see something new, Christian is now mostly disconnected from the network! He is part of a clique containing him and Michael Bohlender. Looking further at their activity they are indeed focusing almost exclusively on Kube. Michael was in fact one of those low centrality nodes Christian was bridging to previously.

So what are we looking at? It seems to be the birth of an insular sub-team in the KDEPIM community. It's technically not a fork since they're working on a specific software but this clique configuration indicates they moved their focus there, they didn't attract the rest of the KDEPIM community to contribute (yet?) and they stopped contributing completely to the wider KDEPIM effort (at least for the time frame we've been looking at). The community got split there.

Now we could leave it at that and consider it like a detail... or... if you're like me and want not only to produce those graphs and metrics but wonder if some of those things could be turned into useful tools for community stewardship in general and the Community Working Group in particular, you won't stop there.

From the two networks above and the one I produced the last time it's clear that we need to deal with time... From a single network we freeze the time and get a configuration for a given period. If we ever want to see that something like the clique we saw appearing here can be detected we need a less static view.

For the time being, we will look at individual centrality of a contributor over time. For that we will get their monthly centrality value in the network over a three months sliding window (previous month, current month and next month). Since it's also interesting to have an idea of the activity of the contributor over the time period, we'll also plot the normalized monthly activity of the contributor. Finally, since centrality is dependent on the team size, we'll plot the normalized team size on the period.

Regarding that last plot, a few more words because it's a fairly important one that Volker Krause helped me realize during the KDEPIM sprint because of his own plots and discussing them with him, unfortunately it's also what makes the centrality tricky to read. The centrality value of a node is a value between 0 and 1, if a node is not connected at all it gets a 0 if a node is connected to all other nodes it gets a 1. So obviously, if the team is large you need way more connections to get a high centrality than in a small team.

Corollary of the point above is that centrality values variation are meaningful only during a stable team size. If we're a period of decreasing or increasing team size variations on a centrality can occur for a node even though it would have maintained the exact same connections! And that's why we have the third plot on the team size in the graphs below to get an idea on how much trust we can put in the variation of the centrality plot.

Alright, with that out of the way (although it'll keep haunting us while reading those plots), now it's time to explore those plots. We won't look only at one, I think it's a good idea to look at more than one contribution pattern before coming back to Christian. To get there and keep those plots somewhat comparable I'll drastically expand the time period we'll look at, instead of looking at 2017 only, we'll go all the way back to 2007! This way we can see more of KDEPIM's history and get patterns also from old timers. Let's start!

So first thing first, we see the evolution of the team size in KDEPIM on the last ten years. Interestingly we see the decrease that Paul Adams was pointing out in his last Akademy talk... but it's not reaching the ground and it looks like it stabilized at least since 2014. Is it the case for the whole of KDE? Does the commit activity look the same globally? Clearly questions I'll have to investigate as well, it never ends! :-)

In any case this variation on team size seems to indicate that we can look at the centrality variations from 2007 to end of 2009 or from 2014 to the end of 2017 somewhat safely. Of course the team size keeps varying but it's more noise than a real trend so it should be fine overall.

With that in mind, what we can see from Till is a former core contributor who slowly stopped to contribute. This is crystal clear just from his activity plot and the centrality plot as expected follows the same pattern. It's indeed less correlated with his activity in the 2010 to 2012 period but that's to be expected with the downward trend in team size.

This second graph is now about Volker Krause. We can see the top activity he had during 2009 and because the team size was large at the time it required such a high activity for him to have his centrality spike as well. The mystery spike of September 2016 is what prompted the display of the team size plot. He had only a very tiny activity that month which generated a surge in centrality... well it turns out that even though he did only a hand full of commits some of them were on build system files which tend to be touched by others and because of the smaller team size than in 2009 the variation get amplified.

So now that we're done with our two "example" core contributors... let's get back in the territory of the very active contributors of the past year...

Let's look at Laurent in this third graph, clearly he has been contributing to KDEPIM for a long time but overall not on a very high volume. It really started to increase around 2012 so I guess that's when he slowly took over maintainership of KMail. As expected that's when we see his centrality raising as well as he was getting involved with more and more components of KDEPIM. Of course it's slightly amplified by the decrease of team size over the 2012 - 2014 period but he kept getting more central even after that.

And finally, this fourth graph gets us back to Christian. Clearly he joined KDEPIM at the end of 2010, from that point on he looks like any other future contributor with increased activity correlating with increased centrality (watch out for the decrease of team size until 2014 which amplifies a bit the effect on that period). Then during 2014 we have a somewhat stable centrality and activity. Some noise but nothing out of the ordinary over a year. It gets interesting after that though. During 2015 we see his activity increasing again but at the same time his centrality starts dropping a first time. It then stays somewhat stable while his activity spikes. And toward the end of 2017 centrality completely drops. This is a very different pattern from all the other contributors we looked at.

In my opinion, the interesting observation is that by looking at the contributor network, we see the clique only appearing at the second semester of 2017, but, on the centrality graph we see this pattern of increasing activity with decreasing centrality starting in 2015! Two years before the community split is visible.

Now the question I have, and I think it'll be a tough one so I might leave it unanswered for a little while. Could we detect this kind of pattern early? Could we detect without too much false positive (even though there always will be some of them)?

I think it's important to think about that because in that particular case, assuming we'd have such a tool, the Community Working Group would have been warned of a team split to come and maybe step in to see if they could save the situation. Currently our Community Working Group is mostly working in reactive mode since they talk to people when a conflict emerges, with such a tool they could also try to be proactive and check on a team if the "increasing activity with decreasing centrality" pattern emerges. I think it would be nice if they could do this and talk to people before too many feelings were hurt.

It'll take time to get there, if at all. But I think it's worth looking into.

new gold editing pattern

• fix for dodge maximized visibility mode in multi-screen environment
• when copying default layouts make sure they are writable in the destination
• new protocol to communicate between applets and Latte in order to
  inform them when they are in a Latte panel/dock and when they dont want any change in their main icon behavior. (#983)

The Elisa team is happy to announce the first bug fix release for the 0.1 version.

The following changes have been integrated:

• c5bc988 search for more cover names in directory by Alexander Stippich (Fix bug 392843);
• 5113d00 remove the huge playlist icon by Alexander Stippich (Fix bug 392782).

One important note, Elisa is now available from flathub. Only the stable releases will be distributed through flathub.

Flathub Elisa page

This release also has a windows setup at the time of release. Thanks a lot to the help from the Craft and binary-factory teams. Without them, I would not be able to do it.

Elisa source code tarball is available here. The Windows installer is also available from this place.

Let’s have some more Usability & Productivity!

I’ve initiated a big project: overhauling KDE Open & Save dialogs for greater usability and productivity. If you would like to follow along, here is the meta-task tracking the work: https://phabricator.kde.org/T8552

So far, we’ve:

• Fixed column widths (Scott Harvey)
• Added view mode buttons to the toolbar (Me, Nate Graham)
• Made the dialog always save the view settings even when canceling or closing (Me, Nate Graham)

All of this work–and hopefully the rest of the “open/save panel improvement” work–will ship with KDE Frameworks 5.46.

(Also, what do people think of the above style for these bullet points instead of the typical one I’ve used below?)

As usual, there’s more! Here’s the other Usability & Productivity-related work from the past week:

New Features

• Kate and other programs using the KTextEditor framework gained syntax highlighting for GDB files (KDE Phabricator revision D11902, implemented in KDE Frameworks 5.46, authored by Milian Wolff)
• Konsole now supports more XTerm-style cursor shapes (KDE Bug 347323, implemented in KDE Applications 18.08.0, authored by Ahmad Samir)

Bugfixes

• Bold, italic, and underline effects now work again for Kate’s syntax highlighting modes (KDE Phabricator revision D12221, fixed in KDE Frameworks 5.46, authored by Christoph Cullman)
• Dolphin’s icon view grid spacing no longer changes unpredictably when previews are turned on or off, and has tighter spacing when previews are on and icons are large (KDE bug 393306, fixed in KDE Applications 18.04.1, authored by me, Nate Graham):
  
• Gwenview no longer crashes when zooming after reloading an SVG image (KDE bug 359736, fixed in KDE Applications 18.04.0, authored by Peter Mühlenpfordt)
• Gwenview’s “Failed to save” warning dialog no longer displays raw HTML in it (KDE bug 393170, fixed in KDE Applications 18.04.04, authored by Peter Mühlenpfordt)
• Okular no longer loses highlighted search results when a page is rotated (KDE bug 387282, fixed in KDE Applications 18.04, authored by Ahmad Osama)
• The Media Frame widget’s mode chooser now displays the modes corrently even for languages where the words are very long (KDE bug 393232, fixed in KDE Plasma 5.12, authored by Friedrich Kossebau)

UI Polish & Improvement

• Changes to a Konsole profile’s keybingings are now immediately applied to that profile (KDE Phabricator revision D12255, improved in KDE Applications 18.08, authored by Ahmad Samir)
• Plasma and Plasma widgets now all use the same color picker widget (KDE Phabricator revisions D12330 and D12318, fixed in KDE Plasma 5.13, authored by Friedrich Kossebau:
  
• Gwenview now positions the viewport more intelligently after crop and resize operations (KDE Phabricator revisions D12167 and D12170, authored by Peter Mühlempfordt)
• Gwenview no longer shows duplicate confirmation dialogs when overwriting an existing image (KDE Phabricator revision D12346, fixed in KDE Applications 18.04.1, improved by Peter Mühlenpfordt)
• The KDirOperator widget (commonly used for inline file browsers in apps like Kate, Kile, and RKWard, as well as open and save dialogs) now has a reload button in the context menu (KDE bug 199994, improved in KDE Frameworks 5.46, authored by me, Nate Graham)

Might seem a little light this week, but trust me, there’s a ton of stuff in progress right now. It may not quite be ready yet, but it will be awesome once it is!

If my efforts to perform, guide, and document this work seem useful and you’d like to see more of them, then consider becoming a patron on Patreon, LiberaPay, or PayPal.

In February after Plasma 5.12 was released we held a meeting on how we want to improve Wayland support in Plasma 5.13. Since its beta is now less than one month away it is time for a status report on what has been achieved and what we still plan to work on.

Also today started a week-long Plasma Sprint in Berlin, what will hopefully accelerate the Wayland work for 5.13. So in order to kick-start the sprint this is a good opportunity to sum up where we stand now.

QT_QPA_PLATFORM

Let us start with a small change, but with huge implications: the decision to not set the environment variable QT_QPA_PLATFORM to wayland anymore in Plasma’s startup script.

Qt based applications use this environment variable to determine the platform plugin they should load. The environment variable was set to wayland in Plasma’s Wayland session in order to tell Qt based applications that they should act like Wayland native clients. Otherwise they load the default plugin, which is xcb and means that they try to be X clients in a Wayland session.

This also works, thanks to Xwayland, but of course in a Wayland session we want as many applications to be Wayland native clients as possible. That was probably the rationale behind setting the environment variable in the first place. The problem is though, that this is not always possible. While KDE applications are compiled with the Qt Wayland platform plugin, some third-party Qt applications were not. A prominent example is the Telegram desktop client, which would just give up on launch in a Wayland session because of that.

With the change this is no longer a problem. Not being forced in its QT_QPA_PLATFORM environment variable to some unavailable plugin the Telegram binary will just execute using the xcb plugin and therefore run as Xwayland client in our Wayland session.

One drawback is that this now applies to all Qt based applications. While the Plasma processes were adjusted to now be able to select the Wayland plugin themselves based on session information other applications might not although the wayland plugin might be availale and then still run as Xwayland clients. But this problem might go away with Qt 5.11, which is supposed to either change the behavior of QT_QPA_PLATFORM itself or feature a new environment variable such that an application can express preferences for plugins and fallback if to the first supported one by the session.

Martin Flöser, who wrote most of the patches for this change, talked about it and the consequences in his blog as well.

Screencasts

A huge topic on Desktop Wayland was screen recording and sharing. In the past application developers had a single point of entry to write for in order to receive screencasts: the XServer. In Wayland the compositor as Wayland server has replaced the XServer and so an application would need to talk to the compositor if it wants access to screen content.

This rightfully raised the fear that now developers of screencast apps would need to write for every other Wayland compositor a different backend to receive video data. As a spoiler: luckily this won’t be necessary.

So how did we achieve this? First of all support for screencasts had to be added to KWin and KWayland. This was done by Oleg Chernovskiy. While this is still a KWayland specific interface the trick was now to proxy via xdg-desktop-portal and PipeWire. Jan Grulich jumped in and implemented the necessary backend code on the xdg-desktop-portal side.

A screencast app therefore in the future only needs to talk with xdg-desktop-portal and receive video data through PipeWire on Plasma Wayland. Other compositors then will have to add a similar backend to xdg-desktop-portal as it was done by Jan, but the screencast app stays the same.

Configure your mouse

I wrote a system settings module (KCM) for touchpad configuration on Wayland last year. The touchpad KCM had higher priority than the Mouse KCM back then because there was no way to configure anything about a touchpad on Wayland, while there was a small hack in KWin to at least control the mouse speed.

Still this was no long term solution in regards to the Mouse KCM, and so I wrote a libinput based Wayland Mouse KCM similar to the one I wrote for touchpads.

I went one step further and made the Mouse KCM interact with Libinput on X as well. There was some work on this in the Mouse KCM done in the past, but now it features a fitting Ui like on Wayland and uses the same backend abstraction.

Dmabuf-based Wayland buffers

Fredrik Höglund uploaded patches for review to add support for dmabuf-based Wayland buffer sharing. This is a somewhat technical topic and will not directly influence the user experience in 5.13. But it is to see in the context of bigger changes upstream in Wayland, X and Mesa. The keyword here is buffer modifiers. You can read more about them in this article by Daniel Stone.

Per output color correction

Adjusting the colors and overall gamma of displays individually is a feature, which is quite important to some people and is provided in a Plasma X session via KGamma in a somewhat simplistic fashion.

Since I wrote Night Color as a replacement for Redshift in our Wayland session not long ago I was already somewhat involved in the color correction game.

But this game is becoming increasingly more complex: my current solution for per output color correction includes changes to KWayland, KWin, libkscreen, libcolorcorrect and adds a KCM replacing KGamma on Wayland to let the user control it.

Additionally there are different opinions on how this should work in general and some explanations by upstream more confused me than guided me to the one best solution. I will most likely ignore these opinions for the moment and concentrate on the one solution I have at the moment, which might already be sufficient for most people. I believe it will be actually quite nice to use, for example I plan to provide a color curve widget borrowed from Krita to set the color curves via some control points and curve interpolation.

More on 5.13 and beyond

In the context of per output color correction another topic, which I am working on right now, is abstracting our output classes in KWin’s Drm and Virtual backends to the compositing level. This will first enable my color correction code to be nicely integrated and I anticipate in the long term will be even necessary for two other far more important topics: layered rendering and compositing per output, what will improve performance and allow different refresh rates on multi-monitor setups. But these two tasks will need much more time.

Scaling on Wayland can be done per output and while I am no expert on this topic from what I heard because of that and for other reasons scaling should work much better on Wayland than on X. But there is currently one huge drawback in our Wayland session: we can only scale integer factors. To change this David Edmundson has posted patches for review adding support for xdg-output to KWayland and to KWin. This is one step in allowing fractional scaling on Wayland. There is more to do according to Davd and since he takes part in the sprint I hope we can talk about scaling on Wayland extensively in order for me to better understand the current mechanism and what all needs to be changed in order to provide fractional scaling.

At last there is cursor locking, which is in theory supported by KWin, but in practice does not work well in the games I tried it with. I hope to start work on this topic before 5.13, but I will most likely not finish it for 5.13.

So overall there is lots of progress, but still quite some work to do. In this regard I am certain the Plasma Sprint this week will be fruitful. We can discuss problems, exchange knowledge and simply code in unity (no pun intended). If you have questions or feedback that you want us to address at this sprint, feel free to comment this article.

Last week I was at work and start to listen my boss said: "We need to show this to our director".  So I went to my coworker table to see what was happening. So they were using Gource to make a video about the git history of the project. Gource is a software version control... Continue Reading →

Virtlyst is a web tool that allows you to manage virtual machines.

In essence it’s a clone of webvirtmgr, but using Cutelyst as the backend, the reasoning behind this was that my father in law needs a server for his ASP app on a Win2k server, the server has only 4 GiB of RAM and after a week running webvirtmgr it was eating 300 MiB close to 10% of all available RAM. To get a VNC or SPICE tunnel it spawns websockify which on each new instance around 20 MiB of RAM get’s used.

I found this unacceptable, a tool that is only going to be used once in a while, like if the win2k freezes or goes BSOD, CPU usage while higher didn’t play a role on this.

Choosing a web interface for KVM/libvirt is no easy task, I have used Archipel and while it’s a nice app it is a pain to install, OpenStack is also overly complicated, and had a button labeled as “Terminate” button that deleted the instance entirely. A simple tool that’s specially simple to install was what I needed, and in fact is what a bunch of people need, here at work, OpenStack was also discarded due the hard installation process and a mix of virsh/virt-manager is used.

Since webvirtmgr is a DJango app, using it’s html templates was a breeze, Grantlee didn’t work with them out of the box, it has a few missing features but one can work around those, libvirt API is also quite well documented so development was quite fast, it took me 3 weeks but could easily be reduced to less than 2 if I had a bit more time.

So Virtlyst v1.0.0 is out, it uses less than 10MiB of RAM, and implements the VNC/SPICE web socket proxy in the same process thus each connections increases a almost nothing of memory usage. The software is already in production, and has all features of webvirtmgr except the migration part, that I plan to add in a future release.

Following the steps of some developer fellows I also created a Patreon account, so if you like what I do and would like to support my work please consider becoming a Patron.

Enough said, go get it!

https://github.com/cutelyst/Virtlyst/archive/v1.0.0.tar.gz

Startup is one of the rougher aspects of the Plasma experience and therefore something we’ve put some time into fixing

Why is startup slow?

The primary reason for Plasma startup being slow is simply that it does a lot of things, including:

• Session restore
• Config migration
• Setting keyboard layouts
• Most esoterically, making sure your colour scheme gets synced to the xrdb database, so that loading xfig or dia or any other pre-Qt/GTK1 application still has the correct colours in your Plasma session

Too many to list. This means it’s easily a whole second or more before we even start loading plasmashell, one of the more time consuming parts of startup.
This slow load gets exaggerated by us not removing the splash screen till everything is actually properly loaded.

However, it’s still an area we can improve.

About startup

Startup consists of mulitple components invoked at 3 different levels.

• Kcminit
  Config modules (kcms) typically update a system when the user applies the settings, however as we need to restore settings there is an optional hook called on startup for various modules.
• KDE Daemons (kded)
  Evolving from the more static nature above may services require running in the background waiting for external events. Some modules are loaded on demand, others are loaded explicitly during startup.
• Autostarted applications
  Meaning launcing core applications such as plasmashell/krunner as well as other applications a user might have selected; such as nextcloud or kgpg
• User shell scripts
  For anything else

These effectively all have their loading invoked at 3 different levels; as defined in the relevant kcminit/kded/autostart .desktop files. Note these may be shipped as core plasma, but can also include completely 3rd party items.

• Before plasmashell and other core autostart services
• Before user applications are restored / autoloaded
• After everything is restored and

A slightly more detailed version can be seen here.

Profiling

The most important part of any speed work is correctly analysing it.
systemd-bootchart is nearly perfect for this job, but it’s filled with a lot of system noise.

I’ve made a fork of systemd-bootchart that only tracks processes owned by that user on github.
To use put the following line into:
/etc/X11/Xsession.d/00-bootchart

/usr/lib/systemd/systemd-bootchart -o /tmp -r &

To profile wayland sessions, mod the SDDM config wayland SessionCommand option.

After 20 seconds an SVG will be placed in /tmp.

An example

Below shows the boot process of my personal machine. The important part to track is when ksplashqml gets destroyed, that signifies that boot is complete. In my case this happens after 4.5 seconds.

Just some of the many fixes

There have been and continue to be lots of tiny changes around the code. Mostly using the awesome tool hotspot here are just a few of the more significant and interesting ones.

A mysterious gap of nothingness

This stupid bug was caused by ksmserver blocking whilst it completed launching phase 1 of kded daemons before it continued onto loading the next section.
Problem is plasmashell and other GUI apps loaded in phase0 first task is to register with the X session manager, ksmserver. End result is we lockup in X code till
ksmserver is done. Solved by a logic rewrite.

Multiple starts of the same daemon

This is the result of the following code in a bunch of processes all started at once.

if (! serviceExistsOnDBus) {
startExecutable(…)
}

Whilst the daemon did handle this case correctly and the false starts aborted, it’s still a lot of time spend linking a process we don’t want.
Solution in this case was to port to DBus activation which is designed for this exact case.

Shortcuts writing on load

When profiling kglobalaccel5 we found it spent a lot of time writing entries on boot, which is a clear sign of something being wrong. The cause was quite complex. Powerdevil would report that the user visible name of the executable (kded) was “Powerdevil”. KScreen would load and report that the username of the executable (also kded) was “kded” this would cause the shortcut daemon to think locales had changed and forcibly reload and save everything.

Summary

Startup is an area that is being improved and we have tonnes of ideas left of things to do, but because it’s dealing with unpredictable 3rd parties it’s an area which requires 90% reading and 10% coding.

If you do have an excessively long boot time, please do try creating a boot chart as above, it will really help start to narrow down where we have problem. I hope to see some detailed reports on bugzilla soon.

Netrunner Pinebook

This week, there was the launch of Netrunner for Pinebook (1) (2). A lot of effort has gone into building the software, improving performance, getting automation and CI in place. That’s effort that benefits the wider KDE community, the wider Free Software-on-ARM community, and more. This is the laptop I’d take with me on a bicycle camping trip — clean, cheap and affordable, although heavier than a phone.

But there is an under-appreciated bit regarding images for an ARM laptop — or pre-installed Linux distro’s in general. And that’s the first-run experience. The Netrunner Pinebook image is delivered so that it boots to the Plasma 5 desktop, no passwords asked, etc. The user is called “live”, the password is “live”, and nothing is personalized. It’s possible, though not particularly secure, to use the laptop this way in a truly disposable fashion. A first-run application helps finalize the configuration of the device by creating a named user, among other things.

One of the under-documented features of Calamares is that it can operate as a first-run application as well as a system installer. This is called “OEM Mode“, because it’s of greatest interest to OEMs .. but also to distro’s that ship an image for users to flash onto (micro)SD card for use in a device.

Main Desktop on Pinebook

This screenshot is from Netrunner on the Pinebook, and you can see the purple-ish Calamares logo labeled “First Time Run This Installer” on the desktop — it’s partly hidden by the system information KCM. That runs Calamares in OEM mode, hardly distinguishable from the live-ISO-installer-mode that it usually has.

A Calamares OEM configuration generally:

• Resizes the image file to fill the entire card,
• Creates a user (the real one, personalised) with a password,
• Performs some initial configuration of the real user,
• Adds packages and system configuration based on that configuration, and
• Does some cleanup (e.g. removing Calamares, since you only need it once).

Configuring Calamares as an OEM installer is no different from any other Calamares installation: make sure the config files end up in /etc/calamares, and then set dontChroot to true (that’s the real difference between OEM mode and regular).

The way Calamares development works, downstreams — that is the distro’s, and in this case Netrunner — just file feature requests for the stuff they need in Calamares, and after some back-and-forthing to make sure it’s sufficiently general, I write it. So the run up to Netrunner on the Pinebook saw some Calamares development aimed specifically at the OEM mode, and some extra bug reports. Nothing, though, that isn’t equally applicable to any other distro that needs a first-run installer.

There is a lot more that could be done in a first-run installer. KaOS has a really nice one, basically hand-holding through initial KDE Plasma Desktop setup. Pardus and Pisi Linux have something similar. A downside is that the more you do, the more specialized it becomes — it would be nice to have a good GNOME counterpart to the Plasma Look-and-Feel selection module in Calamares, but that quickly leads to a multitude of modules and dependencies (not to mention that I can’t write it all myself).

Anyway, that’s my little square inch claim to being useful to the Netrunner Pinebook project (which deletes itself).

Calamares is a distribution-independent (Linux) system installer. Outside of the “big five” distro’s, many smaller “boutique” distro’s need an installer, and Calamares is a highly configurable one that they can use. There’s a few dozen distro’s that I know of that use it (although I’ve only actually installed maybe six of them).

One optional feature — optional at the discretion of the distro which is deploying Calamares, that is — is the use of GeoIP location to find the time zone of the device being installed. This is used to automatically set the clock, for instance. If it’s not switched on, or there’s no network, Calamares defaults to a location defined by the distro — generally New York, although there’s an Austria-based distro that I think defaults to UTC.

For years, the default and suggested GeoIP provider has been freegeoip.net. That service is shutting down — well, being upgraded to a nicer API, at a different location, and with different access limitations. Older ISO images that have Calamares configured to use GeoIP with that service will cease to get usable GeoIP data on july 1st, 2018.

I don’t actually know which distro’s have GeoIP enabled, nor what provider they use.

However, the fact that this provider is shutting down prompted me to go over the existing code and make it more flexible and more general (prodding from Gabriel and Phil and Harald helped here as well). So Calamares is now ready to use more, and different, providers of GeoIP data. The providers can’t agree on using “time_zone” or “timezone” or “TimeZone” as the attribute (JSON) or element (XML) name where the data lives, so there’s a little bit more code and configuration needed. But you (as a distro) can now shop around and pick a GeoIP provider that respects your privacy.

I use to joke that the last week before foss-north is the worst – everything is done, all that is left is the stress.

This year, we have the broadest program yet. 25 speakers talking about everything from community policies, GPU isolation, blockchain, historical KDE software, retro computers, IoT, Android, SailfishOS, bug triaging, crowd funding, software updates, yocto, home automation, design to sub-atomic particles.

You can still get a ticket (and make sure to bring a friend) at foss-north . Welcome!

The latest release of CMake has landed in FreeBSD. Prior to release we had good contact with KitWare via the bug tracker so there were few surprises left in the actual release. There were still a few last-minute fixes left, in KDE applications no less. Here is a brief summary of changes we made:

• FindQt doesn’t match the way FreeBSD ports are built and installed, so we defer to QMake rather than looking for directories,
• FindOpenMP gets a tweak because it won’t find the system pthreads library when gcc (for Fortran) is used,
• FindBLAS gets a larger tweak because BLAS may need to link to libgcc_s, and which gcc_s that is needs to be figured out via ldd(1).

Some older patches have gone away because upstream has picked them up. Tweaks downstream, in package-building-terms, of cmake that were necessary:

• check_include_files respects the required libraries, which can be a surprise when the required libraries have been found but not fully plugged into the build (e.g. missing -L flags).
• the order of includes in automoc sources has changed, which reveals places where a C++ header file doesn’t actually include all of the headers it needs to fully define the types it uses; previously the include order might implicitly include them and the issue is papered over.

CPack now fully supports producing FreeBSD packages from a build / install tree by default, so for non-ports software which uses CMake, cpack -G FREEBSD does the right thing. Previously, this was a non-default tweak to CPack as built in FreeBSD ports.
Edit: as of CMake 3.11.0_1, CPack no longer supports producing FreeBSD packages. There were some unexplored corners of the build process that cause build failures when the FreeBSD pkg(8) support is enabled. So it’s off again until we shine some more light into those corners.

.. and a PS., CMake 3.11.1 has just been released, which reverts the change to check_include_files which I’d been working around.

“I put Qt on my ARM” : The only fun thing about ARM ever

The team over at Netrunner have just announced the launch of Netrunner 18.03 Idolon for the Pinebook. This is the direct result of a year of collaboration between the Netrunner, Pine and KDE Communities in a effort to drive down memory consumption, fix glitches in the graphics stack and enabling accelerated video decode, all of which has resulted in a product that showcases the coming together of the amazing software from KDE and some brilliant hardware engineering from the folks over at Pine.

It’s been quite a journey for my colleagues and I at Blue Systems in putting together this product. We have had to delve into areas where we originally did not have the expertise to fix bugs and constantly push the boundaries of our abilities. This was especially challenging in the ARM world since there are parts of the stack that were proprietary, meaning we cannot debug those parts, leading to many frustrating evenings having been spent on trying to reverse engineer buggy behaviour.

Personally, the launch of Netrunner on the Pinebook marks a milestone towards a goal that I’ve wanted to see realised ever since I discussed it with my peers at UDS N, nearly 10 years ago: Delivering Plasma on cheap and affordable computing devices. Being able to run a fully accelerated open source desktop environment on a device that costs 100 USD to me is a amazing accomplishment. It confidently signals to the world that Plasma is a versatile and mature product that spans across form factors and offers a compelling  alternative to other main stream products on these low end devices.

Shameless Plug: If you enjoy using KDE’s software products, please consider donating

This blog is about KDE Connect, a project to communicate across all your devices. For example, with KDE Connect you can receive your phone notifications on your desktop computer, control music playing on your desktop from your phone, or use your phone as a remote control for your desktop.

In my previous blog, I told you about some of my improvements to the remote media control of KDE Connect. I ended with a note that local album art was not supported yet. Also, no album art was displayed in the media notification or on the lock screen. In the meanwhile, both features have been implemented! If you have KDE Connect 1.8.1 on Android, and KDE Connect 1.3 on your desktop, you'll have both of these features. So all your album art from VLC or Elisa is now visible on your phone!

Secondly, I've been working a bit on KDE Connect's bluetooth support. The code was mostly working already, but the remaining stuff is (of course) the hardest part! Nevertheless, more and more parts start working, so I assume it'll come your way in a couple of months. I'll post an update when it's ready for testing.

For, quite literally a year or more, KMail and Akonadi on FreeBSD have been only marginally useful, at best. KDE4 era KMail was pretty darn good, but everything after that has had a number of FreeBSD users tearing out their hair. Sure, you can go to Trojitá, which has its own special problems and is generally “meh”, or bail out entirely to webmail, but .. KMail is a really great mail client when it works. Which, on Linux desktops, is nearly always, and on FreeBSD, iswas nearly never.

I looked at it with Dan and Volker last summer, briefly, and we got not much further than “hmm”. There’s a message about “The world is going to end!” which hardly makes sense, it means that a message has been truncated or corrupted while traversing a UNIX domain socket.

Now Alexandre Martins — praise be! — has wandered in with a likely solution. KDE Bug 381850 contains a suggestion, which deserves to be publicised (and tested):

sysctl net.local.stream.recvspace=65536
sysctl net.local.stream.sendspace=65536

The default FreeBSD UNIX local socket buffer space is 8kiB. Bumping the size up to 64kiB — which matches the size that Linux has by default — suddenly makes KMail and Akonadi shine again. No other changes, no recompiling, just .. bump the sysctls (perhaps also in /etc/sysctl.conf) and KMail from Area51 hums along all day without ending the world.

Since changing this value may have other effects, and Akonadi shouldn’t be dependent on a specific buffer size anyway, I’m looking into the Akonadi code (encouraged by Dan) to either automatically size the socket buffers, or to figure out where in the underlying code the assumption about buffer size lives. So for now, sysctl can make KMail users on FreeBSD happy, and later we hope to have things fully automatic (and if that doesn’t pan out, well, pkg-message exists).

PS. Modern KDE PIM applications — Akonadi, KMail — which live in the deskutils/ category of the official FreeBSD ports were added to the official tree April 10th, so you can get your fix now from the official tree.

This post is the continuation of the previous one, titled Dear software manager, working in the open for the very first time? Face the challenges (I)

Focus shift

I understand the transition that a front line manager needs to go through when moving to work in the open as a personal journey, mostly because the challenges described in the first post of this series, specially those related with personal values, have had a significant impact on who I am today.

I believe that working in the open long enough will charge not just the way you understand your work but other aspects like your personal relations, your view as a professional… you mindset. The key question to me is how to drive that change in a way that you do not use trial-error as the number one technique to learn, knowing that, unlike in the case of most developers, as a manager your mistakes have a significant impact on those around you.

I strongly believe that habits change mindsets, not the other way around. Which translated to a job means that in order to adapt to a new way of thinking it is required to work in a different way.

So in my opinion, in order to succeed faster as a front line project manager in the open you will need to embrace new habits as a manager. And I know by experience that the transformation process is faster when you realise that it is not just about changing the mechanics of your work but also about shifting your focus.

This is the core idea I want readers to take away. It is not just about adapting what you were doing already within your company, but also shifting the focus of your work to make a meaningful impact in a different area.

From autonomy to alignment

I created a model that helped me to understand where I was, what I needed to focus on in order to succeed as a manager, as a team, as an organization or project. I will provide some information about this model since so I can use it to describe that focus shits I mentioned before.

My personal model can be summarised in a cycle with four stages. I have written about this before, by the way:

toscalix management model

I came to this model through a bottom-up approach, as a result of my experience working in open organizations. The structure in these four stages came from two key popular references:

• The motivation model described by Daniel Pink in his famous book Drive.
• The challenges described by Nilofer Merchant in her book The New How, when moving from strategy to execution in order to innovate. Those challenges many organizations go through led Nilofer to the description of the air sandwitch problem and how to approach it: alignment.

You can find references to both books in the Reads section of this site.

In corporate/in-house projects, front line managers mostly focus on what in the model refers to autonomy. They are perceived as successful when the people they manage are efficient which build trust on development teams, who get more room to work their way. Managers can then focus on effectiveness, risk evaluation, and mitigation activities, etc. increasing their impact and allowing them to help the engineering teams to a greater extend.

In my experience, the initial focus of most front line managers when working in the open is learning the new mechanics that would allow them to increase efficiency first and effectiveness later on of those around them. That might not be a bad approach since sometimes in Open Source projects, efficiency is a significant issue. At the very end, we all want to add value since day one, right?

But often this approach lead those managers to become the project escribe, doing  non-technical work with lower impact they are used to: driving meetings, documenting, etc. I have seen many people in Open Source, even other managers who went through the same process, justifying this approach as necessary to learn the new culture while adapting to the new environment. In other words, you play the role of a junior instead of a newcomer, living in first person a tough contrast when comparing the role you play in the open with the one you play within their companies.

When working in the open, I strongly believe that the key point to significantly shorten the time frame required for a front line manager to add real value to the project is to put emphasis from day one in alignment.

In most companies, this is the focus of more senior managers, so front line managers partially lack the skills and experience required to make a positive impact in alignment early on. At the same time, working in the open represents a unique opportunity to develop those skills and experience without many of the constrains and responsibilities associated to a senior management role.

Execution alignment based on the project goals (shared vision) represents one of the outstanding challenges in Open Source projects, so the main opportunity for a front line manager to add real value.

Back to the personal journey approach, there are several habits that managers will need to change in order to get the right mindset to succeed. I will focus on the two I think are more important, and tough at the same time.

Key habits to change

Back to the personal journey approach, there are several habits that managers will need to change in order to get the right mindset to succeed. I will focus on the two I think are more important, and tough at the same time.

The first one is the management style. As a manager you will need to transit towards coaching as the main style. If directive is the default one in your organization, your journey will be longer and tougher than if your style can be identified already as affiliative. There is plenty of literature about management styles but sadly not much (for this context) about the next habit.

The second one is transparency, which has different requirements and implications for a manager than for a developer working in the open, since they hold a different responsibility within their organizations compared than in the Open Source projects towards their managees.

Let me clarify an interesting aspect of transparency.

There are restaurants where the kitchen is exposed to the customers. We all can see if it is clean, if there is a good working atmosphere, who is the chef and who clean the dishes, etc. Many people feel better in those restaurants because for them, selecting a restaurant is not just about getting tasty food at a reasonable price from a good service.

But is it exposing your kitchen being transparent?

Out of what the experience as a customer, an accountant can tell more meaningful information about that restaurant by looking at the numbers that somebody like me can tell by looking at the kitchen, since I have no clue about cooking. Transparency and exposure are not the same thing.

A key goal as a manager working in the open is to figure out how to drive a symbiotic relation between the organization the team belongs to and the Open Source project and their participants. Transparency at a personal, team and organization level is so important that should be practised since day one. Again, transparency and exposure are not synonyms.

Conclusion

Working in the open involve new challenges that requires a different mindset to be successfully faced by front line managers moving from corporate to Open Source projects. They will need to develop new habits and the most effective way to do so, in my view, is understanding since day one that your focus will need to move towards alignment instead of insisting in autonomy, according to my mental model. With that in mind, my advice is to pay special attention to those habits that will lead you to become a servant for your managees, promoting transparency by example…

…together with a good doses of patience and tolerance to public criticism.

After the shoving is done — and it is, for the most part — it is time to fill up the void left behind by the KDE4 ports that have been shoved aside. In other words, all over the place <foo> has been shoved aside to <foo>-kde4, and now it’s time to reintroduce <foo>, but in the modern KDE Applications form. For instance, there is now a science/kalzium-kde4 (the old stuff) and a science/kalzium (the new stuff). It’s not 100% complete, but most of the applications are there.

Tobias has been the driving force behind this, with ports commits like r466877 which introduced the modern KDE applications in science/. So a huge shout-out to his work in bringing things almost-up-to-date.

Note that we now have KDE Frameworks (5.44 .. there’s an exp-run planned for this week’s 5.45 release) and KDE Applications (17.12.3) but not a Plasma 5 Desktop; so you will be running KDE Applications on the older desktop of your choice if you’re using FreeBSD ports.

Warning: these two posts are a “Lessons Learnt” kind of post, so there is a grandpa kind of smell on it that I am not sure I am comfortable with so there is very little science.

I’ve got lately a few questions from managers about different aspects involved in the transition to working in the open when coming from a traditional corporate environment. This post and the next one are an attempt to answer some of those questions.

In this post I will focus on describing some of the challenges any manager will face and a second one will deal with how to face them.

I will constrain my comments to management aspects, ignoring as much as possible the leadership topic, although they are related. These two articles target what I call front line managers, not senior managers (managers of managers) nor executives. By front line managers I mean those that is in daily contact with developers and that represent, in a top down view of an organization chart, the lower management level. It is true though than many of the ideas you will read  might be valid to other profiles. You tell me.

Challenges

When moving from managing software projects/teams in classic corporate environments into Open Source  (FOSS) projects, there are several new challenges any front line manager will need to face. I group them here in four categories:

• Challenges derived from the fact that Open Source projects are public and open.
• Challenges related with the FOSS culture which has some unique characteristics.
• Open Source has a project nature different in many aspects from the service/product nature most companies have.
• Working in the open implies new challenges from a more personal point of view, involving values, motivations, etc.

Feel free to add more challenges that those named below. I would go over them.

Challenges: public and open

Some of the challenges corresponding to this category, in my opinion are:

• In open environments like Open Source projects, no matter if they are community, company or consortium driven, technical leadership is as relevant (or even more relevant) than any other type of leadership, including business leadership.
• Open Source development and delivery are all about distributed teams and, in most cases, about  multicultural teams.
• Every aspect of the project needs to consider asynchrony by default. I find this challenge one of the most difficult to understand early on for those coming from corporate environments, even from big corporations, since managers tend to be familiar with concentrating specific roles and responsibilities per site/location, even when high availability is a business requirement.
• When working in the open, you not just represent yourself, but also the organization you belong to. This is magnified when talking about managers because very frequently they are also perceived as the voice of the team they manage, which is not necessarily the case every time.
• Front line managers are familiar with dealing with private and confidential information, but working in the open brings new challenges in this regard. This seems obvious. But what in my experience is not so obvious, because it is very often not part of front line manager’s responsibilities within their companies, is to deal with the preparation, communication and consequences of making corporate/internal information public, for instance. There are other interesting cases to consider in this regard.

Challenges: culture

• In Open Source, openness is a given, although depending on the governance model of the project, there might be different degrees. The same applies to sharing.
• One of the pillars that has made Open Source so successful is code ownership. If you develop it, you own it, which means that you are expected to maintain it. I have written several times before about how important this point is for the professional and personal growth of any developer. I know a few that, by the time they turned  20, they were already maintaining software used by thousands of people. That is something no college will teach them… nor most companies, sadly. There are still many so called senior engineers that haven’t dealt with the consequences of their own code or the one done by their teams for a few years. The agile movement, through promoting the micro-service architecture, has recognised how important this point is. Development teams are in charge of maintaining what they deploy in production. Still, Agile has not reached the level taken in this regard by Open Source.
• Standardisation through adoption. This concept is significantly different in corporate environments. The success that Open Source is having though is slightly changing the approach to standardisation many corporations have. There is still a long way to go.
• Consensus is as important as efficiency in Open Source projects. Some people talk about consensus driven development when referring to Open Source development to highlight how important this aspect is. Corporate managers and executives very often perceive Open Source development as significantly slower compared to developing in-house, which technically speaking might be true in some cases. They underestimate though the benefits that consensus has within a project overtime, specially when talking about the motivational aspects, when dealing with complex problems, interoperability, etc..
• Documentation always beats meetings, always. I go even further. Meetings are so expensive and precious in highly distributed environments, that front line managers go through a lot of pain until they learn to focus meetings on discussing instead of reporting. This is a fundamental disagreement I have with the stand up concept, by the way. And I am not the only one. Reporting should not be part of any meeting. Period. Document and read reports up front.
• Open Source is all about specialists (aka rock stars) instead of about teams. Front line managers have a particularly hard time dealing with “unique personalities” in the open. The tools they’ve learn to deal with them are very often not valid in the new environment. As I have written before, the team culture is one of the assets that corporations are bringing into Open Source.

Challenges: project nature

• Open Source projects are mostly related with R&D, technology or tooling development and, in some cases, specially in company driven communities/projects, about pre-production (early productization stages). They are not about developing products or services which is what corporations are mostly about, even when dealing with R&D. This difference requires, for example, that front line managers pay constant attention to value-capture-and-return cycles between the project and the company.
• Within Open Source projects, the relation among organizations is not common to many managers coming from corporate environments. Other organizations are treated as partners instead of customers, even if they are service providers or suppliers. In a similar way somebody you work with is a peer, even when talking about members of their teams (managee).
• Looking at delivery, in Open Source is frequent to release features when ready, on a time based release cadence, which helps to coordinate many different parties. Within most organizations, not even R&D delivery is managed this way. Lately, rolling/continuous approaches are becoming popular among FOSS projects. This way of understanding delivery is very often tough for managers risen in the “deadline drama” culture.
• When taking decisions in the open, front line managers need to adapt to the fact that developers think about the project as much as they think about the company they belong to. Sometimes even more. Who pays your salary and what for are common question among those managers who do not fully understand yet the environment they are working on. They get the perception that people tend to forget the corresponding  answers after a while working in the open.
• I always ask managers working in the open about their definition of success for the teams they manage. By their answers I learn a lot about the transition stage they are in. Defining success, even in FOSS projects with a clear shared vision, might become tough. And it is so important to have an agreed definition by every team member…. In general, a definition of success for a team working in the open should consider at least these elements:
  • The project/community.
  • The company or organization that pays the check.
  • How is the value capture-return cycle defined for both, the company and the project.
  • Additional aspects that motivates the team.

Challenges: personal values

• Front line managers, specially those with little exposure to customers, are not familiar with every aspect involved in professional reputation. It is a relevant concept when your work is public and can be directly associated to you. It is so powerful that it is easily mistaken with the most negative aspects of “ego”. Senior managers coming from corporate environments understand it better but still not fully. Reading or talking about it, listening to those who has been there, working with them, is not enough to get what is like to be on the other side. You need to cross the river to understand it.
• Open Source was born out of strong ethical values. So strong that they are still relevant to many. FOSS is now mainstream so most think that those values are disappearing, being relevant only to the “senior geeks” working in some specific projects. I believe though that those ethical values still matter and, in my experience, the longer people is involved in Open Source, the more relevant they become for them, no matter where they come from. It takes time for anybody coming from corporate environments to fully understand the impact some of these values have and their implications in day to day activities. These values tend to to manifest vigorously when conflicts arise.
• One of the things that everybody learn very soon when collaborating in Open Source projects is that people have “two different personalities” which in some cases diverge: the offline and the online personalities.

These challenges, and many others not mentioned above, will require different levels of attention at different stages of the adaptation/transition process to any manager. So in one way or the other, they will need to develop skills and accumulate experience to successfully face them.

A second post describes some ideas about how to approach these challenges when joining an Open Source project as a manager.

Time for your weekly dose of Usability & Productivity! We’ve got some good stuff today, including some nice improvements for the Open & Save dialogs–with a lot more on that front to come soon!

Additionally, another major bug worth highlighting has been fixed! Previously, image slideshows used for the desktop wallpaper or in a media frame widget would leak memory like crazy, eventually crashing the system. Veteran KDE developer David Edmundson traced this to a Qt bug and submitted a patch that’s been accepted! It’ll go into Qt 5.11 which hasn’t been released yet, so go bug your distros to backport the fix into their Qt 5.9.x or 5.10.x branches, as we plan to do for the upcoming Kubuntu 18.04 release. Soon KDE Plasma users will once again be able to use slideshow wallpapers without blowing up their computers!

But wait, there’s more…

New Features

• When audio is set to switch to new sources that become active, this is now indicated with an on-screen display depicting the new device (KDE Phabricator revision D12083, implemented in KDE Plasma 5.13, authored by Kai Uwe Broulik):
  
• You can (once again!) copy the text of the date and time from the Clock widget (KDE bug 355190, implemented in KDE Plasma 5.13.0, authored by Bernhard Schiffner))

Bugfixes

• Fixed a bug that prevented removable devices from automounting correctly (KDE bugs 391706, fixed in KDE Plasma 5.12.5 and KDE Frameworks 5.46, authored by Stefan Brüns)
• Fixed a bug that could cause Plasma to crash when switching the desktop from Folder View to Desktop View (KDE bug 391642, fixed in KDE Plasma 5.13.0, authored by David Edmundson)
• Fixed a bug that could cause Konsole to not copy long text correctly under certain circumstances (KDE bug 352616, fixed in KDE Applications 18.08.0, authored by Mariusz Glebocki)
• Fixed a bug that could cause Gwenview to not update an image’s thumbnail in the Thumbnail bar after rotating it (KDE bug D11714, fixed in KDE Applications 18.04.0, authored by Peter Mühlenpfordt)
• Fixed a bug in Gwenview that could cause an image’s thumbnail to not update properly after undoing a crop or rotate operation (KDE bug 356998, fixed in KDE Applications 18.04.0, authored by Peter Mühlenpfordt)
• Fixed a bug in Gwenview that could cause changed shortcuts to not take effect until after the program was restarted (KDE bug 389331, fixed in KDE Applications 18.04.0, authored by Peter Mühlenpfordt)
• Fixed a bug causing Baloo (KDE’s file indexing service) to incorrectly
  handle complex boolean queries (KDE bug 392620, fixed in KDE Frameworks 5.46, authored by Stefan Brüns)

UI Polish & Improvement

• Columns in KDE Open & Save dialogs are now always sized correctly, and resize appropriately as the window is resized (KDE bugs 354388, 338502, 196508, 177743, and 96638, improved in KDE Frameworks 5.46, authored by Scott Harvey):
  
• The Open dialog now opens in the correct location when using a file located on a remote filesystem (KDE bug 374913, improved in KDE Plasma 5.12.5, authored by Alex Richardson)
• A consistent (and better) icon is now used for “configure” everywhere (KDE Phabricator revision D12034, improved in KDE Frameworks 5.46, authored by me, Nate Graham):
  
  
  
• The login screen now uses the same icon as the Lock screen for the “find or log in as other user” feature (KDE bug 392830, improved in KDE Plasma 5.13.0, authored by Scott Harvey)
• Dolphin’s Information Panel can now optionally show condensed absolute dates rather than long relative dates – try right-clicking on it! (KDE bug 392352, improved in KDE Applications 18.08.0)
• Gwenview now displays a better background for parts of images that are transparent, and lets the user configure more alternate backgrounds if desired (KDE Phabricator revision D11630, improved in KDE Applications 18.08.0, authored by Huon Imberger):
  
• Gwenview now honors the chosen background color setting for SVG images (KDE bug D11629, improved in KDE Applications 18.08.0, authored by Huon Imberger)
• Gwenview’s transition effect between images has been improved (KDE bug 373161, improved in KDE Applications 18.08.0, authored by Huon Imberger)
• Dolphin’s “Open path” and “Open path in new folder” actions now scroll to and highlight the selected file (KDE bug 377510, improved in KDE Applications 18.08.0, authored by me, Nate Graham)
• Non-square icons can now be used for the Application Launcher’s button (KDE Phabricator revision D12161, improved in KDE Plasma 5.13.0, authored by Kai Uwe Broulik):

  

If my efforts to perform, guide, and document this work seem useful and you’d like to see more of them, then consider becoming a patron on Patreon, LiberaPay, or PayPal.

Tomorrow, I’ll be heading to Piter (St. Petersburg) for acclimatization training before the C++ Russia 2018 conference starts.

C++ Russia – the track in English

While most talks at C++ Russia are in Russian, this year will have more than a few amazing talks in English – from famous names like Andrei Alexandrescu, Jon Kalb and Herb Sutter, to a few less famous ones including yours truly. :)

My talk will be a bit out of my comfort zone – it will not be about monads nor any other aspect of functional programming. I’ll be talking about modern meta-programming for C++17 and 20 – the void_t meta-function and the detection idiom.

If you happen to be close to Piter, join us (the tickets are available at cppconf.ru) or if you just want to grab a beer, send me an e-mail.

---

You can support my work on , or you can get my book Functional Programming in C++ at if you're into that sort of thing.