В комментах разразилась куча споров о том что надо читать документацию, надо проверять ошибки. Но как будто никого не смущает что это очевидная ошибка дизайна — невалидное значение pid_t, возвращаемое из fork, является вполне себе валидным для kill:
pid_t fork(void);
int kill(pid_t pid, int sig);
И там и там pid_t. По идее fork должен возвращать не pid_t а что-то вроде pid_or_invalid_t, так чтобы невалидное значение не могло быть преобразованно к pid_t без сигнала ошибки.
То что man читать надо, это и так понятно.
Марсоход по массе почти в два раза тяжелее китайских луноходов «Юйту» и в четыре раза легче «Спирита/Оппортьюнити», которые сели на Марс в январе 2004.
Судя по открытым данным «Спирит/Оппортьюнит» имеют массу по 185 кг, Юйту — 140 кг. В вашей статье масса марсохода указанна как 250 кг (в английской и китайской вики 240 кг). Что-то не вяжется.
Может сравнение все-таки с Кьюриосити (899 кг)?
Читал когда-то статью о методе сильного снижения эффективности аппаратного шифрования путем криогенной заморозки контроллера — встроенному генератору случайных чисел становилось не откуда брать «случайность». Было бы интересно посмотреть на эффективность комбинированной атаки
Сами атаки на пропуск инструкции кажутся мне крайне серьезными, а защита от атаки крайне слабой — без использования случайных задержек в голову приходят только проверки паролей с поэтапным вычислением хеша так, чтобы пропуск любого этапа делал хеш не валидным.
Но это разве принципиально? ОСРВ-совместимых процессоров много, даже среди радстойких есть выбор. Да даже среди радстойких и не очень дорогих есть выбор)
О, может подскажете что-нибудь? Даже не представляю где можно обывателю приобрести такой, видел решения от st утверждается pin-to-pin совместимость, но не нашел даже четкой информации о ценнике и том как приобрести.
Что по поводу моего вопроса к коту — мне просто интересно. Люблю технические детали:)
Значит будем ждать вашего главного отчёта, чем вам не угодили существующие варианты. Мне-то этот вопрос интерестен.
Кстати вы уже определились о том что будет в основе БКУ, какой процессор?
На вашем месте яб посмотрел на альтернативы внимательней. Объем кода некоторых приложений nasa, которые вроде бы должны быть простыми, намекает ( https://sourceforge.net/projects/cfs-cfdp/reviews ). А вы вроде говорите что ресурсов у вас не много.
Просто получается что решение, претендующее на универсальность есть, а вы все равно решаете делать свое решение, и непонятно чем обоснованно это.
Дак Линукс — это даже не начало — это начала начала. Речь о том что проект nasa уже содержит в себе часть базовых программ платформы (если надо могу дать ссылки на соответствующие презентации/программы). Линукс же — это только ядро, и ничего больше. Получается все базовые программы вам делать самим.
Вы про open source или про сам фреймворк? Если речь о фреймворке — процессы разработки-отладки-тестирования у нас не на много хуже. Зачастую конечно это существует для странных* процессоров, и странных ОСРВ, но суть примерно одинакова. Сложности всегда в бюрократизации процесса, когда-то давно была статья про разработку ПО для самолетов — примерно такой же подход.
Если речь об opensource — это не возможно в текущих реалиях. Не потому что у нас такие-сякие, а потому что nasa — чисто государственная организация, и она должна публиковать результаты своей деятельности. Основные разработчики ПО БКУ у нас — МАРС, Энергия и ИСС делают его для себя. И это — коммерческие компании, пусть и с государственной долей. Вы же не ждете такого подхода от, например, Боинг?
*странных — в смысле не очень распространенных и закрытых для обывателя
cfs.gsfc.nasa.gov
У nasa отличный подход в этом плане, давно внедряют. Тут и кросс-разработка, и набор «стандартных приложений» и другие фишки. Все для микроспутникостроителей. И opensource конечно, хотя насовскую лицензию еще поразбирать надо.
Почему все привязались именно к НК-33… Что бы там не говорилось в новости — повторять двигатель в точности никто не будет, не надо понимать эти действия буквально. Если мы говорим о какой-либо экономической целесообразности, о чем S7 как раз все время и твердит — это будет производный продукт, а никак не точная копия. Продукт созданный с современными реалиями. Никто в здравом уме не будет использовать старую систему управления — она не эффективна. Материалы старые не будут использоваться — они уже давно не производятся (те же припои с которыми погорел Хруничев — устаревают и перестают выпускаться). Восстановить производственную цепочку полностью — нереально и не целесообразно. Посмотрят документацию, разберутся, пообщаются с инженерами — и в итоге сделают свое, пусть похожее, может даже с таким же названием — но не в точности то самое. Возможно сам Сопов этого еще не понимает, но на практике будет именно так — иное нереально даже с их деньгами.
В сложившихся условиях это самая правильная стратегия — не разрабатывать свое с нуля, а воспользоваться существующим заделом. На коммерческих рельсах его скорее всего получится сделать эффективней с точки зрения цена-качество (ведь по сути это ведь все равно будет другой двигатель, пусть и имеющий корни у старого)
CorneliusAgrippa самый главный вопрос — когда? После вашего поста про организацию производства в Москве новостей особо не появлялось. На сайтах тоже ничего особенного. Расскажите, на каком этапе находится создание промышленной установки? Чем сейчас занимается завод в Москве, неужели все два года на электронные линзы ушли?
Считаю что безмасочные технологии могут просто перевернуть рынок, особенно если получится быстро адаптировать их под производство радстойкой электроники — нормальные ПЛИСы у нас делать явно не хотят, возможно такая технология позволила бы делать радстойкие схемы значительно дешевле и быстрее, чем изготавливать маски для БМК. А это дало бы качественный рывок нашей космонавтике — сейчас без ПЛИС из США даже мирные научные миссии не могут запустить
Вот только в аварийном режиме Dragon должен иметь возможность сесть не только во флориде и в аварийной ситуации никто не будет выбирать садиться заснеженную степь или пустыню. Хотя конечно в капсуле можно разное добро на такой случай разместить, спасательные одеяла, к примеру, двуцветные бывают — с одной стороны серебряные, с другой — золотые.
Ну, в кубсатах обычно нет дублирования, коммерческая электронная база, и вообще он во много раз проще и глупее большой геостационарной платформы (хотя если сравнивать только служебные вычислительные системы спутников то разница в производительности не большая). Да, там реально может стоять матрица от зеркалки. Конечно не с совсем уж мыльницы, и не такая уж и обычная, допиленная для большей устойчивости к вибрациям и т.п., но вполне доступная за вменяемые деньги.
Ваш один прибор помимо прочего наверняка внутренне сдублирован (если не строирован), куча гальванической развязки, еще и корпус крутой, и термоинтерфейс какой-нибудь есть. Там все значительно проще. Вот вам аппарат, к примеру
Не берусь отвечать за историческую точность, но благодаря транссибу множество предприятий во время войны было эвакуировано из центральной части России. Думаю это чего-то да стоит.
Дело не только в количестве ресурсов, дело в самом определении термина. Встраиваемые системы обычно не контактируют с человеком, работают при минимуме обслуживания, в случаях когда человек просто не в состоянии выполнить задачу (из-за времени реакции или по другим причинам). Именно по этому необходима большая аккуратность при проектировании таких систем.
И сборщики мусора не могут гарантировать что вся не нужная память будет освобождена (достаточно вспомнить про ошибки потери указателя на событие в C# — если забыть отменить делегату подписку то он будет сидеть в списке до скончания времен. Как и вся зависимая от этого делегата память — ссылка-то сохранилась). + они добавляют непредсказуемости — не знаешь когда он запустится и на что он повлияет. Да, есть сборщики мусора реального времени, но когда они выйдут из исследовательских статей в массы одному root-у известно… А с другой стороны — есть ли в этом смысл? Ведь требования аккуратности и обработке ошибок никуда не пропадают.
В общем «встраиваемость» — это раньше было про дефицит ресурсов. Сейчас, кажется, краеугольной частью «встраиваемости» является «необслуживаемость».
Не думаю, что установка одного концевика сильно усложнит проектирование
Вы удивитесь…
Вообще электронщики, как вы и говорили изначально, считают что задача плевая и зависнуть там ничего не может. Вот и не добавляют лишних деталей. И проблема действительно простая — если производить тестирование кода и как следует изолировать код от аппаратуры (ибо она, как я уже говорил, меняется со временем. Да и нельзя нормально тестировать код с большим количеством внешних зависимостей). Но, как и во всех программистских областях, заказчики считают что код простой и то, что его надо тестировать и поддерживать во внимание не берут, все нужно доказывать, а большинству разработчиков не хочется бодаться с заказчиком, который с радостью сменит прогера на более сговорчивого. Вот и получаются таки монстры с 81k нарушений…
pid_t fork(void);
int kill(pid_t pid, int sig);
И там и там pid_t. По идее fork должен возвращать не pid_t а что-то вроде pid_or_invalid_t, так чтобы невалидное значение не могло быть преобразованно к pid_t без сигнала ошибки.
То что man читать надо, это и так понятно.
Судя по открытым данным «Спирит/Оппортьюнит» имеют массу по 185 кг, Юйту — 140 кг. В вашей статье масса марсохода указанна как 250 кг (в английской и китайской вики 240 кг). Что-то не вяжется.
Может сравнение все-таки с Кьюриосити (899 кг)?
Сами атаки на пропуск инструкции кажутся мне крайне серьезными, а защита от атаки крайне слабой — без использования случайных задержек в голову приходят только проверки паролей с поэтапным вычислением хеша так, чтобы пропуск любого этапа делал хеш не валидным.
О, может подскажете что-нибудь? Даже не представляю где можно обывателю приобрести такой, видел решения от st утверждается pin-to-pin совместимость, но не нашел даже четкой информации о ценнике и том как приобрести.
Что по поводу моего вопроса к коту — мне просто интересно. Люблю технические детали:)
Значит будем ждать вашего главного отчёта, чем вам не угодили существующие варианты. Мне-то этот вопрос интерестен.
Кстати вы уже определились о том что будет в основе БКУ, какой процессор?
На вашем месте яб посмотрел на альтернативы внимательней. Объем кода некоторых приложений nasa, которые вроде бы должны быть простыми, намекает ( https://sourceforge.net/projects/cfs-cfdp/reviews ). А вы вроде говорите что ресурсов у вас не много.
Просто получается что решение, претендующее на универсальность есть, а вы все равно решаете делать свое решение, и непонятно чем обоснованно это.
Дак Линукс — это даже не начало — это начала начала. Речь о том что проект nasa уже содержит в себе часть базовых программ платформы (если надо могу дать ссылки на соответствующие презентации/программы). Линукс же — это только ядро, и ничего больше. Получается все базовые программы вам делать самим.
Если речь об opensource — это не возможно в текущих реалиях. Не потому что у нас такие-сякие, а потому что nasa — чисто государственная организация, и она должна публиковать результаты своей деятельности. Основные разработчики ПО БКУ у нас — МАРС, Энергия и ИСС делают его для себя. И это — коммерческие компании, пусть и с государственной долей. Вы же не ждете такого подхода от, например, Боинг?
*странных — в смысле не очень распространенных и закрытых для обывателя
У nasa отличный подход в этом плане, давно внедряют. Тут и кросс-разработка, и набор «стандартных приложений» и другие фишки. Все для микроспутникостроителей. И opensource конечно, хотя насовскую лицензию еще поразбирать надо.
Считаю что безмасочные технологии могут просто перевернуть рынок, особенно если получится быстро адаптировать их под производство радстойкой электроники — нормальные ПЛИСы у нас делать явно не хотят, возможно такая технология позволила бы делать радстойкие схемы значительно дешевле и быстрее, чем изготавливать маски для БМК. А это дало бы качественный рывок нашей космонавтике — сейчас без ПЛИС из США даже мирные научные миссии не могут запустить
Ваш один прибор помимо прочего наверняка внутренне сдублирован (если не строирован), куча гальванической развязки, еще и корпус крутой, и термоинтерфейс какой-нибудь есть. Там все значительно проще. Вот вам аппарат, к примеру
И сборщики мусора не могут гарантировать что вся не нужная память будет освобождена (достаточно вспомнить про ошибки потери указателя на событие в C# — если забыть отменить делегату подписку то он будет сидеть в списке до скончания времен. Как и вся зависимая от этого делегата память — ссылка-то сохранилась). + они добавляют непредсказуемости — не знаешь когда он запустится и на что он повлияет. Да, есть сборщики мусора реального времени, но когда они выйдут из исследовательских статей в массы одному root-у известно… А с другой стороны — есть ли в этом смысл? Ведь требования аккуратности и обработке ошибок никуда не пропадают.
В общем «встраиваемость» — это раньше было про дефицит ресурсов. Сейчас, кажется, краеугольной частью «встраиваемости» является «необслуживаемость».
Вы удивитесь…
Вообще электронщики, как вы и говорили изначально, считают что задача плевая и зависнуть там ничего не может. Вот и не добавляют лишних деталей. И проблема действительно простая — если производить тестирование кода и как следует изолировать код от аппаратуры (ибо она, как я уже говорил, меняется со временем. Да и нельзя нормально тестировать код с большим количеством внешних зависимостей). Но, как и во всех программистских областях, заказчики считают что код простой и то, что его надо тестировать и поддерживать во внимание не берут, все нужно доказывать, а большинству разработчиков не хочется бодаться с заказчиком, который с радостью сменит прогера на более сговорчивого. Вот и получаются таки монстры с 81k нарушений…