Category: здоровье

Category was added automatically. Read all entries about "здоровье".

Book

PKI курильщика

Обнаружил тут, что в Ведроиде PKI для нужд VPN сделана из говна.

Скажем, есть the Android Keystore provider feature, introduced in Android 4.3

Оно предоставляет плюс минус те же фичи, что виндовые Cryptographic Service Providers/Certificate Stores. А именно, возможность генерировать и использовать приватные ключи так, что приложение не видит ключа.

Ну то есть ключ живёт где-то там под рутом, и даже если нет HSM и ключ можно извлечь, имея физический доступ, при отсутствии уязвимостей эскалации привилегий наш ключ в домике. Он вообще не покидает никогда места генерации. Это опять же из разряда "нет поверхности атаки - нельзя атаковать".

Так вот, в том месте, где у здорового человека генерируется ключ внутри кейстора и публичный ключ отдаётся на подпись центру сертификации, у андроид-курильщика... импорт ключевой пары из ёбаного файла. Который блядь может любое приложение с правами доступа к диску прочитать и отправить товарищу майору.

Тут ещё нашлось, что SCEP это вовсе не MS, а, как и JWT, очень даже Cisco и IETF Draft. Но SCEP в Андроид тоже не завезли.
Book

Стабильность здорового человека

Один из компонентов с 2014 года не запускал.

Обнаружил тут, что на девелоперской тачке нет скрипта, запускающего один из перловых компонентов моей распределённой системы. Обнаружился в папке unused_20140718\shit. Выяснилось что я его в 2014 году аж переместил в другую папку за ненадобностью - я периодически чищу рабочее окружение, там куча диагностических скриптов на выброс и входных данных, воспроизводящих баги, образуется.
Book

Рабочая область языка

> как именно формализовать рабочую область языка?

Есть несколько вариантов. Например:

1. Если проект X писать на языке Y, и проект провалится, будет ли обвинён выбор языка?

Ну то есть игру или архиватор на С++ писать - риска обвинения нет.

2. Если на форуме любителей Y задавать вопросы по проблемам в проекте Y, есть ли вероятность получить квалифицированный ответ?

Грубо говоря, SO по JS завалено нубами, и ответ на трудный вопрос получить трудно, так как даннинг-крюгеровцы набигают, а опытные товарищи не мониторят.

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

3. Разбив инструментально-библиотечную поддержку по областям: https://github.com/Gabriel439/post-rfc/blob/master/sotu.md
Book

Стабильные версии

По опыту многолетней эксплуатации двух проектов оказывается, что стабильные версии компонентов удобнее помечать пост-фактум.

Есть "книжное" понятие стабильной версии здорового человека: делаем новую ветку мастера с feature freeze и только фиксим баги. Через какое-то время в этой ветке оказывается нечего чинить: всё починили, остались только баги, на которые всем похуй, новые баги обнаруживаются редко. Код стабилизировался.

Такие "настоящие" стабильные версии попадаются крайне редко, обычно разные вариации стабильной версии курильщика.

1. Замораживание перед релизом.

Это наиболее частая форма стабилизации, в особенности перед первым релизом. Часто это не для стабилизации вовсе - просто все заебались и хотят релизиться, но QA не пускает. Если QA нет - это внутреннее чувство прекрасного, не позволяющее релизить совсем уж говно и/или заказчик, от которого надо получить бабло и забыть проект как страшный сон.

2. Замораживание перед деплоем

Это наиболее характерно для проектов в стадии поддержки.

3. LTS-ветки

Надо понимать, что LTS-ветки - это просто замороженные ветки. Они обретают некоторую степень стабильности лишь через некоторое время, когда наиболее значительные баги там обнаружат и пофиксят. Ну то есть идея "обновиться на свежевышедшую LTS-ветку" это ужас-ужас.

4. Бэкпорт-ветки

Это как LTS, только на баги в ветке всем похуй. Однако исправления, которые делаются в основной ветке, по возможности бэкпортируются.

Допустим, у нас в проекте есть подсистема из говна. Мы делаем ветку, и затем в мастере заменяем её на подсистему из шоколада. В случае LTS-ветки баги в системе из говна чинятся. А в случае бэкпорт-ветки - нет.

Идея бэкпортов в том, что бэкпорты очень дёшевы. Кроме того они встречаются в сценариях, когда веток как таковых нету.

5. Погонять на стейджинге

Это уже хипсторская идея, в чём-то похожая на старые бета-версии и релиз-кандидаты. Мастер выкатывается на стейджинг, и если всё ок - то через какое-то время выкатывается на продакшен.

6. Погонять на продакшене и если поломалось - откатить

Это вариация 5, но более экстремальная (во всех смыслах).

7. Погонять на продакшене и если поломалось - починить по-быстрому, если не получилось - откатить

И тут как раз мы приходим к первому абзацу поста. Если откатывать - то куда? Надо помечать годные ревизии.

У меня получается так. Запилил фичу - пометил текущую ревизию на проде как стабильную, выкатил на прод. Запилил хотфикс - выкатил по-быстрому, ничего не помечая. Если цепочка хотфиксов после которой обнаруживается что-то фатальное что чинить долго - то откатываем не на прошлый хотфикс, а на последнюю помеченную.


Преимущества такие:
- получается человекочитаемые имена версиям давать в виде даты. Благо двух версий в один день не бывает
- не бывает такого, что версия, помеченная как стабильная, становится нестабильной (может когда-то и бывает, но у меня не было)
- между стабильными версиями нетехнический ченжлог - то есть не бывает такого, что весь ченжлог - это шишку где-то в кишках поменяли на мышку, как правило есть какие-то видимые фичи и улучшения
- виден долгосрочный прогресс - условно, сколько обновлений в год
- всё вышеперечисленное не замусоривается хотфиксами
Book

Копирование файлов здорового человека - 2

Внезапно оказалось, что там в fastcopy неадекватные размеры буферов и значения конкарренси. Но к счастью там есть настройка. Так что удалось в 2-3 раза ускорить копирование мегабайтных файлов в different HDD mode (прошлый пост был про same hdd mode). Я ещё буду проверять дополнительно, конечно.
Book

Копирование файлов здорового человека

https://ipmsg.org/tools/fastcopy.html.en

Process Explorer IO Chart

Для сравнения, всякое говно типа фара, виндового эксплорера, robocopy, teracopy - копируют в разы медленнее этот конкретный датасет на этом конкретном диске.

IO-трафик показывается одновременно 19 чтение 19 записи против попеременного 80-60. Файлы достаточно большие (сотни мегабайт). Буфер в фасткопи конфигурируется. Я поставил гигабайтовый. По умолчанию был 128 мб.
Book

Сколько байт в байте

Раньше был рекорд 10. Типа 1000 флоатов занимала не 4кб, как у здорового человека, а 40. Оверхед хранения.

Сейчас этот рекорд побит. Короче, есть gearman.org, сервер с дебильным протоколом. Но т.к. дело не в сервере, а в его клиенте, упрощаем. Если бы он протокол нормальным, он бы выглядел так:

отправляем X - он возвращает id, пересылает X воркеру, получает от воркера ответ Y и пересылает нам пару (Y, id)

Т.е. по TCP-коннекшену в одну сторону летят сплошняком одни иксы, скленные в одну большую колбасу, а в обратную - вперемешку id и (Y, id)

Клиент к этому делу выглядит так:

request(X).then((Y) => ...)

Внутри у него таблица соответствий id коллбекам-замыканиям, так что клиент id и протокола не видит, для него это асинхронный вызов функции.

Так вот, выясняется что если мы сделаем "пачкой" arrayOfX.map(request), т.е. отправим массив иксов (скажем 1000 штук) - то образовавшиеся промисы с висящими замыканиями займут аж 8 мегабайт, по 8кб на реквест.

У здорового человека оверхед - 100 байт от силы. 50 энтри в хеш-таблицы, с учётом пустых мест, и 50 замыкание. Итого получаем разницу между здоровым и курильщиком в 80+ раз.
Book

Оси здорового человека

Счастливый финал: пан градиента с осями с 60 фпс в FF.

https://github.com/streamcode9/svg-time-series/tree/626ddf9bed104bb457217f2183084b91a4b4261f/benchmarks/d3-myaxis

В-общем, написан был задней ногой, я там по-минимуму причесал, а так можно ещё улучшать и улучшать.

Помимо частых перерисовок, он ещё на каждый кадр переустанавливал атрибуты всем элементам, вместо того чтобы устанавливать их только для вновь добавляемых.

Дальше, я думаю, можно будет
- просто реюзать палки из сетки, переставлять их на новое место
- использовать группы SVG вместо того, чтобы устанавливать атрибуты индивидуально в цикле
- использовать CSS, чтобы не устанавливать атрибуты при добавлении элемента
- добавлять атрибуты до приаттачивания элемента к дому
- приаттачивать большими кусками (и прочие оптимизации DOM)
Book

Pan здорового человека

Нашёл тут pan курильщика: http://bl.ocks.org/mbostock/4e3925cdc804db257a86fdef3a032a45

Как я понимаю, от создателей d3.js

Сделал из него pan здорового человека: https://github.com/streamcode9/svg-time-series/tree/master/benchmarks/d3-pan-zoom

Интересно, что мне разница видна только в Edge, в FF оба варианта работают +- одинаково.

Зато выяснил, что у меня 3 события мыши на кадр. Соответственно если вы делаете какую-то значительную работу в onmove и аналогах - вы гондон.

Линейная интерполяция по 2 событиям не помогла. Надо хитрее. Я так понимаю, играет роль интервал дискретизации позиции (неточно), ну и надо бороться с overshooting более культурно, чтобы не было дёрганий.

Ещё объявляется приз на технологию равномеризации перемещения. В случае графика точность не требуется, но мне кажется что аналог smooth inertial scrolling был бы к месту.
Book

Task queue курильщика

Когда-то давно я, видя насколько ужасным по производительности бывает код, предлагал конкурс, в котором задачу нужно решить как можно медленнее, и определить с помощью жюри самый остроумный вариант. То есть, не вставлять явные замедления, а максимально правдоподобно написать код, который пройдёт ревью типичным курильщиком, однако будет крайне медленным по сравнению с правильным решением. Эдакая диверсия, месть увольняющегося здорового человека.

Сейчас я нашёл подходящий для этого строительный блок.

С его помощью задача 10к раз применить toUppercase() к строке "abc" занимает 700 секунд! Т.е. 70мс на каждый вызов.

Сделано вставкой в плёвую задачу кода индирекшона, который по всем понятиям (что курильщика, что здорового человека) должен занимать заведомо меньше 70мс.

Эти "abc" ставятся в task queue, и задействованы 3 процесса, соединенные через локалхост: клиент, сервер очереди сообщений типа request/response, и воркер.

Я так понимаю, внутри очереди есть какие-то квадратичные алгоритмы, не рассчитанные на 10к сообщений в очереди, причём, скорее всего во всех 3-х компонентах. Достоверно известно, что там точно всё написано по принципу наивного неконкурентного программирования - т.е. двойных буферизаций, учета bandwidth*latency и прочих трюков нет.

Интересно, где зарыта собака окажется.

Upd: сделал бенчмарк, с квартилями, нормализацией, усатыми графиками и шлюхами. Выяснилось, что исправление, которое умозрительно не может замедлять код, его таки замедляет, причём аж на 8%. Но замедляет только говнореализацию сервера на локалхосте. Нормальную реализацию которая на С++ - не замедляет, как и подсказывает нам голова. А сишную нормальную реализацию по WAN даже ускоряет, собственно ради WAN всё затевалось. Говнореализацию по WAN не тестил, но там думаю ускорение в 270% победит замедление в 8%.