Upstart 1.8

Оно не может быть проще, оно сложнее. Все асинхронное всегда сложнее чем последовательное. Но проект upstart видется более логичным. Он подключает то, что генерирует события (мосты), т.о. достигается модульность.

Докажи, что реализация не является практичной. Помоему реализация как раз очень практична, т.к не требует соединения кодовых баз с udev.

зачем же тогда они тянут куски из systemd?

А разве остаются какие-то другие варианты? Udev слили, consolekit похоронили. Как уже было ранее сказано кем-то на ЛОРе - Подождем, пока танк [systemd] увязнет в болоте, а потом открутим колеса и сольем солярку.

This.

Жду аргументированной критики Upstart-а. В чем необходимость systemd, если Upstart решает поставленную задачу?

Да он даже со своей основной задачей — запуском демонов — справиться не может, о чём вообще можно дальше говорить.

http://manpages.ubuntu.com/manpages/precise/en/man5/init.5.html

man 5 init

BUGS

The and and or operators allowed with start on and stop on do not work intuitively: operands to the right of either operator are only evaluated once and state information is then discarded. This can lead to jobs with complex start on or stop on conditions not behaving as expected when restarted. For example, if a job encodes the following condition:

start on A and (B or C)

When 'A' and 'B' become true, the condition is satisfied so the job will be run. However, if the job ends and subsequently 'A' and 'C' become true, the job will not be re-run even though the condtion is satisfied. Avoid using complex conditions with jobs which need to be restarted.

Этот баг всё еще сохраняется? Его не пофиксили? Документация может быть старой.

Этот баг всё еще сохраняется? Его не пофиксили? Документация может быть старой.

Этот баг есть с самого начала существования апстарта и будет в нём всегда, его нельзя починить, потому что upstart с его событийно-ориентированной моделью кривой by design. Поэтому его и задокументировали в man, иначе бы уже давно починили.

А в systemd какая модель?

Здесь уточняется, что не смотря на несколько вариантов валидности условия, демон будет запущен только на один из них - лучший первый. А для многократного запуска есть http://upstart.ubuntu.com/cookbook/#instance

Это всё равно, что постить новости про Unity - хоть и FOSS, но всё равно никем, кроме убунты, не используется всерьёз.

А в systemd какая модель?

Dependency-based.

Не то, чтобы я за systemd, но как с этим сочетаются бесконечные рейсы autofs / nis / nfsd, которые годами висят на ланчпаде в багах и их никто не фиксит? Уж что-то, а тесты у них, раз так, полное говно.

Здесь уточняется, что не смотря на несколько вариантов валидности условия, демон будет запущен только на один из них - лучший первый. А для многократного запуска есть http://upstart.ubuntu.com/cookbook/#instance

Instance нужен, если нужно одновременно запустить несколько экземпляров демона. Но здесь другая задача: демон запускается по событию, когда запустятся A и B, потом демон завершает свою работу сам, потом запускается C, демон снова должен быть запущен, но upstart его не запустит. При этом недопустимо одновременно запускать 2 экземпляра этого демона, instance не подходит. Я не сильно вникал, но подозреваю, что если изменить «A and (B or C)» на «B or C», то этой проблемы не будет, а демон таки перезапустится второй раз.

А вообще, это всё не важно, потому что upstart просто не справляется правильно обработать выражение с синтаксисом, который придумали сами авторы upstart, поэтому полезность такой программы под большим сомнением.

И в чем ключевые отличия?

Это всё равно, что постить новости про Unity - хоть и FOSS, но всё равно никем, кроме убунты, не используется всерьёз.

Upstart серьезная и хорошая система инициализации. Тот факт что Upstart используется (или на будущее «использовался») в Rad Hat говорит сам за себя. Ну и плюс факт того что больше половины линукс десктопов под убунтой. Новость вполне может быть оформлена (что про Upstart, что про Unity). А так все выглядит как зависть по этому поводу. Почему бы ей не быть? Почему бы ей не развиваться если есть желающие ее развивать? Почему Upstart не может реализовывать часть того что «уже есть» в sysytemd? Это опенсорс, а использует кто-то еще или нет вопрос пятый. OpenRC многие используют? Так что не писать новости? Я за то чтоб развивались все.

