Ikemefula:
BB>>Есть разница между проанализировать время исполнения набора машинных инструкций и непонятного интерпретируемого кода? BB>>Предсказать время выполнения и для JS можно но дело в точности. I>Набор машинных инструкций никакому анализу не поддаётся. Это стало понятно еще где то в 50х.
Прямо таки никакому?
Проблема остановки в том, что нет общего алгоритма семантического анализа кода. О некоторых конкретных классах программ можно много чего сказать.
Например, если подпрограмма без вызовов и ветвлений — можно довольно точно оценить время ее выполнения (не считая кэширования, прерываний и пр.).
Ikemefula:
BB>>Прошивку на машинном языке можно подвергнуть статическому анализу, как ручному, так и автоматическому. BB>>Поскольку реакция на каждую команду известна. BB>>Можно выявить возможные лаги, неопределенное поведение и много чего еще.
I>Можно. А еще можно пропустить бОльшую часть, что и происходит.
Ога. А с лишней прослойкой ошибок вдруг не станет?..
BB>>С лишней прослойкой, вроде JS, такого уже не сделаешь, появляется большой класс ошибок и неопределенностей.
I>Эта прослойка исключает целые классы ошибок связаных с памятью.
Ха-ха. А случай когда JS выжрет всю память почему исключается?
Сборка мусора в реалтаймовых системах это очень сомнительная идея.
А ошибки refcounting-а в сторонних компонентах?
Ну и "исключает целые классы ошибок связаных с памятью" ценой внесения трудноуловимых ошибок с динамической типизацией.
BB>>А работа с памятью? Где гарантия, что сборка мусора не произойдёт в критический момент?
BB>>А банальная надёжность? Браузеры еще как падают.
I>Падают, как и любой софт. Чем нативнее, тем чаще падает.
Не так.
Чем меньше лишних говнопрослоек — тем проще код.
Чем проще код — тем проще обеспечить надёжность.
>>А безопасность? I>Дыр в нативно писаном софте всегда вагон и маленькая тележка. Браузер не исключение.
О чем я и говорю, нафиг браузер из критического софта.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Союз, к примеру, изначально проектировался с проработкой по возможности большего количества ситуаций что что то пошло не так. С возможностью ручной коррекции в таких ситуациях, если оно в принципе возможно. И самые опасные участки это вывод на орбиту и спуск.
При выведении всё нештатное происходит так быстро, что человек не успеет даже осознать происходящее. Где-то читал, что на недавней аварии Союза от аварии до срабатывания САС прошло 0.3 сек. Даже очень хорошо подготовленный человек имеет время реакции порядка 100-150 мс.
Поэтому в нормальных ПК весь вывод на орбиту на 100% автоматизирован, в том числе все возможные сценарии спасения.
При спуске после входа в атмосферу мало что можно сделать — ну разве что переключиться на баллистический спуск. Если система термозащиты откажет, то ПК всё равно кирдык, и с этим ничего не сделать (по крайней мере на текущем этапе развития технологий).
НС>Если у Маска любой отказ автоматики в эти моменты означает провал миссии — это очень очень печально.
Я крайне сомневаюсь в том, что НАСА бы одобрила такой подход, особенно в свете МС-10. Да и Маск не самоубийца — он прекрасно понимает, что если угробит экипаж, то мало никому не покажется. У него много врагов во власти, которые из-за него лишаются мегавкусных распилов вроде SLS (Senate Launch System), и они точно раскрутят ситуацию на всю катушку.
Здравствуйте, DenisCh, Вы писали:
DC>Мда... А наши за 6 часов с Земли долетают и стыкуются...
Тем не менее первые испытательные полёты всех существенно новых Союзов всегда были по двухдневной схеме, да ещё и только после неоднократной "обкатке" на Прогрессах.
Кстати, последние Прогрессы уже всего за 2 витка долетали (около 3 часов).
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Аварийное прерывание миссии за пределами участка работы САС (а это довольно большой участок) — означает уничтожение ПН.
Дракон везёт с собой свою САС прямо на орбиту (да ещё потом и обратно на Землю)
Здравствуйте, Cyberax, Вы писали:
C>Ну вот там эта кнопка, скорее всего, и есть.
Скорее всего её (кнопки активации САС) там нет, ввиду полнейшей бесполезности. Время реакции человека категорически неадекватно для любой нештатки при выведении.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Разница в том что высотомер можно термостойкой линзой закрыть, а барометр придется оснащать какими то герметичными шторками, которые открывать где то недалеко от поверхности по сигналу ... с другого высотомера?
Во-первых, барометр можно (и даже нужно) просто открыть против потока, во-вторых, между выходом из плазмы и парашутированием проходит весьма немало времени (посмотри хотя бы любой спуск Союза), так что экипаж вполне может справиться с ручной активацией в случае отказа основных. Ну или использовать банальный акселерометр.
Здравствуйте, koandrew, Вы писали:
НС>>Разница в том что высотомер можно термостойкой линзой закрыть, а барометр придется оснащать какими то герметичными шторками, которые открывать где то недалеко от поверхности по сигналу ... с другого высотомера? K>Во-первых, барометр можно (и даже нужно) просто открыть против потока,
Сбой ориентации (на Союзе такое уже бывало) и прощай барометр?
K> во-вторых, между выходом из плазмы и парашутированием проходит весьма немало времени (посмотри хотя бы любой спуск Союза), так что экипаж вполне может справиться с ручной активацией
Откуда экипаж узнает когда надо активировать, если высотомер не работает?
Здравствуйте, Bill Baklushi, Вы писали:
BB>>>Есть разница между проанализировать время исполнения набора машинных инструкций и непонятного интерпретируемого кода? BB>>>Предсказать время выполнения и для JS можно но дело в точности. I>>Набор машинных инструкций никакому анализу не поддаётся. Это стало понятно еще где то в 50х.
BB>Прямо таки никакому?
Нужен не анализ сам по себе, а определенные гарантии — например, выход за указателя за границы области. Именно с этим уже проблема — на простейшем алгоритме в машинном коде будет куча присваиваний, ветвлений, циклов и тд. Регистровая машина как то иначе работать не умеет. Соответсвенно тупик начинается гораздо раньше, чем при анализе высокоуровневого кода. В высокоуровневом коде можно обойтись без присваиваний и тогда анализатор дает хорошие гарантии в определенных задачах. Это демонстрирует обычный компилятор.
Здравствуйте, Cyberax, Вы писали:
C>Но на земле Windows вполне себе используют в критичных SCADA-системах, которые управляют химическими заводами, ядерными реакторами и электросетями.
Боже, что ты несёшь! Ты бы ознакомился с истоирей атомной энергетики что-ли. Это история ТЫСЯЧ покалеченных и сотен умерших от облучения и отравления. Это история, как люди какой-либо защиты носили закись обогащённого урана вёдрами, без какой-либо защиты. Как этими же вёдрами, своими руками провоцировали цепные реакции, от которых потом и погибли. Если ты думаешь, что это дела давно минувших дней, бородатых 50-х или 60-х прошлого века, я тебя огорчу — нет — это современная история.
"Авария на ядерном объекте Токаймура" — ознакомься!
Если это где-то используют, то это не означает, что это безопасно и надёжно.
ЗЫ: всегда знал, что у веберов какой-то недоразвитый логический аппарат: то им типизация только мешает, то двуг ядерная и химическая промышленность безопасной кажется...
Всё сказанное выше — личное мнение, если не указано обратное.
$>Ну а скептикам "JS умудряется тормозить"- и C++ тормозил и будет тормозить, если не использовать GPU ускорение. Если руки не из жопы, то современные браузеры заливают всё в GPU и всё плавно работает.
ЩИТО!?
Это у кого это руки не из жопы. Покажи таких — не видел.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Aquilaware, Вы писали:
A>И в третьих, HTML сейчас настолько развит, что многократно превосходит многие тулкиты, такие как WPF, хотя еще 5 лет назад это было не так. Ситуация подобна той, когда USB Flash накопители начали превосходить гибкие дискеты (флоппи-диски) в 2000-х. Кто-то оглядывается назад? Нет, кроме коллекционеров и историков.
Прям многократно!?
Как насчёт готовить данные для HTML — JS фрэймворка в соседнем (скажем, третьем) потоке, пока основной поток рисует, а второй занят чтением с диска?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Боже, что ты несёшь! Ты бы ознакомился с истоирей атомной энергетики что-ли. Это история ТЫСЯЧ покалеченных и сотен умерших от облучения и отравления. Это история, как люди какой-либо защиты носили закись обогащённого урана вёдрами, без какой-либо защиты. Как этими же вёдрами, своими руками провоцировали цепные реакции, от которых потом и погибли. Ф>"Авария на ядерном объекте Токаймура" — ознакомься!
Нашел кого удивить такими историями, Cyberax'а
Он как-то сам ссылку давал на сборник подобных историй с подробным разбором.
Здравствуйте, Философ, Вы писали:
C>>Но на земле Windows вполне себе используют в критичных SCADA-системах, которые управляют химическими заводами, ядерными реакторами и электросетями. Ф>Боже, что ты несёшь! Ты бы ознакомился с истоирей атомной энергетики что-ли. Это история ТЫСЯЧ покалеченных и сотен умерших от облучения и отравления.
И это всё из-за JS. Вау!
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Философ, Вы писали:
C>>>Но на земле Windows вполне себе используют в критичных SCADA-системах, которые управляют химическими заводами, ядерными реакторами и электросетями. Ф>>Боже, что ты несёшь! Ты бы ознакомился с истоирей атомной энергетики что-ли. Это история ТЫСЯЧ покалеченных и сотен умерших от облучения и отравления. C>И это всё из-за JS. Вау!
Нет, неверный вывод. Верный такой: в атомной энергетике и в скада можно встретить любую дрянь, в том числе и JS. Практика показывает, что ядерщики таки способны на лютое безумие — способны и JS притянуть туда, где нужна крайняя надёжность и выверенность.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Bill Baklushi, Вы писали:
I>>Можно. А еще можно пропустить бОльшую часть, что и происходит.
BB>Ога. А с лишней прослойкой ошибок вдруг не станет?..
Телепатия тебя подводит.
I>>Эта прослойка исключает целые классы ошибок связаных с памятью. BB>Ха-ха. А случай когда JS выжрет всю память почему исключается?
Это другой класс ошибок и с ними разобраться гораздо проще. Кроме того, консоль это некритичная часть системы, у ней код вобщем простой — обработка нескольких кнопок, по факту.
BB>Сборка мусора в реалтаймовых системах это очень сомнительная идея.
ОМГ! Реалтайм нужен в управляемой системе, а вот требования к консоли гораздо ниже.
BB>А ошибки refcounting-а в сторонних компонентах?
Ошибки рефкаунтинга есть даже без жээса.
BB>Ну и "исключает целые классы ошибок связаных с памятью" ценой внесения трудноуловимых ошибок с динамической типизацией.
I>>Падают, как и любой софт. Чем нативнее, тем чаще падает. BB>Не так. BB>Чем меньше лишних говнопрослоек — тем проще код. BB>Чем проще код — тем проще обеспечить надёжность.
Этого недостаточно. Нативным кодом ты вспотеешь писать такую же консоль управления, далеко не факт, что ошибок будет меньше.
Собтсвенно, в геймдеве уже наелись — теперь почти весь такой вот UI пишется скриптом.
I>>Дыр в нативно писаном софте всегда вагон и маленькая тележка. Браузер не исключение. BB>О чем я и говорю, нафиг браузер из критического софта.
Консоль не является критическим софтом. Выглядит все круто, но на самом деле код там простой. Открой да убедись.
Здравствуйте, Ikemefula, Вы писали:
I>Это сама ракета вот так вот медленно реагирует.
В смысле ткнули в кнопку "Пуск", а она перед тем как взлететь сначала подумала?
Здравствуйте, pagid, Вы писали:
I>>Это сама ракета вот так вот медленно реагирует. P>В смысле ткнули в кнопку "Пуск", а она перед тем как взлететь сначала подумала?
"на видео было видно что реакция на тыкание в экран была довольно медленной"
Реакция медленная — потому что динамика реальной ракеты гораздо медленнее игровой.
Собтсвенно по ссылке именно это и показано — с жээс все в порядке, консоль повторяет динамику реальной ракеты.
