I don't have an opinion on Snowden, honestly. Part of me wants to call him a traitor, as he did reveal information about clandestine operations, but part of me thinks him a hero for revealing the same information about homeland-based activities. I love this country, but I hate its government with a passion... and, as I'm related to a federal employee, I'm not worried about this post landing me on any watch list; I'm already on most of them. God Bless America.

As much as the opposing members of Congress will allow. That is to say, not much, but more than nothing.

Even "better"... I has a Belkin router a while back that had about a 10 foot range. I lived in the middle of nowhere, so interference wasn't an issue.

and the second o in the "too" in "too late"

Which is it? Because those two comments, both from your own fingers, represent completely opposing positions. If the fields are upscaled (height doubled) and displayed independently of each other, as in the first quote, then you get the oscillation I was talking about. the second quote is absolutely correct and I'm glad to see you've realized that you were wrong; a little disappointed that you expressed that realization in the form of an argument, but satisfied nonetheless.

Modern de-interlacing algorithms? You mean the ones your media player application offers you in its configuration? If you have an interlaced stream that starts with an odd field, weaving fields into full frames will always result in better quality. If the stream starts with an odd frame, it's possible that the stream was improperly edited, or that the fields are reversed on all frames; in the first case, you can simply discard the first field, while in the other case, you just reverse the rendering order of the fields, but you still end up weaving them together. A broadcast stream will always have markers every keyframe or so to indicate its resolution, whether it's progressive or interlaced, and, if interlaced, field order, so broadcast interlaced video can always be properly de-interlaced. "Modern" de-interlacing algorithms are designed around simply not knowing and not being able to tell, in an automated way, what they're dealing with, which is important in a media player, since you can't rely on the random files users will throw at you to have proper metadata; their aim is not quality, it's ease of use.

Well, yes, that's precisely what CRTs did. They skipped the width of one scanline (a little more, or less, if not properly calibrated) between each scanline while rendering one field, then rendered the following field in between. This is still the only *proper* way to de-interlace interlaced video, anything else is just compensating for not knowing if the content its display is (properly) interlaced or not.

I'm aware that some content is shot interlaced, but that does not matter here. You're oversimplifying by saying they're just lower-res frames; they're also comprised of alternating lines of the scene, and treating them simply as lower-res frames leads to (and I'm repeating myself, here)

Don't believe me? Go find an old NTSC camcorder, doesn't matter if it's a consumer or pro model, whether it originally sold for $100 to $100,000, as long as it's NTSC, it's going to record interlaced frames. Got one? Good. Now, mount it on a stable tripod, point it at a stationary object that has a sharp horizontal edge and record a few seconds of video; it doesn't matter how much, really, as all you need is 2 consecutive fields (1 frame). Now, get those 2 consecutive fields onto your computer, individually, however you can (a decent capture card and an S-Video connection will suffice) and overlay them onto one-another. Not the same, are they? One of them has that horizontal edge 1 pixel higher than the other, doesn't it? That one's your odd field, the one that's 1px lower is your even field. In fact, everything in that field is 1px higher than everything in the other field, and some fine details running along the horizontal axis appear in one frame, but not the other.

Your fields, being shot by a stationary camera aimed at a stationary subject, would be identical if interlaced video were, as you're simplifying it to be, simply half-height frames.

It's not actually double the temporal resolution, though -- you either get the odd half of the frame, then the even half of the same frame, at which point you've got one full frame every 29.97 seconds, or you get half-frames and experience interlace tearing during high-motion scenes. There's also telecine interlacing that shifts 24FPS content to 30FPS by adding an intermediary frame, even rows from the current frame, odd rows from the next, every 4 frames (that's 6 additional frames for every 24 frames of content, thus 30 frames); if you need 29.97FPS from that, you drop roughly 1 out of every 1000 frames (and you'd better stick to dropping full frames, and then only those that aren't adjacent to your interlaced frames, lest you introduce a noticeable artifact into the video every 33-1/3 seconds). There are a number of other encodings, as well, but they're not really relevant here.

Yes, actually... Well, not always, but on non-shit-tier sets, yes... But, I also think you meant de-interlacing.

It's entirely up to the TV to reconstruct the full frame, then, if necessary, scale the result to match the resolution of the display panel. If you don't do that and, rather, just scale each frame and display them as they come in, you get an image that appears to oscillate at your framerate (up on the even fields and down on the odd), which is really super-noticeable on static objects, like the bug most networks put in the bottom corner of the screen, or in still scenes.

It's been a good decade since I've worked with this stuff, but I still know a great deal of it.

No, it's a half-frame (even or odd lines only) every 59.94s, it's still 29.97 full frames per second.

Well, if you were somehow able to copy the feature code off of the scope (rather than just enabling the feature), and that were not possible before the hack, then I could totally see this as a DMCA violation. Hell, just the act of copying the code off of the scope in the first place would technically infringe Tektronix's copyright. However, while that answers your first question, neither of those things are happening, so it's not really relevant, no matter how much Tektronix thinks and wishes it were.

Even if it did, that information is publicly and freely available on their own website, and will remain there as it is necessary in order to facilitate people ordering the modules in question. That the contents of the module are an EEPROM, with one or two unencrypted SKUs (from their website) written to it, and a SIM slot, is entirely their own doing, and there's nothing illegal about telling someone how to write raw data to an EEPROM or wire said EEPROM up to a SIM card slot.

Fixed that for ya. That's essentially all this guy did; he wrote *unencrypted* SKU numbers, available in plain-text on the company's website, to an EEPROM and plugged it into a PCB that slotted into a configuration expansion slot on the device. That's very much akin to creating a config file that the application in your example knows to look for, with plain text values in it. That the file doesn't already exist isn't a form of protection; think about it -- if you buy the unlock for one feature, the file now exists, and it's plaintext -- no protection, just add the feature SKUs to it and enable the rest of the features in your application for free.

Actually... upon further reading, it looks like the "security" is just a list of SKUs written to an EEPROM. In other words, it's a feature list, not a security measure, and, it would appear, is not protected by the DMCA.

It's also worth noting that "accessible", in the context of the DMCA means, roughly, "made available in an unencrypted and copyable form". After this hack, the only copies that exist are the copies made by Tektronix, at their factory, and those remain just as encrypted or unencrypted as they were when Tektronix made them. Simply causing already-existing code to become executable does not meet that definition.

That said, this is covered by a completely different section of the DMCA, so, still an issue for those involved.

The problem with your analogy is that you didn't buy the race track and the rec track wasn't extra crap that was included with your car; further, there is only one track, which all users must share. The features being unlocked here did, however, come with the oscilloscope, which you bought, and of which there are many; you unlocking yours doesn't deprive someone else of theirs.

so, Motorola's e-fuses, then?