Действия после установки openSUSE Leap 15.4

Уже около месяца я ежедневно использую дома свежий релиз Leap 15.4, и он мне очень нравится. В этой заметке я хочу перечислить несколько небольших доработок, которые я сделал в системе. Некоторые я уже ранее упоминал, но настало время собрать их все в одной записи. Итак:

Доработка загрузки

Если у вас установлена только одна ОС, то загрузчик GRUB2, собственно говоря, не нужен. На UEFI-системах можно загружать ядро Linux сразу, о чём я писал в своё время. Нынче этот приём называется systemd-boot, но самой технике уже сто лет в обед. Например, мой предыдущий компьютер с материнской платой DH67BL-B3 из 2011 года уже умел это делать. Команды ниже добавят в ПЗУ загрузочную запись и заодно отключат вывод системных сообщений при запуске и выключении ОС (всё равно, на десктопе это не нужно):

sudo -i

sudo cp /boot/vmlinuz-5.14.21-150400.22-default  /boot/efi/EFI/opensuse/vmlinuz.efi
sudo cp /boot/initrd-5.14.21-150400.22-default  /boot/efi/EFI/opensuse/initrd.img
efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "opensuse-silent" -u --loader '\efi\opensuse\vmlinuz.efi'
"root=/dev/sda2 initrd=/efi/opensuse/initrd.img resume=/dev/nvme0n1p2 console=ttyS0 vt.global_cursor_default=0 quiet"

systemctl disable getty@tty1.service

NB: Замените /dev/nvme0n1 на адрес своего жёсткого диска

Результат этих действий такой: включение ПК теперь напоминает включение смарт-ТВ или какого-либо бытового прибора: на экране появляется логотип производителя материнской платы, а за тем, через несколько секунд — без мерцаний или чего-либо ещё — сразу рабочий стол. При выключении, опять же, в верхнем левом углу не отображается ничего, экран просто гаснет. Это красиво и изящно, к тому же довольно удобно именно на openSUSE Leap, где ядро почти не меняется, а значит файлы vmlinuz.efi и initrd.img можно обновлять нечасто. Если нужен журнал загрузки, то под рукой всегда есть команда journalctl -b. Также, не будем забывать о том, что обычная запись для GRUB2 в EFI никуда не делась, и можно всегда вернуться к ней. Очень удобно прямо из ОС перезагрузиться в системный интерфейс EFI setup utility следующей командой:

systemctl reboot --firmware-setup

Заодно, я хочу порекомендовать графическую утилиту для управления EFI-записями. Выглядит изящно, умеет многое:

EFI Boot Editor — графический интерфейс к консольной программе efibootmgr

Добавление прав на управление принтерами

Тут мне особо нечего добавить, см. мою прошлогоднюю заметку. Время идёт, а мейнтейнеры openSUSE по-прежнему считают, что у пользователя не должно быть прав на управление печатью. Ну такое…

Исправление работы Packagekit и Discover

Изначально, Packagekit преследовал благородную цель унифицировать управление пакетами в разных дистрибутивах Linux. Не важно, что вы используете — Debian/Ubuntu, Fedora, openSUSE или Manjaro — вы всегда можете обновиться командой pkcon update или установить локальный пакет командой pkcon install-local <файл>. Удобство достигается различными бэкэндами к Packagakit, среди которых есть и Zypp для Zypper в openSUSE. Проблема, однако, в том, что если вы в openSUSE Leap попробуете открыть скачанный RPM-файл в Discover (интерфейсе к Packagekit), то установка гарантированно завершится ошибкой. Всё дело в неспособности бэкэнда Zypp обрабатывать некоторые события от Zypper, например проверку подписи пакетов. Я выяснил, что если проверку подписей отключить, то Discover начинает работать как надо. Следует в конец файла /etc/zypper/zypp.conf добавить gpgcheck=0, этого достаточно. Формально, вы понижаете безопасность, но фактически на десктопе от подписей GPG толку особо нет.

Discover вполне умеет устанавливать локальные пакеты после небольшой доработки

Решение проблемы с korner bug

Korner bug — это просторечное название очень раздражающего визуального дефекта, который проявляется последние пару лет в Plasma. Чтобы его увидеть, нужно включить эффект «Размытие» и установить декорации окон со скруглением углов. Вы быстро заметите, что уголки окон не имеют прозрачности и на некоторых фонах выглядят ужасно.

Этот баг пробовали решать и так, и эдак, но в каждом случае были оговорки, и проблема полностью не исчезала.

Я нашёл надёжное решение, которое наконец-то всё исправляет. Если вы будете использовать эту версию LightlyShaders, то скругление окон будет происходить корректно.

Более того, в настройках эффекта есть возможность использовать «сквиркл» — квадратоокружность, которая, например, используется в macOS. Как обычно, в Plasma вам даётся больше функций, чем вы просили: LightlyShaders содержит ползунок, регулирующий степень похожести круга на квадрат. В яблочном саду занервничали…

Наконец-то, скругление окон работает корректно!

Решение проблемы с «дёргающимися» значками на рабочем столе

Наконец, последним в моём списке идёт баг со странным поведением значков на рабочем столе Plasma. По умолчанию, они выровнены горизонтально относительно верхнего левого угла. Но если тип выравнивания изменить, то вы вскоре заметите неприятный дефект: при загрузке рабочего стола значки как будто снова выровнены по-умолчанию, но стоит щёлкнуть по рабочему столу, как они «улетят» согласно вашим настройкам.

Мне стоило большого труда откопать в переписке разработчиков Plasma обсуждение этого бага, который время от времени всплывал снова и снова. Оказалось, что решение существует. Влад Загородний предложил патч, который исправляет ошибку. Патч отключает функцию прокрутки значков на рабочем столе: если у вас их запредельно много, и они не влезают на рабочий стол, то это патч вам навредит. Но, на мой взгляд, так много значков не бывает почти ни у кого, так что всё в порядке! Скопируйте патч в директорию и примените его:

sudo cp 0001-foobar.patch /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/

cd /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/

sudo patch -p6 <0001-foobar.patch

Да, при следующем обновлении пакета plasma5-desktop всё вернётся обратно, и так до тех пор, пока проблема не будет решена в апстриме. Но, какое-никакое решение есть уже сейчас.

На этом всё, спасибо за внимание!

Новый репозиторий для openSUSE

