Довольно хорошо представляю. Но напомните мне, что случилось с теми кто потерял свои вложения после ряда неприятностей на различных криптобиржах? Вернули они их? Был ли у них шанс вернуть хоть что-то хотя бы через суд?
Я уже молчу про случай когда вы банально теряете ключ от криптокошелька — без регулирования и процедур, и, соответственно, привязки вас как гражданина (т.е. по паспорту) к конкретному кошельку и истории транзакций, ваши шансы восстановить контроль просто нулевые, в то время как потеря данных для доступа к счёту в банке — просто мелкая неприятность, не более того.
Закрытие банка (точнее, регулируемого финансового учреждения), кстати, тоже не проблема — вклады (обычные, не многомилионные) застрахованы, а если Facebook со своей либрой накроется медным тазом (да, звучит невероятно — пока), или решит что им всё надоело — что вы сделаете? Поплачете?
Проблема с нерегулироемой криптой как раз в том что простые пользователи имеют много шансов попасть в неприятности, они ничем и никем не защищены — и вполне очевидно что регуляторы не желают наблюдать у себя под окнами толпы разоренных граждан, которые потеряли всё — и я их вполне понимаю.
Но если вы неуловимый почти анонимный эмитент или криптобиржа, с компанией-пустышкой зарегистрированной на всем известных островах — да, вам все эти проблемы конечно пофиг, никто под окнами не соберётся, да и ответственности никакой.
Представьте себе банки и платежные системы без регулирования — захочется вам такого?
Вас счёт могут в любой момент закрыть или заблокировать без компенсанции, онлайн-платеж не отозвать даже если он отправлен мошеннику, овердрафт может обойтись в 50% годовых, etc. (вспомните микрокредитные компании как частный случай отсутствия регулирования).
И толпы вчерашних студентов (в глазах которых вы сильно устаревший динозавр) хотя вас сожрать чтобы делать все тоже самое, но в 10 раз хуже и в два раза дешевле.
В месте где готовы взять на работу тех кто будет делать в 10 раз хуже, да ещё и дешевле — уважающий себя профессионал с десятками лет опыта и сам работать не будет.
К тому же, всегда есть консалтинг — там как раз студентов не берут, а если и берут то для принеси-подай (на первые лет 5-10).
Многоязычность — это здорово. Непонятно только одно — почему переключение языка внизу довольно таки длинной страницы?
Ведь если человек увидел страницу на незнакомом или плохо понятном языке — то выбор языка это первое что он захочет увидеть вверху страницы, а прокрутить до конца не все догадаются, особенно если крутить долго.
При чтении/записи SSD оперируют страницами, а не секторами, размер страницы может быть от 2 до 16 кб (зависит от конкретной модели), соответственно запись 1 байта никак не может занять меньше 2K в лучшем случае.
Ситуация ухудшается если вам нужно не записать а изменить 1 байт — сначала он прочитает страницу с этим байтом, поменяет в прочитанном блоке этот самый байт, а потом пойдёт искать пустую страницу в которую его можно записать, отметив старую как «грязную» (т.е. использованную но не доступную для записи).
Всё усложняется тем что хоть писать и можно на уровне страницы, запись не может быть сделана «поверх» — сначала нужно стереть аж целый блок (состоящий из многих страниц, от 256K до 4M), и только потом писать.
Если пустых страниц нет (диск был записан полностью как минимум один раз, при этом TRIM не использовался — частый случай когда SSD используются в RAID), то всё просто кошмарно — контроллер сначала читает весь блок, где находится тот злосчастный байт, читает его весь (да, до 4M), стирает его и перезаписывает полностью. На самом деле чуть сложнее — он может попытаться начать джонглировать блоками в рамках оптимизации износа и сборки мусора, ища то что реже всего стиралось и перетасовывая найденное в процессе, вовлекая в процесс резервную зону (недоступную для обычного использования).
Разумеется, всё это дорого обходится — производительность падает, и чем дальше тем больше. TRIM помогает сильно улучшить ситуацию, но, как я уже сказал раньше, не все RAID контроллеры его поддерживают (увы), хотя для «домашних» применений (нет RAID и система поддерживает TRIM) всё достаточно неплохо (если диск под завязку не забит).
На самом деле, в этом нет ничего сложного — максимум четыре часа на чтение доков и одноразовую настройку с тестами осилит любой кто не боится командной строки, спецадмин или суперскиллы для этого не нужны.
Поскольку почти всё обеспечивается нативно самим Postgres, всё остальное лишь удобная обвязка вокруг этого.
Насчёт дисков… не скажу что нужно что-то супер-пупер. На примере одного из своих проектов — небольшая база около 100 гиг, обновляется примерно на 10% ежедневно, непрервные бэкапы за последние 5 дней (с базовым каждый день и возможностью отката в к любой транзакции в этом интервале) занимают около 250 гиг (бэкап на NAS с ZFS — за счёт компрессии и дедупликации получается такая экономия, сетка 1 Gbps), один базовый бэкап выполняется около 45 минут.
Все комплектующие становятся «изношенными» после пары лет работы, с именем или без.
Но судить о железе по сертификатам как-то не очень логично — я, к примеру, из принципа не плачу деньги за сертификаты (именно потому что платный от бесплатного DV отличается только затратами), но никогда не экономлю на железе (хотя и избегаю железа с именем — потому что оно просто дороже, но без ощутимого преимущества, опыт эксплуатации разного оборудования за последние 20 лет показывает что и с именем и без ломаются одинаково, а вот затраты на восстановление/ремонт существенно выше в случае брендов).
Как уже выше сказали — в данном случае нет совершенно никакого смысла платить за что-то, если нет разницы в платном и бесплатном.
«экономить копейки» это обычно в ущерб качеству, здесь же никакого ущерба нет. Или если хостер покупает не «брендовое» оборудование (которое ничуть не хуже, но стоит в пару раз дешевле) — это тоже «экономить копейки»?
Или это вопрос принципа — раз «коммерсант» — то покажи что способен платить? Вот так и появляются помпезные офисы с барами и танцполами, и цены на услуги взлетают до небес.
Инкрементального нет в силу того что есть гораздо более интересная нативная вещь — непрерывный бэкап (continuous backup), с возможностью отката на любую транзакцию между последним base backup и текущим состоянием. barman это умеет, как и уже упомянутый раньше wal-g.
Есть даже покруче возможность — держать рядом сервер с задержкой транзакций (доступный для выполнения запросов на чтение), который будет отставать от мастера на заданное время.
Вообще-то как раз полезно, потому что иногда не поймешь — то ли сеть пропала, то ли сайт вообще недоступен (то есть не отвечает) — а вот индикация того что он просто тормозит этот вопрос проясняет.
Я говорил про Linux. Как дела обстоят в Windows я не в курсе, а в Android WG точно не в ядре (если без рута).
Несколько некорректно сравнивать ssh с туннелем — потому что ssh может себе позволить шифровать длинные блоки и отправлять их одним syscall, в то время как для туннеля приходится каждый блок (обычно один пакет) обрабатывать и собирать отдельно (речь про туннель поверх UDP).
Если очень грубо — OpenVPN вынужден каждый (почти) пакет получать из ядра (а это переключение контекста), потому что-то с ним делать и отдавать обратно в ядро (tun/tap) — итого имеем минимум два syscall на пакет не считая дополнительного копирования данных (в память процесса и из неё). Можно оптимизировать вторую часть, т.е. накапливать принятые пакеты и отдавать в tun/tap пачками после обработки, но это не всегда оптимально и возможно. Можно даже оптимизировать первую часть, получая пакеты пачками (есть для этого фишки в линухе), но всё равно оверхед будет ощутим.
Таким образом, нагрузка на процессор очень сильно возрастает, и мы получаем естественное ограничение скорости передачи с привязкой к мощности процессора — дополнительно к скорости шифрования.
Wireguard может позволить себе делать всё это в самом ядре, без переключения контекста, сильно сокращая накладные расходы — никаких лишних копий, никаких переключений контекста в процессе обработки потоков, не говоря уже о прямом доступе к буферам сокетов/адаптеров, таким образом значительно более эффективно используя процессор.
Проверьте скорость шифрования AES256 (openssl speed aes) и сравните со скоростью передачи openvpn с этим же шифром — первый покажет явно не меньше 100MB/s даже на средненьком интеле (даже RPi4 дает > 60 MB/s), а вот второй загнется где-то уже в районе 10-20 MB/s (т.е. выдаст не больше 100-200 мегабит на гигабитном линке, при этом загружая процессор на 100%).
Есть масса причин по которым человек может оказаться в неположенном месте или в неположенное время на проезжей части, и часть из них полностью или частично вне его контроля.
К тому же, есть люди которые могут быть весьма полезны для общества, но в то же время мало приспособленные для перехода дорог, и нет, они не в состоянии это контролировать — да-да, тот самый «идиот в наушниках» вполне может оказаться гениальным хирургом после трёх смен подряд.
Как выше уже заметили, «автомобиль — это источник повышенной опасности», и водителям (как живым, так и не очень) это нужно учитывать сильнее чем пешеходам, по той простой причине что последние не имеют шансов в случае чего, в то время как первым ну совсем ничего не будет за дополнительную осторожность.
Как вы это представляете? Допустим, есть популярный глобальный сервис, у его DNS запросили инфу порядка тысячи разных кэширующих резолверов — как ему надежно сбросить кэш у каждого из них?
Запонимать всех кто (и когда) спрашивал и слать «сбросить кэш»? При этом, без криптографии тут не обойдётся — все запросы на сброс кэша должны быть подписаны, а резолверы должны их валидировать, и это не считая того что эту «память» нужно хранить где-то постоянно — иначе холодный рестарт сервера (или переход на другой сервер в пуле) не сбросит кэш.
Технически это конечно реализуемо, но усложняет систему неимоверно, а если учесть что клиенты иногда запрашивают кэширующие резолверы совсем не первого уровня, да и самих резолверов могут быть не тысячи а десятки тысяч, то всё становится очень мрачно.
GL.iNet имеет несколько моделей с нативной (из коробки) поддержкой WireGuard.
Памяти и флеша тем не очень много (хотя и хватает для фич типа прокси и прочего), но по скорости всё ок — как SOHO рутер очень даже. Цены тоже вполне демократичные.
Поскольку почти любой софт можно использовать для добра или для зла, а определения добра и зла зависят от законов, традиций и морали в конкретной юрисдикции или обществе в конкретный момент времени, подобная лицензия не может работать в принципе.
Например, банальный калькулятор можно использовать для расчёта параметров моста, но в то же время его можно использовать для расчётов параметров бомбы, в свою очередь, как и мост так и бомба могут быть использованы для добра или для зла, не говоря уже о том что что-то изначально созданное для условного добра может быть впоследствии использовано для не менее условного зла.
Конечно, в лицензии можно конкретно прописать что считать добром и злом, но даже в этом случае представители условного зла вряд-ли будут выполнять условия лицензии, если софт им действительно нужен, точно так же как софтверные пираты не выполняют условий лицензии.
Временное отсутствие возможности сделать что-либо в бета-версии не является запретом — это просто отсутствие возможности. Знаете, бывают ведь просто сны.
Или вы утверждаете что вас изолировали от мира, интернета и заставили пользоваться только этой бета-версией хрома, причем без права апгрейда, да ещё и пожизненно?
Пока же вы утверждаете что отсутствие возможности сделать что-то в экспериментальном продукте является запретом. Тогда можете добавить в список запретов dig в текущих дистрибутивах — там тоже нельзя выбрать не то что свой, а вообще какой-либо DoH.
For a first milestone, we are considering an auto-upgrade approach.
…
… this would upgrade the protocol used for DNS resolution while keeping the user’s DNS provider unchanged.
Как можно увидеть — исключительно в целях заботы о пользователях, да.
Текст явно говорит как раз обратное — я же процитировал выше и даже выделил. Или вы как-то иначе переводите «we have no plans to force users to change their DNS provider» и «user’s DNS provider of choice»?
Выше вы сказали:
А нет, уже запрещает.
Будьте так любезны, процитируйте релевантный фрагмент где вы увидели «запрещает».
Что касается «белого списка» — там же явно написано, что это в рамках эксперимента, и я даже могу понять почему список существует и ограничен — чтобы пользователь случайно не выстрелил себе в ногу, поставив там провайдера который не поддерживает DoH, со всеми вытекающими.
Рассматривать невозможность вносить свой сервер на этапе эксперимента, пока всё отлаживается, как «запрет» — это несколько притягивать за уши.
Если выйдет версия Хрома с «релизом» DoH (т.е. после окончания эксперимента), где будет жёстко ограничен «белый список» и где не будет возможности ставить свои сервера — вот тогда можно будет говорить о «запрете», хотя даже в этом случае Хром не будет единственным браузером.
Я понимаю ваше беспокойство и неверие в добрые начинания Гугля, но всё же давайте будем последовательны — на данный момент ни о каких запретах или принуждениях речи нет, и декларируются вполне адекватные намерения.
Я уже молчу про случай когда вы банально теряете ключ от криптокошелька — без регулирования и процедур, и, соответственно, привязки вас как гражданина (т.е. по паспорту) к конкретному кошельку и истории транзакций, ваши шансы восстановить контроль просто нулевые, в то время как потеря данных для доступа к счёту в банке — просто мелкая неприятность, не более того.
Закрытие банка (точнее, регулируемого финансового учреждения), кстати, тоже не проблема — вклады (обычные, не многомилионные) застрахованы, а если Facebook со своей либрой накроется медным тазом (да, звучит невероятно — пока), или решит что им всё надоело — что вы сделаете? Поплачете?
Проблема с нерегулироемой криптой как раз в том что простые пользователи имеют много шансов попасть в неприятности, они ничем и никем не защищены — и вполне очевидно что регуляторы не желают наблюдать у себя под окнами толпы разоренных граждан, которые потеряли всё — и я их вполне понимаю.
Но если вы неуловимый почти анонимный эмитент или криптобиржа, с компанией-пустышкой зарегистрированной на всем известных островах — да, вам все эти проблемы конечно пофиг, никто под окнами не соберётся, да и ответственности никакой.
Вас счёт могут в любой момент закрыть или заблокировать без компенсанции, онлайн-платеж не отозвать даже если он отправлен мошеннику, овердрафт может обойтись в 50% годовых, etc. (вспомните микрокредитные компании как частный случай отсутствия регулирования).
Вы точно этого хотите?
В месте где готовы взять на работу тех кто будет делать в 10 раз хуже, да ещё и дешевле — уважающий себя профессионал с десятками лет опыта и сам работать не будет.
К тому же, всегда есть консалтинг — там как раз студентов не берут, а если и берут то для принеси-подай (на первые лет 5-10).
Ведь если человек увидел страницу на незнакомом или плохо понятном языке — то выбор языка это первое что он захочет увидеть вверху страницы, а прокрутить до конца не все догадаются, особенно если крутить долго.
Ситуация ухудшается если вам нужно не записать а изменить 1 байт — сначала он прочитает страницу с этим байтом, поменяет в прочитанном блоке этот самый байт, а потом пойдёт искать пустую страницу в которую его можно записать, отметив старую как «грязную» (т.е. использованную но не доступную для записи).
Всё усложняется тем что хоть писать и можно на уровне страницы, запись не может быть сделана «поверх» — сначала нужно стереть аж целый блок (состоящий из многих страниц, от 256K до 4M), и только потом писать.
Если пустых страниц нет (диск был записан полностью как минимум один раз, при этом TRIM не использовался — частый случай когда SSD используются в RAID), то всё просто кошмарно — контроллер сначала читает весь блок, где находится тот злосчастный байт, читает его весь (да, до 4M), стирает его и перезаписывает полностью. На самом деле чуть сложнее — он может попытаться начать джонглировать блоками в рамках оптимизации износа и сборки мусора, ища то что реже всего стиралось и перетасовывая найденное в процессе, вовлекая в процесс резервную зону (недоступную для обычного использования).
Разумеется, всё это дорого обходится — производительность падает, и чем дальше тем больше. TRIM помогает сильно улучшить ситуацию, но, как я уже сказал раньше, не все RAID контроллеры его поддерживают (увы), хотя для «домашних» применений (нет RAID и система поддерживает TRIM) всё достаточно неплохо (если диск под завязку не забит).
Поскольку почти всё обеспечивается нативно самим Postgres, всё остальное лишь удобная обвязка вокруг этого.
Насчёт дисков… не скажу что нужно что-то супер-пупер. На примере одного из своих проектов — небольшая база около 100 гиг, обновляется примерно на 10% ежедневно, непрервные бэкапы за последние 5 дней (с базовым каждый день и возможностью отката в к любой транзакции в этом интервале) занимают около 250 гиг (бэкап на NAS с ZFS — за счёт компрессии и дедупликации получается такая экономия, сетка 1 Gbps), один базовый бэкап выполняется около 45 минут.
Но судить о железе по сертификатам как-то не очень логично — я, к примеру, из принципа не плачу деньги за сертификаты (именно потому что платный от бесплатного DV отличается только затратами), но никогда не экономлю на железе (хотя и избегаю железа с именем — потому что оно просто дороже, но без ощутимого преимущества, опыт эксплуатации разного оборудования за последние 20 лет показывает что и с именем и без ломаются одинаково, а вот затраты на восстановление/ремонт существенно выше в случае брендов).
«экономить копейки» это обычно в ущерб качеству, здесь же никакого ущерба нет. Или если хостер покупает не «брендовое» оборудование (которое ничуть не хуже, но стоит в пару раз дешевле) — это тоже «экономить копейки»?
Или это вопрос принципа — раз «коммерсант» — то покажи что способен платить? Вот так и появляются помпезные офисы с барами и танцполами, и цены на услуги взлетают до небес.
Есть даже покруче возможность — держать рядом сервер с задержкой транзакций (доступный для выполнения запросов на чтение), который будет отставать от мастера на заданное время.
Несколько некорректно сравнивать ssh с туннелем — потому что ssh может себе позволить шифровать длинные блоки и отправлять их одним syscall, в то время как для туннеля приходится каждый блок (обычно один пакет) обрабатывать и собирать отдельно (речь про туннель поверх UDP).
Если очень грубо — OpenVPN вынужден каждый (почти) пакет получать из ядра (а это переключение контекста), потому что-то с ним делать и отдавать обратно в ядро (tun/tap) — итого имеем минимум два syscall на пакет не считая дополнительного копирования данных (в память процесса и из неё). Можно оптимизировать вторую часть, т.е. накапливать принятые пакеты и отдавать в tun/tap пачками после обработки, но это не всегда оптимально и возможно. Можно даже оптимизировать первую часть, получая пакеты пачками (есть для этого фишки в линухе), но всё равно оверхед будет ощутим.
Таким образом, нагрузка на процессор очень сильно возрастает, и мы получаем естественное ограничение скорости передачи с привязкой к мощности процессора — дополнительно к скорости шифрования.
Wireguard может позволить себе делать всё это в самом ядре, без переключения контекста, сильно сокращая накладные расходы — никаких лишних копий, никаких переключений контекста в процессе обработки потоков, не говоря уже о прямом доступе к буферам сокетов/адаптеров, таким образом значительно более эффективно используя процессор.
Проверьте скорость шифрования AES256 (openssl speed aes) и сравните со скоростью передачи openvpn с этим же шифром — первый покажет явно не меньше 100MB/s даже на средненьком интеле (даже RPi4 дает > 60 MB/s), а вот второй загнется где-то уже в районе 10-20 MB/s (т.е. выдаст не больше 100-200 мегабит на гигабитном линке, при этом загружая процессор на 100%).
К тому же, есть люди которые могут быть весьма полезны для общества, но в то же время мало приспособленные для перехода дорог, и нет, они не в состоянии это контролировать — да-да, тот самый «идиот в наушниках» вполне может оказаться гениальным хирургом после трёх смен подряд.
Как выше уже заметили, «автомобиль — это источник повышенной опасности», и водителям (как живым, так и не очень) это нужно учитывать сильнее чем пешеходам, по той простой причине что последние не имеют шансов в случае чего, в то время как первым ну совсем ничего не будет за дополнительную осторожность.
Запонимать всех кто (и когда) спрашивал и слать «сбросить кэш»? При этом, без криптографии тут не обойдётся — все запросы на сброс кэша должны быть подписаны, а резолверы должны их валидировать, и это не считая того что эту «память» нужно хранить где-то постоянно — иначе холодный рестарт сервера (или переход на другой сервер в пуле) не сбросит кэш.
Технически это конечно реализуемо, но усложняет систему неимоверно, а если учесть что клиенты иногда запрашивают кэширующие резолверы совсем не первого уровня, да и самих резолверов могут быть не тысячи а десятки тысяч, то всё становится очень мрачно.
Памяти и флеша тем не очень много (хотя и хватает для фич типа прокси и прочего), но по скорости всё ок — как SOHO рутер очень даже. Цены тоже вполне демократичные.
А что делают хостеры, особенно VPS, с вашими данными — вы знаете?
Например, банальный калькулятор можно использовать для расчёта параметров моста, но в то же время его можно использовать для расчётов параметров бомбы, в свою очередь, как и мост так и бомба могут быть использованы для добра или для зла, не говоря уже о том что что-то изначально созданное для условного добра может быть впоследствии использовано для не менее условного зла.
Конечно, в лицензии можно конкретно прописать что считать добром и злом, но даже в этом случае представители условного зла вряд-ли будут выполнять условия лицензии, если софт им действительно нужен, точно так же как софтверные пираты не выполняют условий лицензии.
Или вы утверждаете что вас изолировали от мира, интернета и заставили пользоваться только этой бета-версией хрома, причем без права апгрейда, да ещё и пожизненно?
Впрочем, неважно. Ставьте файрфокс, я не против.
Пока же вы утверждаете что отсутствие возможности сделать что-то в экспериментальном продукте является запретом. Тогда можете добавить в список запретов dig в текущих дистрибутивах — там тоже нельзя выбрать не то что свой, а вообще какой-либо DoH.
Впрочем, процитирую самого гугля:
Как можно увидеть — исключительно в целях заботы о пользователях, да.
Выше вы сказали:
Будьте так любезны, процитируйте релевантный фрагмент где вы увидели «запрещает».
Что касается «белого списка» — там же явно написано, что это в рамках эксперимента, и я даже могу понять почему список существует и ограничен — чтобы пользователь случайно не выстрелил себе в ногу, поставив там провайдера который не поддерживает DoH, со всеми вытекающими.
Рассматривать невозможность вносить свой сервер на этапе эксперимента, пока всё отлаживается, как «запрет» — это несколько притягивать за уши.
Если выйдет версия Хрома с «релизом» DoH (т.е. после окончания эксперимента), где будет жёстко ограничен «белый список» и где не будет возможности ставить свои сервера — вот тогда можно будет говорить о «запрете», хотя даже в этом случае Хром не будет единственным браузером.
Я понимаю ваше беспокойство и неверие в добрые начинания Гугля, но всё же давайте будем последовательны — на данный момент ни о каких запретах или принуждениях речи нет, и декларируются вполне адекватные намерения.