Исправление beck, (текущая версия) :
А вы бы как сделали?
Ну вы даёте, коллега. Умнейшие люди со всего мира обсуждали этот вопрос пару десятков лет, а вы хотите, что я тут небрежно с дивана перевернул мир айти одной левой.
Я не вижу смысла плодить все эти /bin, /usr/bin, /sbin, /lib, /usr/lib, /usr/local/lib/bin/sbin, и так далее.
Есть принципиально одно разделение - то, что устанавливается в составе ОС, и то, что отдельно прикручивается пользователем.
Вся ОС в например /os и там уже неважно, что и как внутри, это разработчику виднее. Например: /os/bin - исполняемые файлы /os/lib - библиотеки /os/cfg - конфиги /os/rcs - ресурсы
Что-то типа концепции rpm-ostree из Silverblue или rootvg из AIX.
Всё пользовательское для всех в какой-нибудь /user. /user/app1 /user/app2 /user/app3
Все библиотеки, конфиги, ресурсы приложений - внутри appN конкретного приложения. Никаких общих библиотек, каждое приложение внутри себя имеет всё необходимое для работы.
Приложения, которые пользователь ставит себе лично - в его /home/%username%
Установочный диск ОС должен быть один. В нём ровно то, что разворачивается в /os. Никаких там «мы положили в дистрибутив офисный пакет». «а мы калькулятор, браузер и игру судоку». Ради Бога, но всё это при установке уходит в /user. KDE или GNOME? в /user. Python или Perl? В /user. Все эти тысячи ksh, tcsh, bash, zsh, fish? В /user. В /os можно положить только один shell, и он работает по умолчанию для root.
Да, кстати, я б концепцию root как суперпользователя выкинул.
LSO/RSO (Left/Right Security Officers) - два пользователя (4-eyes), обладающие правом утверждать привилегии. Но не имеющие доступа к конфигурации системы, за исключением параметров безопасности.
Через SO можно определить пользователя с расширенными правами и доступами, например к настройкам сети, заведению пользователей, включению их в группы, установки программ в /user, и т.д. Например Installer может ставить ПО, не может настраивать сетевые параметры, а для этого есть NetworkAdmin.
Можно все эти права дать одному пользователю Admin, но изменение прав и привелегий пользователей и групп, а также изменение прав доступа к файлам и каталогам доступно только SO.
Например Admin добавил пользователя User в группу, но это не включится, пока LSO/RSO оба не утвердят это изменение. Admin поменял права доступа к каталогу /books на 777, но это не включится, пока SO не утвердят изменения.
Исправление beck, :
А вы бы как сделали?
Ну вы даёте, коллега. Умнейшие люди со всего мира обсуждали этот вопрос пару десятков лет, а вы хотите, что я тут небрежно с дивана перевернул мир айти одной левой.
Я не вижу смысла плодить все эти /bin, /usr/bin, /sbin, /lib, /usr/lib, /usr/local/lib/bin/sbin, и так далее.
Есть принципиально одно разделение - то, что устанавливается в составе ОС, и то, что отдельно прикручивается пользователем.
Вся ОС в например /os и там уже неважно, что и как внутри, это разработчику виднее. Например: /os/bin - исполняемые файлы /os/lib - библиотеки /os/cfg - конфиги /os/rcs - ресурсы
Что-то типа концепции rpm-ostree из Silverblue или rootvg из AIX.
Всё пользовательское для всех в какой-нибудь /user. /user/app1 /user/app2 /user/app3
Все библиотеки, конфиги, ресурсы приложений - внутри appN конкретного приложения. Никаких общих библиотек, каждое приложение внутри себя имеет всё необходимое для работы.
Приложения, которые пользователь ставит себе лично - в его /home/%username%
Установочный диск ОС должен быть один. В нём ровно то, что разворачивается в /os. Никаких там «мы положили в дистрибутив офисный пакет». «а мы калькулятор, браузер и игру судоку». Ради Бога, но всё это при установке уходит в /user. KDE или GNOME? в /user. Python или Perl? В /user. Все эти тысячи ksh, tcsh, bash, zsh, fish? В /user. В /os можно положить только один shell, и он работает по умолчанию для root.
Да, кстати, я б концепцию root как суперпользователя выкинул.
LSO/RSO (Left/Right Security Officers) - два пользователя (4-eyes), обладающие правом утверждать привелегии. Но не имеющие доступа к конфигурации системы, за исключением параметров безопасности.
Через SO можно определить пользователя с расширенными правами и доступами, например к настройкам сети, заведению пользователей, включению их в группы, установки программ в /user, и т.д. Например Installer может ставить ПО, не может настраивать сетевые параметры, а для этого есть NetworkAdmin.
Можно все эти права дать одному пользователю Admin, но изменение прав и привелегий пользователей и групп, а также изменение прав доступа к файлам и каталогам доступно только SO.
Например Admin добавил пользователя User в группу, но это не включится, пока LSO/RSO оба не утвердят это изменение. Admin поменял права доступа к каталогу /books на 777, но это не включится, пока SO не утвердят изменения.
Исправление beck, :
А вы бы как сделали?
Ну вы даёте, коллега. Умнейшие люли со всего мира обсуждали этот вопрос пару десятков лет, а вы хотите, что я тут небрежно с дивана перевернул мир айти одной левой.
Я не вижу смысла плодить все эти /bin, /usr/bin, /sbin, /lib, /usr/lib, /usr/local/lib/bin/sbin, и так далее.
Есть принципиально одно разделение - то, что устанавливается в составе ОС, и то, что отдельно прикручивается пользователем.
Вся ОС в например /os и там уже неважно, что и как внутри, это разработчику виднее. Например: /os/bin - исполняемые файлы /os/lib - библиотеки /os/cfg - конфиги /os/rcs - ресурсы
Что-то типа концепции rpm-ostree из Silverblue или rootvg из AIX.
Всё пользовательское для всех в какой-нибудь /user. /user/app1 /user/app2 /user/app3
Все библиотеки, конфиги, ресурсы приложений - внутри appN конкретного приложения. Никаких общих библиотек, каждое приложение внутри себя имеет всё необходимое для работы.
Приложения, которые пользователь ставит себе лично - в его /home/%username%
Установочный диск ОС должен быть один. В нём ровно то, что разворачивается в /os. Никаких там «мы положили в дистрибутив офисный пакет». «а мы калькулятор, браузер и игру судоку». Ради Бога, но всё это при установке уходит в /user. KDE или GNOME? в /user. Python или Perl? В /user. Все эти тысячи ksh, tcsh, bash, zsh, fish? В /user. В /os можно положить только один shell, и он работает по умолчанию для root.
Да, кстати, я б концепцию root как суперпользователя выкинул.
LSO/RSO (Left/Right Security Officers) - два пользователя (4-eyes), обладающие правом утверждать привелегии. Но не имеющие доступа к конфигурации системы, за исключением параметров безопасности.
Через SO можно определить пользователя с расширенными правами и доступами, например к настройкам сети, заведению пользователей, включению их в группы, установки программ в /user, и т.д. Например Installer может ставить ПО, не может настраивать сетевые параметры, а для этого есть NetworkAdmin.
Можно все эти права дать одному пользователю Admin, но изменение прав и привелегий пользователей и групп, а также изменение прав доступа к файлам и каталогам доступно только SO.
Например Admin добавил пользователя User в группу, но это не включится, пока LSO/RSO оба не утвердят это изменение. Admin поменял права доступа к каталогу /books на 777, но это не включится, пока SO не утвердят изменения.
Исходная версия beck, :
А вы бы как сделали?
Ну вы даёте, коллега. Умнейшие люли со всего мира обсуждали этот вопрос пару десятков лет, а вы хотите, что я тут небрежно с дивана перевернул мир айти одной левой.
Я не вижу смысла плодить все эти /bin, /usr/bin, /sbin, /lib, /usr/lib, /usr/local/lib/bin/sbin, и так далее.
Есть принципиально одно разделение - то, что устанавливается в составе ОС, и то, что отдельно прикручивается пользователем.
Вся ОС в например /os и там уже неважно, что и как внутри, это разработчику виднее. Например: /os/bin - исполняемые файлы /os/lib - библиотеки /os/cfg - конфиги /os/rcs - ресурсы
Всё пользовательское для всех в какой-нибудь /user. /user/app1 /user/app2 /user/app3
Все библиотеки, конфиги, ресурсы приложений - внутри appN конкретного приложения. Никаких общих библиотек, каждое приложение внутри себя имеет всё необходимое для работы.
Приложения, которые пользователь ставит себе лично - в его /home/%username%
Установочный диск ОС должен быть один. В нём ровно то, что разворачивается в /os. Никаких там «мы положили в дистрибутив офисный пакет». «а мы калькулятор, браузер и игру судоку». Ради Бога, но всё это при установке уходит в /user. KDE или GNOME? в /user. Python или Perl? В /user. Все эти тысячи ksh, tcsh, bash, zsh, fish? В /user. В /os можно положить только один shell, и он работает по умолчанию для root.
Да, кстати, я б концепцию root как суперпользователя выкинул.
LSO/RSO (Left/Right Security Officers) - два пользователя (4-eyes), обладающие правом утверждать привелегии. Но не имеющие доступа к конфигурации системы, за исключением параметров безопасности.
Через SO можно определить пользователя с расширенными правами и доступами, например к настройкам сети, заведению пользователей, включению их в группы, установки программ в /user, и т.д. Например Installer может ставить ПО, не может настраивать сетевые параметры, а для этого есть NetworkAdmin.
Можно все эти права дать одному пользователю Admin, но изменение прав и привелегий пользователей и групп, а также изменение прав доступа к файлам и каталогам доступно только SO.
Например Admin добавил пользователя User в группу, но это не включится, пока LSO/RSO оба не утвердят это изменение. Admin поменял права доступа к каталогу /books на 777, но это не включится, пока SO не утвердят изменения.