Language Selection

English French German Italian Portuguese Spanish

Kde Planet

Syndicate content
Planet KDE -
Updated: 1 hour 59 min ago

Kate LSP Status – July 22

6 hours 41 min ago

After my series of LSP client posts, I got the question: What does this actually do? And why should I like this or help with it?

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

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

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

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

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

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


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


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

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

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

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

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

Feel welcome to show up on and help out! All development discussions regarding this plugin happen there.

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

KDE ISO Image Writer – GSoC Phase 2

7 hours 56 min ago

As mentioned in my previous blog post, the new user interface was functional on Windows. However, the application had to be run using root on Linux to be able to write an ISO image to a USB flash drive.


The original user interface used KAuth to write the ISO image without having to run the entire application with root privileges. KAuth is a framework that allows to perform privilege elevation on restricted portions of code. In order to run an action with administrator privileges without having to run the entire application as an administrator, an additional binary (KAuth helper) which is included alongside the main application binary will perform the actions that require elevated privileges. This approach allows privileges escalation for specific portions of code without granting elevated privileges for code that does not need them. After integrating the existing KAuth helper into the new user interface, it was able to write ISO images by asking for authorisation when required.

Finalising The User Interface

In addition to implementing the KAuth back-end, I polished the user interface and I implemented additional features such as drag and drop support which allows the user to select an ISO image by simply dropping a file on the application window.

KDevelop 5.4 beta 1 released

10 hours 27 min ago

KDevelop 5.4 beta 1 released

We are happy to announce the release of KDevelop 5.4 Beta 1!

5.4 as a new feature version of KDevelop will among other things add some first support for projects using the Meson build system and have the Clang-Tidy support plugin merged as part of built-in plugins. It also brings 11 months of small improvements across the application. Full details will be given in the announcement of the KDevelop 5.4.0 release, which is currently scheduled for in 2 weeks.


You can find the Linux AppImage (learn about AppImage) here: KDevelop 5.4 beta 1 AppImage (64-bit)
Download the file and make it executable (chmod +x KDevelop-5.3.80-x86_64.AppImage), then run it (./KDevelop-5.3.80-x86_64.AppImage).

The source code can be found here: KDevelop 5.4 beta 1 source code

Windows installers are currently not offered, we are looking for someone interested to take care of that.

kossebau Mon, 2019/07/22 - 18:30 Category News Tags release

KDE Connect sprint 2019

13 hours 26 min ago

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.

From friday the 19th to sunday the 21st, we had the KDE Connect sprint. It's always a nice opportunity to meet the others working on KDE Connect, since we usually only talk to each other online.

Lots of activity at the KDE Connect sprint! (Also some KWin & Onboarding sprinters)

On arrival on friday, we immediately got the first issue to fix: the Wi-Fi at the sprint blocks UDP broadcasts. That means KDE Connect couldn't find any device. Adding the IP-addresses makes it work again, but it's a good reminder to actually improve this situation.

On friday and saturday, we had a lot of discussions about projects to improve KDE Connect architecturally. Those are:

  • Not keeping TCP connections open to all reachable devices (really a problem when there are like a 100 devices)
  • Making KDE Connect better on Wayland
  • Google locking down Android more and more, and how to handle that
  • Using mDNS (a.k.a. Avahi/Zeroconf/Bonjour) to discover KDE Connect devices
  • Improving the buggy bluetooth backend

Specifically on bluetooth: it is very hard to make it work on all devices. We're slowly making some progress, though.

Besides that, we worked on lots of smaller features and lots of bugfixes, of course. For example, I changed the Android app to not create a thread for everything single thing we send. This matters a lot for the mousepad plugin, which sends many small packets.

In short, the sprint was great! Thanks SUSE for hosting this sprint!

Python binding for Kuesa

14 hours 16 min ago

KUESA™ is a Qt module designed to load, render and manipulate glTF 2.0 models in applications using Qt 3D.

Kuesa provides a C++ and a QML API which makes it easy to do things like triggering animations contained in the glTF files, finding camera details defined by the designer, etc.

It is a great tool so that designers and developers can share glTF based 3D assets.

With the upcoming release of Kuesa 1.1, we are introducing a python binding for Kuesa. This provides a simple yet powerful way for programmers to integrate glTF content in their python applications with just a few lines of code.

Building Kuesa’s Python binding

The first step is, of course, to build and install Kuesa itself. Instruction are available here, it’s a simple process. Kuesa is a Qt module so it typically installs inside Qt’s standard folders.

Next step is to install Python for Qt, AKA PySide. Note that you must install it for the same version of Qt that you compiled Kuesa with.

If you’ve built your own version of Qt, fear not. Building the python binding for that is fairly easy and quick.

In all cases, we would recommend you use a python virtual environment. This will let you install several versions of the Qt bindings.

Once you’ve installed Python for Qt, you’re ready to build the Kuesa binding.

Building bindings for C++ libraries is a relatively simple process which uses several things:

  • a header file which includes all the C++ headers for the files you want to build bindings for
  • an xml file which lists all the classes and provides helper information for the binding generator. This contains details about enums, can help hide C++ methods or properties, etc
  • a binding generator, Shiboken which parses the C++ headers and generates C++ code that implements the binding

The code for the binding, inside Kuesa’s src folder, contains a CMake project file which takes care of all the details.

So assuming the python virtual env is active and the right version of Qt is in the path, building the binding should be as easy as:

cd .../src/python mkdir build cd build cmake .. make make install

Note: the version of Python for Qt which ships with the 5.12 series is incomplete in it’s coverage of Qt 3D. In particular, some useful classes were missed in the animation module, like QClock which is useful to control the speed and the direction of the animation. We have submitted a patch for PySide which fixes this and it was merged in 5.13.

Your first Kuesa application with Python

Kuesa ships with a simple python application that demonstrates the use of the binding.

The application starts by importing the various required modules:

from PySide2.QtCore import(Property, QObject, QPropertyAnimation, Signal, Slot) from PySide2.QtGui import (QGuiApplication, QMatrix4x4, QQuaternion, QVector3D, QWindow) from PySide2.QtWidgets import (QWidget, QVBoxLayout, QHBoxLayout, QCheckBox, QPushButton, QApplication) from PySide2.Qt3DCore import (Qt3DCore) from PySide2.Qt3DRender import (Qt3DRender) from PySide2.Qt3DExtras import (Qt3DExtras) from PySide2.Qt3DAnimation import (Qt3DAnimation) from Kuesa import (Kuesa)


The scene graph will need a SceneEntity and a GLTF2Import node to load the glTF content.

