Ходячий генератор энтропии

Linux Kernel map

2021-12-17T15:08:22Z

Давно не выкладывал ссылки на всяческие схемы у себя. Кажется, пора.

Linux Kernel map. Схема всех подсистем и взаимосвязей между ними. Верхний пост тоже обновил, само собой.

comments

Подписывание сторонних модулей ядра при использовании SecureBoot

2021-11-03T19:17:22Z

Современные EFI/BIOS в последнее время порой идут с неотключаемым SecureBoot или же порой очень сложно найти, где оно отключается. Зачем он нужен и какую пользу приносит, об этом как-нибудь в другой раз. Слишком обширная тема.

Сейчас мы разберём, как подписывать сторонние модули ядра, не входящие в основную поставку, чтобы они работали с SecureBoot. для примера возьмём VirtualBox, модули которого, обычно идут в виде исходников и собираются с помощью DKMS.

Я использую Fedora 34, но это работает в любом современном дистрибутиве.

Для начала нам понадобится mokutil.


sudo dnf update
sudo dnf install mokutil

Затем создаём новый каталог и генерим пару RSA:

sudo -i
mkdir /root/signed-modules
cd /root/signed-modules
openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=VirtualBox/"
chmod 600 MOK.priv

После чего необходимо добавить пароль. Этот пароль нам потребуется при следующей перезагрузке.

sudo mokutil --import MOK.der

Затем перезагружаемся и на появившемся синем экране выбираем: Enroll MOK --> Continue --> вбиваем пароль из предыдущего шага

Теперь уже создаём скриптик, которым мы будем подписывать модули ядра:

cd /root/signed-modules
vim sign-virtual-box

И сам скрипт, собственно:


#!/bin/bash

