Pull to refresh

Comments 31

Хотелось бы поделиться своим взглядом на стандарт.
Так где свой взгляд на стандарт?
Статья выглядит, как перепечатка первой лекции по Linux, с очепятками и пропущенными запятыми.

Забыли про существование пакетных менеджеров. /usr/bin и /bin — в их ведомстве, /usr/local — целиком на откупе локальной машины и всякой порнографии в стиле make install.


Деление на /bin и /usr/bin давно забыло и является артефактом прошлого, в одной категории с шаббатом и крестными ходами. Ничем, кроме религиозных предпочтений и исторических причин, их объяснить нельзя.

Ошибаетесь. Как в пакете расположат, так бинарники и развернутся.
Хоть в /usr/local/bin, хоть в /opt/mssql-tools/bin, хоть в /usr/local/games
только вот QA дистрибутива такое не допустит. почитайте стандарты уже.

Если вы положите в deb что-то в /usr/local/bin, то, технически, это работать будет, но будет нарушать debian policy: https://www.debian.org/doc/debian-policy/ch-opersys.html


9.1.2. Site-specific programs


As mandated by the FHS, packages must not place any files in /usr/local, either by putting them in the file system archive to be unpacked by dpkg or by manipulating them in their maintainer scripts.

Так точно. Извиняюсь. Погорячился.
У меня там сорцовые бинари лежат, не сразу вспомнил.
UFO just landed and posted this here
В том же арче /bin, /sbin и /usr/sbin давным-давно являются симлинками на /usr/bin. /lib64, /lib и /usr/lib64 тоже ссылаются на /usr/lib. Хотя логичнее было бы избавиться от самого /usr, делая его симлинком на корень.
Хотя логичнее было бы избавиться от самого /usr, делая его симлинком на корень.

Если прямо от самого — то нельзя, так как там ещё куча всего вроде /usr/share и той же /usr/local. В корне такого нет.

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

Прочитать man hier (правда не поняв по конца) нынче дорого стоит

Ещё можно использовать $HOME/bin, чтобы на скорую руку поправить отвалившийся косяк вроде LD_LIBRARY_PATH. У меня там лежит файл monodevelop
вот с таким содержимым,
#!/bin/bash

# Fix the "cannot connect to debugger" bug.
# http://superuser.com/questions/669444/monodevelop-cannot-connect-to-debugger#comment1625964_744763
unset KDE_SESSION_VERSION

# Allow remote debugging
export MONODEVELOP_SDB_TEST=1

#exec /usr/bin/monodevelop "$@"
flatpak run --command=monodevelop --file-forwarding com.xamarin.MonoDevelop @@ "$@" @@
который прозрачно запускается вместо /usr/bin/monodevelop. Только для этого путь $HOME/bin должен быть прописан в самом начале $PATH (export PATH="$HOME/bin:$PATH"). В дебианах вроде по умолчанию так.
Один из способов защиты системы от шаловливых рук юзеров — это запрет запуска этих утилит кому-попало, утсановкой атрибута x.

Даже если забыть про устаревание /sbin и прочего, то защита не очень оказывается — можно файл к себе скопировать. А если не получится — то на дискетке принести / из исходников собрать.

По-хорошему можно все доступные "простым смертным" пути монтировать с noexec, правда это существенно ограничивает возможности использования системы. Тем более почти весь /sbin и так не работает без нулевого UID.
К тому же 750 на утилитах в /sbin (так делают, например,
OpenSUSE) ломает умные дополнения умных шеллов, что весьма неудобно.

почти весь /sbin и так не работает без нулевого UID

Это очень важное "почти". В /sbin есть команды, которым достаточно, чтобы юзер был в группе operator (что в случае обычного компьютера выполянется для всех "простых смертных").

Исторически вариантов сильно больше. На солярках долго /usr/xpg4/bin отличался от /usr/bin — те, кому нужно было соответствие стандартам, а не локальным тараканам, ставили /usr/xpg4/bin вперёд.

Сейчас есть /usr/games, отдельно. На FreeBSD был /stand, теперь /rescue.

Разница между /bin и /usr/bin в одном «фото»:
$ ls -l /
lrwxrwxrwx   1 root root     7 Apr 25 09:57 bin -> usr/bin
lrwxrwxrwx   1 root root     7 Apr 25 09:57 lib -> usr/lib
lrwxrwxrwx   1 root root     9 Apr 25 09:57 lib32 -> usr/lib32
lrwxrwxrwx   1 root root     9 Apr 25 09:57 lib64 -> usr/lib64
lrwxrwxrwx   1 root root    10 Apr 25 09:57 libx32 -> usr/libx32
lrwxrwxrwx   1 root root     8 Apr 25 09:57 sbin -> usr/sbin

Debian Buster 10.0
Не наблюдаю ничего подобного:

cat /etc/os-release
PRETTY_NAME=«Debian GNU/Linux 10 (buster)»
NAME=«Debian GNU/Linux»
VERSION_ID=«10»
VERSION=«10 (buster)»
VERSION_CODENAME=buster
ID=debian
HOME_URL=«www.debian.org»
SUPPORT_URL=«www.debian.org/support»
BUG_REPORT_URL=«bugs.debian.org»
netadm@lb01:~$ ls -l /
total 113
drwxr-xr-x 2 root root 4096 июл 30 04:55 bin
drwxr-xr-x 20 root root 4096 июл 30 04:56 lib
drwxr-xr-x 2 root root 4096 июл 30 04:19 lib64
drwxr-xr-x 2 root root 12288 июл 30 04:55 sbin

Скорее всего, ваша система обновлена со stretch. При обновлении с предыдущего релиза /usr merge не происходит


When upgrading to buster, systems are left as they are, although the usrmerge package exists to do the conversion if desired.
К слову католог /usr означает unified system resources — что и обуславливает всё что в ней.
На самом деле все исполняемые файлы должны быть доступны из /bin, а $PATH — архаизм. Так сделано, например, в Plan 9 — исполняемые файлы из разных директорий (например /386 + /usr/usrname/bin) динамически смонтированы в /bin при помощи bind

Вместо "должны" нужно писать "могут быть". Системе все равно, в одной директории все файлы или в разных. Человеку — удобнее, когда в разных.

И это статья для хабра? Грёбаный стыд.

Тем не менее статья набрала +9 лайков, а автор — кармы +3.
Вот это — гребёный стыд.
С кем поведешься — от того и забеременеешь (tm)
Хотелось бы поделиться своим взглядом

Очень хорошо что у тебя есть свой взгляд, но в оригинальной статье (и в других источниках, если поискать) четко сказано почему появился /usr и почему в современном мире он не нужен.

Вообще ментейнеры любого дистрибутива могут без вреда для пользователей убрать
дублирующие каталоги в /usr, но то ли они привыкли следовать традициям, то ли лень все пересобирать.
/bin, /sbin убрать в /usr?
И получить проблему при ошибке маунта /usr? Так себе идея на мой взгляд.
Есть такая проблема, у нас регулярно вылазила на FreeBSD. Там стиль по умолчанию как раз предполагал (а может, и сейчас) отделение /usr в отдельный раздел, и если он не монтировался (например, из-за переименований wd0/ad0, ad4/ata1, etc.), то надо было дорабатывать руками.

Лечили — или терпели проблемы при перемещении (это обычно таки один раз) и правили fstab вручную, или объединяли /usr с / (но тогда надо было подумать, как выносить /usr/local).

Тогда я тосковал по наличию LVM у некоторых соседей.

На Linux сейчас такие проблемы тоже возможны, но лечатся скорее другими средствами: busybox с набором штатных утилит в initrd, UUIDʼы в fstab…
Sign up to leave a comment.

Articles