F-22: «Хищники» опозорили Америку

au> От себя добавлю: и потому бесполезно на практике, как и БПФ таких размеров.

Ну да, ну да. "Раз я это не могу сделать - значит это никому и не нужно"

Кто тут недавно жаловался на нехватку специалистов по ассемблеру ?

au> Это не значит что программист-инженер должен с полпинка выдавать идеальный софт, но это значит что хороший инженер с хорошими инструментами (что по определению исключает языки выше С) должен делать хороший софт, т.е. когда он закончит, он должен сказать "я закончил — получите".
Современное общество не готово массово оплачивать такого специалиста. Разориться. Это в XIX веке было - господин инженер, по важности в обществе, был где-то между директором и губернатором.

au>> Отказоустойчивой, значит? А что же у них топливная система, связь, навигация, радар и всё остальное что под компом давеча отказали при перелёте через линию перемены дат?
Nikita> Вы читали отчёт ? Я вот пока нет. Всё что официально известно - у 6-ти машин какой-то отказ ПО навигационной системы. У остальных вроде всё в порядке было. Так что из Вашего длинного списка пока остаётся только навигация. В которой также есть компоненты с firmware.

А вперёд вас никому нельзя?

au> Проведу разъяснительно-воспитательную работу с автором алгоритма, который такое заказал. Только так...
Да не только так. Сделать можно и 0-20 бит в показателе. Например, сделать 2048 бабочек с обнулителями входов и буфер. Всё равно такое количество данных в кристалл сразу залететь не может, значит есть последовательная подача.

au> Вот чего нет, так это кооперации. И Серокой дал пример только что. Никто не собирается и не ищет способ сделать лучше. Ведь так заманчиво сбагрить проблемы соседям, сослаться на непреодолимые трудности и в конечном итоге облегчить себе так жизнь. И в этом программирующая общественность уверенно доминирует. Переделывать железо под драйверы — это не абсурд, а полный кретинизм.
Я вот не понимаю этой непоколебимой уверенности. Вы совершенно напрасно не допускаете что правка железа, в конечном итоге, может оказаться более дешевым и более правильным решением чем правка программ.

au> Только теоретически. На практике же нет. Баг-фри — это точное соответствие спецификации.

Ага-ага. Осталось самое элементарное - написать zero-defect спецификацию

au> язык, который даёт в руки все ресурсы системы вместе с ответственностью за их использование, или язык на котором проза каким-то образом управляет этими ресурсами с никакой гарантией надёжности...

Для больших проектов второй явно лучше. Бо написать zero-defect "управлялку" ресурсами гораздо дешевле, чем маяться с безответственным использованием ответственности разбросанным там и сям по миллиону строк кода. Переезд на другую платформу в этом случае также проще - меняем "управлялку" и всё.

hsm>> Вот до этого и осталось 1-2 поколения. А дальше - финишь
Balancer> Какая такая финишЪ?
"Кинематографическое качество." Как только будет достигнуто - дальше двигаться будет некуда. У ЦП такой планки нет в принципе.

au>> Пример из светлой юности. Лекция по конструированию, ведёт Инженер. (мой вольный пересказ)
au>> — Итак, что же значит технологичность. Вот, например, вы проектируете высокочастотный тракт на волноводах. Вам нужен некий резонатор, и коллега вам предлагает сделать резонатор в виде монолитного полого шара со сложной фигурной резьбой на внутренней его стороне. Это решение даст высокие характеристики, но как вы сделаете эту резьбу внутри монолитного шара?! Коллегу это не интересует, он же не конструктор. Для вас, конструктора, это решение абсолютно нетехнологично.
au>> От себя добавлю: и потому бесполезно на практике, как и БПФ таких размеров.
Вуду> - На самом деле для настоящего Инженера здесь встаёт лишь одна проблема: можно ли получить из двух половинок, которые потом свинчиваются/свариваются/склеиваются, шар, по требуемым свойствам не отличающийся от монолитного?


Один моделист сказал:"Если сможете склеить вместе квадратный пластик и предать ему форму шара то, выточить самолет не будет для вас сложностью", а это намного сложнее, чем собирать шар из двух половинок

