My coworker picked up:
http://accessories.us.dell.com/sna/productdetail.aspx?c=us&l=en&cs=19&sku=224-9949&baynote_bnrank=7&baynote_irrank=0&~ck=baynoteSearch
This monitor looks rediculously crazy large, but absolutely awesome every time I walk by his desk.

I picked up an XPS 15 which supports mini-display port (which I dongled to DVI) and HDMI. At least with my video chip and Linux, I can run both external heads at the same time (not all three though, so I suppose only 2 internal DAC's). I think there's some inspirons that have dual headed docks, but I really haven't looked into it since getting mine. I'm pretty sure that Mini-display port can be dongled to VGA, but at least on linux it was always flaky for me.

A co-worker and I both bought XPS-15's at the same time. Mine was an I7 and his an I5. His comp took a dive after two days and mine has been fine. Anyways, for warantee, they made him pay for shipping to them (not sure if this is standard or not) and he'd have to wait until it was all repaired before getting it back. Since he was actually using the laptop for real work and all, he just returned it and decided to buy something local.

Really, almost all of those pre-requisites are mitigated with a system with a good dock and a healthy set of peripherals. If I want a portable laptop (not really much a concern for most developers who work in a cube 99% of the time) I'd at least like a dock so that I can easily leave the crap behind. My big MUST in a computer is at least decent dual monitor support and enough RAM / horsepower so that I don't feel bogged down doing day to day work.

I've got an XPS-15 and it has a great 1980x1080 panel. If you're seriously considering a non-trivial outlay, it may be worth your time. The only thing is the laptop isn't super light, so not the best traveller.

Um, how about an XPS 15? I bought my pre-sandbridge fully loaded last Feb 2011

Core I7
8GB ram
500MB (non-sata)
2GB unshared discrete Nvidia video (dual external tuners) -- 1980x1080 native panel screen (gloss, but oh well)
Price: $1600cad Price now is probably closer to $1000
Running Fedora 15/16 (17 soon) and besides a small niggle with the video (doesn't boot two external heads, so I need to turn one of them on when I'm in X)

I've since upgraded to a 160 SATA, but the rest is great.

The thing works very well, and is quite comparable to my co-worker's $3000 (new) sandybridge enabled Macbook Pro.

robots.txt grumpy, if you don't want to join the link economy.

Google, apple, or any company, organization, etc.. If API's are implicitely copyrighted by definition, all open standards are suspect, all transparency, who the hell knows what happens with the concept of fair use.

The other thought was that Google's web page has never has been an API. Its an end user access mechanism to their service (which hosts a collection of useful information). If you want to use their service, you abide by their TOS which specifically forbits scraping. I've never signed an NDA for using a programming language, but it bet if I did, I'd be just as liable for breaking the terms of use as any Google scraper would be for abusing Google's service.

I'm sure you're more or less correct in regards to smart pointers, but with one caveat. In Java, circular dependencies (regardless of how nested) will always be GC'd eventually unless they're hard linked to a heap object hard-linked to a working area on a live thread. We don't care about crazy inter-dependencies that would normally cause reference counter based pointers to leak.

In Java, you really really don't care about how memory gets allocated and removed unless you're doing very non-trivial performance sensitive work, which is generally not the case when one chooses Java as a starting platform to work in. That said, More vetrain programmers will be able to mitigate most bottlenecks relating to object construction/deconstruction with various techniques (constants, reusable 'hold' objects, weak references for well behaved caching, only allocating objects when they're really going to be used, etc..). Nothing here is specific to java, but you just have fewer avenues as a developer to micro-optimize or shoot your foot off, which has and always will be the Java tradeoff.

I forget if it ever got implemented or not yet (maybe in Java 8) they were removing method scoped variables from the heap allocation which makes a billion little heap allocations (and hence fewer and simpler GC's) events a lot more tolerable.

Plus, coming from a long time convert to Java, once you've coded Java for a while, you have to be pretty off your rocker to make actual memory leaks. I mean really really off your rocker. There are times that caches stick around much longer, or you have an engrossing singleton floating around because a newbie doesn't understand anti-patterns but by and large that is a NON-PROBLEM. I've spent maybe 10 minutes this year thinking about memory management, firstly because I don't have the same performance pressure that most C/C++ programs seems to require (you guys are all nuts or game/embedded developers), and second because it is soo hard to actually cause hard-links to data you expected to throw away.

"You can call your implementation of the Java language Java if you comply with the specification."
And get it tested with the TCK, which was the original cluster F*CK with Apache and the JCP to begin with, because they would only allow the software to be tested if they signed field of use restrictions which Apache wasn't/couldn't abide by.

There are common sets of Java idioms now bult into the language that makes concurrency and multithreading dead simple (for those that have a clue), but you still need to know where and how your program is supposed to function in a multi-threaded setup (which can be hard for any non-trivial orchestration). Common shared data integrity (volatile, static fields, ThreadLocal, etc..), locked collections (synchronized loop iteration), race conditions, circular lock contention, etc.. all still happen in Java if you aren't careful, so knowledge of proper practices and debugging becomes invaluable regardless of what language you're married to. The one exception may be purely functional languages where side-effects basically don't happen, but I find them very impractical for large scale real world applications ouside of a few (mostly academic) use cases.

Don't forget the real reason dev's support higher level scripting languages like LUA. If they needed to hire trained competent C developers to do the same piece of work that a LUA dev can do, it would cost a hell of a lot more to write games (both in raw dollar value per hour, and in the time wasted 'leading with the crap' that isn't important in C). And like you said, if there was some really problem areas that the script was bottlenecking on painfully, i'm sure that single function could get dragged into a native mapping.

Hell now adays, a ton of projects just leverage the engines from other companies (or teams), slap on some game specific native extensions, spend 15% of the budget on higher level scripting/graphics/sound/voice/etc.. and the other 85% on marketing =)

Thanks troll. Google is the ONE company being sued, and there's a really good rationale for WHY they were sued vs. the multitude of other companies using Java based technologies. That doesn't mean that the law suit will enevitably end up in Oracle's favor (probably not unless they get patent wins).

Before Oracle actually bought Sun, they were probably invested into the multi-billion dollars a year revenues from Java based products. Was there ever the thought that they were going to get their asses sued? No they were following the licenses as issued and they 'followed the rules'. Java products doesn't make it a legal hurdle unless:
1. You use their patents
2. You release a java-clone and call it Java without being 'certified' and licensed
3. You copy/paste part of the Oracle based source into your product

Um, each Java thread runs independently, and in The oracle JVM they're OS threads, so assuming that one wrote 'JavaForKernel' module extensions (and a shared runtime hook), there's no reason why it wouldn't be feasible for Java or a java like language to be used in the kernel. That said, its a horrible horrible idea as a result of performance and memory management overhead and bloat, but it would be a neat idea to be able to debug drivers on the fly instead of performing black rites to get C debuggers working nearly as effectively as Java ones do out of the box.

Google employees and good friends didn't have to wait for tickets. My contemporary got his tickets couple weeks ago, and he may not even go...