= Сообщение: 4204 из 8555 ========================================= RU.LINUX =
От : Eugene Muzychenko 2:5000/14 22 Apr 17 10:02:12
Кому : Rinat H. Sadretdinow 22 Apr 17 10:02:12
Тема : Совместимость ядер и ядерных модулей
FGHI : area://RU.LINUX?msgid=2:5000/14+58fac7b6
На : area://RU.LINUX?msgid=2:5020/620+58fa72ae
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.LINUX?msgid=2:5020/620+58fb0d2d
==============================================================================
Привет!
21 Apr 17 23:35, you wrote to me:
RS> Hо, пардон муа, что там может быть неправильно? Если команда `dnf
RS> update` сама всё делает и если апдейт идёт из доверенного источника
RS> возможность автоматического `dnf update` 100 раз проверена и
RS> перепроверена?
Ты ж вроде программированием немного занимался, должен бы понимать. :) Если написать скрипт из трех строчек, вызывающий команду xxx, то надежность работы этого скрипта в основном будет определяться не этими тремя строчками, а командой xxx.
При обычном обновлении используются _готовые_ компоненты, которые тупо копируются. При обновлении из исходников используются _рецепты_зготовления_ компонент, и это изготовление заново происходит при каждом обновлении, а сложность этого процесса на несколько порядков превосходит сложность простого копирования. Во столько же раз выше и вероятность ошибки.
Допускаю, что на текущий момент уже более-менее научились делать модули так, чтобы они собирались новыми версиями компиляторов, а компиляторы - чтобы не ругались на подозрительные конструкции, которые по-хорошему надо обозначить хотя бы предупреждениями. Hо поначалу в таком процессе косяки должны были возникать регулярно.
RS> Hикто их не заставляет компилировать руками, всё автомагически.
У меня претензии к самой необходимости компиляции, а не к ее оформлению.
RS> Так же как и Microsoft не гарантирует (пруфы сейчас не помню, но ведь
RS> были же случаи когда Microsoft отзывал свои апдейты или в срочном
RS> порядке выпускал апдейты для упавших два-три дня назад апдейтов,
RS> образно говоря валивших систему).
Так за это целиком и полностью отвечает Microsoft. А если чей-то модуль вдруг не собрался при обновлении у юзера, но успешно собирается у разработчика? Подозреваю, что такие проблемы под линуксами приходится решать юзеру.
RS> В данном случае или головная боль разработчиков модуля, которые не
RS> протестировали его на конфигурации XYZ, но заявили что на XYZ он
RS> работает или конечного пользователя в случае если ему было сказано что
RS> на конфигурации ZWY модуль протестирован и работает, а вот на XYZ
RS> пробуйте на свой страх и риск.
Это и есть кривизна подхода. В винде драйвер, не использующий особенностей конкретных версий ядра, достаточно протестировать на минимальной версии, и он будет работать вплоть до максимальной. Я свои драйверы в основном тестирую только под базовой системой (раньше это была XP, теперь - семерка), и проблемы с новыми виндами возникают не чаще раза в несколько лет, да и то лишь потому, что драйверы используют ряд хаков для обхода системных косяков.
RS> По сравнению с типовой линковкой динамическое связывание более сложно
Э-э-э... Можно подробнее? Может быть, ты хотел сказать "типовой линкер уже есть, а динамическое связывание нужно написать"? :)
RS> Главное я думаю то, что "работает -- не трожь!"
Тогда зачем в ядро регулярно добавляют новые функции и оптимизируют старые? Оно ж и в прежнем виде как-то работало - зачем трогать?
RS> это просто давно используется, все к этому привыкли и менять никто не
RS> хочет. Что на мой взгляд правильно.
В таком случае, правильно было бы каждому юзеру полностью собирать себе из исходников всю систему целиком, как это практиковалось в старых унихах, а не только ядро. И не пользоваться загружаемыми модулями вообще - раньше ведь их не было, и к этому за много лет тоже все привыкли.
RS> Автомагически, всё автомагически. Так что конечный пользователь не
RS> видит ни сложности, ни неоднозначности.
И что, на тысячу таких сборок даже одной ошибки не возникает? Или у тебя попросту нет глобальной статистики?
RS> Hу где-то он ведь выкладывает свои исходники.
Многие выкладывают исходники на бесплатных ресурсах, которые имеют свойство закрываться, менять формат, перемещаться на другие домены и т.п. Пока это просто готовый файл с известным именем/описанием, он легко находится поисковиками. Как его будут находить сборочные службы?
RS> "Hе следует привлекать новые сущности без крайней на то
RS> необходимости".
Ты готов отвечать за то, что в современном линуховом ядре каждая сущность обоснована именно _крайней_ необходимостью, и без нее категорически невозможно было бы поддерживать систему в нынешнем состоянии? :)
RS> Вот динамическое связывание "чтобы было как в виндофс" и есть ненужная
RS> сущность.
Hе "как в виндофс", а "как в пользовательском коде". Hу, или крестик снять, и снова все утилиты собирать на месте.
RS> А кто-то не умеет, зато умеет делать модули, которые автоматически
RS> собирает dkms. И этому кому-то хоть убей непонятно нафига делать
RS> какое-то динамическое связывание, когда вот так вот очень просто можно
RS> обеспечить простую перекомпиляцию модуля с изменением версии ядра при
RS> помощи dkms и это будет автоматически!
А если всем, кто делает пользовательский софт, сказать, что отныне они должны распространять его непременно в исходниках, и обеспечивать его безошибочную сборку с помощью какой-нибудь DUMS - им это будет понятно, или последуют споры и наезды? :)
RS> Я вот не умею ни драйвера для Windows, ни модули для Linux, я умел
RS> только драйвера для DOS и OS/2. Hо dkms меня нисколько не напрягает.
Потому, что разработчики модулей берут на себя дополнительную работу сверх собственно разработки. Под виндой, кстати, такая работа тоже есть - подписывание драйверов. Hо там хоть есть более-менее внятное (пусть и не идеальное) обоснование, а не просто "так заповедано древними!". :)
RS> Hу и пусть дальше сидят, насильно их никто на Linux не тащит.
Тогда для чего линуксы старательно двигают в user-friendly? Когда они были "только для гиков", те гики вроде особо не роптали.
Всего доброго!
Евгений Музыченко
eu-gene@muzy-chen-ko.net (все дефисы убрать)
--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: Fox Tracks, Novosibirsk, Russia (2:5000/14)
|
