Vlákno názorů k článku
VirtualBox 7.0 přináší plně šifrované virtuální stroje a vylepšenou podporu Direct3D od AsciiWolf - Stále je pro provoz VirtualBoxu nutné (přes DKMS)...

Stále je pro provoz VirtualBoxu nutné (přes DKMS) kompilovat custom kernel moduly nebo je vše již v jádře? VirtualBox jsem používal naposledy před pár lety a tohle byl důvod, proč jsem přešel na řešení založené na KVM.

Stále... :-(
https://www.virtualbox.org/manual/ch02.html#externalkernelmodules

ani keby to nebolo potrebné tak nevidím dôvod používať VirtualBox namiesto KVM. Nie len že KVM je výrazne výkonnejší a má lepšiu integráciu do Linuxu, ale má to i lepšiu konfigurovateľnosť a featury navyše.

duvod proc by nekdo chtel pouzivat VB vidim 2:
1. je na to zvyklej z Windows a jeste virt-manager nezkusil
2. chce pouzivat "bezesvej rezim" (okna z virtualizovaneho pocitace jsou umistovane na plochu hostitelskou)

ad 1. - Taky může přecházet mezi Windows a Linuxem, ale spouštět stejné virtuálky. Pak to není otázka "zvyku", ale nalezení nejméně bolestivé cesty.
ad 2. - Tahle výborná vlastnost mi v Linuxu funguje omezeně, ve Windows aktuálně vůbec. Nějak si nesedly ovladače grafiky... ;o(

Třeba proto, že potřebuje 3D akceleraci ve Windows guestovi... (pokud se něco v hodně nedávné době nezměnilo, tak pro Win neexistovaly drivery a přes SPICE nebo jak se to jmenovalo to nefunguje úplně plnohodnotně...)

A co presne je spatneho na DKMS? Vzdyt to elegantne resi spoustu problemu, kdy se kernelovy modul realne sam znovu aktualizuje treba pri updatu kernelu a od uzivatele zadna specialni interakce vlastne potreba neni..

jen to aby pri povyseni jadra byl balicek neco-dkms pripraven na toto jadro, coz se, mimimalne pred mnoha lety kdy sem VB jeste pouzival, u nej prave casto stavalo ;-)

nicmene ted nevim ktera "strana" ale bud pro hosta nebo hostitele, myslim ze uz par let pro virtualbox je mimo dkms v mainline jadre...

Tak zrovna uz i predposledni 6.1.38 je pripravena i na 6.0 kernely - vyjmecne dokonce driv, ne byla 6.0 oficielne vydana, mate to i v changelogu (ale kdo by to cetl, ze - hejtit bez znalosti skutecneho stavu je bezpracny). Na druhou stranu, kolik lidi doopravdy nasazuje novy kernel, hned jak se objevi na kernel.org? Ano, uber-geek muze narazet... ale u beznych uzivatelu, co jedou na (proti upstreamu vcelku opozdenych) distribucnich kernelech zrovna tohle fakt problem neni.

V obecne rovine pochopitelne... out-of-tree veci nebudou vzdy hned in-sync s tim nejnovejsim releasem vanilkoveho kernelu. To platilo a plati u jakehokoliv patche, ktery zije mimo oficialni struktury. To je samo o sobe tak nejak ocekavatelne... Ale treba u LTS vydani s tim problem vesmes nebyva (i kdyz ano - i tam se obcas objevi neco, co kompabilitu rozbije).

_{PS: a to pisu jako clovek, kteremu se zrovna ted buildi posledni 6.0.1 kernel, co obratem nasadim... a vim, co to obcas obnasi}

hejtit bez znalosti? asi ti to ted v noci uz spatne cte ;-)

coz se, mimimalne pred mnoha lety kdy sem VB jeste pouzival, u nej prave casto stavalo

tedy jasne pisu ze nevim jak je to ted, pisu jak to bylo i to ze uz ho davno nepouzivam, a v dalsi vete pak naopak obhajuju ze ta jedra strana si matne vybavuju ze uz je roky poresena ;-)

nicmene jak sem psal vejs, duvod pouzivat VB vidim jen 2, u me neplati ani 1, takze spoustu let vyhradne virt-manager/libvir­t/qemu

No ono sa to svojho času na Fedore stávalo docela bežne. Takže žiadny uber geek, ale bežný používateľ.

No tak já třeba předloni odešla od VirtualBoxu poté, co na kombinaci novějších jader a intelovských procesorů desáté/jedenácté generace začaly padat virtuální Windows jak zralé hrušky. Oprava tehdy trvala Oraclu skoro půl roku, workaround se split_lock_de­tect=off sice celkem fungoval, ale stoprocentní to taky nebylo.
https://www.virtualbox.org/ticket/20180
A od té doby, co jsem odešla, se mi přestal notebook náhodně sekat po probuzení...