Мантейнер делает как ему удобно

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

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

Контроль нужен не сам по себе, а для решения каких либо задач.
sysvinit действительно был «кирпичиком» и на его основе можно было собрать на что только навыков хватит, при чём для этого не нужно было иметь большой квалификации.
А простой код этого init затруднял внедрение бекдоров.

А что сейчас говорят о систед?
Сложный код за которым трудно следить и который мало кто понимает.
Что он состоит из кучи подсистем с произвольными зависимостями друг от друга так что нельзя заменить какую либо подсистему без вреда общей функциональности.
То есть что с systemd не делай, а сделать что-либо принципиально отличное не выйдет.
Как я тут читал и с этим согласен такое снижение гибкости есть одна из целей.

сторонники Devuan жаловались на то, что в Debian специально включают в зависимости systemd

Debian - это не коллективный разум. Мантейнер делает как ему удобно,а не как хочется каким-то хейтерам.

Там писали что Systemd добавлялся в зависимости программам у которых зависимостей от systemd нет.
То есть нет реальных причин включать systemd им в зависимости.
Единственная причина которая могла потребовать установки systemd в зависимость это чтобы он утянул его с собой в установленный Devuan.
То есть саботаж дистра развивающего альтернативу systemd.

В Debian в качестве инита можно использовать то угодно.

Тогда что заставило сторонников openrc выделяться в отдельный дистрибутив?

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

Вот я бы и хотел услышать что это за задачи такие.

sysvinit действительно был «кирпичиком» и на его основе можно было собрать на что только навыков хватит, при чём для этого не нужно было иметь большой квалификации.

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

А простой код этого init затруднял внедрение бекдоров.

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

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

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

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

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

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

Что значит «принципиально отличное»? Это система инициализации, она занимается стартом и контролем за базовыми сервисами. Каких «принципиальных отличий» ты от нее ждешь? Чтобы она минет делала? И что это за цель такая «снижение гибкости»? Зачем? Какая от этого выгода мировой закулисе?

Там писали что Systemd добавлялся в зависимости программам у которых зависимостей от systemd нет.

На заборе тоже много что писали.

То есть нет реальных причин включать systemd им в зависимости

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

То, что использовать можно, но хреново. Многое нужное не работает.

Вот он, огромный список процессов от системди:

[root@test ~]# ps -efH
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 22:49 ?        00:00:00 /usr/lib/systemd/systemd
root        16     1  0 22:49 ?        00:00:00   /usr/lib/systemd/systemd-journald
dbus        22     1  0 22:49 ?        00:00:00   /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
root        24     1  0 22:49 ?        00:00:00   /usr/lib/systemd/systemd-logind
root        27     1  0 22:49 ?        00:00:00   login -- root
root        50    27  0 22:49 console  00:00:00     -bash
root        89    50  0 22:54 console  00:00:00       ps -efH

Ну не знаю, у меня несколько сотен вывело.

То, что использовать можно, но хреново. Многое нужное не работает.

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

Тогда что заставило сторонников openrc выделяться в отдельный дистрибутив?

Что за таинственные сторонники openrc? А сказать по секрету, что двое мантейнеров openrc в Debian одновременно его разработчики и разработчики Gentoo. Но только они не побежали основывать свой дистрибутив. Более того, мантейнят свою разработку в Debian. Но видимо они не сторонники openrc.

Что за таинственные сторонники openrc? А сказать по секрету, что один двое мантейнеров openrc в Debian одновременно его разработчики и разработчики Gentoo. Но только они не побежали ...

Ты мне ещё скажи что Devuan сделали наркоманы по приколу и вообще слухи про дистр неправильные и он не существует.

много разговора о systemd как о системе инициализации.

в systemd еще куча имплементаций и автор на достигнутом останавливаться вроде как не собирается. т.е. systemd легким движением руки превращается в linuxd.

А у тебя есть информация кто сделал Devuan и какое отношение они имели к дебиану? Не догадки а информация подкрепляемая пруфами? Мне для ознакомления с ситуацией.

Как можно иметь пять звёзд и не знать когда, при каких обстоятельствах и по каким причинам создавался Devuan?

Просто открой поиск лора и забив туда название этого дистра читай от старых постов к новым.

В общем сотри у себя две или три звезды резинкой.

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

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

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

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

Так-так. Я потерял тот момент перехода от «не хочешь systemd - не ставь» до этого вот «гладиолус»

Нужна альтернатива от которой все ахнут и побегут ставить себе а так «умвр» и чхать 95% т.к. есть работа.

Какого перехода? Моя мысль совершенно не про «не хочешь — не ставь», а про то что все теоретики заговора рассказывающие про «кровавая РХ навязывает всем системд административными методами» не удосуживаются ответить на вопрос «зачем».

Карл Маркс более столетия назад написал для чего, зачем и почему.
У него и читай.
Если лень искать то нацди в вк Эрзента и попроси пртслать подходящие цитаты.

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

А, вспомнил, эрзент он вроде эникейщик, работающий за черный рис.

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

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

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

И вообще, если у РХ УЖЕ есть все необходимые ресурсы чтобы протолкнуть нужный им говнософт во все дистрибутивы, ты не находишь что это означает что они УЖЕ контролируют всех и вся и УЖЕ достигли всех тех целей, ради которых, по мнению теоритиков заговора, весь этот системд и затевался?

Я не против теорий заговора, но я хотел бы чтобы эти теории хотя бы не противоречили сами себе.

Вендор-лок, очевидно! Ведь совместимость сломана во все поля.
(Я знаю про достоинства systemd. Мне, как не-сисадмину энетерпрайза, они не нужны).

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

Штооо? Я про вендорлок вообще говорил. Скоро собрать софтину под винду будет легче, чем под unix like систему без systemd.

Твоя теория заговора прогрессирует. Если раньше у РХ были ресурсы чтобы «всего лишь» протолкнуть системд во все дистрибутивы, то теперь уже всемогущая РХ заставляет просто всех делать системд неотключаемой зависимостью. Вопрос о том, зачем ей при такой неограниченной власти мараться о какую-то там систему инициализации, вместо того чтобы поработить нас прямо здесь и сейчас, остается открытым.

о какую-то там систему инициализации

При чём тут это? не собирается из-за другого софта, который больше не работает без systemd (logind, udev) и отчасти из-за cgroups.
Почему не держать простой костыль, чтобы logind, udev можно было бы запускать из другого init'а?

FUNCTION (06.11.2018 15:39:38)

В системд всё просто и прозрачно

4.2

То месиво слайсов/служб/вантов/юниов/ с uuid индентификаторами в /tmp /usr/* /var/* от пользователя от рута просто феноминально, запустить скрытую systemd службу в фоне и скрыть её ждва пальца об асфальт и хрен ты её найдёшь без скурпулёзного прошаривания всего глазами вручную. Никакого преимущества с шелл скриптами нет их можно через sha512 прогнать и если подозрешия то хеши сравнить, всему что не нужно -x на запуск установить и всё. Systemd порождает кашу.

Что нужно знать для написания антивируса под Linux (комментарий) FUNCTION (06.11.2018 15:39:38)

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

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

монопольная systemd архитектура это я скажу вам явный косяк.

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

тема чуши не раскрыта.

Системд изводит незавязанный на него сервис

очередную попытку предпринимаю исследовать systemd и снова разбиваю нос о простые вещи.

итак простая казалось бы вещь - cryptsetup.

В его составе есть программа decrypt_derived, позволяющая делать крипто-swap'ы легким движением руки.

Но при переходе на systemd «вдруг оказалось» что эта гадость парсит /etc/crypttab самостоятельно, мало того - распознает swap'ы и заново их форматирует!

итого гугление вопроса как подружить systemd, cryptoswap с hibernate без необходимости вводить 100500 раз пароли приводит нас к чуть ни единственному решению: лезть в Grub и из настроек Grub управлять криптой, а от использования crypttab отказываться.

ну не (цензура) ли?

объясните мне: ЗАЧЕМ systemd пытается сломать КАЖДУЮ вещь с которой соприкасается? вот буквально - КАЖДУЮ!

ненавижу

systemd - ППЦ

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

залез в я в acpi-support. Вернее обновил его. и он перестал реагировать у меня на LID.

стал копаться по его скриптам и пришел к тому что он теперь проверяет systemd-logind настройки и если systemd нет, то и LID нет.

то есть видимо рано или поздно придется или перейти на sysemd или майнтенить дистрибутив целиком. но пока переходить на LFS не с руки, покопался немного в системе с systemd.

systemd - ППЦ (комментарий)

Systemd наступает на десктоп KDE

С выходом Red Hat Enterprise Linux (RHEL) 7.6 сообщается о прекращении поддержки KDE Plasma, которая теперь считается устаревшей. Полная поддержка KDE будет прекращена в одном из следующих релизах RHEL. Поддерживать текущие версии Red Hat обещает как минимум до 2024 года. Фокус компании уже давно сосредоточен на Gnome, в разработке которой участвует немалое количество программистов Red Hat.

Red Hat Enterprise Linux прекращает поддержку KDE

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

ну он ставится как зависимость, привет

base amd-ucode
base bash
base bzip2
base coreutils
base cryptsetup
base device-mapper
base dhcpcd
base diffutils
base e2fsprogs
base file
base filesystem
base findutils
base gawk
base gcc-libs
base gettext
base glibc
base grep
base gzip
base inetutils
base iproute2
base iputils
base jfsutils
base less
base licenses
base linux
base linux-firmware
base logrotate
base lvm2
base man-db
base man-pages
base mdadm
base nano
base netctl
base pacman
base pciutils
base perl
base procps-ng
base psmisc
base reiserfsprogs
base s-nail
base sed
base shadow
base sysfsutils
base systemd-sysvcompat
base tar
base texinfo
base usbutils
base util-linux
base vi
base which
base xfsprogs
base glibc

Чтобы попасть в программу и получить стипендию вам должно быть 18+ лет, вы должны быть женщиной (цис или транс), транс мужчиной или гендерквиром. Так же в программу приглашаются чернокожие афроамериканцы, латиносы и все кто сталкивается с систематической дискриминацией в мире ойти.

Среди заданий для участников будут:
...

• Проверка юзабили ГНОМа

Outreachy набирают людей чтобы работать над ядром
Это что, подготовка навязывания systemd через привязку к DE Gnome?
Типа кто критикует Gnome, презренный расист, гомофоб и натурал?

Сцена вторая
При открытии китайского сайта, systemd-resolved - переключается на IPv6 - в обход dnscrypt-proxy.
Переключается на DNS servers провайдера.
Как запретить systemd-resolved переключение на другие DNS серверы?

systemd этот живет своей жизнью. Год назад также наступил в это дерьмо: Linux, Debian, Jessie - понять какое приложение шлет DNS запросы

Ссылка IPv6 + systemd-networked + systemd-resolved + dnscrypt-proxy services (комментарий)

Козни Red Hat

Странно, 2 недели назад упомянули разработчика Ming Lei из Red Hat, причастного к изменениям, которые, возможно, провоцируют эту ошибку, но он так и не присоединился к дискуссии в этом баг-репорте. А потом начал сопротивляться уже посланному патчу.

Если кто-то так безответственно работает (не обращает внимание на обратную связь, затрагивающую внесённые им изменения), может, его надо отстранить... Хотя, может, это политика Red Hat: сделать, чтобы у всех бились данные, но только не у клиентов Red Hat, т.к. Red Hat его публично доступную версию изменений и не использовали. А сопротивляется он потому, что правильное решение у него (и Red Hat) уже давно есть, и выглядит оно по-другому, а этот Jens Axboe, как назло, уже нашёл простой способ обойти проблему.

И ещё не заметил в патче https://patchwork.kernel.org/patch/10712695/ полей «Reported-by», хотя к человеку, открывшему отчёт, присоединились ещё несколько людей.

Ядро 4.19.x может вызывать серьёзные ошибки и потерю данных на файловой системе ext4 (комментарий)

Уже и в блочную подсистему проклятый систимде дотянулся?)

Странно, 2 недели назад упомянули разработчика Ming Lei из Red Hat, причастного к изменениям, которые, возможно, провоцируют эту ошибку, но он так и не присоединился к дискуссии в этом баг-репорте. А потом начал сопротивляться уже посланному патчу.

Говорю как старый LOR'овский Ъ: не ходить по ссылкам, даваемым другими — неотъемлемое право, но когда даешь ссылку сам (я про https://patchwork.kernel.org/patch/10712695/), прочти ее хотя бы по диагонали — не придется выслушивать справедливых упреков в 4.2. К слову о критике: если она вся — такого уровня, как коммент, на который отвечаю, то это не критика, а пачкотня.

Этот пост сделал gag и ссылка дана им, и обсуждали там не sysremd, а ext4 и влияние Красношапки на эту ФС.
Я только копипасту *как есть* сделал заключив её в цитату, чтобы понятно что это не мой пост.

П.С. потом гляну по ссылке.

прочти ее хотя бы по диагонали — не придется выслушивать справедливых упреков в 4.2.

Я-то читал. Ming не даёт своего «Reviewed-by», мотивируя, что надо и дальше думать, искать корень проблемы, таким образом тормозя принятие патча («сопротивляется»). А Jens говорит, что надо срочно поправить хотя бы симптомы, потому что у людей горит «стабильное» ядро. И патч Ming'а, из-за которого весь сыр-бор пару месяцев назад вообще предложили отменить.

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

Мы дадим вам enp1s0, говорили они, имена интерфейсов зафиксируются, говорили они

systemd и s6 (внутри докера) хватит всем

Держи ещё:

• https://security-tracker.debian.org/tracker/CVE-2018-16864
• https://security-tracker.debian.org/tracker/CVE-2018-16865
• https://security-tracker.debian.org/tracker/CVE-2018-16866