История изменений

1. Миф: 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 должен быть легок для вас.

1. Миф: 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 должен быть легок для вас.

1. Миф: 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 должен быть легок для вас.