LINUX.ORG.RU

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

 , , ,


3

5

Как сообщается в листе рассылки Linux-дистрибутива Gentoo, его команда разработчиков приняла решение совершить форк проекта udev и тем самым стабилизировать его развитие. В сообщении Ричарда Яо (Richard Yao) говорится:

Всем привет!

Ни для кого из нас не секрет, что текущее направление развития udev под руководством новой команды, выпустившей systemd, крайне безрадостное. Линус Торвальдс «очень подозрительно отнесся к тому факту, что поддержка udev перешла в какой-то сумасшедший режим, вносит изменения, создающие всем проблемы, и полна явного и всепоглощающего идиотизма».

Я поговорил с некоторыми разработчиками в Gentoo, и все мы разделяем озабоченность Линуса. Я принял решение собрать команду и форкнуть udev. Помимо всего прочего, мы хотим убрать ограничение отдельного раздела для /usr. Официальное объявление будет сделано немного позднее на этой неделе.

Высказанное решение еще предстоит к рассмотрению специальным советом разработчиков Gentoo Linux, заседание которого организаторы проекта просят перенести на декабрь, чтобы лучше подготовиться и все обдумать.

>>> Подробности

★★★★★

Проверено: tazhate ()

Ответ на: комментарий от qnikst

хватит iwconfig

iwconfig не хватит, т.к. нужна еще как минимум конфигуарция DHCP, DNS итп

как nm определяет в какой сети ты подключен по ethernet

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

vasily_pupkin ★★★★★ ()

Желаю проекту удачи. Хотя если демоны начнут переписывать под systemd закончится всё равно переходом на него (

FreeLiver ★★★ ()
Ответ на: комментарий от FreeLiver

демоны начнут переписывать под systemd

Это как?

Binary ★★★★★ ()
Ответ на: комментарий от FreeLiver

Хотя если демоны начнут переписывать

Кто? 1.5 гентушника?

anonymous ()
Ответ на: комментарий от ssnley

Извини, что работает десятилетиями? Ты новость-то читал? Форкают, чтобы _стабилизировать_. Для тебя поясняю, пытаются приостановить развитие в ту сторону, куда оно покатилось в последнее время. Т.е. как раз чтобы закрепить то, что «работает десятилетиями».

winlook38 ★★ ()
Ответ на: Разработчики udev о форках от redgremlin

Re: Разработчики udev о форках

«Разработчики udev о форках

http://www.opennet.ru/opennews/art.shtml?num=35374

«Эта лодка перевернется раньше, чем они научатся плавать» — констатирует Сайверс» кто б ожидал честных и вменяемых комментов от поттеро-прокалдок

anonymous ()
Ответ на: Re: Разработчики udev о форках от anonymous

«Разработчики udev о форках

пипец - мы уж радовались и надеялись что all-good ;(

„hate-driven development“ - силища, пока хватит ненависти!

Паниковать рано, но призадуматься еще раз не помешает...хотя все к лучшему

Спасибо анонимусу за ссылку.

swwwfactory ★★ ()
Ответ на: Re: Разработчики udev о форках от anonymous

Несколько месяцев назад, Грег уже отмечал странное поведение отдельных разработчиков Gentoo, стремящихся убедить всех, что никакой проблемы с /usr нет. Комментируя подход к изменению логики работы с /usr разработчиков Gentoo и Debian, Грег заметил «У меня сложилось впечатление, что эти люди неправильно понимают, что на самом деле происходит, и почему». При этом он настойчиво рекомендовал использовать более продуманные дистрибутивы, такие как Fedora, Ubuntu и openSUSE.

Ололо такое ололо.

leg0las ★★★★★ ()

Лучше б делали альтернативу udev, а не форкали его...

trupiko ()
Ответ на: комментарий от vurdalak

может Роббинс для фанты запилит. Он вроде более адекватный разработчик.

он самый главный systemd хейтер

anonymous ()
Ответ на: комментарий от vurdalak

В фанте (видимо что бы не связываться с Леонардо) вместо udev установили mdev. Так что адекватность Роббинса (по вашим меркам, конечно) весьма сомнительна. ....И лично меня это несказанно радует!))))

k0valenk0_igor ★★★ ()
Ответ на: комментарий от k0valenk0_igor

вот так и распространяется дезинформация. Еще не перевели, но сделаем :) Вы не совсем поняли идею с mdev

angry_vincent ()
Ответ на: комментарий от anonymous

Это очень хорошо что пользователи рапортуют ошибки, а разработчики их по мере сил устраняют :)

Lennart ()


Kay, you are so full of sh*t that it's not funny. You're refusing to
acknowledge your bugs, you refuse to fix them even when a patch is
sent to you, and then you make excuses for the fact that we have to
work around *your* bugs, and say that we should have done so from the
very beginning.

Yes, doing it in the kernel is «more robust». But don't play games,
and stop the lying. It's more robust because we have maintainers that
care, and because we know that regressions are not something we can
play fast and loose with. If something breaks, and we don't know what
the right fix for that breakage is, we *revert* the thing that broke.

So yes, we're clearly better off doing it in the kernel.

Not because firmware loading cannot be done in user space. But simply
because udev maintenance since Greg gave it up has gone downhill.

Linus


я правильно понимаю, что удев пойдет лесом? :)

metawishmaster ★★★★ ()
Ответ на: комментарий от lucentcode

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

(мечтательно) А вдруг все арчеводы, недовольные systemd, дружно перейдут на генту и помогут с поддержкой? А если к ним ещё и убунтовцы подтянутся... Ядро линукса тоже с одного человека начиналось. В общем, шансы есть, было бы желание.

anonymous ()
Ответ на: комментарий от vurdalak

Trinity и mate уже показали, что происходит с такими форками.

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

anonymous ()
Ответ на: комментарий от chinarulezzz

юзал кеды с 3.4 ветки. Работал с 128Мб оперативки

Путаешь с kde2, которые занимали 90МБ, либо просто нагло... хм... лукавишь. Либо забыл упомянуть, насколько оно свопилось. У меня сейчас kde3 ~200МБ занимают.

и выполнял все функции что сейчас выполняет amd64-dualcore с 2гб оперативки.

Это говорит только о том, что ты не пользуешься большей частью возможностей кед. Попробуй в третьих кедах положить на десктоп RSS-читалку. Попробуй разместить там несколько иконок под разными углами, просто так, для веселья. Попробуй в панели задач сгруппировать или разгруппировать окна (средний клик в kde4). Попробуй сделать в KDE3 несколько панелей, например, таскбар+систрей+часы внизу, и всплывающая панель с иконками программ слева. Попробуй в двухмониторной системе сделать в KDE3 раздельные таскбары на разных мониторах, чтобы в каждом таскбаре отображались только окна с этого монитора...

Это была только плазма. Попробуй сделать отображение праздников в календаре KDE3 или поиск программы в меню. В kde4 скриншот выкладывается в два клика — PrintScreen и картинка из открытого ksnapshot-а перетаскивается на виджет pastebin, попробуй сделать это в kde3. Попробуй добавить такой же легкодоступный калькулятор со строкой ввода формулы, который из коробки есть в KDE4 по Alt+F2. Встроенный композитинг с эффектами, семантический поиск или возможность посмотреть/послушать файл прямо в dolphin-е не открывая плеер — не обязательные, но иногда приятные мелочи.

Это только то, что навскидку пришло в голову.

anonymous ()
Ответ на: комментарий от lucentcode

Постоянное бэкпортирование

А оно и не требуется. Достаточно того, что есть + не ломать совместимость с софтом.

devl547 ★★★★★ ()
Ответ на: комментарий от anonymous

Попробуй в третьих кедах положить на десктоп RSS-читалку. Попробуй разместить там несколько иконок под разными углами, просто так, для веселья. Попробуй в панели задач сгруппировать или разгруппировать окна (средний клик в kde4). Попробуй сделать в KDE3 несколько панелей, например, таскбар+систрей+часы внизу, и всплывающая панель с иконками программ слева.

Прям тред на винфаке какой-то.

devl547 ★★★★★ ()
Ответ на: комментарий от anonymous

я вот тоже не понимаю в чем беда systemd. хоть кто-ндь во всея рунете объяснит?

Легко.

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

Systemd добавляет кучу новых проблем. Инициализация системы работала десятилетиями. Но пришёл системд, и проблемы, которые были решены 20 лет назад, вылезают снова.

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

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

Итого, systemd — это диверсионная имитация деятельности, которая рекламой и обманом завоёвывает популярность, а затем дестабилизирует систему. Переход на systemd отнимает время многих людей и вызывает только проблемы.

anonymous ()
Ответ на: комментарий от st4l1k

Может любители systemd расскажут в чем профит по сравнению с openrc.

Примерно в том же, в чём и профит Malbolge. Профит systemd: +1000 очков к ЧСВ и возможность троллить неосиляторов на лоре.

anonymous ()
Ответ на: комментарий от devl547

Прям тред на винфаке какой-то.

Человек делает вид, словно в KDE4 не появилось ничего нового по сравнению с KDE3, вот, приходится заниматься просвещением...

anonymous ()
Ответ на: комментарий от anonymous

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

devl547 ★★★★★ ()
Ответ на: комментарий от anonymous

Прям захотелось попробовать. Такую фанатичную ненавись может вызвать только что-то действительно достойное. Как линукс у виндузятников.

//или скорее как windows и линуксоидов.

winlook38 ★★ ()
Ответ на: комментарий от winlook38

«Not because firmware loading cannot be done in user space» на самом деле это ключевой момент. всетаки линус при всем к нему уважении как к менеджеру как архитектор - недоучка. банально недоучился. раз такие косяки до сих пор в ядре

anonymous ()
Ответ на: комментарий от anonymous

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

1-ый вопрос в пятый класс, а второй в Development %)

metawishmaster ★★★★ ()
Ответ на: комментарий от leg0las

или поддержит, или отойдет от идеи того, что читать конфигаруационные файлы из ядра - плохая идея

metawishmaster ★★★★ ()
Ответ на: комментарий от anonymous

дружно перейдут на генту и помогут с поддержкой?

поддержка им просто отчаянно необходима - а то вдруг не справятся с переписывание копирайтов на чужой код, да и постоянное то удаление, то добавление зависимости от kmod это архисложная задача... :-D

А уж бессмысленная возня вокруг отдельного /usr это просто смешно: то, что когда-то началось с покупки двумя бородатыми чуваками нового жёсткого диска превратилось в священную корову тех, кто даже не пытается понять что и зачем нужно в FHS:

http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

Lennart ()
Ответ на: комментарий от Lennart

А уж бессмысленная возня вокруг отдельного /usr это просто смешно:...

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

Причем, чем больше размер FS, тем больше на ней потеряешь.

sergv ()
Ответ на: комментарий от sergv

Причем, чем больше размер FS, тем больше на ней потеряешь.

Даже если по какой-то загадочной причине не делается бэкап данных, которые жалко потерять, то я всё-равно не представляю что такого ценного может быть на разделе /usr - всё стоящее как правило находится либо в /home, либо в /etc.

Для первого существуют бэкапы, для второго etckeeper.

Lennart ()
Ответ на: комментарий от Lennart

что такого ценного может быть на разделе /usr

Не о том речь. Ценна целостность небольшого / для загрузки.

sergv ()
Ответ на: комментарий от sergv

Ценна целостность небольшого / для загрузки.

С повреждённым из-за аппаратого сбоя /usr?! И чего ты после такой загрузки делать собрался?

Lennart ()
Ответ на: комментарий от Lennart

С повреждённым из-за аппаратого сбоя /usr?! И чего ты после такой загрузки делать собрался?

Хомяк и журналы с конфигами спасать.

sergv ()
Ответ на: комментарий от metawishmaster

«нельзя» из ядра читать файлы.

Кстати, для случая загрузки firmware лично Линус сделал исключение.

tailgunner ★★★★★ ()
Ответ на: комментарий от winlook38

Прям захотелось попробовать.

Хочется лично пожевать кактус? Пожалуйста, systemd сейчас есть почти в любом дистрибутиве.

Такую фанатичную ненавись может вызвать только что-то действительно достойное.

Это не фанатичная ненависть, это — опыт.

anonymous ()
Ответ на: комментарий от Lennart

«Lennart

Это очень хорошо что пользователи рапортуют ошибки, а разработчики их по мере сил устраняют :)» разработчики ошибок не устроняют. они заняты qrкодами и впихиванием нового api. сколько багов закрыто в 196 релизе?

anonymous ()
Ответ на: комментарий от sergv

В initramfs его запихай, и то больше шансов, что выживет.

Gorthauer ★★★★★ ()
Ответ на: комментарий от Gorthauer

В initramfs его запихай, и то больше шансов, что выживет.

Ежели образ initramfs будет на большой фалухе с rw при буте, то шансов меньше.

sergv ()
Ответ на: комментарий от sergv

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

Gorthauer ★★★★★ ()
Ответ на: комментарий от Gorthauer

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

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

sergv ()
Ответ на: комментарий от anonymous

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

Тем не менее ошибки активно исправляются, багов исправлено - множество.

Lennart ()
Ответ на: комментарий от Lennart

Тем не менее ошибки активно исправляются, багов исправлено - множество.

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

anonymous ()
Ответ на: комментарий от KRoN73

Это ссылка на стабилизацию пакета под левые арх-ры.

Ъ-лоровец вангует ссылку не заходя по ней.

По ссылке:

...
So please keyword the[m] on ppc* and alpha

Перевести?

В комменты maintainer ни в жисть не посмотрит.

Угу. А открытые тикеты на багзилле — это так, для красоты.

[once again] Тикет про KEYWORDREQ. Эти комментарии читают только arch testers. И то, что я там вижу никаким боком не касается стабилизации на маргинальщине.

Ваши комменты там только помешали.

sf ★★ ()
Ответ на: комментарий от sergv

С тоской вспоминая время, когда этот костыль еще небыл общеупотребимым и lilo вполне себе справлялся с загрузкой ядра..

Лило и так справляется с загрузкой ядра. А общеупотребимость - обратная сторона распространённости... Приходят новые программисты, пишут так, как им вздумается, с тем что им кажется правильным. И есть дистрибутивы которые либо подбирают эту линию как основную, либо поддерживают больший выбор, либо стараются придерживаться того, к чему привыкли ранее, что им кажется лучше. И очень важно поддерживать те программы, которые соответствуют классу «KISS», либо архитектурно более правильны, так как этим мы не даём им сгинуть в общей массе разного рода программ и программистов. Нужно показывать что такие программы важны, такие программы нужны, и не стоит всем программистам думать одинаково и терять из виду прекрасную традицию UNIX'a.

chinarulezzz ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.