LINUX.ORG.RU

systemd — новый подход к инициализации системы

 , , , ,


2

2

Lennart Poettering, сотрудник компании Red Hat, представил концепцию принципиально нового механизма управления инициализацией системы — systemd (system daemon), которая вобрала в себя достоинства классического System V init и более современных launchd (Mac OS X), SMF (Solaris) и Upstart (Ubuntu, Fedora), но при этом лишена многих их недостатков. В разработке этого проекта ему помогали сотрудники Red Hat, Novell, IBM, Intel и Nokia.

systemd опирается на современные linux-технологии: cgroups, AutoFS, D-Bus, и при этом совместим с исторически устоявшимися механизмами: init-скриптами, стандартными командами shutdown, poweroff и т.п. Предоставляемый systemd функционал позволяет заменить не только систему инициализации, но и ряд других подсистем, в частности, cron, (x)inetd, xdm/kdm/gdm/..., частично даже SELinux.

Основные идеи, использованные при создании systemd:

  • Контроль над сокетами. Многие демоны, запускаемые при инициализации, взаимодействуют с другими демонами через unix domain и сетевые сокеты, и большинство существующих систем инициализации запускают демона-клиента только после того, как демон-сервер запустится и создаст сокет. Вместо этого, systemd создает сокеты, а затем запускает демонов, передавая им эти сокеты. Даже если демон-клиент запустится быстрее и начнет использовать сокет раньше сервера, ничего страшного не произойдет: его запрос будет буферизован и передан серверу, как только тот сможет его обработать. Такой подход уже используется в Mac OS X (launchd), позволяя этой ОС достигать впечатляющей скорости загрузки.

    Аналогичный принцип используется systemd и при запуске служб, использующих шину D-Bus.

    Кроме того, возможен автоматический запуск служб при обращении к заданным сокетам (см. ниже).

  • Фоновое монтирование. Такие операции, как монтирование, проверка и активация квот файловых систем, занимают весьма значительную долю загрузочного времени. В большинстве современных систем они выполняются последовательно, до запуска всех демонов. systemd же предлагает монтировать не-жизненно-важные ФС только тогда, когда они кому-то понадобятся. Для этого используется механизм AutoFS. Например, многие служебные демоны вовсе не обязаны ждать, пока смонтируется огромный и к тому же зашифрованный /home.

    Разумеется, этот подход неприменим к /, /proc, /sys и т.п.

  • Минимизация числа вспомогательных процессов. В настоящее время значительная часть работ по инициализации производится шелл-скриптами, что приводит к колоссальным времязатратам. В частности, Леннарт пишет:

    On my system the scripts in /etc/init.d call grep at least 77 times. awk is called 92 times, cut 23 and sed 74,

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

    В качестве альтернативы Леннарт предлагает предлагает переписать критичные участки на C, а также вынести часть функционала в самих демонов и в systemd. Сейчас для systemd уже готовы написанные на C подсистемы монтирования и установки имени хоста. До полной победы, отмечает Леннарт, работа предстоит огромная, но результат того стоит.

  • Отслеживание процессов. В ныне используемых системах инициализации в принципе возможна такая ситуация, когда при неправильном форке процесс может «потеряться». Например, так может произойти с некорректно написанным CGI-приложением, и процесс останется работать даже после остановки веб-сервера.

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

    Также к этой группе задач относится и автоматический перезапуск демонов, перенаправление их stdout/stderr на выбранные TTY или в системный журнал, регистрация всех запусков и остановок служб, и многое другое.

  • Ограничение процессов. systemd предоставляет множество возможностей ограничить или расширить полномочия процессов, контролируя такие параметры, как uid, gid, umask, рабочий и корневой каталоги, класс и приоритет CPU и I/O, наличие доступа на чтение и запись к смонтированным файловым системам и отдельным каталогам и т.п. Также можно использовать возможности по ограничению ресурсов, предоставляемые cgroups.

Базовым элементом systemd являются модули (units), которые связаны между собой и имеют определенный тип. Каждый модуль может требовать для своей работы другие модули, конфликтовать с модулями, запускаться только после или до определенного модуля (директивы конфигурации Requires, Conflicts, Before, After, Wants). Из типов модулей определены:

  • service — обычный демон, поддерживающий операции start, stop, restart, reload. Может быть представлен родным (native) файлом конфигурации systemd или System V init-скриптом.
  • socket. При обращении к сокету генерируется событие, для которого можно настроить обработчик. Например, автоматически запускать определенные службы при обращении к заданному сокету. В этом отношении systemd похож на давно известный (x)inetd, однако при этом поддерживает unix domain сокеты и FIFO.
  • device. Отметив нужные устройства в конфигурации udev, впоследствии можно использовать такие события, как появление и удаление устройства, в качестве событий systemd, назначив на них обработчики. Например, при появлении устройства bluetooth будет запущена соответствующая служба.
  • mount. systemd контролирует все точки монтирования файловых систем. В целях обратной совместимости поддерживается сбор информации о точках монтирования из /etc/fstab.
  • automount. Для помеченных таким образом точек монтирования, монтирование выполняется только при обращении к ним.
  • target. Более гибкий аналог уровней исполнения (runlevels), используемых в System V init. Представляет собой группу служб, объединенных по функциональному назначению. Например, multi-user.target идентичен runlevel 5, а bluetooth.target приводит к инициализации подсистемы bluetooth.
  • snapshot — во многом похож на target. Позволяет «запомнить» существующую конфигурацию units (запущенных служб, открытых сокетов, смонтированных ФС) с тем, чтобы в дальнейшем восстановить это состояние. Позволяет, например, перейти в emergency shell (сейчас это init 1), а затем полностью восстановить набор запущенных служб. Другой пример — выход системы из состояния suspend.

Надо заметить, что systemd отличается от SMF, во-первых, тем, что позволяет оперировать не только зависимостями между службами, но и событиями, например, «готовность устройства» или «обращение к сокету». Во-вторых, systemd использует более простой формат файлов конфигурации (.desktop aka .INI против XML в SMF).

От upstart же systemd отличается более высокой степенью параллелизации, и как следствие, более высокой скоростью загрузки. Например, если демон A требует для работы сокет, открытый демоном B, то upstart сначала запустит демона B, а затем демона A, в то время как systemd создаст сокет сам и запустит обоих демонов одновременно, что занимает примерно в два раза меньше времени. Используемый в upstart принцип, когда ключевыми событиями является лишь запуск и остановка демона, Леннарт и его коллеги считают изначально неэффективным.

Well, the point of the part about Upstart above was to show that the core design of Upstart is flawed, in our opinion. Starting completely from scratch suggests itself if the existing solution appears flawed in its core. However, note that we took a lot of inspiration from Upstart's code-base otherwise.

>>> Подробности

★★★★

Проверено: isden ()

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

>Я рад, что разум в итоге восторжествовал даже у фряшников
Ваше высказывание устарело лет эдак на пять.

ак говорил мой многоуважаемый шеф.

1. Не лезь в исправный механизм.
2. Даже если инструмент устарел, но его применение решает задачу хотя бы на 60%, то нет необходимости применять что-то новое.

Очевидно, что в опенке:
1. Народ более адекватный. Ибо зачем параллелить задачи при убогой SMP. Текущая схема задачу свою решает достаточно хорошо, чтобы не заморачиваться.
2. У них есть чем заняться и без волос.

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

:-) Но знаете ли вы магию helper? Сейчас однако новая и очевидная для всех тенденция к вынесению всего некритичного за границу ядра. auditd, udev, automount, ... . Замедьте, я с вами не спорю, вы правы что здесь что-то мутновато с реализацией. Ест вопросы к наследованию дескрипторов сокетов, обслуживание очередей. Однако, всё это решаемо, но, вопреки заявлениям, путём чщательного допиливания окружающего ландшафта.

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

Ну, насчёт «хорошо» - это вопрос привычки ;) У меня товарищ как на опенку переехал, так на вопрос «ну и как справляешься?», стал отвечать: «А чо, емакс и нетскейп запускаются, что ещё нужно для домашнего компа :)»

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

