это называется субьективно

Я имел в виду «а факты таковы, что…» :)

мне действительно интересно услышать доводы

В рамках одного быстрого сообщения трудно передать всё, что копилось годами :) То, что «в последних твоих темах я не видел серьёзных проблем» мало о чём говорит. Ибо, во-первых, пишу я далеко не о каждой проблеме, а только когда совсем уже нагорит, во-вторых, это не только последние темы, впервые вопрос «Куда катится Gentoo» я начал задавать года два назад (ещё в комментах), а первую тему подобную поднял в конце 2009-го: Чего бы б такое пощупать на замену Gentoo?

С тех пор ситуация только ухудшается.

Но, не раз отмечал, что хотя Gentoo тут особенно ударна, тенденция характерна и для Linux-сообщетва в целом. Пока искал первую жалобу на Gentoo, вспомнил старую тему: Упс. Я не понял. rlocate сносят??

Как, на сегодня так и не вернулся locate, работающий на inotify?

udev, compiz уже сегодня обсудили. KDE4, Gnome3… Под Linux становится всё менее комфортно. Если лет 5 назад я перелезая с Windows на Linux испытывал реальное чувство комфорта, а работать в Windows после Linux было просто противно, то сегодня разница уже минимальна. Можно неделями работать в первой загруженной ОС. И нивелированию этому послужило не улучшение Windows (хотя отчасти это тоже есть), а деградация Linux :-/

не ну в целом здраво и понятно, но всё же ж нужно отделять мух от котлет.

Но, не раз отмечал, что хотя Gentoo тут особенно ударна, тенденция характерна и для Linux-сообщетва в целом.

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

про компиз.. судя по словам мегабакса он таки развивается, да и выпилен не был несмотря то, что уже 2 месяца с lastrite message прошло.

Как, на сегодня так и не вернулся locate, работающий на inotify?

А с чего бы ему вернуться-то.. ну не знаю почему никто не написал locate работающий на notify с ядром >=2.6.64. Автор на него забил судя по homepage ещё в 2005, по моему совершенно не удивительно, что его снесли. И да это действительно не gentoo, а linux в целом.. или правильнее свободный софт в целом.. Хочешь я тебе напишу hslocate на inotify, правда в зависимостях у него dev-lang/ghc будет? А программа через какое-то время будет в haskell-overlay.

ладно в общем ясно

Под Linux становится всё менее комфортно. Если лет 5 назад я

Уже не тот... Трава была зеленее... сахар слаще...

Это в каком месте systemd не соблюдает FHS?

Главным образом, в мечтах анонимусов ЛОРа.

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

Я полагаю, следует разделить на два каталога. В один всё, что часто используется в скриптах: sh, бинарники coreutils, awk, grep, sed и т.п. В другой всё остальное. Для чего — для ускорения выборки по первому каталогу.

а все остальные в /usr/libexec, где они сейчас и лежат.

Вообще-то они в /usr/lib, в основном, валяются. /usr/libexec — это «непризнанный» каталог.

Если так разбираться, то ФС можно разделить на 2 части (не считая всяких /dev, /proc, /sys, /tmp и /home): на неизменную (/usr) и на меняющуюся (/var).

Ты зачем /etc съел?

Как, на сегодня так и не вернулся locate, работающий на inotify?

Хороший вопрос. Неужели за 4 года аналог никто не запилил?

Вообще-то они в /usr/lib, в основном, валяются. /usr/libexec — это «непризнанный» каталог.

В Генте же есть libexec. А в других дистрибутивах просто запускают configure с --libexecdir=/usr/lib. Разница небольшая — пофиг, куда спрятать от пользователя исполняемые файлы, которые он не должен сам запускать, но мне больше нравится именно /usr/libexec, потому что тогда они не перемешиваются с динамическими библиотеками.

Ты зачем /etc съел?

В /var/etc его. Тогда можно будет провернуть мегакрутую штуку: избавиться от корневой системы на диске вообще. Корневая ФС будет в tmpfs, к ней монтируются /usr, /var и /home с диска, а также виртуальные /proc, /sys, /dev, tmpfs в /tmp. А чтобы было не обязательно делать этому всему хозяйству (/usr, /var, /home) 3 отдельных раздела, можно заюзать subvolumes в каком-нибудь btrfs.

В /var/etc его.

Ты что-то не то съел. :} Раздел, на котором /etc (теоретически) можно смонтировать в ro, и это может много где пригодиться. А ты его в /var, жестоко и несправедливо.

Тогда можно будет провернуть мегакрутую штуку: избавиться от корневой системы на диске вообще. Корневая ФС будет в tmpfs

Это сделать и сейчас ничего не мешает. Кажется, еще в кноппиксе был / в tmpfs.

к ней монтируются /usr, /var и /home с диска, а также виртуальные /proc, /sys, /dev, tmpfs в /tmp

/etc это отдельная логическая сущность. /usr, /var, /etc, /home — у каждой из них своё предназначение.