Я всё таки собрался с силами и освоил Open Build Service (OBS), на котором собираются сторонние пакеты для openSUSE (и не только). Необходимость в этом была у меня давно, особенно в свете того, что мой предыдущий репозиторий для Rosa Fresh стремительно терял актуальность вместе с актуальностью самого дистрибутива. Пришло время перенести наработки в новый «домашний» репозиторий для openSUSE. С этой системой я уже давно на «ты». Я начал пользоваться ею с самых первых версий, когда Novell переименовала SUSE в openSUSE в 2006 году. Версиями 10.3-13.1 я пользовался непостоянно, меняя их время от времени на что-то ещё, начиная с 13.1 openSUSE стояла у меня второй системой, а с 15.1— первой. Пока полёт нормальный).

Мой новый репозиторий живёт по следующему адресу:
https://download.opensuse.org/repositories/home:/linuxphoto

Пока что там немного ПО, но уже есть кое-что интересное! Я начал со сборки тем оформления для KDE Plasma 5. На данный момент для версий openSUSE Leap 15.2 и 15.3 собраны:

1. KDE2 Decoration. Это порт классической темы из KDE2 для современного компонента KDecoration2, используемого в Kwin5.

2. Breeze Enhanced. Это форк темы Breeze для декораций окон. Здесь можно настраивать очень много параметров, включая прозрачность заголовка. По это причине Breeze Enhanced хорошо сочетается с полупрозрачными темами Kvantum: вместе с эффектом Blur можно делать полностью «стеклянные» окна.

Первая из двух картинок моя, вторая — из Интернета (я сейчас под ВМ, так что прозрачность толком не показать). Тут нужно заметить, что Breeze Enhanced имеет изъян в виде «треугольников» в местах скругления окон. Это особенность данной темы.

3. Hello Decoration. Это ещё одна тема в стиле macOS. Здесь нет поддержки прозрачности, зато в остальном исполнение просто великолепное! Тема поставляется только для Kwin (не для виджетов Qt5), но зато тут в комплекте идут шейдеры для скругления окон.

Внимание на рамку окна!

4. Skulpture-Qt5. Это очень красивый и незаслуженно забытый стиль оформления для Qt4/5. Изначально в нём была также и тема декорации окон, и развитый конфигуратор, и даже пакет для openSUSE 12. Но теперь всё это изрядно поросло мхом времени. К счастью, автор Skulpture успел портировать этот стиль на Qt5, и именно этот порт я и опакетил.

Тут наоборот: внимание на кнопки!

5. Styleproject-Qt5. На мой взгляд, это самый развитый, сложный и интересный стиль для Qt4/5. Достаточно сказать, что с его помощью в KDE4 какое-то время назад были реализованы Client-Side Decorations (CSD), текстуры, имитировавшие дерево и металл, и многое другое. В моём пакете присутствует версия только версия для Qt5, хотя в теории можно было бы собрать и для Qt4 тоже (разве что в 15.3 это сделать уже сложнее). На снимке ниже показан файловый менеджер KDFM в оформлении Styleproject.

Mavericks жив!

6. LightlyShaders. Как несложно догадаться, это ещё одна реализация Shape Corners, т.е. по сути клон того самого эффекта, который уже и так есть в составе Hello. Их можно держать в системе рядом, они друг друг не мещают. Разница в том, что LightlyShaders развиваются и нормально работают с Qt 5.15 (актуально, если вы захотите обновить Plasma в Leap), а Hello Shaders не развиваются и с новой Qt не собираются. Само по себе, скругление окон выглядит волшебно!

Пока это всё. В ближайших планах у меня перетащить в openSUSE программу для растягивания изображений без потерь (почти). Это Waifu2x-cpp и графический интерфейс к ней. Не переключайтесь))

Немного о быстрой (и тихой) загрузке

Данная запись дополняет мою прошлую заметку про загрузку Linux без экранных сообщений. В этот раз я покажу, как можно организовать загрузку в обход Grub2, т.е. обойтись без стороннего загрузчика вообще. Нам понадобится система с поддержкой UEFI и примерно 5 минут времени.

Современных компьютеров без UEFI днём с огнём не сыщешь, и даже моя рабочая лошадка родом из 2011 года прекрасно поддерживает эту технологию. В Linux имеется замечательная утилита efibootmgr, управляющая загрузочными записями прямо в ПЗУ материнской платы. С помощью Efibootmgr можно добавлять, удалять и менять приоритет загрузки этих записей. Efibootmgr может добавить запись, ссылающуюся на grub2-efi — в этом случае вы увидите меню Grub вашего дистрибутива. Но можно сразу указать путь к vmlinuz и initrd, а также произвольный набор параметров ядра, и тогда Linux будет загружаться безо всякого Grub. Если у вас на ПК установлена только одна ОС, то это прекрасный способ сделать процесс загрузки более быстрым и плавным.

Для реализации этой идеи для начала нужно скопировать образы vmlinuz и initrd из /boot куда-нибудь внутрь EFI-раздела. В моём случае это директория efi/opensuse. Я переименовал эти файлы в initrd.img и vmlinuz.efi для удобства, но названия могут быть любыми. Далее следует ввести команду примерно такого вида:
efibootmgr --create --disk /dev/sda --part 1 --label "opensuse" -u --loader '\efi\opensuse\vmlinuz.efi'
"root=/dev/sda2 initrd=/efi/opensuse/initrd.img resume=/dev/sda2 splash=silent plymouth.enable=0 quiet elevator=noop logo.nologo acpi_osi=Linux acpi_backlight=vendor audit=0 rd.timeout=120 scsi_mod.use_blk_mq=1 dm_mod.use_blk_mq=1 systemd.show_status=0 rd.udev.log-priority=3 ipv6.disable=1 loglevel=3 vt.global_cursor_default=0 systemd.log_target=null systemd.journald.forward_to_console=0 systemd.default_standard_output=null systemd.default_standard_error=null init=/bin/systemd"
На что нужно обратить внимание:

• У меня EFI-раздел находится на /dev/sda1, а корневой — на /dev/sda2 (у вас может быть иначе);
• Я отключил заставку Plymouth, указал планировщик ввода/вывода Noop, отключил IPv6 и убрал вывод сообщений на экран (тут довольно много опций, с избытком);
• Нужно не забыть передать UEFI-загрузчику путь до Systemd. В openSUSE это /bin/systemd, но в других системах может быть иначе, например в Росе это /lib/systemd/systemd.

Далее нужно указать приоритет записей:

efibootmgr -o <номер 1>,<номер 2>...

Можно просто удалить все остальные записи кроме нашей:

efibootmgr -b <номер записи> -B

Дополнительно имеет смыл залезть в UEFI BIOS и включить там быструю загрузку, когда система не показывает логотип производителя, не пытается опрашивать USB-устройства и т.д.

Мой результат: от нажатия кнопки питания на системном блоке до полной прогрузки KDE Plasma проходит 25 секунд, причём половина этого времени проходит ещё до загрузки Linux.

Вот и всё. Если ваш дистрибутив всё равно загружается слишком долго, посмотрите вывод команды systemd-analyze blame. Скорее всего, какой-то сервис инициализируется слишком долго — иногда его проще отключить.

P.S.

Для отключения неопрятных сообщений в консоли, которые мигают, например, перед выключением/перезагрузкой системы, существует простой хак:
sudo systemctl disable getty@tty1.service
Теперь у вас нет консольного терминала, но зато выглядит всё просто отлично!

KMail и Akonadi

Принято считать, что openSUSE нынче уже не тот. Ошибок, мол, много. Но вот показательный пример.

В декабре все три используемых мною дистрибутива — Rosa, OpenMandiva и openSUSE — собрали KDE Applications 18.12. Я являюсь активным пользователем почтового клиента KMail, который использует для доступа к данным подсистему Akonadi. На данный момент результаты забега следующие:

Rosa. Akonadi работает и даёт настроить почтовый ящик Gmail. Но, при попытке скачать письма валится ошибка akonadi_imap_resource. Работать нельзя.

OpenMandriva. Akonadi не работает и даже не запускается. Кое-как я смог его запустить, но настроить почтовый ящик не вышло: всё падает и отваливается ещё на этапе авторизации в Google, причём падает всё тот же akonadi_imap_resource.

Обе системы ещё не довели до ума KDE Applications 18.12. В Росе сейчас внутреннее тестирование и QA (напомню, что релиза Rosa R11 пока не было), да и OpenMandriva 4.0 всё ещё находится в состоянии Alpha 1. Вроде как и нельзя никаких претензий предъявить.

Но в openSUSE Leap 15 репозитории с новыми версиями KDE, KF5 и приложений тоже считаются тестовыми и не до конца стабильными, однако в этой системе у меня KMail работает идеально. Никаких ошибок, программа безупречно запускается и корректно получает почту. Выходит, что не так уж и нестабильна openSUSE?

Будущее наступает

Прочитав заметку Кая Уве о глобальном меню в Plasma 5.13, я уже приготовился было ждать июня, когда эта версия официально выйдет, однако меня ждала хорошая новость! В новой версии openSUSE Leap 15.0, которая тоже ещё не вышла, но уже довольно давно доступна как бета-версия, уже давно всё сделано и работает! Напомню, что речь идёт о поддержке глобального меню не только для Qt-приложений, но и для GTK-программ. Это значит, что в Plasma теперь можно добиться гораздо лучшей интеграции чужеродных приложений (не основанных на Qt5) и наслаждаться отличным и единообразным видом программ, использующтх разные графические библиотеки.

Картинки покажут всё лучше слов, поэтому смотрим:

Для начала — список установленных пакетов, без которых ничего получится

Затем нужно просто добавить на рабочий стол верхнюю панель с меню приложений. В Plasma 5.12 это стало проще, так как больше не нужно идти в настройки стиля и выбирать там расположение меню. Теперь вы просто добавляете стандартную панель с меню и всё происходит автоматически. Так, к примеру выглядит у меня Gimp:

А так — Inkscape:

C Libreoffice нужно немного повозиться. Во-первых, потребуется установить VCL-плагины для интеграции пакета c GTK2 и GTK3 (увы, VCL-плагин для KF5 разрабатывается, но пока не готов). В openSUSE это пакеты libreoffice-gtk2 и libreoffice-gtk3. Затем нужно запустить любой из нужных вам компонентов, предварительно объявив переменную SAL_USE_VCLPLUGIN, например так:

SAL_USE_VCLPLUGIN=gtk oowriter

Результат:

Это просто кра-со-та! Теперь в моём любимом KDE глобальное меню почти так же универсально как и в macOS, и уже явно не хуже чем vala-appmenu, которое работает в XFCE и Mate.

 

UPD.

Среди Linux-блогеров, которых я читаю, есть некий Alex285, являющийся большим фанатом Gnome. Он ведёт интересный блог World of Gnome (WOGUE), откуда удобно узнавать о самых свежих новостях, связанных с Gnome. Я слежу за этой темой для того, чтобы знать, что из себя представляет современный Gnome Shell и мир GTK3-приложений. Вдруг, в какой-нибудь параллельной вселенной или мире розовых пони так случится, что Gnome станет быстрее, удобнее и надёжнее чем KDE Plasma, и тогда мне придётся перейти в стан гномолюбов — хотя бы для того, чтобы оставаться честным с самим собой. К счастью, в реальном мире  всё происходит ровно наоборот: последние версии Gnome (3.22-3.28) работают в моём VirtualBox заметно медленнее чем Plasma, а про убогий набор функций Gnome можно говорить бесконечно.

Так вот, этот самый блогер внезапно очень нервно и агрессивно отреагировал на новость про глобальное меню в KDE. Дескать, это всё не нужно и вообще, вместо меню разработчикам нужно работать над стандартным API приложений, чтобы их функции были доступны из HUD (это такая вываливающаяся сверху область уведомлений со строкой поиска). На это мне есть что сказать: я прекрасно понимаю природу гнева гномовода по поводу глобального меню в KDE. Причина здесь в зависти и бессильной злобе от того, что в конкурирующем настольном окружении хорошо работают штуки, которых в Gnome нет и в ближайшее время точно не будет. У нас есть KRunner (лучшая в своём классе реализация HUD), но самое главное — в KDE меню приложений можно настраивать. Его можно оставить в окне самого приложения, можно закинуть в кнопку в заголовке окна, можно вынести в отдельный плазмоид на панель, можно вообще отключить. Любой, кто пытался освоиться в Gnome Shell, может подтвердить убогость, бедность и малую информативность как оболочки в целом, так и отдельных GTK3-программ. Пользователь Gnome не видит какие программы у него запущены, но он также не видит функций по управлению документом, открытым в GTK3-программе до тех пор, пока не перейдёт к этой программе. Эта «слепота» приводит к тому, что в Gnome нужно тратить дополнительное время на то чтобы постоянно переключаться между обзором запущенных программ и рабочим приложением, а потом отдельно искать, где у приложения меню (и есть ли оно там вообще). Современные тенденции в развитии GTK3 приводят также к тому, что цельность таких рабочих окружений как XFCE и Mate размывается и становится эклектичной. Говоря по-русски, вместо продуманного рабочего стола вы рискуете получить помойку, щедро сдобренную фантазиями дизайнеров Gnome. По этой, и по многим другим причинам, KDE Plasma — лучший рабочий стол на сегодняшний день.

