The Right Tool for the Right Job!

This week’s discussion on DistroWatch and this here blog entry motivated me to articulate certain concerns I bear in respect to choosing “the right tool for the right job”. codeinfig makes a couple of extremely valuable points in his writing (linked above). First and foremost, people (and I mean mostly end-users) should learn some old-school, decent modesty. Not everything has to be streamlined ad infinitumLearning is an important human activity. It stimulates the brain and provides skills useful in the future (Earth turning into an orange-ish nuclear mushroom and whatnot). Secondly, each tool was designed for a specific job and one should really spend some time to understand that job. Case in point, the PDF format. It was created to standardize end-point document presentation (especially for printing), including fonts, images, text, etc. However, that’s about it. It’s not meant as a dynamic file format nor for storing high quality images. These things it does badly. For these things we would be better off using HTML, for instance. However, rather than focusing merely on specific tools and their uses, I would like to discuss the consequences of using tools wrongly.

A great example of a tool is the web browser. We use it everyday for most of our modern-world Web-centric (read: almost all) activities. Unfortunately, as you might have noticed if you use average, off-the-shelf PCs, the Internet has become a place overloaded with data that serves no other purpose than to attract your attention. That data consumes a lot of computer resources for very superficial reasons. I browse the Web to read articles, watch videos and communicate with fellow humans. In other words, to experience the world. Reading requires properly formatted, well-contrasted text, sometimes accompanied by movies and/or images to ease the author in conveying his message. What it does not require is flying title bars, jumping windows, aggressive background animations, etc. Apparently, that’s what we mostly get in the Interwebs nowadays. How about we all throw a big, fat “NO”? How about we inform the people misusing web design for eye-candy that we don’t need all of this bollocks? I dare say JavaScript and CSS abuse should be frowned upon. Another thing wrong with the web browser as a tool is the fact that developers try to cramp as many features into it as possible. Chrome/Chromium is a nightmare in that regard. This modern disease is called “featuritis”. Why not then turn a web browser into an operating system, eh?  I forgot, we’ve got that already – ChromeOS!

I guess a rant would be useless without a proper take-home message. I believe we should not fall for first impressions and the notion of Swiss Army knife tools. They get inconvenient, broken, slow or just unsafe way too quickly. Let’s look for tools that do one job and do it well. In need of a GUI-enabled media player? There is mpv and mplayer already. Both can run in the terminal as well as with a pretty UI. They do everything a modern media player should. Still not enough? Try xine then! Minimalist, one-job tools are available in every BSD or GNU/Linux system’s repository. They just require finding.

Advertisements

Enter OpenBSD – part 1?

Becoming more and more security-aware, I was a bit shocked at how lax the default firewall setup in Debian is. Granted, in FreeBSD one has to toggle PF manually and write the first ruleset by hand. Both UFW and PF can of course be configured during install time already and the rules made strict. That’s beside the point though, because there exists an operating system that focuses on security much more – OpenBSD.

I used to read about OpenBSD here and there (mostly good things). Thanks to it we have OpenSSH and the LibreSSL cryptographic protocol. However, last time I booted the liveCD, it was quite daunting. I embraced the command line long ago, though OpenBSD still proved to be more challenging than I had anticipated. It was really a new and alien environment. Nevertheless, I decided to roll out an install on one of my legacy i386 computers – Dell Latitude E5500, sporting the 2.00 GHz Intel M processor. Not the fastest steed in the stable, though a perfect machine to test OpenBSD on!

The installation was quite uneventful, except for perhaps the weird CLI to fdisk and the overall dated looks. “Vanilla” OpenBSD runs FVWM on top of Xenocara (hardened X11 without 3D acceleration), which can be installed as one of the initial software sets to get a graphical user interface quickly. The XDM display manager was a welcomed addition, too. Surprisingly, OpenBSD is one of the very few operating systems that include a graphical user interface by default. It looks old in 2016, though I still remember the fun I had with Windows 3.11. Alas, there is no rose without thorns as they say…

