LINUX.ORG.RU

ALT 8.0 Server с sysvinit и без pulseaudio и тяжёлых DE

 ,


1

2

Посмотрел на ALT 8.0 Server в действии. Весьма приятный дистрибутив. Особенно приятно то, что, в отличие от некоторых дистрибутивов (не будем показывать пальцами), всё заботливо выложено с исходниками.

Пакетная база тоже весьма приятная и обширная. Одних только исходников на 56 гигов. Впрочем, дистфайлов той же Генты уже давно более чем на полторы сотни гигов. Но, и это гораздо больше чем у многих дистрибутивов. Зеркало того же Debian'а достигает 130-ти гигов только когда включает в себя пакеты для двух архитектур (x86_64 и i386), а также исходники. А это один из самых крупных дистрибутивов наряду с Гентой, да. Для зеркалирования же пакетов для x86_64 + noarch и исходников Альта потребуется 123 гига свободного пространства.

Соответственно, в дистрибутиве включены многие фичи, которые выключены в минималистических дистрибутивах по дефолту. Например, mplayer сразу из коробки слинкован с libopencore-amrnb.so.0 и libopencore-amrwb.so.0. Ну и вообще всё пропатчено и более тщательно подогнано друг к другу. Конечно, и в том же Slackware можно самому всё пересобрать, но это надо пересобирать. А здесь все блага цивилизации сразу из коробки. Конечно, в том же Debian'е тоже многое включено из коробки, но это разные дистрибутивы с разными пакетами и разными опциями.

Например, в репозитории Альта есть xmms, mplayer, purple-plugin-vk,... и т.д., которых нет в Debian'е. При этом в репозитории Альта есть FVWM и десктопный софт, которых нет в том же CentOS (хотя частично и присутствуют в Федоре).

При этом версии пакетов намекают на то, что это дистрибутив не для тех, кто любит гнаться за циферками версий, а для тех, кто предпочитает более отлаженный софт. Так, например, Perl здесь версии 5.22.3, Python версий 2.7.11 и 3.5.1, ruby 2.0.0p510,... и т.д.

По умолчанию в серверной версии идёт systemd, но легко удаляется. Правда, сразу после этого система оказывается в несостоянии перезагрузиться или отключиться, но можно сделать sync и нажать Reset. После перезагрузки этот момент придёт в норму. Правда, от пакета systemd-utils и systemd-udevd в процессах просто так не избавиться. Зато никаких systemd-shim. pulseaudio по умолчанию просто нет, и можно спокойно не ставить.

Локальное зеркало репозитория делается и подключается не совсем интуитивно, но делается и подключается. Дефолтные дистрибутивные конфиги подразумевают, что разделение по архитектурам начинается в p8/branch, но в тех директориях только симлинки. Сами файлы находятся в p8/branch/files. Можно зеркалировать сразу p8/branch/files переименовывая RPMS в RPMS.classic, а потом прописывая так:

rpm [p8] file:///mnt/mpt0/system/alt p8/branch/files/x86_64 classic
rpm [p8] file:///mnt/mpt0/system/alt p8/branch/files/noarch classic

Что же касается лицензий, то и авторы той же Убунты вполне считают её своей интеллектуальной собственностью, но это мало кого от неё отпугивает. Физическим лицам же лицензия Альта вполне позволяет использовать его совершенно спокойно. Ну, а то, что юридическим лицам нужно платить за лицензии, так на то они и юридические лица. Вся эта схема подразумевает, что экономика должна развиваться, юридические лица должны получать прибыль, а труд маинтейнеров дистрибутивов должен быть оплачен.

На скриншоте: оконный менеджер Blackbox (менее функциональный (и более юниксвейный) предок Fluxbox'а), XMMS, Nedit, xlinks, xfe, sakura и эмулятор ZX Spectrum'а Fuse.

>>> Просмотр (1920x1080, 869 Kb)

★★★★★

Проверено: JB ()
Последнее исправление: saahriktu (всего исправлений: 1)

Ответ на: комментарий от intelfx

И да: надеюсь, ты помнишь, что в systemd >70 бинарников, из которых только два требуют друг друга, а остальные сугубо опциональны и частью «комбайна» считаться не могут?

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

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от intelfx

А я тебе уже опровергал это высказывание.

Ты чушь нёс и сову на глобус натягивал, а не опровергал.

AS ★★★★★
()
Ответ на: комментарий от AS

Ты чушь нёс и сову на глобус натягивал

А я могу сказать, что этим занимался только ты.

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Этим занимался только ты.

Ты мне так и не рассказал, как собирать и обновлять udev отдельно от всего остального в рамках сборки пакетов в дистрибутиве, а не занимаясь рукоблудием с make install. Опишешь юзекейс, тогда будем говорить, что это - не комбайн. При чём юзекейс должен быть такой, чтобы он был вменяемым для применения в дистрибутиве.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 2)
Ответ на: комментарий от AS

