И снова Лёня на связи! Systemd и безопасность!

Ну, хоть успокоится и бредить перестанет

Так тут деменция

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

Если кратко, Лёня категоричен - systemd должно быть монолитным.

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

кстати, а где Владимир?

Ну да, а потом сделают обязательной и все плагинные системы пойдут по одному месту.

И я даже подозреваю, где именно это всё ощущается. «Все говорят, что мы вместе. Все говорят, но немногие знают, в каком».

к чему это?! микроядро с модулями/сервисами? по моему нет?! я ошибаюсь?

Нужно!!! Больше?!?!?! Знаков!!!?!?!! Препинания!?!?!?!?! ставить!*?!?!?!?!?!?

- Что, гражданин, не спится?

Основная атака была как раз на systemd дистрибутивы?

это типа как «основная атака была на виндоус, потому что там синее облако на рабочем столе»?

Какие мысли?

Модулярность ПО приветствуется и в инженерии, и в инфосесурити. Лично мне не понятно, зачем мне линковаться с liblzma, в задаче сообщения статуса сервиса.

— Не искушай, орёл, без нужды. Мы хотим с Чебурашкой, который ищет друзей, служить в артиллерии!

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

Помогите, я запутался :(

Не ты один. Было дело, на Gentoo пробовал, без pam тупо не могло в графическую сессию.

- Нет препятствий патриотам!

телефонный терорист, телефонный террорист!!!

Т.е. тема представляет из себя либу в составе Qt, которая подгружается на рантайме? И Qt так устроена, что нельзя положить тему в состав ОС, а все остальное вместе с приложением?

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

В рамках Си проблема монолитности не решаема. А возвращаться к медленному и негибкому комку из башеговна никто уже не будет. Си потворствует реализациям в виде однопоточного процесса, вроде того самого /lib/systemd/systemd.

Чтобы появилась возможность НАДЕЖНО писать распределенные системы, микроядра, и просто многопоточные приложения, нужна возможность организовывать взаимодействие независимых алгоритмов между собой, а ее нету в Си. Беспорядочно отослать горстку байтов через пайп — это не организация. Даже «банальный» канал передачи данных с семантикой из одного потока в другой, как это сделано в Go — это уже большой шаг вперёд, но лишь один из.

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

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

В конце-концов, давай вспомним, что вся эта радость работает на OS Linux, которая тоже является таким же сишным монолитом — именно по тем же самым причинам, а микроядра не взлетели, потому что их сложно разрабатывать, и при этом они медленные и ненадежные. В частности, в той же винде GUI какое-то время был в ядре по тем же причинам (хотя изначально планировался модульным), пока компьютеры не стали достаточно быстрыми, чтобы вынести подсистему GUI в отдельный сервис.

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

Systemd состоит из здорового базового сервиса плюс всякая мелкая многочисленная обвязка вокруг. Если у тебя что-то отвалилось из обвязки, то systemd не сдыхает, но сам по себе /bin/systemd не дает даже банального шела, шел нужно дополнительно запускать, чтобы получить какой-то интерфейс пользователя. Нет pam, нет авторизации, нельзя войти в шел — наслаждаешься неинтерактивной сессией.

Нет pam, нет авторизации, нельзя войти в шел — наслаждаешься неинтерактивной сессией.

Это неверно. Вот на графическую сессию влияет и на модули. Они работают некорректно, ссылаясь на PAM.

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

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

Тебе нечего предъявить кроме шизофазии в стиле «родился на улице Герцена в гастрономе №22».

Даже «банальный» канал передачи данных с семантикой из одного потока в другой, как это сделано в Go

А в Го процессы между собой святым духом общаются, да. Да когда же уже синенавистники поймут, что кроме тех же способов IPC кроме тех, что доступны через си других то и нет, потому что это ограничение ОС а не языка. Пайпы, сокеты, юникс сокеты, файлы, шаред память. Всё. Нету больше способов. И язык тут не причем.

А как бы Вы решали существующую проблему?

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

переместить из адресного пространства одного потока в адресное пространство другого потока

Эвона как!

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

Это даже скорее ограничение процессора, а не ЯП. Заметь, что перечисленные тобой инструменты — это либо копирование памяти, либо разделяемая память. Процессор с когерентным кэшом невозможно сделать большим и эффективным одновременно, эта модель несостоятельна, потому вычисления потихоньку переходят на GPU, где, однако, не спешили готовить инструменты для реализации универсальных и предсказуемых алгоритмов. А без когерентного кэша ты не можешь организовать совместный доступ к этой памяти.

Ну или, если с позиции мейнтейнеров дистрибутивов — просто не завязывался бы на системд.

Критикуешь — предлагай альтернативу. Как можно заменить systemd без чудовищной потери в функциональности?

Как можно заменить systemd без чудовищной потери в функциональности?

Какой? Вот конкретно, какой?

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

Obarun’овский 66-init, базирующийся на s6.

Критикуешь — предлагай альтернативу.

runit, openrc, s6, dinit? Это что касается управления демонами и типа того. Мне больше всего нравится runit. Всё очень просто, не нужно читать тонны мануалов и т.д.

А что касается другой функциональности, вроде timers и прочей лабуды — это было и до и будет после systemd. Есть cron, например. Ну а часть «функциональности» systemd не просто ненужная, а прямо вредная.

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

Именно так!

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

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

Ядро Linux – это плохо или хорошо? Xorg – это плохо или хорошо?

А еще такие вопросы:

Несовместимые между собой десяток версий gtk{1,2,3,4} и qt{1,2,3,4,5,6} – это плохо или хорошо?

А когда весь такой юникс-вейный GNU grep ломает к херам более 20 лет совместимости без всякой причины – это плохо или хорошо?

Ядро Linux – это плохо или хорошо?

Это «реальность». Плоховато, но оно реально работает. Остальное ещё хуже, либо не доросло до реального использования. А так, очень жаль, что не взлетел Plan9 тот же.

Xorg – это плохо или хорошо?

Плохо, конечно.

Несовместимые между собой десяток версий gtk{1,2,3,4} и qt{1,2,3,4,5,6} – это плохо или хорошо?

Отвратительно.

А когда весь такой юникс-вейный GNU grep ломает к херам более 20 лет совместимости без всякой причины – это плохо или хорошо?

Ну сам как думаешь? Только GNU никогда юниксвейностью не отличались на самом деле.

перепишите его уже с нуля…

в /dev/null

перепишите его уже с нуля…

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

Это «реальность». Плоховато, но оно реально работает. Остальное ещё хуже, либо не доросло до реального использования.

Вот и systemd так же.

Это интегрированное решение, которое работает в рамках своей области задач.

В отличие ядра Linux, его относительно несложно заменить на что-то другое, если есть необходимость.

А у ядра Linux вообще нет альтернатив. И никто не жужжит.

В случае с systemd остальное работает как минимум не хуже. Ситуация совсем другая. Если «несовершенный» Linux — вынужденное зло, то «несовершенный» systemd — просто дурость.

В случае с systemd остальное работает как минимум не хуже.

Это не аргумент. Если что-то работает не хуже, но требует собирать себя из кучи деталек, то нет никакого смысла переползать с дефолта.

Точно так же собрать из кучи деталек систему с адекватным супервизором демонов можно было и до systemd. И что же? Мейнстрим сидел на куче легаси говна.

Это если говорить в целом. А если говорить в деталях, то вдруг может оказаться, что у «остального» нет сопоставимых средств изоляции служб, например.

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

Не было изначально смысла делать дефолтом монолитный кусок лёниной жизнедеятельности.

Точно так же собрать из кучи деталек систему с адекватным супервизором демонов можно было и до systemd. И что же? Мейнстрим сидел на куче легаси говна.

Теперь сидит на куче не-легаси говна. Не намного лучше.

В целом мне не очень хочется, честно говоря, углубляться в старый-добрый systemd-холивар. Все аргументы и за и против systemd с его «дефолтностью» и монолотностью/целостностью без взаимозаменяемых компонентов, равно как и про его дизайн, и про всё остальное, уже столько раз повторены на ЛОРе, не говоря уж про весь интернет (где аж сайты целые есть, этому вопросу посвящённые), что я не вижу смысла кидаться в тебя аргументами, которые ты уже и так наверняка читал не раз, и получать в ответ аргументы за, которые я тоже читал не раз. Слишком уж тема пережёванная уже. Давай, может, пропустим этот этап, и сразу agree to disagree?

которые ты уже и так наверняка читал не раз

Более того, я их еще и не раз писал.

Чтобы появилась возможность НАДЕЖНО писать распределенные системы, микроядра, и просто многопоточные приложения, нужна возможность организовывать взаимодействие независимых алгоритмов между собой, а ее нету в Си.

но есть – где? Limbo/Inferno, Go/тот же лимбо, ActiveOberon/AOS, ponylang, L4/C++, Ada/tasks, акторное чё-нить, ну и т.п.

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

Inferno/Limbo: «есть всего 3 сущности: файл/объект, зелёный поток/горутина, типизированный канал»

канал не совсем банальный – во-первых, типизированный, во-вторых, синхронный а не асинхронный.

сравни кстати например с L4::{Fiasco,Pistachio} микроядром на С++.

причина его скорости в том, что есть один примитив для IPC – синхронный sendrecv. выделение памяти через map/grant/revoke, иерархическая подкачка на основе sigma0 и прочих user-level pagers, планировщики, гипервизоры, паравиртуализация, вот это всё.

то есть: здесь тоже есть что-то вроде синхронного типизированного канала.

при этом оно таки на С++, но не суть. С++ там примерно для абстрактной фабрики через миксины, больше шаблонов богу шаблонов. эта абстрактная фабрика выдаёт токены типа ролевого мандатного доступа на capabilities, то есть, корректно типизированные ссылки на объекты ядра (микроядра). поверх которых затем делаем быстрый синхронный IPC.

в отличие от какого-нибудь Mach где 1) самих capabilites и сисколлов около 150 (в L4 около 11) 2)проверка корректности доступа реализована там – здесь доступ либо есть либо его нет, его не нужно по 20 раз проверять.

