После запуска иксов он делают мне 3840x1080, рисуя две его 1920х1080 половины на разных видеовыходах. Одноразово исправляется командой

$ xrandr --output HDMI-0 --pos 0x0

$ xrandr --output VGA-0 --pos 0x0

Как это полностью отключить? Подозреваю, что можно в xorg.conf прописать эти pos вручную (кстати, не знаю как). Но лучше не это, а именно вообще отключить этот виртуальный экран, чтобы вне зависимости от конфигурации видеовыходов он никогда не пытался такое делать. Есть такое?

В иксах с помощью xrandr переключается на лету между VGA и HDMI, как сделать то же самое для ядерной консоли? Знаю про прописывание аргументов в grub, но там нужно ребутаться, другие варианты есть? И ещё, желателен режим чтобы на всех видеовыходах была одинаковая картинка (то есть чтобы сделать 1 раз и больше ничего не переключать) - такое можно настроить хоть как-нить?

%Cpu(s): 10,7 us,  4,3 sy,  0,0 ni,  0,0 id, 82,6 wa,  0,0 hi,  2,3 si,  0,0 st

Вопрос вот про «wa». И кстати почему оно считается состоянием проца вообще? Ведь пока процесс ждёт ответ от диска, ядро проца вполне может заниматься чем-то другим. В фрибсд например iowait не считается занятым ядром и в детализации занятости проца его нет.

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

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

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

Лет 10 назад на старых дисках (blue и подобных на 250гб и меньше) такого ни разу не замечал.

Купил новый хороший БП с большим запасом мощности, засунул в соседний молекс на 5В и 12В линии по low-esr конденсатору 2200мкФ - не помогает ничего.

У меня стандартная процедура доступа к этому счётчику на WD40EFPX (Red Plus 4TB) не работает, диск собственно отклоняет команду его чтения. Я её шлю не через idle3-tools а через фрибсдшный camcontrol в виде блоба байт, но это не важно. На старых дисках (например WD20EFRX Red 2TB, 2015 года) всё работает. А ещё я в инете нашёл жалобы на аналогичную ошибку и из idle3ctl и из hdparm -J, но нигде не нашёл внятные ответы на эти репорты. Может кто на ЛОРе знает точный ответ?

Хотя радует что конкретно у этого диска таймер явно не 8 секунд, но Load Cycle уже стало 2 вместо 1, так что какой-то он есть, сейчас ставлю опыты. Возможно исправлять его и не требуется, но хотелось бы знать остался ли к нему доступ.

$ sensors
k10temp-pci-00c3
Adapter: PCI adapter
temp1:        +41.5°C  (high = +70.0°C)
                       (crit = +72.0°C, hyst = +70.0°C)

it8718-isa-0228
Adapter: ISA adapter
in0:           1.46 V  (min =  +0.00 V, max =  +4.08 V)
in1:           1.60 V  (min =  +0.00 V, max =  +4.08 V)
in2:           3.26 V  (min =  +0.00 V, max =  +4.08 V)
+5V:           2.98 V  (min =  +0.00 V, max =  +4.08 V)
in4:           3.02 V  (min =  +0.00 V, max =  +4.08 V)
in5:           3.14 V  (min =  +0.00 V, max =  +4.08 V)
in6:           4.08 V  (min =  +0.00 V, max =  +4.08 V)  ALARM
in7:           2.74 V  (min =  +0.00 V, max =  +4.08 V)
Vbat:          3.31 V  
fan1:        1163 RPM  (min =    0 RPM)
fan2:           0 RPM  (min =    0 RPM)
fan3:           0 RPM  (min =    0 RPM)
temp1:        +42.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp2:        +51.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermal diode
temp3:        +48.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
cpu0_vid:    +1.050 V
intrusion0:  ALARM

Вот эти in0 in1 итд это что такое? На in6 ещё ALARM какой-то.

Почему пишет +5V 2.98V? Померил вручную на molex разъёме - на 5В нормальные 5В.

Обнаружил странности с ценами (смотрю WD): все диски меньше 2ТБ стоят как 2ТБ (даже 320ГБ) - примерно 5к, а если это Red/Black - то все что меньше 4ТБ стоят как 4ТБ (от 10-12к).

Это всмысле что теперь объём от 2ТБ (или 4ТБ для ответственных мест), а всё что меньше позиционируется как «ну хочешь меньше - дадим меньше за ту же цену»? Или я где-то не там смотрю (всякие алиэкпрессы и прочие помойки в расчёт не берём)?

Диск отвалился по таймауту, спустя 10 часов я это заметил и выключил-включил электричество системному блоку - диск ожил. Хотел посмотреть в смарте что-нить а там всё по нулям, power on hours = 1, power cycle count = 1. Как так, было у кого-нить похожее? Диск WD5000AZRX firmware 01.01A01.

Подозреваю что диск стоит сменить, но всё равно интересно как такое случилось.

Наконец-то дошло дело установить купленный зимой новый монитор (MSI Pro MP271A E2), во всех инет описаниях и у него на коробке написано что он поддерживает 120Гц через HDMI. Видеокарта GeForce GT 610.

xrandr предлагает такое:

HDMI-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 598mm x 336mm
   1920x1080     60.00 +  99.65*   84.90    59.94    50.00  
   1680x1050     59.95  
   1440x900      59.89  
   1280x1024     75.02    60.02  
   1280x960      60.00  
   1280x720      60.00    59.94    50.00  
   1024x768      75.03    70.07    60.00  
   800x600       75.00    72.19    56.25    60.32  
   720x576       50.00  
   720x480       59.94  
   640x480       75.00    72.81    59.94    59.93  

В логе Xorg есть такое:

[2322751.769] (--) NVIDIA(GPU-0): CRT-0: disconnected
[2322751.769] (--) NVIDIA(GPU-0): CRT-0: 400.0 MHz maximum pixel clock
[2322751.770] (--) NVIDIA(GPU-0):
[2322751.781] (--) NVIDIA(GPU-0): CRT-1: connected
[2322751.781] (--) NVIDIA(GPU-0): CRT-1: 400.0 MHz maximum pixel clock
[2322751.781] (--) NVIDIA(GPU-0):
[2322751.785] (--) NVIDIA(GPU-0): DFP-0: disconnected
[2322751.785] (--) NVIDIA(GPU-0): DFP-0: Internal TMDS
[2322751.785] (--) NVIDIA(GPU-0): DFP-0: 330.0 MHz maximum pixel clock
[2322751.785] (--) NVIDIA(GPU-0):
[2322751.799] (--) NVIDIA(GPU-0): Microstep MSI MP271A E2 (DFP-1): connected
[2322751.800] (--) NVIDIA(GPU-0): Microstep MSI MP271A E2 (DFP-1): Internal TMDS
[2322751.800] (--) NVIDIA(GPU-0): Microstep MSI MP271A E2 (DFP-1): 230.0 MHz maximum pixel clock

230MHz для 1920x1080 и правда никак не позволит сделать 120Гц: 230000000/1920/1080=110, а там ещё межстрочные/межкадровые интервалы какие-то должны быть, так что видимо как раз 100Гц и выходит.

Не то что бы мне очень хотелось 120Гц, но раз они заявлены то неприятно что почему-то не дают их выставить.

Вот это 230МГц pixel clock это чьё ограничение? И там рядом 400 и 330 МГц - они чьи?

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

Сделал xrandr --prop, edid оттуда отправил программе edid-decode, результат (конец)

  Detailed Timing Descriptors:
    DTD 2:  1920x1080   84.905 Hz  16:9    95.433 kHz 198.500 MHz (598 mm x 336 mm)
                 Hfront   48 Hsync  32 Hback  80 Hpol P
                 Vfront    3 Vsync   5 Vback  36 Vpol N
    DTD 3:  1920x1080   99.650 Hz  16:9   109.615 kHz 228.000 MHz (598 mm x 336 mm)
                 Hfront   48 Hsync  32 Hback  80 Hpol P
                 Vfront    3 Vsync   5 Vback  12 Vpol N
    DTD 4:  1920x1080  119.982 Hz  16:9   137.260 kHz 285.500 MHz (598 mm x 336 mm)
                 Hfront   48 Hsync  32 Hback  80 Hpol P
                 Vfront    3 Vsync   5 Vback  56 Vpol N

[Вс апр  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 или можно настроить?

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