Ты мне так и не рассказал, как собирать и обновлять udev отдельно от всего остального в рамках сборки пакетов в дистрибутиве

Что значит «как»? Генерируешь билдсистему, пишешь make systemd-udevd (и какие-то ещё общие сборочные цели, не помню уже), потом опакечиваешь полученные бинарники.

не занимаясь рукоблудием с make install

Знаешь, очень сложно «не заниматься рукоблудием с make install» в сборочной системе на основе autotools и make.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от AS

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

Кажется, ты не очень хорошо понимаешь значение слова «юзкейс». Советую заглянуть в словарь.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Журналирования в основном демоне systemd никогда не было и не планируется. Потрудись хотя бы немного изучить предмет спора, прежде чем в него влезать.

https://habrahabr.ru/company/selectel/blog/264731/

Демон инициализации systemd де-факто уже стал стандартом в современных Linux-системах. На него перешли многие популярные дистрибутивы: Debian, RHEL/CentOS, Ubuntu (начиная с версии 15.04). В systemd используется принципиально иной (по сравнению с традиционным инструментом syslog) подход к логгированию.
В его основе лежит централизация: специализированный компонент journal cобирает все системные сообщения (сообщения ядра, различных служб и приложений).

Потрудись объясниться.

... спора, прежде чем в него влезать

Я вообще ни с кем не спорю. Я сейчас решаю перелезать мне на FreeBSD или нет.

zoroaster
()
Ответ на: комментарий от zoroaster

Потрудись объясниться.

Запросто: статью писали некомпетентные болваны (или косноязычные болваны, тут возможны варианты).

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Что значит «как»? Генерируешь билдсистему, пишешь make systemd-udevd (и какие-то ещё сборочные цели, не помню уже), потом опакечиваешь полученные бинарники.


Ты придуриваешься, или что ? Кто за версиями следить будет и как, когда там версии синхронно с версией systemd меняются и всё живёт в рамках одного дерева исходников ? Ты трудозатраты на такое разделение хоть в принципе оценить в состоянии ?

Знаешь, очень сложно «не заниматься рукоблудием с make install» в сборочной системе на основе autotools и make.


Про рукоблудие - это про установленную систему.

AS ★★★★★
()
Ответ на: комментарий от AS

А это уже твои проблемы, тем более что systemd+udevd — как раз те два бинарника, которые можно называть комбайном (т. к. они interdependent). Во всех остальных случаях достаточно написать неравенство на версию основного демона и одновременно устанавливать все требуемые версии libsystemd-shared.so.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Кажется, ты не очень хорошо понимаешь значение слова «юзкейс».

use case. Какой ещё словарь ?

AS ★★★★★
()
Ответ на: комментарий от zoroaster

Из картинки замечательно видно, что systemd и journald — разные демоны. Следовательно, журналирование не входит в функциональность демона systemd.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Во всех остальных случаях достаточно написать неравенство на версию основного

Я тебе приводил пример. Допустим, нашли проблему в компоненте. Как пересобрать только его без увеличения версии всего остального, если всё собирается вместе ? А пересборка всего с увеличением и потянет ненужное обновление всего в системе.

AS ★★★★★
()
Ответ на: комментарий от zoroaster

Учимся переводить: «демоны в составе [проекта] systemd». «systemd» — так называется и главный демон, и проект в целом.

intelfx ★★★★★
()
Ответ на: комментарий от AS

Посмотреть на изменения используемых этим компонентом API. Скорее всего, их не будет. После чего просто взять и пересобрать.

intelfx ★★★★★
()
Ответ на: комментарий от zoroaster

Нет, дорогуша, в твоих словах речь шла именно о демоне systemd:

