In Software We Trust

Inspired by the works of Matthew D. Fuller from I decided to write a more philosophical piece of my own. While distro-hopping recently it came to my mind that whatever we do with our lives, we never do it alone and our well-being depends on other people. It requires us to trust them. Back in prehistoric times a Homo sapiens individual could probably get away with fishing, foraging and hunting for food, and finding shelter in caves. The modern world is entirely different, though. We need dentists to check our teeth, we need groceries to gather food, we need real estate agents to find housing, etc. Dealing with hardware and software is similar. Either we build a machine ourselves or trust that some company X can do a good enough job for us. The same goes for software!

Alright, so we have a computer (or two, or ten, or…) and we want to make it useful by putting an operating system on its drive(s). MacOS X and MS Windows are out of the question for obvious reasons. That leaves us with either Linux or a BSD-based system. Assuming we pick Linux, we can install it from source or in binary form. This is where trust comes into play. We don’t need to trust major GNU/Linux distributions in terms of software packaging and features. We can roll with Gentoo, Linux From Scratch, CRUX or any other source-based distribution and decide on our own what does and doesn’t go into our software. It’s kind of like growing vegetables in a garden. Granted, we ourselves are responsible for any immediate issues like compile errors, file conflicts or missing features. It’s a learning process and one definitely profits from it. However, it’s also time-consuming and requires extremely good understanding of both system design and the feature sets of individual programs. No easy task that. Therefore, it’s far more convenient to use binary distributions like openSUSE, Ubuntu, Fedora, Debian, etc. It requires us to trust that the maintainers and developers are doing a good job at keeping software up-to-date, paying attention to security fixes and not letting bugs through. I myself don’t feel competent enough to be a source-level administrator of my own computer and be able to fix every minor or major issue in C++ code. I prefer to trust people who I’m sure would do it better than me, at least for now.

Curing GUI Phobias

Since some time I’m a happy openSUSE camper, yet often frequenting the main Fedora IRC channel. Truth be told, It was tough to decide between those two distributions as both are extremely solid and bug-free. My third choice would fall to one of the Ubuntu spins (Xubuntu or Lubuntu most likely). Eventually,  I realized I’m less and less inclined to put in that extra time to set up Arch Linux or Gentoo per self-indulgence. I know I would be able to, but why should I? I’m familiar enough with Linux to roll any distribution. It seems my impressions go hand in hand with those of Roger from Dedoimedo ( I’m sure he too would be able to install Arch Linux on any PC of his choosing, though again why should he?

Many modern Linux distributions are solid, finished products. You can install them on anything from a bootable USB or DVD and just get things done. That’s precisely the point. It took years, buckets of sweat and units of blood to reach that state. However, now we’re here! More so, we’ve beaten Windows, because it’s still as much of a pain to install as it used to be a decade ago. Therefore, instead of repeating the rite of passage (read: installing Gentoo or Linux From Scratch on a laptop), we should move forward. There is this wrongly placed elitism in some of us in the Linux and Unix communities (mea maxima culpa!) that if you don’t run a hardcore distribution on your shoddy PC, you’re not nerdy enough. So far from truth this be! Nerdy stuff can be done on virtually any of the mainstream distributions. You can set up servers running Ubuntu Server (duh!). You can build datacentre grade boxes with openSUSE Leap. File server on Raspberry Pi? Yup. And so on. No need to spend hours hacking the Linux kernel to squeeze out that extra 0.000000001% performance gain, thinking that alone makes us Computer Wizards. The important thing about mainstream distributions to bear in mind is that someone poured hours of their free time to assemble together the Linux kernel, utilities, a desktop environment, repositories, etc. All of this so that we wouldn’t have to do it ourselves. Isn’t that golden? Truly, we should build on that rather than shun it.

I understand this stands in stark contrast to my former preachings. I, like many others, have escaped from Windows because it was overburdened with black-box utilities and hidden system services. It was a pain to fix without bricking it entirely. However, it’s actually nice to have a pretty GUI and helper tools to simplify system maintenance. The main difference is that Linux-based operating systems are highly malleable, well-documented and can be adjusted to our liking. I realized that’s probably the main reasons I switched.

Skype for Linux Woes

First and foremost I would like to thank Microsoft and contributors for considering our measly 1+% of desktop coverage and beginning works on the Skype on Linux desktop app. Frankly, previous Skype 4.2 and Skype 4.3 releases felt like rotten meat scraps thrown at a dog (or penguin) and were equally dangerous to Microsoft as to Linux users due to lacking security updates. However, one should be positive as there is light in the form of Skype for Linux Beta. Overall, the app is quite polished and doesn’t have too many graphical glitches. Alas, there are some things to consider still:

  • Only .deb and .rpm packages are available. This strange practice is quite common and I still don’t understand why a tarball with the binary + libraries is not offered alongside. There are many Linux distributions that use other packaging formats. Are vendors afraid that some hacker might reverse engineer the binaries? On top of this, Debian .deb archives can be quite different from Ubuntu .deb archives. Same with Fedora and openSUSE.
  • The website states “Video call your contacts.”. What it doesn’t mention is that this option is not available just yet. We learn it the hard way when calling our Windows-using parents. No talking heads for now, unfortunately.
  • Close to none debugging capabilities. This one pains me the most. The app is clearly denoted as a beta version, therefore one might assume that each user is in fact a beta tester. Any and all feedback would clearly be valuable to Microsoft. Yet, the app doesn’t leak any information to the terminal by default at all. Also, no something went wrong, please send us this pre-formatted report feature is available. I mean, really.
  • Bad software design is bad software design. I accidentally kept typing in the wrong account name, forgetting the domain for users is @hotmail, not @microsoft. Obviously, the account didn’t exist, but instead of telling me this, the app would show a glitched error screen with a Sorry…an unexpected error occurred. This is so Windows 98, honestly. No traceback, no nothing. Also, the Sorry and a cryptic error reference ID don’t really help anyone. What\s up with this attitude?

They’re on the right track, but plenty of polishing is needed. Truth be told, no piece of software shines from the get-go. Uncut diamonds need cutting. That’s just the way the world works.


Fedora 26 – RTL8188EU the Hard Way!

Following my former entry preaching on the greatness of Fedora 26, I decided to share some wisdom regarding USB wireless adapters (aka dongles) with the Realtek RTL8188EU chip. These and many other Realtek-based (usually RTL8188EU and RTL8192CU) adapters are affordable and extremely common. Companies like Hama, Digitus, TP-LINK and Belkin fit them into the cheapest 150N and 300N dongles, claiming that they’re compatible with Linux. In principle, they are. In practice, the kernel moves so fast that these companies have problems keeping up with driver updates. As a result,  poor quality drivers remain in the staging kernel tree. Some Linux distributions like Debian and Ubuntu include them, but Fedora doesn’t (for good reasons!) so Fedora users have to jump through quite some hoops to get them working…

The standard approach is to clone the git repository for the stand-alone RTL8188EU driver, compile it against our kernel + headers (provided by the Linux distribution of choice) and modprobe load if possible. Alas, since the stand-alone driver isn’t really in-sync with the kernel, it often requires manual patching and is in general quite flaky. An alternative, more fedorian approach is to build a custom kernel with the driver included. The rundown is covered by the Building a custom kernel article from the Fedora Wiki. All configuration options are listed in the various kernel-*.config files (standard kernel .config files prepped for Fedora), where “*” defines the processor architecture. Fortunately, we don’t have to mess with the kernel .configs too much, merely add the correct CONFIG_* lines to the “kernel-local” text file and fedpkg will add the lines prior to building the kernel. The lines I had to add for the RTL8188EU chip:

# ‘m’ means ‘build as module’, ‘y’ means ‘build into the kernel’

This however will differ depending on the Realtek chip in question and the build will fail with an indication which line in the kernel .config was not enabled when it should’ve been. Finally, if you do not intend to debug your product later on, make sure to build only the regular kernel (without the debug kernel), as that takes quite some time.


Fedora 26 Beta – the Killer Distro

Lately, I have been distro-hopping way too much, effectively lowering the output of my Java bytecode. However, that’s over, at least for now. I jumped from Lubuntu to Fedora to openSUSE to Lubuntu again and long story short I ended up with all of my computers (but not my family…) converted to Fedora 26 Beta. One might think it’s too soon since Fedora 25 is not end-of-life just yet. Too soon for the faint of heart maybe, not so for a geeky daredevil such as myself!


A cute Fedora doggie courtesy of the Internet

I tested Fedora 26 Beta as an upgrade from Fedora 25 on a legacy Dell Latitude E5500 (32-bit Intel Pentium M 575 + Intel GMA graphics), an aging and equally legacy MacBook 2008-2009 (64-bit Intel Core 2 Duo + nVidia Geforce 9400M GT) and yet another fossil PC – the Fujitsu-Siemens Celsius R650 (Intel Xeon E-series + nVidia Geforce 295 GTX). Each installation used the Fedora 25 LXDE spin as its base to keep things similar. No issues whatsover, even despite the fact that I heavily rely on the RPM Fusion repositories for nVidia and Broadcom drivers. This stands in stark contrast to any attempts to update Lubuntu or any Ubuntu spin I have tried thus far. My apologies beforehand, but personal experience with Ubuntu and its children is lacking on all fronts. Upgrading to a new release (even if it’s an LTS!) is like bracing for a tsunami. It will hit, hard. It seems that the dnf system-upgrade plugin has been perfected and is ready for shipping. Fresh installations of Fedora 26 Beta with LXQt were done on 2 PCs – an ASUS Vivobook S301LA (Intel Core i3 + Intel HD 4600 graphics) and an HP-Compaq Z200 workstation (Intel Xeon E-series + nVidia Quadro FX 1800). This time I used the Workstation flavor netinstall disc image as base. Again, only positive surprises here. All of the core Qt apps worked as intended. I was especially curious about Qupzilla, since it would often crash on other distributions (same with the webkit-gtk based Midori, in fact). I managed to write this entry/article without a single crash. I believe it is a testament not only to the various Fedora teams, but also to the Qupzilla, Qt and LXQt people who keep pushing forward with awe-inspiring zeal. Props, kudos and cheers!

Fedora 26 Beta is a great sign that Linux can into space. The experience is bug-free, solid and developer-ready so that I can return to taxing the OpenJDK JVM with peace of mind. Matter of fact, I begin to like Qt as a GUI framework and I am considering contributing to the Fedora project more ardently. They continuously provide me with great tools, I want to give something in return. We all take, we all should give.

The Kernel, the Kernel’s to Blame!


When getting my Raspberry Pi 3 set up recently I experienced quite some woes concerning out-of-the-box detection of SD cards. One might expect that an SD card slot is nothing more than a USB-like interface. In theory yes, in practice quite some distributions have problems with accepting that fact. Gentoo failed me numerous times, though partially because I decided to go for an extremely slim kernel config. Manjaro also surprised me in that respect – SD card detected, but not as a USB drive (thereby, not mountable). Fedora and Lubuntu had no problems. Each distribution uses a different set of graphical utilities and desktop environments so users often blame the front-end setup. That’s wrong, though, because the inability of a system to detect a piece of hardware has everything to do with the kernel configuration. Indeed, the kernel’s to blame.

I personally prefer the Arch approach – almost everything as modules. Although this could add significant overhead due to the way modules are loaded, in reality it makes Arch-based systems very light on resources. After all, what’s not in, doesn’t get loaded at all. The drawback is that the distribution or the user is required to ascertain that the initramfs is complete enough to allow a successful boot-up. The alternative is to integrate as many drivers as necessary into the kernel, though that of course makes the kernel bulky and isn’t always the optimal solution. There is a lot in-between that unfortunately causes weird issues like the one I experienced.

I think there should seriously be some consensus between distribution teams regarding what goes into a kernel and what doesn’t. Weird accidents can be avoided and it’s down to individual teams to iron that out. Of course, one can go hunting for drivers on GitHub and trying out 5 versions of a Realtek 8188eu driver, but why should the user be required to do so?

The (Necessary?) GNU/Linux Fragmentation

I would like to share with you a story of my recent struggles with Debian. They’re partially my fault, but also partially due to the way Debian handles network management, which is quite different from how other GNU/Linux distributions do it.

The story begins with me being happy with a regular desktop install, powered by XFCE4, but then wanting to switch to the less distracting Openbox. I installed Openbox + extras like the tint2 panel, nitrogen (background/wallpaper setter) and other lightweight alternatives to XFCE4 components. While sweeping up XFCE4 leftovers, “apt autoremove” accidentally removed way too many packages, including network-manager. I was instantly left with no network connection and no means of restoring it, as I learned later. By default network management on Debian is handled by the ifupdown scripts, which “up” interfaces listed in /etc/network/interfaces and direct them to dhclient to get the DHCP lease or assign a static IP address. Incidentally, ifupdown utils have no means of directing wireless interfaces to wpa_supplicant for WPA-encrypted networks. Nowadays, this is handled by network-manager, which “Just Works”. network-manager uses wpa_supplicant to handle WPA-encryption (in addition to many other things), whilst performing the rest of network management itself. This is quite different from running wpa_supplicant directly, which simply failed in my case due to a known regression.

It’s quite sad to see that Debian, despite moving from init scripts to systemd for boot + service management, still insists on configuring network interfaces via Shell scripts (the mentioned ifupdown tools), while a mainstream solution in the form of network-manager is available! Why is it recommended as a “Just Works” alternative yet not offered by default? On Red Hat based distributions (say Fedora, CentOS, etc.) the matter is really simple – you get network-manager and you’re good to go out-of-the-box. That stands to reason, though, as Network Manager is a Red Hat project. Still, the “Just Works” approach baffles me (and disturbs even) greatly. “Just Works” sounds like a catch-phrase typical of commercial operating systems. Since they target desktop and laptop computers mainly, it’s enough if an ethernet interface and/or a wireless interface “just work”. What about servers with multiple NICs, routers, gateways, NATs and VMs, each having its IP address or set thereof? What then? Oh, right, we can write systemd units for each interface and control them via systemctl. Or use the ip utilities for a similar purpose. Or the deprecated ifconfig, which we shouldn’t use, but still can because it’s in the repositories of many distributions. Alternatively, perform DHCP requests via one of the selected clients – dhclient, dhcpcd, dhcpd, etc. We end up with a hodgepodge of programs that are best left to their own devices due to incomplete documentation and/or unclear configuration means. Each GNU/Linux distribution having a set of their own base utilities.

Personally, I feel that’s where the BSDs succeed. You get a clearly separated base system with well-documented and easily-configurable tools that are maintained as a whole. Network interface configuration borders on trivial. More so, the installer handles wireless connections almost seamlessly. Why is it so difficult on GNU/Linux? At this point, I believe the GNU/Linux community would profit greatly by agreeing on a common “base system”. Red Hat’s systemd is the first step to the unification of the ecosystem. While I am strongly opposed to systemd, because it gives merely the illusion of improved efficacy by simplifying configuration and obfuscating details, GNU/Linux should be a bit stronger on common standards, at least for system-level utilities.