Возможно, получится, если (в двадцатых годах двадцать первого века) изначально быть готовым визуализировать это не «средствами TTY-консоли с ASCII-символами», а ну хотя бы с 2D-анимацией.
Но да, вы правы, я в первую очередь про «diff-инструментарий для отображения», а не про «diff для патчинга файлов».
Мысль про «переехал без изменений» – это самый первый/самый очевидный приходящий в голову кейс. Идея же «дифф для деревьев» на самом деле настолько большая и сочная...
... что я только что погуглил и нашёл уже кучку «подходов к снаряду»!
Здравая мысль в этой идее есть. Но, возможно, не там, где думает автор.
В исходном виде эта идея проблематична... в момент попытки оторвать 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, но отсутствовал во всех остальных похожих зарефакторенных».
что вы уже получили деньги на операционную систему и уже купили её, однако у неё произошёл 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 лет...
В 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 будет не менее заметным.
> Как такового «квантового шифрования» в виде готовой алгоритмической реализации в природе ещё не существует.
Да и не может существовать. Потому что квантовая криптография в целом и квантовый обмен ключей в частности реализуются не алгоритмически, а аппаратно. И, к слову, существуют – вот, например, их делает и 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.
У гугла и яндекса намного больше моих денег, чем у Сбербанка (потому что конкретно в Сбербанке моих денег что-то около нуля). А лежащую у гугла мою личную информацию и архив почты я бы оценил дороже, чем мои депозиты во всех банках и стоимость всех принадлежащих мне акций.
Возможно, получится, если (в двадцатых годах двадцать первого века) изначально быть готовым визуализировать это не «средствами 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-* (кабели).
Хотя Type A у тех же Neutrik были и побрутальнее.
Внезапно произошёл? Если это случилось внезапно для вас – вероятно, вы профнепригодны. Если в 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.
Всё-таки немножко актуальнее задача «сделать простой match» (на уровне Haskell 25-летней давности или Scala 17-летней).
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 будет не менее заметным.
Да и не может существовать. Потому что квантовая криптография в целом и квантовый обмен ключей в частности реализуются не алгоритмически, а аппаратно. И, к слову, существуют – вот, например, их делает и Toshiba.
> И в обсуждаемой «коробке» тоже отсутствует.
Вы уверены в этом? МГУ заведомо хуже Тошибы?
> Существуют лишь протоколы обмена ключами устойчивые к взлому для постквантовой криптографии («PQ»). Имеенно на это и заточен PQCrypto-VPN.
Протоколы квантового распределения ключей — это немного другая аббревиатура, а именно QKD.
А квантовая криптография и «постквантовая криптография» не имеют между собой примерно ничего общего. Одна — реализуется исключительно аппаратно, обязательно требует фотонов и использует эффект «квантовой запутанности»; а вторая (PQ) — реализуется программно и использует алгоритмы, для которых пока не было найдено реализаций их «взлома» посредством квантового компьютера.
И опять же, вы куда-то пошли не в ту степь. Я вам показал наглядный пример, нарушающий ваше предположение «в жизни вы НИКОГДА с такими числами не столкнетесь» — а вы поддержку, по сути, BigInteger-ов (в терминологии Java) называете недостатком. Что ещё тогда «недостаток»? Удобные высокоуровневые фронтенды над epoll? «Спрятанные библиотеки» работы с HTTP на высоком уровне? Нужно больше таких «недостатков», пожалуй.
При работе с криптовалютами.
В одном биткойне 10⁸ сатоши. Всего же в системе общее количество сатоши, если я ничего не напутал — примерно 2.1·10¹⁵ сатоши.
В одном эфире 10¹⁸ wei, а для учёта суммарного total supply понадобится работать с числами порядка 10²⁶. Но при этом в системе используются 256-битные целые, поэтому надо уметь работать с числами порядка 10⁷⁸.
В той же Universa в создаваемых смарт-контрактах (а значит, и токенах) «дробность валюты» вообще не ограничена, даже конкретным размером целых чисел.
И да, не путайте целые числа с double. Все те варианты, которые вы предложили (double/extended), для финансовых операций не подходят в принципе.
Более откровенного «троянского коня» по затаскиванию множества наивных пользователей в «ультрабезопасный надёжный и анонимный .onion» сложно представить.
Когда задумаетесь о «переходе в .onion» не просто теоретически, а практически — вспомните, пожалуйста, что его архитектура подразумевает 1024-битный RSA-ключ (пробовал сгенерировать 2048-битный ключ — он тупо не заработал) и… только не смейтесь, кто понимает… SHA-1 для вычисления домена.
А что, интересная идея.
Только попробуйте сначала на себе, пожалуйста. Проверить этот сценарий на удобство достаточно легко — просто каждый раз, когда берёте телефон, чтобы что-нибудь сделать, выполняйте перед тем, что планировали, factory reset.
А что, Сбербанк к ней относится? И вообще, что, «тайна банковских вкладов» есть в России?
Любопытен факт, что это была проблема Мегафона и при этом достижение Яндекса («все яндексовые механизмы работали отлично»).
А может не получиться. FUD-ом балуетесь?
Не-а.
Там, как и везде, сидят такие же лентяи, которые думают, как им бы работать поменьше, а результат получать получше.
Простой вопрос: как по-вашему, добавление счётчиков на сайт банку экономически выгодно или экономически невыгодно?