Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 171
Не стоит тащить сюда холивары с ЛОРа (linux.org.ru)
Поддерживаю. Кроме того, на том же ЛОРе почти неделю назад была новость: «В Debian 8 «Jessie» будет оставлена возможность использования других систем инициализации вместо Systemd» (официальное интервью с Лукасом Нуссбаумом). Я считаю, что стоило бы добавить это в статью.
Поттеринг тот ещё удак, но конкретно к systemd у меня все претензии теоретические. Практическая реализация хороша, а для того, чтобы заменить systemd, надо предложить своё. Желательно, отличающееся по скорости и удобству сопровождения от sysv-init.
Мой Арч до внедрения системГ запускался быстрее, а я понимал, что при этом стартует. Сейчас не так.
А отключение автомонтирования swap на GPT (ибо не все свопы одинаково полезны) путём выпиливания библиотеки с диска — это верх конфигурируемости и простоты настройки.
А отключение автомонтирования swap на GPT (ибо не все свопы одинаково полезны) путём выпиливания библиотеки с диска — это верх конфигурируемости и простоты настройки.
Мне трудно померять скорость старта компьютера — большую часть это или груб, или запрос на пароль. В остальном, что стартует вполне понятно.
А «до systemd» это на sysv-init было? Там, где awk/grep/test килограммами?
А «до systemd» это на sysv-init было? Там, где awk/grep/test килограммами?
awk/grep/test килограммамиА для пользователей, неспособных работать на компьютере, есть ОС виндовс, например.
Дело не способностях, а в том, что awk/grep/test является процессом и запуск каждого из них занимает некоторое время, а сами скрипты в большинстве занимаются инициализацией и запуском/остановкой демонов (часто одинаковой работой) и проверкой состояния процесса, а systemd позволяет запустить процесс и сопровождать его на всех его этапах жизни. Несомненно такой подход дает ряд преимуществ перед классическими сценарными файлами (управление, cgroups, мониторинг, перезапуск, единый интерфейс к системе запуска). Недостатком же systemd как я понял является желания разработчика как можно больше покрыть требований в том числе и реализовать управление устройствами, что со стороны сообщества вызывает бурную реакцию. Честно говоря я никак не пойму, что мешает сделать отдельный компонент/библиотеку и использовать ее как расширение своей системы?
test, [ и куча других мелких утилит в большинстве шеллов встроены и не являются отдельными процессами.
Основной недостаток systemd — то что в pid=1 (который самый важный и падение которого автоматически вызывает kernel panic), засунули кучу ненужного там хлама.
Второй огромный его недостаток — попытка засунуть в systemd огромную кучу всего вроде session manager-а, с жутко привязаным к systemd dbus-интерфейсом, который просто невозможно нормаль реализовать другим способом.
Основной недостаток systemd — то что в pid=1 (который самый важный и падение которого автоматически вызывает kernel panic), засунули кучу ненужного там хлама.
Второй огромный его недостаток — попытка засунуть в systemd огромную кучу всего вроде session manager-а, с жутко привязаным к systemd dbus-интерфейсом, который просто невозможно нормаль реализовать другим способом.
Основной недостаток systemd — то что в pid=1 (который самый важный и падение которого автоматически вызывает kernel panic), засунули кучу ненужного там хлама.А поподробнее можно? А то опять получится, что systemd — это жуть и качмар, потому что он всё делает ровно так, как это сделано в UNIX'е.
Да, pid=1 (который самый важный и падение которого автоматически вызывает kernel panic) создаёт процессы и увправляет ими — ну так он всегда этим занимался. Криво, плохо, но занимался. Или вы уже забыли про уровни выполнения и inittab?
То, что systemd отказался от костылей в виде мешанины плохо описанных и тяжело управляемых shell-скриптов — ну так это можно только приветствовать: это, в каком-то смысле, «возвращение к истокам», ко временам когда демоны запускались init'ов и останавливались (в случае чего) им же без каких-либо посредников.
Второй огромный его недостаток — попытка засунуть в systemd огромную кучу всего вроде session manager-а, с жутко привязаным к systemd dbus-интерфейсом, который просто невозможно нормаль реализовать другим способом.Ну почему невозможно? Берёте исходники и fork'аете. Опять-таки: всё ровно так, как делалось в UNIX'ах начиная с самого начала.
А поподробнее можно? А то опять получится, что systemd — это жуть и качмар, потому что он всё делает ровно так, как это сделано в UNIX'е.
% ls -la /lib/sysvinit/init /lib/systemd/systemd -rwxr-xr-x 1 root root 1309064 Sep 28 22:33 /lib/systemd/systemd -rwxr-xr-x 1 root root 40648 Oct 26 19:52 /lib/sysvinit/init
Да, pid=1 (который самый важный и падение которого автоматически вызывает kernel panic) создаёт процессы и увправляет ими — ну так он всегда этим занимался. Криво, плохо, но занимался. Или вы уже забыли про уровни выполнения и inittab?
В pid=1 никогда не было вычисления зависимостей, socket-активации, dbus интерфейса, монтирования файловых систем, управления cgroup, замены крона и еще кучи хлама.
Я не говорю, что что-либо из этого не нужно. Я говорю, что этому явно место не в pid=1.
Ну почему невозможно? Берёте исходники и fork'аете. Опять-таки: всё ровно так, как делалось в UNIX'ах начиная с самого начала.
Я могу с таким же успехом сказать, что WinAPI — прекрасный кроссплатформенный API для приложений. Есть же libwine.
В pid=1 никогда не было вычисления зависимостей, socket-активации, dbus интерфейса, монтирования файловых систем, управления cgroup, замены крона и еще кучи хлама.А почему, собственно? Потому что его там не было 40 лет назад? Зачем выносить какую-то функциональность из pid=1 если без этой функциональности система всё равно жить не сможет?
Я не говорю, что что-либо из этого не нужно. Я говорю, что этому явно место не в pid=1.
Общий приницип: всё нужно делать настолько просто, насколько это возможно — но не проще. Так вот SysVInit — это как раз решение, которое «проще, чем это возможно». Из-за чего одни проблемы. Огромное количество приключений с SysVInit'ом происходит из-за того, что он пытается делегировать кому-то вещи, которые делегировать, в общем-то, не получается. Из-за того, что в pid=1 нет вычисления зависимостей сервисы частенько стартуют (или, что ещё хуже — останавливаются) не в том порядке. Из-за того, что pid=1 не монтирует файловые системы невозможно заставить сервис стартовать после того, как данные становятся доступными и т.д. и т.п.
Всё это позорище кое-как работало в 70е годы, когда железо «на ходу» никто не менял. Сейчас — оно глючит неимоверно (недаром ни один современный UNIX не использует SysVInit).
Я могу с таким же успехом сказать, что WinAPI — прекрасный кроссплатформенный API для приложений. Есть же libwine.К огромному сожалению libwine — это нифига не референсная реализация. Это попытка создать копию на основе обратной разработки. А этот подход работает нормально только тогда, когда оригинал по той или иной причине умер (см. FreeDOS). WinAPI же используется в системе, которая вполне себе жива и которая отнюдь не использует libwine.
А почему, собственно? Потому что его там не было 40 лет назад? Зачем выносить какую-то функциональность из pid=1 если без этой функциональности система всё равно жить не сможет?
1. Сможет, в том то и дело. Система вполне может жить вовсе без dbus, socket-активации, управления cgroup, cron'а и тп. Собственно два из трех моих PC без этого замечательно живут. И даже без монтирования FS, потому что root монтируется ядром.
2. Вероятность падения программ пропорциональна их сложности. Соответственно, вероятность kernel panic из-за смерти процесса с pid=1 пропорциональна вероятности падения этого самого процесса pid=1, и, следовательно, его сложности. Так зачем усугублять? Единственный аргумент за монолитный инит — скорость из-за отсуствия обмена данными. Но что-то мне не верится в его состоятельность.
Из-за того, что в pid=1 нет вычисления зависимостей сервисы частенько стартуют (или, что ещё хуже — останавливаются) не в том порядке
Нет, не в том порядке сервисы стартуют не из-за того что в pid=1 нет вычисления зависимостей. А в том что зависимости между сервисами неправильно указаны. Т.е. неверные исходные данные.
К огромному сожалению libwine — это нифига не референсная реализация. Это попытка создать копию на основе обратной разработки
Создать аналог systemd session manager-а как раз не получается из-за этого же. Он в качестве API наружу выставляет внутренние сущности systemd.
А у меня до внедрения systemd Arch стартовал явно медленнее.
В целом, я согласен с amarao, systemd хоть и не идеален вообще (например, есть systemd-nspawn, который управляет LXC-контейнерами. Прикольно, но как-то это не в составе init должно быть), но как init он просто конфетка: удобное управление демонами, удобное управление зависимостями, удобные userspace-утилиты, загружается быстрее всех (по крайней мере, у меня).
а я понимал, что при этом стартуетУберите quiet из параметров ядра, и systemd будет так же отображать, что он запускает.
В целом, я согласен с amarao, systemd хоть и не идеален вообще (например, есть systemd-nspawn, который управляет LXC-контейнерами. Прикольно, но как-то это не в составе init должно быть), но как init он просто конфетка: удобное управление демонами, удобное управление зависимостями, удобные userspace-утилиты, загружается быстрее всех (по крайней мере, у меня).
systemd-nspawn — это отдельная standalone утилита. То, что ее кладут в состав — так это потому что она многим нужна, просто чтобы было чем запускать контейнеры.
Современная тенденция такова, что хостнода зачастую выполняет роль гипервизора и менеджера конфигурации, а все приложения запускаются в контейнерах. Это удобно для деплоя, это гораздо более управляемо, это позволяет забыть про dependency hell. В solaris такой подход уже давно сущестовал и получил второе рождение с появлением SmartOS; популярность же недавно появившегося CoreOS понятна и неудивительна: все, кто обслуживает массовые парки однотипных серверов, приходили к аналогичному проприетарному решению — а тут все из коробки.
Современная тенденция такова, что хостнода зачастую выполняет роль гипервизора и менеджера конфигурации, а все приложения запускаются в контейнерах. Это удобно для деплоя, это гораздо более управляемо, это позволяет забыть про dependency hell. В solaris такой подход уже давно сущестовал и получил второе рождение с появлением SmartOS; популярность же недавно появившегося CoreOS понятна и неудивительна: все, кто обслуживает массовые парки однотипных серверов, приходили к аналогичному проприетарному решению — а тут все из коробки.
Я так и не понял как плохо формализуемый контейнер хелл позволил избавиться от депенденси хелла. Контейнер волшебным образом «абра швабра кадабра» переписывает код? Рожает нужные библиотеки? Хрен там. Сидишь, пыхтишь, чтобы сделать нужный контейнер. Эту бы энергию да в мирное русло — обеспечить еать нормальный деплой приложению )
Почему контейнер хелл плохо формализуем? Да потому что он вообще не формализуем. Хуже чем на шаред хостинге — крутиться чёрт знает что, чёрт знает как работает и абсолютно непредсказуемо поведёт себя в следующий момент. Это такой прыжок назад эволюции с заметанием мусора депенденси хелла под ковёр и улыбкой «всё чисто» )
Почему контейнер хелл плохо формализуем? Да потому что он вообще не формализуем. Хуже чем на шаред хостинге — крутиться чёрт знает что, чёрт знает как работает и абсолютно непредсказуемо поведёт себя в следующий момент. Это такой прыжок назад эволюции с заметанием мусора депенденси хелла под ковёр и улыбкой «всё чисто» )
Хватаем uselessd, systemd с выпиленными лишними частями. Openrc тоже никто не отменял. Это же не убранный gnome2 из убунты — можно что хочешь поменять.
Не могу ничего сказать про archlinux, но перевёл у себя несколько машинок Debian Jessie на systemd — все теперь стартуют в несколько раз быстрее.
По поводу отключения автомонтирования swap — а что мешает либо завести тикет в багтрекере, либо самому ручками пропатчить? Опенсоурс же.
По поводу отключения автомонтирования swap — а что мешает либо завести тикет в багтрекере, либо самому ручками пропатчить? Опенсоурс же.
На серверах, имхо, до фонаря какая там система инициализации — перезагружаются они раз в год и будет это занимать 30 секунд или 3 минуты — без разницы. У меня POST дольше проходит :)
Так что на десктопах пусть вортят что хотят — а на серверах пусть будет то, что надёжно и проверено.
Так что на десктопах пусть вортят что хотят — а на серверах пусть будет то, что надёжно и проверено.
Ок, мы переходим в близкую и знакомую мне область.
Вы считаете, что sysv-init надёжен? Я — не считаю. Миллионы тяжело отлаживаемых race-condition, которые появились после перехода на конкурентную модель запуска, трудноотлавливаемые моменты «неготовности», нарушение ожиданий между network mount, mount и скриптами pre-post для сетевых интерфейсов. Это, заметим, только старт. Если же на shutdown какая-то фигня, то её отлаживать ещё сложнее.
Собственно, я про эту проблему уже давным-давно писал, когда первый раз в голову граблями получил: habrahabr.ru/post/113482/. Было это давно, сейчас бы эту проблему я с полпинка учуял. Но грабля-то остаётся.
Так что прежде чем говорить «будет надёжно и проверено», давайте признаем, что то, что было, совсем не отвечает представлению о «надёжно».
Более хрупкой конструкции, чем sysv-init я вообще не видел. Сплошной императивный код, который описывает декларативные зависимости. Так сказать, удачи.
Вы считаете, что sysv-init надёжен? Я — не считаю. Миллионы тяжело отлаживаемых race-condition, которые появились после перехода на конкурентную модель запуска, трудноотлавливаемые моменты «неготовности», нарушение ожиданий между network mount, mount и скриптами pre-post для сетевых интерфейсов. Это, заметим, только старт. Если же на shutdown какая-то фигня, то её отлаживать ещё сложнее.
Собственно, я про эту проблему уже давным-давно писал, когда первый раз в голову граблями получил: habrahabr.ru/post/113482/. Было это давно, сейчас бы эту проблему я с полпинка учуял. Но грабля-то остаётся.
Так что прежде чем говорить «будет надёжно и проверено», давайте признаем, что то, что было, совсем не отвечает представлению о «надёжно».
Более хрупкой конструкции, чем sysv-init я вообще не видел. Сплошной императивный код, который описывает декларативные зависимости. Так сказать, удачи.
Заметьте, я не утверждал что нужно оставить именно sysvinit — есть еще openrc/upstart/etc, которые имеют некоторые плюсы systemd и не имеют его монструозности.
Тем более что конкурентный запуск демонов серверу, ИМХО, противопоказан.
Тем более что конкурентный запуск демонов серверу, ИМХО, противопоказан.
Кстати, расскажите, где там монструозность? С позиции обычного простого сисадмина. Несколько утилит, а как они там внутри слеплены — какое дело?
Отлаживать админскими силами можно только sysv-init, остальные — нет. А если нет, то где разница?
Заметим, если уж мы про абстрактные идеалы, то upstart сильно каноникалом под себя гнётся (commitment agreement и всё такое). RH в этом смысле куда более гуманная.
Отлаживать админскими силами можно только sysv-init, остальные — нет. А если нет, то где разница?
Заметим, если уж мы про абстрактные идеалы, то upstart сильно каноникалом под себя гнётся (commitment agreement и всё такое). RH в этом смысле куда более гуманная.
Среди всех этих инитов только у systemd собственно инит-файлы (юниты) — не на Тьюринг-полном языке. Это — плюс к отлаживаемости.
Это еще вопрос: если в sysvinit я могу просто посмотреть что делает инит-скрипт, то в systemd мне нужно будет лезть в его исходники, при прочих равных.
И это, дополнительно, снижает свободу действий при разработке скриптов запуска.
И это, дополнительно, снижает свободу действий при разработке скриптов запуска.
Да, это был серьёзный аргумент. Заметим, он валиден только для sysv-inint, то есть для спора systemd vs upstart он уже не действует.
Проблема с «админ может починить» состоит в том, что получившаяся конструкция очень хрупкая, а реальная квалификация для разбирательства с сложным инит-скриптом больше, чем кажется.
Де-факто, sysv-init это набор костылей, который давно перерос свои начальные размеры и предназначение. Я долго думал «зачем трогать sysv-init», однако множество примеров и неудачных наступлений на грабли меня постепенно убедили в обратном.
Основной кипиш вокруг systemd связан не с технической стороной, а с позицией Поттеринга по отношению к комьюнити.
Проблема с «админ может починить» состоит в том, что получившаяся конструкция очень хрупкая, а реальная квалификация для разбирательства с сложным инит-скриптом больше, чем кажется.
Де-факто, sysv-init это набор костылей, который давно перерос свои начальные размеры и предназначение. Я долго думал «зачем трогать sysv-init», однако множество примеров и неудачных наступлений на грабли меня постепенно убедили в обратном.
Основной кипиш вокруг systemd связан не с технической стороной, а с позицией Поттеринга по отношению к комьюнити.
Свобода действий — палка о двух концах. В убунтовских инитах сейчас полный мрак и ужас: что-то через upstart, что-то через инит-скрипты с использованием start-stop-daemon, что-то целиком написано вручную, где-то используются lsb/init-functions, где-то copy-paste аналогичного кода прямо в инит-скриптах. Это уже не свобода действий, а бардак.
Справедливости ради замечу, что и на шелле можно сделать хорошо — например, OpenRC: я мало работал с Gentoo, но что видел, — все сделано очень аккуратно. То есть, все решается кодстайлом, но в дебиане с этим всегда были проблемы — и в инит-скриптах, и в исходниках пакетов (кто разбирался в deb-src php, на этом месте тяжело вздохнет).
На примере той же убунты — мне ни разу не приходилось смотреть в исходники upstart-а. Upstart jobs просто работают. А вот ковыряться в кривых унаследованных из дебиана sysv-скриптах и ловить race conditions — приходилось неоднократно.
Еще один пример. Мне понадобилось запустить на той же убунте два инстанса mysql. В upstart и systemd я бы просто добавил поддержку инстансов простым и естественным образом, и запускал бы хоть два, хоть 102 — только конфиги по маске подкладывать. С дебиановским sysv-скриптом же… Ох. Добавить в эту кодолапшу поддержку инстансов я передумал сразу. cp mysql mysql2, и внимательно-внимательно меняем все захардкоженные значения, раза с пятого получится ничего не забыть ;)
Еще важная вещь уже для разработки — new style daemons. Все эти ритуальные заходы с форками и детачами становятся не нужны. Просто работаем себе и ругаемся в stderr — демон готов.
По качеству кода мне, кстати, на данный момент upstart нравится больше systemd. Что неудивительно ввиду возраста проектов. Но внедрение upstart с треском провалилось, а systemd активно внедряется, развивается и улучшается.
Справедливости ради замечу, что и на шелле можно сделать хорошо — например, OpenRC: я мало работал с Gentoo, но что видел, — все сделано очень аккуратно. То есть, все решается кодстайлом, но в дебиане с этим всегда были проблемы — и в инит-скриптах, и в исходниках пакетов (кто разбирался в deb-src php, на этом месте тяжело вздохнет).
На примере той же убунты — мне ни разу не приходилось смотреть в исходники upstart-а. Upstart jobs просто работают. А вот ковыряться в кривых унаследованных из дебиана sysv-скриптах и ловить race conditions — приходилось неоднократно.
Еще один пример. Мне понадобилось запустить на той же убунте два инстанса mysql. В upstart и systemd я бы просто добавил поддержку инстансов простым и естественным образом, и запускал бы хоть два, хоть 102 — только конфиги по маске подкладывать. С дебиановским sysv-скриптом же… Ох. Добавить в эту кодолапшу поддержку инстансов я передумал сразу. cp mysql mysql2, и внимательно-внимательно меняем все захардкоженные значения, раза с пятого получится ничего не забыть ;)
Еще важная вещь уже для разработки — new style daemons. Все эти ритуальные заходы с форками и детачами становятся не нужны. Просто работаем себе и ругаемся в stderr — демон готов.
По качеству кода мне, кстати, на данный момент upstart нравится больше systemd. Что неудивительно ввиду возраста проектов. Но внедрение upstart с треском провалилось, а systemd активно внедряется, развивается и улучшается.
У Upstart'а есть несколько проблем, но главное: он, вообще говоря, мёртв. Ubuntu переходит на systemd, а так как upstart был их проектом, то на этом всё, по сути, и кончается.
Мертв — не мертв, но
1. Релизы выходят с завидной регулярностью, последний — Upstart 1.13.2 — был 4 сентября. Всего за этот год выпущено 5 релизов. SysV Init такой же «мертвый» или даже мертвее, но товарищи из протестующих как раз и ратуют за то, чтобы отказаться от SystemD в пользу «мертвого» проверенного решения.
2. Ubuntu пока только планирует перейти, а по факту там еще довольно много нерешенных задач wiki.ubuntu.com/systemd#Implementation_issues Можно заметить, что по ряду пунктов ребята из Ubuntu ждут, пока изменения попадут в Debian.
3. Upstart — init-система текущей LTS, и будет поддерживаться минимум до третьего квартала 2019 года. Очень вероятно, что она будет доступна как альтернативная еще один-два LTS-цикла (вначале задепрекейтят, потом отключат). Возможно, она останется альтернативной насовсем.
4. и SystemD, и Upstart поддерживают обратную совместимость с Sys V Init, поэтому если писать привычные rc-скрипты, то проблем с переходом не будет. Справедливости ради стоит сказать, что и там, и там есть определенные моменты.
5. В целом, если вам интересен новый init-демон только как замена традиционному, но быстрее, то вам будет все равно, что использовать, что upstart, что systemd.
1. Релизы выходят с завидной регулярностью, последний — Upstart 1.13.2 — был 4 сентября. Всего за этот год выпущено 5 релизов. SysV Init такой же «мертвый» или даже мертвее, но товарищи из протестующих как раз и ратуют за то, чтобы отказаться от SystemD в пользу «мертвого» проверенного решения.
2. Ubuntu пока только планирует перейти, а по факту там еще довольно много нерешенных задач wiki.ubuntu.com/systemd#Implementation_issues Можно заметить, что по ряду пунктов ребята из Ubuntu ждут, пока изменения попадут в Debian.
3. Upstart — init-система текущей LTS, и будет поддерживаться минимум до третьего квартала 2019 года. Очень вероятно, что она будет доступна как альтернативная еще один-два LTS-цикла (вначале задепрекейтят, потом отключат). Возможно, она останется альтернативной насовсем.
4. и SystemD, и Upstart поддерживают обратную совместимость с Sys V Init, поэтому если писать привычные rc-скрипты, то проблем с переходом не будет. Справедливости ради стоит сказать, что и там, и там есть определенные моменты.
5. В целом, если вам интересен новый init-демон только как замена традиционному, но быстрее, то вам будет все равно, что использовать, что upstart, что systemd.
Есть некоторая разница между постановками вопроса «upstart/systemd на выбор» и «что угодно на выбор, верните наши любимые шелл-костыли». :)
Современный upstart достаточно хорош, чтобы в 99% случаев можно было взаимно конвертировать upstart inits и systemd service units, или генерировать оба из некоторого универсального описания. Это хороший вариант. (Насчет openrc я тут не уверен, возможно, тоже что-то реально придумать — но он вне мира gentoo вряд ли приживется).
Поддержание же совместимости с sysv сведется к тому, что во всех пакетах останутся sysv-скрипты, а и upstart, и systemd будут работать в режиме запускалки оных. Получится ровно та же тупиковая ситуация, которую сейчас имеем в убунте, заимствующей пакеты из ничего не знающего об апстарте дебиана. Такой инит нам не нужен.
Современный upstart достаточно хорош, чтобы в 99% случаев можно было взаимно конвертировать upstart inits и systemd service units, или генерировать оба из некоторого универсального описания. Это хороший вариант. (Насчет openrc я тут не уверен, возможно, тоже что-то реально придумать — но он вне мира gentoo вряд ли приживется).
Поддержание же совместимости с sysv сведется к тому, что во всех пакетах останутся sysv-скрипты, а и upstart, и systemd будут работать в режиме запускалки оных. Получится ровно та же тупиковая ситуация, которую сейчас имеем в убунте, заимствующей пакеты из ничего не знающего об апстарте дебиана. Такой инит нам не нужен.
Как-то так!
В эту картинку в свете последжних новостей еще и консоль надо добавить…
Один из кадров этой анимации сердит ksenzov'a.
Хех, получается что systemd, с одной стороны нарушает философию Юникс (будучи «слишком большим и сложным»), а с другой стороны — выполняет свои задачи явно лучше и эффективнее, чем «простые» решения типа sysvinit. И вот перед фанатами этих ваших Линуксов встаёт дилемма: то ли признать философию Юникс неверной (неполной), то ли держаться за неё и пользоваться устаревшим неэффективным софтом. Оба пути для линуксоидов — кошмар, холивар знатный.
Давайте начнём с того, что hurd так и не взлетел, а попытка перечислить что умеет делать ядро (прикладной софт) займёт не один лист.
> Оба пути для линуксоидов — кошмар, холивар знатный.
Ерунда какая. www.opennet.ru/opennews/art.shtml?num=40622
Ерунда какая. www.opennet.ru/opennews/art.shtml?num=40622
Линус считает, что многие изначальные идеалы Unix в современном мире стоит рассматривать скорее как результат устоявшегося мировоззрения, чем как обусловленную реалиями необходимость. Традиционный подход Unix «сделать одно дело и сделать это хорошо», подразумевающий разложение выполнения сложной задачи на связанную цепочку этапов, на каждом из которых применяется простой инструмент, слабо сочетается с тем, как в реальности работают современные усложнённые системы и приложения.
Это всё понятно для любого здравомыслящего человека. Однако же ребята с boycottsystemd.org/ на полном серьёзе рассматривают написанные чуть ли не полвека назад «изначальные идеалы Unix» как истину на все времена и ничего слышать не хотят.
Нет, нужно признать, что философия UNIX устарела.
У меня противоречивые чувства по отношению к systemd: с одной стороны, идея выглядит очень правильной, т.к. sysV init, это, по сути, набор башевых костылей, и никаких переживаний про не-юниксвейность у меня нет. Но с другой стороны, вызывает опасение то, как systemd проталкивается в дистрибутивы. Очевидно, что продукт еще очень сырой, а с их азартным переписыванием всего на свете под systemd он будет оставаться сырым еще очень долго. Многие помнят как подобным образом происходил переход на pulseaudio. Похоже, некоторых история ничему не учит.
Чем быстрее и масштабнее перейдем, тем быстрее пофиксятся баги. Вспомнить тот же pulseaudio например.
Не стоит сопротивлятся прогрессу только из-за боязни что что-то сломается.
Не стоит сопротивлятся прогрессу только из-за боязни что что-то сломается.
Возьмите для примера Wayland. То что Xorg — это говно мамонта родом из 70-х, никто не спорит, а wayland уже сейчас достаточно хорош чтобы его использовали в Jolla. При этом разработчики не беснуются и не пытаются поскорее осчастливить пользователей.
эта возможность нынче, к счастью, нужна 0,01% пользователей. с распространением Wayland/mir/etc возможно просто напишут свою версию RDP, которая будет удобнее и быстрее чем вариации на тему внц и Xserver
Но если дома у бухгалтера нашей конторы стоИт *nix с X11-совместимой графикой, я без проблем смогу пустить её на рабочее место из её дома.И как, пускали? Неторопливый бухгалтер, видимо. «Прозрачность графики на сетевом уровне» круто вроде как было придумано и неплохо звучит, но в целом при применении на практическую сферу не нужно. Есть более адекватные, подходящие, удобные для этого средства.
Это очень странно, потому что основная проблема не в том, что тормозит (хотя без сжатия, конечно, анрил всё равно даже по относительно жирному каналу), а в том, что не отзывчиво. Ну, тот же nx, который выше упоминали, гораздо, горааааздо лучше на плохих условиях. Да, понятно, что он как бы типа «делает то же самое», но при этом он лучше, чем «просто сжатие». Вообще сложно придумать какую-либо другую архитектуру подобной схемы. Кроме того, он может и поверх rdp/vnc/… использоваться. А почему VNC не нравится вам тогда уж?
Что значит «не отзывчиво»Это значит с низкой latency. Протокол синхронный же. Потому задержка обработки ввода в любом случае будет.
Как при помощи VNC организовать терминальный доступ?Ну речь была изначально просто о «доступе бухгалтером». Но всё равно не очень понятно в чём проблема организации «терминального доступа», какие требования(?) вы сюда вкладываете помимо стандартного vncserver, например? Т.к. по определению это всё и есть терминальный доступ же.
Я запускал так links -g — тормоза жутчайшие. Да, может что-то простое с минималистичным интерфейсом работает сносно, но на универсальное решение не тянет.
Чем xinetd не устраивает?
Ну так и запускайте только одну программу без рабочего стола в соответствующем .xinitrc.
Кто будет запускать сеанс?
Чем xinetd не устраивает?
Зачем пользователю рабочий стол, если нужна только одна программа?
Ну так и запускайте только одну программу без рабочего стола в соответствующем .xinitrc.
Да, через ssh. TightVNC умеет сам пробрасывать порт через ssh, так что все прозрачно.
И да, клиентов развешивают по портам. А авторизуют через vnc (vncpasswd).
И да, клиентов развешивают по портам. А авторизуют через vnc (vncpasswd).
Посмотрите на xrdp. Правда, не знаю, как там с seamless-режимом. Но из плюсов — работает со стандартным виндовым RDP-клиентом.
В родном RDP есть seamless-режим. Я имел ввиду, что не знаю, реализовали ли его поддержку в xrdp. Если вы говорите, что там этого режима нет — значит, не реализовали.
Немного не понимаю, зачем Citrix. Вернее, в случаях многих сотен терминальных серверов Citrix удобен и полезен — там кластеры есть и фишки, с этим связанные. А на одном-двух-пяти терминальных серверах отлично работает голый Windows Server, включая seamless applications.
Немного не понимаю, зачем Citrix. Вернее, в случаях многих сотен терминальных серверов Citrix удобен и полезен — там кластеры есть и фишки, с этим связанные. А на одном-двух-пяти терминальных серверах отлично работает голый Windows Server, включая seamless applications.
Seamless applications (они же опубликованные приложения) поддерживаются, начиная с win server 2003 и rdp 5.1. Вот, например, статья в Knowledge Base Nomachine на эту тему от 2004 года. Прямые ссылки на MS лень искать. Правда, в 5.1 были еще какие-то вопросы на эту тему (уже не помню подробностей, давно дело было), а полная поддержка появилась в 6.0.
Так же — просто для справки: в Windows XP была 5.1, версия 6.0 (в которой seamless applictions уже полноценно заработали) появилась в Vista, с версии 6.1 появилась, помимо всего прочего, универсальная подсистема печати, позволяющая не ставить драйвера локальных принтеров на сервер, в версии 7.0 появилось двунаправленное аудио (на терминалах можно использовать микрофон), а в 7.1 — поддержка RemoteFX. Более подробно можно почитать на wiki, при желании, но за последние 15 лет RDP проделал впечатляющую эволюцию и стал полноценным самостоятельным сервисом, который можно использовать без дополнительных примочек сверху.
Хотя стоит денег, да, тут я соглашусь.
Так же — просто для справки: в Windows XP была 5.1, версия 6.0 (в которой seamless applictions уже полноценно заработали) появилась в Vista, с версии 6.1 появилась, помимо всего прочего, универсальная подсистема печати, позволяющая не ставить драйвера локальных принтеров на сервер, в версии 7.0 появилось двунаправленное аудио (на терминалах можно использовать микрофон), а в 7.1 — поддержка RemoteFX. Более подробно можно почитать на wiki, при желании, но за последние 15 лет RDP проделал впечатляющую эволюцию и стал полноценным самостоятельным сервисом, который можно использовать без дополнительных примочек сверху.
Хотя стоит денег, да, тут я соглашусь.
А с Wayland это не получится.
Не получится с голым Wayland и на данный момент.
Вы таки меня убедили, что X forwarding может быть полезным (хотя я до сих пор не верю в то, что он может быть не тормозящим). Так что я поискал: считается, что аналогичная функциональность в Wayland возможна, просто не должна быть встроена. Например проект xpra.org собирается добавить поддержку Wayland. На данный момент такой поддержки нет, но нет и самого Wayland по умолчанию в дистрибутивах.
Знаете, когда десктопное окружение начинает завязываться на систему инициализации — это нехорошо и глупо. А именно это сейчас происходит.
Такое заманчивое предложение, что они не смогли отказаться.
Т.е. в какой-то момент Гном перестанет работать где-либо кроме Линукса.
Поэтому очень многие так ополчились на systemd — он как паразит, слишком быстро распространяется по «организму» и пытается заставить его от себя зависеть в некотором роде.
Так что хотелось бы всё же иметь выбор.
In the interest of enhancing the interoperability between systemd and the GNOME desktop environment, systemd coauthor Lennart Poettering asked the GNOME Project to consider making systemd an external dependency of GNOME 3.2.
Т.е. в какой-то момент Гном перестанет работать где-либо кроме Линукса.
Поэтому очень многие так ополчились на systemd — он как паразит, слишком быстро распространяется по «организму» и пытается заставить его от себя зависеть в некотором роде.
Так что хотелось бы всё же иметь выбор.
Отписался выше о том, что выбор обещают оставить.
Вы, видимо, читали только заголовок новости. Процитирую специально для вас:
Пакет systemd-shim будет доступен далее и будет поддерживаться в Debian Jessie. По умолчанию же по-прежнему будет устанавливаться Systemd.
systemd-shim — «заглушка», предоставляющая dbus-интерфейс Systemd для служб, нуждающихся в нем (таких, как logind, timedated и др.), без необходимости запуска Systemd в качестве системы инициализации (т.е. как init можно по-прежнему использовать sysvinit или любую другую систему). однако, этот пакет предоставляет только dbus-интерфейс org.freedesktop.systemd1.service, для остальных (org.freedesktop.hostname1.service, org.freedesktop.locale1.service, eorg.freedesktop.login1.service и других) все же потребуется установка пакета systemd и использование соответствующих утилит (например, новые версии LightDM не работают без logind, GNOME требует наличия многих служб Systemd).
> Не все разделяют его радикальные идеи по модернизации ядра.
К счастью, от него тут мало что зависит, а Линус пока ещё в своём уме. Да и вообще, что конкретно имеется в виду?
К счастью, от него тут мало что зависит, а Линус пока ещё в своём уме. Да и вообще, что конкретно имеется в виду?
Решил перевести.http://boycottsystemd.org/
1. systemd нарушает философию Unix «Делать одну вещь и при этом хорошо», представляя просто сложный набор малосвязных бинарников. Его зона ответственности давно уже выросла за рамки системы инициализации, и начинает распространяться на управление питанием, устройствами, точками монтирования, cron-ом, шифровнием диска, API сокетов, журналами (syslog), конфигурацией сети, управлением сессиям, предчтение(readahead), определение разделов, регистрация контейнеров [виртуализация], управление именем хоста-временем-локалью, mDNS/DNS-SD, консоли Linux и прочие штуки — все в одном. На повестке дня — дальнейшее расширение systemd и его внедрение в среду GNU/Linux было выяснено во время «2014 GNOME Asia talk». Дайте нам KISS.
2. Журналы systemd (для journald) сохраняются в очень сложном бинарном формате, и могут быть запрошены только journalctl. Это делает журналы потенциально повреждаемыми, и они не имеют ACID-совместимых транзакций. Вы бы не хотели чтобы с системными журналами что-то произошло. Совет от systemd разрабов? Забейте. Единственный путь создать традиционные логи это запустить syslogd как rsyslog вместе с journald. Так же там есть встроенный HTTP сервер. QR коды тоже можно отдавать через него, с помощью libqrencode.
3. Так как systemd очень завязан на API ядра Linux, разные версии systemd несовместимы с разными ядрами и портируемость бессмысленно снижена в разных компонентах. Это политика изолирования [systemd], которая конечно же вгоняет экосистему Linux в свою собственную клетку, работая как препятствие в разработке портируемого ПО как с Linux, так и Unix-деривативами. так же это пораждает трудности с бекпортированием изменений в системой длительной поддержки.
4. udev и dbus становятся обязательными зависимостями. По факту, udev был влит в ветку systemd очень давно. Интеграция менеджера «device node»( который был частью Linux ядра) — это нелегкое решение. Здесь высокая политическая подоплека (имеется в виду политика разработчиков), и много пакетов зависящих от udev, стали зависимы от systemd, несмотря на форки вроде eudev. Начиная с systemd-209, разработчики ввели собственный нестандартный и малодокументированный sd-bus API который замещает некоторые задачи libdbus. Далее, они решили перенести udev на этот новый транспорт, заменили Netlink и сделали udev наглухо привязанным к systemd демоном. Эффект, конечно, значителен.
5. systemd представляет хелпер который снимает coredump-ы (дампы ядра) и перенаправляет их либо в /var/lib/systemd/coredump либо в journal, где они должны быть запрошены через coredumpctl. Последнее, причем — было поведением по умолчанию и его похоже вернут. Это означает что пользователей и админов держат за идиотов, но более важно, в основе своей склонная к повреждениям природа логов journald превращает это в серьезную помеху и безответственный выбор при дизайне системы. Также это может создать усложнения в многопользовательских средах в плане привелегий.
6. Размер systemd (видимо, в файлах и мегабайтах — прим.пер.) превращает его в большую «единственную точку отказа». На момент написания, systemd имел 9 отчетов CVE (уязвимости), с начала внедрения в марте 2010. Вроде и не много, но его всепроникающая (в плане ответственности за компоненты) и важная суть может стать лакомым кусочком для взломщиков, так как его широта поменьше чем ядро, но настолько же критично по последствиям (прим. пер. — по мне так это уже лицемерие и лукавство.)
7. systemd имеет вирусный характер, его расширения добавляют новые API, но продолжая зависеть именно от его инициализации. Его охват функциональности и расползание как зависимость по куче пакетов означает что мейнтейнеры дистрибутивов будут обязаны вынуждать переход или сносить напрочь (старое). Например, GNOME обычно использует компоненты systemd вроде logind и поддержка не-systemd систем становится сложной. Под Wayland, GNOME использует logind который снова заставляет использовать systemd. Все больше мейнтейнеров прописывают в зависимости systemd по этой причине. Быстрый рост в принятии в такие дистрибутивы, как Debian, Arch Linux, Ubuntu, Fedora, openSUSE показывает, что многие пытаются запрыгнуть в уходящий поезд, иногда бездумно (может тут не точно перевел). Например, странно что от него зависят Weston compositor, Polkit, upower, udisks2, PackageKit, и тп. Так же ничего особо не дает то, что systemd не хочет запускаться под пользователем.
8. systemd запускает (clusters — теснится, толпится — прим. пер.) себя под PID 1, вместо того чтоб работать как отдельный гипервизор процессов. Так как он контролирует кучу компонентов, существует тьма вариантов в которых он может помереть (закрашиться) и отправить в небытие всю систему (см. выше про точку отказа). Мы так же отмечаем что чтобы снизить надобности перезагрузки, systemd предоставляет механизм для перезапуска systemctl в реальном времени. Но если с ним чего не так, то система опять идет крахом. Так же есть разные пути, как это может произойти, включая невозможность прочитать предыдущее несовместимое состояние. Это, похоже, другой пример SPOF (одна точка отказа) и ненужном бремени в и так уже критичном комноненте (init).
9. systemd разработан с glibc-в-уме, и не особо поддерживает другие libc-ы. В общем, идея разрабов systemd в стандартной libc библиотеке — та, что баг-в-баг повторит glibc.
10. Сложная «душевная» организация systemd (метафора пер.) делает очень сложной расширение за пределами его собственных рамок (среды) разработки. В то время как запустить шел скрипт из файлов модулей как-то можно, весьма сложно написать реализацию поведения, которая идет из коробки, с учетом всех этих крутых фич. Много пользователей чаще хотят написать сложные программы, которые прямо взаимодействуют с API systemd, или даже модифицировать (его исходники). Кто-то может побеспокоиться о большом количестве путей в коде в критичной для системы программе, включая возможность того что systemd не синхронизируется с шиной сообщений при загрузке и зависнет. Это противоположно традиционному иниту, который определяем и предсказуем по архитектуре.
11. В конечном счете, распространение systemd символично чуть больше чем просто systemd. Оно показывает радикальный сдвиг в мышлении сообщества Linux. И не обязательно позитивном. Это сдвиг по большей части оринтирован на десктоп, ограничивает выбор, изоляционистский, велосипедостройный и просто огромно-антипаттерный. Если ваша задача потворствовать наименьшему делителю, делайте это. Но мы посмотрим в какую-то другую сторону.
12. systemd вообще похоже не знает что за хренью он хочет быть. Он иногда описан как «system daemon» или как «базовый блок в пространстве пользователя чтобы сделать ОС», оба термина слишком неоднозначны. Он поглощает функциональность которая пренадлежала util-linux, беспроводным инструментам (wireless tools), syslog и прочим проектам. У него нет четкого направления, кроме как причуды самих же разработчиков. Что забавно, несмотря на цели по стандартизации дистрибутивов Linux, у него нет четкого стандарта и он по сути просто катится, как перекати-поле.
1. systemd нарушает философию Unix «Делать одну вещь и при этом хорошо», представляя просто сложный набор малосвязных бинарников. Его зона ответственности давно уже выросла за рамки системы инициализации, и начинает распространяться на управление питанием, устройствами, точками монтирования, cron-ом, шифровнием диска, API сокетов, журналами (syslog), конфигурацией сети, управлением сессиям, предчтение(readahead), определение разделов, регистрация контейнеров [виртуализация], управление именем хоста-временем-локалью, mDNS/DNS-SD, консоли Linux и прочие штуки — все в одном. На повестке дня — дальнейшее расширение systemd и его внедрение в среду GNU/Linux было выяснено во время «2014 GNOME Asia talk». Дайте нам KISS.
2. Журналы systemd (для journald) сохраняются в очень сложном бинарном формате, и могут быть запрошены только journalctl. Это делает журналы потенциально повреждаемыми, и они не имеют ACID-совместимых транзакций. Вы бы не хотели чтобы с системными журналами что-то произошло. Совет от systemd разрабов? Забейте. Единственный путь создать традиционные логи это запустить syslogd как rsyslog вместе с journald. Так же там есть встроенный HTTP сервер. QR коды тоже можно отдавать через него, с помощью libqrencode.
3. Так как systemd очень завязан на API ядра Linux, разные версии systemd несовместимы с разными ядрами и портируемость бессмысленно снижена в разных компонентах. Это политика изолирования [systemd], которая конечно же вгоняет экосистему Linux в свою собственную клетку, работая как препятствие в разработке портируемого ПО как с Linux, так и Unix-деривативами. так же это пораждает трудности с бекпортированием изменений в системой длительной поддержки.
4. udev и dbus становятся обязательными зависимостями. По факту, udev был влит в ветку systemd очень давно. Интеграция менеджера «device node»( который был частью Linux ядра) — это нелегкое решение. Здесь высокая политическая подоплека (имеется в виду политика разработчиков), и много пакетов зависящих от udev, стали зависимы от systemd, несмотря на форки вроде eudev. Начиная с systemd-209, разработчики ввели собственный нестандартный и малодокументированный sd-bus API который замещает некоторые задачи libdbus. Далее, они решили перенести udev на этот новый транспорт, заменили Netlink и сделали udev наглухо привязанным к systemd демоном. Эффект, конечно, значителен.
5. systemd представляет хелпер который снимает coredump-ы (дампы ядра) и перенаправляет их либо в /var/lib/systemd/coredump либо в journal, где они должны быть запрошены через coredumpctl. Последнее, причем — было поведением по умолчанию и его похоже вернут. Это означает что пользователей и админов держат за идиотов, но более важно, в основе своей склонная к повреждениям природа логов journald превращает это в серьезную помеху и безответственный выбор при дизайне системы. Также это может создать усложнения в многопользовательских средах в плане привелегий.
6. Размер systemd (видимо, в файлах и мегабайтах — прим.пер.) превращает его в большую «единственную точку отказа». На момент написания, systemd имел 9 отчетов CVE (уязвимости), с начала внедрения в марте 2010. Вроде и не много, но его всепроникающая (в плане ответственности за компоненты) и важная суть может стать лакомым кусочком для взломщиков, так как его широта поменьше чем ядро, но настолько же критично по последствиям (прим. пер. — по мне так это уже лицемерие и лукавство.)
7. systemd имеет вирусный характер, его расширения добавляют новые API, но продолжая зависеть именно от его инициализации. Его охват функциональности и расползание как зависимость по куче пакетов означает что мейнтейнеры дистрибутивов будут обязаны вынуждать переход или сносить напрочь (старое). Например, GNOME обычно использует компоненты systemd вроде logind и поддержка не-systemd систем становится сложной. Под Wayland, GNOME использует logind который снова заставляет использовать systemd. Все больше мейнтейнеров прописывают в зависимости systemd по этой причине. Быстрый рост в принятии в такие дистрибутивы, как Debian, Arch Linux, Ubuntu, Fedora, openSUSE показывает, что многие пытаются запрыгнуть в уходящий поезд, иногда бездумно (может тут не точно перевел). Например, странно что от него зависят Weston compositor, Polkit, upower, udisks2, PackageKit, и тп. Так же ничего особо не дает то, что systemd не хочет запускаться под пользователем.
8. systemd запускает (clusters — теснится, толпится — прим. пер.) себя под PID 1, вместо того чтоб работать как отдельный гипервизор процессов. Так как он контролирует кучу компонентов, существует тьма вариантов в которых он может помереть (закрашиться) и отправить в небытие всю систему (см. выше про точку отказа). Мы так же отмечаем что чтобы снизить надобности перезагрузки, systemd предоставляет механизм для перезапуска systemctl в реальном времени. Но если с ним чего не так, то система опять идет крахом. Так же есть разные пути, как это может произойти, включая невозможность прочитать предыдущее несовместимое состояние. Это, похоже, другой пример SPOF (одна точка отказа) и ненужном бремени в и так уже критичном комноненте (init).
9. systemd разработан с glibc-в-уме, и не особо поддерживает другие libc-ы. В общем, идея разрабов systemd в стандартной libc библиотеке — та, что баг-в-баг повторит glibc.
10. Сложная «душевная» организация systemd (метафора пер.) делает очень сложной расширение за пределами его собственных рамок (среды) разработки. В то время как запустить шел скрипт из файлов модулей как-то можно, весьма сложно написать реализацию поведения, которая идет из коробки, с учетом всех этих крутых фич. Много пользователей чаще хотят написать сложные программы, которые прямо взаимодействуют с API systemd, или даже модифицировать (его исходники). Кто-то может побеспокоиться о большом количестве путей в коде в критичной для системы программе, включая возможность того что systemd не синхронизируется с шиной сообщений при загрузке и зависнет. Это противоположно традиционному иниту, который определяем и предсказуем по архитектуре.
11. В конечном счете, распространение systemd символично чуть больше чем просто systemd. Оно показывает радикальный сдвиг в мышлении сообщества Linux. И не обязательно позитивном. Это сдвиг по большей части оринтирован на десктоп, ограничивает выбор, изоляционистский, велосипедостройный и просто огромно-антипаттерный. Если ваша задача потворствовать наименьшему делителю, делайте это. Но мы посмотрим в какую-то другую сторону.
12. systemd вообще похоже не знает что за хренью он хочет быть. Он иногда описан как «system daemon» или как «базовый блок в пространстве пользователя чтобы сделать ОС», оба термина слишком неоднозначны. Он поглощает функциональность которая пренадлежала util-linux, беспроводным инструментам (wireless tools), syslog и прочим проектам. У него нет четкого направления, кроме как причуды самих же разработчиков. Что забавно, несмотря на цели по стандартизации дистрибутивов Linux, у него нет четкого стандарта и он по сути просто катится, как перекати-поле.
Лучше бы оформили в виде поста.
не ожидал, что кто-то оценит. Делал на коленке за 10-15 минут, много отсебятины и вообще, мне кажется не очень тянет на пост… но да. «то неловкое чувство когда комментарий больше поста»
Ну, можете еще дополнить переводом debianfork.org и письма Яна Джексона для полноты картины :)
Учту на будущее, а сейчас я думаю люди которые следят за темой уже прочитали если не мой перевод то оригинал минимум, и лепить отдельный пост уже поздновато. Да и потом, debianfork.org мне переводить совсем не хочется, я не согласен с мыслями которые там высказаны.
Спасибо всем оценившим в зеленый цвет, мне и правда была неожиданна и приятна такая сильная оценка.
Спасибо всем оценившим в зеленый цвет, мне и правда была неожиданна и приятна такая сильная оценка.
Администраторам парка в полтора сервера действительно может быть непонятно, зачем это все.
Посмотрите на CoreOS — это первый linux-дистрибутив, подходящий для управления парком серверов. Без systemd такое сделать было бы намного сложнее. Причем, ничего такого нового в systemd нет: это все уже было в SMF, в launchctl и даже в upstart; но у systemd есть шанс стать стандартом, а не запускать legacy sysv init junk, как в убунте. Да, у него много недостатков, но жить как в 94-м году с sysv init уже давно нельзя.
Посмотрите на CoreOS — это первый linux-дистрибутив, подходящий для управления парком серверов. Без systemd такое сделать было бы намного сложнее. Причем, ничего такого нового в systemd нет: это все уже было в SMF, в launchctl и даже в upstart; но у systemd есть шанс стать стандартом, а не запускать legacy sysv init junk, как в убунте. Да, у него много недостатков, но жить как в 94-м году с sysv init уже давно нельзя.
О, прибежали минусаторы с лора. :)
Задумайтесь: вы минусуете сами себя. От злости и понимания своей судьбинушки.
99% из того, что вы называете недостатками systemd — это то, что вы просто не знаете как сделать. Это от того, что вы уже неспособны изучить что-то новое, закостенели в своем развитии и не способны воспринять новую информацию. А неотвратимое уже наступление systemd по всем фронтам чувствуете угрозой своему рабочему месту. Да, через тройку лет всех клепателей костылей на шелле и перле сменят более эффективные сотрудники, которые умеют в автоматизацию. Первым заходом, когда появились puppet, chef и подобные им системы управления конфигурацией, смело 50% пердунов, вторым заходом через systemd и всеобщий переход на облака смоет и остальных: apt-get install станет не нужен, а больше вы ничего не умеете.
Задумайтесь: вы минусуете сами себя. От злости и понимания своей судьбинушки.
99% из того, что вы называете недостатками systemd — это то, что вы просто не знаете как сделать. Это от того, что вы уже неспособны изучить что-то новое, закостенели в своем развитии и не способны воспринять новую информацию. А неотвратимое уже наступление systemd по всем фронтам чувствуете угрозой своему рабочему месту. Да, через тройку лет всех клепателей костылей на шелле и перле сменят более эффективные сотрудники, которые умеют в автоматизацию. Первым заходом, когда появились puppet, chef и подобные им системы управления конфигурацией, смело 50% пердунов, вторым заходом через systemd и всеобщий переход на облака смоет и остальных: apt-get install станет не нужен, а больше вы ничего не умеете.
Помню как-то коллегу с другого отдела(не админы) спросил почему у них не супер модный puppet стоит, а какая-то легковесная приблуда. На что он мне сказал что они не хотят тратить все свободное время для того что бы учить «how to puppet» для администрирования 10 серверов :)
10 серверов — это ни о чем, такой парк можно администрировать даже собирая ебилды на продакшене =)
Любители одной кнопочки «сделать мне инфраструктуру» могут присоединяться к стройной колонне любителей кнопочки «сделать мне пиз… хорошо»… Вы такие смешные и беспомощные, когда у Вас заклинивает Вашу кнопочку, и приходится отстегивать баблос за работу таким как мы. Которые могут, как на ансибле с паппетом, так и на баше с авком.
Это вы тут к кому-то не тому обращаетесь :) Я такие кнопочки делал, когда еще паппета в проекте не было. Чем не горжусь — можно было бы знать про cfengine.
Смотрите. Вот есть люди, которые делают инфраструктуру, и люди, которые читают документацию в вики нажимают на кнопочки — просто если нас с вами посадить нажимать кнопочки, мы взвоем от скуки. Первые, при всех их знаниях, зачастую очень любят подвыпендриться с подвывертом, и запилить что-то такое свое, нестандартное, ну потому что у всех стандартных решений есть фатальный недостаток (сам временами грешен, — но на личных проектах, конечно). И этим закладывают огромный риск (в свою пользу — создавая себе джоб секьюрити): если они по той или иной причине уходят, в наследство остается мегабайт недокументированного кода, который проще выбросить к черту, чем в нем разобраться.
Чем более стандартно решение, чем меньше NYHS-велосипедов — тем оно проще и надежнее в обслуживании, и тем взаимозаменяемее люди. А незаменимых сотрудников быть не должно. А именно systemd становится промышленным стандартом, и это главное, за это все недочеты можно простить.
И, да. Легко могу предположить, что пердуны^W Veteran Unix Admins, подписавшиеся под инфантильным манифестом из сабжа, делятся на 10b частей: на упомянутых тех, кто по причине закостенелости мышления не в состоянии освоить новое (тут, на самом деле, можно только посочувствовать), и на тех, кто осознанно занимается велосипедостроительством, обеспечивая себе джоб-секьюрити — а вот таких надо сразу в их самодеятельности пресекать, а если договориться не выходит, с сожалением расставаться — при всех их знаниях и достоинствах. Это не только с админами/девопсами так — писатель собственных фреймворков на пустом месте где-то в этой же категории находятся.
Смотрите. Вот есть люди, которые делают инфраструктуру, и люди, которые читают документацию в вики нажимают на кнопочки — просто если нас с вами посадить нажимать кнопочки, мы взвоем от скуки. Первые, при всех их знаниях, зачастую очень любят подвыпендриться с подвывертом, и запилить что-то такое свое, нестандартное, ну потому что у всех стандартных решений есть фатальный недостаток (сам временами грешен, — но на личных проектах, конечно). И этим закладывают огромный риск (в свою пользу — создавая себе джоб секьюрити): если они по той или иной причине уходят, в наследство остается мегабайт недокументированного кода, который проще выбросить к черту, чем в нем разобраться.
Чем более стандартно решение, чем меньше NYHS-велосипедов — тем оно проще и надежнее в обслуживании, и тем взаимозаменяемее люди. А незаменимых сотрудников быть не должно. А именно systemd становится промышленным стандартом, и это главное, за это все недочеты можно простить.
И, да. Легко могу предположить, что пердуны^W Veteran Unix Admins, подписавшиеся под инфантильным манифестом из сабжа, делятся на 10b частей: на упомянутых тех, кто по причине закостенелости мышления не в состоянии освоить новое (тут, на самом деле, можно только посочувствовать), и на тех, кто осознанно занимается велосипедостроительством, обеспечивая себе джоб-секьюрити — а вот таких надо сразу в их самодеятельности пресекать, а если договориться не выходит, с сожалением расставаться — при всех их знаниях и достоинствах. Это не только с админами/девопсами так — писатель собственных фреймворков на пустом месте где-то в этой же категории находятся.
Вы слишком зациклены на джоб-секьюрити, велосипедах и старых пердунах. И даже знание бинарного кода (хо-хо) не прячет в Вас манагера. Люди ратуют за «разделяй и властвуй», и в этом есть доля смысла. Сам не приверженец архаизмов, но когда мне нагло подсовывают как стандарт(подчеркиваю, стандарт, а не возможную альтернативу) громоздкую систему инициализации, то это явный повод задуматься, как это повлияет на стабильность ОС. К слову, парой постов выше описано, что же так не устраивает «пердунов»:
habrahabr.ru/post/240839/#comment_8075647
Не считаете весомыми аргументами?
habrahabr.ru/post/240839/#comment_8075647
Не считаете весомыми аргументами?
>И даже знание бинарного кода (хо-хо) не прячет в Вас манагера
Вот только что запушил в гит почти 1000 строк свеженаписанного кода. Вот такой вот уевый манагер. :)
>Не считаете весомыми аргументами?
Действительно весомый там один (4-й), все остальное — или ерунда и вкусовщина, или не проблема systemd.
Вот только что запушил в гит почти 1000 строк свеженаписанного кода. Вот такой вот уевый манагер. :)
>Не считаете весомыми аргументами?
Действительно весомый там один (4-й), все остальное — или ерунда и вкусовщина, или не проблема systemd.
Смотрите.Смотрю.
при всех их знаниях, зачастую очень любят подвыпендриться с подвывертом, и запилить что-то такое свое, нестандартное, ну потому что у всех стандартных решений есть фатальный недостаток (сам временами грешен, — но на личных проектах, конечно). И этим закладывают огромный риск (в свою пользу — создавая себе джоб секьюрити): если они по той или иной причине уходят, в наследство остается мегабайт недокументированного кода, который проще выбросить к черту, чем в нем разобраться.True story! Поразительно, но вы, даже сами того не замечая, один в один описали Подтеринга с его поделием… Аплодирую стоя! Просто — браво!
А именно systemd становится промышленным стандартом, и это главное, за это все недочеты можно простить.Вы вообще в курсе что такое стандарты и как их создают? Или вы любое недоразумение слепленное из говна и палок называете промышленным стандартом? А за любой малейший недочет, прощенный вами в любом пром. стандарте, вам бы голову с плеч сняли и правильно сделали бы.
пердуныСказал юноша 70-го года рождения…
инфантильным манифестомПочему-то вспомнил про печальный телефон… :(
не в состоянии освоить новоеПростите, но чем осваивание нового принципиально отличается от осваивания старого, если только ты не труп? И далеко не все новое стоит того, чтобы его осваивать…
Кстати, вы уже освоили новый детектив Дарьи Донцовой? А миллионы
тех, кто осознанно занимается велосипедостроительством, обеспечивая себе джоб-секьюрити — а вот таких надо сразу в их самодеятельности пресекать, а если договориться не выходит, с сожалением расставаться — при всех их знаниях и достоинствах. Это не только с админами/девопсами так — писатель собственных фреймворков на пустом месте где-то в этой же категории находятся.Нет, ну вот опять вы про него! Ну, вот за что вы так не любите Подтеринга, а?
>True story!
Верно. Отличие в том, что это один стандартный велосипед, а не 100 разных, вот и все.
>Сказал юноша 70-го года рождения…
Это unix timestamp 0. Когда-то на хабре не было этого поля, а сейчас либо null так отображается, либо добавили поле с default 0. :)
>И далеко не все новое стоит того, чтобы его осваивать
Для того, чтобы делать такие выводы, надо сначала освоить. Нет, к systemd в его нынешнем есть ворох реальных претензий, вот только претензии 99% хейтеров говорят о том, что они просто не осилили мануал.
Верно. Отличие в том, что это один стандартный велосипед, а не 100 разных, вот и все.
>Сказал юноша 70-го года рождения…
Это unix timestamp 0. Когда-то на хабре не было этого поля, а сейчас либо null так отображается, либо добавили поле с default 0. :)
>И далеко не все новое стоит того, чтобы его осваивать
Для того, чтобы делать такие выводы, надо сначала освоить. Нет, к systemd в его нынешнем есть ворох реальных претензий, вот только претензии 99% хейтеров говорят о том, что они просто не осилили мануал.
Любой мало-мальский грамотный админ, знает, что промышленный стандарт — винда. Вон ее даже в банкоматах ставят. Что ж Вы лезете со своим велосипедным, на коленке склепанным, линуксом? Старый пердун что ле?
Вот это, кстати, хороший комментарий. Несколько экспрессивный, но хороший. Я примерно тоже самое подумал пару недель назад после тестового внедрения chef.
Споткнулся о слово «бойкотирость» и подумал что какой я отсталый и не знаю такого слова… Полез в гугл и понял что все со мной ок, зато вот копи-паста процветает )
А я считаю что чисто архитектурно это если уж и не прорыв — так точно шаг вперед. Наличие «главного демона» — настолько же слабая, насколько и сильная сторона. Если сообщество не останется в стороне и будет его грамотно развивать, это может перерасти в некоторый стандарт. Главная фишка даже не столько распараллеливание взаимодействия, сколько сам факт наличия современной альтернативы косматого sysvinit. Что касается хейтеров — кроме поливания грязью ни одного реального аргумента против я не услышал. Насчет Unixßфилософии так вообще она не нарушается нисколько — если палку перегибать так вообще можно привязаться к тому что «ядро слишком важно для системы и едино и само по себе наличие ядра уже потенциальная уязвимость», во всяком случае выглядит это примерно так.
Небольшой оффтоп — вспоминается былинный холивар про иксы в общем и про X11 в частности. И ничего, все пошло своим чередом, на состояние 2014 года про это вообще забыли и все везде работает, хотя тоже когда-то бойкотировали все кому не лень.
Небольшой оффтоп — вспоминается былинный холивар про иксы в общем и про X11 в частности. И ничего, все пошло своим чередом, на состояние 2014 года про это вообще забыли и все везде работает, хотя тоже когда-то бойкотировали все кому не лень.
наличия современной альтернативы косматого sysvinitЭто не альтернатива, это принуждение.
кроме поливания грязью ни одного реального аргумента против я не услышалНу, либо вы неприкрыто и нагло лжете, либо у вас плохо со слухом и вы не слышите оппонентов…
Насчет Unixßфилософии так вообще она не нарушается нисколькоРазберитесь для начала.
вообще можно привязаться к тому что «ядро слишком важно для системы и едино и само по себе наличие ядра уже потенциальная уязвимость»Я потерял вашу нить, если я правильно распарсил этот поток сознания, то вспомните Hurd, kFreeBSD…
Где-то слышал мнение, что в коде и вообще во всей идее systemd разбираются очень мало разработчиков и всем руководит Леннард. Так что живучесть проекта может оказаться под угрозой.
>в коде и вообще во всей идее systemd разбираются очень мало разработчиков
Что считать тем, что «разбирается»? Ну пусть это будет «сделал от 20 коммитов». Смотрим:
$ git clone git://anongit.freedesktop.org/systemd/systemd
$ cd systemd
$ git shortlog -ns | awk '$1 >= 20' | wc -l
48
Хорошо, пусть 20 — это мало. Возьмем «ядро» разработчиков, от 100 коммитов — можно считать, что это люди, которые понимают проект досконально:
$ git shortlog -ns | awk '$1 >= 100' | wc -l
12
Не очень много, но уж точно не один Поттеринг.
>… и всем руководит Леннард
Да. У любого проекта есть руководитель. Разработкой ядра руководит Линус. Разработкой Python-а руководит Гвидо. Что не так?
Что считать тем, что «разбирается»? Ну пусть это будет «сделал от 20 коммитов». Смотрим:
$ git clone git://anongit.freedesktop.org/systemd/systemd
$ cd systemd
$ git shortlog -ns | awk '$1 >= 20' | wc -l
48
Хорошо, пусть 20 — это мало. Возьмем «ядро» разработчиков, от 100 коммитов — можно считать, что это люди, которые понимают проект досконально:
$ git shortlog -ns | awk '$1 >= 100' | wc -l
12
Не очень много, но уж точно не один Поттеринг.
>… и всем руководит Леннард
Да. У любого проекта есть руководитель. Разработкой ядра руководит Линус. Разработкой Python-а руководит Гвидо. Что не так?
Я вот чего не понимаю: почему он так активно вводится? Я не считаю, что разработчики Debian, Ubuntu, Fedora, openSUSE и др. дистрибутивов, где systemd уже внедрён или активно внедряется, выжили из ума. Я верю, что это компетентные специалисты и никакой Поттеринг не смог бы без веских рациональных аргументов заставить их внедрять systemd.
Есть какие-нибудь e-mail рассылки/статьи, где разработчики вышеупомянутых дистрибутивов объясняли почему они внедряют systemd? А если их нет, то прошу кого-нибудь спросить их.
Есть какие-нибудь e-mail рассылки/статьи, где разработчики вышеупомянутых дистрибутивов объясняли почему они внедряют systemd? А если их нет, то прошу кого-нибудь спросить их.
Мне не нравится systemd из-за того, что зав внедрением новых фич забывают чинить сломанное. За столько лет можно было б инициализацию virtual console починить, а то костыли типа службы, которая передергивает консоль в конце инициализации, это реально несерьезно. Очень долго искал, почему сломались русские буквы в консоли после обновления на очередной релиз. open-suse.ru/content/ne-vklyuchaetsya-sluzhba-kbd
>За столько лет можно было б инициализацию virtual console починить
Внезапно systemd-consoled: www.phoronix.com/scan.php?page=news_item&px=MTgwNzQ
Внезапно systemd-consoled: www.phoronix.com/scan.php?page=news_item&px=MTgwNzQ
Это неделю назад они вместо починки старой консоли в него еще и свою консоль впилили? Вдогонку к вебсерверу, наверное. Ну и про то, что оно «Note that this is still experimental! Instructions on how to run it will follow shortly.» не следует забывать. А мышь, картинки и прочее в консоли у меня еще 10 лет назад были. И русские шрифты и переключение раскладок тоже.
Вас не поймешь, костыли не нравятся, начали разработку нового решения для VT без костылей — тоже не нравится.
Haters gonna hate :)
Haters gonna hate :)
Мне не нравится то, что сломано что-то, работающее много лет. И необходимость костыля вызвана как раз этим. А потом вместо признания и исправления ошибки, строится свой дивный новый мир.
Посмотрел по ссылке. То, что в opensuse не совсем корректно интегрировали kbd с systemd, это уж точно не проблема самого systemd. У меня в Arch-е все хорошо.
Возьмите и сами запилите. Не знаете, куда соваться (или, что почти то же самое, много времени уйдёт, что бы вникнуть)? Тогда перечитайте топик и аргументы (Unix Way и т.п.) и подумайте, нужен ли systemd…
CJK-шрифтов нет и не предвидится без юзерспейсной консоли. Старую консоль пытались фиксить, запихав в неё юникодные шрифты (а не 256-512 избранных символов, как сейчас), но быстро отказались от этой идеи: вылезло слишком много багов.
История с systemd очень напоминает историю с PulseAudio, идея хорошая, но реализация отвратительная и только спустя 2-3 года после начала внедрений, оно стало хоть как-то юзабельное. Причем и также вирусно пульс распространялся
Моё мнение: все кому нравится такая архитектура, какую прививает systemd — обратите взор на MAC OS, Не тащите эту гадость в GNU LINUX.
Серьёзно, в OS X уже давно есть launchD который заведует вообще всем и от которого вообще всё зависит. Полностью монолитный, бинарный, не изменяемый без перекомпиляции, управляемый парой способов и не приемлющий критики launchD.
Я не воинствующий, но зачем менять логику (философию если угодно) того что работало десятилетиями? Я не говорю, что нужно застрять в 70х-80х, но полностью изменить концепцию дистрибутива! Застревать нельзя, а вот развивать имеющееся, не придумывая революций, видимо, скучновато<сарказм>.
Высокий порог вхождения в systemD тоже довод. У меня, тогда ещё молодого, не заняло много времени разобтаться в скриптах инициализации, а вот systemD, с его непрозрачностью, пугает меня до сих пор.
Серьёзно, в OS X уже давно есть launchD который заведует вообще всем и от которого вообще всё зависит. Полностью монолитный, бинарный, не изменяемый без перекомпиляции, управляемый парой способов и не приемлющий критики launchD.
Я не воинствующий, но зачем менять логику (философию если угодно) того что работало десятилетиями? Я не говорю, что нужно застрять в 70х-80х, но полностью изменить концепцию дистрибутива! Застревать нельзя, а вот развивать имеющееся, не придумывая революций, видимо, скучновато<сарказм>.
Высокий порог вхождения в systemD тоже довод. У меня, тогда ещё молодого, не заняло много времени разобтаться в скриптах инициализации, а вот systemD, с его непрозрачностью, пугает меня до сих пор.
Вы перегибаете палку, в том как писать сервисы для systemd можно разобраться за час с нуля, это не rocket science.
Да, у systemd есть проблемы, меня лично вот весьма печалят некоторые нюансы журналирования. Но в systemd замечательно просто сделаны зависимости и с ним просто построить граф зависимостей сервисов, в том числе и от разных событий, файловых систем и прочего.
Да, у systemd есть проблемы, меня лично вот весьма печалят некоторые нюансы журналирования. Но в systemd замечательно просто сделаны зависимости и с ним просто построить граф зависимостей сервисов, в том числе и от разных событий, файловых систем и прочего.
Да замечательный он. В некоторых местах. Но мне вот упорно не понятно на кой же хрен было интегрировать практически неотделимо то, что к системе запуска демонов не относится?
Меня как-то никогда не волновала проблема того что в journald тянет по зависимостям либу для QR кодов. Плюс, как я написал выше — именно интеграция вещей не относящихся к запуску демонов делает systemd интересным (зависимости не только между сервисами).
Я успел поиграться с systemd на арче (на мелкой прототипной arm-борде) и немного с coreos. Знаете, я наверно с радостью выпилил бы некоторые шелл-костыли из боевой убунты. Да, runit простой как тапок и работает, но на systemd то же самое можно сделать проще. В какой-то мере мне даже нравится интеграция journald прямо в него, хотя как journald работает внутри я могу и не одобрять.
Я успел поиграться с systemd на арче (на мелкой прототипной arm-борде) и немного с coreos. Знаете, я наверно с радостью выпилил бы некоторые шелл-костыли из боевой убунты. Да, runit простой как тапок и работает, но на systemd то же самое можно сделать проще. В какой-то мере мне даже нравится интеграция journald прямо в него, хотя как journald работает внутри я могу и не одобрять.
«Плюс, как я написал выше — именно интеграция вещей не относящихся к запуску демонов делает systemd интересным (зависимости не только между сервисами).»
Да опять же сколько угодно. Только зависимости — это забота менеджера пакетов, и собственно, тот самый кусочек юникс-идеалогии заключается в том, что зависимость не должна быть жесткой, от единственного продукта (по крайней мере в случае такой важной и сложной части, как система запуска). Приведу пример из генты: udev, все более намертво завязанный на systemd — плохо, ее форк, eudev, работающий и с openrc и с systemd — хорошо.
Да опять же сколько угодно. Только зависимости — это забота менеджера пакетов, и собственно, тот самый кусочек юникс-идеалогии заключается в том, что зависимость не должна быть жесткой, от единственного продукта (по крайней мере в случае такой важной и сложной части, как система запуска). Приведу пример из генты: udev, все более намертво завязанный на systemd — плохо, ее форк, eudev, работающий и с openrc и с systemd — хорошо.
Я наверно слишком долго работаю с машинами, где давным давно забыли про unix-идеологию (это OS X и специализированные линуксы). Я не совсем понимаю как зависимость сервиса с конфигом на NFS от факта примонтирования NFS раздела — это забота менеджера пакетов.
Systemd работает. Его не интересует, какая у пользователя в голове идеология, он решает свой набор задач, и справляется, по большему счету, сносно. У меня «в голове» идеологии тоже нет, у меня есть задачи, которые надо решать, и инструменты, которые помогают в этом. И если мне проще накидать ini-конфиг, а не шелл-скрипт — я накидаю первый, запущу сервис и забуду об этом.
Systemd работает. Его не интересует, какая у пользователя в голове идеология, он решает свой набор задач, и справляется, по большему счету, сносно. У меня «в голове» идеологии тоже нет, у меня есть задачи, которые надо решать, и инструменты, которые помогают в этом. И если мне проще накидать ini-конфиг, а не шелл-скрипт — я накидаю первый, запущу сервис и забуду об этом.
Сначала Вы про
" journald тянет по зависимостям либу для QR кодов", потом про «зависимость сервиса с конфигом на NFS от факта примонтирования NFS раздела». Это и вносит путаницу.
Расскажите мне про специализированный линуксы, в которых забыли про unix-идеологию? До появления systemd в смысле.
«Systemd работает. Его не интересует, какая у пользователя в голове идеология, он решает свой набор задач, и справляется, по большему счету, сносно.»
Да никто не запрещает Вас системд. Проблема в том, что политика разработчиков системд прямо или косвенно направленна на то, чтоб запретить нам НЕ системд.
«И если мне проще накидать ini-конфиг, а не шелл-скрипт — я накидаю первый, запущу сервис и забуду об этом.»
Опять же. Вы вольны накидать что хотите. Проблема системд, что давятся те, кто хотят накидать шелл-скрипт. Или перл-скрипт. Или xml.
" journald тянет по зависимостям либу для QR кодов", потом про «зависимость сервиса с конфигом на NFS от факта примонтирования NFS раздела». Это и вносит путаницу.
Расскажите мне про специализированный линуксы, в которых забыли про unix-идеологию? До появления systemd в смысле.
«Systemd работает. Его не интересует, какая у пользователя в голове идеология, он решает свой набор задач, и справляется, по большему счету, сносно.»
Да никто не запрещает Вас системд. Проблема в том, что политика разработчиков системд прямо или косвенно направленна на то, чтоб запретить нам НЕ системд.
«И если мне проще накидать ini-конфиг, а не шелл-скрипт — я накидаю первый, запущу сервис и забуду об этом.»
Опять же. Вы вольны накидать что хотите. Проблема системд, что давятся те, кто хотят накидать шелл-скрипт. Или перл-скрипт. Или xml.
> Расскажите мне про специализированные линуксы
У нас в продакшене много разного интересного. Мне кажется вы больше сфокусированы на init-системе ради init-системы. Init — это просто механизм для запуска некоторого количества userspace-задач и их оркестрации.
> Проблема в том, что политика разработчиков системд прямо или косвенно направленна на то, чтоб запретить нам НЕ системд
Я этого не чувствую. Сабж впиливают как зависимость потому что он иногда предоставляет простой апи к вещам, которые ранее было более сложно делать (это касается gnome, насколько я его знаю).
Запретить? Как я ниже написал, вы вольны делать что и как угодно. Разве что с systemd эти шелл-скрипты будет как-то попроще, т.к. какая-то часть задач уже будет решена в systemd.
> Проблема системд, что давятся те, кто хотят накидать шелл-скрипт. Или перл-скрипт. Или xml
Нет, ну никто же не запрещает накидать 3-4 строки systemd-шного сервиса, в котором хоть /etc/rc.local запускайте. Никто не отбирал у вас возможность запускать что угодно когда угодно шелл или иными скриптами.
У нас в продакшене много разного интересного. Мне кажется вы больше сфокусированы на init-системе ради init-системы. Init — это просто механизм для запуска некоторого количества userspace-задач и их оркестрации.
> Проблема в том, что политика разработчиков системд прямо или косвенно направленна на то, чтоб запретить нам НЕ системд
Я этого не чувствую. Сабж впиливают как зависимость потому что он иногда предоставляет простой апи к вещам, которые ранее было более сложно делать (это касается gnome, насколько я его знаю).
Запретить? Как я ниже написал, вы вольны делать что и как угодно. Разве что с systemd эти шелл-скрипты будет как-то попроще, т.к. какая-то часть задач уже будет решена в systemd.
> Проблема системд, что давятся те, кто хотят накидать шелл-скрипт. Или перл-скрипт. Или xml
Нет, ну никто же не запрещает накидать 3-4 строки systemd-шного сервиса, в котором хоть /etc/rc.local запускайте. Никто не отбирал у вас возможность запускать что угодно когда угодно шелл или иными скриптами.
Я этого не чувствую. Сабж впиливают как зависимость потому что он иногда предоставляет простой апи к вещам, которые ранее было более сложно делать (это касается gnome, насколько я его знаю).
Звучит как «Embrace, Extend, and Extinguish».
«У нас в продакшене много разного интересного. Мне кажется вы больше сфокусированы на init-системе ради init-системы. Init — это просто механизм для запуска некоторого количества userspace-задач и их оркестрации.»
Нет, нет, я настаиваю. Какие именно на данный момент линуксы ушли от unix-way?
«Я этого не чувствую. Сабж впиливают как зависимость потому что он иногда предоставляет простой апи к вещам, которые ранее было более сложно делать (это касается gnome, насколько я его знаю).»
Отлично, вот только правильный путь был бы этот кухонный комбайн с возможностью пылесоса разделить на миксер, мясорубку, блендер и пылесос, если Вы понимаете о чем я. И уже к этому предоставлять простой апи. Никто не говорит, что системд лишен определенных прелестей. Проблема в том, что его архитектурные недостатки эти прелести перевешивают.
«Нет, ну никто же не запрещает накидать 3-4 строки systemd-шного сервиса, в котором хоть /etc/rc.local запускайте. Никто не отбирал у вас возможность запускать что угодно когда угодно шелл или иными скриптами.»
Ну опять же, и под виндой qemu /bin/bash, условно говоря, запустить можно. Вот только зачем? Я хочу запускать баш нативно.
Нет, нет, я настаиваю. Какие именно на данный момент линуксы ушли от unix-way?
«Я этого не чувствую. Сабж впиливают как зависимость потому что он иногда предоставляет простой апи к вещам, которые ранее было более сложно делать (это касается gnome, насколько я его знаю).»
Отлично, вот только правильный путь был бы этот кухонный комбайн с возможностью пылесоса разделить на миксер, мясорубку, блендер и пылесос, если Вы понимаете о чем я. И уже к этому предоставлять простой апи. Никто не говорит, что системд лишен определенных прелестей. Проблема в том, что его архитектурные недостатки эти прелести перевешивают.
«Нет, ну никто же не запрещает накидать 3-4 строки systemd-шного сервиса, в котором хоть /etc/rc.local запускайте. Никто не отбирал у вас возможность запускать что угодно когда угодно шелл или иными скриптами.»
Ну опять же, и под виндой qemu /bin/bash, условно говоря, запустить можно. Вот только зачем? Я хочу запускать баш нативно.
Нет, нет, я настаиваю. Какие именно на данный момент линуксы ушли от unix-way?Практически все.
Отлично, вот только правильный путь был бы этот кухонный комбайн с возможностью пылесоса разделить на миксер, мясорубку, блендер и пылесос, если Вы понимаете о чем я.Нет, не понимаю. Unix всегда поставлялся как набор программ. Тесно связанных между собой программ. Выдернуть getty и UNIXv6 и вкрутить в UNIXv7 нельзя. «Дёрнуть» csh из BSD-Linux и засунуть в SystemV без изменений нельзя. И так далее.
Можно ли вообще переносить компоненты из одного UNIX'а в другой? Да, можно: берёте исходники, правите и переносите.
В этом смысле systemd гораздо, гораздо, ГОРАЗДО ближе к «unix way», чем весь тот GNU/mess, который развели в Linux'ах за последние годы.
Читаю этот тред и все больше понимаю, какой же, оказывается, у поклонников systemd бардак в головах, теперь мне уже не так удивителен их выбор, хотя, нет, слово «выбор» — это не про них… Да и странно было бы расчитывать на разумность большинства. Я по своей наивности надеялся, что мне просто не везет с оппонентами, даже отчасти надеялся, что меня переубедят, хоть немного, что не все так плохо, что это я что-то не так понимаю, но нет, каждый второй такую чушь собачью несет, что ощущаешь себя в дурдоме и потихоньку уже сам начинаешь ехать…
Нет, не понимаю. Unix всегда поставлялся как набор программ. Тесно связанных между собой программ. Выдернуть getty и UNIXv6 и вкрутить в UNIXv7 нельзя. «Дёрнуть» csh из BSD-Linux и засунуть в SystemV без изменений нельзя. И так далее.
Не пробовал, но что-то мне подсказывает, что если взять какой-то пакет не столь тесно интегрированный в систему, то он вполне может оказаться совместимым.
Можно ли вообще переносить компоненты из одного UNIX'а в другой? Да, можно: берёте исходники, правите и переносите.
Разве? А потрудитесь прокомментировать цитатку из хэндбука FreeBSD
www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/nutshell.html
Binary compatibility with many programs built for Linux, SCO, SVR4, BSDI and NetBSD.
Сейчас вы должны запеть, что UNIX != Linux, поэтому дальше я попрошу комментариев к en.wikipedia.org/wiki/Linux_Standard_Base
Не пробовал, но что-то мне подсказывает, что если взять какой-то пакет не столь тесно интегрированный в систему, то он вполне может оказаться совместимым.Ни один из пакетов «поглощённых»
systemd с одного UNIX'а на другой перенести нельзя. Да и многие более высокоуровневые пакеты перенести нельзя.Они просто не соберутся.
Разве? А потрудитесь прокомментировать цитатку из хэндбука FreeBSDПотружусь, мне не жалко. Вы такое слово как Wine когда-нибудь слышали? А iBCS2 emulation? Вот примерно так запускаются программы для Linux, SCO, SVR4, BSD и NetBSD под FreeBSD. И так же работает
www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/nutshell.html
Binary compatibility with many programs built for Linux, SCO, SVR4, BSDI and NetBSD
systemd-shim. Плохо работает? Пилите, чтобы работал хорошо, а не рассказывайте всем сказки про не-unix-way.Сейчас вы должны запеть, что UNIX != Linux, поэтому дальше я попрошу комментариев к en.wikipedia.org/wiki/Linux_Standard_BaseА чего тут комментировать? Какая-то поделка, которая не используется на подавляющем большинстве Linux-систем. Чего тут комментировать?
Может вы с FHS перепутали? Он тоже мало кем используется. Перед тем как начать вопить про то, что я ничего не понимаю в колбасных обрезках и тут-то всё точно перепутал: самые популярные Linux-системы — это роутеры, смартфоны, сейчас вот ChromeOS начинает подпирать. Короче — системы, использующие Linux, но «поклавшие болт» на GNU/Mess вообще и LSB в частности. Который сейчас ещё удерживает мизерную долю desktop'а и приличную — только на чрезвычайно консервативном серверов. Вы признаете свою ошибку только когда GNU/Mess выкинут к чертям с сервера или опомнитесь несколько раньше?
Systemd — это, собственно, часть процесса осознания того, что GNU/Mess со своим анти-unix-way подходом забрёл в глубокую жопу и без серъезных реформ грозит отправится на свалку историю.
> Нет, нет, я настаиваю. Какие именно на данный момент линуксы ушли от unix-way?
Разрешите мне в данном случае ответить вопросом на вопрос для понимания контекста — распихать все демоны в контейнеры docker, которые стартуют путем однострочника в runit — это unix-way?
> кухонный комбайн с возможностью пылесоса…
На глаз у меня в пакете systemd на арче около 30 бинарников. Это ваши раздельные мясорубки и пылесосы. Да, они все упакованы в один ящик, как-то так же как амазон пакует покупки. Это спорный момент, так как с одной стороны тут строгое соответствие версий, а с другой — общий цикл релиза. На данный момент последнее проекту не мешает.
> Ну опять же, и под виндой qemu /bin/bash, условно говоря, запустить можно
Аналогия не корректна. Systemd для запуска /bin/bash не намного сложнее чем runit. /bin/bash запускается полностью «нативно» во всех смыслах, которые можно вложить в это слово.
Разрешите мне в данном случае ответить вопросом на вопрос для понимания контекста — распихать все демоны в контейнеры docker, которые стартуют путем однострочника в runit — это unix-way?
> кухонный комбайн с возможностью пылесоса…
На глаз у меня в пакете systemd на арче около 30 бинарников. Это ваши раздельные мясорубки и пылесосы. Да, они все упакованы в один ящик, как-то так же как амазон пакует покупки. Это спорный момент, так как с одной стороны тут строгое соответствие версий, а с другой — общий цикл релиза. На данный момент последнее проекту не мешает.
> Ну опять же, и под виндой qemu /bin/bash, условно говоря, запустить можно
Аналогия не корректна. Systemd для запуска /bin/bash не намного сложнее чем runit. /bin/bash запускается полностью «нативно» во всех смыслах, которые можно вложить в это слово.
Напрягает сложность простых вещей в systemD. Если я хочу что бы сервис стартовал после сети, «в старину» я дал бы ему имя начинающееся с «99-...» и он бы стартовал последним. Теперь мне нужно поставить systemd-networkd-wait-online.service, который будет следить чтобы сервисы нуждающиеся в сети откладывали свой старт.
Сервис, который мониторит сервис, что бы сказать сервисам нуждающимся в сервисе, что сервис стартанул (Тут должна разболеться голова).
Сервис, который мониторит сервис, что бы сказать сервисам нуждающимся в сервисе, что сервис стартанул (Тут должна разболеться голова).
Но вы же согласны с тем что подход с именами начинающимися на 99 не масштабируется?
Всё просто ровно до какого-то момента. Предлагаю почитать amarao habrahabr.ru/post/240839/#comment_8075561
PS: мне не всё нравится в systemd, но и в sysv-init магии хватает.
PS: мне не всё нравится в systemd, но и в sysv-init магии хватает.
Не понимаю я все эти бойкоты. Какое-то навязывание своего мировоззрения получается.
Если разработчик посчитал сделать что-то, значит он должен это делать, а если тебе что-то не нравится, то переходи на альтернативу, ведь то, что не нравится тебе может понравиться кому-то другому.
Например, та же FreeBSD на десктопе может вполне жить. Т.е., если мне, например, новый Debian не понравится, то я просто с него уйду, а не буду разводить дискуссии на форумах, доказывая, что моя точка зрения самая верная.
Если разработчик посчитал сделать что-то, значит он должен это делать, а если тебе что-то не нравится, то переходи на альтернативу, ведь то, что не нравится тебе может понравиться кому-то другому.
Например, та же FreeBSD на десктопе может вполне жить. Т.е., если мне, например, новый Debian не понравится, то я просто с него уйду, а не буду разводить дискуссии на форумах, доказывая, что моя точка зрения самая верная.
Не понимаю я все эти бойкоты. Какое-то навязывание своего мировоззрения получается.Так вы не переворачивайте с ног на голову-то! Как раз навязывание systemd идет по всем фронтам, а не наоборот. Если б такого не было, а оставалась возможность выбора, реальная, а не псевдо, без жестких зависимостей у разных компонентов на systemd, как у гнома и прочего, из-за которых он распространяется как зараза, то и слова бы никто не сказал против…
не понравится, то я просто с него уйдуА что будете делать, когда уже некуда будет уходить?
Как раз навязывание systemd идет по всем фронтам
Так я это и не отрицаю. Одни навязывают systemd, другие навязывают мнение, что systemd — зло.
Я просто хотел сказать, что агрессия и навязывание отталкивают. Возможно, если бы были спокойные и взвешенные рассуждения, без возгласов «Давайте устроим им бойкот!», то это бы так не резало глаз/слух.
А что будете делать, когда уже некуда будет уходить?
Считаю, что спрос рождает предложение. Если будет отток пользователей от «systemd-based» ОС, то, возможно, будет создаваться альтернатива.
Если б такого не было, а оставалась возможность выбора, реальная, а не псевдо, без жестких зависимостей у разных компонентов на systemd, как у гнома и прочего, из-за которых он распространяется как зараза, то и слова бы никто не сказал против…Вот только почему-то когда вводили ELF, glibc, да и тот же sysvinit таких воплей почему-то не было. Ввели — и всё. Почему сейчас, когда очередной устаревший компонент решили наконец-таки заменить столько шума? Плюрализм отчего-то вспомнили. Где был ваш плюрализьм, когда от a.out отказывались?
А что будете делать, когда уже некуда будет уходить?К тому времени уже, я надеюсь, Android (где нет всей этой бессмысленной «мышиной возни») будет достаточно хорош, чтобы на desktop ставить. С серверами, конечно, сложнее…
Все ваши примеры это замены 1->1, а systemd пытается сделать замену n->1, и это n пока растёт и растёт. Осталось еще мэнеджер пакетов в него включить…
И тот факт, что он всё пытается заменить это в общем-то не самое плохое. Что действительно плохо — он втягивает в себя компонент, а затем разработчики убирают возможность его сборки вне systemd (привет, upower-pm-utils! ну или прощай, upower-pm-utils..). Это как раз навязывание.
P.S. сам пользуюсь OpenRC и systemd. ИМХО монолитность не всегда плохо и такой подход имеет право на жизнь(см то же ядро Linux), но не мешайте остальным то, пожалуйста.
И тот факт, что он всё пытается заменить это в общем-то не самое плохое. Что действительно плохо — он втягивает в себя компонент, а затем разработчики убирают возможность его сборки вне systemd (привет, upower-pm-utils! ну или прощай, upower-pm-utils..). Это как раз навязывание.
P.S. сам пользуюсь OpenRC и systemd. ИМХО монолитность не всегда плохо и такой подход имеет право на жизнь(см то же ядро Linux), но не мешайте остальным то, пожалуйста.
У меня ситуация с systemd вызывает такую аналогию: вы принимаете на работу нового человека вместо старого, проверенного работника, уходящего на пенсию. Первым делом новичок проходится по компьютерам коллег и ставит свою ОС вместо той, в которой все работали. Затем он начинает выполнять свои обязанности, но результат его трудов не понимаете ни вы, ни коллеги. Тогда он начинает подстраивать работу коллег под себя. В итоге компания как-то работает, но вы ничего не понимаете.
Поттеринг — это какой-то диверсант, посланный в мир unix чтобы поселить там хаос, разруху и windows-мышление. Ничего не имею против Windows, но в *nix мне нравилась простота, однообразие, возможность выбора, удобные текстовые конфиги. В поделках Поттеринга простотой и не пахнет.
Поттеринг — это какой-то диверсант, посланный в мир unix чтобы поселить там хаос, разруху и windows-мышление. Ничего не имею против Windows, но в *nix мне нравилась простота, однообразие, возможность выбора, удобные текстовые конфиги. В поделках Поттеринга простотой и не пахнет.
Да нет ничерта удобных текстовых конфигов в sysvinit. Там — скрипты. Объяснять, в чём разница?
Текстовые конфиги — в systemd. Возможность делать демоны без пляски вокруг двойного форка — там же. Автоматические логи без единого движения со стороны демона — там же. Гарантированный перезапуск демона (а не мольбы о том, что в его перезапускалке нет ошибок, как в sysvinit) — там же.
Windows-мышления в systemd как раз нет. Это — миф, закрепившийся на русскоязычных околотехнических сообществах (в англоязычных на sysvinit-любителей уже давно косо смотрят). Альтернативы systemd — upstart и openrc, никак не sysvinit, которому давно пора на пенсию по объективным причинам, а не потому, что «пришёл Поттеринг и захотел подстроить работу коллег под себя».
Каждый современный UNIX (не Windows!), используемый на серверах, изобрёл для себя аналог CoreOS. Угадайте, на чём основан CoreOS. Конечно, можно закопать голову в песок и делать вид, что линуксы на серверах не нужны либо нужны в windows-стиле, но зачем, когда есть docker/CoreOS?
Ментейнеры каждого крупного дистрибутива выбрали systemd не потому, что они хотят зла пользователям, в конце концов.
Текстовые конфиги — в systemd. Возможность делать демоны без пляски вокруг двойного форка — там же. Автоматические логи без единого движения со стороны демона — там же. Гарантированный перезапуск демона (а не мольбы о том, что в его перезапускалке нет ошибок, как в sysvinit) — там же.
Windows-мышления в systemd как раз нет. Это — миф, закрепившийся на русскоязычных околотехнических сообществах (в англоязычных на sysvinit-любителей уже давно косо смотрят). Альтернативы systemd — upstart и openrc, никак не sysvinit, которому давно пора на пенсию по объективным причинам, а не потому, что «пришёл Поттеринг и захотел подстроить работу коллег под себя».
Каждый современный UNIX (не Windows!), используемый на серверах, изобрёл для себя аналог CoreOS. Угадайте, на чём основан CoreOS. Конечно, можно закопать голову в песок и делать вид, что линуксы на серверах не нужны либо нужны в windows-стиле, но зачем, когда есть docker/CoreOS?
Ментейнеры каждого крупного дистрибутива выбрали systemd не потому, что они хотят зла пользователям, в конце концов.
«Ментейнеры каждого крупного дистрибутива выбрали systemd не потому, что они хотят зла пользователям, в конце концов.»
Ага, а потому что у них нет физически возможности саппортить форки ключевых пакетов, отвязанных от системд. Осилили это пока что только в генту с eudev.
Ага, а потому что у них нет физически возможности саппортить форки ключевых пакетов, отвязанных от системд. Осилили это пока что только в генту с eudev.
А что такое «гарантированный перезапуск демона»?
И вот это:
И вот это:
Каждый современный UNIX (не Windows!), используемый на серверах, изобрёл для себя аналог CoreOS. Угадайте, на чём основан CoreOS. Конечно, можно закопать голову в песок и делать вид, что линуксы на серверах не нужны либо нужны в windows-стиле, но зачем, когда есть docker/CoreOS?переведите, пожалуйста, на русский.
> А что такое «гарантированный перезапуск демона»?
Возможность убить демона и запустить его снова.
Убить именно демона, а не тот процесс, который занял его PID.
Убить со всеми потомками, а не только с избранными.
Убить именно этого демона, а не запущенный совершенно другим пользователем процесс с тем же названием (любителям killall посвящается).
> переведите, пожалуйста, на русский.
У коммерческих UNIX-систем есть специализированные энтерпрайз-решения, заточенные под легковесную виртуализацию и кластеры, с которых и списан CoreOS. Пример — smartos.org/
Возможность убить демона и запустить его снова.
Убить именно демона, а не тот процесс, который занял его PID.
Убить со всеми потомками, а не только с избранными.
Убить именно этого демона, а не запущенный совершенно другим пользователем процесс с тем же названием (любителям killall посвящается).
> переведите, пожалуйста, на русский.
У коммерческих UNIX-систем есть специализированные энтерпрайз-решения, заточенные под легковесную виртуализацию и кластеры, с которых и списан CoreOS. Пример — smartos.org/
У коммерческих UNIX-систем есть специализированные энтерпрайз-решения, заточенные под легковесную виртуализацию и кластеры, с которых и списан CoreOS.Это я понял, я не понял к чему вы приплели CoreOS комментарием выше, если речи о виртуализации/кластерах и т.д. вообще не шло? И что значит «линуксы на серверах нужны в windows-стиле»? По мне — так systemd и привносит этот windows-стиль.
Автоматические логи без единого движения со стороны демона… бинарные, ага. А вы еще спрашиваете где тут windows-мышление?
Возможность убить демона и запустить его снова.Ну о… ть теперь! А раньше я этого не мог!
Еще о преимуществах systemd. Ускорение загрузки за счет параллельного запуска процессов. Ага. Зачем оно мне на сервере, который я перезапускаю полтора раза в год?
Я согласен что sysvinit это динозавр, которому пора на пенсию, потому что появилось множество новых задач, которые должна решать система инициализации. Но этот динозавр работает предсказуемо и просто, я всегда знаю что мне делать если что-то вдруг сделать понадобилось.
>бинарные, ага.
Может, это Вас удивит, но все файлы в памяти компьютера — бинарные. И cat — такой же просмотрщик бинарных файлов, как и journalctl.
> По мне — так systemd и привносит этот windows-стиль.
Хорошо, мы спорим о понятиях. Что по-вашему есть windows-стиль?
Я считаю, что система, масштабируемая до кластеров — это типичный UNIX-стиль. Ну а насчёт виртуализации — systemd-nspawn — пример того, что в windows-идеологии немыслимо.
Может, это Вас удивит, но все файлы в памяти компьютера — бинарные. И cat — такой же просмотрщик бинарных файлов, как и journalctl.
> По мне — так systemd и привносит этот windows-стиль.
Хорошо, мы спорим о понятиях. Что по-вашему есть windows-стиль?
Я считаю, что система, масштабируемая до кластеров — это типичный UNIX-стиль. Ну а насчёт виртуализации — systemd-nspawn — пример того, что в windows-идеологии немыслимо.
Да, не любят в «сообществе» слишком активных чуваков типа Поттеринга) Чем больше сидеть, придумывать, писать, внедрять — тем больше будет критики от основной массы юзеров, т.е. обычных завсегдатаев ЛОРа итп и просто потребителей. Не скажу, что сильный фанат, кое-что я бы сам покритиковал. Но если способен предложить что-то стоящее — так предложи. Или участвуй в написании. Или просто перейди на альтернативу. Или что-то ещё. Но проще же просто сидеть и теоретизировать как нужно было бы сделать. Причём майнтейнеры большинства дистрибутивов, а также Торвальдс и многие другие — наверно, просто дураки.
Даже на ЛОРе основная масса — не против Поттеринга. Не надо вестись на громкое меньшинство.
Зачем далеко ходить? Прокрутите эту страничку и соберите статистику плюсов и минусов комментов за и против systemd. А потом уже рассказывайте сказки про меньшинство.
Тут не ЛОР и я достаточно долго был там, чтобы знать их сообщество. Около 30% ЛОРа не любят systemd в той или иной мере, остальные либо безразличны, либо за.
А о ненависти к systemd в русском сообществе я уже говорил. Я понимаю, что в русском сообществе линуксоидов меньше процент DevOps'ов и меньше людей, работающих с кластерами. Больше энтузиастов, а не профессионалов. Это объясняет ненависть, но не делает её лучше.
Статистика плюсов/минусов, кстати, тоже многое говорит. О хабре. Конкретно — о том, что значительная часть местного населения готово расставлять плюсы и минусы согласно своей религии, что, мягко говоря, неконструктивно.
А о ненависти к systemd в русском сообществе я уже говорил. Я понимаю, что в русском сообществе линуксоидов меньше процент DevOps'ов и меньше людей, работающих с кластерами. Больше энтузиастов, а не профессионалов. Это объясняет ненависть, но не делает её лучше.
Статистика плюсов/минусов, кстати, тоже многое говорит. О хабре. Конкретно — о том, что значительная часть местного населения готово расставлять плюсы и минусы согласно своей религии, что, мягко говоря, неконструктивно.
«Тут не ЛОР и я достаточно долго был там, чтобы знать их сообщество. Около 30% ЛОРа не любят systemd в той или иной мере, остальные либо безразличны, либо за.»
Я вообще практически не бываю там и он мне не особо интересен. Я про этот ресурс, для примера.
«А о ненависти к systemd в русском сообществе я уже говорил. Я понимаю, что в русском сообществе линуксоидов меньше процент DevOps'ов и меньше людей, работающих с кластерами. Больше энтузиастов, а не профессионалов. Это объясняет ненависть, но не делает её лучше.
»
Конечно. Просто потому, что люди не согласны с Вашим мнением, Вы их записали в «энтузиастов, а не профессионалов», закрыв глаза на всю аргументацию против Вашего мнения. Тогда как с Вашей стороны аргументация в основном уровня «только системы с системд МНЕ проще разворачивать в кластерах, поэтому системд лучше!»
А про наличие недовольных системд в нерусских сообществах — я про системд первый раз услышал в списке рассылки генту для разработчиков, среди которых на мой неискушенный взгляд как раз большинство недовольных.
А в общей массе равнодушные и довольные скорее либо такие как Вы фанатики «одной кнопки», либо просто мыслят по принципу «мейнтейнеры не могут сделать плохо», не разбираясь.
«Статистика плюсов/минусов, кстати, тоже многое говорит. О хабре. Конкретно — о том, что значительная часть местного населения готово расставлять плюсы и минусы согласно своей религии, что, мягко говоря, неконструктивно.»
В первую очередь она опровергает Вашу сказу о том, что системд не любит меньшинство. Это не так. А уж кто именно эта значительная часть местного населения вопрос в другом.
Я вообще практически не бываю там и он мне не особо интересен. Я про этот ресурс, для примера.
«А о ненависти к systemd в русском сообществе я уже говорил. Я понимаю, что в русском сообществе линуксоидов меньше процент DevOps'ов и меньше людей, работающих с кластерами. Больше энтузиастов, а не профессионалов. Это объясняет ненависть, но не делает её лучше.
»
Конечно. Просто потому, что люди не согласны с Вашим мнением, Вы их записали в «энтузиастов, а не профессионалов», закрыв глаза на всю аргументацию против Вашего мнения. Тогда как с Вашей стороны аргументация в основном уровня «только системы с системд МНЕ проще разворачивать в кластерах, поэтому системд лучше!»
А про наличие недовольных системд в нерусских сообществах — я про системд первый раз услышал в списке рассылки генту для разработчиков, среди которых на мой неискушенный взгляд как раз большинство недовольных.
А в общей массе равнодушные и довольные скорее либо такие как Вы фанатики «одной кнопки», либо просто мыслят по принципу «мейнтейнеры не могут сделать плохо», не разбираясь.
«Статистика плюсов/минусов, кстати, тоже многое говорит. О хабре. Конкретно — о том, что значительная часть местного населения готово расставлять плюсы и минусы согласно своей религии, что, мягко говоря, неконструктивно.»
В первую очередь она опровергает Вашу сказу о том, что системд не любит меньшинство. Это не так. А уж кто именно эта значительная часть местного населения вопрос в другом.
>Просто потому, что люди не согласны с Вашим мнением
Пожалуйста, не занимайтесь проецированием.
>МНЕ проще разворачивать в кластерах
именно поэтому Я лично разработал CoreOS, которой уже воспользовалась не одна компания? Извините, у меня нет такой мании величия.
>списке рассылки генту
Интересно, сколько среди их пользователей именно DevOps'ов. Генту давно известна как дистрибутив для этузиастов (в хорошем смысле слова) либо для тех, кто собирает дистрибутив под конкретные цели (например, для embedded. Естественно, на устройстве уже не будет emerge).
>В первую очередь она опровергает Вашу сказу о том, что системд не любит меньшинство
Какая статистика, кстати? Меня минусуют 2 человека, из них 1 в карму. Плюсуют не меньше.
> системд не любит меньшинство
Зайдите на /r/linux или news.ycombinator. Хотя бы по поводу этой же новости: news.ycombinator.com/item?id=8477659
Пожалуйста, не занимайтесь проецированием.
>МНЕ проще разворачивать в кластерах
именно поэтому Я лично разработал CoreOS, которой уже воспользовалась не одна компания? Извините, у меня нет такой мании величия.
>списке рассылки генту
Интересно, сколько среди их пользователей именно DevOps'ов. Генту давно известна как дистрибутив для этузиастов (в хорошем смысле слова) либо для тех, кто собирает дистрибутив под конкретные цели (например, для embedded. Естественно, на устройстве уже не будет emerge).
>В первую очередь она опровергает Вашу сказу о том, что системд не любит меньшинство
Какая статистика, кстати? Меня минусуют 2 человека, из них 1 в карму. Плюсуют не меньше.
> системд не любит меньшинство
Зайдите на /r/linux или news.ycombinator. Хотя бы по поводу этой же новости: news.ycombinator.com/item?id=8477659
А гентушникам-то зачем systemd? У них openrc, там все хорошо.
А вот в дебиане ужасающая помойка. Там что угодно, что приведет в порядок бардак в инитах, подойдет. Хоть системд, хоть апстарт, хоть черт лысый.
А вот в дебиане ужасающая помойка. Там что угодно, что приведет в порядок бардак в инитах, подойдет. Хоть системд, хоть апстарт, хоть черт лысый.
Блин, тока-тока с древнего арча наконец на дебиан переполз, тока-тока заставил тринити работать нормально, и на тебе и сюда systemd добрался.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Страсти вокруг systemd и его использования по умолчанию в Debian