…I plugged in my USB mouse and it didn’t work out-of-the-box. Quite the surprise, since the trackpad worked without hustle. Even FreeBSD provided me with a functional cursor already in the console. It seems that OpenBSD is a different beast altogether and requires some tinkering. Another surprise came later. OpenBSD has a very limited package management system. There is pkg_add to install software packages and a set of other pkg_* tools to get around the repositories. However, querying seems to be missing. Of course, one could pull in the Ports Tree and do everything there. Eventually, I’ll get to that. Still, the official documentation mentions that “regular” users better use binary packages.

More on the topic of the Ports Tree, forget everything you’ve learned from Gentoo or FreeBSD. OpenBSD’s system is more akin to CRUX Linux. To get wanted features no magical ncurses menu will help you. Embrace the Makefile. You’d better! Similarly, there is no official “apt dist-upgrade” or “freebsd-update” system update tool. Patches have to be downloaded, extracted and applied manually. Extremely daunting, no? Thankfully, some kind souls from M:Tier provided alternative means of upgrading OpenBSD systems with “openup” (more on it here) In general, there is a noticeable lack of automation many people might take for granted. For me that’s not really a problem, because I am willing to learn and read. Still, the learning curve is very steep indeed!

All in all, OpenBSD is an interesting operating system. It’s extremely minimal so that even very dated hardware can be used effectively. Also, the manual pages are absolutely unmatched. I learned a lot about windowing and display management just from reading the xdm manpage. On the other hand, OpenBSD is in dire need of extra manpower to make the project more noticeable.

Smartphones are Useless!

Not rocket science, nor a discovery on the scale of Columbus’ deed. However, it came to me recently as I was haphazardly trying to e-mail my work colleague about something extremely important. Swiping through colorful tabs with flashy icons is neither enjoyable nor particularly useful. Legacy, “non-smart” mobile phones were simple devices for calling and writing text messages. Current inventions on the phone market are everything – timetable schedulers, spreadsheets, TVs, gaming consoles, etc. However, they do neither of those things well compared to full-blown equivalents. In addition, the battery often lasts a meager 2 days, opening a new economical niche for cumbersome add-on power-bank batteries. Again, solving nonexistent problems and inventing a plethora of new ones. Below, a bullet-point rundown of everything that drives my gears about the so-called “smart” phones. Yes, it’s a rant, so prepare your ears for loads of rubbish and turd!

  1. Overall design – mobile phones are getting bigger and bigger, while laptops smaller and smaller. Both directions are equally pointless. Doing anything on a 10″ notebook is sheer pain on the eyes, and the newest smartphones just don’t fit into a regular trouser pocket anymore. Even when they do, I look like some sort of a mechanic, always with a toolbox in his jeans. Really smooth! Moreover, for some reason smartphone designers decided it’s much easier to type on a screen than on a regular keypad. Interesting, really. I wonder whether they did a proper survey prior. None of my colleagues think it’s more convenient now. Oh, maybe I should be carrying a stylus in addition?
  2. The GUI – as mentioned earlier, old mobile phones had a simple, non-cluttered interface that would show only the most important features. Furthermore, each of those features was really just a click away. Menus were organized in a clear and concise manner as well. Smartphones seem to adhere to the “all you need to do is just swipe!” philosophy. That’s great, but when you want to find a specific feature pronto, hectic swiping will get you nowhere. How useful is that, really? Also, the colors… Whole books could be written about this.
  3. The software – nowadays most mobile phones are powered by Android (or Windows Mobile or iOS). That’s a nice unification in a world full of incompatible proprietary systems of the past. However, the vendor lock-in and bloat is considerably worse than even on Windows. By default way too many useless options are on, causing the phone to quickly eat away on the battery. Disabling features is a no-go, unfortunately. For instance, if we don’t want Google to track us, we also lose the ability to record our location in actually useful apps. Obviously, Google needs to know where we are at a given moment, because only then can it offer us highly relevant and convenient services (sarcasm). Well, if we don’t want them, we might as well just stop using smartphones altogether. That’s how it works nowadays. Finally, apps from the Google Store often require access to information they should not need in the first place. Case in point, why would an offline game need my phone book?

Obviously, there are other things wrong with smartphones, though one would have to write a book to cover all of them. Thankfully, there is a bit of a resurgence right now. I’m not the only one tired of being chained by a company due to a passing fad. Many stores and retailers offer legacy phones for geezers just like me. Also, they’re often dirt cheap, new (pulled from a warehouse) and the battery lasts a whopping week. Can’t say “no” to that!

Debian vs FreeBSD?

After great, though slightly lacking experience with FreeBSD on the desktop, I decided to look for the “next best thing” in Linux Land. In the end I chose Debian, and for good reasons, I think. There is so much that Debian and FreeBSD have in common that my observations might be useful to anyone considering switching between the two.

debian_freebsd.png

First, shortly on the dissimilarities between Linux and the classic Unices, such as FreeBSD, OpenBSD, NetBSD, Solaris and others. The main contesting point is the definition of the base system. The original Unix paradigm calls for tight integration between the kernel and core tool facilities. After all, the kernel means nothing without the userland interfaces that turn cryptic system calls into actual functionalities. Therefore, BSD systems are tightly developed as a whole (kernel + core userland). Linux was historically only the kernel, initially written by Linus Torvalds. The userland (often of GNU origin) was written later. However, while the core tool set is developed by different project teams, each GNU/Linux (GNU userland + Linux kernel) distribution defines some concept of a base system. Therefore, the Unix vs Linux differences are more historical from today’s perspective. An interesting essay by Eric S. Raymond (“The Cathedral and the Bazaar”) elaborates on the top-down (Unix) and bottom-up (Linux) approaches to software development and maintenance in regards to the base system. Below, a brief “compare and contrast” for the sake of completeness:

  • File systems – UFS, ZFS (FreeBSD) vs ext4, xfs, btrfs, etc. (Debian); this does not cover file systems compatible with both Unix-like OS’ (ntfs, fat*, etc.)
  • Init systems – BSD-style init scripts (FreeBSD) vs systemd (Debian) or sysVinit (Devuan)
  • Package management – ports and binary packages (FreeBSD) vs binary packages and source tree used for development (Debian)
  • Sound systems – modified OSS (FreeBSD) vs ALSA and/or PulseAudio (Debian)
  • Hard drive naming –  adaXsYN or adaXpY for SATA and PATA drives, daXsY for USB drives (FreeBSD) vs sdNX for SATA or USB drives and hdNX for PATA drives (Debian) where X, Y are integers and N is a character
  • Releases – CURRENT, STABLE, RELEASE (FreeBSD) vs Unstable, Testing, Stable (Debian)
  • Containers and virtualization – jails and bhyve (FreeBSD) vs LXC, KVM, etc. (Debian)
  • Other differences I did not mention

Important to note, Debian features listed above are common to most GNU/Linux operating systems. For instance, KVM is a Red Hat invention. Also, the differences between FreeBSD and GNU/Linux have blurred over the years. For instance, FreeBSD offers a lot of GNU tools as part of the Ports Tree, while ZFS and some useful BSD commands were ported to GNU/Linux. Can one then be considered better than the other?

In the end, it all boils down to specific use cases, I believe. Although both Debian and FreeBSD target servers, their strong points are substantially different. FreeBSD relies heavily on data protection and consistency (ZFS), but also slim virtualization (bhyve) and process isolation (jails). If those features are important to us and clearly they should be if we are running a multitude of network-facing services, FreeBSD is clearly the better choice. However, if we want a more general-purpose operating system that is consistent across multiple platforms (mini-computers, servers, workstations, desktops, etc.), Debian would be more suitable. The edge that the bazaar/Lego Linux design has is that one can tailor the operating system to specific needs without the need to use different Unix kernels. Furthermore, hardware and tech support for Linux-based operating systems are clearly more prevalent. It’s down to the availability of resources, though it is rather important to mention that a good server platform can potentially make a reliable and secure operating system for home use as well. Something worth remembering!

