The way my mud did it, and I believe most muds (considering I took my implementation from another popular codebase), was not by forking.
Sockets are just files, so all we did was save everything including players, execl() another instance of the MUD, and exit. Same port wasn't an issue with SO_REUSEADDR.
On boot as it's loading players, their file descriptor ID was saved, so it loads it up and resumes talking to the socket. It also loads the ID of the server socket descriptor. No need to send information to a new process as it just loads the previous game state.
Tidbit inspired me to write my own web-miner, which I open sourced. It's hacked together as I was really just trying to learn how the cryptocoin&mining stuff worked. The mining rate you get with straight javascript is truly abysmal, even with web workers (much worse than the standard cpuminer).
I found a couple examples that do the scrypt part with GPU in browser, but your browser has to support custom shaders, I think (I forget the details), and the version most browsers support doesn't allow this (again, my memory is sketchy about the details).
Or threatened litigation, the hallmark of companies who have no clue about security policy.
Edit: the parent was deleted while I posted this but the gist was that 5-10 years ago all you would get for reporting an issue was a thank you and maybe a T-shirt.
Basically, "it depends". having dealt with extremely DB-intensive applications, I have developed a personal motto of "be nice to the DB".
Let the DB be a secure storage of your data, not a calculating part of your application. But like the top answer says, sometimes it is not practical to do a calculation within the application. In my case, we had a few database servers set aside just for reporting, so we could slam them with difficult queries and not worry about affecting data.
He posted on a real person's wall with the initial bug report. It says right on the /whitehat page not to do that, and he mentioned /whitehat in his bug report, so he should have known.
I think the worst was Windows movie maker, which used to seem to just randomly choose a time it might take and do a bad job of self correcting on the way. Oh, and of course there's a relevant xkcd, http://xkcd.com/612/
FWIW, the SLS gets around this by having explosive bolts in the hinges that blow when the car is past something like 90˚ in orientation and has a velocity of 0 for more than N seconds. However, the SLS is a $300k car, so no expense is spared. That solution might be a little less feasible for a car that costs what the Model X will.
I dunno, given the other story today[1] about the Tesla S blowing away everyone else in safety tests, I wouldn't put it past them to have considered escapability after a roll-over in the X.
It sounds like you want everyone to be a system administrator. That is not going to ever happen.
The human history of inventing has one very consistent theme: making things easier for ourselves. "Computers" will only become easier to use, and require less knowledge of the humans that are using them.
When "computers" go wrong, a human with that specialty will fix it. You have that specialty. Why can't everyone fix their own cars or HVACs or bake their own bread?
The main turnoff for me when it comes to Rails is watching other major companies like Twitter completely rewrite their application away from Rails.
Growing pains -- the kind of pains we all want to endure some day. If you are planning to grow, why wouldn't you start with something you know has an end game (like PHP or Java)?
The often cited slowness of Rails, mixed with companies rewriting their codebases, and the flurry of vulnerabilities in the past year has caused me to take Rails less seriously.
> The main turnoff for me when it comes to Rails is watching other major companies like Twitter completely rewrite their application away from Rails.
I do not like Ruby and have never used Rails, but I feel your conclusion is wrong. Twitter would never have outgrown Rails (at that time they were already wildly successful) if it hadn't been the right (or at least a sufficient) choice for a prototype and initial production framework.
An overwhelming majority of web sites will never grow to the point where they need to drop Rails for technical reasons and some of them will still be hugely successful. If you reach the point where Twitter needed to switch, congratulations, you will able to afford it easily.
On boot as it's loading players, their file descriptor ID was saved, so it loads it up and resumes talking to the socket. It also loads the ID of the server socket descriptor. No need to send information to a new process as it just loads the previous game state.
If you're curious: https://github.com/borlak/acmud/blob/7c2442dfccfc28364fc399a...
And: https://github.com/borlak/acmud/blob/7c2442dfccfc28364fc399a...