Вот тут ИИ нашёл решение до сих пор нерешенной проблемы из области дискретной геометрии: гипотезы Эрдёша (номер 90) (комментарий) VIT заявляет, что существуют полноценные квантовые компы на 700 кубитов, и что 2048-битные модули уже умеют факторизовать (что означает что большинство современных RSA, который повсеместно 2048-битные, можно считать взломанными). Выглядит несколько странно, если это действительно так но по всему миру до сих пор не поднялось много шума об этом.

greenman и LightDiver там, как и я, интересовались подробностями.

Сообщение VIT оттуда про 700 кубитный проц Интел:

Продемонстрировала в декабре 2025 года. Вы об этом не знаете, но мнение имеете и выражать его не стесняетесь. Результаты отличные, как вам может быть известно, это сподвигло US Department of Commerce сделать несколько громких заявлений на прошлой неделе.

и ещё сообщение

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

Запускаю раст-сборку одной штуки, она на компиляции какого-то пакета устраивает SIGILL.

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

1) Как узнать точнее где он крашится? В dmesg только ip, туда можно как-то инструкцию вывести? coredump он не создаёт, команда ulimit -c unlimited перед сборкой не помогла.

2) Как расту глобально подсунуть требование не использовать новомодные инструкции?

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

SIGILL в бинарниках с названием build-script-build, судя по датам перд этим скопилированных.

www.linux.org.ru/forum/general/18298017 это не спам, это иностранец хотел обсудить red5 (опенсорсный видеостриминговый сервер, довольно старый) если и удалять то за 4.8

Я всегда думал что его там нет - ни ** ни pow() не работают, и считал его как e(l(x)*y). Сейчас заглянул в ман чтобы посмотреть как там определить кастомную функцию (чтобы задать pow в каком-нить конфиге), и случайно наткнулся на список арифметических операторов, где значком, обычно использующимся для XOR (^), оказывается обозначается возведение в степень. Правда, только в целочисленную, но в большинстве случаев другого и не надо.

Вскоре после обнаружения 18-летнего потенциального RCE было обнаружено ещё одно, CVE-2026-9256, на этот раз просуществовавшее ещё дольше — 21 год, начиная с версии 0.1.17, выпущенной в начале 2005 года. Для эксплуатации уязвимости требуется наличие в конфиге сервера директивы rewrite, у которой:

• в первом аргументе имеются перекрывающиеся выделяемые параметры регулярного выражения,
• во втором используется два или больше из них, но не используются переменные,
• при этом либо указан тип «redirect», либо параметры во втором аргументе находятся после знака вопроса.

( читать дальше... )

>>> Официальное объявление F5 (f5.com)

20 мая 2026 года разработчики FreeBSD объявили об исправлении семи новых уязвимостей в системе. Не все они одинаково опасны, но есть и крайне неприятные.

( читать дальше... )

>>> FreeBSD Security Advisories (freebsd.org)

13 мая была исправлена уязвимость в популярном для нагруженных систем веб-сервере nginx: CVE-2026-42945, потенциально могущая привести к RCE. Уязвимость появилась 18 лет (2008 год) назад в версии 0.6.27.

( читать дальше... )

Информация об уязвимости была предоставлена Zhenpeng (Leo) Lin из DepthFirst. Кроме того, он же сообщил о следующих проблемах, которые тоже исправлены:

• CVE-2026-40701 (коммит) use-after-free при использовании ssl_verify_client+ssl_ocsp (вроде бы без RCE)
• CVE-2026-42934 (коммит) чтение за пределами буфера в utf-8 парсере при специфических обстоятельствах, может привести к небольшой утечке данных или крашу рабочего процесса
• CVE-2026-42946 (коммит) чрезмерное выделение памяти и чтение за пределами буфера при использовании модулей scgi/uwsgi, проблема проявляется при наличии злонамеренного бекэнда (upstream) через указанные протоколы, либо при mitm канала общения с бекэндом, может привести к чтению памяти nginx или крашу рабочего процесса

>>> Официальное объявление F5 (f5.com)

Во-первых, оцените контакты на нижней стороне платы: картинка

Во-вторых, я заметил что на верхней контактные площадки тоже есть: картинка - зачем они нужны?

А ещё если их (речь про первые) залудить станет лучше или хуже?

Запускаю железку, попадаю в recovery mode, /boot не смонтировалось.

Написал mount -a - смонтировалось успешно, выхожу из recovery и всё грузится дальше и работает. Ребутать для проверок больше нельзя.

В journalctl -b было такое

systemd[1]: Mounting /boot...
systemd[1]: boot.mount mount process exited, code=exited status=32
systemd[1]: Failed to mount /boot.
systemd[1]: Unit boot.mount entered failed state

