On Deprecating Software

In the open-source world software comes and goes much like animal and plant species in the bio world. The reasons are various. Software A was written a long time ago when computers severely lacked in performance. Therefore, it could not adjust to modern programming paradigms easily, and had to be forked and rewritten as software B. Another case – developers were few and at one point they lost interest in software C. Years later someone dug up the project and noticed its many uses. He/she decided to breathe new life into it as software D. The story that everyone talks about nowadays follows an entirely different scenario, though.

Once upon a time, there was a Unix sound system called OSS (Open Sound System). It aligned with the Unix style of device handling and was easy to understand. In fact, it was the first sound system that could be called “advanced”. FreeBSD still relies on a modified version 4 of OSS and it’s perfectly fine for daily use. Then came Linux, based on Unix paradigms, though not Unix itself. In very general terms, it did a lot of things differently and required extra abstraction layers for its sound implementation. OSS was considered cumbersome and too low-level to be worthwhile in the long run. Thus, ALSA (Advanced Linux Sound Architecture) was born. For a long while OSS and ALSA co-existed until OSS was intentionally deprecated. Interestingly, many of the drawbacks of OSS were addressed in OSS v4, making the arguments against it rather moot. However, Linux dominated the open-source world to the point that all OSS-using Unix-based or Unix-like operating systems were marginalized. As a consequence, developers of new sound software primarily targeted ALSA. When I compare it to OSS, there are things it does better and things it does worse. The added abstraction layers theoretically simplify configuration. After all, not everyone needs to know how to address sound I/O on hardware-level. However, due to abstraction it’s more difficult to troubleshoot in cases when by default sound I/O is misconfigured.

Fast forward a few years and some developers now notice that even ALSA is cumbersome and too low level. Due to the rapid expansion of GNU/Linux into the desktop ecosystem, user expectations have changed and various system components have to follow suit as a result. That includes the sound system stack. Lennart Poettering observed that the current solution [ALSA] is flawed and implementing high-level sound features, such as dynamic multi-output setups or mixing is difficult. However, he decided not to (or couldn’t?) fix the underlying problems, but rather build a layer on top of ALSA. Such means of abstraction is likely to add problems, rather than subtract them. On one hand, configuration becomes more intuitive and potentially easier to adjust. On the other hand, the lower-level system (ALSA) still exists and the problems it causes are not addressed, but rather circumvented. Regardless, many projects decided to switch their sound backend from ALSA to the “new cool kid” PulseAudio entirely, for instance Skype, Steam, BlueZ and recently also Firefox.

Curiously enough, replacing ALSA with PulseAudio effectively only streamlines configuration on desktop computers. It’s not a game-changer that magically solves all of the problems attributed to ALSA or OSS, contrary to the claims PulseAudio proponents make. Can OSS or ALSA handle sound output device hot-plugging? Yes. Can volumes be easily adjusted on a per-application basis? Yes. Can multiple applications play sound to the same output? Yes, indeed! Frankly, instead of broken layers on top of broken layers, I would rather see a fix to the underlying components. Still, PulseAudio is here to stay for good and we need to find ways of dealing with it. My favorite is the apulse shim that provides a PulseAudio-like backend for applications and directs all output to ALSA. It’s simple and just works.

The big question I would like to drop, though is whether we should really keep on deprecating software so frivolously? For the majority of cases, both ALSA and OSS can do pretty much the same. Do we then really need something as complex as PulseAudio? Why not a simplified backend so that application developers live happier lives? Food for thought, I believe.

Gentoo vs FreeBSD

I have been running FreeBSD 11-STABLE for some time, though I felt I need to switch to a GNU/Linux environment again. It so happens that we use CentOS 7.2 at work. In addition, FreeBSD is unfortunately not well suited for handling multiple Python versions with unusual libraries. Therefore, I needed something for developers, though not overloaded with fluff like Fedora (yet it would play perfectly with the CentOS environment at work). At this point, I considered either Arch Linux or Gentoo. After running Arch for a short while, I realized I’m a “tweaker” by nature. That’s what let me enjoy the FreeBSD Ports tree so much after all. The minimalism of Arch Linux is great, though tweaking comes with a price of having to locally fork packages and track them with desired features. Therefore, I required something as malleable as FreeBSD in “Linux Land”.

gentoo_freebsd

What might be obvious by now, I chose Gentoo. Thanks to my Bash scripts and a pre-defined kernel .config, it took me merely an evening to get things running on a measly ASUS ultrabook (my current mobile FOSS machine). I then began to realize how much FreeBSD and Gentoo have in common and where they differ. I thought it might be useful to some if I share my observations. Especially, that there is the Gentoo/FreeBSD project for those of us who prefer a more Unix-like kernel, yet don’t want to part with the GNU userland.