for modfile in $(dirname $(modinfo -n vboxdrv))/*.ko; do
  echo "Signing $modfile"
  /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 \
                                /root/signed-modules/MOK.priv \
                                /root/signed-modules/MOK.der "$modfile"
done

На всякий случай можете проверить расположение signfile и если что, подправить пути в скрипте выше:


find /usr/src -name signfile

И далее:

chmod 700 sign-virtual-box
./sign-virtual-box

И пересобираем модуль:

modprobe vboxdrv

В дальнейшем скрипт НЕ УДАЛЯЕМ, как и сгенерированные ключи. Они нам потребуется при каждом обновлении ядра. А вот mokutil будет уже не обязателен.

comments

Fedora 34: первая неделя использования

2021-10-16T17:35:27Z

«О чём думаешь, Евгений?» вопрошает меня Фейсбук. А о том, что давно у меня не было рубрики «карма тестировщика».

Дано: Fedora 34 Workstation. Ванильная. Со всеми патчами и апдейтами из штатных репозиториев. Никаких RPM Fusion и иже с ними.

Уже несколько раз крашился Gnome, причём непонятно из-за чего. Но отчёты в ABRT сгенерились. Надо бы восстановить пароль от багзиллы Fedora и отправить логи туда.
Постоянно пропадает звук на полсекунды или меньше в Firefox, при подключении внешней звуковой карты. Судя по всему, проблема в PipeWire. Решения пока не нашёл. Если проигрывать со штатной звуковой карты в ноутбуке — всё ОК.
При обратном включении иконок на работе столе Gnome, иконки постоянно меняют своё местоположение при включении или выключении дока. Причём заметил, что съезжают всегда одинаково. В качестве обходного решения расположил иконки как мне надо при включенном доке и использовать Gnome Shell только с доком. Стыд, да и только.
Очень редко, но теряются настройки внешних мониторов. Какую-то последовательность пока не уловил. Но случается правда редко и фикс занимает несколько секунд. Переживу. Туда же — меняются местами primary и secondary мониторы.
Нихера не запоминаются настройки размера окон в Gnome Terminal.
До сих пор надо в Gnome Terminal надо отключать Menu acceleration, чтобы заработала клавиша F10. Да, я использую Midnight Commander. Порицайте меня.
Всё так же надо использовать Gnome Tweaks, чтобы добавить кнопки сворачивания, разворачивания и максимизации-минимизации окон.
По хрен знает какой причине у меня не работали сначала Gnome Extensions. Решение: обнулить профиль пользователя и сбросить профили Firefox/Chrome, затем заново переустановить аддоны для браузеров.
Если воткнуть док до загрузки ноутбука, то система будет загружаться раза в три медленнее, чем без него.

Может мне и правда в QA идти было надо?

comments

Сертификат R3 для Let's Encrypt

2021-10-11T16:07:43Z

Думаю ни для кого не новость, что сертификаты от R3 которым подписаны цепочки от тех же Let's Encrypt протухли ещё 30 сентября. Но те, кто выписывают сертификаты с помощью certbot, обнаружили, что сертификат обновляется, но по-прежнему подсовывается старая цепочка доверия.

Чтобы заставить certbot выдавать сертификаты используя цепочку ISRG X1, надо скормить оному команду certbot renew --preferred-chain "ISRG Root X1". Затем просто перезапустить сервер. В дальнейшем будет сгенерирован конфиг для сертификата, где по умолчанию будет прописано необходимая предпочтительная цепочка доверия.

comments

А теперь давайте поговорим за RabbitMQ

2021-06-09T16:16:27Z

.. и его проблемы.

Снова решил пописать про работу. На сей раз, проблема возника с RabbitMQ.

Имеется кролик с неработающими очередями. При этом всё поднято, но если заглянуть в логи, то можно увидеть в первую очередь нечто такое:


2021-06-09 10:02:38.030 [error] <0.19004.32> Error on AMQP connection <0.19004.32> (192.168.0.1:42538 -> 192.168.0.3:5672, vhost: 'none', user: 'updater', state: opening), channel 0:
 {handshake_error,opening,
                 {amqp_error,internal_error,
                             "access to vhost '/' refused for user 'XXX': vhost '/' is down",
                             'connection.open'}}
2021-06-09 10:02:38.030 [info] <0.19004.32> closing AMQP connection <0.19004.32> (192.168.0.1:42538 -> 192.168.0.3:5672, vhost: 'none', user: 'updat
er')
2021-06-09 10:02:38.031 [info] <0.19001.32> accepting AMQP connection <0.19001.32> (192.168.0.2:14580 -> 192.168.0.3:5672)
2021-06-09 10:02:38.032 [info] <0.19020.32> accepting AMQP connection <0.19020.32> (192.168.0.1:42540 -> 192.168.0.3:5672)
2021-06-09 10:02:38.033 [error] <0.19001.32> Error on AMQP connection <0.19001.32> (192.168.0.2:14580 -> 192.168.0.3:5672, vhost: 'none', user: 'smsc', state: opening), channel 0:
 {handshake_error,opening,
                 {amqp_error,internal_error,
                             "access to vhost '/' refused for user 'YYY': vhost '/' is down",
                             'connection.open'}}
2021-06-09 10:02:38.034 [info] <0.19001.32> closing AMQP connection <0.19001.32> (192.168.0.2:14580 -> 192.168.0.3:5672, vhost: 'none', user: 'smsc')
2021-06-09 10:02:38.035 [error] <0.19020.32> Error on AMQP connection <0.19020.32> (192.168.0.1:42540 -> 192.168.0.3:5672, vhost: 'none', user: 'updater', state: opening), channel 0:
 {handshake_error,opening,
                 {amqp_error,internal_error,
                             "access to vhost '/' refused for user 'XXX': vhost '/' is down",
                             'connection.open'}}

Если же зайти в админку кролика, то мы видим сообщение вида:

Virtual host / experienced an error on node rabbit@somehost and may be inaccessible

После раскуривания некоторого количества логов, выяснилось, что проблема в Mnesia. По какой-то причине корраптятся сообщения в msg_stores. Если повнимательнее поискать, то можно заметить такое:


CRASH REPORT Process 
<0.430.0> with 0 neighbours crashed with reason: no match of right hand value {error,{not_a_dets_file,”/var/lib/rabbitmq/mnesia/rabbit@hostname_1/msg_stores/vhosts/628WB79CIFDYO9LJI6DKMI09L/recovery.d ets”}} in rabbit_recovery_terms:open_table/1 line 197

Дальше останавливаем корлика, затем идём по указанному пути и грохаем целиком /var/lib/rabbitmq/mnesia/rabbit@hostname_1/msg_stores/vhosts/628WB79CIFDYO9LJI6DKMI09L/. После этого запускаем демона заново. Всё должно запуститься без проблем.

Некоторые люди зачем-то удаляют mnesia целиком, но если у вас, как и у меня, тонны очередей, эксчейнджей и пользователей, то потом это порой будет проблематично восстаналивать даже при наличии любой системы управления конфигурациями.

comments

Давно я что-то про работу не писал...

2021-06-03T20:43:58Z

...а теперь представился случай. Расскажу-ка я про занятный случай связанный Varnish.

Итак, есть энное количество кешей, ранее работавших на Varnish 3. Работало всё хорошо, но третья ветка давно очень устарела и более не поддерживается. Так что мы смигрировали на ветку 6.0.x, которая является LTS релизом. Пришлось правда переписать кастомные модули для него, но это отдельная история.

Всё б ничего, но после апгрейдв мы заметили в мониторинге такую вещь, что Varnish стал постоянно перезапускаться. Расследование показало, что умирал порождаемый варнишем процесс.
Хочу заметить, что у нас для кастомных сервисов используется runit. Простой как палка, но своё дело делает (systemd-хейтеры и любители поотлаживать bash — вам сюда!). Так вот в процессе дебага мы отловили такую хрень, что SIGTERM посылает сам runit. Что за ерунда? С третьим варнишем таких проблем не было, исправно работал годами.
Тем не менее, в strace видно следующую картину:


1622625209.201334 --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=4431, si_uid=0} ---
1622625209.202221 --- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=4431, si_uid=0} ---
1622625209.203109 rt_sigreturn({mask=[]}) = 0 <0.065258>
1622625209.333354 write(2, "Error: Manager got SIGTERM\n", 27) = 27 <0.000865>
1622625209.590396 getpid()              = 22267 <0.001420>
1622625209.592812 sendto(7, "<131>Jun  2 09:13:29 varnishd[22"..., 57, MSG_NOSIGNAL, NULL, 0) = 57 <0.000927>
1622625209.718907 write(2, "Debug: Stopping Child\n", 22) = 22 <0.157719>
1622625209.877579 getpid()              = 22267 <0.000890>
1622625209.879363 sendto(7, "<135>Jun  2 09:13:29 varnishd[22"..., 52, MSG_NOSIGNAL, NULL, 0) = 52 <0.000916>

После некоторого времени дебага, обнаружили странную вещь. У нас на машинах крутится два инстанса варниша с разными vcl и настройками. Один runit-сервис так и называется varnish, а второй несколько иначе. И вот второй, что интересно, работает как надо.
Нас взяло любопытство и мы взяли и запихвли во второй инстанс настройки от первого. Что интересно, всё заработало.
Дальше мы в порядке бреда просто переименовали runit varnish в что-то другое и... всё заработало.

Проблема решена, но вообще интересно, что её породило. Пока в гипотезе у нас значится, что сам varnish вызывает что-то с точно таким же именем и ранит принимает это за лишний форк или ещё что-то и естественно его прибивает. Дальше вы уже знаете.

Так и живём.

comments

Разбираем команду free: что должен знать администратор Linux

2020-10-01T17:04:20Z

Перед чтением.

Для тех, кто не использует или не любит дистрибутивы Linux семейства RHEL, следует ориентироваться на версии ядра. В случае, когда мы говорим RHEL 6, то имеется в виду ядро 2.6.32 и ниже. Если говорим о RHEL 7/8, то 3.10 и выше.

Отвечая на вопрос «зачем». Как оказалось, у многих даже давно занимающихся администрированием Linux знания об использовании данной команды остались на уровне времён ядер 2.6.32. В то время как в новых ядрах, очень многие фичи были или инвертированы или же сильно изменены. И многие люди про это не в курсе.

Оригинал статьи лежит здесь. На случай, если кто-то мой перевод сочтёт негодным. :)

Разбираем команду free: что должен знать администратор Linux

Команда free популярна среди системных администраторов Unix/Linux. Это серьёзный инструмент, дающий полное представление об использовании памяти в ясном для человека виде.

В man странице про данную команду сказано, что free отображает общее количество свободной и используемой памяти в системе, включая пространство подкачки и физической памяти, а также буферы с кешами используемые ядром операционной системы. Данная информация собирается путём разбора содержимого /proc/meminfo.

Как и другие команды, free прошла через череду изменений на протяжении своего существования, дабы вывод её был осмысленным и точным, что требуется для дальнейшего принятия решений. В RHEL 6 вывод утилиты free ощутимо отличается от вывода такового на RHEL 7 или 8. Впрочем, ключевые параметры остаются неизменными в любой версии.

Если вы наберёте free -h в RHEL 6 (я использовал ключ -h для вывода в удобном для человека виде), то вывод будет похож на этот:

[root@srv ~]# free -h
total used free shared buffers cached
Mem: 94G 44G 49G 161M 993M 1.3G
-/+ buffers/cache: 42G 52G
Swap: 15G 0B 15G

(Рис. 1)

В RHEL 7/8 вывод выглядит иначе:

[root@server1 ~]# free -h
total used free shared buff/cache available
Mem: 15G 751M 1.2G 272M 13G 14G
Swap: 0B 0B 0B

(Рис. 2)

В то же время, в RHEL 8 всё будет выглядеть следующим образом:

[root@tiger ~]# free -h
total used free shared buff/cache available
Mem: 819Mi 164Mi 146Mi 25Mi 509Mi 491Mi
Swap: 0B 0B 0B

(Рис. 3)

Дабы сделать вывод программы более понятным для восприятия, в команде предусмотрены следующие опции: free -b, -k, -m, -g. Они отображают количество памяти в байтах, килобайтах, мегабайтах и гигабайтах. Также вы можете использовать команду free -h для отображения вывода в удобном, понятном для человека виде. Если нужны подробности, запустите free --help для дополнительной справки по возможностям программы.

Различные столбцы, показанные в разных версиях выше, указывают на общую доступную память (total), использованную (used), свободную (free), разделяемую (shared) память. Помимо этого, в выводе отображается память, расположенная в данных момент в буферах и кешах операционной системы.

Впрочем, как и в случае с большинством других команд, необходимые для устранения проблем или выполнении служебных обязанностей системному администратору столбцы вывода команды будут рассмотрены далее.

Red Hat Enterprise Linux 6

В случае с RHEL 6, сфокусироваться следует на столбцах -/+ buffers/cache. На рис. 1 выше мы видим, что общее количество памяти равно 94 гигабайтам, где израсходовано 44 гигабайта и свободно 49 гигабайт. Вообще, это довольно нагруженная система и потребление памяти в ней выглядит высоким. Волноваться не стоит, хотя всё же следует посмотреть на столбец в -/+ buffers/cache. Данное значение показывает занятые 42 гигабайта и свободные 52 Гб. Это означает, что в реальности используется всего 42 гигабайта, а не 44. Значение задействованных 44 гигабайт включает себя ещё и кеши. Заметьте, даже простой взгляд на значение колонки used без учёта значения занятых кешей уже влияет на интерпретацию оценки производительности системы.

Теперь разберём смысл колонок со значениями буферов и кешей:

· buffers: память задействованная буферами ядра
· cached: память занятая “Page Cache” (страничным кешем).

Страничный кеш — не что иное, как данные / файлы, копируемые в оперативную память, в момент когда ядро операционной системы выполняет операции чтения или записи на диске. Причина тому — производительность операций ввода-вывода. Таким образом, ядро держит эти файлы в ОЗУ и высвобождает их в тот момент, когда они не требуются или когда пространство памяти запрашивается какой-либо командой или процессом в случае отсутствия свободной памяти в системе.

Red Hat Enterprise Linux 7/8

В операционных системах RHEL 7/8 уже следует сместить фокус на колонку available, поскольку колонка -/+ buffers/cache была удалена и заменена столбцом available. В то же время, столбцы buffers и cache были объединены в единое значение buff/cache и имеют ровно тот же смысл, что и ранее. Столбец available показывает оценку сколько памяти доступно приложениям без использования подкачки.

Так когда сисадмину всё же следует начать беспокоиться?

Исправна та система, которая показывает максимально возможный объём памяти достаточный для выполнения каких-либо задач, при этом демонстрирующая следующие ожидаемые признаки нормальной работы:

· Значение free близко к 0 или имеет очень небольшие значения
· Значение used близко к общему количеству RAM
· Значение доступной памяти в available (или же описанная в столбцах free -/+ buffers/cache) является относительно большой в сравнении с общим количеством памяти.
· Размер раздела или файла подкачки не меняется

Однако, системному администратору стоит начать беспокоиться, когда появляются следующие признаки реальной нехватки памяти:

· Значение столбца available (или же столбцов free -/+ buffers/cache) близко к нулю или весьма небольшое.
· Размер подкачки начинает расти или меняться из-за того, не хватает свободных страниц памяти и теперь необходимо их сбрасывать на диск
· В dmesg появляются сообщения об OutOfMemory-killer, которые проверяются командой grep -i kill /var/log/messages* или же dmesg | grep oom-killer.

Подведение итогов

Команда free — полезный инструмент, которая может очень рассказать системному администратору о том, что происходит в системе. Знание о различиях в выводе free может помочь в более точной интерпретации выдаваемых данных.

comments

Чиним работу Avahi/Bonjour в локальной сети с собственным резолвером DNS

2020-04-25T00:55:54Z

Крайне презабавную проблему недавно решил у себя. На полноценную статью не тянет. Так, заметка для младоадминов.

Долгое время было лень глянуть, с чего у меня в локальной сети крайне странно отдавались устройства с включённым Zeroconf (то есть с Avahi/Bonjour на борту). Особенность до кучи была в том, что Avahi по умолчанию работает с доменами .local, про что до сих пор не знают многие. Опытные админы уже явно приготовятся кидать в меня что-нибудь тяжёлое, но погодите возмущаться. Лучше загляните в RFC6762, который с 2013 года считается черновым, но уже крайне активно используется как известными вендорами, так и отдельными разработчиками (привет Леннарту Потеррингу, например). Более того, даннный псевдодомен первого уровня уже не рекомендовалсяк использованию в Windows Server 2003. Так что в настоящий момент данный TLD отдан под использование в сервисах mDNS.

Впрочем, отвлёкся. Итак, в чём странность?

А вот в этом:


# avahi-browse -ar

= wlp0s20f3 IPv4 Hostname                                      _xbmc-events._udp    local
   hostname = [hostname.local]
   address = [192.168.1.100]
   port = [9777]
   txt = []
= wlp0s20f3 IPv4 Hostname                                      _xbmc-jsonrpc-h._tcp local
   hostname = [hostname.local]
   address = [192.168.1.100]
   port = [8080]
   txt = ["uuid=410d41db-e758-4593-85cf-f4d0f0569a96" "txtvers=1"]

Казалось бы всё хорошо, Avahi корректно отдаёт и получает данные. Как от устройства локального, так и в домашней сети.

Но не тут-то было:


# host hostname
hostname has address 192.168.1.100

# host hostname.local
hostname has address 127.0.0.200

«Что за ерунда?», спросите вы. Ведь хост один и тот же! Более того, если вы попробуете опросить другие устройства с суффиксом .local (в моём случае это были смартфон и планшет) он упорно будет выдавать вам адрес 127.0.0.200.

Но при использовании утилиты dig, всё становится понятным моментально:



;; ANSWER SECTION:
hostname.local.         0       IN      A       127.0.0.200

;; Query time: 5 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) <== вот наши источник проблемы

Ответ прилетает от моего резолвера который установлен в роутере.

А разгадка проста. Когда была куцая прошивка от весьма дешманского роутера Xiaomi, просто не мог посмотреть в чём проблема и потому забил. После перепрошивки на что-то не столь убогое, у меня появился полноценный интерфейс с доступом к конфигурационным файлам роутера и там обнаружился всё тот же dnsmasq с пустым конфигурационным файлом.

Решение лежит на поверхности:


# Never forward plain names (without a dot or domain part)
domain-needed

# Never forward addresses in the non-routed address spaces.
bogus-priv

# Add local-only domains here, queries in these domains are answered
# from /etc/hosts or DHCP only
local=/local/

# Set the domain for dnsmasq. this is optional, but if it is set, it
# does the following things.
# 1) Allows DHCP hosts to have fully qualified domain names, as long
#     as the domain part matches this setting.
# 2) Sets the "domain" DHCP option thereby potentially setting the
#    domain of all systems configured by DHCP
# 3) Provides the domain part for "expand-hosts"
domain=local

Всё, после чего все устройства будут отдавать правильные адреса и будут корректно работать с приложениями Zeroconf использующими.

comments

Вытаскиваем докерфайл из образа

2019-08-28T21:27:03Z

В своё время неприятно удивился, когда обнаружил, что на Docker Hub перестали выкладывать докерфайлы от образов. Порой было полезно, чтобы понять почему образ докера так или иначе ведёт или собрать свой с небольшими модификациями не занимаясь всем с нуля.

Решается просто вот этой копипастой:

docker history --no-trunc <IMAGE_ID> | tac | tr -s ' ' | cut -d " " -f 5- | sed 's,^/bin/sh -c #(nop) ,,g' | sed 's,^/bin/sh -c,RUN,g' | sed 's, && ,\n & ,g' | sed 's,\s*[0-9]*[\.]*[0-9]*[kMG]*B\s*$,,g' | head -n -1

Не секретно, просто чтобы легче найти было.

comments

Как меняется всё

2018-07-01T12:33:29Z

Недавно одной подруге подготовил тут ноут с Линуксом. Человек потому что привык к нему и менять на что-то другое не хочет. Обнаружил, что некоторые проприоретарные (и не только) приложения нынче уже идут не обычными пакетами, а в формате AppImage или Flatpak вместо классических пакетов. Такой аналог .dmg в OS X, если кому непонятно. Забавно. Где-то, конечно, классические .deb/.rpm остались параллельно тоже.
Интересно, что AppImage так вообще "установки" как таковой не требует. Достаточно chmod +x сделать. Особенно прикольно, что не требует повышения привилегий, т.е. root. Ставится и работает прямо в /home.

Для Flatpak всё же надо поставить пакет один в систему, чтобы он понимал этот формат. Но суть ровно та же самая. Судя по тому, что я уже нахожу приличное количество пакетов в этом формате, это оценили.

С одной стороны, это упрощает жизнь пользователю. И поставщикам всяческих проприоретарных программ, когда не надо думать как же собрать пакет под 100500 дистрибутивов. С другой, уже многократно говорили, что теперь для закрытия уязвимостей придётся обновлять весь зоопарк софта и не факт, что вендор это сможет сделать. Хотя бы потому, что вендора к тому моменту может и не быть. А обновить разделяемую библиотеку которую использует много программ всё же проще.Правда тут возникает другой вопрос, а сможет ли потом программа с ней работать. :)
Но в целом, похоже небольшая революция в десктопном Linux всё же намечается. Или мне кажется?

comments

Принесло релевантным ИТ-чатом

2018-03-07T20:39:55Z

Собственно, я был свидетелем этого разговора, а потом этот текст перекочевал в Телеграм-канал "Devops from Hell".

В одном профильном чате некий собирающийся в SDS юзер попросил рассказать грустных историй про RedHat'овский GlusterFS.

Поскольку относительно недавно мы такое втащили на прод (v3.12), накопилось следующее:
* Не может в 4KN диски, т.к. там индусокод под капотом. Переписка с саппортом про 4kn показала, что им пофиг на платного кастомера и баг чинить никто не будет. С этого момента компания отказалась от платной подписки на RH. Из-за 4kn прикола встряли на замену 39 дисков.
* На RHEL7 под systemd демоны его падают каждые несколько часов, в логах sigterm (15), как будто systemd сам их мочит. В какой-то момент окно авторестарта демона совпало на чуть больше, чем половине машин, и кворум кластера был утрачен. Весь продакшен умер, потом вручную в RHV перезапускали все VM.
* OOM у glusterfsd - родовая болезнь. Оно у него всегда было есть и будет. По этой причине на гластер ставятся жирные по памяти машины без дополнительной нагрузки и задач. Делать HCI на нем - это самый короткий путь в OOM hell.
* Из не смертельного, но раздражающего:
- Туда нельзя положить файл размером больше брика, если брики одинакового размера
- Добровольно-принудительное использование XFS
- Проблемы с некоторыми сетевухами Dell из-за которых после нескольких дней uptime скорость GlusterFS деградирует до 10 раз (к счастью, излечимо)

Нужно ли такое в продакшене? Нет.

comments

Можете точно можете сказать "Теперь Ещё Один Всё Понял"

2018-02-04T15:34:46Z

Всё началось с того, что в какой-то момент у меня померла ROSA Fresh R9. Для видеокарт NVIDIA прилетел драйвер, положивший мне графическую подсистему. Попытка решить проблему по-быстрому и откатить драйвер на более старую версию привела к тому, что система перестала даже пускать через tty. То есть, оставалось только чрутиться и вытаскивать логи. Что было крайне странно, с таким поведением столкнулся впервые. Но поскольку дело было вечером, а я был уставший и с работы, забил на решение вопроса и просто поставил рядом Windows 10 Creators Fall Update, хотя запасной лаптоп тоже имеется. Тем более, что софт у меня кроссплатформенный по большей части, а скопировать данные не проблема. В общем, свитчнуться туда-обратно как два пальца об асфальт. Что я собственно и сделал. :)

Заранее отвечая на вопрос. Нет, сами по себе в NVIDIA не виноваты, если что. Эта проблема, как я понял, характерна для лаптопов с гибридной графикой. И я не один такой с этой проблемой был, как показало дальнейшее изучение вопроса. Впрочем это тема отдельная. Не будем в неё углубляться. Да и пост не про Linux, а Windows. Причём текст от человека, полноценно использовавшего Windows за своим домашним компьютером в последний раз больше 8 лет назад. До этого были только отдельные попытки посмотреть "нучотамумайкрософт". В основном, из под виртуальных машин, а не на "живом" железе.

Что поразило:

- Windows стал почти как Linux. Только Windows. Железо подцепилось ещё до первого логина, включая Wi-Fi. Недостающее автоматом подтянулось до самых свежих версий. Без моего участия вообще. Даже не заглядывал в Device Manager. Забавно, даже загрузочный splash screen автоматом стал фирменный, с логотипом производителя лаптопа.

Впрочем, пару драйверов потом вручную поставить пришлось спустя пару недель, когда я в Device Manager всё же залез.

- Внезапно, не требуется вобще никакой настройки звуковой подсистемы по умолчанию, чем мне в Linux приходилось заниматься сразу после первого входа в систему. При подключении внешнего звука операционная система сама уводит воспроизведение звуков туда. Впрочем настроить звуковую карту только для отдельных приложений никто не запрещает.

- Исправили ряд откровенно сырых мест, связанных с расположением настроек, которые видел в первой версии Windows 10. Всё больше и больше уходит в Settings, Control Panel уже почти не нужна. Скорее всего её готовят к удалению, но как водится у белых людей, а не красноглазых - она оставлена пока часть функциональности доступна только через неё. Вариант, в настольных ОС выпилят, оставят только в серверных.

- Наконец-то больше нет этого кошмарного изврата связанного с добавлением второго монитора в систему. В старых версиях Windows, даже в "семёрке", это работало неочевидно и не всегда правильно. Линуксоиды пинали тут Windows совершенно за дело. Сейчас достаточно нажатия сочетания Win+P. Причём не проблема добавить даже беспроводной монитор. Не хватает, пожалуй, только более продвинутого управления окнами. Тут линуксовые KWin или Mutter очень сильно опережают по возможностям. А виртуальные рабочие столы официально ещё в первых версиях Windows 10 появились.

- Они убрали этот ужасный подход к настройке сети, тянущийся со времён Vista, который не пинал разве что ленивый! Настройка VPN того же теперь стала очень удобной и простой.

- Беспроблемная работа работа ОС при длительном аптайме. Старые версии Windows в этом отношении были просто ужасны. Пара недель без перезагрузки и система ощутимо начинала лагать, даже несмотря на вроде бы наличие ресурсов. Одна из причин сподвигшая меня к переходу на Linux в своё время. Да, я не люблю выключать машину.

Что сразу стало лучше:

- Корректно работает гибридная графика. Тут же избавился от VGA-кабеля, на Linux HDMI работает не везде, в случае лаптопов с гибридными видеокартами. К тому же приходится выбирать между рабочим драйвером, где этот режим работает или родным драйвером NVidia, чтобы иногда в поиграть Steam. Есть ещё нюанс, что и драйвер не во всех конфигурациях может взлететь. Особенно если у вас HDMI выведен на дискретную карту, а не встроенную Intel. Если на работе я обычно ставил свободный драйвер и работал ОК, то дома такой подход не годится (см. Steam). А DisplayPort под Linux у меня не работал вообще, от слова "совсем". Теперь работает.

- Как следствие, у меня теперь корректная поддержка многомониторности. Окна переезжают сами туда-сюда, в зависимости от того, открыл я крышку лаптопа или закрыл. И да, мне теперь не надо прибивать приложения к основному экрану вручную. Что несколько бесило при переходе на KDE 5. Радовало только то, что настраивалось это очень быстро.

- Пропали все проблемы связанные со старыми приложениями вроде DOSBox, которые нормально с многомониторностью в Linux не дружили чуть более, чем никогда. Здесь почему-то с этим проблем нет!

- Мгновенная реакция на любые действия. В Linux такая отызвчивость достигалась либо в весьма простых WM, либо появилась только в KDE5, где значительно более корректно реализована работа OpenGL. У меня порой очень ощутимо лагал KDE4, несмотря на использование OpenGL в качестве рендерингового движка. Это стало очень заметно с переходом на KDE5. Опять же, чем занимались разработчики все эти годы? Пырились в консоль? Впрочем, не все со мной тут будут согласны.

- Корректная работа ACPI. Минуточку, на лаптопе у которого поддержка Linux заявлена вендором официально. Что вообще отдельная история. То есть наличие заявлений от производителя, что лаптоп поддерживает Linux годится только на конкретную версию ядра и конкретный дистрибутив и то есть нюансы...

- ...которые выражаются в том, например, что всё равно некоторые вещи работать не будут. В моём случае имело место некорректная работа USB3 на моём чипсете. Не самом редком, между прочим. Баг поганый, в сочетании с определённым железом он завешивал мне систему наглухо. Говорите, где баг? Пожалуйста: https://bugzilla.kernel.org/show_bug.cgi?id=116961. Всем срать, к слову.

- Пропал побочный баг, когда аудиокарточка при смене аудиопотока, при переключении между приложениями, не выдавала звук в течении 8 секунд. Именно так и проявлялось. Ровно 8 секунд не было звука при запуске любого аудиофайла. Замерял многократно в самых разных приложениях. В OS X и Windows всё работает мгновенно на этой же самой звуковой карте.

- Больше никаких костылей под ACPI. Корректно работает управление яркостью и громкостью. До релиза R9 мне два года пришлось держать костыль для этого в загрузчике. И даже с костылём проблема не была решена до конца. Всё равно был характерный "затуп" при вызове клавиш смены громкости/яркости, пусть и не такой суровый, когда в системе начинало заикаться и тормозить вообще всё.

- Снова появился доступ к огромному рынку рабочего ПО. Платного, бесплатного, свободного или проприоретарного. Под который не надо сидеть писать конфиги, подбирать сочетание библиотек и окружения.

- Корректно работающая работа мультмедийных приложений по сети. Теперь нет проблем скормить плееру фильм или музыку лежащую на сервере. Эту проблему не могут в KDE починить много лет. В Gnome всё работает. И это тоже проблема, я уже как-то писал, что VFS должен быть единым для всех VM и DE. Тому, кто расскажет про монтирование сетевых каталогов по NFS или SMB - посоветую провести эксперимент, связанный с временной недоступностью сети. Нормальная ситуация на лаптопах с Wi-Fi, например. Да, есть ещё костыль в виде autofs у которого есть проблемы с непредсказуемостью работы при нагрузке на сеть. Проверено в реальных боевых условиях под нагрузкой, к слову.

- Из мелкого. Корректная работа контролов. Во всех приложениях работает перемотка по колесу мыши, нет визуальных багов при переключений из полноэкранных OpenGL приложений в ОС. Например, во время работы какой-нибудь игры нажатие Alt+Tab не приведёт к сбросу настроек монитора, которое лечится ручным вызовом XRandr с нужными параметрами.

- Windows Subsystem For Linux почти созрела для моих задач. В Creators Fall теперь даже есть возможность работы с портами USB/COM. Кому надо разрабатывать эмбедщину - самое оно. Правда всё ещё нет поддержки raw sockets, надеюсь это вопрос времени.

- Забавное наблюдение, но мой принтер из под Windows печатает быстрее. И почему-то ни разу не возникло ситуации, когда он ни с того, ни с чего впадает в ступор и отказывается принимать задания, пока не зайдёшь в CUPS и не скинешь режим suspended. Почему так, не понимаю совершенно. Возникало абсолютно спонтенно. Принтер сетевой, аппаратный и без всяких GDI. Разницы быть не должно, но она есть. :(

- В целом стало меньше возни, расширился спектр поддерживаемого железа. Вот,пару месяцев назад прикупил себе на распродаже SteamLink который втыкаешь в телевизор и он сразу находит виндовую машину с запущенным Steam, ставит дополнительные драйверы в ОС и корректно всё транслирует на ТВ по сети.

Но не всё так хорошо, как мне хотелось бы. Чего не хватает:

- Замены KDEConnect. Очень хочется найти. Более-менее похожее можно назвать Pushbullet, но он требует доступа в онлайн и учётку Google для своей работы, что вообще странная идея. Да и работает очень неторопливо так, уведомления прилетают с заметной задержкой.

- Более гибкого управления окнами и скейлингом.

- Более продвинутого управления виртуальными рабочими столами. Пользоваться ими заметно менее удобно, чем Linux.

- Слабовата функциональность Search. Хочется возможностей Spotlight и Krunner. К тому же он почему-то индексирует далеко не всё или делает это очень странно. С чем связано неясно. Если кто пояснит за это, буду признателен.

- Возможности одноклавишного переключения раскладки. Даже в OS X меня бесит переключение по cmd + пробел. Раньше была старинная прожка для этого, но она сломалась в Windows Vista уже. С интересом приму предложения по замене.

- Отдельно огорчает отсутствие нормального эмулятора терминала по функциональности сравнимого с iTerm2 в OS X или Konsole в Linux. Но это не претензия к MS, просто нет такого класса программ пока, в связи с совсем недавним появлением WSL. Работа с серверами у меня никуда не девается даже с домашней машины. Впрочем, надеюсь со временем появится. Putty не предлагать, он ужасен и неудобен. К тому же его замучаешься цеплять к WSL. ConEmu жутко стрёмный и у меня не получилось научить обрабатывать ряд хотекеев. Хотя может исправили, попробую потом ещё разок.

Впрочем подвижки есть, уже реализовали нативный ssh-клиент для Windows. А также подогнали целую пачку BSD- версий стандартных утилит и добавят поддержку AF_UNIX.

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

В общем, я как-то подумал... И решил остаться на Windows 10 Creators Fall, в связи с чем даже честно взял лицензию. CentOS разве что на домашнем сервере останется. Там он работает безукоризненно. Просто потому, что серверные ОС пишут совсем другие люди.

А так, второй раз за долгие годы (после OS X) у меня вообще не возникло какого-либо желания что-то исправлять, патчить, залезать в куда-то глубоко в настройки, дабы сделать жизнь себе более удобной.

Хочется заметить, что Microsoft за за эти годы проделала очень большую работу и от былых претензий у меня уже нет и следа. А вот Linux, увы, до сих пор топчется на одном месте, за исключением серверного сегмента. То, из-за чего мне Windows не нравилась выпилено или переделано до человеческого вида. Исключение составило разве что отключения части функций телеметрии.

comments

ШГ ©

2017-10-01T12:05:52Z

Некоторые время назад я пересел на KDE5. В связи с тем, что он уже работает на другом рендеринговом движке, да и шрифтовой движок сильно изменился с тех пор, посему довольно раздражающей проблемой стала крайне плохо выглядящие шрифты в консольном ПО. В OSX и «дефолтные» весьма и весьма неплохи, то в Linux с зтим швах. До этого последних лет семь-восемь сидел на Terminus, но на новом движке он смотрится просто ужасно. Решение нашлось, за что благодарствую Алексею Федорчуку, aka alv. Семейство шрифтов Input. Шрифты несвободные, но для персонального использования можно взять совершенно невозбранно.

Ссылочку для стражджущих прилагаю. Можете почитать что за зверь и если надо, там же найти линк на скачивание.

comments

Ещё одна полезная шпаргалка

2017-09-05T20:36:08Z

Я уже как-то выкладывал ссылки на инструменты для профилирования ОС (см. верхний пост в блоге). Оказывается, есть дополнение к нему. Описание, а что мы вообще ищем и какого рода данные. Добавлю в свой список полезного, разумеется.

comments

О бездумном копипасте хаутушек

2017-08-03T17:57:40Z

Сегодня на работе разговор как-то зашёл о ресайзинге дисков в Linux под одну из наших задач. В частности, на одной из машин кто-то настроил LVM, положив всё сначала на раздел (mbr/gpt). Из-за этого не выйдет просто сделать pvresize, необходимо менять таблицу разделов. Что порой несколько проблематично, особенно для сервисов, которые критичны к перезагрузкам. Да, знаете ли, есть сервисы где даунтаймы неприемлемы даже на минуту.

Но откуда эти проблемы? А очень просто всё — большинство линуксоидов даже не в курсе, что можно сделать том LVM не создавая перед этим раздел в fdisk. Более, того, именно создание LVM на raw и является правильной практикой и уже потом можно на нём выполнить создание файловой системы. И из хаутушки в хаутушку бездумно кочуют шаги начинающиеся с fdisk /dev/sdX.

comments

2017-06-18T13:45:12Z

Я обещал написать про свой переход на KDE 5. Обещания надо сдерживать. :)

Итак, что хорошо в KDE 5?

Он быстрый. Нет, он реально БЫСТРЫЙ. Такое впечатление, что ты используешь какой-нибудь сверхкомпактный WM без ничего, настолько молниеносная реакция на всё. Причём не в SSD дело. Я и до этого его тестировал в виртуальных машинах и на «живом» железе установленном на обычном HDD. Windows даже с SSD кажется дико медлительным и тяжеловесным после него.
Рендеринг шрифтов. Он стал намного лучше.
Пропала необходимость в костылях подкладываемых в Grub, требуемых для корректной работы клавиш подсветки экрана. Наконец-то явно начата работа в сетевой части KIO-VFS. Smplayer уже наконец-то научился кэшировать и подгружать файлы кусками при воспроизведении из сети, а не качать целиком. DeaDBeeF теперь без проблем начал проигрывать песни с SMB хранилища, но вот Clementine увы. Хотя при этом отлично видит сеть и ресурсы расположенные на сервере.
Я не фанат «плоских» тем, но в этот раз мне реально нравится оформление, хотя есть ещё над чем поработать.
Krunner научился управлять гораздо большими вещами связанными с запуском программ, но всё же хотел бы видеть в нём ещё и функциональность Spotlight из OS X. Реально цены не будет. Тем более, что всё необходимое в движке давно KDE имеется! В KDE 4 зачатки этого даже были, кстати.
Заметно лучше стало с многомониторными конфигурациями. Теперь при закрытии крышки ноутбука он автоматически переносит экран на внешний монитор, если тот подключен.
Теперь стало можно убрать этот проклятый cashew! Спустя столько-то лет! Натурально, главная новость года. Спустя тонны тредов, твиков и мата в багрекерах разработчики признали, что эту штуку надо бы убирать, если она не нужна.
Встроенный архиватор Ark стал юзабельным спустя столько лет! И заметно более быстрым. Не может не радовать.

Что плохо:
Сыро, сыро, сыро! Вроде уже версия 5.9.4 у меня, плюс-минус все типовые задачи покрываются, но недоработок много.

Из того, что увидел сходу:

Отвалилась часть софта написанного на GTK+. Перестали работать глобальные клавиши (например в DeaDBeeF) и меню вызываемое правой кнопкой мыши (как минимум, в DeadBeeF и FileZilla) по щелчку в трее. Также если ты свернул программу в трей, невозможно её вернуть обратно. Только прибить и запустить заново. Касается не всех программ, но многих судя по воплям в Интернете.
Перестало работать отключение тачпада при подключении мыши. Теперь только вручную. Что очень неудобно.
Пару раз упала Plasma, но ничего серьёзного не сломалось, к счастью.
На экране входа не включается фокус на поле ввода пароля, если пользователь один в системе. Кстати, включённую раскладку не показывает тоже, зато можно посмотреть пароль.
Управление несколькими звуковыми картами. Приоритет звуковых устройств работает только для приложений написанных на Qt. Хотя раньше работало для всех (в т.ч. запущенных в Wine). В KDE 4 до PulseAudio 8.0 точно.
То ли не нашёл(?), то ли забыли вернуть на место настройку звуковых уведомлений для системы. В частности, не могу отключить системные звуки при удалении файлов, смене громкости с клавиатуры, и т.п.
Несмотря на улучшение работы с многомониторными конфигурациями, он всё ещё не умеет корректно запускать программы только на том мониторе, который у меня является основным. Нет, изменить можно и без проблем, конечно. Но требует ручной настройки, хоть она и быстрая — пара щелчков мышью.
При наличии очень гибких настроек для масштабирования интерфейса на HiDPI мониторах, при включении этой настройки часть софта отрисовывается с артефактами. Причём ладно бы написанного на другом тулките, точно так же проблемы с ПО на Qt5!
Определённо есть деградация производительности VFS в сетевых задачах. И уж точно он сосёт с производительностью в OSX (разика так в два причём).

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

Вот это всё нашёл в течение пары дней. Сколько найду в дальнейшем — ХЗ.
Я пока этот кактус догрызу конечно, но видимо всё-таки следующей системой у меня будет OS X (в чём я больше уверен), ну или перейду на Gnome 3 (хотя там свои проблемы тоже есть).

comments

Linux на декстопе, часть N

2017-06-04T11:59:12Z

Я давно откладывал написание этого текста в силу того, что считаю всё здесь написанное изрядным капитанством. Но, недавняя эпидемия WannaCry и очередная итерация воплей «надо переходить на Линукс!» сделала своё дело.
Эта заметка — печальное резюме моего трёхлетнего опыта работы над настольными дистрибутивами Linux и общих наблюдений за ситуацией в стране в ИТ-сфере в целом. Не претендуя на истину, выскажу лишь свои субъективные замечания, которые у меня сформулировались к текущему моменту. Я буду очень рад ошибиться в написанном, но сейчас я вижу ситуацию именно таким образом. Ещё раз напоминаю, что тут я говорю только о настолькном применении. Сервер и embedded — это совершенно другая стихия, здесь я их не затрагиваю.

Во-первых, он банально никому не нужен, потому что линукс-сообществу нечего предложить. За десятилетия существования системы никаких серьёзных инноваций за исключением серверного сегмента и некоторых техник из области программирования сделано не было. Но для конечного пользователя не было сделано ровным счётом… ничего. Даже фишки вроде менеджеров пакетов и те куда успешнее и лучше используются прямыми конкурентами. Тут я заодно процитирую своего бывшего коллегу Сашу Казанцева aka akdengi:

«Десктопный Линукс как был мифом так и остался. Окромя Гугла по сути никому не удалось что-то внятное на ядре сделать, да и тот "мутит" уже свое проприетарное. Лозунги про свободу, равенство и безопасность хомячков не прельщают…».

Единственное место, где кое-как подобные системы будут жить — защищённые дистрибутивы. Но это крайне узкоспециальная ниша, кроме особо секретных госов и военки нигде не будет востребована. Если говорить про Россию, теоретически, тема с импортозамещением может взлететь, особенно на почве текущих валютных колебаний. Но я в этом крайне сильно сомневаюсь. Профессиональное сообщество отнюдь не линукс-теоретиков уже успело крепко разочароваться итогами ряда проектов. Как итог, все, кто что-то знает и умеет, скрепя сердце расходятся в другие места. В том числе обратно в мир MacOS и Windows и на гораздо большие зарплаты.

Вторая причина была хорошо сформулирована уважаемым arkanoid на одной из посиделок с ним. Смысл её в том, что нет систем, которые будут просто удобны, пусть и без инноваций. И не красноглазым вроде нас, а обычным не техническим пользователям. Я сам считаю. что такие системы есть. На мой взгляд, здесь можно указать ROSA и ElementaryOS. Но проблема этих обеих ОС в том, что в масштабах Fedora или Ubuntu (и тем более Windows) они слишком маргинальны. Если вы пойдёте на произвольный сайт производителя программы, пишущего софт под Linux, то ROSA с Elementary в списке там явно не будет. А пакет, скачанный с этого сайта, будет заточен, скорее всего, под крайние версии какой-нибудь Fedora или Ubuntu. Не всякий техспециалист разберётся, как решать все эти проблемы с зависимостями. Да ещё в каждом конкретном пакете они будут свои. Про т.н. казуального юзера вообще молчу. Как вы понимаете, юзер плюнет на это и пойдёт куда? Правильно — в MacOS и Windows.

Третья причина вытекает из второй. Юзабилити и вообще отсутствие людей понимающих, что реально важно для пользователя. Если с юзабилити и так давно всё ясно. В 99,9% опенсорсного софта оно попросту отсутствует. И если консольные программы действительно почти достаточно неплохо отлажены и имеют более-менее унифицированный подход к работе (хотя, например, особенности работы find не в первый раз ставят в тупик даже подготовленных айтишников), то с графическими приложениями, несмотря на явный и заметный прогресс, дела обстоят всё ещё ОЧЕНЬ плохо.
С работой над важными для пользователя вещами всё ещё печальнее. Фактически, единственной ОС, которая хоть как-то пыталась решить эти проблемы, являлась всё та же ROSA. Но опять же, т.н. «продвинутое международное опенсорсное сообщество» (в реальности же дико косное, не желающее перемен и всё ещё боготворящее технологии и подходы тридцатилетней давности, отягчённых вдобавок NIH-синдромом) даже не поняло постановки вопроса. Какие-то очень скромные наработки в эту сторону есть у openSUSE и Ubuntu, но там это реализовано настолько топорно, что хочется плакать. С Ubuntu ситуация к тому же крайне плачевная. За столько лет жизни Canonical, Марк Шаттлворт так и не нашёл как это можно монетизировать и дистрибутив медленно, но верно идёт ко дну. Один из таких звоночков, Ubuntu с большим трудом смогла устранить проблему с LightDM после ухода Мартина Питта и сокращение штата компании в целом. Кругом сплошные стратеги, концентрирующихся на глобальных вещах, но начисто игнорирующие всё остальное. В итоге дистрибутивы релизятся с такими проблемами, что не знаешь плакать или смеяться.
Почему такое происходит? Да всё то же самое, о чём говорили многие и не по одному разу хоть сколько-нибудь вменяемые специалисты. У технарей работа юзабилистов и дизайнеров вызывает непонимание и нередко презрение. А зря. И проблема осложняется тем, что, например, юзабилисты — класс специалистов, который just for fun не работает в принципе. За крайне редкими исключениями. Не говоря уже о том, что юзабилити-тестирования «по науке» требуют недешёвого оборудования, студий и массу людей (которым тоже надо заплатить). Одним лаптопом или системником для работы здесь не обойдёшься.
Усугубляет проблему тот факт, что нет единого стандарта на интерфейс и в целом отсутствуют хоть какие-то гайдлайны. К настоящему моменту у нас имеется адская куча фреймворков и тулкитов, в которых одна и та же программа не то, что отрисовывается — ведёт себя по-разному! Вот что мне навскидку вспомнилось: Qt всех версий, GTK+ всех версий, wxWidgets, EFL… Корпоративный софт вообще до сих пор нередко сидит на давно забытом ПО. К примеру, GUI клиента для Cintrix XenApp под Linux, отвязалось от древнего Motif только в прошлом или позапрошлом году! И добавьте к этому кошмарный зоопарк из WM и DE. Те кто считают, что ничего сложного в поддержке такого нет, рекомендую в качестве практического упражнения сесть на первую линию техподдержки какого-нибудь провайдера и попробовать настроить Интернет (скажем, PPPoE) по телефону без всяких там Radmin и TeamViewer не разбирающимся в технике лиентам с: Windows XP, Vista, Windows 7, Windows 8, Windows 8.1 и немножечко MacOS разных версий. А есть ещё люди установившие себе всякие ZverDVD… После недельки работы там, быстро мнение о простоте работы поменяете.
О тестировании всего этого зоопарка я просто помолчу, как о покойнике.

Последняя и самая серьёзная проблема в Linux, заключается в его собственной природе. Не существует такой ОС как Linux. Linux — это ядро. Вместо этого есть горка разрозненных операционных систем, нередко тотально несовместимых между собой это самое ядро использующих. Почти три года назад я уже вскользь упомянул об этом. На сей раз, я скажу более прямо — надо закапывать почти все дистрибутивы и оставлять не больше четырёх-шести. Причём оставшиеся должны быть максимально совместимы между собой. Опыт Android, ChromeOS, да что там говорить, даже MacOS, говорит за то, что единая платформа — благо для подавляющего большинства. А что до остальных… Ну, есть же тематические формы посвящённые ОС на ассемблере там. Пусть живут, но про них будут знать считанные единицы и хоть сколько-нибудь всерьёз про них не говорят.
Безусловно, причин провала Linux на десктопе существенно больше, я затронул лишь самую очевидную верхушку. Начиная от крайне узкотехнических проблем вроде отсутствия поддержки криптоконтейнеров через pkcs#11 в GnuPG или проблемах линковки библиотек в разных системах, кошмарное количество уже написанного legacy, которое набило оскомину абсолютно всем (собственно, на одном из проектов над которым работал, видел реально рабочий и до сих пор активно эксплуатирующийся софт, написанный на Oracle Forms 6i, например). Или если уж совсем энтерпрайзно — SLA. Точнее, его отсутствие.
А почему Linux не пошёл в госсекторе, писал добрых семь лет назад. И за эти годы ситуация практически не изменилась. Если не сказать — стало хуже.

Дискасс.

comments