От IGA
К Администрация (Кудинoв Игорь)
Дата 26.08.2007 23:51:43
Рубрики В стране и мире;

«Микрософт» должен быть уничтожен

http://www.israelshamir.com/ru/ruart155.htm
«Микрософт» должен быть уничтожен

Исраэль Шамир



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

Никто не возмутился: почему мы обязаны платить налог неизбранной нами американской организации? А «Микрософт» - давно не коммерческое предприятие. Это многомиллиардное средство подчинения информационного пространства одному хозяину. Мы не знаем, какому, вряд ли Биллу Гейтсу, скорее более опасному врагу, одно точно, - этот хозяин сидит не в Кремле. Его «программное обеспечение» полно специальных «черных ходов», через которые в ваш компьютер могут заглянуть американские спецслужбы. Его ни с чем не сообразующаяся цена, сделавшая миллиард пользователей - контрабандистами и нарушителями закона – нарочная уловка. Но ведь и купив «законные» Виндоуз, вы не становитесь хозяином программы – вы только получаете некоторые ограниченные права по ее использованию. В новой версии, Висте, это подчеркнуто – там верховный администратор может разрешить или запретить вам любой шаг.

Предположим, что так обстояло бы дело с машинами. Тогда все машины принадлежали бы, скажем, Генри Форду, а мы бы имели лишь право их водить и чинить. Чинить – только в мастерских Форда. Водить – только по дорогам Форда. Перевозить грузы и пассажиров – только с разрешения Форда. О такой диктатуре и не мечтали Макиавелли и анонимные авторы Протоколов.

«Линукс» попытался дать на это ответ в рамках существующей системы деловых отношений. Но «Микрософт» подал на него в суд за нарушение сотен патентов. Если «Микрософт» прав, это значит, что все патентное законодательство пора менять. Но в качестве полумеры, «Микрософт» следует ликвидировать на территории суверенной России. Эту организацию нужно лишить правовой защиты, ее патенты превратить в общедоступные, как патенты на производство спичек и автомобилей. Россия не может решать за Америку. Если американцы хотят платить – это их дело. Но в России можно и нужно принять закон о деприватизации всего связанного с «Микрософтом» программного обеспечения, даже если для этого нужно будет отказаться от планов на вхождение в ВТО.

Так в США был принят закон о демонополизации компании «Стандард Ойл» Рокфеллера.

Депутат Алкснис предложил разработать нашу собственную операционную систему. По этому пути пошли китайцы. Казалось бы – хорошая идея.

Но недавний иск «Микрософта» к «Линуксу» показал, что это недостаточно радикальный путь. «Микрософт» схватил все патенты. Форд не успел застолбить идею двигателя внутреннего сгорания, но Гейтс успел. Поэтому, еще до разработки своей операционной системы, нужно принять закон, который обесценит и отменит все права «Микрософта» на территории России.

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

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

Чудовищная выдумка лицензирования и патентов должна быть ликвидирована, во имя свободы – нашей и вашей.



PS Несколько реакций читателей http://israel-shamir.livejournal.com/17578.html :

(1) Я как профессиональный Линуксист - истинно говорю - этот пост - и Сталлман бы лучше не написал. Все верно на 150%.Софт должен быть свободен - более того - Линукс показывает, что свободный софт может быть никак не хуже платного.Что касается кривоти и косости - во-первых, это ложь, проплаченная Микрософтом и имплантированная в мозги наиболее тупой части населения.
Во-вторых - если бы деньги, которое ГОСУДАРСТВО тратит на Микрософтовские "продукты" (в по сути - это налог на пользователей компьютеров), потратить на Линукс, то все будет в порядке.
Но насчет патентов - поспешу успокоить - все не так просто 1) С нами IBM, Oracle, DOD и все все все, ну и Господь Бог тоже :-). Патентные закорма IBM - невообразимы - при серьезном желании они могут схватиться с Microsoftom так, что мало не показется. Билл Гейтс - придурок - у Микрософта агония - примерно как у Буша - такая аналогия ближе всего. Линукс реально начал выпускать черную кровь у вРАГА рОДА чЕЛОВЕЧЕСКОГО.
2) На территории России патенты Микрософта в любом случае не действительны - патенты, слава Богу действуют только на территории США.Алгоритмы в России и вовсе патентованию ПОКА не подлежат.
А политическая активность pro-Linux очень нужна, и ликвидация статьи 146 УК (70я для 21 века), и, безусловно, отказ в защите прав, конкретно, корпорации Микрософт в России.
Какие скоты все эти милиционеры и законодатели, которые приняли все это анти-Российское законодательство.
ВТО - НЕТ НЕТ
ЛИНУКС - ДА ДА ДА

(2) И это нужно было сделать, если честно, уже очень давно. Лет тридцать назад. Если посмотреть на историю советского программирования, то создается впечатление, будто американские подстилки правят страной не только последние 22 года, но и раньше. ЕС ЭВМ - это было системное преступление, вполне очевидное уже тогда. Однако, его совершили. И подобное совершали потом в меньшем и большем масштабе не раз и не два. Эльбрус, купленный и замороженный американцами - разработка 80-х годов. Микросхемы. ПК, созданный академиком Наумовым в 1986? году, примерно - помню его письмо, которое он написал, побывав в ЦК или правительстве, кажется. Типа, что все преступники и всему конец. Через месяц он умер.
Но когда-то надо же начинать. Но этот Ваш призыв, в сущности, равен призыву начать национально-освободительное восстание, разве нет? Ну, сбросить иго.

(3) ЭЛЬБРУС - системное преступление (аналогичное ЕС-IBM), потому что в качестве прототипа архитектуры взят БАРРОУЗ (а не БЭСМ6 - компьютер с уникальной архитектурой). Отечественная элементная база не покатила и проект естественно схлопнулся. 1979 - 1989 мы имели дело с CYBER-172 (фирма CDC)- специализированный ассиметричный мультипроцессор с матричным спецпроцессором. Этот комплекс использовался для геофизических исследований(разведка углеводородов). В 1982 к нам приезжал Бабаян - разработчик ЭЛЬБРУСА и клялся, что заменит CYBER - осталось благими пожеланиями. Я не такой уж специалист, просто крутился в этой среде. История ЕС ЭВМ изложена, насколько я могу судить, довольно объективно в википедии http://ru.wikipedia.org/wiki/%D0%95%D0%A1_%D0%AD%D0%92%D0%9C
там, правда, не говорится, КТО конкретно принимал это решение, только глухие слухи, и, вроде бы, все ученые были против. Из бесед с причастными у меня осталось только ощущение, что к 1967 СССР вырвался настолько далеко вперед в области вычислительной техники, что казалось, сегодня-завтра Штатам конец. И в этот момент кто-то просто уничтожил всю эту вычислительную технику одним росчерком пера. Правда, в военную область ЕС так и не проникла. Военные так и пользовались для критичных приложений БЭСМ-6, Эльбрусом и единичными экземплярами БЭСМ-10.
забавно, что так называемый "оконный интерфейс", о котором все спорят БГ и СДж, как говорили, был придуман и воплощен в 1970-х в Институте прикладной математики АН СССР Ильюшиным именно на БЭСМ.
Эльбрус - это ... long and sad tale... это тоже была прорывная разработка, но ее страшно тормозили, и только военные, которые могли позволить себе игнорировать партию, у себя его активно использовали.
написано об этом немало, в сети есть. например, поисковики выдали мне любопытное и печальное интервью http://www.electronics.ru/590.html
Что там теперь творится, я не знаю. но мы все отлично помним, что пока учились в школе и институте, новые поколения ЭВМ появлялись каждые год-два, а потом вдруг все оборвалось, в самом начале 1970-х. Эльбруса мы ждали как... степь ждет дождя, а нам его все не давали, да так и не дали.
ЕС - мне приходилось на них... сидеть. но даже в 1985 было проще сделать работу на двадцатилетней старушке БЭСМ-6, чем на самой мощной из ЕС - та просто не работала.

(4) да, вот еще одно любопытное свидетельство: http://alexvr.livejournal.com/115248.html

вообще, интересно сравнить историю советского юникса, тоже краденой разработки - только не под контролем партии, а на энтузиазме http://news.demos.su/private/demos.html
От IGA
К IGA (26.08.2007 23:51:43)
Дата 28.08.2007 21:10:38

Не всё ладно у Linux

http://nuclight.livejournal.com/122841.html
<<<
Как из Линукса уходят разработчики

Читаю http://apcmag.com/node/6735/ - Con Kolivas, один из разработчиков ядра Linux, известный своей веткой пачтей к ядру -ck (увеличивает интерактивность работы на десктопе, пользовалась большой популярностью), дает интервью по поводу своего ухода из разработки.
Начал он издалека, с тех дней в конце 80-х - начале 90-х, когда рынок персональных компьютеров наполняло все новое и новое оригинальное железо, была конкуренция, чем стимулировались инновации и развитие. Затем постепенно Microsoft подмял рынок софта под себя, и постепенно пришли к ситуации резкого снижения конкуренции, количество производителей железа сильно уменьшилось, оно стало производиться под конкретную ОС. В результате сейчас имеем, что вычислительная мощность растет, а без толку (заметна разве что в непосредственно вычислительных задачах, скажем, сжатию видео и т.п.), каких-либо новых разработок не наблюдается.
Подстегивающую конкуренцию теперь могут оказать разве что только альтернативные ОС, прежде всего Линукс, но тут возникает другая проблема - его разработчики нифига не ориентируются на десктоп. Они смотрят на корпорации, на сервера, а корпоративные пользователи, по его словам, заинтересованы прежде всего в том, что бы выжать еще один процент в очередном бенчмарке базы данных, и т.п. Соответственно, когда ему надоело, что одно приложение может "заткнуть" другое из-за неравномерного распределения ресурсов, в 2002 году он взялся за Си, и стал патчить. Постепенно обрел популярность у очень большого числа пользователей, но в основное ядро его патчи так и не включили. Точнее, включали отдельные мелочи, но толку, когда надо менять архитектуру?..

A scheduler that was deterministic and predictable and still interactive is a much better option long term than the hack after hack approach we were maintaining.


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

If there is any one big problem with kernel development and Linux it is the complete disconnection of the development process from normal users. You know, the ones who constitute 99.9% of the Linux user base.


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

Just trawl the normal support forums (which I did for Gentoo users as a way of finding bug reports often because the users were afraid to tell me) and see how many obvious kernel related issues there are. I'd love to tell them all to suddenly flood lkml with their reports of failed boots with various kernels, hardware disappearing, stopping working suddenly, memory disappearing, trying to use software suspend and having your balls blown off by your laptop, and so on.


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

Вот такие дела. Стоит читать все интервью целиком, да.
<<<
От JesCid
К IGA (28.08.2007 21:10:38)
Дата 11.09.2007 21:50:06

Господи-ты-бож-ж-мой

Кто куда только не уходит.

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

Спасибо. Долго и много ржали (зчркн) валялись под стулом..
От IGA
К IGA (26.08.2007 23:51:43)
Дата 27.08.2007 00:37:16

"Итоги освоения ОС ЕС"

http://tapemark.narod.ru/cejtin.html
<<<
Доклад
«Итоги освоения ОС ЕС (заметки пользователя)»

Дата: 29.08.1983

Автор: Григорий Самуилович Цейтин

Источник: архив академика А. П. Ершова
ИТОГИ ОСВОЕНИЯ ОС ЕС
(ЗАМЕТКИ ПОЛЬЗОВАТЕЛЯ)
Г. С. ЦЕЙТИН

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

1. Вообще говоря, точное воспроизведение некоторых зарубежных образцов техники в условиях отставания соответствующей отрасли у нас в стране может помочь быстрому прогрессу этой отрасли и дать толчок её самостоятельному развитию на новой базе. В применении к машинам ЕС такой эффект в определённой степени сказался. На сегодна мы имеем довольно большое количество программно совместимых машин и взаимозаменяемых периферийных устройств, распространившихся по вычислительным центрам, находящимся в разных городах и принадлежащих разным ведомствам. Стали доступными (иногда для эксплуатации, иногда для изучения) некоторые средства программного обеспечения зарубежной разработки, сложились традиции инициативного обмена оригинальным программным обеспечением между различными разработчиками такого программного обеспечения и просто между пользователями. Были осознаны и в какой-то мере решены проблемы, связанные с широкими масштабами распространения машин и значительным объёмом и сложностью программного обеспечения (тиражирование программного обеспечения, обучение пользователей, распространение руководств и справочных материалов, централизованная ремонтная служба и т. п. — сейчас речь не о недостатках в реализации всего этого).

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

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

2. С другой стороны, необходимо иметь в виду, что заимствованное программное обеспечение, в отличие от «железа» (оборудования), нельзя считать «неодушевлённым»; оно несёт в себе определённые знания, традиции и предпочтения, заложенные в него его авторами и не всегда уместные в наших условиях, а в некоторых случаях прямо выражает коммерческие интересы фирмы-разработчика.

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

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

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

Этот подход распространяется не только на построение системы, но и на её эксплуатацию. Функции различных участников процесса эксплуатации сильно разобщены, для каждого из них составлено отдельное руководство (руководство программиста для такого-то языка, руководство системного программиста, руководство оператора), предполагающее, что никто из них не знает того, что должен знать другой. В зарубежных газетных объявлениях упоминается даже такая особая «специальность», как «JCL writer», т. е. составитель заданий для операционной системы на запуск конкретных программ. (Вообще, руководства по эксплуатации весьма пространны, содержат повторы и рассчитаны на низкий уровень подготовки читателя; напрашивается аналогия с сообщавшимся в нашей печати фактом, что в связи с общим снижением культурного уровня некоторые военные уставы в США приходится снабжать иллюстрациями в виде комиксов.) Ясно, что в наших условиях мы не можем, подобно ИБМ, ориентироваться на привлечение большого количества низкоквалифицированных работников, стимулируемых лишь высокой зарплатой. (Следует заметить, что ИБМ экспериментировала и с интенсивными методами организации разработок, такими, как «бригада главного программиста», но к операционной системе это не относится.

Нужно учитывать также различие между нами и США в структуре научно-технического потенциала в области вычислительной техники. Мы отставали и продолжаем отставать в отношении производства собственно оборудования, но в области разработки программного обеспечения, разработки архитектуры ЭВМ, уровня квалификации специалистов по программному обеспечению положение несколько иное. Мы обладаем в этой области давними научными традициями и достаточно квалифицированными кадрами теоретиков и практиков программирования. У нас, как и у программистов западноевропейских стран, есть традиции систематического программирования, ориентированного на ясность структуры программы и на экономное использование ресурсов; в США же программирование испытало сильное влияние установки на «грубую силу» — большой объём памяти и большие затраты машинного времени. Преимущества европейских традиций в программировании проявились, в частности, в том, что на конкурсе на новый язык программирования, объявленном Министерством Обороны США, победила европейская группа (включавшая французов, немцев и англичан) с языком Ада.

Принятие в этих условиях ИБМ-овского варианта, где ориентация на «грубую силу» оборудования выражена сильнее, чем где-либо, напоминает предлагаемый администрацией Р. Рейгана план «взаимного» сокращения стратегических вооружений за счёт ракет наземного базирования. Отрицательный эффект перехода на машины ЕС уже сказался в том, что была оттеснена на задний план машина БЭСМ-6 с её довольно развитым программным обеспечением, а в некоторых приложениях пришлось переходить с лучших систем программирования на худшие, навязанные машинами ЕС.

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

Далее, оказалось, что заимствованная операционная система ориентирована на характеристики оборудования, которые в наших условиях пока не обеспечены. Речь идёт о вполне надёжном его функционировании и о доступности оборудования и материалов в достаточных количествах. Сбои процессора и периферийных устройств (в первую очередь дисководов) — достаточно обычное явление, а каждый такой сбой приводит к потере значительной части ранее выполненной работы. В некоторых случаях система предусматривает возможность продолжения работы — требует перехода на другой дисковод или НМЛ (обычно таких устройств, которые можно было бы занять вместо давшего сбой, не оказывается), но обычный результат сбоя — это гибель одного задания, а нередко и всех заданий с необходимостью перезапуска всей операционной системы. Операционная система предусматривает на случай сбоя специальное средство — контрольные точки и восстановление, но пользование этим средством довольно громоздко и не всегда возможно: его необходимо включать в задачу заранее. Если бы сбои были достаточно редким явлением, можно было бы специально готовить с учётом этого средства задачи, требующие многочасового счёта, включать же это в каждую задачу нереально. (Некоторые из подобных трудностей, а также некоторые, упомянутые далее, частично преодолены в системе КРОС (HASP), представляющей собой надстройку над ОС ЕС и расходующей значительный объём оперативной памяти.)

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

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

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

Бичом существующих машин ЕС стала ненадёжная работа дисководов, частые сбои, неполная взаимозаменяемость между однотипными устройствами (запись, сделанная на одном устройстве, ненадёжно читается на другом), иногда выход дисковода из строя на длительное время. Одна из причин этого, видимо, в том, что были заимствованы количественные параметры дисководов ИБМ (размеры, плотность записи, скорость вращения и т. п.) без возможности воспроизвести тот же уровень технологии, снабжения запчастями и т. п. В наших условиях имело бы смысл, не прекращая усилий, направленных на повышения качества изготовления, учесть уровень, достижимый на сегодня при массовом выпуске дисководов и пакетов дисков, и компенсировать ненадёжность оборудования изменением количественных параметров (например, снижением плотности записи), а также такими средствами, как использование кодов, исправляющих ошибки (при небольших дополнительных затратах памяти они во много раз повышают надёжность); всего этого нельзя было почерпнуть в пресловутом «прототипе».

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

3. Остановимся на некоторых технических недостатках системы. Прежде всего, бросается в глаза значительный объём и громоздкость системы. Это не только следствие технологии её разработки, но связано и с исходной постановкой задачи. Чуть ли не по каждому вопросу система предлагает пользователю широкий выбор вариантов для достижения примерно одной и той же цели. Для хранения информации на внешних носителях предлагаются форматы F, FB, U, V, VS и другие комбинации (кстати, метод хранения информации на магнитных дисках с членением на записи разной длины в пределах одной дорожки является производным от методов, разработанных для более старого носителя — магнитной ленты). Для работы с последовательными наборами данных предлагаются методы BSAM, QSAM с разными вариантами пересылки и буферизации, однако же, несмотря на это разнообразие, приходится обеспечивать ещё и метод EXCP с непосредственным построением команд для внешнего устройства. Для запроса оперативной памяти предлагаются варианты с регистровым запросом, с запросом на одну область или на много, с указанием того или иного подпула. Для перехода задачи в ожидание некоторого условия, необходимого для продолжения работы, существуют разнотипные методы WAIT, ENQ, STIMER. Для обработки ошибок и аномальных ситуаций — SPIE и STAE. Даже на уровне операционной системы в целом помимо системы ОС существует несовместимая с ней система ДОС, предназначенная как будто бы для машин с малым объёмом оперативной памяти (на практике это приводит к тому, что в вычислительном центре, эксплуатирующем ОС, ради пропуска одной программы, написанной в ДОС, приходится останавливать всю работу и весьма непроизводительно использовать мощную машину).

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

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

Обеспечение разнообразия вариантов, в том числе и действительно необходимых, основывается обычно на построении «универсальных» управляющих блоков, где заранее представлены все возможности (и оставлен небольшой резерв на будущее развитие). Однако таким образом будущие потребности предвидеть не удаётся. Для управляющих блоков создаются дополнительные вынесенные части, а введение новых функций сопровождается организацией дополнительных проверок и выходов в старых модулях. Следовало бы с самого начала предусмотреть более гибкую структуру управляющих блоков, а варианты функционирования в случаях, где вероятно расшиение, изображать не битами, а адресами вынесенных подпрограмм. Сейчас же блок DCB, предусматривающий всевозможные типы периферийных устройств, нельзя стандартным образом перестроить на использование вместо периферийного устройства моделирующей его пользовательской программы (впрочем, какие-то возможности появляются вместе с ОТМД (TCAM)).

Сам языковой аппарат, основанный на использовании ключевых и позиционных параметров (и подпараметров) с умолчаниями, без которого пользователь вообще не смог бы воспользоваться системой, не имеет в системе систематической реализации. Естественно было бы ожидать, что система обеспечит единый механизм хотя бы для синтаксического разбора текстов с такой структурой, но его нет, и каждый блок системы производит разбор текста кустарным образом, что сильно удлиняет программы. Например, при анализе операторской команды типа M 130,VOL=(SL,DLIB01) производится проверка на группу символов 'VOL=(SL,' . Кроме того, в результате нет полного единства в синтаксисе и в написании ключевых слов между разными компонентами системы (программа системного вывода требует указывать умолчания ключевых параметров в операторе PROC без знака & и не обязательно для всех ключевых параметров, а ассемблер в макроопределениях — наоборот; сокращение DSN вместо DSNAME допускается на языке управления заданиями, но не для системных утилит). Свободный формат, основанный на ключевых словах, беспорядочным образом чередуется с жёстким форматом 80-байтовых «карт», разделённых на поля, (ещё один пережиток использования устарелых носителей данных) и особыми (неодинаковыми в разных случаях) правилами «переноса» на следующую карту. В результате при обращении к процедуре языка управления заданиями ключевые параметры можно заменять в произвольном порядке, а DD-предложения — только в порядке их следования в процедуре; в предложении EXEC параметры, относящиеся к разным пунктам процедуры, можно заменять только в порядке следования этих пунктов, хотя запись этих замен использует свободный формат. Выдача операторской команды START с очень длинным полем PARM приводит к ошибке языка управления заданиями из-за того, что главные планировщик первоначально преобразует эту команду в задание в 80-байтовом формате (откуда это знать оператору?). Эти и подобные курьёзы хорошо знакомы тем, кто повседневно работает с ОС ЕС.

Реализация многих часто встречающихся функций операционной системы довольно неэкономна. Это относится даже к таким часто встречающимся функциям, как WAIT и GETMAIN, для которых основная часть команд SVC-программ посвящена контролю допустимости параметров (аппаратный контроль при переходе в режим супервизора частично отключается), подготовке учётной информации и рассмотрению специфических случаев. Не случайно даже реализация языка ПЛ‑1, выполненная тем же разработчиком, избегает пользоваться командой GETMAIN для каждого запроса на память и создаёт собственную систему. А в SVC-программах, равно как и в стандартных рекомендациях по организации входа в реентерабельный модуль, GETMAIN широко используется даже для получения маленьких блоков памяти.

Ряд ограничительных установок, принятых в начале разработки прототипа ОС ЕС, и, возможно, уместных в тот период (более 20 лет назад), оказались совершенно неприемлемыми в период широкого освоения этой системы у нас в стране. Это прежде всего отсутствие динамического распределения ресурсов (наборов данных, периферийных устройств) и отсутствие диалогового режима обращения к наборам данных и запуска заданий. («Официальные» решения части этих проблем пришли лишь в последний момент и, как всегда, в виде громоздких надстроек над старой системой.) Эти ограничения системы привели к своеобразному взрыву инициативы пользователей, которые в разных местах, независимо друг от друга и в условиях жестокого недостатка информации о внутренних механизмах ОС разработали и внедрили ряд диалоговых систем, полностью или частично решающих эти проблемы (в МИФИ — PRIMUS, в Ленинградском университете — JEC, в ДВНЦ АН — DED, и т. п.). Эти системы широко распространились за пределами первоначально разработавших их коллективов и оказались во многих случаях лучше приспособленными к потребностям пользователей, чем появившиеся поздней системы, адаптированные с прототипа. (Достаточно заметить, например, что одной из первых решавшихся при этом задач было сохранение информации в случае сбоя операционной системы.) Эту инициативу пользователей можно было бы только приветствовать, пожалев лишь, что с самого начала не было координации этих работ (хотя соревнование разработок имеет свои преимущества). Однако надо учесть, что препятствия, на преодоление которых было затрачено столько усилий, были всего лишь результатом устарелых исходных установок при разработке ОС ЕС, вернее, OS/360; пользователи других операционных систем не могут сдержать улыбки, слыша о наших «великих проблемах».

Можно, кстати, заметить, что принцип статического выделения ресурсов, имевший целью, видимо, предотвращение системных тупиков, не сработал и в этом отношении. При размещении на дисках временных наборов данных, необходимых для заданий, начальное отведение памяти производится заранее (статически), но во время работы допускается захват дополнительных участков, что при общей нехватке места на дисках может привести к неразрешимому конфликту между двумя заданиями, каждому из которых нужна дополнительная память. Вот ещё один пример. В системе с MVT возможна такая ситуация: задание не может начаться из-за отсутствия участка памяти требуемых размеров, который освободится лишь после завершения другого задания. Тем не менее некоторые имена наборов данных уже захвачены им в монопольном режиме, из-за чего другое задание с этими именами и с меньшим запросом на память не сможет начаться. Оператор может выдать команду CANCEL для первого задания, но она будет исполнена лишь после того, как оно получит свой (большой) участок памяти.

Ещё одна «проблема», вызвавшая взрыв самодеятельности, это отсутствие в ОС ЕС средств подготовки текстовых документов (хотя ИБМ для подготовки своих руководств таким средством пользовалась). В условиях дефицита машинисток эта проблема сразу дала себя знать и вызвала к жизни огромное число параллельных разработок разного качества. Аналогичное положение имеет место для средств запуска системных утилит с консоли оператора.

Представляются недостаточными средства защиты программ и данных, предусмотренные оборудованием и операционной системой ЕС. Большая часть средств защиты основана на неосведомлённости пользователя, которому не сообщается, например, структура загрузочного модуля и от которого рекомендуется прятать программу IMASPZAP, корректирующую загрузочные модули. Если же речь идёт о хорошо подготовленном злоумышленнике, то здесь аппаратура обеспечивает лишь один уровень защиты — ключ памяти. Тот, кто сможет получить для своей программы нулевой ключ памяти, сможет любым образом нарушить функционирование системы, например, вывести её из строя, заодно уничтожив сборный протокол, или, не создавая видимых нарушений, перенести в выдачу своей программы таблицу паролей в преобразованном для неузнаваемости виде, или же, наконец, внести желательные для себя изменения в операционную систему на будущее. Получение же нулевого ключа памяти также не является трудной задачей. В системе с MFT сведения о ключе программы, вызвавшей другую программу, хранятся в блоке PRB в незащищённой области памяти и их там легко изменить. В системе с MVT такой возможности до последнего времени как будто бы не было (хотя достаточно было произвести незначительное изменение, скажем, в библиотеке процедур — и оператор, не зная того, вместо программы системного ввода запустил бы в привилегированном режиме совсем другую программу). В последних же изданиях системы присутствует команда MODESET, которая позволяет законным образом произвести любое изменение режима (и это, возможно, оправдано для некоторых системных программ). В описании блока JSCB содержится «успокаивающая» информация о том, что один из битов определяет право задания на выдачу команды MODESET. Но это не соответствует действительности: команда MODESET никаких проверок не делает и работает независимо от этого бита. Здесь не просто отсутствие контроля, а лживая информация о его присутствии. Заметим попутно, что другие компроненты системы, например, команда OPEN, затрачивают значительное время на проверку законности запроса.

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

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

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

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

4. Немалые издержки связаны с тем, что ОС ЕС задумана как точная копия зарубежного образца.

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

Объём разрабатываемого за рубежом программного обеспечения растёт, и с ним растёт необходимый объём работ по адаптации. Помимо системного программного обеспечения необходимо приобретать и адаптировать прикладное программное обеспечение (без него не имело бы смысла заимствовать операционную систему); кстати, каждый прикладной пакет имеет меньшее распространение, чем системное обеспечение, и приобрести его «безлицензионным» методом труднее. В целом при таком положении темпы адаптации могут отстать от темпов зарубежных разработок. Уже сейчас некоторые системные программисты, которым удаётся получить оригинальный вариант зарубежной системы, начинают использовать его, не дожидаясь адаптации его нашими разработчиками. В любом случае при условии адаптации наш пользователь получает вариант примерно десятилетней давности.

О трудностях адаптации говорит и тот факт, что в последних изданиях ОС ЕС ряд важных компонент исключён из понятия операционной системы (они переведены в ранг дополнительных «пакетов»). Это можно рассматривать и как реакцию разработчика на возросший объём работ по адаптации.

Сама адаптация, как предполагается, состоит в подробном разборе полученных программ, в доскональном понимании принципов их функционирования, а также во включении в программы наших обозначений операционной системы и аппаратуры и составлении руководств на русском языке (обычно путём перевода с английского). К сожалению, степень понимания полученных программ невозможно точно оценить и проверить. На вопрос о назначении той или иной детали не всегда возможно разумно ответить. При этих условиях (учитывая также дефицит времени и сил на адаптацию) возможны и необнаруженные ловушки, специально устроенные противником. (Недавняя операция ФБР США против японских фирм Хитати и Мицубиси, стремившихся получить материалы о последних разработках ИБМ, делает такое предположение правдоподобным.) Не принадлежит ли к числу таких ловушек упомянутая выше команда MODESET? (Если говорить конкретно об этой команде, то её появление объясняется, скорее всего, не диверсией, а неаккуратным сочетанием модулей, заимствованных из разных версий прототипа.)

Вот ещё один пример, более старый. В аварийных дампах ОС ЕС в режиме MFT обращало на себя внимание неоднократно встречавшееся странное слово RENZTIEW. Как выяснилось при более внимательном изучении, оно всегда стояло в конце блока SVRB, связанного с SVC-командой аварийного завершения, и засылалось туда специально одним из модулей этой SVC-программы. Чем мотивировано это слово? (Кстати, иногда такие слова служат ориентиром для других модулей ОС ЕС.) Был проделан эксперимент — в соответствующем модуле SVC-программы это слово было заменено на совсем другое — на фамилию одного сотрудника. Система продолжала работать как ни в чём не бывало, выдавая теперь на всех дампах эту фамилию. Итак, на эту роль может быть выбрано любое слово, и оно будет появляться на всех аварийных дампах, поэтому оно может быть использовано для идентификации экземпляра операционной системы, незаметной для не очень внимательного пользователя. Первые четыре буквы слова RENZTIEW входят также в название фирмы LORENZ, сыгравшей роль в получении нашими разработчиками сведений об OS/360. Не было ли это слово меткой экземпляра OS/360, переданного из ИБМ этой фирме?

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

Ещё одним результатом распространения ОС ЕС стала своего рода экспансия английского языка. Заменить английские тексты сообщений ОС на русские оказалось невозможным, так как они разбросаны по самым разным местам системы, и не всюду вместо них можно вставить другие тексты, не затрагивая всего остального. В ОС ЕС нельзя даже свободно пользоваться русским алфавитом (в документации есть отдельный том об употреблении букв кириллицы — так на западный манер разработчики величают русскую азбуку), и приходится писать в программах идентификаторы латиницей, коверкая русские слова, а то и переходя на английские, тоже перевранные. Для серьёзной работы с операционной системой необходимо владеть английским языком, и некоторые системные программисты уже говорят о себе: «владею английским языком в объёме ОС ЕС», а разработчики учатся писать документацию по-английски ради взаимодействия с ... партнёрами по СЭВ. Ещё хуже положение рядового или эпизодического пользователя, получающего на машинной распечатке загадочный английский текст. В отличие от англоязычного пользователя он вынужден сразу же обращаться к справочнику, а справочник поступает только как часть документации операционной системы. Издать наиболее важные тома документаци в виде книг нельзя: это было бы нарушением авторских прав фирмы ИБМ, с документации которой переведены эти материалы. (В результате пользователю приходится довольствоваться разного рода полуграмотными «пособиями».)

5. Одним из результатов распространения ОС ЕС явилось ещё и то, что громоздкий стиль построения этой системы и её документации стал рассматриваться у нас как единственно возможный стиль промышленной разработки. Это нашло отражение в действующих стандартах ЕСПД (где, в частности, все примеры основаны на ОС ЕС) и в сложившейся практике официальной приёмки и распространения средств программного обеспечения. Есть тенденция применять такой подход ко всякому вообще программному продукту, независимо от того, на какую категорию задач и пользователей он рассчитан, какова его предполагаемая сфера распространения и долговечность (программы, создаваемые в расчёте на вечное использование, рискуют устареть раньше других). Сторонники этого подхода не учитывают, что и за рубежом существуют другие формы разработки и распространения программного обеспечения. Достаточно сослаться на программное обеспечение для персональных ЭВМ, разрабатываемое индивидуальными авторами и распростраяемое фирмами в виде гибких дисков (есть, говорят, авторы, удостоенные «золотых дисков»). В качестве примера совершенно иного стиля разработки можно сослаться и на операционную систему UNIX, которая в последние годы завоевала широкий рынок и легла в основу крупных промышленных систем. Авторы этой системы связывают её успех с тем, что она разрабатывалась без определённого технического задания и её развитие направлялось потребностями сравнительно небольшого коллектива высококвалифицированных пользователей (включавшего и самих авторов). Некоторые зарубежные авторы открыто издеваются над громоздким «производственным» стилем программирования, при котором пустяковая задача, требующая лишь пары строк на языке высокого уровня, разрастается из-за мелочных комментариев, служебных отметок, контрольных распечаток и инструкций по их удалению на несколько страниц текста. Таким образом, ссылки на зарубежную практику не могут оправдать сложившиеся у нас однобокое понимание промышленного продукта.

Между тем этот подход стал непреодолимым препятствием для официальной приёмки и распространения многих отечественных программных средств, особенно тех, которые созданы инициативно, под влиянием текущих потребностей эксплуатации ЭВМ высококвалифицированными программистами, работающими в непрофильных организациях. Редкий вычислительный центр не имеет хотя бы чего-нибудь из подобных программных средств, системные программисты списывают их друг у друга, как песни любимых ансамблей. И в то же время с официальной точки зрения это всего лишь нестоящие мелкие «поделки», не имеющие даже статуса рацпредложений, а их авторы (зачастую анонимные) низведены до уровня «умельцев-кустарей». Пренебрежительное отношение к «умельцам» связано, возможно, с тем, что их путают с известной из нравоучительных переводных книг по программированию одиозной фигурой «суперпрограммиста» — неуправляемого маньяка, быстро пишущего программы и скрывающего от окружающих их секреты (скорее всего, это даже и не маньяк, а просто рвач). Реальные разработчики инициативного программного продукта у нас обычно ориентируются на потребности пользователя и хорошо понимают, что и в каком объёме надо объяснять и документировать (средства технологической поддержки и документирования разработок тоже часто создаются инициативно). Эти разработчики создают документацию, достаточную для толкового пользователя (обычно на машинном носителе, чего ГосФАП до сих пор не допускает, несмотря на существование соответствующего ГОСТа), но конечно, они не станут составлять инструкцию о режиме транспортировки и хранения магнитной ленты с программами или, скажем, давать подробное объяснение логики программы, рассчитанное на малоквалифицированного программиста из посторонней организации, которому, быть может, захочется изменить программу (квалифицированный программист воспользуется для этого текстом программы).

Интересно, что влияние традиций ИБМ проявилось не только в вопросе о том, какие документы должны быть, но и в том, каких документов не должно быть. Например, не отражена в ЕСПД документация для пользователя в форме подсказки из ЭВМ в интерактивном режиме. Так же вслед за ИБМ от пользователей стали скрывать исходные тексты программ; это делают даже при адаптации такого программного обеспечения, которое в оригинале всегда сопровождалось исходными текстами.

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

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

6. Критикуя принятое когда-то решение о следовании разработкам фирмы ИБМ, многие задаются вопросом: как это могло случиться? Что это было: непростительная безответственность и близорукость? торжество чьих-то узкоэгоистических интересов? или, по выражению голландского учёного Э. В. Дейкстры, победа США в холодной войне с СССР?

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

Прежде всего, нельзя отрицать достигнутого прогресса в производстве оборудования. К тому же, развитие производства — это не адаптация программного обеспечения: завод, и даже технологию, не спишешь с магнитной ленты, это надо создавать самим. В использовании архитектуры Системы/360 ИБМ самом по себе тоже нет ничего плохого (хотя, вероятно, и с нашим опытом конца шестидесятых годов, мы могли бы выбрать лучший образец для подражания). Далее, если воспроизводится архитектура машины, естественно испытать на ней и заимствованную операционную систему. Это даже необходимо, чтобы проверить функционирование аппаратуры в реальных условиях и ознакомиться с проблемами эксплуатации новых машин. Что же, нужно было и дальше следовать этим путём?

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

Во всяком случае, урок освоения ОС ЕС ясен: можно, и иногда нужно осваивать отдельные образцы зарубежного программного обеспечения, но нельзя становиться на путь постоянного следования за ними.

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

Но необходимо не только поддерживать разработку и производство других типов машин и операционных систем, но и делать усилия для выхода из порочного круга подражания «прототипу». Надо учесть, что и некоторые зарубежные фирмы, производящие аналоги ИБМ-овского оборудования, вносят в него изменения, так что получаются системы, лишь частично совместимые с продукцией ИБМ. Надо прилагать усилия к самостоятельным разработкам, в том числе и на базе существующей операционной системы, не заботясь о совместимости с будущими разработками ИБМ. Можно продолжать использовать существующую производственную базу для выпуска машин ЕС, разрабатывая для тех же машин новые операционные системы и даже (для машин Ряда-2 с микропрограммированием) новые системы команд. Трудно обойтись без соревнования различных направлений в этой области, лишь опыт может показать, что лучше.

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

http://ru.wikipedia.org/wiki/%D0%95%D0%A1_%D0%AD%D0%92%D0%9C
<<<
...
Предпосылки возникновения серии ЕС ЭВМ

Решение об их выпуске было принято в конце 1960-х. Тогда в СССР производились десятки различных несовместимых друг с другом моделей ЭВМ, что затрудняло решение крупных вычислительных и организационных задач. Для осуществления проектов АСУ (автоматизированных систем управления) была крайне желательна унификация компьютерных средств.

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

Однако этот крупномасштабный проект был запущен без должного исследования состояния системы-оригинала, а ведь уже в начале 1970-х в американской литературе система IBM 360 весьма критиковалась как неудачная в техническом отношении (хотя и очень успешная коммерчески). Свою роль сыграла и презентация, сделанная в США для советской правительственной делегации во главе с премьер-министром А. Н. Косыгиным в 1971 г., демонстрировавшая успешное повсеместное использование линии IBM 360.
...

Оценка

Роль ЕС ЭВМ в развитии отечественной информатики неоднозначна.

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

Ценой этого было повсеместное свёртывание собственных оригинальных разработок и попадание в полную зависимость от идей и концепций фирмы IBM, причём далеко не самых лучших по тому времени. Резкий переход от простых в эксплуатации советских машин к намного более сложным аппаратным и программным средствам IBM/360 привёл к тому, что многие программисты стали зациклены на преодолевании трудностей, связанных с недоделками и ошибками IBM-овских разработчиков. Начальные модели ЕС ЭВМ по эксплуатационным характеристикам нередко уступали отечественным компьютерам того времени.

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

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

Причины трудностей, связанных с внедрением ЕС ЭВМ

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

* Объективные трудности мировой компьютерной индустрии, связанные с выработкой единых норм и стандартов на программы и оборудование;
* Неудачный выбор прототипа;
* Негибкое решение о повсеместном массовом внедрении, исключающее другие пути развития;
* Эмбарго на продажу компьютерной техники, объявленное Советскому Союзу после ввода советских войск в Афганистан 1980, что затрудняло апробацию альтернативных решений;
* Недостаточный анализ опыта и ошибок компьютерной индустрии капиталистических стран, который вполне был представлен в литературе, отчего те же ошибки повторялись с ещё более пагубными последствиями;
* Поначалу основной голос в принятии решений играли специалисты по оборудованию, в то время как разработки программного обеспечения считались вторичными и возлагалась большая надежда на западные программы. В результате основным показателем считалась мощность и аппаратная надёжность, а показатели практичности операционной системы и программной среды игнорировались. С самого начала проект вызывал протест у многих специалистов по кибернетике, информатике и программированию, начиная от академика Глушкова и кончая Дейкстрой. Академик С. А. Лебедев выступал ярым противником копирования IBM/360;
* Неправильная ориентация на экономию процессорного времени вместо экономии общих затрат — (времени программистов, исследователей и персонала) для разработки проектов:
o На начальном этапе не уделялось внимания средствам для подготовки и отладки программ — перед программистами и пользователями ставились жёсткие условия готовить задания без единой ошибки, а объёмы человеческой работы для выполнения этих требований не имели значения, это приводило к крайней неэффективности использования компьютера;
o На позднем этапе общей тенденций стало распределение процессорного времени путём создания многотерминальных станций, при этом недостаточное внимание уделялось организации диалога и развитию графических устройств, отчего в дальнейшем серия ЕС стала неконкурентоспособна по отношению к значительно менее мощными малым машинам и персональным компьютерам.

Неупорядоченные факты, суждения и легенды об ЕС ЭВМ

* Посетивший в конце 70-х СССР классик программирования Э. Дейкстра сказал в своём публичном выступлении в Большом зале Академии наук в Ленинграде, что он считает крупнейшей победой США в холодной войне тот факт, что в Советском Союзе производятся компьютеры фирмы IBM.
* Серия ЕС ЭВМ в последние пару десятилетий существования СССР была самым распространённым видом компьютерной техники.
* Несмотря на это, устойчивость компьютеров при работе была потрясающе низкой. «Висли» («вставали») они регулярно, несколько случаев за смену было нормой. Даже сравнение её работы с работой Win95 на кривом третьесортном китайском «железе» будет не в пользу ЕС ЭВМ.
* Так как серия ЕС ЭВМ была скопирована с серии IBM 360/70 и на аппаратном, и на программном уровне, то ходила легенда о некой команде, заложенной в операционной системе, выводящей из недр как бы советской ОС полный текст американского гимна.
* Следует отметить, что в период первоначального создания ЕС ЭВМ мировая практика не распространяла авторские права на программное обеспечение. Это копирование было не эксклюзивной затеей СССР, а было так же осуществлено многочисленными западными конкурентами IBM. Мейнфреймы клонировали американская Amdahl, немецкий Siemens, японские Fujitsu и Hitachi, несколько других фирм. Таким образом, обвинения советских разработчиков в каком-то особом цинизме, нарушении авторских прав и т. д. не имеют под собою серьёзных оснований.
* Экономический развал, произошедший в годы Перестройки послужил причиной массового вывода из эксплуатации ЕС ЭВМ. Изменение экономических условий привело к тому, что громадный объём установленного программного обеспечения оказался ненужным, новое разрабатывалось уже в основном для персональных компьютеров. Там, где требовалось продолжение работы именно на мейнфреймах — происходила замена на более производительные и надёжные западные модели, в том числе бывшие в употреблении. Разработчики из бывшего СССР не смогли долго бороться за рынок — они лишились госзаказов, средств на разработку, их организационные структуры подверглись приватизации и ликвидации с целью высвобождения площадей под офисы.
К тому же, наиболее серьёзные специалисты быстро перешли на работу в IBM или какие-то другие западные компании, связанные с этой техникой. Последние попытки восстановить разработку продолжались до середины 1990-ых годов.
* Финалом жизненного цикла ЕСовских мейнфреймов стала их массовая скупка в целях извлечения из них драгоценных металлов. В составе комплектующих машины имелось несколько десятков грамм золота и, порядка одного или нескольких килограммов серебра. В период с 1990 по 1993 годы свыше 90 % эксплуатировавшихся в СССР мейнфреймов ЕС ЭВМ оказались демонтированы и утилизированы в этих целях.[источник?]
* Для эксплуатации ЕС ЭВМ, впрочем как и СМ ЭВМ, требовались литры пищевого спирта. Требуемый расход спирта на протирку контактов записывался в формуляре каждого устройства. В начале года или квартала начальник ВЦ составлял общую ведомость с суммарной потребностью, затем брал 40-литровый бидон и шёл на склад. Спирт употреблялся не только внутрь и на протирку контактов, но также служил универсальной валютой в эпоху всеобщего дефицита.
<<<
От Кудинoв Игорь
К IGA (27.08.2007 00:37:16)
Дата 27.08.2007 10:19:02

... дела давно минувших дней, преданья старины глубокой... (-)
От IGA
К Кудинoв Игорь (27.08.2007 10:19:02)
Дата 27.08.2007 14:58:32

"Сказка ложь, да в ней намёк" (-)