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

Я даже не ожидал такого, и когда после нажатия «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».

Сделан из платы ASRock Q1900-ITX и самодельного многоэтажного корпуса.

У платы питание 19V, оно даётся извне ноутбучным БП на верхнюю панель корпуса, где стоят измерители потребляемой мощности каждого этажа и разводка к ним питания.

В первоначальном варианте в качестве хранилища был миррор из двух 2.5" wd black, но они что-то быстро перестали удовлетворительно работать (один вроде вообще сдох) и стал использовать ссд. Изначально на втором этаже была другая система которой я тоже иногда пользовался, и вообще этажей планировалось сильно больше двух (кластер с hardware-изоляцией между разными задачами), и хотел ещё сделать красивую переднюю панель вместо вынесенных на шлейфах кнопок с индикаторами, но...

По факту материнка оказалась не особо хорошей (я не знал что asrock это asus, когда её брал): одна сдохла ещё больше 5 лет назад перестала включаться, у второй потекла батарейка, неудачно расположенная рядом с греющимся разъёмом питания ссд (заметил это в мае этого года, когда я и сделал эту фотку, да забыл выложить), и вот осталась последняя третья плата, изначально бывшая запасной. Хотя та что потекла — включается и работает, но на всякий случай отключил её. На фотке она внизу. И и у как минимум двух экземпляров из трёх есть признаки нестабильной работы при большой нагрузке на память.

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

>>> Просмотр (3072x2304, 406 Kb)

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

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

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

Видимо после роняния ноута из него выпал один из двух ссд. Подсоединив его назад, он почему-то сделался не sdb а sdc. Его файловые разделы я добавил назад в mdadm-миррор и всё норм, а вот в /proc/swaps (свап-раздел без миррора) теперь так:

# cat /proc/swaps
Filename				Type		Size		Used		Priority
/dev/sdb2\040(deleted)                  partition	16777212	0		-2
/dev/zram0                              partition	7812496		766492		10

swapoff /dev/sdb2 его не видит, swapoff -a удалил zram а этот битый свап так и оставил.

# swapoff -a
# cat /proc/swaps
Filename				Type		Size		Used		Priority
/dev/sdb2\040(deleted)                  partition	16777212	0		-2
# swapoff -a
# cat /proc/swaps
Filename				Type		Size		Used		Priority
/dev/sdb2\040(deleted)                  partition	16777212	0		-2

# swapon -a
# cat /proc/swaps
Filename				Type		Size		Used		Priority
/dev/sdb2\040(deleted)                  partition	16777212	256		-2
/dev/sdc2                               partition	16777212	0		-3

# swapoff -a
# cat /proc/swaps
Filename				Type		Size		Used		Priority
/dev/sdb2\040(deleted)                  partition	16777212	4		-2
# swapon /dev/zram0 --priority 10
# cat /proc/swaps
Filename				Type		Size		Used		Priority
/dev/sdb2\040(deleted)                  partition	16777212	4		-2
/dev/zram0                              partition	7812496		0		10
# swapon /dev/sdc2
# cat /proc/swaps
Filename				Type		Size		Used		Priority
/dev/sdb2\040(deleted)                  partition	16777212	4		-2
/dev/zram0                              partition	7812496		0		10
/dev/sdc2                               partition	16777212	0		-3

Надо внести в оффтопик-лист вопросы про «как скачать обход блокировок» и подобное, только не знаю как точно сформулировать.

По мотивам Теория параболического зеркала для э/м излучения

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

----

Занялся я изучением данного вопроса, и (видимо закономерно) обнаружил один жуткий обман, который сначала рассказывают в школе, а потом молчаливо одобряют наверно и в большинстве вузов в т.ч. физической направленности. И суть этого обмана отражена в традиционной форме записи уравнений Максвелла, где слева стоят роторы а справа производиные по времени и ток. Подозреваю, что это (нижеописанное) баян, но только для определённого круга лиц, а вот мне данная «картина мира» долго мешала понять как всё это работает на самом деле.

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

Так вот, это самое что ни есть враньё. Более того, тут не просто плохая интерпретация формул, а ещё и неправильные расчёты в итоге, если мы захотим хорошей точности по времени. Суть вот в чём: «породить циркуляцию/ротор» ничто просто так не может - ведь любые изменения э/м поля это его производные по времени, и именно эти производные и есть то, что мы должны считать чтоб узнать что будет потом. Причём почти везде такой подход вопросо не вызывает и принимается за очевидный, но тут почему-то всё перевернули с ног на голову. Так вот: переменное магнитное поле в сердечнике - это не причина, а следствие наведённого э.д.с. А кто же тогда это э.д.с навёл, если не магнитное поле?

А навёл его ток, полностью автономно и без участия магнетизма вообще, смортим внимательней уравнение: rot B = dE/dt + j или dE/dt = rot B - j (коэфициенты опущены для простоты), т.е. если куда-то течёт ток - то там сразу же наводится противодействующее току э.д.с. Не обязательно в катушке, можно и в обычной прямой проволоке. Почему в проволоке этот эффект намного слабее, чем в катушке? Потому что проволока одна, и наведённое поле стремится расползтись в стороны, где его ещё нет, и таким образом возле тока остаётся слабым, а вот в катушке рядом много проволок и все наводят поле концентрированно в маленьком пространстве. Чтобы увидеть механизм расползания, сделайте из двух уравнений один дифур второго порядка - там будет вторая производная по времени равна второй производной по пространству (по сути это радиоизлучение). Надо заметить - это э.д.с. наводится любым током, как переменным, так и постоянным, и сколь угодно долго по времени. Но есть ещё один фактор: то самое магнитное поле в сердечнике - оно начинает наводиться благодаря dB/dt = -rot E, растёт со временем и начинает наводить своё э.д.с, уже не мешающее току, а помогающее. Со временем это приводит сначала к занулению dE/dt, затем к смене его знака и началу уменьшения E (а магнитное поле всё ещё растёт), и скорее всего увеличению тока (т.к. уменьшается мешающее э.д.с).

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

Смотрю что-то почти все окна (штук 30) пропали. Сначала подумал что это wm почему-то их потерял, но нет

**
VTE:ERROR:../src/vtestream-file.h:403:void _vte_snake_reset(VteSnake*, gsize): assertion failed (offset >= snake->tail): (0 >= 4294901760)
Bail out! VTE:ERROR:../src/vtestream-file.h:403:void _vte_snake_reset(VteSnake*, gsize): assertion failed (offset >= snake->tail): (0 >= 4294901760)
Aborted

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

Судя потому, что у пакета libvte указан homepage на gnome.org, виноваты как всегда гномеры.

К счастью, одно весьма важное окно с 10 вкладками было открыто с --disable-server и его этот краш не зацепил. Возможно надо по-дефолту этот режим использовать.

Давайте продолжим тему (она в архиве 2011 год) Померяемся мониторами (и глазами)

Ссылка чуть обновилась (со старой редиректит) https://www.xrite.com/hue-test?lang=en&pageid=77

У меня 4

Монитор NEC MultiSync EA232WMi

up: увеличил яркость с минимальной до максимальной, стало 0

Это non-systemd мод к debian 11 если что. До обновления в списке установленных пакетов у меня был бардак с фиктивными статусами manual/auto и соответственно в autoremove показывало длинный список из частично нужных пакетов, в котором я предварительно разбираться не захотел и стал обновлять как есть.

В начале оказалось довольно просто - ну разумеется update/upgrade, поставить штатно 64-битное ядро. Скачать (apt install --download-only) amd64 версии dpkg, apt, apt-utils, в официальном дебиановском мануале был ещё tar непонятно зачем, тоже скачал, и perl-base - а вот с ним проблема, apt усматривал в его скачивании пачку конфликтов и ничего не делал, поэтому я на него забил. Ну и установить через dpkg -i всё скачанное (через apt не получится - он найдёт там битые зависимости).

После установки 64-битного dpkg/apt всё стало ломаться - apt стал считать 64 нативной архитектурой, а это, как оказалось, означает что все пакеты с архитектурой :all приравниваются теперь к ней, а не к :i386, и куча зависимостей, как all->i386 так и i386->all оказались сломанными, и даже apt install -f их починить не мог (но я б всё равно не стал его наобум запускать, он бы кучу всего сломал с учётом фиктивных auto/manual статусов). Да, удивительно, там такая вот костыльная реализация дерева зависимостей в применении к all, и полазив пару часов по исходникам apt я не нашёл способа это быстро пофиксить.

Было решено пойти методом грязных хаков - открыл в mcedit-е файл /var/lib/dpkg/status и прописал там всем неожиданно ставшим неподходящими i386-пакетам-чьим-то-зависимостям тег Multi-Arch: foreign (хотел составить список хакнутых пакетов чтоб потом исправить назад но запорол его и списка нет), а там где сломалась зависимость i386->all - в Depends i386-пакета дописывал сломанным зависимостям явное :all. Параллельно с этим, если дело касалось multiarch-совместимых библиотек, которые можно ставить параллельно обе архитектуры, просто честно ставил amd64 (откатившись на 32-битный dpkg/apt чтоб всё работало). Узнал неприятный факт - если в Depends прописана зависимость с архитектурой :any - она ломается без внятной диагностики если у пакета-зависимости стоит Multi-Arch: foreign или same (и не нашёл где это задокументировано), так вышло с тем самым перлом на который я забил в начале. Правда не с perl-base (его оказалось можно протащить 32-битный очень долго, обновляя остальное) а с самим perl. Скачал его и ещё 3 нужных ему пакета apt-get download (он не смотрит зависимости автоматически и не ломается от них) и поставил через dpkg -i. Потом ещё остались разные мусорные libXXX-XXX-perl, половина из которых all, половина i386, которые конфликтовали друг с другом и мешали всё делать, снёс их все через dpkg -r --force-depends чтобы потом уже ставить. Несмотря на то, что дебиановцы считают перл критически важным пакетом, на самом деле для более-менее рабочей системы он не нужен. По крайней мере шелл и пакетный менеджер точно прекрасно обходятся без него.

apt в конце концов пришёл в консистетное состояние и дальнейшее можно было делать через него. (если что, до этого никакие install -f, upgrade или dist-upgrade, указанные в мануале как штатное средство такого апгрейда, работать даже не пытались и жаловались на битые зависимости). Установил 64-битный драйвер nvidia и иксы, можно ребутнуться в наконец в гуи вместо 80х25 консолей.

Потом ещё часов 5 ручного разбора смешанной свалки 32/64 пакетов, удаления ненужного, установки нужного в amd64. Правда часть пакетов так и осталась i386, да и пофиг, всё работает, когда-нить с апдейтом версии переставятся на 64 наверно. Ну и wine разумеется нужен 32-битный со всеми его зависимостями - не трогал имеющийся, всё работает.

Итог: стартовое лагание файрфокса с лазанием по диску (не ssd) удлинилось раза в 3 (было секунд 10, стало около 30). То есть фф уже запустился, но всё делает медленно и видно что всё его время занято i/o. В остальном особых изменений не заметил.

мануал из дебиан вики (который не сработал)

описание тега Multi-Arch в .deb пакетах (для хакинга файла базы /var/lib/dpkg/status)