Леннарт Поттеринг (Lennart Poettering) представил (http://lists.freedesktop.org/archives/systemd-devel/2013-Mar...) релиз системного менеджера systemd 200 (http://www.freedesktop.org/software/systemd/). В новой версии переработан код упреждающего чтения данных с жестких дисков в процессе загрузки, который теперь осуществляет чтение в несколько проходов, учитывающих не только размещение данных на диске. но и время доступа к ним. Вторым изменением является добавление в /etc/os-release поля BUILD_ID, предназначенного для использования в операционных системах с непрерывным формированием сборок.URL: http://lists.freedesktop.org/archives/systemd-devel/2013-Mar...
Новость: http://www.opennet.me/opennews/art.shtml?num=36540
Он же должен когда-нибудь выпустить LTS версию?
7-я шапка не за горами... в ней такими темпами версии ПО менять не получится.
нет, не должен. Для Поттеринга системд стал предметом фетиша. Пока оно не впитает в себя всё вокруг LTSов не будет
Что, теперь каждый коммит будет релизом?
Да, действительно, это хороший вопрос. 200 - это версия или номер ревизии?
это "груз 200"
это юбилей.
это диагноз
modus operandi, кули
Release early, release every day!
> Что, теперь каждый коммит будет релизом?Это у него твЫтЫр такой.
$ less --version
less 456 (POSIX regular expressions)
Copyright (C) 1984-2012 Mark Nudelman
1984... Это важно.
> 1984... Это важно.Да, у них пока длиннее. А 1984 важно. Что там у нас, министерство правды или министерство любви на дворе? Я что-то запутался.
>Да, у них пока длиннее. А 1984 важно. Что там у нас, министерство правды или министерство любви на дворе? Я что-то запутался.Нет, но свои двухминутки ненависти многие отрабатывают на опеннете :)
>но и время доступа к нимМне одному кажется, что это уже чересчур.
Городить сложный код ради нескольких миллисекунд?
Или он систему грузит с дискет и ему не нравится часто их менять?
>>но и время доступа к ним
> Мне одному кажется, что это уже чересчур.
> Городить сложный код ради нескольких миллисекунд?
> Или он систему грузит с дискет и ему не нравится часто их
> менять?Чуваку никто не рассказал про NCQ
Чуваку никто не рассказал, что форк в линухе не настолько ресурсоёмкий вызов. И самое главное, он не роняет родителя.
Уже ~полгода использую и системд, и опенрк. Вначале было интересно, грузилось в 2-а раза быстрее.
Теперь, когда функционал набран, с теми же демонами грузится быстрее меньше чем на 1с.
Но есть но, кривой сервис роняет процесс с PID=1. И выход только ресет. Сам уже столкнулся.
В общем виндовый подход. Но там то форка и не было.
Любой апстарт будет лучше. Вот такое моё имхо.
> Но есть но, кривой сервис роняет процесс с PID=1. И выход только
> ресет. Сам уже столкнулся.Что - натурально падает init? Круто, я этого лет 15-ть уже не видел, да и тогда было пару раз на кривейшей красной шапке.
он обзывается теперь:
$ ps -ef|grep systemd
root 1 0 0 марта29 ? 00:00:02 /bin/systemd
но да, падает. теперь есть такие способы его уронить.
запустил свой не отлаженный сервис, выдал что-то типа не могу связаться, служба dbus не зарегистрирована. После этого reboot, shutdown, halt тоже отказались, так как процесс с PID=1 не найден.зыж
>Круто, я этого лет 15-ть уже не виделВообще такого не видел. И в других никсах. А это с 93-го.
Багрепорт написал?
> Багрепорт написал?"Дорогие архитекторы, дома не строят с крыши"?..
Вы не могли бы приоткрыть чуть больше информации "о свой не отлаженный сервис". Каким образом вам удалось уронить init? В голову приходит только что-то из "memory corruption", но возможно вы нашли уязвимость в ядре?
>Вы не могли бы приоткрыть чуть больше информации "о свой не отлаженный сервис".это текстовой файл вида myprog.service в формате systemd.
в частности я писал сервис-файл для нового gdm.зыж
>В голову приходит только что-то из "memory corruption", но возможно вы нашли уязвимость в ядре?разумеется это враги виноваты.
А выложи-ка пожалуйста свой myprog.service, тоже хочу init в арчике снести.
ну ты блин даёшь, я его уже давно стёр.
а править я его пытался на предмет gdm multihead xrandr workaround https://bbs.archlinux.org/viewtopic.php?id=98437 но чтобы для любых dm работал,а то при подключенном доп.мониторе основной не в родной режим входил.
в результате забил в xorg.conf жёстко параметры мониторов, а xdm.service оставил стандартный.
> Что - натурально падает init? Круто, я этого лет 15-ть уже не видел,Да ну? Как минимум раньше, если кильнуть процесс инита раньше стандартной реакцией был кернел паник.
>> Что - натурально падает init? Круто, я этого лет 15-ть уже не видел,
> Да ну? Как минимум раньше, если кильнуть процесс инита раньше стандартной реакцией
> был кернел паник.Милый Аноним, вы хоть иногда читаете, что пишите? "Kernel panic" и падение "init" - это разные вещи, поскольку ядро - это другая программа, это не init.
Милый Vkni, смерть /sbin/init и паника ядра связаны напрямую — первое влечёт второе. И уронить канонiчный SysV Init не так-то просто, в отличие от некоторых новомодных изделий :)
~> sudo kill -9 1
Password:
~> echo HELLO WORLD
HELLO WORLD
где мой обещанный kernel panic? Gentoo, OpenRC 0.11.8
Init реагирует только на SIGHUP, SIGUSR1, SIGINT и SIGWINCH. Можешь ему слать хоть TERM, хоть KILL, хоть SEGV — результат не изменится =)
> Init реагирует только на SIGHUP, SIGUSR1, SIGINT и SIGWINCH. Можешь ему слать
> хоть TERM, хоть KILL, хоть SEGV — результат не изменится =)откуда дровишки?
>> Init реагирует только на SIGHUP, SIGUSR1, SIGINT и SIGWINCH. Можешь ему слать
>> хоть TERM, хоть KILL, хоть SEGV — результат не изменится =)
> откуда дровишки?Из man init, вестимо.
>Init реагирует только на SIGHUP, SIGUSR1, SIGINT и SIGWINCH. Можешь ему слать хоть TERM, хоть KILL, хоть SEGV — результат не изменится =)Лапчатые - это пять! Нет - это 100500+!!! Значит kill -9 получает _процесс_ да? 8-)
> Значит kill -9 получает _процесс_ да? 8-)О том, как работает kill с PID 1 можно прочесть в man 2 kill.
> Милый Vkni, смерть /sbin/init и паника ядра связаны напрямуюМилый GoF, если вас стукнуть молотком по голове, вы умрёте. Таким образом, молоток и смерть - связанные вещи, но далеко не одно и то же. Речь шла про стабильность init, поэтому стабильность ядра, цвет камней на Марсе, защищённость OpenVMS и другие вещи тут не к месту.
>> Что - натурально падает init? Круто, я этого лет 15-ть уже не видел,
> Да ну? Как минимум раньше, если кильнуть процесс инита раньше стандартной реакцией
> был кернел паник.Когда уже выходные закончатся и начнется нормальный учебный процесс?
Инит того, не киляется. Нигде (во при киле инита система переходит в single-user, в Linux он вообще не киляется).
> Когда уже выходные закончатсявот именно. в своё время (видимо, когда *ты* ещё в школу ходил) init отлично убивался. именно таким — несколько неприличным, но необходимым — методом я в своё время делал emergency reboot на одной интересной железяке с пингвинусом. поэтому молчал бы ты про школу…
> Чуваку никто не рассказал, что форк в линухе не настолько ресурсоёмкий вызов.Особенно заметно какой он не ресурсоемкий на примере апача на которого напустили siege :). Хотя перфекционизм у поттеринга конечно разыгрался.
Во-первых — can choose to use a threaded MPM like worker or event, while sites requiring stability or compatibility with older software can use a prefork.
т.е. в апаче давно уже тормозят точно не форки, а его «богатая» функциональность.Во-вторых — в линухе и форк, и легковесные процессы, и потоки реализованы как частный случай системного вызова clone2, который реализован с помощью "копирования страниц при записи" (copy-on-write, COW).
Так что всё вами сказанное из разряда мифов и народных поверий.
NCQ и readahead совершенно с разными целями используются и результат их действий тоже разный.
> NCQ и readahead совершенно с разными целями используются и результат их действий тоже разный.Местных аналитиков это не смущает. Бывает hate driven development. А бывает hate driven analytics. Ну вот это - второе.
> Чуваку никто не рассказал про NCQА ещё про SSD, аппаратные контроллеры со своим кешем, и кеш самого жесткого диска.
И вообще сомнительная операция, учитывая размер стартующих бинарников.
> И вообще сомнительная операция, учитывая размер стартующих бинарников.дело не совсем в размере файла, а в метаданных фс. Холодное чтение файла может вызвать с десяток random IO для подгрузки инодов и списков директорий. Обычный hdd даст задержки в секунды даже на пустых файлах, но для ssd это не критично.
>> И вообще сомнительная операция, учитывая размер стартующих бинарников.
> дело не совсем в размере файла, а в метаданных фс. Холодное чтение
> файла может вызвать с десяток random IO для подгрузки инодов и
> списков директорий.Да, но тут как раз и поможет NCQ.
борьба давно уже не идёт за секунды. борьба веласьб и ведётся за более предсказуемое и контролируемое поведение во время загрузки\работы\остановки\перезапуска сервисов и их зависимостей.
Вы даже не представляете, как я счастлив что эта борьба идет не на моей опенрсевой улице. И даже не в моем гентушном районе. А что до остального - так я попкорном давно запасся.
знаешь, как удобно отличать нормальных людей от всех остальных? не единственным, но очень чётким признаком «остального» является использование бэкслэша для разделения вариантов. вместо нормального слэша. видишь такое — сразу понимай, что это «ж-ж-ж» неспроста.
> борьба давно уже не идёт за секунды.Да уж, заметно.
> борьба велась и ведётся за более предсказуемое и контролируемое поведение
Так для этого сначала головой думать надо и только затем писать... почему-то make(1) _таких_ фокусов себе не позволяет.
> Так для этого сначала головой думать надо и только затем писать… почему-то
> make(1) _таких_ фокусов себе не позволяет.ничего, у лёни портеринга руки дойдут однажды. внезапно он проснётся утром и поймёт, что make никуда не годится, и что надо делать maked.
>> make(1) _таких_ фокусов себе не позволяет.
> ничего, у лёни портеринга руки дойдут однажды. внезапно он проснётся утром и
> поймёт, что make никуда не годится, и что надо делать maked.Когда ему расскажут про buildd, опять придётся писать 23 статьи с обоснованием, почему он о нём не знал^W^W^W^Wпросто необходим изнывающему Миру. Ну, да, ему не впервой.
> ничего, у лёни портеринга руки дойдут однажды. внезапно он проснётся утром и
> поймёт, что make никуда не годится, и что надо делать maked.Не каркай! :D
> Не каркай! :Dда, ты прав, зря я это в паблике написал… теперь если что — буду себя виноватым считать.
ты прав, пора уже замедлять код, а то быстрый стал.
> код упреждающего чтения данных с жестких дисков в процессе загрузки, который теперь осуществляет чтение в несколько проходов, учитывающих не только размещение данных на диске, но и время доступа к ним.Эээээ... какбэ это, вроде, всегда было делом ядра?
Тише, не раскрывайте тайну GNU/systemd (или systemd/systemd?) раньше времени.
> Тише, не раскрывайте тайну GNU/systemd (или systemd/systemd?) раньше времени.Гм, ureadahead или как там его правильно - уж сто лет есть. Какая нафиг тайна? Вы просто ручник не отпустили, парни!
> Тише, не раскрывайте тайну GNU/systemd (или systemd/systemd?) раньше времени.Canonical/Linux
>> код упреждающего чтения данных с жестких дисков в процессе загрузки, который теперь осуществляет чтение в несколько проходов, учитывающих не только размещение данных на диске, но и время доступа к ним.
> Эээээ... какбэ это, вроде, всегда было делом ядра?Если ты имеешь в виду планировщик IO, то ты неправ, потому что горизонт его планирования довольно мал (текущая очередь запросов), а readahead же используется для планирования ввода-вывода на большем промежутке времени.
> Эээээ... какбэ это, вроде, всегда было делом ядра?А демоны для readahead в курсе этой фигни? Ядро не может знать заранее какие файлы в процессе загрузки понадобятся следующими. А вот демоны занимающиеся read ahead - запросто. При том разумно вполне - мелкий демон подчитывает файлы которые потом понадобятся, так что когда они понадобились - они уже раз и в кэше ФС. Загрузка ускоряется. А потом демон вообще отмирает и более никого не беспокоит.
>> Эээээ... какбэ это, вроде, всегда было делом ядра?
> А демоны для readahead в курсе этой фигни? Ядро не может знать
> заранее какие файлы в процессе загрузки понадобятся следующими. А вот демоны
> занимающиеся read ahead - запросто. При том разумно вполне - мелкий
> демон подчитывает файлы которые потом понадобятся, так что когда они понадобились
> - они уже раз и в кэше ФС. Загрузка ускоряется. А
> потом демон вообще отмирает и более никого не беспокоит.Ну, это, если он конечно же отмирает.
А то бывает, что вместе с водой и ребенка выплеснут.
>>> Эээээ... какбэ это, вроде, всегда было делом ядра?
>> А демоны для readahead в курсе этой фигни? Ядро не может знать
>> заранее какие файлы в процессе загрузки понадобятся следующими. А вот демоны
>> занимающиеся read ahead - запросто. При том разумно вполне - мелкий
>> демон подчитывает файлы которые потом понадобятся, так что когда они понадобились
>> - они уже раз и в кэше ФС. Загрузка ускоряется. А
>> потом демон вообще отмирает и более никого не беспокоит.
> Ну, это, если он конечно же отмирает.
> А то бывает, что вместе с водой и ребенка выплеснут.Сказать-то что хотел?
> релиз системного менеджера systemd 200Не, ну уже можно сказать, что systemd обогнал других по размеру версии.
Уже можно говорить "какая-какая у вас версия? А у нас во - 200!".
Для systemd пора бы уже запиливать графическую оснастку, типа gpedit, чтобы не разрывать себе шаблоны в консоли с её командами. Но ведь не будут же - не линукс-вей?
> Для systemd пора бы уже запиливать графическую оснастку, типа gpedit, чтобы не
> разрывать себе шаблоны в консоли с её командами. Но ведь не
> будут же - не линукс-вей?Дада, и обязательно включить его в systemd.
> Для systemd пора бы уже запиливать графическую оснастку, типа gpedit, чтобы не
> разрывать себе шаблоны в консоли с её командами. Но ведь не
> будут же - не линукс-вей?Вот вспомнил как эта фигня называется, называется она в Windows реестр. Привет ошибкам проектирования.
уже есть - называется gconf :-)
> переработан код упреждающего чтения данныхздорово, в арче у меня включено.