Разработчики Debian обсуждают, куда лучше свалить — на systemd или Upstart

С дуба рухнул что ли.

Не перечислите ли проекты, кроме инсталятора, разрабатываемые Дебиан?

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

Если по такому у debian вообще нет штатных разработчиков кроме ребят из SPI, 99% всего это сообщество ёпт.

Расскажешь, в каком месте он долбанутый?С его модульной архитектурой.

График показывает, что не рано. В серверной области у них ничего не накрывается.

Там GPL.

Как это мешает?

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

А как-же
Уже лет 15 с Дебиан работаю.

Если по такому у debian вообще нет штатных разработчиков

Естественно.
Я рад что вы поняли свою ошибку.

Тебе мешает зоопарк, а другим нужен выбор... из ассортимента этого зоопарка.

Типичное сообщество линукса - надо выбрать {что-то} и разводить холивары что это {что-то} лучше, а все остальное гуано.

А вот овер 300 серверов в продакшане - это как то поважнее твоих хотелок будет.

Понтов у тебя больше чем железа.

Спасибо, тебе мил человек за конкретику, а то тазик только понтоваться умеет.

С логированием проблемы быть вроде не должно, так как класический сислог можно будет поднять рядом с системд. Вот только как там будет сливаться dmesg стартовый это конечно вопрос.

А вот pxeboot вопрос интерестный. Вы etc как сейчас разворачиваете?

Я про это: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717517 И вот ещё: http://www.opennet.ru/opennews/art.shtml?num=37902

Разработчики Debian обсуждают, куда лучше свалить — на systemd или Upstart (комментарий)

Если поставить Gnome в Ubuntu 13.10, systemd заменит upstart?

Нет, получится просто раскоряка, а не дистр с GNOME.

А разве «стейбл» вообще как-то ускоряться может? Он же на то и стейбл, чтоб «разницы никакой не заметил».

Типичное сообщество линукса

выбрать {что-то} и разводить холивары убеждать себя что это {что-то} лучше, а все остальное гуано.

А как пользователя? Совсем плохо?

As a project, we seem to be more appealing to packagers than to software developers. That is a pity given the amount of exciting coding tasks that are everywhere in Debian.

DPL©

Понтов у тебя больше чем железа.

Ооо, моих понтов больше чем воздуха на планете, это да. Так а по делу есть что сказать?

а то тазик только понтоваться умеет.

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

Разработчикам же пофигу, насколько лениво там тебе переводить свой зоопарк куда-то.

Разработчикам же пофигу, насколько лениво там тебе переводить свой зоопарк куда-то.

Таки нет, в дебиане как раз на этим обычно парятся.

общий дефолт, а дальше папетом

Так и думал. Я надеялся, что есть опыт подъема с сохраненной конфигурацией. Там интерестнее: игрища с initrd и монтирование /etc по сети.

Нет, я просто не вижу смысла объяснять, когда оппоненту не

интересно, а он лишь приследует желание потроллить.

Угу, я все знаю, но никому не скажу.

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

Угу, я все знаю, но никому не скажу.

Нет, спросил бы ты конкретно - получил бы конкретный ответ.

GNOME перешёл на systemd, мы не можем выкинуть GNOME из Дебиана, следовательно тоже должны перейти на systemd.

Безвольные тряпки.

который активно использует сислог
крон

Не является проблемой. В первом случае можно разрулить journal/syslog на уровне юнитов и системы в целом

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

Если для старта софта, который соблюдает протокол SysV - не является серьезной проблемой. В худшем случае можно использовать режим совместимости, а по хорошему - переписать на юниты. Если софт соблюдает протокол - проблем не будет.

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

pxeboot, и /usr на отдельном разделе

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

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

Мне у каждой пустой балаболки конкретику спрашивать? Тут их на лоре тьма. Особенно в этой теме.

Расскажешь, в каком месте он долбанутый?

http://i.imgur.com/usftZ.png

Мне у каждой пустой балаболки конкретику спрашивать? Тут их на лоре тьма. Особенно в этой теме.

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

Расскажешь, в каком месте он долбанутый?С его модульной архитектурой.

Да почти во всех :)
Система инциализации - не та вещь, в которую следует лезть с инновациями и пытаться все подряд поменять, как минимум из-за проблем с обратной совместимостью.
Если бы они осилили нормальную миграцию, тогда все было бы ок. А просто придти, сунуть продукт напихав в него кучу фич - это как то не линус стайл.

Давно пора. Надеюсь, к восмерочке уже перейдут на systemd.

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

А просто придти, сунуть продукт напихав в него кучу фич - это как то не линус стайл.

Ну да, конечно. Ядро линакса - не линус стайл ))

А теперь простой вопрос: зачем? Зачем все это? Есть рабочее решение, и есть системд, который его ломает, не привнося при этом никакой заметной пользы

Landscape они тоже не писали?

А теперь простой вопрос: зачем? Зачем все это? Есть рабочее решение, и есть системд, который его ломает, не привнося при этом никакой заметной пользы

В такой постановке задачи - незачем. Зачем вам мигрировать, если и так все работает?

Кто там хотел «стандартизации»?

Если Debian и перейдет на systemD, то наверняка и Ubuntu :)

А поддерживать downstream и только перековыривать постоянно пакеты умные люди не станут, надеюсь в сообществе Debian это понимают, окромя 3их девелоперов upstart.

О-о! Что-то все таки написали, но закрытое (не уверен пока), но точно платное. Наверняка прибитое гвоздями к убунте, как и все остальные поделия.

ну если upstart итак копипастит systemd, то им же тока и легче будет

Ну да, конечно. Ядро линакса - не линус стайл ))

Я имел ввиду ломая abi ;)

А теперь простой вопрос: зачем? Зачем все это? Есть рабочее решение

А теперь простой вопрос: зачем? Зачем прогресс, зачем пилить то же ядро, ведь есть старые рабочие версии?

Вопрос не в целесообразности миграции и отсутствии возможности конвертирования скриптов (с этим всё и так ясно), а с криками, что systemd — жырный, не юниксовый и вообще глюкавый.

с криками, что systemd — жырный, не юниксовый и вообще глюкавый.

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

А про «не юниксовый» - истинно так. За бинарные логи надо бить сильно и увесисто.

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

С какими задачами? То что отвечает именно за инициализацию и управления процессами давно стабильно. У меня, например, пара кастомных патчей на управление зависимостями ребейзятся без конфликтов уже с год. Меняется перефирия, но ее 1) никто не заставляет тянуть в прод 2) не знают как использовать на данный момент в проде сами девелоперы.

За бинарные логи надо бить сильно и увесисто.

Бинарные логи системде никто не заставляет использовать. Заставляют использовать stdio бридж, который называется systemd-journald. Он может форвардить в т.ч. и в сислог, если это действительно необходимо. Другой вопрос, что софт, чьи логи действительно нужно хранить и читать и так не то что бы особо срет ими в сислог. Тут важно понимать, что systemd-journald будучи прицепленым ко всем процессам позволяет агрегировать без геммороя гораздо большее количество информации при желании. Это особенно круто на лептопах, не на серверах, да.

За бинарные логи надо бить сильно и увесисто.

Интересно, как блобовый веложурнал имени поцтеринга чувствует себя на разных ФС при blackout? Рушится весь целиком в хламину, или все-таки подлежит частичному восстановлению?

Это особенно круто на лептопах, не на серверах, да.

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

Возможно дистростроителям дебиана хочется видеть свое детище не только на серверах.

Впрочем, я себе слабо представляю проблемы связанные с системой инициализации на реке.

https://lists.fedoraproject.org/pipermail/devel/2013-July/185702.html

> > There's "journalctl --verify" whose main purpose is to verify FSS
> > seals. It will also check the integraty of the data structures in a
> > journal however.
> 
> What can be done if the verification fails? How can one get the
> incomplete data in case journald rotated a journal?

The tool will tell you how much of the file could be verified, starting
from the beginning. 

For tail corruptions your normal journalctl tool will provide you with
as much information as is possible to salvage from the file. It will
output the last complete log line and then finish. This is pretty close
to how good you can get.

Things are different for corruptions in the middle. We have no nice tool
for salvaging data from such corruption, but they could be written
relatively easily. However, since they are highly unlikely due to the
"append-only" model of the journal this hasn't been on our TODO list.

Lennart