Может ли компьютерная книга оставаться актуальной через 30 лет после написания?

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

И припомнилась мне при этом старая-престарая по меркам программирования книга под завлекающим названием «Что мама никогда не рассказывала вам о сопровождении VM». В оригинале она называется «What Mother Never Told You about VM Service», автор Melinda W. Varian.

Итак, на минутку, это 1983 год. Только что появилась первая версия MS DOS. Появления CVS еще ждать примерно 8 лет. Unix уже существует, но пока не получил распространения (у нас в Москве он появится в виде Демос примерно в 1986 на машинах СМ-4). Большинство компьютерных книг того времени сегодня безнадежно устарели.

Книга предназначалась для системных программистов — тех, кто занимался сопровождением системы VM (известной также как CP 67, VM/370, VM/SP, VM/ESA и под многими другими названиями).

Казалось бы, может ли такая книга быть интересной сегодняшним админам (пожалуй, это лучшее соответствие для той деятельности, которая тогда называлась системным программированием)? Посмотрим, судите сами.

Итак, книга посвящается тому, как нужно генерировать ядро, применять полученные от IBM обновления и багфиксы, делать бэкапы, и многому другому.

Оказывается, еще и так можно?


Первое, что изменило тогда мои взгляды на программирование — это способ внесения изменений в код ядра. Сегодня мы назвали бы это патч. В принципе, утилита IEBUPDTE была мне известна уже давно, со времен OS/360, и синтаксис с самих патчей для утилиты UPDATE в CMS был очень похожий. Отличие состояло в том, что сами патчи умел генерировать текстовый редактор XEDIT. Вместо изменения оригинального файла он создавал патчи, которые затем применялись при помощи UPDATE.

Сам процесс генерации ядра упрощенно выглядел так — берем дистрибутив, состоявший из исходных текстов ядра на ассемблере S/370, скомпилированных объектных файлов (часть исходников не поставлялась), макробиблиотек, применяем к ядру патчи по списку из так называемого CONTROL файла, далее ассемблер, линкер, и запись ядра на диск.

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

В принципе, ничего сложного.

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

Конечно же, UPDATE (даже вместе с XEDIT) — это не Git. Более того, это даже не CVS. Это примерно соответствует по возможностям RCS, которая впрочем, появилась примерно в это же время. Но это было одно из первых применений версионирования кода, которое мне встретилось на практике.

Правила выживания системного программиста


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

Опустим технические детали, и приведем только список правил, которым автор рекомендует следовать:

  1. NEVER CHANGE ANYTHING IBM SENDS YOU — никогда не меняйте то, что вам прислали из IBM
  2. KEEP YOUR STUFF SEPARATE FROM IBM’S — храните ваши файлы отдельно от файлов IBM
  3. DON’T EXPECT IT TO WORK — не рассчитывайте на то, что это заработает
  4. ALWAYS LEAVE TRACKS — оставляйте следы изменений
  5. VM SYSTEM PROGRAMMERS DO IT VIRTUALLY ALL THE TIME — вы можете проверить новую систему в любое время
  6. BACK IT UP — делайте бэкапы
  7. BACK IT UP AGAIN — делайте бэкапы снова
  8. DON’T TRUST DDR — не доверяйте DDR
  9. CHECK THE UNRESOLVED REFERENCES — проверьте неразрешенные ссылки
  10. PLAN ON BACKING IT OUT — планируйте бэкапы и откаты
  11. YOU ARE ENTITLED TO A HOME TERMINAL — вам полагается свой (домашний) терминал
  12. CHANGE ONLY ONE THING AT A TIME — меняйте только что-то одно за раз
  13. YOU CAN NEVER HAVE TOO MANY S-DISKS S-дисков не бывает слишком много

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

Правило восемь говорило об утилите Disk Dump Restore, что не следует доверять как самим дампам, так и утилите, которая их делает и восстанавливает, особенно в условиях когда лента может и не прочитаться.

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

Остальные пункты очевидны без пояснений.

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

А тогда и подавно, для нашей команды системных программистов эта книга была обязательной к прочтению, и практически настольной, наравне с обычной документацией по VM. Кстати, на форумах для системных программистов z/OS эту книжку до сих пор советуют. Были даже планы выпустить новую, отражающую реалии VM/390.

Не буду дальше пересказывать. Если вам интересна компьютерная история — лучше почитайте сами.

Книга доступна в PDF в интернете, на сайте самой Мелинды. Сохранено оригинальное форматирование, выполненное под существовавшие тогда принтеры.

В ней примерно 120 страниц, и надеюсь она будет интересна всем, кто интересуется историей компьютеров и ОС.

Ну и напоследок, одно правило выживания от себя, которое мы старались не нарушать: Не стоит генерировать систему, если на дворе уже вечер — есть большая вероятность, что останешься на ночь чинить последствия.

Приятного чтения!
Поделиться публикацией

Комментарии 11

    +4
    В 1985 году впервые была выпущена SICP, но идеи из нее актуальны по сей день. А некоторые из них только-только находят свое применение. Ленивость вычислений, реактивные системы, стримы, виртуальные машины, проблемы таксономии, проблемы, возникающие в параллельных системах — все это есть там. Пусть объем материала ограничен, но есть отсылки на другие источники.

    PS. В оригинальной статье автор читает книгу за 2-6 часов. Хотел бы я уметь читать книги уровня SICP и CLRS хотя бы за 10 часов с адекватным пониманием и прорешиванием задач.
      0

      Да, вы правы — есть такой пласт книг, я думаю SICP тут не одинока. Я могу легко вспомнить еще несколько, не сильно напрягаясь. Скажем, Шоу А. Логическое проектирование операционных систем, классическая книга Ахо, Сети, Ульман по компиляторам (ну, эта кажется вышла чуть позже, но совсем не сильно, где-то 1986 примерно).


      В общем-то, многие фундаментальные идеи, которые живы сегодня, были придуманы уже очень давно.

      –1
      Спасибо! :)
        +1

        Да не за что :)


        На самом деле, в VM было много такого, что и сейчас еще остается как минимум любопытным. Тот же XEDIT, в сочетании с REXX, и сам REXX, и например такая штука, как FLIST, которую вполне можно считать прототипом Norton Commander… И электронная почта, в какой-то мере уже, там уже существовала, и даже сети из нескольких машин можно было построить.


        Или скажем, Programmable Operator… В общем-то, весьма тривиальная штуковина, которая позволяла при этом делать очень много всего интересного.

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


        Гм. Мне кажется те, кто пробовал Gentoo, в этом пункте откровений не обретут.
          +3
          Слово «была» относится к тому времени, когда никакого Gentoo не было, а Линус Торвальдс под стол пешком ходил.
            0
            Перечитал внимательно вступление и понял, что неправильно воспринимал пост. Я воспринимал так: «Внезапно старые компьютерные книги могут быть интересны и сейчас. Я [недавно] прочитал эту книгу и хочу вам порекомендовать. Вот примеры интересных идей, которые я из неё вынес:»
          0
          Судя по статье — ответ «нет»?
          Как исторический артефакт — книга может быть и интересна. Но с практической точки зрения полезного в этой книге меньше чем бесполезного и устаревшего.
            0

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


            Ну и VM сама по себе еще вполне себе живая система, хотя и нишевая.

            0
            Итак, на минутку, это 1983 год. Только что появилась первая версия MS DOS.


            MSDOS v.1.0 — август 1981го.
            1983й — это 2.0, 2.01, 2.10

            Появления CVS еще ждать примерно 8 лет. Unix уже существует, но пока не получил распространения (у нас в Москве он появится в виде Демос примерно в 1986 на машинах СМ-4).


            А не Электроника-85?

            Примерно в 1982—1983 годах копии операционной системы UNIX (v6 и v7) были привезены в Москву. На их основе в Институте атомной энергии им. И. В. Курчатова, при участии ряда специалистов других организаций, проводилось приспособление системы к местным условиям — локализация на русский язык и адаптация к отечественной технике, прежде всего — к машинам СМ-4 и СМ-1420. В то же время локализация проводилась в Институте повышения квалификации Минавтопрома, там новая система называлась «МНОС» (Машинно-Независимая Операционная Система). Позже две команды объединились, а система была переименована в «ДЕМОС» (Диалоговая Единая Мобильная Операционная Система). В 1985 году была выпущена версия 2.0 ОС Демос. Проект закрыт в начале 1990-х годов.
            (Вики)

            А вообще, книжка, конечно, наверняка интересная.
              0

              Как вы догадываетесь, я рассказываю свою историю. В моей реальности работающий Демос вообще появился на ЕС-1061, на виртуальной машине под той же VM/SP. Тот что появился в 1986 для СМ, как-то не пошел, слишком велики были требования, и не очевиден профит.


              А DOS… ну да, 1981, но ведь и книга тоже описывала существующие практики, которые появились несколько раньше.

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

            Самое читаемое