Ironically, the purpose of the law, as I understand it, is to prevent oppressive regimes from recruiting companies to collect information about the citizenry.

And if you narrow "North America" down to US, there are two 3G GSM networks. which means it works of half of the networks available to me. According to that list, Canada is roughly 1/3rd. The question you might ask is why there's two bands to begin with.

No amount of undervolting an opteron is going to surpass power draws of NAS's based on ARM processors.

OEMs do. Canonical's business operations are largely opaque to the community. Sources of revenue I've discovered include: OEMs like Dell buying engineering support contracts for their Ubuntu laptop/netbook offerings, hardware manufacturers paying Ubuntu to port to their new platform, and OEMs like Toshiba paying Canonical to run certification testing.

For netbooks, faster boot and performance is a feature worth pursuing. At this point all I've seen is Scott mention they'll try it and test it before the point of no return that comes with time based releases.

In part it depends on the kinds of programming you want to apply for. There are three kinds of programs:

1. Simple programs that largely revolve around "business logic" and writing and reading from a database. The most complicated stuff is either modeling the whole damn business process or maybe generating some reports. This stuff CAN become complicated, but I treat that as a design flaw. You will have a hard time getting into this without HR buzzword compliance. I think they're doing you a favor. Lots of poor CS students and business/IT majors end up in this place.
2. Simple programs that have complicated results. Lots of EE work revolves around designing simple circuits or programs and demonstrating they satisfy certain engineering properties. Control loops and whatnot. The programs are simple but the consequences may involve differential equations or recurrence relations. The programs are generally a variation of a small set of algorithms, with parameters tuned for your design's requirements. This is where EEs turned programmers generally end up.
3. Complicated programs. Wicked applications of math, like Hidden Markov modelling, or optimizing compilers, language theory and software verification. Speed reading CS won't count here, as you need to deeply understand the principles of computers and programs before you'll be productive here. If you've written a Fast Fourrier Transform implementation in school, you might have a shot. Otherwise, top CS students and grad students only.

So my advice is to find firms that do place EEs into programmer roles. Embedded systems places mainly. I have many EE friends that landed in programming roles, even though they insisted they would fight the trend. Try to position yourself in your current EE employment to work alongside programmers, learn what they do and pick up a few tasks for them. Eventually your CV will have programming related material to pull from for a targeted resume. And you'll have the friends and contacts to pass your resume directly to hiring managers for consideration.

If you're after category 3 work, consider getting graduate degree (don't waste your time on another bachelors). Plenty of EEs go back for different degrees. Look for institutions with EE and CS in one department, and I personally recommend against financing it. Spend 10s of thousands of someone else's money earning an advanced degree. There's TA positions, research positions, scholarships and employer paid options. Be prepared to sacrifice some portion of your life; be it your family, your career or your sanity.

When I TA'd for an advanced undergraduate level OS design class, we used team based projects for instruction and the best weapon we had against freeloading was secret peer evaluation and interrogation about the code. There's a lot of good reasons to go for collaborative design projects. They're closer to real world assignments; when you run into a problem with three people coding, chances are one of them can figure out the typo or think-o. The best students use it as an opportunity to test out revision control systems in collaborative fashion.

I think a lot of students skip the course now because it's been made optional and famously hard. With some effort it could be salvaged into a quality Software Engineering practices course covering revision control, automated builds, testing, static analysis and the engineering implications of NP completeness in operations theory.

I guess the next question is, isn't disclosure the sort of thing the CISO signs off on?

We can't get developers to pay attention to compiler warnings, what makes you think users are going to fare better?

Ironically, people who pay at the pump are least in need of any clerk at all.

No, this is a dumbed down version of civilization. CivRev was just a multiplayer game that could potentially finish in under a lifetime.

You would have a point had it been done for technical reasons. And had you known what you were going on about. Maemo was never based on clutter, it predated clutter by several years and the hardware it ships on lacks 3d acceleration.

Sadly, it seems you're also out of date. Maemo5 features 3d effects, to great use. I'm not sure whether clutter was in the final design, though.

SSL/TLS at it's core generates "session keys" for communication; a string of random characters. It's possible they're trying to deplete the SSL servers of true entropy for some undisclosed attack; PRNG, for example.

It is a bit thicker. But I kinda doubt that it matters much.

Maemo5 has Ovi Maps for Maemo 1.0. No turn-by-turn, etc. No bookmarks or voice announcements. In my experience it's pretty poor for on the go navigation.