— The tinydrm code seems like absolute pure shit that has never seen a compiler. I'm upset, because I expect better quality control. In fact, I expect *some* qualitty control, and this piece-of-shit driver has clearly seen none at all.(tinydrm выглядит как рафинированное дерьмо, которое никогда не пропускали через компилятор. Я зол, поскольку ожидаю куда лучшего контроля качества. Да пусть хоть какого-то контроля, в то время как этот кусок говнокода очевидно вообще никак не тестировался).
Сборка присланного кода компилятором сопровождалась десятками предупреждений и завершалась ошибкой, изучение которой показало, что код не собирается если модуль backlight собирается в виде отдельного модуля (CONFIG_BACKLIGHT_CLASS_DEVICЕ=m), а не как часть ядра. Также Линус указывает на то, что патч отправлен в ядро буквально на следующий день после получения его мейнтейнером, что уже само по себе говорит о качестве тестирования если бы даже оно проводилось.
В качестве временной меры Торвальдс предлагает патчи для DRM модулей отправлять предварительно в ветку linux-next и только потом, после внимательных тестов, позволять им входить в основной состав ядра.
Источник
Комментарии (23)
foxin
27.02.2017 17:01+10Уровень перевода — просто полный абзац. Абсолютно не передает то, что сказал Линус. имхо.
red75prim
27.02.2017 18:15+7Я бы перевёл как:
Код tinydrm — отборнейшее говно, никогда не видевшее компилятора. Я разочарован, поскольку ожидал лучшего контроля качества. Вообще-то, я ожидал хоть какого-то контроля качества, а этот дерьмовый драйвер явно обошёлся без него.
Но смысл был более-менее передан.
lutc
27.02.2017 17:01-2ОфтопКакой у вас ник интересный :)
Equin0x
28.02.2017 01:23+25В резюме Эйрли добавится строчка «Проект был особо отмечен Линусом Торвальдсом» )
poxvuibr
28.02.2017 09:07+6В качестве временной меры Торвальдс предлагает патчи для DRM модулей отправлять предварительно в ветку linux-next и только потом, после внимательных тестов, позволять им входить в основной состав ядра.
Предложил, это интересно сказано
And reghardless of what happens this merge window, I will instate a
hard rule that the DRM code needs to be in linux-next before the
merge window opens. No last-minute crap. No shit that hasn't even
been build-tested.Перевод.
И независимо от того, что случится в текущем окне слияния, я введу неукоснительное правило, что код DRM должен быть в linux-next до того, как откроется окно. Никакой дряни в последний момент. Никакой хрени, которая даже не прошла тест на сборку.
Хотел бы я так предложения вносить.
bapcyk
28.02.2017 09:48Одно время работал на одну сверх-известную компанию, в частности писали драйвера и тп. Сам я в кернеле почти не работал, но расскажу два прикола, связанные с ним (патчи уходили в ядро, даже есть официально принятый драйвер моего коллеги). Прикол раз: нашел в одном файле захардкоденную стринговую константу. И в совершенно другом захардкоденный int — ее длину. Прикол два: в одном драйвере нашли баг, который адски редко проявляется. И там какой-то не то спин, не то for — ожидание "ресурса", что-то такое. Фикс из испанского офиса был — вместо тысячи циклов сделать десять тысяч. Баг закрыли. Однако, через пол-года тестеры его опять открыли. Следующее закрытие с фиксом — сделать сто тысяч циклов.
Не буду называть имена компаний, но они на слуху во всем мире и они много коммитят в кернел и пишут драйвера для своих устройств. Мой вывод был — код линукса чудовищно непрофессионален, его нельзя использовать в критичеспих местах, пишут школьники, студенты, основной мотив — лишь бы была хоть какая-то, пусть условная поддержка того или иного оборудования. В реальности линукс безнадежно отстает от современного оборудования, его практически нельзя использовать на современных ноутбуках. Хотя сам предпочитаю его, но....Lampus
28.02.2017 10:14+7Я немного в другой области работаю, но могу сказать одно: лучше просто не знать что наворочено внутри любого коммерческого закрытого продукта, а иначе про спокойный сон можно забыть.
Ключевое преимущество ядра Linux в данном случае (как и любого другого открытого/свободного продукта) — это возможность найти причину неполадки и исправить её самостоятельно. Да, для этого нужен определенный уровень, да, мало кто этим станет заниматься. Но сама возможность — это уже много.
Приведу пример «сбоку». Мне приходится работать с дорогущими проприетарными САПР и, как по мне, там просто адский ад. Куча глупейших багов и проблем, тикеты на которые висят годами.
Однажды мне пришлось перехватывать вызов unlink с помощью подключения самописной so-шки через LD_PRELOAD, чтобы посмотреть содержимое временных файлов с нетлистами из-за которых падала симуляция. Посмотрев в то, что генерит эта софтина, я ужаснулся содержимому, нашёл причину проблемы, сделал не менее жуткий костыль и в итоге всё завелось. Но мой тикет пофикисили только через пол года, и то не полностью.
Так что альтернатив Linux я пока просто не вижу. Если там что-то не работает, то хотя бы можно докопаться до истины.Ivan22
28.02.2017 12:45+1Согласен! Чем больше работаешь с системой X тем лучше узнаешь о её багах и костылях.
Крупных, сложных систем без багов просто не существует в природе.
Как говорится «здоровых нет — есть недообследованные»
Aingis
28.02.2017 15:03+1Если вы используете проприетарный софт, и нашли баг, критичный для бизнеса, всё что вы можете сделать: отправить заявку и надеяться, что его исправят.
Плюсы: если софт не дохлый, то есть отряд платных фулл-тайм программистов, исправляющих баги, и, если сойдутся звёзды, баг исправят.
Минусы: ресурс фирмы-разработчика ограничен, а багов, скорее-всего, много. Можно долго ждать, пока ваш баг исправят. А если для этого надо переписывать полсистемы, то пиши-пропало. Деньги вы платите независимо от того, исправят баг или нет.
В случае открытого ПО вы можете сами посмотреть исходный код и сделать нужные вам модификации.
Плюсы: вы независимы и контролируете процесс. Вполне вероятно, что многие другие баги уже исправлены другими пользователями ПО, а решения многих проблем уже где-то описаны.
Минусы: затраты на разработку и поддержку. Могут быть сложности с синхронизацией с основной кодовой базой. Дорабатывать софт под ваши нужды нужно самостоятельно.
rstar
28.02.2017 10:01+7Прямота Линуса — третья вещь, за которую мы его так любим.
tangro
28.02.2017 12:23+3В общем-то во многом благодаря именно ей живут и развиваются первые две. Другой бы закрыл глаза, шел бы на компромисы, старался бы не ссориться с людьми. А тут нет, если код — дерьмо — так и пишем «код — дерьмо».
osiraben
28.02.2017 17:09-1А тут нет, если код — дерьмо — так и пишем «код — дерьмо»
Меня так с работы уволили.
Спойлер.Шутка.
Thero
01.03.2017 12:29так-то всё нормально, просто никому из ментейнеров тестивших тинидрм не пришло в голову собирать не монолит…
потому что на тех нескольких девайсах для которых он написан модуль всёравно не сработал бы поидее опции модуля там вообще не должно было быть…poxvuibr
03.03.2017 08:32так-то всё нормально
Ну не совсем так. Дальше Линус продолжил
… and a slightly less annoying piece of crap in this pull request:
that "PRIME_NUMBERS" config thing is utter garbage too.перевод вроде не нужен, но тем не менее
… и немного менее неприятный кусок шлака в этом пулл реквесте это момент конфигурации с "PRIME_NUMBERS" который тоже явно мусор-мусором.
Laney1
если Торвальдс ругается не по-фински — значит ничего критически важного, дело житейское))
A-Stahl
Чтобы Торвальдс начал ругаться на финском в общей рассылке нужно как минимум чтобы на Луне появился лик Таненбаума а демоны подняли веки GNU Hurd`у
past
Есть подозрение, что Торвальдс в критические моменты ругается по-шведски.
Elmot
..., а по-фински когда уж совсем ни в какие ворота.
gearbox
скорее речь о том что шведский это финский аналог английского французского (https://en.wikipedia.org/wiki/Pardon_my_French)
felix_it
Справедливости ради: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg467322.html — вот тут некая perkeleen vittupaa за 2013 год.