Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

This Page is Designed to Last

jeffhuang.com

Post reply on HN
Print view View original

241–250 of 458 posts

Re: This Page is Designed to Last

#241

Post by rimliu »

mark242 wrote: post #14

I fundamentally agree with the principle -- that pages should be designed to survive a long time -- however the steps the author lays out I completely disagree with. "The more libraries incorporated into the website, the more fragile it becomes" is just fundamentally untrue in a world where you're self-hosting all of your scripts. "Prefer one page over several" is diametrically opposed to the hypertext model. Please…

  > "Prefer one page over several" is diametrically opposed to
  > the hypertext model.
No, it is not. No need to split the article into five pages when it can be on one. Unless you want to inflate your clicks, that is.

Re: This Page is Designed to Last

#242

Post by kortilla »

1f60c wrote: post #142
einpoklum wrote: post #58

Make sure that archive.org - the Internet Archive - catches your website in "The Wayback Machine". Catering to that is a pretty good strategy for archiving for at least the next couple of decades, considering that institute's staying power. And on that note - consider donating to them.

The Internet Archive is a fantastic resource. And right now, they happen to match every donation two to one (so $5 becomes $5 + 2 * $5 = $15 dollars!)

How do they match a donation to themselves?

Re: This Page is Designed to Last

#243

Post by pjmlp »

shasheene wrote: post #7

There's no reason why a web browser bookmark action doesn't automatically create a WARC (web archive) format. Heck, with the cost of storage so low, recording every webpage you ever visit in searchable format is also very realistic. Imagine having the last 30 years of web browsing history saved on your local machine. This would especially be useful when in research mode and deep diving a topic. [1] https://github.com…

I always save pages instead of only bookmarking them.

Most websites I used to visit during demoscene high days, are now gone.

Re: This Page is Designed to Last

#245

Post by jakeogh »

shasheene wrote: post #7

There's no reason why a web browser bookmark action doesn't automatically create a WARC (web archive) format. Heck, with the cost of storage so low, recording every webpage you ever visit in searchable format is also very realistic. Imagine having the last 30 years of web browsing history saved on your local machine. This would especially be useful when in research mode and deep diving a topic. [1] https://github.com…

Personal wayback machins should be standard computing kit. I have had one since around 2013. Very bare bones demo: https://bpaste.net/show/3FBH6 it does much more than that. file:// is supported for example, so you can recursively import a folder tree, and re-export it later if you wanted to.

Or in some random script: "from iridb import iri_index" "data = iri_index.get('https://some/url')" I'm skipping lots, you can ref by hash, url, url+timestamp. It hands back a fh, you dont know if the data you are reffing even fits in memory. Extensive caching, all the iri/url quirks, punycode, PSL etc.

Some random pdf in ~/Downloads, "import doc.pdf" and dmenu pops up, you type a tag, hit enter and the pdf disappears into the hash tree, tagged, and you never need to remember where you put it. Later on you only need to remember part of the tag, and a tag is just a sequence of unicode words.

Chunks are on my github (jakeogh/uhashfs, it's heka-outdated dont use it yet), I'll be posting the full thing sometime soonish.

Re: This Page is Designed to Last

#246

Post by perlgeek »

dirktheman wrote: post #231

This is somewhat of a concern to me: I can imagine a distant future where one of the great mysteries would be the rise and fall of literacy, since almost no written communication is left and computers and the internet are long forgotten, obsolete technology. "In the beginning of the 21st century people suddenly stopped reading and writing. In the short timespan of only a few decades almost all form of written communi…

Even if you count only printed books, the number of books published by year is still rising in the US: https://www.theifod.com/how-many-new-books-are-published-eac...

It seems that the time spent reading decreases slightly.

Re: This Page is Designed to Last

#247

Post by masswerk »

tjchear wrote: post #119
zzo38computer wrote: post #102

Earlier quoted context omitted.

O, yes, we forgot that. Footnotes, lists, and tables, are good too.

What about img? It's not inconceivable that an article or a reference manual should have images of some kind.

I guess, the Netscape Navigator 1.0 specs (tables and forms, but before frames and JS) are quite what we may want (with the possible exception of the font tag and, certainly, without the blink tag), augmented by some footnote/reference tags and a reduced set of CSS.

Re: This Page is Designed to Last

#248

Post by kortilla »

juststeve wrote: post #114

Well, a new HTTP status code or header could be created for sites that are closing, then if a browser navigates to the website, it could prompt the user for action? e.g. update bookmark, archive, or email site admin (if on the hosting side).

Most sites close quite abruptly (domain didn’t renew, web server crashed, site was “modernized”, etc). Most link rot is due to the fact that people aren’t actively trying to keep things alive. An HTTP code won’t help with that.

Re: This Page is Designed to Last

#249

Post by sergimansilla »

imhoguy wrote: post #233

We need a common distributed storage protocol - kind of Bit Torrent for web pages. Dead simple in use and built into (every) browser transparently. Anytime a public page is visited/bookmarked then it is preserved in a swarm of caches until the last seeder dies.

Sounds exactly like what the Dat protocol and the Beaker Browser https://www.beakerbrowser.com/ offer.

Re: This Page is Designed to Last

#250

Post by masswerk »

zzo38computer wrote: post #122
tjchear wrote: post #119

Earlier quoted context omitted.

What about img? It's not inconceivable that an article or a reference manual should have images of some kind.

You could just link to them I think, possibly with a hint to specify inlining; the client decides whether to obey that hint or to ignore that hint. (This would be done the same whether the picture is part of the document or is a separate file, I should think. It makes many considerations easier to work with.)

This is actually how it worked in the beginning. Browsers also had an "display images" toggle button in the main control bar.
Post reply on HN