Можно сделать такой скрипт в initrd, который читает из параметров загрузчика не имя корневого устройство, как сейчас, а имя устройства с /etc. Монтирует /etc, читает оттуда какой-нибудь /etc/initialfstab, монтирует по этому конфигу остальные куски системы. Ничего невозможного.

В /var/etc его. Тогда можно будет провернуть мегакрутую штуку: избавиться от корневой системы на диске вообще.

А откуда ядро будет узнавать, как монтировать /etc?

А откуда ядро будет узнавать, как монтировать /etc?

Из параметров загрузчика.

Не обращайте внимания, я принял веществ

А можно сделать в initrd скрипт, монтирующий поочередно все разделы на предмет наличия в них /etc/initialfstab и дающий возможность выбрать, откуда именно из найденного грузить систему.

Раздел, на котором /etc (теоретически) можно смонтировать в ro, и это может много где пригодиться. А ты его в /var, жестоко и несправедливо.

Ну да, что-то не то получается. Просто отдельный раздел под /etc, который занимает метров 10, мне показался странным решением. Но если использовать btrfs subvolumes, то всё нормально, потому что отдельные подтома не ограничиваются в размере, а занимают столько места от раздела, сколько нужно.

Надо будет провернуть такое в каком-нибудь дистрибутиве.

А можно сделать в initrd скрипт, монтирующий поочередно все разделы на предмет наличия в них /etc/initialfstab и дающий возможность выбрать, откуда именно из найденного грузить систему.

o_O Это уже получается какой-то граб вместе с ос-пробером.

Не обращайте внимания, я принял веществ

ок

Можно сделать такой скрипт в initrd, который читает из параметров загрузчика не имя корневого устройство, как сейчас, а имя устройства с /etc. Монтирует /etc, читает оттуда какой-нибудь /etc/initialfstab, монтирует по этому конфигу остальные куски системы.

Даже отдельный initialfstab не нужен — сойдёт же и обычный fstab. Можно, кстати, сделать так, как я делал в своей initramfs (которая /usr монтирует), чтобы fstab записывался прямо в неё.

Просто отдельный раздел под /etc, который занимает метров 10

Ну один черт после завершения переноса бинарников в /usr у нас так и остаётся по факту — десятиметровый корень с одним только /etc.

o_O Это уже получается какой-то граб вместе с ос-пробером.

«GRUB3 will be elisp serialized as xml jited to jvm running as eclipse plugin on a mac running in a virtual pc in a xen instance on a 286er.»

Больше веществ!

Еще я тут подумал, зачем нам модули ядра в /usr? (Они ж там окажутся после мерджа бинарников из корня.) Меня всегда эта нелогичность напрягала — само ядро в /boot, а модули от него в корне.

Между ядром и системой у нас стабильный API, а внутри каждой из них — страх, ужас и кровавые ошметки. Есть две высокоуровневых логических сущности:
1. Ядро + стартовый код в initrd + модули ядра, если ядро собрано с ними.
2. Система GNU, работающая поверх.
Одно ядро может использоваться в разных системах. Разные ядра могут использоваться для загрузки одной и тоже системы. Юзкейзы безграничны.

Выносим модули ядра в /boot/lib!

Код в initrd будет монтировать /boot/lib, и у нас всегда будут доступны правильные модули, независимо от того, в какую систему мы загрузились.

Выносим модули ядра в /boot/lib!

О, вот это правильно. А то я постоянно забываю скопировать модули, когда хочу загрузить убунту с ядром из Генты. Только надо каталог как-то по-другому назвать, чтобы понятнее было. Например, в /boot/kernels/modules будут подкаталоги для модулей, а в /boot/kernels — ядра со всем хозяйством типа initrd.

А где интересно настраиватся этот путь до модулей?

А где интересно настраиватся этот путь до модулей?

Модули загружаются insmod'ом из любого места. В случае их загрузки modprobe их ищет последний, значит, надо как-то настроить module-init-tools. В худшем случае их надо пропатчить, а в лучшем у них есть настройки.

Для этого придумали /home/$USER

Нет, мои данные независимы от системных файлов всех видов и мусора.

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

Я просто сношу весь /.

Там не только мусор, какбэ. Конфиги имакса, фокса, некоторых других программ.

И? Это не отменяет остальной мусор.

А когда udev уже будет зависеть от systemd?

Выносим модули ядра в /boot/lib!

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

Я говорил гипотетически в контексте перелопачивания FHS. Т.е. шляпа сама первая и приведёт всех насильно к светлому будущему, никто не уйдёт обиженным. :-D

Ну в самом деле, после мерджа бинарей в /usr, модули ядра там нахрен не уперлись.

в нём убрана возможность работы с /usr на отдельном разделе

Ты сам свою копипасту читал?

if you have /usr on a separate partition, you must boot your system with an initramfs which pre-mounts /usr

Чего ныть, не понимаю.

избавиться от корневой системы на диске вообще

Ты изобрёл android, tinycore и ещё пару других нестандартных дистров.

Так я ж не шутил. Я ж одобряэ, но уточняэ.

Не, со стороны генты такую инициативу не протолкнуть. Вот если её поттерингу подбросить, тогда...