News for hackers. Stuff that matters.
Re:Linux Performance by konschubert on Friday January 27, 2017 @04:26AM (#13498688)
Because of copyright issues.

People like traffic to their actual domain, because it often means better search engine ranking in the future. On top of that, some websites serve ads, which means that traffic is proportional to revenue.

Re:Linux Performance by Qwertious on Friday January 27, 2017 @07:42AM (#13499402)
Ah, don't you just love it when there's a simple technical problem with a simple and valid technical solution, but there's a legal problem that stops it dead?

Well, legal and whatever domain the "you viewed the ads but they werent tracked so we don't get money" problem falls into. Stupid artificial barriers which are there because they solve an economic problem, that wouldn't exist in a perfect world. Game theory, maybe.

Re:Linux Performance by quickConclusion on Friday January 27, 2017 @10:38AM (#13500377)
This reminds me of the bird complaining: "if only there was no air slowing me down, I would fly a lot faster".
Re:Linux Performance by leephillips on Friday January 27, 2017 @08:28AM (#13499622)
I have the technical ability to steal lots of stuff. But yes, there are legal (and moral) obstacles that keep me from doing it.
Re:Linux Performance by mnutt on Friday January 27, 2017 @10:56AM (#13500491)
The solution described above is pretty much what Google's AMP does. It turns out that a lot of people don't like AMP because they see it as a monopolistic way of keeping users in Google's walled garden. HN doesn't quite have a monopoly on startup/tech news, but I think the same reasons apply.
Re:Linux Performance by sp332 on Friday January 27, 2017 @11:27AM (#13500686)
Sites opt-in to AMP, so copyright is less of an issue there.
Re:Linux Performance by overcast on Friday January 27, 2017 @08:58AM (#13499788)
You'd be OK with putting a ton of work into something, and then having it cached/ripoffed somewhere else?
Re:Linux Performance by fao_ on Friday January 27, 2017 @09:10AM (#13499853)
Google and the Internet Archive already caches it. Also, if your work goes down for whatever (perhaps legal) reason, you know that people can still benefit from it.

Caching it for when a site is overloaded is not ripping it off, just like sending copies of works to the British Library for archival purposes is not ripping the original work off.

Re:Linux Performance by justinhensley on Friday January 27, 2017 @11:03AM (#13500536)
The trick in this solution is deciding when to flip the switch for the cached version.

Perhaps a simple GET to the URL ever 60s. If you receive 5 non-200 responses in a row, then the HN link points to the archive.is version. Same method in reverse for bringing it back.

Re:Linux Performance by fao_ on Friday January 27, 2017 @12:18PM (#13501060)
That sounds like it would DDoS the site. Even better: monitor the comments for "site is down", or just provide a link to google's cached version as a button (Even better than the 'web' link we have at the moment).
Re:Linux Performance by justinsaccount on Friday January 27, 2017 @06:36PM (#13503762)
> That sounds like it would DDoS the site

How would one request per minute from a single server DoS the site, let alone DDoS it?

Re:Linux Performance by otterley on Friday January 27, 2017 @09:24AM (#13499932)
Both of those sites can be instructed not to store copies of your pages for their caches or archives; and they will dutifully follow your instructions.

Also, the library analogy doesn't work in copyright law. Copyright protects the act of copying, not the act of transferring an already-authorized copy of a work to someone else.

Re:Linux Performance by mac01021 on Friday January 27, 2017 @04:54AM (#13498795)
Could we pull up the real page from the actual domain in a full-window iframe and then replace it with the cached version if it fails to load?
Re:Linux Performance by majewsky on Friday January 27, 2017 @05:48AM (#13498989)
That will fail for a lot of websites since X-Frame-Options is becoming more common: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-...