Upstart 1.8

Очередной раунд добавления фич, реализованных в systemd года два назад. Так и будут в догоняющих - когда им надоест-то уже?

Объявят это инновационной разработкой с человеческим лицом. Пипл схавает.

Может просто не всем нужен монстр на стероидах вместо обычного инита?

По-моему они upstart так превращают в systemd.

Может просто не всем нужен монстр на стероидах вместо обычного инита?

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

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

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

Технически, любые патчи в проект Canonical принимаются только после подписания проприетарного CLA:

* http://upstart.ubuntu.com/wiki/ContributingCode

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

проприетарного

Лицензия: GNU General Public License

И да, у Upstart есть киллер-фича: он не привязан к ядру Линукс.

Прочитай то, что написано по ссылке, что я дал. Canonical сами загнали себя в тупик, кстати, со своим CLA - их никто не просил превращаться в опенсорсный Apple.

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

И да, у Upstart есть киллер-фича: он не привязан к ядру Линукс.

Это неправда - он жестко привязан к ядру Linux. И это доказывает, что мы, в коммьюнити Fedora, гораздо лучше разбираемся в тонкостях устройства Canonical и их проектов, чем недоразвитые убунту-фанбои.

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

Ок, я понял - не использовать systemd, чтоб использовать systemd.

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

Буквально на неделе разбирался как писать свои сервисы для Upstart - оказалось гораздо проще и быстрее чем для sysvinit.

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

Выглядит как утка, плавает как утка, крякает как утка, но не systemd.

В квотезы!

Прочитай то, что написано по ссылке, что я дал. Canonical сами загнали себя в тупик, кстати, со своим CLA - их никто не просил превращаться в опенсорсный Apple.

А чего сразу Apple? Почему не FSF в пример привел? Они тоже требуют передачу прав на код.

А чего сразу Apple? Почему не FSF в пример привел? Они тоже требуют передачу прав на код.

Кстати, верно подмечено. Странно жаловаться на Canonical если FSF делает так же по понятным причинам.

Это он RH подсознательно ассоциирует с Apple.

Хорошая новость! А главное, сколько баттхерта вызывает у школоты! Лысый уголовник тоже здесь. :)

Врагу не сдаётся наш гордый Upstart!

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

Но как-то.. было бы еще зачем.

Ubuntu - http://upstart.ubuntu.com/index.html
Fedora - http://www.freedesktop.org/wiki/Software/systemd

Ubuntu - http://upstart.ubuntu.com/cookbook/
Fedora - http://www.freedesktop.org/software/systemd/man/

Linux Ubuntu 0.50%
Linux Fedora 0.01%

Помоему, выбор очевиден.

Ты сделал мой день, спасибо.

И федора, и убунта, и арч, и гента, и ред хат, и тысячи других дистрибутивов являются тестируемыми, и всё лучшее из них попадает в Debian.

Хорошо бы.

Существует мнение, что у systemd есть некоторые возможности, отсутствующие у Upstart:

• Запуск без использования bash/shell скриптов
• Включены сервисы ранней стадии загрузки, написанные на языке C
• Возможность упреждающего чтения данных с диска
• Активация сервисов на основе сокетов
• Активация сервисов на основе сокетов: совместимость с inetd
• Активация на основе шины (Bus-based Activation)
• Активация на основе аппаратуры компьютера
• Конфигурирование зависимостей устройств, используя правила udev
• Активация по событиям файловой системы (inotify)
• Активация по времени
• Управление точками монтирования
• Управление запуском fsck
• Управление квотами
• Управление автомонтированием
• Управление SWAP
• Сохранение снимков состояния системы (snapshotting)

Существует мнение, что, система запуска демонов не должна обладать ни одной из этих возможностей))

Например upstart событейный, что мешает сделать специальный демон, который будет реализовывать:
- Активацию сервисов на основе сокетов

затем сделать другой демон, который будет реализовывать:
- Активацию по событиям файловой системы

и т.д.

Было сказано: UNIX WAY. Но все пытаются слепить монстра, делающего все.

Короче, перечисленный тобой список фич, просто орет, что нельзя это использовать.

Проценты кто и как считал? Но согласен что Ubuntu имеет больше шансов на успех.

Полностью согласен. Upstart больше соответствует UNIX-way идеалам. И в самом деле позволяет дописать всё что причисляют как возможности systemd в виде своих задач.

Активация по событиям файловой системы (inotify)

Upstart 1.8 теперь тоже умеет. Остальное - всё может быть оформлено ввиде задач для Upstart.

Вы не забыли что sysvinit устарел и надо было создать что-то чуть современнее. Но не монстра типа systemd. Ядро подсистемы должно быть маленьким.

Добавлю что Canonical считает что процесс запуска остального должен быть хорошо отлажен и стабильно работать, поэтому Upstart покрыт множеством автоматизированных тестов. И поверх этой стабильной части - работает остальное.

педевикия, обсуждали это здесь: В OpenBSD-current добавлена поддержка KMS (комментарий)

Я допускаю, что федоры больше, но не думаю, что больше 0.1%, кроме того, я считаю, что ubuntu так же больше, где-то на 0.2 - 0.3%.

Активация на основе аппаратуры компьютера

Вот это вообще копец, я считаю. Устройства могут быть совершенно разные, и, вероятно, под одно окружение подойдет одно решение, под другое - другое, а тут все systemd.

NIH же ;D

Фатальный недостаток, все дела...

Когда был создан Upstart а когда systemd? Я знаю ответ. Лучше если сам человек напишет.

Речь вообще-то шла не про время зарождения проектов, а про то, что upstart находится в роли догоняющего, причём догоняет оно методом копипастинга у лидера. Кстати, оно находится в роли догоняющего, несмотря на:

Когда был создан Upstart а когда systemd? Я знаю ответ.

Заметьте, что эта реализация есть и в upstart, вот только не является практичной.

Upstart: Initial release 24 August 2006 systemd: Initial release 30 March 2010

«Лидер» засунул в своего монстра много лишнего, без чего всё было отлажено и давно работало.

Canonical не должен кидаться на systemd, по крайней мере ближайшие несколько лет.

Canonical не должен кидаться на systemd, по крайней мере ближайшие несколько лет.

Сообщите об этом каноникалу, а то они берут цельные куски systemd и беззастенчиво приматывают их скотчем к своему upstart'у ;D

Какая?

Feature Highlights

    Tasks and Services are started and stopped by events
    Events are generated as tasks and services are started and stopped
    Events may be received from any other process on the system
    Services may be respawned if they die unexpectedly
    Supervision and respawning of daemons which separate from their parent process
    Communication with the init daemon over D-Bus
    User services, which users can start and stop themselves

Planned Features

    Events generated at timed intervals or scheduled times (under consideration)
    Events generated as files or directories are changed (in progress)

Сообщите об этом каноникалу, а то они берут цельные куски systemd и беззастенчиво приматывают их скотчем к своему upstart'у ;D

Это незаконно? Или работает хуже? Зачем им переходить на systemd если то что им надо они могут взять и так?

Вы всё куда-то уходите от темы.

Я говорю, что upstart догоняет systemd по фичам. Вы мне в ответ, что upstart старше systemd.

Я говорю, дескать, да, старше, но несмотря на это, в systemd больше фич. Вы мне про то, что каноникалу не нужно кидаться на systemd.

Тогда я снова повторяю: зачем же тогда они тянут куски из systemd? А вы мне теперь уже про закон.

Похоже, мы общаемся на разных языках. Извините.

Udev device event bridge implementation for Upstart available as preview, forwards entire udev database into Upstart.

А что и кому Вы пытаетесь доказать?

Чтобы я сейчас взял и перевел мою систему на systemd? Или чтобы это сделал Canonical?

Может однажды они перейдут или не перейдут - мне в принципе всё равно.

Я не откажусь от Ubuntu ради systemd. Считаю systemd или Upstart важным, но не принципиальным элементом для конечного пользователя.

На этом предлагаю закончить беседу.

Да, systemd обладает фичами которые скоро будут в Upstart или возможно даже тупо возьмут код - мне не принципиально.

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

Затем, что они есть.

А что и кому Вы пытаетесь доказать?

Вы опять всё перепутали. По-моему, что-то доказать пытаетесь именно Вы.

Более того, я не являюсь фанатом каких-либо технических решений в той же Fedora'е. Просто забавно смотреть со стороны на потуги небезызвестной «небольшой конторы», практически не имеющей за душой разработчиков, но умеющей громко давать обещания.

Затем, что они есть.

И это правильный ответ! :D

Буквально на неделе разбирался как писать свои сервисы для Upstart - оказалось гораздо проще и быстрее чем для sysvinit.

Хм. У меня впечатление было ровно обратное — писать сервисы, что для сис5инит, что для системд намного проще, чем для апстарта.

Жду аргументированной критики Upstart-а.

Системд осилили даже в арчике, апстарт же они не потянули. ИМХО, показатель сравнительной простоты.

http://upstart.ubuntu.com/cookbook/#upstart-udev-bridge

Теперь можешь доказывать, что оно «as preview» -_-.

Што?