Фикс уже доступен, даже в нескольких вариантах, но сам факт не может не настораживать.

Если кого-то, как меня, задолбала невозможность сабжа в штабильном дебиане — проблема в том, что mc > 4.8.31 (в stable 4.8.33) использует последовательность OSC 7 для сообщения терминалу текущего каталога в виде URL’а file:// с именем хоста, а KIO < 6.29 (в stablе kio6 6.13.0) такого урла с хостом не понимает. Варианты решения: даунгрейдить mc до 4.8.31, апгрейдить KDE до анстейбла, или пересобрать kf6-kio с этим патчем из апстрима.

Спасибо за внимание.

К примеру, в ответ на

host -6v google.com 2001:4860:4860::8888

приходит

09:20:48.871688 IP6 2a02:xxxx:xxxx:xxxx::xxxx.50073 > 2001:4860:4860::8888.53: 27327+ A? google.com. (28)
09:20:48.890751 IP6 2a0c:a9c7:8::1.53 > 2a02:xxxx:xxxx:xxxx::xxxx.50073: 27327 6/0/0 A 108.177.14.101, A 108.177.14.100, A 108.177.14.102, A 108.177.14.138, A 108.177.14.113, A 108.177.14.139 (124)

host такого не понимает и отваливается по таймауту, хотя днс-ресолвер в роутере таки прожёвывает и отдаёт айпишник. Это вообще как со стандартами согласуется?

Провайдер Дом.ра. ЧСХ, на Мегафоне всё OK. И при запросе к 8.8.8.8 по IPv4 тоже всё ОК, только c v6 фокусы. Опять какие-то ркн-овские игрища, или просто у кого-то там на аплинке руки кривые?

Забавная тут история произошла. Началось с того, что я заметил, что десктопный kdeconnect не хочет принимать файлы, посланные его клиентом с телефона. Причём никаких сообщений об ошибках, ничего — телефонный клиент рапортует, что файл послан, а КДЕ-шное уведомление о приёме продолжает висеть и никак не завершается.

Стал ковыряться. Сбэкпортил свежую версию — хрен, завёл чистого пользователя — хрен. Установил стабильный Дебиан в виртуалке — опа, работает. Но там, известно, системда, а на десктопе у меня нет. Снёс системду в виртуалке (подолбавшись, как водится) — работает. Включил и там и там QT-шный отладочный вывод kdeconnect.*, стал сравнивать — в виртуалке при обнаружении устройства сразу же устанавливается TCP-соединение, а на десктопе с ошибкой сваливается в fallback UDP. Так как вывод ни хрена не информативный, пришлось качать исходники и патчить, чтобы хоть понять, чего ему не нравится. Выяснилось, что демон Кдеконнекта обращается к адресу телефона в виде «::ffff:192.168.x.x», то есть так называемого «ipv4-mapped ipv6». Попробовал пингануть, из виртуалки - просто не пингуется, с десктопа - аж «network unreachable». Нагуглил, что в ядре за это дело отвечает параметр sysctl net.ipv6.bindv6only, и разумеется, в виртуалке он 0, а на десктопе — 1. Выключил — работает. Зашибись.

Но теперь стало интересно, какая же сволочь мне этой настройкой удружила. В /etc/sysctl.d лежит файлик bindv6only.conf. По apt-file и поиском на дебиановском сайте не находится. Стал гуглить дальше — следы обнаружились в багрепортах пакета netbase. Оказывается, эти гендерно-разнообразные этот файл при установке создавали скриптом postinst (нет бы хоть в пакет положили!). После того, как в багрепортах им насовали, создавать (аж с 2010 года) перестали, но и удалять, разумеется, его никто не будет. А раз я систему не переустанавливал никогда, так оно и лежит.

Мляя… Пердолился со всем этим, наверно, больше суток чистого времени. А мораль — если наблюдаются странности с сетевыми приложениями, смотрите /proc/sys/net/ipv6/bindv6only. Ну и, штабильность дебилиана такая штабильность.

Оно вообще как должно работать? У меня (c любым конфигом ядра, что с efifb, что с новомодным simplefb) на консоли что-то видно только до момента загрузки иксов, после этого любая попытка переключиться по Ctrl-Alt-Fn приводит к чёрному экрану. Оно так и должно быть, или это у меня что-то где-то криво настроено?

Пример: настроен OpenVPN-туннель, который отдаёт клиенту глобальный адрес из своего префикса.

Если клиент на хосте, то всё в порядке — интерфейсу tun0 этого хоста присваивается адрес, выданный ВПН, пакеты в него рутятся с этим адресом, и всё работает.

А вот если клиент поднят на маршрутизаторе, за которым есть хосты со своими глобальными адресами — то хрен. Пакет с адресом хоста доходит до туннеля и там пропадает (потому что его адрес источника не совпадает с адресом интерфейса, и туннелю он чужой). И чо делать?

Ну, то есть, всегда можно в лоб запилить маскарадинг, и оно заработает. Но как-то поизящней нельзя? Там, серверу волшебную опцию скормить, интерфейсу туннеля какие-то флаги задать, типа того. Может, TAP вместо TUN поднять, или чо.

Задрало уже. Регаюсь уже на третьем сервисе, у ВСЕХ на poiskvps.ru заявлена поддержка IPv6, а на самом деле — хрен на рыло.

Ну, или посоветуйте VPN-провайдеров с IPv6-туннелем, но такие, похоже, встречаются ещё реже. (Вообще у меня подозрение, что и эти ВПСки с якобы «европейскими» серверами тоже хостятся здесь и тупо пробрасывают туннели «туда» через какой-нить ВПН).

Edit: пнул поддержку hexcore, где регался до этого, адрес выдали. Но один /64 адрес вместо префикса, пришлось городить SNAT. Ну, хоть работает, и то ладно.

KDE-шный kup-filedigger это каким-то образом умеет (хоть и ооочень тормозно) — если выбрать конкретный файл, показывает список хранящихся версий, с возможностью восстановления конкретной из них. Хочется получить что-то такое же для всех хранящихся файлов. Хотя бы для отдельного файла, тогда можно было бы зарядить скрипт и рекурсивно все перебрать. bup, зараза, совершенно непрозрачен в этом плане. Инфа о ревизиях где-то в метаданных должна быть, но как её оттуда вытащить? Никто не ковырялся?

У меня одного вываливается ошибка 403: Forbidden при попытке скачать драйвера с офсайта? Через tor, ЧСХ, пролезло. Это ещё чё за новости? Очередной санкционный бан по IP?

https://iz.ru/1775426/valerii-kodacigov/skorost-otstupa-v-rf-hotat-zapretit-ispolzovanie-servisa-speedtest

Я бы также предложил компетентным органам обратить пристальное внимание на такие, с позволения сказать, образчики враждебной технологии, как traceroute и ping, да и протокол ICMP в целом. Наши люди несанкционированную диагностику сетей не проводят. Для этого есть специально уполномоченные государственные организации, которым истинные патриоты всецело доверяют.

Он же «номер кнопки» в просторечии. Телевизоры с цифровым тюнером умеют это делать уж лет двадцать как, даже самые задрипанные. А мощнейшая линуксовая мультимедия-инфраструктура — хрен. Ни одна софтина, от гуёвых плейеров до консольных тулзов типа dvbv5 — слыхом не слыхала о каких-то там «номерах кнопок». Причём тот же dvbv5-scan в режиме «verbose» видит, падла, этот 0x83 дескриптор с LCN’ами, но сохранить их никуда невозможно, разве что перенаправлять вывод в файл, и потом пердолиться с разбором. 24-й год 21-го века, мать его…

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069182

Короче, в инитскрипт, запускающий udev на системах без системды (причём скрипт этот любезно предоставлен системдэшниками, но сами они, ЧСХ, его не используют), засунута команда, очищающая udev-базу, построенную на этапе initrd. Из-за этого диски, обслуживаемые девмаппером (а это LVM, и, возможно, всякие рейды) перестают нормально видеться удевом как валидные устройства. Что, в свою очередь, портит работу софта, пользующегося удевом для перечисления дисков (а его сейчас море). Причём в cоответствующих udev-рулесах для LVM даже явно говорится о том, что базу надо сохранять.

Отдельно доставляет то, что, как выясняется, кто и зачем вообще добавил это удаление — не знает никто.

Короче, если кто-то, как я, пердолится с безуспешными попытками что-то установить/настроить под 64-битным вайном — сообщаю, что гениальные дебилиановские мейнтейнеры спрятали исполняемый файл wine64 так, что по PATH он не находится. Типа вайновский лончер у них сам определяет, какую версию запускать. Что ломает хренову прорву установочных скриптов разного стороннего софта, которые рассчитывают на существование wine64. Ну, вот что стоило положить в /usr/bin/ долбаный симлинк, утырки?

Я кончил.

что наконец-то даёт возможность включить spec_rstack_overflow=microcode вместо дефолтного safe-ret. Ну чё, по крайней мере у меня в тесте sysbench threads (единственный тест, где результат был хуже, чем при mitigations=off) снижения производительности практически не наблюдается. (Хотя вроде как это менее безопасно, чем «Safe RET», но это другой вопрос.)

Чем бы ещё таким потестить? А то все бегали, орали про «снижение производительности вдвое».

Чо, как у кого прошло новейшее обновление с новым интерфейсом? В интернетах-то вон, вой стоит, что не запускается.

Как было у меня — обновление прошло, Стим сам перезапустился в первый раз нормально(!). Поглядел на новый интерфейс, вышел. И после этого — всё, халява кончилась, запускаться отказывался. Иконка в трее есть, окна нет. В логах куча подобного дерьма:

Jun 16 07:22:52 **** kernel: [ 1924.346637] traps: Composite Threa[4742] trap invalid opcode ip:7ff19dbdb794 sp:7ff18ae8a7f0 error:0 in libcef.so[7ff19b2ef000+7770000]

В интернетах советуют проверить, что установлены 32-битные библиотеки OpenGL/Mesa. Но у меня последний блоб с нвидиевского сайта, естественно, 32-битные либы тоже.

Что помогло лично мне: запустил стим с ключом -vgui, при этом загрузился старый интерфейс. Включил в настройках «use GPU acceleration» (много советов его выключать, но, похоже, новому интерфейсу он, наоборот, как раз таки нужен). Стим захотел перезапуститься, перезапустился сам нормально. После штатного выхода теперь вроде бы запускается без проблем с новым интерфейсом. Ну, ещё Big Picture почему-то оказался в оконном режиме вместо полноэкранного, хотя соответствующий пункт был выключен — помогло его включить/выключить.

Не факт, что переживёт перезагрузку, правда, не пробовал ещё…

Короче, как-то так получилось, что у меня уж давненько наблюдались микрофризы на нвидии 1080. В принципе, не сильно мешали даже в игрушках, так что привык, а разбираться было лень, грешил на драйвера или на недостатки общей конфигурации пекарни. А тут решил посмотреть на ФПСы, поставил mangohud и заметил, что пики на графике frametime, которые сопровождают эти фризы, следуют равномерно через 3 секунды. Опа, думаю, значит, что-то периодически дёргается в фоне. Оказалось — какое-то время назад добавил виджеты кде-шного рабочего стола, показывающие скорость вращения вентиляторов (тупо вывод cat /sys/class/hwmon/.../ fan?_input). Но вот тот, который показывает скорость вентилятора видяхи, за неимением соответствующей записи в /sys, дёргал, по совету из Арчевики, nvidia-settings -q GPUCurrentFanSpeedRPM -t, таки каждые 3 секунды. Я хз, чем это поделие там занимается ради вывода одного-единственного параметра, но таки вот. При этом та же nvidia-smi таким не страдает (но она текущую RPM выводить не умеет, только уставку скорости в процентах). Быстренько переделал утилитку из примеров libXNVCtrl, чтобы выводила нужную скорость, и щас наслаждаюсь идеальными 60 FPS в игрухах.

Тут ещё косяк KDE, конечно — за каким чёртом регулярно обновлять виджеты, когда запущен полноэкранный режим? Композитинг-то отключать научились, а вот это…

Edit: Вижу, требуется пояснение, в чём именно заключается вредность совета. Как выяснилось, nvidia-settnings ради чтения одного-единственного параметра на какую-то долю секунды ставит колом всю видеоподсистему. И это монстроидальное поделие рекомендуется в Арчевики для индикации параметров, например, в conky, что предполагает периодический вызов. А это, на минуточку, при периоде в 3 с, как был у меня — 1200(!) вызовов в час, или 28800(!!) в сутки. (Я тут даже подозреваю, что и глюк с перемежающимися GPF’ами плазмы, заканчивающимися паникой ядра, с которым я бьюсь уже года два — тоже, не исключено, был вызван этим гениальным поделием нвидиевских индусокодеров. Но это требует тестирования хотя бы на протяжении месяца.)

