Gastdrivers voor VirtualBox gaan deel uitmaken van Linux-kernel

De volgende versie van de Linux-kernel, 4.16, integreert de gastdrivers voor VirtualBox. Daarmee vervalt de noodzaak om deze nog handmatig te installeren om verdere integratie te verkrijgen bij het gebruik van een virtual machine.

Phoronix schrijft dat de 'vboxguest'-driver deel gaat uitmaken van de 4.16-kernel. Dat is het gevolg van het werk van Hans de Goede van Red Hat. De driver maakt het gebruik van verschillende functies mogelijk die het gast-OS in de vm verder integreren met de host.

In een bericht op de Linux-kernelmailinglijst schrijft De Goede dat er door de toevoeging van de driver onder meer ondersteuning komt voor knippen en plakken tussen host en gast, voor seamless mode en voor OpenGL pass-through.

Phoronix merkt op dat de optie voor gedeelde folders mogelijk nog niet op tijd klaar is voor release samen met de 4.16-kernel, waardoor deze mogelijk later komt.

Ubuntu in VBox

Reacties (111)

[DigitalExorcist]

Nog meer bloatware in de toch al veel te zware kernel 😐

Stel dat ik nu Xen wil gebruiken .. of geen VM draai......

[CAPSLOCK2000]

Nog meer bloatware in de toch al veel te zware kernel 😐

Stel dat ik nu Xen wil gebruiken .. of geen VM draai......

Ik neem aan dat deze drivers gewoon als modules beschikbaar die je on-demand laadt en anders niet, net als zo'n beetje iedere andere driver op ieder andere modern OS. Zo werkt het nu al en ik neem aan dat ze dat niet veranderen.

[Reactie gewijzigd door CAPSLOCK2000 op 24 juli 2024 10:01]

[green944]

Het zullen modules zijn die alleen wordt geladen als ze nodig zijn. Standaard heef de kernel op RedHat/Centos al meer dan 2400 modules dus een paar erbij maakt niet zoveel uit. Als je ze niet wilt kan je ze blacklisten. b.v. in /etc/modprobe.d/blacklist.conf

[FireDrunk]

Dit dus, al die mensen hierboven die mopperen dat de kernel bloated wordt, snappen het blijkbaar niet.
Modules worden (mits ze in de distro zo gecompileerd worden) geladen in je initrd fase, waarna je er direct plezier van hebt, *mits* ze nodig zijn. Prima oplossing, want er is niets van de VBoxGuestAdditions nodig om te booten, dus lekker async laden.

[Bor]

Of stel dat er een kwetsbaarheid in de guest drivers wordt gevonden; door een standaard installatie vergroot je de attack surface.

[Miki]

Als je weet hoe de Linux kernel werkt dan is speelt dit probleem niet.

De kernel heeft een aantal essentiële drivers die altijd geladen worden en voor de rest wordt op basis van hardware id’s de juiste modules(drivers) ingeladen. Alles wat niet tijdens de boot of naderhand aangevraagd wordt, wordt niet ingeladen. Er dus geen enkel risico.

Mocht je toevallig een Linux doos tot je beschikking hebben, dan kun je met lsmod in de terminal bekijken welke huidige modules zijn geladen

[DigitalExorcist]

Dat weet ik; maar feit is wel dat alles meegeleverd wordt ook als je er niet om vraagt. Of het geladen wordt of niet maakt dan niet uit (als dat wel zo zou zijn ben je helemáál zuur, met tienduizenden mogelijke stuks hardware)

[MrFax]

Dan bouw je toch zelf de kernel? Als jij het zo erg vind dat de kernel zo bloated is moet je er ook de moeite voor nemen om zelf een baseline custom linux kernel te maken. Zo moeilijk is het niet om modules wel of niet mee te nemen

[Reactie gewijzigd door MrFax op 24 juli 2024 10:01]

[KiD_KRiool]

sorry hoor maar de tijd dat de data opslag beperkt was aan je cd- rom schrijfje ligt al ver achter ons

[DigitalExorcist]

Als ik zie wat mensen kunnen maken met 64kb aan geheugen (denk aan de demo-scene) is het onbestaanbaar dat een OS enkele Gb's aan ruimte in moet noemen nog vóórdat je er applicaties op gaat zetten. Heeft niks te maken met dataopslag, maar met efficiëntie.

"Oh we hebben tóch 8Gb geheugen, laten we dat gewoon lekker volpleuren met de meest onzinnige rommel, who cares, door ons dealtje met geheugenfabrikant <x> verkopen zij extra RAM als dat nodig is".

En nee dan heb ik het niet specifiek over optionele kernelmodules die al dan niet geladen worden. Maar het feit dat het meegeleverd wordt terwijl het een basishandeling is om die dingen achteraf te laden als je ze wél nodig hebt.

[Reactie gewijzigd door DigitalExorcist op 24 juli 2024 10:01]

[Becquerel]

dan compile je een kernel zonder deze drivers?

[Verwijderd]

Dan compileer je een custom kernel die geen Virtualbox ondersteuning heeft.

Dat is de kracht van Linux en open-source. Je kan een kernel bouwen die alleen maar ondersteuning heeft voor de hardware van jouw machine.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 10:01]

[fantafriday]

Beetje de omgekeerde wereld natuurlijk. Maar het is een optie.

[Verwijderd]

Maar hoezo dan? Een kernel die je niet zelf samenstelt en voor generiek gebruik bedoelde is bevat toch sowieso spul wat je niet strict gesproken nodig hebt? Ondersteuning voor hardware die je niet hebt bijvoorbeeld? Zomaar een afslag. Als je zo met stroomlijning bezig bent dat je in de stress raakt van wat overbodige componenten ben je sowieso al bezig met custom kernels en vermoedelijk custom distributies.

De toevoeging van de ondersteuning voor een virtualisatietechniek is overigens ook niet nieuw want ook VMware zit ook reeds enige tijd ingebakken: http://webwereld.nl/softw...evat-interfacecode-vmware
Ergens is het dus gewoon logisch dat ook de opensource oplossing dit niveau van implementatie krijgt.

Met die overvloed aan hardwarecapaciteit in het gemiddelde systeem snap ik sowieso de stress niet van een extra module die slechts wat marginale schijfruimte wegknabbeld. Je kan dat allemaal in aparte kernels gaan stoppen die onder andere noemers releasen en twee MB besparen in een aantal gevallen of je kan gewoon één kernel maken die alles doet en het lekker simpel houden voor iedereen ten koste van een een beetje schijfruimte die niemand gaat missen behalve de minimalisten die er naar zoeken.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 10:01]

[rbr320]

Je kan dat allemaal in aparte kernels gaan stoppen die onder andere noemers releasen

En dat gebeurd ook. Zo heeft Ubuntu verschillende varianten van dezelfde kernel versie in zijn repositories met daarin specifieke optimalisaties voor bijvoorbeeld Xen, Azure en andere (cloud) hypervisors. Daarnaast bieden ze al sinds jaar en dag een "lowlatency" versie van de Linux kernel aan, wat gewoon de standaard kernel is met een andere scheduler.

Wat ik bedoel te zeggen is dat dankzij het feit dat de Linux kernel open source is, hij dus vrijelijk door iedereen kan worden aangepast naar verschillende behoeftes. De verantwoordelijk daarvoor ligt echter zoals @Verwijderd al verondersteld bij de gebruiker zelf en daarnaast zijn er distributies die dit als extra service leveren.

[Verwijderd]

Ik geloof niet dat wij op een noemenswaardig niveau een meningsverschil hebben.
Ik reageerde op de "omgekeerde wereld" opmerking van fantafriday.

[rbr320]

Mijn reactie was dan ook bedoeld als een ondersteuning van de jouwe, maar omdat ik je wilde quoten staat hij dus onder de jouwe

[Reactie gewijzigd door rbr320 op 24 juli 2024 10:01]

[Verwijderd]

Custom kernel != custom distribution. Je kan prima een custom kernel maken en draaien onder een standaard Ubuntu distro.

Voor een enkele PC is die paar MB RAM en schijfruimte niet het probleem, maar als jij een datacenter draait met tig virtuele machines dan maakt dat zeker uit. Ook kost het opstart tijd want er moet toch een hardware probe gedaan worden.

[Verwijderd]

Custom kernel != custom distribution. Je kan prima een custom kernel maken en draaien onder een standaard Ubuntu distro.

Ik zeg volgens mij helemaal nergens dat die twee hetzelfde zijn?
Maar je bent wel een beetje raar bezig als je nerveus wordt van een "zware" kernel en je je custom gestroomlijnde superstrakke mileubewuste hipster kernel dan gewoon in Ubuntu steekt.

Voor een enkele PC is die paar MB RAM en schijfruimte niet het probleem, maar als jij een datacenter draait met tig virtuele machines dan maakt dat zeker uit. Ook kost het opstart tijd want er moet toch een hardware probe gedaan worden.

Modules die niet gebruikt worden worden niet geladen, dus RAM niet.
Als je vandaag de dag nog visualiseert op een manier waar je ook de kernel meevirtualiseert (in plaats van dat virtualiseren in containervorm doet waardoor de host kernel gebruikt wordt) moet je denk ik sowieso goed kijken naar wat je aan het doen bent want volgens mij is dat in veel gevallen helemaal niet meer nodig..
Als je wel een miljoenmiljard machines hebt die persé helemaal geisoleerd moeten zijn EN helemaal van top tot teen gevisualiseerd moeten worden is ook die overhead niet zo stressvol als het goed is, en zo wel is het allicht de moeite waard om daar dus zelf een kernel voor samen te stellen.
Dat een generieke kernel release geen rekening houd met zo'n super specifieke use-case lijk me niet heel gek. Met of zonder virtualbox guest addons wil je dan aan de slag met kernel.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 10:01]

[kozue]

Ook kost het opstart tijd want er moet toch een hardware probe gedaan worden.

