Собственно, все большие игроки это уже сделали: Google давным-давно разрабатывает; Amazon (используется Anthropic); Microsoft вроде что-то делает; Meta заанонсили; OpenAI то ли дизайнит свои, то ли использует от гугла.
Подвох в том, что производство чипов по последним техпроцессам — дело дорогое, долгое и хорошо работает только в большом масштабе. А кроме чипов ещё нужны компиляторы/оптимизаторы под них и много разной обвязки. У отдельно взятых AI-стартапов нету сотни дата-центров и многих лет на создание уникальной инфры, поэтому подобным скорее занимаются именно облачные провайдеры, которые в подобном собаку съели.
Стоимость обучения определяется не себестоимостью, а балансом спроса и предложения. Аудитории могут вместить лишь столько студентов, а преподаватели — проводить лишь столько семинаров. Отсюда, повышается и стоимость, чтобы уменьшить число студентов до приемлемого. А учитывая, что есть кредит с господдержкой — спрос растет ещё выше.
Собственно, то же самое с баллами ЕГЭ — есть условные 100 бюджетных мест, из которых условные 99 заняты олимпиадниками без учёта ЕГЭ. И вот единственный студент с наибольшим баллом определяет проходной на бюджет.
Почему провайдеров-то? Провайдеры здесь сами заложники и ничего сделать не могут. Это все государственная структура (РКН).
CF, даже при всех своих умениях работы с трафиком, не может достоверно отличить самодеятельность провайдера от самодеятельности кого-то ещё.
Собственно, их заявление содержит только те факты, для которых у них есть понятные доказательства:
что-то происходит на уровне провайдеров, между пользователем и ближайшей точкой Cloudflare
это что-то одновременно происходит для всех пользователей, вне зависимости от провайдера
Доказательств вины РКН они получить не могут и не делают никаких неверифицируемых заявлений. Что, пожалуй, правильно.
Сделать ничего не могут или не хотят ссориться с российскими властями?
Скорее не могут — SNI формируется клиентом, а значит это он должен что-то делать, чтобы мимикрировать под незамедляемый трафик. Да и инъецированные пакеты приходят именно на сторону клиента.
Cloudflare тут может только, пользуясь своим масштабом, продавить в мир более защищенный сетевой стек, в который нельзя будет инъецировать пакеты сбоку и подсмотреть доменное имя. Но он это уже довольно успешно делает (ECH, QUIC) и это блокируется ещё проще. А всякие скрытые туннели типа VLESS примерно никогда не окажутся отлиты в граните стандартов и реализованы в браузерах.
Может, попробуют побороться за российский трафик
Собсно, тут Cloudflare делает всё что реально может — предоставляет обширнейшую статистику о наблюдаемом явлении благодаря внедрению и распространению NEL. Ещё мог бы со своей экспертизой и данными попробовать в суд подать на кого-нибудь, но, увы, Cloudflare не имеет никакого представителя в РФ.
btw, у Cloudflare уже давно есть такой бесплатный сервис как Cloudflare WARP: https://1.1.1.1 — утверждается, что он делает интернет быстрее и безопаснее.
Зато в облаке данные хранятся геораспределенно с достаточной репликацией, диски регулярно заменяются, а дата-центры защищены от ограблений, пожаров и потопов. Ну просто потому что в большом облаке иначе не делается.
Так что я бы сказал, что множества рисков для дома и для облака практически никак не пересекаются. А сравнивать их — дело холиварное.
Мне кажется, тут есть большое отличие в подходах к языку. Если брать Си и Го, то в их дизайне очень большое влияние имеет простота и минимализм, а любой сахар и новые фичи воспринимаются если не в штыки, то с большим сомнением.
Если же брать раст или, скажем, плюсы, то это сложные языки, которые спокойно позволяют себе иметь больше десяти страниц документации. И соответственно они обычно не отбрасывают решения для реально болящих у людей проблем с мотивацией «не надо этого нам тащить никогда». Что, впрочем, не отменяет возможности для RFC застрять в состоянии «идея хорошая, но непонятно как это красиво впихнуть, запланировали подумать лет через пять».
Как пример — в го несколько разных хороших и проработанных вариантов обработки ошибок оказались отброшены в основном потому что в комьюнити не нашли всеобщей поддержки. А вот в том же расте есть let-else statement, в обсуждении которого под 200 комментариев и который полностью совпадает по функционалу с имеющейся конструкцией match или if, но имеет более упоротый узкоспециализированный синтаксис. И ничего, пободались, приняли, довели до stable.
А почему на графике написано «Autonomously mitigated by Cloudflare», а в теле статьи «За его защиту отвечает сервис Google Project Shield»?
Таки кто отбил эту атаку?
Если читать оригинал, то всё становится понятно (выделение моё):
Since the Mirai attack, KrebsOnSecurity.com has been behind the protection of Project Shield, a free DDoS defense service that Google provides to websites offering news, human rights, and election-related content. Google Security Engineer Damian Menscher told KrebsOnSecurity the May 12 attack was the largest Google has ever handled. In terms of sheer size, it is second only to a very similar attack that Cloudflare mitigated and wrote about in April.
А под картинкой, в свою очередь, есть подпись (выделение моё):
A graph depicting the 6.5 Tbps attack mitigated by Cloudflare in April 2025. Image: Cloudflare.
Итого: атака в мае на KrebsOnSecurity была отбита гуглом, но там нет красивых графиков, поэтому в качестве КДПВ использован другой DDOS (апрельский), отбитый Cloudflare.
Обе атаки очень похожи (~45 секунд UDP флуда) и утверждается, что это один и тот же ботнет тестирует свои возможности.
Нейросети дают точный ответ, если этот ответ существует, достаточно понятно выводится из вводных, и был в обучающей выборке. Если принять эти ограничения, то инструмент ведёт себя весьма хорошо. В конце-концов, люди же используют C++, который тоже имеет undefined behavior при неправильном использовании.
Так, в случае с поиском информации, довольно безопасно искать то, что определенно существует в мире, но вы не помните точных подробностей. И опасно искать факты, которых может не существовать.
Вот, например, мне нужно было добавить новый механизм авторизации в проекты на Node.js, Python, и Ruby. На всём этом я сам примерно никогда не писал, но точно знаю что решаю очень типовую задачу, которая уже миллион раз решалась в разных вариациях и хорошо представлена в обучающей выборке. Поэтому могу спокойно доверить задачу LLM.
С другой стороны, я также делаю рефакторинги и привожу один сервис в соответствие с новыми требованиями бизнеса. LLM не знакома с архитектурой сервиса (и неспособна быстро её «выучить», загрузив его весь в контекст) и практически не знакома с предметной областью требований (потому что её точно не было в обучающей выборке). Отсюда, если я попрошу LLM дописать наиболее вероятный код в наиболее вероятные места, то она сделает что-то, но это что-то вряд ли получится хорошим.
Правильно (не)применять LLM — тоже навык, и я бы сказал что он сложный. Пока что слишком много статей вида «вышла новая LLM ещё больше и теперь можно совсем не думать» и слишком мало «как научить LLM решать ваши задачи и верифицировать этот навык».
we only save a cryptographic hash of your email or phone number
Однако же возможных российских номеров телефона (+79...) всего лишь порядка 2^30 и если там не вычислительно тяжёлый хеш, то довольно несложно банально их все перебрать. Так что тут очень не хватает подробностей про саму хеш-функцию.
По крайней мере радует утверждение, что этот хеш не привязан к самому аккаунту.
ИМХО, мутабельность/иммутабельность ссылок в расте — вводящий в заблуждение концепт. Потому что возможность менять значение не всегда совпадает с уникальностью ссылки. На эту тему есть несколько постов на английском, но я их сейчас сходу не найду.
Например, часто встречается interiour mutability (доступный через примитв UnsafeCell), который позволяет менять объект, если есть какая-то гарантия, что никто больше его не меняет. Например, Mutex берет блокировку, а Cell запрещает передавать себя между потоками.
Поэтому осмысленнее иметь не мутабельные/иммутабельные ссылки, а уникальные/неуникальные. Тогда получается три самых распространенных способа передавать объекты (если не считать Pin'ы):
владение (`T`) — объект принадлежит тебе полностью и исключительно; никаких ссылок на него не существует и теперь это твоя ответственность освободить память.
Shared-ссылка (`&T`) — объект где-то есть, и твоя ссылка на него не уникальна; возможно его кто-то может читать из других потоков.
Unique-ссылка (`&mut T`) — объект где-то есть, но кроме тебя его никто не читает и это единственная активная ссылка на него. Часто это позволяет менять объект.
Тогда общая картина становится немного более логичной. Владение позволяет брать на объект ссылки (в рамках borrow checker'a) и делает тебя ответственным за освобождение ресурсов. А вот уже ссылки позволяют получать доступ к объекту. Так у нас владение и ссылки становятся ортогональными концептами с непересекающимися фичами.
Из факта владения объектом часто следует возможность взять &mut ссылку (или обычную), но не всегда borrow checker это разрешит. Например, если вы передали &Vec<T> в функцию и получили в ответ ссылку на один его элемент, то теперь вы не можете взять и добавить элемент в вектор, хотя им владеете и несёте ответственность освободить память. Ведь вдруг при вставке вектор переаллоцируется и указатель сломается. Borrow checker не даст создать уникальную ссылку на Vec, пока существует какая-то другая ссылка на него же. Таким образом, владение объектом не гарантирует возможность доступа к нему; чтобы взаимодействовать с данными нужно создавать соответствующие ссылки.
А мутабельность owned значений (`let mut x: T`) просто синтаксическая соль, которая на самом деле ни на что не влияет в большом смысле.
В Москве (где, примерно, и расположены дата-центры) одна солнечная панель будет вырабатывать около 1.15кВтч/сут на квадратный метр в солнечном мае. Для питания 63МВт потребуется где-то в 63 тысячи раз больше солнечный батарей и площади. Это уже очень дофига места и обслуживания, а если ещё брать зимние месяцы, то становится совсем невероятно.
Я пробовал смотреть 3D фильмы в VR и меня сразу же укачало от трясущейся камеры, так что вариант только для телеков.
В VR же можно вывести 3д-картинку на виртуальный же экран на удобном расстоянии. Получается ровно как если бы телевизор был на стене, только без телевизора и стены.
Я пробовал так смотреть в самолёте — всё довольно неплохо, если не считать, что Quest 3 с SSD тратит больше энергии, чем забирает из зарядки, а этот самый SSD обжигает ногу на которой лежит.
Проникновение Spectre в оперативную память через обучение предсказателя ветвлений (картинка)
Из диаграммы складывается такое впечатление, что в программу внедряется какой-то исполняемый код с шпионом, который и выполняется в пространстве этого процесса. Но Spectre всё-таки действует только в рамках своего процесса и никак не влияет на другие.
В целом, диаграмма ну очень непонятная. По идее, «Задача X» это и есть ваш процесс в котором вы манипулируете предсказателем ветвлений, но кто такой тогда красный Spectre справа?
Пробравшись, например, в серверы банков, Spectre может достать из оперативной памяти
Если вы банк и на ваших серверах исполняется произвольный бинарник, то кажется что-то пошло очень сильно не так и исправляется это совсем не борьбой со спекулятивными вычислениями.
Если же этот бинарник вы сами туда положили, то скорее стоит переработать методы защиты от Supply Chain-атак. Пожалуй, Spectre тут это не самая большая из ваших проблем.
Если же у вас всё хорошо с защитой цепочки поставок, но Spectre всё равно оказался в ваших бинарниках, то это может означать лишь то, что вы сами его реализовали и сами его собрали. Тогда действительно компиляция в режиме защищенных вычислений вам поможет, да.
Короче, в случае dedicated серверов за физически охраняемой решеткой и тотальным код-ревью, Spectre практически никак не играет роли. Этот класс узязвимостей опасен в основном на shared-платформах, где выполняется множество разных процессов, и не всем из них можно доверять. Например, компьютер пользователя.
У процессоров Эльбрус уязвимости Spectre нет на аппаратном уровне, но она проявляется на уровне компилятора
Но ведь буквально в начале описывается, что это аппартаная уязвимость, да и на протяжении всего текста аналогично: «это глубинная аппаратная уязвимость». Что значит «проявляется на уровне компилятора»?
Без оптимизации компилятора уязвимость не проявляется, потому что компилятор не будет генерировать спекулятивное чтение из памяти.
Я бы скорее ожидал ровно противоположного — с включенными оптимизациями компилятор не станет генерировать код, который заведомо не исполняется. А без оптимизаций он сгенерирует ровно то что и было написано — включая любые чтения из памяти.
Проверяли ли вы, что без оптимизаций уязвимость проверяется на заведомо уязвимых процессорах? Подозреваю, что здесь неправильно поставлен эксперимент и с выключенными оптимизациями уязвимость вообще никогда не воспроизводится вашим кодом (например, из-за проблем с достоверным замером времени исполнения инструкций).
Наиболее важные особенности этого режима в том, что он контролирует обращения за границами объектов, использование неинициализированных переменных и создание новых указателей и конверсию указателей.
Это реализовано на уровне компилятора или на аппаратном уровне? Если первое, то можно ли переписать весь ваш эксплоит на ассемблер и обойти все проверки? Всё-таки вряд ли вы будете контроллировать компиляцию зловредного кода =)
Если второе, то почему вы переключаете флаги компилятора? Кажется для демонстрации влияния защиты нужно переключать только защиту, и ничего больше. Иначе эксперимент какой-то некорректный выходит.
И программные заплатки, увы, не панацея, потому что не только не дают полной защиты, но и снижают производительность системы.
Я всё-таки буду предполагать что ваш режим защищенных вычислений всё-таки работает на уровне компилятора. Тогда чем же он не «программная заплатка»?
Наиболее важные особенности этого режима в том, что он контролирует обращения за границами объектов, использование неинициализированных переменных и создание новых указателей и конверсию указателей.
…и разве всё это не снижает производительность системы?
можно закрыть только переходом на другую архитектуру процессоров и отказом от спекулятивных вычислений
Но как же тогда в процессорах Apple Silicon (который M1, M2, M3) всё-таки Spectre пропатчили? Там же старый-добрый ARM в качестве архитектуры и спекулятивные вычисления всё также присутствуют. Аналогично с новыми поколениями Intel, AMD.
Intel, AMD, ARM, Microsoft, Linux и даже Mac выпустили патчи, которые отчасти закрывают уязвимость Spectre.
Нетехнический наброс, но корректнее было бы вместо Mac написать Apple, всё-таки Mac это лишь линейка продуктов, как, скажем «Intel Core».
Сначала удивился, что в джаве есть целый кеш для простых чисел. Потом перешёл по ссылке и увидел, что это всего лишь кеш объектов Integer (которые boxed).
Как-будто, для этой задачи нужен очень специфичный рейд вида «записывать на быстрый диск два блока, пока на медленный пишется один», чтобы поддерживать среднюю скорость в три блока. Причём со временем соотношение скоростей будет меняться, так что придётся хранить кучу метаданных сверху.
Интересно, существуют ли уже подобные файловые системы .
Использую API, для моих целей (пару раз в неделю реализовать какой-то код по чёткому ТЗ) более чем хватает и выходит на порядок дешевле, чем платить 20$/mo (я трачу около 2$/mo). Почти никаких лимитов, а если подобрать хороший UI, то ещё и очень удобно (например, можно редактировать текст предыдущих вопросов/ответов). Лично я использую openrouter.ai.
Если у вас вдруг есть юзернеймы, то почти всегда почти точно будет какой-то функционал, который потребует по этим самым юзернеймам находить саму сущность пользователя в базе.
Если вас не атакуют, то почти всегда почти точно количество регистраций будет пренебрежимо мало по сравнению с числом легальных действий. Банально потому что пользователь регистрируется лишь однажды, а пользуется приложением часто.
Отсюда простой вывод — у вас уже должен быть general-purpose механизм поиска юзернейма в базе. Чертовски хорошо отлаженный, потому что от него зависит работа примерно всего. Который умеет как-то адекватно жить с ограничениями на количество подключений и решает множество других проблем. Возможно даже с кешированием.
Опять-таки, если вас не атакуют, то почти всегда почти точно юзернеймы будут только валидными. А поскольку регистрации составляют ничтожный объём от всей нагрузки — поддерживать только для них фильтр Блума будет накладно. Вы же помните, что всякий дополнительный индекс — ускоряет некоторые операции чтения, но замедляет все операции записи? Не считая того, что в данном случае он банально тратит ресурсы, увеличивает latency и раздувает общую сложность системы.
К слову о кешировании — почти точно ваш Redis не будет источником правды, а будет лишь кэшировать данные из чего-то более классического (и с более приятными гарантиями). И тут в полной мере встаёт вопрос «а как?». Если мы хотим не просто хранить список имён, то задача поддержания кэша в актуальном состоянии — чертовски нетривиальная с множеством разных компромиссов и тонкостей. Кажется немного опрометчивым советовать в статье для самых новичков добавить в систему кэширующий слой (особенно когда не все соки выжаты из БД).
Нет, это всё-таки проблема гугла. Их задача — принести конверсию рекламодателю, чтобы тот, в свою очередь, принес гуглу деньги. Сама по себе реклама ценности не несёт.
Но я почти уверен, что если бы на денежных метриках не сказывались меры по борьбе с адблоком, гугл бы не продолжал тратить на это свои ресурсы и репутацию.
В идеальном мире, гугл бы с радостью перестал показывать рекламу тем, кто ничего не покупает, если бы это не сказалось на конверсии в других группах (и справедливо стал бы брать больше денег за оставшиеся показы). Как, например, перестал показывать рекламу в России за неимением в этом регионе релевантных рекламных роликов, которые бы могли принести конверсию.
Собственно, все большие игроки это уже сделали: Google давным-давно разрабатывает; Amazon (используется Anthropic); Microsoft вроде что-то делает; Meta заанонсили; OpenAI то ли дизайнит свои, то ли использует от гугла.
Подвох в том, что производство чипов по последним техпроцессам — дело дорогое, долгое и хорошо работает только в большом масштабе. А кроме чипов ещё нужны компиляторы/оптимизаторы под них и много разной обвязки. У отдельно взятых AI-стартапов нету сотни дата-центров и многих лет на создание уникальной инфры, поэтому подобным скорее занимаются именно облачные провайдеры, которые в подобном собаку съели.
Стоимость обучения определяется не себестоимостью, а балансом спроса и предложения. Аудитории могут вместить лишь столько студентов, а преподаватели — проводить лишь столько семинаров. Отсюда, повышается и стоимость, чтобы уменьшить число студентов до приемлемого. А учитывая, что есть кредит с господдержкой — спрос растет ещё выше.
Собственно, то же самое с баллами ЕГЭ — есть условные 100 бюджетных мест, из которых условные 99 заняты олимпиадниками без учёта ЕГЭ. И вот единственный студент с наибольшим баллом определяет проходной на бюджет.
CF, даже при всех своих умениях работы с трафиком, не может достоверно отличить самодеятельность провайдера от самодеятельности кого-то ещё.
Собственно, их заявление содержит только те факты, для которых у них есть понятные доказательства:
что-то происходит на уровне провайдеров, между пользователем и ближайшей точкой Cloudflare
это что-то одновременно происходит для всех пользователей, вне зависимости от провайдера
Доказательств вины РКН они получить не могут и не делают никаких неверифицируемых заявлений. Что, пожалуй, правильно.
Скорее не могут — SNI формируется клиентом, а значит это он должен что-то делать, чтобы мимикрировать под незамедляемый трафик. Да и инъецированные пакеты приходят именно на сторону клиента.
Cloudflare тут может только, пользуясь своим масштабом, продавить в мир более защищенный сетевой стек, в который нельзя будет инъецировать пакеты сбоку и подсмотреть доменное имя. Но он это уже довольно успешно делает (ECH, QUIC) и это блокируется ещё проще. А всякие скрытые туннели типа VLESS примерно никогда не окажутся отлиты в граните стандартов и реализованы в браузерах.
Собсно, тут Cloudflare делает всё что реально может — предоставляет обширнейшую статистику о наблюдаемом явлении благодаря внедрению и распространению NEL. Ещё мог бы со своей экспертизой и данными попробовать в суд подать на кого-нибудь, но, увы, Cloudflare не имеет никакого представителя в РФ.
btw, у Cloudflare уже давно есть такой бесплатный сервис как Cloudflare WARP: https://1.1.1.1 — утверждается, что он делает интернет быстрее и безопаснее.
Зато в облаке данные хранятся геораспределенно с достаточной репликацией, диски регулярно заменяются, а дата-центры защищены от ограблений, пожаров и потопов. Ну просто потому что в большом облаке иначе не делается.
Так что я бы сказал, что множества рисков для дома и для облака практически никак не пересекаются. А сравнивать их — дело холиварное.
Мне кажется, тут есть большое отличие в подходах к языку. Если брать Си и Го, то в их дизайне очень большое влияние имеет простота и минимализм, а любой сахар и новые фичи воспринимаются если не в штыки, то с большим сомнением.
Если же брать раст или, скажем, плюсы, то это сложные языки, которые спокойно позволяют себе иметь больше десяти страниц документации. И соответственно они обычно не отбрасывают решения для реально болящих у людей проблем с мотивацией «не надо этого нам тащить никогда». Что, впрочем, не отменяет возможности для RFC застрять в состоянии «идея хорошая, но непонятно как это красиво впихнуть, запланировали подумать лет через пять».
Как пример — в го несколько разных хороших и проработанных вариантов обработки ошибок оказались отброшены в основном потому что в комьюнити не нашли всеобщей поддержки. А вот в том же расте есть let-else statement, в обсуждении которого под 200 комментариев и который полностью совпадает по функционалу с имеющейся конструкцией match или if, но имеет более
упоротыйузкоспециализированный синтаксис. И ничего, пободались, приняли, довели до stable.Так они последние лет так 20 выходят почти всегда через каждые два месяца: https://en.wikipedia.org/wiki/Linux_kernel_version_history
Ну разве что на новогодние праздники стабильно задерживаются.
Да это же система беспроводной передачи воды!
А почему на графике написано «Autonomously mitigated by Cloudflare», а в теле статьи «За его защиту отвечает сервис Google Project Shield»?
Таки кто отбил эту атаку?
Если читать оригинал, то всё становится понятно (выделение моё):
А под картинкой, в свою очередь, есть подпись (выделение моё):
Итого: атака в мае на KrebsOnSecurity была отбита гуглом, но там нет красивых графиков, поэтому в качестве КДПВ использован другой DDOS (апрельский), отбитый Cloudflare.
Обе атаки очень похожи (~45 секунд UDP флуда) и утверждается, что это один и тот же ботнет тестирует свои возможности.
Нейросети дают точный ответ, если этот ответ существует, достаточно понятно выводится из вводных, и был в обучающей выборке. Если принять эти ограничения, то инструмент ведёт себя весьма хорошо. В конце-концов, люди же используют C++, который тоже имеет undefined behavior при неправильном использовании.
Так, в случае с поиском информации, довольно безопасно искать то, что определенно существует в мире, но вы не помните точных подробностей. И опасно искать факты, которых может не существовать.
Вот, например, мне нужно было добавить новый механизм авторизации в проекты на Node.js, Python, и Ruby. На всём этом я сам примерно никогда не писал, но точно знаю что решаю очень типовую задачу, которая уже миллион раз решалась в разных вариациях и хорошо представлена в обучающей выборке. Поэтому могу спокойно доверить задачу LLM.
С другой стороны, я также делаю рефакторинги и привожу один сервис в соответствие с новыми требованиями бизнеса. LLM не знакома с архитектурой сервиса (и неспособна быстро её «выучить», загрузив его весь в контекст) и практически не знакома с предметной областью требований (потому что её точно не было в обучающей выборке). Отсюда, если я попрошу LLM дописать наиболее вероятный код в наиболее вероятные места, то она сделает что-то, но это что-то вряд ли получится хорошим.
Правильно (не)применять LLM — тоже навык, и я бы сказал что он сложный. Пока что слишком много статей вида «вышла новая LLM ещё больше и теперь можно совсем не думать» и слишком мало «как научить LLM решать ваши задачи и верифицировать этот навык».
Однако же возможных российских номеров телефона (+79...) всего лишь порядка 2^30 и если там не вычислительно тяжёлый хеш, то довольно несложно банально их все перебрать. Так что тут очень не хватает подробностей про саму хеш-функцию.
По крайней мере радует утверждение, что этот хеш не привязан к самому аккаунту.
ИМХО, мутабельность/иммутабельность ссылок в расте — вводящий в заблуждение концепт. Потому что возможность менять значение не всегда совпадает с уникальностью ссылки. На эту тему есть несколько постов на английском, но я их сейчас сходу не найду.
Например, часто встречается interiour mutability (доступный через примитв UnsafeCell), который позволяет менять объект, если есть какая-то гарантия, что никто больше его не меняет. Например, Mutex берет блокировку, а Cell запрещает передавать себя между потоками.
Поэтому осмысленнее иметь не мутабельные/иммутабельные ссылки, а уникальные/неуникальные. Тогда получается три самых распространенных способа передавать объекты (если не считать Pin'ы):
владение (`T`) — объект принадлежит тебе полностью и исключительно; никаких ссылок на него не существует и теперь это твоя ответственность освободить память.
Shared-ссылка (`&T`) — объект где-то есть, и твоя ссылка на него не уникальна; возможно его кто-то может читать из других потоков.
Unique-ссылка (`&mut T`) — объект где-то есть, но кроме тебя его никто не читает и это единственная активная ссылка на него. Часто это позволяет менять объект.
Тогда общая картина становится немного более логичной. Владение позволяет брать на объект ссылки (в рамках borrow checker'a) и делает тебя ответственным за освобождение ресурсов. А вот уже ссылки позволяют получать доступ к объекту. Так у нас владение и ссылки становятся ортогональными концептами с непересекающимися фичами.
Из факта владения объектом часто следует возможность взять &mut ссылку (или обычную), но не всегда borrow checker это разрешит. Например, если вы передали &Vec<T> в функцию и получили в ответ ссылку на один его элемент, то теперь вы не можете взять и добавить элемент в вектор, хотя им владеете и несёте ответственность освободить память. Ведь вдруг при вставке вектор переаллоцируется и указатель сломается. Borrow checker не даст создать уникальную ссылку на Vec, пока существует какая-то другая ссылка на него же. Таким образом, владение объектом не гарантирует возможность доступа к нему; чтобы взаимодействовать с данными нужно создавать соответствующие ссылки.
А мутабельность owned значений (`let mut x: T`) просто синтаксическая соль, которая на самом деле ни на что не влияет в большом смысле.
Планируете ли отнести фичу в апстрим?
В Москве (где, примерно, и расположены дата-центры) одна солнечная панель будет вырабатывать около 1.15кВтч/сут на квадратный метр в солнечном мае. Для питания 63МВт потребуется где-то в 63 тысячи раз больше солнечный батарей и площади. Это уже очень дофига места и обслуживания, а если ещё брать зимние месяцы, то становится совсем невероятно.
В VR же можно вывести 3д-картинку на виртуальный же экран на удобном расстоянии. Получается ровно как если бы телевизор был на стене, только без телевизора и стены.
Я пробовал так смотреть в самолёте — всё довольно неплохо, если не считать, что Quest 3 с SSD тратит больше энергии, чем забирает из зарядки, а этот самый SSD обжигает ногу на которой лежит.
Из диаграммы складывается такое впечатление, что в программу внедряется какой-то исполняемый код с шпионом, который и выполняется в пространстве этого процесса. Но Spectre всё-таки действует только в рамках своего процесса и никак не влияет на другие.
В целом, диаграмма ну очень непонятная. По идее, «Задача X» это и есть ваш процесс в котором вы манипулируете предсказателем ветвлений, но кто такой тогда красный Spectre справа?
Если вы банк и на ваших серверах исполняется произвольный бинарник, то кажется что-то пошло очень сильно не так и исправляется это совсем не борьбой со спекулятивными вычислениями.
Если же этот бинарник вы сами туда положили, то скорее стоит переработать методы защиты от Supply Chain-атак. Пожалуй, Spectre тут это не самая большая из ваших проблем.
Если же у вас всё хорошо с защитой цепочки поставок, но Spectre всё равно оказался в ваших бинарниках, то это может означать лишь то, что вы сами его реализовали и сами его собрали. Тогда действительно компиляция в режиме защищенных вычислений вам поможет, да.
Короче, в случае dedicated серверов за физически охраняемой решеткой и тотальным код-ревью, Spectre практически никак не играет роли. Этот класс узязвимостей опасен в основном на shared-платформах, где выполняется множество разных процессов, и не всем из них можно доверять. Например, компьютер пользователя.
Но ведь буквально в начале описывается, что это аппартаная уязвимость, да и на протяжении всего текста аналогично: «это глубинная аппаратная уязвимость». Что значит «проявляется на уровне компилятора»?
Я бы скорее ожидал ровно противоположного — с включенными оптимизациями компилятор не станет генерировать код, который заведомо не исполняется. А без оптимизаций он сгенерирует ровно то что и было написано — включая любые чтения из памяти.
Проверяли ли вы, что без оптимизаций уязвимость проверяется на заведомо уязвимых процессорах? Подозреваю, что здесь неправильно поставлен эксперимент и с выключенными оптимизациями уязвимость вообще никогда не воспроизводится вашим кодом (например, из-за проблем с достоверным замером времени исполнения инструкций).
Это реализовано на уровне компилятора или на аппаратном уровне? Если первое, то можно ли переписать весь ваш эксплоит на ассемблер и обойти все проверки? Всё-таки вряд ли вы будете контроллировать компиляцию зловредного кода =)
Если второе, то почему вы переключаете флаги компилятора? Кажется для демонстрации влияния защиты нужно переключать только защиту, и ничего больше. Иначе эксперимент какой-то некорректный выходит.
Я всё-таки буду предполагать что ваш режим защищенных вычислений всё-таки работает на уровне компилятора. Тогда чем же он не «программная заплатка»?
…и разве всё это не снижает производительность системы?
Но как же тогда в процессорах Apple Silicon (который M1, M2, M3) всё-таки Spectre пропатчили? Там же старый-добрый ARM в качестве архитектуры и спекулятивные вычисления всё также присутствуют. Аналогично с новыми поколениями Intel, AMD.
Нетехнический наброс, но корректнее было бы вместо Mac написать Apple, всё-таки Mac это лишь линейка продуктов, как, скажем «Intel Core».
Сначала удивился, что в джаве есть целый кеш для простых чисел. Потом перешёл по ссылке и увидел, что это всего лишь кеш объектов Integer (которые boxed).
Как-будто, для этой задачи нужен очень специфичный рейд вида «записывать на быстрый диск два блока, пока на медленный пишется один», чтобы поддерживать среднюю скорость в три блока. Причём со временем соотношение скоростей будет меняться, так что придётся хранить кучу метаданных сверху.
Интересно, существуют ли уже подобные файловые системы .
Использую API, для моих целей (пару раз в неделю реализовать какой-то код по чёткому ТЗ) более чем хватает и выходит на порядок дешевле, чем платить 20$/mo (я трачу около 2$/mo). Почти никаких лимитов, а если подобрать хороший UI, то ещё и очень удобно (например, можно редактировать текст предыдущих вопросов/ответов). Лично я использую openrouter.ai.
Если у вас вдруг есть юзернеймы, то почти всегда почти точно будет какой-то функционал, который потребует по этим самым юзернеймам находить саму сущность пользователя в базе.
Если вас не атакуют, то почти всегда почти точно количество регистраций будет пренебрежимо мало по сравнению с числом легальных действий. Банально потому что пользователь регистрируется лишь однажды, а пользуется приложением часто.
Отсюда простой вывод — у вас уже должен быть general-purpose механизм поиска юзернейма в базе. Чертовски хорошо отлаженный, потому что от него зависит работа примерно всего. Который умеет как-то адекватно жить с ограничениями на количество подключений и решает множество других проблем. Возможно даже с кешированием.
Опять-таки, если вас не атакуют, то почти всегда почти точно юзернеймы будут только валидными. А поскольку регистрации составляют ничтожный объём от всей нагрузки — поддерживать только для них фильтр Блума будет накладно. Вы же помните, что всякий дополнительный индекс — ускоряет некоторые операции чтения, но замедляет все операции записи? Не считая того, что в данном случае он банально тратит ресурсы, увеличивает latency и раздувает общую сложность системы.
К слову о кешировании — почти точно ваш Redis не будет источником правды, а будет лишь кэшировать данные из чего-то более классического (и с более приятными гарантиями). И тут в полной мере встаёт вопрос «а как?». Если мы хотим не просто хранить список имён, то задача поддержания кэша в актуальном состоянии — чертовски нетривиальная с множеством разных компромиссов и тонкостей. Кажется немного опрометчивым советовать в статье для самых новичков добавить в систему кэширующий слой (особенно когда не все соки выжаты из БД).
Нет, это всё-таки проблема гугла. Их задача — принести конверсию рекламодателю, чтобы тот, в свою очередь, принес гуглу деньги. Сама по себе реклама ценности не несёт.
Но я почти уверен, что если бы на денежных метриках не сказывались меры по борьбе с адблоком, гугл бы не продолжал тратить на это свои ресурсы и репутацию.
В идеальном мире, гугл бы с радостью перестал показывать рекламу тем, кто ничего не покупает, если бы это не сказалось на конверсии в других группах (и справедливо стал бы брать больше денег за оставшиеся показы). Как, например, перестал показывать рекламу в России за неимением в этом регионе релевантных рекламных роликов, которые бы могли принести конверсию.