Farewell Father Debian…

Another rant coming up. This time the target is Debian, the father of all and naught. In my endless pursuit of the Zen of lightweightness and small memory footprint I sailed to Island Debian. Everyone knows how Debian is the Most Stable Thing on Earth (besides granite deposits, of course). I installed it, used it and greatly enjoyed user-friendliness in the form of sane configurations, yet moistened in a sweet-sour flexibility juice. Love it!


Debian Stretch with slightly customized Xfce4

Then I came up with this obscene and perverse idea – why not contribute? I like writing tutorials, protocols and articles centered around getting things to work. Debian has a great reputation so the idea did not occur to me as particularly bizarre (the 2 beers in me made matters easier). I looked at the hardware compatibility documentation and almost got a stroke. Yes, it’s stuck on kernel 2.x, while the most recent kernel version is already 4.5. In developers’ years we’re talking about eons here. I thought it should be rather simple to write new documentation, correct? Wrong…

I investigated the main website and admittedly, it’s an absolute mess. Finding anything, including images for Debian Testing requires a certain level of clairvoyance. I wrote on Debian’s IRC channel – no response. I signed up for the debian-doc mailing list and e-mailed my pleads there – no response again. Also, most circulated e-mails dealt with translations to some less popular languages. Frankly, who cares about translations when most of the documentation is absurdly outdated…?

On my previous attempts to wholeheartedly like Debian, I also had problems with broken packages. Might as well bring this up as the issue is recursive. I know, Debian Testing is meant for testing (duh!). However, upstream to it we have Debian Experimental and Debian Unstable. How can an important package such as rsyslog with obviously broken dependencies pass through both of the above and be completely ignored? Has no one tested it prior to releasing? Debian proudly announces on its main website that the repositories hold more than 50,000 packages. How many of them have equally broken dependencies? How many are still maintained upstream? That painfully reminds me of the legacy fglx driver issues that eventually led to frying my discrete AMD graphics by accident. The offending package was still in Debian Wheezy repos, even though the packaging team no longer existed (?!). Curiously, Debian Jessie retained this package in a non-upgradeable, broken form (missing/conflicting dependencies, not cleaned after Wheezy). Why not simply drop it if it’s broken AND unmaintained? Things like this happen all the time. There are too many packages to handle properly… I’m sorry to say it, but Father Debian is getting senile.

Then, I remembered an operating system that has both superb documentation and management – FreeBSD. The only thing stopping me from using FreeBSD fully was missing wireless drivers. This is not the case anymore, as both of my Realtek WiFi USB adapters have FreeBSD drivers. This ship has sailed again – back to its ancestral Unix harbor!


Choosing the FOSS Fighter’s Gear…

…is still as difficult as ever! Recent study of minimal GNU/Linux desktop setups helped me jot down the bare essentials I expect from a work-centric PC laptop:

  • 2-core processor clocked at 2.0+ GHz
  • 2+ GB RAM
  • 250+ GB hard drive
  • Intel HD or AMD integrated graphics
  • wireless (Intel or Atheros)
  • 13-14″ screen

You might laugh at this point, dear reader, all you want. I’m an old geezer (mentally, at least) and anything past year 2000 is new and shiny to me. Also, not every cheap laptop fits the bill. Usually budget computers have 15″ screens, which is perfect for sitting on the desk, though far from perfect when sitting on my lap when horse riding. On the other hand, 13″ ultrabooks often lack a built-in DVD-ROM to save on space and weight. 14″ laptops are perfect, because some of them still do have DVD-ROMs, regardless of how much Apple considers DVDs and CDs legacy stuff. One can still buy music on CDs, mind you!

To cut the story (and crap) short, old Dell and IBM/Lenovo laptops are the best. They typically have tried and tested components, mostly manufactured by Intel. Some IBM/Lenovo Thinkpads sport a CPU and more rarely a GPU slot that accepts a set of various units. While not mandatory, it’s often a nice bonus when one thinks of how easily laptops break and how expensive it is to replace the motherboard ($200+, ouch!). No wonder OpenBSD developers choose Thinkpads for work on the run.  A major piece of advice, also – never entirely trust any wireless adapter/chip that is not from Intel or Atheros. Broadcom is notorious for shifty drivers and Realtek is like mining for gold at an earth gas deposit. Maybe it will work or maybe it will blow up in your face…

Alright, we have the basics downs, where is the problem? The thing is, getting the details from laptop manufacturers is tricky. Lenovo, Dell and HP typically post complete datasheets on their websites, though they produce decent hardware so no problems there. Asus let me down royally prior to my purchase of an 13″ S301 ultrabook. Not sure why it was more important to include in-depth information on Windows 8 and skip all of the relevant hardware details. I still bought the ultrabook, because it was nicely built and had impressive cooling. Enough said.

