LINUX.ORG.RU

Разработчики Fedora обсуждают объединение каталогов для исполняемых файлов

 


0

0

Разработчики Fedora обсуждают возможное объединение каталогов /bin, /sbin/, /usr/bin и /usr/sbin: предлагается все исполняемые файлы помещать в каталог /usr/bin, а другие каталоги сделать символическими ссылками на него для совместимости.

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

  • разделение на /bin и /sbin приводит к усложнению работы разработчиков, которые зачастую ошибаются с выбором каталога, либо бездумно помещают файлы в /usr/bin;
  • первоначальное назначение каталога /sbin (размещение статически собранных файлов, на что указывает буква «s») давно неактуально;
  • разделение на /bin и /sbin не имеет отношения к безопасности (это был бы глупый принцип «security by obscurity»);
  • разделение на /bin и /sbin имеет значение только для переменной $PATH, однако усложнять доступ пользователей к некоторым инструментам - плохая затея; к тому же для этого есть более подходящие каталоги;
  • разделение на /bin и /sbin в любом случае бессмысленно уже пару версий Fedora, поскольку оба каталога включены в переменную $PATH для всех пользователей;
  • разделение приводит к усложнению, а мы должны стремиться к упрощению;
  • различные дистрибутивы размещают некоторые бинарные файлы в различных каталогах, что приводит к проблемам с переносимостью скриптов;
  • разделение на /bin и /usr/bin в основном было сделано для этапа ранней загрузки системы - минимальный набор загрузочных файлов находится в /. Но это давно не работает, и соответствующая опция убрана из инсталлятора anaconda. Более того, размещение /usr на отдельной файловой системе вызывает проблемы при загрузе посредством systemd;
  • разделение на минимальную систему в / и полную в /usr также стало бессмысленно благодаря initrd, а содержание двух уровней «минимальной загрузочной системы» - дурацкая затея;
  • существенно упростится установка «read-only» системы: так, libc и другие системные библиотеки будут доступны только на чтение, а /etc - на чтение и запись;
  • снятие снапшотов станет действительно атомарной операцией. В настоящее время btrfs требует 5 снимков - /lib, /lib64, /bin, /sbin и /usr вместо одного, что неудобно и может приводить к состояниям гонки;
  • существенно упростятся сетевая и контейнерная установки;
  • сборочные скрипты упростятся: в частности, autoconf не знает о разделении на / и /usr, и для правильной работы с ними приходится прилагать специальные усилия;
  • эксперименты уже показали жизнеспособность предложенной схемы и отсутствие серьезных проблем;
  • есть разработчик (Harald Hoyer), готовый выполнить необходимую работу.

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

>>> Подробности

★★★★

Проверено: Shaman007 ()
Последнее исправление: JB (всего исправлений: 2)

Ответ на: комментарий от geekless

>На гентушников, ночами компиляющих ядра

не тупи, детка

иначе я начну вываливать сюда хэпписторис про арчеров, ночами восстанавливающих систему после обновлений

anonymous
()

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

тупые федорасты

... потом что бы этим их высером пользоваться придется посещать мегакурсы от редхата.

много проще кастрировать того одного добровольца герострата :)

psv1967 ★★★★★
()
Ответ на: комментарий от imul

> Вообще-то прочти для начала man umount

В нем где-то написано, что так нельзя делать?

Либо надо отмонтировать ...

Да, конечно, только вот, сюрприз, если mtab - это обычный файл, то все работает.

О чем и было сказано - при симлинке вылязят глюки. Если mtab - обычный файл, то глюков нет.

anonymous
()
Ответ на: комментарий от geekless

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

anonymous
()
Ответ на: комментарий от anonymous

> Да, это понятно, но зачем? Зачем этот разброд, почему именно /usr должен монтироваться из initrd, а остальное из корня? Или для /var тоже отдельный параметр? А если у меня будут еще какие-то разделы (/opt, /srv...) - для них будут свои параметры?

Остальное можно смонтировать из fstab.

Давай представим, что текущей FHS не существует у нас как идеи. Пусть мы пришельцы из космоса, которые этот их юникс сегодня первый раз в глаза увидели. И вот я говорю:
Бинарники на разделе с конфигурацией хоста — да, это понятно, но зачем? Зачем этот разброд, зачем файлы пакетов размазывать по нескольким разделам? Почему именно эти файлы, а остальные на /usr? Да, все это можно, но зачем?

geekless ★★
()
Ответ на: комментарий от anonymous

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

Отличная, четко описанная и документированная структура каталогов. За каждым каталогом закреплено его точное назначение. Каждому каталогу дано короткое легко запоминающееся имя. Никаких симлинков, никаких туманных назначений, никакой базы данных. Или, может, ты знаешь хоть один стандарт файловой системы, который подробнее и понятнее?

размазанность пакетов чуть ли не по всей иерархии; геморрой с установкой одного пакета нескольких версий


Какое отношение пакетный менеджер отдельно взятого дистрибутива имеет к стандарту файловой системы юникс?

anonymous
()
Ответ на: комментарий от geekless

>Почему именно эти файлы, а остальные на /usr?

потому что дебилы стандарт придумывали, тупые задроты-очкозавры с одеревеневшими мозгами

толку от этого /usr/bin, если для установки пакета в любом случае нужны права рута

anonymous
()
Ответ на: комментарий от Chaser_Andrey

> Объединение /bin и /sbin, а также /usr/bin и /usr/sbin - здравая идея. Но объединение /bin и /usr/bin - как-то глупо. А на кой нам тогда /usr? Давайте уже всё в /bin, который и монтировать отдельным разделом.

А если я хочу в отдельном разделе /usr?

firestarter ★★★☆
()
Ответ на: комментарий от anonymous

> зоопарк каталогов, дублирующих друг друга;

Приведи пример зоопарка каталогов, дублирующих каталогов. Только предварительно убедись, что в их назначении (пункт Purpose каждой директории) одинаков.

спагетти из линков и симлинков;

Спагетти из линков и симлинков? Не видел, опять же пруф. GoboLinux не предлагать, он не соответствует FHS.

каталоги с туманным назначением;

Каталоги с туманным назначением? Опять же читай пункт Purpose.

совершенно дебильная структурас дебильными именами, больше похожая на базу данных, чем на систему для использования человеком;

размазанность пакетов чуть ли не по всей иерархии;

геморрой с установкой одного пакета нескольких версий

1) Вполне нормальные имена. Нравится больше /Users или C:\Program Files? 2) и 3) Тут это скорее фича, а не баг. Не согласен? «Вали на венду» или макось или что-нить типа GoboLinux. Да-да, linux не поддерживающий стандарт FHS есть, используей его и не перди тут.

Не достаточно, перди сильнее, стране нужен твой метан.

anonymous
()
Ответ на: комментарий от anonymous

> GoboLinux не предлагать, он не соответствует FHS.

GoboLinux. Да-да, linux не поддерживающий стандарт FHS есть

Эпичное незнакомство с матчастью.

geekless ★★
()
Ответ на: комментарий от geekless

Да, твой слив засчитан. Играем в «Кто первый сказал слив засчитан, тот засчитал свой слив».

anonymous
()

>1. разделение на /bin и /usr/bin в основном было сделано для этапа ранней загрузки системы

2. размещение /usr на отдельной файловой системе вызывает проблемы при загрузе посредством systemd;

Вывод: что за ******бы разместили демонов в usr?

З.Ы.: Упс: /usr/local/sbin/squid

AlexVR ★★★★★
()
Ответ на: комментарий от anonymous

>Отличная, четко описанная и документированная структура каталогов

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

За каждым каталогом закреплено его точное назначение

то-то каждый пакет пихает свои файлы кто куда горазд, без всякой логики

Каждому каталогу дано короткое легко запоминающееся имя

а оно нахрен нужно - запоминать эти имена? и какой дебил придумал назвать каталог конфигов словом etc?

Никаких симлинков, никаких туманных назначений, никакой базы данных

понятно

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

Какое отношение пакетный менеджер отдельно взятого дистрибутива имеет к стандарту файловой системы юникс?

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

anonymous
()
Ответ на: комментарий от deterok

> Это будет реализовано только на fedor'е или изменения в стандарт войдут?

А кто Вам сказал, что это _будет_ реализовано в федоре?

myhand
()

Почему бы просто не сделать каталог /Program Files/, где в каждой подпапке хранятся файлы, необходимые для запуска программы. Чтобы не искать их по всей файловой системе?

zenden
()
Ответ на: комментарий от anonymous

> GoboLinux. Да-да, linux не поддерживающий стандарт FHS есть

Он его поддерживает только симлинками (также, как предлагает жопперинг).

Ну ты понял, да?

Слив.

Сам себе засчитал? Молодец.

geekless ★★
()
Ответ на: комментарий от zenden

потому что это - ойойой, божечки ты мой - как в венде же!! красноглазая прыщета на говно же изойдёт!

anonymous
()
Ответ на: комментарий от anonymous

> В нем где-то написано, что так нельзя делать?
umount {dir|device}
dir - destination
device — source

Да, конечно, только вот, сюрприз, если mtab - это обычный файл, то все работает.


Зато у меня были феерические глюки с mtab (просто файлом) во всех случаях. Нет уж, не хочу, тем более в случае симлинка корректно ставится устройство и по устройству всё прекрасно отмонтируется, также как и по каталогу-назначению.

О чем и было сказано - при симлинке вылязят глюки.

lol, но да ладно, это оффтоп в треде.
Просто каждый из нас останется при своём мнении. Я не считаю это глюком.

imul ★★★★★
()
Ответ на: комментарий от zenden

> Почему бы просто не сделать каталог /Program Files/, где в каждой подпапке хранятся файлы, необходимые для запуска программы. Чтобы не искать их по всей файловой системе?

Зачем тебе их искать «по всей файловой системе»? Мне ни разу не приходилось. ЧЯДНТ?

geekless ★★
()

Зачетный батхёрт. А все из-за размывания деления «минимальная система - система - мир» в современных десктоп-ориентированных дистрах, где все на свете устанавливается через пакетный манагер.

Если уж авторы идеи не видят смысла в выделении «минимальной системы», тогда стоит обсуждать полный перенос:
/usr -> /
/usr/local -> /usr

Предложенный вариант с симлинками - ни в звезду ни в красную армию.

u42
()
Ответ на: комментарий от geekless

>Зачем тебе их искать «по всей файловой системе»?

например, чтобы узнать, какому пакету принадлежит бинарник/библиотека

anonymous
()
Ответ на: комментарий от geekless

> Бинарники на разделе с конфигурацией хоста — да, это понятно, но зачем?

Это о чем?

Зачем этот разброд, зачем файлы пакетов размазывать по нескольким разделам?

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

Пакеты не связаны напрямую с файловой системой. Не нужно их путать.

Почему именно эти файлы, а остальные на /usr?

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

Так проще управлять системой. Это позволяет решать больший спектр задач. Этот стандарт универсален. Он работает не только для федоры, он работает для всего.

Если все компоненты системы соблюдают этот стандарт, то никто не мешает мне используя этот стандарт собрать систему, в которой потом внезапно заменить любой из компонентов. Скажем, я могу использовать ядро bsd вместо ядра линукс, и все будет работать (debian/kfreebsd, ага). Или, если у меня зуд в одном месте, я могу собрать собственный дистрибутив, в которой каталог /usr называется не /usr а /superdir, который монтируется из трех разных мест с помощью пропатченного мной unionfs. Но чтобы не изобретать лишний велосипед - скрипты начальной загрузки я возьму из стандартного дебиана, и все будет работать, потому что скрипты начальной загрузки не лезут в /usr.

Это основа принципов UNIX - каждый компонент системы выполняет только одну задачу, но выполняет ее хорошо.

«Write programs that do one thing and do it well.»

anonymous
()
Ответ на: комментарий от firestarter

Не правильно сказал. Читать как «на кой всё переносить в /usr/bin, если с таким же успехом можно перенести в /bin». Сам usr останется, естественно.

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от x86_64

на моей n900 / находится на встроенной быстрой nand размером в 256 метров, а весь юзерский софт ставится на более медленную и жирную флешку. Действительно, зачем их разделять?

anonymous
()
Ответ на: комментарий от anonymous

>* initrd монтирует корень, он содержит минимум программ и модулей, достаточных для того чтобы смонтировать корень, и занимает минимум памяти (да, initrd грузится в память, внезапно)

* корень монтирует все остальное, /var, /usr, где бы они ни находились, в сети или на локальном диске, после чего запускает пользовательские программы, он содержит огромное количество разных утилит, которые могут понадобиться для проверки и подключения файловых систем

Хм. А если корень находится в сети вместе с /usr (вполне типично, кстати), то задача одна?

x3al ★★★★★
()
Ответ на: комментарий от geekless

хрень, не стоящая того, чтобы её искать

проще найти через поиск в ФМ, каталог результата и будет ответом на вопрос

anonymous
()
Ответ на: комментарий от iBliss

> Приплыли.... все «софтины» с автоконфом отталкиваются от дефолтового префикса /usr, угадай с 3х попыток где окажется $PREFIX/etc ?
$PREFIX/etc окажется в /usr/etc, только Вы забыли что --sysconfdir=/etc поимеет Ваш $PREFIX/etc во все дыры. А я вот не видел софтин которые не используют --sysconfdir=/etc

FeyFre ★★★★
()
Ответ на: комментарий от deterok

> Разработчики Fedora обсуждают

Ну и как из этого следует, что «будет реализовано»?

«Обсуждают» - много где. К примеру, сейчас в debian-devel@lists.d.o. Учим логику и понимаем, что «обсуждают» != «реализуют».

Естественно, в FHS это войдет только как где-то будет реализовано (или запланировано) и не раньше.

myhand
()
Ответ на: комментарий от anonymous

> Затем, что файлы размещаются согласно их назначению (если не очевидно, зачем это надо, то могу объяснить и это). Если файлы разного назначения лежат в одном пакете, то они окажутся в разных каталогах, это логично.

Во-первых, не путай каталоги и разделы.

Во-вторых, современная GNU-система полностью управляется пакетником. Нельзя просто отпилить кусок и сказать «а это у нас будет лежать в сети». Либо у нас хост самодостаточен, и тогда деление на «минимальная система» и «всё остальное ПО» не нужно. Либо у нас всё централизовано, машины грузятся по сети... и разделение на «минимальная система» и «всё остальное ПО» опять не нужно.

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

Так проще управлять системой. Это позволяет решать больший спектр задач. Этот стандарт универсален. Он работает не только для федоры, он работает для всего.



Назови конкретную (и актуальную) задачу, которую в старом варианте размещения можно решить, а в новом нельзя или слишком затратно.

geekless ★★
()
Ответ на: комментарий от zenden

>Почему бы просто не сделать каталог /Program Files/, где в каждой подпапке хранятся файлы, необходимые для запуска программы. Чтобы не искать их по всей файловой системе?

а задержки автодополнения на мегабайтном патхе — это же так удобно!

thunar ★★★★★
()
Ответ на: комментарий от zenden

> Почему бы просто не сделать каталог /Program Files/, где в каждой подпапке хранятся файлы, необходимые для запуска программы. Чтобы не искать их по всей файловой системе?

Ох, мне казалось это очевидно. Ладно, поехали, основы юникс.

Есть два основных принципа размещения файлов:
1. Метод винды (метод ДОС, если хотите). Расположение файла зависит от того, какой программе он принадлежит. Каждая программа получает свой каталог, в котором хранит все файлы,
2. Метод юникс. Расположение файла зависит от его назначения.

Пока программы между собой не связаны кажется, что первый метод лучше и проще. Но все меняется, когда программы начинают взаимодействовать друг с другом. Где программы должны искать свои библиотеки? Пока все либы лежат в одном месте - проблем нет, а когда каждая либа оказывается в своем каталоге, как программы должны узнать где их искать? Прописывать каждую либу в LD_LIBRARY_PATH? А если либ - сотня? Прописывать всю сотню?

А что делать с бинарниками. Сейчас я набираю в баше `mplayer` и баш точно знает, где этот mplayer надо искать. А если mplayer будет в своем каталоге - как баш его найдет? Прописать в PATH все каталоги всех установленных программ? Винда примерно так и делает, и PATH там порой вылазит за тыщу символов.

И это еще только начало. В юниксе есть унифицированная система документации. Я могу набрать `man ls`, `man mplayer`, `man xterm`, `man send` и я увижу документацию, потому что вся эта документация лежит в одном каталоге /usr/share/man. А если она будет лежат у каждой программы отдельно - как man ее найдет? Завести переменную MAN_PATH и вписывать каждую программу в нее?

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

Для этого были написаны стандарты, которые определяют, где что лежит и в каком формате оно там лежит.

Тебе нравится, когда у каждой программы свой каталог? Тогда придумай для начала, как сделать для этого случая хотя бы общую систему документации, которую сможет прочитать любая утилита (man, pman, info, pinfo).

anonymous
()
Ответ на: комментарий от anonymous

На самом деле, конечно, поверх размещения «каждая программа в своём каталоге» можно виртуализовать размещение «каждый каталог — для файлов разного назначения». Но вот сложность системы вырастает в этом случае, а профиты не стоят того.

geekless ★★
()
Ответ на: комментарий от imul

> umount {dir|device}

Это в мане есть.

dir - destination
device — source

А этого нет. Да и, как мы знаем, у `mount --bind` и source и destination - это dir.

Зато у меня были феерические глюки с mtab (просто файлом) во всех случаях.

А можно пример? Я тоже проверю. :)

anonymous
()
Ответ на: комментарий от thunar

>а задержки автодополнения на мегабайтном патхе — это же так удобно!

из-за кучки альтернативно одарённых юзеров, любящих запускать приложения из консоли, должны страдать остальные

ничего страшного, потерпите задержки, или нормальное железо купите

anonymous
()
Ответ на: комментарий от anonymous

>Где программы должны искать свои библиотеки? Пока все либы лежат в одном месте - проблем нет, а когда каждая либа оказывается в своем каталоге, как программы должны узнать где их искать?

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

anonymous
()
Ответ на: комментарий от anonymous

>из-за кучки альтернативно одарённых юзеров, любящих запускать приложения из консоли

говна поешь и песдуй в семёрочку максимальную

thunar ★★★★★
()
Ответ на: комментарий от anonymous

> А можно пример?
Это было год назад. Дублировались записи в /etc/mtab.

Я тоже проверю. :)

Не проверите. Никто в здравом уме не будет ставить в систему systemd годовалой тухлости.

imul ★★★★★
()
Ответ на: комментарий от geekless

>поверх размещения «каждая программа в своём каталоге» можно виртуализовать размещение «каждый каталог — для файлов разного назначения»

я тебе уже говорил ранее, что ничего не нужно «виртуализировать», но ты не понял и опять повторяешь ту же ерундистику

никакой виртуализации, линками и некоторой переделкой пакетного менеджера делается элементарное - параллельное сосуществование нескольких иерархий

при этом нет никакой главной или стандартной иерархии - они все равноправны

anonymous
()
Ответ на: комментарий от thunar

залезь обратно в раздолбанную манду своей мамаши и больше не высовывайся оттуда, даун прыщавый

anonymous
()
Ответ на: комментарий от geekless

> Во-первых, не путай каталоги и разделы.

Не, это ты не путай каталоги и пакеты. :)

Во-вторых, современная GNU-система полностью управляется пакетником. Нельзя просто отпилить кусок и сказать «а это у нас будет лежать в сети».

Вот! Не все системы управляются пакетными менеджерами. И даже те, которые им управляются, могут управляться им не полностью. О чем и шла речь с самого начала. Все embedded/роутеры/телевизоры/мобилки работают без пакетного менеджера с захардкоденым минимальным корнем на r/o флешке. BSD и всякие одноразовые дистрибутивы из категории собрал-и-забыл (DSL/LFS) тоже отлично сработают с фиксированным корнем без пакетного менеджера. И в таких системах пакетный менеджер распространяется по сути только на /usr.

А стандарт FHS - он для всех юниксов, а не только для федоры.

Назови конкретную (и актуальную) задачу, которую в старом варианте размещения можно решить, а в новом нельзя или слишком затратно.

Кроме тех, что в этом треде уже назывались? ;) Ну, например, такая система позволяет мне имея минимальный BSD-шный корень монтировать по NFS линуксовый usr, собранный, скажем, на slackware.

anonymous
()
Ответ на: комментарий от jackill

> А чем мешает initrd? :)

Помимо того что он тормозит загрузку? Ну например, был такой случай - сменил фс корня - нихрена не грузится.

legolegs ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.