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).
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.
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.
In the book "The Moon is a Harsh Mistress" (1966), an electromagnetic catapult is used to deliver goods from the Moon to Earth. It is similar to what you described -- just a really long tube (or rail) at the highest elevation possible.
I really wouldn't call this an alternative. If you are running memcached, it's very unlikely you can switch to Groupcache.
Parts of your application may rely on the expiration feature. But the biggest change is the inability to overwrite a current cache key. Every application I've used does this constantly (object updates).
Groupcache in its current form is useful for a very narrow set of applications.
I can give some examples but my point was basically you have to test for your specific desired user base, and these kinds of posts don't really mean much.
Some things that we did: autoplaying videos. enormous graphics and big text. lots of "as seen on !". landing page was probably 6000-7000 pixels high and the form was near the bottom.
Your target audience is going to heavily influence most of these.
At a previous company our target audience was older women. We A-B tested every single element on our landing page, and I can tell you, using the advice on this site would be a complete disaster.
Russia isn't worried about America becoming too powerful. Russia's stance is that your country should worry about itself, and leave other countries alone. Putin has said many snarky remarks in this respect.
This phrase 'direct access' -- I wouldn't assume, if there exists something like PRISM, that it would have 'direct access' to anybody's servers. More likely, the data would be given from a company TO PRISM.
You could even argue that an API would not be 'direct access'
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...