Что не так с systemd?

Да, всё верно. Это и подобное этому как рак расползающийся по системе и есть беда. Но пока что получается не касаться этой фигни. Пока что.

UNIX-Way в исполнении Поттеринга во всей красе.

Да не в пути суть ИМХО, а в навязывании и пропихивании. Было бы это всё просто софтом хочешь накатывай хочешь нет, где то по умолчанию, не нравится просто сносишь и всё отношение было бы иным и проблем вообще бы не было. Да даже если бы было безальтернативное пропихивание (а оно и случилось) всё ладно, часто нас ставят просто перед фактом это не ново, для меня последней каплей стала лож и переобувание тапок на ходу. Может сейчас то я и пользуюсь всем этим (не всем но некоторым) явно и сам и даже порой удобно, но осадочек остался и он никогда и никуда не денется.

Если на это внимания не обращать то свыкнется и слюбится в конце концов это просто ПО. Оно не виновато. А вот те прошмандовки которые за ним стоят ещё как виноваты, не в том что они написали этот софт, это свободный софт, спасибо им за это. А в том что звездоболы и манипуляторы.

В любом случае парится по этому поводу не надо, есть альтернативы и форки дистрибутивов. Выбор есть. Ещё 150 раз всё поменяется.

Чистый и фанатичный unix way это тоже путь в никуда. Это то к чему надо всегда стремится, но никогда не достигать. Держать себя в узде и при этом развиваться.

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

Угу. Только вывод зависит не только от содержимого ~/temp, но и содержимого ~/. Попробуй создать ~/1 и ~/2 и повторить цикл for.

Попробовал. Внезапно название каталога превращается в регэксп. Шелл такой шелл.

Может будет как с PulseAudio? Пропихивали-пропихивали, но тут ВНЕЗАПНО кто-то сделал PipeWire. И оригинальная поттеринговская реализация сервера сразу стала ненужна.

Будет как будет. Это не вопрос гадания. Начнёт приносить больше проблем чем пользы или появится что-то лучшее в том или ином или всех аспектах так сразу и платочком помашем. И те кто сейчас высмеивает дидов писавших инит скрипты на баше, будут плакать по своим ini файлам и о том что всё по другому.

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

ВНЕЗАПНО

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

А в zsh всё будет в этом случае нормально, но он только от части проблем спасает.

Вот и поговорили.

П.С. С Новым Счастьем!

Приятно иметь дело с образованным человеком. :-)

Еще раз перечитал: https://www.opennet.ru/opennews/art.shtml?num=34042 и поржал над systemD и ее невольными пользователями.

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

нормальный бут-менеджер вместо убогого grub2, в котором даже конфиг генерируется а не руками пишется

Что с GRUB2 то не так? Никто тебя не обязывает генерить конфиг, можно самому написать. Хотя чтобы заставить работать темы на самописном конфиге придётся покрасноглазить. Вон на арчевики есть руководство по написанию конфигов граба вручную.

не нравится просто сносишь

Но ведь так и есть. Тебе никто не запрещает снести systemd и впилить хоть s6 или как он там.

А почему никто hal не вспоминает? Тоже пихали-пихали, а потом сделали udev и выкинули hal на мороз.

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

cat /etc/init.d/atop:

 stop)
        # Check if atop runs
        #
        if [ -e $PIDFILE ] && ps -p `cat $PIDFILE` | grep 'atop$' > /dev/null
        then
                kill -USR2 `cat $PIDFILE`       # final sample and terminate

                CNT=0

                while ps -p `cat $PIDFILE` > /dev/null
                do
                        let CNT+=1

                        if [ $CNT -gt 5 ]
                        then
                                break;
                        fi

                        sleep 1
                done

                rm $PIDFILE
        fi
        rm /run/lock/atop
        ;;

Неужели вместо `cat $PIDFILE` нельзя было сделать переменную, вместо многократного использования этого кода?

И в целом этот код ведь очевидно явно типовой, неужели было не сделать библиотеку типовых функций для sysv? Но при этом скрипты все равно прекрасны, если их правильно писать. Проблема IMHO вовсе не в использовании скриптов, а в ужасном стиле их написания для sysv.

Теперь посмотрим современные скрипты в OpenRC:

root@kube:~# cat /etc/init.d/k0scontroller

#!/sbin/openrc-run
supervisor=supervise-daemon
name="k0s controller"
description="k0s - Zero Friction Kubernetes"
command=/usr/local/bin/k0s
command_args="'controller' '--single=true' "
name=$(basename $(readlink -f $command))
supervise_daemon_args="--stdout /var/log/${name}.log --stderr /var/log/${name}.err"

: "${rc_ulimit=-n 1048576 -u unlimited}"
depend() { 
        need net 
        use dns 
        after firewall
}

IMHO уже получше?

А теперь сравни с современным скриптом /etc/init.d/networking для sysv

stop)
        check_network_file_systems
        check_network_swap

        log_action_begin_msg "Deconfiguring network interfaces"
        if ifdown -a --exclude=lo $verbose; then
            log_action_end_msg $?
        else
            log_action_end_msg $?
        fi
        ;;

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

ps waux | grep programname | grep -v grep | awk '{print $2}'

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

PS: Ещё бы всех заставить xdg-пути соблюдать, вот красота будет.

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

Ну без этого все же не обойтись, а то они не были бы разными дистрами. А вот иногда разные названия юнитов для одного и того-же это очень плохо. Где-то NetworkManager.service, а где-то network-manager.service. И вспоминай. Хотя бы автодополнение качественно по юнитам работало, но почему-то оно всегда половину не подсказывает.

Вон на арчевики есть руководство по написанию конфигов граба вручную.

Дисциплина спец.олимпиады по программированию конфигов загрузчика. Где ещё такое увидишь.

Выключать компьютер то хоть удается без пердолинга?

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

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

В слаке уже elogind, сегодня специально проверял. Благодаря этому DE работают нормально. Так по частям потихоньку всю системду и затащат.

https://www.reddit.com/r/Gentoo/comments/opy7ai/why_elogind/

So logind is part of systemd. Elogind is a project (i believe maintained by gentoo) that seeks to be a logind repalcement for those using non-systemd setups (i.e. openrc, runit, etc). It seeks to provide the same capabilities of logind without requiring anything from systemd.

Tldr; elogind is not part of systemd; it is an alternative to logind for systems without systemd.

elogind - это заслонка от systemD, чтобы не тащить в систему весь systemD.