He's not trying to complete on price w/ Microsoft; So there's nothing stopping him from buying an official controller for each one he builds to get the interface hardware. It just becomes part of the BOM cost.
Then he just has to replace the buttons and joysticks with ones that work for his end-users.
The best part about that team revealing this, was hearing NPR / CNN / BBC and others say Goatse in their broadcasts. Priceless!
I understand that, but it still doesn't address the include:xxx condition I outlined above. If we use an application service provider that sends email on our behalf, I have to get that provider to setup a custom header in the outbound email with a private cert I have generated for them. With SPF I can simply use an include: xxx to specify that I also trust vendorx.com to send mail for mydomain.com. I was inquiring if there is a facility for DKIM to support such a mechanism, which it doesn't seem like there is.
I can take a hardline with the ASPs and require they allow stamp the mail with my DKIM, but if you're not a large enough customer chances are they will say tough deal with it or go somewhere else.
How would that work with trusted partners who may send mail on your behalf? With SPF I can use an include:xxx to define relationships with other systems. With DKIM it seems I would need the partnered system to stamp the sent mail or relay off of our originating servers for DKIM attribute addition (something that might not always be possible). Is there an elegant workaround?
I use them, and what I've found is that they have a very marginal effect (if any) on spam catch rates on your inbound mail. However, they do have a great side benefit. They significantly reduce backscatter, keep yourself off of blacklists, and provide some control of you, your employer, or your client's identity on the web. SPF records provide a mechanism to limit who can spoof as you (as long as recipient servers adhere to them). If you have a risk to yourself or interested parties that someone might spoof your domain (banks!), then SPF provides a means to insure the chain of custody (to an extent).
I do think overall SPF has helped to prevent forged domain letters, but those are less and less common (for those that publish spf). The spammers now either rely on forged domains without DKIM or SPF (why not use both!!) or they send from their own controlled botnet domains and publish legit SPF for themselves as well.
I honestly don't know too much about Mandriva these days. I was an avid Mandrake user until they stir up (some time back).
Looking at the latest release notes there are some interesting things. Looks like a lot of work into 1 click install of codecs, firmware, etc...
I would still hypothesize that OpenSUSE would have the better KDE4 experience, due to the work done to KDEify Firefox and OpenOffice (though I do see Mandriva uses Go-OO). The OpenSUSE Build service as well seems to keep a lot more software options packaged for SUSE then other RPM variants (with of course Ubuntu leading the charge for prepackaged binaries).
I think I might give Mandriva another look though since it has been so long since I considered them.
It is easier to write an incorrect program than understand a correct one.