Команда Gentoo Linux планирует совершить форк проекта udev

Да, это правда. Особенно nm и openrc. У них весьма разные возможности, и в очевидных местах openrc просасывает. Ну, и опять же. Имхо net надо вынести из openrc в отдельный самостоятельный поцкет - ему там не место.

Можно каким-нить популярным образом объяснить, как опенрц может просасывать, учитывая то, что в тех случаях где реализация есть только в nm можно просто делегировать всё nm?

Я правильно понимаю, что с помощью nm я смогу легко сделать след элементарную конфигурацию: бридж через eth0 для виртуалок, wlan0, ppp через wlan/br0, he.net через ppp, при этом чтобы в случае подключения eth0 и не включенного ppp у меня бы wifi отключался?

Можно каким-нить популярным образом объяснить, как опенрц может просасывать

Можно. Ключевое различие в отсутствии API в openrc

Я правильно понимаю, что с помощью nm я смогу легко сделать след элементарную конфигурацию

Нет, не правильно

Ключевое различие в отсутствии API в openrc

я ж популярным попросил, я с полуслова не пойму :).. (я ж не флейма ради спрашиваю). Какое именно апи нужно, и если не сложно то пару юзкейсов (ну и как обычно я смогу сравнить только old.net в openrc, т.к. на network я ещё совсем не смотрел).

Нет, не правильно

ясно.

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

Нафлудили 14 страниц по вбросу. А оно только

еще предстоит к рассмотрению специальным советом разработчиков Gentoo Linux

И им ещё надо

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

Гентушники, рано рвать задницы пока.
Да и вообще буря в стакане, имхо.

Где ты там увидел боевой сервер?

_ сервис отваливается_ - вот здесь. Если это не боевой сервер то сервис отваливаться не должен. Это обычное управление изменениями. Если это не боевой сервер то апдейтить и логи смотреть можно не спеша. А если всё на ходу делать и альфа версии всякой дряни ставить - тогда да, тогда жопа в скипидаре, ссш под рукой нет, надо срочно логи через хттп смотреть и прочей ахинеей заниматься.

не в курсе - не пиши. Это уже является гентушным проектом (этот термин требует доп уточнения, так что всем, кто хочет понять в GLEP-036). Проект будет оффициально анонсирован, когда будут выделены short-term задачи, плюс щас идёт общения с другими существующими форками удава. А ещё забавно почитать комментарии Грега, только не делать выводов пока не прочитаешь все.

Если это не боевой сервер то апдейтить и логи смотреть можно не спеша.

А я и не спешу. Но с помощью systemd это делать удобнее.

Тред не читай @ сразу отвечай.

У них же есть mdev, можно же допилить. Или это слишком сложно?

P.S. Как хорошо, что systemd нет и не будет в BSD.

$ eix -c mdev
[N] dev-util/rpmdevtools ((~)8.2): Collection of rpm packaging related utilities
[N] media-plugins/vdr-streamdev (0.5.2): VDR Plugin: Client/Server streaming plugin
Найдено 2 совпадений.

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

mdev далек от udev так-же, как копейка от автомобиля :]

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

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

busybox | grep mdev
        lsattr, lsmod, lsof, lspci, lsusb, lzcat, lzma, lzop, lzopcat, makedevs, man, md5sum, mdev, mesg, microcom, mkdir, mkdosfs, mke2fs, mkfifo,

Таки в наличии.

Вам dia (а точнее аналога Visio) не нужен, кому-то, мне например, нужен... Думаю, что очень многим пользователям нужен - точно так же, как многим и не нужен. Это явно недостаточно веское основание для того, чтобы говорить о том, что в Linux нет дефицита профессионально написанного софта. Dia я привёл лишь в качестве примера той колоссальной пропасти которая существует между Windows (+Mac OS X) и Linux в плане разработки под эти платформы productivity вещей, наличие которых часто является для пользователя решающим аргументом в пользу выбора платформы. И да, говорить о том, что дистрибутив - это ваш инструмент разработки - это... довольно странно. Вы программы пишите в текстовом редакторе или IDE, компилируете и линкуете собственно компилятором и линковщиком. Это есть в любом дистрибутиве, в любом нормальном дистрибутиве легко ставятся и нужные хидеры, и сами инструменты разработки. Что там, простите, пилить-то надо?

Вам dia (а точнее аналога Visio) не нужен, кому-то, мне например, нужен...

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

Dia я привёл лишь в качестве примера той колоссальной пропасти которая существует между Windows (+Mac OS X) и Linux в плане разработки под эти платформы productivity вещей, наличие которых часто является для пользователя решающим аргументом в пользу выбора платформы

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

1). Не надо строить иллюзии, что если будет один дистрибутив, один тулкит и одна ведущая фирма, то разработчики попрут писать «нужный production софт», будет неработающее дерьмо как сейчас, или сообщество уйдёт на более дружелюбную к разработчику ОСь :)

