Arch Linux перемещает все исполняемые файлы в /usr/bin

Вспоминается цитата в тему:

С удивлением наблюдаю у так называемых «системных администраторов» (я сейчас не про тех, кто серийные номера Windows XP наизусть помнит) боязнь новизны или же неизвестного.
Нет, психологически-то все объяснимо, люди хотят быть узкими специалистами (следует понимать как «выучить что-то одно и всю жизнь его потом продавать»), но где вы, милые, видели, чтобы это работало? Может, в какой-то другой индустрии?
Когда программист умеет писать на пяти разных языках программирования и не боится их применять - это ничего, хороший программист, а когда системный администратор сталкивается с необходимостью обслуживать три-четыре различных системы - для него это трагедия, «зоопарк».
Нет, ну совесть надо иметь-то, ну?

Обновился. Пока полёт нормальный.

Полёт головой вниз с крыши?

Полёт головой вниз с крыши?

Если такой полёт для вас нормальный, то сами так и летайте.

Есть идея уйти от этого «устаревшего» стандарта, так инициируйте процесс обсуждения этих изменений, процесс принятия новой версии стандарта (FHS 3.0 в стадии обсуждения).

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

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

Кстати, про /usr/local/games ещё незаслуженно забыли )))

Ггг, реально, отдельный каталог для фортунок))

Ещё в /opt всякое лежит типа гугля и проприетарщины. Поэтому в /usr полюбому не всё, и PATH таки с разделителем..Ж)

+1

Количество пакетов. Которые обновляются довольно быстро и в большинстве случаев нормально работают. В openSuse есть user репы, согласен. Но допустим когда я хотел поставить codeblocks я нашел около 3-4 репов с кодеблоксом. И не понятно было где какой, с какими фишками, что туда вкомпилили, а что нет.

Плюс очень легко создать свой пакет и пропихнуть в аур. Есть достаточно много софта который мне очень не хочется ставить через make install. В той-же убунте например SFML - версии 1.6, когда версия 2.0 уже как пару лет актуальна и писать под 1.6 вообще смысла нет.

Почему бы им не запилить такую иерархию, как в GoboLinux'е?

Спасибо за детальный ответ. Но всё-же я не вижу особо причин уходить с арча. У меня он стоит уже 3-4 года и всё нормально. Конечно бывают у них спонтанные решения которые отнимают немного времени, зато плюсов у арча множество :)

К сожалению...

А зачем?

Короче говоря /sbin если я правильно понял был аналогом фряшной /rescue. Тогда тем более нафиг этот каталог, потому как идеология эта давно не соблюдается.

В своё время была такая тема, как Unix-войны, и даже если отходить от патентов и прочей дребедени, они породили кучу несовместимостей между различными версиями разных unix'ов. Благодаря этой теме просралось очень много полимеров.

Соответственно вопрос: есть стандарт, зачем отходить от него, оставляя для совместимости несколько костыликов.

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

Конечно бывают у них спонтанные решения которые отнимают немного времени

да что-то в последние 1.5-2 года только «революции» и творятся. Лучше бы более детально бы пакеты тестировали, перед тем, как из тестинга выкинуть.

Был дистрибутив, rolling-release, с достаточно свежим софтом, с редкими революциями, (пародоксально) достаточно стабильный, с простым пакетным менеджером, простой системой инициализации, удобной инфраструктурой. Этакая смесь генты и слаквари. Имхо, система для тех кому не хочется 100% компилять, при этом что-то отдельное в систему впихнуть хочется и для тех, кто не боится что-то ненароком поломать.

Сейчас же, направление движения размыто и непонятно: вроде как и больше на простых пользователей ориентироваться начинает, но чуть ли не каждое обновление стало требовать ручного вмешательства, стабильность... после одного из обновлений купса, когда выпилили автодискаверинг, об этом даже новости не было, а я не с ходу догнал, почему дома принтер на двух машинах видеться перестал. Или почему systemd не может запустить syslog-ng (при этом не говоря, никаких высеров), а если обернуть вызов syslog-ng в shell-скрипт и .service файле прописать его, тогда всё запускается? Так и олдфагам сейчас он становится менее интересен: миграция на systemd, польза от которой очень сомнительна (все говорят про эпическую скорость загрузки... у меня большинство знакомых комп включают раз в сутки, лаптопы вообще не выключатся: в сон или гибернейт уводятся), всякие отхождения от стандартов (типа этого мержинга бинарей или появления эпического /run (ну хорошо, тут больше от FDG говнецом тянет, но тоже крайне непонятная контора))

Так и олдфагам сейчас он становится менее интересен:

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

А зачем?

Выглядит красиво и аккуратно, а им все равно заняться не чем.

К тому же делает почти ненужным пакетный менеджер.

И соотносится с принципами KISS.

