Випуск дистрибутива Sabayon Linux 14.01

Представлено реліз дистрибутива Sabayon Linux 14.01, що поєднав у собі зручність для користувача з гнучкістю Gentoo. Sabayon Linux оформлений у вигляді Live -дистрибутива, з можливістю легкого встановлення на жорсткий диск. Sabayon використовує модифіковану rolling-модель підготовки оновлень, яка робить випуск оновлень більш передбачуваним і менш болючим. Дистрибутив доступний в збірках з KDE 4.11.4 (2.4 Гб), GNOME 3.10.3 (1.9 Гб) і Xfce 4.10 (1.6 Гб).

Пакетна база дистрибутива синхронізована з колекцією портажів Gentoo і повністю сумісна з Portage 2.2 (EAPI2), користувач має можливість встановлення програм як з вихідних текстів, так і використовуючи готові бінарні пакети, зібрані для платформ ARMv7, x86 і x86-64. Для x86 і x86-64 в репозиторії налічується близько чотирнадцяти тисяч пакетів, а для ARMv7 — понад дві тисячі. Пакети оновлюються безперервно (rolling -реліз), надаючи користувачеві доступ до найсвіжіших версій програм. Для керування пакетами підготовлений GUI інтерфейс «Rigo» і консольна програма «equo». Для встановлення дистрибутива використовується інсталятор, заснований на вихідних текстах проекту Anaconda, що розвивається в рамках Fedora Linux. Для ініціалізації та управління службами застосовується systemd. У комплекті поставляється повний набір всіх необхідних мультимедіа кодеків і пропрієтарних драйверів для відеокарт, бездротових адаптерів і софт-модемів.

Особливості дистрибутива Sabayon Linux 14.01:

• Дистрибутив поставляється з ядром Linux 3.12.5 та планувальником введення/виведення BFQ і підтримкою файлової системи ZFS. Додатково доступні для установки пакети з ядрами Linux 3.4 і Linux 3.10;
• Оновлені версії програм, у тому числі GNOME 3.10.3, KDE 4.11.4, Xfce 4.10, LibreOffice 4.1.3. У репозіторіях доступний Cinnamon 2.0;
• Включення в базову поставку збірок з KDE і GNOME клієнта для сервісу доставки ігор Steam і підготовка профілю для запуску клієнта Steam в режимі Big Picture (запуск проводиться за аналогією з входом до сеансу медіа-центру на базі XBMC);
• Оновлення пакетного менеджера Entropy 254 з підтримкою паралельного виконання операцій, наприклад, тепер можна одночасно виконувати встановлення і видалення пакетів. Підтримка паралелізму також додана до бекенду PackageKit 0.8 Entropy.
• Розширено можливості Rigo, інтерфейсу до Entropy для керування установкою програм, що прийшов на зміну додатку Sulfur. Rigo відрізняється сучасним дизайном інтерфейсу, виконаним на базі Gtk3+ і орієнтований на активне використання пошуку. Безпосереднім виконанням операцій з пакетами займається спеціальний демон RigoDaemon, взаємодія з яким організована через DBus. У новій версії Rigo реалізована можливість оперативного виведення повідомлень про наявність оновлень з підтримкою встановлення оновлень в один клік, без необхідності введення пароля адміністратора (для оновлень без пароля користувач повинен бути включений до групи «entropy»).
• Крім Python 2.7 надана можливість використання Python 3.3.

via

Лінус Торвальдс розкритикував дії Red Hat з просування підтримки UEFI Secure Boot з ключами Microsoft

У списку розсилки розробників ядра Linux розгорілася бурхлива дискусія про доцільність пропозиції інженерів компанії Red Hat по включенню до складу ядра механізму динамічного завантаження X.509 сертифікатів з виконуваних файлів у форматі PE, для їх використання з метою верифікації завантажувальних модулів.

Суть ідеї в тому, що сервіс компанії Microsoft, який здійснює формування цифрових підписів для завантажуваних в режимі UEFI Secure Boot компонентів, підтримує тільки інтеграцію сертифікатів у виконувані файли PE, тому розробники Red Hat запропонували включити в ядро ​​функції завантаження ключів з PE-файлів, щоб забезпечити в режимі UEFI Secure Boot можливість завантаження пропрієтарних драйверів і компонентів, завірених ключем Microsoft.

Спроба просунути в ядро ​​подібний код викликала потік обурення з боку Лінуса Торвальдса, який в притаманній йому жорсткій формі висловив абсурдність інтеграції засобів для управління сертифікатами X.509 і парсинга PE-файлів безпосередньо до ядра, а також безглуздість підлаштовування ядра обхідними шляхами під особливості стороннього сервісу Microsoft, замість того щоб в сервісі Microsoft забезпечити створення підписів для модулів ядра Linux.

На думку Лінуса Торвальдса, якщо компанії Red Hat необхідно забезпечити завантаження підписаних ключем Microsoft компонентів, чому б не виділити окрему машину, на якій буде виконуватися розбір PE-файлів, перевірка сигнатур і підтвердження результатів ключем Red Hat, після чого використовувати вже присутні в ядрі засоби підтримки сертифікатів X.509. Якщо якась компанія має намір поставляти верифікований бінарний модуль для Fedora або RHEL, то для створення цифрового підпису повинен використовуватися ключ Red Hat, без спроб створення зовнішніх залежностей від ключів Microsoft.

via