Systemd победил в третьем голосовании по выбору системы инициализации для Debian

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

Ах да вот тут мой косячок. Перепутал опенсурс и фрисофт. Имелся в виду опенсурс. См. Реймонд с Столлман.

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

Ты опять не понял. Апстрим в данном случае это команда ядра РХ. Она всё делает, да. Пересылает что надо Линусу. Но если простой прогер захочет взять и сам поколупаться, или патчи сделать на РХ ядро - примет их команда РХ?

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

в каждом дистре собирали кто во что горазд. ...

ничего нового :) меритократия в полный рост, таков весь линукс

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

Ну что там, дебиан уже развалился на две части?

dell это те самые корпоративщики которые недавно сняли гарантии со своих нотебуков если на них устанавливался vlc?

какое отношение это имеет к серверам, линуксу и разговору вообще?

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

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

$150K/год? Делим на 12 = $12.5K/мес. Нет. Не теми. :)

Да амортизации в три года хватит. ;)

ну вот, а сколько тот HP стоит? :)

мы можем позволить себе замену ПО заказчика при необходимости

и заказчику не надо будет за это платить астрономические суммы?

При смене (если таковая случится и это будет влиять на приклад) ABI.

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

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

опаньки, значит каждый раз, когда дистр взбрыкивает, заказчик все таки должен платить? и суммарно это не выливается в бОльшие деньги чем нормальный софт на стабильном дистре? Только объективно, без саморекламы пожалуйста :)

Ему важен результат, а не процесс. В конце-концов, для этого аутсорсеров и нанимают, чтобы решать задачи mission/business critical, но не своими (непрофильными) силами, а силами специалистов. А уж как мы там это решаем... Заказчику сугубо фиолетово.

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

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

но ведь этого не происходит :)

Т.е., если я игнорирую подходы RH, то я понимаю что и почему я делаю. И да, я несу за это ответственность. Я прямо заявляю что меня ни как не волнует что там делают RH/Ubuntu/прочие дистрибы с комм. поддержкой. Я делаю то, что я делаю. Пока всё работает, я прав. А RH могут поискать на ком ещё заработать.

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

... а критика идеи, предположим. ;)

пусть будет :)

Я о себе забочусь.

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

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

Просто потому что он не дает мне забыть учесть какую-то тонкость, где-то опечататься, и как-то ещё напортачить.

Тебе и аргументировать.

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

Пока я вижу бабьи истерики (пустые эмоциональные утверждения).

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

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

Парочка таких вопросов на полгода, и проект можно закапывать.

Название деревни у меня в профиле. Не смотрели? Нерезиновка называется, она же Москва.

бывал, зазывали остаться поработать. ни за что :)

Везёт (без тени иронии). Да толку-то от от багтрекера? Если задаёшь вопрос «почему», а в ответ уши тереть начинают — «ну, у нас большая контора... у нас большой бардак...» Надоело. Свалил. Не жалею.

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

Я НЕ могу отыметь техподдержку, про то и речь. При всём желании.

эх, я их тут гоняю ежедневно :) это особенно легко, зная внутреннюю кухню

Ну да... У нас мейнтейнер пакета как-то предложил в Solaris 10 вкрячить gcc, точнее, gpp 4.(тут не помню), cmake ну и малость либ до кучи. Проблема только что в Solaris 10 штатно идёт gcc/gpp 3.4.2 (или 3.4.6), так что, gcc/gpp, glibc, cmake (тоже из почти последних) ручками, батенька, ручками.

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

эээ нет, для этого команду sustaining engineering (где я в RH 4 года проработал) хорошо разбавляют именно мейнтейнерами из апстрима. Таким образом они очень хорошо видеят все в верной перспективе - на апстрим смотри, но клиентам бекпорты не ломай.

$150K в год? Ну, я уже написал что категории малость не те. Даже для Нерезиновки. У нас всё несколько скромнее, но с e-mail/irc и google парни просто бесподобны! :)

в Долине все примерно так, и это не предел :) рассылки, гугль и irc имеют один недостаток - там никто никому помогать не _обязан_

Я смирился утверждением насчёт дебага, но не согласен с утверждением «ни кто не смотрит». Как-раз смотрят. Не волнуйтесь. И первого error уже достаточно чтобы дежурный начал башкой крутить и рыть землю носом — чё за фигня. Если сам не вкурит, отзвонится второй линии — разрабам. Да, могут позвонить и в 5.00, в понедельник. Ничего. Нам за это платят.

еще раз - текстовые логи просто не будут записаны, потому что на DEBUG log level их никто не поставит, если специально не сидеть и искать баги. все будет в лучшем случае INFO и выше, что никак не даст мне возможность докопаться до причины проблемы. Но даже если система выставлена на дебаг, это будет генерировать такое количество невозможного шума, что разобраться (даже с поллитрой) будет крайне сложно. С логами заведомо настроенными на такую ситуацию, которые сразу же можно прогонять через нормальный поиск (а не несчастный grep) это перестает быть проблемой.

C opennet:

«Решение может быть пересмотрено путем проведения референдума среди всех разработчиков Debian. В резолюции указано, что в случае, если большинство разработчиков Debian отдадут предпочтение системе инициализации, отличной от systemd, то такое решение будет иметь более высокий приоритет и будет автоматически утверждено техническим комитетом. С учётом большого числа разногласий в сообществе разработчиков, вероятность проведения общего референдума очень высока.»

То есть референдум скорее всего будет, решение комитета скорее всего будет пересмотрено. Много ли шансов у systemd в случае проведения референдума?

ну вот тут можно посмотреть, там не только debian developers участвовали, и наверно не все debian developes, но не думаю, что цифры будут сильно отличаться http://people.debian.org/~stapelberg/2013/05/27/systemd-survey-results.html

R.I.P Debian :)

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

«Ничего я не заострял. Я только заострил внимание на словах 'засунуть в жопу'». Ню-ню.

PaulCarroty> да, с чего ты взял что в sysv не надо больше костылей?

С того, что все костыли уже готовы. А если ещё OpenRC использовать, то костыли можно вообще выкинуть.

PaulCarroty> для systemd упоминается только cgroups

То-то и оно, что упоминается. Сколько там на самом деле костылей придётся делать - ещё неизвестно. Но факт в том, что не меньше, чем для sysvrc.

PaulCarroty> что касается openrc, то назвать это стабильной работой нельзя никак.

Странно. Куча народа пользуется и не жалуется. А то, что ты выше ссылку привёл - это бред. Кто-то включил _экспериментальную_ возможность и прищемил себе яйца дверью, из чего ты делаешь вывод, что двери - это плохо. OpenRC работает на редкость стабильно - это неоспоримый факт.

Именно. Аргументировать и подготовить планы никто не успел. Этот идиот Bdale Garbee устроил очень поспешное принятие решения и никого не слушал (собственно, потому он и идиот. Кто это такой и что он делал в дебьяне, я отлично знаю.). Каждая сторона могла подготовить нормальный список аргументов и нормально всё обсудить, но это было пресечено немедленно.

PaulCarroty> проблема в том, что нет ПО, которое бы использовалось вечно. всегда что-то умирает, а на смену приходит новое.

Но это не значит, что надо заменять ПО на то, которое defective by design.

PaulCarroty> меньшинство всегда недовольно.

Странно. Совсем не меньшинство уже заводит трактор с дебьяна от одной только новости. Компетентные разработчики высказываются также против systemd.

PaulCarroty> а решать технические вопросы полгода это ничто иное как застой.

Зависит от того, что за вопрос. В данном случае лучше не торопиться.

1. У systemd юниты, а не скрипты.

2. Я сейчас не помню, как у upstart, но systemd _пока ещё_ поддерживает скрипты, написанные для sysvrc.

Но зоопарк инитов - действительно адЪ.

Ну что за чушь-то опять? Ты вообще открывал саму дебиановскую дискуссию?

Прочитай: Date: Fri, 25 Oct 2013 12:16:04 -0400

redgremlin> переходи на ЛСД хотя бы, там глюки не такие глобальные.

Теперь ясно, что ты употребляешь.

OpenRC - зависимости разруливает, параллельный запуск поддерживает, скрипты инициализации просты и мощны. Всё просто и прозрачно, а не как в systemd.

Что-то не припоминаю, когда математиков к гуманитариям начали относить

Много ли шансов у systemd в случае проведения референдума?

Да. Что является самым печальным в данной ситуации.

redgremlin> В худшем для journald случае он тупо ничем не хуже

А чем же лучше?

redgremlin> Это в самом худшем случае, поэтому, очевидно, во всех остальных случаях он лучше.

Очевидно, что он не лучше.

Ты вместо того, чтобы оправдываться про первоистчники, лучше доведи до состояния возможности использования хотя бы в примитивном виде с реально загруженной системой, а потом подкати к Поттерингу и скажи: «We dont need your systemd. We've got a better init system - its much more simply and it can use additional учеутышщты like openrc. This init system will be default debian init. Fear and respect us! //Linux.org.ru community». Заодно дай ссылку на проект и образ для VM. Будет отличнейший троллинг.

anonymous> Ну, мобильный Linux в начале-середине 2000-х был тоже не ахти. :)

В самом начале 2000-х - да. В середине - Qtopia, GPE. Вполне неплохие среды. Проблема была только по части поддержки железа всё было плохо, так как родные аппараты почти не выпускали. А так я ставил Familiar на HP hx4700 по руководству от Шомана. Работало не ахти, но с Angstrom стало значительно лучше.

dinama> оставить как есть(или взять openrc если это возможно без крови)

А теперь самое смешное:

Многие, отписавшиеся в поддержку systemd, не понимают, что такое sysvinit. Так вот: чтобы включить OpenRC, sysvinit удалять не нужно. OpenRC работает отдельно от init.

Gotf> Нет.

Во всяком случае он заявил, что то, как сделано в systemd, ему не нравится.

Я имел ввиду полсекунды ускорения.

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

Нет. Им это не нужно. Это перекладывается на специалистов, которые готовят решения. Это называется «Энтерпрайз».

dyasny> нужно чтоб железо работало из коробки и с минимумом дополнительной конфигурации, желательно вообще без вмешательства.

То же самое.

dyasny> если брать систему которая работает из коробки, это, в год, экономит больше чем лишнее железо, включая охлаждение и эл-во.

Ты уверен в том, что систему, которая работает из коробки и есть не просит, готовят неспециалисты?

dyasny> поддержка

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

systemd этому никак не способствует.

А при чём тут математика, когда речь идёт о как минимум двухкратном перевесе голосов?

Похоже, ты не знаешь ни grep ни sed толком. Ни даже awk. Я сам не знаток, но при надобности такое вполне реализуется. И то, что в journald это записывается строчкой покороче - не повод этот самый journald делать, так как в этом случае теряется универсальность инстурмента, и, как следствие, при изучении системы в условиях одного и того же времени теряется компетентность специалиста.

Интересное аргументированное сравнение OpenRC с другими системами инициализации.

Уже давно аргументировал

Не увидел. Кроме того, что «там редхад. редхад круты» «у кого больше бабла тот и прав». а потом эмции - «слоупоки». «застой».

Парочка таких вопросов на полгода, и проект можно закапывать.

Где обоснование, аргументы, расчеты... Опять эмоции.

опять какое-то странное голосование про «системд». неужели никто не видит манипуляций.
нужно такое голосование:

- требуется ли срочная смена системы инициализации в дебиан

Смешно. Ещё раз: я за systemd.

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

А если бы ты попробовала воспользоваться тем же OpenRC, то не пришлось бы на systemd тратить время.

Краткое содержание: alpha не знала про существование OpenRC и думает, что написание инициализационного скрипта/юнита с малым количеством строк возможно только на systemd.

Я что-то пропустил и дебьян стал коммерческой корпорацией?

«там редхад. редхад круты» «у кого больше бабла тот и прав»

опять вранье, пруфы в студию

Где обоснование, аргументы, расчеты... Опять эмоции.

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

anonymous> А чтоб меньше писать - копируйте «правильный» скрипт и используйте как болванку («правильные» же есть в системе)

Я даже дополню, указав, где такой скрипт в дебьяне лежит: /etc/init.d/skeleton

И эти люди критикуют «нестабильное API» и «лапшеобразный код»...

alpha> Вот и я думаю, зачем с нуля набивать, когда эти функции могут быть один раз реализованы в системе инициализации.

Вот только ценой понижения универсальности и гибкости. То, что есть куча случаев, близких к общему, ещё не значит, что надо забивать на частные. История такая же, как и X11 vs Wayland + Mir. Домашние хомячки практически не пользуются сетевой прозрачностью, и поэтому она им не нужна, но ради иллюзорных парочки FPS выкидывать иксы со всеми их костылями, которые, к слову, устраняют, хоть и не здесь и сейчас (а здесь и сейчас иксы работают превосходно, в то время как вялендомир показывает ужасные результаты), это сокрушительный удал по экосистеме GNU/Linux и СПО вообще.

Вот только ценой понижения универсальности и гибкости.

Опять чепуха. Для частных случаев systemd предоставляет ровно ту же возможность запуска произвольных скриптов, что и sysvinit. Только теперь это именно возможность, а не необходимость.

Похоже, ты не знаешь ни grep ни sed толком. Ни даже awk.

Телепат?

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

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

journald это записывается строчкой покороче - не повод этот самый journald делать

как и почему он сделан написано здесь, ознакомся.

так как в этом случае теряется универсальность инстурмента

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

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

еще о твоем фейерическом бреде - «работающем» sysv в debian hurd, оно даже в VM запускается не всегда. и порадуй уже меня скринами с openrc, интересно будет посмотреть.

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

«Нам не нужны грамотные кадры, которые умеют думать. Нам нужны рабы!».

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

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

alpha> И вариант, который позволяет мне не вдаваться без необходимости в детали того как _правильно_ реализовывать запуск демона из под пользователя, и где именно _правильно_ положить pid-файл и с какими точно правами он должен создаваться, а просто указать этого пользователя и пойти заняться другими делами, меня вполне устраивает.

Итого... Windows!

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

И самое интересное:

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

Тогда в чём проблема делегировать задачу одноразового написания инитскрипта человеку, который на этих инитскриптах собаку съел?

alpha> Просто потому что он не дает мне забыть учесть какую-то тонкость, где-то опечататься, и как-то ещё напортачить.

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