FreeBSD as a Desktop OS?

After long hours of experimenting with various GNU/Linux distributions, I decided to return to the place I truly belong – FreeBSD. Whenever I feel tired of all of the inconsistencies in other operating systems, I go back to FreeBSD, as I know it will not let me down. It’s stable, reliable and secure thanks to its Unix heritage. I especially like the fact that whatever I throw at FreeBSD, it never ceases to amaze me. Recently, I managed to compile pyMOL via Clang and get it to run on a non-Linux platform. Apparently, the fixes suggested by me were introduced and pyMOL compiled cleanly. I was simply overjoyed!

Of course, what for me sounds great, might not be so for the average Joe who just wants a stable platform, a tool to do his/her work. To be frank, for that there is PC-BSD (now TrueOS). However, if you’re not daunted by the likes of Arch Linux or Debian and you don’t mind spending some extra time on the initial setup, hear my story! FreeBSD might just be the right OS for you.

freebsd_xfce

First, we have to install the operating system. The ncurses menu of “bsdinstall” might look ugly and off-putting, though it serves its purpose well. One doesn’t even have to manually partition the drives, though I would honestly recommend doing so. Especially, that the two filesystems offered by FreeBSD, UFS or ZFS, harbor features fitting slightly different scenarios. UFS is light and quite reliable, though it doesn’t offer the safe-guarding capabilities of ZFS. I recently started using ZFS as the go-to filesystem for data storage even on GNU/Linux. Although it was originally developed by Sun Microsystems for their SUN platform, FreeBSD can be fully proud of it. It has no equals on servers (except for DragonflyBSD’s HAMMER perhaps).

Next comes package management, which is similarly trivial. “pkg” is the FreeBSD equivalent of Fedora’s “dnf” and Debian/Ubuntu’s “apt”. However, “pkg” is a new kid on the block. In former times one would rely entirely on the Ports Tree to “make” all of the programs from source code. Later, an ncurses menu was added so that each port could be configured for selected features. Although building programs from scratch can be considered fun for only some users, it is important to highlight that the Ports Tree was one of the first distribution paradigms for Unix-like operating systems.

FreeBSD offers the same selection of desktop environments as most GNU/Linux distros and some of them don’t even require in-depth configuration. While a big fan of Openbox, I decided to go with something more streamlined for this analysis, for instance XFCE4. The whole environment can be installed or built from the xfce4 meta-port. In addition, polkit is already configured so that the whiskermenu can be used without setbacks. That being said, FreeBSD does not rely on either dbus or HAL by default so these options have to be enabled in /etc/rc.conf. Once that’s taken care of, the logout, suspend and hibernate options work.

Other than that, it’s rather smooth sailing. On a fairly standard, off-the-shelf ASUS ultrabook almost everything works. Realtek, Atheros, Ralink and Intel wireless chips are rather well supported, thanks to the joint efforts of the BSD community (especially OpenBSD and DragonflyBSD programmers). Thereby, PCI wifi cards or USB dongles are fine. Surprisingly, some work more efficiently than on GNU/Linux. The current limitations I found are the lack of Steam support (though that’s in progress so there IS hope), no fully functional native video chat application and minor issues with non-native filesystems. Currently, ext4, ntfs, exfat and a couple of other filesystems are supported, though only as FUSE modules.

As I mentioned in one of my former entries, FreeBSD has come a long way within the last years and many desktop features are now available. The definite advantage over other operating systems in my opinion is that the desktop features do not taint the original server designation of FreeBSD. They’re more like helpful add-ons to an already great platform. Once the remaining limitations (Steam, video chatting, etc.) are ironed out, FreeBSD will shine as a real alternative to Windows, MacOS X or GNU/Linux.

On System Complexity

