Бессмысленно что то делать на уровне процессора, если память для ИИ будет снаружи.
Посмотрите на NVIDIA. У них данные для DLSS обсчитываются на суперкомпьютере, но апскейлинг в играх на основе этих предварительно просчитанных данных выполняется локально видеокартой пользователя.
Вопрос вообще ставить нужно иначе: какова поддержка уже существующих программных продуктов?
Уже в конце 2023 года компания отчитывалась о существовании более сотни различных сценариев, в которых для расчётов действительно задействуется Ryzen AI. В первую очередь речь идёт о различных операциях и фильтрах в Photoshop, Lightroom, Premiere Pro и DaVinci Resolve, но, очевидно, этот список будет пополняться.
Плюс локальный запуск ИИ-ассистента. Плюс в следующей версии Windows ИИ-функции при наличии сопроцессора смогут работать без доступа к интернету.
В статье речь о другом. Скорее всего, о том, что контроллер шифрует данные на SSD в любом случае. Даже если вы никакое шифрование не включали и "я простая домохозяйка, которой нечего скрывать". Просто ключ шифрования лежит не зашифрованным, а данные на диске зашифрованы им. Как сейф, рядом с которым прилеплена бумажка с паролем.
Когда вы включаете шифрование в ОС, если оно программное (LUKS или BitLocker с настройками по умолчанию), то ОС поверх этого аппаратного шифрования наворачивает свое. И уже ключ шифрования этого программного шифрования может быть защищен TPM или чем там ещё угодно.
Но если вы умудрились повредить микроконтроллер или стёрли тот самый незащищённый ключ аппаратного шифрования (например, подав команду Secure Erase), данные превращаются в кашу в любом случае. Независимо от того, зашифровано ли это все поверх программно или не зашифровано.
Об аппаратном и программном шифровании
В принципе, лучше всегда использовать именно программное. Поскольку аппаратное может быть реализовано с ошибками и уязвимостями, а проверить это вы не можете - исходников прошивки накопителя у вас нет. Исправить тоже не можете, если вендор не исправил баг и не выпустил обновление прошивки. А вот дыру в коде LUKS найти и исправить всяко проще. Плюсы аппаратного шифрования: оно чуть быстрее (но современные процессоры умеют ускорять AES, так что выигрыш мизерный) и оно для ОС выглядит прозрачно, словно его и нет - в накопитель загоняется специальный загрузчик, который расшифровывает накопитель и уже на него ставится ОС. В дальнейшем при включении компьютера сначала отрабатывает этот загрузчик, расшифровывает накопитель, перезагружает компьютер и накопитель выглядит как незашифрованный, соответственно грузится загрузчик операционной системы, которая не подозревает, что она на зашифрованном диске. Соответственно можно это прикрутить даже к какой-нибудь доисторической операционке, которая сама ничего шифровать не умеет.
Есть ещё гибридный вариант: BitLocker с включенной политикой "использовать аппаратное шифрование", когда для шифрования задействуется аппаратные возможности накопителя, но загрузчик не загоняется в накопитель, а в его роли выступает BitLocker. Соответственно, появляется интеграция всего этого дела с групповыми политиками, AD и так далее. Но этот вариант наследует все минусы как от аппаратного шифрования (качество кода прошивки), так и программного (для ОС не прозрачен).
4) публикуется список изменений, официальный анонс, релиз начинает раздаваться через автообновление
Пока не выполнен шаг 4, релиз не состоялся.
Распространение сборок Firefox по зеркалам начинается за несколько дней до официального объявления релиза. До официального анонса данные сборки позиционируется как тестовые кандидаты в релизы, которые не рекомендованы для установки обычными пользователями.
Примечательно, что несмотря на просьбы Mozilla не объявлять о новых выпусках до официального анонса, многие сайты, не следующие данным рекомендациям, уже успели объявить о релизе Firefox 125.
Так что, пока нет официального анонса (а его не было), то, что там лежит в /releases/, релизом не считается. Хотя, в 99% случаев последний релиз-кандидат и идентичен релизу, как видим, бывают исключения. Те, кто установил релиз-кандидат на macOS, получили в это раз сломанное автообновление.
Или уйдёт. Или будет ещё 8 лет сидеть на прошлом LTS-выпуске. А там, глядишь, или ишак сдохнет (отпадёт у человека необходимость в PPTP), или падишах (найдётся желающий поддерживать кодовую базу pptpd и пакет вернут в Ubuntu).
У нас речь про браузер. Сотрудник RedHat, который занимается разработкой на стыке Firefox и Wayland, прямо говорит, что необходимой поддержки со стороны Wayland пока нет, поэтому HDR и Firefox вещи несовместимые.
Есть, но автоматической расшифровки не будет, понадобится ввести резервный ключ восстановления.
В корпоративной среде этот ключ обычно улетает автоматом в AD при включении шифрования. Откуда его получит сисадмин, который и будет заниматься починкой ПК в случае проблем. Рядовой сотрудник, у которого помер ПК, починкой сдохшей системы не занимается.
Но всё ещё не очень понятно как и зачем телеграмм вообще открывает подобные файлы, ещё и блэк лист расширений, какой-то бред
Если файл является медиафайлом, то телеграм автоматически пытается сделать его превьюшку или даже начать его воспроизводить (пример). При этом, похоже, используются системные возможности (возможно, если клиент не может сделать превьюшку сам?).
Скрипт на Python определяется клиентом как медиафайл из-за первой строчки. Дальше расширение файла проверяется по захардкоженному списку исполняемых файлов ("тихое" открытие которых по умолчанию запрещено и попытка открыть файл (даже руками по двойному клику) выдаёт окно "это исполняемый файл, открываем?") и файл передаётся в ОС на открытие.
Без обхода чёрного списка расширений исполняемых файлов этот эксплоит срабатывал бы ещё у меньшего числа пользователей - лишь у тех, кто ранее пытался открыть исполняемые файлы и поставил галочку "не спрашивать больше". Но, благодаря тому, что в чёрном списке была опечатка, удалось найти такое расширение, которое не воспринимается как исполняемый файл, являясь им.
Дальше всё складывается: скрипт на питоне воспринимается как медиафайл, клиент не может сделать превью и, поскольку не воспринимает файл как исполняемый, передаёт его на исполнение операционной системе без вопросов.
https://github.com/mkorthof/traflimit
Во многом потому, что разработчики браузеров оперативно стали загрублять тайминги, не позволяя JS-скриптам эксплуатировать эти уязвимости.
Посмотрите на NVIDIA. У них данные для DLSS обсчитываются на суперкомпьютере, но апскейлинг в играх на основе этих предварительно просчитанных данных выполняется локально видеокартой пользователя.
Плюс локальный запуск ИИ-ассистента. Плюс в следующей версии Windows ИИ-функции при наличии сопроцессора смогут работать без доступа к интернету.
От края до края
Подсветка моя мигает
И с ней удаются
Все хедшоты и киллы
Если накопитель уничтожен, то я не смогу предоставить доступ, даже если очень захочу.
А вот если он не уничтожен, у товарища майора появляется стимул на меня давить.
Бюджетный вариант: microSD-карточка в кардридере + средство её быстрого уничтожения.
В статье речь о другом. Скорее всего, о том, что контроллер шифрует данные на SSD в любом случае. Даже если вы никакое шифрование не включали и "я простая домохозяйка, которой нечего скрывать". Просто ключ шифрования лежит не зашифрованным, а данные на диске зашифрованы им. Как сейф, рядом с которым прилеплена бумажка с паролем.
Когда вы включаете шифрование в ОС, если оно программное (LUKS или BitLocker с настройками по умолчанию), то ОС поверх этого аппаратного шифрования наворачивает свое. И уже ключ шифрования этого программного шифрования может быть защищен TPM или чем там ещё угодно.
Но если вы умудрились повредить микроконтроллер или стёрли тот самый незащищённый ключ аппаратного шифрования (например, подав команду Secure Erase), данные превращаются в кашу в любом случае. Независимо от того, зашифровано ли это все поверх программно или не зашифровано.
Об аппаратном и программном шифровании
В принципе, лучше всегда использовать именно программное. Поскольку аппаратное может быть реализовано с ошибками и уязвимостями, а проверить это вы не можете - исходников прошивки накопителя у вас нет. Исправить тоже не можете, если вендор не исправил баг и не выпустил обновление прошивки. А вот дыру в коде LUKS найти и исправить всяко проще. Плюсы аппаратного шифрования: оно чуть быстрее (но современные процессоры умеют ускорять AES, так что выигрыш мизерный) и оно для ОС выглядит прозрачно, словно его и нет - в накопитель загоняется специальный загрузчик, который расшифровывает накопитель и уже на него ставится ОС. В дальнейшем при включении компьютера сначала отрабатывает этот загрузчик, расшифровывает накопитель, перезагружает компьютер и накопитель выглядит как незашифрованный, соответственно грузится загрузчик операционной системы, которая не подозревает, что она на зашифрованном диске. Соответственно можно это прикрутить даже к какой-нибудь доисторической операционке, которая сама ничего шифровать не умеет.
Есть ещё гибридный вариант: BitLocker с включенной политикой "использовать аппаратное шифрование", когда для шифрования задействуется аппаратные возможности накопителя, но загрузчик не загоняется в накопитель, а в его роли выступает BitLocker. Соответственно, появляется интеграция всего этого дела с групповыми политиками, AD и так далее. Но этот вариант наследует все минусы как от аппаратного шифрования (качество кода прошивки), так и программного (для ОС не прозрачен).
Он официально и не выходил. Процедура такая:
1) выходят релиз-кандидаты
2) на каком-то из них процесс останавливается
3) этот билд раскладывается в каталог с релизами
4) публикуется список изменений, официальный анонс, релиз начинает раздаваться через автообновление
Пока не выполнен шаг 4, релиз не состоялся.
Так что, пока нет официального анонса (а его не было), то, что там лежит в /releases/, релизом не считается. Хотя, в 99% случаев последний релиз-кандидат и идентичен релизу, как видим, бывают исключения. Те, кто установил релиз-кандидат на macOS, получили в это раз сломанное автообновление.
Microsoft глубоко плевать, что кто-то взял дотнет для Windows 98 и похачил его для работы в Windows 95.
Или уйдёт. Или будет ещё 8 лет сидеть на прошлом LTS-выпуске. А там, глядишь, или ишак сдохнет (отпадёт у человека необходимость в PPTP), или падишах (найдётся желающий поддерживать кодовую базу pptpd и пакет вернут в Ubuntu).
Если человеку зачем-то нужно то, чего в репах нет - соберет, ведь "линух славится своей универсальностью" и никто не запрещает делать
make install.А если очень нужно, то даже опакетит и, опционально, PPA поднимет.
Да какие рейтинги, если сами маркетплейсы на явную паль вешают пометку "оригинальный товар"...
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2041751
Вместо MPPE PPTP предлагается использовать L2TP и IPSec. Например, за поддержку L2TP отвечает пакет xl2tpd.
Лучше спросить у самого Мартина.
У нас речь про браузер. Сотрудник RedHat, который занимается разработкой на стыке Firefox и Wayland, прямо говорит, что необходимой поддержки со стороны Wayland пока нет, поэтому HDR и Firefox вещи несовместимые.
Есть, но автоматической расшифровки не будет, понадобится ввести резервный ключ восстановления.
В корпоративной среде этот ключ обычно улетает автоматом в AD при включении шифрования. Откуда его получит сисадмин, который и будет заниматься починкой ПК в случае проблем. Рядовой сотрудник, у которого помер ПК, починкой сдохшей системы не занимается.
HDR ещё менее важная фича, т.к. HDR-мониторы особого распространения не получили.
Я имею в виду настоящую поддержку HDR, а не "псевдо-HDR" для галочки, как во многих мониторах.
А, например, в Linux поддержка HDR вообще невозможна, т.к. отсутствует необходимая поддержка со стороны Wayland.
Что изменится, если заменить в вашем комменте кошку на апельсины?
"Алергик свою алергию не выбирал а вы без апельсинов прожили бы вполне и у вас есть масса других вариантов путешествия кроме самолёта. "
Если файл является медиафайлом, то телеграм автоматически пытается сделать его превьюшку или даже начать его воспроизводить (пример). При этом, похоже, используются системные возможности (возможно, если клиент не может сделать превьюшку сам?).
Скрипт на Python определяется клиентом как медиафайл из-за первой строчки. Дальше расширение файла проверяется по захардкоженному списку исполняемых файлов ("тихое" открытие которых по умолчанию запрещено и попытка открыть файл (даже руками по двойному клику) выдаёт окно "это исполняемый файл, открываем?") и файл передаётся в ОС на открытие.
Без обхода чёрного списка расширений исполняемых файлов этот эксплоит срабатывал бы ещё у меньшего числа пользователей - лишь у тех, кто ранее пытался открыть исполняемые файлы и поставил галочку "не спрашивать больше". Но, благодаря тому, что в чёрном списке была опечатка, удалось найти такое расширение, которое не воспринимается как исполняемый файл, являясь им.
Дальше всё складывается: скрипт на питоне воспринимается как медиафайл, клиент не может сделать превью и, поскольку не воспринимает файл как исполняемый, передаёт его на исполнение операционной системе без вопросов.