VM/SP - это в те времена уже S/370 или S/390. В остальном все верно, десятки и сотни тысяч строк кода IBM - читается очень легко и быстро (подозреваю, что это легкость достигается за счет того, что исходный код IBM OS VM/SP написан на PL/S) и во-многом благодаря развитым макросам. Даже название IBM ассемблера было заменено на HLASM (High Level ASM).
Неужели Вы серьезно относитесь к аудитории Хабра? Нет, 10-15%% здесь профи, подстраиваться под остальных - так себе занятие. Я вот давно жду статью с условным названием: "ООП - враг серьезных программных проектов. Функциональное программирование - пусть не лучший, но выход из тупика ООП". Очень хочется изучить поведение хабровцев, как реакцию на эту статью.
Абсолютно верное возражение! В стародавние времена мы экономили и размер программы и время выполнения кода. Люди тогда знали и ассемблер и кобол, соответственно, идеи оптимизации плавно перекочевывали из ассемблера в COBOL/PLI/FORTRAN/LISP и т.д. Экономия памяти была очень значительной, при этом код также ускорялся, а единственным минусом была потеря реентерабельности.
Вспомнил конец 70-х, начало 80-х, НИИАП (потом НПО АП, А-1001), а не вики, коим, похоже пользуются большинство комментирующих авторов. Хотел написать подробный разбор статьи, но наткнулся на Ваш комментарий, с которым согласен практически полностью. Это самое зрелое, что я прочитал в этой статье. Хочу добавить немного, дело в том, что последний запуск Науки мог бы состояться, если бы Пилюгин со своим модернизированным КОРДом, заложил бы в него «соответствующую логику», которая была реализована в СУ будничных, «вечно аварийных» (каждый третий запуск с вероятностью 70-80% отказ систем второй ступени), — РН «Протон», и при этом нагрузка обычно выходила на орбиту. Я хочу сказать не Вам, а молодежи, которая пишет здесь — отказ отдельных двигателей на старте — это НОРМАЛЬНО, вполне штатная ситуация, для компенсации последствий и существуют системы, подобные КОРД. Тем не менее Пилюгин не заложил в СУ Н-1 необходимые алгоритмы, соответственно, при возникшем пожаре не была отстрелена первая ступень раньше расчетного времени и не была передана команда на вторую ступень отработать дополнительное время. При втором запуске Н-1 из-за КОРДа был уничтожен основной и поврежден второй стартовый стол, что и отбросило СССР от Луны. Я считаю, что проблема была не технической… Более подробно свою (допускаю, что — субъективную) версию событий я описал в предыдущих публикациях Хабра: habr.com/ru/company/mailru/blog/372897 в комментариях.
Вам «повезло», Вы полжизни смотрели в зеленый экран, а мне видимо нет, я только 6 лет смотрел в «зеленый экран» и последний раз его видел летом 1989 года и он уже тогда был многоцветным. Со своей стороны хочу сказать, что свое личное мнение не надо выдавать за тенденцию. Я знаю небольшую группу организаций, которые обязательно смигрируют с МФ, причем в 90% случаев это будут только политические причины (для РФ это будет 100%).
Вы лучше себя пожалейте, я думаю, что Вы имеете «зуб» на IBM (Вас несправедливо уволили, или вовремя не повысили ЗП и т.п.), из-за этого перенести свою обиду на технологию — несколько мелко. Да у МФ есть недостатки — их немного и мы о них знаем. Говорить о том что это закостенелая технология — глупость, настоящий реальный техспец так не скажет (хотя, может быть Вы 30 лет в MVT/SVS смотрели...). Реальные проекты сейчас лежат на стыке МФ — РС графика, и если нет требований по импортозамещению — то это очень жизнестойкая спарка.
Документация была в порядке. Проект был повторен в Х86 за 2,5 года, тем не менее, МФ's не отключали еще 12 лет, при этом РС оборудование было было полностью заменено два раза, перед тем как выключили последний МФ. Что они делали еще больше 10 лет после разработки софта? Они доводили производительность системы до уровня МФ. Новая и старая системы крутились параллельно. Лишь по достижении приемлемых характеристик надежности и скорости функционирования переключились на новую систему. Совокупная вычислительная мощность новой системы превысила мощность старой системы более чем на порядок, при сохранившимся функционале и кол-ве запросов к системе, при этом с трудом вписавшись в сопоставимые временные задержки при работе на старых МФ. Я молчу, что при миграции деньги особо не считали, тк задача
А что это Вы обижаетесь? Принимаете Все на себя? Узнали себя в моих словах?
В РФ, я знаю, как минимум, одну компанию, которая будет вынуждена уйти с МФ на «калькулятор», как мы шутим — «в облака», главное, чтобы не буквально. Они осуществляют миграцию только по политическим причинам!!! Они имеет квалиф.спецов по МФ; компания понимает все сложность и неадекватность процесса перехода; она осознают техническую неэффективность миграции, которая будет компенсирована дополнительным количеством калькуляторов; они знают о потребном временном лаге и в какие деньги это выльется. Политическое решение принято, а техническое решение, пока, окончательно не готово, несмотря на весь тех.бэкграунд и финвозможности этой компании. Вот это подход! Люди уже четыре года подступаются к этому вопросу, потому что право на ошибку — нет, соответственно цена не фиксируется. Вот так люди должны мигрировать с МФ! Когда они понимают, что они теряют и что может быть смогут приобрести. И, без обид, слава Богу, что Вас нет в этой команде.
Если 10-15 лет не проблема, для софта который сделали за 2-3 года, то Вы великий оптимист. Обычно, по опыту миграции — бюджет превосходит в 3-10 раз от запланированного, результатами недовольны, как правило, теряется функционал, а потом, тихо, без помпы, без прессы, все возвращается назад к МФ. Даже, в России есть такие примеры, где руководство отыграло назад (часто по ТВ говорят об этом предприятии), когда стало понятно, что пришедшая высокопрофессиональная поросль просто «кинула» заказчика, наобещав «с три короба», но так не воплотив задуманное (ТЗ) «во плоти» (ну, не получилось, с кем не бывает...). Поэтому, я не читаю сейчас отчетов о миграции с МФ (ложь, раздувание щёк и тому подобное) и Вам не советую.
Респект Вам! Вы один (плюс еще один) здесь защищаете весьма достойную, но абсолютно неизвестную для «молодежи» — платформу. Столько глупости, неуместных аналогий и дичайшей непрофессиональности по обозначенной теме можно встретить только в России! (Даже в Венгрии, Польше и Израиле больше «адеквата», по этой теме, чем на Хабре) И хотя статья — это полный позор для автора, Ваши комментарии наголову, по сути, превосходят саму статью. Успехов Вам в этой заранее проигрышной на территории РФ — борьбе!
Статья — позор автору. Убогий детский язык выдает в авторе его возраст. Как он работает на МФ? Порой кажется он не знает азов этой платформы, но написано, так, что должно понравиться аудитории 35-. Вопрос к Хабру: — у вас есть хотя бы первичный контроль предлагаемых к опубликованию текстов?????
Возможно, я плохо объяснил..., 1 уровень ОС — аппаратуры (не домен), ОС1 защищает, управляет и виртуализирует всю аппаратуру, отделяя реальное железо от других слоев. 2 уровень — гипервизор, или КОС, он не знает ничего про реальное железо, работая на логическом уровне. 3 уровень — другие ОС, потребности которых транслируются через ГиперКос в ОС1, контролируя и защищая всё, что нужно на разных этапах.
Странное решение писать драйверы аппаратуры в ОС. Почему не сделать систему управления аппаратурой как отдельную ОС (нижний слой). На него водрузить ГипервизорОС, а уже в гипервизор грузить разные ОС в разные адресные пространства с хорошей изоляцией и политиками. Некоторые вопросы защиты решились бы за счет выбранного архитектурного решения. Главное, максимально изолировать VM's, дабы проблемы в одной VM не стали проблемой всего компа. А далее, внедрять Ваши придумки..., главное, с переключением контекстов не переусердствовать. Таким образом, Вы могли-бы получить киберось как для телефона, так и для коммутатора, IoT и компов с различными процессорами. А так, как Вам не нужно сдавать Вашу Ось в дурацкую «опен», можно было максимально использовать в своей Оси — аппаратуру. А сам гипервизорОС стал-бы аппаратнонезависимым, что хорошо бы сказалось на бюджете развития Проекта.
VM/SP - это в те времена уже S/370 или S/390. В остальном все верно, десятки и сотни тысяч строк кода IBM - читается очень легко и быстро (подозреваю, что это легкость достигается за счет того, что исходный код IBM OS VM/SP написан на PL/S) и во-многом благодаря развитым макросам. Даже название IBM ассемблера было заменено на HLASM (High Level ASM).
Неужели Вы серьезно относитесь к аудитории Хабра? Нет, 10-15%% здесь профи, подстраиваться под остальных - так себе занятие. Я вот давно жду статью с условным названием: "ООП - враг серьезных программных проектов. Функциональное программирование - пусть не лучший, но выход из тупика ООП". Очень хочется изучить поведение хабровцев, как реакцию на эту статью.
Абсолютно верное возражение! В стародавние времена мы экономили и размер программы и время выполнения кода. Люди тогда знали и ассемблер и кобол, соответственно, идеи оптимизации плавно перекочевывали из ассемблера в COBOL/PLI/FORTRAN/LISP и т.д. Экономия памяти была очень значительной, при этом код также ускорялся, а единственным минусом была потеря реентерабельности.
Вы лучше себя пожалейте, я думаю, что Вы имеете «зуб» на IBM (Вас несправедливо уволили, или вовремя не повысили ЗП и т.п.), из-за этого перенести свою обиду на технологию — несколько мелко. Да у МФ есть недостатки — их немного и мы о них знаем. Говорить о том что это закостенелая технология — глупость, настоящий реальный техспец так не скажет (хотя, может быть Вы 30 лет в MVT/SVS смотрели...). Реальные проекты сейчас лежат на стыке МФ — РС графика, и если нет требований по импортозамещению — то это очень жизнестойкая спарка.
В РФ, я знаю, как минимум, одну компанию, которая будет вынуждена уйти с МФ на «калькулятор», как мы шутим — «в облака», главное, чтобы не буквально. Они осуществляют миграцию только по политическим причинам!!! Они имеет квалиф.спецов по МФ; компания понимает все сложность и неадекватность процесса перехода; она осознают техническую неэффективность миграции, которая будет компенсирована дополнительным количеством калькуляторов; они знают о потребном временном лаге и в какие деньги это выльется. Политическое решение принято, а техническое решение, пока, окончательно не готово, несмотря на весь тех.бэкграунд и финвозможности этой компании. Вот это подход! Люди уже четыре года подступаются к этому вопросу, потому что право на ошибку — нет, соответственно цена не фиксируется. Вот так люди должны мигрировать с МФ! Когда они понимают, что они теряют и что может быть смогут приобрести. И, без обид, слава Богу, что Вас нет в этой команде.