"Netflix didn't use Silverlight because it had extremely good DRM, but because nobody used it nobody had taken the time to reverse engineer it so getting the raw video files out of Netflix would be harder."

Not sure where you're getting those facts from, but Netflix does use DRM extensions in Silverlight as was pushed into using Silverlight because the copyright holders demanded Netflix to do so (just as Love Film were forced to switch from Flash as well).

It would be daft for a company who's business is based on streaming content to the masses (such as Netflix's business is) to switch to a platform that fewer people use simply because fewer people use it. No sane web company would do this unless their content was threatened to be pulled by the content owners.

Ah, interesting. I suppose they probably haven't re-evaluated that decision because they don't really have a compelling reason to care.

When the Netflix android application came out I had high hopes for Netflix on desktop GNU-ish/Linux, particularly when I learned that the Netflix application would work on rooted/otherwise open android phones. That hasn't happened though, so I guess either nobody has bothered to see that through, they got hit with law stuff, or for some reason it isn't technically feasible.

>Because nobody had taken the time to reverse engineer it

You can very easily get the raw file using Wireshark. Ever heard of protocol analysis? You don't need to reverse engineer anything to get the file.

You will get an encrypted form of it, you would still have to figure out the key which would require stepping through silverlight/netflix with a debugger as well as working around whatever tamperproofing has been added to your OS kernel when you installed it.

> software using the Win32 API

Which is all Wine provides, hence the name: Wine Is Not an Emulator.

(Alternately, I guess you could insist that glibc is a POSIX emulator on top of the OS kernel.)

(My point? All of a sudden I need a point? When did that happen?)

Technically WINE provides more than just Win32 APIs, but essentially you're right. WINE is more a compatibility layer / wrapper for PEs than an emulator.

In fact, I often make the container distinction: you have containers (Zones / Jails / OpenVZ) and you have virtual machines (VMWare / Vbox / Qemu / etc). WINE falls more into the containers category because it runs Windows PE natively on the host but in a sandboxed environment (and in an approximate sense of the term, chrooted) but with hooks that go between the host and client.

But, like with WINE, many lump containers into the virtualisation pigeon-hole as the full hardware emulation suites even though you're not actually emulating any hardware with containers.

WINE is not an emulator... and GNU is not Unix ;)

For most intents and purposes they both smell the same, but the devil is in the details.