Kernel Mode-Setting pushed voor kernel 2.6.29

[Huub Reuver]

Bij de introductie van de 2.6.28-kernel was je misschien opgevallen
dat er voorbereidingen zijn getroffen voor kernel mode-setting in
2.6.29.

Even een willekeurige link:
http://www.phoronix.com/scan.php?page=news_item&px=Njk2MA

Het lijkt erop dat RedHat en Intel in navolging van Microsoft proberen
kerneldrivers voor X compleet op kernel-niveau te laten werken.

Voordelen:
- "faster VT-switching"
- "improved suspend and resume support"
- "flicker-free boot experience"

Nadelen:
- userproces (X) zit direct in de kernel te wroeten.
- idem voor binary-only kernels

Is dit alleen hyping of brengt het ook echte voordelen?
Het VT-switchen lijkt mij alleen leuk voor kernel-hackers (en die zullen
toch meestal via een externe terminal zitten te werken, zodat ze niet
hoeven switchen i.p.v. sneller).

Verder lijkt mij dit meer in de trent van "dan kunnen we de gebruikers
laten wachten met een leuker plaatje, want 24bpp, i.p.v. in een beperkte
tekstmode.

Met vriendelijke groet,
Huub Reuver

[Rob]

Men doet dit om bedrijven te pesten die binaire X drivers maken, zoals Nvidia.

Slechte zaak. Nvidia doet een hoop moeite voor Linux drivers, er zijn vele
enthousiaste gebruikers, en het heeft geen pas om deze vanuit een stel
fanatieke anti-binary fanatici weg te pesten.

[Philip Paeps]

Post by Rob
Men doet dit om bedrijven te pesten die binaire X drivers maken, zoals Nvidia.
Slechte zaak. Nvidia doet een hoop moeite voor Linux drivers, er zijn vele
enthousiaste gebruikers, en het heeft geen pas om deze vanuit een stel
fanatieke anti-binary fanatici weg te pesten.

Ik snap het verband niet goed. Kan je deze vreemde stelling even toelichten?

- Philip

[Rob]

Post by Philip Paeps

Post by Rob
Men doet dit om bedrijven te pesten die binaire X drivers maken, zoals Nvidia.
Slechte zaak. Nvidia doet een hoop moeite voor Linux drivers, er zijn vele
enthousiaste gebruikers, en het heeft geen pas om deze vanuit een stel
fanatieke anti-binary fanatici weg te pesten.

Ik snap het verband niet goed. Kan je deze vreemde stelling even toelichten?

Er is een groep kernel ontwikkelaars die tegen binary (closed-source)
drivers is. Deze groep doet voortdurend dingen waar de makers van dat
soort drivers last van hebben. Interfaces veranderen, functies ontoegankelijk
maken, etc.
Deze situatie rond videodrivers is de zoveelste stap in dat plan.
Men wil dat Nvidia de drivers opensource maakt, en doet alles om dat
te bereiken. Als het resultaat is dat Nvidia uit de Linux wereld stapt
dan vind men dat ook prima.
Ik vind het jammer dat dit spelletje gespeeld wordt.

[Philip Paeps]

Post by Rob

Post by Philip Paeps

Post by Rob
Men doet dit om bedrijven te pesten die binaire X drivers maken, zoals Nvidia.
Slechte zaak. Nvidia doet een hoop moeite voor Linux drivers, er zijn
vele enthousiaste gebruikers, en het heeft geen pas om deze vanuit een
stel fanatieke anti-binary fanatici weg te pesten.

Ik snap het verband niet goed. Kan je deze vreemde stelling even toelichten?

Er is een groep kernel ontwikkelaars die tegen binary (closed-source)
drivers is.

Helemaal ongelijk hebben ze niet. Vergeet ook niet dat binary kernel modules
een "grey area" zijn in de context van de GPL.

Post by Rob
Deze groep doet voortdurend dingen waar de makers van dat soort drivers last
van hebben. Interfaces veranderen, functies ontoegankelijk maken, etc.

Als je dat echt denkt, vrees ik dat je last hebt van paranoia. Er is geen
complot. Backward compatibility is ongelofelijk moeilijk en als je vooruit
wil komen moet je af en toe wat meubels omver gooien.

Interfaces worden veranderd omdat kernel developers (de mensen die effectief
aan de kernel hacken) er nood aan hebben. Als dat problemen veroorzaakt voor
buitenstaanders, is dat een ongelukkig maar onoverkomelijke bijzaak.

Vergeet niet dat het chasen van alle in-tree code die door een aanpassing
geïmpacteerd wordt ook geen triviale investering van tijd is. Als je ook nog
rekening moet houden met out-of-tree consumers kom je nooit een meter vooruit.

Als je met de Linux kernel begint, weet je dat er maar twee zekerheden zijn:
de stabiliteit van de userspace interfaces en de volatiliteit van de kernel
interfaces. Als je code in kernel mode moet draaien heb je twee keuzes: open
source het en submit het, of steek resources in het volgen van moving targets.

Post by Rob
Deze situatie rond videodrivers is de zoveelste stap in dat plan. Men wil
dat Nvidia de drivers opensource maakt, en doet alles om dat te bereiken.
Als het resultaat is dat Nvidia uit de Linux wereld stapt dan vind men dat
ook prima.

Er is geen plan. Er zijn geen black helicopters. Mode setting hoort gewoon
niet in userspace en het is uitstekend nieuws dat er eindelijk eens iemand de
hondenjob op zich genomen heeft om dat boeltje eindelijk in de kernel te duwen
waar het hoort. Als er out-of-tree consumers last van hebben, is dat gewoon
jammer.

Post by Rob
Ik vind het jammer dat dit spelletje gespeeld wordt.

Je ziet spoken.

- Philip

[Rob]

Post by Philip Paeps
Er is geen plan. Er zijn geen black helicopters. Mode setting hoort gewoon
niet in userspace en het is uitstekend nieuws dat er eindelijk eens iemand de
hondenjob op zich genomen heeft om dat boeltje eindelijk in de kernel te duwen
waar het hoort. Als er out-of-tree consumers last van hebben, is dat gewoon
jammer.

Dit verhaal is gewoon wat op dat moment de mode is. Nu hoort er ineens
wat in de kernel terwijl vergelijkbare argumenten bij andere interfaces
altijd afgedaan werden met "dat hoort niet in de kernel".

Zo hoort er naar mijn mening een fatsoenlijke geluidsmixing interface in
de kernel. Belachelijk dat maar 1 proces de geluidskaart kan openen, nog
belachelijker dat er dan 10 userprocessen ontwikkeld worden die allemaal
"de beheerder van de geluidskaart" moeten zijn zonder dat er 1 standaard
interface is waarmee een userproces daarmee kan communiceren.

Daardoor zitten we nog steeds met allerlei geluidskaart ellende in Linux
die er in Windows helemaal niet is. Daar is het geen probleem als twee
programma's geluid willen maken want de manier waarop dat moet die kent
iedereen.

Dus het verhaal dat modeswitching in de kernel moet is gewoon hypocriet,
die komt alleen maar even handig uit in de strijd tegen de videokaart
fabrikanten...

[Sabayon User]

Post by Rob
Zo hoort er naar mijn mening een fatsoenlijke geluidsmixing interface in
de kernel. Belachelijk dat maar 1 proces de geluidskaart kan openen,
nog belachelijker dat er dan 10 userprocessen ontwikkeld worden die
allemaal "de beheerder van de geluidskaart" moeten zijn zonder dat er 1
standaard interface is waarmee een userproces daarmee kan communiceren.
Daardoor zitten we nog steeds met allerlei geluidskaart ellende in Linux
die er in Windows helemaal niet is. Daar is het geen probleem als twee
programma's geluid willen maken want de manier waarop dat moet die kent
iedereen.

Met een "fatsoenlijke" geluidskaart zoals de Soundblaster Live (EMUK101)
heb je dit probleem niet.

Je hebt wel een punt, waarom kan onboard geluidsrommel wel goed
functioneren onder Windows (meerdere streams) en niet onder Linux.

[Sabayon User]

Post by Sabayon User
Met een "fatsoenlijke" geluidskaart zoals de Soundblaster Live (EMUK101)
heb je dit probleem niet.
Je hebt wel een punt, waarom kan onboard geluidsrommel wel goed
functioneren onder Windows (meerdere streams) en niet onder Linux.

Ter aanvulling.
Wellicht zijn er commerciele drivers die onboard kaarten wel goed laten
werken.

Heb in de jaren '90 zelf ook commerciele drivers gebruikt voor geluid
(Soundblaster ISA geluidskaart) en printen (Canon inkjetprinter).
Dus het kan wel was destijds mijn gedachte en voor de kosten hoefde ik
het niet te laten. Beide iets van 10 gulden per stuk ;-)

[Rob]

Post by Sabayon User

Post by Rob
Zo hoort er naar mijn mening een fatsoenlijke geluidsmixing interface in
de kernel. Belachelijk dat maar 1 proces de geluidskaart kan openen,
nog belachelijker dat er dan 10 userprocessen ontwikkeld worden die
allemaal "de beheerder van de geluidskaart" moeten zijn zonder dat er 1
standaard interface is waarmee een userproces daarmee kan communiceren.
Daardoor zitten we nog steeds met allerlei geluidskaart ellende in Linux
die er in Windows helemaal niet is. Daar is het geen probleem als twee
programma's geluid willen maken want de manier waarop dat moet die kent
iedereen.

Met een "fatsoenlijke" geluidskaart zoals de Soundblaster Live (EMUK101)
heb je dit probleem niet.

Staat deze dan wel meerdere opens van /dev/dsp e.d. toe?

Post by Sabayon User
Je hebt wel een punt, waarom kan onboard geluidsrommel wel goed
functioneren onder Windows (meerdere streams) en niet onder Linux.

Omdat er in Windows een fatsoenlijk geluids subsysteem in de kernel is,
wat user processen kunnen aanroepen via standaard DLL's zonder te weten
wat voor geluidskaart er is, en dit subsysteem zelf zorgt voor het mixen
van bronnen als de kaart dit niet kan. Dit is dus een functionaliteit die
een geluidskaart fabrikant niet in zijn driver hoeft te verwerken.

In Linux is dat wel voorgesteld maar weggehoond door de Linux kernel
ontwikkelaars die vonden dat dit een userspace issue was. Er moest maar
een userproces komen wat de geluidskaart opende en waar alle programma's
die geluid willen maken aan zouden connecten in plaats van aan de geluidskaart.

Een zo geschiedde. 10 keer. Tal van verschillende geluidsmanagers ontstonden
en er was niet een enkele toegangsmethode via een standaard DLL (shared
library).
Gevolg: er is 10 keer ontwikkelmoeite verspild en nou werkt het NOG niet,
omdat er geen standaard is. Leuk dat je kunt kiezen, maar je WILT niet
kiezen, je wilt dat het gewoon werkt.

Dit is een duidelijk verschil tussen Linux en Windows, wat steeds weer
terug komt. 1 oplossing die gewoon werkt in Windows, en meerdere oplossingen
en "keuzevrijheid" in Linux, die er voor zorgt dat het hele probleem niet
is opgelost omdat dat probleem juist het aanbieden van een standaard was.

Maar wat extra schrijnend is, is dat in een geheel vergelijkbare situatie
m.b.t. de Kernel Mode-Setting ineens gekozen is voor een kernel oplossing,
terwijl daar al een usermode oplossing in gebruik was.

Gaan we nu ook een kernelmode geluidsoplossing krijgen?
Zodat Skype gewoon werkt terwijl je in je browser op een pagina zit waar
een filmpje afgedraaid wordt met geluid?
Of zal dat altijd teveel gevraagd blijven voor Linux?

[Sabayon User]

Post by Rob

Post by Sabayon User
Met een "fatsoenlijke" geluidskaart zoals de Soundblaster Live
(EMUK101) heb je dit probleem niet.

Staat deze dan wel meerdere opens van /dev/dsp e.d. toe?

Ja.

[Sabayon User]

Post by Rob

Post by Sabayon User
Met een "fatsoenlijke" geluidskaart zoals de Soundblaster Live
(EMUK101) heb je dit probleem niet.

Staat deze dan wel meerdere opens van /dev/dsp e.d. toe?

Een ander Linux geluidsprobleem is meerdere geluidskaarten.
Mijn USB headset is ook geluidskaart en die werd eerder geladen dan de
sounblaster. Bovendien moet de USB ingeprikt zijn tijdens de start van
het systeem, anders geen geluid. Hoezo Plug-And-Pray.

Het probleem met de volgorde is wel op te lossen door wat configfiles aan
te passen, maar echt gebruikersvriendelijk is het niet. Waarom niet on
the fly kunnen wisselen.

Het kan wel: in Twinkel en Skype kan je immers wel aangeven welk geluid
via welke geluidskaart moet.
Dus oproepsignaal via de boxen (en ja het belsignaal komt dwars door door
elkaar spelende video's, mp3's en flash-applicaties ;-)) en het gelul
door de headset.

Met een beetje geknutsel is het ook mogelijk om een handsfree BT set te
koppelen.

Meer info over meerdere geluidskaarten (paragraaf 4.8):
http://www.gentoo.org/doc/en/alsa-guide.xml

[Rob]

Post by Sabayon User

Post by Rob

Post by Sabayon User
Met een "fatsoenlijke" geluidskaart zoals de Soundblaster Live
(EMUK101) heb je dit probleem niet.

Staat deze dan wel meerdere opens van /dev/dsp e.d. toe?

Een ander Linux geluidsprobleem is meerdere geluidskaarten.
Mijn USB headset is ook geluidskaart en die werd eerder geladen dan de
sounblaster. Bovendien moet de USB ingeprikt zijn tijdens de start van
het systeem, anders geen geluid. Hoezo Plug-And-Pray.

Dit probleem had ik vroeger ook, ik heb naast de onboard geluidskaart
(intel) een USB kaart. Maar tegenwoordig werkt dat wel goed. Kennelijk
is de detectie volgorde veranderd.
(USB geluid bij prikken en loshalen heeft hier wel altijd gewerkt)

Post by Sabayon User
Het kan wel: in Twinkel en Skype kan je immers wel aangeven welk geluid
via welke geluidskaart moet.
Dus oproepsignaal via de boxen (en ja het belsignaal komt dwars door door
elkaar spelende video's, mp3's en flash-applicaties ;-)) en het gelul
door de headset.

Dat werkt hier dus niet met het onboard geluid. Daarom heb ik ook die
USB geluids adapter, daar hangt Skype aan.
Maar het blijft prutswerk in vergelijking met Windows.

Komop opensource ontwikkelaars! Het moet toch mogelijk zijn om iets minstens
net zo goed te laten werken als in Windows!

[Sabayon User]

Post by Rob
Dit probleem had ik vroeger ook, ik heb naast de onboard geluidskaart
(intel) een USB kaart. Maar tegenwoordig werkt dat wel goed. Kennelijk
is de detectie volgorde veranderd.
(USB geluid bij prikken en loshalen heeft hier wel altijd gewerkt)

Headset uit hoek vist (overbodig geworden vanwege router met SIP
mogelijkheden) inprikt en concludeert dat er nog steeds geen /dev/dsp1
bijkomt na inprikken.

Welke distributie en versienummer gebruik je?

Ben zelf wel weer toe aan wat nieuws, draai nu Sabayon 3.5 64bits.
Sabayon 4.1 is reeds binnen, maar SUSE wil ik ook wel weer een kans geven
met hun 11.1 release ondanks de wat beperkte keus aan software in YAST.
En ook dat codec gezeur was een reden om naar Sabayon over te stappen.
Vrees dat dit nog steeds niet out of the SuSe box werkt..

[Rob]

Post by Sabayon User

Post by Rob
Dit probleem had ik vroeger ook, ik heb naast de onboard geluidskaart
(intel) een USB kaart. Maar tegenwoordig werkt dat wel goed. Kennelijk
is de detectie volgorde veranderd.
(USB geluid bij prikken en loshalen heeft hier wel altijd gewerkt)

Headset uit hoek vist (overbodig geworden vanwege router met SIP
mogelijkheden) inprikt en concludeert dat er nog steeds geen /dev/dsp1
bijkomt na inprikken.
Welke distributie en versienummer gebruik je?

Dit werkt in SuSE al zo lang als ik dat ding heb, en dat was zeker al
bij 10.0 maar wellicht al bij 9.3.
Bij 10.0 was er wel het probleem dat de USB sound adapter nummer 0 werd
en de onboard sound nummer 1.

In OpenSuSe 10.3 en 11.1 werkt het feilloos.

[Huub Reuver]

Post by Sabayon User

Post by Rob
Dit probleem had ik vroeger ook, ik heb naast de onboard geluidskaart
(intel) een USB kaart. Maar tegenwoordig werkt dat wel goed. Kennelijk
is de detectie volgorde veranderd.
(USB geluid bij prikken en loshalen heeft hier wel altijd gewerkt)

Headset uit hoek vist (overbodig geworden vanwege router met SIP
mogelijkheden) inprikt en concludeert dat er nog steeds geen /dev/dsp1
bijkomt na inprikken.

Door het aansluiten van boxen (of een variant hiervan) wordt er ineens
een nieuwe device gevonden?
Zijn er al systemen waarvoor de geluidskaart dat detecteerd?

Als je een USB geluidskaart inprikt zou zelfs zonder headset een
melding geregistreerd moeten worden. Zichtbaar met dmesg en lsusb
(of usbvies als je liever iets grafisch gebruikt).

Met vriendelijke groet,
Huub Reuver

PS een koptelefoon maakt daarbij volgens mij niet uit voor de detectie.

[Dick Hoogendijk]

Post by Huub Reuver
Door het aansluiten van boxen (of een variant hiervan) wordt er ineens
een nieuwe device gevonden? Zijn er al systemen waarvoor de
geluidskaart dat detecteerd?

Zelfs mijn onboard geluids'kaart' detecteert de aansluiting van speakers
of headset. Het verwijderen wordt trouwens ook 'gezien'. De kaartdriver
moet daar wel voor geschikt zijn. Dat spreekt.

Post by Huub Reuver
PS een koptelefoon maakt daarbij volgens mij niet uit voor de
detectie.

Toch wel. Het verschil wordt opgemerkt.

[Sabayon User]

Post by Huub Reuver

Post by Sabayon User
Headset uit hoek vist (overbodig geworden vanwege router met SIP
mogelijkheden) inprikt en concludeert dat er nog steeds geen /dev/dsp1
bijkomt na inprikken.

Door het aansluiten van boxen (of een variant hiervan) wordt er ineens
een nieuwe device gevonden?
Zijn er al systemen waarvoor de geluidskaart dat detecteerd?
Als je een USB geluidskaart inprikt zou zelfs zonder headset een melding
geregistreerd moeten worden. Zichtbaar met dmesg en lsusb (of usbvies
als je liever iets grafisch gebruikt).
Met vriendelijke groet,
Huub Reuver
PS een koptelefoon maakt daarbij volgens mij niet uit voor de detectie.

Het is een headset met ingebouwde geluidskaart.
lsusb detecteerd de zojuist ingeprikte geluidskaart wel, maar de
sounserver pikt dit niet op.

Het sounddevice wordt dus opgemerkt door de kernel en verschijnt dan ook
in de VMWARE device balk. In de daarin draaiende Windows XP kan ik de
headset dus bijschakelen in de virtual machine.

Het probleem is de soundserver die slechts initialiseerd tijdens
opstarten PC of X.

[unknown]

Post by Sabayon User
Het probleem is de soundserver die slechts initialiseerd tijdens
opstarten PC of X.

Juist, het probleem IS de soundserver. Punt.

Het zijn allemaal voortbrengselen van Satan. Na 20 jaar is het nog
steeds niet makkelijk om gewoon geluid te hebben in Linux.

Bart

[Sabayon User]

Post by unknown

Post by Sabayon User
Het probleem is de soundserver die slechts initialiseerd tijdens
opstarten PC of X.

Juist, het probleem IS de soundserver. Punt.
Het zijn allemaal voortbrengselen van Satan. Na 20 jaar is het nog
steeds niet makkelijk om gewoon geluid te hebben in Linux.

Je kan ook overdrijven Bart.
Met een EMUK101 kaartje is er best mee te leven.

Geen idee wat Sounblaster tegenwoordig levert, maar ik neem aan dat ook
deze moderne Soundblaster kaarten goed werken onder Linux.

Kost een paar centen, maar dan heb je ook wat ;-)

[unknown]

Post by Sabayon User

Post by unknown

Post by Sabayon User
Het probleem is de soundserver die slechts initialiseerd tijdens
opstarten PC of X.

Juist, het probleem IS de soundserver. Punt.
Het zijn allemaal voortbrengselen van Satan. Na 20 jaar is het nog
steeds niet makkelijk om gewoon geluid te hebben in Linux.

Je kan ook overdrijven Bart.
Met een EMUK101 kaartje is er best mee te leven.

Ja, en op mijn laptop doet ie het ook. Maar op mijn desktop werkt alles
behalve Flash-geluid, en bij mijn vader werkt het geheel niet. En die
kan dan kiezen uit 7 audio 'dingen' OSS/ALSA/Autodetect/blabla, die het
allemaal niet doen. Erger nog, hij krijgt een zeer vage melding als ie
het probeert. Dit komt op mij over als een zeer onprofessioneel systeem.
En het is al bezig sinds OSS 'vervangen' ging worden door ALSA. En wat
hebben we nu? OSS bestaat nog steeds, ALSA is erbij gekomen, we hebben
ESS, PulseAudio, kArts, en meer gedoe. Ze doen allemaal hetzelfde, maar
net niet.

<rant>
Degene dit soort 'keuzes' prettig vindt is gek. Dit zijn zaken die de
kernel moet regelen en niet een of ander halfbakken user space
programma. Ik zit bijvoorbeeld ook niet te wachten op de 'keuze' voor
een I/O scheduler, of een bepaalde memory management strategie.
</rant>

Post by Sabayon User
Geen idee wat Sounblaster tegenwoordig levert, maar ik neem aan dat ook
deze moderne Soundblaster kaarten goed werken onder Linux.
Kost een paar centen, maar dan heb je ook wat ;-)

Ik wil niks bijzonders, ik wil gewoon muziek kunnen luisteren (soms),
geluid horen bij film(pje)s. Gewoon geluid. Gewoon 'cat mysong.wav >
/dev/dsp'. Niet meer. Niet minder.

Bart

[Sabayon User]

Post by unknown

Post by Sabayon User
Geen idee wat Sounblaster tegenwoordig levert, maar ik neem aan dat ook
deze moderne Soundblaster kaarten goed werken onder Linux.
Kost een paar centen, maar dan heb je ook wat ;-)

Ik wil niks bijzonders, ik wil gewoon muziek kunnen luisteren (soms),
geluid horen bij film(pje)s. Gewoon geluid. Gewoon 'cat mysong.wav >
/dev/dsp'. Niet meer. Niet minder.

Dan toch die onboard rommel uitschakelen en een "fatsoenlijke"
geluidskaart kopen. En ja die zijn er ook in USB uitvoering:

http://www.soundblaster.com/products/

[Martijn van Buul]

Post by Sabayon User
Dan toch die onboard rommel uitschakelen en een "fatsoenlijke"
http://www.soundblaster.com/products/

Uw gebrek aan clue begint lichtelijk aanstootgevend te worden.

[Sabayon User]

Post by Martijn van Buul

Post by Sabayon User
Dan toch die onboard rommel uitschakelen en een "fatsoenlijke"
http://www.soundblaster.com/products/

Uw gebrek aan clue begint lichtelijk aanstootgevend te worden.

Slechts praktisch ingesteld Trollemansz.

[Huub Reuver]

Post by unknown

Post by Sabayon User

Post by unknown

Post by Sabayon User
Het probleem is de soundserver die slechts initialiseerd tijdens
opstarten PC of X.

Juist, het probleem IS de soundserver. Punt.
Het zijn allemaal voortbrengselen van Satan. Na 20 jaar is het nog
steeds niet makkelijk om gewoon geluid te hebben in Linux.

Je kan ook overdrijven Bart.
Met een EMUK101 kaartje is er best mee te leven.

Ja, en op mijn laptop doet ie het ook. Maar op mijn desktop werkt alles
behalve Flash-geluid, en bij mijn vader werkt het geheel niet. En die
kan dan kiezen uit 7 audio 'dingen' OSS/ALSA/Autodetect/blabla, die het
allemaal niet doen. Erger nog, hij krijgt een zeer vage melding als ie
het probeert. Dit komt op mij over als een zeer onprofessioneel systeem.
En het is al bezig sinds OSS 'vervangen' ging worden door ALSA. En wat
hebben we nu? OSS bestaat nog steeds, ALSA is erbij gekomen, we hebben
ESS, PulseAudio, kArts, en meer gedoe. Ze doen allemaal hetzelfde, maar
net niet.
<rant>
Degene dit soort 'keuzes' prettig vindt is gek. Dit zijn zaken die de
kernel moet regelen en niet een of ander halfbakken user space
programma. Ik zit bijvoorbeeld ook niet te wachten op de 'keuze' voor
een I/O scheduler, of een bepaalde memory management strategie.
</rant>

Ik zet persoonlijk altijd mijn vraagtekens bij de systeembeheerder.
Want overschakelen van OSS naar ALSA is alweer een tijdje geleden.

Zelfs een "vage foutmelding" moet traceerbaar zijn.

Is het mogelijk om dat systeem eens te starten met een live-systeem
van SUSE, Ubuntu of Fedora?
Een goede installer kan veel rechttrekken wat een systeembeheerder
scheef heeft getrokken. Deze zijn geschreven voor (bijna) dummies
en een ideale oplossing voor iemand die geen zin heeft in de
materie te duiken.

De live-CD/USB-stick is natuurlijk een snelle check om te kijken
of je je tijd verdoet.

Met een beetje geluk hoef je alleen te kijken naar de instellingen
en deze over te nemen voor het geinstalleerde systeem.

Post by unknown

Post by Sabayon User
Geen idee wat Sounblaster tegenwoordig levert, maar ik neem aan dat ook
deze moderne Soundblaster kaarten goed werken onder Linux.
Kost een paar centen, maar dan heb je ook wat ;-)

Ik wil niks bijzonders, ik wil gewoon muziek kunnen luisteren (soms),
geluid horen bij film(pje)s. Gewoon geluid. Gewoon 'cat mysong.wav >
/dev/dsp'. Niet meer. Niet minder.

Jammer dat dat niet werkt met MP3.

Met vriendelijke groet,
Huub Reuver

[Sabayon User]

Post by Huub Reuver

Post by unknown
Ik wil niks bijzonders, ik wil gewoon muziek kunnen luisteren (soms),
geluid horen bij film(pje)s. Gewoon geluid. Gewoon 'cat mysong.wav >
/dev/dsp'. Niet meer. Niet minder.

Jammer dat dat niet werkt met MP3.

Ik mis de optie Sabayon live cd.
Als er 1 distributie zich richt op multimediaal spektakel is het Sabayon.
Bijkomend voordeel is de mogelijkheid om software te installeren via
Gentoo's portage. Is dan wel een strenge installer, maar wel de meest
uitgebreide software database die ik ken.

Uiteraard flikt Sabayon wat truukjes om patenten te omzeilen (oa MP3),
maar daar kan ik mee leven. Zoalang het out of the box goed werkt hoor je
mij niet klagen.

Nogmaals: onboard sound en video mijden als de pest, het is en blijft
rommel.

[unknown]

Post by Sabayon User
Nogmaals: onboard sound en video mijden als de pest, het is en blijft
rommel.

Je bedoelt "de Linux ondersteuning ervoor is en blijft rommel"?

[Dick Hoogendijk]

Post by unknown

Post by Sabayon User
Nogmaals: onboard sound en video mijden als de pest, het is en blijft
rommel.

Je bedoelt "de Linux ondersteuning ervoor is en blijft rommel"?

Mijn onboard spul wordt in elk geval prima ondersteund in de systemen
waarin ik geen 'kaarten' heb zitten. Ik gebruik solaris en als die er
geen drivers voor heeft doet 4-tech het uitstekend.

[unknown]

Post by Huub Reuver

Post by unknown

Post by Sabayon User

Post by unknown

Post by Sabayon User
Het probleem is de soundserver die slechts initialiseerd tijdens
opstarten PC of X.

Juist, het probleem IS de soundserver. Punt.
Het zijn allemaal voortbrengselen van Satan. Na 20 jaar is het nog
steeds niet makkelijk om gewoon geluid te hebben in Linux.

Je kan ook overdrijven Bart.
Met een EMUK101 kaartje is er best mee te leven.

Ja, en op mijn laptop doet ie het ook. Maar op mijn desktop werkt alles
behalve Flash-geluid, en bij mijn vader werkt het geheel niet. En die
kan dan kiezen uit 7 audio 'dingen' OSS/ALSA/Autodetect/blabla, die het
allemaal niet doen. Erger nog, hij krijgt een zeer vage melding als ie
het probeert. Dit komt op mij over als een zeer onprofessioneel systeem.
En het is al bezig sinds OSS 'vervangen' ging worden door ALSA. En wat
hebben we nu? OSS bestaat nog steeds, ALSA is erbij gekomen, we hebben
ESS, PulseAudio, kArts, en meer gedoe. Ze doen allemaal hetzelfde, maar
net niet.
<rant>
Degene dit soort 'keuzes' prettig vindt is gek. Dit zijn zaken die de
kernel moet regelen en niet een of ander halfbakken user space
programma. Ik zit bijvoorbeeld ook niet te wachten op de 'keuze' voor
een I/O scheduler, of een bepaalde memory management strategie.
</rant>

Ik zet persoonlijk altijd mijn vraagtekens bij de systeembeheerder.

Ik zet mijn vraagtekens bij het feit dat je een systeembeheerder nodig
hebt, voor het instellen van een geluidskaart.

Post by Huub Reuver
Want overschakelen van OSS naar ALSA is alweer een tijdje geleden.

Niet voor Ubuntu. Ik kan nog steeds kiezen.

Post by Huub Reuver
Zelfs een "vage foutmelding" moet traceerbaar zijn.

O, ik kom er zeker ook wel uit. Maar dat is het punt niet.

Post by Huub Reuver
Is het mogelijk om dat systeem eens te starten met een live-systeem
van SUSE, Ubuntu of Fedora?

Euhm. Drie verschillende systemen, die het /misschien/ kunnen? Sorry,
maar dit is de omgekeerde wereld.

Post by Huub Reuver
Een goede installer kan veel rechttrekken wat een systeembeheerder
scheef heeft getrokken. Deze zijn geschreven voor (bijna) dummies
en een ideale oplossing voor iemand die geen zin heeft in de
materie te duiken.

Er is niets scheefgetrokken. Een kale Ubuntu 8.10 install op brandnieuwe
Dell hardware. Niks exotisch, allemaal vrij verkrijgbaar in de markt als
'betrouwbaar' en 'goed'.

Post by Huub Reuver
De live-CD/USB-stick is natuurlijk een snelle check om te kijken
of je je tijd verdoet.

Snel? Als je hem hebt liggen misschien.

Post by Huub Reuver
Jammer dat dat niet werkt met MP3.

Again, you miss the point.

Bart

[Huub Reuver]

Post by unknown

Post by Huub Reuver

Post by unknown

Post by Sabayon User

Post by unknown

Post by Sabayon User
Het probleem is de soundserver die slechts initialiseerd tijdens
opstarten PC of X.

Juist, het probleem IS de soundserver. Punt.
Het zijn allemaal voortbrengselen van Satan. Na 20 jaar is het nog
steeds niet makkelijk om gewoon geluid te hebben in Linux.

Je kan ook overdrijven Bart.
Met een EMUK101 kaartje is er best mee te leven.

Ja, en op mijn laptop doet ie het ook. Maar op mijn desktop werkt alles
behalve Flash-geluid, en bij mijn vader werkt het geheel niet. En die
kan dan kiezen uit 7 audio 'dingen' OSS/ALSA/Autodetect/blabla, die het
allemaal niet doen. Erger nog, hij krijgt een zeer vage melding als ie
het probeert. Dit komt op mij over als een zeer onprofessioneel systeem.
En het is al bezig sinds OSS 'vervangen' ging worden door ALSA. En wat
hebben we nu? OSS bestaat nog steeds, ALSA is erbij gekomen, we hebben
ESS, PulseAudio, kArts, en meer gedoe. Ze doen allemaal hetzelfde, maar
net niet.
<rant>
Degene dit soort 'keuzes' prettig vindt is gek. Dit zijn zaken die de
kernel moet regelen en niet een of ander halfbakken user space
programma. Ik zit bijvoorbeeld ook niet te wachten op de 'keuze' voor
een I/O scheduler, of een bepaalde memory management strategie.
</rant>

Ik zet persoonlijk altijd mijn vraagtekens bij de systeembeheerder.

Ik zet mijn vraagtekens bij het feit dat je een systeembeheerder nodig
hebt, voor het instellen van een geluidskaart.

Ik heb in de praktijk veel 'systeembeheerders' gezien. Dus als ik over
een systeembeheerder praat maak ik geen onderscheid tussen en
thuisgebruiker en iemand die betaald wordt om met pc's te spelen.

Het zal niet de eerste keer zijn dat een 'normale gebruiker' een systeem
'gewoon installeert' terwijl een 'professional' tegen allerlei problemen
aanloopt.

Post by unknown

Post by Huub Reuver
Want overschakelen van OSS naar ALSA is alweer een tijdje geleden.

Niet voor Ubuntu. Ik kan nog steeds kiezen.

En wat kiest Ubuntu standaard?

Ervaring leert dat configuratie tegenwoordig erg goed is, maar dat je
de installatie pas moet aanpassen _NA_ de installatie (als je hebt
gecontroleerd dat het meeste werkt). Dat werkt voor veel systemen het
beste, ook voor Linux.

Gelukkig is de packagemanager van Ubuntu vrij goed dus kun je overbodige
packages eenvoudig achteraf verwijderen.

Om na de installatie even te controleren wat de standaard instelling
was is een live-CD in verhouding snel en simpel.
Of begin jij altijd met een herinstallatie?

Post by unknown

Post by Huub Reuver
Is het mogelijk om dat systeem eens te starten met een live-systeem
van SUSE, Ubuntu of Fedora?

Euhm. Drie verschillende systemen, die het /misschien/ kunnen? Sorry,
maar dit is de omgekeerde wereld.

Ik vraag je niet 3 verschillende systemen te testen. Ik vraag je alleen
of jouw keuze niet werkt of de standaardconfiguratie van Ubuntu.
En de andere staan erbij omdat ik niet kan weten of jij een voorkeur
hebt voor Ubuntu, SUSE of Fedora.

Post by unknown

Post by Huub Reuver
Een goede installer kan veel rechttrekken wat een systeembeheerder
scheef heeft getrokken. Deze zijn geschreven voor (bijna) dummies
en een ideale oplossing voor iemand die geen zin heeft in de
materie te duiken.

Er is niets scheefgetrokken. Een kale Ubuntu 8.10 install op brandnieuwe

^^^^^^ klinkt als niet standaard.

Post by unknown
Dell hardware. Niks exotisch, allemaal vrij verkrijgbaar in de markt als
'betrouwbaar' en 'goed'.

Installeert Ubuntu nog steeds uit zichzelf standaard OSS?
Dan hebben ze wel een steekje laten vallen, want ze liepen voor met veel
hardware-zaken op Debian. Ik had eigenlijk verwacht dat Ubuntu vanaf het
begin ALSA zou hebben gebruikt, standaard. En OSS misschien optioneel.

Overigens als ik een 'kale installatie' uitvoer moet ik zeker even kijken
of alles aanwezig is wat ik nodig heb om te kunnen werken. Sterker, ik weet
100% zeker dat als ik een kale installatie neerzet de geluidskaart niet
werkt.

Post by unknown

Post by Huub Reuver
De live-CD/USB-stick is natuurlijk een snelle check om te kijken
of je je tijd verdoet.

Snel? Als je hem hebt liggen misschien.

Ik weet niet hoe goed jij in foutzoeken bent, maar gezien je reacties
heb je wel iets anders te doen. Anders had je wel gemeld dat het systeem
inmiddels werkt.

Post by unknown

Post by Huub Reuver
Jammer dat dat niet werkt met MP3.

Again, you miss the point.

Waarschijnlijk niet.
Als een gebruiker expliciet een geluidsapplicatie start dan is het
eerder een mp3- of avi-player dan cat.

Vroeger moest het systeem gewoon werken. Tegenwoordig moet een systeem
uit de doos alles kunnen met alle software (inclusief obsolete software).

Dat noem ik niet reëel.

Met vriendelijke groet,
Huub Reuver

[unknown]

Post by Huub Reuver

Post by unknown

Post by Huub Reuver
Want overschakelen van OSS naar ALSA is alweer een tijdje geleden.

Niet voor Ubuntu. Ik kan nog steeds kiezen.

En wat kiest Ubuntu standaard?

Geen flauw idee. Precies het punt. Ik *wil* hier niet kunnen kiezen. Ik
wil gewoon geluid hebben.

Post by Huub Reuver
Ervaring leert dat configuratie tegenwoordig erg goed is, maar dat je
de installatie pas moet aanpassen _NA_ de installatie (als je hebt
gecontroleerd dat het meeste werkt). Dat werkt voor veel systemen het
beste, ook voor Linux.

Aanpassen? Ik wil gewoon simpel geluid hebben. Ik heb het hier niet over
FooBizBang versie 0.23beta-7. Ik heb het over geluid. Uit een
geluidskaart. Een stuk hardware van 15+ jaar oud. En *nog* krijgen 'wij
geeks' het niet eenduidig werkend.

Post by Huub Reuver
Gelukkig is de packagemanager van Ubuntu vrij goed dus kun je overbodige
packages eenvoudig achteraf verwijderen.

Ik bewonder je naiviteit. Het laatste wat ik zal proberen is core
packages als ALSA of OSS weggooien. Dan weet ik zeker dat er in de
toekomst er iets niet gaat werken (want l33thax0r1984 heeft namelijk
zijn baksel met OSS geschreven, want dat was zijn keus, en happycod3r
schreef het met ALSA).

