May 1st, 2014

404

Из комментов на хабре

(по мотивам обсуждения http2)

Начало XXI века характеризовалось неожиданным усложнением, когда простые вещи делали сложными. Вместо простого http, который можно написать на коленке сделали http2, вместо /etc/init.d — systemd, вместо ipv4 — ipv6… Первые тенденции появились ещё в конце XX века, когда вместо ISA шины (которую можно было собрать на рассыпухе) сделали сложную PCI, когда вместо ком-портов появились USB (требовавшие целой отдельной микросхемы для работы).

К началу 20ых годов сложность используемых протоколов достигла такого уровня, когда на планете не осталось ни одного человека, способного объяснить, как именно работают компьютеры. Между экспертами-сетевиками шли ожесточённные дискуссии о том, сколько субслоёв физического уровня в стеке сетевых технологий — 42 или 45? Сторонники 45 указывали на дополнительный протокол криптографического согласования между патч-кордом и используемой прошивкой в SFP3, сторонники 42 указывали на то, что согласование криптографии между разъёмом и патч-кордом находится за пределами хост-системы и учитываться не должно.

Несколько исследовательских групп пытались разобраться с тем, что именно происходит между канальным и сетевым уровнем. Предложенная модель включала в себя автоматическую транскрипцию исполняемого кода с его репликацией посредством специальных аппаратов Гольджи, расположенных на пятом ответвлении от extended secure neighbor solicitation, бинарное представление SGML-кодированного конечного автомата, используемого для интерпретации виртуальной машины, выполняющий битлеты из транскрибированных L2 протеаз.

Институт исследования транспортных протоколов продолжал экспертный трейсинг. Эксперимент начался в 2021 году и ставил своей целью step-by-step исполнение в виртуальной среде процесса обработки tcp3 фрейма. К 2029 году команда закончила трейсинг согласования опций и почти дошла до момента трансформации данных в момент приёма. К этому моменту в институте над проблемой уже работало более 30 тысяч человек, а скорость трассировки дошла до 5 тысяч инструкций в час. Исследователи раннего поколения жаловались, что изменения в научных работах происходят так быстро, что они не успевают их прочитать, а беспечный выходной способен оставить без сна на ближайшую неделю, так много материалов публиковалось. По планам института трассировка до передачи данных браузеру должна была закончиться до 2050ого года.

На научной конференции по исследованию протоколов была поставлена ещё более амбициозная цель — разобраться что происходит с информацией на пути из сокета до момента его преобразования в фотоны. Скептики оценивали сроки в несколько столетий, а наиболее пессимистичные указывали на то, что количество людей, задействованных в процессе, превзойдёт население Китая (16 миллиардов к тому моменту).

К сожалению, даже скептики не смогли предсказать масштабы работ, так как к моменту написания этого учебника, 250 лет спустя начала работ, все 40 миллиардов человек так и не дошли до момента определения к какому табу относятся полученные байты.
404

Lucene/elasticsearch/kibana

Итак, помимо адского интерфейса, у меня сформулировалась одна важная претензия: синтаксис запросов не позволяет реализовать ключи -A/-B/-C grep'а.

Напомню, эти ключи показывают After(-A), Before(-B), Context (-C) вокруг указанной строки. То есть запросив grep "TRACE" -C 30 log.log мы получим 61 строку, в которой будет 30 строк до и 30 строк после сообщения об ошибке. Это особенно важно, если трейс не содержит в себе описания операции. Например, у нас идёт "asking 192.168.1.1 for data", а потом трейс ENOROUTE без указания адреса. Самым важным тут является а) трейс с ENOROUTE, б) адрес, куда не удалось обратиться.

Я не могу придумать адекватного фильтра на lucene, который это может отфильтровать.

Если кто-то может показать пример - покажите, пожалуйста.
404

странная идея - json pipe processing

(По результатам сегодняшнего срача вокруг эластика на работе, конструктивная часть).

Среди всего, что было у MS сделано в powershell, была одна хорошая идея - это передача объектов через pipe.

Я как-то мельком слышал про попытку xml'изации pipe'а. Которая была обречена на проклятия за одно упоминание xml.

Но, теоретическая проблема структурирования объектов, передаваемых в pipe, остаётся.

Вопрос №1: были ли попытки тут сделать что-то подобное?

Если нет, вот набор идей:

Все утилиты, кроме входных и выходных, работают с валидным json'ом. Если такой утилите попадается невалидный json, она:
а) пропускает как есть
б) молча съедает всё, что не json
в) останавливается

Поведение, видимо, контролируется ключами командной строки и/или переменными среды окружения.

Каждая утилита решает одну конкретную проблему.

Например:

json-array-head - возвращает первый элемент из json'а, который список (в top-level). Ключи и поведение аналогичное head. Аналогичный же json-array-tail, json-array-sort, json-array-uniq, json-array-shuffle, json-array-count и т.д. json-array-join принимает на вход два массива, выдаёт один, объединённый. Например, так:

(print-json1;print-json2)|json-array-join|json-array-sort|json-array-uniq|json-array-shuffle|json-print

json-obj-any возвращает любой элемент, json-obj-get возвращает элемент по ключу, json-obj-join объединяет два объекта, json-obj-append добавляет элемент к json'у (то есть первый json, второй объект, json-obj-prepend наоборот) и т.д.

Ключевым являются входные и выходные эндпоинты.

Допустим, простейшее: lines2json - принимает список строк, делает из них array. syslog2json приводит syslog вывод в json, keyval2json превращает вывод key value в json, при этом разделитель даётся в командной строке, а по умолчанию - что-то вменяемое (например, любая комбинация из символов пробела, таба, двоеточия, пайпа, запятой или точки с запятой). Таких фильтров можно придумать много.

Выходные эндпоинты аналогичны:

jsonpipe уже написан (http://thechangelog.com/jsonpipe-convert-json-to-a-unix-friendly-line-based-form/)
json2js выводит в виде операторов присвоения явы
json2env выводит в виде готовых к env'у выражений
и т.д.

Я подожду комментариев, если не будет, попытаюсь что-то своё налабать.

Да, и нужно думать про имя. Имена в примере выше слишком длинные. Я бы предпочёл иметь к ним короткие алиасы вида jog (json-object-get), jah (json array head), etc. Варианты: shson, jsh, jash, jajo, json4shell.

Ах, да, главное, чуть не забыл. ФЯП, разумеется.

json-array-map - работает аналогично xarg'у, принимает на вход array из json'а, вызывает указанную программу для каждого эелмента array, результат заворачивает в array.

json-array-filter - аналогично, но пропускает элементы только в зависимости от результатов выполнения указанной программы.

и т.д.