Сам не ковырял, но сегодня наткнулся на:

http://www.voidlinux.eu/

http://www.phoronix.com/scan.php?page=news_item&px=MTM4NDg

А вообще меня Arch устраивает более чем. Альтернатив пока не вижу.

Меня аналогично арч устраивает на все 100%. Как по мне вообще идеальный дистрибутив.

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

Когда жил на RH (5.0-7.3), у меня то, что в арче ставится через опакечивание или AUR, ставилось подобным образом в /opt/<приложуха>. Потому как меня от спеков RPM до сих пор мутит, а checkinstall, когда о нём узнал, не всегда корректно делал rpm (читать: попросту валился) :) Но возникало куча проблем, когда какая-то прога зависит от другой и приходилось задавать кучи аргументов configure для правильного поиска зависимостей.

Херня, же.

Как только что-то из тестовой поставишь, так он кучу тестовох зависимостей за собой потянет. И плакала твоя стабильная ветка.

разделение на /bin и /sbin давно уже потеряло свою суть

Тем не менее, основная масса программ, находящихся в данных местах, этому разделению соответствует. Исключения же можно пересчитать по пальцам.

Часть программ из /sbin вполне можно запустить и не от рута (если выставить соответствующие разрешения), а часть из /bin - нет (например, init.)

Это где init в /bin находится?

что «нужно на этапе загрузки системы» это initrd

Вот нахрена убирать системные программы из корневой ФС, чтобы засунуть их в нескольких копиях в большие образы, часто хранящиеся в той же корневой ФС, потребующие пересборки на каждый чих, и целиком бьющиеся от одного сбойного сектора?

И зачем всё переносить в /usr «чтоб всё было в одном месте», и с другой стороны не поддерживать отделение /usr?

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

хм, было бы странно, если бы он перемещал их в /usr/src

И зачем всё переносить в /usr «чтоб всё было в одном месте», и с другой стороны не поддерживать отделение /usr?

Отделение /usr прекрасно поддерживается, это очередная чушь. --with-rootprefix=/

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

Что мешает поставить любую инициализации вместо этой?

Эти изменения противоречат принципу иерархии файловой системы ОС Unix.

Разработчики Arch Linux хотят довести принцип KISS до абсурда ?

Arch уже давно не KISS... Теперь ещё и опсурт =)

такое решение вообще не масштабируется и пригодно разве что в случае когда кроме busybox-a больше ничего никогда небудет

причем здесь масштабирование?

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

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

на моём нетбуке обновления были раз в два-три месяца, а на двух других компах дома, получалось не чаще раза-двух в год делать обновления. И, знаешь, проблем действительно было не много: пакеты эволюционировали, революций было мало...

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

Непонятно, почему не в /bin все засунуть, это было бы логичнее. А так правильное решение.

Там же не только /bin, та ещё требухи до бога мамы, вываливать это все в / глупо, а вываливать только /bin, как-то не красиво.

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

• /usr (данные дистрибостроителя,ro),
• /etc/ (настройка,rw,nosuid,nodev,noexec),
• /var (rw,nosuid,nodev,noexec),
• /home (личные данные, rw,nosuid,nodev)

И немного липовых: типа proc, run.

Все смотрится довольно понятно. А главное не ясен юз кейс при котором старый вариант лучше.

А главное не ясен юз кейс при котором старый вариант лучше.

Ты так и не понял, что для / + /bin + /sbin в старом виде нужно менее 500Мб. Эта система работала веками 20 лет и работает до сих пор во фре, опенбсд, нетбсд, солярке. Все эти оси по дефолту по / выделяют около 500Мб. И только линукс отличился, видите ли никто нормально не мог почитать бсдяшные доки и скопировать данные в собственные мануалы. И чем это лучше той же системы, но без возможности восстановить систему из single mode?

ЛОР уже не торт.

Что ты хотел сказать то? Где юзкейс?

Сравни: http://www.openbsd.org/faq/faq4.html#Partitioning
и устаревшую доку http://www.tldp.org/HOWTO/Multi-Disk-HOWTO-21.html на которую ссылается сам дебиан http://www.debian.org/releases/stable/i386/apcs03.html.en

Тогда, н-лет назад, они знали как бить правильно диски. А потом кто-то умный решил, а давай сделаем по дефолту / и swap, просто же!

Это все круто, но где изкейс? Имя сестра, имя!!! А то ты мне напоминаешь толкователя священных писаний.

/ - root: In addition to being where the other file systems are mounted, the root file system holds all the files needed to boot OpenBSD.

В линухе этим занимется initrd (костыль на мой взгляд, но похоже без него не как).

