Мнение Linus'а о Kernel Debugger

Дааа ужж
самомненьице у Линуса - дай бог
и самокритика тоже :)
Холодный нордический характер

А помоему он просто дурак. kdb не нужен потому что заставляет kernel guys думать больше.. офигенный довод.

А по моему что-то в этом есть.

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

Несмотря на некотрые заскоки (типа называния себя ублюдком) сермяжная правда в его письме есть. Вот тут один про повышение производительности труда написал ... :-/, а на кой она нужна в этом деле. Я не отрицаю дебугер нужен, но автоматизация процесса сильно вредит голове. Здесь он прав. Хотя бастардом себя зря назвал :-(.

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

Даже мне стало интересно, посмотреть на тех придурков, которые называют таковым, чела который, сделал весь этот проект, плодами которого, я надеюсь они не пользуются, поскольку у них нет kdb.

Нет, господа. Как это часто случается, в великом и могучем нет точного
эквивалента для такого простого слова, как "bastard". А в данном контексте
я бы перевел его как комбинацию понятий "твердолобый", "бессердечный", "упрямый как осел".

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

> Линус отлично знает тот_тип_людей_который_жить_не_может_без_дебаггеров
Что именно в дебагерах, а вернее в их использовании такого плохого?
> Он знает, что можно ждать от кода, написанного этими людьми.
Что же от такого кода можно ожидать?

Ну, ну, настоящий программист не пользуется отладчиком. Отладчик для людей не уверенных в себе ... Так что-ли ? Где-то я уже это слышал :-)))) И не надо ля ля про то, что для кернел-девелопмента повышение производительности труда не нужна. Нужна еще как. Глюков в ядре километр и от того, что kdb не будет - их меньше не станет. Просто линус начинает понимать, что теряет контроль над исходным кодом ядра. Ведь он и только он принимает окончательное решение о том, какие патчи мержить в основной codeline, а какие нет. Систему надо менять(не операционную конечно :-))) и тестить лучше, а не пытаться ограничить активность девелоперов таким вот ламерским способом. А противникам kdb скажу - такие как они пару сотен тысяч лет назад говорили - ну нахрена нам эти новомодные зубила каменные, руками оно как-то понадежнее будет ... :-)))

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

С чего вообще начался базар про kernel-debugger? Я имею ввиду не здесь,
а в lkml. C проститутки Jeff'a Merky. Этого клоуна в натуре. Вот таких блядей Линус
и не хочет пускать в ядро.

IMHO Линус совершенно прав. Вместо того, чтобы писать стилистически
чистый исходник, люди с отладчиком просто подгоняют код под рабочее
состояние. А кончается это тем, что программа оказывается
непортируемой и неоптимизируемой.
Аминь

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

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

Дебагеры не нужны, потому как они вредны глобально, хотя и полезны локально. Приучаться себя надо правильно мыслить, держать в голове все особенности алгоритмов, чтобы самому логически найти ошибку. Если сможешь без отладчика работать, то производительность труда возростёт существенно. Хотя да, бывает, некоторые моменты поймать в отладчике проще, это и есть локальная полезность. Но мыслыть надо глубже, ширее, глобальнее.

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

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

Вот тогда его нежелание отлаживать имело бы под собой нечто реальное.
А что мы имеем "по ходу жизни"? А имеем мы горы исходных текстов, на которые
нет никакой документации высокого уровня. Я имею в виду не описания входа/
выхода системных вызовов, для этого есть man(2), а общую архитектурную схему
ядра. И сам Линус пока что не спешит этой структурной информацией делиться,
многие же книги типа "The Linux Kernel" (David A. Rusling) написаны третьими
лицами и уже устарели.

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

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

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

Обидно, что в мире свободного ПО этого пока еще не осознали.

--
Сергей Короп, skor@dux.net

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

По поводу дебаггеров: читал я где-то (вроде в Communications of the ACM) исследование о причинах багов у опытных программистов.
Было выделено семь основных причин ошибок:
#1 - Неправильная модель причинно-следственной связи в голове программиста;
#2 - Ошибки, вносимые либо непосредственно отлачиком, либо по причине его использования.
И заметьте: глядя на код больших проектов, писанных грамотными людьми, процентах в 90 случаев вы увидите макросы записи логов/трассиировки за #ifdef DEBUG. Видимо, не спроста у них это основное отладочное средство.
По своему скромному опыту могу сказать что визуальный дебаггер чаще отвлекает чем помогает: можно пол часа нажимать step forward и таращиться на на watches, в то время как проблема быстрее находится умозрительным экспериментом или бисекцией кода printами.

Насчет #ifdef DEBUG - это все-таки наверно не для отладки самими программерами, а для того, чтобы пользователь, обнаруживший багу, мог перекомпилять софт (или если уже) пустить в режиме отладки и получить качественный log о том, когда и почему эта бага проявилась. Насчет отладчиков - IMO пусть лучше они будут (и в ядре в частности). Когда часов 10 чего-то отлаживаешь, отладчик в голове дает сбои, поэтому лучше иметь и хорошие инструменты. Это все равно что не ставить лифт в 9-ти этажном доме по причине - типа "современный человек должен иметь физическую нагрузку чтобы не одряхлеть" - ставить надо, кто захочет, тот и так будет ходить пешком. И не надо забывать, что ядро - это не только система виртуальной памяти и системных вызовов - это епще и драйвера, которые работают с жезезом. Как вы прикажете отлаживать драйвера для железа которое криво документировано - просто компилять, пускать, падать до тех пор пока не будет падать? Нафиг такой геморой? Не вижу причин не включать в ядро дебагер, тем более что он уже существует, если я не ошибаюсь (от SGI?). А на Линуса уже многие наезжают (ESR например) - типа ламер - не использует cvs, testsuites, отладчики - его сравнивают с очень мозгастым студентом, который по причине своих хороших мозгов не занимается учась в институте, и в итоге по причине нехватки опыта/знаний просто проваливает экзамен в институте. Да и вообще - надо поднимать вопрос о том, нужно ли всецело доверять Линусу решения проблем того, что идет в ядро а что нет. Может, просто надо начать свою ветвь ядра (тоже GPLed) - лицензия позволяет.

to anonymous (2000-09-11 20:05:18.0):

> Тут кроме общих фраз кто-то скажет нечто конкретное, или этот тупой
> флем продолжится?

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

Хватит искать врагов, которые мешают программировать без ошибок.
Уже было: запретить goto плюс структуризация всей страны. А толку?
Почитайте Н.П. Брусенцова, "Микрокомпьютеры", книга старая, но про
глюки структурного программирования (как его понимают сторонники подхода
Боэма-Джакопини) там написано достаточно хорошо.

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

А разруха не в сортирах, она в головах. (Ф. Ф. Преображенский)

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

--
Сергей Короп, skor@dux.net

to Сергей Короп и все все все формалисты :) Очень хотелось бы услышать про формальные методы доказательства правильности _готового кода_ , а не алгоритмов. Потому как алгоритм и исходник его реализующий - вещи разные...

to anonymous (2000-09-12 16:54:08.0) > Потому как алгоритм и исходник его реализующий - вещи > разные... Нужно пользоваться системами программирования, где это одно и то же. Что касается верификаторов программ, ищите, скажем, информацию по LCLint и другим системам. Это не совсем верификаторы в строгом понимании, но для примера сойдет. -- Сергей Короп, skor@dux.net

Вообще-то верификация как раз является доказательством соответствия КОДА документированному поведению (декларативно описанному алгоритму).

Еще о "других системах"

www.research.digital.com/SRC/esc/

в Modula-3 автоматическими анализаторами занимались неплохо.

--
Сергей Короп

> Вообще-то верификация как раз является доказательством соответствия
> КОДА документированному поведению (декларативно описанному
> алгоритму).

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

Но для ФП в-общем то, спецификация зачастую и есть программа.

--
Сергей Короп.

*Полная* верификация кода невозможна. Даже теоретически.

ну с ФП и прочим понятно, но на чём писать и под что писать не я выбираю а работодатель, а потому интересует как это приложимо к тем же сям, сям++, яве. ЗЫ: а где на подобные темы можно было бы пообщаться без влетания в оффтопик ? а то уже из ру.линукс поперли :) ЗЗЫ: http://www.research.digital.com/SRC/esc/ - Forbidden

to Viking:
> *Полная* верификация кода невозможна. Даже теоретически.

Пожалуйста, обоснование. Можно мылом.

--
Сергей Короп. skor@dux.net

to anonymous (2000-09-13 11:21:27.0)

> приложимо к тем же сям, сям++, яве.

пишите, кое-что может и найду

> http://www.research.digital.com/SRC/esc/ - Forbidden

Да, похоже и там вебмастер никакой. Попробуйте

www.research.digital.com/SRC/esc/Esc.html


--
Сергей Короп, skor@dux.net

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

Прозрачное замечание: Линус по-своему прав, протестуя против
дебагеров. За последние годы ими (с подачи M$) стали злоупотреблять
(особенно в свете RAD технологий). Очевидно, что человек, привыкший
левой ногой ваять программы на visualXXX, не сможет без дебагера
написать работающую программу, а для настоящего программиста
отсутствие дебагера не фатально, по крайней мере.

Все же, дебагеры часто помогают в жизни. IMHO, единственная
возможность написать "грамотный" bug-report при наличии исходника
состоит в его (исходника) быстрой трассировке. Я, например, много раз
занимался подобными вещами. Мои фиксы есть и в MC, и в aterm'e, и еще
во многих GNUтых прогах. Без дебагера такое было бы невожможно.
А если бы у меня был kernel дебагер, то я не пожалел бы недели-двух,
чтобы найти, почему иксы иногда меня вешают (я даже примерно знаю,
где).

to Viking:
> > Пожалуйста, обоснование.
> Для машины Тьюринга не существует алгоритма, который, имея на входе
> программу, мог бы за конечное время
> дать ответ: будет ли данная программа исполняться бесконечно или нет.

Хм, действительно такая теорема где-то мне встречалась. Но тем не менее,
доказать конечность отдельно взятого алгоритма возможно, придумав для него
функцию декремента (думаю, примеры приводить не нужно?).

Что же касается чисто теоретического вопроса, то пользуются же теоремой
Эрбрана как обоснованием теоретической возможности автоматического
доказательства теорем, хотя процесс генерации подстановок можно продолжать
бесконечно.

Кстати, предложение: давайте эту тему продолжим мылом, а то начинается
оффтопик.

--
Сергей Короп, skor@dux.net

> Нужно пользоваться системами программирования, где это одно и то же. Исторически, ядро Linux (а ведь именно про это был разговор) написано на C + ASM, разве не так? А Cи и Ассемблер (тем более) - не из тех языков, которые способны в точности выразить человеческую мысль. Поэтому можно поставить под сомнение вопрос о существовании подобной системы программирования.

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

Языки программирования, верификация - offtopic.

The theorem mentioned, a.k.a. "the Halting problem", or, "Termination problem" belongs to NP class. Which means, "..there is no formal proof yet that given any input, we will be able to get output in polynomial time". Po russki: dannaya problema ne reshena.

Может я конечно чего-то не понял, но существует доказательство несуществования алгоритма, решающего "halting problem". или реч не об этом?

> Po russki: dannaya problema ne reshena.
Данная проблема решена - за конечное время получить ответ невозможно, так что NP здесь не при чем.
Это ограничение формализма Тьюринга. С тем же успехом можно пытаться доказывать аксиомы евклидовой геометрии.
2 maxcom: эту теорему в свое время доказал Тьюринг.

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

Например можно почитать КАУФМАН В.Ш. "ЯЗЫКИ ПРОГРАММИРОВАНИЯ концепции и принципы" Или/и просто, в свободное время, зайти на algo.4u.ru и почитать там раздельчик про компиляторыю Познакомиться с идефми Фон-Неймана, Бэкуса, Маркова или прочитать пару книжек Дейкстры (не говоря уже о Кнуте)<p> Выше было кем-то сказано, что пока программисты не будут иметь фундаментальной мат. подготовки - будет бардак. Возвращаясь к вопросу о дебагерах, я полагаю, что вешь эта нужная и во многих случаях помогает (особенно, если у вас нет документации на код, а программу надо фиксить). Однако качественный анализ кода в "голове" позволяет исключить "лишние скачки" в дебагере. Таким образом, я полагаю, что разумнее всего использовать комбинацию дебагер+голова(на плечах) ;))

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

to anonymous 2000-09-29 12:37:49.0

> Да откуда эта дурость вообще взялась про то, что программисту
> нужна фундаментальная математическая
> подготовка? Что вы понимаете под программистом?

Я подразумеваю под "программистом" Дональда Кнута, Сеймура Крея,
Джона Мак Карти и многих других, а вовсе не в Делфях иконки таскать.
Как показывает опыт, объяснить, зачем нужна математика программисту,
невозможно, требуется набить множество шишек на собственной голове.
Не буду разводить оффтопик, просто почитайте "Искусство
программирования для ЭВМ".

--
Сергей Короп, skor@dux.net

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

> Я подразумеваю под "программистом" Дональда Кнута, Сеймура Крея

То, что ты подразумеваешь, на этой бренной Земле находится в количестве
до 1000 человек. Что делать остальным?

Вы тут всё о каких-то высоких материях рассуждаете, а я ни как в толк не возьму, разве Linux разрабатывают люди типа Кнута или Дейкстры? Вы комментарии в коде ядра вобще читали? Очень рекомендую. Кстати, а почему Linux так не уважаем среди других Unix? Почему код вдруг не совсем портабельным оказался при смене версии gcc? Может для начала стоит вспромнить о CVS, о нормальной документацие... а уж затем о дебагере и о том как его проектировать? Нельзя же с дерева спрыгнуть и сразу на банкет.

> Почему код вдруг не совсем портабельным оказался при
> мене версии gcc?

на самом деле это наезд не в тему - непортабельным оказался
вовсе не весь код ядра, а архитектурно-зависимая часть поддержки
i386, написанная на GNU AS. И непортабельной она оказалась
именно по вине старых версий as из gnu compiler collection.

Эх, ну как здесь обойтись без оффтопика? Sorry, All (персональное sorry
за оффтопик --- лично Максиму), но все же:

to anonymous (2000-09-29 19:21:09.0):
> Я и без книжек могу сказать, что выдвинутая теорема о матподготовке
> доказуему лишь с противоположной по смыслу формулировкой.
> Математика абсолютно вредна для программиста

Вы уж извините, мистер Икс, за прямоту, но в не столь давние времена
рабочие и колхозницы писали в газету "Правда": "Я этого Пастернака не читал,
но осуждаю". Очень подозреваю, что с математикой Вы знакомы в лучшем случае
на уровне общеобразовательной программы ВУЗа и не очень желаете продвигать
свой уровень образования. Сожалею, но продолжать с Вами дискуссию на эту
тему без конкретных аргументов с Вашей стороны полагаю бессмысленной.

to anonymous (2000-09-29 19:25:49.0):
>> Я подразумеваю под "программистом" Дональда Кнута, Сеймура Крея
> То, что ты подразумеваешь, на этой бренной Земле находится в количестве
> до 1000 человек. Что делать остальным?

Остальные (к которым я причисляю, к своему сожалению, и себя) суть то, что
сказал однажды А. П. Ершов: "солдаты Второй промышленной революции", то есть,
если называть вещи своими именами --- расходный материал. Тем, кого такая роль
устраивает, я в чем-то завидую --- у них в жизни меньше проблем.
Но плох тот солдат, который не мечтает стать генералом. Не каждому дано
достичь такого уровня, как упомянутые выше персоны (мне --- вряд ли удастся),
но я не понимаю упорного нежелания хотя бы сделать такую попытку. И упорная
приверженность разработчиков ядра Linux не самым лучшим на сегодня методам
разработк программ тоже мне непонятна. Потому я собственно и влез в этот
флейм, жаль, что почти бестолку.

--
Сергей Короп.

Я не рабочий и не колхозница, а просто терпеть не могу беспочвенных утверждений, тем более транслируемых на массовую аудиторию. Типа того, что "настоящий программист должен...". Я знаю абсолютно точно, что 80-90% программистов крайне нуждаются в знаниях бухгалтерии - отрасли, где они являются наиболее востребованными. И именно этих знаний они получают меньше всего (если получают вообще) в наших долбаных институтах. В какую задницу засунуть вашу любимую математику, я лично не представляю.

to anonymous (2000-10-02 12:31:15.0):

> просто терпеть не могу беспочвенных утверждений, тем более транслируемых
> на массовую аудиторию.

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

Итак:

> Я знаю абсолютно точно, что 80-90% программистов крайне нуждаются в
> знаниях бухгалтерии - отрасли, где они являются наиболее востребованными.
> И именно этих знаний они получают меньше всего (если получают вообще)

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

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

--
Сергей Короп.

Такие задачи с успехом решали наши прабабушки и прадедушки одной лишь арифметикой. И очень быстро решали. Посмотрите в задачник образца 1907 года. Там много подобных задач.