Совместимость ядер и ядерных модулей

John Freeman написал(а) к Eugene Muzychenko в Apr 17 17:26:37 по местному времени:

Нello, Eugene!

EM> Привет!

EM> 17 Apr 17 15:45, you wrote to me:

JF>> Если под ядро модуль - безусловно.

EM> Ну ладно, для крайне минималистических ядер, где важен каждый десяток килобайт, привязка модуля к ядру на этапе линковки может быть оправдана. Но когда нет нужды экономить этот десяток килобайт, что мешает сделать динамическое связывание? Для вящей красоты оформить этот код модулем. :)

=> сиди в винде, там так

JF>> Wifi->добавить

EM> Так это добавление обычного интерфейса, который по умолчанию привяжется к br-lan. Его нужно будет отвязать, привязать к wan, сделать для него собственный DНCP, настроить файрвол. Не великая работа, но мне такое нужно в каждом маршрутизаторе, лень копаться руками.

Никуда никогда никакой добавленный интерфейс сам не привяжется, всё надо указать. Под openwrt сетевой стэк привязан к конфигам и на новые сети будет создаваться номерной интерфейс, в дефолте wlanx-y, основной wlanx, я так пока не смотрел как делается в "обычном" linux+GNU. Хочется сразу - заливай конфиги, всё сохраняется и клонируется отлично, можно даже через imagebuilder запихать в /rom(обычно squashfs) прошивки.

EM> Всего доброго!
EM> Евгений Музыченко
EM> eu-gene@muzy-chen-ko.net (все дефисы убрать)


С наилучшими пожеланиями, John Freeman.

--- wfido

Eugene Muzychenko написал(а) к John Freeman в Apr 17 23:10:49 по местному времени:

Привет!

20 Apr 17 17:26, you wrote to me:

=>> сиди в винде, там так

А в линуксах будут плакать, колоться, но динамического связывания все равно не сделают? :)

JF> Хочется сразу - заливай конфиги, всё сохраняется и клонируется
JF> отлично

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

JF> можно даже через imagebuilder запихать в /rom(обычно squashfs)
JF> прошивки.

Можно, когда заняться больше нечем, но потрахаться очень хочется. :)

Всего доброго!
Евгений Музыченко
eu-gene@muzy-chen-ko.net (все дефисы убрать)

--- GoldED+/W32-MSVC 1.1.5-b20170303

Rinat H. Sadretdinow написал(а) к Eugene Muzychenko в Apr 17 21:07:02 по местному времени:

Нello Eugene!

20 Apr 17 23:10, you wrote to John Freeman:

=>>> сиди в винде, там так

EM> А в линуксах будут плакать, колоться, но динамического связывания все
EM> равно не сделают? :)

А зачем? Я что-то наверное не понимаю. Всё равно ntoskrnl^W vmlinuz с каждой новой версией пересобирается и модули прекрасно пересобираются вместе с ним. Полторы с половиной проприетарщины типа драйверов nvidia тоже пересобираются, они сто лет в обед как умеют dkms. Драйвера от VirtualBox тоже через dkms сами себя пересобирают. VmWare насколько я помню тоже свои драйвера автоматом пересобирал как только новая версия ядра приползала. В чём проблема то? Кто страдает? Кто колется?

Bye!

--- GoldED+/LNX 1.1.5-b20150715

Eugene Muzychenko написал(а) к Rinat H. Sadretdinow в Apr 17 09:44:00 по местному времени:

Привет!

20 Apr 17 21:07, you wrote to me:

RS> Полторы с половиной проприетарщины типа драйверов nvidia

Боюсь, ты проприетарщины, кроме той nvidia, и не видел вовсе. :)

RS> Драйвера от VirtualBox тоже через dkms сами себя пересобирают. VmWare
RS> насколько я помню тоже свои драйвера автоматом пересобирал как только
RS> новая версия ядра приползала.

Ну да, со временем научились приделывать костыли, если уж по уму не получилось. :)

RS> В чём проблема то? Кто страдает? Кто колется?

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

Всего доброго!
Евгений Музыченко
eu-gene@muzy-chen-ko.net (все дефисы убрать)

--- GoldED+/W32-MSVC 1.1.5-b20170303

Rinat H. Sadretdinow написал(а) к Eugene Muzychenko в Apr 17 08:29:22 по местному времени:

Нello Eugene!

21 Apr 17 09:44, you wrote to me:

RS>> Полторы с половиной проприетарщины типа драйверов nvidia

EM> Боюсь, ты проприетарщины, кроме той nvidia, и не видел вовсе. :)

Ну скорее всего. Если не считать VmWare которая тоже можно сказать проприетарщина, то не видел.

