I have been using the Netspeed widget on my KDE Plasma installations for a long time to display the network download and upload speed in the Plasma panel. When I upgraded to Kubuntu 22.04 a few months ago, I found that it stopped working. After doing some research, I found that the KSysGuard package that the widget depends on has been removed from the Debian and Ubuntu repositories as it is unmaintained (Debian bug).
Thanks to a useful suggestion on Reddit, I was able to recreate the functionality of this widget using the System Monitor Sensor widget. Here is what I did to achieve it.
Add the System Monitor Sensor widget to the panel.
Right-click the widget and click on the Configure System Monitor Sensor option in the menu
In the Appearance tab, load the Network speed preset, set the Display style to Text Only and set the Minimum Time Between Updates to 1 second. Apply the changes before proceeding to the next step.
Open the Sensors Details tab and in the Text Only Sensors field, search for the Download Rate sensor. I chose the Download Rate (B/s) version. There is also a Download Rate (b/s) sensor, if you prefer that.
Click on the small pencil icon edit button just after the name of the widget, Download Rate, to edit it. Specify the down arrow symbol, ↓, as the name. Apply the changes.
Now you have a widget that shows the current download speed on the panel, updated once every second.
Add another System Monitor Sensor widget to the panel and configure it to display the Upload Rate by following the steps above, tweaked for displaying the upload rate.
The result of doing these steps should look like what is shown in the screenshot below.
With this, I have a good replacement for the NetSpeed Widget on my Kubuntu install.
I am a big fan of Willi Mutschler‘s btrfs-luks full disk encryption installation guides on his site, https://mutschler.dev, and have used them for installing Manjaro and Ubuntu 20.04 and newer versions. Recently, I set up Kubuntu 22.04 full disk encryption by following the same guide and noticed a couple of changes that had to be done to get it working. So I am documenting those here till he writes a new guide for Ubuntu 22.04. 🙂
In the step 3 of his excellent guide, the optimized mount options for SSD and NVMe drives are listed. The space_cache option mentioned in that section no longer works on Ubuntu 22.04 because the option has been renamed in the newer versions of the Linux kernel. So one has to specify the option as space_cache=v2. Otherwise, the Ubiquity installer will crash, and the installation will fail.
Also, in the Install the EFI bootloader section, it is a good idea to use the HWE Linux kernel package names corresponding to 22.04 instead of 20.04 since the packages containing the old LTS version in their name are ‘dummy transitional packages’. So the corresponding command can to be updated to
At the time of writing this post, the HWE package installs the same kernel version as the one that shipped with Ubuntu 22.04 since there isn’t a newer kernel released yet – these are usually backported from newer LTS versions.
With these minor changes, it should be possible to follow the steps in that documentation to set up full disk encryption with btrfs and luks on Ubuntu 22.04.
As a bonus, I have used the same guide for installing Kubuntu 20.04, 21.10 and 22.04, with appropriate substitutions, wherever needed.
I have usually skipped the last section in this guide, Install Timeshift, timeshift-autosnap-apt and grub-btrfs, in favour of using my tools of choice to do the same – Snapper and snapper-gui, both of which are available in the official Ubuntu repositories. I will write a blog post about it in the future. 🤞
I have a dual-display setup for my desktop and I usually set up custom keyboard shortcuts in KDE Plasma to allow moving windows between the displays easily. However, the KWin shortcuts section of the Plasma System Settings app has multiple shortcuts named in a confusingly similar way.
So I am writing this post to just document what I did to get my custom Ctrl +Alt + <left/right> arrow shortcut working.
Set up custom shortcuts for the Window to Previous Screen and the Window to Next Screen entries to get this working. As mentioned above, I use Ctrl + Alt + <left arrow> for the former and Ctrl + Alt + <right arrow> for the latter.
Screenshot showing the shortcut entries to change.
I have a WireGuard server running on a Raspberry Pi 4B at my home, exposed to the internet via a static IP address and port forwarding. I set it up using the Linuxserver.io WireGuard docker container, which is straightforward to use and manage.
As I am in a different city now, I had been postponing the updates to the docker container since it is risky to do so remotely. Any issue in the upgrade process could lock me out of my home network till I am physically present in my home.
As I hate deferring updates, I decided to apply the update remotely. To prepare for that, I logged into the Raspberry Pi via the WireGuard VPN and set up a remote forwarding SSH tunnel on a server of mine hosted in the cloud, using a command like,
This command forwards the 2222 port on the remote server to 127.0.0.1:22 on the Raspberry Pi, thereby allowing access to it from the remote server. The -N flag prevents the execution of any remote command (like say, starting the user’s shell) and is useful for just forwarding ports.
Then I logged in directly to that server and logged in to the Raspberry Pi using the forwarded port on that server. Now I could destroy and re-create the WireGuard container without the fear of being locked out since I was connected to the device using SSH and not the WireGuard VPN itself. So, I ran the following command.
The UserKnownHostsfile=/dev/null option prevents the saving of the remote host’s SSH key in the ~/.ssh/known_hosts file, the StrictHostKeyChecking=no option prevents the checking of the remote host key, and the CheckHostIP=no option prevents the checking of the remote host’s IP address. These options disable a lot of important security measures that SSH provides by default ⚠️. But since we are connecting to a known host through a forwarded host, and don’t want to save any local data about it, these options are fine to use.
This command my remote SSH session, and I was worried that I had missed something important and was locked out. So, I disconnected the SSH session using the escape sequence (<enter>~.) and reconnected to my cloud server and then to the Raspberry Pi. It worked and I heaved a sigh of relief and was glad to have pulled this off without any issues. I verified that updated WireGuard container was running without any issues and that I was able to connect to the VPN. 😌
I use KDE Plasma on my Arch desktop and I’ve had some issues with getting my dual-monitor, mixed DPI setup to work properly as mentioned in my previous post.
I nuked and paved my existing installation a few weeks ago and set up Arch afresh on the same computer on a new SSD. On the previous install, I had set up the root filesystem on a hard drive with LVM and the system startup was very slow – ~45 seconds to reach SDDM, an additional ~30 seconds to drop to a usable desktop, and then ~5 seconds to run my xrandr script.
The boot time and the time taken to reach a usable desktop was significantly lesser with the SSD – ~8 seconds to start SDDM, ~5 seconds to the desktop, ~3 seconds to run the xrandr script. So I was happy.
As exciting as that was, I still had many rough edges and paper cuts, most of them persisting across multiple re-installations. Thanks to the posts by various posts by fellow Plasma users, I was able to solve them 🙂
SDDM
Monitor layout
When SDDM started, it always did with my monitor layout and DPI configured wrong. My secondary 1080p monitor is placed to the left of my primary 4K monitor and SDDM always placed the former to the right of the latter.
Thanks to this useful post, I was able to create a custom Xsetup script by adding the xrandr command from my previous post and configuring SDDM to run it when starting the display server.
I don’t like the default theme used by SDDM, maui. Since Arch is a DIY distro, it doesn’t automatically set up the default Plasma theme, breeze, like many other distros do when Plasma is installed.
Previously, I was using the Chili login theme to make the SDDM greeter look nice. I was unsure why and how, the Manjaro installation on my laptop, had a nice Plasma theme for SDDM. But I didn’t spend any time investigating at all till now.
I checked the Arch wiki page on SDDM theming to check if there are nice themes listed there that I could use and found that it is possible to configure the SDDM theme using the Plasma System Settings application after installing the sddm-kcm package. I found the default Breeze theme which I liked very much and set it as the theme. But that didn’t work. So I went ahead and configured it manually in sddm.conf and voilà, it worked! 😀
I was pleasantly surprised to see that Plasma automatically scaled my 4K monitor without having to configure scaling manually via the Display settings application. Everything in the secondary monitor looked large as expected and I had to run my xrandr command from the previous post, with some changes to restart Plasma shell for making the wallpaper fit the scaled display, manually every time due to something in the Plasma startup process resetting the screen configuration irrespective of when my xrandr auto-start script ran.
Thanks to this post on Reddit by a fellow Plasma user, I found that the kscreen2 service was the culprit and disabling it ensured that the display configuration set up by the SDDM Xsetup script persisted and as a result, I didn’t have to manually run my xrandr script 😀 😌
There could be some side-effects caused by disabling the kscreen2 service, but I haven’t run into any till now 🙂
Emoji picker
The built-in emoji picker, introduced in Plasma 5.18, is very convenient and something that Plasma was sorely missing before. However, in spite of installing an appropriate emoji font, the emoji picker had a lot of missing emoji with blank squares and the color/gender variants of some emoji looked broken with those showing up as two separate symbols (one for the emoji and the other for the color/gender variant) overlapping each other.
Thanks to this Reddit post, I was able to solve the issue by creating a custom fontconfig configuration file, ~/.config/fontconfig/fonts.conf, with the configuration below and by forcefully rebuilding the font info cache files by running fc-cache -f.
Last year, I purchased a new 4K monitor to use as my primary display in addition to my existing 1080p monitor. Like with most 4K monitors, this one required scaling to display text and interface elements in a readable size. While the dual monitor setup worked okay out of the box on Windows 10, it didn’t on my Arch install running an up-to-date KDE Plasma.
1.5x scaling in the Display settings on Plasma made everything look okay on the primary 4K monitor but look large and ugly on the 1080p monitor. I was aware that Wayland supports mixed DPI environments very well but I was stuck on Xorg due to having an Nvidia GPU and Plasma’s support for EGLStreams still being a work in progress.
I read multiple recommendations on the internet to scale (mentioned correctly in a few places as “upscaling”) the 1080p display using xrandr to compensate for the scaling done by the desktop environment so that everything looks okay on both displays. What confused me a long time is that “scaling” meant different things when it came to xrandr and the desktop environment. Scaling in the desktop environment translated to zooming in the desktop by 1.5x (“downscaling”) to make everything look larger and (up)scaling the display using xrandr meant zooming out the Xorg display for the monitor 1.5x to make everything look smaller.
A lot of different xrandr commands were given as examples. However, all of those were for setups different from mine and used a lot of parameters and flags without a general explanation of what they do and how to adapt them for other scenarios. This was very important for someone like me who isn’t familiar with the terminology. So for a while, I had to resort using just konsole on the secondary 1080p monitor with the font size reduced to make it look okay and the interface elements still looking large and ugly.
Eventually, I found out the solution that I needed – scale the desktop environment 1.5x which reduced the effective resolution of the 4K (3840×2160) monitor to 1440p (2560×1440) and that of the 1080p (1920×1080) monitor by 1.5x to 720p (1280×720). That made everything on the 4K monitor look properly sized and large on the 1080p monitor. To fix that, I had to use xrandr to upscale the 1080p display by 1.5x (2880×1620) to compensate for the desktop environment’s 1.5x scaling. With that, everything looked good on both monitors. Below is the xrandr command that I used.
The fbmm flag sets the reported physical size of the X screen as a whole. In this case it is (3840+2880)x(2160+1620), which is the sum of the resolutions of both monitors after running the xrandr command. The --pos flag is used to position the monitors in the 6720x3780 display. Since the 1080p monitor is present to the left of the primary 4K monitor, its position is at 0x0. The starting position of the 4K monitor is 2880x0, where 2880 is the horizontal resolution of the 1080p monitor, so that it is positioned right after the latter ends.
This still caused an issue on the 1080p monitor where the Plasma desktop screen was reduced in size by 1.5x and was not filling the whole display. This also meant that the wallpaper was not filling the whole display. The unfilled area in that display was black in color. (Update May 2020: this can be fixed by restarting the Plasma Shell) To work around this issue, I used black color as the wallpaper for that screen and removed all the elements on that desktop. Till very recently, I continued using black color as the wallpaper and when I found that this was fixed in a recent Plasma update (not sure when and which version), I was able to use a proper wallpaper on the 1080p monitor as well.
While this solved the major problem with mixed DPIs, the GUI toolkits (Qt 5, GTK 3) and some applications like Firefox needed some additional scaling tweaks to get them looking okay. For this I used the excellent documentation on HiDPI in the Arch wiki which covered almost everything. Steam and VirtualBox were a couple of notable exceptions that didn’t work okay. The former didn’t support fractional scaling and only worked with 2x scaling which makes everything noticeably larger. The latter was broken and had a lot of issues with the menus appearing in the wrong places and the guest VMs unable to use a proper resolution. Fixing this issue required setting QT_SCREEN_SCALE_FACTORS to 1.0.
I have been using LineageOS on my Redmi Note 4 phone from the day I bought it. Till yesterday, I was running LineageOS 15.1 on it with encryption enabled. Since I wanted to try out the new Pie release, I tried installing the Resurrection Remix 7.0 ROM based on the Android Pie release. After setting everything up and restoring all the apps and data using Titanium Backup, I tried encrypting the device. However the encryption process failed and caused the phone to do a quick restart.
Since this was totally unexpected, I checked the error messages using the adb logcat command. The error message was
E Cryptfs : Bad magic for real block device /dev/block/bootdevice/by-name/userdata
E Cryptfs : Not a valid ext4 superblock
Orig filesystem overlaps crypto footer region. Cannot encrypt in place.
This was strange because the userdata partition that is mounted at /data was formatted normally using the ext4 filesystem. Searching the internet lead me to this Reddit post which gave some useful pointers about the issue.
I tried to resize the userdata partition by formatting it from the bootloader and voilà the encryption succeeded on the next boot after a clean install. So I started restoring the apps and data from the backup and when it was about to complete, I got an error notification which said internal storage running out, some system functions may not work.
I was surprised by this since my phone had 64 GB of internal storage and there is no way for all of it to get used up. I also wondered if it was due to the encryption of the new apps and data (like what Bitlocker does on Windows by showing the disk to be 100% full while it is doing the initial encryption). (After resolving this issue later, I found this to be this reported issue). I started to suspect that something is broken with the installed ROM. I wanted to flash the stock MIUI ROM to check the partition size but it was difficult to find a working download link for the official fastboot ROM files because of issues (intentional?) with the Xiaomi site as usual.
After flashing the stock ROM via the fastboot interface and then flashing TWRP and then the ROM, GApps and Magisk, I booted into the OS to find the internal storage size detected correctly. However, when I tried to encrypt the phone it failed again with the initial error.
Suspecting some issue with the ROM, I installed LineageOS 15.1 because the encryption was working fine on it. But unfortunately, even with LineageOS 15.1, the encryption was failing with the same error. Since I had already spent too much time trying to fix this, I gave up for the time being and went to sleep.
This morning, I researched this issue further and found this post, which revealed this to be an issue with TWRP 3.2+ not formatting the /data partition properly and the solution was to use a 3.1 version to format the userdata partition and then use the latest TWRP to flash Oreo ROMs or newer because of the compatibility requirements. Luckily for me, it worked perfectly and now my phone can run the Pie-based ROM with data encrypted.
One important lesson I learned from this experience is to be conservative when flashing/switching ROMs because I often end up spending a lot of time to get everything working as expected and also have to suffer phone downtime. Another thing I reminded myself (again!) to do is to periodically download and keep backups of the stock fastboot ROMs because of how unreliable the official site can be.
Update (May 2020): Use Barrier, which is a maintained fork of Synergy that supports SSL by default and has builds for Windows, macOS and Linux.
Synergy is a free and open source software (licensed under GPLv2) for sharing one keyboard and mouse between multiple computers. The source is hosted here on GitHub and the Synergy website provides compiled, installable releases with support for SSL encryption for a fee.
At work, I have a Macbook Pro laptop running OS X El Capitan and an Ubuntu 16.04 desktop connected to a monitor which I use daily. Working on two separate computers at the same time is laborious and thanks to Hiemanshu, I came to know about Synergy.
Eager to try it out, I built it from source after patching (to use the Qt installed on my Macbook using Macports) and with minimal configuration, I was able to get it to work. But since my computers were connected to the corporate network, I did not want my keystrokes to be sent through the network in plaintext. So till today, I used an SSH tunnel between my Macbook acting as the server and the Ubuntu desktop acting as a client. It was a little bit inconvenient having to setup the SSH tunnels every time and I didn’t want to use something like autossh.
Imho, in the post-Snowden era, any software sending sensitive plaintext data through the network is broken by design. Since Synergy is free software, I was hoping to patch it to allow SSL communication without requiring a license. With some help from the comments and pull requests on the Synergy GitHub repository and some additional tweaking, I was able to build Synergy 1.8.8 with support for SSL irrespective of the licensing status.
The following details of how I managed to do it are primarily for my reference and I am sharing it on my blog in the hope that it might be useful for others as well. That said, Synergy is a very useful free/libre software and I recommend purchasing a license to support the development. One of the Synergy developers has committed to enable SSL communication by default in the 2.0 version.
Steps to be followed on OS X El Capitan
Clone the Synergy GitHub repository from and checkout the 1.8.8-stable branch
Apply this patch to fix the Qt related paths and also to enable SSL without license check. For Qt installed without using Macports, tweak the frameworkRootDir variable in the patch to point to the correct directory. Also tweak the path to the Info.plist to point to a valid path.
If the Mac OS X 10.11 SDK is not present under the /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs directory, Download it from this GitHub repository and copy it to that directory.
Install the dependencies of Synergy (cmake, qt5) using Macports.
Navigate to the top-level directory of the repository and run ./hm.sh conf -g2 --mac-sdk 10.12 --mac-identity ElCapitan where the current OS is El Capitan and the available default Mac OS X SDK is 10.12. Modify the parameters based on the available SDKs and the OS version.
After the previous command completes without errors, run ./hm.sh build to start the build process.
To create a Mac app, run ./hm.sh dist mac.
The Synergy.app is available under bin/Release/Synergy directory. Drag and drop it to the /Applications directory.
Create the SSL certificate needed by the Synergy server by running the following commands
Navigate to the top-level synergy repository directory and run
./hm.sh conf -g1; ./hm.sh build; ./hm.sh; ./hm package deb
This builds Synergy and creates a .deb package file under the bin directory.
Install the .deb file using dpkg.
Start the Synergy app from the Unity launcher (or alternatively using its full path).
Configure it as a client and set the server address to that of the computer running the server.
The app will display the server’s certificate fingerprint with a prompt to trust or reject it. Trust the fingerprint after carefully verifying it. If there are any errors with the server fingerprint or trusting it, copy the Local.txt file generated on the server and save it under ~/.synergy/SSL/Fingerprints and restart the client.
Cyngn has struck a deal with TrueCaller to integrate it with the default dialer app on Cyanogen OS 12.1. For a privacy-conscious person like me, it was totally unacceptable given the notorious reputation of TrueCaller. Read this post on XDA-Developers for more details.
Here is how I got rid of TrueCaller. Before installing the OTA on my OnePlus One, I turned off mobile data and Wi-Fi so that I could prevent any internet access till I removed TrueCaller. The phone rebooted after installing the Cyanogen OS 12.1 OTA update (which has been pulled due to some issues at the time of writing this). Immediately after that, I opened the dialer and was prompted to enable TrueCaller. I refused it by selecting Not Now.
I also went into the settings menu of the dialer app to make sure there was nothing related to TrueCaller enabled by default. All this just disables TrueCaller but does not remove it entirely. Read on if you want to completely remove it.
Since the TrueCaller app does not show up in the App Drawer, go to Settings ? Apps ? All and scroll down to the TrueCaller Service app. Tap on it and uninstall it from the App Info page that shows up.
Now your phone should be free of TrueCaller and its privacy issues. If you go to the settings menu of the dialer app, you can verify that there are no settings related to TrueCaller.
This should work for any device for which Cyanogen OS 12.1 is released.
In case you have a change of mind after doing this and want to reinstall TrueCaller, you can do that by navigating to /system/vendor/bundled-app/TrueCaller folder using the File Explorer app and installing the APK that is there. The /system/vendor/bundled-app/ folder contains the APK files for all the other pre-loaded (but removable) apps like Boxer, Browser as well.
GNOME 3.14 supports captive portal handling but it is not enabled by default in Debian Jessie probably due to the privacy concerns. To enable it, create a file /etc/NetworkManager/conf.d/20-connectivity-debian.conf with the following content:
[connectivity]
uri=http://network-test.debian.org/nm
response=NetworkManager is online
interval=300
Then restart NetworkManager using the command service network-manager restart as root user (or use sudo if your non-root user has sudo privileges). Once this is done, whenever you connect to a network with a captive portal, GNOME will automatically open the captive portal login page where you can login to get access to the internet. Please note that the requests to the connectivity test URL could be logged and be aware of its privacy implications though no personally identifiable information is sent.
This is very helpful for me since my ISP ACT Fibernet requires its users to login to its captive portal before allowing internet access. Hope this is helpful for others. The configuration given above tries to reach the specified URL once every 300 seconds and tries to open the captive portal login page if it is not reachable. This could cause the NetworkManager applet to try opening the login page if there are any issues with the internet connectivity. So feel free to tweak the interval according to your needs.
