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.


2 thoughts on “On Deprecating Software

  1. software works like evolution– a niche that exists but isnt filled will eventually have something in it, and the web of niches is constantly changing– but not as much as people say.

    corporate software works differently, but not really– a corporate beast is mammoth and needs to find new food sources constantly to survive, or it falls over. rather than adapt to its environment, corporate software constantly tries to adapt the whole ecosystem to itself. other than that, its the same process– just more disruptive.

    but for non-giant-corporations and individuals, its a matter of small adaptations over time (except for fanboys who try to emulate the “adapt the ecosystem” model.) and so whenever people talk about “changing paradigms,” theyre often talking about abandoning things that work for things that are the latest corporate effort to change the whole ecosystem.

    the thing is, the benefits are not always to the ecosystem– theyre to the one species trying to make everything else fit itself. fanboys are drawn to power and prestige, and jump on the back of this mammoth thing, hoping to ride it to victory. they will ultimately be thrown off, but thats the long term.

    for the rest of us, evolution isnt a path “forward” but a path “into” niches. and the niches come and go, but have so much in common, that if youre the type to throw away everything from “before” and chase everything “new,” youre just trying to hitch a ride to giant beast. but the thing about evolution is, so much of it looks the same. you see the same patterns again and again– there are different kinds of fur, but if someone comes along and says “look, fur is the OLD WAY of staying warm, NOW we eat forests and breath fire” all of that is a fallacy– a false appeal to modernity. perhaps eating an entire forest and breathing fire will keep you warm, but theres nothing wrong with fur. youll be seeing fur for the next 50,000 years.

    on a smaller scale, this is what software is like when its not all corporate. when it is, you will see people constantly being dragged from “new” thing to “new” thing, because thats the only way for corporations to survive– drag everyone else along.

    to a large degree, free software can do both– it can chase the mammoth for rides, and fill niches that are too small for the mammoth to reach. but when you have too many corporate fanboys, they want to do everything like corporate– out with the old, in with the new! rinse and repeat. its very inefficient, and people that like efficiency and reliability will always rebel.

    without free software, they have no recourse. with free software, they can always take that piece of infrastructure they were getting a free ride on (udev) keep it working with in any niche they like (eudev) and ultimately create new adapted technologies that are designed for reliability, not trying to change the entire ecosystem (vdev.)

    free software will continue to change (sometime for better, sometimes for worse) because of corporate fanboys that dont understand that evolution isnt a straight line “up” from old to new. and it will continue to adapt and be made as reliable as possible, by people who understand that evolution isnt linear– moving “forwards” is a lot like moving in a big circle, and theres no point in changing everything all the time, just to end up where you started.

    unforunately these days, non-corporate-fanboys are in short supply. but thanks to evolution, there are more tools than ever for a smaller group to build with. that said, we could still lose. the struggle between giant beasts that dont care what they kill off, and the rest of the software world continues. though its a shame fewer people are interested in “the rest of the software world.” monopolies fall too, and they fall a lot harder.

    Liked by 1 person

    • I really like the mammoth metaphor – simply spot on! However, rather than a big circle I think it’s a mountainous landscape or an endless tube with narrow sections.

      What I really love about open-source software is that whatever the corporate world claims, it constitutes the majority of software. It doesn’t matter that the “big bucks” are in proprietary tech. Numbers don’t lie :).

      One of the reasons why I got into learning C. People can claim that it’s an inferior C++ or D, though the truth is that when you need a portable, low-level language, it’s C.

      Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s