демон нарушает KISS и принципы UNIX тем что забирает себе всё больше и больше функций. Даже журналирование.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Посмотреть на изменения используемых этим компонентом API. Скорее
всего, их не будет. После чего просто взять и пересобрать.

Как ? Как не увеличить версию всего остального ? Правильно. Надо кучу srpm для сборки каждого компонента, и с одинаковым тарболом внутри. Даже в KDE компоненты отдельно формируются, а systemd - всё в одном. Клёво, что...

AS ★★★★★
()
Ответ на: комментарий от AS

Никто не обещал разбивать .tar.gz на части; это вопрос удобства, а не архитектуры. Вообще, ты начинаешь выдвигать дополнительные требования. Совместимость модулей между разными версиями комплектов модулей (тем более прямая(!), а не обратная) не входит ни в одно определение модульной системы.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от intelfx

Ты цепляешься за слова. Понятное дело что это не один демон, о том и речь, что система инициализации тянет за собой ещё кучу всего остального, что кучу людей не устраивает.

zoroaster
()
Ответ на: комментарий от zoroaster

Ты цепляешься за слова.

Я не обязан уметь читать твои сумбурные мысли. Я отвечаю на то, что написано. Потрудись изъясняться аккуратно и правильно.

о том и речь, что система инициализации тянет за собой ещё кучу всего остального

Система инициализации не тянет за собой кучу всего остального. Подробности — прямо здесь, в параллельном обсуждении с участем меня и AS.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от zoroaster

Ты цепляешься за слова

И да: я не «цепляюсь за слова», я препятствую подмене понятий с твоей стороны.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

удобный уровень абстракции

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

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от intelfx

Никто не обещал разбивать .tar.gz на части. Вообще, ты начинаешь выдвигать дополнительные требования.

Совсем нет. Это - удобство поддержки в дистрибутиве. И из-за идиотизма разработчиков systemd получилась жопа. А про KISS потом поговорим - сейчас я выпивать пойду. :-)

AS ★★★★★
()
Ответ на: комментарий от intelfx

Система инициализации не тянет за собой кучу всего остального.

Увы, тянет, и совершенно дебилным и ненужным способом. Всё, ушёл. Сегодня буду вряд ли.

AS ★★★★★
()
Ответ на: комментарий от AS

У тебя так и не получилось это обосновать. Вместо этого ты доказал, что билдсистема systemd не приспособлена для сборки разных версий отдельных компонентов. С этим я, конечно, согласен. Но это немного не то.

intelfx ★★★★★
()
Ответ на: комментарий от saahriktu

Потому что задачи, которые решает systemd (управление запущенными процессами), требуют наличия runtime-компонента.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

управление запущенными процессами
наличия runtime-компонента

Системные вызовы никто не отменял. То же создание нового процесса (fork()) - это тоже управление процессами, но для него наличие дополнительного демона не требуется.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

Ты что мне доказать хочешь? Я говорю: для тех функций, которые пытается предоставить другим программам systemd, «просто библиотеки» недостаточно. Нужен runtime-компонент, т. е. демон. Для традиционных операций с процессами в стиле POSIX таким runtime-компонентом выступает ядро, а для операций, которые реализует systemd — им выступает юзерспейсный процесс этого самого systemd.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Для управления процессами достаточно системных ядерных вызовов. При недостаточной функциональности ряда ядерных системных вызовов нужно расширять этот самый ряд системных вызовов ядра. А потом будет достаточно и библиотек, которые будут управлять процессами через ядерные вызовы. Без всяких дополнительных демонов.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

При недостаточной функциональности ряда ядерных системных вызовов нужно расширять этот самый ряд системных вызовов ядра.

Неверно. Это будет нарушать mechanism/policy separation. С точки зрения ядра, systemd — это «policy». (А с точки зрения прикладных приложений, systemd — это «mechanism». Такая вот относительность.)

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Гм. Ну, если посмотреть с этой стороны... Тут, конечно, можно согласиться с тем, что такой демон может быть полезен.

Однако, в любом случае совершенно не обязательно использовать такой демон в качестве замены системе инициализации. Можно использовать такой демон как необязательное дополнение к sysvinit. Кому нужно - запускают, кому не нужно - не запускают.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от intelfx

Вместо этого ты доказал, что билдсистема systemd не приспособлена > для сборки разных версий отдельных компонентов.

Так вот это и есть тот самый дебильный способ устроить ненужную взаимосвязь.

