Доступен первый выпуск новой системы инициализации Epoch (http://universe2.us/epoch.html), позиционируемой в качестве легковесного решения для минималистичных дистрибутивов, которым необходимо обеспечить загрузку без нагромождения и лишних зависимостей. По сути, Epoch развивается в качестве альтернативы init-системы от проекта busybox, и отличающется более широкими возможностями и отказом от использования shell-скриптов для запуска сервисов. Настройки процесса загрузки определяются через единый файл конфигурации (http://universe2.us/epoch.conf). Система написана на языке Си и распространяется (https://github.com/Subsentient/epoch) как общественное достояние (http://ru.wikipedia.org/wiki/%D0%9E%D0%B.... Из зависимостей для работы Epoch требуется только Glibc, pthreads, ядро Linux (привязка к /proc) и опционально /bin/sh.Основные возможности Epoch:
- Для контроля порядка запуска и остановки сервисов используется система приоритетов, выступающая в роли упрощённого аналога зависимостей. Запуск сервисов в параллельном режиме не поддерживается;
- Встроенная система ведения лога, способная обеспечить запись информации о событиях, в том числе на стадиях до монтирования дисковых разделов на запись и без ram-диска;
- Поддержка автоматического монтирования файловых систем, подобных /dev, /proc, /sys, /dev/pts на стадии до начала запуска сервисов;- Поддержка автоматического перезапуска остановленных сервисов при помощи опции AUTORESTART;
- Для управления сервисами предлагается утилита 'epoch', позволяющая запускать и останавливать сервисы, активировать и отключать выполнение сервисов при загрузке и управлять уровнями выполнения (runlevel) без привлечения сторонних компонентов, таких как DBus и shell-скрипты инициализации;
- Отслеживание PID-файлов всех сервисов;
- Поддержка настройки имени хоста на стадии до начала запуска сервисов;
- Для обмена сообщениями с init-процессом применяется протокол membus, основанный на использовании разделяемой памяти. Протокол позволяет создавать сторонние инструменты и графические интерфейсы для управления работой системой инициализации;
- Поддерживаемые утилитой 'epoch' команды также доступны в форме отдельных псевдопрограмм, ссылающихся на один исполняемый файл (используются символические ссылки по аналогии с busybox);
- Повисший во время загрузки или остановки работы процесс можно принудительно завершить через нажатие клавиатурной комбинации Ctrl+Alt+Del;
- Поддержка настройки пользователей и групп.
URL: http://universe2.us/epoch.html
Новость: http://www.opennet.me/opennews/art.shtml?num=39039
Годное решение для выхода из неловкой ситуации команды Debian :)
Неее... Такие модные парни даже не глянут в сторону этой epoch
> Неее... Такие модные парни даже не глянут в сторону этой epochВзрослые дяди, курсовых и проч. хлама, поди, вдоволь нагляделись...
https://github.com/Subsentient/epoch/blob/master/src/actions...Ну, чо, еще один студент учится писать на этом ассемблере. Поттерингов прибыло...
> Ну, чо, еще один студент учится писать на этом ассемблере. Поттерингов прибыло...Поттеринг - это тот чувак, который учил авторов upstart, как работает линукс? (И что характерно - правильно и строго по делу учил)
Он вообще всё всегда правильно и строго по делу.
Но лучше заранее отойти чтоб не забрызгало.
> Но лучше заранее отойти чтоб не забрызгало.Да, когда манагеры идут в программирование, учить их азам чрезвычайно тяжело :)
>Поттеринг - это тот чувак, который учил всехочевидный fix)
>>Поттеринг - это тот чувак, который учил всех
> очевидный fix)Нет, только ламеров из кононикла :)
>>>Поттеринг - это тот чувак, который учил всех
>> очевидный fix)
> Нет, только ламеров из кононикла :)и ламеров из linux kernel занимающихся cgroups, alsa. Ламеров с gstreamer, производителей звуковых карт, дистрибутивостроителей, ну и так далее. Ламеров из каноникла тоже. И из enlightenment. Админов с /usr тоже учит. Да всех подряд)
Что-то не помню, чтобы он когда-то делал заявления в сторону cgroups и разработчиков ядра вообще. В ядро ламеры вообще обычно пробраться не успевают, ибо там Линус еще раньше их крепким словцом учит.
Это вменяемые, не окончательно глухие ламеры.
А Лёнчик на те слова клал с прибором.
Кажется еще у ребят из комьюнити генты были проблемы с навыками чтения манулов, но они сами одумались
> Поттеринг - это тот чувак, который учил авторов upstart, как работает линукс?
> (И что характерно…написал полную хрень, которая кое-как подходит для его локалхоста. а другие админы локалхостов — такие же тупые — теперь с этой чушью на флажке бегают.
Как оно cgi-скрипты прибивает, тоже "пиды отслеживает"? Или автор не знает что бывает при "подходящем" использовании fork()?
Блин, этот пример с cgi скриптами такой странный... Часто вы cgi скрипты используете? На хрен они вообще нужны? o_O особенно такие, что сами не дохнут...
> Блин, этот пример с cgi скриптами такой странный... Часто вы cgi скрипты
> используете? На хрен они вообще нужны? o_O особенно такие, что сами
> не дохнут...В реальной жизни выбор есть далеко не всегда. Работа админа - сделать так, чтобы все работало. Хочу, не хочу, нравится, не нравится - никого не интересует. Даже если скрипты не дохнут сами и устраивают бардак в PIDах.
> Блин, этот пример с cgi скриптами такой странный...Это, блин, не "пример с cgi скриптами", а пример того, что может сделать произвольная программулина.
> Часто вы cgi скрипты используете?
Часто.
> На хрен они вообще нужны?
Чтобы дело делать.
> Годное решение для выхода из неловкой ситуации команды Debian :)Для Debian - нет, у них есть варианты поинтереснее. А вот для Gentoo - вполне. Можно будет наконец-то прекратить измываться над трупом OpenRC.
> Для Debian - нет, у них есть варианты поинтереснее. А вот для
> Gentoo - вполне. Можно будет наконец-то прекратить измываться над трупом OpenRC.Тем более что по фичам сабж идет с OpenRC практически вровень (если не считать явной блоатвари типа сети и cgroups), но при этом на порядок меньше весит.
> блоатвари типа cgroupsЕще один школьник не выучил как работает fork? Или это все тот же?
> но при этом на порядок меньше весит
Смотря в чем измерять. Если в строках быдлокода - может и не меньше...
>> блоатвари типа cgroups
> Еще один школьник не выучил как работает fork? Или это все тот же?Идея, что система инициализации должна бегать за каждым процессом, придумал поттеринг, и продвигают ее - его фанаты. Тридцать лет sysvinit ни за кем не бегал, и ничего.
> Смотря в чем измерять. Если в строках быдлoкода - может и не меньше...
Код openrc настолько крут, что его не понимают даже нынешние разработчики (даже патчи, фиксящие ключевые баги, посмотреть не могут). А тот, кто его написал, уже давно свалил.
> Идея, что система инициализации должна бегать за каждым процессом, придумал поттеринг, и продвигают ее - его фанаты.Точнее, люди, которые не хотят думать своей головой, а слепо повторяют за другими.
> Тридцать лет sysvinit ни за кем не бегал, и ничего.И всё же почитайте про fork(2) и то, кому в каких случаях доставляется SIGCHLD.
> Тридцать лет sysvinit ни за кем не бегал, и ничего.Ага, и тридцать лет за процессами приходилось бегать админу вручную. Нафиг, пусть лучше init за ними бегает, компьютеры должны работать, а не геморрой создавать типа вот этого:
echo -n $"Stopping fail2ban: "
${FAIL2BAN} stop > /dev/null
RETVAL=$?
if [ $RETVAL = 0 ]; then
rm -f ${lockfile} ${pidfile}
echo_success
else
echo_failure
fi
Эх, мОлодеж, разве ж это геморрой?
Это код на шеле, для начинающих, работат стабильнее швейцарских часов.
И правится на раз (ну или раз, два, три).А геморрой, это когда болит пониже спины и ты с этим ничего не можешь сделать.
Вот systemd, pulseaudio — вот это правильный геморрой. Например как висел этот баг с прошлого обсуждения https://bugzilla.redhat.com/show_bug.cgi?id=1026119
>Fedora 20 fails to unmount /home, /tmp and all /dev/mapper/luks- partitions on every shutdownТак и висит. Уже и Лёньчику его показывали (как раз где он распинался как это тяжело в апстарте с размонтированием). Вот это да, это геморрой.
> Эх, мОлодеж, разве ж это геморрой?Это просто пример бажного скрипта. Видите суслика? Если нет - о чем с вами говорить...
> Это код на шеле, для начинающих, работат стабильнее швейцарских часов.
Вы не знакомы со швейцарскими часами.
>Видите суслика? Если нет - о чем с вами говорить...Вижу одного. Но даже и он сможет поправить скрипт, а вот это нет:
> https://bugzilla.redhat.com/show_bug.cgi?id=1026119
> Fedora 20 fails to unmount /home, /tmp and all /dev/mapper/luks- partitions on every shutdown.
>Вы не знакомы со швейцарскими часами.О-ля-ля. Курс лекций вангователей от похтеринга?
Прекрасный, аргументированный ответ. Великолепно вас характеризует.
> Эх, мОлодеж, разве ж это геморрой?Как меня все-таки радуют эти суровые старички =)
> Это код на шеле, для начинающих, работат стабильнее швейцарских часов.
> И правится на раз (ну или раз, два, три).У меня в системах столько этого кода на шелле, который выполняет тривиальные задачи, но в каждом место по-разному, что глаза разбегаются. Плюс к этому, он работает далеко не как швейцарские часы, а через раз и плохо. Вот от этого и появляется настоящий геморрой, о котором ты упомянул ниже.
> А геморрой, это когда болит пониже спины и ты с этим ничего
> не можешь сделать.Когда болит пониже спины, надо к проктологу идти, и он все поправит. Медицина уже давно геморрой лечит так, что потом даже не вспомнишь.
> Вот systemd, pulseaudio — вот это правильный геморрой. Например как висел этот
> баг с прошлого обсуждения https://bugzilla.redhat.com/show_bug.cgi?id=1026119
>>Fedora 20 fails to unmount /home, /tmp and all /dev/mapper/luks- partitions on every shutdownУ коллеги через стол Убунта вообще через раз вешается при шатдауне и он запарился над ней колдовать, потому что в апстарте вообще хрен поймешь куда что девается и откуда что берется. И что теперь? Поправят, не переживай. Ну, или сам поправь. У меня на федоре 20 все отлично отмонтируется и шатдаунится.
«у меня за соседним столом сидит рукожоп. поэтому столы и стулья — это плохо, ведь на них сидят рукожопы!»
>> Тридцать лет sysvinit ни за кем не бегал, и ничего.
> Ага, и тридцать лет за процессами приходилось бегать админу вручную.это плохой админ, уволь его. хороший админ, например, знает про monit, который появился далеко не вчера.
>>> Тридцать лет sysvinit ни за кем не бегал, и ничего.
>> Ага, и тридцать лет за процессами приходилось бегать админу вручную.
> это плохой админ, уволь его. хороший админ, например, знает про monit, который
> появился далеко не вчера.Справедливости для - монит *не решит* эту задачу. Если ты думаешь иначе - это достаточный признак профнепригодности.
1. monit вообще не решает задач, это инструмент, который помогает их решать. и при этом не пытается стать царём горы.
2. я не работаю администратором. мои, впрочем, задачи monit решать помогал. а у админов серьёзного парка техники наверняка есть инструменты намного мощнее, и уж что-то, а вот смена инит-системы будет только лишним геморроем.
> 1. monit вообще не решает задач, это инструментДемагогия
> 2. я не работаю администратором
Позволь спросить, а за каким ... ты тогда вставляешь тут свои пять копеек? Какой там монит тебе лично помогал решать какие задачи - абсолютно нерелевантно.
>> 1. monit вообще не решает задач, это инструмент
> Демагогиятвои проблемы.
>> 2. я не работаю администратором
> Позволь спросить, а за каким … ты тогда вставляешь тут свои пять
> копеек? Какой там монит тебе лично помогал решать какие задачи —
> абсолютно нерелевантно.я и поваром не работаю, знаешь ли. тем не менее это не помешает мне сказать, что воду в решете кипятить не очень умно.
> 1. monit вообще не решает задач, это инструментЭто называется демагогия. Суть в том, что monit - ответ неверный.
> у админов серьёзного парка техники наверняка есть инструменты намного мощнее
Ну да. Вот те же хоть cgroups.
То что один писатель руками пытается сделать из инита звезду смерти - проблемы исключительно этого писателя.
Это не значит, что античный инит нельзя улучшить с умом.
> То что один писатель руками пытается сделать из инита звезду смерти -
> проблемы исключительно этого писателя.Да, да, только он ими людей как можно больше наградить пытается :(
> Это не значит, что античный инит нельзя улучшить с умом.
Да можно, конечно.
Но, видите ли, у этого самого "писателя руками" есть очень нехорошая привычка ломать все, до чего эти самые его "руки" только могут дотянуться... Типа "есть два мнения: мое и неправильное" (С).
Были уже "товарищи", которые "разрушим до основанья, а затем...". И что из этого вышло?
> Были уже "товарищи", которые "разрушим до основанья, а затем...". И что из
> этого вышло?Это вы не к месту. Вышел СССР, который в известные периоды был куда как неплох.
>> 1. monit вообще не решает задач, это инструмент
> Это называется демагогия. Суть в том, что monit — ответ неверный.суть в том, что задачи «следить за процессами», а также активации, рестарты и ты пы — monit решает. и в pid-файлы умеет. но поскольку ты *конкретно* задачу описать не потрудился, я ответил в стиле вопроса.
> Это не значит, что античный инит нельзя улучшить с умом.
опять же, если быть точным — то НЕ НАДО, блин, инит «улучшать». вообще не надо pid 1 трогать. максимум — добавить ему канал коммуникации, по которому он о мёртвых сиротах будет сообщать, и всё. а в свете того, что netlink сейчас позволяет мониторить кучу интересных событий процесса (типа форков, экзеков и так далее), то каким-то образом связывать service management и pid 1 — вообще нафиг не упёрлось.
забавно, что это понимает не только умный автор runit, но даже и авторы upstart, которые тоже позволяют использовать upstart как service manager, не делая из него pid 1.
>>> 1. monit вообще не решает задач, это инструмент
>> Это называется демагогия. Суть в том, что monit — ответ неверный.
> суть в том, что задачи «следить за процессами», а также активации, рестарты
> и ты пы — monit решает. и в pid-файлы умеет.Что он "в пид-файлы умеет"? Ваша русская языка не понимать.
> поскольку ты *конкретно* задачу описать не потрудился, я ответил в стиле вопроса.
Я предельно ясно описал конкретную задачу: при stop сервиса - прибить *все*, что он наплодил.
>> Это не значит, что античный инит нельзя улучшить с умом.
> опять же, если быть точным — то НЕ НАДО, блин, инит «улучшать».
> вообще не надо pid 1 трогать.Говорим инит - подразумеваем sysvinit+initscripts. Здесь как раз такой случай. Да, это задача не для sysvinit, а, скорее, для того что сейчас в initscripts находится.
> забавно, что это понимает не только умный автор runit, но даже и
> авторы upstart, которые тоже позволяют использовать upstart как service manager, не
> делая из него pid 1.Ну да. Или как openrc.
Будем еще копья ломать против cgroups?
> Ваша русская языка не понимать.плохо.
>> поскольку ты *конкретно* задачу описать не потрудился, я ответил в стиле вопроса.
> Я предельно ясно описал конкретную задачу: при stop сервиса — прибить *все*,
> что он наплодил.в принципе, следить за детьми и убивать их — задача самого сервиса. но ситуация жизненная, да.
> Будем еще копья ломать против cgroups?
разупорись, пожалуйста: лично я ничего против cgroups не говорил.
> в принципе, следить за детьми и убивать их — задача самого сервиса.
> но ситуация жизненная, да.Здрасьте. Что, тоже надо man fork прописывать?
>> Будем еще копья ломать против cgroups?
> разупорись, пожалуйста: лично я ничего против cgroups не говорил.Ну и ладненько.
>> в принципе, следить за детьми и убивать их — задача самого сервиса.
>> но ситуация жизненная, да.
> Здрасьте. Что, тоже надо man fork прописывать?привет. если сервис наплодил ребятни — то уж он-то лучше знает, как им правильно сказать, чтобы они дружно выпили эвтаназии. у того же опача, насколько я помню, один процесс работает как монитор и как раз следит за ребятнёй.
это я не к постановке самой задачи, а к тому, что умеющие демонизироваться и плодить детей должны бы — по моему мнению — уметь и прибирать за собой, если их об этом попросить.
>>> в принципе, следить за детьми и убивать их — задача самого сервиса.
>>> но ситуация жизненная, да.
>> Здрасьте. Что, тоже надо man fork прописывать?
> привет. если сервис наплодил ребятни — то уж он-то лучше знает, как
> им правильно сказать, чтобы они дружно выпили эвтаназии.Мда. man fork.
> у того же
> опача, насколько я помню, один процесс работает как монитор и как
> раз следит за ребятнёй.Ну-ну. Маленький ты ишшо, не прибивал никогда толпу cgi-скриптов, после остановки апача...
> Мда. man fork.внимательно пересмотрел. выяснил, что ничего с прошлых раз не изменилось: родителю по-прежнему возвращают pid потомка. у тебя какой-то другой форк, где пиды прячут лучше, чем Военную Тайну?
> Ну-ну. Маленький ты ишшо, не прибивал никогда толпу cgi-скриптов, после остановки
> апача…какого хрена опач за ними не следит? ну, кроме того, что у авторов опача много токсичных веществ, и потому они немного не в себе? реально, авторы опача не могут посмотреть на дерево процессов? только не надо меня убеждать, что каждый cgi-интерпретатор первым делом совершает setsid(), я не верю.
>> Мда. man fork.
> внимательно пересмотрел. выяснил, что ничего с прошлых раз не изменилось: родителю по-прежнему
> возвращают pid потомка. у тебя какой-то другой форк, где пиды прячутЧитай что такое double fork.
> лучше, чем Военную Тайну?
>> Ну-ну. Маленький ты ишшо, не прибивал никогда толпу cgi-скриптов, после остановки
>> апача…
> какого хрена опач за ними не следит?Не может.
> Читай что такое double fork.ага, теперь у нас новое направление появилось. как только заметили, что оппонент таки знает про fork(), резко добавляем то, про что изначально молчали. тактика знакомая и унылая.
я, вообще-то, давно понял, куда ты ведёшь, но интересно было посмотреть, как.
>> какого хрена опач за ними не следит?
> Не может.это да, рукожопие — страшная штука. может, но не хочет.
>> Читай что такое double fork.
> ага, теперь у нас новое направление появилось."У вас" - может и появилось...
> резко добавляем то, про что изначально молчали.
Абсолютно ничего не добавлял. В ман fork тыкал еще какому-то анонимусу в самом начале треда.
> я, вообще-то, давно понял, куда ты ведёшь
Ну а раз понял, что зачем всякие "изначально молчали"?
>>> какого хрена опач за ними не следит?
>> Не может.
> это да, рукожопие — страшная штука. может, но не хочет.Я же объяснил почему не может. Во-первых - не сможет, если сам помрет. Во-вторых - у него нет штатных средств узнать pid'ы в подобных условиях (зачем двойной форк уже прочитал?).
> Ну а раз понял, что зачем всякие «изначально молчали»?интересно было, как подведёшь.
> Я же объяснил почему не может. Во-первых — не сможет, если
> сам помрет.случай экстраординарный — это надо, чтобы монитор помер. если у софта помирает даже монитор — такой софт лучше не трогать и километровой палкой. а уж на сервер ставить… ну, безумству храбрых, чо.
> Во-вторых — у него нет штатных средств узнать
> pid'ы в подобных условиях (зачем двойной форк уже прочитал?).вот жеж… а htop умеет. и даже у тех, кого сам не форкал. видать, Очень Чёрная Магия там, секретные ингредиенты. ну, или разработчики опача таки рукожопы, что намного более вероятно.
> случай экстраординарный — это надо, чтобы монитор помер.Если *каждый* сравнительно типовой сервер будет писать себе по монитору - случаев будет предостаточно.
>> Во-вторых — у него нет штатных средств узнать
>> pid'ы в подобных условиях (зачем двойной форк уже прочитал?).
> вот жеж… а htop умеет.Что умеет? Телепатически передавать пид после двойного форка? Уймись уже.
> и даже у тех, кого сам не
> форкал. видать, Очень Чёрная Магия тамЧто htop умеет и как я уже пояснял выше. Для апача такое решение, конечно, было бы неприемлемым. Это картинки можно рисовать, периодически сканируя /proc/<pid>. Ошиблись, пропустили что-то - не страшно.
>> случай экстраординарный — это надо, чтобы монитор помер.
> Если *каждый* сравнительно типовой сервер будет писать себе по монитору — случаев
> будет предостаточно.рожаешь детей — умей убивать. даже если они тоже детей рожают. не умеешь — не лезь в fork()/exec().
>> вот жеж… а htop умеет.
> Что умеет? Телепатически передавать пид после двойного форка? Уймись уже.да я-то уймусь, мне-то что. смотрю вот на tree mode в htop — и мне спокойно. автор htop — гений астральной магии: сумел построить дерево детей и pid'ы их узнать. и всё это даже без рутового доступа.
> Что htop умеет и как я уже пояснял выше. Для апача
> такое решение, конечно, было бы неприемлемым. Это картинки можно рисовать,
> периодически сканируя /proc/<pid>. Ошиблись, пропустили что-то — не страшно.конечно. лучше сразу всё пропустить, так точно не ошибёшься.
а факт же заключается в том, что механизм есть. и использовать его для нужной цели — можно. и это не чёрная магия. другие механизмы тоже есть, конечно, но — если у меня есть sql-сервер, то это далеко не всегда значит, что файлы больше вообще не нужны.
>>> вот жеж… а htop умеет.
>> Что умеет? Телепатически передавать пид после двойного форка? Уймись уже.
> да я-то уймусь, мне-то что. смотрю вот на tree mode в htop
> — и мне спокойно.Про что тебе спокойно? Ну давай я покажу тебе htop...
Нумер рас:
$ htop
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
1 root 20 0 10648 640 604 S 0.0 0.0 0:01.96 init [2]
26774 myhand 20 0 3936 80 0 S 0.0 0.0 0:00.00 ├─ ./a.outНумер двас:
$ GET http://home.test/cgi-bin/a.out
Do nasty things...
$ htop
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
1 root 20 0 10648 640 604 S 0.0 0.0 0:01.96 init [2]
27249 www-data 20 0 3940 84 0 S 0.0 0.0 0:00.00 ├─ /usr/lib/cgi-bin/a.outУпс. Чавой-то оно не показует, что в первом случае это потомок шелл, а во втором - апача.
$ cat a.c
#include <stdio.h>
#include <unistd.h>int
main(int argc, char* argv[])
{
printf("Content-Type: text/plain\r\n"
"\r\n"
"Do nasty things...\r\n");
fflush(stdout);if (daemon(0, 0))
return 1;while(1) {
sleep(600);
}return 0;
}> автор htop — гений астральной магии: сумел
> построить дерево детей и pid'ы их узнать. и всё это даже
> без рутового доступа.Тебе все уже сказали о htop - он решает задачу совсем в других условиях. *Другую* задачу. Ровно никакой магии не содержит и *данную* проблему абсолютно никак не решает.
> а факт же заключается в том, что механизм есть
Факт заключается в том, что arisu таки man fork не осилил. Или просто придуривается.
факт заключается в том, что твою нечётко поставленную задачу асилил. при этом arisu вполне не против решения задачи более адекватными методами.
> факт заключается в том, что твою нечётко поставленную задачу асилил.Т.е. у тебя htop в этом примере умудряется что-то иное показывать? Продемонстрируй, пожалуйста, патч для htop, который это умудряется делать.
> нечётко поставленную
Что может быть четче: хочу чтобы service xxx stop останавливал все, что сервис xxx наплодил.
> Ну-ну. Маленький ты ишшо, не прибивал никогда толпу cgi-скриптов,
> после остановки апача...Совсем маленькие справляются при помощи killall -u либо vzctl restart, смотря по обстановке. ;-)
>> Ну-ну. Маленький ты ишшо, не прибивал никогда толпу cgi-скриптов,
>> после остановки апача...
> Совсем маленькие справляются при помощи killall -uУгу, попутно пристреливая шеллы, at jobs, кронскрипты и проч. счастье, "смотря по обстановке".
Не барское это дело. Сказали ему stop - и пущай оно все stop.
>> Совсем маленькие справляются при помощи killall -u
> Угу, попутно пристреливая шеллы, at jobs, кронскрипты и проч. счастьеТо есть возможность убежать от пристреливания методом | at +1m устраивает? :) (не говоря о том, что шелл с правами сервиса -- немного странное явление, хотя и бывает)
В том-то и дело, что обстоятельства бывают разные. А у кого они, как и лица, только первый раз разные -- многие здесь знают не первое десятилетие.
Да, полезно выделять общие случаи и шаблонировать их во избежание повторной траты времени и сил на рутинное описание. Вот только когда вместе с сервисной cgroup пристреливают dhcpcd, поскольку нельзя заранее точно сказать, должен ли скрипт подъёма сети завершиться сразу и совсем либо что-то может продолжить самостоятельный полёт -- автоматическое бритьё начинает немножко пощипывать.
Такое вот наблюдение про "всё stop".
> Да, полезно выделять общие случаи и шаблонировать их во избежание повторной траты
> времени и сил на рутинное описание. Вот только когда вместе
> с сервисной cgroup пристреливают dhcpcd, поскольку нельзя заранее точно сказать, должен
> ли скрипт подъёма сети завершиться сразу и совсем либо что-то может
> продолжить самостоятельный полёт -- автоматическое бритьё начинает немножко пощипывать.Что-то я не понял про этот пример. Что за сервисная cgroup, для чего она и как умудрился туда попасть dhcpcd (dhcpd?)?
> Что-то я не понял про этот пример. Что за сервисная cgroup,per-service
> для чего она и как умудрился туда попасть dhcpcd (dhcpd?)?
Он туда попал в рамках выполнения /etc/rc.d/init.d/network, очевидно. dhcpCd -- ещё один DHCP-клиент.
>> Что-то я не понял про этот пример. Что за сервисная cgroup,
> per-serviceТак-так...
>> для чего она и как умудрился туда попасть dhcpcd (dhcpd?)?
> Он туда попал в рамках выполнения /etc/rc.d/init.d/network, очевидно.А с каких это пор каждый файл в /etc/init.d/ считается за сервис (тот самый, по чью душу per-service cgroups и проч)? Любую хорошую идею можно превратить во всякие systemd, кто-б спорил.
>>>> Тридцать лет sysvinit ни за кем не бегал, и ничего.
>>> Ага, и тридцать лет за процессами приходилось бегать админу вручную.
>> это плохой админ, уволь его. хороший админ, например, знает про monit,
>> который появился далеко не вчера.
> Справедливости для - монит *не решит* эту задачу.Можно формулировку крышеломной задачи для пропустивших? А то у меня уже ближе к десятилетию как раз monit и решает весьма разные. Активный локальный мониторинг с пассивным распределённым вообще оказались довольно удачной связкой.
> Можно формулировку крышеломной задачи для пропустивших?arisu не любит конкретных формулировочек.
Я напомню контекст:
#23
-->8--
> блоатвари типа cgroupsЕще один школьник не выучил как работает fork? Или это все тот же?
-->8--#31
-->8--
Идея, что система инициализации должна бегать за каждым процессом, придумал поттеринг, и продвигают ее - его фанаты. Тридцать лет sysvinit ни за кем не бегал, и ничего.
-->8--Т.е. идея была в том, что cgroups это типа блажь, стопнуть все процессы, которые наплодились в итоге от сервиса - "не надо". Ну а тов. arisu в #93 выдал вещь:
-->8--
> Ага, и тридцать лет за процессами приходилось бегать админу вручную.это плохой админ, уволь его. хороший админ, например, знает про monit, который появился далеко не вчера.
-->8--Вот я и объясняю, что monit бегать тушить поголовье наплодившихся потомков апача - пока не умеет. И что задача эта - вполне актуальная. В плохих вещах (тот же systemd) обычно есть и хорошие идеи (иначе совсем "не взлетит"), не надо фанатизма ;)
> А то у меня уже ближе к десятилетию как раз monit и решает весьма разные.
Увы, пока не такое. Да и сомнительно, что это задача для него. Отдать команду на stop/restart сервиса - это для monit. А разбираться кого и как при этом надо прибить - должен кто-то другой.
> Вот я и объясняю, что monit бегать тушить поголовье наплодившихся потомков апача
> - пока не умеет. И что задача эта - вполне актуальная.http://serverfault.com/questions/408554/use-monit-to-monitor...
> В плохих вещах (тот же systemd) обычно есть и хорошие идеи
Для меня тут дело даже не в вещи, а в характере её пропихивания. Когда вещь со своими недостатками лежит себе в сторонке и не норовит сунуться под ноги, так и пусть.
>> А то у меня уже ближе к десятилетию как раз monit и решает весьма разные.
> Увы, пока не такое. Да и сомнительно, что это задача для него.В том числе и такое, только в совокупности с openvz.
> Отдать команду на stop/restart сервиса - это для monit.
> А разбираться кого и как при этом надо прибить - должен кто-то другой.Вот этого кого-то, если не хватает встроенных тестов monit, можно написать на свой вкус.
Впрочем, и его разработчикам без недели десять лет тому парил мозг насчёт избыточности встроенного smtp-клиента: http://lists.nongnu.org/archive/html/monit-dev/2004-02/msg00... (практика показала, что за эти годы мои тогдашние опасения не подтвердились -- у этих ребят руки действительно растут из плеч).
>> Вот я и объясняю, что monit бегать тушить поголовье наплодившихся потомков апача
>> - пока не умеет. И что задача эта - вполне актуальная.
> http://serverfault.com/questions/408554/use-monit-to-monitor...Михаил, мне не смешно.
>> В плохих вещах (тот же systemd) обычно есть и хорошие идеи
> Для меня тут дело даже не в вещи, а в характере её пропихивания.Молитесь за Debian ;) Иначе "прогресс" победит и десятилетия потом будем расхлебывать.
>> Отдать команду на stop/restart сервиса - это для monit.
>> А разбираться кого и как при этом надо прибить - должен кто-то другой.
> Вот этого кого-то, если не хватает встроенных тестов monit, можно написать на свой вкус.Уж больно типовая задача (напр. "прибить нахрен все от этого сервиса"), чтобы специально ради этого танцевать каждый раз. Как раз впору для service supervisor (не смотрел пока пристально, но кажется openrc шагает правильным путем).
> Впрочем, и его разработчикам без недели десять лет тому парил мозг насчёт
> избыточности встроенного smtp-клиента: http://lists.nongnu.org/archive/html/monit-dev/2004-02/msg00...И напрасно. Для мониторилки такое вполне логично. "Сдохни - но сообщение админу передай".
> arisu не любит конкретных формулировочек.ты херовый телепат. чип телепатии, небось, в подворотне у хромого китайца брал? знаю я этого китайца, у него палёный товар.
и да: cgroups — не единственный метод решения. поскольку всё равно завязка на пингвинусы, то и netlink позволяет решить задачу, отмониторив форки/экзеки. да и без netlink'а htop, например, как-то умеет магически дерево процессов рисовать.
(пожимает плечами) мог бы и не выпендриваться, а повторить задачу сразу. да, не умеет. и не будет уметь, насколько знаю, потому что его не хотят делать зависимым от linux. вижу место для небольшого тулбокса к мониту, например, который можно отдельно от него распространять.
> и да: cgroups — не единственный метод решенияНе единственный. Но на других платформах - есть другие решения.
Что не отменяет возможности сделать интерфейс к этому счастью - вполне платформо-независимым. Без безумной практики тащить в свой "продукт" каждый пук из ядра Linux - в этом нет ничего невозможного.
> и без netlink'а htop, например, как-то умеет магически дерево процессов рисовать.
htop - это просто красивая смотрелка. Не удивлюсь, если там делается что-то подобное тому как дитятко из subj этого топика "пиды отслеживает".
Для рисовалки - это подходит. Но и только.
> (пожимает плечами) мог бы и не выпендриваться, а повторить задачу сразу. да,
> не умеет. и не будет уметь, насколько знаю, потому что его
> не хотят делать зависимым от linux.Нет. Потому что это *не его задача*. monit должен решать на основе своих тестов и их зависимостей - какие действия предпринять. После чего - отдать соответствующие команды. В частности, /etc/init.d/service stop.
> Идея, что система инициализации должна бегать за каждым процессом, придумал поттеринг,
> и продвигают ее - его фанаты.Совершенно не обязательно.
> Тридцать лет sysvinit ни за кем не бегал, и ничего.
Ничего что? Ничего хорошего.
>> Смотря в чем измерять. Если в строках быдлoкода - может и не меньше...
> Код openrc настолько крут, что его не понимают даже нынешние разработчикиНу, я и не спорю. Просто этот shit я посмотрел, а разобраться с openrc руки пока не дошли.
Спасибо, мы уж лучше как-нибудь с OpenRC и mdev помучаемся.
> Спасибо, мы уж лучше как-нибудь с OpenRCТогда уж лучше сразу системГ. Блоатварить - так по полной!
Нет, не лучше.
OpenRC вполне можно до ума довести.
> Нет, не лучше.
> OpenRC вполне можно до ума довести.Ну выходит, что среди гентушников одни слабоумные, раз до сих пор не сделали этого? Хотя действительно были моменты, когда я задумывался над адекватностью комьюнити
Там адекватность как раз не так давно появилась, с тех пор как весь неадекват на арчик убежал.
Вот как он ушёл, так всё и наладилось.
Вон #60 пример, ему про Фому, он про Ерёму.
>> Годное решение для выхода из неловкой ситуации команды Debian :)
> Для Debian - нет, у них есть варианты поинтереснее. А вот для Gentoo - вполне.У меня как-то пока больше доверия к разработчикам генты (основная шпана вроде оттуда сбежала, не?), чем к этому безымянному писателю руками.
> У меня как-то пока больше доверия к разработчикам генты (основная шпана вроде оттуда сбежала, не?)Да, разработчик OpenRC оттуда ушел, а оставшиеся не могут разобраться, что он там написал.
Еще показательный пример - спросите у гентушников, почему portage тормозит сильнее yum'а :)
>> У меня как-то пока больше доверия к разработчикам генты (основная шпана вроде оттуда сбежала, не?)
> Да, разработчик OpenRC оттуда ушел, а оставшиеся не могут разобраться, что он
> там написал.
> Еще показательный пример - спросите у гентушников, почему portage тормозит сильнее yum'а
> :)Причем здесь портедж? Вы путаете теплое с мягким.
>>> У меня как-то пока больше доверия к разработчикам генты (основная шпана вроде оттуда сбежала, не?)
> Причем здесь портедж? Вы путаете теплое с мягким.А я всегда думал, что портедж делают разработчики генты, а оказывается нет.
Ну уж Вы скажете тоже. Сильнее yum'a тормозить физически невозможно.А ведь такой хороший был проект apt-rpm, и работал, и хорошо работал, не говоря уж про быстро.
Но yum всех забодал.
>Еще показательный пример - спросите у гентушников, почему portage тормозит сильнее yum'а :)Ответ гентушника: "А что такое yum?"
Нынче делать системы инициализации популярней, чем плееры.Хотя у этой есть хотя бы какие-то killer фичи и конкретная область применения.
Да-да, я подобное нытье уже лет 15 слышу.
На плееры, браузеры, растровые и векторные редакторы, текстовые процессоры, rss-ридеры, инстант мессенджеры, торент-клиенты, WM, DE, аудиоподсистемы, системы контроля версий и т.д. и т.п.
Нытики приходят и уходят, а кол-во годного софта (с отмиранием тупикового) увеличивается и увеличивается.
Кто-то ныл про векторные редакторы? о_О Что есть, помимо inkscape? Который является довольно тормозной и падающей какашкой.RSS ридеров тоже не много.
>растровые и векторные редакторыПоявилось что-то кроме Gimp и Inkscape?
>rss-ридеры
Как гуглоридер помер, так вместе с ним и RSS, ну не считая нескольких маргиналов ушедших на Feedly.
>текстовые процессоры
Как их было два, vim да Emacs, так и осталось вроде.
>кол-во годного софта (с отмиранием тупикового) увеличивается и увеличивается
Теперь смотрим к чему это относится и ставим "годный" в кавычки.
>плееры, rss-ридеры, инстант мессенджеры, торент-клиенты, WM, DE, аудиоподсистемыСамые нужные вещи, надо бы их еще побольше.
> Появилось что-то кроме Gimp и Inkscape?Был как минимум xfig, появились как минимум Krita и sK1/PrintDesign.
> Как гуглоридер помер, так вместе с ним и RSS
А что такое гуглоридер? Что такое RSS, знаю.
>>текстовые процессоры
> Как их было два, vim да Emacs, так и осталось вроде.Пожалуй, единственное верное (IMHO2) утверждение. :)
> Был как минимум xfigЧто значит "был"?
http://www.xfig.org/art17.html
>> Как их было два, vim да Emacs, так и осталось вроде.
> Пожалуй, единственное верное (IMHO2) утверждение. :)Был один, один и остался. Да в vim даже тетриса нет!!!
>> Был как минимум xfig
> Что значит "был"?"Уже был", в смысле. :)
> Был один, один и остался. Да в vim даже тетриса нет!!1
Ох, сколько же с Вас ещё этот юношеский максимализм сошкуривать.
>>> Был как минимум xfig
>> Что значит "был"?
> "Уже был", в смысле. :)На дату смотрите.
>> Был один, один и остался. Да в vim даже тетриса нет!!1
> Ох, сколько же с Вас ещё этот юношеский максимализм сошкуривать.
> http://www.vim.org/scripts/script.php?script_id=172Читаем:
The first (I hope) interactive game inside pure VIM!Не, спасибо. У нас игрушек таки больше, и за ними не надо по варезникам разным шастать...
>> Как гуглоридер помер, так вместе с ним и RSS
> А что такое гуглоридер? Что такое RSS, знаю.Самый популярный rss агрегатор прикрытый этим летом гуглом. Сейчас замена: http://feedly.com
> Как гуглоридер померЯ вообще не понимаю зачем для RSS нужен какой-либо дополнительный софт сверх того, что предоставляет сам браузер и расширения к нему. Как пользовался Feed Sidebar в Firefox, так и пользуюсь лет 5 уже, наверное.
>> Как гуглоридер помер
> Я вообще не понимаю зачем для RSS нужен какой-либо дополнительный софт сверх
> того, что предоставляет сам браузер и расширения к нему. Как пользовался
> Feed Sidebar в Firefox, так и пользуюсь лет 5 уже, наверное.Например для того чтобы прочитанные на смартфоне автоматом отмечались как прочитанные при просмотре с компьютера.
Вот бы чего такое в опенврт вместо тормозной скриптятины, которая по 30+ секунд сопли жует :).
> Вот бы чего такое в опенврт вместо тормозной скриптятины, которая по 30+
> секунд сопли жует :).лол, запихни все что тебе нужно в нужном порядке в аналог rc.local
а я люблю обмазываться несвежими системами инициализации и перезагружать роутер
даёшь systemd-epochd ,init init-a для коллекции.
> даёшь systemd-epochd ,init init-a для коллекции.Инит инита - это в gentoo, там вначале стартует sysvinit, который запускает openrc.
Неплохо.Формат конфигов напоминает systemdшные, только все файлы всех служб слиты в один -довольно неудобно, особенно для мейнтейнеров всяких демонов - непонятно, как скрипт поставлять. К тому же, включение и выключение служб - разбросаны по секциям соответствующих служб, а не как в старом арчевском ините (одна переменная DAEMONS).
> Запуск сервисов в параллельном режиме не поддерживаетсяВ таком случае смысл этого "общественного достояния" только в том что
> опционально /bin/sh? :)
>> Запуск сервисов в параллельном режиме не поддерживается
> В таком случае смысл этого "общественного достояния" только в том чтоНу, в OpenRC тоже по факту не поддерживается. Рандомно возникают циклы зависимостей, и все виснет. Разрабам даже присылали патч, но они не осилили разобраться в сишной части сорцов :)
>> опционально /bin/sh
> ? :)Epoch умеет запускать однострочники на шелле, если знает, где находится шелл.
>>В таком случае смысл этого "общественного достояния""позиционируемой в качестве легковесного решения для минималистичных дистрибутивов"
http://universe2.us/collector/Epoch-2013-12-28.png
кажется вся эта байда с параллелизацией загрузки - одна большая ж, которая не оправдалась. Больше проблем стало, а скорость загрузки практически одна и та же. Чтоб уйти от этого: сравнивается классический инит и новые системы инициализации по количеству фич. При этом, сложность новых инитов увеличилась, но зато это уже объясняется большим охватом задач. Внезапно инит стал уже системным менеджером, а сложность(минус) оправдывается количеством фич(плюс). Нужность этих фич в ините - прогрессом. А необходимость этого прогресса и переход на него - наличием фантомных проблем с sysvinit'ом, которые никто не озвучивает, а озвучив не исправляет. Не исправляют и новые системные менеджеры: тогда ради чего это всё?jff.
> фантомных проблем с sysvinit'ом, которые никто не озвучиваетВот мне интересно, кто первый придумал про "никто не озвучивает", и почему все не задумываясь подхватили эту чушь.
Неужели в самом деле все молчат, и никто так ни слова и не сказал о недостатках и проблемах sysvinit? Вроде бы столько уже было обсуждений об этом, что даже те кто не особо интересовался (как я например) и то всё увидели и услышали.Скорее похоже на то, что все аргументы против sysvinit вы просто игнорируете, вам проще их назвать "пиар и пропаганда systemd", повесить ярлык и забыть. Что-то типа избирательного восприятия.
Вы, конечно, можете со всеми этими аргументами не соглашаться - ваше право, но глупо же делать вид что их вообще не существует и никто их никогда не озвучивал, или вы действительно в это верите?Те же дебиановцы даже специальные страницы в своей вики сделали с изложением своих позиций, чтобы не отвечать в сотый раз на одни и те же вопросы, и чтобы те, кто только что вернулся из анабиоза, могли бы ознакомиться с существующими аргументами за и против. Если бы вы в самом деле пытались разобраться в вопросе, мимо них сложно было бы пройти.
Нет, не придумал.
Нет, не чушь.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#4832
> Нет, не придумал.
> Нет, не чушь.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#4832Сам-то читал? Или ссылку тоже копипастишь, не понимая что там?
Sergey B Kirpichev <skirpichev@gmail.com> writes:
> I just wonder why nobody from tect-ctte take care about the exact
> specification of that "bare minimum" (or, in other words, what exactly
> is wrong with sysvinit).(Сергей Кирпичев пишет: "Мне просто интересно почему никто из TC не позаботился о точной спецификации того самого "минимума" (или, иначе говоря, что именно не так с sysvinit")
Ему отвечают:
In a sense, we all have done this, even if you don't see it explicitly
written in just this way.
("В определенном смысле, мы все сделали это, даже если ты не видишь этого, написанного именно таким образом.")А можно заодно и следующий коммент посмотреть, где тому же Сергею Кирпичеву опять же отвечают:
Coming late to this bugreport and asking questions that have already been
asked and answered many times before, yet feeling entitled to be able
to talk about what others did: good luck with that, but as already
mentioned to other people: I can provide the various emails that we
reached out and did our best. I can also show you that all the
questions you're asking have been asked and answered before. Maybe
investigate a little bit before forming your opinion!(Перевод: Приходишь поздно в этот багрепорт и задаешь вопросы, которые уже были заданы и отвечены много раз до этого, и тем не менее чувствуешь себя наделенным правом говорить о том, что делали другие - удачи с этим, но как уже было сказано другим людям, я могу предоставить различные письма, с которыми мы обращались и прилагали все усилия. Я могу также показать тебе что все вопросы которые ты задаешь уже были заданы и отвечены ранее. Может, разберись слегка прежде чем составлять свое мнение!)
Отсюда вывод - человек бросился в атаку на системд даже не почитав тред для начала, и не изучив мнения других сторон, либо просто их игнорируя. В общем все так, как принято на опеннете.
> ("В определенном смысле, мы все сделали это, даже если ты не видишь
> этого, написанного именно таким образом.")Это нельзя сделать "определенным образом" - это можно сделать одним единственным: взять и перечислить то, что мы собираемся исправить в sysvinit. Или иначе: что мы хотим, чтобы инит делал (не systemd/upstart/<любой иной предмет анонимного фапа>).
> Coming late to this bugreport and asking questions that have already been
> asked and answered many times beforeВы можете пальцем ткнуть туда, где он был "answered"? За и против разных программулин - это не ответ на данный конкретный вопрос.
> Отсюда вывод - человек бросился в атаку на системд
Человек даже не упомянул системд:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#4702> даже не почитав
Все прям как ты...
> кажется вся эта байда с параллелизацией загрузки - одна большая ж, которая
> не оправдалась. Больше проблем стало, а скорость загрузки практически одна и та же.Она не про скорость, она про зависимости. ПонЯл?
> При этом, сложность новых инитов увеличилась,
> но зато это уже объясняется большим охватом задач.Это уже проблемы писателей руками этих "инитов".
Откуда в новости бред про busybox? На сайте этой поделки:
"I didn't want to use busybox init
because it wasn't featureful enough and to achieve the desired effect
would require miles of shell script, and what I did before
(using pure shell script with calls to the busybox binary for power control)
was hideous and unsafe."
Сам проект - дерьмо. Код - дерьмо. Прибит гвоздями к "bash-compatible shell", linux и glibc + требует snprintf. Т.е. для эмбедовки это никак не подходит, фактически.
NIH-синдром хуже поттеринга.
> Прибит гвоздями к [...] glibc + требует snprintfВозможно, эта часть проблемы решается линковкой с musl вместо glibc: http://www.musl-libc.org http://www.etalabs.net/compare_libcs.html
> Прибит гвоздями к "bash-compatible shell",
> linux и glibc + требует snprintf. Т.е. для эмбедовки это никак
> не подходит, фактически.snprintf попрошу не трогать. Одна из самых полезных вещей в С99 лично для меня. Вот башизмы и gnu-змы действительно странно, если так.
>> Прибит гвоздями к "bash-compatible shell",
>> linux и glibc + требует snprintf. Т.е. для эмбедовки это никак
>> не подходит, фактически.
> snprintf попрошу не трогать. Одна из самых полезных вещей в С99 лично
> для меня. Вот башизмы и gnu-змы действительно странно, если так.snprintf я не трогаю, мне не нравится, что даже систему инициализации люди не могут по-человечески написать уже, портабельно и без жестко заданных зависимостей.
Потом эти люди начинают брать с++ и qt там, где можно было обойтись чистым С, только потому, что разрабатывать им так "привычнее" в каком-нибудь qtcreator.
Зачем вообще инит на Си, все эти "параллельные загрузки"? Не зря его еще 30 лет назад написали на sh. Велосипедисты хреновы.
> snprintf я не трогаю, мне не нравится, что даже систему инициализации люди
> не могут по-человечески написать уже, портабельно и без жестко заданных зависимостей.Написать могут (sysV/BSD, почти). Но недовольные и тут находятся.
> Потом эти люди начинают брать с++ и qt там, где можно было
> обойтись чистым С, только потому, что разрабатывать им так "привычнее" в
> каком-нибудь qtcreator.Скажите спасибо, что не Java/C# %)
> Зачем вообще инит на Си, все эти "параллельные загрузки"?
На Си большинство системщины. В параллельных загрузках, по идее, смысл тоже есть — зачем запускать В после А, если им друг на друга параллельно. Тут не это корень зла.
Еще одна система инициализация - легковесней некуда:
Another Init System: Sinit - The Suckless Init System
http://www.phoronix.com/scan.php?page=news_item&px=MTU5NTI
Чем старые добрые bash-скрипты не нравились? Десятилетиями работали. А сейчас зачесалось перейти на что-то эдакое, бинарное, новомодное. На UNIX-культуру всем совсем наплевать что ли?!
> Чем старые добрые bash-скрипты не нравились? Десятилетиями работали.Тем что в каком-нить опенврт это нечто секунд по 30 стартует. Напрягает, однако.
А как же UNIX-way?
> А как же UNIX-way?А ты скажешь где его нарушили?
Вангую «Пусть каждая программа делает что-то одно, но хорошо» (до которого обычно весль UNIX-way сводят почему-то) и заранее смеюсь.
> А как же UNIX-way?Принципы unix-way следует применять вместе со здравым смыслом, а не вместо него.
К тому же один из принципов unix-way вроде подразумевает использование отдельных программ, выполняющих каждая свою определенную задачу, а Вы почему-то предлагаете использовать один универсальный и громоздкий комбайн (интерпретатор скриптов) для выполнения всех задач.
>> А как же UNIX-way?
> Принципы unix-way следует применять вместе со здравым смыслом, а не вместо него.Здравый смысл вам не подсказывает, что прежде чем рассуждать о к-л принципах - нужно о них знать?
> К тому же один из принципов unix-way вроде подразумевает использование отдельных программ
Ключевое слово - "вроде".
> Вы почему-то предлагаете использовать один
> универсальный и громоздкий комбайн (интерпретатор скриптов) для выполнения всех задач.Человек дело говорит. Rule of Generation: не пишите на ассемблерах все подряд.
>> Вы почему-то предлагаете использовать один
>> универсальный и громоздкий комбайн (интерпретатор скриптов) для выполнения всех задач.
> Человек дело говорит. Rule of Generation: не пишите на ассемблерах все
> подряд.Так никто и не пишет. Кстати, а у Вас случайно нет баша, написанного на скриптах?
>>> Вы почему-то предлагаете использовать один
>>> универсальный и громоздкий комбайн (интерпретатор скриптов) для выполнения всех задач.
>> Человек дело говорит. Rule of Generation: не пишите на ассемблерах все
>> подряд.
> Так никто и не пишет.Поттеринг ваш пишет. Весь уже исписался.
ЧуваГ, ты не поверишь, но свой «скрипт» запуска ты можешь хоть на си написать.
(start/stop/… пусть только принимает и всё)
Просто никому это и в голову не приходит, когда баш итак 100% закэширован.И да, заметь, он хоть и универсальный (т.е. будет висеть в памяти компа всё-равно. либо сам, либо ещё и вместе с systemd) но куда меньше последнего (не считая встроенного http-сервера, генератора qr-кодов,…)
$ ls -l /usr/lib/systemd/systemd
-rwxr-xr-x 1 root root 1043760 дек 6 05:45 /usr/lib/systemd/systemd
$ ls -l /bin/bash
-rwxr-xr-x 1 root root 742088 ноя 29 05:20 /bin/bash
$ ls -l /sbin/init
-rwxr-xr-x 1 root root 43696 июн 6 2013 /sbin/initОфигенное?, «узкоспециализированное» решение.
> ЧуваГ, ты не поверишь, но свой «скрипт» запуска ты можешь хоть на си написать.Это замечательно, но я не хочу писать свои скрипты запуска, я может хочу вместо этого потратить время на размышления о смысле жизни и устройстве вселенной.
> И да, заметь, он хоть и универсальный (т.е. будет висеть в памяти компа всё-равно. либо сам, либо ещё и вместе с systemd) но куда меньше последнего
Кажется ты еще забыл посчитать сами скрипты, все утилиты используемые из этих скриптов, и т.д., хотя я и не понимаю, в чем смысл меряться размерами систем инициализации.
> Офигенное?, «узкоспециализированное» решение.
По сравнению с башем - да. Systemd решает ограниченный набор задач, под которые он написан, и он решает эти задачи эффективнее, чем баш. Точнее, чем баш мог бы их решать, если бы к нему еще существовали и скрипты с такой же функциональностью.
>ограниченный набор задачС каждым новым Лёниным коммитом это становится всё менее похоже даже на шутку.
>>ограниченный набор задач
> С каждым новым Лёниным коммитом это становится всё менее похоже даже на
> шутку.Добавление новых возможностей - естественный путь развития любого проекта, с каких пор это считается чем-то плохим?
Предпочитаете проекты, которые развиваются в сторону уменьшения функциональности?
Безусловно это так.
Разница только в деталях реализации — увеличение функциональности за счёт автономной модульности либо нет.
Встраивание в один блоб системы инициализации, http-сервера, генератора qr-кодов, udev,… это явно из разряда «нет».
> Встраивание в один блоб системы инициализации, http-сервера,Если ты имеешь в виду journal-gatewayd, то например у меня даже пакет с ним не установлен. "Встраивание в один блоб" и опциональный пакет - немного разные вещи, если ты не в курсе.
И почему вы так любите любые байки повторять без проверки фактов?
А потом еще и удивляетесь, почему вас никто в нормальных технических обсуждениях не воспринимает всерьез.> генератора qr-кодов
Тоже используется отдельный пакет, qrencode-libs.
А вообще, предлагаю вам новую идею: в утилите ls есть возможность сортировки файлов. Очевидно, это дублирование sort, и готов поспорить, что это все поттеринг виноват, предлагаю эту возможность скорее удалить из блоба ls, пока никто не заметил, и использовать внешние утилиты - sort и т.д., или даже простой и всем понятный шелл-скрипт для сортировки, чисто ради простоты, модульности и unixwayности. И вообще coreutils давно пора разбить на отдельные пакеты, а то это какая-то монополия, нельзя заменить одну из утилит.
Не дадим блобизировать наш linux, даешь минимум возможностей в каждой программе! Ура, товарищи!
>Встраивание в один блоб" и опциональный пакет - немного разные вещиопциональный и автономный — тоже.
>> Встраивание в один блоб" и опциональный пакет - немного разные вещи
> опциональный и автономный — тоже.Предлагаю вернуться к этому вопросу, как только у тебя initscripts заработают автономно от интерпретатора скриптов.
>>> Встраивание в один блоб" и опциональный пакет - немного разные вещи
>> опциональный и автономный — тоже.
> Предлагаю вернуться к этому вопросу, как только у тебя initscripts заработают автономно
> от интерпретатора скриптов.Вот как только сыстемГы без компилятора (gcc или любого другого) заработает (сразу так из исходников) - так сразу к этому вопросу и вернемся ;)
> почему вас никто в нормальных технических обсуждениях
> не воспринимает всерьез.потому что вокруг системды прыгают клоуны, какие там могут быть «технические обсуждения»? вон, ваш портеринг недавно рассказывал, как систему надо шатдаунить — это же детский сад, штаны на лямках и одмин локалхоста. о чём с вами говорить, если ваш лидер порет чушь и не краснеет?
>> почему вас никто в нормальных технических обсуждениях
>> не воспринимает всерьез.
> потому что вокруг системды прыгают клоуны, какие там могут быть «технические обсуждения»?
> вон, ваш портеринг недавно рассказывал, как систему надо шатдаунить — это
> же детский сад, штаны на лямках и одмин локалхоста. о чём
> с вами говорить, если ваш лидер порет чушь и не краснеет?Что ж ты его не поправил?
Кстати, дай угадаю, о его словах ты наверное судил по пересказам других местных аналитиков?
> Что ж ты его не поправил?потому что это отлично сделали до меня.
> Кстати, дай угадаю, о его словах ты наверное судил по пересказам других
> местных аналитиков?не суди других по себе.
>> Что ж ты его не поправил?
> потому что это отлично сделали до меня.Дай угадаю, здесь поправили, на опеннете? Или ему самому написали где-то?
>> Кстати, дай угадаю, о его словах ты наверное судил по пересказам других
>> местных аналитиков?
> не суди других по себе.Не, я просто помню твои комменты на эту тему, где ты почитав, наверное, чей-то "художественный" перевод и не разобравшись, начал обсуждать, при этом было очевидно что ты его слова в оригинале либо вообще не читал, либо специально исказил. А может ты просто сам их не понял, хотя в этом я сомневаюсь.
> Дай угадаювот поэтому я и сказал: «не суди по себе». попробуй представить, что некоторые умеют ходить по ссылкам и свободно читают на английском. я понимаю, в это может быть сложно поверить, но так бывает.
впрочем, тебе всё «очевидно», ты же опеннет читал.
>Это замечательно, но я не хочу писать свои скрипты запуска, я может хочу вместо этого потратить время на размышления о смысле жизни и устройстве вселенной.А кто заставляет? Не пиши.
>Кажется ты еще забыл посчитать сами скрипты, все утилиты используемые из этих скриптов,Это давно уже сделано. И тут это тоже обсуждалось. Могу привести ещё раз
>OpenRC (0.9.3): sysvinit + 300 files, ~30k lines, 3.3k posix sh, ~12k C
>Upstart (1.5): 285 files, ~185k lines, ~97k C
>Debian: sysvinit + 120 files, 5.8k lines
>systemd (v44+): dbus + glib + 900 files, 224k lines, 125k C
>sysvinit: 560kB, 75 files, ~15k lines
>D-Bus: 11MB, ~500 files. 300k lines, 120k C
>glib: 72MB, ~2500 files, ~1.7M lines, ~430k Chttps://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems
>и т.д., хотя я и не понимаю, в чем смысл меряться размерами систем инициализации.Ну, вякать это про (цитата) универсальный и громоздкий комбайн тебя не остановило.
Теперь вот дал задний ход — оказывается это не важно.
>По сравнению с башем - да. Systemd решает ограниченный набор задач, под которые он написан, и он решает эти задачи эффективнее, чем баш.А это вообще просто брехня и маркетинговый булшит. Честно говоря кроме лозунгов от вас ничего и не ожидал.
> А кто заставляет? Не пиши.Ну почему-то многие считают, что я должен их писать, или что мне придется их писать. Рассказывают мне зачем-то, как это просто и легко с sysvinit.
Звучит примерно как если, например, при покупке батареи отопления мне будут рассказывать, что когда ее прорывает, можно все без труда за 10-15 минут заделать с помощью подручных средств и удобных инструментов, которые так удачно входят в комплект, и за минимальную цену.>>Debian: sysvinit + 120 files, 5.8k lines
Ну раз тебе все-таки приспичило померяться, давай тогда уж для точности добавим весь софт, который хотя бы приблизительно позволит воспроизвести возможности systemd, чтобы сравнивать яблоки с яблоками. Всякие там рсислоги, инетд и прочее.
>>По сравнению с башем - да. Systemd решает ограниченный набор задач, под которые он написан, и он решает эти задачи эффективнее, чем баш.
> А это вообще просто брехня и маркетинговый булшит. Честно говоря кроме лозунгов
> от вас ничего и не ожидал.Ну ладно хоть не "пиар и пропаганда", хоть какое-то разнообразие.
Что именно там брехня? Баш эффективнее решает задачи, скажем, взаимодействия с cgroups, или с каким-нибудь dbus, или параллельного запуска сервисов?
Или может брехня то, что "Systemd решает ограниченный набор задач, под которые он написан"?
>> А кто заставляет? Не пиши.
> Ну почему-то многие считают, что я должен их писать, или что мне придется их писать. Рассказывают мне зачем-то, как это просто и легко с sysvinit.Ещё раз, я рассказываю как МНЕ легко их писать и отлаживать.
На ВАС мне, извините, нас рать.
И это вы мне доказываете, что я должен выбрать systemd, а не наоборот.
>>>Debian: sysvinit + 120 files, 5.8k lines
>Ну раз тебе все-таки приспичило померяться, давай тогда уж для точности добавим весь софт,Вам, юноша, вам.
И вы вначале докажите зачем мне эта вся функциональность для НЕуниверсального решения.
Баш я по крайней мере повторно использую ещё в сотне-другой проектов, а systemd только для того, что компьютер стартанул.
>Что именно там брехня? Баш эффективнее решает задачи, скажем, взаимодействия с cgroups, или с каким-нибудь dbus, или параллельного запуска сервисов?Всё брехня и булшит. Начиная с того, что когда вам надо, то вы требуете приплюсовать к башу кучу специализированного софта, а когда вам это не выгодно, говорите только о баше.
> Ещё раз, я рассказываю как МНЕ легко их писать и отлаживать."ЧуваГ, ты не поверишь, но свой «скрипт» запуска ты можешь хоть на си написать."
Не твои слова?Почему-то счетовод Иван Палыч из колхоза "Путь Ильича" мне не рассказывает, как легко и удобно считать на счетах, потому что компьютер он так и не освоил. Наверное, потому что понимает, что мне не интересно, на чём он там считает.
Так почему ты думаешь, что для меня имеет какое-то значение информация о том, легко ли тебе писать скрипты?> И это вы мне доказываете, что я должен выбрать systemd, а не наоборот.
Тебе показалось. Мне вообще-то всё равно, что ты себе выберешь.
Если ты до сих пор не заметил, разговор в ветке вообще шел о проекте из новости vs скрипты+баш, и о роутерах, по крайней мере до тех пор, пока ты зачем-то systemd не приплел сюда. Заметь, ТЫ это сделал, а не я. Это из серии "у кого что болит", наверное...
Я просто из вежливости разговор поддержал. :)> Всё брехня и булшит. Начиная с того, что когда вам надо, то вы требуете приплюсовать к башу кучу специализированного софта, а когда вам это не выгодно, говорите только о баше.
Я предложил приплюсовать кучу софта к башу, только когда ТЫ зачем-то начал сравнивать его размер с systemd, чтобы твое сравнение имело смысл. Пока ты не начал говорить о systemd, не было смысла и говорить о другом софте, необходимом для замены systemd. У тебя, кажется, просто какие-то проблемы с логикой.
>> Ещё раз, я рассказываю как МНЕ легко их писать и отлаживать.
> "ЧуваГ, ты не поверишь, но свой «скрипт» запуска ты можешь хоть на си написать."
> Не твои слова?И? Это как-то оправдывает твой пук о «громоздком комбайне». :D
зыж
>Я предложил приплюсовать кучу софта к башу, только когда ТЫ зачем-то начал сравнивать его размер с systemd,Ты его приплюсовываешь когда думаешь(!!!:D), что это тебе выгодно.
Например тут «использовать один универсальный и громоздкий комбайн».
При этом даже был не в курсе дела, что баш+скрипты+инит+базибокс меньше systemd.
Оставаясь при этом универсальным решением и для других применений в процессе работы.
>Я просто из вежливости разговор поддержал. :)Да брось.
Ты и вежливость — ортогональны.
> И? Это как-то оправдывает твой пук о «громоздком комбайне». :D
> Например тут «использовать один универсальный и громоздкий комбайн».Попробую еще раз, последний: это было сказано, когда речь шла о проекте из новости vs bash. О systemd вообще речь не шла, пока ты не появился.
И да, баш по сравнению с проектом из новости - это именно "универсальный и громоздкий комбайн".
> Ну раз тебе все-таки приспичило померяться, давай тогда уж для точности добавим
> весь софт, который хотя бы приблизительно позволит воспроизвести возможности systemd,
> чтобы сравнивать яблоки с яблоками. Всякие там рсислоги, инетд и прочее.И что же в systemd такого есть, что он уже научился выполнять работу rsyslog? Ты ведь не про поделку под названием jornald, пригодную исключительно для локалхостов анонимов, нет?
> Или может брехня то, что "Systemd решает ограниченный набор задач, под которые
> он написан"?Конечно. Тебя не затруднить предоставить список этого "ограниченного набора"? А то httpd-сервер там вроде уже есть - ждем когда полный LAMP запихнут?
>> Ну раз тебе все-таки приспичило померяться, давай тогда уж для точности добавим
>> весь софт, который хотя бы приблизительно позволит воспроизвести возможности systemd,
>> чтобы сравнивать яблоки с яблоками. Всякие там рсислоги, инетд и прочее.
> И что же в systemd такого есть, что он уже научился выполнять
> работу rsyslog?Если что, я нигде и никогда не утверждал, что systemd может делать все, что может rsyslog. Я как раз говорил об обратном, об использовании rsyslog и прочего, чтобы делать то, что может systemd/journald.
Почему у противников systemd всегда такие проблемы с точным пониманием сказанного?>> Или может брехня то, что "Systemd решает ограниченный набор задач, под которые
>> он написан"?
> Конечно. Тебя не затруднить предоставить список этого "ограниченного набора"?Что за привычка спрашивать очевидные вещи, которые гуглятся на раз-два? Или это просто такой способ ведения дискуссии - заваливание оппонента просьбами продублировать общедоступную информацию, когда самому нечего сказать по делу?
> А то httpd-сервер там вроде уже есть - ждем когда полный LAMP
> запихнут?Даже добавление LAMP не сделало бы набор возможностей systemd неограниченным. Список реализованных в нем возможностей всегда будет ограниченным и конечным в любой момент времени, как и в любом существующем проекте.
Хотя Вы, возможно, гуманитарий, и мыслите не точными математическими категориями, а какими-то абстрактными понятиями, тогда мы друг друга не поймем.
> Что за привычка спрашивать очевидные вещи, которые гуглятся на раз-два? Или это
> просто такой способ ведения дискуссии — заваливание оппонента просьбами продублировать
> общедоступную информацию, когда самому нечего сказать по делу?типичный образчик демагогии от фанбоев системды, кстати. ты выдвинул утверждение, когда тебя попрсили его конкретизировать — впал в истерику и начал пищать, что «в гугель, сукины дети, в гугель!» нет уж.
отсылка человека в гугель в ответ на просьбу перечислить нечто конкретное — это демонстрация нежелания дальше дискутировать на данную тему. иногда так можно намекнуть на действительно вопиющую безграмотность оппонента, а иногда это используют так: «что бы ты там в гугеле ни нашёл — я посмеюсь и скажу, что это фигня; а своих определений не дам ни за какие коврижки!».
так вот. в данном случае — я таки тоже хотел бы увидеть список. потому что у людей, не загипнотизированных «newer and better things», создаётся стойкое впечатление, что никакого списка нет, а к системды просто дописывают рандомные «прикольные фичи». и не «системды написан под набор задач», а «мы вкидываем фичи, а потом упорно придумываем, зачем же мы это сделали».
хотя, возможно, ты гуманитарий, который считает, что является технарём и очень неудачно пытается проэмулировать «технарское мышление». скорее всего, оно так и есть — по крайней мере, если судить по последней фразе твоего комментария.
> типичный образчик демагогии от фанбоев системды, кстати. ты выдвинул утверждение, когда
> тебя попрсили его конкретизировать — впал в истерику и начал пищать,
> что «в гугель, сукины дети, в гугель!» нет уж.По-моему истерика как раз у тебя. Какое утверждение, какое там конкретизировать? Человек просто докопался до вообще нейтральных слов, потому что ему нечего сказать, а ты вдогонку выставляешь себя точно таким же.
В конце концов, если ни он, ни ты не можете или не хотите самостоятельно найти и прочитать базовую информацию о systemd, то может не стоит вообще и лезть в разговор о нём? По-крайней мере я смысла не вижу тратить свое время на копипасту легкодоступной информации для просвещения всех местных аналитегов, мне за это не платят, а лично мне это не интересно. И обсуждать что-то с людьми, которые об этом самом чём-то не имеют вообще никакого представления, т.к. не удосужились предварительно хотя бы основную информацию почитать, тоже смысла не вижу.
молодец, вполне ожидаемое продолжение истерики. самый обычный «случай номер два». в принципе, ты мог и не писать ничего, потому что и так было ясно, что ты ничего конкретного сказать не можешь.именно поэтому ты предпочёл «не заметить» предпоследний абзац в #110, где я специально для тебя пояснил, зачем нужен конкретный список (который, замечу, был упомянут именно тобой, это не мы его придумали). и в дальнейшем будешь «не замечать». если ты хоть немного умный — то сейчас гордо замолчишь. если совсем дурак — продолжишь истерить, но на прямой вопрос так никогда и не ответишь.
> молодец, вполне ожидаемое продолжение истерики. самый обычный «случай номер два». в принципе, ты мог и не писать ничего, потому что и так было ясно, что ты ничего конкретного сказать не можешь.Почитай свои же слова, может хоть так тебе понятнее будет, что я хотел тебе сказать:
"если не понятно, почему — то никакого «технического обсуждения» быть не может в принципе: у оппонента уровень не тот."
http://www.opennet.me/openforum/vsluhforumID3/93946.html#167> именно поэтому ты предпочёл «не заметить» предпоследний абзац в #110, где я специально для тебя пояснил, зачем нужен конкретный список (который, замечу, был упомянут именно тобой, это не мы его придумали)
Не вы придумали? Я понимаю, что ты читать не любишь или не умееешь, но все-таки ты для начала почитай предыдущие комменты, и посмотри кто первый заговорил про этот самый "список". Я тебе даже подскажу - http://www.opennet.me/openforum/vsluhforumID3/93922.html#101
Поскольку реально на тему systemd с тобой обсуждать нечего, думаю на этом можно разговор ни о чем заканчивать.
Понимаешь, мне не интересно обсуждать каждое слово во вполне простой фразе "Systemd решает ограниченный набор задач, под которые он написан", даже если тебе очень хочется до чего-то докопаться, только потому что ты не любишь и не умеешь проигрывать. Удачи!
таки ты оказался совсем дураком.
> Если что, я нигде и никогда не утверждал, что systemd может делать
> все, что может rsyslog.А что ты, болезный, "утверждал"? Что с чем предлагаешь сравнивать?
>>> Или может брехня то, что "Systemd решает ограниченный набор задач, под которые
>>> он написан"?
>> Тебя не затруднить предоставить список этого "ограниченного набора"?
> Что за привычка спрашивать очевидные вещи, которые гуглятся на раз-два?Это не очевидные вещи. Ибо от релиза к релизу - systemd обретает возможности "решать" еще какие-то "задачи". Конца-края этому не видно.
>> А то httpd-сервер там вроде уже есть - ждем когда полный LAMP
>> запихнут?
> Даже добавление LAMP не сделало бы набор возможностей systemd неограниченным. Список реализованных
> в нем возможностей всегда будет ограниченным и конечным в любой момент
> времени, как и в любом существующем проекте.Иными словами это называется - блоатварь. Нечто, спроектированное без цели решать четко очерченный круг задач.
> Хотя Вы, возможно, гуманитарий, и мыслите не точными математическими категориями
Моя плакал от ваши "категорий"... Ох уж эти мне птушники.
Ну раз уж ты такой весь "негуманитарий" - меня интересует точная верхняя грань объединения энтих самых возможностей в каждый момент времени. Для начала - от щас и до того как Солнце станет красным гигантом.
Ты можешь ее указать сейчас, или предполагается что systemd проэволюционирует к звезде смерти?
>> Чем старые добрые bash-скрипты не нравились? Десятилетиями работали.
> Тем что в каком-нить опенврт это нечто секунд по 30 стартует. Напрягает,
> однако.Чем напрягает, ты роутер ребутишь 50 раз на дню?
Когда системному программеру делать нечего, он init пишет.
Или когда прикладной программист решает стать системным.
прикольно.
а совсем без зависимостей - слабО ?(ядро Линукс не считаем) :-)
бо иначе - профита не так уж и много.
но на фоне аналогов - уже что-то )
вот зачем начинать абсолютно каждую строку со слова Object?ID=sysclock
Description=Configuring system clock
StartCommand=hwclock -s
StopCommand=hwclock -w
StartPriority=1
StopPriority=2
Enabled=true
Options=RAWDESCRIPTION
Runlevels=boot coreID=mountruntmp
Description=Mounting /run and /tmp
StartCommand=/etc/epoch/scripts/mountruntmp.sh
StopCommand=NONE
StartPriority=2
StopPriority=0
Enabled=true
Options=RAWDESCRIPTION
Runlevels=boot core hurr
> вот зачем начинать абсолютно каждую строку со слова Object?код не читал, но предположу, что автор не смог в структурированые конфиги.
