Hacker Dilemmas

by aestetix

To remain a hacker in today's polarized world is increasingly difficult and leads to serious philosophical dilemmas.

We are not talking about politics, but attitudes towards technology.  To illustrate this, we will review a few of these dilemmas: old versus new, sharing of modified code, and ownership of networked systems.

In the "old versus new" debate, we see novelty battling nostalgia.  Every new gadget that comes out offers - at least in theory - cool features with which techies want to play.  But once the glow of newness dies away, we are left with a blunt question: what makes this device better than the old one?  At a certain point, there is a law of diminishing returns.

For example, while 4K video resolution is clearly an enhanced experience over 720p, does 8K offer the same improvement over 4K?  And, conversely, how many times has a website (like Reddit) put out a "new" design that destroyed usability?

But sometimes new is demonstrably better.

Take newer software versions: while there are routine updates like security fixes, major updates - such as moving from single- to multi-core architecture - can offer exponential improvements.  Just compare screenshots of Windows 1.0 to Windows 10: the difference between older and newer versions is simply staggering.  Of course, we also get software like Node.js, which over time seems to have gotten worse and more bloated.  In fact, a common complaint about modern software is the bloat that makes it run slowly on faster hardware, in contrast to retro software that often had to be tweaked in very creative ways to meet hardware limitations.  So is new or old better?  The answer is not so clear cut.

For our next dilemma, we turn to code sharing.  With the advent of version control systems, like Git, and websites to share projects (such as GitHub) comes two developments: the ability and encouragement to share software that is "in progress," and the push to likewise share any changes we've made via pull request or repo forking.

When we talk with artists, we learn that sharing "works in progress" is very controversial, especially when we are used to only seeing a final product, like a book or a painting.  Similarly, some open-source developers will quash their git commit history when they put out a new version.

There's also the question of whether the art created is inspired by the artist, or inspired by external pressures that the artist feels once the "in progress" art is shared.  Conversely, many argue that there is no such thing as a "finished" project, and when a code repository is transparent down to the level of individual code commits, it can create an inviting atmosphere, welcoming contributions from anyone in the world.  One could even argue that such radical transparency helps sidestep potential biases of the original maintainer of the codebase.

In the case of changes to code, there's an additional issue of ownership.

When we take some code and modify it, licensing notwithstanding, or if we make some big improvement to it or manage to port it to an otherwise unavailable computer system, do we have an obligation to share this contribution with others?  This boils down to whether code sharing is a zero-sum game: that is, when we add something new into code that is local on our computer, does not sharing it somehow take something away from others who are using unmodified code on their own computers?  One could argue that it does, because someone else wrote the initial code base that we modified.  However, if we follow this reasoning to its logical conclusion, then if we fix a security hole in the code and do not share it, and someone else using the unmodified codebase gets hacked, we would be at fault.  Although without the original code base, neither the security hole nor our fix would even exist.

This begs another question: if we choose not to share our code, what impact does this have on the community in general?  Or, put another way, which has primacy of importance, our personal agency and privacy, or the good of the community?  There is also a deep can of worms there regarding private property that is beyond our current scope, but it's important to acknowledge that it's there.  So in the end, who really should "own" the code?  There is no obvious answer.

And finally, we visit the age old debate of systems ownership, and the benefits therefrom.

Let us take the idea of a networked system of computers, and look at it from different viewpoints.  If we take the "my computer is my castle" approach, then there should be no ownership change for a computer, on or off the network - it belongs to us.  The moment a packet has left the network cable and entered the memory or disk of the computer, it is owned by the destination IP, rather than the source IP.

The software on our system is ours: we own it, and any interaction it has or makes with other computers on the network is determined by us.  Likewise, if we have a hardware problem, we should be able to fix it on our own.  This sentiment is the hallmark of the "right to repair" movement, and views the corporate nature of things like software activation and "take it to the Apple Store" with suspicion.

On the other hand, we could also view our computer as one member of a networked community of systems, with mutual responsibilities to each other.  If our computer gets hacked by a virus, who is to say that that virus won't spread to other computers as well?  In this approach, we have an obligation to keep our computers updated with the latest security patches, not just for our own safety, but for the good of the others as well.  We can take this a step further and, assuming we sometimes have idle time on our systems, donate resources like CPU cycles to a good cause like SETI@home, protein folding, COVID-19 vaccine research, etc.

But with all of this there is a large downside.

By allowing a third-party to automatically access and send updates to our computers, we are also at risk from their mandates.  Let's say Microsoft decides they do not want Windows users to be able to use Google Chrome - what's to stop them from using their automated updates permission to also uninstall Chrome and set a registry key preventing us from running it?  Or worse, why not simply out-source the functionalities found in applications to some "as a service" website, where our computer becomes nothing but a dumb terminal without network access and approval to access the centralized system?  A third time, we discover why this "choice" is a dilemma.

The nature of a dilemma is such that a given situation has multiple views on the "correct approach," none of which are "correct,' and each, if taken to the logical extreme, become tyranny.  When there is no good answer, we must revisit our own conception of first principles, and decide what for each of us is the best balance.

A parting rule of thumb: when something is controversial, it means that there are no easy answers, and so when trying to pick a path, it is important to consider all viewpoints.