А почему это проблема? Мне почему-то кажется, что если температура процессора довольно низкая, то все в пределах нормы и можно ничего не делать. А когда эффективность системы охлаждения от этого падает, то он нагреется до привычной температуры и ситуация не поменяется. Кажется, что баланс будет в итоге достигнут, если система охлаждения вообще способна отводить X ватт тепла при Y температуре внутри. Но причем тогда факт, что процессоры стали холоднее?
Здесь стоит заметить, что при использовании 256 в качестве модуля, в некоторых случаях можно выяснить один бит зашифрованного секрета, не обладая всеми необходимыми ключами. В этой реализации проблема усугубляется ещё и тем, что каждый байт секрета разделяется независимо и из каждого утекает один такой бит. В итоге при разделении стандартного 256битного ключа, достаточно осведомлённый злоумышленник может вычислить 32 его бита, что звучит как дочерта (и значительно сокращает перебор)
Как это работает
окей, пусть мы не знаем одну из долей секрета, но знаем все остальные . Составим СЛАУ на коэффициенты многочлена из уравнений и неизвестных (коэффициенты, плюс недостающая нам доля). Выразим отсюда все коэффициенты через эту неизвестную долю, получим какие-то выражения вида , где y — неизвестно. Фокус в том, что мы обладаем достаточной информацией, чтобы знать, что эта дробь имеет смысл, потому что коэффициент же существует. А значит, что делится на . Если бы действие происходило в поле, то это бы ничего не дало (там можно делить что угодно), но у нас-то кольцо вычетов по непростому модулю 256. Нехитрыми размышлениями можно сократить множество возможных в два раза, а отсюда сокращается и пространство значений самого секрета. Ура!
Был один никнейм, который мне интересен, но занят каким-то арабским каналом, давно уже неактивным. Ну что же, подумал я, и забил. А теперь смотрю на аукцион и вижу его, но вполне доступным (во второй волне). Более того, в телеге и правда этот юзернейм больше никуда не ведёт, но только и занять его самому тоже нельзя.
Но это же не замена стримингов. Найти и скачать файл занимает заметно больше привычных пяти секунд, а уж о автоматических рекомендациях остаётся только мечтать.
Очень странно на Хабре видеть новости, в которых пишут "Уязвимость в ПО, лежащем в основе ..." вместо простого и понятного "Уязвимость в Electron". Так и заголовок короче, и масштаб проблемы с виду побольше — идеально же для новостей, разве нет? Понятное дело, что обыватель может не знать кто этот ваш Electron и где он применяется, но не на Хабре же.
Конкретно в случае с линуксом это будет сложно. Обратную совместимость для юзерспейса сохраняют очень жёстко и там мажорная будет всегда 1 покуда Линус жив. Внутреннее же апи так или иначе ломается постоянно и если из-за него инкрементить мажорную, то она быстро потеряет свой смысл. Так или иначе, получаются какие-то большие нечего не значащие числа. Ну, версия патча из семвера остаётся, но она и так вроде есть.
Номера версий линукса мало что значат, да и мажорный номер уже не первый раз увеличивается потому что минорный стал слишком большим числом. Наверное, можно было бы нумеровать как браузеры где уже далеко за 100+, но и текущий вариант не хуже.
Значит ли это, что для условного питона можно написать реализацию компилятора, который будет выдавать программы, сравнимые с условным rustc по производительности? Чтобы обычный наивный код с kwargs и декораторами работал также, как и обычный наивный код с traits и generics. И ещё интересно во сколько раз этот гипотетический компилятор будет сложнее условного gcc или LLVM.
Хотя бы потому что форматирование это создание где-то в памяти строки, которую потом копировать в поток. С текущим подходом каждый объект просто может как-то себя положить в поток, не используя слишком много дополнительной памяти и времени.
Потому что на Rust часто показывается только финальный вариант + чуть-чуть борьбы с компилятором. На Гошных же примерах подробно объясняется поведение программы, как оно меняется в зависимости от разных деталей, где именно можно накосячить и как это исправлять. На расте сложно элегантно демонстрировать подобные проблемы, на самом деле.
ИМХО, статья скорее должна называться "какие ошибки ловит Rust, но не ловят другие языки".
Возможно я что-то пропустил, но судя по статье — единственное свидетельство участия NVidia это слова не самых законопослушных людей, о том, что их злая компания зашифровала. Честно говоря, это кажется не слишком достоверным источником информации.
Кодогенераторы есть, конечно. Но кажется, что освоить язык Rust лучше помогает изучение языка, а не правил написания грамматик. Да и автору другие руководства по парсингу в Rust показались слишком сложными.
А почему это проблема? Мне почему-то кажется, что если температура процессора довольно низкая, то все в пределах нормы и можно ничего не делать. А когда эффективность системы охлаждения от этого падает, то он нагреется до привычной температуры и ситуация не поменяется. Кажется, что баланс будет в итоге достигнут, если система охлаждения вообще способна отводить X ватт тепла при Y температуре внутри. Но причем тогда факт, что процессоры стали холоднее?
Ну если вы можете из воды и углерода собрать условный спирт и половину органики заодно...
Здесь стоит заметить, что при использовании 256 в качестве модуля, в некоторых случаях можно выяснить один бит зашифрованного секрета, не обладая всеми необходимыми ключами. В этой реализации проблема усугубляется ещё и тем, что каждый байт секрета разделяется независимо и из каждого утекает один такой бит. В итоге при разделении стандартного 256битного ключа, достаточно осведомлённый злоумышленник может вычислить 32 его бита, что звучит как дочерта (и значительно сокращает перебор)
Как это работает
окей, пусть мы не знаем одну из долей секрета, но знаем все остальные
. Составим СЛАУ на коэффициенты многочлена из 
уравнений и 
неизвестных (коэффициенты, плюс недостающая нам доля). Выразим отсюда все коэффициенты через эту неизвестную долю, получим какие-то выражения вида 
, где y — неизвестно. Фокус в том, что мы обладаем достаточной информацией, чтобы знать, что эта дробь имеет смысл, потому что коэффициент же существует. А значит, что 
делится на 
. Если бы действие происходило в поле, то это бы ничего не дало (там можно делить что угодно), но у нас-то кольцо вычетов по непростому модулю 256. Нехитрыми размышлениями можно сократить множество возможных 
в два раза, а отсюда сокращается и пространство значений самого секрета. Ура!
Я про возможность в чужих чатах выбрать профиль кнопкой слева от поля ввода сообщения.
К слову, больше нельзя без премиума писать в чатах от лица своих публичных каналов.
Был один никнейм, который мне интересен, но занят каким-то арабским каналом, давно уже неактивным. Ну что же, подумал я, и забил. А теперь смотрю на аукцион и вижу его, но вполне доступным (во второй волне). Более того, в телеге и правда этот юзернейм больше никуда не ведёт, но только и занять его самому тоже нельзя.
Интересно они высвобождают имена, конечно.
Но это же не замена стримингов. Найти и скачать файл занимает заметно больше привычных пяти секунд, а уж о автоматических рекомендациях остаётся только мечтать.
Если вдруг кому-то захотелось узнать что это такое, то есть более полезная новость: https://cloud.yandex.ru/blog/posts/2022/09/yandex-query-preview (хотя бы с ссылочками на документацию)
Очень странно на Хабре видеть новости, в которых пишут "Уязвимость в ПО, лежащем в основе ..." вместо простого и понятного "Уязвимость в Electron". Так и заголовок короче, и масштаб проблемы с виду побольше — идеально же для новостей, разве нет? Понятное дело, что обыватель может не знать кто этот ваш Electron и где он применяется, но не на Хабре же.
Аккаунт разработчика стоит что-то около $100 в год у Apple.
Конкретно в случае с линуксом это будет сложно. Обратную совместимость для юзерспейса сохраняют очень жёстко и там мажорная будет всегда 1 покуда Линус жив. Внутреннее же апи так или иначе ломается постоянно и если из-за него инкрементить мажорную, то она быстро потеряет свой смысл. Так или иначе, получаются какие-то большие нечего не значащие числа. Ну, версия патча из семвера остаётся, но она и так вроде есть.
Номера версий линукса мало что значат, да и мажорный номер уже не первый раз увеличивается потому что минорный стал слишком большим числом. Наверное, можно было бы нумеровать как браузеры где уже далеко за 100+, но и текущий вариант не хуже.
Значит ли это, что для условного питона можно написать реализацию компилятора, который будет выдавать программы, сравнимые с условным rustc по производительности? Чтобы обычный наивный код с kwargs и декораторами работал также, как и обычный наивный код с traits и generics. И ещё интересно во сколько раз этот гипотетический компилятор будет сложнее условного gcc или LLVM.
Так есть же конфигурация ноутбука с предустановленной Ubuntu.
Вообще, кажется, что по каким-то причинам им проще было завернуть всё в виртуалку, чем убирать из модельного ряда вариант с DOS.
Это при любом не вполне обратимом действии: смена видимости, смена владельца, архивация, удаление.
Хотя бы потому что форматирование это создание где-то в памяти строки, которую потом копировать в поток. С текущим подходом каждый объект просто может как-то себя положить в поток, не используя слишком много дополнительной памяти и времени.
Потому что на Rust часто показывается только финальный вариант + чуть-чуть борьбы с компилятором. На Гошных же примерах подробно объясняется поведение программы, как оно меняется в зависимости от разных деталей, где именно можно накосячить и как это исправлять. На расте сложно элегантно демонстрировать подобные проблемы, на самом деле.
ИМХО, статья скорее должна называться "какие ошибки ловит Rust, но не ловят другие языки".
Удивительно, но такая фича уже существует, причем не вчера появилась. Называется inlay hints.
Выглядит плюс-минус так:
IntelliJ
VS Code
Замечу, что в современном Linux PID использует 64 бита. 2^64 наносекунд это 584 года, причём создание процесса — относительно дорогая операция.
Возможно я что-то пропустил, но судя по статье — единственное свидетельство участия NVidia это слова не самых законопослушных людей, о том, что их злая компания зашифровала. Честно говоря, это кажется не слишком достоверным источником информации.
Кодогенераторы есть, конечно. Но кажется, что освоить язык Rust лучше помогает изучение языка, а не правил написания грамматик. Да и автору другие руководства по парсингу в Rust показались слишком сложными.