На прошедшей в Праге конференции Linux Foundation Embedded Open-Source Summit инженеры из компании Boeing и организации UL (Underwriter Laboratorie, занимается сертификацией безопасности) выступили с докладом о проблемах, связанных с применением Linux в авионике и критически важных системах, в которых предъявляются особые требования к надёжности (полное соответствие поведения заданной спецификации) и безопасности (отсутсвтие неопределенного поведения). Отмечается, что применяемые в авионике специализированные RTOS проходят специальную сертификацию, созданы с оглядкой на предоставление гарантий в безопасности и надёжности, и проходят формальную верификацию соответствия спецификациям...Подробнее: https://www.opennet.me/opennews/art.shtml?num=59364
Проблемы сертификации, хаотичности и культуры разработки решаются созданием отдельного специального дистрибутива, к чему нет никаких препятствий.
А железо - не проблема?
Если все действия доверять софту, то вообще можно тогда и не пытаться в надежность.
> А железо - не проблема?Многие проблемы на самом деле решаемы. В том числе и учетом что железо может быть и не идеально надежное.
> Если все действия доверять софту, то вообще можно тогда и не пытаться в надежность.
Железо может отказать так же как и софт. Там где это важно на этот случай должен быть какой-то план. Скажем резервирование систем. И какая разница, железо откажет или софт? При transient можно попытаться восстановить работу системы. При permanent - ну, упс, продолжаем уже без этой системы с пониженной надежностью.
>Железо может отказать так же как и софт.Относительно недавний случай: Самолёт спроектирован так, что без ассистента им управлять невозможно, благодаря этому удалось снизить расход топлива. Софт глюкнул из за проблем с датчиком и тянул триммер вниз, пока пилот тянул штурвал вверх. Итог понятен, самолёт влетел носом в землю. Я уверен, что там этих ассистентов было 2(резервирование выполнено) и оба уверенно желали пробурить планету насквозь.
И чего? Хренова куча самолетов убились по причинам от отпавших тросиков и проводочков этого паучьего месива до пилотов которые в том месиве приборов не смогли вообще понять в чем проблема, кто из кучи разных показаний врет - и тоже пробурили планету. Про небезопасные маневры и превышения параметров даже упоминать неудобно, этого вооооон там длинный список в той же википедии. И вообще, более 50% инцидентов это human factor. Человек самый проблемный и ненадежный элемент технических систем.
Если ты думаешь, что железячники делают всё тип-топ и надёжно, то я тебя разочарую, но они такие же говноделы, которые ещё и любят скинуть проблемы с результатом их работы на программистов со словами "да они просто в коде в коде это поправят и всё".
>SpaceX использует Linux и обычные x86-процессоры в Falcon 9
Они про ядро и его модули говорят. Не хотят они ничего создавать с нуля, хотят брать готовое или портировать уже имеющееся и тут возникают проблемы.
Мне тоже первое что в гоолову пришло - не нравится Линукс, напишите своё, удовлетворяющее всем потребностям.
Зачем писать свое можно купить QNX там есть все что они хотят.
> Зачем писать свое можно купить QNX там есть все что они хотят.Если посмотреть фичи линуха и qnx то можно заметить что в qnx их "несколько" меньше. Ну скажем в qnx есть реализация эзернета с 0-м временем рекавери путем закольцовки систем с 2-я интерфейсов? При том зачем эйрбасу такая конструкция нужна бывает - несложно догадаться. И в линухе нанять ядерных кодеров да допрогать - вариант. А в qnx - ну попробуйте это.
Ну это можно дописать, а вот что с верифицируемостью,надежностью, модульностью и всем прочим в линуксе? За сколько можно дописать?
> Ну это можно дописать,Да? Ну покажите это. Может еще за разумные сроки и деньги? А то еще и с адекватными условиями лицензии? Странно, а чего вон тем не нравится что они из линуха это хотят.
> а вот что с верифицируемостью,
Типовой девайс с QNX, чего доброго еще и на стремном x86 гробе, с его SMM, ME, и прочим, а также довольно навороченым софтом - вот прямо так уж верифицирован? Позволю себе усомниться в этом. Формальную верификацию проходят только относительно тривиальные штуки. А чему ломаться в тупом тасксвичере? Проблема в том что это довольно бесполезно само по себе - а если это софтом обвесить, до нужной фичности, большой вопрос что там верифицировано в результате. Вон тот MCAS приложивший 2 самолета - номинально сертифицирован был, не мешало ему стремать пилотов прилично времени а парочку угробить совсем.
> надежностью, модульностью и всем прочим в линуксе?
С практической точки зрения у меня есть выводки систем где аптаймом год+ без сбоев вполне обычное дело. Вырубаются по powerloss либо для апдейтов, а не потому что сбой. Откуда я делаю вывод что в принципе наруленый со знанием дела линух в приемлимую надежность может, особенно если с резервированием. Но да, назвать это приключение гарантированным и безопасным? Ни в коем разе. Это здоровая сложная штука, активно развиваемая, где в новой версии могут повесить баг. В этом смысле имплементерам системы придется потр@хаться. Но они привычные.
Модульность? Линух это МОДУЛЬНЫЙ монолит. С вполне оформившимися подсистемами и прочим. И ядро в его минимальном и максимальном обвесе - это две довольно большие разницы. И разумеется для ответственных систем лучше быть ближе к первому чем второму из соображений надежности, стабильности, безопасности и attack surface если есть доступ по сети. Юзермод вообще не навязан, это лишь ядро и может быть любой который удобно в задаче. Некоторые фирмвари сделаны так что ядро пускает лишь 1 процесс, основную тушку фирмвары.
А "всего такого" в линуксе как раз хоть отбавляй, вот его довольно много кто и пытается до умений RTOS заодно еще догнать.
> За сколько можно дописать?
См. выше. ИМХО многие из топиков в принципе решаемы до адекватных на практике уровней. Ну вон Маск и ко не сыкуют в космос летать, комплексные гибридные мероприятия позволяют получить довольно надежные системы даже из неидеальных компонентов. А чрезмерное упование на идеальность компонентов обычно приводит к тому что ситуация когда это оказалось не так - не обрабатывается, или обрабатывается криво, а итог может быть достаточно печален.
Если чего то хочешь , то вложись деньгами или наими кодеров. А то хотят плюшки и притом что бы кто то это сделал за них. Халявщики. Многие компаний это поняли и пилят нужные им фичи сами. Google, Facebook , Amazon и другие.
В данном случае Linux - это ядро, а не дистрибутив.
Оформляешь ядро тарболом и вот уже ядро -- дистрибутив. Магия какая-то, не иначе.
Перефразирую: в докладе говорилось о проблемах разработки ядра, а не собранного из исходников пакетика.
Автор утверждает, что это всё вопрос создания отдельного специального "пакетика", не более.
Порадуете цитатой?
>Проблемы сертификации, хаотичности и культуры разработки решаются созданием отдельного специального дистрибутива, к чему нет никаких препятствий.
Так это автор комментария утверждает."нет чёткого плана развития, заранее определённой архитектуры и требований к системе" - вот это не решается форком. Архитектурой и планированием может заниматься "апстрим", но не ответвление.
Это надуманные проблемы. У QNX всё это было, ну и где она сегодня?
Оформляешь свой вопрос тарболом и вот уже он -- дистрибутив. Магия какая-то, не иначе.
Система развивается. Пару лет назад был свежий релиз.
Или Вы что то другое имели ввиду?
> Перефразирую: в докладе говорилось о проблемах разработки ядра, а не собранного из
> исходников пакетика.Проблемы высосаны из одного места:
"RTOS проходят специальную сертификацию, созданы с оглядкой на предоставление гарантий в безопасности и надёжности, и проходят формальную верификацию соответствия спецификациям."
О каких гарантиях безопасности и надёжности идёт речь?
т.е. если условный самолёт сломался потерпел крушение, то что эти гарантии дадут? Или они до предполагаемого ожидаемого перехода на linux никаких проблем никогда не имели?
Я не в защиту linux и его применения, мне пофиг, но предъявы какие-то попсовые, дутые, рассчитанные на гумунтиратиев.А вот это ещё что такое: "...хаотичность (нет чёткого плана развития, заранее определённой архитектуры и требований к системе), отсутствие должной культуры разработки..."?
Им не нравится открытая система разработки выходит, и что это за отсутствие должной культуры, корпоративной-соборной, когда всё в руках одного "вождя"? Или тансгендерных негров недостаточно?Звучит так, будто ребята совершенно ошиблись адресом и теперь хотят из змеи сделать жирафа, да ещё и с предъявой.
>[оверквотинг удален]
> не имели?
> Я не в защиту linux и его применения, мне пофиг, но предъявы
> какие-то попсовые, дутые, рассчитанные на гумунтиратиев.
> А вот это ещё что такое: "...хаотичность (нет чёткого плана развития, заранее
> определённой архитектуры и требований к системе), отсутствие должной культуры разработки..."?
> Им не нравится открытая система разработки выходит, и что это за отсутствие
> должной культуры, корпоративной-соборной, когда всё в руках одного "вождя"? Или тансгендерных
> негров недостаточно?
> Звучит так, будто ребята совершенно ошиблись адресом и теперь хотят из змеи
> сделать жирафа, да ещё и с предъявой.*рассчитанные на гумунитариев
>А вот это ещё что такое: "...хаотичность (нет чёткого плана развития, заранее определённой архитектуры и требований к системе), отсутствие должной культуры разработки..."?Им не нравится открытая система разработки выходит, и что это за отсутствие должной культуры, корпоративной-соборной, когда всё в руках одного "вождя"? Или тансгендерных негров недостаточно?
Они хотят чтобы весь Линукс писали исключительно только для них одна единственная контора.
Вообще называя вещи своими именами у них и правда нет некоторых элементов той культуры. Скажем они antibug coding практикуют далеко не в самом жестком стиле и нет хорошо формализованых критериев описывающих чайникам DOS и DONTS. Поэтому зашивающийся корейский кодер на которого спихнули F2FS и ksmbd в одну рылу - гребет 2 галерами как умеет, при том даже не имеючи какого-то гайдлайна на тему откровенно провальных действий. Ну и получается как вон тут гражданин ссылочку на CVE прислал, что как бы не айс.
>> Перефразирую: в докладе говорилось о проблемах разработки ядра, а не собранного из
>> исходников пакетика.
> Проблемы высосаны из одного места:
> "RTOS проходят специальную сертификацию, созданы с оглядкой на предоставление гарантий
> в безопасности и надёжности, и проходят формальную верификацию соответствия спецификациям."
> О каких гарантиях безопасности и надёжности идёт речь?
> т.е. если условный самолёт сломался потерпел крушение, то что эти гарантии дадут?
> Или они до предполагаемого ожидаемого перехода на linux никаких проблем никогда
> не имели?Они обозначили проблему. Следующим шагом предложат способы её решения. При этом они могут как действительно хотеть решить проблему, так и в итоге всяких чрезмерных тестирований и сертификаций погубить ядро.
> Я не в защиту linux и его применения, мне пофиг, но предъявы
> какие-то попсовые, дутые, рассчитанные на гумунтиратиев.Иначе говоря, найдутся технически малограмотные люди, готовые активно поддержать инициативу? Вот это и непонятно зачем сделано.
Сборки?
Может еще использовать SteamDeck для этого
Отсылка в сторону батискафа если что
Батискаф, это Титан? Виноват оказался Линукс, что ли? Если так, примите поздравления. Конспирологи утверждают, что его утопили намеренно.
В линуксах геймпады нормально не поддерживаются, это всё враки.
Я бы продолжил делать "батискафы" из консервных банок, сажать туба представителей мировой элиты.
На самом деле просто людям-рыбам не нравятся туристы.
А что бы и нет? Может на нем к северным потокам ныряли,а теперь следы замели.
Так давайте развивать конспирологию.
Допустим, ныряли, заметают.
То есть утопили ненужное и заодно Линукс.
В аренду сдавали этим русским?
> Может еще использовать SteamDeck для этогоДля управления атомными субмаринами контроллеры от иксбокса используют, так что почему бы и не стимдек? Да и самолёты современные давно не на тросиках летают, всё электронное, и джойстик в Аэрбасе куда ближе к логитеховскому, чем ты думаешь.
На джойстике в Аирбасе стоят переменные резисторы, с которых гарантированно стачивается токопроводящий слой?
> На джойстике в Аирбасе стоят переменные резисторы, с которых
> гарантированно стачивается токопроводящий слой?Они могут и в сервисный регламент прописать - "менять каждые X часов". Без этого не airworthy, а кому там в ангаре дурной джойстик помешает? Да и пилот большую часть времени с джойстиком ничего не делает. В нормальной ситуации врубают автопилот и тот рулит эн часов сам. Так что думается даже обычный геймерский джой там бы протянул дофига и больше - у геймеров нагрузки на этот джой намного выше в общем случае.
Кстати, периодическая замена запчастей еще и фича: можно, вот, "your_trial_period_is_over.jpg" всяким показывать. Или летайте на стремном джойстике без запчастей, но если что - вы это сами, а эйрбасы и боинги - хата с краю :). Да и вообще - ну когда еще переменный резистор за несколько килобаксов продашь, например? :)
Это домыслы, или Аирбас действительно такое фуфло?
> Это домыслы, или Аирбас действительно такое фуфло?Полустеб ессно, скорее всего джой там покапитальнее. Но тривиальные компоненты за нетривиальную цену авиаторы любят. Никогда не видели особые, сертифицированные болты - по штуке зелени за болт? И списки расходников и запчастей там длинные, плюс-минус еще 1 компонент вопросы не вызовет. Напишут что менять раз в эн - будут менять раз в эн. Это проблемы производителя адекватно оценить параметры своих компонентов и донести до эксплуатационщиков как и что.
> Отсылка в сторону батискафа если чтоПо-моему у батискафа были проблемы по линии сопромата или катастрофического отказа. Простите, но допустим корпус не способный выдержать давление никакой линукс не скомпенсирует при всем желании. Более того - с пафосным QNX он развалится ничем не хуже. А как показал пример боинга и FAA, можно иной раз и откровенно глюкавый софт сертифицировать - и потом приложить 2 самолета о землю. Тогда, конечно, сертификат отзовут взад а баг придется чинить...
>>Проблемы сертификации, ....... решаются созданием отдельного специального дистрибутива...НЕ решаются в принципе, от слова "никак".
в презенташке (третья ссылка) упомнается DO-178, почитайте на досуге.
Надо юзать BSD/конец конференции.
Дело не только в софтверной части
Попробуй, расскажешь как оно. Если чо, я тоже поюзываю. И потому, никому бы рекомендовать бзд не стал.
Поюзывай молча.
Несколько лет назад словил баг с сетевой картой челсио, при создании виртуальной карты вылетает ошибка, после чего операционная система вовсе не паникует, а начинает случайные данные записывать в случайные файлы.
> Надо юзать BSDИ это будет лучше - ну вот конкретно чем и по каким пунктам?
Можно сказать чем это будет хуже. Непопулярные системы, с мизером разработчиков, меньше фич, жесткому реалтайму даже не пытаются соответствовать (под линух есть патчи RT_LINUX и их большая часть уже замайнлайнили, но еще несколько - таки осталось). Тестовой инфраструктуры вообще толком нету, а о качестве кода говорит например попытка комитнуть кривой вайргад в фрибсд, или шоу с безопасностью виртуалок в OpenBSD где VM могла патчить кернелмод хоста нахаляву. А если этот софт по авиационным стандартам на лажу прозвонить... ух ну и трындец же там будет имхо.
Зато можно будет хвастаться я пропатчил самолет на FreeBSD.
> Зато можно будет хвастаться я пропатчил самолет на FreeBSD.Только чур вы и будете тестовым манекеном для своих патчей...
>> Надо юзать BSD
> Можно сказать чем это будет хуже....
> (под линух есть патчи RT_LINUX и их большая часть уже замайнлайнили, но еще несколько - таки осталось).Классическое "Уже почти да, но еще нет, но вот уже совсем скоро!".
> а о качестве кода говорит например попытка комитнуть кривой вайргад в фрибсдТ.е. то что плохой код так и не закомитили - говорит о плохом качестве кода. Вот оно че, Михалыч!
И то ли дело какой нибудь ksmdb или eBPF - вот там качество кода так и прет!> Тестовой инфраструктуры вообще толком нету,
https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri...
https://cgit.freebsd.org/src/log/?qt=grep&q=cheribsd
> mrsas: Use mrsas_sge64 instead of iovec for the S/G list for passthru. 4 days 1...
Use UMA_ALIGN_PTR instead of sizeof(void *) for zone alignment. John Baldwin 2017-03-15
...
> The TLS offset is a property of the process ABI. Brooks Davis 2016-09-15
> Merge atse(4) interrupt handling and race condition fixes from cheribsd: Bjoern A. Zeeb 2014-09-16...
Да-да, это то, что ваш Платиновый Пропритерный Патрон предложил полгода назад
https://www.opennet.me/opennews/art.shtml?num=58726
> Предложенное решение позволяет блокировать ошибки, вызывающие выход за границы объекта в памяти, не допускает подмену указателей (все указатели должны порождаться от уже существующих указателей), отслеживает обращение к памяти после освобождения (любой доступ к памяти по некорректному указателю или указателю, ссылающемуся на освобождённый объект приводит к генерации исключения).Только результаты этого жесткого "тестирования" комитятся во фрю уже 10 лет.
В общем, ЭкспертПоВсемуОсобенноПоБЗДам294 во всей его пламеннной красе.
> Классическое "Уже почти да, но еще нет, но вот уже совсем скоро!".Скоро сказки сказываются, да не скоро дело делается. У бсдей хотя-бы шедулеры с реалтаймными ГАРАНТИЯМИ есть? Что на интервале в M времени реалтаймный таск выполнится не менее чем N времени? При ЛЮБОМ раскладе? Предоставление таких гарантий в любых условиях (без этого оно вообще не RTOS и не могет про реалтайм всерьез заикаться) - очень отдельный квест в большой операционке и устройстве ее кишок. Вот этот вот шедулинг и механику вокруг я таки уже в майнлайне вижу. Но некоторые вещи все еще способны срывать гарантии. Поэтому "почти". Что-то мне подсказывает что в бсдях этого счастья - даже если такой шелудер будет - на порядок больше. Потому что врядли там кто даже начинал ЭТО всерьез. И тем более начав - в апстрим удосужился бы.
> Т.е. то что плохой код так и не закомитили - говорит о плохом качестве кода.
Оно говорит о организации рабочих процессов. Я бы зассал в их самолете лететь. Мало ли какой мафиози прожмет код авторитетом а принципиальный чел типа автора вайргада в этот раз не попадется?!
> И то ли дело какой нибудь ksmdb
Что за ksmdb?! Я могу штуки три разных подсистемы с похожим - но другим - названием придумать. Вы про которую из?
> или eBPF - вот там качество кода так и прет!
КМК в гайдлайнам по сабжевым системам будут советовать такое вообще отключать. На всякий.
> Только результаты этого жесткого "тестирования" комитятся во фрю уже 10 лет.
Это жесткое тестирование как-то помогает бзде стать реалтаймной системой, например?
>> Классическое "Уже почти да, но еще нет, но вот уже совсем скоро!".
> Скоро сказки сказываются, да не скоро дело делается. У бсдей хотя-бы шедулеры
> <много букав оправданий> Но некоторые вещи все еще способны срывать гарантии. Поэтому "почти". >Какая (очередная) многословная вариация "почти да, но еще нет и *рен его знает, будет ли вообще" ...
> Что-то мне подсказывает что в бсдях этого счастья - даже если такой шелудер будет
> - на порядок больше. Потому что врядли там кто даже начиналНу, твоя фантазия тебе много чего, не имеющего общено с реальность, подсказывает.
Допилить (и верифицировать) под реалтайм какой-нибудь DiscoBSD https://www.opennet.me/opennews/art.shtml?num=58564 всяко проще будет.
Да и наличие "на порядок" большего количества костылей^W прослоек в ядрах, как-то сомнительно. Скорее наоборот - колчиество найденых и (с громкими фанфарами) устраненных тормозов при разработке io_uring как бы, намекает.
>> Т.е. то что плохой код так и не закомитили - говорит о плохом качестве кода.
> Оно говорит о организации рабочих процессов. Я бы зассал в их самолете лететь. Мало ли какой мафиози прожмет код авторитетом а принципиальный чел типа автора вайргада в этот раз не попадется?!Как обычно, много пафоса и перевирания^W отсебятины, мало конкретики. Слетевший с нарезки (бывший) разраб - такого ведь в пингвинчике не будет! А вот платиновые партнеры, пропихнувшие свои дырявые хотелки - совершенно ничего не говорят об организации рабочих процессов, ведь "это другое ©", ага.
>> И то ли дело какой нибудь ksmdb
> Что за ksmdb?! Я могу штуки три разных подсистемы с похожим - но другим - названием придумать. Вы про которую из?https://www.opennet.me/opennews/art.shtml?num=59189
>> или eBPF - вот там качество кода так и прет!
> КМК в гайдлайнам по сабжевым системам будут советовать такое вообще отключать. На всякий.Опять многословные эвфемизмы вместо простого "Это не считается!"|"Это другое!"©
>>> https://www.opennet.me/opennews/art.shtml?num=58564
>> Только результаты этого жесткого "тестирования" комитятся во фрю уже 10 лет.
> Это жесткое тестирование как-то помогает бзде стать реалтаймной системой, например?Похоже, это жесткое тестирование не только нехило помогает гасить баги в зародыше, но и спрыгнуть с темы ЭкспертуПоВсему294.
> Какая (очередная) многословная вариация "почти да, но еще нет и *рен его знает,
> будет ли вообще" ...Судя по тому что я вижу - с приличной вероятностью будет. А вы имели предложить что-то лучше? Тогда давайте по пунктикам, конкретненько. Что там у вас с этим всем? Линуксоидам пришлось основательно перепахать кернел на предмет устранения кода который мог заткнуть надолго ядерный контекст в uninterruptable, нагибая гарантии шедулера. Потому что если процесс нельзя вышибить с проца вот прям ща т.к. он где-то что-то в кернельном контексте делает, окей, значит вон тот реалтаймный процесс подождет - и гарантии профаканы. А вы не ртос соответственно.
Вон то заняло нехило времени и усилий. И даже после этого осталось несколько проблемных мест. Вплоть до цуко вывода в ядерную консоль. А что если она на медленном UART допустим? А, буфер поставим. Круто, а что если буфер заполнился? А, caller встрянет? Ух ты - гарантии идут лесом. И такого счастья когда "жесткий" реалтайм интересовал - ооооочень много где.
> Допилить (и верифицировать) под реалтайм какой-нибудь DiscoBSD
Ну, допилите и верифицируйте, если оно вам надо. Может вы еще и аргументы "за" придумать сможете чтобы всякие боинги и андеррайтеры денег дали? :)
> Как обычно, много пафоса и перевирания^W отсебятины, мало конкретики.
> Слетевший с нарезки (бывший) разраб - такого ведь в пингвинчике не будет!Совсем уж откровенный крап бортанет хоть тот же Торвальдс, объяснив что он вам тут не мусорный бачок. Иногда компромиссы бывают - но, знаете, чтобы вот прямо гангстерская история с пилением балок и абузом девовских полномочий чтобы денег по левому срубить? Ну не знаю, не встречал.
> Опять многословные эвфемизмы вместо простого "Это не считается!"|"Это другое!"©
Мсье, вы баклан. Это "конфигурация/адаптация системы под задачу", "системная интеграция", "экспертиза в области" и т.п.. Представляете, generic система может и не катить в дефолтном виде для сильно кастомной задачи. И в линукс кернеле есть что покрутить на эту тему. Скажем у меня в эмбедовочных ядрах дефолты тех ядер заметно отличаются от десктопных или серверных систем. И даже бывают разные в зависимости от предполагаемого использования конкретного выводка систем. Я уверен что авиаторы смогут и покруче даже, если захотят.
> Похоже, это жесткое тестирование не только нехило помогает гасить баги в зародыше,
Что-то сомневаюсь что у вас там есть обвес реально сравнимый с тем что сейчас в линухе.
А что до ksmbd (а не ksmdb, бжад) - да, факъ, какой же самолет без "виндовой" файлопомойки на управляюших то компах?! Так что всенепременно собрать этот молуль. И наверное еще и хомячкам разрешить с развлекательной системы заливать в бортовые компьютеры что-ниб удь прикольное. Надо ж заимплементить легенды про вирусы перехватываюшие звездные крейсера?! Мы рождены чтоб сделать сказку былью, ниипет :)
> Совсем уж откровенный крап бортанет хоть тот же Торвальдс, объяснив что он вам тут не мусорный бачок. Иногда компромиссы бывают - но, знаете, чтобы вот прямо гангстерская история с пилением балок и абузом девовских полномочий чтобы денег по левому срубить? Ну не знаю, не встречал.В общем, опять много пафоса и попытка заболтать реальность (в которой тот код так и не попал в майнлайн и не факт что попал бы и без вмешательства автора вайергарда).
>> Опять многословные эвфемизмы вместо простого "Это не считается!"|"Это другое!"©
> Мсье, вы баклан. Это "конфигурация/адаптация системы под задачу", "системная интеграция",
> "экспертиза в области" и т.п.. Представляете, generic система может и неКакой уныленький спрыг с первичного тезиса о "качестве кода" на "это другое, ты дурак!" ...
> А что до ksmbd (а не ksmdb, бжад) - да, факъ, какой же самолет без "виндовой" файлопомойки на управляюших то компах?! Так что всенепременно собрать этот молуль. И наверное еще и хомячкам
Ну да, не можешь возразить - заболтай и (опять) подмени контекст. Ничего нового.
> В общем, опять много пафоса и попытка заболтать реальность (в которойВ которой ваши бсды никому на...фих не нужны, но вы аж кюшать не можете и все время пытаетесь сосватать эти "офигенные" системы хоть куда-нибудь. С предсказуемым результатом.
> тот код так и не попал в майнлайн и не факт что попал бы и без вмешательства
Ну, понимаете, если вопрос в том что меня этот код будет держать в воздухе и может без дураков приложить о землю - это все достаточно слабое утешение. И проверять на своей тушке чего-то не хочется. Там и к линуксоидам то претензии как видите есть, но у этих процесс в целом достаточно культурный и прозрачный, так что я например обычно знаю потенциально проблемные фичи типа ksmbd или NTFS3 "заранее". И не юзаю их в большей части одноплатников, соответственно. Вот как раз по критерию "не уверен в качестве кода фичи в данный момент". Даже если это и не самолет, упавшие или взломаные управляющие системы это полный ацтой и я совсем не фанат такого развития событий. Это как минимум вредно для репутации а если совсем не повезет то и сесть можно.
> Какой уныленький спрыг с первичного тезиса о "качестве кода" на "это другое,
В целом у линя довольно приличное качество кода. Но какое правило без исключений? А экспертиза в том и состоит чтобы эти подводные камни знать. Тогда все годами работает и все збс.
> Ну да, не можешь возразить - заболтай и (опять) подмени контекст. Ничего нового.
Есть общая оценка проекта. А есть нюансы. В случае ksmbd и ntfs3 было явно анонсировано что качество кода этих штук компромиссное и их берут авансом т.к. довольно нужные фичи. И я таки был в курсе этого. А вот про ваш вайргад от гангстера таких анонсов не припоминается. На самом деле линуху тоже найдется что предъявить в вон тех контекстах. Но если оценивать проект в целом, скажем по числу багов на KLOC - линух имхо будет здорово лучше. И да, в упралвяющих системах ненужные фичи имеет смысл вырубать. Зафиг там лишние баги и attack surface?!
> Мало ли какой мафиози прожмет код авторитетом а принципиальный чел типа автора вайргада в этот раз не попадется?!https://www.opennet.me/opennews/art.shtml?num=55000 - я просто оставлю это здесь
> Тестовой инфраструктуры вообще толком нетуДля OpenBSD - http://bluhm.genua.de/.
К слову открытое полноценное тестирование для Linux ядра начали делать не так уж и давно и это при их бюджетах.
>К слову открытое полноценное тестирование для Linux ядра начали делать не так уж и давно и это при их бюджетах.Э, тестирование линукс ядра. У одного только оракела несколько тысяч часов тестов линукса исполняется ежесуточно. А там еще куча корпораций разрабов линукса.
>>К слову открытое полноценное тестирование для Linux ядра начали делать не так уж и давно и это при их бюджетах.
> Э, тестирование линукс ядра. У одного только оракела несколько тысяч часов тестов
> линукса исполняется ежесуточно. А там еще куча корпораций разрабов линукса.Они тестируют то, что нужно их клиентам. И Оракл, и Каноникал, и Редхат поверх ванильного ядра накладывают свои патчи и тестируют уже другое ядро. К тому же, это закрытое тестирование и ничего о нем детально неизвестно (какое железо, какое тестовое покрытие, какие виды тестов и т.д.).
Поэтому я все таки говорил про открытое тестирование (kernel-ci.org), которое появилось недавно. Результаты на kernel-ci предоставляют все необходимую информацию о тестировании.
>Они тестируют то, что нужно их клиентам.Оракел сейчас и есть сам клиент линукса. На линуксе крутят свое облако, для него линукс и пилят, собственно.
>И это будет лучше - ну вот конкретно чем и по каким пунктам?Драверы в пространестве пользователя, например (netbsd)
>Можно сказать чем это будет хуже. Непопулярные системы
Непопулярные где? В IT-базаре? В этом случае, это скорее плюс, меньше бедлама, который творится вокруг разработки линукса.
> с мизером разработчиков, меньше фич, жесткому реалтайму
Это не проблема в лавочках, где *bsd юзают в качестве основы, разрабов там сколько хочешь.
> Драверы в пространестве пользователя, например (netbsd)А они вообще есть? Например, для WiFi ax. Ладно, хотя бы для ac.
> Драверы в пространестве пользователя, например (netbsd)1) А что это дает? Возможность перезапустить драйвер? Ух, блин, а сбой драйвера - опасная ситуация хоть там как. И вон то не сильно улучшает общую ситуацию.
2) И вообще при обнаружении аномалии систему нехило бы перезагрузить. Потому что кто б его знает какого реально масштаба урон и что еще там идет не так.
3) Это нагибает скорость и латенси реакции. Кернелу проще гарантированно и вовремя отспорить свое.
4) В линухе внезапно тоже можно довольно мнго чего через юзермод делать. Если реально захотеть.> Непопулярные где? В IT-базаре? В этом случае, это скорее плюс,
Кроме того момента что вот надо нам драйвер для вон той вундервафли писать. И ... ых, ых, ых... так и закончится внедрение системы. А зачем вам система без драйверов, она бесполезна? А для линуксов найти ядерных кодеров достаточно реально.
> меньше бедлама, который творится вокруг разработки линукса.
Честно говоря раздолбай в именно кернел кодинге в лине - довольно экзотично. В том числе и потому что кодинг в кернелмоде ошибок не прощает, а паника в системе как серпом по... - это неизбежно приучает кодеров к джентльменскому минимуму antibug. Но, увы, лишь минимуму.
> Это не проблема в лавочках, где *bsd юзают в качестве основы, разрабов там сколько хочешь.
Если вы не заметили, в современном мире этих лавочек так то уже почти и не осталось как раз. В том числе и поэтому.
Вообще-то есть формально верифицированные ОС. Несколько лет назад китайцы такую сделали.
> Вообще-то есть формально верифицированные ОС. Несколько лет назад китайцы такую сделали.С ними есть 1 мелкая проблема. Это как правило примитивные тасксвичеры которые нихрена не умеют. Нечто более сложное формальной верификации не поддается. А то что ответственность просто перепихнули на других, кодящих вон то, недостающее - это круто, конечно, но делу не помогает.
Там где нужна в крайней степени надежность, не должно быть никаких систем с Linux, Windows, MacOS и т.д. Это вообще на самом деле про другое. Проще говоря универсально решения в этом случае нет
>не должно быть никаких систем с Linux, Windows, MacOSА собственно почему не должно? Попробуйте аргументировать.
>Проще говоря универсально решения в этом случае нетНаверное вы пробовали его найти, раз так утверждаете?
Это больше про большие объемы вычислений: выдриссированы под пользовательские системы с относительной низкой отзывчивостью. А значит в специфике среднее значение специалистов будет под сервера и клиент-серверные установки.
Про системы с высокой "отзывчивостью" вы видимо не в курсе? Про специальные линуксы, используемые в промышленности тоже не в курсе? Тады ой. Судя по общим словам - вы не специалист. Зачем тогда в диалог лезете?
Специальные линуксы не подходят под требования в авионике. Новость читали?
Ну так и обсуждайте новость в чем проблема! Я же не лезу на форум лингвистов или рыбаков со своим ценным мнением. Почему тут то всегда какие-то мамины попросëнки вылезают и рассказывают общими словами что в индустрии должно быть, а чего нет?
Потому что могут! Нет он как бы того этого опен!
В новости сказано, что теорию о ненадехности линукса высказали специалисты фирмы Боинг. На минуточку, это те самые люди, которые до сих пор борются с проблемами ПО в космическом корабле Старлайнер, а еще есть такой самолет Боинг737МАХ у которого вообще нет проблем с ПО, но пара самолетов упала
А твои самолёты как летают не похвастаешься? Боинг немного отличается в мелочах от твоей фанерки склееной в клубе авиамоделистов.
А что, тот анон смог написать полетный софт хотя-бы фанерке? :)
Когда упали? Что-то не слышал в последнее время о катастрофах
Ребят, мне прям льстит, что вы меня с боингом сравниваете, буду стараться!
По поводу того почему падал 737МАХ, гугл вроде ни кого не банил еще, вот например:
https://ru.wikipedia.org/wiki/Boeing_737_MAX#%D0%9...
> Когда упали? Что-то не слышал в последнее время о катастрофахДа вот есть у боинга чудная подсистемка, MCAS - https://en.wikipedia.org/wiki/Maneuvering_Characteristics_Au...
В энных версиях софта на 737MAX она вела себя специфично - вызывая проблемы в взаимодействии с пилотами. На это материлось довольно много пилотов - а 2, вот, угробились совсем, по сути не найдя взаимопонимания с этой системой. В 1-й раз боинг смог как-то отбрехаться, но когда история повторилась точно так же, все поняли что это не случайность. И там много интересного всплыло. И те матюки пилотов на MCAS, и скидки "своему" производителю при сертификации FAA. Вот там уже все конкретно огребли, MAX'ам запретили вылеты и тут уже чинить свои факапы боингу пришлось очень даже.
А по факту -2 самолета из-за в общем то дурного поведения софта.
Совершенно внезапно хардверные вопросы должны решаться в первую очередь с хардверной стороны, инженерные с инженерной. А дистрибутивчики - это больше про медиасистемы и картинки показывать. А то народ уже хочет прокладку между креслом и монитором использовать чуть ли не для решения проблем с загоревшимся двигателем
> Совершенно внезапно хардверные вопросы должны решаться в первую очередь с хардверной стороны, > инженерные с инженерной. А дистрибутивчики - это больше про медиасистемы и картинки
> показывать.Картинки разные бывают. Glass cockpit - тоже как бы картинки показывает. А вот если там что-то пойдет не так, вероятно, пилоту придется здорово понервничать.
> А то народ уже хочет прокладку между креслом и монитором использовать чуть
> ли не для решения проблем с загоревшимся двигателемВообще-то IIRC процедура тушения двигателя обычно как раз вот этой самой прокладкой и инициируется, весьма явно. Потому что после этого двигатель работать ну вот вообще совсем перестает, и это для прокладки между креслом и монитором как бы довольно большая проблема уже, и прокладка не только должна быть в курсе - но и может иметь какие-то свои идеи относительно возможности полностью срубить двигло полностью и окончательно вот прямо сей момент.
>>не должно быть никаких систем с Linux, Windows, MacOS
>А собственно почему не должно? Попробуйте аргументировать.Вы можете математически доказать, что они будут делать только то, что от них ожидают? То есть доказать, что код не содержит ошибок и уязвимостей? Конечно нет, поэтому в таких системах должно быть как можно меньше кода. Любая ошибка может стоить жизни сотням людей и принести ущерб в сотни миллионов $. Никакая экономия на программистах не сможет окупить и одну ошибку в коде. Ну и пишут надёжный код не на Си и даже не на Rust, пишут на языке Ada.
Как и зачем можно математически доказать что-то для исходников, учитывая, что они потом компиляюццо и в самом железе могут происходить всякие внезапности ?Всякие ОСРВ в т.ч для медицинского и иного с повышенными требованиями применения аккурат на сишке обычно и написаны
А аду ту мало того что на чем-то запускать надо, так нет никаких гарантий что обработчик прерываний отработает за определенное небольшое количество тактов
А по поводу окупаемости ошибок в коде, так тот самый боинг наглядно показал что вертел он последствия тех ошибок
(
" Читал SMS -ку, много думал "
А потом решил уточнить
)Интересно, что именно неожиданного в мажоритарном вычислителе 3 плюс один, памяти с ECC и коррекцией ошибок и всём во этом на сапфире с золотыми контактами и керамической платой может произойти?
Всё что только можно придумать - уже ожидаемо.
Далее - возможно, несвязанное:
Ada SPARK , шведы, сертифицированное для управления сердцем - читали?
P.S.У пишущих на Си, скорее всего, не хватает базового образования.
Или чувства самосохранения.
Или всякие коррупционные схемы, т.е ложная уверенность, что их-то не посадят
> P.S. У пишущих на Си, скорее всего, не хватает базового образования.Учитывая что на сях написано большая часть фирмвар в том числе на транспорте, например, automotive и последние линии защит в упрвлении опасными процессами то? Конечно "тойота" иногда случается, особенно как раз у любителей ртосов понавороченнее которые использование стека оценить не могут и выносят блок переменных за ним. Ну так и ариан5 случается. А общего у них то что и те и другие забили на best practices.
(
С "Ариан-5" всё было не так.
Я когда искал исходные коды к этому инциденту, сперва сам их написал, основываясь на коде с отключённой одной проверкой из трёх.И вот по этому коду, ушедшему в "продакшен" после 7-10 лет "по одному запуску в год" и нашёл нужный материал
)
"Тойота" - и есть та коррупционная схема. Работала пока продавали на подконтрольной территории. А в USA их "сдали" "органам". Ну далее - масса материала в Инете.
P.S.
> на сях написано большая часть фирмвар в том числе на транспорте, например, automotive и последние линии защит в упрвлении опасными процессами то?Точно так же: сдать и на лесоповал.
И сохраняя в цикле этот инвариант, оставить вне забора из колючей проволоки только вменяемых. Тех что читали книги, а не просиживали штаны в ВУЗе.
(
Не переживаем - это мозговой штурм.Никто никого не посадит
С чего бы это капиталистам этим озадачиваться? Их никогда не заботили индейцы и пролетарии.
У нас с ними разные цели.
См. про классы и т.п
)
> С "Ариан-5" всё было не так.Я расследователям верю несколько больше чем случайным фэйсам с опеннета. В любом случае, кейс показал что ада мягко говоря не панацея.
> Я когда искал исходные коды к этому инциденту, сперва сам их написал,
Не понимаю что доказывает самописный код.
> "Тойота" - и есть та коррупционная схема.
Да нет там никакой коррупции, есть обычный д@лб@бизм и срезанные для упрощения углы и хреновая квалификация кодеров и видимо проблемы с менеджментом раз это вообще возможно стало.
Во первых они взяли навороченный RTOS, повысив сложность системы.
Во вторых - квалификации кодеров не хватило на оценку worst case в использовании стека.
В третьих у них не было плана на случай если региона стека не хватит. Микроконтроллеры относительно простые системы, там нет страничной памяти и как максимум есть более простая железка для защиты нескольких регионов памяти. Поэтому чтобы поймать переполнение стека надо отдельно явно озаботиться вопросом. Чего в тойоте никто не сделал. Что довольно странно для автомотивщиков.
В четвертых, их лэйаут памяти параноей не страдал - и за стеком жили критичные переменные. Которые оно и перетирало. В том числе и описание чего водила педалью хотел.
В пятых, про идеи оценки валидности переменных, их кросс-верификацию и оценку корректности эволюции состояния систем они явно не слышали. Или кодеру было пох. Хотя любой вменяемый firmware safety guideline дает весьма здравые идеи что делать с критичными переменными как прикинуть что мы вообще в валидном состоянии работаем, что вот эту функцию вызвали в ходе нормального flow программы а не так что частица влетевшая в проц program counter скрутила, и так далее. Тойотеры были явно не в курсе этого или клали на это ....
В шестых, оказалось что они заткнули варнинги MISRA checker. А это уже совсем дно.Коррупция может какой-то вклад и имела но реально это хреновая организация процессов и некомпетентность в топике который это не прощает прежде всего. А регуляторы все же врядли могут сделать реальный аудит вооон какой фирмвари ECU даже если б и захотели.
> Точно так же: сдать и на лесоповал.
"Don't fix what isn't broken" имхо. Какая-нибудь MISRA довольно эффективна как antibug для сей. Но если варнинги чекера затыкать чтоб не мешали сборке проекта - будет примерно как у арианщиков. По похожим причинам.
> Тех что читали книги, а не просиживали штаны в ВУЗе.
В этом мире очень мало книг которые описывают real world системы - и реально существующие проблемы, а не всякие теоретические измышлизмы. Которые зачастую здорово отличаются от того что в реальных системах в реальном мире происходит.
> С чего бы это капиталистам этим озадачиваться? Их никогда не
> заботили индейцы и пролетарии.А таки при регулируемом капитализме за criminal negligence могут и посадить. И индейцам не хочется быть пролетаями - они class action lawsuit хреначат на раз. А это дорого обходится и вредно для репутации.
> У нас с ними разные цели. См. про классы и т.п )
У вас может быть. У меня цель работающие системы с разумными затратами за обозримое время. И желательно не слишком примитивные там где примитивизм отливается в проблемы. Ну да, если не ставить проц выкидывающий подушки безопасности и датчики, они не смогут убить водителя выстрелом подушкой невовремя. Тогда водила убьется вылетом через лобовое сам. Как бы отмазались, но лучше по факту не стало. Нафиг такой инженеринг.
(
Про Ариан-5: постараюсь организовать репост конкретики.Т.е., в отличие от Тойоты, ваши сведения, примерно, как мои о Т.
)По Тойота: о, спасибо!
Теперь хоть ясно, что там было.Из статей на Хабре, наоброт, сложилось впечатление, что кроме как на формальностях японцев "подловить" не удалось.
Да, кстати, про Э.Дейкстра и Ко:
изобретателю семофоров ( или как они там) я бы доверял и остальными идеями.Хотя бы для перестраховки: вдруг он все "грабли" изучил ещё лет за 10 - 15 до нашего рождения?
Про комбинаторный взрыв у Э.Д. что-то было.
> По Тойота: о, спасибо!
> Теперь хоть ясно, что там было.На мой вкус - в целом примерно то же самое что и у арианщиков, т.к. трэш в организации процессов и видимо какие-то проблемы менеджмента проектов и процессов.
Японцы вообще в вопросах корп. культуры - сильно ниже того чем принято о них думать. А хайтек в свое время у них был благодаря усилиям США, а вовсе не потому что они сами офигенные разработчики. Белый человек отслюнявил им нехилый стек технологий, показав что дружить с ним выгодно.
Вон те знания не являются чем-то уникальным, если их знает анонимус с опеннета. А пришедший наниматься в здоровую корпу на такую работу тип должен вон те вещи как раз-два-три. Его наниматель должен это обеспечить. Как и общее управление проектом. А вот если это не получилось, да еще настолько брутально - пример почему все эти регуляторы и сертификаторы вообще нужны. Чтобы хоть какие-то лимиты на подобный трешак установить. В современном мире регуляторы жестко лагают относительно прогресса, разумеется. А новое знание о проблематике пишется кровью.
> Из статей на Хабре, наоброт, сложилось впечатление, что кроме как на
> формальностях японцев "подловить" не удалось.Class action lawsuit против них "индейцы" в виде родственников померших водителей IIRC таки подавали. И "реклама" получилась очень даже, особенно у тематических лиц. Не думаю что эмбеддеры будут покупать себе что-то от тойоты, эти вспоминают тойоту в основном в контексте антибага и как делать не надо :))
> Да, кстати, про Э.Дейкстра и Ко: изобретателю семофоров ( или как они там)
> я бы доверял и остальными идеями.Я никогда и никому не доверяю на 100%, даже себе. Очень мало чего в этом мире реально незыблемые и безусловные константы. Ну может планковская константа. И то я бы не поручился за это.
> Хотя бы для перестраховки: вдруг он все "грабли" изучил ещё лет
> за 10 - 15 до нашего рождения? Про комбинаторный взрыв у Э.Д. что-то было.Все? Очень сомневаюсь. Отраслевые понимания некоторых проблематик не такое уж старое знание. И оно всегда дополняется. Вот кто-то типа DJB выдал некоторые умные мысли, вида "меньше кода == меньше багов". Это и правда работает, но, увы, не всегда является приемлимым вариантом по другим параметрам.
>> Ну и пишут надёжный код не на Си и даже не на Rust, пишут на языке Ada.Про надежный код на Аде - смешно. Про взрыв ракеты Ариан-5 слышали? "Ракета разрушилась на 40-й секунде полёта из-за неверной работы бортового программного обеспечения". "Этот неудачный запуск стал одной из самых дорогостоящих компьютерных ошибок в истории." "центральный полетный модуль - 60 тысяч строк кода на языке Ада"
> Про надежный код на Аде - смешно. Про взрыв ракеты Ариан-5 слышали?
> "Ракета разрушилась на 40-й секунде полёта из-за неверной работы бортового программного
> обеспечения". "Этот неудачный запуск стал одной из самых дорогостоящих компьютерных ошибок
> в истории." "центральный полетный модуль - 60 тысяч строк кода на
> языке Ада"А теперь представь, что их не 60 тысяч, а 30 миллионов и без какого либо статического анализа. Будет лучше?
> А теперь представь, что их не 60 тысяч, а 30 миллионов и
> без какого либо статического анализа. Будет лучше?Ну вообще, корабли Маска вроде на МКС вроде летают, вот как раз с линухом. И почему без анализа? Линух много кто на автомате сканит, тестит, и много чего еще. Знаете что такое syzkaller? А есть такая вещь как syzbot, это пачка syzcaller'ов fuzz'ит кернел, а словив какой-то факап авто-бисектит до проблемного комита и даже ругается в рассылку и показывает на редиску пальцем.
> пачка syzcaller'ов fuzz'ит кернелА я вот то ли у Э. Дейкстра, то ли у Хоара читал, что тестирование не показатель отсутствия ошибок.
Т.е. ошиблись классики ?
( что-то "нутром чую - литр будет" и не ошиблись. И не зря с полсотни докторов наук Гриса переводили.
Причём вышло лучше, чем в оригинале на Globish)
> А я вот то ли у Э. Дейкстра, то ли у Хоара читал, что тестирование
> не показатель отсутствия ошибок.Для себя я предпочитаю верить своим глазам и думать своим мозгом. И я вижу что в случае крупного кода - более-менее адекватны только сложные комплексные мероприятия и вон то это их часть.
При том тесты бывают разные. Скажем юниттесты проверяют что накодили блок кода именно так как было задумано. А более глобальные - что оно после интеграции в целое ведет себя адекватно, т.к. на стыке взаимодействий кусков тоже можно отхватить чудес. А бывает вообще fuzzing. Потому что в даташите может и написано что датчик может выдавать от сих до сих, но, знаете, реальный мир может иметь свое мнение на этот счет и сдруевший датчик влет накормит систему какими-то совершенно неадекватными значениями. Если при этом софт навернется - ну, блин, ой. Поэтому долбежка рандомом не панацея но - при достаточной интенсивности успешно ловит неведому хрень.
> Т.е. ошиблись классики ?
Скорее имели синтетическое представление не от мира сего - особенно его актуальной версии. Могу сказать что всякие математические верификации имеют большую проблему: не работают для более-менее крупного софта из-за комбинаторного взрыва, при котором доказать что-то для ВСЕЙ системы в СБОРЕ что-то становится малореально. А даже если вы проверили отдельные мизерные кусочки это не доказывает что они вместе делают что-то адекватное. Более того - в штуке размером с самолет чертова куча разных систем взаимодействующих между собой. Писаных разными кодерами. И то что 2 разные тимы одинаково поняли формальное описание и все краевые случаи - мягко говоря не факт.
Как угодно но мир стал сложнее. В нем стало больше данных и все хотят больше фич. Если первые авиаторы сидели на воздухе, дергали рычаги от и до сами, то теперь хотят систему автоматической посадки, спутниковую навигацию, анализ топологии местности - и предупреждение что впереди гора, приборов постепенно стало столько что пилоты начали зашиваться, особенно в ситуации отличной от идеала. Не говоря о том что в сотнях проводков, тросиков и чего там еще все время что-то барахлит и из-за отсутствия средств самодиагностики хрен поймешь что. А разбирать самолет от и до перед каждым вылетом никто не будет. И пилот сталкивается с дилеммой, лететь ему абы как или резко и дорого обломать всем кайф под угрозой линча руководством - и все же пусть техники более плотно займутся. Заодно оказалось что умные машины могут лучше знать параметры машины и например не дать пилоту делать явно провальные действия. И ясен фиг логика всего этого - ни в раз не тривиальная. Как и коммуникации с продвинутыми датчиками, перекидывания кучей сообщений по шинам с пачкой систем и проч. Топологически современный транспорт это ездящие, летающие и плавающие сети компьютеров и микроконтроллеров. Это совсем другой паттерн. Со своими специфичными проблемами - но это лучше чем то что было до этого, назад никто не вернется.
> с полсотни докторов наук Гриса переводили.
Я давно не оперирую переводными материалами, в том числе и потому что насколько переводчики в курсе тематики и не наломают дров, угрохав изначальный смысл - отдельный вопрос.
> Причём вышло лучше, чем в оригинале на Globish)
Да вот как бы вам сказать... азы antibug coding годные для практических применений в управляющих системах мне вот например в основном в libera.chat програмеры объяснили + несколько ресурсов жестких профессиональных эмбедеров, которые гамна лаптем покушали на практике. То что так кто-то в РФ может я честно говоря сильно сомневаюсь. А вон та магия нехило работает, я более-менее смог в направление и в принципе я начинаю немного доверять своим сишным фирмварям. Бывает так что даже с 1 раза работает как надо, сразу без багов.
А некое "практическое" понимание топика - парочка firmware safety guideline'ов от компаний типа STMicro которые расписывают с чем вообще можно столкнуться (не, теоретики про половину этого тупо не в курсе и в их рассуждизмы сие зачастую не включено, так что система будет себя вести не так как предсказано ими). Это больше для автомотивщиков, но там видите ли люди тоже мрут если ECU или ABS сделает что-то не то, а это кучка проциков с фирмварой да исполниловкой и сетью - по сути "fly by wire lite". Стандартный паттерн дизайна систем.
Авиаторы еще более замороченные, у них всяких рулесов и гайдов еще больше. На что были причины. Тем не менее что касается софта и сертификации, как показали некоторые примеры это все не очень эффективно работает, если боинг игнорит вопли пилотов и даже падение 1 самолета от дурного алгоритма MCAS, и требуется чтобы еще 1 боинг расплющило точно так же, так что тогда даже какой-нибудь посторонний NTSB понимает что тут где-то подстава и имеет всех по полной.
А каким рентгеном или ультразвуком не удастся "просвечивать" тросы?(
Сами пилоты требуют вернуть старорежимный штурвал "с тросиками", как меру "последней надежды"
)
Я за комплекс мероприятий, но оснований не использовать как часть этих самых комплексных мероприятий, в том числе, и Ada SPARK не вижу.Советские доктора наук при переводе книги Гриса не наломали дров, а, наоборот. Т.е. с этим частным случаем - всё Ок -ей.
Боинг я здесь где-то рядом за 2 датчика с ручным (!) выбором исправного критиковал
> А каким рентгеном или ультразвуком не удастся "просвечивать" тросы?По всей длине? В том нагромождении? С каким-то более-менее гарантированным выводом? Плохо себе представляю как эти процессы могут быть быстрыми и не трудоемкими. Простой самолета - стоит ОЧЕНЬ дорого.
Как в цифровой системе проверить что у меня исполниловка работает? Дать ей команду отмотать воооон туда! И прочекать что концевик сработал или показания датчика положения ожидаемые. Если прокатило -> подсистема живая, а мы реально проверили функциональность. Быстро, автоматически, "от и до". Конечно раз в эн надо более подробную инспекцию, общего износа механики и проч. Но сильно реже.
А терь попробуйте за разумное время прочекать что у вас вся куча стрелочек вообще что-то показывает и это что-то реалистичное? Хорошо получается?
> ( Сами пилоты требуют вернуть старорежимный штурвал "с тросиками", как меру
> "последней надежды" )Да вроде обычно делают некий абсолютно минимальный механический бэкап. Типа горизонта и чего еще по мелочи. К тому же голыми руками огромные поверхности пилот хрен пересилит. Ну а электрике и электронике можно аккумуляторы поставить и/или турбинку для набегающего возраста. Что и делают.
> Я за комплекс мероприятий, но оснований не использовать как часть этих
> самых комплексных мероприятий, в том числе, и Ada SPARK не вижу.Зато их вижу я - Ada используется крайне маргинально и софта на ней и кодеров мизер. А тупые как дрова системы могут быть проблемой. Если UI горбатый и визуализация не доходчива для пилота или экзотичный софт не может допустим актуальные карты нормально отрисовывать, ценность такого улучшения сильно ниже чем могла бы быть. И вот уже кой-кто у...тся об гору, "потому что этой горы не было на карте". Ну и чем ему ада поможет? А была бы навигация попродвинутее - гора была бы на карте а у пилота было бы понимание что туда лететь ни-ни. И даже если софтина рендера карт на си++ каком, имхо, можно пережить. Если ситуацию вот именно комплексно рассматривать, с разных сторон.
> Советские доктора наук при переводе книги Гриса не наломали дров, а,
> наоборот. Т.е. с этим частным случаем - всё Ок -ей.Советская авионика столь крута, что ее первым делом выкидывали даже китайцы, закупавшие у россиян миги в 90-е. А остальным такое и подавно не надо.
> Боинг я здесь где-то рядом за 2 датчика с ручным (!) выбором исправного критиковал
У боинга есть свои скелеты в шкафу, свое легаси (например, нельзя резко ломать ожидания пилотов) и свои бестолковости. Линейка 737 мягко говоря не молодая. А авиаторы точно не фронтир инноваций. И никто не говорил что у них все идеально. Но тут вроде разговор о том как двигаться вперед в будущем, какие проблемы, чем грозит, что можно сделать и проч. Заметьте, это через лет так 30, или сколько там, после появления линуха.
> Про надежный код на Аде - смешно. Про взрыв ракеты Ариан-5 слышали?Вот только Ada там ни при чём.
Т.е. код, конечно же, на ней, а вот причина организационная.Материалы - общедоступны
> Там где нужна в крайней степени надежность, не должно быть никаких систем
> с Linux, Windows, MacOS и т.д.Эти системы некорректно ставить в 1 ряд. Первое вполне годится для автоматических операций без взаимодействия с человеков. Второе и третье в принципе для этого не созданы. Что стало для них большой проблемой например в серверном сегменте. А вы думаете Linux там просто так обосновался? Нифига, им нужны перфоманс и - безотказность а также "необслуживаемость". Потому что когда у вас дофига серверов вы не можете кномочки давить на каждом из них, они должны просто работать.
И между прочим Элон Маск летает в космос используя пингвина. И марсианский вертолетик пингвин юзает. И ничего, дрэгоны летают чартерными рейсами, вертолетик на марсе летал, и от линуха никаких проблем не было особо. А если даже бортовой компьютер сглючит, это решаемо резервированием - и проверкой что компьютеры одного и того же мнения, с игнором и попытками восстановления дивергента если надо.
Windows NT 4.0 Embedded летает на спутниках.
Так вот почему с ними вечно какие-то проблемы. То двигатель не заведется, то панели не раскроются, то еще что-то. Теперь то всё встало на свои места
Теперь то стало понятно как они так умудряются работать с превышением срока службы и приносить пользу человечеству.
Они же "неместные" Ж-)
> Windows NT 4.0 Embedded летает на спутниках.Given enough thrust pigs fly just fine...
> Windows NT 4.0 Embedded летает на спутниках.
>Given enough thrust pigs fly just fine...Allow me to remind you of a phrase from a classic work of Russian literature:
"No Russian words, no Russian face."
Мгимо финишд? Хав мач вач?
Разве что 149-ый аноним, тот закончил если не МГИМО, то школу с английским уклоном.Но нынче эпоха ИИ / GPT.
Так что знание про правильный перевод на Globish фраз типа
"При достаточном тяготении свиньи летают вполне нормально", несколько обесценилось Ж-)
Ну ты сравнил фундаментальную отрасль с тысячами жизней на кону и пет проект Илончика.
> Ну ты сравнил фундаментальную отрасль с тысячами жизней на кону и пет проект Илончика.Пет проекты Илончика пускают чертову кучу недешевых спутников на орбиту и даже возят астронавтов на мкс. И пока вроде достаточно успешно.
А вон те фундаменталы из боинга как раз пару самолетов приложили своим софтом недавно. Однако над ошибками они работать все же умеют. И даже FAA по итогам огребло люлей насколько я помню. У эйрбаса тоже обсираки в том числе и связанные с софтом случались. Если кто хочет сказать что это фу и надо вернуться к механическим тросикам, цифреблатикам и кучам проводочков - так у этого хлама надежность еще ниже была, хоть отказы и по другим причинам но когда у вас вместо 1 шины дикое месиво тросиков, контактов и проч - там в том паучьем царстве очень много чего может пойти не так. И нифига оно не более надежное, чисто статистически. Более того - компьютерные системы имеют хоть какие-то шансы в нормальную (само)диагностику и показ пилоту наиболее важных факапов в приоритетном режиме. Более глупая механика - ну там столько логики напряжно, извините.
> когда у вас вместо 1 шины дикое месиво тросиков, контактов и прочГораздо более дикое месиво (на порядки) тросиков, контактов и проч закопано в процессорах и софте.
> Гораздо более дикое месиво (на порядки) тросиков, контактов и проч закопано в
> процессорах и софте.Оно не отваливается и не перетирается от тряски и вибрации, в отличие от того барахла.
А еще поддается определенной самодиагностике. Состояние тросиков и проводочков можно увидеть только разобрав к хренам весь самолет. Траблы с процессором можно увидеть прогнав тестовые вычисления. Траблы с шиной - пульнув тестовые пакеты. И так далее.
Более того - если вон там прицеплено 3-4 одинаковых датчика, можно проблемный заигнорить на автомате. А если пилоту вывесить эн приборов - большой вопрос куда он посмотрит и сможет ли сделать вывод что прибор гонит. Особенно если пилот не выспался или ситуация нервная/нестандартная. А компьютеру похрен, он циферки сравнит и выводы о датчиках сделает. Он не может не выспаться или быть выбит из колеи нестандартной ситуацией.
> если пилот не выспался или ситуация нервная/нестандартная. А компьютеру похрен, он циферки сравнит и выводы о датчиках сделает."Не очеловечивайте компьютеры - они этого страсть как не любят".
Т.е. как там у Э.Дейкстра ?
Про признак чего-там при использовании антропоморфной лексики в отношении ЭВМ?
(
Заодно и советский полу-учебник "Простое и сложное в программировании" будет повод перечитать Ж-)
)
> "Не очеловечивайте компьютеры - они этого страсть как не любят".Будущее принадлежит разумным машинам имхо. А может и гибридным частично органическим дизайнам. Во всяком случае пока у инженеров большие проблемы с self diag - а self repair почти не существует. И это как бы весьма жирные косяки существующих технологий. А то что так можно было - мы уже поняли.
( на всякий: )Т.е. ту книгу читали?
( неожиданно.)Но там ИИ, скорее жёстко критикуют, чем хваляет.
И выдвинут тезис, о жестких требованиях применимости любого класса ПО.
> Т.е. ту книгу читали?Не факт, но ряд идей достаточно распостранен в sci-fi и у продвинутых спецов. Конвергенция в одни и те же точки может идти разными путями.
> Но там ИИ, скорее жёстко критикуют, чем хваляет.
Я бы сказал что все великие технологии - весьма опасные. Но это и супервозможности из sci-fi. Это может быть большим шагом вперед. С ранее недостижимыми возможностями.
Я бы в идеале хотел увидеть оперирование другими уровнями энергий, вещи типа фотонных двигателей как sublight, проделывание червоточин и/или "гиперпространство" или фокусы на манер Alcubierre drive на практике. И я чертовски уверен что рулить даже дальним подобием чего-то такого механическими тягами - адский маразм. Люди недостаточно быстры и точны для таких вещей. Называя вещи своими именами, они и для обычнго авиалайнера слишком тормознуты. Пилоты 2 самолетов летящих навстречу даже с дозвуковой скоростью запросто могут не успеть на друг друга среагировать.
> И выдвинут тезис, о жестких требованиях применимости любого класса ПО.
Если я что-то понимаю в устройстве этого мира, AI может постепенно стать не только равным человеку, но и гораздо мощнее... и кстати кто-то уже понял что "ChatGPT может предложить варианты как улучшить ChatGPT". Если какой-то вот такой номер заработает в его полном виде...
P.S.Пока не забыл:
> если вон там прицеплено 3-4 одинаковых датчика, можно проблемный заигнорить на автомате.
Только их почему-то 2 ( два) датчика.
И есть тумблер, которым надо вручную выбрать исправный.
P.S. У французов - больше двух.Но, если постараться, то можно:
-- в мороз
-- сразу после полива на датчики антиоблединителя, т.е. со льдом в трубках
-- взлетев метром на 300 .. 700, сказать дружбанам, а "зацените как автопилот нас спасёт" спикировать к земле.И много датчиков не поможет.
P.P.S.
Пилотам же с "базовым образованием"- помогает
> Только их почему-то 2 ( два) датчика.Это плохое инженерное решение: чтобы понять какой датчик врет очень желательно чтобы их было три - тогда 1 сбоящий датчик можно отрубить/заигнорить. Даже автоматически. А поскольку мир не идеален, с датчиками рано или поздно может приключаться какая-то фигня. И подгружать этим человека, если этого можно избежать - фигово с точки зрения надежности и безопасности.
> И есть тумблер, которым надо вручную выбрать исправный.
Идея с мажоритарным выбором 2 из 3 лично мне нравится больше. Понятно что мир не идеален и иногда это невозможно. Но выпихивать решения на мясо, в мануальном режиме, кроме самых необходимых и ключевых решений - хреновый инженерный паттерн как по мне.
Ну да, двигатель тушить на автомате дерьмовая идея, вдруг они там на взлет шли, а тут автоматика решила двигатель потушить. А вот явно кривой датчик отсеять - если остальные 2 адекватные данные выдают - почему нет? Я примерно такой по смыслу фокус в менее критичных управляюших системах использую - неплохо работает, спасая от дурацких взбрыков на ровном месте.
> 700, сказать дружбанам, а "зацените как автопилот нас спасёт" спикировать к земле.
Мне больше понравилось как пилоты испытатели потестировали фиксы самолета на ... недостаточной высоте. Идея о том что тест может пройти неудачно и нехило иметь на этот случай какой-то план почему-то не посетила их. А напрасно! Но это как раз +1 к забагованости людей. На человека вот можно поднажать и он обойдет директивы чтобы тест прогнать вот именно сегодня, иначе дескать руководство вздует. А компьютерам этот фактор вообще похрен. Вы же не депремируете компьютер?!
> Пилотам же с "базовым образованием"- помогает
Можно говорить что угодно но у людей есть лимиты их возможностей и "баги" поведения. Усугубляемые неидеальностями типа невысыпания, паники или напротив неадекватной реакцией на явную угрозу и тому подобные приколы. Люди очень глючные существа. А уж не выспаться для пилота обычное дело - смена таймзон, заскоки компаний, вплоть до потуг игнора регуляторских требований и проч - не есть что-то неслыханное.
Да, полностью согласен.( и, примерно на это же, "прозрачно намекал". )
> и даже возят астронавтов на мксПоревозят десятки тысяч людей ежегодно, как тот же боинг?
> И пока вроде достаточно успешно.
Пока у пет проекта Илончика летных часов за всю жизнь спейсов меньше, чем у самолетов боинга в день. Что как бы намекает, у кого точней статистика отказоустойчивости, не?
> хаотичность
> отсутствие должной культуры разработкиНадо понимать, что это смягчённые и соответствующие CoC-ам формулировки.
И ведь говорится про ядро, где собраны лучшие специалисты, архитекторы, кодеры, а не просто майнтайнеры и сборщики пакетиков.Интересно, зачем компании с двухбуквенным доменом в зоне com всё это надо.
"1 января 2012 года Underwriters Laboratories преобразовалась из некоммерческой организации в коммерческую компанию в США. Новая дочерняя компания, названная просто UL LLC, корпорация с ограниченной ответственностью, взяла на себя бизнес по тестированию и сертификации продуктов Underwriters Laboratories."
"Underwriters Laboratories (UL) — это глобальная некоммерческая научная компания по безопасности, в которой работает более 14 000 человек, которые живут в 40 странах."
>где собраны лучшие специалистыВход в разработку ядра свободный. Буквально. Так что ваше заявление ни на чём не основано. Там проходной двор и слепая надежда, что майнтейнер подсистемы увидит проблему до принятия патча.
Моё заявление основано на собственном опыте:Коммит в ядро как минимум проходит формальное ревью, и проверяющий подписывается. Без этого код так и останется в рассылке.
Коммит в дистрибутивы - это башпрограммист, не способный сам добавить (в смысле - написать) требуемый функционал, находит что-то похожее где попало и пихает в пакетик.
То есть "лучшие" означает не "вообще лучшие", а из "мира Линукс". И в других подсистемах всё куда хуже.
Спросите разрабов Байкала, насколько он свободный
Байкал полностью несвободный.
Никто толком не знает, что такое свобода. Требуется целый Ричард Столлман, что бы объяснить, что это не про бесплатное пыво. Зато если Underwriter Laboratorie обяжет коммитеров проходить сертификацию, можно и свободу не трогать, и заодно китайцев отшить.
>где собраны лучшие специалисты, архитекторы, кодеры:))))))))))))) спасибо поржал
Хотел сначала написать "из мира СПО", не не стал. Все знают™, что СПО - это самое лучшее. ;)
> Интересно, зачем компании с двухбуквенным доменом в зоне com всё это надо.Можно угадать с 1 попытки: будут тестировать это и сертифицировать. Чем еще UL заниматься может?! А чтобы вон то делать надо как минимум нефиговое понимание предметной области. Логично вроде.
>> Интересно, зачем компании с двухбуквенным доменом в зоне com всё это надо.
> Можно угадать с 1 попытки: будут тестировать это и сертифицировать. Чем еще
> UL заниматься может?!Это, как говорится, понятно и ежу.
Вопрос в том, какая цель у столь недешевой деятельности, и к чему приведёт: полетит ли Линукс в космос или мусорную корзину.
> Вопрос в том, какая цель у столь недешевой деятельности,ИМХО,
1) Послать негибкие проприетарные решения и жесткий вендорлок в пень, как все.
2) Получить вон ту хренову кучу фич, даже если для этого и придется потр@хаться.
3) Сэкономить на этом всем. Самим что-то сравнимое с ноля никакой бюджет не потянет, если так делать то билеты на самолет вскоре будет стоить как на суборбитальное путешествие.Есть еще всякие смежные случаи. Скажем юзеринтерфейсы всякие и проч. Там и реалтайм важен т.к. состояние интерфейса должно соответствовать тому что на самом деле есть, и надежность важна - помирание glass cockpit какого - крутая проблема, а на ртосине делать нормальный UI с развитыми коммуникациями по сети и проч - отдельное мучение. И ушлепанский контринтуитивный интерфейс в стиле 2 притопа 3 прихлопа тоже проблема. Даже если он и не откажет, пользователь в нем может запутаться и испытвать проблемы с навигацией. Что бывает довольно критично в случае какого-нибудь бортового компьютера.
> и к чему приведёт: полетит ли Линукс в космос или мусорную корзину.
В космос он уже летает. В мусорную корзину пока не собирается. А появится ли через цать лет что-то лучше - откуда бы заранее знать. Наверное когда-то наступит момент когда кто-то сможет и еще лучше. Во всяком случае это ничему не противоречит.
А кажись у spacex ui какой-то на электроне написан. Так что уже полетел
> И ведь говорится про ядро, где собраны лучшие специалисты, архитекторы, кодеры, а не просто майнтайнеры и сборщики пакетиков.Лучшие?? Это поэтому в ядре так много тупейших ошибок, быдлокодинга и мягко говоря сомнительных архитектурных решений?
>> И ведь говорится про ядро, где собраны лучшие специалисты, архитекторы, кодеры, а не просто майнтайнеры и сборщики пакетиков.
> Лучшие?? Это поэтому в ядре так много тупейших ошибок, быдлокодинга и мягко
> говоря сомнительных архитектурных решений?Ну да. Если бы ядро писали башпрограммисты дистрибутивов и майнтайнеры CoC-ов, ошибки были бы исключительно умные - грамматические и пунктуационные.
> И ведь говорится про ядро, где собраны средние специалисты, архитекторы, кодеры […]Поправил, не благодари. Большая часть кода любого проекта написана самыми обычными, средними по скиллам и когнитивным способностям людьми. В айти существует миф о том, что надо быть восьми и более пядей во лбу, чтобы создать что-то стоящее. Но в реальности гении способные создать вообще хоть что-нибудь встречаются крайне редко.
> Интересно, зачем компании с двухбуквенным доменом в зоне com всё это надо.
Там написано в конце зачем: «доступность специалистов (проще найти компетентных разработчиков и людей, понимающих код)».
>> Интересно, зачем компании с двухбуквенным доменом в зоне com всё это надо.
> Там написано в конце зачем: «доступность специалистов (проще найти компетентных разработчиков
> и людей, понимающих код)».Это заявление для публики. Не всегда цели декларируемые и реальные совпадают.
>> И ведь говорится про ядро, где собраны средние специалисты, архитекторы, кодеры […]
> Поправил, не благодари. Большая часть кода любого проекта написана самыми обычными, средними
> по скиллам и когнитивным способностям людьми. В айти существует миф о
> том, что надо быть восьми и более пядей во лбу, чтобы
> создать что-то стоящее. Но в реальности гении способные создать вообще хоть
> что-нибудь встречаются крайне редко.Самые обычные по когнитивным способностям люди собирают в пакетики трендовые сеты иконок и написанные добрым дядей патчи. А так же думают, что их попытка подменить тезис, заявляя, что 80% пишущих ядро являются его архитекторами, останется незамеченной.
> Большая часть кода любого проекта написана самыми обычными, средними
> по скиллам и когнитивным способностям людьми.В случае кернела с этим немного тухловато. Что самое плохое случится если вы в апликухе или сайтике налажаете? Ну, упадет может. Исправите код да перезапустите. А в ядре - кернелпаник весьма неприятный эвент на чем-то ценном. И таки заставит кодить значительно аккуратнее, обдуманнее и - в целом лучше чем вон те. А если вы так не могли, то скорее всего задолбаетесь, разочаруетесь и пойдете заниматься чем-то другим.
Вроде спейсx летает на линуксах, у них правда что-то взрывается постоянно, и не так много полётов, как у Боинга, но интересно там везде Линукс или в критически важных системах своё
> что-то взрывается постоянноДа вроде пока ничего не уронили.
Да, один раз тупо взорвали спутники на старте, а в другой потеряли на не той орбите. Правда, это давно было.
> Да вроде пока ничего не уронили.Все три первых фалкона взорвались вместе со спутниками.
SpaceX CRS-7 вместе с Dragon красиво фейерверком разлетелись в небе над Флоридой.
Orbcomm-G2 передает привет из состава подводной группировки спутников.Странное у вас какое-то "пока ничего".
И сколько человек в том драгоне погибло? А, нисколько. Это, наверное, потому, что запуск тестовый был.
У них ещё нет никакой защиты от радиации, так что софт -- это меньшая из проблем. Ну а так линукс-то -- нереалтайм система с непредсказуемыми задержками, вряд ли везде.
Существует Linux RT, но проблемы спецификации и драйверов это не решает.
> Существует Linux RT, но проблемы спецификации и драйверов это не решает.Патчи RT_LINUX уже почти втянули в майнлайн. Думаете чего вон те так активизировались?
У них и процессоры не космического класса, а обычные бытовые. Только 3 штук и они считают всё параллельно и сравнивают.
>и сравниваютА если сравниватель откажет?
Задача тебе со звёздочкой подумать что будет. У вас у веб-разработчиков это задачи со звёздочкой считается.
> А если сравниватель откажет?Так эта схема проверена на практике - первый полет Союза с системой автоматического причаливания к космической станции. Стыковку пришлось проводить вручную, т.к. система безопасности отключила по очереди все 3 модуля управления, как выдающие ложные команды. Причина - в систему безопасности заложили неправильные условия проверки команд от модулей управления.
> Стыковку пришлось проводить вручную, т.к. система безопасности отключила по очереди все 3 модуля управления, как выдающие ложные команды.Просто константа "начальная масса корабля" была внесена неправильная.
Подробнее - см. Черток "Ракеты и люди"
> А если сравниватель откажет?На "Шатле" был и пятый компьютер с независимо написаным ПО.
ПО обеспечивало посадку, но не выполнение всех целей полёта
Сделай два сравнителя и более)
> Вроде спейсx летает на линуксах, у них правда что-то взрывается постоянно, и
> не так много полётов, как у Боинга, но интересно там везде
> Линукс или в критически важных системах своёРазгадка проста, Маск юзает бубунту в своих поделиях.
А вот у космонафтики здорового человека был Debian и ничего плохого не случилось:
"NASA использует систему Debian на рабочих местах космонавтов МКС[94]. Также NASA применяло систему Debian в экспериментах на шаттле Колумбия[95]."
Так то "на рабочих местах", это нещитаеца.
У наса люди гибли при полёте.
> У наса люди гибли при полёте.У боинга тоже гибли. И в CCCР гибли, просто про это в отличие от успехов не далдонили в каждой программе Время. Поэтому про мертвых космонавтов или какого-нибудь Неделина знает/помнит не так уж и много народа. Не означает что всего этого не было.
Нормальные Космо(астро)нафты на Арчике и все летает. Дебиан только и подходит, что для ретроградов из насы
Особенно удачный эксперимент в 2003 году получился.
Обычно ничего не мешает компоновать контроллеры реального времени с более тупыми бытовыми контроллерами.Можно хоть два контроллера одной версии, но с разным назначением (реалтайм rtos и нет на linux..).
Но и я думаю, что на одном контроллере двухядерном +- можно добиться результатов выше.
Хаотичность и отсутствие культуры это то чего никогда не будет в Фуксии, которая скоро заменит все никсовые поделки.
Пусть гулаг её хотя бы снова заопенсорсит, как это в начале было.
Чтобы что? Чтобы создать хаотичность и снизить культуру написания кода? Спасибо не надо.
Чтобы снизить культуру внедрения зондов.
А там что-то хоть собирается? Там что-то дорабатывается вообще или оно как какие-нибудь типичные окологосовские склады "стабильно" работающие на FoxPro for DOS десятки лет тупо потому что за миску риса и мутную идейку переделывать всю эту помойку никто не будет?
Все голосовые помощники нест хабы принудительно перевели на Фуксию. Потестят сделают хорошо, перейдут на другие устройства. И медленно покроют всё стадо. Даже в сабж новости почитай к ядру слишком много вопросов. Васяны не в состояние в стратегию.
> Все голосовые помощники нест хабы принудительно перевели на Фуксию.
> Потестят сделают хорошо, перейдут на другие устройства. И медленно покроют всё стадо.Или быстро закроют проект к хренам, может даже вместе с насестом. Как это бывает с более чем 90% проектов гугли. Особенно когда экономика проседает, так что 20% фуксиков уже как раз и ушло искать новую работу...
То ли дело венда...
Сейчас бы Боингу рассуждать о безопасности.
Хардвар - геймпад
Софтвер - стимОС
Ох уж эти черномемщики с батискафом
Сейчас существует реальная проблема - проф. деформации разрабов-коекакеров под такой способ производства, когда фактически работа над фичами важнее любой надежности
Врача ищет больной, а не здоровый. Именно им и надо рассуждать.
Так Боинг и рассуждает
А вот представьте сколько катастроф было бы, если бы на боингах стоял линукс!
Там в драйвере переменная переполнилась и завалила ядро, тут оом убил ваш автопилот.
Ну, это при условии что оно вообще взлетело бы.
На сегодняшний день Боинг обладает самой безопасной сертефицированной операционной системой в мире: Boeing's SNS Server. Так что их мнение стоит уважать.
> На сегодняшний день Боинг обладает самой безопасной сертефицированной операционной системой
> в мире: Boeing's SNS Server. Так что их мнение стоит уважать.Сколько А320 Нео разбилось? А сколько Б737 Макс?
Самолёты сложная система, бортовое ПО далеко не единстенное место отказа. Там кажись с датчиками косяк был.
"Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича, да взять сколько-нибудь развязности, какая у Балтазара Балтазарыча, да, пожалуй, прибавить к этому еще дородности Ивана Павловича..."
(с) Н.В. Гоголь
Смысл новости непонятен. Многопользовательское, многозадачное ядро общего назначение ВНЕЗАПНО! не подходит для критически важных систем! Я вам каждый день могу такую экспертизу проводить, где мои гонорары?
Ты сначала должность какую-нибудь высокую займи, а потом да твоё капитанство будет каждый слушать открыв рот и бабосы будут.
Смысл новости очевиден: заставить эту кучу народа бесплатно поработать и на авиацию, как они работают на жругих технологических гигантов за звездочки на гитхаб (зато не как у фрибзд, где лицензия неправильная)
Сейчас они обозначили проблему, следующим шагом могут захотеть её решать: введут Rust, очень нужную сертификацию или ещё что-то.
Не надо нам в авиации инноваций и хаотичной культуры разработки. Продать лайнер за сотню миллионов долларов, но съэкономить на хорошей RTOS - это в духе современных дизайнеров.
Главное, что этот подход приносит деньги. Цифры продаж Boeing 737MAX не дадут соврать.
Ребят, пользуясь случаем хочу спросить: а что есть из микроядерного для десктопа? Кто чем пользуется?
Пользователей Intel пользует Minix, а про остальных бытуют противоречивые конспирологии.
Какой изящный троллинг
Тебе уже миллион раз только в этом треде сказали Fuchsia OS.
Фикция всё это.
GNU Hurd
Ты, конечно, с него пишешь?
Часть вопроса была «кто чем пользуется».
С него, но оно в виртуалке, запущенной на десктопе
Mac os x...
> вынос драйверов в пространство пользователяШли годы, десятилетия, а линуксоиды все продолжали выносить драйвера из ядра ).
Их кто-то туда обратно что-ли вносит? )
Единственная возможность чтобы твои драйвера хоть как-то собирались в новых выпусках ядра, это быть в ядре. Как только ты вынесешь в модуль, то специально для тебя ядро будет каждый выпуск ломать совместимость abi и api для модулей так, чтобы твои модули никогда не работали с новыми ядрами. А ты или забивал на свой модуль, или делал его совместимым лишь с некоторыми версиями ядра.
Это следствие монолитности, т.е. изначально ущербной модели и узколобости главного пингвина планеты. Ну и толпы баранов, которые вложили в курсовую работу лярды и закрепили идею.
Интересно какие такие драйвера в Linux понадобились боингу для мышек, видеокарт или геймпадов. Понятно что вынос драйверов из ядра мы никогда не дождёмся. Чтобы вынести драйвера из ядра проще написать своё ядро. А значит нет смысла рассматривать линукс дальше про соответствие спецификации, культуру разработки и обеспечение качества. Ясно что ядро предназначено для дестопов и серверов, не подходит для систем с повышенной надёжностью. Вот какие из последних изменений в линуксе так нужны в авионике? Патчи в сетевом стеке, исправления для btrfs, новые драйвера для wifi, поддержка LoongArch и Apple M2, улучшение в гипервизоре KVM.
> из ядра проще написать своё ядро.Или посмотреть на всякие VFIO например и проч.
> Шли годы, десятилетия, а линуксоиды все продолжали выносить драйвера из ядра ).разве? обсуждается такая идея — да, такое есть. но вот работы в этом направлении я что-то не помню (во всяком случае чтобы в ванильное ядро попало).
Попытки сделать фреймворк для этого были. И даже сделали - UIO. Вот только на нём основаны раз, два,... и всё, драйверов. В основном, на шине CAN.
оужас, уберите..Вспомните ntfs драйвер в userspace. И какая там производительность? Аа наверное поэтому его обратно в kernelspace запихнули.
> оужас, уберите..
> Вспомните ntfs драйвер в userspace. И какая там производительность?Такая, что кое-кто в свое время, глядя на результаты бенчей, подломился искать и исправлять торомза в ядерном драйвере Ext?
Продолжали? А когда начали-то? stable_api_nonsense.txt все еще в дереве исходников и пока это так никакого выноса драйверов из ядра не будет
> Продолжали? А когда начали-то? stable_api_nonsense.txt все еще в дереве исходников и пока
> это так никакого выноса драйверов из ядра не будетНачали еще в 90-х. С тех пор регулярно этот вопрос поднимается.
Linux летает на Марсе
Там и 98 винда летает (MARSIS, ищи по новостям), это не показатель.
На марсе поюзать винду 98?) Норм, но кажись лет через 50?
Уже не летает, батарейки хватило на один полет,
А сейчас что используют?
"У Linux проблема в том, что нам нужен не Linux"
Ядро не должно знать от железе и тем более управлять им напрямую. Оно должно быть диспетчером. А сейчас как. Вышла видеокарта от X. Добавляем код в само ядро Linux на тысячи строк (привет AMD). Далее добавляем код в Mesa. И так далее.Да что уж там. Посмотри раздел keyboard ядра.
Вот в этом проблема монолитного ядра. И вишенка на торте - ядро и модули в одном пространстве работают.
Ты начтался Танебаума. Ядро Линукс оптимален.>ядро и модули в одном пространстве работают.
Ты так и ничего не понял. Тебе мозг засрал Эндрю. Проектирование ОС как микросерверной только усложнит внутренюю структуру ядра.
Диспетчером может быть и железка, зачем тогда ОС?-))
в переводе это называеся - не лезте со своим линуксом куда вас не просят.последние несколько лет ( >5 ) появилась тенденция пытаться строить авионику на всяких чипах для телефонов с соответвующим софтом.
всё это очень интересно, но НЕ сертифицируемо впринципе.
В беспилотниках везде и рядом. И вроде это даже хорошо.
только беспилотники не являются основной продукцией Боинга,а так - пжалста ;)
Отказ беспилотника - это не такая уж большая трагедия. В отличие от.
> доступность специалистовЭтим, вообще-то, можно и ограничиться. Всё остальное о "достоинствах" линуха - словоблудие. Потому то "открытость для повсеместного рецензирования" есть много у кого, например, у RTEMS, которая создавалась специаьно для авионики, "более быстрое развитие, активное продвижение новшеств" - это вообще нихрена не достоинство там, где речь идёт о человеческих жизнях, а "хорошо известный API" - это та же "доступность специалистов", только с другого ракурса.
И чем тогда они пользуются?
iOS)
Fuchsia
> FuchsiaДавай тебе в авионику это поставим? Вот ты тестовым пилотом и поработаешь потом как раз. Пустить тебя полетать на этом. Гденить над океаном, подальше от населенных мест.
Давай ты не будешь больше здесь чушь писать? В авиации так никто не делает. Когда все нормально протестят в Fuchsia тогда и полетят. И всё будет ОК.
> Когда все нормально протестят в Fuchsia тогда и полетят. И всё будет ОК.Мне почему-то кажется что скорее всего это "когда" определено как "never". Нет к тому предпосылок. Ушибленный фанатизм марки - предпосылкой не является.
Тестовым пассажиром он будет.
>>И чем тогда они пользуются?софт пишется на Аде.
Не на, а в.
А надо всего лишь разрабатывать программно-аппаратный комплекс и оттачивать железо в связке с софтом.
Почему то у Apple хватило мозгов на такую простую идею а у производителей самолётов, не хватило.
Подозреваю, производители самолётов именно так всегда и делали, и сейчас пока ещё делают, только - увы, эффективные манагеры и здесь хотят "доступных специалистов", умеющих в "хорошо известный API", причём, желательно - обитающих в какой-нибудь дыре мира, которых можно набрать пучок за пятачок.
Тут возникает один вопрос, а вот Линуксу оно, авионика, оно надо? Претензии "летунов" к Линуксу понятны, нужно "многое поменять" для их удобств, но ради чего? Потом выяснится что "Компания Х заменяет проприетарную RTOS на Линукс в своём дорогущем оборудовании, бла-бла, опенсорц, бла-бла, ценник не изменится, но акции уже пошли вверх на фоне прогноза роста прибыли из-за снижения издержек"?
> Тут возникает один вопрос, а вот Линуксу оно, авионика, оно надо?Линуксу надо то что делают участники процесса. Если кто-то решил вписаться делать эти работы, никто им запрещать это не будет. Но и помогать - в меру возможностей.
> Претензии "летунов" к Линуксу понятны, нужно "многое поменять" для их удобств,
> но ради чего?Разработка высоконадежного софта имеет свои особенности. И как угодно но некоторые процессы и практики разработки линукскернела в этом аспекте и правда стоило бы пересмотреть. Уж как минимум жесткую лекциию на тему antibug coding стоило бы дать половине кодеров, включая грандов. Потому что они явно не в курсе некоторых вещей. И хотя обычно прокатывает, временами все же икается.
> Потом выяснится что "Компания Х заменяет проприетарную RTOS на
> Линукс в своём дорогущем оборудовании, бла-бла, опенсорц, бла-бла,
> ценник не изменится,Ессно не изменится. Тестировать линуха на оборудовании типа сабжа - долго канительно и ни в раз не дешево.
> но акции уже пошли вверх на фоне прогноза роста прибыли из-за снижения издержек"?
Любой адекватный бизнес стремится к максимизации прибыли. Главное чтобы оно боком не выходило, а вот за упавший самолет таки - reboot.
> Линуксу надо то что делают участники процесса. Если кто-то решил вписаться делать эти работы, никто им запрещать это не будет. Но и помогать - в меру возможностей.Я что-то пока не вижу чтобы кто-то вписывался поработать, я скорее наблюдаю предложения и пожелания чтобы кто-то пришел и "сделал красиво" неким закулисным бенефициарам.
Мы прекрасно видели как оно проявляет себя когда кому-то реально "ННАДА" - и финансирование разработки начинается и патчи внезапные и подвижки навстречу. Пока ничего похожего.
Ну как бы некоторые пожелания - вполне разумные и определенные идеи могут и другим понравиться. Код без багов и с предсказуемым поведением в ядре нужен не только в самолетах, мягко говоря.А сертификации и проч - вон те как раз и будут как-нить сами. Ну и вон та конфа как я понимаю была о оценке и осознании проблематики направления и понимания в какую сторону двигаться вообще. Как это имплементить - второй вопрос, возникающий после понимания первой его части.
> Ну как бы некоторые пожелания - вполне разумные и определенные идеи могут
> и другим понравиться. Код без багов и с предсказуемым поведением в
> ядре нужен не только в самолетах, мягко говоря.Ну так против безбажного и стабильного кода никто и не выступает, правда когда начинаются реальные подвижки хотя бы в виде того же продвижени Rust мы слышим жуткий вой о том что "не тащите сюда эту ржавчину".
Да знаете, какая-нить MISRA и без всякой ржавчины дело сильно улучшает. Но опять же это надо переубедить толпу "ятакпривык" что их разухабистый стиль кодинга - это на самом деле фи. Хрусту в этом смысле всего лишь несколько проще т.к. он новый яп и потому то что там нельзя или канительно так и сяк воспринимается спокойнее. И то, вот, ты сам сказал.
Лекции это хорошо и нужно. Но продуктивнее все же тулинг пилить для этого, всякие анализаторы кода, чтобы подобные проблемы отлавливались еще на этапе отправки патча в рассылку
А Линукс тут уже давно не решает, что ему надо. Кто больше донатмт, тот и одеяло перетягивает. Вот сделаю контору, стану платиновым спонсором, найму 100000 м0как и 3143дец твоему линуксу. Адаптируем там, и переделаем. И ты же назовешь меня корпорацией добра за нихреновый такой вклад в спо. Но есть один нюанс
Boeing в серебряных спонсорах Linux Foundation. Если перейдёт в платиновые, станет надо.
Тогда им нужна Fuchsia с Zircon.
> Тогда им нужна Fuchsia с Zircon.Мне всегда было интересно - а такие советчики зассали бы или нет если их натурально запихнуть, натурально в самолет, натурально с тем что они продвигали, тестовым пилотом - и посмотреть, угробит их тушку продвигаемый ими софт или нет? Ну правда, гугол, скинься на самолет, и посади в него самых рьяных фанов фуксии полетать, интересно же! А перед посадкой конечно же как в вон том батискафе - вы отказываетесь от претензий, блаблабла, даже если вас размажет в хлам, блаблабла :))
вот видите - это отказ в штатной ситуации.а если как во втором орешке?
пятдесят бортов кружат над ВПП и их надо разводить по эшелонам с точностью 20 метров.
Ты считаешь что в авиации тестирование проходит так что ставят новую прошивку и сразу идут летать? Твои воззрения на ПО в авиации сильно ограничены. Когда допилят все допуски и сертификации в Fushsia тогда и полетят.
> Когда допилят все допуски и сертификации в Fushsia тогда и полетят.Т.е. скорее всего - никогда. Эта хня делалась не для этого и даже не для general purpose. И приоритеты при ее создании у гугли были сильно иные, а кроме гугла там вообще акторов нет, так что и отбалансироваться оно не сможет соответственно. И недавние увольнения 20% тимы вызывают определенные вопросы на тему кто и где ресурсы возьмет на вот это все, и что их к тому мотивирует.
В случае линя я еще в первом приближении могу себе представить - сочетание дофига фич, включая приближение к возможностям к RTOS - и заканчивая продвинутыми фичами. Среди этих фич есть и например интересный драйверок от эйрбаса, где железки с 2 сетевыми ифейсами можно собрать в кольцо, с нулевым временем рекавери при отказе 1 из веток. Еще я понимаю кто такие драйверы линуху писать может. А вот кто фуксии их будет писать - не очень. Гугл и его вебманки от такого далеки, а больше никто дрова для этой штуки и не пишет...
Если перевести с дипломатического, то инженеры Боинг просто рассказали почему они не будут использовать линукс в авионике. Видимо их таки достали этим вопросом. Если же посмотреть на указанные причины, то простыми словами линукс - монолитный копролит, разработанный мартышками без понимания, что они делают. Самым умным мартышках - кернел хакирам, кто смог понять троллинг было наверно обидно. Интересно Линус пошлёт боинг туда же куди нвидию?
Линукс послал невидию, потому что они криворучки, пишут самые упоротые дрова, просто чтобы были, с максимальными косяками и не стремятся это исправлять. По сути им главное галочка что дрова есть, чтобы можно было продавать свои серверные решения компаниям на линуксе (то есть 99% клиентов).
Боинг конечно КО, но повода посылать не появился.
> Линукс послал невидию, потому что...потому что они не часть процесса и не играют совместно, на самом то деле. Это обеспечило лэйбу "worst company ever". За дело.
> Если перевести с дипломатического, то инженеры Боинг просто рассказали почему они не
> будут использовать линукс в авионике. Видимо их таки достали этим вопросом.
> Если же посмотреть на указанные причины, то простыми словами линукс -
> монолитный копролит, разработанный мартышками без понимания, что они делают. Самым умным
> мартышках - кернел хакирам, кто смог понять троллинг было наверно обидно.
> Интересно Линус пошлёт боинг туда же куди нвидию?Это не тот самый Боинк, который капитально обоср.. с Boeing 777-8? Такие иннноваторы, такие инноваторы - сделали люминдиевый (а не алюминиево-литиевый) с негабаритными крыльями (арабы попросили).
Боинг под мудрым руководством супер-эффективных менеджеров сделал насквозь просертифицированный экономически сверхэффективный (как по эксплуатации так и по разработке) B737MAX. Который на чисто инженерных программно-аппаратных эпических косяках положил около 300 человек в двух катастрофах.
Смотря, что под авионикой понимать. Вообще там монстры типа Линукс не нужны. Есть у меня подозрение, что ветер дует со стороны эффективных манагеров, которые думают, что экономия на специалистах доведет до добра. Если железо будет кривое, то софт не поможет, а если железо нормальное, то софт там весьма специфичный и система управления справится без всех современных свистоперделок.
> Смотря, что под авионикой понимать. Вообще там монстры типа Линукс не нужны.
> Есть у меня подозрение, что ветер дует со стороны эффективных манагеров,
> которые думают, что экономия на специалистах доведет до добра. Если железо
> будет кривое, то софт не поможет, а если железо нормальное, то
> софт там весьма специфичный и система управления справится без всех современных
> свистоперделок.Вы не понимаете! Замена того что есть (возможно коммерческого) на "халявный" ляликс позволит повысить прибыль и получить премии кому надо! За одно это корпорат будет носом землю рыть.
>> Смотря, что под авионикой понимать. Вообще там монстры типа Линукс не нужны.
>> Есть у меня подозрение, что ветер дует со стороны эффективных манагеров,
>> которые думают, что экономия на специалистах доведет до добра. Если железо
>> будет кривое, то софт не поможет, а если железо нормальное, то
>> софт там весьма специфичный и система управления справится без всех современных
>> свистоперделок.
> Вы не понимаете! Замена того что есть (возможно коммерческого) на "халявный" ляликс
> позволит повысить прибыль и получить премии кому надо! За одно это
> корпорат будет носом землю рыть.А перед получением премии, отправить их с семьями летать на новых самолетах-)))
> А перед получением премии, отправить их с семьями летать на новых самолетах-)))Ну а на чем они по вашему будут летать? На этом глобусе выбора не так уж и много.
> а если железо нормальное, то софт там весьма специфичный и система управления справится без всех современных свистоперделок.для HPC и AI линукс и нужен чтобы исключить человеческий фактор из управления, а железо там обычное и софт тоже, разница в том что оно сертифицировано на соответствие стандартам поэтому всё достаточно простое и древнее и уже очевидно не удовлетворяет современным потребностям индустрии.
>> а если железо нормальное, то софт там весьма специфичный и система управления справится без всех современных свистоперделок.
> для HPC и AI линукс и нужен чтобы исключить человеческий фактор из
> управления, а железо там обычное и софт тоже, разница в том
> что оно сертифицировано на соответствие стандартам поэтому всё достаточно простое и
> древнее и уже очевидно не удовлетворяет современным потребностям индустрии.Потребностям маркетологов оно не удовлетворяет, а не индустрии. Оно работает, есть наработка на отказ, как следствие прогнозируемое поведение системы, зачем ставить модное и не проверенное, чтобы что?
> Если железо будет кривое, то софт не поможет, а если железо нормальное,Вообще-то высоконадежные системы там где это важно предпочитают не уповать на идеальное железо а вместо этого иметь какой-то адекватный план реакции на такое. Например, нескольких параллельно работающих компьютеров, и если их скажем 3 штуки, сбоящего можно автоматически вырубить/перезапустить - и не так уж важно сбойнуло там железо или софт, вон то может засечь тупой как дрова хардварнай компаратор на управляющих линиях, обнаружив что компьютеры хотят разного -> сбой вон того компьютера. Как-то так Маск летает в космос и на обычном линухе с x86 даже. И почему бы это не работало - кто б его знает.
> Как-то так Маск летает в космос и на обычном линухе с x86 даже.как-то так лет 50 до маска летали
>> Если железо будет кривое, то софт не поможет, а если железо нормальное,
> Вообще-то высоконадежные системы там где это важно предпочитают не уповать на идеальное
> железо а вместо этого иметь какой-то адекватный план реакции на такое.
> Например, нескольких параллельно работающих компьютеров, и если их скажем 3 штуки,
> сбоящего можно автоматически вырубить/перезапустить - и не так уж важно сбойнуло
> там железо или софт, вон то может засечь тупой как дрова
> хардварнай компаратор на управляющих линиях, обнаружив что компьютеры хотят разного ->
> сбой вон того компьютера. Как-то так Маск летает в космос и
> на обычном линухе с x86 даже. И почему бы это не
> работало - кто б его знает.x86 это перебор для многих задач, часть задач вообще на простых триггерах делается, а вот их не сильно сложно резервировать, а заодно обеспечить радиоактивной защитой, к примеру. Это если про космос говорить. Если нужно мониторить датчик, пусть у него даже 100 параметров, а каждый параметр это число с плавающей запятой, то опять таки X86 тоже не нужен.
> x86 это перебор для многих задач, часть задач вообще на простых триггерах делается1) Ну сделайте мне на триггерах нормальный рендер карты местности, с актуальными картами, чтобы как вон те в гору не впечататься, например?
2) Тупые, неинформативные интерфейсы и/или чрезмерно упрощенная логика - ведет либо к потере situation awareness, либо к неверным решениям, либо к проблемам самодиагностики в автоматических режимах и проч. Скажем я знаю как диагностировать на автомате ремотную исполниловку с своим процом. Даже "по сети". Полностью, "end to end". Проверив что подсистема работает и скинув статус заинтересованным. Но с триггерами это все не особо работает.
3) Педально-релейная логика в конечном итоге требует здоровых плат, с кучей контактов, коммутации и проч - и это все начинает испытывать проблемы с надежностью. В этом смысле блоки где только шины, питание и необходимые для ввода или исполниловки соединения могут оказаться и надежнее, и проще в обслуживании, и факапов типа например ошибок подключения будет меньше.> а вот их не сильно сложно резервировать,
x86 тоже не так уж и сложно, если задаться такой целью. Хардварные компараторы на исполниловку быстро покажут что компы хотели разного, а если там 2 из 3 - окей, проблемный обнаружен и можно например попробовать ребутнуть его и восстановить состояние с соседних, в надежде что это был transient.
> а заодно обеспечить радиоактивной защитой, к примеру.
И толку от этого всего если пилот гасит неверный двигатель или влетает в гору? Иногда простота бывает хуже воровства. Как по мне - кой-что из sci-fi в виде например нормальных юзеринтерфейсов и более-менее вменяемой самодиагностики систем стоило бы заимлементить. Линух думается мог бы в этом помочь.
А сказ про дрессировку пилотов это круто, но - когда у него нестандартная ситуация, на все случаи инструкции не напишешь, а вот awareness о фактическом состоянии и возможностях был бы кстати.
> Это если про космос говорить. Если нужно мониторить датчик, пусть у него даже
> 100 параметров, а каждый параметр это число с плавающей запятой, то опять таки X86
> тоже не нужен.Кажется, Неделин благодаря таким господам и помер. Когда захотелось повторить попытку пуска, а тут то и оказалось что тупой как дрова командоаппарат корректно рестартануть - занятие сложное и грабельное. И хоть он трижды надежный а примитивизм конструкции взорвал ракету и угробил народ вокруг, потому что там рестарт последовательности - сущее мучение. И высокий риск лажи. В этом месте мы начинаем догадываться что иногда гибкость, репрограмируемость, смена конфигурации и параметров на лету и продвинутые реакции - бывают нехилой фичой. Это еще не до конца разведано и используется, но так можно.
Внезапно linux который не RTOS и не разрабатывался как RTOS оказался не RTOS и даже разрабатывается не как RTOS. Ужас. Вот это новости.
Ждём следующую: инженеры ардуины обсудили проблемы использования линукс на ардуино, отмечается повышенное по сравнению с прошивкой без системы потребление памяти, тактов процессора, и соответственно потребления...
> Внезапно linux который не RTOS и не разрабатывался как RTOS оказался не RTOS и даже разрабатывается не как RTOS.это не совсем так
Ага дал ссылочку на какой-то левый сайт.
А таки убунту на ардуине грузили. Правда, грузилась она там долго.
OOM киллер или UB поведение библиотек от lgbt+ тут же уронят самолет
Разве lgbt+ пишут либы для ядра? Думал они больше по JS/Rust/Scala.
А bьlдлoкодят в ядро бородатые диды, которые еще в машкодах проги писали, но до сих пор не научились вычислять размер буфера перед записью.
Еще 10 лет назад во всех новостях Linux был синонимом надёжности и безопасности. Похоже, скоро станет антонимом.
Твой анекдот был бы уместен, если бы инженеры Боинга были бы авторитетными и уважаемыми людьми. Но Боинг это дно.
Надёжность тоже разная бывает, и разной степени. Дебиан вполне надёжный для серверных задач, например.
Ну теперь-то понятно, кто виноват в лажах с 737 MAX
Это типа бородатый анекдот про то как установив на истребитель windows америкосы научили самолет зависать в воздухе?
> доступность специалистов (проще найти компетентных разработчиков и людей, понимающих код).Кажется, это главная причина привлекательности Linux для авиапроизводителей.
В авионике крайне жёсткие стандарты. Чтобы софт можно было сертифицировать для авионики - процесс его разработки с нуля должен быть построен в соответствии с её стандартами и все библиотеки которые этот код использует должны быть тоже сертифицированы для авионики.Составляются требования высокого и низкого уровня на диалекте английского с ограниченным словарём. Эти требования трассируются на код и тесты. Код пишется на C/C++/Ada, причём используются не все фичи этих языков и вводятся определённые ограничения, например на единственную точку выхода из функции для Си. Покрытие тестами запредельное, MC/DC для высшего уровня критичности. Ни одна строчка кода и ни один тест не должны быть написаны без опоры на требования.
Причём каждый шаг сопровождается огромным количеством бумажной работы. Если написал код, но налажал с бумажками - то лучше бы вообще ничего не писал.
Так что Линукс в авионике использовать не реально.
А ещё для rtos обычно есть две версии rtos и rtos-do178, последний применяется в самолётах и урезан по самый не балуй, со стандартным rtos там только названиетак что, конечно, просто так применить linux у жадных авиапроизводителей не выйдет, ну и по делом им
Боинг попросил, чтобы ядро сделали ему с нужным ему роадмапом и чтоб немонолитно. А денег на хурд не выделил.
Весь софт Боинга протухшее говно мамонта. И я не понял с какой этой стати сопляки из Боинга смеют критиковать Свободное Сообщество. Смеют что-то там указывать. Пошли они лесом.Боинг должен обанкротится. Нам нужны другие, Свободные самолёты, где под копилефт лицензирована вся авионика.
P.S.Т.е. эта не была ирония?
Хм, интересно...
И это новое что ты придумал?
Можно начать с RISC-V и аппаратов литографии. На век работы хватит.
> Можно начать с RISC-V и аппаратов литографии. На век работы хватит.RISCV ядрами уже забит весь гитхаб...
>>Нам нужны другие, Свободные самолёты, где под копилефт лицензирована вся авионика.а подводные лодки для путешествий к Титанику не ннада?
> Весь софт Боинга ... Боинг должен обанкротится ...У него серьезнее проблемы https://www.forbes.ru/biznes/390923-etot-samolet-proektirova...
Когда-то Линус послал NVIDIA. Пора послать Линусу и Boeing. Пока они не научатся уважительно общатся со Свободным сообществом.
Позор Boing-у... так низко пасть что бы пиарить себя на разработке системы общего назначения Linux.Можно было сказать что просто разрабатывают сверх надежную систему и все.
Убогие конечено.
Им бы погуглить, что такое ОС РВ. Специалисты ...
> применяемые в авионике специализированные RTOS проходят специальную сертификациюЧто-то сертификация никак не спасла Боинги 737 MAX от падений...
> отмечается отсутствие необходимой сертификации надёжности, монолитная архитектура [...], хаотичность, отсутствие должной культуры разработки, обеспечения качества и безопасности"А Васька слушает, да ест" Линукс как был супер-надёжной системой без всей этой бюрократической требухи, так и будет. Как работали на нём сервера годами без перезагрузки, так и будут работать, в то время как вдоль и поперёк сертифицированный костыль MCAS роняет самолёты...
Все немного сложнее. Скажем если сервак тупанет на секунду - никто особо не заметит. Но самолет за это время пролетает довольно приличное расстояние. А космический корабль - еще более приличное. Он не остановится подождать пока там компьютер с тормоза снимется, как и весь реальный физический мир с которым надо взаимодействовать.
Э-э погоди, не гони. Он просто сказал, что линуксовые сервера самые надёжные и лучшие в мире. И говоря это он даёт понять, что качественный софт могут делать только ребята из ГНУ. Давай представим компанию, которая имеет Свободную авионику и копилефтный софт под неё. Неужели ты думаешь ребята из ГНУ такие тупые, что не позаботятся о создании тщательной системы проверок всего софта и электронную начинку под неё?
Если софт - ОС РВ, почему нет? Но Linux - не ОС РВ. Потому, как выше намекали коллеги, непонятно, о чем вообще речь?
> Если софт - ОС РВ, почему нет? Но Linux - не ОС РВ.Вообще, с патчами RT_LINUX он, таки, это. И их уже почти все втянули в майнлайн. В ядрах новее 6.1 там RT_PREEMPT кернел означает сильно другие вещи, с довольно жесткими гарантиями шедулинга реалтаймных процессов. К сожалению это не все и еще есть некоторые проблемные места, способные сорвать гарантии.
> Э-э погоди, не гони. Он просто сказал, что линуксовые сервера самые надёжныеУ надежности есть много аспектов. И сказать что например реалтайм гарантии линуха надежны я бы пока не рискнул, допустим. Это новый слабо изученный топик, в области где оптимизм ничем хорошим не заканчивается.
Это я говорю как тот кто линух в управляющие системы любит ставить. И в этом деле очень важно понимать свои лимиты и трезво оценивать возможности, иначе можно наломать много дров. Тот факт что система не падает еще не гарантия что все идет так как должно было.
> тщательной системы проверок всего софта и электронную начинку под неё?
Я думаю что авиаторы в целом в курсе проблем своей области и вон то решаемо. Но не просто и не быстро. И кой-какие воркфлоу, правила/стиль кодинга и проч в кернеле следовало бы несколько изменить имхо. Де факто линух только в начале своего пути в серьезные управляющие системы и прочие критичные штуки, типа бортовых компьютеров. Но да, он смотрелся бы интересно в ряде мест. Это многие имхо понимают.
> Все немного сложнее. Скажем если сервак тупанет на секунду - никто особо
> не заметит. Но самолет за это время пролетает довольно приличное расстояние.Ну это само собой. Естественно, в авионике нужно не обычное ядро использовать, а реального времени.
Как недавно сообщили, сабж использует Integrity.
Когда спутник висит на орбите и выясняется, что надо внепланово обновить ПО системы навигации, вот тут цирк начинается, на Земле и не снилось, а одно не верное движение и все нет спутника.
> Когда спутник висит на орбите и выясняется, что надо внепланово обновить ПО
> системы навигации, вот тут цирк начинается, на Земле и не снилось,
> а одно не верное движение и все нет спутника.NASA даже марсоходам софт обновляет. И никакого цирка в этом нет. Если проектировано нормальными инженерами, предусмотревшими такие операции.