при этом это L4 как ни странно, реализовано на C++. хотя там часть сделана через IDL, часть через шаблоны шаблонов богу шаблонов.

И не в последнюю очередь проблемы создает архитектура процессоров, которая построена оптимизирована под Си (а не наоборот),

какого именно? тот же Chris Lattner из LLVM сетует что дескать, много всяческого UB из-за которого конпелятор сишки должен быть достаточно умным чтобы что-то там догадываться распараллеливать.

а он приводит примеры когда более низкоуровневое получается более эффективное чем ++ из-за того, что догадываться не нужно на тему семантики абстрактного исполнителя, модели памяти, UB, алиасинга и т.п. – а можно сразу использовать нужные ресурсы на этом низкоуровневом которое при этом получается и более эффективное чем ++.

смотрел из Qt4.8/copperspice или как там презентацию на тему «undefined behaviour is not error», ну почти как в SFINAE, лолъ.

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

и потому, например, на уровне железа нет функции плана «кинуть в другой поток 64 байта данных» — именно «кинуть», необратимо переместить из адресного пространства одного потока в адресное пространство другого потока, хотя внутри процессора такие механизмы есть.

опять же – имеются в виду что-то вроде map/grant/revoke или sendrecv из L4?

И в том числе неэффективность и сложность реализации асинхронных операций проистекает от того, что