> Сейчас однако новая и очевидная для всех тенденция к вынесению всего некритичного за границу ядра.

Только некоторых функций, и только той части, котоаря отвечает за совсем уж юзерспейсные действия.

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

Согласна, только объем пиления такой, что придется целую лесопилку строить, и сгонять на нее великое множество людей. И все только заради системы инициализации? Ой, а может ну ее нафиг, чем глюки годами ловить, лучше 30 секунд подождать :-)

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

>в Debian GNU/Linux для скриптов по умолчанию используется dash - легковесный интерпретатор. а то я вижу вы тут все поголовно на bash наезжаете.

справедливости ради, баш в позикс-режиме (автоматически включается, если вызван как /bin/sh) тоже достаточно быстр

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

>/bin/sh с его прямо скажем убогими средствами текстовой и файловой обработки

имхо, шелл гораздо лучше подходит для работы с текстами и файлами, чем С

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

>Кстати, а не лучше bash JIT комплитятор какой написать

хорошее дело. но сначала хотя бы для POSIX sh

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

>Я о том, что gcc присутствует в обязательном порядке. Иногда на соседней машине, но он есть

Профессиональные искажения восприятия, что ли? Или гента?

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

> Только некоторых функций, и только той части, которая отвечает за совсем уж юзерспейсные действия.

Не буду спорить но аноним помнит про fuse

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

> имхо, шелл гораздо лучше подходит для работы с текстами и файлами, чем С

Никоим образом не за использование C в системе старта, однако хочется спросить а C++, STL, boost::rope как? Тоже тошнит? Может это серъёзное? В скриптах только strcat делается веселее (внешне), любое другое действие очень неэффективно.

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

Из того, что большинству сервисов не требуется ничего сложнее exec и kill, следует то, что накладные расходы bash на этих сервисах близки к нулю, и никакой JIT их не ускорит.

Ответ - нет. Ещё раз, медленнее. Даже для сервисов, которые «просто запускаются», навернута (F13b для определённости) обвязка в виде проверок, надо или нет запускать, всякое last-minute конфигурирование и прочее.

У меня нет F13, поэтому для определенности я беру Debian Lenny. Берем, скажем, скрипт запуска bluetooth... Видим в нем десятки test и [, немного расстраиваемся. От расстройства пишем проверочный скрипт:

while :; do
        if test -x /bin/cp; then
                :
        fi
        [ -f /bin/ls ] && :
done

Пускаем его под strace. И что мы видим... полное отсуствие fork, потому что используются встроенные test и [.

strace -f sh testscript:

23009 access("/bin/cp", X_OK)           = 0
...
23009 stat64("/bin/ls", {st_mode=S_IFREG|0755, st_size=92312, ...}) = 0

То есть дорогих вызовов типа clone нет, откуда берутся расходы? Можно было бы еще спросить про JIT для bash, но ладно...

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

Сам скрипт отслеживанием межсервисных зависимостей не занимается - просто несет в себе «волшебные комментарии».

Глянь как-нить, познавательно.

Давно уже.

Пример Убунты (и, вероятно, Генты) наглядно, тыкскыть, демонстрирует, что отказ от legacy существенно ускоряет

То есть в Убунте init-скрипты уже не на shell, а на... чем?

То есть, ты сейчас спорил со мной, не владея предметом? :)

Я не спорил о деталях работы upstart, так что упрек мимо. И как мне тут подсказали, в upstart скрипты таки на shell, просто к нему добавлен еще и DSL для управления завиисимостями. Хотя к большей части скриптов даже он не добавлен.

Напрасно. Это не клуб благородных джентльменов, а ЛОР.

Ну, не опускаться же мне до вашего уровня ;)

Уже.

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

>Профессиональные искажения восприятия, что ли? Или гента?

Это называется суровая правда жизни.

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

Вот так очередной раз гнусные технари портят гуманитариям полёт фантазии.

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

Ага. И ODM-реестр еще впридачу. Нет уж, спасибо.

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