self.rootEntity = Kuesa.SceneEntity() self.rootEntity.loadingDone.connect(self.onLoadingDone) self.gltfImporter = Kuesa.GLTF2Importer(self.rootEntity) self.gltfImporter.setSceneEntity(self.rootEntity) self.gltfImporter.setSource("file://"+ wd +"/../assets/models/car/DodgeViper-draco.gltf")

It must also use the frame graph provided by Kuesa. This is needed for the custom materials that Kuesa uses for PBR rendering. It also provides performance improvements such as early z filling, and additional post-processing effects such as blurring or depth of field.

self.fg = Kuesa.ForwardRenderer() self.fg.setCamera( self.fg.setClearColor("white") self.setActiveFrameGraph(self.fg)

Note: in this case, the base class is an instance of Qt3DWindow from Qt 3D’s extras module.

When loading is completed, the content of the glTF file can be accessed using the various collections that are available on the SceneEntity class. For example, you can access the animations created by the designer and baked into the glTF file. These can they be controlled from python!

def onLoadingDone(self): self.hoodClock = Qt3DAnimation.QClock(self.rootEntity) self.hoodAnimation = Kuesa.AnimationPlayer(self.rootEntity) self.hoodAnimation.setClock(self.hoodClock) self.hoodAnimation.setSceneEntity(self.rootEntity) self.hoodAnimation.setClip("HoodAction")

Referencing glTF content is done using the names assigned by the designer.

From there on, animations can be started and stopped by accessing the animation player object. Speed and direction can be changed using the clock created above.

Finally, the application embeds the Qt3DWindow inside a widget based UI (using a window container widget) and creates a simple UI to control the animations.


Download KUESA™ here.

The post Python binding for Kuesa appeared first on KDAB.

Interview with Manga Tengu

19 hours 33 min ago

Could you tell us something about yourself?

Hi I’m Nour, better known as “manga tengu”.

I’ve loved drawing since I was a kid. I think it is because pen and paper have always been the most widespread toys for children. When I got to choose what to study I went for architecture as it was a way to combine science and art.

I’ve always been hacking my computer, which led me to get interested in open source.

Do you paint professionally, as a hobby artist, or both?

I paint as a professional hobbyist. Which means it’s a hobby but I put maximum rigor and commitment into it. Professionally I’ve been teaching Krita and digital painting at isart since November 2018.

I’ve made lots of architectural illustration which actually led me to get interested in digital as a painting medium.

What genre(s) do you work in?

I started with caricature as a child. After admitting to myself that I wanted to draw manga, I made hundreds of pages of manga.

After deciding to enter the color realm I’ve been into … drawing manga as digital paintings. Then I rediscovered impressionism, realism…

I’m always piling something on top of what I already have.

Whose work inspires you most — who are your role models as an artist?

I made a rule to always be inspired by several artists at the same time. Getting too focused on a single one appears to have some dangerous effects on me. Actually Vladimir Volegov is the one that moves me the most.

How and when did you get to try digital painting for the first time?

In 2005, I absolutely hated it. It was on a Wacom Graphire 4 small format. At the time it looked so expensive to me… I tried it something like a few hours and left it. Then got back at it a few hours every year or so…Didn’t really get into it before 2011.

What makes you choose digital over traditional painting?

1. The biggest reason for me was that even though a tablet doesn’t look cheap, it’s way cheaper than fine art material. It puts everybody on the same level. If I have a tablet I can have a wider range of color than the finest pigments could give.

2. Speed and flexibility. Depending on how you go at it, your paint can behave as if it was wet as long as you want, or be instantly dry, then wet again… There is no time mixing, cleaning et cetera.

3. You can focus on your art: If the elements you’ve been freed from in point 1 and 2 are no longer, then what can make you stand out? Your talent, your experience, your ideas…

How did you find out about Krita?

I found a David Revoy video about Mypaint. I don’t remember if he suggested Krita or not back then but I thought hey, it seems people in the open source world have more than Blender and Linux for me! Then I went on YouTube and was really impressed with Ramon Miranda’s symmetric robot. I found it so cool I needed to try Krita out.

What was your first impression?

I realized it could do all the things I favored Manga Studio over Photoshop for.

What do you love about Krita?

So many things …

1. At the core, it is definitely meant for drawing and painting. You can feel it in the features and their implementation.

2. I can map shortcuts to any key, not some stupid combination of ctrl button or function buttons. This is very important for lefties. I end up with a very efficient workflow.

3. It’s light and runs on Linux. So I could restore some old computers nobody wanted because “Windows takes 15 minutes to start” and make them into decent working stations.

4. You can talk to the devs directly. It’s not like some gigantic monolith you can only undergo. In fact it feels like a close community.

5. All that for free, seriously?

What do you think needs improvement in Krita? Is there anything that really annoys you?

The Mac version needs some steroids. The resources, bundles, shortcuts import export (I heard they were undergoing some pimping … I have great hopes). For now when I go on a new computer I just override the Krita resource folder, but that’s not enough to bring everything back into place.

What sets Krita apart from the other tools that you use?

The brush engines, the way it is meant for painting…

If you had to pick one favorite of all your work done in Krita so far, what would it be, and why?

That drawing of the Chinese lady in the woods. I feel this is when I stopped focussing on making stupidly smooth shading and begun working on my brushwork.

What techniques and brushes did you use in it?

All my brushes are modifications of brushes bundled with Krita:

Where can people see more of your work?

Anything else you’d like to share?

Keep it fun when you paint! If you don’t enjoy it, you need to change it.

Plasma Mobile at Plasma Sprint Valencia

19 hours 37 min ago

In June month we gathered in Slimbook’s offices to work on Plasma. Along with Plasma developers, we were also joined by KDE Usability and Productivity team.

During the sprint I mostly worked to create up-to-date image for Plasma Mobile, as from last few weeks Plasma Mobile image was quite out-of-date and needed update.

Some of the bugfixes we did includes,

Apart from Plasma Mobile, I worked on general Plasma bugfixes as well,

If you want to know overall progress made in the Plasma + Usability & Productivity sprint, then you can take a look at dot story for more detailed sprint report.

Thanks to Slimbook for hosting us and KDE e.V. for sponsoring my travel!

Also, I am going to Akademy 2019, and talking with Marco Martin about Plasma on embedded devices.

Somewhat Usable

Monday 22nd of July 2019 06:12:29 AM

Adding a feature by yourself is a lot satisfying than requesting someone to add that for you, cause now you are both the producer and the consumer. But to be honest, I never thought I would be the one implementing the Magnetic Lasso for Krita when I requested it 4 years back, leave the fact that I even getting paid for doing so.

Month 2 in making the Titler – GSoC ’19

Monday 22nd of July 2019 04:00:24 AM

Hi! It’s been a while

And sorry for that, I had planned to update last week but couldn’t do so as I had few health issues but now I’m alright.

The QML MLT producer – the progress so far…

From my understanding so far (forgive me for any mistakes that I might make – it’s a different codebase and different concepts – I wholeheartedly welcome corrections and suggestions) the whole producer boils down to two parts – the actual producer code (which is in C and which is the thing which does the ‘producer stuff’) and the wrapper code (which ‘wraps’, supplements and does the actual rendering part of the QML frames). The wrapper files are responsible for mainly rendering the QML templates that are passed to it and make it available for the actual producer to use. And consequently, most of the work is to be done in the wrapper files, as the producer in itself doesn’t change much as it will still do the same things like the existing XML producer (producer_kdenlivetitle.c) – such as loading a file, generating a frame, calling rendering methods from the wrapper files.

So let’s see what work has been done. Starting with the new producer file in mlt/src/modules/qt/producer_qml.c

void read_qml(mlt_properties properties)

As the name suggests, it opens a “resource” file and stores the QML file in the global mlt_properties which is passed.

static int producer_get_image( mlt_frame frame, uint8_t **buffer, mlt_image_format *format, int *width, int *height, int writable )

This method takes in a frame and makes use of the wrapper file – it calls the method which does the rendering part in the wrapper files ( renderKdenliveTitle() ) and sets the rendered image using mlt_frame_set_image to the frame that was passed.

static int producer_get_frame( mlt_producer producer, mlt_frame_ptr frame, int index )

This method generates a frame, calls producer_get_image() and sets a ready rendered frame for the producer, and prepares for the next frame.

The wrapper file has the following methods –

void loadQml( producer_ktitle_qml self, const char *templateQml )

What this method does is – it loads a QML file which is a pointer to a char array and does a bunch of stuff – it checks if it is valid, initialises few properties using mlt_properties_set() methods (width and height). The next method we have is –

void renderKdenliveTitle( producer_ktitle_qml self, mlt_frame frame, mlt_image_format format, int width, int height, double position, int force_refresh )

renderKdenliveTitle() does the rendering part – given a mlt_frame, format and its parameters. And here is where I use QmlRenderer – my last month’s work – it renders QML. I refactored the code a bit to return a rendered QImage in the library. I make use of the renderSingleFrame() method which renders a QML frame for a given position (time)

The programming part in itself wasn’t difficult (although it is far, far from a complete producer – there are a lot of memory leaks right now), understanding how all of it works together in a piece is what took the most effort – in fact it took me a little more than week just to understand and comprehend working of the  producer codebase!

For most of the part, I believe 80% of the producer work is done. The plan is to get a working, solid producer by next week. Although the current code is still far from a ready producer although the whole structure is set and most of the refactoring that had to be be done in the QmlRenderer library in order to accommodate the producer methods is done.

Also, the build system for the QmlRenderer lib was revamped, it’s a clean build system (thanks to Vincent), so for building, all you need to do is clone the repository and do this –

mkdir build cd build qmake -r .. make cd bin ./QmlRender -o /path/to/output/directory -i /path/to/input/QML/file


You can view the code for the QML MLT producer here.

GSoC Milestone Update 1.1

Sunday 21st of July 2019 11:22:07 PM

The second part of Milestone 1 for my Google Summer of Code 2019’s project porting KDE Connect to Windows involves enabling the SFTP plugin that ships in the linux build.

The plugin allows you to navigate through your mobile device’s files (like you do with a file manager) ON YOUR DESKTOP! It makes use of sshfs to allow mounting the remote file system on your desktop. After that, you can use any file manager you like; heck, you can even use your terminal to have a walk through your mobile’s files. Once that is done, you can do literally anything with the mobile device’s files as you would do with the local filesystem: move files, copy them to your desktop machine, delete them, rename, anything!

How it works?

The plugin, like all other plugins, has two parts that comprise the plugin: the desktop side (could be Linux, Windows or OS X) and the mobile side (could be Android, Plasma Mobile or Sailfish OS).

Desktop Side

To start the plugin, the simplest way is to use the Browse device button from the device options.

This is not in the official builds yet. I’ll link down an instructions file to get it working if you want to try

Send file?
The SFTP Plugin concerns with the Browse device button only. The Send file button allows you to send one file to the connected device. It has different code and does not share functionality with Browse device.

Dev Notes: Invocation?

Clicking on the button invokes startBrowsing() function, which is the starting point for this plugin. After that, mounter object handles the connecting part of the SSHFS functionality.

Mobile side

Between the startBrowsing() function invocation and mounter object instantiation, the mobile is invoked by the desktop, to which the mobile replies with a packet containing: IP address, port, password, username and path for the desktop to connect to the mobile.

Dev Notes: Security?

To make the connection secure, the both devices save each other’s identity during the pairing phase, and no other device can then use the password and the address of the mobile device even if they are able to decrypt the already encrypted packet that carries the credentials for the SFTP plugin to the desktop.

For the interested, you can have a look at the encryption information in the app as well. All communications over KDE Connect are end-to-end encrypted.

Encryption Info shows the SHA1 fingerprint of both devices on the mobile!

So, now with a working knowledge of the plugin, let’s go on to porting the plugin over to the Windows side

Getting SSHFS Working on the Windows 10

Working with KDE Connect, a free software, it is simply against the principle to opt for, or even recommend using any proprietary software for any part of the functionality that KDE Connect provides. Naturally, my mentors suggested me to find any open alternatives that could enable me use SSHFS on windows.

Attempt 01 : SSHFS-Win

As the site reads-

SSHFS-Win is a minimal port of SSHFS to Windows. Under the hood it uses Cygwin for the POSIX environment and WinFsp for the FUSE functionality.

While the tech stack and the demonstrations looked promising, I could not get it to work with my test system. I tried using all the various methods as described in the documentation of the project, but sadly the solution simply was not able to connect to the device. The connection kept resetting, so it couldn’t be about the credentials either. I tried making it work for a couple days, but then I had to move on to the next one.

NOTE: I also did try to *just make a connection manually* with the credentials through the GUI frontend Sirikali– same fate

Attempt 02 : Win-SSHFS

While Win-SSHFS supports Windows 10 on-paper, I was still unable to make use of Win-SSHFS, same error.

close but, not quite Attempt 03 : SFTP Net Drive

While not exactly an attempt, I started doubting if these credentials were any good at all! I installed the trial version of SFTP Net Drive, and surprisingly, I was able to atleast get a taste of the sweet SFTP goodness on Windows!

see? not impossible! works, but proprietary tech Attempt 04 : Swish

This final attempt at getting the SSHFS bit working took most of the two weeks previously allotted to the SFTP plugin. To test whether this works or not, I tried out the latest release available at the time of testing. It works, yes.

The sad parts about Swish are-

  1. not maintained anymore
  2. uses a whole different package manager(Hunter package manager) to manage dependencies.

For the first part, since it was already working, I decided to go for Swish (hey, it works!) so we get SSHFS in. I could work on fixing any new limitations that the project faces, over time.

Now, as I went ahead with the dissection of the project’s build process, the second part started getting weirder and tougher with every turn. Not only the project uses a lot of alamaison’s own projects, the code base itself is based on MSVC 2013! There had already been a lot of changes and deprecation, now that I build with MSVC 2019.

The other ported software(with tests DISABLED) are available as my forks-

I also got to build Craft blueprints for a boost library as well

Albeit, the two weeks were wasted because the project was practically unusable to build anew with MSVC 19.

Next up, we decided to step back and look at the way the SFTP plugin worked prior to SSHFS.

The Solution

As you can tell by the code here, the prior implementation used to access the SFTP server (or mobile) using KIO. The SFTP plugin of KIO was again, not maintained for Windows.

Detour to kio-extras

The SFTP plugin is a part of kio-extras, which houses a lot of other plugins as well. These plugins increase the functionality of KIO, that may be used by applications that deal with input output protocols like SFTP et al.

The plugin’s functionality was not much difficult to navigate through; it had simple, easy to read functions for various activities one might perform when dealing with SFTP.

Oh well, the patch to fix SFTP just got accepted and I just landed it. Neat!

Next up, patching the plugin in KDE Connect

With a few lines of code, a patch is under review at KDE invent. Apply this patch to get the button in the device menu like in the image (way) above.

After applying this patch, clicking the Browse device button will initiate the connection through the SFTP plugin of kio-extras, and that will pop up a dialog box with pre-filled password box. Just click OK and the connection will be made, after which an sftp:// URI is invoked for the system to start browsing. Sadly, windows systems do not ship with inbuilt support for sftp:// URIs. So, for this last bit, you can install any third party software that can provide you the missing functionality (eg: WinSCP is a good one!). After this, you will be able to navigate across your mobile device’s filesystem like your local drives!

you can use WinSCP or any other file manager that supports sftp:// URI handling

You can also download WinSCP from the Windows Store if you wish to donate to them along the way! The setup from the official website is completely free of charge!

As it stands, here is a demonstration of the KDE Connect’s SFTP plugin for Windows-

Happy KDEing!


Shubham (shubham)

Sunday 21st of July 2019 05:32:12 PM
Second month progressHello visitors!! I am here presenting you with my second month GSoC project report. I will be providing the links to my work at the end of the section.Second month of work period was much more easier to manage than the first one. All thanks to my semester end vacations. Because of that, I contributed much more than during 1st month. This month have been a fruit-full month for me, fruit-full in the sense that now I could see code written by me doing some action. The base outline which I had laid for the Authorization back-end is now producing some results. A Polkit Authentication dialog can now be seen. Coming to the progress made during this period, I have done the following:Refine and merge the Polkit back-end and QDBus communication patches:I have refactored and refined the above stated patches by removing extra functionality which I had added during my first work period. I have written and arranged the code such that now it shows up authorization dialog generated by the KDE polkit daemon. After doing so, I have merged both the patches into one.Add Unit test for Polkit Authorization back-end:I have added a Unit test for Polkit Authorization back-end, testing the functionality of the authorization back-end. This is almost complete just a bit or two left.Compile Helper into a stand-alone applicationHelper itself is a separate non GUI application which works independently from Main application. Earlier, a macro provided by KAuth was used to compile it into stand-alone application. Now, I have completely removed the dependence on KAuth to do so.Epilogue
So yes, we are gradually moving our way forward towards completely removing our dependence over KAuth. But there are some things which are yet to complete. To name one, I need to finish up QDbus communication from helper to application which sends dbus (Inter Process Communication) messages. Currently I had tried this in QDbus patch, but it is not yet fully complete. All this stuff is done by KAuth currently in master.

Screen shot of KDE Authentication Dialog:

Links to my patches:1. Merged Polkit back-end and QDbus patch:2. Unit test:  3. Helper as a standalone application:Link to cgit repository: Maybe give me some suggestions/advice about the code or anything else you feel about. If you have any suggestions/questions, feel free to ping me at No spams please (Just kidding : ) Till next time, bye bye!!

Kate LSP Status – July 21

Sunday 21st of July 2019 01:18:00 PM

The new LSP client by Mark Nauwelaerts keeps making nice progress.

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

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

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

Feel welcome to show up on and help out! All development discussions regarding this plugin happen there.

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

What is new this week?

The most thing are internal cleanups and minor improvements.

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

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

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

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

[GSoC – 4] Achieving consistency between SDDM and Plasma

Sunday 21st of July 2019 11:47:41 AM

Previously: 1st GSoC post 2nd GSoC post 3rd GSoC post This blog post marks the landing of the initial implementation of theme syncing between SDDM and Plasma, which you may already have read about in Nate's post. Those of you running master can test the feature out by going to the Advanced tab in the...... Continue Reading →

KDE Usability & Productivity: Week 80

Sunday 21st of July 2019 06:01:04 AM

Somehow we’ve gone through 80 weeks of progress reports for KDE’s Usability & Productivity initiative! Does that seem like a lot to you? Because it seems like a lot to me. Speaking of a lot, features are now pouring in for KDE’s Plasma 5.17 release, as well as Applications 19.08. Even more is lined up for Applications 19.12 too, which promises to be quite a release. Anyway, here’s what we’ve got for you:

New Features Bugfixes & Performance Improvements User Interface Improvements

Next week, your name could be in this list! Not sure how? Just ask! I’ve helped mentor a number of new contributors recently and I’d love to help you, too! You can also check out, and find out how you can help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

If you find KDE software useful, consider making a tax-deductible donation to the KDE e.V. foundation.

View and Examples

Sunday 21st of July 2019 12:00:00 AM

This week I began learning about QML to try to fix the View that show the graphs and tools for manipulating graphs. More precisely, I wanted to deal with some problems:

  • Vertexes that go near the border of the view cannot be moved;
  • Ctrl-A do not select all the view, just a limited part;
  • The option menu in the Create Node and Create Edge puts the lateral menu over the scroll bar;
  • The scroll bar in the view don’t have much use, as the view is tiny, and the mouse can be used to move in most cases;
  • The Flickable motion from the Qt is stealing most of the clicks from the MouseArea (maybe remove the interactive option while outside the Select/Move?), making really difficult to create new edges;
  • The Icons for the tools are not being showed.

This is the view now:

This is an probable new view (under implementation), that I will present to my mentors:

I have been studying QML to modify this view and little by little I am building it. Moreover, I modified the two original examples in the code BreadthFirstSearch and PrimSpanningTree to work in the current system (they were with commands not valid for the current version, like interrupt()). I also added one more example for the other search algorithm, DepthFirstSearch and the other implementations are under way:

  • Topological Sorting Algorithm;
  • Kruskal Algorithm;
  • Dijkstra Algorithm;
  • Bellman-Ford Algorithm;
  • Floyd-Warshall Algorithm;
  • Bipartite Matching Algorithm.

I had some other ideas for the interface that can be easily implemented and is a good way to improve the workflow:

This configuration create more space for the programmer while leaving enough space to visualize the graphs correctly and it works well with a new horizontal toolbar.

The new view is not yet available, as it is only local code. The new algorithm for DAG creation and examples are available in the merge requests here and here, respectively.

(Also, I have been really sick in the last week, but now I think I am better!)

Desk lamp

Saturday 20th of July 2019 04:02:28 PM
desk lamp with mirror behind

Some time ago, I wanted to make my own desk lamp. It should provide soft, bright task lighting above my desk, no sharp shadows that could cover part of my work area, but also some atmospheric lighting around the desk in my basement office. The lamp should have a natural look around it, but since I made it myself, I also didn’t mind exposing some of its internals.

SMD5050 LED strips

I had oak floor boards that I got from a friend (thanks, Wendy!) lying around. which I used as base material for the lamp. I combined these with some RGBW led strips that I had lying around, and a wireless controller that would allow me to connect the lamp to my Philips Hue lighting system, that I use throughout the house to control the lights. I sanded the wood until it was completely smooth, and then gave it an oild finish to make it durable and give it a more pronounced texture.

Fixed to the ceiling Internals of the desk lamp

The center board is covered in 0.5mm aluminium sheets to dissipate heat from the LED strips (again, making them last longer) and provide some extra diffusion of the light. This material is easy to work with, and also very suitable to stick the led strips to. For the light itself, I used SMD5050 LED strips that can produce warm and cold white light, as well as RGB colors. I put 3 rows of strips next to each other to provide enough light. The strips wrap around at the top, so light is not just shining down on my desk, but also reflecting from walls and ceiling around it. The front and back are another piece of wood to avoid looking directly into the LEDs, which would be distractive, annoying when working and also quite ugly. I attached a front and back board as well to the lamp, making it into an H shape.

Light reflects nicely from surrounding surfaces

The controller (a Gledopto Z-Wave controller, that is compatible with Philips Hue) is attached to the center board as well, so I just needed to run 2 12V wires to the lamp. I was being a bit creative here, and thought “why not use the power cables also to have the lamp hanging from the ceiling?”. I used coated steel wire, which I stripped here and there to have power run through steel hooks screwed into the ceiling to supply the lamp with power while also being able to adjust its height. This ended up creating a rather clean look for the whole lamp and really brought the whole thing together.

LabPlot has got some beautifying and lots of datasets

Saturday 20th of July 2019 03:34:01 PM
Hello everyone! The second part of this year's GSoC is almost over, so I was due to let you know the progress made in the last 3 weeks. I can assure you we haven't lazed since then. I think I managed to make quite good progress, so everything is going as planned, or I could say that even better. If you haven't read about this year's project or you just want to go through what has already been accomplished you can check out my previous post.
So let's just go through the new things step by step. I'll try to explain the respective feature, and also give examples using videos or screenshots. 
The first step was to improve the welcome screen and make it easily usable, dynamic, clean and intuitive for users. This step was very important since the welcome screen is what the users will first get in contact with when they start using LabPlot. We had a great idea, which was to make a screenshot of the main window whenever the user saves a project. This screenshot will be saved with the project itself and will be used as a thumbnail for Recent and Example projects in the welcome screen. The code section, that deals with making and saving the screenshot, is already committed on the master branch. You can see these thumbnails put to use in the following picture:
Thumbnails put to use
As you might recall, when I wrote the last post, the only section of the welcome screen which wasn't functional was the examples section. Implementing this feature was the next step. You could already catch a glimpse of it in the previous picture. Me and my mentors really like QtCreator's Example section, so that's where I got my inspiration. The example projects are shown in a GridView, and they look quite nice, thanks to the thumbnails. Every example project has a name and one or more tags assigned to itself. Just like in QtCreator's approach, the example projects are searchable based on their names and also on one or more tags. There is a search bar providing this functionality. Unfortunately, we didn't manage to create example projects just yet, so I used some temporary projects for implementing and testing, and also these will be shown in the following demo video:
 The functionality of the Example Projects section
The next step was to make the section and also their content more dynamic. In my last post, these sections/widgets (whichever name you prefer) were static, having a fixed size and their content wasn't adapting really well to the resizing of the main window. As I said that was only a prototype. During the last weeks, I managed to make it really dynamic, as a modern welcome screen should be. The result is pretty nice, at least according to my mentors :). So how does this work? When the user drags the mouse over the frame of a section a line appears, with which the user can easily resize a section just by dragging it. If the user doesn't like the layout he/she created, it can always be reset to the original layout. You can see how it works in the next video:
  Resizing the welcome screen and its content
Another new feature is also connected to the welcome screen. I made it possible for LabPlot to save the layout of the welcome screen whenever it's closed (either because opening/creating a project or because of closing the application). When the welcome screen is displayed next time, it's layout isn't the standard one (to which the user can reset the current layout in the settings) but the saved one. It seemed a good idea and it might be useful since no one would modify the layout, if he/she liked it. This feature is presented in the next video:
  Save welcome screen's layout
Lastly but not least, the welcome screen got another new feature. Now the user can maximize a section, so he/she can interact with the given section much more easily. When the section doesn't need to be maximized, then the user can minimize it and the former layout is restored. This function is particularly useful since there are many sections and they might not be big enough without the others getting particularly small. This was the issue that resulted in figuring out and implementing this idea. The maximizing and minimizing can be done with the icon in the upper-left corner of every section. In addition to this, I also added a go forward and go backwards icon/button to the "Release section" since its implemented using a WebView and users can navigate away from the starting page:
 Maximizing&Minimizng the welcome screen's widgets
Some other changes were made to the categorizing of datasets too. We thought it would be better to organise the datasets into collections (for example collection of R Datasets etc.) then into categories and subcategories. This made possible having a single file for a dataset collection, rather than having a metadata file for every dataset (as it previously was implemented). This, of course, caused some changes in the ImportDatasetWidget and DatasetMetadataManagerWidget, but their functionality stayed the same:
 Changes on ImportDatasetWidget and DatasetMetadataManagerWidget
As you might remember from the post, our main problem was that uploading with KNS3 is disabled for an indefinite amount of time due to errors caused by the library. This made us question whether we should use it at all or not. Given the mentioned problem and the fact that we found the library's functionality quite limited for our purposes, we decided not to use it. Instead, we'll provide a considerable collection of datasets, which should suffice. I already managed to collect and categorize not less than 1000 datasets. And I'm planning to collect some more.

Finally, I'd like to say some words about the next steps. We still have to make some "real" example projects so the users can explore the possibilities provided by LabPlot. I'll have to proceed with the collecting of datasets, in order to provide the users of LabPlot with a considerable dataset collection. As the finish line is getting closer, there won't be new "big features", maybe some minor new ideas, if some will come up, but instead I'd like to focus on cleaning, documenting, refactoring and optimising the code so it will be fit to be brought to the master branch.  I'd also like to search for hidden bugs and errors, to make the new and already implemented features more or less flawless. Some tests should also be written for the dataset management part of the code.

This is it for now. I will continue to work on the project alongside Kristóf and Alexander. I truly enjoy working with them, mostly the "brainstorming part", I think we form a quite good team. I'm thankful to them, for their guidance. When anything new will be finished and running I'll let you know. 

See you soon!Bye!

Popular licenses in OpenAPI

Friday 19th of July 2019 02:25:00 PM

Today I was wondering what the most commonly used license that people use in OpenAPI, so I went and did a quick analysis.


The top 5 (with count and percentage; n=552):

License name count percentage CC-BY-3.0 250 45,29% Apache-2.01 218 39,49% MIT 15 2,71% “This page was built with the Swagger API.” 8 1,44% “Open Government License – British Columbia” 6 1,09%

The striked-out entries are the ones that I would not really consider a proper license.

The license names inside quotation marks are the exact copy-paste from the field. The rest are de-duplicated into their SPDX identifiers.

After those top 5 the long end goes very quickly into only one license per listed API. Several of those seem very odd as well.


Note: Before you start complaining, I realise this is probably a very sub-optimal solution code-wise, but it worked for me. In my defence, I did open up my copy of the Sed & Awk Pocket Reference before my eyes went all glassy and I hacked up the following ugly method. Also note that the shell scripts are in Fish shell and may not work directly in a 100% POSIX shell.

First, I needed to get a data set to work on. Hat-tip to Mike Ralphson for pointing me to APIs Guru as a good resource. I analysed their APIs-guru/openapi-directory repository2, where in the APIs folder they keep a big collection of public APIs. Most of them following the OpenAPI (previously Swagger) specification.

git clone cd openapi-directory/APIs

Next I needed to list all the licenses found there. For this I assumed the name: tag in YAML4 (the one including the name of the license) to be in the very next line after the license: tag3 – I relied on people writing OpenAPI files in the same order as it is laid out in the OpenAPI Specification. I stored the list of all licenses, sorted alphabetically in a separate api_licenses file:

grep 'license:' **/openapi.yaml **/swagger.yaml -A 1 --no-filename | \ grep 'name:' | sort > api_licenses

Then I generated another file called api_licenses_unique that would include only all names of these licenses.

grep 'license:' **/openapi.yaml **/swagger.yaml -A 1 --no-filename | \ grep 'name:' | sort | uniq > api_licenses_unique

Because I was too lazy to figure out how to do this properly5, I simply wrapped the same one-liner into a script to go through all the unique license names and count how many times they show up in the (non-duplicated) list of all licenses found.

for license in (grep 'license:' **/openapi.yaml **/swagger.yaml -A 1 \ --no-filename | grep 'name' | sort | uniq) grep "$license" api_licenses --count end

In the end I copied the console output of this last command, opened api_licenses_unique, and pasted said output in the first column (by going into Block Selection Mode in Kate).

Clarification on what I consider “proper license” and re-count of Creative Commons licenses (12 July 2019 update)

I was asked what I considered as a “proper license” above, and specifically why I did not consider “Creative Commons” as such.

First, if the string did not even remotely look like a name of a license, I did not consider that as a proper license. This is the case e.g. with “This page was built with the Swagger API.”.

As for the string “Creative Commons”, it – at best – indicates a family o licenses, which span a vast spectrum from CC0-1.0 (basically public domain) on one end to CC-BY-NC-CA-4.0 (basically, you may copy this, but not change anything, nor get money out of it, and you must keep the same license) on the other. For reference, on the SPDX license list, you will find 32 Creative Commons licenses. And SPDX lists only the International and Universal versions of them7.

Admiteldy, – and this is a caveat in my initial method above – it may be that there is an actual license following the lines after the “Creative Commons” string … or, as it turned out to be true, that the initial 255 count of name: Creative Commons licenses included also valid CC license names such as name: Creative Commons Attribution 3.0.

So, obviously I made a boo-boo, and therefore went and dug deeper ;)