The other problem is hardware vendors. Why should I be forced to fish for datasheets when shopping for laptops? I thought it’s the hardware vendors’ responsibility to post the basic details of a device on their websites. No, ‘N/A’ next to the ‘Integrated Graphics Memory’ category is not the correct way to do it. Also, there is a huge difference between Intel GMA and Intel HD Graphics 3xxx/4xxx. They should NOT be thrown together into the ‘Integrated HD Graphics’ happy basket. At least this much should be available. Not to mention that quite often the description is incomplete and a lot of the details are missing, like RAM capacity. I’m not asking for RAM operating frequency, because that would obviously be outrageous, no?

To wrap it up, I wish choosing hardware suitable for GNU/Linux and other Unices was not as demanding. Fortunately, we have the Power of the Community to back us up. Plenty of online resources are available for the taking.

GUI Design vs Software Engineering

I gently touched on the topic of graphics design practices vs software engineering in my last entry, though as it seems to bug me quite some, I decided to elaborate. Referring to Windows’ history, I believe the usefulness of graphical interfaces ended around Windows 98-Windows XP, with the latter containing slightly too much bling than I found comfortable. It might be because Windows XP was the last Microsoft operating system I trusted and used almost until it turned end-of-life. Nostalgia is a human thing, after all! Nevertheless, I trust my judgment and have a strong feeling that anything past Windows XP has far too much emphasis on graphical user interfaces. However, I don’t want this entry to become another Why I hate Windows rant from a hurt keyboard warrior. Moving on, then!

When I write a piece of software I typically start with the raw code and focus only on the CLI (command-line interface), until I’m comfortable with how the program works and I am certain that most bugs were caught. Obviously, if the program requires a lot of user input and some operations will be repeated, a GUI (graphical user interface) is indeed needed. Following the KISS (Keep It Simple Stupid) principle, GUIs are supposed to simplify mandane tasks, but also provide the user with direct means of exerting low level control over the piece of software. Therefore, it is important that the GUI is simple and agrees with WYSIWYG (What You See Is What You Get). Further additions are just for eye-candy.

Hence, it really pains me when the primary focus is development of user interfaces. Alone they mean nothing and should something break, we’re dependent solely on the developer. How many of us have seen useless prompts with error codes that mean nothing or are too ambiguous to interpret? Or those occassions when the GUI crashes and we have no idea what happened? That’s why I prefer CLIs and use them until they become too cumbersome. My perfect GUIs are those built by people to simplify window manager configuration, because out of necessity they contain only the most important set of features and give direct access to variables. Glorification of gloss and shine may make the program pleasing to the eye, but long-time use will prove dissatisfying and tiring.

The only beautifications I accept are those that do not interfere with functionality. Back in the old days Apple developed an elegant, consistent style following the teachings of Italian industrial designers. Slight gloss and a clear, grey-white look dominated all applications. This appearance is still used today across all Apple devices, because it has proven to be the perfect balance between pleasing the eye and the mind alike. While I am not a big fan of Apple, it should be said that in terms of GUI design, they did hit the spot!

Manjaro JWM vs BunsenLabs as Lightweight OS

Recently, I’ve been on a hunt for a lightweight GNU/Linux operating system for my Asus Pundit P1-PH1. As one can gather from my last entry, I chose BunsenLabs Linux. However, I did use AntiX on a half-broken Dell Latitude d520 some time ago and became quite fond of IceWM and JWM (Joe’s Window Manager) as desktop environments (sort of). Truth be told, both of those are lighter than Openbox and IceWM in fact may work as a full desktop environment (minus desktop icons, though). Thereby, I decided to give Manjaro Linux 16.04 JWM edition a try.


To begin, I think that the comparison is absolutely unfair. BunsenLabs is built on Debian Stable, while Manjaro packages are derived from cutting-edge Arch Linux. Hence, the kernel, desktop and app versions differ. What is similar though, is the concept of lightweightness, and therefore the software selection partially overlaps. When comparing, I had several criteria in mind – RAM & CPU usage, theming/look, ease of use, stability/reliability.

First, RAM and CPU usage. Both systems are very snappy, though because Manjaro Linux utilizes JWM, ambient RAM consumption was somewhat lower on Manjaro than on BunsenLabs’ Openbox. In addition, Debian does a lot of behind the scenes work preemptively to assure smooth user experience. On the other side of the spectrum, minimalistic Manjaro avoids interfering with user choices, though some basal configuration is done by various scripts. A slight favor to Manjaro Linux on this one.

Next up, theming and look. Manjaro Linux relies quite heavily on flat themes, which seem to be the craze since the inception of Windows 10. In regards to computer use I am a truly old geezer (sage, hermit, you name it!). I prefer a simple, slightly opaque look, preferably with emphasis on the color grey (in less than 50 shades, mind you!). Crunchbang Linux piqued my interest in the past, hence I give this point to BunsenLabs, which continues Crunchbang’s legacy. To be fair though, both operating systems have a very unique and consistent look that simply appeals to different demographics.

One but last, ease of use. Again, both operating systems are rather easy to use, at least according to my doggish, Arch Linux influenced standards. Manjaro sports the Manjaro Settings Manager that allows one-click kernel installation & selection, and easy driver selection for all devices, much like the Drivers app in Ubuntu. In fact, Manjaro strives to be at least as user-friendly as Ubuntu, with much success. BunsenLabs is a lot more conservative in comparison. Basic configuration is done for the user, but adjustments may require delving into text files. Fortunately, I am familiar enough with Openbox and completely don’t mind such incoveniences. A point for each contestant then!

Finally, stability. Here the difference is the most significant in my opinion. BunsenLabs was built on Debian Stable, the most tried and tested GNU/Linux distribution, save for CentOS and FreeBSD. Things can go wrong, but this happens very rarely. Usually, there are problems with the initial setup on partially supported PCs (for instance, laptops with nVidia Optimus graphics). Once those are solved, things run rather smoothly. Debian’s vetting process sieves out almost all bugs before they get to the Stable release. While Arch Linux is incredibly stable, considering its cutting-edge nature, Manjaro often suffers from the instability of the added bling. On standard hardware (read: T-series Thinkpads), Manjaro works fine. However, with dubious devices like my Realtek 8188eu USB WiFi dongle things can go awry. Point to BunsenLabs fo making a good call and choosing Debian Stable.


To wrap it all up, my comparison favored BunsenLabs, though I feel I am biased due to my legacy inclinations. Both Manjaro JWM and BunsenLabs are great in their own regards, however to each his/her own. BunsenLabs for those of us who prefer a stable and reliable working environment and Manjaro JWM for pirates and people who like to live on the edge.

Disclaimer: the images were taken from the Manjaro and BunsenLabs websites. I do NOT own them!

Pumping Performance with Asus Pundit!


Some time ago I became good friends with a certain Asus Pundit P1-PH1. I found it, sad and forgotten, in a local electronics dumpster. Initial diagnostics showed a dead PSU, which I replaced with one from an old MSI small-form factor desktop PC. I also expanded the RAM to 2 GB 533 MHz (maximum it can take) and swapped the single-core Intel D for a faster Pentium 4 processor, clocked at 3.20 GHz. After some reading I realized that the memory can be clocked up to 667 MHz. As I have 2x 1GB 667 MHz DDR2 bricks, I will upgrade this box in the nearest future. To top it off, a 120 GB IDE drive.

The Pundit is a rather dated piece of hardware, though thanks to GNU/Linux I can restore it back to its former multimedia centre glory. As my operating system I chose BunsenLabs Linux, based on Debian Stable. Other noteworthy alternatives are Debian Stable itself, Arch LinuxManjaro Linux, Bodhi Linux, AntiX and Peppermint OS. Frankly, Arch Linux  would be the lightest on resources, but I always have problems with theming and Pundit has some slots/ports I am not entirely familiar with. In other words, the less to configure, the better!

BunsenLabs offers a fairly easy installation procedure, as the installer is based on Debian’s original installer and the bl-welcome post-installation script handles many useful to-dos. Still, I did some minor tweaks to improve my user experience. Below, a summary:

  • Spacefm as file manager instead of Thunar
  • Midori as Internet browser instead of Iceweasel/Firefox
  • Volumeicon as volume icon instead of Volti
  • Blacklisted redundant kernel modules in /etc/modprobe.d/
  • Installed firewalld and the firewall system tray applet
  • Installed additional plugins for Geany

I almost never use more than 1 GB of RAM and CPU usage rarely exceeds 50%. Then again, I don’t do anything especially fancy. It is highly likely that Windows XP would run smoother on this machine, though without regular updates, GNU/Linux is the only safe option. Thereby, grab your favorite GNU/Linux distro and make your legacy hardware shine once more!

The Bloating Bit

First, apologies for being away from the blog for so long. I took time off to start properly learning Python with O’Reilly’s great Python Pocket Reference. My last post dealt with lightweight, yet feature-rich GNU/Linux distributions. Somewhat still in that mood, I took a trip to a local flea market to grab some gaming gems of times long passed. It really brought back memories, but also blantly reminded me that in early-2000 one could have loads of fun with barely a Pentium 4 computer. This in turn brings me to a very distressing phenomenon that gained momentum during the last decade – bit rot.

Although this is not entirely fair, I put the blame mainly on gaming consoles. In former times computers were the domain of gamers and games themselves had to be written more efficiently as the hardware was lacking. This quickly changed and now instead of pressure on performance, we have pressure on buying new hardware to match demanding games. While this shows that game developers got lazy and are less inclined to write good code, the real problem are gaming consoles. The market has shifted drastically in the last decade and gaming consoles are no longer the toys I remember from childhood years, but somewhat serious contenders in the never-ending PC vs console duel. Alas, because PC hardware development is dynamic, consoles quickly fall behind and games have to be stripped down (but not written more efficiently!) of visuals to make them run smoothly. Due to the fact that those consoles are now the prime receivers of game franchises and A+ titles, computers are often left as an afterthought. This in turn leaves games ill-suited for more powerful PCs, because A) porting and optimizing games for PCs requires resources that many companies don’t have and B) very often games will look butt-ugly, because higher resolution models and textures were never planned. Regardless, there seems to be an unhealthy focus on visuals, rather than performance and functionality.

The emphasis on user interface (UI) design shows also in regular software. Suddenly, flashy animations, twinkling objects, sounds, etc. are more relevant than how well a piece of software runs. I have a feeling that many things have already been established at least some 10-20 years ago and lots of new software is developed simply to generate revenue.

Sadly, the GNU/Linux ecosystem suffers from this as well. Tried and tested low-level tools were obfuscated with layers of UIs, which in theory make the life of the common everyman easier, but in practice just force him to rely on badly designed software. For instance, we used to have /etc/fstab for all of our storage device mounting needs, but that didn’t seem to be enough and people had to invent udev and its ilk. Nowadays just doing something forces blind reliance rather than comprehension. Not sure we (the veterans) can fully appreciate that. Frankly, flourishing hardware development should be an incentive to produce greater software not write crappy code, assuming it will run anyway…

The Easy and the Lightweight

Recently, I switched from Manjaro Linux to Arch Linux to get closer to the heart of my GNU/Linux operating system again. It’s pleasant to be in full control of what’s going on under the hood. However, often there are those small things. How do I know which packages are required for handling the multitude of archive formats (tar.gz, .zip, .7zip, etc.)? Why does the file manager not automatically link images to the only image viewing app I have on my system? We all suffer from similar problems and in some way it doesn’t have to be all on the user to figure things out. However, as with great power comes great responsibility, easy to use GNU/Linux distributions typically come with lots of unwanted software that only overburdens our precious machines. Thus, I asked myself – can I get some but not all?

Not entirely surprisingly, Yes. GNU/Linux is flexible enough that many lightweight distributions were born to cater to users with minimal needs. Below, a short round-up:

Bodhi Linux – based on the current Ubuntu LTS branch, it was one of my first GNU/Linux distributions. Although Enlightenment was substituted with its fork, Moksha, it is still equally lightweight. Bodhi will perfectly suit those of us who prefer simplicity and don’t want to be overwhelmed by software choice. The one application per task rule stands strong.

Peppermint OS – also based on the current Ubuntu LTS branch. Peppermint OS makes great use of web-based applications through its Ice web-app creator/linker. Favorite services like Facebook or YouTube can be locally linked in a browser window to mimic software installed on the hard drive. The desktop environment is a mix of LXDE and Xfce.

BunsenLabs Linux – successor to the Debian Stable-based Crunchbang Linux. It’s a community project that intends to continue Crunchbang’s legacy as a fuss-free Debian Stable distribution. It utilizes Openbox with components from Xfce as its desktop environment. A fantastic alternative to those who don’t like installing Debian from scratch.

AntiX – also based on Debian Stable, though with an option of switching to Testing or Unstable at install time. Out-of-the-box it offers numerous applications for typical daily tasks, still staying true to its lightweight nature. The developers push really hard to make AntiX run smoothly on low-end computers. Granted, it was the only complete distribution that worked smoothly on my ancient Intel Pentium M EeePC.

All of the above distributions do great deeds in terms of resource usage and can be installed even on antiquated PIII machines. Their main strength is that they offer the same base functionalities as full-blown distributions, still requiring barely any CPU and RAM. Every single one of them is worth at least trying out!