Новая libc может не заработать на новом ядре (потому что не хватает фич). Но старая libc заработает на новом ядре (потому что сисколлы из ядра не выпиливают).
Строго говоря, алгоритм довольно несложно доработать так, чтобы устаревшие элементы удалялись из куч в тот же момент, когда они вышли из окна. Но для этого потребуется заменить кучу на ваше любимое дерево поиска — тогда удаление станет возможно за O(log N) на каждый новый элемент, где N — размер окна. А реализация какого-нибудь КЧД это уже далековато от "несложно" =)
Однако же альтернативный вариант можно подглядеть здесь: https://stackoverflow.com/a/10696252 — там предлагается аналогичное решение, но с заменой кучи/дерева на список с пропусками, который обладает примерно теми же преимуществами и без необходимости реализовывать балансировку. Но в худшем случае он потребует O(N), что становится практически аналогично quicksort.
В целом, задача как ни крути сводится к поддержанию сортированного списка и быстрее чем O(log N) её решить в общем случае вряд ли выйдет. Учитывая что N (размер окна) довольно мало, то боюсь что любой выигрыш от сложных структур данных запросто будет нивелирован прямолинейностью quicksort.
Согласен, выразился слишком категорично. Какое-то апи есть, но со звездочкой. Из того что вживую втыкался:
Гугл фото (не диск!) закрыл доступ к всей библиотеке через API. Теперь можно видеть только то что было загружено тем же приложением, либо вручную выбирать до 2000 файлов и выдавать к ним доступ. В случае с Диском доступ не закрыли и API есть, но формально все те же самые механизмы уже реализованы и черт его знает что будет в будущем.
Яндекс.диск и его webdav, когда я его трогал, люто резал скорость до где-то 2МБ/с. Это неюзабельно, уж извините.
Про маил ру ничего не скажу, я акцию на 1ТБ пропустил =)
Собственно, примерно никакое файлооблако не даёт гарантий, что автоматизация с ним не сломается. А мне всё-таки хочется верить, что я свой бекап таки смогу просто взять и спокойно восстановить.
Для того чтобы шарить файлы — можно использовать примерно любой мессенджер, а при необходимости залить в примерно любой диск. Надежность при этом совершенно не важна, главное чтобы удобно было. Плюс у того же гугла/яндекса ещё и есть безлимит на фотографии (но со сжатием).
Если же для бекапов и сохранности — Backblaze B2 и AWS Deep Glacier. Первый умеренно дешёвый ($6/TB/mo), с хорошей репутацией и понятным ценообразованием. Второй при правильном использовании стоит сущие копейки (~$1/TB/mo), но восстановление обойдется долго и дорого и есть много подводных камней.
Типичный {гугл,яндекс,маил}.диск обычно имеют ужасные лимиты по скорости, полностью отсутствующее API и отсутствие каких-либо гарантий. Зато у них удобный интерфейс и возможность просто взять и поделиться. С ними я абсолютно уверен разве что в том, что в течении года по ссылке можно будет перейти и файлы через браузер скачать. Ну а большего мне и не надо.
Полноценные S3-подобные хранилища имеют немного более приятное ценообразование и вполне адекватные SLA (они хотя бы есть!). Но никаких красивых ссылок и удобства. Если мой домашний диск вдруг умрет, то почти точно я смогу восстановиться из Backblaze и никто меня в этот момент не забанит и скорость не ограничит. К восстановлению из Amazon, надеюсь, никогда не прибегну, но лишняя копия ещё никому не вредила.
Не надо два разных юзкейса смешивать и всё становится хорошо и приятно.
в конце области видимости или в момент последнего использования
Я всей душой люблю Rust. Но не могу не заметить, что определить «момент последнего использования» в большинстве языков с GC — приблизительно невозможно. Потому что файл может быть в структуре, структура оказалась на куче, а GC в one-shot утилите банально не запускается. И вот теперь close() буквально никогда не вызовется.
А заставлять программиста доказывать компилятору факты о поведении программы — занятие хоть и полезное, но уж больно трудоемкое.
Фактически, Вы можете предъявить только то, что в Go build target оформляется, как комментарий специального вида, и не имеет прямой поддержки в синтаксисе языка.
Если почитать статью по ссылке, то там подсвечивается более важная проблема кросс-компиляции — все условия выражены в терминах названия платформы, а не доступных фич этой платформы.
Во-первых, это не позволяет просто написать «если есть системный вызов pledge(), то используй его», а вместо этого надо перечислить все совместимые платформы вручную. Если вдруг этот список расширится, то нужно его руками менять.
Во-вторых, в Go невозможно скомпилировать под, условно, Linux 2.6. Можно только под какой-то абстрактный Linux с непонятным набором доступных фичей. Здесь можно вспомнить io-uring, который в части дистрибутивов был, а в части его убрали по соображениям безопасности.
А build-теги — ну неудобно, но принципиально ничего не ограничивают.
Нехитрыми преобразованиями «ужасный» следующий код:
foo, err := DoSmth()
if err != nil {
return err
}
Превращается в совершенно «прекрасный»
var foo FooType
{
var err error
foo, err = DoSmth()
if err != nil {
return err
}
}
Я сам скорее согласен с автором и мне грустно видеть заложенную в Go идеологию. Но всё-таки у Go всё-таки имеется достаточный набор инструментов для решения примерно любой практической задачи.
Собственно, все большие игроки это уже сделали: Google давным-давно разрабатывает; Amazon (используется Anthropic); Microsoft вроде что-то делает; Meta заанонсили; OpenAI то ли дизайнит свои, то ли использует от гугла.
Подвох в том, что производство чипов по последним техпроцессам — дело дорогое, долгое и хорошо работает только в большом масштабе. А кроме чипов ещё нужны компиляторы/оптимизаторы под них и много разной обвязки. У отдельно взятых AI-стартапов нету сотни дата-центров и многих лет на создание уникальной инфры, поэтому подобным скорее занимаются именно облачные провайдеры, которые в подобном собаку съели.
Почему провайдеров-то? Провайдеры здесь сами заложники и ничего сделать не могут. Это все государственная структура (РКН).
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 тысячи раз больше солнечный батарей и площади. Это уже очень дофига места и обслуживания, а если ещё брать зимние месяцы, то становится совсем невероятно.
Новая libc может не заработать на новом ядре (потому что не хватает фич). Но старая libc заработает на новом ядре (потому что сисколлы из ядра не выпиливают).
А почему все сложные вычисления происходят именно на кольце, а не в приложении при синхронизации данных на смартфон?
Строго говоря, алгоритм довольно несложно доработать так, чтобы устаревшие элементы удалялись из куч в тот же момент, когда они вышли из окна. Но для этого потребуется заменить кучу на ваше любимое дерево поиска — тогда удаление станет возможно за O(log N) на каждый новый элемент, где N — размер окна. А реализация какого-нибудь КЧД это уже далековато от "несложно" =)
Однако же альтернативный вариант можно подглядеть здесь: https://stackoverflow.com/a/10696252 — там предлагается аналогичное решение, но с заменой кучи/дерева на список с пропусками, который обладает примерно теми же преимуществами и без необходимости реализовывать балансировку. Но в худшем случае он потребует O(N), что становится практически аналогично quicksort.
В целом, задача как ни крути сводится к поддержанию сортированного списка и быстрее чем O(log N) её решить в общем случае вряд ли выйдет. Учитывая что N (размер окна) довольно мало, то боюсь что любой выигрыш от сложных структур данных запросто будет нивелирован прямолинейностью quicksort.
Согласен, выразился слишком категорично. Какое-то апи есть, но со звездочкой. Из того что вживую втыкался:
Гугл фото (не диск!) закрыл доступ к всей библиотеке через API. Теперь можно видеть только то что было загружено тем же приложением, либо вручную выбирать до 2000 файлов и выдавать к ним доступ. В случае с Диском доступ не закрыли и API есть, но формально все те же самые механизмы уже реализованы и черт его знает что будет в будущем.
Яндекс.диск и его webdav, когда я его трогал, люто резал скорость до где-то 2МБ/с. Это неюзабельно, уж извините.
Про маил ру ничего не скажу, я акцию на 1ТБ пропустил =)
Собственно, примерно никакое файлооблако не даёт гарантий, что автоматизация с ним не сломается. А мне всё-таки хочется верить, что я свой бекап таки смогу просто взять и спокойно восстановить.
Для того чтобы шарить файлы — можно использовать примерно любой мессенджер, а при необходимости залить в примерно любой диск. Надежность при этом совершенно не важна, главное чтобы удобно было. Плюс у того же гугла/яндекса ещё и есть безлимит на фотографии (но со сжатием).
Если же для бекапов и сохранности — Backblaze B2 и AWS Deep Glacier. Первый умеренно дешёвый ($6/TB/mo), с хорошей репутацией и понятным ценообразованием. Второй при правильном использовании стоит сущие копейки (~$1/TB/mo), но восстановление обойдется долго и дорого и есть много подводных камней.
Типичный {гугл,яндекс,маил}.диск обычно имеют ужасные лимиты по скорости, полностью отсутствующее API и отсутствие каких-либо гарантий. Зато у них удобный интерфейс и возможность просто взять и поделиться. С ними я абсолютно уверен разве что в том, что в течении года по ссылке можно будет перейти и файлы через браузер скачать. Ну а большего мне и не надо.
Полноценные S3-подобные хранилища имеют немного более приятное ценообразование и вполне адекватные SLA (они хотя бы есть!). Но никаких красивых ссылок и удобства. Если мой домашний диск вдруг умрет, то почти точно я смогу восстановиться из Backblaze и никто меня в этот момент не забанит и скорость не ограничит. К восстановлению из Amazon, надеюсь, никогда не прибегну, но лишняя копия ещё никому не вредила.
Не надо два разных юзкейса смешивать и всё становится хорошо и приятно.
Я всей душой люблю Rust. Но не могу не заметить, что определить «момент последнего использования» в большинстве языков с GC — приблизительно невозможно. Потому что файл может быть в структуре, структура оказалась на куче, а GC в one-shot утилите банально не запускается. И вот теперь close() буквально никогда не вызовется.
А заставлять программиста доказывать компилятору факты о поведении программы — занятие хоть и полезное, но уж больно трудоемкое.
Если почитать статью по ссылке, то там подсвечивается более важная проблема кросс-компиляции — все условия выражены в терминах названия платформы, а не доступных фич этой платформы.
Во-первых, это не позволяет просто написать «если есть системный вызов pledge(), то используй его», а вместо этого надо перечислить все совместимые платформы вручную. Если вдруг этот список расширится, то нужно его руками менять.
Во-вторых, в Go невозможно скомпилировать под, условно, Linux 2.6. Можно только под какой-то абстрактный Linux с непонятным набором доступных фичей. Здесь можно вспомнить io-uring, который в части дистрибутивов был, а в части его убрали по соображениям безопасности.
А build-теги — ну неудобно, но принципиально ничего не ограничивают.
Да без проблем, на самом деле.
Нехитрыми преобразованиями «ужасный» следующий код:
Превращается в совершенно «прекрасный»
Я сам скорее согласен с автором и мне грустно видеть заложенную в Go идеологию. Но всё-таки у Go всё-таки имеется достаточный набор инструментов для решения примерно любой практической задачи.
Собственно, все большие игроки это уже сделали: Google давным-давно разрабатывает; Amazon (используется Anthropic); Microsoft вроде что-то делает; Meta заанонсили; OpenAI то ли дизайнит свои, то ли использует от гугла.
Подвох в том, что производство чипов по последним техпроцессам — дело дорогое, долгое и хорошо работает только в большом масштабе. А кроме чипов ещё нужны компиляторы/оптимизаторы под них и много разной обвязки. У отдельно взятых AI-стартапов нету сотни дата-центров и многих лет на создание уникальной инфры, поэтому подобным скорее занимаются именно облачные провайдеры, которые в подобном собаку съели.
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 тысячи раз больше солнечный батарей и площади. Это уже очень дофига места и обслуживания, а если ещё брать зимние месяцы, то становится совсем невероятно.