‘Getting the Job Done’ Dilemmas

A WordPress user, codeinfig, brought my attention to what I was trying to express in my previous blog entry, but somehow failed to name. The patched together arguments I’ve been tossing around recently illustrate a major issue in software design – abstraction vs obstruction. We build abstraction layers to tie together smaller system components (or features) or to provide an easy to use interface for ourselves and others. However, abstraction layers tend to stack ad infinitum, because we all like having our own, right? Unfortunately, handling abstraction layers becomes more and more difficult with each level. Thus, obstruction is born.

I kept asking myself – why do we even need abstraction layers? I personally prefer working on the very core of the operating system, almost bare metal (though I don’t speak binary yet). The BSDs intrinsically allow this, much to my appreciation. The reason is simple – there is barely any need for abstraction layers. Don’t get me wrong, though. I have nothing against abstraction. It’s often useful in preventing hardware or data damage when getting up close and personal with our PCs. No one wants to intentionally fry their graphics (unless it’s a stress test), correct? Abstractions are good as long as their well-documented and transparent enough.

That’s the problem the GNU/Linux ecosystem is facing right now. There is tons of abstractions that are neither well-documented nor transparent. There are tons of obstructions. Proponents say that systemd units are more structured and more clearly written than legacy rc scripts. Yet they somehow generate more problems, bugs and are in general harder to work with for seasoned Unix administrators. Why binary logs? What was wrong with text files? Are we slowly entering the .bat zone of Windows OS? Pulse Audio suffers from similar problems. It started extremely buggy, reached a somewhat stable state…and still doesn’t solve the supposed problems ALSA caused. One can go on and on, there is hardly any point.

Linas Veptas laid it out perfectly in his open letter to Debian and Ubuntu developers. The root cause of the problem are abstractions turned obstructions, spawned by people who think it’s reasonable to search for a needle in a haystack using a huge industry-grade electromagnet. This we already know. The symptoms are more down to earth, though. Linus and many other Unix IT people/admins/greybeards want to keep on using GNU/Linux, but more importantly get the job done. This is impossible, because good is swapped for an utopian view of better, whether the vast GNU/Linux populace wants it or not. When one spends hours on fixing so-called modern inventions, getting things to work and then getting a good night’s sleep is really all that matters. Why do you think the Devuan project was launched? The developers just want to use their favorite GNU/Linux distribution, Debian without the commitment to nonsense.

Alas, the obstruction avalanche has already caught momentum. The reason is mentioned along the lines in an assay by Steve Litt. People are flawed beings and most of us don’t parse incoming information through a sanity-control mechanism. Microsoft and Apple  tell us we need complexity, because everything nowadays is more complex and they can take care of that everything for us. So that we don’t have to worry, of course! In practice obscurity never solved any problems and never will. That’s just the way of things.

2 thoughts on “‘Getting the Job Done’ Dilemmas

  1. thanks for the mention, and love the entry! steve litt hints at motivation being a key factor in whether an abstraction becomes an obstruction. the desire to become a “gatekeeper” is not something i rule out– although like you, i find that there is still quite a lot left when you focus on the more neutral matter of “design philosophy.”

    in other words, too many abstractions gets in the way regardless of motivations. (and i believe you’re right about transparency and documentation, too.)

    in short, i think gatekeeper aspirations will certainly produce unnecessary and opaque abstractions like litt says, but so will shoddy design with benign intentions.

    and the user can only withstand so many of these “helpers” stacked like turtles all the way down, before john/joan q. public starts to blame the computer, the developers, the companies that may or may not be to blame– sometimes it is (still) bill gates fault, and sometimes he is innocent. but cutting through excessive abstractions is the KEY to computer literacy and efficiency– and still so many focus (exclusively) on applications. 😦 in my opinion, that is a sure recipe for a helpless (at best, a frustrated) user. cheers.

    Liked by 1 person

Leave a comment