Здравствуйте, Cyberax, Вы писали:

C>Оказывается, что UI в капсуле сделан на Chromium + JS, работающих на Линуксе.
"Мы его слепили из того что было, а потом что было то и запулили" (С)
То то он так сурово лагал.

Здравствуйте, anonymous, Вы писали:

A>Иногда управляют. При ручной стыковке, например.
А там есть возможность ручной стыковки? Вряд ли её удобно управлять нажимая на сенсорный экран. Должно быть что-то наподобие джойстика, не заметил на видео, может где-нибудь в ручке кресла спрятано

Здравствуйте, pagid, Вы писали:

A>>Иногда управляют. При ручной стыковке, например.
P>А там есть возможность ручной стыковки? Вряд ли её удобно управлять нажимая на сенсорный экран. Должно быть что-то наподобие джойстика, не заметил на видео, может где-нибудь в ручке кресла спрятано

Симулятор стыковки, который доступен в Сети, как раз про ручную стыковку.

Здравствуйте, Cyberax, Вы писали:

C>У них есть несколько физических переключателей, для выпуска парашюта и ещё чего-то. Но всё остальное — на JS, да.
Как они должны догадаться, что парашют уже пора выпускать? По команде которую покажут в браузере?

vsb>>Летать-то может и летает. Вопрос не в том, летает ли. Вопрос в том, насколько надёжно летает.
P>Так UI же. Ну сбросится при необходимости и снова загрузится и нарисуется Какие проблемы? Подождут. Космонавты же не управляют кораблем как летчики самолетом.

Смотря что в этом UI выводится. Какие-нибудь показатели расхода топлива или кислорода не могут ждать, пока UI «сбросится при необходимости и снова загрузится».

C>Но это ещё не всё. Оказывается, что UI в капсуле сделан на Chromium + JS, работающих на Линуксе.
И показывает он очевидно анимированную GIF'ку

Здравствуйте, Mamut, Вы писали:

vsb>>>Летать-то может и летает. Вопрос не в том, летает ли. Вопрос в том, насколько надёжно летает.
P>>Так UI же. Ну сбросится при необходимости и снова загрузится и нарисуется Какие проблемы? Подождут. Космонавты же не управляют кораблем как летчики самолетом.
M>Смотря что в этом UI выводится. Какие-нибудь показатели расхода топлива или кислорода не могут ждать, пока UI «сбросится при необходимости и снова загрузится».
А почему подразумевается, что интерфейс на каком-нибудь там Qt или C# непременно будет хоть сколько-то надёжнее? По крайней мере в браузере UI можно хотя бы перезагрузить, в отличие от.
Самое плохое, что я могу придумать — браузер выжрет 100Мб памяти, в отличие от Qt, который будет раз в 10 меньше. Только я не очень понимаю кого это должно беспокоить в данном случае и почему.

Здравствуйте, ·, Вы писали:

·>А почему подразумевается, что интерфейс на каком-нибудь там Qt или C# непременно будет хоть сколько-то надёжнее?

Как минимум потому, что размер кодовой базы Qt несравненно меньше размера кодовой базы браузера.

.> По крайней мере в браузере UI можно хотя бы перезагрузить, в отличие от.

Что мешает перезапустить приложение на Qt?

·>Самое плохое, что я могу придумать — браузер выжрет 100Мб памяти, в отличие от Qt, который будет раз в 10 меньше.

А я могу придумать какие-нибудь глюки. Повёл он пальцем, а там вместо тач евентов сгенерировались какие-нибудь зум евенты, окно браузера переколбасило и это в последние секунды до стыковки.

Впрочем я не агитирую за Qt. На мой взгляд для таких вещей должна использоваться отдельная ОС (например vxworks) и весь код должен писаться и верифицироваться с нуля.

BB>Это запредельное ушлёпство, лепить "модное молодёжное" говно, туда где нужна ось реального времени и особо тщательные верификация и тестирование.
BB>Насколько я понял, на корабле физических тумблеров уже нет, остались только жабаскриптовые?..
Говорят все что нуна продублировано физ тумблерами без жаваскрипта внутри: https://www.youtube.com/watch?v=J5VECXgTpWk

