coreutils 8.31, куда делась команда su?

coreutils у меня на месте (арч):

pavlick ~ $ pacman -Qs coreutils
local/coreutils 8.32-1
    The basic file, shell and text manipulation utilities of the GNU operating system
pavlick ~ $ su
Пароль:

SLES 11

Мощно. И зачем?

Во-вторых, почему всё устанавливается в /usr/bin вместо /bin?

Уже много лет так. С разморозкой.

Во-первых, куда делось su в новом coreutils?

https://www.archlinux.org/packages/core/x86_64/util-linux/

Во-первых, куда делось su в новом coreutils?

Его там никогда и не было, либо util-linux, либо login

Во-вторых, почему всё устанавливается в /usr/bin вместо /bin?

Потому что с 2012го так принято.

> Его там никогда и не было

Вот список файлов в пакете coreutils 8.12, который у меня сейчас установлен. /bin/su там есть.

> Потому что с 2012го так принято.

Очень глупо. Что насчёт /usr на отдельном разделе?

Была. Просто не ставилась еще с допотопных времён.

> Мощно. И зачем?

GNOME2. MATE не предлагать.

> https://www.archlinux.org/packages/core/x86_64/util-linux/

То есть, мне ещё и util-linux обновлять. Замечательно.

Очень глупо. Что насчёт /usr на отдельном разделе?

Как насчёт пояснить, зачем это нужно?

А почему бы нет?

Значит, я обновлюсь до coreutils 8.17. Нужный мне readlink там наверное есть.

Спасибо.

То есть, мне ещё и util-linux обновлять. Замечательно.

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

Ты зачем в рабочую систему это всё накатываешь? Ставь новый coreutils в отдельный подкаталог и добавляй его в PATH.

Или приложение вызывает их по абсолютному пути?

Что насчёт /usr на отдельном разделе?

И в чём проблема usr на отдельном разделе?

Судя по скрипту запуска steam, не по абсолютному.

А почему бы нет?

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

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

Допустим, /usr не смонтировался. Набор базовых утилит всё равно должен работать, потому что он в /bin.

Допустим, / не смонтировался, откуда у тебя в /bin возьмутся базовые утилиты?

GNOME2. MATE не предлагать.

Ну хз, у меня отдельные куски GNOME2 под Арчем прекрасно собираются.

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

Было бы неплохо, кстати. У меня на Gentoo были проблемы с GNOME 2, когда я обновил Glib с 2.32 до 2.34. Одно ядро процессора всегда было занято на 100%. Откат обратно до 2.32 решил проблему.

Как ты думаешь, почему вообще существует /usr?

Из initramfs, вестимо.

А что будешь делать, когда поддержка кончится?

Ну вот оттуда же возьмутся и /usr/bin, если /usr не смонтируется. Разницы ровно 0.

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

Потому что у Томпсона и Ричи была ЭВМ с двумя жесткими дисками. На одном они размещали ОС, а на другом пользовательские данные.

Вот этот второй диск и монтировался в /usr.

Набор базовых утилит всё равно должен работать, потому что он в /bin.

Я тут уже писал когда-то, почему это идиотизм.

На, почитай.

Набор базовых утилит должен лежать в initramfs. А если у тебя есть initramfs, то нет абсолютно никаких проблем положить туда абсолютно любые утилиты вне зависимости от префикса.

Ну и кстати как только у тебя появляется initramfs, то выносить /usr на отдельный раздел резко перестаёт быть нужно, потому что ты точно так же можешь вынести /.

Есть ровно одно исключение — R/O образ базовой системы, монтирующийся по сети или из сквоша. Тогда в /usr у тебя жирный образ базовой системы, а в / лежит крохотный локальный стейт. Но это не прижилось, проще overlayfs сделать.

Так в чём вопрос тогда?

Спроси ещё зачем использовать зубную щётку для чистки зубов.

Для меня поддержка кончилась ещё в июне 2019 года. Истёк ключ. А так вообще LTSS-поддержка до 2022 года. Что буду делать потом? Не знаю. Может, установлю обитель зла - Fedora. Или попробую BSD, лол.

1. Ты по-прежнему хранишь «пользовательские данные» в /usr? (А не в /home)
2. У тебя по-прежнему проблема, что ОС не влезает на 3-мегабайтный диск, требующий отдельной тумбы для раскручивания?

А openSuse чем не нравится?

+1

Всё верно.

