RTFM: RFC 2018, SACK.

You can buy the USB version of the Customizer 104 Unicomp keyboard with buckling springs. It's the rightful heir to the model M and allows plugging into a mobile device (provided it has USB).

Forget the Cherry keyboards. They are a mere shadow of the real thing: the Unicomp keyboard you linked to.

I have four of those Customizer 104 models, one all black (no printed keycaps) with buckling springs, one normal (with printed keycaps) with buckling springs, one all grey with "Enhanced Quiet Touch" without printed keycaps again, and one normal with printed keycaps and "Enhanced Quiet Touch". I have to say that the buckling spring versions are *amazing*. I reach highest speeds with the all black unprinted keycaps buckling spring version. The feeling of the "Enhanced Quiet Touch" method is worse, but it is a nice compromise if you want to type without annoying others in the room.
The Unicomp keyboards themselves are amazing as well, they are indeed coffee-spil-proof, i.e. if you empty a glass of liquid on top of them, it simply exits the keyboard through the drain-holes and there is no damage to the mechanics or electronics.

I have no ties with the company, I"m just a very satisfied customer; I ordered the keyboards from oversees even (due to their weight, the shipping costs are not insignificant).

I've been running secure open WiFi networks for the past three years. Using hostapd and a patched radius server to ignore the password. I.e. the user asks for a connection, gets the certificate from the radius server through EAP, then the user is prompted for a username/password. The user is allowed to enter *any* username and *any* password, the "authentication" proceeds and simply grants access.

Presto, open WiFi, with private WPA2 encryption per client, and an SSL certificate from the access point which can be validated against. I don't know what IBM et al have been doing, but this is readily available tech (patching the radius server was/is not exactly rocket science) and it works since 2008, and it certainly is nothing exciting to get all fussy about at a black hat conference.

I see that they have a patent pending; this must be a joke (then again, the whole software patent system is a joke).

Hear, hear!

I couldn't agree more. In fact, if Ubuntu wants to replace synaptic, they should do so; if it helps the newbies, then please do. Real powerusers shouldn't be concerned, since they shouldn't be using synaptic or aptitude or the Ubuntu software center, they should be using bare apt-cache/apt-get. The first thing I regularly do after installing ubuntu is strip it down (i.e. uninstall synaptic, aptitude, network-manager, avahi-daemon and a myriad of other things), so that I essentially have a Debian system with an Ubuntu desktop; it allows you to pick the best of both worlds.

I'd say, skip the DOS-era, and go back a bit more. If you want to learn, play with and understand all of the hardware/disassembly of a TRS-80 (easiest, probably) or Commodore 64 or ZX Spectrum or CP/M running machine (or similar device from that era). There should be emulators for most of them.

The devices have a max of 64KB of memory (except for an occasional bank switch), which contains the OS, the DOS, the BASIC interpreter and your application.
64KB is small enough to learn/explore inside out. That will give you all the (low level, architecture) experience you need; what was done in the DOS era is just more convoluted and messy, but basically the same.

Have you reviewed/tried Arcad? It has (in the full version) architectural computations.

I'm using Arcad to plan some buildingdesigns in 3D. Works reasonably well, comes with a paid license (I'm using the small Easy-entry-level license, which fits my needs just fine).
Some nice trivia about the creators:
- They use Linux exclusively to develop all their softwareproducts.
- The Windows build is created mechanically.
- They sell arcad for 98% to Windows clients.
- The English translation still needs some polishing here and there; but the functionality is solid.

If I understand correctly, we'll then be able to determine the White House effect on the green house effect?

God forbid! The only thing putting my mind at ease here is that he'd probably never be able to achieve the code-quality standards that would allow him to contribute to PostgreSQL.

I can recommend the Alix boards. They are very well designed and draw 3 Watt on average, 5 Watt peak at 100% CPU. I've used them with Voyage, which works very well, and I'm in the process of releasing an alix-customised Debian distribution which will provide a richer environment than Voyage, yet still provides facilities as fall-back flash and network boot.

Have you tried the Samsung B2100? I just got one last week. It's waterproof up to one meter deep for 30 minutes, and you can drop it (a lot; tried that already). The casing looks sturdy enough.

I never liked Perl or Python, but graduated from sh to awk to Pike. It's not for everyone, but for people used to C syntax, it's a script language from heaven.

There are several reasons why, even in smaller groups, using git is advantageous (even if you have only yourself, no other contributors). I'm not going to name them all, but in my experience (I've used RCS, CVS, SVN and now git), some of the more compelling advantages are that you can:

- Actually permanently erase/fix bad commits from the repository without a painful full dump/tricky edit/restore cycle on the repository. I suppose everyone has some of those occasional moments sometime: "Aaargh, I meant to commit only this one file, not this tar.gz file that happened to be in the wrong place at the right time." Git allows you to correct the mistake without bloat in the repository.
- Patch management (instead of keeping around a bunch of patch files, simply create branches for every patch file you'd normally keep) made easy and trackable.
- And related to patch management: commit early, commit often, then cleanup/merge commits before actually committing them "for real" to the bleeding edge version.

For small groups it means that you simply setup a central git repository everyone pushes to. You get all the benefits of DVCS and classic central management, i.e. it allows you to have your cake and eat it too.