Здравствуйте, Тёмчик, Вы писали:
Тё>А можно сделать такой пакетный менеджер, чтоб он автомагически подтягивал подходящие под фичесет проца сборки? Вместо чтоб устанавливать весь багаж? Или с учётом объёмов современного медиа, это неоправданная трата ресурсов на поддержку зоопарка?
По хорошему, так и надо делать хотя бы со своими библиотеками.
Здравствуйте, reversecode, Вы писали:
R>так там нет ошибки R>и в комментах там очень сильно все разжевали
Ошибки нет, есть неожиданное поведение. Я вот не могу себе представить, чтобы что-то подобное было в Java. Оно есть, конечно. Вот буквально недавно была засада с IdentityHashSet, но там причиной была реализация, а не стандарт языка. А в С++ проблемы на каждом шагу именно из-за невероятной сложности стандарта, а его всё расширают и расширают...
Здравствуйте, Pzz, Вы писали:
Pzz>совершенно не важно, сколько ресурсов этот код потребляет, лишь бы укладывался в разумно достижимые.
Беда лишь в том, что эта "разумная достижимость" почти всегда оценивается на машине разработчика, которая, как правило, по ресурсам значительно превосходит среднюю пользовательскую. Поэтому, когда разработчик полагает, что у него еще есть значительный запас по ресурсам, у пользователя ситуация уже приближается к критической, а когда до разработчика наконец дойдет, что пользователи недовольны не зря, вернуть ситуацию под контроль может быть непросто.
Здравствуйте, Евгений Музыченко, Вы писали:
Pzz>>совершенно не важно, сколько ресурсов этот код потребляет, лишь бы укладывался в разумно достижимые.
ЕМ>Беда лишь в том, что эта "разумная достижимость" почти всегда оценивается на машине разработчика, которая, как правило, по ресурсам значительно превосходит среднюю пользовательскую. Поэтому, когда разработчик полагает, что у него еще есть значительный запас по ресурсам, у пользователя ситуация уже приближается к критической, а когда до разработчика наконец дойдет, что пользователи недовольны не зря, вернуть ситуацию под контроль может быть непросто.
Мне ведь не надо тебе объяснять, что нет смысла вылизывать до микросекунды (и, даже, до 1/10 секунды) код, который один раз при старте программы читает ее конфигурационный файл. А код, который медленно и уныло рисует на экране карту, надо оптимизировать изо всех сил, потому что он все равно будет слишком тормозным. Ты и сам это прекрасно понимаешь. А многие не понимают, в том и беда.
А так, я с тобой не спорю, разработчики склонны переоценивать количество ресурсов на компьютере у пользователя. У меня, например, Яндекс.Карты в режиме навигатора высаживают батарейку на телефоне быстрее, чем беспроводная зарядка успевает ее заряжать. А когда телефон был новым, это было не так — тогда Яндекс ориентировался на мощности, сравнимые с мои телефоном, а теперь мощность того, на что они ориентируются, сильно возрасла.
Здравствуйте, Pzz, Вы писали:
Pzz>нет смысла вылизывать до микросекунды (и, даже, до 1/10 секунды) код, который один раз при старте программы читает ее конфигурационный файл.
До десятой секунды можно и не вылизывать, но уже давно стало нормой открывать/закрывать тот файл при запросе каждого параметра. В итоге, при тестировании на мелких файлах, оно работает очень быстро, а когда файл разрастается до тысяч и десятков тысяч строк, "внезапно" начинает тормозить.
Pzz>разработчики склонны переоценивать количество ресурсов на компьютере у пользователя.
Подозреваю, что многие разработчики вообще не представляют себе компьютер среднего пользователя. На работе им дают продвинутую рабочую станцию, дома у них продвинутый игровой компьютер (ибо платят хорошо), поэтому они искренне полагают, что у всех остальных не хуже.
Pzz>У меня, например, Яндекс.Карты в режиме навигатора высаживают батарейку на телефоне быстрее, чем беспроводная зарядка успевает ее заряжать. А когда телефон был новым, это было не так — тогда Яндекс ориентировался на мощности, сравнимые с мои телефоном, а теперь мощность того, на что они ориентируются, сильно возрасла.
А возросло ли с тех пор удобство пользования картами? Если да, то пропорционально ли?
Здравствуйте, Евгений Музыченко, Вы писали:
Pzz>>У меня, например, Яндекс.Карты в режиме навигатора высаживают батарейку на телефоне быстрее, чем беспроводная зарядка успевает ее заряжать. А когда телефон был новым, это было не так — тогда Яндекс ориентировался на мощности, сравнимые с мои телефоном, а теперь мощность того, на что они ориентируются, сильно возрасла.
ЕМ>А возросло ли с тех пор удобство пользования картами? Если да, то пропорционально ли?
Нет, ухудшилось. Они еще гуйню периодически переверстывают. Только к одному варианту привыкнешь, сразу другой выкатят.
Здравствуйте, Pzz, Вы писали:
ЕМ>>А возросло ли с тех пор удобство пользования картами? Если да, то пропорционально ли?
Pzz>Нет, ухудшилось. Они еще гуйню периодически переверстывают. Только к одному варианту привыкнешь, сразу другой выкатят.
О том и речь. "Этакое состояние запора при бурной работе организма".
КД>>1. вагоны ассертов внизу. КД>>2. эшелоны многоуровневых тестов вверху. КД>>3. круглосуточное тестирование. S>В чем разница между 2 и 3?
Наверное, имелось ввиду, что тесты прогоняются не один раз перед релизом, а при каждом коммите. Или даже fuzzy-testing, который действительно имеет смысл гонять круглосуточно.
Здравствуйте, flаt, Вы писали:
КД>>>2. эшелоны многоуровневых тестов вверху. КД>>>3. круглосуточное тестирование. S>>В чем разница между 2 и 3?
F>Наверное, имелось ввиду, что тесты прогоняются не один раз перед релизом, а при каждом коммите.
Сейчас вроде 2021, а не 2001 и очевидно, что "есть тесты" значит "что есть CI/CD с тестами на каждый коммит" По другому смысла не особо много.
F>Или даже fuzzy-testing, который действительно имеет смысл гонять круглосуточно.
Это уже интереснее.
KP>2) ты в 0.5% проекторв где важна safety (хрен знает как на русский перевести, ОБЖ короче). Это когда у тебя атомный реактор или критический компонент в самолете или самоходной карете. Ну, ты в жопе, тут ничего иного не скажешь. Если ты вдруг в неё залез, то ты пишешь на Си-с-классами где нельзя кидать исключения, нельзя выделять память динамически и много других "нельзя". Из хороших моментов, тот компилятор что ты исполняешь тебя сразу бьет по рукам за попытку прыжка на месте (а иногда и расстреливает), а статический анализатор (за который ты отвалил дохулиард не-рублей) так же, сцуко, люто бдит. В итоге у тебя код где ты точно знаешь что и почему происходит, но за очень много денег, т.к. твоя производительность упала в 5-10 раз.
И при этом все равно на выходе получается MCAS, минус два самолета, минус овер триста человек и никто уже не считает сколько убытков
Здравствуйте, landerhigh, Вы писали:
L>И при этом все равно на выходе получается MCAS, минус два самолета, минус овер триста человек и никто уже не считает сколько убытков
Уже 100500 раз было разжевано, что тот MCAS сам по себе ни разу не фатален. Да, он тупил, но было достаточно несложно ему противодействовать. Если бы пилоты лучше понимали устройство и работу самолета, принципы управления, они бы с высокой вероятностью вытянули ситуацию. Но большинство пилотов предпочитает тупо зазубрить типовые варианты, как большинство водителей — типовые схемы поведения на дороге.
Здравствуйте, landerhigh, Вы писали:
L>И при этом все равно на выходе получается MCAS, минус два самолета, минус овер триста человек и никто уже не считает сколько убытков
Мне кажется, уровень сложности систем уже зашкаливает и несмотря на все эти методологии иногда выходит хтонь. В итоге что ты не делай, вероятность ошибки повышается, ещё ведь и коммерчески выгодное решение должно быть.
Здравствуйте, Евгений Музыченко, Вы писали:
L>>И при этом все равно на выходе получается MCAS, минус два самолета, минус овер триста человек и никто уже не считает сколько убытков ЕМ>Уже 100500 раз было разжевано, что тот MCAS сам по себе ни разу не фатален.
Нет.
При анализе (FMEA) состояния, когда система войдет в состояние, которое требует немедленного вмешательства оператора для предотвращения аварии, считаются катастрофическими сценариями отказа. При наличии подобных сценариев система к продакшену не допускается и отправляется на переработку, возможно даже с нуля.
Направление самолета носом в землю — хрестоматийный вид катастрофический отказа. Как раз сам по себе MCAS — фатален.
ЕМ>Да, он тупил, но было достаточно несложно ему противодействовать. Если бы пилоты лучше понимали устройство и работу самолета, принципы управления, они бы с высокой вероятностью вытянули ситуацию. Но большинство пилотов предпочитает тупо зазубрить типовые варианты, как большинство водителей — типовые схемы поведения на дороге.
Оператор не может рассматриваться в качестве защиты от катастрофичного сценария поведения оборудования.
Здравствуйте, kaa.python, Вы писали:
KP>Мне кажется, уровень сложности систем уже зашкаливает и несмотря на все эти методологии иногда выходит хтонь. В итоге что ты не делай, вероятность ошибки повышается, ещё ведь и коммерчески выгодное решение должно быть.
Да нет, просто этот MCAS писали обезьяны под управлением ослов. Или наоборот.
Это, по сути, вообще довольно тривиальный конечный автомат, который, будучи написан прямыми руками, даже в случае одного датчика вставал бы в безопасный отказ.
Здравствуйте, landerhigh, Вы писали:
L>При анализе (FMEA) состояния, когда система войдет в состояние, которое требует немедленного вмешательства оператора для предотвращения аварии, считаются катастрофическими сценариями отказа. При наличии подобных сценариев система к продакшену не допускается и отправляется на переработку, возможно даже с нуля.
Безусловно, система кривая. Но этот косяк почти везде подают, как "MCAS уронил самолет, пилоты ничего не могли сделать". А они могли, и еще как.
L>Направление самолета носом в землю — хрестоматийный вид катастрофический отказа.
MCAS не "направлял самолет носом в землю" целенаправленно, а неадекватно реагировал на неисправность датчиков. Это хрестоматийный случай "перерегулирования". Если бы в алгоритме были жесткие ограничения, то в другой ситуации он из-за них не выправил бы самолет.
L>Оператор не может рассматриваться в качестве защиты от катастрофичного сценария поведения оборудования.
Это будет верно, когда люди в кабине самолета будут называться "операторами", и их задачей будет лишь наблюдение за показаниями приборов, и нажатие аварийной кнопки в нештатной ситуации. Пока же они называются "пилотами", а их деятельность называется "управление самолетом".
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Безусловно, система кривая. ЕМ>Но этот косяк почти везде подают, как "MCAS уронил самолет, пилоты ничего не могли сделать". А они могли, и еще как.
Совершенно верно. MCAS уронил самолет.
Пилоты не смогли понять, что происходит. На минутку — о том, что в самолете есть какой-то MCAS, им рассказать "забыли".
L>>Направление самолета носом в землю — хрестоматийный вид катастрофический отказа. ЕМ>MCAS не "направлял самолет носом в землю" целенаправленно, а неадекватно реагировал на неисправность датчиков. Это хрестоматийный случай "перерегулирования".
Это и есть "целенаправленно". Оно было реализовано так, чтобы направлять самолет носом в землю, если показания датчиков того велят. В соответствии со спецификациями.
ЕМ>Если бы в алгоритме были жесткие ограничения, то в другой ситуации он из-за них не выправил бы самолет.
В этом и состоит предназначение FMEA, чтобы выяснить, какие ограничения должен алгоритм иметь.
L>>Оператор не может рассматриваться в качестве защиты от катастрофичного сценария поведения оборудования.
ЕМ>Это будет верно, когда люди в кабине самолета будут называться "операторами", и их задачей будет лишь наблюдение за показаниями приборов, и нажатие аварийной кнопки в нештатной ситуации. Пока же они называются "пилотами", а их деятельность называется "управление самолетом".
Это верно всегда. Без исключений.
Пилот может быть банально перегружен.
Добавим еще одну нештатную ситуацию на взлете. Птицы. Пожар двигателя. Отказ гидравлики. Кстати, любая из этих ситуаций может вывести из строя еще и датчик угла атаки за компанию, тем самым инициировав работу MCAS в режиме камикадзе.
Все, четырех рук банально не хватит, какими бы опытными не были оба пилота.
По другому смысла не особо много.
