В /var/log/ что-нибудь есть?

Что-то подзабыл: репы rpmfusion отключать нужно когда делается system-upgrade?

вот что выводит opera-stable-58.0.3135.107-0.x86_64

Vbox 6 научился графику ускорять хорошо (как для VM). Но virgl пилят и для qemu/kvm и по идее он уже тоже работает с mesa, но только не на моей невидия и проп драйвере.

А чего ты мучаешься? Поставь себе flatpak через него ставь и обновляй.

Говорят приложения дольше запускаются на flatpak

хорошо, как его установить в систему и откуда качать? у меня зборка RFRemix 29

хорошо, как его установить в систему и откуда качать? у меня зборка RFRemix 29

Говорят приложения дольше запускаются на flatpak

это не самая большая проблема флатпака

dnf install flatpak

А чего ты мучаешься? Поставь себе flatpak через него ставь и обновляй.

Запускай через sdl а не spice, и вс работает.

В virt-manager не получится ведь и нужно делать через virsh?

Opera нет во flathub.

это не самая большая проблема флатпака

Подменил я крч timestamp на более новый у апдейта, и отправил книжку обновляться. Посмотрим, что будет. P.S. Всем спасибо за то, что не проигнорировали меня :) P.S.S. Не буду продолжать засирать чат книжкой, так что, я напишу после, получилось ли это у меня победить, или нет.

@flash20711 — VirtualBox-kmod-6.0.4-3.fc29 http://koji.rpmfusion.org/koji/buildinfo?buildID=10719

Докладываю. После перепрошивки на ту же самую версию всё работает, без каких либо намёков на какие-либо глюки. Только вот теперь другой вопрос. Каким образом у меня появились глюки, и появятся ли они снова? 🤔 P.S. Свой оффтоп прекращаю.

Говорят приложения дольше запускаются на flatpak

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

Кеши... Я их там видел, но на пару десятков метров. Старые прочитанные книжки удаляю, и храню около 10 штук постоянно. А то, когда много непрочитанных книг, аж глаза разбегаются 😁 А по поводу ошибок чтения, я даже второй раз дамп сливал после перепрошивки, на всякий. Ошибок чтения не было, как и какого-либо замедления при чтении.

Значит, кто-то обманул с версией прошивки, которая стояла до текущей. И либо ее кто-то криво патчил, либо кто-то поленился эти патчи накатить или протестировать, а чтобы спрятать косяк подписал резлизной версией

/report Гугл пришел воровать наши переписки

Хз. Когда я её покупал, уже были апдейты на сайте. Так я примерно обновился два раза, и при этом, я ни разу ничего не сбрасывал (вроде).

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

так вот кто сливает все)

Потому что рантаймы должны быть загружены в память. Что-то вроде shared libs Однако, самая большая проблема — именно эти самые рантаймы, котоыре будут вечно висеть в памяти, даже если аналоги требуемых библиотек у тебя уже есть в /usr/lib

Однако теперь еще придется пояснить в чем заключается самая большая проблема, кроме как не понимания. Переводить лень, но одного поста Матиаса должно быть достаточно: Identical files between different runtimes and apps in the same installation are hardlinked, so they will get deduplicated by the kernel. That is not true between runtimes/apps and the host system. But any duplications there would be considered accidental, it is expected that the host system may have wildly different versions, say GNOME 3.30 apps on RHEL7...

Ядро может в дедупликацию? Не знал.

Тут половина не знает что может flatpak, зато любят больше остальных просвещать.

Ну, я flatpak юзаю за компом. Телега к примеру, запускается секунд так 10...

Банить его что ли?

Однако теперь еще придется пояснить в чем заключается самая большая проблема, кроме как не понимания. Переводить лень, но одного поста Матиаса должно быть достаточно: Identical files between different runtimes and apps in the same installation are hardlinked, so they will get deduplicated by the kernel. That is not true between runtimes/apps and the host system. But any duplications there would be considered accidental, it is expected that the host system may have wildly different versions, say GNOME 3.30 apps on RHEL7...

Тут половина не знает что может flatpak, зато любят больше остальных просвещать.

В мой огород камень? хд Тогда прошу прощения

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

Он имеет ввиду, что при дедупликации либ из флатпака и хостовой системы, может случиться все что угодно? Никогда не пытался разобраться с работой ядра, но вот здесь уже интересно

а что будет в лини, когда корень забьётся логами?

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

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

Он пишет что любая дубликация это будет случайность. Можно расценивать как баг. Чтобы убедиться что нет никаого повышенного потребления RAM достаточно уже сейчас скачать Silverblue и убедиться что RAM оно не потребляет в два раза по сравнени с обычной системой. Также там нет такой проблемы как долгий холодный старт т.к. рантаймы и всё добро уже подгружено. То есть нет той проблемы о которой ты пишешь.

Получается, в Silverblue все flatpak рантаймы представляют собой либы на хосте, из-за чего дедуплекация, а точнее механизм разделяемых библиотек, будет корректно работать?

Предлагаю его не банить

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

@erzentd чо как с вашим временем доклада?

Я перечитал и понял, что мы о несколько разных вещах говорили Про Silverblue я полнял, там рантаймы в принципе являются частью системы, из-за чего нет такого дикого съедания памяти при использовании флатпак-приложений Но сначала, когда ты скинул пост из блога человека из silverblue team, я подумал, что и в обычном workstation рантаймы могут являться частью системы, из-за чего при использовании флатпак-приложений либы будут использоватсья системные, после дедупликации, я даже запутался Но ты, как я понял, имел ввиду, что даже при использовании несколькими фалтпак-приложениями одного рантайма, он не будет подгружаться статически для каждого из приложений, а будет использоваться как и обычные разделяемые библиотеки Все правильно, или я где-то опять недопонял?