Netflix on Ubuntu Is Here

It isn't necessarily, given that the Autotools configure installs to /usr/local by default, which is a directory tree explicitly reserved for installation of software outside the package system.

Installing shared libraries can cause problems, but that's rare because shared libraries are versioned in Linux, as opposed to Windows, which greatly reduces the incidence of DLL Hell. In short, a program might find a shared library that isn't the one it wants, but it very likely won't.

Similarly, installing your own executable files might cause problems for scripts. This could be more serious, but, in practice, I've installed a newer version of Perl outside the package system and everything works fine.

The biggest hassle of doing things outside the package system is the simple fact you don't have the package managers doing the scutwork for you. You have to do your own dependency tracking, your own configuration, and your own update management. There is no really easy way to uninstall anything. You quickly come to realize why we have package management in the first place, if you really go nuts with this stuff. ;)

So. The easy advice here is "Wait for the PPA", which the post itself mentions a few times. That will give you a nice little package, albeit not one from the official repos. I do that with VLC and couldn't be happier. But doing this little dance with Wine, building it yourself, is unlikely to cause problems if you follow the instructions.

In short, if you ever want to build software yourself there are two possible destinations, and hence two solutions:

- put it in primary/secondary hierarchy: make a package for your package manager

- put it in tertiary hierarchy (/usr/local) or optional software (/opt/your_software_name): use PREFIX/--prefix or whatever idiom the build system uses for controlling where the files will end up. More often than not with tertiary you don't even need to set up PATHs and include directories (think library and dependencies) and whatnot.

" Use CheckInstall instead of just running "sudo make install", as that will likely put files all over the filesystem, with no easy way of removing them if things go wrong. If in the future you try to install a package that contains the same file as the software you are compiling, you will receive errors and the software you compiled may stop working."

    # Get the source
    apt-get source $package

    # Copy the patch in
    cp my_patch.diff $package-$version/debian/patches
    echo "my_patch.diff" >> $package-$version/debian/series
    
    # Build the package
    dpkg-buildpackage -us -uc

    # Install the newly built package
    dpkg -i package.deb

To be honest, no, they won't.

In fact, they'll likely lose some if they do. They've been able to sell some media execs on the (false) premise that Silverlight == DRM == security == anti-piracy, so as long as Silverlight's DRM remains unavailable on Linux (ie, until the end of time), they won't offer official support on Linux.

The alternatives for them would be to

a) use Silverlight, but without DRM so that Linux users can use Moonlight.

b) use Flash

c) use some other technology

(A) will never happen because they'll lose all their deals. (B) will never happen for the same reason. (C) will never happen because it would take too much time to roll something from scratch, and even then you have the same problem of DRM.

So, at the end of the day, DRM once again gives users every incentive to pirate rather than pay!

Is there a reason then that they use Silverlight instead of flash?

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.

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?)

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.

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.

Downloading a copy over the net that someone else ripped can be detectable.

That being said, I agree that piracy is just piracy. In my mind grabbing something from bittorrent/usenet is the same as using a VPN provider to stream from a different country, is the same as watching an illegal streamed copy on some website, is the same as ripping a copy from a friend/public library.

Did you pay to access it? Does the copyright holder make it freely available? No?

Then it's piracy.

It would be incredibly inefficient to do so, but I could see ways to improve and replicate this approach (like doing this on multiple computers, etc.). You will just end up with the same result.

What? Why is that the case? Unless you have some incredibly old and/or underpowered hardware...