Хм, точно: если подвесить заряд над кольцом и подогнать массу, то это равносильно тому, что мы поместим невесомый заряд в центр кольца. И да, убежит он вверх или вниз, но прижимаясь к оси. Посыпаю голову точечными зарядами :)
Согласен. Но... меня терзают смутные сомнения, так как условия задачи уже не совсем в области определения теоремы Ирншоу: сама "твёрдая подпорка" уже невозможна в голой электростатике, так как внутри у неё всякая ковалентная и квантовая магия, чтобы существовал твёрдый материал, на который мы уже можем клеить магниты.
Если картинка не обманывает, то есть эквипотенциальные поверхности, которые в 3D выглядят как "эритроциты" (таблетки с вмятиной), что явно говорит о потенциальной яме: градиент поля (следовательно, сила) в такой вмятине будет смещать пробный заряд ближе к оси... и нам осталось навесить сверху гравитацию, чтобы такой заряд не улетал от кольца, а возвращался во вмятину из бесконечно-малого смещения.
Напрямую к нашим магнитам, правда, такие рассуждения неприменимы, но моя мысль в том, что, вообще говоря, наличие в системе "невозможных" с точки зрения теоремы Ирншоу объектов типа банальных твёрдых деревяшек, на которые можно наклеить магниты — уже чит сам по себе даже в статике.
Вообще, при наличии гравитации не понятна причина, почему может не работать конструкция с "магнитной стенкой". Рассмотрим предельный случай: в сторону подпорки продлим невесомую ось ротора до условной бесконечности, а на конце соорудим наивную конструкцию с невесомыми отталкивающимися магнитами:
SN
NS===NS------NS SN
SN SN SN
1 2
Правая часть рисунка — не что иное, как повернутый на 90° левитрон, но если вертикальному левитрону нужно вращение для избежания опрокидывания, то лежащий должен стабилизироваться моментом оси: вниз его тянет гравитация, вверх возвращает момент от подвеса #2, к "стенке" его прижимает ротор, а к-нам/от-нас его стабилизируют те же моменты обоих подвесов, которые не дают горизонтально развернуться ротору.
Формально даже по старым стандартам проблем быть не должно, placement new начинает lifetime объекта (https://en.cppreference.com/w/cpp/language/new.html#Placement_new). Разве что с выравниванием могут быть проблемы, но по факту — в 90% систем и компиляторов всё тоже будет ок.
Нет, компиляторами ничего не игнорируется просто так, inline сейчас имеет просто другой смысл (выше написали про линковку), и к встраиванию не имеет никакого отношения. По-хорошему просто так его писать не нужно, иначе можно случайно замаскировать multiple definition error, который обычно выстрелит на линковке.
Запрос Double Click в принципе довольно странен и может насторожить (да и кто читает инструкции к капче?). Проще сделать вид, что кнопка "залипла" и не нажимается, и подменять окна только после нескольких яростных кликов (да — лаунчеры, меняющие фокус, я смотрю на вас с презрением и негодованием).
Выполняется. В демо видно, что после нажатия "Start Here" фейковая кнопка не активна в течение некоторого таймера — в это время, вероятно, под видимым окном грузится страница атакуемого сайта. В описании атаки тоже это проговаривается (не совсем очевидно, правда).
В самой статье сильно не хватает описания инструментария, доступного ИИ (хоть вы и ответили в комментарии выше, почему бы сразу не приложить этот промт в самой статье для желающих повторить эксперимент). Если ИИ доступен execute_code, то простор для решений довольно большой, вплоть до полного слома хостовой системы эксплоитами и прописывания себя в UEFI, например.
если представить элементы поля не в виде чисел, а в виде кортежей
Тогда это уже будет не поле целых чисел, а поле таких "кортежей" (кажется, полностью идентичное полю рациональных чисел). Вопрос просто в определении: по определению поля, множество целых чисел не является полем, так как частное от деления целых чисел может не принадлежать множеству целых чисел.
А, ну да, позволит, а рарчик просто открывался :) В статье ещё описывается использование WebRTC по UDP, у него тоже нет аналога CORS-ограничений вроде как.
Во-первых, открывать голые TCP/UDP соединения браузер всё-таки не позволит (если только через расширения конкретного браузера).
Однако, http-запросы из JS куда угодно разрешены, НО! CORS не позволит прочитать ответ внутри JS, если в ответе нет явного заголовка Access-Control-Allow-Origin: XXX. Да, в wireshark очень чётко видны открывающиеся TCP-сессии, запросы от браузера и радостные ответы локальных сервисов. Тем не менее:
остаётся возможность атаки по стороннему каналу (например, замеряем время запроса к http://127.0.0.1:5432 — косвенно понимаем, работает Postgres у пользователя локально или нет);
банально, всё ещё можно отправить запросы вида PUT http://192.168.0.1/login?user=admin&password=admin&set_dns=99.99.99.99 (зависит от API слушающих сервисов) — ответ нам вообще не важен, мы просто в лоб передаём в запросе нужную информацию слушающему сервису. Именно такой вектор обмена информацией рассматривается в статье.
Для меня лично стало неприятным сюрпризом, что
даже в современных браузерах есть возможность напрямую из песочницы обращаться к локальной сети и выполнять такой жирным пласт запросов (пусть и чаще всего односторонних);
и что CORS всего навсего блокирует ответы, но не запросы (что логично, но требует осознания).
Кстати, эту стереопару вполне можно рассмотреть и в миниатюрном варианте из статьи) Ну и да, она, в отличие от остальных фото в статье, предназначена для метода параллельного взгляда, а не перекрёстного.
Немного дополню озвученные ответы: да, "сила" объёмности зависит от т.н. стереобазы, то есть расстояния между фотоприёмниками (зрачками, объективами стереокамеры/бинокля и пр.). С помощью изменения этого расстояния в VR-приложениях настраивается масштаб сцены относительно пользователя: например, по умолчанию в Google Earth VR мир кажется игрушечным, потому что расстояние между камерами рендеринга равно десяткам/сотням метров, но активация режима "Human Scale" выставляет стереобазу в единицы-десятки сантиметров, что сразу меняет масштаб мира.
Увы, слишком короткая стереобаза (~6 см, межзрачковое расстояние) хоть и должна верно передавать масштаб, но делает два отрендеренных изображения слишком слабо различающимися, что при недостаточном разрешении дисплеев приводит к проблеме "плоской" сцены без параллакса — как в старых игрушках, когда пейзажи запекались в текстуру и натягивались на плоскость.
Так аналитическое решение само по себе торт! Можно предельный переход сделать c → ∞ (спойлер: да, приходим к классическим формулам), можно g покрутить (чёрная дыра), или m занулить (нейтрино, фотон… ну тут конечно погорячился).
Прошу помощи зала: помнится, на Хабре было несколько похожих статей, где рассматривался вопрос поиска некоего алгоритма брутфорсом опкодов миниатюрной ВМ. Так вот, не могу найти статью, в которой рассказывалось, как искалась "программа", помещавшаяся в 64-битное число (внутри которого кодировались инструкции стековой машины в обратной польской нотации), собственно перебором всех 64-битных чисел. Может, кто-то помнит эту статью или хотя бы волшебные слова из неё?
Чиселка с деньгами — это чаще всего всё равно будет какой-нибудь uint64_t, хоть он внутри Integer внутри Object, хоть он внутри struct Wallet внутри struct MyCharacter. А значит, этот кусок памяти можно отыскать. Кроме того, состояние типа "money" обычно какое-то глобальное или по крайней мере не пересоздающееся постоянно, значит, сборщиком оно не разрушится (например, ссылка на "money" опосредованно должна быть у рендерера или у планировщика, пинающего рендерер).
Тут даже ещё интереснее — всё-таки заряд выскользнет перпендикулярно от оси, а не вдоль. Штош, интуиция тут и правда курит в сторонке.
UPD: там даже две седловые точки! Одна вертикально-стабильная, другая горизонтально-стабильная.
Хм, точно: если подвесить заряд над кольцом и подогнать массу, то это равносильно тому, что мы поместим невесомый заряд в центр кольца. И да, убежит он вверх или вниз, но прижимаясь к оси. Посыпаю голову точечными зарядами :)
Согласен. Но... меня терзают смутные сомнения, так как условия задачи уже не совсем в области определения теоремы Ирншоу: сама "твёрдая подпорка" уже невозможна в голой электростатике, так как внутри у неё всякая ковалентная и квантовая магия, чтобы существовал твёрдый материал, на который мы уже можем клеить магниты.
Например, заряженное кольцо:
Если картинка не обманывает, то есть эквипотенциальные поверхности, которые в 3D выглядят как "эритроциты" (таблетки с вмятиной), что явно говорит о потенциальной яме: градиент поля (следовательно, сила) в такой вмятине будет смещать пробный заряд ближе к оси... и нам осталось навесить сверху гравитацию, чтобы такой заряд не улетал от кольца, а возвращался во вмятину из бесконечно-малого смещения.
Напрямую к нашим магнитам, правда, такие рассуждения неприменимы, но моя мысль в том, что, вообще говоря, наличие в системе "невозможных" с точки зрения теоремы Ирншоу объектов типа банальных твёрдых деревяшек, на которые можно наклеить магниты — уже чит сам по себе даже в статике.
Вообще, при наличии гравитации не понятна причина, почему может не работать конструкция с "магнитной стенкой". Рассмотрим предельный случай: в сторону подпорки продлим невесомую ось ротора до условной бесконечности, а на конце соорудим наивную конструкцию с невесомыми отталкивающимися магнитами:
Правая часть рисунка — не что иное, как повернутый на 90° левитрон, но если вертикальному левитрону нужно вращение для избежания опрокидывания, то лежащий должен стабилизироваться моментом оси: вниз его тянет гравитация, вверх возвращает момент от подвеса #2, к "стенке" его прижимает ротор, а к-нам/от-нас его стабилизируют те же моменты обоих подвесов, которые не дают горизонтально развернуться ротору.
Да, а ещё
aligned_alloc, но в статье и комментарии обсуждается именно голый пример "malloc + c-tor", и вот для него формально не всё хорошо.Формально даже по старым стандартам проблем быть не должно, placement new начинает lifetime объекта (https://en.cppreference.com/w/cpp/language/new.html#Placement_new). Разве что с выравниванием могут быть проблемы, но по факту — в 90% систем и компиляторов всё тоже будет ок.
Нет, компиляторами ничего не игнорируется просто так,
inlineсейчас имеет просто другой смысл (выше написали про линковку), и к встраиванию не имеет никакого отношения. По-хорошему просто так его писать не нужно, иначе можно случайно замаскировать multiple definition error, который обычно выстрелит на линковке.Запрос Double Click в принципе довольно странен и может насторожить (да и кто читает инструкции к капче?). Проще сделать вид, что кнопка "залипла" и не нажимается, и подменять окна только после нескольких яростных кликов (да — лаунчеры, меняющие фокус, я смотрю на вас с презрением и негодованием).
Выполняется. В демо видно, что после нажатия "Start Here" фейковая кнопка не активна в течение некоторого таймера — в это время, вероятно, под видимым окном грузится страница атакуемого сайта. В описании атаки тоже это проговаривается (не совсем очевидно, правда).
В самой статье сильно не хватает описания инструментария, доступного ИИ (хоть вы и ответили в комментарии выше, почему бы сразу не приложить этот промт в самой статье для желающих повторить эксперимент). Если ИИ доступен
execute_code, то простор для решений довольно большой, вплоть до полного слома хостовой системы эксплоитами и прописывания себя в UEFI, например.Тогда это уже будет не поле целых чисел, а поле таких "кортежей" (кажется, полностью идентичное полю рациональных чисел). Вопрос просто в определении: по определению поля, множество целых чисел не является полем, так как частное от деления целых чисел может не принадлежать множеству целых чисел.
А, ну да, позволит, а рарчик просто открывался :) В статье ещё описывается использование WebRTC по UDP, у него тоже нет аналога CORS-ограничений вроде как.
Ответ сложнее и интереснее, чем может показаться.
Во-первых, открывать голые TCP/UDP соединения браузер всё-таки не позволит (если только через расширения конкретного браузера).
Однако, http-запросы из JS куда угодно разрешены, НО! CORS не позволит прочитать ответ внутри JS, если в ответе нет явного заголовка
Access-Control-Allow-Origin: XXX. Да, в wireshark очень чётко видны открывающиеся TCP-сессии, запросы от браузера и радостные ответы локальных сервисов. Тем не менее:остаётся возможность атаки по стороннему каналу (например, замеряем время запроса к
http://127.0.0.1:5432— косвенно понимаем, работает Postgres у пользователя локально или нет);банально, всё ещё можно отправить запросы вида
PUT http://192.168.0.1/login?user=admin&password=admin&set_dns=99.99.99.99(зависит от API слушающих сервисов) — ответ нам вообще не важен, мы просто в лоб передаём в запросе нужную информацию слушающему сервису. Именно такой вектор обмена информацией рассматривается в статье.Для меня лично стало неприятным сюрпризом, что
даже в современных браузерах есть возможность напрямую из песочницы обращаться к локальной сети и выполнять такой жирным пласт запросов (пусть и чаще всего односторонних);
и что CORS всего навсего блокирует ответы, но не запросы (что логично, но требует осознания).
Кстати, эту стереопару вполне можно рассмотреть и в миниатюрном варианте из статьи) Ну и да, она, в отличие от остальных фото в статье, предназначена для метода параллельного взгляда, а не перекрёстного.
Немного дополню озвученные ответы: да, "сила" объёмности зависит от т.н. стереобазы, то есть расстояния между фотоприёмниками (зрачками, объективами стереокамеры/бинокля и пр.). С помощью изменения этого расстояния в VR-приложениях настраивается масштаб сцены относительно пользователя: например, по умолчанию в Google Earth VR мир кажется игрушечным, потому что расстояние между камерами рендеринга равно десяткам/сотням метров, но активация режима "Human Scale" выставляет стереобазу в единицы-десятки сантиметров, что сразу меняет масштаб мира.
Увы, слишком короткая стереобаза (~6 см, межзрачковое расстояние) хоть и должна верно передавать масштаб, но делает два отрендеренных изображения слишком слабо различающимися, что при недостаточном разрешении дисплеев приводит к проблеме "плоской" сцены без параллакса — как в старых игрушках, когда пейзажи запекались в текстуру и натягивались на плоскость.
Почему-то прямо с порога некорректный ответ (
clang-trunk -O0):На
-O1и выше всё норм. UB таки стреляет?Для интересующихся — отличный перевод статьи 2018 года на Хабре про эту же технику:
Иллюзия пространства: как новый Spiderman рендерит помещения без геометрии
Так аналитическое решение само по себе торт! Можно предельный переход сделать c → ∞ (спойлер: да, приходим к классическим формулам), можно g покрутить (чёрная дыра), или m занулить (нейтрино,
фотон… ну тут конечно погорячился).Прошу помощи зала: помнится, на Хабре было несколько похожих статей, где рассматривался вопрос поиска некоего алгоритма брутфорсом опкодов миниатюрной ВМ. Так вот, не могу найти статью, в которой рассказывалось, как искалась "программа", помещавшаяся в 64-битное число (внутри которого кодировались инструкции стековой машины в обратной польской нотации), собственно перебором всех 64-битных чисел. Может, кто-то помнит эту статью или хотя бы волшебные слова из неё?
Чиселка с деньгами — это чаще всего всё равно будет какой-нибудь
uint64_t, хоть он внутриIntegerвнутриObject, хоть он внутриstruct Walletвнутриstruct MyCharacter. А значит, этот кусок памяти можно отыскать. Кроме того, состояние типа "money" обычно какое-то глобальное или по крайней мере не пересоздающееся постоянно, значит, сборщиком оно не разрушится (например, ссылка на "money" опосредованно должна быть у рендерера или у планировщика, пинающего рендерер).