Книга: Информационные технологии в СССР

aab2ea96887a7168249c05cbf9131473
Ревич Ю.В., Малиновский Б.Н.
Информационные технологии в СССР. Создатели советской вычислительной техники.
БХВ-Петербург, 2014.
Ревич взял за основу книгу Малиновского «История компьютерной техники в лицах», расширил, [заметно] дополнил. Получился вполне хороший сборник биографий основного пантеона советского вычтеха.
Есть два нюанса.
Во-первых, речь почти только о «железячниках», конструкторах, делавших именно компьютеры. Программисты вне темы книги.
Во-вторых, авторы стараются быть положительно-нейтральными, так скажем. Лишь изредка прорываются штуки вроде письма Ревичу: «Опыт внедрения Эльбрус-1» от того, кто над этим Эльбрусом в 1982 году всем телом бился. Т.ч. срывания покровов нема, они в других статьях и книгах. Просто ровные истории о.
Книга годная, читать было интересно. Получил много поводов подумать и порыскать по другой литературе.

 

Мои учителя

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

Ваня (мой первый лид) смотрел с недоумением. Мне было 18 лет, не знал C, попал в контору по знакомству с директоратом, денег первые месяцы не получал и не просил, хотел учиться правильной разработке. Все мои дурацкие фантазии о какой-либо заботе были разбиты. Получил разработку небольшого (программируемый софтовый калькулятор) коммерческого проекта в одно рабочее рыльце. Получил лида, который жёстко придерживался правила «умный сам научится, а дурака учить — время зря тратить». Получил первый опыт прямого общения с заказчиком, да ещё и на английском (тогда я влепил в письмо чудесное слово «fitches» вместо «features», ведь все вокруг говорили «фичи»!). Получил первый опыт стороннего тестирования — Ваня подходил, с закрытыми глазами проводил полной ладонью по клавиатуре и порождаемый этим хаос раз за разом валил моё приложение в корки. Корки были болью, ибо кто писал на C под MacOS 7/8, тот танков не боится. Ваня пожимал плечами и уходил. Ревью кода проходил раз в месяц в режиме «ты чем думал, когда эту х..ню написал? а это вообще п….ц, а не код». Всё усугублялось тем, что при отсутствии информации об API MacOS я в процессе наваял свою библиотеку control’ов. Думали, выкинем этот ужас, но заказчик вдруг захотел ТАКОГО, что только кастомное рисование и спасло.
В итоге метод Вани сработал. Я написал и сдал свой первый коммерческий проект. Ваня получил оффер и уехал в США в один из мировых top-10 руководителем. Что важно? Если ты хочешь научиться программировать, тебе не нужен учитель. Есть книги. Есть компиляторы. Есть сотни часов теории и практики. Человек извне нужен лишь для того, чтобы корректировать вектор, дабы ученик не упоролся в совсем уж идиотию (ну и явно показать, что каждую итерацию ты делаешь хрень, а не стабильный продукт, да). Ване не было пофиг. Слегка злобный, едкий и честный мужик, которого откровенно тошнило при взглядах на меня и на мой код. Но Ваня НЕ МЕШАЛ. Ученик хочет учиться? Так учись, кто не даёт-то. Хочешь программировать? Вот компьютер, программируй. Нужна нянька? Вернись в детский сад, няньки в нём остались, освободи место тем, кому нянька не нужна. Хочешь за свою работу получать деньги? Делай работу так, чтобы было за что платить деньги. Честно, откровенно, справедливо.
Урок #1: если хочешь учиться, будешь учиться и без нянек; если не учишься, просто не хочешь, иди в жопу тогда, в чём проблема?

Петя задолбал занудством и педантичностью. До меня не сразу дошло, что это я идиот, прямо скажем, но потом дошло. Тогда ещё не было принято фигачить прототипы в продакшен и отстаивать это как вариант нормы. Если ты катил в прод туфту, которая валилась с пятисоткой, ты криворукий олень, а не спешащий навстречу рынку хипстер. Всё просто. Петя рулил проектами на 10..20 человек с планами на 1..2 года. Опять же, это я сейчас понимаю, что организовать наше стадце так, чтобы мы уложились хотя бы приблизительно в годовой план… Дай мне такую задачу, убегу с паническими криками. А Петя справлялся. Пожалуй, то очень важное, чему у него научился (опять же, не меня учили, но достаточно было смотреть на крутого чувака внимательно) — ДОКУМЕНТИРУЙ. ЧИТАЙ МАНУАЛЫ. ПЕРЕПРОВЕРЯЙ СЕБЯ. ПЕРЕПРОВЕРЯЙ ЗАКАЗЧИКА. ВСЁ ПЕРЕПРОВЕРЯЙ. Тогда это раздражало. Сейчас хочется извиниться за свою тупость, но как-то уже и не к месту, много лет прошло. Петя, ты был прав.
Урок #2: без бумажки не только ты какашка, но и твой код, и твой сервис, и вообще всё.

Олег работал тестировщиком. Спокойный боец, даже флегматичный. Торкнуло меня однажды, когда мы в очередной раз сидели ночью, я катил релиз за релизом, а Олег заворачивал из-за багов релиз за релизом. Мы очень устали, была ответственность, всё такое. Олег как-то… всё так же спокойно и с пониманием проверял, возвращал, проверял, возвращал… И снова только позже, рефлексируя, я посмотрел на ситуацию со стороны. Стало стыдно. Разработчик, легко относящийся к своим багам, он… как бы так сказать… я совершенно точно не считаю такого разработчика хорошим. Никакой. Обычный. Возможно, плохой. Но точно не хороший. Твои баги часто бьют по другим людям. Вместо того, чтобы сидеть с девушкой в кафе, лежать с женой на диване, пить вкусное вино, гулять в красивом лесу или просто спать, другой человек тратит свою жизнь на твои косяки. Ты поленился подумать? Тестировщик сидит лишние часы. Поленился проверить? Менеджеру лишние циклы с тикетами. Поленился не быть мудаком? Пользователи исходят истошными кликами на неработающем софте. Фактически ты вор чужого времени, обычный раздолбайский разработчик за свою жизнь умудряется угробить и чужую, если просуммировать все убитые из-за него часы. Потому, если не хочешь быть редисом, становись специалистом, баги которого вызывают хотя бы интерес, а не фейспалм класса «опять этот криворукий, как же заманал».
Урок #3: твои баги влияют на всех и на всё; заядлый багодел крайне вреден, его надо искоренять.
Также Олег молча своей работой показал мне, что разработчик не пуп земли. Не будь тестировщиков, мы со всей своей гениальностью катили бы заказчикам такой кошмар, что из судов не вылезали бы. Не будь техписов, фиг бы кто понял, что за бред мы в очередной раз выдаём за удобный юзерфрендли суперпродакт. Не будь менеджеров, уже через неделю лебедь, рак и щука казались бы верхом организации. Не будь лидов (бьющих дубинкой по задранным лбам)… вот тут не уверен, кстати, потому замнём для ясности. Короче, не будь их всех, разработчики были бы тоже не нужны в том виде и качестве, в котором они есть сейчас — изнеженные капризные создания, вокруг которых всё должно улыбчиво вертеться в темпе вальса.
Урок #4: тестировщик очень нужен.