Linux: личный опыт в этом году

Хочу поделиться своим опытом тестирования дистрибутивов Linux в медленно уходящем 2017 году. Напомню, что мой профиль использования — это классическое настольное применение, также известное как desktop computing. Если говорить конкретно, то свою тестовую машину я использую для интернет-сёрфинга, проигрывания медиа-контента, каталогизации фотографий, а также для написания, сканирования и печати документов. Существенный момент: я регулярно пишу обзоры новинок открытого ПО, которые вы можете читать в журнале Linux Format, поэтому для меня жизненно важно иметь возможность устанавливать самые новые программы. Если есть готовые бинарные сборки — хорошо, нет — не беда, я могу и сам собрать что угодно из Github.com.

С точки зрения «железа», использовалась следующая конфигурация:

• Intel Core i3 2105 с материнской платой DH67BL-B3;
• Встроенная графика Intel HD 3000 Graphics;
• 8 Гб ОЗУ (DDR3/1333)
• Intel SSD 120GB

В качестве подопытных операционных систем выступали интересующие меня дистрибутивы Linux: openSUSE 42.3, elementaryOS 0.4.1, Rosa Fresh R9, Mageia 6. Каждая из этих систем прожила в моём компьютере не менее 2 месяцев и оценивалась с точки зрения удобства, функциональности и эстетики. Ниже я поделюсь своими впечатлениями о каждой из них.

openSUSE 42.3

Данный дистрибутив имеет массу преимуществ для тех, кто по тем или иным причинам, предпочитает RPM-системы. Здесь есть очень удобный и надёжный инсталлятор от Suse Enterprise Linux (SLE) и довольно толковый центр управления YaST. Я сознательно выбрал более консервативную и стабильную версию Leap вместо всегда супер-свежей Tumbleweed по простой причине: в Leap я могу подключить дополнительные репозитории и обновить множество компонентов до самых свежих версий, получив на выходе нечто похожее на Tumbleweed. Но при этом, если что-то пойдёт не так, я всегда могу временно отключить такие репозитории и откатиться обратно. Не стоит забывать, что команда ‘zypper dup’ не столько обновляет пакеты, сколько приводит их в соответствие с текущим набором включённых репозиториев, то есть, её можно использовать и для даунгрейда (отката). Я установил новые версии для Qt5, KF5, KDE, KDE Extras, настроил себе более свежий компилятор GCC 7, перешёл на свежую версию ядра. У меня появилась самая новая версия рабочего стола KDE Plasma 5, которая автоматически обновлялась почти без моего участия. В openSUSE имеется отличная интеграция PackageKit и Zypper, поэтому для установки обновлений достаточно пару раз щёлкнуть мышью по значку в системном лотке. Даже пароль вводить не нужно!

Что и говорить, обновления в openSUSE ставить легко и приятно, однако за последствия никто не отвечает…

Однако, со временем стали вылезать недостатки такой системы: приверженность самым новым версиям вышла мне боком. То и дело после очередного обновления что-нибудь отваливалось или начинало работать не так. Либо Segmentation fault, либо частые падения самой оболочки Plasma (да, она всё ещё падает иногда!), либо временная потеря функциональности (Virtualbox может не работать с самым новым ядром). Проблемы можно обычно решить с помощью маневрирования с репозиториями, но со временем, опять же, дистрибутив превращается в гремучую смесь пакетов от разных поставщиков. Поддерживать стабильность вручную оказалось довольно трудозатратно. Всё таки, openSUSE Leap наиболее надёжен именно в своём изначальном виде, со стандартным набором репозиториев (плюс можно безболезненно использовать Packman), но тогда он теряет важную для меня особенность — свежесть пакетов. Оставаться на Qt 5.6 и GCC 4.8 для меня неприемлемо: я знаю дюжину проектов на Github, которые нельзя скомпилировать с этим устаревающим инструментарием.

Есть и ещё одна особенность проекта openSUSE, которая меня расстраивает. Дело в том, что инфраструктура проекта работает слишком уж нестабильно и непредсказуемо. По выходном где-то раз в месяц останавливается сервис software.opensuse.org, якобы на «плановые работы». Несколько раз я сталкивался с неработающим сервисом OBS и по будним дням – вместо страницы поиска пакетов вылетал Error 404. У openSUSE имеется два датацентра: один в Нюрнберге (Германия) и второй где-то в США. Стабильность работы обоих отражает общую картину с обеспечением качества (quality assurance, QA) в openSUSE – лично я не вижу ни стабильности, ни качества, но зато воочию наблюдаю постоянно прерывающийcя uptime.

При «настольном» использовании система обрастает репозиториями как снежный ком. Ну, по крайней мере, у меня 🙂

По этим причинам я в итоге принял решение перенести openSUSE 42.3 в виртуальную среду VirtualBox и использовать этот дистрибутив по мере надобности. Мне по-прежнему нравится очень удобная функция Zypper, позволяющая мигом установить все зависимости для сборки того или иного пакета:

sudo zypper --si d <package>

Пользовательская аудитория у openSUSE всё ещё значительная, и в частных репозиториях на OBS можно найти очень много интересных программ, которые уже кто-то успел собрать.

elementaryOS 0.4 «Loki»

Это один из самых популярных отпрысков Ubuntu. Система очень хорошо себя зарекомендовала у новичков в мире Linux, и вполне заслуженно, как мне кажется. Система elementaryOS 0.4 «Loki» основана на Ubuntu 16.04 LTS и отличается повышенной стабильностью, надёжностью и увеличенным сроком поддержки. Последнее особенно удобно: можно один раз установить Loki в качестве запасной ОС и вспомнить о ней пару лет спустя. После установки всех накопившихся обновлений с системой не случится ничего страшного, всё продолжит работать как часы. Вроде бы, ничего особенного, но многие другие Linux не переносят такого к себе отношения. Очень круто и удобно то, что elementaryOS полностью совместима с Ubuntu, а значит я могу подключить любой PPA-репозиторий для Ubuntu, и он гарантированно будет работать. Де-факто Ubuntu является наиболее распространённым дистрибутивом Linux в мире, и для него создано множество таких частных PPA-источников. Почти любая Linux-версия какой-либо программы имеется в уже собранном виде в чьём-то PPA, а значит мне не нужно возиться со сборкой исходников. Это удобно.

