LINUX.ORG.RU

Для Fedora 17 утверждён план по переносу компонентов из корня в /usr и переход на Btrfs

 , ,


0

3

После обсуждения идеи переноса части компонентов корневой системы в /usr и объединения /sbin и /bin принято решение об утверждение планов по реализации первой идеи. Вторая идея одобрения не нашла. Обновленная структура корня будет выглядеть приблизительно следующим образом:

  • /usr - установленная система; общедоступно; возможность монтирования в режиме только чтения;
  • /etc - конфигурационные данные; локально;
  • /var - долговременные данные; локально;
  • /run - переменные данные; локально; обязательно использование tmpfs;
 /
 |-- etc
 |-- usr
 |   |-- bin
 |   |-- sbin
 |   |-- lib
 |   `-- lib64
 |-- run
 |-- var
 |-- bin -> usr/bin
 |-- sbin -> usr/sbin
 |-- lib -> usr/lib
 `-- lib64 -> usr/lib64

О преимуществах данного решения можно подробнее прочитать в предыдущей новости.

Так же принято решение об очередной попытке перехода на Btrfs в качестве основной ФС. По сравнению с прошлым планом дополнительно заявлено о решении использовать стандартные для Btrfs механизмы управления томами, вместо LVM, и организации RAID.

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

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

О переходе на Btrfs

>>> О переносе компонентов из корня в /usr

★★★★★

Проверено: anonymous_incognito ()
Последнее исправление: daemonpnz (всего исправлений: 2)
Ответ на: комментарий от Laz

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

Затем, что в предложенном тобой случае получается тот самый DLL Hell, из-за которого система становится неимоверно уязвимой, тормознутой и сильно пожирающей ресурсы. Это почти как статическая линковка, только вместо одного толстого бинарника получаем то же самое, но разнесённое внутри отдельной директории.
В случае же разнесения бинарников в одно место и библиотек и ресурсов в другие - получаем не огород или свалку, а хорошо организованную и разложенную по полочкам систему.
Яркий пример: с предложенным тобой подходом нельзя вместе установить Tremfusion и Tremulous, так как они не смогут в этом случае использовать одни и те же ресурсы - придётся городить копии, что очень нерационально и вообще сильно бьёт по удобству.

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

Laz> Не вижу проблем, я лично с ним дел не имею. Так же, как и с LD_LIBRARY_PATH.

А система - имеет. И системное окружение будет тормозить и жрать ресурсы из-за неимоверно длиннющих переменных среды.

Laz> С тем софтом, в котором жёстко прописаны пути до библиотек и бинарей. Нормальный софт к его числу не относится.

Фигушки. Нормальный софт тоже перестанет нормально собиратся. Ибо отклонение от стандарта.

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

Laz> Да, точно, можно вынести, например, /etc на отдельное устройство с reiserfs - там у меня куча мелких файлов.

Твоё дело. Только передёргиваешь тут ты.

Laz> Сейчас этим и займусь, ведь sysvinit писал не поттеринг, с этим никаких проблем не будет.

Где я о sysvinit писал? Зачем ты сюда sysvinit приплетаешь?

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

Не удосужитесь ли Вы привести источник, откуда почерпнули то, что называете фактом?

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

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

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

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

shapovalov

в конфиге второго груба черт ногу сломит

А всё потому, что конфиг grub2 напрямую редактировать не нужно.

post-factum ★★★★★
()

Федора ебанулась на отличненько.

И как теперь восстанавливать систему, если уср навернулся на другом разделе, а корень еще жив?

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

Просто до них пока ещё не дошло, что для них прогресс.

А может просто упоротые путают регресс и прогресс?

alex-w ★★★★★
()

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

alex-w ★★★★★
()
Ответ на: комментарий от Laz

ну а кто зависимости разруливать будет, если как эти придурки отказаться от бд пакетника?

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

Может быть, конечно =)

А может быть, что упоротые просто постят бесполезные сообщения на ЛОР'е.

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

1) а что для этого нужно?

бизибокс и чекалки есть в initrd

2) а что делать, если корень навернулся, а /usr жив?

3) универсальный способ восстановления системы - альтернативная загрузка с usb/cd/dvd/pxe. Можно добавить в груб загрузку рескуй-образа.

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

Рано хороните. Мы пока умирать не собираемся =)

Ай, таких закапывальщиков в каждом треде пруд пруди. :)

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

Я всегда поддерживал идею давать в качестве капчи два абзаца текста и вопрос на их содержание.

tmp_bot_175
()

Анонимные аналитики голосуют ногами...

Есть такой тип голосования - ногами. Мне лично совершенно не нравится, что творится в федоре. Тут юниксом уже и не пахнет. Какие-то придурки полуграмотные там рулят. Поэтому придется голосовать ногами - просто посносить эту хрень кругом и наплевать в палитру. Глядя на дерьмовую полу-живую 9-ку я уже, было дело, решился все посносить, потом вроде как-то все успокоилось, а теперь опять начинается дурдом. 16-й практически пользоваться невозможно. Сплошной глюк. 17-я будет еще хлеще, как видно. Вместо выпиливания багов - сплошные революции тупой школоты на пустом месте... Тьфу!

Так шо нафиг редхет и иже с ними со всех моих сетапов, пока не поздно.

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

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

Люди GNOME-OS клепают.

По мне дак: Флаг в руки и барабан на шею.

Вот только-бы остальным не говнили.

<TROLL>И «сексуальные проблемы» fedora/gnome на linux.org.ru, скорее всего, обсуждать уже не нужно. Это УЖЕ не UNIX-like. И не POSIX. И не BSD. Это уже - нечто «самостийное, вильное и незалежное». Пусть себе где-нить в другом месте пасется.</TROLL>

