потому что нет задачи увеличивать пропускную способность
Для города актуально организовать перемещение большого количества людей
у вас двоемыслие какое-то.
Повысить пропускную способность можно либо расширение трубы (больше полос) либо упаковка поплотнее (общественный транспорт). Можно повысить привлекательность общественного транспорта (увеличивая тем самым пропускную способность) увеличив количество маршрутов и количество рейсов, сделать ему выделенную полосу.
Но просто уменьшать количество полос = уменьшить пропускную способность ака ухудшить организацию перемещения большого количества людей.
Зачем уменьшать количество полос? Так уменьшается пропускная способность, но не уменьшается скорость (наоборот для той же пропускной способности надо быстрее ехать). Может наоборот больше полос (больше пропускная способность что для города актуально), но каждые 100 метров по лежачему полицейскому (меньше скорость)?
А то все эти высказывания и аргументы про то что средняя скорость по городу 30км/ч - давайте значит уменьшим количество полос сродни менеджерским оптимизациям типа: в фановой трубе туалета в среднем за минуту проходит 3л воды, а труба широкая - давайте уменьшим, сэкономим. А то что там пики потребления бывают - это же думать надо, это не про нас.
как у них там получилось, что индекс по 16-байтному (пусть и упорядоченному) UUID оказался меньше 8-байтного BIgInt?
Сам удивился и залип пытаясь понять. В общем они используют bigint(20) для primary key и id binary(16) для UUID. Из за того что в mysql primary key кластеризован и вторичные индексы указывают на primary key примерно так и выходит.
Размер индексов это вторичных, т.к. первичный это и есть сама таблица.
upd, наврал. bigint(20) все так же занимает 8 байт. Проблема в том что в этом тесте для Bigint есть лишний индекс: primary - count (bigint), плюс индекс на поле id.
Не говорил про разделение блоков, скорее расширение. У вас же не всегда есть место для новой записи. То есть при вставке все равно приходится раздвигать текущие блоки. (или менять ссылку если реализация на связном списке, что врядли используется для индексов, т.к. в индексе по своей похожие данные должны лежать рядом). Что приводит к увеличению записи. Плюс есть детали имплементации на всяких системах (wal, etc). Есть факт что не UUID без инкрементальной составляющей это боль и тормоза на большинстве систем.
Размер WAL с размером индексов слабо коррелирует. Ну и да, в посгре WAL не особо оптимален, так что он сам по себе тот ещё источник тормозов.
For the table with UUID as PRIMARY KEY, you can notice that as the table grows big, the time taken to insert rows is increasing almost linearly. Whereas for other tables, the time taken is almost constant.
The size of the UUID table is almost 50% bigger than Ordered UUID table and 30% bigger than the table with BIGINT as PRIMARY KEY. Comparing the Ordered UUID table BIGINT table, the time is taken to insert rows and the size are almost the same. But they may vary slightly based on the index structure.
И часто вы пишете последовательно одинаковые данные?
Зависит от сценария. Но суть том не в ток как часто пишу я, а в том как часто пишет его БД. В случае последовательного uuid будет писать часто, в результате оверхед от хранения первых байт UUID в индексе может быть меньше.
Да, но проблема в физике: при вставке придется идти в кучу мест на диске, расширять блоки. При этом это вызовет дополнительные чтения с диска, т.к. надо найти место куда вставлять данные, скорее всего это не попадет в кеш (если таблица довольно большая).
При запросах тоже часто приходится запрашивать последние данные (горячие). В случае если добавление в индекс идет только с одной стороны горячие данные лежат рядом, как следствие с большей вероятностью попадут в кеш и не будут оттуда вымыты.
Если ключи распределены равномерно - в некоторых случаях сделать больше чтений. Например если индекс кластерный, данные тоже будут распределены равномерно по диску, а с учетом того что читается сразу блок данных, это приводит к read amplification.
Далее, если положить рядом много одинаковых данных, некоторые БД умеют эти данные очень хорошо сжимать (см clickhouse). Индексы тоже получатся более компактными, что приведет к более быстрому поиску. В общем тут разве что возникает вопрос - почему в UUID изначально не был спроектирован с использованием человеческого unix timestampt
Это да, тут соглашусь. И на самом деле есть прогресс в этом направлении. Тот же драйвер сканера отпечатка пальца может работать от пользователя и вообще написан python (python-validity). Тут больше наверное вопрос в том, как предоставлять доступ для остальных программ. Т.е. сейчас, в основном, используется sysfs/procfs, но по идее можно же и как-то предоставить через другое место?
К примеру, в PHP или JS при работе со строками не возникает переполнения буфера, так как вся работа идет через абстракции, а не через прямую работу с указателями.
Так ядро это как раз та штука которая порождает абстракции. Что делать если у вас внутри абстракции которая обрабатывает строки кончится память (физическая)? В текущий момент размер строки может быть задан статически, что исключает внезапное окончание памяти. Плюс есть гарантия скорости исполнения ядерного кода за счет миниизации внутренний абстракций (что как-бы критично).
Также, в Линукс огромный объем кода работает в ядре — с наивысшим уровнем привилегий. Линукс содержит тысячи драйверов, и это расширяет поверхность атаки. Линукс не предпринимает мер для понижения привилегий и изоляции кода драйверов. Уязвимость в любом из драйверов позволяет получить максимальные привилегии в системе.
Это как раз следствие простоты ядра. Вы предлагаете тащить туда какой-то хитрый контроль доступа? А зачем? Представляете насколько это замедлит скорость обработки для тех же десятигигабитных интерфейсов?
Опять таки в некоторых случаях есть всякие fuse, где вы можете писать драйвера ФС на уровне пользователя. Это медленно, но работает.
Возможно, "опасный" код дает чуть большую производительность. Но нужен ли вам прирост производительности на несколько процентов, если с ним идет куча уязвимостей?
Чуть большую? Опять троллите? Как пример патчи от spectre/melltdown дали нам 30% падения производительности. И это без изменения стиля программирования. Опасный код пишут не просто так. Если у вас будет "безопасный" код в коде планировщика задач, например - все может значительно замедлиться. Я бы сказал что там не несколько процентов, а процентов 30-60, потому что есть критичные куски кода.
В iPhone после загрузки ядра в память область кода ядра аппаратно необратимо блокируется на запись, и защиту можно снять только перезагрузкой. Код, управляющий таблицами страниц, также защищен от записи, и специальные аппаратные меры приняты, чтобы таблицами страниц нельзя было управлять из другого места. А что Линукс на PC? Память ядра не защищена аппаратно, доступ к таблицам страниц не защищен.
А в iPhone вы можете добавить модули ядра без перезагрузки? Может пропатчить от уязвимостей на лету? Для iphone критичен аптайм?
Безопасный код не идет даром. В том же rust мы расплачиваемся скоростью компиляции. И опять таки, для производительного кода приходится использовать unsafe.
А вообще рекомендую почитать книгу Робет Лав - Ядро Linux: Описание процесса разработки. Ядро реально простое. Хотя бы почитайте раздел: `Отличия от обычных приложений`
Понимаете в чем дело... К антивакцинаторам относились как к малым детям, которые не умеют в фактчекинг и аппелируют в основном к эмоциям. В то же время те кто за вакцины были такого типа.
То есть здравые рассуждения без безкомпромисных суждений и сто процентной уверенности. Отличные статьи, которые давали пищу для рассуждений и по сути играли на пользу вакцинации. Без пиара конкретных типов вакцин.
Но тут врывается данный цикл статей с безаппеляционными утверждениями (особенно про мифы) и давлением на эмоции. И все заверте...
В итоге комменты превратились в метание говном двух стай макак. Редкие проблески разумных комментов покрываются частицами снарядов с обоих сторон.
Точно нет? По логике должна быть. Как минимум после смерти аннулируется паспорт, отменяется пенсия и прочее. Опять таки откуда-то берется же статистика по смертности. Да, причина смерти может не фигурировать в общей БД, но здесь то она и не нужна?
Аргумент за - часть данных можно получить через портал госуслуг, т.е. как-то оно туда попадает (смэв?).
Да как не верифицируемую? Это верифицируется как в локальном плане (задать вопрос кто умер?) так и в глобальном плане: На госуслугах у нас после прививки вроде как появляется отметка о вакцинации.
Также у государства есть БД ЗАГС о смерти. Берем среднюю смертность в России (или в регионе), сравниваем со средней смертностью среди тех кто вакцинировался. Если у тех кто вакцинировался смертность ниже - вакцина работает. Если выше - ну значит побочки реально опаснее короны. Если смерность примерно одинаковая - тут серая зона. Сравнивать конечно надо с учетом половозрастного состава. В идеале конечно бы предоставить сырые данные, сагреггированные например по региону, полу и возрасту, чтобы каждый мог проверить.
Проблема то в том что скептики вакцинации иногда пишут вполне легковерифицируемые вещи (а значит научные по критерию Поппера). А в ответ несется затыкание ртов, клеймение, итд вместо красивых графиков и статистики с опровержением. Да, совсем упертых этим не убедишь, но когда с другой стороны несется такое же натягивание совы на глобус как например "мы начали вакцинацию и она мгновенно остановила эпидемию" - перестаешь верить обоим сторонам. А когда нет доверия логичное действие - бездействие.
Да может мало статистики внутри РФ по побочкам, но смертность граждан это то, что собирается железно.
А вас не смущает что при R0 в районе 6-8 у дельты (а это между прочим показатель экспоненты!) и при этом как стали наплевательски относиться к маскам как раз и получается что за месяц-два переболеют процентов 60-80 населения? Что дает нам естественным образом падение регистрируемых случаев.
Также не смущает что по вашим же словам защитный эффект начинает проявляться с 14 и достигает максимума на 42 сутки? То есть вакцинация как-бы тут по вашей же прошлой статье слабо коррелирует, не?
Про Мифы 12 и 13 (влияние на иммунитет и почему может быть не лучшей идеей прививаться в разгар пандемии)
В Мифе 12 было опровергнуто долговременное влияние на иммунитет. Про краткосрочное влияние ничего нет.
Мне вот почему-то кажется что вакцина в кратковременном интервале дает нагрузку на иммунную систему. Причем спутник по логике дает нагрузку на два фронта: подбор антител от белка-шипа и от аденовируса. С учетом вашей прошлой же статьи где написано что антитела начинают образовываться на 14 день получается что первые 14 дней естественная защита проседает (организм борется на два фронта) и для того чтобы заболеть достаточно меньшей дозы вируса. А с учетом того что у нас как раз месяц назад был пик пандемии шансы получить эту дозу довольно высоки.
При этом я не против вакцинации (и исходя из вышеописанной логике в данный момент как раз хорошее время её поставить), но когда говорят только о плюсах и только о них без рассмотрения другой стороны это выглядит весьма стрёмно и довольно непрофессионально.
Есть детекторы руткитов же. Вряд ли крутые приватные штуки сильно распространены, это невыгодно.
А иначе, если рассуждать на том же уровне паранойи - если имеются подозрения о взломе надо выкидывать сервак, т.к. настоящий хакер пропатчит BIOS и добавит efi-модуль, который после переустановки системы будет заново устанавливать руткит.
Или вот гипервизор как efi-модуль поставит например. И все ОС которые будут ставиться в будущем будут под гипервизором сидеть.
Есть же ssh honeypot [cowrie](https://github.com/cowrie/cowrie), который еще и сочетается с smtp honeypot [mailoney](https://github.com/awhitehatter/mailoney). В свое время были разные сценарии после подбора: кто-то пытался запустить майнер, кто-то просто удалял все данные, а кто-то пытался использовать как прокси к публичным smtp-серверам для рассылки спама. Настраивал редирект на локальный smtp-honeypot, смторел что шлют и куда. Заоодно хорошее дело - спамер думает что письма отправлены и потенциально будет меньше слать.
Если хостер не на стороне админа - это плохой хостер. Потому что зачем мне хостер который не на моей стороны и не помогает мне решать проблемы. Вот так все просто
К сожалению такие правила ICAN. И блокируют все днс хостеры. И в данном случае все правильно сделано. Есть спорные случаи с трансфером домена, когда хостер принимает трансфер без требования подтверждения документов и потом блочит через 15 дней. Но в описанном сценарии все правильно. Нет подтверждения документов в течение установленного срока - бан. Захочешь разбана - пришлешь документы. По другому, как видите, никак.
Нагляднее так: драйвер стабилизирует напряжение на этом резисторе, тем самым задавая ток в цепи. При выкусывании одного резистора напряжение на оставшемся будет таким же, как и мощность выделяющаяся на нем (но итоговая упадет в два раза, да, т.к. резисторов стало меньше).
Да похоже все регистраторы такие. Классика - заводишь домен (или делаешь трансфер), вроде все ок. А через две недели тебе паузят домен. Когда по хорошему надо вообще не давать делать действия с доменом до подтверждения данных.
Вы серьезно? У ребенка есть физический доступ к компу и он пойдет таким диким путем? В нашем детстве это обходилось скачиванием liveCD, загрузкой с него и выдачей себе полных прав. И не надо выдумывать себе диких предварительных условий.
Если стоит пароль на биос - это все равно обходится. Единственно что - это может быть сценарием атаки если диск зашифрован и для загрузки надо вводить пароль. Но у таких людей и комп как правило не шарится с детьми.
Похоже на взаимодействие хакера и солонки, не? В том плане что если есть доступ к компу то оттуда и так утащат все самое ценное (пароли, сессии браузера, банковские аккаунты и прочее). Врядли кто-то заморачивается с отдельным аккаунтом на одном компе для игр. Опять таки непривилегированная учетка позволит запустить условный майнинг, или устроить условный dDoS.
А там где повышение привилегий опасно (корпоративная сеть), там и так политиками запрещено ставить левые программы.
И дело не в том чтобы умалить ваши заслуги, работа проделана значительная, просто нельзя ли выбрать более адекватные цели для исследования? В данный момент выглядит как шантаж на выплату баг баунти. (И, со стороны напоминает подход индопакистанских ребятушек которые пишут про отсутствие всяких днс записей типа DMARC/CAA, которые 99.9% не нужны).
volatile-lru — вытеснение недавно используемых ключей, у которых задан срок действия;
allkeys-lru — вытеснение недавно используемых ключей;
volatile-lfu — вытеснение наиболее часто используемых ключей, у которых задан срок действия;
allkeys-lfu — вытеснение наиболее часто используемых ключей;
Вы бы статью давали вычитать кому-то… Из доки:
volatile-lru — Evicts the least recently used keys out of all keys with an “expire” field set
volatile-lfu — Evicts the least frequently used keys out of all keys with an “expire” field set
Каким образом least у вас принял обратное значение? Причем даже в доку смотреть не надо, достаточно включить логику: зачем удалять наиболее часто используемые ключи?
у вас двоемыслие какое-то.
Повысить пропускную способность можно либо расширение трубы (больше полос) либо упаковка поплотнее (общественный транспорт). Можно повысить привлекательность общественного транспорта (увеличивая тем самым пропускную способность) увеличив количество маршрутов и количество рейсов, сделать ему выделенную полосу.
Но просто уменьшать количество полос = уменьшить пропускную способность ака ухудшить организацию перемещения большого количества людей.
Зачем уменьшать количество полос? Так уменьшается пропускная способность, но не уменьшается скорость (наоборот для той же пропускной способности надо быстрее ехать). Может наоборот больше полос (больше пропускная способность что для города актуально), но каждые 100 метров по лежачему полицейскому (меньше скорость)?
А то все эти высказывания и аргументы про то что средняя скорость по городу 30км/ч - давайте значит уменьшим количество полос сродни менеджерским оптимизациям типа: в фановой трубе туалета в среднем за минуту проходит 3л воды, а труба широкая - давайте уменьшим, сэкономим. А то что там пики потребления бывают - это же думать надо, это не про нас.
Сам удивился и залип пытаясь понять. В общем они используют bigint(20) для primary key и
idbinary(16) для UUID. Из за того что в mysql primary key кластеризован и вторичные индексы указывают на primary key примерно так и выходит.Размер индексов это вторичных, т.к. первичный это и есть сама таблица.
этих
KEY
index_events_on_actioned_at(actioned_at),KEY
index_events_unit_demand_partner(unit_id,demand_partner_id)---
upd, наврал. bigint(20) все так же занимает 8 байт. Проблема в том что в этом тесте для Bigint есть лишний индекс: primary - count (bigint), плюс индекс на поле id.
Не говорил про разделение блоков, скорее расширение. У вас же не всегда есть место для новой записи. То есть при вставке все равно приходится раздвигать текущие блоки. (или менять ссылку если реализация на связном списке, что врядли используется для индексов, т.к. в индексе по своей похожие данные должны лежать рядом). Что приводит к увеличению записи. Плюс есть детали имплементации на всяких системах (wal, etc). Есть факт что не UUID без инкрементальной составляющей это боль и тормоза на большинстве систем.
Ок, пример из mysql https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/
скриншот
For the table with UUID as PRIMARY KEY, you can notice that as the table grows big, the time taken to insert rows is increasing almost linearly. Whereas for other tables, the time taken is almost constant.
The size of the UUID table is almost 50% bigger than Ordered UUID table and 30% bigger than the table with BIGINT as PRIMARY KEY. Comparing the Ordered UUID table BIGINT table, the time is taken to insert rows and the size are almost the same. But they may vary slightly based on the index structure.
Подтвержено чем? Вот тут бенчмарк с графиками https://habr.com/ru/company/ozontech/blog/564520/. Условно WAL - количество измененных данных
скриншот
Не верим этой статье - пожалуйста, другая: https://habr.com/ru/post/316036/
скриншот
Зависит от сценария. Но суть том не в ток как часто пишу я, а в том как часто пишет его БД. В случае последовательного uuid будет писать часто, в результате оверхед от хранения первых байт UUID в индексе может быть меньше.
Да, но проблема в физике: при вставке придется идти в кучу мест на диске, расширять блоки. При этом это вызовет дополнительные чтения с диска, т.к. надо найти место куда вставлять данные, скорее всего это не попадет в кеш (если таблица довольно большая).
При запросах тоже часто приходится запрашивать последние данные (горячие). В случае если добавление в индекс идет только с одной стороны горячие данные лежат рядом, как следствие с большей вероятностью попадут в кеш и не будут оттуда вымыты.
Если ключи распределены равномерно - в некоторых случаях сделать больше чтений. Например если индекс кластерный, данные тоже будут распределены равномерно по диску, а с учетом того что читается сразу блок данных, это приводит к read amplification.
Далее, если положить рядом много одинаковых данных, некоторые БД умеют эти данные очень хорошо сжимать (см clickhouse). Индексы тоже получатся более компактными, что приведет к более быстрому поиску. В общем тут разве что возникает вопрос - почему в UUID изначально не был спроектирован с использованием человеческого unix timestampt
Это да, тут соглашусь. И на самом деле есть прогресс в этом направлении. Тот же драйвер сканера отпечатка пальца может работать от пользователя и вообще написан python (python-validity). Тут больше наверное вопрос в том, как предоставлять доступ для остальных программ. Т.е. сейчас, в основном, используется sysfs/procfs, но по идее можно же и как-то предоставить через другое место?
Вы должно быть троллите?
Так ядро это как раз та штука которая порождает абстракции. Что делать если у вас внутри абстракции которая обрабатывает строки кончится память (физическая)? В текущий момент размер строки может быть задан статически, что исключает внезапное окончание памяти. Плюс есть гарантия скорости исполнения ядерного кода за счет миниизации внутренний абстракций (что как-бы критично).
Это как раз следствие простоты ядра. Вы предлагаете тащить туда какой-то хитрый контроль доступа? А зачем? Представляете насколько это замедлит скорость обработки для тех же десятигигабитных интерфейсов?
Опять таки в некоторых случаях есть всякие fuse, где вы можете писать драйвера ФС на уровне пользователя. Это медленно, но работает.
Чуть большую? Опять троллите? Как пример патчи от spectre/melltdown дали нам 30% падения производительности. И это без изменения стиля программирования. Опасный код пишут не просто так. Если у вас будет "безопасный" код в коде планировщика задач, например - все может значительно замедлиться. Я бы сказал что там не несколько процентов, а процентов 30-60, потому что есть критичные куски кода.
А в iPhone вы можете добавить модули ядра без перезагрузки? Может пропатчить от уязвимостей на лету? Для iphone критичен аптайм?
Безопасный код не идет даром. В том же rust мы расплачиваемся скоростью компиляции. И опять таки, для производительного кода приходится использовать unsafe.
А вообще рекомендую почитать книгу Робет Лав - Ядро Linux: Описание процесса разработки. Ядро реально простое. Хотя бы почитайте раздел: `Отличия от обычных приложений`
Понимаете в чем дело... К антивакцинаторам относились как к малым детям, которые не умеют в фактчекинг и аппелируют в основном к эмоциям. В то же время те кто за вакцины были такого типа.
https://habr.com/ru/post/535626/
https://habr.com/ru/post/538850/
То есть здравые рассуждения без безкомпромисных суждений и сто процентной уверенности. Отличные статьи, которые давали пищу для рассуждений и по сути играли на пользу вакцинации. Без пиара конкретных типов вакцин.
Но тут врывается данный цикл статей с безаппеляционными утверждениями (особенно про мифы) и давлением на эмоции. И все заверте...
В итоге комменты превратились в метание говном двух стай макак. Редкие проблески разумных комментов покрываются частицами снарядов с обоих сторон.
Точно нет? По логике должна быть. Как минимум после смерти аннулируется паспорт, отменяется пенсия и прочее. Опять таки откуда-то берется же статистика по смертности. Да, причина смерти может не фигурировать в общей БД, но здесь то она и не нужна?
Аргумент за - часть данных можно получить через портал госуслуг, т.е. как-то оно туда попадает (смэв?).
Да как не верифицируемую? Это верифицируется как в локальном плане (задать вопрос кто умер?) так и в глобальном плане: На госуслугах у нас после прививки вроде как появляется отметка о вакцинации.
Также у государства есть БД ЗАГС о смерти. Берем среднюю смертность в России (или в регионе), сравниваем со средней смертностью среди тех кто вакцинировался. Если у тех кто вакцинировался смертность ниже - вакцина работает. Если выше - ну значит побочки реально опаснее короны. Если смерность примерно одинаковая - тут серая зона. Сравнивать конечно надо с учетом половозрастного состава. В идеале конечно бы предоставить сырые данные, сагреггированные например по региону, полу и возрасту, чтобы каждый мог проверить.
Проблема то в том что скептики вакцинации иногда пишут вполне легковерифицируемые вещи (а значит научные по критерию Поппера). А в ответ несется затыкание ртов, клеймение, итд вместо красивых графиков и статистики с опровержением. Да, совсем упертых этим не убедишь, но когда с другой стороны несется такое же натягивание совы на глобус как например "мы начали вакцинацию и она мгновенно остановила эпидемию" - перестаешь верить обоим сторонам. А когда нет доверия логичное действие - бездействие.
Да может мало статистики внутри РФ по побочкам, но смертность граждан это то, что собирается железно.
А вас не смущает что при R0 в районе 6-8 у дельты (а это между прочим показатель экспоненты!) и при этом как стали наплевательски относиться к маскам как раз и получается что за месяц-два переболеют процентов 60-80 населения? Что дает нам естественным образом падение регистрируемых случаев.
Также не смущает что по вашим же словам защитный эффект начинает проявляться с 14 и достигает максимума на 42 сутки? То есть вакцинация как-бы тут по вашей же прошлой статье слабо коррелирует, не?
Про Мифы 12 и 13 (влияние на иммунитет и почему может быть не лучшей идеей прививаться в разгар пандемии)
В Мифе 12 было опровергнуто долговременное влияние на иммунитет. Про краткосрочное влияние ничего нет.
Мне вот почему-то кажется что вакцина в кратковременном интервале дает нагрузку на иммунную систему. Причем спутник по логике дает нагрузку на два фронта: подбор антител от белка-шипа и от аденовируса. С учетом вашей прошлой же статьи где написано что антитела начинают образовываться на 14 день получается что первые 14 дней естественная защита проседает (организм борется на два фронта) и для того чтобы заболеть достаточно меньшей дозы вируса. А с учетом того что у нас как раз месяц назад был пик пандемии шансы получить эту дозу довольно высоки.
При этом я не против вакцинации (и исходя из вышеописанной логике в данный момент как раз хорошее время её поставить), но когда говорят только о плюсах и только о них без рассмотрения другой стороны это выглядит весьма стрёмно и довольно непрофессионально.
Есть детекторы руткитов же. Вряд ли крутые приватные штуки сильно распространены, это невыгодно.
А иначе, если рассуждать на том же уровне паранойи - если имеются подозрения о взломе надо выкидывать сервак, т.к. настоящий хакер пропатчит BIOS и добавит efi-модуль, который после переустановки системы будет заново устанавливать руткит.
Или вот гипервизор как efi-модуль поставит например. И все ОС которые будут ставиться в будущем будут под гипервизором сидеть.
Есть же ssh honeypot [cowrie](https://github.com/cowrie/cowrie), который еще и сочетается с smtp honeypot [mailoney](https://github.com/awhitehatter/mailoney). В свое время были разные сценарии после подбора: кто-то пытался запустить майнер, кто-то просто удалял все данные, а кто-то пытался использовать как прокси к публичным smtp-серверам для рассылки спама. Настраивал редирект на локальный smtp-honeypot, смторел что шлют и куда. Заоодно хорошее дело - спамер думает что письма отправлены и потенциально будет меньше слать.
https://hostpapasupport.com/about-icanns-new-domain-verification-rules/
https://ru.godaddy.com/help/verifying-contact-information-for-icann-validation-8948
К сожалению такие правила ICAN. И блокируют все днс хостеры. И в данном случае все правильно сделано. Есть спорные случаи с трансфером домена, когда хостер принимает трансфер без требования подтверждения документов и потом блочит через 15 дней. Но в описанном сценарии все правильно. Нет подтверждения документов в течение установленного срока - бан. Захочешь разбана - пришлешь документы. По другому, как видите, никак.
Нагляднее так: драйвер стабилизирует напряжение на этом резисторе, тем самым задавая ток в цепи. При выкусывании одного резистора напряжение на оставшемся будет таким же, как и мощность выделяющаяся на нем (но итоговая упадет в два раза, да, т.к. резисторов стало меньше).
Да похоже все регистраторы такие. Классика - заводишь домен (или делаешь трансфер), вроде все ок. А через две недели тебе паузят домен. Когда по хорошему надо вообще не давать делать действия с доменом до подтверждения данных.
Вы серьезно? У ребенка есть физический доступ к компу и он пойдет таким диким путем? В нашем детстве это обходилось скачиванием liveCD, загрузкой с него и выдачей себе полных прав. И не надо выдумывать себе диких предварительных условий.
Если стоит пароль на биос - это все равно обходится. Единственно что - это может быть сценарием атаки если диск зашифрован и для загрузки надо вводить пароль. Но у таких людей и комп как правило не шарится с детьми.
Похоже на взаимодействие хакера и солонки, не? В том плане что если есть доступ к компу то оттуда и так утащат все самое ценное (пароли, сессии браузера, банковские аккаунты и прочее). Врядли кто-то заморачивается с отдельным аккаунтом на одном компе для игр. Опять таки непривилегированная учетка позволит запустить условный майнинг, или устроить условный dDoS.
А там где повышение привилегий опасно (корпоративная сеть), там и так политиками запрещено ставить левые программы.
И дело не в том чтобы умалить ваши заслуги, работа проделана значительная, просто нельзя ли выбрать более адекватные цели для исследования? В данный момент выглядит как шантаж на выплату баг баунти. (И, со стороны напоминает подход индопакистанских ребятушек которые пишут про отсутствие всяких днс записей типа DMARC/CAA, которые 99.9% не нужны).
Вы бы статью давали вычитать кому-то… Из доки:
volatile-lru — Evicts the least recently used keys out of all keys with an “expire” field set
volatile-lfu — Evicts the least frequently used keys out of all keys with an “expire” field set
Каким образом least у вас принял обратное значение? Причем даже в доку смотреть не надо, достаточно включить логику: зачем удалять наиболее часто используемые ключи?