Re: Проверить на наличие железяки
On Thu, 22 Sep 2016 13:08:44 +0300
Eugene Berdnikov <bd4@protva.ru> wrote:
> Чтобы написать, много чего ещё нужно. Монитор, клавиатура, культурный
> слой (умение читатать, знание того что такое алгоритм и т.д.).
> Вот только писателей софта едва ли 1/10 от числа пользователей
> (скорее даже меньше 1/100). Так что не надо точку зрения
> программистов выдавать за абсолют за всех. Удивитесь тому, что на в
> мире есть очень много людей, и всех очень разные шкалы ценностей.
> Взгляды на то, что такое свобода тоже сильно различаются, в том числе
> по отношению к ПО.
Пару сотен лет назад Иван Андреич Крылов написал басню "Свинья под
Дубом". Я как раз про то, про что написано в этой басне.
Если тебе, персонаж басни, не нужна свобода, а нужны только её плоды,
не следует пытаться продемонсттрировать что ты лучше того меньшинства,
которому эта свобода нужна. Потому что твои желуди, которыми ты
питаешься, вырастают благодаря им.
Моя претензия в первую очередь к тем, кто гордится своим нежеланием
знать. Не знаешь - молчи в тряпочку. А не пытайся доказать другим, что
знать и не надо.
> > > Понимать при этом, что там этот софт делает -- по большей части
> > > не является необходимостью. Например, занимаясь сопровождением
> > > почтовых систем уже два десятка лет, я довольно поверхностно знаю
> > > протокол IMAP. Потому как нужды в ПОНИМАНИИ его нет, то есть
> > > она мне и даром не нужна, эта свобода. Хотя кому-то может быть
> > > интересно изучать IMAP по исходникам, например, imapsync'а.
> >
> > Это очень странно. Я вижу две странности.
> >
> > 1. Двадцать лет работать с imap-ом и так и ни разу не пообщаться с
> > imap-сервером при помощи телнета. Там же все настолько текстовое и
> > понятное.
>
> Ну вот расскажите нам, как понять что такое UIDVALIDITY, глядя лишь
> в протокол сессии IMAP и не прибегая к RFC. Разумеется, перевод слова
> "validity" и что скрывается за аббревиатурой UID будем считать
> известным. Изложите логическую последовательность, с удовольствием
> почитаю.
[skip]
> > 2. Вспомнив о необходимости изучать протокол, почему-то подумать об
> > изучении его не по RFC (хотя там все понятным английским языком
> > написано, и не нужно иметь двадцатилетний опыт работы в IT, чтобы в
> > нем разобраться - я его прочитал и понял еще году в 96, примерно
> > через год после начала использования Linux), и даже не по
> > исходникам reference implentation, каковой является pine/alpine и
> > uw-imapd, а по исходникам imapsync. Это из серии "Рабинович по
> > телефону напел".
>
Так, похоже ты разучился понимать не только сложные концепции из
области IT, но и текст, написанный по-русски. Я пишу, что главная
странность в том, что ты предлагаешь изучать IMAP по исходникам
imapsync а не по RFC, а ты мне начинаешь возражать, что понять IMAP
путем только эксперементов telnet-ом нельзя, надо читать RFC.
> Тогда о каком "понимании" речь в словах "главная свобода во free
> software - это свобода ПОНИМАТЬ что твой компьютер делает"? Вы вообще
> что хотите понимать в работе программы? Скажите конкретно. Скажем,
> если интересуют системные вызовы и их параметры -- для это исходники
> не нужны, в юниксах есть strace/truss/tusc и т.п. утилиты для этого,
> можно дебаггерами решить эту задачу. Как для опенсорца, так и для
> проприетарного софта.
Нельзя решить задачу понимания логики поведения даже конкретной
программы только дебаггером. Потому что никогда у тебя не хватит ни
времени, ни воображения для того, чтобы написать такой test suite,
который вызовет срабатывание обоих веток в каждом условии.
Конечно, иногда дебаггер помогает разобраться в нетривиальном поведении
чужого кривого кода. Но вообще есть эмпирическое правило - если тебе
понадобился дебаггер, т.е. ты не смог понять, что делает код, путем его
чтения, то код, с которым ты работаешь, крив. Если это твой код - выкинь
и перепиши сначала. Прямой код при чтении дает больше информации чем
при пошаговом прогоне, потому что читатель видит все особые случаи и
реакцию на них. А нормальная программа состоит из обработки особых
случаев вообще процентов на 95.
А чтобы понять что делают системные вызовы нужна единственная утилита -
man. А вообще для этого лучше APUE читать. Но, к сожалению, иногда
оказывается, что системные вызовы ведут себя не так, как написано у
Стивенса, а реализации протоколов - не так, как описано в RFC. И тогда
приходится лезть в их код.
>
> Прежде всего, изучать какую-то область я не начинаю с чтения софта.
А из твоего предыдущего письма можно было сделать строго
противоположный вывод. Что ты рекомендуешь изучать imap по исходникам
imapsync.
IMAP - это образцовый вариант, когда так делать не надо. Есть внятный
RFC, есть возможность поиграться с протоколом интерактивно, есть
reference implementation, есть хорошо документированные библиотеки для
различных языков программирования.
Но существуют ситуации когда кроме исходников читать больше
нечего. Вот, например, с чего ты порекомендуешь изучать функционирование
bluetooth-подсистемы в Linux? А использование виджета spice-клиента для
доступа к виртуальным машинам?
И, к сожалению, именно подход "дайте мне
магическую хрень, которая сделает все что нужно сама", провоцирует
создание именно такого софта. Когда экономят на документации, экономят
на удобочитаемости кода из соображений "а, все равно никто разбираться
не будет, все будут использовать как есть".
--
Reply to: