Представлены очередные корректирующие релизы ядра Linux (http://www.kernel.org/): 3.0.9 (https://lkml.org/lkml/2011/11/11/253) (264 исправления (http://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.0.9)) и 3.1.1 (https://lkml.org/lkml/2011/11/11/255) (268 исправлений (http://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.1.1)). Как обычно, в анонсе выхода новых версий подчеркивается обязательность проведения обновления. Из подсистем в которых исправлены ошибки можно упомянуть: USB, usb_storage, mac80211, ath9k, Suspend, epoll, ACPI, VFS, CIFS, ext4, ext2, ext3, NFS, md/raid5, iscsi-target, drm/radeon, ALSA, ipv4, ipv6, KVM, Xen.
Отдельно можно отметить исправление ошибок в реализации программного RAID. В md/raid10 устранена серьёзная ошибка, которая могла привести к повреждению данных: при наличии активного запасного диска (hot-spare) в случае деградации массива, запасной диск не добавлялся в пустой слот, а заменял собой первый рабочий диск. В реализации md/raid5 устранена ...URL: https://lkml.org/lkml/2011/11/11/255
Новость: http://www.opennet.ru/opennews/art.shtml?num=32288
> Отдельно можно отметить исправление ошибок в реализации программного RAID.Ждём бэкпортов в 2.6.32. Такое нельзя оставлять неисправленным.
в 2.6.35
Учимся читать:
-->8--
md/raid5: fix bug that could result in reads from a failed device.
This bug was introduced in 415e72d034c50520ddb7ff79e7d1792c1306f0c9
which was in 2.6.36.
-->8---->8--
md/raid10: Fix bug when activating a hot-spare.This is a fairly serious bug in RAID10.
This bug was introduced in commit
2bb77736ae5dca0a189829fbb7379d43364a9dac
which first appeared in 3.1.
-->8--Бекпорта _чего_ Вы хотите в 2.6.32 - ошибок? Чтобы потом их исправить, ага...
Спасибо, добрый человек, успокоил.
В md/raid10 устранена серьёзная ошибка - а я думал это у мну руки кривые и меня вообще глючит O_O
Даже в процессорах бывают ошибки.
"Даже"... "И на Солнце бывают пятна" (С)
Хм, ну по оси абсции у нас не время, а всего лишь нумерация версий ядер, что ИМХО не является адекватной системой отсчета для этой ситуации. Т.к., даже вот недавно, Линус сменил нумерацию для удобности, а не из-за каких-то технических соображений, что-ли...Да и взять, да и посмотреть на даты выпуска, скажем, ядер 2.0 и 2.2 (1996 и 1999 года) и ядер 2.6 и 3.0 (2003 и 2011 года), то ясно, что это не одинаковые отрезки времени...
Рост то есть, однозначно, но во времени он вряд-ли будет "настолько экспоненциальный"...
> Рост то есть, однозначно, но во времени он вряд-ли будет "настолько экспоненциальный"...Драйвера. Оборудования нового появляется достаточно много. Под него нужны дрова.
>> Рост то есть, однозначно, но во времени он вряд-ли будет "настолько экспоненциальный"...
> Драйвера. Оборудования нового появляется достаточно много. Под него нужны дрова.В монолитном ядре на платформе PC это означает писец и гигабайтные размеры ядер. Если не прийти к динамической загрузке модулей.
> Если не прийти к динамической загрузке модулей.Крепко вас "заморозило". Качественно.
> Если не прийти к динамической загрузке модулей.А вы из какой криокамеры? А то у линукса загрузка модулей именно динамическая. Я даже уже не помню сколько лет оно так. Видимо, хладагент в вашей криокамере был забористый.
Драйвер_ы_, а не драйвер_а_. Аноним! Будь грамотен!
> Хм, ну по оси абсции у нас не время, а всего лишь нумерация версий ядер, что ИМХО
> не является адекватной системой отсчета для этой ситуации.Какая ситуация? В новости нет ни слова про время!
> Да и взять, да и посмотреть на даты выпуска, скажем, ядер 2.0 и 2.2 (1996 и 1999 года)
> и ядер 2.6 и 3.0 (2003 и 2011 года), то ясно, что это не одинаковые отрезки времени...Нехера не ясно, ясно то, что было "... исследование проведённое на основе оценки изменения размера 297 релизов..."
> Рост то есть, однозначно, но во времени он вряд-ли будет "настолько экспоненциальный"...
Нет там время...
---
v1.0 ~= 1 Мб -> x = exp(1*10^6), x ~= 14
v3.1 ~= 74 Мб -> x = exp(74*10^6), x ~= 1919 - 15 = 5
8 релизов с 1991 года, отседа коэф прироста тушки == 8/5 или 1.6
То есть, следующая версия на 1.6 больше предыдущей.
---
Решая ур-ние: exp(x*10^6) = 20, получим размер ядра 4.0 равный 300 Мегам :)
метрика не привязанная ко времени, а к номерам релизов, говорит о психологии определяющего релиз, а не о развитии ядра, поэтому не нужна.
> метрика не привязанная ко времени, а к номерам релизов,В последнее время релизы вроде более-менее стабильно по времени выпускают.
в графике к новости НЕ последнее время занимает большую часть
> 19 - 15 = 5Да, в 8 утра математика на высоте :D
> Да, в 8 утра математика на высоте :DВ военное время значение синуса может достигать двух!
Что-то я не сильно пойму, где вот у Вас получились такие цифры.
exp(1000000) = 3.03321539680209e+434294. Разве не так?Все-равно как бы там ни было, я же написал, что мое имхо говорит : ) , что нету смысла приводить вот такие графики. Вот если бы это относилось Ubuntu - другое дело - один и тот же интервал межу релизами.
//Да, а математика в 8 утра получилась интересная у Вас. : ))
> Что-то я не сильно пойму, где вот у Вас получились такие цифры.
> exp(1000000) = 3.03321539680209e+434294. Разве не так?Пля.... :) логарифм конечно же...
e^x = 1000000
x = ln(1000000)
x ~= 13.82
Ну так получается exp(13.82) = 1004499.5, это да.А Вы тогда написали exp(1*10^6). Это же разные вещи то. Что я не понимаю?..
Конечно, если у Вас ещё есть охота к этому. : )
Ну а чего не понятного...Если принять первый релиз за нулевую точку, то примерный размер
можно узнать через функцию: S = exp(14 + k), где k = 0, 1, 2, 3, 4, 5
---Ладно, фигня всё это. Для любых известных чисел всегда можно найти некую закономерность,
даже для абсолютно случайных, - для них это называется закон распределения.Более того, из всяких статей по вирусологии можно узнать, что рост некой
ограниченной популяции бактерий, вирусов подчиняется именно экспоненте,
например плесень на куске хлеба.Пугает другое, что при таком законе, предел насыщения наступает быстро.
А результатом этого предела могут стать, экспоненциальный рост ошибок,
сложность адаптаций все популяций в новой среде обитания, вполне допустимо,
что она там вообще не сможет жить. К примеру, на RealTime устройства,
в последние пять лет, Linux запихнуть все сложнее и сложнее. Лично знаю
три конторы, которые ушли в сторону RTEMS и uCOS.
Некое подобие творится и на деcктопах. Раньше надо было многое доставлять,
доделывать, сейчас проблема в том, чтоб выкинуть все лишнее и оно продолжало
работать, живой пример KDE.
Похожее на серверах - после установки надо делать полный аудит, того что же
у нас там наставилось. То SUID программка выскочит, то NFS на почтовом серваке
подефолту включён, AVAHI какой-то крутиться, /usr/include/* зачем-то... :)
Уважаемый pavlinux, Вы уже пошли в философию. :)
Это развитие. Если во времена Minix-а было мало людей, понимающих что такое Minix, то следовательно - мало мнений, мало путей развития.Сейчас же ситуация поменялась - много заинтересованных людей, много мнений - следовательно много пишется кода, комбайн Opera тому пример. Не спорю - Opera прекрасная програма, но не все разделяют такую философию, предпочтя FF+TB+Xchat+Licq (etc)...
Да, есть менеджеры по разработке и прочие должности у крупных продуктов, но почему программы/окружения стали такие - IMHO причина в мною вышесказанном.
> Хм, ну по оси абсцииПо какой оси?!
http://ru.wikipedia.org/wiki/Абсцисса
Ой, ну опечатался малек - да, нужно "оси абсцисс".
Работу intel HDA с кодеками от VIA исправили?
В какую новость не заглянешь, везде обновлён ext4, эта фс до такой степени баганая что уже несколько лет пилят её?
Нет, просто в любом ПО есть что улучшать и оптимизировать.
> В какую новость не заглянешь, везде обновлён ext4, эта фс до такой степени баганая что уже несколько лет пилят её?Что вы к ext4 прицепились? В том же ряду упоминался IPv4 - про него аналогичное брюзжание выглядело бы куда интереснее.
> В какую новость не заглянешь, везде обновлён ext4, эта фс до такой
> степени баганая что уже несколько лет пилят её?Вроде серьезные баги там уже поудавили. Живет себе. Работает. Уже несколько лет. Это не значит что там нет более мелких багов и что улучшать уже нечего. Как известно, нет предела совершенству.
> А сколько лет в твоей фряхе не замечали эскалацию прав с лузера до рута через PAM?Вопрос не ко мне. Я не использую PAM и отключаю использование PAM в ПО, так как давно полагаю опасную дыру в этой подсистеме.
> Кстати авторы либы PAM свой фэйл уже узрели, а вот фряшники судя по всему так и не поняли что в их системе кое-что не так.
PAM — это не изобретение фряшников, а сторонняя подсистема от Sun Microsystems, Inc. (мир её праху), интегрированная сначала в Red Hat Linux, а уже потом появившаяся в свободных Unix'ах.
> По крайней мере исправлений до сих пор нет AFAIK. Так и живете с _известной_ эскалацией прав.
Нету у меня ничего завязанного на PAM. Без этого и живу много лет.
Не городите тут чушь! Уязвимость OpenPAM обсуждается в другой теме.
> Вопрос не ко мне. Я не использую PAM и отключаю использование PAMМожет тогда еще и электричество отключишь заодно? Ну его нафиг этот прогресс - всякие там короткие замыкания же, etc :)
>> Вопрос не ко мне. Я не использую PAM и отключаю использование PAM
> Может тогда еще и электричество отключишь заодно?Может и отключу, когда его к нам пустят по оголённым проводам. А что, экономия на изоляции и материалах — важнейший тренд в современной политике удешевления разработок. А я такие "разработки" в гробу видел.
> Ну его нафиг этот прогресс - всякие там короткие замыкания же, etc :)
Если вместо кроссплатформенных HAL/PolicyKit ВНЕЗАПНО для всех Unix оставят только линуксовые UDev/UPower/UDisks/KMS/GEM с, естественно, non-stable API, и вертитесь как хотите, то ничего не останется делать, как послать такой "прогресс" к чертям собачьим.
>Может и отлючу, когда его к нам пустят по оголённым проводам.Отключай быстрей! Не поверишь, но до подстанции твоего города/посёлка/района электричество подаётся по воздушным линиям с оголёнными проводами.
> Может и отключу, когда его к нам пустят по оголённым проводам. А
> что, экономия на изоляции и материалах — важнейший тренд в современной
> политике удешевления разработок.Ты не поверишь, высоковольтки все как одна без изоляции. А ты попробуй соорудить изоляцию для лэп-500, которая вообще 500 киловольт выдержит. Поймешь в чем прикол. Как раз в плане (не)экономии на изоляции и материалах.
> А я такие "разработки" в гробу видел.
Срочно отказывайся от электричества - см. выше.
>> Ну его нафиг этот прогресс - всякие там короткие замыкания же, etc :)
> Если вместо кроссплатформенных HAL/PolicyKit ВНЕЗАПНО для всех Unix оставят только
> линуксовые UDev/UPower/UDisks/KMS/GEM с, естественно, non-stable API, и вертитесь
> как хотите, то ничего не останется делать, как послать такой "прогресс" к чертям собачьим.Посылай, твое право. Кстати а разве не такие как ты обсирали HAL за то что он типа "линукс-ориентированный"? Смешной у тебя критерий линукс-ориентированности - "если что-то не реализовано в моей системе - виноват линукс!"
>> Может и отключу, когда его к нам пустят по оголённым проводам. А
>> что, экономия на изоляции и материалах — важнейший тренд в современной
>> политике удешевления разработок.
> Ты не поверишь, высоковольтки все как одна без изоляции. А ты попробуй
> соорудить изоляцию для лэп-500, которая вообще 500 киловольт выдержит. Поймешь в
> чем прикол. Как раз в плане (не)экономии на изоляции и материалах.Не надо быть дураком, чтобы не видеть разницы между воздушными линиями электропередач для подстанций и внутридомовой электропроводкой для конечных потребителей.
>> соорудить изоляцию для лэп-500, которая вообще 500 киловольт выдержит. Поймешь в
>> чем прикол. Как раз в плане (не)экономии на изоляции и материалах.
> Не надо быть дураком, чтобы не видеть разницы между воздушными линиями электропередач
> для подстанций и внутридомовой электропроводкой для конечных потребителей.Надо быть iZEN'ом чтобы сперва влопаться в свои же формулировки, а потом от них отчищаться.
Кстати если уж на то пошло, было время - экономили на проводах, прокладывая галимый алюминий. Хотя конечно же те кому не пофигу что у него и как - не жлобятся на медные провода. Кстати нынче такая же тенденция с витой парой - нынче в моде "омедненный алюминий". Так что предлагаю тебе проверить состав проводов в твоей хате и при нахождении удешевленного люминя уйти в монастырь. Ну и эзернет наверное тоже использовать не стоит, раз такая подляна с удешевлением. А то вдруг тебе удешевленную витуху подсунут? :)
>Судя по всему рост размера носит экспоненциальный характер и если применить экстраполяцию,то к версии 4.0 размер уйдет в бесконечность. И либо на радость проприетарщиков линукс раздавит сам себя, либо на радость таненбауму поменяет архитектуру.
может быть тогда до разработчиков дойдет - что имеет смысл держать стабильным API для драйверов - что бы можно было держать архив драйверов отдельно, все остальное отдельно.
А сейчас львиная доля исправлений это перепиливание дров под каждый чих с измнением API
> может быть тогда до разработчиков дойдет - что имеет смысл держать стабильным API для драйверовСтабильное API - это прекращение всякого развития, это смерть ядра.
>>может быть тогда до разработчиков дойдет - что имеет смысл держать стабильным API для драйверов - что бы можно было держать архив драйверов отдельно, все остальное отдельно.А сейчас львиная доля исправлений это перепиливание дров под каждый чих с измнением API
>Стабильное API - это прекращение всякого развития, это смерть ядра.
Вы прочли что вам написали? Поняли? Стабильное API это не прекращение всякого развития - это лишь стабильное API. И уж точно это никак не смерть ядра. ИМХО, стабильное API - это не самое лучшее решение для открытого софта, такое решени сойдет только закрытому софту сделанному ради бабла.
и хоть одну систему с развитием и стабильным апи можете назвать? Из тех что я помню - только ОС/2, там действительно на последних версиях работали драйвера от версии 2. Вот только развитие там совсем скисло. У винды же - что не версия, то новые драйвера. Причем очень часто для старых устройств драйверов просто нет - я знаю контору где до сих пор работает плоттер на НТ4 только потому, что фирма-производитель давно померла и новых драйверов для устройства нет и не будет.
*BSD - в рамках релиза стабильный API, между релизами серьезные поломки.
Win32* - ..Да и теже Linux, что самое то смешное.
RedHat Linux 3,4,5,6 - в пределах релиза не смотря на серьезные перепиливания - сохраняют API и ABI для дров.
Linux на ядрах до 2.6 делился на стабильную ветку - с достаточно стабильным API - и нестабильную 2.x+1 где отрабатывалось новое.Была смерть ?
Может быть просто текущая ситуация выгодна тем кто имеет акции RedHat вынуждая покупать у них платную поддержку. А вы как попугай повторяете маркитоидный бред и поддерживаете рублем акции RedHat.
>[оверквотинг удален]
> Win32* - ..
> Да и теже Linux, что самое то смешное.
> RedHat Linux 3,4,5,6 - в пределах релиза не смотря на серьезные перепиливания
> - сохраняют API и ABI для дров.
> Linux на ядрах до 2.6 делился на стабильную ветку - с достаточно
> стабильным API - и нестабильную 2.x+1 где отрабатывалось новое.
> Была смерть ?
> Может быть просто текущая ситуация выгодна тем кто имеет акции RedHat вынуждая
> покупать у них платную поддержку. А вы как попугай повторяете маркитоидный
> бред и поддерживаете рублем акции RedHat.Слушай, чувак. Это капитализм, детка. Деньги есть всеобщий эквивалент. А не желание прогресса или движения к светлому будущему.
> *BSD - в рамках релиза стабильный API, между релизами серьезные поломки.
> Win32* - ..В рамках релиза нет развития. Что полностью подтверждает утверждение тредстартера.
> Да и теже Linux, что самое то смешное.
> RedHat Linux 3,4,5,6 - в пределах релиза не смотря на серьезные перепиливания
> - сохраняют API и ABI для дров.Нет там в пределах релиза "серьезных перепиливаний". Наоборот трясутся над тем чтобы аби не сломалось, как в юзерспейсе так и в ядре. Часть кода с кучей усилий бекпортится на старые ядра, но обычно - крайне малая часть от изменений.
> Была смерть ?
> Может быть просто текущая ситуация выгодна тем кто имеет акции RedHat вынуждая
> покупать у них платную поддержку. А вы как попугай повторяете маркитоидный
> бред и поддерживаете рублем акции RedHat.Дадада. Редхат правит миром через 20 цадиков в Польше и кушает детей по утрам. Еще редхат вечно ломает апи в виндоусе, бсд и макоси. А все ведутся, чувак, прикинь?
> *BSD - в рамках релиза стабильный API, между релизами серьезные поломки.
> Да и теже Linux, что самое то смешное.
> RedHat Linux 3,4,5,6 - в пределах релиза не смотря на серьезные перепиливания
> - сохраняют API и ABI для дров.Приведенные вами примеры как раз демонстрируют, что там, где API стабилен, развития нет - есть только поддержка, с бэкпортированием исправлений из свежих версий с нестабильным API.
> Linux на ядрах до 2.6 делился на стабильную ветку - с достаточно стабильным API
Заметим, что взрывное развитие Linux (см. сабжевую новость) началось только после того, как отказались даже от такой квази-стабильности API.
> Заметим, что взрывное развитие Linux (см. сабжевую новость) началось только после того,
> как отказались даже от такой квази-стабильности API.А я всю дорогу думал, что развитие Linux началось после вливания в него 1,3 млрд. долларов IBM в течение двух-трёх лет в начале нулевых. А ты нам тут открываешь глаза, что оказывается non-stable API всему "виной". :))
> А я всю дорогу думал, что развитие Linux началось после вливания в
> него 1,3 млрд. долларов IBM в течение двух-трёх лет в начале нулевых.А я думал что развитие линукса началось после того как Торвальдс вывалил первую версию публично, народ решил что им оно надо и сообща навалились. А ибм пришел как-то сильно опосля, когда дело было уже на мази. Потому что крупные корпорации слишком толстокожи чтобы понять что разработка им нужна на старте. Поэтому взлетать как правило приходится без них. А потом их участие - по мере нужности им чего либо.
> А ты нам тут открываешь глаза, что оказывается non-stable API всему "виной". :))
Кому надо stable api - юзают свой ископаемый 2.6.18-чтотамуних из своего редхата 5 уже который год и не парятся по поводу апи и abi. Один ты как самый клоун проблемы видишь. У других. Там где их нет.
> А я думал что развитие линукса началось после того как Торвальдс вывалил первую версию публично, народ решил что им оно надо и сообща навалились. А ибм пришел как-то сильно опосля, когда дело было уже на мази.Сказки - даже в 2.4 ядро - было слишком далео от "на мази". Развитие началось после того как IBM влило стопку патентов и бабла в эту недоработанную систему.
> Кому надо stable api - юзают свой ископаемый 2.6.18-чтотамуних из своего редхата 5 уже который год и не парятся по поводу апи и abi. Один ты как самый клоун проблемы видишь. У других. Там где их нет.
Вюношь, Прежде чем оскорблять других стоило бы посмотреть в зеркало - на ту обезьяну которую ты там видишь. Для сведения такого ископаемого как ты - тот 2.6.18 который в RHEL5 - уж ооочень далек от того что было 2.6.18, и гораздо ближе к 2.6.32 (или дальше) чем тебе кажется.
А что касается проблем.. Любой крупный проект завязаный на ядро - имеет проблемы.
В качестве хорошего примера можно взять pNFS, или Lustre - и оценить количество работы которые нужны и там и там для допиливания под атуальное ядро - и как это переписывается в следующем релизе.
Хотя я очень сомневаюсь что вьюнош - имеет даже отдаленное восприятие программирования под ядро, что бы оценить это - а просто выступает как павиан кричащий в толпе что ему сказал вожак.
>Сказки - даже в 2.4 ядро - было слишком далео от "на мази". Развитие началось после того как IBM влило стопку патентов и бабла в эту недоработанную систему.ну да! :D
многим, не столько бздишнегам, сколько анти-линуксоидам, хотелось бы так думать, но...
Но линух уже был на предприятиях под ораклом, под диалапом с автодозвоном, под замену нетвари с неплохим решением марс.
>Вюношь, Прежде чем оскорблять других стоило бы посмотреть в зеркало - на ту обезьяну которую ты там видишь.заслуживает отдельного комментария - хамло и не более.
>В качестве хорошего примера можно взять pNFS, или Lustre - и оценить количество работы которые нужны и там и там для допиливания под атуальное ядроух ты!
Это случаем не те проекты, которые после 2-3 лет так и не смогли натянуть на zfs и прочий хлам из bsd/cddl? отличный пример! :D
как не пытались люстру оторвать от линуха, так и не получилось! :D
> ух ты!
> Это случаем не те проекты, которые после 2-3 лет так и не
> смогли натянуть на zfs и прочий хлам из bsd/cddl? отличный пример!
> :D
> как не пытались люстру оторвать от линуха, так и не получилось! :DpNFS отношения к ZFS не имеет.
Люстра достатоно легко портируется на любую OS - есть полумертвый проект по вливанию FreeBSD поддержки - и даже планируется его влить в mainstream люстры ;-)
не имеет.
но все эти примеры в последние годы развивались как раз не как проекты с базой на linux.
вот и всё что хотел сказать.зыж
>Люстра достатоно легко портируется на любую OSну а что там предыдущий оратор плакался то? :D
> не имеет.
> но все эти примеры в последние годы развивались как раз не как проекты с базой на linux.
>вот и всё что хотел сказать.Хорошо бы еще вьюнош разбираться в вопросе. pNFS это таки linux kernel based проект.
>ну а что там предыдущий оратор плакался то?"досточно легко" - это 2 недели портирования между минорными (изменение в 4й цифре) релизами.
В случае Linux, в случае Solaris/BSD - это делается действительно проще и реже.А все по тому что мозгов у разработчиков ядра нет - или нет желания - сделать что-то и поддерживать.
Это же проще - всегда можно сломать и казать - так плохо! А при поддержке - приходится думать и решать как лучше сделать на перспективу. Вот и превращается linux kernel в сборище сиюминутных решений, без оглядывания на перспективу. И большие цифры изменений - лишь подчеркивают не желание разработчиков думать, а не "взрывное" развитие - как многим тут кажется.
pNFS, малыш, это таки стандарт, а не проект. :D
> А я всю дорогу думал, что развитие Linux началось после вливания в него 1,3 млрд. долларов IBMа стоит ли заниматься тем, что явно не получается?
Вопрос риторический.
Зыж
если все же не угомонишься, то прочитай про первыц ынтырпрайзный оракл 8.0.5 под линух и когда это было и с каким ведром.
А потом представь, что уже до этого многие под линь ставили 7.7.3 от ско опенсервер/юниксваре из-за плюшек нового ПО и адекватной интеграции с вин и нетварью.
вот чтобы не быть голословным
>История выпуска для Linux x86
>сентябрь 1998 года — Oracle 8.0 (8.0.5)http://ru.wikipedia.org/wiki/Oracle_Database#.D0.98.D1.81.D1...
версия ядра на тот момент
>9 июня 1996 — Linux версии 2.0.0
>25 января 1999 — Linux версии 2.2.0http://ru.wikipedia.org/wiki/Linux_(%D1%8F%D0...)#.D0.98.D1.81.D1.82.D0.BE.D1.80.D0.B8.D1.8F
> вот чтобы не быть голословным
>>История выпуска для Linux x86
>>сентябрь 1998 года — Oracle 8.0 (8.0.5)
> http://ru.wikipedia.org/wiki/Oracle_Database#.D0.98.D1.81.D1...и что вы хотели сказать этим? в то время Oracle и на FBSD работал ;-) и что ?
вобщем как обычно пукнули в лужу
1. В то время - не работала.
2. Вы как-то специально недопонимаете разницу "официально_поддерживала_в_продакшене" и "в то время Oracle и на.."
3.
>и что вы хотели сказать этим?только то, что линух задолго до событий, описываемых в сплетнях айзинки, уже был готов к промышленному применению и даже обгонял многие коммерческие *никсы
> Приведенные вами примеры как раз демонстрируют, что там, где API стабилен, развития нет - есть только поддержка, с бэкпортированием исправлений из свежих версий с нестабильным API.Оригинальная предспосылка была - стабильный API останавливает развитие проекта. Покажите мне как он остановил развитие FreeBSD? да - ветка stable имеет много исправлений и небольшое развите со стабильным кодом. А в Current - можно ломать сколько хочется.
Это не развитие?> Заметим, что взрывное развитие Linux (см. сабжевую новость) началось только после того, как отказались даже от такой квази-стабильности API.
Развите началось после того как конторы типа RH/IBM/SuSe и тп - влил в ядро несколько милиардов, а отнюдь не от отмены stable API.
утчи матчасть ребенок.
> Оригинальная предспосылка была - стабильный API останавливает развитие проекта. Покажите мне как он остановил развитие FreeBSD? да - ветка stable имеет много исправлений и небольшое развите со стабильным кодом. А в Current - можно ломать сколько хочется.
> Это не развитие?Разумеется, развитие. Разумеется, только с отказом от стабильности API.
> Развите началось после того как конторы типа RH/IBM/SuSe и тп - влил в ядро несколько милиардов, а отнюдь не от отмены stable API.
> утчи матчасть ребенок.Кроме бреда и хамства, аргументы есть?
> Разумеется, развитие. Разумеется, только с отказом от стабильности API.Так проект развивается? а стабильное API в нем присутсвует?
Или тут другой аргумент - что Linux не хочет тратить свое ультра дорогое время на исправление своих же ошибок?
Это же не так интересно - как тупо кодить новый код :)
что-что? каждая версия? драйвера от висты подходят под 7 и 8
1) разные драйверы - по разному. Я видел даже как дрова переставали работать после сервиспаков.
2) Ситуация много хуже чем в Линукс - если вендор устройства сдох, то новых дров не будет никогда. В линуксе-бсд его либо портируют на новое апи сами разработчики ядра (когда билд "ломается") либо, в крайнем случае, самому можно это сделать.
> 1) разные драйверы - по разному. Я видел даже как дрова переставали
> работать после сервиспаков.Наиболее эпичен был SP2 в XP. Некоторые системы падали в бсод с INACCESSIBLE_BOOT_DEVICE. Ответ майкрософта был шедеврален: "извините, но ваше железо более не поддерживается и не будет работать с XP SP2".
Еще бывает прикольно когда производитель засунул все дрова мамки в монолитный EXE (особенно это любит фирма интел). Потом снял мамку с производства в пользу такой же но версии чуть поновее. А дрова уже другие. А для "устаревшей" мамки их выпускать перестают. А "поддержка XP с SP2" - вовсе не означает что на XP SP2 + все хотфиксы это поставится. Оно вполне себе умеет ломаться сообщая что у вас не та версия винды, мол. Подавайте нам ванильный SP2! (Мне что, сносить все секурити апдейты?!). Вот тут гемора можно получить от души. В лучшем случае удастся распаковать монолитный блоб на составляющие и поставить их отдельно. Но геморроищу в любом случае будет оптом и в розницу.
(Hell yea, капча подтверждает: 00000)
2. тож самое и в лин-бсд, еси дрова распространяются блобом. и не нужно раскатывать губу, что вы там сами чего-то напишите, напишите под карточки энвидии.
И много вы блобов видели под линуксы? Я лично знаю только карточки nvidia - да, они неюзабельны без блоба. Плюс некоторые принтеры, в основном от canon. Всё остальное работает искаропки, без блобов, либо не широко распространено. Сейчас использую ноутбук без единого блоба. Кроме флешплеера, вестимо :) Да и тот временно...
> И много вы блобов видели под линуксы? Я лично знаю только карточки
> nvidia - да, они неюзабельны без блоба. Плюс некоторые принтеры, в
> основном от canon. Всё остальное работает искаропки, без блобов, либо не
> широко распространено. Сейчас использую ноутбук без единого блоба. Кроме флешплеера, вестимо
> :) Да и тот временно...Да куча их, всяких этих фирмваре, карточка-то вайфайная у вас тоже с блобом, поди, работает? Или вы маргинал который генту с deblob собирали?
> что-что? каждая версия? драйвера от висты подходят под 7 и 8А видеодрайвер от икспы черта с два заработает на семерке. Почему-то некоторые как обычно говорят не всю правду, что очень типично для господ из MS и их прихлебателей ;)
> что-что? каждая версия? драйвера от висты подходят под 7 и 8С какой-то вероятностью, отличной от единицы, да.
>ИМХО, стабильное API - это не самое лучшее решение для открытого софта, такое решени сойдет только закрытому софту сделанному ради бабла.Ага, glibc/glib/gtk/qt и т.д. имеют стабильный API, следовательно, они не пригодны для открытого софта.
разве gtk и qt стабильный api?
> разве gtk и qt стабильный api?а вы видели где нить что бы рамках qt 4.x.y менялся API без смены x ?
я не разу не видел.
А вот в ядре когда минорное обновление 2.6.x.3 ломает API которое было в 2.6.x - видел, и не один раз.
>а вы видели где нить что бы рамках qt 4.x.y менялся API без смены x ?У них обратная совместимость. Если что-то написано под Qt 4.0, то оно будет работать и на 4.7. С ядром такое не прокатит. Драйвер под 2.6.32 не соберётся под 2.6.35 и т.д.
> под 2.6.32 не соберётся под 2.6.35 и т.д.Ну и хорошо: меньше никем не поддерживаемого сто лет гнилья в кернеле. В результате остаются только качественные дрова которые кому-то нужны и которые кто-то готов майнтайнить. А не как у виндузятников - вывалили какой-то крап чисто номинально, а дальше сами крутитесь как хотите: баги чинить не будем, под новые винды переделывать не будем, сорцы тоже не дадим. Короче, хотите новую винду - покупайте новую железку! А писать драйвер для новой ОС для железки которую вы позавчера купили, а мы ее вчера с производства сняли - нам никакого резона нет, что вы!
>Ну и хорошо: меньше никем не поддерживаемого сто лет гнилья в кернеле.Внезапно, 3 месяца != 100 лет. К тому же "гнильё" из ядра не очень то любят выкидывать. Так и таскают всё с собой, перетряхивая каждые 3 месяца. Естественно, тестировать на железе последствия сих перетряхиваний тоже ни кто не собирается.
> Внезапно, 3 месяца != 100 лет. К тому же "гнильё" из ядра
> не очень то любят выкидывать. Так и таскают всё с собой, перетряхивая
> каждые 3 месяца. Естественно, тестировать на железе последствия сих перетряхиваний
> тоже ни кто не собирается.Не хочу ничего сказать но у меня почему-то на моем железе открытые драйвера из линукса работают лучше чем закрытые из винды. Например SATA диск. При горячем подключении линукс намного адекватнее реагирует на всевозможные glitches. Если вдруг чипсет или диск переклинило, он допирает ресет контроллеру или линку вхреначить. Винда при таком просто теряет диск. До ребута. Очень "удобно".
>>а вы видели где нить что бы рамках qt 4.x.y менялся API без смены x ?
> У них обратная совместимость. Если что-то написано под Qt 4.0, то оно
> будет работать и на 4.7. С ядром такое не прокатит. Драйвер
> под 2.6.32 не соберётся под 2.6.35 и т.д.а кто виноват в том что не соберется? разработчики QT вот могут такое сделать - а ядро то чем хуже?
> А сейчас львиная доля исправлений это перепиливание дров под каждый чих с
> измнением APIЗато остаются только живые драйвера которые кто-то готов поддерживать. Зачем нам тонны барахла которое никто не майнтайнит и не чинит???
>Зачем нам тонны барахла которое никто не майнтайнит и не чинит???Чтобы таскать с собой и делать видимость, что железка поддерживается. Глядишь, и правда что-то 5-летней давности внезапно заработает.
> Чтобы таскать с собой и делать видимость, что железка поддерживается. Глядишь, и
> правда что-то 5-летней давности внезапно заработает.Угу, давайте вспомним в какой ОС первой появилась поддержка usb 3.0 ;)
>> может быть тогда до разработчиков дойдет - что имеет смысл держать стабильным API для драйверов
> Стабильное API - это прекращение всякого развития, это смерть ядра.Стабильный API... О чем ты вообще трындишь? "Совместимость важнее производительности" (С) Максима мира ИТ образца 1980 года.
Win API, Win32 API, Win32S API, NET SL, Win RT -- и чего основной конкурент дурью мается?
> Win API, Win32 API, Win32S API, NET SL, Win RT -- и
> чего основной конкурент дурью мается?И я о том. За более 10 лет наплодили только 5 видов API. До ядра им далековато.
До платформы им далековато.
> До платформы им далековато.До какой платформы? Которая им не нужна?
> До какой платформы? Которая им не нужна?Это вы о чем? MS линуксом свои даунлоады отгружает. Такой вот пируэт судьбы :)))
>> До какой платформы? Которая им не нужна?
> Это вы о чем? MS линуксом свои даунлоады отгружает. Такой вот пируэт
> судьбы :)))Куда отгружает?
> Куда отгружает?Юзерам. Ну и прочим клоунам типа вас. Я конечно понимаю что обладателям мозжечка вместо мозга очень сложно посмотреть сервак на какой ОС им там файло отдает, однако рекомендую все-таки посмотреть чем пользуется AKAMAI CDN, отдающий даунлоады MS'а :D. Windows server обгоняет линукс. Так обгоняет, что сам MS им пользоваться для сервировки не стал, хотя казалось бы уж сами себе то настричь лицензий могут до упора и даром :)))
>> Куда отгружает?
> Юзерам. Ну и прочим клоунам типа вас. Я конечно понимаю что обладателям
> мозжечка вместо мозга очень сложно посмотреть сервак на какой ОС им
> там файло отдает, однако рекомендую все-таки посмотреть чем пользуется AKAMAI CDN,
> отдающий даунлоады MS'а :D. Windows server обгоняет линукс. Так обгоняет, что
> сам MS им пользоваться для сервировки не стал, хотя казалось бы
> уж сами себе то настричь лицензий могут до упора и даром
> :)))вот что за манера, говоришь: "у вас руки из Ж", а в ответ получаешь: "посмотрите какие валенки зеленые...". хватит юлить и бегать. не стабильный апи в линуксе и это ни чем не оправдать, ни валенками ни AKAMAI.
>может быть тогда до разработчиков дойдет - что имеет смысл держать стабильным API для драйверов - что бы можно было держать архив драйверов отдельно, все остальное отдельно.А что мешает паковать собственно ядро с некоторым минимальным базовым набором модулей в отдельный архив, модули сетевых 1000 Мбит/с в другой архив, модули 100 Мбит/с сетевух в третий, ..., модули ALSA устройств, ..., модули KMS/GEM, и т.д. Т.е. каждый вид модулей в свой архив. Тогда и конечному пользователю не придётся всё качать. И не надо никакого стабильного API (нефиг поощрять писателей закрытого кода).
> А что мешает паковать собственно ядро с некоторым минимальным базовым набором модулей
> в отдельный архивчестно говоря, жуткую чепуху обсуждаем.
неужели для вас 70мб это много?
если качать разницу в версиях пакета, а не сами пакеты, то не имеет значения, упаковано ядро раздельно, или едино.
даже в моих глазах (человека, который плохо разбирается в математике) в издеваетесь над ней. экспонента стремится в бесконечность, но никогда её не достигает. людям из 70-тых тоже могло казаться, что ось, которая жрёт 700 мб ОЗУ, раздавит любой компьютер, и производство софта войдёт в коллапс.фактически, unix занимает всё меньшую и меньшую долю ОЗУ и HDD. а ведь ранее даже здравомыслящие люди перекомпилировали ядро, чтобы уменьшить его вес.
график в новости не имеет смысла, не стоило его публиковать.
что, боитесь что ядро вот вот лопнет? :)
> что, боитесь что ядро вот вот лопнет? :)Ясный перец. Клепать монолитное ядро на платформе, в которой тысячи железок - идиотизм, причем очевидный.
>> что, боитесь что ядро вот вот лопнет? :)
> Ясный перец. Клепать монолитное ядро на платформе, в которой тысячи железок -
> идиотизм, причем очевидный.Ты просто не понимаешь фишку бизнеса. Задача - удержать разработку внутри проекта любыми способами. Меняющийся API этому только способствует, т.к. дешевле оплатить работу kernel-team, чем нанять группу программистов, которые мало того, будут писать драйвер, так ещё и вовремя адаптировать под новые версии.
> Ты просто не понимаешь фишку бизнеса. Задача - удержать разработку внутри проекта
> любыми способами. Меняющийся API этому только способствует, т.к. дешевле оплатить работу
> kernel-team, чем нанять группу программистов, которые мало того, будут писать драйвер,
> так ещё и вовремя адаптировать под новые версии.А почему собственно кто-то должен работать так как удобно/привычно/хотелось бы вам? Вам удобен виндовс? Ну и флаг вам в руки. Какие проблемы то? А разработчики линукса делают так как удобно им. Судя по тому что в ряде ниш оно выпилило остальные системы - не так уж и плохо у них получается.
Кстати 4 разных несовместимых между собой дотнета да еще переход от WinForms к WPF - это ничего, нормально видимо. Хотя полпрограммы приходится перелопачивать. У микрософтовцев лицемерие - вторая натура. За собой они никогда бревна в глазу не видят, зато у конкурентов соринку в глазу всегда найдут.
> Ясный перец. Клепать монолитное ядро на платформе, в которой тысячи железок -
> идиотизм, причем очевидный.Так драйвера - модули как правило. Поэтому фактически в памяти висит только то что реально требуется для конкретной системы. В этом плане нет каких-то фундаментальных отличий от винды, например. Которая к слову тоже не стесняется менять API, так что драйвера XP, 2000, 2003, 2008 и Win7 совместимы только сильно иногда и с оговорками, а видеодрайвера например вообще от XP на семерку например хрен вообще поставишь.
> 2000, 2003, 2008 > Win7 совместимы только сильно иногда и с оговорками, а видеодрайвера например вообще от XP на семерку например хрен вообще поставишь.И не говори. Меняют api каждые 3-4 года. Ужас просто. Не то что нвидивский блоб, который надо обновлять каждые 3-4 месяца под новое ядро.
> И не говори. Меняют api каждые 3-4 года. Ужас просто. Не то
> что нвидивский блоб, который надо обновлять каждые 3-4 месяца под новое ядро.Просто людей пишущих открытое ядро проблемы проприерасов мало волнуют. Что ожидаемо - в чужой монастырь со своим уставом не ходят.
>> И не говори. Меняют api каждые 3-4 года. Ужас просто. Не то
>> что нвидивский блоб, который надо обновлять каждые 3-4 месяца под новое ядро.
> Просто людей пишущих открытое ядро проблемы проприерасов мало волнуют. Что ожидаемо -
> в чужой монастырь со своим уставом не ходят.а проблемы других открытых проектов которые не влиты в ядро ?:)
так пусть вливаются. в чём проблема то?
а то и рыбку съесть и нах.. сесть.
> так пусть вливаются. в чём проблема то?
> а то и рыбку съесть и нах.. сесть.Вьюнош - я тебе уже говорил - разберись в области о чем говоришь. А потом уже выссказывай свое мнение.
Пока же от тебя гасификация луж и все.
Кроме того включи мозги - и поймешь что иногда проекты или не хотят вливаться в ядро, или не готовы (не дописаны) - а такое поведение обезьянок под руководством линукса - вредит всем. Ибо проектам приходится тратить ресурсы что бы поддерживать мараз ядро писателей.
Вместо того что бы всем разиваться и сосуществовать.
>И не говори. Меняют api каждые 3-4 года. Ужас просто. Не то что нвидивский блоб, который надо обновлять каждые 3-4 месяца под новое ядро.а зачем ты ядро то меняешь?
сиди как в виндах - на старом ведре и обновляй с критическими патчами (включая и видео) вида "не выключайте компьютер 33%".
или чё, скажешь этого там нет? или скажешь после этих 20-30 минут ещё и винда иногда просто не стартует?
>Так драйвера - модули как правило.И гвоздями прибитые к своему ядру. Профит от такой "модульности" нулевой. Разве что появление всяких костылей, вроде initrd и dracut.
>>Так драйвера - модули как правило.
> И гвоздями прибитые к своему ядру. Профит от такой "модульности" нулевой. Разве
> что появление всяких костылей, вроде initrd и dracut.Пишите дрова для win95, это API и ABI уж точно никто менять больше не будет. Ибо некому.
>Пишите дроваэто вы кому говорите то?
я конечно понимаю плохообъяснимую заботу анальных рабов об опенсорсных драйверо-писателях, но всё же.