Всякие нехорошие сайты пытаются управлять позицией прокрутки страницы, чем весьма раздражают. Можно ли запретить им доступ к этому?

Перетыкая VGA-кабель случайно приподнял видеокарту, в которую он воткнут, от материнки, и она перестала показывать картинку на монитор даже после того как я восстановил её положение в слоте. Сервер при этом работает как и раньше, проблема только с видео.

Видеокарта PCI (вроде S3 Trio какое-то, не помню), вылезли из слота те контакты которые ближе к задней стенки (передняя часть прижата к материнке конструкцией корпуса, а вот сзади должен был быть болт но его нет).

Можно ли как-то переинициализировать видеокарту не ребутая комп целиком? ОС FreeBSD, набирать что-то можно только вслепую т.к. сетевого доступа к руту нет.

upd: Таки ребутнул - лучше сейчас планово чем возиться потом когда срочно консоль потребуется. Видео ожило. В практическом плане проблема решена, но вопрос «как починить без ребута» так и не отвечен, так что пусть тема не будет помечена решённой.

Хочется кардинально защитить свой комп с линуксом от возможных повреждений из-за некорректного напряжения питания. (а то недавно один лоровец писал что с ним это случилось) Знаю, в бесперебойниках бывает защита от такого, но она там вида «отключим реле когда заметили плохое», при этом у неё очевидно есть задержка реакции или этот выключатель просто может сломаться от того, что ему самому подали плохое питание.

Если допустим предположить, что в розетке окажется 1000В (или 10000В) вместо 220, каким способом можно сделать так, чтобы допустим ничего выше 350В (это примерно амплитуда бытовой 220В сети + ещё чуть-чуть) до оборудования гарантированно не дошло даже на короткое мгновение (а на длинное - не дошло ничего кроме нормальной 220В синусоиды)?

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

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

Что ещё можно предложить? А так же, есть ли какая-то общепринятая практика и готовые решения по тому что написал я?

Заметил в соседней теме.

Если написать вот так 🤡 🚮

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

Возможно, курсивный их вид более правильный, хотя раньше я на эту тему не думал.

В дебиане если запущен screen то он включает «полноэкранный» режим в терминале, тот же самый в котором работает mc, без терминального скроллбака, а если сделать detach то содержимое исчезает и возвращаемся в тот вид консоли который был до запуска screen. В фрибсд же поведение другое: скроллбак остаётся как был, и при выходе в консоли остаётся содержимое screen перед выходом. Я почти уверен что это просто разные дефолты и где-то настраивается (без перекомпиляции), где?

TL;DR: Столкнувшись с третьим обнаруженным за 2026 год переполнением буфера (и, по версии F5, RCE если нет ASLR) при работе с регэкспами и переменными, разработчик freenginx Максим Дунин решил, что пора это прекращать, и добавил в свой продукт проверку размера переменной перед тем как записывать в неё данные. Оттуда это нововведение утащили к себе и nginx, что даёт надежду на прекращение новых CVE на эту тему.

Теперь подробности.

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

Уязвимость появилась в версии nginx 0.9.6, исправления попали в версии freenginx 1.31.3, nginx 1.30.4, nginx 1.31.3.

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

>>> Коммит (freenginx.org)

Коммит: https://cgit.freebsd.org/src/commit/?id=e2585687890e

(описание проблемы к которой там были assert-ы)

Replace the assertions with runtime checks.

Репорт: https://www.freebsd.org/security/advisories/FreeBSD-SA-26:54.sysvsem.asc

III. Impact

An unprivileged local user can trigger out-of-bounds reads and writes on
kernel heap memory, potentially leading to privilege escalation.

Я правильно понимаю что тут через испорченный телефон «заменим ассерты на нормальные проверки, чтобы убрать возможность kernel panic» превратилось в «уязвимость позволяет манипулировать памятью ядра и повышать привилегии»?

Раньше работало, теперь нет. Пример: я отредактировал комментарий, жму кнопку, он начинает отправляться, и тут я замечаю опечатку. Нажимаю esc (отмена текущего запроса), исправляю её, жму кнопку опять. Некоторое время назад это перестало работать (кнопка отправки второй раз не нажимается). Зачем там вообще какая-то спец. логика? Это же обычная post-форма. А с этим нововведением приходится нажимать f5 чтобы перезагрузить форму редактирования, что при плохом инете может занять весьма некомфортное время.

Почему она так называется? Никакого «time of day» (часы:минуты:секунды) она очевидно не отдаёт.

Перемещено hobbit из talks

Недавно обнаружил, что в FreeBSD 14 убрали portsnap из базовой системы. Рекомендуют пользоваться гитом из пакетов для скачивания портов, а ещё есть portsnap в тех же пакетах. Ещё есть всякие костыли чтобы скачать тарболл портов вручную, разумеется без автоматической проверки контрольной суммы или подписи. Что это за вредительство то?

После какого-то действия (нажимал кнопки) заметил что залипло Super. В итоге почти ничего нельзя было сделать т.к. она часть хоткеев WM, зато можно было двигать окна итд т.к. это на неё забиндено. Переключится ctrl-alt-f1 (сработало) и в консоли не набираются буквы (если их набирать с зажатым Super они действительно не набираются). Переключился назад в иксы - работа клавиатуры пришла в норму, запустил xev там тоже всё как положено, следов проблемы вроде как нет. Переключаюсь в консоль - буквы всё ещё не набираются (хорошо что alt-Fn назад в иксы работает). Консоль починилась после ухода в pm-suspend и пробуждения назад, и теперь вроде всё хорошо.

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

Debian 11, ядро 5.10. В dmesg и в логах иксов на момент проблемы пусто. Что это было? И как это можно по-лучше было диагностировать? Или может и сейчас что-то проверить можно, вдруг проблема не исчезла а только спряталась?

30 июня 2026 года были опубликованы уведомления об исправлении 13 новых уязвимостей в ОС FreeBSD.

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

>>> FreeBSD Security Advisories (freebsd.org)

systemd в очередной раз мне тайком нагадил

Jun 30 01:07:59 nb2 systemd-timesyncd[595]: Initial synchronization to time server 92.255.126.4:123 (0.debian.pool.ntp.org)

Начались такие сообщения примерно неделю назад, при этом разумеется я этот timesyncd не трогал и даже не знал что он у меня установлен. Впрочем, сам timesyncd, как оказалось, был и раньше - первое упоминание его в логе в августе 2025, при том что лог начинается с февраля 2025, но время он мне тайком не портил и я его не замечал.

Собственно, почему такое произошло и как его отключить чтобы он потом назад опять не включился?

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

systemd-timesyncd оказался отдельным пакетом, так что apt-get purge позволил даже не лазить по конфигам systemd для его отключения. Однако вопрос «почему он годами молчал а теперь начал активно синхронизировать время» - всё равно актуален.

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

00000000000016b9 <.bL11>:
    16b9:       48 8b 04 ce             mov    rax,QWORD PTR [rsi+rcx*8]
    16bd:       48 19 04 cf             sbb    QWORD PTR [rdi+rcx*8],rax
    16c1:       48 ff c1                inc    rcx
    16c4:       75 f3                   jne    16b9 <.bL11>
    16c6:       48 83 1f 00             sbb    QWORD PTR [rdi],0x0

00000000000016ba <.bL11>:
    16ba:       48 8b 04 ce             mov    rax,QWORD PTR [rsi+rcx*8]
    16be:       48 19 04 cf             sbb    QWORD PTR [rdi+rcx*8],rax
    16c2:       48 ff c1                inc    rcx
    16c5:       75 f3                   jne    16ba <.bL11>
    16c7:       48 83 1f 00             sbb    QWORD PTR [rdi],0x0

00000000000016c5 <.bL11>:
    16c5:       48 8b 04 ce             mov    rax,QWORD PTR [rsi+rcx*8]
    16c9:       48 19 04 cf             sbb    QWORD PTR [rdi+rcx*8],rax
    16cd:       48 ff c1                inc    rcx
    16d0:       75 f3                   jne    16c5 <.bL11>
    16d2:       48 83 1f 00             sbb    QWORD PTR [rdi],0x0

Собственно, если отметить первый лагающий вариант (где .bL11=0x16BA) за точку отсчёта, то итоги такие:

-7..-1 - хорошая скорость
0..11 - замедление на 30-35%
12..15 - хорошая скорость
16..23 - замедление на 15-20%
24..31 - хорошая скорость
32..32+11 - замедление на 30-35%
32+12..32+31 - хорошая скорость

Ещё я проверил что будет если вставлять NOP-ы внутрь цикла. Так вот, добавление например 2 NOP-ов приводит к тому, что лаги начинаются на 2 байта раньше (т.е. при той же позиции JNE как и раньше начинались), а вот заканчиваются на том же месте как раньше, т.е. при той же позиции метки (т.е. лаги от -2 до 11). Вторая зона лагов стала какой-то размазанной с усилившимся пиком в самом начале, а так же она появилась таки во втором цикле на 32+16-2.

сдвиг   время выполнения бенчмарка
-6       511.9 +- 14.8
-5       515.2 +- 12.3
-4       511.6 +- 8.9
-3       507.3 +- 7.2
-2       683.0 +- 9.2    <-- первый круг
-1       672.1 +- 12.3
0        670.5 +- 8.6
1        674.8 +- 17.1
2        669.4 +- 7.4
3        672.5 +- 11.0
4        675.0 +- 9.1
5        669.9 +- 8.9
6        675.5 +- 8.8
7        679.1 +- 7.6
8        696.9 +- 23.6
9        691.6 +- 14.8
10       680.5 +- 9.5
11       684.0 +- 9.0
12       516.5 +- 7.9
13       517.2 +- 11.6
14       792.3 +- 36.8   <--
15       605.4 +- 37.5
16       575.8 +- 24.2
17       566.0 +- 16.0
18       555.8 +- 21.6
19       562.0 +- 14.5
20       555.7 +- 8.7
21       537.2 +- 10.7
22       534.4 +- 11.2
23       549.9 +- 14.6
24       522.1 +- 10.6
25       517.8 +- 9.5
26       515.5 +- 8.4
27       517.0 +- 4.2
28       512.2 +- 7.4
29       516.8 +- 8.6
30       680.3 +- 9.2  <-- второй круг
31       675.0 +- 19.7
32       671.7 +- 8.9
33       669.2 +- 9.1
34       668.3 +- 10.8
35       667.0 +- 9.6
36       669.0 +- 8.9
37       671.0 +- 9.5
38       670.6 +- 10.8
39       676.5 +- 10.1
40       681.0 +- 10.5
41       682.1 +- 12.7
42       693.5 +- 16.7
43       689.8 +- 13.5
44       512.5 +- 4.9
45       516.9 +- 7.1
46       685.5 +- 12.3   <--
47       515.2 +- 7.6
48       519.0 +- 8.7
49       513.2 +- 7.9
50       512.4 +- 6.2
51       510.8 +- 4.7
52       510.3 +- 7.3
53       507.4 +- 7.0
54       509.2 +- 6.9

Вообще мне казалось что для более быстрой работы кода надо выравнивать начала циклов по 16-байтным границам, но тут ничего подобного незаметно, все адреса не пойми какие. Есть замеченная закономерность: когда JNE доползает до адреса 0x16c5 - лаги начинаются, когда до него доползает и начало цикла - заканчиваются. Но JNE двухбайтовый, т.е. когда он на 0x16c4 то второй его байт на 0x16c5 и лагов ещё нет.

Есть ли шанс объяснить почему так? А то мне совсем не нравится что код рандомно теряет треть скорости на ровном месте, тут я заметил, где-то не замечу, да и на разных процах это может быть по-разному, что делать?

---------------

Почти итог: адреса в дампах выше считал от начала объектного модуля, оказывается модуль автоматически (если явно не указать) по 16-байт границе не выравнивается, и адреса в бинарнике уплыли. Реальное замедление получается если тело цикла пересекает 32-байт границу (кроме случая когда за неё вылезает только один байт последней инструкции, почему-то), выглядит логично.

https://www.freebsd.org/security/advisories/FreeBSD-SA-26:26.ktls.asc

Механизм аналогичный линуксовому copyfail.

Но переживать особо не стоит - баг в ktls, который выключен по-дефолту (sysctl kern.ipc.tls.enable=0).

Баг в KTLS, при этом KTLS включён по умолчанию начиная с релиза 15.0, в более ранних - выключен и можно не переживать. Проверить тут: sysctl kern.ipc.tls.enable.

Для новости слишком поздно - объявили 9 июня.

Перехожу по ссылке из поиска куда-то, а там

Ошибка при установлении защищённого соединения

ищу где кнопка добавления исключений, но её почему-то нет. Читаю внимательнее что написано

При соединении с otvet.mail.ru произошла ошибка. Сертификат узла был отозван.
Код ошибки: SEC_ERROR_REVOKED_CERTIFICATE

Вобщем, там GlobalSign и он отозван. На главной у них выпущеный сегодня утром сертификат от какого-то греческого CA, а в других местах видимо забыли переделать.

Почитал, оказалось что GlobalSign запланировал отзыв сертификатов и вообще всех российских клиентов. А чего новости на лоре не было или даже темы в толксах? Только про LE.

https://www.phoronix.com/news/Arch-Linux-AUR-Russian-Spam

скриншот оттуда

Современные диски очень долго пересобираются после замены, шанс того что во время пересборки слетит и второй (raid5) или даже третий (raid6) становится всё выше. Причём они не обязательно должны именно сломаться в этот момент, может быть в них например давно уже пачки бэдов, по их никто не читал (с большими дисками шансы этого тоже растут), а во время пересборки вылезло и навернуло массив. Как вы относитесь к данной проблеме?

1) избегаем рейды кроме миррора, расходы на диски соответственно повысились

2) боимся, но желание сэкономить перевешивает, делаем raid5/6

3) это всё страшилки, нет там никаких проблем, пользуемся raid5/6 без лишних страхов

4) проблема есть, но всё забекаплено и если что восстановим, а на простои пофиг

Речь про диски типа 20тб и похожие.

Фу такими быть.

Я ещё мирился с системг на тех немногих железках где стоит дебиан (более старых версий), но на новом даже стартовый скрипт нормально теперь не прописать без возни с юнитами. Походу и на серверах надо его на девуан менять.

https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#automated-contri...

Additionally, AI-generated code conflicts with this project's license (Unlicense), since you cannot truly release code into the public domain if you didn't author it yourself.