Sabayon 14.01 is a modern and easy to use Linux distribution based on Gentoo, following an extreme, yet reliable, rolling release model.
This is a monthly release generated, tested and published to mirrors by our build servers containing the latest and greatest collection of software available in the Entropy repositories.

The ChangeLog files related to this release are available on our mirrors.

Linux Kernel 3.12.5 with BFQ iosched, updated external ZFS filesystem support, GNOME 3.10.3, KDE 4.11.4, Xfce 4.10, LibreOffice 4.1.3, UEFI SecureBoot support for 64 bit images (with bundled UEFI shell), systemd as default init system, a greatly improved version of the Entropy package manager supporting concurrent activities (like parallel installation of applications) and PackageKit 0.8.x support with backend parallelization enabled. Last but not really least, the integration of Steam and a new install profile called Steam Big Picture mode (also improperly known as SteamBox on my blog) that turns your computer into a powerful Linux gaming machine.
These are just some of the awesome things you will find inside the box.

Please read on to know where to find the images and their torrent files on our mirrors.

Steam Big Picture mode

Following our well appreciated Media Center mode, that lets you convert your computer into an XBMC-based media center, we're now offering a way to get away from the boring Christmas movies and start doing something more serious: gaming, on Linux. Our KDE and GNOME images come with Steam preinstalled and ready to be launched. In addition to this, a new boot and install mode called "Steam Big Picture" (formerly and improperly known as SteamBox mode) is now available letting you turn your computer into a real Linux gaming console, no matter if it is NVIDIA, AMD or Intel GPU-based.

Parallel Entropy, parallel PackageKit

It took a couple of months to be ready for prime time, but we're happy to announce that Sabayon 14.01 is being shipped with Entropy 254, containing true parallelization support. Installing and removing packages simultaneously while querying the system repository is now possible and the Big Entropy Lock is in the process of being completely removed (the brave-new-lock-2 feature branch is now live) and future Entropy releases will be able to install and remove packages in parallel within the same transaction, to squeeze all the possible I/O and CPU capacity available on modern systems.
The new PackageKit 0.8 Entropy backend now has parallelization enabled as well and, thanks to the extensive use of lazy loading of resources, offers an unprecedented request latency.
Entropy Client and Server modules are going through a complete API refactoring.

1-Click updates, passwordless upgrades, reliability improvements

With the advent of Entropy 254, we have also been able to improve the ease of use and effectiveness of our graphical frontends, Rigo (a Google-like package management system interface) and Magneto (a RigoDaemon notifications frontend), enabling users to rapidly update their systems as soon as possible through the 1-Click update button (that is only offered when a certain set of requirements are met) in order to ensure a better protection against potential security flaws. Starting from Sabayon 14.01, any user in the "entropy" group, will be allowed to update the system without entering the administrative password. If you believe that your users should not do this, just consider removing the "passwordless-upgrade" package or the local users from the entropy group.

System upgrades are now protected against incomplete, broken or circular dependencies at the library linker level by the new "preserved libraries" Entropy feature, a concept borrowed from the Portage package mangler. Basically, this translates into increased reliability of upgrade paths, especially in scenarios where the system being upgraded was largely lagging behind. Libraries are preserved on the system as long as there are executables needing them. They are then garbage collected and removed as soon as this doesn't hold anymore. A side effect of this is that mixing Portage and Entropy has become safer.
LTSI Linux Kernels, 3.4, 3.10 now offered

We are now tracking the 3.4 and 3.10 Long Term Stable Linux kernels, offering (almost) same-day updates to them. If you are using Sabayon in a server environment, you surely welcome this. However, if you're using Sabayon on your laptop, desktop workstation, switching between kernels or just moving to a new version has become a no-brainer operation through Rigo: just go to the preferences menu, select the kernel menu (LTS and regular kernels are listed in separate menus), pick a kernel and click "Install". Rigo will take care of updating external modules in a reliable and safe way on your behalf.

Python 3.3 offered side by side with Python 2.7

Python 3 is being slowly but steadily adopted by many open source projects. While we believe that Python 3.x still needs some more work, we are starting to prepare a migration plan that will be hopefully rolled out in 12-18 months.
If you want to experiment with Python 3.3.3, you may be happy to know that we are shipping with it!

GNOME 3.10.3, Cinnamon 2.0 (in repositories only), sheeeesh

GNOME 3.10 was long awaited by our users, but we had to make sure that openrc users had the time to catch up with us with regards to the compatibility problems and move to systemd, which is now a hard requirement. If you loved GNOME 3.8 (who did? sarcasm...), you may be more than happy to jump to the 3.10 bandwagon.
Together with the GNOME 3.10 bump, we kicked out Cinnamon 2.0, which has been available in our repositories before Linux Mint (ihihi hi there!) made a new ISO. Enjoy Cinnamon with a cup of hot chocolate (unless you live in Australia, in that case well, enjoy Summer).

Tracking the Portage tree has been a success

In 2011 we first started to design a tinderbox tool to track fresh ebuilds and have the resulting binary packages pushed to repositories automatically. After two years, we are happy to report that 90% of the bump work is carried out automatically by simple scripts (yeah we managed to replace people with simple scripts, not entirely bash based though). By defining bump rules and constraints, we are able to reliably offer the perfect mix between bleeding edge and stability. As someone said once: "if you do your job perfectly, the world doesn't know you exist", and this seems to be exactly the case. This is how we think continuous building and rolling release should be done. Testing is the secret sauce.