У меня 1ТБ стораджа со времён бета-тестинга MRu-облака. Не пропадать добру. Написал FUSE-файловую систему для него. Если у кого схожая ситуация - тащите, тестируйте. Мне нужны отзывы, баги, предложения и т.д.

Например, в каких операциях нужен кэш. Где стоит поставить блок/мьютекс. Что ещё стоит реализовать.

В планах дальше шифрование файлов перед заливкой.

Ссылка: https://gitlab.com/Kanedias/MARC-FS

P.S. Debian Stable не предлагать.

Перемещено leave из talks

Есть тема с записью лекций по теоретической физике: Видеолекции по теорфизике под свободной лицензией (update2)

С начала учебного года эта деятельность продолжилась (начали появляться исходники трёх новых курсов). Хотелось бы автоматизировать процедуру размещения их на YouTube.

Как я понял есть возможность загружать видео из командной строки. Вопрос: каким инструментом лучше всего для этой цели пользоваться?

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

MrClon

Вот такое даже есть: https://developers.google.com/youtube/v3/guides/uploading_a_video

Я таки заставил эту игру работать 😊

В процессе была куча сегфолтов и адовые артефакты.

По сути проблемы всего три (конкретно для r600g, в целом для месы – 2):

1. Контекст OpenGL 4.2. Драйвер r600g рапортует версию 3.3, а движок игры, в свою очередь, работает по принципу segfault driven error handling. Решается просто:

   MESA_GL_VERSION_OVERRIDE=4.2 
   MESA_GLSL_VERSION_OVERRIDE=420

2. Невалидные шейдеры. Тут сразу:
   • Во-первых, разрабы используют расширение ARB_shading_language_include, которое не поддерживается ничем кроме невидиевской проприетарщины. Но во имя амдшной проприетарщины они запилили в движок fallback режим, в котором это расширение реализуется прямо в движке на коленке, однако включается этот fallback режим (немного) через жопу – они (только) проверяют возвращаемое значение функции glXGetProcAddressARB на nullptr. А glXGetProcAddressARB не обязан возвращать nullptr, кроме адреса надо смотреть еще в список расширений, чего они не делают, а месовская реализация никогда не возвращает nullptr -> segfault driven error handling. Чинится этот баг подстановкой костыля в LD_PRELOAD.
   • Во-вторых, в шейдерах постобработки SMAA/FXAA у них где-то в дебрях кода обложенное ifdef'ами лежит включение очередного расширения, что, блджад, не правильно. После обнаружения этой фигни месовский GLSL компилятор совершенно справедливо прерывает компиляцию, а так как ребята не умеют в обработку ошибок — см. выше. Этот баг обходится с помощью месовского механизма подмены шейдеров в рантайме и костыля-решейпера их кода шейдеров. файла drirc, в который нужно добавить

     <application name='Divinity Original Sin Enhanced Edition' executable='EoCApp'>
         <option name='allow_glsl_extension_directive_midshader' value='true' />
     </application>

3. Графические артефакты. У них в движке (насколько я понял) есть две принципиально разные ветки кода/рендеринга, которые разделяются по (внимание!) строке в GL_VENDOR: если в этой строке что угодно кроме "ATI Technologies Inc.", то активируется невидиевская ветвь, что на месе приводит к аду, если же доставить в LD_PRELOAD еще один костыль с этой строкой, то рендеринг становится мягким и шелковистым.

TL;DR: Gentoo, дефолтные кеды, ШГ, панелька с автоскрытием.

>>> Просмотр (1600x900, 1682 Kb)

Инженер Red Hat Питер Хаттерер выпустил первую версию приложения Piper, которое позволяет конфигурировать (преимущественно игровые) настраиваемые мыши с большим количеством кнопок. Piper является графическим интерфейсом на GTK+ к демону ratbagd и получает данные об устройствах от libratbag.

В настоящее время libratbag поддерживает около 20 моделей конфигурируемых мышей Etekcity, Logitech и Roccat. Разработчик отмечает, что EULA к официальному конфигуратору Razer напрямую запрещает реверс-инжинеринг протокола, используемого для настройки мышей этого производителя.

>>> Подробности

