А можно с этого момента по подробнее. Я понимаю когда мы конектимся к серверу в интернете. Сервер может быть перегружен. Находится в другом конце мира. Пакеты могут ходить окольными путями. И т. д.
Но если я нахожусь с NTP сервером в одной сети и пинги там менее 1мс, то откуда берётся 30мс?
Хранить данные в текстовом файле... Это конечно сильно. Ну да ладно. Не это меня больше всего зацепило.
В первую очередь в глаза бросился бардак с самими сертификатами. Три разных формата ссылок в сертификатах (и не факт, что это полный набор, там где три там и четыре и пять, просто возможно они ещё не попадались). Не ужели утвердить единый формат QR кодов это так сложно? Вот по одному только этому факту можно понять какой бардак творится среди разработчиков сервиса. Выглядит так, как будто бы там несколько комманд разработчиков, которые между собой ни как не взаимодействуют. Из за чего каждый делает свой костылесипед.
Как человек имеющий дело со сложными релейными схемами скажу так. Всё зависит от сложности алгоритма. Если алгоритм управления это что-то простое. Типа "если одновременно выполняется эти условия и не чыполняются эти" и вся схема управления это пара реле, то да, реле проще и надёжнее.
Но вот как только схема управления хоть чуть чуть усложняется, то лучше МК. Релейные схемы позволяют реализовывать очень сложные штуки. Но в то же время их сложно отлаживать и главное у тебя нет права на ошибку. Если ошибку в ПО можно исправить просто перепрошивкой, то ошибку в релейной схеме малой кровью обычно не решить.
Так как раз используют. Если растворить корпус подобной микросхемы то внутри ты увидишь, что если там внутри несколько частей разделённых диэлектриком. И связь через между частями микросхемы осуществляется при помощи света, индуктивности или ёмкости (в зависимости от технологии). Так что вполне себе физическое разделение.
Большинство выходов МК могут быть настроены для работы в режиме пуш-пул. Никакой дополнительный подтягикующий резистор им не нужен. Единственный резистор который нужен это токоограничивающий, чтобы ток заряда/разряда затвора не превышал рекомендуемый ток для порта МК.
По поводу драйвера. Для работы с маленькими транзисторами драйвер не нужен. Драйвер нужен только для могучих транзисторов с большой ёмкостью и напряжением затвора. Однако мощный полевой транзистор МК в одиночку тоже не раскачает. Так что...
Тут вот какой нюанс. Аппаратные ключи специально проектируются таким образом, чтобы их невозможно было скопировать. То есть предполагается, что ключом может воспользоваться только тот, у кого есть к нему физический доступ.
В случае использования USB over IP ключом может воспользоваться кто угодно, кто сможет подключиться. То есть "физическое обладание ключом" заменяется на "задача контроля доступа". И тут весь вопрос в том, как это будет реализовано. Можно конечно удариться в аниме и соединить сервер с физическим ключом и клиент отдельной витой парой по типу точка-точка с авторизацией по физическому ключу... В теории так сделать можно, и это будет супер надёжно и безопасно, но мы же понимаем, что ни кто так делать не будет. А как только мы упрощаем способ подключения, то мы автоматом понижаем безопасность решения. То есть грубо говоря если у нас авторизация просто по паролю, а доступ есть не только из локальной сети, а через интернет, то это конечно удобно для пользователей, но считай, что никакого ЭЦП у тебя нет, а есть только пароль. Так как любой кто знает пароль может воспользоваться твоей ЭЦП. Если проводить аналогию, это всё равно, что поставить дорогую железную дверь, но ключ хранить под ковриком.
И обрати внимание. Я не говорю, что это априори плохо. Как ни странно формальное снижение безопасности по факту может даже увеличивать безопасность. Приведу что имеется в виду. Предположим у нас есть дверь на склад. Огромная сейфовая дверь, способная выдержать прямое попадание из РПГ. С электронным замком с биометрией и одноразовыми паролями подписанными лично ЭЦП директора. Круто? Круто! Но через неделю в двери будет лежать деревянный брусочек чтобы дверь не закрывалась. И внезапно оказывается, что китайская картонная дверь с авторизацией по обычным NFC меткам безопасней, так как люди не будут лениться её закрывать.
Так, что я не говорю, что USB over IP это однозначно плохо. Просто его использование снижает безопасность и поэтому теперь уже ты должен придумать как организовать контроль доступа так, чтобы компенсировать это снижение безопасности.
В телевизоре черезстрочная развёртка. Частота кадров 50i обозначает, что вещание идёт со скоростью 50 полукадров в секунду. Один полукадр с чётными линиями, второй полукадр с нечётными. То есть если брать отдельную строку, то она обновлялась через кадр. То есть 50/2 = 25.
В теории конечно же можно хранить где то буфер кадра и обновлять всегда экран целиком. Но первые телевизоры были аналоговыми устройствами. Никаких буферов кадра в них и в помине не было. Что приходило из эфира то напрямую и показывали. А мерцание скрашивалось из за того, что у люминофора есть послесвечение + при плохой фокусировке одна строка частично подсвечивала соседние.
Это вопрос к владельцу сайта. Какой уровень подтверждения он хочет.Задача самого простого сертификата подтверждать только то, что заходя на gosuslugi.ru ты получаешь данные именно от gosuslugi.ru, а не от какого то другого.
Вопрос популярности. Я как то в качестве первоапрельской шутки создал фейковый сайт. Несмотря на то, что далеко не все оценили шутку и было много бугурта в сообществе. Домен всё ещё живёт и сертификат регулярно обновляется.
Я думаю чтобы центр сертификации почесался бы блокировкой должна накопиться какая то критическая масса жалоб. Для сайтов однодневок она может просто не успеть набраться. А за это время будет обмануто много людей.
То есть чтобы реализовать такую подмену нужно получить доступ к пользовательской системе и прописать сертификат фейкового центра сертификации в качестве корневого и доверенного. Встаёт вопрос, а почему бы тогда за одно ещё не поставить парукейлогеров и не настроить вебку вещать напрямую в оранжевый ютуб. Раз у нас уже есть доступ, то что мелочиться.
Думаю дело не в размерах файла в байтах. Размер больно странный. Скорее всего проблема не в количестве байт, а в количестве каких то структур в файле. Скажем программист подумал и решил «в файле может быть не более 32767 записей типа Х. Каждая запись занимает несколько байт + есть записи других типов, вот в сумме и появляется ограничение в 8 мегабайт
Если в схеме стабилизатора нет ни одного конденсатора (керамика в гомеопатических дозах не в счёт), а напряжение в сети равно нулю (на всякий случай напомню, в сети напряжение переменное и в некоторые моменты времени мгновенное значение равно нулю). То ты хоть на какой схемотехнике строй драйвер, без электричества он не сможет заставить светодиод светиться.
За то работает
^ на скрине тест сигнала PPS. Цифра показывает чему было равно системное время в тот момент когда был получен сигнал PPS. Для бытовой точности как по мне весьма недурственный результат. Гораздо лучше чем я бы смог получить с какого то сервера из интернета.
Имхо. Излишний функционал для дома. Для этого тебе нужно будет в память устройства занести карту часовых поясов. При этом это должна быть именно карта, а не просто если долгота больше 50 и меньше 60 то часовой пояс такой то, это так не работает.
Потом получившуюся карту регулярно обновлять. Потому что не только в России правительство переодически херней страдает часовые пояса перекраивая.
А теперь вопрос, зачем нужен этот функционал для часов которые в течении всего срока службы скорее всего даже не покинут пределы квартиры? Не проще ли один раз при запуске ввести поправку и навсегда об этом забыть?
Ну или вообще без всякого GPS — DCF77 какой-нибудь ловить, если территориальное расположение позволяет.
Имхо. GPS универсальнее чем DCF77. Возможно если бы мы жили в германии, то да, DCF77 круто. Но на большей части территории России DCF77 ловится чуть менее чем ни как. А там где ловится очень много чего зависит от состояния атмосферы (будет проходить сигнал или нет), расположения приемника, наличия источников помех поблизости, погоды на марсе и т. д. И как бы да, вроде бы одной успешной синхронизации скажем в неделю достаточно чтобы часы показывали точное время (даже на дерьмовом кварце часы без синхронизации за неделю не так сильно уйдут чтобы это создало бы проблему). С дрогой стороны есть GPS который стабильно раз в секунду дает точное значение времени плюс PPS сигнал.
Хотя я бы никогда и ни кому не посоветовал бы использовать com.sun.net.httpserver, ни для каких целей вообще, есть вещи которые отмирают, это мертвый код, который абсолютно бесполезен, даже с точки зрения обучения.
Было бы интересно узнать обоснование, почему com.sun.net.httpserver не стоит использовать вообще никогда. Это я сейчас без подколов спрашиваю. У меня сейчас есть задача которая требует добавить в программу простенький HTTP сервер (собственно именно гугля по запросу «Java Http server» я этот пост и нашел). И решение использовать com.sun.net.httpserver мне кажется логичным
Джеттер «NTP по сети ~±30 mSec»А можно с этого момента по подробнее. Я понимаю когда мы конектимся к серверу в интернете. Сервер может быть перегружен. Находится в другом конце мира. Пакеты могут ходить окольными путями. И т. д.
Но если я нахожусь с NTP сервером в одной сети и пинги там менее 1мс, то откуда берётся 30мс?
Хранить данные в текстовом файле... Это конечно сильно. Ну да ладно. Не это меня больше всего зацепило.
В первую очередь в глаза бросился бардак с самими сертификатами. Три разных формата ссылок в сертификатах (и не факт, что это полный набор, там где три там и четыре и пять, просто возможно они ещё не попадались). Не ужели утвердить единый формат QR кодов это так сложно? Вот по одному только этому факту можно понять какой бардак творится среди разработчиков сервиса. Выглядит так, как будто бы там несколько комманд разработчиков, которые между собой ни как не взаимодействуют. Из за чего каждый делает свой костылесипед.
Как человек имеющий дело со сложными релейными схемами скажу так. Всё зависит от сложности алгоритма. Если алгоритм управления это что-то простое. Типа "если одновременно выполняется эти условия и не чыполняются эти" и вся схема управления это пара реле, то да, реле проще и надёжнее.
Но вот как только схема управления хоть чуть чуть усложняется, то лучше МК. Релейные схемы позволяют реализовывать очень сложные штуки. Но в то же время их сложно отлаживать и главное у тебя нет права на ошибку. Если ошибку в ПО можно исправить просто перепрошивкой, то ошибку в релейной схеме малой кровью обычно не решить.
Так как раз используют. Если растворить корпус подобной микросхемы то внутри ты увидишь, что если там внутри несколько частей разделённых диэлектриком. И связь через между частями микросхемы осуществляется при помощи света, индуктивности или ёмкости (в зависимости от технологии). Так что вполне себе физическое разделение.
А что сложного в получении сертификата?
Большинство выходов МК могут быть настроены для работы в режиме пуш-пул. Никакой дополнительный подтягикующий резистор им не нужен. Единственный резистор который нужен это токоограничивающий, чтобы ток заряда/разряда затвора не превышал рекомендуемый ток для порта МК.
По поводу драйвера. Для работы с маленькими транзисторами драйвер не нужен. Драйвер нужен только для могучих транзисторов с большой ёмкостью и напряжением затвора. Однако мощный полевой транзистор МК в одиночку тоже не раскачает. Так что...
Тут вот какой нюанс. Аппаратные ключи специально проектируются таким образом, чтобы их невозможно было скопировать. То есть предполагается, что ключом может воспользоваться только тот, у кого есть к нему физический доступ.
В случае использования USB over IP ключом может воспользоваться кто угодно, кто сможет подключиться. То есть "физическое обладание ключом" заменяется на "задача контроля доступа". И тут весь вопрос в том, как это будет реализовано. Можно конечно удариться в аниме и соединить сервер с физическим ключом и клиент отдельной витой парой по типу точка-точка с авторизацией по физическому ключу... В теории так сделать можно, и это будет супер надёжно и безопасно, но мы же понимаем, что ни кто так делать не будет. А как только мы упрощаем способ подключения, то мы автоматом понижаем безопасность решения. То есть грубо говоря если у нас авторизация просто по паролю, а доступ есть не только из локальной сети, а через интернет, то это конечно удобно для пользователей, но считай, что никакого ЭЦП у тебя нет, а есть только пароль. Так как любой кто знает пароль может воспользоваться твоей ЭЦП. Если проводить аналогию, это всё равно, что поставить дорогую железную дверь, но ключ хранить под ковриком.
И обрати внимание. Я не говорю, что это априори плохо. Как ни странно формальное снижение безопасности по факту может даже увеличивать безопасность. Приведу что имеется в виду. Предположим у нас есть дверь на склад. Огромная сейфовая дверь, способная выдержать прямое попадание из РПГ. С электронным замком с биометрией и одноразовыми паролями подписанными лично ЭЦП директора. Круто? Круто! Но через неделю в двери будет лежать деревянный брусочек чтобы дверь не закрывалась. И внезапно оказывается, что китайская картонная дверь с авторизацией по обычным NFC меткам безопасней, так как люди не будут лениться её закрывать.
Так, что я не говорю, что USB over IP это однозначно плохо. Просто его использование снижает безопасность и поэтому теперь уже ты должен придумать как организовать контроль доступа так, чтобы компенсировать это снижение безопасности.
В телевизоре черезстрочная развёртка. Частота кадров 50i обозначает, что вещание идёт со скоростью 50 полукадров в секунду. Один полукадр с чётными линиями, второй полукадр с нечётными. То есть если брать отдельную строку, то она обновлялась через кадр. То есть 50/2 = 25.
В теории конечно же можно хранить где то буфер кадра и обновлять всегда экран целиком. Но первые телевизоры были аналоговыми устройствами. Никаких буферов кадра в них и в помине не было. Что приходило из эфира то напрямую и показывали. А мерцание скрашивалось из за того, что у люминофора есть послесвечение + при плохой фокусировке одна строка частично подсвечивала соседние.
Это вопрос к владельцу сайта. Какой уровень подтверждения он хочет.Задача самого простого сертификата подтверждать только то, что заходя на gosuslugi.ru ты получаешь данные именно от gosuslugi.ru, а не от какого то другого.
Вопрос популярности. Я как то в качестве первоапрельской шутки создал фейковый сайт. Несмотря на то, что далеко не все оценили шутку и было много бугурта в сообществе. Домен всё ещё живёт и сертификат регулярно обновляется.
Я думаю чтобы центр сертификации почесался бы блокировкой должна накопиться какая то критическая масса жалоб. Для сайтов однодневок она может просто не успеть набраться. А за это время будет обмануто много людей.
То есть чтобы реализовать такую подмену нужно получить доступ к пользовательской системе и прописать сертификат фейкового центра сертификации в качестве корневого и доверенного. Встаёт вопрос, а почему бы тогда за одно ещё не поставить парукейлогеров и не настроить вебку вещать напрямую в оранжевый ютуб. Раз у нас уже есть доступ, то что мелочиться.
Какие подтверждения нужны для получения сертификата удостоверяющего исключительно домен, кроме как подтверждение владения доменом?
Если в схеме стабилизатора нет ни одного конденсатора (керамика в гомеопатических дозах не в счёт), а напряжение в сети равно нулю (на всякий случай напомню, в сети напряжение переменное и в некоторые моменты времени мгновенное значение равно нулю). То ты хоть на какой схемотехнике строй драйвер, без электричества он не сможет заставить светодиод светиться.
^ на скрине тест сигнала PPS. Цифра показывает чему было равно системное время в тот момент когда был получен сигнал PPS. Для бытовой точности как по мне весьма недурственный результат. Гораздо лучше чем я бы смог получить с какого то сервера из интернета.
Потом получившуюся карту регулярно обновлять. Потому что не только в России правительство переодически херней страдает часовые пояса перекраивая.
А теперь вопрос, зачем нужен этот функционал для часов которые в течении всего срока службы скорее всего даже не покинут пределы квартиры? Не проще ли один раз при запуске ввести поправку и навсегда об этом забыть?
Имхо. GPS универсальнее чем DCF77. Возможно если бы мы жили в германии, то да, DCF77 круто. Но на большей части территории России DCF77 ловится чуть менее чем ни как. А там где ловится очень много чего зависит от состояния атмосферы (будет проходить сигнал или нет), расположения приемника, наличия источников помех поблизости, погоды на марсе и т. д. И как бы да, вроде бы одной успешной синхронизации скажем в неделю достаточно чтобы часы показывали точное время (даже на дерьмовом кварце часы без синхронизации за неделю не так сильно уйдут чтобы это создало бы проблему). С дрогой стороны есть GPS который стабильно раз в секунду дает точное значение времени плюс PPS сигнал.
Было бы интересно узнать обоснование, почему com.sun.net.httpserver не стоит использовать вообще никогда. Это я сейчас без подколов спрашиваю. У меня сейчас есть задача которая требует добавить в программу простенький HTTP сервер (собственно именно гугля по запросу «Java Http server» я этот пост и нашел). И решение использовать com.sun.net.httpserver мне кажется логичным