Become a fan of Slashdot on Facebook


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Long Hours and Efficiency (Score 1) 602

by theunixman (#33416884) Attached to: Tech's Dark Secret, It's All About Age
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.

Comment: The Myth of RAM (Score 1) 298

by theunixman (#32575384) Attached to: Knuth Got It Wrong

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.

Comment: Hibernate and Requirements (Score 1) 429

by theunixman (#25636305) Attached to: Reuse Code Or Code It Yourself?

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.

At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer.