Лекция RMS в КТИ (Швеция), 1986 год

---

Rms. Кажется, что есть три вещи, о которых люди хотели бы от меня услышать. С одной стороны, я подумал, что лучшее, о чём можно рассказать здесь клубу хакеров,— это на что был похож MIT (Массачусетский технический институт) в прежние времена. Что делало Лабораторию искусственного интеллекта таким особенным местом. Но мне говорят ещё, что поскольку здесь совсем не те люди, которые были на конференции в понедельник и во вторник, что я должен рассказать о том, что происходит в проекте GNU, и что мне следует рассказать о том, почему программы и информация не могут принадлежать кому бы то ни было, это значит — всего три рассказа, а поскольку два из этих предметов заняли по часу каждый, значит, мы тут будем довольно долго. Так что у меня была мысль, что, наверно, я мог бы разбить это на три части, и люди могли бы выйти на тех частях, которые им неинтересны, и что тогда, когда я подойду к концу части, я могу сказать, что это конец, и люди могут выйти, а я могу послать Яна Рюнинга привести других людей.

[Кто-то говорит: “Janne, han trenger ingen mike” (перевод: “Янне, ему не надо микрофона.”).]

Ян, вы готовы выбегать и приводить других людей?

Jmr. Я ищу микрофон, и что-то подсказывает мне, что он — внутри этого запертого шкафа.

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

А всё-таки, установить ли мне эту систему, чтобы оповещать вас о частях рассказа, или вы просто хотите отсидеть все три части? [Ответ: Да-а]

Когда я начал программировать, это было в 1969 году в лаборатории IBM в Нью-Йорке. После этого я пошёл в училище с отделением информатики, наверное, таким же, как большинство из них. Там было несколько профессоров, которые отвечали за то, что предполагалось делать, и были люди, которые решали, кто чем может пользоваться. Большинство ощущало недостаток в терминалах, но у многих профессоров были собственные терминалы в кабинетах, это было расточительно, но типично для них. Когда я посетил Лабораторию искусственного интеллекта в MIT, я обнаружил там более свежую атмосферу. Например, там терминалы считались общими, и профессора, запирая двери в свои кабинеты, рисковали найти свои двери взломанными. Мне даже показывали тележку с большим куском железа, которую употребили для взлома двери кабинета одного профессора, когда тот имел наглость запереть терминал. В те дни было очень мало терминалов, было, наверное, что-то вроде пяти терминалов в системе, так что если один из них был заперт, это было настоящим бедствием.

В последующие годы я был вдохновлён этими идеями, и много раз я карабкался за потолки или под полы, чтобы открыть комнаты, где были машины, которые нужны были людям для дела, и я обычно оставлял за собой записку, объяснявшую людям, что они не должны быть настолько эгоистичны, чтобы запирать дверь. Те, кто запирал дверь, в основном думали только о себе. У них, конечно, были причины, там было что-нибудь, что, как они думали, могло быть украдено, и они хотели запереть это, но они не заботились о других людях, которым были нужны другие вещи, запертые в той же комнате. Почти всякий раз, когда это происходило, как только я обращал их внимание, что то, должна ли быть заперта комната, касается не только их, они обычно были в состоянии найти компромиссное решение: какое-нибудь другое место, чтобы сложить вещи, о которых они беспокоились — стол, который они могли запереть, или другую каморку. Но дело в том, что люди обычно не утруждают себя размышлениями об этом. Они думают: “Эта комната — Моя, я могу запереть её, и наплевать на всех остальных”, а это именно то отношение, от которого мы должны их отучить.

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

Другое, чего у нас в лаборатории не было,— это защита файлов. На компьютере не было никакой безопасности. И мы совершенно сознательно шли на это. Хакеры, писавшие Несовместимую Систему Разделения Времени (ITS), решили, что защита файлов обычно применялась самозваным системным администратором, чтобы получить власть надо всеми остальными. Они не желали, чтобы кто-то был способен таким образом взять власть над ними, поэтому они не реализовали такого рода особенность. В результате когда бы в системе что-нибудь ни сломалось, ты всегда мог это наладить. Тебе никогда не надо было сидеть с чувством безысходности из-за того, что нельзя НИКАК, потому что ты знал точно, что было не так, а кто-то решил, что они не доверяют тебе этого. Тебе не приходится бросать всё и ехать домой в ожидании, пока кто-нибудь придёт утром и наладит систему, когда ты в десять раз лучше его знаешь, что нужно сделать.

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

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

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

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

Но одной из проблем, с которыми мне пришлось столкнуться, была проблема несвободных программ. Например, после ухода хакеров в лаборатории произошло вот что. Машины и программы, которые мы разработали, невозможно было больше поддерживать. Программы, конечно, работали и продолжали работать, если никто их не изменял, но машины — нет. Машины ломались, и не было никого, кто мог бы их починить, и в конце концов их выбрасывали. В былые времена, да, у нас были договоры на обслуживание, но это была по существу шутка. Это был способ достать запчасти после того, как опытные хакеры из лаборатории устраняли проблему. Потому что если ты дашь выездному специалисту по обслуживанию устранить это, это займёт у них несколько дней, а ты не хочешь этого, ты хочешь, чтобы оно работало. Так что люди, которые знали, как это сделать, просто шли и быстро устраняли это, и поскольку они были вдесятеро компетентнее любого из выездных специалистов по обслуживанию, они могли сделать это гораздо лучше. И потом, когда у них оставались пережжённые платы, они просто оставляли их там и говорили выездному специалисту: “заберите их и пришлите нам новых”.

В по-настоящему старые времена наши хакеры обычно дорабатывали и машины, которые поступали из Digital. Например, они построили страничные модули для PDP-10. Сейчас я думаю, здесь [в Стокгольме] есть люди, которые тоже делают такое, но это было очень необычно в те времена. В по-настоящему старые времена, в начале шестидесятых, люди привыкли дорабатывать компьютеры: добавлять всевозможные новые команды, новые замысловатые возможности разделения времени, так что у PDP-1 в MIT к тому времени, когда её списывали в середине семидесятых, было примерно вдвое больше команд, чем было, когда её поставили Digital в начале шестидесятых; у неё были особые аппаратные возможности для распределения ресурсов и необычайные возможности переадресации памяти, что давало возможность назначать отдельные аппаратные устройства конкретным задачам разделённого времени, и ещё многое, о чём я даже толком не знаю. По-моему, они даже встроили своего рода расширенные режимы адресации, они добавили индексные регистры и косвенную адресацию и они по существу превратили её из слабой машины в полуприличную.

Мне кажется, один из недостатков сверхбольших интегральных микросхем — что в машины больше невозможно добавлять команды.

У PDP-1 также была одна интересная черта: можно было уместить интересные программы в очень небольшое число команд. Меньше, чем для любой другой машины с тех пор. Скажем, например, знаменитая экранная заставка “секущиеся квадраты”, которая делала квадраты, которые росли и разбивались на много меньших квадратов, которые росли и разбивались на меньшие квадраты. Это уместилось во что-то вроде пяти команд на PDP-1. И много других прекрасных экранных программ можно было уместить в несколько команд.

Вот чем была Лаборатория ИИ. Но чем ещё отличалась культура хакеров, кроме их анархизма? Во времена PDP-1 только один человек мог пользоваться машиной, по крайней мере, поначалу. Через несколько лет они написали систему разделения времени, и они добавили для этого массу аппаратуры. Но вначале приходилось просто записываться на какое-то время. Ну, конечно, профессора и исследователи, работающие над официальными проектами, всегда приходили в дневное время. Так что люди, которые хотели получить побольше времени, записывались на вечер, когда было меньше желающих, и это породило обычай хакеров работать по ночам. Даже когда была многозадачность, всё равно было легче получить время, ты мог получить больше циклов ночью, потому что было меньше пользователей. Так что люди, которые хотели переделать много дел, всё равно приходили вечером. Но потом это стало кое-чем другим, потому что ты был не один, было ещё несколько хакеров, и так это стало социальным явлением. В дневное время, если ты приходил, ты мог ожидать увидеть исследователей и профессоров, которые не любили машину по-настоящему, в то время как если ты приходил вечером, ты видел хакеров. Стало быть, хакеры приходили вечером, чтобы быть со своей культурой. И у них возникли другие традиции, такие, как принимать китайскую еду в три часа утра. И я помню много восходов из окна автомобиля, возвращающегося из китайского квартала. На самом деле это было очень красиво — встречать восход, потому что это такое тихое время суток. Это чудесное время суток, чтобы идти спать. Это так славно — идти домой, когда небо чуть светлеет и птицы начинают чирикать, ты можешь получить мягкое чувство полного удовлетворения, спокойствия за работу, которую ты сделал этой ночью.

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

