Собственно, это я к чему — сама-то BSD RIP, конечно, но её init style используется и в линуксах некоторых.

угу, типа обьявили
sh program
зарипленным
и только в моде теперь продвинутых
./program .

> сокращается повторный вызов программ (например, awk в процессе инициализации запускается около 92 раза, grep - 77 раз) и повторное обращения к типовым ресурсам

а разве первое обращение не приведет к тому, что, скорее всего, программа будет находится в кэше диска?

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

видимо, systemd еще демоном будет висеть

что-то (или кто-то) мне подсказывает, что нацелено на встроенную и мобильную ниши)

Неужто будет вторая нормальная init-система? А то пока кроме OpenRC вообще ничего вменяемого нет...

от создателя пульса...чёт я побаиваюсь ))

>лучше бы iowait в ядре фиксили!

с 31го до 33 имеет смысл обновляться? - в багтрекере вроде говорят про какие-то патчи, которые немного получше проблему делают, сейчас как только что-нибудь свапится системе пипец приходит.

Имеет. Мне помогло, по крайней мере.

Осторожно, в треде разбушевался велосипедист!

по iowait мне кажется без разницы, а вот в остальном наверное да, имеет

>Леннарт Поттеринг (Lennart Poettering), создатель звукового сервера PulseAudio

PulseAudio

Дальше не читал.

> видимо, systemd еще демоном будет висеть

В первой строчке по ссылке на оригинал написано, что вместо инита, как upstart.

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

затем же, зачем пульс, когда все использую alsa ^_^

Для полу-Ъ, которые пошли только по одной ссылке

On Upstart

To begin with, let me emphasize that I actually like the code of Upstart, it is very well commented and easy to follow. It's certainly something other projects should learn from (including my own).

That being said, I can't say I agree with the general approach of Upstart. But first, a bit more about the project:

Upstart does not share code with sysvinit, and its functionality is a super-set of it, and provides compatibility to some degree with the well known SysV init scripts. It's main feature is its event-based approach: starting and stopping of processes is bound to «events» happening in the system, where an «event» can be a lot of different things, such as: a network interfaces becomes available or some other software has been started.

Upstart does service serialization via these events: if the syslog-started event is triggered this is used as an indication to start D-Bus since it can now make use of Syslog. And then, when dbus-started is triggered, NetworkManager is started, since it may now use D-Bus, and so on.

One could say that this way the actual logical dependency tree that exists and is understood by the admin or developer is translated and encoded into event and action rules: every logical «a needs b» rule that the administrator/developer is aware of becomes a «start a when b is started» plus «stop a when b is stopped». In some way this certainly is a simplification: especially for the code in Upstart itself. However I would argue that this simplification is actually detrimental. First of all, the logical dependency system does not go away, the person who is writing Upstart files must now translate the dependencies manually into these event/action rules (actually, two rules for each dependency). So, instead of letting the computer figure out what to do based on the dependencies, the user has to manually translate the dependencies into simple event/action rules. Also, because the dependency information has never been encoded it is not available at runtime, effectively meaning that an administrator who tries to figure our why something happened, i.e. why a is started when b is started, has no chance of finding that out.

Furthermore, the event logic turns around all dependencies, from the feet onto their head. Instead of minimizing the amount of work (which is something that a good init system should focus on, as pointed out in the beginning of this blog story), it actually maximizes the amount of work to do during operations. Or in other words, instead of having a clear goal and only doing the things it really needs to do to reach the goal, it does one step, and then after finishing it, it does all steps that possibly could follow it.

Or to put it simpler: the fact that the user just started D-Bus is in no way an indication that NetworkManager should be started too (but this is what Upstart would do). It's right the other way round: when the user asks for NetworkManager, that is definitely an indication that D-Bus should be started too (which is certainly what most users would expect, right?).

A good init system should start only what is needed, and that on-demand. Either lazily or parallelized and in advance. However it should not start more than necessary, particularly not everything installed that could use that service.

Finally, I fail to see the actual usefulness of the event logic. It appears to me that most events that are exposed in Upstart actually are not punctual in nature, but have duration: a service starts, is running, and stops. A device is plugged in, is available, and is plugged out again. A mount point is in the process of being mounted, is fully mounted, or is being unmounted. A power plug is plugged in, the system runs on AC, and the power plug is pulled. Only a minority of the events an init system or process supervisor should handle are actually punctual, most of them are tuples of start, condition, and stop. This information is again not available in Upstart, because it focuses in singular events, and ignores durable dependencies.

Now, I am aware that some of the issues I pointed out above are in some way mitigated by certain more recent changes in Upstart, particularly condition based syntaxes such as start on (local-filesystems and net-device-up IFACE=lo) in Upstart rule files. However, to me this appears mostly as an attempt to fix a system whose core design is flawed.

Besides that Upstart does OK for babysitting daemons, even though some choices might be questionable (see above), and there are certainly a lot of missed opportunities (see above, too).

There are other init systems besides sysvinit, Upstart and launchd. Most of them offer little substantial more than Upstart or sysvinit. The most interesting other contender is Solaris SMF, which supports proper dependencies between services. However, in many ways it is overly complex and, let's say, a bit academic with its excessive use of XML and new terminology for known things. It is also closely bound to Solaris specific features such as the contract system.

Есть надежда, что эта зараза не распространится :)

http://0pointer.de/blog/projects/systemd.html

Is this a Red Hat project?

No, this is my personal side project.

Спасибо, осилил.

> Есть надежда, что эта зараза не распространится :)

Если какой-то дистр найдёт это удобным, как федора нашла апстарт, почему бы и не использовать?

> Если какой-то дистр найдёт это удобным, как федора нашла апстарт, почему бы и не использовать?

Потому что слишком много систем управления сервисами - это плохо; и потому, что пишет ее человек, больше всего известный глюкавым PulseAudio.

> я лучше знаю ЧТО ГДЕ КОГДА и КАК! точка

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

> когда число демонов будет > over 100
в преисподней ?

Угу. В Windows — сервисы ведь, да? :))

службы же )))

Ах вот как это называется в Not Unix-ОС... Спасибо, просветил.

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

Слава Solaris SMF покоя не дает аффтару.

Спасибо. Может и пригодится.

>Потому что слишком много систем управления сервисами - это плохо
Начнем с того, что у нас >300 дистрибутивов и чуть ли ни каждую неделю возникает новый. На этом фоне все остальные велосипеды выглядят блекло.

>> Потому что слишком много систем управления сервисами - это плохо

Начнем с того, что у нас >300 дистрибутивов

На этом и закончим .

> >Есть BSD style и System V. Остальные не нужны.

BSD

У меня для тебя плохие новости

Кстати, а кроме ArchLinux есть ещё вменяемые дистрибутивы, использующие BSD-стиль инициализации?

P.S. Предлагаемая система чем-то близко напоминает концепцию, предложенную в Minix3 для драйверов, а ещё ближе — службы Windows.

> видимо, systemd еще демоном будет висеть

Вы так говорите, как будто традиционный init демоном не висит. И, кроме того, PID 1 просто таки обязан висеть демоном и вызывать wait(2) время от времени.