Нил Стивенсон - В начале была командная строка

• Название: В начале была командная строка
• Автор: Нил Стивенсон
• Жанр: Прочая околокомпьтерная литература
• Год: 1999
• ISBN: 0380815931

Это «Слово» — слово одного человека — об искусстве (и хитрости) состояния нашего компьютерно-ориентированного существования. А учитывая что этот один человек — Нил Стивенсон — известный писатель, прагматик, провидец, «гикнутый» философ и автор известнейших произведений литературы (Лавина, Криптономикон и т. д.) — это слово стоит чтобы его услышали. Это хорошо аргументированное исследование Стивенсона в немного напыщенном тоне — вдумчивый, весёлый трактат о киберкультуре прошлого и настоящего, тирании в области операционных систем, революции в Интернете, Диснее, не говоря уже о рассуждениях о смысле бытия.

---

Единственные фрагменты этого, которые удобочитаемы, для нормальных людей, — сообщения об ошибках и предупреждения. И все что здесь заслуживает внимания, это то, что Linux не останавливает, и не падает, когда он встречает ошибку; он выдает вразумительную претензию, прекращает попытки запустить какой-то упрямый или поврежденный процесс, и катится дальше. Это было решительно не верно для ранних версий «яблочных» и «мелкомягких» ОСей, по той простой причине, что ОСь, которая неспособна ходить и жевать жвачку одновременно, возможно, не сможет восстановиться от ошибок. Поиск и обработка ошибок требует отдельного процесса, работающего параллельно с тем, который «ошибся». Типа супер-эго, если угодно, что присматривает за всеми остальными процессами, и выскакивает, когда какой-то из них теряется. Теперь, когда MacOS и «Винда» могут делать более чем одну вещь одновременно, они стали значительно лучше обрабатывать ошибки, чем обычно, но они даже не приблизились к Linux или другим Юнихам в этом отношении; и их большая сложность сделала их уязвимыми для новых типов ошибок.

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

Линух не заточен под какие-то централизованные политики, диктующие, как писать сообщения об ошибке и документацию, так что каждый программист пишет свои собственные. Обычно они на английском, даже если учесть, что до фига и больше линуховых программистов-европейцев. Часто они забавны (сообщения, а не программисты — прим. перев.). Но всегда честны. Если какая-то бяка случилась, если программуля просто еще недоделана, или если пользователь что-то воткнул не туда, об этом будет заявлено в лоб. Интерфейс командной строки облегчает программулям надоедание нам небольшими комментариями, предупреждениями, и сообщениями там и тут. Даже если приложение плющит как подбитую субмарину, оно обычно может все еще перебиваться небольшими сообщениями типа «S. O.S.». Иногда, когда вы кончаете работать с программой и закрываете его на фиг, вы обнаруживаете, что оно оставило серию некритичных замечаний и низкоуровневых сообщений об ошибах через окно терминала из которого вы его запустили. Как если бы программное обеспечение болтало с вами о том, как оно было, пока вы с ним работали.

Документация для Linux поступает в форме «человеческих страниц» (man pages — сокращение от manual («Поручик молчать!» — прим. перев. — не от «рукосуйство», а от «руководство»). Вы можете иметь доступ к ним или через ГРАФИЧЕСКИЙ ИНТЕРФЕЙС ПОЛЬЗОВАТЕЛЯ (команда xman) или из командной строки (команда man). Вот образец со страницы руководства для программы вызывающей rsh: «Стоповые сигналы стопят только локальный процесс rsh; это возможно неправильно, но к настоящему времени слишком сложно, чтобы пофиксить, по причинам слишком заумным, чтобы объяснять здесь.»

«Человечьи страницы» содержат много таких материалов, которые читаются подобно кратким мантрам пилотов, борющихся с управлением поврежденными самолетами. Общее чувство, — типа тысяч монументальных, но «темных» усилий, увиденных во вспышке стробоскопа. Каждый программист имеет дело с его собственными костылями и тараканами; он — слишком занят фиксированием их, и улучшением своих программулей, чтобы объяснять вещи подробно или удовлетворить сложные претензии.

На практике вы почти никогда не встретите серьезного «таракана» при прогоне Linux (в смысле, фиксить Линуха кувалдой о «трех пальцах», в отличие от Виндов, приходится очень редко — прим. перев). А если встретили — почти всегда это происходит с коммерческим софтом (различные поставщики продают программное обеспечение, которое работает под Linux). ОпСистема и ее основные программные утилиты слишком важны, чтобы в них водились серьезные жуки. Я работал под Линухом каждый день с позднего 1995-го и видал, как многие «аппликационные» программы рушились напрочь в пламени, но я никогда не видeл аварию самой ОпСистемы. Никогда. Ни разу. Довольно много линуховых систем, которые работают непрерывно и в жестких условиях в течение месяцев или лет, без необходимости в перезагрузке.

Коммерческие ОСи должны принять ту же официальную позицию по отношению к ошибкам, как коммунистические страны — к бедности. Исходя из доктрин, не возможно допустить, что бедность была серьезной проблемой в коммунистических странах, поскольку целью коммунизма являлась ликвидация бедности. Аналогично, коммерческие «осевые» компании, типа «Яблока» и «Мелкософта», не могут пройти мимо допущения, что их программное обеспечение «утараканено» и что оно разрушаеся все время, сколько-нибудь изящнее, чем Disney, который может выпустить пресс-релиз о том, что Микки Маус — просто актер в костюме.

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

Но этого не случается. Корпорации Акционерного Капитала являются замечательными изобретениями, которые дали нам многие отличные товары и услуги. Они хороши в многих вещах. Допущение неудачи не — одно из них. Черт, они не могут даже избежать незначительных недостатков!

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

Некоторые могли бы поспорить, что потребительская досада, со временем, переплавится в своего рода чешую (или мозоль — прим. перев.), которая может скрыть серьезное нарушение, и, что честность могла, следовательно, быть наилучшей политикой, в конце концов; истина все еще «где-то рядом» (слоган «truth is out of there», кстати, нашими телевизионщиками был переведен довольно странно: на самом деле он звучит «истина не здесь», то есть, «правды здесь нет» — прим. перев.) на рынке операционных систем. Бизнес расширяется достаточно быстро, так что до сих пор значительно лучше иметь миллиарды хронически раздраженных клиентов, чем миллионы счастливых.

Большинство системных администраторов, которых я знаю, кто работает с Windows NT все время соглашаются, что, «когда оно падает», приходится его перезагружать, и, когда оно получает серьезные повреждения, единственный путь, чтобы его пофиксить — переустановка операционной системы с нуля. Или, по крайней мере, — это единственный путь, который они знают, чтобы пофиксить эту штуку, что означает тоже самое. Без базара, возможно, что инженеры в Microsoft знают все уловки для «подъема» рухнувшей системы, но если они и знают что-то, они не кажутся склонными делиться с кем-либо из тех системных администраторов «с передовой», которых я знаю.

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

Насколько я знаю, Debian — единственная поставка Linux, которая имеет собственную конституцию (http://www.debian.org/devel/constitution), но что меня в натуре подкупило, так это их феноменальная «тараканья база данных» (http://www.debian.org/Bugs), которая является своего рода диалоговой «Книгой Судного Дня» всех ошибок, угроз ошибок и искупления грехов. Сама простота. Когда возникла проблемка с Debian в начале января 1997-го, я послал туда сообщение, описывающее проблемку на адрес [email protected]. Моей проблемке быстро был присвоен номер сообщения об ошибке (#6518) и уровень опасности (доступные варианты: «критический», «могила», «важно», «нормально», «исправлено» и «просьба трудящихся»), и она была направлена по спискам рассылки, где «дебьянутые» люди «зависают». В пределах двадцати четырех часов я получил пять «электропочтовых» писем, разъясняющих, как пофиксить проблемку: два из Северной Америки, два из Европы, и один из Австралии. Все эти «электрописьма» натолкнули меня на те решения, которые сработали, и избавили меня от проблемки. Но в то же самое время, копия этого обмена опытом была включена в дебиановский «определитель жуков», так что, если другие пользователи поимели ту же проблемку позже, они могли бы глянуть в базу и найти решение, не посылая новых, избыточных сообщений о дефектах.