9 ms·

How Websites Die

144 points by herbertl 4y ago

lazyjeff 4y ago
I've been working on this problem for a while. Website upkeep is hard to quantify, but basically every disk fails and every operating system eventually needs a serious upgrade. The timeframe that a system can run continuously is not that long compared to the timeframe that information is relevant. So the most lightweight way to keep something up and running is to make it trivial to port to many hosting configurations by simplifying the toolchain needed to rehost it. (Note that humans are part of that workflow, if it's a company) I've written a manifesto about making a commitment to keep websites online and maintained for 10-30 years, for people who are maintaining web content: https://jeffhuang.com/designed_to_last/ https://jeffhuang.com/designed_to_last/ And on the flipside (from a user's point of view), I've also been working on a background process that automatically captures full-resolution screenshots of every website you visit, creating your own searchable personal web archive: https://irchiver.com/ https://irchiver.com/ I've personally been trying to make a commitment to keep my web projects and writing online for 30 years. My original internal goal when I started thinking about this, was to outlast all the content on Twitter, Google+, and facebook.com. One of those has already been met, kind of sadly.
- anonymoushn 4y ago
  irchiver seems incredible. I hope there's a comparable product for other OSes one day.
  - ryanfox 4y ago
    I’ve been working on a very similar thing which runs on Windows, Mac, and Linux: https://apse.io https://apse.io
- 10000truths 4y ago
  It’s not uncommon to hear of rack servers with several years of continuous uptime. I wouldn’t be surprised if you could keep a website online for a decade without touching anything by using an LTS distro, enabling unattended upgrades, and running something like nginx.
