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

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

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

показать невозможно. 

Возможно, получится, если (в двадцатых годах двадцать первого века) изначально быть готовым визуализировать это не «средствами TTY-консоли с ASCII-символами», а ну хотя бы с 2D-анимацией.

Но да, вы правы, я в первую очередь про «diff-инструментарий для отображения», а не про «diff для патчинга файлов».

Мысль про «переехал без изменений» – это самый первый/самый очевидный приходящий в голову кейс. Идея же «дифф для деревьев» на самом деле настолько большая и сочная...

... что я только что погуглил и нашёл уже кучку «подходов к снаряду»!

Difftastic.

SemanticDiff.

GumTree.

Здравая мысль в этой идее есть. Но, возможно, не там, где думает автор.

В исходном виде эта идея проблематична... в момент попытки оторвать AST-дерево от синтаксиса. «А что, Go и Python, это ж примерно одно и то же, только синтаксис разный – так что давайте переключалку между синтаксисами сделаем».

Да вот нет. Сотни языков программирования придуманы не потому, что «одним нравится писать BEGIN / END, другим фигурные скобочки, а третьим круглые».

А, например, потому, что одним нравится воспринимать весь код как данные, и писать функции, способные работать с последовательностью statement-ов точно так же, как с последовательностью целых чисел. Другим – писать математику изначально, на уровне языка, векторизованно. Третьим – иметь строжайшую и надёжнейшую типизацию на уровне языка (при этом автоматически выводимую), четвёртым – не иметь никакой строгости в типизации и не париться по ней до момента запуска, когда в одной переменной может оказаться и строка, и число, и свиной хрящик. Пятым – иметь на уровне языка контроль над AST и возможность написать макросы, работающие прямо с деревом кода, шестым – на уровне языка иметь возможность написать макросы, работающие исключительно с исходным кодом.

Попытка сделать «универсальный AST для всех языков» была бы, мягко скажем, сложна. Jack of all trades, master of none.

... зато как только мы осознаём, что «AST – это вообще специфика конкретного языка, и AST для Rust-а будет заметно отличаться от AST для SQL»,... мы видим, что идея работает значительно лучше. Н

Любая качественная современная IDE всё равно строит такое дерево внутри себя. Позволяет делать крутые операции, работающие именно с семантикой кода, а не с текстом; самое простое – это, например, переименовать функцию, так, что при этом изменятся и все её вызовы (а вот упоминания её в текстах, комментариях, документационных строках – изменятся или нет только по твоему выбору), а более сложное, например – это рефакторить целый метод, вытаскивая его в функцию или поднимая в иерархии классов.

А вот что многие такие IDE не делают до сих пор, кажется – это не делают синтаксически-специфичные diff-ы. Как-то как пошла десятки лет назад идея делать «diff-ы на уровне текста» – так до сих пор и тянется; и массово используемый git со своими патчами только поддерживает её.

Было бы очень удобно, если бы появился и вошёл в массы инструментария для дифф-патчинга, понимающий именно синтаксис кода (и да, разумеется, его пришлось бы научить AST-ам всех языков отдельно – а без этого он бы работал по старинке, «с исходником»).

Не «в файле удалено 60 строк, добавлено 60 строк», а «перетащил метод replaceItem и поставил перед методом deleteItem, а не после, как было раньше; но не изменил ни буковки».

Не «20 строк модифицировано где-то внутри себя», а «переименовал переменную цикла i в index».

Не «в 30 файлах удалено по 30 строк, добавилось по 20, в одном появилось 50 строк», а «в TreeModel, HouseModel, GunModel, WolfModel, HumanModel, PlayerModel был выпилен метод render, который у всех имел почти одинаковую реализацию (AST которой во многом был похож во всех моделях), и различался только логикой создания в мире, зато появился классо-специфичный метод instantiate; зато у BaseModel появился тот самый новый метод render, общий для всех, и абстрактный метод instantiate (вызываемый render-ом); и кстати, при массовом рефакторинге ты лажанулся и забыл, что PlayerModel::render вызывал ещё predictMovement – и ты удалил его –, вызов которого был только в его AST, но отсутствовал во всех остальных похожих зарефакторенных».

Есть способ ещё круче – для всех тех страдальцев, кому (как мне) в 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 ...

Информация

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