Dan weet jij niet hoe modules geladen worden. Denk je echt dat de kernel voor alle drivers (modules) gaat kijken of hun hardware toevallig aanwezig is? Dan ben je een uur bezig met opstarten, want er is nogal wat hardware gemaakt in de afgelopen decennia. Er wordt gescand op aanwezige hardware en ieder stukje hardware heeft een eigen ID (bv de PCI ID's in "lspci -n"). Vervolgens wordt er een driver geladen die bij dat ID hoort. Iedere module heeft namelijk een lijst met bijbehorende device ID's (te zien in "modinfo <naam>") die in de modmap opgeslagen worden.
Als je niet op virtualbox draait, vindt de kernel dus geen virtualbox device ID's en zal ie nooit een poging doen die drivers te laden. Meer dan een rondslingerend bestand op je disk is het dan dus niet.

[Hero of Time]

Dus je hebt liever dat er initieel niets wordt ondersteund en je zelf moet gaan uitvogelen wat je precies nodig hebt, dan dat het zekere voor het onzekere wordt genomen en gewoon alles wordt ondersteund? Want waarom zou de kernel standaard AMD CPU's ondersteunen als je alleen maar Intel hebt? En dan neem je eens een AMD en dan, oh, oeps, sorry, dat werkt niet, want er is geen support voor, dat moet je eerst zelf nog even aangeven. Heb je nu even een week de tijd om alles uit te zoeken wat je nou precies aan en uit moet zetten om van Intel naar AMD support te gaan? En dan daarna 2 uur geduld om de boel opnieuw te compileren.

Nee, laat het maar lekker allemaal standaard ondersteund worden. Wie er echt interesse in heeft kan zich er meer in verdiepen en een eigen kernel bakken speciaal gericht op zijn/haar specifieke hardwareconfiguratie.

[fantafriday]

Volgens mij zeg ik alleen dat ik het nut van standaard vBox drivers erin te doen niet helemaal begrijp gezien het gross er 0 aan heeft...

[Hero of Time]

En het gros van de Intel gebruikers heeft geen klap aan AMD support en andersom, net als het gros van de nVidia GPU bezitters niets heeft aan die van AMD en Intel en alle oudere kaarten en die in servers gebruikt worden. En zo zijn er nog bakken meer zaken die er standaard in zit waar 'het gross' niets aan heeft.

[Blokker_1999]

Je moest eens weten hoeveel modules er vandaag op een standaard kale distro worden meegeleverd die maar door een fractie van de gebruikers actief worden ingeladen terwijl er meergebruikte modules zijn die vandaag niet worden meegeleverd. De vbox guest drivers worden door redelijk wat mensen gebruikt en het blijft soms sukkellen om ze geladen te krijgen.

[Becquerel]

Ja, want de huidige kernel bevat natuurlijk alleen maar meuk die jij specifiek nodig hebt.....

En zelf wat doen voor een gratis OS... Of doneer jij genoeg dat ze voor jou speciaal compilen?

[fantafriday]

Nee dat zeg ik niet. Maar vBox drivers zijn nou niet bepaald iets waar het gross iets aan zal gaan hebben.

[Becquerel]

Maar jij hebt er toch geen last van? De kernel wordt enkele MBs groter, maar tis allemaal load on demand meuk. Persoonlijk zou ik zeggen gooi het in de package managers, maar wie ben ik.

[kozue]

Enkele MB's? Enkele kB's zul je bedoelen. De meeste modules zijn heel klein. De virtio gpu driver (zegmaar de kvm tegenhanger van de virtualbox video driver) is ongeveer 126kb.

[Becquerel]

dan zie ik het hele probleem niet.

[JAVE]

Je kan ook een petitie starten met argumenten waarom de vboxguest drivers NIET in de kernel moeten zitten...

[Marctraider]

Dat was vroeger inderdaad de leus. Linux was zo veel sneller en efficienter omdat de hardware toen nog rete traag was, weinig geheugen beschikbaar was, waardoor je dus distro's als Gentoo e.d. kreeg waar een hele 'optimization' community achter zat die allemaal zaten te klooien met compiler flags, om maar dat enkele procentje meer snelheid te kunnen krijgen voor significante instabiliteit van hun gecompileerde software. Gelukkig zijn systemen hedendaags zo snel dat je er geen drol meer van merkt.

http://funroll-loops.teurasporsaat.org/

Grappig was het wel, moet ik zeggen

[Reactie gewijzigd door Marctraider op 24 juli 2024 10:01]

[Anonymoussaurus]

Bloatware???? Dit zijn virtuele drivers voor je VM. Voor bijvoorbeeld de integrated graphics, etc. Als je die driver niet installeert, kun je nog wel eens krijgen dat 'ie niet in fullscreen wilt, of de resolutie niet hoger kan.

[MadEgg]

Het is wel bloatware omdat lang niet alle kernels op VirtualBox draaien, en daarmee deze drivers niet nodig hebben.

Je hoeft ze niet te compileren, en ik hoop dat er wel aparte kernel packages komen voor VM's op VirtualBox zodat je zelf kunt kiezen. Het zal wel als module gecompileerd worden waardoor het niet standaard geladen wordt, maar toch... er staan al zoveel drivers in welke je lang niet allemaal nodig hebt.

[The Zep Man]

er staan al zoveel drivers in welke je lang niet allemaal nodig hebt.

Dat is juist een sterk punt van Linux. Veel oude hardware heb ik een tweede leven gegeven omdat het (recente) Linux kan draaien.

Je ziet voor de kernel dat het framework voor drivers en 'subdrivers' zodanig wordt ingericht dat het toevoegen van hardware een eenmalige actie is. De overhead om oud spul te blijven ondersteunen wordt daarmee gereduceerd tot het minimum. Voor het werk is er dus weinig behoefte om drivers/ondersteuning te schrappen. Zoals eerder genoemd wordt een kernel module pas geladen als deze nodig is. Dat beetje schijfruimte voor ongebruikte modules (in de praktijk vaak <100 KB per module) die meegeleverd worden in een standaard Linuxdistributie kan iedereen wel missen, en het maakt de distributie veelzijdiger. Al ga je specialistisch aan de slag dan kan je altijd nog besluiten om bepaalde modules niet mee te compileren.

Een interessant boek voor jou en iedereen die zelf de teugels in handen willen houden is hier te vinden. Het is gratis en best wel uitgebreid, net als de Linux kernel, maar ik vertrouw erop dat het wel gaat lukken om de goudkorrels eruit te halen.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 10:01]

[MadEgg]

LFS heb ik lang geleden een keer gedaan. Prachtig project, maar wel bewerkelijk en niet te onderhouden Wel leerzaam.

Ik zou best wat zien in enige segmentatie van de kernels - afhankelijk van het type hardware (of door de gebruiker gekozen) een kernel draaien geschikt voor in een VM, op oude hardware of juist op nieuwe hardware.

Veel last heb je natuurlijk niet van honderden / duizenden modules die je niet gebruikt maar het is wel bloat die je niet nodig hebt. Net zo min als dat ik echt last heb van Candy Crush in Windows 10, maar het heeft daar niets te zoeken, dus heb ik het er liever niet.

[The Zep Man]

