Lots of high-current outlets, preferably on several circuits. Some non-fluorescent, repositionable work lights to help kill the flicker and see the work. Locking wheels for everything. Pegboard and hangers. Fans, ventilation, etc.

Not Zombies. A Hive Mind: http://en.wikipedia.org/wiki/LOIC

The problem isn't being able to keep up with younger programmers in quality so much as quantity. As long as managers believe that hours and lines of code are reasonable proxies for quality and success, younger developers will continue to be seen as the saviors of projects long past failure, while the experienced programmers that can implement far better solutions far faster are going to be second class citizens. And the young code factories will be promoted to management, which they will be even more incompetent at, and will continue the same metrics.

Even better would be a language that didn't need horrendous amounts of crappy boilerplate code for every API.

At least now people who would not have known about a potential attack vector can take precautions and be safer without having to wait for Microsoft to introduce more vulnerabilities when they come up with a "fix" for this one.

I'm fairly certain that past a certain volume, keeping a significant fraction of requests resident in RAM is not actually possible. Consider sites serving up large media files that are constantly changing, and even with a fairly large budget having RAM to cache all of that content is not reasonable. It's not much larger when having sufficient spindles for naïve algorithms is also not an option.

At this point having intelligent algorithms that understand non-uniform memory access patterns is essential, whether it's L1 - L2 cache, cache to SDRAM, RAM to disk, and even local disks to network storage. This is where algorithms like B*-tree and the B*-heap start to perform much better, since they're designed around such non-uniform memory access. Database engines also have been designing indexes around these principles for decades, although in a very specific way that's much more difficult to use generally.

So while it may be comforting to throw out the RAM card and give up when the reality of budgets and billion-dollar-RAM-caching systems are unobtainable and give up, actually trying to solve the underlying problem is much more interesting.

I use them on ext3 with no problems. It's true that very early on there was a problem with them and journaled filesystems, but that has long since been solved.

They are not at all related. Seriously. And if you are getting requirements you think Hibernate can't fulfill, you have done something so fundamentally wrong somewhere that if you code the database layer yourself you will be completely screwed. So find out what the real problem is and what you need to change to work with Hibernate.