First off, the Ports Tree I gently mentioned as my prime fancy earlier. What changed is that I started using ports-mgmt/portmaster on FreeBSD more extensively. In many ways it’s similar to Gentoo’s Portage. The make.conf file for global configurations is present in both Unix-like operating systems as well, though it differs in purpose and syntax obviously. I believe the biggest difference, however is that FreeBSD flags need to be tracked on a per package basis, while Gentoo heavily relies on more centralized settings. Regardless, FreeBSD has a slight advantage by providing pre-built binary packages for most ports, unlike Gentoo. Sometimes building software from source can be annoying, specifically when the builds fail for reasons we cannot control.

Secondly, one can run Gentoo in a FreeBSD way – as a server and/or local distribution system. Portage has built-in software distribution features, while FreeBSD offers ports-mgmt/poudriere for that purpose. Where Gentoo falls short is FreeBSD’s jails, bhyve and outstanding firewall solutions (PF and IPFW). No wonder, though. “True” Unix-like operating systems, namely Solaris and the BSDs had these features integrated early on. GNU/Linux is just now experiencing a renaissance of container technologies and virtualization. Furthermore, ZFS on Linux still has some licensing issues which prevent clean kernel integration. For that reason alone Solaris/OpenIndiana/Illumos or FreeBSD are better picks in terms of extensive data storage.

Thirdly, Gentoo and FreeBSD share some BSD and GNU utilities, though that’s more an aspect of the open-source community, than either of the systems. Let’s face it, FreeBSD belongs to the Unix-like BSD world, while Gentoo is a GNU/Linux distribution. However, it is feasible to reproduce the FreeBSD “feel” in Gentoo to some extent. For instance, we can try to rely on as many BSD tools as possible. Also, GCC can be replaced with Clang for software builds if one so prefers. I am actually eager to test this in a Linux LXC container or a simple chroot environment soon.

Looking at the discussed point again, I’m beginning to wonder whether choosing a GNU/Linux distribution as my primary OS was such a good idea. Probably not, though as in the case of Debian earlier, it’s a matter of use scenarios. Gentoo gives me the flexibility and hardware+software support I need on mobile devices. Also, similarly to FreeBSD, it is extremely “sane” and values stability over Arch’s bleeding edge. I guess I will bear with the long compile times somehow, though on a proper workstation I would much prefer to run any of the BSDs instead.

Enter OpenBSD – part 2!

I feel I have wronged OpenBSD in my earlier entry, while it surely deserves proper attention. My main problem was that it really surprised me with its minimalist approach. However, the more I used the default tools and read the documentation, the more it became clear to me. I especially needed to drop some presumptions I made based on Internet articles addressed to laymen:

  • OpenBSD has nothing to do with FreeBSD except for selected tools and features (rc.conf, PF firewall, Ports Tree design, etc.). Thereby, the two systems are not comparable to each other at all (except for its common heritage in BSD4.4 Lite). In fact, each BSD system is independent, contrary to the “Distribution” in the BSD acronym.
  • OpenBSD has very well defined goals (code correctness, security, stability, etc.), which do not require it to cater to the end-user. Therefore, it is not built with desktop users in mind specifically, though many desktop features are of course available thanks to contributions from members of the community.

Having the above points in mind, I approached OpenBSD as an entirely separate and unique entity. I am glad to say, I was quite happy with what I saw. It’s indeed amazingly documented and understanding it properly is mostly about reading that documentation. Everything needed to run a basic installation is there. The Ports Tree and packages lets the user expand on the already great base. On each operating system I usually install a set of essential tools I need for software development and leisure – vim (with GUI if possible), w3m (for command-line Web browsing), firefox, a file manager (mc, pcmanfm, etc.) and a music player (mplayer, for instance). I’m happy to report that all of those applications are available from the not-so-small OpenBSD repositories. In general, BSDs are not strong on games, though OpenBSD offers a nice selection still. I grabbed OpenTTD and 0ad instantly. Also, since the base contains xenocara, I added Openbox on top of the already provided fvwm, cwm and twm. Openbox is my absolute favorite among the *box window managers and with a small laptop screen, a tiling window manager such as i3 or awesome is not exactly what I would call convenient.

Since then, I’m running OpenBSD as my secondary operating system (FreeBSD being the primary). It’s quite smooth sailing, though I still have a lot to learn regarding setting up network services and rebuilding the kernel. I feel OpenBSD would be more suited for a small, space-limited server than FreeBSD. I didn’t yet have the chance to test it on an ARM device, though I guess there it should also shine.