Выпуск Systemd 243 с устранением уязвимостей

преимущества такого ПО как система инициализации и проявляются тогда, когда всё работает неидеально.

ага... комп не загрузился из-за сабжа - вот тебе и все преимущество...

Только ничего из этого не нужно. Ну ладно, GuixSD в качестве интересного концепта ещё покатит. Остальное никаких преимуществ перед вменяемыми дистрибутивами не даёт.

Только ничего из этого не нужно.

Systemd не нужно. А тот же devuan+maemo leste отлично подходит для кпк. Что ты на n*** поставишь? Devuan+heads для анонимизации и секурности, самой близкой к эталону, а не tails с незакрытыми cve и блобами. Slackware/crux - уникальные дистрибутивы с своими особенностями в архитектурном плане, а void - авангард в плане сборки софта и работы с сообществом. Это особенные, уникальные дистры. А все остальное лишь клоны красношапки, и их нужность теперь под сомнением.

Не systemd не нужно.

Fixed.

А вообще, уникальность дистра — штука вторичная. Вспоминается известный демотиватор «Just because you are unique, doesn’t mean you are useful».

Что ты на n*** поставишь?

Рутованного стока на них более чем достаточно. А вообще пора бы уже перестать насиловать труп и начать на современное железо ориентироваться: кнопочники на Qualcomm 205 в худшем случае, Gemini и подобное в лучшем.

А для x86_64 достаточно Arch. Остальное не нужно вообще.

А все остальное лишь клоны красношапки

Бред. Красношапка остаёт от того же арча по изначальной простоте и по актуальности софта в репах.

А вообще, уникальность дистра — штука вторичная

Вторичная. И единственная, заслуживающая внимания. Из клонов не выбирают. Это бессмысленная потеря времени.

Рутованного стока на них более чем достаточно

Что поставишь, спрашиваю? 😁

А вообще пора бы уже перестать насиловать труп и начать на современное железо ориентироваться

Ось для человека, или человек для оси?

А для x86_64 достаточно Arch.

Ааа, школьник... Приятно познакомиться.

Бред. Красношапка остаёт от того же арча по изначальной простоте и по актуальности софта в репах.

Что может быть проще инсталлятора и актуальней fedora rawhide?

Ааа, школьник... Приятно познакомиться.

Хм. Однако!

Не имею ниче против арча.😁

Лишь диагностика пациента по форме черепа.

Лишь диагностика пациента по форме черепа

Хохлонацло в своём репертуаре

Беги, стучи модераторам что нацпол развожу)

Да не, это надо специально оставить, чтобы люди видели кто ты и что ты.

Про форму черепа. Ты знаешь, я вот читал - про свою. И описание характера совпало просто 1 в 1.

Ой, подумаешь подорвал тебе пердак в треде про политику. Чё, злопамятный?)

Ну, раз в год и палка стреляет. Те же объяснения знаков зодиака так оформлены, что любой человек под них подойдёт. Под все. Каждого знака. С упущениями на индивидуальные различия/особенности. 😉

А это и не то, с чем непосредственно взаимодействует пользователь. Это внутреннее устройство системы.

Виндузятник детектед :) Что ты здесь забыл, виндузятник?

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

Что поставишь, спрашиваю? 😁

Ничего. Потому как рутованного стока более чем достаточно.

Ось для человека, или человек для оси?

Ось для человека, союзники для унтеров.

Единственную ось для человека потребыдло с лёгкой подачи ZTЁ и тормозиллы дружно закопало почти пять лет назад, теперь вот всем кагалом откопать пытаемся. Да, там нет systemd, но существующую там систему инициализации местные диванные ыксперды-луддиты тоже не жалуют.

Лишь диагностика пациента по форме черепа.

Диагностировалка не выросла.

Может и не выросла но я оказался прав.

Код выхода - это один из способов передать информацию. Всё остальное - лишь ваши домыслы.

Можно и гланды через жопу удалять, и дебаг через exit code делать.

Ну вот и выходит, что предъявить вам некому.

Предъявить что?

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

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

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

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

Значит, наряду с PostgreSQL надо поднять и продублировать всё в MySQL, ejabberd дополнить каким-нибудь openfire, локальный gitlab подпереть... чем, кстати?

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

