Re: mobile synch - That already exists with the N900 and Firefox with the Weave plugin.

Anyone that gripes about wanting Flash on their phone/mobile device *HAS NEVER HAD* Flash on a mobile device. If they had, they wouldn't want it so bad.

*raises hand*

Here, please. I have an N800 and an N900. I *do* want flash on my devices and I *do* use it. Both of those devices have adblock plus to combat annoying ads with the built-in browser. The main thing is, I can still use flash if (and when) I want to. That's my choice to make - not the manufacturers.

Oh look! It uses hover states for mouse tracking - something that isn't supported on a touch interface... Oh look! The N900 has a touch interface that supports hover!

AT&T runs the one (1) and only GSM 3G network in the United States of America.

T-Mobile would be very shocked to hear this...

Google Voice, Gizmo5 account (if you already have one; they're not accepting new requests) or a SkypeIn US number. Get a GSM smartphone with a simcard from a Canadian provider (since you're there most of the time). When in the states, get a pre-paid sim card with voice/data or just data. If you need the SkypeIn, it will set you back $30 for the year.

You now set up GV to forward calls to your US number to your VoIP account (Gizmo/Skype) while in Canada. Calls will be delivered via data. When in the states, you can continue with the same method, but with a prepaid simcard OR you can just forward via voice.

Note that while data plans for Canada or pre-paid US may be capped/metered you only need to use the GSM data when you are out-and-about. Any decent smartphone these days will happily shuffle data through wifi instead.

My Nokia N900 might be a bit too pricey, but will do everything here seamlessly with the built-in Skype and SIP integration.

The only thing this doesn't cover is porting your existing number to GoogleVoice...

I would add that the "floor mat" excuse always sounded like BS to me.

There may have been more than one conclusion or actual root cause for the stuck accelerators. I can confirm that on one of my (non-Toyota) cars I have personally seen 2 different aftermarket floor mat styles slide forward and end up in a position that stuck the gas pedal down.

4) install distccd on a bigger system on the same network; emerge distcc as soon as possible on the smaller system

Nokia's handwriting calculator running on an N810 or the upcoming N900. Add in a bluetooth keyboard if you want something full size to type on...

Not yet...maybe soon...Part of their whole Project Dark thing is for them to start carrying high-end handsets. Rumor is that they'll have the Nokia N900 in Q1 '10.

TMobile Even More Plus.

TMobile is very friendly to unlocked phones. If you buy one of their subsidized phones, they will unlock it for you 90 days from purchase. They even have a gray market phone support department; they support the phones they don't even sell...

I would mod up if I could. I've got two separate Isilon clusters at work and they are indeed awesome. Just one of the features that go above and beyond standard RAID is what they call FlexProtect. I allows for the ability to handle your redundancy not just at a node/disk level, but right down to a directory/file level. Only need N+1 except for some critical data? You can give that file or whole directory N+4 while keeping the rest of the cluster N+1.

It appears that you misunderstand the aphorism...obscure != secret

There is some, albeit minimal value in security through obscurity...but that's not what you're talking about. Securing something via obscurity is akin to giving an attacker 100% of what they need to break the security and putting a layer of obscurity on top. Encoding a message with ROT13, for example. Giving an attacker the ROT13 encoded text and having the ROT13 algorithm available is everything they need to decipher the message.

Having a security system based on a secret key is *not* security through obscurity. The attacker simply does NOT have all of the information needed to break the system. Now, the system is only as secure as long as the key is secret. With a large enough keyspace, you can be more than reasonably assured that the system is secure as long as the key remains a secret.

...even if you don't want to spend for the HD, a TiVo Series 2.5 DT does dual tuning goodness at standard def and has been available for how many years?

Don't take this the wrong way, because I love RT, but it does have some serious performance problems in the large scale.

It's absolutely perfect for the volume that I'm currently administering (3K-4K tickets per year, roughly 15K correspondence, 70K transactions) and once you realize why certain things are laid out the way they are, the API is *very* easy to extend and customize.

The last RT shop that I worked in was a completely different story. We were doing 100K+ tickets per year easy (with that increasing at a rapid rate) and that was 6 years ago. When I left, about a year and a half ago, there were approx 700+ queues, many thousands upon thousands of users and millions of correspondence. There was quite a bit of performance tweaking we needed to do to the code and, of course, the DB just to make it useable. Simply iterating over the queue list using the API was taking upwards of 3 seconds. 3 seconds. Not to render the list in a browser. Not to access the names of each queue. Just to iterate through the list. That install is now plowing through tickets faster than even and is well past the 1M ticket mark, likely has in the tens of millions of correspondence and is performing adequately.

RT is a *great* tool, but you're not going to see performance at those numbers unless you have a firm grasp on DB tuning, perl, Mason and RT's architecture and get your hands very dirty - or you pay a hefty sum to Best Practical for support.

* VMware ESX - enterprise grade virtualisation server. Combined with vmware infrastructure, you run a bare minimum hypervisor (no overhead from a standard linux or windows OS host), store your virtual machines on a SAN or NFS, have a pool of physical servers and automatically load-balance your VMs between them or even bring them back up automatically if a physical server goes bang. Nearly completely abstract your servers from the hardware, run 20 servers per actual piece of tin. Very much not free.

Almost. What you're describing is full "VMware Infrastructure". ESX is the bare-metal hypervisor - and has actually been "replaced" with ESXi. This is a stripped down version that has a smaller install footprint and therefore a lower exposure to exploits. Most of the old ESX patches were for things like Samba and CUPS on the service console. ESXi now comes from vendors like Dell in an embedded form even: 32MB on an SD card, pre-installed, no hard drive required.

You can use local storage with ESX and ESXi; just format it with VMFS. When you're dealing with live-migration (vmotion), automated resource balancing (DRS) and bringing VMs back up after a bang (HA), that's all part of VMware Infrastructure and Virtual Center.

Very much not free - BUT the ESXi installable hypervisor? Free. Go download it now if you want it. Due to the stripped down nature, it supports a more limited set of hardware than VMware Server (which relies on a regular host OS to work out the hardware details), but it performs much better. Depending on the host hardware and VM workload, you can get a 20:1 VM:host ratio with your eyes closed.

Please, someone shoot this idea down - why not just do it with infrared lights on the sidelines or something similar? All you need is some focused, non-visible light broadcast at field level and you could paint that visible using a chroma-key-like system. Calculating the angles of this and the deflection of the field, etc, etc seems far more complicated than it has to be...