форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
Сообщение от opennews (??) on 07-Апр-13, 08:59
В ходе работ по улучшению поддержки системного менеджера systemd в качестве init-процесса начального RAM-диска (initrd), разработчики Кей Сайверс и Гарольд Хойер столкнулись (https://plus.google.com/108087225644395745666/posts/H9CFBQLG8S8) с интересным и по-своему курьезным фактом — при использовании initrd, суммарное время инициализации ядра и initrd оказалось примерно на 10% меньше, чем время инициализации ядра без initrd. Начальный RAM-диск (http://ru.wikipedia.org/wiki/Initrd) (initrd)  представляет собой специализированную файловую систему, которая используется ядром на стадии начальной загрузки. Основная задача initrd — обеспечить монтирование жизненно важных файловых систем: корня и /usr. В наиболее простых ситуациях (локальные дисковые разделы) данная работа может быть проделана и ядром, однако в случае использования для этих разделов специфическим механизмов (LVM, RAID, multipath, шифрование, NFS), initrd является наиболее простым и гибким решением. Также он может оказаться полезен в качестве аварийно-восстановительной системы, предоставляя администратору средства, необходимые для исправления ошибок при монтировании ключевых системных разделов. Традиционно считалось, что отказ от initrd должен неизбежно привести к увеличению скорости загрузки. Однако, при использовании в качестве init-процесса initrd systemd, результат получился неожиданным и парадоксальным: ядро в сочетании с initrd отрабатывали быстрее, чем ядро без initrd. Наиболее вероятная причина состоит в том, что при загрузке без initrd ядро выполняет вызов wait_for_device_probe(), ожидая завершения инициализации всех периферийных устройств. В то время как при использовании initrd с systemd, загрузка продолжается сразу после инициализации необходимых устройств (т.е. носителей корня и /usr). Асинхронная архитектура systemd, в отличие от классической синхронной, позволяет не задерживать процесс загрузки на ожидание устройств, которые не требуются на данном этапе. В зависимости от аппаратной конфигурации системы, эта задержка может сильно отличаться: например, встроенный в ноутбук 3G-модем без SIM-карты задерживает загрузку на 5 секунд, а сервер с тысячами физических дисков и/или логических томов может потерять несколько десятков минут, опрашивая каждое блочное устройство на предмет наличия на нем файловой системы. Стоит отметить, что в обсуждении (https://plus.google.com/108087225644395745666/posts/H9CFBQLG8S8) один из разработчиков приводит довольно простой патч (http://git.fenrus.org/git/?p=packages/kernel.git;a=blob;f=bo...), который теоретически должен исправить эту проблему, путем перевода данной операции в ядре на асинхронный режим. К сожалению, пока отсутствуют результаты измерений, которые бы позволили судить об эффективности такого исправления. В дополнение, несколько других, более коротких новостей от проекта systemd: -  Разработчики systemd и Arch Linux Том Гундерсен и Дейв Рейзнер обеспечили (https://plus.google.com/114015603831160344127/posts/RtPgrezU6Cy) поддержку systemd в качестве init-процесса initrd при использовании стандартного для Arch генератора inird — mkinitcpio (в то время, как упомянутая выше работа Сайверса и Хойера акцентируется на dracut, стандартном initrd-генераторе Fedora/RHEL и Mageia/Mandriva). -  Разработчик Arch Linux и SDDM (http://www.opennet.me/opennews/art.shtml?num=36449) Андреа Скарпино представил (https://plus.google.com/104652450278570828775/posts/BjcLZyDLQ7f) библиотеку libsystemd-qt (https://github.com/ndr/libsystemd-qt), упрощающую обращение к функциям systemd из программ на базе фреймворка Qt. В качестве примера использования библиотеки приводится простая программа ksystemd, позволяющая просматривать состояние различных системных юнитов. В целом, проект направлен на улучшение взаимной интеграции systemd и KDE. -  Разработчики пользовательского окружения Enlightenment обеспечили (http://git.enlightenment.org/core/enlightenment.git/commit/?...) поддержку использования systemd в качестве системы инициализации сеанса. Запуск пользовательского сеанса в десктоп-окружении во многом аналогичен загрузке системы, что позволяет использовать для решения обеих этих задач один и тот же механизм, с минимальной адаптацией. Ранее, в силу сложившейся в эпоху SysV init традиции неоднократно дублировать и реализовывать заново уже существующую функциональность, каждое десктоп-окружение предлагало свою собственную систему инициализации сеанса. Замена множества собственных реализаций на общий стандарт должна упростить жизнь разработчикам DE и позволит им сконцентироваться на более актуальных задачах. -  Опубликованы видеозаписи докладов сотрудника компании Wargaming (известной своей игрой World of Tanks) Максима Мельникова, одного администраторов инфраструктуры серверов World of Tanks. В первом докладе (https://www.youtube.com/watch?feature=player_embedded&v=uAzV...) «Зачем нам systemd», кратко рассматриваются ключевые преимущества systemd, полезные для системных администраторов и отсутствующие в других решениях. Во втором докладе (https://www.youtube.com/watch?feature=player_embedded&v=gDEi...) обсуждаются достоинства механизма Journal и разбирается практический пример его использования. Доклады примечательны тем, что тема использования systemd впервые затронута на русскоязычной конференции разработчиков и пользователей Linux ((LVEE 2012 (http://lvee.org/ru/reports/materials_lvee_2012)). <center> <iframe width="640" height="360" src="http://www.youtube.com/embed/uAzVsVAVbEU?rel=0" frameborder="0" allowfullscreen></iframe></center> <center> <iframe width="640" height="360" src="http://www.youtube.com/embed/gDEiCsjA1mk?rel=0" frameborder="0" allowfullscreen></iframe></center> URL: https://plus.google.com/108087225644395745666/posts/H9CFBQLG8S8 Новость: http://www.opennet.me/opennews/art.shtml?num=36611
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–5 +/–
Сообщение от Аноним (??) on 07-Апр-13, 08:59
Норм.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
Сообщение от Аноним (??) on 07-Апр-13, 09:06
Продолжаем анонировать на время загрузки?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+5 +/–
	Сообщение от тоже Аноним (ok) on 07-Апр-13, 10:51
	В тексте есть намек на крайнюю ситуацию: "Проблема в датацентре устранена, сервера уже загружаются и часа через полтора, опросив всю периферию, наконец загрузятся".
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	15. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–4 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 11:25
	Хватит уже идеопатировать, какие полтора чяса? проверка одного диска в 3тб длиться дольше будет чем опрос 26 дисков. И да лучше знать сразу при загрузке что у тебя траблы с винтами чем потом ковырять логи.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	63. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+4 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:07
	> Хватит уже идеопатировать, какие полтора чяса? проверка одного диска в 3тб длиться > дольше будет чем опрос 26 дисков. И да лучше знать сразу > при загрузке что у тебя траблы с винтами чем потом ковырять > логи. А при чем здесь траблы с винтами?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	127. "Разработчики systemd: загрузка с initrd оказалась..."	–16 +/–
	Сообщение от arisu (ok) on 07-Апр-13, 20:38
	> А при чем здесь траблы с винтами? мозг включи, ага.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	284. "Разработчики systemd: загрузка с initrd оказалась..."	+3 +/–
	Сообщение от Аноним (??) on 09-Апр-13, 00:33
	Как минусуют на предложение влючить мозг! Прям красота...
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	285. "Разработчики systemd: загрузка с initrd оказалась..."	+4 +/–
	Сообщение от Led (ok) on 09-Апр-13, 02:26
	> Как минусуют на предложение влючить мозг! Прям красота... Естественно. Они считают, что включать мозг - "несовременно". Мозг должен включить им systemd... когда посчитает нужным... "асинхронно"
	Ответить | Правка | ^ к родителю #284 | Наверх | Cообщить модератору

	157. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 23:47
	> при загрузке что у тебя траблы с винтами чем потом ковырять логи. А давайте всем дискам fsck при старте делать по этому поводу, да? Всем 26. На 3 Тб. И полную проверку поверхности. Чтоб уж наверняка. И пусть весь мир подождет!
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	173. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от x0r (??) on 08-Апр-13, 00:42
	да, лучше бы сделали on-line проверку fs как в FreeBSD и не парились
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	202. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 09:30
	> да, лучше бы сделали on-line проверку fs как в FreeBSD и не парились Кроме деградации перфоманса дисков на хзсколько часов :)
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	235. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от sHaggY_caT (ok) on 08-Апр-13, 13:38
	Советую Вам когда-нибудь заглянуть в BSD-ый lost+found на разделе с UFS с хваленым soft updates, и придти в ужас, если сервер несколько раз ребутали резетом. Нет уж, на фре только ZFS!
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	249. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от anoser_anon on 08-Апр-13, 15:03
	Правильно. там нет lost+found. Соответственно некуда смотреть и в ужас не придешь.
	Ответить | Правка | ^ к родителю #235 | Наверх | Cообщить модератору

	251. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от sHaggY_caT (ok) on 08-Апр-13, 15:28
	> Правильно. там нет lost+found. Соответственно некуда смотреть и в ужас не придешь. Что бы появился, ребутните пару раз сервер под настоящей(не локалхостовой) нагрузкой
	Ответить | Правка | ^ к родителю #249 | Наверх | Cообщить модератору

	273. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+4 +/–
	Сообщение от kurokaze (ok) on 08-Апр-13, 21:53
	> да, лучше бы сделали on-line проверку fs как в FreeBSD и не > парились Вот уж не надо, я с этим ужасОм несколько лет мучался. Хуже был только ntfs
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	182. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Батяня Комбат on 08-Апр-13, 05:34
	Пурга, боец. Читай устав - он кровью писан. Такие проблемы решаются по другому, и если датацентр сдохнет ... никто в мире кроме NOC'а и товариша полковника - и не узнает, даже TCP сессии не порвуться. А ты (салага!) предлагаешь суетиться и сучить - а это не наши методы! Пи^W как там ныне положено - АМЕН!
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	203. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+3 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 09:31
	Иллюстрация по теме "сорванные башни".
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	21. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Buy (ok) on 07-Апр-13, 13:05
	Там ананировать не на что, если бы хоть ощутимый эффект был. Тонны кода, документации, холиваров, а на выходе -2 секунды от 20. Я не воодушевлен.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	46. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 15:24
	> Там ананировать не на что, если бы хоть ощутимый эффект был. Тонны > кода, документации, холиваров, а на выходе -2 секунды от 20. Я > не воодушевлен. Тонны документации - уже офигенно полезных выход. Особенно по сравнению со всякими SysV init и OpenRC, где чтобы понять назначение скрипта, необходимо читать его код. А в systemd каждый чих документирован, и про каждый чих делается подробная запись в логи.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	49. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+6 +/–
	Сообщение от гость on 07-Апр-13, 15:30
	Ещё, знаешь, названия скриптов помогают %)
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	53. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 15:43
	> Ещё, знаешь, названия скриптов помогают %) Если бы названия всегда помогали, программа man так бы никогда и не появилась. И info тоже.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	107. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 07-Апр-13, 19:04
	> Ещё, знаешь, названия скриптов помогают %) Спасибо, видел я что обычно творится в таких скриптах. И лучше я буду читать простой конфиг на 5 строк чем то что там нынче навалено. Не в обиду, но в половине инитовских скриптов почему-то оказывается лютейший гогнокод писаный на коленке каким-то укуренным бабуином. Например, константы размазанные по всей трехстраничной портянке вперемешку с логикой - стандартное состояние дел.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	160. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от etw (ok) on 08-Апр-13, 00:06
	Ты забыл добавить, что этот говнокод между дистрибутивами, к тому же, обычно еще и непереносим. И поэтому майнтенеры каждого из них занимаются сочинением своих ламповых инит-говняшек.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	195. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 09:04
	> Ты забыл добавить, что этот г внокод между дистрибутивами, к тому же, обычно > еще и непереносим. И поэтому майнтенеры каждого из них занимаются сочинением > своих ламповых инит-г вняшек. Может, вы просто скрипты ни писать ни читать не умеете, м? Оба причем?
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	200. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–2 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 09:23
	> Может, вы просто скрипты ни писать ни читать не умеете, м? Оба причем? Осталось еще добавить что зато вот вы - Д`Артаньян :).
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	237. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+6 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 14:04
	> И лучше я буду читать простой конфиг на 5 строк А если он не сдюжит работать как надо -- пойдёте читать исходники systemd?
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	65. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–3 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:09
	> Тонны документации - уже офигенно полезных выход. Особенно по сравнению со всякими > SysV init и OpenRC, где чтобы понять назначение скрипта, необходимо читать > его код. А в systemd каждый чих документирован, и про каждый > чих делается подробная запись в логи. Зачем нужны тонны документации, если сам скрипт служит себе же самой полной документацией? И каждый чих документировать не нужно - он самим скриптом документирован уже. А в systemd приходится даже чихи, при чем - каждый! - документировать. При чем следуеи учитывать, что история учит только одному - история ничему не учит. Это я к чему - исторически сложилось так, что доступная документация на пару-тройку версий отстает от быстро развивающейся программы. А уж найти более быстро развивающуюся программу, чем systemd, задачка не из простых!
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	67. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+3 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:14
	> Зачем нужны тонны документации, если сам скрипт служит себе же самой полной > документацией? И каждый чих документировать не нужно - он самим скриптом > документирован уже. Вы полагаете, это нормально, когда вместо чтения man-страницы приходится читать код (причем отнюдь не три строчки, и написан он далеко не всегда читабельно)? > А в systemd приходится даже чихи, при чем - каждый! - документировать. В SysV init, по хорошему, тоже нужно. Но на это просто забивают, отбрехиваясь заклинаниями про "прозрачность". > При чем следуеи учитывать, что история учит только одному - история > ничему не учит. Это я к чему - исторически сложилось так, > что доступная документация на пару-тройку версий отстает от быстро развивающейся программы. Не знаю, у каких таких программ она отстает, а у systemd изменения в код и документацию идут либо в одном коммите, либо в двух подряд.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	330. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от vg. on 10-Апр-13, 11:02
	> > Зачем нужны тонны документации, если сам скрипт служит себе же самой полной > > документацией? И каждый чих документировать не нужно - он самим скриптом > > документирован уже. > > Вы полагаете, это нормально, когда вместо чтения man-страницы приходится читать код (причем отнюдь не три строчки, и написан он далеко не всегда читабельно)? ну для большинства и букварь поначалу нечитабелен, а с опытом - вполне себе ;-)
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	333. "Разработчики systemd: загрузка с initrd оказалась..."	+1 +/–
	Сообщение от arisu (ok) on 10-Апр-13, 11:42
	> ну для большинства и букварь поначалу нечитабелен, а с опытом — вполне > себе ;-) до сих пор не могу спокойно читать. как увижу «мама мыла раму» — так возбуждаюсь сразу.
	Ответить | Правка | ^ к родителю #330 | Наверх | Cообщить модератору

	108. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 07-Апр-13, 19:05
	> Зачем нужны тонны документации, если сам скрипт служит себе же самой полной документацией? По опыту чтения таких скриптов - чаще всего он служит документацией по теме "быдлокодинг на шелл, или как не надо писать скрипты инициализации".
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	110. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 07-Апр-13, 19:22
	>> Зачем нужны тонны документации, если сам скрипт служит себе же самой полной документацией? > По опыту чтения таких скриптов - чаще всего он служит документацией по > теме "быдлокодинг на шелл, или как не надо писать скрипты инициализации" Чтение исходников сисемд, несомненно, обогатит ваш опыт, но вряд ли изменит ваши выводы. И таки да, чтение документации в каких то простых случаях может заменить чтение исходников.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	199. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 09:21
	> Чтение исходников сисемд, несомненно, обогатит ваш опыт, но вряд ли изменит ваши выводы. Если я суюсь в систему инициализации, у меня как правило цель - новый кастомный демон запустить. А вовсе не все исходники в мире перечитать. Чем проще это делается - тем лучше моя жизнь. Это так сложно понять? Вот написать 5 строчек в конфиг - это явно проще чем вкуривать в трехстраничные скрипты писанные левой пяткой какого-то индивида. > И таки да, чтение документации в каких то простых случаях может заменить чтение исходников. И таки да, в 99% случаев это именно простые случаи и будут. Ну, запуск/останов демона. Ну по некоторым критериям, например "сеть появилась!". Ну под неким юзером. Ну с неким приоритетом. Ну перезапуск, если он упал. Совершенно стандартные задачи. И вот это вот в sysv init приходится довольно густо докостыливать. В то время как в сабжеобразных системах инициализации это пяток строк конфига и более нифига.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	332. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от vg. on 10-Апр-13, 11:19
	> Если я суюсь в систему инициализации, у меня как правило цель - > новый кастомный демон запустить. А вовсе не все исходники в мире > перечитать. Чем проще это делается - тем лучше моя жизнь. Это > так сложно понять? Вот написать 5 строчек в конфиг - это > явно проще чем вкуривать в трехстраничные скрипты писанные левой пяткой какого-то > индивида. тут важно определиться - Вы в роли юзера или админа. Если юзера - то все понятно, хочется чтобы "все искаропки", ну и что-то прикрутить простое и понятное с помощью отвертки была возможность. Ежели админа - тогда непонятно нежелание чтения скриптов - Вам не нравится изучать, как система устроена? Как же Вы тогда хотите получить знания о ее работе? Документация зачастую неполна и неточна...
	Ответить | Правка | ^ к родителю #199 | Наверх | Cообщить модератору

	222. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от другой аноним on 08-Апр-13, 11:04
	В отличие от скриптов, чтение исходников системд и не требуется. Здесь требуется только прочитать что добавлять в конфиги. Которые, как я понимаю, более менее логичны и единообразны, в отличие от длинных портянок скриптов с кучами переменных и циклов
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	270. "Разработчики systemd: загрузка с initrd оказалась..."	+6 +/–
	Сообщение от arisu (ok) on 08-Апр-13, 21:47
	ага. логичны и единообразны. с кучей ключей типа «запустить, если есть файл abc.» «запустить, если есть файл abc и сегодня новолуние.» «запустить, если…» вот вся эта штука называется «командный язык». и он — СЮРПРАЙЗ! — уже давно есть. shell. но у Инноваторов NIH в тяжелейшей форме, поэтому вместо sh и набора утилит они делают монстра systemd и набор условных команд. чтобы администраторам надо было знать И sh, И systemd. а раньше одного sh хватало.
	Ответить | Правка | ^ к родителю #222 | Наверх | Cообщить модератору

	331. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от vg. on 10-Апр-13, 11:11
	>> Зачем нужны тонны документации, если сам скрипт служит себе же самой полной документацией? > По опыту чтения таких скриптов - чаще всего он служит документацией по > теме "быдлокодинг на шелл, или как не надо писать скрипты инициализации". а никто и не обещал в этих скриптах примерных учебных пособий. с опытом, когда умеешь незадумаваясь читать разный по стилю и качеству код, уже понимаешь, что ранее отвратное - теперь просто особенность написания. ну а совсем уж ужасные или опасные места сам переписываешь с матюками и патчами - опенсурс же
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	128. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Michael Shigorin (ok) on 07-Апр-13, 20:39
	> Тонны документации - уже офигенно полезных выход. Это пока её не *приходится* читать от и до.  Скрипты в этом плане куда меньше претендуют на выедание мозга (если читатель не виндузятник рееструс вульгарис, а человек с пониманием шелла). > А в systemd каждый чих документирован, и про каждый чих делается подробная запись в логи. Вот только в реальной работе не помогает, а так почти не соврали, да.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	158. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 23:51
	> этом плане куда меньше претендуют на выедание мозга Это, знаете ли, очень от скрипта зависит. Пишут их разные люди. Хотя временами возникает ощущение что пишут эти скрипты таки не люди. А инопланетяне, укуренные бабуины и прочие тушканчики. Чисто глядя на тот код который там встречается. Где константы (при том верные только для системы автора) размазаны равномерным слоем по трехстраничной портянке и прочие подобные "прелести".
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	164. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+3 +/–
	Сообщение от angra (ok) on 08-Апр-13, 00:24
	Покажи на примере debian или rhel. В то что создатели маргинальных дистров могут придумать что угодно я и так верю, были же долбодятлы, которые все на php хотели переписать. Вообще большой размер отдельных инит-скриптов связан с нестандартными действиями и systemd здесь не поможет. Стандартные действия у debian и rhel уже оформлены в шелловые функции и писать свой собственный start-stop-daemon в большинстве случаев смысла нет.
	Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

	197. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 09:12
	> Покажи на примере debian или rhel. Начались виляния попой. Вот есть прога. Допустим в репах ее нет. Надо демон запустить. Обнаруживаем что там или совсем нет скрипта и надо самому писать. Или там есть черти-какой гогнокод, валидный только для системы автора. И так и сяк - много гемора. Написать 5 строк в конфиг - намного проще. И для более-менее типового процесса демона их будет выше крыши, все дела. > В то что создатели маргинальных дистров могут придумать что угодно я и так верю, > были же долбодятлы, которые все на php хотели переписать. Вообще-то гунявые скрипты встречались и просто в программах. Которые дебианщики или рхеловцы не удосужились запакетировать совсем. Ну или скриптов может вообще не быть. Спорный вопрос что лучше: гунявые скрипты или никаких вообще. > Стандартные действия у debian и rhel уже оформлены При том у каждых по своему.
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	221. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+8 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 10:59
	> Начались виляния попой. Вот есть прога. Допустим в репах ее нет. Надо > демон запустить. Обнаруживаем что там или совсем нет скрипта и надо > самому писать. Или там есть черти-какой гогнокод, валидный только для системы > автора. И так и сяк - много гемора. Написать 5 строк > в конфиг - намного проще. И для более-менее типового процесса демона > их будет выше крыши, все дела. Дело в том, что это еще нужно разобраться, кто "виляет попой". Вам предложили два основных подхода к реализации стартовых скрипов. Если этого мало, есть LSB. Со скриптами, оформленными в соответствии с LSB проблемы иногда наблюдаются только у "маргинальщиков", которые LSB не поддерживают. И да, если уж на то пошло, можно взять шаблон стартового скрипта и заменить в нем одну строчку - путь к программе. Если программа писалась в соответствии со стандартами - она запустится и будет работать. Если же автор программы - чудак, не желающий иметь ничего общего со стандартами, то systemd тут мало чем поможет, так как написать unit для такой программы может оказаться сложнее, чем стартовый скрипт - отладить его значительно сложнее. >> Стандартные действия у debian и rhel уже оформлены > При том у каждых по своему. Еще раз повторяю - в гугл по термину LSB (Linux Standard Base). А если автор не желает писать в соответствии со стандартами (яркий пример - Ваш любимый герой Поттеринг!), то тут ни systemd, ни оформление каких-то магических unit’ов в 5 строчек не поможет.
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	275. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+3 +/–
	Сообщение от kurokaze (ok) on 08-Апр-13, 21:59
	> Это, знаете ли, очень от скрипта зависит. Пишут их разные люди. Хотя > временами возникает ощущение что пишут эти скрипты таки не люди. А > инопланетяне, укуренные бабуины и прочие тушканчики. Что мешает "сказочнику" написать как надо и выложить? Если ты не можешь написать, то как ты можешь оценивать достоверно? Ну и если никто не улучшил, логично что это г никому кроме тебя не надо. А тут знаешь ли безотносительно из под чего это редкое глюкавое г у тебя будет запускаться. Так то
	Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

	277. "Разработчики systemd: загрузка с initrd оказалась..."	+1 +/–
	Сообщение от arisu (ok) on 08-Апр-13, 22:02
	> Что мешает «сказочнику» написать как надо и выложить? ну, иногда просто лень. «да, это надо бы переписать, и при вот таких вот обстоятельствах его заглючит, но… вот когда заглючит, тогда и перепишу. а пока пусть так ковыляет.» и оно годами так ковыляет.
	Ответить | Правка | ^ к родителю #275 | Наверх | Cообщить модератору

	328. "Разработчики systemd: загрузка с initrd оказалась..."	+2 +/–
	Сообщение от Ordu (ok) on 10-Апр-13, 09:24
	> вот когда заглючит, тогда и перепишу. Ситуация знакомая до боли. Но я не вижу чем systemd может помочь в данной ситуации. Разве что тем, что на systemd, потенциально, глюки полезут раньше. Синтаксис скриптов /bin/sh устоялся ещё во времена Наполеона или где-то около. А вот в устойчивость опций systemd мне не очень верится.
	Ответить | Правка | ^ к родителю #277 | Наверх | Cообщить модератору

	329. "Разработчики systemd: загрузка с initrd оказалась..."	+1 +/–
	Сообщение от arisu (ok) on 10-Апр-13, 09:33
	так и я о том же.
	Ответить | Правка | ^ к родителю #328 | Наверх | Cообщить модератору

	161. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от etw (ok) on 08-Апр-13, 00:13
	>> Тонны документации - уже офигенно полезных выход. > Это пока её не *приходится* читать от и до.  Скрипты в > этом плане куда меньше претендуют на выедание мозга (если читатель не > виндузятник рееструс вульгарис, а человек с пониманием шелла). А зачем мне перечитывать десятки реализаций обработки PID-файлов различной степени корявости на шелле, если в системд это делается одной строкой в конфиге, которая везде работает одинаково и эта работа описана в мане?
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	165. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от angra (ok) on 08-Апр-13, 00:26
	В debian/rhel это тоже делается одной строкой. Вот только при желании вы можете прочитать что стоит за этой строкой имея знания только шелл.
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	170. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Michael Shigorin (ok) on 08-Апр-13, 00:34
	> В debian/rhel это тоже делается одной строкой. Вот только при желании вы > можете прочитать что стоит за этой строкой имея знания только шелл. В альте скомбинировано (т.е. rh-style в целом, но с применением start-stop-daemon).
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	260. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–2 +/–
	Сообщение от etw (??) on 08-Апр-13, 20:43
	> В debian/rhel это тоже делается одной строкой. Вот только при желании вы > можете прочитать что стоит за этой строкой имея знания только шелл. То, что в debian и rhel есть готовые функции для стандартных действий (кстати, часто в их реализации залезаешь?) не отменяет наличия кучи инит-скриптов, авторы которых решили изобрести велосипед.
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	264. "Разработчики systemd: загрузка с initrd оказалась..."	+3 +/–
	Сообщение от arisu (ok) on 08-Апр-13, 21:20
	то, что в libc есть готовые функции для стандартных действий (кстати, часто в их реализации залезаешь?) не отменяет наличия кучи сишнософта, авторы которого решили изобрести велосипед. поэтому — по твоей же логике — си следует выкинуть подальше, и вместо него сделать язык, у коготорого пять команд — разные варианты вывода приветмира, а шестая — вызов внешней программы на древнем си, когда приветмиров не хватило. и этот язык должен стать основным языком разработки системного софта. если до тебя и в таком виде не дошло, то ты безнадёжен.
	Ответить | Правка | ^ к родителю #260 | Наверх | Cообщить модератору

	334. "Разработчики systemd: загрузка с initrd оказалась..."	–1 +/–
	Сообщение от etw (ok) on 10-Апр-13, 11:45
	> то, что в libc есть готовые функции для стандартных действий (кстати, часто > в их реализации залезаешь?) не отменяет наличия кучи сишнософта, авторы которого > решили изобрести велосипед. Много ли сишных программ, в которых используются свой аллокатор вместо malloc просто потому, что автор не знал о его существовании? Мне так не кажется. А вот в инит-скриптах подобное излишнее велосипедостроение на каждом шагу. > поэтому — по твоей же логике — си следует выкинуть подальше, и > вместо него сделать язык, у коготорого пять команд — разные варианты > вывода приветмира, а шестая — вызов внешней программы на древнем си, > когда приветмиров не хватило. и этот язык должен стать основным языком > разработки системного софта. Твою аналогию можно было бы принять, если бы 99% используемых сишных программ только бы и делали, что выводили "Привет мир". Однако, это не так.
	Ответить | Правка | ^ к родителю #264 | Наверх | Cообщить модератору

	335. "Разработчики systemd: загрузка с initrd оказалась..."	+1 +/–
	Сообщение от arisu (ok) on 10-Апр-13, 12:08
	есть информация о том, что 99% инит-скриптов именно «выводят приветмир»? где почитать исследование? я даже не буду при этом требовать, чтобы там всенепременно были велосипеды, потому что авторы не знают про стандартные библиотеки функций для инит-скриптов, которые в дистрибутивах таки есть. и не буду требовать доказательств того, что авторы именно не знали о. давай начнём с доказательства первого утверждения, остальное потом.
	Ответить | Правка | ^ к родителю #334 | Наверх | Cообщить модератору

	343. "Разработчики systemd: загрузка с initrd оказалась..."	–2 +/–
	Сообщение от etw (ok) on 10-Апр-13, 23:27
	> есть информация о том, что 99% инит-скриптов именно «выводят приветмир»? где > почитать исследование? Просто феерично. Сначала ты говоришь о том, что замена инит-скриптов, выполняющих запуск/останов демонов в большиснтве случаев по одной той же схеме, на конфиги равнозначна замене универсального языка Си на язык, только и могущий, что выводить "привет мир", что уже является бредом. А когда я тебе указала на некорректность сравнения однообразных инит-скриптов и разнообразных программ, написанных на Си, то почему-то высплыла необходимость доказательства только что рожденного твоим нездоровым разумом утверждения о том, что 99% инит-скриптов выводят "привет мир". До каких пор ты собираешься нести бред?
	Ответить | Правка | ^ к родителю #335 | Наверх | Cообщить модератору

	340. "Разработчики systemd: загрузка с initrd оказалась..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 10-Апр-13, 14:09
	> Много ли сишных программ, в которых используются свой аллокатор вместо malloc > просто потому, что автор не знал о его существовании? Трудоёмкость выполнения выберите всё-таки сопоставимую, проводя аналогию.
	Ответить | Правка | ^ к родителю #334 | Наверх | Cообщить модератору

	345. "Разработчики systemd: загрузка с initrd оказалась..."	–1 +/–
	Сообщение от etw (ok) on 10-Апр-13, 23:32
	>> Много ли сишных программ, в которых используются свой аллокатор вместо malloc >> просто потому, что автор не знал о его существовании? > Трудоёмкость выполнения выберите всё-таки сопоставимую, проводя аналогию. Аналогия моего оппонета "специализированные скрипты - произвольные программы" изначально является бредом и развивать ее я не собираюсь.
	Ответить | Правка | ^ к родителю #340 | Наверх | Cообщить модератору

	308. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 09-Апр-13, 23:20
	>>> Тонны документации - уже офигенно полезных выход. >> Это пока её не *приходится* читать от и до.  Скрипты в >> этом плане куда меньше претендуют на выедание мозга (если читатель не >> виндузятник рееструс вульгарис, а человек с пониманием шелла). > А зачем мне перечитывать десятки реализаций обработки PID-файлов различной степени корявости > на шелле, если в системд это делается одной строкой в конфиге, > которая везде работает одинаково и эта работа описана в мане? Не могу понять, о чём вообще спор. Есть несколько ситуаций, которые, похоже, перемешались в голове у спорящих: 1) Установили софтину, надо стартануть. Если при установке мы не получили уведомлений о том, что надо что-то особенное сделать - правим конфиг (если надо; документацию по самой софтине ведь читать в любом случае надо, правильно?) и стартуем - для этого у нас и скрипт/юнит. Разницы между systemd и прочим на этом этапе НЕТ. 2) Софтина таки не стартует. В случае rc-скриптов читаем ошибки на stderr (возможно, запуская заново с какой-нибудь волшебной опцией - тут согласен, неудобно, ибо ошибка может быть не постоянно возникающей) и смотрим в логи любой удобной программой. В случае systemd - смотрим в логи, ибо больше особо ничего не светит. Причём смотрим только теми средствами, которые systemd нам даёт - спасибо дяде Поттерингу за бинарную свободу выбора. 3) Нам надо написать собственно скрипт/юнит для запуска. Тут всё зависит от конкретного случая - некоторые системы rc-скриптов просты, некоторые не очень. Зато и отлаживать rc-скрипты заметно проще. Плюс: вменяемый админ в любом случае умеет управляться с шеллом, а, следовательно, в случае rc-скриптов не приходится изучать лишний (именно лишний!) декларативный язык. В общем, преимуществ у systemd именно по части запуска сервисов - только _возможность_ их асинхронного запуска, с сомнительным преимуществом в лишние несколько секунд аптайма. Про остальные особенности systemd я лучше промолчу...
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	344. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от etw (ok) on 10-Апр-13, 23:31
	> В случае systemd - смотрим в логи, ибо > больше особо ничего не светит. Systemd перенаправляет stderr в syslog/journald, при этом еще и показывая кусок, имеющий отношение к демону, при вызове systemctl status daemon.service
	Ответить | Правка | ^ к родителю #308 | Наверх | Cообщить модератору

	357. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от c0smonaut (ok) on 11-Апр-13, 21:45
	> Особенно по сравнению со всякими SysV init и OpenRC, где чтобы понять назначение скрипта, необходимо читать его код. А в systemd каждый чих документирован, и про каждый чих делается подробная запись в логи ...аноним английский осилил, а юникс-шелл - нет...
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

3. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+28 +/–
Сообщение от Nxx (ok) on 07-Апр-13, 09:11
Тоже думаю, что давно надо было включить Qt в systemd.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
Сообщение от Константавр (ok) on 07-Апр-13, 09:38
>В ходе работ по улучшению поддержки системного менеджера systemd.... загрузка с initrd оказалась быстрее загрузки без initrd А потом, в ходе работ по улучшению, они поймут, что набор отдельных скриптов на баше делает процесс загрузки более быстрым, гибким и настраиваемым. Да. Это вброс.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–2 +/–
	Сообщение от GotF (ok) on 07-Апр-13, 09:52
	> набор отдельных скриптов на баше За bash в init-скриптах нужно бить тяжёлым тупым предметом по голове, особенно когда файл начинается с «#!/bin/sh».
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Константавр (ok) on 07-Апр-13, 09:56
	хе-хе! Один попался :)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 09:57
	> особенно когда файл начинается с «#!/bin/sh». А когда он начинается с «#!/sbin/runscript»?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	17. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от GotF (ok) on 07-Апр-13, 11:35
	>> особенно когда файл начинается с «#!/bin/sh». > А когда он начинается с «#!/sbin/runscript»? Не знаю. Ни в Debian, ни в RHEL такой команды нет.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	74. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:28
	>>> особенно когда файл начинается с «#!/bin/sh». >> А когда он начинается с «#!/sbin/runscript»? > Не знаю. Ни в Debian, ни в RHEL такой команды нет. Да, это местечковый велосипед :)
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	12. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от sasku (ok) on 07-Апр-13, 10:57
	> особенно когда файл начинается с «#!/bin/sh». согласен, раз нарвался на проблему: сидел на центоси, там /bin/sh вызывал /bin/bash перешел на демьяна и вдруг все мои инит-скрипты перестали работать ( оказалось в демьяне /bin/sh вызывает /bin/dash (Debian Almquist Shell (dash))
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	95. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от anonymous (??) on 07-Апр-13, 17:18
	Ну и кто в итоге дураком остался?
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	99. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+6 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 17:32
	> Ну и кто в итоге дураком остался? Поттеринг, конечно же.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	163. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от etw (ok) on 08-Апр-13, 00:17
	>> особенно когда файл начинается с «#!/bin/sh». > согласен, раз нарвался на проблему: > сидел на центоси, там /bin/sh вызывал /bin/bash > перешел на демьяна и вдруг все мои инит-скрипты перестали работать ( > оказалось в демьяне /bin/sh вызывает /bin/dash (Debian Almquist Shell (dash)) Обычно правильные инит-скрипты сразу завязаны на какой-нибудь свой дистрибутивоспецифичный /etc/init.d/functions (куда вынесена часто используемая функциональность) и непортабельны оп определению, даже если шелл тот же самый.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	171. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Michael Shigorin (ok) on 08-Апр-13, 00:37
	> и непортабельны оп определению Отчасти это так, поскольку в разных дистрибутивах по-разному смотрят на задачи конфигурирования и зачастую это имеет под собой основания.  Вот только "как ни садитесь"...
	Ответить | Правка | ^ к родителю #163 | Наверх | Cообщить модератору

	192. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 08:46
	> и зачастую это имеет под собой основания.   А потом берешь с сайта авторов программу которой в репе не было или версия не та или что там еще. Там вроде как есть скрипт. Чпокс - не работает. Чпокс - там гогнокод. Чпокс - вагон допущений о системе, взятые из системы автора и размазанные по всей портянке. Получается что "висит груша - нельзя скушать". Во, блин, счастье - самому с нуля переписывать портянку или три страницы чужого гогнокода лопатить. Супротив конфига на пяток строк - разница совсем не в пользу портянки получается.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	286. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Пр0х0жий (??) on 09-Апр-13, 05:14
	Может пнуть его для начала через 'dpkg-reconfigure dash'? Или как там в Дебианах? RTFM же... Однако ж и в #171 посмотреть.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	292. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–2 +/–
	Сообщение от qux (ok) on 09-Апр-13, 13:52
	Для начала, если для неинтерактивного шелла выбран dash, то наверное это зачем-то нужно. Лично /me тут совсем больших выгод не знает, но встряхнуть любителей использовать башизмы вместе с /bin/sh вещь неплохая. Хоть и поотваливалось кое-где ой...
	Ответить | Правка | ^ к родителю #286 | Наверх | Cообщить модератору

	13. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+9 +/–
	Сообщение от anonymous (??) on 07-Апр-13, 11:06
	Туым предметом надо бить тех, кто не осознает, что /bin/sh не обязан равняться /bin/bash.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	56. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 15:49
	> Туым предметом надо бить тех, кто не осознает, что /bin/sh не обязан > равняться /bin/bash. sysvinit-проблемы :)
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	69. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:15
	>> Туым предметом надо бить тех, кто не осознает, что /bin/sh не обязан >> равняться /bin/bash. > sysvinit-проблемы :) Да нет, проблемы "программеров", которые сначала чего-нибудь накодят, а потом говорят - "Да зачем нужны эти ваши стандарты?! Теперь будет вот так, я переписывать свою писанину ради сответствия стандартам не буду!" Но в случае sysvinit эта проблема решается правкой одной-двух строчек. А вот в случае systemd - это генетическая проблема, не имеющая, как правило, простого и однозначного решения.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	78. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:35
	> Да нет, проблемы "программеров", которые сначала чего-нибудь накодят, а потом говорят - > "Да зачем нужны эти ваши стандарты?! Теперь будет вот так, я > переписывать свою писанину ради сответствия стандартам не буду!" > Но в случае sysvinit эта проблема решается правкой одной-двух строчек. Не подскажете, как правкой одной-двух строчек заставить произвольно выбранный init-скрипт запускаться на любом дистрибутиве?
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	109. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 19:22
	> запускаться на любом дистрибутиве? Никак. Более того - половина долбоклюев пишет эти портянки по принципу "у меня же работает?!". Да еще перемешав пути с логикой и прочая. Чинить за ними такой крап - на редкость отвратное занятие.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	129. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от GotF (ok) on 07-Апр-13, 20:41
	> Не подскажете, как правкой одной-двух строчек заставить произвольно выбранный init-скрипт запускаться на любом дистрибутиве? Если скрипт и дистрибутив LSB-совместимые, то особых проблем быть не должно. В иных случаях проще будет написать с нуля.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	166. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от etw (ok) on 08-Апр-13, 00:26
	>> Не подскажете, как правкой одной-двух строчек заставить произвольно выбранный init-скрипт запускаться на любом дистрибутиве? > Если скрипт и дистрибутив LSB-совместимые, то особых проблем быть не должно. В > иных случаях проще будет написать с нуля. Ага. До первого "source /lib/lsb/init-functions", который, как оказывается, в дебиане не тот же самый, что и в centos. Вот и переписывают с нуля. И зачем, спрашивается?
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	44. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 07-Апр-13, 15:19
	> А потом, в ходе работ по улучшению, они поймут, что набор отдельных > скриптов на баше делает процесс загрузки более быстрым, гибким и настраиваемым.   > скриптов на баше > быстрым /0
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	130. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 07-Апр-13, 20:44
	>> скриптов на баше >> быстрым > /0 Почитайте скрипты {ldv,legion}@altlinux и поучитесь писать без лишних форков.  Естественно, если вместо read var < file использовать var=`cat file` (вот так, без кавычек даже) -- тормозить будет как детский трактор. Младотурки, блин.  Даже на ноль делить в школе не научились.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	159. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 23:55
	> Почитайте скрипты {ldv,legion}@altlinux и поучитесь писать без лишних форков.   Я вот почитал факин ман на апстарт и научился писать ему джобы. Теперь оно и процессы перезапускает, и приоритет им ставит, и под нужным юзером пинает, etc, etc, etc. По нужным событиям и без лишних форков. И всего пяток строчек конфига на все про все. Вот это - хорошее соотношение efforts/results. Куда лучше упомянутых портянок на мое нескромное мнение. А если вдруг этого окажется мало - вот тогда уже и будем звать скриптопортянки. Только это надо в хорошо если 1% случаев.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

8. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–2 +/–
Сообщение от Аноним (??) on 07-Апр-13, 10:27
"Если программисты настолько незрелые, то их поделиям нечего делать на моих системах" - ЛОР шагает ИРЛ.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+5 +/–
Сообщение от Аноним (??) on 07-Апр-13, 10:52
Разработчики initrd: загрузка  без systemd оказалась быстрее загрузки с systemd
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 11:29
	через 10 лет, Леннарт научиться писать интерпретаторы и напишет свой баш и перепишет все на него.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	121. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–2 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 20:10
	Он command.com свой напишет, после чего в autoexec.bat можно будет положить скрипт инициализации.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	45. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–3 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 15:21
	> Разработчики initrd: загрузка  без systemd оказалась быстрее загрузки с systemd А что, разработчики initrd и разработчики systemd - разве не одно и то же?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	131. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Michael Shigorin (ok) on 07-Апр-13, 20:45
	>> Разработчики initrd: загрузка  без systemd оказалась быстрее загрузки с systemd > А что, разработчики initrd и разработчики systemd - разве не одно и то же? "Разработчики initrd" -- в общем случае некорректный термин (для опровержения предлагаю попробовать его точно определить).
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	186. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 07:15
	> А что, разработчики initrd и разработчики systemd - разве не одно и то же? Initrd был задолго до systemd. Такая вот неожиданность.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

14. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–3 +/–
Сообщение от Fracta1L (ok) on 07-Апр-13, 11:15
Дано: Gentoo & OpenRC Делаем: rc-update del xdm default && rc-update add xdm boot Итого: от граба до KDM проходит 2-3 секунды, systemd сосёт :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	41. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 15:06
	> Дано: Gentoo & OpenRC > Делаем: rc-update del xdm default && rc-update add xdm boot > Итого: от граба до KDM проходит 2-3 секунды, systemd сoсёт А если отключить OpenRC и оставить SysV init, будет грузиться еще быстрее :) (OpenRC не умеет в параллельную загрузку, а SysV умеет)
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	71. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+3 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:22
	> А если отключить OpenRC и оставить SysV init, будет грузиться еще быстрее :) > (OpenRC не умеет в параллельную загрузку, а SysV умеет) Вообще-то, OpenRC - это просто избыточная прослойка над SysV init. Когда-то, когда SysVinit не умел параллельной загрузки, поверх него придумали OpenRC, в котором планировалось реализовать эту функциональность. Прошло несколько лет. SysVinit научился грузиться параллельно (чем активно пользуется дебиан), а OpenRC до сих пор зависает при включении rc_parallel=yes.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	85. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:49
	> Прошло несколько лет. SysVinit научился грузиться параллельно (чем активно пользуется > дебиан), а OpenRC до сих пор зависает при включении rc_parallel=yes. А держится он в генте только потому, что так хочет один конкретный человек - Luca Barbato. Ничем не лучше поцтеринга, кстати. Поэтому, когда тру-гентушники выступают против systemd - это смотрится довольно забавно :)
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	92. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от anonymous (??) on 07-Апр-13, 17:10
	>> Прошло несколько лет. SysVinit научился грузиться параллельно (чем активно пользуется >> дебиан), а OpenRC до сих пор зависает при включении rc_parallel=yes. > А держится он в генте только потому, что так хочет один конкретный > человек - Luca Barbato. Ничем не лучше поцтеринга, кстати. > Поэтому, когда тру-гентушники выступают против systemd - это смотрится довольно забавно > :) Gentoo вообще становится просто идиотским дистрибутивом. Все, что могу, перевожу потихоньку на дебиан. Hardened вот жалко, хорошее направление... Но вообще когда на ноуте с e-350 aptitude быстрее работает и меньше грузит проц, чем emerge на 8-ми ядернике, это о чем-то говорит. То они конфетки поцтеринг и ко дарят, то обновлении внезапно прилетает куча ненужной ерунды...
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	97. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 07-Апр-13, 17:21
	> Gentoo вообще становится просто идиотским дистрибутивом. Все, что могу, перевожу потихоньку > на дебиан. Hardened вот жалко, хорошее направление... > Но вообще когда на ноуте с e-350 aptitude быстрее работает и меньше > грузит проц, чем emerge на 8-ми ядернике, это о чем-то говорит. Просто изначально Gentoo создавали технари, со своими хорошим технарскими идеями. Но создать мало, надо еще поддерживать и допиливать. Но те технари уже ушли, остались одни филологи, которые занимаются косметической правкой второстепенных bash-скриптов, считая это крутым линукс-хацкерством. > То они конфетки поцтеринг и ко дарят Ну конфетки они дарили когда извинялись. После того, как они сначала громко кричали о "регрессиях" в udev, а потом их "исправленный" вариант оказался на порядок хуже исходного (фиговые кодеры из гуманитариев, да) - извинения были единственным способом сохранить лицо. За умение признать свои ошибки их нельзя не уважать.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	188. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 08-Апр-13, 07:54
	> А держится он в генте только потому, что так хочет один конкретный > человек - Luca Barbato. Ничем не лучше поцтеринга, кстати. "Свое г-но не пахнет" (народная мудрость).
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	112. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от alexxy (ok) on 07-Апр-13, 19:29
	Зато openrc работает и на embedded и на отличных от linux OS, в отличии от systemd. Проблем с параллельным запуском я как то не видел последние пару лет в openrc.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	224. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 08-Апр-13, 11:09
	> Зато openrc работает и на embedded На embedded работает все то же самое что и везде. И конкретно openrc никому там нафиг не упал.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	169. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от etw (ok) on 08-Апр-13, 00:33
	>> Дано: Gentoo & OpenRC >> Делаем: rc-update del xdm default && rc-update add xdm boot >> Итого: от граба до KDM проходит 2-3 секунды, systemd сoсёт > А если отключить OpenRC и оставить SysV init, будет грузиться еще быстрее > :) > (OpenRC не умеет в параллельную загрузку, а SysV умеет) SysV уже ничего не умеет, потому что эта ОС померла. Также нет стандартного и единого sysvinit-а - каждый дистрибутив пишет свой велосипед в sysv-стиле (или в bsd-стиле, но все равно СВОЙ). В дебиане используется свой местечковый sysv-style init, поверх которого водружен insserv, помогающий разрешать зависимости. Но от этого параллельная загрузка в остальных дистрибутивах с их собственными sysv-style init системами не появляется.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

18. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–3 +/–
Сообщение от виндотролль (ok) on 07-Апр-13, 11:37
Начал читать новость, тут же возникла мысль, что разработчики системд готовят себе почву, так сказать. И действительно > Стоит отметить, что в обсуждении один из разработчиков приводит довольно простой патч, который теоретически должен исправить эту проблему, путем перевода данной операции в ядре на асинхронный режим. Начало systemd/linux (или GNU/systemd ?) положено.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	77. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:33
	> Начало systemd/linux (или GNU/systemd ?) положено. Еще в позапрошлом году в ядро приняли леннартовский патч, перекраивающий работу планировщика задач. Кстати, нынче фичами этого патча пользуется не только systemd, но и upstart.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

19. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+4 +/–
Сообщение от ip1981 (ok) on 07-Апр-13, 12:38
Показывать текст по видео - это пипец.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 13:39
	В духе поттеринговщины, чо.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

20. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
Сообщение от Buy (ok) on 07-Апр-13, 12:58
Дожились, systemd тормозит без initrd.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	38. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 15:02
	Почему? Это ядро без initrd тормозит.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	70. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+9 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:17
	> Почему? Это ядро без initrd тормозит. Тормозит-то ядро, а виноват-то systemd. Он вообще во всем виноват. И воду в кране тоже он выпил.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	88. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:52
	> И воду в кране тоже он выпил. Хотя нет, воду выпил Поцтеринг.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	90. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 17:05
	> Хотя нет, воду выпил Поцтеринг. Нет, редхат. Без него линукс уже давно занимал бы 146% десктопов.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	101. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Stax (ok) on 07-Апр-13, 17:52
	Ну а с ним убунта заняла эти 146%.. Конечно, если бы занял линукс, было бы лучше, но и так неплохо вышло.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	117. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–2 +/–
	Сообщение от бубунавт on 07-Апр-13, 19:50
	Чего? Сколько там убунта заняла десктопов? Чьих десктопов? А линукс сколько всего занял десктопов? :)) Уверен, никто ни у кого ничего не занимал, всё осталось как и было ;)
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	190. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 08:37
	> Чего? Сколько там убунта заняла десктопов? На данный момент - более 11 миллионов вроде как. > Чьих десктопов? Например, моих.
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	113. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от alexxy (ok) on 07-Апр-13, 19:31
	> Почему? Это ядро без initrd тормозит. Ну удивитесь наверное, но в ядре initramfs есть всегда, просто если на нем не находят /init или /bin/init или /sbin/init то происходит поиск корня механизмами ядра, что может занять время. Если initramfs есть то выполняется инит от туда
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	191. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 08-Апр-13, 08:40
	> Ну удивитесь наверное, но в ядре initramfs есть всегда, Возможен и вариант загрузки ядра совсем без начального рамдиска. Кстати сие отвечает на вопрос - почему на allwinner'ской вундервафле ядро несколько секунд тупит. Оно у меня как раз без рамдиска взлетает. Как ни странно, в ARMовой убунте...
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	227. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Buy (ok) on 08-Апр-13, 12:21
	У меня нету. За ненадобностью.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

23. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+4 +/–
Сообщение от Адекват on 07-Апр-13, 13:20
Наверное идея о том. что не следовало так анально заменять sysvinit на systemd, а для начала протестировать 2-3 года на добровольцах, отловив все глюки, выяснив узкие места, оптимизировать код и подготовить полностью готовую модель для каждого дистрибутива, внедряя, сохраняя старые системы инициализации, демонстрируя явные приимущества systemd перед прочими системами инициализации, спрашивая мнение сообщества "готовы ли вы отказаться от старой системы инициализации", и получив ответ "да готовы !!", ввиду того что systemd действительно рвет все прочие системы иницализации по всем фронтам - это идея быдло-дегенерата, больного шизофренией, болезнью паркинсона, а еще являющегося эталоном ретроградности. ДА ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	57. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–2 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 15:53
	> Наверное идея о том. что не следовало так анально заменять sysvinit на > systemd, а для начала протестировать 2-3 года на добровольцах, отловив все > глюки, выяснив узкие места, оптимизировать код и подготовить полностью готовую модель > для каждого дистрибутива, внедряя, сохраняя старые системы инициализации, демонстрируя > явные приимущества systemd перед прочими системами инициализации, спрашивая мнение сообщества > "готовы ли вы отказаться от старой системы инициализации", и получив ответ > "да готовы !!", ввиду того что systemd действительно рвет все прочие > системы иницализации по всем фронтам - это идея быдло-дегенерата, больного шизофренией, > болезнью паркинсона, а еще являющегося эталоном ретроградности. > ДА ? Медленное и аккуратное внедрение бывает только в промышленных дистрах и всяких дебианах. Все остальные в большей или меньшей степени являются bleeding edge, и предпочитают решать проблемы по возможности быстрее. Выбирайте тот дистрибутив, который действительно вам подходит, и таких проблем не будет.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	134. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Michael Shigorin (ok) on 07-Апр-13, 20:48
	> Все остальные в большей или меньшей степени являются bleeding edge, и > предпочитают решать проблемы по возможности быстрее. Решать или создавать?  Вчера одной юной бездари на пальцах уже пытался баланс пояснить.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	172. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–2 +/–
	Сообщение от etw (ok) on 08-Апр-13, 00:39
	> Наверное идея о том. что не следовало так анально заменять sysvinit на > systemd, а для начала протестировать 2-3 года на добровольцах, отловив все > глюки, выяснив узкие места, оптимизировать код и подготовить полностью готовую модель > для каждого дистрибутива, внедряя, сохраняя старые системы инициализации, демонстрируя > явные приимущества systemd перед прочими системами инициализации, спрашивая мнение сообщества > "готовы ли вы отказаться от старой системы инициализации", и получив ответ > "да готовы !!", ввиду того что systemd действительно рвет все прочие > системы иницализации по всем фронтам - это идея быдло-дегенерата, больного шизофренией, > болезнью паркинсона, а еще являющегося эталоном ретроградности. > ДА ? Парочка вопросов на засыпку. Дано: все известные критические проблемы в багтрекере, которые могут блокировать выпуск, закрыты, производительность выше, чем была до этого и уже год-полтора добровольцы вовсю ставят этот софт и используют. Внимание, вопросы: - Остались ли баги в софте? - Через какой время ограниченного тестирования на добровольцах можно быть уверенным, что отловлены все баги и оптимизировано все, что можно? - В каких нетестовых дистрибутивах сейчас есть по-умолчанию systemd?
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	184. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Адекват on 08-Апр-13, 07:03
	> Внимание, вопросы: >  - Остались ли баги в софте? >  - Через какой время ограниченного тестирования на добровольцах можно быть уверенным, > что отловлены все баги и оптимизировано все, что можно? >  - В каких нетестовых дистрибутивах сейчас есть по-умолчанию systemd? Это все вопросы к ментейнерам, баги конечно остались, с вероятностью от .. скажем 40% до 5%, в зависимости насколько усердно их отлавливали. После того как, по мнению разработчиков, количество багов сведено к минимому - данный продукт нужно выкладывать в тестовые ветки репозитариев. После того как тестовый systemd начинает расползаться по компам добровольцев - начинают всплывать новые баги, так как повышается разнообразие конфигураций железа компьютеров у пользователя. Они натаклкиваются на баги, пишут багрепорты, баги фиксятся. После того, как кол-во сообщений о найденых багах сводится к минимому в абстрактную единицу времени - можно выкладывать systemd в стабильные ветки репозитариев, сохраняя при этом старую систему инициализации. Тестовых и нетестовых дистрибутивов нет, или я не знаю такие - есть тестовые ветки репозитариев. По умолчанию systemd в моем ArchLinux, к слову сказать из него ушло более одного ментейнера, по причине того что отказались от sysvinit в пользу systemd.
	Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

	262. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от etw (ok) on 08-Апр-13, 21:04
	>[оверквотинг удален] >>  - В каких нетестовых дистрибутивах сейчас есть по-умолчанию systemd? > Это все вопросы к ментейнерам, баги конечно остались, с вероятностью от .. > скажем 40% до 5%, в зависимости насколько усердно их отлавливали. > После того как, по мнению разработчиков, количество багов сведено к минимому - > данный продукт нужно выкладывать в тестовые ветки репозитариев. После того как > тестовый systemd начинает расползаться по компам добровольцев - начинают всплывать новые > баги, так как повышается разнообразие конфигураций железа компьютеров у пользователя. > Они натаклкиваются на баги, пишут багрепорты, баги фиксятся. После того, как > кол-во сообщений о найденых багах сводится к минимому в абстрактную единицу > времени - можно выкладывать systemd в стабильные ветки репозитариев, ты не поверишь, но именно так и делается. С открытыми критичными багами никто даже релиз не будет формировать. Потом новый софт уходит в тестовую ветку дистрибутива (в федоре - rawhide, в opensuse - factory), где проверяется добровольцами. И лишь затем, после того, как убедятся, что софт таки не содержит критичным багов, его либо кладут в текущий релиз (если это минорное обновление системного софта или мажорное - прикладного), либо откладывают до следующего релиза. По крайней мере так делается в приличных десктопных дистрибутивах. Как в вашем арче заведено, я не знаю. > сохраняя при > этом старую систему инициализации. старые init-скрипты в systemd до сих пор работают. во время переходного периода в приличных дистрибутивах, опять же, была возможность использовать старую init-систему. Но бесконечно поддерживать legacy на протяжении долгого времени ничто не будет, конечно. Один-два релиза и все. А если в отдельных дистрибутивах майнтенеры мудаки и отдают пользователям софт без какого-либо QA, то это, извините, уже не Поттеринг виноват.
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

	297. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Michael Shigorin (ok) on 09-Апр-13, 19:18
	> С открытыми критичными багами никто даже релиз не будет формировать. Вот это новость, прям прошлым веком повеяло.
	Ответить | Правка | ^ к родителю #262 | Наверх | Cообщить модератору

	347. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от etw (ok) on 11-Апр-13, 00:08
	>> С открытыми критичными багами никто даже релиз не будет формировать. > Вот это новость, прям прошлым веком повеяло. При чем тут прошлый век?
	Ответить | Правка | ^ к родителю #297 | Наверх | Cообщить модератору

	349. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 11-Апр-13, 01:56
	>>> С открытыми критичными багами никто даже релиз не будет формировать. >> Вот это новость, прям прошлым веком повеяло. > При чем тут прошлый век? При гонке за time to market, которая тогда ещё не допрогрессировала до того, что наблюдаем ныне. Ну и трава была зеленей, понятное дело.
	Ответить | Правка | ^ к родителю #347 | Наверх | Cообщить модератору

	353. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от etw (ok) on 11-Апр-13, 11:41
	>>>> С открытыми критичными багами никто даже релиз не будет формировать. >>> Вот это новость, прям прошлым веком повеяло. >> При чем тут прошлый век? > При гонке за time to market, которая тогда ещё не допрогрессировала до > того, что наблюдаем ныне. При гонке за time to market увеличивают частоту релизов и используют различные agile-техники разработки в команде, но не начинают игнорировать баги.
	Ответить | Правка | ^ к родителю #349 | Наверх | Cообщить модератору

	356. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 11-Апр-13, 18:37
	> При гонке за time to market увеличивают частоту релизов Да. > и используют различные agile-техники разработки в команде Да. > но не начинают игнорировать баги. И их тоже, потому как запыхиваясь над релизами и закопавшись по уши в юзерсторисы -- как ни странно, всё равно всего не сделаешь. Вы же понимаете, что требовать от двух женщин ребёнка через три месяца -- это гонка, а не оптимизация?..
	Ответить | Правка | ^ к родителю #353 | Наверх | Cообщить модератору

	358. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–2 +/–
	Сообщение от etw (ok) on 12-Апр-13, 03:51
	>> При гонке за time to market увеличивают частоту релизов > Да. >> и используют различные agile-техники разработки в команде > Да. >> но не начинают игнорировать баги. > И их тоже, потому как запыхиваясь над релизами и закопавшись по уши > в юзерсторисы -- как ни странно, всё равно всего не сделаешь. > Вы же понимаете, что требовать от двух женщин ребёнка через три месяца > -- это гонка, а не оптимизация?.. Вообще-то, большинство agile-подходов оринтированы именно на поддержание постоянной скорости работы в течение долгого времени и поставку качественного кода. Потому при нормально поставленной работе за релизами никто не бежит (да и зачем бежать если они и так часто выходят?) и баги также не игнорируются, ибо приоритетнее фич. Разумеется, можно все испоганить и поставить с ног на голову, но ценность качественного кода и вред гонки со временем на истощение - это одни из основных идей.
	Ответить | Правка | ^ к родителю #356 | Наверх | Cообщить модератору

	359. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Michael Shigorin (ok) on 13-Апр-13, 15:32
	>>> При гонке за time to market [...] используют различные agile-техники >> это гонка, а не оптимизация > Вообще-то, большинство agile-подходов оринтированы Я о том, что если ttm ставить во главу угла, а разум свой отодвинуть и к чужому тоже не прислушиваться -- то получается именно гонка и дальше любые достоинства любых подходов идут лесом, потому что рано или поздно начнётся истерика вида "уже три месяца на исходе, где ребёнок?!". Ну нет в разработке серебряной пули, с самыми лучшими инструментами и методологиями надо начинать с целей, людей и взаимопонимания.
	Ответить | Правка | ^ к родителю #358 | Наверх | Cообщить модератору

	360. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от etw (ok) on 14-Апр-13, 21:19
	>>>> При гонке за time to market [...] используют различные agile-техники >>> это гонка, а не оптимизация >> Вообще-то, большинство agile-подходов оринтированы > Я о том, что если ttm ставить во главу угла, а разум > свой отодвинуть и к чужому тоже не прислушиваться -- то получается > именно гонка и дальше любые достоинства любых подходов идут лесом, потому > что рано или поздно начнётся истерика вида "уже три месяца на > исходе, где ребёнок?!". > Ну нет в разработке серебряной пули, с самыми лучшими инструментами и методологиями > надо начинать с целей, людей и взаимопонимания. Так при чему тут тогда прошлый век? Нормально поставленный процесс разработки и сейчас не редок. И в прошлом веке бардак тоже в некоторых компаниях был.
	Ответить | Правка | ^ к родителю #359 | Наверх | Cообщить модератору

	361. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Michael Shigorin (ok) on 15-Апр-13, 02:11
	> Так при чему тут тогда прошлый век? При степени гоночности.
	Ответить | Правка | ^ к родителю #360 | Наверх | Cообщить модератору

	351. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от бедный буратино (ok) on 11-Апр-13, 07:42
	>> С открытыми критичными багами никто даже релиз не будет формировать. > Вот это новость, прям прошлым веком повеяло. Чем именно? Windows 95? Играми Daggerfall, Reunion, X-com?
	Ответить | Правка | ^ к родителю #297 | Наверх | Cообщить модератору

25. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
Сообщение от Аноним (??) on 07-Апр-13, 13:44
А какие у systemd недостатки что его все так не любят?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	26. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–8 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 13:51
	Только один - монструозный комбайн.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	39. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 15:03
	> Только один - монструозный комбайн. По сравнению с любым монолитным ядром меркнут все юзерспейсовские комбайны.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	81. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:40
	> Только один - монструозный комбайн. Это systemd-то комбайн? Вы еще coreutils не видели. Вот это - всем комбайнам комбайн! В один проект запихнуто куча программ совершенно разного назначения - кодирование base64, расчет хеш-сумм, изменение приоритета процесса, сортировка текста, смена владельца файла, вывод текущей даты и т.п.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	153. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от develop7 (ok) on 07-Апр-13, 23:11
	Поскольку coreutils писаны а) давно и б) не Поттерингом, Это Совсем Другое Дело.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	167. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Michael Shigorin (ok) on 08-Апр-13, 00:26
	> Поскольку coreutils писаны а) давно и в) ранее это были fileutils, textutils и кто-то ещё третий.
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	27. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Адекват on 07-Апр-13, 13:56
	> А какие у systemd недостатки что его все так не любят? В частности команда journalctrl -u postfix -n50 (тут кстати между -n и 50 не должно быть пробела, иначе команда вернет ошибку) дает задержку в 3-4 секунды. Последующие вызовы - более быстрые. Гораздо больший по объему лог но не journalctl, а простой текстовый файл - выводит мнговенно с первого раза (cat /var/log/some.log | tail -n 50)
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	28. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+4 +/–
	Сообщение от ip1981 (ok) on 07-Апр-13, 13:58
	> cat /var/log/some.log | tail -n 50 Не надо так делать. Даже теоретически tail -n 50 мог бы оптимизировать вывод.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	96. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–3 +/–
	Сообщение от Адекват on 07-Апр-13, 17:20
	>> cat /var/log/some.log | tail -n 50 > Не надо так делать. Даже теоретически tail -n 50 мог бы оптимизировать > вывод. Да хоть a=`cat /var/log/Xorg.0.log | tail -n 50`; if [ "$a" != "" ]; then echo `echo $a`; else if [ "$a" = "" ]; then echo "нечего выводить"; fi;fi все равно будет быстрее
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	135. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Michael Shigorin (ok) on 07-Апр-13, 20:50
	> a=`cat /var/log/Xorg.0.log | tail -n 50`; if [ "$a" != "" ]; > then echo `echo $a` Вот так виндузятники и палятся -- кому нужен хвост Xorg.0.log, слепленный в одну строку?
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	185. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Адекват on 08-Апр-13, 07:03
	>> a=`cat /var/log/Xorg.0.log | tail -n 50`; if [ "$a" != "" ]; >> then echo `echo $a` > Вот так виндузятники и палятся -- кому нужен хвост Xorg.0.log, слепленный в > одну строку? То есть ты таки проверил :))) ?
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	307. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 09-Апр-13, 23:18
	> То есть ты таки проверил :))) ? То есть я-таки такое эээ... ладно, штатно вооружённым глазом вижу. ;)
	Ответить | Правка | ^ к родителю #185 | Наверх | Cообщить модератору

	140. "Разработчики systemd: загрузка с initrd оказалась..."	+2 +/–
	Сообщение от arisu (ok) on 07-Апр-13, 21:01
	а что, просто передать путь к файлу аргументом tail теперь не модно?
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

29. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
Сообщение от Аноним (??) on 07-Апр-13, 14:07
недостатки системд (повыбирал из разных веток linux.org.ru и ещё откуда-то): --- --Systemd — это, пожалуй, самая сложная init-система из существующих на данный момент. Если подробнее, то: Раньше в арче был BSD-Style Init. В нём последовательно запускались все демоны, указанные в rc.conf, а когда они все запустились, то стартовали и иксы. Sysvinit остальных дистров отличается от арчевого bsdinit только тем, что вместо единого файла rc.conf используется каталог rc.d, который позволяет иметь разные списке. Но программа, которая их запускает, умеет запускать их параллельно, то есть иксы могут запуститься раньше, не дожидаясь остальных демонов. На многоядерных машинах это экономит время. Systemd пошел дальше. Вместо простого списка сервисов, которое надо запустить, он описывает дерево запуска. Каждый его unit-файл описывает узел этого дерева. И этих unit-файлов сотни. Через unit-ы в нём описано всё, условный и безусловн ый запуск, монтирование и проверки файловых систем, запуск и остановки и т.д. Еесли вдруг в одном из узлов дерева что-то не так, то всё поддерево перестает запускаться. Это вызывает море удовольствия в часах проведенных в попытках найти и исправить причину... --- Поскольку юнит — это не скрипт и туда нельзя запихнуть конструкции с if и for (а такое частенько бывает нужно), то в systemd такие вещи переписывают на Си (!) и компилируют, а сам файл прописывают только запуск /usr/lib/systemd/systemd-<name>. Типичный пример: systemd-fsck-root.service. В результате, чтобы просто узнать, что именно делает этот долбаный юнит, нужно искать среди исходников systemd (а также кучи других пакетов) нужный файл и разбираться в каше сишного кода. Которая, к слову, выглядит пострашнее любого навороченного баш-скрипта. ---- к systemd претензия в том, что он — худшее, что могли выбрать арчеводы для init-системы. Да, то, что было в арче, ужасно. Но его можно было улучшить, хотя бы добавив обработку LSB-headers для параллельного запуска. Если не хотелось изобретать свой, можно было взять готовый openrc из gentoo, старенький initrg из suse или адаптировать под себя параллельную загрузку из дебиана. Но они выбрали худший возможный вариант — сломать всё и переписать заново используя самую сложную и кривую систему из всех, что можно было выбрать. Если бы systemd работал .— все были бы рады. Любая программа идеальна, пока она делает то, что тебе надо. В теории. Но на практике таких программ не бывает. Всегда бывает нужно изменить что-то, оптимизировать под себя настройки, добавить собственный скрипт для автозапуска или поправить один из существующих. Наконец иногда вылазят баги после апдейта, которые надо быстро поправить и работать дальше. Арчеводы, как никто другой, должны об этом знать. Но поиск багов systemd — это ужас, как его настраивать знают не многие, а отлаживать его умеют единицы. Простой пример: если заменить /tmp на симлинк в /home/tmp, то systemd сносит крышу и система не стартует. Как это починить? Как найти причину и исправить её? Раньше считалось, что арч хорош потому, что он KISS. Но использование вместо init-а велосипедокомбайна из (неполный список) init-демона, syslog-а, udev, cron, dbus, (x)inetd, readahead, ulatencyd, kdm/gdm/xdm, consolekit, sethostname, mount и http-сервера говорит о том, что арч больше не KISS. Какие ещё есть причины им пользоваться? ----
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	32. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Анноннимм on 07-Апр-13, 14:29
	>[оверквотинг удален] > знают не многие, а отлаживать его умеют единицы. > Простой пример: если заменить /tmp на симлинк в /home/tmp, то systemd сносит > крышу и система не стартует. Как это починить? Как найти причину > и исправить её? > Раньше считалось, что арч хорош потому, что он KISS. Но использование вместо > init-а велосипедокомбайна из (неполный список) init-демона, syslog-а, udev, cron, dbus, > (x)inetd, readahead, ulatencyd, kdm/gdm/xdm, consolekit, sethostname, mount и http-сервера > говорит о том, что арч больше не KISS. Какие ещё есть > причины им пользоваться? > ---- Ну вообще-то, если тебе так нужен if или ещё что-то, не обязательно писать сразу unit на Си. Ты можешь написать то, что тебе нужно на шелле, например, и запускать это юнитом. Просто разработчики systemd это делают на Си, видимо, скорости ради. Так что параноидальный бред про сложность и не гибкость в этом месте некорректен. > Если бы systemd работал Работает. Что я делаю не так?
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	47. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–5 +/–
	Сообщение от cmp (ok) on 07-Апр-13, 15:25
	А я согласен. Переписали бы на перле скрипты, да хоть на ноде.жс, хоть на пхп, но на си то нахрена, а ведь еще есть selinux и уефи наступает.. вместо тупого добавление пары строк в скрипт придется новый файл создавать, дублировать функционал старого, править права, контекстные права, и скрестив пальцы надеяться, что там не выползет еще какая хрень. У меня федора 2 месяца не простояла, после очередной обновы перестала грузится, ядро нормально, где-то на скриптах замирала и ждала хз чего, ни ошибок, ни ворнингов.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	52. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 07-Апр-13, 15:40
	> А я согласен. Переписали бы на перле скрипты, да хоть на ноде.жс, > хоть на пхп, но на си то нахрена, а ведь еще > есть selinux и уефи наступает.. вместо тупого добавление пары строк в > скрипт придется новый файл создавать Если у вас возникает такая необходимость, значит, вы что-то делаете неправильно. Программа должна настраиваться через конфигурацию, а не через код. > У меня федора 2 месяца не простояла, после очередной обновы перестала грузится, > ядро нормально, где-то на скриптах замирала и ждала хз чего, ни > ошибок, ни ворнингов. Нельзя просто взять и подвесить systemd. Любой юнит, даже если зависнет, все равно будет убит по таймауту (по умолчанию 5 минут). В отличие от SysV init, который виснет навсегда (приходилось сталкиваться, спасибо дебиану за это).
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	58. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–3 +/–
	Сообщение от cmp (ok) on 07-Апр-13, 15:56
	> Если у вас возникает такая необходимость, значит, вы что-то делаете неправильно. > Программа должна настраиваться через конфигурацию, а не через код. Должна, но не обязана, прелесть линукса в гибкости, можно запустить демон, а можно два, вот на недели tftpd  разворачивал, нету у нее конфига, как прикажете папку корня ftp менять. > Нельзя просто взять и подвесить systemd. Любой юнит, даже если зависнет, все > равно будет убит по таймауту (по умолчанию 5 минут). В отличие > от SysV init, который виснет навсегда (приходилось сталкиваться, спасибо дебиану за > это). SysV то еще убожество, но он прозрачен абсолютно, с момента запуска init можно контролировать его добавляя в скрипты выдачу отладочных мессаг в крайнем случае, можно передав параметр ядру сразу получить консоль и делать все в ручном режиме
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	61. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:05
	> Должна, но не обязана, прелесть линукса в гибкости, Помнится, разработчики Windows в свое время реализовали довольно интересную задумку - унифицированную базу данных для хранения настроек программ (реестр). Но они не могли обязать разработчиков программ не устраивать там срача. В результате разработчики программ с лозунгом "прелесть реестра в гибкости" мигом превратили его в помойку. Именно за это мы и любим текстовые конфиги - они совершенно негибкие, и их гораздо труднее загадить. > вот на недели tftpd  разворачивал, нету у нее конфига, как прикажете папку корня ftp менять. В sysvinit - править инит-скрипт, который является кодом и поэтому будет затерт при следующем обновлении. В systemd - поправить конфиг юнита, который является (внезапно) просто конфигом. > SysV то еще убожество, но он прозрачен абсолютно, с момента запуска init > можно контролировать его добавляя в скрипты выдачу отладочных мессаг А в systemd не надо ничего добавлять, достаточно в повысить loglevel до debug, и все его компоненты начнут писать в лог подробную отладочную информацию. Нормальный код имеет много преимуществ перед сметанными на живую нитку скриптами.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	208. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 08-Апр-13, 10:04
	> обязать разработчиков программ не устраивать там срача. Плюс сами развели там срач. Плюс не дали утилит в системе для прозрачной работы с данными. Так что найти в реестре все ветки содержащие "вася" но не содержащие "петя" - это рокет сайнс. Так изначально вообще не предусмотрено. А с учетом объема ср@ча в реестр - там обычно почти все что угодно находится не менее 100500 раз.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	64. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:09
	> SysV то еще убожество, но он прозрачен абсолютно, Очень грустно, когда рассуждениями про "прозрачность" пытаются оправдать полное отсутствие вменяемой документации.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	75. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:29
	> Очень грустно, когда рассуждениями про "прозрачность" пытаются оправдать полное отсутствие вменяемой документации. Документация - не unix-way. Пусть всякие MSDN-ы документацию пишут, а мы и в код глянем.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	209. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 08-Апр-13, 10:04
	> Документация - не unix-way. А как же маны???
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	80. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от cmp (ok) on 07-Апр-13, 16:39
	> Очень грустно, когда рассуждениями про "прозрачность" пытаются оправдать полное отсутствие > вменяемой документации. ешкин кот, да на кой черт документировать пять строк проверки наличия проги, конфига и его валидности? > В результате разработчики программ с лозунгом "прелесть реестра в гибкости" мигом превратили его в помойку. Винда сама себя в помойку превращает штатными средствами. > Именно за это мы и любим текстовые конфиги - они совершенно негибкие, и их гораздо труднее загадить. загадить можно все. > А в systemd не надо ничего добавлять, достаточно в повысить loglevel до debug, и все его > компоненты начнут писать в лог подробную отладочную информацию. Нормальный код имеет много преимуществ перед сметанными на живую нитку скриптами. Это если дело дошло до лога, это еще пойди тонну доков перечитай, по конфигурированию системд, и прочая прочая. Да SysV убог, но зато прост и легко меняется полностью или частично, а главное работает, системд сам себе на уме, заменить его проблематично, любое действие требует курения манов. Нет в нем и новшеств выгодно отличающих его, то есть меняем шило на мыло. Я писал уже как-то, что очень бы хотелось демона чьей задачей был бы контроль других демонов, только не так как это делают нагиосы, а полномаштабный, с интеграцией с системой, построением графиков использования ресурсов, возможно; с управляемой логикой в случае падения; может это не совсем то, но с интеграцией с dbus, с удалением функции запуска демонов из SysV - это был бы выход на новый уровень, а системд всего лишь велосипед.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	83. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:46
	> ешкин кот, да на кой черт документировать пять строк проверки наличия проги, конфига и его валидности? Я уже лет 20 не видет init-скрипты по пять строк. С тем же успехом можно утверждать "зачем документировать apache, там же три строчки весь код". > Винда сама себя в помойку превращает штатными средствами. Как и SysV init. > Это если дело дошло до лога, это еще пойди тонну доков перечитай, > по конфигурированию системд, и прочая прочая. Да, одну man-страницу прочитать - неподъемный труд. Уж лучше тыщу строчек индусокода, но зато на родном баше. > Да SysV убог, но зато прост и легко меняется полностью или частично, > а главное работает, системд сам себе на уме, заменить его проблематично, > любое действие требует курения манов. С компьютерами вообще сложно работать. > Нет в нем и новшеств выгодно отличающих его, то есть меняем шило на мыло. Да и у Linux никаких новшеств по сравнению с MS-DOS, ага. Такая же черная консоль :) > Я писал уже как-то, что очень бы хотелось демона чьей задачей был > бы контроль других демонов, только не так как это делают нагиосы, > а полномаштабный, с интеграцией с системой, построением графиков использования ресурсов, > возможно; с управляемой логикой в случае падения; может это не совсем > то, но с интеграцией с dbus, с удалением функции запуска демонов > из SysV - это был бы выход на новый уровень Тащемта, это systemd и есть. Разве что графики не строит (зато есть cgtop). А графики и munin строить может.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	93. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от cmp (ok) on 07-Апр-13, 17:10
	> Я уже лет 20 не видет init-скрипты по пять строк. slackware, дома только он, на работе центос - корп стандарт и скрипты его не сложнее. хотя иногда с ними тоже возникают траблы, напримет неспособность проверить корневую фс, так как там прописано проверять /, и вдруг ни с того ни с сего он обнаруживает что это папка соответсвенно скрипт вылетает в ошибку и система не грузится, на SysV встречал эту проблему часто и на рэдхате и на альте, и на компах, и на серверах, и встраиваемых системах, дейсвительно хрен поймешь, что в этих скриптах не отрабатывает, но на худой конец можно снести весь огород и сделать тупое fsck /dev/sdx > С тем же успехом можно утверждать "зачем документировать apache, там же три > строчки весь код". если бы это было действительно так. > Как и SysV init. ну на убунте мб, в центосе все кашерно. > Да, одну man-страницу прочитать - неподъемный труд. > Уж лучше тыщу строчек индусокода, но зато на родном баше. а она одна? речь собственно и идет про замену кучи скриптов на кучу бинарников > С компьютерами вообще сложно работать. в компьютерах нолики да единички, работать сложно с идиотами, поттеринг может и не идиот, но выскочка и порядочный засранец. > Да и у Linux никаких новшеств по сравнению с MS-DOS, ага. Такая > же черная консоль :) Пфф > Тащемта, это systemd и есть. Разве что графики не строит (зато есть > cgtop). > А графики и munin строить может. может и прикрутили что уже, не в курсе, только вот udev делает свою работу и никто его его не хаит, а системд и диски монтирует и за процессами следит, так пусть он тогда дбас зпменит и удев, и глибц, и может поттеринг и ядро свое запилит?
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	98. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 17:29
	>> Я уже лет 20 не видет init-скрипты по пять строк. > slackware, дома только он, на работе центос - корп стандарт и скрипты его не сложнее. если бы это было действительно так © > ну на убунте мб, в центосе все кашерно. Вот не надо ля-ля. Я с 4-5 центосом работал довольно плотно. Переход 6-го на upstart снес порядочную часть sysvinit-го геморроя. И уже очень хочется, чтобы поскорее вышел 7-й с systemd, чтобы забыть еще кучу проблем. > а она одна? речь собственно и идет про замену кучи скриптов на кучу бинарников Для 1 юнита + 1 вызываемого из него бинарника - одна. Хотя бывает, что несколько юнитов и бинарников делают разные части одной работы (например, readahead-collect, readahead-replay) - тогда и man-страница у них одна. > Пфф Ну теперь вы поняли, как практикующие админы относятся к заявлениям "у systemd никаких полезных новшеств, один гемор" :) > может и прикрутили что уже, не в курсе, только вот udev делает > свою работу и никто его его не хаит Гентушники хаяли. Правда, потом извинялись и дарили конфеты.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	100. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от cmp (ok) on 07-Апр-13, 17:36
	> Ну теперь вы поняли, как практикующие админы относятся к заявлениям "у systemd > никаких полезных новшеств, один гемор" :) Как практикующий админ, у systemd никаких полезных новшеств, один гемор.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	115. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от alexxy (ok) on 07-Апр-13, 19:41
	> Гентушники хаяли. Правда, потом извинялись и дарили конфеты. Хаяли не сам удев а что с ним пытался сделать поттеринг, после того как вставил в systemd. Удев попросту больше нельзя собрать не собрав остальных компонентов systemd, потеряна совсместимость удава со старыми ядрами (да да ваши любимые 2.6.32 перестают работать с новым удавом) и тп.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	230. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Адекват on 08-Апр-13, 12:52
	> 6-го на upstart снес порядочную часть sysvinit-го геморроя. Я упорото не могу понять, почему вы считаете что sisvinit - геммор, а systemd манна небесная. Я вот считаю что наоборот - systemd, это геммор, а sysvinit - это то, "каким линукс должен быть". Во всяком случае тот. что был в Арче. Вы никогда не сталикавались с тем, что с systemd почему-то драйвер на сетевую карту не загружался на 100ую загрузку, хотя 99 раз перед этим загружался ? Мне кажется это происходит потому что он не успевает загрузиться, потому что "агрессивная параллелизация". Или имена интерфйесов сетвеых не менялись на "не правильные" ? Жесткие диски sda sdb именами не менялись после перезагрузки ? Когда вы перейдете на systemd, это вас все ждет, не обязательно сразу, но обязательно ждет, если вы конечно не эксперт-телепат, который может видеть будущее.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	138. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Michael Shigorin (ok) on 07-Апр-13, 20:54
	> хотя иногда с ними тоже возникают траблы, напримет неспособность проверить корневую фс, > так как там прописано проверять /, и вдруг ни с того ни с сего он обнаруживает что это > папка соответсвенно скрипт вылетает в ошибку и система не грузится, на SysV встречал > эту проблему часто и на рэдхате и на альте Покурочили ФС или fstab с UUID.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	220. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от cmp (ok) on 08-Апр-13, 10:58
	угумс, вдруг не с того не с сего на встраиваемой системе что-то покурочилось, да так смачно, что извлечение винта и проверка его на другой системе ни ошибок не выявила, ни загружаемость системы не восстановила.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	266. "Разработчики systemd: загрузка с initrd оказалась..."	+/–
	Сообщение от arisu (ok) on 08-Апр-13, 21:29
	маловероятно, но не невозможно.
	Ответить | Правка | ^ к родителю #220 | Наверх | Cообщить модератору

	354. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от nuclight (??) on 11-Апр-13, 17:04
	> Я уже лет 20 не видет init-скрипты по пять строк. http://svnweb.freebsd.org/base/release/9.0.0/etc/rc.d/rwho?v... А если стандартные вычесть, так даже и меньше пяти останется.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	124. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 20:18
	>Я писал уже как-то, что очень бы хотелось демона чьей задачей был бы контроль других демонов ...Но не придумал, чем отвлечь санитаров.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	139. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 07-Апр-13, 20:55
	> Я писал уже как-то, что очень бы хотелось демона чьей задачей был > бы контроль других демонов, только не так как это делают нагиосы, > а полномаштабный, с интеграцией с системой, построением графиков использования > ресурсов, возможно; с управляемой логикой в случае падения Посмотрите monit+collectd?  Каждый прекрасно решает свои задачи.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	145. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от quux (??) on 07-Апр-13, 22:12
	> Каждый прекрасно решает свои задачи Не надо сказок. Что monit cделает если основной процесс некоего демона нарожал потомков, а потом аварийно завершился ? Как сказать мониту "останови демона X и не перезапускай его пока я не прикажу" ? Как _гарантированно_ избежать состязаний при загрузке ?
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	149. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Michael Shigorin (ok) on 07-Апр-13, 22:42
	> Не надо сказок. Правильно, а вот почти десяток лет боевой эксплуатации кое-что говорит. > Что monit cделает если основной процесс некоего демона нарожал потомков, > а потом аварийно завершился ? Что скажут, то и делает -- например, дёргает скрипт рестарта (который может уже более вдумчиво разбираться, что там такое -- хотя криво падающий софт как-то даже страшновато представить в своей зоне ответственности) и пишет руту. > Как сказать мониту "останови демона X и не перезапускай его пока я не прикажу" ? monit stop X > Как _гарантированно_ избежать состязаний при загрузке ? Оформив страховой полис, что Вы как маленький?
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	309. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от quux (??) on 09-Апр-13, 23:40
	>> Не надо сказок. > Правильно, а вот почти десяток лет боевой эксплуатации кое-что говорит. Опыт говорит что нормальных решений сейчас не существует, есть наборы костылей разного радиуса кривости. >> Что monit cделает если основной процесс некоего демона нарожал потомков, >> а потом аварийно завершился ? > Что скажут, то и делает -- например, дёргает скрипт рестарта (который может > уже более вдумчиво разбираться, что там такое Да щас. 99.(9)% скриптов ни в чем разбираться не будут и тупо оставят порожденные процессы болтаться в системе дальше. > -- хотя криво падающий > софт как-то даже страшновато представить в своей зоне ответственности) и пишет руту. За "десяток лет боевой эксплуатации" никогда не видели падения демона? Ну, ну. >> Как сказать мониту "останови демона X и не перезапускай его пока я не прикажу" ? > monit stop X Это радует. >> Как _гарантированно_ избежать состязаний при загрузке ? > Оформив страховой полис, что Вы как маленький? То есть ответа не будет ?
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	317. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 10-Апр-13, 00:59
	>>> Что monit cделает если основной процесс некоего демона нарожал потомков, >>> а потом аварийно завершился ? >> Что скажут, то и делает -- например, дёргает скрипт рестарта (который может >> уже более вдумчиво разбираться, что там такое > Да щас. 99.(9)% скриптов ни в чем разбираться не будут и тупо > оставят порожденные процессы болтаться в системе дальше. Ещё раз: - если это неисправимо в самой софтине (например, бинарь) -- остаётся только подпирать так или иначе, причём будет это рестарт сервера/виртуалки/контейнера или прибитие всего живого в неймспейсе -- разницы катастрофической нет, т.к. у _этой_ медали обратная сторона _есть_ и известна (выплёскивание с водой младенца по шаблонному невниманию); - если это исправимо в софтине, исправлять поведение следует именно там -- возможно, временно используя предыдущий пункт в качестве объезда. >> -- хотя криво падающий >> софт как-то даже страшновато представить в своей зоне ответственности) и пишет руту. > За "десяток лет боевой эксплуатации" никогда не видели падения демона? Ну, ну. Если бы не видел, monit бы не упоминал (только не десяток, а полтора уже скоро). Настолько криво падающих и впрямь сходу не припомню. >>> Как _гарантированно_ избежать состязаний при загрузке ? >> Оформив страховой полис, что Вы как маленький? > То есть ответа не будет ? Каков вопрос, таков ответ.  Про гонки под конкретно systemd писал недавно и достали они достаточно крепко, чтобы лишний раз даже вспоминать не хотелось.
	Ответить | Правка | ^ к родителю #309 | Наверх | Cообщить модератору

	210. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–2 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 10:13
	> Посмотрите monit+collectd?  Каждый прекрасно решает свои задачи. Ага, и будет у нас лоскутное одеяло запускалок. Половина программ запускается там. Половина - сям, а некоторое вообще вон оттуда взлетает. Вот смотришь на конкретную программу - и попробуй угадать: откуда ее такую хорошую запустили. Очень удобно - шариться в три-четыре закоулка системы вместо одного. Это на сервере. На десктопе все еще веселее...
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	232. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от cmp (ok) on 08-Апр-13, 13:02
	> Посмотрите monit+collectd?  Каждый прекрасно решает свои задачи. Спасибо, посмотрел, не то это collectd - по мотивам cacti, видимо, имел удовольствие ковырять, обрезать ошибки до 20 символов полученные от дочерних процессов это сильно. monit - аля nagios, какая-то студенческая свистоперделка, брать id процесса из pid-файла, а если id уже получен другим процессом, проверять контрольную сумму /proc/<pid>/exe? Комплексное решение хочется, чтобы pid получать от fork-exec, отслеживать создание потомков, данные читать в виде как есть, а не процентами от чего-то там, и не генерить их каждые 10 сек, а предоставлять по требованию, динамически конфигурировать список наблюдаемых процессов, и лучшим вариантом тут будет виртуальная фс, кстате в качестве плюшки можно писать на эту фс логи, а денон будет их парсить и по регекспам генерировать события, не говоря уже о решении проблемы с ротацией логов.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	267. "Разработчики systemd: загрузка с initrd оказалась..."	+2 +/–
	Сообщение от arisu (ok) on 08-Апр-13, 21:31
	есть подозрение (без сарказма), что способы получить реализацию этой хотелки — как обычно. или пишем сами, или платим тем, кто нам напишет.
	Ответить | Правка | ^ к родителю #232 | Наверх | Cообщить модератору

	336. "Разработчики systemd: загрузка с initrd оказалась..."	+/–
	Сообщение от cmp (ok) on 10-Апр-13, 12:44
	> есть подозрение (без сарказма), что способы получить реализацию этой хотелки — как > обычно. или пишем сами, или платим тем, кто нам напишет. )), ну да, только за мои деньги я попрошу не иначе как шедевр, и ни малейшего представления нет кто бы мог это сделать, а самому... так проще скриптами)), с 9 до 9 на работе и это блин отпуск).
	Ответить | Правка | ^ к родителю #267 | Наверх | Cообщить модератору

	337. "Разработчики systemd: загрузка с initrd оказалась..."	+/–
	Сообщение от arisu (ok) on 10-Апр-13, 12:51
	> )), ну да, только за мои деньги я попрошу не иначе как > шедевр ну… составляй договоры, контролируй работу и всё такое. ну, и получишь на выходе как обычно, конечно. > и ни малейшего представления нет кто бы мог это сделать всё зависит от суммы, которую ты готов потратить, и от сроков, которые ты готов поставить. как-то так. > а самому… так проще скриптами вот все вы так. сначала Такое-То Описание, а потом в кусты…
	Ответить | Правка | ^ к родителю #336 | Наверх | Cообщить модератору

	339. "Разработчики systemd: загрузка с initrd оказалась..."	+/–
	Сообщение от cmp (ok) on 10-Апр-13, 13:45
	> ну… составляй договоры, контролируй работу и всё такое. ну, и получишь на > выходе как обычно, конечно. > всё зависит от суммы, которую ты готов потратить, и от сроков, которые > ты готов поставить. как-то так. Не согласен, это удача - найти человека способного выполнить то, что ты хочешь и так как ты хочешь, в большенстве случаев, хочешь сделать хорошо - сделай сам. >> а самому… так проще скриптами > вот все вы так. сначала Такое-То Описание, а потом в кусты… ну не совсем, мои скрипты меня вполне устраивают, они как раз умеют запускать процесс гарантированно получать его pid и отличать его в последствии от другого получившего тот же id, конечно отслеживать потомков и прочая прочая мечта, но писались они под более широкий спектр задач с прицелом на маленький-эффективный-универсальный
	Ответить | Правка | ^ к родителю #337 | Наверх | Cообщить модератору

	312. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Michael Shigorin (ok) on 10-Апр-13, 00:13
	> Спасибо, посмотрел Не, не посмотрели, но дело хозяйское.
	Ответить | Правка | ^ к родителю #232 | Наверх | Cообщить модератору

	338. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от cmp (ok) on 10-Апр-13, 13:10
	> Не, не посмотрели, но дело хозяйское. Скажем так, увидел, что оно из себя представляет, или чего не представляет, объем скриптов, которые надо написать или поправить, для вменяемой объвязки сравним с объемом проекта, который бы делал то, что нужно, если писать самому, и в добавок синхронизировать это на разных машинах, администрировать разные части в разных местах, и в результате - весь выигрышь уходит в ноль, если не падает ниже.
	Ответить | Правка | ^ к родителю #312 | Наверх | Cообщить модератору

	137. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 07-Апр-13, 20:52
	> Нельзя просто взять и подвесить systemd. Что, и сегфолтнуть тоже нельзя?  Меня посодють? :]
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	174. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от etw (ok) on 08-Апр-13, 00:43
	>> Нельзя просто взять и подвесить systemd. > Что, и сегфолтнуть тоже нельзя?  Меня посодють? :] Сегфлотнуть можно все, даже баш.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	298. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 09-Апр-13, 19:18
	> Сегфлотнуть можно все, даже баш. Вам удавалось сегфолтнуть bash?  Мне пока нет, а systemd -- да.
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	310. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 09-Апр-13, 23:57
	>> Сегфлотнуть можно все, даже баш. > Вам удавалось сегфолтнуть bash?  Мне пока нет, а systemd -- да. $ alias r="fc -e -" $ r r <здесь будет ругань> $ r r r r r r <... много-много раз...> KABOOM! Работает (практически?) во всех bourne-шеллах. :)
	Ответить | Правка | ^ к родителю #298 | Наверх | Cообщить модератору

	315. "Разработчики systemd: загрузка с initrd оказалась..."	+1 +/–
	Сообщение от arisu (ok) on 10-Апр-13, 00:48
	эм... $ bash $ fc bash: vi: command not found wtf?!
	Ответить | Правка | ^ к родителю #310 | Наверх | Cообщить модератору

	316. "Разработчики systemd: загрузка с initrd оказалась..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 10-Апр-13, 00:58
	> эм... > $ bash > $ fc > bash: vi: command not found > wtf?! О, глядишь, так и получится поприучать линуксоидов читать man'ы... А там, глядишь, они их и писать снова нормальные начнут. :)
	Ответить | Правка | ^ к родителю #315 | Наверх | Cообщить модератору

	320. "Разработчики systemd: загрузка с initrd оказалась..."	–1 +/–
	Сообщение от arisu (ok) on 10-Апр-13, 01:07
	$ man fc No manual entry for fc
	Ответить | Правка | ^ к родителю #316 | Наверх | Cообщить модератору

	322. "Разработчики systemd: загрузка с initrd оказалась..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 10-Апр-13, 01:09
	> $ man fc > No manual entry for fc Теплее... Даю подсказку: чем отличаются "ls" и "/bin/ls"?
	Ответить | Правка | ^ к родителю #320 | Наверх | Cообщить модератору

	323. "Разработчики systemd: загрузка с initrd оказалась..."	+/–
	Сообщение от arisu (ok) on 10-Апр-13, 01:10
	да не надо, туплю я просто.
	Ответить | Правка | ^ к родителю #322 | Наверх | Cообщить модератору

	321. "Разработчики systemd: загрузка с initrd оказалась..."	+/–
	Сообщение от arisu (ok) on 10-Апр-13, 01:09
	чёрт. что-то я спросонок торможу, фигню написал.
	Ответить | Правка | ^ к родителю #316 | Наверх | Cообщить модератору

	318. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Michael Shigorin (ok) on 10-Апр-13, 01:02
	> Работает (практически?) во всех bourne-шеллах. :) $ r r -bash: fc: не нашел такую команду Ой, вот ведь незадача -- фиксить у тестового пользователя нечего %)
	Ответить | Правка | ^ к родителю #310 | Наверх | Cообщить модератору

	319. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 10-Апр-13, 01:05
	>> Работает (практически?) во всех bourne-шеллах. :) > $ r r > -bash: fc: не нашел такую команду > Ой, вот ведь незадача -- фиксить у тестового пользователя нечего %) Я ж специально написал, что срабатывает со второго ввода...
	Ответить | Правка | ^ к родителю #318 | Наверх | Cообщить модератору

	324. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 10-Апр-13, 01:10
	>>> Работает (практически?) во всех bourne-шеллах. :) >> $ r r >> -bash: fc: не нашел такую команду >> Ой, вот ведь незадача -- фиксить у тестового пользователя нечего %) > Я ж специально написал, что срабатывает со второго ввода... Действительно; bash завершился с errorlevel 1, но не по SIGSEGV.
	Ответить | Правка | ^ к родителю #319 | Наверх | Cообщить модератору

	325. "Разработчики systemd: загрузка с initrd оказалась..."	+/–
	Сообщение от arisu (ok) on 10-Апр-13, 01:14
	> Действительно; bash завершился с errorlevel 1, но не по SIGSEGV. у меня с размаху сегфолтнулся. 4.2.37(2) а вот zsh отказался сегфолтится: «fc: event not found: r», сколько раз ему «r r» ни делай.
	Ответить | Правка | ^ к родителю #324 | Наверх | Cообщить модератору

	326. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 10-Апр-13, 01:18
	>>>> Работает (практически?) во всех bourne-шеллах. :) >>> $ r r >>> -bash: fc: не нашел такую команду >>> Ой, вот ведь незадача -- фиксить у тестового пользователя нечего %) >> Я ж специально написал, что срабатывает со второго ввода... > Действительно; bash завершился с errorlevel 1, но не по SIGSEGV. Разные шеллы в разных ОС выдают разное, в зависимости от своего устройства, направления роста стека и так далее. У меня bash - сейчас проверил - вообще вылетает с "Illegal instruction (core dumped)". ksh - до каких-то там фиксов - вылетал, кажись, как раз с SIGSEGV. P.S.: Я - спать.
	Ответить | Правка | ^ к родителю #324 | Наверх | Cообщить модератору

	327. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от etw (ok) on 10-Апр-13, 04:52
	>> Сегфлотнуть можно все, даже баш. > Вам удавалось сегфолтнуть bash?  Мне пока нет, а systemd -- да. Мне как-то удавалось двухстрочным скриптом стабильно сегфолтить баш.
	Ответить | Правка | ^ к родителю #298 | Наверх | Cообщить модератору

	341. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Michael Shigorin (ok) on 10-Апр-13, 14:31
	> Мне как-то удавалось двухстрочным скриптом стабильно сегфолтить баш. Было бы интересно на него посмотреть, если вдруг ещё найдётся; в любом разе спасибо.
	Ответить | Правка | ^ к родителю #327 | Наверх | Cообщить модератору

	346. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от etw (ok) on 11-Апр-13, 00:06
	>> Мне как-то удавалось двухстрочным скриптом стабильно сегфолтить баш. > Было бы интересно на него посмотреть, если вдруг ещё найдётся; в любом > разе спасибо. Дело было больше полугода назад и, разумеется, проблемная часть была сразу же переписана. Помню только, что дело было, вроде, при использовании конструкции вида ${parameter##word} или подобного рода.
	Ответить | Правка | ^ к родителю #341 | Наверх | Cообщить модератору

	118. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от anonymous (??) on 07-Апр-13, 20:01
	> > Если бы systemd работал > > Работает. Что я делаю не так? Видимо, не программируете и не администрируете.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	154. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Анноннимм on 07-Апр-13, 23:11
	>> > Если бы systemd работал >> >> Работает. Что я делаю не так? > Видимо, не программируете и не администрируете. Я так люблю такие пустословные предположения! И с нетерпением жду описание проблем, возникших в процессе эксплуатации systemd. А также, в идеале, ссылку на заведённый баг в трекере. Что касается моей скромной персоны. На продакшн-серверах systemd нет, ибо убунта, и никто не будет менять ОС ради смены системы инициализации, это не самоцель. По-большому счёту, там мне пофигу, что за инит используется. Работает, не кукарекает, ну и ладно. Но от использования systemd бы не отказался, многие вещи там сделаны удобно (или просто сделаны, в отличие от init). Касательно программирования. Да, ничего кроме автоматизирующих рутину скриптов я не пишу. Но на десктопе я использую systemd для загрузки программ в пользовательской сессии (i3wm, pulseaudio, urxvtd). И юнит-файлы к ним я писал сам. И это элементарно. И удобно. Вообще, сама идея выделить в отдельную сущность запускалку абстрактных приложений и определять путь до бинарника + аргументы/(pre|post)-start хуки и тд в конфигурацию гораздо логичне, чем писать на каждый чих свою запускалку,  тому же на шелле, не так ли? Это как бы абстракция, причём, вполне закономерная.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	168. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Michael Shigorin (ok) on 08-Апр-13, 00:29
	> Вообще, сама идея выделить в отдельную сущность запускалку абстрактных приложений Общую часть выделить -- да, мысль здравая.  Беда в другом -- где-то передел и попытки вылепить на Це то, что лучше и прозрачнее делается на шелле, а где-то недодел и игнорирование тех самых багрепортов, которых зачем-то хотите, как если бы имеющихся было мало (неужели уже свою часть исправили?). > Но на десктопе я использую systemd для загрузки программ в пользовательской сессии > (i3wm, pulseaudio, urxvtd). И юнит-файлы к ним я писал сам. И это элементарно. И удобно. И чем же это элементарнее и удобнее ~/.xsession.d/?
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	280. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Анноннимм on 09-Апр-13, 00:11
	>> Вообще, сама идея выделить в отдельную сущность запускалку абстрактных приложений > Общую часть выделить -- да, мысль здравая.  Беда в другом -- > где-то передел и попытки вылепить на Це то, что лучше и > прозрачнее делается на шелле, а где-то недодел и игнорирование тех самых > багрепортов, которых зачем-то хотите, как если бы имеющихся было мало (неужели > уже свою часть исправили?). Я думаю, что тут один язык (Си) выбран исключительно унификации ради. Про игнорирование багрепортов не слышал, если просветите, буду признателен. >> Но на десктопе я использую systemd для загрузки программ в пользовательской сессии >> (i3wm, pulseaudio, urxvtd). И юнит-файлы к ним я писал сам. И это элементарно. И удобно. > И чем же это элементарнее и удобнее ~/.xsession.d/? А я не говорил, что это чем-то элементарнее или удобнее, чем .xsession.d. Но это элементарно и удобно в целом. Как приятные бонусы - более быстрый старт (хотя в этом месте мне фиолетово) и возможность использовать бОльшую часть systemd-* утилит для разбора полётов, мониторинга и диагностики. А-ля systemctl --user --failed и systemctl --user status. Но в целом согласен, это не киллер-фичи. Но я и не претендовал, я лишь указывал на то, что юнит-файлы systemd - это не бинарные конфиги и не какое-то непонятное зло, а простые текстовые конфиги. А то выше товарищ некий рассказывал ужасы какие-то.
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	313. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 10-Апр-13, 00:35
	> Я думаю, что тут один язык (Си) выбран исключительно унификации ради. Как уже не раз приводилось в примерах -- унификация бывает как полезная (взаимозаменяемость деталей), так и безмозглая (ездить на самосвале за батоном в соседний магазин).  В частности, когда люди с явно недостаточным опытом системного администрирования берутся слепить всё "как лучше" -- выходит нередко уродство, непригодное к собственно администраторскому применению. Опять вспоминается http://egorfine.com/ru/articles/worse-than-failure/ и упоминаемый там The Tool, кстати. > Про игнорирование багрепортов не слышал, если просветите, буду признателен. Да гляньте хотя бы шляпную багзилу по systemd в федоре, регулярно натыкаюсь.  Повесят, повисит, поговорят, висит дальше. А если бы внедрение не форсировали, то и фидбэк было бы больше возможности разгребать рабочим порядком. >> И чем же это элементарнее и удобнее ~/.xsession.d/? > А я не говорил, что это чем-то элементарнее или удобнее, чем .xsession.d. А-аа.  Тут просто raorn@ то же самое несколько дней назад упоминал, я и заинтересовался -- правда, ответа по существу и там не получил. В любом разе спасибо.
	Ответить | Правка | ^ к родителю #280 | Наверх | Cообщить модератору

	259. "про баги systemd"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 08-Апр-13, 20:37
	> И с нетерпением жду описание проблем, возникших в процессе эксплуатации systemd. > А также, в идеале, ссылку на заведённый баг в трекере. Да, вот очередное и опять вследствие безмозглой асинхронности -- можете приступать к исправлению (если дело будет только за переводом на английский и его ещё нет, берусь сделать): https://bugzilla.altlinux.org/28805
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	281. "про баги systemd"	+/–
	Сообщение от Анноннимм on 09-Апр-13, 00:20
	>> И с нетерпением жду описание проблем, возникших в процессе эксплуатации systemd. >> А также, в идеале, ссылку на заведённый баг в трекере. > Да, вот очередное и опять вследствие безмозглой асинхронности -- можете приступать к > исправлению (если дело будет только за переводом на английский и его > ещё нет, берусь сделать): https://bugzilla.altlinux.org/28805 Что-то этакое у меня было, когда устанавливал арч на новый ноут. Всё решилось прописыванием KEYMAP=ru FONT=cyr-sun16 в /etc/vconsole.conf. После этого русские шрифты в текстовой консоли стали нормальные. Сейчас специально переключился в консоль - проблема не проявляется, несмотря на периодические обновления systemd. Не знаю, та же у вас проблема или нет по своей сути. И справедливости ради. Я не пытался доказать, что багов в systemd нет. Они везде есть. Речь о том, что писать комментарии, вроде того, на который я ответил первоначально, без каких либо обоснований своих слов глупо.
	Ответить | Правка | ^ к родителю #259 | Наверх | Cообщить модератору

	289. "про баги systemd"	–1 +/–
	Сообщение от anoser_anon on 09-Апр-13, 08:04
	это проблема не в системд, а в плимуте. Исправлено в плимуте.
	Ответить | Правка | ^ к родителю #259 | Наверх | Cообщить модератору

	293. "про баги systemd"	+/–
	Сообщение от qux (ok) on 09-Апр-13, 15:40
	Подобных багов не один и не два. Вот еще (под конец вид проблемы отличается): https://bugzilla.redhat.com/show_bug.cgi?id=892340
	Ответить | Правка | ^ к родителю #289 | Наверх | Cообщить модератору

	305. "про баги systemd"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 09-Апр-13, 23:15
	> это проблема не в системд, а в плимуте. Та, на которую сослался -- вылазила и без plymouth.  Майнтейнер опять починил, дифф не смотрел ещё...
	Ответить | Правка | ^ к родителю #289 | Наверх | Cообщить модератору

	180. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 05:16
	Запили unit и запили init скрипт, нафига мне systemd тогда?
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	306. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 09-Апр-13, 23:16
	> Запили unit и запили init скрипт, нафига мне systemd тогда? Если это исключение -- то ещё может быть смысл.  Если же перекрывание штатных юнитов и лепка обёрток к инитскриптам оказывается частым явлением, вот тогда именно такой вопрос и встаёт.
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

	42. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+7 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 15:16
	> Еесли вдруг в одном из узлов дерева что-то не так, то > всё поддерево перестает запускаться. Это вызывает море удовольствия в часах проведенных > в попытках найти и исправить причину... Как только люди не страдают, лишь бы логи не читать. А ведь там прямо написано, что, когда и почему не запустилось. > Поскольку юнит — это не скрипт и туда нельзя запихнуть конструкции с > if и for (а такое частенько бывает нужно), то в systemd > такие вещи переписывают на Си (!) и компилируют, а сам файл > прописывают только запуск /usr/lib/systemd/systemd-<name>. Типичный пример: systemd-fsck-root.service. В принципе, то же самое можно сделать хоть на баше, но будет мееедленно. > В результате, чтобы просто узнать, что именно делает этот долбаный юнит, нужно > искать среди исходников systemd (а также кучи других пакетов) нужный файл > и разбираться в каше сишного кода. Которая, к слову, выглядит пострашнее > любого навороченного баш-скрипта. Квадратно-гнездовое мышление времен SysV, когда была традиция не документировать процесс загрузки, так что узнать назначение скрипта можно было только чтением его кода. А в эпоху systemd, чтобы понять назначение любого стандартного юнита, достаточно прочитать его manpage. > ---- > к systemd претензия в том, что он — худшее, что могли выбрать арчеводы для init-системы. > ... Ну и дальше поток сознания ЛОР-клоуна AX (одноклассник Зенитура). Никаких аргументов, одни эмоции. Даже комментировать не стоит. > Раньше считалось, что арч хорош потому, что он KISS. Но использование вместо > init-а велосипедокомбайна из (неполный список) init-демона, syslog-а, udev, cron, dbus, > (x)inetd, readahead, ulatencyd, kdm/gdm/xdm, consolekit, sethostname, mount и http-сервера Ну дык все правильно. Вместо кучи велосипедов, каждый из которых нужно изучать отдельно - одно нормальное решение, которое можно изучить один раз. Простота - залог здоровья!
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	51. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–4 +/–
	Сообщение от cmp (ok) on 07-Апр-13, 15:37
	нормальный скрипт в данном контексте не нуждается в документации, на то он и скрипт - 4 функции start/stop/restart/status, если чтение его вызывает проблемы, лучше не трогать, целее система будет, его можно воспринимать как конфиг со стандартным синтаксисом, а вы пытаетесь заменить это программой со своим конфигом и мануалом, зачем только не понятно.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	54. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 07-Апр-13, 15:46
	> нормальный скрипт в данном контексте не нуждается в документации, Весьма спорное утверждение. > на то он и скрипт - 4 функции start/stop/restart/status, если чтение его вызывает проблемы, > лучше не трогать, целее система будет, его можно воспринимать как конфиг > со стандартным синтаксисом, а вы пытаетесь заменить это программой со своим > конфигом и мануалом, зачем только не понятно. Затем, что язык программирования - это нифига не конфиг, очевидно же. Не надо смешивать настройки и код.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	59. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 07-Апр-13, 15:57
	Между прочим, это ключевые принципы классического unix-way: - никакой документации (кому надо - путь читает сорцы) - конфигурация и код едины (надо настроить - правь код) Во всяком случае, именно такое впечатление складывается, если верить сторонникам sysvinit.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	142. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+3 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 21:06
	>Между прочим, это ключевые принципы классического unix-way: >- никакой документации (кому надо - путь читает сорцы) Короткий и локальный код должен быть самодокументированным, вынос документации за пределы кода обычно не нужен и вреден. Например, вряд ли кому-то потребуется читать документацию к конкретным инитскриптам вне контекста чтения или правки самих скриптов (разве что общий обзор специфичных для дистрибутива решений). >- конфигурация и код едины (надо настроить - правь код) Конфигурация в общем случае пишется на языке сценирования конфигурируемой программы. (В частности, чтобы не плодить сущностей и не задавать два формата: один формат (язык) для сценирования, второй --- для конфигурирования). Вполне естественно, что конфигурирование самой ОС (в частности, инитскрипты) пишется на стандартном языке сценирования ОС (sh), а не в выдуманном кем-то формате нестандартной программы. >Во всяком случае, именно такое впечатление складывается, если верить сторонникам sysvinit. Это действительно часть Unix Way. Третье поколение программистов и администраторов свидетельствует.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	211. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 10:16
	> - никакой документации А маны - это, типа, не юникс вэй? Как интересно. >  (кому надо - путь читает сорцы) Вот только юникс был проприетарной системой. И сорцев соответствнено не было. > - конфигурация и код едины (надо настроить - правь код) См. выше.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	247. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 14:57
	Это когда и где в Unix не было исходников?
	Ответить | Правка | ^ к родителю #211 | Наверх | Cообщить модератору

	248. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 15:00
	>А маны - это, типа, не юникс вэй? Как интересно. Попробуйте (в нормально, не отпоттеросяненной ОС) $man initscript и приколитесь.
	Ответить | Правка | ^ к родителю #211 | Наверх | Cообщить модератору

	355. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от nuclight (??) on 11-Апр-13, 17:57
	Чушь какая. Разве что в головах фанатов, извративших оригинал. Вот тут http://old.intuit.ru/department/os/osunix/ в первых трех главах нормально изложено.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	60. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от cmp (ok) on 07-Апр-13, 15:58
	> Затем, что язык программирования - это нифига не конфиг, очевидно же. > Не надо смешивать настройки и код. /etc/rc.d/ знаете для чего нужна папка etc? Программа для запуска программы - дисонанса не улавливаете?
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	62. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:06
	> /etc/rc.d/ > знаете для чего нужна папка etc? В SysV init - для хранения программ. > Программа для запуска программы - дисонанса не улавливаете? Ну дык SysVinit-way во все поля.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	68. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:15
	>> /etc/rc.d/ >> знаете для чего нужна папка etc? > В SysV init - для хранения программ. Когда программы лежат в /etc и запускают другие программы - это и есть unix-way! Тупым systemd-фанатикам не понять :)
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	76. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:30
	> Когда программы лежат в /etc и запускают другие программы - это и > есть unix-way! Тупым systemd-фанатикам не понять :) А еще всякие *bin-ы - для лохов! Настоящие юниксоиды там конфиги хранят. Но systemd-фанатикам, опять же, не понять.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	362. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Клыкастый (ok) on 17-Июн-15, 13:48
	> Когда программы лежат в /etc а они там не лежат. там лежат конфиги и стартовые скрипты. все правятся текстовыми редакторами. не улавливаю диссонанса.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	125. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 20:23
	> знаете для чего нужна папка etc? > Программа для запуска программы - дисонанса не улавливаете? Вы недалеки от просветления. Это и есть Unix Way: запускать программы по возможности программами. Вручную пусть всё запускают те, кто каталоги "папками" называет.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	143. "Разработчики systemd: загрузка с initrd оказалась..."	+1 +/–
	Сообщение от arisu (ok) on 07-Апр-13, 21:09
	> Затем, что язык программирования — это нифига не конфиг, очевидно же. > Не надо смешивать настройки и код. видимо, именно поэтому у системд есть таки условия в «конфигах». корявые, неудобные, но есть. внизапна! это уже язык программирования. хоть и не тюринг-полный. не кидайся камнями из стеклянного дома.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	144. "Разработчики systemd: загрузка с initrd оказалась..."	+/–
	Сообщение от Аноним (??) on 07-Апр-13, 21:27
	Кстати, да, на рефале написать систему инициализации было бы круто.
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	212. "Разработчики systemd: загрузка с initrd оказалась..."	+/–
	Сообщение от Аноним (??) on 08-Апр-13, 10:17
	> Кстати, да, на рефале написать систему инициализации было бы круто. Так пишите, кто вам не дает?
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	231. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Адекват on 08-Апр-13, 13:01
	> Квадратно-гнездовое мышление времен SysV, когда была традиция не документировать процесс > загрузки, так что узнать назначение скрипта можно было только чтением его > кода. > А в эпоху systemd, чтобы понять назначение любого стандартного юнита, достаточно прочитать > его manpage. А вы manpag'у на все 100% доверяете :) ? может в нем какая-то неточность есть, или смысл выражений можно как-то двояко трактовать ? Или ментейнеры не досмотрели и не обновили manpage ? Я вот считаю, что действительно понять как работает скрипт - можно увидев его код, просто пробежав глазами.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	126. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от anonymous (??) on 07-Апр-13, 20:29
	> Systemd пошел дальше. Вместо простого списка сервисов, которое надо запустить, он описывает > дерево запуска. Каждый его unit-файл описывает узел этого дерева. И этих > unit-файлов сотни. Через unit-ы в нём описано всё, условный и безусловный запуск, монтирование и проверки файловых систем, запуск и остановки и т.д. > Еесли вдруг в одном из узлов дерева что-то не так, то > всё поддерево перестает запускаться. Это вызывает море удовольствия в часах проведенных > в попытках найти и исправить причину... IMO построить дерево запуска можно (и нужно) статически, что впрочем вполне успешно делается таким простым средством, как insserv.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	177. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–2 +/–
	Сообщение от etw (ok) on 08-Апр-13, 00:56
	> Sysvinit остальных дистров отличается не отличаЕтся, а отличаЮтся. > программа, которая их запускает, умеет запускать их параллельно Сам инит параллельно ничего без нашлепки сверху под названием insserv (которая есть только в дебиане и Ко) запускать не умеет. > могут запуститься раньше, не дожидаясь остальных демонов. На многоядерных машинах это > экономит время. > Systemd пошел дальше. Вместо простого списка сервисов, которое надо запустить, он описывает > дерево запуска. Каждый его unit-файл описывает узел этого дерева. И этих > unit-файлов сотни. Через unit-ы в нём описано всё, условный и безусловн > ый запуск, монтирование и проверки файловых систем, запуск и остановки и т.д. А как ты хотел без построения дерева зависимостей эти самые зависимости выяснить? > Еесли вдруг в одном из узлов дерева что-то не так, то > всё поддерево перестает запускаться. Это вызывает море удовольствия в часах проведенных > в попытках найти и исправить причину... Я, наверное, не буду оригинальна, однако замечу, что в логах есть эхм... скажем так, сортировка по времени. Очень сильно помогает узнавать с чего начались проблемы. > Поскольку юнит — это не скрипт и туда нельзя запихнуть конструкции с > if и for (а такое частенько бывает нужно), то в systemd > такие вещи переписывают на Си (!) и компилируют, а сам файл > прописывают только запуск /usr/lib/systemd/systemd-<name>. Типичный пример: systemd-fsck-root.service. Если тебе так хочется свой скрипт проверки ФС, то напиши его и вызывай юнитами, кто тебе запрещает? Тебе еще и меньше кода писать придется из-за отсутствия необходимости соблюдать LSB-соглашения. > В результате, чтобы просто узнать, что именно делает этот долбаный юнит, нужно > искать среди исходников systemd (а также кучи других пакетов) нужный файл > и разбираться в каше сишного кода. Которая, к слову, выглядит пострашнее > любого навороченного баш-скрипта. К слову, у Поттеринга и Ко код написан хорошо и понятно.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	240. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от an (??) on 08-Апр-13, 14:17
	> > программа, которая их запускает, умеет запускать их параллельно > > Сам инит параллельно ничего без нашлепки сверху под названием insserv (которая есть > только в дебиане и Ко) запускать не умеет. А ничего, что insserv выстраивает скрипты в /etc/rc?.d/ _не во время загрузки системы_, а в процессе загрузки совсем не участвует?
	Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

	302. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 09-Апр-13, 22:58
	> А как ты хотел без построения дерева зависимостей эти самые зависимости выяснить? hint: эту операцию не так много смысла выносить в рантайм, т.к. относительно одного и того же набора это дерево должно быть инвариантно; при этом помимо потенциальной задумчивости солвера и необходимости как-то неинтерактивно разрывать возможные циклы получается возможность сильно упростить критический для запуска системы код.  Соответственно обновление кэша можно выполнять утилитой, которую дёргать в т.ч. из пакетных менеджеров и у которой будет шанс внятно вывалиться при проблемах. > Я, наверное, не буду оригинальна, однако замечу, что в логах есть эхм... > скажем так, сортировка по времени. Очень сильно помогает узнавать с чего > начались проблемы. Это когда загрузка проходит успешно.  Далее, логи ротируются и при достаточно скромных аптаймах нужный фрагмент ко времени фиксирования проблемы мог уже уехать. Логи и отлаживаемость "на месте" -- это как бэкап и зеркало... > К слову, у Поттеринга и Ко код написан хорошо и понятно. И со строками на сях работать проще/компактней/надёжней, чем на шелле, угу. Возвращаемся всё к тому же: сырую технологию даже не тащат, а назойливо пихают всем подряд, пытаясь использовать в качестве бета-тестеров.  Это даже не php, а хуже в квадрате.
	Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

30. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–5 +/–
Сообщение от Аноним (??) on 07-Апр-13, 14:08
ещё хотите про недостатки системд? ---- >> теперь бинарные логи. зачем? > Место на диске экономить, хотя бы. Нет. Для этого придумали logrotate, который успешно gzip-ит (bzip-ит, xz-ит, на ваш выбор) логи уже пару десятков лет. Если хочется, то в обычном rsyslog-е есть потоковое сжатие, чтобы писать логи сразу в сжатом формате, для экономии места. Идея бинарных логов была в том, чтобы превратить их в базу данных, по которой можно делать быстрый поиск, типа "выдайте мне лог такой-то программы за такое-то число". В ответ ему, кажется, автор rsyslog-а писал, что для этого не нужен бинарный формат, есть уже куча готовых программ, которые можно цеплять на обычный syslog, они его проиндексируют, и даже в базу данных могут сложить (навскидку GrayLog2, ElasticSearch, Solr...), и поиск в них намного лучше и фичастее. Но разве поттеринг будет кого-то слушать? --- systemd — это примерно как взять и заменить автосцепку на всех вагонах на аналогичную, не приносящую никаких бонусов. движения есть, траты колоссальные, людских ресурсов тратится море, но профита НЕТ. при переходе с poll на epoll профит ощутим, при переходе с gcc 2.95 на gcc 3 тоже. а при переходе на systemd геморроя много, а толку нет. понятное дело, что для людей, которые в возне с линуксом проводят свой досуг, systemd может быть интересен, но для индустрии это жуть. ---- Поттеринг меня раздражает. Он как студент, который не может понять чужого кода на Си и пишет программу полностью, заново, на Python. В примере Си заменить на ядро, а Python на Си. Какие реальные преимущества есть у PulseAudio по сравнению с ALSA? Регулятор громкости всех приложений из одного окна? Да написал бы он себе небольшую утилиту для ALSA - но нет же, не захотел разбираться в коде, сделал прослойку поверх ALSA. Проброс звука по сети? Было в Linux средствами NAS ещё с начала 90-х годов, и багов в этой программе гораздо меньше, чем в PulseAudio, если они вообще есть. Переключение ведущегося разговора с микрофона и колонок на скайпфон без его прерывания? Скайпопроблема. Невозможность поменять порядок звуковых карт без правки конфигов? У меня в Mandriva/SUSE возможно, в остальных не знаю почему нет GUI.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Часть нити удалена модератором

	34. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 14:48
	леннарт, поттеринг, ты?
	Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

	40. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 07-Апр-13, 15:04
	> леннарт, поттеринг, ты? Нет, это другой леннартоборец вас поддерживает :)
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	50. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+4 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 15:35
	> Нет. Для этого придумали logrotate, который успешно gzip-ит (bzip-ит, xz-ит, на ваш > выбор) логи уже пару десятков лет. Если хочется, то в обычном > rsyslog-е есть потоковое сжатие, чтобы писать логи сразу в сжатом формате, > для экономии места. Идея бинарных логов была в том, чтобы превратить > их в базу данных, по которой можно делать быстрый поиск, типа > "выдайте мне лог такой-то программы за такое-то число". В ответ ему, > кажется, автор rsyslog-а писал, что для этого не нужен бинарный формат, > есть уже куча готовых программ, которые можно цеплять на обычный syslog, > они его проиндексируют, и даже в базу данных могут сложить (навскидку > GrayLog2, ElasticSearch, Solr...) Все эти костыли по-своему замечательны, но проблем дизайна протокола syslog они не решают. Наиболее паршивых проблем две: 1. Неструктурированная запись. syslog by design ориентирован на человека, а не на машинный парсинг, поэтому вместо структурированной записи с именами полей, получается одна текстовая строчка, которую в общем случае может понять только человек. Такое вот сжатие с потерями. В то время как в Journal это сжатие происходит не на стадии записи лога, а на стадии выдачи его человеку. При необходимости, и программы, и человек могут использовать полезную информацию о структуре записи (например, искать сообщения по UUID). 2. Недоверенная информация. В syslog может писать кто угодно и что угодно. Даже из-под nobody можно написать туда такого, что админ будет месяц разбираться. В UNIX эту проблему решили много лет назад, введя специальный защищенный бинарный лог (BSM). Так появилась инфраструктура аудита. Но вопросы структурирования, индексирования информации, быстрого поиска по ней и т.д. актуальны не только для событий безопасности, но и для всех системных событий, так что появление Journal было неизбежно. > а при переходе на systemd геморроя много, а толку нет. С точки зрения диванного теоретика - да :) > понятное дело, что для людей, которые в возне с линуксом проводят свой > досуг, systemd может быть интересен, но для индустрии это жуть. А вот тырпрайз-админы с нетерпением ожидают RHEL/CentOS/OL 7. В основном из-за Journal, конечно. > Поттеринг меня раздражает. Ну и опять поток сознания какого-то хипстера. Скучища...
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	87. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+3 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:51
	> Все эти костыли по-своему замечательны, но проблем дизайна протокола syslog они не > решают. Наиболее паршивых проблем две: > 1. Неструктурированная запись. syslog by design ориентирован на человека, а не на > машинный парсинг, поэтому вместо структурированной записи с именами полей, получается > одна текстовая строчка, которую в общем случае может понять только человек. > Такое вот сжатие с потерями. В то время как в Journal > это сжатие происходит не на стадии записи лога, а на стадии > выдачи его человеку. При необходимости, и программы, и человек могут использовать > полезную информацию о структуре записи (например, искать сообщения по UUID). Ась? Какое-какое "сжатие с потерями"? Эк Вас приложило-то... А "сжатие происходит не на стадии записи лога, а на стадии выдачи его человеку" - это вообще шедевр! И, к стати, журнал, чем бы он ни был записан (хоть syslog, хоть journal, хоть админом на бумажке) нужен для анализа его человеком. Компьютер, конечно же, может ему в этом помочь, но журнал в текстовом виде в этом случае предпочтительнее, чем в бинарном, поскольку для работы с текстами УЖЕ ЕСТЬ КУЧА ГОТОВЫХ И ПРОВЕРЕННЫХ ИНСТРУМЕНТОВ (grep, awk, perl etc), а для бинарного их (аналоги) нужно создавать с нуля, и ошибок при этом будет немало... Логичный вопрос - зачем терять существующие инструменты ради еще несуществующих и, скорее всего, бажных? > 2. Недоверенная информация. В syslog может писать кто угодно и что угодно. > Даже из-под nobody можно написать туда такого, что админ будет месяц > разбираться. Вы хотите сказать, что в journal писать может не кто угодно? Тогда смысл в этом журнале, если нужная МНЕ (не Вам и не Поттеру, а именно мне на моем компьютере!) программа не может писать в журнал? А если может - то кто мешает мне (ну или тому, кто может запустить програму на этом компьютере) написать в журнал что угодно? Вы (ну, не лично, а в лице Поттера, или кто там сейчас главный идеолог проекта) пытаетесь проблему безопасности решать инструментом, для этого не предназначеным (системным журналом). Можно, конечно, микроскопом гвозди забивать, но неудобно - молотком значительно удобнее и для пальцев безопаснее. > А вот тырпрайз-админы с нетерпением ожидают RHEL/CentOS/OL 7. В основном из-за Journal, > конечно. Ну, "тырпрайз-админы" вынуждены "колоться, но жрать кактусы" (С), но ведь жизнь есть и за пределами "тырпрайза" -  почему остальные должны "жрать кактусы" за компанию? А если завтра "тырпрайз-админы" возьмут веревки и дружно вешаться станут, остальным тоже вешаться прикажете? А своя-то голова на плечах зачем? Только есть в нее, или все-таки зачем-то еще нужна?
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	89. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 17:02
	> Ась? Какое-какое "сжатие с потерями"? Эк Вас приложило-то... А "сжатие происходит не > на стадии записи лога, а на стадии выдачи его человеку" - > это вообще шедевр! Попробую еще раз, для самых несообразительных: структура записи (какая информация какому полю принадлежит) - это информация. И при выводе в формате /var/log/messages она теряется. > но журнал в текстовом виде в этом случае предпочтительнее, чем > в бинарном, поскольку для работы с текстами УЖЕ ЕСТЬ КУЧА ГОТОВЫХ > И ПРОВЕРЕННЫХ ИНСТРУМЕНТОВ (grep, awk, perl etc), а для бинарного их > (аналоги) нужно создавать с нуля, и ошибок при этом будет немало... Бинарный формат не требует создания таких инструментов, по определению. Просто потому, что парсинг текста - это просто попытка восстановить потерянную информацю (отсоединить обратно котлеты от мух, PID от имени бинарника, время от текста сообщения и т.д.). В бинарном формате их не нужно разделять, потому что их никто не смешивал. > Вы хотите сказать, что в journal писать может не кто угодно? Тогда > смысл в этом журнале, если нужная МНЕ (не Вам и не > Поттеру, а именно мне на моем компьютере!) программа не может писать > в журнал? А если может - то кто мешает мне (ну > или тому, кто может запустить програму на этом компьютере) написать в > журнал что угодно? Записать в журнал вы можете все, что угодно. Но только от своего имени (UID, GID, session ID). И столь ненавидимый вами бинарный формат позволит легко отфильтровать это. А при записи в syslog регистрируется не UID программы (протокол syslog это не поддерживает), а тот UID, который сама программа изволит сообщить. Поэтому даже nobody может писать от имени рута. > А если завтра "тырпрайз-админы" возьмут веревки и дружно вешаться станут Скорее, завтра станут вешаться противники systemd, в знак протеста :)
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	94. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 17:15
	> Попробую еще раз, для самых несообразительных: структура записи (какая информация какому > полю принадлежит) - это информация. И при выводе в формате /var/log/messages > она теряется. Вот, для сравнения, несжатый вариант Tue, 2012-10-23 23:51:38 CEST PRIORITY=6 SYSLOG_FACILITY=3 _MACHINE_ID=a91663387a90b89f185d4e860000001a _HOSTNAME=epsilon _TRANSPORT=syslog SYSLOG_IDENTIFIER=avahi-daemon _COMM=avahi-daemon _EXE=/usr/sbin/avahi-daemon _SYSTEMD_CGROUP=/system/avahi-daemon.service _SYSTEMD_UNIT=avahi-daemon.service _SELINUX_CONTEXT=system_u:system_r:avahi_t:s0 _UID=70 _GID=70 _CMDLINE=avahi-daemon: registering [epsilon.local] MESSAGE=Joining mDNS multicast group on interface wlan0.IPv4 with address 172.31.0.53. _BOOT_ID=5335e9cf5d954633bb99aefc0ec38c25 _PID=27937 SYSLOG_PID=27937 _SOURCE_REALTIME_TIMESTAMP=1351029098747042 И сжатый: Oct 23 23:51:38 epsilon avahi-daemon[27937]: Joining mDNS multicast group on interface wlan0.IPv4 with address 172.31.0.53. Несжатый вариант можно спокойно фильтровать по любому полю, а сжатый сначала надо распарсить, чтобы привести вновь в некоторое подобие несжатого.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	102. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+3 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 18:07
	> А при записи в syslog регистрируется не UID программы (протокол syslog это > не поддерживает), а тот UID, который сама программа изволит сообщить. Поэтому > даже nobody может писать от имени рута. http://blog.gerhards.net/2011/11/trusted-properties-in-rsysl... просвещайся.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	296. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от qux (ok) on 09-Апр-13, 18:57
	> http://blog.gerhards.net/2011/11/trusted-properties-in-rsysl... просвещайся. Оттуда: > The idea is rooted in the journald proposal :)
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	132. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от jOKer (ok) on 07-Апр-13, 20:45
	А между прочим кто сказал, что поступающая в журнал инфа должна укладываться в прокрустово ложе представлений Леонардо о нормализации? И почему бы не хранить данные в NoSQL DB? И с какого перепуга Леонардо смешал в кучу нормализацию данных (которая очевидно в журнале никому не упала) и бинарный формат, который возможно кому-то и понадобится? Между этими понятиями, если что, знак равенства не стоит!
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	148. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 07-Апр-13, 22:40
	> И почему бы не хранить данные в NoSQL DB? считай, что бинарный лог и есть такая DB.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	152. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от jOKer (ok) on 07-Апр-13, 22:58
	Наивный вопрос имею: а почему бы не считать такой БД обычный текстовик в формате "ключ-значение"?
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	155. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 07-Апр-13, 23:16
	можно и так считать, под 'NoSQL БД' попадает всё что угодно
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	156. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от jOKer (ok) on 07-Апр-13, 23:32
	Тогда последний наивный вопрос: а не проще ли было бы прикрутить к rsyslog (как вариант) NoSQL backend на вкус админа хоста и расслабится? На все-про-все пол-часа работы...
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	162. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 08-Апр-13, 00:17
	> а не проще ли было бы прикрутить к rsyslog (как вариант) NoSQL backend сислог не предоставляет равноценный интерфейс приложению. Mеняется не только способ хранения, но и API между логгером и сервисом (+ некоторые метаданные из приложения). Правда, текущее API сделано убоговато и не раскрывает всего потенциала технологии. [сообщение отредактировано модератором]
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	214. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 10:23
	> Наивный вопрос имею: а почему бы не считать такой БД обычный текстовик в формате "ключ-значение"? Потому что у него нет индексов для быстрого лукапа в основном. Ну и потому что он неэффективен для хранения всего что отличается от текста. Например IPv4 занимает в бинарном виде 4 байта. А сколько он займет в виде текста? Ах, вплоть до 15 байтов? И как вам перспектива получить лог не на 4 гига а на 15? Ну, если немного отмасштабировать. А потом будет очень круто, когда 15-гиговый лог без индекса надо будет целиком лопатить грепом.
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	226. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от jOKer (ok) on 08-Апр-13, 12:12
	На самом деле, вы немножко забегаете вперед: сначала надо условится о том "что" храним, а уж потом думать о том "как" храним. О том "что храним". Если мы все согласны с тем, что журнал призван хранить массив слабо-нормализованной информации, то изделие из мастерской Леонардо нам *уже* не подходит, вне зависимости от того в каком формате это все хранится. Теперь о том, "как" хранить. Есть разные случаи и разные потребности: кому-то и индексы будут не нужны, а кому-то потребуются множественные параллельные запросы в стиле map-reduce. ОК, ну так для этой цели как раз и нужна архитектура фронтэнд-бакэнд, причем в качестве бакэнда должна иметь возможность выступить *любая* NoSQL СУБД. От текстовика, до промышленных МонгоДБ  и ОриентДБ. Но, насколько я понимаю, изделие Леонардо этого не умеет и работает строго со своим хранилищем. Так что и тут неувязочка. Подытоживая: возможно, rsyslog и иже с ними и устарели (не буду спорить, хотя спорить есть о чем), но и то что пихает г-н Поттеринг - это не то. ИМХО, это сильно урезанная и пропущенная через призму его мнения версия того что надо. И ничего другого от него ждать и не стоит: практически все его программы очень неопрятны и размазаны архитектурно. Риск их применения ну очень велик, а профит напротив - ничтожен.
	Ответить | Правка | ^ к родителю #214 | Наверх | Cообщить модератору

	141. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 07-Апр-13, 21:02
	> Попробую еще раз, для самых несообразительных: Вы бы сами для начала перестали путать "формат /var/log/messages" и RFC 3164/5424. > Бинарный формат не требует создания таких инструментов, по определению. Сказочник. > Просто потому, что парсинг текста - это просто попытка восстановить потерянную > информацю (отсоединить обратно котлеты от мух, PID от имени бинарника, время от > текста сообщения и т.д.). В бинарном формате их не нужно разделять, > потому что их никто не смешивал. Вопрос в надежде на то, что это был всё-таки помрачённый User294: зачем в РСУБД хранимые процедуры придумали -- сами сообразите или подсказать надо? >> А если завтра "тырпрайз-админы" возьмут веревки и дружно вешаться станут > Скорее, завтра станут вешаться противники systemd, в знак протеста :) Завтра он начнёт интересными пакетиками с сетью обмениваться, что-то мне подсказывает.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	147. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от quux (??) on 07-Апр-13, 22:28
	> зачем в РСУБД хранимые процедуры придумали -- сами сообразите или подсказать надо? Ну и зачем ?
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	151. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 07-Апр-13, 22:49
	>> зачем в РСУБД хранимые процедуры придумали -- сами сообразите или подсказать надо? > Ну и зачем ? ...когда всё решается высокоуровневыми запросами по структурированным данным, ага... ;-)
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	196. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от жабабыдлокодер (ok) on 08-Апр-13, 09:12
	Хранимые процедуры придуманы для реализации бизнес-логики, когда скорость критична или когда необходимо преобразование данных прямо в базе. И что?
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	311. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 10-Апр-13, 00:11
	> И что? Если мне не изменяет склероз по мотивам давно уж прочтённого Дейта, то изначально высоколобые теоретики предполагали, что всем(tm) будет достаточно языка четвёртого поколения. Жизнь оказалась заковыристей. Так и тут -- когда заливают про "всем хватит полутораста высокоуровневых ручек [с прибитой гвоздями семантикой]", купиться на это может в основном недостаточно уделивший внимание предыдущим сериям молодняк. При этом и ручки нужны, и SQL полезен -- спору нет.  В отличие от людей с табличным или псевдосистемным подходом ко всему подряд.
	Ответить | Правка | ^ к родителю #196 | Наверх | Cообщить модератору

	193. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от anonymous (??) on 08-Апр-13, 09:01
	> > зачем в РСУБД хранимые процедуры придумали -- сами сообразите или подсказать надо? > > Ну и зачем ? В процессе отработки кошерного реляционного запроса легко получаются многомерные массивы нехилого объема. И тогда придумать sql clause, который engine может переварить становится нетривиально и он (clause) сильно зависит от engine (т.е. формально переносимо, фактически --- нет).
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	133. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 20:47
	1) Структурированный лог это замечательно. 2) Двоичный лог это просто глупость. 3) "Доверенное" логгирование это палка о двух концах, поскольку добавляет в систему еще одну Точку Отказа Всего.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	181. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 05:30
	> Все эти костыли по-своему замечательны, но проблем дизайна протокола syslog они не > решают. Наиболее паршивых проблем две: > 1. Неструктурированная запись. syslog by design ориентирован на человека, а не на > машинный парсинг, поэтому вместо структурированной записи с именами полей, получается > одна текстовая строчка, которую в общем случае может понять только человек. > Такое вот сжатие с потерями. В то время как в Journal > это сжатие происходит не на стадии записи лога, а на стадии > выдачи его человеку. При необходимости, и программы, и человек могут использовать > полезную информацию о структуре записи (например, искать сообщения по UUID). Все программисты сразу кинулись переписывать программы под journald ? > 2. Недоверенная информация. В syslog может писать кто угодно и что угодно. > Даже из-под nobody можно написать туда такого, что админ будет месяц > разбираться. А вот ненадо ставить права на лог 777. > В UNIX эту проблему решили много лет назад, введя специальный защищенный бинарный > лог (BSM). Так появилась инфраструктура аудита. > Но вопросы структурирования, индексирования информации, быстрого поиска по ней и т.д. актуальны > не только для событий безопасности, но и для всех системных событий, > так что появление Journal было неизбежно. вы действительно хотите индексировать логи на боевом сервере? Как там у journald с удаленными логами, не стриминг по http а именно удаленная запись логов.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	283. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Анноннимм on 09-Апр-13, 00:32
	> вы действительно хотите индексировать логи на боевом сервере? А вы действительно используете syslog для логирования запросов, к скажем, высоконагруженному nginx? Мне кажется, тут безальтернативно - либо писать их в файл самим nginx'ом, что и делается в 90 из 100 инсталляций, либо, если есть реальная необходимость, то докупить озу и хранить их какое-то время в рамдиске, а потом сливать куда нибудь по сети. Можно ещё писать на отдельный диск, да, должно быть не очень печально в плане нагрузки. Впрочем, это меня уже в сторону понесло, основная мысль - писать быстро генерирующиеся большими пачками логи что в syslog, что в journal - глупость. А для системных логов, я практически уверен, переубедите меня тестами или примерами, существенной разницы и нет. > Как там у journald с удаленными логами, не стриминг по http а > именно удаленная запись логов. Не знаю. Но вообще, journald более чем спорная штука, тут не поспоришь.
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	295. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от qux (ok) on 09-Апр-13, 18:55
	> А вот ненадо ставить права на лог 777. А вот не надо считать будто это убирает проблему. Вызов спец. тулзы никто не отменял.
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	146. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 07-Апр-13, 22:17
	> Идея бинарных логов была в том, чтобы превратить их в базу данных, по которой можно делать быстрый поиск идея бинарных логов в другом, ~ стандартизированное навешивание метаданных на логгируемый текст. Можно, конечно, сделать тоже самое и в текстовых форматах. Технологически текстовый формат значительно сложнее бинарного в реализации. Чтобы представить какое это адище можно посмотреть как это делают с хml. Проблема текущих текстовых логов это отсутствие вообще какой-либо стандартизации представления данных. Т.е. для каждой админской настройки нужно херачить свои регэкспы для выдёргивания метаданных. > типа "выдайте мне лог такой-то программы за такое-то число" суть этого не быстрый поиск, а фильтрация по метаданным. И быть там может не только имя программы, а и другие атрибудты которых в стандартном логгере просто нет. > В ответ ему, кажется, автор rsyslog-а писал, что для этого не нужен бинарный формат, есть уже куча готовых программ, которые можно цеплять на обычный syslog, они его проиндексируют Есть некоторые костыли. Ибо поблема, ещё раз повторю, не в поиске. > systemd — это примерно как взять и заменить автосцепку на всех вагонах на аналогичную, не приносящую никаких бонусов. движения есть, траты колоссальные, людских ресурсов тратится море, но профита НЕТ. при переходе с poll на epoll профит ощутим, при переходе с gcc 2.95 на gcc 3 тоже. а при переходе на systemd геморроя много, а толку нет ваша проблема в том, что вы ничего не видите дальше своего носа и душой прикипели к "уютным" инструментам из своего юношеского прошлого. Т.е. состарились и превратились в пенсионера в негативном смысле этого слова. бонусы от systemd-подобной технологии могут быть видны только через длительное время, пока большая часть разработчиков сервисов не станут пользоваться новыми фичами. > Какие реальные преимущества есть у PulseAudio по сравнению с ALSA? например, ALSA умеет _нормально_ делать только hwmix и не умеет софтверно. Если перевести на более привычный язык, ALSA не умеет работать с несколькими приложениями если драйвер этого не позволяет. > Регулятор громкости всех приложений из одного окна? наоборот же, у ALSA один регулятор громкости для всех каналов, у PA персональные для клиента. ALSA не даёт однотипныъ фич приложениям на всём железе, потому всегда будет нужен аналог PA. > Да написал бы он себе небольшую утилиту для ALSA - но нет же, не захотел разбираться в коде в случае с PA он не захотел быдлокодить и костылить. Архитектурно на ALSA'у нельзя нормально навесить весь подобный функционал. > понятное дело, что для людей, которые в возне с линуксом проводят свой досуг, systemd может быть интересен, но для индустрии это жуть. это, между порчим, придумал не Поттеринг, а индустрия в лице SUNа и solaris/smf. Откуда он и упёр многое в системд. Теперь индустрия в лице красношапки хочет похожее видеть у себя.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	150. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+3 +/–
	Сообщение от Michael Shigorin (ok) on 07-Апр-13, 22:48
	> суть этого не быстрый поиск, а фильтрация по метаданным. Внимание, вопрос: когда она начинает быть нужна? > Есть некоторые костыли. Ибо поблема, ещё раз повторю, не в поиске. Для *проблемы* есть более вменяемые решения, уже как-то приводил списочек.  А эти полумеры -- они в тривиальных случаях жизнь затрудняют, в сложных... тоже затрудняют, т.к. стыковать сложнее (по крайней мере здесь и сейчас). > бонусы от systemd-подобной технологии могут быть видны только через длительное время, > пока большая часть разработчиков сервисов не станут пользоваться новыми фичами. Зачем тогда такая спешка с запихиванием всех на systemd всеми правдами и неправдами? > например, ALSA умеет _нормально_ делать только hwmix и не умеет софтверно. JFYI, dmix знаю куда больше времени, чем Вас читаю. > наоборот же, у ALSA один регулятор громкости для всех каналов, у PA > персональные для клиента. ALSA не даёт однотипныъ фич приложениям на всём > железе, потому всегда будет нужен аналог PA. А если мне не надо? (и лишние wakeups тоже не хочу)
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	216. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 10:37
	>> суть этого не быстрый поиск, а фильтрация по метаданным. > Внимание, вопрос: когда она начинает быть нужна? Когда кто-то идет изучать логи, а не просто спускает их в /dev/null в очередной раз. Ну да, если логи просто спускать в /dev/null - их можно в любом формате писать. А вот если хочется проанализировать чем вообще машина занимается - тут текстовые логи начинают вызывать бурную икоту. За отсутствием там каких либо индексов обработка логов сколь-нибудь нагруженного сервака за сколь-нибудь существенный период занимает уйму времени. Потому что единственный способ - прочитать все логи и посмотреть нет ли в каждой записи интересующих значений. Что как-то тормознуто на больших объемах логов. > тоже затрудняют, т.к. стыковать сложнее (по крайней мере здесь и сейчас). Кому-то сложнее, кому-то проще. Вот рынок и решит кому как проще оказалось. > Зачем тогда такая спешка с запихиванием всех на systemd всеми правдами и неправдами? Никто к лично вам не придет отбирать у вас sysvinit. Просто если админам в целом окажется более удобно нечто типа systemd, вы просто останетесь без пользователей дистра. Это будет вполне честным вариантом. > А если мне не надо? (и лишние wakeups тоже не хочу) А вы знаете, даже фирма Нокия, которую wakeups интересовали поболее любого альта, раз так в эн, ибо у них батарейные девайсы, с питанием от хиленького мобилочного акку, в свое время вполне успешно применила пульсаудио на мобильном телефоне. И вы знаете, они там натурально поюзали разные громкости звука для разных приложений. Так что уровень громкости рингтона - не то же самое что уровень громкости звука в плеере и не то же самое что громкость разговора во время звонка, например. Что вообще-то чертовски логично и ожидаемо. По поводу чего ваши претензии смотрятся, мягко говоря, очень натянутыми. А называя вещи своими именами - вы их откровенно высосали из пальца для оправдания своей персональной упертости.
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	245. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Пр0х0жий (??) on 08-Апр-13, 14:56
	> если админам в целом окажется более удобно нечто типа systemd, > вы просто останетесь без пользователей дистра. Пользователям всё равно, что удобнее админам. Но и с системд может произойти прямо до наоборот. > даже фирма Нокия применила пульсаудио на мобильном телефоне Кирпичи от Нокиа тоже умели это, где пульсаудио не может быть по-определению. > они там поюзали разные громкости звука для разных приложений dmix + softvol или где-то enable control keys Что дефолтно часто не активировано и надо подтолкнуть. Если ситуацию нельзя довести до подобного, то это уже проблемы клозет сорс.
	Ответить | Правка | ^ к родителю #216 | Наверх | Cообщить модератору

	269. "Разработчики systemd: загрузка с initrd оказалась..."	+1 +/–
	Сообщение от arisu (ok) on 08-Апр-13, 21:40
	там вообще несколько через кое-что сделано. система жестоко завязана на dbus и gconf, причем без особой на то надобности.
	Ответить | Правка | ^ к родителю #245 | Наверх | Cообщить модератору

	268. "Разработчики systemd: загрузка с initrd оказалась..."	+2 +/–
	Сообщение от arisu (ok) on 08-Апр-13, 21:37
	> А вы знаете, даже фирма Нокия, которую wakeups интересовали поболее любого альта, > раз так в эн, ибо у них батарейные девайсы, с питанием > от хиленького мобилочного акку, в свое время вполне успешно применила пульсаудио > на мобильном телефоне. и это был редкостный идиотизм, да. учитывая, что при этом нокия не дала исходников некоторых важных приложений — нормально выпилить пульсосрань не получается до сих пор. ты ведь — без сомнения — знаешь, что на N900 mplayer из-за пульса иногда подтормаживает? как, без сомнения, знаешь, что у новых пульсов другой сетевой протокол, а старый пульс на N900 апгрейднуть нельзя, ибо некоторый софт (см. выше), поэтому хвалёная «передача звука по сети» тоже не работает. это так, навскидку. конечно, доблестному китайскому комсомольцу подобные вещи в кайф. а мне вот — нет, потому что единственное, из-за чего можно было с трудом терпеть пульс — передача звука по сети — не работает.
	Ответить | Правка | ^ к родителю #216 | Наверх | Cообщить модератору

	294. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от qux (ok) on 09-Апр-13, 18:54
	> Зачем тогда такая спешка с запихиванием всех на systemd всеми правдами и неправдами? Зачем оно RH имхо очевидно, а насчет всех это вопрос к ним же. Должно быть или из-за отличного качества продукта, или из-за неудовлетворительной квалификации затаскивающих это как дефолтный init. Толсто, да, но других причин честно не придумывается.
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	178. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от etw (ok) on 08-Апр-13, 01:07
	> есть уже куча готовых программ, которые можно цеплять на обычный syslog, > они его проиндексируют, и даже в базу данных могут сложить (навскидку > GrayLog2, ElasticSearch, Solr...), и поиск в них намного лучше и фичастее. Ха-ха! Давай по пунктам: - Solr это индексатор. Сам по себе ничем не ценен - ElasticSearch то же самое - Graylog2 Начнем с того, что это сетевой сервер на джаве, требующий для работы внешний индексатор (еще один демон) и кластерную распределенную СУБД (монга). И это мы еще веб-морду не поставили, а она требует ruby on rails, rack-compatible application server, и полновесный http-демон. То, что ты предложил, предназначено для сбора логов с большого количества серверов в промышленных масштабах на выделенный под эти цели кластер. journal же нужен для похожей задачи, но только в рамках одной машины. Это совершенно разные области!
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	303. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 09-Апр-13, 23:08
	> То, что ты предложил, предназначено для сбора логов с большого количества > серверов в промышленных масштабах на выделенный под эти цели кластер. > journal же нужен для похожей задачи, но только в рамках одной машины. > Это совершенно разные области! Внимание, вопрос: зачем мне "то же самое, только в рамках одной машины"? А что применить из уже работающего крупнокалиберного по задачам, где _действительно_ есть смысл в риторике, которую слышу в пользу journal -- и так знаю.
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

36. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
Сообщение от pavlinux (ok) on 07-Апр-13, 15:00
sata_nv.parallel_scan=1
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	73. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:26
	> sata_nv.parallel_scan=1 Хм. А тыщу LVM-томов оно тоже ускорит (это не возражение, а именно вопрос)?
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	84. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:47
	залучит все
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	86. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 07-Апр-13, 16:51
	> залучит все В смысле - залучит?
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

123. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
Сообщение от Аноним (??) on 07-Апр-13, 20:14
Вот прочитал комментарии и подумал. Знаете, что самое забавное. Комментаторы столько энергии и страсти тратят на критику/защиту systemd, как будто от этого что-то зависит. А между тем весь этот процесс идет независимо от них. Я таки защищаю всех тех, кто просто делает свое дело.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	183. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 08-Апр-13, 05:41
	> Вот прочитал комментарии и подумал. Знаете, что самое забавное. Комментаторы столько энергии > и страсти тратят на критику/защиту systemd, как будто от этого что-то > зависит. А между тем весь этот процесс идет независимо от них. > Я таки защищаю всех тех, кто просто делает свое дело. Пока платят бабки чтоб процесс то не шел? Менеджер дал задание программер написал, как написал че написал всем пофиг. Главное это продать, прорекламировать и продать. Не индусские неасиляторы баша стоят дешевле, это позволяет сэкономить. Есть проблемы добро пожаловать в службу поддержки redhat. Дальше можно не писать и так понятно зачем systemd нужен и кому.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	198. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 08-Апр-13, 09:15
	Можно было вообще не писать с самого начала. Столько энергии в пустоту ущло.
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	352. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от бедный буратино (ok) on 11-Апр-13, 07:43
	> Пока платят бабки чтоб процесс то не шел? Да, кому-то платят бабки за то, чтобы процесс развития opensource не шёл. Но большинство - идейные, запуганные перспективами. Как когда-то пугали коммунизмом, что всё задушит и отберёт, так и сейчас опенсорцом.
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	350. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от бедный буратино (ok) on 11-Апр-13, 07:40
	Люди пишут злобные комментарии не от хорошей жизни. Они просто выросли в таком мире, на такой культуре. И не имеет значение, хорошее это или плохое. Люди пишут комментарии по тому, что более популярно. Потому что более резонансно. Кто-то от таких комментариев ломается (разработчики Gnome3), кто-то с большим трудом через них пробивается, постоянно оправдываясь (systemd), а кто-то просто делает то, что считает нужным, так, как считает нужным (лидеры ядра Linux, системы OpenBSD). Так выпьем же за то, чтобы всё это делало нас только сильнее.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

176. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
Сообщение от Хрен с горы on 08-Апр-13, 00:52
Ай да Леннарт, ай да сукин сын!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

187. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
Сообщение от Аноним (??) on 08-Апр-13, 07:19
а кто эта женщина в очках?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	207. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Av (??) on 08-Апр-13, 09:47
	> а кто эта женщина в очках? Ах вон оно что! Я то думаю, что это у WOT'а сервера постоянно отваливаются и тех. работы регулярнее появления тандема на экране. Так это поттеринг.
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

215. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
Сообщение от Аноним (??) on 08-Апр-13, 10:30
Я не ошибся там упомянуты сервера с тысячами дисков?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	217. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 08-Апр-13, 10:44
	> Я не ошибся там упомянуты сервера с тысячами дисков? Сервак с 40 дисков собрал вообще какой-то индивид с хабры. На коленке и вообще с виндой. По поводу чего не понятно, чего бы вдруг пингвину не работать с сотнями или даже тысячами дисков.
	Ответить | Правка | ^ к родителю #215 | Наверх | Cообщить модератору

	218. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 10:54
	Ну как бы с того кто подключить их будет ну очень проблемно. Просто жуть как проблемно. То есть в теории я не отрицаю такого, но на практике бред.
	Ответить | Правка | ^ к родителю #217 | Наверх | Cообщить модератору

	287. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Аноним (??) on 09-Апр-13, 06:40
	Adaptec RAID 72405 ASR-72405 Single PCI-E x8, 24-port SAS 24*3+6=78 ну по крайней мере 78 подрубить можно, и еще pci-e x1 остануться.
	Ответить | Правка | ^ к родителю #218 | Наверх | Cообщить модератору

	314. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от Michael Shigorin (ok) on 10-Апр-13, 00:37
	> Adaptec RAID 72405 ASR-72405 Single PCI-E x8, 24-port SAS > 24*3+6=78 Это если без экспандеров.  С другой стороны -- а оно честно не затыкается при 24 дисках?
	Ответить | Правка | ^ к родителю #287 | Наверх | Cообщить модератору

223. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
Сообщение от Аноним (??) on 08-Апр-13, 11:08
Вопрос номер раз, почему systemd не была написана раньше? Тот кто может такую написать люди умные и им она нафиг не нужна. Те кто не могут, поклоняться поттерингу.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	271. "Разработчики systemd: загрузка с initrd оказалась..."	+1 +/–
	Сообщение от arisu (ok) on 08-Апр-13, 21:50
	ну да, примерно потому же, почему двухпанельных файловых менеджеров не так много (мёртвые проекты и проекты в анабиозе не в счёт). именно потому, что пока он автору нужен, то автор не очень хорошо программирует. а когда автор хорошо программирует — уже и не нужен.
	Ответить | Правка | ^ к родителю #223 | Наверх | Cообщить модератору

228. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
Сообщение от svr on 08-Апр-13, 12:25
Centos 6.3, кусочек из killproc():         # Kill it.         if [ -n "$pid" ] ; then                 [ "$BOOTUP" = "verbose" -a -z "${LSB:-}" ] && echo -n "$base "                 if [ -z "$killlevel" ] ; then                        if checkpid $pid 2>&1; then                            # TERM first, then KILL if not dead                            kill -TERM $pid >/dev/null 2>&1                            usleep 100000                            if checkpid $pid && sleep 1 &&                               checkpid $pid && sleep $delay &&                               checkpid $pid ; then                                 kill -KILL $pid >/dev/null 2>&1                                 usleep 100000                            fi                         fi                         checkpid $pid                         RC=$?                         [ "$RC" -eq 0 ] && failure $"$base shutdown" || success $"$base shutdown"                         RC=$((! $RC)) Кусочек из status() status() {         local base pid lock_file= pid_file=         # Test syntax.         if [ "$#" = 0 ] ; then                 echo $"Usage: status [-p pidfile] {program}"                 return 1         fi         if [ "$1" = "-p" ]; then                 pid_file=$2                 shift 2         fi         if [ "$1" = "-l" ]; then                 lock_file=$2                 shift 2         fi         base=${1##*/} Про инит скрипты musqld вообще молчу. Человек, который считает что это правильно и удобно, определённо не дружит с головой
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	229. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Av (??) on 08-Апр-13, 12:40
	а что не так собственно? алгоритм не красивый? или буковки незнакомые?
	Ответить | Правка | ^ к родителю #228 | Наверх | Cообщить модератору

	233. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от svr on 08-Апр-13, 13:09
	Дебильные непараметризованные sleep и usleep, usage в status не описывает реально его функционал и прочее и прочее. Это адов бардак, писавшийся разными людьми с разными подходами, сплошные костыли и workaround'ы. Мне по работе приходится постоянно в этом центосном навозе копаться и я очень очень тоскую по systemd на своих личных компах и ноутбуках. А ещё приходится писать init'ы для использования с initctl от upstart и прочую херь, которая в systemd пишется в три-пять простых и понятных строк
	Ответить | Правка | ^ к родителю #229 | Наверх | Cообщить модератору

	234. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Av (??) on 08-Апр-13, 13:35
	Странные у вас аргументы про костыли и подходы, systemd внутри тоже не блещет фердипердозностью.
	Ответить | Правка | ^ к родителю #233 | Наверх | Cообщить модератору

	236. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от svr on 08-Апр-13, 13:58
	> Странные у вас аргументы про костыли и подходы, systemd внутри тоже не > блещет фердипердозностью. Чего странного? Я представил энтерпрайзный быдлокод, объяснил что мне в нём не нравится. И, в отличие от, для использования systemd мне в его код лезть нет необходимости. Он экономит моё время. А если systemd внутри не блещет "фердипердозностью", так я только рад: не уверен в необходимости такого блеска.
	Ответить | Правка | ^ к родителю #234 | Наверх | Cообщить модератору

	241. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Av (??) on 08-Апр-13, 14:26
	Это вы себя программируете словом "быдлокод"? Объясните чем тогда отличается изменение под свои нужды "быдлокода" и "быдлоконфига" для systemd?
	Ответить | Правка | ^ к родителю #236 | Наверх | Cообщить модератору

	243. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от svr on 08-Апр-13, 14:33
	> Это вы себя программируете словом "быдлокод"? Объясните чем тогда отличается изменение > под свои нужды "быдлокода" и "быдлоконфига" для systemd? Временем, коллега. Разбирание в кривых (а их реально много) init скриптах есть бесполезная трата времени. Конфиг сервиса для systemd представляет собой несколько простых строчек и понятен с первого взгляда. Вероятность ошибок снижается, эффективность работы повышается. Если это не очевидно - увы.
	Ответить | Правка | ^ к родителю #241 | Наверх | Cообщить модератору

	246. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Av (??) on 08-Апр-13, 14:57
	Вы теплое с мягким не путайте. Несколько строчек будет и в скрипте для запуска среднестатистического сервиса. Вы попробуйте сделать конфиг под systemd с условиями запуска, допустим, по времени запуска или версии ядра..
	Ответить | Правка | ^ к родителю #243 | Наверх | Cообщить модератору

	252. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от svr on 08-Апр-13, 15:37
	> Вы теплое с мягким не путайте. Несколько строчек будет и в скрипте > для запуска среднестатистического сервиса. Вы попробуйте сделать конфиг под systemd с > условиями запуска, допустим, по времени запуска или версии ядра.. Вот удивляют меня люди, не читающие документацию, но активно при этом спорящие. В описании сервиса в вашем случае пригодятся директивы Requires= After= ExecStartPre= а также секция [Timer]. Если, конечно, какие-то причины не позволяют использовать cron например
	Ответить | Правка | ^ к родителю #246 | Наверх | Cообщить модератору

	253. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Av (??) on 08-Апр-13, 15:49
	вот-вот! в конечном итоге для нетривиальной задачи ваш конфиг выродится в указание путей к скриптам...
	Ответить | Правка | ^ к родителю #252 | Наверх | Cообщить модератору

	254. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–2 +/–
	Сообщение от svr on 08-Апр-13, 16:42
	> вот-вот! в конечном итоге для нетривиальной задачи ваш конфиг выродится в указание > путей к скриптам... Демагог же. К чёрту авто, в нетривиальном случае придётся воспользоваться лошадью.
	Ответить | Правка | ^ к родителю #253 | Наверх | Cообщить модератору

	274. "Разработчики systemd: загрузка с initrd оказалась..."	+2 +/–
	Сообщение от arisu (ok) on 08-Апр-13, 21:54
	в тривиальном случае достаточно самоката. в нетривиальном — всё равно самому байк собирать. а непонятная конструкция, у которой 100500 ручек, но реально полезны только манипуляторы, которыми она может пощекотать механизмы, которые пыталась заменить — действительно, вряд ли нужна.
	Ответить | Правка | ^ к родителю #254 | Наверх | Cообщить модератору

	288. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+2 +/–
	Сообщение от Av (??) on 09-Апр-13, 07:47
	> Демагог же. К чёрту авто, в нетривиальном случае придётся воспользоваться лошадью. Ну-ну, софизмы до сего момента звучали от вас.
	Ответить | Правка | ^ к родителю #254 | Наверх | Cообщить модератору

	242. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от pavlinux (ok) on 08-Апр-13, 14:29
	> И, в отличие от, для использования systemd мне в его код лезть нет необходимости. А нафига тогда полез в killproc()?
	Ответить | Правка | ^ к родителю #236 | Наверх | Cообщить модератору

	244. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–2 +/–
	Сообщение от svr on 08-Апр-13, 14:34
	>> И, в отличие от, для использования systemd мне в его код лезть нет необходимости. > А нафига тогда полез в killproc()? Разгребал разнообразные глюки при shutdown'е сервера
	Ответить | Правка | ^ к родителю #242 | Наверх | Cообщить модератору

	255. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 17:06
	Ай а ссылку на багрепорт можно?
	Ответить | Правка | ^ к родителю #244 | Наверх | Cообщить модератору

	258. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от svr on 08-Апр-13, 18:14
	> Ай а ссылку на багрепорт можно? Сервисы внутрикомпанейские, собственной разработки, поэтому и багзилла внутренняя ;) Просто когда дебажишь свои поделия, приходится разбираться в стандартных библиотеках init-скриптов. А оттуда выплывает всякое...
	Ответить | Правка | ^ к родителю #255 | Наверх | Cообщить модератору

	256. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от chinarulezzz (ok) on 08-Апр-13, 18:02
	>Centos 6.3, кусочек из killproc(): глянь на код CRUX, Slackware. От людей и для людей.
	Ответить | Правка | ^ к родителю #228 | Наверх | Cообщить модератору

	257. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от svr on 08-Апр-13, 18:06
	>>Centos 6.3, кусочек из killproc(): > глянь на код CRUX, Slackware. От людей и для людей. CRUX некторое время юзал, потом ушёл на анлогичный lunar. В целом про инициализацию CRUX'а согласен: человеками и для человеков ;-)
	Ответить | Правка | ^ к родителю #256 | Наверх | Cообщить модератору

	278. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 22:06
	> CRUX некторое время юзал, потом ушёл на анлогичный lunar. Кстати, а в crux есть поддержка нескольких репозиториев? В lunar-то точно нет (поэтому я и использую до сих пор SMGL).
	Ответить | Правка | ^ к родителю #257 | Наверх | Cообщить модератору

	279. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
	Сообщение от Аноним (??) on 08-Апр-13, 22:16
	Похоже таки есть. Но там нет аналога emerge --depclean, увы.
	Ответить | Правка | ^ к родителю #278 | Наверх | Cообщить модератору

239. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
Сообщение от Аноним (??) on 08-Апр-13, 14:16
"Раньше мой линукс поднимался медленно, но когда я попробовал systemd мой линукс стал подниматься гораздо быстрее..." << >>
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

261. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+1 +/–
Сообщение от Аноним (??) on 08-Апр-13, 21:02
без systemd, еще быстрее
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

263. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	–1 +/–
Сообщение от phpcoder (ok) on 08-Апр-13, 21:13
Спасибо! Интересно было послушать, жаль что слайдов во втором видео не видно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	290. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
	Сообщение от anonymous (??) on 09-Апр-13, 08:40
	В новости есть ссылка на страницу с докладами к конференции, а там есть ссылки на все презентации.
	Ответить | Правка | ^ к родителю #263 | Наверх | Cообщить модератору

342. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."	+/–
Сообщение от anonymous (??) on 10-Апр-13, 20:38
Разработчики ненужноd: загрузка с ненужно оказалась быстрее загрузки без ненужно
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема