Gepubliceerd: Dinsdag 24 juni 2008
154 Linuxprogrammeurs hebben zich uitgesproken tegen closed-source drivers voor Linux. Nvidia is de gebeten hond, maar die piekert er niet over om te open-sourcen.
Toon volledig artikel
niemand verplicht niemand iets, dit is gewoon opruiende taal, waar niemand iets wilt van weten vermoed ik. Er is altijd een vraagstuk geweest of we binary drivers volledig zouden accepteren. En zelf in het linux kamp zijn daar voor en tegenstanders van.
wat nu een hoop devs zeggen is, neen voor ons strookt het niet met wat wij willen bereiken met dit platform. Als je een eerste klas ervaring wilt dan kan je best kiezen voor drivers die open source zijn. Merk op geen Linus Torvalds.
Dat Ati en Intel de 2 andere grote gpu brouwers wel open source support en documentatie geven, is wat de druk op nvidia vergroot. Niet wat er in dit dom statement staat.
Als Linux gebruiker vindt ik twee dingen belangrijk:
- dat zoveel mogelijk software open source is. Dat betekent dat er maatschappelijke controle op techniek is. Het betekent ook dat software zo goed mogelijk om elkaar inspeelt.
- dat ik keuze vrijheid heb. Als het niet anders kan, dan kies ik voor closed source.
Wat ik met dit soort discussies tussen NVIDA en de Stahlmanfundamentalisten vrees, is dat ik als gebruiker klem kom te zitten tussen twee uitersten. Volstrekte nerds zijn zomaar in staat om goed werkende closed source te vervangen door slecht werkende open source.
Graag pragmatisch blijven dus.
Zonder die "Stallmanfundamentalisten" zat jij nu nog op een Windowsbak aan te klungelen.
Graag pragmatisch blijven dus.
Sorry, hierin ga ik in ieder geval niet mee ;-)
Waarom ga je niet mee in pragmatisch blijven? Omdat er gesproken wordt over Stallmanfundamentalisten? Dat is idd niet pragmatisch, maar ik denk dat watdra onderscheid wil maken tussen pragmatische Linux programeurs en non-conformistische programmeurs die per se vinden dat alles ge-GNU-ed moet worden.
Ik ga hier niet in mee, omdat ik vrees dat "Linux" steeds verder volgestouwd wordt met gesloten technologieën.
Voor wie daar geen moeite mee heeft, prima, ieder heeft recht op zijn eigen mening.
Ik vindt het maar een horror scenario en ben van mening, ook duidelijk aan te mogen geven dat ik het er niet mee eens ben.
Ik zal de rollen omdraaien "kom op allemaal, geen gesloten technologie meer gebruiken, weg met nVIDIA, weg met Mono, Moonlight, libdvdcss, win32 codecs, van nu af aan uitsluitend vrije software".
Wat denk je daar van?
:-)
Helemaal mee eens.
Ook pragmatisch gezien spreekt er nog wel het een en ander voor vrije software. Open Source drivers kunnen gewoon met alle distro's meegeleverd worden. Pragmatisch gezien vind ik het een stuk handiger als dingen gelijk 'out of the box' werken in plaats van dat ik eerst nog met de hand op zoek moet naar de juiste drivers.
Pragmatisch lijkt het mij ook veel handiger als het mogelijk is gelijk een bug op te lossen in plaats van dat je moet wachten op de mensen van NV.
Op computers die ik voor werk gebruik is het al helemaal geen probleem meer. Alle software, behalve de zaken waar ik expliciet voor betaal, komen hier strikt uit de standaard repo's. Instabiliteit of een veiligheidsprobleem zouden hier ook volstrek onacceptabel zijn.
Op computers die ik gebruik om, bijvoorbeeld, een beetje te surfen staat dan misschien nog flash of een verdwaalde codec maar ook dat is rap aan het afnemen. Pragmatisch gezien zou het ook hier superhandig zijn als ik alles uit de standaard repo's kon krijgen en ik me geen zorgen hoefde te maken over de legaliteit ergens van.
Dat Ati en Intel de 2 andere grote gpu brouwers wel open source support en documentatie geven
Merk op dat er ook Open SOurce nVidia drivers zijn zonder 3D ondersteuning, net zoals Ati dat heeft. Wil je bv un ubuntu met een Ati kaart ook 3D dan zul je handmatig closed source drivers moeten installeren.
Kortom, als gebruiker heb je de keus voor OSS of CSS.. en daar gaat het in Linux om: "keuze"
Afgezien van de juridische implicaties (binary-only drivers zijn in de ogen van veel prominente kernel developers niet toegestaan) moeten ze vrij weinig. Vanuit een marktwaarde standpunt is het echter heel erg zinnig: je driver gaat er alleen maar in kwaliteit op vooruit zonder dat je er zelf alle moeite in hoeft te steken. Daarnaast werkt je hardware out-of-the-box met iedere Linux distributie.
Broadcom heeft dat "the hard way" moeten leren: de binary driver voor hun Tigon3 gigabit ethernet kaart was zo slecht dat Dave Miller en Jeff Garzik een alternatieve open source driver hebben geschreven (tg3). Die werd in de loop der tijd zo veel beter dan de Broadcom driver (werkte o.a. op hardware die Broadcom niet supporte) dat Broadcom z'n binary-only driver heeft moeten terugtrekken. Uiteindelijk hebben ze het onderhoud van de in-kernel tg3 driver overgenomen. Het grote voordeel voor Broadcom is nu dat de driver out-of-the-box werkt met iedere Linux distributie, zelfs op hardwareconfiguraties die ze met hun binary-only driver nooit hebben getest of hebben kunnen testen.
Ik verwacht overigens dat Nvidia binnen een jaar of twee bijdraait en ook open source drivers gaat leveren. Ze moeten wel nu Intel en AMD/ATI open source drivers leveren: die twee zullen binnen het Linux segment heel wat marktaandeel van Nvidia gaan afsnoepen. Daar kun je wel tegeninbrengen dat de Linux markt te klein is, maar als dat zo is, waarom zouden Intel en AMD/ATI hun drivers wel open sourced hebben?
Erik
Ze hebben groot gelijk
Dat valt te bezien, klanten stemmen met hun voeten.
We maken het de laatste tijd vaker mee dat een bedrijf vasthoudt aan closed source, obscurity en proprietary software. Nvidia zou eens kennis moeten nemen van het debacle met de OV-chipkaart.
Ik zie het als een achterhoede gevecht, je ziet namelijk in de industrie een brede kentering richting Open Source, vanwege de voordelen.
Ik ben een grote voorstander van Open Source, maar ik snap ook dat er bedrijven zijn die met "closed source" hun boterham moeten verdienen. Ik snap het "gehuil" omtrent dit verhaal dus niet echt. Het speelt al jaaaaren en NVidia houdt (mijns inziens terecht) voet bij stuk. Het kan best zijn dat de drivers van NVidia zaken bevatten die ze liever niet open en bloot aan de concurrentie willen geven.
En wat betreft concurrentievervalsing, het is niet zo dat de kaarten van AMD/ATI dusdanig veel slechter zijn dat je persee voor die NVidia kaart moet kiezen als je geen binary-only code wilt draaien op je systeem.
Als een "standaard gebruiker" boeien mij die "binary drivers" niet echt, want zelfs voor FreeBSD leveren ze drivers die voor mij gewoon goed werken. Ik respecteer NVidia dat ze zelfs drivers hebben gebouwd voor een besturingssysteem met dergelijk klein marktaandeel op de desktop.
De toekomst zal waarschijnlijk leren dat niet alles open source kan zijn, een gezonde mix tussen open en closed werkt waarschijnlijk veel beter dan een van de beide extremen (alles closed, waar we vandaan komen; versus alles open, waar zoveel mensen om een mij onduidelijke reden naartoe willen).
Ze hebben groot gelijk. Waarom zou een bedrijf verplicht open source moeten leveren.
Ze zijn niks verplicht. Ik snap niet waar jij dat vandaan haalt, mag een klant niet meer om bepaalde dingen vragen?
is het zover dat een open source community niet meer mag verzoeken om een open source driver? Moeten we nu de politie naar die open source bende sturen?
Ik denk dat er nog heel wat Linux gebruikers met nVidia kaarten bij moeten komen willen ze een echt statement kunnen maken. Voorlopig is het marktaandeel van Linux nog te klein om verandering af te dwingen.
Het marktaandeel Linux is voldoende groot om bij Intel en AMD/ATI open source drivers af te dwingen.
Erik
Het marktaandeel Linux is voldoende groot om bij Intel en AMD/ATI open source drivers af te dwingen.
Dat komt omdat Intel met een schuin oog naar de servermarkt kijkt waar de penetratie van Linux natuurlijk wel relevant is. In de consumentenmarkt waar Nvidia zich op richt (ik heb tenminste nog nooit een server gebouwd met een Nvidia kaartje) is die te verwaarlozen.
Maar goed, wel een kostelijk verhaal weer ;-)
heh neen.
Best raar dat dit zogezegd enkel nvidia is. terwijl ik een hele hoop mensen uit de netwerk stack zie staan. Waar binary drivers ook een degenlijk probleem zijn. Ik ben zeker dat iedereen die tekenende zijn eigen frustraties met verschillende binary drivers had. Dat deze "James Bottomley" focussed op nvidia is wat kleingeestig. De devs die tekende ondertekende *ENKEL* wat er in het statement staat.
We, the undersigned Linux kernel developers, consider any closed-source Linux kernel module or driver to be harmful and undesirable. We have repeatedly found them to be detrimental to Linux users, businesses, and the greater Linux ecosystem. Such modules negate the openness, stability, flexibility, and maintainability of the Linux development model and shut their users off from the expertise of the Linux community. Vendors that provide closed-source kernel modules force their customers to give up key Linux advantages or choose new vendors. Therefore, in order to take full advantage of the cost savings and shared support benefits open source has to offer, we urge vendors to adopt a policy of supporting their customers on Linux with open-source kernel code.
Want ik ben vrij zeker dat kernel meer crashed omdat mensen hun windows drivers via NDISwrapper in de linux kernel proppen.
anyway je kan altijd gaan kijken op kerneloops.org waaraan de kernel crashed.
en bij de laatste release, is de grootste proprietory boosdoener blijkbaar
VNetBridgeDown (P) 241 [external] Bug in the proprietary VMWare drivers
die word enkel voorafgegaan door een fedora-only bug na hibernate...
Voorlopig blijven nVidia kaarten met die gesloten drivers het het beste doen met m'n Ubuntu pc'tje en daar reken ik een producent op af.
probleem is dat we niets kunnen doen wanneer het niet werkt ... zoals met de infamous
nvidia white screen bug
en dan heb je aan de open source kant miljoenen lijnen code die werken en ondersteund en getest wordt door een brede groep mensen.
En aan hun kant 12 devs die op een eiland de binary blob van nvidia brouwen.
Dan is het voor ons wachten tot ze een fix uitbrengen, kan frustrerend zijn ... niet.. Terwijl er een kans bestaat dat er in de groep Xorg devs, mensen zijn die het probleem willen en kunnen oplossen.
nigga please link eens niet naar de closed source driver van ati als je zoiets zegt...
de ati driver gemaakt door amd is nog *steeds* closed source. en zorgt nog *steeds* voor problemen
amd heeft wel documentatie vrijgegeven, en er word gewerkt aan open drivers, die al wel goed werken maar op het moment niet feature complete zijn voor alle kaarten.
xf86-video-ati
xf86-video-radeonhd
dat zijn de open source drivers.
Die eerste zin had je ook wel anders kunnen neerzetten ik ben ook maar een mens en maak fouten!
Die open source driver zit ook vol fouten en draait nog slechter dan de gesloten versie van ati.
Bij bv ubuntu wordt zelfs aangeraden om nvidia kaarten te gaan gebruiken en indien het niet anders kan de closed source ati driver.
true, ik was niet zo voorzichtig als ik had kunnen zijn.
de vraag is een beetje wanneer de informatie die je gebruikt van ubuntu, gepubiceert is. Er is veel veranderd in korte tijd.
Maar ik ga niet onder stoelen of banken steken dat de open source drivers nog niet af zijn. De 3D documentatie is nog niet zoo lang vrij. En behalve voor rs690 kaartjes, of r3xx zal de 3d hardware accelleartie vast nog niet veel doen. Hoewel ze er al in slagen om glxgears e.d. accelerated te laten werken op r5xx iirc. Deze dingen zijn zeker nog niet af.
Maar ati bied nu dus de keuze aan klanten, ofwel gebruik je de ""feature complete"" binary driver, ofwel gebruik je een open source driver die voornamenlijk enkel 2D accelerated doet. Deze dingen zijn zeker nog in opbouw maar zo is linux steeds.. Op zijn minst hebben we de optie om iets te ondernemen. En staan we niet voor een verdomme feit wanneer de binary driver een bepaalde kaart of bepaalde versie van kernel/xorg/mesa/... niet meer ondersteund. En er zijn een hoop situaties waar een open source 2D accelerated driver veel meer waard is dan een 3D binary blob.
Die keuze heb je nu bij ati/amd kaarten en niet bij nvidia.
Je kan bijvoorbeeld de een ati9600pro kaartje dat 4 jaar geleden ofzo nog een zeer behoorlijke kaart was niet meer gebruiken met de laatste binary drivers van amd. Daar komt dan het open source support in actie die u nog steeds alle opties bied. Want er zijn stiekem nog wel wat computers die dat kaartje gebruiken... maar de amd devs willen zich focussen op zeroday support voor de HD3000 reeks ..
Het is dus wat zoeken naar wat de beste oplossing is voor iedereen.
Ten slotte zou ik nogmaals willen opmerken dat het in realiteit helemaal niet op nvidia gefocussed is. Dit is wat wij er hier van aan het maken zijn. Het gaat veeleer over een van de fundamentele linux vraagstukken.
hoe laten we *gesloten bedrijven processen* samenwerken op een open (source) systeem.
Inderdaad, wat heb je aan een open source driver zoals amd/ati uitgeeft die slecht werkt en waarvan de helft is weg gelaten wat wel in een windows driver te vinden is.
Pas als die ontwikkelaars er voor kunnen zorgen dat een amd/ati kaart goed werkt onder linux dan hebben ze een punt om te gaan klagen over nvidia.
Wat is nu belangrijker, dat er een open source driver is of dat de hardware goed werkt?
ati/amd heeft geen open source driver uitgebracht
het heeft docs uitgebracht, en sponsort novell een beetje om een driver te ontwikkelen.
Ook goed maar werkt die open source driver die de ontwikkelaars zelf hebben geschreven aan de hand van de documentatie goed?
Dat is dus mijn punt.
fout uw punt was dat de helft is weggelaten, waar de realiteit is dat de helft nog moet komen.
als je van niets vertrekt en de helft bouwt is het een andere situatie, dan
als je van iets begint en de helft weggooit.
Verder ben ik bekend met de codebases van de verschillende drivers. En durf ik stellen dat je een aantal zaken onderschat.
eerst en vooral: DE 3D DOCUMENTATIE DIE ATI VRIJGAF WAS VRIJGEGEVEN EIND *FEBRUARI* DIT JAAR
dus de open source community heeft er dus nog maar een 4 tal maden beschikking over. En jij klaagt dat de desgevolgende driver niet feature complete is met een software project dat al vele jaren loopt, en code deelt met de windows driver? Moet ik het eens hebben over IT projecten waar de overheid geld in stack een looptijd hadden van jaren en dat minder opleverde?
Nou het mooie is dus ook dat als je het beter kan, je altijd zelf eens mag proberen he. Alle gegevens zijn er.
Maar goed ik weet niet wat je probeert te bewijzen? Dat closed source hardware support zogezegd beter is? Vergeet dat maar, eens je kaart ondersteund wordt door opensource projecten ben bijna steeds beter af.
Overigens de 3D documentatie die is vrijgegeven was enkel voor de r5xx chips in februari. de r6xx 3D programming guide is pas vrijgegeven 11 JUNI ongeveer. Reken eens uit hoe lang ze die gegevens al hebben...
Dus wees gerust je moet nog niet van de daken beginnen roepen dat Open source niet werkt.
Verder zijn er nog verschillende zaken die heel deze situatie bemoeilijken. Zo is er bijvoorbeeld een heel hoge drempel om met dit soort code te beginnen. Je moet enorm veel afweten van enorm veel zaken. X-server architectuur + api, opengl, GPU's , dual display, modesetting, ... En de huidige devs zijn een beetje verzuurd zeker als ik het over airlied heb. (die had overigens de docs al wat langer onder NDA's). Ook is een AMD graphics kaart de volgende niet. Er zijn de verschillende generaties chipsets zoals je mij al r3xx, r5xx, r6xx, rs690 en dergenlijke hebt horen vallen. Ze hebben niet allemaal dezelfde aansluiting, pcie, agp, .. Ze hebben niet allemaal dezelfde outputs. vga, digital, ..
Kortom, deze zaak is nog volop bezig.
En als er geen vooruitgang geboekt word zullen er gerust stappen ondernomen worden. Als je meer wilt weten, volg het dan zelf nauwer op de voet. Want al de gegevens die de linux community heeft zijn ook voor U toegankelijk. (en het is duidelijk dat je ze niet kent)
ps: de reden dat er momenteel 2 driver projecten zijn laat al zien hoe stroef het loopt. Maar dat is nu eenmaal de sterkte van het open source proces. Volg het maar eens op de voet je zal versteld staan.
verder zijn er nog al open source ati driver projecten geweest, niet in het minst de poging van jerome glisse met avivo.
je kan met de opensource code al compiz draaien op een aantal kaarten... iets waar de ati-binary driver *MEER* dan een jaar over gedaan heeft.
Sommige oudere NVidia & ATi hardware werkt al met open source drivers, maar ik denk dat je voorlopig als je echt geen binary driver wilt gebruiken het beste een Intel kunt kopen. Nadeel is de 3D performance, en dat je dan weer wat minder keus hebt qua andere hardware (AFAIK altijd een Intel processor). Anders kun je enigzins oude ATi kopen want die worden het eerst ondersteunt.
wederom fout.
er is geen enkele nvidia kaart die 3D ondersteunt in opensource nv driver is enkel 2D, en nouveau zal in de voorziene toekomst helemaal niets doen.
voor ati was er inderdaad al voor de r3xx in xf86-ati al accelerated 3D support.
De performance daarvan is behoorlijk.
trouwens aan die support voor r3xx (en voor de normale mensen dat zijn alle kaarten in de 9000 range (9200, 9600, ..) iirc (maar product naming en chip generatie is nog zo'n onduidelijk ding soms ;-)).
daar is ook veel rond te doen geweest. ATI leverde de specificaties onder NDA aan slechts enkele devs; beweerde later dat het helemaal opensource, was, kwam daar dan op terug, ... kortom een heel verhaal.
waar we ons hier maar niet mee bezighouden.
In de nabije toekomst zal de closed source ati driver nog steeds de te verkiezen optie zijn als je om een of andere rare reden wilt gamen op linux.
Maar out of de box support, voor dingen zoals compiz, en een gewone desktop ervaring zullen op afzienbare tijd geleverd worden door de open source versies. Die hopenlijk stabieler zijn met iets minder features.
Net zoals niet iedereen op windows de laatste catalyst gaat downloaden, zal de standaard versie op linux waarschijnlijk open zijn.
Dit is wat nu beoogt wordt. Dat is de voorlopige oplossing hoe ze opensource en een bedrijf als amd willen laten werken met elkaar. We zien wel wat het word.
Volgens mij zijn er wel sommige NVidia kaarten die 3D ondersteunen middels FOSS driver, maar het betreft erg oude modellen.
ahja "volgens mij"
leuk dat je dat denkt, maar het is niet zo.
http://nouveau.freedesktop.org/wiki/FrontPage#Status
"Any 3D support is still limited for extremely lucky developers"
nv driver
http://xorg.freedesktop.org/wiki/nv
"At present the nv driver has no 3D acceleration."
(en verwijst verder door naar nouveau)
Het is niet zo, en dat is de realiteit. Nouveau driver zit al verschillende jaren op dit punt. Dus je mag gerust stoppen met de FUD. Er is geen enkele nvidia kaart die open source ondersteund wordt met 3D accelerated support.
echt niet, ik zou vast de memo gekregen hebben mocht dat veranderd zijn. Maar kom ik ben mensenlijk misschien heb ik het gemist. Link me eens naar die machische driver voor die oude kaarten ?
FUD? Nounou, alsof ik een of andere marketing guru van NVidia ben zeg. Je hebt gewoon gelijk, en dat heb je dmv bronnen nu bewezen. Klaar.
Het was een denkfout die in verband staat met het feit dat NVidia een aantal oudere kaarten heeft dan ATI terwijl ATI pas later met Linux ondersteuning kwam. Vervolgens heb ik een tijdje onderzoek gedaan naar een open source driver voor mijn toenmalige ATI kaartje (R3x0). Ik had dus daarvoor wel een werkende NVidia met 3D, maar vervolgens geen ATI met 3D. Vandaar.
O ja? Bij mij juist niet. Ik heb de nVidia driver er weer afgeknikkerd omdat ik de schermresolutie dan niet hoger kan instellen dan 50Hz. En vooral 's avonds is dat niet prettig.
50 hz, hmmmmmm ligt dat niet aan de keuze beeldscherm, anders kun je met gtf je modeline zelf maken....
usage: gtf x y refresh [-v|--verbose] [-f|--fbmode] [-x|--xorgmode]
x : the desired horizontal resolution (required)
y : the desired vertical resolution (required)
refresh : the desired refresh rate (required)
-v|--verbose : enable verbose printouts (traces each step of the computation)
-f|--fbmode : output an fbset(8)-style mode description
-x|--xorgmode : output an Xorg-style mode description (this is the default
if no mode description is requested)
De ontwikkeling van de Nouveau Nvidia driver gaat erg goed vooruit. Ongeloofelijk hoe die mensen zonder kennis of info over de chip een driver kunnen ontwikkelen die werkt. De 2d driver werkt ondertussen beter de de 2d driver die Nvidia zelf uitbrengt, aan de 3d driver wordt hard gewerkt en hier is het voorlopige resultaat:
http://nl.youtube.com/watch?v=-sLgtwEAgLo
"Nvidia ondersteunt Linux en de Linux-community, en krijgt al tijden complimenten voor de kwaliteit van zijn driver," laat de chipfabrikant weten. "Nvidia heeft de driver als binary-only uitgebracht, omdat we graag ons intellectuele eigendom willen beschermen."
Wel jammer dat Nvidia zo reageert maar het is hun goed recht natuurlijk. Aan de andere kant zouden de drivers van Nvidia een enorme stap voorwaarts hebben gemaakt als ze wel open-source waren. Nvidia is imho nog altijd de beste videokaart voor Linux juist vanwege hun goede drivers. Maar het kan nog altijd beter. Hun windows-drivers hebben bijv. meer opties m.b.t. meerdere monitoren met de kanttekening dat ik dit alweer een jaar terug heb getest...
Ondanks dat Ati tegenwoordig ook drivers voor Linux levert zijn de generic-drivers voor Ati standaard meegeleverd in Linux duidelijk beter... Wel is het goed om te constateren dat Linux steeds serieuzer wordt genomen door fabrikanten.
Correct me if I wrong: De laatste Intel integrated videokaarten hebben open-source drivers. Intel is dan ook lekker aan de weg aan het timmeren met relatief krachtige onboard videokaarten...
Op mijn huidige NVidea kaart heb ik geen problemen met het draaien, met de bin-only driver.
Verder vind ik dit soort bin-only praktijken pure concurrentievervalsing, omdat het niet mogelijk is deze grafische kaart te gebruiken op alternatieve processoren of nog belangrijker dat de mogelijkheid om met alternatieve processoren de laatste hardware te kunnen gebruiken of om voor alternatieve OS-sen een driver te maken.
De specificatie van een grafische kaart met alle aansturingsmogelijkheden is geen interlectueel eigendom, maar iets waar je als consument gewoon recht op hebt.
Verder is het bin-only denken een pure restant van het achterhaalde bussiness model, waar ook Microsoft Windows deel vanuit maakt en wat het steeds meer heeft gehad.
Wat ik nog steeds vreemd vind (en niet alleen van Linux) is dat de kernel niet dermate afgeschermd is dat een probleem met een driver geen crash kan veroorzaken. Dan maakt het namelijk ook geen klap meer uit of een driver open of closed source is, want dat is geisoleerd.
het probleem is dat het om kernel drivers gaat, zonder toegang to de kernel kunnen die apparaten niks. En dan kan het zijn dat ie crasht...
het probleem is dat het om kernel drivers gaat
Exact wat ik bedoel... ik verbaas me erover dat dit nog nodig is vandaag de dag. Dat dit kernel drivers zijn betekent dat het grafische subsysteem als onderdeel van de kernel wortd gezien. Niet gehinderd door enige kennis op dit niveau (OS hacken op de uni is al weer een kleine 15 jaar geleden) lijkt me dat eigenlijk I/O en onder het idee "all input is evil" iets wat je buiten de kernel moet houden. Ik vermoed dat de reden performance is ("anders is het grafische systeem niet snel genoeg"), maar vanwege Moore's law zou ik zeggen dat we dat station zo onderhand gepasseerd zouden moeten zijn. Maar goed, ik zal wel iets essentieels missen.
[quote][Maar goed, ik zal wel iets essentieels missen./quote]
Je mist het essentiele feit dat microkernels ondertussen een allang gepasseerd station zijn. Ooit leuk in academische kringen, in de praktijk wordt het nauwelijks nog gebruikt. Ook met een microkernel kan je de boel de fout in laten gaan: je zou de IO door de microkernel kunnen laten doen en de rest door de grafische server, maar als de grafische server de microkernel een verkeerde IO opdracht geeft hangt de hardware alsnog. Wat dat betreft is er geen verschil met monolitische kernels.
Erik
Je mist het essentiele feit dat microkernels ondertussen een allang gepasseerd station zijn.
Dat is geen feit...
Ooit leuk in academische kringen, in de praktijk wordt het nauwelijks nog gebruikt.
Wil je deze onzin in het vervolg voor je houden?
Hypervisors ('virtual machines' zoals VMware!!!), Minix, L4, QNX (!!!), Mach, MacOS, TRON (!!!), Symbian (!!!) EROS & opvolgers (capability-based security research OS), Exokernel, real-time kernels (RTOS), en allerlei hybrids zoals Windows NT en MacOSX... allerlei embedded hardware (en SoC) draait nog steeds op embedded kernels en dat zal voorlopig zo blijven
Die met de uitroeptekentjes erachter zou ik geen 'gepsseerd station' of 'academisch project' durven te noemen.
Ook met een microkernel kan je de boel de fout in laten gaan: je zou de IO door de microkernel kunnen laten doen en de rest door de grafische server, maar als de grafische server de microkernel een verkeerde IO opdracht geeft hangt de hardware alsnog. Wat dat betreft is er geen verschil met monolitische kernels.
Nogal wiedes, maar het doel is dat bij een fout niet het hele systeem op z'n gat valt, en dat je de dat onderdeel kunt restarten. Bestwel handig op een kerncentrale of lantaarnpaal, vind je niet?
Een hypervisor/virtual machine is wat anders dan een microkernel. Een hypervisor creeert één of meerdere virtuele machines. Binnen een virtual machine draait dan weer een volledig besturingssysteem dat ook direct op de kale hardware zou kunnen draaien. Als je meerdere besturingssystemen tegelijkertijd draait schermt de hypervisor die van elkaar af. De afzonderlijke besturingssystemen hebben elkaar niet nodig om te draaien.
Een microkernel met z'n servers is in z'n totaliteit een volledig besturings. Er zijn servers voor het filesystem, netwerk code, de verschillende drivers, etc. die niet in de kernel draaien. Applicaties draaien naast die servers. Een server op zich is geen volledig besturingssysteem, het is gespecialiseerd in één ding en kan zonder de microkernel niet draaien.
Voor gespecialiseerde applicaties (het voorbeeld van de kerncentrale dat je gaf) worden microkernels nog wel gebruikt, maar voor algemeen dagelijks gebruik als PC (waar het in deze thread om gaat) niet meer. Windows NT is ooit z'n leven begonnen als microkernel, maar de huidige incarnaties zijn dat allang niet meer. Om MacOS X een microkernel te noemen vind ik wat ver gaan: het gebruikt wel Mach, maar net zoals de eerste Mach implementaties samen met een BSD kernel in dezelfde address space.
Om even terug te komen op de verkeerde IOs: nee, een microkernel helpt niet tegen verkeerde IOs. Als een server de kernel een IO laat doen die via DMA de kernel zelf overschrijft dan is er niets meer om die server te herstarten. Het enige wat hiertegen helpt is een IOMMU maar dat is een stuk hardware en geen onderdeel van een kernel.
Erik
Voor embedded toepassingen worden RTOS en microkernels nog steeds toegepast. Ik heb legio voorbeelden genoemt van microkernels alsmede hybrids. En ja, de originele Windows NT kernel geprogrammeerd door DEC was inderdaad een microkernel. Microkernels mogen dan niet gebruikt worden in desktops omdat daar Windows/Linux/MacOSX op draait, ze worden opzeker op allerlei embedded fronten gebruikt. En dat zie je niet omdat 't embedded toepassingen zijn. Het is dus pertinente onzin dat microkernels 'een gepasseerd station' zijn of 'enkel in academische kringen' worden gebruikt. Het zou mij niet verbazen als allerlei hardware in een desktop of server een microkernel draait.
De komst van DRI2 (reeds in Fedora geïmplementeerd bijwijze van test) maakt de noodzaak van de binary driver van nvidia voor veel desktop users stukken minder.
In een telefonisch interview met Cnet windt voorzitter van technisch advies James Bottomley er geen doekjes om: "Nvidia's gesloten module is een van de grootste oorzaken van het crashen van de kernel," zo laat hij weten. "En dat straalt af op Linux."
Was het ook niet zo dat bij Vista zo'n 28,8% van de crashes werd veroorzaakt door Nvidia drivers?
webwereld.nl/ar...ta-crashes.html
Ik zie niet direct in waarom NVIDIA de source niet beschikbaar zou stellen? Het is niet zo dat ze daardoor inkomsten mislopen oid, aangezien je nog steeds de hardware zult moeten aanschaffen om gebruik te kunnen maken van het product.
Zoals al eerder opgemerkt, het komt de kwailteit alleen maar ten goede.
Alleen vanuit een concurrentie oogpunt kan ik het begrijpen, ze willen niet dat AMD/ATI of Intel aan de haal gaat met hun driver model, maar dat lijkt me onwaarschijnlijk, aangezien de kaarten toch behoorlijk anders opgebouwd zijn en het blijkbaar (gezien de onofficiele driver projecten) mogelijk is om dit toch grotendeels te reverse engineeren.
Bovendien heb je kans dat na verloop van tijd je ondersteuningskosten omlaag gaan aangezien je betere drivers hebt die op meerdere platforms werken.
Mijns inziens dus voornamelijk voordelen. Een potentieel nadeel zou kunnen zijn dat mensen die onofficiele/aangepaste drivers gebruiken toch support willen van Nvidia en dat dat extra tijd kost aan de telefoon/email om uit te leggen dat niet elke variant van een open source driver ondersteund kan worden.
[offtopic]
Conspiracy Theory: Nvidia maakt gebruik van het ATI driver model en wil niet dat men daarachter komt, dus houdt zijn source closed... ;)
[/offtopic]
nvidia staat bekend om dat ze optimalisaties uitvoeren met hun drivers die ervoor zorgen dat bepaalde games onder nvidia beter presteren dan onder ati indien het gelijknamige kaarten zijn.
Ik denk dat ze die geheimen niet graag aan de concurrentie bekend maken.
Dat mogen ze dan wel willen. Deze extreme optimalisaties heb ik niet nodig onder Linux. Als NVidia open source drivers maakt die de kaarten naar behoren laat werken ben ik tevreden. Speciale optimalisatie voor spelen is mijninziens echt niet nodig. En als ze dat niet prijs willen geven kan je deze lui nog een closed source driver aanbieden.
"Wij, de ondergetekende Linuxontwikkelaars, beschouwen elke closed-source Linux module of driver als schadelijk en ongewenst."
Ik begrijp hun probleem niet. Als die *paaar* programmeurs dat zo belangrijk vinden dan HOEVEN ze die drivers niet te gebruiken! Het is niet verplicht of zo. Gebruik lekker de open source projecten en werk daar aan mee of zo?
Mijn ubuntu draait prima met die closed src drivers. En daar gaat het mij om. Laat nvidia lekker met rust dus. Als er een paar closed source drivers nodig zijn om linux verder van de grond te krijgen, so be it.
Ook kan ik prima accepteren dat nvidia daar algorithmes in heeft zitten die ze liever voor zichzelf houden. Ze zullen zich daar vast wel mee *onderscheiden* van de concurrentie.
Zou ik ook doen in hun geval.
Die paar programmeurs zijn wel precies die mensen die de kernel die jij gebruikt helpen ontwikkelen en debuggen. Er zitten grote namen tussen als Alan Cox (SMP, IDE, SATA, serial), Jens Axboe (block subsystem), James Bottomley (SCSI), Neil Brown (MD RAID), Thomas Gleixner (tickless kernels), Ted T'so (ext2, ext3, ext4), David Woodhouse (MTD, JFFS2), Ralf Baechle (MIPS), Russell King (ARM), etc.
Het probleem is ook niet dat zij een closed-source driver gebruiken, integendeel dat doen ze niet. Waar ze wel dagelijks mee te maken hebben zijn bug reports die lijken te zijn veroorzaakt door het gedeelte van de kernel waar zij verantwoordelijk voor zijn, maar die bij nadere inspectie worden veroorzaakt door een closed-source driver. Ik kan me goed voorstellen dat ze dat goed zat worden.
Ik wil je ook aanraden om het Kernel Driver Statement eens te lezen, dan zul je zien dat het om meer gaat dan alleen onderhoud. Het belangrijkste punt is dat open source een kwestie is van geven en nemen: ik gebruik een open source kernel en in ruil daarvoor help ik die kernel te verbeteren. Fabrikanten met closed source drivers zijn net parasieten: ze nemen alleen maar geven nooit.
Dat je Ubuntu prima draait met closed source drivers is fijn voor je. Ik hoop alleen dat je niet komt klagen op Ubuntu forums of de Linux kernel mailing list als ze dat niet doen want dan wordt je keihard uitgelachen. De enige die je nog kan helpen met problemen met je closed source driver is de fabrikant zelf en als die er geen zin in heeft of je hardware te oud vindt blijf je met de problemen zitten. Alleen met een open source driver kan iedereen die snapt hoe de kernel werkt je helpen.
Die zogenaamd geheime algoritmes van Nvidia zullen ook wel meevallen, hoe je 3D hardware maken is al jaren bekend. Hoe ze dat precies in silicium gieten is mogen ze wel voor zich houden, maar welke waarden je naar welk registertje moet schrijven om de boel aan de praat te krijgen is nou niet zo bijzonder dat je dat speciaal hoeft te beschermen.
Erik
Fabrikanten met closed source drivers zijn net parasieten: ze nemen alleen maar geven nooit.
Ik vind je commentaar te fel. Ze opereren binnen de regels en het is hun goed recht om hun software close-source te houden. Indien close-source niet gewenst is, misschien moeten dan de regels worden aangepast dat je het doodgewoon niet toe laat. Het zou Nvidia wel sieren dat wanneer hun drivers daadwerkelijk zulke problemen oplevert, dat ze tegen betaling het lijstje namen die jij noemde inhuren. De mooiste oplossing is gewoon open-source drivers. Dat ben ik zeker met je eens. Waarom moeilijk doen als het gemakkelijk kan...
Of binnen de regels opereren en of het hun goed recht is, daar zijn de meningen over verdeeld.
Feit is dat Alan Cox, iemand met een enorm aandeel source code in de kernel, keer op keer in het openbaar blijft verklaren dat closed source driver geen goed recht zijn en dat zijn code daar zeker niet voor mag worden gebruikt. Hij doet dat met de reden dat als het ooit nog eens tot een rechtzaak komt, hij de rechtbank kan wijzen op zijn intenties (als een onderdeel in een contract vaag is dan zijn de intenties van belang) en dat de beklaagden zich niet kunnen beroepen dat ze niet wisten van zijn visie.
Feit is ook dat Harald Welte van het GPL violations project rechtzaken blijft winnen en daarmee closed source projecten open forceert. Closed source drivers zijn volgens het Duitse recht zeker niet toegestaan en gezien het feit dat TomTom buiten de rechtzaal om met GPL violations een schikking heeft kunnen treffen laat dat zien dat het in Nederland waarschijnlijk ook niet zal zijn toegestaan.
Ik ben het met de GPL interpretaties van Alan Cox en Harald Welte eens: closed source drivers zijn niet toegestaan. In dat licht blijf ik bij mijn standpunt: een fabrikant met een closed source driver is een parasiet, het is immers onmogelijk een driver te maken zonder gebruik te maken van GPL'ed open source gedeeltes van de kernel.
Erik
Of binnen de regels opereren en of het hun goed recht is, daar zijn de meningen over verdeeld.
Oh??? Da's nieuw voor mij. Vertel eens: wie is van mening dat het onwettig is als je de sources van je eigen software niet wenst te publiceren?
Sommige OSS-aanhangers doen de OSS wereld net voorkomen als een enge sekte. Daarmee doe je de community op de lange termijn geen plezier. De OSS-gemeenschap zal ook flexibiliteit moeten betrachten in het business model wil men uiteindelijk overleven. Het is geen alles of niets...
Vertel eens: wie is van mening dat het onwettig is als je de sources van je eigen software niet wenst te publiceren?
Je haalt wat dingen door elkaar, we hebben het hier specifiek over broncode voor kernel drivers, niet over broncode voor willekeurige programma's.
Makers van closed source software zijn vrij om *eigen* broncode niet te publiceren, dat is ook niet wat er betwist wordt. Probleem bij Linux kernel drivers is dat die drivers alleen gemaakt kunnen worden door stukken van de kernel te gebruiken die alleen beschikbaar zijn onder GPLv2 licentie waardoor die driver niet alleen meer *eigen* broncode is. Daardoor worden die drivers afgeleide van de kernel en moeten ze aan de licentie voldoen. Toevallig zegt die licentie in het kort dat je je binary-only driver alleen mag vrijgeven als je ook de broncode vrijgeeft. Als je aan die licentie niet voldoet vervalt daarmee ook automatisch je recht om de binary-only driver te distribueren.
Nogmaals, de meningen over de bovenstaande interpretatie zijn verdeeld, maar het is niet de mening van Linus Torvalds die doorslaggevend is. Er zijn voldoende andere kernel developers met substantiele aandelen in de kernel code die het niet met Linus eens zijn (Alan Cox, Harald Welte, zie vorige post) die de bovenstaande interpretatie wel aanhangen.
Het is geen alles of niets...
Het is wel alles of niets. Als je graag GPL'ed software wilt gebruiken in je product dan zit er niets anders op dan de licentie te volgen. Of zoals een Duitse rechter recent opmerkte in een zaak van Harald Welte tegen Skype:
If a publisher wants to publish a book of an author that wants his book only to be published in a green envelope, then that might seem odd to you, but still you will have to do it as long as you want to publish the book and have no other agreement in place".
(zie Harald Welte's blog).
Als je graag GPL'ed open source software in je product wilt gebruiken is er slechts één manier en dat is door aan de licentie te voldoen. Dan kun je mopperen dat de OSS community "flexibiliteit in het business model moet betrachten", maar dat hoeft de OSS community helemaal niet te doen: niemand dwingt jou namelijk om OSS software in je product te gebruiken, het staat je vrij om de functionaliteit elders in te kopen of zelf te ontwikkelen. Het niet gebruiken van OSS in je product kost je geld, tijd of beide, maar dat is dan je eigen keuze geweest. Het is dan onzin om het business model van de OSS community de schuld te geven van het falen van je eigen business model.
Erik
Als je graag GPL'ed open source software in je product wilt gebruiken...
Je hele vlammende betoog hangt op dit punt. Gebruikt Nvidia GPL'ed open source software in haar product? Als Nvidia dat doet dan kan ik je gedachtegang een beetje volgen.
Ik heb namelijk nog nooit gehoord dat Nvidia GPL code gebruikt in of rond haar videokaarten. Vanuit die gedachte vind ik het raar om Nvidia te pushen om open source te leveren. We mogen al lang blij zijn dat ze in elk geval iets doen. Er zijn genoeg bedrijven die niet eens reageren op een verzoek om drivers te maken of info beschikbaar te stellen. Nu hebben we er eindelijk eentje die er tijd in investeert, en dan gaan we hem aanvallen.
Het leveren van GPL code is geen plicht in wettelijke zin, alleen in een morele. Er zijn miljoenen mensen die open source gebruiken zonder er iets voor terug te geven. Gaan we die straks ook aanvallen? Zijn dat binnenkort ook parasieten omdat ze geen bug-reports indienen of support leveren op forums?
Ik zie dat ik je laatste reactie niet goed genoeg heb gelezen. My bad :(
Ik ben het nog steeds niet helemaal met je eens, maar ik kan je gedachtegang volgen. Ik vind de stelling dat je parasiteert op GPL, als je code moet gebruiken uit de kernel om je driver werkend te krijgen, extreem ver gezocht. Maar goed, jou mening.
Die paar programmeurs zijn wel precies die mensen die de kernel die jij gebruikt helpen ontwikkelen en debuggen. Er zitten grote namen tussen als Alan Cox (SMP, IDE, SATA, serial), Jens Axboe (block subsystem), James Bottomley (SCSI), Neil Brown (MD RAID), Thomas Gleixner (tickless kernels), Ted T'so (ext2, ext3, ext4), David Woodhouse (MTD, JFFS2), Ralf Baechle (MIPS), Russell King (ARM), etc.
Dat klinkt leuk, maar de belangrijkste missen ze dus. Er is dus geen support van Linus Torvalds op dit moment.
Het probleem is ook niet dat zij een closed-source driver gebruiken, integendeel dat doen ze niet. Waar ze wel dagelijks mee te maken hebben zijn bug reports die lijken te zijn veroorzaakt door het gedeelte van de kernel waar zij verantwoordelijk voor zijn, maar die bij nadere inspectie worden veroorzaakt door een closed-source driver. Ik kan me goed voorstellen dat ze dat goed zat worden.
Ik kan dit begrijpen, maar in mijn opinie is dat een onderdeel van hun hobby/vak. Dat moeten ze maar accepteren.
Ik wil je ook aanraden om het Kernel Driver Statement eens te lezen, dan zul je zien dat het om meer gaat dan alleen onderhoud. Het belangrijkste punt is dat open source een kwestie is van geven en nemen: ik gebruik een open source kernel en in ruil daarvoor help ik die kernel te verbeteren. Fabrikanten met closed source drivers zijn net parasieten: ze nemen alleen maar geven nooit.
Dat zou ik zo niet noemen. Nvidia hoeft geen driver voor Linux te leveren. Men moet blij zij n dat men als bedrijf überhaupt er geld en tijd in wilt steken.
Die zogenaamd geheime algoritmes van Nvidia zullen ook wel meevallen, hoe je 3D hardware maken is al jaren bekend. Hoe ze dat precies in silicium gieten is mogen ze wel voor zich houden, maar welke waarden je naar welk registertje moet schrijven om de boel aan de praat te krijgen is nou niet zo bijzonder dat je dat speciaal hoeft te beschermen.
Misschien mogen ze nog geen eens iets bekend maken. Ze zullen heus wel nog iets met patenten hebben die hiermee te maken hebben.
Dus wanneer 140 (belangrijke) programmeurs het samen ergens over eens zijn dan is dat maar zo, maar als Torvalds er bij staat dan heeft het ineens een gigantische betekenis? Torvalds heeft zich hier al eerder over uitgesproken. Of hij nou wel of niet op deze petitie staat doet er niet zo toe. Die man heeft z'n handen al vol met vanalles...
Klopt. Maar hij is wel DE aanspreekpunt omtrent Linux. Zijn mening is dan ook van dus danig impact dat het effect heeft. Het feit dat hij er niet bij staat geeft een ander signaal af aan bedrijven.
Misschien wil hij zich niet bemoeien met dit soort zaken, of met petities in het algemeen. Misschien is hij afwezig. Wie weet.
Er staan echt grote namen in qua developers. Ik ben het met je eens dat wellicht sommige bedrijven enkel kijken of Torvalds er tussen staat, maar dat is hun kortzichtigheid. Bovendien is het niet enkel een statement naar die bedrijven. Het is een statement van Linux kernel developers aan de wereld. Dat NVidia reageert betekent dat ze zich aangesproken voelen, en da's wat Doubleday bedoelde met De Linuxcommunity vangt dus bot bij Nvidia. Je had toch niet verwacht dat bijvoorbeeld NVidia ineens positief zou reageren?
Overigens voert OpenBSD al jaren actie voor soortgelijke problemen mbt hardware & drivers. Vaak is een van de laatste redmiddelen reverse engineeren...
Ik vind het volkomen terecht dat die ontwikkelaars aanstippen dat ze het liever open source zouden willen zien. Ik vind het ook absoluut het goed recht van Nvidia om dat te weigeren, maar of het slim is en of ik het er mee eens ben is een tweede.
Ik vind zelf het grootste nadeel van die binary blobs dat ze niet (makkelijk) in de repository meegenomen kunnen worden. Ik draai zelf Nvidia onder Debian, en af en toe stopt na een dist-upgrade X met werken (ok, ik draai ook unstable, maar goed). Moet je weer hopen dat een reinstall werkt en/of dat er inmiddels een nieuwere versie is. Als ze in de repo mee zouden komen zou dat natuurlijk min of meer synchroon lopen.
Overigens is Debian natuurlijk ook rete-principieel met dat soort dingen en kun je vast wel zo'n binary in een repo proppen. Maar alleen al het iedere keer akkoord gaan met de licentievoorwaarden (hoezo? Ik heb toch hardware van jullie gekocht?!?) is gewoon al irritant.
Ok, ik draai ook unstable, maar goed
Ik ben blij dat je het zelf al aangeeft, Je kiest de bleeding edge. Je moet je dus niet verbazen dat je je zo nu en dan eens snijd. ;) Ik denk dat dit ook minder te maken heeft met open/gesloten. In unstable kom je soms dingen tegen die nog niet bij zijn. Bij een videokaart valt dat alleen zo verschrikkelijk op.
"We verwachten niet van de Linuxontwikkelaars dat ze onze bugs oplossen. Wij ondersteunen de gebruikers zelf."
Behalve natuurlijk als je een laptop hebt van aziatische houtje-touwtje fabrikanten als Acer e.d. want dan blaat Nvidia vrolijk dat je voor ondersteuning bij de fabrikant moet zijn. En daar loop je maar al te vaak vast.
Om te kunnen reageren, dient u ingelogd te zijn.
2 jaar geleden: 13 februari 2010
3 jaar geleden: 13 februari 2009
4 jaar geleden: 13 februari 2008
5 jaar geleden: 13 februari 2007
14 jaar geleden: 13 februari 1998
IDG Nederland is uitgever van: AppFish
, CIO, Computer!Totaal, Computerworld, ITworld, Jobworld, MacWorld, RAW fotomagazine, TechFish, Tips & Trucs, Webwereld en Zoom.nlMeer informatie: IDG Nederland, IDG.com, Privacy-statement, Cookie-statement Hosting by Terremark.
