The slab and the permacomputer
society.robinsloan.com
society.robinsloan.com
I see this trend too: the systems powering the modern world are increasingly featureful, complicated, centralised into a few hands, and this will likely continue.
I'm a keen developer and user in this world, and recognize the vast users this world provides for.
At the same time, I appreciate a back-to-basics approach that emphasizes systems that can be understood and controlled by individuals and small communities:
* Hardware that has open specs: Pinephone, Pinebook, Raspberry Pi, ...
* Open source OSs: Linux desktop, Linux mobile, Lineage OS.
* https://reproducible-builds.org/ and https://www.bootstrappable.org/, allowing trust to be distributed.
* Monorepo based OSs: NixOS, Guix.
* Gemini, rather than the web: web browsers are now beyond reasonable understanding/control for small communities.
* Mastodon rather than Twitter.
* Projects that are community driven.
* XMPP/Matrix over Signal/Discord/FB.
I choose to live within this world for my personal world where possible. It's not as featureful, and that's fine.
Slab vs cloud is a non-issue. The real issue is technocracy vs humanity.
Currently we have no human computing of any kind. Non-experts have two choices: being monitored in as many different ways as is practical in order to be carpet-bombed with targeted ads and (increasingly) fake news. Or being forced into endless tinkering with opaque systems that sort-of work some of the time, maybe, and require expert knowledge for installation and configuration.
That's it. There is nothing else on the table. It's one or the other - and often both.
So when I read a phrase like "Google's largesse" I'm not sure what the point of the article is.
There is no largesse. And there's also no real choice for most users.
The independent dev community could change this, but it seems permanently attached to the wrong end of the telescope, looking at computing from the comfort of its tool- and toy-making treadmill.
"Why should an ordinary user care about this?" isn't asked nearly as often as it should be. And "Don't you understand the tech is fun to play with?" is not the right answer.
Many of the biggest innovations in computing happened because someone asked that question. For some reason the entire industry seems to have stopped asking it.
Except when there's an obvious possibility an answer can be monetised. And while that's certainly a reason, it's not necessarily the best reason.
> The independent dev community could change this, but it seems permanently attached to the wrong end of the telescope, looking at computing from the comfort of its tool- and toy-making treadmill.
In defense of the tool makers: the reason corporate IT can cater to regular users so well is because they can throw a lot of warm bodies at the problem. The tools we use in this industry are shit, but it doesn't matter when you can use hordes of developers as a protein substitute for better tooling.
I believe the road for "independent dev" software usable by masses starts with better tools, and better tools for making tools.
Additionally, I think "most of the biggest innovations in computing" actually happened because of toy-making treadmill. Even in the startup world, a common advice is to scratch your own itch - it often leads to something that's widely useful.
> "Why should an ordinary user care about this?" isn't asked nearly as often as it should be. And "Don't you understand the tech is fun to play with?" is not the right answer.
In defense of the "independent dev community": perhaps we care a little bit too much about ordinary users? The way I see it, most modern software is dumbed down, lowest-common-denominator toys, whose sole purpose is to sell well and/or sell their users out. Tech-savvy people, and even less savvy users who care about getting things done, are now considered a niche too small to care for. While there are some businesses still working on "power user" tools, the platforms themselves - operating systems - are being optimized for unsophisticated users, dumbed down and locked down.
Again, I believe most of the biggest innovations, the ones helping everyone, start with engineers scratching their own itch. To the extent it's becoming harder, all users lose out.
I really disagree. I think engineers scratching their own itch leading down to trickle-down tooling is what a lot of independent devs _like to believe_, but that it's motivated mostly by self-importance. I think the utter failure of the FOSS desktop is proof that devs are motivated to work on things they find fun and that these things do _not_ necessarily translate to things that general users want to use.
> Even in the startup world, a common advice is to scratch your own itch - it often leads to something that's widely useful.
I think that's bad advice. That's the _kind_ of advice that leads to things like the hundreds of now-dead clothes washing startups or valet parking startups. And while endless VC rounds blunt this, at least startups have some form of market pressure to have people use their software.
> In defense of the "independent dev community": perhaps we care a little bit too much about ordinary users?
Not really. Software devs are the last set of STEM-engineers that still insist on understanding _everything_ and holding entire systems in their heads. Civil Engineers don't start by considering the subatomic forces that hold their materials together; automotive engineers don't understand every aspect of the software and combustion reaction that goes into their designs. Most engineers accept abstraction as a cost for building useful things.
> The way I see it, most modern software is dumbed down, lowest-common-denominator toys, whose sole purpose is to sell well and/or sell their users out.
"Sell well" is just a euphemism for "software that others use". Money is just the easiest metric to calculate for software being bought and sold, but metrics like "downloads per month" are just as impactful.
Just like you didn't buy a new car and then spend days learning about how it works, most users of software don't want to either. That's not to say that there isn't a robust scene of modifying cars or building hobby cars, but that most people who drive cars for utility purposes don't care to pierce the abstraction veil of an automatic transmission, a brake pedal, and power steering. Most software users just want software that gets out of their way or enables to connect with others in novel ways. They don't care about how much energy their software uses (as long as it's affordable) or how "simple" it is or whether it uses Unix sockets or DBus or something.
I'm not a desktop environment developer, but I can't imagine it's especially fun compared to other projects. The bigger projects (Gnome, KDE, etc) are definitely being run for instrumentalist reasons, and are supported to quite a degree by companies with a business interest in having them.
Thinking about this reminded me of a highly insightful comment by user Floegipoky[0]:
> By mimicking the Apple and Microsoft tactic of constructing vast monolithic environments and applications, you have all unwittingly been playing to their strengths, not yours. Such enormous proprietary companies can afford such brute-force strategies because they have vast financial and manpower resources to draw on.
> Projects like Gnome and Open Office become like our banking industries: vast, baroque, impossible to regulate effectively, and cripplingly expensive to maintain.
Doesn't exactly sound fun — and whose itch is being scratched by working on these?
> the Linux desktop world (and even the kernel world beneath it) has completely and utterly forgotten its roots. Unix Philosophy isn't merely a neat marketing phrase: it describes a very specific way to construct large, complex systems. Not by erecting vast imposing monoliths, ego-gratifying as that may be, but by assembling a rich ecosystem of small, simple, plug-n-play components that can be linked together in whatever arrangement best suits a given problem.
I acknowledge this.
> "Why should an ordinary user care about this?" isn't asked nearly as often as it should be. And "Don't you understand the tech is fun to play with?" is not the right answer.
I have spoken to friends and family and they are perfectly happy with their mainstream computing choices.
I acknowledge that my preference for back-to-basics is partly due to fun. I'm not trying to change minds. I enjoy this small paradise for hackers.
I like the idea of not having to worry about hardware when I'm more interested in software. But there's a certain amount of control that's given up when you relinquish ownership of the hardware. I don't like the idea of paying for things in a service model.
I'm approaching this from a personal perspective, not a business perspective. I'm completely comfortable with reducing my business's risk and liability by buying into hardware as a service. But I'm not as inclined to trust it for personal computing.
This is the point that the author makes in the second part of their post. Quote:
"The dutifully critical part of me wants to shout: you shouldn’t trust these slabs! Their operators, G — and A — and M — and the rest, will surely betray you. The very signature of the corporate internet is the way it slips from your grasp. The leviathans swim off in pursuit new markets, and what do they leave you with? Deprecation notices."
So, something like: "not your chips, not your code"?
This also really reminds me of the absolute squandering of resources by "modern" systems - old x86 DOS systems with 1/16,000 the memory and processing power were literally more responsive for everyday use than the mountians of framework junk we run on today. There is a lot of headroom left to downsize and create very useful machines.
Like, some sort of verifiable computing kind of deal.
Because I hadn’t read the quotation carefully (as otherwise I would have caught the part about depreciation notices before reading the article).
At some point, Microgoogazon transitions to being manufacturers and/or operators of the hardware, and the (perhaps nominal) ownership devolves to some variation on a public utility like electricity.
To bring it back to this article:
> You already know the answers! They’d use less power; they’d be hardy against the elements
Less power than what? Are current low-power SOCs not enough? Do we need even lower power? What exactly _is_ the power budget and where do we see this deployed? Why would they need to be hardy against the elements; books certainly are _not_.
> The whole stack, from the hardware to the boot loader to the OS (if there is one) to the application, would be something that a person could hold in their head.
I mean, whose head? A kernel programmer can probably hold a very different set of things in their head than a network engineer than a web programmer and so on. One person's "easy" is another person's "hard". So how do we define "hold in their head"?
> Basically every computer used to be like that, up until the 1980s or so;
Were they? Documentation and manuals were expensive and hard to find. There was no place to ask questions and receive answers like forums or StackOverflow. Computing time was scarce. Only in _hindsight_, now that we have web pages describing these older architectures and their machine code available at our fingertips do these architectures seem easily comprehensible. But at the time, with computer time being scarce and manuals being expensive, this mostly wasn't the case. (This is my other problem with permacomputing, the weird Lindy-effect exoneration.)
> I find this totally evocative: it’s easy to imagine future permacomputers that rely, for some of their functions, on artifacts from a time before permacomputing. It would be impossible, or at least forbiddingly difficult, to produce new model files, so the old ones would be ferried around like precious grimoires …
I mean, if I were larping as the monk protagonist of a post-apocalyptic movie sure, but otherwise I don't see how this is desirable.
I'd take permacomputing more seriously if it actually defined terms like "lower power" (how many mW is "low") and then tried to actually motivate why these things tie into their vision of permacomputing.
EDIT: I also _always_ get downvoted without explanation when I raise anti-permacomputing viewpoints which also leaves a bad taste in my mouth when discussing this topic.
Now _that_ would be very cool! I can imagine a computing device driven by solar or wind. But when it comes to solar or wind, the important part isn't energy usage as much as it is dealing with inconsistent energy output. Here we'd want to design computers for situations with varying amounts of available power. But that's much more nuanced than "low power".
> Also since data storage is constantly moving to be more volatile, complex to decode and distributed in space, we might want to start encoding our knowledge as the ancient civilizations did, in stone, but with some easy to decode language (think Voyager probe). That would be permastorage.
That too would be very cool. Not sure if you've read over VPRI's paper on digital Cuneiform Tablets [1] but it's a great read in that vein.
The minor visual tweaks which arrived in macOS 11 and iOS 14, to me, evoke a similar sense of "slab" computing. I saw it in the merging of UI tooling; in the visual and operational related-ness of widgets across the two operating systems; with the tiny details like the hazy amorphous backgrounds and the flattening of "windows"; with the gentle deprecation of "system" UI (making the menubar recede); most especially with the expansion of cross-device tooling - your current state with many document types can move with you from device to device. The visual similarities are nothing to do with "merging the operating systems". Apple likely won't do that - they tie the OS to the hardware, the form factor, the principle input/output mechanisms. The similarities are about providing consistent experience and interfacing across different operating systems. It's probably also a bit about "branding" Apple's version and approach to "slab" computing.
Apple are already embracing this "slab" idea, already have it working across a growing number of applications and device types, in a way that non-nerds can use it with minimal set-up.
I'm imagining an individual or org could download a daemon, start it up on a spare machine (or a workstation with spare cycles!) and just get paid over time as people run lambdas/workers on their hardware. Of course you'd need some really intense sandboxing, but that seems like it could be solvable. Or maybe it isn't, and that's the reason this doesn't exist.
Isn't this essentially what browser+js does? you download someones code and execute it locally. Reminds me of this xkcd https://xkcd.com/1367/
however, after typing that out I think I see what you really meant: if I'm running something compute intense, why can't I just borrow cpu from a couple neighbors instead of going all the way to the datacenter?
Sandboxing would be important, but it would also be pretty hard to build applications that really take advantage of this model. concurrency on one machine is hard enough!
It's highly unfortunate that this can't seem to be done in systems with millions of times the compute resources, decades later. /s