Ответ Линуса на пост о мертвейшем линуксе и срач отцов-основателей.

В BSD тоже, и BSD тоже красная тряпка :)

Я специально не упомянул. О покойниках либо хорошо, либо ничего . :)

О покойниках либо хорошо, либо ничего . :)

Ну BSD уж точно не менее жива, чем Солярис.

Справедливости ради, обычно можно обновить только ядро. Навыки компиляции, конечно, required.

Ну, в общем-то, да. Просто никогда не знаешь, поймаешь ли проблемы или нет. Иногда, правда, появляются заодно обновления, от которых не сразу очевидно чего ждать. Например, вдруг требуется новый udev или initramfs-tools. Сам-то я как-нибудь с этим разберусь, а вот какие-то простые пользователи...

Тут же еще одна сторона вопроса есть, о которой речи не шло. Это разработчики драйверов. Скажу честно, что меня как потенциального разработчика, чехорда с API/ABI не устроила бы. Я трачу свое время, чтобы что-то заработало. Сэкономьте мне время, не меняйте API. Я же не имею возможностей сопровождать драйвер всю жизнь. И это уже не сопровождение драйвера получается, а сопровождение чьих-то изменений в API. Этим заниматься нет никакого желания. А производителям тоже сопровождать старое железо под новое API нет никакого резона. Но оно же работало когда-то. Так пусть работает и дальше. Нет же - выкидывают как unmaintainable.

Скажу честно, что меня как потенциального разработчика, чехорда с API/ABI не устроила бы. Я трачу свое время, чтобы что-то заработало. Сэкономьте мне время, не меняйте API. Я же не имею возможностей сопровождать драйвер всю жизнь.

(занудным голосом) Официальная позиция заключается в том, что ты должен засабмитить драйвер in tree, и дальше при изменениях API его будут править те, кто меняет API.

Кстати, в пределах серии 2.6.x, x > 26, не припомню сильных изменений API.

Нет же - выкидывают как unmaintainable.

Не знаю таких примеров.

Ну BSD уж точно не менее жива, чем Солярис.

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

Ну BSD уж точно не менее жива, чем Солярис.

Ну и разработчиков в 50 раз меньше, как и клиентской базы

Да ты что? Как считал?

не говоря уж о продажах.

Плакал.

(занудным голосом) Официальная позиция заключается в том, что ты должен засабмитить драйвер in tree, и дальше при изменениях API его будут править те, кто меняет API.

И что, меняют? Вот про X.Org точно могу сказать, что меняют. Причем постоянно, но там хотя бы драйверов не столько, сколько в Linux, то есть не так напряжно.

Не знаю таких примеров.

Про ядро ничего не могу сказать, поэтому сейчас получится, что и нет такого просто, потому что *ты* об этом не слышал. Я вот, например, слышал, что собирались в 2.6.38 уделить слой совместимости между v4l и v4l2, а у меня как раз в компе стоит карточка видеозахвата, которая *вроде бы* (а это я проверю потом) поддерживает только v4l, а не v4l2. Пока что у меня ядро 2.6.32, и я не знаю, будет ли она работать на новом ядре. В любом случае, если бы было v4l-only устройство, то оно бы уплыло в дальние дели.

В иксах тоже, кстати, сейчас массовые удаления идут. Например, дропнули XAA. И теперь не работает хардварное ускорение на S3, а только программное через shadowFB. Я как-то писал поддержку EXA, но потому уперся в то, что архитектура EXA не учитывает специфику старых карт. Вполне резонно ожидать, что когда-то выкинут вообще все, что не имеет KMS.

(занудным голосом) Официальная позиция заключается в том, что ты должен засабмитить драйвер in tree, и дальше при изменениях API его будут править те, кто меняет API.

И что, меняют?

Да.

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

Естественно, я знаю не всё. Но в ядре до сих пор живут драйверы aha1542.c и in2000.c - последние компьютеры с этими устройствами у нас списали 10+ лет назад (и уже тогда они были древним хламом).

Конечно, хочется стабильного драйверного интерфейса. Но nature of the beast такова, что мы этого не дождемся - не потому, что это невозможно, а потому, что это сознательно саботируется.

Конечно, хочется стабильного драйверного интерфейса. Но nature of the beast такова, что мы этого не дождемся - не потому, что это невозможно, а потому, что это сознательно саботируется.

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

Firefox - хрестоматийный пример в этой теме, когда постоянно меняли API для расширений. Сколько их (может быть, даже полезных) замерло во временах 1.5. Будь я писателем этих расширений, послал бы в задницу все после пары таких выкрутасов.