To do so, and after looking at the results a bit more, I noticed that the url: entries of the name: Creative Commons licenses seem to point to actual CC licenses, so I decided to rely on that. Luckily, this turned out to be true.

I broadened up the initial search to one extra line, to include the url: line, narrowed down the next search to name: Creative Commons, and in the end only to url:

grep 'license:' **/openapi.yaml **/swagger.yaml -A 2 --no-filename | \ grep 'name: Creative Commons' -A 1 | grep 'url' | sort > api_licenses_cc

Next, I searched for the most common license – CC-BY-3.0:

grep --count '' api_licenses_cc

The result was 250, so for the remaining6 5 I just opened the api_licenses_cc file and counted them manually.

Using this method the list of all “Creative Commons” license turned out to be as follows:

  1. CC-BY-3.0 (250, of which one was specific to Australian jurisdiction)
  2. CC-BY-4.0 (3)
  3. CC-BY-NC-4.0 (1)
  4. CC-BY-NC-ND-2.0 (1)

In this light, I am amending the results above, and removing the bogus “Creative Commons” entry. Apart from removing the bogus entry, it does not change the ranking, nor the counts, of the top 5 licenses.

Further clean-up of Apache (17 July 2019 udpate)

Upon further inspection it looked odd that I was getting so many Apache-2.0 matches – if you added all the Apache-2.0 hits (initially 421) with all the CC-BY-3.0 hits (250), you already reached a higher number than all the occurrances of the license: field in all the files (552). Clearly something was off.