А то чо-то стал ковыряться — какой-то хренов зоопарк. Всякие вики советуют смотреть в /usr/include/X11/cursorfont.h или сравнивать с древней темой типа whiteglass — интересно, они сами это пробовали? У той же whiteglаss под КДЕ половина курсоров тупо не отображается, причем такие ходовые, как «уголки» при изменении размеров окна. Другой половины, наоборот, нет в этих древних списках — таких, как курсоры для драг&дропа, например. В штатных дебиановских темах курсоров полно каких-то имён типа nw-resize, отсутствующих в cursorfont, и симлинков с именами, похожими на хэши типа 0426c94ea35c87780ff01dc239897213 -> wait. Откуда они взялись? Хоть какие-то доки на весь этот бардак существуют в природе?

Edit: ну, какой-то более новый список я нашёл. Но про хэши вопрос остаётся.

Не совсем к линуксу относится, скорей к общесетевым вопросам, но спрошу тут. Наблюдаю какой-то сабж на домашнем серваке где-то с начала месяца (443/https, что характерно, работает). Заметил по сообщениям от certbot, что он не может летсенкриптовский ключ проверить (для этого сервак ACME должен зайти на мой по http, причём строго на 80 порт, в другие не умеет). Сначала подумал, что провайдер порт заблочил, но таки нет — в логах апача успешные заходы на 80 порт проскакивают, причём даже из Штатов, например. На магистральных каналах какие-то боевые действия, что ли? Но почему только 80 порта касается?

В частности имею в виду позорище с (не)подхватом монитора, включенного уже после загрузки. Между прочим, оффтопик умел это делать уже начиная с семерки, если не раньше. И напомню, что на современных видяхах никаких там вечно запитанных DVI/VGA уже нет, как правило, то есть надо уметь обрабатывать hotplug. Ну, udev умеет генерить событие при включении, а дальше что с ним делать? Ладно, иксы можно перезапустить, хоть по Ctrl-Alt-Bksp, хотя и это требует предварительного шаманства (нужно в конфиге разрешить запуск иксов без монитора и саму эту клавиатурную комбинацию) — а с фреймбуфером что? Никакое пердоление с заданием EDID в параметрах ядра не помогает от слова вообще.

Или это я настолько отстал от жизни со своим инитом и иксами, и модные systemd/wayland таки умеют подхват из коробки?

Короче, есть такая конфигурация ALSA->JACK: дефолтный plug -> dmix -> loopback -> dsnoop -> alsa_in -> JACK (кусок .asoundrc ниже, без capture части, она сейчас не важна).

pcm.!default {
    type plug
    slave {
        pcm "aloopDuplex"
        format S32_LE
    }
}

pcm.aloopPlayback {
  type dmix
  ipc_key 1
  ipc_key_add_uid true
  slave {
    pcm "hw:Loopback,0,0"
    format S32_LE
#    rate 48000 # default
    period_size 1024
    buffer_size 4096
  }
}

# duplex device
pcm.aloopDuplex {
  type asym
  playback.pcm "aloopPlayback"
  capture.pcm "aloopCapture"
}

# ------------------------------------------------------
# alsa_in -j alsa_in -d cloop -r 48000 -q 1
pcm.cloop {
  type dsnoop
  ipc_key 3
  ipc_key_add_uid true
  slave {
    pcm "hw:Loopback,1,0"
    format S32_LE
#    rate 48000 # default
    period_size 1024
    buffer_size 4096
  }
}

Формат S32_LE выбран для совместимости с JACK (потому что он обычно запускается первым и alsa_in создаёт свой конец loopback’а с таким форматом).

В принципе, в таком виде всё даже работает, НО. Битрейт в алсовской части, как видно, везде дефолтный 48000. Сам JACK сидит на 96000, поэтому получается двойная конвертация: сначала из источника (с каким-то своим битрейтом) plug делает 48000, а потом уже alsa_in 96000. Мне так показалось, что можно от этого избавиться, указав везде rate 96000 для Алсы, чтобы конверсия была один раз, на стороне plug. Попробовал — ИЧСХ, оно даже работает со speaker-test, например. Но вот Файрфокс, ска, отказывается цепляться к дефолтному устройству с какой-то невнятной диагностикой, чего-то там про MediaSinkAudioError.

Сначала подумал, что ему вообще битрейт выше 48000 не нравится, но он таки цепляется и звук выводит, если: а) запустить через apulse (пульсы в системе нет); или б) если дефолтным устройством задать непосредственно звуковуху, работающую на зажатом битрейте 96000.

ХЗ, чего ему может не нравиться. Ну, то есть, скорей всего, какой-то косяк в его поддержке Алсы, которую афтары постепенно deprecate’ят, но вдруг я чего-то ещё в конфиге не учёл?