LFS heb ik lang geleden een keer gedaan. Prachtig project, maar wel bewerkelijk en niet te onderhouden Wel leerzaam.

Bedankt dat je mijn punt bevestigt, want dat is hetzelfde punt dat je kan maken over het onderhouden van verschillende kernels/distributies.

Ik zou best wat zien in enige segmentatie van de kernels - afhankelijk van het type hardware (of door de gebruiker gekozen) een kernel draaien geschikt voor in een VM, op oude hardware of juist op nieuwe hardware.

Die keuze die heb je. Er is niets mis mee dat de standaardkernel van de meeste distributies op de meeste hardware draait. Al bevalt dat je niet dan kan je het (vaak zelfs geassisteerd/geautomatiseerd) zelf compileren.

Veel last heb je natuurlijk niet van honderden / duizenden modules die je niet gebruikt maar het is wel bloat die je niet nodig hebt.

Bloat zie ik als ongewenste software die een significante invloed heeft op de prestaties/capaciteiten van een systeem. Voor mij vallen ongebruikte kernel modules hier niet onder. Ik heb liever dat ze er voor de zekerheid er wel bij zitten. Als ik compileer kost dat mij misschien 1/10e seconde om een ongewenste module mee te compileren en het kost wat ruimte in de distributie en opslag, maar daar leef ik wel mee (en vele anderen).

De kracht van Linux is juist dat het een enkele kernel is. Distributies configureren de kernel en staan verdere specialisatie toe. Al heb je een specialistische kernel nodig omdat een algemene kernel niet werkt, dan heb je zeer waarschijnlijk ook een specialistische distributie nodig. Daar zou ik eerst een keuze in maken. Algemene distributies (Debian Linux, Arch Linux, etc.) moeten algemeen blijven om vanaf een enkel installatiemedium zo flexibel mogelijk inzetbaar te zijn.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 10:01]

[MadEgg]

Bedankt dat je mijn punt bevestigt, want dat is hetzelfde punt dat je kan maken over het onderhouden van verschillende kernels/distributies.

Elke kernelupdate zelf moeten downloaden, configureren en compileren is alweer een heel ander verhaal dan eenmalig een andere kernel package kiezen en deze door de package manager laten beheren. Daar zijn ook build farms voor bij de distributies. Ik heb tijdenlang Gentoo gedraaid, hierbij compileer je alles ook van source en mag je ook zelf je kernel compileren, maar is het wél onderhoudbaar dankzij de hulp van de briljante package manager.

Bloat zie ik als ongewenste software die een significante invloed heeft op de prestaties/capaciteiten van een systeem. Voor mij vallen ongebruikte kernel modules hier niet onder. Ik heb liever dat ze er voor de zekerheid er wel bij zitten. Als ik compileer kost dat mij misschien 1/10e seconde om een ongewenste module mee te compileren en het kost wat ruimte in de distributie en opslag, maar daar leef ik wel mee (en vele anderen).

Bloat is voor mij gewoon ongewenste (onnodige) features en software. Een zekere mate van bloat is onvermijdelijk maar er zijn wel grenzen. Ik vind specifieke drivers voor een virtualisatieplatform wel wat ver gaan. Het installeren via een losse package ging altijd prima, ik heb zelf nooit deze drivers hoeven te bouwen / installeren op mijn VirtualBox VM's.

De kracht van Linux is juist dat het een enkele kernel is. Distributies configureren de kernel en staan verdere specialisatie toe. Al heb je een specialistische kernel nodig omdat een algemene kernel niet werkt, dan heb je zeer waarschijnlijk ook een specialistische distributie nodig. Daar zou ik eerst een keuze in maken. Algemene distributies (Debian Linux, Arch Linux, etc.) moeten algemeen blijven om vanaf een enkel installatiemedium zo flexibel mogelijk inzetbaar te zijn.

Het installatiemedium kan best alles bevatten, maar de uiteindelijk geïnstalleerde kernel zou best wat meer op je systeem toegespitst kunnen zijn. De boot-partitie groeit en groeit maar door dit soort zaken.

Ik zal er niet wakker van liggen maar vind het absoluut niet nodig dat dit standaard in elke kernel zit. Los daarvan is het natuurlijk prima als het in de kernel source opgenomen wordt, dat maakt de toekomst zekerder aangezien de kernel developers de compatibiliteit van modules bewaken. Dat betekent nog niet dat alle drivers standaard in de kernel packages moeten zitten. En gelukkig zitten ze dat ook niet allemaal.

[Reactie gewijzigd door MadEgg op 24 juli 2024 10:01]

[Joep Lunaar]

Bloat is voor mij gewoon ongewenste (onnodige) features en software. Een zekere mate van bloat is onvermijdelijk maar er zijn wel grenzen. Ik vind specifieke drivers voor een virtualisatieplatform wel wat ver gaan. Het installeren via een losse package ging altijd prima, ik heb zelf nooit deze drivers hoeven te bouwen / installeren op mijn VirtualBox VM's.

