Подведены (http://permalink.gmane.org/gmane.linux.debian.devel.announce... итоги ежегодных выборов (https://www.debian.org/vote/2016/vote_001) лидера проекта Debian. В нынешнем году в голосовании приняло участие 282 разработчика, что составляет 27.5% от всех участников, имеющих право голоса (в прошлом году явка составила 35%, в позапрошлом 39%). Низкая явка в основном обусловлена предсказуемостью исходов выборов, так как в этом году заявку подал только один кандидат и выборы свелись к голосованию за и против него.
В итоге, на пост лидера утверждён Мехди Догуи (https://www.debian.org/vote/2016/platforms/mehdi) (Mehdi Dogguy), 32-летний уроженец Туниса, проживающий во Франции. Мехди работает в группе высокопроизводительных систем EDF (https://ru.wikipedia.org/wiki/%C3%89lectricit%... и занимался адаптацией Debian для использования на нескольких кластерах, входящих в список TOP500. Мехди также участвовал в создании специализированных производных дистрибутивов (например, Scibian, вариант Debian для научных учреждений), наработки которых вернулись в основной проект в форме улучшений к slurm-llnl, OFED, Debian Installer и Debian Live. На посту лидера Мехди намерен уделить основное внимание оптимизации взаимодействия между разработчиками Debian, выявляя узкие места и избавляясь от усложнений.URL: http://permalink.gmane.org/gmane.linux.debian.devel.announce...
Новость: http://www.opennet.me/opennews/art.shtml?num=44259
Ну неплохо. Хочется пожелать ему только удачи.
Хотеть такое же число кандидатов на высшие руководящие посты в госс-ве. Че-то все лезут порулить, хотя и сложность и отвественность вроде бы выше =)
Там есть возможность нарубить капусты и не сесть.
А в демьяне же нынче так - тебя все будут обс***ть, а ты это хавать - забесплатно. Под конец блестящей карьеры твоё имя в выдаче гугля будет забетонировано со всеми грязными словами какие только есть в убогом ёзыке эльфоф ... Это успех, такое всем нужно, да ... так что - в очередь!(С)
Зато какое резюме получится!
Скажет нет systemD?
На посту лидера Мехди намерен уделить основное внимание оптимизации взаимодействия между разработчиками Debian, выявляя узкие места и избавляясь от усложнений.
Да, скажет нет СистемД.
Да уже смиритесь с ним, и потратьте время на изучение доков.
«всё, что нас не убивает, делает нас сильнее» ©
«всё, что нас не убивает, делает нас сильнее» ©
Если только не калечит, не беременнеет и не вызывает зависимости...Хм. SystemD вызывает зависимость? :)
Как минимум зависимость от dbus!
На десктопе d-bus уже давно must have.
Чисто гномовская штука, принятая в KDE по недоразумению. В 2007, KDE взяло и отказалось от своего звукового сервера, от своего DCOP и от кучи чего ещё - в пользу гномовского
Вы ещё вспомните, КАК оно всё работало, это самое от КДЕ... Тут, скорее, не "отказалось", а "не осилило".
> Как минимум зависимость от dbus!Это неправда, работает и без него. Сперва неплохо бы матчасть подучить.
>>Хм. SystemD вызывает зависимость? :)Заставит вас забеременеть.
>Хм. SystemD вызывает зависимость? :)Нет он больше похож на радикальное Католичество(ну или секту). Поначалу его воспринимают в штыки и отказываются принимать, а потом берут в руки знамяD и продолжают "Крестовый поход Поттеринга", захватывая соседние дистрибутивы.
Радикальное православие чем-то лучше?
Крестовые походы они пока не устраивали
> Крестовые походы они пока не устраивалиНасильное крещение Казани Иваном 4 как бы не в счёт..
> Насильное крещение Казани Иваном 4 как бы не в счёт..скажи, что ты принимаешь и я скажу кто ты
"Страхом ко крещению никак не приводить" - приказ Ивана 4 епископу Казани.
> "Страхом ко крещению никак не приводить" - приказ Ивана 4 епископу Казани.Угу. Белые, пушистые православные священники.
Организация самого первого КП началась с воззвания Византийского императора Алексиоса I, и греки вполне себе поучаствовали, хоть и не на первых ролях. Отдельно, еще можно отметить совместный поход Амальрика Иерусалимского и Византии против Египта.
У вас два по истории.
> У вас два по истории.смотря ЧЬЮ версию истории рассматривать
> Хм. SystemD вызывает зависимость? :)Вызывает. Он удобный. Один только цивилизованный оверрайд дефолтных конфигов на свои чего стоит. Кардинально решили множество глупых проблем администрирования. В отличие от корявых художеств скриптопердозников.
> В отличие от корявых
> художеств скриптопердозников.Ага, главное почаще повторять и глядишь,
https://lists.freedesktop.org/archives/systemd-devel/2016-Fe...
> * Most configurable timeouts in systemd now expect an argument of
> "infinity" to turn them off, instead of "0" as before. The semantics
> from now on is that a timeout of "0" means "now", and "infinity"
> means "never" . To maintain backwards compatibility, "0" continues to
> turn off previously existing timeout settings.станет неправдой и забудется.
>> * Most configurable timeouts in systemd now expect an argument of
>> "infinity" to turn them off, instead of "0" as before. The semantics
>> from now on is that a timeout of "0" means "now", and "infinity"
>> means "never" . To maintain backwards compatibility, "0" continues to
>> turn off previously existing timeout settings.Зы, забыл разжевать для основной массы восторженных поклонников:
… конфигурируемые таймауты в системде теперь ожидают "infinity" вместо "0" для отключения … т.е. "0" теперь означает "прям щаз", а "infinity" – "никогда". А шоб вам не было скучно, для обратной совмести существовашие до этого таймауты все еще отключаются '0'.
Ты еще "забыл" уточнить что в sysv init таймаутами вообще никто не заморачивался. Их просто не было. Поэтому если сервис вис на старте - ни вам логов с ошибками, ни статуса операции. OpenRC не сильно лучше: не решает никаких насущных проблем администрирования систем.
> станет неправдой и забудется.Докопаться можно до любой программы. Только sysv init таймауты вообще никто и никак не ловит. Придраться к реализации конечно не получится, потому что ее нет, но от этого не легче.
Как минимум зависимость от ковбоев из RH )
Ну ты то по зависимости эксперт со своими ораклами и санями. Только вот редхат контрибутит в открытые проекты гораздо охотнее и активнее. За это и имеет влияние на окружающий мир. Жестко приказать они никому ничего не могут, а мягко повлиять, делая нужную работу - вполне.
а еще стоит помнить, что это выражение впервые вышло из уст психически больного человека
расслабьтесь и получайте удовольствие, ага
>Да уже смиритесь с ним, и потратьте время на изучение доков.Не как что бы давно так же пела всему миру Майкрософт: мол, смиритесь уже с виндой, и потратьте время на изучение книжек от МайкрософтПресс и сертификацию в тренинг-центрах имени нас (любимых) Теперь вот мелкомягкие молчат в тряпочку. Ну и с КрасноШапкой будет так же.
>«всё, что нас не убивает, делает нас сильнее» ©
Вот тут не поспоришь: НенужноД нас не убил (хотя очень-очень пытался), и немалая часть сообщества успела консолидироваться против этой заразы... за свою генту я почти спокоен, во всяком случае. Так что - да, мы стали сильнее. Чего не скажешь про systemd-зависимых.
> за свою генту я почти спокоен, во всяком случае.А подскажите где Gentoo используется на продашкне?
А вы используете системд в продакщне?
Я конечно понимаю желание набросить не по теме, потому отмечу его.Но всё-таки отвечу - я, прям сейчас, нет, не использую. Но т.к. в проде очень часто используется CentOS, то очевидно что через некоторое время неизбежно придётся. И на предыдущей работе коллеги из соседнего отдела использовали, не от хорошей жизни, а потому что для ультрамодносвежего софта написанного разработчиками требовалось всё самое свежее, что означило переход на свежую сентось, и соответственно системду.
Или предлагаете байкотировать требование менеджеров проекта, либо срочно переходить на Gentoo/Slackware?
> Или предлагаете байкотировать требование менеджеров проекта, либо срочно переходить на
> Gentoo/Slackware?И на вахтовую работу системных администраторов. Бхаха!
ЗЫ: Ну, со Слакой то раньше умудрённые системные ленивцы сидели (они там растекались по серверной ровным слоем). Сейчас не знаю как.
> А вы используете системд в продакщне?Все используют или очень скоро будут
Systemd нарушает Unix Way. Эта "философия" гласит о том, что лучше куча маленьких программ, делающих что-то одно, но хорошо. Systemd - монструозный полу-дистрибутив, делающий всё, что угодно, но из рук вон плохо.
Примеры можно? Некоторые вещи он делает лучше, чем "куча маленьких программ", например, sysvinit не поддерживает восстановление состояния сервиса.
Тебе же на пальцах объяснили - не одной гигантской прогой!
С чего бы init должен делать восстановление состояния сервиса?! Для этого, кому надо есть куча прилад.И зачем я это всё говорю? Тут этого никто не оценит!(С) Порудчик
Damage is done ...
объясните пожалуйста - почему для обновления systemd необходимо перебирать initrd?
а то обновил systemd, а оно бах не видит обновлений пока не обновилось ядро и не пересобрался initrd.
> объясните пожалуйста - почему для обновления systemd необходимо перебирать initrd?Этот вопрос надо задать своему дистрибутиву. У меня вот есть система где initrd вообще нет, а системд - есть. Парадокс? :)
дистрибутив самый правильный - RedHat EL 7.
> дистрибутив самый правильный - RedHat EL 7.Ну так и задай этот вопрос саппорту рэдхата.
> С чего бы init должен делать восстановление состояния сервиса?! Для этого, кому
> надо есть куча прилад.Поэтому вместо одного systemd-delta будет целая эпопея, а вместо 5-10 строчек с параметрами запуска - 5 килобайтов логики, которая быстренько отвалится без диагностики и средств отладки, как только что-то оказалось отлично от идеала. Такое управление системой может устраивать сопливых пыанэров которым главное пальцы перед одноклашками разогнуть, но для продакшнов это неприемлимо.
подскажите как выкусить атрибут shared который ставит systemd на все что не попадя?
> подскажите как выкусить атрибут shared который ставит systemd на все что не
> попадя?Это у вас не systemd, а винда. Проверьте её антивирусом. Systemd ничего такого по-умолчанию не делает. Может вы с ним экспериментировали под грибами или типа того, а потом забыли?
Вообще-то в компании, где я работаю, _все_ сервера продакшн на генте. И уже не один год. И полет нормальный. И переходить на что-то там иное никто не собирается. И слушать о том, какие мы неправильные и нетрушные - тоже. Завидуйте молча.
Откуда столько агрессии, что за реакция обиженного школьника? Я задал совершенно нейтральный вопрос т.к. мне интересно. В ответ какой-то взрыв эмоций. Тут уже точно хочется спросить "Это Gentoo людей так доводит?" :)А что за компания-то и сколько машин?
Я не завидую, я сочувствую.
<бывший гентушник>
Безумие не лечиться, пусть дальше доят козу.
> Безумие не лечиться, пусть дальше доят козу.Только потом оказывается как в анекдоте - "козел у вас конечно задр...й, но жить будет".
>...смиритесь с ним...Кресты тебе во все поля!
Микрософтизация линукса вызывает устойчивое отторжение у всех, знакомых с вольницей OpenSource не из рекламных проспектов.
> «всё, что нас не убивает, делает нас сильнее» ©"Я смотрю особо сильным тебя сделали глисты и блохи"
Изучение доков? Да это не доки, а хрень какая-то. Чтобы понять как что-то сделать - нужно... Сразу лезть исходники!
Для примера, как генерится из fstab-а соответсвующие файлы для подключения через SystemD? Покажите это в документации. (Просьба упоротых не говорить, что вначале пишем fstab, а потом генерим юниты) А... Нет? Да правильно, что нет, а почему нет - ниже.
SystemD является попыткой вполне обоснованного и очень красивого и удобного подхода к централизации процесса инициализации и управления всех связанных с этим процессов с использованием специальных декларативных файлов. Но это поптыка получилась, мягко говоря, хреновой по нескольких причинам:
1. Некоторые компоненты были частично подготовлены и их недостатки не задокументированы, потому см.п.2.
2. Некоторые компоненты были заговнокожены по мотивам определенных юскейсов, документация представляет собой маркетинговый булшит без какой-либо логической нагрузки. Про основной юскей тоже забыли сказать.
3. Полное отсутсвие валидации юнит файлов (процесса инициализации) - пока не сделаете ничего не узнаете. Отладка процесса инициализации без возможности её выполнить без виртуалки это потрясающее занятие, сродни того, что у меня работает, а Вы жуйте моё д*****. При этом есть прекрасная вещь в виде systemctl, которая может Вам показать как все работает, но при перезагрузке выяснится, что толку только проверка синтаксиса.
4. Большое количество юнит файлов "про запас" вообще вынесет мозг непоготовленного человека, которому не дистрибутив клепать, а один раз в 5 лет сервер настроить.Все эти недостатки были с самого начала, но их никто править не будет, потому что тогда SystemD админы потеряют свою божественность как таковую.
Итого, что имеем:
1. Декларацию правильного и удобного подхода
2. Отвратительную докуменатцию
3. Отвратительную реализацию
4. Отсутсвие улучшение имеющейся функциональности
5. Бардак в уже имеющейся функциональности
6. Невозможность отделить пользователькие задачи от общесистемных, да и вообще необходимость изучить все, лишь для запуска какого-либо своего сервиса
+
1. В нормальных init есть все модули и симлинки на них в каталогах с уровнями запуска, соответственно дергаются только необходимые. У Поттеринга дергаются все(причем из нескольких мест) и для отмены загрузки необходимо в каталоги с "более высоким приоритетом" создавать симлинк на /dev/null - что он курил, когда это придумывал остается загадкой.
2. Огромное число различных опций и проверок в Unit файлах жестко упирается в функционал systemd(потому он такой раздутый), если systemd чего проверять не умеет, но придется в unit файле городить sh костыль с абсолютно нечитаемой структурой.
3. Поттеринг любит вносить координальные изменения, но дабы у пользователя ничего не домалось добавляет костыли которые отличают unit-файлы до и после прихода новой версии. Т.к. обычный пользователь может тупо не знать об этом и не вносить руками изменения в unitы, то от версии к версии костылей накапливается все больше.
> 1. В нормальных init есть все модули и симлинки на них в
> каталогах с уровнями запуска, соответственно дергаются только необходимые. У Поттеринга
> дергаются все(причем из нескольких мест) и для отмены загрузки необходимо в
> каталоги с "более высоким приоритетом" создавать симлинк на /dev/null - что
> он курил, когда это придумывал остается загадкой.Благодаря такому механизму systemd хорошо взаимодействует с пакетными менеджерами. Есть дефолтная конфигурация от майнтайнеров, которую приносит пакет, в виде как посчитал правильным майнтайнер. А есть админская локальная, в /etc - на случай если майнтайнерские умолчания не нравятся. Локальная конфигурация имеет приоритет.
Зачем так? Затем, что при этом не надо беспокоиться угробит ли пакетный менеджер при обновлении пакеты локальный конфиг майнтайнерским и придумывать всякие подпорки и хаки. Пакет может менять свой дефолтный конфиг как хочет. Но админские изменения в /etc, если они есть - трогать никто не будет. Удобно и логично.
> 2. Огромное число различных опций и проверок в Unit файлах жестко упирается
> в функционал systemd(потому он такой раздутый), если systemd чего проверять не
> умеет, но придется в unit файле городить sh костыль с абсолютно
> нечитаемой структурой.В юнит-файле нельзя использовать скрипты. Но можно вызвать в ExecStart (ExecPre или где там еще) скрипт... который будет столь же (не)читаем как обычные sysv init скрипты. Просто этого счастья будет одно на сто пакетов. А не в каждом первом пакете. PROFIT.
Бонусом - ну попробуй указать какие системные вызовы использует твоя програма через shell script. Или там bounding set CAPS'ам задать. Что, ты даже таких слов не знаешь? А мы этим уже во всю пользуемся, урезая права сервисам до минимальных и настраивая всякие шедулеры и приоритеты. А много ли скриптов отслеживает таймаут старта подшефного сервиса? Кому-то конечно нравится молчаливый факап без диагностики, но не все же такие.
> 3. Поттеринг любит вносить координальные изменения, но дабы у пользователя ничего не
> домалось добавляет костыли которые отличают unit-файлы до и после прихода новой версии.Покажешь какой-нибудь суровый убедительный пример?
intelfx залогинься
> Бонусом - ну попробуй указать какие системные вызовы использует твоя програма через shell script. Или там bounding set CAPS'ам задать.Для этого вам нужен систем? А до системд вы этого не умели, не знали? А тут пришел Лёня и открыл глаза админам локалхоста. Т.е. системд хорош тем, что он нам рассказао о CAPs и т.п. Великолепно.
> Бонусом - ну попробуй указать какие системные вызовы использует твоя програма через shell script.
> Или там bounding set CAPS'ам задать. Что, ты даже таких слов не знаешь?
> А мы этим уже во всю пользуемся, урезая права сервисам до минимальных и настраивая всякие шедулеры и приоритеты.Ты похож на человека рассказывающего что GitHub это самая крутая система управления версиями.
http://man7.org/linux/man-pages/man2/seccomp.2.html
http://man7.org/linux/man-pages/man7/capabilities.7.html> А много ли скриптов отслеживает таймаут старта подшефного сервиса?
Вспомнилось "А ваши иниты могут стартовать систему за 3 (три !) секунды?"
Аж всплакнул.
> Для примера, как генерится из fstab-а соответсвующие файлы для подключения через SystemD? Покажите это в документации.:-) Так, что fstab работает, как должно работать. Для примера. Так и генерятся. Если так не генерятся, тогда bug, да, надо исправлять...
>> Для примера, как генерится из fstab-а соответсвующие файлы для подключения через SystemD? Покажите это в документации.
> :-) Так, что fstab работает, как должно работать. Для примера. Так и
> генерятся. Если так не генерятся, тогда bug, да, надо исправлять...подскажите как отключить установку флага shared на все директории средствами systemd?
вот ставит он его и не спрашивает fstab - хочет это пользователь или нет.
Как победить ?
Багрепорт вероятно...
(В fstab таких флагов нет. И в systemd тоже нет - никак не конфигурируется. Соответствующий комментарий гласит, что это для работы контейнеров...)
Кроме MountFlags в юнитах.
Кастрированный кот с вами врядли согласиться
Ну и в каких доках я могу прочитать про настройку таймаутов прибивания сервисов, к примеру?
> Скажет нет systemD?А что такое systemD?
А кто такой Марио?
https://youtu.be/xAdo9bgToTk
Это сантехник. И у него есть брат Луиджи.
Звучит как начало сюжета браззерс.
Король умер. Да здравствует король!
> и избавляясь от усложненийЭто давно не про дебиан
> намерен уделить основное внимание оптимизации взаимодействия между разработчиками Debian, выявляя узкие места и избавляясь от усложнений.Менторов сделают таки менторами, а не вахтёрами?
Скоро Debian будет пакеты таскать из Ubuntu а не наоборот,как сейчас...
Камасутра v2.0
Ты таки не поверишь...
Уже. С разморозкой.
> Скоро Debian будет пакеты таскать из Ubuntu а не наоборот,как сейчас...Да они их в обе стороны таскают, половина разработчиков убунты - разработчики дебиана. Дебиан - это такой правильный вариант центоса, но только вместо рхела убунта.
А что в центе неправильного
> А что в центе неправильногоВзаимоотношения с сообществом у убунты с дебианом лучше. И пакетный менеджер тоже.
зачем выбирать лидера каждый год? что можно за год сделать дельного работая даже на основной работе?
и как-бы отсутствие желающих на сей пост говорит о том, что люди понимают - обрести гиморроя себе на год а результатов труда так и не увидеть.
как Вы смеете сомневаться в общепризнанной правильности демократических процедур?
//sarcasm
Я его не знаю!!! Но рад за Debian.
Про существование Debian не знаю!!! Но рад за Мехди.
/* Fixed */
А теперь проверка на преданность идеям opensource: попробуйте назвать предыдущего лидера проекта (никуда не подсматривая)
почему-то не слышно недовольных возгласов против проведения выборов из одного кандидата
Может, потому что лидер Дебиана не лезет юзверю в карман и не объявляет крестовых походов против других дистров? А когда заканчивается срок, просто тихо уходит, а не меняет правила, чтобы подольше продержать свой царственный зад не троне?