So I re-counted the Apache hits by limiting myself only to the url: field of the license:, instead of the name: and came to a half of the original number. Which brought it from first down to second place. Basically I applied the same method as above for counting Creative Commons licenses.

hook out → not proud of the method, but happy with having results

  1. This should come as no surprise, as Apache-2.0 is used as the official specification’s example

  2. At the time of this writing, that was commit 506133b

  3. I tried it also with 3 lines, and the few extra results that came up where mostly useless. 

  4. I did a quick check and the repository seems to include no OpenAPIs in JSON format. 

  5. I expected for license in api_licenses_unique to work, but it did not. 

  6. The result of wc -l api_licenses_cc was 255. 

  7. Prior to version 4.0 of Creative Commons licenses each CC license had several versions localised for specific jurisdictions. 

Kubuntu 18.10 reaches end of life

Friday 19th of July 2019 08:35:21 AM

Kubuntu 18.10 Cosmic Cuttlefish was released on October 18th 2018 with 9 months support. As of 18th July 2019, 18.10 reaches ‘end of life’. No more package updates will be accepted to 18.10, and it will be archived to in the coming weeks.

The official end of life announcement for Ubuntu as a whole can be found here [1].

Kubuntu 19.04 Disco Dingo continues to be supported, receiving security and high-impact bugfix updates until January 2020.

Users of 18.10 can follow the Kubuntu 18.10 to 19.04 Upgrade [2] instructions.

Should for some reason your upgrade be delayed, and you find that the 18.10 repositories have been archived to, instructions to perform a EOL Upgrade can be found on the Ubuntu wiki [3].

Thank you for using Kubuntu 18.10 Cosmic Cuttlefish.

The Kubuntu team.

[1] –
[2] –
[3] –

Overriding Wordlist component function to use Multiple Datasets.

Friday 19th of July 2019 06:34:00 AM

One of the tasks for GSoC 2019 included adding multiple datasets to smallNumbers activity. The aim of the activity is to teach students to count the number of object on the falling item. But the activity is not an independent activity, but it is the sub-activity of the parent activity gletters. In gletter the overall working is the same, apart from the fact that this time their are no falling objects but alphabets, and the student has to identify the falling alphabet and press the corresponding button on the keyboard. So to manage different types of falling items the activity uses a separate core component i.e. Wordlist. Now since the task was to implement the multiple datasets for smallnumbers activity without affecting the functionalitiy of its parent activity gletters, I had to make some changes in wordlist component.

Wordlist initially reading data

The Wordlist component uses a loadFromFile function which is provided the path to the file location which contains the dataset. The files provided are json files and the function uses a parser to parse the contents of the file.

function loadFromFile(fname) {
function loadFromFile(fname) {
filename = fname;
var from;
maxLevel = 0
wordList = parser.parseFromUrl(filename, validateWordlist);
if (wordList == null) {
error("Wordlist: Invalid wordlist file " + fname);
if (useDefault) {
// fallback to default file:
wordList = parser.parseFromUrl(defaultFilename, validateWordlist);
if (wordList == null) {
error("Wordlist: Invalid wordlist file " + defaultFilename);
from = "default-file " + defaultFilename;
else {
error("Wordlist: do not use default list, no list loaded");
} else {
from = "file " + fname;
// at this point we have valid levels
maxLevel = wordList.levels.length;
console.log("Wordlist: loaded " + maxLevel + " levels from " + from);
return wordList;

but in case of multiple datasets we use qml files to store data and hence the same function could not be used with multiple datasets.

Creating a new function to initialise wordlist

In Multiple dataset architecture we are provided with the data part of the Data.qml file in the main qml file of our activity like

property var levels:

This data is already in JSON format, which is exactly what is needed by the Wordlist. So I created a function loadFromJSON in Wordlist component to take this data as input and initialise the Wordlist according to it.

function loadFromJSON(levels) {
wordList = {levels: levels};
maxLevel = wordList.levels.length;
return wordList;

Lastly I added a condition in gletters.js file to use the respective function when there is some value in items.levels variable(when the activity uses multiple datasets).

items.ourActivity.dataSetUrl + "default-"+locale+".json"));

This way I was able to use multiple datasets in smallnumbers activity without affecting the functionality of parent activity gletters.

More in Tux Machines

today's leftovers

  • Linux Weekly Roundup #35

    Hello and welcome to this week's Linux Roundup and what a wonderful week we had! We have plenty of Linux Distro releases and LibreOffice 6.3 RC1. The Linux distros with releases this week are Q4OS 3.8, SparkyLinux 5.8, Mageia 7.1, ArcoLinux 19.07.11, Deepin 15.11, ArchBang 2107-beta, Bluestar 5.2.1, Slackel 7.2 "Openbox" and Endeavour OS 2019.07.15. I looked at most of these Linux Distros, links below, I will look at some of them in the new week and some I will unfortunately not have a look at, for download links and more, please visit Well, this is this week's Linux Roundup, thank you so much for your time! Have a great week!

  • Full Circle Magazine: Full Circle Weekly News #140
  • Christopher Allan Webber: ActivityPub Conf 2019

    That's right! We're hosting the first ever ActivityPub Conf. It's immediately following Rebooting Web of Trust in Prague. There's no admission fee to attend. (Relatedly, the conference is kind of being done on the cheap, because it is being funded by organizers who are themselves barely funded.) The venue, however, is quite cool: it's at the DOX Centre for Contemporary Art, which is itself exploring the ways the digital world is affecting our lives. If you plan on attending (and maybe also speaking), you should get in your application soon (see the flier for details). We've never done one of these, and we have no idea what the response will be like, so this is going to be a smaller gathering (about 40 people). In some ways, it will be somewhere between a conference and a gathering of people-who-are-interested-in-activitypub. As said in the flier, by attending, you are agreeing to the code of conduct, so be sure to read that.

Sysadmin Appreciation Day, IBM and Fedora

  • Gift ideas for Sysadmin Appreciation Day

    Sysadmin Appreciation Day is coming up this Friday, July 26. To help honor sysadmins everywhere, we want you to share your best gift ideas. What would be the best way a team member or customer could show their appreciation for you? As a sysadmin, what was the best gift you've ever received? We asked our writers the same question, and here are their answers: "Whilst working in the Ubuntu community on Edubuntu, I took it upon myself to develop the startup/shutdown sound scheme, which became the default in Ubuntu for, from what I can understand, the next decade. Whilst people had a love-hate relationship with my sound scheme, and rightly so, I had a love-hate relationship with my sound card during the development. At the time I had recorded all my sound samples using one sample rate, but my new sound card, as my motherboard had exploded a few days earlier, did not support it. I had two choices, resample all my samples (which I didn't really want to do) or buy a new sound card.

  • Red Hat OpenStack Platform with Red Hat Ceph Storage: Radosbench baseline performance evaluation

    Red Hat Ceph Storage is popular storage for Red Hat OpenStack Platform. Customers around the world run their hyperscale, production workloads on Red Hat Ceph Storage and Red Hat OpenStack Platform. This is driven by the high level of integration between Ceph storage and OpenStack private cloud platforms. With each release of both platforms, the level of integration has grown and performance and automation has increased. As the customer's storage and compute needs for footprints have grown, we have seen more interest towards running compute and storage as one unit and providing a hyperconverged infrastructure (HCI) layer based on OpenStack and Ceph. [...] Continuing the benchmarking series, in the next post you’ll learn performance insights of running multi-instance MySQL database on Red Hat OpenStack Platform and Red Hat Ceph Storage across decoupled and hyperconverged architectures. We’ll also compare results from a near-equal environment backed by all-flash cluster nodes.

  • The State of Java in Flathub

    For maintainers of Java-based applications in Flathub, it's worth noting that even if you consume the Latest OpenJDK extension in your application, users will not be broken by major updates because OpenJDK is bundled into your Flatpak. The implication of this for users is that they won't see updates to their Java version until the application maintainer rebuilds the application in Flathub. If you maintain a Java-based Flatpak application on Flathub, you can consume the latest version of your chosen OpenJDK stream (either LTS or Latest) simply by rebuilding; the latest version of that OpenJDK steam will be pulled in automatically.

  • Fedora Magazine: Contribute at the Fedora Test Week for kernel 5.2

    The kernel team is working on final integration for kernel 5.1. This version was just recently released, and will arrive soon in Fedora. This version has many security fixes included. As a result, the Fedora kernel and QA teams have organized a test week from Monday, Jul 22, 2019 through Monday, Jul 29, 2019. Refer to the wiki page for links to the test images you’ll need to participate. Read below for details.

Debian and Ubuntu Leftovers

  • Bootstrappable Debian BoF

    Greetings from DebConf 19 in Curitiba! Just a quick reminder that I will run a Bootstrappable Debian BoF on Tuesday 23rd, at 13.30 Brasilia time (which is 16.30 UTC, if I am not mistaken). If you are curious about bootstrappability in Debian, why do we want it and where we are right now, you are welcome to come in person if you are at DebCon or to follow the streaming.

  • Candy Tsai: Outreachy Week 6 – Week 7: Getting Code Merge

    You can’t overhear what others are doing or learn something about your colleagues through gossip over lunch break when working remotely. So after being stuck for quite a bit, terceiro suggested that we try pair programming. After our first remote pair programming session, I think there should be no difference in pair programming in person. We shared the same terminal, looked at the same code and discussed just like people standing side by side. Through our pair programming session, I found out that I had a bad habit. I didn’t run tests on my code that often, so when I had failing tests that didn’t fail before, I spent more time debugging than I should have. Pair programming gave insight to how others work and I think little improvements go a long way.

  • about your wiki page on I/O schedulers and BFQ
    this is basically to report outdated statements in your wiki page on
    I/O schedulers [1].
    The main problematic statement is that BFQ "...  is not ideal for
    devices with slow CPUs or high throughput I/O devices" because too
    heavy.  BFQ is definitely more sophisticated than any of the other I/O
    schedulers.  We have designed it that way to provide an incomparably
    better service quality, at a very low overhead.  As reported in [2],
    the execution time of BFQ on an old laptop CPU is 0.6 us per I/O
    event, against 0.2 us for mq-deadline (which is the lightest Linux I/O
    To put these figures into context, BFQ proved to be so good for
    "devices with slow CPUs" that, e.g., Chromium OS migrated to BFQ a few
    months ago.  In particular, Google crew got convinced by a demo [3] I
    made for them, on one of the cheapest and slowest Chromebook on the
    market.  In the demo, a fast download is performed.  Without BFQ, the
    download makes the device completely unresponsive.  With BFQ, the
    device remains as responsive as if it was totally idle.
    As for the other part of the statement, "...  not ideal for ...  high
    throughput I/O devices", a few days ago I ran benchmarks (on Ubuntu)
    also with one of the fastest consumer-grade NVMe SSDs: a Samsung SSD
    970 PRO.  Results [4] can be summarized as follows.  Throughput with
    BFQ is about the same as with the other I/O schedulers (it couldn't be
    higher, because this kind of drives just wants the scheduler to stay
    as aside as possible, when it comes to throughput).  But, in the
    presence of writes as background workload, start-up times with BFQ are
    at least 16 times as low as with the other I/O schedulers.  In
    absolute terms, gnome-terminal starts in ~1.8 seconds with BFQ, while
    it takes at least 28.7 (!) seconds with the other I/O schedulers.
    Finally, only with BFQ, no frame gets lost in video-playing
    BFQ then provides other important benefits, such as from 5x to 10X
    throughput boost in multi-client server workloads [5].
    So, is there any chance that the outdated/wrong information on your
    wiki page [1] gets updated somehow?  If I may, I'd be glad to update
    it myself, after providing you with all the results you may ask.
    In addition, why doesn't Ubuntu too consider switching to BFQ as
    default I/O scheduler, for all drives that BFQ supports (namely all
    drives with a maximum speed not above ~500 KIOPS)?
    Looking forward to your feedback,
  • Should Ubuntu Use The BFQ I/O Scheduler?

    The BFQ I/O scheduler is working out fairly well these days as shown in our benchmarks. The Budget Fair Queueing scheduler supports both throughput and low-latency modes while working particularly well for consumer-grade hardware. Should the Ubuntu desktop be using BFQ by default? [...] But in addition to wanting to correct that Wiki information, Paolo pops the question of why doesn't Ubuntu switch to BFQ as the default I/O scheduler for supported drives. Though as of yet, no Ubuntu kernel developers have yet commented on the prospect of switching to BFQ.

Devices With Linux Support

  • Quest Releases KACE SDA & SMA Updates

    The update to 7.0 for KACE Systems Deployment Appliance is primarily about bringing a scope of endpoint management capabilities with new support for Linux devices to the table.

  • Rugged, Kaby Lake transport computer has a 10-port LAN switch with PoE

    Axiomtek’s Linux-ready “tBOX400-510-FL” transportation system has a 7th Gen Intel CPU and a 10-port managed switch with 8x M12-style 10/100Mbps PoE and 2x GbE ports. The rugged system also has 3x mini-PCIe slots and dual swappable SATA drives. Axiomtek has launched a fanless, Kaby Lake-U based transportation computer with a choice of power supplies designed for in-vehicle, marine, or railway applications. The rugged tBOX400-510-FL features a Qualcomm-driven, Layer 2 managed PoE switch with support for IP surveillance and video management applications. “Customers can connect IP cameras directly without installing an extra PoE switch, minimizing overall deployment costs and installation space onboard,” stated Axiomtek product manager Sharon Huang.