Умышленно сократил количество вариантов до минимально возможного. Подобного опроса на ЛОР пока не было. Значит пора провести. Как всегда просто хочу разобраться.
>>> Результаты
Владельцы сайтов, зарабатывающие на конверсии переходов из поисковиков на свои страницы, говорят о значительном снижении трафика.
Поисковые системы, вроде Google, дают ответ на главной странице своего сайта и для простых ответов уже не требуется выполнять переход на сайты-источники.
А как поступаешь ты, $username? Пиши как ищешь в интернете в комментарии. Это помогает нам в продвижении алгоритмами ЛОРа.
PS. Под классическими поисковыми системами понимаю Yandex, DuckDuckGo, Google Search, Yahoo и прочее, а под ИИ-поиском – поиск через интерфейсы ИИ-чатов или с помощью ИИ-агентов.
PPS. Специально не раскрываю известные мне сценарии работы с современным поиском, чтобы не подталкивать отвечать определённым образом.
>>> Результаты
Системы рекомендаций, последнее время, кормят меня прохладными историями из жизни компьютерных сервисов и отзывами клиентов на их работу, я и сам работал в сервисе лет 20 назад, поэтому имею представление о той «сантабарбаре» которая там происходит. А как с ремонтами складываются дела у тебя, $username?
Расскажи свою прохладную об обращении в сервис по ремонту техники, хотя в опросе я имел ввиду микропроцессорную технику, но в качестве «еды» пойдут и истории о бытовой технике, которая часто служит столько, что никто не помнит когда точно её купили.
>>> Результаты
Да просто интересно
Не знаю зачем, но у меня теперь дома, как я намерил, 580Мбит/с соединение с этими вашими интернетами.
Главное стоит это на 10% дороже моих прежних 100Мбит/с.
Было достаточно заказать замену «модема», не знаю почему они его так называют, в общем провайдерское оборудование на территории заказчика.
Теперь Keenetic Giga хоть будет чем-то занят…
PS. Тред заряжен на привлечение клоунов и ненужнистов, а так же обречён быть удалённым.
Всем спасибо.
А у тебя $username, дома что за скорость?
В разрабатываемой Ubuntu 26.10 «Stonking Stingray» завершён переход базовых утилит с GNU Coreutils на написанную на Rust и распространяемую по лицензии MIT реализацию uutils/coreutils. В актуальных release notes Ubuntu 26.10 изменение обозначено как «100% Rust coreutils»: последние остававшиеся GNU-версии cp, mv и rm заменены реализациями uutils 17 августа 2026 года, когда в репозиторий Ubuntu вернули Rust-реализацию cp.
Процесс замены начался 12 марта 2025 года, когда Canonical представила план «Carefully But Purposefully Oxidising Ubuntu». Главной причиной называлось повышение безопасности базовых компонентов: Rust позволяет на этапе компиляции исключать целые классы ошибок управления памятью, характерных для C и C++. При этом Canonical подчёркивала зрелость существующих реализаций — GNU Coreutils не объявлялись устаревшими или небезопасными, речь шла о долгосрочной модернизации Ubuntu.
( читать дальше... )
>>> Источник (ubuntu.com)
Я понял, что играть на телевизоре гораздо веселее и привычнее, например, для жены, а ещё ждал гостей, которые собирались заглянуть ко мне на неделю-другую летом.
Мой Яндекс ТВ едва дружил с Bluetooth. Я с трудом поставил на него Steam Link, но телевизор совсем не хотел тянуть поток больше 30 Мбит/с. Камушек там оказался довольно дохлым: смотреть MKV в устраивающем меня качестве получалось, а вот со стримингом Steam он справлялся плохо.
Менять телевизор не улыбалось, поэтому я стал смотреть в сторону приставок. Долго ли, коротко ли, я набрёл на H96Max: разные ревизии, варианты с 4 и 8 гигабайтами ОЗУ, гигабитный Ethernet. Судя по отзывам, всё работало шустро, а гигабит был вполне честный. Долго читал отзывы на маркетплейсах. Было ощущение, что это лотерея, но я решил рискнуть. Приставки с приятным лейблом на корпусе стоили уже совсем негуманно, а тут выигрыш в цене обещал быть в 2–2,5 раза.
Судя по количеству продаж на маркетплейсах, приставка понравилась не только мне.
Приехала коробочка, которую я сразу запустил. Первый smoke test в Steam Link показал 300 Мбит/с от источника к приставке. Я был счастлив: задуманное удалось.
( читать дальше... )
Перемещено shell-script из ai
Свежая PISA 2025 показала довольно неприятную тенденцию: школьники всё хуже не столько читают как таковые, сколько понимают, сопоставляют и критически оценивают прочитанное. Это крупнейшее исследование PISA за всю историю — около 760 тысяч 15-летних школьников из 91 страны и экономики. По данным OECD, средний результат по чтению в странах организации с 2015 по 2025 год упал на 28 баллов, что соответствует примерно полутора годам обучения. В итоге средний показатель чтения в PISA оказался самым низким за всю историю измерений.
Причём это не результат нескольких особенно неудачных стран. Если сравнивать 2018 и 2025 годы, то снижение читательской грамотности зафиксировано в 56 из 74 стран и экономик, для которых имеются сопоставимые данные; улучшение обнаружилось только в пяти. В 35 странах OECD среднее падение за семь лет составило 25 баллов. Одновременно доля точных и беглых читателей сократилась примерно на семь процентных пунктов, а доля так называемых hasty readers — тех, кто быстро читает задание и столь же быстро отвечает неправильно, — выросла примерно с 7 до 11%. Особенно сильно результаты ухудшались ближе к концу теста, что исследователи связывают со снижением внимания, настойчивости или уверенности при работе со сложными заданиями.
Самое любопытное на фоне распространения LLM — сильнее всего проседают именно навыки, которые должны становиться важнее в эпоху ИИ: отличать факт от мнения, оценивать достоверность информации, сопоставлять источники и разбираться с неоднозначным текстом. Руководитель образовательного направления OECD Андреас Шляйхер отдельно обращает на это внимание в разборе результатов PISA. При этом свести всё к формуле «ChatGPT отупляет школьников» нельзя: падение результатов началось ещё до массового распространения генеративного ИИ и даже до COVID. Сама OECD осторожно предполагает, что свою роль могут играть уменьшение чтения для удовольствия и привычка к цифровому чтению в режиме быстрого пролистывания, но причинно-следственную связь эти данные сами по себе не доказывают.
Исследователи CERT Polska раскрыли шесть уязвимостей в MikroTik RouterOS, две из которых объединяются в цепочку, получившую название MikroTrick. По данным исследователей, цепочка позволяет без аутентификации получить полный административный контроль над маршрутизатором, если его SSH-сервис доступен из недоверенной сети. CERT Polska уже подтвердила эксплуатацию MikroTrick в реальных атаках, наблюдавшихся как минимум со 2 сентября 2026 года.
MikroTik выпустила исправления 3 сентября и обозначила обновление как важное security update. Исправленные версии — RouterOS 6.49.21, 7.23.4, 7.24.2 и 7.25beta3. Производитель рекомендует обновиться всем пользователям, хотя подчёркивает, что большинство стандартных конфигураций непосредственно атаке не подвержено: в конфигурации RouterOS по умолчанию доступ к SSH со стороны интернета блокируется firewall.
( читать дальше... )
>>> Источник (mikrotik.com)
1 сентября исследователи Cyera Research раскрыли подробности уязвимости PostGREShell — CVE-2026-6471, позволявшей пользователю PostgreSQL с привилегией REPLICATION загружать произвольные нативные библиотеки в процесс СУБД. Ошибка появилась вместе с механизмом логического декодирования ещё в PostgreSQL 9.4 и оставалась незамеченной около 12 лет. Само исправление было выпущено раньше — 13 августа в PostgreSQL 18.6, 17.11, 16.15, 15.19 и 14.24.
PostgreSQL оценил CVE-2026-6471 в 7,2 балла CVSS. Согласно официальному описанию, пользователь, не являющийся суперпользователем, но имеющий атрибут REPLICATION, мог через механизм логического декодирования заставить сервер выполнить dlopen() произвольного файла, доступного системной учётной записи PostgreSQL. В результате код из библиотеки выполнялся уже не с SQL-правами атакующего, а непосредственно внутри процесса сервера БД.
( читать дальше... )
>>> Источник (cyera.com)
В LLVM завершён перевод DirectX backend из экспериментального в официальный статус. Соответствующий pull request #214066 был влит в основную ветку llvm-project 31 августа. DirectX перенесён из LLVM_ALL_EXPERIMENTAL_TARGETS в обычный LLVM_ALL_TARGETS, поэтому теперь backend будет собираться по умолчанию вместе с другими штатными целями LLVM.
Ранее для его включения требовалось явно добавлять DirectX через CMake-параметр LLVM_EXPERIMENTAL_TARGETS_TO_BUILD. В принятом изменении DirectX добавлен в стандартный список targets и удалён из экспериментального.
Речь идёт не о реализации Direct3D или графическом драйвере. DirectX backend преобразует LLVM IR в DXIL — DirectX Intermediate Language, используемый DirectX 12 для представления скомпилированных шейдеров. Согласно документации LLVM, DXIL основан на bitcode старого LLVM 3.7, дополненного специфичными для DirectX операциями, ограничениями и метаданными. Результат помещается в контейнер DXContainer, содержащий DXIL и дополнительную информацию о шейдере.
( читать дальше... )
>>> Источник (github.com)
В составе ежедневных сборок Ubuntu 26.10 «Stonking Stingray» появился отдельный установочный образ, собранный для процессоров уровня x86-64-v3 (amd64v3). В официальном каталоге Canonical Ubuntu 26.10 Daily Build первый stonking-desktop-amd64v3.iso датирован 4 сентября, а 7 сентября на появление нового варианта обратил внимание Phoronix. Обычный образ amd64 продолжает выпускаться параллельно, поэтому поддержки более старых x86-64-процессоров Ubuntu пока не лишается.
x86-64-v3 — более высокий базовый уровень архитектуры AMD64. Для нового ISO Canonical прямо указывает необходимость поддержки AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE и XSAVE — требования можно увидеть непосредственно на странице образов Ubuntu 26.10. В практическом смысле это примерно поколение Intel Haswell и более новое оборудование соответствующего уровня AMD. Компиляция с расчётом на v3 позволяет программам использовать современные инструкции без необходимости сохранять код, пригодный для запуска на самых ранних x86-64-процессорах.
Эксперименты Canonical начались не с нынешнего ISO. Ещё в Ubuntu 25.10 разработчики представили механизм architecture variants: после изменений в dpkg, APT и Launchpad один и тот же пакет может собираться в нескольких вариантах для разных уровней x86-64. Для 25.10 оптимизированные amd64v3-версии были доступны примерно для 2000 исходных пакетов из main и включались пользователем через настройку APT. По внутренним тестам Canonical, полный rebuild под x86-64-v3 давал для большинства пакетов небольшой выигрыш порядка 1%, но некоторые вычислительные задачи ускорялись заметнее.
( читать дальше... )
>>> Источник (ubuntu.com)
6 сентября разработчики Asahi Linux объявили о начале официальной поддержки компьютеров Mac на процессорах Apple M3. Поддержка M3, M3 Pro и M3 Max добавлена непосредственно в установщик проекта. По словам разработчиков, Linux на этих системах уже достиг состояния, при котором значительная часть оборудования, ранее поддержанного на машинах с M1 и M2, работает и на M3.
На поддерживаемых Mac уже работают Wi-Fi, Bluetooth, NVMe, клавиатура и тачпад, встроенные микрофоны и веб-камера, управление частотами CPU и распределение задач между производительными и энергоэффективными ядрами. Также поддерживается USB 3 со скоростью до 10 Гбит/с. В ходе подготовки M3 разработчикам пришлось, в частности, реализовать поддержку нового контроллера USB Type-C ACE3, используемого в M3 Pro и M3 Max.
( читать дальше... )
>>> Источник (asahilinux.org)
Привет, $username!
Хотел рассказать о своём проекте OpenShield. OpenShield – это фарвол для Linux с контролем сетевой активности отдельных приложений, написанный на Rust. Для управления используется терминальный интерфейс, а фильтрацией пакетов занимается nftables с возможностью переключения на iptables. В режиме обучения программа пропускает исходящий трафик и автоматически создаёт разрешающие правила. Затем можно перейти в режим Enforcing: соединения, для которых нет разрешающего правила, будут блокироваться. Правила можно привязывать к cgroup, пути исполняемого файла и параметрам запуска, дополняя ограничениями по адресам, портам и протоколам. Поддерживаются действия accept, drop и reject, а также временное отключение правил без их удаления.
Идея создать свой аналог OpenSnitch появилась довольно давно, но не было окончательного видения проекта. Когда я понял что должно получиться, закипела работа.
Я написал на GitHub, что OpenShield является форком opensnitch, наверное это не совсем так, поскольку заимствована лишь идея, а код написан заново, отличаются механизмы работы и задачи приложения. Поэтому точнее было бы назвать OpenShield самостоятельной реализацией, вдохновлённой OpenSnitch. В OpenSnitch заметный акцент сделан на интерактивном контроле исходящих соединений через графический интерфейс; также есть управление системным фаерволом и несколькими узлами. В OpenShield я делаю упор на локальную политику защиты хоста и работу через терминал, в том числе на серверах без графического окружения. Основной сценарий — собрать правила в режиме обучения, проверить их и перейти к фильтрации по явно разрешённым соединениям.
Отдельное внимание уделяется поведению при ошибках. В режиме Enforcing невозможность достоверно определить приложение не должна превращаться в разрешение трафика: неоднозначная атрибуция приводит к блокировке соответствующего пакета. При критических сбоях предусмотрен аварийный режим BlockAll. Изменять правила и режим работы может только root, а наблюдение доступно участникам группы openshield. Управление и мониторинг разделены между локальными Unix-сокетами с проверкой учётных данных клиента; сетевого управляющего API нет.
Демон и TUI написаны на Rust, в собственном коде запрещён unsafe. Дополнительно ограничены размеры сообщений, очереди и время обработки запросов, предусмотрены проверки сохранённого состояния и тесты поведения при перегрузке. Это не обещание отсутствия уязвимостей и не утверждение, что OpenSnitch небезопасен, а описание выбранных инженерных приоритетов. Обучение тоже не определяет, заслуживает ли приложение доверия: оно лишь фиксирует наблюдавшуюся активность, поэтому полученные разрешения необходимо проверять перед включением Enforcing.
Довольно продолжительное время было уделено производительности приложения, однако она пока остаётся слабым местом при большом количестве коротких соединений и интенсивном исходящем UDP-трафике, особенно состоящем из множества небольших пакетов. Здесь важнее не столько объём переданных данных, сколько количество пакетов и новых соединений, для которых требуется определить приложение.
Это связано со стоимостью проверки правил, привязанных к приложениям. Обычные сетевые правила — адреса, порты, протоколы и интерфейсы — обрабатываются непосредственно ядром через nftables или iptables. Если же решение требует проверки приложения, пакет передаётся демону через NFQUEUE. Демон устанавливает владельца сокета, проверяет идентичность процесса и сопоставляет её с условиями правила: путём исполняемого файла, cgroup, аргументами запуска и другими заданными признаками. Такая проверка существенно дороже сравнения адреса и порта.
Для TCP предусмотрено ускорение: после авторизации соединения его established-трафик может обрабатываться в ядре через conntrack с проверкой поколения политики. Поэтому длительное разрешённое TCP-соединение обычно обходится дешевле постоянного открытия новых. Для UDP, не разрешённого отдельным сетевым правилом, проверка приложения повторяется для каждого пакета, требующего прикладного решения. Именно этот сценарий особенно чувствителен к PPS: даже небольшой по мегабитам поток способен заметно загрузить демон и увеличить задержки. Используемые кеши ускоряют поиск владельца, но не заменяют проверку актуальности его идентичности безусловным повторным разрешением.
Я представляю первую публичную версию, где представлен основной набор функций приложения, над производительность ещё предстоит работать. В OpenSnitch механизм проверок проще, поэтому его работа не даёт подобной нагрузки на систему, возможно схожий режим появится и в OpenShield.
Приложение собирается для Debian 12 и 13, Ubuntu 22.04, 24.04 и 26.04, Fedora 43 и 44, AlmaLinux 9 и 10, Rocky Linux 9 и 10, openSUSE Leap 16.0, openSUSE Tumbleweed, Alpine Linux 3.23 и 3.24, а также Arch Linux. В зависимости от дистрибутива предусмотрены пакеты для x86_64 (amd64), 32-разрядного x86 (i586/i686), ARMv5, ARMv6, ARMv7, ARM64 (aarch64), PowerPC 64 LE (ppc64le), IBM Z (s390x) и RISC-V 64 (riscv64). Это общий перечень архитектур: не каждая комбинация дистрибутива и архитектуры входит в матрицу сборки.
Предрелизные проверки установки пакетов и функциональные тесты фаервола выполняются:
Всего получается 37 комбинаций дистрибутива и архитектуры. Для каждой проверяются nftables и резервный iptables, включая обучение, переход в Enforcing и применение правил. Отдельный performance gate запускается на openSUSE Tumbleweed x86_64.
Для остальных архитектур пока выполняются сборка, проверка формата исполняемых файлов и пробный запуск --version; полноценного тестирования установки и фильтрации трафика на них нет. Контейнерные проверки также не означают проверку собственного ядра каждого дистрибутива.
Скачать и попробовать приложение можно по последнему актуальному тегу v0.2.4
Сильно не пинайте, буду благодарен за любые отзывы и комментарии.
Спасибо, что дочитали до конца.
5 сентября стало известно о новом направлении AMD по использованию Rust в низкоуровневом программном стеке графических процессоров. Сотрудник AMD Харш Менон (Harsh Menon) сообщил о формировании небольшой специализированной команды, задача которой — «push Rust deep into the GPU stack». В качестве направлений он перечислил компиляторы, runtime, firmware, архитектуру GPU и совместное проектирование аппаратного и программного обеспечения.
Объявление подтверждается опубликованной самой AMD вакансией Software Development Engineer — Rust, Compilers, and GPU Systems. В ней компания прямо называет Rust «core technical direction» при разработке системного ПО следующего поколения для GPU. Работы должны охватить компиляторы, runtime, низкоуровневое ПО GPU, прошивки и средства разработки. AMD отдельно подчёркивает: «Rust is not incidental to this role» — язык рассматривается не как вспомогательный инструмент для отдельных утилит.
( читать дальше... )
>>> Источник (amd.com)
Сегодня попалась новость, что Bodycam, которую видел в анонсах уже даже не помню когда, года 2 назад, набрала 38 тысяч игроков в пике.
Я не люблю сетевые шутеры, надеюсь авторы заработают на первой части, вторую выпустят уже как ААА шутер с возможностью сражений на серверах против живых игроков, а любителям сюжетных кампаний покажут «страсти-мордасти» не хуже чего-нибудь первоклассного.
Графоний — положили с горкой. Но тут интереснее не столько количество полигонов, сколько сама механика: обычного HUD, перекрестия и даже счётчика патронов нет, оружие не «приклеено» к центру камеры, а руки, тело и ствол двигаются относительно друг друга. Поэтому первые минут двадцать приходится буквально учиться заново целиться и ходить. Звук тоже играет почти такую же роль, как картинка — шаги, выстрелы и положение противника по этажам действительно приходится слушать.
Игра всё ещё выглядит, как будто бы, как техническое demo, командная схватка иногда скатывается в довольно аркадное месиво, не смотря на подчёркнуто реалистичные механики. В голосовом эфире, во время игры, многие общаются на русском.
Важно, что поддержка Linux не заявлена, но она есть, поэтому, наверное, я и пишу этот текст. Запущено под openSUSE Tumbleweed. Железо и конфигурация те же, что в прошлый раз.
30 августа на MiniDebConf Winterthur 2026 инженеры CERN Федерико Вага и Никос Ципинакис представили доклад «Controlling CERN’s Accelerators with Debian», посвящённый переводу компьютеров системы управления ускорительным комплексом с дистрибутивов семейства Red Hat на Debian. Согласно опубликованным CERN материалам, до конца 2026 года Debian 13 должен быть установлен более чем на 2200 промышленных компьютерах и встраиваемых системах. 1 сентября это отдельно подтвердила Debian Publicity Team.
При этом речь не идёт о полном отказе CERN от RHEL или AlmaLinux. В начале презентации авторы специально вынесли на отдельные слайды фразы «WE WILL NOT TALK ABOUT DATA CENTERS» и «WE WILL NOT TALK ABOUT EXPERIMENTS»: миграция касается прежде всего Front-End Computers (FEC), непосредственно управляющих оборудованием ускорителей. В документации Linux @ CERN RHEL и AlmaLinux по-прежнему перечислены среди поддерживаемых систем, а для AlmaLinux 9 и 10 продолжает поддерживаться интеграция с инфраструктурой CERN. Таким образом, заголовки о полном «прощании с Red Hat и IBM» несколько преувеличивают масштаб изменений.
( читать дальше... )
>>> Источник (debconf.org)
Пока Хуанг доказывает, что DLSS5 будущее игростроя, а остальные кидаются в него помидорами, мне тут подумалось вот что.
DLSS5 просаживает производительность даже RTX5090, проявляется это в снижении FPS, мне попадались сообщения, что от ~100 кадров, в некоторых играх остаётся ~25.
Картинка становится дёрганой, теряется плавность, приличные доны в такое играть не будут.
И вот это всё навело меня на мысль, может же ИИшечка научится рисовать кадры так, как они выглядят на киноплёнке. То есть экспозиция в ~1/25 приводит к размытию динамичных объектов на проявленном кадре, а статичные объекты выглядят чёткими.
Так вот кино использует 24 кадра примерно 50 лет, и картинка там всегда выглядит плавной.
Чтобы получить Cinema-эффект нужно научить нейронку изображать этот эффект на лету. Можно применять этот эффект как к большему, так и к меньшему числу кадров. То есть никто не заставляет использовать 24 кадра, можно и 60, и 120. Тогда исходить что выдержка будет 1/60, 1/120 и так далее.
Тогда будет хватать меньшего числа кадров, а картинка будет выглядеть более естественной.
PS. Тред заряжен на привлечение клоунов и ненужнистов:)
| следующие → |