4 ms·

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

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.

immibis 5y ago
IPFS does this.
- xyzzy123 5y ago
  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.
- WJW 5y ago
  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 5y ago
    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.
jstummbillig 5y ago
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 5y ago
  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 5y ago
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.
cxr 5y ago
> 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 5y ago
  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 5y ago
    > 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).

immibis 5y ago

IPFS does this.

xyzzy123 5y ago
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.
WJW 5y ago
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 5y ago
  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.

jstummbillig 5y ago

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 5y ago
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 5y ago

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.

cxr 5y ago

> 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 5y ago
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 5y ago
  > 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).