С чего это демон снова должен быть запущен.. Очевидно, для реализации какого-то специфичного поведения нужно создать специального управляющего демона.

И в чем ключевые отличия?

systemd строит зависимости для сервисов и пытается их удовлетворить, когда нужно запустить что-то. Upstart делает всё шиворот-навыворот, он запускает что-то, когда приходит какой-то сигнал, например, о том, что запустилось что-то другое. Подробно тут: http://0pointer.de/blog/projects/systemd.html, «On Upstart»

С чего это демон снова должен быть запущен..

С того, что наступило условие для запуска. Кстати, если запустятся A и B, демон запустится, остановится, потом остановится B и запустится C, то как поведёт себя upstart?

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

Очевидно, что тут в комментариях и не только уже предложили создать столько вспомогательных демонов для upstart, что скоро для них не хватит PID'ов. Это расточительство системных ресурсов, в systemd хотя бы разделено то, что нужно разделить, а то, что одно целое — в одной программе. А когда для одной задачи нужен набор программ, как в upstart, — это уже не UNIX Way.

монстра нет. есть коллекция системд утилит на все случаи жизни. ну и да помимо запуска демонов за ними нужно потом следить и управлять. упстарт до менеджера сервисов слегка не дотягивает.

и как часто ты собираешь поддержку арм в своём ядре для х86 десктопа? я вот ни разу интересно зачем в ядро запихнули столько ненужного?

ЗЫ надеюсь этот ростой пример показывает куски объективной логики(потому что на мой взгляд всё это слишком очевидно и без аналогий)

Может и так. Но зачем тогда тянуть его фичи?

Мы вроде не на сайте Apple/Windows. Что значит «тянуть» фичи? Хорошие фичи значит, почему бы не реализовать их у себя в своем варианте системы? Многое просто приходиться (придется) сделать потому что udev привязывается к systemd. А если кто-то (коллектив или даже коммерческая компания) форкнет systemd целиком и будет пилить свой вариант под своим именем? Сделает свою реализацию (systemE, systemI)? Примеров достаточно: Иксы, Open/LibreOffice, список продолжается в бесконечность. С каких пор это стало плохо в опенсорс? Я лично рад и за Upstart, и за systemd, и за OpenRC, и за остальных. Это наша сила.

ты мог бы знать что единственная причина по которой убунта не перешла на системд это то что решение принимал автор упстарта.

для системд тоже не требует, но автору удев так проще..

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

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

вот как решит - тогда решит, а пока сидим на... я не знаю что у меня, всё работает, у меня кажется upstart 1.5

ну так зачем ты обсуждаешь что технически лучше если:
а. тебе всё равно
б. ты в этом даже разбираться не стал.

когда нужно запустить что-то
пытается их удовлетворить

Вместо «start on», «dependency on»?

то как поведёт себя upstart?

Сказано же, не запустит.

А когда для одной задачи нужен набор программ

Так тут декомпозиция. Сложная задача делится на ряд простых. Это как раз хорошо. Мне не понравится реализация демона - я его выкину/перепишу/допишу. Компоненты более независимы. А в systemd что..

до менеджера сервисов слегка не дотягивает.

Фишка в том, что УМВР. Может сложность задачи слегка мм.. преувеличена, а инструменты усложнены, мне ведь не надо гитхаб перезапускать, а если и надо, то уж точно не на upstart/systemd.

на все случаи жизни.

кони в вакууме - сходу не нужно.

таким демоном в системд является системд и ничего создавать не нужно всё есть из коробки

спасибо. т.е. вместо человеко понятного ruby, например, я должен возиться с конфигами systemd, в надежеде, что там все предусмотрено. Не, я пас.

не хватит PID'ов

