> в реалтайме вообще работать с памятью нельзя - только то, что заранее
> выделено и подготовлено. но реалтайм это именно управление двигателем, а не расчет маневра.Это требования не столько по части реалтаймности, сколько по части надежности и предсказуемости. Хотя кроме всего прочего paging на диск может убить и времена отклика, т.к. пока нужной страницы памяти нет - код из нее выполнять невозможно, разумеется. Но на самом деле причина - в том что будет совсем не круто если где-то на середине маневра все встанет колом, "потому что кончилась память". Поэтому особо ответственный софт в всяких МК и прочая - использует статичное выделение памяти.
> а вот не реалтаймовые вещи, типа расчета маневров (которые делаются задолго ДО),
> можно писать на том, что удобно.
Вот только там еще вес - на вес золота. И с электропитанием чаще всего большой напряг - источников энергии в космосе мало и цены на генерацию электричества в космосе - тоже вполне космические. А еще всякие заморочки с radiation hardening. Это означает относительно примитивный процессор, который к тому же не имеет права много кушать и в целом система не может много весить. Поэтому в сумме решить проблему доустановкой пары серверов, как это любят жабисты, будет стоить дороже чем отлить сервер из золота в натуральную величину. И нет, отгрузить все задачи на ЦУП не получится. А что если линк невовремя отвалится?
> PS да и Linux не реалтайм-ОС, так что для реального времени нужно
> весь стек технологий тянуть - от железа и ОС до программ.
Вообще-то, есть и реалтаймная версия линуха. Вон целое московское метро внедряет, если что. Конечно не космос, и не наносекундный реалтайм, но ПЛК обслуживающий нужды метро - это ответвенно и реалтаймно. Так что вот не надо тут лить воды на пингвинов, они могут летать, если пнуть посильнее...
> И даже СУБД нужно подгонять под реалтийм... или не применять СУБД,
> что, наверное, правильно. ИМХО.
А про это помнится неплохо писали яндекс + перцы из московского метро. Там они рассказали что и как они делали.
