Я сделал пропритарщину в кубе - программа патчинга VBIOS для GTX470-780Ti для отключения вызывающих артефакты проблемных каналов памяти. Без исходников, а для работы ещё и прав рута требует (или попросит ввести пароль от sudo).

Помимо отображаемых в интерфейсе фиксированных текстовых ссылок - никаких закладок в ней нет; но это нельзя никак проверить кроме как поверить мне на слово, всё как любят на ЛОРе.

Предназначена для программного восстановления работоспособности артефактных карт GTX470-780Ti путём модификации VBIOS. Если вы хотите чтоб старое железо, совместимое с nouveau снова заработало - вам должно понравиться)

Идея в том, что если карта этой серии не работает/глючит - то по статистике довольно часто дело в коммуникации по одному из каналов памяти. И этот канал можно просто отключить, получив снова рабочее оборудование.

В процессе работы попеременно прошивает различные vbios, и после перезагрузки просит проверить работает или нет. В зависимости от того работает или нет - соотвественно выбирает какой VBIOS прошивать дальше.

Линукс тут при том что линукс-версия есть, разрабатывалась наравне c оффтопик-версией, основное отличие от виндовой лишь в том, что вместо безопасного режима используется смена target systemd через set-default multi-user.target и systemctl set-default graphical.target.

Соответственно от linux-пользователя ожидается готовнотсь работать в текстовой консоли 80x25, по карйней мере вернуть взад графический режим загрузки через sudo systemctl set-default graphical.target. Программа к текстовой консоли условно готова, хотя и не вся псевдографика нормально отрисовывается. В частности цветовая маркировка кнопок в этом режиме может быть не очень интуитивна - для интуитивного выбора верхнего или нижнего вариантов можно использовать Home/End. Если очевидных артефактов нет, то рабочесть VBIOS проверяем через startx (в предположении что драйвер для этих карт установлен - nouveau или старая ветка драйвера nvidia).

Остальная инструкция по сути такая же как инструкция для windows представленная на сайте. Там же архив с бинарниками: https://gpuzelenograd.github.io/NVIDIARU?L202211

Называется «Old NVIDIA artifacts»

Также отмечу что функционал открытия файла VBIOS для модификации (в противовес прошивке физической карты) - работает только в полноценном графическом сеансе, так как использует XDG Desktop Portal для диалога открытия файлов. Также чтоб портал работал - сама программа НЕ должна быть запущена от рута.

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

C момента появления vulkan была инфа что он может использоваться для вычислений без необходимости взаимодействия с визуальной составляющей оконной системы, через vulkan compute. Тогда я надеялся что это будет убийца cuda, однако технология не обрела популярности.

Решил потыкать её палочкой - а работает ли оно вообще. Оказалось что вполне работает и достаточно платформонезависима!

Основные проблемы - мало документации, мало средне-уровневых обёрток над низкоуровнеыом API.

Запилил на vulkan compute нагрузочный тест видеопамяти, может быть полезен при оценке стаильности при оверклокинге или ремонте - https://github.com/GpuZelenograd/memtest_vulkan

Бинарники есть в артефактах сборки (удалятся через 90 дней) https://github.com/GpuZelenograd/memtest_vulkan/actions/runs/3140130070 и в файлах релиза -https://github.com/GpuZelenograd/memtest_vulkan/releases/

Пример работы выглядит так:

https://github.com/GpuZelenograd/memtest_vulkan v0.4.0
To finish testing use Ctrl+C

1: Bus=0x04:00 DevId=0x1F07   8GB NVIDIA GeForce RTX 2070
2: Bus=0x03:00 DevId=0x1B82   8GB NVIDIA GeForce GTX 1070 Ti
3: Bus=0x00:00 DevId=0x0000   2GB llvmpipe (LLVM 13.0.1, 256 bits)
                                                   Override index to test:2
Testing 2: Bus=0x03:00 DevId=0x1B82   8GB NVIDIA GeForce GTX 1070 Ti
      1 iteration. Since last report passed 46.700972ms     written     3.2GB, read:     6.5GB    208.8GB/sec
     23 iteration. Since last report passed 1.023638989s    written    71.5GB, read:   143.0GB    209.5GB/sec
    131 iteration. Since last report passed 5.029294127s    written   351.0GB, read:   702.0GB    209.4GB/sec
    771 iteration. Since last report passed 30.041030795s   written  2080.0GB, read:  4160.0GB    207.7GB/sec
^C
memtest_vulkan: no any errors, testing PASSed.
  press any key to continue...

Пример, обнаруживший ошибки

https://github.com/GpuZelenograd/memtest_vulkan v0.3.0
To finish testing use Ctrl+C

1: Bus=0x01:00 DevId=0x1B87   8GB NVIDIA P104-100
Testing 1: Bus=0x01:00 DevId=0x1B87   8GB NVIDIA P104-100
      1 iteration. Since last report passed 52.20479ms      written     3.8GB, read:     7.5GB    215.5GB/sec
     21 iteration. Since last report passed 1.0515038s      written    75.0GB, read:   150.0GB    214.0GB/sec
    216 iteration. Since last report passed 10.021230569s   written   731.2GB, read:  1462.5GB    218.9GB/sec
   2125 iteration. Since last report passed 100.010942973s  written  7158.8GB, read: 14317.5GB    214.7GB/sec
Error found. Mode NEXT_RE_READ, total errors 0x3C7EC3 out of 0x3C000000 (0.39384872%)
Errors address range: 0x9D66148C..=0xDCD3036B  bit-level stats table:
         0x0 0x1  0x2 0x3| 0x4 0x5  0x6 0x7| 0x8 0x9  0xA 0xB| 0xC 0xD  0xE 0xF
SinglIdx                 |      1m         |                 |                 
   0x1?                  |      1m         |                 |                 
TogglCnt      3m 820k    |                 |                 |                 
1sInValu            1   2|  32 249 13645067| 15k 39k  81k142k|219k308k 398k468k
   0x1? 506k502k 448k353k|239k134k  63k 25k|79792113  310  43|   5        1    

Справочно - существует аналогичная штука для openCL, но с поддержкой openCL я ловил больше проблем чем с Vulkan - https://github.com/ihaque/memtestCL

Первый раз работаю с web-socketами. Предполагается сервер на Qt на основе этого примера - https://doc.qt.io/qt-6/echoserver.html

и клиент на сервере node.js - вероятно как тут: https://www.npmjs.com/package/websocket

Гоняться будет поток jsonов в направлении сервер->клиент, один json - одно текстовое сообщение.

После прочтения всех доков остался следующий вопрос - со стороны клиента при подключении со стороны node.js передаётся опциональное поле protocol, вида

client.connect('ws://localhost:8080/', 'echo-protocol');

А вот со стороны Qt-ного сервера - никакого упоминания о том, какие protocol надо отправлять чтоб к нему подключиться - нет. Возможно любой, но на моём уровне понимания этого вопроса - какая-то угадайка получается.

В сязи с этим вопрос - есть ли какая-то дока по этому полю, чему в протоколе соответствует этот параметр из node.js?

Используется ли это поле на практике, и если да - какие типичные использования?

Ищется место, раздающее домены 3го, 4го хоть 5го уровня, всё равно. Имя любое, хоть .i-am-dumb.info

Требования по фичам минимальные - авторизоваться через web по email, вписать статический IP. Раз в год-полтора - поменять IP.

Автоматизированное обновление через dyndns не требуется, минимизация рисков подмены через многофакторную аутентификацию и т.п. не требуетя, специальные типы записей не требуются. Анонимности тоже не требуется, пусть хоть email публикуют. Какиелибо dns-хитрости для http/https тоже не нужны.

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

Есть что такое?

Знакомлюсь с растом, пока даже не столько чтоб на нём писать, а чтоб понять подходы и там где это возможно и осмысленно применять в С++.

С трейтами Copy, и Clone и Drop всё вроде понятно. Не понял пока одного - верно ли что при передачи владения переменной с перемещеним (например со стека в вектор - так же вроlе можно?) всегда выполняется просто побитовое перемещение в другое место?

Иными словами - может ли unsafe тип внутри содержать указтель на себя, который в специальном трейте типа Drop можно будет корректировать при таком перемещении, или так нельзя?

Usecase следующий - сделать аналог Vec, который при малом количестве элементов будет хранить их не в куче, а в себе, и соотвественно указывать будет не на кучу, а на внутренний буфер в самой переменной.

Пытался настроить gpu passthrough на материнке ECS X79R-AX c Xeon E5-2667 и упёрся в то, что BIOS не даёт необходимой ACPI-таблицы DMAR, хотя железо по идее всё поддерживает.

Согласно идее и последней ссылке в https://stackoverflow.com/questions/32177990/iommu-initialization-without-bio... хочу попробовать просто подложить таблицу от того же чипсета X79. Ну или если полезут ошибки - как-то её поредактировать.

Но для этого надо эту acpi таблицу откуда-то взять. Буду благодарен, если кто-нибудь выложит или пришлёт на gpfault@smtp.ru

Сделать для этого нужно следующее:

sudo cat /sys/firmware/acpi/table/DMAR > DMAR.raw

Если такого файла нет - убедиться что в биосе включено всё что касается Intel Virtualization

Также желателен полный дамп таблиц ACPI через утилиту acpidump из пакета с именем вроде acpica-tools:

sudo acpidump > acpidump.raw

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

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

В древовидном режиме htop показывает загрузку процессора дочерними потоками, однако для основного потока (являющегося корнем поддерева) он показывает суммарную загрузку процессора всеми потоками данного процесса.

Есть ли какая-то возможность интерактивно посмотреть на загрузку процессора именно основным потоком?

Приходит в голову только вычесть из суммы значения всех остальных, но это плохо решает задачу «Интерактивный анализ использования CPU основным потоком при различных действиях»

Для начала работы некоторого алгоритма необходимо подготовить массив из 128-ми void*, заполненный нулями. Массив выделяется при помощи aligned_alloc, поэтому гарантированно выравнен по sizeof(void*[128]).

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

Поскольку данные хорошо выровнены, и не потребуются в кеше - по идее наиболее быстрый способ - отправить их в память при помощи streaming non-temparal - что-то типа _mm512_stream_si512 - оно же VMOVNTDQA для x86.

Но как можно кросс-архитектурно намекнуть компилятору, что тут будет уместна такая инструкция?

То что данные выронены на 64 байта наверное можно объяснить, обнулив младшие биты указателя, с которым идёт работа. А вот как выразить на С совет не помещать данные в кеш - непонятно

Foxit Software выпустила первую стабильную версию Foxit PDF reader — программы просмотра pdf-документов.

В качестве тулкита используется GTK. Внешний вид (включая мелкий баннер в правой части полосы меню) и функционал практически идентичны старым версиям Windows-клона и содержат все минимально необходимые функции просмотрщика. Из недостатков стоит отметить не очень удобную реализацию поиска и отсутсвие хоткеев к некоторым часто нужным пунктам меню.

Уникальной особенностью Foxit reader является крайне быстрая прорисовка без заметной на глаз задержки даже для сложных страниц при интенсивной навигации по всему документу — используется тот же pdf-движок на freetype2, что и в других продуктах Foxit Software.

Доступен бинарный пакет для x86 в виде deb, rpm и tar.bz2.

>>> Скачать

Пришла в голову такая идея: пусть сервер отсылает некотрый длинный поток данных по tcp, при этом клиент точно знает что первая половина данных ему не нужна, а вторая нужна как можно быстрее. При этом ограничение скорости определяется наиболее узким местом канала - шейпером у провайдера клиента (или технологией последний мили до клиента(модем)). Также, предполагая худшее, положим что протокол верхнего уровня тупой и не поддерживает seek (например http с отключённым range). Таким образом, единственная возможность получить данные второй части быстрее - это извращения на уровне tcp. А именно предлагается следующее: поскольку причиной того, что сервер отправитель отсылает данные с реальной скоростью канала клиента, а не быстрее является то, что клиентом установлен малый размер tcp-окна и что подтверждения о доставке от клиента приходят не слишком быстро.

Что будет, если клиент установит большое tcp-окно и на те данные которые ему не нужны, будет присылать подтверждения ранее их получения? Насколько я понимаю канал сервера на отдачу будет работать в полную силу и, поскольку канал клиента не может принять столько данных, часть (ненужных клиенту) входящих пакетов будет дропаться (или буферизоваться, но после переполнения буфера опять дропаться).

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

Вопрос скорее теоретический, нежели практический, ибо сейчас ситуация модем + сервер без докачки уже малоактуальна. Однако всё же интересно узнать о том, насколько реалистично выглядит такая реализация "forward seek" для tcp, и какие могут быть проблемы? Возможно кто-то имел опыт с подобными приёмами тогда, когда это было действительно актуально на практике?

На данный момент сижу за 17" ЭЛТ с 1600*1200@75. Но, всему хорошему приходит конец и что-то его последнее время лагает. К тому же на 17" приходится выбирать - или текста мало влезает или шрифты слишком мелкие (физически).

Посему некоторое время назад озаботился выбором замены. И к своему удивлению обнаружил что относительно недорогие моники у которых есть хоть 1200 по вертикали имеют диагональ _не меьнше_ 24. (Насколько я понял отсутсвие на рынке моников нормального разрешения с меньшей диагональю вызвано тем, что многие быдлоприложения на дельфи, mfc и прочих некорректно работают с вендовыми настройками DPI и вендоюзер возвращает такие моники "потому что мелко".)

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

Таким образом остаётся 2 варианта:

1)Брать 20" 1680*1050 и смириться с тем что даже на самых мелких шрифтах при разбивании экрана вертикально на 2 рабочие области в каждой из них будет строк текста ещё меньше чем сейчас (т.е. downgrade налицо), поскольку по вертикали мало пикселей (ну или шрифты будут настолько квадратные что ппц).

2)Или же брать 24" 1920*1200 и садится подальше от него, чтоб не замечать что размер пикселей как на ноутбуке 10 летней давности.

3)Я бы рад взять LG L2000 с разрешением 1600*1200, но кажется он недавно исчез даже в дефолт-сити не говоря уже о других предложениях на 20" 1600*1200 на <15K :(. Поставки окончились, остались лишь пустышки в прайсах :(

Чувство эстетики говорит, что надо выбрать вариант 1), потому что там пиксель меньше, а иначе будут ШРИФТЫ (ибо в варианте 2 DPI будет почти в 1,5 раза хуже чем сейчас - это всё же перебор)

Здравый смысл наоборот говорит что надо выбрать 2), потому что можно просто сесть подальше и считать что это 20". К тому же по идее при одинаковых угловых размерах для зрения - чем дальше сидеть тем лучше.

Что посоветует all и анонимусы?

Есть несколько вопросов к тем, кто работает (а не только гамает и кино смотрит) за >=24: Не приходится ли слишком сильно "крутить головой", это не раздражает? Какие проблемы могут возникнуть с подключением 1920*1200 по dvi? по d-sub? dvi будет работать хоть с чем-то из дров {nv, nvidia}? (видео - nvidia GF 5200 - на CRT такое разрешение легко выдаёт по d-sub). В ограничения dvi-single_link не упрётся?

Какие pcmcia-карточки с usb-портами заработают под линуксом?

Напишите пожалуйста, кто сталкивался с ними, фирму/чип и соответственно заработало ли. Отрицательный опыт также интересен. Спасибо.

~curlftpfs 192.168.8.8 ~/note
~mount|grep fuse
curlftpfs on /home/g/note type fuse (rw,nosuid,nodev,user=g)
~stat /home/g/note
File: `/home/g/note'
Size: 1024 Blocks: 0 IO Block: 4096 Каталог
Device: 11h/17d Inode: 1 Links: 1
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 1970-01-01 03:00:00.000000000 +0300
Modify: 1970-01-01 03:00:00.000000000 +0300
Change: 1970-01-01 03:00:00.000000000 +0300
~ls /home/g/note
bin/ boot@ dev/ etc/ home/ lib/ lost+found/ mnt/ opt/ proc/ root/ sbin/ sys/ tmp/ usr/ var/
~whoami
g
~id
uid=1000(g) gid=1000(g) группы=10(wheel),92(audio),93(optical),94(floppy),1000(g)
~sudo -s
~#stat /home/g/note
stat: невозможно выполнить stat для `/home/g/note': Отказано в доступе
~#ls /home/g/note
ls: невозможно получить доступ к /home/g/note: Отказано в доступе
~#whoami
root
~#
~curlftpfs --version
curlftpfs 0.9 libcurl/7.15.5 fuse/2.5

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

sudo cat somesecurefile|cat>~/note/outfile

поскольку у сp нет прав читать, а у sudo cp писать.

Получается, что у пользователя есть права на папку, а у рута нет. Это как так? Впервые такое вижу. Разъясните, пожалуйста в каких ещё ситуациях возможно, что у юзера больше прав, чем у рута.

В качестве возможного решения предлагается следующая прога:

#include <unistd.h>
#include <fcntl.h>
int main(){
int i=open("/dev/fb0",O_RDONLY);//Пишем из фреймбуфера
int o=open("/dev/fd0",O_WRONLY);//На дискету
static const unsigned s=0x400;
char c[s];
read(0,c,1);//Wait for enter
sleep(5);//Time to switch to other vt
for(;;){
int res=read(i,c,s);
if (res<=0) break;
write(o,c,res);
}
return 0;
}

Запускаю прогу на одном терминале, делаю rm -rf / на другом, после завершения переключаюсь на первый, жму Enter, переключаюсь на тот с которого будет скрин и жду результата...

Вопрос: я правильно понимаю, что если файл удалён после открытия программой, то программа может с ним корректно работать дальше?

Версия rm, установленная в системе ещё поддерживает возможность удаления /

Виртуальную машину или chroot не предлагать :)

Можно ли сделать так, чтоб zsh не добавлял в историю команды, начинающиеся с определённой строки? Можно ли заставить его каждую добавляемую в историю команду прогонять через мой обработчик?

После того как 1 раз по ошибке исполнил rm и 2 раза poweroff появилось резкое желание не добавлять в историю команды, начинающиеся с "rm ", "poweroff", "reboot" и "sudo " ...

Не получается настроить частоту развёртки во framebuffer - при увеличении частоты (с помощью fbset) происходит срыв развёртки.

В иксаx (дрова nv) нормально работают следующии modeline:

Modeline "1600x1200" 200.0 1600 1680 1800 2155 1200 1233 1234 1267

Modeline "1984x1233" 242.9 1984 2080 2200 2555 1233 1233 1234 1267

Первый из них преобразую для fbset (по этому HOWTO: http://www.tldp.org/HOWTO/Framebuffer-HOWTO-18.html ) и получаю

fbset -g 1600 1200 1600 1200 8 -t 5000 355 80 33 33 120 1

- срывается. Пока не подниму pixclock с 5000 до 7000 развёртка срывается. 7000 не устраивает поскольку вертикальная получается 52 Гц :( , а хочется хотя бы 72 (разумеется при сохранении 1600x1200)

пробовал немного крутить другие параметры fbset - не помогает, но я не очень понимаю какие именно надо в этом случае. Реально иксы работают и на pixclock 242Mhz, в логах иксов что по DDC ограничение 200Mhz (5000 для fbset), в доках моника ограничение на 160Mhz (>=6250 для fbset) но уж никак не 7000.

То, что генерит gtf -f тоже срывается.

И, совершенно неясно: если поставить глубину цвета не 8 а 32 или 24 то вообще одна рябь при любом режиме. (глубина цвета совершенно непринципиальна)

Монитор ЭЛТ iiyama HM703UT(vision mater pro 413), видео GeForce FX 5200, подключён через обычный VGA, дрова nvidiafb.

dmesg|grep nvidiafb

nvidiafb: PCI id - 10de0322

nvidiafb: Actual id - 10de0322

nvidiafb: nVidia device/chipset 10DE0322

nvidiafb: CRTC0 analog found

nvidiafb: CRTC1 analog not found

nvidiafb: EDID found from BUS1

nvidiafb: CRTC 0 appears to have a CRT attached

nvidiafb: Using CRT on CRTC 0

nvidiafb: MTRR set to ON

nvidiafb: PCI nVidia NV32 framebuffer (64MB @ 0xE0000000)

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

Ещё раз отмечу, что в иксах и в винде 1600x1200@(примерно 75) отлично работают.

В качестве варианта рассматривается переход на rivafb (он поддерживает мою видяху?) или vesafb-<somepatch> (если сможет 1600x1200@75)

Что ещё можно сделать?

Существует ли хоть какой-нибудь стандарт на Esc-последовательности терминала для клавиш с модификаторами? Или что придёт терминалостроителям в голову, то и используют?

Про попытки логического расширения Vtxxx знаю, но там дальше Shift+Fn вроде бы не доходит... Интересует что-либо более извращённое вроде Ctrl+Enter, Alt+Shift+Insert, Ctrl+Shift+Left (А лучше вообще всё что возможно)...

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

Интересует любая информация на тему ТАКИХ esc-последовательностей.

Дистрибутив Arch 0.7.2 У меня существуют устройства 0-63 в /dev/vc и ссылки на них tty0-tty63 в /dev

в udev.rules прописано по умолчанию(я не менял):

KERNEL=="tty[0-9]*" NAME="vc/%n" SYMLINK+="%k"

Использую только первые 12 консолей - вполне хватает

Как объяснить ядру, что не нужно создавать устройства 13-63 (раздражают, при просмотре /dev занимают пол-экрана)?

И ещё один вопрос: при просмотре man`ов справа имеется поле в несколько символов. Как его убрать(я жадный, места жалко)?

P.S. Понимаю, что вопросы крайне дурацкие, но уж извините сам не знаю как...