The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Обоснование целесообразности переноса компонентов из корня в..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Обоснование целесообразности переноса компонентов из корня в..."  –1 +/
Сообщение от opennews (ok) on 27-Янв-12, 12:21 
В связи с волной необоснованной критики Леннарт Поттеринг (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.me/opennews/art.shtml?num=32914

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Обоснование целесообразности переноса компонентов из корня в..."  –15 +/
Сообщение от daemonpnz (ok) on 27-Янв-12, 12:21 
А всё необходимое для начальной загрузки я так понимаю он предлагает совать в initrd?! Тогда в топку такие его идеи.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Обоснование целесообразности переноса компонентов из корня в..."  +5 +/
Сообщение от dalco (ok) on 27-Янв-12, 12:35 
Кого "его"? Поттеринг здесь вообще не при чем (о чем и написано в его блоге ангельским по белому).

P.S. Идею запихать все в /usr придумали совсем другие люди, а Поттеринг всего лишь обеспечил работоспособность сей идеи в systemd (впрочем, systemd точно так же работает и с "классической раскладкой" диска).

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

41. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 14:12 
> А всё необходимое для начальной загрузки я так понимаю он предлагает совать в initrd?!

Между прочим
1. initrd для этого и предназначен.
2. оно все уже давно туда засунуто, иначе бы система не грузилась.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

44. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Xaionaro (ok) on 27-Янв-12, 14:15 
>> А всё необходимое для начальной загрузки я так понимаю он предлагает совать в initrd?!
> Между прочим
> 1. initrd для этого и предназначен.
> 2. оно все уже давно туда засунуто, иначе бы система не грузилась.

Лично у меня не везде initrd вообще используется. И лучше бы он вообще почти нигде не использовался.

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

47. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Andrey Mitrofanov on 27-Янв-12, 14:17 
> Лично у меня не везде initrd вообще используется. И лучше бы он
> вообще почти нигде не использовался.

К моему ручки-то не тяни!?

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

49. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 14:22 
> Лично у меня не везде initrd вообще используется.

Это ваши половые трудности.

> И лучше бы он вообще почти нигде не использовался.

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

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

176. "Обоснование целесообразности переноса компонентов из корня в..."  +2 +/
Сообщение от Xaionaro (ok) on 27-Янв-12, 20:15 
> Это ваши половые трудности.

Некоструктивный тезис.

> initrd - гибкое и эффективное решение, и нет смысла от него отказываться ради чьей-то необоснованной фобии.

Это гибкий, в каком-то смысле эффективный, но костыль. Самый настоящий костыль, если подумать как оно работает. Да, он работает, но нельзя сказать, что решение это элегантное. Без него нельзя жить? Вон, во FreeBSD как-то и без initrd хорошо живётся. Другими словами, более простых и надёжных решений несколько штук придумать вполне можно.

И нет, это не "фобия". Это скорее неприязнь нагромождений и костылей. Я люблю когда система проста как гвоздь и молоток. И отсюда антипатия в том числе и к Поттеренговскому набору. Все эти pulseaudio (думаю уже каждый натерпелся), зависимости на dbus (отдельная тема для холивара), логи читаемые только специальными утилитами у меня вызывают просто отвращение, но я их не боюсь.

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

224. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от tavaaver on 27-Янв-12, 23:54 
Я с пульсом не натерпелся. Как работал, так и работает.
Более того, я с удовольствием транслирую звук по сети с ноутбука на большую машину (подключенную к усилителю и колонкам), когда смотрю фильмы на диване.

Я что-то сделал не так?

Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

232. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Oleg (??) on 28-Янв-12, 01:13 
>с ноутбука на большую машину

А на большой машине включить фильм не судьба? :) Или у тебя дармовая электроэнергия?

Ответить | Правка | ^ к родителю #224 | Наверх | Cообщить модератору

235. "Обоснование целесообразности переноса компонентов из корня в..."  –1 +/
Сообщение от Xasd (ok) on 28-Янв-12, 03:39 
> Или у тебя дармовая электроэнергия?

ох чорт! пойду проверю не забыл ли я выключить свет в туалете!!!

:-D :-D

Ответить | Правка | ^ к родителю #232 | Наверх | Cообщить модератору

308. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 29-Янв-12, 13:23 
Могли бы и природе позаботиться, если что.
Ответить | Правка | ^ к родителю #235 | Наверх | Cообщить модератору

281. "Обоснование целесообразности переноса компонентов из корня в..."  +2 +/
Сообщение от netch (ok) on 28-Янв-12, 21:58 
>> Это ваши половые трудности.
> Некоструктивный тезис.
>> initrd - гибкое и эффективное решение, и нет смысла от него отказываться ради чьей-то необоснованной фобии.
> Это гибкий, в каком-то смысле эффективный, но костыль. Самый настоящий костыль, если
> подумать как оно работает. Да, он работает, но нельзя сказать, что
> решение это элегантное. Без него нельзя жить? Вон, во FreeBSD как-то
> и без initrd хорошо живётся.

Во FreeBSD "хорошо живётся" за счёт того, что загрузчик выполняет сравнимую функциональность достижением файлов модулей с малого количества известных FS.
UFS, ZFS, NFS и пожалуй всё. Да, он может там и конфиги прочесть, и модули, и загрузить их. А для писателей на Форте ещё и вкусности доступны. Но условия несравнимы.
Initrd - значительно более универсальное решение, хотя за него и плата (в большинстве исполнений это хрень столь же загадочная как BIOS - или сработала, или нет, а лезть внутрь - это требуется сработавшая загрузка).

BTW, FreeBSD умеет initrd (только он зовётся mfsroot), и этим пользуются - для запусков в сложных условиях, или тот же инсталлятор запускается именно в нём.

> Другими словами, более простых и надёжных
> решений несколько штук придумать вполне можно.

Например?

> И нет, это не "фобия". Это скорее неприязнь нагромождений и костылей. Я
> люблю когда система проста как гвоздь и молоток. И отсюда антипатия
> в том числе и к Поттеренговскому набору. Все эти pulseaudio (думаю
> уже каждый натерпелся), зависимости на dbus (отдельная тема для холивара), логи
> читаемые только специальными утилитами у меня вызывают просто отвращение, но я
> их не боюсь.

Ну initrd всего этого не требует.

Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

208. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от kuku on 27-Янв-12, 22:24 
Простите, а зачем тогда корневой раздел ?
Пользовательский и т.д. ?
Это в FreeBSD есть.
Всё же, корневой (mount point - /) и пользовательский
(mount point - /usr) разделы были не зря придуманы.
Например, ту же флешку с корневым разделом не плохо
иметь... так, на всякий случай...
Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

242. "Обоснование целесообразности переноса компонентов из..."  –1 +/
Сообщение от arisu (ok) on 28-Янв-12, 09:22 
> initrd — гибкое и эффективное решение

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

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

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

249. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от Аноним (??) on 28-Янв-12, 10:28 
> …которое, тащемта, не нужно.

Ты еще расскажи что 640 кило хватит всем. Initrd позволяет взлететь с крайне хитровыгнутой стартовой площадки. Другие методы - когда как. Что? Втолкать все в ядро? Не модулями? А благородный дон в курсе что некоторые из архитектур имеют жесткие лимиты на размеры неких областей? И утолкать тудя супержирное ядро может и не получиться.

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

А ты распишешься за _все_ платформы, архитектуры и загрузочные конфигурации, чтобы делать столь глобальные выводы? Или у тебя тоже синдром админа локалхоста вылез - мол, раз я не юзаю, значит никому это не надо?

> initrd нужно только если хочется сделать «одно универсальное ядро для всех».

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

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

И ты конечно готов написать такую программу... эээ, стоп, а как я ее буду запускать на какойнить там железке где допустим MIPSовый проц с допустим u-boot'ом? А может, с redboot'ом? Как мне предлагается такую программу до установки системы запустить, интересно? Ты готов это родить под все существующие загрузчики? :)

> и сгенерирует конфиг ядра, где некоторые самые нужные модули будут
> впилены жёстко, просто нужные — модулями, а остальное вообще отключит нафиг.

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

> вот у меня ядро пересобирается пять минут (реально, пять минут). а
> «дистрибутивный» конфиг — где-то пол часа, если не больше.

А у меня весь initrd перестраивается за 20 секунд. В гробу я видал кайф ждать вместо 20 секунд 5 минут.

Ответить | Правка | ^ к родителю #242 | Наверх | Cообщить модератору

257. "Обоснование целесообразности переноса компонентов из..."  +3 +/
Сообщение от arisu (ok) on 28-Янв-12, 11:35 
>> …которое, тащемта, не нужно.
> Initrd позволяет взлететь с крайне хитровыгнутой стартовой площадки.

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

> Втолкать все в ядро? Не модулями?

кагбэ ты не поверишь, но достаточно «втолкать» драйвера для дисков и для корневой fs. всё остальное ядро отлично подтянет уже с диска (или другого носителя, не суть важно).

> А благородный дон в курсе что некоторые из архитектур имеют жесткие лимиты на размеры неких областей? И утолкать тудя супержирное ядро может и не получиться.

ты странное бинарное существо. или «всё модулями» или «всё монолитом». попробуй расширить кругозор.

> А ты распишешься за _все_ платформы, архитектуры и загрузочные конфигурации, чтобы делать
> столь глобальные выводы?

что, есть какая-то платформа, под которую ядро можно собрать *только* с условием взлёта с initrd? жду примера тогда. не гипотетического, если что.

> Знаешь, если продолжить ту же логику — модули вообще зря изобрели. Надо
> было вкомпиливать вообще все 100500 дров в одну монолитную чушку. А
> модули — туда же куда и рамдиски.

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

> И ты конечно готов написать такую программу…

угу. за деньги.

> эээ, стоп, а как я ее буду запускать на какойнить там железке где допустим MIPSовый проц с допустим u-boot'ом? А может, с redboot'ом?

ты прямо на этой железке и собираешь ядро? месье знает толк в извращениях.

> Как мне предлагается такую программу до установки системы запустить, интересно?

зачем? лучше запусти сначала свой мозг. если у тебя неизвестная зверушка от непонятного вендора — ты ССЗБ, и нестандартный секс тебе обеспечен в любом случае.

> Ты готов это родить под все существующие загрузчики? :)

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

> Слушай, на писюке никому не вперлось экономить целый мег памяти путем таких
> ужимок и прыжков

мне — «впёрлось». и память, и время пересборки ядра. а ты — лжец, поскольку «никому» подразумевает, что и мне тоже.

> А у меня весь initrd перестраивается за 20 секунд.

так ты ещё и не знаешь разницы между генерацией initrd и пересборкой ядра? круто. ну, сделай свои «20 секунд», когда обновляешь ядро, угу. впрочем, ты сейчас начнёшь говорить, что я красноглаз, и все «нормальные люди» берут ядра из пакетов своих дистрибутивов.

Ответить | Правка | ^ к родителю #249 | Наверх | Cообщить модератору

280. "Обоснование целесообразности переноса компонентов из..."  +1 +/
Сообщение от netch (ok) on 28-Янв-12, 21:52 
>>> …которое, тащемта, не нужно.
>> Initrd позволяет взлететь с крайне хитровыгнутой стартовой площадки.
> кагбэ не помню, чтобы я с этим спорил. правда, какая религия запрещает
> собрать кастомное ядро для этой площадки — не ясно.

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

