lyricsubnet

Unix

Первый компьютерный вирус в мире

"Два самых громких открытия из Беркли - LSD и Unix. Я не думаю, что это совпадение."

- Аноним

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

Особенности хороших вирусов таковы:

• Небольшой размер

Вирус делает не так много вещей, так что ему и не нужны большие объёмы. Некоторые люди спорят, являются ли вирусы живыми существами или это лишь частички опасной нуклеиновой кислоты и белка.

• Портативность

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

• Возможность управлять ресурсами носителя

Если владелец не даст вирусу безопасного приюта и энергии для размножения, вирус погибнет.

• Быстрая мутация

Вирусы часто мутируют в несколько различных форм. Эти формы имеют общую структуру, но достаточно отличаются, чтобы смутить защитные механизмы носителя.

Unix проходит по всем пунктам и походит на вполне успешный вирус. Его первоначальная форма была крайне компактной и обладала небольшим количеством возможностей. Наибольшую важность имела минималистичность его архитектуры, потому как изобилие возможностями сделало бы его настоящей операционной системой (такими как файлы, отображающие память, быстрый ввод/вывод, надёжная файловая система, запись, файлы, блокировка устройств, рациональное межпроцессовое взаимодействие и так далее до тошноты), но зато Unix был портативен. Операционная система с большим числом возможностей убавила бы это качество. Unix питается энергией его носителя. Без администратора, который нянчится с системой, Unix регулярно падает, сбрасывает ядро и виснет. Unix часто мутирует: латается и изменяется, чтобы то, что работает на одной версии, не работало в другой. Если бы Штамм Андромеды был программой, ей был бы Unix.

Unix это компьютерный вирус с пользовательским интерфейсом.

История чумы

Корни Unix'овой чумы идут в 1960'ые, когда American Telephone and Telegraph, General Electric и Массачусетский Технологический Институт встали в ряд для проекта по разработке нового типа операционной системы, названного "информационная утилита". С трудом проспонсированная Отделом агентства перспективных исследовательских проектов Министерства обороны США (известного как ARPA), идея разработать систему для использования на отдельных компьютерах была так же надёжна, как электростанция - дающая бесконечные вычислительные ресурсы сотням или тысячам людей. Информационная утилита была бы оснащена предостаточным количеством модулей центральных процессоров, хранилищами памяти и процессорами ввода/вывода, так что одно взаимодействовало бы с остальным, продолжая работу. Система была продумана и обеспечивала высочайший уровень компьютерной безопасности, чтобы действия одного пользователя не повлияли на другого. Её цель была видна даже в названии: "Multics" это сокращение от "Составная Информационная и Компьютерная Система" (MULTiplexed Information and Computer System).

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

В конце концов, Multics достиг всех своих целей, но в 1969 он отстал по графику, и AT&T к нему охладел: вышел из проекта, оставив трёх исследователей - Кена Томпсона, Денниса Ритчи и Джозефа Осанна - с непредвиденным для них свободным временем. После того как программисты безуспешно попытались уговорить руководство купить DEC System 10 (мощный компьютер с разделением времени и утончённой операционной системой), Томпсон и его друзья отступили, чтобы написать (и поиграть в) игру "Космическое путешествие" на компьютере PDP-7, стоявшем в то время без дела в углу лаборатории.

Вначале Кен использовал GE645 от Bell Labs, чтобы кросс-компилировать игру на PDP-7, но вскоре - рассчитывая, что было бы быстрее написать операционную систему для PDP-7 вместо того чтобы разрабатывать Космическую Войну в удобной среде GE645 - Томпсон написал для PDP-7 ассемблер, файловую систему и минимальное ядро. Всё, чтобы поиграть в Космическое Путешествие. Таким образом и появился Unix.

Подобно исследователям, работавшим над бактериальным оружием (другой спонсированный APRA проект того же времени), ранние исследователи Unix не осознавали всех последствий своих действий. Но, в отличие от тех экспериментов, у Томпсона и Ритчи не было никакой протекции. Конечно же, вместо того, чтобы сдержать себя, они увидели себя в роли евангелистов. Томпсон и Ко. нечаянно написали несколько страниц того, что они назвали документацией, и затем всё это они начали отсылать.