Одной из причин, почему я использую elementaryOS, а не саму Ubuntu, является рабочий стол Pantheon, который является оригинальной разработкой проекта elementary. Он основан на библиотеках GTK3 и Granite, и включает в себя отдельные элементы Gnome 3 (хотя их тут немного). Pantheon очень быстр и по своему поведению напоминает пресловутую macOS, как внешне, так и идеологически.

Вроде бы всё чисто и аккуратно, но активная вкладка в браузере очень слабо выделена, из-за чего работать неудобно. В дизайне elementaryOS не очень хорошо обстоят дела с контрастностью элементов.

Несмотря на то, что я не являюсь поклонником Debian и deb-дистрибутивов, наличие на компьютере elementaryOS для меня полезно, так как на свете существует некоторое число программ, которые очень легко установить в Ubuntu-подобных ОС, и очень трудно собрать где-либо ещё. Хороший пример: игра Machines vs. machines, которая опирается на QML-модули к Qt5, написанные в Canonical специально для Ubuntu. Это также относится к целому пласту программ, написанных в то время, когда в Canonical ещё делал ставку на Unity и Mir, и разрабатывал много специфических для Ubuntu компонентов. Другой пример – замечательный каталогизатор заметок Outwiker, который очень легко поставить из PPA и довольно муторно собирать вручную.

elementaryOS 0.4 могла бы быть идеальной настольной системой, но увы, она имеет свои недостатки, которые раскрываются после первых дней интенсивного использования. Во-первых, не все компоненты от Ubuntu 16.04 можно заменить более свежими версиями, и если программа требует самую новую GTK3, то мне гораздо проще накатить новейшую Fedora и собрать всё там, вместо ломания стабильной, но устаревшей GTK3 в elementaryOS. Во-вторых, кажущееся удобство рабочего окружения оборачивается совершенно дикими проблемами при каждодневной работе. Копирование файлов в Pantheon-files, каталогизация фотографий штатным приложением, веб-сёрфинг в Midori и Epiphany (Gnome Web) – всё это очень неудобно. Мало функций, мало настроек, невозможно что-либо изменить и перенастроить. Дополнительное наблюдение, которое, впрочем, относится не столько к elementaryOS 0.4, сколько ко всем рабочим окружениям на GTK3 – это крайне скудная и ограниченная функциональность прикладных программ. Я уже писал заметку о возмутительно убогом индикаторе погоды от проекта elementary, но с остальными приложениями из нового elementary AppCenter ситуация та же. Когда я подбираю свободные приложения для своей рубрики в журнале, я всегда отмечаю убожество и ограниченность программ на GTK3. Почти все они примитивны до безобразия, и при том часто ещё и нестабильно работают. Напротив, самые лучшие, развитые и функциональные приложения часто написаны на C++ и имеют интерфейс на Qt. Такое вот наблюдение 🙂

Наконец, я отмечаю всё возрастающую жадность разработчиков elementaryOS в отношение пользовательских донатов. Принцип Pay what you want – пример отвратительной жадности и истончающейся связи этих ребят с реальностью. Они заставляют ничем не виноватых людей чувствовать себя нищебродами каждый раз когда требуется скачать из AppCenter «условно-бесплатную» программу (с лицензией GPLv3, между прочим). Разумеется, это вовсе не означает что весь дистрибутив Loki 0.4 из-за этого плох.

Мы напишем недопрограмму на Vala и GTK3, а вы нам дадите немного денег. Видимо, в мире хипстеров растёт напряжение из-за недостатка донатов…

В итоге, elementaryOS живёт у меня на запасной разделе моего SSD и используется время от времени, в зависимости от задач и настроения.

Rosa Fresh R9

Мои отношения с этим российским дистрибутивом начались в 2012 году, когда в мае проект Rosalab презентовал версию Rosa Marathon. Этот релиз планировали поддерживать и обновлять аж 5 лет, что являлось прямым ответом на Ubuntu 12.04 LTS от британской Canonical. Увы, история Rosa Linux продолжила своеобразное «хождение по мукам» своего прародителя – французской Mandriva Linux. В 2011-2013 годах Rosa имела мощную финансовую подпитку от фонда NGI, организованным бывшим министром связи РФ Леонидом Рейманом. У компании имелся шикарный офис в Сколково и большой штат сотрудников. Именно в это время под руководством UX-дизайнера Кирилла Монахова был создан прекрасный набор фирменных значков Rosa и куча интересных модификаций для KDE. Многое из этого используется в дистрибутиве до сих пор.

Отличная фирменная тема значков — это именно то, что меня всегда привлекало во внешнем виде Rosa Linux

Любопытно, что «тучные» годы Rosa Lab совпали с волной неистовой критики дистрибутива со стороны анонимусов и прочих человекоподобных с сайта Linux.org.ru. Дистрибутив ненавидели за то, что под него якобы попилили неисчислимые суммы бюджетных денег, а также за то, что он русский, а всё русское по определению толковым быть не может. Время показало, что оба обвинения были напрасными. С некоторых пор Rosa Linux существует под крылом НТЦ ИТ «Роса», имеет очень скромный штат сотрудников (не знаю, сколько их там точно, но вряд ли больше 10-15 человек) и в основном развивается за счёт образовавшегося сообщества. Интересно, что в наши дни у дистрибутива вполне неплохая репутация у Интернет-пользователей, никто Росу больше не ненавидит, но зато и будущее дистрибутива немного туманно: лично я боюсь, что проект может в любой момент умереть, и сообщество просто не справится с его поддержкой (например, кто-то должен оплачивать размещение сборочной среды ABF в датацентре).

После Rosa Marathon стартовала проект Rosa Fresh – версия дистрибутива с полускользящим режимом поддержки и обновления. «Полу-» означает, что в рамках базовой платформы у вас есть полноценная роллинг версия, а для перехода между платформами всё же рекомендуется устанавливать систему с нуля. Были выпущены две базовых платформы: 2014.1 и 2016.1, последняя является актуальной на данный момент.

Итак, какими особенностями обладает Rosa Fresh R9, основанная на платформе 2016.1?

