Что любопытно, "покрытие" в русском языке также имеет то же значение. До поездки товарищ считал, что он "прикрыт", а после поездки оказалось, что он "покрыт".
Видеокамера, распознавание образов и автоматический пулемет. Если подростки в капюшонах не успеют дойти до пересечения с ЖД, то не пострадают на нем.
UPD: а если серьезно, то наверное только штрафами это можно как-то пытаться побороть. Если не расчехлил все органы чувств перед переходом - получи штраф. Примерно как с ремнями безопасности.
Да, вы правы. У нас все хорошо, у нас суд таких ордеров не выдает. Потому что не надо: ФСБ имеет прямой доступ к данным всех соцсетей, им не надо ничего ни у кого требовать - они просто берут и смотрят.
Просто ребята думают о будущем. Сначала ЖД на Луне, потом удлинят до Земли, чтобы дешевле гелий-3 возить, а там и в сторону Марса можно веточку протянуть.
Я бы сказал "да, оплачивать, оно того стоит". Хотя недоработок в PyCharm дофига... Но JetBrains с российскими пользователями тоже больше не работает, так что это не вариант.
As with all attack-oriented research, there is a risk that our work developing VPN fingerprinting techniques will be adopted by real attackers. To minimize this risk, we are in the process of responsibly disclosing our findings to the VPN operators whose obfuscated servers we successfully identified in our evaluation. We believe that the security of the VPN ecosystem is best advanced by having these problems surfaced by responsible researchers. Our work will help accurately inform users about the VPN services they rely on, and we hope it will enable more robust countermeasures to be developed and deployed.
С этим TikTok они совсем озверели. Убийственный диалог про гражданство уже упоминался в статье; были еще не менее фантастичные диалоги (я видел про отслеживание зрачков и про использование WiFi), где таким же образом пытались найти "жареные" факты про TikTok - вернее, обрамить уже высказанные в СМИ страшилки хоть какой-то фактурой - с таким же разгромным результатом. Ничего не нашли, никаких доказательств сбора данных не нашли, но "highly likely" рули.
В какой-то мере от ASML зависят все. Хотя они и не единственный производитель литографического оборудования, и фабрики уже понастроенные работают. Но тут уж вопрос, насколько готовы ASML пойти на обострение, и насколько готовы США пойти на обострение.
Вот только захотят ли они ехать туда, где на патенты клали? Захотят ли туда ехать те специалисты, про которых в статье говорилось? И захотят ли с ними самими после этого работать - особенно, если США на саму ASML наложит санкции (сразу по поводу нарушения патентов и по поводу того, что ASML становится "пособником" Китая в современных технологиях, а США считает недопустимым, чтобы у Китая были современные технологии)?
Старые добрые подмодули (submodule) git и компиляцию из исходников. Да, это трудоёмко, но в то же время:
Ужасно просто
Разработчики сразу во всём разбираются, даже не имея опыта работы с C++
Не ужасно просто, а просто ужасно. Кому-то надо cmake, кому-то надо autoconf, кому-то надо make с параметрами, кому-то надо perl (привет, openssl), кому-то надо 100500 3rd party зависимостей, которым самим тоже много чего надо (привет, ffmpeg). Да еще надо заставить их использовать наши версии библиотек, а не встроенные (лучи любви в zlib и openssl, которые используют чуть более, чем все, и которые так и норовят прилинковаться из системных данных).
Conan/vcpkg решают большую часть проблем за нас - умные люди уже понаступали на все гвозди.
Вы сами себе противоречите. Сначала говорите, что BSOD в драйвере случается только на старте системы, а через пару предложений - что падает, если нажать хитрую кнопочку в хитром приложении и виноваты в этом драйвера. Не срастаются как-то эти высказывания.
Если система падает на старте, то это что-то сломалось очень сильно, это какая-то хитрая и необычная комбинация чего-то установленного. Обычно же проблемы вылезают именно в процессе работы. В случае железа - например, разогретая видеокарта начала выдавать сбои в памяти. В случае драйвера - либо ошибка, вызываемая каким-нибудь редким рейсом, или, скажем, фрагментацией памяти, или какой-нибудь off-by-one, например, который раз в год попадает "точно в цель".
Только они, емнип, должны были выпускаться где-то на Тайване. Все бы хорошо, но Миландр попал под санкции и все пролетело. Поэтому я не уверен, что "серийная поставка с 2024 г" будет. А микроновский Амур, видимо, производится в России.
Так это презентация ядра SCR1 самого Syntacore. Конечно, они там заявили IPIC, и поставляют IPIC. А Микрон этот IPIC решили не использовать, а вместо него прикрутили какое-то другое (самопальное?) решение.
Как младший представитель линейки пойдет. Будем надеяться, что дальше будет и что-то большее для тех, кому надо - типа 64 кБ RAM, 64 кБ EEPROM, USB, CAN, Ethernet, SRAM/EXTMEM кому 64 кб не хватает... И что-то более вменяемое в прерываниях, а то 8 (восемь!!!) каналов прерывания назначено на 8 катастрофических события PCC (выход за границы по напряжению/частоте/температуре), зато все 8 каналов прерываний от GPIO заведены на единственное прерывание.
В этой функции все прекрасно... примерно такие шедевры получаются, если писать код, не приходя в сознание (как оно и рассказано в статье):
(b << 2) | (c & 0xC0) >> 2 -- явная ошибка со сдвигом >>2, должно быть >>6, иначе биты друг на друга накладываются.
А если это исправить, то получается, что a b c суть части 24-битного значения, которое делится на 18-битную целую и 6-битную дробную часть (в обеих ветках кода, ибо / 64.0 суть intPart + fracPart/64.0
Под вопросом деление fracPart/63.0 в _isFracture части. Может и так быть, конечно, ибо мы не знаем спецификацию входных данных, но я не вижу смысла в таком представлении данных (получается, что целые значения в таком варианте представлены двумя различными вариантами с 0 и 63 в fracPart, и это еще и приводит к уменьшению разрешения представимых данных)
Чую, что что-то не так и с negativeSign. Опять же, без спецификации не понятно, но сочетание ~ и - меня сильно смущает (с учетом того, что такое binary complement), и отдельные танцы с бубнами с fracPart. Я бы в такой функции обязательно оставил комментарий о том, как именно выглядят исходные данные, чтобы можно было разобраться потом.
EDIT: заморочился нашел документацию на FreeD. Видимо, это парсинг вот этого:
"The value is expressed in millimetres as a 24-bit twos-complement signed number, where the most-significant bit (bit 23) is the sign bit, the next 17 bits (bits 22 to 6) are the integer part and the remaining bits (bits 5 to 0) are the fractional part; alternatively, this may be thought of as a signed integer value in units of 1/64 mm. The range of values is from -131,072.0 mm (800000 hex) to nearly +131,072.0 mm (7FFFFF hex)"
То есть авто заморочился и написал оба подхода к решению одной и той же задачи и обе ветки кода должны всегда возвращать одинаковый результат. По факту - в ветке с fracPart - баг с делением на 63 (привносится небольшая ошибка на практически всех значениях) и случайно правильный результат на отрицательных значениях (из серии "ответ правильный, а решение нет"), а в "целочисленной" ветке - ошибка на 1/64 мм на всей отрицательной половине входных значений, включая даже и 0x800000 из документации.
Автомобиль - источник повышенной опасности. Оставим за скобкой злоумышленников - они при желании все равно угонят тачку, пусть она и заперта. А вот пьяная шпана, просто проходящая мимо, может воспринять открытую машину как приглашение покататься - и покататься с "кегельбаном" как результат.
Проведите параллель не в сторону полуголых девиц, а в сторону забытого в кафешке огнестрельного оружия. Логика та же.
Именно про танки (WoT) я не в курсе, я больше warthunder предпочитаю; там скорее сама компания угробит свою игру, чем читы (меня вымораживает регулярно случающийся дикий дизбаланс команд, когда буквально за полминуты, с первого соприкосновения, полкоманды сливается в нули и все, проигрыш обеспечен). Одиночный читер в таких играх имхо меньше проблем может натворить, чем в шутерах.
Но про то, что заморачиваться не будут - не верю. Ребята из Escape from Tarkov в своем античите блокировали Hyper-V, потому что были читы, которые в отдельной виртуалке что-то там химичили с сетевым обменом между игрой и сервером - так любители заводили отдельный компьютер для MitM! Если будет спрос на читы - найдутся замороты, которые обучат сетку на предмет помощи игроку, и найдутся умники, которые это все обернут в красивую конфетку, которую одним кликом можно запустить и наслаждаться.
Что любопытно, "покрытие" в русском языке также имеет то же значение. До поездки товарищ считал, что он "прикрыт", а после поездки оказалось, что он "покрыт".
Видеокамера, распознавание образов и автоматический пулемет. Если подростки в капюшонах не успеют дойти до пересечения с ЖД, то не пострадают на нем.
UPD: а если серьезно, то наверное только штрафами это можно как-то пытаться побороть. Если не расчехлил все органы чувств перед переходом - получи штраф. Примерно как с ремнями безопасности.
Да, вы правы. У нас все хорошо, у нас суд таких ордеров не выдает. Потому что не надо: ФСБ имеет прямой доступ к данным всех соцсетей, им не надо ничего ни у кого требовать - они просто берут и смотрят.
Просто ребята думают о будущем. Сначала ЖД на Луне, потом удлинят до Земли, чтобы дешевле гелий-3 возить, а там и в сторону Марса можно веточку протянуть.
Я бы сказал "да, оплачивать, оно того стоит". Хотя недоработок в PyCharm дофига... Но JetBrains с российскими пользователями тоже больше не работает, так что это не вариант.
As with all attack-oriented research, there is a risk that our work developing VPN fingerprinting techniques will be adopted by real attackers. To minimize this risk, we are in the process of responsibly disclosing our findings to the VPN operators whose obfuscated servers we successfully identified in our evaluation. We believe that the security of the VPN ecosystem is best advanced by having these problems surfaced by responsible researchers. Our work will help accurately inform users about the VPN services they rely on, and we hope it will enable more robust countermeasures to be developed and deployed.
С этим TikTok они совсем озверели. Убийственный диалог про гражданство уже упоминался в статье; были еще не менее фантастичные диалоги (я видел про отслеживание зрачков и про использование WiFi), где таким же образом пытались найти "жареные" факты про TikTok - вернее, обрамить уже высказанные в СМИ страшилки хоть какой-то фактурой - с таким же разгромным результатом. Ничего не нашли, никаких доказательств сбора данных не нашли, но "highly likely" рули.
В какой-то мере от ASML зависят все. Хотя они и не единственный производитель литографического оборудования, и фабрики уже понастроенные работают. Но тут уж вопрос, насколько готовы ASML пойти на обострение, и насколько готовы США пойти на обострение.
Вот только захотят ли они ехать туда, где на патенты клали? Захотят ли туда ехать те специалисты, про которых в статье говорилось? И захотят ли с ними самими после этого работать - особенно, если США на саму ASML наложит санкции (сразу по поводу нарушения патентов и по поводу того, что ASML становится "пособником" Китая в современных технологиях, а США считает недопустимым, чтобы у Китая были современные технологии)?
Да, именно про это. Решили в конце концов включить. В Ubuntu 24.04 пакеты (большинство) будут идти без этой опции.
https://www.phoronix.com/news/Ubuntu-Frame-Pointers-Default https://www.phoronix.com/news/F38-fno-omit-frame-pointer
Не ужасно просто, а просто ужасно. Кому-то надо cmake, кому-то надо autoconf, кому-то надо make с параметрами, кому-то надо perl (привет, openssl), кому-то надо 100500 3rd party зависимостей, которым самим тоже много чего надо (привет, ffmpeg). Да еще надо заставить их использовать наши версии библиотек, а не встроенные (лучи любви в zlib и openssl, которые используют чуть более, чем все, и которые так и норовят прилинковаться из системных данных).
Conan/vcpkg решают большую часть проблем за нас - умные люди уже понаступали на все гвозди.
Вы сами себе противоречите. Сначала говорите, что BSOD в драйвере случается только на старте системы, а через пару предложений - что падает, если нажать хитрую кнопочку в хитром приложении и виноваты в этом драйвера. Не срастаются как-то эти высказывания.
Если система падает на старте, то это что-то сломалось очень сильно, это какая-то хитрая и необычная комбинация чего-то установленного. Обычно же проблемы вылезают именно в процессе работы. В случае железа - например, разогретая видеокарта начала выдавать сбои в памяти. В случае драйвера - либо ошибка, вызываемая каким-нибудь редким рейсом, или, скажем, фрагментацией памяти, или какой-нибудь off-by-one, например, который раз в год попадает "точно в цель".
Только они, емнип, должны были выпускаться где-то на Тайване. Все бы хорошо, но Миландр попал под санкции и все пролетело. Поэтому я не уверен, что "серийная поставка с 2024 г" будет. А микроновский Амур, видимо, производится в России.
Так это презентация ядра SCR1 самого Syntacore. Конечно, они там заявили IPIC, и поставляют IPIC. А Микрон этот IPIC решили не использовать, а вместо него прикрутили какое-то другое (самопальное?) решение.
Как младший представитель линейки пойдет. Будем надеяться, что дальше будет и что-то большее для тех, кому надо - типа 64 кБ RAM, 64 кБ EEPROM, USB, CAN, Ethernet, SRAM/EXTMEM кому 64 кб не хватает... И что-то более вменяемое в прерываниях, а то 8 (восемь!!!) каналов прерывания назначено на 8 катастрофических события PCC (выход за границы по напряжению/частоте/температуре), зато все 8 каналов прерываний от GPIO заведены на единственное прерывание.
Просто не убрались в 16 линий встроенного синтакоровского IPIC, поэтому вместо него поставили какой-то EPIC на 32 линии.
В этой функции все прекрасно... примерно такие шедевры получаются, если писать код, не приходя в сознание (как оно и рассказано в статье):
(b << 2) | (c & 0xC0) >> 2 -- явная ошибка со сдвигом >>2, должно быть >>6, иначе биты друг на друга накладываются.
А если это исправить, то получается, что a b c суть части 24-битного значения, которое делится на 18-битную целую и 6-битную дробную часть (в обеих ветках кода, ибо / 64.0 суть intPart + fracPart/64.0
Под вопросом деление fracPart/63.0 в _isFracture части. Может и так быть, конечно, ибо мы не знаем спецификацию входных данных, но я не вижу смысла в таком представлении данных (получается, что целые значения в таком варианте представлены двумя различными вариантами с 0 и 63 в fracPart, и это еще и приводит к уменьшению разрешения представимых данных)
Чую, что что-то не так и с negativeSign. Опять же, без спецификации не понятно, но сочетание ~ и - меня сильно смущает (с учетом того, что такое binary complement), и отдельные танцы с бубнами с fracPart. Я бы в такой функции обязательно оставил комментарий о том, как именно выглядят исходные данные, чтобы можно было разобраться потом.
EDIT: заморочился нашел документацию на FreeD. Видимо, это парсинг вот этого:
"The value is expressed in millimetres as a 24-bit twos-complement signed number, where the most-significant bit (bit 23) is the sign bit, the next 17 bits (bits 22 to 6) are the integer part and the remaining bits (bits 5 to 0) are the fractional part; alternatively, this may be thought of as a signed integer value in units of 1/64 mm. The range of values is from -131,072.0 mm (800000 hex) to nearly +131,072.0 mm (7FFFFF hex)"
То есть авто заморочился и написал оба подхода к решению одной и той же задачи и обе ветки кода должны всегда возвращать одинаковый результат. По факту - в ветке с fracPart - баг с делением на 63 (привносится небольшая ошибка на практически всех значениях) и случайно правильный результат на отрицательных значениях (из серии "ответ правильный, а решение нет"), а в "целочисленной" ветке - ошибка на 1/64 мм на всей отрицательной половине входных значений, включая даже и 0x800000 из документации.
Автомобиль - источник повышенной опасности. Оставим за скобкой злоумышленников - они при желании все равно угонят тачку, пусть она и заперта. А вот пьяная шпана, просто проходящая мимо, может воспринять открытую машину как приглашение покататься - и покататься с "кегельбаном" как результат.
Проведите параллель не в сторону полуголых девиц, а в сторону забытого в кафешке огнестрельного оружия. Логика та же.
Я подозреваю, что даже несильный обдув газом рабочей области приведет к красивому разлетанию металлической пыли из этой области во все стороны.
Именно про танки (WoT) я не в курсе, я больше warthunder предпочитаю; там скорее сама компания угробит свою игру, чем читы (меня вымораживает регулярно случающийся дикий дизбаланс команд, когда буквально за полминуты, с первого соприкосновения, полкоманды сливается в нули и все, проигрыш обеспечен). Одиночный читер в таких играх имхо меньше проблем может натворить, чем в шутерах.
Но про то, что заморачиваться не будут - не верю. Ребята из Escape from Tarkov в своем античите блокировали Hyper-V, потому что были читы, которые в отдельной виртуалке что-то там химичили с сетевым обменом между игрой и сервером - так любители заводили отдельный компьютер для MitM! Если будет спрос на читы - найдутся замороты, которые обучат сетку на предмет помощи игроку, и найдутся умники, которые это все обернут в красивую конфетку, которую одним кликом можно запустить и наслаждаться.