кстати, а почему именно асинхронных? вот в L4 они синхронные и быстродействие IPC повысилось в 20…100 раз (по сравнению с Mach микроядром, например; да и по сравнению с QNX4 тоже лучше, хотя не в десятки раз, а просто в разы)

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

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

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

да ладно. вот L4 например вполне взлетело, и опять же – по быстродействию IPC там быстрее на порядки.

в Plan9 пытались то же самое делать на мультиплексировании P9FS styx протокола, например, тот же /dev/window, /dev/console, 8.5 и Rio;

в Inferno/Limbo/Dis – на уровне правильно типизированного языка Limbo = C + модули + ADT + правильные ссылки ref + корутины + каналы, и виртуальной машины Dis,

в AOS/ActiveOberon – на основе активных объектов,

в Ada – на основе tasks, рандеву и т.п. синхронизаций контролируемой памяти

в каком-нибудь pony lang – на основе модели акторов и типизированных различных reference capabilities ссылок

в общем, вопрос можно переформулировать так: какая модель многозадачности и IPC была бы более адекватна и насколько она тут должна быть завязана на сам язык???

Чтобы появилась возможность НАДЕЖНО писать распределенные системы, микроядра, и просто многопоточные приложения, нужна возможность организовывать взаимодействие независимых алгоритмов между собой, а ее нету в Си.

нужно что-то типа π-исчисления и сетей Петри.

вот кстати, про «Undefined Behaviour is not error» и прочий SFINAE.

аналогии: лисп тоже был определён как частично определённые, не тотально определённые функции.

вполне by design: Маккарти хотел язык, который имел бы возможность «заморозить вычисления» и например их обрабатывать символьно, в каком-то вручную задаваемом смысле.

вот недавно перечитывал recursive.pdf Recursive Functions of Symbolic Expressions and Their Comutation by Machine Джона Маккарти про формализацию лиспа, навеяло этим:

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

1. М-выражения – это метавыражения для записи вычисления применения функций. то есть: М выражение означает метасинтаксис типа двухэтажной W-грамматики алгола с метаправилами и гиперправилами, смысл которого: <Foo bar baz> означает вычисляем применение Foo с аргументами bar baz

2. S-выражения, или символьные выражения – это промежуточная форма записи для дальнейшей обработки (символьной – например ленивое вычисление либо символьное дифференцирование/интегрирование, каррирование и т.п.)

3. λ-выражения (лямбда-выражения) и например label – это формы, предназначенные для обёртывания в S-выражения (возможно, частично рекурсивные)

4. COND-выражения – это определение не тотально а частично определённых функций через условные выражения (если покрыты не все случаи, функция в этих местах не определена)

….

5. линейного лиспа L-выражения, стр. 30 – для хранения в виде ‘linear LISP’ для отображения S-выражений в строки

6. диаграммы и блоксхемы тоже можно, см. рис 5,6.

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

в форте вот есть внутренний и внешний интерпретатор.

здесь тоже можно сказать что классический лисп «на самом себе», «уравнения Максвелла в программировании» – это 0. метаязык макросов с unquote,splice и (a ,x)=(quote a x) `

1. внешний интерпретатор apply в терминах реализации eval, LABEL, QUOTE,NIL, COND
2. внутренний интерпретатор eval в терминах evcon, evlis, assoc
3. примитивы в терминах QUOTE,ATOM, EQ, COND, CAR, CDR, LABEL, LAMBDA, append, evlis, assoc
4. сама реализация примитивов частично рекурсивно через cond, car, cdr, eval, evcon, assoc, evlis

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

особо доставляют аналогии внешнего и внутреннего с двухэтажной W-грамматикой синтаксиса и семантики метаправил и гиперправил алголовых.

кстати, в алголе была дешёвая реализация parbegin..parend параллельных конструкций, например, тех же сопрограмм, cactus/octopus stack, продолжений и т.п.

либо тут что-то подобное seL4 или SPARK нужно мутить для формализации семантики параллельных процессов.

либо что-то реактивное типа коэффектов и монад хаскелеподобных.

нужна возможность организовывать взаимодействие независимых алгоритмов между собой, а ее нету в Си

но есть например в Limbo через каналы, ADT и горутины.

которые в том же Plan9 вполне себе были реализованы поверх обычной libplan9.

нужна возможность организовывать взаимодействие независимых алгоритмов между собой, а ее нету в Си.

а ещё лучше транспьютеры и язык Occam, и там действительно добились каких-то успехов (например, компиляторы Си и фортрана были реализованы поверх компилятора Occam и параллельных в смысле семантики пи-исчисления процессов)

в plan 9 графический интерфейс rio и 8½ реализован как мультиплексированный сетевой/файловый сервер, не факт что однопоточный.

в общем-то, вполне можно было бы обойтись и сишкой – если мультиплексировать аккуратно.

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

есть ещё способы. например, IPC в L4: map/grant/revoke, примерно 11 сисколлов и синхронный IPC с совмещённым sendrecv одновременно.

И язык тут не причем.

язык Limbo и вирт. машина Dis реализуют почти такой же Си, только сделанный правильно, типизированный правильно:

1. ссылки а не нетипизированные указатели из BCPL

2. ADT на уровне модулей

3. типизированные каналы и семантика CSP каналов Хоара, а не асинхронное непонятно что

так что язык в этом смысле имеет значение.

опять же, например, язык ActiveOberon и активные (а не как обычно) объекты.

или язык Ада и контролируемая память, limited controlled смарт поинтер какой-нибудь, foo'access корректно типизированные ссылки вместо бестиповых foo'address указателей, task type, task entry, рандеву, SPARK и Muen SK, вот это всё.

вот насколько невозможно было бы выделить в этом вашем монолитном systemd нечто наподобие tau0 из Muen SK, separation kernel на няшной Аде/SPARK ?

в Genode/sculpt OS есть похожее, в MirageOS unikernel тоже есть нечто похожее

в монолитном копролите от лёни потного – «не, не слышал»

Это даже скорее ограничение процессора, а не ЯП.

боттлнека фон Неймана, ога.

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

Occam и транспьютеры, например :))

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

а и не надо. вот в PonyLang делают акторы и несколько различных типов ссылок, ‘reference capabilities’ для эффективного распараллеливания.

чтобы значит share nothing.

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

примерно как сделано мультиплексирование ресурсов в Rio в Plan 9.

сначала, конечно нужно избавиться от systemd и его нелепой функциональности.

не жили в systemd – не надо было и начинать.

уязвимость в xz

атака на systemd дистрибутивы

Г-споди, дай людям мозгов…

Второе - по ссылке предлагаю распилить libsystemd на несколько кусков. Зачем - не ясно. Ну и да, как ты ловко (нет) подменил нежелание пилить libsystemd на куски фразой

Лёня категоричен - systemd должно быть монолитным

полностью поддерживаю!!!

вейланд не нужен, нужен nano-X, или Yutani из toaruos

линукс переписать на toaruos или L4

питон переписать на kuroko без GIL

турбовижн на Dflat и лиспОС на ChrysaLisp

грузиться сразу в микроядро поверх которого ChrysaLisp и далее в какой-то ucsd-p-system-os

блин, у него все репозитории тут довольно годные :)))