• Интеграцией дополнительных инструментов настройки (drak-приложений, унаследованных от Mandriva) в стандартный центр настройки KDE Plasma. Для сторонних программ сделаны соответствующие KCM-обёртки;
• Свежими версиями рабочих окружений и прикладных программ. Версии пакетов в Rosa могут немного отставать от upstream, но зато в дистрибутиве организовано более толковое и тщательное тестирование новых функций. Если новая версия Plasma 5 несёт в себе регрессии и новые ошибки, пользователи Rosa получат её позднее, когда ошибки будут исправлены в корректирующих минорных релизах. Это не очень удобно для тех кому нужен bleeding edge (таким лучше подойдёт Manjaro или тот же Tumbleweed), но зато обеспечивает отличную стабильность системы. Однажды установленная Rosa Fresh может работать годами без сбоев;
• Наличием огромного количества дополнительного ПО в репозитории Contrib. Стандартная поставка Rosa уже включает задействованный репозиторий Contrib, который по своему «богатству» не уступает, а иногда и превосходит знаменитый AUR от проекта Arch Linux. Я говорю сейчас не о формальном количестве пакетов, а о наличии всяких редких штук, вроде VoltAir, OilWar, Softmaker Freeoffice, которые сложно найти где-то ещё в готовом виде. В отличие от россыпи PPA-репозиториев в Ubuntu или частных OBS в openSUSE, содержимое Contrib централизованно пересобирается и тестируется средствами сборочной фермы ABF, что положительно сказывается на стабильности программ;

Хотите поиграть в эту игру? Ставьте Rosa Fresh!

• Возможностью скачать свежий промежуточный образ системы вместо того, чтобы накатывать огромный пласт обновлений поверх оригинального релизного образа. Это не полноценные nightly builds, но очень близко к ним. Это именно то, чего мне так не хватает в других дистрибутивах, особенно когда под рукой нет быстрого безлимитного Интернета (бывает и такое!);
• Наличием дружного и адекватного сообщества на официальном форуме проекта. Активность там умеренная, и, к примеру, сообщество Ubuntu будет гораздо многочисленнее и более разговорчивым, однако форум Росы гораздо толковее, чем форум openSUSE, и бесконечно лучше того, что происходит в русском сообществе elementaryOS (напомню: ребята там зачем-то специально забросили свой форум и переместились в Telegram-канал, где быстро скатились в привычный для телеграма шлак).

В разделе «Системное администрирование» содержатся инструменты, которые в других дистрибутивах разбросаны где попало.

В Росе довольно удобно заниматься сборкой программ из исходного кода, так как, с одной стороны, у нас есть здесь практически все инструменты и библиотеки для сборки (актуальных версий), а с другой, имеется довольной развитый инструментарий URPM, который содержит все неоходимые мне функции. Например, аналогом “zypper –si d” здесь выступает “urpmi –buildrequires”, а вместо “zypper dup” можно использовать “urpm-reposync”.

Разумеется, у Росы имеются и недостатки. Помимо неустойчивого положения дистрибутива и непонятных перспектив (а точнее – молчания со стороны НТЦ ИТ «Роса»), я бы отметил довольно архаичный инсталлятор и заброшенность прежних разработок (например, проигрыватель Rosa Media Player больше не развивается). Но в реальной эксплуатации это всё мелочи.

Rosa R9 является сейчас моей основной системой, и она меня полностью устраивает. Мне нравится то, что инфраструктура сборки этого дистрибутива находится на территории России, и помимо моей личной позиции, тут есть и практическая сторона: никакой тропический ураган или санкции США на реэкспорт ПО не могут повлиять на доступность Росы. Если вопрос с «американскими сервисами» был чисто политическим и никак не отразился в итоге на доступе к ним в РФ, то в конце августа этого года я лично столкнулся с тем, что моя Russian Fedora Remix 26 (какая ирония!) не могла достучаться до списка зеркал именно тогда, когда мне срочно нужно было сделать “sudo dnf update” – в это время в городке Ралейф бушевал ураган «Харви», который на несколько часов обесточил датацентр Red Hat. После этого я задумался: хочу ли я, чтобы мою работу с Linux определяли ураганы в стране вероятного противника? 😉

Mageia 6

Напоследок напишу немного о Mageia Linux. Это ещё один потомок почившей Mandriva Linux и в некотором смысле конкурент Rosa Linux. Я никогда особо интенсивно не использовал Mageia, так как в данном дистрибутиве исторически всегда наблюдались разброд, шатания и срывы сроков. Но я добросовестно прожил некоторое время с Mageia 6, так как в ней имеется портированный из Fedora пакетный менеджер DNF. С моей точки зрения, DNF является более перспективной технологией, чем URPM, и мне очень жаль, что в Росе пока нет DNF. Я пробовал портировать его самостоятельно, но это оказалось трудным заданием, и пока что я застрял где-то на сборке библиотеки Hawkey. В общем, я снимаю шляпу перед разработчиками Mageia за то, что они проделали отличную работу. Более того, в Mageia имеется графический интерфейс для DNF под названием Dnfdragora. Эта программа использует libYui и может интегрироваться с GTK3, Qt5 и ncurses. Такие штуки вызывают у меня зависть и восхищение!

Современный и быстрый менеджер пакетов, плюс отличный интерфейс к нему — это, безусловно, сильный ход разработчиков Mageia.

Что касается самого дистрибутива, то для начала я советую прочитать обзор от Dedoimedo. Сразу скажу, что с выводами этого уважаемого автора с согласен лишь отчасти. В принципе, Mageia 6 вполне можно использовать в качестве основной системы, особенно если вам нужен проприетарный драйвер Nvidia, однако я легко могу перечислить и недостатки данного дистрибутива:

• Крайне скудное наполнение стандартных репозиториев (и небогатый выбор сторонних). Я уже как-то привык, что QtCurve, Kvantum, Cool Retro Term можно поставить сразу из репозиториев в Росе. В Магее так нельзя, увы;
• Старые версии программ. Версия с Plasma 5 использует устаревший набор KDE Applications 16.12, которому скоро стукнет год. Остальные программы обновляются тоже крайне избирательно;
• Странная приверженность к неудачным пережиткам Mandriva, например к Netapplet. Чтобы понять всю ущербность Netapplet по сравнению с NetworkManager (стандарт в большинстве другим дистрибутивов Linux), достаточно сравнить поведение Mageia и Rosa в VirtualBox: если на хосте меняются сетевые настройки, то NetworkManager в гостевой системе заметит это и автоматически перенастроится, а NetApplet в Mageia просто потеряет сеть до тех пор пока вы не сделаете “# service network restart”. Кстати, в Mageia почему-то нет sudo в стандартной поставке;
• Довольно много багов. Например, смена языка и системной локали удивительным образом не влияет на некоторые программы. И таких мелочей в системе хватает.

В общем, если бы не DNF, то Mageia 6 вообще не стоило бы рассматривать.

