The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

SpaceX использует Linux и обычные x86-процессоры в Falcon 9, opennews (??), 03-Июн-20, (0) [смотреть все] +1

Сообщения [Сортировка по времени | RSS]


185. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Аноним (143), 04-Июн-20, 10:34 
И что же в Rust непредсказуемого относительно управления памятью? Это тебе не Java / C# / Python со сборкой мусора
Ответить | Правка | Наверх | Cообщить модератору

315. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  –2 +/
Сообщение от Аноним (313), 04-Июн-20, 18:22 
> И что же в Rust непредсказуемого относительно управления памятью? Это тебе не
> Java / C# / Python со сборкой мусора

Например MISRA C запрещает динамическое выделение памяти в HEAP. И правильно делает. А вы вообще в состоянии понять упрвление памятью этой штуки чтобы осознать worst case? А то хорошо когда фирмварь запускается - и у нее ну вот вообще совсем не может кончиться память после этого.

Ответить | Правка | Наверх | Cообщить модератору

334. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Forth (ok), 04-Июн-20, 19:07 
Какой штуки? Rust в heap память выделяет явно, через хреновины типа Box.
Не надо - не пользуйся Box.
Ответить | Правка | Наверх | Cообщить модератору

468. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Совершенно другой аноним (?), 05-Июн-20, 15:37 
> Какой штуки? Rust в heap память выделяет явно, через хреновины типа Box.
> Не надо - не пользуйся Box.

Я так понимаю, что уважаемый тёзка, а может и родственник, хотел указать, что память того, может утечь и закончится, и когда в очередной раз Вы вызовете выделение памяти, вам скажут, в терминах C - NULL. И дальше что Вы будете делать на половине пути между орбитой и землёй?

Ответить | Правка | Наверх | Cообщить модератору

489. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Forth (ok), 05-Июн-20, 20:00 
> Я так понимаю, что уважаемый тёзка, а может и родственник, хотел указать,
> что память того, может утечь и закончится, и когда в очередной
> раз Вы вызовете выделение памяти, вам скажут, в терминах C -
> NULL. И дальше что Вы будете делать на половине пути между
> орбитой и землёй?

А вы не выделяйте. В расте пока Box::new не скажешь heap трогать не будет.
Для таких случаев, как описываете, есть no_std режим. Там урезанная стандартная библиотека без heap.
Так что если надо полный детерминизм для этого всё есть.

Ответить | Правка | Наверх | Cообщить модератору

511. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Аноним (-), 06-Июн-20, 16:45 
И тем не менее, раст какой-то сложный и его все время перефигачивают. Вон новая версия и опять дохрена изменений. Это замечательно, но когда я между железом и софтом - я при этом утрачиваю видение системы в целом. И вместо понятной и предсказуемой штуки получается черный ящик, что совсем не рулит. Для сей осознать взаимодействие с железом явно проще. И высокоуровневые конструкции всему этому вообще совсем не помогают - ровно наоборот.
Ответить | Правка | Наверх | Cообщить модератору

545. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Forth (ok), 07-Июн-20, 22:03 
> И тем не менее, раст какой-то сложный и его все время перефигачивают.
> Вон новая версия и опять дохрена изменений.

Все эти изменения с обратной совместимостью, старый код никак не пострадает.

> Это замечательно, но когда
> я между железом и софтом - я при этом утрачиваю видение
> системы в целом. И вместо понятной и предсказуемой штуки получается черный
> ящик, что совсем не рулит. Для сей осознать взаимодействие с железом
> явно проще. И высокоуровневые конструкции всему этому вообще совсем не помогают
> - ровно наоборот.

С чего такие выводы?  Вы посмотрите на ассемблерный выхлоп.
Даже что-то функциональное типа .filter.map.collect выражается в итоге в простой цикл без фигни неведомой.

Ответить | Правка | Наверх | Cообщить модератору

547. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +1 +/
Сообщение от Аноним (547), 08-Июн-20, 00:17 
> Все эти изменения с обратной совместимостью, старый код никак не пострадает.

Это в целом выглядит высокорискованно - на уровне парсинга, генерации кода, стандартных либ и объема изменений во всем этом. ИМХО, если кто живет на вулкане, hi-rel его явно не интересовал. Какой rel на вулкане, право? В любой момент #%анет! Это единственное что можно гарантировать.

> С чего такие выводы?  Вы посмотрите на ассемблерный выхлоп.

Есть какие-то внятные гарантии что это будет одинаковым или мало изменяющимся между версиями компилера, либ и ллвм?

> Даже что-то функциональное типа .filter.map.collect выражается в итоге в простой цикл без
> фигни неведомой.

Зато все это надо в бошке держать - понимая как оно де факто оттранслируется. И если я хотел простую конструкцию - то и записать ее логично просто. А завтра в LLVM или этой штуке что-то поменяется и все окажется иначе. А чего доброго и с багами. Даже в си, без всяких плюсов, можно получить довольно нестандартные приколы в репу, с которыми "апликушники" либо не знакомятся, либо не парятся.

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

Так там ordu вон чего-то с этим упражнялся на атмегах - но я так и не понял каких успехов он достиг. И может ли он при этом сказать о своей системе то что могу сказать я.

Ответить | Правка | Наверх | Cообщить модератору

551. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Forth (ok), 08-Июн-20, 01:17 
Я не доверяю ни gcc, ни расту ни любому другому софту.
Я проверяю. В основном модульными тестами и тестами, которые QA проводит на наших продуктах. Если продукт тесты проходит, а тесты покрывают всё или по-крайней мере все критичные части, значит можно _предполагать_, что всё хорошо.
Полагаться же на некое "они там наворотили", а вот тут "все такое проверенное временем" я не буду.
Другое дело, что писать на C и тем более тесты C-кода, гораздо муторнее и дольше и это задолбало.
Я свой выбор сделал: legacy остается на C, всё новое пишется на Rust, если нет каких-то объективных причин писать на чем-то другом.
Ответить | Правка | Наверх | Cообщить модератору

553. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Аноним (-), 08-Июн-20, 07:54 
> Я не доверяю ни gcc, ни расту ни любому другому софту.

Я тоже. И имею заметить что понимание заскоков тулчейна может потребовать несколько месяцев плотного знакомства до того как поляна хоть немного вытопчется и станет понятно куда ходи, куда не ходи, и почему это так.

> Я проверяю. В основном модульными тестами и тестами, которые QA проводит на
> наших продуктах. Если продукт тесты проходит, а тесты покрывают всё или
> по-крайней мере все критичные части, значит можно _предполагать_, что всё хорошо.

А оно является именно "critical" когда с вот лично вас за отказ этой штуки могут спросить, с перспективой компенсации ущерба или тем более обвинить в причинении вреда здоровью/смерти?

> Полагаться же на некое "они там наворотили", а вот тут "все такое
> проверенное временем" я не буду.

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

А так то тесты конечно да, но опять же ресурсов не бесконечно и обвешивать все тестами - нафиг надо.

> Другое дело, что писать на C и тем более тесты C-кода, гораздо
> муторнее и дольше и это задолбало.

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

> Я свой выбор сделал: legacy остается на C, всё новое пишется на
> Rust, если нет каких-то объективных причин писать на чем-то другом.

А это вообще про какие сценарии? Характер софта, требования к надежности, платформы, ... ? А то если это уебня какая-нибудь или корпсофт - я в курсе чего там, thank you very much. А если это что-то типа микроконтроллеров с требованиями к надежности и жесткому реалтайму, это уже интереснее послушать. Если это честное описание проблем, особенностей и грабель вместо слащавого маркетингового булшита, например. Вот маркетинговый булшит я могу почитать на сайте любой корпорахи.

Ответить | Правка | Наверх | Cообщить модератору

559. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Forth (ok), 08-Июн-20, 21:02 
> А оно является именно "critical" когда с вот лично вас за отказ
> этой штуки могут спросить, с перспективой компенсации ущерба или тем более
> обвинить в причинении вреда здоровью/смерти?

