OberonCore

Так это и так учитывается и без всяких "законных" ужесточений на качество. У конторы с хорошей репутацией скорее купят ПО, чем у никому неизвестной конторы (или печально известной).

http://ru.wikipedia.org/wiki/Чем_хуже,_тем_лучше

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

Если причина -- buffer overflow или segment violation в прикладном софте -- однозначно можно наказывать "по полной" за неиспользование в производстве давным-давно известных безопасных практик.

Да нет, как раз с Оберонами (включая КП и ББ) в этом отношении всё просто отлично: компиляторы маленькие и надежные, проверил отсутствие импорта SYSTEM -- и вперед.

С GPL и прочими "as is" системами вполне может быть такое развитие - будет создан некоторый консорциум, который будет ставить свой лэйбл, что-то вроде добровольной сертификацией с одновременным созданием страхового фонда.
"Консорциум "Рога и копыта" гарантирует работоспособность ПО в виде, описанном в документации/постановке задач. В случае коммерческих убытков звонить по тел. 555-555-55"
А за вступление в консорциум - входные тесты на живучесть ПО/цикла разработки и страховой взнос.

Не нужен такой закон. ПРивожу пример из своей практики. В документации Microsoft не описаны некоторые тонкости поведения области уведомлений. В частности, диспетчер задач и то, что послыает иконки о качестве связи, действуют в XP с нарушением всех описанных в документации договорённостей. ПРишлось предпринять практическое иссследование (гугление не дало результата), чтобы выяснить, какие из иконок отображать, а какие - прятать.

Ну и что мне делать в этой связи? На кого списать баги? Если следовать букве этого закона, я должен либо ждать несколько лет, пока Microsoft задокументирует поведение указанных приложений, либо, выпускать продукт с заведомыми с самого начала багами, поскольку разумного алгоритма добавления (или отказа в добавлении) иконок в трей не выявил.

Любой закон дожен способствовать развитию, а не тормозить его.

Законы ведь не имеют обратной силы, так что все уже "принятые" лиц. соглашения врядли получится отменить.

Ну так мы живем не только сегодняшним днём.

А реально получится, что отвечать будет последний в цепи, т.е. разработчик прикладного софта.

А то, что появится ещё один вариант страховки, ясно кому выгодно.

Ну и, наконец, кто будет виноватого искать? Каким образом можно доказать, что виновен именно этот разработчик, а не какой-либо другой?

ПО не выполнило обещанную задачу. Какая разница упадет - оно с AV или с ассеротм? Или не упадет, а просто покажет окошко: "Не смогла". Убытки у юзера и в том и в другом случае будут в $.

Я к тому, что если вы успеете продать ваш софт до того, как примут закон, то к вам никаких претензий, потому что, это было "до того как". Ну, а если после принятия закона вы сознательно воспользовались данным багом/недокументированой функцией, то, как сказал А. Ильин, вы действовали не по доке, поэтому, вы и виноваты.Да, да! Пусть пишут без ошибок.

Сколько раз можно про одно и то же.

Тут уже граница между ущербом от использования ПО (потеря данных, авария и т.п.) и ущербом от невозможности использовать ПО (гарантийные обязательства).

Пример:
Если техника сломалась, то производитель отвечает только по гарантийным обязательствам. Если в технике был серьёзный конструктивный дефект, который привёл к человеческим жертвам, то тут уже дело судебное.

Ну так и в ПО есть такая практика - тех саппорт называется. Только стоит дорого Вы хотите всем навязать эту дополнительную цену? Все-таки по сравнению с техникой есть принципиальные отличия. Каждая произведенная единица техники ломается индивидуально с какой-то вероятностью. Эту вероятность закладывают в стоимость. У ПО произведенная единица одна и ломается она одинаково в одинаковых случаях. Или не ломается совсем. Поэтому если я покупаю ПО, которое без проблем работает у друга (или я попробовал триал и убедился, что ПО работоспособно для моих задач), то я не хочу разделять стоимость гарантийных обязательств с кем-то еще, кто использует это ПО для несколько других задач (и с которыми данное ПО справляется плохо). Но если у меня серьезная контора и риски слишком велики - то почему бы и не купить тех саппорт.



Ну да. Где-то в сети видел что-то типа "10 самых злобных ошибок в ПО". Насколько я помню, без судебных дел там не обошлось.

А ещё есть понятие (юридическое) халатности. Т.е. если не были предприняты общеизвестные, базовые меры к обеспечению надёжности. Вот тут-то некий базовый уровень требований можно выставить.

Т.е. если некий стройматериал неадекватно себя повёл через 10 лет в силу каких-то новых обнаруженных свойств, то это не халатность; если вообще можно квалифицировать как ошибку... А вот если не были выполнены стандартные расчёты на прочность - то сажают

Если вы хотите всех обязать использовать обероны - то так и скажите Это будет проще, чем сформулировать "базовые меры к обеспечению надёжности" и проверить их выполнение.



Ага. Расскажите мне про стандартные расчеты программ Дейкстра? Так даже его поклонники не всегда могут придти к согласию относительно самого правильного цикла в конкретной ситуации. Просто запретить "недейкстровские" конструкции? См. тему про Duff's device. Не говоря уже о том, что сам по себе запрет не помогает писать правильные программы. Первична сама воля к тому, чтобы писать правильно. Как вы ее собираетесь контролировать? Психологический тест при приеме на работу в качестве программиста?

Ну шо Вы тень на плетень наводите Понятие "безопасный язык программирования" давно и прочно определено в ИТ. Требования к системе типов и управлению памятью тоже однозначно сформулированы.
Вполне чёткий, легко проверяемый критерий.
Уходить ниже этого уровня можно в силу тоже вполне ясно очерченного круга причин (да и локализуется этот уход обычно хорошо). Если же ушли без таких причин, значит - волюнтаризьм и халатность.

Это дело будущего. Но того, которое нам надо делать уже сегодня
Кто ж виноват, что затормозилось дело на 2 десятка лет...
Был "кризис резкого роста", но теперь пора, пора - от знахарства к науке...

Ну тогда извините. Оберон со своим SYSTEM пролетает. Впрочем даже если убрать SYSTEM, то все равно остается компилятор/рантайм. А пока ближе всего к описываемой вами безопасности жаба У нее верифицируемый байткод. Т.е., достаточно "стандартизировать" сам верификатор - вполне реальная задача.



Угу. Можно обязать прогонять ПО через такой верификатор. Собственно это уже есть и работает для жабы. А толку - в программах на жабе нет багов?

Если мы не берём вопрос злоумышленности (а мы его не берём), то это не имеет значения. Любой язык, обеспечивший герметичность типов/памяти и отделивший нарушающие средства, относится к этому классу.

Да причем здесь злоумышленность. Много вы на BB напишите без иморта SYSTEM или какого-нибуь Kernel'а? До первого WinAPI вызова или попытки обработать ASSERT Не надо подгонять "базовую безопасность" под оберон Все должно быть строго, если уж на такую серьезную штуку замахнулись. А пока ваши рассуждения больше похоже на мечты выпихнуть C/C++ с ниши ПО в native коде Эта ниша и так уменьшается, оставляя место только задачам, которые как раз требуют небезопасности для эффективного решения, не туда надо целить