Post by Huub Reuver
Om na de installatie even te controleren wat de standaard instelling
was is een live-CD in verhouding snel en simpel.
Of begin jij altijd met een herinstallatie?

Tuurlijk niet. Maar ik vind dit werkelijk zeer veel werk voor het
inschakelen van geluid.

Post by Huub Reuver
Ik vraag je niet 3 verschillende systemen te testen. Ik vraag je alleen
of jouw keuze niet werkt of de standaardconfiguratie van Ubuntu.

*Ik heb geen keuze gemaakt* UBUNTU maakte een keuze, die NIET werkt.

Post by Huub Reuver

Post by unknown
Er is niets scheefgetrokken. Een kale Ubuntu 8.10 install op brandnieuwe

^^^^^^ klinkt als niet standaard.

Met 'kaal' bedoel ik gewoon, simpel, Ubuntu CD erin, klikklik
installeren, klaar.

Post by Huub Reuver
Ik weet niet hoe goed jij in foutzoeken bent, maar gezien je reacties
heb je wel iets anders te doen. Anders had je wel gemeld dat het systeem
inmiddels werkt.

Het gaat om de PC van mijn vader. Ik woon niet meer thuis (al een
jaartje of twaalf niet meer).

Post by Huub Reuver

Post by unknown

Post by Huub Reuver
Jammer dat dat niet werkt met MP3.

Again, you miss the point.

Waarschijnlijk niet.
Als een gebruiker expliciet een geluidsapplicatie start dan is het
eerder een mp3- of avi-player dan cat.
Vroeger moest het systeem gewoon werken. Tegenwoordig moet een systeem
uit de doos alles kunnen met alle software (inclusief obsolete software).
Dat noem ik niet reëel.

And again..., you miss the point:

1. 'cat' is niet obsolete.
2. Ik test geluidskaarten altijd als volgt: cat /dev/urandom > /dev/dsp.
Als ik dan ruis hoor, weet ik dat iig mijn speakers het doen, de kabels
goed zitten en er wat drivers OK zitten.

Overigens vind ik dat die /dev/dsp (of welke /dev/* dan ook), gewoon raw
geluidsdata moet kunnen vreten, van verschillende bronnen en die dan
correct mixen. En ja, dat is een *kernel* feestje, geen
Alsosspulseaudioestkarts-monster.

Bart

[Rob]

Post by unknown
Overigens vind ik dat die /dev/dsp (of welke /dev/* dan ook), gewoon raw
geluidsdata moet kunnen vreten, van verschillende bronnen en die dan
correct mixen. En ja, dat is een *kernel* feestje, geen
Alsosspulseaudioestkarts-monster.

Ja dat vind ik ook. Maar dat mag kennelijk niet van de kernel ontwikkelaars.

Wat ik dan zo vreemd vind is dat ze iets vergelijkbaars voor video settings
ineens WEL erin willen. Dat is toch scheef.
De praktijk heeft nu toch wel ruimschoots aangetoond dat geluid in userspace
niet werkt.

[Huub Reuver]

Post by Sabayon User

Post by Rob
Zo hoort er naar mijn mening een fatsoenlijke geluidsmixing interface in
de kernel. Belachelijk dat maar 1 proces de geluidskaart kan openen,
nog belachelijker dat er dan 10 userprocessen ontwikkeld worden die
allemaal "de beheerder van de geluidskaart" moeten zijn zonder dat er 1
standaard interface is waarmee een userproces daarmee kan communiceren.
Daardoor zitten we nog steeds met allerlei geluidskaart ellende in Linux
die er in Windows helemaal niet is. Daar is het geen probleem als twee
programma's geluid willen maken want de manier waarop dat moet die kent
iedereen.

Met een "fatsoenlijke" geluidskaart zoals de Soundblaster Live (EMUK101)
heb je dit probleem niet.
Je hebt wel een punt, waarom kan onboard geluidsrommel wel goed
functioneren onder Windows (meerdere streams) en niet onder Linux.

Als ik een avi en mp3 tegelijk afspeel is eigenlijk het enige probleem
dat ik de niveau's niet onafhankelijk kan instellen (intel hda onboard
audio van realtek). Meerdere geluidsbronnen is geen probleem.

Alleen als ik een videostream pakt die niet vloeiend loopt hakkelt het
geluid van de MP3 ook. Niet echt verbazend.

En ik kan ook het geluid laten hakkelen als mijn systeem vol belast wordt.
Ook weer niet echt verbazend.

De vraag is natuurlijk of dat ligt aan het programma, de kernel of de
geluidschip. Ik heb niet het gevoel dat de kernel en de chip de
veroorzaker zijn. Als je speelt met 'nice' weet je misschien meer. En
verder heb je nog opties voor de scheduler die e.e.a. kunnen verbeteren.

Met vriendelijke groet,
Huub Reuver

[Rob]

Post by Huub Reuver
Als ik een avi en mp3 tegelijk afspeel is eigenlijk het enige probleem
dat ik de niveau's niet onafhankelijk kan instellen (intel hda onboard
audio van realtek). Meerdere geluidsbronnen is geen probleem.

Verhip er is kennelijk wat verbeterd. Ik werk sinds een paar dagen met
OpenSUSE 11.1 (kernel 2.6.27) en het werkt nu wel.

mplayer zegt nog wel:
[AO OSS] audio_setup: Can't open audio device /dev/dsp: Device or resource busy

Maar geeft vervolgens wel geluid.

Wacht, te vroeg geluichd. Mplayer werkt kennelijk via een sound proces.
Skype kan nog steeds geen geluid maken terwijl er iets afspeelt.

Het blijft wankel.

[unknown]

Post by Huub Reuver
Als ik een avi en mp3 tegelijk afspeel is eigenlijk het enige probleem
dat ik de niveau's niet onafhankelijk kan instellen (intel hda onboard
audio van realtek). Meerdere geluidsbronnen is geen probleem.
Alleen als ik een videostream pakt die niet vloeiend loopt hakkelt het
geluid van de MP3 ook. Niet echt verbazend.

Ik zou denken, die beiden hebben niks met elkaar te maken, waarom zou de
MP3 dan hakkelen als de videostream dat doet?

[Sabayon User]

Post by unknown
Ik zou denken, die beiden hebben niks met elkaar te maken, waarom zou de
MP3 dan hakkelen als de videostream dat doet?

Het blijft brak zo'n onboard soundkaart.
Daarom bouw ik bij iedere PC wissel de Sounblaster Live over.

Uiteraard pas nadat ik wederom heb ervaren dat de kwaliteit en drivers
van onboard geluidsrommel nog steeds niet voldoet ;-)

[unknown]

Post by Sabayon User

Post by unknown
Ik zou denken, die beiden hebben niks met elkaar te maken, waarom zou de
MP3 dan hakkelen als de videostream dat doet?

Het blijft brak zo'n onboard soundkaart.

Elke brakke onboard geluidskaart kan zoiets makkelijk trekken :)

[Sabayon User]

Post by unknown

Post by Sabayon User

Post by unknown
Ik zou denken, die beiden hebben niks met elkaar te maken, waarom zou
de MP3 dan hakkelen als de videostream dat doet?

Het blijft brak zo'n onboard soundkaart.

Elke brakke onboard geluidskaart kan zoiets makkelijk trekken

Kunnen wel, maar doen ho maar.
Iets met brakke linuxdrivers.

[Philip Paeps]

Post by Sabayon User

Post by unknown

Post by Sabayon User

Post by unknown
Ik zou denken, die beiden hebben niks met elkaar te maken, waarom zou
de MP3 dan hakkelen als de videostream dat doet?

Het blijft brak zo'n onboard soundkaart.

Elke brakke onboard geluidskaart kan zoiets makkelijk trekken

Kunnen wel, maar doen ho maar.
Iets met brakke linuxdrivers.

Submit patches (I have...). De ALSA developers horen graag van je.

- Philip

[Sabayon User]

Post by Philip Paeps

Post by Sabayon User
Kunnen wel, maar doen ho maar.
Iets met brakke linuxdrivers.

Submit patches (I have...). De ALSA developers horen graag van je.

Neem aan dat ze dit zelf ook weten.
Ga wel voor betere hardware, insteekkaartje inprikken gaat een stuk
sneller dan een driver schrijven ;-)

[Wietse Muizelaar]

Post by Sabayon User

Post by Philip Paeps

Post by Sabayon User
Kunnen wel, maar doen ho maar.
Iets met brakke linuxdrivers.

Submit patches (I have...). De ALSA developers horen graag van je.

Neem aan dat ze dit zelf ook weten.

Waar baseer je die aanname op?

[Rob]

Post by Philip Paeps

Post by Sabayon User

Post by unknown

Post by Sabayon User

Post by unknown
Ik zou denken, die beiden hebben niks met elkaar te maken, waarom zou
de MP3 dan hakkelen als de videostream dat doet?

Het blijft brak zo'n onboard soundkaart.

Elke brakke onboard geluidskaart kan zoiets makkelijk trekken

Kunnen wel, maar doen ho maar.
Iets met brakke linuxdrivers.

Submit patches (I have...). De ALSA developers horen graag van je.

Waarom de ALSA developers wel en de OSS developers niet?

[Huub Reuver]

Post by Philip Paeps

Post by Sabayon User

Post by unknown

Post by Sabayon User

Post by unknown
Ik zou denken, die beiden hebben niks met elkaar te maken, waarom zou
de MP3 dan hakkelen als de videostream dat doet?

Het blijft brak zo'n onboard soundkaart.

Elke brakke onboard geluidskaart kan zoiets makkelijk trekken

Kunnen wel, maar doen ho maar.
Iets met brakke linuxdrivers.

Submit patches (I have...). De ALSA developers horen graag van je.

Als je de originele post terugleest zie je een zeer snelle test
waarbij gevonden wordt dat meerdere geluiden gelijk spelen en dat
geluidsapplicaties elkaar kunnen storen.

Eigenlijk volgen er 2 conclusies:
- Zelfs met een simpele geluidskaart kunnen meerdere geluiden tegelijk
spelen.
- Geluid is niet goed als de video hakkelt.
Uit gebrek aan interesse was de laatste waarneming misschien ongelukkig
geformuleerd. Een conclusie dat de resultaten te verwachten zijn
is misschien wat kort door de bocht.

Robert merkt terecht op dat de weergave van de resultaten vragen oproepen.

Eigenlijk zijn over de storing er 3 conclusies mogelijk:
1- de test is niet goed uitgevoerd (voor de geluidsstoring dan)
2- de resultaten zijn niet accuraat weergegeven (er missen waarnemingen)
3- er is iets mis met linux, de geluidskaart of de driver

Robert, conclusie 1 of 2 zijn zeker mogelijk want het doel van de
test was niet uit te zoeken waarom het geluid stoorde.

Sabayon trekt al de conclusie dat er sprake is van brakke hardware en
brakke drivers.
Misschien kan Sabayon zijn conclusies onderbouwen?

En dat allemaal voor een probleem waarvan niemand nog heeft genoemd
wat het praktisch belang zou zijn...

Met vriendelijke groet,
Huub Reuver

[Sabayon User]

Post by Huub Reuver
Sabayon trekt al de conclusie dat er sprake is van brakke hardware en
brakke drivers.
Misschien kan Sabayon zijn conclusies onderbouwen?

Is kennis door ervaring opgedaan.
Bij elke nieuwe PC ga ik eerst het onboard geluid proberen. En ook bij
mijn huidige ruim 2 jaar oude systeem bleek de onboard geluidskaart niet
in staat om met de Linux AC97 driver simultaan meerdere geluidsbronnen af
te spelen.

Na plaatsen van de Soundblaster Live (EMUK101 driver) was simultaan
afspelen van meerdere geluidsbronnen wel mogelijk.

[Martijn van Buul]

Post by Huub Reuver
1- de test is niet goed uitgevoerd (voor de geluidsstoring dan)
2- de resultaten zijn niet accuraat weergegeven (er missen waarnemingen)
3- er is iets mis met linux, de geluidskaart of de driver

Vergeet in dit lijstje het alom aanwezige multimedia framework van je
desktop niet. Mijn ervaringen met pulseaudio, esd en arts zijn niet echt
fantastisch. Bij haperingen zou ik in ieder geval in eerste instantie hier
kijken.

Wat betreft on-board geluidskaarten: Het is geen wet van Meden en Perzen,
maar on-board spul is vaak duidelijk van een lagere kwaliteit. Dat is voor
een belangrijk deel ook niet echt verwonderlijk - afscherming is wat
vervelender op een multi-layer moederboard waar het woekeren is met ruimte
dan op een PCI kaart waarvan de afmetingen voornamelijk worden bepaald
door de afmetingen van het PCI slot. Dat uit zich echter voornamelijk in
ruis, niet in haperen en stotteren (en in minder mogelijkheden, maar daar
ging het hier niet over)

[Sabayon User]

Post by Martijn van Buul
Wat betreft on-board geluidskaarten: Het is geen wet van Meden en
Perzen, maar on-board spul is vaak duidelijk van een lagere kwaliteit.
Dat is voor een belangrijk deel ook niet echt verwonderlijk -
afscherming is wat vervelender op een multi-layer moederboard waar het
woekeren is met ruimte dan op een PCI kaart waarvan de afmetingen
voornamelijk worden bepaald door de afmetingen van het PCI slot. Dat uit
zich echter voornamelijk in ruis, niet in haperen en stotteren (en in
minder mogelijkheden, maar daar ging het hier niet over)

Onboard sound en video. Leuk dat het kan, en daar is dan ook alles mee
gezegt.

Uitschakelen die bende en wat knaps kopen voor multimediaal spektakel ;-)

[Rob]

Post by Sabayon User
Onboard sound en video. Leuk dat het kan, en daar is dan ook alles mee
gezegt.
Uitschakelen die bende en wat knaps kopen voor multimediaal spektakel ;-)

Ik verwacht niet zo veel deskundigheid van iemand die nog niet eens zijn
eigen systeemnaam en usernaam kan instellen...

[Sabayon User]

Post by Rob

Post by Sabayon User
Uitschakelen die bende en wat knaps kopen voor multimediaal spektakel ;-)

Ik verwacht niet zo veel deskundigheid van iemand die nog niet eens zijn
eigen systeemnaam en usernaam kan instellen...

Is dat waar Linux gebruiken om draait?

Gelukkig ga ik dan weer voor multimediaal spektakel ;-)

[Rob]

Post by Martijn van Buul
Vergeet in dit lijstje het alom aanwezige multimedia framework van je
desktop niet. Mijn ervaringen met pulseaudio, esd en arts zijn niet echt
fantastisch. Bij haperingen zou ik in ieder geval in eerste instantie hier
kijken.

Wanneer worden die programma's toch eens uitgefaseerd?
Maar nee, er komen steeds weer nieuwe van die prutswerken in Linux.

Zo gaat het geluid in Linux NOOIT goed werken.

Maar ja, mag niet in de kernel he? Er is immers geen binaire driver
fabrikant die we hier mee kunnen stangen. Dus dan geldt de regel dat
waar de kerneldeveloper het nut niet van ziet, niet ik de kernel mag.
(zelfs als dat nut er wel degelijk is)

[Maurice Janssen]

Post by Rob
Er is een groep kernel ontwikkelaars die tegen binary (closed-source)
drivers is.

IMHO is dat terecht. Hoe meer druk op producenten om documentatie te
geven om zelf drivers te maken, hoe beter. Binary drivers zou je niet
moeten willen.

Post by Rob
Deze groep doet voortdurend dingen waar de makers van dat
soort drivers last van hebben. Interfaces veranderen, functies ontoegankelijk
maken, etc.
Deze situatie rond videodrivers is de zoveelste stap in dat plan.
Men wil dat Nvidia de drivers opensource maakt, en doet alles om dat
te bereiken. Als het resultaat is dat Nvidia uit de Linux wereld stapt
dan vind men dat ook prima.
Ik vind het jammer dat dit spelletje gespeeld wordt.

Ik vind het ook jammer dat het zo gespeeld wordt, maar je kunt je
afvragen hoe we ervoor staan over een aantal jaar als je binary drivers
klakkeloos accepteert.
- support voor oudere hardware verdwijnt veel sneller,
- je bent van de fabrikant afhankelijk voor bugfixes,
- je kunt de code niet controleren op securityrisico's

Als je Linux gebruikt omdat het open source is (en niet alleen omdat het
gratis is), zou je je m.i. eens goed moeten afvragen of je een binary
driver wel wilt gebruiken.

[Rob]

Post by Maurice Janssen

Post by Rob
Er is een groep kernel ontwikkelaars die tegen binary (closed-source)
drivers is.

IMHO is dat terecht. Hoe meer druk op producenten om documentatie te
geven om zelf drivers te maken, hoe beter. Binary drivers zou je niet
moeten willen.

Het is al meermalen aangegeven door nvidia dat het binary of niets is.
Ik geef de voorkeur aan binary omdat dat werkt. Met geen driver heb ik
geen beeld.

Post by Maurice Janssen
Als je Linux gebruikt omdat het open source is (en niet alleen omdat het
gratis is), zou je je m.i. eens goed moeten afvragen of je een binary
driver wel wilt gebruiken.

Ik vind dat een kulverhaal. Een Linux systeem bevat veel opensource software
maar ook closed software. Daar doe je niks aan, en het is niet de taak
van de kernel ontwikkelaars om het leven van de gebruikers onmogelijk
te maken. Laten ze zelf maar een intelbordje kopen, en de gebruikers de
keus laten om een nvidia kaart te nemen.
(je hoort vaak het verhaal over de geweldige drivers van intel maar er
staat nooit bij dat er helemaal geen videokaarten van intel of met intel
chips bestaan!)

[Huub Reuver]

Post by Rob

Post by Maurice Janssen

Post by Rob
Er is een groep kernel ontwikkelaars die tegen binary (closed-source)
drivers is.

IMHO is dat terecht. Hoe meer druk op producenten om documentatie te
geven om zelf drivers te maken, hoe beter. Binary drivers zou je niet
moeten willen.

Het is al meermalen aangegeven door nvidia dat het binary of niets is.
Ik geef de voorkeur aan binary omdat dat werkt. Met geen driver heb ik
geen beeld.

Zonder binary driver heb je wel beeld. Alleen geen 3D-ondersteuning en
andere extra's (tv-out en zo) via VESA of een open source driver.

Het biedt weinig meerwaarde t.o.v. een moederbord met geintegreerde
GPU van Intel. Maar intel videokaarten werken niet met een AMD64.

Post by Rob

Post by Maurice Janssen
Als je Linux gebruikt omdat het open source is (en niet alleen omdat het
gratis is), zou je je m.i. eens goed moeten afvragen of je een binary
driver wel wilt gebruiken.

Ik vind dat een kulverhaal. Een Linux systeem bevat veel opensource software
maar ook closed software. ...

Ervaringen verschillen. Ik heb hier verschillende systemen en als ik
zoek naar closed software dan houdt het wel op bij flash en een 'unzip'
of zo.

Of mag ik unzip nog meetellen als open source?

Zoveel closed source software bevat Linux niet. En meestal is er een
vergelijkbaar of beter open source alternatief.

Post by Rob
... Daar doe je niks aan, en het is niet de taak
van de kernel ontwikkelaars om het leven van de gebruikers onmogelijk
te maken. ...

Nee, dat is de taak van de hardware fabrikanten.

Jij steunt de hardware fabrikanten in hun keuze voor closed source
drivers. En als er problemen zijn vraag je kernel-developpers en
distributeurs die problemen op te lossen.

Post by Rob
... Laten ze zelf maar een intelbordje kopen, en de gebruikers de
keus laten om een nvidia kaart te nemen.

Lees: het boeit jouw geen donder wat zij voor hardware willen hebben,
als ze maar een nvidia kaart kopen en de problemen oplossen voor
nvidia-gebruikers.

Ik kan me voorstellen dat kernel-developpers zo'n mening minder leuk
vinden.

Post by Rob
(je hoort vaak het verhaal over de geweldige drivers van intel maar er
staat nooit bij dat er helemaal geen videokaarten van intel of met intel
chips bestaan!)

Je zou NVidia kaarten kunnen laten liggen en kiezen voor een Ati
Radeon... Moet je ook nog concessies doen op prestaties, maar minder
als bij NVidia. En de ondersteuning zou verbeteren (bij de open source
driver).

Maar als jij wil investeren in closed source moet je dat doen. Je moet
dan wel accepteren dat kernel-developpers jou als 2e rangs gebruiker
behandelen.

En de kans dat Linux daardoor minder bruikbaar wordt.
En dat Xen en VMWare daardoor minder goed werken.
Etc..

Met vriendelijke groet,
Huub Reuver

[Maurice Janssen]

Post by Rob

Post by Maurice Janssen

Post by Rob
Er is een groep kernel ontwikkelaars die tegen binary (closed-source)
drivers is.

IMHO is dat terecht. Hoe meer druk op producenten om documentatie te
geven om zelf drivers te maken, hoe beter. Binary drivers zou je niet
moeten willen.

Het is al meermalen aangegeven door nvidia dat het binary of niets is.

Voor mij reden genoeg om geen Nvidia te kopen. Het is aan hun om die
keuze te maken, maar ik ga ze daarin niet ondersteunen door hun hardware
te kopen.

Post by Rob

Post by Maurice Janssen
Als je Linux gebruikt omdat het open source is (en niet alleen omdat het
gratis is), zou je je m.i. eens goed moeten afvragen of je een binary
driver wel wilt gebruiken.

Ik vind dat een kulverhaal. Een Linux systeem bevat veel opensource software
maar ook closed software.

Hangt er vanaf wat je kiest. Ook met alleen opensource en zonder binary
drivers valt prima te werken.

Post by Rob
Daar doe je niks aan,

Niet als je niet wilt, nee. Ook prima, maar kom dan over een jaar niet
klagen dat je Nvidia kaart niet werkt met de nieuwste drivers.
Als je dat wilt voorkomen, moet je nu bij de fabrikant gaan zeuren om
documentatie, zodat er een opensource driver gemaakt kan worden.

Post by Rob
en het is niet de taak
van de kernel ontwikkelaars om het leven van de gebruikers onmogelijk
te maken.

Zoals al genoemd in deze thread: dat doen ze niet met opzet.

[Rob]

Post by Maurice Janssen

Post by Rob
en het is niet de taak
van de kernel ontwikkelaars om het leven van de gebruikers onmogelijk
te maken.

Zoals al genoemd in deze thread: dat doen ze niet met opzet.

Daar ben ik het niet mee eens. Er lopen er daar een paar rond die niets
liever doen dan binary driver makers (en dus ook gebruikers) een hak te
zetten.

[Fred Mobach]

Post by Rob

Post by Maurice Janssen

Post by Rob
en het is niet de taak
van de kernel ontwikkelaars om het leven van de gebruikers onmogelijk
te maken.

Zoals al genoemd in deze thread: dat doen ze niet met opzet.

Daar ben ik het niet mee eens. Er lopen er daar een paar rond die
niets liever doen dan binary driver makers (en dus ook gebruikers) een
hak te zetten.

Gemeenlijk doen ze dat door bepaalde zaken als "GPL only" te exporteren.
En dat werkt dan ook prima.

En ter informatie : aangezien *zij* die software schrijven zijn *zij* de
enigen die die condities bepalen. Als je het er niet mee eens bent :
schrijf die source zelf met de door jou gewenste condities. :-)

[Rob]

Post by Fred Mobach

Post by Rob

Post by Maurice Janssen

Post by Rob
en het is niet de taak
van de kernel ontwikkelaars om het leven van de gebruikers onmogelijk
te maken.

Zoals al genoemd in deze thread: dat doen ze niet met opzet.

Daar ben ik het niet mee eens. Er lopen er daar een paar rond die
niets liever doen dan binary driver makers (en dus ook gebruikers) een
hak te zetten.

Gemeenlijk doen ze dat door bepaalde zaken als "GPL only" te exporteren.
En dat werkt dan ook prima.
En ter informatie : aangezien *zij* die software schrijven zijn *zij* de
schrijf die source zelf met de door jou gewenste condities. :-)

Het gaat er niet om of zij dat mogen doen, er werd geclaimed dat ze dat
niet met opzet doen en dat doen ze dus *WEL* met opzet.

[Fred Mobach]

Post by Rob

Post by Fred Mobach

Post by Rob
Daar ben ik het niet mee eens. Er lopen er daar een paar rond die
niets liever doen dan binary driver makers (en dus ook gebruikers)
een hak te zetten.

Gemeenlijk doen ze dat door bepaalde zaken als "GPL only" te
exporteren. En dat werkt dan ook prima.
En ter informatie : aangezien *zij* die software schrijven zijn *zij*
de enigen die die condities bepalen. Als je het er niet mee eens bent
: schrijf die source zelf met de door jou gewenste condities. :-)

Het gaat er niet om of zij dat mogen doen, er werd geclaimed dat ze
dat niet met opzet doen en dat doen ze dus *WEL* met opzet.

Sommigen willen dat, maar wat er in de tree van Linus komt bepalen zij
weer niet.

Het is me al eens opgevallen dat Linus vrij coulant is wat betreft
binaire modules. Maar het viel me ook op dat hij wars is van het
ondersteunen van oude interfaces als hij denkt dat een ander interface
beter is (in technisch opzicht). En wat anderen daarvan vinden schijnt
hem in het geheel niet te interesseren. Ik vermoed dat hij niet de
helpdesk bemant. :-)

[unknown]

Post by Maurice Janssen

Post by Rob
Er is een groep kernel ontwikkelaars die tegen binary (closed-source)
drivers is.

IMHO is dat terecht. Hoe meer druk op producenten om documentatie te
geven om zelf drivers te maken, hoe beter. Binary drivers zou je niet
moeten willen.

Waarom niet?

Post by Maurice Janssen
Ik vind het ook jammer dat het zo gespeeld wordt, maar je kunt je
afvragen hoe we ervoor staan over een aantal jaar als je binary drivers
klakkeloos accepteert.
- support voor oudere hardware verdwijnt veel sneller,

Hoe kan bestaande support verdwijnen? Die is er toch al? Bovendien
sluiten binary modules open source modules niet uit.

Post by Maurice Janssen
- je bent van de fabrikant afhankelijk voor bugfixes,

Nu ben ik afhankelijk van de kernel-hackers.

Post by Maurice Janssen
- je kunt de code niet controleren op securityrisico's

Nu ook niet. Daarvoor moet je namelijk behoorlijk goed kunnen
programmeren én verstand hebben van security. Dat zijn niet zoveel mensen.

Post by Maurice Janssen
Als je Linux gebruikt omdat het open source is (en niet alleen omdat het
gratis is), zou je je m.i. eens goed moeten afvragen of je een binary
driver wel wilt gebruiken.

Het maakt mij niks uit of Linux open source is. Ik denk overigens dat
het geen reden is voor de meeste mensen (ach crap, daar zijn ze weer;
wie zijn toch die 'meeste mensen' ?)

Voor een gebruiker (en een computer is toch veelal een middel, geen
doel) maakt het werkelijk geen klap uit of het open source is, closed
source, binary, licensed source, weet-ik-veel-wat. Als het maar werkt.
En het liefst beter of net zo goed als de concurrent (anders neem ik die
wel).

Bart

[Maurice Janssen]

Post by unknown

Post by Maurice Janssen
Ik vind het ook jammer dat het zo gespeeld wordt, maar je kunt je
afvragen hoe we ervoor staan over een aantal jaar als je binary drivers
klakkeloos accepteert.
- support voor oudere hardware verdwijnt veel sneller,

Hoe kan bestaande support verdwijnen? Die is er toch al? Bovendien
sluiten binary modules open source modules niet uit.

De driver van nu ondersteunt te hardware van nu, maar ondersteunt de
driver die Nvidia levert voor de kernels van een jaar verder ook nog de
hardware van nu? Of alleen de hardware die dan gangbaar is?
Ideale manier om je klanten nieuwere hardware aan te smeren.

Post by unknown

Post by Maurice Janssen
- je bent van de fabrikant afhankelijk voor bugfixes,

Nu ben ik afhankelijk van de kernel-hackers.

Als ik mag kiezen ben ik toch liever afhankelijk van kernel-hackers dan
van fabrikanten. Van de laatste weet je bij voorbaat dat het hun alleen
maar om het geld te doen is.

Post by unknown

Post by Maurice Janssen
- je kunt de code niet controleren op securityrisico's

Nu ook niet. Daarvoor moet je namelijk behoorlijk goed kunnen
programmeren én verstand hebben van security. Dat zijn niet zoveel mensen.

Klopt, maar je mag verwachten dat kernel-hackers die kennis wel hebben.
En dat er meerdere mensen naar de code kijken voordat deze de kernel in
gaat.

Post by unknown

Post by Maurice Janssen
Als je Linux gebruikt omdat het open source is (en niet alleen omdat het
gratis is), zou je je m.i. eens goed moeten afvragen of je een binary
driver wel wilt gebruiken.

Het maakt mij niks uit of Linux open source is. Ik denk overigens dat
het geen reden is voor de meeste mensen (ach crap, daar zijn ze weer;
wie zijn toch die 'meeste mensen' ?)

Tsja, ieder zijn ding. Mij maakt het wel uit, maar wie ben ik?

[Rob]

Post by Maurice Janssen

Post by unknown

Post by Maurice Janssen
Ik vind het ook jammer dat het zo gespeeld wordt, maar je kunt je
afvragen hoe we ervoor staan over een aantal jaar als je binary drivers
klakkeloos accepteert.
- support voor oudere hardware verdwijnt veel sneller,

Hoe kan bestaande support verdwijnen? Die is er toch al? Bovendien
sluiten binary modules open source modules niet uit.

De driver van nu ondersteunt te hardware van nu, maar ondersteunt de
driver die Nvidia levert voor de kernels van een jaar verder ook nog de
hardware van nu? Of alleen de hardware die dan gangbaar is?
Ideale manier om je klanten nieuwere hardware aan te smeren.

Nvidia levert diverse drivers voor de verschillende generaties van hardware,
en past de oude drivers regelmatig aan aan de nieuwe kernels.
Dat het zo vaak stuk gaat bij een nieuwe driver komt nou juist door de
wankele kernel interface van Linux, en daarbij vaak ook nog door de
bekende "deze functie is niet meer beschikbaar voor niet-GPL drivers
nananana" problemen.

Post by Maurice Janssen

Post by unknown

Post by Maurice Janssen
- je bent van de fabrikant afhankelijk voor bugfixes,

Nu ben ik afhankelijk van de kernel-hackers.

Als ik mag kiezen ben ik toch liever afhankelijk van kernel-hackers dan
van fabrikanten. Van de laatste weet je bij voorbaat dat het hun alleen
maar om het geld te doen is.

Aan de andere kant weten ze wel veel meer van de hardware.
Ik denk dat het maken van een driver voor een videokaart niet triviaal
is, en het steeds maar aanpassen aan de nieuwste hardware ontwikkelingen
ook niet.

[unknown]

Post by Maurice Janssen
Als ik mag kiezen ben ik toch liever afhankelijk van kernel-hackers dan
van fabrikanten. Van de laatste weet je bij voorbaat dat het hun alleen
maar om het geld te doen is.

Hm. Geld lijkt me een redelijk incentief juist op dit vlak om het juist
goed te doen. Anders krijg je een 'works-for-me' driver. Tevens hebben
de Nvidia hackers (ook geen debielen) een betere toegang tot
documentatie, hardware engineers, enz. Lijkt mij een voordeel.

Post by Maurice Janssen

Post by unknown

Post by Maurice Janssen
- je kunt de code niet controleren op securityrisico's

Nu ook niet. Daarvoor moet je namelijk behoorlijk goed kunnen
programmeren én verstand hebben van security. Dat zijn niet zoveel mensen.

Klopt, maar je mag verwachten dat kernel-hackers die kennis wel hebben.
En dat er meerdere mensen naar de code kijken voordat deze de kernel in
gaat.

Nu toch ook? Of die mensen nu bij Nvidia werken, of voor Linux.com,
maakt mij niet zoveel uit. Ze zijn beide gebaat bij een correct werkende
driver.

Echt, binary/opensource voor drivers is voor mij alleen een politiek
issue, geen technisch. (En daarmee een non-issue, ik geef geen zier om
de licentie van de software op mijn PC, zolang het legaal is en het werkt.)

Bart

[Dick Hoogendijk]

Post by unknown

Post by Maurice Janssen

Post by Rob
Er is een groep kernel ontwikkelaars die tegen binary
(closed-source) drivers is.

IMHO is dat terecht. Hoe meer druk op producenten om documentatie te
geven om zelf drivers te maken, hoe beter. Binary drivers zou je
niet moeten willen.

Waarom niet?

Ik heb deze discussie nu al tig keren voorbij zien komen. Het antwoord
op de vraag is eigenlijk alleen: omdat het niet strookt met de linux
policy. De argumentatie(s) doen me ook vaak denken aan de policy van
Debian, welke soms ontwikkelingen in de weg staat. staat.
"Principe is principe" -- daar komt het op neer.

Het hele gezeik dat NVidia kaarten niet goed zouden zijn is gebaseerd op
het niet vrijgeven van hun drivers. Het is gelul dat NVidia kaarten
slecht zijn. Integendeel, het zijn uitstekende kaarten!
Misschien zou het geen kwaad kunnen als men in de linux OSS community
wat meer leert dat samenwerking (hier met closed source) niet bij
voorbaat slecht is. In het hele leven ben je -afhankelijk- iets wat in
de linux community vaak als verschrikkelijk wordt afgedaan. Er is niks
mis met afhankelijkheden. Bescherming daartegen en het krampachtig
creëren van een 'wereld' waarin je alles in eigen hand zou hebben is
imho niet de juiste weg.

Post by unknown
Nu ook niet. Daarvoor moet je namelijk behoorlijk goed kunnen
programmeren én verstand hebben van security. Dat zijn niet zoveel mensen.

Maar -wel- de mensen die het hart vormen van de linux community. Vaak
vergeten we dat linux ook buiten die groep heel veel wordt gebruikt. Je
vindt ze niet in deze NG, al die zakenmensen wiens IT'er is overgegaan
op Redhat of whatever. Hen zal open/closed een worst wezen. Zoals jij

Post by unknown
Het maakt mij niks uit of Linux open source is. Ik denk overigens dat
het geen reden is voor de meeste mensen (ach crap, daar zijn ze weer;
wie zijn toch die 'meeste mensen' ?)
Voor een gebruiker (en een computer is toch veelal een middel, geen
doel) maakt het werkelijk geen klap uit of het open source is, closed
source, binary, licensed source, weet-ik-veel-wat. Als het maar werkt.
En het liefst beter of net zo goed als de concurrent (anders neem ik
die wel).

En voor iedere -GROOT- gebruiker gelden deze uitspraken.
Just my 2 ¢t.

[Klaasjan Brand]

Post by Dick Hoogendijk

Post by unknown

Binary drivers zou je niet moeten willen.

Waarom niet?

Ik heb deze discussie nu al tig keren voorbij zien komen. Het antwoord
op de vraag is eigenlijk alleen: omdat het niet strookt met de linux
policy. De argumentatie(s) doen me ook vaak denken aan de policy van
Debian, welke soms ontwikkelingen in de weg staat. staat. "Principe is
principe" -- daar komt het op neer.

Het principe dat de broncode aangepast moet kunnen worden om problemen op
te lossen is anders wel redelijk geaccepteerd.
De enige partij die _alle_ broncode heeft van een kernel met nvidia
binary driver is nvidia, maar toch krijgen de kernel ontwikkelaars
support verzoeken van mensen die deze driver gebruiken. In dat geval is
het principe "zoek het zelf maar uit" ook niet heel onverwacht...

Post by Dick Hoogendijk
Het hele gezeik dat NVidia kaarten niet goed zouden zijn is gebaseerd op
het niet vrijgeven van hun drivers. Het is gelul dat NVidia kaarten
slecht zijn. Integendeel, het zijn uitstekende kaarten!

Vandaar dat we dit jaar getracteerd zijn op grote hoeveelheden
uitvallende nvidia chips (vooral vervelend wanneer ze op laptop
moederborden vastgesoldeerd zitten).

Post by Dick Hoogendijk
Misschien zou
het geen kwaad kunnen als men in de linux OSS community wat meer leert
dat samenwerking (hier met closed source) niet bij voorbaat slecht is.
In het hele leven ben je -afhankelijk- iets wat in de linux community
vaak als verschrikkelijk wordt afgedaan. Er is niks mis met
afhankelijkheden. Bescherming daartegen en het krampachtig creëren van
een 'wereld' waarin je alles in eigen hand zou hebben is imho niet de
juiste weg.

Dat klinkt precies als de weg die de nvidia ontwikkelaars kiezen.

De echte vraag is dus wie er eerst opgeeft. Mijn geld staat op nvidia;
zodra hun kaarten compleet reverse engineered zijn en er support voor is
in de nouveau drivers denk ik niet dat ze hun binary driver nog langer
hoeven te onderhouden. Geef het een jaar of 5...

...tegen die tijd gebruiken we waarschijnlijk weer software renderers op
90-core larrabee chips, maargoed.

Kj

[Rob]

Post by Klaasjan Brand
Het principe dat de broncode aangepast moet kunnen worden om problemen op
te lossen is anders wel redelijk geaccepteerd.
De enige partij die _alle_ broncode heeft van een kernel met nvidia
binary driver is nvidia, maar toch krijgen de kernel ontwikkelaars
support verzoeken van mensen die deze driver gebruiken. In dat geval is
het principe "zoek het zelf maar uit" ook niet heel onverwacht...

Maar wie spreekt dat tegen? NATUURLIJK moeten problemen met de driver
worden doorgegeven naar Nvidia.

Dat is echter niet hetzelfde als lekker interfaceje wijzigen zodat Nvidia
weer leuk problemen heeft met de volgende kernel release!

(Of VMware of whatever andere partij die de sources niet wil geven maar
wel aan de kernel linkt)

[Klaasjan Brand]

Post by Rob

Post by Klaasjan Brand
Het principe dat de broncode aangepast moet kunnen worden om problemen
op te lossen is anders wel redelijk geaccepteerd. De enige partij die
_alle_ broncode heeft van een kernel met nvidia binary driver is
nvidia, maar toch krijgen de kernel ontwikkelaars support verzoeken van
mensen die deze driver gebruiken. In dat geval is het principe "zoek
het zelf maar uit" ook niet heel onverwacht...

Maar wie spreekt dat tegen? NATUURLIJK moeten problemen met de driver
worden doorgegeven naar Nvidia.

het probleem is dat de nvidia driver ook problemen in de code van anderen
kan veroorzaken. Nvidia levert alleen geen support op volledige Linux
distributies, dus ben je in dat geval behoorlijk zuur.

Post by Rob
Dat is echter niet hetzelfde als lekker interfaceje wijzigen zodat
Nvidia weer leuk problemen heeft met de volgende kernel release!

Je kan natuurlijk altijd een oude kernel blijven gebruiken totdat nvidia
de zaken (weer) voor elkaar heeft.

Het liefst steken ze bij nvidia uiteraard zo weinig mogelijk effort in
het onderhouden van hun spullen. Nieuwe zaken als kernel modesetting of
bijvoorbeeld de "texture from pixmap" uitbreiding die zaken als compiz
mogelijk maakt vereisen nieuwe drivers. Die vooruitgang wordt door de OSS
community gepushed, terwijl nvidia er achteraan hobbelt. Dat is hun
keuze, maar vind je echt dat de OSS community vanwege beschikbaarheid van
een driver vooral geen interfaces mag veranderen om dingen te verbeteren?

Kj

[Dick Hoogendijk]

Post by Klaasjan Brand
Het principe dat de broncode aangepast moet kunnen worden om problemen
op te lossen is anders wel redelijk geaccepteerd.

Mee eens. Dit geldt alleen voor de code waarvan je de maker(s) bent.

Post by Klaasjan Brand
De enige partij die _alle_ broncode heeft van een kernel met nvidia
binary driver is nvidia, maar toch krijgen de kernel ontwikkelaars
support verzoeken van mensen die deze driver gebruiken. In dat geval
is het principe "zoek het zelf maar uit" ook niet heel onverwacht...

Ze hebben groot gelijk. Ze zijn niet verantwoordelijk voor code die zij
niet hebben geschreven. Bij een goede samenwerking echter is snel en
vruchtbaar overleg echter wel mogelijk. Ik zie dit b.v. ook in de
relatie solaris/nvidia. De ontwikkelversies (nevada/opensolaris)
beschikken altijd over de nieuwste nvidia drivers. Maar er is dan ook
veel en goed overleg tussen solaris/nvidia engineers ;-)

Post by Klaasjan Brand

Het is gelul dat NVidia kaarten slecht zijn. Integendeel, het zijn
uitstekende kaarten!

Vandaar dat we dit jaar getracteerd zijn op grote hoeveelheden
uitvallende nvidia chips (vooral vervelend wanneer ze op laptop
moederborden vastgesoldeerd zitten).

Ik heb het over nvidia kaarten. On board chips zijn helaas soms andere
koek. De kwaliteit daarvan wisselt, maar top is het nooit.

Post by Klaasjan Brand
Dat klinkt precies als de weg die de nvidia ontwikkelaars kiezen.
De echte vraag is dus wie er eerst opgeeft. Mijn geld staat op nvidia;
zodra hun kaarten compleet reverse engineered zijn en er support voor
is in de nouveau drivers denk ik niet dat ze hun binary driver nog
langer hoeven te onderhouden. Geef het een jaar of 5...
...tegen die tijd gebruiken we waarschijnlijk weer software renderers
op 90-core larrabee chips, maargoed.

In de praktijk komt het er dus op neer dat je kiest voor (a) je geloof
en daarmee nvidia kaarten weigert te gebruiken of (b) samenwerking
tussen closed/open source met als gevolg dat op jouw OS nvidia kaarten
prima werken. De kaarten die in solaris systemen zitten worden bij mij
tot in alle puntjes door de driver ondersteund. Warm worden is er bv
niet bij ;-) Wachten op reversed enginering is kiezen voor het achter de
feiten aanhobbelen. Dat is in elk geval niet mijn keuze.

[Klaasjan Brand]

Post by Dick Hoogendijk

Post by Klaasjan Brand
Vandaar dat we dit jaar getracteerd zijn op grote hoeveelheden
uitvallende nvidia chips (vooral vervelend wanneer ze op laptop
moederborden vastgesoldeerd zitten).

Ik heb het over nvidia kaarten. On board chips zijn helaas soms andere
koek. De kwaliteit daarvan wisselt, maar top is het nooit.

Als je het artikel gelezen hebt had je gezien dat het puur om de nvidia
chips gaat (onboard of op een losse kaart maakt weinig uit)

Post by Dick Hoogendijk

Post by Klaasjan Brand
...tegen die tijd gebruiken we waarschijnlijk weer software renderers
op 90-core larrabee chips, maargoed.

In de praktijk komt het er dus op neer dat je kiest voor (a) je geloof
en daarmee nvidia kaarten weigert te gebruiken of (b) samenwerking
tussen closed/open source met als gevolg dat op jouw OS nvidia kaarten
prima werken.

Is het een "geloof" dat Linux kernel developers je niet graag helpen met
bugs in binary drivers? Maw: kan je om die reden niet juist kiezen voor
kaarten met OSS support zonder gelijk in de fanatiekelingen-hoek terecht
te komen?

Post by Dick Hoogendijk
De kaarten die in solaris systemen zitten worden bij mij
tot in alle puntjes door de driver ondersteund. Warm worden is er bv
niet bij ;-) Wachten op reversed enginering is kiezen voor het achter de
feiten aanhobbelen. Dat is in elk geval niet mijn keuze.

Als je niet van reverse engineered drivers houdt kan je bijna geen Linux
gebruiken. Aan de andere kant zijn er zat Linux drivers die - juist omdat
ze compleet opnieuw geschreven zijn - kwalitatief een stuk beter in
elkaar steken...

Kj

[Sabayon User]

Post by Klaasjan Brand
Vandaar dat we dit jaar getracteerd zijn op grote hoeveelheden
uitvallende nvidia chips (vooral vervelend wanneer ze op laptop
moederborden vastgesoldeerd zitten).

Dus toch een algemeen probleem. Dacht dat ik de enige was die Geforce
kaarten erdoorheen stookt als slijtageonderdeel.

Binnenkort de 3e kaart in 2.5 jaar.

De huidige 8500GT is nog niet zo ver heen dat hij vertraging veroorzaakt
(bijv. beeldopbouw KPDF) of helemaal geen beeld meer geeft. Maar
veroorzaakt al wel vastlopers op een net opgestart systeem en regelmatig
haperingen op flash video'a tijdens muisbeweging.

Het aftakelings-proces is dus reeds begonnen na amper een jaar
heetstoken..

Volgende kaart wordt er 1 met actieve koeling.

[Dick Hoogendijk]

Post by Sabayon User
Dus toch een algemeen probleem. Dacht dat ik de enige was die Geforce
kaarten erdoorheen stookt als slijtageonderdeel.
Binnenkort de 3e kaart in 2.5 jaar.

Mijn NVidia kaarten zitten al jaren in mijn systemen, zonder ook maar
enige vorm van slijtage. Alle uit de 7xxx series, dat wel. En niet onder
linux als hoofdbesturing.

[Rob]

Post by Dick Hoogendijk

Post by Sabayon User
Dus toch een algemeen probleem. Dacht dat ik de enige was die Geforce
kaarten erdoorheen stookt als slijtageonderdeel.
Binnenkort de 3e kaart in 2.5 jaar.

Mijn NVidia kaarten zitten al jaren in mijn systemen, zonder ook maar
enige vorm van slijtage. Alle uit de 7xxx series, dat wel. En niet onder
linux als hoofdbesturing.

Ik heb ook al diverse nvidia kaarten gehad (in verband met de steeds
wisselende bus als je een nieuw moederbord koopt) maar ik ken die problemen
ook niet.

Nu een Asus 8500GT op een Asus moederbord en 0 stabiliteitsproblemen.

[Marcel]

On Sun, 4 Jan 2009 20:02:55 +0000 (UTC), Sabayon User

Post by Sabayon User

Post by Klaasjan Brand
Vandaar dat we dit jaar getracteerd zijn op grote hoeveelheden
uitvallende nvidia chips (vooral vervelend wanneer ze op laptop
moederborden vastgesoldeerd zitten).

Dus toch een algemeen probleem. Dacht dat ik de enige was die Geforce
kaarten erdoorheen stookt als slijtageonderdeel.
Binnenkort de 3e kaart in 2.5 jaar.
De huidige 8500GT is nog niet zo ver heen dat hij vertraging veroorzaakt
(bijv. beeldopbouw KPDF) of helemaal geen beeld meer geeft. Maar
veroorzaakt al wel vastlopers op een net opgestart systeem en regelmatig
haperingen op flash video'a tijdens muisbeweging.
Het aftakelings-proces is dus reeds begonnen na amper een jaar
heetstoken..
Volgende kaart wordt er 1 met actieve koeling.

Met andere woorden, de airflow in je kast is waardeloos.
Ook een kaart met passieve koeling moet z'n warmte ergens kwijt en
heeft dus een bepaalde airflow nodig.
Heeft dus niets met Geforce te maken maar alles met de constructie van
de behuizing waar je die in plaatst.

[Sabayon User]

Post by Dick Hoogendijk
Het hele gezeik dat NVidia kaarten niet goed zouden zijn is gebaseerd op
het niet vrijgeven van hun drivers. Het is gelul dat NVidia kaarten
slecht zijn. Integendeel, het zijn uitstekende kaarten! Misschien zou
het geen kwaad kunnen als men in de linux OSS community wat meer leert
dat samenwerking (hier met closed source) niet bij voorbaat slecht is.
In het hele leven ben je -afhankelijk- iets wat in de linux community
vaak als verschrikkelijk wordt afgedaan. Er is niks mis met
afhankelijkheden. Bescherming daartegen en het krampachtig creëren van
een 'wereld' waarin je alles in eigen hand zou hebben is imho niet de
juiste weg.

Mee eens.

Overigens zit er een prettige bug in de Nvidia driver.
Stel je desktop in op uitgesmeerd over 2 schermen en je krijgt na
opstarten een linker hoofdscherm met menu / statusbalk en een bijscherm
zonder menubalk. Het voordeel is dat je applicaties fullscreen gaan op 1
scherm ipv uitgesmeerd over 2 schermen.

In Windows is dit zo in te stellen, de driver en interface voor de Linux
versie werken dus niet geheel 1:1. I don't care.

Overigens is de Nvidia driver een drama op Windows MCE met 2 schermen en
deze instelling. Zodra je de MCE applicatie start gaat 1 scherm op zwart.
Wel een mooie applicatie dat MCE en een stuk gebruikersvriendelijker dan
RAW streams dumpen via scripts zoals ik onder Linux doe. Alleen jammer
dat je er native Windows voor moet draaien.

Mijn TV-kaart is een Hauppage WintTV-PVR150 (single-tuner), prima kaart
met MPEG2 hardware versnelling (DVD kwaliteit). Alleen Linux was en is
(?) er nog niet klaar voor. Drivers zijn tegenwoordig wel in de kernel
aanwezig, alleen jammer dat men ictv-tune "vergeten" is, zodat je alsnog
zelf moet knutselen om de kaart op de juiste frequentie te kunnen zetten.
En ja de Video4Linux applicaties kunnen alleen met goedkope aggenebbus
kaarten overweg.

Al met al ben ik niet ontevreden over Linux en het wordt alleen maar
steeds mooier: http://www.sabayonlinux.org/

Binnenkort maar eens tijd vrijmaken om Sabayon V4.1 64 te installeren.

;-)

[Huub Reuver]

Post by Rob
Men doet dit om bedrijven te pesten die binaire X drivers maken, zoals Nvidia.
Slechte zaak. Nvidia doet een hoop moeite voor Linux drivers, er zijn vele
enthousiaste gebruikers, en het heeft geen pas om deze vanuit een stel
fanatieke anti-binary fanatici weg te pesten.

Voor een NVidia systeem hier betekent keuze voor open source drivers dat
de netwerkkaart moet werken met een reverse engineered forcedeth driver
en de videokaart beperkt is tot 2D (waarschijnlijk zonder accelaratie).

Feiten:
- Er zijn veel enthousiaste NVidia-gebruikers met Linux.
- NVidia steekt veel moeite in de drivers [1].
- Bij closed source zit je vast aan de drivers geleverd door NVidia, ook
bij een driver voor een nieuwe kernel voor een bestaand systeem.
- Onderhoud van een systeem met binary drivers kost meer tijd dan met
open source drivers.
- Ontwikkeling van open source driver door reverse engineering kost
meer tijd dan noodzakelijk omdat documentatie ontbreekt.
- Open Source drivers van NVidia zijn crippled (met name video).
- Binary drivers _ondergraven_ de sterke punten van Linux [2].

Dus wie pest wie?

Ervaringen zullen verschillen, maar bovenstaande is voor mij voldoende
om liever niet voor NVidia te kiezen. Ik kies liever een systeem dat mij
minder tijd en moeite kost.

Tegenover de meerprijs voor een NVidia videokaart in een laptop staat
bij open source ineens geen prestatievoordeel (bijvoorbeeld).

Met vriendelijke groet,
Huub Reuver

[1] http://www.phoronix.com/scan.php?page=article&item=nvidia_180_vdpau&num=1
[2] https://www.linuxfoundation.org/en/Kernel_Driver_Statement

[Joost]

Post by Huub Reuver
- Onderhoud van een systeem met binary drivers kost meer tijd dan met
open source drivers.

Stierenschijt. Ik heb jarenlang Fedora met de livna repository gedraaid.
Nieuwe kernel? Binnen een paar uur was de bijbehorende nvidia driver via
yum te installeren. Dat jij meer tijd nodig hebt geeft meer aan dat jij
je systemen verkeerd inricht dan dat de closed source driver producenten
fout zitten.

Post by Huub Reuver
- Ontwikkeling van open source driver door reverse engineering kost
meer tijd dan noodzakelijk omdat documentatie ontbreekt.

Waarom zou je een opensource driver willen maken als de producent een
goed werkende driver levert? Je verhaal is alleen geldig als de
producent geen driver wil maken, of alleen een slecht presterende.

Joost

[Huub Reuver]

Post by Joost

Post by Huub Reuver
- Onderhoud van een systeem met binary drivers kost meer tijd dan met
open source drivers.

Stierenschijt. Ik heb jarenlang Fedora met de livna repository gedraaid.
Nieuwe kernel? Binnen een paar uur was de bijbehorende nvidia driver via
yum te installeren. Dat jij meer tijd nodig hebt geeft meer aan dat jij
je systemen verkeerd inricht dan dat de closed source driver producenten
fout zitten.

Je zegt "het kost mij geen tijd", want "fedora heeft er al de nodige tijd
ingestoken".

Mijn stelling is "het kost meer tijd dan noodzakelijk als de drivers
gewoon meeontwikkeld zouden worden met de standaard kernel". Want de tijd
die Fedora erin steekt zou jij ook mee moeten tellen. Inclusief de tijd
voor backports als de driver moeilijker is aan te passen dan de rest van
de kernel.

Jouw commentaar: Stierenschijt.
Als je de tijd van fedora zou moeten betalen had je misschien een andere
mening. Van Stiereschijt kan niemand leven.

Post by Joost

Post by Huub Reuver
- Ontwikkeling van open source driver door reverse engineering kost
meer tijd dan noodzakelijk omdat documentatie ontbreekt.

Waarom zou je een opensource driver willen maken als de producent een
goed werkende driver levert? Je verhaal is alleen geldig als de
producent geen driver wil maken, of alleen een slecht presterende.

Jij bent afhankelijk van NVidia voor een binary kernel driver.

Het verhaal is ook geldig als de fabrikant stopt met de driver.
Of als je een gepatchte kernel wil gebruiken, waarbij de patch
conflicteerd met de NVidia-drivers. Ik kan me voorstellen dat
je bij virtualization tegen problemen aan kunt lopen (Xen).


Nu de volgende stap:
Als naast NVidia ook Intel, Ati, Realtek, Atheros, Marvell en andere
alleen binary drivers leveren. Waarom zou je dan Linux gebruiken?
Open source? Gratis? Gebruikersvriendelijk? Eenvoudig aan te passen?
Leuk om mee te werken?

Misschien vind je dat te politiek?

Met vriendelijke groet,
Huub Reuver

[Joost]

Post by Huub Reuver
Mijn stelling is "het kost meer tijd dan noodzakelijk als de drivers
gewoon meeontwikkeld zouden worden met de standaard kernel". Want de tijd
die Fedora erin steekt zou jij ook mee moeten tellen. Inclusief de tijd
voor backports als de driver moeilijker is aan te passen dan de rest van
de kernel.

Dit geldt voor ieder pakket. Ieder pakket moet door Fedora onderhouden
worden. Kortom, ieder pakket is arbeidsintensief. Third party pakketten
zijn zelfs eenvoudiger voor een distributeur, ze hoeven namelijk niet
een slechtgeschreven README (programmeurs zijn namelijk per definitie
slechte documenteurs) waarin de helft niet staat door te lezen voor alle
configuratieopties, daarna alle dependencies in te bouwen in de RPM, etc
etc. Dat is al allemaal gedaan.

Post by Huub Reuver

Post by Joost
Waarom zou je een opensource driver willen maken als de producent een
goed werkende driver levert? Je verhaal is alleen geldig als de
producent geen driver wil maken, of alleen een slecht presterende.

Jij bent afhankelijk van NVidia voor een binary kernel driver.

Of ik nou afhankelijk ben van NVidia of van een kernelprogrammeur,
afhankelijk ben ik toch. Dan liever afhankelijk van iemand die de bron
kent dan van iemand die een ding reverse engineert.

Ik gebruik Linux al sinds 1996 op mijn desktop (en voor de mensen die de
headers van dit bericht zitten te bestuderen: Ja, dit is een Vista
laptop. Ik had het over mijn desktop), tot 2 jaar geleden Slackware,
maar ik ben er achter gekomen dat ik betere dingen te doen heb met mijn
tijd dan alles steeds maar zelf te hercompileren. Of NVidia of Fedora of
Truus van de overburen die pakketten voor mij compileert zal mij worst
wezen.

Open source is leuk en aardig, maar als er een toch een vrijelijk
beschikbare closed source versie is die beter is, kies ik die.

Joost

[Marcel]

Post by Huub Reuver

Post by Joost

Post by Huub Reuver
- Onderhoud van een systeem met binary drivers kost meer tijd dan met
open source drivers.

Stierenschijt. Ik heb jarenlang Fedora met de livna repository gedraaid.
Nieuwe kernel? Binnen een paar uur was de bijbehorende nvidia driver via
yum te installeren. Dat jij meer tijd nodig hebt geeft meer aan dat jij
je systemen verkeerd inricht dan dat de closed source driver producenten
fout zitten.

Je zegt "het kost mij geen tijd", want "fedora heeft er al de nodige tijd
ingestoken".
Mijn stelling is "het kost meer tijd dan noodzakelijk als de drivers
gewoon meeontwikkeld zouden worden met de standaard kernel". Want de tijd
die Fedora erin steekt zou jij ook mee moeten tellen. Inclusief de tijd
voor backports als de driver moeilijker is aan te passen dan de rest van
de kernel.

Het kost ook meer tijd dan noodzakelijk om 100+ verschillende
distributies te onderhouden.
Met andere woorden, zou je ook pleiten voor een enkele (vooruit een
stuk of 5) distributie ?

[Huub Reuver]

Post by Marcel

Post by Huub Reuver

Post by Joost

Post by Huub Reuver
- Onderhoud van een systeem met binary drivers kost meer tijd dan met
open source drivers.

Stierenschijt. Ik heb jarenlang Fedora met de livna repository gedraaid.
Nieuwe kernel? Binnen een paar uur was de bijbehorende nvidia driver via
yum te installeren. Dat jij meer tijd nodig hebt geeft meer aan dat jij
je systemen verkeerd inricht dan dat de closed source driver producenten
fout zitten.

Je zegt "het kost mij geen tijd", want "fedora heeft er al de nodige tijd
ingestoken".
Mijn stelling is "het kost meer tijd dan noodzakelijk als de drivers
gewoon meeontwikkeld zouden worden met de standaard kernel". Want de tijd
die Fedora erin steekt zou jij ook mee moeten tellen. Inclusief de tijd
voor backports als de driver moeilijker is aan te passen dan de rest van
de kernel.

Het kost ook meer tijd dan noodzakelijk om 100+ verschillende
distributies te onderhouden.
Met andere woorden, zou je ook pleiten voor een enkele (vooruit een
stuk of 5) distributie ?

1) Hoeveel pakketten zijn er die jij eventueel zou toepassen als je
huidige distributie zou stoppen?

Buiten RedHat (Fedora), SUSE (OpenSUSE), Ubuntu en Debian zijn er weinig
pakketten die generiek toepasbaar zijn. Pakketten als Xandros/Linspire
zie ik niet als vervanging voor een Fedora of RedHat.

Veel van de overige pakketten zijn forks die voor specifieke toepassingen
zijn (en daarop gericht worden onderhouden) en forks die slecht of niet
worden onderhouden (ik verwacht dat eeebuntu uiteindelijk weer opgaat in
ubuntu). Dat mensen daar tijd insteken zal niet veranderen al heb je
1 standaard Linux-distributie.

Elke distributie die ik tel, tel jij waarschijnlijk minimaal als 2.
Ik tel 'slechts' een stuk of 5 relevante distributies.

2) Waarom kost een binary driver meer tijd?
Als er een probleem is met een binary videodriver krijg je rapportage.
"Hij doet 't niet."

De waarde van de ondersteuning van de distributie wordt praktisch
gereduceerd tot doorgeefluik. De distributeur moet meer klachten
verwerken als deze niet snel genoeg opgelost worden.

Bij een binary driver krijgt de ontwikkelaar minder goede informatie
terug, dus is vaak extra communicatie nodig. Hij moet zelf meer werk
verrichten voor het schrijven van een patch. Het kost tijd waar het
het meest pijn doet (patchen gaat ten koste van ontwikkeling).


3) Binary patches vertragen ontwikkeling en releases.
Distributeur pusht om een release uit te kunnen brengen. Daarvoor
starten ze al met een development-versie van X. NVidia geeft geen
ontwikkelversie vrij, release vertraagt.

X wordt gereleased, binary driver wordt vrijgegevan en het beta project
wordt dus nu pas gestart (vertraging kost extra tijd!). De keus is dus
extra vertraging of een release met (ongeteste) beta drivers. Release
versnellen om tijd te winnen kost extra tijd. Release ingaan met
ongeteste drivers kost extra tijd. Vertraging, versnelling en ongeteste
release ondergraven de positie van de distributeur.

Met een open source driver kan de distributeur zijn beta eerder starten
(gelijk met de andere open source drivers), meer en betere terugkoppeling
geven op de beta drivers en sneller een beter produkt releasen.


4) "Natuurlijke selectie" vergroot problemen voor beginners.
Door "natuurlijke selectie" leren ervaren gebruikers systemen te kiezen
die minder problemen opleveren. In het teststadium worden probleem-
kaarten niet of minder getest.

Meer kans op een beginner die tegen een probleem aanloopt en dus meer
werk voor de distributeur. En een doorgeefluik. En minder tijd voor
ontwikkeling van de driver door de programmeur. En een kortere
testperiode.


Feitelijk wordt het 'ecosysteem' van Linux buiten spel gezet door het
gebruik van binary drivers. Dat vormt een extra belasting op de hele
'community'.

Vrij vertaald: het kost extra tijd. Meer kans dat niet kan worden
geleverd of dat niet _op_tijd_ kan worden geleverd. Of dat geen
acceptabele kwaliteit wordt gehaald. Meer werk, gebruikers lopen weg.

Op dit moment zijn grafische kaarten en binary drivers nog showstoppers
voor Linux. Gelukkig is de hele netbook hype opgebouwd rond een intel
videokaart. Misschien niet de beste 3D prestaties maar wel goede
ondersteuning en een eenvoudige installatie. Beter als bij NVidia.

Met vriendelijke groet,
Huub Reuver

[Marcel]

Post by Huub Reuver

Post by Marcel

Post by Huub Reuver

Post by Joost

Post by Huub Reuver
- Onderhoud van een systeem met binary drivers kost meer tijd dan met
open source drivers.

Stierenschijt. Ik heb jarenlang Fedora met de livna repository gedraaid.
Nieuwe kernel? Binnen een paar uur was de bijbehorende nvidia driver via
yum te installeren. Dat jij meer tijd nodig hebt geeft meer aan dat jij
je systemen verkeerd inricht dan dat de closed source driver producenten
fout zitten.

Je zegt "het kost mij geen tijd", want "fedora heeft er al de nodige tijd
ingestoken".
Mijn stelling is "het kost meer tijd dan noodzakelijk als de drivers
gewoon meeontwikkeld zouden worden met de standaard kernel". Want de tijd
die Fedora erin steekt zou jij ook mee moeten tellen. Inclusief de tijd
voor backports als de driver moeilijker is aan te passen dan de rest van
de kernel.

Het kost ook meer tijd dan noodzakelijk om 100+ verschillende
distributies te onderhouden.
Met andere woorden, zou je ook pleiten voor een enkele (vooruit een
stuk of 5) distributie ?

1) Hoeveel pakketten zijn er die jij eventueel zou toepassen als je
huidige distributie zou stoppen?
Buiten RedHat (Fedora), SUSE (OpenSUSE), Ubuntu en Debian zijn er weinig
pakketten die generiek toepasbaar zijn. Pakketten als Xandros/Linspire
zie ik niet als vervanging voor een Fedora of RedHat.
Veel van de overige pakketten zijn forks die voor specifieke toepassingen
zijn (en daarop gericht worden onderhouden) en forks die slecht of niet
worden onderhouden (ik verwacht dat eeebuntu uiteindelijk weer opgaat in
ubuntu). Dat mensen daar tijd insteken zal niet veranderen al heb je
1 standaard Linux-distributie.
Elke distributie die ik tel, tel jij waarschijnlijk minimaal als 2.
Ik tel 'slechts' een stuk of 5 relevante distributies.

Tijd blijft imho een onzin argument als je ziet hoeveel tijd er
verspild wordt aan 100+ distributies.
Dat getal tel ik overigens niet zelf, gewoon even gekeken op
distrowatch.com waar een lijst van 100 stuks staat.

Post by Huub Reuver
2) Waarom kost een binary driver meer tijd?
Als er een probleem is met een binary videodriver krijg je rapportage.
"Hij doet 't niet."

En dat is anders bij een niet binary videodriver ?

Post by Huub Reuver
De waarde van de ondersteuning van de distributie wordt praktisch
gereduceerd tot doorgeefluik. De distributeur moet meer klachten
verwerken als deze niet snel genoeg opgelost worden.

Hoezo ?
De distributeur kan ook gewoon aangeven dat het probleem elders ligt.

Post by Huub Reuver
Bij een binary driver krijgt de ontwikkelaar minder goede informatie
terug, dus is vaak extra communicatie nodig. Hij moet zelf meer werk
verrichten voor het schrijven van een patch. Het kost tijd waar het
het meest pijn doet (patchen gaat ten koste van ontwikkeling).

Waarom komt er minder goede informatie terug ?
Als je het mij vraagt is dat niet meer dan een aanname die je doet om
je verhaal te ondersteunen.

Post by Huub Reuver
3) Binary patches vertragen ontwikkeling en releases.
Distributeur pusht om een release uit te kunnen brengen. Daarvoor
starten ze al met een development-versie van X. NVidia geeft geen
ontwikkelversie vrij, release vertraagt.
X wordt gereleased, binary driver wordt vrijgegevan en het beta project
wordt dus nu pas gestart (vertraging kost extra tijd!). De keus is dus
extra vertraging of een release met (ongeteste) beta drivers. Release
versnellen om tijd te winnen kost extra tijd. Release ingaan met
ongeteste drivers kost extra tijd. Vertraging, versnelling en ongeteste
release ondergraven de positie van de distributeur.
Met een open source driver kan de distributeur zijn beta eerder starten
(gelijk met de andere open source drivers), meer en betere terugkoppeling
geven op de beta drivers en sneller een beter produkt releasen.

Ik zie het probleem niet zo van een release die wat later is.

[Huub Reuver]

Post by Marcel

Post by Huub Reuver

Post by Marcel

Post by Huub Reuver

Post by Joost

Post by Huub Reuver
- Onderhoud van een systeem met binary drivers kost meer tijd dan met
open source drivers.

Stierenschijt. Ik heb jarenlang Fedora met de livna repository gedraaid.
Nieuwe kernel? Binnen een paar uur was de bijbehorende nvidia driver via
yum te installeren. Dat jij meer tijd nodig hebt geeft meer aan dat jij
je systemen verkeerd inricht dan dat de closed source driver producenten
fout zitten.

Je zegt "het kost mij geen tijd", want "fedora heeft er al de nodige tijd
ingestoken".
Mijn stelling is "het kost meer tijd dan noodzakelijk als de drivers
gewoon meeontwikkeld zouden worden met de standaard kernel". Want de tijd
die Fedora erin steekt zou jij ook mee moeten tellen. Inclusief de tijd
voor backports als de driver moeilijker is aan te passen dan de rest van
de kernel.

Het kost ook meer tijd dan noodzakelijk om 100+ verschillende
distributies te onderhouden.
Met andere woorden, zou je ook pleiten voor een enkele (vooruit een
stuk of 5) distributie ?

..

Post by Marcel

Post by Huub Reuver
Elke distributie die ik tel, tel jij waarschijnlijk minimaal als 2.
Ik tel 'slechts' een stuk of 5 relevante distributies.

Tijd blijft imho een onzin argument als je ziet hoeveel tijd er
verspild wordt aan 100+ distributies.

Wat wil jij?
Een distributie voor alles?

Ubuntu, eeebuntu, LEAF, RedHat ES en SUSE ES zijn volgens mij niet te
vangen in een distributie. Zelfs als RedHat en SUSE gelijkwaardig
lijken bieden ze de gebruiker heel andere voordelen.

Even buiten het feit dat een ontwikkeling in Ubuntu uiteindelijk
ook leidt tot een verbetering van RedHat (en andersom).

Post by Marcel

Post by Huub Reuver
2) Waarom kost een binary driver meer tijd?
Als er een probleem is met een binary videodriver krijg je rapportage.
"Hij doet 't niet."

En dat is anders bij een niet binary videodriver ?

Rapportage kan alles zijn van "Hij doet 't niet" tot een bugtraces
of een kant en klare patch.

Ik ga er voor het gemak even van uit (ja, weer een aanname) dat
mensen die een probleem kunnen debuggen en daar tijd in willen
steken dit vooral doen bij een open source driver. Om die reden
verwacht ik bij open source drivers meer "deskundige gebruikers"
en dus meer en beter bruikbare terugkoppeling.

Voor het debuggen van een closed source driver wil je toch echt
betaald worden. Ik zie hierbij "debuggen" met als doel "reverse
engineering" als een speciaal geval dat ik buiten beschouwing laat.

Post by Marcel

Post by Huub Reuver
De waarde van de ondersteuning van de distributie wordt praktisch
gereduceerd tot doorgeefluik. De distributeur moet meer klachten
verwerken als deze niet snel genoeg opgelost worden.

Hoezo ?
De distributeur kan ook gewoon aangeven dat het probleem elders ligt.

Ja, in plaats van 1 keer het probleem te analyseren en op te lossen
bij een open source driver kan een distributeur 10 kaar aangeven
dat het probleem elders ligt. En daarna kan hij klagen dat alle
gebruikers switchen naar een distributie die zelf ook iets doet.

Ik zie zelf alleen toegevoegde waarde in een distributeur die
problemen terugkoppelt en oplost. Oplossen van een probleem betekent
isoleren, debuggen, tracen en uiteindelijk een patch uitbrengen.
Natuurlijk is een distributeur blij als zijn klanten hem de oplossing
aandragen. Maar in de regel wordt hij betaald omdat hij zelf dat
terugkoppelt en terugkomt met een oplossing.

Is je ooit opgevallen dat lijst van de 100 meest produktieve kernel-
hackers veel werknemers van redhat en suse bevat? Een verkoop argument
van veel distributies is dat ze ZELF problemen kunnen oplossen. Als
daaruit volgt dat veel klanten gebaat zijn bij een complete rewrite
van de driver, dan komt er een patch met een rewrite.

Bij hardware binaries kan een developper een probleem gaan voorkauwen
voor de hardware distributeur en complete traces aanleveren. Waarom
zou hij dat doen? Aanleveren van de juiste traces kost tijd en geld.
En de leverancier geeft met een binary driver duidelijk te kennen
dat de distributeur geen volwaardige partner is.

Hier geldt "Voor het debuggen van een closed source driver wil je toch
echt betaald worden.".

Post by Marcel

Post by Huub Reuver
Bij een binary driver krijgt de ontwikkelaar minder goede informatie
terug, dus is vaak extra communicatie nodig. Hij moet zelf meer werk
verrichten voor het schrijven van een patch. Het kost tijd waar het
het meest pijn doet (patchen gaat ten koste van ontwikkeling).

Waarom komt er minder goede informatie terug ?
Als je het mij vraagt is dat niet meer dan een aanname die je doet om
je verhaal te ondersteunen.

Nogmaals, de betere distributies hebben goede programmeurs in dienst.
Zij kunnen, mits de klanten erom vragen, een goede ondersteuning bieden
voor de driver-programmeurs van fabrikanten.

Post by Marcel

Post by Huub Reuver
3) Binary patches vertragen ontwikkeling en releases.

..

Post by Marcel
Ik zie het probleem niet zo van een release die wat later is.

Een latere beta-releaese betekent dat de functionaliteit later in de
produktie-releases terechtkomt. Dit betekent dat releases van de
distributie meer ondersteuning vragen (naleveren missende drivers of
debuggen beta-drivers) of later op de markt komen.

Als een produkt later op de markt komt is misschien de klant al
geswitched naar een concurrerend systeem dat wel voldoet. Dus minder
inkomsten of voorfinancieren. Beide betekent netto minder geld.


Maar bovenstaande is natuurlijk alleen een aanname gebaseerd op
vereenvoudiging en mijn zeer beperkte analyse mogelijkheden.
Dat neemt niet weg dat goodwill en betaalde support hier belangrijke
issues zijn.

Ik ga er vanuit dat leveranciers van binary drivers ook niet betalen
voor support. Dan komt de vraag omhoog drijven wie er wel betaalt
voor support van die drivers.

Met vriendelijke groet,
Huub Reuver

[Marcel]

Post by Huub Reuver

Post by Marcel

Post by Huub Reuver

Post by Marcel

Post by Huub Reuver

Post by Joost

Post by Huub Reuver
- Onderhoud van een systeem met binary drivers kost meer tijd dan met
open source drivers.

Stierenschijt. Ik heb jarenlang Fedora met de livna repository gedraaid.
Nieuwe kernel? Binnen een paar uur was de bijbehorende nvidia driver via
yum te installeren. Dat jij meer tijd nodig hebt geeft meer aan dat jij
je systemen verkeerd inricht dan dat de closed source driver producenten
fout zitten.

Je zegt "het kost mij geen tijd", want "fedora heeft er al de nodige tijd
ingestoken".
Mijn stelling is "het kost meer tijd dan noodzakelijk als de drivers
gewoon meeontwikkeld zouden worden met de standaard kernel". Want de tijd
die Fedora erin steekt zou jij ook mee moeten tellen. Inclusief de tijd
voor backports als de driver moeilijker is aan te passen dan de rest van
de kernel.

Het kost ook meer tijd dan noodzakelijk om 100+ verschillende
distributies te onderhouden.
Met andere woorden, zou je ook pleiten voor een enkele (vooruit een
stuk of 5) distributie ?

..

Post by Marcel

Post by Huub Reuver
Elke distributie die ik tel, tel jij waarschijnlijk minimaal als 2.
Ik tel 'slechts' een stuk of 5 relevante distributies.

Tijd blijft imho een onzin argument als je ziet hoeveel tijd er
verspild wordt aan 100+ distributies.

Wat wil jij?
Een distributie voor alles?

Huh ??
Geen idee hoe je tot een dergelijke vraag komt.
Ik reageer nog steeds op de opmerking dat er tijd verspild wordt door
Fedora als het om nvidia drivers gaat omdat ze geen open source zijn.

Post by Huub Reuver
Ubuntu, eeebuntu, LEAF, RedHat ES en SUSE ES zijn volgens mij niet te
vangen in een distributie. Zelfs als RedHat en SUSE gelijkwaardig
lijken bieden ze de gebruiker heel andere voordelen.

Het voordeel dat er een ander naampje op de doos staat ?
Het zou niet zo kunnen zijn dat bij het bundelen van alle krachten die
nu 100+ distributies onderhouden voordelen samen komen zodat er een
distributie ontstaat met nog veel meer voordelen ?

Post by Huub Reuver
Even buiten het feit dat een ontwikkeling in Ubuntu uiteindelijk
ook leidt tot een verbetering van RedHat (en andersom).

Wat dus tijdverspilling is als we jouw redenatie volgen.
Zeg maar twee keer het wiel uitvinden of misschien een keer uitvinden
en vervolgens moet de ander het ook implementeren wat tijd kost.

Post by Huub Reuver

Post by Marcel

Post by Huub Reuver
2) Waarom kost een binary driver meer tijd?
Als er een probleem is met een binary videodriver krijg je rapportage.
"Hij doet 't niet."

En dat is anders bij een niet binary videodriver ?

Rapportage kan alles zijn van "Hij doet 't niet" tot een bugtraces
of een kant en klare patch.

Het kan maar dat wil nog niet garanderen dat het ook op die manier
gebeurt.

Post by Huub Reuver
Ik ga er voor het gemak even van uit (ja, weer een aanname) dat
mensen die een probleem kunnen debuggen en daar tijd in willen
steken dit vooral doen bij een open source driver. Om die reden
verwacht ik bij open source drivers meer "deskundige gebruikers"
en dus meer en beter bruikbare terugkoppeling.

En hoeveel mensen lopen er nu daadwerkelijk op deze aardbol rond die
dat kunnen, dat willen en daar ook tijd voor vrij (kunnen) maken in
verhouding tot het aantal gebruikers dat niet veel verder komt dan
"hij doet het niet"

Post by Huub Reuver

Post by Marcel

Post by Huub Reuver
De waarde van de ondersteuning van de distributie wordt praktisch
gereduceerd tot doorgeefluik. De distributeur moet meer klachten
verwerken als deze niet snel genoeg opgelost worden.

Hoezo ?
De distributeur kan ook gewoon aangeven dat het probleem elders ligt.

Ja, in plaats van 1 keer het probleem te analyseren en op te lossen
bij een open source driver kan een distributeur 10 kaar aangeven
dat het probleem elders ligt. En daarna kan hij klagen dat alle
gebruikers switchen naar een distributie die zelf ook iets doet.

Ja en ?
Dat is toch die vrijheid waar Linux zo om geprezen wordt ?
Bevalt iets niet aan een distributie switch je gewoon naar een andere.

Post by Huub Reuver
Is je ooit opgevallen dat lijst van de 100 meest produktieve kernel-
hackers veel werknemers van redhat en suse bevat? Een verkoop argument
van veel distributies is dat ze ZELF problemen kunnen oplossen. Als
daaruit volgt dat veel klanten gebaat zijn bij een complete rewrite
van de driver, dan komt er een patch met een rewrite.

Nope is me nooit opgevallen om de simpele reden dat het mijn interesse
niet heeft.
Ik draai al jaren naar tevredenheid Debian en het zal me eerlijk
gezegd worst wezen wie wat maakt.
Linux is voor mij een middel en geen doel.
Ook het hele idee achter open source ed zegt mij persoonlijk weinig
tot niets, het is voor mij niets meer en minder dan een stuk
gereedschap.

Post by Huub Reuver
Bij hardware binaries kan een developper een probleem gaan voorkauwen
voor de hardware distributeur en complete traces aanleveren. Waarom
zou hij dat doen? Aanleveren van de juiste traces kost tijd en geld.
En de leverancier geeft met een binary driver duidelijk te kennen
dat de distributeur geen volwaardige partner is.

Die mening deel ik niet.
De leverancier geeft met een binary driver aan dat hij bepaalde dingen
niet aan de grote klok wil hangen ivm bijv concurrentie.
Nog even buiten beschouwing gelaten dat er misschien gebruik gemaakt
wordt van patenten oid van derden die niet open source mogen/kunnen
worden.
Weinig fabrikanten zitten er om te springen om bedrijfsgeheimen zomaar
openbaar te maken.

Post by Huub Reuver

Post by Marcel

Post by Huub Reuver
Bij een binary driver krijgt de ontwikkelaar minder goede informatie
terug, dus is vaak extra communicatie nodig. Hij moet zelf meer werk
verrichten voor het schrijven van een patch. Het kost tijd waar het
het meest pijn doet (patchen gaat ten koste van ontwikkeling).

Waarom komt er minder goede informatie terug ?
Als je het mij vraagt is dat niet meer dan een aanname die je doet om
je verhaal te ondersteunen.

Nogmaals, de betere distributies hebben goede programmeurs in dienst.
Zij kunnen, mits de klanten erom vragen, een goede ondersteuning bieden
voor de driver-programmeurs van fabrikanten.

En de fabrikant heeft goede programmeurs in huis die toegang hebben
tot alle informatie die bestaat mbt het produkt.

Post by Huub Reuver

Post by Marcel

Post by Huub Reuver
3) Binary patches vertragen ontwikkeling en releases.

..

Post by Marcel
Ik zie het probleem niet zo van een release die wat later is.

Een latere beta-releaese betekent dat de functionaliteit later in de
produktie-releases terechtkomt. Dit betekent dat releases van de
distributie meer ondersteuning vragen (naleveren missende drivers of
debuggen beta-drivers) of later op de markt komen.
Als een produkt later op de markt komt is misschien de klant al
geswitched naar een concurrerend systeem dat wel voldoet. Dus minder
inkomsten of voorfinancieren. Beide betekent netto minder geld.

Zoals gezegd maak ik al jaren gebruik van Debian dus het hele principe
van release dates zegt mij zowieso helemaal niks ;-)
Daarnaast geloof ik er weinig tot niets van dat een klant van
distributie wisselt omdat een release uitgesteld wordt.
De meeste bedrijven die ik Linux zie gebruiken kopen een distributie
gelijktijdig met nieuwe hardware en doen pas een upgrade naar een
nieuwe release als er weer nieuwe hardware aangeschaft wordt.
Jouw principe zou overigens in theorie opgaan voor iedere distributie
aangezien ze allemaal met een closed source driver moeten werken en
dus allemaal de release date niet halen.

Post by Huub Reuver
Ik ga er vanuit dat leveranciers van binary drivers ook niet betalen
voor support. Dan komt de vraag omhoog drijven wie er wel betaalt
voor support van die drivers.

De klant die het produkt koopt waarschijnlijk.
Zal gewoon ingecalculeerd worden in de aanschafprijs lijkt mij.

[Joost de Heer]

Post by Marcel
Geen idee hoe je tot een dergelijke vraag komt.
Ik reageer nog steeds op de opmerking dat er tijd verspild wordt door
Fedora als het om nvidia drivers gaat omdat ze geen open source zijn.

Fedora levert die drivers niet, dat doen 3rd party repositories (bijv.
Livna, die overigens nog veel meer levert). Fedora verliest dus geen tijd.

Joost

[Marcel]

Post by Joost de Heer

Post by Marcel
Geen idee hoe je tot een dergelijke vraag komt.
Ik reageer nog steeds op de opmerking dat er tijd verspild wordt door
Fedora als het om nvidia drivers gaat omdat ze geen open source zijn.

Fedora levert die drivers niet, dat doen 3rd party repositories (bijv.
Livna, die overigens nog veel meer levert). Fedora verliest dus geen tijd.

Huub denkt daar toch anders over :
===
Mijn stelling is "het kost meer tijd dan noodzakelijk als de drivers
gewoon meeontwikkeld zouden worden met de standaard kernel". Want de
tijd
die Fedora erin steekt zou jij ook mee moeten tellen. Inclusief de
tijd
voor backports als de driver moeilijker is aan te passen dan de rest
van
de kernel.
===

[Huub Reuver]

Post by Marcel

Post by Huub Reuver

Post by Marcel

Post by Huub Reuver

Post by Marcel

Post by Huub Reuver

Post by Joost

Post by Huub Reuver
- Onderhoud van een systeem met binary drivers kost meer tijd dan met
open source drivers.

Stierenschijt. Ik heb jarenlang Fedora met de livna repository gedraaid.
Nieuwe kernel? Binnen een paar uur was de bijbehorende nvidia driver via
yum te installeren. Dat jij meer tijd nodig hebt geeft meer aan dat jij
je systemen verkeerd inricht dan dat de closed source driver producenten
fout zitten.

Je zegt "het kost mij geen tijd", want "fedora heeft er al de nodige tijd
ingestoken".
Mijn stelling is "het kost meer tijd dan noodzakelijk als de drivers
gewoon meeontwikkeld zouden worden met de standaard kernel". Want de tijd
die Fedora erin steekt zou jij ook mee moeten tellen. Inclusief de tijd
voor backports als de driver moeilijker is aan te passen dan de rest van
de kernel.

Het kost ook meer tijd dan noodzakelijk om 100+ verschillende
distributies te onderhouden.
Met andere woorden, zou je ook pleiten voor een enkele (vooruit een
stuk of 5) distributie ?

..

Post by Marcel

Post by Huub Reuver
Elke distributie die ik tel, tel jij waarschijnlijk minimaal als 2.
Ik tel 'slechts' een stuk of 5 relevante distributies.

Tijd blijft imho een onzin argument als je ziet hoeveel tijd er
verspild wordt aan 100+ distributies.

Wat wil jij?
Een distributie voor alles?

Huh ??
Geen idee hoe je tot een dergelijke vraag komt.
Ik reageer nog steeds op de opmerking dat er tijd verspild wordt door
Fedora als het om nvidia drivers gaat omdat ze geen open source zijn.

Post by Huub Reuver
Ubuntu, eeebuntu, LEAF, RedHat ES en SUSE ES zijn volgens mij niet te
vangen in een distributie. Zelfs als RedHat en SUSE gelijkwaardig
lijken bieden ze de gebruiker heel andere voordelen.

Het voordeel dat er een ander naampje op de doos staat ?
Het zou niet zo kunnen zijn dat bij het bundelen van alle krachten die
nu 100+ distributies onderhouden voordelen samen komen zodat er een
distributie ontstaat met nog veel meer voordelen ?

Dus toch een distributie voor alles.
Nee, wat jij noemt is een illusie, net als 40.000 man droppen op Texel
en hopen dat er na een jaar een blauwdruk voor wereldvrede uitrolt.

Post by Marcel

Post by Huub Reuver
Bij hardware binaries kan een developper een probleem gaan voorkauwen
voor de hardware distributeur en complete traces aanleveren. Waarom
zou hij dat doen? Aanleveren van de juiste traces kost tijd en geld.
En de leverancier geeft met een binary driver duidelijk te kennen
dat de distributeur geen volwaardige partner is.

Die mening deel ik niet.
De leverancier geeft met een binary driver aan dat hij bepaalde dingen
niet aan de grote klok wil hangen ivm bijv concurrentie.

En de concurrentie heeft die informatie niet allang door reverse
engineering?

...

Post by Marcel

Post by Huub Reuver

Post by Marcel

Post by Huub Reuver
3) Binary patches vertragen ontwikkeling en releases.

..

Post by Marcel
Ik zie het probleem niet zo van een release die wat later is.

Een latere beta-releaese betekent dat de functionaliteit later in de
produktie-releases terechtkomt. Dit betekent dat releases van de
distributie meer ondersteuning vragen (naleveren missende drivers of
debuggen beta-drivers) of later op de markt komen.
Als een produkt later op de markt komt is misschien de klant al
geswitched naar een concurrerend systeem dat wel voldoet. Dus minder
inkomsten of voorfinancieren. Beide betekent netto minder geld.

Zoals gezegd maak ik al jaren gebruik van Debian dus het hele principe
van release dates zegt mij zowieso helemaal niks ;-)
Daarnaast geloof ik er weinig tot niets van dat een klant van
distributie wisselt omdat een release uitgesteld wordt.
De meeste bedrijven die ik Linux zie gebruiken kopen een distributie
gelijktijdig met nieuwe hardware en doen pas een upgrade naar een
nieuwe release als er weer nieuwe hardware aangeschaft wordt.
Jouw principe zou overigens in theorie opgaan voor iedere distributie
aangezien ze allemaal met een closed source driver moeten werken en
dus allemaal de release date niet halen.

"Ik gebruik Debian dus ik heb niets te maken met geld en nieuwe
ontwikkelingen."

Wake up. Misschien sta je met je eerstvolgende pc al voor het blok.

Post by Marcel

Post by Huub Reuver
Ik ga er vanuit dat leveranciers van binary drivers ook niet betalen
voor support. Dan komt de vraag omhoog drijven wie er wel betaalt
voor support van die drivers.

De klant die het produkt koopt waarschijnlijk.
Zal gewoon ingecalculeerd worden in de aanschafprijs lijkt mij.

De klant ziet dus een hogere prijs, een uitgelopen levertijd en
in vergelijking een produkt dat de capaciteiten van de hardware
niet gebruikt...
Denk je dat de klant in dat geval overschakeld naar Open Source?
Of dat de klant misschien terug migreert naar Windows? Of Mac-OS?

Als alle opties closed source zijn heeft Linux een sterk punt minder.

Ja, ik zie een groot verschil in ontwikkeling voor linux in open
source (investering) en closed source (desinvestering). Closed
source is binnen Linux mogelijk en soms zelfs nuttig. Ik heb alleen
nog geen goede nuttige toepassing gezien van closed source in een
kritiek onderdeel als de kernel en al helemaal niet in de kernel van
een standaard pc.

Het blijft een feit dat je de programmeurs van open source bedrijven
onderschat en die van NVidia overschat. Door code inspection kan
code alleen verbeteren. Door samenwerking hoeft NVidia niet alle
werk zelf te doen. Dan heb je in dezelfde tijd een nuttige uitbreiding
van Linux, die niet afhankelijk is van 1 leverancier.

Denk je werkelijk dat je door het opsluiten van goede (?) programmeurs
met documentatie en hardware betere code krijgt?
Met 3-4% marktpenetratie is dat zo over na een (1) bezuinigingsronde.
Who cares?

Met vriendelijke groet,
Huub Reuver

[unknown]

Post by Huub Reuver
- Er zijn veel enthousiaste NVidia-gebruikers met Linux.

Of enthousiaste Linux-gebruikers met Nvidia. Ik ben er eentje van. Ik
weet niet eens wat voor driver ik heb, Envy heeft ze geinstalleerd en
het werkt allemaal goed. Toegegeven, ik gebruik geen 3D dingetjes.

Post by Huub Reuver
- NVidia steekt veel moeite in de drivers [1].
- Bij closed source zit je vast aan de drivers geleverd door NVidia, ook
bij een driver voor een nieuwe kernel voor een bestaand systeem.

Bij open source zit ik vast aan de drivers geleverd door de kernel
hackers. Persoonlijk heb ik liever een driver van Nvidia, met complete
toegang tot documentatie, hardware engineers, etc, dan eentje die in
elkaar gehobbyt (sp?) is door iemand op zijn zolderkamer.

Post by Huub Reuver
- Onderhoud van een systeem met binary drivers kost meer tijd dan met
open source drivers.

Dat snap ik niet. Onderhoud is toch gewoon, driver downloaden,
installeren, testen, uitrollen? Of dat ding nou open of binary is, maakt
toch geen klap uit?

Bart

[Sabayon User]

Post by unknown

Post by Huub Reuver
- Er zijn veel enthousiaste NVidia-gebruikers met Linux.

Of enthousiaste Linux-gebruikers met Nvidia. Ik ben er eentje van. Ik
weet niet eens wat voor driver ik heb, Envy heeft ze geinstalleerd en
het werkt allemaal goed. Toegegeven, ik gebruik geen 3D dingetjes.

3D werkt ook goed. Het is alleen jammer dat de Geforce modellen zo heet
worden onder Linux en daardoor snel kapot gaan.

Heb tijdens de vorige videokaartwissel ook een case-fan gemonteerd in de
toch al vrij grote kast. Heeft helaas weinig resultaat (> 10 graden
Celsius). De huidige Geforce 8500GT wordt 71 graden en bij wat extra 3D
werk wordt de 85 - 90 wel gehaald.

Vanwege de goede prestaties zal de volgende kaart weer een Geforce
worden, ben videokaarten maar als slijtageonderdeel gaan zien ;-)

[Klaasjan Brand]

Post by Sabayon User
3D werkt ook goed. Het is alleen jammer dat de Geforce modellen zo heet
worden onder Linux en daardoor snel kapot gaan.

Worden ze heter onder Linux dan onder een ander OS? (dat zou dan dus aan
de nvidia driver moeten liggen, wat me erg sterk lijkt)

Post by Sabayon User
Heb tijdens de vorige videokaartwissel ook een case-fan gemonteerd in de
toch al vrij grote kast. Heeft helaas weinig resultaat (> 10 graden
Celsius). De huidige Geforce 8500GT wordt 71 graden en bij wat extra 3D
werk wordt de 85 - 90 wel gehaald.

1) Je hebt een GT versie, wat betekent dat je een snellere core en
geheugen hebt, maar dat meer warmte zal ontwikkelen.
2) 90 graden core temperatuur kan best binnen de normale
bedrijfstemperatuurmarge vallen.
3) Je overclocked toch niet he? :)

Post by Sabayon User
Vanwege de goede prestaties zal de volgende kaart weer een Geforce
worden, ben videokaarten maar als slijtageonderdeel gaan zien ;-)

Tuurlijk. Gewoon met oogkleppen op een nieuwe kopen. Persoonlijk zie ik
"om de haverklap uitvallen" niet echt als een goede prestatie.

Kj

[Sabayon User]

Post by Klaasjan Brand
1) Je hebt een GT versie, wat betekent dat je een snellere core en
geheugen hebt, maar dat meer warmte zal ontwikkelen. 2) 90 graden core
temperatuur kan best binnen de normale bedrijfstemperatuurmarge vallen.
3) Je overclocked toch niet he?

Post by Sabayon User
Vanwege de goede prestaties zal de volgende kaart weer een Geforce
worden, ben videokaarten maar als slijtageonderdeel gaan zien ;-)

Tuurlijk. Gewoon met oogkleppen op een nieuwe kopen. Persoonlijk zie ik
"om de haverklap uitvallen" niet echt als een goede prestatie.

Volgens hardware Goeroes is 70-80 werktemperatuur goed voor versneld
afschrijven. Een Geforce 7 / 8 / 9 schijnt onder Windows iets van 40-50
graden te doen in idle toestand.

De vorige was een passief gekoelde MSI 7600GS (na anderhalf jaar defect)
en nu heb ik een passief gekoelde Asus 8500GT in mijn systeem zitten die
na ruim een jaar aftakelings verschijnselen begint te vertonen.

Volgende wordt sowieso een actief gekoelde videokaart uit de Geforce 9
serie. Het houdt me wel up to date ;-)

Zo hard hoeven videokaarten niet bij me te werken, 2 19" inch 4:3 TFT
monitoren met de 3D kubus uitgeschakeld (werkte niet lekker over 2
schermen). Ga ik glxgears draaien of een spelletje spelen (TORCS of
Alienarena) zit de kaart in no time op 90 graden Celsius.

[Marcel]

On Sun, 4 Jan 2009 20:31:21 +0000 (UTC), Sabayon User

Post by Sabayon User

Post by Klaasjan Brand
1) Je hebt een GT versie, wat betekent dat je een snellere core en
geheugen hebt, maar dat meer warmte zal ontwikkelen. 2) 90 graden core
temperatuur kan best binnen de normale bedrijfstemperatuurmarge vallen.
3) Je overclocked toch niet he?

Post by Sabayon User
Vanwege de goede prestaties zal de volgende kaart weer een Geforce
worden, ben videokaarten maar als slijtageonderdeel gaan zien ;-)

Tuurlijk. Gewoon met oogkleppen op een nieuwe kopen. Persoonlijk zie ik
"om de haverklap uitvallen" niet echt als een goede prestatie.

Volgens hardware Goeroes is 70-80 werktemperatuur goed voor versneld
afschrijven. Een Geforce 7 / 8 / 9 schijnt onder Windows iets van 40-50
graden te doen in idle toestand.
De vorige was een passief gekoelde MSI 7600GS (na anderhalf jaar defect)
en nu heb ik een passief gekoelde Asus 8500GT in mijn systeem zitten die
na ruim een jaar aftakelings verschijnselen begint te vertonen.
Volgende wordt sowieso een actief gekoelde videokaart uit de Geforce 9
serie. Het houdt me wel up to date ;-)
Zo hard hoeven videokaarten niet bij me te werken, 2 19" inch 4:3 TFT
monitoren met de 3D kubus uitgeschakeld (werkte niet lekker over 2
schermen). Ga ik glxgears draaien of een spelletje spelen (TORCS of
Alienarena) zit de kaart in no time op 90 graden Celsius.

Kennelijk besef je niet dat het probleem niet in de videokaart zit
maar eerder in je behuizing waar kennelijk een gebrek is aan een
fatsoenlijke airflow.
Fatsoenlijk koelen van een passieve gekoelde videokaart bestaat
slechts bij de gratie van een goede airflow.
Heb je die airflow niet kan een passief gekoelde videokaart z'n warmte
niet kwijt.
Verwacht overigens geen wonderen van een actief gekoelde kaart tenzij
deze geforceerd naar buiten blaast, ook die heeft tenslotte airflow
nodig om de warmte uiteindelijk uit de kast te krijgen.

[Paul van der Vlis]

Post by unknown

Post by Huub Reuver
- Er zijn veel enthousiaste NVidia-gebruikers met Linux.

Of enthousiaste Linux-gebruikers met Nvidia. Ik ben er eentje van. Ik
weet niet eens wat voor driver ik heb, Envy heeft ze geinstalleerd en
het werkt allemaal goed. Toegegeven, ik gebruik geen 3D dingetjes.

Post by Huub Reuver
- NVidia steekt veel moeite in de drivers [1].
- Bij closed source zit je vast aan de drivers geleverd door NVidia, ook
bij een driver voor een nieuwe kernel voor een bestaand systeem.

Bij open source zit ik vast aan de drivers geleverd door de kernel
hackers. Persoonlijk heb ik liever een driver van Nvidia, met complete
toegang tot documentatie, hardware engineers, etc, dan eentje die in
elkaar gehobbyt (sp?) is door iemand op zijn zolderkamer.

Dan heb je closed-source spul, en dat wil zeggen een slechte
ondersteuning door Linux kernel (dat is dan "tainted") en distributies.
Best mogelijk dat na een kernel update de boel niet meer werkt. Maar
gelukkig kun je dan nog overschakelen naar de open source driver.
En biedt Nvidia support voor jouw specifieke distributie en versie?

Post by unknown

Post by Huub Reuver
- Onderhoud van een systeem met binary drivers kost meer tijd dan met
open source drivers.

Dat snap ik niet. Onderhoud is toch gewoon, driver downloaden,
installeren, testen, uitrollen? Of dat ding nou open of binary is, maakt
toch geen klap uit?

Opensource drivers worden geleverd als onderdeel van X of de Linux
kernel, die hoef je niet apart te downloaden, installeren, testen of uit
te rollen. Hoeveel tijd wou je overigens besteden aan dat testen? Als ik
rare problemen zie bij een systeem met binary-drivers, dan zijn die de
eerste die ik ga verwijderen.

Met vriendelijke groet,
Paul van der Vlis.

[Rob]

Post by Paul van der Vlis

Post by unknown
Bij open source zit ik vast aan de drivers geleverd door de kernel
hackers. Persoonlijk heb ik liever een driver van Nvidia, met complete
toegang tot documentatie, hardware engineers, etc, dan eentje die in
elkaar gehobbyt (sp?) is door iemand op zijn zolderkamer.

Dan heb je closed-source spul, en dat wil zeggen een slechte
ondersteuning door Linux kernel (dat is dan "tainted") en distributies.

Maar wel goede ondersteuning van de hardware!

Post by Paul van der Vlis
Best mogelijk dat na een kernel update de boel niet meer werkt. Maar
gelukkig kun je dan nog overschakelen naar de open source driver.

Ja en dan zit je ineens met kreupele ondersteuning voor je videokaart.
Dat werkt dus niet.

Een videokaart driver is niet iets wat je "even in elkaar hacked", daar
is gedetailleerde kennis van de hardware voor nodig die wellicht zelfs
binnen het bedrijf wat de hardware maakt niet helemaal op papier beschikbaar
is. Daar kunnen ontwikkelaars elkaar gewoon vragen stellen.

"kan zijn dat het na een update niet werkt" dat is voor mij in een Linux
systeem een totaal non-argument want dat kan met ALLES wel zo zijn!

Ik heb pas nog mijn systeem geupdate naar een nieuwe versie (OpenSuSE 11.1)
en ik kan je vertellen: dan is er VAN ALLES wat niet meer werkt! Maar
de Nvidia driver nog wel.

Dingen die goed werken weer kapot maken daar houden Linux ontwikkelaars
gewoon van.
Sommige dingen krijg je met wat gepruts weer werkend, andere dingen moet je
hopen dat er fixes voor komen, de rest leg je je maar weer bij neer.

Er is altijd een balans van dingen die gaan werken na een update, en dingen
die altijd werkten en nu ineens niet meer.

[Hans W]

Post by Huub Reuver
Verder lijkt mij dit meer in de trent van "dan kunnen we de gebruikers
laten wachten met een leuker plaatje, want 24bpp, i.p.v. in een beperkte
tekstmode.

Laat ik voorop stellen dat ik niet al te veel kernel kennis heb.

Wat is er zo erg aan wachten op een bootende machine? Ik loop, als ik
al
moet booten, eerst naar mijn kantoor. Dan zet ik de machine aan en ga
vervolgens lekker koffie zetten.

Ik maak me drukker over eventuele exploits omdat userland meuk in
de kernel komt. Of begrijp ik dat niet goed?

Goed 2009,

Hans

[Martijn van Buul]

Post by Hans W
Ik maak me drukker over eventuele exploits omdat userland meuk in
de kernel komt. Of begrijp ik dat niet goed?

Dat begrijp je inderdaad niet goed. Nog afgezien van het feit dat er helemaal
geen userland meuk in de kernel komt (dat is een verkeerde interpretatie van
Huub) zou het overigens ook geen fluit uitmaken als dat wel zou gebeuren. Die
code draait al met veel te veel rechten, het naar de kernel trekken zou daar
weinig aan verslechteren.

[Huub Reuver]

Post by Hans W

Post by Huub Reuver
Verder lijkt mij dit meer in de trent van "dan kunnen we de gebruikers
laten wachten met een leuker plaatje, want 24bpp, i.p.v. in een beperkte
tekstmode.

Laat ik voorop stellen dat ik niet al te veel kernel kennis heb.

Ik ben zelf ook maar hobbyist. Misschien iets meer ervaring en iets
meer ingelezen dan gemiddeld, maar dat maakt mijn mening op z'n best
een "educated guess".

Post by Hans W
Wat is er zo erg aan wachten op een bootende machine? Ik loop, als ik
al
moet booten, eerst naar mijn kantoor. Dan zet ik de machine aan en ga
vervolgens lekker koffie zetten.

Ik vraag me ook een beetje af of dit een stap voorwaarts (of terug) is
of gewoon het zoveelste stapje in de ontwikkeling van:
- X-drivers schrijven rechstreeks in de kernel (MTRR en zo)
- X-drivers vervangen door fb-drivers in de kernel
- betere hardware toegang (en dus betere prestaties)

Ter informatie:
De term "kernel-mode" is volgens mij overgenomen van Windows waarbij deze
ontwikkeling al heeft plaatsgevonden. Daarbij was het commentaar voor
W2k dat een buffer overflow daarbij een groot risico werd.

Post by Hans W
Ik maak me drukker over eventuele exploits omdat userland meuk in
de kernel komt. Of begrijp ik dat niet goed?

Mits goed afgescheiden zal een exploit in userland nooit een probleem
kunnen vormen. Een userland programma kun je vaak afschermen in een
chroot-omgeving als je echt paranoia bent. Met X heb je natuurlijk de
kans een exploit op kernel-niveau te laten werken.

De userland driver zal bijna vanaf scratch herschreven moeten worden voor
een plaatsje in de kernel. Bij de huidige driverfabrikanten Intel, NVidia,
AMD/Ati en S3/VIA, zie je alleen een enorm verschil in de kwaliteit
van de drivers.

Mijn vraag is dan ook inderdaad of deze ontwikkeling leidt tot een
sneller systeem, als je voor beveiliging geen water bij de wijn wilt
doen.

Met vriendelijke groet,
Huub Reuver

[Martijn van Buul]

Post by Huub Reuver
Bij de introductie van de 2.6.28-kernel was je misschien opgevallen
dat er voorbereidingen zijn getroffen voor kernel mode-setting in
2.6.29.
http://www.phoronix.com/scan.php?page=news_item&px=Njk2MA
Het lijkt erop dat RedHat en Intel in navolging van Microsoft proberen
kerneldrivers voor X compleet op kernel-niveau te laten werken.

Je bent weer eens slecht ingelicht; Linux heeft al sinds *jaren* framebuffer
drivers en kernelspace video acceleratie. Dat is niets nieuws, en de steek
onderwater richting Microsoft (schijnt verplicht te zijn hier, stupide gedrag!)
is m.i. nogal onterecht, en vooral ook niet van toepassing.

Post by Huub Reuver
- "faster VT-switching"
- "improved suspend and resume support"
- "flicker-free boot experience"
- userproces (X) zit direct in de kernel te wroeten.

Dat doet X nu ook al, want X moet onder rootpriorities draaien, en heeft
dankzij de knullige architectuur van Linux ook nog eens toegang tot *alle*
hardware nodig. Dat is in de praktijk niet bijzonder veel beter of slechter
dan de hele rimram dan maar in kernelspace draaien. Overigens is er helemaal
nergens gezegd dat de videodrivers van X in kernelspace gaan draaien, dat is
een invulling die jij eraan geeft.

Het *enige* dat er gebeurt is dat de *configuratie* van een videokaart met KMS
consequent op *een* plek gebeurt, ipv allerlei vieze ranzige omwegen via X.
Dat biedt eigenlijk alleen maar voordelen. Als dat "in de kernel wroeten" is,
dan zal ieder proces zich daar wel aan bezoedelen dan.

Post by Huub Reuver
- idem voor binary-only kernels

1) Wat is er ook alweer mis met binary kernel modules?
2) En hoe is dat anders dan binary X servers?
3) Wat is de relevantie?

Post by Huub Reuver
Is dit alleen hyping of brengt het ook echte voordelen?

Nee, het is een overdreven reactie van jouw kant. Die 80x25 console waren we
toch al kwijt.

[Martijn van Buul]

Post by Huub Reuver
Bij de introductie van de 2.6.28-kernel was je misschien opgevallen
dat er voorbereidingen zijn getroffen voor kernel mode-setting in
2.6.29.
http://www.phoronix.com/scan.php?page=news_item&px=Njk2MA
Het lijkt erop dat RedHat en Intel in navolging van Microsoft proberen
kerneldrivers voor X compleet op kernel-niveau te laten werken.

Je bent weer eens slecht ingelicht; Linux heeft al sinds *jaren* framebuffer
drivers en kernelspace video acceleratie. Dat is niets nieuws, en de steek
onderwater richting Microsoft (schijnt verplicht te zijn hier, stupide gedrag!)
is m.i. nogal onterecht, en vooral ook niet van toepassing.

Post by Huub Reuver
- "faster VT-switching"
- "improved suspend and resume support"
- "flicker-free boot experience"
- userproces (X) zit direct in de kernel te wroeten.

Dat doet X nu ook al, want X moet onder rootprivileges draaien, en heeft
dankzij de knullige architectuur van Linux ook nog eens toegang tot *alle*
hardware nodig. Dat is in de praktijk niet bijzonder veel beter of slechter
dan de hele rimram dan maar in kernelspace draaien. Overigens is er helemaal
nergens gezegd dat de videodrivers van X in kernelspace gaan draaien, dat is
een invulling die jij eraan geeft.

Het *enige* dat er gebeurt is dat de *configuratie* van een videokaart met KMS
consequent op *een* plek gebeurt, ipv allerlei vieze ranzige omwegen via X.
Dat biedt eigenlijk alleen maar voordelen. Als dat "in de kernel wroeten" is,
dan zal ieder proces zich daar wel aan bezoedelen dan.

Post by Huub Reuver
- idem voor binary-only kernels

1) Wat is er ook alweer mis met binary kernel modules?
2) En hoe is dat anders dan binary X servers?
3) Wat is de relevantie?

Post by Huub Reuver
Is dit alleen hyping of brengt het ook echte voordelen?

Nee, het is een overdreven reactie van jouw kant. Die 80x25 console waren we
toch al kwijt.

[Philip Paeps]

Bij de introductie van de 2.6.28-kernel was je misschien opgevallen dat er
voorbereidingen zijn getroffen voor kernel mode-setting in 2.6.29.

Het zou tijd gaan worden.

http://www.phoronix.com/scan.php?page=news_item&px=Njk2MA
Het lijkt erop dat RedHat en Intel in navolging van Microsoft proberen
kerneldrivers voor X compleet op kernel-niveau te laten werken.

Daar heeft het niets mee te maken. Device drivers horen (in een monolitsche
kernel) nu eenmaal in kernel-space te draaien. Er zitten al sinds the
beginning of time allerlei hacks in de kernel zodat X11 drivers in userspace
kunnen draaien. Die approach barst al enige tijd uit zijn voegen.

- "faster VT-switching"
- "improved suspend and resume support"
- "flicker-free boot experience"

- More convenient device drivers
- Fewer layering violations

- userproces (X) zit direct in de kernel te wroeten.
- idem voor binary-only kernels

Eh - nee. In de huidige world order zit X11 rechtstreeks met hardware te
knoeien. In de nieuwe world order zal X11 aan de kernel vragen om de hardware
aan te sturen, zoals dat ook met andere devices het geval is. Weg layering
violation, weg zwaar proces van /dev/(k)mem.

Is dit alleen hyping of brengt het ook echte voordelen?

Het brengt voordelen en is jaren overdue.

- Philip

[Huub Reuver]

Post by Philip Paeps

Bij de introductie van de 2.6.28-kernel was je misschien opgevallen dat er
voorbereidingen zijn getroffen voor kernel mode-setting in 2.6.29.

Het zou tijd gaan worden.

http://www.phoronix.com/scan.php?page=news_item&px=Njk2MA
Het lijkt erop dat RedHat en Intel in navolging van Microsoft proberen
kerneldrivers voor X compleet op kernel-niveau te laten werken.

Daar heeft het niets mee te maken. Device drivers horen (in een monolitsche
kernel) nu eenmaal in kernel-space te draaien. Er zitten al sinds the
beginning of time allerlei hacks in de kernel zodat X11 drivers in userspace
kunnen draaien. Die approach barst al enige tijd uit zijn voegen.

- "faster VT-switching"
- "improved suspend and resume support"
- "flicker-free boot experience"

- More convenient device drivers
- Fewer layering violations

Ok, de berichtgeving die ik heb gezien noemt allerlei ontwikkelingen, maar
vergeet deze voordelen te noemen. Een cleanere interface is natuurlijk
altijd goed.

Post by Philip Paeps

- userproces (X) zit direct in de kernel te wroeten.
- idem voor binary-only kernels

Eh - nee. In de huidige world order zit X11 rechtstreeks met hardware te
knoeien. In de nieuwe world order zal X11 aan de kernel vragen om de hardware
aan te sturen, zoals dat ook met andere devices het geval is. Weg layering
violation, weg zwaar proces van /dev/(k)mem.

En alles dat schrijven naar /dev/(k)mem overbodig maakt is natuurlijk goed.

"Though nothing legitimately writes to /dev/kmem, XFree86 does need to
write to /dev/mem, but only to video memory, ... "
Benieuwd of dit nog impact heeft op mtrr's en het afspelen van video's.

Dat zal wel toekomstmuziek zijn.

Post by Philip Paeps

Is dit alleen hyping of brengt het ook echte voordelen?

Het brengt voordelen en is jaren overdue.

Dank voor je antwoord.

Ik zal eens kijken of ik hier in januari wat mee kan spelen.
Tenslotte zijn de kernel-mode patches voor een intel videokaart al
beschikbaar voor 2.6.28.

Met vriendelijke groet,
Huub Reuver

[Klaasjan Brand]

Bij de introductie van de 2.6.28-kernel was je misschien opgevallen dat
er voorbereidingen zijn getroffen voor kernel mode-setting in 2.6.29.

Die "voorbereidingen" werken al in Fedora 10 (en zelfs al in F9 als
preview) op een beperkt aantal videokaarten.

Het lijkt erop dat RedHat en Intel in navolging van Microsoft proberen
kerneldrivers voor X compleet op kernel-niveau te laten werken.

Kerneldrivers op kernelnivo. Klinkt als een goed idee. Toch jammer dat
Microsoft er eerst mee moest komen ;)

Overigens blijft de X server gewoon in userspace modus draaien.

- "faster VT-switching"
- "improved suspend and resume support" - "flicker-free boot experience"

- geen crashes meer als je een race conditie triggert terwijl X en de
kernel over een VT ruzieen

- (het belangrijkst voor mij) fatsoenlijk videokaart state herstel na
suspend/resume cycli. Momenteel moet je via een ranzige userspace hack de
videokaart met X en VT switches in een werkende staat terugbrengen na een
resume. Als de kernel weet hoe de videokaart weer in een "beeld aan"
modus gebracht moet worden (en dat inclusief eventueel draaiende 3d
applicaties) is die hack overbodig.

- userproces (X) zit direct in de kernel te wroeten. - idem voor
binary-only kernels

Nu zit X rechtstreeks met PCI apparaten te knoeien. Volgens mij is dat
juist de taak van de kernel.

Verder lijkt mij dit meer in de trent van "dan kunnen we de gebruikers
laten wachten met een leuker plaatje, want 24bpp, i.p.v. in een beperkte
tekstmode.

Dat is een bijwerking, maar het levert voor niet-freaks een meer
"professionele" uitstraling op dus meer Linux acceptatie, dus waarom niet?

Kj

[Sabayon User]

Post by Klaasjan Brand

Bij de introductie van de 2.6.28-kernel was je misschien opgevallen dat
er voorbereidingen zijn getroffen voor kernel mode-setting in 2.6.29.

Die "voorbereidingen" werken al in Fedora 10 (en zelfs al in F9 als
preview) op een beperkt aantal videokaarten.

Welke videokaarten zijn dit?

[Klaasjan Brand]

Post by Sabayon User

Post by Klaasjan Brand

Post by Huub Reuver
Bij de introductie van de 2.6.28-kernel was je misschien opgevallen
dat er voorbereidingen zijn getroffen voor kernel mode-setting in
2.6.29.

Die "voorbereidingen" werken al in Fedora 10 (en zelfs al in F9 als
preview) op een beperkt aantal videokaarten.

Welke videokaarten zijn dit?

In Fedora 10 een aantal ATI kaarten (X800 werkt bij mij, X1nnn zou moeten
werken; de nieuwere radeonhd kaarten zijn kennelijk nog problematisch).
Intel support zal binnenkort wel worden toegevoegd gezien de kernel
ontwikkelingen.

Voordat je een ATI kaart koopt: de nieuwe X drivers zijn nog zeker niet
bugvrij. Sommige OpenGL applicaties zijn in staat je systeem hard op te
hangen. (bug is aangemeld btw).

Kj