Христос Воскресе 🥚

https://github.com/J-jaeyoung/bad-epoll
https://nvd.nist.gov/vuln/detail/CVE-2026-46242

Линух стабильно доказывает, что если вам важна безопасность, то это не к нему.

И если про предыдущие находки хотя бы можно было сказать, что они касаются только идиотов, которые не занимаются харденингом, то тут уже такое не сработает. Потому что проблема касается буквально всех: epoll – это не act_pedit, загрузку которого можно отключить на 99.9% машин и забыть, потому что он нахуй никому не нужен. epoll – базовый механизм ядра, без которого не работает (почти) вся асинхронная сеть Linux.

Это вам знак, что давно пора переходить на OpenBSD или z/OS.

Очень мого интересных релизов последнее время

https://huggingface.co/unsloth/GLM-5.3-Flash
https://huggingface.co/Qwen/Qwen3.8-Flash-Next
https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-0731

Сейчас будем заниматься тестированием этих моделей ✌️

По GLM-5.3-Flash уже немного есть что сказать:

1. Это микс архитектуры DSV4F + Kimi K3.
2. По KV Cache за счет понятно чьих заслуг все прекрасно.
3. Главный вопрос в данный момент – наличие prefix caching, именно это будет решающим моментом. От этого зависит возможность оффлоада кв кэша в ОЗУ. У Kimi K3, например, на релизе с этим были проблемы.

Что касательно Qwen3.8-Flash-Next:

Выглядит ОЧЕНЬ многообещающе. По бенчмаркам это уровень DeepSeek-V4-Flash-0731, который на уровне GLM-5.2 (а GLM-5.2 > Opus 4.8, если кто забыл) в кодинге, но Qwen3.8-Flash-Next ЗНАЧИТЕЛЬНО компактнее и ключевое тут не в тотал параметрах, а активных – всего 6 миллиардов, тогда как у DSV4F их 13 миллиардов. За счет этого Qwen3.8-Flash-Next будет в РАЗЫ быстрее, но при этом качество должно быть такое же. Это предстоит проверить. Иметь модель для кодинга со скоростью 1000 TPS – давняя моя цель.