Суть в том, что разрешить значение null и разрешить отсутствие поля — это разные вещи.
Это действительно разные вещи, но вы их совершенно неверно трактуете:
Отсутствие поля = оно не определено в структуре/классе.
Если же поле определено, то оно "всегда есть", и в случае nullable может иметь значение NULL.
Отступление от этого принципа ведет в тупик (требует разных NULL'ей, приводит к семантической путанице/неоднозначности). Это регулярно демонстрирует JSON (и другие "текстовые" языки описания данных).
В этом ключе, пример с update не корректен, точнее говоря налицо проблема в дизайне API.
Отминусовал: по-факту fud-перевод fud-заметки по fud-заявлению Check Point.
В сопричастных к теме кругах есть три общеизвестных факта:
Без ключей не расшифровать. Если конечно авторы шифровальщика где-то не налагали, что достаточно редко. А если случается то "дятлы Касперского" относительно быстро выпускают инструменты для расшифровки.
Для 80% платежеспособных пострадавших от шифровальщиков за восстановление, мягко говоря, удобнее официально заплатить посреднику. Причем маржа посредников определяется/ограничивается, прежде всего, конкуренцией среди этих посредников.
"Доктор ноль" (полный перевод греческого и арабского корней "Dr. Shifro") давным-давно известная контора, со специфичной, но ПОНЯТНОЙ бизнес-моделью. При желании таких можно найти еще десяток, начиная с упомянутой Сoveware.
Конечно, шифровальщикам платить не стоит. Однако, когда дело оборачивается потерей данных и репутации, приоритеты "внезапно" у пострадавших меняются. Поэтому всяческих "докторов нуль" можно упрекнуть только в том, что они не говорят об этом явно, сразу и в лоб. Хотя постойте, откуда же "недовольные клиенты" и кто-то в CheckPoint узнали об этом?
Получается, что Dr. Shifro плохие, из-за того что все-таки говорят что делают, а всякие Сoveware хорошие, потому что тупо не сознаются в очевидном? — Вот это лично меня и раздражает в данном случае.
Камрады напомнили и попросили показать слайд сравнения "теплого с мягким" с прошлого Highload++:
Тем не менее, это данные реального теста. Если мне не изменяет память, то это результат make bench-quartet на моем старом ноуте. Для воспроизведения достаточно собрать ioarena, а потом выполнить make bench-quartet в поддиректории db/mdbx.
Внутри B+Tree без WAL, поэтому WAF имеет OlogN зависимость от объема данных. Но многое зависит от сценария использования:
Если вставка идет в порядке возрастания ключей, то разница с RocksDB уже совсем не большая.
Если допустимы потери при вылете ядра или отключении питания, то на порядок-другой быстрее.
MDBX (но не LMDB) умеет LIFO_RECLAIM, что минимизирует набор горячих страниц/секторов, соответственно "writeback кеш с батарейкой" даёт на порядок больше.
мы будем прикручивать "входящую очередь" на основе MDBX к нашему Hiper100re (пока закрытая переделка ClickHouse).
libmdbx спокойно выдерживает 10K-1000K вставок (зависит от размера записей).
на диск конечно каждое изменение не персистится, но есть чекпоинты и ничего не теряется если не падает ядро ОС (и не выключается питание). Либо нужен writeback c батарейкой.
Почему как вы думаете Ryzen отказался от всех AMD-специфических 3DNow! и всяких XOP-инструкций? Они ж вроде не такие сложные были? Ответ: да — для ALU они не были уж очень сложными, но их очень тяжело декодировать. Добавьте сюда их малопопулярность… и вывод очевиден…
По сути вы правы, но хочу немного уточнить:
Поддержка этих инструкций действительно требовала ресурсов кристалла в основном именно для декодирования, но и плюс затраты (нельзя назвать несущественными) на внешне небольшую разницу в поведении.
При этом рынок всё равно требует поддержки Intel-овских кодов. Получалось что AMD приходилось носить два "чемодана с батарейками", причем это затраты не только внутри кристалла, но и на всех этапах дизайна / разработки / верификации.
В январе я делал обзор по персданным на рынке дарквеба. Все там хорошо с нероссийскими, просто аффтар данной заметки слишком увлечен борьбой с режЫмом. Кстати, по русский пишется «на Украине», хотя смысл неправильного написания понятен — это их борьба…
Согласен, именно так. Причем статья для наивных хомячков в духе "левиафана".
К слову, подобной персональной инфы на граждан "самой демократической и безопасной" страны в разы больше ;)
Не нужно никакого нового процессора.
Достаточно простой, очевидный и безусловно надежный способ уже описан в патентной заявке.
Пока сложно сказать у кого будет патентный приоритет, но разработчики Эльбруса в курсе.
Поэтому надеюсь что приоритет будет за ними.
Это действительно разные вещи, но вы их совершенно неверно трактуете:
Отступление от этого принципа ведет в тупик (требует разных NULL'ей, приводит к семантической путанице/неоднозначности). Это регулярно демонстрирует JSON (и другие "текстовые" языки описания данных).
В этом ключе, пример с update не корректен, точнее говоря налицо проблема в дизайне API.
@НЛО, а можно попросить feature "развидеть" = не видеть "статей" от выбранных аккаунтов?
Почему эта статья, а не заявление в полицию/прокуратуру (еще лучше коллективное)?
Иск в суд...?
Отминусовал: по-факту fud-перевод fud-заметки по fud-заявлению Check Point.
В сопричастных к теме кругах есть три общеизвестных факта:
Конечно, шифровальщикам платить не стоит. Однако, когда дело оборачивается потерей данных и репутации, приоритеты "внезапно" у пострадавших меняются. Поэтому всяческих "докторов нуль" можно упрекнуть только в том, что они не говорят об этом явно, сразу и в лоб. Хотя постойте, откуда же "недовольные клиенты" и кто-то в CheckPoint узнали об этом?
Получается, что Dr. Shifro плохие, из-за того что все-таки говорят что делают, а всякие Сoveware хорошие, потому что тупо не сознаются в очевидном? — Вот это лично меня и раздражает в данном случае.
ptsecurity, а может на PHD2019 устроить показательный взлом/обман ЕБС?
Камрады напомнили и попросили показать слайд сравнения "теплого с мягким" с прошлого Highload++:
Тем не менее, это данные реального теста. Если мне не изменяет память, то это результат
make bench-quartetна моем старом ноуте. Для воспроизведения достаточно собрать ioarena, а потом выполнитьmake bench-quartetв поддиректорииdb/mdbx.В ближайший четверг (2018-11-29) буду с этой темой на Технологии управления данными от "Открытых Систем".
Внутри B+Tree без WAL, поэтому WAF имеет OlogN зависимость от объема данных. Но многое зависит от сценария использования:
На всякий случай, вдруг пригодится:
По сути вы правы, но хочу немного уточнить:
Поддержка этих инструкций действительно требовала ресурсов кристалла в основном именно для декодирования, но и плюс затраты (нельзя назвать несущественными) на внешне небольшую разницу в поведении.
При этом рынок всё равно требует поддержки Intel-овских кодов. Получалось что AMD приходилось носить два "чемодана с батарейками", причем это затраты не только внутри кристалла, но и на всех этапах дизайна / разработки / верификации.
Согласен, именно так. Причем статья для наивных хомячков в духе "левиафана".
К слову, подобной персональной инфы на граждан "самой демократической и безопасной" страны в разы больше ;)
Просится в подзаголовок книги о Java ;)
C++ плохой, потому что даже разработчики JDK не умею им пользоваться.
olegchir, давай подписывайся под тезисом и можно будет расходится ;)
Достаточно простой, очевидный и безусловно надежный способ уже описан в патентной заявке.
Пока сложно сказать у кого будет патентный приоритет, но разработчики Эльбруса в курсе.
Поэтому надеюсь что приоритет будет за ними.
Игореха — ержи пять
;)