Здравствуйте, Sinclair, Вы писали:

V>>Т.е. это "ваши" подосрали, а не "наши".
S>Вы сейчас к кому примазываетесь-то? Кого вы "нашими" называете?

Это на кого ты пытаешься свалить ошибки "вашей" безответственной братии.


V>>Суть проблемы — подписанный и абсолютно исправный драйвер оказался способен исполнять внешний подгружаемый p-код.
V>>Всё-таки, доигрались в "легко обновляемые байт-коды", дебилы, Б.
S>В который раз поражаюсь вашей способности читать всё наоборот.
S>1. "Способность исполнять внешний подгружаемый p-код" является не багом, а фичей драйвера

Т.е. багом архитектуры, опять бгг.

Мне уже примерно понятны зигзаги карьеры их технического руководства.
Т.е., вот тебе пошло уже вредительство от игрушечных технологий "генного" плана — это когда разрабы с геномом фриков-лалашек растут по карьёрной лестнице и тянут свои шаловливые ручки к рычагам принятия решений.

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

В реальной работе я бы тебе гвоздя ржавого не доверил, я ж помню твои эксперименты по генерации кода на C# — степень самокритичности примерно нулевая, зато степень очковтирательства и изворотливости — примерно максимально возможная. И это когда уже совсем разжевали и в рот положили сценарии, где код даёт ошибку. Только почему-то посторонний vdimas видит эти косяки сходу, за единицы/десятки секунд, а потративший кучу времени на тему автор с трудом "догоняет" даже спустя несколько раундов объяснений, бгг...

А сдаётся мне, что автор тупо врёт — да не может же он быть НАСТОЛЬКО тупым.
Автор просто врёт себе, врёт окружающим.

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


S>2. Выполнение NRE при исполнении внешнего подгружаемого кода является не фичей, а багом драйвера.

Чего? ))

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

Похоже, в более высокостоящей архитектуре всей этой приблуды не прописали сценарий — как реагировать на проваливающиеся аж на уровень VM тупые NRE байт-кода, бгг...
Такие вещи разрабатываются на архитектурном уровне и выдаются в кач-ве ТЗ техническими лидерами проекта.

Кароч, это не баг в C++, по крайней мере, никакой ошибки в C/C++ в произошедшем нет, бо на этом уровне отработали штатные ср-ва, которые помогли сразу же локализовать проблему.

Да, я понимаю твои рассуждения: "в уютном коде, выполняющемся на уровне ядра, могут быть ошибки, и VM должен был обыграть более гладко!"
Напомню, что это код уровня ядра...
Что ошибки в нейтиве на этом уровне, когда могут быть локализованы, приводят к отключению подсистемы или к BSOD, если нормальное функционирование системы далее невозможно.
А когда ошибки на этом уровне не могут быть локализованы, то машина ведёт себя произвольно — дай бог где-то диагностика заметит какой-то бред и насильно перегрузит (полно и такого кода в мониторе ядра)

Вот и получается, что для более простого, более безопасного языка ты требуешь еще большей толерантности, хотя должно было быть, по-идее, ровно наоборот — ведь "сложнее ошибиться" (С) Синклер!

А на деле, пресловутый NRE ты мог получить даже просто закрыв Windows.Forms в неудачный момент — это ж привычные постоянно исправляемые сомны багов на уровне C#.

Я ведь тщательно слежу за дотнетом еще с 2002-го и сам кучу раз репортил — да не бывает такой плотности багов в нейтивной разработке ни за что и никогда, оно бы ничего и никогда не работало с таким подходом. ))

А дотнетный Решарпер в Студии отваливается десятки раз за день до сих пор, бгг...
Хорошо хоть они догадались разбить его на модули меньшего размера, чтобы при краше модуля подгружать/инициализировать лишь его, а не весь монструозный плагин.

Но такой подход — это роспись в собственной убогости, разумеется.
За 20 лет не могли отловить баги, бгг.
Жесть, конечно...

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

Когда мне в руки на "поиграть" попадает нечто, что "долгие годы исправно работает" (произносится громко, причём сразу от нескольких опытных разрабов) — у меня оно всё начинает резко падать и захлёбываться собственными соплями. ))
Как раз специализируюсь на поиске ненадёжностей в т.ч. в архитектурном плане и в выработке решений по ним.


S>"абсолютно исправный" драйвер не вызвал бы NRE при исполнении произвольного байт-кода.

Ты действительно не понимаешь, или намеренно работаешь на публику?

Это вполне "законный" NRE уровня виртуальной машинки.
Ну как "законный".
Ужас-ужас, конечно, но разработчики на управляемых языках особо не парятся.


S>Склонен согласиться с автором https://medium.com/@vkoukis/the-root-cause-for-the-recent-crowdstrike-mess-is-not-a-content-update-it-is-a-bug-in-csagent-sys-c3904570f78a

Ты склонен бегать аки ужик на сковородке тут — по ссылке тоже исходят из того, что ошибка была "логическая".

И тоже правильно поняли происходящее — сначала нашли как проблему обойти, а только потом (и неизвестно когда) будут решать как проблему решить.
И да, этому идиотизму посвящена чуть ли не половина твоей ссылки, что говорит о твоей недалёкости, коль даёшь НАСТОЛЬКО низкопробные ссылки — ведь автор не может знать всех подробностей архитектуры решения, как и подробностей происходящего, т.е. вольно или невольно скатывается в банальную желтушность, в распускание слухов, бгг...

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

===========
Вопрос не так прост, как кажется на первый взгляд, бо не позволяет отделять разработчиков друг от друга, ведь даже если в "уютную" область входит достаточно опытный разработчик, навроде тебя, он с некоторой ощутимой вероятностью расслабляет булки на твой же манер, среда-то "безопасная!"
"Выкинет исключение, а не молча отформатирует диск!" (С)

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

ИМХО, в IT надо тупо возвращаться к истокам, к накопленному ранее опыту и определённому менталитету инженера-программиста, независимо от языков и сред.

Фричество не работает, за это уже не первый раз больно прилетает бумеранг.

Здравствуйте, Sinclair, Вы писали:

V>>Т.е. это "ваши" подосрали, а не "наши".
S>Вы сейчас к кому примазываетесь-то? Кого вы "нашими" называете?

Это на кого ты пытаешься свалить ошибки "вашей" безответственной братии.


V>>Суть проблемы — подписанный и абсолютно исправный драйвер оказался способен исполнять внешний подгружаемый p-код.
V>>Всё-таки, доигрались в "легко обновляемые байт-коды", дебилы, Б.
S>В который раз поражаюсь вашей способности читать всё наоборот.
S>1. "Способность исполнять внешний подгружаемый p-код" является не багом, а фичей драйвера

Т.е. багом архитектуры, опять бгг.

Мне уже примерно понятны зигзаги карьеры их технического руководства.
Т.е., вот тебе пошло уже вредительство от игрушечных технологий "генного" плана — это когда разрабы с геномом фриков-лалашек растут по карьёрной лестнице и тянут свои шаловливые ручки к рычагам принятия решений.

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

В реальной работе я бы тебе гвоздя ржавого не доверил, я ж помню твои эксперименты по генерации кода на C# — степень самокритичности примерно нулевая, зато степень очковтирательства и изворотливости — примерно максимально возможная. И это когда уже совсем разжевали и в рот положили сценарии, где код даёт ошибку. Только почему-то посторонний vdimas видит эти косяки сходу, за единицы/десятки секунд, а потративший кучу времени на тему автор с трудом "догоняет" даже спустя несколько раундов объяснений, бгг...

А сдаётся мне, что автор тупо врёт — да не может же он быть НАСТОЛЬКО тупым.
Автор просто врёт себе, врёт окружающим.

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


S>2. Выполнение NRE при исполнении внешнего подгружаемого кода является не фичей, а багом драйвера.

Чего? ))

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

Похоже, в более высокостоящей архитектуре всей этой приблуды не прописали сценарий — как реагировать на проваливающиеся аж на уровень VM тупые NRE байт-кода, бгг...
Такие вещи разрабатываются на архитектурном уровне и выдаются в кач-ве ТЗ техническими лидерами проекта.

