[enobrev]

You could potentially keep a website "on a bookshelf at home" as well, provided the database is small enough. It doesn't even need to be SQLite. No matter the data format, you could get a fully running website on a raspberry pi, maybe with a subset of the data.

I'm picturing a bookshelf of raspberry pis in custom "boxes" like a collection of 8-tracks. Pull one out, plug it it, turn it on, and connect to it.

Considering the majority of my 20 year web-building career is long gone, this idea kind of intrigues me.

[cxr]

> I'm picturing a bookshelf of raspberry pis in custom "boxes" like a collection of 8-tracks. Pull one out, plug it it, turn it on, and connect to it.

Why do your books need onboard compute? Why a Raspberry Pi, and not, like, an MMC/SD or Minidisc?

I think when we recognize what led you to first reach for the Raspberry Pi, we'll be able to better nail down why things are more difficult today than they need to be, and what we should be doing instead to eliminate that difficulty.

[enobrev]

I was thinking of this generally. I've built hundreds of websites and while many had plenty of similarities, there would still be a plethora of databases and languages to support. And that's just my own history. There are quite a few developers, languages, data formats, services, etc.

And so the system that can run any "boxed" website - as in a working archive - would need to support all of these things, as they are today, in some form or would need to emulate / translate these things.

But instead of normalizing and archiving, my off-the-cuff suggestion is basically to freeze it in time. OS, languages, databases, services, data, code, everything is exactly as it was last built. Ideally, provided the storage medium held all its bits and the power source were compatible, it should boot up in 200 years without issue.

In a sense this is what we've accomplished with VMs and containers. But those still require an underlying system. If the system is part of the medium, you only need power and a console.

[cxr]

> there would still be a plethora of databases and languages to support

I don't think you absorbed the point I was going for there.

It sounds like you're prioritizing the website as an entity unto itself above the content. You're not thinking of the content as individual entities, and the website merely being a place where these entities are collected—like books on a bookshelf. That first false step in the conceptualization of this stuff is I believe to be _the_ reason that websites are "hard" to make manageable for a non-technical audience. All the implementations of "Information Management: A Proposal" have been executed poorly because the thing that TBL was outlining was obviously going to require computer systems, and when computer systems are involved you get the kinds of people who work on computer systems and their (largely self-serving) tendencies—which a lot of the time involves making everything in that system another system.

Do you need to support a plethora of databases and languages to maintain the other books on your bookshelf—that is, the dead-tree ones? Even for digital artifacts... the music you listen to, do you encode those as programs with unbounded power that you execute every time you want to hear a song? Or do you restrict yourself to relying on "dead" formats for what is sufficiently "dead" content, and then offload the need for computation to a separate machine that operates across a well-defined interface and that exists outside the content itself—a music player app? When it comes to backups, do you exclusively use self-extracting archives instead of something reliable like a tarball or a ZIP? Why not?

At the end of the day, websites are really just about pieces of content and the names we assign to them. It's the entanglement of all the unnecessary violations of the Principle of Least Power in the form of live systems and running programs that has made this stuff hard to manage (often not just for non-technical people, but programmers and sysadmins, too).

[enobrev]

Thanks for your thorough response. You've made your point well.

As I gather it, and I realize I'm simplifying, you're suggesting that websites need to be compiled for consumption just as a studio recording would be. I'm suggesting otherwise: That it's too varied of an experience to be compiled sufficiently across all the different ways in which the web is composed and consumed.

The content is not alone in what needs to be archived in order for a website (or any software) to live beyond just today. We don't _only_ read websites. We experience them in different ways depending on the purpose.

I have 30 tabs open right now: HN, google music, wordle, twitter, github, docker, nytimes, aws console, a couple blog posts, some software documentation, a couple pricing pages, and google maps open. Most of these things are not even remotely related in functionality, and we're supposed to be able to archive them into some similar format? For what purpose?

Much like a game, the experience of the content can be inherent in the content itself. But games are written to the same system. NES emulators and PS emulators and so on are required to enjoy game archives for systems that are now gone. My suggestion is to skip the emulator and include the environment with the content - which allows every piece of software to exist as it were originally conceived.

I could export a list of places I've been from google, but that's not useful to me in the same way without an interactive map to see the places therein. Same goes for foursquare and yelp and anything else that I allow to track my location for some purpose.

It would be incredible to be able to click around a static localized mostly-functional read only version of slashdot or fark or digg or prodigy or compuserve or geocities, or more recently HN or reddit. The UI for these applications is a _part_ of the content. Because the features are included in the content. Upvotes and Downvotes on HN are not the same as they are on slashdot, because slashdot's came with reasons. How does one experience that without the actual software? And how do we compile those software onto a single system that we'll be able to just load from nothing?

Do we _need_ to support a plethora of databases for books? No. Because they're books. Static, unsearchable, non-functional. Amazing in their simplicity. Perfect for what they are.

Software isn't that, nor should it be.

This isn't even a new suggestion. We used to have arcades - which were filled with separate systems built for single games, and each one was the size of a closet, including a screen and a UI. You can buy a 50 year old arcade game and, provided it was taken care of, it'll still boot up and work as it did in 1972.

Now we can get an entire system, with any software, and any database, onto a computer small enough that you could put hundreds of them on a single bookshelf. We could have terminals at libraries that you could plug these cartridges into and consume the information therein, and interact with them, in the original format.

I'm definitely not saying its the answer and should be done - only that it would be reasonable to accomplish as the world is today.

[jstummbillig]

To normies this is incredibly far from a bookshelf. What is a raspberry pi? What is the sqlite in doesn't-even-need-to-be-sqlite? Why do I have to care?

The highest level of questions you would need to be aiming for on the hardware side are: Where do I put this thing? Where did I leave the power chord? How do I turn it on?

If it doesn't turn on, you have someone repair it as you would any other electronic appliance. Can't be repaired? Get a new one. As soon as you plug it in it automatically fetches the automatically created backup. How? From where? What about encryption? The user is not qualified to answer any of that and should not be expected to care or expected to be involved into the decision. If I want to get involved with how electricity gets to my power socket I can look that stuff up on the internet. In the meantime just make it work without any intervention and with 99.9% reliability.

Us techies (maybe subconsciously) still lean way too much towards trying to involve users with the stuff we care about, when most of them just want our work to be invisible. Hide the complexity. Make it seamless. Make all tech a power socket.

[donkeybeer]

All that doesn't matter. What normies did was purchase a CD of a native application, install it and have it work basically forever; with zero need for servers or hosting costs.

[wccrawford]

In my experience, home servers are delicate. Power outages and brownouts not only temporarily take the server offline, they can corrupt it and take it offline permanently. And you still have to pay for the hardware and the power.

It's much cheaper, easier, and more reliable to go with a cheap webhost like nearlyfreespeech.net to keep it online at almost no cost or maintenance.

[immibis]

IPFS does this.

[WJW]

As long as you bother to pin the content of course, otherwise you have to hope that someone else does. But if you have to store the data yourself anyway, why not go even simpler and store the content in a folder on your hard drive?

[immibis]

That's the point: if you want to put the website on your bookshelf, you can pin it.

Storing websites on your hard drive tends to break URLs; content addressing solves that.

[xyzzy123]

I believe that content addressed storage had to be built open-source because it was ultimately not in anyones corporate interest to further it.

It's interesting to reflect on the kinds of technologies which are clearly possible, but never seem to get built because they don't centralise control. Truly offline apps, and actually working device-to-device networking fall in this bucket I think. Yes, there are power and privacy considerations but it's pretty clear none of the big players want those technologies to take off.