au> А вперёд вас никому нельзя?

Здесь - наврядли. Не думаю что вот Вы, например, регулярно читаете даже Flying Safety Magazine...

*То есть я правильно понял, что отчёта Вы не видели ?

мужественный> Пардон, что вмешиваюсь в беседу программистов, но эту фразу надо будет непременно "влепить" разработчикам CAD/CAM/CAE/PDM/PLM, наипаче американским, как они уже достали своими недоделками и вумными рассуждениями о тяжёлой своей доле, за наш счёт разумеется.

Че ж сразу американским-то, а? Нынче одна из самых наикрутейших PLM-контор - вообще-то французская По части архитектурно-строительных САПР на технологическое лидерство претендует немецкая и венгерская, а вы все шишки на амриканские компании сыплете. К слову говря самый адекватный машинострительный комлекс CAD/CAM/CAE/PDM - именно американского производства (я про SolidWorks).

И насчет недоделок - вы думаете русские разработчик CAD/CAM/CAE/PDM (до PLM не доросли еще) производят доделки? Назовите кто - АСКОН, АДЕМ, Топ-Системы, моя недавняя вотчина ПроПро? Ню-ню...

И, наконец, сами-то много сумели? Или хотя бы пробовали?

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

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

au>> Мы не делим заслуги и не пинаем программистов. Речь о методах и отношении к инженерному делу. У программистов последние два пункта хромают на всю голову. Ты, как я понял, совершенно нерепрезентативен.
Mishka> Предмет у них уже сложнее. Старые методы не подходят.

Проблема в том что результаты "новых" не подходят. Мне не подходят. Строгим немым людям в форме тоже не подходят. Сделали вот (как его, забыл..) инспектора спутников, а он забыл как рулить. Я думаю что люди, которые деньгами рулят по подсказке финансового софта, тоже не поймут шутки "ой, вы только не волнуйтесь, у нас тут баг, щаз мы его..." Разобрались: говно в софте. Новые методы сказываются, ибо новое поколение делало. Такой вот reality check. А для бытовухи оно сойдёт конечно, висты-шмисты.
Кстати, прикол. Один пилот из тех Ф-22 связался с Локхид Мартин в полёте — думаю взял с собой в полёт спутниковый телефон, не иначе.

au>> Нормальный программист не знает и не хочет знать что такое ассемблер; а слово микрокод для него вообще пустой звук.
Mishka> Нормальный инженер не знает много чего из физики и не хочет знать. И спины для него пустой звук.

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

au>> плод не только работы этого программиста, но и серой массы, которой я ни грамма не доверю важное дело. Потому что серая масса не состоит на 100% из хороших программистов-инженеров,
Mishka> Но это же везде такая проблема. Процент хороших инженеров не может быть большим — по определению. А остальная масса и производит серые товары. Её, серой массы больше, а значит и произведёт она намного больше.

Инженер растёт с опытом, становится лучше. Программист (тот который не инженер) ждёт более заботливой версии компилятора и более мощного железа.

au>> Просто skill shortage, хоть убейся.
Mishka> Он везде.

Дык, а вот не все согласны..

au> Кстати, прикол. Один пилот из тех Ф-22 связался с Локхид Мартин в полёте — думаю взял с собой в полёт спутниковый телефон, не иначе.

Машина только-только осваивается ВВС. И инженеры LM входят в состав бригад технического обслуживания. А тут вообще первый заграничный вояж - в части куча народу "из фирмы". Так что пилот просто связался с базой по обычной связи.

au> Да. Но законы физики инженера дисциплинируют с нулевого возраста, и инженер не подумает поправить законы физики под свой не совсем удачный дизайн.

Эйнштейн вот поправил - очень даже хорошо получилось

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

Хе-хе, не знаете вы сколько человек-времени занимает тестирование сложного софта. Порой действительно дешевле железо новое сделать

