Ложь не является альтернативной точкой зрения.
В мире постправды у Трампа украли выборы, мы находимся на поской земле, нас чипируют с помощью 5g и так далее и тому подобное. И это теперь называют альтернативной точкой зрения.
Джойказино, это как раз как не нужно делать рекламу. При правильной постановке выхлоп был бы больше, но тут тоже сработало жлобство — вставим рекламу так, чтобы она раздражала.
Можно сказать, что чем больше будет стриминговых сервисов, эксклюзивов, копирайтных войн, тем болше торренты будут выигрывать.
С другой стороны, чем больше будет этого маразма, тем меньше будет прибыль и быстрее все это загнется. И тогда, наконец-то, появятся адекватные сервисы.
Я уже открыл документацию по контроллеру. Хотя по документации номер порта четный — это адрес, а нечетный — счетчик. А у вас нечетные порты — адрес. возможно четные — количество. Там возможно специально сделали, чтобы за одну команду можно было грузить как адрес так и количество. Или это баг, превратившийся в фичу. :)
Чисто технически команда OUT выдает на шину адреса номер порта, а на шину данных сами данные. И адреса портов это не память, поэтому адрес порта может увеличиваться на единицу, а данные могут быть любого размера.Там нет никакого инкремента адреса, поэтому непонятно откуда взялся порт 84, точнее ваше предположение скорее всего неправильно насчет этого порта. Возможно баг в самом устройстве. Да и непонятно как устройство дожно на это все реагировать. Вообще было бы интересно докопаться до истинной причины.
Я думаю рисовать сложные скрипты внутри процесса — это антипаттерн. Такое лучше выносить в виде внешних задач (external task). Они потом прекрасно отлаживаются. Ну и сам воркер для этих задач легко пишется и отлаживается.
А чего сразу Интел.
Напомню, когда планировался переход из 32 в 64 бит — у интел, скорее всего, были планы переделать все. Но тут быстро подсуетилось амд…
Почитал про это поделие — не впечатлило:
— прибитие гвоздями алгоритма шифрования к версии а еще и к типу так себе решение;
— local, public — это обязательно полностью писать? кобол все- равно не переплюнуть;
— кодирование размера как 8 байт — автор думает что в токене будут терабайты? кодировки utf или asn смотрят с удивлением на этот финт;
— jwt это не только токен, это еще oauth стандарт, рассказывающий про инфраструктуру.
Все постояннос равнивают JWT с сессиями, забывая (или не зная) откуда ввобще оно взялось. JWT часть OAUTH спецификации, которая рассчитана на мультисерверную среду. Там есть сервер авторизации — который выдает токены и сервер ресурсов — который использует токены. В спецификации это разные сущности, и им друг с другом не нужно общаться. Попробуйте не общаться, если у вас просто идентификатор сессии.
Отсюда можно сделат вывод — если у вас монолит — вам не нужно все усложнять — используйте сесиии. Если у вас мультисерверная среда — не придумывайте велосипед — используйте OAUTH и JWT токены.
Я намекал, что большая часть смен — это утеря телефона или почты. А вы предлагаете это все через техподдержку проводить? Ну это не серьезно.
Здесь, конечно, не помешал бы дополнительный канал с пользователем, но его нет. А утерянный телефон или почта это точно не доп. канал подтверждения. Так что тут, я согласен с Instagram. А вот насчет возврата, не все так однозначно. У гугла, вроде, есть превичный емаил, который нельзя сменить или что- то такое.
Человек, возможно, меняет телефон или почту, если у него нет доступа к старому телефону или почте. И если слать пуш уведомления на недоступный пользователю телефон или почту, то как сам пользователь может их сменить?
У вас наивное представление об алгоритмах с закрытым/открытым ключем как об симетричных блочных алгоритмах, где используется поосто случайная последовательность. Это не так. Повторю, у кждого алгоритма свои ключи.
Все таки зависит от размера ключа. А хеш — это входные данные для алгортмов с открытм/закрытым ключем. Притом часть хеша может быть отброшена, если ключи поддерживают меньший размер данных.
Например для ECDSA на кривой в 192 бита при хеше 256 бит в подписи будет 192 бит хеша.
В мире постправды у Трампа украли выборы, мы находимся на поской земле, нас чипируют с помощью 5g и так далее и тому подобное. И это теперь называют альтернативной точкой зрения.
С другой стороны, чем больше будет этого маразма, тем меньше будет прибыль и быстрее все это загнется. И тогда, наконец-то, появятся адекватные сервисы.
Вас ни сколько не смущает то, что вы предлагаете?
Напомню, когда планировался переход из 32 в 64 бит — у интел, скорее всего, были планы переделать все. Но тут быстро подсуетилось амд…
— прибитие гвоздями алгоритма шифрования к версии а еще и к типу так себе решение;
— local, public — это обязательно полностью писать? кобол все- равно не переплюнуть;
— кодирование размера как 8 байт — автор думает что в токене будут терабайты? кодировки utf или asn смотрят с удивлением на этот финт;
— jwt это не только токен, это еще oauth стандарт, рассказывающий про инфраструктуру.
Отсюда можно сделат вывод — если у вас монолит — вам не нужно все усложнять — используйте сесиии. Если у вас мультисерверная среда — не придумывайте велосипед — используйте OAUTH и JWT токены.
Здесь, конечно, не помешал бы дополнительный канал с пользователем, но его нет. А утерянный телефон или почта это точно не доп. канал подтверждения. Так что тут, я согласен с Instagram. А вот насчет возврата, не все так однозначно. У гугла, вроде, есть превичный емаил, который нельзя сменить или что- то такое.
Например для ECDSA на кривой в 192 бита при хеше 256 бит в подписи будет 192 бит хеша.