Игорь, под руководством которого я впервые сделал что-то, что включил во внутреннее «сперва добился», закрепил во мне ощущение: хороший руководитель НЕ МЕШАЕТ. Да, это риск. Легко продолбать момент, когда прям вот надо было коршуном пасть на жертву и помешать творить зло (собсно говоря, на это я пару раз напоролся и до сих пор размышляю о том, когда же всё-таки авторитарно бить по рукам). Но в то же время это в какой-то мере… правильное деяние с точки зрения человечности? Когда не вмешиваюсь, молча говорю что-то типа «считаю тебя взрослым зрелым специалистом, которому я могу доверить реализацию проекта без постоянного контроля, потому не подведи, пожалуйста». Постоянный контроль убивает творчество, мысль, инициативу. А так… заодно и воспитывает ответственность.
Урок #5: нет ничего круче самостоятельности.
Евлампий, Ефим и Егор в свою очередь примерно в тот же период жизни и осмысления показали мне, что плохой руководитель почти всегда мешает. И почти всегда тому причиной два кита: 1) некомпетентность, 2) страх потери контроля. Как и все неудачные в своих проявлениях люди, эти тоже учителя. Просто научили не быть (не стать) таким же. Спасибо.
Урок #6: внимательно смотри на плохих специалистов и учись у них не быть ими.

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

Наблюдение за Кимой дало понимание… даже не нужды, она очевидна… роли саппорта в жизни планеты. И снова тупоголовый тот разработчик, что относится к саппортам свысока. Если человек хорошо и тщательно выполняет эту работу, на большом продукте он стоит пары разработчиков. В конце концов, именно следствия разработческих недоделок и косяков входят волной гуано в первую линию обороны психики наших нежняшек — в саппортов. Святые люди, ейбо. Мало того, что им приходится вежливо, тактично и толково отвечать на сотни «ааааа, вы уроды, ничего не работает, верните как было! атписька!», так ещё они продолжают улыбаться и общаться с теми, кто допустил столько багов. Я бы уже после первого дня такой нагрузки настроил бы форвард на разработку, пусть наслаждаются. Но нельзя так делать почему-то. Разбегутся-с.
Урок #8: саппорты святые.

Что в этом списке важно… Вас не должны учить, чтобы вы научились. Просто смотрите на людей. Наблюдайте за их работой. Не стесняйтесь спрашивать о том, как и что в их процессах работает. В десятый раз повторю то, что через раз тут пишу: учитесь самостоятельно. Нет, никто ничего вам не должен. Это ваша жизнь, вы за неё в ответе. За будущее, за свою специальность, за состояние мозга, за конфигурацию нейронов. Не мама, не папа, не бабушка и даже не цепочка лидов до боженьки. Вокруг вас всегда есть кто-то, кто умеет что-то лучше вас. Учитесь у них, достаточно иногда просто посидеть рядом. Человек не должен вас учить, чтобы быть учителем. Часто достаточно уже того, что он есть. Всегда есть что-то, что вы умеете плохо. Добудьте учебники, наточите пальцы и научитесь делать это хоть чуточку лучше.
В конце концов, попробуйте себя в разных ролях. Протестируйте продукт Альберта (и получите те же баги ещё раз пять обратно, после чего посмотрите в зеркало). Попробуйте отменеджить проект (тикеты, заказчики, формулирование ТЗ, подбивка сроков, планов, всё такое). Напишите мануал к своему сервису, дайте своей бабушке (не поняла? отличный у вас мануал). Замените саппорта на сутки. Ладно, жестоко. На час. Часа хватит. Побудьте лидом недельку (заодно поймёте, почему ответ «а потому!» не считается правильным).
PS. Ну и да, у всех (кроме Евлампия, Ефима и Егора) прошу прощения. До того, как стать умным, я был глупым. Жаль, что вы при этом присутствовали и вынуждены были из меня эту глупость своим примером изгонять. 🙂

Книга: Low-Level Programming

414l6NJ8yyL._SX348_BO1,204,203,200_
Igor Zhirkov.
Low-Level Programming: C, Assembly, and Program Execution on Intel® 64 Architecture.
Apress, 2017.
Про low level сейчас мало свежих книг, потому мимо этой пройти сложно. Но лучше бы и пройти, отложив на будущее. Озлоблённость и недоумение вызваны неудовлетворённым ожиданием. Я хотел книгу про ассемблер, процессоры, архитектуры, красивости и всякое такое. А получил методичку какую-то отечественному студенту.
В книге 446 страниц. Если убрать «технические» страницы (обложка, содержание, индекс, благодарности, титульные страницы глав и т.п.), а их 36, получим 410. Но ещё есть приложения: про gdb (9), make (5), семь из 333 syscalls (6), сводочка про перфтесты (3). Ещё минус 23 страницы, в остатке 387. Буду злобным и summary-страницы в конце каждой главы посчитаю ненужными: 17. Итого получаем книгу в 360 страниц.
Но… тадам! Со 127-й страницы по 220-ю нам пересказывают основы языка C! А с 221-й по 231-ю галопом про БНФ, AST и парсинг с семантикой. Зачем-то. А с 241-й страницы по 261-ю галопом про good code practices. Снова зачем-то. Эдак 120 страниц добавляю в минус. Осталось 240. Из которых 115 посвящены «Assembly Language and Computer Architecture» и 125 теме «Between C and Assembly».
Вот сами подумайте, что можно уместить в 115 страниц по заданной теме? Правильно. Снова галопом. И автор прям сознательно указывает, что команды не описывает, мол, всё устаревает, топайте в интернеты, в мануалы от Intel, там научитесь. Ну офигеть мне удобно метаться туда-сюда, просто вот разе на десятом восторг от решения. Проверочные вопросы примерно из той же области: «What is the difference between sar and shr? Check Intel docs» — кхм, уважаемый Игорь, мне казалось, что задача учебника также и в том, чтобы рассказать мне об этой разнице, а не форвардить в мануалы Intel, которые я и без того почитаю. В общем, в сравнении с другими книгами эта тема разобрана просто никак. Очень конспективно, лишь бы зачёт сдать.
Единственное, за что хочется сказать «спасибо» — Between-тема. Она тоже конспективно, тоже галопом, но весь этот дайджест собран в одном месте и позволяет раскручивать интернеты более точечно и системно.
Итого… Ну, 125 страниц из 446. Я не знаю, кому и зачем нужна такая книга. Не знаю, кто ставил ей хорошие оценки на Амазоне. Есть гораздо более правильные книги по C. И гораздо более правильные о практике программирования. И про ассемблер, как уже знаю. Автор очевидно хорошо знает тему. Но нафига пытаться упихнуть в удава десять слонов? И о чём и для чего всё-таки книга? Практику всё равно после неё до фига молотить. Теоретику слишком мало написано. Интересующемуся (вот типа меня) слишком конспект и как-то… чуть дубово написано, пардон.
В общем, я грустно разочарован.

