ufm

lmaoooooooooooo

Kryptos

🔗 Kryptos

Один чувак нашифровал, другие мучаются расшифровывают.



Первую часть расшифровали: BETWEEN SUBTLE SHADING AND THE ABSENCE OF LIGHT LIES THE NUANCE OF IQLUSION

Вторую часть расшифровали: IT WAS TOTALLY INVISIBLE HOWS THAT POSSIBLE ? THEY USED THE EARTHS MAGNETIC FIELD X THE INFORMATION WAS GATHERED AND TRANSMITTED UNDERGRUUND TO AN UNKNOWN LOCATION X DOES LANGLEY KNOW ABOUT THIS ? THEY SHOULD ITS BURIED OUT THERE SOMEWHERE X WHO KNOWS THE EXACT LOCATION ? ONLY WW THIS WAS HIS LAST MESSAGE X THIRTY EIGHT DEGREES FIFTY SEVEN MINUTES SIX POINT FIVE SECONDS NORTH SEVENTY SEVEN DEGREES EIGHT MINUTES FORTY FOUR SECONDS WEST X LAYER TWO

Третью часть расшифровали: SLOWLY DESPARATLY SLOWLY THE REMAINS OF PASSAGE DEBRIS THAT ENCUMBERED THE LOWER PART OF THE DOORWAY WAS REMOVED WITH TREMBLING HANDS I MADE A TINY BREACH IN THE UPPER LEFT HAND CORNER AND THEN WIDENING THE HOLE A LITTLE I INSERTED THE CANDLE AND PEERED IN THE HOT AIR ESCAPING FROM THE CHAMBER CAUSED THE FLAME TO FLICKER BUT PRESENTLY DETAILS OF THE ROOM WITHIN EMERGED FROM THE MIST X CAN YOU SEE ANYTHING Q ?

Над четвёртой частью ломают голову, а пятая даже ещё не показалась.

comments

Что было с Амазоном

🔗 Что было с Амазоном

Summary of the Amazon DynamoDB Service Disruption in Northern Virginia (US-EAST-1) Region

19–20 октября 2025 года в регионе Северная Вирджиния (US-EAST-1) произошел значительный сбой в работе сервисов AWS, вызванный, главным образом, скрытым состоянием гонки в автоматизированной системе управления DNS Amazon DynamoDB. Это привело к сбоям в разрешении DNS для региональной конечной точки DynamoDB, что привело к масштабным последствиям для нескольких сервисов AWS. Событие развивалось в три основных этапа: учащение ошибок API DynamoDB (с 23:48 по тихоокеанскому времени 19 октября до 2:40 по тихоокеанскому времени 20 октября), ошибки подключения к NLB (с 5:30 до 14:09 по тихоокеанскому времени 20 октября) и сбои запуска экземпляров EC2 из-за проблем с подключением (с 2:25 до 13:50 по тихоокеанскому времени 20 октября).

Проблема была связана с архитектурой DNS DynamoDB, которая использует DNS Planner для генерации планов конечных точек и избыточные DNS Enactors (в трёх зонах доступности) для их применения через Amazon Route 53. Редкое состояние гонки возникло, когда один Enactor столкнулся с задержками, позволив другому применить новый план и удалить старый в процессе. Это привело к пустой записи DNS для публичной конечной точки, что привело к блокировке подключений. Восстановление потребовало ручного вмешательства для восстановления DNS к 2:25 утра по тихоокеанскому летнему времени, а полное подключение было восстановлено к 2:40 утра по истечении срока действия кэшей. Глобальные таблицы испытывали задержки репликации, но оставались доступными в других регионах.

В EC2 наблюдались ошибки API, задержки и сбои запуска из-за зависимостей от DynamoDB. Менеджер рабочих процессов дроплетов (DWFM) не смог поддерживать аренду на физических серверах («дроплетах»), что привело к ошибкам, связанным с нехваткой ёмкости. После восстановления DynamoDB DWFM столкнулся с перегрузкой из-за накопившихся данных, что потребовало ограничения пропускной способности и перезапуска. Network Manager столкнулся с задержками распространения сетевых данных для новых экземпляров, которые были устранены к 10:36 PDT. Полное восстановление EC2, включая снятие ограничений пропускной способности, произошло в 13:50 PDT. Существующие экземпляры не пострадали.

В NLB возникали ошибки подключения из-за сбоев проверки работоспособности, усугублявшиеся задержкой распространения сетевых данных для новых экземпляров EC2. Это приводило к чередованию работоспособных и неработоспособных состояний, вызывая ненужные отказоустойчивости AZ и снижение производительности. Инженеры отключили автоматические отказоустойчивости в 9:36 PDT, восстановив работу к 14:09 PDT после стабилизации EC2.

Влияние на другие сервисы:
- Lambda: Ошибки и задержки API до 14:15 PDT, с задержками из-за сбоев опроса SQS и недостаточного масштабирования из-за проблем с NLB/EC2.
- ECS/EKS/Fargate: Сбои запуска и масштабирования контейнеров до 14:20 PDT.
- Amazon Connect: Повышенное количество ошибок вызовов/чатов до 13:20 PDT, с обратным заполнением данных до 28 октября.
- STS: Ошибки API до 09:59 PDT.
- AWS Management Console: Сбои аутентификации до 01:25 PDT.
- Redshift: Ошибки запросов и кластеров до 02:21 PDT, некоторые кластеры недоступны до 21 октября из-за заблокированных замен EC2; проблемы с запросами IAM временно затронули все регионы.
- Другие сервисы, такие как Airflow, Outposts и Support Center, столкнулись с аналогичными сбоями.

AWS извинилась за последствия и предложила решения: отключение/пересмотр автоматизации DNS DynamoDB для устранения состояния гонки; добавление контроля скорости NLB; улучшение тестирования и регулирования EC2; а также текущие проверки для повышения устойчивости и времени восстановления во всех сервисах.

comments

#nokings #humour #politique #gimp

running docker on a raspberry pi

Документация это просто

🔗 Документация это просто

Какой нынче имеется простой способ писать документацию? Чтобы не заморачиваться, и чтобы сразу и HTML вариант и PDF вариант образовывались.

Есть такой метод! Показываю. Ключевые моменты: Pandoc и Tectonic.

Документы пишем в формате Markdown. Выглядит как простой текст, без мудрёных команд. Можно вставлять рисунки, делать таблицы, использовать математические формулы. Вот пример документа:

# Задача

В школьной столовой Петя заметил, что количество котлет на тарелке уменьшается по формуле
$$
K(t) = K_0 - t,
$$
где $K_0$ — начальное число котлет, а $t$ — время в минутах, прошедшее с момента, как Петя сел за стол.

Если у Пети было 5 котлет, то через сколько минут Петя обратится к маме со словами:
*«Мам, а добавки можно?»*

# Таблица умножения

| | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
|---|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
| 1 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 2 | 2 | 4 | 6 | 8 | 10| 12| 14| 16| 18|
| 3 | 3 | 6 | 9 | 12| 15| 18| 21| 24| 27|
| 4 | 4 | 8 | 12| 16| 20| 24| 28| 32| 36|
| 5 | 5 | 10| 15| 20| 25| 30| 35| 40| 45|
| 6 | 6 | 12| 18| 24| 30| 36| 42| 48| 54|
| 7 | 7 | 14| 21| 28| 35| 42| 49| 56| 63|
| 8 | 8 | 16| 24| 32| 40| 48| 56| 64| 72|
| 9 | 9 | 18| 27| 36| 45| 54| 63| 72| 81|

{width=100}

Преобразуем это дело в HTML:

pandoc example.md -o example.html --standalone --mathjax

Получаем:


Аналогичным образом соорудим PDF:

pandoc example.md -o example.pdf --pdf-engine=tectonic --template=template.tex

Сравниваем:


Стиль PDF-документа можно задавать, меняя template.tex. Для HTML тоже есть аналогичный флаг --css=style.css.

comments

labubuntu

Тест 223 карточек microSD

Благодаря Tech Debunker наткнулся на уникальный тест 223 карточек microSD. Некий энтузиаст Мэтт Коул несколько лет подряд покупал карточки на AliExpress и Amazon и проверял их на реальный объем, скорость работы и, главное, выносливость (ресурс). Последнее выявлялось путем цикличной записи 16 секторов, равномерно распределенных по всему пространству каждой карты. Фиксировалось число циклов до появления первого сбоя и далее до моментов, пока 0,1%, 1%, 10%, 25% и 50% секторов становились нечитаемыми.

Для тестов он использовал восемь компьютеров, около 70 картридеров и собственноручно написанные утилиты.
Был сформирован гигантский отчет с десятками диаграмм и финальным рейтингом, складывающимся из скорости работы, реальной емкости и выносливости.

Общая картина по ресурсу
Среднее число циклов перезаписи по всем картам до появления первого сбойного сектора составило 2441, а медианное – 1431. А среднее число циклов до 50% сбойных секторов составило 4870, медианное – 2533. Брендовые карты демонстрировали примерно вдвое лучшие показатели, чем безымянные и фейковые.

Топ 10 карт до $15 из его рейтинга (они же на иллюстрации):

1. Kingston Canvas Go! Plus 64GB
2. PNY PRO Elite Prime 64GB
3. SanDisk Extreme 64GB
4. PNY Premier-X 128GB
5. Delkin Devices HYPERSPEED 128 GB
6. HP microSDXC mx330 64GB
7. Kioxia Exceria G2 64GB
8. Kingston Industrial 8GB
9. Samsung EVO Plus 64GB
10. SanDisk Ultra 128GB

#полезности