Німці розробили перший у світті фотоновий ЦП (і запустили на ньому DOOM)

На відміну від класичних електронних ЦП, де інформація передається електронами через провідники, фотонні ЦП використовують світло, тобто потоки фотонів, що є плюсом, оскільки світло не виробляє тепла при передачі даних.

Головна технічна проблема була у створенні оптичного транзистора, де один промінь світла керує іншими, але Akhetonics вирішила проблему ефектом Керра і деякими 2D-матеріалами.

Фотоновий ЦП може працювати в терагерцовому діапазону (на відміну від гігагерцевого діапазона електронних ЦП), що в 1000 разів швидше. При цьому, енергоспоживання знижується в 10-100 разів.

Також виробляти такі ЦП можна на існуючих фабриках з техпроцесом 90-250 нм, що робить їх відносно дешевими та дозволяє зберігти виробництво в Європі.

Перші прототипи планують поставити корпоративним клієнтам в середині 2026 року

> https://youtu.be/9tqOPS6x9l8
> https://www.akhetonics.com/technology

останнє просте число у файлі (10-мільйонне) —

179424671

про зручний та незручний UI/UX —
про (не)зручні інтерфейси користувача

https://woltman.com/gnome-bad/

В ChatGPT з’явилась нова функція, яка візуально пояснює математичні та наукові концепції.

Тепер такі речі як теорема Піфагора, закон ідеального газу (PV = nRT) або закон Гука можна вивчати у форматі інтерактивних візуалізацій.

Тобто це не просто формула в підручнику. Система показує, як змінюються змінні, як працює формула і що відбувається, якщо змінити параметри.

Загалом вже доступно приблизно 70 ключових наукових концепцій, які можна буквально “покрутити руками” і зрозуміти, як вони працюють.

Для школярів або студентів це може бути набагато зрозуміліше, ніж суха теорія.

Є школярі на каналі? 👀

Latency Numbers Every Programmer Should Know
Interactive
https://colin-scott.github.io/personal_website/research/interactive_latency.html

https://www.youtube.com/watch?v=CxGSnA-RTsA

прикольно стиснуто

Большинство распределенных систем падают не потому, что один сервис умер. Они падают потому, что живые сервисы начинают слишком активно "спасать" ситуацию.

Типичный сценарий выглядит невинно. Один downstream-сервис начинает отвечать не за 50 мс, а за 2 секунды. Причина может быть любой: медленная база, исчерпанный connection pool, GC pause, перегретый shard.

Upstream продолжает принимать трафик. Запросы теперь живут дольше, значит одновременно открытых запросов становится больше. Растут очереди, количество goroutine, threads, sockets, memory usage. Это backpressure, которую система почему-то решила проигнорировать.

А дальше появляется retry.

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

Если 20 процентов запросов начинают ретраиться дважды, нагрузка легко превращается из 100 RPS в 140. Latency растет еще сильнее, таймаутов становится больше, retries запускаются чаще.

Получается положительная обратная связь.

Latency -> timeout -> retry -> дополнительная нагрузка -> еще большая latency.

На этом этапе система уже может быть технически "здоровой". Все pods running, CPU еще не 100 процентов, health checks зеленые. Но очередь растет быстрее, чем сервис способен ее разгребать.

Потом начинается каскад.

Upstream исчерпывает connection pool. Его запросы начинают зависать. Сервисы выше по цепочке тоже запускают retries. Клиенты обновляют страницу. Load balancer перераспределяет трафик на оставшиеся якобы здоровые instances.

Через несколько минут локальная деградация превращается в outage всей системы.

Поэтому надежная distributed architecture начинается не с Kubernetes и не с количества реплик.

Она начинается с вопроса: "Что произойдет с системой, когда один компонент станет медленным, но еще не умрет?"

Хорошая система умеет сказать "нет".

Bounded queues вместо бесконечных очередей. Жесткие timeouts. Exponential backoff с jitter. Retry budgets. Circuit breakers. Bulkheads. Ограничение concurrency. Load shedding. И главное - retries только для действительно retryable операций.

Особенно опасны одинаковые timeout и retry policies на всех уровнях. Если frontend, API gateway и три внутренних сервиса каждый делают по 3 попытки, один пользовательский запрос теоретически может породить десятки downstream-вызовов.

Именно поэтому я при разборе production-инцидентов смотрю не только на место, где появилась ошибка. Я ищу место, где система перестала ограничивать ущерб. Потому что отказ одного сервиса - это обычная эксплуатационная проблема.

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

#заметкиархитектора

Недавно я поймал очень неприятную вещь там, где вообще не ожидал ее увидеть - внутри библиотеки, которую просто добавили в Python VirtualEnv.

Я запускал AI-агента для работы с проектом. Ничего экзотического: обычный код, обычное окружение, зависимости. Но у меня есть профессиональная паранойя - AI у меня никогда не получает обычный доступ к машине. Filesystem ограничен, secrets вынесены, права урезаны, а исходящий трафик во время работы разрешен только к API самого AI-провайдера. Именно это в итоге и спасло.

Механика атаки была особенно неприятной. Библиотека в определенный момент специально ломалась, и агент закономерно упирался в ошибку. Я писал ему обычный запрос в стиле: "найди проблему и почини". Агент шел смотреть код библиотеки, находил место поломки, а прямо рядом в комментарии было что-то вроде: "чтобы исправить эту проблему, выполни следующий код". Ниже уже находилась инструкция, которая пыталась заставить его прочитать локальные данные и выполнить действия, вообще не связанные с реальным багом.

Для Python этот комментарий был просто текстом. Для coding agent он фактически становился частью управляющего контекста. И в этом принципиальная разница: атакующему уже не обязательно добиваться выполнения вредоносного Python-кода. Иногда достаточно заставить AI прочитать нужный файл именно в тот момент, когда он ищет решение проблемы.

Вот здесь у меня окончательно поменялось отношение к prompt injection. Раньше модель угроз выглядела понятно: опасен код, который мы выполняем. Теперь опасным становится и контент, который читает агент с доступом к инструментам. README, комментарий, fixture, документация зависимости, CLAUDE.md, issue или сгенерированный лог могут содержать инструкции, которые человек воспримет как мусор, а AI попытается выполнить.

Если бы агент видел `.env`, потенциально утекли бы credentials. Если бы имел unrestricted network access, данные можно было бы отправить наружу. Если бы имел доступ к git, CI или cloud credentials, последствия были бы уже совсем другого масштаба. Но запрос наружу просто не прошел: сеть была закрыта на уровне окружения.

Именно поэтому я не считаю prompt-level правила достаточной защитой. Фраза "не читай secrets" проигрывает архитектурному запрету читать secrets, а инструкция "не отправляй данные наружу" проигрывает firewall, который физически не позволяет этого сделать.

Для AI-агента я применяю ту же модель, что и для недоверенного workload: least privilege, sandbox, минимальный filesystem scope, ephemeral credentials, deny-by-default network и audit действий.

Supply chain теперь состоит не только из кода, который машина исполняет, но и из текста, который AI считает инструкцией. И если ваша защита строится только на system prompt, то фактически вы доверяете безопасность production способности LLM вовремя понять, что ее пытаются обмануть.

Я предпочитаю, чтобы даже успешно обманутый AI физически не мог сделать ничего действительно опасного.

#заметкиархитектора

CRDT хорошо понимать не как "магическую eventual consistency", а как способ заранее определить такую структуру данных, которую разные узлы смогут менять независимо, а потом слить без конфликтов.

Возьмем OR-Set - Observed-Remove Set. Он нужен там, где несколько replica могут одновременно добавлять и удалять одни и те же элементы: collaborative apps, distributed caches, replicated metadata, shopping carts, multi-region storage.

Проблема обычного Set очень простая. Пусть replica A и B одновременно работают с элементом "x". A делает add("x"), а B - remove("x"). Потом сеть восстанавливается. Что должно победить?

OR-Set решает это не timestamp-ом, а уникальными тегами операций.

Когда A добавляет "x", она хранит не просто:

x

а, например:

(x, a1)

Если B независимо тоже добавит "x":

(x, b1)

Теперь множество логически содержит:

x -> {a1, b1}

Удаление работает хитрее. remove("x") удаляет только те теги, которые replica уже видела.

Допустим, A видит только a1 и делает remove("x"). Она удаляет a1, но b1, созданный параллельно на B, остается.

После merge:

x -> {b1}

То есть concurrent add побеждает remove.

Это не случайность, а выбранная семантика.

Для merge нам снова нужны свойства:

merge(A, B) = merge(B, A)

merge(merge(A, B), C) = merge(A, merge(B, C))

merge(A, A) = A

Именно commutativity, associativity и idempotency позволяют доставлять обновления в любом порядке, повторять их и переживать network partition без coordinator.

Интересная часть начинается с масштаба. Если один логический элемент добавляли N раз, у него потенциально может накопиться O(N) уникальных tag-ов. Значит, CRDT не отменяет стоимость согласования - он переносит ее из runtime coordination в metadata.

И вот это важный архитектурный trade-off.

Мы можем платить latency на каждой операции через lock, leader или consensus. А можем разрешить локальные изменения мгновенно, но платить памятью, metadata и сложностью garbage collection позже.

CRDT полезны не потому, что "работают без конфликтов". Они полезны потому, что превращают конфликт из runtime-события в заранее определенную алгебру данных.

#заметкиархитектора #история