http://www.overclockers.ru/hardnews/66619/v-poiskah-samogo-nadezhnogo-hdd-201...

Звание самых надёжных заслужили HDD, выпущенные HGST, продемонстрировавшие единичные проценты отказов, в то время как некоторые устройства производства Seagate «блеснули» способностью выходить из строя чуть ли не половиной личного состава.

Сводная таблица картинкой:
http://www.overclockers.ru/images/news/2015/01/23/backblaze_1.png

Оригинальный пруф не гуглил.

Здравствуйте,

не работает опция x-vga=on

qemu 2.1.50

ошибка такая:

qemu-system-x86_64: -device pci-assign,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Property '.x-vga' not found

изза чего она не работает? или она будет работаеть только с vfio-pci ?

Здравствуйте,

не получается прокинуть видиокарту через KVM

в загрузчик добавил опции:

i915.enable_hd_vgaarb=1 intel_iommu=on vfio_iommu_type1.allow_unsafe_interrupts=1 pcie_acs_override=downstream

выполняю:

qemu-system-x86_64 -enable-kvm -M q35 -m 1024 -cpu host \
-smp 6,sockets=1,cores=6,threads=1 \
-bios /usr/share/qemu/bios.bin -vga none \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \
-device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \
-device vfio-pci,host=02:00.1,bus=root.1,addr=00.1

и выдаёт ошибку:

qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: error, group 1 is not viable, please ensure all devices within the iommu_group are bound to their vfio bus driver.

как я понял это изза того что в группе 1 состоят несколько устройств и чтоб всё работало нужно их все прокинуть

чтоб это обойти есть опция pcie_acs_override=downstream

которая не помогает..

- ASRock FM2A88M Extreme4+
- AMD A10-6700 [Radeon HD 8670D]       — host
- SAPPHIRE Radeon HD 7790 1GB          — guest 
- linux-3.17.1-gentoo-r1
- qemu-kvm

ядро загружается вот так:

iommu=pt iommu=1 ivrs_ioapic[5]=00:14.0 pci-stub.ids=1002:665c,1002:0002

[    0.014323] [Firmware Bug]: AMD-Vi: IOAPIC[5] not in IVRS table
[    0.014328] [Firmware Bug]: AMD-Vi: No southbridge IOAPIC found
[    0.014329] AMD-Vi: Disabling interrupt remapping

[    0.323963] AMD-Vi: Found IOMMU at 0000:00:00.2 cap 0x40
[    0.323965] AMD-Vi: Extended features:  PreF PPR GT IA
[    0.323968] AMD-Vi: Interrupt remapping enabled
[    0.324116] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:14.0 domain=0x0000 address=0x000000fdf800ff98 flags=0x0008]
[    0.324191] AMD-Vi: Initialized for Passthrough Mode

qemu-system-x86_64 -enable-kvm -M q35 -m 4096 -cpu host -smp 4,sockets=1,cores=4,threads=1 \
-bios /usr/share/qemu/bios.bin -vga qxl \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \
-device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \
-drive file=windows.img,id=disk,format=raw -device ide-hd,bus=ide.0,drive=disk

в GPU-Z: http://i.imgur.com/77jFbUO.png

в Catalyst: http://i.imgur.com/Yr4e1Ps.png

Запускать -bios /usr/share/qemu/bios.bin -vga none и смотреть через HDMI не получается, очевидно нет сигнала, а -vga qxl работает, винду вижу в открывающемся окне.

Естественно, графика притормаживает, в GPU-Z видно, что проброшено не полностью, но можно ли это считать частичным успехом проброса и как довести проброс до ума?

Чтобы определялся полностью, а не как обрезок (Microsoft Basic Display Adapter), кстати сенсоры (только GPU FAN) оно тоже читает.

Кастую господ Novell-ch, NeverLoved, darkenshvein, devl547, andrew667.

Здравствуйте,

хочу пробросить видиокарту в гостя под kvm

сделал всё как тут https://bbs.archlinux.org/viewtopic.php?id=162768

в итоге:

qemu-system-x86_64: -device vfio-pci,host=03:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: error no iommu_group for device
qemu-system-x86_64: -device vfio-pci,host=03:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device initialization failed.
qemu-system-x86_64: -device vfio-pci,host=03:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device 'vfio-pci' could not be initialized

