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

Зачем /usr/bin/awk? Что-то мешает написать «#!/bin/awk»?

А у меня awk и так в /bin. Ты это у мандривоводов спроси

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

>это проблема systemd

Проблемы systemd - это проблемы systemd, я про нее вообще не говорил. Просто de-facto разница между /usr/bin и /bin (и /lib & /usr/lib, соответственно) стирается (а в той же федоре и разницы между bin и sbin нет: «разделение на /bin и /sbin в любом случае бессмысленно уже пару версий Fedora, поскольку оба каталога включены в переменную $PATH для всех пользователей»). А если не видно разницы, зачем держать 4 разных места?

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

> Просто de-facto разница между /usr/bin и /bin (и /lib & /usr/lib, соответственно) стирается (а в той же федоре и разницы между bin и sbin нет: «разделение на /bin и /sbin в любом случае бессмысленно уже пару версий Fedora, поскольку оба каталога включены в переменную $PATH для всех пользователей»). А если не видно разницы, зачем держать 4 разных места?

Действительно, на*рена спрашивается, борщ, котлеты и компот подавать в разной посуде?! Ведь, всё-равно всё смешается!

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

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

с симлинками уже некуда будет монтировать

естественно это всё не про десктоп, где терабайтные винты, оффтопик на другом разделе и пр.

sllxxe
()

>Леннарт Поттеринг
этот тот, что придумал пульс?
он же создатель systemd
его говно не работает - виновата иерархия директорий...
у него ЧСВ не сильно ли зашкалило?
да гнать нахер этого дурачка подальше!

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

>с симлинками уже некуда будет монтировать

Щито? Где такую траву выдают? Гиклеса выше прочитай - просто в таком случае initrd должен будет монтировать не только корень, но и /mnt. Усе.

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

Проблемы systemd - это проблемы systemd

А кроме него, проблем со /usr ни у кого нет. В той же федоре, правила udev мирно лежат в /etc, конфиги долбаного systemd - в /etc и /lib, альса на этапе загрузки не нужна, всяческие pulse/NM стартуют после монтирования всех ФС.

no-dashi ★★★★★
()
Ответ на: комментарий от redgremlin

>разделение на /bin и /sbin в любом случае бессмысленно уже пару версий Fedora, поскольку оба каталога включены в переменную $PATH для всех пользователей
зачем /sbin в $PATH простого юзверя?
у меня это 181 чисто рутовая команда

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

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

Сейчас, если, скажем, сгорит сервер, линукс-систему можно восстановить имея список пакетов и бакап каталога /etc. Такой бакап делается мгновенно и восстановление из него довольно простое. Если у каждой проги конфиги будут в своем каталоге - как предлагаешь делать бакап этих конфигов?

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

То есть отказываемся от унифицированной системы документации, так? Каждая программа должна иметь собственный велосипед, и в комплекте с программой find должна идти своя программа man-find, в комплекте с diff свой man-diff, а в комплекте с patch свой man-patch. Ты этого хочешь?

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

Ярлыки где? Кто будет знать, где именно лежат эти ярлыки? Кто будет их создавать при установке программы, кто будет их удалять при удалении/обновлении?

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

То есть в каждой Qt-программе свой Qt, в каждой GTK-проге своя библиотека GTK. То же самое с Tk, wxWidgets, SDL, Motiff и т.д. А xlib тоже каждая программа с собой тащить будет. А может и Х-ы свои с собой принесет? А что с alsa/pulse - их тоже каждая прога будет с собой тащить?

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

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

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

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

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

Где есть этот список? Ты вообще сейчас о чем?

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

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

Всё решаемо.

Да, стандарт FHS и пакетный менеджер описывают лучшее возможное решение. Ничего лучше представлено не было.

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

> Много ли на линуксе реально хороших программ, которые я не могу поставить в оффтопик?

Да, много. Собственно, почти все. Когда в винде появится единый интерфейс управления видеовводом (аналог v4l) чтобы я мог любым плеером его смотреть и писать, а не только тем единственным, что идет в комплекте с тюнером, когда там появятся вменяемое рабочее окружение (Gnome/KDE) с поддержкой рабочих столов, нормальным управлением окнами, которые можно закрепить поверх или зафиксировать их расположение при запуске, когда в винде будет хотя бы нормальный пакетный менеджер с автоматическим разрешением зависимостей и автоматической загрузкой и установкой недостающих компонентов - тогда и приходи, поговорим.

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

