В реальной жизни есть некоторые нюансы — а именно:
выбор очень ограничен, что особенно актуально для тех кто работает в небольшом коллективе (или вообще фрилансит) и не любит тусовки или многолюдные мероприятия — соответственно ищет примерно такую же пару;
нет никаких гарантий что человек которым вы заинтересовались вообще заинтересован в знакомстве (не говоря уже про отношения);
кроме внешнего вида (и изредка рода занятий/хобби) вы не имеете вообще никакой информации о человеке — хотя бы очень упрощенном круге интересов и/или предпочтений (к примеру — веганы часто не любят мясоедов, совы — жаворонков, и т.п.).
В общем, реальная жизнь это хорошо если круг общения очень широк или как минимум постоянно меняется, при этом человек легко может общаться с кем угодно и этот самый круг идёт на контакт — но это так далеко не у всех, так что виртуальные знакомства вполне имеют смысл, ибо буквально без усилий дают широкий круг общения (который в реальной жизни в принципе недостижим) и возможность фильтрации (если это важно).
Это конечно круто когда всё супершустро, но для подобных задач "очень" понятие весьма условное — если вы собираете образ раз в час, да пусть даже раз в 15 минут, то не особо важно — это 10 секунд или 10 миллисекунд.
Образы обычно создаются редко но надолго, даже для процесса разработки и отладки этих образов 10 секунд это ничто (на фоне остальных затрат времени), не говоря уже о том что время загрузки (с учётом инициализации всего железа, POST etc) часто составляет не менее пары минут — куда тут спешить со сборкой?
Честно говоря, с трудом себе представляю где это может быть критично — разве что речь про "сборка образов как услуга", или каком-то супер-пупер кластере виртуалок из десятков-сотен машин где загрузочные образы генеряются на лету а виртуалки (пере)создаются каждую минуту или чаще с разными требованиями — но как раз для этого случая проще всё решать на лету, а не создавать образы.
Для некоторых это и есть настоящая жизнь. Если для кого-то "настоящая" это (к примеру) путешествия, семья, еда, спорт — то нет совершенного ничего необычного что для кого-то ещё это программирование, как хобби оно ничем не хуже фотографии, рисования или шахмат.
Да, большинство работает чтобы жить, но всё же есть ощутимая прослойка тех кто живет чтобы работать (причем не только айтишники), просто им платят за то что они делали бы бесплатно "для себя", и в семейной жизни у них проблем не больше чем у других (а то и меньше).
В общем, «Выбери себе работу по душе, и тебе не придется работать ни одного дня в своей жизни», так что пенсия в безопасности.
Пауза на клиенте с идеей PoW гораздо проще, мне кажется.
Пауза — это открытое соединение, ценный ресурс. Гораздо проще по достижении лимита вплоть до исчерпания времени паузы все запросы отбивать с кодами 429 или 503 и установкой заголовка Retry-After для индикации оставшегося времени ожидания, а особо упорных (которые продолжают слать запросы до его истечения) — банить жёстко.
Хотя, честно говоря, все эти ожидания и прочие лимиты, включая PoW мало помогают против "продвинутых" ломателей — ко мне приходили целые полчища ботов, притворялись полноценными клиентами (js, все дела) — в логах это видно как один-два запроса в секунду на логин, с одного IP пробуют ровно одну пару, максимум две — и он не пытается больше в ближайшие сутки. Да, скорость перебора так себе, но оно ж кушать не просит и не торопится, а банить — по какому критерию? Настоящие пользователи тоже ошибаются, в час обычно парочка пробует с пяток имен-паролей к своим аккаунтам — потому что забывают либо пароли либо как именно зарегистрированы.
клиенту не нужно поддерживать открытое подключение и ждать пакеты ACK, подтверждающие доставку сообщений
Да, но вместо ACK у нас есть GRANT — другое название но такая же функция. Если взять старый добрый RUDP (который так и не стал RFC но всё же использовался) то будет почти то же самое — соединения не надо поддерживать, а детали можно подкрутить.
Это вацапу нужно доказывать, что у них всё чин-чинарём.
Ну Дурову ж вы верите про сервера? С одной стороны правильно говорите, а с другой всё ж как-то непоследовательно.
Понятно, что никакого плейнтекста там нет, но и как именно обрабатываются сообщения вам неизвестно.
Если они уходят зашифрованными ключём который не покидает моё устройство, причем шифруется проверенным протоколом (а он проверен) — практически безразлично как они обрабатывается за пределами устройства. Это примерно как хранить зашифрованный файл на Dropbox — всё равно что они с ним делают.
мы достоверно знаем, что воцап пересылает зарепорченные сообщения дежурным индусам
Эээ… ну тут как бы WA не при чём — потому что тот кто его получил однозначно имеет его в расшифрованном виде, и репортит уже плейнтекстом — что более чем логично.
секьюрность, которую предоставляет проприетарное приложение, мнимая
Под этим соусом можно вообще 90% всего что есть выбросить — от софта (все реализации VPN в железках) до железа (HSM жалобно плачут), единственная безопасная вещь в плане коммуникаций — это телепатия, и то с оговорками.
и даже телеграм со всеми его недостатками и возможностью чтения обычных сообщений сервером на голову выше
Если кто-то, кроме получателя и меня может читать сообщения за пределами наших устройств — это само по себе такая дыра что все остальные плюсы никогда не приведут баланс хотя бы к нулю. Для домохозяек с кошечками, конечно, малоактуально, но речь-то не о них, а на территории стран СНГ телеграм используется многими от полиции до судей, включая пересылку документов — вот как-то не верю я в то что эта золотая жила никем не прорабатывается. Причём, что примечательно, Дуров вложил немалые усилия в рекламу телеграма именно как "безопасного и приватного", хотя по умолчанию, без уже упомянутых выше телодвижений и ограничений это верно на -1% (кроме уже упомянутых домохозяинов).
Т. е. то, что уже есть, например, в Matrix. Только проприетарное
Это если у вас есть возможность и квалификация поставить свой сервер, поддерживать его и обеспечивать безопасность. И если есть дар убеждения или власть заставить его использовать всех с кем вы общаетесь. И ещё много всяких если — в то время как WA, при всей их непушистости, вряд-ли пойдут на явный или даже замаскированный обман в плане шифрования и доступа к данным — потому что это всплывёт неизбежно, а когда всплывёт — то потеряют они намного больше чем приобретут.
Чем вам Signal-то не угодил? Он же дублирует воцап по функционалу.
Он мне очень нравится. Ну ок, почти очень. Но есть пара неприятных и весьма важных моментов:
невозможно заставить всех из моего круга общения (в том числе многих клиентов) поставить Signal, а WA у них уже есть (причём у некоторых и он со скрипом, не любят они мессенжеры, не говоря уже о зоопарке оных);
уже упомянутая мной невозможность синхронизации на разных устройствах (и даже не планируемая) — которая уже есть в WA;
Whatsapp впринципе не имеет ничего общего с безопасностью — он проприетарный. Иными словами, он как минимум читает все сообщения и хранит их копии на серверах.
Откуда дровишки? Сообщения хранятся на серверах (в зашифрованном виде — т.е. сервер их не может прочитать) до момента попадания на устройство получателя. Телеграм же по умолчанию получает сообщения в открытом виде, и они хранятся на его серверах доступными для чтения кому-нужно.
Де факто, они могут слать сообщения плейнтектом — вы не сможете проверить.
Их протоколы известны, отреверсены и даже есть альтернативные клиенты — нет там плейнтекста, да и проверяется это легко — при желании и опыте. Кстати, протокол они делали совместно с сообществом Signal (который проверен и прошёл аудит), а не на коленке, как телеграм (с проблемами в первой версии).
Чтобы читать переписку от телеги, нужно иметь и симку, и пароль, который выступает, всё-таки, вторым фактором.
Да ну? А у меня вот ни симки, ни пароля десктопный клиент не спрашивает, и будучи перетащенным на другой комп спокойно всё показывает, да и хранит историю локально в открытом виде. Да, я знаю что могу поставить запрос пароля и 2FA (и то огрызок — через SMS) — но это телодвижения которые неискушённый человек не произведёт, не говоря уже о том что самый главный (и едва ли не единственный) плюс телеграма — работа со многими устройствами одновременно — не работает в случае секретных чатов (нет синхронизации).
Впрочем, эта же беда и у Signal (нельзя связать несколько мобильных устройств) — а так телеграм бесценный был бы мессенжер для всего, а не только для котиков и разговоров о погоде.
Телеграм как минимум имеет шифрование обычных чатов, E2E секретных, открытый код клиента и верифицируемые билды — на голову выше, чем Whatsupp.
Для людей кому важна приватность это вторично, им намного более важно где и в каком виде хранятся и передаются их сообщения.
Вы не знаете и не можете знать что делают с сообщениями (обычными) на серверах телеграма — а поскольку уходят они туда как раз плейнтекстом, то доверия всё же больше к WA, причём телеграм уже не один год сопротивляется вводу шифрования по умолчанию и делает всё чтобы секретные чаты были неудобны — уже вышеупомяныте ограничения на одно устройство (они видны только на устройстве где вы открыли секретный чат, на каждом свой) и невозможность работы с ними на декстопе (по крайней мере на Windows) — с чего бы это? А делать copy&paste с мобильника на десктоп пароля или ещё чего-то важного переданного секретным чатом, особенно если там 20-30 случайных символов — то ещё удовольствие.
WA, кстати, уже скоро выкатит версию где работать можно с несколькими устройсвами одновременно (сейчас доступна в бете) — без хранения сообщения на серверах, и с E2EE — технически это несложно и безопасно.
Да, WA это не супер-пупер, но если отбросить "красоту" — то с точки зрения практического использования для человека которому важна приватность, причём на более чем одном устройстве одновременно и с синхронизацией, без разворачивания своей инфраструктуры (куда можно поставить Matrix) — увы, это единственный вариант.
Так что не всё так радужно с альтернативами, увы, хотя разумеется кто-то в чём-то лучше, но нет ни одного который был бы хорош во всём сразу.
Прийдёт compliance с требованием что-то делать или не делать — будем.
Если, к примеру, у вас интернет-магазин с приёмом кредиток (особенно если клиенты вводят номера прямо на вашем сайте) — то compliance уже у вас (PCI DSS), придётся выполнять все нормы и регулярно тестироваться на соответствие.
А так да — если требований и проверяющих нет, если закон/клиенты/партнёры не требуют наличия чего-то — то никакие нормы выполнять не надо, главное чтобы не влезли.
С другой стороны, сами нормы (которые либо содержат, либо легко приводятся в форму чек-листа и сценариев реализации) очень сильно помогают любому безопаснику (по крайней мере если он не машина) — людям свойственно ошибаться и забывать, даже самым крутым, по списку же легче и реализовывать и проверять — если, конечно, список сам по себе грамотный (увы, не все нормы адекватные).
обложиться оборудованием, запасами продуктов и воды вокруг жилых отсеков.
А разве радиация никак не меняет свойства того через что проникает? Людей-то мы спасём, оборудование может тоже выживет, но вот что станет с едой и водой в процессе такого воздействия?
Основная фича — быстрый поиск по префиксу, например в случае IP адресов (т.е. битовых строк) — найти все адреса входящие в подсетку.
Операции с префиксными деревьями имеют сложность O(k) (где k — длина ключа), в отличие от O(log n) (где n — количество элементов) в случае с "обычными" деревьями.
И где он будет хранить пароль для автономной работы по расписанию? Или все бэкапы делать исключительно ручками и только с 2FA (а то ж троянец может и клавиатуру логировать)? Если ручками то проще уж DAS который физически отключается после бэкапа.
Лучше организовать write-only бэкап, когда можно только создавать новые файлы (что-то типа ZFS/BTRFS отлично дедуплицирует), а для восстановления и удаления нужная ручная авторизация (с 2FA). Удаление, впрочем, можно сделать и по расписанию но на самом NAS.
И что? Это не противоречит "собиралась практически с нуля" — Попов просто взял дистр линукса и ничего сам не писал, а тут всё самописное, достаточно посмотреть на этот самый код, его качество это уже другой вопрос.
Да и вообще насчёт говнокода — вы в ядро линукса когда-нибудь заглядывали? Там его тоже достаточно — даже сейчас, про первые версии я уже молчу, но ничего, работает ведь, шагает по планете. Можете для разнообразия глянуть на код windows (есть в сети), вообще страх и ужас — но это не мешает ему быть #1 в десктопах.
Минкомсвязи, похоже, делает логичную вещь: хочет, чтобы крупные зарубежные компании открыли у нас представительства (офисы) и платили здесь налоги
Закон вроде крупность компаний не определяет, или я чего-то путаю? Там две статьи с определениями — в первой про "500 тыс. пользователей" (в этом случае Digital Ocean может не бояться), но во второй вообще кто угодно если предоставляет услуги в сети и работает с пользователями из РФ — т.е. буквально можно вообще любого, даже самого мелкого провайдера да и вообще кого угодно за рубежом прибить (он явно не побежит не то что офис открывать, но даже личный кабинет не сделает).
"Случайное" зерно тоже на самом деле псевдослучайное, и не гарантирует отсутствие повторов последовательностей после перезагрузок, инициализаций, синхронизаций и т.п.
Для данного конкретного случая (UUIDv7) это несущественно, потому что есть временная метка, чтобы они начались повторяться нужно выполнение двух условий — сбой системного времени с одновременным сбросом зерна ровно в то же самое состояние в котором оно было в тот самый момент времени, а это уже очень маловероятно.
Плюс, если у нас нет "железного" генератора, зерно можно сделать очень близким к "истинно случайному", например, если собирать по одному биту из TSC после каждого syscall, не говоря уже о других источниках — время выполнения чего угодно что связано с железом (не только ввод-вывод но и все процессы инициализации в процессе загрузки системы) — в этом случае вероятность того что к моменту начала использовалия CSPRNG оно будет ровно в том же состоянии что было когда-то будет стремиться к нулю (при достаточном размере, разумеется).
Но это не повод пренебрегать надежностью и безопасностью.
До тех пор пока зерно не покидает место генерации и тот-кому-не-нужно не имеет к нему доступа — риск стремится к нулю, разумеется, при использовании "правильного" CSPRNG. Грубо говоря, если у вас есть хороший CSPRNG в сейфе из вибраниума, и совсем неслучайное (но неизвестное) зерно — то результат с практической точки зрения не отличается от "истинно случайного". Если можете привести ссылку на работу которая это опровергает — буду признателен, я таковых не нашёл.
Зря вы так — я прочитал и вполне осилил, но в вашем комментарии на который я отвечал речь явно не идёт про данную конкретную разработку — поскольку вы говорите "Да, вы правы, но так развивается ИТ отрасль" и далее про нивелирование затрат — но как раз в отрасли в общем затраты далеко не всегда нивелируются, на что я и обратил внимание.
Просто с течением времени, стоимость железа нивелируется с затратами на разработку.
Если вы планируете выпуск (допустим) миллиона устройств (без наворотов с распознаванием голоса а с чистым функционалом метеостанции и графиками) то гораздо экономичней будет таки оптимизированная разработка.
Грубо говоря, железо под *pi стоит $15, а под что-то а-ля Arduino/STM32/etc — стоит $5 — вот уже вам 10 миллионов разницы в массовом производстве. И если разработчику придётся заплатить $50000 вместо $10000 — это гораздо менее существенно на фоне затрат на железо.
А для штучных товаров или хобби-проектов, или если свистелки хочется — тогда конечно ок, можно и не мучаться с оптимизациями.
К сожалению, для SSD (если это не NVMe) нет стандартных атрибутов которые показывали бы реальное состояние "здоровья", у каждого вендора (а иногда и у каждой линейки моделей) свои и часто несовместимые — именно для этого и нужна drivedb — если заглянете туда, увидите что в некоторых устройствах одно и то же значение имеет разные id и иногда даже отличается семантика.
Простой пример — у Samsung атрибут 177 — Wear Leveling Count (не у всех моделей), у SanDisk и у Kingston его скорее не будет (тоже зависит от модели). Просто пройдитесь smartctl по разным вендорам SSD — сразу станет ясно что нет ничего стандартного.
Впрочем, даже если атрибуты известны — они не всегда отражают реальность, по моему опыту SSD почти всегда умирают внезапно — т.е. вплоть до смерти всё ок по всем атрибутам, потом вдруг "ой всё", иногда задолго до исчерпания паспортного ресурса. Чаще всего такое происходит с обычными потребительскими моделями (уже стопочка SanDisk и Kingston), но и суровые датацентровские (Samsung DCT) тоже не исключение.
Ситуация усложняется тем что не все вендоры (и не для всех моделей) публикуют информацию об атрибутах, поэтому при их чтении smartctl получаем вот такое (со свежей drivedb и накопителем Kingston которому уже минимум года два):
а среди остальных нет ни одного который бы указывал на реальное использование ресурса кроме количества часов онлайн (количество записанных данных мало что даёт если неизвестен WAF, а в зависимости от использования он может быть весьма немаленьким).
Бывает и наоборот — смарт во всю жалуется что "всё пропало", но накопитель работает без проблем ещё пару лет (уже перемещённый в некритичную систему, ради эксперимента).
Так что ситауция мало изменилась по сравнению с обычными HDD — smart наверное лучше чем без него, но его "надёжность" всё ещё на уровне бросания монетки (по крайней мере для SATA/SAS, по NVMe у меня ещё нет статистики).
Возможно, вам попалась очень древняя версия nfdump, но в своё время я ушёл от flow-tools именно по причине его ограниченности в отчётах — там число отчётов, хоть и велико, но всё же фиксировано, в то время как в nfdump вы може формировать свои по произвольной комбинации полей, и очень даже шустро.
К плюсам nfdump (кроме поддержки Netflow v9) можно также отнести мощную фильтрацию и хорошую компрессию (bz2, lz4, lzo1x-1) собранных данных (которая поддерживается прозрачно как коллектором так и анализатором) — что позволило сократить объемы сырых собранных данных в несколько раз (по сравнению с flow-tools).
Для него также есть набор визуального анализа, который делает почти то же что и ваш проект — NFsen, он хоть и старенький но довольно мощный, также есть попытки его улучшить. Впрочем, для анализа (D)DoS всё равно пришлось делать свой — готовые решения далеко не всегда дают всё что нужно.
И наконец, nfdump — это живой проект, в отличие от flow-tools (разработка которого прекращена много лет назад, насколько я знаю), а в свете того что IPv6 шагает по планете, без NetFlow v9 жить будет очень тяжко.
В реальной жизни есть некоторые нюансы — а именно:
В общем, реальная жизнь это хорошо если круг общения очень широк или как минимум постоянно меняется, при этом человек легко может общаться с кем угодно и этот самый круг идёт на контакт — но это так далеко не у всех, так что виртуальные знакомства вполне имеют смысл, ибо буквально без усилий дают широкий круг общения (который в реальной жизни в принципе недостижим) и возможность фильтрации (если это важно).
Это конечно круто когда всё супершустро, но для подобных задач "очень" понятие весьма условное — если вы собираете образ раз в час, да пусть даже раз в 15 минут, то не особо важно — это 10 секунд или 10 миллисекунд.
Образы обычно создаются редко но надолго, даже для процесса разработки и отладки этих образов 10 секунд это ничто (на фоне остальных затрат времени), не говоря уже о том что время загрузки (с учётом инициализации всего железа, POST etc) часто составляет не менее пары минут — куда тут спешить со сборкой?
Честно говоря, с трудом себе представляю где это может быть критично — разве что речь про "сборка образов как услуга", или каком-то супер-пупер кластере виртуалок из десятков-сотен машин где загрузочные образы генеряются на лету а виртуалки (пере)создаются каждую минуту или чаще с разными требованиями — но как раз для этого случая проще всё решать на лету, а не создавать образы.
Для некоторых это и есть настоящая жизнь. Если для кого-то "настоящая" это (к примеру) путешествия, семья, еда, спорт — то нет совершенного ничего необычного что для кого-то ещё это программирование, как хобби оно ничем не хуже фотографии, рисования или шахмат.
Да, большинство работает чтобы жить, но всё же есть ощутимая прослойка тех кто живет чтобы работать (причем не только айтишники), просто им платят за то что они делали бы бесплатно "для себя", и в семейной жизни у них проблем не больше чем у других (а то и меньше).
В общем, «Выбери себе работу по душе, и тебе не придется работать ни одного дня в своей жизни», так что пенсия в безопасности.
firewalld достаточен для простых вещей, типа открыть порт для чего-то, но для ряда случаев этого очень мало и приходится копать глубже.
Пауза — это открытое соединение, ценный ресурс. Гораздо проще по достижении лимита вплоть до исчерпания времени паузы все запросы отбивать с кодами 429 или 503 и установкой заголовка Retry-After для индикации оставшегося времени ожидания, а особо упорных (которые продолжают слать запросы до его истечения) — банить жёстко.
Хотя, честно говоря, все эти ожидания и прочие лимиты, включая PoW мало помогают против "продвинутых" ломателей — ко мне приходили целые полчища ботов, притворялись полноценными клиентами (js, все дела) — в логах это видно как один-два запроса в секунду на логин, с одного IP пробуют ровно одну пару, максимум две — и он не пытается больше в ближайшие сутки. Да, скорость перебора так себе, но оно ж кушать не просит и не торопится, а банить — по какому критерию? Настоящие пользователи тоже ошибаются, в час обычно парочка пробует с пяток имен-паролей к своим аккаунтам — потому что забывают либо пароли либо как именно зарегистрированы.
Да, но вместо ACK у нас есть GRANT — другое название но такая же функция. Если взять старый добрый RUDP (который так и не стал RFC но всё же использовался) то будет почти то же самое — соединения не надо поддерживать, а детали можно подкрутить.
Ну Дурову ж вы верите про сервера? С одной стороны правильно говорите, а с другой всё ж как-то непоследовательно.
Если они уходят зашифрованными ключём который не покидает моё устройство, причем шифруется проверенным протоколом (а он проверен) — практически безразлично как они обрабатывается за пределами устройства. Это примерно как хранить зашифрованный файл на Dropbox — всё равно что они с ним делают.
Эээ… ну тут как бы WA не при чём — потому что тот кто его получил однозначно имеет его в расшифрованном виде, и репортит уже плейнтекстом — что более чем логично.
Под этим соусом можно вообще 90% всего что есть выбросить — от софта (все реализации VPN в железках) до железа (HSM жалобно плачут), единственная безопасная вещь в плане коммуникаций — это телепатия, и то с оговорками.
Если кто-то, кроме получателя и меня может читать сообщения за пределами наших устройств — это само по себе такая дыра что все остальные плюсы никогда не приведут баланс хотя бы к нулю. Для домохозяек с кошечками, конечно, малоактуально, но речь-то не о них, а на территории стран СНГ телеграм используется многими от полиции до судей, включая пересылку документов — вот как-то не верю я в то что эта золотая жила никем не прорабатывается. Причём, что примечательно, Дуров вложил немалые усилия в рекламу телеграма именно как "безопасного и приватного", хотя по умолчанию, без уже упомянутых выше телодвижений и ограничений это верно на -1% (кроме уже упомянутых домохозяинов).
Это если у вас есть возможность и квалификация поставить свой сервер, поддерживать его и обеспечивать безопасность. И если есть дар убеждения или власть заставить его использовать всех с кем вы общаетесь. И ещё много всяких если — в то время как WA, при всей их непушистости, вряд-ли пойдут на явный или даже замаскированный обман в плане шифрования и доступа к данным — потому что это всплывёт неизбежно, а когда всплывёт — то потеряют они намного больше чем приобретут.
Он мне очень нравится. Ну ок, почти очень. Но есть пара неприятных и весьма важных моментов:
Всё остальное не играет особой роли.
Откуда дровишки? Сообщения хранятся на серверах (в зашифрованном виде — т.е. сервер их не может прочитать) до момента попадания на устройство получателя. Телеграм же по умолчанию получает сообщения в открытом виде, и они хранятся на его серверах доступными для чтения кому-нужно.
Их протоколы известны, отреверсены и даже есть альтернативные клиенты — нет там плейнтекста, да и проверяется это легко — при желании и опыте. Кстати, протокол они делали совместно с сообществом Signal (который проверен и прошёл аудит), а не на коленке, как телеграм (с проблемами в первой версии).
Да ну? А у меня вот ни симки, ни пароля десктопный клиент не спрашивает, и будучи перетащенным на другой комп спокойно всё показывает, да и хранит историю локально в открытом виде. Да, я знаю что могу поставить запрос пароля и 2FA (и то огрызок — через SMS) — но это телодвижения которые неискушённый человек не произведёт, не говоря уже о том что самый главный (и едва ли не единственный) плюс телеграма — работа со многими устройствами одновременно — не работает в случае секретных чатов (нет синхронизации).
Впрочем, эта же беда и у Signal (нельзя связать несколько мобильных устройств) — а так телеграм бесценный был бы мессенжер для всего, а не только для котиков и разговоров о погоде.
Для людей кому важна приватность это вторично, им намного более важно где и в каком виде хранятся и передаются их сообщения.
Вы не знаете и не можете знать что делают с сообщениями (обычными) на серверах телеграма — а поскольку уходят они туда как раз плейнтекстом, то доверия всё же больше к WA, причём телеграм уже не один год сопротивляется вводу шифрования по умолчанию и делает всё чтобы секретные чаты были неудобны — уже вышеупомяныте ограничения на одно устройство (они видны только на устройстве где вы открыли секретный чат, на каждом свой) и невозможность работы с ними на декстопе (по крайней мере на Windows) — с чего бы это? А делать copy&paste с мобильника на десктоп пароля или ещё чего-то важного переданного секретным чатом, особенно если там 20-30 случайных символов — то ещё удовольствие.
WA, кстати, уже скоро выкатит версию где работать можно с несколькими устройсвами одновременно (сейчас доступна в бете) — без хранения сообщения на серверах, и с E2EE — технически это несложно и безопасно.
Да, WA это не супер-пупер, но если отбросить "красоту" — то с точки зрения практического использования для человека которому важна приватность, причём на более чем одном устройстве одновременно и с синхронизацией, без разворачивания своей инфраструктуры (куда можно поставить Matrix) — увы, это единственный вариант.
Так что не всё так радужно с альтернативами, увы, хотя разумеется кто-то в чём-то лучше, но нет ни одного который был бы хорош во всём сразу.
А чем айтишники принципиально лучше чем сотрудники других отраслей что они не должны бороться?
Если, к примеру, у вас интернет-магазин с приёмом кредиток (особенно если клиенты вводят номера прямо на вашем сайте) — то compliance уже у вас (PCI DSS), придётся выполнять все нормы и регулярно тестироваться на соответствие.
А так да — если требований и проверяющих нет, если закон/клиенты/партнёры не требуют наличия чего-то — то никакие нормы выполнять не надо, главное чтобы не влезли.
С другой стороны, сами нормы (которые либо содержат, либо легко приводятся в форму чек-листа и сценариев реализации) очень сильно помогают любому безопаснику (по крайней мере если он не машина) — людям свойственно ошибаться и забывать, даже самым крутым, по списку же легче и реализовывать и проверять — если, конечно, список сам по себе грамотный (увы, не все нормы адекватные).
А разве радиация никак не меняет свойства того через что проникает? Людей-то мы спасём, оборудование может тоже выживет, но вот что станет с едой и водой в процессе такого воздействия?
Основная фича — быстрый поиск по префиксу, например в случае IP адресов (т.е. битовых строк) — найти все адреса входящие в подсетку.
Операции с префиксными деревьями имеют сложность O(k) (где k — длина ключа), в отличие от O(log n) (где n — количество элементов) в случае с "обычными" деревьями.
И где он будет хранить пароль для автономной работы по расписанию? Или все бэкапы делать исключительно ручками и только с 2FA (а то ж троянец может и клавиатуру логировать)? Если ручками то проще уж DAS который физически отключается после бэкапа.
Лучше организовать write-only бэкап, когда можно только создавать новые файлы (что-то типа ZFS/BTRFS отлично дедуплицирует), а для восстановления и удаления нужная ручная авторизация (с 2FA). Удаление, впрочем, можно сделать и по расписанию но на самом NAS.
И что? Это не противоречит "собиралась практически с нуля" — Попов просто взял дистр линукса и ничего сам не писал, а тут всё самописное, достаточно посмотреть на этот самый код, его качество это уже другой вопрос.
Да и вообще насчёт говнокода — вы в ядро линукса когда-нибудь заглядывали? Там его тоже достаточно — даже сейчас, про первые версии я уже молчу, но ничего, работает ведь, шагает по планете. Можете для разнообразия глянуть на код windows (есть в сети), вообще страх и ужас — но это не мешает ему быть #1 в десктопах.
Закон вроде крупность компаний не определяет, или я чего-то путаю? Там две статьи с определениями — в первой про "500 тыс. пользователей" (в этом случае Digital Ocean может не бояться), но во второй вообще кто угодно если предоставляет услуги в сети и работает с пользователями из РФ — т.е. буквально можно вообще любого, даже самого мелкого провайдера да и вообще кого угодно за рубежом прибить (он явно не побежит не то что офис открывать, но даже личный кабинет не сделает).
Для данного конкретного случая (UUIDv7) это несущественно, потому что есть временная метка, чтобы они начались повторяться нужно выполнение двух условий — сбой системного времени с одновременным сбросом зерна ровно в то же самое состояние в котором оно было в тот самый момент времени, а это уже очень маловероятно.
Плюс, если у нас нет "железного" генератора, зерно можно сделать очень близким к "истинно случайному", например, если собирать по одному биту из TSC после каждого syscall, не говоря уже о других источниках — время выполнения чего угодно что связано с железом (не только ввод-вывод но и все процессы инициализации в процессе загрузки системы) — в этом случае вероятность того что к моменту начала использовалия CSPRNG оно будет ровно в том же состоянии что было когда-то будет стремиться к нулю (при достаточном размере, разумеется).
До тех пор пока зерно не покидает место генерации и тот-кому-не-нужно не имеет к нему доступа — риск стремится к нулю, разумеется, при использовании "правильного" CSPRNG. Грубо говоря, если у вас есть хороший CSPRNG в сейфе из вибраниума, и совсем неслучайное (но неизвестное) зерно — то результат с практической точки зрения не отличается от "истинно случайного". Если можете привести ссылку на работу которая это опровергает — буду признателен, я таковых не нашёл.
Зря вы так — я прочитал и вполне осилил, но в вашем комментарии на который я отвечал речь явно не идёт про данную конкретную разработку — поскольку вы говорите "Да, вы правы, но так развивается ИТ отрасль" и далее про нивелирование затрат — но как раз в отрасли в общем затраты далеко не всегда нивелируются, на что я и обратил внимание.
Если вы планируете выпуск (допустим) миллиона устройств (без наворотов с распознаванием голоса а с чистым функционалом метеостанции и графиками) то гораздо экономичней будет таки оптимизированная разработка.
Грубо говоря, железо под *pi стоит $15, а под что-то а-ля Arduino/STM32/etc — стоит $5 — вот уже вам 10 миллионов разницы в массовом производстве. И если разработчику придётся заплатить $50000 вместо $10000 — это гораздо менее существенно на фоне затрат на железо.
А для штучных товаров или хобби-проектов, или если свистелки хочется — тогда конечно ок, можно и не мучаться с оптимизациями.
К сожалению, для SSD (если это не NVMe) нет стандартных атрибутов которые показывали бы реальное состояние "здоровья", у каждого вендора (а иногда и у каждой линейки моделей) свои и часто несовместимые — именно для этого и нужна drivedb — если заглянете туда, увидите что в некоторых устройствах одно и то же значение имеет разные id и иногда даже отличается семантика.
Простой пример — у Samsung атрибут 177 — Wear Leveling Count (не у всех моделей), у SanDisk и у Kingston его скорее не будет (тоже зависит от модели). Просто пройдитесь smartctl по разным вендорам SSD — сразу станет ясно что нет ничего стандартного.
Впрочем, даже если атрибуты известны — они не всегда отражают реальность, по моему опыту SSD почти всегда умирают внезапно — т.е. вплоть до смерти всё ок по всем атрибутам, потом вдруг "ой всё", иногда задолго до исчерпания паспортного ресурса. Чаще всего такое происходит с обычными потребительскими моделями (уже стопочка SanDisk и Kingston), но и суровые датацентровские (Samsung DCT) тоже не исключение.
Ситуация усложняется тем что не все вендоры (и не для всех моделей) публикуют информацию об атрибутах, поэтому при их чтении smartctl получаем вот такое (со свежей drivedb и накопителем Kingston которому уже минимум года два):
а среди остальных нет ни одного который бы указывал на реальное использование ресурса кроме количества часов онлайн (количество записанных данных мало что даёт если неизвестен WAF, а в зависимости от использования он может быть весьма немаленьким).
Бывает и наоборот — смарт во всю жалуется что "всё пропало", но накопитель работает без проблем ещё пару лет (уже перемещённый в некритичную систему, ради эксперимента).
Так что ситауция мало изменилась по сравнению с обычными HDD — smart наверное лучше чем без него, но его "надёжность" всё ещё на уровне бросания монетки (по крайней мере для SATA/SAS, по NVMe у меня ещё нет статистики).
Возможно, вам попалась очень древняя версия nfdump, но в своё время я ушёл от flow-tools именно по причине его ограниченности в отчётах — там число отчётов, хоть и велико, но всё же фиксировано, в то время как в nfdump вы може формировать свои по произвольной комбинации полей, и очень даже шустро.
К плюсам nfdump (кроме поддержки Netflow v9) можно также отнести мощную фильтрацию и хорошую компрессию (bz2, lz4, lzo1x-1) собранных данных (которая поддерживается прозрачно как коллектором так и анализатором) — что позволило сократить объемы сырых собранных данных в несколько раз (по сравнению с flow-tools).
Для него также есть набор визуального анализа, который делает почти то же что и ваш проект — NFsen, он хоть и старенький но довольно мощный, также есть попытки его улучшить. Впрочем, для анализа (D)DoS всё равно пришлось делать свой — готовые решения далеко не всегда дают всё что нужно.
И наконец, nfdump — это живой проект, в отличие от flow-tools (разработка которого прекращена много лет назад, насколько я знаю), а в свете того что IPv6 шагает по планете, без NetFlow v9 жить будет очень тяжко.