RS>> Драйвера от VirtualBox тоже через dkms сами себя пересобирают.
RS>> VmWare насколько я помню тоже свои драйвера автоматом пересобирал
RS>> как только новая версия ядра приползала.

EM> Ну да, со временем научились приделывать костыли, если уж по уму не
EM> получилось. :)

Почему это костыли? Это Dynamic Kernel Module Support, вполне штатная вещь. Если так судить, то Windows Update тоже костыли, оно ведь делает по большому счёту то же самое, только не пересобирает какой-нибудь usbd.sys, а устанавливает готовый.

RS>> В чём проблема то? Кто страдает? Кто колется?

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

В таком случае они страдают ещё и когда пишут свои продукты. Потому что одно от другого в данном случае не отделимо, в то время как приделка поддержки dkms к своим продуктам это вообще (утрирую) минутное дело.

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

Ну эти да, страдают и плачут. Но всё же меньше тех, которым повезло обзавестись продуктами, которые вообще не поддерживаются. А кто их просил приобретать такие продукты? Я говорю не про корпоративных пользователей, для них сделают поддержку, однозначно, а про простых, домашних. ССЗБ они в таком случае.

Bye!

--- GoldED+/LNX 1.1.5-b20150715

Eugene Muzychenko написал(а) к Rinat H. Sadretdinow в Apr 17 15:48:14 по местному времени:

Привет!

21 Apr 17 08:29, you wrote to me:

RS> Почему это костыли?

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

RS> Это Dynamic Kernel Module Support, вполне штатная вещь.

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

RS> Если так судить, то Windows Update тоже костыли, оно ведь делает по
RS> большому счёту то же самое, только не пересобирает какой-нибудь
RS> usbd.sys, а устанавливает готовый.

WU - это именно автоматизация замены компонент, а не их изготовления.

RS> В таком случае они страдают ещё и когда пишут свои продукты.

Разумеется. В частности, на них ложится задача не просто распространения продукта, а его привязки определенным образом к DKMS (создание своего репозитория или загрузка в существующие). И поддержка работоспособности этой привязки на всем времени существования продукта.

RS> приделка поддержки dkms к своим продуктам это вообще (утрирую)
RS> минутное дело.

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

RS> Ну эти да, страдают и плачут. Но всё же меньше тех, которым повезло
RS> обзавестись продуктами, которые вообще не поддерживаются.

О том и речь, что хорошо сделанный продукт может вообще не нуждаться в поддержке. Драйвер под NT 3.5, правильно сделанный в начале 90-х, прекрасно работает под десяткой, даже если его производитель давным-давно перестал существовать.

RS> А кто их просил приобретать такие продукты? Я говорю не про
RS> корпоративных пользователей, для них сделают поддержку, однозначно, а
RS> про простых, домашних. ССЗБ они в таком случае.

И что ты посоветуешь простым, домашним пользователям в плане приобретения продуктов, чтобы иметь гарантированную поддержку? :)

Всего доброго!
Евгений Музыченко
eu-gene@muzy-chen-ko.net (все дефисы убрать)

--- GoldED+/W32-MSVC 1.1.5-b20170303

Rinat H. Sadretdinow написал(а) к Eugene Muzychenko в Apr 17 13:04:06 по местному времени:

Нello Eugene!

21 Apr 17 15:48, you wrote to me:

RS>> Почему это костыли?

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

Простой конечный пользователь вообще не в курсе что он получает, `dnf update` всё делает и пользователь даже понятия не имеет что там под капотом.

RS>> Это Dynamic Kernel Module Support, вполне штатная вещь.

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

Не согласен. Совсем не согласен. Ну да ладно.

RS>> Если так судить, то Windows Update тоже костыли,

EM> WU - это именно автоматизация замены компонент, а не их изготовления.

`dnf update` тоже автоматизация замены компонент (не знаю как правильно написать аналогичную строчку для apt-get).

RS>> В таком случае они страдают ещё и когда пишут свои продукты.

EM> Разумеется. В частности, на них ложится задача не просто
EM> распространения продукта, а его привязки определенным образом к DKMS
EM> (создание своего репозитория или загрузка в существующие).

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

EM> И поддержка работоспособности этой привязки на всем времени
EM> существования продукта.

Выше я уже на это ответил.

RS>> приделка поддержки dkms к своим продуктам это вообще (утрирую)
RS>> минутное дело.

EM> Не важно, что минутное - важно, что это действие, несвойственное
EM> производителю.

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

EM> А кто будет этим заниматься после того, как производитель прекратит
EM> поддержку продукта, или вообще свою деятельность?

Если это коммерческий продукт, то адекватное решение найдут. А если не коммерческий, то нафига его поддерживать?

RS>> Ну эти да, страдают и плачут. Но всё же меньше тех, которым
RS>> повезло обзавестись продуктами, которые вообще не поддерживаются.

EM> О том и речь, что хорошо сделанный продукт может вообще не нуждаться в
EM> поддержке. Драйвер под NT 3.5, правильно сделанный в начале 90-х,
EM> прекрасно работает под десяткой, даже если его производитель
EM> давным-давно перестал существовать.

Я вот где-то полтора-два года назад хотел завести у себя какой-то Sound Blaster, вполне себе даже Creative, родной, не Китай, но давно снятый с производства. Драйвера нашёл только для XP, причём официально, на сайте Креатива, по их пошаговой инструкции. И там чёрным по белому было написано что в других виндовсах эти драйвера не пойдут. Я не поверил, два дня прыгал вокруг компа с бубном, но на Windows Seven эти драйвера водрузить так и не смог. Ради интереса установил Windows XP и драйвера взлетели как миленькие! Но Windows XP мне не нужен. Значит ли это что Creative плохо делает плохие продукты?

RS>> А кто их просил приобретать такие продукты? Я говорю не про
RS>> корпоративных пользователей, для них сделают поддержку,
RS>> однозначно, а про простых, домашних. ССЗБ они в таком случае.

EM> И что ты посоветуешь простым, домашним пользователям в плане
EM> приобретения продуктов, чтобы иметь гарантированную поддержку? :)

Сидеть на виндофс и не выёживаться :-)

Bye!

--- GoldED+/LNX 1.1.5-b20150715

Eugene Muzychenko написал(а) к Rinat H. Sadretdinow в Apr 17 22:41:39 по местному времени:

Привет!

21 Apr 17 13:04, you wrote to me:

RS> Простой конечный пользователь вообще не в курсе что он получает, `dnf
RS> update` всё делает и пользователь даже понятия не имеет что там под
RS> капотом.

До тех пор, пока все делается правильно. Однако, тупо скопировать файлы и скомпилить исходники - несколько разные по сложности и надежности операции.

Кстати, каким образом линуксы гарантируют отсутствие ошибок в GCC, заголовках и объектных библиотеках? Если при сборке какого-то модуля компилятор вдруг ругается, чья это головная боль - разработчиков модуля, разработчиков компилятора, или конечного юзера?

RS> Не согласен. Совсем не согласен.

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

RS> `dnf update` тоже автоматизация замены компонент

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

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

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

RS> А если это Вася Пупкин, то он даёт ссылку на гитхаб, где его крутой
RS> продукт всё равно будет лежать в виде исходников.

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

RS> Это получается (грубо говоря) насрать насрал, а ручку слива не дёрнул.

Какая прелестная аналогия. :) Точнее будет "тортик испек - молодец, а теперь-ка, будь добр, с ложечки покорми". :)

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

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

RS> Если это коммерческий продукт, то адекватное решение найдут. А если не
RS> коммерческий, то нафига его поддерживать?

Что значит "нафига"? Он, как минимум, должен лежать в таком месте, чтобы любая система могла его оттуда самостоятельно достать, а как максимум - продолжать оставаться совместимым с новыми компиляторами/заголовками, чтобы при сборке не вылезало ошибок. Каким образом это обеспечивается?

RS> два дня прыгал вокруг компа с бубном, но на Windows Seven эти драйвера
RS> водрузить так и не смог. Ради интереса установил Windows XP и драйвера
RS> взлетели как миленькие! Но Windows XP мне не нужен. Значит ли это что
RS> Creative плохо делает плохие продукты?

Это значит, что ей неинтересно обеспечивать расширенную совместимость. У Creative вообще никогда не было хороших драйверов - только плохие и посредственные. Но это их собственный выбор, а не системная проблема. Я умею делать драйверы, работающие от NT 3.x до десятки, и многие другие умеют, и такие драйверы существуют. Поэтому каждый разработчик может выбирать стратегию - то ли выпускать отдельную версию под каждую систему, то ли выпускать общую, работающую в разных системах.

Кстати, драйвер под XP мог не работать под семеркой (и вообще начиная с висты) еще и потому, что в XP еще поддерживалась Legacy-модель звукового интерфейса, а в висте ее изжили. Такая смена моделей происходит раз в 10-15 лет, тут ничего не поделаешь. Но и при таком раскладе можно сделать драйвер, который будет работать и в NT 3.x, и в десятке, но делать его, само собой, можно было не раньше появления 2k, где впервые ввели KS-модель.

