systemd-free всё

Ну так это же фрактал. Человек со злокачественной опухолью чсв.

Он удалил всего один пост, но дерево из 388 постов

Даже в тредах про YOBA кулер такой фигни не было. Уж там то срач был какой, а чистили все равно ручками и аккуратно.

Он удалил всего один пост, но дерево из 388 постов

Так надо уметь.

спокойно живу без систумд в генте. в чем проблема?

p.s. хочу заметить что leave выписал -3 хейтеру, а фанбоям снял с нулем

p.s. хочу заметить что leave выписал -3 хейтеру, а фанбоям снял с нулем

Да пусть срач всполыхнёт с новой силой!

С нулем снимается автоматом дальше второго узла в дереве удалённых.

Туда ему и дорога.

Да пусть срач всполыхнёт с новой силой!

Чего сраться, нужно писать принципиально новый инит.

Во-первых — его главный процесс (который имеет PID 1) должен иметь минимум библиотек с которыми он слинкован, код должен быть максимально простым (возможно даже примитивным) — чтобы не упал. Задача этого процесса — назапускать процессов, делающих всю настоящую работу (парсинг конфигов, запуск демонов и т.д.), и при падении worker-ов перезапускать их.

Во-вторых — демоны могут быть описаны как простые скрипты запуска и остановки (раздельно), начинающиеся со строки #!${path_to_shell}, всё остальное содержимое процесс-гвардиан этого демона скармливает проге ${path_to_shell} на стандартный ввод. Опционально демон может содержать файлы dependencies и environment в которых описаны соответственно все зависимости демона (по умолчанию зависимостей нет) и окружение демона. Это вместе с многопроцессностью инита позволит реализовать конкурентную загрузку.

В-третьих — наследование демонов. Второй способ описания демонов — файл inherited, содержащий имя демона, на котором основан текущий. Тогда те файлы, которые есть в папке демона заменят соответствующие файлы демона родителя (для файла окружения применять слияние с приоритетом потомку).

В-четвёртых — тулза для миграции с устаревших инитов. Она позволит автоматизировать процесс перехода, и как следствие продавить новый инит всюду. Нечего сидеть на копролитах!

Имея такой инит можно реализовать:

• парсинг демонов на gpu — так как процессы-гвардианы демонов уже не являются главным процессом ОС, то можно их прилинковать к libopencl.so или libGL.so и реализовать парсинг с использованием ядер или вычислительных шейдеров. Если написать шел, выполняющий скрипты с использованием мощностей gpu, то всё совсем станет хорошо.
• Добавление аналогов «типов юнитов» из systemd — это просто демоны шаблоны, использующие переменные окружения (т.е. всякие ExecStart, ExecStop будут прописываться в environment потомка).

Насчёт смены раскладки и человечного скроллинга в tty — этим лучше пусть занимается отдельный проект. Принципиально новая замена tty (но это уже будет совсем другая история).

всё остальное содержимое процесс-гвардиан этого демона скармливает проге

по-твоему выходит, я каждый раз должен делать вроде service jail reverse_stop взаместо одного echo "jail_reverse_stop=true" >> /etc/rc.conf
вместо реализации, давай-ка сначала про UI\UX подумай.

Сори, нераспарсил.

Я честно пытался, даже «взаместо» зареплейсил сначала на «заместо», а потом на «вместо»^U

Если это про автостарт демонов, то он естественно будет обязательно (правда я ещё не знаю как — наверное симлинками на каталоги демонов или файлом с их названиями).

Если это про передачу параметров в демон, то все они должны быть в его environment.

Go for it!

Пришёл поручик и всё опошлил.

Ничего никто не опошлил. Вам показалось.

Поручик, лучше идите опошлите ещё что-нибудь.

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

Напомню, что ты высказался за выкидывание Qt и GTK. Я вот вообще не вижу тормозов в Qt и GTK при нормальных условиях. А при ненормальных тормозит даже консоль. Так что написание интерфейсов с использованием обёрток, КМК, вполне оправдано, ибо плюсы (лёгкость написания и доступа к функциональности, единый внешний вид и настройки) перевешивают минус в виде возможного снижения скорости работы. Так же оправдано, как использование скриптов в определённых случаях. Web затрагивать не будем, это уже отдельный разговор. Вернёмся к теме systemd. У меня нет каких-то бенчмарков, чтобы посмотреть на разницу скорости работы systemctl/юнитов и init-скриптов. Но недостатки скриптовой логики также и в уже упомянутой неочевидности. В systemd уже реализована и документирована логика поведения. А на Bash можно что-то упустить (уже приводились примеры с отслеживанием процессов и порядком запуска), реализации могут быть костыльными и т. п.

Ещё ты жаловался, что systemd это комбайн и зачем там вообще networkd. Про это штеудач уже пояснил, но я ещё хочу добавить, что ты же не жалуешься, что в Bash встроены свои реализации cd, echo, test, kill (или жалуешься?).

И наконец: как часто ты вообще напрямую сталкиваешься с инитом? Один раз прочитать man (тем более что во всяких Arch Wiki ещё и подробные инструкции есть) и настроить как надо — не так уж сложно. При этом нет никакой гарантии, что с другим инитом ты потратишь меньше времени и сил на настройку, даже умея писать скрипты. А ведь systemd ещё и предоставляет различные полезные функции, например socket-активацию, автоматическое монтирование, таймеры, nspawn. Но ты всё равно готов отказаться от удобств Arch Linux и сидеть на какой-то маргинальщине. Подумай, есть ли в этом смысл.

Я может и упорот, но вроде бы не полный дебил.

Очень на это надеюсь.

Если это про автостарт демонов

т.е. ты не знаком с другими ОС и как там устроенно? *bsd\opensolaris? как можно придумать систему инициализации имея лишь две вводные: [не systemd] и [запускать сервисы на gpu]? посмотри как там у других.

Если это про передачу параметров в демон, то все они должны быть в его environment.

плохо представляю, как это?

хочу заметить что leave выписал -3 хейтеру, а фанбоям снял с нулем

Первый же удалённый с -3 комментарий от «фанбоя», а дальше по 7.1.

реализации могут быть костыльными и т. п.

И systemd тоже.

systemd это комбайн

Эалонный.

зачем там вообще networkd

Он там ненужен, но его почему-то анально пропихнули.

в Bash встроены свои реализации cd, echo, test, kill (или жалуешься?).

Они там ненужны.

как часто ты вообще напрямую сталкиваешься с инитом?

Когда он мне в консольке (фреймбуффере) прямо посреди ввода чего-то пишет какую-то невразумительную хрень.

Один раз прочитать man (тем более что во всяких Arch Wiki ещё и подробные инструкции есть) и настроить как надо — не так уж сложно

И к «не-systemd» тоже самое относится

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

Ну ты понел

А ведь systemd ещё и предоставляет различные полезные функции

И емакс ещё надо, да, обсуждали уже.

Они там ненужны.

Нужны — производительность наше всё.

Когда он мне в консольке (фреймбуффере) прямо посреди ввода чего-то пишет какую-то невразумительную хрень.

А почему это в systemd не фиксят? А потому, что обратная совместимость — первая версия так себя вела, а значит так будут себя вести и 230, и 887, и 100500 версии. Фтопку. Переписать с нуля.

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

как можно придумать систему инициализации имея лишь две вводные: [не systemd] и [запускать сервисы на gpu]? посмотри как там у других.

А чо там думать? Главное сделать на яваскрипте, там заодно поддержка webgl будет.

Сначала надо решить на чем писать - на яваскрипте, на кофескрипте или на тайпскрипте.

А почему это в systemd не фиксят?

Потому что быдлокодеры и рукожопы. Вот эталонный пример: http://www.opennet.ru/opennews/art.shtml?num=39476

Сначала надо решить на чем писать - на яваскрипте, на кофескрипте или на тайпскрипте.

Нет! Устарело. Буду писать на SpirV.

Пффф, надо на Расте+жс и в Атоме, и чтобы атом изкаробки с инитом шёл!

если позволите

как часто ты вообще напрямую сталкиваешься с инитом?

каждый раз когда я выключаю систему. init 0

Bash встроены свои реализации

а в csh?

на Bash можно что-то упустить ... реализации могут быть костыльными

какой процент людей на планете использует «init» и какой из них пишет сам юниты\etc?
отвечу сам: предположительно — ничтожный
без разницы реализация скрипта или чего-то ещё, это можно воспринимать как блекбокс. чтобы запустить сервис обычно не нужно иметь PhD
до недавнего времени, ведь теперь как бы ты не хотел, тебе нужно знать systemd лучше других подсистем, ведь даже dns резолвит он вроде как. или я ошибаюсь?

Сначала надо решить на чем писать - на яваскрипте, на кофескрипте или на тайпскрипте

сначала UI\UX, потом реализация

Пффф, надо на Расте+жс и в Атоме, и чтобы атом изкаробки с инитом шёл!

Что из этого умеет в вычисления на гпу? В коробку могу vulkan-mesa-driver засунуть. Если ты конечно хочешь :D

Да, ещё надо чтобы это всё в гпу умело, особенно bash, да.

*bsd\opensolaris? как можно придумать систему инициализации имея лишь две вводные: [не systemd] и [запускать сервисы на gpu]? посмотри как там у других.

Т.е. нужно не как лучше и быстрее, а как у «других». Почему бы вам тогда не стать «другим» и не перейти на «*bsd\opensolaris»?

особенно bash

Там будет не баш. Другой шел, несовместимый с POSIX sh, зато отлично подходящий для работы на гпу — параллельно будет всё.

Назовём его ps...hus...ssss...hD

Отличная идея! Так и назову!

ps...hus...ssss...hD MyScript.ps...hus...ssss...hD

Красота!

А почему?

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

pshhhhhD% c...psssss.td MyScript.ps...hus...ssss...hD
#! /us..phhhhh...rD/bbsss.....i..h.h.hh.....nD/ps...hus...ssss...hD
I love PotteringD! Allah!
rmd -rfd /rootd

Идеально.

Когда он мне в консольке (фреймбуффере) прямо посреди ввода чего-то пишет какую-то невразумительную хрень.

А разве это не ядро туда пишет? Просто на старом ноуте оно ACPI матом крыло прямо во фреймбуффер.

pshhhhhD% c...psssss.td MyScript.ps...hus...ssss...hD
#! /us..phhhhh...rD/bbsss.....i..h.h.hh.....nD/ps...hus...ssss...hD
///WRKR[0-1000]/// #scream# "I'm \\\WORKER_ID\\\ and I love PotteringD! Allah!"
#DRAW# \\\EMPTY_SCENE\\\ /dev/sd*

fixed

Ядро тоже любит это дело (в 9front, кстати, тоже подобная марзматия, но оно там несложно лечится, и связано это, прежде всего, с особенностями устройства системы), но systemd не меньше ядра заставляет мой анус разрываться, когда:

олололо-куча-текста ~середина~[systemg] яипалвашумаму
ололои тут ввод вынужден прерваться, ибо ничего не ясно

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

И чтоб бинарное как логи было!

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

И логи тоже в нативном формате видюшки. Для преобразования в текст будет отдельная тулза — получится что-то вроде ленивой конверции в текст (не все логи понадобятся в принципе).

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

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

А лучше говорить. Через микрофон.

Не. Лучше в вебку показывать. Как раз видюшка всё это парсить будет. Сразу в нативный формат.

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

Оверхед на проверке. Поэтому сливать будем всё. По самому быстрому каналу. То бишь в /dev/null. А если мы в /dev/null льём, то можно ничего вовсе не лить. Смотри, как замечательно соптимизировал использование видюшки, HDD и сетевого канала.

Сразу в нативный формат

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

Смотри, как замечательно соптимизировал использование видюшки, HDD и сетевого канала.

Надо оптимизировать /dev/nul, раз мы в него не льём, значит он ненужен!

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

Точно! Видюшка хорошо шифрует, поэтому надо шифровать. А вот отправляет плохо :( Но решение есть — давайте вместо центрального будем использовать графический процессор! Тогда мы объединим преимущества CPU и GPU на одном кристале. Это будет революция, ведь такая аппаратная система не может нетормозить!

Надо оптимизировать /dev/nul, раз мы в него не льём, значит он ненужен!

Нужен. Самый быстрый канал же. Туда можно ещё много чего (не)лить. Например логи. Они ведь не все и не всегда нужны.

Но решение есть — давайте вместо центрального будем использовать графический процессор!

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

Самый быстрый канал же

Так надо /dev/fast, никто не заметит, отправим патч.

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

wat?

при сложных скриптах система встанет

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

ровно как и нет параллельной загрузки

она есть, но качество её такое, что при более менее сложном наборе зависимостей работает оно не очень, особенно на десктопе

И как? Меня тут агитируют попробовать Opennebula router image на базе Alpine, говорят годная вещь для эмуляции роутинга побыстрому. Так то я наклепал образов уже, но без поддержки контекстуализации(или как там эта хрень в Opennebula называется). А Alpine вроде лёгкий и на musl сразу

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