Теоретически вы можете сделать свой, по своим правилам.
Централизованное регулирование сделает это невозможным даже теоретически - вы подчинитесь какому-нибудь Всемирному Комитету, который и будет управлять.
Тут есть важный вопрос: а кто же создает эти ограничения? (я сейчас не про РКН)
Когда-то вебмастер сидел, и вручную подбирал степень сжатия jpeg, чтобы картинка не сильно "мылилась", но с 200 кб сжалась до 50 - и это ускоряло загрузку в 4 раза.
Сейчас "а давайте влепим компонент, создающий вот такой интересный эффект анимации?" + 3 мегабайта. В локальной сети разработчика эффект замедления не выражен, но где-то "на природе" по нестабильному мобильному интернету получаем проблему, вместо секунды загрузки - несколько десятков секунд, в т.ч. с переключениями между БС связи, что еще ухудшает ситуацию.
Это к тому, что какой бы быстрый протокол не придумали инженеры - вебмастера всегда найдут, чем его забить в ноль.
Кстати, я вот только сегодня выяснил, что оказывается теперь для работы с тем же Рутокеном ЭЦП и госпорталами (по крайней мере налоговой) никакой Криптопро больше не нужен.
Мало того, что оно теперь работает "из браузера", мало того, что поддерживается Линукс, так ещё и архитектура arm поддерживается.
Не нужна больше виртуалка с Виндой для сдачи отчётности, и нет больше странных глюков с не такими пакетами и сервиспаками...
Подозреваю, что создатели чипа просчитали вероятности математически, а не полагаясь на "здравый смысл".
Поясню: допустим, мы берем за основу тики процессора, параметр А у нас - word от счетчика, параметр В - word от счетчика со сдвигом. Разумеется, они связаны, общее число вариантов конечно, последовательности для каждого известны и т.д.
По здравому смыслу так и будет: приходит Мариванна в 9, до 13 генерирует ключ, скорее всего в 10:30 (как показали наблюдения за ней)
Но сам счетчик - unsigned long, с периодом обращения, ну скажем, около часа, малейшее отклонение интервала от 9:00 и 10:30 дает расхождения в пределах 65536 вариантов параметра А, * на еще какое-то, меньшее, количество вариантов параметра В. Увеличим частоту - увеличим варианты В.
Опять же, это число конечно, и если последовательности нам известны - можем предугадать. Но - вероятность этого = 1/ (65536 * тыщи), к тому же от последовательности у нас небольшой кусочек, генерируется она вообще однократно (ну ладно, раз в квартал) - в общем, всё плохо с подбором.
А вот движение мыши - в теории непредсказуемо, но оно тоже ограничено параметрами экрана, т.е. количество вариантов конечно, и скорее всего из всего их массива будет только "влево-вправо по дуге несколько раз".
Остается только рассчитать вероятности предсказания того и другого - подозреваю, что они будут примерно одинаковы, если вообще не в пользу "мыши".
Допустим, вы обновили ядро ОС. Во Фре это сделать было чуть-чуть сложнее, его еще пересобрать надо, а в Линуксе сейчас вот вообще просто в порядке апдейта, особенно если настроить автообновление.
Но в новой версии ядра что-то поломали - такое было раньше, и бывает сейчас. И теперь при загрузке сетевая карта не определилась, или определилась не так, и драйвер не заработал. Вот и "не должен".
Во Фре драйвера вкомпилены в ядро (раньше так было во всяком случае), при обновлении дерева исходников ядра старый драйвер мог некорректно заработать с новым ядром (такое встречалось, правда, там был драйвер несовсем стандартной железки, но теоретически мог быть и драйвер сетевой).
Из относительно свежих примеров - отказы в работе c WiFi-чипами в Убунте, пропадание поддержки звука через HDMI, пропадание сетевой карты в Армбиане.
И вот это всё вы увидите только после перезагрузки на новом ядре. после штатного в общем-то процесса обновления.
Видимо, где как. В нашей районной могут продать на месте, или можно купить буквально за углом в вендинговом автомате, или заказать на маркетплейсе и придти с ним...
Насколько помню - там было несколько входящих значений, которые влияли на эту последовательность. Если бы решал задачу сейчас - можно было бы взять за основу счетчик (что там будет внутри МК - микросекунды, миллисекунды, абстрактные такты), и плясать от них.
Момент начала генерации кода от момента подачи питания - штука довольно случайная, особенно если успело пройти под миллион тактов. Конечно, если задаться целью, зная код, имея железо, и время для сбора статистики...
Почему те взяли за основы мышку? Ну, так решили. В Линуксе есть свой /dev/urandom, в Винде тоже вроде что-то подобное...
Как обычно, на самом деле всё не совсем так, хотя и похоже )
Есть проблема физического износа: те же вентиляторы, диски и тому подобное. Да, они постепенно выходят из строя, и при этом как правило именно включение-выключение их и добивает. Хотите добить быстро - выключайте почаще, это не даст им незаметно состариться, умрут молодыми.
Но есть другое решение: регламент плановой замены - раз в N месяцев старые диски выкинули, новые диски поставили, несмотря ни на SMART, ни на чуйку, ни на что. По регламенту.
Есть проблема неактуальности версий: уже вышла Proga 12.6.3 , а у нас до сих пор 8.0.0! Срочное обновление!!
Нет, срочно по рукам лопатой. Потому что при этом есть очень хорошая вероятность сломать совместимость с чем-то, что казалось бы ну вот вообще никак не связано. Готовим новое железо (или виртуалку на старом), устанавливаем новую версию, ТЕСТИРУЕМ - а потом миграция системы на новую версию.
Да, и даже ядро ОС. Тем более ядро ОС.
А как же безопасность?! Ведь в старой версии, если в полнолуние криворукий дятел три раза щелкнет клювом - в систему может пролезть сетевой червь?!
Ну если криворукий дятел знает, что в систему может пролезть червь - ну поставь ты сначала вокруг защиту, не будь криворуким дятлом! И даже если не знаешь - представь, что может - и поставь. Потом - см.выше - новая инсталляция, тестирование, миграция.
Да, и про плановую замену не забываем, чтобы у кулеров не вырастала борода из пыли и диски не летали.
И остается вопрос с кривыми программами, которые жрут память, гадят под себя на диск какашками временных файлов, и оставляют зомби по углам. Штош, видимо на тех серверах, у которых аптайм годами, такие просто не водятся. Либо отцы-программисты их пролечили, либо админ-владелец решил выбрать другое решение задачи.
Как-то так.
А не вот это вот "в любой непонятной ситуации - перезагружайся!"
Ну, после угрозы применения пыток коллега, который давал мне доступ, сознался - он сделал remount корневой ФС, потому что иначе не получалось создать мне учётку на сервере.
И так, проблема сервера была не в порядке юнитов, а исключительно в корневой ФС.
Неет, проблема была в кривых руках. Которые, в том числе, снесли fstab, и свалили всё на "устаревание"...
А я предположу, что в потрошка FreeBSD полез молодой, бывший виндовый админ, ужаснулся, что сервер не перезагружали больше недели и "не обновляли систему", немедленно всё обновил и отправил в ребут.
Была у меня книжечка, там был алгоритм генерации псевдослучайной последовательности, как писали - хороший. А вот сам алгоритм крайне простой, его запросто на МК реализовать, даже примитивном.
Либо Rutoken Lite или S, если физлицо (копируемые - там только пароль хранить), либо Rutoken ЭЦП - некопируемые сертификаты генерируются на ключе, либо Jacarta (там вроде тоже и такой и такой варианты есть).
Остальное несертифицированное, и официально нельзя использовать.
Можно просто принести свой, купленный отдельно - сертифицированный, конечно.
Ради поддержания которого вводились заградительные пошлины, утильсборы, и сейчас купить нормальную машину стоит больших денег. А где же наши прекрасные Лады? С запчастями из хорошего металла, отличным ЛКП, с трубками и шлангами, которые не крошатся, эргономичные, удобные?
А он там, где не нужно заниматься повышением качества, нужно проталкивать новые пошлины, техрегламенты и утильсборы, то есть конкурировать административно.
И вот так оно везде. Сейчас вот в IT импортозамещение приспичило - где оно было несколько лет назад, когда везде сидели "золотые и платиновые партнёры" известных вендоров, и через тот же админресурс проталкивали именно их "решения"?
Это всё про деньги. Все остальное - лапша на уши, красивые словесные конструкции
Они искали оптимальный вариант. В любом случае это мне выгоднее чем искать единственный офлайн магазин в ближайшем городе, где продается то что мне нужно.
Если структура перестает помещаться в контексте восприятия (это ещё до ИИ придумано было) - нужно менять структуру или подход к ней.
Перепутать единственный итератор не с чем. Перепутать два итератора сложно. Три - тоже сложновато. Больше 7, да ещё с глобальными переменными - флагами - запросто, пора пересматривать алгоритм.
Ну это из серии "если покрасить панду в черный цвет - вы ее не узнаете" - потому что вы представляете себе панду как медведя в очках, а не вот это вот.
У ИИ могут быть другие ассоциации, если знать какие - можно обмануть.
Ну я же говорил, как только государство начинает что-то регулировать - "всё должно быть пострижено, покошено, и выкрашено зелёной краской!". А паспорт у вас с собой?!
От просто "красивого домена" до самого факта что-то там создать и зарегистрировать.
Теоретически вы можете сделать свой, по своим правилам.
Централизованное регулирование сделает это невозможным даже теоретически - вы подчинитесь какому-нибудь Всемирному Комитету, который и будет управлять.
Тут есть важный вопрос: а кто же создает эти ограничения? (я сейчас не про РКН)
Когда-то вебмастер сидел, и вручную подбирал степень сжатия jpeg, чтобы картинка не сильно "мылилась", но с 200 кб сжалась до 50 - и это ускоряло загрузку в 4 раза.
Сейчас "а давайте влепим компонент, создающий вот такой интересный эффект анимации?" + 3 мегабайта. В локальной сети разработчика эффект замедления не выражен, но где-то "на природе" по нестабильному мобильному интернету получаем проблему, вместо секунды загрузки - несколько десятков секунд, в т.ч. с переключениями между БС связи, что еще ухудшает ситуацию.
Это к тому, что какой бы быстрый протокол не придумали инженеры - вебмастера всегда найдут, чем его забить в ноль.
Кстати, я вот только сегодня выяснил, что оказывается теперь для работы с тем же Рутокеном ЭЦП и госпорталами (по крайней мере налоговой) никакой Криптопро больше не нужен.
Мало того, что оно теперь работает "из браузера", мало того, что поддерживается Линукс, так ещё и архитектура arm поддерживается.
Не нужна больше виртуалка с Виндой для сдачи отчётности, и нет больше странных глюков с не такими пакетами и сервиспаками...
Хоть что-то хорошее.
Подозреваю, что создатели чипа просчитали вероятности математически, а не полагаясь на "здравый смысл".
Поясню: допустим, мы берем за основу тики процессора, параметр А у нас - word от счетчика, параметр В - word от счетчика со сдвигом.
Разумеется, они связаны, общее число вариантов конечно, последовательности для каждого известны и т.д.
По здравому смыслу так и будет: приходит Мариванна в 9, до 13 генерирует ключ, скорее всего в 10:30 (как показали наблюдения за ней)
Но сам счетчик - unsigned long, с периодом обращения, ну скажем, около часа, малейшее отклонение интервала от 9:00 и 10:30 дает расхождения в пределах 65536 вариантов параметра А, * на еще какое-то, меньшее, количество вариантов параметра В. Увеличим частоту - увеличим варианты В.
Опять же, это число конечно, и если последовательности нам известны - можем предугадать.
Но - вероятность этого = 1/ (65536 * тыщи), к тому же от последовательности у нас небольшой кусочек, генерируется она вообще однократно (ну ладно, раз в квартал) - в общем, всё плохо с подбором.
А вот движение мыши - в теории непредсказуемо, но оно тоже ограничено параметрами экрана, т.е. количество вариантов конечно, и скорее всего из всего их массива будет только "влево-вправо по дуге несколько раз".
Остается только рассчитать вероятности предсказания того и другого - подозреваю, что они будут примерно одинаковы, если вообще не в пользу "мыши".
Но это только предположение
Допустим, вы обновили ядро ОС.
Во Фре это сделать было чуть-чуть сложнее, его еще пересобрать надо, а в Линуксе сейчас вот вообще просто в порядке апдейта, особенно если настроить автообновление.
Но в новой версии ядра что-то поломали - такое было раньше, и бывает сейчас. И теперь при загрузке сетевая карта не определилась, или определилась не так, и драйвер не заработал.
Вот и "не должен".
Во Фре драйвера вкомпилены в ядро (раньше так было во всяком случае), при обновлении дерева исходников ядра старый драйвер мог некорректно заработать с новым ядром (такое встречалось, правда, там был драйвер несовсем стандартной железки, но теоретически мог быть и драйвер сетевой).
Из относительно свежих примеров - отказы в работе c WiFi-чипами в Убунте, пропадание поддержки звука через HDMI, пропадание сетевой карты в Армбиане.
И вот это всё вы увидите только после перезагрузки на новом ядре. после штатного в общем-то процесса обновления.
Видимо, где как. В нашей районной могут продать на месте, или можно купить буквально за углом в вендинговом автомате, или заказать на маркетплейсе и придти с ним...
Вот именно! )
Однако, пароль вы вспомнили, я вижу...
Насколько помню - там было несколько входящих значений, которые влияли на эту последовательность.
Если бы решал задачу сейчас - можно было бы взять за основу счетчик (что там будет внутри МК - микросекунды, миллисекунды, абстрактные такты), и плясать от них.
Момент начала генерации кода от момента подачи питания - штука довольно случайная, особенно если успело пройти под миллион тактов.
Конечно, если задаться целью, зная код, имея железо, и время для сбора статистики...
Почему те взяли за основы мышку? Ну, так решили.
В Линуксе есть свой /dev/urandom, в Винде тоже вроде что-то подобное...
Как обычно, на самом деле всё не совсем так, хотя и похоже )
Есть проблема физического износа: те же вентиляторы, диски и тому подобное. Да, они постепенно выходят из строя, и при этом как правило именно включение-выключение их и добивает.
Хотите добить быстро - выключайте почаще, это не даст им незаметно состариться, умрут молодыми.
Но есть другое решение: регламент плановой замены - раз в N месяцев старые диски выкинули, новые диски поставили, несмотря ни на SMART, ни на чуйку, ни на что. По регламенту.
Есть проблема неактуальности версий: уже вышла Proga 12.6.3 , а у нас до сих пор 8.0.0!
Срочное обновление!!
Нет, срочно по рукам лопатой. Потому что при этом есть очень хорошая вероятность сломать совместимость с чем-то, что казалось бы ну вот вообще никак не связано.
Готовим новое железо (или виртуалку на старом), устанавливаем новую версию, ТЕСТИРУЕМ - а потом миграция системы на новую версию.
Да, и даже ядро ОС. Тем более ядро ОС.
А как же безопасность?! Ведь в старой версии, если в полнолуние криворукий дятел три раза щелкнет клювом - в систему может пролезть сетевой червь?!
Ну если криворукий дятел знает, что в систему может пролезть червь - ну поставь ты сначала вокруг защиту, не будь криворуким дятлом! И даже если не знаешь - представь, что может - и поставь.
Потом - см.выше - новая инсталляция, тестирование, миграция.
Да, и про плановую замену не забываем, чтобы у кулеров не вырастала борода из пыли и диски не летали.
И остается вопрос с кривыми программами, которые жрут память, гадят под себя на диск какашками временных файлов, и оставляют зомби по углам.
Штош, видимо на тех серверах, у которых аптайм годами, такие просто не водятся.
Либо отцы-программисты их пролечили, либо админ-владелец решил выбрать другое решение задачи.
Как-то так.
А не вот это вот "в любой непонятной ситуации - перезагружайся!"
Неет, проблема была в кривых руках. Которые, в том числе, снесли fstab, и свалили всё на "устаревание"...
А я предположу, что в потрошка FreeBSD полез молодой, бывший виндовый админ, ужаснулся, что сервер не перезагружали больше недели и "не обновляли систему", немедленно всё обновил и отправил в ребут.
И тут-то что-то пошло не так...
Была у меня книжечка, там был алгоритм генерации псевдослучайной последовательности, как писали - хороший.
А вот сам алгоритм крайне простой, его запросто на МК реализовать, даже примитивном.
не, это программа такое делает. Ключ выдает мгновенно.
Либо Rutoken Lite или S, если физлицо (копируемые - там только пароль хранить), либо Rutoken ЭЦП - некопируемые сертификаты генерируются на ключе, либо Jacarta (там вроде тоже и такой и такой варианты есть).
Остальное несертифицированное, и официально нельзя использовать.
Можно просто принести свой, купленный отдельно - сертифицированный, конечно.
У нас есть независимый суверенный АвтоВАЗ.
Ради поддержания которого вводились заградительные пошлины, утильсборы, и сейчас купить нормальную машину стоит больших денег. А где же наши прекрасные Лады? С запчастями из хорошего металла, отличным ЛКП, с трубками и шлангами, которые не крошатся, эргономичные, удобные?
А он там, где не нужно заниматься повышением качества, нужно проталкивать новые пошлины, техрегламенты и утильсборы, то есть конкурировать административно.
И вот так оно везде. Сейчас вот в IT импортозамещение приспичило - где оно было несколько лет назад, когда везде сидели "золотые и платиновые партнёры" известных вендоров, и через тот же админресурс проталкивали именно их "решения"?
Это всё про деньги. Все остальное - лапша на уши, красивые словесные конструкции
НДС.
Они искали оптимальный вариант. В любом случае это мне выгоднее чем искать единственный офлайн магазин в ближайшем городе, где продается то что мне нужно.
Если структура перестает помещаться в контексте восприятия (это ещё до ИИ придумано было) - нужно менять структуру или подход к ней.
Перепутать единственный итератор не с чем. Перепутать два итератора сложно. Три - тоже сложновато. Больше 7, да ещё с глобальными переменными - флагами - запросто, пора пересматривать алгоритм.
Ну это из серии "если покрасить панду в черный цвет - вы ее не узнаете" - потому что вы представляете себе панду как медведя в очках, а не вот это вот.
У ИИ могут быть другие ассоциации, если знать какие - можно обмануть.
Ну я же говорил, как только государство начинает что-то регулировать - "всё должно быть пострижено, покошено, и выкрашено зелёной краской!". А паспорт у вас с собой?!
От просто "красивого домена" до самого факта что-то там создать и зарегистрировать.