Реально ли избавиться от /usr?

хым.. а я, когда собирал LFS, тоже ломал голову над «архитектурным» вопросом что куда ставить, но делать «как у всех» не хотелось =) хотя стандарт fhs очень продуманный и читая понимаешь, что не дураки писали. почитайте. интересно.

у меня система логически разделена на 3 куска: / (rootfs), /usr и /usr/local.
в / (rootfs) ставится «не нужно 1-го уровня» (я так называю, кхе-хе) все необходимое для работы системы, в т.ч. библиотеки, если какие-то «везде» ставятся в /usr, то тоже перекочевали в / корень, т.к. программы из корня требуют их. помимо всего прочего, в / установлены dhcpcd, pppd и sshd.
в /usr ставится «не нужно 2-го уровня», а именно все инструменты разработки для сборки программ и простой софт, без которого система скучна: syslog, cron, sendmail. и в /usr/local все остальное.

таким образом, можно удалить целиком /usr/local (и|или) /usr, а система останется в рабочем состоянии.
такая дурь в голову ударила после того, как я прочел в fhs что /usr это read-only файловая система, - я так понял, что когда стояли толстые мейнфреймы и офисные ПеКа были тонкими клиентами - /usr монтировалась удаленно в RO режиме. могу ошибаться, это лишь мои догадки. так вот, система поэтому не зависима от «внезапно немонтируемой» /usr.
а в /usr/local уже до кучи решил ставить весь остальной софт. с одной лишь оговоркой, что /usr/local/etc является симлимком на /etc/local директорию. т.е. так или иначе получается, что конфиги все лежат в одном /etc.

все данные как обычно в /var лежат.

еще я думаю, а не перенести ли мне остатки (cron, syslog, sendmail) тоже в / корень... от не знаю.

сейчас все стараются убрать /bin /sbin и подобные в /usr/xxx, а ты идёшь против системы.

правильно делает. Ибо эти твои «все» свернули с UNIX Way на маздайный путь. Это выгодно только крупным монополиям.

https://fedoraproject.org/wiki/Changes/NoBinDeps

да-да. Например красной шапке выгодно.

PS: необходимый коммент я тебе прилепил.

помимо всего прочего, в / установлены dhcpcd, pppd и sshd.

Патрег не одобряет такой выбор для pppd и sshd.

Хотя тебе конечно виднее.

такая дурь в голову ударила после того, как я прочел в fhs что /usr это read-only файловая система, - я так понял, что когда стояли толстые мейнфреймы и офисные ПеКа были тонкими клиентами - /usr монтировалась удаленно в RO режиме. могу ошибаться, это лишь мои догадки.

так и было. Мало того, в этом и сейчас смысл есть, учитывая наличие разных нетбуков. Я так и сделаю, как только дождусь в своём нетбуке вечного, быстрого и бесплатного анлима. А то сейчас Сеть ещё не так доступна, как оно того хотелось-бы. Если в десктопах у меня вечный, быстрый, и почти бесплатный анлим, то вот в мобильной технике к сожалению не так.

еще я думаю, а не перенести ли мне остатки (cron, syslog, sendmail) тоже в / корень... от не знаю.

зачем?

обоснуй. А то я не вижу там ничего плохого.

1. Мне не нравится факт того, что есть /usr/bin /usr/sbin /bin /sbin /usr/local/bin /usr/local/sbin. Зачем мне в системе помойка из копий катологов (не вижу смысла в разделении 'bin'|'sbin' и 'уср'|'не уср'), пусть у меня будет только /bin — мне так проще и удобней.

2. Не надо набирать постоянно '/usr/*' для доступа к содержимому. /уср не будет мазолить глаза.

На хабре была статья об истории появления /usr. Я её не читал, но смысл был в том, что у мужиков просто закончилось место на /, а LVM тогда не было, и ребята решили присобачить ещё один хард для программ, которые просто не помещались в корень. Зачем же тащить этот 30 летний костыль в современные системы?

3. Всё будет структурированно, согласно моим предпочтениям и видением идеалов комфорта: конфиги в /etc и ~ и т.п.
Сгруппирую согласно чёткой логике - в этом каталоге только bin'арники, в том только lib'лиотеки, там только конфиги, т.е верхний каталог будет логичено обуславливать его содержимое, для более удобной и быстрой навигации по каталогам и для понимания где что лежит и осознания, что всё разложено по полочкам как тебе удобно

А вы про prefix не знали, ну-ну ...

я боялся, что он не во всём базовом совте есть

все /bin /sbin /usr/bin /usr/sbin объединю в /bin.

дык помойка и получится. Не?

С одной точки зрения - да, а с другой - нет
Не будет много клонов одного каталога, размазанных по всей системе.
Всё будет в одном смысловом месте.
А графический софт от базовых системных утилит можно и отделить в отдельный каталог - в /bin/X или в /X

Мне не нравится факт того, что есть /usr/bin /usr/sbin /bin /sbin /usr/local/bin /usr/local/sbin. Зачем мне в системе помойка из копий катологов (не вижу смысла в разделении 'bin'|'sbin' и 'уср'|'не уср')

Linux система традиционно делится на пять категорий:

1. /bin/, /lib/, /etc/ необходимые программы без которых НИКОГДА нельзя. Их очень немного, меньше гигабайта. Особняком стоит /boot/ который вообще не нужен, кроме как на начальном этапе загрузки(до монтирования rootfs).

1.1 /sbin/ часть программ, которые нужны исключительно администратору. Большинство из них просто не будет работать никак, кроме как от него. Например в большинстве систем для юзеров абсолютно бесполезна fsck (впрочем, если какому-то юзеру оно нужно, всегда его можно добавить в группу disk, и сделать ему симлинк на эту программу, для его удобства).

2. /usr/bin и т.д. Это опциональные программы, которые постоянно всем нужны. В отличие от (1) без них можно обойтись, например при аварии.

2.1 /usr/sbin Тоже опциональные, но для администратора. К примеру iptables. Сеть работает и без этой утилиты. А юзеры не могут и не нуждаются в том, что-бы туда лазать.

3. $HOME — отдельный каталог для каждого юзера, в котором он сам решает, что ему нужно, а что не нужно.

только /bin — мне так проще

ага. И работать под рутом. Так всем проще, не сомневаюсь. Однострок на перле дать? Работать-то проще, но ВСЁ испортить — тоже не сложно. В т.ч. и случайно. Ну и враг тоже не дремлет(хотя самый страшный враг это тот, кто на клаву давит).

На хабре была статья об истории появления /usr. Я её не читал, но смысл был в том, что у мужиков просто закончилось место на /, а LVM тогда не было, и ребята решили присобачить ещё один хард для программ, которые просто не помещались в корень. Зачем же тащить этот 30 летний костыль в современные системы?

ну во первых это легенда. Во вторых, дело не в том, как придумали, а в том, что за 30 лет ничего лучше не осилили(хотя и пытались). Не, попытайся и ты, я же не против. С удовольствие прочту ss.

3. Всё будет структурированно, согласно моим предпочтениям и видением идеалов комфорта: конфиги в /etc и ~ и т.п.
Сгруппирую согласно чёткой логике - в этом каталоге только bin'арники, в том только lib'лиотеки, там только конфиги

для администратора удобнее группировать не по типам файлов, а по типам задач. Т.е. по пользователям. Если роль пользователя меняется, он перелогинивается в другой аккаунт, и работает от другого имени. При этом его доступ меняется (что-то разрешается, а что-то запрещается). В особо запущенных случаях даже администратору надо что-то запрещать(man SELinux), но в простых системах рут просто должен иметь голову на плечах, и не лезть в каталоги пользователя(ибо пользователь самостоятельно может и должен всё там настраивать).

А если юзеру вывалить не нужный ему /usr/sbin, то это его только запутает. У него и так в /usr/bin/ Over9000 программ.

А графический софт от базовых системных утилит можно и отделить в отдельный каталог - в /bin/X или в /X

лучше в /usr/X11/bin/. У меня в слаке даже симлинк такой есть.

Можешь и /usr/X11/kde/bin сделать ;)

только /bin — мне так проще

ага. И работать под рутом. Так всем проще, не сомневаюсь. Однострок на перле дать? Работать-то проще, но ВСЁ испортить — тоже не сложно. В т.ч. и случайно. Ну и враг тоже не дремлет(хотя самый страшный враг это тот, кто на клаву давит).

почему под рутом? можно же группы настроить, права

почему под рутом? можно же группы настроить, права

нельзя. Попытайся настроить права доступа к отдельному имени файла. Так, что-бы userA видел /bin/x и /bin/y, а userB видел только /bin/x, а вот /bin/y не видел. Это сделать невозможно, за то можно запретить видимость и использование всего /sbin/, и разрешить /bin.

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

Также многие атаки основаны на создании хардлинка. Очевидная защита от этого: запретить юзеру создавать хардлинки в этой ФС(на этом разделе). Если у тебя всё в одной фс, то ты этого сделать не сможешь(во всяком случае /tmp/ и /var/tmp тебе не запретить. Есть и другие каталоги), потому приходится выносить ФС с исполняемыми файлами в отдельную область(области), в которые у пользователя доступ только для чтения.

любой пакетманагер

куда скажешь, так и вкатит

обоснуй, как произвольный deb/rpm вкатить не в /usr

Мне не нравится факт того, что есть /usr/bin /usr/sbin /bin /sbin /usr/local/bin /usr/local/sbin. Зачем мне в системе помойка из копий катологов (не вижу смысла в разделении 'bin'|'sbin' и 'уср'|'не уср'), пусть у меня будет только /bin — мне так проще и удобней.

Ну так сделай симлинки. В чём проблема?

нельзя. Попытайся настроить права доступа к отдельному имени файла. Так, что-бы userA видел /bin/x и /bin/y, а userB видел только /bin/x, а вот /bin/y не видел. Это сделать невозможно, за то можно запретить видимость и использование всего /sbin/, и разрешить /bin.

а ACL и SeLinux?

обоснуй, как произвольный deb/rpm вкатить не в /usr

когда же вы, школьники, научитесь гуглить?

Вот, погуглил за тебя:

http://www.debian.org/doc/manuals/maint-guide/first.ru.html

Вы можете изменять различные переменные в файле Makefile. Например каталог установки по умолчанию изменяется с помощью параметра в командной строке: ./configure --prefix=/usr.

MacOS

что-бы userA видел /bin/x и /bin/y, а userB видел только /bin/x, а вот /bin/y не видел. Это сделать невозможно, за то можно запретить видимость и использование всего /sbin/, и разрешить /bin.

а ACL и SeLinux?

это невозможно не из-за «слабости» unix-like прав, а из-за отсутствия смысла.

Имя — часть содержимого каталога, а каталог это _одна_ сущность. Запретить доступ к имени == запретить доступ к одной строчке в текстовом файле. Можно, но только ко всему файлу. Или порезав файл на строчки. Тоже самое и с каталогами.

Реально ли избавиться от /usr?

я слышал, что у пользьзователей bumblebee были истории успеха

если бы он хотел только префикс, ты его предыдущие треды посмотри.

если бы он хотел только префикс, ты его предыдущие треды посмотри.

ну пока хотябы префикс, остальное потом

Makefile

deb

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

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

Ну а так, вам всё правильно сказали, скачайте deb-src, измените параметры сборки, в частности prefix, соберите пакет с изменёнными параметрами и установите.

тред не читай, сразу отвечай?

Я тред читал, если читал его и ты, то видел здесь около 5 моих комментариев.

Вашу полемику с drBatty я так же видел.

Ты сказал:

x0r

обоснуй, как произвольный deb/rpm вкатить не в /usr

Тебе ответил drBatty: Реально ли избавиться от /usr? (комментарий) .

Я раскрыл немного глубже ответ.

Жениться вам барин нужно, жениться.

/usr/include куда ?

да и /usr/x86_64-pc-linux/* которые gcc юзает

ну и не стоит забывать про то что если вы захотите такое сделать то gcc-config вам придется переделывать.

как и большую часть eselect

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

и вообще идея скинуть все в /bin плоха в корне, /sbin не просто так отдельно сделан.

dpkg -X

2. Не надо набирать постоянно '/usr/*' для доступа к содержимому

mv /usr/bin/* /bin && rmdir /usr/bin && ln -s /bin /usr/bin

не проверял но должно работать.

только при наличии <tab> это не нужно

2. Не надо набирать постоянно '/usr/*' для доступа к содержимому.

А зачем ты его постоянно набираешь?

2. Не надо набирать постоянно '/usr/*' для доступа к содержимому.

На хабре много чего пишут. Но всему из этого стоит слепо следовать.

3. Всё будет структурированно

Отказ от использования директорий и спихивание всего софта в одну файлопомойку теперь называется структурированием? Оригинально.