Category: происшествия

Category was added automatically. Read all entries about "происшествия".

Book

mercurial-server всё

Так получилось, что я с незапамятных времён подсел на Меркуриал. Первый коммит аж в январе 2005, до выхода меркуриала, так как я старался импортировать историю. До этого я тоже +- извращениями страдал - Clearcase LT и Perforce. Немного SVN и Darcs было даже.

Так вот, какого-то внятного решения для того, чтобы поместить его на VPS и всем туда пушить, у Меркуриала не было, во всяком случае в ~2010 году. Ну был hg serve, но это какой-то кал.

Так вот, я нашёл mercurial-server, который прилепливался к openssh и прекрасно работал, администрируясь через пуши в служебную репу. Unix way в-общем практически.

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

Ну и на всё это наслаивается смерть Python 2.x и то что я ещё завязался на Trac. Который уже вроде есть в альфа версии под Python 3, ну и на том спасибо.

Но ещё у меня есть старый "продакшен" сервер, который в целом умер, но на 5% работает. И его выкинуть жалко и обновить нельзя. И есть "новая" его версия, которая работает на 95%, но в прод я не выкатываю так как "недоделано".

Ну и надо пушить из прода в этот mercurial-server. Но на проде какой-то старый меркуриал, а на mercurial-server меркуриал новый, но репа была создана в старом и какие-то проблемы с интероперабельностью.

Тьфу.

В-общем надо собирать силы и чинить эти 5% чтобы выкатить "новую" версию и забыть про интероперабельность с говном и палками.

Но "новую" версию я тоже делал уже несколько лет. И она на node 8.x который уже EOL. Оно как бы работает на 10.x но я решил не рисковать, для чего собрал кастомную версию ноды. Но скрипт для сборки взял в арче, а там политика всё динамически линковать. В-общем из-за этого не только плюсы, но и минусы. В результате залепил пакет nodejs-lts-carbon-semistatic, который постепенно приближается к своему официальному бинарному собрату по степени статичности - в 4 версии пакета залинковал icu, там icu 67 68 69 вроде обратно совместимы по сорцам, но в то же время нет. В результате надо было прибивать гвоздями версию icu. Но теперь вроде полечил.
Book

Перл не готов к продакшену-2

Вынес из комментов

1. Не просто пишут низкокачественные модули, но не чинят их потом. Баги не закрываются годами даже при наличии патчей/PR
2. Все модули которые мне нужны (~5) оказались еssentially unsupported (см. п. 1),
3. я даже не могу взять их на мейнтенанс, поскольку авторы последний раз видели перл 10 лет назад и сменили 10 работ и вообще никаких креденшлов не помнят, не могут отдать мне права и им похуй уже, а админы, которые потенциально могут насильно отобрать пакет-сироту, не отвечают неделями, поскольку они такие же и им тоже похуй.
4. Надо лепить приватный (или полуприватный) форк поскольку попытки протолкнуть фикс в апстрим тщетны
5. Поломанные модули сидят также и в perl_core, который технически в одной репе с перлом, т.е. поломан и "сам" перл
6. Система СI-тестов cpan testers на вешающиеся тесты отпадающие по таймауту пишет пустышку, т.е. вешающиеся тесты неотличимы от отсутствия тест-раннера на нужной платформе.
6а. На тесты, которые нельзя запустить по причине не поломки зависимости, тоже возвращается пустышка, и они тоже неотличимы. В результате мейнтейнеры не знают о поломке и не могли бы починить, даже если б им не было похуй.
7. Есть практика опциональных тестов. То есть половина тестов обычно тупо не запускается на автоматических тестерах. Сделано это из благих намерений, но на практике приводит к тому, что всё поломано, но этого не видно.
8. Баг-трекер самого перла - в том же духе, что и модули. Баги висят по 17 лет, и их не закрывают даже по причине смерти всех заинтересованных лиц.
Book

Ещё о деплойменте

Я тут хочу спроектировать и задокументировать полный жизненный цикл IT-предприятия, со всеми процессами и программными компонентами. В первом приближении (остапа несло):