С другой стороны, про особенности initrd надо постоянно помнить. Например, не забывать ему скормить указание на хитрые драйвера, LVM и тому подобное, если автоматом это не доработано (сплошь и рядом натыкаюсь на такое).

> кагбэ ты не поверишь, но достаточно «втолкать» драйвера для дисков и для
> корневой fs. всё остальное ядро отлично подтянет уже с диска (или
> другого носителя, не суть важно).

Увы, всё сложнее. Где-то надо конфиг подложить, где-то драйвера промежуточных шин...


>> А ты распишешься за _все_ платформы, архитектуры и загрузочные конфигурации, чтобы делать
>> столь глобальные выводы?
> что, есть какая-то платформа, под которую ядро можно собрать *только* с условием
> взлёта с initrd? жду примера тогда. не гипотетического, если что.

Я такое видел. При старте ядра настраивался доступ к сетевому корню, вбивалось пару static route (да, это уже идиотизм конкретной местности), уточнения параметров infiniband драйвера и специфические параметры для монтирования корня. Автоматом оно там в принципе не запускалось, ибо ядро не знает, что и как вылавливать и корректировать из ответа DHCP.
Идею вписывать эти правила в код ядра, пожалуйста, не предлагать.

> зачем? лучше запусти сначала свой мозг. если у тебя неизвестная зверушка от
> непонятного вендора — ты ССЗБ, и нестандартный секс тебе обеспечен в
> любом случае.

Угу. И в случае возможности собрать для этого комплект userland'а с каким-нибудь даже перлом внутри нестандартный секс резко облегчается.

>> Ты готов это родить под все существующие загрузчики? :)
> а зачем? не видел ни одного идиота, который попытался бы пересобрать ядро
> прямо на роутере, например. подозреваю, что такие существа умирают намного раньше
> — в силу фатального дефекта головного мозга.

А при чём тут "прямо на раутере"?

>> А у меня весь initrd перестраивается за 20 секунд.
> так ты ещё и не знаешь разницы между генерацией initrd и пересборкой
> ядра? круто. ну, сделай свои «20 секунд», когда обновляешь ядро, угу.

Зачем?

> впрочем, ты сейчас начнёшь говорить, что я красноглаз, и все «нормальные
> люди» берут ядра из пакетов своих дистрибутивов.

Ну в чём-то это так. Я тоже вот красноглаз (ну, не я, а контора), ибо свои ядра, но это таки рабочая задача.

Ответить | Правка | ^ к родителю #257 | Наверх | Cообщить модератору

291. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от arisu (ok) on 28-Янв-12, 23:40 
> Сравни затраты по времени и прочему на сборку ядра и на компоновку
> нескольких файликов уже скомпиленного в один тарболл.
> Религия — не мешает. Мешает — разумная лень.

если это ядро нужно один раз — да. если постоянно — я лучше соберу его нормально один раз.

> Увы, всё сложнее. Где-то надо конфиг подложить, где-то драйвера промежуточных шин…

это всё принципиально не кладётся на носитель и не настраивается в сонфиге ядра (конфиг для модуля? в /etc? O_O)

>>> А ты распишешься за _все_ платформы, архитектуры и загрузочные конфигурации, чтобы делать
>>> столь глобальные выводы?
>> что, есть какая-то платформа, под которую ядро можно собрать *только* с условием
>> взлёта с initrd? жду примера тогда. не гипотетического, если что.
> Идею вписывать эти правила в код ядра, пожалуйста, не предлагать.

не предлагаю. это, пардон, какое-то мегаизвращение вообще.

> Угу. И в случае возможности собрать для этого комплект userland'а с каким-нибудь
> даже перлом внутри нестандартный секс резко облегчается.

если это неведома зверушка, то с большой долей вероятности в «универсальном» ядре или чего-нибудь не хватит, или что-нибудь окажется лишним и так далее. к тому же сей случай подпадает как раз под «универсальное ядро с initrd», против которого я ничего не имею.

> А при чём тут «прямо на раутере»?

слабо представляю не-роутер с redboot, например. к тому же оппонент прыгает с темы на тему как ушибленый между лап заяц.

>> ядра? круто. ну, сделай свои «20 секунд», когда обновляешь ядро, угу.
> Зачем?

ты не в курсе, зачем обновляют ядра? O_O

> Ну в чём-то это так.

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

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

а вообще — да, там должен быть список соответствий железяк и драйверов, опции для грубой и тонкой настройки разных вещей типа netfilter и так далее. короче, такой «конфигуратор ядра с человеческим лицом». но я лично не готов заниматься написанием и поддержкой, мне проще сконфигурировать ядро руками и потом просто делать make oldconfig, включая по пути новые плюшки из консоли.

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

Ответить | Правка | ^ к родителю #280 | Наверх | Cообщить модератору

297. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от Аноним (??) on 29-Янв-12, 01:28 
> действительно, программа-конфигуратор, которая после загрузки дистриба обнюхает железяки и сформирует нужный конфиг была бы весьма удобна. в принципе, в ней даже можно считерить немного: если загружено «универсальное» ядро — глянуть на вывод lsmod.

make localyesconfig/localmodconfig ?

Ответить | Правка | ^ к родителю #291 | Наверх | Cообщить модератору

298. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от arisu (ok) on 29-Янв-12, 01:54 
> make localyesconfig/localmodconfig ?

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

Ответить | Правка | ^ к родителю #297 | Наверх | Cообщить модератору

286. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от Клыкастый2 on 28-Янв-12, 22:27 
яростно плюсую каждый абзац. в принципе ты тему закрыл, не знаю что добавить.
Ответить | Правка | ^ к родителю #257 | Наверх | Cообщить модератору

318. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от Ant0 email(??) on 30-Янв-12, 00:10 
>>что, есть какая-то платформа, под которую ядро можно собрать *только* с условием взлёта с initrd? жду примера тогда. не гипотетического, если что.

Была такая задача, система грузиться с усб-флешки:
1) Ядро взлетает с помощью сислинукса (+впиленный в ядро инитрд)
2) Передает управление инитрд, а тот ПРОСТО ждет (sleep 1 в бесконечном цикле), пока не подцепится эта самая усб-флешка самим ядром.
3) После, как подцепилась усб-флешка, с нее монтируется в лууп корень и передается управление иниту.
4) Профит...

Может подскажете, глубокоуважаемый гуру, как сделать то же самое без инитрд?.. ;)

Ответить | Правка | ^ к родителю #257 | Наверх | Cообщить модератору

319. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от arisu (ok) on 30-Янв-12, 02:20 
> Может подскажете, глубокоуважаемый гуру, как сделать то же самое без инитрд?.. ;)

jmp $

Ответить | Правка | ^ к родителю #318 | Наверх | Cообщить модератору

322. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от Kodir (ok) on 30-Янв-12, 12:15 
> А ты распишешься за _все_ платформы, архитектуры и загрузочные конфигурации...

Есть такое мнение, которое я поддерживаю: скрещение ужа с ежом даёт бесполезный кусок колючего г-на. Даже если мобильных применений Линукса на порядки больше десктопных, это не повод делать десктопный линукс таким же убогим, зато "универсальным". Вобщем-то, всё это - плата за Трольвадский "for fun", который ниструя не позаботился о будущем. Ну так зачем тогда рвать ж**у за какие-то универсальные идеалы?? Нужен тупо линукс для десктопа со всеми сопутствующими особенностями:
RAM можно точно ожидать не меньше 512Мб. Хард - от 50Гб (с учётом SSD). Сеть и Тырнет - опциональны и ни в коем случае не должны подразумеваться как единственный источник обновлений. Дисплей и клава обязательны, мышь - по вкусу. Тогда можно получить хорошо заточенную архитектуру, которая не будет приносить проблем 90% юзеров из-за того, что какой-то ЁПРСТ-моторс суёт линуксы под капот.

Ответить | Правка | ^ к родителю #249 | Наверх | Cообщить модератору

311. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от Michael Shigorin email(ok) on 29-Янв-12, 17:50 
>> initrd — гибкое и эффективное решение
> …которое, тащемта, не нужно. достаточно просто собирать ядро под железяку.

Это недистрибутивно и имеет больше шансов вылезти боком при смене железки, в которую воткнут корень.

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

Ответить | Правка | ^ к родителю #242 | Наверх | Cообщить модератору

312. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от arisu (ok) on 29-Янв-12, 17:52 
>> достаточно просто собирать ядро под железяку.
> Это недистрибутивно и имеет больше шансов вылезти боком при смене железки, в
> которую воткнут корень.

одно другому не мешает. emergency ядро с kitchen sink лежит себе отдельно, а работает собраное под железяку.

Ответить | Правка | ^ к родителю #311 | Наверх | Cообщить модератору

87. "Обоснование целесообразности переноса компонентов из корня в..."  +2 +/
Сообщение от daemonpnz (ok) on 27-Янв-12, 15:11 
наберись опыта и практики, а потом уже заявляй безапелляционно, что система без initrd не загрузится.
Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

285. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от netch (ok) on 28-Янв-12, 22:17 
>> А всё необходимое для начальной загрузки я так понимаю он предлагает совать в initrd?!
> Между прочим
> 1. initrd для этого и предназначен.
> 2. оно все уже давно туда засунуто, иначе бы система не грузилась.

Только вот проблема - чтобы обеспечить эквивалент по удобству ремонта (да-да, это не enterprise случай), тот initrd должен содержать как минимум полноценный шелл и возможность его вызвать.

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

2. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Анон on 27-Янв-12, 12:31 
Все правильно. Только название "usr" сбивает с толку, к юзеру это не имеет никакого отношения.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Аноним (??) on 27-Янв-12, 12:40 
смысл имеет:
/bin /lib /sbin - системный софт, необходимый для загрузки и базовый функционал.
/usr/bin /usr/lib - под функционал, доставляемый администратором/пользователем системы
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

105. "Обоснование целесообразности переноса компонентов из корня в..."  +6 +/
Сообщение от anon2 on 27-Янв-12, 16:05 
> Все правильно. Только название "usr" сбивает с толку, к юзеру это не имеет никакого отношения.

конечно, не имеет - ведь это всегда означало "Unix System Resources"

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

191. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Адольф on 27-Янв-12, 21:22 
Кстати в оригинальном AT&T Unix /usr выполняла роль /home
Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

196. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от pavlinux (ok) on 27-Янв-12, 21:43 
Сам придумал или у таких же в википедии прочитал?

/lib наверно Linked Interprocess Binary ?
/home - Here Of My Executables
/boot - Be Out Of True

Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

231. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Пр0х0жий (??) on 28-Янв-12, 01:05 
>> Все правильно. Только название "usr" сбивает с толку, к юзеру это не имеет никакого отношения.
> конечно, не имеет - ведь это всегда означало "Unix System Resources"

Да ну?!
http://lib.ru/MAN/scotutor.txt

Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

5. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Mike Lee on 27-Янв-12, 12:37 
/sbin/init куда положим?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Обоснование целесообразности переноса компонентов из корня в..."  +2 +/
Сообщение от Andrey Mitrofanov on 27-Янв-12, 12:43 
> /sbin/init куда положим?

Вон выше написали: / -> в initrd, /usr -> теперь /

