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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Коммит: 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 и в логах иксов на момент проблемы пусто. Что это было? И как это можно по-лучше было диагностировать? Или может и сейчас что-то проверить можно, вдруг проблема не исчезла а только спряталась?

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.

Вот тут ИИ нашёл решение до сих пор нерешенной проблемы из области дискретной геометрии: гипотезы Эрдёша (номер 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, судя по датам перд этим скопилированных.