Только после того, как клиент согласится провести опломбирование не только изделия, но и управляющего интерфейса машины, во избежание вмешательств с его стороны. Этого уже не первый год от них добится пытаемся. :)

> А так то тесты конечно да, но опять же ресурсов не бесконечно
> и обвешивать все тестами - нафиг надо.

Не понимаю как без модульных, системных, стресс тестов (в том числе климатических и прочее) можно тогда говорить о "Critical" и личной ответственности? Глупо быть обвиненным в кривости изделия, не проверив его в полном объеме.

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

То не тот пакетный менеджер, ничего в систему не ставит, посмотрите как оно сделано. Мы же о cargo говорим?

> А это вообще про какие сценарии? Характер софта, требования к надежности, платформы,
> ... ? А то если это уебня какая-нибудь или корпсофт -
> я в курсе чего там, thank you very much.

Что могу - расскажу. :)

> А если
> это что-то типа микроконтроллеров с требованиями к надежности и жесткому реалтайму,
> это уже интереснее послушать.

Так и есть. Система отслеживает попадание людей в близкое положение к рабочим органам машин или под колеса. При возникновении опасной ситуации выключает механизмы/останавливает машину, если допустимо. Как минимум выдает тревогу оператору машины. Речь о шахтных и карьерных погрузчиках, самосвалах, буровых машинах и т.п.

> Если это честное описание проблем, особенностей и
> грабель вместо слащавого маркетингового булшита, например. Вот маркетинговый булшит я
> могу почитать на сайте любой корпорахи.

Куда же без грабель и особенностей, есть они, но пока ни во что критичное не вляпывались.
Правила разработки в целом те же, что и для safe-critical систем на C, язык просто другой.
Например память только статическая, без аллокаторов, детерминизм всех вычислений, время всех операций считается по worst-case и т.д. и т.п.
Пробегусь по основным замеченным вещам:
1. На удивление не было граблей пока с линковкой с C кодом, просто работает как надо. Все-таки тесно интегрировано с llvm/clang, нечему ломаться.
2. Отладка доставляет некоторый геморой, потому что нормально отладчик работает только в дебаг режиме, без оптимизаций. А в нем все на порядок медленнее, чем в релизе, не попадаем в тайминги реальных операций иногда. Наверное лечится подбором параметров оптимизации llvm, не проверял. Но редко нужен отладчик, 95% багов ловится тестами!
3. После C компиляция медленная конечно, текущий проект в релизе собирается 7 минут, дебаг побыстрее минуты 2. Терпимо, тем более что релиз сам не собираешь, это забота билд-сервера.
4. Поддержка со стороны IDE вменяемая только в IntelliJ/CLion, в остальных есть грабли.

Ответить | Правка | Наверх | Cообщить модератору

565. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Аноним (566), 13-Июн-20, 11:14 
> уже не первый год от них добится пытаемся. :)

Еще надо к питанию не подключать, чтобы уж наверняка.

>> А так то тесты конечно да, но опять же ресурсов не бесконечно
>> и обвешивать все тестами - нафиг надо.
> Не понимаю как без модульных, системных, стресс тестов (в том числе климатических
> и прочее) можно тогда говорить о "Critical" и личной ответственности? Глупо
> быть обвиненным в кривости изделия, не проверив его в полном объеме.

Если говорить об этом - вы кого пытаетесь за дурака держать? Ну невозможно в полном объеме протестировать любую мало-мальски сложную систему. Все кто в теме об этом прекрасно в курсе. То что мой decision making на предмет что тестить хуже тойотовского - можно поспорить :)

А, на поржать, в этом вашем пыхтонрасте то на что налетела тойота не особо то и чинится. Раст видите ли на системе без MMU так вообще от переполнения стэка не поможет особо - а там тоже вот так вот запросто пойдет и перепишет переменные и кучу. В большой системе MMU возбухает на основании сегментов, но в более мелких МК - MPU есть не всегда и не у всех.

