Компания General Dynamics C4 Systems (http://en.wikipedia.org/wiki/General_Dynamics_C4_Systems)&nb...и австралийский исследовательский центр NICTA (http://en.wikipedia.org/wiki/NICTA) открыли (http://sel4.systems/) под свободными лицензиями исходные тексты микроядра seL4 (https://github.com/seL4/seL4) (Secure Embedded L4), компоненты (https://github.com/seL4/l4v) математического доказательства его надёжности и сопутствующий код для построения высоконадёжных операционных систем. Ядро открыто (https://github.com/seL4) под лицензией GPLv2, а утилиты и работающий в пространстве пользователя код содержит как элементы под лицензией GPLv2, так и компоненты под лицензией BSD.Микроядро seL4 нацелено на предоставление повышенного уровня безопасности и надёжности для критически важных систем, используемых в авиации, медицине, финансовом секторе, энергетике и других областях, где необходима гарантия отсутствия сбоев. Корректность реализации seL4 в своё время была доказана (https://www.opennet.ru/opennews/art.shtml?num=23011) математически, что даёт основание считать решения на базе seL4 самыми надёжными в мире. Математическое доказательство надёжности свидетельствует о том, что seL4 полностью соответствует заданным на формальном языке спецификациям и гарантирует отсутствие ошибок, приводящих к проблемам с блокировками, переполнениям буфера, арифметическим исключениям и неинициализированным переменным. В своё время Агентство по перспективным оборонным научно-исследовательским разработкам США (DARPA) использовало seL4 для повышения защищённости ПО, используемого в военных беспилотных летательных аппаратах.
Архитектура seL4 примечательна (http://sel4.systems/FAQ/) выносом частей для управления ресурсами ядра в пространство пользователя и применения для таких ресурсов тех же средств разграничения доступа, как для пользовательских ресурсов. Для разработчиков предлагается компоненто-ориентированная платформа для разработки приложений CAmkES (http://sel4.systems/CAmkES/), позволяющая моделировать и создавать системы на основе seL4 в виде коллекции взаимодействующих между собой компонентов. Также поставляется (https://github.com/seL4) набор примеров и прототипов систем на основе seL4, подборка драйверов и библиотека для создания драйверов, порт Си-библиотеки Musl (https://www.opennet.ru/opennews/art.shtml?num=39365).URL: https://github.com/seL4
Новость: https://www.opennet.ru/opennews/art.shtml?num=40297
Сначала нужен список поддерживаемого оборудования
И список портиротированного ПО
У кого-то такая инфа?
У меня инфа. Поддерживается железо:
F-16, M1 Abrams, Piranha, MX, SAPS, MASP, GDMX, TDRSS.
Демократичненько
ссылку или бабабол
Да балабол, но все равно ржачно.
> У меня инфа. Поддерживается железо:
> F-16, M1 Abrams, Piranha, MX, SAPS, MASP, GDMX, TDRSSКлассно M1 Abrams, сервер, серверная и дизельгенератор в одном флаконе )))
Ога! Можно WoT гонять :)
> Ога! Можно WoT гонять :)Только тут подсказывают что для того чтобы гусеница за 30 секунд чинилась - надо технологии сильно заппгрейдить.
Не знаю как там у абраши и с наших православных танков 3/4 этого форума тупо трак от земли не оторвут :) Какой там заменить :)
Так я и говорю - технологии надо сильно прокачать. Ну там например выводок нанороботов, который гусеницу на месте пересобирать будут. Впрочем, при таких технологиях танки уже не требуются: наноботы могут ведь не только смонтировать гусеницу, но и размонтировать гусеницу на танке врага. Да и вообще весь танк.
да и самих врагов тоже, им пофигу, что ломать.
> да и самих врагов тоже, им пофигу, что ломать.Это наверное опционально, низкоприоритетная задача. Враги узрев такую разборку будут сpaть кирпичами и врядли будут испытывать чрезмерно воинственное настроение. Но если вдруг они окажутся чрезмерно тyпыми и не сделают ноги - можно и их до кучи.
вообще, всё наоборот: намного выгодней разломать врагов и оставить полезную технику на месте.впрочем, если у кого-то будут технологии такого уровня, а у других нет, и защиты тоже нет — то ни о каких врагах речь уже не идёт, только о «чего изволите, бвана?»
> Классно M1 Abrams, сервер, серверная и дизельгенератор в одном флаконе )))Боюсь стоимость владения вас не обрадует...
>У кого-то такая инфа?Да, у кого-то есть.
Ну беспилотники уже поддерживаются. Дело за малым.
про титаник тоже так говорили
Так все правильно - капитан и айсберг не были составными частями корабля, на них гарантия не распостранялась.
каким бы надёжным не был сейф, его всегда можно бросить в вулкан (с)
Т.е. не мне одному кажется, что математики что-то не учли???
Учли, и пофиксили в следующих релизах. Титаник, Олимпик и Британик так и плавали непатченные.
есть мнение, что говоруны эти были лицами заинтересованными
> даёт основание считать решения на базе seL4 самыми надёжными в мире.Никто не спорит что примитивный тасксвичер можно написать без багов. Теперь удачи написать без багов обвязку, без которой все это примерно столь же полезно как выключенный компьютер.
>> даёт основание считать решения на базе seL4 самыми надёжными в мире.
> Никто не спорит что примитивный тасксвичер можно написать без багов. Теперь удачи
> написать без багов обвязку, без которой все это примерно столь же
> полезно как выключенный компьютер.То есть ты хочешь сказать, что все ваши поделки априорно бажные? Я правильно тебя понимаю?
Я хочу сказать что все мало-мальски сложные программы апнриори бажные. И хрен вы их валидируете математически.
Зависит от инструмента, подхода к разработке, и человека. К критическим задачам нужно подходить скрупулёзно. Априори бажность - хорошая отговорка для тех кто проектирует лифты, корабли, самолёты, автотехнику, робототехнику. Баги бывают, чо. Невнимательность - всего лишь невнимательность, и ничего с этим поделать нельзя.
К критическим задачам надо подходить скурпулезно. Делая резервирование, проводя тщательное тестирование, используя статические анализаторы, чтобы указать человеку на подозрительные части кода и т.д. И при этом - учитывая, что узел таки имеет шанс отказать и планируя реакции на это - на разных ровнях системной иерархии.И мне очень жаль, что вы не понимаете, что баги - это не просто невнимательность. Как минимум - всегда будут прооблемы с непредсказуемум взаимодействием с программынм окружением, недопониманием спецификаций (в том числе теми, кто и составляет), не оправдавшимися ожиданиями к оборудованию и пользователю и так далее, и тому подобное. Никто не совершенен, и баги - просто результат этого несовершенства.
согласен, добавлю только, что эксперимент по созданию сверх надежного, но крайне минималистичного софта уже был - qmail. ИМХО, народ предпочитает постфикс.Есть такое правило - 20/80 - которое озвученно экономистом, но перефразировать и применить можно много к чему - 20 процентов программы (кода) удовлетворят потребности 80% пользователей. Если по этой логике построить кривую, то в определенный момент кол-во дополнительных проверок понизит скорость выполнения кода, а значит снизит "удовлетворенность", то есть 100% результ в принципе не достижим, а вариант с 99.97% чертовски дорог.
В данном случае разработчики решили пойти по довольно логичному пути - выкинуть все драйвера в юзер-спейс, ведь именно драйвера большая часть кода и именно они (она) содержат наибольшее кол-во багов, однако это означает, что программа-драйвер будет работать медленее, во-первых, во-вторых пока программа будет ждать в очереди на выполнение железка может и буффер переполнить, а это уже потеря данных, ну и самое вкусное, если программа-драйвер глюкнет и ядро ее прибьет, то обслуживаемая ею железяка может повиснуть без возможности переинициализации без оключения питания, которое в свою очередь может быть реализованно только при перезагрузке, так что какая разница - кернел паник или не паник если все равно ребут. На десктопах, конечно, сохраниться перед ребутом хорошо, но до десктопа этому ядру еще лет 30, а для серверов придумали транзакции.
Только одно, но ничто не мешает ядру не просто прибить драйвер, а перезапустить. А тогда разница очень большая.
Драйвер, может, и перезапустится, но перезапустится ли железка?
> Только одно, но ничто не мешает ядру не просто прибить драйвер, а
> перезапустить. А тогда разница очень большая.Железка и драйвер работают синхронно - перезапуск драйвера, в лучшем случае потеря данных, синхронизация с железкой это портянка кода который протестировать весьма проблематично...
в промышленности уже давно и на полную катушку используется резервирование, упал сервак, так есть другой, что кстате решает проблему с обновлениями, а вот супер стабильное ядро, что прекажете не обновлять или все равно дублировать, я не зря вспомнил про qmail, его не обновляют и новых плюшек там нет, то есть хорошо, что есть выбор, но это ровным счетом ничего не решает.
> данных, синхронизация с железкой это портянка кода который протестировать весьма
> проблематично...Особенно прикольно AMDшники GPU ресторят при сбоях. Они пытаются восстановить состоягние GPU. И зачастую это удается - все падает точно так же как до рестарта. И процесс повторяется. С другой стороны, если это добро выбросить - случится выпадение ядерных осадков...
скажи, ты говоришь так же, как и пишешь — монотонно, укладывая в одно предложение кучу несвязаных словосочетаний? если нет, то какого же чёрта ты пишешь так, что читать тебя почти физически неприятно и хочется отоварить молотком по черепу?
Насколько я понимаю, единственный более-менее надежный вариант реакции - громко умирать. Любые попытки перезапуска и восстановления состояния без выхода на уровень вышележащей системы слишком рискованны - потому что непонятно, откуда сбой вообще взялся и насколько поломано в данный момент окружение. И нет, вариант "перезапуск драйвера микроядром" - это не выход на уровень вышележащей системы. Как минимум - потому что ядро работает на том же железе. Корректный подход - сдохнуть, позволив забрать управление дублирующему узлу. А потом уже что-то будет пытаться востановить работу, перезапускаться, проводить тестирование и т.д. - автоматика или ремонтники.
> Только одно, но ничто не мешает ядру не просто прибить драйвер, а
> перезапустить. А тогда разница очень большая.По моим наблюдениям за ядром линукса это обычно так: встает колом железка, а потом драйвер ядра с переменным успехом пытается вправить ей мозг. А если GPU не получилось перезапустить - радости то с работающего драйвера? Картинки то все-равно не будет. ЧСХ такое можно и с модульным монилитом понаблюдать для самых разных железок.
Чтобы свойства seL4 были сколь-нибудь сохранены, его и запускать надо на каком-то убер-тривиальном ASIC где кроме примитивного RISC с полутора командами вообще ничего нет. Правда, не понятно что с ним потом делать, но об этом мы подумаем в другой раз...
> А если GPU не получилось перезапустить - радости то с работающего
> драйвера? Картинки то все-равно не будет. ЧСХ такое можно и с
> модульным монилитом понаблюдать для самых разных железок.Понятно, что если железка-дрянь, то АппаратноПрограммныйКомплекс тоже будет плох. Тем не менее, сейчас операционные системы универсальны => желательно закладываться и на хорошие железки, чтобы на них ОС тоже была полезна.
А так, в своё время были мониторы, которые можно было убить программно, потом исчезли.
С железом тенденция ровно обратная - становится быстрее-выше-сильнее-навороченнее-фичастее-быстрее... и глючнее. Достаточно посмотреть на дрова линуха и посмотреть сколько там вбито костылей и воркэраундов на все случаи жизни.Для начала - у CPU от AMD и Intel - обновляемый микрокод. Это чтобы можно было запатчить часть багов после выпуска чипа, не отправляя всю партию под пресс, что дорого и досадно. А если секцию ERRATA у даташитов читать - позеленеешь ненароком...
> 20 процентов программы (кода) удовлетворят потребности 80% пользователей.жаль только, что для разных пользователя эти двадцать процентов включают разные фичи.
> И мне очень жаль, что вы не понимаете, что баги - это
> не просто невнимательность.Просто невнимательность, но не просто. Не надо умных слов, друг. Люди делают не понимая что именно они делают также в области проектирования и программирования. Не надо оправданий, тем более из области философии и психологии, про несовершенство мироздания и ожидания. Рукожоп есть жопорук. Скажи про несовершенство строителю, что построил тебе дом. Или мостостроителям. Это не вопрос ожидания, а разумности. Есть области, где нужно быть не просто внимательным, а скрупулёзно-доебительно-двадцать-семь-раз-отмерившим, профи своего дела. В остальном конечно, большинство плодят баги. Но людей с такой философией нельзя подпускать написанию критичных программ. У них неверный подход в голове, не говоря уже про руки. Дядя Вирт писал немного о надёжности.
> прооблемы с непредсказуемум взаимодействием с программынм окружением
имхо, в критичных участках использовать целую ОС - неверно.
> Просто невнимательность, но не просто. Не надо умных слов, друг. Люди делают
> не понимая что именно они делают также в области проектирования и
> программирования. Не надо оправданий, тем более из области философии и психологии,А это не оправдания, это капитанинг. Иногда, даже если не хочется делать баг - он может всpaться. Человеческий мозг - не цифровой компьютер, поэтому не обладает идеальной надежностью и 100% воспроизводимостью работы.
> А это не оправдания, это капитанинг. Иногда, даже если не хочется делать
> баг - он может всpaться. Человеческий мозг - не цифровой компьютер,
> поэтому не обладает идеальной надежностью и 100% воспроизводимостью работы.А кусок кремния таки прямо обладает 100% надежностью и воспроизводимостью... Тото у третьих пней предусматривался вариант работы в режиме напоминающем RAID 1.
> А кусок кремния таки прямо обладает 100% надежностью и воспроизводимостью...Так его люди делали, со всеми вытекающими...
> Не надо оправданий, тем более из области философии и психологии, про несовершенство
> мироздания и ожидания.Про философию я соглашусь, она здесь неуместна, но игнорировать психологию совсем не стоит. Психология может вносить и вносит свои погрешности в процесс мышления человека. Кроме того, ограничения "вычислительных способностей" мозга -- это не вопрос ли психологии?
Есть мнение, что человек вплотную подошёл к верхней планке сложности разрабатываемых им систем. Я поясню. Человек непосредственно, без всяких хитроумных заморок типа разделения задачи на подзадачи, может решать лишь весьма простые задачки. Разделение задачи на подзадачи позволяет решать более сложные задачи, но это костыль, потому что попадаются задачи, которые упорно не хотят делиться на подзадачи. С этими проблемами справляются используя дополнительные костыли, помогающие бить задачу на части. Но это всё костыли, и практическая неизбежность багов говорит нам именно об этом. Некостыльным способом решать такие задачи, было бы увеличение "iq" разработчика (не в смысле умения проходить тесты на iq, а в смысле способности решать сложные задачи). Тренировки мозга, эволюция или искусственный интеллект -- вот где могут скрываться некостыльные решения. Причём тренировки мозга -- вряд ли смогут решить проблему, лишь снизить её остроту.
PS. И, простите что вмешиваюсь, но вы спорите с Анонимом, по-моему, ни о чём. Вы говорите о том, что программист, проектирующий/пишущий не должен опускать руки в борьбе с багами; Аноним же говорит о том, что подобный настрой в работе не избавит от багов на 100%. И, по-моему, вы оба правы.
> Кроме того, ограничения "вычислительных способностей" мозга -- это не вопрос ли психологии?Нэт, это физиология изучает.
> Человек непосредственно, без всяких хитроумных заморок типа разделения
> задачи на подзадачи, может решать лишь весьма простые задачки.Хвать уже муть писать, спутали всё. Алгоритмы с рефлексам, задачи с инстинктами.
Весь тред, да и все комменты в теме - х...ета полная, ничего общего не имеющая с реальностью.
Ну чесслово - глупее идиотов выглядят, только размышляющие идиоты.
> Хвать уже муть писать, спутали всё. Алгоритмы с рефлексам, задачи с инстинктами.Ну раскройте глаза нам глупым или, как говорится, GTFO.
Впрочем я уверен, что вы просто недостаточно интересовались причинами возникновения тех или иных ошибок, и уж во всяком случае не интересовались тем, что говорят об этом другие, в том числе и те, кто по роду своей деятельности изучает ошибки, которые мозг совершает *систематически*. Если интересно, то вот популярное изложение объясняющее на примерах, что такое когнитивное искажение: http://lesswrong.ru/w/Когнитивные_искажения
Обратите там внимание на опыт с рулеткой и прочие эксперименты демонстрирующие т.н. "якорение", и задайте себе после этого вопрос: можете ли вы вообще доверять своему мозгу? То есть другие когнитивные искажения тоже заслуживают внимания, но там хоть какие-то пути просматриваются как можно внести поправку, корректирующую деструктивное влияние мозга на процесс мышления, "якорение" же не позволяет даже этого.
>> Не надо оправданий, тем более из области философии и психологии, про несовершенство
>> мироздания и ожидания.
> Про философию я соглашусь, она здесь неуместна, но игнорировать психологию совсем не
> стоит. Психология может вносить и вносит свои погрешности в процесс мышления
> человека. Кроме того, ограничения "вычислительных способностей" мозга -- это не вопрос
> ли психологии?не нужно думать что знания нашей психики завершены. То что мы ошибаемся не означает что мы можем только ошибаться. Что ошибки неизбежны. Наша инерция не даёт осознавать проблемы и мы выдумываем себе оправдания, вроде простых "истин": все ошибаются, ничто не идеально.
> PS. И, простите что вмешиваюсь, но вы спорите с Анонимом, по-моему, ни
> о чём. Вы говорите о том, что программист, проектирующий/пишущий не должен
> опускать руки в борьбе с багами; Аноним же говорит о том,
> что подобный настрой в работе не избавит от багов на 100%.
> И, по-моему, вы оба правы.хорошо тогда :)
> Априори бажность - хорошая отговорка для тех кто проектирует лифты,Вот у лифта может быть дубовый алгоритм, который воможно провалидировать математически. Хотя у современных лифтов это уже не факт - в больших зданиях лифты принимают решения куда ехать исходя из количества людей и оптимальности поездки и там уже целая отдельная наука.
> корабли, самолёты, автотехнику, робототехнику.
А вот у этих бывает и сложный софт и на этот случай предпринимаются специальные меры.
> Баги бывают, чо. Невнимательность - всего лишь невнимательность,
Людям свойственно ошибаться. И ничего с этим поделать нельзя. Но это можно учесть. Есть множество инженерных принципов. Например, принципы FAILSAFE. Или вон у одного из боингов бортовые компьютеры созданы из разной комплектухи, а софт писан 2-я разными командами на 2-х разных ЯП. Это чтобы ни при каких обстоятельствах не случилось так что оба компьютера сразу словили один и тот же баг, как раз. То-есть, мысль о существовании багов не только допущена, но и приняты превентивные меры нацеленные на то, чтобы пилоты даже в этом случае остались с как минимум 1 работоспособным компьютером.
> Людям свойственно ошибаться.и свойственно _не_ ошибаться.
> И ничего с этим поделать нельзя.
можно, они же знают что им свойственно...
> Но это можно учесть. Есть множество инженерных принципов.
Хорошо. Это разумно.
> Или вон у одного из боингов бортовые компьютеры созданы из разной комплектухи, а софт
> писан 2-я разными командами на 2-х разных ЯП.Тоже хорошо. Только бы не делали три, понимаешь? На случай если первые два ку-ку. А потом четыре, на случай если первые три ку-ку.
> и свойственно _не_ ошибаться.Только когда вся программа и рантайм - размером с hello world, да еще транслятор под стать.
> можно, они же знают что им свойственно...
Ни разу не видел уникомов, которые бы писали большие программы без ошибок. Ну разве что роботов припахать. Но тут есть подстава - первую версию AI могут сделать только люди, а стало быть она будет с багами...
> Тоже хорошо. Только бы не делали три, понимаешь? На случай если первые
> два ку-ку. А потом четыре, на случай если первые три ку-ку.Для самолетов нормально делать по 2-4 резерва для подсистем, отказ которых что-то решает. Иногда и это кстати не помогает - у одного самолета с 3-я двигателями развалившийся хвостовой двигатель разнес все 3 гидролинии. Конец немного предсказуем. ЧСХ, работу над ошибками делали - и гидролинии по другому стали укладывать, и от потенциальных обломков кожухом защитили. Но все-равно периодически как-то так оказывается что где-то вcpaaлся баг...
>> и свойственно _не_ ошибаться.
> Только когда вся программа и рантайм - размером с hello world, да
> еще транслятор под стать.тогда очевидно что программа должна стремиться к выполнению желательно одной функции, но выполнять её безупречно.
> тогда очевидно что программа должна стремиться к выполнению желательно одной функции, но
> выполнять её безупречно.Не обязательно. Но программа должна быть или простой как топор, или должно быть предусмотрено что она может сбойнуть и это не должно вести к фатальным последствиям.
>> тогда очевидно что программа должна стремиться к выполнению желательно одной функции, но
>> выполнять её безупречно.
> Не обязательно. Но программа должна быть или простой как топор, или должно
> быть предусмотрено что она может сбойнуть и это не должно вести
> к фатальным последствиям.не обязательно, но стремление хорошее, даже лучшее из возможных, принимая во внимание сказанное тобой, скромное имхо.
>> Априори бажность - хорошая отговорка для тех кто проектирует лифты,
> Вот у лифта может быть дубовый алгоритм, который воможно провалидировать математически.
> Хотя у современных лифтов это уже не факт - в больших
> зданиях лифты принимают решения куда ехать исходя из количества людей и
> оптимальности поездкиКакая в пязду оптимальная поездка, на несвязаном графе с последовательными узлами?
Ты недооцениваешь лифты. Даже в простом лифте высотных зданий и офисов люди указывают вверх им или вниз. Так что из очевидных оптимизаций - как минимум лифт может пытаться ехать последовательно вверх и последовательно вниз. А если лифт уже полный - можно и не останавливаться, даже если и вызвали, например. А в чем пойнт похлопать дверями и уехать дальше? В более продвинутых может учитываться еще и количество ожидающих. А иногда и на какой этаж они хотят. А иной экспонат нынче уже норовит заняться и бизнес аналитикой: делается распознавание морды лица, а потом "Ага, это - хрен Вася из 100500-го офиса, он по статистике обычно ездит с 30-го этажа на 105-й".
> То есть ты хочешь сказать, что все ваши поделки априорно бажные? ЯВаши тоже. _Все_. http://lib.ru/ANEKDOTY/errors.txt_with-big-pictures.html
+++Чем больше программист делает ошибок, тем быстрее он делается ученым.
> Ваши тоже. _Все_. http://lib.ru/ANEKDOTY/errors.txt_with-big-pictures.htmlЧСХ, в каждой шутке есть доля правды :).
зато дарповы гранты.
Если отказаться от бесполезного bloatware (kde/gnome/systemd/etc) с кучей модных фишек, а решать реальные узкоспециализированные задачи, то все получится. Например, система управления зажиганием ДВС (реальное время, счет на микросекунды) может уложиться в 1000 строк на C для atmega8 и еще успевать выводить статистику на экран.
> Если отказаться от бесполезного bloatware (kde/gnome/systemd/etc) с кучей модных фишек,
> а решать реальные узкоспециализированные задачи, то все получится. Например, система управления
> зажиганием ДВС (реальное время, счет на микросекунды) может уложиться в 1000
> строк на C для atmega8 и еще успевать выводить статистику на
> экран.Это объясняет и оправдывает тысячи дистров линя?
Угу. А потом вам понадобится какая-то хитрая алгоритмика для экономии топлива. А потом - дополнить её для снижения выбросов. А потом еще что-то... А потом получится "KDE, версия для системы зажигания ДВС". Вероятнее всего - разложенная на несколько камней чтобы удержать-таки те самые микросекунды, что её ни разу не упростит.Я не против избавления от bloatware (еще б я был против - сам на notion сижу и mupdf погоняю), но не стоит съезжать в сторону аскетичного ничего не умеющего кода. Тот же KDE громоздок не потому, что много фич, а потому что он громоздок, akonadi - тому свидетельство. Ну как можно было умудриться сделать простейшую хранилку контактов и прочего такой монструозной? А всё потому, что по факту весь этот софт - монолитен. В том смысле, что для того, чтобы заменить, удалить или добавить любой компонент нужны приличные усилия и знания. Было бы оно по простоте как писание скриптов с пайпами или как рисование в какой-нибудь dataflow-тулзе - был бы миллион разных вариантов, из которых выросло бы что-то вменяемое.
> Угу. А потом вам понадобится какая-то хитрая алгоритмика для экономии топлива. А потом - дополнить её для снижения выбросов. А потом еще что-то... А потом получится "KDE, версия для системы зажигания ДВС". Вероятнее всего - разложенная на несколько камней чтобы удержать-таки те самые микросекунды, что её ни разу не упростит.Вот это и есть overengineering ибо дальнейшее усложнение алгоритмов повышает сложность практически по экспоненте и также снижает стабильность и предсказуемость. Выигрыш при этом максимум 5% по эффективности и то в идеальных условиях на новой машине, пока естественный разброс при износе узлов его не перекрыл. Гляньте ecomodder.com, там весит топ по топливной экономичности машин и большинство из них до 2000-го года.
Выигрыш - в том, что ты продашь больше машин, показав людям эту экономию или это уменьшение выбросов.А вообще - не стоит цепляться к примеру. Речь шла о том, что усложнение систем - штука повсеместная и естественная. Точно так же, как монолитные материалы уступают место композитам, например - от лыж до домов. Точно так же, как вместо очага с поленьями сейчас имеем автоматические котлы с хитрыми форсунками, автоматикой и черт знает чем еще. Также как вместо полоски железа в современных ножах - порошковая сталь. И так далее, и тому подобное. И с "простейшей автоматикой" то же самое - выше где-то пример с лифтами уже приводили. С алгоритмикой работы отопления и вентиляции - то же самое, всё сложнее становится. Везде так.
> Речь шла о том, что усложнение систем - штука повсеместная и естественная.Детский садик Ромашка.
Панимаешь в чём вся х..ня - доступные материалы - для говна,
говно не должно жить в каменном доме, с камином.
В доме говна - нужны системы кондиционирования и вентиляции.
Говно должно думать, что оно не говно. Для этого само говно,
производит для говна, продукцию из/на говне.
В основной массе, говно знающие, что делает говно, само верит
в то, что производит. И начинает думать, что если каждое говно
покупает, то, чем я хуже остального говна.Говну не нужен дом из мрамора, гавну нужен просто дом.
Газбетон, ДСП, ПВХ, ... - типичный состав дома говна.Так же говно, покупает лыжи Salomon за 1500$ и ботинки к ним за 3000$,
правда у говна даже нет 3-ого разряда по ОФП.
> Точно так же, как вместо очага с поленьями сейчас имеем автоматические котлы с хитрыми форсунками, автоматикой и черт знает чем еще. Также как вместо полоски железа в современных ножах - порошковая сталь. И так далее, и тому подобное. И с "простейшей автоматикой" то же самое - выше где-то пример с лифтами уже приводили. С алгоритмикой работы отопления и вентиляции - то же самое, всё сложнее становится. Везде так.Везде очень по-разному. Я в курсе про котлы/вентиляцию/etc. Там также все неоднозначно: многие до сих пор предпочитаю системы отопления независящие от электроэнергии. Они самые безотказные, но сложнее в проектировании, дороже и в большинстве своем имеют немного более низкий КПД. Все же попытки иначе сжечь твердое топливо с применением различной автоматики не дают существенного выигрыша в правильно спроектированной системе отопления.
Удешевлении технологии и маркетинг отнюдь не стремятся сделать вещь лучше. Как вы и сами отметили, производители они хотят больше продать и им не выгодно делать вещи с длительным сроком эксплуатации.
В каждом отдельном случае нужно взвешивать, что реально даст введение той или иной технологии, насколько она безотказна и ремонтно пригодна и даст ли вообще какие либо существенные преимущества.
> Гляньте ecomodder.com, там весит топ по топливной экономичности машин и большинство из них до 2000-го года."Невидимая рука рынка" как бы намекает - зачем тратиться на топливную экономичность, когда можно потратить в 10 раз меньше на пиар и хомячки все равно всё купят.
> А всё потому, что по факту весь этот софт - монолитен. В том смысле, что для того,
> чтобы заменить, удалить или добавить любой компонент нужны приличные усилия и
> знания.И вот тут мы опять смотрим на Хы с разными WM. :-)
> И вот тут мы опять смотрим на Хы с разными WM. :-)а также на никсовую консоль и старый добрый принцип «одна задача — одна программа». но всё это неимоверно сложно для ЦА всяких DE.
> Если отказаться от бесполезного bloatware (kde/gnome/systemd/etc) с кучей модных фишек,А также выбросить GPU со спеками на 900 страниц, чипы беспроводной сети у которых драйвер на 70% состоит из воркэраундов их багов и попыток развесить чип с минимальными потерями, ну и все такое прочее :).
> А также выбросить GPU со спеками на 900 страниц, чипы беспроводной сети
> у которых драйвер на 70% состоит из воркэраундов их багов и
> попыток развесить чип с минимальными потерями, ну и все такое прочее
> :).Да нужно выбрасывать или делать их совершенно независимыми узлами, дабы в случае их подвисания основная часть могла нормально функционировать дальше. Меня не вдохновляет перспектива сбоя системы жизнеобеспечения (если я или кто-то из людей мне небезразличных окажется от нее зависим) только по тому, что кто-то решил, что без красивого 3d интерфейса с 120fps уныло и куда веселее соединить несколько важных модулей по wi-fi.
> Да нужно выбрасыватьНужно? Выбрасывайте, разрешаю.
> или делать их совершенно независимыми узлами,
Как вы себе это представляете? Вот хочется вам картинку на экран рисовать - попробуйте при этом от GPU не зависеть, да? Или там при кидании пакетов по сети - от чипа сетевки. Или там при записи на диск - от чипа контроллера на мамке, чипа на диске, немеряной фирмвари накопителя и что там еще. Сферическое железо в вакууме это круто, но если например у вас отвалился диск - как вы себе представляете продолжение работы чтобы софт не заметил отвал диска?
>[оверквотинг удален]
> Нужно? Выбрасывайте, разрешаю.
>> или делать их совершенно независимыми узлами,
> Как вы себе это представляете? Вот хочется вам картинку на экран рисовать
> - попробуйте при этом от GPU не зависеть, да? Или там
> при кидании пакетов по сети - от чипа сетевки. Или там
> при записи на диск - от чипа контроллера на мамке, чипа
> на диске, немеряной фирмвари накопителя и что там еще. Сферическое железо
> в вакууме это круто, но если например у вас отвалился диск
> - как вы себе представляете продолжение работы чтобы софт не заметил
> отвал диска?Аноним, съибни, а! Ну лошара же последний.
> Ну лошара же последний.Отправь СМСку с текстом "не лох!" на короткий номер. Ведь чем больше СМС ты пошлешь, тем больше ты не лох :).
>> или делать их совершенно независимыми узлами,
> Как вы себе это представляете?Точно также как строится микроядерная ОС.
Есть контроллер с основной программой, простой идеально отлаженный и проверенный. Он управляет остальными узлами. В случае зависания одного из узлов контроллер его перезапускает. В случае отказа узла, контроллер задействует дублирующий узел. Узлы естественно с hotplug.
> Точно также как строится микроядерная ОС.Ну да, то-есть сферическое железо в вакууме, которое никто никогда не увидит, кроме десятка операторов ядерных реакторов на всю планету.
> зажиганием ДВС (реальное время, счет на микросекунды) может уложиться в 1000
> строк на C для atmega8А допотопные версии зажигания были и вовсе механическими. Ну вот вы и замените компьютер на счеты, их хрен завесишь без аппаратных жульничеств.
> и еще успевать выводить статистику на экран.
Зато считает с комариной скоростью, да и сколь-нибудь нормальный интерфейс пользователя отрисовать не способна. Каждому свое. Не всем надо супер-хард-реалтайм и убер-мега-гипер-надежность ценой нагибания всех остальных свойств.
Спору нет, автомобиль из титана сантиметровой толщины будет сложнее разбить. А еще он будет стоить как самолет, обладать погаными разгонными характеристиками и выпускаться в количестве 5 штук в год, ибо поди еще обработай этот чертов титан...
> А допотопные версии зажигания были и вовсе механическими. Ну вот вы и
> замените компьютер на счеты, их хрен завесишь без аппаратных жульничеств.Ненужно передергивать. Есть этап усовершенствования системы, после которого дальнейшее совершенствование практически ничего не дает кроме усложнения, снижения надежности и ремонтопригодности. Я привел реальный пример с ДВС. Механическое зажигание существенно проигрывает микроконтроллеру как по надежности, так и по точности. Но дальнейшие увеличение точности не дает ничего.
>> и еще успевать выводить статистику на экран.
> Зато считает с комариной скоростью, да и сколь-нибудь нормальный интерфейс пользователяДля вывода интерфейса подключите планшет/телефон. Сохранится надежность там где она реально необходима и получите красивый интерфейс.
> Ненужно передергивать. Есть этап усовершенствования системы, после которого дальнейшее
> совершенствование практически ничего не дает кроме усложнения, снижения надежности и ремонтопригодности.А тут тоже зависит от. Что понимать под ремонтом? Возможность сделать радиолампу на замену сгоревшей в гараже? Возможность перепаять транзистор? Замена стандартной микросхемы логики? Смена сбойнувшего проца? Вынимание сервера из стойки и замена на такой же, но исправный? Где та грань?...
> А тут тоже зависит от. Что понимать под ремонтом? Возможность сделать радиолампу
> на замену сгоревшей в гараже? Возможность перепаять транзистор? Замена стандартной микросхемы
> логики? Смена сбойнувшего проца? Вынимание сервера из стойки и замена на
> такой же, но исправный? Где та грань?...Зависит от условий эксплуатации и целесообразности. Например на сервере многие части можно заменить на горячую, а в ноутбуке наоборот заменить видеокарту весьма проблемно. Конструкция настоящего джипа должна быть простой и очень надежной, позволять ремонт в поле, без стендов диагностики и сложного инструмента. Мотор гоночного болида наоборот настраивают на дорогих стендах и выбрасывают после гонки.
> Зависит от условий эксплуатации и целесообразности.Вот тут мы и приходим к самому главному. Да, три гидролинии в самолете - имеют некий смысл. А вот прокладывать в обычной хате водопровод с троекратным резервированием по принципу "а вдруг сломается?!" - ну вы поняли. Сабж в большинстве применений имеет какой-то такой же смысл: много лишней возни при неоправданно скромном выигрыше.
> Например на сервере многие части можно заменить на горячую,
> а в ноутбуке наоборот заменить видеокарту весьма проблемно.Нынче все проще - удвигают виртуализатором/контейнеризатором на живую VM/контейнер на соседний агрегат, а проблемный можно совсем выключить, сделать с ним все что надо и потом вернуть как было. А юзеры ничего и не заметят.
> Конструкция настоящего джипа должна быть простой и очень надежной, позволять ремонт
> в поле, без стендов диагностики и сложного инструмента. Мотор гоночного болида
> наоборот настраивают на дорогих стендах и выбрасывают после гонки.А сабж просто телега и 4 колеса, с аргументом что так уж точно ломаться нечему. А как там в вас двигатель и подвеска (if any) будут работать - разработчики шасси вообще не отвечают.
> А вот прокладывать в обычной хате водопровод с троекратным резервированием по принципу "а вдруг сломается?!" - ну вы поняли.Обычно в квартире ставят шаровый кран на вводе и перед каждой точкой разбора. Это дает возможность перекрыть потекший кран на кухне и продолжать пользоваться туалетом, а также менять разводку в квартире, не перекрывая во всем подъезде/доме воду.
Я вот до сих пор не могу понять почему массовые автомобили не выпускают из алюминия?..
> выпускают из алюминия?..Потому что он мягкий как черти что, и при ДТП из юзера будет фарш. Обратите внимание чем обычно заканчиваются авиакатастофы...
>> выпускают из алюминия?..
> Потому что он мягкий как черти что, и при ДТП из юзера
> будет фарш. Обратите внимание чем обычно заканчиваются авиакатастофы...Скорее, потому что дорогой. Мягкость и разушаемость материалов при аварии наборот плюс, т.к. деформацией гасится энергия, которая иначе бы передалась на пассажиров и водителя.
как я понимаю микрокод (и аппаратный алгоритм) процессора по сути компонент тасксвитчера?
И ошибки в микрокоде никто не отенял, во всяком случае для процессоров, в которых он есть.
Какой тогда смысл в сверхнадежной системе?
Гг. Осталось теперь математически доказать надежность всех остальных сервисов, которые делаю этот обглодышь минимально юзабельным.
> Гг. Осталось теперь математически доказать надежность всех остальных сервисов, которые
> делаю этот обглодышь минимально юзабельным.Летают и работают. А у вас в протоны датчики уебиметром заколачивают. Чья б мычала...
Что доказывает качество конструкции и огромный запас прочности, на фоне которого, воздействие кувалдометром просто ничтожно.
ровно до тех пор, пока датчик вверх ногами не прикувалдят
> Летают и работают.Конкретно с seL4 летает, вероятно очень мало всего.
> А у вас в протоны датчики уебиметром заколачивают.
А это аппаратный баг, от него никакое микроядро не спасет.
Ща поверх него запилят "сверхнадёжное" ПО на JavaScript и HTML5.
Надо еще доказать корректность компилятора которым это все собирается.
А ещё математически доказать 100% надёжность и корректность работы процессоров, на которых это ядро выполняется.
>Надо еще доказать корректность компилятора которым это все собирается.
> http://compcert.inria.fr/А что, сам на себе без багов он писаться не захотел? А то он на ocaml завязан и что там еще. А кто будет проверять проверяющего?
еще одно ядро
там кода кот наплакал. код, конечно, легко читается и всё такое, но там ничего особо и нет. плюс оно, как я понимаю, не реалтайм.
ну так правильно, с тяжолым ядром в верх не полетишь, избавляются от груза
> там кода кот наплакал. код, конечно, легко читается и всё такоеТак в этом то и весь пойнт сверхнадежных - надо спихнуть все проблемы на других, а моя хата с краю, ничего не знаю. Люди этот сверхнадежный принцип уже столетиями используют ;].
> Так в этом то и весь пойнт сверхнадежных - надо спихнуть все
> проблемы на других, а моя хата с краю, ничего не знаю.
> Люди этот сверхнадежный принцип уже столетиями используют ;].Нет, здесь принцип не бери на себя большую ответственность, чем реально можешь потянуть. Если каждый модуль такой системы будет его передерживаться, то можно получить действительно стабильную систему. Вопрос остается с производительностью: модулей будет очень много и вероятно существенный процент cpu уйдет на пересылку сообщений между ними.
> Нет, здесь принцип не бери на себя большую ответственность, чем реально можешь
> потянуть.Ну так я и говорю - для вычислений большинства человекам хватит деревянных счет. Они не глючат, да и сломать еще надо постараться.
> GPLv2, так и компоненты под лицензией BSDФранкенштейн
> применяет seL4 для повышения защищённости программных систем, используемых в военных беспилотных летательных аппаратах.Персиянские операторы "Автобазы" подтверждают.
Ну что, ждем новости типа: "В ядре seL4 обнаружена критическая уязвимость ...".Хотя думаю, что такое мало вероятно скорее по причине того, что это ядро используют 2 с половиной человека, а еще меньше людей пытаются его вольно или невольно сломать.
И да, кстати, то, что ядро формально соответствует спецификации, не гарантирует, что в спецификации могут ошибки.
> не гарантирует, что в спецификации могут ошибки.Да-да-да, вполне возможно, что ошибки не могут в спецификации.
> Открыт код сверхнадёжного микроядра seL4Ну всё, после этого Танненбаум и Торвальдс стоят в сторонке и, обнявшись, плачут навзрыд.
Просто офигительная новость. Актуальное микроядро под GPL лицензией, да еще и нашедшее реальное применение - это то, что когда-то не хватило GNU.
К сожалению, сейчас оно не подойдет для GNU, так как нужна лицензия GPLv3+, иначе им нет смысла развивать платформу, которую могут тивоизировать.
где то уже читал про математическое доказательство и микроядро, и при чем недавно ...
> где то уже читал про математическое доказательство и микроядро, и при чем недавно ...если читал там, где "где-то" пишут без дефиса, а "причём" раздельно, то это был дилетантский бред
Ну чего набросились, парень радуется, что читать научился. Следующий этап - научиться писать!
Кажется беспилотник уже ломали в 2012 году.
Уверены они что система надежная?
http://xakep.ru/news/58149/
По сути они заглушили сигналы GPS и подменили их своими. Никакого взлома тут не было - обычная глушилка. Сейчас американцы как раз работают над мегаточными гироскопами, которые будут позволять выдерживать направление, не используя показания GPS.
> Сейчас американцы как раз работают над мегаточными гироскопами...Хорошо бы, ибо - тупик :-| ... да вот только в отличае от тебя - амеры не дураки :-(
PS: Гороскопы времён WWII позволяли работать тем стратегам ночью. С точностью до города, да :) но дык больше полувека прошло уж как ...
> PS: Гороскопы времён WWII позволяли работать тем стратегам ночью.Ну, так все правильно - днем же звезд не видать. Как же с гороскопом без звезд-то работать. А стратеги, видно, те еще астрологи...
> Ну, так все правильно - днем же звезд не видать. Как же
> с гороскопом без звезд-то работать. А стратеги, видно, те еще астрологи...Вот немецкая разведка с помощью форса гороскопов сорвала отступление французских войск...
Что-то не компилится.
> as: unrecognized option '-mcpu=cortex-a9'
Там надо исправить: '-mcpu=microwave'
> Там надо исправить: '-mcpu=microwave'Судя по вышеизложеннному, -mcpu=F-16.
Ну если ты пытаешься заставить ассемблер с компилировать код с оптимизацией под ЦП, то помочь тебе нечем.
Если там не Systemd то ненужно. Ведь всё, на чём нет Systemdб крутые хакеры объявляют устаревшим и не модным.
Пусть Поттер это генералу Динамиксу в лицо скажет! >/<
А была ли доказана безошибочность программ, которые использовались при провекри безошибочности?
А была ли доказана безошибочность программ, которые использовались при проверке безошибочности программ, которые использовались при проверке безошибочности?
Нет не была. Почему тест крэшился :))))
Чем оно надёжнее проверенного Windows Core?
> Чем оно надёжнее проверенного Windows Core?Чем windows core.
Рилтайм от блекбери круче, инф100!1 да и кореос торт а не печенько рекламное
Это что попытка диверсии типа программы "Звездных войн"?
> Это что попытка диверсии типа программы "Звездных войн"?Звери, а не люди: провоцируют вероятного противника писать софт вместо того, чтобы менять нескучные обои в своем болгеносе.