Вряд ли кто-нибудь слышал об операционной системе DOS-777. А такая реально существовала. Правда в действительности это была самая обычная MS DOS с незначительными изменениями, предназначенная для работы на единственном компьютере и выполнения одной единственной программы. Своим появлением этот клон в некотором роде обязан проблеме обратной совместимости. Но обо всем по порядку.
Новая и важная программа вдруг повела себя совершенно загадочным образом. Это настолько взбесило ее авторов, что было решено дисассемблировать MS DOS, разобраться в нюансах ее работы и найти причины странных ошибок. Сейчас, даже в запальчивости, вряд ли кто-то решится дисассемблировать, например, Windows-10 и разобраться во всех ее особенностях. Но тогда, в начале 90-х, когда ОС представляла собой три сравнительно небольших файла, их дисассемблирование и анализ заняли недели две.
Было обнаружено множество мелких особенностей, которые вряд ли кому-то сейчас интересны. Но в те времена по результатам анализа можно было даже заполнить недостающими названиями поля внутренних таблиц MS DOS, которые в одной из книжек серии «Библиотека системного программиста» под редакцией Фроловых (издательство «Диалог МИФИ») были обозначены как «зарезервированные».
Повторюсь, вряд ли все эти тонкости кому-то сейчас интересны, но о трех найденных нюансах, так или иначе связанных с проблемой обратной совместимости, пожалуй, стоит упомянуть.
Нюанс первый. Самые ранние «резидентные» программы, например, «SideKick», прямо по контексту команд внутри MS DOS искали адрес внутреннего флага «занятости» ОС. В следующих версиях этот контекст изменился, да и появилась документированная функция запроса флага, но несколько «старых» команд были специально перенесены в сегмент данных (на них управление не попадало), чтобы древние программы по-прежнему находили нужный контекст. На ум приходит аналогия со спуском нового корабля, получающего имя легендарного предшественника. Тогда по традиции из старого корпуса вырезается плита и крепится как мемориальная доска на новом корабле. Так вот, все версии MS DOS несли на борту маленький кусочек самой первой версии 1981 года.
Следующий нюанс был любопытнее. Оказалось, что перед запуском любого EXE-файла MS DOS проверяет среди его команд определенный контекст в определенном месте. Если он там находится – ОС слегка «раздвигает» соседние команды и добавляет команды PUSH CX и POP CX.
Поскольку в контексте присутствовала команда LOOP, очевидно, это исправление ляпа какого-то разини из MicroSoft, забывшего, что цикл портит этот регистр. Рекламный слоган: «в новой версии MS DOS даже старые программы работают лучше!» заиграл неожиданными красками. Мы не пробовали искать, какая поделка MicroSoft исправляется таким образом, зато были предложения написать свою программу с ассемблерной вставкой так, чтобы нужный код попал в нужное место. По мысли автора, далее нужно всего лишь иметь зависимость от содержимого CX. Когда MS DOS вставит ненужную POP CX, поведение программы изменится, можно тащить MicroSoft в суд за вредоносные действия и трясти с нее миллионы. Но поскольку предлагавший это по судам никогда не ходил и адвокатов (тем более, американских) не нанимал, дальше трепа в курилке дело не пошло.
И, наконец, третий нюанс, который, как выяснилось, и был причиной ошибок. Это работа с 20-ой адресной линией. Для молодого поколения, которое, к счастью для себя, не сталкивалось с подобными вещами, вероятно, потребуется объяснение. Первоначальный вариант персонального компьютера с 8086 имел соединение с оперативной памятью 20-ю адресными линиями. Сам адрес вычислялся в команде сложением двух частей: т.н. сегмента (16 старших бит из 20) и т.н. смещения (16 младших бит из 20). Таким образом, формально можно задать две части, сумма которых больше, чем два в двадцатой степени. Но ничего страшного не происходило. Перенос из последней 19-ой линии (они нумеруются с нуля) просто пропадал и получался адрес в первых 64 Кбайтах.
Когда примерно в 1986 году появились 32-х разрядные процессоры и компьютеры, 20 адресных линий увеличились до 30 (а не до 32, поскольку 0-ая и 1-ая линии стали внутренними). Короче, появилась нормальная 20-ая адресная линия и никакого «заворота» в младшие адреса уже не получалось.
Лично я никогда не видел в программах использования трюка с «заворотом». Если такие и были, это уж совсем какая-то седая древность и дурной стиль. Но в Америке неизвестно кто для совместимости с неизвестно чем, вдруг так озаботился надуманной проблемой, что для 20-ой линии в компьютеры была добавлена электрическая схема, позволяющая ее обнулять! Прямо так и говорилось: включить и выключить 20-ую линию.
А это было время, когда дурость одного деятеля, заявившего, что «640 Кбайт хватит на все задачи» становилась все яснее и яснее. Появились всякие памяти «expanded», а как раз из-за 20-ой линии появился 64 Кбайтный уютный «чуланчик» в памяти выше мегабайта, на который первой лапу наложила сама MicroSoft и поместила туда MS DOS, немного освобождая, тем самым, пресловутые 640 Кбайт. При этом работа с 20-ой линией внутри MS DOS заставила вспоминать поговорку про дурака и писаную торбу. При обращении к функции DOS эта адресная линия, естественно, включалась, чтобы получить управление выше мегабайта. А при выходе из функции DOS эта линия… Думаете, восстанавливала исходное состояние? Выключалась? Включалась? Мы тоже так думали и не угадали. Оказалось, что при первом обращении к DOS и возврате в программу 20-ая линия отключалась, а при последующих обращениях (т.е. обращениях из программы с тем же PSP) оставалась включенной. Это и сбило всех с толку и при отладке (а отладчик сам обращался к функциям DOS) осталось незамеченным. А поскольку важная программа требовала много памяти для команд и данных и располагалась выше мегабайта, то неожиданное отключение у нее одного бита в адресе приводило к самым разнообразным эффектам.
Выход был простой: при старте один раз обратиться к DOS, например, запросить номер версии, затем включить 20-ую линию и забыть о ней как о страшном сне. Поэтому никакой специально исправленной DOS, как мы сначала опасались, создавать не потребовалось. Но поскольку было жаль уже потраченных двух недель, вместо штатной DOS все же был использован ее клон, который вообще не дергал эту чертову 20-ую линию и имел еще несколько мелких улучшений. Этот клон и получил название DOS-777 по номеру отдела, где все это происходило.
На мой взгляд, есть и еще худшее решение о совместимости, чем фокусы с 20-ой линией. Это регистры команд MMX, совмещенные с регистрами FPU. Я читал такое объяснение этому архитектурному решению: при переключении задач, ОС запоминает контекст остановленной задачи, в том числе регистры FPU. При использовании MMX, они автоматически также будут запоминаться и восстанавливаться. По-моему, это решение не выдерживает никакой критики: к моменту, когда реально появились программы с MMX, сменилось несколько версий (чуть не поколений) ОС, например, той же Windows. Проще было объявить, что до такого-то номера версии одновременно несколько задач с MMX работать не будут. Вместо этого теперь на веки-вечные MMX и FPU мешают друг другу. И всего лишь из-за попытки совместимости с какими-то старыми Windows времен, когда еще не было MMX, и про которые все уже давно забыли.
Таким образом, проблема обратной совместимости объективно существует, и решать ее иногда приходится. Но если в первых двух приведенных примерах решение было остроумным, и главное, скрытым для пользователей, которым эта совместимость ни к чему, то в двух последних примерах попытка совместимости (на мой взгляд, надуманная!) привела к вычурным аппаратным решениям и породила проблемы. Причем совместимость уже тогда гораздо лучше обеспечивалась специально разработанным режимом виртуального 8086.
Главной же бедой любой обратной совместимости является то, что с каждым годом пользователей, которым она нужна, все меньше и меньше. А учитывать ее приходится всем.
Здравствуйте, кт, Вы писали:
кт>Главной же бедой любой обратной совместимости является то, что с каждым годом пользователей, которым она нужна, все меньше и меньше. А учитывать ее приходится всем.
Клетка. В ней 5 обезьян. К потолку подвязана связка бананов. Под ними лестница.
Проголодавшись, одна из обезьян подошла к лестнице с явными намерениями достать банан. Как только она дотронулась до лестницы, вы открываете кран и из шланга поливаете ВСЕХ обезьян очень холодной водой. Проходит немного времени, и другая обезьяна пытается полакомитЬся бананом. Те же действия с вашей стороны. Третья обезьяна, одурев от голода, пытается достать банан, но остальные хватают ее, не желая холодного душа.
А теперь уберите одну обезьяну из клетки и замените ее новой обезьяной.
Она сразу же, заметив бананы, пытается их достать. К своему ужасу, она увидела злые морды остальных обезьян, атакующих ее.
После третьей попытки она поняла, что достать банан ей не удастся. Теперь уберите из клетки еще одну из первоначальных пяти обезьян и запустите туда новенькую. Как только она попыталась достать банан, все обезьяны дружно атаковали ее, причем та, которую заменили первой еще и с энтузиазмом.
И так, постепенно заменяя всех обезьян, вы придете к ситуации, когда в клетке окажутся 5 обезьян, которых водой вообще не поливали, но которые не позволят никому достать банан. Почему?
Потому что тут так принято...
ЗЫ. Как-то каким-то чудом откопал свою первую виндовую программу — игра Охота на лис, которую писал на виндовом Borland Pascal под Win 3.1. Я точно помню, что она ещё работала под 98 виндой. А вот в XP уже не запустилась
Здравствуйте, кт, Вы писали:
кт>Следующий нюанс был любопытнее. Оказалось, что перед запуском любого EXE-файла MS DOS проверяет среди его команд определенный контекст в определенном месте. Если он там находится – ОС слегка «раздвигает» соседние команды и добавляет команды PUSH CX и POP CX. кт>Поскольку в контексте присутствовала команда LOOP, очевидно, это исправление ляпа какого-то разини из MicroSoft, забывшего, что цикл портит этот регистр. Рекламный слоган: «в новой версии MS DOS даже старые программы работают лучше!» заиграл неожиданными красками. Мы не пробовали искать, какая поделка MicroSoft исправляется таким образом, зато были предложения написать свою программу с ассемблерной вставкой так, чтобы нужный код попал в нужное место. По мысли автора, далее нужно всего лишь иметь зависимость от содержимого CX. Когда MS DOS вставит ненужную POP CX, поведение программы изменится, можно тащить MicroSoft в суд за вредоносные действия и трясти с нее миллионы. Но поскольку предлагавший это по судам никогда не ходил и адвокатов (тем более, американских) не нанимал, дальше трепа в курилке дело не пошло.
Интересно, сколько им за это отвалили? И на сколько версий продержалась защита?
кт>На мой взгляд, есть и еще худшее решение о совместимости, чем фокусы с 20-ой линией. Это регистры команд MMX, совмещенные с регистрами FPU. Я читал такое объяснение этому архитектурному решению: при переключении задач, ОС запоминает контекст остановленной задачи, в том числе регистры FPU. При использовании MMX, они автоматически также будут запоминаться и восстанавливаться. По-моему, это решение не выдерживает никакой критики: к моменту, когда реально появились программы с MMX, сменилось несколько версий (чуть не поколений) ОС, например, той же Windows. Проще было объявить, что до такого-то номера версии одновременно несколько задач с MMX работать не будут. Вместо этого теперь на веки-вечные MMX и FPU мешают друг другу. И всего лишь из-за попытки совместимости с какими-то старыми Windows времен, когда еще не было MMX, и про которые все уже давно забыли.
В принципе это было малой проблемой, потому что одновременно FPU и MMX в одной программе практически не использовалась, и никакое соглашение по вызову не допускало сохранение данных в FPU и MMX за пределами набора собственно аргументов и результатов функций.
Основная же диверсия была не в этом, а на 20 лет раньше, когда какой-то диверсант решил, что вместо нормально нумерованных регистров FPU там должен быть стек. Если бы не это — проблема от того, что FP5 является одновременно MM5 для некоторых операций, волновала бы не больше, чем то, что сейчас EAX может хранить число, указатель или кусок строки.
А начиная с AVX это без разницы потому, что в нём повторены команды MMX, и FPU можно применять независимо. Правда, тот AVX не везде (у меня на последнем лаптопе Skylake процессор без AVX).
кт>Таким образом, проблема обратной совместимости объективно существует, и решать ее иногда приходится. Но если в первых двух приведенных примерах решение было остроумным, и главное, скрытым для пользователей, которым эта совместимость ни к чему, то в двух последних примерах попытка совместимости (на мой взгляд, надуманная!) привела к вычурным аппаратным решениям и породила проблемы. Причем совместимость уже тогда гораздо лучше обеспечивалась специально разработанным режимом виртуального 8086.
Чем же этот режим помог бы с MMX?
кт>Главной же бедой любой обратной совместимости является то, что с каждым годом пользователей, которым она нужна, все меньше и меньше. А учитывать ее приходится всем.
Вот честно — я не понимаю, зачем Intelʼу до сих пор сохранять старт процессора в 16 битах.
Здравствуйте, netch80, Вы писали:
N>Интересно, сколько им за это отвалили? И на сколько версий продержалась защита?
понятия не имею. Но сам подход прекрасен.
N>В принципе это было малой проблемой, потому что одновременно FPU и MMX в одной программе практически не использовалась,
наоборот, пока оформлялись цвета пикселей с помощью какой-нибудь "сатурнации" можно было бы командами FPU начинать считать следующую сцену. И физически это работало бы одновременно.
N>Чем же этот режим помог бы с MMX?
Имелась ввиду 16-разрядная адресация
N>Вот честно — я не понимаю, зачем Intelʼу до сих пор сохранять старт процессора в 16 битах.
Потому, что в момент старта никаких таблиц селекторов-дескрипторов еще нет, а такая адресация всегда готова к работе.
Здравствуйте, netch80, Вы писали:
N>Правда, тот AVX не везде (у меня на последнем лаптопе Skylake процессор без AVX).
Он намного больше "не везде", чем кажется — хотя появился уже лет 10 назад, но в массовом софте ты его не увидишь. И все благодаря обратной совместимости, ради нее все оптимизируют софт хорошо если под SSE-SSE2.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
N>>Правда, тот AVX не везде (у меня на последнем лаптопе Skylake процессор без AVX).
Ops>Он намного больше "не везде", чем кажется — хотя появился уже лет 10 назад,
Хм... 2011Q1 это не 10 лет. (Моменты начала обещаний не подходят.)
И кода, написанного по принципу "выбираем одну из 100500 реализаций согласно фичам процессора, только меняем указатели на функции" вокруг дофига. В видео и тому подобном.
Intel C++ и GCC имеют явную поддержку такого подхода.
Ops> но в массовом софте ты его не увидишь.
Именно что вижу — благодаря выбору на ходу.
Ops> И все благодаря обратной совместимости, ради нее все оптимизируют софт хорошо если под SSE-SSE2.
Под SSE2 это самая общая оптимизация без выбора (на уровне умолчаний компилятора).
Особые случаи — kdb+, например (у нас она активно в ходу) посылает нафиг при отсутствии SSE4.2, fallbackʼа не предоставляет.
Здравствуйте, кт, Вы писали:
N>>В принципе это было малой проблемой, потому что одновременно FPU и MMX в одной программе практически не использовалась, кт>наоборот, пока оформлялись цвета пикселей с помощью какой-нибудь "сатурнации" можно было бы командами FPU начинать считать следующую сцену. И физически это работало бы одновременно.
Ну, я опирался на отзывы игрописателей тех времён. Возможно, некоторые вещи можно было бы резко облегчить с одновременным FPU+MMX, не буду спорить. Хотя ещё лучше бы они убрали стек при переходе в 32-битный режим.
N>>Чем же этот режим помог бы с MMX? кт>Имелась ввиду 16-разрядная адресация
Не понял связи.
N>>Вот честно — я не понимаю, зачем Intelʼу до сих пор сохранять старт процессора в 16 битах. кт>Потому, что в момент старта никаких таблиц селекторов-дескрипторов еще нет, а такая адресация всегда готова к работе.
Ну так ради этого можно было запилить какое-то умолчание без таблиц в памяти. Они и бо́льшие костыли пилили просто на ровном месте.
Здравствуйте, netch80, Вы писали:
N>Хотя ещё лучше бы они убрали стек при переходе в 32-битный режим.
Говорят, фильм для дураков. А мне нравится. (с)
А мне нравится. И транслятору есть где пооптимизировать.
N>>>Чем же этот режим помог бы с MMX? кт>>Имелась ввиду 16-разрядная адресация N>Не понял связи.
В режиме виртуального 8086 нет никакой 20 линии в принципе. Какой чудак вообще привязался к этой линии, останется тайной.
N>Ну так ради этого можно было запилить какое-то умолчание без таблиц в памяти. Они и бо́льшие костыли пилили просто на ровном месте.
Так сегмент+смещение и есть то самое умолчание и добавлять ничего не нужно. Не все ли равно как выглядят первые 100-200 команд после включения процессора?
Здравствуйте, netch80, Вы писали:
N>Под SSE2 это самая общая оптимизация без выбора (на уровне умолчаний компилятора).
N>Особые случаи — kdb+, например (у нас она активно в ходу) посылает нафиг при отсутствии SSE4.2, fallbackʼа не предоставляет.
Недавно была новость, что FF в ближайших версиях перестанет работать на процессорах без поддержки SSE2, хром это сделал в 14 году. Вот это — массовый софт, а не kdb+
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, кт, Вы писали:
N>>Хотя ещё лучше бы они убрали стек при переходе в 32-битный режим. кт>Говорят, фильм для дураков. А мне нравится. (с) кт>А мне нравится. И транслятору есть где пооптимизировать.
Что в этой кривизне может нравиться? Возможность выстрелить себе в ногу на ровном месте? Необходимость транслятору реализовывать в себе хаки для поддержки стека на регистрах?
N>>>>Чем же этот режим помог бы с MMX? кт>>>Имелась ввиду 16-разрядная адресация N>>Не понял связи. кт>В режиме виртуального 8086 нет никакой 20 линии в принципе. Какой чудак вообще привязался к этой линии, останется тайной.
Если речь про необходимость её включения, то 704KB вместо 640KB нужны независимо от того, это чисто реальный режим или v8086.
Если про возможность её отключения... вот тут не знаю. В вики пишут, что если не отключать — ломались какие-то важные программы.
N>>Ну так ради этого можно было запилить какое-то умолчание без таблиц в памяти. Они и бо́льшие костыли пилили просто на ровном месте. кт>Так сегмент+смещение и есть то самое умолчание и добавлять ничего не нужно. Не все ли равно как выглядят первые 100-200 команд после включения процессора?
Не всё равно, когда на них нужен свой декодер и конвейер. И только начиная с AVX стали делать команды, которые в принципе не известны 16-битному декодеру.
Здравствуйте, Ops, Вы писали:
N>>Под SSE2 это самая общая оптимизация без выбора (на уровне умолчаний компилятора). N>>Особые случаи — kdb+, например (у нас она активно в ходу) посылает нафиг при отсутствии SSE4.2, fallbackʼа не предоставляет. Ops>Недавно была новость, что FF в ближайших версиях перестанет работать на процессорах без поддержки SSE2, хром это сделал в 14 году.
Ну, неудивительно. В 64 битах SSE2 вообще по умолчанию. В 32 — есть варианты, но, по-моему, даже атомы сейчас его умеют (хотя ещё вопрос, насколько стабильно шустро).
То, что я собираю у себя локально из исходников, сейчас имеет по умолчанию "-march=pentium4 -msse -msse2", даже самые глубоко системные штучки. Это таки помогает, даже если оно только быстрое копирование делает через SSE.
Ops> Вот это — массовый софт, а не kdb+
Не передёргивай. Открыто было сказано, что массовый софт — это всякие видеоплееры.
Здравствуйте, netch80, Вы писали:
N>Ну, неудивительно. В 64 битах SSE2 вообще по умолчанию. В 32 — есть варианты, но, по-моему, даже атомы сейчас его умеют (хотя ещё вопрос, насколько стабильно шустро).
Я почему-то думал, что SSE2 и больше уже точно лет 10 умеют вообще все. Только речь о том, что до сих пор тащили совместимость с еще более старыми. N>То, что я собираю у себя локально из исходников, сейчас имеет по умолчанию "-march=pentium4 -msse -msse2", даже самые глубоко системные штучки. Это таки помогает, даже если оно только быстрое копирование делает через SSE.
Никто не собирает ничего "у себя локально из исходников", только гики.
N>Не передёргивай. Открыто было сказано, что массовый софт — это всякие видеоплееры.
Не нравится хром как массовый софт? Ну спроси в шароваре, многие ли дропнули у себя поддержку древностей.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
N>>Ну, неудивительно. В 64 битах SSE2 вообще по умолчанию. В 32 — есть варианты, но, по-моему, даже атомы сейчас его умеют (хотя ещё вопрос, насколько стабильно шустро). Ops>Я почему-то думал, что SSE2 и больше уже точно лет 10 умеют вообще все. Только речь о том, что до сих пор тащили совместимость с еще более старыми.
Только если ты спросиш Intel, можно ли считать, что SSE{1,2} будет везде и всегда, получиш посыл нафиг к документации, что никаких гарантий никто не даст в принципе, и что всегда надо проверять.
N>>Не передёргивай. Открыто было сказано, что массовый софт — это всякие видеоплееры. Ops>Не нравится хром как массовый софт?
Опять странные домыслы и нечтение. Даже нет смысла отвечать.
Здравствуйте, netch80, Вы писали:
N>Опять странные домыслы и нечтение. Даже нет смысла отвечать.
Ну конечно. Ты почему-то домыслил, что массовый софт (про который, между прочим, написал я) — это видеоплееры, и пытаешься утверждать, что я чего-то не читаю.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
N>>Опять странные домыслы и нечтение. Даже нет смысла отвечать.
Ops>Ну конечно. Ты почему-то домыслил, что массовый софт (про который, между прочим, написал я) — это видеоплееры,
Тот, которому реально нужны высокие фичи процессоров (AVX и выше) — да, так оно и есть.
Ops> и пытаешься утверждать, что я чего-то не читаю.
Здравствуйте, netch80, Вы писали:
N>Тот, которому реально нужны высокие фичи процессоров (AVX и выше) — да, так оно и есть.
Вот это неплохо бы чем-то подкрепить. А то видеоплееры у меня уже много лет не тормозили, в т.ч. на старом железе (недавно заменил 8-9 летний комп, который и при покупке был совсем не топовый), а вот браузеры постоянно притормаживают.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
N>>Тот, которому реально нужны высокие фичи процессоров (AVX и выше) — да, так оно и есть.
Ops>Вот это неплохо бы чем-то подкрепить. А то видеоплееры у меня уже много лет не тормозили, в т.ч. на старом железе (недавно заменил 8-9 летний комп, который и при покупке был совсем не топовый),
Ну, если ты не просишь у них воспроизвести FullHD без потерь, то тормозить, наверно, не будут.
А вот с такой просьбой вдруг начинается хотение множества новомодных фишек типа BMI или пропуск кадров. Только учти, что где-то значительно важнее зависимость от кодека и видеокарты (типа, ускорение x.264 она умеет, и целерона достаточно, а x.265 уже дзуськи).
Ops> а вот браузеры постоянно притормаживают.
Браузеры тормозят из-за того, что клиентский жабаскрипт набивают мегабайтами ненужной фигни. Если бы ты им дал бесскриптовую страницу — отработали бы со скоростью её загрузки. А управляющий жабаскрипт AVX-like фичами не ускорить.
Поэтому настояние на SSE для браузера это больше избавление от зависимости от FPU для плавучки, и самые базовые шаблоны ускорения манипуляций с изображением, чем что-то более глубинное.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А ведь всего 25 лет прошло...
Все же тогда прогресс ощущался отчетливее. Я помню, как первый раз в жизни попал на ВЦ. Я классе в пятом учился. И там использовались две ЭВМ: какая-то ламповая, отлаженная и работающая, и новейшая ЕС, не помню, какая. И тогда я впервые увидел, как выглядит память. Кто-то из инженеров менял сгоревшую на годную. Один бит представлял из себя две здоровых лампы, установленных на каком-то мостике. И сотрудники ВЦ мечтали поскорее закончить с запуском ЕС и перевести задачи на нее.
А сейчас вокруг полезных вещей слишком много свистоперделок. Из-за которых и полезность не всегда удается разглядеть.
