Вроде как тут пишут, что в RHEL будет http://ru.wikipedia.org/wiki/Systemd
странно, что на все крики против - в статье до сих пор нет раздела «критика»
Myth: systemd is about speed. чото не то со скоростью
Myth: systemd's fast boot-up is irrelevant for servers. быстрая загрузка невозможна для серверов
Myth: systemd is incompatible with shell scripts. - несовместим с шелл-скриптами
Myth: systemd is difficult. - это сложная хренотень
Myth: systemd is not modular. - он не модульный
Myth: systemd is only for desktops. - только для досктопа
Myth: systemd was created as result of the NIH syndrome. он был создан как результат какого то НЕХ синдрома.
Myth: systemd is a freedesktop.org project. это проект freedesktop.org
Myth: systemd is not UNIX. - не соответствует стандартам юникс
Myth: systemd is complex. - это комплексное решение
Myth: systemd is bloated. в нём есть блобы
Myth: systemd being Linux-only is not nice to the BSDs. - я нихрена не понял его алабанские заморочки, системд не приятен, подобно инициализации БСД.
Myth: systemd being Linux-only makes it impossible for Debian to adopt it as default.
Он сделает невозможным переключение на другую систему инициализации
Myth: systemd could be ported to other kernels if its maintainers just wanted to. он может быть переведён на другие ядра, если мейнтейнеры захотят етава.
Myth: systemd is not portable for no reason. не портируется. на это нет всяких причин.
Myth: systemd uses binary configuration files. - он использует бинарные конфиги
Myth: systemd is a feature creep.- системд - говнецо будущего
Myth: systemd forces you to do something. - системд заставит тебя чонить делать
Myth: systemd makes it impossible to run syslog. сделает невозможным запуск сислога
Myth: systemd is incompatible. - он несовместим
Myth: systemd is not scriptable, because of its D-Bus use. - не скриптуется, потому что повязан с дБасом.
Myth: systemd requires you to use some arcane configuration tools instead of allowing you to edit your configuration files directly.
он заставляет тебя использовать спецтузлы, вместо твоего любимого joe
Myth: systemd is unstable and buggy. - нестабилен и зело глюкав
Myth: systemd is not debuggable. - нет возможности отладки (ты же свободный от задротства человек?)
Myth: systemd makes changes for the changes' sake. вносит изменения ради изменений
Myth: systemd is a Red-Hat-only project, is private property of some smart-ass developers, who use it to push their views to the world. системд это личный проект редхата, которые ложат х на остальных
Myth: systemd doesn't support /usr split from the root directory. он не поддерживает отделение /usr и корня
Myth: systemd doesn't allow your to replace its components. не позволяет заменять компоненты
Myth: systemd's use of D-Bus instead of sockets makes it intransparent. использует дБас заместо сокетов, делая это прозрачно(ансейф?)
Myth: systemd being Linux-only is not nice to the BSDs.
Myth: systemd being Linux-only makes it impossible for Debian to adopt it as default.
Myth: systemd could be ported to other kernels if its maintainers just wanted to.
При этот на первый говорит, что бздшникам оно и не нужно.
На второй: Дебиан и так делает очень много - пущай ещё поработают.
А на третий «системД - это одно большое Г, и оно не портируемо».
Он так и не написал, что прибил udev к systemd стальными гвоздями.
Про то, что в systemd нет багов это как раз мистика. То, что в федориной багзиле всего пару штук багов не значит, что их нет вообще. Просто его systemd никому не сдался и багов как видишь мало. А как начнут пользоваться тонны багов посыпятся и надо заставить его жрать свое г пару-тройку дней, чтобы не врал и не зазнавался.
Они мудаки. Сам лично знаю пару человек, неплохих программистов, и иногда даже очень хороших, однако вся их неновисть заканчивается установкой убунты, и затем сносом оной через 2 дня. Игр нет, что-то все не как раньше, любимой слушалки музыки и нотпада нет. Гавно ваш линукс. Я бы наверное сам так рассуждал, если бы я в ключевой момент смог бы прямо поставить винду. Были проблемы с железом, поэтому остался тут. Через пару месяцев ставил ещё раз для работы, но находится там уже не смог. Поэтому и сидят
Миф: systemd переусложнен [архитектурно]
(кстати, тут он отвечает в духе «ололо, да весь ленакс с его софтом такой». Доктор Хикки настоятельно рекомендует регулярные инъекции Plan 9 в гойловной моск поциента, вплоть до полного выздоровления)
Myth: systemd is bloated.
Миф: systemd раздут [архитектурно]
(«не-не-не, веб-серверок можно и не компелять, значит — не раздутый»)
нет. не является. Это 69 файлов, которые вместе работают, вместе ставятся, и вместе поддерживаются. Работают они параллельно, потому-то и пришлось сделать 69 файлов, а не один. Но он не монолитный, наоборот - он будет очень хорошо загружать все ваши 69 ядер CPU.
миф: systemd быстрый.
Да. Быстрый. (900мс, кто быстрее? [почему-то не рассказано, как там слака загрузилась. примечание переводчика]). Однако нам плевать на быстроту, нам главное, что-бы код был читаем [можно подумать, что его кто-то читает]. мы вообще не думали о скорости - так получилось.
миф: для серверов не важна скорость загрузки.
Важна. Вспомните, как вы мучительно долго перезагружали своё облако на Windows™? С нашим systemd вы будете перезагружать своё облако мгновенно!
миф: systemd не совместим со скриптами
Чушь! systemd может запускать что угодно! Ему вообще плевать, что он запускает!
миф: systemd сложен.
Нонсенс! Что там сложного-то? Простой и понятный [Ленарту] конфиг! Вспомните, как ВЫ мучились, осваивая этот тупой и дебильный shell!
Конечно systemd тоже надо изучать, но мы проверяли: большинство людей [очевидно идиотов] намного быстрее врубаются в наш конфиг, чем в shell, в котором очень много лишнего и ненужного [видимо речь про параллельный запуск]
По ссылке нет никаких опровержений, демагогия какая-то. Причём по некоторвм вопросам даже наоборот прямо говорит что да, это действительно так и пытается убедить что это хорошо.
И вообще, что это тут делает в новостях, особенно без перевода? В Толксы.
Myth: systemd is about speed. чото не то со скоростью
С точностью до наоборот. Миф был «systemd писали ради скорости». Опровержение «Мы о скорости не думали. Это просто побочный эффект того, что все писалось кошерно и правильно».
Если вы собираете Systemd со всеми опциями конфигурирования, то вы получите 69 отдельных файлов. Эти файлы все выполняют разные задачи, и разделены по ряду причин. Например, мы разработали Systemd с учетом требований безопасности, поэтому большинство демонов запускаются с минимальными привилегиями ( например, с использованием возможностей ядра ), и реализуют конкретные задачи, для того, что бы свести к минимуму их зоны безопасности и взаимодействия. Кроме того, Systemd распараллеливает процесс загрузки больше, чем любое предварительное решение. Это происходит за счёт запуска большинства процессов параллельно. Таким образом, очень важно, чтобы Systemd разделено на множество бинарных файлов и, таким образом процессов. Большинство из этих файлов могут использоваться вне Systemd.
Пакет содеращий 69 отдельных файла вряд ли можно назвать монолитным. Отличием от предварительного решения является то, что мы распространияем много компонентов в одном архиве, и поддерживаем их в едином репозитории с единым циклом выпуска.
2. Миф: Systemd о скорости.
Да, Systemd быстр (Кто ещё может предоставить загрузку полношл пользовательского окружения в ~ 900ms ?), Но это в основном просто побочный эффект делать все правильно. В самом деле, мы никогда не садились за оптимизацию производительности Systemd во всём. Вместо этого, мы на самом деле часто сознательно выбрали немного медленные пути при написании кода для того, чтобы сделать код более читабельным. Это не значит, что быстро не имеет никакого значения для нас, но снижение Systemd своей скорости, конечно, совершенно ошибочное мнение, так как это, конечно, не где-нибудь в верхней части нашего списка целей.
3. Миф: быстрая Systemd по загрузке не имеет никакого значения для серверов.
Это просто совершенно не соответствует действительности. Многие администраторы на самом деле заинтересованы в низком времени простоя во время технического обслуживания windows. В конфигурациях высоко доступных систем это вроде хорошо если вышедшая из строя система возвращается в рабочее состояние реально быстро. В облачных установки с большим числом виртуальных машин или контейнеров цена медленной загрузки умножается на числом экземпляров. Трата минут процессора и ввода-вывода на очень медленную загрузку сотен виртуальных машин или контейнеров уменьшает плотность вашей системы резко, черт возьми, это даже будет стоить вам больше энергии. Медленная загрузка может быть весьма финансово дорога. Тогда, как быстрая загрузка контейнеров позволяет реализовать логику, такие как групповая активация контейнеров, что позволяет существенно увеличить плотность облачной системы.
Конечно, во многих серверных установках загрузка на самом деле не имеет значения, но Systemd должна охватывать всю доступную полосу пропускания. И да, я знаю, что часто на серверах прошивка (firmware) тратит больше всего времени при загрузке, и ОС в любом случае быстрее по сравнению с этим, но хорошо, Systemd по-прежнему должна охватывать всю доступную полосу пропускания (см. выше ... ), и нет, не все серверы имеют такие плохие прошивки, и, конечно, не виртуальные машины и контейнеры, которые являются серверами в своем роде, тоже.
4. Миф: Systemd несовместимо со сценариями оболочки.
Это полностью ложно. Мы просто не используем их в процессе загрузки, поскольку мы считаем, что они не являются лучшим инструментом для этой конкретной цели, но это не значит, Systemd несовместима с ними. Вы можете легко запустить скрипты, как сервис Systemd, черт возьми, вы можете запускать скрипты, написанные на любом языке, как сервис Systemd, Systemd не заботит то, что внутри исполняемого файла. Кроме того, мы активно используют скрипты для наших собственных целей, для установки, сборки, тестирования Systemd. И вы можете использовать сценария в начале процесса загрузки, использовать их как нормальный сервис, вы можете запустить их на этапе выключения, использование сценариев практически не имееет ограничений.
5. Миф: Systemd сложен.
Это и есть весь нонсенс. Systemd платформы на самом деле гораздо проще, чем традиционно используемые в дистрибутивах Linux, потому что она объединяет системы объектов и их зависимостей, как юниты Systemd. Язык конфигурационного файла очень прост, кроме того мы избавились от дублирующихся файлов конфигурации. Мы предоставляем едыные инструменты для конфигурирования большей части системы. Система значительно меньше, чем в конгломерате традиционных дистрибутивов Linux. У нас также есть довольно полная документация (все ссылки на главной странице) о почти каждой детали Systemd, которая охватывает не только интерфейсы администратора / пользователя, но и API для разработчиков.
Понимание Systemd, конечно, приходит с обучением. Все, что делает. Тем не менее, мы хотели бы верить, что Systemd на самом деле проще для понимания, чем основанные на Shell сценариях системы загрузки для большинства людей. Удивленно мы говорим, что? Ну, как выясняется, shell сценарии не являются достаточно простым языком, их синтаксис тайный и сложный. Юниты Systemd по существу проще для понимания, они не подвержены языку программирования, но просты и имеют декларативный характер. Это всё, если у вас есть опыт в shell сценариях, то да, для принятия Systemd потребуется немного обучения.
Чтобы сделать процесс обучения легким, мы старались обеспечить максимальную совместимость с предыдущими решениями. Но не только это, на многих дистрибутивах вы обнаружите, что некоторые из традиционных инструментов теперь даже сказать вам, - во время выполнения, что вы просите, - как вы могли бы сделать это с помощью новых инструментов вместо этого, в возможно более хорошим способом .
Во всяком случае, вероятно, что Systemd также проста, как такая система может быть, и мы стараемся чтобы система была легка для обучения. Но да, если вы знаете Sysvinit, то для принятия Systemd потребует немного обучения, но, откровенно говоря, если вы освоили Sysvinit, то Systemd должен быть легок для вас.
Вообще, всё правильно сказал. Насторожили только две его фразы:
Moreover, building a simple OS based on systemd will involve much fewer packages than a traditional Linux did.
То есть он уже противопоставляет systemd-based OS "традиционным линуксам"? Не слишком ли много на себя берёте, батенька? Тогда busybox-based OS вообще, по его логике, мегауникальны. И, кстати, требуют вообще всего два бинарника - ведра и бизибокса.
That said, D-Bus actually has bindings for almost any scripting language this world knows. Even from the shell you can invoke arbitrary D-Bus methods with dbus-send or gdbus. If anything, this improves scriptability due to the good support of D-Bus in the various scripting languages.