Шит. Это тот же unix, просто линукс тольще стал за эти годы, поэтому юзкейс по разбивке аналогичный, а размеры разделов нужно увеличить. В случае линукса основной вес добляет /lib/modules, сделать для 2-3 инсталляций разных ядер размер корня в 500-600 Мб, более чем достаточно. Так что берешь инфу как бить диски для опенбсд и делаешь по аналогии и учитываешь специфуку линукса - толстые маны, толстые программы, толстые логи. Все основное сделано за тебя. Тут вот есть даже расчет в процентных значениях: http://www.openbsd.org/cgi-bin/man.cgi?query=disklabel&sektion=8 (секция AUTOMATIC DISK ALLOCATION)

В линухе этим занимется initrd (костыль на мой взгляд, но похоже без него не как).

В линуксе за это отвечал всегда /boot - 100Мб для нежадных.

Ты похоже не понимаешь слово юзкейз. Опиши в какой ситуации старая разбивка даст мне приемущества над новой.

Опиши в какой ситуации старая разбивка даст мне приемущества над новой.

Тогда, когда у тебя полетит /usr раздел и ты не сможешь ничего сделать без livecd. Раньше в такой ситуации грузился safe(single)-mode, который не монтирует ничего кроме /. Дальше ты мог использовать fdisk, cp, mv и все другие простые команды. Ты с такой ситуацией никогда не сталкивался, а вот на серверах это относительно частая проблема. Возможно ты скажешь - юзай рейд, он тебя от всего спасет, не спасет, т.к. бывают ситуации, когда нет смысла выделять рейд под систему: три диска, 1 системный, 2 уходят в рейд под данные и за счет этого система никогда не тормозит какой бы io не был на дисках с данными. И только идиоты совмещают на одном диске и данные и систему.

В линуксе за это отвечал всегда /boot - 100Мб для нежадных.

Правильно ты заметил, лор уже не торт. Беда в том, что в промышленных дитрибах ядро довольно минимально скомпилено, а все остальное в модулях, которые, сюрприз находятся не в /boot.

Дальше больше, если твой /, а с ним и /lib находятся на неком вычурном рейде или lvm, или pxe или все вместе, у тебя несколько выходов: перекомпилить ядро (что в пром дистрибах не приветствуется), раздувать загрузчик и третий путь, это initrd с модулями и бинарниками, достаточными для доступа к /.

Именно initrd выполняет ту роль, которую некогда выполнял /.

а все остальное в модулях, которые, сюрприз находятся не в /boot.

Ты плохо читаешь? Arch Linux перемещает все исполняемые файлы в /usr/bin (комментарий)

В случае линукса основной вес добляет /lib/modules, сделать для 2-3 инсталляций разных ядер размер корня в 500-600 Мб, более чем достаточно.

Дальше больше, если твой /, а с ним и /lib находятся на неком вычурном рейде или lvm, или pxe или все вместе, у тебя несколько выходов: перекомпилить ядро (что в пром дистрибах не приветствуется), раздувать загрузчик и третий путь, это initrd с модулями и бинарниками, достаточными для доступа к /.

И снова ты плохо читаешь: Arch Linux перемещает все исполняемые файлы в /usr/bin (комментарий)

три диска, 1 системный, 2 уходят в рейд под данные

Именно initrd выполняет ту роль, которую некогда выполнял /.

Скажи мне где именно находится initrd? И в каком из современных дистрибутивов он еще используется ?

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

Тогда, когда у тебя полетит /usr раздел и ты не сможешь ничего сделать без livecd.

И что? А если полетит / или initrd? Какова вероятность их выхода? Ты покрыл один редкий сценарий восстановления, который хорошо перекрывается livecd.

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

Ванга, ты чтоль? Для такого случая у меня всегда есть iLo и livecd, поскольку если уж гребанется одна из базовых fs, это как миниму повод внимательно разобраться как так получилось, и надеяться на слабый инструмент не дело.

Скажи мне где именно находится initrd?

О да, это забавная тема в линуксе, которая меня радует. Без /boot доступного для grub ничего работать не будет. Потому и говорю, что костыль.

Ты плохо читаешь?

Возможно ты плохо пишешь. Я твой поток сознания не осиливаю.

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

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

А если полетит / или initrd?

Ты спутал init и initrd. Первый действительно находится на корне, а вот initrd всегда лежал в /boot. Однако, уже во многих дистрибутивах отказались от initrd в пользу initramfs, которая также лежит в /boot. Вот тебе пруфы:

1.1 http://www.opennet.ru/base/sys/initrd_intro.txt.html
1.2 http://www.ibm.com/developerworks/linux/library/l-initrd/index.html

2.1 http://ru.wikipedia.org/wiki/Init

Как видишь в случае, когда /boot отдельно (он в таком случае вообще редко крашится), / + /bin + /sbin + /lib (но нас интересует /lib/modules) система подымется и без /usr, /var и прочих разделов. А вот что ты будешь делать когда слетит /usr вместе с /lib, который тоже теперь в /usr ? :)))