Вот куда засунуть старый initrd?? В UEFI, наверное...

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

43. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Аноним (??) on 27-Янв-12, 14:14 
> Вон выше написали: / -> в initrd, /usr -> теперь /

Походу, вы текста не читали. / -> /usr, а initrd без изменений, т.к. он изначально самодостаточен.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

178. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от СуперАноним on 27-Янв-12, 20:16 
initrd живёт в /boot
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Обоснование целесообразности переноса компонентов из корня в..."  +8 +/
Сообщение от dq0s4y71 (??) on 27-Янв-12, 12:38 
Новости о Поттеринге всегда одни и те же: он опять обосновал, почему нужно что-то куда-то перенести или что-то поломать...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

61. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 14:42 
> Новости о Поттеринге всегда одни и те же: он опять обосновал, почему
> нужно что-то куда-то перенести или что-то поломать...

Это прогресс, детка :)

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

96. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Аноним (??) on 27-Янв-12, 15:35 
>> Новости о Поттеринге всегда одни и те же: он опять обосновал, почему
>> нужно что-то куда-то перенести или что-то поломать...
> Это прогресс, детка :)

Это фэйк, детка. Словесами ошибочно выдаваемый за якобы прогресс.

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

126. "Обоснование целесообразности переноса компонентов из корня в..."  –3 +/
Сообщение от Аноним (??) on 27-Янв-12, 17:26 
>>> Новости о Поттеринге всегда одни и те же: он опять обосновал, почему
>>> нужно что-то куда-то перенести или что-то поломать...
>> Это прогресс, детка :)
> Это фэйк, детка. Словесами ошибочно выдаваемый за якобы прогресс.

Это именно прогресс - FHS становится всё лучше и удобнее.
Интересно, появится всё-таки обоснованная критика улучшений FHS, или в её существование по прежнему надо свято верить?

Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

252. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Аноним (??) on 28-Янв-12, 10:34 
> Это прогресс, детка :)

Тасовка карт в колоде прогрессом не является.

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

270. "Обоснование целесообразности переноса компонентов из корня в..."  –1 +/
Сообщение от Аноним (??) on 28-Янв-12, 13:02 
> Тасовка карт в колоде прогрессом не является.

Комментирование на форуме - тоже.
А вот слияние перенос /bin в /usr/bin - безусловно является. Почему именно - объяснено в статье.

Ответить | Правка | ^ к родителю #252 | Наверх | Cообщить модератору

12. "Обоснование целесообразности переноса компонентов из корня в..."  –4 +/
Сообщение от I am (??) on 27-Янв-12, 12:55 
И да, нахрена /usr/bin, /usr/sbin, /bin, /sbin... Особо бесит, когда в PATH по дефолту нет /sbin.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Обоснование целесообразности переноса компонентов из корня в..."  –3 +/
Сообщение от YetAnotherOnanym on 27-Янв-12, 13:14 
Ну так поправьте .yourshellrc, в чём проблема?
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

32. "Обоснование целесообразности переноса компонентов из корня в..."  +2 +/
Сообщение от Xaionaro (ok) on 27-Янв-12, 13:46 
> Особо бесит, когда в PATH по дефолту нет /sbin.

О да, это определённо является причиной слить /sbin и /usr/sbin. Не смотря на то, что если в PATH нет /sbin, то и /usr/sbin там обычно тоже нет. Пофиг что можно просто поправить конфиги, лучше всю систему перелопатить.

> И да, нахрена /usr/bin, /usr/sbin, /bin, /sbin

У них разные функции, см. FHS.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

287. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Клыкастый2 on 28-Янв-12, 22:47 
> Пофиг что можно просто поправить конфиги, лучше всю систему перелопатить.

Всё для apt-get-kiddies. закончится всё одним разделом, /linux /program_files, файлом подкачки и скачкой rpm с интернет помоек.

>> И да, нахрена /usr/bin, /usr/sbin, /bin, /sbin
> У них разные функции, см. FHS.

что-то мне подсказывает что дальше вики дело не двинется, а мнение не поменяется.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

97. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 15:37 
> И да, нахрена /usr/bin, /usr/sbin, /bin, /sbin... Особо бесит, когда в PATH
> по дефолту нет /sbin.

По секьюрити. Не?

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

108. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 16:28 
>> И да, нахрена /usr/bin, /usr/sbin, /bin, /sbin... Особо бесит, когда в PATH
>> по дефолту нет /sbin.
> По секьюрити. Не?

Не. Ничто не мешает пользователю поместить в PATH что угодно.

Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

131. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от ZloySergant (ok) on 27-Янв-12, 18:09 
>> По секьюрити. Не?
>Не. Ничто не мешает пользователю поместить в PATH что угодно.

Ничто не мешает поставить запрет на запуск из $PREFIX/sbin всем, кроме отдельно взятых пользователей.

Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

142. "Обоснование целесообразности переноса компонентов из корня в..."  –1 +/
Сообщение от Аноним (??) on 27-Янв-12, 18:25 
>>> По секьюрити. Не?
>>Не. Ничто не мешает пользователю поместить в PATH что угодно.
> Ничто не мешает поставить запрет на запуск из $PREFIX/sbin всем, кроме отдельно
> взятых пользователей.

RBAC уже реализован в пингвине? Хоть в каком-нибудь? С профилями выполнения?

Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

147. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от ZloySergant (ok) on 27-Янв-12, 18:30 
>>>> По секьюрити. Не?
>>>Не. Ничто не мешает пользователю поместить в PATH что угодно.
>> Ничто не мешает поставить запрет на запуск из $PREFIX/sbin всем, кроме отдельно
>> взятых пользователей.
> RBAC уже реализован в пингвине? Хоть в каком-нибудь? С профилями выполнения?

Оно как-бы и не обязательно для такого запрета. man 5 group

Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

313. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Michael Shigorin email(ok) on 29-Янв-12, 18:05 
> RBAC уже реализован в пингвине? Хоть в каком-нибудь? С профилями выполнения?

И давно.  Раз осилили четыре буквы для повторения -- идите-ка да читайте и дальше сами.

Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

157. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 18:56 
> Ничто не мешает поставить запрет на запуск из $PREFIX/sbin всем, кроме отдельно
> взятых пользователей.

Это вообще никак не связано с содержимым переменной PATH.
Хотя твоё знание man group меня восхитило, молодец.

Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

237. "Обоснование целесообразности переноса компонентов из корня в..."  +2 +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 28-Янв-12, 04:02 
>> И да, нахрена /usr/bin, /usr/sbin, /bin, /sbin... Особо бесит, когда в PATH
>> по дефолту нет /sbin.
> По секьюрити. Не?

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

Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

13. "Обоснование целесообразности переноса компонентов из корня в..."  –4 +/
Сообщение от Аноним (??) on 27-Янв-12, 12:58 
>Необоснованной

Да что вы говорите?!

>В настоящее время разные дистрибутивы Linux и Unix-системы по разному формируют состав /bin и /usr/bin

Да. И что это повод прогибаться под коммерческие системы a-la макос или солярки ?
Надо использовать позитивный опыт, - это да, - но пока оснований для такого я вот не вижу. Если уж так надо сблизится, то почему не прогнуть хомячков макоси? Или пользователей некоммерческого линукса не жалко?

>что позволит упростить организацию бездисковых систем

Вот и делайте отдельную версию дистра для них. И причем здесь серверная (да и десктопная тоже) ось?

>Упрощение формирования гостевых окружений для систем виртуализации