Kleine verheldering:
Het gaat in dit geval om het opnemen van de VBOX guest driver modules in de "upstream kernel mainline", waardoor voortaan bij wijzigingen in de interne kernel APIs (wat veel gebeurt), eventueel benodigde wijzigingen in de code van deze modules worden meegenomen en getest op regressies, iets dat grote voordelen heeft voor hen die de modules hebben ontwikkeld.
De installatie via een losse package betrof de installatie van out-of-mainline modules, die dan deels tijdens installatie ook nog moeten worden gecompileerd tegen de geïnstalleerde kernels (zie ook https://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support).

De opname van deze code in de mainline heeft dus alleen maar voordelen.
Alle gezever over "bloatware" heeft daarmee niets van doen. Zoals velen al hebben aangevoerd kan wat feitelijk wordt geïnstalleerd of geladen geheel door de gebruiker zelf worden bepaald en meestal zorgt de gebruikte Linux distributie voor zinnige keuzes.

[MadEgg]

Heb je de laatste paragraaf van de reactie waar je op reageert wel gelezen?

[CAPSLOCK2000]

Ik zou best wat zien in enige segmentatie van de kernels - afhankelijk van het type hardware (of door de gebruiker gekozen) een kernel draaien geschikt voor in een VM, op oude hardware of juist op nieuwe hardware.

Wat voor verschillen zou je willen zien tussen die segmenten?
Wat zou een kernel voor oude/nieuwe/virtuele hardware wel of niet moeten bevatten?
Bepaalde drivers wel of niet laden kan al, daar zijn geen aanpassingen aan de kernel voor nodig.

Ooit hadden we Linux-kernels voor systemen met veel geheugen, en systemen met weinig geheugen, alsmede systemen met een enkele CPU(-core) of meerdere CPU's. Op een gegeven moment is men daar mee gestopt omdat nieuwere algoritmes goed omgaan met alle situaties.

[JayPe]

Ooit hadden we Linux-kernels voor systemen met veel geheugen.....<KNIP>

Uit de meest recente release announcement:

There are two kinds of kernels in Slackware. First there are the
huge kernels, which contain support for just about every driver in the
Linux kernel. These are primarily intended to be used for installation,
but there's no real reason that you couldn't continue to run them after
you have installed. The other type of kernel is the generic kernel, in
which nearly every driver is built as a module. To use a generic kernel
you'll need to build an initrd to load your filesystem module and
possibly your drive controller or other drivers needed at boot time,
configure LILO to load the initrd at boot, and reinstall LILO. See the
docs in /boot after installing for more information. Slackware's Linux
kernels come in both SMP and non-SMP types now. The SMP kernel supports
multiple processors, multi-core CPUs, HyperThreading, and about every
other optimization available. In our own testing this kernel has proven
to be fast, stable, and reliable. We recommend using the SMP kernel
even on single processor machines if it will run on them. Note that on
x86_64 (64-bit), all the kernels are SMP capable.

Ooit = nog steeds :-)

[Heidistein]

Ja, zo gaat het inderdaad. Maar volgens mij bedoelt hij dat er vroeger kernels waren met PAE enabled (physical address extention) voor als je het geld had om meet van 4GB geheugen te hebben in je 32 bit bakje, en de SMP versie voor symatric(?) multi processor systemen, voor de echt hele rijke mensen met meerdere CPU's.

Ik kan me nog een mail herinneren (niet terugvinden) van ruwweg 16 jaar geleden, waarin er een issue was met performance op grafische systemen op single cpu (single core, omdat multicore nog niet bestond) machines (dus vrijwel alle computers destijds). Linus Thorvalds had hier geen last van op zijn 4 CPU werkstation met belachelijk veel ram. "Poor Linus" reageerde iemand hier op.

[Becquerel]

Das zijn alle Intel drivers in mijn kernel dus ook bloatware, aangezien ik full AMD heb....

[MadEgg]

Yup. Voor jou wel. Bloat is tot op zekere onvermijdelijk. Ergens moet je de grens trekken, wanneer is het te veel. Persoonlijk trek ik in dit geval wel de grens bij drivers voor virtualisatieoplossingen, die niet eens noodzakelijk zijn om de virtuele machine te laten starten.

[Becquerel]

Drivers zijn load on demand, en die enkele MBs die ze kosten, ach, daar lig ik niet echt wakker om. Zou ik dat wel doen, dan compileer ik mijn eigen kernel wel.

Maar aan alle tegenstand te zien, zou iemand een eigen distro moeten maken Fork Debian, of beter Deviaun en haal daar de vm drivers uit!

[sko]

Lang niet alle kernels draaien op de chipset die jij hebt, dus is dat ook bloatware?

[CAPSLOCK2000]

Het is wel bloatware omdat lang niet alle kernels op VirtualBox draaien, en daarmee deze drivers niet nodig hebben.

Je hoeft ze niet te compileren, en ik hoop dat er wel aparte kernel packages komen voor VM's op VirtualBox zodat je zelf kunt kiezen. Het zal wel als module gecompileerd worden waardoor het niet standaard geladen wordt, maar toch... er staan al zoveel drivers in welke je lang niet allemaal nodig hebt.

Waar heb je last van? Praktisch gezien is het grootste bezwaar dat het wat schuifruimte kost. Op de meeste systemen gaat die paar MB echt geen verschil maken.

In theorie zou het nog een beveiligingsprobleem kunnen opleveren, maar als een aanvaller al zo ver is dat er drivers geladen kunnen worden dan heb je een groter probleem.

[DigitalExorcist]

Ik stam uit de tijd van opt-in .... als ik een VM draai onder vbox installeer ik zelf die guest additions wel..

[SirNobax]

als ik een VM draai onder vbox installeer ik zelf die guest additions wel

Dit zijn niet de guest extensions waar binary blobs voor USB en een hoop andere rotzooi in zit, maar code voor betere aansturing van het virtuele scherm en de muis, wat direct een hoop extra features mogelijk maakt die in de VM-host software zit ingebakken. Niet meer dan logisch dat dit nu in de mainline kernel gaat komen gezien dit niet anders is met de KVM virtio drivers, of die van Hyper-V.

En daarnaast als voordeel dat de code van fatsoenlijke kwaliteit moet zijn voordat deze uberhaupt de kernel in mogen, dat is maar de vraag bij de losse vbox-guest-agent.

[Reactie gewijzigd door SirNobax op 24 juli 2024 10:01]

[CAPSLOCK2000]

Installeer je ook zelf de toetsenborddriver voor je fysieke systemen?

