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)
Ответ на: комментарий от anonymous

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

значит, надо делать форк стандарта

форк - для удобных дистрибутивов, FHS - для всего остального

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

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

Да, это невероятно сложно. А конкретно:
$ time find /usr -name blablabla.so
real 0m38.436s
user 0m0.256s
sys 0m0.834s

Пол минуты на поиск.

Ты правда хочешь, чтобы любая программа у тебя запускалась пол минуты? Воткнул флешку, подождал пол минуты, появился значок. Кликнул на значок, подождал пол минуты, открылся файловый менеджер. Кликнул на картинку, подождал пол минуты, открылась твоя картинка. Тебе так больше нравится, да? ;)

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

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

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

Давай-ка подробнее, расскажи свой вариант иерархии файловой системы. Очень интересно. :)

anonymous
()

Ха-ха-ха!

Кто там, Луговский распинался про то, что помойка в Слаквари начинается прямо в / ?

Интересно, а как бы он отнесся к этой расчудесной инициативе горе-разрабов Федориного Горя?

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

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

Сам понял, что сказал?

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

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

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

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

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

Это всё троллейбусы из буханки.

geekless ★★
()
Ответ на: комментарий от anonymous
time find /usr -name blablabla.so

real    0m0.245s
user    0m0.129s
sys     0m0.112s

чини руки/систему

но дело даже не в этом

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

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

Как обычно, Фракталл не может облечь свою мысль в слова русского языка. А ведь задатки-то здравого ума есть. Если бы не был не умеющим разговаривать психом, авось и в люди бы вышел.

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

>Это при монолитном ядре сменил фс корня - нихрена не грузится

монолитное ядро, менял фс корня с reiserfs на ext4 - ничего не пересобирал

мораль: нужно собирать ядро с умом, а не выпиливать всё подряд ради пары сотен килобайт сэкономленной памяти

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

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

В общем это логично, все, кроме системных утилит запихнуть в отдельный каталог, тот же /opt, c подкаталогами строгой структуры:

/opt
/opt/programname
/opt/programname/bin
/opt/programname/etc
/opt/programname/lib

A в /usr/bin делать симлинки.

TGZ ★★★★
()

а отчего бы не положить в C:\Program Files\bin

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

я бы рассказал, если бы хотел

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

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

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

Э, ты что-то путаешь.

Это не мои теоретизирования, это реальный случай. Ты считаешь, что реальность что-то путает?

Я сменил фс с ext3 на reiserfs. До этого рейзера не использовал и потому при последнем обновлении ядра драйвер рейзера в initrd не вошёл (но вообще в системе он есть).

Ну и вообще в initrd те-же файлы, что и на ФС, т.е. налицо дублирование. Дублирование - это плохо (за исключени бекапов и кэшей), стало быть initrd - костыль.

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

>Во-вторых, современная GNU-система полностью управляется пакетником.

Да.

Нельзя просто отпилить кусок и сказать «а это у нас будет лежать в сети»

Вот такие убогие у нас пакетники.

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

> чини руки/систему

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

К тому же это был оптимизированный поиск - поиск конкретного файла. А ты попробуй вот так:
time find /usr -type f | wc -l

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


Вот расскажи подробнее, как это сделать-то?

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

>>Нельзя просто отпилить кусок и сказать «а это у нас будет лежать в сети»

Вот такие убогие у нас пакетники.

В Gentoo так можно. Читай про INSTALL_MASK в man make.conf

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

> /opt

/opt/programname

/opt/programname/bin


/opt/programname/etc


/opt/programname/lib


A в /usr/bin делать симлинки.



И в /etc/ симлинки? В /usr/share/man тоже симлинки делать? А в /usr/share/applications? Что будешь делать с /usr/share/icons и /usr/share/backgrounds? А /usr/lib? Что на счет /usr/include? Где еще надо создавать симлинки? Можешь полный список каталогов перечислить? Скажем, в /var/ тоже симлинки делать? В каких подкаталогах?

Будешь ли ты дублировать симлинками все файлы из /opt/programname, или только некоторые?

Как в эту схему укладывается:
$ ls -la /usr/bin/java
lrwxrwxrwx 1 root root 22 Авг 19 2007 /usr/bin/java -> /etc/alternatives/java

