Дистрибутив Calculate Linux официально переходит на eudev

Нормальным, понятным и удобным образом иметь systemd-udevd одной версии, а systemd - другой будет не сильно просто.

Да, разные версии systemd и udev — столь необходимое условие для нормальной работы. Я не устаю поражаться аргументации противников системд.

нуда. В системе бывают армогедоны, когда рабочая командная строка уже чудо.

Но kwrite врятли может делать аля tail -f, а потом еще и grep сверху, например. Емакс, кстати, так может. И удаленный доступ тоже.

а я сомневаюсь что kwrite может адекватно смотреть логи по сети.

Не сомневайся. И по ssh, и по ftp и как угодно — открой для себя kioslave :-)

Согласен, навык выживания это умение пользоваться man.

Угу. Тут да, мне, например, навыки работы с vim помогли, когда я починял из busybox систему.

Я про войну. И man может не быть. Тот же busybox.

переход на eudev, с целью ухода от «непредсказуемой тенденции развития systemd».

Как хорошо, что есть ещё на свете разумные люди.

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

Но с унынием надо броться, а потому вот вам немного критики systemd, но не в бытовом, а в классическом, древнегреческом смысле. Мои высказывания основаны на многолетнем опыте использования GNU/Linux в проде, на системах с LA, отличным от нуля, как до «эпохи» systemd, так и после неё.

1. Бинарные логи. Это одна из самых любимых тем как хейтеров, так и фанатов. Хейтеры сетуют на то, что их неудобно читать. Читать? Это как? На ночь, прямо из файла? Читайте лучше классиков мировой литературы, ей-богу! Логи — это не книга на ночь, их можно читать только в контексте поиска ответа на конкретный вопрос, и это возможно эффективно делать только используя фильтрацию вывода. Как часто вы читаете /var/log/messages целиком, и как часто вы в нём что-то грепаете? Поверьте, грепу всё равно, stdin открывать, или файл на диске. Кроме того, никто не запрещает вести человекочитаемые логи в обычном месте и иметь при этом бинарные. В чём профит? В производительности. Когда у вас в минуту генерируется хотя бы полторы-две тысячи сообщений со всей сети, бинарные логи очень быстро перестают казаться чем-то ненужным, как принято говорить на ЛОРе. Бинарный лог меньше по размеру обычного текстового, он быстрее записывается на диск и быстрее передаётся по сети. Вы понимаете всю важность быстрой записи на диск и передачи по сети при фатальных крахах системы? Иногда счёт идёт на миллисекунды, каждая — это 125 килобайт ценнейшей информации. И важность такого поведения растёт с количество серверов. Вы думаете все эти splunk, new relic и прочие, они от хорошей жизни появились? Впрочем, нет никакой необходимости хранить бинарные логи на домашней машине.

2. Переименования интерфейсов. На этот раз камень в огород команды systemd. Старая схема именования обладала всеми теми же признаками, какими обладает новая. Менять её совершенно бессмысленно. Старые умолчания делают всё то же самое, но при этом они, что называется, vendor-agnostic. Если название вендора действительно важно — и я уверен, что такие ситуации бывают — lshw в помощь.

3. Старый «добрый» SysV Init. Нет, нет, нет и ещё раз нет. Писать инициализационные скрипты для SysV Init неоправданно неудобно. Посмотрите на процесс инициализации любого «большого» ПО, например PostgreSQL, и вы всё поймёте сами. И кто как не инит — корневой процесс системы, единый предок всех остальных процессов — должен следить за тем, чтобы то, что было запущено оставалось запущенным? Да, я знаю про daemontools. И как это делать из крона. И как это делать ещё несколькими разными способами. Но вопрос остаётся прежним: почему это должно оставаться заботой админа? Забота админа придумать как должно быть и починить то, что поломалось, а не бегать за системой и не уговаривать её держать падучий Bind запущенным. Однако, текущая реализация в systemd не решает проблемы с неудобными скриптами. То, что легко делается юнитами не вызывало проблем и с SysV Init, однако посмотрите как теперь выкручиваются с инициализацией PostgreSQL. Кода, по ощущениям, стало больше. Только теперь он написан в обход systemd, а не в обход SysV. Полный провал.

[продолжение следует]

4. Tight coupling. Да, формально systemd придерживается модульной архитектуры. В реальности, модульности нет. Работает либо весь комплект сразу (ну, может быть за исключением каких-то мелочей), либо не работает ничего. Но это не от убогости самой идеи, это от безрукости архитекторов и лени программистов, которым некому надавать по рукам. RedHat умеет зарабатывать деньги, но не умеет руководить проектами такого уровня. И чем больше ошибок будет молча принято, тем сложнее будет их признать и исправить в будущем, не потеряв при этом лица. Вопрос лежит большей частью в плоскости политики, а не программирования, и это печально, так как политка находится вне профессионального поля пользователей Линукс.

5. Унификация дистрибутивов. Разнообразие всегда было, на мой взгляд, сильной стороной Линукс как явления. Опасность безальтернативного внедрения systemd очевидна: любая серьёзная ошибка в таком большом проекте — заметьте, к тому же довольно юном! — может привести к глобальным проблемам на всех серверах под управлением GNU/Linux. Разнообразие и взаимозаменяемость компонентов нужны как воздух, если, конечно, вы планируете хоть сколько-нибудь дальше предстоящего обеда и партейки в LoL вечером. Именно по этой причине нельзя, выражаясь в терминах ЛОРа, закапывать *BSD. Это наш запасной паровоз на случай перебоев с подачей электричества. По этой же причине нельзя «прибивать гвоздями» ядро к systemd. Но не стоит путать унификацию и стандартизацию. Это разные вещи. Расширяемый стандарт на API системы инициализации и референсная реализация этого API может положить конец всем срачам, но systemd не подходит на эту роль по нескольким причинам, одна из которых — фактическая завязанность всей разработки на одну коммерческую компанию.

В любом случае, я предпочитаю прагматизм, и мне нужны не «шашечки», и не «ехать», а решить конкретную задачу, при чём так, чтобы поддержка решения не требовала потом значитльного количества времени и усилий. С SysV Init это получает с большим трудом. С systemd тоже. Так что проблема не в «Лёне» и не в «ретроградах», а в тех, кто бросается из крайности в крайность, усложняя тем самым жизнь и себе, и окружающим.

Спасибо за внимание.

Не удивительно. Резко негативное и отрицательное отношение к чему-либо свойственно меньшинствам.

Логи не нужны. Вообще не нужны на десктопе!

Спасибо за внимание.

Intelfx не стесняйся, залогинься.

А когда десктоп сломается?)

Резко негативное и отрицательное отношение к чему-либо свойственно меньшинствам.

Моё резко негативное и отрицательное отношение к гомосексуализму тоже очень плохо и такие как я уже в меньшинстве?

Замечательный шаг, Calculate Linux!

Будешь разбирать логи и отслеживать по ним статистику? Ты серьёзно?

systemd-хейтерство это ИСКЛЮЧИТЕЛЬНО фанатизм

википедия говорит - «Фанатизм как эмоциональное проявление характеризуется чрезмерным рвением, энтузиазмом, одержимостью, слепой верой в правоту своих (чаще всего, экстремальных религиозных или политических) убеждений, в превосходство и исключительность предмета своего обожания и его последователей в «собственном лице».»

и что я вижу? те, кто решили в силу каих-либо причин не использовать системд - ИСКЛЮЧИТЕЛЬНО фанатики. хотя они и обозначили неприемлемость этого поделия исключительно для них. но поттерингонутые всё не унимаются...

Логическая ошибка. «Свойственно меньшинствам» не тождественно «свойственно только меньшинствам». Тем более в твоём случае это природная реакция.

Хейтеров понабежало с обоих сторон... Впрочем, ничего удивительного.

Мне systemd как система инициализации нравится. Даже очень. Юниты, зависимости, контроль выполнения, диагностика - все замечательно, без сарказма. На init возвращаться особо не хочется. Upstart мне с самого начала напоминал костыль. Сейчас живу на Jessie, (пересел с Арча когда еще Wheezy был в глубоком тестинге), катастрофических проблем с systemd не испытывал. Хотя WTF-моменты иногда случаются. Как вам например такой баг: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756144 При перезапуске journald падает dhcp-клиент и без перезапуска демона подняться не может, потому что не может подсосаться к сокету journald из-за особенностей этого самого journald. Баг закрыли отключением перезапуска journald по умолчанию. Это как-то... странно.

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

Logind иногда теряет представление о пользовательских сессиях, из-за чего отваливаются привелегии. (Вообще вся эта канитель с механизмами повышения привилегий, начиная еще с consolekit, мне кажется возней не в том направлении. Вот уж тут связка из демона с сокетом и нужными допусками, классических юниксовых групп и простого пользовательского интерфейса была бы простейшим элегантным решением. Но в GNOME решили иначе, им потребовался монстр).

Я надеюсь что период юношеского максимализма у Поттеринга все-таки пройдет, и когда-нибудь systemd все-таки сделают модульным до такой степени, чтобы после грамотной работы составителей дистров можно было сделать sudo apt-get purge systemd-journald и не поломать при этом систему.

Ну или хейтеры systemd успокоются и начнут пилить полезные вещи. Идея uselessd, кстати, весьма интересна. Жаль что пока криков больше чем пользы. Вместо Devuan и скандалов-интриг-расследований лучше бы впилили uselessd в сам Debian и обработали хорошенько напильником.

В Linux-среде сейчас крайне не хватает простых десктопных утилит с полным в рамках своей задачи функционалом.

Переключение раскладокх: если отбросить все прибитое гвоздями к DE или нещадно глючащее, остается gxkb, который просто замечателен, но раскладки и свойства xkb через него не настроить. А отдельностоящей утилиты для такой задачи нет.

Переключение мониторов: опять же если отбросить все прибитое гвоздями к DE или нещадно глючащее, остается lxrandr и arandr, которые опять-таки замечательны, но сохранения профилей и демона для обработки hotplug в них нет. А сохранение статической конфигурации мониторов через скрипт в xdg-autostart - это пистолет, направленный себе в ногу.

Управление пользовательскими/системными наборами .desktop файлов в каталоге приложений и автозапуске, + файловые ассоциации: вот тут бы пригодился хороший логичный инструмент «для всего», благо спецификации FreeDesktop в этом плане складываются в великолепный и очень логичный сверху до низу механизм (особенно с новыми версиями спецификаций, которые сейчас в разработке). В этой категории задач нет ничего, только обрывки там да сям.

Не-а, это не я. И вообще, пункты 2-4 там некорректны.

И тебе Спасибо

надо ж, адекватный анонимус

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

Можешь пояснить, что конкретно здесь имеется в виду?

<вброс>Серьезный энтерпрайз не готов ломать обратную совместимость для перехода на systemd, очевидно же</вброс>

man qlop

Пакет app-portage/portage-utils

Можешь пояснить, что конкретно здесь имеется в виду?

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

Проблема ровно в одном - если это набор маленьких программ, почему нельзя было их написать так, чтобы они могли работать отдельно и главное прозрачно? Если-же это комбайн (коим он по сути и является), то уровень допиленности должен быть качественно иным.

Да хз, субъективно одно и тоже, я даже не сразу осознал, что у меня теперь в системе новая система инициализации (а вот сон моему ноуту на первых порах поломали-таки, прадва потом починили, но осадочек остался.)

<объективная_реальность>Серьёзный бизнес себя очень хорошо чувствует на systemd.</объективная_реальность>
man платные дороги в России

А, ну распилы-откаты - это да, тут я бессилен возразить. Против зашибания бабла не попрешь, можно только не работать с дерьмом(я вовсе не о systemd, я о людях) - но это не прибыльно.

Ура! Ура! Пускай эти красноголовые у себя на сервере эти системг ставят и мучаются с глюками...

Это ты вообще другую задачу решил. Совсем. И она уже решена — бинарником с правами 4750 и нужной группой.

Смысл logind+policykit в динамической раздаче привилегий (на действия и на устройства) в рантайме.

А вот на какой-нибудь embedded платке с линуксом, если туда systemd вариант дебиана ставить, то грузится он гораздо дольше, чем sysvinit

Кстати, в чём именно эта система удобна

ну ты дал! Темнота!

ща «админы системд», вчера слезшие с винды, тебе все объяснят :)

Оно загнется сразу после интеграции kdbus в ядро и перехода на него оригинального udev.

Напишут прослойку и дальше будут пользоваться eudev.

Ммм, а можно пример?

У меня вот обратный опыт. Дома микромашинка одноядерная на ARM'е, с арчом — так вот, systemd там запускает систему быстрее, чем инитскрипты.

Формат юнитов проще

ну да... «админы системд» как попки вызубрили 100 опций юнит файла и гордятся этим ;) А через полгода по новой учить, так как чудо-поцтер еще 50 опций за это время туда напихал - для «гибкости» :)

kdbus в ядро

не бывать этому - Линус покажет им свой волшебный жест!

Напишут прослойку

Прям вот так за пару дней и напишут. Kdbus пишется под использование с systemd и создать альтернативу будет не просто сложно, а очень сложно.

Ахаха! Что же там такого непредсказуемого случилося?

ох-хо-хо! «случилося» системд :)

Вот ну очень предсказуемое поведение разрабов

+++++++

systemd's readahead implementation has been removed. As none of the developers has been using rotating media anymore, and nobody stepped up to actively maintain this component of systemd it has now been removed

+++++++

А, ну распилы-откаты - это да, тут я бессилен возразить.

Давай хотя бы ты не будешь бредить. Мне, как инсайдеру, от этого и смешно и больно.

Против зашибания бабла не попрешь, можно только не работать с дерьмом(я вовсе не о systemd, я о людях) - но это не прибыльно.

Тут совсем не понял о чём ты.

Kdbus пишется под использование с systemd

Ты ещё напиши, что всё ядро пишется под использование с systemd.

Прям вот так за пару дней и напишут.

Не за пару, но за неделю под пиво.

так вот, systemd там запускает систему быстрее, чем инитскрипты.

Пруфов не будет, как обычно?

Потому что никто до сих пор не заказал Поттеринга.

А как все еще недавно начиналось, линукс будет великим. Но теперь становится понятно, что все сдохнет быстрее Винды

Тут совсем не понял о чём ты.

О твоей фразе про бизнес. Миграция с старых дистрибутивов на новые с systemd - то еще удовольствие.

Новые инсталляции - неплохи, тут спору нет.

Сей очкареГ уже ничего не покажет. Профукал он момент. Системд уже не в зародыше.

вроде позиционируют свой дистрибутив как серьёзное энтерпрайзное изделие, а на деле в маргиналов-протестунов играются

Два чая... девушке.

Да, разные версии systemd и udev — столь необходимое условие для нормальной работы

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

Хороший был дистрибутив.