URL:
Новость: https://www.opennet.ru/opennews/art.shtml?num=30080
Лучше бы в федоре из /var/run поубирали все подкаталоги, а то пробуешь её смонтировать на tmpfs, и при запуске начинают сыпаться ошибки "не найден каталог /var/run/XXXXX"
Об этом и идет речь в тексте.
>Лучше бы в федоре из /var/run поубирали все подкаталоги, а то пробуешь её смонтировать на tmpfs, и при запуске начинают сыпаться ошибки "не найден каталог /var/run/XXXXX"Это проблема старой системы инита, используемой в f14 по умолчанию.
В f15 будет systemd, который автоматически создаёт все необходимые файлы и каталоги в run/ и lock/
Может в подкаталогах будут жить нитки всего этого добра? Вроде:apache22.pid/2508
apache22.pid/2509
apache22.pid/2511Или там как-то все иначе придумают?
>>Для решения проблемы с недоступностью /var/run на ранней стадии загрузки различные дистрибутивыа с какого перепугу /run будет 100% доступен на ранней стадии загрузки?
С такого же, с которого /dev доступен сейчас.
/var бывает выносят на отдельное устройство, если там будет лежать, например, мыло или база постгреса
ну а /run никто в трезвом уме не будет трогать
В принципе, логично
Новая версия FHS ??Да есть проблемы с этим /var/run, пусть будет просто /run
Главное, что смогли договориться!!! Вот это и есть прогресс :)
Дурацкая идея.Тогда давайте сразу все в корень пихать.
Если человек вместо использования решений, проверенных годами, пытается перековеркать ее идеологию - то гнать таких в шею и искать адекватных и, самое главное, УМНЫХ разработчиков.
ИМХо.
(sorry за капс местами)
ее идеологию --> идеологию OS
> Если человек вместо использования решений, проверенных годами, пытается перековеркать ее идеологию - то гнать таких в шею и искать адекватных и, самое главное, УМНЫХ разработчиков.Вот они так и поступили :-)
/run - это ещё один важный шаг в строгом разделении задач по основным каталогам файловой системы. А все эти /dev/.xxx и /var/run - это издевательство над идеологией fhs.
Хорошее решение.
Когда приложения поправят на использование только /run то можно будет /var c noexec монтировать.
+1, я тоже не обрадовался, когда обнаружил, что с noexec на /var дистриб рассыпается. А ведь там есть куда шальному юзеру писать (/var/tmp/).
> Когда приложения поправят на использование только /run то можно будет /var c
> noexec монтировать.Боюсь, что не поможет. Всякие скрипты для пакетных менеджеров обычно не в /var/run кладут, а в какой-нибудь /var/lib.
а что, кто-то выносит /var на отдельный раздел?!
> а что, кто-то выносит /var на отдельный раздел?!А что кто-то его не выносит в отдельный раздел и как часть корня использует ?
>> а что, кто-то выносит /var на отдельный раздел?!
> А что кто-то его не выносит в отдельный раздел и как часть
> корня использует ?В Линуксе один раздел подо всё - нормальная практика. Много систем "из коробки" ставятся именно так.
>>> а что, кто-то выносит /var на отдельный раздел?!
>> А что кто-то его не выносит в отдельный раздел и как часть
>> корня использует ?
> В Линуксе один раздел подо всё - нормальная практика. Много систем "из
> коробки" ставятся именно так.У меня извращённый сервер в RAID1 на винте унутрях железки и винте снаружи (USB), так вот при буте с него, винт внешний ещё не подцепляется (эту шину ведро дёргает позже монтирования корня), поэтому после подгрузки корня нужно провести синхронизацию массива. Если бы в корне был весь массив, я бы повесился ждать синхронизации. А так, процесс занимает пару минут.
>>Много систем "из коробки" ставятся именно так.
>У меня извращённый сервердальше можно не читать, и автору советую в будущем не писать
> В Линуксе один раздел подо всё - нормальная практика. Много систем "из коробки" ставятся именно так.Да, так многие системы ставятся. Практика абнормальная.
Это до первого сбоя. После попыток отсортировать перемешавшее содержимое /var и /etc всегда монтирую в отдельный раздел.
/etc? а fstab у вас где?
/etc/fstab. У вас не так?
так а как тогда у вас /etc на отдельном диске? отдельные диски через него монтируются
У меня /etc не на отдельном диске.
ясно, просто Вы не понятно написали.
Да, опечатался. Перед «всегда» (а не после «содержимое») должна быть запятая. Речь шла о /var.«Казнить нельзя помиловать» получилось ;)
нет, один раздел подо всё - ненормальная практика. отдельный раздел под корень и под пользовательские данные. остальное - очень специфично (отдельный раздел под мыло, файлопомойку из закачек, всякие версии scratchbox и т.д.), но вот основные разделы из корня выносить смысла нет
> нет, один раздел подо всё - ненормальная практика. отдельный раздел под корень
> и под пользовательские данные. остальное - очень специфично (отдельный раздел под
> мыло, файлопомойку из закачек, всякие версии scratchbox и т.д.), но вот
> основные разделы из корня выносить смысла нетЭто не ко мне, это к дистроклепателям.
> В Линуксе один раздел подо всё - нормальная практика. Много систем "из
> коробки" ставятся именно так.А потом таких _ч_удил кучами ломают через дырявый экзим.
>> В Линуксе один раздел подо всё - нормальная практика. Много систем "из
>> коробки" ставятся именно так.
> А потом таких _ч_удил кучами ломают через дырявый экзим.Ну Линукс в плане стандартизация вообще очень своеобразная система.
Ога, а потом пизнес ДЕ если засирается раздел. Я так лично прокололся поставив веб-кам писать все происходящее в кабинете.
>>> а что, кто-то выносит /var на отдельный раздел?!
>> А что кто-то его не выносит в отдельный раздел и как часть
>> корня использует ?
> В Линуксе один раздел подо всё - нормальная практика. Много систем "из
> коробки" ставятся именно так.Господа минусующие, вы бы хоть писали, в каких Линух-системах по-умолчанию при установке не предлагается всё(кроме /boot) упихать в один раздел.
Для домашней машины приходится не /var, а /home выносить на отдельный раздел, иначе некоторые фильмами и музыкой быстро её...
/home само собой (а что, кто-то делает иначе?), но и /var, как единственную постоянно изменяемую часть лучше вынести отдельно (если /tmp в памяти).
выделить под корень 10Гиг
отдельно arhiv postrgesql mail squid log итд в зависимости от задач
ни одной причины отделять usr var итд кроме гемороя нет
man 5 exportsПосле этого понимание "отделения usr var" (tm) появляется сразу же.
> man 5 exports
> После этого понимание "отделения usr var" (tm) появляется сразу же.bash-4.1$ man 5 exports
No entry for exports in section 5 of the manualчто-то понимания не пришло.
nfs-utils не пробовали ставить?
> nfs-utils не пробовали ставить?нет, конечно. оно мне не надо, я его не использую и не вижу, каким образом это связано с нахождением /usr на отдельном не сетевом разделе.
> выделить под корень 10Гиг
> отдельно arhiv postrgesql mail squid log итд в зависимости от задач
> ни одной причины отделять usr var итд кроме гемороя нетПри таком раскладе большая вероятность получить незагружающуюся после аварийного выключения питания систему. Лично наблюдал такое в своей практике раз пять для установок с одним большим корнем, в котором и /home и /var свалены в одну кучу. Думайте почему в промышленных дистрибутивах корень в readonly монтируют ?
Весело потом после cбоя из /etc выковыривать кусочки /var. Незабываемый опыт.
> Весело потом после cбоя из /etc выковыривать кусочки /var. Незабываемый опыт.Наилучшим образом было бы монтировать / на read-only.
/var, /tmp, /home, /dev и т.п. монтировать отдельно
через tmpfs, nfs и просто на других разделах.
Но вот есть у людей странная привычка писать в /etc
во время работы системы...
#!/bin/shsudo remount_root_rw
vim $1
sudo remount_root_ro
> #!/bin/sh
> sudo remount_root_rw
> vim $1
> sudo remount_root_roРечь не про ручное редактирование файлов в /etc, а о программах,
которые туда пишут автоматом.
Например, некоторые пишут в /etc/adjtime или /etc/mtab.
Последний -- абсолютно не нужен вообще, но зачем-то держат.
Первому место явно не в /etc.
У меня:$ ls -l /etc/adjtime
lrwxrwxrwx 1 root root 26 Янв 18 00:36 /etc/adjtime -> ../var/lib/hwclock/adjtimeКак раньше делали /usr/var ссылкой на /var.
А /etc/mtab… уже не помню, что‐то помешало сделать также.
> У меня:
> $ ls -l /etc/adjtime
> lrwxrwxrwx 1 root root 26 Янв 18 00:36 /etc/adjtime -> ../var/lib/hwclock/adjtimeА у меня это файл "из коробки".
Но если разобрать каждый отдельный случай
(я привел только два примера, их, конечно, больше), решение для них
наверняка найдется. Вопрос не в этом, а в том, что нет уверенности,
что нет четкой и ясной установки "наверху", т.е. среди разработчиков,
что в /etc писать от нечего делать не надо.
И нет никакой гарантии, что очередная поставленная софтина
не свалится. Нет такой уверенности и касательно дистрибутива в целом.> Как раньше делали /usr/var ссылкой на /var.
> А /etc/mtab… уже не помню, что‐то помешало сделать также./etc/mtab - это чистой воды анахронизм. Есть /proc/mounts.
Кроме того, ядро знает, какие системы и куда подмонтированы,
спросить можно у него. Способов -- вагон и тележка.
Кстати, в BSD-ях /etc/mtab нет и в помине, потому
что он реально не нужен.
>> У меня:
>> $ ls -l /etc/adjtime
>> lrwxrwxrwx 1 root root 26 Янв 18 00:36 /etc/adjtime -> ../var/lib/hwclock/adjtime
> А у меня это файл "из коробки".А. Ну, я файл тоже руками переместил. Не понравилось нарушение FHS :).
> Но если разобрать каждый отдельный случай
> (я привел только два примера, их, конечно, больше), решение для них
> наверняка найдется. Вопрос не в этом, а в том, что нет уверенности,
> что нет четкой и ясной установки "наверху", т.е. среди разработчиков,
> что в /etc писать от нечего делать не надо.
> И нет никакой гарантии, что очередная поставленная софтина
> не свалится. Нет такой уверенности и касательно дистрибутива в целом.Согласен насчёт отсутствия уверенности. Программы пишутся различными несвязанными людьми. Дистрибутивы GNU/Linux — это собрание различных программ. Это следствие свободы. Зато каждый может начать собирать свой дистрибутив.
Но дистрибутив всё‐таки — это уже единый объект. Да, если его собирать дома на коленке, то можно кое‐как склепать, чтобы лишь заработало, и тогда не будет целостности и стержня. Но если он предназначен для массового пользования, то должна быть «политика партии», единые чёткие правила. И должна быть хорошая связь пользователей с разработчиками дистрибутива, чтобы сообщать о багах — например, записях в /etc. Тогда, если разработчики программы не исправляют проблему, то управляющие дистрибутивом выберут «официально поддерживаемой» другую аналогичную программу. Если такой порядок не работает, значит, и дистрибутив — не очень.
Что-то не видно на горизонте дистрибутива или системы,
в которой бы английским по белому было написано большими
буквами "В целях... мы позволяем монтировать / на read only".
Исключением, наверное, являются только системы для тонких клиентов,
которые монтируют все по NFS/whatever. Да и то не факт.Я склоняюсь к тому, что я практически
одинок в своих желаниях странного.
Судя по всему, люди забыли даже разницу
между /bin|/sbin и /usr/bin|/usr/sbin.Так что против ветра один в поле не воин.
>Я склоняюсь к тому, что я практически
>одинок в своих желаниях странного.
>"В целях... мы позволяем монтировать / на read only".Я кстати тоже думаю, что 90% времени и пространства FS можно держать в RO - потом не будет проблем при выключениях питания и т.д. или Я не прав?
> Что-то не видно на горизонте дистрибутива или системы,
> в которой бы английским по белому было написано большими
> буквами "В целях... мы позволяем монтировать / на read only".
> Исключением, наверное, являются только системы для тонких клиентов,
> которые монтируют все по NFS/whatever. Да и то не факт.
> Я склоняюсь к тому, что я практически
> одинок в своих желаниях странного.
> Судя по всему, люди забыли даже разницу
> между /bin|/sbin и /usr/bin|/usr/sbin.
> Так что против ветра один в поле не воин.Ты не одинок, но нас мало.
Берите фрюшу. Там по другому и не было никогда(кроме / в ro разумеется).
>> Весело потом после cбоя из /etc выковыривать кусочки /var. Незабываемый опыт.
> Наилучшим образом было бы монтировать / на read-only.
> /var, /tmp, /home, /dev и т.п. монтировать отдельно
> через tmpfs, nfs и просто на других разделах.
> Но вот есть у людей странная привычка писать в /etc
> во время работы системы...Остаётся вопрос с обновлением
>>> Весело потом после cбоя из /etc выковыривать кусочки /var. Незабываемый опыт.
>> Наилучшим образом было бы монтировать / на read-only.
>> /var, /tmp, /home, /dev и т.п. монтировать отдельно
>> через tmpfs, nfs и просто на других разделах.
>> Но вот есть у людей странная привычка писать в /etc
>> во время работы системы...
> Остаётся вопрос с обновлениемПоддержка системы невозможна без записи в /etc.
Добавление пользователей и групп, обновление конфигов,
одновление системы... Дело же не в этом.
Неужели я говорю такие сложные вещи?
В /etc нет смысла писать, КОГДА СИСТЕМА ПРОСТО РАБОТАЕТ.
> выделить под корень 10Гиг... а сможете так на девайсе бутающемся из 4Мб флехи? :)
>> выделить под корень 10Гиг
> ... а сможете так на девайсе бутающемся из 4Мб флехи? :)минут за 10 разверну debian или freebsd
А я за! Давно надо было сделать!
Почему всю жизнь все никсы жили и не испытывали проблем, а теперь возникла необходимость? Неужели нет менее радикального способа? Чем подход той же Убунты плох? Не одобряю нарушение FHS. Может еще будем диски буквами с двоеточием именовать, если так захотят разработчики Федоры?
И так зоопарк из систем и дистрибутивов, так еще хотят стать более непохожими. Скоро будет проще перейти с BSD на Solaris, чем сменить дистрибутив.
> Почему всю жизнь все никсы жили и не испытывали проблем, а теперь
> возникла необходимость? Неужели нет менее радикального способа? Чем подход той же
> Убунты плох? Не одобряю нарушение FHS. Может еще будем диски буквами
> с двоеточием именовать, если так захотят разработчики Федоры?
> И так зоопарк из систем и дистрибутивов, так еще хотят стать более
> непохожими. Скоро будет проще перейти с BSD на Solaris, чем сменить
> дистрибутив.ога, вот особенно вся эта линуксячая энтропия вылезает когда собираешь прошивочку для каконить эмбеддед ширпотреба. Где у девелоперов busybox апсалютна свое видение на то как должен работать modprobe, а у линуса нашего всио торвальдса когда он релизил нечто похожее на ядро 2.6.22.19 совсем другое. в итоге собирая этот ералаш воедино натыаешсо на очень таки интересные выверты, когда iptables при использовании iprange ругаецо на modprobe, которая в свою очередь ищет с..ка модули ядра почему-то в очень стандартном месте /opt/lib/modules и два стандартных места она не умеет. Вобщем в линуксе все так, одни ядро пилят, другие grsecurity, третьи GNU окружение, четвертые пытаются собрать все это воедино и назвать дистрибутивом. Вобщем собирая через пару лет новую прошивку я чувствую наступлю я на эти грабли с /run. Блин и почему нету никакой альтернативы в эмедддед решениях этому линуксу а?...
Ну не занимайтесь эмбеддовкой, если не получается. В мире есть много других работ, вы наверняка найдёте подходящую для ваших потребностей и способностей.
> Блин и почему нету никакой альтернативы в эмедддед решениях этому линуксу а?...Хм.. фря?
> Хм.. фря?Ага, при том что у фри нет НИ ОДНОЙ файловой системы реально пригодной для нормальной работы из флехи напрямую прицепленой к процу без всяких контроллеров? Что в эмбеддовке - совершенно штатная ситуация: многие мелкие процы умеют бутаться из NAND или SPI флех напрямую прицепленых к ним. Ну или из NOR на "классической шине памяти" - олдскульный вариант, который по прежнему встречается. В пингвине таковых ФС аж минимум 3 штуки на разные вкусы и задачи есть сразу есть в дефолтовом ядре: SquashFS, JFFS2, ubifs. А фря что предложит?
> 3 штуки на разные вкусы и задачи есть сразу есть в
> дефолтовом ядре: SquashFS, JFFS2, ubifs. А фря что предложит?zfs, вестимо — у них это любимый жупел.
> zfs, вестимо — у них это любимый жупел.Когда оно такое хорошее попробует взлететь с 4 мег флеша и 16 мег оперативы, будет немного другое слово, но тоже на букву Ж :). Единственное решение которое я видел и которое вообще хотя-бы худо-бедно буталось из флеша - это немеряная сжатая ФС которая при старте расжимается в оперативу. Сразу. Целиком. Даже если забыть про то что это не быстро, и про то что весь флеш забит под завязку при весьма скромном функционале, факт что половина оперативы сразу херится псу под хвост - достаточно невкусен сам по себе. Не говоря о том что изменять настройки предлагалось путем ... перепрошивки нового образа ФС. Более вменяемых решений я не видел (загрузка по TFTP и прочая, херящие самостоятельность девайса еще менее вменяемый фариант).
Даёшь 1,44М дискеты!
У вас любое упоминание Фри вызывает такой лютый поток, что невольно подозреваешь вас в латентного фрибсдшника.
>> Хм.. фря?
> Ага, при том что у фри нет НИ ОДНОЙ файловой системы реально
> пригодной для нормальной работы из флехи напрямую прицепленой к процу без
> всяких контроллеров? Что в эмбеддовке - совершенно штатная ситуация: многие мелкие
> процы умеют бутаться из NAND или SPI флех напрямую прицепленых к
> ним. Ну или из NOR на "классической шине памяти" - олдскульный
> вариант, который по прежнему встречается. В пингвине таковых ФС аж минимум
> 3 штуки на разные вкусы и задачи есть сразу есть в
> дефолтовом ядре: SquashFS, JFFS2, ubifs. А фря что предложит?Так сделайте, если вам это надо :) Вот лично мне эти "SquashFS, JFFS2, ubifs" в дефолтовом ядре не пристали ни разу, как и, уверен, 99,999999% пользователей. Как и НАНД/НОР флехи напрямую к процу.
Зато дурдома во фре значительно меньше. Особенно такого, как "выковыривать частички /var из /etc", чесслово, никогда бы не подумал, что такое возможно где-либо кроме mustdie. Да и всяких попыток писать в devfs или proc во фре нету только потому, что незачем, там и без этих приблуд всё работает. :)
> Так сделайте, если вам это надо :) Вот лично мне эти "SquashFS,
> JFFS2, ubifs" в дефолтовом ядре не пристали ни разу, как и,
> уверен, 99,999999% пользователей. Как и НАНД/НОР флехи напрямую к процу.вот поэтому фря на эмбедах никому ни в один орган и не упёрлась.
>> Хм.. фря?
> Ага, при том что у фри нет НИ ОДНОЙ файловой системы реально
> пригодной для нормальной работы из флехи напрямую прицепленой к процу без
> всяких контроллеров? Что в эмбеддовке - совершенно штатная ситуация: многие мелкие
> процы умеют бутаться из NAND или SPI флех напрямую прицепленых к
> ним. Ну или из NOR на "классической шине памяти" - олдскульный
> вариант, который по прежнему встречается. В пингвине таковых ФС аж минимум
> 3 штуки на разные вкусы и задачи есть сразу есть в
> дефолтовом ядре: SquashFS, JFFS2, ubifs. А фря что предложит?man 4 geom_uzip
Хоть бы ознакомился прежде чем мычать.http://www.freebsd.org/doc/en_US.ISO8859-1/articles/solid-st...
http://www.ukuug.org/events/eurobsdcon2009/papers/embedded-f...
http://www.freebsdnews.net/2008/09/02/embedded-freebsd-systems
> ога, вот особенно вся эта линуксячая энтропия вылезает когда собираешь прошивочку для
> каконить эмбеддед ширпотреба.Вай. А вы много собрали этого ширпотреба? Я вот с OpenWRT развлекаюсь, уталкивая оный в разнообразные девайсы. Мне нравится. У соляр и бсдей ничего такого и близко нет, пардон. В смысле, какуюнить фрибсд можно при большом желании запихнуть в полторы железки. Только результат будет неконкурентоспособным убожищем. А кому нужен девайс, который, простите, даже измененные системные настройки сохранить не сможет?
> Где у девелоперов busybox апсалютна свое видение на то как должен работать modprobe,
У них вообще очень специфичные взгляды на жизнь. Но с этим можно жить. Особенно сравнив футпринт итогового образа с бизибоксом и с тем же самым набранным стандартными утилитами. Извините, бизибокс компактнее в разы. Это накладывает некий отпечаток, да. Но это 1 бинарь который заменяет собой почти весь юзермод стандартной системы. По сути половина операционки :). Что довольно-таки круто и за это одно ему можно простить некоторые бестолковости.
> а у линуса нашего всио торвальдса когда он релизил нечто похожее на ядро
> 2.6.22.19 совсем другое.Ого, ды вы, батя, некроман. Лично я ядра менее .32 считаю ископаемыми. И да, я что-то не понял что совсем уж не так с modprobe в бизибоксе. Вроде работает. Я не заметил какую-то подляну? Ну раз не заметил - ок, черт с ней :)
> очередь ищет с..ка модули ядра почему-то в очень стандартном месте /opt/lib/modules
А для модулей ядра уже кто-то определил стандарт? Может я торможу, но мне не попадалось таковых стандартов. Не затруднит ли благородного дона ткнуть меня носом в этот стандарт?
> Вобщем в линуксе все так, одни ядро пилят, другие grsecurity, третьи GNU
> окружение, четвертые пытаются собрать все это воедино и назвать дистрибутивом.А что не так то? Работают люди. Делая те компоненты так как ИМ было нужно и удобно. А как вы сделаете чтобы было хорошо и удобно ВАМ - только вы и знаете. Наивно ожидать что кто-то вам все за вас сделает и выложит все в лучшем виде да еще и даром. Хотя-бы потому что задачи у всех разные.
> Вобщем собирая через пару лет новую прошивку я чувствую наступлю я на эти грабли с /run.
Да ладно вам, вменяемые эмбеддед дистрибуции, хоть тот же опенврт например - наверняка все это обрулят, так что вам скорее всего даже лично не придется особо дрюкаться. Любителям некромансии и LFS-way придется ессно подрюкаться побольше, но они знали на что шли. А если вы хотите юзать кривые и горбатые сдк от производителей очередной кривой хреновины - так могу заметить что эти сдк сроду оличаются кривизной и велосипедизмом независимо от /run. Хотя я и не понимаю на кой черт надо было трогать /var/run, тоже мне - нашли вселенскую проблему на ровном месте, блин. И, обнажив шпаги, бросились побеждать зло. Д`Артаньяны в чистом виде :)))
> Блин и почему нету никакой альтернативы в эмедддед решениях этому линуксу а?...
Потому что если некто поюзал BSD в своей железке, то он и исходник зажопить обычно не забывает. Поэтому *вам* оно не светит, покуда вы не разопретесь на порт самолично (не пройдет и 10 лет, ага). Ваш Кэп. Всякие VxWorks коммерческие, платные и с точки зрения функционала довольно убоги. Соляры и прочая - вообще никогда для этого не создавались. Всякие мелкие RTOS - другой калибр. Еще есть всякие WinCE, etc - для настоящих извращенцев, которые хотят получить нечто странное и за бабки :)
раз ты развлекаешься с openwrt то очевидно знаешь какое количество патчей накладываецо на ядро твоего любимого линукса, чтобы оно хоть как-то взлетело на железяке. Я тоже пилю всякий шит, и поверь одним openwrt не ограничиваюсь, кстати не самый качественный продукт.
По поводу _моей_ некромании ты децл погорячился оглянись вокруг, кругом полно всякого булшита который работает на тыщу лет уже как не поддерживаемом 2.4 ядре, всякие асусы к примеру 500 серии. Одна из лучших серий медиаплееров Dune работает _внимание_ на 2.6.22.19 (ух ты!). Если ты сам не догадался почему они все сидят на протухших ядрах так я тебе скажу - потому что АПИ в линуксе каждый релиз ломается, ну не может торвальдс мыслить дальше чем следующий релиз. А сломал АПИ значит нужно переписывать весь варез который ты на С писал для этой железки. Модули ядра написанные для 2.6.22.19 хрена лысого ты загрузишь в 2.6.32 и тд. и ты это прекрасно знаешь. А всякие нехорошие люди из всяких broadcom`ов любят еще сорцы на дрова не отдавать не смотря на весь ваш жпл вместе взятый, ну релизят дрова они под 2.4 а поделки с реверсинжирингом которые как-то работают на 2.6 это просто ахтунг. И потом я на тебя посмотрю как ты на 4метровый флеш запихаешь 2.6 ядро с обвязкой и попробуешь туда поставить хотя бы 1,5 полезных проги, не говоря уже о всяких transmission и тд.А стандартов в линуксах вообще раз-два и обчелся, а по большому счету у каждого дистростроителя и прошивкостроителя свой стандарт, openwrt, ddwrt, d+rtn, и тд. Вот когда начнешь _сам_ собирать прошивки для чего-то более отличного чем soho роутер, LFS так сказать, вот тогда то ты и наматеришься на свой линукс. Попробуй на досуге хотя бы для dir320 2.6.32 ядро собери и запихни, можешь развлечься еще и установкой openvpn сервера на него... только не говори что dir320 это гуано, потому как 2.4 нахэ никому не нужный на нем очень даже работает и openvpn сервер пашет на ура.
Портировани FreeBSD на хлам идет не очень быстро, про все остальное я вообще не упоминаю, есть маза правда ковырнуть NetBSD, но дров под нее нема. Вот я и сожалею о том что кроме кривого линупса больше ничего и не поставишь.
> А что не так то? Работают люди. Делая те компоненты так как ИМ было нужно и удобно.Ну ваще-то делая для других, надо делать также, чтоб и ИМ было удобно. :)
> Лично я ядра менее .32 считаю ископаемыми
Ну да, если каждый месяц покупать новый ПК, то ископаемые. У людей стоят сервера ещё с 2.4, и ничего, работают и жрать не просят.
> Хотя я и не понимаю на кой черт
> надо было трогать /var/runДа вот, похоже, в линуксе никто ничего и не понимает. Поэтому и юзают нормальные люди фрю. И не бздят. :)
> Потому что если некто поюзал BSD в своей железке, то он и
> исходник зажопить обычно не забывает.У вас определённо перверсивное представление о BSD. Впрочем, это и так всем известно =)
Может, NetBSD...
главная проблема тут дрова под тот же broadcom, сидеть с железкой без wifi как-то не очень.
>Блин и почему нету никакой альтернативы в эмедддед решениях этому линуксу а?...То, что Вы не знаете, не значит, что ее нет - пользуйтесь QNX, VxWorks...
«Всю жизнь» в никсах не было /dev/.udev, dev/.mdadm, /dev/.systemd и /dev/.mount. Ни прочих костылей. И /dev был совсем другим. Всего несколько лет назад /media, /selinux, /srv и /sys не было. Да и /proc до сих пор не везде есть.Вот чтобы не городить зоопарк костылей для каждой системы — везде будет /run. Очень правильно.
> «Всю жизнь» в никсах не было /dev/.udev, dev/.mdadm, /dev/.systemd и /dev/.mount.залез в свой /dev. ни одного из указаных каталогов не обнаружил. Slackware 13.37 RC2. ЧЯДНТ?
>> «Всю жизнь» в никсах не было /dev/.udev, dev/.mdadm, /dev/.systemd и /dev/.mount.
> залез в свой /dev. ни одного из указаных каталогов не обнаружил. Slackware
> 13.37 RC2. ЧЯДНТ?ах, нет, вру. /dev/.udev таки есть. больше никого.
кстати, ни разу меня сие не напрягало.
> /dev/.udev таки есть. больше никогоВидимо, рейда в системе нет - минус .mdadm. А .mount где-нибудь в другом неожиданном месте лежит.
>кстати, ни разу меня сие не напрягало.
Думаю, пользователей slackware не будет напрягать, даже если хомяки станут в недрах /sbin/ монтироваться. Это же не федора какая-нибудь, тут всё патрикоугодно.
>> /dev/.udev таки есть. больше никого
> Видимо, рейда в системе нет — минус .mdadm.нет.
> А .mount где-нибудь в другом неожиданном месте лежит.
я, честно говоря, даже не знаю, что это и зачем оно надо.
> Думаю, пользователей slackware не будет напрягать, даже если хомяки станут в недрах
> /sbin/ монтироваться. Это же не федора какая-нибудь, тут всё патрикоугодно.будет, будет. меня вообще многое в слаке напрягает. но в остальных дистрибах меня напрягает намного больше вещей, потому сижу на слаке.
А /dev/.blkid.tab, /dev/.initramfs? В том-то и дело, что это отдельные костыли отдельных дистрибутивов. Пока немногочисленные, но если так пойдёт и дальше… Вот, решили пресечь это на корню, выделить специальный каталог. Разумно.
Они с точкой. ls -a
>Почему всю жизнь все никсы жили и не испытывали проблем, а теперь возникла необходимость?Помниться когда я вперые поставил Линукс себе на домашнюю машину(это был 1994 год и ядро у него было 1.0.2) у него было одно нарушение FHS которое мне понравилось, ведь жили же юниксы всю жизнь без этого (DGUX,Solaris,SCO еще что-то я тогда помню это был майнстрим, и были такие люди как ты которые кричали : что линукс это поделка это совсем не юникс, каким местом он юникс, он кто вообще BSD или SYSV). Так вот нарушение FHS было такое в Линуксе была директория /root а в мейнсриме ее не было хоум диаректори для рута был /. Причем команд su и темболее sudo небыло (хотя su помое-му кое-где была все-таки). Теперь посмотри в /root и вывали все это в /....
Правильнее было бы иметь /home/root
> Правильнее было бы иметь /home/rootНет. Не правильнее. /home у нормальных людей живет на отдельном разделе.
Что таке подход убунты? Он какой-то особенный и был впервые применен именно там?Перечитайте новость и расслабьтесь. Представители каноникала заявили что они так себе сделают. А Марк не ошибается. Только он знает, как обустроить десктопный линукс! То что одобрил Марк, одобряете и такие как вы.
> были такие люди как ты которые кричали : что линукс это поделка это совсем не юникс, каким местом он юникс, он кто вообще BSD или SYSV
> Перечитайте новость и расслабьтесь. Представители каноникала заявили что они так себе сделают. А Марк не ошибается. Только он знает, как обустроить десктопный линукс! То что одобрил Марк, одобряете и такие как вы.1. Мне не нравится выражение "такие как вы". Это уже переход на личности, поэтому "такие как вы" - господа, не умеющие вести дискуссию.
2. Мне без разницы, что одобрил Марк, его разработчики эффективно решили проблему, это куда важнее. И его поделием не пользуюсь, ведь оно для таких убунтариев, как вы, которые готовы лизать задницы Маркам, Торвальдсам, не имея своего мнения, аргументируя это словом "прогресс".
3. Грустно и печально, что мэйнстрим - это линукс, а не BSD или Minix. А все из-за таких, как вы, которые превратили изначально убогую студенческую поделку в "модную и свободную" систему, которая не может быть достаточно стабильной, чтоб ей доверяли больше, чем BSD в плане безопасности. И дистрибутивы которой наплодились и разрознили unix-сообщество так, что в каждом дистрибутиве есть новые уникальные и несовместимые фичи-костыли, создающие головные боли пользователям этих систем.
Нравится шоу уродов - ваше дело. Мне не нравится помнить о мелких и крупных различиях, администрируя различные сервера. Ладно бы просто различия Linux и FreeBSD, так еще приходится мириться с кучей дерьма в голове разработчиков дистрибутивов.
Ладно, "Такие как вы все" - устроит?
> Грустно и печально, что мэйнстрим - это линукс, а не BSD или Minix. А все из-за таких, как вы, которые превратили изначально убогую студенческую поделку в "модную и свободную" систему, которая не может быть достаточно стабильной, чтоб ей доверяли больше, чем BSD в плане безопасности.Есть мнение, что дело не только в моде, но и в лицензиях. Не все рискуют код на котором построен бизнес открывать под GPL, но открывать его под BSD желающих ещё меньше. С GPL если конкуренты твой код попользуют, то хотя бы наработки вернут, а с BSD закроют и спасибо не скажут.
>Почему всю жизнь все никсы жили и не испытывали проблем, а теперь возникла необходимость?Это потому, что создатель пульсаудио сделал жест рукой и все вокруг забегали. Возникает только вопрос, кто он такой, что под него прогибается весь линуксовый мэйнстрим? И это не смотря на его явно, скажем так, неровные поделки.
Думаю, лет так через пять этот товарищ похоронит весь линукс.
> Это потому, что создатель пульсаудио сделал жест рукой и все вокруг забегали.
> Возникает только вопрос, кто он такой, что под него прогибается весь
> линуксовый мэйнстрим?Умный человек, предлагающий адекватные решения наболевших проблем, очевидно же.
> И это не смотря на его явно, скажем так, неровные поделки.
Внезапно, неровным оказывается только pulseaudio и только в убунту. А в мандриве, например, тот же пульс работает отлично.
> Думаю, лет так через пять этот товарищ похоронит весь линукс.
Кто, Шаттлворт? Этот может, да.
>Умный человек, предлагающий адекватные решения наболевших проблем, очевидно же.Уж чего-чего, а с var/run не было проблем лет 15, если не больше. А теперь будут.
>Внезапно, неровным оказывается только pulseaudio и только в убунту. А в мандриве, например, тот же пульс работает отлично.Я пользователь мандривы. Задержка в 200 миллисекунд это не проблема? Да и упорству разрабов мандривы я могу только позавидовать. Столько патчей http://svn.mandriva.com/svn/packages/cooker/pulseaudio/relea.../, чтобы хоть как-то заставить эту поделку работать.
>Кто, Шаттлворт? Этот может, да.От него вреда меньше, ибо "улучшения" локализуются исключительно в пределах убунты.
>Я пользователь мандривы. Задержка в 200 миллисекунд это не проблема?У вас неправильная мандрива. В правильной мандриве пульс работает нормально. И в правильной сусе, кстати, тоже. И даже в дебиане, говорят.
>От него вреда меньше, ибо "улучшения" локализуются исключительно в пределах убунты.
Не только. Марк на всю никсовую идеологию свою заднюю лапу поднимает. И ещё пиарит это как единственно верный путь.
>У вас неправильная мандрива. В правильной мандриве пульс работает нормально. И в правильной сусе, кстати, тоже. И даже в дебиане, говорят.Вы таки по ссылке сходили? И вообще, ларчик просто открывается. В мандриве пульс отключается одной галочкой, а в дебиане так и вообще не устанавливается по-умолчанию. Кроме того, пульс в убунте берут из дебиана http://packages.ubuntu.com/source/maverick/pulseaudio
>Не только. Марк на всю никсовую идеологию свою заднюю лапу поднимает. И ещё пиарит это как единственно верный путь.Мне он как-то до лампочки. А вот из федоры "улучшения" текут во все дистры.
>Вы таки по ссылке сходили?Там много букв и текcта :'(
>В мандриве пульс отключается одной галочкой
А зачем его отключать, если он и так хорошо работает?
>А зачем а в дебиане так и вообще не устанавливается по-умолчанию.
Говорят, ставили специально, чтобы можно было регулировать громкость для каждой проги незаивсимо от её возможностей. И, говорят, работает отлично.
>Кроме того, пульс в убунте берут из дебиана
То-то я смотрю убунтовские патчи http://bazaar.launchpad.net/~ubuntu-core-dev/pulseaudio/ubun.../ так на дебиановские похожи http://patch-tracker.debian.org/package/pulseaudio/0.9.21-4
Как говорил Леннарт про некоторые патчи убунты "это прямое оскорбление" (http://0pointer.de/blog/projects/pa-in-ubuntu.html). А в дебиане практически только мелкие фиксы по части расположения файлов.
> И, говорят, работает отлично.говорят, что кур доят.
>говорят, что кур доят...... и pulseaudio глючит.
>>говорят, что кур доят…
> … и pulseaudio глючит.доеных кур я не видел, а глючный пульсаудио — видел. предпочитаю верить фактам, которые наблюдал и проверял сам, а не утверждениям «пульсаудио не глючит, потому что не глючит!»
А я не видел ни доёных кур, ни глючного пульса. Вот нормально работающий пульс - видел.Наверное, всё дело в том, что я не юзаю убанту?
> Наверное, всё дело в том, что я не юзаю убанту?прикинь — я тоже. какое совпадение!
> Умный человек, предлагающий адекватные решения наболевших проблем, очевидно же.Интересно услышать мнение Торвальдса по этому поводу.
Предсказываю разделение дистрибутивов unix-like и fedora-way.
>> Умный человек, предлагающий адекватные решения наболевших проблем, очевидно же.
> Интересно услышать мнение Торвальдса по этому поводу.Судя по тому, что патчи от Леннарта (в основном наращивание фич для systemd) проходят в мейнстрим ядра, мнение Торвальдса о работе Леннарта скорее положительное :-)
> ... дистрибутивов unix-like ....Из того, что видел - все они какие-то частично юникс-лайк.
Тут, наверно, будет "unix-like run" :)
> Внезапно, неровным оказывается только pulseaudio и только в убунту.В федоре он не ровнее, встроенный микшер работает лучше, без задержек и слишком умного перенаправления звука когда в системе несколько звуковых карт, поэтому после установки системы PA -- один из первых кандидатов на "yum remove"
Федорино Коре... Вообще странная тенденция плодить каталоги в корне по поводу и без. Почему тогда каталоги юзеров в корень не класть, подобно руту...
> Почему тогда каталоги юзеров в корень не класть, подобно руту...Патамушта юзеров много, а рут один. Если юзер Вася без хомяка останется - это проблема Васи. А вот если без хомяка останется рут - это проблема всей системы и все её юзеров.
> Федорино Коре... Вообще странная тенденция плодить каталоги в корне по поводу и
> без. Почему тогда каталоги юзеров в корень не класть, подобно руту.../home — корень всех бед человеческих.
> /home — корень всех бед человеческих.Не, если уж корень, тогда / :P.
Save the planet: rm -rf /* yourself :)
rm: cannot remove `yourself': Permission denied
>Почему тогда каталоги юзеров в корень не класть, подобно руту...так ничего и не мешает, useradd -d /vasya vasya
В принципе идея неплохая. У меня большенство серверов сейчас имеют в качестве / USB-Flash в ro с виртуальным /var, /tmp, и т.д. А жесткие (если они вообще есть) уже в зависимости от предназначения сервера собираются в RAID и монтируются после загрузки основной части системы
Интересен такой коммит в systemd http://cgit.freedesktop.org/systemd/commit/?id=80758717a6359...
Вот кусок сообщения:+ log_warning("/usr appears to be on a different file system than /. This is not supported anymore. "
+ "Some things will probably break (sometimes even silently) in mysterious ways.");
Согласен, эти люди скоро похоронят линукс.
> Согласен, эти люди скоро похоронят линукс.А что, за создание дистра не снабженного такими сомнительными "улучшениями" будут расстреливать с особой жестокостью?
>А что, за создание дистра не снабженного такими сомнительными "улучшениями" будут расстреливать с особой жестокостью?Расстреливать не будут, но проблем с ними будет больше. Прям как с фряхой при портировании линуксового софта.
> Расстреливать не будут, но проблем с ними будет больше.Проблемы будут от небольших несовместимостей, но
> Прям как с фряхой при портировании линуксового софта.
Вот так сходу смог придумать разве что 1 внятный метод вызвать у бсдунов конкретный батхерт при портировании - юзать чтонить типа clone() с флагами типа неймспейсов/контейнеров. Тогда они обломятся т.к. похожего функционала у них нет. Но это какой-то сильно специфичный пример, нужный очень изредка.
>> Вот так сходу смог придумать разве что 1 внятный методА udisks, udev, alsa, gem? Это мало? Кроме того мне до лампочки "баттхёрт", ибо пилить софт под каждую систему не мне. Но благодаря усилиям некоторых товарищей, скоро придётся пилить ещё и под каждый дистрибутив.
Это всё от того, что у тебя реального опыта нифига нету, иначе знал бы. чем системы отличаются, и какие геморрои бывают при портировании.
> А что, за создание дистра не снабженного такими сомнительными "улучшениями" будут расстреливать
> с особой жестокостью?дистр с "улучшениями" будет грузиццо за 10 сек, а без в 2 раза дольше, конечно хомяки сразу же возрадуюцо таким улучшениям. а как же. а потом оне плавно перетекут в убунту и будет фсем щастье! о!
>дистр с "улучшениями" будет грузиццо за 10 сек, а без в 2 раза дольше, конечно хомяки сразу же возрадуюцо таким улучшениям. а как же. а потом оне плавно перетекут в убунту и будет фсем щастье! о!Ни куда они не перетекут. Сабжевые "улучшения" попадут во все бинарные дистры, включая debian. Остается только красноглазие в виде генты или арча.
> Ни куда они не перетекут. Сабжевые "улучшения" попадут во все бинарные дистры,
> включая debian. Остается только красноглазие в виде генты или арча.Если эти улучшения действительно делают жизнь лучше, то, конечно, перетекут.
Если же они приводят к развитию хронического красноглазия на почве траха с системой, то они, по традиции, так и останутся эксклюзивной фичей убунты.
арч - это красноглазие? поюзайте, потом скажете. пакман это самый лучший пакетный манагер.
> арч - это красноглазие? поюзайте, потом скажете.
> пакман это самый лучший пакетный манагер.Доказательства в студию!
> дистр с "улучшениями" будет грузиццо за 10 сек, а без в 2 раза дольше,Ну ладно, если все будет настолько замечательно - я даже согласен потерпеть расколбас. Потому что вижу разницу между стартом допустим роутера, камеры наблюдения или там кого еще за 15 секунд вместо 30. Хотя я и не понимаю почему перенос /var/run -> /run обязан все ускорить в 2 раза. Если от этого наступает такой эпичный прогресс, давайте все файлы в / вывалим, как в CP/M, чтоли?А директории вообще отменим как излишние сущности :)
это просто шедеврально! а потом они и /home запретят монтировать.
> Интересен такой коммит в systemd http://cgit.freedesktop.org/systemd/commit/?id=80758717a6359...Прежде чем начинать вопить и швыряться пометом, стоит почитать обоснование: http://freedesktop.org/wiki/Software/systemd/separate-usr-is...
Что характерно, автор поясняет, что проблемы с /usr на отдельном разделе возникают не из-за systemd (ему-то как раз пофигу), а из-за кривых рук дистросторителей. Дело systemd - предупредить.
>Что характерно, автор поясняет, что проблемы с /usr на отдельном разделе возникают не из-за systemd (ему-то как раз пофигу), а из-за кривых рук дистросторителей.Где-то я уже это слышал. И главное, в списке дубовый софт типа ALSA, D-Bus, CUPS, с которым таких проблем никогда не было. Я уже начинаю ненавидить этих идиотов.
Особенно пикантно выглядит присутствие в списке кривого софта его же собственного уродливого детища под названием PulseAudio.
> его же собственного уродливого детища под названием PulseAudioВы так говорите, как будто pulseaudio действительно плохо работает.
>Вы так говорите, как будто pulseaudio действительно плохо работает.Так он вообще у меня вообще не работает. Леннарт кричит про кривую звуковуху. Вывод: только под снос.
Это не его (systemd) собачье дело. И не пользователя предупреждать надо, а баги вешать на эти кривые руки. Тем паче если они в соседнем отделе.
>Это не его (systemd) собачье дело. И не пользователя предупреждать надо, а баги вешать на эти кривые руки. Тем паче если они в соседнем отделе.Эти кривые руки всегда могут послать лесом. Нет багрепортов от юзеров - всё оки, гуляй отсюда.
А так юзер хотя бы сразу корень зла увидит, а не будет на костях чёрной курицы гадать. И может, хоть один из тысячи да зарепортит.
> А так юзер хотя бы сразу корень зла увидит, а не будет
> на костях чёрной курицы гадать. И может, хоть один из тысячи
> да зарепортит.да. всенепременно если увижу — зарепорчу баг в systemd.
>если оно плачет, что не может что-то поддерживать — то пусть пофиксят так, чтобы плакать перестало.Вот когда udev и еще стопятьсот программ пофиксят, тогда и перестанет. Должен же кто-то сказать, из-за чего весь сыр-бор.
>вот тогда багрепорт полетит уже в сторону удева.
Боюсь, сначала багрепорты полетят куда угодно, но не к истинным виновникам торжества.
Люди, выросшие в мире, где отдельный /usr был вполне нормальным явлением, долго не смогут понять, в чём же дело. В результате посыпется куча жалоб на systemd, plymouth, ядро, видеодрайвера и уборщицу бабу Валю.
> Вот когда udev и еще стопятьсот программ пофиксят, тогда и перестанет.благодарю. когда мне понадобится программа, которая будет вякать про то, что надо пофиксить другие программы — я такую и поищу/напишу. а системди вякать нечего, я её не спрашивал.
> Должен же кто-то сказать, из-за чего весь сыр-бор.
ну и пусть в списках рассылки соответствующих говорит, мне-то об этом долдонить зачем?
> Боюсь, сначала багрепорты полетят куда угодно, но не к истинным виновникам торжества.
я лично отослал бы удевовцам.
> Люди, выросшие в мире, где отдельный /usr был вполне нормальным явлением, долго
> не смогут понять, в чём же дело. В результате посыпется куча
> жалоб на systemd, plymouth, ядро, видеодрайвера и уборщицу бабу Валю.а некоторые (типа меня) и не будут пытаться понять. если оно работало раньше, и это было удобно — не ломайте. поломали — идиоты, быстро почините. не хотите — досвидос, я тогда лучше на винду пойду, там хоть сразу ясно, что идиотизм никто никогда чинить не будет.
> Прежде чем начинать вопить и швыряться пометом, стоит почитать обоснование: http://freedesktop.org/wiki/Software/systemd/separate-usr-is...что характерно — пульсаудио один из первых в списке проблемного софта.
> что характерно — пульсаудио один из первых в списке проблемного софта.Дык софт абсолютно без проблем делает только майкрософт. А разработчики из редхата умеют признавать свои ошибки, в отличие от.
>> что характерно — пульсаудио один из первых в списке проблемного софта.
> Дык софт абсолютно без проблем делает только майкрософт. А разработчики из редхата
> умеют признавать свои ошибки, в отличие от.и, натурально, заместо чинить свой пульсаудио они предпочитают так напугать юзера, чтобы он делал всё Единственно Правильным Путём.
>и, натурально, заместо чинить свой пульсаудиоМне кажется, отсутствие стереозвука до момента монтирования файловых систем, право же, не такая уж и страшная проблема. Вот udev внушает гораздо больше опасений.
> Мне кажется, отсутствие стереозвука до момента монтирования файловых систем, право же,
> не такая уж и страшная проблема. Вот udev внушает гораздо больше
> опасений.ну, раз это не проблема — зачем оно в списке проблемных приложений? тут или трусы, или крестик, и то и то не выходит.
>А разработчики из редхата умеют признавать свои ошибки, в отличие от.Пока они умеют их добавлять. Вот не было бы systemd и ни кто не знал бы, что под лялих почти все(!) сервисы кривые. А мы видать идиоты, раз почти 10 лет гоняли кривой софт, который странным образом работал без проблем на отдельном /usr и с /var/run
Это чуть другая история (см. тж. http://lwn.net/Articles/429695/) -- хотя IMNSHO Леннарт взял на себя слишком много таким предупреждением о граблях в других местах (хотя при разборе полётов минимум одно из этих мест оказалось отсебятиной в интересах пульса -- чтоб добраться до {pci,usb}.ids и понарисовывать на крыжиках чего физического -- а других сколь-нибудь фич, а не попросту багов, не припоминаю).
> Сокращение точек tmpfs-монтирования, вместо /var/lock и /var/run останется один /run;Угу, у нас же mountpoint-constrained environment, острый дефицит точек монтирования.
> Хранение всех требуемых в процессе работы приложений данных в одном месте. ... все будет собрано в /run;Что мешает всё собрать в /var/run?
> Уход от использования начинающихся с точки скрытых файлов;А какая связь? Если они про /dev/.something, то это и так проговорено.
> Возможность стандартизировать для всех дистрибутивов размещение директории для хранения доступных на ранней стадии runtime-данных;Угу, самый лучший способ ввести общий стандарт - отказаться от стандарта де-факто. Молодцы, чо...
> У разработчиков исчезнет ощущение дискомфортаКакие тонкие натуры, понимаешь!
> Создание более четкого разделения..."Более" - это насколько более?
Всё это, на самом деле, не более чем словоблудие, единственный весомый аргумент - что /var/run нужна до того, как смонтируется /var, и единственный способ разрешить это противоречие они видят в использовании /run.
А вообще, то, что в каждом дистре даные распиханы по каталогам на свой манер, уже давно не новость, так что - ну, будет ещё и /run, не помрём.
> Что мешает всё собрать в /var/run?Читай выше. /var может оказаться в отдельном разделе с noexec.
>Для решения проблемы с недоступностью /var/run на ранней стадии загрузки различные дистрибутивы придумывают свои несовместимые с другими системами решенияПоэтому надо придумать еще одно решение, поддержать традицию так сказать.
А кому мешают точки и при чем здесь они ― не понятно мне пока.
Идея хорошая.ЗЫ, по поводу того что lock туда-же. Может еще приведут в порядок и нормально локи научатся делать, а то очень радуют такие локи, от которых потом все стопается.
Стопается, о юный друг, когда не умеют нормально снимать/срубать.
Ога, такое чувство что программы пишут без учета того что они могут завершиться некорректно.
Стандартное, простое, легкое для понимание неправильное решение для блокировки повторного запуска, используемое в over9000 программах:
Создаем файлик, потом в конце удаляем его, а если файлик уже есть, то мы выходим. Работает просто замечательно, до первого нештатного завершения процесса.
> URL:
> Новость: https://www.opennet.ru/opennews/art.shtml?num=30080Дык Линукс никогда и не стремился быть Юниксом.
Так, отправная точка. А дальше - мировая революция, зохавать всех.
Хотите Юникс - вэлком: www.openbsd.orgА что же /var/run?
Мож. тут бывают спецы по AIX, интересно их мнение на этот счет.
Говорят сначала тоже Юниксом была эта ОС (по крайней мере внешне),
потом с-ии-льно изменилась.
Канонiчное определение unix:проприетарная операционная система, совместимая с posix не менее, чем на 1%.
Всё, что подходит под это определение, можно считать эталоном современного юникса.
Windows?
> Windows?А что, у них есть Unix services for windows. Насколько оно там совместимо - ну кто сильно хочет заделаться в поклонники Мазоха имхо может пойти и проверить :)
У аикса свое горе - в нем реестр придумали.
> У аикса свое горе - в нем реестр придумали.Реестр windows был задуман как альтернатива сральнику из многочисленных конфиг-файлов,
которые каждый норовил наваять и раскидать как бог пошлет. Каждая прога тащит в себе
парсер, любое изменение формата ломает совместимость. Разделения прав доступа к разным опциям конфигурации нет. Правка конфигов вручную исключает даже минимальную защиту от дурака или банальной опечатки, которую потом бывает весьма нетривиально найти. Администрировать их даже в масштабах 1 системы было и остается жестоким баттхертом. Я уж не говорю про масштабы предприятия.
То, что первые реализации реестра в Винде были мягко говоря кривоваты вовсе не означает
что идея плоха. Наоборот, она очевидна, и отсутствие подобного механизма в большинстве
современных Unix-like операционках указывает их отсталость.
> URL:
> Новость: https://www.opennet.ru/opennews/art.shtml?num=30080Похоже, пришло время пересмотра стандартов?
Тогда почему бы не попереименовывать
/bin - /Binares Files
/sbin -> /System Binares Files
/etc -> /Et cetĕra
/var -> /Variable Data
/run -> /Data For Running Process
/home -> /Users Datas And Documents
/proc -> /Datas For Process
/lib -> /Programm LibraryА в ядро ОС включить графическую подсистему и грузить её одним файлом, имеющим внутри себя файловую систему, и при загрузке монтировать интернет-ресурс, содержащий все драйвера?
Или даже вообще отключить возможность загружать ядро локально! Пусть у юзера останется только загрузчик!
> Или даже вообще отключить возможность загружать ядро локально! Пусть у юзера останется
> только загрузчик!(Глядя на u-boot, качающий ядро и рутфс по TFTP): Здравствуйте, Кэп!
Данное сообщение прошу рассматривать исключительно как САРКАЗМ, блин.
> Данное сообщение прошу рассматривать исключительно как САРКАЗМ, блин.Да ладно, для восприятия сарказма требуются как минимум зачаточные признаки интеллекта ..
> Похоже, пришло время пересмотра стандартов?
> Тогда почему бы не попереименовывать
> /bin - /Binares Files
> /sbin -> /System Binares Files
> /etc -> /Et cetĕra
> /var -> /Variable Data
> /run -> /Data For Running Process
> /home -> /Users Datas And Documents
> /proc -> /Datas For Process
> /lib -> /Programm LibraryВсё это сделано в GoboLinux.
> Всё это сделано в GoboLinux.Если бы оно еще было живым. x86_64 нет, arm нет, документации нет, новых рецептов нет, воды нет, жизни нет, заселена полутора некрофилами-за-идею.
Тогда у вас получится пародия на OS X, только без application bundles. Хотя если добавить туда тот же Nix... Эх.Вообще, FHS/LFS это анахронизм, ад и погибель. Ну вот на какого лешего вообще мне *на десктопе* с двумя разделами (/ и /home) на одном единственном винте, нужны /bin, /usr/bin, /sbin, /opt/*/bin, /usr/local/bin и $HOME/.local/bin? Потому что бородатые старперы считают что это очень практично, т.к. проверено мейнфреймами в 80-х? Так one size NEVER fits all.
Сто лет хочу уже в файловой системе улучшенную смесь NEXTSTEP и Plan 9. Но не судьба.
> Тогда у вас получится пародия на OS X, только без application bundles.
> Хотя если добавить туда тот же Nix... Эх.
> Вообще, FHS/LFS это анахронизм, ад и погибель. Ну вот на какого лешего
> вообще мне *на десктопе* с двумя разделами (/ и /home) на
> одном единственном винте, нужны /bin, /usr/bin, /sbin, /opt/*/bin, /usr/local/bin и $HOME/.local/bin?
> Потому что бородатые старперы считают что это очень практично, т.к. проверено
> мейнфреймами в 80-х? Так one size NEVER fits all.
> Сто лет хочу уже в файловой системе улучшенную смесь NEXTSTEP и Plan
> 9. Но не судьба.Видимо бородатые старперы хорошо понимали, что валить в одну кучу систему, программы, исходники, пользовательские и системные данные, временные файлы и пр крайне херовая идея.
Поэтому по возможности структурировали разные по назначению компоненты. И с того момента
это нисколько не потеряло актуальности, а скорее даже наоборот. Если подумать, то окажется что в штатном режиме работы не нужно ничего записывать и фиксировать время доступа к системным компонентам, но есть резон разместить их на максимально защищенной от сбоев файловой системе. А вот о временных файлах можно особенно не заботиться, зато желательно чтоб доступ к ним был побыстрее. То же касается и различных кэшей. А еще очень неплохо держать пользовательские данные и конфигурацию системы отдельно, чтобы в случае чего сразу знать, что нужно сохранить, а что смело грохнуть. Вот и получается простая и эффективная структура. И надо заметить совершенно не важно /bin или c:\Program files\ -
смысл от этого не меняется ни разу.
Ну а любителям держать все в корне одной огромной FS хочу пожелать удачно полечить гемморой.
>[оверквотинг удален]
> /var -> /Variable Data
> /run -> /Data For Running Process
> /home -> /Users Datas And Documents
> /proc -> /Datas For Process
> /lib -> /Programm Library
> А в ядро ОС включить графическую подсистему и грузить её одним файлом,
> имеющим внутри себя файловую систему, и при загрузке монтировать интернет-ресурс, содержащий
> все драйвера?
> Или даже вообще отключить возможность загружать ядро локально! Пусть у юзера останется
> только загрузчик!Вы MacOS X видели?
Тогда уж лучше Program files и Documents and settings для /home . А чо, совместимость!
)))
Кто скажет, почему монтирование не сделать на начальном этапе до запуска демонов...
>...почему монтирование не сделать на начальном этапе до запуска демонов...Перечисли все возможные драйверы, необходимые для монтирования и сам поймёшь
>>...почему монтирование не сделать на начальном этапе до запуска демонов...
> Перечисли все возможные драйверы, необходимые для монтирования и сам поймёшьinitrd разве не поможет?
Как будто их море, а из долбаной мысли побыстрее загрузится и показать картинку, кому она нужна эта быстрота, 5 секунд грузится или 10...
>...а из ... мысли побыстрее загрузится и показать картинку...Всю дорогу считал, что лучше один раз включить, и потом до-олго работать, а не перезагружать на каждый чих... Грустно, братцы...
А если не нужно долго работать? Например нужно быстро глянуть что-нибудь в инете или на локальном диске, прочитать/отправить письмо. В результате загрузка и выключение занимают в несколько раз больше времени, чем собственно "работа". Не страшно, если подобная надобность возникает в результате неспешной застольной беседы, хуже, когда из-за экстренного телефонного звонка.
>А если не нужно долго работать? Например нужно быстро глянуть что-нибудь в инете или на локальном диске, прочитать/отправить письмоДля таких потребностей есть режим "sleep".
Для задач мобильного использования интернет есть немного другие ОС и устройства...
А любая попытка создать _универсальную_ OS приведут к созданию "универсального растворителя".
Делать им нечего.
Пожалуйста, "симовлической" может быть зарплата - ссылка, все-таки, "символьная".
Символьная от слова символы?Нет, она как раз symbolic, то есть символическая. Мягкая. В противоположность жёсткой.
Уж не помню, к какому комменту пример:
%mount
/dev/ada1s1a on / (ufs, local, noatime, soft-updates)
devfs on /dev (devfs, local, multilabel)
/dev/ada1s1e on /usr (ufs, local, noatime, soft-updates)
/dev/ada1s1d on /var (ufs, local, noatime, soft-updates)
/dev/md0 on /var/run (ufs, asynchronous, local, noatime)
/dev/md1 on /tmp (ufs, asynchronous, local, noatime)Вот вам и /usr в отдельном разделе и tmp и /var/run в памяти. Там может быть и tmpfs, у меня mfs. Мне пофиг :)
Хз, у меня что-то должно сломаться? Не похвалиться ради, а примера для.%uname -or
FreeBSD 8.2-PRERELEASEХотя, run, по логике, можно бы и унести куда подальше, точнее поближе. Но учитывая, какой бардак, _имхо_, в файловых системах в дистрах линукса, такие "нововведения" скорее пугают и настораживают. =\
Разговор идет не о фре, там как раз энтого нет...
Та я понял. Я не вкурил, почему тут всё работает, а там нифига (всмысле, по новости, без костылей)
потому что это линукс, stable API nonsence, а если сказать по другому - когда коту делать нечего он известно что делает :)
В линуксах абсолютно нет системного подхода, каждый сам себе дистроклепатель и ССЗБ.
> потому что это линукс, stable API nonsence, а если сказать по другому
> - когда коту делать нечего он известно что делает :)
> В линуксах абсолютно нет системного подхода, каждый сам себе дистроклепатель и ССЗБ.а в *BSD чтоль есть общий системный подход ? когда фришники с опенёнками договорятся чтоб можно было без перестановки оси одной перестановкой портов из фри опен получить ?
> а в *BSD чтоль есть общий системный подход ? когда фришники с
> опенёнками договорятся чтоб можно было без перестановки оси одной перестановкой портов
> из фри опен получить ?Это две РАЗНЫЕ операционные системы. С разными задачами. Встречный вопрос: Когда дистрибутивы Линукса будут придерживаться хотя бы FHS?