Earlier quoted context omitted.
The location of the voter.
Ohh I see, okay thanks. Surprising but cool!
So if one creates a HN profile from Amundsen–Scott Station, you can have a disproportionate effect? Very interesting.
Websocketd
31–40 of 233 posts
Re: Websocketd
#32This is the second or third "it's CGI again" thing I've seen in the past year. While these things are cool and definitely have their place, it's still worth noting that process per connection scales fairly poorly, simply because processes and forking are relatively expensive, and therefore it's probably unwise to deploy something like this in production anymore. It is what it is, I suppose.
Is that a feature or a bug of *nix?
Re: Websocketd
#33Earlier quoted context omitted.
Ohh I see, okay thanks. Surprising but cool!
So if one creates a HN profile from Amundsen–Scott Station, you can have a disproportionate effect? Very interesting.
I imagine it's not the mere creation that matters but where the login is usually from? And I'd assume the account age matters too...
Re: Websocketd
#34Earlier quoted context omitted.
SVR4 came out 30 years ago. I think it's time to let it go.
I'm fine with letting it go! I just don't understand why they're claiming this is "the UNIX way" as if that's a good thing.
The unix way is 'decoupled microservices', breaking down components in to small pieces for reuse, it continues to be used and reinvented in different contexts. Both monolith and decoupled components have their cheerleaders but simply dismissing either as 'not a good thing' doesn't add anything to the debate.
Re: Websocketd
#35This is the second or third "it's CGI again" thing I've seen in the past year. While these things are cool and definitely have their place, it's still worth noting that process per connection scales fairly poorly, simply because processes and forking are relatively expensive, and therefore it's probably unwise to deploy something like this in production anymore. It is what it is, I suppose.
But websocket connections are usually long lasting. So the cost of the fork is less important.
Re: Websocketd
#36Wondering if it would be more "unixy" to use sock files [1] ? I think some WSGI servers such as Gunicorn [2] support said functionality. I do think there is a place for websocketd provided you do not use tools like WSGI servers already.
1: https://en.wikipedia.org/wiki/Unix_domain_socket
2: http://docs.gunicorn.org/en/stable/deploy.html?highlight=soc...
Re: Websocketd
#37This is the second or third "it's CGI again" thing I've seen in the past year. While these things are cool and definitely have their place, it's still worth noting that process per connection scales fairly poorly, simply because processes and forking are relatively expensive, and therefore it's probably unwise to deploy something like this in production anymore. It is what it is, I suppose.
Not that much on modern Linux/BSD systems at least. The kernel is smart enough to just copy fewer pages when forking not the entire parent process image.
Re: Websocketd
#38It looked simple enough, but I was curious about the threading example on https://github.com/joewalnes/websocketd/wiki/CPP-Input-Outpu...
The variable `count` appears to be incremented non-atomically from two different threads. Is that safe in C++?
Re: Websocketd
#39Doesn’t this have an impedance mismatch? Stdin/out are stream based. Websocket is message based. There is no guarantee you can transmit the content of a single WebSocket message inside a single os read or write call. Unless you expect that on both sides messages might be fragmented across multiple calls and callbacks. But I don’t see the docs mentioning that.
Re: Websocketd
#40Or just use cowboy which is written is in erlang and will scale better.