Історичні паралелі з СРСР, або «Байки від дяді Міші». Михайло Крамаренко — про неймовірні історії з українського IT

Михайло Крамаренко вже понад 40 років працює в галузі інформаційних технологій. Член журі IT Awards 2015, керівник програмних комітетів IT Arena, один із засновників школи бізнес-аналізу в LITS, кандидат технічних наук, автор загальновідомої фрази: «Яку проблему ми вирішуємо?». Зараз Михайло, або, як його називають в IT-спільноті, «Дядя Міша», — CTO в компанії KindGeek.

В інтерв’ю для DOU Михайло поділився особистою історією — спогадами про те, як у СРСР крали іноземні IT-розробки, та власними думками щодо того, чому Союз пішов шляхом клонування і як це було організовано в ті часи.

Приклад використання відомої фрази Михайла Крамаренка на одній з конференцій

Клонувати чи не клонувати — ось у чому питання

Як кажуть, технологічні прориви робляться для потреб війни й через лінощі. Потреба розвитку вітчизняного IT стала зрозумілою ще в 50-х роках через необхідність організовувати інженерні розрахунки. Наприклад: для обрахунку ядерної зброї СРСР було залучено понад 100 жінок, які працювали щодня по 8 годин, просто проводячи підрахунки. Технологічне відставання у виробництві якісних, надійних апаратних засобів та індустріальній розробці програмного забезпечення було очевидним для керівництва країни.

Досі ширяться чутки про так звану «війну академіків», в якій одна група (Сергія Лебедєва) відстоювала розробку власних ЕОМ, тоді як інша (група Башира Рамеєва) відстоювала клонування найкращих західних технологій. Думаю, що керівництво країни та науковці прекрасно розуміли ситуацію та рівень відставання. Коли ж обставини зумовили ще більше зростання IBM у частці ринку і серед конкурентів вона виглядала як «IBM і сім гномів» — відповідь на питання, клонувати чи ні та що саме клонувати, була очевидною.

У 1967 році керівництво СРСР ухвалило рішення про клонування західних комп’ютерних технологій (резолюція 1180/420). Причиною були брак коштів, спеціалістів та інфраструктури серійного виробництва, а також заборона урядом США експорту IBM System/360 до Союзу. Справді, витрати на розробку System/360 становили п’ять мільярдів доларів (сьогодні це понад 30 млрд доларів). За оцінкою академіка Анатолія Дородніцина, станом на 1969 рік в СРСР налічувалося трохи більше як 1500 програмістів, причому фахівців із несумісних архітектур, самоучок, математиків, фізиків тощо. За оцінкою Фредеріка Брукса, на розробку OS/360 пішло 5000 людино-років, а отже, проєкт порівняної складності всі радянські програмісти створювали б 10 років у кращому випадку. І це не рахуючи трансляторів, прикладних програм, СУБД, телемоніторів тощо. Красти було швидше, легше, ну й вони це вже добре вміли.

Чому я став програмістом, або Мій шлях у галузь

Чи не найбільший вплив на мій вибір майбутньої спеціальності мав батько. Він працював у ОКБ ЕВОТ (пізніше НДКІ ЕЛВІТ — Науково-дослідний конструкторський інститут електронної вимірювальної та обчислювальної техніки) Львівського політехнічного інституту, де разом з колегами створював пристрої цифрової обробки сигналів, спектроаналізатори, цифрові вимірювальні прилади, оригінальні спеціалізовані системи (наприклад, реалізація швидкого перетворення Фур’є) тощо. Керівник ОКБ ЕВОТ Бенціон Йосипович Швецький, з яким мені пощастило познайомитись ще в шкільні роки, позиціонував ОКБ як Brüel & Kjær (данська інженерно-електронна компанія) для потреб вітчизняного воєнно-промислового комплексу. «Ми працюємо без НДР (науково-дослідних робіт — ред.), відразу розробка», — так Швецький представляв замовникам з ВПК потенціал науковців та інженерів ОКБ.