I appreciate how one can often draw a parallel between life sciences and computer sciences. For instance, complexity has similar features in both fields. Although many aspects like the transition from aquatic to terrestrial life are still largely disputed, it is reasonable to believe that complexity is born out of a necessity to adapt to environmental changes or novel needs. This concept can be translated to technological development quite smoothly. Let us consider evolution of telecommunication devices as an example. In the past people were pleased to be able to communicate with fellow humans without the need for letters, which often took weeks or months to be delivered (telegraphs). With time expectations grew, however. Nowadays, it is more or less a norm to not only call and text, but also browse the Web through mobile devices. Though bold, it is fair to claim that the drivers of progress/evolution were in this case the growing needs of the elusive end-user.

Technical savvy is considered a blessing by many. It’s like a catalyst or facilitator of ideas. It’s also a curse, though, because it creates a rift between the ones who can (makers) and the ones who depend (users) on the makers for their prosperity. A quasi-feudal system is formed, linking both parties together. The makers may (if personal ethics suggest) aid users, as they have both the power and moral obligation to do so. This in turn drives progress, which would otherwise be stunted, because makers often do not require elaborate tools to express themselves (assumption!). Alas, with growing needs, inherently grows the complexity of created tools.

It is important to note that the user is a bit of a decisive factor. The system should be complex enough to satisfy the needs of the user deftly, though also simple enough to allow easy maintenance on the side of the makers. A certain equilibrium needs to be reached. In a perfect scenario both parties are content, because the makers can do something good for the society and express themselves in more elaborate ways, while the users live better lives thanks to the technological development sustained by the makers.

Moving on to operating systems, the “complex enough” is usually minimal and many GNU/Linux distributions are able to cover it. What the users expect nowadays is the following:

  • an ability to do to a “test run” of the operating system without installing it; after all, the installation might fail and no one wants to lose their data
  • easy means of installing the operating system, without the need to define complex parameters like hard drive partitioning or file system types
  • out-of-the-box support for internal hardware like graphics cards, wireless adapters, auxiliary keyboard keys, etc. 
  • a reasonable selection of software for daily and specialized needs, clearly defined and documented with optional “best of” categories 
  • straightforward use of extra peripherals like printers, USB drives, headphones, etc.
  • clear, accessible and easy to learn interface(s)

Unfortunately, the same GNU/Linux distributions then go out of their way to tip the balance and make the system not “simple enough” to be reliably maintained. For instance, does every single main distribution require official support for all of the desktop environments? What for? That doesn’t really help the user if he/she is left with too much choice and suddenly has to decide which desktop environment is “better”. Do all of the desktop environments provide the same complete array of functionalities? In terms of “too much complexity” this is not the only problem, of course! I think there are some Unix-like operating systems (including the BSDs here, too) which do better than others in terms of satisfying the expectations of users:

  • Linux Mint caters to the needs of an average user perfectly. All of the above requirements are fulfilled and the selection of officially supported desktop environments is so that the user should not get confused. In addition, they’re similar in their looks and functionalities.
  • Fedora Linux also does a great job by offering a very streamlined and appealing working environment. It’s geared more towards software developers, though even regular users should find Fedora attractive.
  • Arch Linux (and per extension Manjaro Linux) and FreeBSD (per extension TrueOS/PC-BSD also) do NOT cater to the average user, but offer many possibilities and a good initial setup. Building a full-blown, user-friendly system is a matter of minutes.
  • Debian was always good with the out-of-the-box experience and this has not changed since. Granted, the installer has to be prompted to automagically produce a GNOME3-based system.

Ubuntu and its derivatives didn’t make it to the list, because they often break in unpredictable ways, causing headaches even to more technically-inclined people. The lack of consistency between Ubuntu flavors and general over-engineering often prove troublesome. Well, at least to me.

To sum up (and for the TL:DR folk), complexity is an inherent feature of both biology (evolution) and computer sciences. When building operating systems one should remember that the balance between “complex enough to be easily usable” and “simple enough to be easy to maintain” needs to be kept perfectly. Otherwise, we get instabilities, broken packages, lost data and other horrible scenarios…