Т.е. вы утверждаете, что в наших законах есть что-то, согласно чему пункт договора «в ошибках программного обеспечения виноват Покупатель» (именно в такой абсолютной формулировке и именно без других пунктов вроде «кроме случаев, когда Продукт был украден etc») становится ничтожным в случае, если покупатель не пользуется купленным автомобилем?
> покупатель расписался при покупке, что в глюках ПО виноват он
> Б был не за рулём и вообще не давал права на управление В
Мне кажется, что одно другому не мешает. Раз покупатель на бумаге виноват в глюках ПО, то виноват именно он, а не водитель. Нефиг подписывать такие условия (^_^)
Чи! (^_^) Правда, Хокинг ни разу не Эльда… А если посмотреть на тенденцию Гугла отследить каждый шаг пользователя (взять хоть тот же Chrome с кучей форков, одной из важных фич которых является удаление всей «шпионской» активности), то несколько раз подумаешь перед тем, как привести чобита домой (-_-) — желание хранить секреты (заканчивая паранойей) никто не отменял.
Т.е. я пытаюсь выяснить, чем конкретно будут руководствоваться соответствующие органы при вынесении обвинительного приговора, и как можно «упростить» их работу путем введения конкретных условий, чтобы не вышло ситуации «телега родила теленка» (что-то произошло, а информации для адекватного вынесения приговора попросту нет, и судьи будут руководствоваться какими-то своими домыслами вместо объективной информации).
Я не до конца понимаю нить нашего разговора. Есть контракт на разработку инструмента. Есть исполнитель контракта, который его нарушил. Есть приемщик, который все-таки закрыл контракт (т.е. признал, что он выполнен в полном объеме). Есть некоторое неприятное событие, связанное с потерей жизни/здоровья, которое возникло из-за того, что исполнитель все-таки накосячил. Мы пытаемся выяснить (если не брать во внимание мой комментарий выше), кто должен быть наказан. Я предлагаю внести в контракт конкретность, например, в виде пункта «В случае возникновения угрозы жизни или здоровью, связанной со сбоем продукта, ответственность возлагается на исполнителя».
То, что правонарушение отличается от преступления, я знаю, спасибо. Меня интересует конкретный случай, где правонарушение повлекло за собой преступление, и способы его решения. Конкретно — возможность внесения в договор пункта, описанного выше, в том числе и законодательная поддержка.
Если это связано с нашим законодательством, то я, к сожалению, не знаком с юридической стороной данного вопроса. Если же нет (т.е. в законах нет запрета оговаривать условия ответственности в договоре), то почему не может?
У нас имеется интересная тенденция перекладывать вину до тех пор, пока не появится козел отпущения, которого можно будет наказать. Робот — механизм, его не накажешь. А вот тех, кто его сделал, наказать можно. А человек — суть есть тот же механизм, только во много раз более сложный. У него так много паттернов поведения, что некоторые уже отчаялись найти закономерности и объявили человека существом выше обычных систем, не подчиняющимся никаким правилам, а значит, не механизмом (магией, вестимо — как же еще объяснить работу того, о чем мы не знаем, как оно работает?).
С другой стороны, на самом деле нам нужно не наказать кого-то, а пресечь подобные действия в будущем (не будем путать цель и способы ее достижения). Сбойного робота, безусловно, убираем с эксплуатации и чиним (или выкидываем). А вот что дальше делать? Действительно, либо робота закоротило из-за каких-то неизвестных на то время причин (а наказывать за то, чего предположить было практически невозможно, я не считаю адекватным, ибо опыта такое наказание практически не добавит (ну, только конкретный случай), а вот страх ошибки усилит (и мы можем получить неудачника, который боится что-либо делать)), либо кто-то из персонала недостаточно хорошо проверил соответствие изделия документам (а тут уже в ход идет договор — если нигде не прописано, кто за эту ситуацию отвечает, то какое мы имеем право выбирать случайного человека (а с юридической точки зрения оно именно так и выглядит) и называть его верблюдом?).
Короче говоря, расчет, холодный расчет, и ничего более. Потешить свое самолюбие, почувствовать себя сильным, выдвигая обвинительный приговор — всегда пожалуйста, но не в ущерб другим делам.
P.S. Все вышесказанное — сугубо мои мысли, и я не переходил на личности.
А давайте посадим производителей оружия за то, что они производят машины убийства. Или даже лучше — давайте посадим педагогов, учителей и родителей тех детей (неважно, сколько последним лет), которые выросли в убийц. Мы же не только исполнителей преступления сажаем, но и соучасников, а те, кто участвовал в развитии личности убийцы (пусть даже и не специально — не думаю, что программисты специально выделывают easter egg'и для геноцида), суть есть соучасники преступления.
Если программист выполнил ТЗ, а клиент не умеет пользоваться продуктом — вина клиента. Если программист не выполнил ТЗ, а клиент принял такой продукт — вина клиента, потому что договор превыше каких-то там эмоциональных соображений о справедливости во всем мире.
Я имел в виду то, что устройство без программы — простая железка, а вот та программа, которая на них выполняется, как раз и заставляет их генерировать прерывания, передавая их другим компонентам (сетевая карта слушает порт, и если она «услышит» сигнал, она разбудит ЦП, который обработает поступивший пакет, и «забудит» обратно).
Да, если это аппаратные прерывания (и если я правильно представляю, как оно может работать без такой же постоянно слушающей программы, пусть и низкоуровневой)…
Так, стоп. А кто эти прерывания генерировать будет? Тоже программы ведь. Если не программы, значит, обработку нужно выносить на внешнее устройство, чтобы процессор вообще не был занят (ни пользовательскими программами, ни ОС, ни низкоуровневыми вещами) и, соотвественно, мог останавливать свою работу. А внешнее устройство также требует источник питания. Может, я чего-то не понимаю, но полностью уйти от постоянно работающих программ не получится (банально — генерация сигнала от видеокарты на монитор (видеокарта — тоже компьютер со своим процессором, памятью etc, и кто скажет, что это не так, пусть первый кинет в меня камень)), но можно снизить количество мучающих процессор задач путем сведения всех «опросников состояния» к более-менее единой системе (таймер ОС, аппаратные прерывания). Автор, ты это хотел сказать?
Присоединяюсь. Есть ли hardware-поддержка Event-Driven программ, или же события таки эмулируются опросом «Уже приехали? А теперь приехали?» на самом-самом-самом низком уровне?
Все относительно и сугубо индивидуально. Зависит от многих факторов, в том числе и от того, с чем раньше работал кодер (языки, технологии, стили кодирования etc). Впрочем, как я уже сказал, в основном я у себя использую strpos для таких целей, и поэтому мне это видеть точно так же просто, как и сравнение подстроки с переменной.
Есть такая штука, как желание понимать код без лишних размышлений. Если написано substr($source, 0, strlen($prefix)) == $prefix, то, например, я сразу увижу, что у строки $source проверяется наличие префикса $prefix, пусть и несколько громоздко. Если я увижу strpos($source, $prefix) === 0 или !strncasecmp($source, $prefix, strlen($prefix)), то мне придется чутка поднапрячься, чтобы увидеть то же самое (хотя в первом я это и так вижу, потому что часто использую, а второе понимаю, потому что тоже когда-то писал на Си). А вот если там будут стоять какие-то монструозные конструкции, работающие за «полтора такта» процессора и занимающие пять символов кода (или, наоборот, тридцать строк), но при этом настолько для меня неестественно используемые, то на расшифровку строки кода уйдет много больше времени (по сравнению с примерами выше).
Нет, я не хочу сказать, что ТС сказал какую-то бесполезную глупость — наоборот, спасибо, возможно, я это применю как-нибудь в том же обработчике ошибок. Да, учиться полезно, и так мы узнаем новое. Да, в конце концов есть комментарии. Однако я не из поколения компьютеров размером со шкаф, и у меня нет болезненной идеи оптимизировать все без разбору — я приверженец мысли, что если код требует комментария с описанием работы, когда его (код) можно переписать так, чтобы он был очевиден (другие имена переменных/функций и, возможно, несколько более длинное и неизящное решение), то его нужно переписать, а вот если это — бутылочное горлышко программы, то можно сделать реализацию понепонятней и побыстрее, но отметить это место комментарием «так быстрее работает, чем обычная реализация».
И оно функционирует точно так же, как и в обычном потоке (без сбоев и неадекватных реакций)? Просто мне казалось, что в shutdown уже какие-то компоненты PHP деинициализированы.
Сломаться может что угодно и по разным причинам (та же память, выделенная под скрипт, кончилась, или случайно удалили запятую из кода ядра и забыли про это), но суть не в этом. В таком виде действительно отмена действия фатальных ошибок была бы кстати (не глобально, но в некоторых конкретных случаях). Можно идти на bugs.php.net и делать фичреквест (хотя кажется мне, что такие уже были) (^_^)
А если исключение никто не поймал, то возникнет ошибка Unhandled exception, которая превратится в исключение, которое никто не ловит и которое вызовет ошибку Unhandled exception… ИМХО, ошибки первичней исключений (хотя бы потому что находятся уровнем ниже, как ассемблер ниже си и пайтона).
Производительность — вопрос относительный. ЕМНИП, apache все равно что-нить да заберет в буфер перед отправкой. Короче, все зависит от архитектуры системы. А вот, например, большие файлы как asset'ы (например, хранятся они в БД, и как статику через apache отдать не выйдет) отдавать не получится (банально память кончится, а если не кончится, то сначала PHP все считает в память, потом отдаст apache'у, тот опять все в буфер заберет (ну, точнее не он… не суть, короче — давно стек протоколов учил), а потом уже отдаст клиенту — в итоге достаточно длительное время клиент будет ожидать скачивание).
Исключение — своя комплексная система обработки ошибок и неадекватные функции, которые выплевывают warning'и на события, вполне без этого обходящиеся (например, move_uploaded_file — если файл переместить невозможно, то он возвращает false и выдает warning, когда можно было бы просто вернуть false, а я бы уже разобрался, ругаться пользователю или попытаться переместить еще куда-нибудь).
> Б был не за рулём и вообще не давал права на управление В
Мне кажется, что одно другому не мешает. Раз покупатель на бумаге виноват в глюках ПО, то виноват именно он, а не водитель. Нефиг подписывать такие условия (^_^)
То, что правонарушение отличается от преступления, я знаю, спасибо. Меня интересует конкретный случай, где правонарушение повлекло за собой преступление, и способы его решения. Конкретно — возможность внесения в договор пункта, описанного выше, в том числе и законодательная поддержка.
С другой стороны, на самом деле нам нужно не наказать кого-то, а пресечь подобные действия в будущем (не будем путать цель и способы ее достижения). Сбойного робота, безусловно, убираем с эксплуатации и чиним (или выкидываем). А вот что дальше делать? Действительно, либо робота закоротило из-за каких-то неизвестных на то время причин (а наказывать за то, чего предположить было практически невозможно, я не считаю адекватным, ибо опыта такое наказание практически не добавит (ну, только конкретный случай), а вот страх ошибки усилит (и мы можем получить неудачника, который боится что-либо делать)), либо кто-то из персонала недостаточно хорошо проверил соответствие изделия документам (а тут уже в ход идет договор — если нигде не прописано, кто за эту ситуацию отвечает, то какое мы имеем право выбирать случайного человека (а с юридической точки зрения оно именно так и выглядит) и называть его верблюдом?).
Короче говоря, расчет, холодный расчет, и ничего более. Потешить свое самолюбие, почувствовать себя сильным, выдвигая обвинительный приговор — всегда пожалуйста, но не в ущерб другим делам.
P.S. Все вышесказанное — сугубо мои мысли, и я не переходил на личности.
Если программист выполнил ТЗ, а клиент не умеет пользоваться продуктом — вина клиента. Если программист не выполнил ТЗ, а клиент принял такой продукт — вина клиента, потому что договор превыше каких-то там эмоциональных соображений о справедливости во всем мире.
Так, стоп. А кто эти прерывания генерировать будет? Тоже программы ведь. Если не программы, значит, обработку нужно выносить на внешнее устройство, чтобы процессор вообще не был занят (ни пользовательскими программами, ни ОС, ни низкоуровневыми вещами) и, соотвественно, мог останавливать свою работу. А внешнее устройство также требует источник питания. Может, я чего-то не понимаю, но полностью уйти от постоянно работающих программ не получится (банально — генерация сигнала от видеокарты на монитор (видеокарта — тоже компьютер со своим процессором, памятью etc, и кто скажет, что это не так, пусть первый кинет в меня камень)), но можно снизить количество мучающих процессор задач путем сведения всех «опросников состояния» к более-менее единой системе (таймер ОС, аппаратные прерывания). Автор, ты это хотел сказать?
substr($source, 0, strlen($prefix)) == $prefix, то, например, я сразу увижу, что у строки $source проверяется наличие префикса $prefix, пусть и несколько громоздко. Если я увижуstrpos($source, $prefix) === 0или!strncasecmp($source, $prefix, strlen($prefix)), то мне придется чутка поднапрячься, чтобы увидеть то же самое (хотя в первом я это и так вижу, потому что часто использую, а второе понимаю, потому что тоже когда-то писал на Си). А вот если там будут стоять какие-то монструозные конструкции, работающие за «полтора такта» процессора и занимающие пять символов кода (или, наоборот, тридцать строк), но при этом настолько для меня неестественно используемые, то на расшифровку строки кода уйдет много больше времени (по сравнению с примерами выше).Нет, я не хочу сказать, что ТС сказал какую-то бесполезную глупость — наоборот, спасибо, возможно, я это применю как-нибудь в том же обработчике ошибок. Да, учиться полезно, и так мы узнаем новое. Да, в конце концов есть комментарии. Однако я не из поколения компьютеров размером со шкаф, и у меня нет болезненной идеи оптимизировать все без разбору — я приверженец мысли, что если код требует комментария с описанием работы, когда его (код) можно переписать так, чтобы он был очевиден (другие имена переменных/функций и, возможно, несколько более длинное и неизящное решение), то его нужно переписать, а вот если это — бутылочное горлышко программы, то можно сделать реализацию понепонятней и побыстрее, но отметить это место комментарием «так быстрее работает, чем обычная реализация».