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

Подлинный промах — сама идея «скрытых» файлов.

Возможно. В Plan9 скрытых файлов нет.

Чем симлинк не устраивает?

http://defun.co/gKG3

Для тех кто вопит и не согласен напомню статью от 27 января 2012 года на опеннете с перечисленными плюсами перевода /bin,/sbin в /usr:

Разработчики дистрибутива Fedora Linux рассматривают возможность перемещения всех имеющихся в системе исполняемых файлов в одну директорию. Иными словами, предлагается размещать исполняемые файлы только в каталоге /usr/bin, а директории /bin, /sbin и /usr/sbin преобразовать в символические ссылки, указывающие на /usr/bin. По аналогии предлагается упразднить /lib и помещать все системные библиотеки только в директории /usr/lib. В случае одобрения предложения, изменения могут вступить в силу уже в весеннем релизе Fedora 17.

Перенос всех файлов и библиотек в иерархию /usr открывает очень интересные перспективы: так как все необходимые для работы компоненты будут присутствовать в рамках одного дискового раздела, появляется возможность обособленного использования нескольких разделов /usr для загрузки разных версий или состояний дистрибутива (например, через создание снапшотов в процессе обновления) и, что особенно интересно, становится возможным использование одного смонтированного в режиме только для чтения самодостаточного раздела /usr одновременно на нескольких компьютерах. Ранее, при монтировании /usr по сети, у администраторов возникали проблемы с обновлением содержимого /bin, /sbin и /lib на конечных машинах, с самодостаточным /usr поддерживать большое число типовых машин станет значительно проще и безопаснее (/usr предлагается монтировать в режиме только для чтения).

В соответствии с новым подходом, все устанавливаемые из RPM-пакетов компоненты будут сосредоточены только внутри раздела /usr и не будут встречаться за его пределами. Файлы и каталоги, присутствие которых необходимо вне иерархии /usr предлагается связывать при помощи символических ссылок. В корне останутся только файлы, имеющие непосредственное отношение к текущему компьютеру, например, файлы конфигурации, логи и файлы с меняющимися данными (/etc, /root, /var, /run).

Разделение /bin и /usr/bin было актуальным во времена раздельного монтирования корня и раздела /usr, в случае невозможности примонтировать /usr, наличие каталогов /bin и /lib позволяло сохранить минимально работающую систему, которую можно было использовать в качестве базы для дальнейшего восстановления. В настоящее время дистрибутив нереально загрузить без /usr (/usr монтируется из initramfs до запуска процесса инициализации и содержит необходимые для загрузки компоненты), что в сочетании с распространением практики разбиения диска на один большой раздел и подготовкой установочного образа в виде Live-системы, позволяет отнести к анахронизмам разделение бинарных файлов по разным частям файловой системы.

В пользу объединения sbin и bin упоминается то, что во многих дистрибутивах данные директории одновременно включены в путь по умолчанию, а также то, что в sbin можно найти программы, которыми пользуются и обычные пользователи. Тем не менее, среди разработчиков Fedora нашлось много противников объединения sbin и bin, которые считают логичным разделение пользовательского ПО и требующих повышенных привилегий программ для администратора (изначально каталог sbin предназначался для статически собранных программ). Также упоминается то, что объединение sbin и bin вызовет необходимость действий со стороны разработчиков upstream-проектов.

Источник: http://www.opennet.ru/opennews/art.shtml?num=32914

[::]\/\классеко/\/[::]

http://www.black-sabbath.com/images/covers/heavenandhell_original.jpg

По-моему перенос /{s}bin в /usr это просто гениальное решение и я не понимаю к чему всё это бурление говн. Открываются вполне аргументированные и востребованные преимущества, а нафиг вам этот / сдался я вообще догнать не могу.

И для фанатиков: systemd тут совершенно ни при чём. Головой думайте, а не повторяйте один за одним как хомячки наболевшие фразы.

Ранее, при монтировании /usr по сети, у администраторов возникали проблемы с обновлением содержимого /bin, /sbin и /lib на конечных машинах