Кароч, это не баг в C++, по крайней мере, никакой ошибки в C/C++ в произошедшем нет, бо на этом уровне отработали штатные ср-ва, которые помогли сразу же локализовать проблему.

Да, я понимаю твои рассуждения: "в уютном коде, выполняющемся на уровне ядра, могут быть ошибки, и VM должен был обыграть их как-то более гладко!"
Напомню, что это код уровня ядра...
Что ошибки в нейтиве на этом уровне, когда могут быть локализованы, приводят к отключению подсистемы или к BSOD, если нормальное функционирование системы далее невозможно.
А когда ошибки на этом уровне не могут быть локализованы, то машина ведёт себя произвольно — дай бог где-то диагностика заметит какой-то бред и насильно перегрузит (полно и такого кода в мониторе ядра)

Вот и получается, что для более простого, более безопасного языка ты требуешь еще большей толерантности, хотя должно было быть, по-идее, ровно наоборот — ведь "сложнее ошибиться" (С) Синклер!

А на деле, пресловутый NRE ты мог получить даже просто закрыв Windows.Forms в неудачный момент — это ж привычные постоянно исправляемые сомны багов на уровне C#.

Я ведь тщательно слежу за дотнетом еще с 2002-го и сам кучу раз репортил — да не бывает такой плотности багов в нейтивной разработке ни за что и никогда, оно бы ничего и никогда не работало с таким подходом. ))

А дотнетный Решарпер в Студии отваливается десятки раз за день до сих пор, бгг...
Хорошо хоть они догадались разбить его на модули меньшего размера, чтобы при краше модуля подгружать/инициализировать лишь его, а не весь монструозный плагин.

Но такой подход — это роспись в собственной убогости, разумеется.
За 20 лет не могли отловить баги, бгг.
Жесть, конечно...

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

Когда мне в руки на "поиграть" попадает нечто, что "долгие годы исправно работает" (произносится громко, причём сразу от нескольких опытных разрабов) — у меня оно всё начинает резко падать и захлёбываться собственными соплями. ))
Как раз специализируюсь на поиске ненадёжностей в т.ч. в архитектурном плане и в выработке решений по ним.


S>"абсолютно исправный" драйвер не вызвал бы NRE при исполнении произвольного байт-кода.

Ты действительно не понимаешь, или намеренно работаешь на публику?

Это вполне "законный" NRE уровня виртуальной машинки.
Ну как "законный".
Ужас-ужас, конечно, но разработчики на управляемых языках особо не парятся.


S>Склонен согласиться с автором https://medium.com/@vkoukis/the-root-cause-for-the-recent-crowdstrike-mess-is-not-a-content-update-it-is-a-bug-in-csagent-sys-c3904570f78a

Ты склонен бегать аки ужик на сковородке тут — по ссылке тоже исходят из того, что ошибка была "логическая".

И тоже правильно поняли происходящее — сначала нашли как проблему обойти, а только потом (и неизвестно когда) будут решать как проблему решить.
И да, этому идиотизму посвящена чуть ли не половина твоей ссылки, что говорит о твоей недалёкости, коль даёшь НАСТОЛЬКО низкопробные ссылки — ведь автор не может знать всех подробностей архитектуры решения, как и подробностей происходящего, т.е. вольно или невольно скатывается в банальную желтушность, в распускание слухов, бгг...

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

===========
Вопрос не так прост, как кажется на первый взгляд, бо не позволяет отделять разработчиков друг от друга, ведь даже если в "уютную" область входит достаточно опытный разработчик, навроде тебя, он с некоторой ощутимой вероятностью расслабляет булки на твой же манер, среда-то "безопасная!"
"Выкинет исключение, а не молча отформатирует диск!" (С)

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

ИМХО, в IT надо тупо возвращаться к истокам, к накопленному ранее опыту и определённому менталитету инженера-программиста, независимо от языков и сред.

Фричество не работает, за это уже не первый раз больно прилетает бумеранг.