Здравствуйте, ·, Вы писали:

M>>Смотря что в этом UI выводится. Какие-нибудь показатели расхода топлива или кислорода не могут ждать, пока UI «сбросится при необходимости и снова загрузится».
·>А почему подразумевается, что интерфейс на каком-нибудь там Qt или C# непременно будет хоть сколько-то надёжнее?
Ну, тут хоть надежда есть, что люди занимались именно надежностью https://doc.qt.io/QtSafeRenderer/qtsr-overview.html
M>>По крайней мере в браузере UI можно хотя бы перезагрузить, в отличие от.
И что же мешает это сделать в C++ или C#?
·>Самое плохое, что я могу придумать — браузер выжрет 100Мб памяти, в отличие от Qt, который будет раз в 10 меньше. Только я не очень понимаю кого это должно беспокоить в данном случае и почему.
Съест больше, процессора потратит больше, энергии нужно отвести больше.

Здравствуйте, vsb, Вы писали:

vsb>·>А почему подразумевается, что интерфейс на каком-нибудь там Qt или C# непременно будет хоть сколько-то надёжнее?
vsb>Как минимум потому, что размер кодовой базы Qt несравненно меньше размера кодовой базы браузера.
Зато юзерская база и варианты использования ещё более несравненно больше.
Очень спорный подход оценивать надёжность продукта по LoC.

.>> По крайней мере в браузере UI можно хотя бы перезагрузить, в отличие от.
vsb>Что мешает перезапустить приложение на Qt?
У браузера песочница меньше, да и приложение не на нативном языке, а значит UB и расстрелов памяти нет.

vsb>·>Самое плохое, что я могу придумать — браузер выжрет 100Мб памяти, в отличие от Qt, который будет раз в 10 меньше.
vsb>А я могу придумать какие-нибудь глюки. Повёл он пальцем, а там вместо тач евентов сгенерировались какие-нибудь зум евенты, окно браузера переколбасило и это в последние секунды до стыковки.
Эээ.. И? Qt будет надёжнее, т.к. не умеет зум евенты или что?
Ты придумай не какие-нибудь глюки, а какие-то такие, которые релевантны для браузера, но не в Qt.

vsb>Впрочем я не агитирую за Qt. На мой взгляд для таких вещей должна использоваться отдельная ОС (например vxworks) и весь код должен писаться и верифицироваться с нуля.
Верификация увеличит стоимость и время разработки на порядок-два... Мы же говорим о UI. и фиг знает даст ли это какие-то преимущества в UI. Что можно верифицировать в UI? Что юзер палцы водит правильно?

Cyberax:

A>>Во-первых, это всего лишь UI, и к нему нет требований жесткого реального времени и атомной надежности. Ядро летательного аппарата очевидно работает на других (разных) технологиях с тройным резервированием. Поэтому даже если UI будет перезапущен, это никак не отразится на летных функциях аппарата.
C>Компьютер с UI у них тоже троирован.
Так и представляю, нужно какое-то срочное ручное действие по пилотировнию, в это время один экземпляр компьютера занимается сборкой мусора, второй яростной своппит, а третий стучит в АНБ

А если серьёзно, если софт сделан криво, его не спасёт ни дублирование, ни троирование. Вот инцидент со сбоем на ракете Ариан — компьютер перестает что-либо понимать, отключается, вступает в работу следующий и также отключается и т.д.

А с радиационной стойкостью как? А носители там не флеш по 50 бит на ячейку?

Aquilaware:

A>А вот JavaScript — на данный момент просто среда выполнения. Одна из. Как язык, JavaScript не очень годится для сложных приложений (нет типизации). А вот как среда выполнения — он имеет смелое и производительное LISP-сердце. Но никто не заставляет вас использовать JavaScript, если вы используете HTML как стандартный UI тулкит. Вам будет проще и удобнее использовать тот язык, на котором написано ваше приложение.

Прошивку на машинном языке можно подвергнуть статическому анализу, как ручному, так и автоматическому.
Поскольку реакция на каждую команду известна.
Можно выявить возможные лаги, неопределенное поведение и много чего еще.
С лишней прослойкой, вроде JS, такого уже не сделаешь, появляется большой класс ошибок и неопределенностей.
А работа с памятью? Где гарантия, что сборка мусора не произойдёт в критический момент?

