Открытые системы

Unix и не только

Интервью с Кеном Томпсоном

Сотрудники журнала Computer недавно встретились с Кеном Томпсоном в лаборатории Bell Labs корпорации Lucent Technologies, чтобы поговорить о первых работах Томпсона над Unix, и его самых последних исследованиях, связанных с распределенными вычислениями.

Кен Томпсон в представлении не нуждается: он был одним из создателей операционной системы Unix, а также распределенных операционных систем Plan 9 и Inferno. Вместе с Джозефом Кондоном Томпсон разработал Belle - чемпиона мира по шахматам среди компьютеров; Как и Деннис Ричи, в 1998 году он был награжден Национальной медалью США по технологии за создание системы Unix и языка Си.

Недавно за достижения в области распределенных вычислений Кену Томпсону была вручена премия Tsutomu Kanai Award, учрежденная Computer Society и Hitachi. По случаю этого события журналисты Computer посетили лауреата в лаборатории Bell Labs корпорации Lucent, чтобы побеседовать о его первых работах над Unix и последних проектах, связанных с распределенными вычислениями. Больше всего нас интересовало, как складывается творческий процесс в Bell Labs и мнение Томпсона о направлении развития компьютерной науки.

Творчество и разработка программного обеспечения

В публикациях, сопровождающих номинацию и вручение вам премии Kanai Award, ваши работы все время называются простыми, но мощными. Как вам удалось изобрести такие мощные средства?

Я сторонник «восходящего» мышления. Если вы дадите мне детский конструктор нужного размера, я могут представить себе здание. Я могу, глядя на простейшие детали, оценить возможность создания из них структур высотой в полмили, если только у меня будет возможность дополнить их функциональность.

И наоборот, я не могу, рассматривая здание, представить себе детали конструктора, из которых оно построено. Когда мне попадается «нисходящее» описание системы или языка, которое содержит бесконечные библиотеки, описывающие один уровень за другим, у меня возникает ощущение какой-то трясины. Представить себе это я не могу. Мне трудно понять, как все эти компоненты связаны друг с другом; я не в состоянии разобраться, когда мне предлагают некую сложную конструкцию. Возможно, простота моих решений объясняется тем, что я не могу создать ничего более сложного. На самом деле я обязательно должен разбить систему на более мелкие составные части.

В вашей группе, вероятно, есть сторонники как «нисходящего», так и «восходящего» мышления. Как же вы общаетесь и с теми, и с другими?

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

Время от времени, возможно, раз в пять лет, мне на глаза попадается статья, по прочтении которой я могу сказать: «Этот человек рассуждает не как обычные люди. Он мыслит в перпендикулярной плоскости». Когда попадаются такие люди, мне хочется встретиться с ними, прочитать их статьи, пригласить к себе на работу. Иметь человека с «перпендикулярным» видением какой-то задачи - всегда хорошо. Это помогает развивать идеи.

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

Парадигмы разработки программного обеспечения

В сетевых операционных системах Plan 9 и Inferno больше всего поражает согласованное и активное использование небольшого числа абстракций. Очевидно, что при работе над этими проектами существовало логически связное представление и реализовала его сплоченная группа. Не могли бы вы более подробно рассказать о том, как происходит сам процесс работы?

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

Что касается самого процесса, то описать его довольно сложно. Он несколько хаотичен, хотя время от времени дает некоторые результаты. Одним из таких результатов стала структура. Я вхожу в состав Computing Sciences Research Center, который представляет собой союз творческих индивидуальностей - никаких групп, никаких руководителей. Эта модель исследований давно принята в Bell Labs.

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

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

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

Вы упомянули о технических аргументах. Как вы поступили в вашем случае? Как было принято решение на основе этих технических аргументов?

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

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

Я думаю, существует не так уж много людей, способных предложить интересные идеи в отношении проблемы, с которой им никогда не приходилось сталкиваться. Вместо этого они говорят: «Попробуйте это сделать». Кроме того, в любом случае, самолюбие здесь ни при чем, так что в случае ошибки, вы можете вернуться и сказать: «У вас есть другая идея? Эта идея не работает». Безусловно мне самому приходилось предлагать плохих идей не меньше, чем хороших.

Что вы посоветуете разработчикам, которые хотят усовершенствовать свою архитектуру так, чтобы ее можно было назвать «простой, но мощной»?

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

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

К тому же я не уверен, что способность открывать нечто новое можно заменить какими-то реальными принципами: так случилось, что вам понадобилась некая функция прежде, чем кто-то еще понял, что она необходима. Способ, которым вы случайно получили то, о чем думали - это большая удача. Мой вам совет: будьте удачливы. Идите, купите подешевле и продайте подороже, и все будет прекрасно.

UNIX

Когда-то в одном интервью на вопрос, что бы вы изменили, если бы пришлось еще раз создавать Unix, вы ответили: «добавил бы букву e к системному вызову creat». А если серьезно, учитывая, что это все в прошлом, можете ли вы сказать, какие трудности вы преодолели, рассказать об оригинальных решениях и о том, что сегодня сделали бы по-другому.

Я думаю, что самое важное и замечательное качество в Unix состоит в том, что в ней реализован ясный и простой интерфейс: открыть, закрыть, прочитать и записать. Такой подход позволил реализовать shell, а также обеспечить переносимость Unix. В ранних системах ввод/вывод имел различные точки ввода, но с помощью Unix вы можете от них абстрагироваться. Вы открываете файл, и, если он оказался на ленте, можете в него писать. Каналы дали возможность использовать инструментальные средства и фильтры, которые позволили адаптировать классические громоздкие программы, такие как сортировка.

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

В Unix этой концепции нет; здесь была лишь одна группа интерфейсов типа открыть-закрыть-прочитать-записать. Это оказалось заметным упущением и послужило причиной появления в Unix таких неприятных вещей, как ptrace и некоторые из системных вызовов. Каждый раз, когда мне попадаются последние версии Unix, я обнаруживаю 15 новых системных вызовов. Я больше не обращаю на это внимания. Это уже было исправлено в Plan 9.

17.04.1999г

---

Также в разделе:

• OpenForum открытых систем
• Открытые системы сегодня
• Аpхитектуpа T-SPACE
• Дума о миграции
• Поколение NT графические станции SGI и Intergraph
• Межсетевой экран Aker
• Компонентные технологии в системах промышленной автоматизации
• Управление информационными системами: базовые концепции и тенденции развития
• Из истории автоматизации методологий управления предприятия
• Связывания для объектных языков
• Снова о объектных СУБД
• Краткая история страны хакеров
• Unix с погружением
• Использование и администрирование PPP