дааа, давай ещё и $PATH костылить на /mnt/bin
я не курю, я нуб. но по крайней мере я это признать могу

sllxxe
()

Наконец-то хоть кто-то не побоялся осуществить довольно серъёзную перемену, т.к. уже давно пора пересмотреть некоторые аспекты т. наз. «Unix», заменив старые подходы на более современеные.

soko1 ★★★★★
()

а как они fsck собираются запускать ?

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

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

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

> Всё-таки федора сейчас наиболее интересный дистрибутив.

Школьникам? Понимаете, некоторым людям Linux нужен для работы. Вас это шокирует?

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

Пример удачного можно? И с чего Вы взяли, что в Debian не предлагают никаких «новых решений» (=> «ничего не делают»)? Обоснуйте, пожалуйста.

мне сейчас изучение федоры и вот таких всяких новшеств доставляет удовольстие и развивает (надеюсь)

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

Просто мне не нравится, когда кричат, что Леннарт дескать всем навязывает свои решения силой. Нет этого и никогда не будет.

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

PS: Не знаю, цитировал ли кто - но вот обсуждение в рассылке Debian'а: http://lists.debian.org/debian-devel/2011/10/msg00157.html

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

>Наконец-то хоть кто-то не побоялся осуществить довольно серъёзную перемену, т.к. уже давно пора пересмотреть некоторые аспекты т. наз. «Unix», заменив старые подходы на более современеные.

перемена ради перемены, без другого смысла? no way.

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

> Затем, что без этого будет ОЧЕНЬ плохо с коммерческим софтом.

Игрушек нет? Бедный школьник...

Примерно как сейчас.

А что _сейчас_ мешает Вам запустить пераццкую коммерческую программулину из отдельного каталога (а-ля виндовс)?

Так что весь нужный Вам функционал имеется. Увы, не видно что это как-то связано с «плохо» у коммерческого софта. Сдается мне, Вы где-то переложили с больной головы на здоровую...

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

>Кто тебе мешает держать в /boot спасательный initrd типа Tiny Core?

а кто мешает оставить стандарт в нормальном состоянии ?

и откуда /boot ? он внутри / и кто тут слоупок ?

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

Полностью согласен с вами. Например: а что если Systemd починят, и он станет корректно работать с отдельным /usr? т. е. тогда нельзя будет уже /usr вынести? Все в одной свалке будет?
А так уже пускай делают что хотят. Главное чтоб ничего не сломали, и не сделали только хуже. + потом расхлебывать это не пришлось

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

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

жирная флешка? А 256 м - это какая? Для эмбедед это в 30 раз больше того, что нужно.

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

лучше сделать так

/Program Files /Program Files (x86)

Некошерно ибо пробелы и верхний регистр.

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

Про mkfs сказали выше - создавать образы в хомяке никто не запрещает. fsck - то же самое. sysctl, lsmod и т.д. информацию исправно выдают. Специально прятать sbin смысла нет.

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

> *fsck*, rmmod, sysctl, mkfs*, init и т.д. это программы простого пользователя? о_О

mkfs.{vfat,ntfs,ext4} — да, как минимум. Или «простой пользователь» флэшки форматировать нынче уметь не должен, для этого сисадмин нужен? fsck туда же, если для них GUI нарисуют.

(Вопрос прав на устройство прекрасно решается правилами udev.)

А sysctl давно не нужен, уже сто лет как изобрели /proc и /sys. Которые, кстати, обычный пользователь(tm) умеет, в меру разумных ограничений, читать.

Остальное — да.

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

Ну и она заработала и что?

А если ты такой продвинутый пользователь, что на ней фс хочешь сменить, то напишешь /sbin/mkfs, ну если ты этого не знаешь, то может тебе флешку не стоит форматировать ;)

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

>mkfs.{vfat,ntfs,ext4} — да, как минимум. Или «простой пользователь» флэшки форматировать нынче уметь не должен, для этого сисадмин нужен? fsck туда же, если для них GUI нарисуют.

Ну как минимум пользователь должен быть в курсе какую фс выбрать, чтобы флешка не сдохла через неделю. Так что «простой пользователь» нынче не умеет. ;)

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

> перемена ради перемены, без другого смысла? no way.

