В связи с возможным объединением каталогов /bin и /sbin в один хотелось бы узнать почему кто-то против этого? Какие минусы вы в этом видите?

+ открыть спойлер

Vascom пишет:

В связи с возможным объединением каталогов /bin и /sbin в один хотелось бы узнать почему кто-то против этого? Какие минусы вы в этом видите?

для начала, хотелось-бы выслушать ваши доводы ЗА такое объединение.

Леннарт Поттеринг в списке рассылки разработчиков предоставляет список преимуществ такого подхода:

ds: главный лемминг-проводник ведёт остальных леммингов в пропасть.

разделение на /bin и /sbin приводит к усложнению работы разработчиков, которые зачастую ошибаются с выбором каталога, либо бездумно помещают файлы в /usr/bin;

Если у нас настолько тупорылые разработчики, то почему-бы не свалить всю помойку на диск C: ?

первоначальное назначение каталога /sbin (размещение статически собранных файлов, на что указывает буква «s») давно неактуально;

man hier

/sbin  Like  /bin,  this  directory  holds  commands needed to boot the system, but
              which are usually not executed by normal users.

выделенное слово хорошо видно?

разделение на /bin и /sbin не имеет отношения к безопасности (это был бы глупый принцип «security by obscurity»);

Леннарт -- лемминг.

Если вы тоже лемминг, дальше не читайте. Если вы умеете думать головой, прочтите:

$PATH имеет непосредственное отношение к безопасности. Однако, вовсе НЕ потому, что он "что-то скрывает". Это наглое ЛПП. На самом деле, $PATH уменьшает риск подмены, т.е. если юзер набрал ls, то он _ожидает_, что выполнится /bin/ls, а не как в маздае $PWD/ls. Разница существенная, ибо враг в принципе обычно имеет доступ к $PWD (это текущий каталог, и враг может например подсунуть архив, в котором лежит ЕГО ls), и враг може обмануть пользователя, попросив его выполнить его команду, которая на самом деле -- вредоносный код злоумышленника.

Существует класс потенциально опасных утилит, которыми можно загубить ВСЁ, и которые обычно всё равно не нужны пользователю. В качестве примера можно привести /sbin/mke2fs, которая в GNU/Linux эквивалентна FORMAT в MS-DOS-подобных ОС.

Если юзеру нужны такие программы (что бывает крайне редко), то юзеру следует набрать полный путь, дабы быть уверенным в том, что опасная команда сделает именно то, что он хочет. Например:

$ /sbin/fdisk -l

Диск /dev/sda: 8035 МБ, 8035237888 байт
162 heads, 28 sectors/track, 3459 cylinders, всего 15693824 секторов
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x4efc010b

Устр-во Загр     Начало       Конец       Блоки   Id  Система
/dev/sda1   *          28       99791       49882   83  Linux
/dev/sda2           99792    15693823     7797016   83  Linux

Безусловно Леннарт об этом знает, и сознательно вводит в заблуждение остальных леммингов.

разделение на /bin и /sbin имеет значение только для переменной $PATH, однако усложнять доступ пользователей к некоторым инструментам - плохая затея; к тому же для этого есть более подходящие каталоги;

см. выше. Ну и демагогия детектед: НЕ ТОЛЬКО для $PATH это важно. Системные компоненты вообще полезно держать в отдельном ящике. Например у меня дома ножовка/молоток/паяльник лежат отдельно. Дети знают где (я от них ничего не скрываю), и знают, что лазать туда НЕЛЬЗЯ. И совсем не потому, что у них это не получается. Получится, если надо будет, а папы нет поблизости. Ну а обычные инструменты лежат в других ящиках, доступных без особых разрешений.

разделение на /bin и /sbin в любом случае бессмысленно уже пару версий Fedora, поскольку оба каталога включены в переменную $PATH для всех пользователей;

федоррапроблемы.

разделение приводит к усложнению, а мы должны стремиться к упрощению;

ящик со специальными инструментами -- тоже усложнение. Да и вообще -- идеал простоты: помойка. Мы должны стремится к помойке?