AS ★★★★★
()
Ответ на: комментарий от d_a

Жаль, я уж с попкорном сел, как в старое время :)

Так я же не насовсем тему покинул. :-)

AS ★★★★★
()
Ответ на: комментарий от intelfx

Нет, дорогуша, в твоих словах речь шла именно о демоне systemd:

Даже журналирование.

Теперь я подключусь. Скажи мне, что будет с логами, если systemd установить, а journald (или как его) - нет ? Опять же, наличие systemd-journald в основном пакете это что ? Ошибка мантейнера ? Ему стоило journald отдельно паковать ?

AS ★★★★★
()
Ответ на: комментарий от AS

Какая «ненужная взаимосвязь» появляется оттого, что все компоненты распространяются в одном дереве исходников? Никакой.

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

intelfx ★★★★★
()
Ответ на: комментарий от AS

Скажи мне, что будет с логами, если systemd установить, а journald (или как его) - нет ?

Всё хорошо с ними будет. Логи самого systemd уйдут в kmsg, а stdout/stderr запущенных им процессов — в /dev/null (как и раньше).

Опять же, наличие systemd-journald в основном пакете это что ? Ошибка мантейнера ?

Это следование рекомендациям. Апстрим говорит, что не хочет поддерживать конфигурации без journald (имеет право).

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

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

Разумеется, можно из одного srpm собрать несколько бинарных пакетов. Но. Они, всё равно, собираются они все вместе, версионные зависимости меняются синхронно. И, даже, если ты зависимости сделаешь не жёстко, и сможешь обновить отдельный пакет, оставив остальные с меньшей версией, команда общего обновления системы попытается втянуть всё, где версия выросла.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от intelfx

Логи самого systemd уйдут в kmsg, а stdout/stderr запущенных им процессов — в /dev/null (как и раньше).

Возьму по journald таймаут до завтра - нужен бук с systemd, который на работе остался. :-)

что не хочет поддерживать конфигурации без journald (имеет право).

Ага, насаждая комбайн ещё и административно.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

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

К счастью, в курсе. Возможно, я немного Arch-biased — но, кмк, всё то, что можно сделать в примитивном pacman'е, должно быть можно сделать и в более продвинутых пакетных менеджерах.

Они, всё равно, собираются они все вместе, версионные зависимости меняются синхронно.

И что? Кто заставляет делать их (зависимости) жёсткими?

И, даже, если ты зависимости сделаешь не жёстко, и сможешь обновить отдельный пакет, оставив остальные с меньшей версией

Вот именно.

команда общего обновления системы попытается втянуть всё, где версия выросла.

Я стесняюсь спросить, а ты как хотел?

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

команда общего обновления системы попытается втянуть всё, где версия выросла.

Я стесняюсь спросить, а ты как хотел?

Не надо стесняться, спрашивай. :-) Я хочу, чтобы обновление udev было обновлением только udev (к примеру, раз уж я к нему изначально цепляюсь), и чтобы dist-upgrade не предлагал, после обновления udev в репозитории, ещё вытянуть и systemd, который вовсе трогать не требовалось, но который, ввиду общей сборки из одного srpm, совершенно напрасно увеличил версию.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

Так жёсткие зависимости как бы намекают, что systemd-udevd уже некоторое время не рассчитан на работу вне остальных компонентов systemd, хоть и может.

Если после появления systemd в LFS'е с sysvinit'ом использовался udev из состава systemd (т.е. его реально было собрать отдельно не собирая весь systemd), то в последнее время все версии всех дистрибутивов без systemd в качестве дефолта перешли на eudev.

saahriktu ★★★★★
() автор топика
Последнее исправление: saahriktu (всего исправлений: 2)
Ответ на: комментарий от saahriktu

что systemd-udevd уже некоторое время не рассчитан
на работу вне остальных компонентов systemd, хоть и может.

На самом деле может. У меня systemd не используется, но udev работает. Библиотеки вот да, нужны:

libsystemd-230-alt1.M80P.3
libudev1-230-alt1.M80P.3
systemd-utils-230-alt1.M80P.3
udev-230-alt1.M80P.3
udev-extras-230-alt1.M80P.3
udev-hwdb-230-alt1.M80P.3
udev-rule-generator-net-230-alt1.M80P.3
udev-rules-230-alt1.M80P.3

AS ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.