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

Forget flat design. Design in a 1995 style for full impact

lingscars.com

Post reply on HN
Print view View original

61–70 of 100 posts

Re: Forget flat design. Design in a 1995 style for full impact

#61

Post by laumars »

mattmanser wrote: post #54
laumars wrote: post #49

Earlier quoted context omitted.

Sadly Lin is now blaming Hacker News for hacking her site with the intention of taking it offline - which is just retarded as: a) we're legitimate curious visitors (albeit not maybe not customers - but who's to say that some of us wouldn't be converted from window shoppers to buyers - that's kind of the point of websites after all) and b) her webserver set up to only allow for 500 concurrent connections. Which is jus…

To be fair, the trouble with a name like Hacker News is that the uninitiated don't know it's for programmers and entrepreneurs. And I never get people having a go about stuff like concurrent connections at amateurs, that's completely our fault. Why can't web servers stop acting like babies that need constant attention with some sort of mystical knowledge to stop them falling over when something new happens? Why is ou…

Because hardware varies significantly. What's optimal on some systems is sub-par on others. Thus it takes a sysadmin to set up the server optimally.

Also, most web farms these days are built with multiple nodes that serve ~500 concurrent requests (even multiple VMs performs better than one instance of Linux on the same hardware running bare metal) and load distributed across each node. So a 500 concurrent default is entirely reasonable.

However all of the above is moot because she's running Apache on Debian - which does not default to 500 concurrent connections. That is a setting she's applied herself (or paid someone to set up).

And for the record, I'm all for amateurs rolling their own web servers - I'm certainly not elitist in that regard. But the fact remains that some of this stuff is rather technical, so complaining that it isn't easy is like saying cars should be self-servicing and that we shouldn't need garages and engineers.

Re: Forget flat design. Design in a 1995 style for full impact

#62

Post by vidarh »

laumars wrote: post #61
mattmanser wrote: post #54

Earlier quoted context omitted.

To be fair, the trouble with a name like Hacker News is that the uninitiated don't know it's for programmers and entrepreneurs. And I never get people having a go about stuff like concurrent connections at amateurs, that's completely our fault. Why can't web servers stop acting like babies that need constant attention with some sort of mystical knowledge to stop them falling over when something new happens? Why is ou…

Because hardware varies significantly. What's optimal on some systems is sub-par on others. Thus it takes a sysadmin to set up the server optimally. Also, most web farms these days are built with multiple nodes that serve ~500 concurrent requests (even multiple VMs performs better than one instance of Linux on the same hardware running bare metal) and load distributed across each node. So a 500 concurrent default is…

But a lot of these limits could default to automatically adjust. Serving much more than 500 concurrent requests for static content is rather trivial on most remotely modern hardware if the software is designed for it.