2). написание программ подобного уровня это не дело community и так просто всё не делается, а делается только появлянием крупного игрока совета управляющего созданием, или крупного заказчика.

И да, говорить о том, что дистрибутив - это ваш инструмент разработки - это... довольно странно.

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

Конечно удобней. Тебе выдали костылки со стразами из переделанных страпонов. А ты их пытаешься использовать для выкапывания канавы и рассказываешь как это удобно. Особенно удобно с багами " journalctl and parsing corrupted journals", " journalctl -f stops following new logs unexpectly when new logs are coming too fast" и кучей всего остального приведённого в данном треде. А через системд впихивать имя иконки, заданной в конфиге, в TXT запись в днс - это на 146% повысит удобство.

Особенно удобно с багами

Баги будут исправлены. Это не недостатки, а именно временные ошибки. Не беспокойся, в sysv тоже есть и были баги.

Баги будут исправлены.

Приблизительно такая же песня у фанатов amd-ati и открытых дров: Они вот-вот будут полностью дописаны, осталось еще чуть-чуть!

А ещё забавно почитать комментарии Грега

Где?

Вот только дрова ати пилит ати, и в системд вкладываются почти все дистрибутивы.

На здоровье. Только вот не нужно это навязывать, ок? Я вот консервативен, и не хочу видеть на своих серверах это с бинарными логами и своим httpd.

А кто навязывает? Я в печали потому, что этого даже опционально нету (вернее есть, но недоделано).

Не надо строить иллюзии, что если будет один дистрибутив
написание программ подобного уровня это не дело community

Так вот, если будет один дистрибутив, и этот дистрибутив будет иметь координационный совет по разработке и солидную коммерческую крышу (RedHat или Canonical), то да, можно констатировать тот факт, что «не community» будет делать коммерческий софт под такой дистрибутив, вполне закономерно ставя знак равенства Ubuntu = Linux или RedHat = Linux. А под миллион наколенных любительских поделок, созданных программистами «для своих» в кошмарном программистком бреду - ни один уважающий себя вендор ничего никогда писать не будет. Так же как и редкий пользователь, не являющийся админом или разработчиком, в это болото полезет. И это плохо, потому что с 2003-го года, когда я начал пользоваться Linux как основной системой, ситуация с ПО не только не стала лучше, а местами так даже стала хуже, потому что тогда в 2003-ом многие коммерческие игроки рынка ПО на что-то надеялись, а сейчас им уже просто глубоко нас*ать на Linux, и это вполне закономерно в общем-то.

я поудалял уже эту тему в почте, поэтому явный линк на сообщение не дам, но если не ошибаюсь, то gentoo-dev@g.o тема про результат council meeting (на gmane пока ещё не появилось, там пока только первая часть где он от ryao целей проекта добивается и пишет про проблемы лицензии) писалось вчера поздно вечером.

Писатели серебрянного века и то меньшими идеалистами были :)

никто не мешает RedHat или Canonical или IBM или ВасяПупкин Inc. делать коммерческий софт уже сейчас. Ничто не мешает вендорам писать под RedHat или Canonical уже сейчас; более того они это делают и многие наработки становятся кроссплатформенными хотя раньше были win-only. Но есть подозрение, что мы видим сильно разные участки рынка :)

gentoo-dev@g.o тема про результат council meeting (на gmane пока ещё не появилось, там пока только первая часть где он от ryao целей проекта добивается и пишет про проблемы лицензии

Не это http://article.gmane.org/gmane.linux.gentoo.devel/81263 ?

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

Он как я понимаю пока не есть в генте кастомной фичей, пока все завязано на openrc.

Ничто не мешает вендорам писать под RedHat или Canonical уже сейчас

Не мешает, но этот софт как правило не ориентирован на рядового пользователя. проще говоря, это не софт для рабочей станции, а софт для разработки или для серверных применений. Впрочем, не могу отрицать тот факт, что позитивная тенденция наметилась, и она заключается в том, что коммерческие вендоры уже воспринимают Ubuntu как безальтернативный Linux-десктоп.
Насчёт excherbo - речь кстати была о том, что те, кто тратит силы на его разработку/поддержку могли бы свои таланты применить более полезным образом. И уж во всяком случае не стоит их поддерживать в стремлении клепать 100500-й source-based дистрибутив в то время как это не только не решает никаких проблем, но ещё и создаёт дополнительные, отвлекая ресурсы на малосущественную и маловостребованную работу.

А если они форкнул udev, они еще больше его завяжут на openrc.

Какое именно апи нужно

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

И если не сложно то пару юзкейсов

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

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

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

просто не нужно писать говнософт и он везде будет работать :) щас неговнософта по ряду причин почти нет. В крайнем случае прописать четкие зависимости.

И уж во всяком случае не стоит их поддерживать в стремлении клепать 100500-й souurce-based дистрибутив в то время как это не только не решает никаких проблем, но ещё и создаёт дополнительные, отвлекая ресурсы на малосущественную и маловостребованную работу.

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

Итак, остаётся только аргумент про ресурсы, а их нет! нет никаких дополнительных ресурсов! никто не отвлекается! просто если бы не было exheribo НИКТО из тех кто им занимаются не делал бы то, что хочется ВАМ. Более того если бы не было exheribo, gentoo и остальных дистров, кроме одного избранного, то и большого количества программистов бы вообще не было, как и linux в целом :) И да, пожалуйста, не забывайте про багрепорты и патчи, которые идут из всех дистров в апстрим.

еще больше его завяжут на openrc

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

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

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

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

Я правильно понял, что поверх nm, можно иметь своё кастомное средство конфигурации. Если не сложно, то можно именно юзкейсом, типа: возможность иметь 3rd-party программу, в которой можно сделать <то, что можно сделать>

Как метаинформацию для контроля поведения системы в различных сетевых окружениях.

юзкейс, а не абстракцию можно?

Вариант анонимуса, с возможностью сделать простой widget принимается, с помощью чистого openrc это сделать нельзя, by design. Решение от openrc вместе с net включать сервис вида ifplugd с dbus интерфейсом, предоставляющий информацию об изменении состояния сети по поддерживаемым интефейсам (filesystem/socket/dbus), или если нужна и возможность изменения конфигурации, то предоставлять управление сетью юзерскому сервису такому как nm или wicd.

что значит «ещё больше»? eudev не завязан на openrc, а openrc это drop-in-replacement sysv-init не имеющий зависимостей кроме kernel-specific фигни и POSIX sh.

..многие коммерческие игроки рынка ПО на что-то надеялись, а сейчас им уже просто глубоко нас*ать на Linux ..

Расскажите это Valve

он просто никак не может быть заменой udev-у в общем случае.

В общем случае да, но тем не менее, может быть его допилить дешевле, чем с корнем вырывать udev из systemd для того, чтобы сделать fork.

нет, точно не проще, более того автор mdev этого не хочет.

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

Это будет в архиве на gmane или еще каком-то открытом архиве?

насколько я понимаю должно в gmane появиться в течении дня.

баги висят месяцами. баги типа «shotdown deadlok» или «wrong dev enumeration» всплывают по разными id снова и снова (их не переоктрывают а создают новые что б замаскировать проблемы). так что.. systemd+journald это типичная альфа. без тестов. без нормальных доков и с непрерывным изменением кода..

я идиот, и попутал комментарий рича фримена с грегом, стыд мне и позор.

НИКТО из тех кто им занимаются не делал бы то, что хочется ВАМ

Ну мне и не нужно, чтобы они тот же Visio клепали, я переживу. Тем не менее, с высокой долей вероятности они бы писали софт в это время, а не занимались дистроваянием. А любой софт, хотя для удалённого прожигания цисок насквозь гневом Господним - то куда лучше, чем его отсутствие. Только не говорите мне, что без exherbo они бы по коммерческим палаткам разбрелись, это как минимум безосновательно.

/etc/init.d/сервис start
* start failed
cat /var/log/messages | tail
в чем трабла?

tail /var/log/messages

qnikst, я гляжу ты openrc специалист, можешь помочь мне?

У меня три сетевых интерфейса eth0, wlan0, usb0. Заметил, что если я сижу на usb0/wlan0 и запускаю сервис, зависящий от net, он начинает поднимать net.eth0, пока решаю это тем, что удаляю у такого сервиса net из зависимостей, но это какое-то кривое решение... Есть ли кошерный способ?

Ну например. Прихожу я в некое место A, включаю ноут, подключаюсь к вайфаю. Приложение загребает инфу о точке доступа из NM, делает дубликат и прицельно сбивает с оригинала с наведением по кисмету клиентов^W^W^W^W^W^W^W^W^W^W^W^W^WПростейший вопрос - к какой сети я сейчас подключен по эзернету. Нужно для автоматического монтирования соответсвующих шар

qnikst, я гляжу ты openrc специалист,

я не волшебник, я только учусь =)

зависит как depend или use? Сейчас в openrc пересмотрели логику работы need net и практически всем сервисам нужен use net, а если нужен конкретный интерфейс, то rc_service_need=«net.xxx» надо. Более менее разные случаи и решения рассмотрены у Диего.

[1] http://blog.flameeyes.eu/2012/10/may-i-have-a-network-connection-please

для приложения с дубликатом, хватит iwconfig (где он там живёт) сможешь копии снимать даже не подключаясь. По второму пункту, как nm определяет в какой сети ты подключен по ethernet? по маку dhcp, или как?