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 и мнение Томпсона о направлении развития компьютерной науки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UNIX

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

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

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

Я позаимствовал только одно: иерархическую файловую систему, различие состояло в том, что Multics была системой виртуальной памяти и эти «файлы» были не файлами, а своеобразными правилами именования сегментов. Попав в одно из иерархических пространств имен, которые были подключены извне и на самом деле не являлись частью системы, пользователь обращался к нему и они становились частью его адресного пространства, а затем он использовал машинные команды для сохранения данных в этом сегменте. Я совершенно откровенно это позаимствовал.

Кроме того, Multics была системой виртуальной памяти со страничными прерываниями и не различала страницы данных и страницы программ. Вы переходили на сегмент, возвращаемый по страничному прерыванию, вне зависимости от того, были это данные или команды. Не было файлов, которые можно было читать или записывать – ничего, что бы вы могли передавать на удаленную систему. На мой взгляд, это недостаток. Огромное пространство виртуальной памяти являлось унифицированной концепцией, лежащей в основе Multics (и ее нужно было попробовать в эпоху, когда все стремились создать единую теорию программирования), хотя я считаю, что это было серьезной ошибкой.

Мне захотелось отделить данные от программ, поскольку данные и команды друг от друга сильно отличаются. Читая файл, вы почти всегда уверены, что данные будут читаться последовательно, и вас не удивляет, что вы можете загрузить a и прочитать затем a + 1. Более того, извлекать из кэш команды намного сложнее, чем данные. Поэтому я добавил системный вызов exec, который указывает «запустите это как программу», в то время как в Multics вы должны были «прерваться» по отсутствию требуемой команды и перейти на нее.

История разработки

В первых версиях по существу экспериментировал с некоторыми концепциями Multics на PDP-7 после того, как проект был закрыт. Я работал с такой маленькой командой, какую вы только можете себе представить. Затем я выбрал двоих пользователей, Дуга Макилроя и Денниса Ричи, которых интересовали языки. Выслушав их замечания, очень профессиональные и точные, я был вынужден разработать еще пару вариантов на ассемблере PDP-7.

В какой-то момент я получил от Мартина Ричардса из Массачусетского технологического института BCPL и преобразовал его в то, что считал довольно прямым переводом, но на самом деле получился иной язык, который я назвал Би. Затем Деннис добавил к нему типы и назвал его Си.

Мы купили PDP-11 – одну из самых первых машин – и я переписал Unix на ассемблере PDP-11, получив работоспособную версию. Она использовалась для некоторых внутренних телефонных приложений корпорации Bell, для сбора отчетов о неисправностях и контроля различных вещей, в частности кабелей, размещение которых менялось. Эти приложения так или иначе требовали поддержки со стороны операционной системы. Их необходимо было обслуживать, поэтому в Bell Labs была создана специальная группа Unix Support Group. Она должна была служить своего рода интерфейсом связывать наши версии с приложениями в предметной области, которым была необходима более стабильная среда. Они не казались чем-то неожиданным. Со временем они были преобразованы в коммерческую версию компании AT&T и более автономную версию от USL.

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

Третья версия (я занимался основой ОС, ядром, а Деннис – блочным вводом/выводом и диском) оказалась удачной; она и стала версией 5, которая использовалась в лаборатории, а версия 6 была передана в университеты. Затем была создана версия 7, где было сделано перераспределение системы для подготовки первого переноса на Interdata 832, который осуществили Стив Джонсон и Деннис Ричи. Независимо от нас аналогичный перенос был сделан в Австралии.

Что касается версии 6, агентство ARPA (Advanced Research Projects Agency) приняло ее в качестве стандарта для сообщества Arpanet. Университет Беркли получил контракт на поддержку и распространение этой системы. Их основной вклад состоял в адаптации стека TCP/IP, разработанного в Университете штата Иллинойс и добавлении виртуальной памяти к версии, которую Bell Labs переносила на VAX.