FHS/LFS давно просятся к переделке. Ибо для большого ряда систем банально неактуальны (а бородатые дядьки все равно сделают все так, как им надо — выносят же они /usr сейчас на отдельную партицию, например)

Глобально переделать все это пробовали (см. GoboLinux) — не взлетело. С одной стороны было много спорных моментов, с другой — не осилили все поддерживать, с третьей — не хватило пиара. В один чих традицию не поломать, в общем, независимо от того, плоха она или хороша. Поэтому начинают с малого — то отдельный /run, то /bin'ы склеят.

Глядишь, лет через 50, и догонят идеи мертвого, но вечно живого Plan 9.

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

> в настоящий момент можно было бы расширить

список утилит в /bin и /sbin с учетом потребностей людей


ППКС.

Не только расширить список но и держать всякие базы id 'шников для udev и пр, на корне. И вообще нафиг РЕШИТЬ ПРОБЛЕМУ.

И проблема не в том что /bin - /sbin ненужен а в том что функционал СЛОМАЛИ и не апдейтали в соответствие с веяниями времени. Если кому то нужен
gpg или screen в корне, это нужно обеспечить. Я бы например очень был бы рад там screen и mc. А еще больше был бы рад возможности как держать там screen так и от него избавится при необходимости.

Короче предлагаю двинуть альтернативную движуху. ВЕРНУТЬ ВОЗМОЖНОСТИ КОТОРЫЕ У НАС БЫЛИ И РАСШИРИТЬ ИХ!

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

> Ну как минимум пользователь должен быть в курсе какую фс выбрать, чтобы флешка не сдохла через неделю. Так что «простой пользователь» нынче не умеет. ;)

Это не то. Речь, как я понимаю, о «простом» пользователе, как противоположности «привелегированному» (суть root'у). Физически это, зачастую, один и тот же человек. У Вас трудности с выбором ФС для флэшек?

А если речь вести о «простом пользователе» Марьивановне Бухгалтерской, то ей вообще консоль противопоказана, какая речь может идти про /bin и /sbin?

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

<sarcasm fat=«yes»>Точно, давайте вообще $PATH отменим. /bin/bash, /opt/android-sdk/bin/adb, что там мелочиться. Если пользователь продвинутый то он напишет.</sarcasm>

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

> вася, юзай свой дебиан и не обращай внимания

на прогресс десктопных дистрибутивов


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

Тут дискуссия четко разделилась на тех кто пользовался возможностями корня на отдельном разделе, чиня как десктопы так и серверы, и чмо которые не пользовались потому что вендузятники, а линукс у них только чтобы попи***ть на ЛОР.

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

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

А ты разбивай. Кто мешает-то?

Бинарники в системе ценности не представляют - они накатываются с любого репа, если побьются.

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

Кстати, о бесперебойниках - журналируемые файловые системы таки рулят.

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

>Пример удачного можно?

Удачные патчи в gcc. Удачно интегрированный xen. Наконец-то удачный selinux.

Много чего они делают удачного и капитализация на рынке как бы намекает.

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

>Вижу много тех, кто в глаза systemd не видел, но осуждает После крякающего и тормозящего pulseaudio, конечно (и не с его ли помощью проэксплуатировали ядро 2.6.30?). Поделки одного автора. Вполне справедливо после этого его и осуждают.

хотя ни к какому продакшену отношения не имеет вообще например.

За продакшн я рад. Хотелось бы самому так (хотя проскакивали новости, что и на сервера эту поделку впендюрят. Или уже?) А вот с десктопами ситуация удручающая. Вообще плохо всё это: раз опенсорс, значит каждая дефективная поделка нуба Пупкина обязательно оставит огромную воронку уже в том, что до этого работало, и работало хорошо. Выход один — собирать всё самому. Что я и сделал, плевав на все эти pulseaudio, systemd и прочих зомби всяких поттеров. «Создайте систему для идиотов, и только идиоты будут ей пользоваться.» Вы на верном пути.

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

sudo? o_O
спасибо - кушай сам
но опять же - зачем мне по табу видеть миллион команд, которые мне де факто не доступны как пользователю?

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

>При том, что с помощью NTFS Junction Points можно монтировать любые разделы в каталоги на NTFS.

Можно. Только почему эта сволочь запрещает заходить в каталог, если устройство, которое в него монтируется, отсутствует?

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