Вот с этого и надо было начинать! То есть Поттеринг (читай, - редхат) вздумал над линуксоидами поэксперементировать ради своего перспективно-облачного направления! Вот в это я верю!(((

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

48. "Обоснование целесообразности переноса компонентов из корня в..."  –1 +/
Сообщение от Аноним (??) on 27-Янв-12, 14:20 
> Да что вы говорите?!

Да. А вы можете привести пример обоснованной критики сабжа?
Именно критики, а не панических воплей по поводу придуманных на ходу страшных сказок.

> Да. И что это повод прогибаться под коммерческие системы a-la макос или солярки ?

У них сделано лучше и удобнее, чем в линуксе. Это повод.

> Вот и делайте отдельную версию дистра для них. И причем здесь серверная (да и десктопная тоже) ось?

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

> Вот с этого и надо было начинать! То есть Поттеринг (читай, -
> редхат) вздумал над линуксоидами поэксперементировать ради своего перспективно-облачного
> направления! Вот в это я верю!(((

Вы утверждаете, что виртуализация нужна только редхату, да? :)

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

150. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от ganelon email(ok) on 27-Янв-12, 18:42 
>> Да. И что это повод прогибаться под коммерческие системы a-la макос или солярки ?
> У них сделано лучше и удобнее, чем в линуксе. Это повод.

Таки ви в этом уверены? Вы уважаемый походу ни разу с макосью не связывались.
Там установка текстурпака на майнкрафт вызывает определённые затруднения из за неимоверной кривизны тамошней файловой системы, не говоря уж о более сложных вещах.

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

314. "'Обоснование' целесообразности переноса компонентов"  +2 +/
Сообщение от Michael Shigorin email(ok) on 29-Янв-12, 18:42 
>> Да что вы говорите?!
> Да. А вы можете привести пример обоснованной критики сабжа?

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, да. :]

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

317. "'Обоснование' целесообразности переноса компонентов"  +/
Сообщение от mihail krijich on 29-Янв-12, 18:55 
> Слайды (больше -- на http://tinyurl.com/rhbz-separate-usr):

грамотно.

Ответить | Правка | ^ к родителю #314 | Наверх | Cообщить модератору

14. "Обоснование целесообразности переноса компонентов из корня в..."  +5 +/
Сообщение от anonymous (??) on 27-Янв-12, 13:01 
Считаю его идею достаточно прогрессивной, так как достигается унификация,  выигрыш будет очень значительным на бездисковых рабочих местах и в разных средах для виртуализации. Пример с соляркой подтверждает.

Противникам: есть такой дистр, зовется Calculate, у него обновление так и производится: обновляем рут-раздел, если прокатило - после перезагрузки рут-раздел будет сменен на обновленный, в случае чего можно будет откатить все назад. Если все ок - следующий раз будет использоваться старый рут-раздел. В данном случае все будет гораздо проще (нету костыля, который это делает), и без перезагрузки.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

31. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Anoynymous on 27-Янв-12, 13:46 
> обновляем рут-раздел, если прокатило - после перезагрузки рут-раздел будет сменен на обновленный

И как вы узнаете, что прокатило? а то ведь может показаться, что прокатило, а после перезагрузки - что не прокатило :)

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

38. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от anonym on 27-Янв-12, 14:09 
Да пребудет с Вами великий mount.
Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

98. "Обоснование целесообразности переноса компонентов из корня в..."  –4 +/
Сообщение от Аноним (??) on 27-Янв-12, 15:39 
> Да пребудет с Вами великий mount.

Валяй, набери приличную маунт-команду на сериальной консоли энтерпрайз-сервера без ошибок, когда шелл без всяких обвязок даже автокомплита не дает сделать, и хистори отсутствует, а тебя в ж.пу клюет большой начальник "Стартуй сервер, сцук, немедленно, сейчас 15-00, а не то твою шкурку гвоздями 100 на заднем дворе приколотим к стенке!".

Админы локалхоста такие админы...

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

267. "Обоснование целесообразности переноса компонентов из корня в..."  +2 +/
Сообщение от Аноним (??) on 28-Янв-12, 13:00 
> Валяй, набери приличную маунт-команду на сериальной консоли энтерпрайз-сервера без ошибок,
> когда шелл без всяких обвязок даже автокомплита не дает сделать, и
> хистори отсутствует, а тебя в ж.пу клюет большой начальник "Стартуй сервер,
> сцук, немедленно, сейчас 15-00, а не то твою шкурку гвоздями 100
> на заднем дворе приколотим к стенке!".

А почему набор команды кажется тебе непосильной задачей?
Ты не умеешь читать или печатать?

Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

83. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от anonymous (??) on 27-Янв-12, 15:06 
спроси у разработчиков calculate.... я пользовался их дистром - мне понравилась сама идея, все четко и по полкам.
Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

124. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от yurkis (ok) on 27-Янв-12, 17:23 
>Пример с соляркой подтверждает.

Солярка, на сколько мне помнится позволяет откатываться снепшотами. Хотя при этом таки структура каталогов помогает.

>В данном случае все будет гораздо проще (нету костыля, который это делает), и без перезагрузки.

Кстате, интереса ради. unmount/mount там же (в /usr) лежать будут?

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

139. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Аноним (??) on 27-Янв-12, 18:22 
>>Пример с соляркой подтверждает.
> Солярка, на сколько мне помнится позволяет откатываться снепшотами. Хотя при этом таки
> структура каталогов помогает.

Не для рутового пула.

>>В данном случае все будет гораздо проще (нету костыля, который это делает), и без перезагрузки.
> Кстате, интереса ради. unmount/mount там же (в /usr) лежать будут?

Ага, два раза.


Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

16. "Обоснование целесообразности переноса компонентов из корня в..."  –1 +/
Сообщение от Sas (ok) on 27-Янв-12, 13:05 
То они выпиливают /var/run в корень, теперь они запиливают все в /usr
Как нить ночью обновишься, а все что было в /var сейчас в корне
А все из корня в /usr
Как вам /usr/root, /usr/dev, /usr/proc, /spool, /log
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "Обоснование целесообразности переноса компонентов из корня в..."  +19 +/
Сообщение от Аноним (??) on 27-Янв-12, 13:21 
Не ходи за Поттеринга,
Ничего хорошего.
Утром встанешь, /usr набок,
А /sbin взъерошена.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

94. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 15:35 
+1 : Маразм менять в устаканеной системе расположение каталогов из-за пары-тройки приложений. IMHO такая система отходит постепенно от UNIX-way.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

115. "Обоснование целесообразности переноса компонентов из корня в..."  +2 +/
Сообщение от Аноним (??) on 27-Янв-12, 16:39 
> +1 : Маразм менять в устаканеной системе расположение каталогов из-за пары-тройки приложений.
> IMHO такая система отходит постепенно от UNIX-way.

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

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

168. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Аноним (??) on 27-Янв-12, 19:51 
> +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 это заработает, ась?

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

172. "Обоснование целесообразности переноса компонентов из корня в..."  +4 +/
Сообщение от Аноним (??) on 27-Янв-12, 20:01 
$ 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)

Учись выбирать правильный дистибутив.

Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

288. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Клыкастый2 on 28-Янв-12, 23:12 
аналогично


Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

209. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Михрютка on 27-Янв-12, 22:28 
> $ 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

Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

220. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Пр0х0жий (??) on 27-Янв-12, 23:35 
> И без /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)

Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

283. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от netch (ok) on 28-Янв-12, 22:03 
>> +1 : Маразм менять в устаканеной системе расположение каталогов из-за пары-тройки приложений.
>> IMHO такая система отходит постепенно от UNIX-way.
> Это 10 федора, Поттеринг еще в школу ходил. В /sbin статические бинарники,
> говорите, ась? И без /usr это заработает, ась?

[/usr]/sbin последнее время были не статические, а такие, которые не-админу нафиг не сдались.

Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

315. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Michael Shigorin email(ok) on 29-Янв-12, 18:49 
> От 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
$ _

Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

23. "Обоснование целесообразности переноса компонентов из корня в..."  +2 +/
Сообщение от netc (??) on 27-Янв-12, 13:28 
однозначно поддерживаю +1 или даже +100

реально это будет гораздо лучше и удобнее

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору
Часть нити удалена модератором

185. "Обоснование целесообразности переноса компонентов из корня в..."  –1 +/
Сообщение от Аноним (??) on 27-Янв-12, 20:57 
> Успокойтесь, я не хочу холиварить обоснованная критика или нет, но автор не
> имеет право в новости судить об этом, :). Говоря "необоснованная" он
> лишь навязывает своё мнение, а не пересказывает факты. Это неэтично, просто.

Он именно пересказывает факты - обоснованной критики не-бы-ло.

Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

199. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Xaionaro (ok) on 27-Янв-12, 21:48 
>> Успокойтесь, я не хочу холиварить обоснованная критика или нет, но автор не
>> имеет право в новости судить об этом, :). Говоря "необоснованная" он
>> лишь навязывает своё мнение, а не пересказывает факты. Это неэтично, просто.
> Он именно пересказывает факты - обоснованной критики не-бы-ло.

Любое мажорное изменение всегда неприятно. Всегда нужна какая-то адаптация к новым условиям. А востребованность в адаптации - это всегда плохо. Вопрос о том насколько это целесообразно - это уже отдельный вопрос, любой ответ на который всегда будет строго субъективным. Обоснованная критика или нет, определяется тем, целесообразно терпеть эти изменения или нет. И целесообразно или нет, как я уже сказал, вопрос субъективный. Т.ч. никто не имеет право заявлять однозначно обоснованная то была критика или нет.

Ответить | Правка | ^ к родителю #185 | Наверх | Cообщить модератору

206. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 22:19 
> Любое мажорное изменение всегда неприятно. Всегда нужна какая-то адаптация к новым условиям.

Ничего подобного. Например изменения о которых говорит Поттеринг приятны и не требуют никакой адаптации.

> И целесообразно или нет, как
> я уже сказал, вопрос субъективный. Т.ч. никто не имеет право заявлять
> однозначно обоснованная то была критика или нет.

Это технический вопрос, а не философский. Целесообразность определяется плюсами, подробное описание которых есть в статье Поттеринга.
И обоснованность критики также определяется техническими специалистами, работающими над поддержкой и улучшением дистрибутивов. Одним из которых и является Поттеринг.

Ответить | Правка | ^ к родителю #199 | Наверх | Cообщить модератору

316. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Michael Shigorin email(ok) on 29-Янв-12, 18:52 
> Например изменения о которых говорит Поттеринг приятны и не требуют никакой адаптации.

Врёте.  См. выше ссылки на lwn.

Ответить | Правка | ^ к родителю #206 | Наверх | Cообщить модератору

36. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от xoomer (ok) on 27-Янв-12, 13:55 
"Возможность использования нескольких разделов /usr для загрузки разных версий или состояний дистрибутива, например, в процессе обновления можно сохранить старое содержимое в отдельном разделе и вернуться на него в случае проблем."

А как тогда быть с /home/.* ? Врядли все конфиги софта будут совместимы с разными версиями этого же софта.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

40. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от xxx (??) on 27-Янв-12, 14:10 
> А как тогда быть с /home/.* ? Врядли все конфиги софта будут
> совместимы с разными версиями этого же софта.

Это необоснованная критика!!!  /home/ должен быть на одном разделе с /usr Но об этом решено было тактично умолчать.


Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

56. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 14:31 
> А как тогда быть с /home/.* ? Врядли все конфиги софта будут совместимы с разными версиями этого же софта.

Если автор софта ломает совместимость конфига, но при этом не меняет его имя/расположение - за такое надо бить по сусалам.

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

169. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 19:57 
Это не решит проблему. Такое происходит чаще чем хотелось бы, и даже среди вполне серьезного софта. И будет происходить.
Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

276. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 28-Янв-12, 20:22 
> Если автор софта ломает совместимость конфига, но при этом не меняет его
> имя/расположение - за такое надо бить по сусалам.

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

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

84. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 15:07 
> "Возможность использования нескольких разделов /usr для загрузки разных версий или состояний
> дистрибутива, например, в процессе обновления можно сохранить старое содержимое в отдельном
> разделе и вернуться на него в случае проблем."
> А как тогда быть с /home/.* ? Врядли все конфиги софта будут
> совместимы с разными версиями этого же софта.

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

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

134. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 18:19 
>> "Возможность использования нескольких разделов /usr для загрузки разных версий или состояний
>> дистрибутива, например, в процессе обновления можно сохранить старое содержимое в отдельном
>> разделе и вернуться на него в случае проблем."
>> А как тогда быть с /home/.* ? Врядли все конфиги софта будут
>> совместимы с разными версиями этого же софта.
> Точно так же, как и сейчас - либо использовать софт, у авторов
> которого хватает ума не ломать конфиги, либо сипользовать несколько домашних разделов
> или снэпшотов одного раздела.

Ты где снэпшоты на UFS/EXTx нашел, поделись травой? Пару карманов насыпь?

Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

151. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 18:43 
> Ты где снэпшоты на UFS/EXTx нашел, поделись травой? Пару карманов насыпь?

Научись читать:
1. ext нигде не упоминается.
2. значение союза "либо" - представление альтернативы.

Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

278. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от mihail krijich on 28-Янв-12, 20:32 
> Ты где снэпшоты на UFS/EXTx нашел, поделись травой? Пару карманов насыпь?

при чем тут, в обсуждении линуха, ufs - не понятно, но все же: что вы курили, когда решили что в уфс нет снапшетов?

Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

171. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 20:00 
> использовать софт, у авторов которого хватает ума не ломать конфиги

Т.е. "не нужно" во весь рост? Пардон, не катит.

> сипользовать несколько домашних разделов

В большинстве случаев это лишний геморрой или невозможно.

> или снэпшотов одного раздела.

В большинстве случаев это лишний геморрой или невозможно.

Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

173. "Обоснование целесообразности переноса компонентов из корня в..."  –1 +/
Сообщение от Аноним (??) on 27-Янв-12, 20:11 
> В большинстве случаев это лишний геморрой или невозможно.

ниасилил? :)
ну дык это уж точно не Поттеринга проблемы.

Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

180. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 20:19 
Я-то осилил. Но на десктопах, да еще и для преконфигуренных дистров это гемор или нерационально.
Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

194. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 21:33 
> Я-то осилил. Но на десктопах, да еще и для преконфигуренных дистров это гемор или нерационально.

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

Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

52. "Обоснование целесообразности переноса компонентов из корня в..."  +6 +/
Сообщение от xxx (??) on 27-Янв-12, 14:25 
Вообще волна необоснованной критики в осоновном была вида:
"Леннарт - лох!"
"Леннарт, зачем ты сломал наш Linux?"
"Леннарт, когда ты допилишь пульаудио?"
"Леннарт, ну сколько можно?"
"Леннарт, где ты живешь? Куда высылать яд?"

И ни на один их этих, волнующих сообщество, вопросов он так и не ответил! Так может критика была обоснованной?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

54. "Обоснование целесообразности переноса компонентов из корня в..."  +4 +/
Сообщение от Аноним (??) on 27-Янв-12, 14:29 
> Вообще волна необоснованной критики в осоновном была вида:
> "Леннарт - лох!"
> "Леннарт, зачем ты сломал наш Linux?"
> "Леннарт, когда ты допилишь пульаудио?"
> "Леннарт, ну сколько можно?"
> "Леннарт, где ты живешь? Куда высылать яд?"

Забыли еще
"Леннарт, ты сломал наш юниксвей!"

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

55. "Обоснование целесообразности переноса компонентов из корня в..."  +4 +/
Сообщение от skJ on 27-Янв-12, 14:29 
Что за паника, не совсем понятно.
Всегда было в рекомендациях, в корне - необходимое для загрузки, в /usr - системный софт, в /usr/local - пользовательский софт.
По-моему, все правильно делают.
Если бы они аналогично *BSD стали придерживатся традиций и тоже доп софт пихать в /usr/local, а конфиги его в /usr/local/etc - было б совсем прекрасно. В той же фре никогда не надо гадать, где что от какой софтины лежит. В линуксе частенько приходится пробежать по всем бинам/сбинам, либам, шарам, не айс..
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

67. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 14:51 
> Всегда было в рекомендациях, в корне - необходимое для загрузки, в /usr
> - системный софт, в /usr/local - пользовательский софт.
> По-моему, все правильно делают.

На самом деле, очень нелогично. Например, зачем пихать в корень все необходимое для загрузки, если все то же самое должно лежать в initrd, по определению?
Или: зачем в линуксе нужно деление на мир/порты? В *BSD это деление понятно: мало разработчиков, приходится жертвовать качеством поддержки некритичного софта, и он вынесен в порты. Но в линуксе таких проблем нет, там все пакеты поддерживаются одинаково аккуратно.

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

103. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от YetAnotherOnanym on 27-Янв-12, 16:01 
> все пакеты поддерживаются одинаково аккуратно

ORLY?

Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

122. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 17:20 
>> все пакеты поддерживаются одинаково аккуратно
> ORLY?

Именно так. А ты думал почему яндекс с рамблером от бзди сбежали как от чумы?

Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

282. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от netch (ok) on 28-Янв-12, 22:02 
>>> все пакеты поддерживаются одинаково аккуратно
>> ORLY?
> Именно так. А ты думал почему яндекс с рамблером от бзди сбежали
> как от чумы?

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

Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

292. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 29-Янв-12, 00:21 
> Потому что достаточного интеллекта на админов не набрали, весь разобран.
> Тут действительно приходится держаться за mainstream.

butthurt? напрасно, будь выше этого: от того, что ты обзываешь админов рамблера с яндексом перечисленные ими технические недостатки бзди не исчезнут.

Ответить | Правка | ^ к родителю #282 | Наверх | Cообщить модератору

329. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от netch (ok) on 30-Янв-12, 13:59 
>> Потому что достаточного интеллекта на админов не набрали, весь разобран.
>> Тут действительно приходится держаться за mainstream.
> butthurt? напрасно, будь выше этого: от того, что ты обзываешь админов рамблера
> с яндексом перечисленные ими технические недостатки бзди не исчезнут.

Недостатки - да. _Перечисленные ими_ - нет. Там 90% было клиническим бредом.
Возможно, им реально повлияли какие-то другие недостатки, против этого не буду спорить - но не те, что были открыто названы.

Ответить | Правка | ^ к родителю #292 | Наверх | Cообщить модератору

324. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Michael Shigorin email(ok) on 30-Янв-12, 13:48 
>>>> все пакеты поддерживаются одинаково аккуратно
>>> ORLY?
>> Именно так.

Отнюдь.

>> А ты думал почему яндекс с рамблером от бзди сбежали как от чумы?
> Потому что достаточного интеллекта на админов не набрали, весь разобран.
> Тут действительно приходится держаться за mainstream.

Валик, там были две разные стопки причин, как понимаю.  За рамблер не скажу, а в яндексе интеллекта у админов (и судя по виденному, и манагеров) вообще-то прилично.

Ответить | Правка | ^ к родителю #282 | Наверх | Cообщить модератору

328. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от netch (ok) on 30-Янв-12, 13:58 
>>> А ты думал почему яндекс с рамблером от бзди сбежали как от чумы?
>> Потому что достаточного интеллекта на админов не набрали, весь разобран.
>> Тут действительно приходится держаться за mainstream.
> Валик, там были две разные стопки причин, как понимаю.  За рамблер
> не скажу, а в яндексе интеллекта у админов (и судя по
> виденному, и манагеров) вообще-то прилично.

Я не про админов верхнего уровня, а про массу.
А на верхнем уровне там сплошные тараканы в головах. Последний переезд на линукс (независимо от конечной полезности) обоснован был сплошь дырявыми аргументами.

Ответить | Правка | ^ к родителю #324 | Наверх | Cообщить модератору

335. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Michael Shigorin email(ok) on 30-Янв-12, 14:56 
> А на верхнем уровне там сплошные тараканы в головах. Последний переезд на
> линукс (независимо от конечной полезности) обоснован был сплошь дырявыми аргументами.

В рамблере -- насколько понимаю, да, а в яндексе -- отнюдь.  Правда, там с фряшными админами и не общался, сплошь линуксоводы знакомые.

Ответить | Правка | ^ к родителю #328 | Наверх | Cообщить модератору

245. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от arisu (ok) on 28-Янв-12, 09:40 
>> все пакеты поддерживаются одинаково аккуратно
> ORLY?

да, все три. остальные в процессе, и их не считают.

Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

111. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 16:31 
На системах с малым количеством памяти полезнее загрузить из ядра модуль к рутовой FS, чем вываливать в память раскормленный initrd. Особенно это касается устройств с 8-16-32 Мб озей
Если же на такие системы нужно забить, тогда нужно явно осознавать, куда стремится дистрибутив - на десктопы онли или к широкому применению. А также все производные дистрибутивы от него.
Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

113. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Аноним (??) on 27-Янв-12, 16:37 
> На системах с малым количеством памяти полезнее загрузить из ядра модуль к
> рутовой FS, чем вываливать в память раскормленный initrd. Особенно это касается
> устройств с 8-16-32 Мб озей

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

Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

275. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от uniman (ok) on 28-Янв-12, 15:00 
>В *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 или симлинками.

Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

323. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Michael Shigorin email(ok) on 30-Янв-12, 13:45 
> Но в линуксе [...] все пакеты поддерживаются одинаково аккуратно.

Врёте.

Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

73. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Аноним (??) on 27-Янв-12, 14:58 
> Что за паника, не совсем понятно.
> Всегда было в рекомендациях, в корне - необходимое для загрузки, в /usr
> - системный софт, в /usr/local - пользовательский софт.
> По-моему, все правильно делают.
> Если бы они аналогично *BSD стали придерживатся традиций и тоже доп софт
> пихать в /usr/local, а конфиги его в /usr/local/etc - было б
> совсем прекрасно. В той же фре никогда не надо гадать, где
> что от какой софтины лежит. В линуксе частенько приходится пробежать по
> всем бинам/сбинам, либам, шарам, не айс..

Если бы у тебя был моск - ты бы прочитал ман к dpkg и нашёл там опцию -S

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

279. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от mihail krijich on 28-Янв-12, 20:42 
>[оверквотинг удален]
>> Всегда было в рекомендациях, в корне - необходимое для загрузки, в /usr
>> - системный софт, в /usr/local - пользовательский софт.
>> По-моему, все правильно делают.
>> Если бы они аналогично *BSD стали придерживатся традиций и тоже доп софт
>> пихать в /usr/local, а конфиги его в /usr/local/etc - было б
>> совсем прекрасно. В той же фре никогда не надо гадать, где
>> что от какой софтины лежит. В линуксе частенько приходится пробежать по
>> всем бинам/сбинам, либам, шарам, не айс..
> Если бы у тебя был моск - ты бы прочитал ман к
> dpkg и нашёл там опцию -S

Если бы у разработчиков был мозг, то они бы не устраивали помойки изначально, не устраивали бы идиотизма: "без /usr система все равно не грузится", а как следствие, не нужно было получившуюся помойку сваливать в одну кучу и не было бы тезисов: "Возможность использования нескольких разделов /usr для загрузки разных версий или состояний дистрибутива", "Упрощение формирования гостевых окружений для систем виртуализации", т.к. это было бы доступно изначально, например так, как это доступно во фре.

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

293. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 29-Янв-12, 00:24 
> Если бы у разработчиков был мозг, то они бы не устраивали помойки
> изначально, не устраивали бы идиотизма: "без /usr система все равно не
> грузится"

Не бзди - попробуй удалить /usr на бзде и она точно так же не загрузится.

Ответить | Правка | ^ к родителю #279 | Наверх | Cообщить модератору

299. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от mihail krijich on 29-Янв-12, 05:27 
>> Если бы у разработчиков был мозг, то они бы не устраивали помойки
>> изначально, не устраивали бы идиотизма: "без /usr система все равно не
>> грузится"
> Не бзди - попробуй удалить /usr на бзде и она точно так
> же не загрузится.

В многопользовательский режим - не загрузится, будет ругаться на отсутствие /usr/libexec/getty, в однопользовательский режим - без проблем.
Без /usr/local, а именно там все, что не входит в мир, так же загрузится без проблем.

Ответить | Правка | ^ к родителю #293 | Наверх | Cообщить модератору

303. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Аноним (??) on 29-Янв-12, 12:14 
> В многопользовательский режим - не загрузится, будет ругаться на отсутствие /usr/libexec/getty,
> в однопользовательский режим - без проблем.

Ещё раз тебе говорю: не бзди!
GNU/Linux тоже без проблем загрузится в однопользовательский режим.

Ответить | Правка | ^ к родителю #299 | Наверх | Cообщить модератору

309. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от mihail krijich on 29-Янв-12, 15:58 
> GNU/Linux тоже без проблем загрузится в однопользовательский режим.

название дистрибутива скромно опускаем?

Ответить | Правка | ^ к родителю #303 | Наверх | Cообщить модератору

68. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Аноним email(??) on 27-Янв-12, 14:52 
a kak mountit /usr esli mount budet v /usr/bin lejat ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

72. "Обоснование целесообразности переноса компонентов из корня в..."  –1 +/
Сообщение от Аноним (??) on 27-Янв-12, 14:57 
> a kak mountit /usr esli mount budet v /usr/bin lejat ?

А как до этого монтировали корень, если mount лежал в корне? :)
initrd рулит.

// Правда, в ядре есть костыли для монтирования корня без initrd, но этот жуткий изврат скорее для эмбеддовки.

Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

114. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Аноним (??) on 27-Янв-12, 16:39 
> // Правда, в ядре есть костыли для монтирования корня без initrd, но
> этот жуткий изврат скорее для эмбеддовки.

Это жуткий изврат, потому что подходом с initrd по умолчанию пользуются установщики дистрибутивов, заранее рассчитанные на незнакомое железо?
Или это жуткий изврат, потому что у вас лично не возникало желания и необходимости делать именно так?
Или для этого требуется правильно скомпилять ядро, запихнув не модулями, а именно в ядро - драйвер FS корня и дискового контроллера, а у вас этого не получалось?

Критерии жуткости и извращения, пожалуйста.

Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

167. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от el torito email on 27-Янв-12, 19:44 
В бытность админом ни на одном хосте не имел нужды в initrd. А тебя послушать - так это якобы обязательная вещь. Глупости же говоришь, да по сто раз повторяешь. Стыдоба.
Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

109. "Обоснование целесообразности переноса компонентов из корня в..."  –1 +/
Сообщение от anonymous (??) on 27-Янв-12, 16:29 
Что-то жиденькое обоснование какое-то.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

127. "Обоснование целесообразности переноса компонентов из корня в..."  +2 +/
Сообщение от Xasd (ok) on 27-Янв-12, 17:29 
> Что-то жиденькое обоснование какое-то.

зато обоснования "поэтому НЕ нужно переностить всё в /usr/" -- ещё более жиденькое :-D

сомое частое это: "я уже привык вот так, и не хочу менять" :)

на втором месте это:
"у меня "/bin/" и "/usr/" на разных разделах. и допустим повредился раздел "/usr/", и я делаю failsafe-загрузку и запускаю "/bin/fsck" для "usr"-раздела"
-- вообще притянуто ЗАУШИ както.. чессслово.
(сколько раз у меня повреждался раздел "/", но сёравно это не мешало замонтировать его в режиме readonly и с негоже запустить fsck для его-же-собственной проверки.
и потом даже не объясняется почему это вдруг раздел "/usr/" обезательно поломается (да так сильно, что даже замонтироваться в режиме readonly не сможет!), а раздел "/bin/" якобы не может поломатся :-D :-D)

на третьем месте: "потеряется совместимость со старыми программами" -- вообще глупейший из контр-доводов. так как совместимость только улучшится :-)

Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

146. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от anonymous (??) on 27-Янв-12, 18:30 
>сколько раз у меня повреждался раздел "/", но сёравно это не мешало замонтировать его в режиме readonly и с негоже запустить fsck для его-же-собственной проверки.

Опровержение есть твой сомнительный опыт? С чего тебе должны верить на слово? Вдруг ты нагло врёшь? Тем более никакой информации ни про файловую систему, ни про характер повреждения ты не привёл. Может там и повреждения не было, а просто проверка фс после нескольких ремоунтов.


>зато обоснования "поэтому НЕ нужно переностить всё в /usr/" -- ещё более жиденькое :-D

А тут и обосновать нечего. Обосновать должен тот, кто проталкивает изменения. Но, как видно, аргументы жиденькие для таких серьёзных изменений. Вот например "упрощение формирования гостевых окружений". Что тут собрались упрощать? В чём заключается упрощение?

Или вот "шедевр": "Возможность использования нескольких разделов /usr для загрузки разных версий или состояний дистрибутива.". Сразу вопрос, а можно ли systemd на этапе загрузки указать, какой раздел /usr монтировать? Только вот ведь незадача, все его сервисы лежат в /usr. Какие костыли придётся использовать для решения этой задачи? Пихать все потроха и зависимости systemd в initrd?

Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

154. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 18:46 
> А тут и обосновать нечего. Обосновать должен тот, кто проталкивает изменения.

Обоснования приведены в статье по ссылке. Попробуй её прочитать. Если не поймёшь с первого раза - попробуй прочитать ещё раз.

> Вот например "упрощение формирования гостевых окружений". Что тут собрались упрощать? В чём заключается упрощение?

Это тоже описано в статье по ссылке. Попробуй её прочитать. Если не поймёшь с первого раза - попробуй прочитать ещё раз.

Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

164. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от anonymous (??) on 27-Янв-12, 19:24 
> Это тоже описано в статье по ссылке. Попробуй её прочитать. Если не
> поймёшь с первого раза - попробуй прочитать ещё раз.

Нет, всего этого не написано в статье. Если ты уверен в обратном, то прочитай ещё раз, пока не убедишься, что там этого нет. Если по-прежнему в тебе горит уверенность, что там что-то есть, обратись к специалистам. Тебе помогут.

Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

174. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 20:13 
>> Это тоже описано в статье по ссылке. Попробуй её прочитать. Если не
>> поймёшь с первого раза - попробуй прочитать ещё раз.
> Нет, всего этого не написано в статье.

Я же ясно сказал: если не понял - читай ещё раз. До тех пор, пока не дойдёт.

Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

326. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Michael Shigorin email(ok) on 30-Янв-12, 13:55 
> Я же ясно сказал: если не понял - читай ещё раз. До тех пор, пока не дойдёт.

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

Вот они, гримасы капитализма -- в данном случае в виде "популярности" как метрики и пиара как непременной составляющей технического процесса...

Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

325. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Michael Shigorin email(ok) on 30-Янв-12, 13:53 
> сомое частое это: "я уже привык вот так, и не хочу менять" :)

Если бы у Вас был опыт, то знали бы цену принципу "работает -- не трогай".

> на втором месте это:
> "у меня "/bin/" и "/usr/" на разных разделах. и допустим повредился раздел
> "/usr/", и я делаю failsafe-загрузку и запускаю "/bin/fsck" для "usr"-раздела"
> -- вообще притянуто ЗАУШИ както.. чессслово.
> (сколько раз у меня повреждался раздел "/", но сёравно это не мешало

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

> на третьем месте: "потеряется совместимость со старыми программами" -- вообще
> глупейший из контр-доводов. так как совместимость только улучшится :-)

Не замечал такого довода, но цена Вашему идентична -- ломаный грош.

Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

117. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 17:01 
ну, я например не использую initrd, у меня и ядро то обычно монолитно.

получается нерациональная трата места, копируя файлы для initrd и даже cо сжатием их, всё равно будет больше занято места как на носителе, так и в памяти. не вижу причин переносить всё в /usr, тем более, распихивая линки потом - науха переносить то, если линки оставить придётся?

мне гораздо интереснее разделить доступ, когда одна точка монтирования для записи, другая - для чтения только. например, все файлы для записи скидывать в /var - /var/etc, /var/tmp, /var/run, /var/srv, /var/home и тд

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

119. "Обоснование целесообразности переноса компонентов из корня в..."  +2 +/
Сообщение от Аноним (??) on 27-Янв-12, 17:18 
> ну, я например не использую initrd, у меня и ядро то обычно
> монолитно.

всем пофик :)

> получается нерациональная трата места, копируя файлы для initrd и даже cо сжатием
> их, всё равно будет больше занято места как на носителе, так
> и в памяти. не вижу причин переносить всё в /usr, тем
> более, распихивая линки потом - науха переносить то, если линки оставить
> придётся?

Попробуй прочиать текст новости - там объяснено почему.

> мне гораздо интереснее разделить доступ, когда одна точка монтирования для записи, другая
> - для чтения только. например, все файлы для записи скидывать в
> /var - /var/etc, /var/tmp, /var/run, /var/srv, /var/home и тд

Попробуй прочиать текст новости - там это уже описано.

Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

130. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Xasd (ok) on 27-Янв-12, 17:50 
> науха переносить то, если линки оставить придётся?

переносить -- файлы (содержимое каталогов)

линки ставить на -- каталоги (а не на файлы, которые являются содержимым каталогов)

Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

118. "Обоснование целесообразности переноса компонентов из корня в..."  –1 +/
Сообщение от Xasd (ok) on 27-Янв-12, 17:17 
доводы разумные...

..но количество старпёров сейчас уже не счесть. они будут яростно сопротивляться любой перемене :-D

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

132. "Обоснование целесообразности переноса компонентов из корня в..."  +3 +/
Сообщение от Аноним (??) on 27-Янв-12, 18:16 
Молодые пердуны всегда видят фатальный недостаток. Они бы сделали лучше! Ха-ха-ха-ха! И вместо масадосиса мы увидели вендец 3.1, этот жуткий ужас!

Валяйте, умники, только не на форумах языками чесать - а мешки ворочать^Wкод писать - да такой крутой, что мы закачаемся. И, самое главное - который проживет 35 лет почти без изменений, ибо всем хорош, а остальные могут лишь трындеть по форумам и в каментах ср.ть!

Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

156. "Обоснование целесообразности переноса компонентов из корня в..."  –1 +/
Сообщение от Аноним (??) on 27-Янв-12, 18:50 
> Валяйте, умники, только не на форумах языками чесать - а мешки ворочать^Wкод
> писать - да такой крутой, что мы закачаемся. И, самое главное
> - который проживет 35 лет почти без изменений, ибо всем хорош,
> а остальные могут лишь трындеть по форумам и в каментах ср.ть!

Именно так всё и происходит - изменения в FHS продвигают те, кто активно пишут крутой код. Среди оппонентов я ни одного известного программиста не увидел - видимо это объясняет полное отсутствие обоснованной критики.

Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

165. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от anonymous (??) on 27-Янв-12, 19:28 
> Именно так всё и происходит - изменения в FHS продвигают те, кто
> активно пишут крутой код. Среди оппонентов я ни одного известного программиста
> не увидел - видимо это объясняет полное отсутствие обоснованной критики.

Какой крутой код написал Леннарт? И особенно интересны критерии его "крутости" по сравнению с тысячей других программ, коих тут каждый второй написал не один десяток.


Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

177. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 20:16 
> Какой крутой код написал Леннарт? И особенно интересны критерии его "крутости" по
> сравнению с тысячей других программ, коих тут каждый второй написал не
> один десяток.

pulseaudio, systemd.
Теперь попробуй перечислить хотя бы пару программ из "не один десяток", включённых во все распространённые дистрибутивы GNU/Linux. Можно даже не включённых в установку по-умолчанию.

Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

233. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Пр0х0жий (??) on 28-Янв-12, 02:24 
>> Какой крутой код написал Леннарт?
> pulseaudio,

Мне нужно описывать проблему Front vs Headphones в pulseaudio?
В отличие от ...

Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

236. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Xasd (ok) on 28-Янв-12, 03:51 
> Мне нужно описывать проблему Front vs Headphones в pulseaudio?
> В отличие от ...

былобы не плохо :-)

Ответить | Правка | ^ к родителю #233 | Наверх | Cообщить модератору

240. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Аноним (??) on 28-Янв-12, 08:51 
>>> Какой крутой код написал Леннарт?
>> pulseaudio,
> Мне нужно описывать проблему Front vs Headphones в pulseaudio?
> В отличие от ...

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

Ответить | Правка | ^ к родителю #233 | Наверх | Cообщить модератору

239. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Аноним (??) on 28-Янв-12, 08:49 
>> Какой крутой код написал Леннарт? И особенно интересны критерии его "крутости" по
>> сравнению с тысячей других программ, коих тут каждый второй написал не
>> один десяток.
> pulseaudio

выносится в первую очередь - ибо с ним не работает микрофон. Alsa наше все.
автор упорно не хотел чинить ошибки в коде, сломаный OSS support назвал достоиством.

> systemd.

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

> Теперь попробуй перечислить хотя бы пару программ из "не один десяток", включённых
> во все распространённые дистрибутивы GNU/Linux. Можно даже не включённых в установку
> по-умолчанию.

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


Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

265. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 28-Янв-12, 12:55 
> pulseaudio выносится в первую очередь - ибо с ним не работает микрофон.

Ложь - микрофон отлично работает. Или ты можешь подтвердить ссылкой на баг-репорт?

> Alsa наше все.

И она тоже отлично работает с pulseaudio.

> systemd уродский костыль который не позволяет легко модифицировать процедуру старта - только через правки исходника, и пересборку.

Опять ложь. Или ты можешь подтвердить ссылкой на баг-репорт?

> То что они включены это заслуга RH который продавил свое решение, и
> смеется.

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

Интересно, ненавистники Леннарта вообще могут обойтись без наглой лжи?

Ответить | Правка | ^ к родителю #239 | Наверх | Cообщить модератору

268. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от arisu (ok) on 28-Янв-12, 13:00 
>> Alsa наше все.
> И она тоже отлично работает с pulseaudio.

а не наоборот?

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

я так понимаю, пруфлинк на заявления и исследования случайно отклеился?

Ответить | Правка | ^ к родителю #265 | Наверх | Cообщить модератору

272. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от Аноним (??) on 28-Янв-12, 13:08 
Как ты смешно задёргался когда тебя поймали на лжи :)
Ответить | Правка | ^ к родителю #268 | Наверх | Cообщить модератору

274. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от arisu (ok) on 28-Янв-12, 13:19 
> когда тебя поймали на лжи

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

Ответить | Правка | ^ к родителю #272 | Наверх | Cообщить модератору

294. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от Аноним (??) on 29-Янв-12, 00:26 
>> когда тебя поймали на лжи
> интересно, где? тебя же не затруднит привести ссылку на мою ложь, правда?

Парой сообщений выши - см. №265

Ответить | Правка | ^ к родителю #274 | Наверх | Cообщить модератору

331. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от Michael Shigorin email(ok) on 30-Янв-12, 14:12 
>>> Alsa наше все.
>> И она тоже отлично работает с pulseaudio.

Ни разу не отлично, но работает.

> а не наоборот?

alsa-pulse действительно есть, но кривое.

Ответить | Правка | ^ к родителю #268 | Наверх | Cообщить модератору

332. "Обоснование целесообразности переноса компонентов из..."  +1 +/
Сообщение от arisu (ok) on 30-Янв-12, 14:22 
всё-таки я намекал, что это пульс живёт за счёт алсы, а никак не наоборот.
Ответить | Правка | ^ к родителю #331 | Наверх | Cообщить модератору

330. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Michael Shigorin email(ok) on 30-Янв-12, 14:10 
>> pulseaudio
> выносится в первую очередь

Обычно да.

> - ибо с ним не работает микрофон.

Это не так, PA -- едва ли не единственный известный мне разумный вариант получения приемлемой латентности записи звука с микрофона тонкого клиента при условии подстройки под задачу (снижение количества и IIRC размера сегментов).

> автор упорно не хотел чинить ошибки в коде, сломаный OSS support назвал достоиством.

А вот это да: автор упорно пытается съехать и указание на ошибки и передёргивания воспринимает как личный наезд.

Да, он не виноват _один_ в лени кучи других редхатовцев приводить своё Г к приличному виду без пинков от платящих заказчиков.  Ну так и нечего лезть за них на амбразуру и тем более переваливать проблемы с больной головы на здоровые.

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

Ответить | Правка | ^ к родителю #239 | Наверх | Cообщить модератору

259. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от arisu (ok) on 28-Янв-12, 11:58 
XEdit включён во все распространённые (и даже в не очень распространённые) дистрибутивы. значит ли это, что XEdit — действительно хороший и удобный редактор? только не надо увёртки про «свою нишу».
Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

262. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от Аноним (??) on 28-Янв-12, 12:50 
> XEdit включён во все распространённые (и даже в не очень распространённые) дистрибутивы.
> значит ли это, что XEdit — действительно хороший и удобный редактор?
> только не надо увёртки про «свою нишу».

Ты хочешь сказать что ты автор хедита?
Или что ты окончательно утратил нить рассуждений и не понимаешь о чём вообще идёт речь?

Ответить | Правка | ^ к родителю #259 | Наверх | Cообщить модератору

128. "Обоснование целесообразности переноса компонентов из корня в..."  –1 +/
Сообщение от skybon (ok) on 27-Янв-12, 17:32 
Идея унификации правильная. Только нафиг /usr/bin, а не просто /bin?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

158. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Аноним (??) on 27-Янв-12, 18:56 
>Improved compatibility with other Unixes (in particular Solaris)

вот пусть тока не трындит. Где он еще нашел /sbin->/usr/sbin ? Только соляра этим отличается. И я хз как трактористы выкручиваются в случае боков с /usr без отдельного /sbin.

>The primary commercial Unix implementation is nowadays Oracle Solaris.

Доооо. Разбудите его там кто-нибудь, напомните, что 2000 год уже закончился.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

160. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Владимир email(??) on 27-Янв-12, 19:07 
Все правильно. В простате надёжность.
Чем проще будет организована система - тем она будет стабильнее и соответственно надёжнее. Это всегда был путь Linux, поэтому это самая надёжная система.
Если есть причины еще упростить - почему бы и нет.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

162. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от anonymous (??) on 27-Янв-12, 19:16 
>В простате надёжность.

Где ты увидел упрощение?

Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

163. "Обоснование целесообразности переноса компонентов из корня в..."  +2 +/
Сообщение от Михрютка on 27-Янв-12, 19:21 
>В простате надёжность.

В мозгах надежность должна быть, блин, в мозгах!

Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

301. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от mihail krijich on 29-Янв-12, 08:00 
> Все правильно. В простате надёжность.
> Чем проще будет организована система - тем она будет стабильнее и соответственно
> надёжнее. Это всегда был путь Linux, поэтому это самая надёжная система.
> Если есть причины еще упростить - почему бы и нет.

а нафига тогда вообще деление на bin и sbin, давайте уж все в кучу, упрощать, так упрощать.

Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

161. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от anonymous (??) on 27-Янв-12, 19:15 
Маразм крепчал.


>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.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

166. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Михрютка on 27-Янв-12, 19:41 
теперь осталось еще статическую линковку отменить, как в соляре, и будет совсем хорошо.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

183. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от жора on 27-Янв-12, 20:53 
Минус этого переноса очевиден. Рушится базовая система, необходимая для административных действий в случае проблем с загрузкой.
Восполнить это можно двумя способами, либо раздуть 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 можно монтировать, а можно использовать и свой оригинальный, что дает дополнительную гибкость.

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

187. "Обоснование целесообразности переноса компонентов из корня в..."  +2 +/
Сообщение от Аноним (??) on 27-Янв-12, 21:10 
> Минус этого переноса очевиден. Рушится базовая система, необходимая для административных действий в случае проблем с загрузкой.

Каких именно проблем? Если у тебя система не загрузилась с бинарниками в /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 - тоже.
Может быть всё дело в том, что аргументы Поттеринга рассчитаны на тех, кто постоянно занят развитием и поддержанием дистрибутивов, а не досужими рассуждениями на форумах?


Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

190. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от жора on 27-Янв-12, 21:21 
Ты прочитать пробовал, на что отвечаешь?

> Каких именно проблем? Если у тебя система не загрузилась с бинарниками в
> /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 - тоже.
> Может быть всё дело в том, что аргументы Поттеринга рассчитаны на тех,
> кто постоянно занят развитием и поддержанием дистрибутивов, а не досужими рассуждениями
> на форумах?

Почитайте мнение этих людей. Они, мягко говоря, далеко не однозначны.

Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

197. "Обоснование целесообразности переноса компонентов из корня в..."  –1 +/
Сообщение от Аноним (??) on 27-Янв-12, 21:45 
> О том и речь. Могут быть проблемы с монтированием /usr. Особенно сетевого.

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

> К зоопарку добавлен еще один "принцип построения". Или вы уверены, что все
> остальные "исчезнут".

Он добавлен ещё лет 15 назад в эпоху классического юникса. Что там говорил про "читать на что отвечаешь"? ;)

> Речь шла бездисковых станциях.

Тогда твоя фраза "монтируется поверх" лишена всякого смысла - поверх чего может монтироваться сетевой раздел на _бездисковом_ терминале?

> Да. только ради чего?

А почему бы и нет собственно? Это всего лишь один из множества плюсов от предлагаемых улучшений. Сейчас такое сделать крайне геморройно, после объединения /usr это сделать будет легко.

> Почитайте мнение этих людей. Они, мягко говоря, далеко не однозначны.

Ну ссылки что-ли приводи. Только не на форумы "крутых всезнающих админов", а на разработчиков дистрибутивов. Например сейчас в gdm-list идёт микросрачик по поводу выпиливания ConsoleKit - народ против выпиливания особо не возражает, желающие странного готовы взять поддержку на себя.

Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

203. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от жора on 27-Янв-12, 22:10 
> Могут разумеется - только маловероятно, что загрузка в / поможет эти проблемы
> решить. Нет, конечно такой маленький шанс есть, при условии что загрузка
> без /usr работает - в большинстве современных дистрибутивов это не так
> - несмотря на формальное разделение этот use-case как правило не тестируется.

На большинстве - это на Федоре. В однопользовательском режиме все же обычно не используется /usr.

> Он добавлен ещё лет 15 назад в эпоху классического юникса. Что там
> говорил про "читать на что отвечаешь"? ;)

Я о ссылках /bin -> /usr/bin и т.д.


>> Речь шла бездисковых станциях.
> Тогда твоя фраза "монтируется поверх" лишена всякого смысла - поверх чего может
> монтироваться сетевой раздел на _бездисковом_ терминале?

Сетевой корень cовмещается с корнем в оперативке.

> А почему бы и нет собственно? Это всего лишь один из множества
> плюсов от предлагаемых улучшений. Сейчас такое сделать крайне геморройно, после объединения
> /usr это сделать будет легко.

Точно так же, как и сейчас.

Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

211. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 22:31 
> На большинстве - это на Федоре. В однопользовательском режиме все же обычно
> не используется /usr.

cd /sbin && ldd *|grep /usr | wc -l
На моей убунте даёт 47.
Можешь проверить на своём любимом дистре.
Надо что-то ещё пояснять про "обычно не используется /usr"?

> Я о ссылках /bin -> /usr/bin и т.д.

Можешь посмотреть на соплярис, от 11 и выше.

> Сетевой корень cовмещается с корнем в оперативке.

Внимание вопрос: откуда этот самый корень взялся в оперативке на _бездисковой_ станции?

>> А почему бы и нет собственно? Это всего лишь один из множества
>> плюсов от предлагаемых улучшений. Сейчас такое сделать крайне геморройно, после объединения
>> /usr это сделать будет легко.
> Точно так же, как и сейчас.

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

А я уверен, что они станут - просто потому, что это удобнее и облегчает портирование софта.

Ответить | Правка | ^ к родителю #203 | Наверх | Cообщить модератору

219. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от жора on 27-Янв-12, 23:28 
> cd /sbin && ldd *|grep /usr | wc -l
> На моей убунте даёт 47.
> Можешь проверить на своём любимом дистре.
> Надо что-то ещё пояснять про "обычно не используется /usr"?

У меня на дом. дебиане три библиотеки. Причем некритичные (ntfs, ntfs-3g, fuse).
Тем не менее этот довод (Все украдено до нас) все же весомее пустословия Потеринга.

> Можешь посмотреть на соплярис, от 11 и выше.

Исходная тема - унификация. А тут умирающий Солярис.

> Внимание вопрос: откуда этот самый корень взялся в оперативке на _бездисковой_ станции?

Корня в памяти не встечал? Или он только на дисковых станциях возможен?
Тем не менее вопрос к теме не относится.

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

