LINUX.ORG.RU

Devuan 6.1

 , , , ,


1

2

2 января состоялся релиз дистрибутива Devuan Excalibur 6.1, основанного на Debian 13 «trixie». Ключевое отличие дистрибутива – это поддержка систем инициализации, отличных от systemd. Дистрибутив поставляется по умолчанию с окружением Xfce. Пакеты собираются для архитектур i386, amd64, armel, armhf, arm64, ppc64el и riscv64.

Дистрибутив сопровождает около 400 пакетов, позволяющих функционировать без systemd, такие как например, elogind, OpenRC или runit. В целом, дистрибутив сохраняет совместимость с Debian, за исключением данных моментов. Доступны также окружения: Cinnamon, KDE, LXQt, LXDE, MATE и Sway. Система инициализации по умолчанию – SysVinit, можно перейти на OpenRC и runit. Также присутствует возможность работы без D-Bus. В качестве сетевого менеджера используется Network-Manager в варианте, не привязанном к systemd. ConsoleKit используется в Xfce и MATE, в остальных – elogind. Также стали доступны неофициальные сборки для Raspberry Pi.

Запущен также Devuan Testing 7 «Freia». Ключевые особенности релиза со стороны Devuan пока неизвестны.

>>> Подробности



Проверено: dataman ()
Последнее исправление: dataman (всего исправлений: 4)
Ответ на: комментарий от liksys

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

Тем не менее укажу, что 4 команды, что вы привели не есть ответ на мой вопрос. Мой вопрос, как получить список файлов загружаемых юнитов (с полным к ним путём) в порядке их запуска? Мне так же не нужен список всех юнитов, мне нужен список только запускаемых юнитов.

показывает юнит, который отвечает за этот сервис

Фишка, не нужная, если нет системд.

показывает тебе действительное состояние сервиса

Точно? Я вот помедитировал над выданным списком и нашёл, что, например, SMPlayer записан там с первым кином, а не тем, что он крутит прямо сейчас. Понятно, что это ни на что не влияющая мелочь, но ps же показывает, какой процесс фиктивный или зомби.

И вообще, читай документацию к systemd-analyze, там подробно расписано, как получить всю нужную информацию.

Так где удобства системд, если сначала надо читать много документации? Причём ради чего? Ради «знания системд»? А зачем мне её знать, если она не даёт мне никаких удобств по сравнению с тем, что было без неё?

И вот в этом месте вам подобные должны не срать на Devuan, а говорить подобным мне: «Тя никто ничего не заставляет, вали на свой Devuan, если тебе системд не нравится».

Это и есть путь СПО: возможность свалить туда, где комфортно, а не мудохаться с тем, что дают (да ещё и за деньги) «злые корпорасты».

mister_VA ★★
()
Ответ на: комментарий от mister_VA

как получить список файлов загружаемых юнитов (с полным к ним путём) в порядке их запуска?

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

Отдельно хочу заметить, что то, что ты хочешь - не являтся практической задачей. Мне, как человеку, который уже лет 10 делает продукты на systemd (а админит еще больше) никогда не было это нужно. Тем более, это не нужно и тебе. Тем не менее, решение - вот.

Фишка, не нужная, если нет системд.

Идиотская претензия.

Точно?

Совершенно точно.

SMPlayer

Откуда он у тебя там вообще взялся? Впрочем, ты даже не понял, о чем я тебе сказал: сервис != процесс. Сервис может быть запущен, потому что обрабатывается внутренними механизмами systemd.

Например, сервисом может быть однократно отрабатывающий процесс. Например, при загрузке OS тебе надо по I2C скормить в какой-нибудь чип маленький блобик. Ты пишешь сервис foobari2c, в котором ставишь зависимость от наличия /dev/i2c-0, а затем однократный запуск команды, загружающей данные. После того, как программа отработает, больше ты ее в ps не увидишь. А вот systemctl status будет показывать, что сервис активен, и процесс успешно завершился. А при остановке сервиса можно точно так же выполнить однократную команду и очистить память чипика. На оба этих действия можно навесить зависимости. Это недостижимая гибкость и уровень интроспекции для классических инитов.

Так где удобства системд, если сначала надо читать много документации?

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

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

Для тебя, как для конечного юзера, которому даже рут на машине не нужен, не меняется вообще ничего. Это удобство для дистросироителей, админов и разработчиков: возможность строить сложные деревья зависимостей, гибко ими управлять и избавиться от сопровождения инит-скриптов. Либо это делает systemd, либо ты пишешь и поддерживаешь собственные уникальные и неповторимые баш-портянки. Причем, если в первом случае на этот код смотрят тысячи человек, то со вторым тебе придется мудохаться самому.

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

вам подобные

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

не мудохаться с тем, что дают (да ещё и за деньги) «злые корпорасты»

Да-да. Злые корпорасты, пишущие ядро линукса - это хорошо. Корпорасты, сделавшие X11 - тоже хорошо. Корпорасты, сделавшие systemd - плохо, смотри не перепутай.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от pihter

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

Minerva
()
Последнее исправление: Minerva (всего исправлений: 1)
Ответ на: комментарий от Minerva

С 2019 наблюдаю за новостями этого дистрибутива

Я был там, Гендальф… 3000 лет назад

pihter ★★★★★
()
Ответ на: комментарий от liksys

софт, написанный людьми, внезапно был написан не просто так, а для решения какой-то проблемы

Да и эта проблема мною давно была озвучена: распараллеливание запуска служб/сервисов/демонов при старте системы. И так же давно мною был зада вопрос: а нахрена это на большинстве компов? Во-первых, там нет нужды что-то запускать параллельно, во-вторых, нет прироста скорости «холодного пуска», поскольку прирост скорости от параллельности съедается работой по выстраиванию дерева запуска.

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

Корпорасты, сделавшие systemd - плохо

Сделавшие – хорошие, начавшие его пропихивать безальтернативно – плохие.

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

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

Чаво? Какую логику какой системой?! Системой управляет (а) ядро, (б) пользователь этой системы, (в) системные службы. Системдэ тут лишняя прослойка.

Если у меня на компе крутится только почтовый сервер, dns-сервер и это типа защищено обычным брандмауэром, то зачем для этого системдэ?! А если вообще речь идёт о сервере СУБД, где нет вообще больше ничего, кроме?

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

ЗАЧЕМ? Строить сложные деревья зависимостей без простой возможности проверить их до запуска?

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

У системд есть либАстрал, который позволяет узнать, какие сервисы с какой скоростью запустятся ДО запуска?!

Это первая команда из моего списка

systemctl list-dependencies показывает дерево зависимостей, а не порядок загрузки.

Можешь скомбинировать баш-магией

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

Идиотская претензия.

Нет, это указание, что системд решает задачи, которые без системд не возникают.

Например, сервисом может быть однократно отрабатывающий процесс.

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

для того, чтобы пользоваться systemd

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

на этот код смотрят тысячи человек

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

на место systemd здесь можно поставить любой другой продвинутый init

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

mister_VA ★★
()
Ответ на: комментарий от mister_VA

эта проблема мною давно была озвучена

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

взгромоздил на него тот же Дебин

Как видишь, у меня на арче всё работает великолепно. Вопросы либо к дебиану, либо к тому, что ты в нем наворотил.

начавшие его пропихивать безальтернативно

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

(в) системные службы. Системдэ тут лишняя прослойка.

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

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

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

systemctl list-dependencies показывает дерево зависимостей, а не порядок загрузки.

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

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

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

ЗАЧЕМ? Строить сложные деревья зависимостей без простой возможности проверить их до запуска?

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

У системд есть либАстрал, который позволяет узнать, какие сервисы с какой скоростью запустятся ДО запуска?!

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

Нет, это указание, что системд решает задачи, которые без системд не возникают.

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

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

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

Вообще ничего читать не нужно, если всё и так работает

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

как я слышал

Как обычно, слышал ты разве что звон, из которого и сделал далеко идущие выводы. Идем на гитхаб и смотрим: 2420 контрибьютеров.

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

Я бы, конечно, мог докопаться до того, что я такого не говорил (я говорил, что «systemd - не система инициализации, а системный менеджер»), и что ты в очередной раз переврал мою цитату. Но не буду. Вместо этого я выскажу очевидную для разумных людей мысль, что подмножество systemd, которое выполнеяет функции init, сравнимо с другими современными инитами. В упомянутых инитах тоже есть специфические вещи и команды, которые нужно выучить.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 2)
Ответ на: комментарий от liksys

