Этот предел является вычислимым числом. Хотя и не факт что рациональным. Как и значение функции в этой предельной точке (оно равно нулю). Поэтому эта теорема верна в конструктивной математике (о которой речь в этом среде)
Двояко. В процессе проверки гипотез часто находиться много нового. Чтоьы отвергнуть гипотезу, нужно что-то понять про задачу. И так далее.
Когла опровергают какие-то гипотезы через контрпример, сам контрпример выглядит взятым с потолка. Но на самом же деле, чтобы этот контрпример построить, нужно довольно хорошее понимание, почему эта гипотеза ложна, чего ей не хватает.
... причем в исходной модели есть на данном интервале, когда исходная модель не определена
Не очень понимаю, к чему это. Я не говорю, что Ваш метод плохой сам по себе. Я лишь говорю, что он не решает проблемы, которую Вы же сами и обозначили: как нарисовать кривую на компьютере.
Точнее сказать, в данном конкретном случае он её решает, но это вопрос чисто совпадения, а не общей закономерности. В общем случае нужно идти через анализ кривой, как я писал выше.
P.S. ну неопределена и неопределена — это же исходная постановка задачи. Если она так исходно была поставлена, значит скорее всего, это никого особо не волнует.
Вообще говоря, конечная формула более подвержена погрешностям, чем исходный вариант. Банальнопрям классический кандидат на catastrophic cancellation. С другой стороны, косинус можно посчитать довольно точно. С корнем, конечно, будет потеря точности, но он в обоих вариантах присутствует. И разумеется потеря точности с корнем не такая сильная, как в случае catastrophic cancellation.
Реальная причина, почему график стал лучше в том, что Вы разбили кривую на два лепестка. У кривой есть особая точка в (0, 0) и по сути Вы искусственно добавили контрольную точку, чтобы корректно обработать эту особенность.
Аналогичного результата можно добиться если в исходном подходе просто к списку точек взять и добавить точки.
И это собственно показывает путь к рисованию произвольных кривых. Вместо того, чтобы искать какую-то специфичную параметризацию, нужно искать особые точки: экстремумы, точки перегиба, самопересечения и прочее. И дальше рисовать сегменты между особыми точками наивным подходом.
Не очень понятна мотивация статьи и аппроксимации. Такая аппроксимация не особо лучше чем просто константа. Она работает исключительно потому, что Гауссов интеграл сходится невероятно быстро.
Но никому особо не нужна аппроксимация вида, гдемало. Обычно нужна аппроксимация вида гдемало. И со вторым Ваша аппроксимация вряд ли справится, по очевидным причинам.
Если же нужна грубая аппроксимация, то проще просто аппроксимировать константой при хоть сколько-то значимых значениях x.
Не очень понятно зачем. Выглядит так, будто нужно ручками следить за жизненным циклом. Но тогда можно и ручками дёргать createRoot/render/unmount.
Имело бы смысл, если бы библиотеку один раз можно было повесить на странице, и дальше она бы сама следила за добавлением и уничтожением узлов. В таком виде это имеет больше смысла.
Вообще вопрос проверки ассимптотики в тестах довольно важен и мало освещён. Хотя соглашусь, что пример в статье довольно неудачен.
На эту тему есть интересные тесты в rust-analyzer: раз, два. Они собирают статистику времени исполнения из 5-10 разных размеров для входа. На этой статистике строят регрессии. И если регрессия не выглядит линейной — тест считается упавшим (чуть сложнее, но суть такая).
Задача не найти ошибку, а угадать, куда указал анализатор. И анализатор не всегда указывает на место ошибки — вместо этого он указывает на "подозрительное место". Это не одно и то же.
А здесь довольно много разных факторов. Перечислю их безотносительно их критичности.
Для начала встаёт вопрос а что именно шифровать. Шифровать всё затея не лучшая (и непонятно что делать с джоинами). В идеале шифровать только собственно пд. Но тогда проблема в том, что пользователи любят указывать свои пд в условных комментариях или описаниях.
Дальше вопрос а как часто эти пд расшифровуются. Если на каждый запрос, то встаёт риск, что они куда-нибудь утекут после расшифровки: в логи, при ошибке, в другой микросервис, во внешнюю систему, в отчёт и прочее. Чтобы их расшифровывать пореже нужно аккуратно понять, а что именно шифровать, что нет. И дальше нужно очень аккуратно писать код, чтобы он мог работать с шифрованными данными.
Аналогичный вопрос, что с пд происходит до шифрования. Здесь тоже полно мест для утечки.
Ну и сама работа с ключами тоже весёлая. Ключи могут утечь из памяти в своп или кордамп. ВМ могут заснапшотить с памятью — тогда ключи можно достать из снапшота. К счастью, в логи обычно ключи не пишут (хотя бывает =().
Плюс ключи ведь нужно где-то хранить, в отдельном микросервисе например. И этот микросервис тоже нужно бэкапить. В нём тоже нужно как-то реализовывать физическое удаление и всё прочее.
С бэкапами тоже интересно. По-хорошему бэкапы должны быть иммутабельными и храниться где-нибудь отдельно. В частности их могут хранить на каком-нибудь (внешнем) s3 — а как оно там мутируется и удаляется никто не знает. Ну и при мутации бэкапов есть риск сломать его...
Здесь также есть всякая экзотика, что даже перезапись данных нулями не гарантирует их полного удаления. WAL может довольно долго не транкатиться (особенно в условном mssql). Есть всякие CoW фс по типу btrfs, которые при перезаписе создадут копию. А при прямом доступе к диску, бывает можно восстановить часть данных даже после перезаписи. Например всякий page redirect на ssd.
Короче говоря, рисков очень много разных. И самый главный вопрос: "а оно Вам надо"? ** Чаще всего удаление ПД подразумевает "к данным нельзя обратиться штатными средствами и они не используются при штатной обработке". В частности, формально даже soft delete является корректной мерой. Поэтому меры против такой вот археологии нужно отдельно обосновывать в рамках Вашей модели угроз.
**не является юридическим советом, проконсультируйтесь с юристом.
P.S. Я уже не говорю о том что шифрование, а тем более шифрование в бд довольно сложное (легко сделать неправильно). Многие программисты могут просто захардкодить ключ шифрования...
secure_delete это миф. И даже шифрование не всегда спасает. Если вам реально важно удаление пд, то это большая инженерная и аналитическая работа. Никаких волшебных палочек здесь нет.
Разделение моделей "Шаблон" и "Событие": Диапазоны идеальны для сущности Booking (где есть конкретная привязка к календарной дате). Но они плохо подходят для таблицы базового расписания (resource_availability_intervals), которая хранит циклические правила: “каждый понедельник с 09:00 до 13:00”. Хранить расписание в виде tstzrange заставило бы нас заниматься бесконечной генерацией (seeding) явных диапазонов на годы вперед для каждого ресурса, что раздуло бы БД. А скрещивать циклический LocalTime с tstzrange в рамках одного запроса — сомнительное удовольствие.
У Вас все запросы сравнивают колонку в бд с параметрами запроса. Там концептуально джоины по tsrange в бд делать никогда не нужно. А если их и делать, то это будет больно в любом формате хранения =/ Поэтому, кмк, эта причина не очень обоснована.
Вендоронезависимость (Vendor Lock-in): Типы range — это крутая, но чисто «постгресовая» фича. Использование стандартных типов позволяет при необходимости мигрировать b2b-платформу на любой другой диалект (MS SQL, MySQL, Oracle) силами изменения одной строки в конфиге.
На моём опыте, любая система с более менее нормальной нагрузкой гвоздями прибита к конкретной бд. Иногда бывает пара субд - но это отдельная, довольно большая инженерная работа.
Чтобы "поменять строку в конфиге" и оно запустилось на другой субд - такое не встречается. Обычно там либо баги всякие странные начинают лезть, либо производительность просаживается. Банально, в том же postgresql и ms sql разные подходы к блокировкам и конкуретности - ms sql может чаще выдавать LOCK_ERROR чем postgresql (и это нужно будет обрабатывать в приложении).
Ну и планировщики у субд сильно разные. Поэтому обычно под разные субд нужно писать разные запросы с разными индексами. Иначе производительность обычно получается довольно скудная.
Поэтому эта причина тоже кмк не обоснована.
И единственная причина, почему можно согласиться - это поддержка в hibernate.
Не уверен, насколько код в репозитории для примера, чем для реального использования.
Подход с midnight splitting конечно интересный, но в Вашей реализации не учитывается возможность брони сквозь полночь. Например, нельзя забронировать слот с 23:00 до 01:00 следующего дня.
Дальше обращу внимание, что реальные расписания гораздо сложнее Вашей модели. Как минимум там есть возможность менять расписание во времени, на специальные даты и так далее. Спишу это на демку.
Теперь к сути происходящего. Делать select for update на целый ресурс — затея несколько проблематичная. Для начала это может вызывать дедлоки (но мб если мы в одном запросе делаем, то там есть консистентный порядок). Во вторых, это убивает конкурентность в корне.
Одним из решений в плане конкурентности это шардирование. Нарезаете всё время доступности ресурса на временные интервалы, например по дням (в UTC). И дальше при бронировании блокируете все интервалы, с которыми у Вас есть пересечения (это может быть несколько дней из-за разных таймзон!). Гранулярность интервалов подбирать можно исходя из двух ограничений: 1) чем короче интервал, тем выше конкурентность 2) но если интервал короче типовой продолжительности слота, то нужно брать слишком много локов.
Если же хочется большей конкурентности, то тогда можно сделать внешнюю синхронизацию через условный редис.
Ну или же можно сторговать latency на throughput и смириться с коллизиями. Самое главное, это заранее определить правила выбора какую бронь из коллизии выбросить. Дальше, единственное что остаётся это удостовериться, что нашу запись не выбросили. Например, можно сделать у бронирования время создания и время "коммита"; при этом сделать ограничение, что интервал между созданием и коммитом должен быть короче T; тогда нам достаточно после коммита подождать время T+eps, если наша бронь всё ещё актуальна — можно выдать подтверждение.
Если говорить о теме статьи, то мне кажется тема собственно блокировок не раскрыта. Почему используется именно for update, а не for no key update? Как будет взаимодействовать создание бронирования с конкурентной правкой расписания? И так далее.
По поводу получения списка слотов. По перфу реализация приемлимая, т.к. на один ресурс не может быть слишком много бронирований (дискретизации нас спасает). А вот принцип перебора не очень работает. В частности, этот метод не может выдать слот 13:45-14:15. Это может быть ок, может нет. По хорошему, нужно бы перебирать просто все "дырки", длиной хотя бы в X.
Можно ли это сделать через индекс, без запроса всех бронирований — тут сходу не скажу.
---
На последок добавлю пару вопросов по бд.
Для работы с интервалами времени можно использовать интервальных типы в постгрес. Они позволяют естественно выразить всякие операции типа пересечения или вложенности. Плюс они поддерживают вменяемые индексы, если потребуется.
К слову об индексах. Индексы подобраны довольно неудачно, т.к. записи плохо шардируются по времени. В идеале любой индекс стоит начинать хотя бы с тенанта. Я бы сделал индекс хотя бы (company, start), а в идеале (company, resource, start). Добавлять end в индекс смысла нет, т.к. запросы носят другой характер.
Здесь кстати в идеале вложить resources внутрь booking просто как массив. Либо json, либо просто массив. Тогда это всё можно в один индекс закинуть.
Также, если оставлять это всё на отдельных start/end, а не интервалах, то стоит запросы перестроить, чтобы там было ограничение и сверху и снизу на start — иначе будет очень много фильтрации при выборке.
И немного о другой теме, по поводу обновления расписания. Увидел реализацию в виде delete all + insert. Это, конечно, работает. Но в проде может вызывать сильную потерю данных из-за какого-нибудь cascade ...
Возможно получилось несколько скомкано. Если будут непонятны какие-то из тезисов, можете спросить.
Не говорю уже о том, а зачем их вообще прятать... (там другая модель защиты).
Проверка цифровой подписи
Может быть неплохо, но принципиально мало что меняет. Подпись точно так же можно украсть. Тут скорее зависит от аудита инфраструктуры, чем от внедрения подписей...
И в целом не очень понятна сама претензия: а в какая модель угроз и злоумышленника? Пока что выглядит как типичная история с supply chain. Она же, хоть и в меньшем масштабе, присутствует и в самом андроиде.
P.S. код, конечно, не самый приличный, но тут и у оригинала не всё гладко =/
Другой вопрос, что мы предпочитаем знание "попроще". Правда это "проще" в разных ситуациях разное.
Например, для кого-то "проще" — это когда поменьше параметров и постулатов. В этом смысле модель силы земного притяжения попроще нейронки. А вот если же говорить про силу трейния — тут уже зависит (т.к. нужно как-то найти много разных коэффициентов трения).
В других ситуациях "попроще" — это короче путь от постулатов до практического применения. В этом смысле ллм проще чем условные законы Кирхгофа, т.к. сразу даёт ответ. А законы Кирхгофа проще чем куловские постулаты/уравнения Максвелла.
В частности, с точки зрения фундаментальной науки, знание в виде нейронки — есть довольно неудобное научное знание. Но оно от этого не перестаёт быть научным знанием...
Так это macro_rules, а не derive. Это совершенно не связанные вещи.
Ну и касательно самих macro_rules, я не вижу здесь указаний, что они задумывались как временное решение. Они были в языке с момента релиза и, насколько я знаю, тогда не было планов их заменить на что-то другое.
Просто уже после релиза языка, при практическом опыте использования, пришли к выводу, что систему макросов можно улучшить. Сначала добавили макросы в основной неймрез. А потом предложили макросы 2.0 — но это аж 2016 год, через год после релиза.
Есть ли у Вас ссылки, которые именно что подкрепляют Ваше заявление, что (derive) макросы именно что задумывались как временно решение?
P.S. ну и sunshine/rust-course не является официальным источником, и не похож, как заслуживающий доверия (в таких тонких вопросах)
Если функция вычислима, и конструктивно непрерывна, то хоть одна точка пересечения нуля является вычислимой.
Этот предел является вычислимым числом. Хотя и не факт что рациональным. Как и значение функции в этой предельной точке (оно равно нулю). Поэтому эта теорема верна в конструктивной математике (о которой речь в этом среде)
Двояко. В процессе проверки гипотез часто находиться много нового. Чтоьы отвергнуть гипотезу, нужно что-то понять про задачу. И так далее.
Когла опровергают какие-то гипотезы через контрпример, сам контрпример выглядит взятым с потолка. Но на самом же деле, чтобы этот контрпример построить, нужно довольно хорошее понимание, почему эта гипотеза ложна, чего ей не хватает.
Нет, такая запись не используется. Традиционный способ записать подобное высказывание выглядит как-то так:
Всё же, предел, это число. Для "равенств в пределе" используют символику Ландау.
Не очень понимаю, к чему это. Я не говорю, что Ваш метод плохой сам по себе. Я лишь говорю, что он не решает проблемы, которую Вы же сами и обозначили: как нарисовать кривую на компьютере.
Точнее сказать, в данном конкретном случае он её решает, но это вопрос чисто совпадения, а не общей закономерности. В общем случае нужно идти через анализ кривой, как я писал выше.
P.S. ну неопределена и неопределена — это же исходная постановка задачи. Если она так исходно была поставлена, значит скорее всего, это никого особо не волнует.
Вообще говоря, конечная формула более подвержена погрешностям, чем исходный вариант. Банально
прям классический кандидат на catastrophic cancellation. С другой стороны, косинус можно посчитать довольно точно. С корнем, конечно, будет потеря точности, но он в обоих вариантах присутствует. И разумеется потеря точности с корнем не такая сильная, как в случае catastrophic cancellation.
Реальная причина, почему график стал лучше в том, что Вы разбили кривую на два лепестка. У кривой есть особая точка в (0, 0) и по сути Вы искусственно добавили контрольную точку, чтобы корректно обработать эту особенность.
Аналогичного результата можно добиться если в исходном подходе просто к списку точек взять и добавить точки
.
И это собственно показывает путь к рисованию произвольных кривых. Вместо того, чтобы искать какую-то специфичную параметризацию, нужно искать особые точки: экстремумы, точки перегиба, самопересечения и прочее. И дальше рисовать сегменты между особыми точками наивным подходом.
Не очень понятна мотивация статьи и аппроксимации. Такая аппроксимация не особо лучше чем просто константа. Она работает исключительно потому, что Гауссов интеграл сходится невероятно быстро.
Но никому особо не нужна аппроксимация вида
, где
мало. Обычно нужна аппроксимация вида
где
мало. И со вторым Ваша аппроксимация вряд ли справится, по очевидным причинам.
Если же нужна грубая аппроксимация, то проще просто аппроксимировать константой при хоть сколько-то значимых значениях x.
Не очень понятно зачем. Выглядит так, будто нужно ручками следить за жизненным циклом. Но тогда можно и ручками дёргать createRoot/render/unmount.
Имело бы смысл, если бы библиотеку один раз можно было повесить на странице, и дальше она бы сама следила за добавлением и уничтожением узлов. В таком виде это имеет больше смысла.
Вообще вопрос проверки ассимптотики в тестах довольно важен и мало освещён. Хотя соглашусь, что пример в статье довольно неудачен.
На эту тему есть интересные тесты в rust-analyzer: раз, два. Они собирают статистику времени исполнения из 5-10 разных размеров для входа. На этой статистике строят регрессии. И если регрессия не выглядит линейной — тест считается упавшим (чуть сложнее, но суть такая).
Edit: хабр съел первый абзац =/
Задача не найти ошибку, а угадать, куда указал анализатор. И анализатор не всегда указывает на место ошибки — вместо этого он указывает на "подозрительное место". Это не одно и то же.
А здесь довольно много разных факторов. Перечислю их безотносительно их критичности.
Для начала встаёт вопрос а что именно шифровать. Шифровать всё затея не лучшая (и непонятно что делать с джоинами). В идеале шифровать только собственно пд. Но тогда проблема в том, что пользователи любят указывать свои пд в условных комментариях или описаниях.
Дальше вопрос а как часто эти пд расшифровуются. Если на каждый запрос, то встаёт риск, что они куда-нибудь утекут после расшифровки: в логи, при ошибке, в другой микросервис, во внешнюю систему, в отчёт и прочее. Чтобы их расшифровывать пореже нужно аккуратно понять, а что именно шифровать, что нет. И дальше нужно очень аккуратно писать код, чтобы он мог работать с шифрованными данными.
Аналогичный вопрос, что с пд происходит до шифрования. Здесь тоже полно мест для утечки.
Ну и сама работа с ключами тоже весёлая. Ключи могут утечь из памяти в своп или кордамп. ВМ могут заснапшотить с памятью — тогда ключи можно достать из снапшота. К счастью, в логи обычно ключи не пишут (хотя бывает =().
Плюс ключи ведь нужно где-то хранить, в отдельном микросервисе например. И этот микросервис тоже нужно бэкапить. В нём тоже нужно как-то реализовывать физическое удаление и всё прочее.
С бэкапами тоже интересно. По-хорошему бэкапы должны быть иммутабельными и храниться где-нибудь отдельно. В частности их могут хранить на каком-нибудь (внешнем) s3 — а как оно там мутируется и удаляется никто не знает. Ну и при мутации бэкапов есть риск сломать его...
Здесь также есть всякая экзотика, что даже перезапись данных нулями не гарантирует их полного удаления. WAL может довольно долго не транкатиться (особенно в условном mssql). Есть всякие CoW фс по типу btrfs, которые при перезаписе создадут копию. А при прямом доступе к диску, бывает можно восстановить часть данных даже после перезаписи. Например всякий page redirect на ssd.
Короче говоря, рисков очень много разных. И самый главный вопрос: "а оно Вам надо"? ** Чаще всего удаление ПД подразумевает "к данным нельзя обратиться штатными средствами и они не используются при штатной обработке". В частности, формально даже soft delete является корректной мерой. Поэтому меры против такой вот археологии нужно отдельно обосновывать в рамках Вашей модели угроз.
**не является юридическим советом, проконсультируйтесь с юристом.
P.S. Я уже не говорю о том что шифрование, а тем более шифрование в бд довольно сложное (легко сделать неправильно). Многие программисты могут просто захардкодить ключ шифрования...
secure_delete это миф. И даже шифрование не всегда спасает. Если вам реально важно удаление пд, то это большая инженерная и аналитическая работа. Никаких волшебных палочек здесь нет.
У Вас все запросы сравнивают колонку в бд с параметрами запроса. Там концептуально джоины по tsrange в бд делать никогда не нужно. А если их и делать, то это будет больно в любом формате хранения =/
Поэтому, кмк, эта причина не очень обоснована.
На моём опыте, любая система с более менее нормальной нагрузкой гвоздями прибита к конкретной бд. Иногда бывает пара субд - но это отдельная, довольно большая инженерная работа.
Чтобы "поменять строку в конфиге" и оно запустилось на другой субд - такое не встречается. Обычно там либо баги всякие странные начинают лезть, либо производительность просаживается. Банально, в том же postgresql и ms sql разные подходы к блокировкам и конкуретности - ms sql может чаще выдавать LOCK_ERROR чем postgresql (и это нужно будет обрабатывать в приложении).
Ну и планировщики у субд сильно разные. Поэтому обычно под разные субд нужно писать разные запросы с разными индексами. Иначе производительность обычно получается довольно скудная.
Поэтому эта причина тоже кмк не обоснована.
И единственная причина, почему можно согласиться - это поддержка в hibernate.
Не уверен, насколько код в репозитории для примера, чем для реального использования.
Подход с midnight splitting конечно интересный, но в Вашей реализации не учитывается возможность брони сквозь полночь. Например, нельзя забронировать слот с 23:00 до 01:00 следующего дня.
Дальше обращу внимание, что реальные расписания гораздо сложнее Вашей модели. Как минимум там есть возможность менять расписание во времени, на специальные даты и так далее. Спишу это на демку.
Теперь к сути происходящего. Делать select for update на целый ресурс — затея несколько проблематичная. Для начала это может вызывать дедлоки (но мб если мы в одном запросе делаем, то там есть консистентный порядок). Во вторых, это убивает конкурентность в корне.
Одним из решений в плане конкурентности это шардирование. Нарезаете всё время доступности ресурса на временные интервалы, например по дням (в UTC). И дальше при бронировании блокируете все интервалы, с которыми у Вас есть пересечения (это может быть несколько дней из-за разных таймзон!). Гранулярность интервалов подбирать можно исходя из двух ограничений: 1) чем короче интервал, тем выше конкурентность 2) но если интервал короче типовой продолжительности слота, то нужно брать слишком много локов.
Если же хочется большей конкурентности, то тогда можно сделать внешнюю синхронизацию через условный редис.
Ну или же можно сторговать latency на throughput и смириться с коллизиями. Самое главное, это заранее определить правила выбора какую бронь из коллизии выбросить. Дальше, единственное что остаётся это удостовериться, что нашу запись не выбросили. Например, можно сделать у бронирования время создания и время "коммита"; при этом сделать ограничение, что интервал между созданием и коммитом должен быть короче T; тогда нам достаточно после коммита подождать время T+eps, если наша бронь всё ещё актуальна — можно выдать подтверждение.
Если говорить о теме статьи, то мне кажется тема собственно блокировок не раскрыта. Почему используется именно for update, а не for no key update? Как будет взаимодействовать создание бронирования с конкурентной правкой расписания? И так далее.
По поводу получения списка слотов. По перфу реализация приемлимая, т.к. на один ресурс не может быть слишком много бронирований (дискретизации нас спасает). А вот принцип перебора не очень работает. В частности, этот метод не может выдать слот 13:45-14:15. Это может быть ок, может нет. По хорошему, нужно бы перебирать просто все "дырки", длиной хотя бы в X.
Можно ли это сделать через индекс, без запроса всех бронирований — тут сходу не скажу.
---
На последок добавлю пару вопросов по бд.
Для работы с интервалами времени можно использовать интервальных типы в постгрес. Они позволяют естественно выразить всякие операции типа пересечения или вложенности. Плюс они поддерживают вменяемые индексы, если потребуется.
К слову об индексах. Индексы подобраны довольно неудачно, т.к. записи плохо шардируются по времени. В идеале любой индекс стоит начинать хотя бы с тенанта. Я бы сделал индекс хотя бы (company, start), а в идеале (company, resource, start). Добавлять end в индекс смысла нет, т.к. запросы носят другой характер.
Здесь кстати в идеале вложить resources внутрь booking просто как массив. Либо json, либо просто массив. Тогда это всё можно в один индекс закинуть.
Также, если оставлять это всё на отдельных start/end, а не интервалах, то стоит запросы перестроить, чтобы там было ограничение и сверху и снизу на start — иначе будет очень много фильтрации при выборке.
И немного о другой теме, по поводу обновления расписания. Увидел реализацию в виде delete all + insert. Это, конечно, работает. Но в проде может вызывать сильную потерю данных из-за какого-нибудь cascade ...
Возможно получилось несколько скомкано. Если будут непонятны какие-то из тезисов, можете спросить.
P.S. в целом статья мне понравилась, спасибо
И как это поможет?
Не говорю уже о том, а зачем их вообще прятать... (там другая модель защиты).
Может быть неплохо, но принципиально мало что меняет. Подпись точно так же можно украсть. Тут скорее зависит от аудита инфраструктуры, чем от внедрения подписей...
И в целом не очень понятна сама претензия: а в какая модель угроз и злоумышленника? Пока что выглядит как типичная история с supply chain. Она же, хоть и в меньшем масштабе, присутствует и в самом андроиде.
P.S. код, конечно, не самый приличный, но тут и у оригинала не всё гладко =/
Другой вопрос, что мы предпочитаем знание "попроще". Правда это "проще" в разных ситуациях разное.
Например, для кого-то "проще" — это когда поменьше параметров и постулатов. В этом смысле модель силы земного притяжения попроще нейронки. А вот если же говорить про силу трейния — тут уже зависит (т.к. нужно как-то найти много разных коэффициентов трения).
В других ситуациях "попроще" — это короче путь от постулатов до практического применения. В этом смысле ллм проще чем условные законы Кирхгофа, т.к. сразу даёт ответ. А законы Кирхгофа проще чем куловские постулаты/уравнения Максвелла.
В частности, с точки зрения фундаментальной науки, знание в виде нейронки — есть довольно неудобное научное знание. Но оно от этого не перестаёт быть научным знанием...
Что будет, если после ввода пинкода наоборот выйти и ввести его ещё раз? Откроется ли то же самое? Если нет, то это не имеет смысла
Edit: ну и в целом отличить пинкод и пинкод наоборот можно через скорость ввода (на отдельном устройстве)
Так это macro_rules, а не derive. Это совершенно не связанные вещи.
Ну и касательно самих macro_rules, я не вижу здесь указаний, что они задумывались как временное решение. Они были в языке с момента релиза и, насколько я знаю, тогда не было планов их заменить на что-то другое.
Просто уже после релиза языка, при практическом опыте использования, пришли к выводу, что систему макросов можно улучшить. Сначала добавили макросы в основной неймрез. А потом предложили макросы 2.0 — но это аж 2016 год, через год после релиза.
Есть ли у Вас ссылки, которые именно что подкрепляют Ваше заявление, что (derive) макросы именно что задумывались как временно решение?
P.S. ну и sunshine/rust-course не является официальным источником, и не похож, как заслуживающий доверия (в таких тонких вопросах)
Что делать, если глубина стека будет больше доступного количества регистров?
Да не то чтобы особенность. Достаточно частый подход, вплоть до nanopass с десятками ir
Edit: ну и с приходом mlir теперь похожая история едет и во всякие clang/mojo/arc и прочее