Надеюсь, в вашей правильной конторе всё именно так и устроено.

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

Внезапно, преимущества такого ПО как система инициализации и проявляются тогда, когда всё работает неидеально.

И это неизбежно приводит к резкому падению качества софта и культуры производства, что собственно и наблюдаем. Зачем искать баги, что-то там чинить, думать о правильной архитектуре и организации работы, если можно просто перезапускать падающее говно? Системдэ очень вреден в дальней перспективе.

Можно и гланды через жопу удалять, и дебаг через exit code делать.

В какой-то книжке прочитали, что код выхода исключительно «для _штатной_ отработки совершенно _штатных_ вариантов развития событий при работе программы» - и изливаете теперь здесь свой синдром утёнка? Какие принципиальные проблемы с использованием кода выхода для передачи причины ошибки, внутренней или внешней?

Предъявить что?

За необоснованный простой.

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

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

Т.е. подумать чуть дальше своего огорода ты даже и не пытаешься. :) Понятненько.

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

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

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

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

За необоснованный простой.

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

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

Ты не поверишь. Это не только возможно, но и прекрасно работает уже 20 лет.

Теоретики, блин...

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

Т.е. ответить вам нечего, вот вы и отбрехиваетесь общими фразами.

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

И правда, всё с вами понятно.

Да, я вижу, понимание прям брызжет :)

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

Вы придуриваетесь или правда не понимаете? Делаю последнюю попытку объяснить.

К примеру, есть локальный gitlab. Работа происходит приблизительно так:

1. Программисты отправляют коммиты в репозиторий gitlab, где они проверяются автоматическими тестами CI.
2. Нередко изменения сперва проходят review через MR там же.
3. Когда подходит время выпуска, создаётся тег, по которому CI gitlab собирает тестовые образы и отправляет тестерам.
4. Тестеры сообщают о найденных проблемах в issues проекта в gitlab.
5. Когда основные баги исправлены, CI по тегу собирает финальные образы, подписывает их и отправляет на сервер обновлений, откуда их потом утягивают клиенты.

Эта инфраструктура сделана не просто так, а потому что она позволяет автоматизировать и свести воедино многие процессы, увеличивая эффективность. Но по-вашему, тут всё неправильно, поскольку рабочий процесс завязан на сервис. Давайте, предложите более эффективную альтернативу. Только не в общих словах в стиле «надо сделать хорошо», а конкретно.

Эта инфраструктура сделана не просто так, а потому что она позволяет автоматизировать и свести воедино многие процессы, увеличивая эффективность.

Видимо ты действительно вообще не видишь дальше собственного носа. :)

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

Не пробовал подумать, а зачем вообще клиентам нужно всё это ваше непреывное CI? Может им вовсе не CI нужно, а качественный продукт, на самом деле...

Видимо ты действительно вообще не видишь дальше собственного носа. :)

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

Нет, это вы не видите дальше собственного носа. Бизнес-модель интернет-провайдера «немножко» отличается от бизнес-модели, например, игровой индустрии, и слепо переносить свои повадки на других вам не следует. У вас может быть очень много клиентов, но всем им нужен приблизительно один и тот же набор сервисов. У нас же под три сотни версий конфигурации под разные страны и даже штаты, и любые проблемы с нашим ПО (которое чертовски сложное внутри) - это потери миллионов в день, и вовсе не рублей. Так что если у вас нет конкретных и чётких аргументов, то держите своё дилетантское мнение при себе.

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

И, традиционно, мы никогда не узнаем конкретного названия чудесного предприятия игровой индустрии где всё надо непрерывно обновлять и перезапускать. :)

Devuan+heads для анонимизации и секурности, самой близкой к эталону

Даааа, охеренная шутка про взлом инфраструктуры проекта на 1 апреля это и есть твоя «самая близкая к эталону секурность». У специалистов же баттхёртиан закономерно вызывает баттхёрт вопиющей некомпетентностью создателей.

Slackware/crux - уникальные дистрибутивы с своими особенностями

Ага, примерно как дауны и аутисты это «уникальные детки».

но существующую там систему инициализации местные диванные ыксперды-луддиты тоже не жалуют

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

Я знаю что ты, и кормить тебя не буду, извини. 😉

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

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

Вот это и используют, ибо в Gonk много чего из андроида позаимствовано. А в фоне там вертится довольно приличное количество сервисов, да. Правда, большинство ещё на стадии инитрамфс прописываются. И система триггеров там эпичнейшая. Хоть на вставку кабеля действие прописать можно. Такой уровень интеграции Лёньке даже и не снился. Впрочем, поскольку заточка под x86 === костыли по жизни, неудивительно.

Хоть на вставку кабеля действие прописать можно.

Ты про udev раньше не слышал?

Естественно, слышал. И даже правила пилил. Но udev — не тот уровень совсем. Конечно, может, я отстал от жизни, но вроде как udev-триггеры в сами юниты systemd поместить нельзя, в отличие от сервисных деклараций в андроидных инитах.

эталону, а не tails с незакрытыми cve

Devuan+heads

Это проект в котором ядро grsec, лохматого года патч, в котором после установки куча дырочек?

И ты их щас назовешь, да?)

Но udev — не тот уровень совсем.

Почему? «на вставку кабеля действие прописать можно» - это как раз тот самый уровень.

udev-триггеры в сами юниты systemd поместить нельзя

Напрямую - нет. Впрочем неясно зачем такое вообще может понадобится.

в отличие от сервисных деклараций в андроидных инитах

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

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

Есть сервисы, зависящие от событий железа. Например, зачем держать запущенным adbd, если кабель не воткнут? Или демон obexftp, когда блютус выключен?

Насколько я понимаю в связке udev/systemd это реализуется просто udev-правилом которое стартует/останавливает соответствующий сервис. Соответственно самому сервису (и сервис-менеджеру systemd) пофик, что именно его запустило или прихлопнуло - udev, пользователь или другой сервис.

Как это реализуется в случае андроида?

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

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

Thunderbird отдали «сообществу» и там меняется только версия движка, никакого развития.

Всё это «развитие» - чисто маркетинго-шизофренический бред. Есть потребности и есть инструменты - всё. Остальное от лукавого, чистая психиатрия. Ваше «развитие» - это маркетинговый ход, позволяющий впарить лохам одно и тоже десять раз в разных фантиках. Экстраполировать такой маркетинг на линукс - это чисто шиза какая-то.

А также заплатили Arch, openSUSE, Solus, Mageia, Rosa, AltLinux и т.д.

Достаточно подтянуть разработчиков KDE и Gnome, при этом сделав какие-то фишки, а-ля logind, и привязав их к systemd. И не очень большое комьюнити умрёт это всё от systemd отвязывать и махнёт рукой.

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

Вот да.

При этом возможность использовать полюбивщееся старье никто не забирал

Эту возможность забрали разработчики основных DE.

Разработчикам этих пакетов тоже заплатили?

Разработчики ленивые и не хотят писать инит-скрипты параллельно unit-файлам.

почему ты уверен, что те, кто был против systemd не сделали это по глупости/некомпетентности/ошибке/околорелигиозным предубеждениям?

Это элементарно: systemd избыточен в качестве init. init должен быть прост и надёжен, а тут такое: https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html. Linux всё ближе к десктопу: уже нужна перезагрузка для установки обновлений.

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

Так Поттеринг же писал, что разработка systemd будет вечной. Стабилизация - не его забота. :-)

Ну так код возврата и есть способ разобраться в причинах падения.

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

Переписывать это никто не будет. Увы, мир не идеален.

А, ну вот, что и требовалось доказать: systemd нужен для подкостыливания говнокда. Очень клёво.

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

Только это не было задачей процесса init.

И до сих пор не его задача, если архитектура правильная.

И до сих пор не его задача, если архитектура правильная.

Раз функционал приделали, то, увы, уже его. А это лишний ненужный для init код, где тоже может быть баг.

У нас один из сервисов устанавливает такое правило udev:

# Run touch2mouse service for each touch screen found
ACTION=="add", KERNEL=="event*", ENV{ID_INPUT_TOUCHSCREEN}=="1", \
    TAG+="systemd", ENV{SYSTEMD_WANTS}+="touch2mouse@%k.service"

При подключении сенсорного экрана запускается отдельный сервис для данного конкретного устройства. (Шаблонные сервисы - удобнейшая штука!)