Большинство выходов МК могут быть настроены для работы в режиме пуш-пул. Никакой дополнительный подтягикующий резистор им не нужен. Единственный резистор который нужен это токоограничивающий, чтобы ток заряда/разряда затвора не превышал рекомендуемый ток для порта МК.
По поводу драйвера. Для работы с маленькими транзисторами драйвер не нужен. Драйвер нужен только для могучих транзисторов с большой ёмкостью и напряжением затвора. Однако мощный полевой транзистор МК в одиночку тоже не раскачает. Так что...
Тут вот какой нюанс. Аппаратные ключи специально проектируются таким образом, чтобы их невозможно было скопировать. То есть предполагается, что ключом может воспользоваться только тот, у кого есть к нему физический доступ.
В случае использования 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 мне кажется логичным
Побуду немного кэпом. Причин использования многопоточности вагон и маленькая тележка и использование использование многопоточности для ускорения вычислений это одна из множества областей применения.
Простой пример предположим у тебя всего одно ядро. Есть основной поток, во время работы которого возникло событие о котором надо отправить отчет на удаленный сервер. Если ты все делаешь в одном потоке то пока программа подключится к удаленному серверу (а пинг иногда может и в сотнях мс измеряться) пока выгрузит данные, пока еще как то там отреагирует на событие. Все это время основной поток простаивает. А если еще есть проблемы со интенет соединением, то он будет пытаться еще несколько попыток отаравки сделать. Между которыми еще таймаут выждет. И все это время работа программы парализована. Поэтому мы создаем отдельный поток и обработку события выносим в отдельный поток. Все. Программа может дальше заниматься своими делами, а обработчик события может неспешно пытаться отправить этот файл на удаленный сервер. И даже несмотря на то, что у тебя всего навсего одно ядро, то есть ни о каком истинно паралельном вычислении быть не может. Но так как обработчик события все равно большую часть времени ждет выполнения операций ввода вывода, то никаких проблем это не создает и программа работает лучше.
Всегда удивляешься, когда встречаешь в интернете ссылки на сертификаты своих коллег!
К сожалению, в нашей стране далеко не все Центры метрологии и стандартизации и метрологические институты обладают достаточным уровнем компетентности и профессионализма.
К вопросу об уровне профессионализма. Закину еще в копилку фейлов. Открываем ПМ-ку на СОЭКС Квантум (весь из себя поверенный и т. д.). Открываем страницу 10 раздел 4.14 и читаем:
Согласно этой ПМ-ке прибор нужно поместить в поле мощностью до 1 Зв/с (напоминаю, речь о приборе на СБМ-20-1) и дождаться накопления дозы в 1000 Зв (опять же напоминаю, что речь идет о приборе на датчике СБМ-20-1 и бытовом процессоре на бытовом микроконтроллере, никакими радиационно стойкими элементами в нем даже и не пахнет). И после такого испытания прибор должен не просто остаться в живых, но даже измерить накопленную дозу с требуемой точностью.
Как думаешь, кто то хотя бы раз этот пункт испытаний хотя бы раз пытался выполнить?
Длинные волны и на такой мощности не думаю, что кому то смогут создать проблем. Не говоря уже о том, что как то очень притянуто за уши выглядит, что для каких то вещей которым нужна сепер точность будут использовать DCF77 а не GPS который и ловится лучше и дает в разы большую точность.
Ну по поводу правильности времени я бы поспорил. Все зависит от того, какое время считать правильным. С бытовой точки зрения время то может быть и одинаковое, а вот с какой то более научной, может и на сколько то мс отличаться. Другое дело, что ловить сигнал DCF который еле еле пробивается в хорошую погоду ни кто для таких целей не будет. Есть же GPS и все могу нужно реально точное время синхронизируются через него. Да и мощность тут такая, что далеко он не уйдет.
А что сложного в получении сертификата?
Большинство выходов МК могут быть настроены для работы в режиме пуш-пул. Никакой дополнительный подтягикующий резистор им не нужен. Единственный резистор который нужен это токоограничивающий, чтобы ток заряда/разряда затвора не превышал рекомендуемый ток для порта МК.
По поводу драйвера. Для работы с маленькими транзисторами драйвер не нужен. Драйвер нужен только для могучих транзисторов с большой ёмкостью и напряжением затвора. Однако мощный полевой транзистор МК в одиночку тоже не раскачает. Так что...
Тут вот какой нюанс. Аппаратные ключи специально проектируются таким образом, чтобы их невозможно было скопировать. То есть предполагается, что ключом может воспользоваться только тот, у кого есть к нему физический доступ.
В случае использования 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 мне кажется логичным
Простой пример предположим у тебя всего одно ядро. Есть основной поток, во время работы которого возникло событие о котором надо отправить отчет на удаленный сервер. Если ты все делаешь в одном потоке то пока программа подключится к удаленному серверу (а пинг иногда может и в сотнях мс измеряться) пока выгрузит данные, пока еще как то там отреагирует на событие. Все это время основной поток простаивает. А если еще есть проблемы со интенет соединением, то он будет пытаться еще несколько попыток отаравки сделать. Между которыми еще таймаут выждет. И все это время работа программы парализована. Поэтому мы создаем отдельный поток и обработку события выносим в отдельный поток. Все. Программа может дальше заниматься своими делами, а обработчик события может неспешно пытаться отправить этот файл на удаленный сервер. И даже несмотря на то, что у тебя всего навсего одно ядро, то есть ни о каком истинно паралельном вычислении быть не может. Но так как обработчик события все равно большую часть времени ждет выполнения операций ввода вывода, то никаких проблем это не создает и программа работает лучше.
К вопросу об уровне профессионализма. Закину еще в копилку фейлов. Открываем ПМ-ку на СОЭКС Квантум (весь из себя поверенный и т. д.). Открываем страницу 10 раздел 4.14 и читаем:
Согласно этой ПМ-ке прибор нужно поместить в поле мощностью до 1 Зв/с (напоминаю, речь о приборе на СБМ-20-1) и дождаться накопления дозы в 1000 Зв (опять же напоминаю, что речь идет о приборе на датчике СБМ-20-1 и бытовом процессоре на бытовом микроконтроллере, никакими радиационно стойкими элементами в нем даже и не пахнет). И после такого испытания прибор должен не просто остаться в живых, но даже измерить накопленную дозу с требуемой точностью.
Как думаешь, кто то хотя бы раз этот пункт испытаний хотя бы раз пытался выполнить?