Тонкий клиент WYSE C10LE и состояние 32-битных систем
Запустил Debian 11 с LXQt на WYSE C10LE — тонком клиенте из 2010, построенном на платформе VIA Eden Esther VX855 — несуперскалярном 32-битном процессоре x86 с частотой в 1 ГГц, 512 МБ DDR2 RAM и 128 МБ флеш-памяти, подключённой к шине IDE.
Процессор относительно современный, в наличии SSE2 и SSE3 (PNI). За видео в этом SoC отвечает VIA Chrome9 HCM, поддерживающий DirectX 9 и декодирование H.264 в Windows, но в Linux обеспечивающий только самое базовое 2D-ускорение средствами открытого драйвера OpenChrome. Также существует проприетарный драйвер, поддерживающий 2D и 3D, но только под Ubuntu 12.04-12.10.
Система работает, на удивление, не так уж и плохо. Для совсем старых и низкопроизводительных платформ существует только один сравнительно современный веб-движок — QtWebkit, который устарел, плохо обрабатывает современный javascript и содержит известные уязвимости, зато присутствует во многих дистрибутивах в том или ином виде, хоть как-то поддерживается и — главное — быстро рендерит и потребляет малое количество памяти.
На фотографии представлен веб-браузер Qutebrowser с 7 открытыми вкладками, в режиме работы с QtWebkit. Как видно, даже с 7 вкладками (2 из которых — страницы Википедии с большим количеством картинок) браузер потребляет около 140 мегабайт, что позволяет комфортно сёрфить интернет на смешных 512 МБ RAM.
Из других браузеров, до сих пор поддерживающих QtWebkit, можно отметить Otter Browser и KDE’шный Konqueror, который дополнительно поддерживает еще и KHTML (3 движка в одном браузере), но в Debian собран только с WebEngine. Первый в репозиториях Debian не присутствует.
Браузер Seamonkey, актуальная версия которого построена на базе движка из Firefox 60, работает более-менее сносно, но не блестяще — рендерит дольше QtWebkit’а примерно в 2-3 раза, потребляет заметно больше памяти, зато работает со всеми современными сайтами. Можно использовать в качестве запасного варианта, когда QtWebkit не справляется.
Опробовав разные дистрибутивы на этой машине, обнаружил следующие особенности и проблемы:
- Syslinux на этой платформе запускается сам и загружает ядро и initrd на порядок быстрее GRUB2 — 5 секунд против примерно 1 минуты. Бегло посмотрев код загрузки ядра и включив режим отладки в GRUB, каких-то очевидных проблем, которые могут вести к такому поведению, не обнаружил, детально отлаживать не стал. Загрузка в GRUB2 происходит по USB 2.0, не по 1.1 (загрузчик plop перед запуском grub не ускоряет процесс).
- У syslinux на удивление плохая документация. Quick start’ы из wiki все какие-то недописанные — не пошаговое руководство, а разрозненная информация. Нигде не говорится о необходимости копирования .c32-файлов, если нужно меню — додумался сам, благо кучу раз видел файлы syslinux в других дистрибутивах.
- С некоторыми вызовами ACPI на WYSE наблюдаются проблемы. В частности, thermal-подсистема отдаёт ответ по 5-6 секунд, что и замедляет загрузку ядра, и тормозит на 5-6 секунд каждый вызов утилиты sensors. Благо, в ядре есть отдельный thermal-драйвер под процессор, что позволяет отключить ACPI thermal без последствий и потери в функциональности.
- Все GTK3-приложения подтормаживают, медленно прорисовывают окна, с задержкой откликаются на действия. Возможно, дело в теме, но её смена и попытка отключить все анимации к заметному ускорению не привели. GTK2 и Qt5 откликаются на действия быстро, работают хорошо.
- В последних версиях ядра Linux (в т.ч. LTS-ветке 5.15) присутствует ошибка, приводящая к зависанию этого процессора (вот эта проблема)
- Графический сеанс Debian не запускался сразу после установки. Проблема оказалась в systemd: systemd-logind устанавливает опцию CanGraphical=false из-за видео, потому, что драйвер OpenChrome выполнен в виде X.org DDX, и ни DRM, ни FB не поддерживаются. Простое решение — добавить nomodeset в строку запуска ядра: [1], [2]
- В archlinux32 всё сломано: многие программы не запускаются из-за обновлений библиотек без перекомпиляции всех пакетов, от них зависящих, т.к. не всегда их возможно перекомпилировать с современными версиями библиотек и компиляторов (многим «жирным» проектам требуется больше 4 ГБ виртуальной памяти для сборки, они падают на 32-битных системах, а кросс-компиляция в archlinux32 не используется). Разработчики выпускают shim-пакеты со старыми библиотеками, чтобы хоть как-то вернуть работоспособность программ, но библиотеки необходимо устанавливать вручную, в виде зависимостей к пакетам они не прописаны.
Устанавливаешь chromium — не запускается, seamonkey — не запускается. Удручающее зрелище. - Дистрибутив slitaz включает веб-браузер и кучу программ в 50 мегабайт iso-образа, но тоже страдает от проблем с версионностью библиотек. Многие пакеты серьёзно устрарели, но сам факт возможности упаковки веб-браузера, аудио и видеоплеера, полноценной темы со всеми иконками, всех возможных средств настройки системы и прочего всего в 50 мегабайт впечатляет. Проект почти не развивается.
- Основные устоявшиеся дистрибутивы Linux либо не формируют .iso для x86, либо вовсе не предоставляют 32-битных пакетов. Некоторые форки RHEL, такие как Rocky Linux, можно забутстрапить из 32-битных репозиториев, также есть x86 ISO OpenSUSE Tumbleweed (который rolling release), но если смотреть глобально, полноценная поддержка x86 осталась только в Debian.
- zstd даже с -22 –long не дотягивает до степени сжатия xz -5 для упаковки rootfs.
>>> Просмотр (3728x2700, 1280 Kb)