- EddieDante 4y ago
  > I've also been working on a background process that automatically captures full-resolution screenshots of every website you visit, creating your own searchable personal web archive: How are screenshots searchable? They aren't plain text. You can't grep them.
  - anonymoushn 4y ago
    The tool captures screenshots in addition to text.
    - doodles33 4y ago
      That seems awfully simillar to archive.org wayback machine. I do like to see all these archival projects though, they are certainly worthwhile.
      - lazyjeff 4y ago
        irchiver captures text on the page, and separately OCRs the screenshots (specifically, the screenshot from your viewport). So you can search just what was shown on the page, or what was in the page. Both techniques have pros and cons. While archive.org is fantastic, it can only capture pages that are both 1) publicly accessible (i.e. no social media content) that it happens to crawl, and 2) static content (you're out of luck if the content you want is loaded dynamically, or changes depending on user input).
        pabs3 4y ago
        IIRC archive.org does save the JS and things it downloads, so you can replay them when you visit the archived site later.
        doodlesdev 4y ago
        I guess the difference in this case is that the JS on web archive relies on future browsers being backwards compatible, whereas irchiver relies on much less to stay timeless which is good. Although I don't think JavaScript will ever get a major update (as in breaking comparability) I believe relying on that is not a perfect way to archive web content. This kind of backwards compatibility breakage is something we have seen before with the deprecation of Adobe Flash and it could theoretically happen elsewhere on the web stack.
- SoftTalker 4y ago
  I think it's less a technological problem and more just that everyone who used to care about that site or its content no longer does. Or the company behind it has gone out of business -- who is going to maintain a website for a defunct organization, and why would anyone want to? There's no obligation for a person to maintain anything longer than he wants to do it. Putting a blog online is not a lifetime committment. Interests change, or you simply realize nobody much cares about your online musings, and you move on to other interests.
  - gowld 4y ago
    But what can you do when you do care, to make your website as durable as a printed book?
    - hypertele-Xii 4y ago
      You could literally print it in a book. With links suffixed by a page number [915].
    - bombcar 4y ago
      Depends on if you want it to survive without you maintaining it. If so, something like a bog-standard Wordpress blog hosted by them might work until they decide they don't want to bother anymore. Otherwise, some setup using S3-as-a-website or GitHub pages may work, but those also depend on the company maintaining that service. If your entire website can be dropped into a ZIP file and served anywhere, you have a greater chance in it surviving, especially if the internet archive got a copy at some point. But if you die and nobody cares about the content, eventually it will disappear.
      - ElectricalUnion 4y ago
        > If your entire website can be dropped into a ZIP file and served anywhere, you have a greater chance in it surviving, especially if the internet archive got a copy at some point. Well, your entire website can be a zip: https://redbean.dev/ https://redbean.dev/
    - 4y ago
- chubot 4y ago
  Hm interesting, I read over your 7 guidelines [1] and I would say I agree 50%. So the most lightweight way to keep something up and running is to make it trivial to port to many hosting configurations by simplifying the toolchain needed to rehost it -- I agree with this, although I would use the words "standards" and multiple implementations. The linked article doesn't appear to emphasize this. 1. Return to vanilla HTML/CSS Again I feel the relevant issue is "standards", multiple implementations, and the fallback option of "old code" like GNU coreutils (i.e. taking advantage of the Lindy Effect). Not just just HTML/CSS (which certainly meet all of those criteria.) I thought about this when designing https://www.oilshell.org/ https://www.oilshell.org/ and the toolchain - The site started in Markdown but is now standardized on CommonMark [1], which has multiple implementations. So I don't see any reason to stick to HTML/CSS. - The tools are written in Python and shell [2]. Both languages have multiple implementations. (Ironically, Oil is a second implementation of bash! My bash scripts run under both bash and Oil.) - Python and shell rely on Unix, which is standardized (e.g. Linux and FreeBSD have a large common subset that can build my site). This is perhaps unconventional, but I avoided using languages that I don't know how to bootstrap like node.js (has a complex JIT and build process), Go (doesn't use libc) or Rust (complex bootstrap). On the other hand, C has multiple implementations, and Python and shell are written in C, and easy to compile. I'd say Lua also falls in this category, but node.js doesn't. I feel like this is at least 60% of the way to making a website that lasts 30 years. The other 40% is the domain name and hosting. This is a pretty a big site now, you can tar a lot of it up and browse it locally (well it's true you may have to rewrite some self links). Of course, this is my solution as a technical user. If you're trying to solve this problem for the general public, then that's much harder. [1] https://www.oilshell.org/blog/2018/02/14.html https://www.oilshell.org/blog/2018/02/14.html [2] https://www.oilshell.org/site.html https://www.oilshell.org/site.html 2. Don't minimize that HTML Mildly agree if only because it's useful to be able to read HTML to rewrite self links and so forth. Tools don't need it, but it's nice for humans. 3. Prefer one page over several If you're allowed to use Python and shell to automate stuff, then this isn't an issue. I suppose another risk is that people besides me might not understand how to maintain my code. But I don't think it needs to be maintained -- I think it will run forever on the basis of Unix, shell, and Python. Those technologies have "crossed the chasm", where again I think the jury is still out on others. 4. End all forms of hotlinking Yes, my site hosts all its own JS and CSS. 5. Stick with native fonts Yes, custom fonts have a higher chance of being unreadable in the future. I just use the browser's font preference to avoid this issue. It's more future proof and in keeping with the spirit of the web (semantic, not pixel perfect). 6. Obsessively compress your images Agree 7. Eliminate the broken URL risk I think too few people are using commodity shared hosting ... I've been meaning to write some blog posts about that. I use Dreamhost but NearlyFreeSpeech is basically the same idea. It's a Unix box and a web server that somebody else maintains. I absolutely don't care about CPUs, disk drives, even ipv4 vs. ipv6, and I've never had to. The key point is writing to an interface and not an implementation. Commodity shared hosting is a de facto standard. The main difference between a tarball of HTML and a shared hosting site is that say "index.html" is always respected as /, and a few other minor things. So I expect Heroku and similar platforms to come and go, but the de-facto standard of a shared hosting interface will stay forever. It's basically any Unix + any static web server, e.g. I think OpenBSD has a pretty good httpd that's like Apache/Nginx for all the relevant purposes. Github pages also qualifies. So I guess this is adding sort of a programmer's slant to it. To be honest it took me a long time to be fluent enough in Python and shell to make a decent website :) Markdown/CommonMark definitely helps too. I had of course made HTML before this, but it was the odd page here and there. Making a whole site does require some automation, and I agree that lots of common/popular tools and hosting platforms will rot very quickly. (and like you I've seen that happen multiple times in my life!) And I think what your guidelines might be missing is a guideline on how to make "progress". For example CommonMark being standardized is progress that has happened in the last 10 years. You don't want to be tied to the old forever. At some point you have to introduce new technologies, and the way to do that is once there's wide agreement on them and multiple implementations. (just like there's wide agreement on HTML) I think there is / can be progress in dynamic sites too, so you don't have to stick to static!
- samsquire 4y ago
  One of my ideas is called Wantsfiles at the root of domains. The Wantsfiles contains information about what you want and the price you're willing to pay. An order matching system matches your Wantsfiles.txt to Sellfiles.txt and transacts on your behalf. So I could host link to my tgz on my Wantsfile and offer $5 to host the tarball a month. There we go a perpetually hosted website. You could call it autohosting.
- powersnail 4y ago
  > system font stack that matches the default font to the operating system of your visitor If the list just matches the default font of the OS, is there a difference between using such a stack vs. not specifying a font? Wouldn't the browser naturally use the OS's default if font-family is unset?
- 8n4vidtmkvmk 4y ago
  disk failure and os upgrades are a non-issue with the right technology stack.... but then you have other problems (more complicated setup)
- shadowofneptune 4y ago
  Interested personally in the font stack point. The system font stacks listed focus on font styles more than individual typefaces. If I want say, Bookman, is there any harm to long-term use to use a font stack tailored to that font?
  - chipotle_coyote 4y ago
    There isn't, no, and there's no particular harm in self-hosted web fonts when it comes to long-term stability. Not only is it relatively unlikely that future browsers will deprecate web fonts but not anything else in current CSS (in which case there's a bigger issue than your fonts), it's even less likely that they'll do so in an entirely incompatible fashion. Assuming you've designed your font stack with decent fallbacks -- which you should -- then it's just like any other font stack, e.g., you may not be presenting in the typeface that you really want to, but nothing's going to break. ("Web fonts are okay, actually" is evidently the windmill I will keep tilting at on Hacker News.)
paulgb 4y ago
> you may attempt to archive it, but should you wish to avoid sadness down the line, you should accept now in your heart that all archives will eventually succumb to the sands of time. Enjoyed this.
- bombcar 4y ago
  You could etch your data and website onto copper plates and launch them into the depths of space; this will likely last near until the heat-death of the universe!
  - asddubs 4y ago
    and simultaneously it will be lost immediately
    - saagarjha 4y ago
      And here we see the difference between available and accessible :)
jaytaylor 4y ago
> I’ve often thought about getting together with some friends to pay into a fund to house our websites after we die. I don’t think setting that up would be too hard — the math around insurance policies of this sort is quite simple — I mostly haven’t tried to set something like this up just since it’s a pretty morbid ask. But, if you’d be interested, maybe reach out to me? > Our ghosts could live forever, if we help each other. I love this idea and would gladly assist in the effort, let's set it up :)
- cxr 4y ago
  Previously <https://news.ycombinator.com/item?id=31047818 https://news.ycombinator.com/item?id=31047818> ----- From the NearlyFreeSpeech.Net FAQ <https://www.nearlyfreespeech.net/about/faq#Interest https://www.nearlyfreespeech.net/about/faq#Interest>: > Q: Do I get interest on my deposit? A: No[, but...] We periodically reevaluate this situation, because we think a web account that runs forever purely off of its own interest is a pretty cool idea. NFSNet also has an interesting part in their FAQ in response to the question If I think services you host are currently unavailable due to lack of funds; is there anything I can do?, they outline a process whereby third-parties can fund a hosted service by creating an account themselves, depositing funds into their own account (NFSNet services are prepaid instead of billed after the fact), and then submitting a manual (but free) request to transfer those funds to the original accountholder based on the service's domain name. I've always thought this was interesting because in theory someone could set up a community, disappear, and then the community could step up to keep it funded long enough for the person to get out of the hospital/be rescued at sea/etc, so long as the infrastructure is solid enough to remain operational without being attended to (not vulnerable to exploits, etc.) They've also got a policy where if the member who operates the service is a willing participant, they can publish their NearlyFreeSpeech.Net account ID and have donors add funds to cover 100% of service costs via automated transfers. <https://www.nearlyfreespeech.net/about/faq#Lifeboat https://www.nearlyfreespeech.net/about/faq#Lifeboat>
- floren 4y ago
  the year is 2122 and all the "good" (short, memorable) DNS names are owned by ghosts. in the grim dark future, there is only joe_smith_from_minneapolis_born_2055.com
deleted 4y ago
[deleted]
doodles33 4y ago
Unstoppable domains solve this problem by making domain purchases permanent and stored on a decentralized blockchain - although that brings some problems of it's own - and IPFS solves that by not requiring that a central server stays online to serve that content, although this does require that _someone_ be insterested in serving the website at all.
- rchaud 4y ago
  This article isn't about websites going offline. It's about websites dying of 'natural causes', meaning the author or site manager lost interest in updating and maintaining the site. There's much more to the soul of a website than the datacenter where it's hosted. I doubt if the handful of mirror.xyz 'decentralized' sites I see popping up will still exist in 5 years' time.
- Dan_Sylveste 4y ago
  >blockchain >solves this problem Sure. Absolutely. Probably cures cancer too.
  - doodlesdev 4y ago
    Show me where I can buy a permanent domain directly from ICANN and be sure that it will be stored forever without ever relying on a single company or system to keep working and I will suggest it over any blockchain solution immediately. The problem is that it does not exist and it probably never will, and thus this is the next big thing. Also relevant LOL (although you're right when it comes to blockchain and cancer, this is nonsense, I just though it was funny): https://www.independent.co.uk/news/business/business-reporter/blockchain-startup-cancer-research-revolutionising-b1920550.html https://www.independent.co.uk/news/business/business-reporte...
spc476 4y ago
It comes down to the person running the website has to care. That's it. It doesn't matter how simple it is if the person doesn't care. In my own case, I've been running my own website for 24 years now [1]. The URLs I started out with have remained the same (although some have gone, and yes, I return 410 for those) and the technology hasn't changed much either (it was Apache 24 years ago, it's still Apache today; my blog engine [2] was a C-based CGI program, and it's still a C-based CGI program. The rest of the site is static, and there's no Javascript (except for one page). I can see it lasting at least six more years, and probably more. But I care. [1] Started out on a physical server (an AMD 586) and a few years later on a virtual server. [2] https://github.com/spc476/mod_blog https://github.com/spc476/mod_blog
- remus 4y ago
  > It comes down to the person running the website has to care. Personally I think it is a little more nuanced, in particular I think the relationship between how much someone cares and how much effort is required to keep the website online is what matters. If your website is super simple you don't need to care about it very much (though you do need to care at least a little bit). On the other hand, if everyone who works at google suddenly quit tomorrow because they didn't care the stack of cards would fall over very quickly because it's a lot of work maintaining millions of servers.
sparcpile 4y ago
There have been some attempts to capture sites that became the ghosts or disappeared completely. During the dotcom bubble through 2008, Steve Baldwin(co-author of Netslaves) had that as a side project. https://www.disobey.com/ghostsites/ https://www.disobey.com/ghostsites/ Our Incredible Journey still does this, with more snark and humor. https://ourincrediblejourney.tumblr.com/ https://ourincrediblejourney.tumblr.com/
fleddr 4y ago
I'd like to call out the somewhat related problem of website rot. Meaning, the websites is online, it once worked perfectly, but becomes increasingly dysfunctional due to technical deprecations. The soft obligation to use HTTPS these days has deranked old HTTP-only websites in search, making them hard to find. These websites are also "defaced" with browser warnings or some subresources may not load at all. Embedded maps no longer work, since Google regularly breaks their API. Facebook login or other FB plugins no longer work, since it needs a yearly checkup of your account and there's the new requirement of needing to have a privacy policy. Those are just some examples of websites partially breaking through no fault of its creator, if you'd agree that the web should be backwards-compatible.
- asddubs 4y ago
  also, even if those older http sites get a certificate, any embedded scripts that point at http URLs, even if those URLs are also available on https, will not load and break. Especially hard to fix if you have user generated HTML on there. Same for http download links from https websites, will not work anymore. anything that used cookies on embedded resources will also be broken because of the missing samesite header (same for third party cookies obviously) if google really goes through with removing alert/prompt/etc from their browser like they said they were planning to a while back, so so many things will break
  - EamonnMR 4y ago
    Notification prompt is 10x more annoying than alert ever was.
    - deleted 4y ago
      [deleted]
  - fleddr 4y ago
    I'm uniquely bothered by this problem as I visit many such dysfunctional sites. I'm active in the (hobbyist) field of documenting species. There's thousands upon thousands of websites created by amateurs containing unique niche content. For example, somebody might have made it their lifelong hobby to document every species of bee in their territory. It's a fragmented mess of incompetently produced websites, but I find it incredibly charming and in the spirit of the original web. Above all, it is their content that has lasting value. The people behind it are good, generous. That's why it makes me so angry when their work is cast aside like this. Things not just technically breaking, in many cases simply disappearing altogether from search results.
nonrandomstring 4y ago
A very nice read with some poignant thoughts and quotes on digital impermanence. Life on the Internet is nasty, brutish and short.
sshine 4y ago
My first domain “expired” in an unexpected way after 18 years. I got a .eu.org because I believed that eu.org would be more stable than a commercial provider. I used the same not-for-profit DNS provider until they were commercially acquired and the parent company shut down the old nameservers. Now I’m locked out: eu.org does not respond to inquiries for switching nameservers, and my account predates the auth system. While my phone number is the same, auth reset does not work with phone. It would have been fun to retain the same domain forever, but stuff breaks, people die, and things crumble.
rschachte 4y ago
This really makes me want to redesign my site with minimal external dependencies and clear documentation.
foxhop 4y ago
I personally sunset a handful of websites this year. only kept a handful to try to dedicate time to. writing open source the new site is called Make Post Sell (https://www.makepostsell.com https://www.makepostsell.com) hoping to restore a bunch of content as shops in this multitenant SaaS.
langsoul-com 4y ago
Sad and depressing when things die, especially without notice, but that's life. I have a blog, https://langsoul.com https://langsoul.com, that could die anytime. After all, sites are a lot of work and only a few make anything worthwhile to continue. Not to mention, if I were to suddenly get ill, what then? Do I write into my will to launch a farewell blog post? I think there was this internet cult that maintained their site for over 20 years from the leaders death. It required alive cult members to keep it alive. Unfortunately I don't have cult members, nor funds to start a trust to keep the site going.
- kaeruct 4y ago
  I think the cult you are referring to is Heaven's Gate: https://www.heavensgate.com/ https://www.heavensgate.com/
the_origami_fox 4y ago
The automated url # fragments on highlights for this website is a cool but weird feature

144 points by herbertl 4y ago

I've been working on this problem for a while. Website upkeep is hard to quantify, but basically every disk fails and every operating system eventually needs a serious upgrade. The timeframe that a system can run continuously is not that long compared to the timeframe that information is relevant. So the most lightweight way to keep something up and running is to make it trivial to port to many hosting configurations by simplifying the toolchain needed to rehost it. (Note that humans are part of that workflow, if it's a company) I've written a manifesto about making a commitment to keep websites online and maintained for 10-30 years, for people who are maintaining web content: https://jeffhuang.com/designed_to_last/ https://jeffhuang.com/designed_to_last/ And on the flipside (from a user's point of view), I've also been working on a background process that automatically captures full-resolution screenshots of every website you visit, creating your own searchable personal web archive: https://irchiver.com/ https://irchiver.com/ I've personally been trying to make a commitment to keep my web projects and writing online for 30 years. My original internal goal when I started thinking about this, was to outlast all the content on Twitter, Google+, and facebook.com. One of those has already been met, kind of sadly.

anonymoushn 4y ago
irchiver seems incredible. I hope there's a comparable product for other OSes one day.
- ryanfox 4y ago
  I’ve been working on a very similar thing which runs on Windows, Mac, and Linux: https://apse.io https://apse.io
10000truths 4y ago
It’s not uncommon to hear of rack servers with several years of continuous uptime. I wouldn’t be surprised if you could keep a website online for a decade without touching anything by using an LTS distro, enabling unattended upgrades, and running something like nginx.
EddieDante 4y ago
> I've also been working on a background process that automatically captures full-resolution screenshots of every website you visit, creating your own searchable personal web archive: How are screenshots searchable? They aren't plain text. You can't grep them.
- anonymoushn 4y ago
  The tool captures screenshots in addition to text.
  - doodles33 4y ago
    That seems awfully simillar to archive.org wayback machine. I do like to see all these archival projects though, they are certainly worthwhile.
    - lazyjeff 4y ago
      irchiver captures text on the page, and separately OCRs the screenshots (specifically, the screenshot from your viewport). So you can search just what was shown on the page, or what was in the page. Both techniques have pros and cons. While archive.org is fantastic, it can only capture pages that are both 1) publicly accessible (i.e. no social media content) that it happens to crawl, and 2) static content (you're out of luck if the content you want is loaded dynamically, or changes depending on user input).
      - pabs3 4y ago
        IIRC archive.org does save the JS and things it downloads, so you can replay them when you visit the archived site later.
        doodlesdev 4y ago
        I guess the difference in this case is that the JS on web archive relies on future browsers being backwards compatible, whereas irchiver relies on much less to stay timeless which is good. Although I don't think JavaScript will ever get a major update (as in breaking comparability) I believe relying on that is not a perfect way to archive web content. This kind of backwards compatibility breakage is something we have seen before with the deprecation of Adobe Flash and it could theoretically happen elsewhere on the web stack.
SoftTalker 4y ago
I think it's less a technological problem and more just that everyone who used to care about that site or its content no longer does. Or the company behind it has gone out of business -- who is going to maintain a website for a defunct organization, and why would anyone want to? There's no obligation for a person to maintain anything longer than he wants to do it. Putting a blog online is not a lifetime committment. Interests change, or you simply realize nobody much cares about your online musings, and you move on to other interests.
- gowld 4y ago
  But what can you do when you do care, to make your website as durable as a printed book?
  - hypertele-Xii 4y ago
    You could literally print it in a book. With links suffixed by a page number [915].
  - bombcar 4y ago
    Depends on if you want it to survive without you maintaining it. If so, something like a bog-standard Wordpress blog hosted by them might work until they decide they don't want to bother anymore. Otherwise, some setup using S3-as-a-website or GitHub pages may work, but those also depend on the company maintaining that service. If your entire website can be dropped into a ZIP file and served anywhere, you have a greater chance in it surviving, especially if the internet archive got a copy at some point. But if you die and nobody cares about the content, eventually it will disappear.
    - ElectricalUnion 4y ago
      > If your entire website can be dropped into a ZIP file and served anywhere, you have a greater chance in it surviving, especially if the internet archive got a copy at some point. Well, your entire website can be a zip: https://redbean.dev/ https://redbean.dev/
  - 4y ago
chubot 4y ago
Hm interesting, I read over your 7 guidelines [1] and I would say I agree 50%. So the most lightweight way to keep something up and running is to make it trivial to port to many hosting configurations by simplifying the toolchain needed to rehost it -- I agree with this, although I would use the words "standards" and multiple implementations. The linked article doesn't appear to emphasize this. 1. Return to vanilla HTML/CSS Again I feel the relevant issue is "standards", multiple implementations, and the fallback option of "old code" like GNU coreutils (i.e. taking advantage of the Lindy Effect). Not just just HTML/CSS (which certainly meet all of those criteria.) I thought about this when designing https://www.oilshell.org/ https://www.oilshell.org/ and the toolchain - The site started in Markdown but is now standardized on CommonMark [1], which has multiple implementations. So I don't see any reason to stick to HTML/CSS. - The tools are written in Python and shell [2]. Both languages have multiple implementations. (Ironically, Oil is a second implementation of bash! My bash scripts run under both bash and Oil.) - Python and shell rely on Unix, which is standardized (e.g. Linux and FreeBSD have a large common subset that can build my site). This is perhaps unconventional, but I avoided using languages that I don't know how to bootstrap like node.js (has a complex JIT and build process), Go (doesn't use libc) or Rust (complex bootstrap). On the other hand, C has multiple implementations, and Python and shell are written in C, and easy to compile. I'd say Lua also falls in this category, but node.js doesn't. I feel like this is at least 60% of the way to making a website that lasts 30 years. The other 40% is the domain name and hosting. This is a pretty a big site now, you can tar a lot of it up and browse it locally (well it's true you may have to rewrite some self links). Of course, this is my solution as a technical user. If you're trying to solve this problem for the general public, then that's much harder. [1] https://www.oilshell.org/blog/2018/02/14.html https://www.oilshell.org/blog/2018/02/14.html [2] https://www.oilshell.org/site.html https://www.oilshell.org/site.html 2. Don't minimize that HTML Mildly agree if only because it's useful to be able to read HTML to rewrite self links and so forth. Tools don't need it, but it's nice for humans. 3. Prefer one page over several If you're allowed to use Python and shell to automate stuff, then this isn't an issue. I suppose another risk is that people besides me might not understand how to maintain my code. But I don't think it needs to be maintained -- I think it will run forever on the basis of Unix, shell, and Python. Those technologies have "crossed the chasm", where again I think the jury is still out on others. 4. End all forms of hotlinking Yes, my site hosts all its own JS and CSS. 5. Stick with native fonts Yes, custom fonts have a higher chance of being unreadable in the future. I just use the browser's font preference to avoid this issue. It's more future proof and in keeping with the spirit of the web (semantic, not pixel perfect). 6. Obsessively compress your images Agree 7. Eliminate the broken URL risk I think too few people are using commodity shared hosting ... I've been meaning to write some blog posts about that. I use Dreamhost but NearlyFreeSpeech is basically the same idea. It's a Unix box and a web server that somebody else maintains. I absolutely don't care about CPUs, disk drives, even ipv4 vs. ipv6, and I've never had to. The key point is writing to an interface and not an implementation. Commodity shared hosting is a de facto standard. The main difference between a tarball of HTML and a shared hosting site is that say "index.html" is always respected as /, and a few other minor things. So I expect Heroku and similar platforms to come and go, but the de-facto standard of a shared hosting interface will stay forever. It's basically any Unix + any static web server, e.g. I think OpenBSD has a pretty good httpd that's like Apache/Nginx for all the relevant purposes. Github pages also qualifies. So I guess this is adding sort of a programmer's slant to it. To be honest it took me a long time to be fluent enough in Python and shell to make a decent website :) Markdown/CommonMark definitely helps too. I had of course made HTML before this, but it was the odd page here and there. Making a whole site does require some automation, and I agree that lots of common/popular tools and hosting platforms will rot very quickly. (and like you I've seen that happen multiple times in my life!) And I think what your guidelines might be missing is a guideline on how to make "progress". For example CommonMark being standardized is progress that has happened in the last 10 years. You don't want to be tied to the old forever. At some point you have to introduce new technologies, and the way to do that is once there's wide agreement on them and multiple implementations. (just like there's wide agreement on HTML) I think there is / can be progress in dynamic sites too, so you don't have to stick to static!
samsquire 4y ago
One of my ideas is called Wantsfiles at the root of domains. The Wantsfiles contains information about what you want and the price you're willing to pay. An order matching system matches your Wantsfiles.txt to Sellfiles.txt and transacts on your behalf. So I could host link to my tgz on my Wantsfile and offer $5 to host the tarball a month. There we go a perpetually hosted website. You could call it autohosting.
powersnail 4y ago
> system font stack that matches the default font to the operating system of your visitor If the list just matches the default font of the OS, is there a difference between using such a stack vs. not specifying a font? Wouldn't the browser naturally use the OS's default if font-family is unset?
8n4vidtmkvmk 4y ago
disk failure and os upgrades are a non-issue with the right technology stack.... but then you have other problems (more complicated setup)
shadowofneptune 4y ago
Interested personally in the font stack point. The system font stacks listed focus on font styles more than individual typefaces. If I want say, Bookman, is there any harm to long-term use to use a font stack tailored to that font?
- chipotle_coyote 4y ago
  There isn't, no, and there's no particular harm in self-hosted web fonts when it comes to long-term stability. Not only is it relatively unlikely that future browsers will deprecate web fonts but not anything else in current CSS (in which case there's a bigger issue than your fonts), it's even less likely that they'll do so in an entirely incompatible fashion. Assuming you've designed your font stack with decent fallbacks -- which you should -- then it's just like any other font stack, e.g., you may not be presenting in the typeface that you really want to, but nothing's going to break. ("Web fonts are okay, actually" is evidently the windmill I will keep tilting at on Hacker News.)

paulgb 4y ago

> you may attempt to archive it, but should you wish to avoid sadness down the line, you should accept now in your heart that all archives will eventually succumb to the sands of time. Enjoyed this.

bombcar 4y ago
You could etch your data and website onto copper plates and launch them into the depths of space; this will likely last near until the heat-death of the universe!
- asddubs 4y ago
  and simultaneously it will be lost immediately
  - saagarjha 4y ago
    And here we see the difference between available and accessible :)

jaytaylor 4y ago

> I’ve often thought about getting together with some friends to pay into a fund to house our websites after we die. I don’t think setting that up would be too hard — the math around insurance policies of this sort is quite simple — I mostly haven’t tried to set something like this up just since it’s a pretty morbid ask. But, if you’d be interested, maybe reach out to me? > Our ghosts could live forever, if we help each other. I love this idea and would gladly assist in the effort, let's set it up :)

cxr 4y ago
Previously <https://news.ycombinator.com/item?id=31047818 https://news.ycombinator.com/item?id=31047818> ----- From the NearlyFreeSpeech.Net FAQ <https://www.nearlyfreespeech.net/about/faq#Interest https://www.nearlyfreespeech.net/about/faq#Interest>: > Q: Do I get interest on my deposit? A: No[, but...] We periodically reevaluate this situation, because we think a web account that runs forever purely off of its own interest is a pretty cool idea. NFSNet also has an interesting part in their FAQ in response to the question If I think services you host are currently unavailable due to lack of funds; is there anything I can do?, they outline a process whereby third-parties can fund a hosted service by creating an account themselves, depositing funds into their own account (NFSNet services are prepaid instead of billed after the fact), and then submitting a manual (but free) request to transfer those funds to the original accountholder based on the service's domain name. I've always thought this was interesting because in theory someone could set up a community, disappear, and then the community could step up to keep it funded long enough for the person to get out of the hospital/be rescued at sea/etc, so long as the infrastructure is solid enough to remain operational without being attended to (not vulnerable to exploits, etc.) They've also got a policy where if the member who operates the service is a willing participant, they can publish their NearlyFreeSpeech.Net account ID and have donors add funds to cover 100% of service costs via automated transfers. <https://www.nearlyfreespeech.net/about/faq#Lifeboat https://www.nearlyfreespeech.net/about/faq#Lifeboat>
floren 4y ago
the year is 2122 and all the "good" (short, memorable) DNS names are owned by ghosts. in the grim dark future, there is only joe_smith_from_minneapolis_born_2055.com

deleted 4y ago

[deleted]

doodles33 4y ago

Unstoppable domains solve this problem by making domain purchases permanent and stored on a decentralized blockchain - although that brings some problems of it's own - and IPFS solves that by not requiring that a central server stays online to serve that content, although this does require that _someone_ be insterested in serving the website at all.

rchaud 4y ago
This article isn't about websites going offline. It's about websites dying of 'natural causes', meaning the author or site manager lost interest in updating and maintaining the site. There's much more to the soul of a website than the datacenter where it's hosted. I doubt if the handful of mirror.xyz 'decentralized' sites I see popping up will still exist in 5 years' time.
Dan_Sylveste 4y ago
>blockchain >solves this problem Sure. Absolutely. Probably cures cancer too.
- doodlesdev 4y ago
  Show me where I can buy a permanent domain directly from ICANN and be sure that it will be stored forever without ever relying on a single company or system to keep working and I will suggest it over any blockchain solution immediately. The problem is that it does not exist and it probably never will, and thus this is the next big thing. Also relevant LOL (although you're right when it comes to blockchain and cancer, this is nonsense, I just though it was funny): https://www.independent.co.uk/news/business/business-reporter/blockchain-startup-cancer-research-revolutionising-b1920550.html https://www.independent.co.uk/news/business/business-reporte...

spc476 4y ago

It comes down to the person running the website has to care. That's it. It doesn't matter how simple it is if the person doesn't care. In my own case, I've been running my own website for 24 years now [1]. The URLs I started out with have remained the same (although some have gone, and yes, I return 410 for those) and the technology hasn't changed much either (it was Apache 24 years ago, it's still Apache today; my blog engine [2] was a C-based CGI program, and it's still a C-based CGI program. The rest of the site is static, and there's no Javascript (except for one page). I can see it lasting at least six more years, and probably more. But I care. [1] Started out on a physical server (an AMD 586) and a few years later on a virtual server. [2] https://github.com/spc476/mod_blog https://github.com/spc476/mod_blog

remus 4y ago
> It comes down to the person running the website has to care. Personally I think it is a little more nuanced, in particular I think the relationship between how much someone cares and how much effort is required to keep the website online is what matters. If your website is super simple you don't need to care about it very much (though you do need to care at least a little bit). On the other hand, if everyone who works at google suddenly quit tomorrow because they didn't care the stack of cards would fall over very quickly because it's a lot of work maintaining millions of servers.

sparcpile 4y ago

There have been some attempts to capture sites that became the ghosts or disappeared completely. During the dotcom bubble through 2008, Steve Baldwin(co-author of Netslaves) had that as a side project. https://www.disobey.com/ghostsites/ https://www.disobey.com/ghostsites/ Our Incredible Journey still does this, with more snark and humor. https://ourincrediblejourney.tumblr.com/ https://ourincrediblejourney.tumblr.com/

fleddr 4y ago

I'd like to call out the somewhat related problem of website rot. Meaning, the websites is online, it once worked perfectly, but becomes increasingly dysfunctional due to technical deprecations. The soft obligation to use HTTPS these days has deranked old HTTP-only websites in search, making them hard to find. These websites are also "defaced" with browser warnings or some subresources may not load at all. Embedded maps no longer work, since Google regularly breaks their API. Facebook login or other FB plugins no longer work, since it needs a yearly checkup of your account and there's the new requirement of needing to have a privacy policy. Those are just some examples of websites partially breaking through no fault of its creator, if you'd agree that the web should be backwards-compatible.

asddubs 4y ago
also, even if those older http sites get a certificate, any embedded scripts that point at http URLs, even if those URLs are also available on https, will not load and break. Especially hard to fix if you have user generated HTML on there. Same for http download links from https websites, will not work anymore. anything that used cookies on embedded resources will also be broken because of the missing samesite header (same for third party cookies obviously) if google really goes through with removing alert/prompt/etc from their browser like they said they were planning to a while back, so so many things will break
- EamonnMR 4y ago
  Notification prompt is 10x more annoying than alert ever was.
  - deleted 4y ago
    [deleted]
- fleddr 4y ago
  I'm uniquely bothered by this problem as I visit many such dysfunctional sites. I'm active in the (hobbyist) field of documenting species. There's thousands upon thousands of websites created by amateurs containing unique niche content. For example, somebody might have made it their lifelong hobby to document every species of bee in their territory. It's a fragmented mess of incompetently produced websites, but I find it incredibly charming and in the spirit of the original web. Above all, it is their content that has lasting value. The people behind it are good, generous. That's why it makes me so angry when their work is cast aside like this. Things not just technically breaking, in many cases simply disappearing altogether from search results.

nonrandomstring 4y ago

A very nice read with some poignant thoughts and quotes on digital impermanence. Life on the Internet is nasty, brutish and short.

sshine 4y ago

My first domain “expired” in an unexpected way after 18 years. I got a .eu.org because I believed that eu.org would be more stable than a commercial provider. I used the same not-for-profit DNS provider until they were commercially acquired and the parent company shut down the old nameservers. Now I’m locked out: eu.org does not respond to inquiries for switching nameservers, and my account predates the auth system. While my phone number is the same, auth reset does not work with phone. It would have been fun to retain the same domain forever, but stuff breaks, people die, and things crumble.

rschachte 4y ago

This really makes me want to redesign my site with minimal external dependencies and clear documentation.

foxhop 4y ago

I personally sunset a handful of websites this year. only kept a handful to try to dedicate time to. writing open source the new site is called Make Post Sell (https://www.makepostsell.com https://www.makepostsell.com) hoping to restore a bunch of content as shops in this multitenant SaaS.

langsoul-com 4y ago

Sad and depressing when things die, especially without notice, but that's life. I have a blog, https://langsoul.com https://langsoul.com, that could die anytime. After all, sites are a lot of work and only a few make anything worthwhile to continue. Not to mention, if I were to suddenly get ill, what then? Do I write into my will to launch a farewell blog post? I think there was this internet cult that maintained their site for over 20 years from the leaders death. It required alive cult members to keep it alive. Unfortunately I don't have cult members, nor funds to start a trust to keep the site going.

kaeruct 4y ago
I think the cult you are referring to is Heaven's Gate: https://www.heavensgate.com/ https://www.heavensgate.com/

the_origami_fox 4y ago

The automated url # fragments on highlights for this website is a cool but weird feature