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

"Unknown or expired link." - Why?

google.com

Post reply on HN
Print view View original

71–80 of 142 posts

Re: "Unknown or expired link." - Why?

#71

Post by apgwoz »

piinbinary wrote: post #16
jgrahamc wrote: post #13

It's an artefact of the way in which news.arc (actually srv.arc) uses functions for links. Here's the key code: (= dead-msg* "\nUnknown or expired link.") (defop-raw x (str req) (w/stdout str (aif (fns* (sym (arg req "fnid"))) (it req) (pr dead-msg*)))) If the fnid (function ID) isn't in the fns* list then you get the dead message. (def flink (f) (string fnurl* "?fnid=" (fnid (fn (req) (prn) (f req))))) In many place…

I would be interested to know how much state is in those closures. If it is less than 200 or so bytes, it would not be impractical to encode it (b64) in the url for the next page (rather than a reference to the state).

Racket has support for serialization of closures and continuations, which it's web server makes extensive use of. It seems like it'd be possible to expose the relevant functions to make that happen, though I have no idea how large the closures actually are once serialized.

Re: "Unknown or expired link." - Why?

#72

Post by bkmartin »

pg wrote: post #44
wvenable wrote: post #32

Earlier quoted context omitted.

Or it's so ingrained in the architecture of the software that a fix isn't possible without completely rewriting it and changing the entire design philosophy.

Sort of yes, sort of no. It's a rapid prototyping technique. Essentially you fix it case by case, by taking individual bits of code that use this technique and replacing them with the uglier and less flexible but more efficient alternative of a hard-coded url.

Paul, I really do not mean any disrespect here because you are truly a class act and first rate player in the start up world. You are also a great hacker that loves to push the limits. You've created an amazing community here that I have been able to learn a ton from.

I have to ask, and I'll probably get down voted to hell because I'm naive or something, but what is so elegant about a coding technique that breaks under normal usage conditions? If I put out a customer facing piece of code, especially after 4 years, wouldn't it make sense to use an "uglier and less flexible but more efficient alternative" that doesn't break?

I understand your previous explanations of why this happens and of rapid prototyping etc. But at what point does the architecture actually get changed to eliminate this bug?

Re: "Unknown or expired link." - Why?

#73

Post by dasil003 »

gnaritas wrote: post #59
dasil003 wrote: post #39

Earlier quoted context omitted.

> If it's running out of memory to store the closures it would run out of memory to store the interaction state. Not necessarily. The way I would approach this is to keep the link cache in memory, but have the links contain the minimal necessary state to reconstruct the link from disk-based storage in the case where the cache is gone. That gives the same excellent median performance without any breakage.

> The way I would approach this is to keep the link cache in memory, but have the links contain the minimal necessary state to reconstruct the link from disk-based storage in the case where the cache is gone. It's not a cache, and you clearly don't understand the issue. These are callbacks to closures, embedding the state in the URL is what they attempt to avoid because doing that is tedious .

Sorry, bad choice of words. I was just shooting from the hip here in response to the parent that suggests you can't both keep something in RAM for the majority of cases and still make it robust.

The fact that embedding state in the URL is tedious is neither here nor there, but in any case it's a pretty garbage excuse. You know what's more tedious than writing code to pass a few integers around in links? Thousands of people losing carefully written paragraphs of enlightened prose on a regular basis. In fact the more carefully considered, the more likely the text is to be lost. If it took 24 hours or even 12 hours for links to expire then maybe you could justify the approach, but it seems to be well under an hour on average before a given closure is purged. This site seems hardly so complex as to be gaining much from a pure continuation approach, and if you can't ease this problem in a lisp then are all of us building services for non-hackers doomed to life of bitter tedium?

Re: "Unknown or expired link." - Why?

#74

Post by jrockway »

smackfu wrote: post #41
Tichy wrote: post #20

Earlier quoted context omitted.

Hacker News is open source, so it seems as if nobody is interested in fixing it. Or are there fixes and pg has rejected them?

To be honest, if it was written in a more popular language, there would probably be a fix.

I'm also pretty sure that the downloadable news.arc is not the exact code running on this site.

Re: "Unknown or expired link." - Why?

#75

Post by mrb »

adamrmcd wrote: post #68

Silly question, but, if HN is purportedly open-source where can I download the source code?

  1. http://arclanguage.org/install
  2. Extract arc3.tar
  3. See news.arc
However, AFAIK pg forked from the latest public news.arc, so the current Hacker News platform is not open source.

Re: "Unknown or expired link." - Why?

#76

Post by wvenable »

gnaritas wrote: post #67
wvenable wrote: post #65

Earlier quoted context omitted.

No, I understand the issue. But you're presupposing a specific implementation here. If you were just designing this in, for example, PHP then you'd just need one piece of state: the page # (for more...) or the parent comment id (for the comment) and so on. The real issue is that there's a whole bunch of saved state on the server for operations that could be (and should be) completely stateless.

No, the issue is time, specifically, pg's time; using callbacks takes less programmer time than manually building every URL statelessly. Yes, it could be done another way, but it wouldn't exist at all if he'd had to do that for every link because it'd have taken too much of his time.

What is it about Arc or the architecture of HN that makes callbacks so easy and stateless URLs so hard? I've written a forum in under 3 hours the "traditional" way in PHP. I find the stateless concept a lot simpler in general. None of these links should require any server state at all.

Re: "Unknown or expired link." - Why?

#77

Post by tptacek »

pg wrote: post #64
biot wrote: post #54

Earlier quoted context omitted.

Over the last week the home page appears to be cached longer than the arc timeout, no doubt due to the spike in traffic. As I throw away cookies when closing the browser, I need to login daily. It's been impossible to login from the HN home page because of this. Refreshing the page doesn't help; I've had to click through to a story to be able to login. You should hard-code that one too.

The problem there is that we switched to a new deliberately slow hashing function for passwords. Edit: I investigated further, and actually you're right, the problem was due to caching. It should be better now because we're not caching for as long. But I will work on making login links not use closures.

What'd you go with, and how much of a pain was it to get working in Arc?

I ask because I'd love to be able to make a claim like "even Hacker News, which is written in a Lisp, managed to implement a modern password hash".

Re: "Unknown or expired link." - Why?

#80

Post by stickfigure »

Tichy wrote: post #20
smackfu wrote: post #15

The first complaints are from 1575 days (over 4 years) ago, including about the more button breaking, so I am guessing pg has no interest in fixing it.

Hacker News is open source, so it seems as if nobody is interested in fixing it. Or are there fixes and pg has rejected them?

Hacker News is open source

Is this true? If so, where can I find the code?

Post reply on HN