Штраф это предупредительная мера. Если корпорации не изменят политику, суммы будут увеличиваться (или штрафы участятся) и рано или поздно это уже будет трудно игнорировать. GDPR предусматривает штрафы до 4% от годового оборота, а это уже очень больно даже для Google и FB.
Разумеется, корпорации будут бороться — но рано или поздно их таки нагнут, пусть не сразу и возможно не с первого раза эффективно, но неизбежно.
А вообще это шаг в правильном направлении — если есть кнопка "разрешить всё", то логично обязать поставить рядом такую же "запретить всё", которая ничем (кроме текста) не отличается от первой.
На актуальных всё точно также — собственно, это и меня и сподвигло перейти на NVMe в своё время, это было небо и земля даже для чисто экспериментальных проектов с кучей VM (хотя изначально я тоже был скептически настроен).
Окрылённый полученным опытом я посоветовал давнему клиенту тоже попробовать (он периодически жаловался на производительность, несмотря на то что в системе были только SSD) — в итоге он остался доволен как слон и сказал что субъективно ощущения как после пересадки с HDD на (первые) SSD — хотя конечно это зависит от задач (у него сильно нагруженный i/o кластер с k8s).
Proxmox ZFS выбирают за бесплатные снапшоты
В чём их бесплатность по сравнению с LVM thin? Да и при любом раскладе это "бесплатно" только для хостера, для клиентов это боль если (к примеру) у них там нагруженные базы или ещё что-то чему вредит COW.
ZFS и так не быстрая, и лучшее ей применение это NAS & co, где данные редко модифицируются "по месту" (бэкапы и прочее), если её ставить на хостинг и там хорошая активность — это просто смерть производительности даже на NVMe, и это при выключенных компрессии и дедупликации, а с ними это вообще ужас-ужас — в начале всё ок но со временем за счёт фрагментации всё начинает тормозить просто ужасно, особенно если памяти на ARC не десятки гигабайт и процессор не очень многоядерный.
Также при тестах из ВМ есть риск, что чтение будет из ОЗУ хоста.
Риск есть только если хост принудительно включает кэш и игнорирует direct i/o — я очень сомневаюсь что Hetzner это делает, не говоря уже о том что это приводит к сильному "загрязнению" памяти хоста всяким мусором и в целом плохо сказывается на всех (любая VM может загнать в swap хост и сильно помешать соседям — объём кэша на процесс/пользователя не тюнится, разве что ядро патченное).
Но я делал тесты и по чтению, разумеется — результаты почти идентичны (разница в пару процентов).
Для полноты картину, вот результаты тестирования с /dev/ram0 (на той же VM):
Так что очень маловероятно что хост кэширует что-то — даже с учётом оверхеда виртуализации это было в пусть в два-три раза медленней, но явно не на порядок.
Тесты ZFS могут не говорить о реальной призводительности если неизвестно сколько памяти получил ARC — ZFS очень агрессивен в кэшировании (direct i/o игнорирует), так что если памяти у вас достаточно (32GB или больше) вы меряете производительность самой файловой системы, а не накопителя. Поставьте ограничение на ARC чтобы файл в него точно не влезал, и добавьте --fsync=1 к fio (убедившись что в ZFS не стоит sync=disabled) — тогда тест будет более реалистичным.
С блоками по 4k ситуация очень плохая за счёт организации самого ZFS (дерево, контрольные суммы и вот это всё) — сделайте ramdisk и померяйте, результаты тоже будут не впечатляющими, хотя конечно лучше чем с диском (любым).
NVME выдаёт 220к 4к IOPS в сумме (r+w). При этом Samsung заявляет о 1М IOPS.Видимо не 4К IOPS.
Потому что они указывают данные не для микса, а отдельно для чтения и записи — на только чтении или записи вы вероятно можете получить почти близко к 1M iops при QD > 32 а то и 128, правда, в вакууме идеальных условиях — т.е. тестируете его в монопольном режиме, причём заточенным под максимум производительности тулом. Вообще странно было бы ожидать от производителя гарантии iops не зная где и как будет использоваться накопитель, может его вообще по USB подключат, поэтому они указывают возможности железа (NVMe + PCIe), а вытянет ли их ваш конкретный сетап — это уже вопрос.
Теперь вернёмся к NVMe на Hetzner. Я провел тот же тест с файлом в 20G, с блоками по 1M и 4k, всё длительностью 1 минута — думаю это уж точно в кэш не влезло (разве что в SLC на самом накопителе):
Разумеется, если я снижаюсь до 4k, то получаем сильное проседание по bandwidth, но если учесть что это виртуалка и на одном хосте их много, то оверхед и общая нагрузка сильно портят картину:
Очевидно что результаты, как вы выразились, "не впечатляющие", но если туда поставить обычные (не NVMe) SSD, они станут в несколько раз менее впечатляющими, а если учесть любовь некоторых хостеров строить хосты на ZFS, то всё совсем может оказаться печально (принудительный COW даже на блочных устройствах, компрессия и прочие радости — зато типа "супер надёжно").
Для сравнения — вот результат от OVH (VPS Comfort), где они тоже пишут про NVMe:
Очень похоже что что они ограничивают iops до 16k (слишком ровные результаты), соответственно при блоках в 4k сильно проседает и bandwidth. То же самое для 1M:
Тут уже видно что идёт ограничение по bandwitdh (слишком уж "ровно" оно на протяжении всего теста) — и это в два-три раза менее впечатляюще чем у Hetzner.
Собственно, я и тесты-то сделал не чтобы показать что в виртуалке можно получить максимум от NVMe — за счёт виртуализации это практически невозможно (очень большой оверхед по дороге к накопителю, особенно если виртуалок много), но использование NVMe вполне оправданно — потому что без них всё будет намного хуже, как минимум в разы, а на загруженных по i/o хостах может даже на один-два порядка — по той простой причине что условные 500K iops на NVMe дадут по 50k iops на десяти виртуалках, в то время как не менее реалистичные 100k на "обычных" SSD дадут соответственно по 10k, да и скорость поделится соответственно.
В качестве иллюстрации оверхеда (домашний сервер, PNY CS3030 1T как накопитель, KVM в proxmox), на этот раз на чтении:
Это гораздо более впечатляюще чем у Hetzner, но — это сервер на котором нет нагрузки, он фактически простаивает, да и процессор на нём в пару раз пошустрее (а он важен для пути накопитель=>lvm=>vm и обратно). Теперь тот же fio на хосте через LVM который подцеплен к виртуалке:
Как видите, просто за счёт того что это виртуалка, мы уже теряем около 40%(!) — и это она одна, другой нагрузки в системе нет и даже отключены все митигации как на хосте так и на виртуалке (mitigations=off) — разумеется если виртуалок с десяток или два, они что-то делают, а поскольку это хостер то и митигации по полной программе — мы просядем ещё больше, но это проседание будет намного менее заметным чем в случае SATA/SAS.
Так что если кто-то говорит что "VPS получит скорость NVMe" — он скорее всего таки врёт, но если этот кто-то говорит "на наших хостах стоят NVMe и это сильно повышает производительность [чем если бы стояли SATA/SAS]" — то это всё же скорее всего правда — об этом говорит и опыт с хостерами, и собственный (правда, не на Hyper-V).
Про RAID для NVMe тоже смешанные чувства — конечно, "один раз не считается", но я для эксперимента делал softRAID1 (mdadm) на двух потребительских NVMe (PNY CS3030 1T, посаженных на один PCIe x16 слот в X470D4U + Ryzen 3600X), разницы в скорости практически не было (при записи), рандомное чтение было быстрее но не помню на сколько — и это совсем не серверное железо. Увы, это было относительно давно, сборки уже нет, а результаты я не сохранял — но успех этого эксперимента позволяет мне верить что заявленное Hetzner наличие RAID 10 на их cloud серверах очень реалистично, вопреки выводам в статье про невозможность (или нецелесообразность) RAID на NVMe.
Те, кто пишет про RAID, либо банально врут, либо замедляют скорость чуть ли не ниже SSD, что исключает полезность NVMe-дисков.
Получается Hetzner врёт? Они утверждают что у них RAID10 на хостах, диски NVMe, и судя по результатам тестирования внутри cloud-серверов, похоже таки на правду (fio на самом дешёвом cloud server, CX11, ему уже несколько лет):
# fio --filename=/fio.test --size=1G --direct=1 --rw=randrw --bs=1m --ioengine=libaio --iodepth=8 --iodepth_batch_submit=8 --runtime=10 --numjobs=6 --time_based --group_reporting --name=iops-test-job --eta-newline=1
...
Run status group 0 (all jobs):
READ: bw=2894MiB/s (3034MB/s), 2894MiB/s-2894MiB/s (3034MB/s-3034MB/s), io=28.3GiB (30.4GB), run=10012-10012msec
WRITE: bw=2919MiB/s (3061MB/s), 2919MiB/s-2919MiB/s (3061MB/s-3061MB/s), io=28.5GiB (30.6GB), run=10012-10012msec
## А также чистая запись
# fio --filename=/fio.test --size=1G --direct=1 --rw=randwrite --bs=1m --ioengine=libaio --iodepth=8 --iodepth_batch_submit=8 --runtime=10 --numjobs=6 --time_based --group_reporting --name=iops-test-job --eta-newline=1
iops-test-job: (g=0): rw=randwrite, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=libaio, iodepth=8
...
Run status group 0 (all jobs):
WRITE: bw=4560MiB/s (4781MB/s), 4560MiB/s-4560MiB/s (4781MB/s-4781MB/s), io=44.6GiB (47.8GB), run=10008-10008msec
В процессе тестирования использование процессора (vCPU, он там один) около 60%.
По любому быстрее чем обычный SSD — в разы. Результаты стабильные за все несколько лет, и не только на одном сервере, разумеется, и это с учётом того что на одном хосте крутится явно не один виртуальный.
Если нет, то устанавливаем программу и генерируем ключи.
Зачем же генерировать эти ужасно длинные RSA ключи по умолчанию, если можно сделать короткие ed25519 без потери качества?
Например, ssh-keygen -t ed25519 производит довольно короткую строку для паблик-ключа (её удобно копировать): ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH5KCvDh/K5lRJW1f4X+wpt0PIrLwvbtSf3YIqqh1/tY user@localhost
Откуда такое пренебрежение к секретарям? С учётом того какую работу она выполняла и насколько хорошо, не говоря уже о переработках — совершенно неважно как называлась её должность.
Секретарь — это далеко не всегда только "подать кофе" и "организовать встречу", равно как и далеко не всегда топ-менеджер стоит тех денег которые ему платят.
Нет, логика у меня чуть другая — не ставить капканы там где поможет железная дверь. Блокировка системы с шифрованием диска — это защита от подавляющего большинства жуликов всех мастей во всех их градациях, в то время как подавляющее меньшинство с ресурсами и желанием добраться до моих данных не остановит даже бронепоезд.
Разумеется я не поставлю пароль "1234" на кошелёк, но и делать его самоуничтожающимся тоже не собираюсь — там просто нет таких сумм которые вызовут интерес братков с утюгом, а все остальные его оставят в покое как поймут что без утюга ничего не достать.
К тому же, любой капкан, т.е. изощренная система защиты, это вероятность её ложного срабатывания или случайного приведения в действие — что для большинства людей очень большой минус.
Властей мне бояться нечего — по крайней мере в моей стране, я честный налогоплательщик и проблем с законом не имею, но если уж власть сменится так что дойдёт до "мордой в пол" (очень маловероятный сценарий) то интересовать их будет явно не содержимое моего диска, для них при любом раскладе там ничего ценного — состояние моих финансов им и так известно, а скелетов в шкафах у меня нет. Если же это будет какая-то хитрая подстава (тоже очень маловероятно) — то мне как раз будет выгодно показать что у меня ничего "такого" нет, чем наоборот.
Как говорила героиня одного известного фильма — мне нечего скрывать, я просто не хочу ничего показывать.
Если то что стирается кому-то сильно нужно все эти меры мало помогут — разве что вы готовы пожертвовать своей жизнью и/или здоровьем (или ваших близких) ради того чтобы данные не попали в руки врагов. А в случае если не готовы — то через очень короткое время вы сами расскажете где лежит шифрованный бэкап, как из него получить данные и активно в этом поможете, даже в другой стране.
Во всех остальных случаях достаточно простой блокировки и шифрованного диска — украдут "простые жулики" или любопытные захотят посмотреть — ничего не получат и дальше не полезут.
Сейчас крипта уже позволяет намного быстрее и дешевле осуществлять многие операции, что делает ее более удобной чем фиат.
Да ладно? Что может быть проще и быстрее оплаты кредиткой/телефоном с NFC? Это занимает пару секунд, равно как и перечисление с карты на карту (хотя это зависит от банка) — по простоте и скорости крипте это только снится, особенно на суммах до $100, не говоря уже о том что с криптой если нарвёшься на жулика хрен что вернешь, в отличие от карточки.
"Дешевле" тоже весьма расплывчатое понятие, зависит от конкретных участников — но оплата карточкой/переводом/налом потребителю стоит одинаково, все риски и сборы/затраты и так уже в цене товара или услуги, а вот с криптой всё совершенно иначе — если кто-то продаёт реальные услуги или товары, то ему нужно учесть риски связанные с волатильностью и выводом, а это в итоге "дешевле" не получится при всём желании, т.е. сама транзакция может оказаться с очень низкой стоимостью, но цена будет выше для плательщика.
Ясный пень если кто-то не хочет светить транзакции карточкой не воспользуется — но большинству это как раз пофиг, а вот что большинству совсем не пофиг — так это защищенность транзакций и волатильность (вот зачем нужно регулирование).
Что касается мнимой анонимности — то без комплекта бубнов крипта отслеживается не хуже чем карточки и уж точно проще чем нал, т.е. опять-таки сервис для маргиналов и прочих тёмных лошадок, и конечно же трейдеров всех мастей — для них тут просто рай.
Это будет иметь смысл если только они не будут замедлять выполнение. Обработка исключений — это дорого, очень дорого, в любом языке который это поддерживает — помню я нарвался на это первый раз в .Net когда работа с сокетами выбрасывала исключения на "connection refused" (которое совсем не исключение, если подумать) — это был кошмар, и с тех пор ситуация не поменялась, даже в C++.
Причём, весь этот метод вполне может отвечать принципу "делать что-то одно" и даже быть достаточно коротким, но при этом в 50% случаев будет вылетать в oops (обрабатывая данные извне, к примеру) — если он вызывается сотни миллионов раз то исключения напрочь убьют производительность.
Гугль хорошо описал большинство "за" и "против" и в итоге отказался от них даже в C++, ну а ядро Линукса не то чтобы напичкано goto, но совсем ими не гнушается — представьте там исключения и прочие "правильные" меры (выделение метода — это тоже может влиять на производительность).
Так что как уже не раз сказали раньше — goto можно (и даже иногда нужно) использовать грамотно, а вот "тащить и не пущать" — это плохая практика, это всё равно что отказаться от утюгов и стиральных машин дома и заставить людей отдавать стирать и гладить вещи в спецсервисы, а то пожары случаются, водой заливает и всё такое. Да ещё и острые ножи, ножницы и бритвы можно запретить, ими ж порезаться можно, или даже кого-то убить.
К тому же, как показывает опыт, никакой супер-пупер язык не мешает писать говнокод, пусть там не будет goto но будет что-то другое, даже на всеми любимом Rust можно косячить по самое немогу (в логике и т.п. вещах).
Какой кликбейт… причём тут вообще Линукс как таковой если проблема в Remmina и её обвязке? Она может возникнуть на любой системе где стоит Remmina и её позволяют запускать (даже Windows), причём совсем необязательно даже из обработчиков URL.
НДС оплачивает покупатель, хотя должен оплачивать производитель добавленной стоимости
В общем-то, в этом и суть НДС — это де-факто налог на потребление (нечто вроде "налога на продажи", только более гуманный с экономической точки зрения за счёт отсутствия каскадного эффекта) и оплачивать его должен именно конечный потребитель — производитель (поставщик товаров/услуг) его совсем не должен оплачивать.
То что в реальности налог в казну взимается с продавцов — это сделано исключительно для упрощения логистики сборов, в частности чтобы физлица после посещения магазинов не отщипывали свои кровные для налоговой отдельным платежом (представьте этот кошмар) — поэтому он заложен в конечной цене.
Вероятно всё дело в том что "все знали", я же говорил о тайной записи (т.е. когда собеседник не в курсе что его пишут, против записи и потом обнаруживает факт оной).
Также возможно что в вашем окружении все параноики и для них запись всех разговоров — норма, но всё же большинство людей относится к этому негативно.
Или вы думаете что законы (в ЕС в частности) которые наказывают за запись без согласия всех участников просто от балды появились?
В РФ и других странах бСССР защита личной жизни и приватности вообще не в моде, скорее даже наоборот — и это очень печально.
Такой товарищ был, и спалился он не на разглашении а банально по пьяни проболтался что пишет разговоры.
Если вам лично всё равно, пишут вас или нет, это не значит что всё равно остальным, и игнорировать вероятное нежелание других людей — как минимум неуважение, хотя в некоторых более продвинутых странах за запись (даже "для себя") без согласия предусмотрена ответственность.
Не знаю насчёт "сообщества сплетников", но факт того что вы пишете "втихую" косвенно говорит о том что вы не доверяете собеседникам, ожидаете подвоха, прикрываясь при этом "личным делом", при этом вам совершенно незнакомы границы личного и совершенно безразлично отношение других к этому вопросу, если бы это было не так вы бы знали что ваши права заканчиваются ровно там где начинаются права другого человека.
С другой стороны, я почти не сомневаюсь что вы категорически против сбора биометрии банками и прочими конторами, явно не желая оказаться в невыгодном положении в случае чего — но при этом сами собиратете ту же самую биометрику (в виде голоса) которая может быть использована если и не против вас, то против ваших собеседников, независимо от того хотите вы этого или нет — потому что безопасность хранения подобных записей вы обеспечить не можете.
Слухи и сплети это совершенно другое — во времена дипфейков коллекция сэмплов голоса это гораздо более неприятная вещь, да и демонстрация выборочных фрагментов записи — тоже, для людей которые не имеют публичных записей или выступлений это весьма актуальная проблема.
Увы, больше тут нечего сказать — но вполне вероятно кто-то использует вырванную из контекста часть записи вашего с кем-то разговора, которая разрушит вашу жизнь или как минимум доставит кучу неприятностей — я уверен что после это вы измените своё мнение. Если этого не случится — считайте что вам крупно повезло. Но разумеется, можете верить что с вами такого случится не может.
Где гарантия того что вы не будете эти разговоры давать послушать друзьям/родственникам "чисто для смеха" — или это типа не публикация?
А если записи утекут (даже в пересказанном виде) и пострадает другая сторона? Вы готовы этой стороне компенсировать неприятности? Или может вы обязуетесь хранить записи в охраняемом бункере, исключающем утечки?
Даже если закон этого не запрещает, записывать разговоры хотя бы без уведомления (хотя по хорошему нужно согласие) собеседника — это просто свинство, кроме редких случаев когда вам угрожают, шантажируют etc.
Был у меня один знакомый, который спалился на тайной записи разговоров — и мгновенно ушел в игнор у всех с кем общался, причём это были не собиратели долгов, не рекламщики, а люди которые считали его если не другом то как минимум товарищем. Последствия на этом не закончились, впрочем — с работы вылетел и долго искал новую, да и репутация у него упала ниже плинтуса.
Если таки и правда "раз в год" — что за бренд/модель? По своему опыту я столкнулся только с парой "естественных" смертей свитчей — это были D-Link, причём в выборке более 30 штук и все они проработали не менее 15 лет.
К сожалению, есть довольно продвинутые трекеры (и уже давно) с которыми дебаунсинг не работает — ссылки либо зашифрованы (т.е. их никак не идентифицировать и не очистить), либо просто являются идентификатором на трекере — т.е. до перехода на трекер точку назначения не узнать.
Такие ссылки конечно можно блокировать по списку трекеров, но тогда это будут просто мёртвые ссылки.
Вы пишите абстракцию один раз (тут дел-то на полчаса максимум) — а используете потом вечно (если она не сильно убивает производительность или если это неважно).
А краткость в Perl… как выше уже упоминалось — для себя или таких же — да, вполне, одноразовый или просто write-only код — тоже, но не забывайте — код лучше писать с расчётом на то что сопровождать и поддерживать его будет склонный к насилию психопат, который знает, где вы живёте — вполне возможно что вы им станете если посмотрите на свой код лет через 10-15.
Достаточно сохранить %-, @- и @+, все остальные это производные от @- и @+:
$` is the same as substr($var, 0, $-[0])
$& is the same as substr($var, $-[0], $+[0] - $-[0])
$' is the same as substr($var, $+[0])
$1 is the same as substr($var, $-[1], $+[1] - $-[1])
$2 is the same as substr($var, $-[2], $+[2] - $-[2])
$3 is the same as substr($var, $-[3], $+[3] - $-[3])
В свою очередь %+ это производная от %-.
PS: Можно даже написать простой класс-обёртку вокруг этого, чтобы иметь результат как экземпляр класса, используя $re->post, $re[1] etc (если его ещё нет на metacpan). Чуть-чуть пострадает производительность, конечно, но сохранение тоже не бесплатно.
Знакомства (не отношения) IRL тоже ни к чему не обязывают, в общем-то, только риски чуть выше.
Вообще во всей этой индустрии классический конфликт — люди хотят безопасно и надёжно, но в то же время анонимно до последнего момента, а это в принципе несовместимо, и они не готовы пожертвовать своей анонимностью (= пройти полную идентификацию на сервисе).
Если, как уже выше упоминалось, сделать сервис который будет гарантировать что конкретную личность за профилем можно найти при необходимости (с паспортом, адресом и видео которое подтверждает связь паспорта и фото в профиле, разумеется не для публичного доступа а в архив на случай запроса из полиции) — то все эти жулики (и даже просто неадекваты) выпиливаются очень быстро ибо подставные личности быстро закончатся, заодно будет безопасно, ибо если что — то ниточки быстро раскручиваются, при желании разумеется.
При этом сами профили можно оставить относительно анонимными — без реальных имён, адресов etc — только реальное фото и тэг "верифицирован" — в итоге и овцы сыты, и волки целы. Те кто не хочет "палиться" (типа "давно здесь сижу") могут обновлять фотки (только свои, т.е. с модерацией) и никнейм — на статус профиля это не влияет.
Правда, реализация подобного потребует железобетонных гарантий отсутствия утечек реальных данных, что в принципе реализуемо технически но никому (из владельцев сервисов) неинтересно.
Штраф это предупредительная мера. Если корпорации не изменят политику, суммы будут увеличиваться (или штрафы участятся) и рано или поздно это уже будет трудно игнорировать. GDPR предусматривает штрафы до 4% от годового оборота, а это уже очень больно даже для Google и FB.
Разумеется, корпорации будут бороться — но рано или поздно их таки нагнут, пусть не сразу и возможно не с первого раза эффективно, но неизбежно.
А вообще это шаг в правильном направлении — если есть кнопка "разрешить всё", то логично обязать поставить рядом такую же "запретить всё", которая ничем (кроме текста) не отличается от первой.
На актуальных всё точно также — собственно, это и меня и сподвигло перейти на NVMe в своё время, это было небо и земля даже для чисто экспериментальных проектов с кучей VM (хотя изначально я тоже был скептически настроен).
Окрылённый полученным опытом я посоветовал давнему клиенту тоже попробовать (он периодически жаловался на производительность, несмотря на то что в системе были только SSD) — в итоге он остался доволен как слон и сказал что субъективно ощущения как после пересадки с HDD на (первые) SSD — хотя конечно это зависит от задач (у него сильно нагруженный i/o кластер с k8s).
В чём их бесплатность по сравнению с LVM thin? Да и при любом раскладе это "бесплатно" только для хостера, для клиентов это боль если (к примеру) у них там нагруженные базы или ещё что-то чему вредит COW.
ZFS и так не быстрая, и лучшее ей применение это NAS & co, где данные редко модифицируются "по месту" (бэкапы и прочее), если её ставить на хостинг и там хорошая активность — это просто смерть производительности даже на NVMe, и это при выключенных компрессии и дедупликации, а с ними это вообще ужас-ужас — в начале всё ок но со временем за счёт фрагментации всё начинает тормозить просто ужасно, особенно если памяти на ARC не десятки гигабайт и процессор не очень многоядерный.
Риск есть только если хост принудительно включает кэш и игнорирует direct i/o — я очень сомневаюсь что Hetzner это делает, не говоря уже о том что это приводит к сильному "загрязнению" памяти хоста всяким мусором и в целом плохо сказывается на всех (любая VM может загнать в swap хост и сильно помешать соседям — объём кэша на процесс/пользователя не тюнится, разве что ядро патченное).
Но я делал тесты и по чтению, разумеется — результаты почти идентичны (разница в пару процентов).
Для полноты картину, вот результаты тестирования с /dev/ram0 (на той же VM):
Так что очень маловероятно что хост кэширует что-то — даже с учётом оверхеда виртуализации это было в пусть в два-три раза медленней, но явно не на порядок.
Тесты ZFS могут не говорить о реальной призводительности если неизвестно сколько памяти получил ARC — ZFS очень агрессивен в кэшировании (direct i/o игнорирует), так что если памяти у вас достаточно (32GB или больше) вы меряете производительность самой файловой системы, а не накопителя. Поставьте ограничение на ARC чтобы файл в него точно не влезал, и добавьте
--fsync=1кfio(убедившись что в ZFS не стоитsync=disabled) — тогда тест будет более реалистичным.С блоками по 4k ситуация очень плохая за счёт организации самого ZFS (дерево, контрольные суммы и вот это всё) — сделайте ramdisk и померяйте, результаты тоже будут не впечатляющими, хотя конечно лучше чем с диском (любым).
Потому что они указывают данные не для микса, а отдельно для чтения и записи — на только чтении или записи вы вероятно можете получить почти близко к 1M iops при QD > 32 а то и 128, правда, в
вакуумеидеальных условиях — т.е. тестируете его в монопольном режиме, причём заточенным под максимум производительности тулом. Вообще странно было бы ожидать от производителя гарантии iops не зная где и как будет использоваться накопитель, может его вообще по USB подключат, поэтому они указывают возможности железа (NVMe + PCIe), а вытянет ли их ваш конкретный сетап — это уже вопрос.Теперь вернёмся к NVMe на Hetzner. Я провел тот же тест с файлом в 20G, с блоками по 1M и 4k, всё длительностью 1 минута — думаю это уж точно в кэш не влезло (разве что в SLC на самом накопителе):
Разумеется, если я снижаюсь до 4k, то получаем сильное проседание по bandwidth, но если учесть что это виртуалка и на одном хосте их много, то оверхед и общая нагрузка сильно портят картину:
Очевидно что результаты, как вы выразились, "не впечатляющие", но если туда поставить обычные (не NVMe) SSD, они станут в несколько раз менее впечатляющими, а если учесть любовь некоторых хостеров строить хосты на ZFS, то всё совсем может оказаться печально (принудительный COW даже на блочных устройствах, компрессия и прочие радости — зато типа "супер надёжно").
Для сравнения — вот результат от OVH (VPS Comfort), где они тоже пишут про NVMe:
Очень похоже что что они ограничивают iops до 16k (слишком ровные результаты), соответственно при блоках в 4k сильно проседает и bandwidth. То же самое для 1M:
Тут уже видно что идёт ограничение по bandwitdh (слишком уж "ровно" оно на протяжении всего теста) — и это в два-три раза менее впечатляюще чем у Hetzner.
Собственно, я и тесты-то сделал не чтобы показать что в виртуалке можно получить максимум от NVMe — за счёт виртуализации это практически невозможно (очень большой оверхед по дороге к накопителю, особенно если виртуалок много), но использование NVMe вполне оправданно — потому что без них всё будет намного хуже, как минимум в разы, а на загруженных по i/o хостах может даже на один-два порядка — по той простой причине что условные 500K iops на NVMe дадут по 50k iops на десяти виртуалках, в то время как не менее реалистичные 100k на "обычных" SSD дадут соответственно по 10k, да и скорость поделится соответственно.
В качестве иллюстрации оверхеда (домашний сервер, PNY CS3030 1T как накопитель, KVM в proxmox), на этот раз на чтении:
Это гораздо более впечатляюще чем у Hetzner, но — это сервер на котором нет нагрузки, он фактически простаивает, да и процессор на нём в пару раз пошустрее (а он важен для пути накопитель=>lvm=>vm и обратно). Теперь тот же fio на хосте через LVM который подцеплен к виртуалке:
Как видите, просто за счёт того что это виртуалка, мы уже теряем около 40%(!) — и это она одна, другой нагрузки в системе нет и даже отключены все митигации как на хосте так и на виртуалке (mitigations=off) — разумеется если виртуалок с десяток или два, они что-то делают, а поскольку это хостер то и митигации по полной программе — мы просядем ещё больше, но это проседание будет намного менее заметным чем в случае SATA/SAS.
Так что если кто-то говорит что "VPS получит скорость NVMe" — он скорее всего таки врёт, но если этот кто-то говорит "на наших хостах стоят NVMe и это сильно повышает производительность [чем если бы стояли SATA/SAS]" — то это всё же скорее всего правда — об этом говорит и опыт с хостерами, и собственный (правда, не на Hyper-V).
Про RAID для NVMe тоже смешанные чувства — конечно, "один раз не считается", но я для эксперимента делал softRAID1 (mdadm) на двух потребительских NVMe (PNY CS3030 1T, посаженных на один PCIe x16 слот в X470D4U + Ryzen 3600X), разницы в скорости практически не было (при записи), рандомное чтение было быстрее но не помню на сколько — и это совсем не серверное железо. Увы, это было относительно давно, сборки уже нет, а результаты я не сохранял — но успех этого эксперимента позволяет мне верить что заявленное Hetzner наличие RAID 10 на их cloud серверах очень реалистично, вопреки выводам в статье про невозможность (или нецелесообразность) RAID на NVMe.
Получается Hetzner врёт? Они утверждают что у них RAID10 на хостах, диски NVMe, и судя по результатам тестирования внутри cloud-серверов, похоже таки на правду (fio на самом дешёвом cloud server, CX11, ему уже несколько лет):
В процессе тестирования использование процессора (vCPU, он там один) около 60%.
По любому быстрее чем обычный SSD — в разы. Результаты стабильные за все несколько лет, и не только на одном сервере, разумеется, и это с учётом того что на одном хосте крутится явно не один виртуальный.
Зачем же генерировать эти ужасно длинные RSA ключи по умолчанию, если можно сделать короткие ed25519 без потери качества?
Например,
ssh-keygen -t ed25519производит довольно короткую строку для паблик-ключа (её удобно копировать):ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH5KCvDh/K5lRJW1f4X+wpt0PIrLwvbtSf3YIqqh1/tY user@localhostОткуда такое пренебрежение к секретарям? С учётом того какую работу она выполняла и насколько хорошо, не говоря уже о переработках — совершенно неважно как называлась её должность.
Секретарь — это далеко не всегда только "подать кофе" и "организовать встречу", равно как и далеко не всегда топ-менеджер стоит тех денег которые ему платят.
Нет, логика у меня чуть другая — не ставить капканы там где поможет железная дверь. Блокировка системы с шифрованием диска — это защита от подавляющего большинства жуликов всех мастей во всех их градациях, в то время как подавляющее меньшинство с ресурсами и желанием добраться до моих данных не остановит даже бронепоезд.
Разумеется я не поставлю пароль "1234" на кошелёк, но и делать его самоуничтожающимся тоже не собираюсь — там просто нет таких сумм которые вызовут интерес братков с утюгом, а все остальные его оставят в покое как поймут что без утюга ничего не достать.
К тому же, любой капкан, т.е. изощренная система защиты, это вероятность её ложного срабатывания или случайного приведения в действие — что для большинства людей очень большой минус.
Властей мне бояться нечего — по крайней мере в моей стране, я честный налогоплательщик и проблем с законом не имею, но если уж власть сменится так что дойдёт до "мордой в пол" (очень маловероятный сценарий) то интересовать их будет явно не содержимое моего диска, для них при любом раскладе там ничего ценного — состояние моих финансов им и так известно, а скелетов в шкафах у меня нет. Если же это будет какая-то хитрая подстава (тоже очень маловероятно) — то мне как раз будет выгодно показать что у меня ничего "такого" нет, чем наоборот.
Как говорила героиня одного известного фильма — мне нечего скрывать, я просто не хочу ничего показывать.
Если то что стирается кому-то сильно нужно все эти меры мало помогут — разве что вы готовы пожертвовать своей жизнью и/или здоровьем (или ваших близких) ради того чтобы данные не попали в руки врагов. А в случае если не готовы — то через очень короткое время вы сами расскажете где лежит шифрованный бэкап, как из него получить данные и активно в этом поможете, даже в другой стране.
Во всех остальных случаях достаточно простой блокировки и шифрованного диска — украдут "простые жулики" или любопытные захотят посмотреть — ничего не получат и дальше не полезут.
Да ладно? Что может быть проще и быстрее оплаты кредиткой/телефоном с NFC? Это занимает пару секунд, равно как и перечисление с карты на карту (хотя это зависит от банка) — по простоте и скорости крипте это только снится, особенно на суммах до $100, не говоря уже о том что с криптой если нарвёшься на жулика хрен что вернешь, в отличие от карточки.
"Дешевле" тоже весьма расплывчатое понятие, зависит от конкретных участников — но оплата карточкой/переводом/налом потребителю стоит одинаково, все риски и сборы/затраты и так уже в цене товара или услуги, а вот с криптой всё совершенно иначе — если кто-то продаёт реальные услуги или товары, то ему нужно учесть риски связанные с волатильностью и выводом, а это в итоге "дешевле" не получится при всём желании, т.е. сама транзакция может оказаться с очень низкой стоимостью, но цена будет выше для плательщика.
Ясный пень если кто-то не хочет светить транзакции карточкой не воспользуется — но большинству это как раз пофиг, а вот что большинству совсем не пофиг — так это защищенность транзакций и волатильность (вот зачем нужно регулирование).
Что касается мнимой анонимности — то без комплекта бубнов крипта отслеживается не хуже чем карточки и уж точно проще чем нал, т.е. опять-таки сервис для маргиналов и прочих тёмных лошадок, и конечно же трейдеров всех мастей — для них тут просто рай.
Это будет иметь смысл если только они не будут замедлять выполнение. Обработка исключений — это дорого, очень дорого, в любом языке который это поддерживает — помню я нарвался на это первый раз в .Net когда работа с сокетами выбрасывала исключения на "connection refused" (которое совсем не исключение, если подумать) — это был кошмар, и с тех пор ситуация не поменялась, даже в C++.
Если у нас есть конструкция типа:
Причём, весь этот метод вполне может отвечать принципу "делать что-то одно" и даже быть достаточно коротким, но при этом в 50% случаев будет вылетать в oops (обрабатывая данные извне, к примеру) — если он вызывается сотни миллионов раз то исключения напрочь убьют производительность.
Гугль хорошо описал большинство "за" и "против" и в итоге отказался от них даже в C++, ну а ядро Линукса не то чтобы напичкано goto, но совсем ими не гнушается — представьте там исключения и прочие "правильные" меры (выделение метода — это тоже может влиять на производительность).
Так что как уже не раз сказали раньше — goto можно (и даже иногда нужно) использовать грамотно, а вот "тащить и не пущать" — это плохая практика, это всё равно что отказаться от утюгов и стиральных машин дома и заставить людей отдавать стирать и гладить вещи в спецсервисы, а то пожары случаются, водой заливает и всё такое. Да ещё и острые ножи, ножницы и бритвы можно запретить, ими ж порезаться можно, или даже кого-то убить.
К тому же, как показывает опыт, никакой супер-пупер язык не мешает писать говнокод, пусть там не будет goto но будет что-то другое, даже на всеми любимом Rust можно косячить по самое немогу (в логике и т.п. вещах).
Какой кликбейт… причём тут вообще Линукс как таковой если проблема в Remmina и её обвязке? Она может возникнуть на любой системе где стоит Remmina и её позволяют запускать (даже Windows), причём совсем необязательно даже из обработчиков URL.
В общем-то, в этом и суть НДС — это де-факто налог на потребление (нечто вроде "налога на продажи", только более гуманный с экономической точки зрения за счёт отсутствия каскадного эффекта) и оплачивать его должен именно конечный потребитель — производитель (поставщик товаров/услуг) его совсем не должен оплачивать.
То что в реальности налог в казну взимается с продавцов — это сделано исключительно для упрощения логистики сборов, в частности чтобы физлица после посещения магазинов не отщипывали свои кровные для налоговой отдельным платежом (представьте этот кошмар) — поэтому он заложен в конечной цене.
Вероятно всё дело в том что "все знали", я же говорил о тайной записи (т.е. когда собеседник не в курсе что его пишут, против записи и потом обнаруживает факт оной).
Также возможно что в вашем окружении все параноики и для них запись всех разговоров — норма, но всё же большинство людей относится к этому негативно.
Или вы думаете что законы (в ЕС в частности) которые наказывают за запись без согласия всех участников просто от балды появились?
В РФ и других странах бСССР защита личной жизни и приватности вообще не в моде, скорее даже наоборот — и это очень печально.
Такой товарищ был, и спалился он не на разглашении а банально по пьяни проболтался что пишет разговоры.
Если вам лично всё равно, пишут вас или нет, это не значит что всё равно остальным, и игнорировать вероятное нежелание других людей — как минимум неуважение, хотя в некоторых более продвинутых странах за запись (даже "для себя") без согласия предусмотрена ответственность.
Не знаю насчёт "сообщества сплетников", но факт того что вы пишете "втихую" косвенно говорит о том что вы не доверяете собеседникам, ожидаете подвоха, прикрываясь при этом "личным делом", при этом вам совершенно незнакомы границы личного и совершенно безразлично отношение других к этому вопросу, если бы это было не так вы бы знали что ваши права заканчиваются ровно там где начинаются права другого человека.
С другой стороны, я почти не сомневаюсь что вы категорически против сбора биометрии банками и прочими конторами, явно не желая оказаться в невыгодном положении в случае чего — но при этом сами собиратете ту же самую биометрику (в виде голоса) которая может быть использована если и не против вас, то против ваших собеседников, независимо от того хотите вы этого или нет — потому что безопасность хранения подобных записей вы обеспечить не можете.
Слухи и сплети это совершенно другое — во времена дипфейков коллекция сэмплов голоса это гораздо более неприятная вещь, да и демонстрация выборочных фрагментов записи — тоже, для людей которые не имеют публичных записей или выступлений это весьма актуальная проблема.
Увы, больше тут нечего сказать — но вполне вероятно кто-то использует вырванную из контекста часть записи вашего с кем-то разговора, которая разрушит вашу жизнь или как минимум доставит кучу неприятностей — я уверен что после это вы измените своё мнение. Если этого не случится — считайте что вам крупно повезло. Но разумеется, можете верить что с вами такого случится не может.
Где гарантия того что вы не будете эти разговоры давать послушать друзьям/родственникам "чисто для смеха" — или это типа не публикация?
А если записи утекут (даже в пересказанном виде) и пострадает другая сторона? Вы готовы этой стороне компенсировать неприятности? Или может вы обязуетесь хранить записи в охраняемом бункере, исключающем утечки?
Даже если закон этого не запрещает, записывать разговоры хотя бы без уведомления (хотя по хорошему нужно согласие) собеседника — это просто свинство, кроме редких случаев когда вам угрожают, шантажируют etc.
Был у меня один знакомый, который спалился на тайной записи разговоров — и мгновенно ушел в игнор у всех с кем общался, причём это были не собиратели долгов, не рекламщики, а люди которые считали его если не другом то как минимум товарищем. Последствия на этом не закончились, впрочем — с работы вылетел и долго искал новую, да и репутация у него упала ниже плинтуса.
Вы же в статье пишете:
а тут уже "пара случаев за всю историю".
Если таки и правда "раз в год" — что за бренд/модель? По своему опыту я столкнулся только с парой "естественных" смертей свитчей — это были D-Link, причём в выборке более 30 штук и все они проработали не менее 15 лет.
К сожалению, есть довольно продвинутые трекеры (и уже давно) с которыми дебаунсинг не работает — ссылки либо зашифрованы (т.е. их никак не идентифицировать и не очистить), либо просто являются идентификатором на трекере — т.е. до перехода на трекер точку назначения не узнать.
Такие ссылки конечно можно блокировать по списку трекеров, но тогда это будут просто мёртвые ссылки.
Вы пишите абстракцию один раз (тут дел-то на полчаса максимум) — а используете потом вечно (если она не сильно убивает производительность или если это неважно).
А краткость в Perl… как выше уже упоминалось — для себя или таких же — да, вполне, одноразовый или просто write-only код — тоже, но не забывайте — код лучше писать с расчётом на то что сопровождать и поддерживать его будет склонный к насилию психопат, который знает, где вы живёте — вполне возможно что вы им станете если посмотрите на свой код лет через 10-15.
Достаточно сохранить
%-,@-и@+, все остальные это производные от@-и@+:В свою очередь
%+это производная от%-.PS: Можно даже написать простой класс-обёртку вокруг этого, чтобы иметь результат как экземпляр класса, используя
$re->post, $re[1]etc (если его ещё нет на metacpan). Чуть-чуть пострадает производительность, конечно, но сохранение тоже не бесплатно.Знакомства (не отношения) IRL тоже ни к чему не обязывают, в общем-то, только риски чуть выше.
Вообще во всей этой индустрии классический конфликт — люди хотят безопасно и надёжно, но в то же время анонимно до последнего момента, а это в принципе несовместимо, и они не готовы пожертвовать своей анонимностью (= пройти полную идентификацию на сервисе).
Если, как уже выше упоминалось, сделать сервис который будет гарантировать что конкретную личность за профилем можно найти при необходимости (с паспортом, адресом и видео которое подтверждает связь паспорта и фото в профиле, разумеется не для публичного доступа а в архив на случай запроса из полиции) — то все эти жулики (и даже просто неадекваты) выпиливаются очень быстро ибо подставные личности быстро закончатся, заодно будет безопасно, ибо если что — то ниточки быстро раскручиваются, при желании разумеется.
При этом сами профили можно оставить относительно анонимными — без реальных имён, адресов etc — только реальное фото и тэг "верифицирован" — в итоге и овцы сыты, и волки целы. Те кто не хочет "палиться" (типа "давно здесь сижу") могут обновлять фотки (только свои, т.е. с модерацией) и никнейм — на статус профиля это не влияет.
Правда, реализация подобного потребует железобетонных гарантий отсутствия утечек реальных данных, что в принципе реализуемо технически но никому (из владельцев сервисов) неинтересно.