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?

Funny, when I'm searching youtube for boobs and penises, all I get is IT-related stuff!

You don't always need to rely on what others tell you; it's called the power of observation. For things you can't learn through pure observation, yes, you rely on others, but you don't do so blindly, you use those very same powers of observation to tell when what you're being told isn't working or isn't going to work. Will you, yourself, sometimes be wrong? If course, because that, too, is part of learning. I'm sorry I didn't go into enough detail for you, but I'm writing a Slashdot comment, not a Ph.D dissertation; this is something I'm doing for leisure so I might not always maintain your perfect standards of detail. It's funny we should be in disagreement on this point when we're clearly actually not. A source needn't be broadly reliable or unreliable, but for a certain piece of information, yes, a source is either reliable or unreliable; people need to be taught, at the very least, to discern whether a piece of information they are looking at is more potentially accurate or potentially inaccurate and seek out additional sources as necessary, rather than simply relying on a source because "well, I don't know, this guy sounds smart, so he's probably right, I can't check the information for myself because reasons".

Or it means I said re-implement instead of port. for something I'm doing because "that might be fun", that not-so-fun (for me, at least; if you like porting between languages, more power to you) task is a good enough reason to walk away.

You must've been replying to a different post...

My point was that's how you teach people to learn. This is early-childhood stuff, if it's not done by kindergarten or 1st grade, it's probably too late. Once they've learned how to learn, they'll quickly pick up how to apply new things they learn, and the rote memorization of facts our students are expected to do for the entirety of their education suddenly becomes easier, because they've been shown how to find uses for the things they're being taught.

If we can't afford enough kindergarten teachers to keep the classes down to manageable sizes for this, we're already fucked.

Not gonna disagree with that assessment, either. It's not like industry has never been wrong before. I mean, really, the web design community is heading toward vertical-parallax, perpetual-scrolling monstrosities that give 10% of users headaches (literally) and can't be properly bookmarked or navigated. The industry is following them down that path!

There's a reason I'm not following suit: I prefer to make things that are actually usable! Yes, it's cool to add this or that new feature and make it look nice. Everyone wants to feel like what they're building or using is cutting edge, and that's just fine, right up to the point where you start breaking usability in the name of design.

Go ahead, re-implement the select box so you can ensure that it looks the same in all browsers, across all platforms. Add type-to-search and autocomplete to it. I'm all for that, you're improving the UX... unless you don't also handle switching between selections with the up and down arrows, entering and exiting the field via the tab key (trivial if you use a *real* select box and follow progressive-enhancement, replacing the select *for display* with your new control, this is not only possible, but trivial), and confirming the highlighted selection via the enter key. If you don't implement the functionality people are expecting *before* extending, then you're actually *breaking* things. And if you can't implement the native behavior it in a handful of lines of code, you probably shouldn't implement the control at all; most likely, any extensions you make will be inefficient and clunky, as well. But, I digress...

Creating GUI apps on the desktop isn't much better, in reality. You still have a multitude of languages; the application language and GUI framework, which is typically a language of its own (WYSIWYG form builders only carry you so far), if your application interfaces with a database you still have some form of SQL, and that API you need to interface with to access that bit of data from that 3rd party service? If you care about performance, you're proxying API calls through a local server that caches the results; if you need to intelligently clear or refresh bits of that cache based on some bit of application logic, you may need something more sophisticated than a simple HTTP cache, so there's your server-side application language. Don't get me started on version headaches with libraries...

I may have been born in the 80's, but I agree... they'd have laughed and taken away your beer if you had told somebody that programming the web was going to be so much worse than writing native applications. Hell, that's a good way to lose your beer today!