[Вс апр  6 20:34:58 2025] usb 1-4: new high-speed USB device number 5 using ehci-pci
[Вс апр  6 20:34:58 2025] usb 1-4: New USB device found, idVendor=03f0, idProduct=3d17, bcdDevice= 1.00
[Вс апр  6 20:34:58 2025] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Вс апр  6 20:34:58 2025] usb 1-4: Product: HP LaserJet P1005
[Вс апр  6 20:34:58 2025] usb 1-4: Manufacturer: Hewlett-Packard
[Вс апр  6 20:34:58 2025] usb 1-4: SerialNumber: LC00FTQ
[Вс апр  6 20:34:58 2025] usblp 1-4:1.0: usblp0: USB Bidirectional printer dev 5 if 0 alt 0 proto 2 vid 0x03F0 pid 0x3D17
[Вс апр  6 20:35:02 2025] usblp0: removed
[Вс апр  6 20:39:49 2025] usb 1-4: USB disconnect, device number 5

Включаю принтер в usb, через какое-то время появляется /dev/usb/lp0, проходит ещё 5 сек и оно исчезает (предпоследняя строчка лога). Последняя строчка это я вытащил кабель. В lsusb он виден всё время пока кабель вставлен.

Раньше всё работало (не помню когда точно, но вроде уже этот релиз стоял - Devuan 4, это аналог Debian 11), на ноутбуке рядом (там Debian 11) тоже удаляется. Если пока он есть успеть отправить туда firmware - принтер реагирует на неё как раньше (крутит валиком). Но потом всё равно удаляется.

Почему это может быть?

Линуксовый multipathd как-то автоматически распознаёт что например sdc и sdf - два пути к одному и тому же «диску» (речь про первое его подключение, когда никаких данных там ещё не записано). Мне лень изучать его исходники, как он это делает?

Фрибсд так не умеет, там надо вручную задавать устройства, хочу тоже автоматизировать. Из доступной информации вижу: номер шины, номер таргета на шине, номер луна, wwpn (идентификатор порта лун-провайдера). Из всего этого совпадают только номера лунов, но номер луна может совпасть и у разных дисков.

Системг обнаружил, что физическое устройство, на которое был по его мнению смонтирован путь, исчезло, и размонтирует его. Я монтирую - он сразу опять размонтирует (пишет в лог). Как это прекратить? Путь разумеется монтируется на уже новое устройство которое есть. В fstab ничего не менялось т.к. UUID у него тот же - он скопирован через dd.

Нужно чтобы демон думал что к нему подключаются из инета, хотя на самом деле к нему подключается другая локальная прога. В этой проге я включаю на сокет опцию O_BINDANY, делаю bind() на внешний поддельный айпи-адрес и затем connect() к адресу демона.

Из tcpdump-ов выяснилось, что TCP SYN идёт правильно через локалхост от моей проги к демону, а вот SYN+ACK ответ отправляется в настоящий интернет через сетевуху, до моей проги не доходит. Как ему объяснить что он тоже должен через локалхост идти? Напрашивается ipfw fwd, но ему же надо айпи+порт куда заворачивать указывать, а он там поддельный и к тому же каждый раз разный.

Вообще я думал что при наличии локального сокета с нужным ip+port+ip+port пакеты должны попадать сразу в него вне зависимости от того, какому интерфейсу это всё принадлежит, но оказывается нет.

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

Исходные данные:

1) есть функция int SSL_shutdown(SSL *ssl);

Краткое содержание мана: функция отправляет «close notify alert» и иногда ещё и принимает ответ на него (тоже «close notify alert») от той стороны. Возвращает: -1 если произошла ошибка либо нужно ждать читаемости/записываемости сокета, 0 если «close notify alert» отправлен успешно, но ответный ещё не получен, и 1, если и отправлен и получен.

Касательно возврата 0 там есть три пояснения:

а) если мы планируем закрывать сокет то можно этим и ограничиться и ответ не ждать

б) есть рекомендация вызвать SSL_shutdown() повторно чтобы принять ответ

в) есть рекомендация вызвать SSL_read() повторно чтобы принять ответ - да, в том же мане 4 абзацами ниже предыдущего утверждения, которому оно немного противоречит (подозреваю речь идет про SSL_ERROR_ZERO_RETURN, см. ниже, но это догадка)

2) есть ошибка SSL_ERROR_ZERO_RETURN, в мане к SSL_get_error описанная так: та сторона закрыла соединение для записи, отправив «close notify alert», читать данные больше нельзя (и уточнение что речь не идёт о сокете, а только об ssl-сессии).

Описание очень похоже на описание нуля, возвращённого из recv() для обычных BSD-сокетов, однако в инете я нашёл ряд репортов про получение этой ошибки от SSL_write(), так что кажется её может делать и он. Тут непонятно: ман говорит что нельзя больше читать, а оказывается что и запись тоже блокируется? В SSL/TLS вообще есть такое явление как наполовину закрытый поток, когда одна сторона завершила отправку и уведомила об этом, а потом только принимает ответ?

В мане какие-то мутные намёки на то, как будто оно есть, но не уточнено как с ним обращаться. Например, как известно, TLS иногда шлёт какие-то служебные данные, которые в итоге прозрачно обрабатываются во время вызова SSL_read/SSL_write. Пока соединение полностью открыто, с ними всё просто: узнаём что на уровне сокетов что-то пришло, вызывает SSL_read(), тот уже либо выяснит что это полезные данные и выдаст нам их, либо примет и обработает служебные и скажет что пользовательских пока нет. Если же та сторона сделала shutdown и нам SSL_read возвращает только SSL_ERROR_ZERO_RETURN, то кем читать пришедшие байты? SSL_write не годится, если мы пока что не хотим ничего записывать, а оставлять их в сокете тоже нельзя - они будут постоянно триггерить select() или его аналоги. Убирать сокет из select-а тоже нельзя - тогда мы не узнаем если он вдруг закроется уже на уровне tcp.

Или, может быть, всё проще, и SSL_ERROR_ZERO_RETURN следует считать как «соединение умерло, закрываем всё что осталось», а в мане просто враньё? Смущает фраза из мана SSL_shutdown: «the peer is still allowed to send data after receiving the close_notify event», и рядом ещё ода рекомендация использовать именно SSL_read вместо повторного SSL_shutdown.

Судя по веб-архиву, 22-24 июля 2024 они его сделали. Зашёл посмотреть, первое что подумал - что они просрочили домен и его захватили киберсквоттеры, как с bzip2 случилось. Но походу это не так и сайт настоящий. Точнее, теперь у них 9 (может не все нашёл) сайтов - по отдельному домену 2 уровня на каждый «раздел». Напомнило сайты известного наверно автора rus-os.narod.ru, но у того оно всё 3-го уровня на бесплатном хостинге было в тут вот так.

Или может всё-таки у них что-то случилось, например проект приобрели какие-то эффективные бизнесмены?

Обижаться на то, что я не оценил оформление твоей новости/продукта из неё и сносить за это коммент с причиной «флуд» (но оставлять такой же формально «флуд», на который я отвечал), а затем, по примеру худших представителей лора, искать рандомный мой коммент в поиске чтоб поставить к нему клоуна в ответ - со стороны модератора крайне некрасиво.

Допустим, есть переменная, полностью обычная (просто char a; - для определённости пусть будет однобайтовая). Ещё до начала совместного к ней доступа она инициализируется либо нулём, либо не нулём. Если ноль - то дальше она не меняется. Если не ноль - то дальше в неё могут записываться другие ненулевые значения в произвольные моменты времени. Другой тред читает эту переменную, не утруждая себя межтредовой синхронизацией, но единственное что ему нужно - выяснить ноль в ней или нет. Как мне кажется, никаких проблем это создать не должно ни при каких обстоятельствах. Однако может быть я что-то упустил? И второй вопрос, отдельный: где формально написано что так можно?

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

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

И второй вопрос: по российскому законодательству будет осуждаться выкладывание этих pdf-ок на сайте для безвозмездного скачивания кем угодно?

Старая тема но в ней оказалось много неверной информации так что создаю новую.

В иксах через setxkbmap настроен переключатель en-ru с индикацией через scrolllock. В норме включёный индикатор скроллока означает русскую раскладку. Проблема: если включить русскую раскладку, затем передёрнуть клавиатуру в разъёме - то скролллок выключается (раскладка, естественно, остаётся русской). Если после этого ещё раз нажать хоткей - то раскладка переключается с русской на английскую, а скролллок включается. И он так и остаётся в противоположном нормальному состоянии до тех пор, пока либо его не пофиксить повторным передёргиванием клавы уже на англ раскладке, либо переключить раскладку через гуи-переключатель, который ставит правильный скроллок.

От софта это не зависит. Если запустить startx xterm - поведение такое же.

Это баг в xorg или можно настроить?

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

Я даже не ожидал такого, и когда после нажатия «restart firefox» оно вместо закрывания окна краша начало что-то куда-то отправлять пришлось выдернуть патчкорд из разъёма, успело около мегабайта отослать. Шлёт как оказалось курлом, т.е. прибивание гуи-процесса отправку не останавливает, надо ещё курл отдельно прибить. А ещё игнорирует настройки прокси, что впрочем неудивительно. Если галочку снять то в следующий раз она опять оказывается установлена.

В директории крашрепортера есть файл crashreporter.ini

Crash Reporter]
EmailMe=0
IncludeURL=1
SubmitReport=0

{
  "submit_report": true,
  "include_url": false
}

Например тут: www.linux.org.ru/forum/linux-org-ru/6228389/history

Если включить подсветку различий, то в последних двух правках якобы ничего не менялось кроме заголовка. В предпоследней версии при включении подсветки различий добавляется 21-й пункт, по идее должный быть подсвеченный красным, но не подсвеченный, при этом следующие за ним превращаются из 21-24 в 22-25 (но это видимо из-за нативного поведения списочных html-тегов).

Аналогично, в последней версии новый добавленный 21-й пункт не подсвечен зелёным.

Раскладки настроены так:

setxkbmap us,ru -option "" -option "grp:lctrl_lshift_toggle,grp_led:scroll"

При нажатии ctrl+shift переключается язык и переключается индикатор скролллока. Но если переключать язык не хоткеем а например через гуи - скролллок не переключается. То есть получается например выбранный русский язык, но скролллок выключен. Если после этого переключать опять через ctrl-shift - переключается и то и то, и получается выбран уже англ, но скроллок загорается. Можно ли как-то сделать чтобы скроллок не переключался на просто другое состояние, а переключался на правильное (us - выключен, ru - включён)?

По-моему когда-то давно оно так и работало, но возможно я что-то путаю.

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

Думаю не составит особого труда найти эту логику в исходниках xorg-а и всё выяснить, но вдруг ответ имеется и без них? Поэтому создал тему.

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

Собственно вопрос остаётся - почему так и как это исправить.

Ещё удивительнее: после опытов в других сессиях и в основной стало нормально работать. Интересно когда опять сломается. Ребутать не хочу.

В связи с темой PHP 8.4 — большое обновление языка, напомнившей мне про пхп, решил его кое-где применить и в ходе планирования наткнулся на такую штуку.

Примеры:

<?php
  $a = array('a' => 1);
//  $X = array(&$a['a']); $X = 1;
  $b = $a;
  $a['a'] = 2;
  var_dump($b);

<?php
  $a = array('a' => 1);
  $X = array(&$a['a']);// $X = 1;
  $b = $a;
  $a['a'] = 2;
  var_dump($b);

<?php
  $a = array('a' => 1);
  $X = array(&$a['a']); $X = 1;
  $b = $a;
  $a['a'] = 2;
  var_dump($b);

<?php
  $a = array('a' => 1);
  $X = array(&$a['a']);
  $b = $a;
  $a['a'] = 2;
        $X = 1;
  var_dump($b);

<?php
  $a = array('a' => 1);
  $X = array(&$a['a']);
  $b = $a;
        $X = 1;
  $a['a'] = 2;
  var_dump($b);

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

Впрочем, это, как и остальные его мелкие некрасивости, никак не влияет на тот факт, что пхп всё равно лучший вариант для «накодить несложное по-быстрому».

Добавил sata-диск, ребутнулся, итог:

1) после запуска гуи (lightdm+x11 с автологином) перестаёт работать клавиатура и мышь (alt+prtscr+b работает, ctrl-alt-f1, numlock итд не работают)

2) qemu-system-x86_86 (он в автозапуске) пишет про отсутствующий модуль kvm

Оказалось, что откуда-то запустилось ядро 3.16 вместо 4.19 и от этого всё пошло наперекосяк. В видимом после запуска /boot/ есть только 4.19, и в /boot/grub/grub.cfg тоже прописано 4.19. В биосе в качестве загрузочного на первом месте стоит правильный диск который был и раньше. Добавленный диск виден как sdb. В dmesg правильный диск - «sd 0:0:0:0», неправильный - «sd 1:0:0:0». Но походу grub цепляет с него и конфиг и ядро, хотя дальнейшая загрузка делается с правильного диска. Как так вышло и как исправить?

Этот второй диск - старый системный для текущей ОС, возможно там какие-нить идентификаторы совпадают, но до мая этого года тот диск был подключён вторым и всё работало (но была другая материнка хоть и той же модели - возможно отличается ревизия биоса или какие-то опции в нём). Старые системные разделы просто висели неиспользуемыми (у них тип mdraid, это половина миррора) и ничему не мешали. Никаких обновлений ядер/grub/initramfs за прошедшее время (с отключения диска) не было.

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

Обновление:

Заметил, что груб с не тем конфигом сам тоже не тот - над меню показывается версия пакета, там deb8. Осталось узнать кто же запускает не тот grub. Или эта строчка в конфиге прописана?

1) grub-install /dev/sda - не помогает (я думал возможно прошитый на sda груб почему-то считает что его домашний раздел на sdb)

2) затирание загрузочного кода в mbr sdb - не помогает (думал может быть биос грузит с sdb несмотря на явное указание грузить с sda)

3) убирание флага активности с sdb1 - не помогает

4) затирание описания раздела sdb1 (то есть этого раздела теперь вообще нет) - помогло, стал грузиться правиьный груб с правильным конфигом итд

Но тему решённой не помечаю, т.к. вопрос никуда не девается: каким образом и кто запускает груб не с того диска. Мастер-бутсектор на старом диске (кроме таблицы разделов) затёрт, то есть грузится точно MBR правильного диска, который в свою очередь вряд ли может по своей инициативе лезть на другой (или может?).

Внутри там двуядерный athlon, но второе ядро не используется, т.к. я не умею его запускать.

Запускается через DOS, но весь сетевой стек, начиная с драйвера сетевух (их там 4 штуки, назывались вроде dlink 520, по факту VIA Rhine II), менеджер памяти, движок кооперативной многозадачности, псевдографический оконный интерфейс и базовые утилиты типа шелла, телнета, сниффера и http-браузера — самописные в виде монолитного бинарника на турбо-паскале + ассемблере, местами 32-битном.

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

Фотография

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

Оно опять сломалось.

Сам патч https://firk.cantconnect.ru/yt-dlp/yt-dlp-fix-dzen-20241104.patch

Пропатченая версия yt-dlp если кому лень: https://firk.cantconnect.ru/yt-dlp/yt-dlp-2024.10.22-patched

Как патчить вручную:

Кладём yt-dlp в текущую директорию

7z x yt-dlp # unzip ругается на шебанг, поэтому 7z
patch -p0 < yt-dlp-fix-dzen-20241104.patch
zip -r yt-dlp.patched.zip __main__.py yt_dlp
echo '#!/usr/bin/env python3' > yt-dlp.patched
cat yt-dlp.patched.zip >> yt-dlp.patched 
chmod +x yt-dlp.patched

Если кто-то отправит им его в этот баг https://github.com/yt-dlp/yt-dlp/issues/11385 я не против

В ходе патчинга обнаружил неудобство: dzen спамит ссылками на якобы разные форматы, из-за чего список раздувается в несколько раз. Убрал форматы «AudioMute» оттуда (для mpd они вообще полностью дублируют обычные т.к. аудиострим там отдельный и так, для m3u8 - не дублируют, если кому надо можете раскомментить нужную строку в патче там комментарий указан об этом). И ещё он каждый m3u8 формат репортит 4 раза не знаю зачем - как это убрать я не знаю, по факту надо добавить в игнор урлы с GET-параметром redundant в мастер-файле m3u8 (его парсинг за пределами парсинга дзена, я его не трогал).

$ kolourpaint 
kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.ServiceUnknown" 
 "The name org.freedesktop.UDisks2 was not provided by any .service files"
kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.ServiceUnknown" 
 "The name org.freedesktop.UDisks2 was not provided by any .service files"
kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.ServiceUnknown" 
 "The name org.freedesktop.UDisks2 was not provided by any .service files"
kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.ServiceUnknown" 
 "The name org.freedesktop.UDisks2 was not provided by any .service files"
kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.ServiceUnknown" 
 "The name org.freedesktop.UDisks2 was not provided by any .service files"
kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.ServiceUnknown" 
 "The name org.freedesktop.UDisks2 was not provided by any .service files"
kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.ServiceUnknown" 
 "The name org.freedesktop.UDisks2 was not provided by any .service files"
kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.ServiceUnknown" 
 "The name org.freedesktop.UDisks2 was not provided by any .service files"
kf.dbusaddons: Can not find 'kdeinit5' executable at  "/home/user1/bin:/home/user1/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games" "/usr/bin, /usr/lib/qt5/bin"
kf.service.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf.service.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf.service.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf.service.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf.coreaddons: Error detected in cache, re-generating
kf.service.services: KServiceTypeTrader: serviceType "ThumbCreator" not found

Кстати хотел клоуна в теги засунуть так пишет

Некорректный тег: '🤡'

Поставил на ноут новую память, решил её на всякий случай проверить. Итоги:

memtest86 пишет «file /boot/memtest86.bin not found» в grub-е, хотя такой файл там есть

memtest86+ виснет на самом первом тесте где-то в середине (спустя пару сек после запуска).

Установил юзерспейсный memtester (он локает память чтоб она не уходила в свап и делает тесты на ней, разумеется не по всему адресному пространству), запустил его в 4 потока по 2G+2G+2G+1G + браузер со всяким медиа чтоб занять остальное (памяти всего 8g) - ошибок не показывает, ничего не виснет.

update:

В конфиге grub-а скопипастил всякие insmod и root из memtest86+ в memtest86 - он после этого запустился и тоже повис на первом тесте

Pass 0%
Test 24%
Test #1 [Address test, own address Sequential]
Testing: 4096M-6144M   2048M of 8078M
Pattern: address

Виснет всегда на одном и том же месте.

upd: Это не первый тест а второй, там нумерация с нуля. Первый #0 это «walking ones».

Если сделать skip на test#1 то виснет на #2 если его тоже skip то на #3 на том же «testing 4096-6114».