О создании Unix Деннисом написан прекрасный рассказ, который можно найти на его домашней странице (Прим. ред. – «Эволюция системы Unix с разделением времени» (The Evolution of the Unix Time-Sharing System) по адресу http://cm.belllabs.com/cm/cs/who/dmr/hist.html).

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

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

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

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

По своему опыту и опыту некоторых моих друзей могу сказать, что Linux – довольно ненадежная система. Microsoft выпускает не слушком надежные программные продукты, но Linux худший из них. Это среда долго не продержится. Если вы используете ее на одном компьютере – это одно дело. Если же хотите применять Linux в брандмауэрах, шлюзах, встроенных системах и так далее – она требует еще очень серьезной доработки.

Распределенные вычисления: сетевые операционные системы и языки

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

В Plan 9 и Inferno основные идеи – это протоколы для связи между компонентами и расширение конкретных концепций. В Plan 9 ключевая абстракция – это файловая система (позволяющая читать и записывать что-либо, а также выбрать по имени в иерархии) и экспорт протоколов, являющихся абстракцией для удаленных каналов, которые позволяют реализовать распределенность. Inferno работает точно так же, но имеет более высокий уровень интерактивности языка благодаря использованию языкового интерфейса Limbo, который похож Java, но, как мне кажется, намного яснее.

Limbo

Во-первых, я должен сказать, что язык сам по себе практически полностью создан Сином Дорвардом. И то, что я о нем рассказываю, вовсе не означает, что я много сделал для его реализации.

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

При работе с языками C++ и Java у меня возникало определенное беспокойство, когда я просил сделать что-либо, а в ответ получал: «Хорошо, вы делаете это так-то или можете сделать так-то». Совершенно очевидно, если вы в состоянии сделать что-то столь разнообразными способами и все эти способы более менее эквивалентны, значит в системе заложено слишком много возможностей. Я считаю, что здесь реализованы более ограниченные концепции, которые лучше подходят для Inferno.

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

Есть ряд обязательных возможностей, к примеру, некоторая ориентация на объекты. Вы могли бы заменить Limbo на Java (хотя мне бы этого не хотелось) и сохранить базовые принципы Inferno, кроме тех случаев, когда они не соответствуют системным требованиям. Син решил, что вся система должна иметь язык «для сборки мусора» на более высоком уровне, при котором не разделяются взаимодействующие процессы, поддерживающие свои собственные адресные пространства (в некоторых из них сборка мусора осуществляется, а в некоторых – нет).

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

Кроме того, реализация языка (и опять-таки это не моя заслуга) не имеет функции сборки мусора типа «отметить и удалить». Она базируется на контроле указателей: если вы что-то открываете, а затем возвращаетесь, ведется контроль указателей. Таким образом, у вас нет высоких или низких отметок уровня, поскольку 99% мусора удаляется, как только выясняется, что ссылка на него утрачена. Если вы приравняли указатель к нулю, значит, вы не намерены использовать данные, на которые он ссылается, и, следовательно, все эти данные удаляются.

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

И опять-таки, это весьма прагматичный подход. Это не стремление использовать самый хороший алгоритм для сборки мусора. Это просто способ собирать мусор, который представляет достаточно эффективным.

Текущая работа

Некоторые из нас ведут исследования, в рамках недавно созданной в Lucent группы разработки продукта, получившего название PathStar Access Server. По сути он представляет собой коммутатор и маршрутизатор для IP-телефонов и серверов данных, предназначенный для крупного офиса. Он во многом ориентирован на IP. Вы снимаете телефонную трубку, набираете номер и можете вести селекторное совещание.

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

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

Есть несколько оригинальных компонентов. Реальная обработка звонков, которая обычно выполняется с помощью огромной машины с конечным числом состояний, здесь реализована довольно интересно. Мы создали язык генерации машин с конечным числом состояний. Объект такого языка – это машина с конечным числом состояний, но источник – нет. Реальный телефонный разговор – это группа взаимодействующих машин с конечным числом состояний, почти как процессы. И, конечно же, они должны быть распределенными, поскольку вы звоните на другие телефоны.

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

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

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

Так примерно ведут себя и языки FSM, которые не позволяют сделать все «за один присест». Полагаю, что именно таким способом и создавались компьютерные языки.

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

Музыкальная коллекция

Это «проект», в котором я реализую свои личные пристрастия, исследовательский интерес и увлечение музыкой. Я попытаюсь объяснить все с внешней точки зрения. У меня большая коллекция музыкальных записей. Из различных источников я получаю списки типа «Лучшая десятка», «Лучшие 50 записей», и пытаюсь составить музыкальную коллекцию.

Сейчас в моем списке около 35 тыс. песен, из которых у меня есть порядка 20 тысяч. Я сжал эти записи с помощью созданного в Bell Labs алгоритма, получившего название PAC (Perceptual Audio Coding), и храню их в системе типа «музыкального ящика». Я начал составлять свою коллекцию еще до появления MP3 в Сети. PAC во многом превосходит MP3.

Мою коллекцию нельзя представить широкой публике по юридическим соображениями. Я обратился к юристам и рассказал, что собрал большое число звукозаписей, но, как мне показалось, они не поняли, что я понимаю под словом «большое». Они заявили, что использование записей в исследовательском проекте законно, и они меня поддерживают, но сесть за меня в тюрьму не готовы. Так что я не могу представить ее вообще. Но это довольно впечатляюще. У системы есть комбинированный экран, как у браузера; и вы можете перемещаться по спискам, годам и неделям.

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

Компьютерная наука и будущее

Я бы хотел дать совет своему сыну, да и всему следующему поколению: идите в биологию.

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

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

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

Операционные системы, должны выполнять очень большую работу. Сейчас, если вы намерены создать что-то стоящее, вы должны конкурировать с Microsoft, должны поддерживать все браузеры, Word, Office и многое другое. Даже если вы напишете более качественную операционную систему, никто из тех, кто действительно сейчас использует компьютеры, не знает, какой у операционной системы интерфейс. Для них интерфейс – это браузер или Microsoft Office.

У вас может быть самый лучший и самый красивый интерфейс в мире, самая расширяемая операционная система, которая переносится куда угодно, и вам придется переносить ее, затрачивая тысячи человеко-лет рабочего времени, на приложения, исходные тексты которых вы не можете получить. У вас есть два пути: обратиться к Microsoft и попросить исходные тексты на Office, чтобы перенести его на свою операционную систему, а они будут смеяться вам в лицо; или, вооружившись руководством пользователя, получить исходный текст путем обратной разработки и они в любом случае подадут на вас в суд. Так что понятно, что этого никогда не произойдет, поскольку «входная плата» чересчур высока.

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

Конечно, нет. Любого, кто скажет, что в мире больше нет места новому – можно отнести к списку по крайней мере 400 людей, утверждавших то же самое с Рождества Христова.

Да, есть немало интересных программ, которые стоит написать.

Чем я и занимался во время зимнего отпуска

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

Благодарности

Мы признательны Патрику Ригану из компании Lucent Technologies за организацию этого интервью, и Бриджитт Ханги за предоставленные фотографии. Снимок Unix Room в центре Computing Sciences Research Center любезно предоставлен компанией Lucent Technologies.

Об авторе