А банальная надёжность? Браузеры еще как падают. А безопасность?

Здравствуйте, pagid, Вы писали:

C>>У них есть несколько физических переключателей, для выпуска парашюта и ещё чего-то. Но всё остальное — на JS, да.
P>Как они должны догадаться, что парашют уже пора выпускать? По команде которую покажут в браузере?
Видимо, по хронометражу. Это резервный переключатель, на случай отказа вообще всего.

Здравствуйте, Bill Baklushi, Вы писали:

BB>Прошивку на машинном языке можно подвергнуть статическому анализу, как ручному, так и автоматическому.
Кто мешает анализировать JS?

BB>Можно выявить возможные лаги, неопределенное поведение и много чего еще.
BB>С лишней прослойкой, вроде JS, такого уже не сделаешь, появляется большой класс ошибок и неопределенностей.
BB>А работа с памятью? Где гарантия, что сборка мусора не произойдёт в критический момент?
Я не припомню, чтобы сборка мусора в браузере как-то влияла на отзывчивость.

BB>А банальная надёжность? Браузеры еще как падают. А безопасность?
Думаю, что астронавты с экранов управления на Порнхаб не заходят.

Здравствуйте, Mamut, Вы писали:

M>Смотря что в этом UI выводится. Какие-нибудь показатели расхода топлива или кислорода не могут ждать, пока UI «сбросится при необходимости и снова загрузится».
Почему не могут? Что должны и могли бы сделать космонавты за считанные секунды, если вдруг бы увидели, что топливо и кислород закончились
Есть конечно одна ситуация — куда-то очень очень понятно и наглядно должна выводится команда "надеть шлем" в случае разгерметизации или какого-нибудь выброса гидразина в кабину. Только боюсь, что в традиционной космонавтике, она проходит даже мимо процессора БЦВМ, прямо с датчиков на транспарант. А тут да, через Chromium + JS

·>А почему подразумевается, что интерфейс на каком-нибудь там Qt или C# непременно будет хоть сколько-то надёжнее?

А почему подразумевается, что интерфейс обязательно должен быть на Qt или C#?

·>По крайней мере в браузере UI можно хотя бы перезагрузить, в отличие от.

Действительно, перезагрузить интерфейс возможно строго и исключительно в браузере.

·>Самое плохое, что я могу придумать — браузер выжрет 100Мб памяти, в отличие от Qt, который будет раз в 10 меньше. Только я не очень понимаю кого это должно беспокоить в данном случае и почему.

Самое плохое, что можно придумать — это браузер зависнет в ключевой момент.

P>Почему не могут? Что должны и могли бы сделать космонавты за считанные секунды, если вдруг бы увидели, что топливо и кислород закончились

Не «закончились», а «заканчивается» или «расход выше расчетного» или «миллион прочих важных вещей, отклик от которых не может подождать».

P>Есть конечно одна ситуация

Есть конечно множество ситуаций.

Здравствуйте, Cyberax, Вы писали:

C>Видимо, по хронометражу. Это резервный переключатель, на случай отказа вообще всего.
Тогда получается, что у них перед глазами должен быть... э-э-э... видимо хронометр, работающий независимо от всего, оно же все отказало.

BB>>А работа с памятью? Где гарантия, что сборка мусора не произойдёт в критический момент?
C>Я не припомню, чтобы сборка мусора в браузере как-то влияла на отзывчивость.

Прямо у самого гугла есть целая страница по куче проблем, которые могут возникнуть с JS https://developers.google.com/web/tools/chrome-devtools/memory-problems

Про GC в самом конце:

If your page appears to pause frequently, then you may have garbage collection issues.

You can use either the Chrome Task Manager or Timeline memory recordings to spot frequent garbage collections. In the Task Manager, frequently rising and falling Memory or JavaScript Memory values represent frequent garbage collections. In Timeline recordings, frequently rising and falling JS heap or node count graphs indicate frequent garbage collections.

Once you've identified the problem, you can use an Allocation Timeline recording to find out where memory is being allocated and which functions are causing the allocations.