форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Обоснование целесообразности переноса компонентов из корня в..."	–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 (??) 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 (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 (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 (ok) on 27-Янв-12, 18:42
	>> Да. И что это повод прогибаться под коммерческие системы a-la макос или солярки ? > У них сделано лучше и удобнее, чем в линуксе. Это повод. Таки ви в этом уверены? Вы уважаемый походу ни разу с макосью не связывались. Там установка текстурпака на майнкрафт вызывает определённые затруднения из за неимоверной кривизны тамошней файловой системы, не говоря уж о более сложных вещах.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	314. "'Обоснование' целесообразности переноса компонентов"	+2 +/–
	Сообщение от Michael Shigorin (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 (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 (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 (ok) on 30-Янв-12, 13:48
	>>>> все пакеты поддерживаются одинаково аккуратно >>> ORLY? >> Именно так. Отнюдь. >> А ты думал почему яндекс с рамблером от бзди сбежали как от чумы? > Потому что достаточного интеллекта на админов не набрали, весь разобран. > Тут действительно приходится держаться за mainstream. Валик, там были две разные стопки причин, как понимаю.  За рамблер не скажу, а в яндексе интеллекта у админов (и судя по виденному, и манагеров) вообще-то прилично.
	Ответить | Правка | ^ к родителю #282 | Наверх | Cообщить модератору

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

	335. "Обоснование целесообразности переноса компонентов из корня в..."	+/–
	Сообщение от Michael Shigorin (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 (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 +/–
Сообщение от Аноним (??) 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 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 (ok) on 30-Янв-12, 13:55
	> Я же ясно сказал: если не понял - читай ещё раз. До тех пор, пока не дойдёт. Когда пишущие передёргивают и притягивают за уши нерелевантное -- сколько раз ни читай, в худшем случае создастся иллюзия, что дошло. Вот они, гримасы капитализма -- в данном случае в виде "популярности" как метрики и пиара как непременной составляющей технического процесса...
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	325. "Обоснование целесообразности переноса компонентов из корня в..."	+/–
	Сообщение от Michael Shigorin (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 (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 (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. "Обоснование целесообразности переноса компонентов из корня в..."	+/–
Сообщение от Владимир (??) 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 (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 | Индекс форумов | Темы | Пред. тема | След. тема