Хорошие люди

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

Давайте на примере. У вас есть ближний набор задач ABC (написать сейчас-сегодня сервис поиска работы, вакансии, резюме, это вот всё). И есть дальний набор задач XYZ (рекомендации после машинного обучения, рекламная сеть работодателям, служба умных рассылок, собственный биллинг, соцсесточка кандидатов, тестовая платформа). Идеи есть, даже бюджеты есть, но проблема с людьми. Вы не IT-беспомощный, есть опыт и всякое нужное, потому вполне внятно представляете, какой стек где используется. Потому вывешиваете вакансию с перечислением… скажем, Python, PostgreSQL, Django, Linux, ну и фоновый фундамент в виде алгоритмы + процессы + адекватность.
Приходит Петя. Не ваш знакомый. Не по рекомендации знакомого. Человек, которого вы не знаете совершенно. Но он считает, что подходит к работе, что вы предлагаете. Как вам удостовериться, что это так и что Петя не пекарь, месяц назад решивший сменить профессию? Про пекаря не шутка, реальный случай. Дядька много лет в пекарне работал, утомился и захотел начать с чистого листа. Чем-то понравилось программирование, месяц прозанимался по вечерам, пришёл на вакансию middle.
Для удобства (иначе можно расходиться) предположим, что вы не идиот, не эльф, не вчерашний выпускник детского сада. Потому знаете, что люди могут заблуждаться, обманывать, переоценивать себя, смещать акценты, умалчивать, выпячивать и т.д. А ещё каждый день утром перечитываете список когнитивных искажений, потому даже в зеркало смотрите с прищуром.
И да, вы не телепат. И не гений психологии. Вы, конечно, уверены, что глазом-алмазом раскусите любой орешек, но этой вашей уверенности есть название в списке выше. Нет, не раскусите. Потому вооружайтесь всем, что прочли на Хабре и в Твиттере, и айда отделять пекарей от прирождённых питонистов.
Блин, ещё лирический абзац. Вышесказанное, конечно, подразумевает, что нанимать пекаря вы не готовы. После ряда бесед я не уверен в этом «конечно», отсюда и абзац. Пекари пекут хлебобулочные изделия. Они этому учились теорией и практикой. Программисты пишут программы. Этому они тоже учились теорией и практикой. Если в вас 146% оптимизма в конце жизненного квартала, вы можете предположить (ну, читали же про случаи!), что пекарь Петя за полугодие наваяет вам бекенд с API, от которого не повесится фронтендер, не будут нервно смеяться админы (они делают ставку, будет ли побит рекорд в 1000 алёртов мониторинга за сутки), не будет стыдно перед колбасником Игорем (которого вы наймёте после увольнения Пети). Но это даже не сказка и не фантазия. В общем, не надо пороть фигню. Есть работа для программиста? Нанимайте программиста. Скучный вариант, но часто срабатывает.

Уф. Ну и? Какие вопросы задавать будете? Человек явно хороший. Лицо доброе, речь гладкая, в глазах отсветы печи (огнём горят, ага). Котяток любит. Дома жена и двойня малявок на лавке, ножки свесили, болтают. С хорошестью проблем нет. Сервис-то напишет? А когда? А какой? А с каким качеством? Заодно придумайте вопросы, которые вам прям вот сейчас (а не через год) дадут понимание, обучаем ли Петя. Да, он не знает Django. Но по-братски клянётся, что за две недели выучит! Поверите? Нет? Да? А на основании чего?
В процессе интервьюрования вы, возможно, вспомните, что разработка сервиса — это не только код писать, но ещё и тестировать, документировать, эксплуатировать. Хороший разработчик этому учится достаточно долго уже потому, что нужда в таких умениях в голову пролезает не сразу. Очень туго идёт, прямо скажем. Пока сто раз не напорешься на баги (Вова тесты не написал), не уткнёшься в пустоту информации (Олег документацию не написал), не поднимешься в три часа ночи по звонку (Игоря потребление памяти не волновало)… Хотя… Хорошему человеку разочек объясните и он всё поймёт, да? Не проблема, согласен. Это только какие-то плохие человеки даже после десяти напоминаний в прод мимо теста катятся, ага.
Уже готовы спрашивать? Давайте я финально масла в азарт подолью. Петя хочет 150К в месяц. Консилиум лидов прикинул, что нужный вам сервис писать от первого символа до прода надо год. Потому сейчас вы решаете следующую задачу: кто получит ваши 1.8М рублей, хороший человек или хороший программист? Вот и решайте. Интересная задачка. Ещё интереснее в том, что никакой Петя никаких гарантий вам не даст. Он ничего не должен. Наёмный работник, о чём Пети в удобный им момент легко вспоминают. Просидит свои месяцы, получит зарплату, разведёт руками и пойдёт дальше. Потому ВСЯ ответственность на вас. Вам решать, вам потом разгребать и думать, чего дальше делать.
Всё. Время пошло. Вам ещё троих таких же нанять (и через год объяснять результат за 7М+ рублей). Постарайтесь не скатиться в банальное техноинтервью, это нынче моветон. Enjoy.

У меня чего сарказьму и йаду столько-то… Честное слово, насмотрелся на «хороших людей» до упокоя души. Не работает этот метод. Ничем не лучше бросания монеток в кандидата. Девять из десяти раз будет устрашающий код, уволенный человек и рыдающие переписывающие. Но об этом статью никто не напишет, чё, звучит как-то обыденно. Один раз монетка попадёт в чувака, который и так бы норм собеседование сдал. Да, он выстрелит. За год в сеньора, за два года в лиды, за три года в CTO на IPO. Про него сложат легенды и будут тыкать примером. Красивые твиты напишут. Что-то типа «Петя на собеседовании не смог в XOR, через три года директор PetiaSoft, будь как Петя» и 123К ретвитов от тех, кто не может в XOR (словно это пропуск в директора). Но ещё раз: один из десяти. А с теми девятью вам надо будет чёт делать нехорошее. Пять раз объяснить задачу. Четыре раза попросить её сделать. Шесть раз убиться глазами о предложенное решение. Трижды напиться от отчаяния.
PS. Метод «хорошего человека» работает только в одном варианте: хороший человек УЖЕ знает столько, что ваш стек и ваше доучивание для него являются привычной каплей в море. Для него нет проблемы хорошо освоить MySQL, у него за плечами Oracle и PostgreSQL уровня DBA. Для него нет проблемы освоить Python, он 120 лет пишет на C / C++ / Java / PHP / Perl / JavaScript. И ваши нюансы местного хайлоада для него не проблема после 15 лет хайлоада в пяти топовых центрах обработки данных. Алгоритмы? Ну… активный коммитмент в SciPy устроит вместо зачёта? Вот такое норм. Таких бойцов и в самом деле не собеседуют, просто говорят о жизни за чашкой чая, осторожно подманивая.

Таки что должен разработчик

Порою бывают разговоры с разными разработчиками, которые (разговоры) после суммы за N..M времени дают интересную картину. Прочтите список ниже. Уверен, хоть с парой пунктов, но сталкивались. А часть одобряете.

Разработчик не должен ставить себе задачи. Этим занимаются лиды и менеджеры.
Разработчик не должен проверять свою работу. Этим должны заниматься тестировщики.
Разработчик не должен хотя бы думать про эксплуатацию. Этим должны заниматься админы.
Разработчик не должен делать архитектуру. Этим должны заниматься архитекторы и лиды.
Разработчик не должен учиться. Его должен обучать работодатель.
Разработчик не должен думать про юзеров. Этим должен заниматься саппорт.
Разработчик не должен разбираться в базах. Этим должен заниматься специальный DBA.
Разработчик не должен разбираться в железе. Этим должен заниматься хелпдеск или железячник.
Разработчик не должен заниматься продуктом. Этим должен заниматься product owner.
Разработчик не должен в удобство. Этим должен заниматься UX-боец.
И ещё куча всего. Бекендеры не должны даже админку на бутстрапе. Фронтендеры не должны даже Node.js на Ubuntu поставить. Джависты не должны в JVM, а питонисты в PVM, так сказать. Скучной тикетной бюрократией тоже менеджеры. А планы оставим лидам и… да, менеджерам. Про прибыль пусть голова у бизнеса болит.

Тут… сложно с оценкой. Формулировать не хочу, попробовал, получил даже наброском две страницы. Предлагаю умственное упражнение. Найдите ответы на вопрос «в какого рода бизнесах и в каких задачах такие разработчики применимы?» Из «таких» при этом исключим редких узких специалистов, которые ничего больше не знают, но могут по названию функции сказать файл и номер строки в исходнике JVM. Их очень мало, живут справа на крае распределения.
Напомню некоторые важные элементы производства софта, чтобы вам было удобнее.
Экономика. Грубо говоря, количество денег на старте. Влияет на то, как долго вы можете что-либо делать до момента, когда что-то начнёт приносить прибыль, достаточную, чтобы покрывать текущие расходы. Например, у вас 1М рублей и разработчик Иванов за 100К рублей. Соответственно, уже через 10 месяцев на рынке должен быть МойСуперПродукт с остатком в 100К рублей (вам ведь всё ещё платить Иванову) после выплат за хостинг, рекламу, налоги и т.д. Если Ивановых два, у вас 5 месяцев, а продукт должен выдавать 200К. Если для надзора за этой парой вам нужен Сидоров за 200К, вам хана — бюджета на два с половиной месяца, затем пополнение списка «миллион закрытых стартапов». Примитивно, но наглядно.
Продукт. Разработка ради разработки не нужна вне стен квартиры. Программист программой решает задачу / проблему. Цельная совокупность решений составляет продукт. Целью разработки является выход продукта на рынок / в науку / в народные массы. Пока продукта нет, все работают в минус и на перспективу (ща мы наберём компетенцию на семи граблях и каааак ух!).
Качество. Иванов, не умеющий в эксплуатацию, склонен делать сервисы, падающие под слабой нагрузкой. Петров, не умеющий в базы, поставит базу колом своим селектзвёздочка на месячном логе. Мало того, что вы можете так нарваться уже на репутационные риски, так впереди могут оказаться претензии от клиентов. А, да, ещё Иванов и Сидоров будут месяц чинить. Посмотрите на Экономику — это минус 200К от вашего начального бюджета.
Форсмажоры. У вас два разработчика и один лид. Лида сбивает автобус. Что дальше? У вас бекендер и фронтендер, фронта сбивает автобус. Что дальше? У разработчиков всё хорошо, но автобус добрался до вас. Что дальше? Bus factor в прямом виде редко бывает, но в вариантах постоянно: болезни, семья, государство (смешные кейсы, когда руководителя проекта с Болотной в автозаке на весь день), усталость (мужики, не могу больше, ухожу в отпуск на месяц), бабло (мужики, за углом на 10К больше, пока-пока) и т.п. Ваш бизнес остановится или нет? А почему?

Как-то так. Клеймить и размахивать шашкой не буду. Можете посмотреть вакансии и резюме. Посмотреть оклады (почему Иванов 100К, а Петров 200К). Прикинуть, с какой командой и какой стартап хотя бы в теории может выжить в период разработки. Всё просто считается. Ну а потом ещё раз перечитать список и прикинуть, что такое хорошо, что такое плохо.

Книга: Kafka: The Definitive Guide

kafka
Gwen Shapira, Neha Narkhede, Todd Palino.
Kafka: The Definitive Guide. Real-Time Data and Stream Processing at Scale.
O’Reilly, 2017.
Понадобилось достаточно срочно прочитать одну (на стопку времени нет) книгу по Kafka, да ещё свежую, да ещё по нескольким темам, да ещё толковую. Повезло, вот это она.
Писали те, кто делает и пользуется. Потому текст получился почти строго по делу с внятными примерами и доходчивыми аргументами в пользу того или ного решения. Покрыты схемы раскатки, использование, админство, мониторинг и пара-тройка фенечек. Документацию книга не заменяет, конечно, но даёт отличный проход порога входа.
Вообще я больше привык критически брюзжать, потому про хорошие книги не знаю, чего сказать. Просто хорошая. Рекомендую всем, кто собирается возиться с Kafka.

