https://www.dailydot.com/parse... The "Barbie: I can be a computer engineer" book showed her having to ask the boys in her class to code a game for her because she wasn't able to! Not a great message for her fans.

There were other reactors working in the same plant until the last one shut down in 2000 (14 years after the disaster) so there were plenty of people working *in the same building* for a good long time.

Surely for wrestling there are much more important events such as Wrestlemaina and the Summer Slam? :-)

Why does a driver for a game controller need to be incorporated into the kernel?

Yeah, and monkeys _could_ fly out of my butt by 2050 too. They'd have more chance of powering the grid at night though...

Facebook's android app drains battery, is full of bugs and has a wierd non-standard interface. I didn't think they could make it any worse, but here we go - well done Facebook, you really raised the bar on suck there.

To me it all comes down to categorising the data. Some things need backing up daily, others weekly, monthly, annually and others once and never again. Also some things never need backing up. My first step with backup is to categorise the data when it is stored, then use the right backup strategy. If you don't sort the data properly you end up wasting money backing up stuff that isn't important, and may even miss things that are important. My servers are based at home, close to the desktop/laptop machines, so though I have RAID for important data, everything is vulnerable to fire/flood/theft etc... However, I do have a co-located server based 300 miles away to run several websites I look after. When I looked for the hosting provider I factored in the price for extra storage, and then ordered the server with a fair chunk of extra space than I will ever need for the web servers. I now use the colocated server as a rsync destination - no private data (in case it is compromised), but it makes me feel better that me and my family survive a house fire, the family pictures will too.

Molten Salt Reactors have benefits, but the first one (MSRE) was also a nightmare to decommission (like Dounreay)

From the Wikipedia MSRE page ( http://en.wikipedia.org/wiki/Molten-Salt_Reactor_Experiment ):

You're exactly right about the conflict between gaming and multi-user computing, and I think the problem has always been that Windows attempts to do both at once when it doesn't really need to. Few games need to have explorer and all the rest running in the background - what games need is (more or less) exclusive access to hardware.

The Amiga had an answer to this - AmigaOS was a multitasking os with all the nice eye candy etc, but there was a API call ( Forbid() ) that you could use to ask the kernel to suspend multitasking, and pretty much everything else except core kernel functions. From there on you had access to the hardware and you could do what was necessary to get gaming performance. If you were doing this the proper way you'd still use API calls to get memory, use resources etc... As long as you followed the rules and put things back as you found them at the end of your program when you re-established multitasking all the old processes would spring back to life as if nothing had happened.

Obviously you wouldn't want to make these kind of calls on your web server today, so there has to be security around what processes are allowed to do this! Still - might work a bit better than Windows current method of trying to be a multi user server and a games console at the same time.

Stair