That scary thing
I've spent most of my time since yesterdayi contemplatingii the following conversation :
davout Mebbe make scoopbot_revived not mention the title and let assbot handle it?
mircea_popescu Just dump teh link ? Eh, let it be decentralized.davout Sounds like each would do a small and simple job unix philosophy.
mircea_popescu This trivial problem just blew my stack. I confess I have NFI which is the correct approach.
* mircea_popescu steps away slowly and in terror, letting the parties involved decide.davout Sounds better to remove code from scoopbot rather than add some conditional logic to assbot.
kakobrekla The thing is that fucking conditional code is already in place as well, for some other bots.
davout Just my two cents.
mircea_popescu I would definitely read the essay discussing the merits of either side. I just realised I actually don't grok this shit.Adlai Seems parsimonious that in a channel where a bot announces link titles, there's no need to supply them yourself.
davout Because then what happens when scoopbot_revived is replaced by scoopbot_x or whatever.
kakobrekla You mean again :)
mircea_popescu What happens if assbot dies ? We must lose scoopbot titling too ?davout Assbot never diez.iii
mircea_popescu Decentralisation contrary to parsimonyiv. Fancy that.davout I'm really too lazy to argue further, I just tend to remove code instead of adding more whenever I can get what I want either of those ways.v
mircea_popescu No, I can definitely see your point. What bothers me is that I see no way to either dismiss it, or pick it.
Consider the contrary approach : suppose assbot's current situation in the "read website titles" market (it provides a service in competition to other agents, to the degree that service's useful) gets upgraded to a monopoly : only assbot may read the link and spit out the title. The overpowering question is, why stop there ?vi
Why not make an api and everyone who wants to put a link in channel pipes it into assbot ? Then the links can also be... checked. You know, for kids. See where this is going ?
Centralisation is always predicable on these "extra benefits", it's why states even ended up existing in the first place. Here and now, anywhere else and everywhere else the selling points for centralism are and were, and will be : that it's easier ; and that it's cheaper. Because, in point of fact, it is. So why should you and your girlfriend both pay rent, and have to cart the dildoes and cakes from one side of the town to the other ? And for that matter why should you and your recent wife keep individual checkbooks ? It's a waste of trees and then they have to be reconciled at the end!
The problem at issue here is absolutely trivial, of course. Its triviality has however made me realise that Ivii don't actually have a model for resolving this essential conflict that's any better than "I know obscenity when I see it, sir". Sure, you know imposition when you see it. Odds are you won't be seeing it every time you're about to impose on a snake in the grass. That is, after all, how the snake in the grass got to be such an evil mean racist gypsy pedophile in the first place. More importantly, the inability to define obscenity is prima facie sufficient evidence that it doesn't even exist.
I believe we absolutely need a model to illuminate the interaction between decentralisation and parsimonyviii, and we probably need it yesterday.ix
———- I even went for an icecream sugar bomb at Kako's place, which is the MP equivalent of putting the afterburners on. [↩]
- You know that thing where you explore all the ways in which a certain discussion could have went ? Yeah, I do that. [↩]
- He has a point here : it scarcely ever happens, and he never stays dead for long. [↩]
- If you think about it for a moment, these are exactly the contrary forces in distributed computing. What's "reuse code", what's "please upgrade" or "automatic upgrade" etc ? Parsimony. At the expense of what ? Decentralization.
If everyone were to reuse code maximally, then we'd have maximal parsimony in IT. We'd also have minimal stability - all NSA'd need is to frack the root of the reuse tree. If we were to all automatically upgrade everything, there'd be maximal parsimony in code distribution. Also maximal fragility. Fragility and stability are opposite evaluations of decentralization much like hot and cold are opposite evaluations of entropy. [↩]
- Which is a sound principle. Where is it a sound principle ?
In the domain which he himself lists, which is to say "when I". Within his own domain, wherein he is perforce and necessarily the centralizing agent, further centralization at his own hands is not a cost, and it produces benefits, so it is necessarily a good move. [↩]
- The rule is zero, one, infinity. And you'd better have one damned good reason why one rather than infinity. [↩]
- And I suspect, we. [↩]
- You will note that most of the "start-ups" (affectionately known as DERPs) that the VC circus keeps threshing around in the doomed but apparently unrenounceable hope that some grain will somehow materialize out of thistle and broadleaf weeds suffer from the exact same problem : an inability to adequately model this fundamental tension. Obviously, they also lack the intellectual werewithal to comprehend it, but that's par for the course in that space. [↩]
- That I only actually discovered this yesterday, in spite of being "involved in Bitcoin" since forever and in spite of it being clearly and obviously (in retrospect) a fundamental point of that involvement says a lot about what actual disruption actually is. Yes, Satoshi's code still sucks. How was he to know ? [↩]
Monday, 4 May 2015
It seems to me that the primary consideration is the limited recourse available to the most serene republic, as with any other state, in the event of the disappearance/elimination of a key service operator.
Since this is our primary concern for both critical and non-critical services, particularly in-channel bots, one potential framework for resolving this conundrum would be assess the sensitivity of the code itself and determine parsimony vs. decentralisation based on this. That is, if code can be openly published, or perhaps at least distributed throughout assbot's L1, and re-implemented at a moment's notice in the event of an operator going MIA or AWOL, then the service may be safely appended to an existing pillar. If the code is too sensitive to publish or even share among the L1, as determined by the consequent vulnerability to the operational system, then it should remain independently operated so as to distribute the risk of multiple critical services failing simultaneously.
Is scoopbot overly sensitive ? I don't know. But if it isn't, I see little harm in having assbot take it over.
I humbly submit this proposal in the full knowledge that the security and maintenance of code are not my forte. 'Tis just a thought.
Saturday, 9 May 2015
*crickets*
Saturday, 9 May 2015
It's a big lake, takes thinking.