И в дебах можно явно указать необходимые файлы, а не пакеты?

Каким чудом дистрибутив, в котором не обновляется софт на новые версии, должен поддерживать видеокарту, которая поступила в продажу после его выхода?

драйвер на cd положит производитель в коробочку с железкой?

до меня только что дошло. Поеттринг появился как замена ему любимого. Я то думал, какой мудак пропал из поля зрения.

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

Мне похер, мне надо, чтобы работало. И у меня все работает. А скажи, зачем ты обновляешь ядро, иксы и дистрибутив каждый день, а потом жалуешься? Возьми одно ядро, которое работает и используй.

И в дебах можно явно указать необходимые файлы, а не пакеты?

Ответ Линуса на пост о мертвейшем линуксе и срач отцов-основателей. (комментарий)

Вот чем тебе mono(который .net, а не модератор) не нравится?

не вижу преимущества. Абстракций можно и в С++ наделать, а рантайм огромный, при том, что с переносимостью у него хуже чем у явы (и он медленнее явы).

не вижу преимущества.

Перед чем - перед Си++? Безопасность. Перед Явой? Легче и лучше спроектирован.

Каким чудом дистрибутив, в котором не обновляется софт на новые версии, должен поддерживать видеокарту, которая поступила в продажу после его выхода?

А ничего, что на WinXP(которой 10 лет уже) в итоге поддерживается всё железо которое вышло за эти 10 лет плюс-минус несколько лет(совместимость с драйверами для NT/2k). С помощью тех самых волшебных дисков с драйверами.

А Линус вопит про «Stable API is non-sense». Вот оно, stable API - когда драйвера грамотно написанные 10 лет назад, худо-бедно без косяков работают по сей день. Да, я верю, что говно мамонта которое было 10 лет назад никто поддерживать не хочет, ну так и не удивляйтесь, что вендоры не хотят поддерживать железо - работы много, толку - полтора красноглазика.