Ik denk dat het "all-inclusive, one size fits all" model prima werkt voor een general purpose OS. Als je speciale behoeftes hebt waardoor je last hebt van die toevoegingen kun je ze er eenvoudig uithalen. Als je in een vakgebied werkt waar dat relevant is heb je ook wel de handigheid om zelf een kernel te compileren.

[IStealYourGun]

Ik kan me niet herinneren dat de Linux kernel een opt-in model had, eerder een opt-out. De meeste moderne distro's hadden de drivers sowieso al aan boord.

[Joep Lunaar]

... en gezien je naam schep je genoegen in het uitroeien van alle nieuwlichterij. Just kidding.

[SilentLucidity]

Hij bedoeld dat het bloatware is als het standaard in de kernel zit, wat een normale linuxgebruiker of servers aan deze ondersteuning? Niets. Simpele oplossing is echter de kernel zonder te compileren, problem solved.

[Anonymoussaurus]

Ah, ja dat is wat anders. Duidelijk. Thanks!

@DigitalExcorcist Helaas is alles tegenwoordig alleen maar opt-out .

[The Zep Man]

Ik zou apart kernels moeten gaan compileren om iets wat ongewenst is eruit te gaan slopen.

Zoveel misinformatie... Dit zit niet in de kernel en heeft geen invloed op een niet-VirtualBox systeem anders dan dat het enkele KB gebruikt op de harde schijf. Het wordt niet eens in het geheugen geladen. Qua dat denk ik dat je meer winst zal krijgen door je 'minimalistische woede' op andere softwareproducten te richten.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 10:01]

[SilentLucidity]

De andere kant is dat we linux-build met speciale vm-kernel gaan bouwen. Is dat waar we heen willen?
Mijn persoonlijke opvatting is dat alles zo 'simpel' mogelijk moet blijven (voor de simpele gebruiker), dan kunnen de 'experts' zelf een kernel zonder bs. Uiteindelijk zal een light-distro deze functies toch uit de kernel slopen om op die oude laptops met 1 1ghz core en 500mb te blijven draaien.

[JAVE]

Tja, dat is al sinds het begin zo.
Je krijgt een redelijk generieke kernel, met drivers voor veel gebruikte hardware.
Wil je iets bijzonders, of wil je je kernel minimaliseren? Dan compileer je hem zelf.

Maar is tegenwoordig niet het meeste als module gecompileerd voor Linux? Als je een driver dan niet nodig hebt, dan laadt je systeem hem niet in, en is er dus niets aan de hand.

[Joep Lunaar]

@ @nathan-96 en @Anonymoussaurus Niet juist.
De gebruikte Linux distributie (Debian, Redhat, Suse enz) bepaalt wat zij in de kernels die zij bouwen stoppen (kernel build config) en hoe zij de kernels en modules in packages onderbrengen.
Niets staat je in de weg om of een distributie te kiezen die werkelijk niets standaard installeert, of om zelf een heel specifieke kernel te bouwen. Als je dan ook alle modules, maar ook alleen die nodig zijn, in de kernel opneemt (dus niet als losse kernel module, maar direct in de kernel image opneemt) dan krijg je slanke/enz kernel die ook nog eens supersnel laadt. De prijs is dat als je iets wijzigt in hardware of software configuratie waarvoor een extra module nodig is, of als je een nieuwe versie van de kernel wilt, je het spul weer moet gaan compileren enz. Dan is het rusten op een redelijke keuze van de distributie (een aantal altijd onmisbare modules in de kernel en de rest als losse modules) wel zo handig en makkelijk.

[aldieaccounts]

Niet de vboxguest module laden?
non issue. Er zitten gegarandeerd drivers voor hardware die je niet hebt in de kernel. Meestal in de vorm van een module die gewoon niet geladen wordt.

[terracide]

Ik vind dat DigitalExorcist een punt heeft. Natuurlijk kan je de kernel compileren, en dat is ook helemaal niet zo moeilijk. Maar juist om het nieuwe gebruikers makkelijk te maken wordt er steeds meer "rotzooi" in de kernel gestopt zodat nieuwe gebruikers niets meer hoeven te installeren. Ik vind dat juist de omgekeerde wereld. Zorg dat het voor nieuwe gebruikers makkelijker wordt op een anderen manier zodat je bestaande gebruikers niet lastig valt met lompe kernels.

[Becquerel]

Load on demand. Jouw kernel wordt hierdoor niet trager, alleen ietsjes groter.....

[DigitalExorcist]

In de begindagen van Slackware (misschien nog steeds wel) was dat inderdaad het geval. Je bootte naar de shell met minimale hardwaresupport en voor de rest moest je het zelf maar bekijken... wil je bepaalde kernelmodules erbij hebben? Dan compileer je die maar lekker zelf. Wil je updaten? Compileer je maar lekker zelf. Nieuwe compiler nodig? Dan compileer je die maar lekker ze.... eh...

[leuk_he]

Behalve dat je anno 2018 de soures niet allemaal gedownload hebt, maar download als je ze nodig hebt.

en uiteraard, een server installeer je zonder een echte gui.

https://help.ubuntu.com/l...e/installing-from-cd.html
Unlike the Desktop Edition, the Server Edition does not include a graphical installation program.

[Jerie]

Iedere kernel die veel hardware support, zal ook heel veel hardware supporten (met of zonder LKM) die jij nooit op jouw apparaatje gaat draaien. Kun je twee dingen doen: je compiled die zaakjes niet als modules, of je neemt die paar kB extra voor lief. Het laatste doe je by default, het eerste doe je bij embedded apparatuur. Vooral vroeger want tegenwoordig gaat het nergens meer over.

Er is veel bloat hoor in de computerwereld. Maar dan zou ik toch eerst 'ns kijken naar Web 3.0; JavaScript, PNG/JPEG, enz.