Вопросы либо к дебиану, либо к тому, что ты в нем наворотил.

Ничего, всё «умолчательное».

Дистростроители сами брали systemd и внедряли его, потому что видели в нем решение своих проблем.

Ога, так сами, что устраивали голосования, а потом форкали дистрибутив, чтобы получит всё то же самое, но без/с системд.

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

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

Т.е. системд претендует стать операционной системой поверх операционной системы. Зачем? Чтобы РедХат таки смогла выпнуть всех конкурентов с полянки?

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

Эти 3 сервиса я могу вручную запускать каждую перезагрузку, т.е. примерно 1 раз в жизни компа. Тут не нужна параллельность, тут справляется SysVinit четвертьвековой давности.

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

Именно. Для множества случаев это просто не нужно. Вообще.

для использования systemd достаточно понимать его базовые концепции и знать меньше десяти команд.

Для написания своих юнитиов этого тоже достаточно?

Идем на гитхаб и смотрим: 2420 контрибьютеров.

И? Решения принимаются среди них голосованием?

В упомянутых инитах тоже есть специфические вещи и команды, которые нужно выучить.

Есть. Но для SysVinit это примерно 1 листок текста, остальное – знание шелл-скриптов. Для OpenRC чуть больше, но опять самое сложное – шелл-скрипты.

Для системд шелл знать не надо, надо знать язык написания юнитов, что включат и знание ряда параметров, зависящих от версии системд. А шелл всё равно надо знать, если админишь хотя бы личный комп.

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

Ну а как «чинить» системд, восстанавливая систему, тоже ясно и понятно? Тута никакие systemd-analyze и systemctl и т.д. не помогут, системд работает ведь не от той системы, да.

mister_VA ★★
()
Ответ на: комментарий от mister_VA

Ничего, всё «умолчательное».

Значит к дебиану вопросы.

Ога, так сами, что устраивали голосования

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

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

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

системд претендует стать операционной системой поверх операционной системы

Не претендует.

Эти 3 сервиса я могу вручную запускать каждую перезагрузку

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

тут справляется SysVinit четвертьвековой давности

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

Для множества случаев это просто не нужно.

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

Для написания своих юнитиов этого тоже достаточно?

Да.

И? Решения принимаются среди них голосованием?

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

Но для SysVinit это примерно 1 листок текста

Для systemd то же самое.

надо знать язык написания юнитов

Нет никакого языка написания юнитов, алло. Есть самые обыкновенные декларативные INI-файлы. И подавляющее большинство юнитов пишется по одному и тому же лекалу. Конфигурация максимально примитивна.

А вообще, десять параметров в INI запомнить - это фу-фу-фу, а изучать целый бесполезный паскаль для обучения программирования - это вам норм, кабинетным клоунам. Либо крестик сними, либо трусы надень и будь последователен.

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

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

Ну а как «чинить» системд, восстанавливая систему, тоже ясно и понятно?

Совершенно понятно, но чуть-чуть иначе, чем во времена SysV. Проблема исключительно в том, что systemd сделал лично твои знания устаревшими, и поэтому ты на него бухтишь. Строго говоря, если ты понимаешь, как устроен линукс - проблем решительно нет никаких. А если не понимаешь - то за пределами стандартных плясок с бубном ты все равно ничего не исправишь.

liksys ★★★★
()
Ответ на: комментарий от liksys

Не охота вчитываться, о чем вы тут спорите, но:

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

Собеседник не в курсе, что порядок загрузки модно указывать при помощи After и Before?

wandrien ★★★
()
Ответ на: комментарий от liksys

А вообще, десять параметров в INI запомнить - это фу-фу-фу, а изучать целый бесполезный паскаль для обучения программирования - это вам норм

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

bread
()
Ответ на: комментарий от wandrien

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

corona
()
Ответ на: комментарий от wandrien

Собеседник не в курсе, что порядок загрузки модно указывать при помощи After и Before?