В итоге, опыт использования подсказывает мне, что среди настольных дистрибутивов наиболее сбалансированным вариантом является Rosa R9 (а скоро уже выйдет и R10). Если вы по какой-то причине не любите Plasma 5, то можно использовать отдельную редакцию Росы с рабочим столом Gnome 3. В зависимости от вкуса, предпочтений и привычек вполне достойно установить Ubuntu 16.04 или elementaryOS 0.4, но использовать openSUSE Leap или Mageia скорее всего не стоит: количество ошибок и трудностей со временем приведёт к разочарованию.

Спасибо, что дочитали до конца. Подписывайтесь, ставьте лайки, и всё такое…

Решение проблемы с долгой перезагрузкой в openSUSE

Этот баг долго не давал мне покоя, ещё с версии 42.1. Суть в том, что при выключении или перезагрузке система замирала на консольном приглашении на 60-90 секунд, и лишь потом выключалась. Поиск в Google, конечно же, выдавал кучу подобных жалоб от других людей, вместе с советами по решению проблемы. Но мне ничего не помогало: ни отключение служб, ни ручное отмонтирование разделов, ни ручное завершение всех процессов.

Наконец, мне удалось выяснить, что дело было в кривизне Systemd 228, используемой в openSUSE Leap. Мне помог рецепт, описанный тут. Быстрое решение выглядит так:

The bug can be worked around by creating a file /etc/sysctl.d/50-coredump.conf with the following contents:

kernel.core_pattern=core

That causes the kernel to write coredumps directly, bypassing the buggy systemd code.

Однако, так ядро будет при определённых обстоятельствах писать большие дампы в файл на корневом разделе. Чтобы избежать этого, можно скидывать дамп ядра в /dev/null:

sudo -i

ln -s /dev/null /etc/sysctl.d/50-coredump.conf

echo '* hard core 0' >> /etc/security/limits.conf

UPD.

За последнее время мне удалось выяснить, что в некоторых случаях описанный выше метод не помогает, но зато гарантированно помогает уменьшение таймаута, который использует Systemd для ожидания завершения пользовательских процессов. Нужно всего лишь изменить файл /etc/systemd/system.conf, раскомментировав параметр DefaultTimeoutStopSec и установив ему какое-нибудь небольшое значение. Например, так:

#DefaultStandardOutput=journal
#DefaultStandardError=inherit
#DefaultTimeoutStartSec=90s
DefaultTimeoutStopSec=5s
#DefaultRestartSec=100ms
#DefaultStartLimitIntervalSec=10s
#DefaultStartLimitBurst=5

Теперь больше никаких задержек при перезагрузке или выключении!

2GIS для Linux жив!

Когда-то, в ноябре 2014 года, разработчики «Дубльгиса» выпустили новенькую бета-версию своего справочника для Linux. Там был чистый интерфейс на Qt5 и QML, плавная работа, возможность скачать карту любого города России и некоторых других стран… Красота! Однако же, дальше беты дело не пошло, и вскоре сайт, посвящённый новой версии 2GIS, закрылся, а разработка перспективного справочника в формате ПК-версии была прекращена. Но репозиторий со сборками дубльгиса для Ubuntu продолжал жить, и он работает до сих пор. В openSUSE имеется несколько частных репозиториев с rpm-пакетами 2GIS. В подобном пакете, на самом деле, содержится не сама программа, а скрипт, который вытягивает deb-пакет из сети и перепаковывает его чем-то вроде alien. В openSUSE 13.2 и 42.1 такой трюк работал без сучка и задоринки, но уже в 42.2 программа перестала запускаться:

Очевидно, что приложение, собранное под старую версию Ubuntu 14.04, уже не может запускаться в более новых версиях Linux. Забавно, что неосиляторы с Гиктаймса в подобной ситуации сдались ещё раньше: на этапе установки пакета. Однако я не первый раз запускаю проприетарный софт в Linux и знаю, что большинство подобных программ (XnRetro, Dropbox, Skype и т.п.) поставляются с собственным набором некоторых системных библиотек. Всегда можно попробовать удалить одну или несколько таких библиотек и посмотреть как программа попытается использовать общесистемные. Короче говоря, если избавиться от файла /usr/lib/2GIS/v4/lib/libpthread.so.0, то Дубльгис прекрасно запускается и работает:

 

 

KDE и перспективный формат FLIF

В номере №205 журнала Linux Format я писал о новом графическом формате FLIF (Free Lossless Image Format), который превосходит PNG и WebP по сжатию данных без потерь. В комплекте с исходным кодом FLIF (т.н. reference implementation) имеются библиотеки кодировщика и декодера, сам кодировщик, а также простейшее средство просмотра — консольная программа viewflif. С таким минимальным набором вполне можно работать, однако формат, по сути, в этом случае выполняет роль архиватора: ни листать, ни редактировать FLIF-файлы без предварительной конвертации нельзя. Правда, есть ещё набор консольных утилит ImageMagick, который с некоторых пор поддерживает формат FLIF. Приличных графических программ просмотра, которые были бы основаны на ImageMagick, в природе нет, к тому же, большинство готовых сборок ImageMagick собраны без поддержки FLIF и не могут его читать. Хотите поддержку — собирайте из исходного кода сами.

На этом фоне Qt FLIF Plugin оказался глотком свежего воздуха. Данная разработка сделана датским программистом Себастьяном Валем (Sebastian Wahl), который ведёт свой блог и увлекается алгоритмами сжатия изображений. Суть Qt FLIF Plugin проста: в вашем распоряжении появляется разделяемая библиотека libflif.so (не путать с одноимённой библиотекой из состава самого кодировщика FLIF!), которая может быть использована любыми Qt-приложениями, поддерживающими QImageIOPlugins, например Gwenview, Kolourpaint и многими другими. Автор плагина также написал свой собственный минималистичный просмотрщик графических файлов, вполне неплохой!

Итак, для сборки нам потребуется слегка подредактировать файл project.pro, добавив туда строку CONFIG += c++14:

Если этого не сделать, то проект просто не соберётся современными версиями GCC. Затем нужно убедиться в том, что заголовочные файлы FLIF лежат в нужном месте — между прочим, их нужно заранее вручную положить в /usr/include/FLIF:

Далее командуем make и ждём несколько секунд. Получившуюся библиотеку нужно проверить на успешную линковку с кодировщиком FLIF (дело в том, что плагин почему-то иногда не линкуется):

