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

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

Дистрострои же не поспевают, причём уже весьма значительное время. Роллинг-дистрибутивы держатся актуальных апстримных версий, клепая грязные сценарии сборки и жертвуя интеграционным тестированием. Стабильные же дистрибутивы банально не успевают во всём разбираться и всё пакетировать, а потому добрую половину софта не поставляют. А чтобы то, что поставляется, реально собиралось — перед релизами устраивают mass rebuild относительно текущего состояния репозитория.

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

Когда-то очень давно, ещё в десятых, я занимался этим вопросом[1] (осторожно, суровый легаси-код на ocaml4), но к сожалению нам не хватило финансирования, так что проект в глубокой стагнации.

[1] https://github.com/freehck/bf

Любой.

Даже более того: до недавнего времени, glibc не собиралась с помощью clang. Это значило, что даже имея llvm, вы не сможете получить работающий gcc(по крайней мере без патчей). Ну а сборка самого gcc тоже не бывает простой - вроде как 2.X верисю можно собрать без gcc, а далее вам придётся точно так же собирать одну версию gcc за другой.

Для с++

> Каких "элементарных" алгоримтов вам не хватает, что вы не можете их найти?

Динамические массивы, списки, буфферы. Ну просто как пример.
Про klib и glib я знаю. Но шаг в сторону - или пишешь сам, или welcome to type punning.

>>  Нет стандартизированных сборочных систем, есть только Makefile.
>1. Это хорошо.

Возможно. Но почему для сборки мне надо тащить что-то из интернета, а не взять то, что есть в дистре, а потом трахаться дополнительно с наладкой. Я что-то не понимаю в жизни. Ну да, всё можно, всё делаю, но блин.

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

Ну, я поздно взялся за go, дженерики там были. А остальное заменяется кривым, но any.
Я про то, что в stdlib с++, rust, go - есть дофига разного, для C - сделай сам.

Который вечно отстает, в котором вечно нет нужных версий либ, а мейнтейнеры суют свои шаловливые руки в код.

> Храни код зависимостей в проекте в директории deps и сопровождый нужную систему сборки.

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

[dependencies]
regex-lite   = { path = "../deps/regex/regex-lite" }
regex-syntax = { path = "../deps/regex/regex-syntax" }

И все работает. Все просто работает.

Тем более, есши Вы такие термины знаете, то должны знать, что бардак это плохо.

> логи грепать

Через консоль? Это только красноглазия ради, а если за деньги, то инструментами сохраняющими время, а то и не требующими копаться лично.

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

>>решал эту задачу страшным однострочником

Именно в решении задач в консоли,  на огромном мощном десктопе, и проблема в эргономике.

Так, в консоли, уместно на легких встраиваемых контроллерах, но там и лог интересен только свежий.

Если задачу, как у Вас решать строго в консоли, то systemd лучше, его и хотели сделать что бы было лучше, но не доделали.

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

Я мало интересуюсь, что там на серверах.
Но на десктопе, хоть он и для разработки и хобби, хотелось бы обойтись без консоли, в смысле, что только через консоль.
Мир не из одних серверов состоит. У меня есть Планшет с Linux, больше для баловства и экспериментов, но на нём консоль нафиг не сдалась, от слова совсем. С  ТВ приствками аналогично, там из управления в основном мышь и голосовые команды, а не клавиатура.

>>почти в каждом DE есть свой гуй

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

> логи обычно перенаправляют в условный Loki

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

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

Скорей бы увидеть SystemdOS и как оно раздавит б-гомерзкий линекс.

Все кроме Alpine - какие-то васяноподелия, которым пользуются полтора землекопа.

В любом случае он неизбежно будет отличаться от OpenRC в Gentoo. А значит разбираться с ним нужно будет отдельно для каждого дистрибутива. Я не говорю, что свобода - это плохо. Но с точки зрения администрирования в enterprise - это зло. Поэтому корпорации, как основной источник финансирования Linux, продвигают везде systemd. И любительский кошелёк, как не соразмерный по величине с корпоративным, уже никак не может повлиять на продвижение альтернатив к systemd.

Если же попытаться ограничить OpenRC стандартами, чтобы для администратора он стал одинаковым в разных дистрибутивах, то он невольно превратится в такую же сложную конструкцию, как systemd.

Зачем вас маргиналить, если вы и сами отлично справляетесь?

У линксойдов 4% десктопа. Сколько процентов линуксойдов пользуются гентой? 2%? 3%?
Если же говорить про сервера, то и тут у генты не все так хорошо.
В проде ее можно встретить раз в 100 лет, но и на подкроватных локалхостах не так уж часто.

> такой же тупой прием как и называть то что тебе не нравится теорией заговора

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

Ага, с консолью и лимитами пользователя, который сделал su/sudo.

>>свойствами пользователя

Читайте маны, полезно. Начните с man 2 fork

> Ты с вантуза пишешь?

С сертифицированного Unix

man 7 daemon

Всё, что там описано, не нужно сервису управляемому обычным классическим init. А нужно только для того, чтобы пользователь мог сделать /etc/init.d/someservice restart.

Демонизация не нужна ни в runit, ни в openrc, ни в upstart, ни в systemd. Даже процессу, который запущен из inittab не нужна. Демонизация отрывает управление процессом и это костыль для работы скриптов sysv/at&t

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