Щоразу, коли батько приходив з роботи й розповідав про новий комплекс для Байконуру, спектроаналізатор для підводного флоту, щоб збити шуми моторів до рівня «білого шуму» тощо, мене розпирала гордість і величезна цікавість.

Група розробників ОКБ, 60-ті. Батько Михайла в центрі в першому ряду

Пам’ятаю слова батька, які стали моїм дороговказом: «Знаєш, оця моя електроніка вже скоро буде „не в темі“. Перспективно — бути програмістом». Коли справа дійшла до вибору напряму вищої освіти, у Львівській політехніці на той час було лише три спеціальності, дотичні до комп’ютерної галузі, а саме: прикладна математика (ПМ), електронно-обчислювальні машини (ЕОМ) та автоматизовані системи управління (АСУ). Я послухав поради батька та вступив на кафедру АСУ.

Перші програми

У 1981 році, навчаючись на третьому курсі Львівської політехніки, я, по суті, опинився на зламі часів: на 8-му поверсі 5-го корпусу ще працювала вітчизняна ЕОМ МІР — машина для інженерних розрахунків вітчизняного виробництва, а на першому поверсі головного корпусу вже була ЄС-1030 — радянський клон IBM System/360.

У студентські роки мені випала нагода програмувати для цих двох типів ЕОМ: мовою АЛМІР-65 для ЕОМ МІР і Fortran — для ЄС ЕОМ.

Доступ до ЄС ЕОМ був пакетним. Найбільша морока була з набором тексту програм. Щоб перенести текст програми на перфокарти, потрібно було йти в головний корпус у перфораторну кімнату і передавати його дівчатам для перфорування. Відбувалось це, звісно, з помилками, тож доводилося по декілька разів проходити всі ті «кола пекла», щоб запустити програму й отримати результат. Відповідно налагоджену колоду перфокарт берегли як зіницю ока.

Приблизно такий вигляд мали колоди перфокарт Михайла

ЕОМ МІР була набагато «демократичнішою» в сенсі персонального доступу, вона мала консоль на основі Consul, на якій можна було самостійно набирати код, потім зберігати програму на перфострічці. Але МІР не була готова до вирішення питань облікового характеру та планування виробництва в межах підрозділу, підприємства, міністерства чи країни.

Михайло з одногрупником Володимиром Іванківим за машиною МІР-1. Це третій курс, перші програми

«Дралоскоп» — не байки

Свою кар’єру в IT я почав у СКБ СТ (Спеціальне конструкторське бюро системотехніки) при науково-виробничому об’єднанні «Електрон». Варто відзначити, що СКБ СТ брало участь у розробці першої АСУ в Союзі — АСУП Львів.

Взагалі все, що у той час випускали більш-менш цікавого з IT, було зроблено в дев’яти оборонних міністерствах (скорочено — «дев’ятка»), підпорядкованих військово-промисловій комісії. Під її керівництвом працювали всі ці науково-дослідні інститути, конструкторські бюро, виробництва. Цікаво те, що військово-промислова комісія існує досі при уряді рф.

ВПК та дев’ять оборонних міністерств

Інтернету тоді не було, тож потрібно було їздити у відрядження з магнітними стрічками або за стрічками, обмінюватися досвідом. Коли я був «молодий і гарний», то часто мав такі поїздки. Запам’яталось відрядження на об’єднання «Світлана» Міністерства електронної промисловості в Ленінграді, яке входило в «дев’ятку». Саме там хлопці водили мене та показували «дралоскоп» — так дотепники прозвали пристрій для копіювання західних мікросхем.

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

А що потрібно було для програмного забезпечення? По-перше, розібратися, як цим користуватися, написати документацію, підготувати курси тощо. І відповідно, останній етап — дистрибуція.

У Калініні (сьогодні Твер, де нещодавно згорів інститут, який розробляв ракети) містився хаб, який називався «Центрпрограмсистем». Туди я теж їздив у відрядження. Це було місце дистрибуції клонів програмного забезпечення. Працівники «Центрпрограмсистем» періодично їздили за кордон, отримували дистрибутиви, забирали стрічки та привозили їх разом з документацією. Плюс окремо організовували курси, де навчали, як працювати з програмними продуктами. Щорічно до Софії в «Центрпрограмсистем» на роботу висилали 5–7 людей. І цікавим залишається той факт, як вміло вони це пояснювали: «Досвід західних фірм узагальнювався у радянсько-болгарському інституті „Інтерпрограма“ та зусиллями НДІ „Центрпрограмсистем“ пропагувався в СРСР». Отак-от вміли формулювати: замість «крали» — «узагальнювали досвід».

Декілька разів був і на прохідній НДІ «Восход», який у народі називали «обчислювальний центр КДБ», для отримання дистрибутивів. Процес був такий: на вході стояли офіцери з блакитними просвітами (блакитні просвіти на погонах носили військовослужбовці КДБ — ред.). Мені виносили стрічки, але всередину доступ був заборонений, і зрозуміло чому: їхніми основними замовниками були радянські силовики з КДБ та Міноборони, а отже, стає зрозуміло, кого вони тоді обслуговували та хто там працював.

Детективна історія про Adabas

На початку 1980-х військово-промисловий комплекс перебував у стані вибору СУБД. Були потуги в розробці власної системи, проте вони не увінчалися успіхом. Реляційні СУБД були тоді на стадії становлення, і їх серйозно не розглядали. Наприклад, СУБД Oracle ставили в СКБ СТ 1987 року на VAX-11. Отже, то був етап «розброду та хитання», аналітики ВПК думали, на чому «їхати» далі: на IMS від ІВМ, який тоді вже склонували та назвали «ОКА», на мережевій СУБД IDMS чи Adabas від Software AG.

Adabas — це СУБД з інвертованими списками. Щоб було зрозуміло: коли в мене є дві зв’язані таблички в реляційні СУБД, то між ними робиться JOIN — «many-to-one». Велика цінність Adabas була в тому, що в ній це відношення «many-to-one» було на борту завдяки підтримці періодичних груп в межах одного запису. Основною потребою ВПК була база даних обліку та планування з типовим відношенням «many-to-one», і для вирішення таких задач Adabas був одним із найкращих варіантів. Тому його тихо та обережно поцупили. Клон отримав власну назву «СПЕКТР», адже у нас все своє і все найкраще. Різні міністерства та інститути його адаптували під своїми назвами: «ТРИАДА», «ИСХОД», «ДИСОД», «КВАНТ» для низки ЄС ЕОМ та для лінійки СМ ЕОМ — «МІРІС», «ГРАД», які, відверто, були неповноцінними... Проводились Reverse Engineering, навчання, написання документації тощо. Взагалі основна проблема клонування — це «лінія затримки»: поки вкрадуть, поки розберуться, поки зроблять Reverse Engineering і навчаться тим користуватись. Цікаво, що першу адаптацію Adabas виконав саме НДІ «Восход».

Вкрасти самі «бінарники» і дистрибутиви не складно. Але зовсім інша річ — здобути вихідний код, адже це розуміння архітектури та технології розробки СУБД. Джон Магуайр, засновник і президент Software AG, порівнював Reverse Engineering Adabas із крадіжкою рецепта Coca-Cola.

Сьогодні завдяки open source можна отримати вихідний код багатьох СУБД, а тоді такого не було і залишалося лише одне...

Як розповідав Джон Магуайр у своїй доповіді перед комісією конгресу, щоб вкрасти вихідний код Adabas, 1979 року бельгієць Марк Андре Дегейтер сконтактував із маркетинговим відділом Software AG, аби отримати ім’я найкращого технічного експерта в компанії. Його скерували до Джима Еддіса з офісу в місті Рестон, штат Вірджинія. Джим був одним із двох співробітників у цій компанії, хто мав доступ до вихідного коду Adabas. Дегейтер запропонував йому від імені Радянського Союзу хабаря у розмірі 150 000 доларів, на що Еддіс відповів, що йому потрібно порадитись, і негайно розповів усе президенту компанії Джону Магуайру, який, своєю чергою, повідомив усі деталі FBI.

Щоб вивести бельгійського шпигуна на чисту воду, Джон Магуайр, співпрацюючи із федеральними агентами, вийшов з ним на прямий контакт. Вони проводили телефонні бесіди та декілька разів зустрічалися для обговорення деталей. Як і Джиму Еддісу, Марк Дегейтер обіцяв заплатити чималу суму за вихідний код. Цей процес тривав близько семи місяців, проте зрештою Дегейтера таки заарештували в Міжнародному аеропорті Кеннеді у Нью-Йорку. В портфелі бельгійця знайшли документи та телеграми, які свідчили про те, що він співпрацював з кількома радянськими компаніями.

У статті The Washington Post Джон Магуайр назвав радянські комп’ютерні технології «античними», зазначивши, що «російське програмне забезпечення відстає від американського на 10–15 років»: «США витратили мільйони доларів на розробку. Для росіян 500 тисяч доларів — це крапля в морі, щоб спробувати надолужити згаяне».

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

Заголовки газет про історію з Adabas

Технологія впливає на життя, а життя впливає на технологію

Одним із висновків, який я зробив, є те, що технологія впливає на життя, а життя впливає на технологію. Тобто технологія, яку ти засвоїв, якоїсь миті може докорінним чином вплинути на твоє життя. І власне, цікаво, що продукти Software AG відіграли значну роль на одному з етапів мого життя.

У 1998 році я поїхав працювати до Польщі в компанію, яка представляла Software AG. У Польщі тоді теж була купа мейнфреймів та інсталяцій вже відомого нам Adabas. Варто зазначити, що у Software AG була своя мова четвертої генерації (4GL) — Natural для розробки програм на Adabas, яка вже тоді працювала на своїй віртуальній машині (можна провести аналогію з JVM). І власне, з появою Java Software AG створили нову мову — BOLero (business oriented language), а пів року по тому мені довірили представляти її на сцені театру ім. Юліуша Словацького в Кракові перед повною залою польських ІТ-спеціалістів на заході Magia świata s/390.

Як працювало клонування та промислове шпигунство

Аналітики відповідних закладів відстежували основні тенденції, топових іноземних вендорів, визначали, що потрібно зараз СРСР, і міркували над тим, як це вкрасти. Далі було кілька варіантів: засилали шпигуна через підставну фірму, як це сталося, наприклад, з базою даних Adabas, або робили «контрольовані вікна» імпорту. «Контрольовані» тому, що відповідні заклади та служби контролювали процеси з обох сторін. Союз організував процес «імпорту», а Захід контролював, що їм можна дозволити поцупити, а що ні.

Як працювали ці «контрольовані вікна»? Наприклад, відкривається інститут «Інтерпрограма» в Болгарії, бо там не було такої жорсткої технологічної «залізної завіси». Це відбувалося так: у Болгарію у відрядження засилали «товаришів», які розбиралися, що там, їздили по виставках, дивилися на тренди — що купити, яку версію, що вкрасти. Потім починався процес адаптації, тобто Reverse Engineering. Усі ці програмні продукти або чипи приїжджали в науково-дослідні інститути, де вже вітчизняні інженери розбиралися, як вони влаштовані. А далі, залежно від того, це програмний продукт чи хардвер, запускалося відповідне виробництво.

Схема клонування в СРСР

Байка про «Правець»

Як я вже розповідав, у Болгарії в ті часи були сприятливі умови для створення «контрольованих вікон» імпорту завдяки двосторонньому контролю процесу західної та союзної розвідок. Цей метод забезпечив СРСР ще одну вагому крадіжку — клон ІВМ РС. Вони навіть запустили власний завод і назвали його «Правець». Що цікаво, Правець — це мала батьківщина Тодора Живкова, останнього радянського правителя Болгарії, і завод назвали на честь містечка, звідки він родом. У 1989 році я поїхав у відрядження в Софію разом з колегами, і ми проїжджали повз Правець — таке невеличке містечко із заводом на горі.

