единственный бинарный установочный файл когорый на сайте циски был такой и скачал

В сторону увеличения конечно

Осталось пофиксить проблемы виртуалок, подмана, ostree. Дело за малым. - https://github.com/containers/libpod/issues/6563 - https://github.com/containers/libpod/issues/6563

Виртуалки, подман, и флатпаки работают. Но да, silverblue не хочет работать с btrfs. Проверял в виртуалке.

Подскажите как в nvidia settings добавить prime в Fedora 32?

Quadro P3200 Mobile

Не уверен насчёт Quadro, но для новых чипов с драйвером 440.xx ничего не надо делать, prime offload работает из коробки.

Спасибо. Просто на убунте можно было принудительно выбрать видеокарту через настройки

Проприетарные драйверы стоят? Если да, покажи вывод xrandr --listproviders

Providers: number : 2 Provider 0: id: 0x47 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 5 associated providers: 0 name:modesetting Provider 1: id: 0x2ba cap: 0x0 crtcs: 0 outputs: 0 associated providers: 0 name:NVIDIA-G0

name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4 server glx extensions: GLX_ARB_context_flush_control, GLX_ARB_create_context, GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, GLX_ARB_multisample, GLX_EXT_buffer_age,

по идее должна работать встроенная, т.к. никакой нагрузки нет

Дискретная и интегрированная с prime offload не переключаются эксклюзивно, а включаются по необходимости для отдельных приложений (типа как в винде). __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia делает ровно это - заставляет программу (glxinfo в данном случает) использовать дискретную видуокарту.

в винде, если не ошибаюсь, вшит список приложений в драйвер для дискретной карты, а тут как определяется необходимость?

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

в гноме отдельное контекстное меню есть для запуска на дискретном видео

и там же решение "Rolling back intel-microcode from 3.20191115.1ubuntu018.04.2 to 3.20180312.0~ubuntu18.04.1, and apt-mark hold intel-microcode seems to have fixed the problem for now." Как откатить этот микрокод на федоре?

Тебе не повезло, у нас как раз один чел, хорошо знакомый с ноутбуками, fwupd и вот этим всем, недавно свалил из Телеги.

(

аккаунта нет. Я так понимаю это интел на рукожопил?

Кажется, я начал находить след этой проблемы Возможно, все дело в fprintd.service, который в systemd отвечает за работу с устройствами, добавляющих авторизацию через отпечаток пальца. Кусок лога: Jun 24 16:35:37 DEV94 systemd[1]: Starting Fingerprint Authentication Daemon... Jun 24 16:35:37 DEV94 systemd[1]: Started Fingerprint Authentication Daemon. Jun 24 16:36:07 DEV94 systemd[1]: fprintd.service: Succeeded. Jun 24 17:33:14 DEV94 systemd[1]: Starting Fingerprint Authentication Daemon... Jun 24 17:33:14 DEV94 systemd[1]: Started Fingerprint Authentication Daemon. -- Reboot -- Jun 24 17:33:51 DEV94 systemd[1]: Starting Fingerprint Authentication Daemon... Jun 24 17:33:51 DEV94 systemd[1]: Started Fingerprint Authentication Daemon. Jun 24 17:34:22 DEV94 systemd[1]: fprintd.service: Succeeded. Как раз перед ребутом можно обратить внимание, что данный сервис не перешел в состояние success, о чем свидетельствует отсутствующее сообщение об этом Саму проблему со входом я обнаружил в 17:33 и сразу же сделал хард ребут Попробую отключить этот сервис и посмотреть, как ведет себя экран разблокировки в принципе

Отличная находка же. Зарепортишь баг?

делаю по этой статье https://www.altlinux.org/Rutoken#%D0%A0%D1%83%D1%82%D0%BE%D0%BA%D0%B5%D0%BD_S

Почему?

У тебя альт линукс?

нет, fedora

И какого чуда ты ожидаешь?)) Эта поделка для работы требует libusb 0.1.7, который еще аж в шестом рхел поставлялся. Тебе, очевидно, придется собрать/скачать эту библиотеку и подкладывать к ПО, которое они там поставляют А еще лучше — прокинуть эту поделку в виртуалку и работать с ней там. Туда хоть винду ставь, хоть альт

Ты ведь про Silverblue спрашиваешь, да? Если честно, то я уже не помню, почему система не грузилась, но точно помню - @Artem4 уже скидывал баг-репорт.

И даже тогда давно из под федоры я мог использовать rutoken s из под федоры, кажется

Т.е. из под федоры ключ с токена не вытащить?

Там, если ты обратил внимания, рутокен с для работы требует собственный "драйвер", который в свою очередь требует очень старые версии библиотек, которых уже давно нет в федора

Там не нужен, по идее, драйвер. Должно работать через эмуляцию pkcs11 поверх pkcs15 средставми opensc.

драйвер для токена установлен - ifd-rutokens-1.0.4-1.x86_64

Зачем? Без него pkcs15-tool токен не видит?

Ну я кстати сейчас этот драйвер удалил и ошибка не появляется

он теперь говорить , что токен пустой

А ты его инициализировал?

я его покупал

Я не говорил, что считаю, что ты бесплатно токен получил.

не, я имею в виду покупал токен с ЭЦП. т.е. он не пустой. я с него когда-то давно экспортировал ключ

в УЦ импортировали

под вендой при помощи КриптоПро доставал pfx

Значит криптопрой же и экспортируй сейчас, если этот те же ключи. У тебя токен является pkcs15 хранилищем. Opensc хранит на нем данные, выставляя наружу pkcs11-интерфейс. То же самое делает и криптопро, но формат контейнеров на pkcs15 у cryptopro и opensc может не совпадать.

Ты можешь попробовать глянуть, что за данные там лежат через pkcs15-tool или opensc

как это сделать?

Дата 2019, не знаю насколько всё это актуально на сегодняшний день. Но там не только это, много чего еще сильно медленнее: https://www.phoronix.com/scan.php?page=article&item=linux-50-filesystems&num=2

tl;dr, I can make btrfs look awesome, and I can make it look stupid. It depends on your workload, but generally speaking a normal Fedora user's workload is going to feel the same regardless of the file system. Phoronix is widely ignored and a joke to the fs development community. Facebook deploys latency sensitive workloads across millions of machines with btrfs. We do not accept latency regressions, our threshold for performance regressions depends on the workload, but is generally under 5% and usually 1%. That's not to say that btrfs is faster always, but that it depends on your workload. The overwrite case is clearly a loser almost always, unless you use the nocow file attr on those files. Reads can sometimes have higher latencies, but that's the price you pay for checksumming. Inside Facebook we run with compression on everywhere, which reduces the IO sizes both ways, which reduces the overhead to the point where it's clearly faster than either xfs or ext4. That's not the sole reason we use compression, but it's a nice way to get around the cost of checksumming. I'm currently knee deep in a performance discrepancy issue that WhatsApp has discovered. However I have to get the file system to the point where it has > 1 TiB of metadata (not data, actual metadata) before I see a difference between btrfs and xfs for that workload. Before that point it's not even a competition, btrfs wins hands down. And even then we're talking about maximum latencies, so every once and a while btrfs appears to go out to lunch for around 500ms for unknown reasons. These are the sort of performance investigations that btrfs is having right now, edge cases under specific workloads. Generally speaking it's on par if not faster than anybody else, and the cases where it's slower there's a clear trade off being made for checksumming. Thanks, Josef

tl;dr, I can make btrfs look awesome, and I can make it look stupid. It depends on your workload, but generally speaking a normal Fedora user's workload is going to feel the same regardless of the file system. Phoronix is widely ignored and a joke to the fs development community. Facebook deploys latency sensitive workloads across millions of machines with btrfs. We do not accept latency regressions, our threshold for performance regressions depends on the workload, but is generally under 5% and usually 1%. That's not to say that btrfs is faster always, but that it depends on your workload. The overwrite case is clearly a loser almost always, unless you use the nocow file attr on those files. Reads can sometimes have higher latencies, but that's the price you pay for checksumming. Inside Facebook we run with compression on everywhere, which reduces the IO sizes both ways, which reduces the overhead to the point where it's clearly faster than either xfs or ext4. That's not the sole reason we use compression, but it's a nice way to get around the cost of checksumming. I'm currently knee deep in a performance discrepancy issue that WhatsApp has discovered. However I have to get the file system to the point where it has > 1 TiB of metadata (not data, actual metadata) before I see a difference between btrfs and xfs for that workload. Before that point it's not even a competition, btrfs wins hands down. And even then we're talking about maximum latencies, so every once and a while btrfs appears to go out to lunch for around 500ms for unknown reasons. These are the sort of performance investigations that btrfs is having right now, edge cases under specific workloads. Generally speaking it's on par if not faster than anybody else, and the cases where it's slower there's a clear trade off being made for checksumming. Thanks, Josef