sergv
()

Всю ветку не читал, может уже и был этот вопрос: через время это ждет и Red Hat/CentOS?

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

в конфиге второго груба черт ногу сломит, раньше было проще.

От только ненадо про груб2. И вобще - там другой принцип построения конфига. Ман, намекает, что grub.conf вручную править вобще не желательно. Вместо этого пихаем свои скриптики в /etc/grub.d (по крайней мере в дебьяне/убунте) и радуемся жизни.

Grub2 крут, еще бы его помержили с burg :)

KennyMinigun ★★★★★
()

а я поддерживаю обе идеи! чем проще будет система тем легче ее продвигать в массы

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

а я поддерживаю обе идеи! чем проще будет система тем легче ее продвигать в массы

Система становится не проще, а тупее. Что до масс, то им глубоко фиолетово что там в корне, где /usr и переход на Btrfs, они таких сло и не знают.

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

чем проще будет система тем легче ее продвигать в массы

1) Использование неотлаженной файлухи - это есть упрощение?

2) Свалка из бинарников (которые раньше были в (/usr|/usr/X11R6)?/bin) в одном месте - это есть упрощение?

3) А GNOME нужно «продвигать в массы»? Настолько глюкавое поделие уже никуда нельзя продвинуть.

sergv
()

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

Я смотрю лавры Патрика кого-то в Красношапке мучают ночными кошмарами.

void_ptr ★★★★
()

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

self-learningMACHINE
()
Ответ на: комментарий от alpha

Да, стимулировали. http://dir.gmane.org/gmane.comp.file-systems.btrfs

А федора-то тут причем? Вы уж сразу на kernel.org ткните, чтобы не мелочиться.

А слабо пойди да посмотреть, какая работа делается в реальности и кем именно? В том числе как обстоит дело с той же fsck. Статистику по коммитам например?

Так не закоммитили ничего - на что смотреть-то? Ткните, пожалуйста.

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

Как с луны прямо... Есть такая волшебная старая штука - почтовая рассылка. У всех дистров там основная активность. Или форум. Или даже в ирку можно задвигать идеи.

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

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

/tmp может и должен остаться отдельной точкой монтирования. В дебиане идиотов не любят.

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

Два чая этому господину.

Вообще интересно было бы узнать мнение менее эмоциональных товарищей по поводу всех этих «великих перемен». По мне так masturbatory renaming в полный рост.

А встроенные системы на то и встроенные, чтобы иметь свою специфику, причём вовсе не обязательно одну на всех.

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

Вы уж сразу на kernel.org ткните, чтобы не мелочиться.

Это был такой сарказм? Вы вообще немножко почитайте о том, кто и разработкой чего занимается в мире Open Source.

http://www.h-online.com/open/features/Kernel-Log-An-analysis-of-Linux-kernel-...

The authors also looked into which developers review the code of other kernel hackers before it gets integrated into the kernel – these are mostly the subsystem maintainers. The greatest number of reviews in the currently evaluated period were done by David S. Miller, who maintains the network, IDE and SPARC code. He's followed by John W. Linville (WLAN) and Greg Kroah-Hartman (USB, Staging, Driver Core) as well as Andrew Morton, who handles all kernel areas.

The authors related these figures to the employer figures, which showed that almost 38% of the code is handled by Red Hat developers. Novell came second with over 13%, followed by Intel with just over 9%. In this evaluation, the unaffiliated hobbyists only contributed just under 5%.

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

Это был такой сарказм? Вы вообще немножко почитайте о том, кто и разработкой чего занимается в мире Open Source.

Не вырывайте из контекста. Я задал вполне конкретный вопрос - зачем Вы привели вполне конкретную ссылку на мейллист btrfs?

Я должен узнать оттуда, что большинство ключевых девелоперов ее работают в Oracle? Спасибо, это итак многие знают. Меня интересует - при чем здесь федора?

Второе. Ссылка на коммиты будет - или Вы просто отбрехались «иди туда, не знаю куда»?

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

Жду не дождусь, когда уже все конфиги запихают в ~/.config.


Какая разница, где помойке быть? ~/.config/SomeShit принципиально ничем не лучше ~/.SomeShit

Такая, милый хомячок, что если ты захочешь забэкапить все конфиги накопленные годами, то надо будет сделать только tar -c ~/.config | bzip2 > /net/backup/conf.tbz2.

А вообще, надо тупо перенести директории с / или /usr в хомяк (можно скрытые). Что б получилось так:

~/etc ~/bin ~/lib ~/doc ...

Lego_12239 ★★
()

Лично меня затрахали личности использующие для квотирования «<<-----Цитата----<<». Явно быдлоxml не только снижает понятность конфигурации, не только загружает простаивающие мощности процессоров, не только является серебряной пулей для всего, но и необратимо поражает кору и, даже, сердцевину межушного ганглия неосторожных пользователей.

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

У меня в initramfs есть fsck, оттуда я лечу другие разделы (и корень тоже могу подлечить, если что). А больше ничего особенного отдельный корень не умеет. Вот у меня другая история есть - я очистил таблицу разделов. И как мне тут отдельный корень помог бы? Даже если бы я смог в него загрузиться, testdisk всё равно лежит на /usr. В общем, в случаях серьёзнее «после непланового ребута побилась фс и он не может примонтировать часть разделов» от отдельного корня толку никакого.

Вот, ты тормоз. Сказали же, про монтирование по сети /usr.

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