- Взаимодействие аналитиков со стейкхолдерами, извлечение информации из чатов в трекер
- Документирование инцидентов. Сервер упал пришлось переподнять, в очередной раз произошел редкий креш (залогировано редкое событие и т п). Некие объективные данные для оценки серьёзности проблем. Часто бывает недооценка приоритетов в духе "я думал, что этот креш происходит раз в месяц, а вы оказывается каждый день руками переподымаете а мне ничего не говорите". Наоборот тоже бывают - требуют починики редких крешей. Это аналогично случаю, когда хотят ускорения компонента, который почти не влияет на общую производительность. Только не про производительность, а про надёжность.
- Статистика по логам, стектрейсам и креш-дампам. Фактически то же самое что выше, но если восстановление от отказа автоматическое или отказы некритические и невидимые. Своего рода автоматически документируемые инциденты и автоматически собираемая дополнительная информация по вручную задокументированным инцидентам.
- Secure by design система архивирования и бекапов. Скажем, взломанная система не может незаметно затереть или подменить свои бекапы, сделанные до момента взлома (всякие бекапы-на-шару этим свойством не обладают). А если даже взломана система где лежат эти бекапы, взломщик не может их прочитать поскольку они зашифрованы публичным ключом, приватный ключ к которому знает только HSM который сам его сгенерировал и никому не говорит и вообще лежит в сейфе и никогда из него до момента форенсик-анализа инцидента не доставался. Хеши старых бекапов лежат в блокчейне, так что даже если доступ на затирание таки получен, мы это увидим. И те пе, тут можно много напридумывать.
- Мониторинг с алертами и обнаружением аномалий (скажем, автоматически строится статистическая модель текста логов, over 9000 пейперов по anomaly detection ). On-premises https://anomaly.io/ без демонстрации своего очка третьим лицам, с устойчивой системой архивации в стиле предыдущего пункта, т.е. взломщик не может прочитать или подделать метрики собранные до момента получения доступа даже если сломал сервер метрик
- Сорс-контрол: как хостить сорс-контрол, какие бранчи, как сквошить, как называть коммиты, как помечать версии которые попадали на стейджинг и продакшон, как интегрировать с багтрекером ("в какой версии это было пофикшено"), как составлять юзер-визибл ченжлог.
- CI/CD, reproducible builds, обеспечение идентичности стейджинга и продакшена путем техник наподобие имиджей или rpm-ostree. Опять же невозможность подделки имиджа задним числом.
- ...
Book

Мониторинг стихий

Я понаходил инструменты для контроля за всеми стихиями:

- Сводки и предупреждения о бедствиях: http://coe.gob.do (включая их страничку в фейсбуке, поскольку во время бедствий офсайт лежит) - наш МЧС, 3 уровня тревоги по каждой из провинций Доминиканы

- Землетрясения: http://earthquake.usgs.gov/earthquakes/map/

- Ураганы: https://www.wunderground.com/hurricane/ (включая аналитику)

- Общая спутниковая ситуация с дождём, волнами и ветрами: http://windytv.com
Book

Матерная версия "бедняжки"

Мадам тут попала в ДТП на скутере (но отделалась ушибами и неглубокими ссадинами, причём самое смешное, прямо напротив больницы скорой помощи aka http://www.centromedicopuntacana.com/), в связи с чем спросила у меня, как будет по-русски "jodida". Словарь переводит как "бедняжка", но joder - это грубое "ебать", и также употребляется в переносных значениях, близких к русским "наебать-объебать". Т.е. jodida буквально "выебанная". "Затраханная" - это несколько другое, пострадавшего в ДТП так не называют.

Я так понимаю, варианта с причастием нет, и ближе всего "ёбнулась" или "наебнулась". Any thoughts?
Book

Играем в куклы

http://thedeemon.livejournal.com/96870.html

По-моему, это метафорическая иллюстрация к программированию вообще.

1. Пользователю наплевать на технические аспекты

Потребителю, программы, в-общем, всё равно, как она устроена внутри, лишь бы выполняла функции

2. ТруЪ-решения и наколенные

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

3. Refuctoring после увольнения ключевого сотрудника

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

5. Лишние зависимости

Оказалось, что готовых хвостов в продаже нет, но есть головы по приемлемой цене. И голову от хвоста никак не отрезать, потому что и волосы распадутся, т.к. удерживаются не столько резинкой, сколько пластиком головы (кто вырывал волосы куклам в садике, знает). Более того даже если отрежешь - лысые головы никому не нужны, т.е. выгоды никакой

6. Почему компании часто предпочитают смерть проекта открытию исходного кода

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

7. Необходимость стартапу быть пластичным и выпускаться как можно раньше

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

8. Любовь к определённым приёмам

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

9. Любовь к стабильности и запрет рефакторинга

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

10. Почему нельзя давить на разработчика по срокам

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

Зарвали сь эти криптоанархисты

Придумали, значит, самоуничтожающиеся данные. Вот пейпер: http://vanish.cs.washington.edu/research.html

Слово "самоуничтожающиеся" громкое, на самом деле скукотища: Генерируют случайный ключ, помещают его в деградирующее со временем хранилище, уничтожают оригинал ключа и вместе с сообщением хранят адрес дешифрующего ключа в хранилище.

В качестве хранилища используют существующие DHT-сети. Для надежности ключ разбрызгивают по сети через Shamir Secret Sharing, так что ключ можно прочитать из сети, если можно прочитать M из N составных частей.

В результате этой банальщины получают впечатляющие результаты:

It is possible to create a system that can permanently delete data after a timeout:

1. even if an attacker can retroactively obtain a pristine
copy of that data and any relevant persistent cryptographic
keys and passphrases from before that timeout,
perhaps from stored or archived copies;

2. without the use of any explicit delete action by the
user or the parties storing that data;

3. without needing to modify any of the stored or
archived copies of that data;

4. without the use of secure hardware; and

5. without relying on the introduction of any new
external services that would need to be deployed
(whether trusted or not).

Пояснения к пунктам:

1. Имеется ввиду такой сценарий: вы отправили зашифрованное сообщение через гугл. Он тайно от вас сохраняет все сообщения. Затем полиция приходит в гугл с ордером и гугл отдает им сохраненное сообщение. Также у вас конфискуют все криптоключи (которые вы разумеется по недочету меняете раз в 100 лет).

2, 3. Понятно что гугл вы никак не можете заставить удалить свое сообщение

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

5. Тут имеется ввиду, что если б нужно было создать DHT-сеть специально для нужд Vanish, то такое решение было бы менее безопасным т.к. у правительства был бы мотив внедрять в эту сеть левые узлы. А так можно любые сети использовать - в экспериментах использовали Kazaa, Gnutella и Azureus
Book

(no subject)

Недавно своем спортзале я нашел мертвого паука-птицееда.. сегодня обнаружил живого "африканского гигантского миллипеда", длиной сантиметров 15-20

Book

Scoped Resource Pool + Stack Allocator как расширение концепции Apache Pools

Scoped resource pool - это модель полуавтоматического управления ресурсами в С++, средняя между моделью "конструктор-деструктор" и сборкой мусора.

Псевдокод:
{
   pool p;
   void *a = p.allocate(2);
   void *b = p.allocate(3);
}
При смерти пула освобождаются все выделенные в нем ресурсы (в общем случае не только память).

В некотором смысле пул является обобщением scope, автоматического управления памятью в С++ и умных указателей auto_ptr/shared_ptr. В случае автоматического управления памятью грохаются все члены текущего scope или все члены структуры. А в случае пула - все члены пула.

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

Пул является в общем случае декоратором нижележащего аллокатора/деаллокатора ресурсов.

Однако такая модель выделения памяти (ресурсы сначала только выделяются, а потом только освобождаются причем все сразу) дает интересные возможности для оптимизации производительности, слегка пожертвовав инкапсуляцией аллокатора и сделав его интерфейс более толстым.

Классические кучи ориентированы на случайное выделение и удаление блоков случайного размера. Boost Pool Library [2] ориентирована на случайное выделение и удаление блоков фиксированного размера. Scoped resource pool же позволяет использовать самый простой и быстрый способ выделения памяти - стек (правда, сегментированный в общем случае).

То есть, большие сегменты стека запрашиваются стековым аллокатором у нижележащего аллокатора сегментов (ниже на 2 уровня чем пул), а новые объекты просто добавляются в конец текущего сегмента и смещается указатель конца сегмента. При переполнении сегмента в список сегментов добавляется новый блок.

При удалении пула и стекового аллокатора могут вызываться в цикле все деструкторы объектов (а могут и не вызываться, в зависимости от потребностей) и освобождаются сегменты путем вызова аллокатора сегментов.

Таким образом, использование стека в сочетании с пулом позволяет:
  1. существенно ускорить операции выделения и освобождения памяти за счет того, что некоторое количество неиспользуемой памяти не освобождается до уничтожения пула;
  2. уменьшить количество ошибок. связанных с неосвобождением памяти, путем централизованного управления временем жизни
Ссылки по теме:

[1] Apache Portable Runtime Pools
[2] Boost Pool Library