> То есть дорогих вызовов типа clone нет, откуда берутся расходы?

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

И как мне тут подсказали, в upstart скрипты таки на shell

Тебе сказали пол-правды. Скрипты на шелл там для тех, кому нужен скрипт на шелл. Для тех, кому скрипт не нужен (например, dbus или anacron) вместо директивы script/end script используется директива exec.

Хотя к большей части скриптов даже он не добавлен.

Почитай/посчитай внимательнее.

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

Видим в нем десятки test и [, немного расстраиваемся. От расстройства пишем проверочный скрипт:

 
while :; do 
        if test -x /bin/cp; then 
                : 
        fi 
        [ -f /bin/ls ] && : 
done 

Пускаем его под strace. И что мы видим... полное отсуствие fork, потому что используются встроенные test и [.

strace -f sh testscript:

 
23009 access("/bin/cp", X_OK)           = 0 
... 
23009 stat64("/bin/ls", {st_mode=S_IFREG|0755, st_size=92312, ...}) = 0 

То есть дорогих вызовов типа clone нет

Вот честно, для чего ты всё это писал? Чтобы убедить меня в том, что cat и /bin/cat - разные команды? Спасибо, К.О. Что в случае твоего примера никакого ощутимого прироста в скорости, будь то bash, lua или галимый C не будет? Ещё раз спасибо, достопочтенный дон Кихот Ламанчский. Только учти, что ветряные мельницы, с которыми ты сражаешься никакого отношения к реальности не имеют.

Чтобы твой тест имел хоть какой-то смысл, надо брать профайлер и смотреть, как так получается, что «FreeBSD грузится на порядок быстрее любого линукса», как тут вон BSD'шники глумятся. Люди из initng и upstart такие тесты проводили (уж не знаю, насколько корректные, но результат upstart'а, в который раз повторюсь, меня впечатлил)

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

>> То есть дорогих вызовов типа clone нет, откуда берутся расходы?

А хбз, профилировать надо.

Что там профилировать, параллельно пускать надо (в чем и пойнт upstart).

Для тех, кому скрипт не нужен (например, dbus или anacron) вместо директивы script/end script используется директива exec.

ОК, по одному fork на запуск сервиса они экономят. Я очень удивлюсь, если средний десктоп не выдаст хотя бы 200 fork в секунду на bash. Так что экономия неочевидна в лучшем случае.

Хотя к большей части скриптов даже он не добавлен.

Почитай/посчитай внимательнее.

Я уже сказал, что у меня Debian, а не Убунта. Но вот человек посчитал: http://www.linux.org.ru/jump-message.jsp?msgid=4842538&cid=4845990

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

>и больше, но скорости загрузки сама по себе такая методика не добавляет.

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

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

Какой какой С?

Вы там в вашем мухохранске афигели совсем.

Мне другое интересно как вы собираетесь оптимизировать те десятки тысяч обращений к одним и тем же файлам которые имеют место быть при загрузке? Так уверяют авторы ядра которые проверяли сей момент.

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

Ну, в отличие от tailgunner'а я мал-мал экспериментировал с параллельным запуском. Сам по себе этот метод (грубо говоря, for i in /etc/init.d/*; do $i start &; done) особого прироста не даёт, т.к. мы быстренько упираемся в лимит ресурсов (ну, наиболее вероятно, что в I/O). Это всё равно что типичную десктопную машинку задр...ть при помощи make -j 10 - и ей плохо, и тебе никакого толку.

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

> прочитай внимательнее здесь и здесь

Вот это: «получается 62 традиционных скрипта и 32 апстартовских»? Я же не о точном соотношении спорю - я говорю, что в убунте еще дофига обычных init-скриптов. Да и вообще, речь шла о профите от Lua/JIT bash/whateverheresy против скрипта на обычном bash, и том, что граф зависимости служб и скрипты на shell дадут 99.9% профита от переписывания скриптов с shell на Lua/JIT bash/whateverheresy.

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

> Это всё равно что типичную десктопную машинку задр...ть при помощи make -j 10 - и ей плохо, и тебе никакого толку.

Доо... аналогии такие аналогии. make -j2 на типичной десктопной машине даст почти 2-кратный выигрыш.

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

>Сам по себе этот метод (грубо говоря, for i in /etc/init.d/*; do $i start &; done) особого прироста не даёт, т.к. мы быстренько упираемся в лимит ресурсов (ну, наиболее вероятно, что в I/O).

У меня метод прирост дал. На глаз. Вероятно, потому, что у меня двухъядерник.

А лимит ресурсов будет всегда, при любом методе. Или вы уже нашли способ его обойти?

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

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

Кстати, как ее включить? Попробую при следующей перезагрузке.

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

Варианты описаны тут: /usr/share/doc/insserv/README.Debian

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

> А если make -j4?

на обычном двухъядернике это не даст заметного выигрыша по сравнению с make -j2, и даже может быть медленнее. Но на двухъядернике даже make -j10 будет быстрее обычного make.

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

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

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

> А на Celeron-е (обычном)?

На одноядерннике make -j2 тоже может дать выигрыш, но небольшой. Впрочем, уже вроде есть двухъядерные Celeron'ы :)

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

Ох... Как хорошо уметь читать... А ещё полезно не забывать прочитанное. Соотношение апстартовых и традиционных скриптов - примерно 1:1. При том, что все «базовые» - уже в виде /etc/init/<name>.conf.

и том, что граф зависимости служб и скрипты на shell дадут 99.9% профита

У вас (Debian) _УЖЕ_ есть граф зависимостей. Что, тебе это сильно помогло?

make -j2 на типичной десктопной машине даст почти 2-кратный выигрыш.

И как 2-кратным выигрышем от текущего состояния ты собираешься догнать убунту с её 5-8-кратным (по настенным часам)... А взять и резко нарастить количество ядер с 2 до 8 на десктопе, увы, не получится. Так что «думай ещё, Бычий ...!»

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

> А лимит ресурсов будет всегда, при любом методе. Или вы уже нашли способ его обойти?

Разумеется, будет. И уперевшись в физические лимиты железки придётся думать, как сделать умнее, чем есть сейчас. Тов. tailgunner уверен, что делать умнее, чем сейчас, не нужно, и всё можно решить брутфорсом...

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

> «думай ещё, Бычий ...!»

Да, не восприми как персональное оскорбление. Просто анекдот такой есть...

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

> Как хорошо уметь читать... А ещё полезно не забывать прочитанное. Соотношение апстартовых и традиционных скриптов - примерно 1:1

«получается 62 традиционных скрипта и 32 апстартовских» %)

и том, что граф зависимости служб и скрипты на shell дадут 99.9% профита

У вас (Debian) _УЖЕ_ есть граф зависимостей. Что, тебе это сильно помогло?

У нас отключено его использование. Кроме того, A->B->C->D - это тоже граф, только он параллельности не дает. Вечером попробую включить параллельность.

make -j2 на типичной десктопной машине даст почти 2-кратный выигрыш.

И как 2-кратным выигрышем от текущего состояния ты собираешься догнать убунту

Никак. Я собираюсь всего лишь продемонстрировать негодность твоей аналогии.

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

Вероятно, потому, что мало кто хочет переписывать ворох init-скриптов.

Да ты явно сбрендил.

$ for i in `dpkg -L initscripts | grep etc/init.d/` ; do wc -l $i ; done
65 /etc/init.d/bootmisc.sh
88 /etc/init.d/mountall.sh
108 /etc/init.d/umountnfs.sh
41 /etc/init.d/rc.local
144 /etc/init.d/umountfs
31 /etc/init.d/mountall-bootclean.sh
96 /etc/init.d/bootlogd
117 /etc/init.d/sendsigs
97 /etc/init.d/mountdevsubfs.sh
76 /etc/init.d/bootlogs
158 /etc/init.d/skeleton
33 /etc/init.d/stop-bootlogd
83 /etc/init.d/mountkernfs.sh
59 /etc/init.d/rmnologin
83 /etc/init.d/halt
108 /etc/init.d/mountnfs.sh
31 /etc/init.d/mountnfs-bootclean.sh
62 /etc/init.d/killprocs
57 /etc/init.d/umountroot
51 /etc/init.d/stop-bootlogd-single
38 /etc/init.d/reboot
180 /etc/init.d/mtab.sh
55 /etc/init.d/mountoverflowtmp
68 /etc/init.d/hostname.sh
78 /etc/init.d/urandom
159 /etc/init.d/checkfs.sh
35 /etc/init.d/single
445 /etc/init.d/checkroot.sh

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

>> Вероятно, потому, что мало кто хочет переписывать ворох init-скриптов.

Да ты явно сбрендил.

Вот думаю - сказать тебе «ПНХ» или спросить «ты о чем?».

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

«получается 62 традиционных скрипта и 32 апстартовских» %)

Я всё-таки рекомендую тебе внимательно перечитать три упомянутые сообщения. Хинт: правильный ответ - 62:55.

У нас отключено его использование.

ну зачем ты пытаешься меня обмануть? Хотя, впрочем, в дебиановский insserv я не глядел давно. В SuSE'шном граф зависимостей используется.

Никак. Я собираюсь всего лишь продемонстрировать негодность твоей аналогии.

Ты опять бьёшься с ветряными мельницами в твоём мозгу :/

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

>> У нас отключено его использование.

ну зачем ты пытаешься меня обмануть

А ты уверен, что это _я_ бьюсь с ветряными мельницами в своем мозгу? %) Ну зачем мне врать тебе? Я в худшем случае честно ошибаюсь.

Хотя, впрочем, в дебиановский insserv я не глядел давно.

Прикинь, он у меня не установлен даже - в дефолтовом Ленни.

tailgunner ★★★★★ ()

Эх... жаль. Линукс все усложняется и усложняется. И скоро уже не получится так просто реанимировать упавшую систему, и частая переустановка системы будет обычным делом рядового линуксоида.

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

>порядка в управлении сервисами стало, может быть, и больше, но скорости загрузки сама по себе такая методика не добавляет.

Я там приводил цифры суси. 21 сек до kdm а через ~38 сек KDE 4 готов к работе.

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

>1. Не лезь в исправный механизм.

2. Даже если инструмент устарел, но его применение решает задачу хотя бы на 60%, то нет необходимости применять что-то новое.

Совершенно верно. Хочу только добавить, что эти девелоперы со своими новшествами не только лезут в то, что работает, но и по-хамски тратят мое драгоценное время. Они думают, мне больше нечего делать, как каждый год изучать заново их героиновые приходы. Есть стабильное знание, стабильный инструмент. Это же большое завоевание. По этим инструментам большое количество литературы (даже старой и еще актуальной), курсы, большое число носителей знания. Чуть только люди застабилизируют свои знания, так находится какой-то хрен, который пытается все отменить. grep у него тормозит, блин.

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

>заметная часть треда про то, что на (домашнем) компе трёхмесячный аптайм противопоказан.

works for me!

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

И вы ещё под win не пишете! Вот там действительно приходы. И не надо мне про «стабильный API». С моим уходом оттуда лучше не стало (6 лет).

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

> Чуть только люди застабилизируют свои знания, так находится какой-то хрен, который пытается все отменить. grep у него тормозит, блин.

Аминь, брат.

tailgunner ★★★★★ ()

> On my system the scripts in /etc/init.d call grep at least 77 times. awk is called 92 times, cut 23 and sed 74

пионеры юные, головы чугунные, сами оловянные, черти окаянные

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

Ну и зачем оно нужно? У меня у десктопа по 50 дней аптайма, мне наплевать на скорость загрузки. [..]

[..] Лично мне на моём личном ноутбуке нужно.

и на ноутбуке оно не очень то и нужно. отучаемся говорить за всю сеть и открываем для себя suspend-to-ram. на моём ноутбуке, который я очень интенсивно всюду и везде с собой таскаю, тоже uptime 30 дней и больше.

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

PS: заряда батареии в suspend кстати на неделю хватает.

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