Прописано в fstab через UUID. Файловая система xfs. boot на том же устройстве что и /, при этом / разумеется ещё раньше смонтирован успешно, то есть устройство не могло к тому времени ещё не найтись ядром. В dmesg ничего про это не написано, только лог успешного монтирования из моего mount -a.

Что ему не понравилось и куда системг спрятал лог неудавшегося mount-а при старте?

«i/o error» на любые действия, после перетыкания в слот есть небольшое время когда можно запустить smartctl, затем опять отваливается.

=== START OF INFORMATION SECTION ===
Device Model:     SATAFIRM   S11

  9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       271978

271978 - враньё, разумеется.

Понятное дело, что у него что-то слетело и чинить его нецелесообразно, но в чём причины могут быть? Это признак того что он поддельный или просто неудача? Стоял практически без нагрузки с момента покупки - занято меньше 10гб из 120, запись наверно меньше мегабайта в день (а может и вообще около нуля), чтение тоже не особо большое.

Допустим, я добавлю в свою пермиссивную лицензию пункт о запрете скармливания кода LLM-обучателям (включая косвенное скармливание путём отправки кода туда, где это с большой вероятностью будет сделано автоматически). Какие негативные последствия для продукта от этого могут случиться?

Обсуждения того, что бессовестные llm-щики на всё это наплюют и всё равно украдут код в свои бредогенераторы, прошу тут не устраивать, вопрос не про это.

Уже который раз из-за рандомной фразы начинается дискуссия, которая оффтоп к обсуждаемой теме, но тем не менее вполне заслуживает быть обсуждённой в техническом разделе. Выходим дилемма или нарушать правила оффтопом или отказываться от обсуждения, оба варианта не особо приятные. Почему бы не сделать вынос ветки в новую тему?

Тема black, старый вид.

Были у меня в директории рядом с исходниками, внутри рута рабочей копии vcs, несколько скриптов тестов. Часть из них использовала внешние (по отношению к репе) данные, и поэтому я их пока не коммитил (внёс в игнор-лист), думая что закоммичу когда решу вопрос с нормальным хранением данных для них. А только что мне пришлось там же рядом, в директории с тестами (она не вся в игноре), откатить локальное изменение, и я сделал revert на всю tests/. Но в revert был баг - оно игнорировало списки игнора и откатило tests/ к состоянию репы, по факту сделав rm -Rf на всё что было заигнорировано :(

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

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

Кто с какими сталкивался (без археологии)? Какой из современно используемого софта можно под них скомпилировать чтобы он работал, без кучи костылей? Речь про системы, которые можно представить в виде чего-то компьютеро-подобного, например пытаться запустить на них, например, хотя бы обычное /bin/cat.

Напомню, Си формально не требует 8-битных байтов. А следовательно, используя всякие int8 int16 итд - рискуем получить слом совместимости с системами, где байты например 7-битные или 10-битные (там таких типов получается не будет). Стало интересно, насколько это актуально, или можно с чистой совестью продолжать забивать на это, как я всегда делал.

Я, конечно, понимаю, что такие системы, даже если существуют, очень редки. Вопрос в том, насколько они «очень редки» или же их сейчас вообще ровно ноль.

В очередной раз увидел эту штуку в мане к procfs. Возник вопрос - почему везде дефолт 0? Это же дыра для всяческих утечек. От 1 или 2 что-то может сломаться? В фрибсд всегда настраивал сокрытие чужих процессов, и даже инсталлятор там предлагает это сделать (с некоторых пор). В линуксе же кроме абзаца в мане нигде почти не упоминается, как будто не принято.

Система FreeBSD.

Ситуация такая: входящие пакеты собираются сетевухой LRO в один большой tcp-сегмент. Дальше оно должно роутиться на другой интерфейс, в него такой большой пакет не влезает. Даже если послать назад icmp ошибку, исходный хост же не виноват в ситуации и исправить ничего не сможет. TSO на втором интерфейсе нет.

Очевидное решение - отключить LRO, но есть и нетранзитные соединения (их даже большинство), где он полезен. Какие у кого есть мысли по этому поводу?

Способов нарезать назад большой tcp-сегмент на маленькие же нет? (речь не про ip фрагментацию а перепаковать именно tcp)

Это же очень важное событие для линукса, как её можно удалять?

Заметил такую штуку. Если на входящий («in») пакет сделать fwd для смены ему next-hop (старый next-hop был локалхостом в связи с тем что dst ip локальный, новый - внешний), то при последующем проходе правил на выходе для исходящего («out») пакета интерфейсом отправки всё равно значится «lo0». Т.е. пакет можно файрволить правилом с «out xmit lo0», однако на самом деле он шлётся по указанному в первом проходе файрволла next-hop-у через соответствующий ему интерфейс.

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

Меня время от времени обзывают луддитом в связи с моим осуждением некоторых современных модных ИТ-штук.

Извиняюсь за внешнюю ссылку, но нашёл интересную статью про данную тему.

Ъ:

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

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

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