Генеральний директор заводу мав прямий телефон без набору номера (знаєте, як у фільмі «17 миттєвостей весни», коли Штірліц Борману телефонує?) до Тодора Живкова. Він, тоді ще молодий хлопець, також був випускником кафедри ЕОМ факультету автоматики Львівської політехніки. Я познайомився з ним особисто під час його вступу до аспірантури Ігоря Михайловича Вишенчука.

Пам’ятаю, як привезли один з перших «Правців» IBM PC/XT з 5-дюймовим дисководом. Типовою схемою захисту MS-DOS-них програм тоді був запис кількості зроблених інсталяцій в міжсекторному проміжку на дискеті. Тобто запускали якусь програму, вона потребувала інсталяції, робила декремент на кількість допустимих копій, а потім казала: «Купи мене ще!». Чому це був унікальний екземпляр дисководу? У нього була апаратна помилка, і можна було цю дискету на момент запису вийняти без жодних негативних наслідків. Усі колеги приходили «піонерити» програми саме на цей екземпляр «Правця».

Фото Михайла біля саме того «Правця»

Цікавим є той факт, що кожен радянський міністр оборонного міністерства запускав виробництво власного клону IBM PC. Усі міністри «дев’ятки» вважали обов’язковим робити свій персональний клон, тому існували ЕС-1840, «Іскра», «Нейрон», «Пошук», «Істра-4816» — ціла пачка приблизно того самого, тільки з невеликими варіаціями апаратної реалізації.

Байка про «Відеотон» та «мідну скріпку»

«Електрон», де я працював, взаємодіяв не тільки з болгарами, а й з угорцями. Угорські клоновані машини були надійнішими у порівнянні з радянськими, оскільки у них на підприємстві «Відеотон» була краща культура розробки та виробництва.

Якось на «Електрон» приїхав інженер з «Відеотону» і каже: «Слухайте, ми тут нещодавно розробили власний аналог VT100 (термінал виробництва Digital Equipment Corporation — ред.). Мені потрібні висновки щодо рівня сумісності», тобто про те, наскільки якісно вони його клонували.

Я тоді працював «страшним» інженером-програмістом на СМ-1420, відповідно представника «Відеотону» скерували до мене. СМ-1420 працювала під операційною системою RSX-11М (радянський клон ОС РВ). Цікаво, що архітектор RSX-11М Девід Катлер пізніше очолював розробку Microsoft Windows NT. На RSX-11М була популярна система FMS (forms management system) — редактор форм. За допомогою FMS проєктували екрани для Dumb Terminal: малювали лейбочки, поля вводу даних тощо. Форматування екрана здійснювалось за допомогою ЕSC-послідовностей, які вже інтерпретував дисплей. Я знав напам’ять ЕSC-послідовності й перевірив — справді той FMS, який «заточений» на VT100, безперебійно працює, усе добре. На знак вдячності інженер «Відеотону» подарував мені фірмову документацію Digital Equipment Corporation на VT100.

Чому я це запам’ятав? Бо до документації додавалася VT100 Programming Reference Card, яка була причеплена мідною скріпкою до основної документації на термінал. Мідною, бо вона не ржавіє. Я тоді подивився на цей «звірячий вищир капіталізму» і подумав: «Як же їм важко там працювати, у зарубіжжі».

VT100 Programming Reference Card

Байка про Олімпіаду-80

Цю історію я довідався від колег під час одного із відряджень до Москви чи Твері. Однією з украдених Радянським Союзом систем була «КАМА» (оригінал — СICS) — телемонітор для обслуговування терміналів типу IBM 3270.

І ось в СРСР 1980 року проходить Літня олімпіада в Москві, делегацію компанії IBM запрошено в обчислювальний центр управління Олімпіадою. Представники Союзу не врахували рівень компетенції візитерів. Один з представників делегації IBM підійшов до монітора, ввів код транзакції — і на всіх екранах системи управління Олімпіадою з’явився напис СICS. Завіса. Reverse Engineering не спрацював: начебто і розібрались, як воно працює, але не до кінця...

Ходили чутки, що саме під маркою Олімпіади в Союз потрапив один з перших дистрибутивів Adabas.

Історія про «Мрію» і «Буран», або Дахи самі не падають

«Буран» (за версією російських загарбників) — це перший радянський орбітальний корабель багаторазового використання, проте цей шатл здійснив лише один політ 15 листопада 1988 року, і на цьому його надтехнічні можливості завершилися. Ще одним відомим фактом є те, що цей радянський шатл перевозила на собі наша знищена рашистами «Ан-225 Мрія».

Ан-225 «Мрія» перевозить «Буран»

Архітектура бортової системи шатла «Буран» ЕОМ «Бисер-4» була зроблена на основі клонів ІВМ 370. Зауважу, що задля забезпечення відмовостійкості було використано чотирикратне резервування бортового комп’ютера ІВМ 370. Кожна з цих чотирьох бортових машин виконувала ту саму програму з подальшим порівнянням результатів обчислень. Оскільки я орієнтуюся, наскільки надійними були клоновані ІВМ 370 комп’ютери на землі, то можу припустити, чому це був єдиний політ «Бурану»: не вірю, що бортова система була життєздатною. А як вже відомо з історії, «Буран» літав лише раз, а потім його загнали в ангар, у якому 2002 року обвалився дах. Ви взагалі вірите, що на об’єкті, який охороняють, у період ремонтних робіт просто так падає дах — і з кінцями? Ми говоримо тут про росію, там якщо щось таке горить або розвалюється, то це явно комусь потрібно.

«Буран» у 2002 році, коли на нього звалився дах корпусу

Чому СРСР відставав

Якщо підсумувати, то на рівні ідей, теорії та алгоритміки в СРСР було все гаразд, існували власні школи. Кого-кого, а тих же фізиків і математиків вміли готувати. Наприклад, можна згадати Катерину Ющенко (у лютому на DOU було інтерв’ю з сином Катерини Ющенко Юрієм про її життя та досягнення — ред.). В одиничних екземплярах або малими партіями вміли робити ЕОМ, наприклад «МІР». Але ж все не так просто: окрім апаратури, потрібно було ще зробити програмне забезпечення, наприклад компілятор АЛМІРА-65. І з усім цим циклом — від надійного чипа до програмного продукту індустріальної якості — були великі складнощі.

Поняття «тестувальник» взагалі не існувало: кожен програміст писав документацію під назвою «контрольний приклад» і описував, що потрібно, аби перевірити, як воно працює: які повинні бути вхідні дані та які вихідні дані отримаєте. Методологією розробки був Waterfall: спочатку технічне завдання, а потім імплементація. Результат — низький ступінь реакції на змінність вимог. Якщо вимоги змінювалися по ходу п’єси, то все починалося спочатку.

За розробку технічного завдання відповідав «постановник завдань» — роль дуже подібна до сучасного бізнес-аналітика.

Ще однією важливою деталлю, яка ускладнювала процес, була типова відсутність технологічних засобів контролю версії. Не було такого, що ви написали код і могли побачити, якою була попередня версія, хто її закомітив, яка різниця з тим, що є в контрольній версії тощо. «Контроль версій», який реально використовувався: роздруківка тексту, ручка, помітки на роздруківці. Тому були проблеми з відстеженням змін, складність координації колективної розробки. Це ще один із проявів низької культури розробки програмних продуктів.

Гальмував розробку і пакетний доступ — ті колоди перфокарт, про які я згадував. Телемонітори, за допомогою яких можна було працювати онлайн, з’явилися пізніше.

Тобто культури індустріальної розробки програмного забезпечення не було. Тому Джон Магуайр, президент Software AG, абсолютно мав рацію: відставали не тільки технологічно, а й у самих процесах. Процеси індустріальної розробки програмних продуктів прийшли до нас тільки з аутсорсом.

Якість страждала на всіх рівнях. На рівнях хардверу, клонованої апаратури та софтверу. Радянські клони працювали несправно. Приходиш до машинної зали, а вона стоїть. Щодо чипів, то їх виділяли два типи: ті, що пройшли військову прийомку, і ті, що не пройшли. Якщо на транзисторі або на мікросхемі була надрукована зірочка, то він пройшов військовий прийом і працює надійніше.

І, звісно, фокус розробників був не на проєктуванні, а на Reverse Engineering і розробці документації. Наприклад, ви працюєте на тому ж НДІ «Восход», вам дають стрічку, ви розбираєтеся з нею, дивитесь, що там написано в машинному коді. Ваш мозок заточений на з’ясування того, як воно працює всередині, чи немає небажаного коду, керованого зовні тощо, а не на проєктування та розробку нового функціоналу. Відповідно, що складніші програмні продукти, то більше відставання. А з початку 1980-х років радянська промисловість тільки те й робила, що намагалася пристосувати дедалі складніші західні комп’ютери, щораз збільшуючи розрив. Промислова продуктивність від цього погіршувалася, оскільки комп’ютери 70-х старіли та часто виходили з ладу. До 1989 року чверть усіх комп’ютерів загального призначення в Радянському Союзі складали ЄС ЕОМ, виготовлені 1974 року, а там була скопійована технологія, яка вперше була випущена 1965-го — 24 роки до того.

На мій погляд, клонування та крадіжки відкинули розвиток інформаційних технологій у СРСР. Хоча позитивним наслідком цього стала громада кваліфікованих інженерів, які вийшли на ринок у кінці 80-х років під час розвалу ВПК і могли працювати на західних комп’ютерах із західними технологіями. Якби розробка власних машин тривала, ймовірно, зменшилася б вірогідність аутсорсингу, адже потрібно було б використати купу коштів і часу на перенавчання людей. Закон Горбачова про кооперативи та поява інтернет-провайдерів завершили формування бази для вітчизняного аутсорсингу. А отже, не було б клонування — не було б і аутсорсингу.

Чому на росію чекає подорож машиною часу

Коли я прочитав новину, що путін дає завдання для запуску власних програмних та апаратних засобів, мене ніби перенесло машиною часу в період моєї молодості. У росії знову опустилася «залізна завіса», тож для апаратних та пропрієтарних програмних засобів вони знову будуть змушені налагоджувати та розширювати процеси промислового шпигунства.

З одного боку, оскільки є багато готових для використання open source продуктів, у росіян можуть бути якісь надії. З іншого боку, вважаю, що IT-спеціалісти (особливо ті, що працювали в аутсорсі) просто емігрують, і в них знову буде брак кадрів.

На рівні технологій це будуть великі проблеми. Адже їм потрібно буде налагоджувати свої технологічні лінії, відповідно будуть робити або імпортувати сучасні аналоги дралоскопів. Або красти хардвер через такі самі «контрольовані вікна» імпорту: створювати підставні фірми в Європі, Казахстані чи, можливо, у Китаї, який значно попереду рф. Або розширювати «імпортозаміщення» чемоданами контрабандних мікросхем. Варто відзначити, що вся інфраструктура для організації «імпортозаміщення», промшпигунства та обходу санкцій за допомогою третіх країн у рф є. Наприклад, науково-дослідний інститут «Восход» досі існує та обслуговує всі силові міністерства.

Новостворені «контрольовані вікна» стануть причиною підвищення рівня корупції. Бо в них імпорт та «імпортозаміщення» означає корупцію. А отже, розкрадуть залишки свого нафтогазового бюджету та ще сильніше посилять відставання.

Історія повторюватиметься. Проте запхати ніс далі, ніж буде дозволено, не вдасться, як і в ті часи, коли чітко знали, що можна дозволяти вкрасти, а що ні. Тобто програмне забезпечення, яке можна використати десь у Space Shuttle, або ланки тактичного керування їм вкрасти не дадуть, а щойно полізуть далі — отримають по руках. Як це сталося зі шпигуном з Adabas.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU