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

171–180 of 458 posts

Re: This Page is Designed to Last

#171

Post by dbtx »

gwern wrote: post #144
dbtx wrote: post #134

Earlier quoted context omitted.

I have this problem. Some bits of history are gone except from old backups of profile directories and profiles where I've already set places.history.expiration.max_pages to some absurdly high number. I need to do a handful of experiments to see exactly how this interacts with Sync, even though I've (foolishly) already synced the important profiles. I'd hope that the cloud copies of the places database just keeps grow…

Even if you set the setting, how can you be sure that it won't be reset on an upgrade or that you'll remember to set it if you need a new profile (perhaps your old one becomes buggy, crufty, corrupt, or all three)? I thought I had all my history retained until one day I couldn't find a website I knew I had visited years ago, and took a closer look at my history and was very unpleasantly surprised... What happened? I'…

I can't be sure. When I say 'combine them all offline', I mean using something like [1] which refuses to do anything for me because the Waterfox database version is a rather old Firefox version, and that seems to expect all the db's versions to be up-to-date and equal, which seems pointless. #include was my next step-- only I don't walk very well, so that didn't happen "yet". Or I'm lazy, or distracted, or depressed, or something. When I recently got tired of realizing a thing was on the other machine, I bit the bullet and synced them, if only to see how well that worked.

Anyway, thanks for the guide.

[1] https://github.com/crazy-max/firefox-history-merger

Re: This Page is Designed to Last

#172

Post by Thorrez »

heavyset_go wrote: post #150
Avamander wrote: post #116

Earlier quoted context omitted.

I think Chrome(ium) does as well. Very annoying tbh.

Chrome was the first browser I encountered that deletes history without being instructed to.

It looks like Firefox has been doing it since 2010[1]. I wonder how long Chrome has been doing it, since launch, 2008? Here's a Chrome bug discussing it[2].

[1] https://web.archive.org/web/20151229082536/http://blog.bonar...

[2] https://bugs.chromium.org/p/chromium/issues/detail?id=500239

Re: This Page is Designed to Last

#173

Post by ssivark »

jtbayly wrote: post #66
carlosdp wrote: post #52

I was expecting the solution to be mirror your generated pages on IPFS ( https://ipfs.io ), so they just don't go away at all (as long as someone has them pinned). The proposed solution set seems extremely convoluted and don't actually solve the issue.

That’s quite the caveat, and speaking as somebody who has attempted it, you’ve introduced quite a bit of complexity. The whole point is that complexity militates against keeping it online. Keeping it simple, the author’s theory seems to go, is the single most effective way to make something likely to be able to be available long term. I think he’s probably right.

You might keep the content format mighty simple, but keep in mind that the hosting and delivery mechanism consisting of http/html are extremely demanding. In particular, your website's availability is fundamentally limited by the uptime of your host machine (which you are only leasing) and its HTTP server and network. If you forget to renew the lease on your host machine, or there is some mishap by the service provider, your website will vanish without a trace -- even if it happened to have a high rate of visitors.

Re: This Page is Designed to Last

#174

Post by T-hawk »

zbentley wrote: post #77
fyp wrote: post #69

I don't think there's any good solution to the dead link problem. For example there are 11 links in this article: https://jeffhuang.com/ https://gomakethings.com/the-web-is-not-dying/ https://archivebox.io/ https://webmasters.stackexchange.com/questions/25315/hotlinking-what-is-it-and-why-shouldnt-people-do-it https://goaccess.io/ https://victorzhou.com/blog/minify-svgs/ https://evilmartians.com/chronicles/images-don…

Put a wayback machine link in parentheses/superscript after every link in the page?

Of course, you can't know how long the Wayback Machine itself will continue to exist, either.

Re: This Page is Designed to Last

#175

Post by hk__2 »

ryanfox wrote: post #140
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’ve been building an application to do this, except for everything on your computer! It’s called APSE[0], short for A Personal Search Engine. [0] https://apse.io

Having to pay $15/month ($180/yr!) to be able to search stuff on my own computer for years seems awfully expensive. I'd rather depend on some simple open-source piece of software that I can understand and maintain if necessary.

Re: This Page is Designed to Last

#176

Post by falcolas »

bepvte wrote: post #59
falcolas wrote: post #22

Earlier quoted context omitted.

Or not bitrot, but ever-changing browser APIs.

When was the last browser change that broke things like simple news websites????

The phrases "simple" and "news websites" don't combine well these days. Even the NPR website downloads 13.2 MB of content over 91 individual requests, and takes just over 3.6 seconds to load (6.5 to finish).

- CSS Stylesheets: 3

- Animated gifs: 1

- Individual JS files: 11 (around 2MB of JS decompressed (but not un-minimized))

- Asynchronous Requests: 14 (and counting)

And that's with uBlock Origin blocking 12 different ad requests.

That's not simple in any form. So, the possibility of something on this page breaking? High. There's a lot of surface area for things to break over time. And that's not counting what happens when the NPR's internal APIs change for those asynchronous requests.

Re: This Page is Designed to Last

#177

Post by nichochar »

Wonderful write-up. In particular, I appreciated how actionable this was. As a backend developer that loves the web but isn't part of the whole frontend mania, I completely relate, yet still learned a couple things that I can apply easily.

Re: This Page is Designed to Last

#178

Post by hk__2 »

juststeve wrote: post #101
notatoad wrote: post #79

Earlier quoted context omitted.

I think the Stack Overflow guidelines have "solved" this problem in about the cleanest way currently possible: expect links to die, and include the relevant information in your answer. If the link still works when it gets clicked on that's a bonus, but it shouldn't need to be available for the content you're reading to be understandable.

And there's also the HTTP 300 codes if content has been moved.

These work only if you move stuff around on the same website. If you switch domains you can't just ask the new domain owner to redirect requests to your new website.

Re: This Page is Designed to Last

#179

Post by rodw »

I think this article is excellent, but one small nit: isn't it contradictory to say don't minimize HTML but do minimize SVG?

The justification in the HTML case is that "view source is good" and "it's compressed over the wire anyway". Don't those arguments apply equally (or nearly equally) well to SVG?

Post reply on HN