Friday, October 10, 2014

Netflix arrives to openSUSE without dirty tricks, yes natively.

Naturally, if it were so simple one would not need an article. There has been a lot of news floating around about +Netflix finally being available natively for +Linux. In case you are not aware, getting Netflix on Linux was a labored and complicated process requiring all sorts of WINE hacking or virtualization. +Microsoft had announced that its strategy would be changing away from Silverlight which Netflix has depended on for their DRM content delivery. Netflix then announced they would be dropping Silverlight in favor of +HTML5 once some DRM framework was developed so they could secure their licensed content. Naturally this announcement was greeted with excitement from Linux desktop users all over, excepting of course those whom are absolutely opposed to DRM.

In the last couple of days, there has been a flurry of articles and tutorials on how to get Netflix to work natively. Most of these of course are claiming that it is +Ubuntu only, though this is absolutely false. The new HTML5 DRM video delivery is enabled by Network Security Services which have been around for a long time, but have only recently acquired the Encrypted Media Extensions for the sort of secured DRM necessary for Netflix. While +Android and Chrome OS had Netflix, this left people wondering why not desktop Linux since the two other operating systems use the Linux kernel too. On Chrome, Google developed a special plugin to provide the DRM to allow Netflix to work, while on Android this was facilitated by an app that had the DRM built in.

So now we have working DRM thanks to Google, Mozilla, and many other parties. Firstly, you need NSS 3.16.2 or greater and the +Google Chrome browser version 37 or higher. You will need to go into your Netflix settings and tell it you'd prefer the HTML5 player. Upto very recently you'd need to have your browser falsely identify itself as another browser to get it to work, but this is no longer necessary. At present Chromium and Firefox cannot run Netflix. +Mozilla Firefox will be getting support as well, but it'll be reliant on a proprietary Content Decryption Module or CDM from +Adobe beyond their more conservative approach with a greater focus on privacy and security. This module would most likely be delivered in the same fashion as the +Adobe Flash Player.

Tuesday, October 7, 2014

Sneak peek at openSUSE 13.2; hands on with beta 1

I've been running the beta 1 of 13.2 for a few days now, and there are lots of interesting and welcome changes. Overall it is surprisingly bug free, and I anticipate it will be a very smooth release (at least on +GNOME since I don't use KDE). Now, if you want to know what versions of packages are included you may take a look at this post. I on the other hand want to introduce you to the things that you may NOT know, and that are particularly interesting.

So we have long heard that btrfs would be replacing EXT4 as the default file-system in +openSUSE and many other distributions eventually. Generally it is ready and eventually will outstrip EXT4 and other file-systems for speed as well as it's many other compelling features. However as of yet it still suffers from being a bit too slow. Thus, if you use a separate /home partition you'll notice XFS is being proposed as the default. For some of you this makes sense, but if you are like me it came as quite a surprise. Last I knew XFS was recommended for ridiculously huge volumes and suffered performance issues that made it impractical for domestic use. Naturally I wanted to get to the bottom of this. +Greg Freemyer offered the following explanation:
XFS was designed for high-end systems including supercomputers.The design is 20 years old, so many of the features it incorporates work well on current multi-core laptops and PCs.

During the decade from 2000-2010, XFS had a well deserved reputation of working very inefficiently with small files.  In the 2010/2011 timeframe XFS received major improvements related to metadata handling. This had a huge positive impact on how well XFS works with small files. The key concept is that journal is now maintained initially in RAM. Prior to streaming a large junk of journal information to the disk journal, it is now elevator sorted.

That means when the actual on disk updates are done by applying the journal, the disk head will follow a series of disk seeks all in the same direction. This drastically cut down on long disk head seeks when working applying the journal. The end result was drastically faster speeds when working with small files on rotating media.

ext4 on the other hand was designed for previous generation
computers. Although it can scale to the sizes needed today, it simply was not designed to handle that heavy workloads and massive scaling that modern laptops and desktops can demand.  As such, ext4 is rapidly approaching end of life.

The envisioned replacement for ext4 for the last several years has been btrfs. Unfortunately, btrfs has not yet achieved the performance levels needed to take on heavy workloads.
Though EXT4 is being developed still, it is too old to really cope with modern use cases. In benchmarks vs. XFS newer iterations of EXT4 were nearly able to catch up to the speed of modern XFS, but with one caveat; the journal had to be disabled, which as you probably know is a horrible idea leading to corruption and fragmentation of your data. For some further reading I suggest this article from +SUSE.

Now as you may know, YaST was recently rewritten in the Ruby language. A big reason for this is that only about two people at SUSE knew the language it was written in before called the YaST Markup Language or YML. This of course made it difficult to maintain, and even harder to get community contributions for. Thankfully this has worked out and we've been seeing lots of work on YaST, cleaning up code and modernizing it; adding stability and speed improvements across the entire suite. Our installer even is a YaST module and has seen improvements thanks to the switch to Ruby as well. The improvements are obvious with quick and responsive action across all of YaST. The installer has seen benefits of this as it is quicker, smoother, and more responsive than ever across any of the cards. A new card has been added allowing network configuration (no idea if it works with wifi at all since it isn't the NetworkManager) which among other things allows you to set the hostname for your computer. The interface itself has seen a nice facelift, now with a cleaner more readable experience. In the partitioning scheme card there is a simple modifier dialog that will allow you to set non-default file-systems as well as a check box for expanding SWAP to allow suspend. GRUB2 is now not only default, but the only supported bootloader and has seen bugfixes and obvious speed improvements. Also so far as installation is concerned this has become immensely faster, completing before I can even finish a cigarette. This improvement is due to streamlining the installation process; in the past it would make a large number of mkinitrd calls, whereas now it should only make one call at the very end of the process.

Overall this is turning out to be a very exciting release. And with as good as it looks in this early beta, I anticipate raving reviews. Please consider helping test this release, and file your bugs at our own Bugzilla.