IT в СССР (как убили вычтех, сумбурные итоги)

Подводить итоги решения 1969 года конспективно сложно, жахнуло по всему на 20 лет вперёд по всем фронтам. Но попробую, обозначив ключевые, как считаю, моменты.
Выбор сторонней системы в качестве эталона и стратегия совместимости с нею автоматически ставит копирующего в позу догоняющего и опаздывающего. Зачастую система версии 1 оказывается в руках тогда, когда производитель уже доводит версию 2 в лабораториях, а версия 3 зарождается в умах. Вы добываете версию 1. Реверсите её, разрабатываете свою производственную документацию, отдаёте на заводы, те начинают осваивать… Бац, в магазинах уже версия 2, а вы ещё и с первой не разобрались.
Вот в эту позу и согнали советский вычтех. Создали огромный НИЦЭВТ, набили инженерами и конструкторами, выдали план. Под зонтик Ряда набрали и других. Раковский (зампред Госплана и председатель МПК по ВТ) в печати рапортовал про «20 тыс. ученых и конструкторов, 300 тыс. рабочих и техников на 70 заводах». Вся эта махина переориентировалась на освоение выпуска новой для них архитектуры.
Также следует учитывать нюанс, которым постоянно играют в спорах, поворачивая в нужные спорщикам стороны. Как ни странно, но доля именно украденного и полностью склонированного на фоне всей номенклатуры в СССР была довольно мала. Часто копировались интерфейсы, а вот начинка была либо целиком своя, либо творчески доработанная (ниже пример из Еревана), либо по лицензии. Что, к слову, позволило СССР закрыть авторскими свидетельствами и патентами часть ЕС ЭВМ, а потом их ещё и по миру продавать. Да, совместимы с IBM 360, но железо другое. В основном.

