В связи с волной необоснованной критики Леннарт Поттеринг (Lennart Poettering) подготовил (http://0pointer.de/blog/projects/the-usr-merge) сводный документ (http://www.freedesktop.org/wiki/Software/systemd/TheCaseForT...), в котором обобщил мотивы переноса содержимого /bin и /lib в директорию /usr в грядущем релизе Fedora 17, а также опроверг наиболее часто встречающиеся мифы. По словам Поттеринга новое унифицированное расположение исполняемых файлов и библиотек внутри раздела /usr (содержимое /bin планируется перенести в /usr/bin, /sbin в /usr/sbin, /lib в /usr/lib и /lib64 в /usr/lib64) более совместимо с UNIX, чем практикуемый в Linux подход с разделением на /bin и /usr/bin (в SysV Unix /bin является симлинком на /usr/bin).
Некоторые плюсы переноса компонентов из корня в /usr:
- В настоящее время разные дистрибутивы Linux и Unix-системы по разному формируют состав /bin и /usr/bin. Перенос всех исполняемых файлов в /usr/bin и наполнение /bin через символические ссы...URL: http://0pointer.de/blog/projects/the-usr-merge
Новость: http://www.opennet.ru/opennews/art.shtml?num=32914
А всё необходимое для начальной загрузки я так понимаю он предлагает совать в initrd?! Тогда в топку такие его идеи.
Кого "его"? Поттеринг здесь вообще не при чем (о чем и написано в его блоге ангельским по белому).P.S. Идею запихать все в /usr придумали совсем другие люди, а Поттеринг всего лишь обеспечил работоспособность сей идеи в systemd (впрочем, systemd точно так же работает и с "классической раскладкой" диска).
> А всё необходимое для начальной загрузки я так понимаю он предлагает совать в initrd?!Между прочим
1. initrd для этого и предназначен.
2. оно все уже давно туда засунуто, иначе бы система не грузилась.
>> А всё необходимое для начальной загрузки я так понимаю он предлагает совать в initrd?!
> Между прочим
> 1. initrd для этого и предназначен.
> 2. оно все уже давно туда засунуто, иначе бы система не грузилась.Лично у меня не везде initrd вообще используется. И лучше бы он вообще почти нигде не использовался.
> Лично у меня не везде initrd вообще используется. И лучше бы он
> вообще почти нигде не использовался.К моему ручки-то не тяни!?
> Лично у меня не везде initrd вообще используется.Это ваши половые трудности.
> И лучше бы он вообще почти нигде не использовался.
Лучше бы ваши религиозные взгляды не нашли широкого распространения.
initrd - гибкое и эффективное решение, и нет смысла от него отказываться ради чьей-то необоснованной фобии.
> Это ваши половые трудности.Некоструктивный тезис.
> initrd - гибкое и эффективное решение, и нет смысла от него отказываться ради чьей-то необоснованной фобии.
Это гибкий, в каком-то смысле эффективный, но костыль. Самый настоящий костыль, если подумать как оно работает. Да, он работает, но нельзя сказать, что решение это элегантное. Без него нельзя жить? Вон, во FreeBSD как-то и без initrd хорошо живётся. Другими словами, более простых и надёжных решений несколько штук придумать вполне можно.
И нет, это не "фобия". Это скорее неприязнь нагромождений и костылей. Я люблю когда система проста как гвоздь и молоток. И отсюда антипатия в том числе и к Поттеренговскому набору. Все эти pulseaudio (думаю уже каждый натерпелся), зависимости на dbus (отдельная тема для холивара), логи читаемые только специальными утилитами у меня вызывают просто отвращение, но я их не боюсь.
Я с пульсом не натерпелся. Как работал, так и работает.
Более того, я с удовольствием транслирую звук по сети с ноутбука на большую машину (подключенную к усилителю и колонкам), когда смотрю фильмы на диване.Я что-то сделал не так?
>с ноутбука на большую машинуА на большой машине включить фильм не судьба? :) Или у тебя дармовая электроэнергия?
> Или у тебя дармовая электроэнергия?ох чорт! пойду проверю не забыл ли я выключить свет в туалете!!!
:-D :-D
Могли бы и природе позаботиться, если что.
>> Это ваши половые трудности.
> Некоструктивный тезис.
>> initrd - гибкое и эффективное решение, и нет смысла от него отказываться ради чьей-то необоснованной фобии.
> Это гибкий, в каком-то смысле эффективный, но костыль. Самый настоящий костыль, если
> подумать как оно работает. Да, он работает, но нельзя сказать, что
> решение это элегантное. Без него нельзя жить? Вон, во FreeBSD как-то
> и без initrd хорошо живётся.Во FreeBSD "хорошо живётся" за счёт того, что загрузчик выполняет сравнимую функциональность достижением файлов модулей с малого количества известных FS.
UFS, ZFS, NFS и пожалуй всё. Да, он может там и конфиги прочесть, и модули, и загрузить их. А для писателей на Форте ещё и вкусности доступны. Но условия несравнимы.
Initrd - значительно более универсальное решение, хотя за него и плата (в большинстве исполнений это хрень столь же загадочная как BIOS - или сработала, или нет, а лезть внутрь - это требуется сработавшая загрузка).BTW, FreeBSD умеет initrd (только он зовётся mfsroot), и этим пользуются - для запусков в сложных условиях, или тот же инсталлятор запускается именно в нём.
> Другими словами, более простых и надёжных
> решений несколько штук придумать вполне можно.Например?
> И нет, это не "фобия". Это скорее неприязнь нагромождений и костылей. Я
> люблю когда система проста как гвоздь и молоток. И отсюда антипатия
> в том числе и к Поттеренговскому набору. Все эти pulseaudio (думаю
> уже каждый натерпелся), зависимости на dbus (отдельная тема для холивара), логи
> читаемые только специальными утилитами у меня вызывают просто отвращение, но я
> их не боюсь.Ну initrd всего этого не требует.
Простите, а зачем тогда корневой раздел ?
Пользовательский и т.д. ?
Это в FreeBSD есть.
Всё же, корневой (mount point - /) и пользовательский
(mount point - /usr) разделы были не зря придуманы.
Например, ту же флешку с корневым разделом не плохо
иметь... так, на всякий случай...
> initrd — гибкое и эффективное решение…которое, тащемта, не нужно. достаточно просто собирать ядро под железяку. в 90 как минимум прочентах случаев (число с потолка) вообще достаточно впилить в ядро поддержку пары файловых систем (не модулями, в смысле), чтобы необходимость в initrd пропала.
initrd нужно только если хочется сделать «одно универсальное ядро для всех». но зачем? собственно, давно назрела необходимость в программе, которая проинспектирует железо и сгенерирует конфиг ядра, где некоторые самые нужные модули будут впилены жёстко, просто нужные — модулями, а остальное вообще отключит нафиг. вот у меня ядро пересобирается пять минут (реально, пять минут). а «дистрибутивный» конфиг — где-то пол часа, если не больше.
> …которое, тащемта, не нужно.Ты еще расскажи что 640 кило хватит всем. Initrd позволяет взлететь с крайне хитровыгнутой стартовой площадки. Другие методы - когда как. Что? Втолкать все в ядро? Не модулями? А благородный дон в курсе что некоторые из архитектур имеют жесткие лимиты на размеры неких областей? И утолкать тудя супержирное ядро может и не получиться.
> ядро поддержку пары файловых систем (не модулями, в смысле), чтобы необходимость
> в initrd пропала.А ты распишешься за _все_ платформы, архитектуры и загрузочные конфигурации, чтобы делать столь глобальные выводы? Или у тебя тоже синдром админа локалхоста вылез - мол, раз я не юзаю, значит никому это не надо?
> initrd нужно только если хочется сделать «одно универсальное ядро для всех».
Знаешь, если продолжить ту же логику - модули вообще зря изобрели. Надо было вкомпиливать вообще все 100500 дров в одну монолитную чушку. А модули - туда же куда и рамдиски.
> но зачем? собственно, давно назрела необходимость в программе, которая проинспектирует
> железоИ ты конечно готов написать такую программу... эээ, стоп, а как я ее буду запускать на какойнить там железке где допустим MIPSовый проц с допустим u-boot'ом? А может, с redboot'ом? Как мне предлагается такую программу до установки системы запустить, интересно? Ты готов это родить под все существующие загрузчики? :)
> и сгенерирует конфиг ядра, где некоторые самые нужные модули будут
> впилены жёстко, просто нужные — модулями, а остальное вообще отключит нафиг.Слушай, на писюке никому не вперлось экономить целый мег памяти путем таких ужимок и прыжков, а на других архитектурах твой подход может создать больше проблем чем решить.
> вот у меня ядро пересобирается пять минут (реально, пять минут). а
> «дистрибутивный» конфиг — где-то пол часа, если не больше.А у меня весь initrd перестраивается за 20 секунд. В гробу я видал кайф ждать вместо 20 секунд 5 минут.
>> …которое, тащемта, не нужно.
> Initrd позволяет взлететь с крайне хитровыгнутой стартовой площадки.кагбэ не помню, чтобы я с этим спорил. правда, какая религия запрещает собрать кастомное ядро для этой площадки — не ясно. раз она такая хитрая — почти наверняка это эмбедовка. а под эмбедовки нормальные люди собирают кастомные ядра с минимумом всего, потому что там обычно ресурсов и так не шибко много.
> Втолкать все в ядро? Не модулями?
кагбэ ты не поверишь, но достаточно «втолкать» драйвера для дисков и для корневой fs. всё остальное ядро отлично подтянет уже с диска (или другого носителя, не суть важно).
> А благородный дон в курсе что некоторые из архитектур имеют жесткие лимиты на размеры неких областей? И утолкать тудя супержирное ядро может и не получиться.
ты странное бинарное существо. или «всё модулями» или «всё монолитом». попробуй расширить кругозор.
> А ты распишешься за _все_ платформы, архитектуры и загрузочные конфигурации, чтобы делать
> столь глобальные выводы?что, есть какая-то платформа, под которую ядро можно собрать *только* с условием взлёта с initrd? жду примера тогда. не гипотетического, если что.
> Знаешь, если продолжить ту же логику — модули вообще зря изобрели. Надо
> было вкомпиливать вообще все 100500 дров в одну монолитную чушку. А
> модули — туда же куда и рамдиски.это не «та же логика», это твои личные глюки, которые ты с какого-то испугу приписываешь мне. разбирайся с ними сам.
> И ты конечно готов написать такую программу…
угу. за деньги.
> эээ, стоп, а как я ее буду запускать на какойнить там железке где допустим MIPSовый проц с допустим u-boot'ом? А может, с redboot'ом?
ты прямо на этой железке и собираешь ядро? месье знает толк в извращениях.
> Как мне предлагается такую программу до установки системы запустить, интересно?
зачем? лучше запусти сначала свой мозг. если у тебя неизвестная зверушка от непонятного вендора — ты ССЗБ, и нестандартный секс тебе обеспечен в любом случае.
> Ты готов это родить под все существующие загрузчики? :)
а зачем? не видел ни одного идиота, который попытался бы пересобрать ядро прямо на роутере, например. подозреваю, что такие существа умирают намного раньше — в силу фатального дефекта головного мозга.
> Слушай, на писюке никому не вперлось экономить целый мег памяти путем таких
> ужимок и прыжковмне — «впёрлось». и память, и время пересборки ядра. а ты — лжец, поскольку «никому» подразумевает, что и мне тоже.
> А у меня весь initrd перестраивается за 20 секунд.
так ты ещё и не знаешь разницы между генерацией initrd и пересборкой ядра? круто. ну, сделай свои «20 секунд», когда обновляешь ядро, угу. впрочем, ты сейчас начнёшь говорить, что я красноглаз, и все «нормальные люди» берут ядра из пакетов своих дистрибутивов.
>>> …которое, тащемта, не нужно.
>> Initrd позволяет взлететь с крайне хитровыгнутой стартовой площадки.
> кагбэ не помню, чтобы я с этим спорил. правда, какая религия запрещает
> собрать кастомное ядро для этой площадки — не ясно.Сравни затраты по времени и прочему на сборку ядра и на компоновку нескольких файликов уже скомпиленного в один тарболл.
Религия - не мешает. Мешает - разумная лень.С другой стороны, про особенности initrd надо постоянно помнить. Например, не забывать ему скормить указание на хитрые драйвера, LVM и тому подобное, если автоматом это не доработано (сплошь и рядом натыкаюсь на такое).
> кагбэ ты не поверишь, но достаточно «втолкать» драйвера для дисков и для
> корневой fs. всё остальное ядро отлично подтянет уже с диска (или
> другого носителя, не суть важно).Увы, всё сложнее. Где-то надо конфиг подложить, где-то драйвера промежуточных шин...
>> А ты распишешься за _все_ платформы, архитектуры и загрузочные конфигурации, чтобы делать
>> столь глобальные выводы?
> что, есть какая-то платформа, под которую ядро можно собрать *только* с условием
> взлёта с initrd? жду примера тогда. не гипотетического, если что.Я такое видел. При старте ядра настраивался доступ к сетевому корню, вбивалось пару static route (да, это уже идиотизм конкретной местности), уточнения параметров infiniband драйвера и специфические параметры для монтирования корня. Автоматом оно там в принципе не запускалось, ибо ядро не знает, что и как вылавливать и корректировать из ответа DHCP.
Идею вписывать эти правила в код ядра, пожалуйста, не предлагать.> зачем? лучше запусти сначала свой мозг. если у тебя неизвестная зверушка от
> непонятного вендора — ты ССЗБ, и нестандартный секс тебе обеспечен в
> любом случае.Угу. И в случае возможности собрать для этого комплект userland'а с каким-нибудь даже перлом внутри нестандартный секс резко облегчается.
>> Ты готов это родить под все существующие загрузчики? :)
> а зачем? не видел ни одного идиота, который попытался бы пересобрать ядро
> прямо на роутере, например. подозреваю, что такие существа умирают намного раньше
> — в силу фатального дефекта головного мозга.А при чём тут "прямо на раутере"?
>> А у меня весь initrd перестраивается за 20 секунд.
> так ты ещё и не знаешь разницы между генерацией initrd и пересборкой
> ядра? круто. ну, сделай свои «20 секунд», когда обновляешь ядро, угу.Зачем?
> впрочем, ты сейчас начнёшь говорить, что я красноглаз, и все «нормальные
> люди» берут ядра из пакетов своих дистрибутивов.Ну в чём-то это так. Я тоже вот красноглаз (ну, не я, а контора), ибо свои ядра, но это таки рабочая задача.
> Сравни затраты по времени и прочему на сборку ядра и на компоновку
> нескольких файликов уже скомпиленного в один тарболл.
> Религия — не мешает. Мешает — разумная лень.если это ядро нужно один раз — да. если постоянно — я лучше соберу его нормально один раз.
> Увы, всё сложнее. Где-то надо конфиг подложить, где-то драйвера промежуточных шин…
это всё принципиально не кладётся на носитель и не настраивается в сонфиге ядра (конфиг для модуля? в /etc? O_O)
>>> А ты распишешься за _все_ платформы, архитектуры и загрузочные конфигурации, чтобы делать
>>> столь глобальные выводы?
>> что, есть какая-то платформа, под которую ядро можно собрать *только* с условием
>> взлёта с initrd? жду примера тогда. не гипотетического, если что.
> Идею вписывать эти правила в код ядра, пожалуйста, не предлагать.не предлагаю. это, пардон, какое-то мегаизвращение вообще.
> Угу. И в случае возможности собрать для этого комплект userland'а с каким-нибудь
> даже перлом внутри нестандартный секс резко облегчается.если это неведома зверушка, то с большой долей вероятности в «универсальном» ядре или чего-нибудь не хватит, или что-нибудь окажется лишним и так далее. к тому же сей случай подпадает как раз под «универсальное ядро с initrd», против которого я ничего не имею.
> А при чём тут «прямо на раутере»?
слабо представляю не-роутер с redboot, например. к тому же оппонент прыгает с темы на тему как ушибленый между лап заяц.
>> ядра? круто. ну, сделай свои «20 секунд», когда обновляешь ядро, угу.
> Зачем?ты не в курсе, зачем обновляют ядра? O_O
> Ну в чём-то это так.
на самом деле ситуацию с «универсальным ядром» я считаю неверной, вот и всё. какой смысл иметь ядро в исходниках и не подтачивать его под своё железо?
действительно, программа-конфигуратор, которая после загрузки дистриба обнюхает железяки и сформирует нужный конфиг была бы весьма удобна. в принципе, в ней даже можно считерить немного: если загружено «универсальное» ядро — глянуть на вывод lsmod.
а вообще — да, там должен быть список соответствий железяк и драйверов, опции для грубой и тонкой настройки разных вещей типа netfilter и так далее. короче, такой «конфигуратор ядра с человеческим лицом». но я лично не готов заниматься написанием и поддержкой, мне проще сконфигурировать ядро руками и потом просто делать make oldconfig, включая по пути новые плюшки из консоли.
платить же за подобный софт (за разработку, i mean) никто не станет, потому что «пересборка ядра для школьников-гентушников и красноглазых фанатиков, ололо!» а это совсем не так ведь. пичалька.
> действительно, программа-конфигуратор, которая после загрузки дистриба обнюхает железяки и сформирует нужный конфиг была бы весьма удобна. в принципе, в ней даже можно считерить немного: если загружено «универсальное» ядро — глянуть на вывод lsmod.make localyesconfig/localmodconfig ?
> make localyesconfig/localmodconfig ?да, это база, в принципе. но я имел в виду нечто более приятное для обычного пользователя, с возможностью порулить настройками как в виде «поставь галку, если хочешь использовать то-то» до возможности индивидуально галки расставлять. с рюшечками, гуи-свистелками и так далее. чтобы «я пересобрал ядро под своё железо» было не arcanum art, а рутинной и вдобавок автоматизируемой операцией. и делалось, в принципе, в процессе установки дистрибутива.
яростно плюсую каждый абзац. в принципе ты тему закрыл, не знаю что добавить.
>>что, есть какая-то платформа, под которую ядро можно собрать *только* с условием взлёта с initrd? жду примера тогда. не гипотетического, если что.Была такая задача, система грузиться с усб-флешки:
1) Ядро взлетает с помощью сислинукса (+впиленный в ядро инитрд)
2) Передает управление инитрд, а тот ПРОСТО ждет (sleep 1 в бесконечном цикле), пока не подцепится эта самая усб-флешка самим ядром.
3) После, как подцепилась усб-флешка, с нее монтируется в лууп корень и передается управление иниту.
4) Профит...Может подскажете, глубокоуважаемый гуру, как сделать то же самое без инитрд?.. ;)
> Может подскажете, глубокоуважаемый гуру, как сделать то же самое без инитрд?.. ;)jmp $
> А ты распишешься за _все_ платформы, архитектуры и загрузочные конфигурации...Есть такое мнение, которое я поддерживаю: скрещение ужа с ежом даёт бесполезный кусок колючего г-на. Даже если мобильных применений Линукса на порядки больше десктопных, это не повод делать десктопный линукс таким же убогим, зато "универсальным". Вобщем-то, всё это - плата за Трольвадский "for fun", который ниструя не позаботился о будущем. Ну так зачем тогда рвать ж**у за какие-то универсальные идеалы?? Нужен тупо линукс для десктопа со всеми сопутствующими особенностями:
RAM можно точно ожидать не меньше 512Мб. Хард - от 50Гб (с учётом SSD). Сеть и Тырнет - опциональны и ни в коем случае не должны подразумеваться как единственный источник обновлений. Дисплей и клава обязательны, мышь - по вкусу. Тогда можно получить хорошо заточенную архитектуру, которая не будет приносить проблем 90% юзеров из-за того, что какой-то ЁПРСТ-моторс суёт линуксы под капот.
>> initrd — гибкое и эффективное решение
> …которое, тащемта, не нужно. достаточно просто собирать ядро под железяку.Это недистрибутивно и имеет больше шансов вылезти боком при смене железки, в которую воткнут корень.
Что мне не нравится во всей этой истерии, так это смешение относящихся, не относящихся и относящихся не тем боком доводов в одну большую кучу, не подлежащую осмысленному обсуждению.
>> достаточно просто собирать ядро под железяку.
> Это недистрибутивно и имеет больше шансов вылезти боком при смене железки, в
> которую воткнут корень.одно другому не мешает. emergency ядро с kitchen sink лежит себе отдельно, а работает собраное под железяку.
наберись опыта и практики, а потом уже заявляй безапелляционно, что система без initrd не загрузится.
>> А всё необходимое для начальной загрузки я так понимаю он предлагает совать в initrd?!
> Между прочим
> 1. initrd для этого и предназначен.
> 2. оно все уже давно туда засунуто, иначе бы система не грузилась.Только вот проблема - чтобы обеспечить эквивалент по удобству ремонта (да-да, это не enterprise случай), тот initrd должен содержать как минимум полноценный шелл и возможность его вызвать.
Все правильно. Только название "usr" сбивает с толку, к юзеру это не имеет никакого отношения.
смысл имеет:
/bin /lib /sbin - системный софт, необходимый для загрузки и базовый функционал.
/usr/bin /usr/lib - под функционал, доставляемый администратором/пользователем системы
> Все правильно. Только название "usr" сбивает с толку, к юзеру это не имеет никакого отношения.конечно, не имеет - ведь это всегда означало "Unix System Resources"
Кстати в оригинальном AT&T Unix /usr выполняла роль /home
Сам придумал или у таких же в википедии прочитал?/lib наверно Linked Interprocess Binary ?
/home - Here Of My Executables
/boot - Be Out Of True
>> Все правильно. Только название "usr" сбивает с толку, к юзеру это не имеет никакого отношения.
> конечно, не имеет - ведь это всегда означало "Unix System Resources"
/sbin/init куда положим?
> /sbin/init куда положим?Вон выше написали: / -> в initrd, /usr -> теперь /
Вот куда засунуть старый initrd?? В UEFI, наверное...
> Вон выше написали: / -> в initrd, /usr -> теперь /Походу, вы текста не читали. / -> /usr, а initrd без изменений, т.к. он изначально самодостаточен.
initrd живёт в /boot
Новости о Поттеринге всегда одни и те же: он опять обосновал, почему нужно что-то куда-то перенести или что-то поломать...
> Новости о Поттеринге всегда одни и те же: он опять обосновал, почему
> нужно что-то куда-то перенести или что-то поломать...Это прогресс, детка :)
>> Новости о Поттеринге всегда одни и те же: он опять обосновал, почему
>> нужно что-то куда-то перенести или что-то поломать...
> Это прогресс, детка :)Это фэйк, детка. Словесами ошибочно выдаваемый за якобы прогресс.
>>> Новости о Поттеринге всегда одни и те же: он опять обосновал, почему
>>> нужно что-то куда-то перенести или что-то поломать...
>> Это прогресс, детка :)
> Это фэйк, детка. Словесами ошибочно выдаваемый за якобы прогресс.Это именно прогресс - FHS становится всё лучше и удобнее.
Интересно, появится всё-таки обоснованная критика улучшений FHS, или в её существование по прежнему надо свято верить?
> Это прогресс, детка :)Тасовка карт в колоде прогрессом не является.
> Тасовка карт в колоде прогрессом не является.Комментирование на форуме - тоже.
А вот слияние перенос /bin в /usr/bin - безусловно является. Почему именно - объяснено в статье.
И да, нахрена /usr/bin, /usr/sbin, /bin, /sbin... Особо бесит, когда в PATH по дефолту нет /sbin.
Ну так поправьте .yourshellrc, в чём проблема?
> Особо бесит, когда в PATH по дефолту нет /sbin.О да, это определённо является причиной слить /sbin и /usr/sbin. Не смотря на то, что если в PATH нет /sbin, то и /usr/sbin там обычно тоже нет. Пофиг что можно просто поправить конфиги, лучше всю систему перелопатить.
> И да, нахрена /usr/bin, /usr/sbin, /bin, /sbin
У них разные функции, см. FHS.
> Пофиг что можно просто поправить конфиги, лучше всю систему перелопатить.Всё для apt-get-kiddies. закончится всё одним разделом, /linux /program_files, файлом подкачки и скачкой rpm с интернет помоек.
>> И да, нахрена /usr/bin, /usr/sbin, /bin, /sbin
> У них разные функции, см. FHS.что-то мне подсказывает что дальше вики дело не двинется, а мнение не поменяется.
> И да, нахрена /usr/bin, /usr/sbin, /bin, /sbin... Особо бесит, когда в PATH
> по дефолту нет /sbin.По секьюрити. Не?
>> И да, нахрена /usr/bin, /usr/sbin, /bin, /sbin... Особо бесит, когда в PATH
>> по дефолту нет /sbin.
> По секьюрити. Не?Не. Ничто не мешает пользователю поместить в PATH что угодно.
>> По секьюрити. Не?
>Не. Ничто не мешает пользователю поместить в PATH что угодно.Ничто не мешает поставить запрет на запуск из $PREFIX/sbin всем, кроме отдельно взятых пользователей.
>>> По секьюрити. Не?
>>Не. Ничто не мешает пользователю поместить в PATH что угодно.
> Ничто не мешает поставить запрет на запуск из $PREFIX/sbin всем, кроме отдельно
> взятых пользователей.RBAC уже реализован в пингвине? Хоть в каком-нибудь? С профилями выполнения?
>>>> По секьюрити. Не?
>>>Не. Ничто не мешает пользователю поместить в PATH что угодно.
>> Ничто не мешает поставить запрет на запуск из $PREFIX/sbin всем, кроме отдельно
>> взятых пользователей.
> RBAC уже реализован в пингвине? Хоть в каком-нибудь? С профилями выполнения?Оно как-бы и не обязательно для такого запрета. man 5 group
> RBAC уже реализован в пингвине? Хоть в каком-нибудь? С профилями выполнения?И давно. Раз осилили четыре буквы для повторения -- идите-ка да читайте и дальше сами.
> Ничто не мешает поставить запрет на запуск из $PREFIX/sbin всем, кроме отдельно
> взятых пользователей.Это вообще никак не связано с содержимым переменной PATH.
Хотя твоё знание man group меня восхитило, молодец.
>> И да, нахрена /usr/bin, /usr/sbin, /bin, /sbin... Особо бесит, когда в PATH
>> по дефолту нет /sbin.
> По секьюрити. Не?Нет. Чисто для удобства тех, кто работает в консоли, плюс ма-а-аленький прирост производительности при запуске исполняемых файлов без указания абсолютного пути.
>НеобоснованнойДа что вы говорите?!
>В настоящее время разные дистрибутивы Linux и Unix-системы по разному формируют состав /bin и /usr/bin
Да. И что это повод прогибаться под коммерческие системы a-la макос или солярки ?
Надо использовать позитивный опыт, - это да, - но пока оснований для такого я вот не вижу. Если уж так надо сблизится, то почему не прогнуть хомячков макоси? Или пользователей некоммерческого линукса не жалко?>что позволит упростить организацию бездисковых систем
Вот и делайте отдельную версию дистра для них. И причем здесь серверная (да и десктопная тоже) ось?
>Упрощение формирования гостевых окружений для систем виртуализации
Вот с этого и надо было начинать! То есть Поттеринг (читай, - редхат) вздумал над линуксоидами поэксперементировать ради своего перспективно-облачного направления! Вот в это я верю!(((
> Да что вы говорите?!Да. А вы можете привести пример обоснованной критики сабжа?
Именно критики, а не панических воплей по поводу придуманных на ходу страшных сказок.> Да. И что это повод прогибаться под коммерческие системы a-la макос или солярки ?
У них сделано лучше и удобнее, чем в линуксе. Это повод.
> Вот и делайте отдельную версию дистра для них. И причем здесь серверная (да и десктопная тоже) ось?
Сделайте свой дистрибутив, и устраивайте в нем зоопарк версий. А в нормальных дистрах ориентируются на унификацию.
> Вот с этого и надо было начинать! То есть Поттеринг (читай, -
> редхат) вздумал над линуксоидами поэксперементировать ради своего перспективно-облачного
> направления! Вот в это я верю!(((Вы утверждаете, что виртуализация нужна только редхату, да? :)
>> Да. И что это повод прогибаться под коммерческие системы a-la макос или солярки ?
> У них сделано лучше и удобнее, чем в линуксе. Это повод.Таки ви в этом уверены? Вы уважаемый походу ни разу с макосью не связывались.
Там установка текстурпака на майнкрафт вызывает определённые затруднения из за неимоверной кривизны тамошней файловой системы, не говоря уж о более сложных вещах.
>> Да что вы говорите?!
> Да. А вы можете привести пример обоснованной критики сабжа?http://lwn.net/Articles/431111/ и в частности -- на http://lwn.net/Articles/431215/ Леннарт, замеченный в треде под ником mezcalero, так и не ответил (может, времени не хватило, а может, вопрос был по существу).
Думаю, многих вменяемых админов возмутило нарушение принципа "работает -- не трогай", причём методом напролома.
> Именно критики, а не панических воплей по поводу придуманных на ходу страшных
> сказок.Типа "половина наших других погремушек не тестировалась толком с отдельным /usr и нам лениво собрать свои пакеты по-человечески, а не через /dev/arse"? (это про то, когда на самом деле корни "проблемы" уходят в кривые редхатовские сборки pulseaudio, udev, совершенно второстепенных хелперов и задействованных ими библиотек откуда попало)
Слайды (больше -- на http://tinyurl.com/rhbz-separate-usr):
https://bugzilla.redhat.com/show_bug.cgi?id=463168
https://bugzilla.redhat.com/show_bug.cgi?id=558960>> Да. И что это повод прогибаться под коммерческие системы a-la макос или солярки ?
> У них сделано лучше и удобнее, чем в линуксе. Это повод.Вы сами-то их пробовали? Я вот совершенно не удивлён тому, что большинство коммерческих *nix передохло под напором линукса.
> Сделайте свой дистрибутив, и устраивайте в нем зоопарк версий. А в нормальных
> дистрах ориентируются на унификацию.К сведению тех, кому не по нутру такие новости и особенно "обоснования": http://lists.altlinux.org/pipermail/devel/2012-January/19304...
> Вы утверждаете, что виртуализация нужна только редхату, да? :)
Ещё vmware, да. :]
> Слайды (больше -- на http://tinyurl.com/rhbz-separate-usr):грамотно.
Считаю его идею достаточно прогрессивной, так как достигается унификация, выигрыш будет очень значительным на бездисковых рабочих местах и в разных средах для виртуализации. Пример с соляркой подтверждает.Противникам: есть такой дистр, зовется Calculate, у него обновление так и производится: обновляем рут-раздел, если прокатило - после перезагрузки рут-раздел будет сменен на обновленный, в случае чего можно будет откатить все назад. Если все ок - следующий раз будет использоваться старый рут-раздел. В данном случае все будет гораздо проще (нету костыля, который это делает), и без перезагрузки.
> обновляем рут-раздел, если прокатило - после перезагрузки рут-раздел будет сменен на обновленныйИ как вы узнаете, что прокатило? а то ведь может показаться, что прокатило, а после перезагрузки - что не прокатило :)
Да пребудет с Вами великий mount.
> Да пребудет с Вами великий mount.Валяй, набери приличную маунт-команду на сериальной консоли энтерпрайз-сервера без ошибок, когда шелл без всяких обвязок даже автокомплита не дает сделать, и хистори отсутствует, а тебя в ж.пу клюет большой начальник "Стартуй сервер, сцук, немедленно, сейчас 15-00, а не то твою шкурку гвоздями 100 на заднем дворе приколотим к стенке!".
Админы локалхоста такие админы...
> Валяй, набери приличную маунт-команду на сериальной консоли энтерпрайз-сервера без ошибок,
> когда шелл без всяких обвязок даже автокомплита не дает сделать, и
> хистори отсутствует, а тебя в ж.пу клюет большой начальник "Стартуй сервер,
> сцук, немедленно, сейчас 15-00, а не то твою шкурку гвоздями 100
> на заднем дворе приколотим к стенке!".А почему набор команды кажется тебе непосильной задачей?
Ты не умеешь читать или печатать?
спроси у разработчиков calculate.... я пользовался их дистром - мне понравилась сама идея, все четко и по полкам.
>Пример с соляркой подтверждает.Солярка, на сколько мне помнится позволяет откатываться снепшотами. Хотя при этом таки структура каталогов помогает.
>В данном случае все будет гораздо проще (нету костыля, который это делает), и без перезагрузки.
Кстате, интереса ради. unmount/mount там же (в /usr) лежать будут?
>>Пример с соляркой подтверждает.
> Солярка, на сколько мне помнится позволяет откатываться снепшотами. Хотя при этом таки
> структура каталогов помогает.Не для рутового пула.
>>В данном случае все будет гораздо проще (нету костыля, который это делает), и без перезагрузки.
> Кстате, интереса ради. unmount/mount там же (в /usr) лежать будут?Ага, два раза.
То они выпиливают /var/run в корень, теперь они запиливают все в /usr
Как нить ночью обновишься, а все что было в /var сейчас в корне
А все из корня в /usr
Как вам /usr/root, /usr/dev, /usr/proc, /spool, /log
Не ходи за Поттеринга,
Ничего хорошего.
Утром встанешь, /usr набок,
А /sbin взъерошена.
+1 : Маразм менять в устаканеной системе расположение каталогов из-за пары-тройки приложений. IMHO такая система отходит постепенно от UNIX-way.
> +1 : Маразм менять в устаканеной системе расположение каталогов из-за пары-тройки приложений.
> IMHO такая система отходит постепенно от UNIX-way.Если бы ты удосужился прочитать текст новости, которую комментируешь, то понял бы почему именно ты сказал полную чушь.
> +1 : Маразм менять в устаканеной системе расположение каталогов из-за пары-тройки приложений.
> IMHO такая система отходит постепенно от UNIX-way.От unix-way уже давно отошли:
$ ldd /sbin/iptables
linux-gate.so.1 => (0x0064a000)
libiptc.so.0 => /usr/lib/libiptc.so.0 (0x00b61000)
libxtables.so.2 => /usr/lib/libxtables.so.2 (0x00b58000)
libm.so.6 => /lib/libm.so.6 (0x00b26000)
libc.so.6 => /lib/libc.so.6 (0x009b0000)
libdl.so.2 => /lib/libdl.so.2 (0x00b51000)
/lib/ld-linux.so.2 (0x0098b000)Это 10 федора, Поттеринг еще в школу ходил. В /sbin статические бинарники, говорите, ась? И без /usr это заработает, ась?
$ ldd /sbin/iptables
linux-vdso.so.1 => (0x00007fff0fdff000)
libip4tc.so.0 => /lib64/libip4tc.so.0 (0x00007fbcd98ad000)
libip6tc.so.0 => /lib64/libip6tc.so.0 (0x00007fbcd96a5000)
libxtables.so.7 => /lib64/libxtables.so.7 (0x00007fbcd9499000)
libc.so.6 => /lib64/libc.so.6 (0x00007fbcd910e000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fbcd8f0a000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbcd9ab4000)Учись выбирать правильный дистибутив.
аналогично
> $ ldd /sbin/iptables
> linux-gate.so.1 => (0x0064a000)
> libiptc.so.0 => /usr/lib/libiptc.so.0 (0x00b61000)
> libxtables.so.2 => /usr/lib/libxtables.so.2 (0x00b58000)
> libm.so.6 => /lib/libm.so.6 (0x00b26000)
> libc.so.6 => /lib/libc.so.6 (0x009b0000)
> libdl.so.2 => /lib/libdl.so.2 (0x00b51000)
> /lib/ld-linux.so.2 (0x0098b000)правильно, сначала мы наверзаем в /sbin, а потом, вместо того, чтобы вычистить каку, заметем его под /usr
> И без /usr это заработает, ась?Запросто
$ ldd /sbin/iptables
linux-gate.so.1 => (0xb7891000)
libip4tc.so.0 => /lib/libip4tc.so.0 (0xb7865000)
libxtables.so.4 => /lib/libxtables.so.4 (0xb785d000)
libc.so.6 => /lib/libc.so.6 (0xb7705000)
libdl.so.2 => /lib/libdl.so.2 (0xb7700000)
/lib/ld-linux.so.2 (0xb7892000)
>> +1 : Маразм менять в устаканеной системе расположение каталогов из-за пары-тройки приложений.
>> IMHO такая система отходит постепенно от UNIX-way.
> Это 10 федора, Поттеринг еще в школу ходил. В /sbin статические бинарники,
> говорите, ась? И без /usr это заработает, ась?[/usr]/sbin последнее время были не статические, а такие, которые не-админу нафиг не сдались.
> От unix-way уже давно отошли:
> $ ldd /sbin/iptables
> libiptc.so.0 => /usr/lib/libiptc.so.0 (0x00b61000)[...]
> Это 10 федора, Поттеринг еще в школу ходил. В /sbin статические бинарники,
> говорите, ась? И без /usr это заработает, ась?Ну не все ж такие, как редхат.
$ ldd /sbin/iptables
linux-gate.so.1 => (0xb7723000)
libip4tc.so.0 => /lib/libip4tc.so.0 (0xb76ff000)
libxtables.so.5 => /lib/libxtables.so.5 (0xb76f7000)
libc.so.6 => /lib/libc.so.6 (0xb7593000)
libdl.so.2 => /lib/libdl.so.2 (0xb758e000)
/lib/ld-linux.so.2 (0xb7724000)
$ rpm -qf /sbin/iptables
iptables-1.4.10-alt1
$ _
однозначно поддерживаю +1 или даже +100реально это будет гораздо лучше и удобнее
> Успокойтесь, я не хочу холиварить обоснованная критика или нет, но автор не
> имеет право в новости судить об этом, :). Говоря "необоснованная" он
> лишь навязывает своё мнение, а не пересказывает факты. Это неэтично, просто.Он именно пересказывает факты - обоснованной критики не-бы-ло.
>> Успокойтесь, я не хочу холиварить обоснованная критика или нет, но автор не
>> имеет право в новости судить об этом, :). Говоря "необоснованная" он
>> лишь навязывает своё мнение, а не пересказывает факты. Это неэтично, просто.
> Он именно пересказывает факты - обоснованной критики не-бы-ло.Любое мажорное изменение всегда неприятно. Всегда нужна какая-то адаптация к новым условиям. А востребованность в адаптации - это всегда плохо. Вопрос о том насколько это целесообразно - это уже отдельный вопрос, любой ответ на который всегда будет строго субъективным. Обоснованная критика или нет, определяется тем, целесообразно терпеть эти изменения или нет. И целесообразно или нет, как я уже сказал, вопрос субъективный. Т.ч. никто не имеет право заявлять однозначно обоснованная то была критика или нет.
> Любое мажорное изменение всегда неприятно. Всегда нужна какая-то адаптация к новым условиям.Ничего подобного. Например изменения о которых говорит Поттеринг приятны и не требуют никакой адаптации.
> И целесообразно или нет, как
> я уже сказал, вопрос субъективный. Т.ч. никто не имеет право заявлять
> однозначно обоснованная то была критика или нет.Это технический вопрос, а не философский. Целесообразность определяется плюсами, подробное описание которых есть в статье Поттеринга.
И обоснованность критики также определяется техническими специалистами, работающими над поддержкой и улучшением дистрибутивов. Одним из которых и является Поттеринг.
> Например изменения о которых говорит Поттеринг приятны и не требуют никакой адаптации.Врёте. См. выше ссылки на lwn.
"Возможность использования нескольких разделов /usr для загрузки разных версий или состояний дистрибутива, например, в процессе обновления можно сохранить старое содержимое в отдельном разделе и вернуться на него в случае проблем."А как тогда быть с /home/.* ? Врядли все конфиги софта будут совместимы с разными версиями этого же софта.
> А как тогда быть с /home/.* ? Врядли все конфиги софта будут
> совместимы с разными версиями этого же софта.Это необоснованная критика!!! /home/ должен быть на одном разделе с /usr Но об этом решено было тактично умолчать.
> А как тогда быть с /home/.* ? Врядли все конфиги софта будут совместимы с разными версиями этого же софта.Если автор софта ломает совместимость конфига, но при этом не меняет его имя/расположение - за такое надо бить по сусалам.
Это не решит проблему. Такое происходит чаще чем хотелось бы, и даже среди вполне серьезного софта. И будет происходить.
> Если автор софта ломает совместимость конфига, но при этом не меняет его
> имя/расположение - за такое надо бить по сусалам.dovecot любит менять опции в конфиге, предлагаете наделать тыщу конфигов? а если у меня конфиг не умолчательный, а довольно хитрый, что делать установщику, пытаться мой конфиг сконвертить или воткнуть умолчательный?
> "Возможность использования нескольких разделов /usr для загрузки разных версий или состояний
> дистрибутива, например, в процессе обновления можно сохранить старое содержимое в отдельном
> разделе и вернуться на него в случае проблем."
> А как тогда быть с /home/.* ? Врядли все конфиги софта будут
> совместимы с разными версиями этого же софта.Точно так же, как и сейчас - либо использовать софт, у авторов которого хватает ума не ломать конфиги, либо сипользовать несколько домашних разделов или снэпшотов одного раздела.
>> "Возможность использования нескольких разделов /usr для загрузки разных версий или состояний
>> дистрибутива, например, в процессе обновления можно сохранить старое содержимое в отдельном
>> разделе и вернуться на него в случае проблем."
>> А как тогда быть с /home/.* ? Врядли все конфиги софта будут
>> совместимы с разными версиями этого же софта.
> Точно так же, как и сейчас - либо использовать софт, у авторов
> которого хватает ума не ломать конфиги, либо сипользовать несколько домашних разделов
> или снэпшотов одного раздела.Ты где снэпшоты на UFS/EXTx нашел, поделись травой? Пару карманов насыпь?
> Ты где снэпшоты на UFS/EXTx нашел, поделись травой? Пару карманов насыпь?Научись читать:
1. ext нигде не упоминается.
2. значение союза "либо" - представление альтернативы.
> Ты где снэпшоты на UFS/EXTx нашел, поделись травой? Пару карманов насыпь?при чем тут, в обсуждении линуха, ufs - не понятно, но все же: что вы курили, когда решили что в уфс нет снапшетов?
> использовать софт, у авторов которого хватает ума не ломать конфигиТ.е. "не нужно" во весь рост? Пардон, не катит.
> сипользовать несколько домашних разделов
В большинстве случаев это лишний геморрой или невозможно.
> или снэпшотов одного раздела.
В большинстве случаев это лишний геморрой или невозможно.
> В большинстве случаев это лишний геморрой или невозможно.ниасилил? :)
ну дык это уж точно не Поттеринга проблемы.
Я-то осилил. Но на десктопах, да еще и для преконфигуренных дистров это гемор или нерационально.
> Я-то осилил. Но на десктопах, да еще и для преконфигуренных дистров это гемор или нерационально.Никто вроде бы и не заставляет. Прелесть в том, что это возможно, причём после реализации приложений по улучшению FHS это будет возможно без жутких костылей. И все этим плюшки - совершенно "бесплатно" - в смысле без поломок и регрессий.
Вообще волна необоснованной критики в осоновном была вида:
"Леннарт - лох!"
"Леннарт, зачем ты сломал наш Linux?"
"Леннарт, когда ты допилишь пульаудио?"
"Леннарт, ну сколько можно?"
"Леннарт, где ты живешь? Куда высылать яд?"И ни на один их этих, волнующих сообщество, вопросов он так и не ответил! Так может критика была обоснованной?
> Вообще волна необоснованной критики в осоновном была вида:
> "Леннарт - лох!"
> "Леннарт, зачем ты сломал наш Linux?"
> "Леннарт, когда ты допилишь пульаудио?"
> "Леннарт, ну сколько можно?"
> "Леннарт, где ты живешь? Куда высылать яд?"Забыли еще
"Леннарт, ты сломал наш юниксвей!"
Что за паника, не совсем понятно.
Всегда было в рекомендациях, в корне - необходимое для загрузки, в /usr - системный софт, в /usr/local - пользовательский софт.
По-моему, все правильно делают.
Если бы они аналогично *BSD стали придерживатся традиций и тоже доп софт пихать в /usr/local, а конфиги его в /usr/local/etc - было б совсем прекрасно. В той же фре никогда не надо гадать, где что от какой софтины лежит. В линуксе частенько приходится пробежать по всем бинам/сбинам, либам, шарам, не айс..
> Всегда было в рекомендациях, в корне - необходимое для загрузки, в /usr
> - системный софт, в /usr/local - пользовательский софт.
> По-моему, все правильно делают.На самом деле, очень нелогично. Например, зачем пихать в корень все необходимое для загрузки, если все то же самое должно лежать в initrd, по определению?
Или: зачем в линуксе нужно деление на мир/порты? В *BSD это деление понятно: мало разработчиков, приходится жертвовать качеством поддержки некритичного софта, и он вынесен в порты. Но в линуксе таких проблем нет, там все пакеты поддерживаются одинаково аккуратно.
> все пакеты поддерживаются одинаково аккуратноORLY?
>> все пакеты поддерживаются одинаково аккуратно
> ORLY?Именно так. А ты думал почему яндекс с рамблером от бзди сбежали как от чумы?
>>> все пакеты поддерживаются одинаково аккуратно
>> ORLY?
> Именно так. А ты думал почему яндекс с рамблером от бзди сбежали
> как от чумы?Потому что достаточного интеллекта на админов не набрали, весь разобран.
Тут действительно приходится держаться за mainstream.
> Потому что достаточного интеллекта на админов не набрали, весь разобран.
> Тут действительно приходится держаться за mainstream.butthurt? напрасно, будь выше этого: от того, что ты обзываешь админов рамблера с яндексом перечисленные ими технические недостатки бзди не исчезнут.
>> Потому что достаточного интеллекта на админов не набрали, весь разобран.
>> Тут действительно приходится держаться за mainstream.
> butthurt? напрасно, будь выше этого: от того, что ты обзываешь админов рамблера
> с яндексом перечисленные ими технические недостатки бзди не исчезнут.Недостатки - да. _Перечисленные ими_ - нет. Там 90% было клиническим бредом.
Возможно, им реально повлияли какие-то другие недостатки, против этого не буду спорить - но не те, что были открыто названы.
>>>> все пакеты поддерживаются одинаково аккуратно
>>> ORLY?
>> Именно так.Отнюдь.
>> А ты думал почему яндекс с рамблером от бзди сбежали как от чумы?
> Потому что достаточного интеллекта на админов не набрали, весь разобран.
> Тут действительно приходится держаться за mainstream.Валик, там были две разные стопки причин, как понимаю. За рамблер не скажу, а в яндексе интеллекта у админов (и судя по виденному, и манагеров) вообще-то прилично.
>>> А ты думал почему яндекс с рамблером от бзди сбежали как от чумы?
>> Потому что достаточного интеллекта на админов не набрали, весь разобран.
>> Тут действительно приходится держаться за mainstream.
> Валик, там были две разные стопки причин, как понимаю. За рамблер
> не скажу, а в яндексе интеллекта у админов (и судя по
> виденному, и манагеров) вообще-то прилично.Я не про админов верхнего уровня, а про массу.
А на верхнем уровне там сплошные тараканы в головах. Последний переезд на линукс (независимо от конечной полезности) обоснован был сплошь дырявыми аргументами.
> А на верхнем уровне там сплошные тараканы в головах. Последний переезд на
> линукс (независимо от конечной полезности) обоснован был сплошь дырявыми аргументами.В рамблере -- насколько понимаю, да, а в яндексе -- отнюдь. Правда, там с фряшными админами и не общался, сплошь линуксоводы знакомые.
>> все пакеты поддерживаются одинаково аккуратно
> ORLY?да, все три. остальные в процессе, и их не считают.
На системах с малым количеством памяти полезнее загрузить из ядра модуль к рутовой FS, чем вываливать в память раскормленный initrd. Особенно это касается устройств с 8-16-32 Мб озей
Если же на такие системы нужно забить, тогда нужно явно осознавать, куда стремится дистрибутив - на десктопы онли или к широкому применению. А также все производные дистрибутивы от него.
> На системах с малым количеством памяти полезнее загрузить из ядра модуль к
> рутовой FS, чем вываливать в память раскормленный initrd. Особенно это касается
> устройств с 8-16-32 Мб озейНа таких системах используют busybox и uclibc. Правда к обсуждаемой теме это не имеет вообще никакого отношения ибо речь идёт про дистрибутивы общего назначения, а не специализированные системы.
>В *BSD это деление понятно: мало разработчиков, приходится жертвовать качеством поддержки некритичного софта, и он вынесен в порты.Неверно. Более того, тезисы - полная хрень от незнания. Сказывается, что в linux dists отсутствует понятие операционной системы и ее границ. В BSD оно есть, и основывается на исходных текстах операционной системы в /usr/src.
#ls /usr/src/
bin sbin lib usr.bin usr.sbin ...#cd /usr/src
#make
#make installИ система инсталируется в
1 /bin, /lib, /sbin,
2 /usr/bin, /usr/sbin, /usr/lib, /usr/libexec /usr/shareНикто не оформляет систему в виде пакетов, кроме как архивно-дистрибутивных tar.gz
Можно, но смысла крайне мало.Размеры корневой системы могут быть весьма скромные
# du -sch /bin /sbin /lib /boot/kernel
684k /bin
5.1M /sbin
7.3M /lib
45M /boot/kernel
58M total
Там дейсвительно только то, что может понадобиться для старта системы и ее ремонта если что.
К примеру, ничто не мешает системе загрузиться при примонтированном /usr или /usr/local/ с NFS, или еще как (разные ситуации бывают).Смешивать код операционной систему и сторонних приложений - хороший способ устроить свалку, поэтому его выносят в /usr/local или /usr/pkg. Это просто практически удобно.
И нет никаких заморочек с inintrd или симлинками.
> Но в линуксе [...] все пакеты поддерживаются одинаково аккуратно.Врёте.
> Что за паника, не совсем понятно.
> Всегда было в рекомендациях, в корне - необходимое для загрузки, в /usr
> - системный софт, в /usr/local - пользовательский софт.
> По-моему, все правильно делают.
> Если бы они аналогично *BSD стали придерживатся традиций и тоже доп софт
> пихать в /usr/local, а конфиги его в /usr/local/etc - было б
> совсем прекрасно. В той же фре никогда не надо гадать, где
> что от какой софтины лежит. В линуксе частенько приходится пробежать по
> всем бинам/сбинам, либам, шарам, не айс..Если бы у тебя был моск - ты бы прочитал ман к dpkg и нашёл там опцию -S
>[оверквотинг удален]
>> Всегда было в рекомендациях, в корне - необходимое для загрузки, в /usr
>> - системный софт, в /usr/local - пользовательский софт.
>> По-моему, все правильно делают.
>> Если бы они аналогично *BSD стали придерживатся традиций и тоже доп софт
>> пихать в /usr/local, а конфиги его в /usr/local/etc - было б
>> совсем прекрасно. В той же фре никогда не надо гадать, где
>> что от какой софтины лежит. В линуксе частенько приходится пробежать по
>> всем бинам/сбинам, либам, шарам, не айс..
> Если бы у тебя был моск - ты бы прочитал ман к
> dpkg и нашёл там опцию -SЕсли бы у разработчиков был мозг, то они бы не устраивали помойки изначально, не устраивали бы идиотизма: "без /usr система все равно не грузится", а как следствие, не нужно было получившуюся помойку сваливать в одну кучу и не было бы тезисов: "Возможность использования нескольких разделов /usr для загрузки разных версий или состояний дистрибутива", "Упрощение формирования гостевых окружений для систем виртуализации", т.к. это было бы доступно изначально, например так, как это доступно во фре.
> Если бы у разработчиков был мозг, то они бы не устраивали помойки
> изначально, не устраивали бы идиотизма: "без /usr система все равно не
> грузится"Не бзди - попробуй удалить /usr на бзде и она точно так же не загрузится.
>> Если бы у разработчиков был мозг, то они бы не устраивали помойки
>> изначально, не устраивали бы идиотизма: "без /usr система все равно не
>> грузится"
> Не бзди - попробуй удалить /usr на бзде и она точно так
> же не загрузится.В многопользовательский режим - не загрузится, будет ругаться на отсутствие /usr/libexec/getty, в однопользовательский режим - без проблем.
Без /usr/local, а именно там все, что не входит в мир, так же загрузится без проблем.
> В многопользовательский режим - не загрузится, будет ругаться на отсутствие /usr/libexec/getty,
> в однопользовательский режим - без проблем.Ещё раз тебе говорю: не бзди!
GNU/Linux тоже без проблем загрузится в однопользовательский режим.
> GNU/Linux тоже без проблем загрузится в однопользовательский режим.название дистрибутива скромно опускаем?
a kak mountit /usr esli mount budet v /usr/bin lejat ?
> a kak mountit /usr esli mount budet v /usr/bin lejat ?А как до этого монтировали корень, если mount лежал в корне? :)
initrd рулит.// Правда, в ядре есть костыли для монтирования корня без initrd, но этот жуткий изврат скорее для эмбеддовки.
> // Правда, в ядре есть костыли для монтирования корня без initrd, но
> этот жуткий изврат скорее для эмбеддовки.Это жуткий изврат, потому что подходом с initrd по умолчанию пользуются установщики дистрибутивов, заранее рассчитанные на незнакомое железо?
Или это жуткий изврат, потому что у вас лично не возникало желания и необходимости делать именно так?
Или для этого требуется правильно скомпилять ядро, запихнув не модулями, а именно в ядро - драйвер FS корня и дискового контроллера, а у вас этого не получалось?Критерии жуткости и извращения, пожалуйста.
В бытность админом ни на одном хосте не имел нужды в initrd. А тебя послушать - так это якобы обязательная вещь. Глупости же говоришь, да по сто раз повторяешь. Стыдоба.
Что-то жиденькое обоснование какое-то.
> Что-то жиденькое обоснование какое-то.зато обоснования "поэтому НЕ нужно переностить всё в /usr/" -- ещё более жиденькое :-D
сомое частое это: "я уже привык вот так, и не хочу менять" :)
на втором месте это:
"у меня "/bin/" и "/usr/" на разных разделах. и допустим повредился раздел "/usr/", и я делаю failsafe-загрузку и запускаю "/bin/fsck" для "usr"-раздела"
-- вообще притянуто ЗАУШИ както.. чессслово.
(сколько раз у меня повреждался раздел "/", но сёравно это не мешало замонтировать его в режиме readonly и с негоже запустить fsck для его-же-собственной проверки.
и потом даже не объясняется почему это вдруг раздел "/usr/" обезательно поломается (да так сильно, что даже замонтироваться в режиме readonly не сможет!), а раздел "/bin/" якобы не может поломатся :-D :-D)на третьем месте: "потеряется совместимость со старыми программами" -- вообще глупейший из контр-доводов. так как совместимость только улучшится :-)
>сколько раз у меня повреждался раздел "/", но сёравно это не мешало замонтировать его в режиме readonly и с негоже запустить fsck для его-же-собственной проверки.Опровержение есть твой сомнительный опыт? С чего тебе должны верить на слово? Вдруг ты нагло врёшь? Тем более никакой информации ни про файловую систему, ни про характер повреждения ты не привёл. Может там и повреждения не было, а просто проверка фс после нескольких ремоунтов.
>зато обоснования "поэтому НЕ нужно переностить всё в /usr/" -- ещё более жиденькое :-DА тут и обосновать нечего. Обосновать должен тот, кто проталкивает изменения. Но, как видно, аргументы жиденькие для таких серьёзных изменений. Вот например "упрощение формирования гостевых окружений". Что тут собрались упрощать? В чём заключается упрощение?
Или вот "шедевр": "Возможность использования нескольких разделов /usr для загрузки разных версий или состояний дистрибутива.". Сразу вопрос, а можно ли systemd на этапе загрузки указать, какой раздел /usr монтировать? Только вот ведь незадача, все его сервисы лежат в /usr. Какие костыли придётся использовать для решения этой задачи? Пихать все потроха и зависимости systemd в initrd?
> А тут и обосновать нечего. Обосновать должен тот, кто проталкивает изменения.Обоснования приведены в статье по ссылке. Попробуй её прочитать. Если не поймёшь с первого раза - попробуй прочитать ещё раз.
> Вот например "упрощение формирования гостевых окружений". Что тут собрались упрощать? В чём заключается упрощение?
Это тоже описано в статье по ссылке. Попробуй её прочитать. Если не поймёшь с первого раза - попробуй прочитать ещё раз.
> Это тоже описано в статье по ссылке. Попробуй её прочитать. Если не
> поймёшь с первого раза - попробуй прочитать ещё раз.Нет, всего этого не написано в статье. Если ты уверен в обратном, то прочитай ещё раз, пока не убедишься, что там этого нет. Если по-прежнему в тебе горит уверенность, что там что-то есть, обратись к специалистам. Тебе помогут.
>> Это тоже описано в статье по ссылке. Попробуй её прочитать. Если не
>> поймёшь с первого раза - попробуй прочитать ещё раз.
> Нет, всего этого не написано в статье.Я же ясно сказал: если не понял - читай ещё раз. До тех пор, пока не дойдёт.
> Я же ясно сказал: если не понял - читай ещё раз. До тех пор, пока не дойдёт.Когда пишущие передёргивают и притягивают за уши нерелевантное -- сколько раз ни читай, в худшем случае создастся иллюзия, что дошло.
Вот они, гримасы капитализма -- в данном случае в виде "популярности" как метрики и пиара как непременной составляющей технического процесса...
> сомое частое это: "я уже привык вот так, и не хочу менять" :)Если бы у Вас был опыт, то знали бы цену принципу "работает -- не трогай".
> на втором месте это:
> "у меня "/bin/" и "/usr/" на разных разделах. и допустим повредился раздел
> "/usr/", и я делаю failsafe-загрузку и запускаю "/bin/fsck" для "usr"-раздела"
> -- вообще притянуто ЗАУШИ както.. чессслово.
> (сколько раз у меня повреждался раздел "/", но сёравно это не мешалоЕсли бы у Вас был опыт, то знали бы, что не всегда разрушения позволяют хоть как-то смонтировать раздел.
> на третьем месте: "потеряется совместимость со старыми программами" -- вообще
> глупейший из контр-доводов. так как совместимость только улучшится :-)Не замечал такого довода, но цена Вашему идентична -- ломаный грош.
ну, я например не использую initrd, у меня и ядро то обычно монолитно.получается нерациональная трата места, копируя файлы для initrd и даже cо сжатием их, всё равно будет больше занято места как на носителе, так и в памяти. не вижу причин переносить всё в /usr, тем более, распихивая линки потом - науха переносить то, если линки оставить придётся?
мне гораздо интереснее разделить доступ, когда одна точка монтирования для записи, другая - для чтения только. например, все файлы для записи скидывать в /var - /var/etc, /var/tmp, /var/run, /var/srv, /var/home и тд
> ну, я например не использую initrd, у меня и ядро то обычно
> монолитно.всем пофик :)
> получается нерациональная трата места, копируя файлы для initrd и даже cо сжатием
> их, всё равно будет больше занято места как на носителе, так
> и в памяти. не вижу причин переносить всё в /usr, тем
> более, распихивая линки потом - науха переносить то, если линки оставить
> придётся?Попробуй прочиать текст новости - там объяснено почему.
> мне гораздо интереснее разделить доступ, когда одна точка монтирования для записи, другая
> - для чтения только. например, все файлы для записи скидывать в
> /var - /var/etc, /var/tmp, /var/run, /var/srv, /var/home и тдПопробуй прочиать текст новости - там это уже описано.
> науха переносить то, если линки оставить придётся?переносить -- файлы (содержимое каталогов)
линки ставить на -- каталоги (а не на файлы, которые являются содержимым каталогов)
доводы разумные.....но количество старпёров сейчас уже не счесть. они будут яростно сопротивляться любой перемене :-D
Молодые пердуны всегда видят фатальный недостаток. Они бы сделали лучше! Ха-ха-ха-ха! И вместо масадосиса мы увидели вендец 3.1, этот жуткий ужас!Валяйте, умники, только не на форумах языками чесать - а мешки ворочать^Wкод писать - да такой крутой, что мы закачаемся. И, самое главное - который проживет 35 лет почти без изменений, ибо всем хорош, а остальные могут лишь трындеть по форумам и в каментах ср.ть!
> Валяйте, умники, только не на форумах языками чесать - а мешки ворочать^Wкод
> писать - да такой крутой, что мы закачаемся. И, самое главное
> - который проживет 35 лет почти без изменений, ибо всем хорош,
> а остальные могут лишь трындеть по форумам и в каментах ср.ть!Именно так всё и происходит - изменения в FHS продвигают те, кто активно пишут крутой код. Среди оппонентов я ни одного известного программиста не увидел - видимо это объясняет полное отсутствие обоснованной критики.
> Именно так всё и происходит - изменения в FHS продвигают те, кто
> активно пишут крутой код. Среди оппонентов я ни одного известного программиста
> не увидел - видимо это объясняет полное отсутствие обоснованной критики.Какой крутой код написал Леннарт? И особенно интересны критерии его "крутости" по сравнению с тысячей других программ, коих тут каждый второй написал не один десяток.
> Какой крутой код написал Леннарт? И особенно интересны критерии его "крутости" по
> сравнению с тысячей других программ, коих тут каждый второй написал не
> один десяток.pulseaudio, systemd.
Теперь попробуй перечислить хотя бы пару программ из "не один десяток", включённых во все распространённые дистрибутивы GNU/Linux. Можно даже не включённых в установку по-умолчанию.
>> Какой крутой код написал Леннарт?
> pulseaudio,Мне нужно описывать проблему Front vs Headphones в pulseaudio?
В отличие от ...
> Мне нужно описывать проблему Front vs Headphones в pulseaudio?
> В отличие от ...былобы не плохо :-)
>>> Какой крутой код написал Леннарт?
>> pulseaudio,
> Мне нужно описывать проблему Front vs Headphones в pulseaudio?
> В отличие от ...лучше перечислить кучи солюшенов для разных программ - которые сводились к "отключите нафик pulseaudio и пусть приложение работает нормально с alsa".
и то что потребовалось больше 5 лет что бы таких солюшенов поубавилось.
>> Какой крутой код написал Леннарт? И особенно интересны критерии его "крутости" по
>> сравнению с тысячей других программ, коих тут каждый второй написал не
>> один десяток.
> pulseaudioвыносится в первую очередь - ибо с ним не работает микрофон. Alsa наше все.
автор упорно не хотел чинить ошибки в коде, сломаный OSS support назвал достоиством.> systemd.
уродский костыль который не позволяет легко модифицировать процедуру старта - только через правки исходника, и пересборку. Сомнительное удовольствие.
> Теперь попробуй перечислить хотя бы пару программ из "не один десяток", включённых
> во все распространённые дистрибутивы GNU/Linux. Можно даже не включённых в установку
> по-умолчанию.То что они включены это заслуга RH который продавил свое решение, и смеется.
им чем больше проблем - тем больше тикетов на поддержку, тем больше бабла.
А вы радуетесь..
> pulseaudio выносится в первую очередь - ибо с ним не работает микрофон.Ложь - микрофон отлично работает. Или ты можешь подтвердить ссылкой на баг-репорт?
> Alsa наше все.
И она тоже отлично работает с pulseaudio.
> systemd уродский костыль который не позволяет легко модифицировать процедуру старта - только через правки исходника, и пересборку.
Опять ложь. Или ты можешь подтвердить ссылкой на баг-репорт?
> То что они включены это заслуга RH который продавил свое решение, и
> смеется.И снова ложь - конкуренты RH включили это в свои дистрибутивы потому, что это отлично работает, обеспечивает большую гибкость и удобство для пользователей.
Интересно, ненавистники Леннарта вообще могут обойтись без наглой лжи?
>> Alsa наше все.
> И она тоже отлично работает с pulseaudio.а не наоборот?
> И снова ложь - конкуренты RH включили это в свои дистрибутивы потому,
> что это отлично работает, обеспечивает большую гибкость и удобство для пользователей.я так понимаю, пруфлинк на заявления и исследования случайно отклеился?
Как ты смешно задёргался когда тебя поймали на лжи :)
> когда тебя поймали на лжиинтересно, где? тебя же не затруднит привести ссылку на мою ложь, правда?
>> когда тебя поймали на лжи
> интересно, где? тебя же не затруднит привести ссылку на мою ложь, правда?Парой сообщений выши - см. №265
>>> Alsa наше все.
>> И она тоже отлично работает с pulseaudio.Ни разу не отлично, но работает.
> а не наоборот?
alsa-pulse действительно есть, но кривое.
всё-таки я намекал, что это пульс живёт за счёт алсы, а никак не наоборот.
>> pulseaudio
> выносится в первую очередьОбычно да.
> - ибо с ним не работает микрофон.
Это не так, PA -- едва ли не единственный известный мне разумный вариант получения приемлемой латентности записи звука с микрофона тонкого клиента при условии подстройки под задачу (снижение количества и IIRC размера сегментов).
> автор упорно не хотел чинить ошибки в коде, сломаный OSS support назвал достоиством.
А вот это да: автор упорно пытается съехать и указание на ошибки и передёргивания воспринимает как личный наезд.
Да, он не виноват _один_ в лени кучи других редхатовцев приводить своё Г к приличному виду без пинков от платящих заказчиков. Ну так и нечего лезть за них на амбразуру и тем более переваливать проблемы с больной головы на здоровые.
PS: несколько оголтелых зашитников вызывают удивление: вы же ничем не лучше оголтелых противников леннартизма.
XEdit включён во все распространённые (и даже в не очень распространённые) дистрибутивы. значит ли это, что XEdit — действительно хороший и удобный редактор? только не надо увёртки про «свою нишу».
> XEdit включён во все распространённые (и даже в не очень распространённые) дистрибутивы.
> значит ли это, что XEdit — действительно хороший и удобный редактор?
> только не надо увёртки про «свою нишу».Ты хочешь сказать что ты автор хедита?
Или что ты окончательно утратил нить рассуждений и не понимаешь о чём вообще идёт речь?
Идея унификации правильная. Только нафиг /usr/bin, а не просто /bin?
>Improved compatibility with other Unixes (in particular Solaris)вот пусть тока не трындит. Где он еще нашел /sbin->/usr/sbin ? Только соляра этим отличается. И я хз как трактористы выкручиваются в случае боков с /usr без отдельного /sbin.
>The primary commercial Unix implementation is nowadays Oracle Solaris.
Доооо. Разбудите его там кто-нибудь, напомните, что 2000 год уже закончился.
Все правильно. В простате надёжность.
Чем проще будет организована система - тем она будет стабильнее и соответственно надёжнее. Это всегда был путь Linux, поэтому это самая надёжная система.
Если есть причины еще упростить - почему бы и нет.
>В простате надёжность.Где ты увидел упрощение?
>В простате надёжность.В мозгах надежность должна быть, блин, в мозгах!
> Все правильно. В простате надёжность.
> Чем проще будет организована система - тем она будет стабильнее и соответственно
> надёжнее. Это всегда был путь Linux, поэтому это самая надёжная система.
> Если есть причины еще упростить - почему бы и нет.а нафига тогда вообще деление на bin и sbin, давайте уж все в кучу, упрощать, так упрощать.
Маразм крепчал.
>Daniel: What happened to the proposed change of /usr/sbin -> /usr/bin as part of the /usr merge?
>Lennart: that bit got delayed for one release and will be proposed for F18 again.
теперь осталось еще статическую линковку отменить, как в соляре, и будет совсем хорошо.
Минус этого переноса очевиден. Рушится базовая система, необходимая для административных действий в случае проблем с загрузкой.
Восполнить это можно двумя способами, либо раздуть initramfs до уровня базовой системы с удобной оболочкой, дисковыми и сетевыми утилитами, либо держать /usr в самой конревой файловой системе. У обоих способов есть серьезные недостатки и пойти на это можно, если преимущества их перевешивают.Преимущества по Поттерингу.
* В настоящее время разные дистрибутивы Linux и Unix-системы по разному формируют состав /bin и /usr/bin. Перенос всех исполняемых файлов в /usr/bin и наполнение /bin через символические ссылки позволит избежать путаницы и сохранить совместимость с ранее практикуемым методом.
Во-первых не факт, что все дистрибутивы и юникс системы последуют призыву Портинга в светлое будущее. Во-вторых, даже если так произойдет, желаемой унификации не будет по причене разного подхода к расположению и содержанию конфигов. К примеру один и тот же сетевой /usr монтируется на станциях разными дистрибутивами. В одном конфиги в /etc/program, в другом в /etc/program.conf.
* Все устанавливаемые из RPM-пакетов неизменные компоненты будут сосредоточены только внутри раздела /usr и не будут встречаться за его пределами, что позволит упростить организацию бездисковых систем и повысит их безопасность - для работы достаточно будет экспортировать в режиме только для чтения раздел /usr и централизованно обновлять его, не заботясь о необходимости синхронизации содержимого каталогов /bin, /sbin и /lib. В корне останутся только файлы, связанные с загрузкой и специфичные для текущей машины данные, например, файлы конфигурации, логи и файлы с меняющимися данными (/etc, /root, /var, /run).
Вот здесь все наоборот. Кроме /usr придется монтировать как минумум /etc.
Сейчас же, например, в ltsp, монтируется только один корень или по nfs ro или, что чаще, nbd + squashfs и накладывается на фс в оперативной памяти. Это и функциональнее, и совершеннее, и не менее безопасно.* Возможность использования нескольких разделов /usr для загрузки разных версий или состояний дистрибутива. Например, в процессе обновления можно сохранить старое содержимое в отдельном разделе и вернуться на него в случае проблем. Возможна также реализация схемы, при которой имеется две копии содержимого /usr: активная копия монтируется в режиме только для чтения, а в неактивную устанавливается обновление, после чего директории меняются местами и синхронизируются;
Приехали. Обновили /usr1. При этом изменился /etc. Вернулись на /usr0. И "великий" systemd, прочитав конфиг, пытается грузить не существующие программы. Возможно, systemd будет хранить конфиги в другом месте, но проблема не сильно меняется.
* Упрощение формирования гостевых окружений для систем виртуализации - достаточно монтировать внутри виртуальных окружений системный раздел /usr в режиме только для чтения. При этом автоматически решаются проблемы с обновлением начинки гостевых систем и существенно экономится дисковое пространство;
/usr и сейчас можно монтировать только для чтения. Но, кроме этого /bin можно монтировать, а можно использовать и свой оригинальный, что дает дополнительную гибкость.
Доводы передового разработчика напоминают отписку для дураков. Думаю, большинство дистрибутивов в этом вопросе не пойдут стройными рядами за Федорой.
> Минус этого переноса очевиден. Рушится базовая система, необходимая для административных действий в случае проблем с загрузкой.Каких именно проблем? Если у тебя система не загрузилась с бинарниками в /usr/bin то с чего ты решил, что она магическим образом загрузится с бинарниками в /bin ?
> Во-первых не факт, что все дистрибутивы и юникс системы последуют призыву Портинга
> в светлое будущее. Во-вторых, даже если так произойдет, желаемой унификации не
> будет по причене разного подхода к расположению и содержанию конфигов. К
> примеру один и тот же сетевой /usr монтируется на станциях разными
> дистрибутивами. В одном конфиги в /etc/program, в другом в /etc/program.conf.Унификация означает "одинаковые принципы построения", а вовсе не "одинаковые имена каждого файла".
> Вот здесь все наоборот. Кроме /usr придется монтировать как минумум /etc.
> Сейчас же, например, в ltsp, монтируется только один корень или по nfs
> ro или, что чаще, nbd + squashfs и накладывается на фс
> в оперативной памяти. Это и функциональнее, и совершеннее, и не менее
> безопасно.Неверно. Конфиги и другие файлы, специфичные для машины хранятся на самой машине. Монтировать некий общий /etc просто нет необходимости. Так что единый /usr в ro безопаснее и удобнее
> Приехали. Обновили /usr1. При этом изменился /etc. Вернулись на /usr0. И "великий"
> systemd, прочитав конфиг, пытается грузить не существующие программы. Возможно, systemd
> будет хранить конфиги в другом месте, но проблема не сильно меняется.Если обновление затрагивает /etc (причём именно ломающим совместимость образом) - ничто не мешает сделать его снэпшот.
> /usr и сейчас можно монтировать только для чтения. Но, кроме этого /bin
> можно монтировать, а можно использовать и свой оригинальный, что дает дополнительную
> гибкость.Забавно: необходимость монтировать несколько разделов в случае с ltsp позиционируется как недостаток, а теперь - как достоинство. Ты уж определись - гибкость это или гемор?
> Доводы передового разработчика напоминают отписку для дураков. Думаю, большинство дистрибутивов в этом вопросе не пойдут стройными рядами за Федорой.
До сих пор шли: /run во всех дистрибутивах уже есть или в ближайших планах, pulseaudio - тоже.
Может быть всё дело в том, что аргументы Поттеринга рассчитаны на тех, кто постоянно занят развитием и поддержанием дистрибутивов, а не досужими рассуждениями на форумах?
Ты прочитать пробовал, на что отвечаешь?> Каких именно проблем? Если у тебя система не загрузилась с бинарниками в
> /usr/bin то с чего ты решил, что она магическим образом загрузится
> с бинарниками в /bin ?О том и речь. Могут быть проблемы с монтированием /usr. Особенно сетевого.
>> Во-первых не факт, что все дистрибутивы и юникс системы последуют призыву Портинга
>> в светлое будущее. Во-вторых, даже если так произойдет, желаемой унификации не
>> будет по причене разного подхода к расположению и содержанию конфигов. К
>> примеру один и тот же сетевой /usr монтируется на станциях разными
>> дистрибутивами. В одном конфиги в /etc/program, в другом в /etc/program.conf.
> Унификация означает "одинаковые принципы построения", а вовсе не "одинаковые имена каждого
> файла".К зоопарку добавлен еще один "принцип построения". Или вы уверены, что все остальные "исчезнут".
>> Вот здесь все наоборот. Кроме /usr придется монтировать как минумум /etc.
>> Сейчас же, например, в ltsp, монтируется только один корень или по nfs
>> ro или, что чаще, nbd + squashfs и накладывается на фс
>> в оперативной памяти. Это и функциональнее, и совершеннее, и не менее
>> безопасно.
> Неверно. Конфиги и другие файлы, специфичные для машины хранятся на самой машине.
> Монтировать некий общий /etc просто нет необходимости. Так что единый /usr
> в ro безопаснее и удобнееРечь шла бездисковых станциях.
>> Приехали. Обновили /usr1. При этом изменился /etc. Вернулись на /usr0. И "великий"
>> systemd, прочитав конфиг, пытается грузить не существующие программы. Возможно, systemd
>> будет хранить конфиги в другом месте, но проблема не сильно меняется.
> Если обновление затрагивает /etc (причём именно ломающим совместимость образом) - ничто
> не мешает сделать его снэпшот.Да. только ради чего?
>> /usr и сейчас можно монтировать только для чтения. Но, кроме этого /bin
>> можно монтировать, а можно использовать и свой оригинальный, что дает дополнительную
>> гибкость.
> Забавно: необходимость монтировать несколько разделов в случае с ltsp позиционируется
> как недостаток, а теперь - как достоинство. Ты уж определись -
> гибкость это или гемор?В случае бездисковых станций дополнительное монтирование не прибовляет гибкости. Здесь да, прибавляет. Хотя я согласен снять этот аргумент.
>> Доводы передового разработчика напоминают отписку для дураков. Думаю, большинство дистрибутивов в этом вопросе не пойдут стройными рядами за Федорой.
> До сих пор шли: /run во всех дистрибутивах уже есть или в
> ближайших планах, pulseaudio - тоже.
> Может быть всё дело в том, что аргументы Поттеринга рассчитаны на тех,
> кто постоянно занят развитием и поддержанием дистрибутивов, а не досужими рассуждениями
> на форумах?Почитайте мнение этих людей. Они, мягко говоря, далеко не однозначны.
> О том и речь. Могут быть проблемы с монтированием /usr. Особенно сетевого.Могут разумеется - только маловероятно, что загрузка в / поможет эти проблемы решить. Нет, конечно такой маленький шанс есть, при условии что загрузка без /usr работает - в большинстве современных дистрибутивов это не так - несмотря на формальное разделение этот use-case как правило не тестируется.
> К зоопарку добавлен еще один "принцип построения". Или вы уверены, что все
> остальные "исчезнут".Он добавлен ещё лет 15 назад в эпоху классического юникса. Что там говорил про "читать на что отвечаешь"? ;)
> Речь шла бездисковых станциях.
Тогда твоя фраза "монтируется поверх" лишена всякого смысла - поверх чего может монтироваться сетевой раздел на _бездисковом_ терминале?
> Да. только ради чего?
А почему бы и нет собственно? Это всего лишь один из множества плюсов от предлагаемых улучшений. Сейчас такое сделать крайне геморройно, после объединения /usr это сделать будет легко.
> Почитайте мнение этих людей. Они, мягко говоря, далеко не однозначны.
Ну ссылки что-ли приводи. Только не на форумы "крутых всезнающих админов", а на разработчиков дистрибутивов. Например сейчас в gdm-list идёт микросрачик по поводу выпиливания ConsoleKit - народ против выпиливания особо не возражает, желающие странного готовы взять поддержку на себя.
> Могут разумеется - только маловероятно, что загрузка в / поможет эти проблемы
> решить. Нет, конечно такой маленький шанс есть, при условии что загрузка
> без /usr работает - в большинстве современных дистрибутивов это не так
> - несмотря на формальное разделение этот use-case как правило не тестируется.На большинстве - это на Федоре. В однопользовательском режиме все же обычно не используется /usr.
> Он добавлен ещё лет 15 назад в эпоху классического юникса. Что там
> говорил про "читать на что отвечаешь"? ;)Я о ссылках /bin -> /usr/bin и т.д.
>> Речь шла бездисковых станциях.
> Тогда твоя фраза "монтируется поверх" лишена всякого смысла - поверх чего может
> монтироваться сетевой раздел на _бездисковом_ терминале?Сетевой корень cовмещается с корнем в оперативке.
> А почему бы и нет собственно? Это всего лишь один из множества
> плюсов от предлагаемых улучшений. Сейчас такое сделать крайне геморройно, после объединения
> /usr это сделать будет легко.Точно так же, как и сейчас.
> На большинстве - это на Федоре. В однопользовательском режиме все же обычно
> не используется /usr.cd /sbin && ldd *|grep /usr | wc -l
На моей убунте даёт 47.
Можешь проверить на своём любимом дистре.
Надо что-то ещё пояснять про "обычно не используется /usr"?> Я о ссылках /bin -> /usr/bin и т.д.
Можешь посмотреть на соплярис, от 11 и выше.
> Сетевой корень cовмещается с корнем в оперативке.
Внимание вопрос: откуда этот самый корень взялся в оперативке на _бездисковой_ станции?
>> А почему бы и нет собственно? Это всего лишь один из множества
>> плюсов от предлагаемых улучшений. Сейчас такое сделать крайне геморройно, после объединения
>> /usr это сделать будет легко.
> Точно так же, как и сейчас.Ты не понимаешь разницы или притворяешься?
Для понимания можешь попробовать посмотреть через какие костыли это реализовано в calculate linux. Потом сравнить с парой командой mount, которые потребуются для реализации того же после того как предложения Сиверса со товарищи станут стандартом.А я уверен, что они станут - просто потому, что это удобнее и облегчает портирование софта.
> cd /sbin && ldd *|grep /usr | wc -l
> На моей убунте даёт 47.
> Можешь проверить на своём любимом дистре.
> Надо что-то ещё пояснять про "обычно не используется /usr"?У меня на дом. дебиане три библиотеки. Причем некритичные (ntfs, ntfs-3g, fuse).
Тем не менее этот довод (Все украдено до нас) все же весомее пустословия Потеринга.> Можешь посмотреть на соплярис, от 11 и выше.
Исходная тема - унификация. А тут умирающий Солярис.
> Внимание вопрос: откуда этот самый корень взялся в оперативке на _бездисковой_ станции?
Корня в памяти не встечал? Или он только на дисковых станциях возможен?
Тем не менее вопрос к теме не относится.
> Ты не понимаешь разницы или притворяешься?
> Для понимания можешь попробовать посмотреть через какие костыли это реализовано в calculate
> linux. Потом сравнить с парой командой mount, которые потребуются для реализации
> того же после того как предложения Сиверса со товарищи станут стандартом.Тем не менее не вижу принципиальной разницы.
> У меня на дом. дебиане три библиотеки. Причем некритичные (ntfs, ntfs-3g, fuse).
> Тем не менее этот довод (Все украдено до нас) все же весомее
> пустословия Потеринга.Вообще-то этот аргумент я как раз у Поттеринга и взял. Ты б всё же прочитал оригинальную статью, а?
>> Можешь посмотреть на соплярис, от 11 и выше.
> Исходная тема - унификация. А тут умирающий Солярис.Ну поскольку обсуждаемое предложение облегчает портирование, не давая регрессий (ок, за редким исключением вроде дебьяна для тех кто не использует нтфс и принципиально не хочет иметь дело с initrd), то думаю дистростроители с радостью пойдут на данный шаг вслед за федорой.
>> Ты не понимаешь разницы или притворяешься?
>> Для понимания можешь попробовать посмотреть через какие костыли это реализовано в calculate
>> linux. Потом сравнить с парой командой mount, которые потребуются для реализации
>> того же после того как предложения Сиверса со товарищи станут стандартом.
> Тем не менее не вижу принципиальной разницы.Ну спроси у разработчиков calculate linux - они тебе объяснят сколько заняла разработка данной фичи и сколько усилий требуется на её поддержку.
> Для понимания можешь попробовать посмотреть через какие костыли это реализовано в calculate linux.можно подробностей?
>> На большинстве - это на Федоре. В однопользовательском режиме все же обычно
>> не используется /usr.
> cd /sbin && ldd *|grep /usr | wc -l
> На моей убунте даёт 47.
> Можешь проверить на своём любимом дистре.
> Надо что-то ещё пояснять про "обычно не используется /usr"?вот это, в первую очередь, и нужно чинить, а не дальше ломать.
# uname -a
FreeBSD myhost 8.2-RELEASE-p6 FreeBSD 8.2-RELEASE-p6 #1: Tue Jan 10 14:21:54 MSK 2012 root@myhost:/usr/obj/usr/src/sys/MYKERNEL amd64
# cd /sbin && ldd *|grep /usr | wc -l
0
# cd /bin && ldd * | grep /usr | wc -l
0
> вот это, в первую очередь, и нужно чинить, а не дальше ломать.А где ты увидел предложение сломать что-либо?
Опять пытаешься выдать свой бред за реальность?
>> вот это, в первую очередь, и нужно чинить, а не дальше ломать.
> А где ты увидел предложение сломать что-либо?
> Опять пытаешься выдать свой бред за реальность?Перестань паясничать, лукавить и подлизывать. Понимаю, не приятно за фидору, но увы...
>> Могут разумеется - только маловероятно, что загрузка в / поможет эти проблемы
>> решить. Нет, конечно такой маленький шанс есть, при условии что загрузка
>> без /usr работает - в большинстве современных дистрибутивов это не так
>> - несмотря на формальное разделение этот use-case как правило не тестируется.
> На большинстве - это на Федоре. В однопользовательском режиме все же обычно
> не используется /usr.Боюсь, ты таки с фряхой попутал. Там действительно в single user автоматом только корень.
В большинстве линуксов при этом уже смонтировано всё автоматически подключаемое, под руководством /etc/rc.sysinit или аналога.
> Боюсь, ты таки с фряхой попутал. Там действительно в single user автоматом только корень.хм. а это чем-то плохо?
>> Боюсь, ты таки с фряхой попутал. Там действительно в single user автоматом только корень.
> хм. а это чем-то плохо?Для неё - нет. Потому что в корне достаточно средств, чтобы попасть в шелл, сделать mount, fsck, загрузить штатные модули, отредактировать fstab (через /bin/ed) и в общем выполнить весьма немалый объём всякой возни. И они проверяются на работоспособность.
>(через /bin/ed)ed - конечно сильно, но можно и более обыденными средствами: /rescue/vi
>> Может быть всё дело в том, что аргументы Поттеринга рассчитаны на тех,
>> кто постоянно занят развитием и поддержанием дистрибутивов, а не досужими
>> рассуждениями на форумах?Вы с ними хоть общались, крикливый Вы наш?
> Почитайте мнение этих людей. Они, мягко говоря, далеко не однозначны.
Вот именно.
Спасибо за изложенное, хотя читать и воспринимать Вашему оппоненту, похоже, сложно. :(
> До сих пор шли: /run во всех дистрибутивах уже есть или в
> ближайших планах, pulseaudio — тоже.(внимательно осмотрел свою слаку) нету. вы, сударь, лжец.
Речь шла о дистрибутивах, а не о детских конструкторах.
> Речь шла о дистрибутивах, а не о детских конструкторах.это, случайно, не о тех, у которых несколько лет мегабаг в OpenSSL был, потому что маинтайнер — криворукий идиот? благодарю, я лучше на «детском конструкторе» останусь.
p.s. то, что ты слаку видел только издалека в виде iso-образа — даже доказывать не надо.
А тут все просто. Леннарт ориентируется отнюдь не на однопользовательские системы, а на энтерпрайз. Там подходы другие, поэтому он и не задумывается над "восстановлением". Там все данные хранятся на рейд-массивах, заранее созданы запасные сервера на случай физических поломок и пр. Если есть махонький серверок, на котором крутится десятка два-три виртуалок, то возможность иметь для них один общий usr - бесценна, это здорово экономит место и гарантирует, что обновлены будут все машины - причем без каких-либо дополнительных усилий. Ну, и возможность отката простым монтированием дорогого стоит.
...А до проблем с восстановлением системы на старенькой файлопомойке ему и дела нет...
Fedora это полигон для тестирования нововедений на хомячках.
Вот когда RedHat это пропихнет в RHEL - тогда можно о чем-то говорить, а хомячки из федориного горя должны хоть что-то заплатить RH, если не деньгами - то побыть подопытными крысами :)
Полигон для тестирования, кажется, слишком плохо звучит.RH захотела - запилили systemd. Кому не нравится идут лесом, кому пофиг - у тех все работает нормально, ибо багов и проблем как таковых здесь не больше, чем раньше.
И какие положительные моменты есть для домашних машин? Дома мне ни жарко, ни холодно от наличия или отсутствия /sbin. Я уж и не помню, когда в последний раз что-то даже в /etc менял, благо Мандрива почти на все хороший гуй имеет. А вот в масштабах немелкого предприятия - таки да, Леннарт все по полочкам разложил.
ОН РАБОТАЕТ НА RED HAT. RED HAT выпускает ось ДЛЯ ПРОМЫШЛЕННЫХ СЕРВЕРОВ - так понятнее? Его может интересовать только конечный результат - удобство работы в энтерпрайзе. Ну, а кто дома Федору использует - должен же кто-то будущий энтерпрайз тестировать?
> И какие положительные моменты есть для домашних машин? Дома мне ни жарко,
> ни холодно от наличия или отсутствия /sbin. Я уж и не
> помню, когда в последний раз что-то даже в /etc менял, благо
> Мандрива почти на все хороший гуй имеет. А вот в масштабах
> немелкого предприятия - таки да, Леннарт все по полочкам разложил.
> ОН РАБОТАЕТ НА RED HAT. RED HAT выпускает ось ДЛЯ ПРОМЫШЛЕННЫХ СЕРВЕРОВ
> - так понятнее?Дибил он. А работать он может хоть в Белом Доме или ООН.
Если он видит разницу в монитровании /usr как / для NFS, тогда тут неувязочка,
по его феншую, /usr должен монтироваться как /usr иначе хня получается.
А если примонтировали удалённый /usr как /usr, где же тогда корень, и чем тогда
NFS /usr будет отличаться от / ?Отседа вывод: Ничем отличаться не будет. Тогда нах...я дописывать три буквы к / ?
---Более того, NFS структуры на NFS серверах хранятся совершенно в иных местах,
так как обычно это урезанные, минимальные копии файловой структуры, только с
необходимым набором утилит, библиотек и софта.
---
> Упрощение формирования гостевых окружений для систем виртуализацииКто ему сказал, что мне нужна вся иерархия /usr ?
Кто ему сказал, что окружения виртуализации есть копии хост системы?
Кто ему сказа, что скорость работы через virtio будет быстрее, чем внутри?
Облачные, кластерные хосты тоже будут тянуть все с одного сервака?
Бред ломать фундамент, заменяя его воздушной подушкой на 10-цис-2-альфа-димитилпропиленбутаноле, и убеждать что это нужно.
> И какие положительные моменты есть для домашних машин? Дома мне ни жарко,
> ни холодно от наличия или отсутствия /sbin.Ну тогда ты просто не заметишь никакой разницы. Если конечно не пользуешься виртуализацией вообще. Соответственно можешь не тратить энергию на обсуждение изменений, которые ты всё-равно не почувствуешь.
> в SysV Unix /bin является симлинком на /usr/bin.http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_...
/
/tmp
/dev
/dev/null
/dev/tty
/dev/consoleНет там больше ничего.
--
Так же для дибилов вроде Поттыринга написалиhttp://pubs.opengroup.org/onlinepubs/009695399/xrat/xbd_chap...
A.10.1 Directory Structure and FilesA description of the historical /usr/tmp was omitted, removing any concept of differences
in emphasis between the / and /usr directories. The descriptions of /bin, /usr/bin,
/lib, and /usr/lib were omitted because they are not useful for applications. In an early
draft, a distinction was made between system and application directory usage, but this
was not found to be useful.
> новое унифицированное расположение исполняемых файлов и библиотек внутри
> раздела /usr (содержимое /bin планируется перенести в /usr/bin, /sbin в
> /usr/sbin, /lib в /usr/lib и /lib64 в /usr/lib64) более совместимо с UNIX,b. If you cannot stop the applications using the logical volume, or it is a system directory
such as /var or/usr, change to single-user state as follows:
# /sbin/shutdown
c. Unmount the file system as follows:
# /sbin/umount /dev/vg01/lvol2
2. Extend the logical volume. For example:
# /sbin/lvextend -L 332 /dev/vg01/lvol2Где?
> 2. Extend the logical volume. For example:
> # /sbin/lvextend -L 332 /dev/vg01/lvol2
> Где?прости ему убогому. человек ничего дальше соляры не видел.
>[оверквотинг удален]
>> /usr/sbin, /lib в /usr/lib и /lib64 в /usr/lib64) более совместимо с UNIX,
> b. If you cannot stop the applications using the logical volume, or
> it is a system directory
> such as /var or/usr, change to single-user state as follows:
> # /sbin/shutdown
> c. Unmount the file system as follows:
> # /sbin/umount /dev/vg01/lvol2
> 2. Extend the logical volume. For example:
> # /sbin/lvextend -L 332 /dev/vg01/lvol2
> Где?Сейчас ты должен создать новый правильный initrd - положить туда что нужно и загрузившись заново сделать то что хочется.
/bin
/boot
/dev
/etc
/home/user/{bin,sbin,lib,libexec,include}
/lib/libexec/
/media
/opt
/proc
/root
/run
/sbin
/share/{info,include,doc,man,src}
/srv
/sys
/tmp
/varсобрать в следующий раз LFS так?
>[оверквотинг удален]
> /opt
> /proc
> /root
> /run
> /sbin
> /share/{info,include,doc,man,src}
> /srv
> /sys
> /tmp
> /var/local ищо :)
Да чего уж там
/man
/doc
/locale
/info
/log
/cache
/spool
/rpm - для бландинок, чтоб далеко ходить не надо было, и в скриптах меньше писать (тоже экономия места,.. на терабайтниках-то)
> собрать в следующий раз LFS так?
пардон, если повторяю выше описанное, но Ctrl+F не нашел. итак:
а что будет с /opt, так и останется в корне, или также закинут в /usr