>потому что это требует дохрена работы по переработке старого кода - который
>вне дерева,
>вместо того что бы писать новый. Эта мысль понятна?"ну вы, блин, даете..." (ц)
к счастью, у девелоперов ядра нет цели поддерживать обратную совместимость с вашим кодом.
Да и странно с вашей стороны хотеть совместимости между разными ветками ядра,
в то самое время когда заявлена возможность любых изменений при таких переходах.
Или они не должны ниче менять, тянуть свой древний и кое-где кривой код, не менять его
лишь потому что у вас там что-то не собереться на новой версии? Товарисч, вы идиот.
Взяли два разных ядра и плачетесь, что нет совместимости в их внутреннем API...
Это практически то же самое, что взять маздай и BSD - и начать вещать, что вот плохо, что у них kernel API разный.
>Требуется изобретение костылей за место убраной их экспорта функции (ну блин васе
>захотелось - он не увидел в дереве не одного используещего эту
>функцию кода).
>Мисье вы хоть раз пытались писать код который работает для любой 2.6
>?
у меня получалсо разный код по мере того, как что-либо менялось связанное с ним.
И неудивительно, ведь API неизменно в 2.6.x ветках, а не во всей 2.6.
Я смотрю, вас не беспокоит общий прогресс. Пусть все будет старое, ниче не нужно исправлять даже во внутренней архитектуре - лишь бы вам не нужно было начинать думать...
Топка по вам плачет...
>Видимо нет
смотри выше.
"зьила с*ка?" (ц) Подеревьянский
>тогда бы задумались о том количестве проверок и костылей
>которые приходится с собой тянуть.
если есть сомнения в моей компетенции - смотрите ChangeLog на 2.6.22.9
и ищите баг, тянущийся с первых .22-rc и аж до .23-rc6
"Fix device address listing for ipv4."
урла на багзилле:
http://bugzilla.kernel.org/show_bug.cgi?id=8876
и внимательно изучайте имя репортера, приславшего фикс.
>мисье сбавте тон, хамство показывает вас с худшей стороны.
мой тон как раз под стать вашему пониманию Линукса
>Было 2.4 vs 2.5 всех все устраивало. Можно было протестировать в -devel
>ветке новые фичи и потом только вливать в стабильную. Ах -devel
>никто не ставит и не протестируешь нормально?.. Но пардон мисье -
>зачем делать из пользователей vanila подопытных кроликов.
Очнитесь, больной... у вас горячка
-devel - это -rcX/-gitX
мало? тестируйте лучше и шлите больше багрепортов на rc ядра.
Ах вы ложили Х на их должное тестирование? Так на кого вы тогда плачитесь?
Как ядро не назови - а с таким отношением в любом "super-mega-stable" будут ошибки.
А новые фичи добавлять нужно - ибо это не бздя, которая скоро мхом покроеццо.
Так что, процесс впорядке.
Разве что -rcX фазу я бы раза в два сделал дольше.
Мир не из одних потребителей ядра состоит, много кто и rc тестит. Им стоит дать больше времени.
>Вот даже Мортон сказал что захлебывается в багах vanila.
ну вот как с вами по-другому разговаривать?? Вещаете, что тон мой плох.
А вы ЧИТАТЬ умеете?
не в багах ваниллы он захлебываеться.
Вот первоисточник, напрягите моск:
http://kerneltrap.org/Linux/2.6.23-rc6-mm1_This_Just_Isnt_Wo...
а вот и суть проблемы, высказанной Мортоном:
"Andrew suggested that the -mm process wasn't working as well as it could"
Он говорит о разработке -mm ветки (!!!). О том, что присылают много некачественных патчей,
которые без долгих фиксов на ваниллу не накладываються!
Собственно, это как раз святая святых новых фич ядра, как раз та -devel ветка, о которой вы плакались.
Так что, возвращаясь к вашим словам, Мортон не в ванильных багах захлебываеться,
а в своих собственных - -mm.
Нафига он принял так много патчей, что ему уже тяжело их обработать??
>Куда уж рядовым пользователям тогда :)
тАварисч, рядовые пользователи жмут кнопочку "update" у себя в [К]Убунте и не жужжжат.
Не надо путать
>Ваш идеал это вечно глючащее ядро которое иногда вдруг начинает работать ?
>тогда вам пожалуй на Windows или на другие OS :)
дык это именно в венде раз в пятилетку меняют ядерное API.
Это как раз ВАМ туда. Вам стабильности API не хватает.
Про глючащее ядро вы сами придумали, значит, вы об этом думаете и допускаете.
Ну точно вам на венду. Там годами не _ремонтируют_ API, оно стабильное, глючное и заброшенное...