Наличием Systemd. Посмотрим, что будет в 2022 году интересного без ненужно-прог и телеметрии.

Наличием Systemd.

Сам Федору собирается ставить, лол…

Ну тогда Devuan, Artix или Void.

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

Всяко лучше чем федора.

все идет к этому:
systemd(pid 0)
|
-systemd-kernel(pid 1)

гЫы

gcc -std=gnu99  -I. -I../lib  -I../lib    -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -MT su.o -MD -MP -MF .deps/su.Tpo -c -o su.o su.c
su.o: In function `cleanup_pam':
su.c:(.text+0x122): undefined reference to `pam_setcred'
su.c:(.text+0x142): undefined reference to `pam_close_session'
su.o: In function `modify_environment':
su.c:(.text+0x212): undefined reference to `pam_getenvlist'
su.o: In function `main':
su.c:(.text+0xd67): undefined reference to `pam_start'
su.c:(.text+0xdbf): undefined reference to `pam_set_item'
su.c:(.text+0xdf7): undefined reference to `pam_set_item'
su.c:(.text+0xe13): undefined reference to `pam_authenticate'
su.c:(.text+0xe2f): undefined reference to `pam_acct_mgmt'
su.c:(.text+0xeee): undefined reference to `pam_setcred'
su.c:(.text+0xf1c): undefined reference to `pam_open_session'
su.c:(.text+0x1062): undefined reference to `pam_end'
su.c:(.text+0x10db): undefined reference to `pam_end'
su.c:(.text+0x10f6): undefined reference to `pam_strerror'
su.c:(.text+0x11b0): undefined reference to `pam_strerror'
su.c:(.text+0x1467): undefined reference to `pam_chauthtok'
su.o: In function `cleanup_pam':
su.c:(.text+0x131): undefined reference to `pam_end'
su.o:(.data+0x0): undefined reference to `misc_conv'
collect2: ld returned 1 exit status
make[3]: *** [su] Error 1
make[3]: *** Waiting for unfinished jobs....

Разумеется, pam-devel установлен.

Побуду без realpath значит.

А чем тебе Mate не угодила?

Например, я не могу скомпилировать Firefox с поддержкой gconf, потому что в MATE - dconf. Не могу нажать Alt-F2 и быстро ввести название утилиты из состава DE, потому что я не знаю, как они называются. Скажем, caja и pluma я помню, а аналог какого-нибудь file-roller, gucharmap или baobab я сходу не вспомню. Наконец, там GTK3, со всеми вытекающими последствиями. Хоть я и не любитель кастомизировать темы. Ещё мне нравится тут штатный Compiz. А в MATE он есть? Я, конечно, не против compton, но Compiz отличный. Делать окна полупрозрачными Alt+Scroll, или экранная лупа.

realpath было ещё 350 тыщ лет назад. в debian lenny вон точно есть

Моя операционка вышла в одно и то же время с Debian Lenny, даже на одной и той же версии ядра - 2.6.27.

Изначально там были coreutils 6.12, но впоследствие с сервис-паками обновили до 8.12.

Может быть, realpath не было в изначальном 6.12, а когда coreutils впоследствие обновляли, эту утилиту не стали туда добавлять? Что-то вроде энтерпрайз, стабильность... Или realpath раньше была не в coreutils, а в каком-то другом наборе утилит? По аналогии с su, которая переехала в util-linux из всё тех же coreutils.

Короче вот что со Стимом. В steam.sh утилита realpath вызывается при создании pins. Если разрешить Steam Runtime, стим при запуске сканирует системные библиотеки, находит устаревние версии, и заменяет их своими, более новыми. Создаёт директорию pinned_libs_64 и туда кладёт симлинки на эти библиотеки, и указывает LD_LIBRARY_PATH. Таким образом, Стим работает даже в самых старых системах.

А у меня тут не удаётся создать pins, соответственно Steam Runtime не работает, и сам Steam не работает без какой-то новой библиотеки (не пишет, какой именно). Если же я копирую realpath из другого дистра, Steam успешно создаёт pins, запускается и работает.

Очень глупо. Что насчёт /usr на отдельном разделе?

Поттеринг ломает /usr

уже можно было бы или найти realpath, или собрать realpath, или тупо сделать враппер на realpath. видимо, тебе это не нужно.

Скопировал из другой системы, работает. Я создал тему,чтобы правильно решить проблему, обновив системный coreutils до версии, в которой есть эта утилита.