Сначала Unix-инфекция ограничивалась несколькими определёнными группами внутри Bell Labs. На момент её начала патентному офису Labs потребовалась обработка текста. Они купили PDF-11/20 (к тому времени Unix мутировал и перешёл ко второму носителю) и стали первыми подопытными добровольцами штамма. К 1973 Unix перешёл на 25 разных систем внутри лаборатории исследований, и AT&T вынужден был создать Unix Systems Group для внутренней поддержки. Исследователи в Колумбийском Университете узнали о Unix и попросили у Ритчи копию. Перед тем как все поняли, что случилось, Unix вырвался на волю.

Литература сообщает, что Unix преуспел из-за технического превосходства. Это не так. Unix превосходил его соперников эволюционно, но не технически. Unix обрёл коммерческий успех из-за того, что был вирусом. Его эволюционными преимуществами были небольшой размер, простое устройство и объединяющая всё портативность. Позже он стал популярным и продаваемым из-за того что был подкреплён на трёх крайне успешных носителях: рабочих станциях PDP-11, VAX и Sun (Sun фактически создан, чтобы быть вирусным вектором).

Как пишет один из сотрудников DEC:

От: CLOSET::E::PETER 29-СЕН-1989 09:43:26.631

К: closet::t_parmenter

Тема: Unix

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

Из как минимум 20 коммерческих производителей рабочих станций, появившихся или уже существовавших в то время (с конца 1970 до начала 1980) только малая группа - Digital, Apollo, Symbolics, HP - противостояла Unix. К 1993 Symbolics попал в главу 11, а Apollo купили (HP). Сейчас оставшиеся компании - рьяные сторонники Unix.

Накопление случайного генетического материала

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

Это же справедливо для Unix. Несмотря на его изначально малый размер, Unix собирал мусорный геном в потрясающем темпе. Например, сложно найти такую версию Unix, в которой не будет драйвера для наборной машины Linotronic или Imager, даже если только несколько пользователей Unix знает, как эти устройства выглядят. Как обнаружил Олин Шиверс, изначальное эволюционное давление на Unix ослабилось, и штамм пробрался наружу.

Дата: Ср., 10 Апр. 91 08:31:33 EDT

От: Олин Шиверс <shivers@bronto.soar.cs.cmu.edu>

К: UNIX-HATERS

Тема: Эволюция Unix

Я думал об общей эволюции (здесь я использую этот термин свободно) Unix со времён его зарождения в Bell Labs, и мне кажется, следует описать её так:

В ранние времена PDP-11 программы на Unix имели следующие шаблоны в проектировании:

   Правило 1. Программа не должна быть хорошей или даже корректной.

Но:

   Правило 2. Программа должна быть маленькой.

Отсюда поход с 'набором инструментов' и прочее.

Конечно, со временем компьютерное оборудование развивилось и стало мощнее: процессоры разогнались, адресное пространство сместилось от 16 до 32 бит, память стала дешевле, и так далее.

Так что правило 2 ослабилось.

Дополнительный генетический материал продолжает мутировать по ходу распространения вируса. В действительности, не важно, как туда попали гены - они покорно переходят из поколения в поколение, где второй и третий родственник будет похож на другого так же, как Вуди Аллен похож на Майкла Джордана. Это поведение описано в нескольких книгах. Например, Раздел 15.3, "Routing Information Protocol (RIP)", страница 183 прекрасной книги о сетях Internetworking with TCP/IP Дугласа Кумера показывает, как низшие гены выживают и мутируют в сетевом коде Unix (параграф 3):

Несмотря на малозначительные улучшения после предшественников, популярность RIP и IGP исходит не от их технических заслуг. Напротив, так вышло, потому что Беркли поставило программу routed вместе с популярной системой 4.X BSD UNIX. Поэтому, многие интернет-сайты приютили и установили routed и начали использовать RIP даже не понимая его технических достоинств и ограничений.

Следующий параграф гласит:

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

Как классическая радиостанция, играющая тот же список произведений десятилетиями, Unix одновременно показывает своё смешанное и устаревшее наследие. Там есть эра Clash графических интерфейсов, эра Beatles названий команд в две буквы и системных программ (например, ps), чей лаконичный и смутный вывод разработан для медленных телетайпов; эра Bing Crosby редактирования команд (# и @ всё ещё остаются командами редактирования строк по умолчанию) и эра Scott Joplin дампов ядра.

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

Успокаивающая мысль.

Секс, наркотики, Unix

В то время как Unix распространяется подобно вирусу, то, как его повсеместно принимают, можно описать другой метафорой - это дизайнерский наркотик.

Как любой хороший наркодиллер, AT&T раздала бесплатные образцы Unix университетам в течение 1970'ых. Исследователей и студентов "торкнуло" от Unix сильнее, чем от любой другой ОС. Он довольно дешёвый, податливый, работает на относительно недорогой аппаратуре. И он превалировал - для их нужд и для тех, кто мог его получить. Лучшая операционная система, которая потягалась бы с Unix, или требовала бы такое оборудование, которое университеты не могли себе позволить, или не была бы "бесплатной", или была бы выходкой не из тех мест, где её так деловито синтезировали. Политика AT&T задаром производила огромные массы хакеров Unix, зависимых от него. Психологически, если не химически.

Когда появился микропроцессор Motorola 68000, вместе с ним возникло множество компаний, специализирующихся на рабочих станциях. Совсем не многие обладали значительной компетенцией в операционных системах. Практически все из них использовали Unix: из-за его портативности и количества хакеров, у которых не было другого способа что-либо починить, и которые были легко и дёшево доступны. Эти программисты были способны к изощрениям (которые иногда называются "портированием"), чтобы Unix появлялся на других платформах. Для этих новоиспечённых производителей оборудования Unix был самым экономичным решением.

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

Хотелось ли им операционной системы с ужасным набором инструментов? Наверное, нет.

Хотелось ли им системы без автодополнения команд? Нет.

Хотелось ли им операционной системы с убогим и опасным пользовательским интерфейсом? Никоим образом.

Хотелось ли им системы без файлов расположения памяти? Нет.

Хотелось ли им систему, не способной оставаться в работе больше нескольких дней (иногда часов) подряд? Не-а.

Хотелось ли им единственной системы без "умной" печати? Конечно, нет.

Хотели ли они получить самую дешёвую рабочую станцию, которую могли себе позволить, поддерживающую компилятор и линковщик? Определённо. Им хотелось пожертвовать ради этого.

Пользователи говорили, что выбрали Unix, потому что он был лучше чем "каменные ножи и медвежьи шкуры" - среды разработки FORTRAN и Cobol, которые они использовали уже три десятилетия. Но, выбирая Unix, они неосознанно проигнорировали годы исследований в операционных системах, которые привели к огромным по значимости результатам. Это не так и важно, как они думали: Unix был лучше того, что у них было. К 1984, согласно собственным записям DEC, четверть поставок с VAX в Соединённых Штатах шла с Unix, даже если DEС не всегда его поддерживал.

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

Стандартизируя несоответствие

"Замечательно в стандартах то, что среди них всегда есть что выбрать."

- Грэйс Мюррэй Хоппер

Как только Unix обрёл популярность в 80'ые, началась непрерывная работа части его поставщиков по "стандартизации" операционной системы. Хоть часто и кажется, что эти усилия нужны только в пресс-релизах и на не-программистских экранах, Unix'овые гиганты вроде Sun, IBM, HP и DEC на самом деле выбросили миллионы долларов на решение проблемы - проблемы, во многом являющейся таковой только из-за них.

Почему поставщики Unix в действительности не хотят его стандартизировать

Движение к унифицированному Unix началось по большей части от потребителей. Они видели огромное множество Unix'ов, находили всё это слишком сложным и, в конце концов, покупали клон PC и использовали Microsoft Windows. Очевидно, что покупатели отдавали предпочтение покупке схожей по цене рабочей станции с "настоящей" операционной системой (где их ввели в заблуждение, сказав, что это Unix), но всегда есть риск, что критически важные приложения, нужные им, не будут поддерживаться на конкретной версии Unix, приобретённой ими.

Вторая причина, по которой потребителям хотелось совместимых версий Unix, была в том, что они ошибочно полагали, что программная совместимость заставит поставщиков оборудования соревноваться в цене и производительности, что в конечном счёте снизит стоимость рабочих станций.

Конечно, обе причины были _теми же причинами_, по которым производители станций в лице Sun, IBM, HP и DEC в действительности _не хотели_ унифицировать Unix. Если каждая рабочая станция от Sun, IBM, HP и DEC будет исполнять те же программы, тогда компания, которая уже внесла трёхмиллионный вклад в Sun, не захочет оставаться в её продуктной линии: эта мифическая компания таким же образом может сходить и купить блок станций от HP или DEC, если те предложат лучшую цену.

Это всё как-то иронично. Одна из причин, по которым пользователи перешли на Unix, это обещание в "открытых системах", которыми они смогут заменить их пропреитарные мейнфреймы и мини. Но в конечном итоге переход на Unix стал по сути переходом на новую пропреитарную систему - систему, которой выдалось быть пропреитарной версией Unix.

Дата: Ср., 20 Ноя. 91 09:37:23 PST

От: simsong@nextworld.com

К: UNIX-HATERS

Тема: Названия Unix

Возможно, отслеживать разные названия для различных версий Unix не проблема для большинства людей, но сегодня редактор копий здесь, в NeXTWORLD, спросил меня, в чём разница между AIX и A/UX.

"AIX это Unix от IBM. A/UX это Unix от Apple".

"В чём разница?" - спросил он.

"Я не уверен. Обе эти системы - AT&T System V с некоторыми изменениями. Есть HP-UX - версия System V от HP со своими. DEC зовёт свою систему ULTRIX. DGUX - от Data General. И не забудь Xenix - это от SCO."

NeXT в это время называет свои версии Unix (которые суть Mach с обмотанным вокруг мёртвым Unix) - NEXTSTEP. Но невозможно дать определение для NEXTSTEP. Это оконная система? Objective-C? Среда? Mach? Что?

Изначально многие поставщики хотели использовать слово "Unix" для описания своих продуктов, но от этого их предостерегли юристы AT&T, посчитавшие, что слово это является своего рода значимым зарегистрированным торговым знаком. В итоге, чтобы избежать судебной тяжбы, им приходилось выбирать имена вроде VENIX или UNTRIX.

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

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

Дата: Вск., 13 Мая 90 16:06 EDT

От: Джон Р. Дюннинг <jrd@stony-brook.scrc.symbolics.com>

К: jnc@allspice.lcs.mit.edu, UNIX-HATERS

Тема: Unix: последнее слово в несовместимости

Дата: Вт., 8 Мая 90 14:57:43 EDT

От: Ноэл Чиаппа <jnc@allspice.lcs.mit.edu>

[...]

Мне кажется, лишь Unix и снежинки - два класса объектов во вселенной, две разные единицы которых никогда не совпадают.

Думаю, он прав, и это напомнило мне одну историю.

Несколько лет назад, когда я был консультантом, я работал в компании-производителе программного обеспечения, которая строила нечто вроде приложения с огромным графическим пользовательским интерфейсом. Они использовали какой-то вид Unix на PDP-11 для разработки и планировали продать это с платой к OEM. Моя задача заключалась в оценке различных версий Unix, исполняющихся на похожей на мультибус аппаратуре, чтобы понять, что больше подходит их нуждам.

Процесс оценки состоял в большей степени в попытке протестировать их программу, которая была ранним прототипом их продукта, скомпилировать и запустить на различных *nix'ах. Мой хлеб, как говорится. Но упс, один поставщик изменил порядок аргументов в его классе системных функций. И чёрт, посмотрите на это: брешь в компиляторе Xenix предостерегает вас от использования сущностей размером с байт; вам приходится подделывать их с помощью структур, объединений и прочего. Что ж, знаете ли - возможности Venix якобы в реальном времени не работают от слова совсем. Вам нужно искать свои собственные. До тошноты.

Я не помню в деталях, в каких версиях какие были проблемы, но результат был в том, что не было ни одной пары из пятёрки, которую я пробовал, совместимой для чего-то кроме тривиальных программ! Я был в шоке. Я был ужасно потрясён. Я был вдохновлён тем, что семейство операционных систем, нацеленных на совместимость, стало такого рода провалом. Но вещь, действительно поразившая меня, была в том, что ничего из этого не удивило *nix'овых хакеров! Их реакция была чем-то вроде: "Что ж, такова жизнь. Несколько #ifdef'ов здесь, пара фальшивых библиотечных интерфейсов функций там, в чём проблема-то?"

Я не знаю, есть ли у истории иная мораль кроме той, что никому не следует доверять ничего, что относится к Unix, чтобы оно было совместимо с чем-то, относящимся к Unix. Ой, и да, я слышал, что некоторое время спустя та компания перевыполнила свой двухлетний план - в конечном счёте они выбросили Unix и работали под машины с MS-DOS. Всё было из соображений поскорее избавиться от этой штуки и выставить её подальше за дверь!

В 1989, публикуясь в списке рассылки RISKS Питера Ньюмана, Пит Шиллинг, инженер Alcoa Laboratories Applied Mathematics and Computer Technology Division, раскритиковал понятие слова "стандарт" в целом, приводя в пример такие программные системы как Unix. Реальные стандарты, писал он, нужны для физических объектов, таких как стальные балки: это даёт архитекторам возможность заказать часть и употребить их в своих разработках с пониманием, что они будут действовать в условиях реального мира. Если балка испортится во время работы, юристы строительной компании смогут воззвать к юристам производителя балок, чтобы обсудить такие вещи как компенсация и штрафные убытки. По всей видимости, опасность ответственности оставляет большинство компаний честными; все нечестные, предположительно, в скором времени будут закрыты.

Это понятие стандартов ломается, когда его применяют к программным системам. Какого рода спецификации должна удовлетворять версия Unix? POSIX? X/Open? COBRA? Такое огромное пространство для манёвра среди этих стандартов, что компания может быть ответственной за несоответствие им, смешно задуматься. Понятно, что каждый следует собственным стандартам, поэтому большинство продуктов несовместимы.

Sun Microsystems недавно анонсировал, что объединяется с NeXT, чтобы обнародовать OpenStep, новый стандарт объектно-ориентированных пользовательских интерфейсов. Чтобы достичь такой открытости, Sun обёрнет свой C++ и DOE вокруг Objective-C и NEXTSTEP. Не можете решить, какому стандарту следовать? Не проблема: теперь вы можете следовать всем.

Надеюсь, у вас нет никакой срочной работы.

Мифы Unix

Наркоманы врут себе. "Косячок не сделает меня тупым", "я лишь один раз попробую крэк", "я могу остановиться когда захочу". Если вы находитесь на рынке наркотических веществ, вы обязательно услышите подобные слова.

У Unix есть своя коллекция мифов, также как и сеть дилеров, распространяющих их. Возможно, вы уже слышали их ранее:

1. Он стандартен.

2. Он - быстрый и эффективный.

3. Это правильная ОС для любой цели.

4. Он мал, прост и элегантен.

5. Сценарии командной оболочки и конвейеры это отличный способ структурировать сложные проблемы и системы.

6. У него есть электронная документация.

7. У него есть документация.

8. Он написан на языке высокого уровня.

9. X и Motif придают Unix дружелюбность и простоту, как в Macintosh.

10. Процессы дешевы.

11. Он первым открыл:

• Иерархическую файловую систему

• Электронную почту

• Сетевые и интернет-протоколы

• Удалённый доступ к файлам

• Безопасность/пароли/защиту файлов

• finger [протокол для предоставления информации о пользователях удалённой системы]

• Одинаковое обращение с устройствами ввода/вывода

12. Он обладает продуктивной средой программирования.

13. Это современная операционная система.

14. Это то, чего хотят люди.

15. Его исходный код:

• Доступен

• Понятен

• Соответствует тому, что вы исполняете

Далее в этой книге вы найдёте объяснение и разоблачение большинству этих мифов.

A. Эпилог

Просветление через Unix

От: Майкл Трэверс <mt@media-lab.media.mit.edu>

Дата: Суб., 1 Дек 90 00:47:28 -0500

Тема: Просветление через Unix

К: UNIX-HATERS

Unix постоянно говорит нам переходящей природе всех вещей, тем самым избавляя от сансарных привязанностей и ускоряя просветление.

Например, пока я пытался понять сценарий инициализации X, который кто-то дал мне, я наткнулся на строку, которая выглядела как обычная команда оболочки Unix с термином "exec", предварённым ей. Любопытствуя, что exec может сделать, я написал "exec ls" в окно оболочки. Команда перечислила содержимое каталога, затем убила оболочку и все другие окна, открытые в тот момент, и оставлила экран почти полностью чёрным с крошечным белым неактивным курсором на дне, чтобы напомнить мне, что ничто не абсолютно, и что всё связано со своей противоположностью.

Раньше произошедшее смутило бы меня или разозлило. Это было до того как я нашёл просветление через Unix. Теперь у меня нет никакой привязанности к моим процессам. И процессы, и их исчезновение иллюзорны. Мир - это Unix, а Unix - мир, беспрестанно трудящийся во спасение всех чувствующих существ.

B. Создатели сознались: C и Unix - розыгрыш

К НЕМЕДЛЕННОМУ ВЫПУСКУ

Только что прозвучало завявление, потрясшее компьютерную индустрию: Кен Томпсон, Деннис Ритчи и Брайан Керниган признали, что операционная система Unix и язык программирования C за их авторством - сложная первоапрельская шутка, поддерживаемая более 20 лет. Выступая на последнем Форуме разработки программного обеспечения UnixWorld, Томпсон произнёс:

"В 1969 AT&T завершил работу над проектом Multics с GE/AT&T. Мы с Брайаном тогда работали над ранним выпуском Pascal из лаборатории ETH профессора Никлауса Вирта в Швейцарии. Нас впечатлила его элегантная простота и мощь. Деннис же дочитал "Утомлённых кольцами" - весёлую пародию National Lampoon на великую трилогию Толкина "_Властелин колец_". Забавы ради мы решили спародировать Multics и Pascal. Мы с Деннисом отвечали за операционную среду. Мы посмотрели на Multics и разработали новую систему - так, чтобы она была настолько сложной и загадочной, насколько это возможно, чтобы донельзя смутить случайного пользователя. Мы назвали её "Unix" в качестве пародии на Multics, так же, как и другие рискованные намёки.

Потом Деннис и Брайан работали над полностью искривлённой версией Pascal, названной "A". Когда мы обнаружили, что другие пытались писать настоящие программы на A, мы быстро добавили ещё больше загадочных особенностей, и язык перешёл в B, потом в BCPL, и, наконец, в C. Мы остановились, когда добились чистой компиляции следующей строки:

for(;P("\n"),R=;P("|"))for(e=C;e=P("_"+(*u++/8)%2))P("|"+(*u/4)%2);

Мы и подумать не могли, что современные программисты будут пытаться использовать язык, допускающий такие утверждения! На самом деле мы хотели продать это Советам, чтобы отодвинуть их прогресс в информатике лет на 20 или больше. Представьте наше удивление, когда AT&T и другие корпорации Соединённых Штатов попробовали C и Unix! У них ушло 20 лет на то, чтобы разобраться и создавать хоть сколь-нибудь полезные программы, используя нашу технологическую пародию из 60-ых, и нас поражает упорство (если не здравомыслие) обычного программиста Unix и C.

В любом случае, мы с Брайаном и Деннисом последние несколько лет работалем исключительно на Lisp под Apple Macintosh, и мы чувствуем вину за хаос, смущение и по-настоящему плохой код, получившиеся в итоге нашего старого глупого розыгрыша."

Основные поставщики и потребители Unix и C в лице AT&T, Microsoft, Hewlett-Packard, GTE, NCR, и DEC на данный момент отказываются давать какие-либо комментарии. Borland International, лидирующий поставщик инструментов Pascal и C, таких как популярные Turbo Pascal, Turbo C, и Turbo C++, заявил, что подозревал это на протяжении долгих лет; компания продолжит укреплять позиции своих продуктов Pascal и прекратит дальнейшие усилия по разработке C. Представитель IBM впал в приступ неконтролируемого смеха и был вынужден отложить созванную наспех новостную конференцию, посвящённую судьбе RS/600, сказав: "Workplace OS будет доступна очень скоро". Профессор Вирт Института ETH и отец структурных языков Pascal, Modula 2 и Oberon произнёс странные слова: "Ф.Т. Барнум был прав".

Рассвет "хуже есть лучше"

Ричард П. Габриэль

Основная проблема с Lisp сегодня исходит из напряжения между двумя противоположными программными философиями. Эти философии называются "правильная вещь" и "хуже есть лучше". [Это выдержка из статьи "Lisp: Good News, Bad News, How to Win Big" Ричарда П. Габриэля, изначально появившейся в выпуске журнала AI Expert за апрель 1991. © 1991 Richard P. Gabriel. Разрешение на печать предоставлено автором и AI Expert.]

Я и почти каждый причастный к разработке Common Lisp и CLOS в своё время были подвержены экстремальному воздействию стиля разработки MIT/Стэнфорда. Его суть можно собрать фразой "правильная вещь". В соблюдении этого стиля важно, чтобы код обладал всеми следующими характеристиками:

• Простота

  Устройство [Здесь и далее под устройством в виду имеется внутреннее устройство -Перев.] должно быть простым и в реализации, и в интерфейсе. В максимальной простоте приоритет отдаётся интерфейсу.

• Корректность

  Устройство должно быть корректным во всех обозримых аспектах. Некорректность просто непозволительна.

• Последовательность

  Устройство не должно быть непоследовательным. Устройству позволяется быть чуть менее простым и менее полным, чтобы избежать противоречий. Последовательность так же важна, как корректность.

• Полнота

  Устройство должно покрывать столько важных ситуаций, сколько возможно. Должны быть покрыты все разумно ожидаемые случаи. Простоте не позволяется чрезмерно сокращать полноту.

Я уверен, многие люди согласятся, что всё это - хорошие характеристики. Я назову использование этой философии проектирования "Подходом MIT". Common Lisp (с CLOS) и Scheme представляют этот подход в проектировании и реализации.

Философия "хуже есть лучше" немного отличается:

• Простота

  Устройство должно быть простым и в реализации, и в интерфейсе. В простоте приоритет за реализацей, а не за интерфейсом. Простота - самое главное в устройстве.

• Корректность

  Устройство должно быть корректным во всех обозримых аспектах. Чуть лучше, если устройство будет более простым, чем более корректным.

• Последовательность

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

• Полнота

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

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

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

Позвольте начать, пересказав историю. Она покажет, что разделение MIT/Нью-Джерси допустимо, и что сторонники каждой философии в действительности верят, что их философия лучше.

Два известных человека - один из MIT, другой из Беркли (но работающий на Unix) - однажды встретились, чтобы обсудить проблемы одной операционной системы. Человек из MIT был сведущ в ITS (операционной системе Лаборатории ИИ MIT) и читал исходники Unix. Его интересовало, как Unix решил проблему "PC loser-ing" [Счётчик команд (Program Counter). PC - регистр в центральном процессорном устройстве, следящий за текущей точкой выполнения внутри исполняемой программы.]. Эта проблема встречается, когда пользовательская программа вызывает системную процедуру, чтобы выполнить длительную операцию, у которой может быть значительное состояние, такую как ввод/вывод, включая его буферы. Если во время операции происходит прерывание, состояние пользовательской программы должно быть сохранено. Из-за того, что вызов системной процедуры обычно является одной инструкцией, PC пользовательской программы не захватывает состояние процесса надлежащим образом. Системная процедура должна отходить либо назад, либо вперёд. Правильной вещью было бы отойти назад и восстановить PC пользовательской программы до инструкции, вызвавшей системную процедуру, так что возобновление пользовательской программы после, к примеру, прерывания заново войдёт в системную процедуру. Называется это "PC loser-ing", потому что PC по принуждению переходит в "лузерский режим", где "лузером" любя называют "user"'а в MIT.

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

Парень из Нью-Джерси сказал, что решение Unix было верно, ведь что философия проектирования Unix была в простоте, и правильная вещь была бы слишком сложной. Кроме того, программисты могли легко вставить дополнительную проверку и цикл. Парень из MIT указал на то, что реализация была проста, но интерфейс к функциональности был сложным. Парень из Нью-Джерси сказал, что в Unix был выбран правильный компромисс: простота реализации была важнее простоты интерфейса.

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

Теперь я хочу доказать, что "хуже есть лучше" - лучше. C - язык программирования, созданный для написания Unix, и он был создан с использованием подхода Нью-Джерси. Следовательно, C - язык, для которого легко написать приличный компилятор, и он требует от программиста писать такой текст, который легко интерпретировать компилятору. Некоторые называют C модным языком ассемблера. И ранний Unix, и компиляторы C обладали простой структурой, их легко портировать, они требуют меньше машинных ресурсов для исполнения и предоставляют примерно от 50% до 80% того, чего вы хотите от операционной системы и языка программирования.

Половина компьютеров, существующих в любой точке мира, хуже среднего (меньше или медленнее). Unix и C хорошо работают на них. Философия "лучше есть хуже" заключаетсяв том, что простота реализации имеет высший приоритет, что значит, что Unix и C легко портировать на описанные выше машины. Следовательно, можно ожидать, что если 50% функциональности Unix и поддержка C - удовлетворительно, они начнут появляться везде. И они начали, не так ли?

Unix и C - настоящие компьютерные вирусы.

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

Важно помнить, что в своём изначальном виде вирус должен быть в основном хорошим. Тогда его заразительное распространение гарантировано, поскольку он портативен. Как только вирус начал распространяться, появится давление, чтобы улучшить его, возможно, увеличивая его функциональность ближе к 90%, но пользователи к тому времени уже приучены принимать вещь хуже, а не лучше. Таким образом, программное обеспечение по "хуже есть лучше" сначала получит признание, затем приучит пользователей ожидать меньше и в конце будет улучшено до того, что станет почти хорошей вещью. Если конкретнее, то хоть даже компиляторы Lisp в 1987 были почти так же хороши, как компиляторы C, было куда больше экспертов, желающих сделать компиляторы C лучше, чем тех, кто хотел бы улучшить компиляторы Lisp.

Хорошая новость: в 1995 у нас будут хорошая операционная система и язык программирования. Плохая новость: это будут Unix и C++.

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

Как дела пойдут у правильной вещи? Есть два основных сценария: сценарий "большой сложной системы" и сценарий "похожей на алмаз драгоценности".

Сценарий "большой сложной системы" таков:

Во-первых, нужно продумать правильную вещь. Затем нужно продумать её реализацию. Наконец, она реализуется. Поскольку это правильная вещь, она обладает почти 100% желаемой функциональности, и простота реализации не заботит авторов, так что реализация занимает долгое время. Она - большая и сложная. Она требует сложных инструментов для правильного использования. Последние 20% занимают 80% усилий, правильной вещи нужно много времени, чтобы выбраться в свет, и она удовлетворительно работает только на самом утончённом оборудовании.

Сценарий "похожей на алмаз драгоценности" таков:

Правильная вещь занимает вечность на разработку, но она довольно миниатюрна на каждом этапе пути. Реализовать её так, чтобы она исполнялась быстро, или невозможно, или слишком сложно для большинства реализующих.

Два этих сценария соответствуют Common Lisp и Scheme. Первый сценарий также относится к классическому программному обеспечению искусственного интеллекта.

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

Из всего этого мы можем заключить, что в основном нежелательно в первую очередь стремиться к правильной вещи. Лучше сделать так, чтобы от неё была доступна лишь половина, чтобы она распространилась как вирус. Как только люди "клюнут" на неё, найдите время, чтобы улучшить её до 90% "правильности".

Неправильным выводом будет трактование притчи буквально и заключение, что C - лучшее средство для программного обеспечения в ИИ. 50% решения в основном должны быть верны, но не в этом случае.

D. Библиография

Как только Вы подумали, что выбрались из леса...

Allman, Eric. “Mail Systems and Addressing in 4.2bsd.” January 1983 USENIX.

Allman, Eric, and Miriam Amos. “Sendmail Revisited.” Summer 1985 USENIX.

Costales, Bryan, Eric Allman, and Neil Rickert. sendmail. O’Reilly & Associates, 1993.

Comer, Douglas. Internetworking with TCP/IP. Prentice Hall 1993.

Coplien, James O. Advanced C++: Programming Styles and Idioms. Addison-Wesley, 1992.

Crichton, Michael. The Andromeda Strain. Knopf, 1969.

Crichton, Michael. Jurassic Park. Knopf, 1990.

Doane, Stephanie M., et al. “Expertise in a Computer Operating System.”

Journal of Human-Computer Interaction. Vol 5, Numbers 2 and 3.

Gabriel, Richard P. “Lisp: Good News, Bad News, How to Win Big.” AI Expert, April 1991.

Garfinkel, Simson, and Gene Spafford. Practical UNIX Security. O’Reilly & Associates, Inc., 1991.

Jones, D. F. Colossus. Berkeley Medallion Books, 1966.

Kernighan, B. and Mashey. “The Unix Programming Environment.” IEEE Computer, April 1981.

Libes, Don, and Sandy Ressler. Life with UNIX: A Guide for Everyone. Prentice-Hall, 1989.

Liskov, Barbara, et al. CLU reference manual. Springer, 1981.

Miller, Fredriksen, and So. “An Empirical Study of the Reliability of Unix Utilities.” Communications of the ACM, December 1990.

Norman, Donald A. The Design Of Everyday Things. Doubleday, 1990.

Norman, Donald A. “The trouble with Unix: The user interface is horrid.” Datamation, 27 (12), pp. 139-150. November 1981

Pandya, Paritosh. “Stepwise Refinement of Distributed Systems,” Lecture Notes in Computer Science no 430, Springer-Verlag.

Stoll, Cliff. The Cuckoo’s Egg. Doubleday, 1989.

Tannenbaum, Andy. “Politics of UNIX.” Washington, DC USENIX Conference, 1984.

Teitelman, Warren, and Larry Masinter. “The Interlisp Programming Environment.” IEEE Computer, April 1981.

Vinge, Vernor. A Fire Upon the Deep. Tom Doherty Associates, 1992.

Zorn, B. The Measured Cost of Conservative Garbage Collection. Technical Report CU-CS-573-92. University of Colorado at Boulder, 1992.