Very interesting, but compare the details of the filing to the statement released by the superintendant that states:

Upon a report of a suspected lost, stolen or missing laptop, the feature was activated by the District's security and technology departments...This feature has only been used for the limited purpose of locating a lost, stolen or missing laptop. The District has not used the tracking feature or web cam for any other purpose or in any other manner whatsoever.

Seems someone needs to get their story straight...

Seriously, what could have made the school district think that this was, in any way, a good idea?
Well, it seems bone-headed now but a year ago when (theoretically, I don't actually know) a few laptops were stolen on the bus, from the locker rooms...figuring out which students were stealing them doesn't seem so bad, does it? Okay, you're right, it still seems like a bad idea...

The main problem was with resource forks causing a bunch of ._foo files, but there's not too much you can do about that if you're copying data from HFS+ to something else

Try rsrc = false in your unison profile.

Calling it "excellent" might be a stretch but a lot of what they do is generally "better than average" -- take Gmail, since that's mostly what this article is about. Before Google, no free email provider offered POP access, much less IMAP; incoming and outgoing attachments were required to be small, and archiving old messages was limited by severely small data limits. Gmail really raised the bar of expectations.

Not that being this way excuses their behavior, especially in cases like this; but there's certainly more to Google's "reputation for excellence" than just their search engine.

No, that's not native, which the GP specifically mentioned. There's nothing like trying to coach my coworker through downloading and installing ntfs-3g (and, until the latest version, MacFUSE first) over the phone (especially the time there was no internet access). Good luck trying to explain why they need it, too, since the drive is RO with the native driver ("if I see it, why can't I write to it?").

Also, last time I checked (I don't use it that much), performance was abysmally slow. I just realized I'm a bit outdated, so I'll have to upgrade and see if that fixes it.

NTFS-3G is awesome, true, but isn't native.

It's not really the same thing; in the US we have network breaks and local breaks, they're scheduled as such and all the local stations take their local breaks at the same time -- the network doesn't air anything during those spots so nothing is "covered up". In Canada, they apparently cover up both the local and network breaks with their own breaks, effectively blocking all the network commercials that we look forward to.

Hope I've explained this sufficiently; it's the difference between a scheduled local spot when there is no network spot run versus the (highly-anticipated) network spots being covered up.

Actually, the GP is correct -- the US 525 (and most other modern systems, with the exception of France) use negative modulation. 100%+ white can even cause the RF transmitter to completely cut out, I'm told. (actually I just looked in to it a bit further, apparently anything over 130 IRE causes the zero carrier, which leads to the buzz we've all heard [leitch PDF]).

Anyway, IRE isn't the same as the percentage of full modulation -- IRE is a (somewhat invented) scale for referencing the luma information; to continue your scope comment you also see -40 IRE as part of the sync pulse; this of course doesn't correspond to the video signal being at -40% modulation, so it doesn't necessarily follow that 100 IRE == 100% modulation.

Anyway, this old wikipedia article[1] is the best explanation I can find online right now and also has some information on why negative modulation is preferable to positive modulation.

By the way, I'm not 100% certain but believe this negative modulation is only the AM RF over the air transmission and not the vanilla component/composite video in a facility. If that's true (and again, I'm not sure); that certainly would lead to further confusion in measuring and testing.

Hope this helps rather than confuses :-)

1: The section above about "IRE Interpretation" completely confuses me, though. I think the writer wrote "100% white" in a few places they meant "black"