Официально анонсирован (http://permalink.gmane.org/gmane.linux.gentoo.devel/81901) проект eudev (https://github.com/gentoo/eudev), в рамках которого разработчики дистрибутива Gentoo приступили к развитию форка системы udev, отвечающей за управление файлами устройств в директории /dev и обработку операций подключения/отключения внешних устройств. Причиной создания форка является несогласие разработчиков Gentoo с новой политикой развитии udev, которая поставила под угрозу способность поддерживать существующие установки Gentoo.
Несмотря на то, что udev по прежнему доступен для обособленного использования и может быть собран без привязки к особенностям systemd, недовольство вызывает разработка udev с оглядкой на новые версии ядра Linux, что часто нарушает совместимость со старыми системами. При этом, по мнению разработчиков Gentoo, привязка к новым возможностям ядра Linux не всегда оправдана и привносится даже тогда, когда зависимости от новых версий ядра можно избежать. Подобная тенденция стала наблюдаться после перехода (https://www.opennet.ru/opennews/art.shtml?num=33526) udev под крыло проекта systemd, разработчики которого не заинтересованы в предоставлении полной поддержки в udev систем, выступающих в роли альтернативы systemd.
Eudev будет развиваться как проект группы заинтересованных разработчиков из сообщества Gentoo с целью предоставления альтернативного решения, которое со временем может быть одобрено для интеграции в дистрибутив Gentoo. Мэйнтейнерам используемого в настоящее время пакета udev не навязывается переход на форк, тем не менее разработчики eudev намерены показать, что в поддержании systemd-udevd вне пакета systemd нет необоходимости, когда есть eudev.
В конечном счёте, будет ли дистрибутив переведён на eudev или останется на systemd-udevd зависит от решения консультативного совета Gentoo.
Eudev будет развиваться без привязки к технологиям Gentoo, что позволит использовать его и в других дистрибутивах Linux. Первое время развитие будет нацелено на обеспечение работы в Gentoo, но это не исключает приём исправлений для ошибок, специфичных для других дистрибутивов. После того, как работа eudev в Gentoo будет признана стабильной планируется наладить сотрудничество с разработчиками других дистрибутивов с целью привлечения их к разработке проекта. В идеале, eudev можно будет использовать для прозрачной замены systemd-udevd. Для упрощения участия в проекте сторонних разработчиков в качестве платформы для размещения репозитория решено использовать GitHub. Разработчики eudev готовы к интеграции поддержки интересных другим дистрибутивам возможностей, за исключением необоснованных предложений (например, желании интегрировать в eudev собственную систему инициализации) и изменений, делающих невозможным обновление существующих систем на новую версию eudev.
Для минимизации регрессивных изменений планируется поддерживать активную ветку разработки HEAD в состоянии постоянной готовности к релизу. Для того чтобы добиться высокого качества ветки HEAD добавление любого незначительного изменения потребует рецензирования со стороны другого разработчика eudev, для значительных изменений автору кода нужно будет получить рецензию от двух разработчиков. Кроме того, с целью упрощения поиска регрессий, коммиты, вносящие логически независимые изменения, должны явно документировать все затрагиваемые подсистемы.Из задач, которые планируется решить на начальном этапе развития eudev упоминается работа по избавлению от привязки к особенностям новых версий ядра, возвращение возможности работы со старыми ядрами Linux и различными инструментариями, улучшение совместимости с существующими системами инициализации, такими как OpenRC и Upstart. В настоящее время уже выполнена переработка системы сборки и восстановлена поддержка некоторых старых ядер Linux до версии 2.6.31 включительно. Код помечен как готовый для выпуска первой бета-версии. В дерево портажей добавлен пакет eudev. Следующими шагами станет обеспечение поддержки библиотеки uclibc, устранение регрессий, вызванных переходом с module-init-tools на kmod (https://www.opennet.ru/opennews/art.shtml?num=32577), возвращение правил 70-persistent-net.rules и возможности использования отдельного раздела /usr без initramfs. В настоящее время проект systemd находится в процессе смены лицензии с GPL на LGPL, ответвление eudev произведено в разгар данного процесса и в дальнейшем разработчики форка намерены последовать примеру systemd и все развиваемые в рамках eudev улучшения распространять под лицензией LGPL.
В качестве примера неоправданной оптимизации в systemd-udevd, ведущей к регрессивным изменениям, упоминается переход на API kmod для загрузки модулей, который позволяет загружать модули ядра без вызова дополнительных утилит. Проблема такого подхода связана с тем, что kmod загружает модули последовательно, в то время как классическая обработка правил в udev производилась с ответвлением нового процесса. Экономия 0.01 мс на выполнение вызова fork() ничтожна по сравнению с задержкой в 10-20 мс, необходимой для загрузки данных с диска. Для ускорения загрузки модулей с диска в kmod предлагается компоновать группу модулей в один файл, но данная возможность не применяется во всех дистрибутивах. Раньше, так как udev мог стартовать загрузку следующего модуля не дожидаясь окончания загрузки предыдущего, подобные задержки компенсировались параллельным чтением модулей. После перехода на API kmod все модули стали загружаться последовательно, и в случае зависания модуля, например, из-за невозможности инициализировать оборудование, теперь останавливается и загрузка других модулей.
Что касается вопроса оптимизации скорости загрузки, то по мнению разработчиков eudev, при загрузке надёжность важнее скорости, а экономия микросекунд не оправдывает появление ошибок и урезание гибкости настройки, поэтому основное внимание будет уделяться в первую очередь устранению регрессивных изменений, внесённых разработчиками systemd. Тем не менее, разработчики eudev не отвергают предложений по ускорению загрузки, если такие предложения разумны, и намерены приступить к оптимизации скорости после выпуска нескольких стабильных релизов.
URL: http://permalink.gmane.org/gmane.linux.gentoo.devel/81901
Новость: https://www.opennet.ru/opennews/art.shtml?num=35619
> избавлению от привязки к особенностям новых версий ядраА генту-LTS они выпустят?
> После перехода на API kmod все модули стали загружаться последовательно
Троллинг поттеринга и ко засчитан :)
я думаю их доведут до такого состояния новые новшества ядра, что они выпилят ядро линукс и на Gentoo/FreeBSD перейдут
Зачем чего-то выпиливать? Генту не привязана к ядру. Какое хочешь ядро, такое и собирай.
жаль, нету время компилить генту, да и для себя смысла не вижу
После ubuntu скорость работы поражает! Загружается быстро и не шевелит HDD постоянно при запуске приложений.
> После ubuntu скорость работы поражает! Загружается быстро и не шевелит HDD постоянно
> при запуске приложений.После ubuntu скорость работы почти любого дистра поражает.
>> После ubuntu скорость работы поражает! Загружается быстро и не шевелит HDD постоянно
>> при запуске приложений.
> После ubuntu скорость работы почти любого дистра поражает.Вот что питон животворящий делает!
// Кстати, в генте, как и в федоре, пакетный менеджер написан на нем, родимом.
>> После ubuntu скорость работы почти любого дистра поражает.
> Вот что питон животворящий делает!Ну так его аптгетом побустать - минут пять, с передышками. Гента за это время даже либрофис скомпилить не успеет :)
Не нравится компилировать, юзай Archlinux. Тоже не плох.
> Не нравится компилировать, юзай Archlinux. Тоже не плох.Спасибо, мне работающая система нужна а не минное поле для камикадзе, где могут по ходу пьесы заменить систему инициализации и что там еще.
"Вы просто не умеете их готовить!" ;)Gentoo на стареньком ноуте с 1.5ГГц Celeron у меня собирается за ночь. С кедами, лисой и либрой.
Главное уметь настроить сборку. Когда на гигабитке еще 8 современных ядер выделяются в помощь, все компилится так, что не успеваешь на экране увидеть что-то, так мелькает.
Память добил до двух гиг. Во время сборки полтора гига выделяю под ramfs. Для тех пакетов, которым это мало, прописано исключение.
> Gentoo на стареньком ноуте с 1.5ГГц Celeron у меня собирается за ночь.А убунта вкатывается с флехи на SSD за 5 минут. Почувствуйте разницу.
>> Gentoo на стареньком ноуте с 1.5ГГц Celeron у меня собирается за ночь.
> А убунта вкатывается с флехи на SSD за 5 минут. Почувствуйте разницу.Именно с этого и началось. Почуствовал. Не шевелится она на таком ноуте. Работать просто не возможно.
А Gentoo взлетела.
гентушечка всегда была побыстрее люого дистра )) странно что сейчас об это упомянули ))
> гентушечка всегда была побыстрее люого дистра ))А гентушники - всегда были теми, кто в это верит, а ещё - в деда мороза:)
> А гентушники - всегда были теми, кто в это верит, а ещё - в деда мороза:)Не, ну эти камикадзи реально любят ввинтить дюжину недефолтных ключей компилера касающихся оптимизации. Профит они конечно с этого имеют. Но в результате потом валят в багтрекер и имеют всем мозг рассказывая про мегауникальный баг - мол, как-так, вместо трактора танк получается. А тут то и оказывается что такая дикая комбинация флагов никем особо не тестировалась и компилер сгенерил глючный код. И если самого автора бага еще не жаль, то вот чем виноваты авторы программы что им такой гражданин упорно имел мозг - не понятно..
> Не, ну эти камикадзи реально любят ввинтить дюжину недефолтных ключей компилера касающихся
> оптимизации. Профит они конечно с этого имеют. Но в результате потом
> валят в багтрекер и имеют всем мозг рассказывая про мегауникальный багВообще то, те что хотя бы читали хендбук в курсе, что первое что необходимо при обнаружении бага - пересобрать пакет с дефолтными ключами.
Ну а те кто не читал - те будут пытаться напрягать других в любом случае и на любой система.
>> гентушечка всегда была побыстрее люого дистра ))
> А гентушники - всегда были теми, кто в это верит, а ещё
> - в деда мороза:)Сложно не верить тому, что видишь собственными глазами ;)
Идеология Gentoo ориентирована на то, что юзер собирает себе систему под свои нужды. Можно собрать так, что будет хуже любого дистрибутива. Можно и наоборот - все в руках человеческих.
Не нужно быть семи пядей во лбу, чтобы понять: если программа собрана под любой процессор и под любую конфигурацию, то оно заведомо будет работать медленней и потреблять больше ресурсов, чем если ее же собрать под КОНКРЕТНЫЙ процессор и под КОНКРЕТНУЮ конфигурацию.
> Не нужно быть семи пядей во лбу, чтобы понять: если программа собрана
> под любой процессор и под любую конфигурацию, то оно заведомо будет
> работать медленней и потреблять больше ресурсов, чем если ее же собрать
> под КОНКРЕТНЫЙ процессор и под КОНКРЕТНУЮ конфигурацию.Ох, еще один наивный плод загибающейся системы школьного образования этой страны...
Начнем с того, что ты можешь просто не заметить разницы. Т.к. доминируют в указанных показателях все-таки обычно вычислительная сложность алгоритмов, а не детали их реализации. Разница - проценты, максимум 10-20, но никак не в разы. Измерить ее - еще вполне таки можно, а вот "на глаз" заметить...
Во-вторых, код *может* быть оптимизирован по определенное семейство процессоров, под определенную архитектуру. Но исключительно редко - под *конкретный* процессор и тем более какую-то *конкретную* конфигурацию. Короче, как там в итоге все обернется (в плюс али в минус) при указании сборки всего с конкретными ключами компилятора и "под конкретный процессор" - можно только гадать. Но блаженны верующие, да...
> Ох, еще один наивный плод загибающейся системы школьного образования этой страны...Критерии оценки различны. Однако результатом МОЕГО школьного образования оказалось, как выяснилось как-то на 25-ти летии выпуска, что три четверти класса живут и работают за пределами страны, в которой учились в школе.
> Начнем с того, что ты можешь просто не заметить разницы. Т.к.
> доминируют в указанных показателях все-таки обычно вычислительная сложность алгоритмов,
> а не детали их реализации.Мы говорим об одной и той же программе или разных? Разные в данном контексте смысла сравнивать не вижу.
> Разница - проценты, максимум 10-20,
> но никак не в разы. Измерить ее - еще вполне
> таки можно, а вот "на глаз" заметить...Предлагаю эксперимент. Собрать wget без поддержки SSL, Kerberos, LDAP и т.п. И сравнить потребление памяти двумя вариантами при скачивании файла с ftp. Разница будет в РАЗЫ.
Другой пример. Если программа не умеет сама определять наличие 3DNow/SSE и т.п., то компилятор не будет на каждый чих устраивать проверки и генерить код и для AMD и для Intel. Он сгенерит код, который будет медленно, в разы медленнее (!) работать везде. Если его, конечно, не попросить об обратном.Конкрентный пример с конкретным ноутом: VLC в убунте на нем показывать SD h264 не смог (IP TV). В генте я добился вполне приемлемого результата. Когда задача решается или нет это в РАЗЫ или как?
> Но исключительно редко - под *конкретный* процессор и тем
Возможно я не точно выразился. Речь шла, конечно, под конкрентую серию и архитектуру CPU.
Привести примеры, когда какие-то дополнительные команды CPU дают прирост производитлеьности в разы? А ведь многие дистрибутивы собираются до сих пор под P5...> Но блаженны верующие, да...
Во-первых, в царство небесное не верю, во-вторых, я вообще не верю в то, что нельзя проверить.
>> Начнем с того, что ты можешь просто не заметить разницы.
> Мы говорим об одной и той же программе или разных?Здесь речь шла о том, что вносит основной вклад в показатели, о которых вы сделали столько громких заявлений.
> Предлагаю эксперимент. Собрать wget без поддержки SSL, Kerberos, LDAP и т.п. И
> сравнить потребление памяти двумя вариантами при скачивании файла с ftp.Ну вперед, покажите цифры первого варианта. Культурненько - вывод соответствующих утилит, а не вашу интерпретацию оного.
> Не нужно быть семи пядей во лбуНе нужно иметь двух сантиметров высоты лба, чтобы понять, что сэкономленное время стоит рассматривать вместе с дополнительно затраченным.
>> Не нужно быть семи пядей во лбу
> Не нужно иметь двух сантиметров высоты лба, чтобы понять, что сэкономленное время
> стоит рассматривать вместе с дополнительно затраченным.Естественно. В случае с гентой будет минут на 10 дольше. Или вы считаете не время работы человека, а время работы компьютера? Ну тогда за ночь 2-3 раза в год он рублей на 10 электричества действительно съест ;)
> Или вы считаете не время работы человека, а время работы компьютера?В первую очередь человека, но в зависимости от ситуации и компьютерное тоже может заметно влиять.
> нету времяЗа что вы так ненавидите русский язык?
Да ладно, это нормальный воронежский акцент.
> я думаю их доведут до такого состояния новые новшества ядра, что они
> выпилят ядро линукс и на Gentoo/FreeBSD перейдутНет, они просто сделают форк ядра - eLinux. Ну и копирайты на © Gentoo Foundation поменяют, само собой :)
Нормально там с копирайиами. emerge udev скачивает/распаковывает systemd (!) и собирает.
>копирайтыкопилефты же!
Нет, копирайты. Копилефт - это такой вид копирайта. Открой любой файл под GPL - в первых строчках будет слово Copyright
> я думаю их доведут до такого состояния новые новшества ядра, что они выпилят ядро линукс и на Gentoo/FreeBSD перейдутПока что решение для автомонтирования ФС флешек через devd на FreeBSD выглядит так (фрагмент файла /etc/devd.conf):
# Automount
attach 10 {
match "device-name" "umass[0-9]+";
action "sleep 4 && mkdir -p /media/$device-name && chown -R <username> /media/$device-name && \
(/sbin/mount_msdosfs -o sync -L ru_RU.UTF-8 -D CP1251 /dev/da0s1 /media/$device-name || \
/sbin/mount_msdosfs -o sync -L ru_RU.UTF-8 -D CP1251 /dev/da0 /media/$device-name)";
};detach 10 {
match "device-name" "umass[0-9]+";
action "/sbin/umount -f /media/$device-name && rm -r /media/$device-name";
};Нужно только как-то научить devd подсовывать правильное значение <username> в многопользовательской ОС и обеспечить простой способ корректного отмонтирования ФС со стороны этого пользователя вместо точного определения точки монтирования и выполнения команды umount для (пока ещё присоединённого) носителя. Был бы HAL, как раньше, такой проблемы не существовало бы. Теперь — увы и ах — всё переделали с завязкой на Linux udev.
> Нужно только как-то научить devd подсовывать правильное значение <username> в многопользовательской
> ОС`whoami`, не?
> и обеспечить простой способ корректного отмонтирования ФС со стороны этого
> пользователя вместо точного определения точки монтирования и выполнения команды umount
> для (пока ещё присоединённого) носителя. Был бы HAL, как раньше, такой
> проблемы не существовало бы. Теперь — увы и ах — всё
> переделали с завязкой на Linux udev.Подумай, что можно сделать.
>> Нужно только как-то научить devd подсовывать правильное значение <username> в многопользовательской
>> ОС
> `whoami`, не?Не.
hint: от кого выполнится этот whoami и будет ли разница хоть раз?
> `whoami`, не?Представь: в компе появилась флешка, комп об этом узнал. Имеется в виду, что об этом узнали всякие системные демоны, которые запущены под root или под nobody или под ещё каким-нибудь системным пользователем. Если этот демон сделает whoami, это whoami вернёт ему root или nobody. А надо определить, КТО вставил флешку, кто щас сидит перед компом. И это нетривиальная задача. Например, если щас запущены иксы, и юзер залогинен в них, то нужно взять того юзера, который залогинен в иксах. Впрочем, даже это соображение вызывает сомнения: что если у нас какой-нибудь сервер с кучей мониторов. За каждым сидит какой-нибудь чел. И тут появляется флешка. И кто из них её вставил?
>> После перехода на API kmod все модули стали загружаться последовательно
> Троллинг поттеринга и ко засчитан :)eudevщики сами себя затроллили, расписавшись в своем ламерстве. Прав был Грег...
Ядро всегда загружает модули последовательно, даже если вызовы были выполнены из параллельных процессов.
А демоны грузятся параллельно.
Прикинь?
> А демоны грузятся параллельно.
> Прикинь?В systemd, upstart и даже sysvinit - да. А в openrc - официально не поддерживается :)
Не надо ля-ля. Поддерживается официально, но!:rc_parallel has never officially been declared a stable feature (see the
comments in rc.conf regarding this).и
# WARNING: whilst we have improved parallel, it can still potentially lock
# the boot process. Don't file bugs about this unless you can supply
# patches that fix it without breaking other things!Надеюсь, переводить не надо и вам ясно, что официально оно поддерживается, но на уровне нестабильной ветки дистрибутива, а также вам должно быть ясно, почему это так и как сделать эту функцию лучше в случае не правильной ее работы ;)
> Не надо ля-ля. Поддерживается официально, но!:Не надо ля-ля. Вот комментарий разработчика: http://www.linux.org.ru/forum/desktop/8529910?cid=8530111
> просто параллельная загрузка официально не поддерживается и могут возникать баги, которые будут закрывать WONTFIX
> а также вам должно быть ясно, почему это так и как сделать эту функцию лучше в случае не правильной ее работы ;)Так, как это делают в ubuntu - тупо скопировать с поцтеринга?
> Так, как это делают в ubuntu - тупо скопировать с поцтеринга?Даже поттеринг может временами предложить что-то дельное. Оценивать надо технологии а не личности, баклан.
>> Так, как это делают в ubuntu - тупо скопировать с поцтеринга?
> Даже поттеринг может временами предложить что-то дельное. Оценивать надо технологии а не
> личности, баклан.За баклана он ответит!
>> А демоны грузятся параллельно.
>> Прикинь?
> В systemd, upstart и даже sysvinit - да. А в openrc -
> официально не поддерживается :)А не поддерживается потому, что рандомно виснет. И никто не может понять, почему https://bugs.gentoo.org/show_bug.cgi?id=391945
Подозреваю, проблема в глобальных блокировка питона.
> Ядро всегда загружает модули последовательно, даже если вызовы были выполнены из параллельных процессов.Разница как я понимаю в том, что в одном случае р@ком встает весь процесс загрузки, ожидая пока модуль раздуплится, а во втором - ну, висит некий процесс. И пусть висит. Остальное то грузится.
Позволю себе заметить что туповэйтинг - то с чем Поттеринг так люто боролся. А тут вдруг на третий день Зоркий Глаз замечает что при загрузке модулей по цепочке есть туповэйтинг инициализации модулей и загрузка стоит колом. Косячок-с :)
> Разница как я понимаю в том, что в одном случае р@ком встает весь процесс загрузки, ожидая пока модуль раздуплится, а во втором - ну, висит некий процесс. И пусть висит. Остальное то грузится.Ну дык в systemd так и сделано. Окончания загрузки модулей никто не ждет - загрузка идет дальше.
А вот гентушный openrc так не умеет. Там есть режим параллельного запуска служб, но он не поддерживается официально и юзается "на ваш страх и риск". Поэтому для параллелизации загрузки (хотя бы) модулей приходится юзать легаси код из systemd :)
> А вот гентушный openrc так не умеет.Ах, вот оно что. Сошлись 2 NIH-овца в поединке...
> Разница как я понимаю в том, что в одном случае р@ком встает
> весь процесс загрузки, ожидая пока модуль раздуплится, а во втором -
> ну, висит некий процесс. И пусть висит. Остальное то грузится.Нет, не в этом. В любом случае все работает по второму варианту.
> Нет, не в этом. В любом случае все работает по второму варианту.Из изначальных заяв следовало что это нифига не так.
> Разница как я понимаю в том, что в одном случае р@ком встает
> весь процесс загрузки, ожидая пока модуль раздуплится, а во втором -
> ну, висит некий процесс. И пусть висит. Остальное то грузится.
> Позволю себе заметить что туповэйтинг - то с чем Поттеринг так люто
> боролся. А тут вдруг на третий день Зоркий Глаз замечает что
> при загрузке модулей по цепочке есть туповэйтинг инициализации модулей и загрузка
> стоит колом. Косячок-с :)Нет. systemd не ждет инициализации всех устройств - ему достаточно только дисков с / и /usr. Все остальные девайсы могут спокойно инициализироваться в фоне (если для них не прописаны явные зависимости в default.target).
А вот openrc by design последовательный - он ждет, пока завершится "udevadm settle", и продолжает загрузку только после этого.
Соответственно, попытки "ускорить" чтение модулей параллелизацией на уровне udev - это просто костыли, исправляющие openrc-специфичные проблемы. Afaik, даже в upstart этого бардака нет.
> Нет. systemd не ждет инициализации всех устройств - ему достаточно только дисков с / и /usr. Все остальные девайсы могут спокойно инициализироваться в фоне (если для них не прописаны явные зависимости в default.target).Поттеринг изобрел smss.exe ? После загрузки системы она все грузится и не готова к работе.
> Поттеринг изобрел smss.exe ? После загрузки системы она все грузится и
> не готова к работе.Как и разработчики upstart и sysvinit (да, даже он научился запускать службы параллельно).
И только разработчики openrc и рады бы, да не работает оно - виснет https://bugs.gentoo.org/show_bug.cgi?id=391945
>> Поттеринг изобрел smss.exe ? После загрузки системы она все грузится и
> не готова к работе.
>Как и разработчики upstart и sysvinitу меня sysvinit, и всё загружается до логина. Поццерингофилы лепят остальным свойственные им болячки?
> Ядро всегда загружает модули последовательно, даже если вызовы были выполнены из параллельных процессов.Узкое место не в запуске ядром, а в чтении с диска - с диска код модулей читается параллельно, не ожидая пока предыдущий модуль запустится ядром.
> Узкое место не в запуске ядром, а в чтении с диска -
> с диска код модулей читается параллельно, не ожидая пока предыдущий модуль
> запустится ядром.В результате бедный винчестер постоянно дергается между разными секторами, да и планировщик IO мечется как угорелый. Вместо последовательного чтения - рандомное. Что практически всегда медленнее, даже на SSD.
А вот в kmod все по уму сделано - если скорость критично, можно собрать модули вместе, и тогда скорость их загрузки с винта будет максимально возможной.
>В результате бедный винчестер постоянно дергается между разными секторами, да и планировщик IO мечется как угорелый. Вместо последовательного чтения - рандомное.Скажи это Поттерингу.
>>В результате бедный винчестер постоянно дергается между разными секторами, да и планировщик IO мечется как угорелый. Вместо последовательного чтения - рандомное.
> Скажи это Поттерингу.Поттеринг это знает, и использует параллелизацию только там, где она дает выигрыш.
Разработчики Gentoo тоже это знают, и используют ее только там, где она дает проигрыш :)
>>В результате бедный винчестер постоянно дергается между разными секторами, да и планировщик IO мечется как угорелый. Вместо последовательного чтения - рандомное.
> Скажи это Поттерингу.Есть тонкая разница между параллелизацией чтения и параллелизацией исполнения.
Поттеринг ее понимает, гентушники - нет.
>Есть тонкая разница между параллелизацией чтения и параллелизацией исполнения.Это ты к чему? systemd читает винт последовательно? Насмешил. Там полный event-based, и даже твой Поттеринг не узнает, что и когда будет прочитано.
> В результате бедный винчестер постоянно дергается между разными секторами,Намного лучше если он быстро прочтет модуль и потом покурит бамбук минутку, пока модуль раздупляется.
> Узкое место не в запуске ядром, а в чтении с диска - с диска код модулей читается параллельно, не ожидая пока предыдущий модуль запустится ядром.Существенный бонус тут только тогда, когда модули лежат на разных дисках, с разными очередями запросов на чтение. В противном случае запросы опять-таки окажутся в одной очереди, и при этом возникнет излишняя нагрузка на планировщики I/O ядра и диска.
Кроме того, в большинстве случаев модули лежат в initrd (прочитанный ранее с диска загрузчиком), т.е. на RAM-диске. Скорость чтения с которого - ни разу не узкое место.
> Существенный бонус тут только тогда, когда модули лежат на разных дисках,Или SSD, который к рандомным seek-ам относится нормально.
>> Узкое место не в запуске ядром, а в чтении с диска - с диска код модулей читается параллельно, не ожидая пока предыдущий модуль запустится ядром.
> Существенный бонус тут только тогда, когда модули лежат на разных дисках, с
> разными очередями запросов на чтение. В противном случае запросы опять-таки окажутся
> в одной очереди, и при этом возникнет излишняя нагрузка на планировщики
> I/O ядра и диска.man readahead
> Кроме того, в большинстве случаев модули лежат в initrd (прочитанный ранее с
> диска загрузчиком), т.е. на RAM-диске.Ага, 5% всех используемых модулей - в initrd.
man 5% (подсказка: 5% - не "большинство")
> Скорость чтения с которого - ни
> разу не узкое место.Ну да, initrd не и диска же считывается, а из астрала.
>Ну да, initrd не и диска же считывается, а из астрала.initrd загружается в память еще на самом первом этапе загрзуки вместе с ядром, и потом висит в памяти до завершения работы. Потому модули с него читаются из оперативной памяти всегда.
>>Ну да, initrd не и диска же считывается, а из астрала.
> initrd загружается в память еще на самом первом этапе загрзуки вместе с
> ядром, и потом висит в памяти до завершения работы. Потому модули
> с него читаются из оперативной памяти всегда.Фееричный бред
Надо было назвать не Eudev, а Gundev.
Было бы веселее.
Чувак, они это самое "G" хотят выпилить, а не впилить.
Entoo?
Гента резко упала в моих глазах после переноса ifconfig и route из /sbin/ в /bin/. ЧСВ некоторых "разработчиков" дистрибутива зашкаливает.
"Гента резко упала в моих глазах после переноса ifconfig и route из /sbin/ в /bin/" - так а в чем проблема то? ln -s ...))
> "Гента резко упала в моих глазах после переноса ifconfig и route из
> /sbin/ в /bin/" - так а в чем проблема то? ln -s ...))Ну как, раньше ламерам надо было полный путь вводить, а так сразу все работает. Кощмар, теперь те кто пользуется дистром уже 2 дня не смогут чмырить тех кто только что вкатил себе это! Ужас!
А какая глубококонцептуальная разница то?
Теперь обычный пользователь может посмотреть интерфейсы и таблицы маршрутов. Это неконцептуально.
> Теперь обычный пользователь может посмотреть интерфейсы и таблицы маршрутов. Это неконцептуально.Неконцептуально или не безопасно?
>> Теперь обычный пользователь может посмотреть интерфейсы
> Неконцептуально или не безопасно?Негламурненько! Пи-и-иу....
>>> Теперь обычный пользователь может посмотреть интерфейсы
>> Неконцептуально или не безопасно?
> Негламурненько! Пи-и-иу....Предлагаю в ответ /home и /opt перенести в /sbin
> Предлагаю в ответ /home и /opt перенести в /sbinАга, /home и /opt - в /usr/local, /usr/[s]bin - в /[s]bin/local, ./sbin -> в /bin/sbin, /bin - в отдельный раздел, монтируем его R/O, остальные noexec...
Скорее! Пока RH не запатентовал!!
>> Предлагаю в ответ /home и /opt перенести в /sbin
> Ага, /home и /opt - в /usr/local, /usr/[s]bin - в /[s]bin/local, ./sbin
> -> в /bin/sbin, /bin - в отдельный раздел, монтируем его R/O,
> остальные noexec...
> Скорее! Пока RH не запатентовал!!Слишком сложно для них. Предлагаю свалить всё в одну папку /. При совпадении имен добавлять в конце "_XXXXX", где XXXXX - не что иное как порядковый номер по отсортированному списку inode в файловой системе.
> иное как порядковый номер по отсортированному списку inode в файловой системе.Где вы были в эпоху CP/M?! :D
> Слишком сложно для них. Предлагаю свалить всё в одну папку /. При
> совпадении имен добавлять в конце "_XXXXX", где XXXXX - не что
> иное как порядковый номер по отсортированному списку inode в файловой системе.А ещё допилим FS с версионностью
/ifconfig:98985438202372
%)
> А ещё допилим FS с версионностью
> /ifconfig:98985438202372Мсье знает толк :). Только версию надо сделать пострашнее, типа как хэши в гите или гуиды какие-нибудь :)
а rhel какие нибудь бинарники переносил?
>>>> Теперь обычный пользователь может посмотреть интерфейсы
>>> Неконцептуально или не безопасно?
>> Негламурненько! Пи-и-иу....
> Предлагаю в ответ /home и /opt перенести в /sbinНе, давайте лучше все, кроме /dev, /proc и /tmp, перенесем в /usr.
> Предлагаю в ответ /home и /opt перенести в /sbinДа, у Gentoo должен быть собственный путь! Зачем бездумно повторять за всякими федорками?
>> Предлагаю в ответ /home и /opt перенести в /sbin
> Да, у Gentoo должен быть собственный путь! Зачем бездумно повторять за всякими
> федорками?Т.е. Вы предлагаете создать /gentoo , а уже в нем bin, usr, opt, home, tmp, etc?..
Оригинальненько, ничего не скажешь ;)
Установка gentoo начинается с того, что в "родительском" дистрибутиве создаётся, к примеру /mnt/gentoo и там далее внутри по списку bin, usr etc.
Так что, ваше предложение уже реализовано.
> Т.е. Вы предлагаете создать /gentoo ,Накаркаете - услышат же :)
таки бред(!) на счёт секурности. Что мешает обычному юзеру сказать /sbin/ifconfig? и не надо расказывать про права доступа. Покажите мне дистр, в котором "ис каропки" /sbin имеет права доступа 700.
Точно. Мне вообще надоело писать /sbin/ifconfig вместо ifconfig. Если конфигурацию можно посмотреть от пользователя, я буду смотреть её от пользователя. Делать sudo ради того, чтобы не писать /sbin/ -- глупо. Экономия в один символ. К тому же приходится лишний раз пароль вводить. Так что перенос ifconfig из /sbin в /bin -- здравое решение.
> Точно. Мне вообще надоело писать /sbin/ifconfig вместо ifconfig. Если конфигурацию можно
> посмотреть от пользователя, я буду смотреть её от пользователя. Делать sudo
> ради того, чтобы не писать /sbin/ -- глупо. Экономия в один
> символ. К тому же приходится лишний раз пароль вводить. Так что
> перенос ifconfig из /sbin в /bin -- здравое решение.Хм. А насколько вообще здравое решение запускать ifconfig от пользователя?
Настолько же здравое как и запускать ipconfig /all или смотреть Пуст -> ... -> Сетевые подключения.
> Настолько же здравое как и запускать ipconfig /all или смотреть Пуст ->
> ... -> Сетевые подключения.$ ipconfig /all
zsh: command not found: ipconfigА "пуска" у меня нет. Наверное, потому что у меня не Gentoo?
> Мне вообще надоело писать /sbin/ifconfig вместо ifconfig.Откройте для себя перменную среды PATH и файл $HOME/.profile :-)
> Точно. Мне вообще надоело писать /sbin/ifconfig вместо ifconfig+1
Хорошо, что есть ip a<enter>,
>> Точно. Мне вообще надоело писать /sbin/ifconfig вместо ifconfig
> Хорошо, что есть ip a<enter>,cat /proc/net/* - Наше фсё!!!
в том-то и дело, что сотни пользователей уже написали в тысячах скриптов /sbin/ifconfig. И удалённо обновились.
> в том-то и дело, что сотни пользователей уже написали в тысячах скриптов
> /sbin/ifconfig. И удалённо обновились.Какие-то больно старые скрипты. ifconfig/route с 2000 года еще deprecaeted в пользу iproute2.
Безопасность это процесс. Несколько странно думать, что перемещение нескольких файлов сделают безопасную систему опасной.
> Несколько странно думать, что перемещение нескольких файлов
> сделают безопасную систему опасной.Могут (например, если высунуть недостаточно аккуратно написанный suid helper из штатного места, где он хотя бы прикрыт правами доступа в каталог), но не в данном случае.
Не заню, как правильно, но в моем дистрибутиве ifconfig и route лежат в /sbin, но работают от обычного пользователя, если прописать полный путь.
> Не заню, как правильно, но в моем дистрибутиве ifconfig и route лежат
> в /sbin, но работают от обычного пользователя, если прописать полный путь.А в Генту даже путь прописывать не надо!
Это правильно и удобно. Хотя двигать оттуда, где устоялось не очень хорошо, лучше бы с дурацкой привычкой не давать простым пользователям /sbin:/usr/sbin в PATH покончили.
А вообще, культурные люди давно ip используют.
> Это правильно и удобно.Да.
> Хотя двигать оттуда, где устоялось не очень хорошо,
Да.
> лучше бы с дурацкой привычкой не давать простым пользователям /sbin:/usr/sbin в
> PATH покончили.Нет.
> А вообще, культурные люди давно ip используют.
Да.
А ещё есть симлинки. :)
>>лучше бы с дурацкой привычкой не давать простым пользователям /sbin:/usr/sbin в PATH покончили.
>Нет.Обоснуйте, пожалуйста.
>>>лучше бы с дурацкой привычкой не давать простым пользователям /sbin:/usr/sbin
>>>в PATH покончили.
>>Нет.
> Обоснуйте, пожалуйста.Дополнение засоряет, одного этого уже достаточно...
PS: http://sisyphus.ru/srpm/installer-feature-symlinks-from-sbin :)
>уже достаточно...Не достаточно.
> лучше бы покончили с простыми пользователями...Правильно, долой ламеров!!!
сhown -R root:root /
chmod -R o-rwxsSt /
> Теперь обычный пользователь может посмотреть интерфейсы и таблицы маршрутов.Ничего, что он и раньше "это" мог?
>> Теперь обычный пользователь может посмотреть интерфейсы и таблицы маршрутов.
> Ничего, что он и раньше "это" мог?Юзеры, ваще обнаглели, пинг - разрешили, traceroute - разрешили, некоторые,
не будем показывать пальцем, sudo разрешают....
>>> Теперь обычный пользователь может посмотреть интерфейсы и таблицы маршрутов.
>> Ничего, что он и раньше "это" мог?
> Юзеры, ваще обнаглели, пинг - разрешили, traceroute - разрешили, некоторые,
> не будем показывать пальцем, sudo разрешают....ыыы павлиныч, последний раз на клиентской инсталляции убунты - трейсроута не было вапще. на мою просьбу, а нельзя ли? - тут же поставили - они, оказывается, в рутовой консольке сидели. Говорил прозой, даже не подозревая...
> ыыы павлиныч, последний раз на клиентской инсталляции убунты - трейсроута не было вапще.Простые смертные tracepath нынче юзают. Это кастрированный трейсроут,
там можно задавать только размер пакета, да и то не более 64 кило.
re #208 (куда-то уже делось, видимо, из-за ругани) -- на альте так:$ ls -ld /var/log/messages /var/log/syslogИ соответственно такой саппорт можно засунуть в группу, посмотрев другие доступные по ней объекты и подумав (мне не доводилось, потому кэшированного ответа нет).
lrwxrwxrwx 1 root root 15 Feb 13 2009 /var/log/messages -> syslog/messages
drwxr-x--- 2 root adm 4096 Mar 1 2010 /var/log/syslogИли как вариант, достроить syslog на выдачу специально для них лога в более другое место либо на логсервер, где хоть в LogAnalyzer свалить. Если в дистрибутиве принимаются соответствующие *.d/*.conf, то хоть пакетом с шаблонным кусочком конфигурации.
> ыыы павлиныч, последний раз на клиентской инсталляции убунты - трейсроута не было вапще.А там по дефолту гламурненький mtr. Хорошая штука, кстати. Хоть и другая.
> А там по дефолту гламурненький mtr. Хорошая штука, кстати. Хоть и другая.Минздрав предупреждает:
$ ls -l =tracepath =mtr
-rwxr-xr-x 1 root root 13856 May 9 2011 /bin/tracepath
-rws--x--- 1 root netadmin 56276 Apr 22 2012 /usr/bin/mtr
Да никакой. Берем каталоги
/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbinи раскидываем по ним все бинарники от балды. Фак ю поцтеринг!
Давно пора сократить количество этих каталогов, я считаю.
> А какая глубококонцептуальная разница то?удалённо обновил и ребутнул. Несмотря на репутацию генты как якобы требующей постоянного контроля за обновлениями, с 2005го года не было обновления, после которого система пропадала бы из сети. Даже на новую систему инициализации был непротиворечивый опциональный даже после обновления переход. И в скриптах подъёма интерфейса был /sbin/route.
Что характерно, пока тогда думал, что с машиной, думал что Линус какой-нибудь усб_маллок в усб_юсер_маллок() переименовал, со стороны дистрибутива вообще новостей не ожидал.
АХренительно! У вас наверное и сервера тоже падают так же быстро, как и репутация дистрибутива!
=))
sbin это статически слинкованые бинарники а не то что ты подумал, хотя какая уже разница.
> sbin это статически слинкованые бинарники а не то что ты подумал, хотя
> какая уже разница.По факту, там уже давно лежат бинарники, юзающие so. Причем эти so могут лежать и в /usr (давеча в debian-devel был эпичный срач, когда это наконец заметили).
А в действительности, по этим самым "фактам" - в том же дебиане *необходимые* бинарники там лежат либо статические, либо с библиотеками в /lib. Такие дела. Вы ведь не думаете, что pam_cracklib.so понадобится для монтирования какой-либо файловой системы? :) В обсуждении debian-devel речь шла именно о таких исключениях.Пример:
$ ldd /sbin/fsck.ext3
linux-vdso.so.1 => (0x00007fff8f5ba000)
libext2fs.so.2 => /lib/libext2fs.so.2 (0x00002b66b354b000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x00002b66b3779000)
libblkid.so.1 => /lib/libblkid.so.1 (0x00002b66b397d000)
libuuid.so.1 => /lib/libuuid.so.1 (0x00002b66b3b9c000)
libe2p.so.2 => /lib/libe2p.so.2 (0x00002b66b3da0000)
libc.so.6 => /lib/libc.so.6 (0x00002b66b3fa8000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00002b66b430a000)
/lib64/ld-linux-x86-64.so.2 (0x00002b66b332b000)
$ ldd /sbin/lvm
linux-vdso.so.1 => (0x00007fffb91ff000)
libdl.so.2 => /lib/libdl.so.2 (0x00002b0a4081e000)
libreadline.so.5 => /lib/libreadline.so.5 (0x00002b0a40a22000)
libdevmapper.so.1.02.1 => /lib/libdevmapper.so.1.02.1 (0x00002b0a40c63000)
libudev.so.0 => /lib/libudev.so.0 (0x00002b0a40e85000)
libc.so.6 => /lib/libc.so.6 (0x00002b0a41093000)
/lib64/ld-linux-x86-64.so.2 (0x00002b0a405fe000)
libncurses.so.5 => /lib/libncurses.so.5 (0x00002b0a413f6000)
libselinux.so.1 => /lib/libselinux.so.1 (0x00002b0a4163c000)В общем, вы за дебиан не переживайте. Школота, конечно, и до дебиановских рассылок давным давно добралась - но там еще есть люди, которые могут этой школоте что-то разъяснить.
Напр.,
http://lists.debian.org/debian-devel/2012/08/msg00918.html
http://lists.debian.org/debian-devel/2012/08/msg00908.html
> А в действительности, по этим самым "фактам" - в том же дебиане
> *необходимые* бинарники там лежат либо статические, либо с библиотеками в /lib.А остальные - типа не-необходимые? Тогда, простите, какого хрена они делают в корне, а не в /usr?
The /usr Hierarchy
Purpose/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere.
Large software packages must not use a direct subdirectory under the /usr hierarchy.
Сходите FHS почитайте
Чего сказать-то хотел?
Он же сказал: чтобы сходили почитали FHS.
> В общем, вы за дебиан не переживайте.Блажен кто верует(С)
> Школота, конечно, и до дебиановских рассылок давным давно добралась - но там еще есть люди, которые могут этой школоте что-то разъяснить.
> Напр., http://lists.debian.org/debian-devel/2012/08/msg00918.html , http://lists.debian.org/debian-devel/2012/08/msg00908.htmlИ в качестве примера ссылки на 2012 год, ещё до печально известного голосования "будем голосовать, пока не проголосуют правильно(С)", это времена когда Демьян был ... Debian! Я тогда такие же речи пихал и вдруг ... :(
Нынче, 12 лет спустя демьяну тупо нечем хвастаться, just yet another Linux (C)
IMHO
man hier
Приплыли :)Utilities used for system administration (and other root-only commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin.
откуда же вас по на выпускали таких.
Читай внимательней http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES
Gentoo:# which ifconfig
/sbin/ifconfig# which route
/sbin/route
обновляться не пробовали?
Ха. Когда я при установке арча с очередной исошки вообще не нашёл ifconfig - вот это был номер :-D.
Арчь все еще требует загружать iso для свой установки и при этом не имеет инсталлятора?
Это у них kiss нынче такой :)
> Арчь все еще требует загружать iso для свой установкиНе требует, а предоставляет возможность.
>и при этом не имеет инсталлятора?Да, не имеет. И?
В том и вопрос, нужно мне iso загружать что бы arch установить или для этого любого livecd
Ммм, просто из интереса, а в чем сложность скачать лишний iso? Все равно потом из сети тянуть вагоны пакетов.
>> Арчь все еще требует загружать iso для свой установкиДык по любому вытащишь придётся, даже чтобы на скажем ventoy накатить. Да оно и правильно, вдруг сеть не заведётся? Вы просто уже забыли что так - бывает :)
>>и при этом не имеет инсталлятора?
>Да, не имеет. И?Во-общето имеет! Ы! Просто Арчешкольники предсказуемо! - даже свой фетиш не знают ;-p :-D
Коммит сделан в апстрим вообще-то
http://net-tools.git.sourceforge.net/git/gitweb.cgi?p=net-to...
Ну и раньше никто не мешал неруту выполнить /sbin/ifconfig
>Гента резко упала в моих глазахИ шо так таки и упала?! Это несчастье. Скорбим вместе с Вами.
А скажите мне как гентушник (со стажем) гентушнику: проблемы с секурностью от этого есть? И если нет, то на фига ли разводить холивар на пустом месте?
Я не гентушник, но если перенос вот этого в другой дир - самая большая проблема Генты ... то возможно :-)
Понаделали дистрибутивов и теперь переливают из пустого в порожнее, переписывая один и тот же функционал.<troll>Да, Аноним знает как лучше. Лучше, чтобы только Fedora с Red Hat и Debian с Ubuntu. ^.^</troll>
Надеюсь, Грега они всё же услышали.
А, что - он сказал по их поводу что-но новое и разумное?// А вот что ему ответили на очередное "фи":
"The fact that people seem to think they need to fork a project should be seen as a huge issue. You seem to be ignoring that entirely." (c) тот-самый-парень
> А, что - он сказал по их поводу что-но новое и разумное?Да, он сказал что дергать апи для вгрузки модулее - намного умнее чем делать какой-то форк и выполнять какой-то левый посторонний бинарник. ИЧСХ, он в этом прав. В конечном итоге все-равно это инструктирование ядра сделать некие операции. Указанный маршрут может быть короче и не требовать закладки на наличие в системе какого-то стороннего бинаря. Который вообще никто не обещал.
>> А, что - он сказал по их поводу что-но новое и разумное?
> Да, он сказал что дергать апи для вгрузки модулее - намного умнее
> чем делать какой-то форк и выполнять какой-то левый посторонний бинарник.Интересно, а "левый посторонний бинарник" общается с ядром посредством магии вуду?
Ох, школие.
С какого перепугу дистрибутив сам себе ничего не обещал?
А, ну да. А libkmod, стало быть, уже является частью стандарта POSIX, раз ты ее гарантируешь в любом дистрибутиве.Что мешает поддерживать ОБА способа загрузки? Зачем выламывать старый функционал, если это не оправдано?
"Мразилла Ко" каждый год демонстрирует - почему:Потому что тогда поддерживать придётся ОБА (аффтарский стиль сохранён!)
Но ведь тогда нельзя будет сократить программера (который и так на четверть ставки) и выписать себе очередной бонус! Резать к чёртоыой матери!(С) ПВ
> udev по прежнему [...] может быть собран без привязки к особенностям systemdЛожь. Он может быть _использован_ без привязки к systemd, но обособленная _сборка_ не поддерживается.
> Ложь. Он может быть _использован_ без привязки к systemd, но обособленная _сборка_ не поддерживается.В последнем выпуске systemd вроде лишние зависимости убрали "For embedded systems it is now possible to build udev and systemd without blkid and/or kmod support.". http://lists.freedesktop.org/archives/systemd-devel/2012-Nov...
Или вы о другом ?
Нет, немножко о другом.
Точнее, о том, что udev прекрасно работает без systemd.
Но не собирается без него, потому что там довольного много общего кода.
>> udev по прежнему [...] может быть собран без привязки к особенностям systemd
> Ложь. Он может быть _использован_ без привязки к systemd, но обособленная _сборка_
> не поддерживается.
>>> udev по прежнему [...] может быть собран без привязки к особенностям systemd
>> Ложь. Он может быть _использован_ без привязки к systemd, но обособленная _сборка_
>> не поддерживается.
> http://www.mail-archive.com/systemd-devel@lists.freedes...Немного промазал ссылкой: http://www.mail-archive.com/systemd-devel@lists.freedes...
Setting up to allow separate udev and systemd builds[PATCH 1/5] build-sys: move common libraries to separate Makefile
[PATCH 2/5] build-sys: move udev build to a separate makefile
[PATCH 3/5] build-sys: move systemd build to a separate makefile
[PATCH 4/5] build-sys: add --enable-systemd configure option
[PATCH 5/5] build-sys: add --enable-udev configure option
> Setting up to allow separate udev and systemd builds[PATCH 1/5] build-sys: move
> common libraries to separate Makefile
> [PATCH 2/5] build-sys: move udev build to a separate makefile
> [PATCH 3/5] build-sys: move systemd build to a separate makefile
> [PATCH 4/5] build-sys: add --enable-systemd configure option
> [PATCH 5/5] build-sys: add --enable-udev configure optionНа что закономерно ответили, что это изменение значительно усложняет систему сборки, а значит, противоречит принципу KISS.
> На что закономерно ответили, что это изменение значительно усложняет систему сборки,
> а значит, противоречит принципу KISS.Будучи применён достаточно последовательно, этот принцип может привести данный апстрём к мысли о значительном упрощении сборки -- только под шляпу... заодно и комбинаций вариантов для поддержки меньше, кругом выгода.
Суся, арч, мандрива, фруга и другие обидятся.
> Будучи применён достаточно последовательно, этот принцип может привести данный апстрём к мысли о значительном упрощении сборки -- только под шляпу... заодно и комбинаций вариантов для поддержки меньше, кругом выгода.Кстати, Миша, 5 лет спустя не могу не заметить -- так и вышло. =/
> значит, противоречит принципу KISS.Ага, а выколупывать нужные файлы после мейкинсталла - это у них значит KISS? :)
Lennart Poettering Tue, 19 Jun 2012 01:31:59 -0700On Tue, 12.06.12 12:52, William Hubbs (w.d.hu...@gmail.com) wrote:
heya,
Sorry, not going to merge this
> http://www.mail-archive.com/systemd-devel@lists.freedes...Redhat и ее разработчики. Традиционно кооперативны и не кладут болт на чужие проблемы. Совсем не похоже на ульриха и глибцу :)
просто Ульрих следит за качеством, а не за модными веяниями
> просто Ульрих следит за качеством, а не за модными веяниямиСреди широких масс модно закидывать Дреппера ссаными тряпками точно так же, как и Поттеринга, есличо.
> Среди широких масс модно закидывать Дреппера ссаными тряпкамиПри том не за красивые глаза а за вполне себе стиль майнтайнерства потребовавший от остальных или таскать вагон патчей или просто брутально форкаться как eglibc. Обратите внимание что у eglibc написано в достоинствах :)
Внезапно, майнтайнеры - это тоже люди. Они во первых в мало-мальски самостоятельных и чего-то из себя представляющих дистрах не собираюстя безмолвно строиться под шапку, кушая любой шит отсыпанный свыже, а во вторых, класть на их удобство - можно. Но - икнется потом. Ульриху таки икалось. А теперь eglibc пожалуй установлен на бОльщем числе компьютеров чем glibc оригинальный. Такие вот чудеса науки.
> просто Ульрих следит за качеством, а не за модными веяниямиУгу, поэтому отлупляет всяких лошпедов с их ARMами с коментами типа "а мы не поддерживаем эту архитектуру, идите в пень!". Ну если вам по пути с таким апстримом - флаг вам в руки и барабан на шею. Вот еще не хватало в открытой системе строиться под какие-то конкретные архитектуры просто потому что апстрим упоролся и забил на кроссплатформенность.
>> udev по прежнему [...] может быть собран без привязки к особенностям systemd
> Ложь. Он может быть _использован_ без привязки к systemd, но обособленная _сборка_
> не поддерживается.Посмотрите гентушный ебилд
>Посмотрите гентушный ебилдТам грязный хак, а не штатная сборка.
> Проблема такого подхода связана с тем, что kmod загружает модули последовательно, в то время как классическая обработка правил в udev производилась с ответвлением нового процесса. Экономия 0.01 мс на выполнение вызова fork() ничтожна по сравнению с задержкой в 10-20 мс, необходимой для загрузки данных с диска.Однако практика показывает, что после перехода udev на kmod система стала грузиться быстрее. Значит, кто где-то мухлюет с циферками.
«there's no way to load modules in parallel. Please check the kernel implementation of module_init before stating things like above. Exec'ing several instances of modprobe doesn't mean you are loading the modules in parallel.»
> Значит, кто где-то мухлюет с циферками.Понял, где. fork удава - это не 0.01 мс, а 0.01 с - т.е. 100 мс. Что, конечно же, "ничтожно" по сравнению с 10-20 мс.
> 0.01 с - т.е. 100 мсмда..
>> 0.01 с - т.е. 100 мс
> мда..Зато теперь меня возьмут в разработчики gentoo!
Тебя Похтеринг возьмёт.
Будешь пульсу пилить и задержки считать.
А потом с Грегом будешь всем отвечать "вы не понимаете".
> А потом с Грегом будешь всем отвечать "вы не понимаете".А вот Грег чисто технически прав: нормальный вариант это дергать вызов api если вам от системы что-то надо. А не дергать какие-то левые нестандартные бинари фиг знает где.
Однако лобовой дерг API ведет к блокирующим вызовам. Вероятно граждане должны бы юзать отдельные треды/форки для ускорения. Мало ли, может какой модуль будет минуту инициализироваться.
ну или просто разработчикия ядра -- придумают (или уже придумали?) -- API для неблокирующих вызовов :) .kmod не имеет там чтоли async-режима? [ну если не умеет -- думаю при большой необходимости разработчики-kmod всегда могут его запилить :).. врядли это нерешаемая проблема]
> Тебя Похтеринг возьмёт.Похтеринг не возьмет :(
> А потом с Грегом будешь всем отвечать "вы не понимаете".
Хочешь крикнуть "Кроа-Хартман - идиот!"? Крикни, не стесняйся!
>> Значит, кто где-то мухлюет с циферками.
> Понял, где. fork удава - это не 0.01 мс, а 0.01 с
> - т.е. 100 мс. Что, конечно же, "ничтожно" по сравнению с
> 10-20 мс.Стоп, не 100, а 10. Но все равно "ничтожно".
Насаждение systemd и включение в него udev похоже на попытки нагадить всем отличным от Федоры дистрибутивам и очень смахивает на тактику M$: "Пользователи ... со временем «сдаются». По словам Джули Ларсон Грин, точка перелома наступает примерно через шесть недель использования Windows 8".
Эта тактика описана у Сунь Цзы как "жечь мосты после прохождения наступающего войска". До создания Майкрософт оставалось 2000 лет.
> Насаждение systemd и включение в него udev похоже на попытки нагадить всем
> отличным от Федоры дистрибутивам и очень смахивает на тактику M$А гентушники, в свою очередь, пытаются присунуть всем остальным дистрам свой openrc.
Достаточно поискать эпичные обсуждения в архиве debian-devel, когда главный "разработчик" eudev Люся Горбатый пытался доказать дебиановцам, что они обязаны перейти на openrc, и пофиг, что его нет в дебиановских репах и он не умеет параллельной загрузки (в отличие от стандартного дебиановского инита).
Строго говоря, параллельная загрузка в генте есть, включается rc_parallel="YES" в /etc/rc.conf, так что высказанное вами на половину - ложь ;)
> Строго говоря, параллельная загрузка в генте есть, включается rc_parallel="YES" в /etc/rc.conf,
> так что высказанное вами на половину - ложь ;)Строго говоря, ее там нет. Разработчики OpenRC неоднократно говорили, что этот режим официально не поддерживается, и все багрепорты относительно него будут закрывать с WONTFIX.
>> Строго говоря, параллельная загрузка в генте есть, включается rc_parallel="YES" в /etc/rc.conf,
>> так что высказанное вами на половину - ложь ;)
> Строго говоря, ее там нет. Разработчики OpenRC неоднократно говорили, что этот режим
> официально не поддерживается, и все багрепорты относительно него будут закрывать с
> WONTFIX.Вот например, комментарий одного из ведущих разработчиков openrc:
http://www.linux.org.ru/forum/desktop/8529910?cid=8530111
>>> Строго говоря, параллельная загрузка в генте есть, включается rc_parallel="YES" в /etc/rc.conf,
>>> так что высказанное вами на половину - ложь ;)
>> Строго говоря, ее там нет. Разработчики OpenRC неоднократно говорили, что этот режим
>> официально не поддерживается, и все багрепорты относительно него будут закрывать с
>> WONTFIX.
> Вот например, комментарий одного из ведущих разработчиков openrc:
> http://www.linux.org.ru/forum/desktop/8529910?cid=8530111только следует уточнить, что я не только не ведущий, но даже и не разработчик openrc (не считая одного принятого коммита и нескольких не принятых). А по поводу rc_parallel я использую и многие используют, т.е. поддержка все же есть.
> только следует уточнить, что я не только не ведущий, но даже и
> не разработчик openrcЧто однако не извиняет отношения к фиче. Лишний повод не связываться с такой поделкой и разработчиками.
>Люся Горбатый пытался доказать дебиановцам, что они обязаны перейти на openrc, и пофиг, >что его нет в дебиановских репахВы таки можете не верить, но openrc есть в Дебиановских репах
> попытки нагадить всем отличным от Федоры дистрибутивам и очень смахивает на тактику M$: "Пользователи ... со временем «сдаются».Ключевое слово "пользователи". Пользователи венду не форкнут.
>> попытки нагадить всем отличным от Федоры дистрибутивам и очень смахивает на тактику M$: "Пользователи ... со временем «сдаются».
>Ключевое слово "пользователи". Пользователи венду не форкнут.Ну вон - демьян форкнули и сделали devuan без systemd ... хватит тямы назвать это "историей успеха"? :-\
>недовольство вызывает разработка udev с оглядкой на новые версии ядра Linux, что часто нарушает совместимость со старыми системами.
>Разработчики Gentoo официально анонсировали проект eudev
>что часто нарушает совместимость со старыми системами
>Разработчики Gentoo
>старыми системами
>GentooWTF???
>>недовольство вызывает разработка udev с оглядкой на новые версии ядра Linux, что часто нарушает совместимость со старыми системами.
>>Разработчики Gentoo официально анонсировали проект eudev
>>что часто нарушает совместимость со старыми системами
>>Разработчики Gentoo
>>старыми системами
>>Gentoo
> WTF???Ну надо же было к чему-то докопаться.
А что такого? Генту тянет кучу версий различного софта, и тянет довольно долго. Обычно выкидываются промежуточные версии, но избранное - годами живёт.
/me ждал крестового похода супротив еретиков, но форк udev'а - это тоже годно.:)
> /me ждал крестового похода супротив еретиков, но форк udev'а - это тоже годно.:)Правда форкеры сами не сильно лучше. "Война была равна" :)
> В качестве примера неоправданной оптимизации в systemd-udevd, ведущей к регрессивным изменениям, упоминается переход на API kmod для загрузки модулей, который позволяет загружать модули ядра без вызова дополнительных утилитэээээ... а это точно регрессия? точно-точно?
>> В качестве примера неоправданной оптимизации в systemd-udevd, ведущей к регрессивным изменениям, упоминается переход на API kmod для загрузки модулей, который позволяет загружать модули ядра без вызова дополнительных утилит
> эээээ... а это точно регрессия? точно-точно?Работает быстрее - значит, регрессия. По гентушным меркам.
Ведь неоднократно говорилось, что процы нынче мощные, SSD быстрые, а значит, тормоза не имеют значения.
>эээээ... а это точно регрессия? точно-точно?Таки не позволяет использовать что-то отличное от kmod. Уменьшение функционала есть регресс.
>>эээээ... а это точно регрессия? точно-точно?
> Таки не позволяет использовать что-то отличное от kmod. Уменьшение функционала есть регресс.kmod -- это лишь СРЕДСТВО а не цель.
а цель (функционал) -- это в данном случае инициализация модулей. :)
если проблема возникает только на старых ядрах -- то просто обнови ядро :), или не обновляй udev (до тех пор пока не решишься обновить ядро).
Есть среды, в которых твое СРЕДСТВО вдруг превратится в цель ради использования нового ядра.
Да здравствует стопиццот реализаций одного и того же функционала! Да здравствует Крылов, так точно предсказавший в басне про лебедя, рака и щуку всю суть разработки линукса!
басня кстате не совсем верная.в реальной жизни эти три животных врядли смогли бы начать такой проект (переместить воз).
я конешно перечитаю басню ещё раз -- может быть я забыл какие-то детали.
# P.S.: а что касается науки (если причислять -- Linux к науке) -- то давно уже было замечено, что развитие науки всегда шло через этапы:
... -> "разветвление" -> "объеденение" -> "разветвление" -> "объеденение" -> "разветвление" -> "объеденение" -> ...
расскажите это менеджерам в пнендостане, орущим devepoers, developers,developers и говорящих что конкуренция это хороше.
Блин веткой промазал
В басне tight coupling, а "в линуксе" всё-таки loose coupling.
>Да здравствует стопиццот реализаций одного и того же функционала!Да здравствует консолидация всего функционала в монолитный модуль!!!
> Да здравствует консолидация всего функционала в монолитный модуль!!!Ну, я и говорю, стопиццот недоделанных реализаций одного и того же функционала, равно как и гора костылей сверху для обеспечения видимости совместимости между разными дистрами и подсистемами - конечно же лучше.
Неинтересно ведь, когда функционал един и хорошо продуман.
Gentoo был интересным дистрибутивом, но его огромным минусом является тот факт, что ПО которые есть в его составе, очень долго получает статус стабильного. Например GCC или Glibc, и самое главное что процесс обновления ПО тоже не всегда проходит без проблем, и это при всем при том что ПО долго находится в стадии тестирования. Часто случается, что пока стабилизируется одна версия ПО уже выходит другая версия. Конечно же, это не проблема, если новая версия включает в себя только новый функционал, но не включает в себя исправления критических багов или уязвимостей. Да, можно такие патчи сделать и наложить самому, но в таком случае это почти все ПО которое установлено. Хотя есть аналог Gentoo с другой системой правления портами и даже с новыми версиями ПО. Но данный проект развивается медленно, хотя возможно даже уже заброшен. Есть и другие но, к сожалению, их основа на Gentoo а это накладывает на подобные проекты такую же тень что и у Gentoo.На мой взгляд, Gentoo теряет былую популярность. Но в нем есть и плюсы, которых к сожалению становятся все меньше. Темпы развития у проекта на мой взгляд очень сильно снижаются, что нельзя назвать плюсом в нашем быстро развивающемся мире.
Фундаментальное свойство ПО: постоянные изменения и переработка с целью соответствия его требованиям поставленных задач (которые тоже меняются со временем), исправление ошибок, оптимизация (тюнинг). Кто этого не понимает, тот надолго остаётся с "return 4" в функции генерации псевдослучайного числа.Необходимо налаживать и поддерживать на качественном уровне процесс непрерывного сопровождения ПО, а не останавливаться на выпусках релизов и аврально затыкать дыры, если что-то произошло.
> Фундаментальное свойство ПО: постоянные изменения и переработка с целью ... Кто этого не понимает, тот надолго остаётся с
> "return 4" в функции генерации псевдослучайного числа.Только вот переработки некоторого современного ПО сродни изменению константы в приведённом вами примере. Вчера было 4, сегодня покоммитили 118, завтра будет 0.
>> Фундаментальное свойство ПО: постоянные изменения и переработка с целью ... Кто этого не понимает, тот надолго остаётся с
>> "return 4" в функции генерации псевдослучайного числа.
> Только вот переработки некоторого современного ПО сродни изменению константы в приведённом вами примере. Вчера было 4, сегодня покоммитили 118, завтра будет 0.И даже ради этого стоит...
В Gentoo, в отличие от большинства других дистрибутивов, можно спокойно смешивать стабильные и нестабильные версии пакетов в одной системе. Нужен тебе новый gcc - размаскируй, пользуйся, пиши багрепорты и реквестируй стабилизацию, всё будет. Это же не дебиан какой, где релиза пять лет ждут.
Ну в дебиан вы тоже можете, хотя и не так просто как в генте.
> В Gentoo, в отличие от большинства других дистрибутивов, можно спокойно смешивать стабильные
> и нестабильные версии пакетов в одной системе. Нужен тебе новый gcc
> - размаскируй, пользуйся, пиши багрепорты и реквестируй стабилизацию, всё будет. Это
> же не дебиан какой, где релиза пять лет ждут.Вы видимо так и не поняли, о чем я говорю. Зачем мне смешивать две разные ветки ПО, именно в Gentoo я могу установить любое нестабильное ПО в любом дистрибутиве. Но не в этом суть, да я могу писать баг репорты для стабилизации ПО, но пока я это буду делать выйдет новая версия ПО а возможно и не одна. Видите ли, в отличие от других дистрибутивов, чтобы работать в Gentoo надо быть, опытным пользователем так было в начале проекта. Теперь же чтобы в Gentoo получить желаемое в нем надо быть не просто опытным пользователем, а желательно сразу программистом. Не сложно это написать баг репорт, для стабилизации ПО, все это можно и нужно, но будет ли от этого польза. Скорее всего, нет, причины: Теряет популярность, сообщество у проекта есть, но оно становится меньше. Где можно использовать Gentoo, десктоп – можно, но надо понимать, что ПО отстает от а значит, все современные функции вы не получите. Да и еще надо понимать и быть готовым к тому, что обновление происходит не всегда гладко. Сервера – можно, но не нужно, опять же не совсем актуальное ПО, проблемы при обновлении на сервере критичнее, чем на десктоп системе. Простой сервера иногда просто недопустим.
Это все сильно сужает потребительский круг. Но, на мой взгляд, Gentoo идеален для исследователя Linux систем. Система минимальная, очень просто проследить, что за что отвечает, и баги есть для повышения исследовательской деятельности.
Сейчас разработчики Gentoo взяли еще форк udev пока его допилят, еще, что нить в голову придет. И так пока проект окончательно не просядет
C учетом 2.193 это самая стабильная linux система. BSD не беру расчет, т.к. не использовал ни в продакшене ни на рабочих станциях. Причем я не программист, что не мешает мне ее использовать во многих инсталяциях, писать багрепорты, общаться с разрабами и закидывать исправления, которые я могу делать. Gentoo ни к чему не обязывает пользователя, из-за чего ламеры начинаю думать, что система должна гарантированно правильно реагировать на любые их хотелки.
> C учетом 2.193 это самая стабильная linux система. BSD не беру
> расчет, т.к. не использовал ни в продакшене ни на рабочих станциях.
> Причем я не программист, что не мешает мне ее использовать во
> многих инсталяциях, писать багрепорты, общаться с разрабами и закидывать исправления,
> которые я могу делать. Gentoo ни к чему не обязывает пользователя,
> из-за чего ламеры начинаю думать, что система должна гарантированно правильно реагировать
> на любые их хотелки.Ни кто и не говорит, что Gentoo к чему то обязывает. Сама идея Gentoo очень хорошая, но актуальность ее ПО отталкивает. Насколько быстро добавляются критические уязвимости по сравнению с другими дистрибутивами, не быстро.
Ни кто не говорит, что разработчики должны воплощать все пожелания пользователей. Но пользователь как конечный потребитель имеет значимость, так же как и разработчик.
Я считаю, что любой проект время от времени требует пересмотра приоритетов, пересмотра направлений в зависимости от изменений потребительского рынка.
Повторюсь, я не считаю проект Gentoo плохим, его некоторые идеи актуальны. Но вот подход к реализации этих идей не всегда актуален
> Насколько быстро добавляются критические уязвимости по сравнению с другими дистрибутивами, не быстро.Мне этому верить на слово или как?
Тебя не устраивает актуально ПО в ~??
>...Теперь же чтобы в Gentoo получить желаемое в нем надо быть не просто опытным пользователем, а желательно сразу программистом...Ты не прав.
Я не являюсь программистом. Я - системный администратор. Максимум - скриптики автоматизации на bash или cmd. Однако Gentoo пользуюсь с огромным удовольствием.
* Нет инсталлятора? Да я уже забыл когда пользовался инсталляторами!
* Нет графических утилит обновления системы? Э-м... Это как в Windows? Спасибо, не надо - совсем не трудно набрать в командной строке "emerge -uD world"
* Трудности с установкой "нестабильных программ"? Ай, бросьте! Я без труда разобрался!
* Неожиданности при обновлениях? Так ведь есть профили "desktop", "server", "developer", "hardended"...
Сознайтесь: вы просто давно не заглядывали в сферу Gentoo.
Всегда было интересно то, как часто в таких обсуждениях мелькает "я" как единое мерило и абсолютный довод. И собственный действия, как единственно верные. А так же то, что людей при этом не смущает тот факт, что остальным, равно как и тем, кому он непосредственно пишет, может быть совершенно наплевать как на это самое "я", так и на его проявления.
Если для того, чтобы пользоваться Gentoo надо быть системным администратором Gentoo - то пусть системные администраторы Gentoo его и используют, странно думать, что остальные тоже являются администраторами Gentoo.
Невозможно досконально разбираться в тонкостях работы каждого инструмента, которым пользуешься. От некоторых хочется, чтобы они работали по принципу just work. И если дистр без пользователя этого делать не умеет, а так же требует сверяться с Google/Gentoo Wiki/Support Forums при выполнении любого незнакомого действия - то его вполне могут счесть именно таким, как откоментировали выше. И вполне заслуженно.
Кажись ChatGPT bot?
правильно, у кого какой гандурас болит, тот то и чешет.это ж пофиг, что любой нормальный сервер после рестарта от 3 до 5 минут проводит в посте, проверке и обнулении памяти, инициализации и загрузке биоса И/О, прежде чем вообще попытается загрузить ОС.
пофиг, что ОС не умеет толком динамически освобождать/получать память, ядра.
зато наш лаптопчег будет грузиццо на 3, 14159268 сек быстрее ААААА!!!11 несомненное преимущество.
цирк.
> пофиг, что ОС не умеет толком динамически освобождать/получать память, ядра.Помнится, учили ещё на SPARC -- а что сейчас не так?
> Разработчики eudev готовы к интеграции поддержки интересных другим дистрибутивам возможностей, за исключением необоснованных предложений (например, желании интегрировать в eudev собственную систему инициализации) и изменений, делающих невозможным обновление существующих систем на новую версию eudev.На что это они намекают?