Средний класс ЭВМ запускали серией ЕС (четыре поколения: Ряд-1..4). Ряд-1 — копирование IBM 360.
По времени судите сами. Т.к. работы по ЕС ЭВМ начались раньше, в 1971 году совместные испытания проходила уже первая ЕС-1020. Тогда же и начали выпускать. Год релиза оригинала — 1964. Отставание в семь лет.
По особенностям реверсинга снова судите сами (тут поможет глава «ЕС-1033 — триумф…» по воспоминаниям Бадрутдиновой (по ссылке 34-страничный PDF). ЭВМ ЕС-1030 разрабатывали в Ереване. Документации нет, потому в ход пошла креативность: выкинули из системы всё, что казалось лишним. Ну и отдали заводу, мол, я сделяль. Завод даже ДОС запустить не смог, ибо армяне бодро выкинули, как оказалось, элементы совместимости линейки IBM 360. Заводу пришлось выпускать 101 (!) бюллетень нулевых доработок. Один фиг машина оказалась капризная, ненадёжная, с производительностью в полтора раза ниже ТЗ. Выпускать начали с 1972 года (ещё год отставания).
А вот над этим абзацем я долго думал:

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

Как читать эти слова про завершение программы Ряд-1? Завершена работа по догонялке уже 9-летней давности серии. Всё-таки пришлось писать свои ОС, вложив офигилиард ресурса (4М команд в начале 70-х — это как сейчас заново Windows написать и отладить). Произошла адовая перестройка производства (99 типов периферии). Просто замечательно, если учесть, что в 1974 году Intel выпустила уже процессор 8080 (да и то с опозданием).

Такой вот старт серии.

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

  • Линия АСВТ (совместимость с Hewlett Packard HP-2000): 8 моделей.
  • Линия PDP-11: 11 моделей.
  • Линия VAX: 3 модели.
  • Линия Intel: 8 моделей.

Итого 30+ моделей, суммарным выпуском около 60К за все годы. Говорят, получилось лучше, чем ЕС. Правда, злые языки добавляют, что это по причине меньшего количества деталей, меньше возможности накосячить.


Опоздание опозданием, а что с качеством? Да как всегда. Я сам патриот хоть куда и за движ «СССР — родина слонов», но про ЕС ЭВМ почти ни одного доброго слова (окромя тех, кто их министерски выпускал, понятно) не вычитал. Вот в 1974 году сражаются с ЕС-1050: «По разным причинам ни одна из выпущенных до того времени ЕС-1050 не работала, и репутация машин ряда ЕС катастрофически падала». ПО РАЗНЫМ, Карл. Любопытные воспоминания, кстати. Коротенькие, но там и про вольтаж микросхем, и про непропайки, и про выбрасывание систем контроля. Также можно почитать и вот эту заметку: «В первой половине 80-х там стояли две ЕС1022. Обслуживало их человек 10, и без работы они не сидели».
Можно зайти с другой, менее земной стороны: в материалах специальной Комиссии Государственного комитета по науке и технике при Совмине СССР оценивают отставание от США по надёжности аппаратных и периферийных устройств во второй половине 1960-х в 10 раз. Грубо говоря, если американский инженер долбался с деталью раз в десять дней, то наш каждый день. // Этот же комитет, к слову, обозначил в 1966 году, что у одной лишь IBM конструкторов и производственной мощности больше, чем вместе у всех предприятий и организаций СССР, занятых вычтехом.
Каждый год задержки поставки ЭВМ потребителю означал наращивание отставания на год. Сейчас это не катастрофа (бжчки, да в 2008 году уже вовсю 4-ядерные Intel были с SSE4, хоть через десятилетие стойки забивай ими), а в те годы революционного развития такой разрыв — пропасть.

Цифровую микроэлектронику СССР и полупроводники в целом только ленивый не пнул. Отставание в 5..8 лет местами прям очень оптимистичная оценка. Мануэль Кастельс в начале 90-х и вовсе оценил в 20-летие, считая, что в 70-х наступил перелом и не зарос, так сказать.
В этом месте следует запомнить следующее: СССР мог в прототипы, эксперименты и изобретения, но в упор не мог в серийное производство нужным количеством с нужным качеством. Потому зачастую споры слепых с глухими. Одни твердят про первенство в том или ином, другие показывают фотографии пустых полок магазинов. Правы обе стороны. Но первенство осваивалось в стенах лабораторий, а вот на заводах была беда… ну… нет, там было множество хороших людей. Но делали они такоэ… Я внизу избранную библиографию даю, в ней книга Симонова, а в ней много цитат из архивов, а в цитатах упоминается доля брака. Лучше эти числа не видеть.
Здесь тоже множество проблем уже со старта. Но снова одна из стратегических — курс на копирование, клонирование, погоню за США. Тем, кто взвивается в праведном гневе, советую изучить историю серии К155, например, в контексте патентной чистоты. А если кажется, что это всего лишь примерчик, советую изучить масштабы использования этой серии. Как по мне, одна из важнейших в СССР за все годы. Правда, с ней тоже так себе получилось. ЕС-1030 сделали на К155, а поляки ЕС-1032 по той же схеме на SN-74 (оригинал, ага). Автоматически получили вдвое выше производительность. Бывает.

Чего же в итоге добились этой спорной реформой 1969 года? Тут тоже стоит хорошо подумать до того, как обозначить точку отсчёта. Если принять за точку тот абздольц, в котором учёные с инженерами пытались выкрутиться, и оценивать достижения относительно «ничего», будет множество поводов для гордости. Если в каждый год поставить рядом США (раз уж так стремились), получится неловко. Например, можно сказать, что в СССР на заводе «Ангстрем» освоили толстоплёночные схемы и освоили, ура! А можно из угла сказать, что в то же время (пока в СССР начинали осваивать) в США у IBM «уже работал завод-автомат, выпускавший 240 миллионов таких схем в год» (воспоминания Сергеева тоже рекомендую к вдумчивому осмыслению).
Всего с 1970 года по 1997 год в СССР было выпущено 15.5K+ ЕС ЭВМ всех серий и 60K СМ ЭВМ всех серий. Для сравнения: в 60-х IBM ежегодно продавала по 10K..15K, а PDP-11 было продано больше 500K. В масштабах СССР такой выпуск просто грустный. Следует признать, что другие модели некоторое время продолжали разрабатывать и выпускать вплоть до 90-х (что тоже, к слову, забавно). Ну т.е. нет, покрыть СССР слоем ЭВМ ни разу не получилось.
Все отрасли вычтеха были направлены на изучение, копирование, доработку, изготовление зарубежных образцов даже в ущерб здравому смыслу. Делалось это в условиях всё тех же эмбарго. В СССР нельзя было продавать ничего, что хоть как могло быть использовано не в мирных целях, так сказать. От материалов до готовой продукции. Потому добывали нужное в обход, через нейтралов, через подставные фирмы, через третьи руки. Яркий пример: «В августе 1973 года предприятию была поручена разработка и организация производства карманного микрокалькулятора на интегральных схемах с автономным питанием (БЗ-04). В качестве прототипа был взят калькулятор японской фирмы “Шарп”, который поступил в продажу в Японии месяц назад. .. так как никакой документации, кроме купленного в Японии образца, мы не имели» (цитирую по Сергееву). Т.е. ну вот обыденно так. Можно раз за разом перечитывать эту цитату, всё глубже погружаясь в контекст великой страны.
Или вот школьные компьютеры. Старый (2012 год!) пост на Хабре. Одним это «ого, 16 моделей!», но другим это «ага, DEC PDP-11, Intel i8080, Zilog Z80, Intel i8086/8088, 6502».
Программирование… Пожалуй, тоже там же. Я с удовольствием слушаю рассказы о том, как и что было, да и читаю тоже. Но в 80-х писал на BASIC, в 90-х на Pascal, в 2000-х на C, C++ и Java. А также SQL, HTML, JavaScript. И ещё несколько слов, в которых ни единой буквы из кириллицы. Советские книги, которые собирал, тоже были про Ada, Algol, Fortran, PL/1 и т.п. Снова ни одной буквы. В разговорах с советскими программистами рисовалась та же картина (ну, с учётом их времени, понятно). То, что выбивалось из мейнстрима, было загадкой: где найти? где посмотреть? где попробовать?
И так бесконечно. Признаюсь, бОльшую часть материала за последние недели две прочёл / пролистал впервые. И сейчас только один вопрос: что называть советской школой после середины 60-х? Вопрос не к головам, не к рукам, не к историческим реалиям (совершенно адовые примеры партийного «руководства»). Вопрос к самому определению. Советская школа чего-то в вычтехе — это школа копирования? Или школа превозмогания ради достижения слабого типового результата, достигаемого в нормальных условиях? Когда инженеры микроэлектроники углубляют подвал штыковыми лопатами и выгоняют продуктовый магазин из здания будущего завода — это круто или нет? Когда этот завод потом занимается погоней за США и героически догоняет на разномастном оборудовании результат N-летней давности — это круто или нет? Объективного ответа у меня нет. Субъективный есть: не круто. Вычтех был просран, пардон. Не догнали, не перегнали. Всплески героических подвигов и превозмогания говорят лишь о силе, воле и разуме отдельных людей и коллективов, но не про отрасль в целом. А в целом всё чрезвычайно грустно и печально закончилось. До сих пор хлебаем. Такие вот итоги. Можно ли было лучше? Не знаю. Наверное, можно. Только в условиях раннего феодализма 1950..60-х не получилось.

Тут вот избранная библиография. Опорные книги, которые достаточно полно передавали либо факты (цитаты из документов, спецификации), либо дух эпохи (воспоминания с невинными деталями). Литературы, конечно, на порядки больше, но если вам любопытно раскрутить историю самостоятельно, начните с этих книг:

  • [Малиновский Б., Ревич Ю. Информационные технологии в СССР. Создатели советской вычислительной техники. БХВ-Петербург, 2014] — хорошо описан ранний этап советского вычтеха.
  • [История информационных технологий в СССР. Знаменитые проекты. Компьютеры, связь, микроэлектроника. Книма, 2016] — сборник статей, хорошо про всплески превозмогания и успехов.
  • [Симонов Н.С. Несостоявшаяся информационная революция: 1940-1960. РФСОиН, 2013] — история электроники, микроэлектроники в контексте СССР, много работы с архивами.
  • [Сергеев В.С. Страницы жизни. Ангстрем, 1998] — мемуары технолога и директора вокруг «Ангстрема».
  • [Карпилович Ю.В. Так было. Минск, 2004] — мемуары главного инженера Минского завода ЭВМ.

Пожалуй, хватит.

IT в СССР (как убили вычтех, развязка)

Повторюсь и ещё раз скажу, что умных голов было много, потому о проблеме зоопарка думали на всех уровнях ещё с конца 1950-х. Без высокой степени совместимости невозможны проекты ЕГСВЦ Китова (1958..59 гг.), ОГАС Глушкова (1962..198x гг.), проект, мелькнувший в архивах Ершова, сайт которых упорно лежит (1964 г.). Эти проекты сами по себе очень интересны и погибли по другим причинам, об этом в другой раз, возможно. Факт в том, что не проснулись однажды с осознанием, видели и размышляли.
Но размышлять мало, надо делать. А это не получилось. Сейчас коллективы разработчиков и заводчан назвали бы «недоговорными». Вы могли договориться с кем-либо в личном порядке, но если требовалась официальная поддержка… Беда. Госплан, бюрократия, очереди производства, подковёрная грызня ведомств, планы, сроки, внезапная срочность к знаковым датам.
Попробуйте сами. Вы Иванов, главный конструктор ЭВМ Петя-1, у вас за плечами десять лет оригинальных архитектур и десятки людей в коллективе. И есть Сидоров, главный конструктор ЭВМ Вася-2М, у которого тот же анамнез. Приходит к вам Сидоров и вы за чайником чая обсуждаете унификацию всего. Согласны. Унификация рулит. Но из этого следует, что часть уж очень оригинальных архитектур надо выбросить, а часть переделать, внедрив общие компоненты. Скажите, Иванов, вы готовы отказаться от Пети-1? От государственных наград? От премий? От места автора первой в мире полуторичной 11-разрядной квадратно-выпуклой ЭВМ, выдающей 146 операций в венерианскую секунду? А в глаза коллективу посмотреть? Это что же, они тоже всего лишаться? И все эти годы они неправильное делали? А как вы своему министерству объясните, что Сидоров из другого министерства более стратегически разработку вёл? В конце концов, это у Сидорова его Вася-2М фигня, а вот у вас уж точно наикрутейший Петя-1!
Внутри СВОИХ систем конструкторы занимались унификацией, конечно. Нормальный инженер не может этим не заниматься. Особо достоин упоминания Рамеев, заложивший в своих Уралах потенциал единой линейки ЭВМ на разные уровни задач. Но и всё, пожалуй.

В таких ситуациях приходит руководство и принимает волевое решение. Могло и позже, наверное, но с 1965 года по миру начались поставки гениальной в производстве, унификации и развитии IBM System/360 (тут все разработчики встали и поклонились упоминанию источника восьмибитовой чумы), которая прям вот была почти именно то, что всем надо было. Руководство напряглось и обратилось к экспертам, требовалось разработать аванпроект ОКР «Ряд» (линейка машин, совместимость и прочее).
Эксперты (ИТМиВТ во главе с Лебедевым) в ответ в 1966 году выдали вялый 50-страничный отчёт. В нём скептически отозвались об IBM 360, да и ничего толкового не предложили. Министерство озадачилось. Каждый крупный коллектив вместо общей архитектуры толкал свою (Москва, Киев, Минск, Ереван, Пенза). Министерство озадачилось ещё больше. Ведь всё честно сделали. Дали учёным и конструкторам возможность высказаться, выработать общий вектор. Не получилось. Ну ок.
Разработку аванпроекта поручили сторонникам (как понимаю по воспоминаниям Левина) выбора IBM 360 в качестве основы и всё было решено ещё ДО января 1967 года (заседание, на котором решение утвердили) и уж точно до 1969 года (финальное совещание с ведущими разработчиками). Почему я считаю, что решено всё было ДО?
Большинство стран, участвовавших в «Ряде», было против IBM 360, топили в пользу английской Системы-4. Только ГДР, уже осваивавшая систему, была за американцев. Большинство участников совещания 1969 года были против IBM 360, топили за Систему-4, раз не получилось своё проработать. Основные аргументы были очень весомыми:

  • СССР не мог покупать у IBM ничего, ибо эмбарго.
  • К моменту клонирующего производства IBM 360 уже была бы значительно устаревшей системой 10-летней давности.
  • Связей с IBM нет никаких и не предвидится, потому никаких стажировок, поддержки и остального.
  • С англичанами уже связи, уже стажировки, уже готовность к поставкам, помощи, обучению, наладке.

А со стороны сторонников аргумент один: у IBM 360 огромный богатый софт, на который ушли тысячи человеко-лет, мы круто победим, его стырив через тех же немцев. Ура-ура. По пути и свой напишем, не беда. Потому IBM 360, всем спасибо, расходитесь.

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

После чтения конспекта заседаний и докладных и вообще осмыслении у меня следующие соображения… За два-три года до 1969 года все узнали мнение всех сторон. И это мнение не менялось. Именно обсуждения и диалога я нигде не нашёл. Стороны только фиксировали свою позицию и больше не колебались. Это инженеры и администраторы довольно небольшой прослойки, не первое десятилетие знакомые. Битые жизнью, партией и вообще. Уверен, для них не был сюрпризом ни итог 1967 года, ни итог 1969 года.
Да, это глупый выбор. Очень наивный, очень оптимистичный. Но у него есть причины.
Официальная нередко за кадром в блогах или без акцента, а я акцентирую: острая нехватка программистов и программ. Компьютеры без софта не нужны. Софт пишут программисты. При разработке новой системы требуется новый набор ВСЕГО для всех отраслей от операционной системы до складских журналов. Делать этот софт было некем. Отсюда и такой упор на то, что вот у IBM овердофига всего, писать заново не надо, достаточно обеспечить совместимость. На 70% выбор архитектуры был вызван выбором программного обеспечения.
Неофициальная, мне кажется, тоже имеет право на. Вы министр. Перед вами разработчики компьютеров, которые за годы не смогли договориться и выпустить единое. Перед вами заводы, которые за годы не смогли наладить стабильное и качественное производство. Перед вами программисты… ах да, их нет. А те, что есть, развлекаются переписыванием кода под 25+ систем. Перед вами Госплан и партия, которые вообще понятия не имеют, чего хотят, но хотят этого очень. Вот вы точно будете тем же людям давать вариант, с которым они уже не справились? 20 лет анархии, феодализма и махновщины. Давшие интереснейшие результаты для науки, но не учитывавшие интересы страны.
Вот, собсно, начальственный тапок по столу и стукнул. В этой истории отлично выступили все. Интересно отметить и то, что упускают из виду те, кто упоминает Уралы в качестве альтернативы: Уралы не выдвигались. Это замечательный ряд машин с большим заделом, готовые для сети, пошедшие в серию. Но напомню: каждое КБ тянуло одеялко на себя и фантазировать на тему «советские конструкторы единым фронтом выступили за отечественную разработку [любого конструктора]» не стоит. Не было такого. Этот шанс тоже профукали.

С 1969 года и отсчитывают начало конца. Но почему? Всё-таки за основу взяли популярную и мощную систему. Да и выпуск своих систем не прекратили, да и вовсе продолжили разрабатывать. Как и ожидалось, не всё просто.

Продолжение следует.

IT в СССР (как убили вычтех, зоопарк)

Можно сказать, что до судьбоносного 1967 года вычтех СССР за [условно] 20 лет добился многого. Прошла пора первых пробных и полуподпольных (Брук отжигал) экспериментов, компьютеры пошли в серию. Даже не так. В СЕРИИ. Бегло осмотрим успехи только лишь «массовых» или значимых выпусков, оставляя за кадром специальные машины. В скобках количество выпущенных ЭВМ до 1967 года. Ну, примерно, т.к. разбивки по годам я не нашёл.
БЭСМ-1 (1), БЭСМ-2 (67), БЭСМ-4 (30), БЭСМ-6 (завершена к 1966 году, до 1987 года выпустили 355), М-20 (20), Днепр (500), Весна (19), Снег (20), Киев (2?), Минск-1 (220), Минск-11 (11), Минск-12 (5), Минск-14 (36), Минск-16 (1), Минск-2 (118), Минск-22/22М (734), Наири (500?), Сетунь (46), Стрела (7), Урал-1 (183), Урал-2 (139), Урал-3 (22), Урал-4 (30). А ещё Мир, Проминь, Раздан, Урал-11. И ещё машинки, но я утомился выписывать.
Считаем. 25+ моделей, 2700+ экземпляров. Штуковины размером от шкафа до опенспейса. От суперкомпьютеров до боевых середняков «обычных» заводов. И это лишь к моменту, когда проблему озвучили с верхов, а ведь каждый год появлялись новые модели в ещё бОльших количествах.

Итак, проблема: они друг с другом не совместимы. Некоторые ламповые, некоторые полупроводниковые. У одних в байте 6 бит, у других 7. Или вот Сетунь вообще троичная ЭВМ. Разная разрядность. И системы команд разные. И периферия. Всё, блин, разное. Промышленность не успевала лицо к ладони прикладывать.
Как, впрочем, и программисты. Ведь для каждой новой модели, у которой что-то было другое, софт приходилось писать заново. Писали его всё ещё в машинных кодах, языки едва начали выходить из стадии домашних заготовок, до Алголов и Фортранов в массах было далеко. Учитывая то, что лишь на ввод программы можно было потратить десятки часов… Ну прекрасно же. Романтика!
Вишенкой на тортик была традиционная беда советской промышленности — качество и количество деталей. В 1952 году попытка заменить немецкие лампы в М-1 на начавшие поступать отечественные пентоды 6X4 завершилась тем, что инженер поехал на завод лично отбирать несколько сотен ламп, уж больно разброс значений был велик (источник у Малиновского в большом тексте, поищите по слову «Светлана»). У военных с их спецприёмкой и цепким взглядом гэбистов на производство ситуация была лучше, но тоже не идеальна. Про опыт машиниста М-50 в 1959..1960 годах можно почитать здесь. По мелькающим в других статьях и мемуарах эпизодам… ну, думаю, автор объективно описал реалии.
Как итог, десятки КБ и заводов, сотни учёных, тысячи инженеров и армия рабочих множили зоопарк ЭВМ с азартом мартовских кроликов, тем самым умножая проблему ежегодно.

Что любопытно, на ЭВМ советская централизация и диктатура дала сбой. Творилась полная анархия, разработчики не знали друг о друге, заказы на заводы пропихивались разными занятными способами (тут помогут первые страницы книги «Так было» Карпиловича), программисты творили софт без единой базы (хотя… ну какое единство при такой «совместимости»?). Как в таких условиях реализовать что-либо плановое — не понять. Могу понять те гордость и спокойствие, с которым конструкторы вместе с историками описывают тот период, но есть нюанс: вспоминают свою работу, свои разработки. Был замечательный коллектив, с энтузиазмом придумали, воплотили, [не] получили премию. Но почти совершенно не упоминают то, с каким трудом это внедрялось, какие плелись интриги, как бригады с заводов мотались месяцами жить у пользователя в машинном зале, чтобы наладить очередное чудо. Боюсь, сгладило бы пастораль, на которой бяками сплошь партия и бюрократы.
Однако, следует признать, что всё-таки отрасль ЭВМ работала. Это сейчас не панибратски похлопывающая по плечу фраза, наоборот. Действительно хорошие архитектуры. Действительно толковое применение и зафиксированные рекорды. БЭСМ-6 няшка. Уралы няшки, Наири няшки. Всё нужное считалось быстро и по делу. Первые там, первые сям.
Но… Давайте на всего одном примере: Сетунь. В вычислительном центре МГУ силами 20 начинающих сотрудников создали ЭВМ. Ну и хорошо, да? Они сделали её троичной. Этому очень умиляются десятилетиями, но для неё надо было написать заново ВЕСЬ софт, у неё была лютая несовместимость вообще со всем. Ну кого из учёных это волновало? Никого. Сетунь начали толкать в серию. При этом Брусенцов отдал Казанскому заводу комплект чертежей, который разрабатывался для завода в Киеве. Казанские смотрели с интересом. Дальше началась эпопея с производством. Никому толком не нужная, никуда не влезающая по общей практике машина, созданная любителями вне системы производства. С грехом пополам выпустили 46 серийных образцов за 5 лет, да и всё. Зачем вообще её было создавать (а не выбить для МГУ имеющиеся варианты)? Зачем настолько выпадающую из ряда машину в серию? Зачем эту серию утвердили (потом опомнились и гасили)? Почему заводчан подключали так поздно? Сколько нужно разработчиков, чтобы поговорить с админом до запуска сервиса?
Так тонко подвожу к выводу, который сделал. Нет, учёные во всех этих историях не жертвы и не непонятые гении. В массе своей (если судить по разработкам) они упорно творили без оглядки на действительные нужды страны. В ущерб разуму, в ущерб стратегии, производству и общему благу пробивались свои архитектуры, но не архитектуры СССР, но Иванова, Петрова, Сидорова и ещё десяти дядь, решивших, что им никто не указ. Умные. Хорошие. Интересные люди. Но без нужного уровня [само]контроля. И укажу явно: были бюджеты, были заказы, всё было. Там, где не было, вина руководителя, который вне мейнстрима по собственной инициативе клепал. Но и после такого изделия пускались в серию, а коллективы получали не по рукам, но по конверту. В общем, гуляй, пока играет музыка.

Продолжение следует.