Как ты будешь решать проблему принадлежности каталогов? Скажем, после удаления очередного пакета каталог /usr/share/aclocal стал пустым, его уже можно удалять, или еще нет?

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

Думал, все так просто? ;)

anonymous
()

Вот это реально тред-детектор. Хоть бы постыдились некоторые рассуждать о том, чего и близко не понимают. Понахватались где-то по углам и теперь позорятся. Особенно удивляют товарищи, сидящие на всяких древних дебианах (в которых тоже не всё гладко) и орущие о ненужности развития. До вас всё равно не скоро докатится, чего волноваться-то? Или те кто кричат про несчастные будущие сервера. Можно подумать эти вещи прямо завтра в продакшн будут насильно загонять. Досадно за ЛОР как-то даже...
Всё-таки федора сейчас наиболее интересный дистрибутив. Передовой и постоянно развивающийся и предлагающий новые решения. Не всегда они удачные, но не ошибается только тот, кто ничего не делает.

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

>> А можно пример?

Это было год назад. Дублировались записи в /etc/mtab.

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



А, то есть проблема с обычным файлом /etc/mtab была только в systemd? ;)

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

> проблемы systemd спихиваешь на файл? Как всегда systemd не виноват?)
Откуда такие феерические выводы? Мне нужно было пощупать systemd, я это сделал. Решил оставить, но натолкнулся на глюк с mtab. Сделал ссылку — всё рассосалось.

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

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

не надо сваливать на файловую систему не её функцию. Очевидно,что список установленных программ, манов и прочей нечисти должен храниться в единой бд, откуда можно было бы без особого труда получить путь до нужного файла. Но вы говорите - нет, пусть лучше у нас будет большая файлопомойка, в которой черт ногу сломит. Читали недавнюю статью на хабре про make install?

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

> А, то есть проблема с обычным файлом /etc/mtab была только в systemd? ;)

Я её заметил именно с systemd, когда выхлоп mount начал показывать не совсем то, что ожидалось. И не вижу повода для твоей радости, поскольку покормить мне тебя больше нечем.

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

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

Это ты сейчас тут про реест так тонко намекаешь?

imul ★★★★★
()

/everything

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

Даешь помойку в реестре... то есть в бд! Если не ориентируешься в этой «помойке», то почитай FHS до просветления... ну или вали на венду или к макосекам.

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

Толсто же. Никто не мешает в винде прям щас делать единое деревце с логическими томами. Прост большинству оно непривычно. А быдлопроги для «геймерских» мышей вообще не знают, что винда может быть установлена не в диск С: :) Если б все зависело только от девелоперс - они давно бы хлам выпилили, о чем честно признаются в сорцах винтукея. Гугл «we are morons»

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

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

То есть каждая программа в любом случае будет регистрировать в этой базе данных все свои файлы? Дык, именно так все и сделано. Эта база данных и называется пакетным менеджером. Она хранит список установленных программ с их размещением в файловой системе. :)

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

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

Читали недавнюю статью на хабре про make install?

Нет. Я использую make install (DESTDIR=`pwd`/root) только для одноразовых проектов, которые нужно максимально урезать по месту, установив вручную только минимум, но не нужно обновлять или поддерживать.

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

> не надо сваливать на файловую систему не её функцию.

Хранить файлы — не функция ФС? Да ты гений!

Очевидно,что

Кому очевидно, тебе? Все шагают не в ногу, только ты — в ногу. Молодец.

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

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

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

Файлопомойку как раз ты предлагаешь.

Читали недавнюю статью на хабре про make install?

Ну как тут не вспомнить классическое: «Умные люди глянцевые журналы не читают, умные люди их издают.»

geekless ★★
()

Команда Fedora, не слушайте идиотов, вы на верном пути =) Так держать!

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

Он к тебе домой что ли приходит и запихивает свои поделки? Никому ничего никто не навязывает. Собирай свой LFS или генточку там или арчик и делай там что хочешь. Полно дистров где никогда не будет системд. Не надо истерик.

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

> Собирай свой LFS или генточку там или арчик и делай там что хочешь. Полно дистров где никогда не будет системд. Не надо истерик.

Назови-ка хоть один. В генточке, арчике, lfs и даже в дебиане он уже есть.

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

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

wbrer ★★★
()

Прочитал аргументы. У меня одного ощущение, что это

(1) сильно, ну очень сильно заточено под федору,

(2) фактически приведёт к тому, что что-либо кроме systemd работать толком не сможет,

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

Ну и (4) в списке есть повторяющиеся пункты. Это что, для большей убедительности?

В общем, как говорится, не смешите мои тапочки. Это приведёт только к ухудшению ситуации с совместимостью т.к. мир развлится на федору и не федору.

Вот как-то так, ИМХО

ssvda
()

Вот уж видимо других проблем в линуксе нет, что столько народу волнует структура каталогов.

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

> Всё-таки федора сейчас наиболее интересный дистрибутив. Передовой и постоянно развивающийся и предлагающий новые решения.

это не развитие, это переливание из пустого в порожнее

Некоторые системы, такие, как широко распространенная седьмая версия, все программы хранят в /bin, не имея дела с /usr/bin.

Керниган & Пайк, UPE

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

> Вот уж видимо других проблем в линуксе нет, что столько народу волнует структура каталогов.

А это как с переводом часов туда-сюда. Кинь в собаку камнем - она на камень глядеть будет.

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

>это не развитие, это переливание из пустого в порожнее

Я не буду переубеждать, но скажу, что мне сейчас изучение федоры и вот таких всяких новшеств доставляет удовольстие и развивает (надеюсь). Повторюсь, что не всегда новшества хороши, но люди обсуждают, пробуют, улучшают или держатся в стороне, кому как удобно. Просто мне не нравится, когда кричат, что Леннарт дескать всем навязывает свои решения силой. Нет этого и никогда не будет. Just for fun же.

wbrer ★★★
()

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

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

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

Но вообще проблемы затронуты серьёзные. Фундамент грызут какбэ. Поэтмоу интерес обоснован.

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

>Можно подумать эти вещи прямо завтра в продакшн будут насильно загонять.
А systemd уже зафорсили.

Не всегда они удачные, но не ошибается только тот, кто ничего не делает

Ошибаются одни, а страдают уже практически все. Обидно как-то, не находите?

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

>Пол минуты на поиск.

А теперь с locate. Предположим, что оно обновляется по inotify.

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

Гентушник это диагноз.

>Ну и вообще в initrd те-же файлы, что и на ФС, т.е. налицо дублирование. Дублирование - это плохо (за исключени бекапов и кэшей), стало быть initrd - костыль.

Давай рассмотрим вполне жизненные ситуации.

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

Предложи решение без initrd. И да, мне жалко RAM, чтобы делать allyesconfig (а с allmodconfig ядро не найдёт рут, хотя казалось бы все модули те же, что и с initrd. И в каком месте дублирование тут является костылём?).

Ну и у меня LVM, что автоматически подразумевает наличие initrd.

x3al ★★★★★
()

Очень хорошее начинание. Давно пора с этой мусоркой разобраться

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

>И в /etc/ симлинки?

Зачем? Софт найдёт свой конфиг, а искать чужие не так часто нужно.

В /usr/share/man тоже симлинки делать?

Сейчас это решается гуглем. Либо локальным поиском.

А в /usr/share/applications?

Ярлыки, как обычно.

Что будешь делать с /usr/share/icons

В некоторых альтернативных системах это вшивают в бинарники.

А /usr/lib?

Хороший повод избавиться от вечной гонки за новизной/депенденси-хэлла и выделить стандартные библиотеки (да хотя бы LSB), которые есть везде в отдельный каталог. К ним выпускать только security-апдейты. Остальное каждая программа может таскать с собой.

Что на счет /usr/include?

Отдельные пакеты с -headers, нужны немногим, остаются теми же, что и были.

lrwxrwxrwx 1 root root 22 Авг 19 2007 /usr/bin/java -> /etc/alternatives/java

В гоболинуксах это решается намного лучше, чем ваши альтернативы и eselect.

Как ты будешь решать проблему принадлежности каталогов? Скажем, после удаления очередного пакета каталог /usr/share/aclocal стал пустым, его уже можно удалять, или еще нет?

Эм. Есть список системных каталогов. Всё, что не входит в него — нафиг.

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

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

Всё решаемо.

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

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

А в оффтопиках начиная с свисты оно неубиваемо. Бэкапится, всегда есть мини rescue-система (с гуем!), которая восстановит его, все записи туда всегда проходят с местным аналогом барьеров. В реальном мире не так уж и плохо.

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