Как стать автором
Обновить
275
0
Honeyman @Honeyman

Пользователь

Отправить сообщение

Есть способ ещё круче – для всех тех страдальцев, кому (как мне) в Type-C не хватает масштабности и брутальности Type B:

USB-C коннекторы Neutrik. Той самой фирмы, которая делает лучшие (или одни из лучших) XLR-коннекторы. NMC-C-HR (мама) и NMK-20U-* (кабели).

Neutrik NMC-C-HR
Neutrik NMC-C-HR
Neutrik NMK-20U-*
Neutrik NMK-20U-*

Хотя Type A у тех же Neutrik были и побрутальнее.

NAUSB-W-B
NAUSB-W-B
NKUSB-*
NKUSB-*

что вы уже получили деньги на операционную систему и уже купили её, однако у неё произошёл EOL

Внезапно произошёл? Если это случилось внезапно для вас – вероятно, вы профнепригодны. Если в 2013-ом или 2014-ом году вы купили Windows Server 2003. Не Windows Server 2008 (у которого EOL наступил в 2020-ом году – но в 2013-ом он уже был). Не Windows Server 2012, который вы и должны были купить в 2013–2014–ом году (и у которого EOL наступит ещё через годик, но понятно, сейчас он уже неактуален).

Впрочем, есть вариант с сознательной диверсией....

Почему всё это нужно менять, если стол не треснул, сервер продолжает трудиться,

Не нужно, конечно же. Но с другой стороны, такому серверу и обновлять «сертификаты Минцифры» не нужно, потому что этот сервер явно и очевидно не подключен к интернету (в обратном случае – см. пункт 1 про профнепригодность; ну а в ваших терминах – «стол уже треснул»). И поддерживать не надо. А значит, и решать проблемы «с написанием скриптов, которые бы работали на операционке, снятой с поддержки 8 лет назад», тоже ни к чему.

К слову, вы в курсе, что у Windows XP/Server 2003 в SSL-сертификатах вообще не поддерживаются все современные криптоалгоритмы на эллиптических кривых? Красота какая, а? Найдите там хоть какие-нибудь TLS_ECDHE_* алгоритмы...

... впрочем, речь идёт разве что про 2014-ый год. В котором вы поставили-настроили сервер, а там опа, внезапно EOL.

А сейчас – 2022-ой. И EOL у сервера, который вы сейчас купите, не должен наступить раньше чем через 9 лет...

Да-да, у меня в 92-ом были проблемы с bash-ем, и с тех пор я ему не доверяю, уж лучше старый проверенный ksh...

Если что, EOL у XP был в 2014-ом, 8 лет назад. У Server 2003 – в 2015-ом.

Предвосхищая дальнейшие мысли: и у Windows 7, и у Windows 8 (не проапгрейденной до 8.1) тоже уже случился EOL.

В 2021-ом году не было и не могло быть задачи «сделать простой switch» (на уровне K&R C примерно 40-летней давности). Это было бы немножко… неактуально, вы не находите ли?

Всё-таки немножко актуальнее задача «сделать простой match» (на уровне Haskell 25-летней давности или Scala 17-летней).
Как-то странно говорить про потерю монополии архитектуры Intel/x86 на рынке, про то, что AMD и Intel не приходилось беспокоиться и задумываться, что происходит на рынках альтернативных архитектур, и упомянуть только M1. И не упомянуть ещё одно интересное слово, по поводу которого AMD и Intel стоило бы занервничать ещё больше.

Graviton.

Ещё 5 лет назад Amazon купил одну израильскую компанию, разрабатывающую ARM-процессоры. Всё-таки у Амазон в их расходах на хостинг-центры немалую долю составляет закупка оборудования.

Вот в 2018-ом году на AWS Summit уже и были анонсированы первые Graviton-ы, ARM-процессоры для серверов (а ещё и Inferentia, какие-то системы именно для алгоритмов обучения).
А в 2019-ом – Graviton2. На архитектуре Arm Neoverse N1, именно ориентированном на серверы варианте Arm.

И сейчас инстансы с этими Graviton2 понемногу появляются и для платформенного использования («как виртуалки»),… но и для software-as-a-service (например, Amazon RDS – когда пользователь получает «СУБД как услугу»).

И вот тут уже стоило бы забояться ещё больше. Дорогие (но известные) ноутбуки — это одно. А массовый хостинг, в котором вместо «дебиана на интел» можно запустить «дебиан на арм» и (возможно) обнаружить, что нужную тебе производительность ты получаешь за меньшие деньги — это очень опасно. А когда ты даже не должен разбираться с особенностями архитектуры, а получаешь «одну и ту же СУБД, но на твой выбор или на интеловском процессоре или на ARM» – то переключиться с интел на арм и обратно становится совсем просто.

И это ещё вопрос, с чего на что переключаться — в списке «инстансов с оптимизированной памятью», например, инстансы на Graviton2 стоят вообще по умолчанию.

И вот тут, если вдруг окажется, что пользователям Amazon AWS Graviton2 вполне нравится – тут уже речь пойдёт о том, что Amazon перестанет закупать серверные процессоры в таком количестве. И влияние на доходы Intel будет не менее заметным.
А что, в PL/Python нельзя сделать
json.loads(something, parse_float=decimal.Decimal)
?
> Как такового «квантового шифрования» в виде готовой алгоритмической реализации в природе ещё не существует.

Да и не может существовать. Потому что квантовая криптография в целом и квантовый обмен ключей в частности реализуются не алгоритмически, а аппаратно. И, к слову, существуют – вот, например, их делает и Toshiba.

> И в обсуждаемой «коробке» тоже отсутствует.

Вы уверены в этом? МГУ заведомо хуже Тошибы?

> Существуют лишь протоколы обмена ключами устойчивые к взлому для постквантовой криптографии («PQ»). Имеенно на это и заточен PQCrypto-VPN.

Протоколы квантового распределения ключей — это немного другая аббревиатура, а именно QKD.

А квантовая криптография и «постквантовая криптография» не имеют между собой примерно ничего общего. Одна — реализуется исключительно аппаратно, обязательно требует фотонов и использует эффект «квантовой запутанности»; а вторая (PQ) — реализуется программно и использует алгоритмы, для которых пока не было найдено реализаций их «взлома» посредством квантового компьютера.
И давно ли PQCrypto-VPN научился делать квантовое шифрование? А более интересно, как он научился это делать «на обычных PC», без специального оборудования?
Справляется — скорее junior. Прочитал требования «на доске, от руки», скривился и сказал «а позовите лучше архитектора проекта, в который вы меня хантите, нам найдётся что пообсуждать» — скорее senior.
Это не 256-битные ключи, это 256-битные целые числа — при чём тут криптография?

И опять же, вы куда-то пошли не в ту степь. Я вам показал наглядный пример, нарушающий ваше предположение «в жизни вы НИКОГДА с такими числами не столкнетесь» — а вы поддержку, по сути, BigInteger-ов (в терминологии Java) называете недостатком. Что ещё тогда «недостаток»? Удобные высокоуровневые фронтенды над epoll? «Спрятанные библиотеки» работы с HTTP на высоком уровне? Нужно больше таких «недостатков», пожалуй.
Для начала, расскажите, в каких областях техники оперируют такими степенями. В жизни вы НИКОГДА с такими числами не столкнетесь.


При работе с криптовалютами.
В одном биткойне 10⁸ сатоши. Всего же в системе общее количество сатоши, если я ничего не напутал — примерно 2.1·10¹⁵ сатоши.
В одном эфире 10¹⁸ wei, а для учёта суммарного total supply понадобится работать с числами порядка 10²⁶. Но при этом в системе используются 256-битные целые, поэтому надо уметь работать с числами порядка 10⁷⁸.
В той же Universa в создаваемых смарт-контрактах (а значит, и токенах) «дробность валюты» вообще не ограничена, даже конкретным размером целых чисел.

И да, не путайте целые числа с double. Все те варианты, которые вы предложили (double/extended), для финансовых операций не подходят в принципе.
Более мощную мотивацию для массового перехода в .onion всего на свете сложно себе представить.


Более откровенного «троянского коня» по затаскиванию множества наивных пользователей в «ультрабезопасный надёжный и анонимный .onion» сложно представить.

Когда задумаетесь о «переходе в .onion» не просто теоретически, а практически — вспомните, пожалуйста, что его архитектура подразумевает 1024-битный RSA-ключ (пробовал сгенерировать 2048-битный ключ — он тупо не заработал) и… только не смейтесь, кто понимает… SHA-1 для вычисления домена.
«Запретить использовать вычислительные мощности для сбора, хранения и передачи информации о предпочтениях пользователей».

А что, интересная идея.

Только попробуйте сначала на себе, пожалуйста. Проверить этот сценарий на удобство достаточно легко — просто каждый раз, когда берёте телефон, чтобы что-нибудь сделать, выполняйте перед тем, что планировали, factory reset.
Тут маленький нюанс, что Google и Яндекс к тайне банковских вкладов вообще никак не относятся.

А что, Сбербанк к ней относится? И вообще, что, «тайна банковских вкладов» есть в России?

Помните, как все смс Мегафона в Яндексе всплыли?

Любопытен факт, что это была проблема Мегафона и при этом достижение Яндекса («все яндексовые механизмы работали отлично»).

Вот и тут такая же история может получиться.

А может не получиться. FUD-ом балуетесь?
У гугла и яндекса намного больше моих денег, чем у Сбербанка (потому что конкретно в Сбербанке моих денег что-то около нуля). А лежащую у гугла мою личную информацию и архив почты я бы оценил дороже, чем мои депозиты во всех банках и стоимость всех принадлежащих мне акций.
Ну точно, там такие альтруисты сидят, которые размышляют над тем, чтобы им ещё такого сделать чтобы сдирать с клиентов поменьше денег ))


Не-а.

Там, как и везде, сидят такие же лентяи, которые думают, как им бы работать поменьше, а результат получать получше.

Простой вопрос: как по-вашему, добавление счётчиков на сайт банку экономически выгодно или экономически невыгодно?
> или вместо депозитов надо кредиты написать, или вместо выше — ниже. :)

Да, вы правы, спасибо.
и ничего взамен не получаю

Неправда, получаете.
Маркетинговые данные, которые собирает (например, с помощью этих инструментов) и которыми пользуется Сбербанк, приводят к повышению эффективности его работы (иначе этих счётчиков там и не стояло бы).
Повышение эффективности его работы приводит к повышению качества услуг и/или снижению их себестоимости.
В конечном итоге всё отражается на цифрах в годовом отчёте банка.

Утрированно: не будь этих счётчиков — процент по депозиту в Сбербанке был бы самую чуточку выше.
Как мило, что Сбербанку в вопросах обработки секретных данных вы доверяете больше, чем Гуглу и Яндексу.
1
23 ...

Информация

В рейтинге
Не участвует
Откуда
Нижегородская обл., Россия
Зарегистрирован
Активность