Казалось бы процесс производства софта гораздо более короткий чем при проектировании железа или какого-либо устройства.
Можно легко внести изменение и протестировать, в отлчии от той же электрической схемы.
Т.е. ПО можно за одно и тоже время проверить и улучшить во много раз больше чем железку.
И ПО должно быть в итоге намного надежнее железа.
При этом часто встречается в компаниях разделение программистов на тех кто пишет софт ( добавляет фичи, фиксит баги ) и тех кто его поддерживает ( фиксит критичные баги в срочном порядке ).
Причем некоторые крупные компании ( где ошибки в ПО сильно критичны ) берут инженеров других компаний, которые фиксят критичные баги которые возникают в процессе работы.
Почему нет критичных багов в релизных процессорах, материнских платах, компьютерах ? И в компаниях обычно нет инженера Интел который сидит и поддерживает их процессор.
Как правило все ошибки идут уже на уровне драйверов и софта.
Как разработчики железа при той же периодичности крупных релизов ~раз в 1 год добиваются надежной работы, хотя их цикл внесения изменений намного дольше.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, GarryIV, Вы писали:
GIV>Здравствуйте, okon, Вы писали:
O>>Почему нет критичных багов в релизных процессорах, материнских платах, компьютерах ? GIV>Нет, совсем нет, ни одного.
Ну познается в сравнении, по сравнению с софтом — никогда.
На своей истории я много раз сталкивался с критичными ошибками в софте — код программы переставал неожиданно работать, при этом сам код программы не повреждался.
При этом с железом такого не наблюдается ( если конечно оно физически не вышло из строя = изменение кода программы ).
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Ну познается в сравнении, по сравнению с софтом — никогда. O>На своей истории я много раз сталкивался с критичными ошибками в софте — код программы переставал неожиданно работать, при этом сам код программы не повреждался. O>При этом с железом такого не наблюдается ( если конечно оно физически не вышло из строя = изменение кода программы ).
Количество программ с которыми ты имел дело как бы на несколько порядков больше.
ЗЫЖ У меня модуль wi-fi в ноуте глючит, это считается?
Элементарно, Ватсон.
Разработчики железа не пишут на JS, Python, C++ прочей ненадежной лабуде.
Чтобы писать надежные программы, умолчания должны быть ЗАПРЕЩЕНЫ от слова совсем.
За неявные преобразования — РАССТРЕЛ.
За неявные переходы при обработке исключений — бессрочная каторга в Сибири...
И что мы видим в результате?
А видим мы Оберон, RUST и Go.
Но даже ты, скажешь, что Оберон — это отстой...
А вот разработчики RUST через десятки лет после создания Оберона пришли фактически к тому же.
А разработчик Go вообще закончил виртовскую школу. Хоть и работает в гугле.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, GarryIV, Вы писали:
GIV>Здравствуйте, okon, Вы писали:
O>>Ну познается в сравнении, по сравнению с софтом — никогда. O>>На своей истории я много раз сталкивался с критичными ошибками в софте — код программы переставал неожиданно работать, при этом сам код программы не повреждался. O>>При этом с железом такого не наблюдается ( если конечно оно физически не вышло из строя = изменение кода программы ).
GIV>Количество программ с которыми ты имел дело как бы на несколько порядков больше.
Не уверен, в моем списке программ наверное штук 20-30. При этом в конкретном компьютере железок того же порядка.
От сменных модулей — каждый модуль еще состоит из частей в итоге 20-30 наберется.
При этом я еще пользуюсь кучей железок — телефоны и пр.
GIV>ЗЫЖ У меня модуль wi-fi в ноуте глючит, это считается?
Зависит от того из-за чего глючит, если от поломки например у тебя там контакт поврежден механически ( = изменение логики работы ) то не считается.
И в чем глюк заключается — если этот глюк блокирует тебе работу, то да.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Не уверен, в моем списке программ наверное штук 20-30. При этом в конкретном компьютере железок того же порядка.
Уверен на 100%, что одних драйверов ты используешь больше 20-30. Потом загляни в диспетчер задач/top, чтобы посмотреть, сколько сервисов крутится у тебя (да, ты их тоже используешь, но неявно). А потом уже считай программы.
Общий ответ: потому, что люди, принимающие решения, не хотят платить за надёжность софта. Это касается как производителей, так и покупателей.
В целом надёжность софта значит гораздо меньше, т.к. обычно есть возможность обновить этот самый софт. С железом это сделать практически невозможно. Стоит отметить, что когда игры и программы распространялись на дисках, надёжность софта была повыше, т.к. у среднего покупателя не было возможности обновиться по интернету.
К примеру Microsoft раньше использовала огромный парк тестовых машин самых разных конфигураций, на которых прогонялись все билды Windows. Когда это убрали, качество упало. Зато сэкономили деньги.
Нет формального определения качества. Нет даже возможности сравнить качество двух конкурирующих продуктов кроме как личными впечатлениями. Поэтому качество, как правило, не служит ориентиром при выборе программы. Ориентируются на дизайн, ориентируются на формальный список фич. Например микрософт решит, что пора подтянуть качество Windows и следующие 5 лет будет выпускать только багфиксы без единой новой фичи. Увеличит это продажи? Нет, уменьшит.
А языки и прочее это всё вторично.
Ну и такая культура пренебрежения качеством проникает во все уголки. Не удивлюсь, если автопилот в юбере пишут те же люди, что писали фронтэнд на JavaScript, с соответствующим подходом.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, okon, Вы писали:
O>>Не уверен, в моем списке программ наверное штук 20-30. При этом в конкретном компьютере железок того же порядка.
N>Уверен на 100%, что одних драйверов ты используешь больше 20-30. Потом загляни в диспетчер задач/top, чтобы посмотреть, сколько сервисов крутится у тебя (да, ты их тоже используешь, но неявно). А потом уже считай программы.
Еще обычно драйвер сопоставляется железке.
В таком случае можно посчитать количество деталей на плате, там тоже не один процессор, а другие ”сервисы“.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Еще обычно драйвер сопоставляется железке. O>В таком случае можно посчитать количество деталей на плате, там тоже не один процессор, а другие ”сервисы“.
Конечно можно. И ты обнаружишь, что всё ломается и многое очень плохо спроектировано, особенно в ноутбуках или смартфонах. Ради интереса поговори за бокалом пива с мастером из сервис центра, он тебе расскажет про надёжность железа всё, что знает.
O>Казалось бы процесс производства софта гораздо более короткий чем при проектировании железа или какого-либо устройства. O>Можно легко внести изменение и протестировать, в отлчии от той же электрической схемы. O>Т.е. ПО можно за одно и тоже время проверить и улучшить во много раз больше чем железку. O>И ПО должно быть в итоге намного надежнее железа.
В условиях рыночной экономики — зачем производителю вообще надо писать надежное ПО?
O>Почему нет критичных багов в релизных процессорах, материнских платах, компьютерах ? И в компаниях обычно нет инженера Интел который сидит и поддерживает их процессор. O>Как правило все ошибки идут уже на уровне драйверов и софта.
Именно потому, что вместо глючной железки разработать новую — долго. А вместо глючной программы разработать новую версию и впарить покупателям — быстро.
И да, убедить пользователя поставить новую версию программы — проще, чем убедить физически поменять железку.
Здравствуйте, okon, Вы писали:
O>И ПО должно быть в итоге намного надежнее железа. O>Как разработчики железа при той же периодичности крупных релизов ~раз в 1 год добиваются надежной работы, хотя их цикл внесения изменений намного дольше.
Вообще говоря, надежность софта достаточно большая. Вот попробуй положить ютуб, гугл, контакт, банковский софт и т.д. Хрен у тебя получится. Какие то мелкие баги да, могут проскальзывать. Но на то они и мелкие что с ними можно жить. Быстро выпустить фичу важнее чем пофиксить мелкие некритичные баги.
Здравствуйте, okon, Вы писали:
O>Почему нет критичных багов в релизных процессорах, материнских платах, компьютерах ? И в компаниях обычно нет инженера Интел который сидит и поддерживает их процессор. O>Как правило все ошибки идут уже на уровне драйверов и софта.
То, что вы о них не знаете, не значит, что их нет.
Вот тут, например, список извесных ошибок семейства микроконтролёров SAM D5x/E5x Family.
Примеры ошибок:
2. Silicon Errata Issues
...
2.14 Non-Volatile Memory Controller (NVMCTRL)
2.14.1 NVM Read Corruption
NVM reads could be corrupted when mixing NVM reads with Page Buffer writes.
Workaround
Disable cache lines before writing to the Page Buffer when executing from NVM or reading data from NVM while
writing to the Page Buffer. Cache lines are disabled by writing a one to CTRLA.CACHEDIS0 and
CTRLA.CACHEDIS1.
или
2.1 Analog-to-Digital Converter (ADC)
2.1.1 ADC SYNCBUSY.SWTRIG
The ADC SYNCBUSY.SWTRIG gets stuck to '1' after wake-up from Standby Sleep mode.
Workaround
Ignore the ADC SYNCBUSY.SWTRIG status when waking up from Sleep mode.
Как вам такой Workaround?
И таких ошибок семь десятков примерно. Это известных. И только в одном широкоиспользуемом микроконтролёре.
А как начнёшь работать на низком уровне с какой-нибудь железкой, ну там, с Wi-Fi модулем, например, и стоит отклониться от обычного сценария, то пиши "пропало". Обычный сценарий, это например, один модуль на USB. А подключаешь второй — и всё, после soft перезагрузки модули не отвечают. Или что-нибудь другое в этом же роде.
Здравствуйте, vsb, Вы писали:
vsb>Общий ответ: потому, что люди, принимающие решения, не хотят платить за надёжность софта. Это касается как производителей, так и покупателей.
Дополню вас небольшим примером, который как-то приводил мой коллега (как раз в обсуждении вопроса качества ПО). Этот он сам нашел в какой-то статье или книге.
Со слов коллеги где-то до начала 90-х производители медицинского оборудования (имеется в виду серьезного и потенциально опасного — таких, как рентгеновские аппараты) не сильно заморачивались вопросами качества управляющего ПО и процессы разработки там были в целом такими же как везде.
Но где-то в конце 80-х, начале 90-х прошла целая волна серьезных инцидентов с мед. оборудованием, и как следствие — огромные иски от потерпевших и штрафы от контролирующих органов.
По их результатам производители оборудования прикинули, что возможные потери от исков из-за ошибок в ПО многократно перекрывают вложения в организацию процесса тестирования и выпуска надежного ПО.
Были сделаны соответствующие изменения и как результат проблемы не ушли совсем, но их количество резко упало.
Т.е. пока вероятные потери от ненадежного ПО не будут превышать затрат на обеспечения его надежности — никто не этой самой надежностью заниматься и не будет.
Здравствуйте, okon, Вы писали:
O>Казалось бы процесс производства софта гораздо более короткий чем при проектировании железа или какого-либо устройства. O>Можно легко внести изменение и протестировать, в отлчии от той же электрической схемы. O>Т.е. ПО можно за одно и тоже время проверить и улучшить во много раз больше чем железку. O>И ПО должно быть в итоге намного надежнее железа.
С точностью до наоборот.
Вопрос "на засыпку": в каком коде чаще всего обнаруживаются баги? Да в том, который только что написали или поменяли! (Есть статья на эту тему как минимум от Гугла. Возможно, Фейсбук тоже смотрел такую статистику и где-то рассказывал.)
Таким образом, лёгкость внесения изменений в софт по сравнению с железом провоцирует _увеличение_ количества багов, а не их уменьшение. Чисто статистически.
O>Почему нет критичных багов в релизных процессорах, материнских платах, компьютерах ? И в компаниях обычно нет инженера Интел который сидит и поддерживает их процессор. O>Как правило все ошибки идут уже на уровне драйверов и софта.
На эту тему уже высказались намного более компетентные коллеги. Я только вспомню FDIV bug, Spectre и Meltdown.
O>Как разработчики железа при той же периодичности крупных релизов ~раз в 1 год добиваются надежной работы, хотя их цикл внесения изменений намного дольше.
Это у них throughput ~1 процессор в год, а latency ~20 лет. Со всеми вытекающими.
Т.е. объём _анализа_, _моделирования_, _верификации_ и тестирования по сути несопоставим. Ровне все те элементы, которые ведут к снижению количества ошибок и как правило "пропускаются" при разработке ПО.
Здравствуйте, okon, Вы писали:
O>Казалось бы процесс производства софта гораздо более короткий чем при проектировании железа или какого-либо устройства. O>Можно легко внести изменение и протестировать, в отлчии от той же электрической схемы. O>Т.е. ПО можно за одно и тоже время проверить и улучшить во много раз больше чем железку. O>И ПО должно быть в итоге намного надежнее железа.
Можно просто открыть errata на эти железки, и представить, сколько геморроя была у писателей драйверов и ОС, пока они эти "особенности" обходили, сразу передумаешь сравнивать.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, okon, Вы писали:
O>Почему нет критичных багов в релизных процессорах, материнских платах, компьютерах ? И в компаниях обычно нет инженера Интел который сидит и поддерживает их процессор.
Есть.
O>Как разработчики железа при той же периодичности крупных релизов ~раз в 1 год добиваются надежной работы, хотя их цикл внесения изменений намного дольше.
Никак не добиваются. И часто к их ошибкам приходится делать workaround в драйвере. И если workaround оказывается недостаточно хорош, то некоторые несознательные пользователи считают, что это ошибка в драйвере.
Здравствуйте, GarryIV, Вы писали:
GIV>ЗЫЖ У меня модуль wi-fi в ноуте глючит, это считается?
Почему ты думаешь, что это не софтверная проблема?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