hsm>> Я вот не понимаю этой непоколебимой уверенности. Вы совершенно напрасно не допускаете что правка железа, в конечном итоге, может оказаться более дешевым и более правильным решением чем правка программ.
Серокой> Правка железа - это новый цикл тестирования и запуск производства микросхем. И всё это стоит денег, и немалых. И времени по определению больше больше, чем уйдёт на то же тестирование ПО, поскольку плюсуется время изготовления микросхемы.
Можете привести это самое определение?
Представьте ситуацию: правка железа будет стоить вам N денег а правка программы - 3хN денег Какой вариант вы выберите?

au>>> Связь в том, что на ассемблере можно сделать баг-фри.
Balancer>> "баг-фри" можно на любом языке написать. Но не на любом это можно сделать просто Хуже ассемблера по этому показателю, пожалуй, только прямое программирование в машинных кодах
au> Только теоретически. На практике же нет. Баг-фри — это точное соответствие спецификации. В этой теме я подразумеваю встроенные и ответственные системы, вроде авионики.

Я вынужден вас расстроить, но и в авионике самолёта есть баги

au> Инженер не может абстрагироваться от законов физики, он в них живёт и действует. Он и не подумает о враппере для них. В этом кроется разница между инженерами и писателями технофэнтэзи.
Законы конечно он враппить не будет, а вот свое изделие сполшь и рядом. Никакой принципиальной разницы с программами.

hsm> "Кинематографическое качество." Как только будет достигнуто - дальше двигаться будет некуда. У ЦП такой планки нет в принципе.

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

au>> Кстати, прикол. Один пилот из тех Ф-22 связался с Локхид Мартин в полёте — думаю взял с собой в полёт спутниковый телефон, не иначе.
Nikita> Так что пилот просто связался с базой по обычной связи.

Вы признались что не читали, я читал. Зачем забивать эфир этими буквами?

Balancer> Рендеринг - это уже сегодня одна из не самых ресурсоёмких частей. В отличии от кино, в играх требуется эмулировать мир. А это - возрастание потребных ресурсов на многие порядки

Эмулировать - как показала практика ресурсов нужно много меньше, чем его визуализировать. Вот если симулировать...

au>> Только теоретически. На практике же нет. Баг-фри — это точное соответствие спецификации. В этой теме я подразумеваю встроенные и ответственные системы, вроде авионики.
sxam> Я вынужден вас расстроить, но и в авионике самолёта есть баги

Да я как-бы читал новости. Но количества...

В.М.> Эмулировать - как показала практика ресурсов нужно много меньше, чем его визуализировать. Вот если симулировать...

Ну так речь и идёт о том, что эмуляция приближается к симуляции

au>Разобрались: говно в софте. Новые методы сказываются, ибо новое поколение делало. Такой вот reality check. А для бытовухи оно сойдёт конечно, висты-шмисты.

Как часто это уже слыхано... "Раньше вода была гораздо мокрее." "Мне этих ваших новомодных штучек не надобно, я все на ассемблере запрограммирую". Типично, кстати. И объяснимо - нынешнее программирование предполагает непрерывное обучение. Специалист в области программирования обязан постоянно учиться, без отрыва от производства.

au>>> Только теоретически. На практике же нет. Баг-фри — это точное соответствие спецификации. В этой теме я подразумеваю встроенные и ответственные системы, вроде авионики.
sxam>> Я вынужден вас расстроить, но и в авионике самолёта есть баги
au> Да я как-бы читал новости. Но количества...

Так и раньше было. И радары отказывали, и чего только не было.

au>>Разобрались: говно в софте. Новые методы сказываются, ибо новое поколение делало. Такой вот reality check. А для бытовухи оно сойдёт конечно, висты-шмисты.
Сергей-4030> Как часто это уже слыхано... "Раньше вода была гораздо мокрее."

Болтаете ерунду.

MIB determined that one of the root causes of the mishap was an inadequate GN&C software development process
MIB determined that there was an inadequate, system-level integration process
MIB report clearly indicated that inadequate systems engineering (including a lack of implementation of software requirements, configuration control, validation of math models and testing) was a significant causal factor in the mishap

was a failure to implement existing (NASA) engineering requirements, standards and practices



Мало?