It's so great that this is available now. Reading the title I was hoping Netflix had stepped up and made this work, but no. It's frustrating that it needs to work this way, running through wine with multiple patches but at least it works.
Don't do that. Particularly don't do that on Ubuntu, this is a pretty sure way to break something. Build a Debian package, it's not that hard. For example, use "checkinstall", it'll build automatically one for you.
make -l (--load-average) will throttle the number of make jobs, so you can specify a big -j to have many ready jobs but ensure you don't exceed run more than your number of CPUs.
Even if you have unilmited RAM, at some point context switching overhead will slow down the process as you add extra simultaneous jobs. Moreover, with the Linux BFS scheduler, optimum performace is achieved when the number of jobs is equal to the number of CPUs.
Be careful with that one. I left a very beefy (32 cores, 64GB ram) CS department server unresponsive for several minutes doing that with the linux kernel.
" 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."
Read about the FHS (while its use is evolving), it is still a good reference). Typically, stuff installed in secondary /usr/{bin,lib,...}, and primary (/bin,...) hierarchies is handled by package managers, which handle conflicts in a bulletproof way. This means that if you install some files manually that happen to be in use by some package, the system won't know about it, and if not and you install a conflicting package afterwards, the package manager will barf at you because there's a file there already. Also it will be hard to know which files to remove (e.g when upgrading/uninstalling the manually compiled software) save for a rare few that provide a make uninstall or actually reinstalling, capturing stdout and looking for which files got installed. To sum it up it is a problem of tracking and consistency.
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.
> For the casual Linux user, can you explain why './configure && make && make install' is a bad idea? Thanks.
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.
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.
> In fairness to Windows (and I never thought I would say that), .DLL files are now versioned via WinSxS
Apparently, that's not working as well as MS hoped, either from a technical or adopting perspective: From the same wikipedia article:
- However, runtime libraries in Visual C++ 2010 no longer use this technology; instead, they include the version number of a DLL in its file name, which means that different versions of one DLL will technically be completely different DLLs now.
- a bug in sxs.dll causes heap corruption, leading to application crashes. This issue is not fixed by any XP service packs. Users must manually install a QFE (Quick Fix Engineering).
It should be noted that including the version of the library in the filename has been a simple solution that's been used in Unix since the early '90s, when shared libraries become fashionable. (Oh, Ultrix - how I hated not having shared libraries when I had to use you... Luckily, you're dead now)
If only there was an easy way for a user to add a few patches to an Ubuntu package. Not hacks like checkinstall that don't do dependencies or anything. Maybe something like copying /usr/portage/app-emulation/wine to /usr/local/portage/app-emulation/ and adding an epatch command in. Or if you're lucky just save the patches into /etc/portage/patches/app-emulation/wine/.
# 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
- How do I make sure any other systems I own also get the patched version? (Gentoo: set up an overlay and commit the fixed package)
- How do I get notified when the package was updated upstream and my patch is no longer being applied? (Gentoo: emerge tells you when a new package is being installed from a different repository than the currently installed package)
You're probably going to say I should use a PPA, but not everyone is comfortable with signing up for a proprietary service and accepting their TOS. And setting up a PPA is way more complicated than maintaining a portage overlay in some VCS. And of course I have to submit a new package whenever a new version of Ubuntu comes out.
That's just Bollocks. And by bollocks I mean: another anti-consumer business deal.
There are NF clients for PC, Android, ChromeOS, Xbox, PS3, Wii, AppleTV, iPhone, and iPad, at least. They're using webkit and HTML5 under the client covers[1,2]. They're a heavily invested open source company and they use and publish tons of source code and open API's for developers [3,4].
Conclusion? They will lose some media deals if they offer a Linux port. Sucks to be us.
> They will lose some media deals if they offer a Linux port.
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!
This post is an excellent explanation why Linux on desktops is as rare as unicorns.
Imagine average computer user (consumer?), who see such post.
Breaking news! Yada, Yada. And then
./configure && make && sudo make install
From the PR point of view it would be better if such Netflix port was never done, such news would never be written.
Someone potentially interested in installing Ubuntu would come accross such news and I bet this person would never look again at Ubuntu or any other Linux.
"Get Firefox and Microsoft Silverlight working in WINE."
IMHO that's the stinky part of it. Saying "Netflix on Ubuntu is Here" is misleading when you're actually using a special version of a compatibility layer* to run the Windows version.
That's far from Netflix supporting Linux.
* that's what the compiling part is about, if you read the post there's a notice about packages being released soon.
I think it's because the person publishing this is excited for being able to finally watch the Netflix they pay a subscription for on their preferred OS.
"There is a PPA coming out soon to make installation much easier. If you are not comfortable with compiling software in linux, I recommend waiting for the PPA."
Several months from now, if you google "netflix ubuntu," you'll get easy hand-holding instructions that don't involve the console at all.
I thought the idea behind Netflix using Silverlight (instead of flash, which would presumably allow Netflix to normally work in Linux, like youtube or amazon instant video) was that Silverlight had super-duper DRM stuff that did nonsense with TPM.
If it works with WINE, I am guessing the situation is not quite that simple?
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.
Most computers don't have TPMs but Netflix runs on any Windows OS that has Silverlight. In the end, it is still software using the Win32 API, it just required implementing some Microsoft-specific functionality they had going on.
I do wonder how the Netflix apps not on Microsoft platforms work though. The Android, iOS, and game console versions mainly.
"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.
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.
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.
Ripped from a source you have legal access is undetectable in most cases.
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?
I wasn't aware that it did. My only personal experience with Netflix on windows was Netflix being very very strict about my windows installation being up to date and verified (or whatever the terminology was). This was 2007/2008 or abouts though.
Is there a reason then that they use Silverlight instead of flash?
No! Silverlight & WINE? Horrible! I would have preferred pure HTML5 solution. Btw. I just cancelled my Netflix account a few months ago and told them to have fun with their MS Silverlight.
In Netflixes defence, they are dealing with an intrenched, politically influential, and absurdly powerful media sector that is used to monopolistic business and bleeding customers dry on their terms. Any ground netflix takes is given hesitantly, and their use of Silverlight was probably a mandate by some suits who thought Flash was too vulnerable to people taking their precious ones and zeros and saving them outside the app.
It's kind of funny how dedicated they are to securely rendering the video when you can just screen capture and record whatever you are watching.
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.
Yup, Lovefilm was also forced to switch to Silverlight. The content providers haven't learned anything from the mistakes of the music industry. This is going to end badly for them.
I doubt it. They'll continue to thrive because enough people will jump through their hoops. and they'll give up juuuuust enough ground to keep people agreeable.
How'd that work out with music and books? Amazon and iTunes became powerful players _because_ the DRM created lockin and they ended up controlling the customers. Publishers are stuck now that they gave control to Amazon and helped Kindle become a proprietary success.
The video producers seem to be running along, handing over the same control to folks like Apple and Microsoft. Not a good strategy long-term, when they want to make DRM go away and sell to any old platform. By then, people will be locked in via their collections on iTunes or whatnot.
Amazon Video (who coincidentally owns Lovefilm) uses Flash and continues to do so; so I'm not entirely convinced that the studios were the major role in Loveflim's switch.
I have considered taking a principled stance like you, but then I always remember that my primary linux computer probably couldn't play back netflix video even without any DRM... and I have a Roku.
I would be interested in seeing a breakdown of how much of their traffic comes from PCs/Macs, and how much comes from various tablets/consoles/phones/etc. The impression I get from the people I talk to is that most people use the later these days.
for about 10 seconds I was thinking about restarting my Netflix sub. Then I read part of the article and found it wasn't a native solution or Netflix who was stepping up.
I would - as someone who owns zero Windows machines, this means that I can actually use Netflix as opposed to - well, not.
Amusingly, this was literally the last thing that I still wasn't able to do on Linux that I wanted to - GNU/Linux is a fully capable OS, but DRM is quite a nuisance.
There are two things I miss on Linux: my collection of games and half of my battery life. I do virtually everything on Linux, but when on the road or in the mood for a game, well, there's not much of a choice.
My understanding is that netflix uses silverlight for DRM reasons. What I don't understand though is how this drm is effective or why there aren't popular tools (I am guess there actually are tools though) that circumvent this DRM. Fundamentally, there is a buffer for your screen where the content is being written with a 4 bytes or so per pixel right? Presumably there is something similar with audio?
To me it seems like the best way to avoid all of this DRM garbage is to make effective ripping programs. If you did it right you could even use it as a dvr and then watch your media offline locally.
Even if you could rip at the raw 24bpp RGB output and streaming audio, you are talking 356MByte/s (20GByte/m) of data for 1080p. People want the original streams because they have already been nicely compressed.
Now sure, you can then recompress this stream, if your CPU is able to compress it in real time as Netflix sends it to you. You'll double your compression artifacts, and any dropped frames compensating for your CPU speed or bandwidth will be lost forever. The end result will probably be between VHS and camrip in terms of quality.
If someone really wants a rip, it's easier to get the decrypted form from a DVD or Bluray. Plenty of people have already done the work packaging most stuff like this anyway.
> What I don't understand though is how this drm is effective or why there aren't popular tools (I am guess there actually are tools though) that circumvent this DRM
Because there's no point - Netflix's selection is limited enough that it's still easier and faster (and less work) to pirate the content from DVD rips (available on Bittorrent, etc.), in which case you get the added benefit of much higher quality.
In other words, the only reason that Netflix isn't used for piracy is because the platform is still "inferior" to the existing piracy options already available!
not sure i agree with you - Prime has a decent selection, but is organized in a very frustrating way compared with Netflix. While netflix bundles tv-show seasons, you find yourself adding season after season to your 'watch list' on prime (which they only recently implemented - before that you didn't even have a queue). Also, their Roku/PS3 apps are much more painful to navigate with repeated movies (the standard def version and HD version), fewer categories, and i've often had problems where the movie/show will cut out consistently. More or less if i can't find the show/movie on netflix i'll search prime, but other than that, prime is best for the 2-day shipping.
You can stream video on Ubuntu on Hulu right now without having to set up some custom wine/silverlight anything. Just point your web browser to Hulu and start watching.
On Ubuntu it involves chroot, because Wine is apparently fundamentally dependent on a 32-bit architecture. Probably related to it implementing the Win32 API.
I am surprised that there is no Netflix for Boxee/Android reverse engineering taking place. Both Linux devices with fully working Netflix clients and no WINE.
I pay for Netflix because I feel it's an okay value to get a few things I like to watch. I don't mind paying a reasonable price for media, but in exchange I want it when I want, on the device I want. I don't blame NF here, I blame the content holders.
In addition to restricting what I watch, the content holders are also only selling half to NF. Most series they'll sell a few seasons and reserve the rest locked up, hoping you'll buy a disk from them. Suck.