Дальше, нужно установить саму библиотеку, скопировать .desktop-файлы и зарегистрировать соответствующий тип файла для share MIME database. Следующие команды я выполнял из директории ~/qt_flif_plugin/configuraton:
sudo cp ../libflif.so /usr/lib64/qt5/plugins/imageformats/
sudo cp qimageioplugins/x-flif.desktop /usr/share/kservices5/qimageioplugins/
sudo cp imagethumbnail-flif.desktop /usr/share/kservices5/
sudo cp x-flif.xml /usr/share/mime/packages/
sudo /usr/bin/update-mime-database /usr/share/mime

Результат будет заметен сразу же. Во-первых, заработает генератор миниатюр в файловом менеджере Dolphin:

Во-вторых, можно будет смотреть FLIF-файлы в Gwenview, стандартной программе просмотра из набора KDE:

На данный момент можно использовать лишь версию Gwenview 16.08 или более старую, так как из-за этого коммита программа, начиная с версии 16.12, содержит другой механизм поддержки сторонних форматов. Но это уже вопрос к автор FLIF-плагина — надеюсь, он обновит свой код когда-нибудь. Меня же очень радует сжатие, которое обеспечивает FLIF. Только посмотрите:

 

Скоро выйдут Fedora 25 и openSUSE 42.2

Релиз Fedora 25 запланирован на 15 ноября, а openSUSE 42.2 — на день позже. На самом деле, оба этих дистрибутива я тестирую уже около месяца, установив ещё бета-версии. У меня есть некоторые наблюдения, которыми я хочу поделиться.

Fedora

Это очень достойный и довольно стабильный дистрибутив, который прекрасно подойдёт для домашнего использования, если вы возьмёте не официальную версию, а сборку от проекта Russian Fedora — в ней уже добавлены дополнительные репозитории, кодеки и прочие штуки, которые в обычной Федоре нужно проделывать вручную. Даже если вы не собираетесь использовать Федору как основную систему, её всегда полезно иметь где-нибудь под рукой (в виртуальной машине или на отдельном жёстком диске/разделе), потому что Федора — это всегда самая новая версия рабочего стола Gnome, передовая и самая стабильная работа новой графической системы Wayland, надёжная и стабильная поддержка UEFI и Secureboot в инсталляторе, огромный выбор стороннего ПО через систему Fedora Copr и многое другое.

Вместе с тем, пользоваться Fedora 25 Beta как основной системой затруднительно, потому что многие проекты в Copr пока не делают сборок для версии 25, многие инструменты, вроде Fedy, тоже пока поддерживают только версии Fedora вплоть до 24-й. Короче говоря, надо просто немного подождать.

В середине октября моя Russian Fedora 25 Beta вдруг перестала обновляться и вообще видеть сервера обновлений. Я догадался заглянуть на страницу состояния инфраструктуры Федоры и увидел там много красного цвета. Инфраструктура всего проекта «лежала» примерно 2 часа по вине урагана «Матфей», который вызвал наводнения и обрыв электропередач в местечке Raleigh, где и расположен дата-центр Fedora Project. Казалось бы, Fedora умеет искать местные зеркала своих репозиториев во всех частях мира, однако сам список зеркал всё равно сначала подтягивается из США. Так что при использовании стандартных настроек пакетного менеджера DNF, работоспособность Russian Fedora всё равно критично зависит от американских серверов.

openSUSE

Предыдущий релиз 42.1 мне откровенно не понравился — он был очень «сырым» и стал более-менее хорошим только через пару-тройку месяцев, когда большинство проблем разработчики наконец решили. Я использую openSUSE ещё со времён версии 10.2 и могу сказать, что за прошедшее время было много как хороших, так и неудачных релизов —  в этом смысле проект openSUSE остаётся непредсказуемым. Правы были те пользователи, которые не стали обновляться до Leap 42.1 и остались на отличных версиях 13.1 и 13.2. Но похоже, что грядущий выпуск 42.2 получится исключительно удачным. За месяц активного использования я остался очень доволен качеством и производительностью системы. Пожалуй, стоит перечислить достоинства и некоторые выявленные недостатки в openSUSE 42.2.

Достоинства:

• Традиционно лучший инсталлятор из виденных мною. Логичный, удобный, стабильный — оно и не мудрено, ведь готовили его изначально для платной версии SUSE SLE:
• Приятный в использовании и очень производительный рабочий стол Plasma5;
• Огромный набор дополнительного ПО в системе openSUSE Build Service (OBS). Здесь много энтузиастов из сообщества openSUSE поддерживают свои сборки пакетов, и тут есть практически всё;
• Пакетный менеджер Zypper, который, на мой взгляд, гораздо мощнее любого apt или urpm*. На моей практике мне удавалось легко и изящно откатывать систему к предыдущему состоянию после обновления из «левых» репозиториев, используя Zypper. Сломать пакетную систему в openSUSE практически нереально — даже загубленную систему всегда можно вернуть в строй, вычистив её от ненужных наслоений;
• Интересные возможности бэкапа и версионирования системы благодаря файловой системе Btrfs. В последний раз я тестировал Btrfs ещё с openSUSE 13.1, и тогда меня неприятно удивила низкая производительность этой ФС на десктопе. С тех пор я всегда форматировал корневой раздел для openSUSE в ext4, но недавно я решил поставить 42.2 RC на отдельный жёсткий диск и оставил в инсталляторе настройки по умолчанию — они-то и предлагают всегда Btrfs. В итоге, установленная система показалась мне очень быстрой, и теперь мне больше не хочется менять Btrfs на ext4. Кстати, недавние тесты показывают, что Btrfs не так уж и отстаёт от конкуренток;
• Самый удобный способ установки обновлений, что я когда-либо видел. В системном лотке Plasma5 сидит значок обновлений, который подаёт сигнал о новых версиях пакетов. Достаточно всего двух щелчков мыши — и обновления тут же скачиваются и устанавливаются!

Недостатки:

По мелочи всегда набираются ошибки, которые хоть и не сильно влияют на общее впечатления о системе, но раздражают. Так, при выходе (log out) из Plasma5 эта самая Плазма сначала замирает на пару секунд, потом с ошибкой перезапускается, и лишь после этого сеанс завершается. Есть надежда, что это исправят в ближайших выпусках Plasma 5.8.х, так что нужно просто подождать обновлений. В остальном, некоторые программы всё равно приходится собирать вручную (KEncFS, KNemo), но их немного. Русификация Plasma5 в целом на «четвёрку» — чуть похуже чем в Rosa Fresh, но мелкие огрехи не сильно портят жизнь.

Самое главное — openSUSE 42.2 ещё до своего выхода оказался очень стабильным и пригодным для использования дистрибутивом, который я могу рекомендовать всем, кто интересуется Linux.