--- /dev/null
+---
+postid: 05d
+title: Despre Oameni și Melci
+date: March 26, 2017
+author: Lucian Mogoșanu
+tags: video
+---
+
+<p style="text-align: right">
+*"**V**ivre à même l'éternité, c'est vivre au jour le jour."*
+</p>
+<p style="text-align: right">
+***V**ă mulțumim pentru realizările de azi!
+**V**ă așteptăm mâine cu forțe noi, cu inițiative noi!*
+</p>
+
+Despre Oameni și Melci[^1] is a practical illustration of our previous
+discussion [on the unfairness of nature][slither], taking place in the
+setting of early post-communist Romania. Which sets the premise for an
+interesting story.
+
+You see, if you're a Romanian, then you should understand that,
+regardless of what those other socialists would have you believe, the
+2017 nationalist agenda of the children of the
+[Romanian Communist Party][tezele] -- that is, PSD, ex-PDSR, ex-FSN,
+ex-paștele pizdii mamii lor de viermi împuțiți[^2] -- is not entirely
+baseless. About a decade and a half before that hopeful beginning
+consisting of promises on which the EU dream[^3] didn't deliver, at
+least for some... well, about a decade and a half before that, Romanians
+were being fed the same kind of concocted promises of freedom coming
+right after the dictator's bloody death[^4]. This so-called freedom
+meant "we want the Americans to come and give us their cocks" and
+"Americans" meant pretty much everyone from the West.
+
+Thus, the act of destruction depicted in the movie was conceived,
+prepared and executed by two sides: the Romanian side, represented by
+Vladimir (Vișan), and the American side, represented by two Frenchies
+(Stévenin and son) who want to exploit the opportunities offered by this
+new banana republic, namely to make sure that the small Aro Câmpulung
+plant stays down and gets sold piece by piece of scrap metal[^5].
+
+Their plan is almost -- but not quite -- thwarted by an otherwise smart
+wannabe influencer cum union leader, George (Vasluianu), who comes up
+with the not-entirely-bad idea of buying the plant. But not in any
+conventional way, oh no: his proposal is to crowdfund the acquisition by
+having the workers cash off sperm donation. This is where the pure,
+unadulterated Romanian comedy part comes in. Really, there's nothing
+more amusing than a bunch of guys -- some of them young, most of them in
+their forties -- trying to save the company by donating their seed to
+Western families[^6], while their conservative wives are all outraged by
+this heresy. And unlike depicted in bad Hollywood movies, the business
+proposition fails because that's just how the story goes.
+
+The rest of the Romanian parts are also as Romanian as they could be:
+the French teacher wants to impress the Frenchies communist-style, but
+fails; Manuela (Bârlădeanu) studied her telenovella Spanish and her
+mother makes great jam, which Frenchie son likes, so he gives the girl
+the opportunity of her life, anyway, certainly better than being
+George's fuckgirl; George herds the derp-flock made up of company "men";
+Romanians are unimpressed by them fancy snails; and, among others,
+Romanians are easily impressed by him Michael Jackson -- piece by piece,
+exactly what you'd expect from a minor culture trying to assimilate into
+itself that of the conquerors.
+
+And this about sums it all up: ever since the beginning of time[^7], for
+each Romanian who attempted to do something productive, there were seven
+others who sat and watched doing nothing, and two others who conspired
+the former's demise... or something like that.
+
+[^1]: Englishized as "Of Snails And Men", though I'd say it's rather Of
+ Men and Snails. 2012, directed by Tudor Giurgiu and written by Ionuț
+ Teianu. Starring Dorel Vișan, Andi Vasluianu, Monica Bârlădeanu and
+ some French guys.
+
+[^2]: I couldn't possibly express that in today's English, and I don't
+ know enough of Shakespeare's variety to write down a proper
+ equivalent; and besides, you wouldn't understand anyway.
+
+[^3]: A dream entirely concocted by Romanians, mind you.
+
+[^4]: To quote:
+
+ > **Vladimir**: Remember how you did during the Revolution?
+ > **George**: How we did what?
+ > **Vladimir**: You gathered here in front of the plant
+ > (gesticulates): free-dom! free-dom!
+ > **Vladimir**: Well, you got it.
+
+[^5]: This was a common occurence in 1990s Romania. Why? Well, I'll hand
+ the mic over to the economists to give an explanation of the
+ phenomenon.
+
+[^6]: To quote:
+
+ > **Ion**: Good night.
+ > **Carmen**: (Playful.) Are you tired?
+ > **Ion**: No, but y'know, tomorrow I'm going with the boys at
+ > Bucharest.
+ > **Carmen**: Oh, I know-I know-I know...
+ > **Ion**: Nighty... (resisting:) wait! C'mon, you know I can't! You
+ > know that very well! It was very clear in those questionnaires, what
+ > the heck.
+ > **Carmen**: I know, but c'mon, just a little, those guys won't
+ > catch on so easily.
+ > **Ion**: I can't... Don't you understand?
+ > **Ion**: Woman, we need to save that plant, what the heck!
+ > **Carmen**: (Upset.) You don't love me anymore.
+ > **Ion**: I do love you. But I can't do it tonight. I'm working for
+ > export.
+
+[^7]: Read up on some Romanian folklore sometime. It's not bad at all.
+
+[slither]: /posts/y02/048-slither-io-unfairness.html
+[tezele]: /posts/y03/05a-july-theses.html
+[aferim]: /posts/y01/039-aferim.html
--- /dev/null
+---
+postid: 05e
+title: The generative model of computing
+date: April 2, 2017
+author: Lucian Mogoșanu
+tags: asphalt, tech
+---
+
+*Once upon a time I [wrote a piece][modelul-generativ] that turned out
+decent enough to deserve being re-written in English. This is the result
+of that re-write.*
+
+One of the fundamental properties of computing is that it can be
+represented at various layers of abstraction: what constitues a program?
+Is it made up from a bunch of electrical signals? Or from evolving bits?
+Is it a set of registers changing their values in time? Or variables
+that are read, written and executed? Any of these is a valid
+representation, only one of them may be more useful to us than the
+others at a given time.
+
+At the same time, one of the fundamental problems of software is that it
+is inherently replicable. Mind you, this is not *my* problem; I myself
+am very happy with how computing and software work -- at least when they
+do[^1] -- which makes this ease of replication the exact opposite of a
+problem. It is however a problem for halfwits; for those people who
+believe that something that was read, and thus learned, can and
+sometimes must be magically un-learned; or who believe that something
+that was uttered can be magically un-uttered. No one sane knows why
+anyone would ever wish for this piece of nonsense to be possible[^2],
+but computer engineering is supposed to give practical solutions to
+technical problems, and I'm feeling particularly generous today, so
+let's indulge this intellectual wankery.
+
+As I was saying, software is replicable, and the problem is whether it
+can be made impossible, or at the very least extremely hard to
+replicate. That is, it is easy for virtually anyone to download a
+program off the Internet and run it on their computers; or a movie, or a
+secret document, and open them using a program. This works even when one
+is not legally authorized to do so, and it's simpler and a lot cheaper
+than actually stealing things, which forces the *actual* economic value
+of intellectual property to asymptotically go towards zero.
+
+This pernicious issue can be easily described at the instruction set
+architecture level. Generally processors contain an instruction dubbed
+`mov`, which moves a numeric value from a register to another. The
+problem, however, is precisely that it *doesn't* move data: it copies
+it! That is, when saying `mov r0, r1`, we read for example "move data
+from `r1` to `r0`", but we mean "copy data from `r1` to `r0`"; in other
+words, upon setting `r0` to the contents in `r1`, `r1`'s value doesn't
+change at all[^3]. This is so for very good practical reasons: firstly,
+it is more expensive to actually move data from one register to another,
+as we need to do two operations (set destination to source value; then
+erase source) instead of one; secondly, we don't know what the value of
+an "erased" (or otherwise "empty") register should be.
+
+But let's leave aside these details for a moment and specify in more
+precise terms what it is that we want: a computer that cannot *copy*
+data per se, and that can only *move* it. This is, of course,
+impossible: one must *put*, i.e. create, or otherwise generate an
+object somewhere in able to be able to then move it somewhere else. So
+what we really want is a computer with two basic operations:
+
+* a `move` operation: from register to register, from main memory to
+ register, from disk to main memory, etc.
+* a `generate` operation, that "puts" data into a memory unit (register,
+ a cell in main memory, on disk, etc.)
+
+An intuitive way to look at this is that any memory unit can be in one
+of two states: either "empty", in which case it cannot be read
+(i.e. used as a source); or "full", in which case it could be used as a
+source or destination if the user desires. Thus `move` cannot read from
+an empty register, while `generate` is pretty much equivalent to our old
+`mov`: it can read and write from and to anything. The advantage of this
+separation is that it would allow hardware manufacturers to limit the
+use of `generate`, by imposing a price on every instruction call and/or
+other policies, possibly used in conjunction with cryptographic
+approaches. Simply put, the possibility of having an instruction set
+with a `move` and a restricted `generate` opens up the possibility of a
+whole new different type of computing.
+
+Let's look at some of the practical design and implementation challenges
+of this model. Performance is an issue, as discussed previously, at
+least as far as the fabrication technology remains the same. Space is
+also an issue, as every memory cell now needs at least an extra bit to
+represent empty or full state. Since the data in memory cells is usually
+moved around, then a. all `move` instructions need to be transactions,
+i.e. if and when a `move` is completed, we are guaranteed that the
+destination contains the desired data and the source is empty, otherwise
+the `move` has failed and the state hasn't changed; and b. all memory
+must be persistent, such that e.g. following a power outage the system
+can be restored to its previous state without any data loss. These
+engineering problems are perfectly approachable, if not necessarily
+trivial.
+
+Then there are deeper problems: is this type of computer
+Turing-complete? This question cannot be given an off-the-top-of-head
+answer, and shall not be explored here due to space constraints.
+
+Then there are other practical problems: how easy is it to program such
+a computer? Adding costs to copying would conceivably put a limit on the
+development of software, as it would emphasize economy over the writing
+of code; but that aside, how usable would the machine be from the point
+of view of the user/programmer[^4]?
+
+Then there is the problem that software producers themselves would need
+need to pay for every software copy that they sell, because they would
+need to copy it before selling it. Which brings us to the crux of the
+problem: software and hardware vendors concoct all these technologies,
+e.g. SGX, various DRM "solutions", without thinking of many of the
+trade-offs involved. One can't stop copying without putting limits to
+it; and then once they've done this, they can't copy without actually
+copying[^5]; no, you can't have your cake and eat it too.
+
+[^1]: See "[The myth of software engineering][software-engineering]".
+
+[^2]: Oh, yes, I do very well, thank you. But this doesn't make you any
+ less of an idiot.
+
+[^3]: This also holds true for other operations, e.g. the arithmetic and
+ logic ones. For example `add r0, r1` typically adds the value in
+ `r1` to that in `r0` and stores it in `r0`, but leaves `r1` intact,
+ and so on.
+
+[^4]: To be perfectly clear: I can write code in assembly as easily as I
+ can write it in Python or almost any other language you'll give me,
+ because I practice these kinds of things and I can easily determine
+ the strengths of each particular language. However, I cannot as
+ easily program a quantum computer, because I don't know how to, and
+ because much of the knowledge of how to generally do it hasn't been
+ discovered yet. Sure, we know what the basic primitives are and
+ quite a few algorithms are well-specified, but let's say I wanted to
+ make my own Nethack implementation on a Quantum machine.
+
+ Contrary to what you might think, Nethack is an important cultural
+ product of this era, so why would not this be a legitimate question?
+
+[^5]: Take the DRM technologies used for video streaming for example:
+ they've come so far as to keep the DRM code and decryption keys
+ secret in a processor mode that is controlled by the manufacturer --
+ which assumes *implicit* trust on the user's part, which is stupid,
+ that is to say, a socialist measure, which is to say, entirely
+ tyrannical yet pretending to be something else -- but the data still
+ needs to reach your display decrypted, so that useful data, and not
+ garbage, is displayed. And even if the decryption algorithm and keys
+ were embedded in the display, you could still film what the display
+ is showing, which makes the whole charade pointless.
+
+ In other words, they are implementing a solution which *provably*
+ doesn't work, and by the by, they are also running secret software
+ on your computing device. Secret software which, of course, could
+ not possibly spy on you or impersonate you in ways you haven't even
+ imagined. But using PGP is bad and, y'know, generally a terrorist
+ thing to do.
+
+[modelul-generativ]: http://lucian.mogosanu.ro/bricks/modelul-generativ-al-software-ului
+[software-engineering]: /posts/y02/03c-the-myth-of-software-engineering.html
projects / thetarpit.git / commitdiff