[nlinzweden]

Volgens mij is deze driver (wat inderdaad waarschijnlijk gewoon een module zal zijn) onderdeel van de GNU/Linux die je *in* de VM draait. Dus zelfs als je VirtualBox gebruikt, zal de host Linux nog steeds deze driver niet nodig hebben.

[Loller1]

Mmm... Hoewel dit de gebruiksvriendelijkheid zeker ten goede zal komen... is dit iets dat je in de kernel zou willen? Ik veronderstel dat dit ook alleen maar werkt met VirtualBox en niet met VMware, Hyper-V, etc.?

[CAPSLOCK2000]

VMWare en Hyper-V hebben al eigen drivers in de Linux-kernel.

[Gamrin]

In dat geval; waarom doen we moeilijk/waarom zit dit er niet al jaren in?

[CAPSLOCK2000]

Ik weet het niet zeker, maar ik meen dat er twee redenen zijn.
De eerste is dat VirtualBox begon als een closed-source product. De ontwikkelaars wilden hun drivers dus helemaal niet in de publiek beschikbare kernel, die waren alleen voor hun betalende klanten. Later is VirtualBox van licentie veranderd waardoor het geen probleem meer is.
Verder meen ik dat de eerste versies van deze drivers nogal ingrijpend waren en ook andere delen van de kernel aanpaste. Het wordt niet wenselijk geacht om zo'n veranderingen eenzijdig door te voeren. Het is de bedoeling dat je alle aanpassingen in losse delen opsplitst en die bespreekt met de relevante kernelteams. Dat kan veel tijd kosten bij ingrijpende veranderingen.
Vaak is het bij dit soort projecten ook zo dat ze hun eigen programmeerstijl hanteren, bijvoorbeeld de huisstijl van de ontwikkelaar. Als zo'n driver deel wordt van de mainline kernel moet de stijl worden aangepast. Dat kan ook voor vertraging zorgen, geen idee of dat hier van toepassing is.
Ten slotte moet je bereid zijn om je werk te onderhouden als je deel wordt van de kernel. Sommige projecten zijn daar nog niet klaar voor, bijvoorbeeld omdat hun werk nog te snel verandert om het lange tijd te ondersteunen. Die kiezen er dan voor om buiten de kernel te blijven. Wederom weet ik niet of dat hier van toepassing is. Oracle staat niet echt bekend om z'n vrijgevigheid, mogelijk speelt dat een rol.

[Anonymoussaurus]

Eindelijk (werd een beetje vervelend om telkens bij elke nieuwe update weer die virtuele disk erin te rammen).. Al gebruik ik al een tijdje geen VirtualBox meer. Het is zeer gebruiksvriendelijk, en naar mijn mening meer Plug 'N Play dan bijvoorbeeld Hyper-V en VMWare.

Bij Hyper-V (wat ik eigenlijk alleen maar gebruik) is het af en toe nogal gaar - en weet niet of dat een driverprobleempje is - maar heb zo nu en dan op onverklaarbare wijze last van VM's die ik niet in fullscreen kan runnen, terwijl ik wel de nodige toetsencombinaties en instellingen heb geprobeerd .

[Reactie gewijzigd door Anonymoussaurus op 24 juli 2024 10:01]

[|sWORDs|]

Vrijwel alle distros gebruiken open-vm-tools voor VMware. Die gaat gewoon in je OS update rondje mee.

[Hydranet]

Ik snap niet dat ze virtualbox drivers in de kernel gaan integreren, je hebt toch al KVM om virtual machines te draaien. Volgens mij draaien de meeste bedrijven die een virtual enironment draaien onder Linux KVM of RHEV.

[rbr320]

Gelukkig zijn er meer manieren om een Linux VM te draaien dan in een enterprise omgeving. Zo gebruik ik op mijn werk Macbook VirtualBox voor een Windows en een Linux guest. Het is namelijk gratis in tegenstelling tot VMware Workstation of Parallels en werkt net zo goed.

[Erik-Hendriks]

VMware is ook gratis voor niet commercieel gebruik.
Mijn virtualbox laat m'n Ubuntu steeds crashen na de laatste update van vorige week. Weer met kvm begonnen, is wel een stuk trager viel mij op.

[rbr320]

VMware is ook gratis voor niet commercieel gebruik.

Volgens mij valt privégebruik bij een commercieel bedrijf ook onder commercieel gebruik. In ieder geval doet VirtualBox prima wat ik wil. Ik gebruik overigens Solus als Linux desktop.

[IStealYourGun]

How is VirtualBox licensed?
The VirtualBox base package contains the full VirtualBox source code and platform binaries and is licensed under the GNU General Public License, version 2. You can distribute and modify the base package, provided that you distribute all modifications under the GPLv2 as well.

The VirtualBox Extension Pack is available under the VirtualBox Extension Pack Personal Use and Evaluation License, which is a free license for personal, educational or evaluation use, or an Enterprise License, which is a for-fee license that allows most commercial, non-distribution uses restricted by the PUEL.

More information about the Oracle VM VirtualBox Enterprise License for the VirtualBox Extension Pack can be found on the Oracle VM VirtualBox pages, which also contains a link to the Oracle Store where you can directly buy licenses. Please contact Oracle for additional information.

For information about a license to distribute the VirtualBox Extension Pack, please contact vbox_oem_sales_ww@….

Voor alle duidelijkheid, enkel van toepassing op de VirtualBox Extension Pack.

[CAPSLOCK2000]

Ik snap niet dat ze virtualbox drivers in de kernel gaan integreren, je hebt toch al KVM om virtual machines te draaien. Volgens mij draaien de meeste bedrijven die een virtual enironment draaien onder Linux KVM of RHEV.

Dat is het Linux-model. Iedereen mag drivers leveren. Zolang anderen geen last hebben van jouw driver is alles welkom. Het doet er niet toe hoe groot of klein de markt is, dat speelt geen rol. Als jij een driver voor je waterkoker hebt geschreven dan zal Linus die met liefde opnemen zolang de code aan alle regels voldoet.
Zolang iemand de moeite wil doen om de code te onderhouden zodat anderen er geen last van hebben mag de code de kernel in.

[Hero of Time]

Let op waar je het over hebt. Je noemt KVM, dat is de hypervisor. Dit bericht gaat specifiek over de Guest Tools, iets wat je gebruikt binnen de VM, niet om een VM te draaien.
Het klopt dat er ook KVM guest zaken in de kernel zit, maar dat is net zo het geval voor Xen. Je opmerking zou net zo goed voor KVM kunnen gelden, aangezien Xen eerder was.

Wat de VirtualBox Guest Tools voornamelijk doen, is interessant voor desktop gebruik. Servers draaien zonder GUI, dus wat heb je dan aan een hogere resolutie en OpenGL?

[hackerhater]

Dit zijn de drivers voor de guestOS-en.
Dus niet een Linux-host, maar een Linux-installatie in de VM.

[Hero of Time]

Klinkt heel mooi. Ik heb vroeger de handleiding op het VB forum geschreven hoe men de tools in Linux kan installeren via de ISO. Jammer dat Shared Folders er niet direct in zal zitten, maar de eerste stappen zijn geweldig om te horen. Scheelt zo veel werk voor mensen die verwachten dat het 'gewoon werkt'.

Wat ook een voordeel is wanneer het in de kernel zit, is dat het dan als algemene functie werkt en geen versie specifieke zaken zal bevatten. Bij veel distro's zitten de tools ook in de repo maar die lopen uiteindelijk enorm achter. Dit kan voor rare problemen zorgen of er blijven security bugs open staan omdat backporten niet te doen is (om die reden zitten de tools en VirtualBox zelf ook niet meer in Debian Stable).

[Dreamvoid]

Nadeel is dan wel dat als je op een distro zit die geen nieuwe kernels meer krijgt, je de VB-drivers ook niet meer kan updaten.

[Hero of Time]

Het zit in de kernel. De distro maintainer houd updates hiervan bij, als het goed is. De basis functionaliteit die je wilt blijft gewoon beschikbaar en zou dus altijd op dezelfde manier moeten werken. Dus of je nou op kernel 4.16 zit, of straks op 5.0 zou dan niets uit moeten maken.

Wordt je betreffende kernel niet meer ondersteund upstream, dan zal de distro eventuele fouten in dit deel moeten patchen of een nieuwere aan moeten bieden. Of je blijft op een distro release die helemaal geen updates meer krijgt, dan moet je IMO niet piepen en gewoon upgraden.

[nvaert1986]

Ik zit mensen hier klagen over de grootte van de kernel. Als die dan toch echt te groot is dan compileer je de kernel toch zelf? Kan zelfs zonder initrd indien gewenst. Zo heb ik een kernel voor m'n laptop met alles wat ik nodig heb en die is zo'n 7MB en kan nog kleiner als het moet. Is snel en lost het hele probleem qua grootte en onoverzichtelijke modules op

[P1nGu1n]

Hans de Goede blijkt ook nog eens Nederlander te zijn

Bron

[himlims_]

hans was/is in loondienst bij redhat, toffe kerel! erg gericht op licentie/voorwaarden, en maakt zich hard voor opensource software en standaarden. zorgt dat de downloads (os) geen foutieve games/textures etc. bevatten welke rechten aan kleven. ken er weinig die zo fanatiek zijn als hij

[Anonymoussaurus]

Klinkt ook totaal niet Nederlands (of Belgisch) .

Hier wat meer info over hem:

• http://linuxplumbersconf.org/ocw/users/43
• http://hansdegoede.livejournal.com/

[Reactie gewijzigd door Anonymoussaurus op 24 juli 2024 10:01]

[MiesvanderLippe]

En waarom dan niet gewoon open-vm-tools? Wat een onzin om dit in de generieke kernel te bouwen...

[GekkePrutser]

Oooh eindelijk!!

Ik gebruik nu VirtualBox op een dedicated server bij Scaleway maar omdat zij custom kernels gebruiken om te booten is het elke keer weer een geklooi met compileren van de drivers. Bijna elke keer gaat er wel wat stuk.

Ik gebruik VirtualBox en niet KVM omdat ik dan de VMs ook op andere platformen kan draaien zonder aanpassingen.

Edit: Shit, het zijn alleen maar de gastdrivers. Dus nog steeds geklooi met compileren voor mij.

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 10:01]

[aldieaccounts]

Wat een boel mensen zeuren over bloat zeg. Het is gewoon een extra kernel module, je *hoeft* hem niet te laden hoor. Zal default ook niet geladen worden lijkt me. Als er een nieuwe netwerk kaart ondersteund wordt gaan mensen toch ook niet klagen over bloat?

[aldieaccounts]

Boehoe, vboxguest.ko is hier 390k groot. Als 390k diskspace een probleem is dan moet je maar 1 film weggooien. Er worden voortdurend nieuwe drivers voor allerhande dingen aan linux toegevoegd (en ook wel zo nu en dan oude weggesmeten). Het is niet anders dan een driver voor hardware en daar hoor ik niemand over.

Het is juist hulde als de driver een 'officiele' kernel driver wordt (net zoals voor xen en hyper-V, trouwens) .

[Ventieldopje]

Sterker nog, het is een module ... die hoef je niet eens te bouwen! Al stop je er een miljard modules in dan wordt alleen de source groter en zelfs dat zou je modulair binnen kunnen halen.

Kortom je micro kernel zal net zo micro blijven