Как меняется стоимость кода в зависимости от требований к его надёжности?

Ну, получается, если в 1000 строк 1 ошибка в open source, то в коммерческом коде как раз будет 1000 ошибок. Все сходится.

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

Хотя нет, ответ есть. Это коэффициент «42». Просто умножь не него исходную цену. Будет из той же оперы. Просто и понятно, без мучительных и мудрёных объяснений.

Эмпирическое из опыта. Чем дальше тем сложнее ошибки и тем сложнее их выковыривать.

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

Коэффициент 42 меня бы устроил, но мне никто не поверит.

Моё имхо.

Самый дешёвый и оптимальный способ писать софт - опытным разработчиком (или под надзором), без тестов.

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

Следующий уровень - опытные разработчики с частичным покрытием тестами. Примерно в 2 раза больше работы, незначительное повышение качества, усложнение дальнейшего развития.

Следующий уровень - полное покрытие тестами. Примерно в 2-2.5 раза дольше, потребуется имитировать все ошибочные сценарии. Софт получается устойчивым к ошибкам. Применимо для критичных отраслей.

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

Где-то перед этим формальное доказательство. Работает для ограниченного числа проектов. Имеет смысл для основы вроде микроядра ОС.

ну я смотрю, коэффициент 50 уже неоднократно прозвучал :)

Но задачи оценки надежности часто именно что неформализуемы. Здесь нужен человек, который оценит, что надежно, а что - нет. Повторяюсь.

Нет, если тебе повезет, то ты можешь использовать SPARK как подмножество Ады или какое-другое подмножество другого языка, но только подмножество. И что такой верификатор докажет? Что код делает именно то, что ему приказали? Но то ли он делает, чего от него ждут люди?

А покрытие тестами - ну, такой себе аргумент. Допустим, на тестах самолет летал только над северным полушарием. Потом миллион раз пролетал в бою. А потом послали его через Антарктиду в первый раз в жизни, а он взял и свалился в штопор. Утрирую, но отдаленно напоминающий это случай был в космонавтике совсем недавно. Шуму тогда было в прессе!

Впрочем, когда кроме тестов ничего другого не остается, то приходится довольствоваться малым.

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

Хотя, конечно, люди совсем не дураки. Там, где надо, давно подключают и математиков, и физиков, целые НИИ работают, но так бывает не всегда. Представляешь, сколько тут людей нужно подключить?

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

Чтобы АЭС

Теперь уверен, что тупой троллинг начался где-то со второго сообщения в теме.

Когда консенсус?

Да хз, на самом деле, это всё неформализуемо. Странная отрасль IT. Оценки, сроки - всё от балды по большому счёту.

Ага, иллюзия предсказуемости, в которую так хочется поверить, но это не только в айти.

Не хочу свести с вычислимой формуле, хочу хотя бы набор примеров.

Не хочу свести с вычислимой формуле, хочу хотя бы набор примеров.

У меня стойкое ощущение, что ты хочешь заглянуть в «послезавтра».

Боюсь, на на наших глазах произойдёт «промышленная революция» в программировании, когда тысячи кодеров со своими «фреймворками» и различными предпочтениями будут заменены, как те крестьяне со своими плугами на «энергонасыщенные тракторы и комбайны», при изготовлении которых и нужны «материаловедение, сопромат с теми самыми гарантиями надёжности».

Прошу прощения за, как всегда, кривую аналогию…

Ну я на самом деле пытаюсь подготовить выступление на тему того, зачем я начал заниматься ЯОС. Смысл тут простой, думаю, уже можно раскрыть. Линукс стоит, допустим 10 млрд. долларов (это когда-то по методике посчитали стоимость Федоры 10-летней давности, ядро 1 ярд, весь дистрибутив - 10). Это нынешний Линукс, который решето, столько стоит. Если бы Россия хотела, она могла бы написать свою ОС масштаба линукс с нуля, потому что это цена дороги Москва-Казань, на которую деньги нашлись, и которая не строго необходима.

Но можно задаться вопросом, а сколько бы стоила нормальная операционка, которая не решето? Ясно, что она стоила бы дороже, а насколько дороже? Вот эту оценку я и хочу получить.

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

Само выступление состоится, кстати, 13 декабря в 11 по Москве, онлайн, анонсы тут: https://forum.oberoncore.ru/viewtopic.php?f=155&t=6816

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

пытаюсь подготовить выступление

То, что написал, - это уже «выступление». Как раз для уровня «инвесторов». :)

Это оказалось враньём и по ходу дела нашлись цифры

ТС, а эмпирически нельзя установить некую, так сказать, недостоверность корреляции «ошибок» между открытым кодом и коммерческим? 😀

Даже исходя из того, что на З/П сидит человек, полностью погруженный в проблему и задачу. В то время как писатель открытого софта не так сконцентрирован и попутно занимается много еще чем, даже в носу ковыряние будет отвлекающим фактором.

Да забудь уже про открытый код, вопрос не про него. Это просто было «краткое содержание предыдущих серий». Но если ты хочешь про это поговорить, то ты говоришь про процесс создания кода, а ошибки - это результат написания, который можно в данном случае рассматривать и отдельно о процесса, поскольку код существует отдельно от процесса его создания и его можно отдельно же изучать. Если он доступен, конечно же. Проприетарный код доступен ограниченно, поэтому действительно, в целом достоверно сравнить нельзя.

Я, кстати, придумал, как можно действовать. Сравнивать с другими попытками заделать дырочки в решете. Например, Андроид. Там тоже есть дыры. https://habr.com/ru/company/otus/blog/547160/

Другой случай создания ОС на базе Open Source - это Mac OS.

Но мне уже некогда это раскапывать, чтобы сделать хороший кадр на эту тему, нужно день потратить :(

Инвесторы с утра каждый день, после Бизнес-ФМ и биржевых котировок сразу бегут на ЛОР.

Вот видишь: пока искал истину, заодно и прорекламировал. Все довольны - игра с положительной ненулевой суммой.

Если бы хотел именно прорекламировать, сделал бы отдельную тему. Возможно, ещё сделаю.

Более надёжный код дольше писать, дольше писать тратить больше времени программиста и это после того уже как программа готова, а до этого время на решение задачи и это зависит от её сложности. Итаго сама по себе надёжность ничего не стоит стоит время программиста затраченное на решение поставленной задачи в виде написания кода который эту задачу решает с последующим аудитом программиста готового решения для внесения в него правок относительно возможных внештатных ситуаций с финальной оптимизацией всего уже готового этого дела. Надёжный код тупо гораздо дольше писать, а вся надёжность заключается в «а что если XXXXX тогда надо тут и там YYYY этим мы гарантируем ZZZZ» для каждой строчки уже готового кода. Чиста ИМХО я разработкой не занимаюсь.

Так вот и надо понять, насколько дороже. Например, сравнить стоимость разработки Андроида со стоимостью разработки Линукса.

и уже не успею получить здесь какую-либо цифру

У тебя не в цифрах проблема.

а сколько бы стоила нормальная операционка, которая не решето

Правильный вопрос: а можно ли написать практически полезную операционку, которая не решето? И что такое «не решето»?

Просто уязвимости в линуксе (или OpenBSD, если угодно) известны, ты можешь кричать «решето». А про уязвимости в Windows, KasperskyOS, macOS и прочей подобной продукции тебе не расскажут.

Ставь вопрос «Можно ли написать ОС, уровень доверия к которой будет выше, чем к Linux? И если можно, то как?» А уж после этого можно и стоимость обсудить.

Например, сравнить стоимость разработки Андроида со стоимостью разработки Линукса

Ты в курсе, что Андроид это надстройка над Линуксом? А сейчас часть кода Андроида входит в ядро Линукса? Как ты собрался их сравнивать?

Ты - инвестор или кто? Отвечай прямо, сколько дашь.

Вот это правильный анонимус, сразу с козырей зашёл.

Я бы без сожаления профинансировал ТСа на бутылку хорошего коньяка, чтобы он прекратил наезжать на линукс и СПО. Но он ведь не прекратит. И у него есть право на своё мнение, я вообще уважаю идейных людей.

Поэтому мне интересно говорить с ТСом об идеях, а не о деньгах…

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

Ты в курсе, что Андроид это надстройка над Линуксом?

Нет, я только в курсе, что они как-то связаны. Насчёт надстройки я не уверен. Я думаю, что это скорее всё же форк Линукса, а это уже другое. Так вот, гугл взял решето, заткнул в нём часть дырочек (он, наверное, старался их заткнуть), потратил эн денег, осталось столько-то дырочек. Оценив затрату денег и оставшиеся дырочки, можно оценить и эффективность пути, выбранного гуглом.

Прогуглил эту гуглотему. Вот что пишут:

http://rus-linux.net/MyLDP/android/android-vs-linux.html#:~:text=%D0%92%20%D0%BD%D0%B5%D0%BC%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D1%83%D0%B5%D1%82%D1%81%D1%8F%20%D1%8F%D0%B4%D1%80%D0%BE%20Linux,%D1%8D%D1%82%D0%BE%20%D0%B1%D1%8B%D0%BB%D0%BE%20%D0%B1%D1%8B%20%D0%B2%20%D0%B4%D0%B8%D1%81%D1%82%D1%80%D0%B8%D0%B1%D1%83%D1%82%D0%B8%D0%B2%D0%B5.

В андроиде нет даже glibc. Считать ли его после этого линуксом?

Поэтому мне интересно говорить с ТСом об идеях, а не о деньгах…

При этом ТС идейно хочет поговорить о деньгах…

В андроиде нет даже glibc.

В Void Linux тоже (теперь?) нет glibc.

Но и там и там есть libc

интересуют любые определения надёжности. Пока что конкретики в теме было маловато.

Стандарты – наше всё. Бюрократическая конкретика:
ГОСТ 27.002—89 Термины и определения (общие) ©.
ГОСТ Р 51904-2002 Требования к ПО (встроенные системы) ©.
ГОСТ 28195-99 Оценка качества программных средств ©

способы повышения надёжности

Тестирование: классификация ©.

их стоимость

«Время – деньги». Ихний баланс – оптимальная стоимость потерь, постулируемых методом экономического волюнтаризма.

Нет никакой стоимости. Есть рыночек. За сколько договоришься - за столько и продашь свое время / готовый код.

Давайте лучше опсудим славянские языки программирования.

Голосую за ЁптаСкрипт.

Ну я на самом деле пытаюсь подготовить выступление на тему того, зачем я начал заниматься ЯОС. Смысл тут простой, думаю, уже можно раскрыть. Линукс стоит, допустим 10 млрд. долларов (это когда-то по методике посчитали стоимость Федоры 10-летней давности, ядро 1 ярд, весь дистрибутив - 10). Это нынешний Линукс, который решето, столько стоит. Если бы Россия хотела, она могла бы написать свою ОС масштаба линукс с нуля, потому что это цена дороги Москва-Казань, на которую деньги нашлись, и которая не строго необходима.

Ох лал

Зависимости нет.

Изменится в (зп разработчика на rust)/(зп разработчика на c/c++) раз.

вот и надо понять, насколько дороже

ну давай прикинем.

вариант где никто не вспоминал слово «надежность»

• команда разработчиков реализует ПО со всеми заявленными фичами. собственно, на этом все.

вариант хоть сколько-то «надежный»

• команда разработчиков реализует ПО со всеми заявленными фичами.
• команда тестировщиков (по объемам затрат будем считать ее примерно равной команде разработчиков) проводит тестирование и
• вываливает на головы разработчиков все найденные безобразия. оные безобразия разработчики ничтоже сумняшеся устраняют. для простоты будем считать, что стоимость устранения безобразий примерно равна стоимости разработки.

итого, в первом случае затраты на разработку Х, во втором случае - 3Х.

если принять за единицу надежности одну итерацию тестирование-устранение недочетов, то в первом случае надежность равна 0, во втором 1.

Если бы Россия хотела, она могла бы написать свою ОС масштаба линукс с нуля

Ну ты же понимаешь, что это нафиг не нужно. Даже если представить себе, что РФ отключат от Интернет, Линукс и опенсорс все равно будут провозить на флешках и лэптопах, по земле, по морю и в воздухе.

Конечно надёжный код дороже. Стоимость надёжного кода повышается из-за процедур проверочных тестов, некоторые из которых нужно писать параллельно с софтом.

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

Хотение России само по себе ничего не решает. Нужна готовность инфраструктуры принять такую ОС.

Нет линейной зависимости. Очень опытный специалист не сможет писать некачественный код, даже бесплатно, если не стоит отдельно такая задача, просто из уважения к своему профессионализму, а является ли проект open-source или коммерческой разработкой - мало чего меняет.

Очень опытный специалист не сможет писать некачественный код, даже бесплатно,

спецы писать некачественный код не умеют. когда-то умели конечно… а потом разучились.

Я не видел мест, где тестировщиков было бы столько же, сколько разработчиков. Обычно их в несколько раз меньше. Так что скорее важен тот факт, что они «вываливают».

если принять за единицу надежности одну итерацию тестирование-устранение недочетов

Это не годится для определения единицы надёжности, поскольку это характеристика процесса, а не результата.

а сколько бы стоила нормальная операционка, которая не решето?

Solaris - 8 млн. человеко-лет.

Меня интересуют любые определения надёжности, любые способы повышения надёжности и их стоимость

У одной системы на эрланге был даунтайм в десятые секунды за 20 лет. Коэффициент надежности 99.99999.

Они не осилили - башдор есть и у них.

https://mkozuharov.wordpress.com/2014/10/02/shellshock-bash-bug-solaris-linux/

Т.е. предлагаешь мерять по времени даунтайма? Что ж, это одна из возможных метрик, правда, не про кибербезопасность.

Я не видел , где тестировщиков было бы столько же, сколько разработчиков.

а я видел места, где тестировщиков было раза в два, а то и в три больше, чем разработчиков. и это не смотря на то, что процесс тестирования был по тем временам неплохо автоматизирован.

Это не годится для определения единицы надёжности, поскольку это характеристика процесса, а не результата.

во-первых «нашли и устранили» это даже целых два результата. во-вторых тут в задних рядах интересуются как именно ты будешь оценивать надежность без тестирования, «мамой клянус», «зуб даю» или что-то инновационное?

а я видел места, где тестировщиков было раза в два, а то и в три больше, чем разработчиков. и это не смотря на то, что процесс тестирования был по тем временам неплохо автоматизирован.

А тестировщики могут ошибаться? …