:фацепальм.бмп:

В настоящее время дистрибутив нереально загрузить без /usr (/usr монтируется из initramfs до запуска процесса инициализации и содержит необходимые для загрузки компоненты)

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

Аргументы «за» просто офигенные, да.

Зато из рута можно bin со sbin выпилить. Зачем? Лично я хз, сам так не делаю и никому не советую. Вообще конечно не актуально для локалхостов, особенно там где /usr на корневом разделе.

Перепутал статьи местами. Но эта тоже полезна. А вообще первоначально планировалось скопировать эту:

В связи с волной критики Леннарт Поттеринг (Lennart Poettering) подготовил сводный документ, в котором обобщил мотивы переноса содержимого /bin и /lib в директорию /usr в грядущем релизе Fedora 17, а также опроверг наиболее часто встречающиеся мифы. По словам Поттеринга, новое унифицированное расположение исполняемых файлов и библиотек внутри раздела /usr (содержимое /bin планируется перенести в /usr/bin, /sbin в /usr/sbin, /lib в /usr/lib и /lib64 в /usr/lib64) более совместимо с UNIX, чем практикуемый в Linux подход с разделением на /bin и /usr/bin (в SysV Unix /bin является симлинком на /usr/bin).

Некоторые плюсы переноса компонентов из корня в /usr:

В настоящее время разные дистрибутивы Linux и Unix-системы по разному формируют состав /bin и /usr/bin. Перенос всех исполняемых файлов в /usr/bin и наполнение /bin через символические ссылки позволит избежать путаницы и сохранить совместимость с ранее практикуемым методом.

Все устанавливаемые из RPM-пакетов неизменные компоненты будут сосредоточены только внутри раздела /usr и не будут встречаться за его пределами, что позволит упростить организацию бездисковых систем и повысит их безопасность - для работы достаточно будет экспортировать в режиме только для чтения раздел /usr и централизованно обновлять его, не заботясь о необходимости синхронизации содержимого каталогов /bin, /sbin и /lib. В корне останутся только файлы, связанные с загрузкой и специфичные для текущей машины данные, например, файлы конфигурации, логи и файлы с меняющимися данными (/etc, /root, /var, /run).

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

Упрощение формирования гостевых окружений для систем виртуализации - достаточно монтировать внутри виртуальных окружений системный раздел /usr в режиме только для чтения. При этом автоматически решаются проблемы с обновлением начинки гостевых систем и существенно экономится дисковое пространство;

В качестве примера успешной унификации доступа к исполняемым файлам приводится Solaris 11, в котором все стандартные программы сосредоточены только в разделе /usr;

Дополнение: В списке рассылки разработчиков Fedora опубликовано сообщение о скорой миграции Fedora Rawhide на новую схему размещения исполняемых файлов. Для пользователей, использующих Rawhide, для перехода на новую схему потребуется выполнить несколько ручных операций, которые детально изложены в сообщении.

Ну назови хоть пару плюсов старого метода, раз всё тебе не так :)

самый главный аргумент: we have somebody who wants to do the work.

Это как раз и понятно. В вот bin и sbin зря они смешали.

Неправильно pacmanом пользуетесь.

А вот этого я сам не догнал, если честно. Хотя с другой стороны, идея sbin давно исчерпалась. Например я всегда когда набирал в системе без $PATH путь к бинарнику путал пути sbin с bin. При чём в каждой системе всё было по разному (по крайней мере у линукса и бсд). И не всегда это расположение было логично.

А сейчас такой проблемы не будет, потому что все бинари в одном месте.

И «минус» я вижу только один - `ls` дольше список выводит :)

А какие плюсы по твоему в /sbin, /usr/sbin, кроме как «привычно»? (просто интересно)

Выходит обновление ядра, и вы делаете что? Пересобираете initrd? И так каждый раз?

Именно так мы и поступаем, mkinitcpio запускается автоматически при обновлении пакета linux (там у нас ядро живёт).

Дополню lampslave: это занимает несколько секунд :)

Sabayon ?

Ну наконец-то и тут избавились от дурацкого костыля 30-с-хреном летней давности

Напротив, засунули в этот костыль всю систему. Раз уж взялись, так перенесли бы всё содержимое /usr в /. А то пересобирать им, видите ли много.

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

Ээ.., это примерно тоже самое, что сказать «бубунта это ведь дебиан». Окриветь можно сразу на оба глаза: на один от дебианщиков, на второй от бубунтятников :)
Если ему нужен бинарный дистр, то их вагон и маленькая тележка, и в каждом из них своя система пересборки пакетов, где то лучше, где то хуже, но есть в кажд

Вот ведь какой вкусный , однако, кактус :)

.. и никакого смысла, прог в портах slackduilds.org мизер и их количество несравнимо даже со slackduilds.org

Какая разница, если в одном большом костыле один побочный сменит другой побочный? :)

Плюсы уже приводились выше, независимое монтирование базовой и основной системы, полноценная база на компактной железяке с ограниченным объёмом памяти под систему, и т.п.

Но вообще-то сие есть задача инноватора, доказывать жизненную необходимость его идей в изменении того, что работает и так.

То, что выложено «за» изменения, недостаточные, а то и откровенно спорные аргументы. Что хорошо программеру, админу смерть ))

А какие плюсы по твоему в /sbin, /usr/sbin, кроме как «привычно»? (просто интересно)

Кстати тоже интересно. У мну как раз попадаетца /sbin -> /bin, и /usr/sbin -> /usr/bin =)

Ну да, конечно

Чëрт с ним, с башем, но /bin/sh обязателен по FHS.

Это где такая жесть? O_O

\0

Блин, ну как же всë-таки некоторым винда мозги проела, что даже дроби через обратный слеш пишут... :(

у меня алиас на замену )

(дополняю свой комментарий)

Проверил. Никаких изменений, всё замечательно ставится и работает.

> find /usr -name bin
/usr/bin
/usr/ccs/bin
/usr/lib/lp/bin
/usr/lib/cc-ccr/bin
/usr/lib/cc-cfw/platform/transport/bin
/usr/lib/cc-cfw/platform/invagent/bin
/usr/lib/cc-cfw/platform/fwagent/bin
/usr/lib/cc-cfw/platform/ccragent/bin
/usr/lib/gnome-private/bin
/usr/lib/gnome-private/demo/jds/bin
/usr/lib/cacao/bin
/usr/lib/scn/bin
/usr/lib/breg/bin
/usr/sfw/bin
/usr/sfw/i386-sun-solaris2.10/bin
/usr/xpg4/bin
/usr/demo/jds/bin
/usr/openwin/bin
/usr/openwin/lib/xscreensaver/bin
/usr/sadm/bin
/usr/sadm/install/bin
/usr/sadm/sysadm/bin
/usr/sadm/lib/smc/bin
/usr/sadm/admin/bin
/usr/share/sgml/docbook/dsssl-stylesheets-1.77/bin
/usr/share/webconsole/private/bin
/usr/share/webconsole/private/container/bin
/usr/share/webconsole/bin
/usr/dt/bin
/usr/dt/appconfig/dtpower/bin
/usr/dt/appconfig/sdtprodreg/bin
/usr/dt/appconfig/sdtpdasync/bin
/usr/perl5/5.8.4/bin
/usr/perl5/bin
/usr/perl5/5.6.1/bin
/usr/proc/bin
/usr/X11/bin
/usr/jdk/instances/jdk1.6.0/bin
/usr/jdk/instances/jdk1.6.0/jre/bin
/usr/jdk/instances/jdk1.5.0/bin
/usr/jdk/instances/jdk1.5.0/jre/bin
/usr/jdk/packages/jmf/bin
/usr/jdk/packages/javax.help-2.0/bin
/usr/jdk/packages/javax.help-2.0/demos/bin
/usr/jdk/packages/org.jdesktop.jdic-0.8/bin
/usr/j2se/bin
/usr/j2se/jre/bin
/usr/snadm/bin
/usr/apache2/bin
/usr/postgres/8.3/bin
/usr/postgres/8.2/bin
/usr/postgres/upgrade/81/bin
/usr/postgres/upgrade/bin
/usr/apache/bin
/usr/apache/tomcat/bin
/usr/apache/tomcat55/bin
/usr/sunvts/bin
/usr/xpg6/bin
/usr/oasys/bin
/usr/vmsys/bin
/usr/pgadmin3/bin
/usr/local/bin[/bin]

 > uname -sr
SunOS 5.10

Идеал местных любителей юникса, я так щитаю

Просто я всегда считал что sbin'ы для рута и для того у кого есть привилегии рута. По-моему ж такой принцип? Если да, то куда например кидать wicd, или mount? Потому что например на сервере понятно что никто из пользователей не будет монтировать свои диски, или же настраивать инет, но если дело обстоит с десктопом, то порой команды которые логичны для рута применимы и пользователем. Да и вообще, нафига эта псевдоизоляция необходима и что она за собой несёт? Ведь запуск команд ограничивает не их местонахождение, а ядро системы... Поэтому в чём отличия sbin от bin мне не до конца понятны, по крайней мере в современности. Объясните коль кто знает.

Отличие в кошерности :)

Ну сравнили. В данном случае перемещение директорий не особо на что-то повлияло. И вообще если вы мне подскажете дистрибутив с подобием AUR, простыми описаниями пакетов и свежим софтом, тогда ладно. А лично меня данное изменение практически не затронуло, хотя и являюсь программистом.

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

p.s. другое непонятно, зачем сейчас конфиги наоборот на кучу мелких распиливают, напр. что apt.conf[.d], что тот же богоугодный rc.conf арчеры выпилили..

Идеал местных любителей юникса, я так щитаю

Писать ты умеешь не очень хорошо, но считать - еще хуже.

Это нулевой символ же.

Симлинк /bin хотя бы присутствует, надеюсь? ))

Да, толстый у них PATH наверное...

Да, толстый у них PATH наверное...

Придумалась шутка по поводу преимуществ переноса всего в /usr:

1) Запись $PATH теперь сократилась до строчки:

PATH=/usr/bin

+ убраны непонятные многим пользователям символы ":" в этой переменной ;)

Сейчас, как понимаю, разница между bin и sbin размылась

Во-во, я о том же. Поэтому особого смысла в сохранении этой иерархии и не вижу.

p.s. другое непонятно, зачем сейчас конфиги наоборот на кучу мелких распиливают, напр. что apt.conf[.d], что тот же богоугодный rc.conf арчеры выпилили..

В арче понятно почему - ибо systemd. А вот в остальных дистрибах хз. Наверное чтобы более-менее порядок был. Это всё равно что репы дополнительные в дебиане подрубать - можно всё пихать в sources.list, а можно разбивать на логичные группы файлов в sources.list.d

Ubuntu или Gentoo.

А вот реально, по какому принципу там формируется $PATH? find'ом сканируется по ФС наличие новых каталогов «bin»? ;)

А вот реально, по какому принципу там формируется $PATH?

Я тебе намекну:

> man tr | grep /usr
Reformatting page.  Please Wait... done
     /usr/bin/tr [-cs] string1 string2
     /usr/bin/tr -s | -d [-c] string1
     /usr/bin/tr -ds [-c] string1 string2
     /usr/xpg4/bin/tr [-cs] string1 string2
     /usr/xpg4/bin/tr -s | -d [-c] string1
     /usr/xpg4/bin/tr -ds [-c] string1 string2
     /usr/xpg6/bin/tr [-c | -C] [-s] string1 string2
     /usr/xpg6/bin/tr -s [-c | -C] string1
     /usr/xpg6/bin/tr -d [-c | -C] string1
     /usr/xpg6/bin/tr -ds [-c | -C] string1 string2
  /usr/xpg4/bin/tr
  /usr/bin/tr
                  Note:  /usr/bin/tr  supports  character   class
                  /usr/xpg4/bin/tr to support  these  expressions
  /usr/bin/tr
  /usr/xpg4/bin/tr
  /usr/xpg6/bin/tr

 > echo test | tr '[:lower:]' '[:upper:]'
Bad string
 > echo test | /usr/xpg6/bin/tr '[:lower:]' '[:upper:]'
TEST

Не ломается - не трогай.

А еще два правила линуксоида:

• У меня все работает.
• То, что у меня не работает, мне не нужно

Я больше скажу - так происходит и в дебиане, и бубунте. Более того, в дебе и бубунте инитрд пересобирается на каждый чих.

ога, подстригли бороду отцам-основателям UNIX, ни за что ни про что =))

Кстати, про /usr/local/games ещё незаслуженно забыли )))

Ещё в /opt всякое лежит типа гугля и проприетарщины. Поэтому в /usr полюбому не всё, и PATH таки с разделителем..Ж)

А что в AUR хорошего? Каждый раз вручную пересобирать. В этом смысле launchpad и пользовательские репозитории software.opensuse.org например куда интереснее.

Ну сравнили. В данном случае перемещение директорий не особо на что-то повлияло.

Сравнил. Потому как это костыльное решение для костыля. Поясняю: есть разделение по директориям, оно закреплено в стандарте (опускаю реплики типа «в стандарте не сказано, что это может быть симлинком на одно место»). Есть идея уйти от этого «устаревшего» стандарта, так инициируйте процесс обсуждения этих изменений, процесс принятия новой версии стандарта (FHS 3.0 в стадии обсуждения). Ведь ввели /opt, когда потребовалось размещать всякое проприетарное добро, идущее одним бандлом, добавили /media, /srv, когда оно потребовалось. А то и так уже: всякие /run с непонятной структурой, теперь и мерж всех бинов в /usr/bin.

При этом «для совместимости» делается ещё один костыль: симлинки /bin, /sbin, /usr/sbin. А если убрать эту костыльную совместимость, то, как минимум, добавляется работа маинтейнерам пакетов: правильно переложить всё в /usr/bin, поправить все #!/bin/sh на #!/usr/bin/sh. А если возникнет необходимость поставить какой-то .run файл, то будет вообще облом с кряком и головняк конечному пользователю.

И вообще если вы мне подскажете дистрибутив с подобием AUR, простыми описаниями пакетов и свежим софтом, тогда ладно.

только по этим причинам пока на арче. А вообще:

1. Простые описания пакетов:

• CRUX (как я выше писал, изначально арчевские PKGBUILD отличались только наличием depends=)
• Slitaz - есть даже конвертер из арчевских
• Alpine Linux - почти один в один арчевские

2. AUR. Тут тяжелее

• CRUX - есть отдельные репозитории с портами, можно заводить, качать и строиться. Про это выше @OldManClone писал. Он же и подробности может рассказать.
• Slitaz - развивается, возможно даже появится (http://forum.slitaz.org/topic/user-repository)
• AlpineLinux - нет ничего похожего, и скорее всего врядли будет

3. Свежесть софта. Вопрос относительный. Особенно с последними тенденциями в арчике (в треде уже обсуждалось)

• CRUX - ничего не скажу, @OldManClone лучше расскажет
• Slitaz - вполне себе, хотя задержки с обновлениями есть
• AlpineLinux - вполне себе

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

• CRUX - нет депендов, только если обновляться с сетевого репозитория, локальные пакеты зависимости не проверяют.
• Slitaz - уже не помню. Чую, что стоит опять на него пристально поглядеть :)
• AlpineLinux - основан на uClibc, как следствие: нет локалей, нет совместимости с glibc/eglibc приложениями (особенно актуально при установке проприетарного софта). Если бы не это, мигрировал бы на него не задумываясь.

Развиваю: путь поиска в /usr/bin зашивается во все оболочки, а ещё лучше патчится ядро Linux, что бы всякие exec по дефолту искали в /usr/bin :-D

А чего это у всех так бомбит? Логичное решение.