Собеседник просто включил дурачка. Я ему уже и systemd-analyze, и маны разжевывал - что в лоб, что по лбу.

liksys ★★★★
()
Ответ на: комментарий от bread

Изучать паскаль в тыщу раз полезнее

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

  • Либо софт на паскале встречается во много раз чаще, чем systemd;
  • Либо паскаль - такое говно, что софт на нем приходится править по месту кратно чаще, чем юниты systemd.
  • Либо всё сразу

%)

всё продолжаете небо коптить

Не ной.

liksys ★★★★
()
Ответ на: комментарий от liksys

Не читал ваше общение, потом перечитаю. Но предположу что ты исходишь из того что у тебя системд уже есть. Ты закрываешь глаза на ту цену которую системд запросил при его установке. Цену, о которой я писал в предыдущем посте – потеря командования. Ты больше не командир и не сисадмин. Для тебя эта цена маленькая (по каким-то твоим причинам). А для других эта цена большая. И они предпочитают другие решения с меньшей для них ценой.

(я не имею ввиду никакой конкретный пост, просто общее замечание)

corona
()
Ответ на: комментарий от corona

Я же советовал тебе не писать пьяным на лор.

Ладно.

Ты больше не командир и не сисадмин.

Это ложное утверждение. Если твое командирство заканчивается на знании баша - ты никогда командиром и не был. А если ты понимаешь глубинные процессы, происходящие в ОС - для тебя не поменяется вообще ничего, как не поменялось в этом случае для меня. Изменился лишь инструмент и язык, на котором он написан. Задачи при этом стали решаться сильно эффективнее. И я все так же могу залезть в исходники и что-нибудь там навертеть, нужное мне.

У большинства хейтеров просто припекает жопу от того, что systemd делает их сакральные знания, на поверку оказавшиеся поверхностными, неактуальными, и одним махом решает все проблемы, для которых оные хейтеры имели вагон скриптиков и готовые рецептики, написанные другими людьми (которые умеют читать сишный код и понимают SysV лучше сабжевых товарищей). Вот и вся история.

liksys ★★★★
()
Ответ на: комментарий от liksys

Если твое командирство заканчивается на знании баша … А если ты понимаешь глубинные процессы …

Какое-то упрощённое у тебя видение, либо, либо. Хотя я в том (linux.org.ru) посте писал именно про промежуток.

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

Хм, для тебя цена нулевая, странно. Ну ок, я вернусь к этому через несколько дней.

У большинства хейтеров просто припекает жопу … сакральные знания … вагон скриптиков и готовые рецептики

А может тут какие-то твои боли? Быть ближе к сути, к ядру, к тому «как оно работает» – это естественное желание. Все всегда (в детских садах, школах) стараются эти желания мотивировать. Желание «колдовать», склеивать башем «заклинания» утилит прямого доступа к функциям ядра – совершенно естественно. Чувствуешь себя волшебником, стоящим рядом с корифеями ядра (я писал об этом, в том же посте).

Ты почему-то отказываешь другим в праве (не юридически конечно – насмехаясь) на их совершенно естественные, и важные (может в ядре что-то сделает потом) увлечения.

corona
()
Ответ на: комментарий от corona

Какое-то упрощённое у тебя видение

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

я в том посте писал именно про промежуток

Там чушь понаписана.

Хм, для тебя цена нулевая, странно.

Нет никакой цены. Я не потерял контроль, для меня ничего не поменялось.

А может тут какие-то твои боли?

Ты не протрезвел.

Быть ближе к сути, к ядру, к тому «как оно работает» – это естественное желание.

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

Ты почему-то отказываешь другим в праве

Не отказываю. Еще раз повторяю: разработка ОС не должна ориентироваться на чувство собственной важности отдельно взятого юзера, который не хочет, чтобы его «сакральные знания» устарели. Ось должна быть удобной для разработчиков, сопровождающих и для большинства конечных пользователей в первую очередь.

liksys ★★★★
()
Ответ на: комментарий от liksys

Не отказываю. Еще раз повторяю: разработка ОС … Ось должна быть …

Это называется «соскочил». Я тебе про твои насмешки («припекает жопу») в адрес пытливых умов, а ты мне про разработку ОС. Таки отказываешь.

corona
()
Ответ на: комментарий от corona

Оные пытливые умы не в состоянии отличить mask от disable даже после километров объяснений. Это не пытливость, а воинственное ламерство.

Так что повторяю в третий раз: не пиши пьяным на лор.

liksys ★★★★
()
Ответ на: комментарий от liksys

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

bread
()
Ответ на: комментарий от liksys

В горячо любимой пытливым умом винде есть три состояния (на самом деле 4, но не существенно): выключено, вручную и авто.

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

wandrien ★★★
()
Ответ на: комментарий от liksys

Оные пытливые умы не в состоянии отличить

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

Мы пришли к общему пониманию что «заклинатели» вообще (а не некоторые конкретные) – это хорошо, и пусть их будет много? А недоразумений пусть будет поменьше. Так?

Или таки отказываешь?

corona
()
Ответ на: комментарий от bread

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

Ога, я вижу. @mister_VA, например, будучи паскалефанбоем со стажем, всё еще не в состоянии понять, как работают инструкции Before и After в оных юнитах.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от corona

Сорри, я правда не имею никакого желания разбираться в этом потоке сознания.

Не пиши пьяным на лор.

liksys ★★★★
()
Ответ на: комментарий от wandrien

что здесь эти же состояния называются соответственно замаскировано, выключено и включено

Почему только 3, должно быть 4: вкл, выкл, савсэм выкл, мамой клянус выкл! А потом после обновления шинда все равно включает даже то, что «мамой клянус». Вот как надо делать.

bread
()
Последнее исправление: bread (всего исправлений: 1)
Ответ на: комментарий от bread

вкл, выкл, савсэм выкл, мамой клянус выкл!

Держи, заслужил: 🤡

liksys ★★★★
()
Ответ на: комментарий от liksys

Человек, знающий баш - это человек, знающий баш. Всё, точка. … при разработке ОС

Ну вот опять, ты как-то упрощённо мыслишь. Если я сказал «сисадмин», то это (почему-то, в твоём понимании) человек который знает только баш. И опять ты почему-то перескакиваешь на разработку ОС.

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

Поставив системд, тебе надо читать маны, которые (имхо) монолитные и ненужно сложные. А без чтения нет уверенности. А без уверенности нет сисадмина. Причём вне зависимости от сертификатов и факта трудоустройства. Я это имел ввиду когда сказал:

Ты больше не командир и не сисадмин.

Да, это решаемо, чтением манов. Но у этого есть цена. Я в следующем посте напишу о ней.

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

Это как «я за всё хорошее и против всего плохого». Слишком, бессмысленно общо. На это можно натянуть что угодно. Люди разные, кому одно удобно, кому другое (винда, мак). А кому и удобства вообще не важны (разрабы опенбсд; а пользователи там по остаточному прнципу). Да и системд это большая тема, есть и плюсы и минусы. Вобщем, не надо перескакивать на «разработку ОС» при обсуждении других тем.

corona
()
Ответ на: комментарий от corona

Цена которую просит системд для уверенного администрирования – чтение манов. Я посчитал, для системд как голого инита, надо прочитать 75 страниц из 200-страничной книжки. Голый инит, т.е. не считая slice, scope, device, ещё кое-чего из базового, а также без журнала, логина, юдева, и многого чего прочего что подмял под себя системд. И без нетворк. Нетворк в дебиане свой, классический, на основе /etc/network/interfaces.


Как посчитано.

Посчитал число ключевых слов во всех юнитах во вполне дефолтной системе (виртуалка, иксы, без DE, просто WM, без специфичного софта типа nginx, samba). Также посчитал число ключевых слов, и вообще всех слов в базовых системд манах. Предполагая что все ключевые слова описываются одним количеством обычных слов, получил число слов, которые нужно прочитать (для большого числа должно быть вполне близко). Для перевода в страницы, сравнил с «Войной и миром» Толстого.

Не всё идеально, не всё парсится, например некоторые ключевые слова на нескольких строках. И DevicePolicy не распарсилось, лень писать точный регэксп.

Всего в тех манах 465 ключевых слов, и 81 тысяч обычных. В системе 179 ключевых слов. Получаем примерно 31 тысячу обычных слов которые надо прочитать. В войне и мире 587 тысяч слов, и 1440 страниц (судя по амазону).

1440*31/587=76.048
1440*81/587=198.71

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


создание списка ключевых слов в системе

#!/bin/bash

# unit type
ut=("service" "socket" "target" "device" "mount" "automount" "timer" "swap" "path" "slice" "scope")

rm -f all_units1.txt

while read sdir; do
if [[ $sdir == \#* ]]; then continue; fi
echo $sdir
for ((iiut=0; iiut<${#ut[@]}; iiut++)); do
find $sdir -iname "*.${ut[$iiut]}"|xargs cat >> all_units1.txt
done

done < systemd_dirs.txt

cat all_units1.txt |sed '/^\s*$/d; /\[.*\]/d; /#.*/d' |sort> all_units2.txt
cat all_units2.txt | awk 'BEGIN{FS="="} {print$1}' |sort| uniq > all_units3.txt

создание списка ключевых слов из манов

#!/bin/bash

if [ -z $1 ]; then echo "need a filename with the list of systemd keywords"; exit 1; fi

rm -f all_kw.txt

totalwc=0;
while read cm; do
if [[ $cm == \#* ]]; then continue; fi
echo $cm
gunzip -c $cm > cm
cmwc=`wc cm | awk '{print $2}'`
totalwc=$(($cmwc+$totalwc));

#echo "# $cm" >> all_kw.txt

awk '
    /\.PP/ {pp_line = NR; next}
    NR==pp_line+1 && /^[[:space:]]*\\fI.*=\\fR.*([,[:space:]]*\\fI.*=\\fR.*)*$/ {
        split($0, parts, ",")
        for (i in parts) {
            if (parts[i] ~ /\\fI.*=\\fR.*/) {
                gsub(/\\fI|=\\fR.*|[[:space:]]*/, "", parts[i])
                print parts[i]
            }
        }
    }
    pp_line = 0
' cm >> all_kw.txt
done < mans.txt
echo $totalwc
#cat kw_exceptions_ok.txt >> all_kw.txt

cat all_kw.txt|sort > all_kw_s.txt
comm -32 $1 all_kw_s.txt > rem.txt

mans.txt

/usr/share/man/man5/systemd.service.5.gz
/usr/share/man/man5/systemd.socket.5.gz
#/usr/share/man/man5/systemd.target.5.gz
#/usr/share/man/man5/systemd.device.5.gz
/usr/share/man/man5/systemd.mount.5.gz
#/usr/share/man/man5/systemd.automount.5.gz
/usr/share/man/man5/systemd.timer.5.gz
#/usr/share/man/man5/systemd.swap.5.gz
/usr/share/man/man5/systemd.path.5.gz
#/usr/share/man/man5/systemd.slice.5.gz
#/usr/share/man/man5/systemd.scope.5.gz
/usr/share/man/man5/systemd.unit.5.gz
/usr/share/man/man5/systemd.exec.5.gz
/usr/share/man/man5/systemd.kill.5.gz
/usr/share/man/man5/systemd.resource-control.5.gz

systemd_dirs.txt

/etc/systemd/system
/usr/lib/systemd/system
/usr/lib/systemd/user
/run/systemd/transient
/run/systemd/generator
corona
()
Ответ на: комментарий от liksys

Нет никакой цены

Это говорит о том что ты эти ман страницы не читал, или не смотрел юниты в своей системе. Ты делегировал администрирование системой системд. Ничего страшного. Просто твоё:

Я не потерял контроль, для меня ничего не поменялось.

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

corona
()
Ответ на: комментарий от corona

Цена которую просит системд для уверенного администрирования – чтение манов. Я посчитал

Дальше я этот бред не читал. Это всё пустые теоретизирования.

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

Повторяю еще раз:

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

  2. Не пиши пьяным на лор.

liksys ★★★★
()
Ответ на: комментарий от liksys

Дальше я этот бред не читал

Эх, жаль. Ты прочитал 11 слов, а весь результат в следующих 9 словах. Надо было мне те 9 слов в начало поместить, тогда ты бы успел прочитать результат.

Если чтение манов само по себе является ценой -…

Да. Конечно.

… никакой ты сисадмин

Хм, неожиданный вывод :)

Повторяю еще раз … на низком уровне оно все так же общается с ядром

Я эту твою мысль понял с первого раза, и пояснил: Я имел ввиду под «промежутком» сисадмина, который….

Ты оставил без внимания простое рассуждение. Без чтения манов нет уверенности. Без уверенности ты кожаный мешок а не сисадмин. Надо читать, 75 страниц. Это цена (не вся конечно). Ну же? Давай уже, признавай! :)

corona
()
Ответ на: комментарий от corona

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

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от liksys

Ок :)

Давай тогда о другом попробуем – сеть.

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

В отличие от инита, где ини-файлы вполне оправданы, такие конфигурации – это в большой степени программирование. Можно написать баш скрипт, с вызовами unshare, nsenter, ip, iptables, etc, и накрутить там любую программную логику. А можно прочитать ещё 130 страниц (я перевёл 52.3 тысячи слов из трёх манов, systemd-network, -link, -netdev в страницы) с описанием того как системд переводит эти объективные сложности в простые ини файлы. И здравый смысл подсказывает что всё равно, ини файлы программу не заменят.

Поэтому кмк есть ещё одна цена, отложенная (когда/если понадобится) – это 130 страниц + бодание с переводом объективных сетевых сложностей в простые ини-файлы (aka жгутики, в терминах метапрога, он тоже «упрощательством» занимался, уверен ты его помнишь).

corona
()
Ответ на: комментарий от liksys

понимания принципов работы ОС нет

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

bread
()
Последнее исправление: bread (всего исправлений: 1)
Ответ на: комментарий от bread

В соседнем треде выяснили

Не выяснили.

При любой непонятной ситуации можете только расплакаться

Можем пойти и поправить код, конечно же. Рекомендую перестать выдумывать чучелки.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 2)
Ответ на: комментарий от liksys

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

corona
()
Ответ на: комментарий от liksys

Опять лишь реакция без поста. Здравый смысл тебя заборол, и ты поплыл :)

Ладно. Я только лишь прокомментирую твоё «Не нужно».

Например я пробую сконфигурить ipsec, в близкой к реалу конфигурации подсетей. Или я реализую анти-ддос для сайта, и хочу проверить работу BPF (как пример; никогда не писал), и мне нужны сотни виртуальных хостов. Или вот, задачка (первое что подвернулось в поиске): Два браузера на разных сетевых интерфейсах (заметь кстати, люди предлагают нэймспэйсы и firejail, и никто не предлагает системд). Да мало ли для чего такое нужно.

corona
()
Ответ на: комментарий от corona

Здравый смысл

Здравого смысла от тебя не было, один бред

поплыл

Да-да, убеждай себя в этом.

Я только лишь прокомментирую твоё «Не нужно».

Мое «не нужно» было о твоих постах - что мне не интересно обсуждать твои галлюцинации по поводу мануалов и псевдосложности systemd.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от liksys

… твои галлюцинации по поводу мануалов и псевдосложности systemd.

Да, спасибо. Действительно, надо прояснить.

Не помню чтобы я писал что системд сложный. Я его почти не пробовал, исходники конечно не открывал, я только маны читал. Если напомнишь – я тогда уточню что имел ввиду. Помню я писал про маны: монолитные и ненужно сложные. Это да.


Монолитные.

По уму описание должно быть по главам, определяющимися задачами, как с помощью системд решить ту или иную задачу. Примерно так пишут учебники. Можно остановиться на любой главе, выкинуть остальные, и жить с полученными знаниями, применять их (ну плюс-минус; так не делают в молодости конечно, но в зрелости легко). Хочу я изолировать проприетарные зловредные сервисы – вот глава с ключевыми словами про это. Хочу automount – вот ключевые слова про это. А хочу голый инит – вот введение на 3 странички с 10 ключевыми словами. Это был бы хороший, годный ман. Сейчас оно читабельно, но оно всё сгруппировано по… не знаю чему, реализации наверно? Сделали, и описали что сделали («мам, смотри, что я сделал!»). Это негодные маны (для пользователей). Люди решают свои задачи, и им не интересно что вы там сделали.

Ненужно сложные.

  • Частично это просто дополнительное слово для описания той же монолитности. Из-за дурно-сгруппированного изложения надо прочитать не 75 (linux.org.ru) нужных страниц (они же никак не маркированы, используется в системе это ключевое слово или нет), а все 200, и по ходу чтения решать, достаточно ли это востребованная функция, или нет. Надо самому в голове маркировать. Головняк.

  • Частично это те самые неудачные 80% усилий которые нужны для 20% функций (правило Парето). Как пример, сеть: все-объемлющие ини-жгутики – это в принципе дурной упрощательский подход, см. выше.


Но. Конечно маны писали не дураки. Есть причина (как минимум одна) по которой маны вот такие, и подход системд (ини файлы) вот такой. Деньги. РэдХэт получает денежку за курсы и сертификаты. Тогда монолитность и сложность нужны. (РэдХэту)

А денежка эта (наверно маленькая доля всех денег, но всё же) берётся в конечном счёте из наших карманов. Если это чья-то личная инвестиция, то она перекладывается на работодателя (сертифицированный специалист стоит дороже). Либо сразу на нас, путём увеличения цены на продукт/сервис, если это инвестиция работодателя в сотрудника. С мира по нитке – нищему на рубаху мэнеджерам РэдХэта бОльшие зарплаты.

corona
()
Ответ на: комментарий от corona

Монолитные.

Нет. Это многократно разбиралось и опроваргалось.

Дальше этот слоп можно даже не читать.

liksys ★★★★
()
Ответ на: комментарий от liksys

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

corona
()
Ответ на: комментарий от corona

Ссылку дать – не барское это дело?

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

получишь по попе :)

Оно еще и хамит. Тем более обойдешься без ссылок. Иди образовывайся сам.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 2)
Ответ на: комментарий от liksys

Оно еще и хамит

Да ладно, «попа» – это вполне мягко, по-детски. На самом деле ты мне нравишься. Просто тем что ты разработчик. В моих глазах – этого достаточно, всё, ты ценный. Заббала бы я выкинул нахер с форума, обойдёмся без новостей о системд. Просто ты заблуждаешься (типа и командиром остался, и цена нулевая, ну чудес не бывает же, ну), и упрямишься почему-то на ровном месте. Хочу понять.

И я кстати месяц назад назад хотел перейти на системд. Правда. Но… вскоре ужаснулся.

PS.

Да, я назвал тебя там «кожаным мешком». Немного резко вышло, да. Извини. Можно было помягче выразиться. Это с необходимостью следовало из твоих утверждений. Формально так. Фактически – неудачно вышло, да, извини.

corona
()
Последнее исправление: corona (всего исправлений: 1)
Ответ на: комментарий от liksys

Ещё не прочитал всё, но вроде никто не просил тебя, так что попрошу я.

тут (linux.org.ru):

systemd используется на оборудовании UI

Тут без конкретики ничего не понятно. Системд может быть на каком-то общем сетевом оборудовании, а NASA использует лишь их камеры, где системд скорее всего нет, причём лишь для охраны парковки. А может и да, используется для критично важного, просто у Ubiquiti есть специалист который захарденил им системд. Есть конкретика? (кстати про спутник в космосе тоже хотелось бы конкретики, жаль tinykey забанился)

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

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

Но самое главное – а точно у тебя системд это необходимость (альтернативные пути объективно хуже), а не опыт и личная симпатия? Я имею ввиду что разраб с опытом в другой ОСи (QNX, VxWorks) использовал бы для этой цели свою знакомую ОСь, а не линукс, и системд не появился бы даже на горизонте. А если и линукс, то в инете полно страниц где люди (с опытом) аргументируют против системд в эмбеде, и не используют его. Но ты всё равно, похвастайся пожалуйста! :)

corona
()
Ответ на: комментарий от corona

Мне наскучило. Сто раз уже всё обсуждалось.

liksys ★★★★
()
Ответ на: комментарий от corona

Бывший RedHat’овец, PhD, весьма опытный и в софте и в электронике, не удовлетворён системд в эмбеде – за альтернативные без-системд линуксы, и даже (сдержанно) против системд. Kevin Boone (когда искал, видел ссылку, но зря не добавил к предыдущему посту)

corona
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.