железо vt-d поддерживает ( под xen прокидывалось всё )

в /sys/kernel/iommu_groups пусто

grep -i vfio  /boot/.config
CONFIG_VFIO_IOMMU_TYPE1=m
CONFIG_VFIO=m
CONFIG_VFIO_PCI=m
CONFIG_VFIO_PCI_VGA=y
CONFIG_KVM_VFIO=y

cat /proc/cmdline
BOOT_IMAGE=Linux-KVM ro root=801 pci-stub.ids=1002:6818,1002:aab0

Сюда можно и нужно писать, какими бы ключами вы бы хотели поделиться. Steam, desura, всякие бандлы и т.д.

Замечания:

• рекомендуется минимально возможное обсуждение без флуда, холиваров и оффтопа
• после переполнения эта тема будет закрыта для комментирования, вместо нее будет создана новая
• предыдущая тема: Обмен ключами, скидками и прочими игровыми радостями (2)

Доброго всем вечера.

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

Нужна максимально тихая (насколько это возможно для механики), с тактильным откликом (насколько я понял, надо смотреть Cherry MX Brown и Cherry MX Clear). В случае с символами на клавишах желательна либо подсветка, дабы было удобно пользоваться в темноте, либо наоборот, отсутствие символов, дабы я наконец-то освоил слепую печать. Так же крайне желательна подставка под руки.

Нашёл обалденный сайт, где можно выбрать механизм клавиш, кольца для уменьшения громкости клика, раскладку и даже раскрасить клавиатуру, но доставка там по совершенно невменяемой цене.

На какие варианты, поставляемые в россию стоит обратить внимание?

Сначала я назвал эту тему «История появления 3D-ускорения в открытых драйверах видеокарт», но 95% текста посвящено закрытым драйверам. Для открытых драйверов нужно было проделать огромную работу и новости выходили редко, наверное поэтому я запомнил мало новостей. В итоге получился исторический текст о событиях, связанными с драйверами видеокарт для Linux и FreeBSD, который, я надеюсь, окажется кому-нибудь интересным. Принимаются исправления, текст можно копировать себе, перерабатывать. Я не стал писать те новости, которые меня не заинтересовали и которые я не запомнил, а также все даты открытия очередной части спецификаций чипсетов ATi/AMD, и дат добавления очередных версий OpenGL. Последнее в драйверах для Linux появляется сразу после появления новой версии OpenGL. Все эти события я узнал благодаря периодическим заходам на сайты linux.org.ru и opennet.ru с 2008 по 2012 год. Текст разбит на части, следующие части - в первых комментариях к теме.

Предыстория.

До 2008 года всё было просто (да и в мире железа тоже всё было просто, Intel/AMD, NVIDIA/ATi). Есть открытые драйверы видеокарт, которые имеют функцию 2D-ускорения, и позволяют выставлять большие разрешения экрана. Они поставляются вместе с дистрибутивом Linux. И есть закрытые драйверы видеокарт, драйверы от производителя, которые отличаются от открытых только наличием 3D-ускорения.

1). Открытый драйвер для видеокарт NVIDIA называется nv. Написан самой NVIDIA.

2). Открытый драйвер ati написан непонятно кем. Пожалуйста, скажите, кем он написан, помогала ли компания ATi написать его, и если нет, то почему он тогда называется открытый, а не свободный? Не застал Linux в то время.

1а). Официальный драйвер NVIDIA. Поддерживает ядра Linux версии 2.4 и 2.6 (а также FreeBSD и Solaris), XFree86 и Xorg. Поставляется в виде run-файла, который универсален для всех дистрибутивов Linux для архитектур процессора x86 и x86_64. Есть 3 ветки драйвера, 7x.xx, 9x.xx и текущая, 100.xx. Поддерживается только текущая (видеокарты GeForce 6-7), а для остальных иногда выпускаются обновления, добавляющие поддержку новых версий ядре Linux и X-серверов.

Очень мало ошибок. Скорость работы 2D и 3D та же, что и в Windows. Есть возможность разгона и регулирования скорости вращения кулера. Есть поддержка SLI. Единственный недостаток драйвера NVIDIA для Linux - не поддерживается 3-way SLI - в остальном полная идентичность Windows-версии (я пишу о том времени, когда GeForce 8 с рядом новых технологий ещё не вышел).

2а). Официальный драйвер ATi. Поддерживает Linux x86 и x86_64, не знаю насчёт 2.4 и XFree86. Один раз была прекращена поддержка старых серий видеокарт - драйвер версии 8.28.8 от 2006 года. Пользователям этих видеокарт оставалось пользоваться только 2D-ускорением, потому что в закрытый драйвер не добавлялась поддержка новых версий X-сервера и ядра Linux. А значит, ветки драйвера две: 8.28.8 и текущая.

Очень много ошибок. Они проявляются во всём: повседневная работа, проиггрывание видео, медленное 3D с искажениями (артефактами), отсутствие функций 2D и 3D-ускорений, полноэкранные приложения, переключение в виртуальный терминал, спящий режим, огромные задержки (рекорд - 5 месяцев) добавления в драйвер поддержки новых видеокарт, ядер Linux и X-сервера.

У меня создаётся впечатление, что создатели драйвера были программистами низкого класса, они писали раздутый код с большим количеством ошибок и неточностей, по принципам «лишь бы скомпилировалось» и «лишь бы заплатили». Хорошо что когда я попробовал Linux, у меня была NVIDIA - а если бы была ATi, остался бы я на нём? На форумах можно было увидеть такую аналитику, «в мире открытого ПО тысячи программистов высокого класса. Но они бессильны перед видеоадаптерами от ATi: реверс-инжиниринг драйверов для таких устройств, как видеокарты, очень сложен. Вот открыли бы ATi спецификации - и сообщество сразу бы написало драйвер получше, чем у них!».

Вот такая предыстория. А теперь история.

2006 год.

1). Компания AMD приобретает компанию ATi. Качество драйверов для Linux начинает расти. В среде компьютерных специалистов появляется неопределённость. Раньше были фанаты:

1. Процессоров Intel и видеокарт NVIDIA
2. Процессоров Intel и видеокарт ATi
3. Процессоров AMD и видеокарт NVIDIA
4. Процессоров AMD и видеокарт ATi

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

2). Начинается разработка открытого драйвера nouveau, попытки добавить в открытый драйвер nv 3D-ускорение путём реверс-инжиниринга закрытого драйвера.

3). Поддержка видеокарты GeForce 8 появилась, по традиции, сразу после выхода этих видеокарт: 2D-ускорение, 3D-ускрнеие, разгон. Новые технологии CUDA, PureVideo и PhysX, задерживались. Также задерживалось появление поддержки 2D-ускорения для GeForce 8 в открытом драйвере nv, но тогда это ещё никого не волновало: ничего, добавят потом.

2007 год.

1). Свершилось открытие первой части спецификаций видеокарт ATi. Сообщество пользователей Linux ликует! В то, что это действительно случилось, трудно поверить! Разумеется, основная цель этого действия то, что это позволит улучшить работу ПО на видеокартах ATi, а не создание открытого видеодрайвера для Linux, но и для Linux это огромный подарок! Те, кому не терпится получить хороший драйвер для видеокарты ATi интересуются, почему открыли спецификации, а не готовый исходный код драйвера.

2). В первую же неделю после этого появляется открытый видеодрайвер RadeonHD, отличие которого от ati - начальная поддержка 3D-ускорения. После тестирования она была перенесена в ati. Разработчикам RadeonHD давали очереные части спецификаций раньше, чем сообществу, под условиями неразглашения. В RadeonHD появлялись новые функции, и ускорение старых, раньше, чем в ati. Кроме того, ati был стабильнее. Над открытым драйвером трудятся несколько сотрудников компаний AMD и Novell в режиме полного рабочего дня.

3). Появление NVIDIA CUDA одновременно для Windows и Linux. Логично: учёные вряд ли станут держать вычислительные кластеры под Windows. И сразу после появления CUDA во всех новостях о релизах драйвера NVIDIA появляются тонны исправлений CUDA, и так несколько лет. Года два как утихло, наверное. Также странным является способ распространения NVIDIA CUDA для Linux. Для Windows это два файла, 32 и 64-битная программа установки. Для Linux это 12 файлов, для 6 популярных дистрибутивов Linux! И ладно бы ещё были пакеты в родном для дистрибутива формате, RPM/DEB! Но нет: каждый установщик имеет формат run. Странно: run-файл драйвера один для всех дистрибутивов Linux, хотя сделать один файл для всех версий ядра Linux и X-сервера непросто. А здесь их 6! Впервые пользователи Linux столкнулись с таким отношением компании NVIDIA к себе. Список поддерживаемых дистрибутивов Linux. Технология NVIDIA PureVideo задерживается.

Сегодня ситуация не изменилась. Существует библиотека NVIDIA Cg, для игр, есть версия для Linux. Так даже её теперь распространяют не в tar.gz, а в RPM/DEB/tar.gz, а NVIDIA CUDA 4.2 - в 6 run-файлах.

Захват видео и аппаратное его сжатие на видеокарте в линуксе не такая и сложная штука, методом проб и ошибок нашел оптимальные параметры, плюс возможность звук записывать. Любителям писать всякие скринкасты или ролики игр пригодиться.

http://www.gearsongallium.com/?p=1238

Еще очень порабовало то что vaapi и omx могут работать вместе, одновременно. Достаточно omx запустить через DRI_PRIME, воистину мощь линукса не знает границ.

Как итог vaapi поумолчанию дает явно больший битрейт, разница в размере итоговых файлых почти 100%, хотя качество как по мне одинаковое.

http://www.gearsongallium.com/?p=1252

взял тут себе N8 на замену полумёртвому Desire X.

знал, на что иду: разработка Symbian и приложений под него прекращена, полно отзывов, что тормозит буквально весь интерфейс, да и вообще пользоваться невозможно..

так вот: хожу с этим аппаратом уже 2 недели, и вот что я скажу: этот динозавр лохматого 2010 года выпуска, с 600мгц процессором и 256мб(!) памяти вполне может потягаться с нынешними бюджетными андроидофонами.

автономная работа: 3 дня *активного* использования. 3 часа сёрфинга интернета, 3 часа музыки, 1 час разговоров по 3g - в таком режиме телефон садится к концу 3 дня.
ovi store - очень удобные покупки приложений. можно оплачивать прямо со счета любого мобильного. гуглплей умеет только в билайн, и то у меня не получилось.
usb otg, hdmi - в смартфон можно воткнуть USB-флешку с HD-фильмом и вывести всё это дело на ТВ по HDMI. без конвертаций и установки всяких MX-плееров.
камера - 12мп, ксеноновая вспышка. заруливает многие современные смарты. пример ночного фото.

есть еще всякие мелкие плюшки, типа компаса и FM-трансмиттера (говорят, удобно выводить музыку на fm-приёмник в машине) - но я так и не нашёл им применения.

ну и да, недостатки тоже есть:

ИГОР-ТО НЕТ. из игор, есть разве что птицы да всякая фигня типа дурака-покера-судоку — но мне это не важно, в принципе:)
штатный софт - дефолтный браузер - просто убожество. дефолтная клавиатура - еще хуже (чтобы переключить язык, нужно заходить в меню). дефолтный плеер не умеет во flac. дефолтный калькулятор совсем уж простенький. ну и так далее.
256 мб памяти - запустить ЗЛЫХ ПТИЧЕК рядом с оперой с ~10 вкладками, jabber-клиентом, плеером, смотрелкой картинок и SMS-сообщениями не получится - будут лагать.

короче - годный телефон, годная ОС. не понимат, зачем Nokia её закопала. печалька. :(

>>> Просмотр (1080x1280, 277 Kb)

в обшем щупать e4defrag стал давно, на стоковом ядре суси 11.2 (31.5 вроде) он отлично работал, но стоило обновить ядро до более новой версии, как он переставал работать, выводя на всех файлах что-то типа

[6/31] "/root/Mail"
        File is not regular file                [ NG ]
 [7/31]/root/defrag-09-online-defrag-command.c:    0%

[882/3185] "/var/lib/rpm"
        File is not regular file                [ NG ]
[883/3185]/var/lib/rpm/Filedigests:     100%  extents: 32 -> 3  [ OK ]
[884/3185]/var/lib/rpm/Installtid:      100%  extents: 10 -> 1  [ OK ]
[885/3185]/var/lib/rpm/Dirnames:        100%  extents: 22 -> 1  [ OK ]

НЕ РАБОТАЕТ!

Прочитал новости, что начиная с linux 3.10 в ядро входят открытые драйвера для радеонов с поддержкой UVD. Обновился до 3.10, поставил libvdpau, libva, libva-vdpau-driver, прописал export VDPAU_DRIVER=r600, export LIBVA_DRIVER_NAME=vdpau. Запускаю vainfo, а там:

libva info: VA-API version 0.34.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'vdpau'
libva info: Trying to open /usr/lib/dri/vdpau_drv_video.so
libva info: Found init function __vaDriverInit_0_33
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.34 (libva 1.2.1)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.4
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD

А где же поддержка H.264 и MPEG-4 ??? Плейеры соответственно тоже не декодируют через видюху.

А ещё в dmesg пишет:

[drm] initializing kernel modesetting (PALM 0x1002:0x9806 0x1043:0x84E3).
[drm] Loading PALM Microcode

хотя вот здесь http://wiki.gentoo.org/wiki/Radeon написано, что для моей видюхи (Radeon HD 6320) он должен загружать прошивку SUMU. Глюк железа или ядра? На других дистрах (ubuntu 13.04, 13.10) тоже пишет PALM.

Кто подскажет, что я делаю не так? У кого-нибудь получилось запустить на радеоне аппаратное декодирование через vdpau?

Дистр: ArchLinux Девайс: Asus EEE PC 1215B

Делаю комп с большим числом беспроводных сетевух. Каждую сетевуху надо отдать отдельным устройством виртуальной машине. Для виртуалки использую KVM. Мать gigabyte p75-d3 и проц i5-3550. Все чего удалось мне добиться - это проброс почему-то только одного чипсетного USB контроллера (туда подключена сетевуха) + устройства на PCI-E. Пробовал пробрасывать отдельные внешние PCI устройства (сеть, звук, контроллер usb) - не пашет (не стартует виртуfлка - пробовал в centos6, fedora 19, ubuntu 12.04). Не пашут и пробросы usb-устройств. Почему? Пока могу лишь 3 интерфейса отдать гостям (2 pci-e слота и встроенный usb-контроллер), а хостовой машине остается четвертый. Хочу услышать ваши истории успеха на системах интел и амд.

P.S. мать официально не поддерживает vt-d.

Дана мамка asrock h61m-itx c 2.20a биосом и проц i5 3330, видюха встроенная в проц и hd7790.
http://savepic.net/3977706.htm
Все встало с пол пинка, видеокарта пробросилась без проблем в 8.1 винду, покрутил хевен, все очень быстро, но дальше пошли косяки.

!) Не грузиться винда в нормальном режиме, нужно только с пониженым разрешением, и то не всегда срабатывает, ощущение что идет конфликт между мониторами, он у меня один и я переключаю в его настройках с dvi на hdmi, может винда не находит монитор на внешней и перегружается. Попробую другу винду или вообще xen.
2) Нет звука, дрова на звукавухи просто не находит, может легче прокинуть юсб звук?

Но в целом если бы не эти два косяка, накатить на ссд винду, и никакие вайны не нужны.

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

• XEmbed-трей (legacy трей):
  Самый первый стандарт трея в UNIX-системах, основан на технологии встраивания в X11. Великая суть: приложение создаёт окно-значок и встраивает в нужную область, просто и сердито.
  
  Недостатки:
  • Контролировать значок может только само приложение;
  • Не учитывается, что областей трея может быть несколько (на нескольких мониторах);
  • Привязано к X Window System.
  Достоинства:
  • Поддерживается почти везде (кроме Unity и WingPanel (Pantheon));
  • Поддерживают почти все приложения.
  Не самый плохой стандарт, вполне можно считать чем-то вроде UNIX-way, но сейчас как-то отжило своё (не UNIX-way, а XEmbed-трей).
  
  
• SNI-трей (org.freedesktop.StatusNotifierItem):
  Стандарт, впервые представленный в KDE SC 4.4 для решения проблем с XEmbed-треем.
  Взаимодействие приложения с областью трея происходит через dbus, при этом сам значок рисуется областью трея, и при желании область может значок заменять на другой и т.д. Например, в KDE сейчас стандартные приложения типа KMix в трее имеют белые значки, которые делаются на уровне Plasma, а не на уровне самих приложений.
  Хоть StatusNotifierItem и был представлен проектом KDE, наибольшую известность получил в Ubuntu, ибо… в KDE особо не видно разницы :-).
  В свою очередь, в Ubuntu 10.04 были продемонстрированы библиотека libappindicator и ayatana-индикатор indicator-application, которые и реализуют SNI-трей. Собственно, в Ubuntu стал известен не столько StatusNotifierItem/appindicator, сколько сами по себе ayatana-индикаторы, но разработчики приложений таки опираются именно на appindicator.
  Также в Ubuntu есть плагин к трею Qt4 sni-qt, который все Qt4-приложения переводит на SNI-трей, но главная проблема — нужен патч kubuntu_14_systemtrayicon.diff, который так и не попал в upstream Qt4 (в Qt5 таки попал, но сам sni-qt ещё не адаптирован для него).
  
  Недостатки:
  • Меньшая поддержка, нежели у XEmbed-трея;
  • Меньшая поддержка среди приложений, что, впрочем, сильно улучшается со временем из-за того, что Unity не поддерживает XEmbed-трей.
  Достоинства:
  • Стандарт freedesktop.org;
  • Поддерживается Unity, MATE, Xfce (через indicator-application);
  • Поддерживается WingPanel, Cairo-Dock;
  • Поддерживается GNOME Shell (через расширение, если оно не отвалилось, опять);
  • Не привязано к какому-либо графическому серверу (да и что может помешать приложению из XWayland по dbus слать значок к области трея в Wayland :3?);
  • Гибкость и масштабируемость (отдельно учитывать в стандарте многомониторные конфигурации даже не нужно, всё отлично работает само по себе);
  • Поведение значка определяется самой областью трея.
  Можно сказать, это и есть идеальный трей, стандарт, на который и следует опираться, если не хочется оказаться за бортом (хотя бы вместе с X.Org'ом). Тем более, libappindicator вполне умеет рисовать и XEmbed-значки, если нет области SNI-трея.
  
  
• Ayatana-индикаторы:
  Одновременно с indicator-application в Ubuntu 10.04 были представлены и сами индикаторы в рамках проекта Ayatana.
  Сказать — зачем, как-то особо не получается, все индикаторы (indicator-sound, indicator-bluetooth и т.д., да даже indicator-appmenu) вполне можно было оформить и в виде StatusNotifierItem.
  Большинство компиляций индикаторов, кстати говоря, даже содержат в большей степени appindicator'ы, нежели ayatana-индикаторы, ведь создаватели компиляций всё равно разницы не видят.
  
  Недостатки:
  • Не так и много дистрибутивов внесли индикаторы в свои репозитории (в openSUSE их нет, в Debian они есть);
  • Больше похожи на прослойку между Unity, MATE, Xfce и appindicator; в общем, не нужны;
  • Индикаторы зависят от Gtk3 или Gtk2 (причём, не все индикаторы имеют поддержку Gtk2; например, indicator-appmenu не имеет);
  Достоинства:
  • Поддерживаются Unity, MATE (через официальный mate-indicator-applet), Xfce (через xfce4-indicator-plugin);
  • Само собой, гибкость на уровне SNI-трея;
  • Привязки к графическому серверу также нет (ayatana-индикаторы, скоро на всех Mir'ах страны!).
  Малонужная штука, но из-за того, что indicator-applet (который и был форкнут в mate-indicator-applet) и xfce4-indicator-plugin были написаны в рамках Ubuntu… в общем, если хочется SNI/appindicator на MATE и Xfce (а кто его не хочет :3?), то и ayatana-индикаторы тоже нужны.

Есть те кто используют xen и следит за его развитием, как там сейчас ситуация с nvidia passthrough, за 3 года совсем никаких изменений и все также глухо?

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

Ну и еще интересно что там эмуляцией звуковой карты, она только через OSS (/dev/dsp) может работать? Его же несколько лет назад выпилили в пользу alsa, где я его им достану.