пидов им жалко.. Поцеринг тоже про пиды говорил, дескать у макоси пиды маленькие. В этом есть какой-то профит? А то что системы должны быть распределены, вы не слышали? Может вообще один процесс сделать, пусть в нем все крутится - красота.

какое-то скомкано-моноблочное мышление, у поцеринга и его приверженцев.

если хочешь, то можешь и на руби, но если ты пишешь демона а не свой костыль то прочитай мануал на пару страниц и не неси чушь.

прописываем повторный курс чтения документации.

но не смеятся над этим вроде тоже никто не обещал.

О! Вот это было бы правильно. Посмеяться и пусть себе работают над тем, над чем считают нужным. Но со стороны многих это имхо не смех, а злость по поводу того что так все победно шло, а этот «засранец» подпортил картину. Злятся, а между тем им никакого дела не должно быть до других в этом плане, тем более что такой «бмв» хороший сделали. Видно этого им не достаточно, нужно чего-то еще.

ну я носом тыкаю обычно только тех кто манула не чесал а в драку лезет...

в общем семь проблем один RTFM

> Linux Ubuntu 0.50%
> Linux Fedora 0.01%

Враньё - в Fedora в идентификаторе браузера не написано название дистрибутива Linux. Смотри Linux Other.

> Я допускаю, что федоры больше, но не думаю, что больше 0.1%

Это ты зря.

Мне тоже не нравится Systemd, я за выбор, как это было в openSUSE 12.1-12.2.

> Проценты кто и как считал?

Это статистика Википедии. Там Linux Other процент и Linux Ubuntu полпроцента, остальные 0,06%.

А зачем был нужен systemd когда уже был upstart? Могли же просто коммитить в код сообща.

Не могли, после того как Марк сказал что RedHat использует Upstart

А этого вполне хватает, чтобы не принимать во внимание другое .. :)

.. и слабость. Мигель прав

В жопе засвербило?

одной задачи

Разных задач, управления инициализацией, запланированными заданиями и журнал - разные задачи.

NIH же ;D

Именно, это и есть причина появления проекта systemd в стенах Red Hat.

Хм... Танк-то не увяз :D Они скручивают колёса с едущего танка :D

// «Либо чудо, либо фокус» © Е. Гришковец.

Это если смотреть по времени зарождения проектов.

По поводу остального — см. в треде диалог с любителем микрософта :)

Ну а что по поводу остального? Например Mir по отношению к Wayland сейчас пребывает ровно в том же состоянии, в котором пребывал systemd до по отношению к upstart в 2010 году, но этого почему-то никто не замечает. Странно, почему никто не проводит такую аналогию.

Имидж каноникал решает. Как в той притче про мальчика-пастуха, его постоянное враньё и волка.

UPD: появление systemd может быть объяснено ещё и тем, что RedHat'у стала нужна не только система инициализации, а что-то большее (на правах домысла).

Имидж каноникал решает.

Вот давайте не будем. Red Hat просто не могли отдать такой стратегический компонент, как систему инициализации, в руки конкурентов, а то не дай бог кто подумает, что Canonical оказывается тоже умеют писать годноту (вот вы, например, похоже даже не допускаете такой мысли). Red Hat был нужен подконтрольный им проект. Короче, обычный NIH.

появление systemd может быть объяснено ещё и тем, что RedHat'у стала нужна не только система инициализации, а что-то большее (на правах домысла)

Совпадает с причиной появления Mir.

Ответ на это сообщение.

По поводу «в тайне от сообщества» им предъявили как раз не за Mir, а за переход на «соборную» модель «разработки» самого дистра.

Вы оригинал читали, или поверили интепретации plm? (Судя по тому, что произошло после, речь идёт об Ubuntu Touch.)

Да, причем, равно как systemd мог бы быть основан на upstart, mir мог бы быть основан на wayland, месть?)

Не превращается, так как upstart всё ещё выполняет одну задачу: запускает и останавливает процессы по событиям, мосты же отдельные процессы.
Взаимодействующие процессы вместо одного комбайна — всё в лучших традициях Unix и Plan 9.