Если статья будет про методы обхода блокировок, то не важно бут там VPN или почтовые голуби, она всё равно будет подпадать под действие этого закона.
В то же время если ты пишешь статью про то как настроить VPN сервер, как настроить VPN клиент, а рядом положишь статью про настройку маршрутизации, NAT, маскарадинг и прочее, то ты же не пишешь про способы обхода блокировок. А то что некоторые несознательные граждане могут вопсользоваться полученный информацией для противоправных действи, плохие, плохие граждане. Но если ты ничего не писал про способы обхода блокировок, а только про технические аспекты технологий, то по идее такое блокировать не должны.
Тут правда есть нюанс. Одно дело буква закона, другое дело исполнители. Но от глупости исполнителей ни одни закон не защищён.
Просто напоминаю, до релиза 75 дней. Уже поздно игру делать. По хорошему сейчас должно идти финальное тестирование и исправление багов. У тебя уже должен быть проработан весь геймплей, все сюжетные задания и тестировщики должны искать баги уровня "а не будет ли софтлока если ГГ найдёт сапоги скороходы до того как ему выдадут квест на их поиски" и заниматься мелкими правками баланса по типу ХП врагов и размер окна для парирования.
Немного не так. Сам тендер да, кто дешевле. Однако вся магия прячется в условиях тендра. Представитель завода идёт в баню с представителем заказчика и потом в условиях тендра появляется строчка "не менее ХХХ балов за локализацию". А потом "ой, на тендер пришёл всего один единственный исполнитель".
Сертификат выданный Let's Encrypt делает именно то, для чего был создан. Подтверждает, что полученные данные выданы именно тем сервером, который обслуживает этот домен. И не были модифицированы по пути. Всё. Ничего большего он не делает.
По поводу диаграммы направленности. Уже давно существует Иридиум Go, размером с обычный компактный LTE модем и всенаправленной антенной. И он умеет подключаться к спутниковому интернету.
Да скорость у Иридиума Go ниже плинтуса. Да тарифы негуманные. Однако факт остаётся фактом. В габарите обычного мобильника и со всенаправленной антенной реально достучаться до спутника.
И тут нужно делать поправку на то, что Иридиум это старая система. Современные технологии могут улучшить эти показатели.
То есть как это будет на практике работать нужно будет ещё посмотреть. Но в теории мне кажется вполне реальным установить соединение на какой то сверх низкой скорости. Понятно, что если нужны мегабиты, то бери тарелку, но если скорости будет хватать хотя бы на текстовую переписку в мессенжере то это уже будет круто. Даже если для этого придётся купить отдельный модем по типу Иридиум GO
Выборка то может и достаточная. Однако это работает только если выборка репрезентативная. То есть например если из всех людей взять случайные 20к то это одно дело. А если если проводить опрос "пользуетесь ли вы интернетом" на сайте яндекса, то даже 100к опрошенных будут не очень показательными.
В данном случае мы очевидно видим довольно много категорий людей которые не попали в выборку. Вот что то мне подсказывает, что люди часто использующие VPN для обхода блокировок не горят желанием добровольно ставить трекер отслеживающий посещаемые сайты.
Лень искать фото, но таких "лайфхакеров" с ведёрками там было не оди и не два. В некоторых местах из них даже очереди скапливались. И обычным посетителям приходилось ждать пока очередная быдлосемейка наполнит все свои тазики и ведёрки.
Так что ИМХО. Основная проблема статьи в позиционировании. Если бы вместо тезиса "ищем халяву" было бы "интересно, а какой максимальной плотности данных получится добиться, прежде чем алгоритмы сжатия начнут портить информацию". Вроде мелочь, но другая подача и статья бы совсем по другому бы воспринималась.
Наш учитель в институте любил фразу "точное решение ни кому не нужно, людям нужно решение с достаточной точностью".
Это стандартные типы данных. Все знают, что работа с вещественными числами в компьютере сопряжена с потерей точности. Но в большинстве случаев эти типы дают достаточно правильный результат, чтобы на такие вещи закрыть глаза
К слову в целочисленные типы данных тоже можно далеко не любое число записать.
Ну если так рассуждать, то давай создавать отдельную платёжную систему под каждый магазин. ПятёрочкаКард для оплаты покупок в Пятёрочке, МагнитКард для оплаты покупок в Магните. Причём разные платёжные системы будут обслуживаться разными банками. Конкуренция во все щели.
А в чём обман? Банк установил курс обмена. Мне этот курс показался выгодным и я совершил сделки по этому курсу.
То есть предположим ты решил купить квартиру. Смотришь есть отличное предложение, всего за 5 лямов. Совершаешь сделку, уже начинаешь завозить вещи в новую квартиру, а тут приходит продавец и говорит "ты незаконно обогатился. Такая квартира стоит минимум десятку.". Отдавай мне ещё 5 лямов.
А можно с этого момента по подробнее. Я понимаю когда мы конектимся к серверу в интернете. Сервер может быть перегружен. Находится в другом конце мира. Пакеты могут ходить окольными путями. И т. д.
Но если я нахожусь с NTP сервером в одной сети и пинги там менее 1мс, то откуда берётся 30мс?
Хранить данные в текстовом файле... Это конечно сильно. Ну да ладно. Не это меня больше всего зацепило.
В первую очередь в глаза бросился бардак с самими сертификатами. Три разных формата ссылок в сертификатах (и не факт, что это полный набор, там где три там и четыре и пять, просто возможно они ещё не попадались). Не ужели утвердить единый формат QR кодов это так сложно? Вот по одному только этому факту можно понять какой бардак творится среди разработчиков сервиса. Выглядит так, как будто бы там несколько комманд разработчиков, которые между собой ни как не взаимодействуют. Из за чего каждый делает свой костылесипед.
Как человек имеющий дело со сложными релейными схемами скажу так. Всё зависит от сложности алгоритма. Если алгоритм управления это что-то простое. Типа "если одновременно выполняется эти условия и не чыполняются эти" и вся схема управления это пара реле, то да, реле проще и надёжнее.
Но вот как только схема управления хоть чуть чуть усложняется, то лучше МК. Релейные схемы позволяют реализовывать очень сложные штуки. Но в то же время их сложно отлаживать и главное у тебя нет права на ошибку. Если ошибку в ПО можно исправить просто перепрошивкой, то ошибку в релейной схеме малой кровью обычно не решить.
Так как раз используют. Если растворить корпус подобной микросхемы то внутри ты увидишь, что если там внутри несколько частей разделённых диэлектриком. И связь через между частями микросхемы осуществляется при помощи света, индуктивности или ёмкости (в зависимости от технологии). Так что вполне себе физическое разделение.
Большинство выходов МК могут быть настроены для работы в режиме пуш-пул. Никакой дополнительный подтягикующий резистор им не нужен. Единственный резистор который нужен это токоограничивающий, чтобы ток заряда/разряда затвора не превышал рекомендуемый ток для порта МК.
По поводу драйвера. Для работы с маленькими транзисторами драйвер не нужен. Драйвер нужен только для могучих транзисторов с большой ёмкостью и напряжением затвора. Однако мощный полевой транзистор МК в одиночку тоже не раскачает. Так что...
Тут вот какой нюанс. Аппаратные ключи специально проектируются таким образом, чтобы их невозможно было скопировать. То есть предполагается, что ключом может воспользоваться только тот, у кого есть к нему физический доступ.
В случае использования USB over IP ключом может воспользоваться кто угодно, кто сможет подключиться. То есть "физическое обладание ключом" заменяется на "задача контроля доступа". И тут весь вопрос в том, как это будет реализовано. Можно конечно удариться в аниме и соединить сервер с физическим ключом и клиент отдельной витой парой по типу точка-точка с авторизацией по физическому ключу... В теории так сделать можно, и это будет супер надёжно и безопасно, но мы же понимаем, что ни кто так делать не будет. А как только мы упрощаем способ подключения, то мы автоматом понижаем безопасность решения. То есть грубо говоря если у нас авторизация просто по паролю, а доступ есть не только из локальной сети, а через интернет, то это конечно удобно для пользователей, но считай, что никакого ЭЦП у тебя нет, а есть только пароль. Так как любой кто знает пароль может воспользоваться твоей ЭЦП. Если проводить аналогию, это всё равно, что поставить дорогую железную дверь, но ключ хранить под ковриком.
И обрати внимание. Я не говорю, что это априори плохо. Как ни странно формальное снижение безопасности по факту может даже увеличивать безопасность. Приведу что имеется в виду. Предположим у нас есть дверь на склад. Огромная сейфовая дверь, способная выдержать прямое попадание из РПГ. С электронным замком с биометрией и одноразовыми паролями подписанными лично ЭЦП директора. Круто? Круто! Но через неделю в двери будет лежать деревянный брусочек чтобы дверь не закрывалась. И внезапно оказывается, что китайская картонная дверь с авторизацией по обычным NFC меткам безопасней, так как люди не будут лениться её закрывать.
Так, что я не говорю, что USB over IP это однозначно плохо. Просто его использование снижает безопасность и поэтому теперь уже ты должен придумать как организовать контроль доступа так, чтобы компенсировать это снижение безопасности.
В телевизоре черезстрочная развёртка. Частота кадров 50i обозначает, что вещание идёт со скоростью 50 полукадров в секунду. Один полукадр с чётными линиями, второй полукадр с нечётными. То есть если брать отдельную строку, то она обновлялась через кадр. То есть 50/2 = 25.
В теории конечно же можно хранить где то буфер кадра и обновлять всегда экран целиком. Но первые телевизоры были аналоговыми устройствами. Никаких буферов кадра в них и в помине не было. Что приходило из эфира то напрямую и показывали. А мерцание скрашивалось из за того, что у люминофора есть послесвечение + при плохой фокусировке одна строка частично подсвечивала соседние.
Если статья будет про методы обхода блокировок, то не важно бут там VPN или почтовые голуби, она всё равно будет подпадать под действие этого закона.
В то же время если ты пишешь статью про то как настроить VPN сервер, как настроить VPN клиент, а рядом положишь статью про настройку маршрутизации, NAT, маскарадинг и прочее, то ты же не пишешь про способы обхода блокировок. А то что некоторые несознательные граждане могут вопсользоваться полученный информацией для противоправных действи, плохие, плохие граждане. Но если ты ничего не писал про способы обхода блокировок, а только про технические аспекты технологий, то по идее такое блокировать не должны.
Тут правда есть нюанс. Одно дело буква закона, другое дело исполнители. Но от глупости исполнителей ни одни закон не защищён.
Просто напоминаю, до релиза 75 дней. Уже поздно игру делать. По хорошему сейчас должно идти финальное тестирование и исправление багов. У тебя уже должен быть проработан весь геймплей, все сюжетные задания и тестировщики должны искать баги уровня "а не будет ли софтлока если ГГ найдёт сапоги скороходы до того как ему выдадут квест на их поиски" и заниматься мелкими правками баланса по типу ХП врагов и размер окна для парирования.
Немного не так. Сам тендер да, кто дешевле. Однако вся магия прячется в условиях тендра. Представитель завода идёт в баню с представителем заказчика и потом в условиях тендра появляется строчка "не менее ХХХ балов за локализацию". А потом "ой, на тендер пришёл всего один единственный исполнитель".
Возможно это калька с американцев. Только у них RUD (rapid unscheduled disassembly) звучит как шутка. А у нас в шутку забыли добавить юмор.
Сертификат выданный Let's Encrypt делает именно то, для чего был создан. Подтверждает, что полученные данные выданы именно тем сервером, который обслуживает этот домен. И не были модифицированы по пути. Всё. Ничего большего он не делает.
По поводу диаграммы направленности. Уже давно существует Иридиум Go, размером с обычный компактный LTE модем и всенаправленной антенной. И он умеет подключаться к спутниковому интернету.
Да скорость у Иридиума Go ниже плинтуса. Да тарифы негуманные. Однако факт остаётся фактом. В габарите обычного мобильника и со всенаправленной антенной реально достучаться до спутника.
И тут нужно делать поправку на то, что Иридиум это старая система. Современные технологии могут улучшить эти показатели.
То есть как это будет на практике работать нужно будет ещё посмотреть. Но в теории мне кажется вполне реальным установить соединение на какой то сверх низкой скорости. Понятно, что если нужны мегабиты, то бери тарелку, но если скорости будет хватать хотя бы на текстовую переписку в мессенжере то это уже будет круто. Даже если для этого придётся купить отдельный модем по типу Иридиум GO
Выборка то может и достаточная. Однако это работает только если выборка репрезентативная. То есть например если из всех людей взять случайные 20к то это одно дело. А если если проводить опрос "пользуетесь ли вы интернетом" на сайте яндекса, то даже 100к опрошенных будут не очень показательными.
В данном случае мы очевидно видим довольно много категорий людей которые не попали в выборку. Вот что то мне подсказывает, что люди часто использующие VPN для обхода блокировок не горят желанием добровольно ставить трекер отслеживающий посещаемые сайты.
С чего это расходиться? Утечка есть утечка.
Лень искать фото, но таких "лайфхакеров" с ведёрками там было не оди и не два. В некоторых местах из них даже очереди скапливались. И обычным посетителям приходилось ждать пока очередная быдлосемейка наполнит все свои тазики и ведёрки.
Так что ИМХО. Основная проблема статьи в позиционировании. Если бы вместо тезиса "ищем халяву" было бы "интересно, а какой максимальной плотности данных получится добиться, прежде чем алгоритмы сжатия начнут портить информацию". Вроде мелочь, но другая подача и статья бы совсем по другому бы воспринималась.
Наш учитель в институте любил фразу "точное решение ни кому не нужно, людям нужно решение с достаточной точностью".
Это стандартные типы данных. Все знают, что работа с вещественными числами в компьютере сопряжена с потерей точности. Но в большинстве случаев эти типы дают достаточно правильный результат, чтобы на такие вещи закрыть глаза
К слову в целочисленные типы данных тоже можно далеко не любое число записать.
Ну если так рассуждать, то давай создавать отдельную платёжную систему под каждый магазин. ПятёрочкаКард для оплаты покупок в Пятёрочке, МагнитКард для оплаты покупок в Магните. Причём разные платёжные системы будут обслуживаться разными банками. Конкуренция во все щели.
А в чём обман? Банк установил курс обмена. Мне этот курс показался выгодным и я совершил сделки по этому курсу.
То есть предположим ты решил купить квартиру. Смотришь есть отличное предложение, всего за 5 лямов. Совершаешь сделку, уже начинаешь завозить вещи в новую квартиру, а тут приходит продавец и говорит "ты незаконно обогатился. Такая квартира стоит минимум десятку.". Отдавай мне ещё 5 лямов.
Джеттер «NTP по сети ~±30 mSec»А можно с этого момента по подробнее. Я понимаю когда мы конектимся к серверу в интернете. Сервер может быть перегружен. Находится в другом конце мира. Пакеты могут ходить окольными путями. И т. д.
Но если я нахожусь с NTP сервером в одной сети и пинги там менее 1мс, то откуда берётся 30мс?
Хранить данные в текстовом файле... Это конечно сильно. Ну да ладно. Не это меня больше всего зацепило.
В первую очередь в глаза бросился бардак с самими сертификатами. Три разных формата ссылок в сертификатах (и не факт, что это полный набор, там где три там и четыре и пять, просто возможно они ещё не попадались). Не ужели утвердить единый формат QR кодов это так сложно? Вот по одному только этому факту можно понять какой бардак творится среди разработчиков сервиса. Выглядит так, как будто бы там несколько комманд разработчиков, которые между собой ни как не взаимодействуют. Из за чего каждый делает свой костылесипед.
Как человек имеющий дело со сложными релейными схемами скажу так. Всё зависит от сложности алгоритма. Если алгоритм управления это что-то простое. Типа "если одновременно выполняется эти условия и не чыполняются эти" и вся схема управления это пара реле, то да, реле проще и надёжнее.
Но вот как только схема управления хоть чуть чуть усложняется, то лучше МК. Релейные схемы позволяют реализовывать очень сложные штуки. Но в то же время их сложно отлаживать и главное у тебя нет права на ошибку. Если ошибку в ПО можно исправить просто перепрошивкой, то ошибку в релейной схеме малой кровью обычно не решить.
Так как раз используют. Если растворить корпус подобной микросхемы то внутри ты увидишь, что если там внутри несколько частей разделённых диэлектриком. И связь через между частями микросхемы осуществляется при помощи света, индуктивности или ёмкости (в зависимости от технологии). Так что вполне себе физическое разделение.
А что сложного в получении сертификата?
Большинство выходов МК могут быть настроены для работы в режиме пуш-пул. Никакой дополнительный подтягикующий резистор им не нужен. Единственный резистор который нужен это токоограничивающий, чтобы ток заряда/разряда затвора не превышал рекомендуемый ток для порта МК.
По поводу драйвера. Для работы с маленькими транзисторами драйвер не нужен. Драйвер нужен только для могучих транзисторов с большой ёмкостью и напряжением затвора. Однако мощный полевой транзистор МК в одиночку тоже не раскачает. Так что...
Тут вот какой нюанс. Аппаратные ключи специально проектируются таким образом, чтобы их невозможно было скопировать. То есть предполагается, что ключом может воспользоваться только тот, у кого есть к нему физический доступ.
В случае использования USB over IP ключом может воспользоваться кто угодно, кто сможет подключиться. То есть "физическое обладание ключом" заменяется на "задача контроля доступа". И тут весь вопрос в том, как это будет реализовано. Можно конечно удариться в аниме и соединить сервер с физическим ключом и клиент отдельной витой парой по типу точка-точка с авторизацией по физическому ключу... В теории так сделать можно, и это будет супер надёжно и безопасно, но мы же понимаем, что ни кто так делать не будет. А как только мы упрощаем способ подключения, то мы автоматом понижаем безопасность решения. То есть грубо говоря если у нас авторизация просто по паролю, а доступ есть не только из локальной сети, а через интернет, то это конечно удобно для пользователей, но считай, что никакого ЭЦП у тебя нет, а есть только пароль. Так как любой кто знает пароль может воспользоваться твоей ЭЦП. Если проводить аналогию, это всё равно, что поставить дорогую железную дверь, но ключ хранить под ковриком.
И обрати внимание. Я не говорю, что это априори плохо. Как ни странно формальное снижение безопасности по факту может даже увеличивать безопасность. Приведу что имеется в виду. Предположим у нас есть дверь на склад. Огромная сейфовая дверь, способная выдержать прямое попадание из РПГ. С электронным замком с биометрией и одноразовыми паролями подписанными лично ЭЦП директора. Круто? Круто! Но через неделю в двери будет лежать деревянный брусочек чтобы дверь не закрывалась. И внезапно оказывается, что китайская картонная дверь с авторизацией по обычным NFC меткам безопасней, так как люди не будут лениться её закрывать.
Так, что я не говорю, что USB over IP это однозначно плохо. Просто его использование снижает безопасность и поэтому теперь уже ты должен придумать как организовать контроль доступа так, чтобы компенсировать это снижение безопасности.
В телевизоре черезстрочная развёртка. Частота кадров 50i обозначает, что вещание идёт со скоростью 50 полукадров в секунду. Один полукадр с чётными линиями, второй полукадр с нечётными. То есть если брать отдельную строку, то она обновлялась через кадр. То есть 50/2 = 25.
В теории конечно же можно хранить где то буфер кадра и обновлять всегда экран целиком. Но первые телевизоры были аналоговыми устройствами. Никаких буферов кадра в них и в помине не было. Что приходило из эфира то напрямую и показывали. А мерцание скрашивалось из за того, что у люминофора есть послесвечение + при плохой фокусировке одна строка частично подсвечивала соседние.