Great find Xeni!

Or should I say... "Great find, Lt. Col. Jardin!"

(this is a joke, BTW. the thing is you get a blogger reporting that another site is reporting that the military is trying to recruit bloggers and wouldn't it be funny if Wired or Boing Boing was secretly being infiltrated.. oh... nevermind!)

I'm just reeling from the term "Boingo-Bucket." Maybe Mark F. and Danny Elfman were subliminally subjected to this marketing meme whilst they slept in 1972, only to have it emerge later in life.

As for me... I'm renaming the trashcan icon on my desktop to "boingo bucket" or "ruckus recycler"

Yea! Finally a post I can talk authoratatively!

Just a few notes from the conversation here...

1. Gender Identity != Sexual Orientation. I'm really hoping that Dr. Benway is joking... Look, being trans does not make you gay. Trust me. I tried. I really wanted to be gay. It's just that... well... I'm just not gay. And about sexual orientation, I know several transmen and transwomen. Some are attracted to members of their own gender, some are not. And there are enough in either camp to support the assertion that orientation seems to be independent of identity.

2. We walk amongst you undetected. When you see George Galloway in a leotard next to Pete Burns you say, "eek! he makes an ugly broad!" (Galloway, that is) And then you congratulate yourself on being able to spot the non-genetically-female. In the real world, it's not as simple. Some transfolk are not especially interested in "passing," some find it hard to pass without surgery and others pass _very_ well. Here's the interesting thing... people who pass very well... they tend not to point out that they're transsexuals. In part because people start doing crazy stuff like asking them annoying questions or wanting to beat them up. But the point here is that when you see a transsexual who doesn't pass, you start to think that you can spot them all. When you see a transsexual that does pass, you don't think to yourself, "oh... that person over there may be a transsexual, I'll have to reassess my ability to detect such persons." In short, there are a lot of transfolk who pass, and pass quite well.

3. I used to go to gay bars to get a drink someplace where I wouldn't get beat up. An interesting thing about gay bars, there are often non-gay people there. And that's okay. Well.. it would be okay with me if I owned a gay bar. 'cause the way I looked at it, a gay bar isn't a place exclusively for gay people, it's a place where you don't have to be rigidly hetero-normative to get a drink and not get beaten up. So just 'cause a transperson goes to a gay bar does not mean that they're gay. But some are. My point is, going to a gay bar does not imply that one is "gay".

@AnnoyedCapitalist...

Gender is actually a little more complicated than genetics. Having a Y chromosome doesn not make you male, as people with Androgen Insensitivity Syndrome or Congenital Adrenal Hyperplasia can tell you.

Having a SRY gene on a Y chromosome will in the vast majority of cases result in "maleness" but it is far from universal. And I think it's the "corner cases" that we're talking about here.

Do a google or wikipedia search on "intersex".

SWEEEEEET!!

I'm sure everyone's giving you more advice than you need (or even want.) But just remember... parenthood is a process that's been in beta test for a long time. Just make sure that everyone in the family is getting _some_ rest, and you'll be fine. I was always amazed with how little sleep you actually need to change nappies.

Congrats! There's nothing more satisfying than taking part in the great chain of life... etc. etc.

P.S. - There's nothing wrong with naming your child after famous mathematicians. @miles... hush!

Kerckhoff's principle applied to developing DRMish systems...

Continuing my comments... One of the reasons we have "improved" versions of debugging tools is that there is a pervasive fear among technologists and record company executives that general knowledge of the implementation of a DRM system will more rapidly to successful exploits.

In the commercial crypto developers community (of which I was a part for a while) there were several discussions in the 80's and 90's about similar concepts. (If you're really interested, google "A secret that cannot be readily changed should be regarded as a vulnerability")

In the crypto world, we have this thing called "Kerckhoff's Principle" which can be described as: "A system should be secure, even if an adversary has complete knowledge of the system, save a secure key." This has gotten us out of trouble several times. It allows us, as algorithm developers and implementors to openly discuss our concepts and have them be debated in public. There is general agreement amongst really smart people that this is "a good thing."

With respect to DRM systems, consider a DRM system that could be implemented in such a way that while it's under development, a blessed "developer key" could be used to allow the developer to peek into every nook and cranny of the system under development. When it came time to ship the device, a new key... a production key... preferably related to a key not under control of the development organization is installed into the device.

You could take this one step forward and release such a system under an open source license (and yes... I can hear Cory going apoplectic over the concept of "open source DRM".) Actually... several years ago, Sun proposed such a system. A system called DReaM. And it was released to near universal, deadening silence, a total "cricket moment."

But hope springs eternal... the best solution to the DRM problem? Get rid of it. It complicates development at best, and at worst it allows people to complain about "anti-competitive" behavior on the big 4's part. The argument being that since a professional copyright infringer could either buy CDs or DVDs to copy directly, and the ease with which DRM regimes seem to be defeated, the _only_ reason the labels could be supporting DRM is as an indirect path to control the distribution not only of their content, but to control the companies that build devices to distribute their content.

That being said... I suspect we'll continue to see DRM used for the foreseeable future, despite the success of DRM-free projects. But... for the love of everything that's holy, can we please stop considering developers as "the enemy"? It isn't helping.

Degrading debugging tools to prevent developers from hacking DRM systems is considered harmful.

Sadly, Apple is not the only company to do this. If you use the WinCE / WinMobile platform, you need to get all your platform and BSP debugging done _before_ you add DRM to the mix. Several years ago I worked for a company that was developing a custom device that (among other things) allowed you to download music and play it on the device. We did all the proper things with respect to licensing, including promising to take reasonable steps to protect the intellectual property rights of our partners. To be sure, there were a number of "typical" snags. But the most irritating bit was when, after signing deals with the big 5 (there used to be 5 major labels), signing a deal with Microsoft for the WinCE DRM bits, jumping through Verisign's bizarre hoops to identify ourselves, we discovered that kernel debugging on WinCE is (or was) _completely_ disabled after you add DRM to the platform.

I don't know if any of you out there have developed a BSP (Board Support Package) for WinCE (or any other embedded OS), but it's not always a straight-forward process. Documentation from chip vendors is not always completely accurate and timing tolerances seem to vary with the quality of some parts. Debugging custom drivers is often required to discover the cause of vexing low-level problems in a reasonable time frame.

In our case, we had to maintain multiple build environments: one for our BSP & Apps without DRM, and one with DRM. We also had to get quite "creative" in the way we debugged problems and even had to spend time developing custom tools.

The long and the short of it was that the removal of debugging capabilities from the development process added at least 3 man-months to our development project, but what's worse... it seemed to add (at least) 3 months to our release calendar.

Bringing this back to a discussion about DTrace... removing capabilities from a development tool is unlikely to be a good idea. Especially with tools like DTrace, where enterprising developers can figure how to remove the Apple "improvements" while maintaining full functionality. I suspect that if Apple doesn't do it themselves, someone out there will fork the code and distribute a "unimproved" version of DTrace for MacOSX 10.5. Or... they'll just give the patches to the proper maintainer and enterprising developers will be able to compile the "unimproved" version from sources (though admittedly, this is always slightly less easy than I might have made it sound.)

"Improving" DTrace will require Apple developers to get an "unimproved" version if they feel the "improved" version is not working properly (and believe me, programmers rarely think of _themselves_ being the problem before they think of their _tools_ as having issues.)

Sure... I can understand Apple having to "play nice" with the big 4, but it's time we move past the model of "system developer as adversary."