EM>> И что ты посоветуешь простым, домашним пользователям в плане
EM>> приобретения продуктов, чтобы иметь гарантированную поддержку? :)

RS> Сидеть на виндофс и не выёживаться :-)

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

Всего доброго!
Евгений Музыченко
eu-gene@muzy-chen-ko.net (все дефисы убрать)

--- GoldED+/W32-MSVC 1.1.5-b20170303

Rinat H. Sadretdinow написал(а) к Eugene Muzychenko в Apr 17 23:35:08 по местному времени:

Нello Eugene!

21 Apr 17 22:41, you wrote to me:

RS>> Простой конечный пользователь вообще не в курсе что он получает,
RS>> `dnf update` всё делает и пользователь даже понятия не имеет что
RS>> там под капотом.

EM> До тех пор, пока все делается правильно.

Естественно. Но, пардон муа, что там может быть неправильно? Если команда `dnf update` сама всё делает и если апдейт идёт из доверенного источника возможность автоматического `dnf update` 100 раз проверена и перепроверена?

EM> Однако, тупо скопировать файлы и скомпилить исходники - несколько
EM> разные по сложности и надежности операции.

Никто их не заставляет компилировать руками, всё автомагически.

EM> Кстати, каким образом линуксы гарантируют отсутствие ошибок в GCC,
EM> заголовках и объектных библиотеках?

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

EM> Если при сборке какого-то модуля компилятор вдруг ругается, чья это
EM> головная боль - разработчиков модуля, разработчиков компилятора, или
EM> конечного юзера?

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

RS>> Не согласен. Совсем не согласен.

EM> А сможешь внятно объяснить, чем плохо динамическое связывание по
EM> сравнению с типовой линковкой? Именно в общем случае, а не частных,
EM> вроде экономии нескольких десятков килобайт на все загружаемые модули,
EM> или привязки к редко используемым внутренним структурам ядра?

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

RS>> `dnf update` тоже автоматизация замены компонент

EM> В ходе которой происходит их изготовление весьма сложным и
EM> неоднозначным способом.

Автомагически, всё автомагически. Так что конечный пользователь не видит ни сложности, ни неоднозначности.

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

EM> А если они некоммерческие, и уже потратили несколько тысяч часов на
EM> разработку продукта, который хотят бесплатно раздавать всем желающим -
EM> конечно же, вполне справедливо нагрузить их еще и созданием
EM> репозитория. :)

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

RS>> А если это Вася Пупкин, то он даёт ссылку на гитхаб, где его
RS>> крутой продукт всё равно будет лежать в виде исходников.

EM> А если у Васи Пупкина по каким-то причинам нет аккаунта на гитхабе?

Ну где-то он ведь выкладывает свои исходники.

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

Ну где-то ведь Вася Пупкин выкладывает свои исходники! :-)

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

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

Никому это не надо. Про бритву Оккама в курсе? "Не следует привлекать новые сущности без крайней на то необходимости". Вот динамическое связывание "чтобы было как в виндофс" и есть ненужная сущность.

RS>> Если это коммерческий продукт, то адекватное решение найдут. А
RS>> если не коммерческий, то нафига его поддерживать?

EM> Что значит "нафига"? Он, как минимум, должен лежать в таком месте,
EM> чтобы любая система могла его оттуда самостоятельно достать, а как
EM> максимум - продолжать оставаться совместимым с новыми
EM> компиляторами/заголовками, чтобы при сборке не вылезало ошибок. Каким
EM> образом это обеспечивается?

Это обеспечивается при помощи dkms.

RS>> два дня прыгал вокруг компа с бубном, но на Windows Seven эти
RS>> драйвера водрузить так и не смог. Ради интереса установил Windows
RS>> XP и драйвера взлетели как миленькие! Но Windows XP мне не нужен.
RS>> Значит ли это что Creative плохо делает плохие продукты?

EM> Это значит, что ей неинтересно обеспечивать расширенную совместимость.

Ну ладно, будем считать что это плохой пример я привёл.

EM> Я умею делать драйверы, работающие от NT 3.x до десятки, и многие
EM> другие умеют, и такие драйверы существуют.

А кто-то не умеет, зато умеет делать модули, которые автоматически собирает dkms. И этому кому-то хоть убей непонятно нафига делать какое-то динамическое связывание, когда вот так вот очень просто можно обеспечить простую перекомпиляцию модуля с изменением версии ядра при помощи dkms и это будет автоматически!

Я вот не умею ни драйвера для Windows, ни модули для Linux, я умел только драйвера для DOS и OS/2. Но dkms меня нисколько не напрягает.

EM>>> И что ты посоветуешь простым, домашним пользователям в плане
EM>>> приобретения продуктов, чтобы иметь гарантированную поддержку?
EM>>> :)

RS>> Сидеть на виндофс и не выёживаться :-)

EM> Потому они и сидят на виндофс, что не хотят, с трудом перебравшись на
EM> линукс, внезапно открыть для себя что-нибудь вроде обсуждаемой
EM> парадигмы. :)

Ну и пусть дальше сидят, насильно их никто на Linux не тащит.

Bye!

--- GoldED+/LNX 1.1.5-b20150715

Eugene Muzychenko написал(а) к Rinat H. Sadretdinow в Apr 17 10:02:12 по местному времени:

Привет!

21 Apr 17 23:35, you wrote to me:

RS> Но, пардон муа, что там может быть неправильно? Если команда `dnf
RS> update` сама всё делает и если апдейт идёт из доверенного источника
RS> возможность автоматического `dnf update` 100 раз проверена и
RS> перепроверена?

Ты ж вроде программированием немного занимался, должен бы понимать. :) Если написать скрипт из трех строчек, вызывающий команду xxx, то надежность работы этого скрипта в основном будет определяться не этими тремя строчками, а командой xxx.

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

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

RS> Никто их не заставляет компилировать руками, всё автомагически.

У меня претензии к самой необходимости компиляции, а не к ее оформлению.

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

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

RS> В данном случае или головная боль разработчиков модуля, которые не
RS> протестировали его на конфигурации XYZ, но заявили что на XYZ он
RS> работает или конечного пользователя в случае если ему было сказано что
RS> на конфигурации ZWY модуль протестирован и работает, а вот на XYZ
RS> пробуйте на свой страх и риск.

Это и есть кривизна подхода. В винде драйвер, не использующий особенностей конкретных версий ядра, достаточно протестировать на минимальной версии, и он будет работать вплоть до максимальной. Я свои драйверы в основном тестирую только под базовой системой (раньше это была XP, теперь - семерка), и проблемы с новыми виндами возникают не чаще раза в несколько лет, да и то лишь потому, что драйверы используют ряд хаков для обхода системных косяков.

RS> По сравнению с типовой линковкой динамическое связывание более сложно

Э-э-э... Можно подробнее? Может быть, ты хотел сказать "типовой линкер уже есть, а динамическое связывание нужно написать"? :)

RS> Главное я думаю то, что "работает -- не трожь!"

Тогда зачем в ядро регулярно добавляют новые функции и оптимизируют старые? Оно ж и в прежнем виде как-то работало - зачем трогать?

RS> это просто давно используется, все к этому привыкли и менять никто не
RS> хочет. Что на мой взгляд правильно.

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

RS> Автомагически, всё автомагически. Так что конечный пользователь не
RS> видит ни сложности, ни неоднозначности.

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

RS> Ну где-то он ведь выкладывает свои исходники.

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

RS> "Не следует привлекать новые сущности без крайней на то
RS> необходимости".

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

RS> Вот динамическое связывание "чтобы было как в виндофс" и есть ненужная
RS> сущность.

Не "как в виндофс", а "как в пользовательском коде". Ну, или крестик снять, и снова все утилиты собирать на месте.

RS> А кто-то не умеет, зато умеет делать модули, которые автоматически
RS> собирает dkms. И этому кому-то хоть убей непонятно нафига делать
RS> какое-то динамическое связывание, когда вот так вот очень просто можно
RS> обеспечить простую перекомпиляцию модуля с изменением версии ядра при
RS> помощи dkms и это будет автоматически!

А если всем, кто делает пользовательский софт, сказать, что отныне они должны распространять его непременно в исходниках, и обеспечивать его безошибочную сборку с помощью какой-нибудь DUMS - им это будет понятно, или последуют споры и наезды? :)

RS> Я вот не умею ни драйвера для Windows, ни модули для Linux, я умел
RS> только драйвера для DOS и OS/2. Но dkms меня нисколько не напрягает.

Потому, что разработчики модулей берут на себя дополнительную работу сверх собственно разработки. Под виндой, кстати, такая работа тоже есть - подписывание драйверов. Но там хоть есть более-менее внятное (пусть и не идеальное) обоснование, а не просто "так заповедано древними!". :)

RS> Ну и пусть дальше сидят, насильно их никто на Linux не тащит.

Тогда для чего линуксы старательно двигают в user-friendly? Когда они были "только для гиков", те гики вроде особо не роптали.

Всего доброго!
Евгений Музыченко
eu-gene@muzy-chen-ko.net (все дефисы убрать)

--- GoldED+/W32-MSVC 1.1.5-b20170303