And reasonable queuing behaviour for sites have been possible for well over a decade. E.g. Eddie is 14 years old (http://eddie.sourceforge.net/txt/WP_1.0.html - see the "Quality of Service" section in particular - while Eddie is intended for clustered setups, there are many situations where this approach is amenable even to single server setups) and provides a solution (amongst others) where if the system can't handle the incoming traffic, rather than serving up the main page and choking on assets and failing miserably in serving up anything to anyone, you can serve up a small light "queue" page and grant access to the full site as and when capacity allows.

There are certainly plenty of things that truly does require a lot of technical skill to sort out, but a lot of software have poor defaults and lacks relatively straightforward features that would make the out of the box experience tremendously much better for less technical users.

Re: Forget flat design. Design in a 1995 style for full impact

#63

Post by laumars »

vidarh wrote: post #62
laumars wrote: post #61

Earlier quoted context omitted.

Because hardware varies significantly. What's optimal on some systems is sub-par on others. Thus it takes a sysadmin to set up the server optimally. Also, most web farms these days are built with multiple nodes that serve ~500 concurrent requests (even multiple VMs performs better than one instance of Linux on the same hardware running bare metal) and load distributed across each node. So a 500 concurrent default is…

But a lot of these limits could default to automatically adjust. Serving much more than 500 concurrent requests for static content is rather trivial on most remotely modern hardware if the software is designed for it. And reasonable queuing behaviour for sites have been possible for well over a decade. E.g. Eddie is 14 years old ( http://eddie.sourceforge.net/txt/WP_1.0.html - see the "Quality of Service" section in…

> But a lot of these limits could default to automatically adjust.

No. I do not want my server hardware attempting to guess optimal performance. I'd rather do that myself and know that it's set up correctly.

You wouldn't buy a sports car then moan that it's a manual gear box and lacks cruise control. Just as you wouldn't run an automated tool to master a studio recording before sending the master off for CD pressing. If people want guesswork then don't install professional tools (sane defaults are another issue though - I just object to pro-tools applying guesswork).

> And reasonable queuing behaviour for sites have been possible for well over a decade.

Apache does queue TCP/IP connection requests. "Sorry pages" should be configured on the load balancer rather than HTTP daemon as the whole point of them is to offload the work from the saturated nodes.

> There are certainly plenty of things that truly does require a lot of technical skill to sort out, but a lot of software have poor defaults and lacks relatively straightforward features that would make the out of the box experience tremendously much better for less technical users.

A lot of software does have crap defaults, like how Apache publishes it's version number and the underlying OS by default (the ServerTokens directive). However the examples given (concurrent connections and sorry pages) are not wrong (her concurrent connections is set to a non-default value and sorry pages don't belong on the HTTP daemon because they're supposed to bypass the load)

Re: Forget flat design. Design in a 1995 style for full impact

#64

Post by mAritz »

ZirconCode wrote: post #48
retube wrote: post #22

Earlier quoted context omitted.

A quick glance seems to indicate they break every rule of modern web design. It's almost too perfect. Like the spec was to to do the exact oposite of what you're supposed to....

It's titled "New Page 1". It's just so perfect.

The title of the mainframe page is "Fabricland fabric shops throughout South of England and mail order service". So, that's good and informative.

Re: Forget flat design. Design in a 1995 style for full impact

#65

Post by dllthomas »

laumars wrote: post #63
vidarh wrote: post #62

Earlier quoted context omitted.

But a lot of these limits could default to automatically adjust. Serving much more than 500 concurrent requests for static content is rather trivial on most remotely modern hardware if the software is designed for it. And reasonable queuing behaviour for sites have been possible for well over a decade. E.g. Eddie is 14 years old ( http://eddie.sourceforge.net/txt/WP_1.0.html - see the "Quality of Service" section in…

> But a lot of these limits could default to automatically adjust. No. I do not want my server hardware attempting to guess optimal performance. I'd rather do that myself and know that it's set up correctly. You wouldn't buy a sports car then moan that it's a manual gear box and lacks cruise control. Just as you wouldn't run an automated tool to master a studio recording before sending the master off for CD pressing.…

"No. I do not want my server hardware attempting to guess optimal performance. I'd rather do that myself and know that it's set up correctly."

Parent said "default to automatically adjust" - and I see no reason it shouldn't. You could still manually tweak all you want.

Re: Forget flat design. Design in a 1995 style for full impact

#66

Post by laumars »

dllthomas wrote: post #65
laumars wrote: post #63

Earlier quoted context omitted.

> But a lot of these limits could default to automatically adjust. No. I do not want my server hardware attempting to guess optimal performance. I'd rather do that myself and know that it's set up correctly. You wouldn't buy a sports car then moan that it's a manual gear box and lacks cruise control. Just as you wouldn't run an automated tool to master a studio recording before sending the master off for CD pressing.…

"No. I do not want my server hardware attempting to guess optimal performance. I'd rather do that myself and know that it's set up correctly." Parent said " default to automatically adjust" - and I see no reason it shouldn't. You could still manually tweak all you want.

The automatic adjust option would be a crap default though. Just the process of Apache checking whether a page is static or dynamic means accepting the connection to begin with - by which point it would be too late to forward the connection to a sorry page if content is dynamic. It would also mean that connections end up stacking at a far greater rate as Apache is required to open each and every request just to identify teh requested file. The whole process would just break servers that are already under heavy load and serves no purpose what-so-ever on servers that aren't stressed. And since this whole argument is about how software should ship sane defaults, Apache is definitely doing the right thing by not including such nonsense by default.

Believe me when I say that I'd welcome such a routine if it was practical as it would save me weeks of my life from load testing and fine tuning. But it just wouldn't work in practice.

Re: Forget flat design. Design in a 1995 style for full impact

#67

Post by kephra »

dualogy wrote: post #8

Aaaand it's down. lingscars.com will never understood why a scary DDoS from a "Hacker site" hit them..

"WAH! My site is under heavy load! I am working very hard to bring it back soon!"

thats a progress to the prior cookie and redirect hell.

Re: Forget flat design. Design in a 1995 style for full impact

#70

Post by dllthomas »

laumars wrote: post #66
dllthomas wrote: post #65

Earlier quoted context omitted.

"No. I do not want my server hardware attempting to guess optimal performance. I'd rather do that myself and know that it's set up correctly." Parent said " default to automatically adjust" - and I see no reason it shouldn't. You could still manually tweak all you want.

The automatic adjust option would be a crap default though. Just the process of Apache checking whether a page is static or dynamic means accepting the connection to begin with - by which point it would be too late to forward the connection to a sorry page if content is dynamic. It would also mean that connections end up stacking at a far greater rate as Apache is required to open each and every request just to ident…

Automatic dynamic tuning isn't an obvious choice[1], and isn't what I was suggesting, and I doubt it was what the parent great-grandparent was suggesting. I simply meant scaling parameters based on the hardware available and whatever else can be determined easily at configuration time.

[1] Not going to come out and say it couldn't work, but I am skeptical for a good many reasons, some of which you've touched on.

Post reply on HN