Тем не менее не вижу принципиальной разницы.

Ответить | Правка | ^ к родителю #211 | Наверх | Cообщить модератору

221. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 23:38 
> У меня на дом. дебиане три библиотеки. Причем некритичные (ntfs, ntfs-3g, fuse).
> Тем не менее этот довод (Все украдено до нас) все же весомее
> пустословия Потеринга.

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

>> Можешь посмотреть на соплярис, от 11 и выше.
> Исходная тема - унификация. А тут умирающий Солярис.

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

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

Ну спроси у разработчиков calculate linux - они тебе объяснят сколько заняла разработка данной фичи и сколько усилий требуется на её поддержку.

Ответить | Правка | ^ к родителю #219 | Наверх | Cообщить модератору

289. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Клыкастый2 on 28-Янв-12, 23:30 
> Для понимания можешь попробовать посмотреть через какие костыли это реализовано в calculate linux.

можно подробностей?

Ответить | Правка | ^ к родителю #211 | Наверх | Cообщить модератору

302. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от mihail krijich on 29-Янв-12, 08:13 
>> На большинстве - это на Федоре. В однопользовательском режиме все же обычно
>> не используется /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

Ответить | Правка | ^ к родителю #211 | Наверх | Cообщить модератору

305. "Обоснование целесообразности переноса компонентов из корня в..."  –1 +/
Сообщение от Аноним (??) on 29-Янв-12, 12:29 
> вот это, в первую очередь, и нужно чинить, а не дальше ломать.

А где ты увидел предложение сломать что-либо?
Опять пытаешься выдать свой бред за реальность?

Ответить | Правка | ^ к родителю #302 | Наверх | Cообщить модератору

310. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от mihail krijich on 29-Янв-12, 16:00 
>> вот это, в первую очередь, и нужно чинить, а не дальше ломать.
> А где ты увидел предложение сломать что-либо?
> Опять пытаешься выдать свой бред за реальность?

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

Ответить | Правка | ^ к родителю #305 | Наверх | Cообщить модератору

284. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от netch (ok) on 28-Янв-12, 22:09 
>> Могут разумеется - только маловероятно, что загрузка в / поможет эти проблемы
>> решить. Нет, конечно такой маленький шанс есть, при условии что загрузка
>> без /usr работает - в большинстве современных дистрибутивов это не так
>> - несмотря на формальное разделение этот use-case как правило не тестируется.
> На большинстве - это на Федоре. В однопользовательском режиме все же обычно
> не используется /usr.

Боюсь, ты таки с фряхой попутал. Там действительно в single user автоматом только корень.
В большинстве линуксов при этом уже смонтировано всё автоматически подключаемое, под руководством /etc/rc.sysinit или аналога.


Ответить | Правка | ^ к родителю #203 | Наверх | Cообщить модератору

290. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Клыкастый2 on 28-Янв-12, 23:31 
> Боюсь, ты таки с фряхой попутал. Там действительно в single user автоматом только корень.

хм. а это чем-то плохо?

Ответить | Правка | ^ к родителю #284 | Наверх | Cообщить модератору

327. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от netch (ok) on 30-Янв-12, 13:57 
>> Боюсь, ты таки с фряхой попутал. Там действительно в single user автоматом только корень.
> хм. а это чем-то плохо?

Для неё - нет. Потому что в корне достаточно средств, чтобы попасть в шелл, сделать mount, fsck, загрузить штатные модули, отредактировать fstab (через /bin/ed) и в общем выполнить весьма немалый объём всякой возни. И они проверяются на работоспособность.

Ответить | Правка | ^ к родителю #290 | Наверх | Cообщить модератору

333. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от mihail krijich on 30-Янв-12, 14:31 
>(через /bin/ed)

ed - конечно сильно, но можно и более обыденными средствами: /rescue/vi

Ответить | Правка | ^ к родителю #327 | Наверх | Cообщить модератору

334. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Michael Shigorin email(ok) on 30-Янв-12, 14:46 
>> Может быть всё дело в том, что аргументы Поттеринга рассчитаны на тех,
>> кто постоянно занят развитием и поддержанием дистрибутивов, а не досужими
>> рассуждениями на форумах?

Вы с ними хоть общались, крикливый Вы наш?

> Почитайте мнение этих людей. Они, мягко говоря, далеко не однозначны.

Вот именно.

Спасибо за изложенное, хотя читать и воспринимать Вашему оппоненту, похоже, сложно. :(

Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

260. "Обоснование целесообразности переноса компонентов из..."  +1 +/
Сообщение от arisu (ok) on 28-Янв-12, 12:03 
> До сих пор шли: /run во всех дистрибутивах уже есть или в
> ближайших планах, pulseaudio — тоже.

(внимательно осмотрел свою слаку) нету. вы, сударь, лжец.

Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

261. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от Аноним (??) on 28-Янв-12, 12:48 
Речь шла о дистрибутивах, а не о детских конструкторах.
Ответить | Правка | ^ к родителю #260 | Наверх | Cообщить модератору

263. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от arisu (ok) on 28-Янв-12, 12:52 
> Речь шла о дистрибутивах, а не о детских конструкторах.

это, случайно, не о тех, у которых несколько лет мегабаг в OpenSSL был, потому что маинтайнер — криворукий идиот? благодарю, я лучше на «детском конструкторе» останусь.

p.s. то, что ты слаку видел только издалека в виде iso-образа — даже доказывать не надо.

Ответить | Правка | ^ к родителю #261 | Наверх | Cообщить модератору

186. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от жабабыдлокодер (ok) on 27-Янв-12, 20:57 
А тут все просто. Леннарт ориентируется отнюдь не на однопользовательские системы, а на энтерпрайз. Там подходы другие, поэтому он и не задумывается над "восстановлением". Там все данные хранятся на рейд-массивах, заранее созданы запасные сервера на случай физических поломок и пр. Если есть махонький серверок, на котором крутится десятка два-три виртуалок, то возможность иметь для них один общий usr - бесценна, это здорово экономит место и гарантирует, что обновлены будут все машины - причем без каких-либо дополнительных усилий. Ну, и возможность отката простым монтированием дорогого стоит.
...А до проблем с восстановлением системы на старенькой файлопомойке ему и дела нет...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору
Часть нити удалена модератором

189. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 21:19 
Fedora это полигон для тестирования нововедений на хомячках.
Вот когда RedHat это пропихнет в RHEL - тогда можно о чем-то говорить, а хомячки из федориного горя должны хоть что-то заплатить RH, если не деньгами - то побыть подопытными крысами :)
Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

193. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от ArtKun on 27-Янв-12, 21:29 
Полигон для тестирования, кажется, слишком плохо звучит.

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

Ответить | Правка | ^ к родителю #189 | Наверх | Cообщить модератору

200. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от жабабыдлокодер (ok) on 27-Янв-12, 21:48 
И какие положительные моменты есть для домашних машин? Дома мне ни жарко, ни холодно от наличия или отсутствия /sbin. Я уж и не помню, когда в последний раз что-то даже в /etc менял, благо Мандрива почти на все хороший гуй имеет. А вот в масштабах немелкого предприятия - таки да, Леннарт все по полочкам разложил.
ОН РАБОТАЕТ НА RED HAT. RED HAT выпускает ось ДЛЯ ПРОМЫШЛЕННЫХ СЕРВЕРОВ - так понятнее? Его может интересовать только конечный результат - удобство работы в энтерпрайзе. Ну, а кто дома Федору использует - должен же кто-то будущий энтерпрайз тестировать?
Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

202. "Обоснование целесообразности переноса компонентов из корня в..."  +2 +/
Сообщение от pavlinux (ok) on 27-Янв-12, 22:00 
> И какие положительные моменты есть для домашних машин? Дома мне ни жарко,
> ни холодно от наличия или отсутствия /sbin. Я уж и не
> помню, когда в последний раз что-то даже в /etc менял, благо
> Мандрива почти на все хороший гуй имеет. А вот в масштабах
> немелкого предприятия - таки да, Леннарт все по полочкам разложил.
> ОН РАБОТАЕТ НА RED HAT. RED HAT выпускает ось ДЛЯ ПРОМЫШЛЕННЫХ СЕРВЕРОВ
> - так понятнее?

Дибил он. А работать он может хоть в Белом Доме или ООН.

Если он видит разницу в монитровании /usr  как / для NFS, тогда тут неувязочка,
по его феншую, /usr должен монтироваться как /usr иначе хня получается.
А если примонтировали удалённый /usr как /usr, где же тогда корень, и чем тогда
NFS /usr будет отличаться от / ?

Отседа вывод: Ничем отличаться не будет. Тогда нах...я дописывать три буквы к / ?

---

Более того, NFS структуры на NFS серверах хранятся совершенно в иных местах,
так как обычно это урезанные, минимальные копии файловой структуры, только с
необходимым набором утилит, библиотек и софта.


---
> Упрощение формирования гостевых окружений для систем виртуализации

Кто ему сказал, что мне нужна вся иерархия /usr ?
Кто ему сказал, что окружения виртуализации есть копии хост системы?
Кто ему сказа, что скорость работы через virtio будет быстрее, чем внутри?
Облачные, кластерные хосты тоже будут тянуть все с одного сервака?

Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору
Часть нити удалена модератором

227. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от pavlinux (ok) on 28-Янв-12, 00:10 
Бред ломать фундамент, заменяя его воздушной подушкой на 10-цис-2-альфа-димитилпропиленбутаноле, и убеждать что это нужно.  
Ответить | Правка | ^ к родителю #263 | Наверх | Cообщить модератору

212. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 22:34 
> И какие положительные моменты есть для домашних машин? Дома мне ни жарко,
> ни холодно от наличия или отсутствия /sbin.

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


Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору

192. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от pavlinux (ok) on 27-Янв-12, 21:23 
> в 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 Files

A 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.


Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

198. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Пр0х0жий (??) on 27-Янв-12, 21:46 
> новое унифицированное расположение исполняемых файлов и библиотек внутри
> раздела /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

Где?


Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

205. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от Михрютка on 27-Янв-12, 22:18 

> 2. Extend the logical volume. For example:
> # /sbin/lvextend -L 332 /dev/vg01/lvol2
> Где?

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


Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

244. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 28-Янв-12, 09:29 
>[оверквотинг удален]
>> /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 - положить туда что нужно и загрузившись заново сделать то что хочется.

Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

217. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (??) on 27-Янв-12, 23:19 
/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 так?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

229. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от pavlinux (ok) on 28-Янв-12, 00:12 
>[оверквотинг удален]
> /opt
> /proc
> /root
> /run
> /sbin
> /share/{info,include,doc,man,src}
> /srv
> /sys
> /tmp
> /var

/local ищо :)

Да чего уж там

/man
/doc
/locale
/info
/log
/cache
/spool
/mail
/rpm - для бландинок, чтоб далеко ходить не надо было, и в скриптах меньше писать (тоже экономия места,.. на терабайтниках-то)


> собрать в следующий раз LFS так?

Ответить | Правка | ^ к родителю #217 | Наверх | Cообщить модератору

320. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от anonimous on 30-Янв-12, 11:20 
пардон, если повторяю выше описанное, но Ctrl+F не нашел. итак:
а что будет с /opt, так и останется в корне, или также закинут в /usr
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру