Возможно ли в современном дистрибутиве настроить мультисит на одной видеокарте?

Все ресурсы перерыл: нашёл руководства 15-тилетней давности, мультисит с отдельной видеокартой на каждый seat и какие-то хаки/поделки с хардкодной реализацией.

Из свежего нашлось, что сделали протокол drm lease и даже вроде в wayland поддержку сделали, но вот организовать multiseat с его помощью, вроде, нельзя (только если самому код допиливать).

UPD: нашёл вот такое https://gerrit.automotivelinux.org/gerrit/admin/repos/src/drm-lease-manager

Поддержка Ray Tracing (далее RT) у AMD заявлена лишь для поколения RDNA2 графики, в то время как более ранняя Vega, используемая в т.ч. во всех выпущенных на сегодняшний день APU Ryzen, её официально лишена.

В мае 2021 Joshua Ashton показал возможность поддержки RT на Vega (статья в броузере в центре --- там детали). В сентябре был подготовлен патч для Mesa, к концу года принят в dev-ветку, но войдёт лишь в грядущую Mesa 22.0.

Cлева показан пример RayTracing reflection(Sascha Willems'a), запущенный на встроенном видео AMD Ryzen 3 2200G(устройство - RADV RAVEN). Справа же Vulkan Hw Capability Viewer --- расширения VK_KHR_acceleration_structure и VK_KHR_ray_tracing_pipeline присутствуют.

Замечу, что производительность на встроенном видео удручающая, расширения VK_KHR_ray_query, VK_KHR_pipeline_library, VK_KHR_deferred_host_operations отсутсвуют, но для знакомства с RT может подойти.

>>> Просмотр (2536x1080, 510 Kb)

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

Ну в общем это тред игр, где вам хотелось воскликнуть «это гениально!». Добавлю еще одну, Do not feed the monkeys - игра про видеонаблюдение как одну из новых технологий зондирования. Еще одна вертится в памяти, может быть позже вспомню

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

Насколько я понял в документации этого в явном виде просто нет. Как и многого другого, но сейчас не об этом.

Использую канал nixos-unstable. Желание простое - зафиксировать версию ядра, которое я поставил из этого канала сегодня, чтобы все обновлялось, кроме ядра.

Зная ЛОР с классическим «тебе это не надо», поясню зачем оно надо. Я накладываю на ядро патч. При этом у меня Core 2 Duo и ядро собирается 6 часов. Мне не уперлось при каждом обновлении ждать 6 часов. Поэтому я собрал сейчас, и хочу заморозить. В любом линуксе это делается элементарно. В NixOS хочу понять как.

Подскажите пожалуйста, куда копать.

В GTK+ и Qt он есть: GtkTreeView и QTreeView соответственно.

Используем его аж в двух своих приложениях: smstree и DrugStore. Также часто встречаем в серьёзных программах, таких как Atril, Tixati, или хотя бы более простой недревовидный QTableView, как в SQLiteBrowser или DoubleContact от hobbit.

Из сего заключаем, что данный виджет — хороший индикатор матёрости тулкита, и при его отсутствии тулкит вообще не следует воспринимать всерьёз. Наделать на коленке флажков с комбобоксами каждый школьник может — а увы, именно подобное убожество часто всплывает на ЛОРе как очередной нескучный графический тулкит.

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

Тулкиты, для которых такого определённо нет, тоже завезите: будет доска позора.

Доска почёта:

• GTK+: GtkTreeView
• Qt: QTreeView / QTableView
• Tk: TreeView / TkTreeCtrl
• wxWidgets: wxGrid / wxTreeCtrl
• LCL: TListView / TTreeView, VirtualTreeView
• SwingX: JXTreeTable
• JavaFX: TableView / TreeView / TreeTableView
• ImGui: Unity-IMGUI-TreeView / Unity-IMGUI-List-View
• IUP: IupTree
• 1С: ТаблицаФормы
• FLTK: Fl_Tree
• Serenity LibGUI: TreeView

Доска позора:

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

Есть snap, flatpak, wayland. Вроде хорошее дело, но - они добавляют изоляцию между приложениями, и такие штуки как jack, pulseaudio уже не могут работать как раньше. Надо что-то решать. И тут появляется надежда - pipewire. Но надежда ложная, потому что это катастрофа!

Нет, надежда все-таки есть.

Вот мои претензии (которые в итоге разрешились):

1. Обязательный ресемплинг. Как известно, pulseaudio поддерживало две частоты дискретизации микшера - основную и альтернативную. Это позволяло, в случае воспроизведения например только музыки со spotify переключать микшер на частоту дискретизации потока и УБРАТЬ ресемплинг! Если воспроизводит только одно приложение, ресемплинга быть НЕ ДОЛЖНО! Потому что он не нужен. Pipewire не позволяет, и похоже что реализовать это в той архитектуре, которую заложили, будет весьма непросто. На практике он всегда делает ресемплинг и всегда портит звук.

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

Переключение РАБОТАЕТ уже сейчас, на версии из Git! На релизе 0.3.33 у меня не работает.

КАК СДЕЛАТЬ:

В pipewire.conf пишем:

default.clock.rate          = 48000
default.clock.allowed-rates = [ 44100, 48000 ]

Можно перечислить в allowed-rates до 16 значений. Все!

ТЕПЕРЬ - если воспроизведения не было, и запустить на воспроизведение ОДНО приложение, pipewrire будет переводить себя и звуковую карту на частоту дискретизации этого приложения, и ресемплинга НЕ БУДЕТ.

2. При работе с jack клиентами может меняться размер буфера. Занавес! То есть я играю на гитаре, и тут мне меняют размер буфера? А ничего что это приведет к слышимому и чувствуемому изменению задержки звука? Как играть??? Так НЕЛЬЗЯ ДЕЛАТЬ, а надо делать ровно наоборот. Я уже молчу про то, что изменение на лету размера буфера может просто крашануть jack приложение, которое такого бреда не ожидало!

3. Для того, чтобы вообще хоть как-то задать размер буфера для jack клиентов, надо запускать приложение с переменной окружения PIPEWIRE_LATENCY. То есть мне теперь все приложения из консоли стартовать? Или все desktop файлы править? С настоящим jack это решается элементарно - программой управления типа qjackctl. Там просто выбирается какой буфер, и все приложения используют его. Должно быть ВОТ ТАК.

Решение:

pw-metadata -n settings 0 clock.force-quantum <size>

устанавливает фиксированный размер буфера.

Или в jack.conf:

node.lock-quantum = true

4. Нельзя нормальным образом поменять частоту дискретизации при работе с jack клиентом. Используется та, на которую настроен pipewire своим конфигом. С нормальным jack частота просто выбирается в qjackctl. А с pipewire что, мне править конфиг и перезапускать его, или как?

Решение, можно менять на лету:

pw-metadata -n settings 0 clock.force-rate <samplerate>

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

Последний релиз и коммиты, которые делаются прямо сейчас показывают, что развитие пошло именно в нужную сторону.

Товарищи из Гугла [1] (а до этого из Пейсбука [2]) говорят, что все процессоры говно.

Для Ъ: процессоры молча считают неправильно (aka SDC). Один умудрился так зашифровать, что никто больше расшифровать не может. Ничего не говорят о масштабах трагедии или распределении Intel против AMD.

Кто-нибудь из операторов ДЦ сталкивался с подобным?

[1] https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s01-hochschild.pdf

[2] https://engineering.fb.com/2021/02/23/data-infrastructure/silent-data-corrupt...

https://github.com/systemd/systemd/pull/19598

Поттеринг осторожничает:

on a scale from 1 to 10 how much would debian hate if we actually would adopt this?

С++ – сложный язык. Хоть это для каждого по разному и тд, но он очевидно сложнее большинства (всех?) высокоуровневых языков программирования. С другой стороны он очень быстрый и дает тотальный контроль.

Теперь вопрос: должен ли язык быть априори настолько сложным для достижения мощи как в с++ или же так просто исторически сложилось (ака историческая несправедливость)?

Собственно, сабж: https://github.com/GTAmodding/re3

Работают хорошо, по крайней мере GTA 3 и Vice City, Liberty City Stories не пробовал. Для работы нужен как минимум OpenGL 2.1 или OpenGL ES 2.0.

20.02.21 репозиторий на GitHub закрыт по DMCA. Ссылки на другие источники: раз, два, три.

Короче отправил свою старую AWUS036H на пенсию.

https://www.aircrack-ng.org/doku.php?id=faq#what_is_the_best_wireless_card_to_buy

Написано значит, что Alfa AWUS036ACH — это самое оно, но ядро линуксовое как всегда заглючит и упадёт.

А AWUS036ACM типа хорошо работает, но у него менее удобное форма, чтобы вставлять.

Есть ли шанс на первое, что прилетит какой-то post-factum на голубом вертолёте и всё починит? Или безнадёга и брать второе?

subj

"Кратк. сест. тал."

Я описываю свой собственный опыт основанный на тестировании и использовании прошивок с microG в повседневной жизни.

Топик не про то как патчить вашу [название прошивки] прошивку NanoDroid-patcher а про ток как проще всего самому себе сделать прошивку с microG из коробки.

Да разговор именно про сборку из исходников.

Необходимые начальные условия:

• желание
• актуальный дистрибутив GNU/Linux
• минимум 250Gb свободного места
• минимум 16Gb озу
• наличие актуальных для требуемой версии android-а: device tree, kernel sources и vendor blob`s под ваш девайс
• свободное время

Далее нам нужна одна из прошивок с поддержкой signature spoofing

Выбираем любую на свой вкус.

Хозяйке на заметку - не смотря на наличие такого чудовища творения как LineageOS bundled with microG конкретно на LOS применение патчей signature spoofing оказывают крайне негативное влияние на общую стабильность получающейся прошивки. Поэтому если хотите страдать но дальше продолжать есть кактус то успехов вам в этом.

Выбрали себе прошивку? Качаем исходники. Это элементарно даже описывать нет смысла но ладно если вы так хотите то на примере AospExtended

repo init -u git://github.com/AospExtended/manifest.git -b 11.x
repo sync -c -j$(nproc --all) --force-sync --no-clone-bundle --no-tags

Первая команда пролетит мгновенно а вторая растянется на долго в зависимости от скорости вашего канала в интернет. После этого исходники aex вы скачали.

Далее добавляем свои собственные device tree, kernel sources и vendor blob`s к скачанным исходникам aex делается это в файле:

mkdir -p .repo/local_manifests
touch .repo/local_manifests/roomservice.xml

Хозяйке на заметку - дерево устройства device tree не универсально и должно быть адаптировано под конкретную прошивку. Делается это относительно просто но это предмет отдельного разговора. Т.е. да за основу можно брать деревья устройства с любых прошивок под такую-же версию android под конкретно ваш аппарат.

Мы всё ещё не добавили microG и F-Droid! Всё в тот же roomservice.xml добавляем:

<!-- microG and F-Droid -->
<project name="omnirom/android_prebuilts_prebuiltapks" path="prebuilts/prebuiltapks" remote="github" revision="android-11" />

И по новой синхронизируем repo sync.

Теперь самое интересное интеграция всего этого счастья в прошивку!

В директории своего дерева устройства…

cd $AOSP/device/VENDOR/NAME
touch microG.mk

И в microG.mk вставляем буквально следующее:

# microG
PRODUCT_PACKAGES += \
    AuroraStore \
    FDroid \
    additional_repos \
    FakeStore \
    GmsCore \
    GsfProxy \
    MozillaNlpBackend \
    NominatimNlpBackend \
    com.google.android.maps.jar

Далее добавляем в device.mk

# microG
$(call inherit-product, $(LOCAL_PATH)/microG.mk)

И остаётся только собрать и прошить!

source build/envsetup.sh
lunch aosp_device_codename-userdebug
make -j$(nproc --all) | tee build.log

Хозяйке на заметку - там написано make aex -j$(nproc --all) | tee log.txt но оно не работает.

Удачных вам сборок и прошивок!

Год или два назад, хотел решить проблему дёрганного UI в linux.
Проявлений у неё много, но простейший кейс, это однопоточный процесс, заставляющий дёргаться всё остальное на четырёхядерном железе.
Микрофризы на разных программах разной силы. Скажем, chromium более чувствителен, чем firefix. Но даже в emacs они порой ощутимы.
Перепробовал тогда всё: приоритеты, cgroups, тюнинг CFQ, пересборка debian stable без tickless и с 1000hz.

Всё впустую. И в сумме, и по отдельности.
Да, cgroups вполне успешно душит общее использование CPU низкоприоритетной группой, но когда надо поскроллить в хромиуме, в группе гораздо с гораздо более высокими cpus shares, лаги никуда не деваются.

Не люблю наколенные поделки, но раз в прошлом ничего не получилось, попробовал стороннее ядро http://https://liquorix.net
Честно говоря, немного шокирован результатами. Моя конфигурация cgroups там не работает, только скрипт повышающий приоритет декстоп-ориентированым процессам, но на этом с ара-тюнингом с моей стороны всё.

Так вот: я вообще не могу навскидку понять, завершилась моя фоновая однопоточная числодробилка, или нет.
Другой типичный юзкейс: проявка raw в rawtherapee, пока в picture-in-picture фаерфокс играет что-то с ютуба.
На стоковом ядре, или из бекпортов, видео жёстко лагало и периодически просто фризилось на несколько секунд, понижение приоритета rawtherapee не помогало.
С ядром liquorix и rawtherapee с nice 10 вижу, как периодически выпадают кадры из видео, когда rawtherapee пытается всё процессорное время сожрать, но общая плавность вполне сохраняется.
nice начинает наконец реально работать с точки зрения отзывчивости. Долгоиграющий многопоточный пожиратель cpu с nice 19 не то чтобы совсем уж незаметен, но доставляет меньше проблем.

Из совсем неожиданных эффектов: очень быстро переключаются рабочие столы. Редко что-то завершаю, от того у меня полно программ и окон, и почему-то на стоковом ядре, даже без нагрузки, нужно немного времени чтобы всё нарисовать.
Казалось, это норма. Оказывается нет.

Сижу с этим ядром на одной из машин уже месяц, пока проблем не было.
Работают ли числодробилки медленнее? Не знаю. Я бы не огорчился и от 20% пенальти по общему runtime.
Из нехорошего: там ещё кучи каких-то патчей, решающих проблемы, которых у меня нет. Стрёмненько.
Ядра пекутся как пирожки, а не раз в вечность. Тоже стрёмненько.
Нет поддержки x86.
Пока из недостатков вроде всё.

TL;DR: MuQSS делает всё, о чём мы мечтали, и без ручного тюнинга.

Debian 9, Linux 4.9. Внезапно гуй перестал отвечать, курсор мертв много минут. Почему такое происходит в 2020? Почему из коробки дистибутивы не научились лечить такое?

Фото стола: https://i.ibb.co/8MzTJzq/P-20201129-072410.png

Как известно, Apple начала неистово превращать компьютер в телефон как раз после смерти Джобса. А на определенной версии Mac OS X нельзя комфортно сидеть до скончания времен, как на Windows XP, со свидетелями Windows 2000 наперевес.
Никто так и не задумал сколотить команду для выпуска свежих дистрибутивов, с обновлением всего что можно? А там и вовсе переписыванием?

https://www.youtube.com/watch?v=3d4xXvF2ukY

Понимаешь, что есть музыка развлекательная и как бы это сказать, вызывающая более высшие чувства как эта. Недаром и комментарии вроде

If aliens asked me for one good reason not to wipe out the planet, I would show them this.

She stopped being a human when she began singing this song..and then she became an Angel of God...

Ave Maria Gratia plena
Maria Gratia plena
Maria Gratia plena
Ave, ave dominus
Dominus tecum

Benedicta tu in mulieribus
Et benedictus
Et benedictus fructus ventris
Ventris tui Jesus

Дальше почему-то не звучало здесь

Ave Maria
Ave Maria Mater dei
Ora pro nobis pecatoribus
Ora, ora pro nobis
Ora ora pro nobis pecatoribus

Nunc et in hora mortis
In hora mortis nostrae,
In hora mortis, mortis nostrae
In hora mortis nostrae
Ave Maria!

Решил открыть в последнем (4.14) Eclipse CDT проект на C, использующий Makefile в свободной форме.

Что ж, проиндексировалось и открылось всё весьма быстро и, как видно, сам Eclipse в памяти занимает меньше 1 ГБ. И да, я могу вручную (ни о каком автоопределении целей, как это умеет remake, речи не даже идёт) добавить произвольные цели make (make targets) и собрать их (см. окно «Build Targets» справа).

Но на этом плюсы заканчиваются.

Eclipse не обрабатывает Makefile’ы и не строит базу данных компиляции в процессе создания проекта и потому индексирует тупо всё, что попадётся под руку. Это значит, что список включённых в проект файлов (часть модулей же обычно исключена из .config), равно как и #define’ы, ему априори неизвестны, и ни о каком точном рефакторинге говорить нельзя.

Более того, часть (включённого) кода в редакторе «сияет красным», и мне сообщают об ошибках, которых нет. Так, на снимке на 324-й строке fs/btrfs/async-thread.c Eclipse не может определить тип переменной work, хотя и ежу понятно, что это тип struct btrfs_work *, и этот тип определён в лежащем рядышком хедере. При попытке навигации к объявлению переменной work (хотя это локальная переменная в btrfs_work_helper()) мне предлагается 100500 кандидатов, разбросанных по всему проекту (диалог Open Declaration).

Вердикт – текстовый редактор, не более. Я, как давний пользователь и поклонник Eclipse, реально разочарован.

Несколько обязательных комментариев:

• WM – WindowMaker
• Тема оформления GTK3 – Greybird. К сожалению, только в «штатных» темах Adwaita, Greybird и Numix Eclipse выглядит удовлетворительно (в силу того, что разработчики SWT сделали ряд «хаков» для поддержки этих конкретных тем оформления), хотя, напр., поля ввода по-прежнему выглядят гигантскими. Сами разработчики рекомендуют попробовать отключить вышеупомянутые «хаки» (-Dorg.eclipse.swt.internal.gtk.noThemingFixes, см. bug 527729) и включить Clearlooks-Phénix, но, на мой взгляд, там работы ещё непочатый край: кнопки панели инструментов становятся раза в полтора больше и «уезжают» вправо.
• Да, ШГ. Да, «кровь из глаз». Да, я всё это уже не раз слышал.

>>> Просмотр (1920x1200, 146 Kb)

Наткнулся тут на очень добротно сделанный редактор для python для маленьких (и не только).

• Мимимишный и весёлый интерфейс
• Несколько режимов работы
• Отладчик
• Плоттер выхлопа в графики
• Repl куда без него, тоже удобно сделан для совсем ничего не понимающих
• Чекер с удобными подсказками

https://codewith.mu/en/tutorials/

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

Я не люблю питон и не особо его знаю, но иногда приходится что-то по мелочи делать, теперь буду делать в Mu. Хоть глаз радует :D

У меня доступна из реп debian testing.

А ещё ещё нашёл называется Thonny https://thonny.org

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

И того Thonny это

• Асистент который к вашему же коду делает замечания
• Строит дерево программы
• Список переменных
• Заметки
• В целом гораздо больше средств отладки для большего понимания что происходит в коде
• Удобный установщик пакетов
• И многое другое

Ну, а после него или с ним или с обеими можно выбирать любой vim или emacs со всякими иными.

Наверное ещё есть. Но чёт интерес ковырять пропал. Короче всё ::)

Копаясь в интернетах на тему IOMMU наткнулся на https://www.kernel.org/doc/Documentation/x86/x86_64/boot-options.txt в которой есть опция iommu=soft с неясным описанием. Также нашел форум https://bbs.archlinux.org/viewtopic.php?id=168555 , где говорится, что с этой опцией можно пробросить некоторые кривые устройства.

Также есть вот что:
CONFIG_GART_IOMMU:

Support for full DMA access of devices with 32bit memory access only
on systems with more than 3GB. This is usually needed for USB,
sound, many IDE/SATA chipsets and some other devices.
Provides a driver for the AMD Athlon64/Opteron/Turion/Sempron GART
based hardware IOMMU and a software bounce buffer based IOMMU used
on Intel systems and as fallback.

И обсуждение здесь: https://forums.gentoo.org/viewtopic-t-835843-start-0.html

Это как так? Получается, что эта опция позволяет использовать функции ремапинга видеопамяти в процах AMD или полностью софтверный вариант в intel-устройствах?

У кого-нибудь завелось?

Очевидно, что эта байда (если работает без аппаратной поддержки) ппц как грузит проц и тормозит.