различные дистрибутивы размещают некоторые бинарные файлы в различных каталогах, что приводит к проблемам с переносимостью скриптов;

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

разделение на /bin и /usr/bin в основном было сделано для этапа ранней загрузки системы - минимальный набор загрузочных файлов находится в /. Но это давно не работает, и соответствующая опция убрана из инсталлятора anaconda. Более того, размещение /usr на отдельной файловой системе вызывает проблемы при загрузе посредством systemd;

т.е. тут Леннарт сам признался, что он неосилятор, и не осилил сделать systemd, который работает везде? Простите, это система для systemd, или всё же наоборот?

разделение на минимальную систему в / и полную в /usr также стало бессмысленно благодаря initrd, а содержание двух уровней «минимальной загрузочной системы» - дурацкая затея;

Ложь. Рассчитана на тех леммингов, кто не понимает магии initrd.

существенно упростится установка «read-only» системы: так, libc и другие системные библиотеки будут доступны только на чтение, а /etc - на чтение и запись;

Ещё одна ложь. Чем /sbin/ тут мешает? Причём тут вообще это?

снятие снапшотов станет действительно атомарной операцией. В настоящее время btrfs требует 5 снимков - /lib, /lib64, /bin, /sbin и /usr вместо одного, что неудобно и может приводить к состояниям гонки;

ложь. Если свалить всё в одну кучу, то это ничего не изменит. Скорее наоборот. Проще сделать 5 непротиворечивых снимков, чем одну групповую фотографию. Это любой фотограф знает. На любой групповой фотке всегда кто-нибудь получится с закрытыми глазами (моргает), или просто с рожей, как у олигофрена.

существенно упростятся сетевая и контейнерная установки;

ложь. Просто ещё одна ложь.

сборочные скрипты упростятся: в частности, autoconf не знает о разделении на / и /usr, и для правильной работы с ними приходится прилагать специальные усилия;

autoconf И НЕ ДОЛЖЕН ЭТОГО ЗНАТЬ, дурья твоя бошка! Autoconf ставит ПО не туда, куда хочется Леннарту, а туда, куда хочет АДМИНИСТРАТОР. Если надо -- будет ставить в $HOME, и получится "портабельная программа".

эксперименты уже показали жизнеспособность предложенной схемы и отсутствие серьезных проблем;

В Windows 3.11 тоже не было никаких вирусов.

есть разработчик (Harald Hoyer), готовый выполнить необходимую работу.

это который будет ничего ни делать?

/usr/sh - для пользовательских скриптов (баш, питон, etc).

накропанным пользователем скриптам нечего делать в одном каталоге с бинарниками, управляемыми пакетным менеджером.Сейчас роль такого каталога неофициально исполняет /usr/local/bin, но это уродство же.

fragment пишет:

накропанным пользователем скриптам нечего делать в одном каталоге с бинарниками, управляемыми пакетным менеджером.Сейчас роль такого каталога неофициально исполняет /usr/local/bin, но это уродство же.

То есть изначально имелось в виду разделение по пользовательский/системный? /home/user/bin с экспортом в PATH в помощь.

Если пользователей хотя бы 50 - будете экспортировать 50 путей?

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

Сейчас роль такого каталога неофициально исполняет /usr/local/bin, но это уродство же.

Почему MS-DOS не является идеальной системой, ведь там никаких ограничений нет, и любой процесс может получить доступ к любым файлам, и даже к любой памяти любого процесса?

Для некоторых узких применений -- является и именно в силу описанных особенностей.

Разделение на /bin и /sbin в PATH ни от чего не защищает.

Обычный пользователь не имеет прав записи в оба эти каталога. Так что подменить злоумышленник всё равно ничего не сможет.

Но он может изменить саму $PATH как угодно. Так что это не аргумент.

fragment пишет:

Если пользователей хотя бы 50 - будете экспортировать 50 путей?

Если сценарий нужен 50 пользователям -- это уже требует решения на уровне системы.

Так зачем же разделять эти каталоги?

fragment, зачем? Почему бы этот скрипт не опакетить и положить аккуратно в /bin?