Но когда все хакеры ушли из лаборатории, это вызвало демографический сдвиг, потому что профессора и исследователи, которые не любили машину по- настоящему, были так же многочисленны, как и раньше, так что они были теперь доминирующей стороной, а они очень боялись. “Без хакеров, которые поддерживали бы систему”,— говорили они,— “у нас будет катастрофа, у нас должно быть коммерческое программное обеспечение”, и они говорили: “мы можем ожидать, что компания будет поддерживать его”. Время показало, что они были совершенно неправы, но они так и сделали.

Это было как раз когда ожидалось появление новой системы KL-10, и встал вопрос, будет ли на ней установлена Несовместимая Система Разделения Времени или система Twenex компании Digital. Поскольку хакеры, которые, наверное, поддержали бы ITS, ушли, эти академические типы выбрали коммерческое программное обеспечение, и это имело несколько немедленных результатов. Некоторые из них на самом деле не были такими немедленными, но они следовали неизбежно, как понял бы любой, кто размышлял об этом.

Один из результатов — что программы были гораздо хуже написаны и их было труднее понимать; как следствие, людям было труднее вносить в них изменения, которые фактически были необходимы. Другой — что эти программы приходили со средствами безопасности, что неизбежно заставляло людей меньше сотрудничать друг с другом. В старые времена на ITS считалось желательным, чтобы каждый мог заглянуть в любой файл, изменить любой файл, потому что у нас были на это причины. Я помню один интересный скандал, когда кто-то прислал запрос на помощь по использованию программы Macsyma. Это программа символьной алгебры, разработанная в MIT. Он послал одному из людей, работавших над ней, запрос на помощь, и получил ответ через несколько часов от кого-то другого. Он ужаснулся, он послал сообщение: “такой-то и такой-то, должно быть, читает вашу почту, наверное, файлы почты не защищены в вашей системе, как следует?” “Конечно; никакие файлы в нашей системе не защищены. В чём дело? Вы получили ответ раньше. Чем вы недовольны? Конечно, мы читаем почту друг друга, чтобы находить таких людей, как вы, и помогать им”. Некоторые просто не понимают, что для них лучше.

Но, конечно, в Twenex не только есть безопасность, и по умолчанию она включена, но она также разработана в предположении о том, что безопасность используется. Так что там много такого, что очень легко сделать, и это может причинить большой ущерб, и единственное, что может тебя уберечь от совершения такого действия по ошибке,— это безопасность. В ITS мы развили другие средства, делающие маловероятным совершение таких действий по ошибке, но в Twenex у тебя их не было, потому что они предполагали, что там будет действовать строгая безопасность и только у начальства будет власть делать это. Так что они не заложили никакого другого механизма, затрудняющего такие случайные действия. В результате ты не можешь просто взять Twenex и выключить безопасность и получить то, что ты на самом деле хотел, и больше не было хакеров, чтобы сделать изменения и заложить те другие механизмы, так что люди были вынуждены применять безопасность. И примерно через шесть месяцев после того, как появилась машина, они начали некий переворот. То есть, сперва у нас было предположение, что у каждого, кто работал в лаборатории, будет флаг wheel, который даёт полную власть отменять все меры безопасности, но в один прекрасный день ты приходил и видел, что флаг wheel почти у всех снят.

Когда я обнаружил это, я перекинул всё назад. В первый раз оказалось, что я знаю пароль одного из тех, кто был включён в элиту, так что я мог воспользоваться этим, чтобы включить всех обратно. Во второй раз он изменил пароль, он теперь поменял симпатии, он теперь был частью аристократической партии. Итак, мне пришлось выключить машину и применить однозадачный ДДТ, чтобы обойти это. Я немного покопался в мониторе и наконец понял, как заставить его загрузиться и позволить мне его подлатать, так что я мог выключить проверку пароля, и тогда я включил людям всю кучу флагов wheel и послал системное сообщение. Я должен пояснить, что имя этой машины было OZ, так что я послал системное сообщение: “Была ещё одна попытка захвата власти. До сих пор аристократические силы терпели поражение — Радио ‘Свободная OZ’”. Позднее я обнаружил, что “Радио ‘Свободная OZ’” есть в театре Firesign. В то время я этого не знал.

Но постепенно становилось всё хуже и хуже, просто природа принципов, на которых была построена система, вынуждала людей требовать всё больше и больше безопасности. До тех пор, пока я наконец не был вынужден прекратить пользоваться машиной, потому что я отказывался хранить пароль в секрете. С тех пор, как пароли появились в Лаборатории ИИ MIT, я пришёл к заключению, что для того, чтобы следовать своему убеждению о том, что паролей не должно быть, нужно, чтобы у меня всегда был самый очевидный из возможных паролей, и мне следует всем рассказывать, какой это пароль. Из-за того, что я не верю, что на компьютере безопасность на самом деле желательна, я не должен добровольно помогать поддерживать режим безопасности. В системах, которые допускают это, я задаю “пустой пароль”, а в системах, где это запрещено или где это значит, что ты не можешь войти туда из других мест, или ещё что-нибудь, я задаю своё имя пользователя в качестве пароля. Это один из самых очевидных среди возможных паролей. А когда мне указывают на то, что таким образом люди могли бы войти в систему под моим именем, я говорю: “Да, в том-то и мысль, что кому-то может быть необходимо получить какие-то данные с этой машины. Я хочу гарантировать, что безопасность их не отошьёт”.

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

Но та машина также не была задумана для поддержки феномена под названием “туризм”. Сейчас “туризм” — очень старая традиция в Лаборатории ИИ, которая жила вместе с другими нашими формами анархии, она состояла в том, что мы позволяли посторонним приходить и пользоваться машиной. Так вот, во времена, когда каждый мог подойти к машине и войти под каким угодно именем, это было само собой: если ты заглянул в лабораторию, ты можешь войти в систему и работать. Позднее мы это немного формализовали как официальную традицию, особенно когда началась Arpanet и люди со всей страны начали подключаться к нашим машинам. Так вот, на что мы надеялись — это что эти люди на самом деле будут учиться программировать и начнут изменять систему. Если вы скажете это системному администратору в любом другом месте, он будет в ужасе. Если вы предложите, чтобы любой посторонний мог пользоваться машиной, он скажет: “Но что, если он начнёт изменять системные программы?” Но для нас, когда посторонний начинал изменять системные программы, это значило, что он выказывает неподдельное желание стать активным членом сообщества. Мы всегда поощряли их к этому. Начиная, конечно, с написания новых системных утилит, небольших, мы приглядывали за тем, что они сделали, и поправляли это, но затем они переходили к добавлению возможностей к существующим большим утилитам. А это — программы, существовавшие десять или, может быть, пятнадцать лет, вырастая часть за частью по мере того, как один искусник за другим добавлял новые возможности.

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

Но у машин ITS были определённые особенности, которые помогали предотвратить выход этого из-под контроля, одной из них была возможность “шпионить”, когда любой мог подсмотреть, что делает кто угодно другой. И, конечно, туристы обожали шпионить, они думают, это такая классная штука, немного некрасиво подглядывать, но в результате если турист начинает делать что-то, что вызывает неприятности, всегда есть кто-то, кто смотрит за ним. Так что очень скоро его друзья начинают сходить с ума, потому что они знают, что существование туризма зависит сознательности туристов. Так что обычно оказывалось, что кто-нибудь знает, кто был тот парень, и мы были в состоянии указать ему на дверь. А если мы не могли, мы полностью выключали доступ из определённых мест, на некоторое время, а когда мы включали его обратно, к тому времени он уже уходил и забывал нас. И так это продолжалось годы, и годы, и годы.

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

Но когда они впервые получили эту систему Twenex, у них было на уме несколько изменений, которые они хотели внести. Изменений в том, как работала безопасность. Они также хотели, чтобы машина была как в сети ARPA, так и в сети MIT-chaos, и вышло, что они были не в состоянии сделать это, что они не могли найти кого-нибудь, кто был бы достаточно компетентен, чтобы внести такие изменения. Больше не было талантов, чтобы это сделать, и её было трудно изменять. В этой системе было гораздо труднее разобраться, потому что она была так плохо написана, и, конечно, Digital не собирались этим заниматься, так что их мысль о том, что коммерческая система будет по существу сама себя поддерживать, оказалась ошибочной. Они всё так же нуждались в системных хакерах, но у них больше не было возможностей приманивать системных хакеров. И сейчас в MIT больше людей, заинтересованных изощрении ITS, чем заинтересованных в изощрении Twenex.

И заключительная причина, по которой это происходит — это что Twenex нельзя передавать. Twenex — это несвободная программа, и тебе позволено иметь исходные тексты, только если ты будешь хранить их в секрете на определённых скверных условиях, и это придаёт им дурной запах. Если только человек не забывчив (в мире компьютеров есть такие люди, есть люди, которые будут делать что угодно, если их это забавляет, не задумываясь ни на минуту о том, сотрудничают ли они с кем-нибудь другим, но нужно быть изрядно забывчивым, чтобы не замечать, как грустно работать над подобной программой, а это отвращает ещё больше). А если этого недостаточно, есть факт, что каждый год или около того они выдают тебе новый выпуск, заполненный полусотней тысяч дополнительных строк, набитых обезьянами. Потому что они в общем следуют предписаниям школы системной разработки “миллион барабанящих по кнопкам обезьян в конце концов придут к чему-нибудь полезному”.

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

Примерно три с половиной года назад для меня было ясно, что мне следует начать разработку системы свободных программ. Мне представлялись возможными две разновидности системы: во-первых, система типа машины LISP,— по существу, система, точь-в-точь такая же, как машина LISP MIT, которую тогда только что разработали, только свободная и работающая на универсальной аппаратуре, а не на специальных машинах LISP. А другая возможность — более ортодоксальная операционная система, и для меня было ясно, что если я делаю ортодоксальную систему, то мне следует сделать её совместимой с Unix, потому что это сделает переход на неё лёгким для всех окружающих. Очень скоро я пришёл к заключению, что мне следует выбрать второе по той причине, что я понимал, что нельзя сделать что-нибудь действительно подобное системе машины LISP на универсальной аппаратуре. Система машины LISP пользуется специальной аппаратурой плюс специальным модифицируемым микрокодом, чтобы добиться одновременно хорошей скорости вычислений и устойчивого обнаружения ошибок, особенно ошибок в типе данных. Чтобы заставить систему LISP достаточно быстро работать на обычной аппаратуре, мы должны начать делать предположения. Предполагать, что определённый аргумент имеет определённый тип, а когда это не так, система просто даёт сбой.

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

Так что в результате тебе нужно что-то выполняющееся под оболочкой системы LISP, чтобы отлавливать эти ошибки и позволять пользователю продолжать вычисления и давать ему отчёт о том, что произошло. Наконец, я пришёл к заключению, что если я собираюсь делать операционную систему на более низком уровне, то я мог бы с таким же успехом сделать хорошую операционную систему — то есть был выбор между операционной системой с LISP и просто операционной системой; стало быть, мне надо сделать сперва операционную систему и мне надо сделать её совместимой с Unix. Наконец, когда я осознал, что я могу воспользоваться самым занятным в английском языке словом в качестве названия для системы, стало ясно, какой выбор я был просто вынужден сделать. А тем словом было, конечно, GNU, что значит “Gnu's Not Unix” (GNU — не Unix). Рекурсивное сокращение  — это очень старая традиция в обществе хакеров MIT. Она началась, я думаю, с редактора, названного TINT, что значит: “Tint Is Not Teco” (“Tint — это не Teco”), а затем она прошла через такие названия, как “SINE” (“SINE Is Not Emacs”: “SINE — это не Emacs”), и FINE (“Fine Is Not Emacs”: “Fine — это не Emacs”), и EINE (“Еine Is Not Emacs”: “Еine — это не Emacs”), и ZWEI (“Zwei Was Eine Initially”: “Zwei изначально был Emacs”), и в конце концов теперь она дошла до GNU.

Я бы сказал, что с того времени, около двух с половиной лет назад, когда я на самом деле начал работу над GNU, я сделал больше половины всей работы. Когда я готовился начать работу над проектом, я сперва поискал вокруг, что из свободного я мог найти уже готовым. Я узнал об интересной переносимой системе компиляторов, которая называлась “набор свободного университета для компиляторов”[1], и я думал, что с таким названием, я, наверное, могу получить его. Итак, я послал сообщение лицу, разрабатывавшему его, с вопросом, не мог ли бы он передать его проекту GNU, и он сказал: “Нет, университет, может быть, и свободный, а программы, которые он разрабатывает — нет”, но потом он сказал, что тоже хочет получить систему, совместимую с Unix, и он хочет написать что-то вроде ядра для неё, так что почему бы мне не написать утилиты, и вместе их можно было бы распространять с его несвободным компилятором, чтобы поощрить людей покупать этот компилятор. А я подумал, что это предложение смехотворно, так что я сказал ему, что первым моим проектом будет компилятор.

В то время я на самом деле знал об оптимизирующих компиляторах не много, потому что я ни над одним из них никогда не работал. Но я запустил свои руки в компилятор, о котором мне в то время сказали, что он — свободный. Это был компилятор под названием PASTEL, что, по словам авторов, означает “болезненный PASCAL”.

Pastel был очень сложным языком, включающим такие особенности, как параметризованные типы, и явные параметры типа, и много сложных вещей. Компилятор, конечно, был написан на этом языке, и у него было много сложных особенностей для оптимизации использования всего этого. Например, тип “строка” в этом языке был параметризованным; можно было сказать строка(n), если тебе нужна была строка определённой длины; ты также мог просто сказать строка, и параметр определялся из контекста. Ну вот, строки очень важны, и для многих конструкций, пользующихся ими, необходимо быстрое исполнение, а это значит, что у них должно быть много особенностей для обнаружения таких вещей, как: когда объявленная длина строки — аргумент, о котором известно, что он неизменен на протяжении функции, сохранить значение и оптимизировать код, который они собираются сгенерировать, много сложных вещей. Но мне удалось увидеть в этом компиляторе, как делать автоматическое размещение регистров, и некоторые идеи о том, как обращаться с разными типами машин.

Ну, вот. Поскольку этот компилятор уже компилировал PASTEL, что мне нужно было сделать — это добавить предобработчик для C, что я и делал, и добавить постобработчик для 68000, который, как я ожидал, станет моей первой целевой машиной. Но я столкнулся с серьёзной проблемой. Из-за того, что язык PASTEL был определён так, чтобы не требовать от тебя, чтобы ты объявлял что-нибудь перед тем, как ты будешь обращаться к этому, объявления и обращения могли быть в любом порядке, другими словами, паскалевское “предварительное” объявление было в прошлом, поэтому необходимо было прочесть всю программу и держать её в памяти, а потом обрабатывать её всю целиком. В результате промежуточная память, используемая в компиляторе, размер необходимой памяти, был пропорционален размеру вашего файла. И это относилось также к пространству стека, тебе нужны были колоссальные количества стекового пространства, и результатом, к которому я пришёл, было то, что на доступной мне системе 68000 нельзя было запустить компилятор. Потому что это была ужасная версия Unix, которая давала тебе лимит во что-то вроде 16K слов стека, это несмотря на существование шести мегабайт в машине, у тебя могло быть только 16K слов стека или что-то вроде этого. И, конечно, чтобы генерировать свою матрицу конфликтов, чтобы увидеть, какие временные значения конфликтуют или живут в то же время, что и другие, ему нужна была квадратная матрица бит, и для больших функций это занимало сотни тысяч байт. Так что мне удалось отладить первый проход из десяти или около того проходов компилятора, кросс-компилировать на ту машину и затем обнаружить, что второй никогда не сможет выполниться.

Пока я размышлял о том, что делать с этими проблемами, и гадал, стоит ли мне попытаться решить их или написать полностью новый компилятор, между делом я начал работать над GNU Emacs. GNU Emacs — это главная распространяемая часть системы GNU. Это расширяемый текстовый редактор, во многом сходный с изначальным Emacs, который я разработал десять лет назад, кроме того, что он пользуется настоящим LISP в качестве языка расширений. Сам редактор реализован на C, как и интерпретатор LISP, так что интерпретатор LISP полностью переносим, и тебе не нужна система LISP, внешняя по отношению к редактору. Редактор содержит собственную систему LISP, и все команды редактирования написаны на LISP, так что они обеспечивают тебя примерами того, как писать свои собственные команды редактирования, и то, с чего начать, так что ты можешь делать из них команды редактирования, какие тебе на самом деле нужны.

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

Но как бы то ни было, мой друг дал мне эту программу, и моим намерением было поменять команды редактирования высокого уровня, чтобы сделать их совместимыми с первоначальным Emacs, к которому я привык. И заставить их обрабатывать все комбинации численных аргументов и так далее, всё, что можно было бы от них ожидать, и получить все возможности, которые я хотел. Но спустя короткое время я обнаружил, что язык расширений этого редактора, который называется MOCKLISP, не был достаточен для этой задачи. Я обнаружил, что мне придётся немедленно поменять его, чтобы делать то, что я планировал. До этого у меня была мысль, может быть, когда-нибудь заменить MOCKLISP на настоящий LISP, но я обнаружил, что это нужно было сделать с самого начала. Ну, вот, MOCKLISP называется MOCK (фальшивым) потому, что в нём нет никакого рода типов структур: в нём нет списков; в нём нет никакого рода массивов. В нём также нет символов LISP, то есть объектов с именами: для каждого конкретного имени есть только один объект, так что ты можешь напечатать имя и ты всегда получишь тот же самый объект. А это невероятно затрудняет написание многих видов программ, тебе приходится делать вычисления сложными манипуляциями строк, которые на самом деле плохо отражают происходящее.

Так что я написал интерпретатор LISP и поставил его на место MOCKLISP, и в процессе этого я обнаружил, что мне пришлось переписать много внутренних структур данных редактора, потому что я хотел, чтобы они были объектами LISP. Я хотел, чтобы связи между LISP и редактором были чистыми, это означает, что объекты, такие, как буферы редактора, подпроцессы, окна и позиции в буфере,— всё это должно быть объектами LISP, так что примитивы редактора, которые работают с ними, на самом деле можно вызывать как функции LISP с данными LISP. Это значило, что мне требовалось переделать форматы данных всех этих объектов и переписать все функции, которые работали с ними, и в результате примерно через шесть месяцев я переписал в редакторе почти всё.

Вдобавок, из-за того, что было так трудно писать на MOCKLISP, всё, что было написано на нём, было очень нечисто, и переписывая это с использованием мощи настоящего LISP, я мог сделать это гораздо эффективнее и гораздо проще и гораздо быстрее. Итак, я сделал это, и в результате, когда я начал распространять эту программу, от того, что я получил, осталась только небольшая доля.

В этот момент компания, которой Гослинг, как он думает, продал программу, оспорила право моего друга распространять её, а сообщение было в архиве на лентах, так что он не мог найти его. А Гослинг отрицал, что он дал ему разрешение. И тогда произошло нечто странное. Он вёл переговоры с этой компанией, и казалось, что компанию в основном заботило, чтобы он не поставлял ничего напоминающего то, что они поставляли. Понимаете, он по-прежнему поставлял, и компания, где он работал, то есть Megatest, по-прежнему поставляла то же самое, что он дал мне, что на самом деле было старой версией Emacs Гослинга с его изменениями, так что он собирался заключить с ними соглашение, по которому он прекратил бы поставлять это и перешёл бы на GNU Emacs, и они потом признали бы, что у него, в конце концов, в самом деле было разрешение, и предположительно все были бы довольны. И эта компания вела со мной переговоры о том, что она хочет поставлять GNU Emacs, конечно, свободно, но также продавать разного рода услуги по поддержке, и они хотели нанять меня для помощи в этом. Так что есть что-то странное в том, что они потом передумали и отказались подписать соглашение, и вывесили в сети объявление, что мне не разрешено распространять программу. На самом деле они не сказали, что предпримут что-нибудь, они просто сказали, что неясно, могут ли они когда-нибудь сделать что-то. А этого было достаточно, чтобы запугать людей так, что никто не стал бы больше пользоваться ей, а это печально.

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

Итак, я был принуждён переписать всё остальное, что оставалось, и я это сделал, это заняло у меня недели полторы. Так что они одержали грандиозную победу. А я уж никогда не стал бы сотрудничать с ними как бы то ни было после этого.

Потом, когда GNU Emacs стал довольно стабилен, что заняло на всё про всё года полтора, я начал возвращаться к другим частям системы. Я разработал отладчик, который я назвал GDB, это символьный отладчик для программ на C, который недавно вошёл в дистрибутив. Сейчас это отладчик в значительной мере в духе DBX,— отладчика, который входит в берклиевскую Unix. Команды состоят из слова, которое говорит, что ты хочешь сделать, с последующими аргументами. В этом отладчике команды могут сокращаться, и частые команды сокращаются до одной буквы, но любое уникальное сокращение всегда допускается. В нём есть расширяемые средства справки, ты можешь напечатать HELP с последующей командой или даже подкомандами и получить обширное описание того, как применять эту команду. Конечно, можно напечатать любое выражение на C, и он выведет значение.

Можно также делать кое-что необычное для символьных отладчиков C, например, ты можешь сослаться на любой тип C по любому адресу и проверить величину либо присвоить значение. Так что, например, если хочешь разместить число с плавающей точкой по определённому адресу, ты просто говоришь: “Дай мне объект типа FLOAT или DOUBLE по этому адресу”, и затем присваиваешь его. Ещё ты можешь проверить все величины, которые проверялись в прошлом. Каждое проверяемое значение заносится в “историю величины”. Можно сослаться на любой элемент в истории по его порядковому номеру, или можно легко сослаться на последний элемент просто знаком доллара. А это значительно облегчает отслеживание структуры списка. Если есть любого рода структура C, которая содержит указатель на другую структуру, можно просто сделать что-нибудь вроде PRINT *$.next, это значит: “Взять следующее поле из последнего, что ты мне показал, и показать структуру, которая указывает на это”. И можно повторять эту команду, и каждый раз ты увидишь следующую структуру в списке. В то время как в любом другом отладчике C, который я видел, единственный способ сделать это — печатать каждый раз всё более длинную команду. А когда это сочетается с особенностью, что просто нажатие на возврат каретки повторяет последнюю команду, которую ты ввёл, это становится очень удобно. Просто нажимаешь возврат каретки для каждого элемента в списке, который хочешь просмотреть.

Ещё в отладчике есть переменные, которые можно явно присваивать, любое число переменных. Ты говоришь знак доллара с последующим именем, и это — переменная. Можно присваивать этим переменным значения любого типа C, и потом можно проверять их впоследствии. Кроме прочего, это полезно для такого: если есть конкретная величина, и ты знаешь, что ты собираешься часто обращаться к ней, тогда вместо того, чтобы запоминать её номер в истории, можно дать ей имя. Также можно найти им применение, когда устанавливаешь условные точки останова. Условные точки останова есть во многих символьных отладчиках, ты говоришь: “ остановиться, когда ты дойдёшь до этого места в программе, но только если данное выражение истинно”. Переменные в отладчике позволяют сравнивать переменную в программе с предыдущим значением, которое ты сохранил в переменной отладчика. Другое, для чего их можно применять — это подсчёт, потому что, кроме прочего, присваивания — это выражения C, следовательно, ты можешь сделать $foo+=5 для увеличения величины $foo на пять, или просто сделать $foo++. Это можно делать даже в условной точке останова, так что это дешёвый способ останавливать его каждый десятый раз, когда проходится точка, можно сделать $foo--==0. Всем понятно? Уменьшить foo, и если это — ноль, остановиться. И тогда ты устанавливаешь $foo равным числу раз, которое хочешь пропустить, и отпускаешь его. Ещё это можно применять для проверки элементов массива. Предположим, у тебя есть массив указателей, тогда ты можешь сделать:

PRINT X[$foo++]

Но сначала ты делаешь

SET $foo=0

Ладно, когда делаешь это [показывает на выражение PRINT], ты получаешь нулевой элемент X, а тогда делаешь это снова и получаешь первый элемент, и предположим, это указатели на структуры, тогда ты, наверное, поставишь здесь звёздочку [перед X в выражении PRINT], и каждый раз он выводит следующую структуру, на которую указывает элемент массива. И, конечно, ты можешь повторять эту команду, нажимая возврат каретки. Если повторять единственную команду недостаточно, можно создать пользовательскую команду. Можно сказать: Define Mumble, а потом ты даёшь несколько строк команд, а потом говоришь end. И уже определена команда Mumble, которая выполняет эти строки. И очень полезно помещать эти определения в командный файл. В каждом каталоге у тебя может быть командный файл, который будет автоматически загружаться, когда запускаешь отладчик, находясь в этом каталоге. Так что для каждой программы можно определить набор пользовательских команд для доступа к структурам данных, полезный для этой программы. Можно даже снабжать свои пользовательские команды документацией, так что они станут обрабатываться средствами справки точно так же, как встроенные команды.

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

SET $PC=<некоторое число>

Так можно устанавливать счётчик команд. Можно также устанавливать указатель стека, или можно сказать:

SET $SP+=<что-нибудь>,

если хочешь увеличить указатель стека на определённую величину. Но вдобавок можно велеть ему начать с определённой строки в программе, можно установить счётчик команд на определённую строку исходного текста. Но что, если ты обнаружишь, что вызвал функцию по ошибке, что ты на самом деле вообще не хотел вызывать эту функцию? Скажем, эта функция так наворочена, что на самом деле ты хочешь вернуться из неё назад и сделать вручную то, что эта функция должна была сделать. Для этого можно воспользоваться командой RETURN. Ты выбираешь кадр стека и говоришь: RETURN, и это приводит к тому, что этот кадр стека и всё, что он включает, отбрасывается, как если бы эта функция завершилась прямо сейчас, и ты также можешь задать значение, которое она должна вернуть. Выполнение не продолжается; он делает вид, что произошло завершение, и снова останавливает программу, так что ты можешь продолжить изменять что-нибудь другое.

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

В дополнение, одна немножко забавная вещица: в C есть строковые константы, что происходит, если использовать строковую константу в выражении, которое вычисляется в отладчике? Он вынужден создать строку в программе, которую ты отлаживаешь. Ну, он и создаёт. Он формирует вызов MALLOC в этой отлаживаемой программе, даёт MALLOC выполниться и затем получает назад управление. Итак, он невидимо находит место для размещения строковой константы.

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

Есть ещё две главных части системы GNU, которые уже существуют. Одна — это новый компилятор C, а вторая — это ядро TRIX.

Новый компилятор C — это то, что я написал в этом году, начиная с этой весны. Я решил наконец выбросить PASTEL. Этот компилятор C пользуется некоторыми идеями из PASTEL и некоторыми идеями из Переносимого оптимизатора Аризонского университета. Их интересная идея была в том, чтобы адресовать много различных видов машин, генерируя простые команды, а затем комбинируя несколько простых команд в сложную команду, когда целевая машина это допускает. Чтобы делать это унифицированно, они представляют команды в алгебраической записи. Например, команду ADD можно было бы представить так:

  r[3]=r[2]+4

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

Иногда, в зависимости от того, используется ли как-нибудь в дальнейшем результат первой команды, может быть необходимо сделать объединённую команду с двумя операторами присваивания. Одно — для этой величины [указывает на ???], а второе — с этой величиной [указывает на ???], заменённой на то, что приходит из второй команды. Но если этим значением пользовались только один раз, его можно исключить после подстановки; не нужно вычислять его ещё раз. Так что на самом деле несколько сложно сделать подстановку правильно, проверяя, что промежуточные команды не меняют никакую из этих величин, и тому подобное. Когда поддерживаешь такие вещи, как адресация с автоинкрементом или автодекрементом, а я это сейчас делаю, тебе приходится также делать разные проверки этого, чтобы проверять ситуации, где то, что ты делаешь, не сохраняет величины.

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

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

     (set (reg 2)
          (+ (reg 2)
             (int 4)))

Это выглядит, как LISP, но семантика этого не совсем, как в LISP, потому что каждый символ здесь распознаётся обособленно. Есть конкретный фиксированный набор этих символов, который определён, всё, что нужно. И у каждого есть конкретная комбинация типов параметров, например, у reg это всегда целое, потому что регистры перенумерованы, а + принимает два подвыражения, и так далее. И у каждого из этих выражений есть также тип данных, который по существу говорит, фиксированная запятая или плавающая, и сколько байтов — длина. Это можно расширить, чтобы принимать во внимание другие аспекты, если понадобится.

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

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

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

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

Этот компилятор в настоящее время работает с синтаксическим анализатором, который обращает программу C по существу в синтаксическое дерево, аннотированное сведениями о типах данных C. Затем другой проход, который смотрит на это дерево и генерирует код вроде этого [код, похожий на LISP]. Потом несколько проходов оптимизации. Один — чтобы обрабатывать вещи вроде переходов через переходы, переходы на переходы, переходы на .+1, всё, что может быть упрощено немедленно. Потом распознаватель общих подвыражений, потом нахождение базовых блоков и выполнение анализа потоков данных, чтобы знать, какие величины используются в каждой команде, и никогда — после неё. А также связывание каждой команды с местами, где величины, которые ей нужны, генерируются, так что если у меня есть одна команда, которая генерирует псевдорегистр R[28], а потом другая команда позднее, которая пользуется этим псевдорегистром, и это — первое место, где используется R[28], я заставляю второе место указывать на первое, и этот указатель применяется в управлении попытками объединения команд. Объединяются не смежные команды, объединяется команда, использующая величину, с командой, которая произвела эту величину. Даже если есть другие команды между ними, в данном случае это не важно, нужно просто проверить их и убедиться, что они никак не вмешиваются. Потом, после объединителя, к делу приступает динамический распределитель регистров, и наконец нечто, преобразующее это в ассемблерный код.

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

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

Для 68000 код ещё не идеален. Я знаю места, где ранние стадии выполняются не наилучшим образом, потому что он не может полностью заглянуть вперёд. У него есть выбор на ранней стадии, и он делает то, что по его мнению обещает быть лучше всего, но на самом деле, если бы он сделал по-другому, более поздняя стадия достаточно прозорлива, чтобы сделать что-нибудь ещё лучше. Но ранняя стадия не знает, что собирается делать поздняя стадия, так что мне нужно ещё поработать кое над чем из этого.

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

[Вопрос: У вас есть генератор кода для 32000?] Пока нет, но, опять-таки, вам нужен будет не генератор кода, а просто описание машины. Список всех машинных команд в этом [лиспоподобном] виде. Так что фактически кроме работы по воплощению идеи об ограничениях на то, какие аргументы могут быть в регистрах и в каких видах регистров, что было нужно для 68000 и не нужно для VAX, работа по переносу этого компилятора с VAX на 68000 заняла всего несколько дней. Так что переносить очень легко.

В настоящее время компилятор генерирует ассемблерный код и может генерировать отладочные данные как в формате, который понимает DBX, так и в особом внутреннем формате GDB. Я бы сказал, компилятор требует работы только в трёх областях. Первая: мне надо добавить возможность “профилирования” вроде той, которая есть в компиляторах Unix. Вторая: мне надо сделать эти распределения регистров поумнее, чтобы больше не видеть глупостей в выходных файлах. И третья: есть различные ошибки, вещи, которые пока не отрабатываются правильно, хотя он скомпилировал себя верно. Я ожидаю, что это займёт всего несколько месяцев, и тогда я выпущу компилятор.

Другая немалая часть системы, которая существует — это ядро. [Вопрос: перерыв?] А, да, по-моему, мы забыли про перерывы. Почему бы мне не закончить про ядро, это должно занять только около пяти минут, а потом мы можем сделать перерыв.

Ну вот, в качестве ядра я планирую взять систему под названием TRIX (насколько я знаю, это ничего не означает), которая возникла как исследовательский проект в MIT. Эта система основана на удалённом вызове процедур. Так что программы называются доменами. Каждый домен — это адресное пространство и различные допуски, а допуск — это не что иное, как способность вызывать домен. Любой домен может создать “порты допуска” для вызова, и потом он может передать эти порты другим доменам, и нет никакой разницы между вызовом системы и вызовом другого пользовательского домена. Фактически ты не знаешь, что у тебя. Таким образом, очень легко получить реализацию устройств другими пользовательскими программами. Файловую систему можно реализовать пользовательской программой, прозрачно. Сообщения между сетями тоже прозрачны. Ты думаешь, что прямо вызываешь другой домен, а на самом деле ты вызываешь домен сетевого сервера. Он получает данные, которые ты даёшь в вызове, и передаёт их через сеть программе другого сервера, который затем вызывает домен, с которым ты пытаешься общаться. Но вы с тем другим доменом видите это как происходящее невидимо.

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

Особенности, которые, как я считаю, должны быть добавлены, включают номера версий, восстановление удалённых файлов, сведения о том, когда и как и где файл заархивирован на ленте, атомарное замещение файлов. Я считаю, что в Unix хорошо, что когда файл записывается, можно уже посмотреть на то, что там происходит, например, можно вызвать tail и узнать, как далеко зашло дело, это очень славно. А если программа умирает, частично записав файл, видно, что она сделала. Всё это хорошо, но тот частично записанный вывод никогда не должен приниматься за полный вывод, который ты ожидал в конце концов получить. Предыдущая версия этого должна продолжать быть видимой, чтобы каждый, кто пытается пользоваться этим, пользовался ею, пока новая версия не будет сделана полностью и верно. Это значит, что новая версия должна быть видима в файловой системе, но не под тем именем, которое предполагалось. Её следует переименовывать, когда она завершена. Это, между прочим, то, что происходит в ITS, хотя там каждая пользовательская программа делает это явно. Для совместимости с Unix и пользовательскими программами это нужно делать невидимо.

У меня есть хитро запутанная схема, как попытаться заставить номера версий уложиться в существующие пользовательские программы Unix. Это — идея, что ты указываешь имя файла, оставляя номер версии неявным, если ты просто указываешь имя файла обычным образом. Но если ты хочешь указать точное имя, либо потому, что ты хочешь явно задать, какую версию брать, либо потому, что ты вообще не хочешь никаких версий, ты помещаешь в конец точку. Так что если задаёшь имя файла FOO, это значит: “Искать версии, которые есть у FOO, и взять самую свежую”. Но если ты говоришь FOO., это значит: “взять в точности имя FOO, и ничто другое”. Если ты говоришь FOO.3., это говорит: “взять в точности имя FOO.3”, то есть, конечно, версию три FOO, и никакую другую. При выводе, если ты просто говоришь FOO, она в конце концов создаст новую версию FOO, но если ты говоришь FOO., она запишет файл, названный в точности “FOO”.

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

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

И эту идею можно соединить с “выбором звёздочкой”, говоря, что имя, которое не заканчивается на точку, подходит ко всем именам без номеров их версий, так что если в определённом каталоге есть, например, файлы:

  foo.1 foo.2 bar.8

Если я говорю *, это эквивалентно

  foo bar

потому что она берёт все имена и отбрасывает их версии, и берёт все различные имена. Но если я говорю: *., тогда она берёт все имена в точности, ставит точку после каждого, и сопоставляет с ними. Так что это даёт мне все имена для всех индивидуальных версий, которые существуют. И аналогично, понятна разница между *.c и *.c.: это [первое] даст по существу ссылки на все файлы *.c без версий, в то время как это [второе] даст все версии ... ну, на самом деле не даст, надо сказать *.c.*.; здесь я ещё не продумал деталей.

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

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

Что касается поддержки сети, я намерен когда-нибудь реализовать TCP/IP для этой системы. Я также думаю, что можно воспользоваться KERMIT, чтобы получить что-нибудь эквивалентное UUCP.

Командный интерпретатор, я считаю, уже написан. У него есть два режима: один имитирует командный интерпретатор BOURNE, а другой имитирует C-shell в той же программе. Я ещё не получил его копию, и я не знаю, сколько работы он от меня потребует. Также существует много других утилит. Существует MAKE, LS, есть замена YACC под названием BISON, который сейчас поставляется. Существует кое-что весьма близкое к LEX, но оно не полностью совместимо, оно требует некоторой работы. И в общем, то, что остаётся сделать, гораздо меньше того, что сделано, но мы всё ещё нуждаемся в помощи большого числа людей.

Люди меня всегда спрашивают: “Когда это может быть завершено?” Конечно, я не могу знать, когда это будет завершено, но задавать мне этот вопрос — неправильно. Если бы вы планировали платить за это, для вас имело бы смысл пожелать узнать в точности, что вы собираетесь получить и когда. Но поскольку вы платить за это не собираетесь, правильным для вас было бы спрашивать: “чем вы можете помочь ускорить завершение?” У меня есть список проектов, он в файле в MIT, и люди, заинтересованные в оказании помощи, могли бы посылать мне почту по этому адресу Internet, а я вышлю в ответ список проектов. (Интересно, работает ли это (глядя на мел)). Это видно? Это “RMS@GNU.ORG” (просто следите за скачущим мячиком). А теперь давайте сделаем перерыв, а после перерыва я скажу нечто действительно противоречивое. Так что не уходите пока. Если вы уйдёте сейчас, вы пропустите самое интересное.

[Тут у нас был пятнадцатиминутный перерыв.]

Меня просили объявить, как можно получить копии программ GNU. Ну, один способ, конечно, если у вас есть знакомый приятель, у которого есть копия, вы можете скопировать, но если у вас нет знакомого приятеля с копией и вы не подключены к Internet, не можете взять её по FTP, то вы всегда можете заказать ленту с дистрибутивом и послать денег в Фонд свободного программного обеспечения. Разумеется, свободные программы — это не то же самое, что бесплатное распространение. Я дальше подробно это объясню.

Вот у меня руководство по EMACS, прекрасно изданное. С него сделали диапозитивы и напечатали офсетным способом. Хотя вы тоже можете сами распечатать его из исходных текстов, которые включены в дистрибутив EMACS, вы можете получить эти копии из Фонда свободного программного обеспечения. Потом можно будет подойти и посмотреть, и в нём также есть бланк заказа, оттуда можно списать кое-какие данные, и эта картинка [на обложке] тоже некоторым понравилась. Это [указывая на фигуру, за которой гонится RMS верхом на гну] — испуганный программозапиратель, я в своё время о нём расскажу.

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

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

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

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

Когда я вошёл в эту отрасль, когда я начал работать в MIT в 1971 году, мысль о том, что программами, которые мы разрабатывали, нельзя обмениваться, даже не обсуждалась. И то же самое было в Стенфорде и CMU, и у всех, и даже в Digital. Операционная система Digital в то время была свободной. Очень и очень часто я брал программу из системы Digital, например кросс-ассемблер PDP-11, и переносил его на ITS и добавлял кучу особенностей. На эту программу не было авторских прав.

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

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

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

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

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

Идея информационной собственности вредна на трёх разных уровнях. Материально вредна на трёх разных уровнях, и каждому виду материального вреда соответствует свой духовный вред.

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

Вот. Фактически не надо делать ничего особенного, чтобы заставить программу разойтись по всем тем, кто хочет ею пользоваться, потому что они сами могут прекрасно копировать её, и она дойдёт до каждого. Всё, что вам нужно после того, как вы написали программу,— это присесть в сторонке и дать людям делать, что они хотят. Но этого не происходит: вместо этого кто-то преднамеренно пытается воспрепятствовать обмену программой, а фактически он не просто пытается воспрепятствовать этому, он пытается давить на других людей, чтобы они помогали в этом. Всегда, когда пользователь подписывает договор о неразглашении, он по существу продаёт своих товарищей-пользователей. Вместо того, чтобы следовать золотому правилу и сказать: “Мне нравится эта программа, моему соседу она тоже понравилась бы, я хочу, чтобы она была у нас обоих”, вместо этого он сказал: “Угу, дайте её мне. Чёрт с ним, с моим соседом! Я помогу вам уберечь её от моего соседа, только дайте её мне!”, а такое мировоззрение наносит духовный ущерб. Такое отношение: “Чёрт с ними, с моими соседями, дайте МНЕ копию”.

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

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

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

А потом, есть ещё ситуация, когда программа работает адекватно, но она неудобна. Например: в первый раз, когда мы получили графический принтер в MIT, мы сами написали программы, и мы внесли много замечательных особенностей, например, она посылала тебе сообщение, когда твоё задание заканчивало печать, и она посылала тебе сообщение, если в принтере кончалась бумага, а у тебя было задание на очереди, и много другого, это было то, что мы хотели. Потом мы получили гораздо более великолепный графический принтер, один из первых лазерных принтеров, но тогда программу поставляла Xerox, и мы не могли править её. Они не собирались закладывать эти особенности, а мы не могли, так что нам приходилось иметь дело с вещами, которые “наполовину работали”. И было очень огорчительно знать, что мы были готовы, мы желали, мы были в состоянии исправить это, но нам не разрешали. Нас саботировали.

А потом все те люди, которые пользуются компьютерами и говорят, что компьютеры для них — тайна за семью печатями,— они не знают, как они работают. Ну как же они узнают? Они не могут прочесть программы, которыми пользуются. Единственный способ, которым люди узнают, как следует писать программы или как программы делают то, что они делают,— это чтение исходных текстов.

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

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

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

Вот мы и видим: сколько систем табличных вычислений было сделано, каждая — новой компанией, каждая — безо всякой пользы от понимания того, как это делалось раньше? Да, верно, первая такая система не была совершенством. Она, наверное, работала только на определённых видах компьютеров, и что-то она делала не наилучшим из возможных способов. Так что были разные причины, по которым определённые люди хотели бы переписать её части. Но если бы им приходилось переписывать только части, которые они на самом деле желали улучшить, работы было бы гораздо меньше. Ты можешь понимать, как улучшить систему в одном аспекте, и не понимать, как улучшить ту же самую систему в другом аспекте; фактически, у тебя может быть много головной боли с тем, чтобы сделать это так же хорошо. И вот, если бы ты мог взять часть, которая тебе нравится, и переделать только часть, к которой у тебя лежит душа, ты мог бы получить систему, которая лучше во всех отношениях, положив на это гораздо меньше труда, чем это теперь нужно для написания новой системы целиком. Да, мы все знаем, что система часто может выиграть от того, что её полностью перепишут, но это только если ты можешь сначала прочесть старую.

Итак, люди в отрасли программирования выработали метод разбазаривания большого количества своего времени и, таким образом, естественно, увеличения потребности в программистах сверх необходимости. Почему имеется нехватка программистов? Потому что из-за интеллектуальной собственности программисты организованы так, чтобы разбазаривать половину работы, которую они делают, так что нам кажется, что нужно вдвое больше программистов. И таким образом, когда люди указывают на систему интеллектуальной собственности, говоря: “взгляните на высокие показатели статистики занятости, посмотрите, какая это большая отрасль промышленности”, это на самом деле доказывает только то, что люди расточают много денег и времени. Если они говорят о методах повышения производительности программиста, они охотно делают это, если речь идёт о превосходных пакетах разработки, но чтобы улучшить производительность программиста избавлением от того, что сделано явно для снижения его производительности,— нет, они против этого. Потому что это снизило бы число занятых программистов. Есть в этом что-то слегка шизофреническое.

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

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

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

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

Ну вот; люди, которые считают, что они могут владеть программами, в общем приводят два аргумента в пользу этого. Первый — это “я написал её, это дитя моего духа, в ней — моё сердце, моя душа. Как может кто-то забрать её у меня? Где бы она ни оказалась, она моя, моя, МОЯ!!”. Ну, как-то странно, что большинство из них подписывает соглашения, по которым она принадлежит компании, на которую они работают.

Итак, я убеждён, что это одна из вещей, о которой легко можно дорассуждаться до убеждения, что она важна, но точно так же легко можно убедить себя, что это не имеет никакого значения.

Обычно эти люди применяют этот аргумент, чтобы требовать права контролировать даже то, как люди могут изменять программу. Они говорят: “Никто не должен быть в состоянии превратить моё произведение искусства в мешанину”. Ну, представьте, что у лица, которое изобрело блюдо, которое вы планируете приготовить, было бы право контролировать то, как вы можете его готовить, потому что это его произведение искусства. Вы хотите изъять соль, но он говорит: “Ну, нет. Я составил это блюдо, и в нём должно быть ровно столько соли!” “Но врач говорит, что соль для меня небезопасна. Что мне делать?”.

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

Второй ряд их аргументов — экономический. Они говорят: “Как люди будут получать плату за программирование?”, и в этом есть зерно реальной проблемы. Но многое из того, что они говорят,— заблуждение. Оно состоит в том, что не одно и то же — говорить: “если мы хотим, чтобы было много людей, пишущих программы, мы должны обеспечить, чтобы им не приходилось зарабатывать на жизнь другим путём”, с одной стороны, и “нам нужна существующая система, ремесло программиста должно приносить богатство”, с другой стороны. Есть большая разница между обеспечением просто прожиточного минимума и созданием класса денежных программистов, по крайней мере, как это делается сейчас в Штатах. Они всегда говорят: “Что я буду есть?”, но вопрос на самом деле не “что он будет есть?”, а “как он заработает на суши?”. “Будет ли у меня крыша над головой?”, но в действительности подразумевается “как ему купить отдельную квартиру?”

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

Когда у вас есть что-нибудь подобное программе, как бесконечный бутерброд, как дорога, которую нужно проложить один раз, но как только она проложена, совсем не важно, сколько вы будете ездить по ней, нет никаких затрат на её использование, вообще говоря, лучше, если мы не берём плату за пользование ей. И есть множество того, что мы сейчас развиваем и платим людям за строительство. Например, все эти улицы в городе. Очень легко найти людей, которые будут программировать бесплатно; на самом деле невозможно найти людей, которые будут строить улицы бесплатно. Строить улицы — это не такое творческое и интересное занятие, как программирование. Но у нас много улиц, мы находим деньги, чтобы оплатить это, и способ, которым мы это делаем, гораздо лучше, чем если бы мы сказали: “Пусть компании строят улицы и расставят киоски, и тогда каждый раз, когда сворачиваешь за угол, ты будешь платить таксу. И тогда компании, которые выберут хорошие места для улиц,— те будут рентабельны, а другие обанкротятся”.

Есть одна забавная вещь, которая происходит, когда кто-то начинает делать много денег огораживанием чего-нибудь. До этого, бывает, находятся многие и многие люди, которые с неподдельным энтузиазмом и рвением желают работать в этой отрасли, единственный вопрос — как им получить хоть какие-то средства для жизни. Если взять, например, математиков, есть куда как больше людей, которые хотят заниматься чистой математикой, чем фондов на то, чтобы кто-то был чистым математиком. И даже когда вы получаете фонды, вы не получаете очень много, они не живут богато. А для музыкантов это ещё хуже. Я видел статистику того, сколько получает средний музыкант, средний человек, посвящающий большую часть своего времени тому, чтобы пытаться быть музыкантом, в Массачусетсе; это было что-то вроде половины медианного дохода или меньше. Этого едва хватает на то, чтобы жить, это трудно. Но есть много таких, кто пытается делать это. А потом, когда становится вообще возможно получать очень высокую плату за то, чтобы делать что-нибудь, все те люди исчезают, и начинают говорить: “никто не будет этим заниматься, если им не будут хорошо платить за это”.

И я видел, как это произошло в отрасли программирования. Те самые люди, которые работали себе в Лаборатории ИИ, получали очень мало и любили свою работу, теперь не помышляли о том, чтобы работать меньше, чем за пятьдесят тысяч долларов в год. Что произошло? Когда вы ставите людей перед возможностью получать много денег, когда они видят, что другие за подобную работу получают столько денег, они чувствуют, что должны получать то же самое, и таким образом никто не хочет продолжать по-старому. И очень просто после того, как это произошло, думать, что платить людям много денег — единственный из возможных способов, но это не так. Если бы не было возможности делать много денег, у нас были бы люди, которые были бы согласны делать это за небольшие деньги, особенно когда это что-нибудь творческое и интересное.

Вот. Я понимал, что уникальный мир Лаборатории ИИ разрушен, я понимал, что торговля программами была органической частью того, что разрушило его, и я также понимал, как я объяснил раньше, насколько необходимы свободные программы для того, чтобы существовало подобное общество. Но потом, подумав об этом ещё, я осознал все эти аспекты, в которых запирание программ вредит всему обществу, в особенности вынуждая людей продавать своих соседей и вызывая упадок общества. Тот самый дух, который ведёт к тому, что люди смотрят, как кого-нибудь убивают на улице, и никому не говорят. Дух, постоянные проявления которого мы встречаем в таком большом числе компаний вокруг нас. И для меня было ясно, что у меня был выбор, я мог стать частью того мира и чувствовать себя несчастным оттого, что я делаю со своей жизнью, или решить бороться с этим. Итак, я решил бороться с этим. Я посвятил свою карьеру попытке воссоздать общество обмена программами, попытке положить конец явлению запирания общеполезной информации. И система GNU — средство для достижения этой цели. Это техническое средство для достижения общественной цели. С помощью системы GNU я надеюсь сделать прививку пользователям против угрозы программозапирателей.

В настоящее время запиратели по существу заявляют о своей власти делать компьютер человека бесполезным. Когда-то в США были люди, наиболее распространено это было около пятидесяти лет назад, они были в мафии, они приходили в магазины и бары, особенно в бары, когда бары были запрещены, конечно. Они приходили и говорили: “Много мест в округе недавно сгорело. Вы ведь не хотите сгореть, не так ли? Ладно, мы защитим вас от пожаров, вам только придётся платить тысячу долларов в месяц, и мы гарантируем, что здесь пожара не будет”. И это называлось “протекционный шантаж”. А сейчас у нас ситуация, когда человек говорит: “У вас есть замечательный компьютер, и у вас есть программы, которыми вы пользуетесь. Ну так вот, если вы не хотите, чтобы эти программы исчезли, если вы не хотите, чтобы за вами пришла полиция, лучше заплатите мне тысячу долларов, и я дам вам копию этой программы с лицензией”, и это называется “программный протекционный шантаж”.

На самом деле всё, что они делают — это вмешиваются в дела всех других людей, которые делают то, что нужно, но они убеждают, как самих себя, так и нас, остальных, что они выполняют полезную функцию. Ну, на что я надеюсь — это что когда тот парень из программной мафии придёт и скажет: “Ты хочешь, чтобы эти программы исчезли из твоего компьютера?”, пользователь сможет сказать: “Я больше тебя не боюсь. У меня есть вот эта свободная система GNU, и теперь ты ничего не можешь мне сделать”.

Вот. Одно из оправданий, которые люди иногда предлагают для владения программами,— это идея дать людям стимул к производству. Вообще я поддерживаю идею частного предпринимательства, так же как идею надежды заработать деньги производством того, чем другие люди хотели бы воспользоваться, но с этим в отрасли программирования сейчас полный бардак. Производство несвободной программы — не такой же вклад в общество, как производство той же самой программы с тем, чтобы она была свободной. Потому что написание программы — только потенциальный вклад в общество. Настоящий вклад в богатство общества происходит, только когда программой пользуются. А если вы предотвращаете применение программы, вклада в действительности не происходит. Итак, вклад, в котором нуждается общество,— не эти несвободные программы, для производства которых у каждого есть такой стимул; вклад, который нам на самом деле нужен,— это свободные программы, так что в обществе бардак из-за того, что оно создаёт для людей стимул делать то, что не очень полезно, и не создаёт стимула делать то, что полезно. Таким образом, основная идея частного предпринимательства не реализуется, и можно даже сказать, что общество невротично. В конце концов, когда индивидуум поощряет в других поведение, которое плохо для этого индивидуума, мы называем это неврозом. А тут — общество ведёт себя таким манером, поощряя программистов делать то, что плохо для общества.

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

Благодарю за внимание.

[После этого RMS отвечал на вопросы около часа. Я включил только очень немногие из вопросов и ответов в эту версию. Запись была плохой, у меня не было времени проработать, как следует, всю ленту]

В: Кто-нибудь пытался создавать вам проблемы?

О: Единственный раз, когда кто-то пытался мне создать проблему, это были те собственники, так называемые, самозваные собственники Emacs Гослинга. Кроме этого, у них нет оснований для того, чтобы делать это, так что они могут не так уж много. Между прочим, мне бы хотелось привлечь внимание всех к тому, как люди применяют язык для того, чтобы попытаться поощрять людей думать определённым образом и не думать по-другому. Многое из современной терминологии в этой отрасли было выбрано самозваными собственниками программ, чтобы попытаться поощрить вас, попытаться заставить вас смотреть на программы по образу и подобию материальных объектов, которые являются собственностью, и не замечать различий. Самый вопиющий пример этого — термин “пират”. Пожалуйста, отказывайтесь применять термин “пират” для описания тех, кто желает обмениваться программами со своим соседом, как добрый гражданин.

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

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

Когда книги можно было делать только массовым производством, тогда авторские права начали приобретать смысл, а кроме того, это не отнимало у читающей общественности свободу. Как член общества, у которого не было печатного пресса, вы всё равно не могли скопировать книгу. Так что вы не теряли никакой свободы просто из-за того, что были авторские права. Таким образом, авторское право было изобретено и приобрело нравственный смысл из-за технического сдвига. Сейчас происходит обратный сдвиг. Индивидуальное копирование информации всё улучшается и улучшается, и мы видим, что предел прогресса техники — возможность копирования любого рода информации. [перерыв из-за переворота ленты]

Итак, мы снова в том же положении, как в древнем мире, где в авторских правах не было смысла.

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

Для информации, которую каждый может копировать, верно другое. И, следовательно, нравственные понятия, которые подходят к этому,— другие. Наши нравственные понятия рождаются из размышлений о том, насколько определённое дело поможет людям и насколько оно навредит людям. Если объект материален, вы можете придти и забрать этот стул, но вы не можете придти и скопировать его. А если вы заберёте стул, это ничего не будет производить, поэтому оправданий нет. Если кто-то говорит: “Я выполнил работу, чтобы сделать этот стул, и этот стул может быть только у одного человека, почему бы ему не быть у меня”, почему бы и нам не сказать: “Ну да, это разумно”. Когда человек говорит: “Я вырезал биты на этом диске, только у одного человека может быть этот диск, так что не смейте забирать его у меня”, ладно, в этом тоже есть смысл. Если только у одного человека будет этот диск, почему бы ему не быть у парня, который владеет этим диском.

Но когда кто-то другой приходит и говорит: “Я не собираюсь ломать твой диск, я просто хочу по волшебству сделать другой точно такой же, как этот, а потом я заберу его, а ты можешь продолжать пользоваться этим диском точно так же, как раньше”, ну, это то же самое, как если бы кто-нибудь сказал: “У меня есть волшебный копировщик стульев. Ты можешь по-прежнему наслаждаться своим стулом, сидеть на нём, ставить его туда, куда угодно, но у меня тоже будет стул”. Это — хорошо.

Если людям не нужно столярничать, они могут просто щёлкнуть пальцами и раздвоить их,— это чудесно. Но этот сдвиг в технике не устраивает людей, которые хотят быть в состоянии владеть отдельными копиями и получать деньги за отдельные копии. Эта идея применима только к косной материи. Так что они делают всё возможное, чтобы представить программы как материальные объекты. Вы когда-нибудь задумывались, почему, когда вы приходите в магазин программ и покупаете копию программы, она бывает упакована во что-то, что выглядит, как книга? Они хотят, чтобы люди думали, будто они получают материальный объект, и не осознавали, что они на самом деле получили в форме цифровых данных, которые можно копировать.

К конце концов, что такое компьютер, если не универсальная машина? Вы, наверное, изучали универсальные машины Тьюринга, машины, которые могут имитировать любую другую машину. Причина, по которой универсальная машина так хороша — то, что вы можете заставить её имитировать любую другую машину, а инструкции можно копировать и менять,— именно то, что нельзя делать с материальным объектом. И это — именно то, что программозапиратели хотят отнять у общественности. Они хотят получить выгоду от технического сдвига к универсальным машинам, но они не хотят, чтобы эту выгоду получила общественность.

По существу они пытаются сохранить “век материальных объектов”, но он прошёл, и мы должны привести свои идеи о добре и зле в соответствие с действительными фактами мира, в котором мы живём.

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

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

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