LINUX.ORG.RU
ФорумTalks

Резолюция Дебиан Init Systems и systemd

 , ,


0

5

Выбор 1: Подтверждение Инициативного Разнообразия Используя свои полномочия в соответствии с разделом 4.1 (5) Устава, проект издает следующее утверждение, описывающее нашу текущую позицию по системам Init, разнообразию систем Init и использованию средств systemd. Это утверждение описывает положение проекта на момент его принятия. Эта позиция может развиваться с течением времени без необходимости прибегать к будущим общим резолюциям. Процесс GR остается доступным, если проект нуждается в решении и не может прийти к консенсусу.

Выбор 2: systemd, но мы поддерживаем изучение альтернатив Используя свои полномочия в соответствии с разделом 4.1 (5) Устава, проект издает следующее утверждение, описывающее нашу текущую позицию по системам Init, разнообразию систем Init и использованию средств systemd. Это утверждение описывает положение проекта на момент его принятия. Эта позиция может развиваться с течением времени без необходимости прибегать к будущим общим резолюциям. Процесс GR остается доступным, если проект нуждается в решении и не может прийти к консенсусу.

Выбор 3: Сосредоточьтесь на systemd для системы Init и других объектов Используя свои полномочия в соответствии с разделом 4.1 (5) Устава, проект издает следующее утверждение, описывающее нашу текущую позицию по системам Init, разнообразию систем Init и использованию средств systemd. Это утверждение описывает положение проекта на момент его принятия. Эта позиция может развиваться с течением времени без необходимости прибегать к будущим общим резолюциям. Процесс GR остается доступным, если проект нуждается в решении и не может прийти к консенсусу.

Проект Debian признает, что системные единицы обслуживания systemd являются предпочтительной конфигурацией для описания того, как запустить демон / службу. Пакеты должны включать сервисные модули или сценарии инициализации для запуска демонов и сервисов. Если проект или соответствующие стороны не договорились об ином, средства systemd, где они существуют и являются стабильными и поддерживаются сопровождающими systemd, должны быть предпочтительнее, чем специфичные для Debian способы решения той же проблемы, если подход Debian не имеет явных и очевидных преимуществ.

Выбор 4: Поддержка несистемных систем, без блокировки прогресса Название: Поддержка несистемных систем, без блокировки прогресса ПРИНЦИПЫ

  1. Мы хотим продолжать поддерживать несколько систем инициализации в обозримом будущем. И мы хотим улучшить нашу поддержку systemd. Мы разочарованы тем, что для этого пришлось задействовать еще одну ГР.

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

СИСТЕМНЫЕ ЗАВИСИМОСТИ 3. В идеале пакеты должны быть полностью функциональными для всех систем инициализации. Это означает (например), что демоны должны отправлять традиционные сценарии инициализации или использовать другие механизмы, чтобы гарантировать, что они запускаются без systemd. Это также означает, что настольное программное обеспечение должно быть устанавливаемым и в идеале полностью функциональным, без systemd.

  1. Так что отказ от поддержки несистемных систем, где такая поддержка недоступна, является ошибкой. Но это не критическая ошибка выпуска. Вопрос о том, записано ли требование для systemd как формальная ошибка в системе ошибок Debian, когда нет доступных исправлений, зависит от сопровождающего.

  2. Когда пакет имеет ограниченную функциональность без systemd, это обычно не должно документироваться как (прямое или косвенное) Зависит или Рекомендуется от systemd-sysv. Это связано с тем, что при таких зависимостях установка такого пакета может попытаться переключить систему инициализации, а это не то, чего хотел пользователь. Например, демон с только системным сценарием файла systemd по-прежнему должен быть установлен в несистемной системе, поскольку его можно запустить вручную. Одним из следствий этого является то, что в несистемных системах может быть возможно установить программное обеспечение, которое не будет работать или не будет работать должным образом из-за необъявленной зависимости от systemd. Это неудачно, но попытка переключить систему инициализации пользователя хуже. Мы надеемся, что лучшие технические подходы могут быть разработаны для решения этой проблемы.

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

https://www.debian.org/vote/2019/vote_002 - больше инфы

★★★

Точка невозврата для debian (а вместе с debian, и для всего linux-сообщества) была пройдена в 2014 году. Нынешнее голосование - пустышка, не способная изменить реальное положение вещей. Не понятно, зачем они его вообще затеяли.

У меня другой вопрос. Когда debian уже наконец перейдёт на формат пакетов rpm, и станет официальным респином федоры? Аргументы для этого точно такие же, какие были в случае перехода на systemd в качестве основной системы инициализации.

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)
Ответ на: комментарий от Manhunt

Вот ваще нет

Свободой выбора инструментов и обусловлен весь существующий зоопарк дистрибьютивов, то что дебиановци забили на LSB мега особенными их не делает, что хотят то и городят, в прочем как и следование LSB не превращает любой дистр в респин федоры

sparks ★★★
()

Напомните плес почему не надо использовать системди в 2к19, кроме ностальгического пердения песком от старперов, застрявших в девяностых?

Im_not_a_robot ★★★★★
()
Ответ на: комментарий от Im_not_a_robot

потому что оно просто всунуто, вместо того чтобы быть полноценно интегрировано в систему. Вот и имеем параллельно с systemd скрипт service, скрипты в /etc/init.d, cron и другие дублирующие функционал инструменты

SR_team ★★★★★
()
Ответ на: комментарий от Im_not_a_robot

Не то, чтобы ненужно, но:

большой -> сложный -> малопредсказуемый.

Пример.

Есть юнит .timer.

В юните есть RandomizedDelay.

Так вот, при любом изменении системного времени - например, ntpd решил дрифтануть, или, что печальнее, у тебя машина под HyperV с дефолтными настройками - этот самый RandomizedDelay пересчитывается заново.

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

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

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

pkuutn
()
Ответ на: комментарий от hakavlad

да

Но ты понимаешь, что понять это затруднительно ?

lenin386 ★★★★
()
Ответ на: комментарий от Im_not_a_robot

Напомните плес почему не надо использовать системди в 2к19, кроме ностальгического пердения песком от старперов, застрявших в девяностых?

Не все любят говно есть полной ложкой.

scanner
()
Ответ на: комментарий от Deleted

все правильно и тред про дебиан.

P.S. cron не только в дебиане задержался, хотя в шапке возможно и выкинули

SR_team ★★★★★
()
Ответ на: комментарий от SR_team

Ну, вопрос же был: почему бы не использовать systemd? Ты говоришь: потому что в Дебиане развели бардак. Но это же как раз аргумент за то, чтобы использовать только systemd и прекратить тем самым бардак.

Deleted
()
Ответ на: комментарий от Deleted

Ну, вопрос же был: почему бы не использовать systemd?

в треде про дебиан, вот я о нем и ответил. В NixOS например systemd приготовлен очень хорошо - система стартует быстро, никаких проблем нет.

Но это же как раз аргумент за то, чтобы использовать только systemd

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

SR_team ★★★★★
()
Ответ на: комментарий от Deleted

Притворяешься?

Или правда не понял?

Она не «делает случаную задержку». Она «генерирует случайную задержку каждый раз при изменении времени». Каждые 5 секунд под HyperV, к примеру. Очень полезно и нужно для таймера, который раз в сутки отрабатывает, к примеру.

pkuutn
()
Ответ на: комментарий от SR_team

можно и его выкинуть

Можно. Только при обсуждении что взять вместо него любители альтернативных ориентаций всё равно передерутся и переобидятся друг на друга. Да и смысла отказываться от systemd нет, только фрагментацию платформы плодить.

Deleted
()

Но всё же посмотрим.

Коготок увяз, всей птичке пропасть.

aes_ultimum ★★
()
Ответ на: Притворяешься? от pkuutn

Погуглил. Эта функция нужна, чтобы регулярные таймеры не выполнялись одновременно. В упор не понимаю сути трагедии.

Deleted
()
Ответ на: комментарий от Deleted

Трагедии в таймерах нет.

Есть непредсказуемое поведение.

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

pkuutn
()
Ответ на: комментарий от SR_team

ФункциАнал у тебя в штанах, это называется - функциональность.

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от Im_not_a_robot

Напомните плес почему не надо использовать системди в 2к19, кроме ностальгического пердения песком от старперов, застрявших в девяностых?

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

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от Manhunt

Когда debian уже наконец перейдёт на формат пакетов rpm, и станет официальным респином федоры?

Таких планов нет.

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

Такие же это какие?

Polugnom ★★★★★
()
Последнее исправление: Polugnom (всего исправлений: 1)

Ничего не понял, что они решили то в итоге? Выглядит так,что никакого решения не принято и всё осталось как было до этого.

grem ★★★★★
()
Ответ на: комментарий от Manhunt

Когда debian уже наконец перейдёт на формат пакетов rpm

Могут перейти, для удобства ментейнеров.

buka14
()
Последнее исправление: buka14 (всего исправлений: 1)
Ответ на: комментарий от grem

Ничего не решили, это список вариантов для предстоящего GR.

intelfx ★★★★★
()
Ответ на: комментарий от deep-purple

Так же часто, как использую в системе 2 сетевых карты, из-за чего приходится отказываться от имён ввиде eth0. Т.е. практически никогда, как и большинство пользователей.

grem ★★★★★
()

Debian - это сырье для Убунты. Уже на серверах Убунта почти в 2 раза опережает Дебиан. Поэтому в Дебиане будет systemd, потому-что этого хочет убунта. И вообще - systemd рулит.

FilosofeM ★★
()
Ответ на: комментарий от FilosofeM

в Дебиане будет systemd, потому-что этого хочет убунта

С чего это хочет? Сейчас, конечно Unity мертв, а гном прибит к systemd, но наоборот же было? Ubuntu была со своим upstart. Он даже в редхатовских дистрибутивах был по умолчанию.

boowai ★★★★
()

Choice 1: Affirm Init Diversity

Сначала покеты за названия выпиливают, теперь diversity это своё всем навязывают! Зла на них не хватает!

MrClon ★★★★★
()
Ответ на: комментарий от gentux

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

grem ★★★★★
()
Ответ на: комментарий от SR_team

В NixOS например systemd приготовлен очень хорошо - система стартует быстро, никаких проблем нет.

Ждал этого коммента, блин. Серьезно? Сустемдик нужен для скорости загрузки? Тьфу на тебя.

mandala ★★★★★
()
Ответ на: комментарий от Deleted

Для debian и так есть фрагментация, не во вскх версиях возможно его вкорясить, т.к. есть дебиан и без линукса, а сустемдик прибит гвоздями к пингвину. Кстати, дебианщики сегодня вносят основной вклад в развитие SysVinit.

Кстати, а тут писали новость

https://www.opennet.ru/opennews/art.shtml?num=51883

В sysvinit добавлена утилита для преобразования unit-файлов systemd

В состав системы инициализации sysvinit включена вспомогательная утилита sysd2v, позволяющая конвертировать unit-файлы сервисов systemd в формат классических скриптов инициализации SysV с заголовками LSB. Утилита будет поставляться начиная с выпуска sysvinit 2.97 в каталоге «contrib».

mandala ★★★★★
()

У меня такое ощущение, что проблемы не в systemd, а в Debian. Репозитории тухнут, ряды мейнтейнеров редеют, поэтому выбирать приходится из двух зол.

  1. Поменять систему релизов, например, исключив тестинг. Плюс поменять систему опакечивания, например, отказавшись от патчей. Это сильно облегчит жизнь оставшимся мейнтейнерам, но ударит по штабильности.

  2. Отказаться от системди, вернув взад мейнтейнеров с проекта Devuan. Штабильности в таком случае ничего не угрожает. Работы, правда станет теперь в три раза больше, но авось вернувшиеся блудные сыны справятся.

qtm ★★★
()
Ответ на: комментарий от FilosofeM

С точностью до наоборот. Убунту полностью зависит от Debian. Вкорячили в Debian systemd, пришлось и убунтовцам делать то же самое.

Polugnom ★★★★★
()
Ответ на: комментарий от Polugnom

Фанатам хоть ссы в глаза, все божья роса.

Берем первое что в голову пришло - plasma-desktop. Идем в сид и смотрим версию - 5.14. Напомню, последняя 5.17. И это, млять, не какая-то левая прога от васяна. Это одно из двух основных DE! Если это не тухнущие репозитории, то что это?

В чейнджлоге каждого релиза есть надпись «из-за отсутствия поддержки удалены следующие пакеты».

qtm ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.