Я даже нашел костыль на тему. Но черт возьми, это что? Специальный линкер? Какой-то экспериментальный? Спецом для? Серьезно? Блин, на сях это стандартным линкером из тулчейна можно обыграть если надо. Не то чтобы совсем без костылей, но не таких же, йпрст...

> То не тот пакетный менеджер, ничего в систему не ставит, посмотрите как
> оно сделано. Мы же о cargo говорим?

О карго, конечно. Я не доверяю хипстерам норовящим мне нагадить мне куда-то сбоку каким-то мусором. А то что оно не в систему - отлично, у меня какой-то мусор мимо системного пакетника. А потом припрутся рубисты, питонисты, ноджыэсеры... и в конце концов сделают мою систему одной большой помойкой.

> Что могу - расскажу. :)

Я тут случайно наткнулся на пример. Подофигел малость. Ощущения системы вообще по сути нет.

> машину, если допустимо. Как минимум выдает тревогу оператору машины. Речь о
> шахтных и карьерных погрузчиках, самосвалах, буровых машинах и т.п.

Это уже неплохо. Хоть я и не понимаю как вы при этом расписываетесь что эта шляпа может сделать в хучшем случае и чего делаете по поводу конской скорости релиза тулчейнов.

> Куда же без грабель и особенностей, есть они, но пока ни во что критичное не вляпывались.

Смотря что за критичное считать.

> Правила разработки в целом те же, что и для safe-critical систем на
> C, язык просто другой.

И субъективно - его навороченность совсем не в плюс, а правила особо не отработаты и не особо проверены. И копаясь вопросом как мне свои фирмвари улучшить сделав защиту от stack overflow я наткнулся на то нечто от растовиков. Долго фигел. Такое все же не в моем вкусе, я в МК предпочитаю быть близко к железу а не абстрагироваться от него хрен знает чем.

> Например память только статическая, без аллокаторов, детерминизм всех вычислений, время
> всех операций считается по worst-case и т.д. и т.п.

Ну раз так - а как вы узнаете использование стэка в worst case? И как конопатите его переполнение? Путем покупки крЮтого и дорогого камня с MPU? :)

> 1. На удивление не было граблей пока с линковкой с C кодом,
> просто работает как надо. Все-таки тесно интегрировано с llvm/clang, нечему ломаться.

А я в GCC руку набил - так что ну вообще ничерта с этого не выигрываю. Для меня это чуждая экосистема, мне самому не особо нужная. И ее зависимость от целого гугла и эпла на почти все и вся меня нервирует. Тем более что ни тем ни другим мелкие кортексы вообще не уперлись.

> Наверное лечится подбором параметров оптимизации llvm, не проверял. Но редко нужен
> отладчик, 95% багов ловится тестами!

Вот кстати у меня на си примерно так же. Только что вычислил забавный баг просто позырив дизасм.

> 3. После C компиляция медленная конечно, текущий проект в релизе собирается 7
> минут, дебаг побыстрее минуты 2. Терпимо, тем более что релиз сам
> не собираешь, это забота билд-сервера.

Как-то энтерпрайзно очень.

> 4. Поддержка со стороны IDE вменяемая только в IntelliJ/CLion, в остальных есть грабли.

Говоря за себя я МК для мелких вещей предпочитаю, без всяких ртосов и проч. Для наворотов у меня линухи на одноплатинках есть.

p.s. ах да, в процессе этого всего я как раз и узнал на чем именно лоханулась тойота... %)

Ответить | Правка | К родителю #559 | Наверх | Cообщить модератору

538. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Аноним (537), 07-Июн-20, 20:13 
> Так что если надо полный детерминизм для этого всё есть.

Для полного детерминизма надо как можно проще и без библиотек. А это явно не про раст.

Ответить | Правка | К родителю #489 | Наверх | Cообщить модератору

543. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Forth (ok), 07-Июн-20, 21:58 
>> Так что если надо полный детерминизм для этого всё есть.
> Для полного детерминизма надо как можно проще и без библиотек. А это
> явно не про раст.

Опять двадцать пять. Пишите проще и без библиотек. Никто же не обязывает.


Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру