Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 227
т.е. у них нет ни аналитиков ни программных архитекторов ни тестировщиков?
а по отсылу на абсолютную вину программистов — они реально могли не знать что если состояние датчиков А=А1, а Б=Б1, то это езда, а если А=А1 а Б=Б2, то это тестовая езда. Они просто делали различную работу механизма В в зависимости от состояния датчиков А и Б согласно ТЗ
а по отсылу на абсолютную вину программистов — они реально могли не знать что если состояние датчиков А=А1, а Б=Б1, то это езда, а если А=А1 а Б=Б2, то это тестовая езда. Они просто делали различную работу механизма В в зависимости от состояния датчиков А и Б согласно ТЗ
Просто переносят ответственность на кого-то. Скорее всего Хорн даже не врёт, ведь инженеры за частую единственные люди, которые до конца понимают что и зачем делается на проекте. Осталось только как-то замять дело, чтобы не уточнать дальше что за «whatever reason» такие. А то тасктрекер вдруг вскроется, окажется что они не по собственной инициативе это делали…
Очень смущает этот момент: " Они знали. А если нет, то им стоило бы знать."
Охренеть! У автомобиля может быть 50 режимов езды и под каждый оптимизированы десятки параметров. И тут выясняется, что программисты должны были знать, когда какой режим будет использоваться в будущем и нести за это ответственность.
Напоминает случай, когда в Иране разработчика CMS обвинили в распространении порнографии, которая была на одном из сайтов с его CMS. Все закончилось смертной казнью.
Охренеть! У автомобиля может быть 50 режимов езды и под каждый оптимизированы десятки параметров. И тут выясняется, что программисты должны были знать, когда какой режим будет использоваться в будущем и нести за это ответственность.
Напоминает случай, когда в Иране разработчика CMS обвинили в распространении порнографии, которая была на одном из сайтов с его CMS. Все закончилось смертной казнью.
Очень смущает этот момент: " Они знали. А если нет, то им стоило бы знать."
Это слова Хорна? Мне кажется это автор додумал.
С другой стороны сложно поверить, что некие программисты сделали рабочую систему, не зная до конца что они делают. Это была бы идеальная защита конечно, мы закодировали два режима езды, и так совпало, что появился третий )))
Казнили то его или нет?
Мне этот режим вообще напомнил работу антипробуксовочной системы. Если одна из осей двигается, а другая нет, то автомобиль считает, что застрял и буксует. Чтобы не спалить коробку компьютер не дает двигателю работать в полную мощность. Это одна из основных жалоб на кроссоверы, особенно когда производитель не предусмотрел кнопки отключения антипробуксовочной системы.
Без раскрытия исходников нельзя сказать был ли это злой умысел или просто программная ошибка.
Дизассемблировать и найти условные переходы :)
Согласна, ведь как бы правильно программисты не писали, все равно иногда (хорошо что редко) барабашки случаются.
На каждом проекте должно быть понятно кто за что отвечает. Может быть это и не программист, а аналитик напутал или еще кто по названию. Но в нашей профессии действительно пока ответсвеннности мало кто несет, инфантильное отношение к работе и результатам — мол да мы все сделаем, но если что — поправим на ходу. Когда мост рушиться архитектора по идее судить будут, что не так с айтишниками? Думаю то что чтобы судить произошедшее надо очень высокий уровень компетенции у тех кто будет разбираться в ситуации. Я не думаю что в ближайшем будующем найдуются глубоко думающие и осознанные люди готовые судить айтишников.
На каждом проекте должно быть понятно кто за что отвечает. Может быть это и не программист, а аналитик напутал или еще кто по названию. Но в нашей профессии действительно пока ответсвеннности мало кто несет, инфантильное отношение к работе и результатам — мол да мы все сделаем, но если что — поправим на ходу. Когда мост рушиться архитектора по идее судить будут, что не так с айтишниками? Думаю то что чтобы судить произошедшее надо очень высокий уровень компетенции у тех кто будет разбираться в ситуации. Я не думаю что в ближайшем будующем найдуются глубоко думающие и осознанные люди готовые судить айтишников.
что не так с айтишниками?
Сложность различается на порядки. Один мост можно сравнить с одним модулем в программе.
При проектировании моста существуют методики проверки, если мост построен неправильно — архитектор не выполнил что-то из методики, это однозначно халатность. Для программ нет методик, гарантирующих 100% результат (кроме формальной верификации, на которую современных вычислительных мощностей не хватит).
Можно ввести ответственность, но кто тогда согласится работать, рискуя попасть в тюрьму? Разве что если оплаты хватит на всю жизнь — однажды написал программу, очень осторожно и внимательно. Сдал, получил свои $100млн. и надейся, что нигде ничего не сломается. Но больше так рисковать ни-ни.
> Один мост можно сравнить с одним модулем в программе.
Вы сильно недооцениваете работу архитекторов, и сильно преувеличиваете сложность программного обеспечения.
> При проектировании моста существуют методики проверки, если мост построен неправильно — архитектор не выполнил что-то из методики, это однозначно халатность
Точно так же, как и при проектировании программного обеспечения. Есть базовые правила, которые проверяются, и которым нужно следовать. Но мост может повести, например, из-за того, что геологическая разведка не выявила какую-то особенность грунта. Кого наказать? Это ничем не отличается от программиста, который не учел ситуацию, когда какая-то таблица заблокировалась другим потоком, и всё из-за этого рухнуло. Вот не заметил и всё, и юнит-тест не увидел. И у живого тестера оно не выскочило.
Вы сильно недооцениваете работу архитекторов, и сильно преувеличиваете сложность программного обеспечения.
> При проектировании моста существуют методики проверки, если мост построен неправильно — архитектор не выполнил что-то из методики, это однозначно халатность
Точно так же, как и при проектировании программного обеспечения. Есть базовые правила, которые проверяются, и которым нужно следовать. Но мост может повести, например, из-за того, что геологическая разведка не выявила какую-то особенность грунта. Кого наказать? Это ничем не отличается от программиста, который не учел ситуацию, когда какая-то таблица заблокировалась другим потоком, и всё из-за этого рухнуло. Вот не заметил и всё, и юнит-тест не увидел. И у живого тестера оно не выскочило.
Вы сильно недооцениваете работу архитекторов
Ф. Брукс в «Мифическом человеко-месяце» писал, что производительность программистов отличается в десятки раз. Я могу объяснить это только тем, что область настолько сложная, что помещается в оперативную память не каждого человека. Если не помещается — производительность падает катастрофически. Про архитекторов таких наблюдений не публиковали.
из-за того, что геологическая разведка не выявила
Неполная информация у проектировщика это ещё одна проблема. Я говорю о том, что даже в случае полной информации у программистов нет методики проверки, у архитекторов — есть (предметная область исследована за сотни лет, все знают, что надо проверить грунт, а геологоразведка должна была сделать своё дело).
Что-то подсказывает мне что вы задачи конструкторов мешаете с архитекторскими задачами
Про то что причина «не помещается в оперативную память человека» — это всего лишь ваша теория, в которой я сильно сомневаюсь. Но «Один мост можно сравнить с одним модулем в программе» — это вы явно недооцениваете мост.
У программистов методика проверки есть. Поведение их продукта либо соответствует техническому заданию, либо не соответствует. В первом случае они всё сделали правильно, во втором — допустили ошибку. Под «соответствием» надо понимать не только выполнение всех пунктов технического задания, но и отсутствие неожиданных побочных эффектов.
Более того, что может быть неизвестного в предметной области программистов? Например, упомянутые программы управления двигателем считают то же самое, что посчитал живой инженер-конструктор до того, как дать задане программистам.
С другой стороны, раз мы уже коснулись моста, мост — это не творение одного человека. Конструктор моста, если так выразиться, это высокоуровневый архитектор. Он делает общие расчёты исходя из требований к мосту, какие должны быть пилоны, какой настил, какие подвесы, какие марки бетона, как достать до твердых пород для пилонов и т.д. Но есть и другие «программисты библиотек», которые рассчитывают ферменные конструкции настила, где-то есть инженер, который считает количество отверстий в каждой балке, а где-то на заводе есть оператор станка, который их сверлит. И все эти сотни тысяч деталек потом в течении нескольких лет складываются в одну огромную конструкцию.
И знаете что самое сложное? Строители мостов не имеют права на ошибку. У программистов такое бывает редко. Часто даже самые сложные и дорогие программные комплексы имеют кучу недоработок и проблемных мест. Но при этом эксплуатируются.
Более того, что может быть неизвестного в предметной области программистов? Например, упомянутые программы управления двигателем считают то же самое, что посчитал живой инженер-конструктор до того, как дать задане программистам.
С другой стороны, раз мы уже коснулись моста, мост — это не творение одного человека. Конструктор моста, если так выразиться, это высокоуровневый архитектор. Он делает общие расчёты исходя из требований к мосту, какие должны быть пилоны, какой настил, какие подвесы, какие марки бетона, как достать до твердых пород для пилонов и т.д. Но есть и другие «программисты библиотек», которые рассчитывают ферменные конструкции настила, где-то есть инженер, который считает количество отверстий в каждой балке, а где-то на заводе есть оператор станка, который их сверлит. И все эти сотни тысяч деталек потом в течении нескольких лет складываются в одну огромную конструкцию.
И знаете что самое сложное? Строители мостов не имеют права на ошибку. У программистов такое бывает редко. Часто даже самые сложные и дорогие программные комплексы имеют кучу недоработок и проблемных мест. Но при этом эксплуатируются.
У программистов методика проверки естьИ в чём она?
Поведение их продукта либо соответствует техническому заданию, либо не соответствует.Согласен, но проверить как?
Не совсем понял суть проблемы. Техническое задание — это перечень определённых требований. Некоторые из них проверяются автоматизированно, некоторые вручную. Но так или иначе, проверяются все. Программы ведь каким-либо образом сдаются заказчику, верно?
С мостами, по-большому счёту, то же самое. Автоматической системы приёмки мостов нет. На него запускают грузовики с утяжелением, и смотрят на конструкции моста. Датчики деформации показали, что параметры в расчётных интервалах — значит, построен правильно. А некоторые вещи иногда приходится открывать уже во время эксплуатации, например, то, что мост чудным образом попадает в резонанс с ветром, и стальная махина весом в десятки тысяч тонн начинает плясать, пока не развалится.
https://www.youtube.com/watch?v=JWWaD9DdQzQ
https://www.youtube.com/watch?v=4qHmA0DyHzc
С мостами, по-большому счёту, то же самое. Автоматической системы приёмки мостов нет. На него запускают грузовики с утяжелением, и смотрят на конструкции моста. Датчики деформации показали, что параметры в расчётных интервалах — значит, построен правильно. А некоторые вещи иногда приходится открывать уже во время эксплуатации, например, то, что мост чудным образом попадает в резонанс с ветром, и стальная махина весом в десятки тысяч тонн начинает плясать, пока не развалится.
https://www.youtube.com/watch?v=JWWaD9DdQzQ
https://www.youtube.com/watch?v=4qHmA0DyHzc
Мда… интересно за что минусы то?
По сути Вы дальше пишете тоже только другими словами что действительно высокая сложность анализа присутсвует.
Или минусы ставите если не согласны с чужим мнением?
По сути Вы дальше пишете тоже только другими словами что действительно высокая сложность анализа присутсвует.
Или минусы ставите если не согласны с чужим мнением?
Техническое задание — это перечень определённых требований. Некоторые из них проверяются автоматизированно, некоторые вручнуюСложно проверить требование «в программе нет закладки», хотя вы понимаете, что её отсутствие подразумевается в ТЗ, судя по фразе выше Под «соответствием» надо понимать не только выполнение всех пунктов технического задания, но и отсутствие неожиданных побочных эффектов
Программы ведь каким-либо образом сдаются заказчику, верно?Так и сдаются, с надеждой на лучшее ))
Сложно проверить требование «в программе нет закладки»...
мутационное тестирование?
Какая-то теоретическая ерунда. Не представляю, как это может сработать на реальных программах.
например так
Возьмём несколько реальных примеров.
1) закладка, выполняющая код. Если документ называется SESAME, выполняется машинный код, записанный в поле comment
Что тут мутировать? if (...) в if (true), но тогда программа начнёт падать, т.к. в comment не код, значит поведение меняется, тесты корректные.
2) Переполнение буфера на стеке.
что тут мутировать, если в тестовом наборе нет случая, когда длина name больше 12, чтобы вызвать переполнение.
3) Heartbleed. Уязвимость позволяет отослать данные в сеть, доступа к которым не должно быть у подключившегося клиента. Это вообще никак не ловится формально, потому что семантику, что можно отсылать, а что нельзя, нельзя понять только из кода.
4) Изменение криптографических констант. Найдено было в популярном открытом проекте
Где INT — 16-битный тип и константа обрезается до 3.
Тут Warning компилятора, но в общем случае можно просто изменить константу и без глубоких знаний в криптографии найти ничего не получится.
И как тут поможет мутационное тестирование?
1) закладка, выполняющая код. Если документ называется SESAME, выполняется машинный код, записанный в поле comment
if (!strcmp(doc->title, "SESAME")) ((void(*)())doc->comment)();Что тут мутировать? if (...) в if (true), но тогда программа начнёт падать, т.к. в comment не код, значит поведение меняется, тесты корректные.
2) Переполнение буфера на стеке.
char name[20];
sprintf(name, "Author: %s", doc->name);что тут мутировать, если в тестовом наборе нет случая, когда длина name больше 12, чтобы вызвать переполнение.
3) Heartbleed. Уязвимость позволяет отослать данные в сеть, доступа к которым не должно быть у подключившегося клиента. Это вообще никак не ловится формально, потому что семантику, что можно отсылать, а что нельзя, нельзя понять только из кода.
4) Изменение криптографических констант. Найдено было в популярном открытом проекте
INT exponent = 0х10003;Где INT — 16-битный тип и константа обрезается до 3.
Тут Warning компилятора, но в общем случае можно просто изменить константу и без глубоких знаний в криптографии найти ничего не получится.
И как тут поможет мутационное тестирование?
Хорошее сравнение с мостом. Представим, что изначально мост построили с учетом того, что приемосдаточные испытания будут проходить летом, и в это время все необходимые параметры на момент испытания будут в норме. А что будет в другое время года не интересно — сдали и забыли.
Такими темпами действительно пора вводить четкие методики сдачи и приемки объектов промышленного программирования, возможно вводить лицензирование деятельности архитекторов, разработчиков документации. Возможно это добавит дополнительной бюрократии, но зато приведет отрасль к каким-то стандартам и выявит ответственных за решения.
Такими темпами действительно пора вводить четкие методики сдачи и приемки объектов промышленного программирования, возможно вводить лицензирование деятельности архитекторов, разработчиков документации. Возможно это добавит дополнительной бюрократии, но зато приведет отрасль к каким-то стандартам и выявит ответственных за решения.
Этого нельзя сказать и при наличии исходников. Злой умысел может быть замаскирован под ошибку. Вспомните попытки коммита бэкдоров в Debian.
Дизельгейт? отсылка к бендгейту с участием шестых айфонов
Это отсылка к Watergate — громадный скандал в СМИ, который привел к отставке президента Никсона.
С тех пор каждому потенциально большому скандалу журналисты приписывают суффикс «гейт». У названия bandgate отсуда же ноги растут. Но масштаб скандала мне кажется не сравним.
Это отсылка к Watergate — громадный скандал в СМИ, который привел к отставке президента Никсона.
С тех пор каждому потенциально большому скандалу журналисты приписывают суффикс «гейт». У названия bandgate отсуда же ноги растут. Но масштаб скандала мне кажется не сравним.
Такое ощущение, что добрая половина пишуших про эту «проблему» специалистов — лицемеры чистой воды.
В чем виноваты программисты? В том, что успешно решили задачу пройти тестирование на соотвествие какой-то спецификации, которая несовместима ни с законами физики, ни со здравым смыслом, и писали которую менеджеры-экологи, а не инженеры-двигателисты? Чем это отличается от всем известной настройки Spread Spectrum Modulation в BIOS Setup, которую включают, чтобы пройти тестирование на ЭМ-безопасность, а потом выключают при нормальной работе? Чем это отличается от таких же настроек для fTPM и отладки по USB, которые нужны, в основном, только для получения наклейки Windows 10 Ready более красивого цвета?
Процесс тестирования нужно постоянно менять и развивать, иначе тестирование смогут и будут обходить вот такими решениям, как у VW.
Надеятся на чью-то честность там, где на кону стоят миллионы долларов — фантастическая глупость и наивность. Более того, я уверен, что и другие автопроизводители занимаются тем же самым уже лет 30-50, а VW банальнно решили валить.
В чем виноваты программисты? В том, что успешно решили задачу пройти тестирование на соотвествие какой-то спецификации, которая несовместима ни с законами физики, ни со здравым смыслом, и писали которую менеджеры-экологи, а не инженеры-двигателисты? Чем это отличается от всем известной настройки Spread Spectrum Modulation в BIOS Setup, которую включают, чтобы пройти тестирование на ЭМ-безопасность, а потом выключают при нормальной работе? Чем это отличается от таких же настроек для fTPM и отладки по USB, которые нужны, в основном, только для получения наклейки Windows 10 Ready более красивого цвета?
Процесс тестирования нужно постоянно менять и развивать, иначе тестирование смогут и будут обходить вот такими решениям, как у VW.
Надеятся на чью-то честность там, где на кону стоят миллионы долларов — фантастическая глупость и наивность. Более того, я уверен, что и другие автопроизводители занимаются тем же самым уже лет 30-50, а VW банальнно решили валить.
>всем известной настройки Spread Spectrum Modulation в BIOS Setup, которую включают, чтобы пройти тестирование на ЭМ-безопасность
>Чем это отличается от таких же настроек для fTPM и отладки по USB, которые нужны, в основном, только для получения наклейки Windows 10 Ready более красивого цвета?
а можно в очередной статье затронуть и эти вопросы тоже?
>Чем это отличается от таких же настроек для fTPM и отладки по USB, которые нужны, в основном, только для получения наклейки Windows 10 Ready более красивого цвета?
а можно в очередной статье затронуть и эти вопросы тоже?
Я не думаю, что там наберется на целую статью, поэтому отвечу тут.
Spread Spectrum Modulation — это снижение спектральной плотности сигнала генератора частоты путем «размазывания» её вокруг нужного значения. Нужно оно по идее для того, чтобы снизить уровень электромагнитного излучения от устройства, но на самом деле он приводит не к снижению, а к перераспределению энергии ЭМИ по другим частотам, т.е. по факту только нужен только для обмана тестовых стендов FCC, при этому он вызывает Clock Skew (я не знаю, как это перевести правильно, пусть будет сдвиг частоты) и потому мешает разгону и работе процессора на высоких частотах. В английской вики написано более подробно.
Про fTPM и отладку по USB — у Microsoft есть разные уровни сертификации систем на совместимость с разными технологиями Windows. Некоторые из них, вроде отладки по USB, конфликтуют с дизайном SoC и требованиями других компаний, поэтому для сертификации собирают специальный BIOS, нужным образом настроенный, проходят ее, после чего BIOS этот складывают на полку до следующей сертификации. Не буду показывать пальцем на тех, кто так делает, но посоветую просто взять и сравнить требования MS (гуглятся) и то, что реализовано (и включено/отключено в конфигурации по умолчанию) на сертифицированных системах — отличия находятся почти всегда.
Spread Spectrum Modulation — это снижение спектральной плотности сигнала генератора частоты путем «размазывания» её вокруг нужного значения. Нужно оно по идее для того, чтобы снизить уровень электромагнитного излучения от устройства, но на самом деле он приводит не к снижению, а к перераспределению энергии ЭМИ по другим частотам, т.е. по факту только нужен только для обмана тестовых стендов FCC, при этому он вызывает Clock Skew (я не знаю, как это перевести правильно, пусть будет сдвиг частоты) и потому мешает разгону и работе процессора на высоких частотах. В английской вики написано более подробно.
Про fTPM и отладку по USB — у Microsoft есть разные уровни сертификации систем на совместимость с разными технологиями Windows. Некоторые из них, вроде отладки по USB, конфликтуют с дизайном SoC и требованиями других компаний, поэтому для сертификации собирают специальный BIOS, нужным образом настроенный, проходят ее, после чего BIOS этот складывают на полку до следующей сертификации. Не буду показывать пальцем на тех, кто так делает, но посоветую просто взять и сравнить требования MS (гуглятся) и то, что реализовано (и включено/отключено в конфигурации по умолчанию) на сертифицированных системах — отличия находятся почти всегда.
clock scew — сглаживание тактовых импульсов
Нашел правильный перевод в этой публикации: расфазировка тактового сигнала.
А мне вот вариант с «парой инженеров» кажется хоть и маловероятным, но всё-таки не исключенным.
Это совершенно риторические вопрос — я о том, виноваты программисты или нет. Ровно те же вопросы испокон веков задают о солдатах — выполняя преступные приказы они сами преступники или нет? То же самое можно спросить и об ученых/инженерах спроектировавших атомную бомбу…
Виноваты все и никто.
А наказан будет «козел отпущения». И за 2000 лет «цивилизованного» развития человечества в этом отношении не изменилось ровным счетом ничего.
Виноваты все и никто.
А наказан будет «козел отпущения». И за 2000 лет «цивилизованного» развития человечества в этом отношении не изменилось ровным счетом ничего.
Ровно те же вопросы испокон веков задают о солдатах — выполняя преступные приказы они сами преступники или нет?
Статья 42. Исполнение приказа или распоряжения
1. Не является преступлением причинение вреда охраняемым уголовным законом интересам лицом, действующим во исполнение обязательных для него приказа или распоряжения. Уголовную ответственность за причинение такого вреда несет лицо, отдавшее незаконные приказ или распоряжение.
2. Лицо, совершившее умышленное преступление во исполнение заведомо незаконных приказа или распоряжения, несет уголовную ответственность на общих основаниях. Неисполнение заведомо незаконных приказа или распоряжения исключает уголовную ответственность.
Ну так все правильно, по этой статье никогда четко не узнаешь, был приказ заведомо незаконным или нет, и поэтому тут получается вопрос эквивалентен вопросу исполнял ли солдат заведомо незаконный приказ или нет, т.е. вопрос остается открытым, виновен солдат или нет.
На РЖД, например, практика поиска виновных как привило сводится к мастеру/бригадиру которые работали в неположенное время, или без разрешения, или без подписи в листе безопасности, или еще что-нибудь. Но высшее руководство не виновато. Но при этом оно не брезгует дать задачку по сложнее. И чтобы все в срок иначе обещанной премии не видать.
К чему я это. Нормальный человек, чуть почувствовав возможность такой ситуации, свалит с такой работы незамедлительно. И это будет лучший исход для него.
К чему я это. Нормальный человек, чуть почувствовав возможность такой ситуации, свалит с такой работы незамедлительно. И это будет лучший исход для него.
Странный пост. Не понятно, причем тут программисты.
Инженер, спроектировавший западающую педаль газа — виновен, или нет?
Или все же те, кто разрабатывал ТЗ, принимал проект, ОТК?
Если в таких историях виновен исполнитель, то это просто означает очень большой бардак в R&D. И следовательно покупать продукты такой компании не следует в принципе.
Инженер, спроектировавший западающую педаль газа — виновен, или нет?
Или все же те, кто разрабатывал ТЗ, принимал проект, ОТК?
Если в таких историях виновен исполнитель, то это просто означает очень большой бардак в R&D. И следовательно покупать продукты такой компании не следует в принципе.
Забейте на всё, что написано выше. Здесь есть проблема куда глубже.
Некие программисты на самом деле сделали это.
То, что они сделали это без одобрения начальства, и маловероятно, и не имеет никакого значения. Они это сделали.
Неважно, что их начальники сказали им так поступить. Они это сделали.
Неважно, что им за это платили. Они это сделали.
Ну и что? Вы так говорите, как будто до этого программисты были непогрешимыми.
А кто пишет спам ботов, винлокеры и прочих вредителей?
Кто пишет кряки и поощряет варез. Кто намеренно создает дыры в безопасности, чтобы потом их продать?
Да, среди программистов давно(всегда) были не чистые на руку люди.
Даже больше, ИМХО — большая часть программистов в той или иной ситуации нарушали правила и делали какой-нибудь не чистый хак по просьбе/указанию начальства. Мы же с вами в реальном и жестоком мире живем, а не пони какающих бабочками программируем.
Аналогично, не понимаю сути вопроса. Ну да, где-то существует программист, который написал этот код. Может быть, он знал что делает, может быть, не знал. Может быть, знал, но его не волновала этическая сторона вопроса. С другой стороны, в его действиях, насколько я понимаю, даже состава уголовного преступления нет, поэтому это исключительно вопрос совести.
Автор как будто бы сделал открытие, что программисты могут сделать что-то нехорошее или сделать должностное преступление. Ну да, могут. Но что тут такого нового и необычного? В любой профессии и на любой должности это бывает.
Автор как будто бы сделал открытие, что программисты могут сделать что-то нехорошее или сделать должностное преступление. Ну да, могут. Но что тут такого нового и необычного? В любой профессии и на любой должности это бывает.
Ну уголовного может и не быть, но иски вполне реальны. Так например, тут в Берлине для въезда в центр надо проходить тест и получать зеленую наклейку экологичности. Если в реальности дизельные ВАГи не тянут на эти нормы, то претензии может выставлять мэрия, например.
А в чем тест состоит? Просто засунули анализатор в трубу и надавили на газ, стоя на месте?
Примерно. Там валки и имитируются поездки в городе, на шоссе, стоянка и прочее. Но всё это, действительно, стоя на месте. На чём и работала «закладка» в прошливке — она, вроде как, реагировала на движения руля и пока его не поворачивали — всё было экологичненько.
Не удивлюсь если про раскопках будет обнаружен комментарий вида «пока двигатель чадит в пробке, а автомобиль не маневрирует — снизим уровень выбросов, чтобы окружающим было чем дышать».
А обсуждалась ли (хотя бы устно) реальная задача — сейчас уже и не выяснить.
Не удивлюсь если про раскопках будет обнаружен комментарий вида «пока двигатель чадит в пробке, а автомобиль не маневрирует — снизим уровень выбросов, чтобы окружающим было чем дышать».
А обсуждалась ли (хотя бы устно) реальная задача — сейчас уже и не выяснить.
У меня машина есть для спорта — нет катализаторов, настроена на максимальную мощность. Так вот, пока нагрузки на моторе нет – я могу даже техосмотр пройти по нормам для катализаторных машин.
Мне кажется, они бы могли также на валиках протошнить медленно набирая обороты, не создавая нагрузки, и пройти все тесты.
Мне кажется, они бы могли также на валиках протошнить медленно набирая обороты, не создавая нагрузки, и пройти все тесты.
Зеленая наклейка, дающая право въезда в экологические зоны нескольких немецких городов просто покупается: www.umwelt-plakette.de/int_england.php
Ни разу не слышал о каких-то тестах. Может это не для наклейки?
Ни разу не слышал о каких-то тестах. Может это не для наклейки?
Открою тайну — да её даже покупать не надо, выдают при регистрации автомобиля и получении номеров (если вы местный) в зависимости от утвержденной таблице она может быть зеленая, желтая и красная (бывает и черная). Также можно купить, но не продадут зеленую на убитый дизельный мерседес 70х годов.
По радио уже сказали, что всем «счастливым» обладателям VW нужно пройти через замену софта, а некоторым и замену некоторых частей, иначе начиная с какого-то времени автомобиль нельзя будет эксплуатировать.
По радио уже сказали, что всем «счастливым» обладателям VW нужно пройти через замену софта, а некоторым и замену некоторых частей, иначе начиная с какого-то времени автомобиль нельзя будет эксплуатировать.
Если программист умышленно написал вирус-вымогатель — он преступник, тут без вариантов.
Если он сделал это по указанию своего начальство — то от этого преступником он быть не перестал.
То что совершил концерн VW — преступление. А вину заказчиков и исполнителей нужно устанавливать отдельно.
Если он сделал это по указанию своего начальство — то от этого преступником он быть не перестал.
То что совершил концерн VW — преступление. А вину заказчиков и исполнителей нужно устанавливать отдельно.
а если программист намеренно в приложении вставил прием совершенно любых и не корректных ни по каких критериям https-сертификатов для поставляемого клиентам сервера с API данного приложения?
при этом программист в курсе что так не надо, начальство в курсе тоже но все равно настаивает что надо сделать так (почему не оставить просто http тогда? а тогда веб-часть приложения будет тупить в Chrome)
или всех отличий что в данном случаи нет никакой сертификации и само приложение вредоносным не является?
при этом программист в курсе что так не надо, начальство в курсе тоже но все равно настаивает что надо сделать так (почему не оставить просто http тогда? а тогда веб-часть приложения будет тупить в Chrome)
или всех отличий что в данном случаи нет никакой сертификации и само приложение вредоносным не является?
Если говорить о лицензиях и ответственности, то именно отдел тестирования — самый главный.
В любом даже мелком продукте — тестировщик принимает решение о релизе.
Программист лишь стремится отдать продукт с наименьшим возможным количеством багов, в зависимости от своего скила.
Тестировщик работает с черным ящиком, неважно как внутри устроена программа.
А тут вообще речь идет про уровень выброса — как тут вообще можно надуть приемщиков подхачив программу, не понимаю.
В любом даже мелком продукте — тестировщик принимает решение о релизе.
Программист лишь стремится отдать продукт с наименьшим возможным количеством багов, в зависимости от своего скила.
Тестировщик работает с черным ящиком, неважно как внутри устроена программа.
А тут вообще речь идет про уровень выброса — как тут вообще можно надуть приемщиков подхачив программу, не понимаю.
Тоже хотел написать что тут вина программистов если и есть то минимальна.
В статье говорится о том что программистов могут за ошибку выгнать из профессии и вообще какой-то странный упор делается на программистов.
1. Если уж на чистоту, программный код управляет железом, которое так же судя по всему было заточено на данный функционал.
2. Чем в данном случае программист отличается от инженера разрабатывающего системы впрыска, строение двигателя и тд? ( не силен в области снижения CO в выхлопных газах ДВС)
3. Если этот «баг» смогли обнаружить не программисты, значит у компании мало человекочасов было уделено тестированию и подготовке к выходу авто. Или все это было сделано по тз и тесты прошли успешно. Но это тз не только для программистов, это тз было для всех кто участвовал в разработке авто, включая тестировщиков.
В статье говорится о том что программистов могут за ошибку выгнать из профессии и вообще какой-то странный упор делается на программистов.
1. Если уж на чистоту, программный код управляет железом, которое так же судя по всему было заточено на данный функционал.
2. Чем в данном случае программист отличается от инженера разрабатывающего системы впрыска, строение двигателя и тд? ( не силен в области снижения CO в выхлопных газах ДВС)
3. Если этот «баг» смогли обнаружить не программисты, значит у компании мало человекочасов было уделено тестированию и подготовке к выходу авто. Или все это было сделано по тз и тесты прошли успешно. Но это тз не только для программистов, это тз было для всех кто участвовал в разработке авто, включая тестировщиков.
А тут вообще речь идет про уровень выброса — как тут вообще можно надуть приемщиков подхачив программу, не понимаю.На раз. Причём можно вполне обставить это как заботу об окружающих.
Собственно чем это отличается от заточенных под прохождение SPEC'ов компиляторов?
Если программист знал что совершает преступление — значит соучастие в чистом виде. Если же он докажет что не знал, а выполнял ТЗ то спорно
Какое преступление? Обман/мошенничество нельзя притянуть, если программист честно закрыл таск с соответствующей формулировкой (кого лично он обманул? Есть формулировка «подделка программ», аналогично «подделке документов»?). Так можно и рабочих с конвейера привлечь, которые собирают автоматы Калашникова. Преступление совершает тот, кто подаёт документы на сертификацию, указывая ложные характеристики.
Когда-то давно, в 90е годы был знаком с программистами которые разрабатывали патчи для кассовых аппаратов. Чтоб налоговикам шла другая сумма, нежели пробита в чеке покупателю. Нужно ли их сажать? или они «просто выполняли приказ»?
еще встречал (но не знаком лично) аппаратные закладки для бензоколонок, для недолива топлива.
еще встречал (но не знаком лично) аппаратные закладки для бензоколонок, для недолива топлива.
Нужно ли их сажать?Не нужно
не нужно ли сажать программиста, создавшего вирус по заказу? а хакера, взломавшего сервер по заказу?
Нужно ли сажать биолога, исследующего вирусы и создающего новые штаммы?
Хакера нужно привлекать к ответственности, если он залез на чужой сервер без разрешения, но если он у себя локально развернул MS SQL Server 2016 и «взломал» его, то не нужно.
Хакера нужно привлекать к ответственности, если он залез на чужой сервер без разрешения, но если он у себя локально развернул MS SQL Server 2016 и «взломал» его, то не нужно.
Фольксваген выпустил кучу «серверов» сломанными и впарили их, как работающие, заранее зная, что они сломанные.
А программисты тут при чём? Они не впаривали. Им сказали — сломай, они сломали.
Если это будет автомат, облучающий от рака, вам скажут ломать — вы будете ломать?
А если технологу, производящему колбасу, скажут: «разбавляй ядовитым говном», он будет разбавлять?
Так разбавляют же всякими Exxx, и все вокруг в курсе, что это вредно.
Есть ли грань между этими случаями, насколько далеко допустимо заходить (поднять излучение на 5% можно, а на 1200% нельзя? А на 7% можно? А излучение на 7% выше нормы вреднее, чем отравленная колбаса?).
Нормальный технолог — нет, он придаст огласке и уволится.
Нет, фольксваген выпустил кучу оверклоченных в хламину серверов, в которых прикрутил опцию возвращающую настройки обратно в случае прохождения сертификации по ЭМИ.
а разве ответ на этот вопрос не зависит от наличия погонов у программиста? За создание Stuxnet никто не сидит.
Программистов, написавших софт спамбота — тоже расстрелять?
Почему то мне кажется, что решение о реализации такой фичи в автомобиле — принималось не в закрытой комнате одним человеком. Грубо говоря — вся команда ядра была в курсе. И если они приняли это решение — то либо это было решение начальства — мы не сможем реализовать эти тесты, делайте обход, либо кто то не укладывался в ТЗ ;) И сейчас просто назначают крайнего. Вот кого назначат — того все ругать и будут…
Я вот думаю — если тест непроходим настолько, что пришлось делать специальный режим работы двигателя — может надо в консерватории, в смысле в том месте, где эти тесты придумывают, что то поправить? Или мы просто движемся в сторону экологии как то так: значит так, мы тут решили, что надо выхлопы снизить в 100 раз, скорость и грузоподьемность поднять в 1000 раз, цену снизить в 2 раза. До завтра времени хватит? ;)
Почему то мне кажется, что решение о реализации такой фичи в автомобиле — принималось не в закрытой комнате одним человеком. Грубо говоря — вся команда ядра была в курсе. И если они приняли это решение — то либо это было решение начальства — мы не сможем реализовать эти тесты, делайте обход, либо кто то не укладывался в ТЗ ;) И сейчас просто назначают крайнего. Вот кого назначат — того все ругать и будут…
Я вот думаю — если тест непроходим настолько, что пришлось делать специальный режим работы двигателя — может надо в консерватории, в смысле в том месте, где эти тесты придумывают, что то поправить? Или мы просто движемся в сторону экологии как то так: значит так, мы тут решили, что надо выхлопы снизить в 100 раз, скорость и грузоподьемность поднять в 1000 раз, цену снизить в 2 раза. До завтра времени хватит? ;)
Программистов, написавших софт спамбота — тоже расстрелять?
Вот конкретно спамбота — да, причем желательно публично. В назидание.
разработка != использование.
В разработке любого софта нет ничего криминального. А вот тех кто заказывает и использует спамботов и других вредителей — там да, надо наказывать.
В разработке любого софта нет ничего криминального. А вот тех кто заказывает и использует спамботов и других вредителей — там да, надо наказывать.
И разработка — тоже может быть криминалом. Так же как и в реальной жизни: если ты делаешь ножи, которыми можно резать не только хлеб, но, в принципе, для убийства они не предназначены — то ты невиновен. Если делаешь что-то, что по своей сути «в мирных целях» использовать сложно — загремишь как соучастник.
В каждом конкретном случае нужно разбираться отдельно, а то так и создатели TeamViewer'а в преступники попадут. Но если создатель софта знал что он разрабатывает и зачем — да, конечно нужно наказывать,
В каждом конкретном случае нужно разбираться отдельно, а то так и создатели TeamViewer'а в преступники попадут. Но если создатель софта знал что он разрабатывает и зачем — да, конечно нужно наказывать,
Есть такое понятие «заведомо преступный приказ». Вся ответственность программистов в подобных случаях должна крутиться вокруг него.
Если я правильно помню, это понятие освобождает от выполнения приказа, а не от ответственности.
А после отказа от выполнения приказа маленький полевой трибунал может решить, что это попытка диверсии…
Неисполнение заведомо преступного приказа освобождает от ответственности за неисполнение, исполнение заведомо преступного приказа влечёт ответственность за исполнение наравне с отдавшим приказ, исполнение не заведомо преступного приказа освобождает от ответственности исполнителя приказа.
Получается, если исполнитель не в курсе, что нарушает закон, он и не виноват?
Если совсем не в курсе про закон запрещающий что-то делать, то виноват, если понимал, что делает. Если в курсе про такой закон, но введён в заблуждение отдающим приказ (в том числе самим фактом приказа), что нарушает, то не виноват.
Если программист не в курсе, про запрет на выдачу фэйковых данных при реальных испытаниях, но выполняет приказ «выдать фэйковые данные при испытаниях», то виноват. Если выполняет приказ «для отладочных целей выдавай фэйковые данные при таких-то условиях» и не должен знать, что они могут быть при реальных испытаниях, то не виноват.
Если программист не в курсе, про запрет на выдачу фэйковых данных при реальных испытаниях, но выполняет приказ «выдать фэйковые данные при испытаниях», то виноват. Если выполняет приказ «для отладочных целей выдавай фэйковые данные при таких-то условиях» и не должен знать, что они могут быть при реальных испытаниях, то не виноват.
Чего плохого в том, чтобы перевести двигло в более экологичный режим, если автомобиль стоит на месте? Тем более, что контроллеры и так умеют адаптироваться к условиям движения сто лет в обед.
Замечение актуально, если верно утверждение «режим тестирования определяется по неподвижным задним колесам».
Замечение актуально, если верно утверждение «режим тестирования определяется по неподвижным задним колесам».
может быть пора уже придумать аналог клятвы Гиппократа для программистов?..
Дизельгейт уже происходит не только с Volkswagen:
www.theguardian.com/environment/2015/oct/09/mercedes-honda-mazda-mitsubishi-diesel-emissions-row
www.theguardian.com/environment/2015/oct/09/mercedes-honda-mazda-mitsubishi-diesel-emissions-row
может все таки требования по выхлопам слегка надуманны? если уже пачка производителей их обходит?
С мочевиной, как я понимаю, в нормы попасть можно. Вот пусть и оснащают ей дизели. И нечего обманывать про дешевый, мощный и экологичный дизель.
;) А вы его купите? Или предпочтете все таки «дешевый, мощный и экономичный»?
Так в том-то и дело. Продают как дешевый, мощный, экологичный, а по факту можно выбрать только два. Обман.
Проблема в том, что дешевый и мощный купить нельзя по закону.
Ну и хорошо. Я хочу дышать чистым воздухом.
Тогда надо запретить дизель и ездить на электромобилях.
Потому что под современные экологические требования невозможно сделать нормальный бюджетный дизельный двигатель.
Потому что под современные экологические требования невозможно сделать нормальный бюджетный дизельный двигатель.
А коптить будет ТЭЦ, вырабатывающая для них электричество.
Да. С максимальным КПД, в отличии от ДВС, которые и близко так не умеют.
Нет, ну серьезно? Довод с ТЭЦ уже обсасывался тысячу раз.
ДВС — это маленькое и дешевое устройство, которое еще и должно уметь работать в широком спектре оборотов. В таких условиях КПД очень, ОЧЕНЬ плохенькое.
ТЭЦ и другие электростанции работают в максимально эффективном режиме. Им не надо быть компактными, им не надо быть сверх бюджетными, им не надо менять выход в зависимости от ситуации. Даже с учетом потерь на транспортировку и хранение электричества — потери все равно значительно меньше чем при работе ДВС(не говоря уж о том, что топливо тоже надо добывать и транспортировать).
И вот этот вот текст что я выше своими словами пересказал — постоянно упоминается. Но все равно появляется довод про ТЭЦ. Пичалька. :(
Нет, ну серьезно? Довод с ТЭЦ уже обсасывался тысячу раз.
ДВС — это маленькое и дешевое устройство, которое еще и должно уметь работать в широком спектре оборотов. В таких условиях КПД очень, ОЧЕНЬ плохенькое.
ТЭЦ и другие электростанции работают в максимально эффективном режиме. Им не надо быть компактными, им не надо быть сверх бюджетными, им не надо менять выход в зависимости от ситуации. Даже с учетом потерь на транспортировку и хранение электричества — потери все равно значительно меньше чем при работе ДВС(не говоря уж о том, что топливо тоже надо добывать и транспортировать).
И вот этот вот текст что я выше своими словами пересказал — постоянно упоминается. Но все равно появляется довод про ТЭЦ. Пичалька. :(
На самом деле тут слова не помогут, тут нужно в числах считать. Да, КПД двигателя на ТЭЦ выше, да, загрязнение ниже. Но. Есть ещё потери на транспортировке, проблемы хранения и обработки пиковых нагрузок и так далее. В конце-концов производство и утилизация аккумуляторов — та ещё радость. Так что получается ли в итоге выигрыш — это бооольшой вопрос.
P.S. Хотя, кстати, электромобили вполне могут сделать всю конструкцию экологичнее. Скажем ветряки обладают большой проблемой: у них выработка весьма и весьма неравномерная. Но если существенный процент энергии будет уходить на зарядку электромобилей, а оные электромобили согласятся заряжаться «по остаточному принципу» (а они согласятся если их владельцам скидку сделают), то можно будет «уравновешивать» энергосистему не только играясь с генерацией, но и поднимая/опуская потребление! В идеале можно вообще из электромобилей в сеть энергию высасывать (понятно что за плату и только в том случае есть владелец на это даст согласие).
P.S. Хотя, кстати, электромобили вполне могут сделать всю конструкцию экологичнее. Скажем ветряки обладают большой проблемой: у них выработка весьма и весьма неравномерная. Но если существенный процент энергии будет уходить на зарядку электромобилей, а оные электромобили согласятся заряжаться «по остаточному принципу» (а они согласятся если их владельцам скидку сделают), то можно будет «уравновешивать» энергосистему не только играясь с генерацией, но и поднимая/опуская потребление! В идеале можно вообще из электромобилей в сеть энергию высасывать (понятно что за плату и только в том случае есть владелец на это даст согласие).
Проблема транспортировки и хранения весьма актуальна и для нефтепродуктов. Танкеры регулярно тонны нефти сливают в океаны. Не говоря уж о всяких локальных загрязнениях при ДТП и на заправках.
По поводу утилизации аккумуляторов — активно ведуться работы по переработке старых аккумов в новые. Там же по сути нет ничего, что нельзя было бы повторно использовать.
Да, сейчас электромобили на уровне автомобилей с ДВС, в том числе и по экологии. Но фишка в том, что ДВС некуда улучшать, а у электромобилей и связанных с ними продуктами — улучшения только в начале пути.
По поводу утилизации аккумуляторов — активно ведуться работы по переработке старых аккумов в новые. Там же по сути нет ничего, что нельзя было бы повторно использовать.
Да, сейчас электромобили на уровне автомобилей с ДВС, в том числе и по экологии. Но фишка в том, что ДВС некуда улучшать, а у электромобилей и связанных с ними продуктами — улучшения только в начале пути.
Пусть делают небюджетные дизели, а бюджетными будут бензиновые двигатели, у них с этим попроще. А как иначе? Ослабление экологических норм — это какое-то странное решение, мой сосед, значит, экономит, а дышать мне.
скорее методику тестирования надо менять, требования не от хорошей жизеи придумали.
«Eсли бы у нас была настоящая профессия (видимо, здесь имеется в виду формальная причастность с сертификацией и лицензией, как у врачей — прим.перев.), то они бы предстали перед профессиональной комиссией, было бы проведено расследование, и если бы их признали виновными — выпнули бы из профессии с позором.»
Не переживайте. В Германии есть такие виды наказания за мошенничество — запрет заниматься определенным судом видом деятельности. Поэтому мошенников, вложившихся в свое обучение и временем и деньгами в этой стране довольно мало.
Не переживайте. В Германии есть такие виды наказания за мошенничество — запрет заниматься определенным судом видом деятельности. Поэтому мошенников, вложившихся в свое обучение и временем и деньгами в этой стране довольно мало.
Вопрос даже интереснее — разве в программистскую этику входит забота об окружающей среде?
«Выпнуть из профессии»? orly? Разве врача лишат лицензии, если он лечил, условно, «очень плохого человека»? Нет, лишат, если лечил плохо.
«Выпнуть из профессии»? orly? Разве врача лишат лицензии, если он лечил, условно, «очень плохого человека»? Нет, лишат, если лечил плохо.
А разве в какую либо этику входит обман? Врача в ФРГ ожидает таже участь, если его пациент потерял здоровье, которое уже не вернуть. Хотя и в России так же (если, например, припомнить историю косметических операций жены Пименова).
Точно такими же мотивами можно оправдать мошенника, «нашедшего» кредитную карточку кого-либо и «оформив кредит» на этого человека.
Специалист, которому предложили запрграммировать «этот трюк», должен быть совсем идит, чтоб не понимать, что это обман и мошенничество. Но наивные идиоты врядли программированием занимаются.
Пять лет назад, устроившись в одну фирмочу в ФРГ столкнулся с подобным вопросом. Из-за плохого на тот момент владения языком подписал одну бумажку этой конторы, что якобы участвовал в каких-то действиях по обучению практикантов. Фирме за это от города отчисляли немного денег и вероятно налоговые плюшки. Мой коллега просто отказался это делать и позже объяснил мне положерие дел. Тогда все обошлось, но думать стал лучше.
Точно такими же мотивами можно оправдать мошенника, «нашедшего» кредитную карточку кого-либо и «оформив кредит» на этого человека.
Специалист, которому предложили запрграммировать «этот трюк», должен быть совсем идит, чтоб не понимать, что это обман и мошенничество. Но наивные идиоты врядли программированием занимаются.
Пять лет назад, устроившись в одну фирмочу в ФРГ столкнулся с подобным вопросом. Из-за плохого на тот момент владения языком подписал одну бумажку этой конторы, что якобы участвовал в каких-то действиях по обучению практикантов. Фирме за это от города отчисляли немного денег и вероятно налоговые плюшки. Мой коллега просто отказался это делать и позже объяснил мне положерие дел. Тогда все обошлось, но думать стал лучше.
А разве в какую либо этику входит обман?
Обмана нет: была спецификация, по ней написано ПО. Честно — как задачу поставили — так и написано. Спрос с того, кто ставил задачу с прицелом на мошенничество.
Врача в ФРГ ожидает таже участь, если его пациент потерял здоровье, которое уже не вернуть.
Вот именно, давайте подумаем, кто является «пациентом» для программиста, и в чем здесь обман. Результат работы — здоровье или ПО, если проводить параллели. «Здоровье» не потеряно — если бы программиста обязали написать ПО, выполняющее такие-то функции, он написал бы ПО, которое не выполняет всего, что надо, но врет, будто бы ТЗ выполнено — это будет обман и «потеря здоровья».
Специалист, которому предложили запрграммировать «этот трюк», должен быть совсем идит, чтоб не понимать, что это обман и мошенничество. Но наивные идиоты врядли программированием занимаются.
Трюк как трюк. Это его, программиста, работа — писать ПО по техзаданию.
Ну вот на суде и будут ращбираться — тупо ли программисты реализовывали хитросоставленное техзадание или всетаки понимали какие процессы там идут.
В случае мошенничества нужно было сообщить об этом руководству. Не надо мне расказывать сказки, что за это могли уволить. Могли, конечно. Но по суду ещеб и компенсацию выплатили на пару десятилений вперед и такого международного скандала бы не было, все пресеклось бы на этой стадии. Это не Россия. Тут даже профсоюзы настоящие.
В случае мошенничества нужно было сообщить об этом руководству. Не надо мне расказывать сказки, что за это могли уволить. Могли, конечно. Но по суду ещеб и компенсацию выплатили на пару десятилений вперед и такого международного скандала бы не было, все пресеклось бы на этой стадии. Это не Россия. Тут даже профсоюзы настоящие.
Жестоко, но на самом деле было бы очень хорошо, если бы тех программистов признали виновными (желательно вместе с начальниками конечно). В следующий раз задумавшим пакость будет гораздо труднее найти исполнителей.
Отмазка «я просто выполнял приказ» не действует даже в отношении военных, почему другие профессии должны быть исключением?
Отмазка «я просто выполнял приказ» не действует даже в отношении военных, почему другие профессии должны быть исключением?
Отмазка «я просто выполнял приказ» не действует даже в отношении военных, почему другие профессии должны быть исключением?Подозреваю, что дела обстоят таким образом только в Нарнии, а в реальном мире попробуй доказать, что ты не верблюд, отказываясь выполнять сомнительный приказ.
Отмазка «я просто выполнял приказ» не действует даже в отношении военных
Не является преступлением причинение вреда охраняемым уголовным законом интересам лицом, действующим во исполнение обязательных для него приказа или распоряжения. Уголовную ответственность за причинение такого вреда несет лицо, отдавшее незаконные приказ или распоряжение.
Они это сделали.
…
И что вы предлагаете в таком случае?
Увольняться?
Или или читать менеджеру лекцию, которому насрать, и который, в случае чего, найдёт другого работника, который это сделает?
Почему вы не вините инженеров, которые спроектировали двигатель таким образом, что его можно перевести в такой режим?
Почему вы не вините менеджеров и руководство компании, которые и приказали это сделать?
Почему вы вините инструмент, а не того, кто этим инструментом управляет?
Почему вы вините инструмент, а не того, кто этим инструментом управляет?Потому что любой программист — это в первую очередь человек, а не инструмент. А если кто-то за «лишние три сребренника» готов писать ботов или отравлять людей — то не стоит прикрываться разного рода отмазками. Как тут хорошо заметили: отмазка «я просто выполнял приказ» не действует даже в отношении военных, почему другие профессии должны быть исключением?.
Что касается менеджеров — они, надо полагать, получать по заслугам, что касается инженеров — то это уже как бы вообще ни в какие ворота: зачем во всей этой системе вообще компьютер, если он такое допускает? Микросхемы и программы для того туда и засунуты, чтобы следить за режимами работы двигателя, больше в них никакого смысла нет!
Программисты — это такие большие дети. Они привыкли к полнейшей безответственности. Но это всё было хорошо пока между программой и вселенной стоял человек: какие бы там расчёты ни сделал компьютер в проекте Манхэттен в конечном итоге это были всего лишь рассчёты. Принимать их во внимание или нет — решали люди. Однако в последние десятилетия всё чаще так оказывается, что между компьютером и человеческой жизнью никого нет — а отмазки всё те же: «ой, я просто исполнял распоряжение… ой, я просто все перепутал и сделал ошибку». Почему эти отмазки не работают, когда рушится мост, но должны работать, когда софт всё «ставит раком»?
И, кстати, никто не предлагает программистов расстреливать: ведь архитекторов, которые неправильно спроектировали рухнувшее здание тоже не расстреливают, ведь правда? Происходит следствие, выясняют — кто виноват в том или ином косяке, определяется наказание (штраф или уголовка). Один и тот же болт может стоить три копейки и триста рублей в зависимости от того — прошёл ли он соответствующие испытания и можно ли будет на производителя потом «повесить» вину за упавший самолёт — но в мире ПО всё не так: самый супер-пупер-ынтырпрайз идёт все с теми же «гарантиями» — «в крайней случае вернём вам три рубля, которые вы заплатили за программу, но ни в коем случае не больше». А с чего вдруг? За что я, собственно, плачу покупая какой-нибудь Windows Server? За те два байта, которые кто-то в каком-то файлике увеличил? Ну так я и сам так сделать могу…
Давно пора было навести в этой области порядок и если эта встряска приведёт к каким-то положительным телодвижениям в этой области — я буду рад.
отмазка «я просто выполнял приказ» не действует даже в отношении военных, почему другие профессии должны быть исключением?
Не действует она только тогда, когда исполнитель приказа понимал, что совершает преступление. Грубо: исполнение приказа «уничтожить село со всеми жителями» подразумевает преступление, а исполнение приказа «ориентир 70, лево 5, дальность 300» — нет, если исполнитель точно не знает, что за этим целеуказанием скрывается заведомо гражданский объект. Если знает и понимает, что приказ заведомо преступный — срок. Если знает, но не понимает — психушка. Если не знает — единственное наказание только муки совести. Возможно.
Очень уж зыбкая граница между сроком и муками совести. Как определить знал солдат что там гражданский объект или нет? Да даже если знал, то он вполне мог считать, что делает благое дело «благодаря» пропаганде и/или религии.
Это дело следствия установить знал или нет. В демократических правовых государствах обычно в условиях презумпции невиновности, то есть следствие должно доказать, что солдат знал, а не солдат должен доказывать, что не знал.
А вот если считает, что совершая преступление делает благое дело, то срок обычно. Главное — понимал ли что совершает преступление, а по каким мотивам — дело десятое.
А вот если считает, что совершая преступление делает благое дело, то срок обычно. Главное — понимал ли что совершает преступление, а по каким мотивам — дело десятое.
Сравнивать гражданскую жизнь и военную вообще не корректно. На войне всегда убивают. Убивать — преступление. Но в силу каких-то политических и идеологических обстоятельство одно убийство является преступлением а другое убийство таковым не является, а может даже является заслугой достойной награды, и заранее это неизвестно, потому что критерии преступления будут определяться уже ПОСЛЕ окончания войны и не законом, а законом ПОБЕДИТЕЛЯ в этой войне.
Давно пора было навести в этой области порядок и если эта встряска приведёт к каким-то положительным телодвижениям в этой области — я буду рад.
Ничего не изменится, пока есть много людей (принимающих решения о покупке софта), которые, выбирая между софтом с ответственностью но ценой в 10 (100) раз больше, выберут оставить всё как есть. Если продавить законодательно, просто покупать не будут, нанимая знакомого Васю «ну напиши нам SQL-сервер за 3 копейки и 2 месяца, а если в нём будут глюки, исправишь, мы тебя наказывать не будем» и всё вернётся на круги своя.
С таким подходом и убийц наказывать не нужно. Всегда же можно за бутылку найти в подворотне исполнителя, как с этим бороться?
Убийца в курсе, что нарушает закон, в том-то и дело. А если он не в курсе, что есть статья за убийство, то это его проблемы. В итоге виноваты будут оба.
Тут вопрос не в этической, а в экономической составляющей.
Желание спросить с разработчиков за их баги непременно выльется в финансовую страховку всех их рисков.
Желание спросить с разработчиков за их баги непременно выльется в финансовую страховку всех их рисков.
Да. Рассмешили. На фольксвагене программисты работают за 3 копейки. И еще они нанимают для разработки индусов по аутсорсу.
Специалисты в концернах такого класса в худшем случае работают по тарифам, где самый минимум 2000евро нетто(уже с учетом налогов) и максимум 3500(5000 брутто). А скорее всего работаю по отдельным договорам, где заработок от 60000 брутто в год.
За такие деньги ошибок быть не должно — каждая ошибка и ее последующее исправление обходится концерну в миллиардные убытки. Поэтому тестирование идет не на коленке, а на специальных стендах и выполняется специальнообученными людьми.
Специалисты в концернах такого класса в худшем случае работают по тарифам, где самый минимум 2000евро нетто(уже с учетом налогов) и максимум 3500(5000 брутто). А скорее всего работаю по отдельным договорам, где заработок от 60000 брутто в год.
За такие деньги ошибок быть не должно — каждая ошибка и ее последующее исправление обходится концерну в миллиардные убытки. Поэтому тестирование идет не на коленке, а на специальных стендах и выполняется специальнообученными людьми.
За $60k евро в год не должно быть ошибок? Рассмешили. Сейчас стандартная зарплата посредственного кодера-индуса который умеет по английский и немного по C++ начинается от $100k евро в год и ошибок он делает столько, что можно лопатой разгребать. Чтобы ошибок почти не было придётся тратить наверно около $10m (да, в 100 раз больше) за тот же небольшой объём несложного кода.
«Но только почти, только почти» :)
Это где же столько платят «посредственным индусам»? Расточительство же!
Есть ошибки. Вы уж определитесь, в евро или долларах. Очень может быть, что индусы в сша получают намного круче. Но 60000 евро в год это довольно приличная работа для программера. Можете посмотреть о показателях зарблаты именно в Niedersachsen (именно там располагается головной завод в Wolfsburg) на http://gehalt.de. Или можете посмотреть на любых сайтах по поиску работы в этом регионе.
Серьезно? В крупных компаниях Senior'ы могут получать с бонусами $200K, и за эти диньги никто не требует от них полного отсутствия ошибок, все понимают что ошибки неизбежны. Чтобы требовать отсутствия ошибок и при этом если эти ошибки будут грозить штрафами/тюрьмой — ценник должен начинаться от $500К и поверьте за эти деньги работать будут раз в 10 медленнее чем работают в нормальных условиях. Эквивалентная продуктивность будет более чем на порядок ниже. Оплатите разницу?
Между 500к и 200к нет принципиальной разницы. Это как между 1-м и 2-мя миллиардами нету разницы: что так что так денег больше чем нужно. Вот если платить скажем 3 миллиона в год (цена хорошего дома), то здесь уже есть мотивация больше работать.
За 200000 сеньоры несут пермональную отвественность. И если программера за 60килоевро на первый случай могут и простить (что сомнительно судя по размерам ущерба), то сеньора просто сразу же уволят с надлежащей рецензией.
И в этом конкретном случае речь идет не об ошибках, а о намеренном изменении кода.
Отсюда вывод — сеньор сам по себе человек разумный и не мог не знать о том, что программирует код для мошенничества. Или это был приказ откудато сверху.
В любом случае сейчас спорить глупо. Пройдет разбирательство.тогда послушаем, что официально заявят.
И в этом конкретном случае речь идет не об ошибках, а о намеренном изменении кода.
Отсюда вывод — сеньор сам по себе человек разумный и не мог не знать о том, что программирует код для мошенничества. Или это был приказ откудато сверху.
В любом случае сейчас спорить глупо. Пройдет разбирательство.тогда послушаем, что официально заявят.
Не согласен. В нормальных компаниях людей не увольняют за ошибку даже если она компании стоила миллионы долларов, они поинмают что ошибаются все. Конечно если человек делает факап за факапом — это повод уже, а просто за пару багов — уволят очень вряд ли. Даже если это приведет к миллионным потерям.
За одну ошибку может и не уволят. Это все зависит от многих причин, в том числе и личностных — отношение других сотрудников именно к этому человеку, руководства и пр. К томуже все чтут законодательство. Но если ошибки повторяются часто, то уже есть законодательный повод расстаться.
А если убытки исчисляются миллиардами и потерей рынка?
А если убытки исчисляются миллиардами и потерей рынка?
Если убытки исчисляются миллиардами — то это 100% разработчик не виноват. Если в компании один разработчик может ошибиться на миллиарды долларов — это значит что в руководстве компании вероятно находятся идиоты и они виноваты в первую очередь.
Если человек постоянно что-то сильно портит — значит он просто не соответствует квалификации. Если человек даже пару раз подряд «потерял» несколько миллионов — это в первую очередь повод пересмотреть процесс — почему такое вообще возможно, людей обычно не увольняют за это.
А законодательный повод расстаться на родине большинства крупнейших IT компаний — любой (в большинстве мест есть менее 10 исключений). Т.е. уволить можно за то что цвет волос не понравился или вообще без объяснения причин или за то что человек болеет часто. Тем не менее увольняют только если человек не соответствует квалификации.
Если человек постоянно что-то сильно портит — значит он просто не соответствует квалификации. Если человек даже пару раз подряд «потерял» несколько миллионов — это в первую очередь повод пересмотреть процесс — почему такое вообще возможно, людей обычно не увольняют за это.
А законодательный повод расстаться на родине большинства крупнейших IT компаний — любой (в большинстве мест есть менее 10 исключений). Т.е. уволить можно за то что цвет волос не понравился или вообще без объяснения причин или за то что человек болеет часто. Тем не менее увольняют только если человек не соответствует квалификации.
Я все понимаю, но… В ТОЙ стране (про ЭТУ даже и начинать не будем) людей толпами сжигал всего 70 лет назад. Не со зла. Исключительно из дисциплины и по приказу.
Посмотрите на авиаотрасль — вот там и гарантии и жёсткие сертификации и много чего ещё. НО:
— там вхлам устаревшие технологии _повсеместно_ (уровень софтверных технологий там ~80-90ые годы прошлого века… в лучшем случае — подобрались к 0ым,
— стоимость этого ПО — адовая. Хотите Windows Server 2000 за x*10000 денег? Наверное нет? А почему? Там же производитель ПО будет ОТВЕТСТВЕННЕН!
Короче, люди, не судите и не судимы будете. Вы не знаете всех обстоятельств, но крики возносите до небес…
— там вхлам устаревшие технологии _повсеместно_ (уровень софтверных технологий там ~80-90ые годы прошлого века… в лучшем случае — подобрались к 0ым,
— стоимость этого ПО — адовая. Хотите Windows Server 2000 за x*10000 денег? Наверное нет? А почему? Там же производитель ПО будет ОТВЕТСТВЕННЕН!
Короче, люди, не судите и не судимы будете. Вы не знаете всех обстоятельств, но крики возносите до небес…
Я вот только не понял что такого плохого вы увидели в авиации. Как будто устарелость технологий сама по себе — это что-то плохое. Оно что — работает от этого хуже? Падает чаще? Не замечал у себя за окнами эшелонов самолётов врезающихся в землю, уж извините.
А что окошки не такие красивые — ну так без этого прожить, в общем, можно.
А что окошки не такие красивые — ну так без этого прожить, в общем, можно.
Да ничего плохого, кроме огромной стоимости поддержки и внедрения новых фич.
Я вам конкретный кейс предложил — купили бы вы супер-надёжную с кучей сертификатов и гарантий лицензию на 1! ядро процессора Windows Server 2000 за сумму равную стоимости Windows Server 2012 R2 * 10 000?
Сама по себе устарелость технологий — это боль от попыток внедрения чего-либо современного, это боль от юзабилити древних времён и это ещё куча нюансов. И да, оно работает не хуже, но могло бы работать лучше. Авиаотрасль такова, что там деваться особо некуда — авиакатострофы никому не нужны. Отрасль атомной энергетики аналогична. Отрасль автомобилестроения — рангом ниже (там множитель всего порядка 100 получится к актуальной цене и отставание не 15-20 лет, а 5-10).
Сама по себе устарелость технологий — это боль от попыток внедрения чего-либо современного, это боль от юзабилити древних времён и это ещё куча нюансов. И да, оно работает не хуже, но могло бы работать лучше. Авиаотрасль такова, что там деваться особо некуда — авиакатострофы никому не нужны. Отрасль атомной энергетики аналогична. Отрасль автомобилестроения — рангом ниже (там множитель всего порядка 100 получится к актуальной цене и отставание не 15-20 лет, а 5-10).
Почему эти отмазки не работают, когда рушится мост, но должны работать, когда софт всё «ставит раком»?
Потому-что хороший код, внезапно, никому, кроме самих программистов, не нужен: всем нужно по-быстрому накостылять, чтобы было что продавать. Там, где не нужно чтобы что-то встало раком, там ведут контроль. А там, где нужно чтобы что-то встало раком, всё делается так, чтобы что-то встало раком. Как и требовалось.
Или вы предлагаете выгонять с работы тех, кто выполняет, собственно, свою работу?
«в крайней случае вернём вам три рубля, которые вы заплатили за программу, но ни в коем случае не больше». А с чего вдруг? За что я, собственно, плачу покупая какой-нибудь Windows Server?Нет проблем. Хотите MySQL с гарантиями? Пожалуйте $3M за лицензию в год. ОС? $10M за лицензию в базовой комплектации, обновление лицензии через год — $8M. Устанавливать это можно только на специальное железо (ценник придумайте сами) и работать с этим могут только люди получившие специальную лицензию (конечно лицензия не бесплатна и требует продления раз в пол года). Откуда вы думаете возьмутся гарантии? Просто покупатели будут оплачивать все возможные выплаты по искам + все издержки и дополнительные затраты на проверку кода из своего кармана. Вот только готов поспорить что не будете вы покупать ПО за такой ценник.
Откуда вы думаете возьмутся гарантии?Оттуда же, откуда и всегда. Почему-то когда взрывается аккумулятор и сгорает дом — то виновность производителя не ограничивается стоимостью копеечного аккумулятора, когда глючит копеечный чипсет — то его отзывают, чтобы данные не терялись, а когда «падает» сервер за несколько тысяч долларов — то выясняется, что никто ни в чём не виноват и ради получения хоть каких-то гарантий платить "$10M за лицензию в базовой комплектации". Почему вдруг? Кто-то заставлял делать эту ОС через тяп-ляп так, чтобы она всё время глючила? Нет — всё наоборот: поскольку годами «тяп-ляп» сходило с рук, то теперь ничего другого и нет, вот и всё. Но это не значит, что нужно всё так и оставить. Нет, это просто означает, что вводить отвественность за брак в ПО нужно постепенно, вот и всё.
Система делась под определенные условия (читай «отказ от обязательств»). Та же система но с гарантиями по определению будет делаться во-первых дольше, во-вторых дороже, а в-третьих после такого дев. цикла еще может оказаться невостребованной на рынке. Если взять прикидку, что 80% результата можно достигнуть за 20% ресурсов, то можете прикинуть стоимость ПО со значительно более высоким качеством. Особенно интересно, что большинству такой софт вообще не нужен и стоимость ошибок достаточно низка.
Так что «тяп-ляп» тут ни при чем: чего хотели, то и получили. Вам не нравится эта ОС? Возьмите другую. Другой нет — ну можете написать сами.
Так что «тяп-ляп» тут ни при чем: чего хотели, то и получили. Вам не нравится эта ОС? Возьмите другую. Другой нет — ну можете написать сами.
Особенно интересно, что большинству такой софт вообще не нужен и стоимость ошибок достаточно низка.Пока «стоимость ошибок была достаточно низка» вопросов не было. Сейчас стомость ошибоки выросла, а подходы остались. Но ничего страшного: если ИТ-индустрия не готова заняться разгребанием своих авгиевых конюшен, то за неё это сделают законодатели. Ну а если вода пущенная из соседней речки смоет чего к чертям собачьим — ну так это мелочи, вы сами к этому стремились.
Мне кажется, вы не вполне уловили мою мысль. Если коротко — то все реально, но платить будет клиент. Особенно в случае законодательных изменений в сторону обязательной ответственности (про смерть опен сорса при таком подходе я даже не говорю).
В вашем примере со сточными водами все, как мне кажется, будет довольно просто. Условный производитель ОС просто будет по разному лицензировать один и тот же софт для разных видов деятельности с разной ценой ошибки. Или даже вообще не предлагать его в некоторых случаях. При этом стоимость такой лицензии будет выше на пару порядков, чтобы покрыть возможные риски. А если вам, как клиенту, такой подход не подходит, то можете выбрать любой другой доступный вам способ организации ИТ структуры.
В вашем примере со сточными водами все, как мне кажется, будет довольно просто. Условный производитель ОС просто будет по разному лицензировать один и тот же софт для разных видов деятельности с разной ценой ошибки. Или даже вообще не предлагать его в некоторых случаях. При этом стоимость такой лицензии будет выше на пару порядков, чтобы покрыть возможные риски. А если вам, как клиенту, такой подход не подходит, то можете выбрать любой другой доступный вам способ организации ИТ структуры.
Мне кажется, вполне можно обойтись без «платить будет клиент». Совершенно не секрет, что ИТ-отрасль до сих пор работает на сверхприбылях, и если производители самолётов/автомобилей счастливы, когда выходят на маржу 20%, то ИТшные компании воротят нос при маржинальности 50%. И они не несут никакой ответственности лишь потому, что спрос на рынке до сих пор значительно превышает предложение, а государственного регулирования нет никакого. Если рынок зарегулировать и поумерить аппетиты держателей ИТ-бизнеса, ничего страшного с ценами не произойдет. Грубо говоря, пожертвовав 5% маржи на страховые фонды, ИТ-компании не пострадают.
Это относится только к компаниям типа Microsoft.
Огромный пласт ИТ — работа с индивидуальными заказчиками, там много головной боли нет эффекта масштаба. Представьте себе контору, которая делает систему учёта для городских электросетей. Туда вносится информация по абонентам, а также схемы связности сетей и планы замен кабелей и муфт. Ежемесячный платёж в 1 млн. руб. (а больше сети давать жмотятся) еле хватает, чтобы заплатить всем з/п и запасти небольшую подушку на разные случаи.
Огромный пласт ИТ — работа с индивидуальными заказчиками, там много головной боли нет эффекта масштаба. Представьте себе контору, которая делает систему учёта для городских электросетей. Туда вносится информация по абонентам, а также схемы связности сетей и планы замен кабелей и муфт. Ежемесячный платёж в 1 млн. руб. (а больше сети давать жмотятся) еле хватает, чтобы заплатить всем з/п и запасти небольшую подушку на разные случаи.
Совершенно не секрет, что ИТ-отрасль до сих пор работает на сверхприбылях
ЭЭЭ… правда? Или вы это по ФБ и Гуглу только судите?
И они не несут никакой ответственности лишь потому, что спрос на рынке до сих пор значительно превышает предложение
Нет. Они просто не позиционируют свой продукт, как настолько надежный, чтобы быть ответственным за возможные ошибки. Альтернатива этому «сертифицированные» версии продукта, за совсем другие деньги, которые идут и с инсталляцией (железо, сопутствующий набор софта) и поддержкой. Но цена совсем другая.
Грубо говоря, пожертвовав 5% маржи на страховые фонды, ИТ-компании не пострадают.
Цифра там совсем другая.
то ИТшные компании воротят нос при маржинальности 50%Да ну? Ну давайте например поделим прибыль на доход у Google: 14.4B/66B = 22%, что то нос не воротят. Может кто другой воротит? Например Apple 39.5B/183B = 22% — тоже не воротит. Facebook 2.4B/12.5B = 19%, Microsoft 12.2B/93.5B = 13%, Может Amazon воротит? Ан, нет, у Amazon последний год вообще 300 миллионов убыток. Не вижу я 50%, даже близко к 50% не вижу. 5% маржи это вообще смешно, возьмем Apple с одним из самых больших отношений дохода на сотрудника. 5% от маржи это 2 миллиарда или ~17 тысяч долларов на сотрудника в год (и это до налогов), думаете кто то согласится за +17К брать на себя такую ответственность что можно в тюрьму попасть? А вы предлагаете по сути всех сотрдников сделать более квалифицированными, и еще кучу лишнего времени тратить на обеспечение мало кому нужного качества — 5% маржи тут не спасет дело. Даже 100% маржи тут дело не спасет т.к. во первых возрастут ставки (мало кто согласится на такую ответственность за скромную прибавку к ЗП), во вторых сильно возрастет время создания продукта.
Только чтобы узнать маржинальность, вы поделите прибыль до налогообложения, а не после. Цифры поменяются :)
> А вы предлагаете по сути всех сотрдников сделать более квалифицированными
Я предлагаю сделать ответственность соответствующей нанесённому ущербу. А уж квалифицированными станут сотрудники или нет, это уже не принципиально. Рынок сам отрегулируется. Производитель вашего автомобиля несёт полную ответственность за его исправность и возможный ущерб, который автомобиль нанесёт кому-либо вследствие неправильной работы, например, систем торможения или безопасности. Производитель пакета с молоком также несёт ответственность за его чистоту и отсутствие инфекций. И ни автомобиль, ни молоко от этого не стали стоить космических денег.
> А вы предлагаете по сути всех сотрдников сделать более квалифицированными
Я предлагаю сделать ответственность соответствующей нанесённому ущербу. А уж квалифицированными станут сотрудники или нет, это уже не принципиально. Рынок сам отрегулируется. Производитель вашего автомобиля несёт полную ответственность за его исправность и возможный ущерб, который автомобиль нанесёт кому-либо вследствие неправильной работы, например, систем торможения или безопасности. Производитель пакета с молоком также несёт ответственность за его чистоту и отсутствие инфекций. И ни автомобиль, ни молоко от этого не стали стоить космических денег.
Производитель пакета с молоком также несёт ответственность за его чистоту и отсутствие инфекций. И ни автомобиль, ни молоко от этого не стали стоить космических денег.
Если из-за пакета несвежего молока сорвётся сделка на полмиллиарда, молочник эту сумму компенсировать не будет.
В случае с Windows заранее неизвестно, какой и где может быть ущерб. Производитель может заранее заявить — эта версия предназначена исключительно для дома, эта — для офиса, в бортовые системы и АЭС ставить нельзя, ущерб заведомо не более 5 баксов. Ах да, они сейчас в точности так и пишут в EULA — что бы ни случилось, компенсация фиксированная.
Производитель может заранее заявить — эта версия предназначена исключительно для дома, эта — для офиса, в бортовые системы и АЭС ставить нельзя, ущерб заведомо не более 5 баксов.Производитель, собственно, так и делает: есть Windows Home Edition, есть Windows Profession, есть Windows для серверов…
Ах да, они сейчас в точности так и пишут в EULA — что бы ни случилось, компенсация фиксированная.Проблема в том, что компансация фиксированная для всех версий, которые при этом по цене всё-таки отличаются весьма существенно. За что тогда плата, если не за дополнительные гарантии? За то, что в реестре пара чисел поменялась?
Только чтобы узнать маржинальность, вы поделите прибыль до налогообложения, а не после. Цифры поменяются :)Google: Pretax: 17.2B, net: 14.4B. Revenue: 66B. Разница 26% vs 22%. Для остальных компаний аналогично, так что советую в следующий раз прежде чем бросаться словами — хотябы изучить матчасть чтобы не позориться. Кроме того маржа до налогов мало важна, но даже если ее считать все равно вы чушь городите.
Я предлагаю сделать ответственность соответствующей нанесённому ущербу. А уж квалифицированными станут сотрудники или нет, это уже не принципиально. Рынок сам отрегулируется.Ага, платить за это будут из своего кармана. Рынок магическим образом эти деньги ни от куда не возьмет, а не магическим образом — будете платить за лицензию в 10 раз дороже, opensource убьете и все сопутствующее, включая сильное замедление прогресса в этой области.
Производитель вашего автомобиля несёт полную ответственность за его исправность и возможный ущерб, который автомобиль нанесёт кому-либо вследствие неправильной работы, например, систем торможения или безопасностиЕсли автомобиль сломается из-за чего я опоздаю на совещание и сорвется сделка — удачи вам выбивать компенсацию. И опять же, для тех до кого долго доходит — производитель автомобилей может позволить себе это потому что наценка будет не так существенна, т.к. случаи проблем крайне редки. Вы упускаете из виду что отрасли несравнимы. Сравнивать пакет молока с ОС — это конечно сильно. Вероятность того что в автомобиле лопнет например рулевой вал или откажут тормоза по вине производителя — крайне мала. А если у вас двигатель заглохнет и вы не ожидая этого попадете в ДТП — опять же, удачи выбивать деньги у производителя, 99% вы будете виноваты т.к. должны подобный случай предусматривать а не обгонять перестраиваясь за метр от встречной машины.
Кстати, в случаем с протухшим молоком вам запросто скажут что протухшее молоко чувствуется на вкус и поэтому надо было не пить. А случаи с инфекциями столь редки и не так дороги в предотвращении что опять же можно взять ответственность.
> Ага, платить за это будут из своего кармана. Рынок магическим образом эти деньги ни от куда не возьмет, а не
> магическим образом — будете платить за лицензию в 10 раз дороже
Вы всерьёз считаете, что среди ИТ-компаний не найдется достаточно желающих взять на себя риски и тем самым выдавить с рынка задравших лицензию в 10 раз?
> opensource убьете и все сопутствующее, включая сильное замедление прогресса в этой области.
Я не предлагаю убивать opensource. Когда магазин мне продает товар, он несёт ответственность за его качество. Когда мне товар безвозмездно даёт в пользование благотворитель, он никакой ответственности не несёт. Это исключительно вопрос наличия сделки между поставщиком и покупателем.
> Вероятность того что в автомобиле лопнет например рулевой вал или откажут тормоза по вине производителя
> крайне мала.
И тем не менее, как только автопроизводитель обнаруживает потенциальный дефект конструкции, он отзывает автомобили для модернизации. Не ради заботы об окружающих, а ради того, чтобы себя обезопасить от судебных исков.
> А если у вас двигатель заглохнет и вы не ожидая этого попадете в ДТП — опять же, удачи выбивать деньги у
> производителя
Интересно, откуда у вас такая уверенность? Во всех цивилизованных странах ДТП из-за проблем в конструкции или брака автомобиля гарантированно влечёт за собой полную компенсацию ущерба производителем плюс ещё моральный сверху. Вы там выше стандартный шаблон интернет-тролля упоминали, называется «учите матчасть и не позорьтесь». Я сейчас могу его вам торжественно вручить обратно :)
Поймите, я не предлагаю карать баблом и уголовкой разработчиков за каждый найденный баг. Но, грубо говоря, если конкретно продаваемый функционал не работает, и как раз это нанесло ущерб потребителю, за это надо платить. И единственное последствие этого — с рынка уйдут раздолбаи, которые не способны организовать контроль качества.
Пример: учетная система из-за программной ошибки удалила накладную и инвойс от поставщика. Кредиторка, соответственно, не видна, предприятие просрочило оплату и попало на штраф из-за этого сбоя. Виноват ли поставщик учётной системы в данном случае? Виноват. Потому что этот функционал так же важен, как работа тормозной системы у автомобиля.
> магическим образом — будете платить за лицензию в 10 раз дороже
Вы всерьёз считаете, что среди ИТ-компаний не найдется достаточно желающих взять на себя риски и тем самым выдавить с рынка задравших лицензию в 10 раз?
> opensource убьете и все сопутствующее, включая сильное замедление прогресса в этой области.
Я не предлагаю убивать opensource. Когда магазин мне продает товар, он несёт ответственность за его качество. Когда мне товар безвозмездно даёт в пользование благотворитель, он никакой ответственности не несёт. Это исключительно вопрос наличия сделки между поставщиком и покупателем.
> Вероятность того что в автомобиле лопнет например рулевой вал или откажут тормоза по вине производителя
> крайне мала.
И тем не менее, как только автопроизводитель обнаруживает потенциальный дефект конструкции, он отзывает автомобили для модернизации. Не ради заботы об окружающих, а ради того, чтобы себя обезопасить от судебных исков.
> А если у вас двигатель заглохнет и вы не ожидая этого попадете в ДТП — опять же, удачи выбивать деньги у
> производителя
Интересно, откуда у вас такая уверенность? Во всех цивилизованных странах ДТП из-за проблем в конструкции или брака автомобиля гарантированно влечёт за собой полную компенсацию ущерба производителем плюс ещё моральный сверху. Вы там выше стандартный шаблон интернет-тролля упоминали, называется «учите матчасть и не позорьтесь». Я сейчас могу его вам торжественно вручить обратно :)
Поймите, я не предлагаю карать баблом и уголовкой разработчиков за каждый найденный баг. Но, грубо говоря, если конкретно продаваемый функционал не работает, и как раз это нанесло ущерб потребителю, за это надо платить. И единственное последствие этого — с рынка уйдут раздолбаи, которые не способны организовать контроль качества.
Пример: учетная система из-за программной ошибки удалила накладную и инвойс от поставщика. Кредиторка, соответственно, не видна, предприятие просрочило оплату и попало на штраф из-за этого сбоя. Виноват ли поставщик учётной системы в данном случае? Виноват. Потому что этот функционал так же важен, как работа тормозной системы у автомобиля.
Вы всерьёз считаете, что среди ИТ-компаний не найдется достаточно желающих взять на себя риски и тем самым выдавить с рынка задравших лицензию в 10 раз?-Производители молока должны покрывать упаковки золотом
-Но это приведет к значительному подорожанию молока, неужели вы не понимаете?
-Вы всерьез считаете что среди производителей молока не найдется достаточно желающих провадать молоко по той же цене что и было раньше?
Понимаете какую глупость сказали? Вы прадлегаете сильно усложнить поддержку кода, сильно замедлить его написание, требовать намного выше уровень программистов и еще повесить на них ответственность — все это влечет к увеличению затрат, а еще есть кумулятивный эффект когда вы просто обнаруживаете себя в ситуации что программисты достаточной квалификации кончились на рынке и линейно уже ничего не масштабируется, это приведет к еще большему росту цен. Но конечно, рынок же волшебный, обяжи обшивать пакеты молока золотом и он сам волшебным образом вернет цену на место.
Я не предлагаю убивать opensource. Когда магазин мне продает товар, он несёт ответственность за его качество.Так и сейчас хотите ответственности — платите миллиард и получайте. А то что вы платите — это покрывает только расходы на разработку.
И тем не менее, как только автопроизводитель обнаруживает потенциальный дефект конструкции, он отзывает автомобили для модернизации. Не ради заботы об окружающих, а ради того, чтобы себя обезопасить от судебных исков.И программисты баги фиксят, представляете? Ровно в такой же мере как отзывают машины.
Интересно, откуда у вас такая уверенность? Во всех цивилизованных странах ДТП из-за проблем в конструкции или брака автомобиля гарантированно влечёт за собой полную компенсацию ущерба производителем плюс ещё моральный сверху.Читайте внимательнее. Если у вас отказали тормоза — да. Но если вы нарушили правила, вышли на опасный обгон и двигатель встал — то виноваты вы, просто потому что везде в правилах написано что так делать нельзя и ваши действия поставили всех в аварийную ситуацию в которой любая из десятков проблем могла привести к аварии. Кстати, если parking assist ударит другую машину — виноваты будете полностью вы тоже, если адаптивный круиз-контроль «поцелует» кого-то в бампер — то виноваты тоже будете вы.
Поймите, я не предлагаю карать баблом и уголовкой разработчиков за каждый найденный баг. Но, грубо говоря, если конкретно продаваемый функционал не работает, и как раз это нанесло ущерб потребителю, за это надо платить.Я же говорю — SQL сервер $6M за годовую лицензию + 5% от стоимости предприятия (чтобы масштабировать на потенциальный ущерб). Готовы купить?
И единственное последствие этого — с рынка уйдут раздолбаи, которые не способны организовать контроль качества.Прямо мир розовых единорогов. Много найдете программистов готовых взять на себя эту ответственность? Это нанесет огромный удар по индустрии и выше уже отписано почему.
учетная система из-за программной ошибки удалила накладную и инвойс от поставщика. Кредиторка, соответственно, не видна, предприятие просрочило оплату и попало на штраф из-за этого сбоя.Если в договоре прописаны гарантии — то виноват, если не прописаны — то не виноват. На этот случай во всех договорах пишут что «в случае обстоятельств неприодолимой силы штрафы не накладываются» и подобное — т.к. баг в системе ни от кого не зависил — то по договору штрафа не будет.
> Понимаете какую глупость сказали? Вы прадлегаете сильно усложнить поддержку кода, сильно замедлить
> его написание, требовать намного выше уровень программистов и еще повесить на них ответственность
Я сказал как раз не глупость. Это вы почему-то считаете, что рядовое выполнение своих обязанностей не через задницу у программистов должно сильно замедлить написание и требовать намного выше уровень квалификации. С каких это пор написание просто качественного кода оказывается дороже, чем написание некачественного кода, а потом его мучительное сопровождение и фиксы? Другой вопрос, что первое потребует потратить больше средств «сейчас», а второе позволяет растянуть затраты во времени, пусть в итоге и общая стоимость будет больше. И естественно, компании, которые неспособны наладить культуру разработки, уйдут с рынка и оставят место тем, которые способны.
> Но если вы нарушили правила, вышли на опасный обгон и двигатель встал
Конечно же, если нарушили правила и попали в аварию… и если кувалдой стукнули, то автопроизводитель не виноват. И соответственно, никто и не говорит, что разработчиков софта надо ругать за баги, когда серверную стойку залило водой с протекшей крыши, или когда в метро украли ноутбук.
> Много найдете программистов готовых взять на себя эту ответственность?
> Это нанесет огромный удар по индустрии и выше уже отписано почему.
Много. Я не преувеличиваю. Ладно, отставим в сторону автомобили, это пример абстрактный. Давайте посмотрим на разработчиков, например, микросхем. У них и сложность работы, и характер этой самой работы весьма близки к разработке ПО. С одним нюансом: у них недопустимы баги в продакшене. Любой чип с багом — это негодная и зачастую отправленная в утиль вся серия устройств на этом чипе. И ничего, при таком раскладе живут себе и здравствуют. И мы не наблюдаем ПЛИС по $6M или чипов памяти по 5% от стоимости предприятия.
> На этот случай во всех договорах пишут что «в случае обстоятельств неприодолимой силы штрафы не
> накладываются» и подобное — т.к. баг в системе ни от кого не зависил — то по договору штрафа не будет.
У вас, мягко говоря, неожиданное понимание сути форс-мажора в договорных отношениях. :D
Конечно же, баг — это обстоятельство неприодолимой силы. Баг, он дан нам свыше, и мы можем с ним только смириться. А попытка бороться с багами уничтожит отрасль разработки ПО.
Вы знаете, сарказм сарказмом, но за всеми вашими «аргументами» выглядывает всего лишь одна первопричина. Она звучит примерно так: «Да не собираюсь я напрягаться и работать качественно! Мне нравится как сейчас, когда я пишу что хочу и как хочу, и никто мне не вправе выдвигать претензии.»
> его написание, требовать намного выше уровень программистов и еще повесить на них ответственность
Я сказал как раз не глупость. Это вы почему-то считаете, что рядовое выполнение своих обязанностей не через задницу у программистов должно сильно замедлить написание и требовать намного выше уровень квалификации. С каких это пор написание просто качественного кода оказывается дороже, чем написание некачественного кода, а потом его мучительное сопровождение и фиксы? Другой вопрос, что первое потребует потратить больше средств «сейчас», а второе позволяет растянуть затраты во времени, пусть в итоге и общая стоимость будет больше. И естественно, компании, которые неспособны наладить культуру разработки, уйдут с рынка и оставят место тем, которые способны.
> Но если вы нарушили правила, вышли на опасный обгон и двигатель встал
Конечно же, если нарушили правила и попали в аварию… и если кувалдой стукнули, то автопроизводитель не виноват. И соответственно, никто и не говорит, что разработчиков софта надо ругать за баги, когда серверную стойку залило водой с протекшей крыши, или когда в метро украли ноутбук.
> Много найдете программистов готовых взять на себя эту ответственность?
> Это нанесет огромный удар по индустрии и выше уже отписано почему.
Много. Я не преувеличиваю. Ладно, отставим в сторону автомобили, это пример абстрактный. Давайте посмотрим на разработчиков, например, микросхем. У них и сложность работы, и характер этой самой работы весьма близки к разработке ПО. С одним нюансом: у них недопустимы баги в продакшене. Любой чип с багом — это негодная и зачастую отправленная в утиль вся серия устройств на этом чипе. И ничего, при таком раскладе живут себе и здравствуют. И мы не наблюдаем ПЛИС по $6M или чипов памяти по 5% от стоимости предприятия.
> На этот случай во всех договорах пишут что «в случае обстоятельств неприодолимой силы штрафы не
> накладываются» и подобное — т.к. баг в системе ни от кого не зависил — то по договору штрафа не будет.
У вас, мягко говоря, неожиданное понимание сути форс-мажора в договорных отношениях. :D
Конечно же, баг — это обстоятельство неприодолимой силы. Баг, он дан нам свыше, и мы можем с ним только смириться. А попытка бороться с багами уничтожит отрасль разработки ПО.
Вы знаете, сарказм сарказмом, но за всеми вашими «аргументами» выглядывает всего лишь одна первопричина. Она звучит примерно так: «Да не собираюсь я напрягаться и работать качественно! Мне нравится как сейчас, когда я пишу что хочу и как хочу, и никто мне не вправе выдвигать претензии.»
Ваша проблема в завышенном самомнении, вы считаете что вы то уж хороший программист, который никогда не делает ошибок — но это конечно же не так, ошибки делают все. И ошибки — это не «написанный через задницу код» — это свойственно программистам любого уровня, при этом даже если заменить всех программистов на условно хороших сейчас — это уже выйдет неподъемно для бизнеса, а количество ошибок не сократится радикально, будет меньше но не так сильно.
С производителями микросхем сравнивать некорректно. Во первых реально сложные микросхемы делают единичные компании (догадайтесь почему) и вкладываются в это огромные деньги. Большинство микросхем по сложности не сравнимы с ОС/БД и подобными продуктами. Кроме того в микросхемах гораздо меньше неопределенности, протестировать все режимы проще чем протестировать полностью ОС. А еще для железа есть бесплатный по сути набор реальных сложных тестов. Если новый ЦП нормально запускает сложные мат. расчеты и результат сходится, все ПО работает на нем и т.д.. — это уже тестирует очень много. ОС вы так не протестируете. И даже не смотря на это все равно в ЦП бывают баги, даже в последних сериях Intel'овских процессоров. И никто не отзывает, и в утиль никто не отправляет.
Вот например.
Ну и маленький кусочек таблички для одного поколения одного семейства процессоров:
Ну и в общем
К чему я? К тому что надо матчасть учить прежде чем рассказывать сказки. Баги есть везде, и нормально с этим люди живут, и нет программистов способных писать идеальный код, всегда будут баги, надо просто самомнение понизить до адекватного уровня и не говорить что «просто не хочется напрягаться и работать качественно» потому что сами то (как и вообще любой программист) это «идеально качественно» обеспечить не в состоянии.
С каких это пор написание просто качественного кода оказывается дороже, чем написание некачественного кода, а потом его мучительное сопровождение и фиксы?С самого начала. Написать изначально безглючный код — гораздо дороже чем написать обычный код и потом пофиксить. Если код слишком плохой — это тоже самое как если он слишком хороший в отношении денег, в первом случае придется все переделывать много раз, во втором — придется вкладывать огромные силы сразу. Идеал — где-то посередине, когда в коде могут быть баги но он в целом нормальный.
конечно же, если нарушили правила и попали в авариюРечь была про конкретный случай. Если бы движок не встал — вы бы в аварию не попали, но это не дает повод судить производителя (судить то можно, но безрезультатно). А в 99% случаев соблюдения правил отказ большинства вещей (кроме чего то уровня заклинивания/поломки рулевого вала, колес или тормозов) — не приведет к ДТП. Отказ дворников в ливень например не должен приводить к ДТП если правильно выбирать скорость и дистанцию, если это стало причиной ДТП — в первую очередь сами будете виноваты т.к. выбрали скорость/дистанцию не по условиям.
Много. Я не преувеличиваю.Я ни одного не знаю.
С производителями микросхем сравнивать некорректно. Во первых реально сложные микросхемы делают единичные компании (догадайтесь почему) и вкладываются в это огромные деньги. Большинство микросхем по сложности не сравнимы с ОС/БД и подобными продуктами. Кроме того в микросхемах гораздо меньше неопределенности, протестировать все режимы проще чем протестировать полностью ОС. А еще для железа есть бесплатный по сути набор реальных сложных тестов. Если новый ЦП нормально запускает сложные мат. расчеты и результат сходится, все ПО работает на нем и т.д.. — это уже тестирует очень много. ОС вы так не протестируете. И даже не смотря на это все равно в ЦП бывают баги, даже в последних сериях Intel'овских процессоров. И никто не отзывает, и в утиль никто не отправляет.
However, the problem for those affected is the bug has been hard-coded into both the current generation of Haswell chips and the first shipments of Broadwell chips already delivered to hardware OEMs, according to Intel. In response, Intel has issued a software “microcode update,” a patch that simply turns TSX off rather than fixing it.
“We have addressed the TSX issue with the release of a microcode update that disables TSX on current steppings of the affected Haswell and Broadwell products,” an Intel spokesman said in a statement. “Longer term, Intel is committed to correcting the issues with TSX and enabling the feature on future processors.”
Вот например.
Ну и маленький кусочек таблички для одного поколения одного семейства процессоров:
Ну и в общем
Intel typically finds and publishes hundreds of bugs—known as “erratum"—some of which only crop up under certain conditions or in certain products. Of those, a few affect consumers at large: in 2011, for example, a bug plagued Intel’s “Cougar Point” chipset, and a bug within its SSD 320 drives could cause them to unexpectedly fail.Не скажу за все баги но много может быть пофикшено просто кооперацией с разработчиками компиляторов которые добавят правила «не генерировать такую последовательность кода» и вставят где нужно nop или чуть поменяют инструкции.
К чему я? К тому что надо матчасть учить прежде чем рассказывать сказки. Баги есть везде, и нормально с этим люди живут, и нет программистов способных писать идеальный код, всегда будут баги, надо просто самомнение понизить до адекватного уровня и не говорить что «просто не хочется напрягаться и работать качественно» потому что сами то (как и вообще любой программист) это «идеально качественно» обеспечить не в состоянии.
Конечно же, баг — это обстоятельство неприодолимой силы.Часто пишут «по обстоятельствам не зависящим от сторон соглашения» или подобное. В этом плане баг вполне подходит.
Я не считаю, и нигде не писал, что мой код безглючный. Но через две комнаты от меня сидит бригада тестировщиков, которые сидят и проверяют этот самый код после меня. И возвращают мне его на доработку, если что-то не так. Это очень просто и обыденно, они есть в куче компаний. А знаете что самое забавное? Есть ещё больше компаний, в которых их нет. Или другой вариант: они есть, но ради того, что проект надо выставить побыстрее, QC просто режут. Взять Яндекс, которому весь Интернет недавно перемывал косточки. Это вполне типичный пример, у них бестолковое требование «сдать к годовщине Октябрьской революции» было важнее, чем требование «доделать проект». Понятное дело, их проект в целом бесплатный, и они никому ничем не обязаны, пользователи проголосуют посещаемостью ресурса, да и только. Но ведь точно так же поступают и многие внедренцы корпоративного ПО. И вот это надо давить.
> Большинство микросхем по сложности не сравнимы с ОС/БД и подобными продуктами. Кроме того в
> микросхемах гораздо меньше неопределенности, протестировать все режимы проще чем протестировать
> полностью ОС.
Да ну? А кроме ОС/БД есть ещё другой софт? Скрипт, сохраняющий карточку клиента в CRM, он сложнее сдвигового регистра или нет?
И что такое «гораздо меньше неопределённости»? Микросхема работает по спецификации, а программа — по божьей воле? У микросхемы, к вашему сведению, куда больше параметров, которые одновременно надо выдерживать. Если программа — это просто выполнение алгоритма, то микросхема — это алгоритм плюс синхронизация (у вас там не будет семафоров/мютексов, если хотите использовать результат двух потоков, будьте добры, позаботьтесь, чтобы они физически одновременно завершились), плюс топология, плюс борьба с паразитными емкостями/индуктивностями, плюс уложить всё это добро в допустимый TDP.
И ничего, как-то справляются.
> Ну и маленький кусочек таблички для одного поколения одного семейства процессоров:
Да, аж пять страниц. В Windows 98, я помню, такой же список включал 4000 только известных на момент релиза бага. И знаете, эти процессоры намного дороже и сложнее, чем 99% существующего на рынке корпоративного софта.
> Часто пишут «по обстоятельствам не зависящим от сторон соглашения» или подобное.
> В этом плане баг вполне подходит.
Ну т.е. если вам строили дачу, и фундамент треснул, вы к прорабу ругаться не пойдёте. Это от сторон соглашения не зависит.
Если я вас не убедил, что проблема исключительно в отсутствии QA, а не в специфике работы, то давайте еще пример с автомобилями подброшу. Вы согласитесь, что аварии автомобилей наносят значительный ущерб, они непредсказуемы, и происходят часто? Каждый владелец автомобиля хоть раз, но куда-то попадал, верно?
И согласитесь, что страховые компании стоимость страховки рассчитывают, исходя из суммы ущерба * риск возникновения этого ущерба + своя прибыль сверху? Так вот, на сколько страховка автомобиля от ДТП делает его дороже? На порядок? Или на несколько процентов?
> Большинство микросхем по сложности не сравнимы с ОС/БД и подобными продуктами. Кроме того в
> микросхемах гораздо меньше неопределенности, протестировать все режимы проще чем протестировать
> полностью ОС.
Да ну? А кроме ОС/БД есть ещё другой софт? Скрипт, сохраняющий карточку клиента в CRM, он сложнее сдвигового регистра или нет?
И что такое «гораздо меньше неопределённости»? Микросхема работает по спецификации, а программа — по божьей воле? У микросхемы, к вашему сведению, куда больше параметров, которые одновременно надо выдерживать. Если программа — это просто выполнение алгоритма, то микросхема — это алгоритм плюс синхронизация (у вас там не будет семафоров/мютексов, если хотите использовать результат двух потоков, будьте добры, позаботьтесь, чтобы они физически одновременно завершились), плюс топология, плюс борьба с паразитными емкостями/индуктивностями, плюс уложить всё это добро в допустимый TDP.
И ничего, как-то справляются.
> Ну и маленький кусочек таблички для одного поколения одного семейства процессоров:
Да, аж пять страниц. В Windows 98, я помню, такой же список включал 4000 только известных на момент релиза бага. И знаете, эти процессоры намного дороже и сложнее, чем 99% существующего на рынке корпоративного софта.
> Часто пишут «по обстоятельствам не зависящим от сторон соглашения» или подобное.
> В этом плане баг вполне подходит.
Ну т.е. если вам строили дачу, и фундамент треснул, вы к прорабу ругаться не пойдёте. Это от сторон соглашения не зависит.
Если я вас не убедил, что проблема исключительно в отсутствии QA, а не в специфике работы, то давайте еще пример с автомобилями подброшу. Вы согласитесь, что аварии автомобилей наносят значительный ущерб, они непредсказуемы, и происходят часто? Каждый владелец автомобиля хоть раз, но куда-то попадал, верно?
И согласитесь, что страховые компании стоимость страховки рассчитывают, исходя из суммы ущерба * риск возникновения этого ущерба + своя прибыль сверху? Так вот, на сколько страховка автомобиля от ДТП делает его дороже? На порядок? Или на несколько процентов?
Согласитесь, что страховые компании стоимость страховки рассчитывают, исходя из суммы ущерба * риск возникновения этого ущерба + своя прибыль сверху? Так вот, на сколько страховка автомобиля от ДТП делает его дороже? На порядок? Или на несколько процентов?Собственно речь о том и идёт, что несколько процентов получаются потому, что основные затраты несёт не страховая компания, а компания производящая автомобиль. Всевозможные проверки, тесты, спецификации. Тесты на знание ПДД, опять-таки. Всё это вместе снижает риск до приемлемых величин — и вот уже после этого страховка за несколько процентов становится реальностью.
А софтверные компании всем этим заниматься не хотят. Потому если вдруг страховка от программных сбоев станет обязательной (а это — как раз типичное решение проблемы «со стороны государства»), то вначале она будет стоить в несколько раз дороже, чем сама программа. Но она создаст спрос на программы, в которых количество известных и не исправленных багов измеряется хотя бы двузначным, а не шестизначным, числом. Ну а дальше — да, дальше уже будет работать рынок.
Причём вопрос уже начинает подниматься, речь уже идёт не о том произойдёт ли это вообще, а скорее о том когда это произойдёт. С этой точки зрения история с Фольксвагеном — вещь скорее положительная.
Нет, вы не поняли. Я не про аварии из-за неисправности автомобиля. Это мизер в общем количестве, конечно, не в последнюю очередь из-за этого самого контроля качества в автомобильных компаниях. Я про аварии по вине участников ДТП. Машины царапаются, бьются, разбиваются в хлам. Но эти 5% КАСКО, их хватает на то, чтобы вам компенсировать стоимость автомобиля, если вы его разобьете в хлам. Всего лишь 5%.
> Потому если вдруг страховка от программных сбоев станет обязательной (а это — как раз типичное решение
> проблемы «со стороны государства»)
Не «от программных сбоев». От ущерба от программных сбоев. Это важная разница. Зависший компьютер с котиками ущерб не нанесет. А вот софт, управляющий технологическим производством, может в каких-то случаях при ошибке в коде нанести прямой ущерб. Вот за это его разработчик должен отвечать.
> Потому если вдруг страховка от программных сбоев станет обязательной (а это — как раз типичное решение
> проблемы «со стороны государства»)
Не «от программных сбоев». От ущерба от программных сбоев. Это важная разница. Зависший компьютер с котиками ущерб не нанесет. А вот софт, управляющий технологическим производством, может в каких-то случаях при ошибке в коде нанести прямой ущерб. Вот за это его разработчик должен отвечать.
Вот за это его разработчик должен отвечать.
Кого вы имеете в виду под разработчиком? Человека или компанию? И почему должен, если заказчик софта готов взять на себя эти риски?
Должен отвечать поставщик программно-аппаратного решения, как сейчас сделано с автомобилями и другими товарами. Ведь если в автомобиле вылетел болтик, не к производителю болтов вопрос, а к производителю автомобиля. Последний уже может спросить с производителя болтов, если у них был какой-то договор на отдельных условиях.
Аналогично с Windows. Зависла — кто виноват? Железо может глючное, или ошибка в связке с другой программой, эту связку может протестировать только поставщик решения. Сделал интерграцию, протестировал, запечатал конфигурацию, запретив что-то доустанавливать. Тогда можно говорить о гарантиях и ответственности.
Аналогично с Windows. Зависла — кто виноват? Железо может глючное, или ошибка в связке с другой программой, эту связку может протестировать только поставщик решения. Сделал интерграцию, протестировал, запечатал конфигурацию, запретив что-то доустанавливать. Тогда можно говорить о гарантиях и ответственности.
Какой вы гибкий. Ткнули носом что программисты не могут писать идеальный код вы тут же оп и оказывается уже не программисты виноваты а надо тестетов побольше. Так вот ткну носом еще раз — тестеры тоже не идеальны и баги пропускать могут, а некоторые специфичные баги вообще фиг выявишь тестерами.
Тоже самое с микросхемами, ткнули носом что багов на самом деле вагон, ткнули носом что никто не отзывает и живут нормально и тут уже начинается что типа «да, баги есть, но если сосчитать абсолютное их количество — их меньше». Ну если абсолютное количество багов — это метрика то я могу предоставить программу ровно с 1 багом — она не будет запускаться, по вашей логике она почти идеал.
А страховка — вообще смешно, как раз сумма ущерба * вероятность + сумма предотвращения этого ущерба (чтобы первое слагаемое не было совсем запредельным) — это уже будет астрономическая сумма даже без прибыли сверху. Причем такая астрономическая что клиенты в принципе не потянут столько платить. Программистов будете оплачивать в 10 раз дороже чем докторов — по нескольку тысяч в час.
Тоже самое с микросхемами, ткнули носом что багов на самом деле вагон, ткнули носом что никто не отзывает и живут нормально и тут уже начинается что типа «да, баги есть, но если сосчитать абсолютное их количество — их меньше». Ну если абсолютное количество багов — это метрика то я могу предоставить программу ровно с 1 багом — она не будет запускаться, по вашей логике она почти идеал.
плюс топология, плюс борьба с паразитными емкостями/индуктивностями, плюс уложить всё это добро в допустимый TDP.Так микросхемы и производят не одна команда, кто-то пишет логику а потом какой-нибудь foxconn или прочие делают железку. Можно посмотреть сколько миллиардов стоят интеловские фабы, и сколько еще уходит собственно на разработку. И это железка в которой логики гораздо меньше чем в ОС.
Микросхема работает по спецификации, а программа — по божьей воле?У железок все несколько проще, там строго формальный набор допустимых входов и определенные выходы и все это тестируется проще. А попробуйте хотябы в голове вообразить сценарий полного тестирований всей ОС (любой современной десктопной). И вручную конечно железки мало кто собирает по транзисторам, есть софт генерирующий описание железки из кода.
Ну т.е. если вам строили дачу, и фундамент треснул, вы к прорабу ругаться не пойдёте. Это от сторон соглашения не зависит.У вас плохо с логикой. Если прораба похитят во время работы — вот тогда я вряд ли смогу по соглашению выставить счет за задержку, зависит от соглашения конечно. А если в соглашении прописана гарантия на все что сделано включая фундамент — то отвечают.
А страховка — вообще смешно, как раз сумма ущерба * вероятность + сумма предотвращения этого ущерба (чтобы первое слагаемое не было совсем запредельным) — это уже будет астрономическая сумма даже без прибыли сверху. Причем такая астрономическая что клиенты в принципе не потянут столько платить. Программистов будете оплачивать в 10 раз дороже чем докторов — по нескольку тысяч в час.
Ну извините. Моя вина, что я не написал тут целиком законопроект со всеми нюансами «как надо сделать, чтобы было справедливо», а просто указал на существование проблемы. Я просто грешным делом подумал, что такие очевидные вещи писать не нужно, а оказывается, надо разжевывать всё.
> Так вот ткну носом еще раз — тестеры тоже не идеальны и баги пропускать могут, а некоторые
> специфичные баги вообще фиг выявишь тестерами.
И что? Ну пропустили баг, бывает. Мне вот недавно меняли рулевую рейку по гарантии. Там был баг. Концерн Hyundai не обанкротился.
> Ну если абсолютное количество багов — это метрика то я могу предоставить программу ровно с 1 багом
> — она не будет запускаться, по вашей логике она почти идеал.
Извините, опять забыл очевидную вещь написать. Тот список не только меньше, но в нем ещё и критичных багов нет. Процессоры работают, не теряют данные пользователей и не искажают их.
> Так микросхемы и производят не одна команда, кто-то пишет логику а потом какой-нибудь foxconn или
> прочие делают железку.
Это как-то уменьшает сложность задачи, которую нужно решить для разработки микросхем? Если на то уж пошло, то к вашему сведению, всё, что я упомянул, решает разработчик микросхемы, а не изготовитель. OEM-производитель может заниматься отладкой техпроцесса, чтобы уменьшить токи утечки, например, но он не будет компоновать кристалл.
> А попробуйте хотябы в голове вообразить сценарий полного тестирований всей ОС (любой современной
> десктопной).
Моя ОС — это не что-то аморфное и работающее через непонятную хитро закрученную задницу. Это набор из нескольких тысяч компонент, каждая из которых имеет определённый API и такую точно спецификацию на функционирование. Я вам более того скажу, она уже тестируется. Полностью. И эта ОС мне не наносила материального ущерба ни разу, ей я вполне доверяю. Наверное, вам тоже не наносила. Так чего должен бояться её разработчик?
> У вас плохо с логикой.
У меня с логикой как раз хорошо. Вы выше назвали баг в программе «обстоятельством не зависящим от сторон соглашения». Я вам в пример привёл такой же баг, только сделанный не программистом, а строителем. Ведь форс-мажор, он же и в договорах подряда есть. А вы теперь мне доказываете, что строители вот гарантию давать должны. И у кого проблемы с логикой?
> А страховка — вообще смешно, как раз сумма ущерба * вероятность + сумма предотвращения этого
> ущерба (чтобы первое слагаемое не было совсем запредельным) — это уже будет астрономическая сумма
> даже без прибыли сверху
Вдумайтесь: вы только что написали, что стоимость ущерба, которое наносит программное обеспечение клиентам, это астрономическая сумма. Я так понимаю, в разы превышает стоимость программного обеспечения. Вы ничего не перепутали? А то при таком раскладе получается, что вы прям не проблемы клиентов решаете, а наоборот, несёте им боль, ужас и разрушение. Причём они еще и деньги вам платят за то, чтобы программа нанесла им ущерб, десятикратный от уплаченной суммы.
Говорите, логика?
> Так вот ткну носом еще раз — тестеры тоже не идеальны и баги пропускать могут, а некоторые
> специфичные баги вообще фиг выявишь тестерами.
И что? Ну пропустили баг, бывает. Мне вот недавно меняли рулевую рейку по гарантии. Там был баг. Концерн Hyundai не обанкротился.
> Ну если абсолютное количество багов — это метрика то я могу предоставить программу ровно с 1 багом
> — она не будет запускаться, по вашей логике она почти идеал.
Извините, опять забыл очевидную вещь написать. Тот список не только меньше, но в нем ещё и критичных багов нет. Процессоры работают, не теряют данные пользователей и не искажают их.
> Так микросхемы и производят не одна команда, кто-то пишет логику а потом какой-нибудь foxconn или
> прочие делают железку.
Это как-то уменьшает сложность задачи, которую нужно решить для разработки микросхем? Если на то уж пошло, то к вашему сведению, всё, что я упомянул, решает разработчик микросхемы, а не изготовитель. OEM-производитель может заниматься отладкой техпроцесса, чтобы уменьшить токи утечки, например, но он не будет компоновать кристалл.
> А попробуйте хотябы в голове вообразить сценарий полного тестирований всей ОС (любой современной
> десктопной).
Моя ОС — это не что-то аморфное и работающее через непонятную хитро закрученную задницу. Это набор из нескольких тысяч компонент, каждая из которых имеет определённый API и такую точно спецификацию на функционирование. Я вам более того скажу, она уже тестируется. Полностью. И эта ОС мне не наносила материального ущерба ни разу, ей я вполне доверяю. Наверное, вам тоже не наносила. Так чего должен бояться её разработчик?
> У вас плохо с логикой.
У меня с логикой как раз хорошо. Вы выше назвали баг в программе «обстоятельством не зависящим от сторон соглашения». Я вам в пример привёл такой же баг, только сделанный не программистом, а строителем. Ведь форс-мажор, он же и в договорах подряда есть. А вы теперь мне доказываете, что строители вот гарантию давать должны. И у кого проблемы с логикой?
> А страховка — вообще смешно, как раз сумма ущерба * вероятность + сумма предотвращения этого
> ущерба (чтобы первое слагаемое не было совсем запредельным) — это уже будет астрономическая сумма
> даже без прибыли сверху
Вдумайтесь: вы только что написали, что стоимость ущерба, которое наносит программное обеспечение клиентам, это астрономическая сумма. Я так понимаю, в разы превышает стоимость программного обеспечения. Вы ничего не перепутали? А то при таком раскладе получается, что вы прям не проблемы клиентов решаете, а наоборот, несёте им боль, ужас и разрушение. Причём они еще и деньги вам платят за то, чтобы программа нанесла им ущерб, десятикратный от уплаченной суммы.
Говорите, логика?
Замечательно что часть ошибок вы признали, теперь разжую оставшееся.
Так вот собственно подвожу суть вышесказанного: для 99% клиентов суммы ущерба и риски более чем приемлемы. Это включает большинство компаний, им проще настроить бекап чем переплачивать даже 10% за стоимость каждой остальной программы за дополнительную надежность. Суммарно для них риск простоя сотрудника окупится. Но есть очень небольшая часть клиентов у которых в специфичных случаях риски могут быть миллиардными. Так вот я говорю о том что всех все устраивает а ради этих << 1% клиентов не стоит (и никто конечно не будет это делать) вводить ответственность за баги. Остальные 99% будут даже против, т.к. сейчас у них есть выбор и они могут предпринимать шаги которые сочтут нужными — например бекапы, а в случае регулировки им навязывается заранее «менее бажный» софт с какими-то «гарантиями», правда упущенную прибыль посчитать трудно и вернут ее вряд ли даже с «гарантиями», а поэтому все бекапы и прочее все так же будут нужны и эти 99% клиентов только потеряют в сумме.
А вот те <<1% у которых убытки большие — пусть они сами заботятся о страховке, платят из своего кармана за специальный супер-надежный софт или настраивают какие-то хитрые избыточные схемы вычислений. Все остальные не должны платить долю за что-то что нужно только этому небольшому количеству клиентов.
Страховые сейчас делают очень похоже. Если у вас дорогая машина и вероятность ущерба большая (например 16 лет и вчера водительскую лицензию получил) — то страховка будет очень большая, а для подавляющего большинства она дешевая. Тут так же, подавляющее большинство устраивает текущее положение дел, оно может не устраивать только тех кто хочет заставить весь мир платить вскладчину за свои риски, но такого, понятное дело, никогда не будет.
А суммы астрономические будут выходить если требовать повышения надежности почти до идеала (о чем вы тут раньше говорили) — это будет стоить чем дальше тем дороже и переплюнет суммы ущерба. Второй фактор — это те маленькие компании с миллиардными потенциальными убытками. А для большинства и сейчас рынок работает и рынок показывает что люди не готовы платить за супер-надежность или тем более за гарантии, т.к. надежность повышается другими средствами (бекапы, быстрое развертывание, балансировка и т.д. .), которые в совокупности дешевле чем платить за повышение надежности программ, а гарантии многим не нужны т.к. риски они сами минимизируют вышеприведенными средствами, а у многих под сколько-нибудь реальным риском находятся совершенно не критичные вещи.
Тот список не только меньше, но в нем ещё и критичных багов нет. Процессоры работают, не теряют данные пользователей и не искажают их.Критичность — понятие относительное, кому то зависание критично, а касательно данных — надо делать бекап, ну и случаи когда что-то без спроса удаляет данные — все же достаточно редки (я ниже объясню почему это важно и почему они могут быть даже не редкими и все равно все ок).
Это как-то уменьшает сложность задачи, которую нужно решить для разработки микросхем?Железки зачастую содержат очень топорную логику, в этом плане даже ЦП много проще чем ОС.
И эта ОС мне не наносила материального ущерба ни разу, ей я вполне доверяю.Не понятно к чему это? Вам просто повезло, баги есть в любой ОС одного класса примерно в равной мере. В QNX и подобных их вероятно сильно меньше но и эти по сути ядра — сильно специфичны.
Я вам в пример привёл такой же баг, только сделанный не программистом, а строителем.Если вы заключили договор с программистом и прописали в нем ответственность — то да. Все зависит от того как составлен договор, если вы составили его хорошо и доказали что вашей вины небыло (т.е. не «данные удалились а бекапы мы не делаем», а что-то действительно не зависящее от вас) — то отвечать не будете. В договоре с прорабом обычно гарантии прописаны, да и работа прораба все же несравнимо проще чем работа группы программистов использующих в течение нескольких лет.
А то при таком раскладе получается, что вы прям не проблемы клиентов решаете, а наоборот, несёте им боль, ужас и разрушение.
Так вот собственно подвожу суть вышесказанного: для 99% клиентов суммы ущерба и риски более чем приемлемы. Это включает большинство компаний, им проще настроить бекап чем переплачивать даже 10% за стоимость каждой остальной программы за дополнительную надежность. Суммарно для них риск простоя сотрудника окупится. Но есть очень небольшая часть клиентов у которых в специфичных случаях риски могут быть миллиардными. Так вот я говорю о том что всех все устраивает а ради этих << 1% клиентов не стоит (и никто конечно не будет это делать) вводить ответственность за баги. Остальные 99% будут даже против, т.к. сейчас у них есть выбор и они могут предпринимать шаги которые сочтут нужными — например бекапы, а в случае регулировки им навязывается заранее «менее бажный» софт с какими-то «гарантиями», правда упущенную прибыль посчитать трудно и вернут ее вряд ли даже с «гарантиями», а поэтому все бекапы и прочее все так же будут нужны и эти 99% клиентов только потеряют в сумме.
А вот те <<1% у которых убытки большие — пусть они сами заботятся о страховке, платят из своего кармана за специальный супер-надежный софт или настраивают какие-то хитрые избыточные схемы вычислений. Все остальные не должны платить долю за что-то что нужно только этому небольшому количеству клиентов.
Страховые сейчас делают очень похоже. Если у вас дорогая машина и вероятность ущерба большая (например 16 лет и вчера водительскую лицензию получил) — то страховка будет очень большая, а для подавляющего большинства она дешевая. Тут так же, подавляющее большинство устраивает текущее положение дел, оно может не устраивать только тех кто хочет заставить весь мир платить вскладчину за свои риски, но такого, понятное дело, никогда не будет.
А суммы астрономические будут выходить если требовать повышения надежности почти до идеала (о чем вы тут раньше говорили) — это будет стоить чем дальше тем дороже и переплюнет суммы ущерба. Второй фактор — это те маленькие компании с миллиардными потенциальными убытками. А для большинства и сейчас рынок работает и рынок показывает что люди не готовы платить за супер-надежность или тем более за гарантии, т.к. надежность повышается другими средствами (бекапы, быстрое развертывание, балансировка и т.д. .), которые в совокупности дешевле чем платить за повышение надежности программ, а гарантии многим не нужны т.к. риски они сами минимизируют вышеприведенными средствами, а у многих под сколько-нибудь реальным риском находятся совершенно не критичные вещи.
> Критичность — понятие относительное, кому то зависание критично, а касательно данных — надо делать
> бекап
Да. А крокодил обычно зелёный. Ну и что?
> Железки зачастую содержат очень топорную логику
Да. А программное обеспечение, кстати, тоже далеко не всегда включает нейронные сети. Вы кроме ОС, ещё примеры приложений знаете? Для вас не будет открытием, что логика бизнес-приложений в основном так же прямолинейна и проста?
> Не понятно к чему это?
Плохо, что непонятно. Это к размеру степени риска, который несёт производитель ОС, если возьмёт на себя ответственность за её качество.
> Если вы заключили договор с программистом и прописали в нем ответственность — то да
Отлично. Уже что-то.
> В договоре с прорабом обычно гарантии прописаны
Хорошо. Допустим, гарантии не прописаны. Бывает. Не все юристы, не все внимательные. Вы будете что-то требовать от прораба и рассчитывать на компенсацию?
> Это включает большинство компаний, им проще настроить бекап чем переплачивать даже 10% за
> стоимость каждой остальной программы за дополнительную надежность.
Bingo! Ваши астрономические суммы и многократный рост стоимости программиста внезапно превратились в 10% в реальной жизни :)
> А суммы астрономические будут выходить если требовать повышения надежности почти до идеала (о чем
> вы тут раньше говорили)
O_o Давайте тогда цитату, где я такое говорил. Про взятие ответственности за качество — говорил и говорю. Про то, что софт должен быть до идеала отполирован, не говорил ни разу.
> Но есть очень небольшая часть клиентов у которых в специфичных случаях риски могут быть
> миллиардными
Разработчики, которые пишут софт под такие специфичные случаи, риски на себя как раз обычно берут. Это другой рынок, и там другие правила.
> бекап
Да. А крокодил обычно зелёный. Ну и что?
> Железки зачастую содержат очень топорную логику
Да. А программное обеспечение, кстати, тоже далеко не всегда включает нейронные сети. Вы кроме ОС, ещё примеры приложений знаете? Для вас не будет открытием, что логика бизнес-приложений в основном так же прямолинейна и проста?
> Не понятно к чему это?
Плохо, что непонятно. Это к размеру степени риска, который несёт производитель ОС, если возьмёт на себя ответственность за её качество.
> Если вы заключили договор с программистом и прописали в нем ответственность — то да
Отлично. Уже что-то.
> В договоре с прорабом обычно гарантии прописаны
Хорошо. Допустим, гарантии не прописаны. Бывает. Не все юристы, не все внимательные. Вы будете что-то требовать от прораба и рассчитывать на компенсацию?
> Это включает большинство компаний, им проще настроить бекап чем переплачивать даже 10% за
> стоимость каждой остальной программы за дополнительную надежность.
Bingo! Ваши астрономические суммы и многократный рост стоимости программиста внезапно превратились в 10% в реальной жизни :)
> А суммы астрономические будут выходить если требовать повышения надежности почти до идеала (о чем
> вы тут раньше говорили)
O_o Давайте тогда цитату, где я такое говорил. Про взятие ответственности за качество — говорил и говорю. Про то, что софт должен быть до идеала отполирован, не говорил ни разу.
> Но есть очень небольшая часть клиентов у которых в специфичных случаях риски могут быть
> миллиардными
Разработчики, которые пишут софт под такие специфичные случаи, риски на себя как раз обычно берут. Это другой рынок, и там другие правила.
Для вас не будет открытием, что логика бизнес-приложений в основном так же прямолинейна и проста?Ну бизнес приложение по цене разработки микроконтроллера будет с меньшим числом ошибок, за такие цены кто-то и не прочь будет взять ответственность на себя. Только вот не хотят такие деньги платить, потому что не нужно никому.
Хорошо. Допустим, гарантии не прописаны. Бывает. Не все юристы, не все внимательные. Вы будете что-то требовать от прораба и рассчитывать на компенсацию?Если прораб договор составил хорошо а вы абы-как — так вы вообще фиг за что компенсацию получите, будут соблюдены только самые базовые нормы, а эти нормы базовые потому что они просты для исполнения и дешевы, а без них все рушится и не работает. В софте понятное дело (любому образованному человеку, не факт что вам понятно) что все по другому, да и в принципе оно нормально работает и сейчас и все довольны, поэтому никаких регулировок и не будет.
Bingo! Ваши астрономические суммы и многократный рост стоимости программиста внезапно превратились в 10% в реальной жизни :)Плохо с логикой, очень плохо. 2 класса церковно приходской школы. «Я не готов платить даже тысячу рублей за эту машину» не значит что «Bingo вот я же говорил что машина стоит 1000 рублей!». Очень советую пойти в школу доучиться, или книжку по логике купить.
Разработчики, которые пишут софт под такие специфичные случаи, риски на себя как раз обычно берут. Это другой рынок, и там другие правила.Отлично, а на кой тогда нужные такие же правила на все рынке если его участники вполне довольны тем что есть?
> Ну бизнес приложение по цене разработки микроконтроллера будет с меньшим числом ошибок,
> за такие цены
Опять на порядок удорожаем, да? ;)
> любому образованному человеку, не факт что вам понятно
> 2 класса церковно приходской школы
> Очень советую пойти в школу доучиться, или книжку по логике купить.
О'кей, я вас понял. Как только аргументы заканчиваются, надо приступать к хамству. До свидания-с, дальше общайтесь со шпаной в подворотне, вы общий язык найдёте.
> за такие цены
Опять на порядок удорожаем, да? ;)
> любому образованному человеку, не факт что вам понятно
> 2 класса церковно приходской школы
> Очень советую пойти в школу доучиться, или книжку по логике купить.
О'кей, я вас понял. Как только аргументы заканчиваются, надо приступать к хамству. До свидания-с, дальше общайтесь со шпаной в подворотне, вы общий язык найдёте.
Опять на порядок удорожаем, да? ;)Ну смотрим цены микроконтроллеров. Я думаю там можно и на 2 порядка иногда.
Что, ответить по сути нечего? На 10 раз когда ткнули носом что не прав (началось это все с фантастической >>50% маржи у IT компаний) — наконец выдохся? Надо просто дружить с логикой и не делать таких смешных нелепых выводов как выше, «не готови платить и 10%» == «подорожает всего на 10%». А то мне это чем-то напомнило антинаучное балабольство одного индивида в соседнем треде про возникновение жизни. Чему соответствует логика то и написал, может не 2 класса, может 3, но не выше. Вы бы хотябы были последовательны в своих заблуждениях, и хотябы с логикой не путались. А то уже от половины отказались по мере тыкания носом в ошибки, и теперь противоречащие логике извороты делаете.
Кстати, должен признать — интересный ход: писать откровенную ересь и чушь, манипулировать фактами, отказываться от своих слов, нагло попирать логику в своих выводах и в кажом ответе на свои комментарии искать какую либо фразу которую можно было бы интерпретировать как оскорбление, после чего гордо заявить «не важно что все мои высказывания — бред, я прав потому что смотрите, меня обидели». Жаль не могу принять на вооружение, т.к. привык все же оперировать фактами и логикой. Но ход интересный, достоен внесения в статью «правила демагога».
Моя вина, что я не написал тут целиком законопроект со всеми нюансами «как надо сделать, чтобы было справедливо»
Вот вам законопроект со всеми нюансами:
Закон Российской Федерации о возмещении убытков, возникших в результате ошибок работы программ для ЭВМ
Возмещение убытков, возникших в результате ошибок работы программ для ЭВМ, осуществляется на условиях, определенных лицензионным договором, договором авторского заказа или трудового договора, если иное не предусмотрено Конституцией Российской Федерации или международными договорами Российской Федерации. Ошибками работы программ для ЭВМ считаются не выполнение программой требований, заложенных в техническом задании на разработку программы для ЭВМ или аналогичном документе, содержащем описание того, какие выходные данные должна выдавать программа для ЭВМ в ответ на те или иные входные данные.
Ответьте, пожалуйста на несколько простых вопросов — кто вы по професси, кто вы по специальности и кем вы работаете?
Так сказать, подтвердите свою квалификацию, чтобы все видели, что ваши слова — не диванный аналитизм, а человек их высказывающий действительно понимает, о чём он говорит.
PS для справки — баги в чипах есть, баги в процессорах есть, баги в памяти есть. И нет, партии из-за этого не отзывают — на процессоры ставятся блокировки багованного функционала (Intel, привет тебе с твоей транзакционной памятью!), в чипах на серию вешается информация в даташит (чипы идут по сильно уменьшенной цене)… в редких случаях «совсем не юзабельно» отзывается вся серия, в памяти используются различные алгоритмы переопределения ячеек памяти.
Так сказать, подтвердите свою квалификацию, чтобы все видели, что ваши слова — не диванный аналитизм, а человек их высказывающий действительно понимает, о чём он говорит.
PS для справки — баги в чипах есть, баги в процессорах есть, баги в памяти есть. И нет, партии из-за этого не отзывают — на процессоры ставятся блокировки багованного функционала (Intel, привет тебе с твоей транзакционной памятью!), в чипах на серию вешается информация в даташит (чипы идут по сильно уменьшенной цене)… в редких случаях «совсем не юзабельно» отзывается вся серия, в памяти используются различные алгоритмы переопределения ячеек памяти.
По специальности математик, по профессии программист. Около восьми лет проработал в банке на развитии самописной АБСки, потом ушел в ERP на Microsoft Dynamics.
Конечно же, про баги в чипах я утрирую, они там бывают. Речь-то о другом была — что компании-разработчики чипов за эти баги несут ответственность. Взять те же процессоры, сколько Пентиумов в начале 1990-х отзывала Intel из-за бага FDIV? Если мне память изменяет, на три миллиарда долларов. И это с учётом возможности обойти его с помощью программной заплатки.
Конечно же, про баги в чипах я утрирую, они там бывают. Речь-то о другом была — что компании-разработчики чипов за эти баги несут ответственность. Взять те же процессоры, сколько Пентиумов в начале 1990-х отзывала Intel из-за бага FDIV? Если мне память изменяет, на три миллиарда долларов. И это с учётом возможности обойти его с помощью программной заплатки.
Более характерен другой пример. Когда в тот же самом злосчастном Pentium'е нашли другую проблему, то народ в Intel'е на уши встал и за неделю всё разрулили. В прессе писали, футболки выпускали. И вообще каждый аппартный баг, который может реально привести к проблемам (тот же rowhammer) долго обсуждается, его пытаются как-то обойти, в крайнем случае даже железки отзывают!
А если баг в софте с подобными же последствиями? Да на него всем положить с прибором! Шо у нас таки багов мало? Ну заткнём мы эту дыру… когда-нибудь. Всё равно ещё 100500 останется…
Вот с этим подходом и нужно бороться начинать…
А если баг в софте с подобными же последствиями? Да на него всем положить с прибором! Шо у нас таки багов мало? Ну заткнём мы эту дыру… когда-нибудь. Всё равно ещё 100500 останется…
Вот с этим подходом и нужно бороться начинать…
Т.е. вы с опытом работы в достаточно маленькой области программирования пытаетесь распространить ваш опыт на все области? Веб, системное ПО, ОС, драйвера, программирование контроллеров,… — у каждой области очень много специфики и почти нигде нет полных автоматов. Простите, но я советую вам отказаться от юношеского максимализма и шире взглянуть на проблему.
В начале 90х была жёсткая конкуренция на рынке изготовителей x86 процессоров (больше 4х производителей при не таком уж и большом рынке) — у них выбора банально не было. При этом сейчас, когда конкурентов нет (AMD для них не то, чтобы конкуренты), они процессоры не особо отзывают (по крайней мере громких случаев в последние годы я не припомню), при том что багают регулярно. И да, в мире ПО в аналогии отзыва железки идут хот-фиксы, хот-патчи и экстренные релизы.
В начале 90х была жёсткая конкуренция на рынке изготовителей x86 процессоров (больше 4х производителей при не таком уж и большом рынке) — у них выбора банально не было. При этом сейчас, когда конкурентов нет (AMD для них не то, чтобы конкуренты), они процессоры не особо отзывают (по крайней мере громких случаев в последние годы я не припомню), при том что багают регулярно. И да, в мире ПО в аналогии отзыва железки идут хот-фиксы, хот-патчи и экстренные релизы.
> Т.е. вы с опытом работы в достаточно маленькой области программирования пытаетесь распространить
> ваш опыт на все области?
Я прошу прощения, а что в вебе, системном ПО или софте под микроконтроллер такого, что отличает эту работу от любой другой инженерной? Разработчик софта под STM32 не должен отвечать за качество своей работы, а инженер, который разводит плату под него же, отвечать должен?
Меня другое удивляет: почему среди профессиональных (или считающих себя таковыми) инженеров-программистов так много людей, которые уверены в исключительности своей работы? Это какая-то профессиональная деформация. Да, зарплаты у нас выше, чем у инженеров, которые на пост-советских предприятиях чертят фланцы и втулки для всякхи железяк. Но этим мы обязаны высокому спросу на свою работу у бизнеса, а не какому-то уникальному качеству ИТ-специалистов. И это до поры, потому как рынок рано или поздно насытится, и наступит перелом. Поэтому проще будьте, господа.
> ваш опыт на все области?
Я прошу прощения, а что в вебе, системном ПО или софте под микроконтроллер такого, что отличает эту работу от любой другой инженерной? Разработчик софта под STM32 не должен отвечать за качество своей работы, а инженер, который разводит плату под него же, отвечать должен?
Меня другое удивляет: почему среди профессиональных (или считающих себя таковыми) инженеров-программистов так много людей, которые уверены в исключительности своей работы? Это какая-то профессиональная деформация. Да, зарплаты у нас выше, чем у инженеров, которые на пост-советских предприятиях чертят фланцы и втулки для всякхи железяк. Но этим мы обязаны высокому спросу на свою работу у бизнеса, а не какому-то уникальному качеству ИТ-специалистов. И это до поры, потому как рынок рано или поздно насытится, и наступит перелом. Поэтому проще будьте, господа.
Высокий спрос у бизнеса на нашу работу, который свободный (сейчас объективного порога входа в профессию практически не существует) рынок труда удовлетворить, похоже, судя по уровню зарплат, не в состоянии и является объективным (начколько это слово применимо к социальным отношениям) свидетельством нашей исключительности. Когда рынок уравняет нашу работу с работой остальных инженеров (скорее бы все инженеры стали богатыми, а не программисты бедными), тогда мы перестанем быть исключительными. Ну а пока имеем ту исключительную для инженеров зарплату, которую имеем.
Ну что, ж сравним хотя бы просто по уровням, с которыми ПО в той или иной степени взаимодействует (крайне ненадёжная картинка, но уже она показывает сложность тестирования):
— программа для контроллеров: контроллер (без багов?) -> плата (без багов?) -> физический мир (до сих пор не все эффекты изучены),
— веб-программа: браузер (ассорти, все с багами) -> исполнитель js (без багов?) -> железо клиента (без багов?) -> сетевой канал (без проблем?) -> стек сервеного ПО (распределение нагрузки, передача запроса на сервер приложений, без багов?) -> сервер приложений (без багов?) -> библиотеки приложения (без багов?) -> само приложение (ТЗ полное?) -> железо сервера (без багов?).
В итоге мы имеем следующую картину — для контроллеров есть шанс выстроить тестирующий конвеер, который обеспечит отсутствие багов (но очень дорого), а для веба это невыполнимая задача (т.к. приходится опираться на множество стороннего ПО, костыль к какждой проблеме не подставишь, да и не все они известны).
У ниженеров-программистов, так же как и у других инженеров и иных творческих (или относительно творческих) специальностей в принципе исключительная работа. Но если для инженеров других специальностей рынок устоявшийся и за время существования отработаны необходимые механизмы контроля (но и в этом случае всё не так радужно, как в вашем представлении), то в сфере программирования (постоянно меняющейся к тому же) отработать механизмы приёмки не получается (слишком мало времени отрасли и слишком вариабельная архитектура, которая ещй и меняется в мейнстриме постоянно). Именно поэтому ваша идея об «ответственности» программистов крайне утопична (и я уже приводил в пример где-то в комментариях к этой статье авиотрасль — там требуемая вами ответственность есть. Стоимость ПО, его потребительские свойства и скорость написания — соответствующие.
Хорошие программисты, если смотреть на запад, эквиваленты высокопрофессиональным инженерам (не тем, которые чертят фланцы и втулки, да). И рынку всё равно их недостаточно. В нашей стране программисты (по секрету) безумно дешёвые (для сравнения сениор у нас зарабатывает минимум в 2 раза меньше, чем в Америке, с Кремниевой долиной вообще сравнивать не хочется). Просто так сложилась эконмическая ситуация, что текущие зарплаты программистов существенно выше работников других специальностей. И да, даже если рынок (вдруг) насытится хорошие программисты всё равно останутся на уровне близком к высокопрофессиональным инженерам.
Я вот больше не понимаю вашего самоуничижения… Или такой плохой софт писать приходится?
Ну а за счёт голодного рынка заполнить потребность профессионалами не получается, что до
— программа для контроллеров: контроллер (без багов?) -> плата (без багов?) -> физический мир (до сих пор не все эффекты изучены),
— веб-программа: браузер (ассорти, все с багами) -> исполнитель js (без багов?) -> железо клиента (без багов?) -> сетевой канал (без проблем?) -> стек сервеного ПО (распределение нагрузки, передача запроса на сервер приложений, без багов?) -> сервер приложений (без багов?) -> библиотеки приложения (без багов?) -> само приложение (ТЗ полное?) -> железо сервера (без багов?).
В итоге мы имеем следующую картину — для контроллеров есть шанс выстроить тестирующий конвеер, который обеспечит отсутствие багов (но очень дорого), а для веба это невыполнимая задача (т.к. приходится опираться на множество стороннего ПО, костыль к какждой проблеме не подставишь, да и не все они известны).
У ниженеров-программистов, так же как и у других инженеров и иных творческих (или относительно творческих) специальностей в принципе исключительная работа. Но если для инженеров других специальностей рынок устоявшийся и за время существования отработаны необходимые механизмы контроля (но и в этом случае всё не так радужно, как в вашем представлении), то в сфере программирования (постоянно меняющейся к тому же) отработать механизмы приёмки не получается (слишком мало времени отрасли и слишком вариабельная архитектура, которая ещй и меняется в мейнстриме постоянно). Именно поэтому ваша идея об «ответственности» программистов крайне утопична (и я уже приводил в пример где-то в комментариях к этой статье авиотрасль — там требуемая вами ответственность есть. Стоимость ПО, его потребительские свойства и скорость написания — соответствующие.
Хорошие программисты, если смотреть на запад, эквиваленты высокопрофессиональным инженерам (не тем, которые чертят фланцы и втулки, да). И рынку всё равно их недостаточно. В нашей стране программисты (по секрету) безумно дешёвые (для сравнения сениор у нас зарабатывает минимум в 2 раза меньше, чем в Америке, с Кремниевой долиной вообще сравнивать не хочется). Просто так сложилась эконмическая ситуация, что текущие зарплаты программистов существенно выше работников других специальностей. И да, даже если рынок (вдруг) насытится хорошие программисты всё равно останутся на уровне близком к высокопрофессиональным инженерам.
Я вот больше не понимаю вашего самоуничижения… Или такой плохой софт писать приходится?
Ну а за счёт голодного рынка заполнить потребность профессионалами не получается, что до
Хорошо, давайте сравним.
— программа для контроллеров:
контроллер (без багов?) — за баги отвечает разработчик
плата (без багов?) — за баги отвечает разработчик
физический мир (до сих пор не все эффекты изучены) — за баги никто не отвечает.
веб-программа:
браузер (ассорти, все с багами) — отвечает клиент
исполнитель js (без багов?) — отвечает клиент
железо клиента (без багов?) — отвечает клиент
сетевой канал (без проблем?) — отвечает клиент/провайдер
стек сервеного ПО — отвечает хостер (распределение нагрузки, передача запроса на сервер приложений, без багов?)
сервер приложений (без багов?) — отвечает разработчик
библиотеки приложения (без багов?) — отвечает разработчик (кстати, а зачем вы не упомянули про библиотеки в случае микроконтроллеров?)
само приложение (ТЗ полное?) — отвечает разработчик
железо сервера (без багов?) — отвечает хостер
И чем это отличается по сути от верхнего варианта? Тоже три зоны ответственности у разработчика. Приложение, библиотеки, среда выполнения.
> Я вот больше не понимаю вашего самоуничижения… Или такой плохой софт писать приходится?
Это не моё самоуничижение. Это стыд за многих моих коллег. Вон, выше был спор с одним таким. Сначала пытался аргументировать, потом начал играться словоблудием, и скатился в бросание какашками.
— программа для контроллеров:
контроллер (без багов?) — за баги отвечает разработчик
плата (без багов?) — за баги отвечает разработчик
физический мир (до сих пор не все эффекты изучены) — за баги никто не отвечает.
веб-программа:
браузер (ассорти, все с багами) — отвечает клиент
исполнитель js (без багов?) — отвечает клиент
железо клиента (без багов?) — отвечает клиент
сетевой канал (без проблем?) — отвечает клиент/провайдер
стек сервеного ПО — отвечает хостер (распределение нагрузки, передача запроса на сервер приложений, без багов?)
сервер приложений (без багов?) — отвечает разработчик
библиотеки приложения (без багов?) — отвечает разработчик (кстати, а зачем вы не упомянули про библиотеки в случае микроконтроллеров?)
само приложение (ТЗ полное?) — отвечает разработчик
железо сервера (без багов?) — отвечает хостер
И чем это отличается по сути от верхнего варианта? Тоже три зоны ответственности у разработчика. Приложение, библиотеки, среда выполнения.
> Я вот больше не понимаю вашего самоуничижения… Или такой плохой софт писать приходится?
Это не моё самоуничижение. Это стыд за многих моих коллег. Вон, выше был спор с одним таким. Сначала пытался аргументировать, потом начал играться словоблудием, и скатился в бросание какашками.
Кстати, должен признать — интересный ход: писать откровенную ересь и чушь, манипулировать фактами, отказываться от своих слов, нагло попирать логику в своих выводах и в кажом ответе на свои комментарии искать какую либо фразу которую можно было бы интерпретировать как оскорбление, после чего гордо заявить «не важно что все мои высказывания — бред, я прав потому что смотрите, меня обидели». Жаль не могу принять на вооружение, т.к. привык все же оперировать фактами и логикой. Но ход интересный, достоен внесения в статью «правила демагога».
Как хорошо что такую дурь на практике никто не будет принимать за стандарт. Ну может в одной отдельно взятой стране убьют IT. Уже вот высказывания были что готовить IT специалистов — это вред, вот вы видимо из этой же оперы.
Вообще это со временем проходит. Наберетесь опыта (если решите развиваться в отрасли), получите знания — тогда осознаете что написали чушь, вместе посмеемся потом над этим.
Как хорошо что такую дурь на практике никто не будет принимать за стандарт. Ну может в одной отдельно взятой стране убьют IT. Уже вот высказывания были что готовить IT специалистов — это вред, вот вы видимо из этой же оперы.
Вообще это со временем проходит. Наберетесь опыта (если решите развиваться в отрасли), получите знания — тогда осознаете что написали чушь, вместе посмеемся потом над этим.
По секрету — в веб-деве приходится отвечать и за браузер (в том числе js-машину), плохое соединение, нередко, тоже складывается в плане ответственности на веб дев.
Серверное ПО\железо — как повезёт, бывает, что опять же на веб-дева ответсвтвенность падает.
Сервер приложений — фиг чего сделаешь (разве что версию поменять), но правильно, ответствтвенность укладывают на веб-дева.
Библиотеки, в случае с вебом — их много больше и они несут больший объём функционала приложения, нежели у программ для контроллеров.
ТЗ для веб-приложения никогда не бывает полным. Поэтому «как не должно работать» можно только относительно достоверно прогнозировать.
Вот этим всем и отлчиается (шире ответственность, хуже контроллируемость).
PS это именно самоуничижение, по непонятному для меня признаку. Стыд за коллег выражается, обычно, иначе… менее активно и громко, как минимум.
Серверное ПО\железо — как повезёт, бывает, что опять же на веб-дева ответсвтвенность падает.
Сервер приложений — фиг чего сделаешь (разве что версию поменять), но правильно, ответствтвенность укладывают на веб-дева.
Библиотеки, в случае с вебом — их много больше и они несут больший объём функционала приложения, нежели у программ для контроллеров.
ТЗ для веб-приложения никогда не бывает полным. Поэтому «как не должно работать» можно только относительно достоверно прогнозировать.
Вот этим всем и отлчиается (шире ответственность, хуже контроллируемость).
PS это именно самоуничижение, по непонятному для меня признаку. Стыд за коллег выражается, обычно, иначе… менее активно и громко, как минимум.
Вы путаете понятия «бороться с проблемами» и «нести ответственность». Тестировать и отлаживать софт под разные броузеры — это не означает «отвечать за его неработоспособность из-за не совместимости с броузером». То же самое касается и плохой связи и хостинга и т.д… Это не сфера ответственности разработчика, и никто, собственно, разработчикам этого в вину и не ставит.
> ТЗ для веб-приложения никогда не бывает полным. Поэтому «как не должно работать» можно только
> относительно достоверно прогнозировать.
> Библиотеки, в случае с вебом — их много больше и они несут больший объём функционала приложения,
> нежели у программ для контроллеров
Не больший. Уж поверьте. Коммуникационная библиотека или библиотека управления дисплеем для STM32 нередко намного сложнее, чем код приложений. Опять же таки, разработчик обычно знает и подводные камни коммуникационной библиотеки, и подводные камни jQuery.
> PS это именно самоуничижение, по непонятному для меня признаку. Стыд за коллег выражается, обычно,
> иначе… менее активно и громко, как минимум.
Я просто написал своё мнение. Потом меня один тролль втянул в дискуссию с ним, тут, признаюсь, я погорячился. Он до сих пор вон не угомонится, гадит в форум :)
> ТЗ для веб-приложения никогда не бывает полным. Поэтому «как не должно работать» можно только
> относительно достоверно прогнозировать.
> Библиотеки, в случае с вебом — их много больше и они несут больший объём функционала приложения,
> нежели у программ для контроллеров
Не больший. Уж поверьте. Коммуникационная библиотека или библиотека управления дисплеем для STM32 нередко намного сложнее, чем код приложений. Опять же таки, разработчик обычно знает и подводные камни коммуникационной библиотеки, и подводные камни jQuery.
> PS это именно самоуничижение, по непонятному для меня признаку. Стыд за коллег выражается, обычно,
> иначе… менее активно и громко, как минимум.
Я просто написал своё мнение. Потом меня один тролль втянул в дискуссию с ним, тут, признаюсь, я погорячился. Он до сих пор вон не угомонится, гадит в форум :)
Нет, пользователи всегда подходят с точки зрения «нести отвестветвенность» (синонимизируя с «бороться с проблеммами»). И так было пока компании не начали чётко прописывать, под какие браузеры проверяется, под какие — нет. И вот этот текущий подход вы как раз и называете безотвественным в соседнем месте.
Программисты фольцвагена, кстати, вполне возможно, сейчас в такой же ситуации (код и ТЗ никто из нас не видел, поэтому сказать точно — невозможно) — вполне возможно, что они понятие не имели предназначение этого режима (и как верно предположили в других комментариях — этот режим может использоваться с пользой вне тестовых стендов).
Сомневаюсь, что отношение объёма библиотек к объёму кода такое же как в вебе. Вы можете назвать конкретные цифры?
Это не один тролль (он длительное время вёл корректную полемику), это двое вас (ты и khim, с него, кстати, вроде всё началось), упорно высказывая непопулярную точку зрения (причём khim, возможно и троллил) добились высокого градуса полемики…
Программисты фольцвагена, кстати, вполне возможно, сейчас в такой же ситуации (код и ТЗ никто из нас не видел, поэтому сказать точно — невозможно) — вполне возможно, что они понятие не имели предназначение этого режима (и как верно предположили в других комментариях — этот режим может использоваться с пользой вне тестовых стендов).
Сомневаюсь, что отношение объёма библиотек к объёму кода такое же как в вебе. Вы можете назвать конкретные цифры?
Это не один тролль (он длительное время вёл корректную полемику), это двое вас (ты и khim, с него, кстати, вроде всё началось), упорно высказывая непопулярную точку зрения (причём khim, возможно и троллил) добились высокого градуса полемики…
> Нет, пользователи всегда подходят с точки зрения «нести отвестветвенность» (синонимизируя с «бороться с
> проблеммами»)
Речь шла не о том, «как хочется пользователю», а «как должно быть». Это очевидно, что пользователю хочется по-максимуму всё самое лучшее, и чтобы бесплатно. Это другая абсолютная крайность, которая тоже неправильная.
> И вот этот текущий подход вы как раз и называете безотвественным в соседнем месте.
Вы вообще не поняли сути спора. Безответственным я называю не подход, когда компании чётко прописывают свою ответственность. Это как раз исключение из правил. В большинстве EULA вы увидите волшебное слово «AS IS» и аналогичные формулировки. Поставщики ПО не несут вообще ответственности за его качество. Никакой. Если вы купите лицензию на использование приложения, и оно окажется глючным, нестабильным и т.д., вы не сможете пойти и забрать свои деньги. Вы сможете ждать доброй воли разработчика, чтобы он выпустил патч, рассчитывая понравиться клиенту. Или не ждать, если это специализированное ПО, и клиенты никуда все равно не денутся.
Если приложение своей ошибкой (не из-за броузера, не из-за среды исполнения или сбоя железа, а именно из-за обычной ошибки, которую легко отловить простым тестированием) нанесло вам материальный ущерб, вы не сможете пойти и потребовать от разработчика компенсации. Не сможете, и всё. Вот про это и был спор. А не про то, как-там-бедным-несчастным-программистам-тяжело-тестировать-код в этом немеренно сложном окружении.
> Сомневаюсь, что отношение объёма библиотек к объёму кода такое же как в вебе. Вы можете назвать
> конкретные цифры?
Ну, вот глянул в Keil, стек TCP на ARM-ядро (например, под STM32) — килобайт 20 в ОЗУ и около 40К в ПЗУ. SSL — чуть больше 30К в ОЗУ и 100К в ПЗУ. Это много, учитывая, что подавляющее большинство моделей STM32 и их аналогов несут на борту 64-128К ОЗУ, и только несколько топовых 256-384К.
Да, сорри, я не должен был это знать, у меня ограниченный кругозор, ведь раз я занимаюсь ERP, то кроме ERP ничего знать не должен.
> упорно высказывая непопулярную точку зрения
Вот именно. Причина такого возмущения как раз в этом слове и кроется. Рассказывать на ИТ-сайте о том, что наша индустрия ведёт бизнес некрасиво, это дело неблагодарное, я прекрасно отдаю себе в этом отчёт. Это все равно что в мечеть зайти, и сказать, что Аллах фигня, а Будда истинный пророк.
> проблеммами»)
Речь шла не о том, «как хочется пользователю», а «как должно быть». Это очевидно, что пользователю хочется по-максимуму всё самое лучшее, и чтобы бесплатно. Это другая абсолютная крайность, которая тоже неправильная.
> И вот этот текущий подход вы как раз и называете безотвественным в соседнем месте.
Вы вообще не поняли сути спора. Безответственным я называю не подход, когда компании чётко прописывают свою ответственность. Это как раз исключение из правил. В большинстве EULA вы увидите волшебное слово «AS IS» и аналогичные формулировки. Поставщики ПО не несут вообще ответственности за его качество. Никакой. Если вы купите лицензию на использование приложения, и оно окажется глючным, нестабильным и т.д., вы не сможете пойти и забрать свои деньги. Вы сможете ждать доброй воли разработчика, чтобы он выпустил патч, рассчитывая понравиться клиенту. Или не ждать, если это специализированное ПО, и клиенты никуда все равно не денутся.
Если приложение своей ошибкой (не из-за броузера, не из-за среды исполнения или сбоя железа, а именно из-за обычной ошибки, которую легко отловить простым тестированием) нанесло вам материальный ущерб, вы не сможете пойти и потребовать от разработчика компенсации. Не сможете, и всё. Вот про это и был спор. А не про то, как-там-бедным-несчастным-программистам-тяжело-тестировать-код в этом немеренно сложном окружении.
> Сомневаюсь, что отношение объёма библиотек к объёму кода такое же как в вебе. Вы можете назвать
> конкретные цифры?
Ну, вот глянул в Keil, стек TCP на ARM-ядро (например, под STM32) — килобайт 20 в ОЗУ и около 40К в ПЗУ. SSL — чуть больше 30К в ОЗУ и 100К в ПЗУ. Это много, учитывая, что подавляющее большинство моделей STM32 и их аналогов несут на борту 64-128К ОЗУ, и только несколько топовых 256-384К.
Да, сорри, я не должен был это знать, у меня ограниченный кругозор, ведь раз я занимаюсь ERP, то кроме ERP ничего знать не должен.
> упорно высказывая непопулярную точку зрения
Вот именно. Причина такого возмущения как раз в этом слове и кроется. Рассказывать на ИТ-сайте о том, что наша индустрия ведёт бизнес некрасиво, это дело неблагодарное, я прекрасно отдаю себе в этом отчёт. Это все равно что в мечеть зайти, и сказать, что Аллах фигня, а Будда истинный пророк.
большинстве EULA вы увидите волшебное слово «AS IS» и аналогичные формулировки
Это и называется — чётко прописать свою ответственность.
Ничем не хуже «покроем любые убытки в пределах 100 рублей», ну или в пределах уставного капитала компании, от конкретных чисел суть не меняется.
И именно этой крайности вы и придерживаетесь.
Именно! Волшебное слово «as is» чётко описывает то, чем отвечает поставщик общего решения перед конкретным покупаетелем. В конкретных договорах разработки, например, прописываются сроки реакции и меры ответственности, которые несёт компания-разработчик. Это ваше требование очень похоже на ситуацию вида — купили обычный компьютер в магазине, поставили в качестве сервера банковского, а он возьми и сходни! Миллиардные потери компания понесла! А размер ответственности производителя какой? Правильно — стоимость компьютера! Стоимость ПО отработавшего в корне неверно так же можно вернуть. Возможно, через суд, но это зависит от конкретного поставщика.
А каков объём кода более-менее нормального решения? Просто отношение в вебе, по примерной прикидке, нередко колеблется около 90-95% библиотечного кода…
Молодец, что знаешь, можешь взять пряник с полки. Это не отменяет вашу упёртость и непопулярность точки зрения.
Ну да, приходите вы такой весь в белом в таксопарк и кричите «таксисты мудаки!» — вот примерно из той же оперы. Безнес и IT — это совершенно разные вещи.
Именно! Волшебное слово «as is» чётко описывает то, чем отвечает поставщик общего решения перед конкретным покупаетелем. В конкретных договорах разработки, например, прописываются сроки реакции и меры ответственности, которые несёт компания-разработчик. Это ваше требование очень похоже на ситуацию вида — купили обычный компьютер в магазине, поставили в качестве сервера банковского, а он возьми и сходни! Миллиардные потери компания понесла! А размер ответственности производителя какой? Правильно — стоимость компьютера! Стоимость ПО отработавшего в корне неверно так же можно вернуть. Возможно, через суд, но это зависит от конкретного поставщика.
А каков объём кода более-менее нормального решения? Просто отношение в вебе, по примерной прикидке, нередко колеблется около 90-95% библиотечного кода…
Молодец, что знаешь, можешь взять пряник с полки. Это не отменяет вашу упёртость и непопулярность точки зрения.
Ну да, приходите вы такой весь в белом в таксопарк и кричите «таксисты мудаки!» — вот примерно из той же оперы. Безнес и IT — это совершенно разные вещи.
В большинстве EULA вы увидите волшебное слово «AS IS» и аналогичные формулировки.
Не заключайте такие соглашения. Заключайте договора с поставщиками ПО, которые несут материальную ответственность за качество ПО. Не хотят заключать? А вы пробовали? Сколько миллиардов долларов предлагали за виндовс, например?
веб-программа:
браузер (ассорти, все с багами) — отвечает клиент
исполнитель js (без багов?) — отвечает клиент
железо клиента (без багов?) — отвечает клиент
сетевой канал (без проблем?) — отвечает клиент/провайдер
...
И как это всё применить в реальном судопроизводстве?
Что-то глюкнуло, юзер побежал писать заявление на возмещение убытков.
Эксперт, назначенный судом, воспроизводит глюк и подробно, доказательно описывает, кто виноват и что делать.
Сколько стоит эта работа? Истец будет её оплачивать, если убыток меньше, чем стоимость этой работы?
Что делать, если эксперт не смог установить причины (а деньги ему всё равно надо заплатить, т.к. время потрачено) — за счёт истца платить?
Работу эксперта и прочие издержки должна оплачивать проигравшая в суде сторона. Это хорошее, проверенное правило.
> Это и называется — чётко прописать свою ответственность.
Это называется «рынок работает в условиях сверхприбылей». Как только спрос и предложение на ИТ-услуги выровняются, эта норма станет роскошью сама по себе.
> Это и называется — чётко прописать свою ответственность.
Это называется «рынок работает в условиях сверхприбылей». Как только спрос и предложение на ИТ-услуги выровняются, эта норма станет роскошью сама по себе.
издержки должна оплачивать проигравшая в суде сторона
А если суда не было? Не нашёл эксперт доказательств. Неплохой кстати способ парализовать работу софтверной компании — ведь эксперт должен получить и все исходные коды, и полный доступ к серверам для расследования, и при необходимости любые права доступа для проведения следственных мероприятий.
Я кажется понял, что сделают софтверные компании, чтобы соблюсти идеальный баланс между своими доходами, полной гарантией в рамках законов и удорожанием продукта в 100500 раз. Но вам это решение вряд ли понравится.
Софтовые компании просто будут заключать договора на обслуживание со страховыми. По аналогии с покупкой техники в кредит — магазин получил свою гарантированную долю, а дальнейшее сопровождение долга — забота банка.
Т.е., покупая условно Windows, пользователь платит 5000 руб. в Microsoft (и это цена, которая есть без введения гарантий) плюс страховая наценка, которая устанавливается полностью по воле страховой компании. Может быть даже будут разные редакции: Windows Госстрах и Windows АльфаСтрахование, чтобы пользователь мог выбрать между дешёвой ценой и лёгкостью получить компенсацию. А уж страховщики собаку съели на оценке рисков, чтобы продукт не стал стоить в 1000 раз дороже, и на защите своих интересов в суде, чтобы у пользователей не возникло желания злоупотребить своими правами.
Кормить посредников-юристов это самое простое, на что пойдут компании при введении таких законов. Главное, что в самих компаниях ничего не меняется. На такую схему вы согласны?
Если суда не было, и полюбовно не договорились, то никто никому ничего не должен, это тоже стандартная практика. Если эксперт не нашел доказательств, то истец проигрывает суд.
> Софтовые компании просто будут заключать договора на обслуживание со страховыми
Я думаю, произойдёт так, как сейчас происходит с банками. Вы в курсе, что если с вашей карты уводят деньги по мошенническим операциям, и вы это доказываете, банк их вам компенсирует за свой счёт? В банках для этого специально есть резервный фонд. Грубо говоря, в стоимости обслуживания карт уже заложена страховая сумма, примерно 5%, на покрытие рисков владельца.
> плюс страховая наценка, которая устанавливается полностью по воле страховой компании
Ну, не совсем по воле. Деятельность страховых компаний достаточно зарегулирована, и их наценки, резервы, размеры и порядок хранения денежных средств и т.д., всё это рассчитывается по законодательным нормам.
> Главное, что в самих компаниях ничего не меняется. На такую схему вы согласны?
Я считаю, что во многих случаях поменяется. Ведь качество ПО будет напрямую коррелировать с размером оборотгных средств, замороженных в страховом фонде :)
> Софтовые компании просто будут заключать договора на обслуживание со страховыми
Я думаю, произойдёт так, как сейчас происходит с банками. Вы в курсе, что если с вашей карты уводят деньги по мошенническим операциям, и вы это доказываете, банк их вам компенсирует за свой счёт? В банках для этого специально есть резервный фонд. Грубо говоря, в стоимости обслуживания карт уже заложена страховая сумма, примерно 5%, на покрытие рисков владельца.
> плюс страховая наценка, которая устанавливается полностью по воле страховой компании
Ну, не совсем по воле. Деятельность страховых компаний достаточно зарегулирована, и их наценки, резервы, размеры и порядок хранения денежных средств и т.д., всё это рассчитывается по законодательным нормам.
> Главное, что в самих компаниях ничего не меняется. На такую схему вы согласны?
Я считаю, что во многих случаях поменяется. Ведь качество ПО будет напрямую коррелировать с размером оборотгных средств, замороженных в страховом фонде :)
Деятельность страховых компаний достаточно зарегулирована, и их наценки, резервы, размеры и порядок хранения денежных средств и т.д., всё это рассчитывается по законодательным нормамЭто уже отношнения страховщиков и законодателей, софтверным компаниям не интересно.
Ведь качество ПО будет напрямую коррелировать с размером оборотгных средств, замороженных в страховом фондеЭто почему? Софтверные компании не вкладывают деньги в фонды. Они ищут партнёров со своими фондами. Нет фондов — найдём другого страховщика, благо тут страховая компания — поставщик услуг, а софтверная — капризный клиент. И страховщики будут конкурировать между собой, предлагать хорошие условия, лишь бы получить контракт с той же Microsoft, присосаться к денежному потоку и получить клиентов.
Как только спрос и предложение на ИТ-услуги выровняются
Этого не случится до момента создания искусственного интеллекта.
Да толку с ним общаться нету, у него как выяснилось ни опыта работы ни понимания процессов, считает что купив 100500 тестеров — можно обеспечить качество и то что компания должна отвечать за каждый ущерб по каждому багу. То что текущее положение вещей устраивает 99% компаний гораздо больше чем его глупые предложения — игнорирует. А заниматься самоуничижением — это видимо такое вынужденное, когда ничего не понимаешь но пытаешься сунуть свой нос и «запретить, не пущать, зарегулировать». Прямо из думы сбежал.
PS для справки — баги в чипах есть, баги в процессорах есть, баги в памяти есть. И нет, партии из-за этого не отзывают — на процессоры ставятся блокировки багованного функционала (Intel, привет тебе с твоей транзакционной памятью!), в чипах на серию вешается информация в даташит (чипы идут по сильно уменьшенной цене)… в редких случаях «совсем не юзабельно» отзывается вся серия, в памяти используются различные алгоритмы переопределения ячеек памяти.Даже существенно более простые микросхемы (типа периферийных контроллеров, микроконтроллеров, драйверов) порой имеют богатые errata sheets, что уж там.
Рынок магическим образом эти деньги ни от куда не возьмет, а не магическим образом — будете платить за лицензию в 10 раз дорожеВсего в 10? Уже хочу! Сейчас Windows Server Datacenter Edition стоит не в 10, а в 600 раз дороже, а в качестве гарантий — всё тот же шиш с маслом, что и у Windows Home Edition!
Тут как с пакетом молока: за сорвавшуюся сделку на миллиарды производитель платить не будет, а вот счёт от врача — оплатит как миленький. У производителей же ПО (независимо от того для чего оное ПО предназначено) в качестве компенсации — стоимость ПО и не более того.
То, что Windows Home Edition «приходит» без гарантий я могу принять, то, что Windows Server Datacenter Edition их тоже не включает — уже нет. Это фактически одно и то же изделие в разных коробках (да, кое-какого кода в Datacenter Edition добавили, но подавляющий объём кода — общий), за что я плачу, если не за повышенные гарантии?
Ну ценообразование можно объяснить разными способами. Некоторые например могут продавать home версию вообще в убыток (т.е. если бы продавали только ее или все по одинаковой home цене — был бы убыток), но с целью увеличить количество специалистов знакомых с софтом, а на enterprise версиях уже отбивают деньги. Или например поддержка может стоить денег, ну или надо учитывать что пусть там + миллион строк кода но этот код продается гораздо меньшему числу клиентов — отсюда и цена. Куча вариантов.
Ну а раз у вас уже появилась «куча вариантов», то может и про "$3M за лицензию в год" и «ОС? $10M за лицензию» не стоит рассказывать сказок?
Ответственность за выпущенную продукцию — она тоже разная бывает: с китайского производитель болтов «за три копейки пучок» и стоимость болтов может оказаться невозможным стрясти, а производитель болтов для авионики — может вам и миллиардные убытки скомпенсировать если самолёт по его вине упадёт.
И только разработчики ПО упорно придерживаются формулы «вы нам $100500 за наше поделие, а в случае чего — мы, может быть, от доброты душевной, их вернём».
Давно уже пора вводить разумную ответственность — а если производящие ПО компании этого ещё не поняли, то это, как я уже говорил, за них сделает государство. Причём всё наверняка будет сделано с куда более серьёзными последствиями для отрасли, но тут уж «удивляться не приходится»: если специалисты по разработке ПО свои проблемы решать не хотят, то их придётся решать кому-то ещё…
И никаких проблем для open source: то, что вы получаете бесплатно — приходит без всяких гарантий, под вашу личную ответственность, а если кто open source продаёт (это же, в общем, тоже не запрещено) — будет отвечать так же как и любой нормальный производитель.
Ответственность за выпущенную продукцию — она тоже разная бывает: с китайского производитель болтов «за три копейки пучок» и стоимость болтов может оказаться невозможным стрясти, а производитель болтов для авионики — может вам и миллиардные убытки скомпенсировать если самолёт по его вине упадёт.
И только разработчики ПО упорно придерживаются формулы «вы нам $100500 за наше поделие, а в случае чего — мы, может быть, от доброты душевной, их вернём».
Давно уже пора вводить разумную ответственность — а если производящие ПО компании этого ещё не поняли, то это, как я уже говорил, за них сделает государство. Причём всё наверняка будет сделано с куда более серьёзными последствиями для отрасли, но тут уж «удивляться не приходится»: если специалисты по разработке ПО свои проблемы решать не хотят, то их придётся решать кому-то ещё…
И никаких проблем для open source: то, что вы получаете бесплатно — приходит без всяких гарантий, под вашу личную ответственность, а если кто open source продаёт (это же, в общем, тоже не запрещено) — будет отвечать так же как и любой нормальный производитель.
Нет, мы конечно все знаем государства которые могут ввести законы не только «с куда более серьёзными последствиями для отрасли» но и просто убивающие эту отрасль на корню. Но вы же понимаете что не везде законы принимают клинические идиоты, правда? Пойдете в сенат с предложением «а давайте зарубим отрасль и потеряем триллионы чтобы кто-то суммарно сэкономил миллиарды»? Ну даже если пойдете — над вашей шуткой посмеются и вернутся к работе.
И никаких проблем для open source: то, что вы получаете бесплатно — приходит без всяких гарантий, под вашу личную ответственность, а если кто open source продаёт (это же, в общем, тоже не запрещено) — будет отвечать так же как и любой нормальный производитель.Т.е. продаю я за 10 рублей софт со своим маленьким патчем и уже ответственный, вот же у вас фантазии. Сейчас софт стоит ровно столько чтобы окупить его разработку. Маржа производителей ПО достаточно низкая на уровне 10-20% в зависимости от компании. Для того чтобы осуществить то что вы говорите надо поднять расходы в разы (а с учетом дефицита кадров может и на порядок и больше) и при этом еще и риски вырастут. Ну абсурд же. Ответственность все прописывают в договоре. Если продолжают так прописывать то или нету спроса на такую высокую надежность и гарантии либо это просто невозможно сделать в разумных бюджетах, не находите?
И только разработчики ПО упорно придерживаются формулы «вы нам $100500 за наше поделие, а в случае чего — мы, может быть, от доброты душевной, их вернём».
А может это не разработчики, а их клиенты не хотят работать по формуле «мы вам 100500 000 за ваше поделие, чтобы вы если что заплатили нам ...»?
ради получения хоть каких-то гарантий платить "$10M за лицензию в базовой комплектации". Почему вдруг?
У нас рынок. Был бы стпрос и возможность сделать дешевле, сделали бы.
Либо нет спроса на гарантии, либо не получается сделать дешевле.
Все подобные требования и вводятся в законодательном порядке, потому что рынок тут не работает.
Рынок — он слеп и глух и стремится к тому, чтобы сделать как можно дерьмовей и дешевле. А если что-то потом взорвётся или сгорит — ну так это когда ещё будет. Условно говоря дешевле застраховаться на случай Чернобыля или Фукусимы, чем предотвращать их. А если страховки не хватит — государство «досыпет», благо прецедентов — вагон и маленькая тележка.
Рынок — он слеп и глух и стремится к тому, чтобы сделать как можно дерьмовей и дешевле. А если что-то потом взорвётся или сгорит — ну так это когда ещё будет. Условно говоря дешевле застраховаться на случай Чернобыля или Фукусимы, чем предотвращать их. А если страховки не хватит — государство «досыпет», благо прецедентов — вагон и маленькая тележка.
А когда аккумулятор внезапно быстрее теряет емкость из-за чего у вас гаснет электричество и срывается важная сделка — вам так же никто ничего не компенсирует. Если вы хотите аккумулятор с подобными гарантиями — он будет много дороже и его обслуживанием будут заниматься представители производителя далеко не на бесплатной основе (а влезание туда любого другого человека будет автоматически обнулять гарантию, ровно как и нарушение режима влажности и еще куча вещей). И срок службы этого аккумулятора будет обозначет условно «1 год, далее замена/обслуживание», не сделали эту «замену/обслуживание» — гарантия аннулируется. Все еще хотите такой аккумулятор?
А если сервер взорвется — я думаю ситуация будет такая же как с аккумулятором. Тут все просто. Вероятность взрыва при текущем техпроцессе крайне мала, эти риски производитель готов нести, т.к. сильных дополнительных затрат они не несут. В софте уменьшение вероятности стоит очень больших денег и времени, никто просто так не будет этим заниматься (иначе вылетит с рынка). Занимаются этим только там где это очень нужно. С точки зрения программиста все то же самое — если ему говорят «зарплата такая же но ответственность вплоть до уголовной» — то он просто не пойдет на такое место, поэтому мало того что на написание ПО будет тратиться несравнимо больше времени — еще и ЗП программистов будет сильно выше (а еще надо учесть что при таком раскладе программисты нужны тоже высокой квалификации).
Делают не тяп-ляп, делают так как позволяют технологии (иначе, если было бы возможно, кто-то начал бы делать не «тяп-ляп» как вы выражаетесь, и сразу подмял бы под себя весь рынок, коли цена сравнима а надежность заметно выше, но так не происходит, догадайтесь почему).
Никто в здравом уме не будет вводить подобную ответственность, т.к. это сильно ударит по отрасли, всех устраивает текущее положение вещей, где важна надежность — используется избыточность, она дает даже при не особо надежных частях достаточный суммарный запас прочности, и обходится дешевле.
И вообще сравнивать с мостом, как тут делают — некорректно. Вот построили вы мост, все хорошо, все процессы выполнены, а потом внезапно началось идеальное землетрясение с частотой точь в точь как частота резонанса моста — мост рухнул. Или внезапно на мост упал метеорит. Будете сажать архитектора за то что он не предусмотрел защиту от метеоритов? А в разработке ПО таких ситуаций тысячи.
А если сервер взорвется — я думаю ситуация будет такая же как с аккумулятором. Тут все просто. Вероятность взрыва при текущем техпроцессе крайне мала, эти риски производитель готов нести, т.к. сильных дополнительных затрат они не несут. В софте уменьшение вероятности стоит очень больших денег и времени, никто просто так не будет этим заниматься (иначе вылетит с рынка). Занимаются этим только там где это очень нужно. С точки зрения программиста все то же самое — если ему говорят «зарплата такая же но ответственность вплоть до уголовной» — то он просто не пойдет на такое место, поэтому мало того что на написание ПО будет тратиться несравнимо больше времени — еще и ЗП программистов будет сильно выше (а еще надо учесть что при таком раскладе программисты нужны тоже высокой квалификации).
Делают не тяп-ляп, делают так как позволяют технологии (иначе, если было бы возможно, кто-то начал бы делать не «тяп-ляп» как вы выражаетесь, и сразу подмял бы под себя весь рынок, коли цена сравнима а надежность заметно выше, но так не происходит, догадайтесь почему).
Никто в здравом уме не будет вводить подобную ответственность, т.к. это сильно ударит по отрасли, всех устраивает текущее положение вещей, где важна надежность — используется избыточность, она дает даже при не особо надежных частях достаточный суммарный запас прочности, и обходится дешевле.
И вообще сравнивать с мостом, как тут делают — некорректно. Вот построили вы мост, все хорошо, все процессы выполнены, а потом внезапно началось идеальное землетрясение с частотой точь в точь как частота резонанса моста — мост рухнул. Или внезапно на мост упал метеорит. Будете сажать архитектора за то что он не предусмотрел защиту от метеоритов? А в разработке ПО таких ситуаций тысячи.
Забейте на всё, что написано выше. Здесь есть проблема куда глубже.
А я считаю, что есть толк в массовом осознании того, что двое программистов могут вертеть многомиллиардную корпорацию. Наша работа сродни магии — ее плохо кто понимает, еще меньше владеют ей, но при этом все ей пользуются. При всем при этом мы — самая социально незащищенная группа: нет никаких способов бороться за свои права. Забастовка водителей автобусов прализует город. Забастовка мусорщиков — и весь город в грязи. Забастовка программистов или администраторов… кто-нибудь слышал что-либо глупее? Не выйти на работу врачу — это его право. А вот админу остановить сервер — это уже преступление. Во что это может вылиться? Скорей потребуют более жесткий контроль за деятельностью программеров.
В данном случае все легко закончится: программеры будут тупо все отрицать и говорить, что не ведали, что делают: типа нам сказали — мы сделали. Обвинитель, в данном случае компания, не сможет им ничего противопоставить: являясь одновременно и заказчиком, они не смогут утверждать, что программерам все было известно заранее, при этом не подставив себя.
Он забыл сказать, что у них есть спецы водилы для тестов, это не так просто проехать по нормам для тестового цикла FTP-75 с выхлопами в пределах ограничений.
Для желающих поиграть в проходящие тесты: github.com/cezheng/Volkswagen-Xcode
Detects when your Xcode tests are being run in a CI server, and makes them pass.
Я бы на месте программистов написал универсальный интерфейс для приема режимов извне согласно требованиям создал/сгенерировал «шаблоны» необходимых режимов. Далее если бы мне сказали, что при поступлении сигнала X должен применяться режим X' я бы даже не стал задумываться зачем так нужно. Все есть в требованиях. Я же инженер программист, а не инженер-эколог, инженер-проектировщик ДВС. Откуда мне знать как будет меняться выхлоп если, например, в газовую смесь добавить 2мг дизельного топлива? У меня просто есть шаблон который делает это в системе по команде от ECU. Так в чем же моя вина? В том что я не разбираюсь помимо программирования в экологии и ДВС на достаточном для анализа уровне?
В списке ваших вопросов/утверждений, явно не хватает:
Они не понимали, что они делали, потому что это вне их компетенции.
Почему-то все забыли об этом слове
В списке ваших вопросов/утверждений, явно не хватает:
Они не понимали, что они делали, потому что это вне их компетенции.
Почему-то все забыли об этом слове
С рамками ответственности инженеров всё не так просто, как кажется. Планирую написать ответ дяде Бобу.
Вспомнилась история про фейковые данные со станции МИР и программсита, которого «попросили» это написать :)
del
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Скандал вокруг Volkswagen и роль программистов в нём