Блин, когда уже будет стабильная версия ядерного API для сторонних драйверов? чтобы я мог спокойно нарисовать драйвер и быть уверенным, что если я следую написанному в Documentation/* то драйвер будет работать без перекомпиляции в течение хотя бы нескольких лет.

Начнём с того, что в сравнении с явой язык поудобнее. Вызовы к Сишным библиотекам делаются в пол-пинка, а не с кучей геморроя как в яве. Насчёт медленнее - ты как-то отстал от жизни, быстродействие сравнимо, если не быстрее, и потребление памяти у .net(mono) поменьше чем для аналогичных проектов на яве.

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

З.Ы. Плюсам место на свалке.

А Линус вопит про «Stable API is non-sense». Вот оно, stable API - когда драйвера грамотно написанные 10 лет назад, худо-бедно без косяков работают по сей день.

Грамотность здесь вообще не причем - просто у венды есть стабильная ветка, а у Linux нет. И кстати, «Stable API nonsense» написал известный мудак Кроа-Хартман.

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

Вот и корень проблемы.

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

/0

Просто фул хаус какой-то!

Для тех, кто прослоупочил или не знает ангельского - копипаста с Опеннета:

В связи с недавно опубликованным заявлением о первичном приоритете сохранения неизменности внешних программных интерфейсов ядра Linux, влияющих на работу пользовательских приложений, Линусу Торвальдсу был задан вопрос, как в этом случае следует воспринимать наблюдаемые последние годы нарушающие совместимость изменения в ядре, такие как прекращение поддержки некоторых файлов и директорий в /proc, постоянное изменение структуры /sys, непостоянство механизма уведомления приложений об изменениях в файловой системе (inotify, dnotify и fnotify) и наличие в ядре API-вызовов, которые можно использовать только из модулей под лицензией GPL.

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

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

Возобновление совместимости из-за ранее внесённых ошибок рассматривается как очень сложные для решения проблемы. Например, из-за ошибки в ядре была нарушена работа 32-разрядного демона autofs при использовании 64-разрядных сборок ядра. Различные дистрибутивы добавили в свой состав разные патчи для устранения данной проблемы, но при попытке исправить проблему в ядре возникла ситуация нарушения совместимости на уровне ошибок со старыми версиями (перестали работать пакеты autofs, в которые были добавлены исправления для обхода проблемы в ядре).

Также упоминается, что многие из связанных с обеспечением обратной совместимости параметров ядра настраиваемы, поэтом можно собрать ядро с такими настройками, при которых совместимость со старыми компонентами пользовательского окружения будет нарушена. Примером таких настроек, которые легко отключается в конфигурации, может служить поддержка формата исполняемых файлов a.out, прослойка для совместимости со старым беспроводным стеком, поддержка некоторых возможностей /proc и элементы совместимости с lm-sensors. Другие параметры, влияющие на совместимость, требуют включения или отключения во время работы, например, управляющие переключением видеорежимов модули KMS должны быть отключены для старых версий X.Org, так как они мешают работе старой схемы инициализации графики.

Что касается вызовов, доступных только для модулей под лицензией GPL, то эти вызовы никогда не являлись API и относятся к категории внутренних интерфейсов ядра. Разработчики ядра никогда не утверждали, что ядром будут поддерживаться модули с лицензией отличной от основной лицензии на код ядра. Более того, многие люди утверждают, что не GPL модули использовать с ядром Linux нелегально, но юридически подобная лицензионная несовместимость пока не подтверждена в суде.

В дополнение Линус привёл пример нескольких проблем, связанных с нарушением совместимости API, с которыми ему приходится сталкиваться как пользователю Linux:

• Непостоянство программных интерфейсов драйверов, развиваемых проектом X.Org. В частности, упоминаются постоянно возникающие проблемы с разработчиками драйвера Nouveau, которые слишком часто меняют API, что приводит к несовместимости DRM-модуля Nouveau с прошлыми версиями драйвера, работающего на уровне пользователя. Тем не менее, в настоящее время отмечаются положительные сдвиги в этой области, в частности, проект Nouveau изменил свою политику и теперь пытается избегать нарушения совместимости API;
• Частое нарушение в прошлом обратной совместимости в звуковых библиотеках, развиваемых проектами ALSA и PulseAudio. Практика нарушения API в звуковых библиотеках не касалась интерфейсов ядра и в настоящее время уже почти не проявляется, тем не менее, в прошлом непостоянство звукового API приводило к большим проблемам в среде разработчиков приложений;
• Нарушение работы бинарных приложений при обновлении GLibc. Несмотря на то, что разработчики Glibc относятся к проблемам совместимости значительно более аккуратно, чем разработчики GTK+, временами случаются просчёты, приводящие к нарушению работы пользовательских приложений. При сообщении о подобных фактах нарушения работы ответом часто является ссылка на проблемы самого приложения. Хочется надеется, что недавнее изменение модели управления в проекте Glibc позволит пересмотреть правила обеспечения совместимости.

Хорошо, для диванных теоретиков уточняю - вне случаев явно связанных с программированием железа и совсем уж низкоуровневых частей системы. И то, спорно. для примера см. Singularity.

В нагрузку - ты помнится на управляемых языках не пишешь, так что откуда ты знаешь вкус устриц? Мне таки довелось писать и на C и на C#, в принципе даже на плюсах немного, но тот опыт уж слишком незначителен и негативен. В итоге на C# одна и та же задача решается тупо быстрее за счёт отсутствия необходимости слежения за указателями(я не говорил что за использованием памяти смотреть не надо, просто свои хитрости есть).

откуда ты знаешь вкус устриц?

Пытался на питоне писать скрипты для фрикада. Ощутил всю жесть работы на этом говноязыке.

А можешь вспомнить, в чём была самая непонятная жесть? Ибо питон не относится к моим любимым языкам, хотя писать время от времени приходится, но standalone приложения и какой-то особой жести я не припомню.

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

А можешь вспомнить, в чём была самая непонятная жесть?

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

Я — за ручную сборку мусора. И нормальную работу с памятью.

В невозможности явно задать тип данных.

Используй строго типизированные языки.

Я — за ручную сборку мусора. И нормальную работу с памятью.

А я за использование инструментов по назначению, а не везде где попадётся. Гуй писать на си/си++ - нафиг-нафиг, я слишком ленив чтобы так над собой издеваться. Крайние случаи типа GUI на embedded железке не берём, уж очень специфичный. Но и пихать интерпретатор python на армовую железку с 8 мегами флеша и 32 ОЗУ я тоже не буду, обойдусь Си, хоть он и не всегда удобен, но в условиях ограниченных возможностей очень к месту. Хотя присматриваюсь к Lua, для некритичных к скорости участков.

Гуй писать на си/си++ - нафиг-нафиг, я слишком ленив чтобы так над собой издеваться

Клиентская часть гуя — на JS, серверная — на сях. И все ОК.

серверная — на сях. И все ОК.

До тех пор пока не требуется особо извращённой логики и неизбежных при длительной поддержке костылей.