--- /dev/null
+---
+postid: '04e'
+title: On system reliability, or, a top-down approach to (dispel the myth of) "software engineering"
+date: August 18, 2016
+author: Lucian Mogoșanu
+tags: tech
+---
+
+After establishing that "software engineering" can only be considered an
+honest engineering discipline through the practice of
+[making software suck less][software-engineering-ii], the next logical
+step is figuring out how to do that.
+
+Software engineering methodologies are dime a dozen, and we might get to
+them sometime later, but for now let us start from the system-level
+view[^1].
+
+As a tradition[^2] software engineers build their (general or
+narrow-purpose) systems using the "commodity component-based"
+philosophy, i.e. instead of rewriting software, they aim to reuse it as
+much as possible. This approach may look sensible on the surface, except
+when it isn't. In fact the mantra of "modularity" is nowadays flagrantly
+overused in the field, as engineers either ignore or simply do not know
+the trade-offs involved. The same is the case with software's so-called
+"flexibility", which supposedly makes software cheaper to build than
+hardware.
+
+In this essay I will attempt to deconstruct this principle and its
+supposedly magical properties by enumerating a set of trade-offs (or
+problems, if you wish to call them such) that are particular to the
+approach. The first two trade-offs stem from purely human issues.
+
+**Trade-off 1: standards**. Engineers generally use standards to guide
+ the building of their systems. In software this is rarely the
+ case[^3], with many so-called "engineers" not even bothering to
+ specify their software, let alone standardize it. Thus very often a
+ single implementation of a program becomes the de facto standard, even
+ in the free and open-source software world. I'm not even touching
+ closed-source software with a ten foot pole here, that can of worms is
+ too rotten.
+
+**Trade-off 2: Abelson's saying**. Good software is in some sense not
+ that different from good literature, e.g. well-known scientific
+ papers. The latter are often partially or completely rewritten by
+ multiple people, sometimes (more rarely) using multiple languages,
+ thus giving the writer as well as the public a better idea of what the
+ work says and does. On the other hand single designs and
+ implementations are harbingers of mono-cultures, which lead to the
+ narrowing of ideas[^4] in the field. Of course, sometimes new ideas
+ are worse than no ideas.
+
+The next two trade-offs are pure design considerations.
+
+**Trade-off 3: dependencies**. The existence of granular components
+ gives rise to (sometimes circular) dependencies, e.g. component D
+ needs component C which relies on A and B to work. The number of
+ implicit relations in dependency trees (or graphs) tend to grow
+ exponentially, which makes solving dependencies a (generally) hard
+ problem[^5].
+
+**Trade-off 4: component versioning**. Components' interfaces change in
+ time, which is especially problematic in the case of components with
+ lax (or no) interface specification. This may give rise to situations
+ such as (but not limited to) that in which D needs C needs A1 and B,
+ while E needs A2 to work, where A1 and A2 are different versions of
+ A. It may be that A1 and A2 cannot coexist in the system -- this is an
+ addendum to trade-off 3, and it often makes engineering "commodity
+ component-based" systems intractable, especially when so-called
+ "software upgrades" are involved.
+
+Finally, the fifth trade-off is of a mixed nature:
+
+**Trade-off 5: fits-in-head**. Systems with a large number of components
+ usually do not "fit in head", i.e. they are not fully understood by
+ the engineers involved in developing it. This is another generally
+ hard problem, the chief idea being that the bigger the number of
+ components, the bigger is the number of unknowns. With this the
+ probability of non-deterministic behaviour in the system grows and
+ with it the system's overall fragility.
+
+These trade-offs are far from being the only issues of the "commodity
+component-based" approach and are not necessarily inherent to it. For
+example the first two trade-offs are observable in other approaches too,
+but bear more weight in the philosophical framework of code reuse.
+
+As things usually go in any honest engineering discipline, one cannot
+expect to find a magical solution to all these trade-offs, otherwise
+they would be something other than trade-offs -- and the discipline
+would yet again be something other than engineering. However, we can
+derive a set of general principles to be used as rules of thumb, and
+broken when absolutely necessary, as expected of engineering. These
+principles can be formulated as follows:
+
+**Principle 1: clarity of purpose**. Systems must be ideally designed
+ with a single purpose in mind (or, to solve a single problem) and as a
+ consequence must be as small as possible. The smaller its "number of
+ purposes", the more resilient the system will be.
+
+**Principle 2: integrated structure**. System designs must be
+ monolithic. This does not preclude the use of components, as long as
+ said components are fully integrated into the system[^6].
+
+**Principle 3: convergence**. "Software upgrades" are to be
+ avoided. Ideally the work will converge to a largely stable code
+ base. Ading features or changing the system's scope should ideally
+ result in a complete redesign and rewrite.
+
+This list of rules of thumb is also necessarily incomplete, but we will
+keep it short for the sake of enumerating a few principles rather than
+rigid rules. More importantly, they may be taken as the first steps
+toward an honest, sane, enthusiasm-free, minimal-suck approach to
+software engineering.
+
+[^1]: "Apps" are unimportant to the engineer, as "apps" usually suck by
+ default. It is obvious that "apps" start from a (usually
+ well-defined) purpose and evolve following
+ [Philip Greenspun's tenth rule][tenth-rule], turning into monstrous
+ gigantic pieces of crap that quite often *defeat* their original
+ purpose.
+
+ In other words, kids enthusiastically "code" "apps". Engineers
+ design systems.
+
+[^2]: As what is now a tradition, not as what was initially a
+ tradition. Thinkers such as Knuth, [Dijkstra][dijkstra], etc. are
+ very often utterly misunderstood.
+
+[^3]: It used to be different with POSIX, ISO C, ANSI Common Lisp, etc.,
+ but the bureaucrats simply couldn't keep up with the software
+ enthusiasts. C'est la vie, as they say wherever they say that.
+
+[^4]: This was for example discussed in the essay on
+ [operating system design][os-design]. POSIX being a standard was in
+ itself a trade-off, as it ended up being used by most
+ production-grade systems, but in the process it effectively killed
+ operating systems research. Also see Pike,
+ [Systems Software Research is Irrelevant][systems-software].
+
+[^5]: Which in turn leads to so-called "dependency hells". See Haskell's
+ Cabal dependency hell for more details. Moreover, the current
+ solution, the Haskell Tool Stack, is not an elegant one to say the
+ least; more like a palliative, I would say.
+
+[^6]: The Linux kernel is a good example of a system* that is monolithic
+ yet modular -- monolithic in the sense that every piece of code may
+ (roughly) access any data object in the kernel; modular in the sense
+ that functionality is (roughly) split across compilation units.
+
+ These are not the only two ways to look at Linux as
+ modular/monolithic -- for example run-time device probing makes the
+ kernel modular**, while the system designer's ability to statically
+ choose what components are included, and enforce that state of
+ affairs at run-time, makes it monolithic --, but they nevertheless
+ constitute two possible ways.
+
+ \-\-\-
+ * Although not a system by itself.
+ ** And, as by-product, portable.
+
+[software-engineering-ii]: /posts/y02/049-the-myth-of-software-engineering-ii.html
+[tenth-rule]: http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming
+[dijkstra]: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html
+[os-design]: /posts/y01/03a-the-linguistic-barrier-of-os-design.html
+[systems-software]: http://herpolhode.com/rob/utah2000.pdf
--- /dev/null
+---
+postid: '04f'
+title: Freedom is Slavery, or how and why everything costs
+excerpt: On the pitfalls of doublespoken equality.
+date: August 22, 2016
+author: Lucian Mogoșanu
+tags: asphalt
+---
+
+Let's begin with a selective [quote from Moldbug][moldbug]:
+
+> What is callous altruism? Altruism itself is a piece of 20th-century
+> jargon. We could contrast it with the original word for the same
+> thing, obviously too Christian to prosper in our age: charity. When
+> we say charity, of course, we think of empathic altruism.
+>
+> When we think of charity, we think not just of helping others - but of
+> helping others whom we know and love, for whom we feel a genuine,
+> unforged emotional connection. For whom we feel, in a word, empathy.
+> Understandably, these people tend to be those who are socially close
+> to us. If not people we already know, they are people we would easily
+> befriend if we met them.
+>
+> Dickens, no stranger to genuine empathy, had a term for nonempathic
+> altruism. He called it telescopic philanthropy. Who is Peter Singer?
+> Mrs. Jellyby, with tenure.
+>
+> [...]
+>
+> Another source of venal satisfaction is that when you help people, or
+> appear to help them, you become a patron. You gain ownership over
+> them. When you help overthrow the dictator of Egypt, for example, you
+> become in a sense the new government of Egypt. The old dictator was a
+> strongman - the new dictator is a weakman, because he owes his job to
+> someone else. That someone is you - the collective you, but you
+> nonetheless. If you decide you don't like your weakman, it's easy to
+> find another weakman.
+>
+> The fear that someone, somewhere, is exercising power over someone
+> else, is one of the most basic cues of the callous-altruist mentality.
+> Let me kill the master and free the slave. Out of altruism! Not
+> sadism or ambition, of course. My hands are pure.
+>
+> But slavery is simply dependence, and the default state of the newly
+> "freed" slave is to be dependent on his new master - you, because you
+> killed the old master. So your sadism itch is scratched, because you
+> get to kill; and your ambition itch is scratched, because you become a
+> slavemaster.
+
+The snippets above discuss Freedom is Slavery in the context of Western
+politics, i.e. whatever meddling shit Americans and their allies[^1]
+have been undertaking in Iraq, Egypt, Syria, etc. in the last few
+decades or so. That's all nice and good.
+
+What Moldbug misses is that this aspect of people wilfully becoming
+slaves of various stuff, most of all to their own stupidity, is becoming
+entrenched in today's Western culture. Orwell might have gotten it
+right, but then again, he might have meant something else completely, so
+let's discuss that too.
+
+So what does Freedom is Slavery mean? According to the definition of
+doublethink, the slogan is to be interpreted as freedom -- as
+interpreted by the average citizen -- not being actual freedom, but the
+exact opposite, which is... slavery, right? Well, right, only not
+quite. Orwell might have described it this way for the sake of
+satirizing some aspects of Soviet communism, but I'm not entirely sure
+that freedom means what he thought it does or that slavery is even a
+conceptual opposite. There's been a lot of discussion going on about the
+meaning of freedom for more than a century now, so I'm not going to go
+into the depths of all that; but I do want to make sure we're not making
+basic mistakes such as confusing freedom and right[^2].
+
+Simply put, freedom can be considered the absence of constraints, as per
+the definition in Merriam-Webster. This may in some sense be equivalent
+to being freed of physical shackles, e.g. when being freed from prison,
+but *not necessarily*[^3], and this "not necessarily" is what's
+important to us. Freedom is a state of affairs as much as it is a state
+of mind[^4] and one cannot go without the other.
+
+Additionally, freedom, or at least a doublespoken version of it, also
+denotes giving things away without asking for anything in return,
+i.e. "for free", as gratuity, etc. This meaning is also of interest to
+us, since it is one of the biggest pitfalls used to create slavery in
+nowadays' Western society.
+
+Slavery on the other hand is in its old Aritstotelian sense not
+necessarily the absence of freedom as it is the presence of
+dependence. That is, despite what the socialist pigs might have the
+naïve believe, the condition of being a slave necessarily flows not only
+from the freedom of becoming one, but also from the slave's acceptance
+as well as the owner's will. So Moldbug's argument holds because he
+knows that freeing the average derp is not in and of itself enough, as
+the derp in question will have absolutely no idea what to do with said
+freedom and will thus fall back to his natural slave-state.
+
+In other words, there is no such thing as "giving [someone] freedom",
+which follows directly from freedom being a state of mind.
+
+So, putting the above together, we may say that slavery is, possibly
+among other things, the freedom of being subject to another. Assuming
+even that one is born a slave, then slavery is the freedom to not do
+anything in order to not be a slave, which is what puts some sort of
+approximate equivalence sign between this and the welfare state.
+
+So, freedom, or rather free-dom -- that is, things that are for free do
+bear a cost, like any other thing in the observable physical
+Universe. The cost is that of creating a relationship in which the taker
+becomes dependent on the giver-away, which is also why the first dose is
+always free. In other words, Freedom is Slavery. There you go.
+
+Now that we're here, let us give a few examples of Freedom is Slavery in
+the so-called modern Western culture.
+
+Example the first, and my
+favourite. [Da muthafuckin' cloud][cloud-software]. No, all that stuff
+isn't for free. The trick is for you to put all your stuff on their
+servers instead of buying (cheap) storage for yourself, and then for
+them to fuck you in the ass however they want with
+"[I have altered the deal][deal-worse]" moments. And by the time you
+figure it out, switching to alternatives is much too costly to even be
+considered.
+
+Example the second, and my other favourite. Software Freedom. While
+monsieur Stallman was no nitwit, he was pretty naïve himself by
+believing that people will actually read the code -- spoiler: no,
+[they will not][software-engineering-ii]. Using software will almost
+always make one dependent on it, whether in terms of how the data is
+represented or what the algorithm does, etc. Now, while using
+proprietary software will make you dependent on companies such as
+Microsoft, Google or Apple, using free software makes you dependent on
+the nerd who's writing the goddamn code -- *unless* you read the code
+and learn to maintain it yourself, and this is quite a big
+unless. That's why licenses that provide the software "as-is" are the
+most honest of them all; they just give you the chance to fuck yourself
+in the ass.
+
+Example the third. Fiat money. Classical example of a corporation
+offering you a good deal in social security if you let it print however
+much money it wants. Except it's a really bad deal, in that you're not
+gonna see any of those money.
+
+Example the fourth, fifth, up to the nth. Basically any contract or
+agreement in which you have no say other than "I Accept"[^5].
+
+And that about sums up Freedom is Slavery.
+
+[^1]: Their enemies too, because why not.
+
+[^2]: Just to get that out of the way: you have a freedom when you can
+ do stuff, while you have a right when some controlling entity such
+ as the State allows you to do stuff. So for example [We][we] tells
+ the story of a place where people have no freedoms, but they do have
+ certain rights, such as the right to eat, which incidentally is also
+ an obligation established in great detail, e.g. by the amount of
+ times one must chew their food before swallowing it.
+
+ So in the sense of hierarchy of power, which is exactly what Moldbug
+ discusses in his essay and what we are discussing in this one,
+ freedom is the set of things that fall out of the state's
+ control. This is why for example you are not granted the right to
+ death, but you certainly have the freedom to do so, and nobody but
+ your God can and may punish you for it.
+
+[^3]: Just ask Brooks Hatlen:
+
+ > **Dufresne**: I just don't understand what happened in there.
+ >
+ > **Heywood**: Old man's crazy as a rat in a tin shithouse, is what.
+ >
+ > **Red**: Oh Heywood, that's enough out of you!
+ >
+ > **Ernie**: I heard he had you shittin' in your pants!
+ >
+ > **Heywood**: Fuck you!
+ >
+ > **Red**: Would you knock it off? Brooks ain't no bug. He's
+ > just... just institutionalized.
+ >
+ > **Heywood**: Institutionalized, my ass.
+ >
+ > **Red**: The man's been in here fifty years, Heywood. Fifty years!
+ > This is all he knows. In here, he's an important man. He's an
+ > educated man. Outside, he's nothin'! Just a used up con with
+ > arthritis in both hands.
+
+[^4]: Which is why in nature there is no excuse for stupidity, and why
+ ultimately [the former abhors equality][slither-io].
+
+[^5]: See for example Popescu's
+ [Here's what they don't tell you when they bring you those papers to sign][trilema].
+
+[moldbug]: http://unqualified-reservations.blogspot.ro/2013/09/technology-communism-and-brown-scare.html
+[we]: /posts/y02/04b-we.html
+[slither-io]: /posts/y02/048-slither-io-unfairness.html
+[cloud-software]: /posts/y02/041-cloud-software-is-unreliable-ii.html
+[deal-worse]: https://www.youtube.com/watch?v=WpE_xMRiCLE
+[software-engineering-ii]: /posts/y02/049-the-myth-of-software-engineering-ii.html
+[trilema]: http://trilema.com/2015/heres-what-they-dont-tell-you-when-they-bring-you-those-papers-to-sign/
projects / thetarpit.git / commitdiff