Waarom niet standaard binary drivers onder Linux?

zaterdag 8 oktober 2005 23:51

💩

Omdat binary drivers bijzonder klote zijn voor een OS als Linux dat enorm cross-platform is. Veel hardware is op zich niet platform-afhankelijk, maar als je met binary drivers gaat kutten dus opeens wel omdat je dan een x86 driver hebt voor (bijvoorbeeld) een netwerkkaart die je in een ppc wilt gebruiken. Dat gaat dan niet werken.

All my posts are provided as-is. They come with NO WARRANTY at all.

Acties:

Cyphax

Moderator LNX

Nou, drivers worden toch in binaire vorm uitgegeven? ATI doet dat, nVidia doet dat... daar zijn ze niet bang voor (maar het kost ze wellicht meer dan het op lijkt te leveren). Ik vind dat persoonlijk wel best, dat ze geen geheimen prijs willen geven snap ik.
Het is ontzettend veel werk om voor al die verschillende systemen packages te maken. Toch komt het geregeld voor bij wat grotere projecten (denk aan Gaim bijv.) dat er verschillende packages zijn in verschillende formaten. Maar als ik zelf een projectje op zou zetten zou ik slechts de source uitgeven. Waarom? Zorg jij zelf maar dat het gecompileerd wordt, 't is jouw systeem.

En dan zijn er zat vrijwilligers die de moeite nemen om voor jouw distro een pakketje te bakken.
Windowssystemen zijn doorgaans veel meer identiek aan elkaar terwijl er geen 2 linuxen gelijk zijn (dat is natuurlijk ook weer overdreven maar het idee is hetzelfde)

Dat program files alternatief is er in principe, alleen iets minder eensgezind. De meeste programma's komen in /usr/local of /usr/share, sommigen in /usr/lib zelfs, of /opt/...
Dat is een punt dat zeker verbeterd kan worden, dat ben ik met je eens.
En je geeft zelf ook een oplossing: --prefix

[ Voor 14% gewijzigd door Cyphax op 08-10-2005 23:54 ]

Saved by the buoyancy of citrus

zaterdag 8 oktober 2005 23:58

Acties:

Palomar

Nouja, zoveel verschillende platformen zijn er ook weer niet. En het grootste gedeelte van de (beginnende) gebruikers heeft toch x86, dus daar kan iig wel een standaard voor worden gemaakt en dan kan de rest wel gaan aanklooien met source codes.
Ik erger me zelf ook telkens weer aan dit soort dingen bij Linux. Voor de gewone gebruiker wordt het allemaal zo onnodig moeilijk gehouden. Ik ben sinds kort redelijk intensief bezig met Ubuntu en dan kun je dus met apt-get allerlei kant en klaar spul downloaden. Dat werkt prima. Maar zogauw ik iets wil installeren wat niet op de repositories staat is er vaak alleen een source code van te downloaden. Nu ben ik best ervaren op computergebied en ook bereid om dingen te leren, maar het compilen en installeren en weet ik veel allemaal nog meer met die source bestanden dat lukt me 5 op de 10 keer gewoon niet. Aldoor weer errors waar ik niks van begrijp etc.

En als een standaard voor (x86) binaries echt technisch niet mogelijk is (zou niet weten waarom niet, maargoed) dan is er toch ook wel iets als een installer te maken voor source bestanden. Iet swaarmee dit proces automatisch wordt uitgevoerd zonder in de console bezig te moeten gaan?

[ Voor 3% gewijzigd door Palomar op 09-10-2005 00:00 ]

zondag 9 oktober 2005 00:17

Acties:

Cyphax

Moderator LNX

Palomar schreef op zaterdag 08 oktober 2005 @ 23:58:
Nouja, zoveel verschillende platformen zijn er ook weer niet. En het grootste gedeelte van de (beginnende) gebruikers heeft toch x86, dus daar kan iig wel een standaard voor worden gemaakt en dan kan de rest wel gaan aanklooien met source codes.
Ik erger me zelf ook telkens weer aan dit soort dingen bij Linux. Voor de gewone gebruiker wordt het allemaal zo onnodig moeilijk gehouden. Ik ben sinds kort redelijk intensief bezig met Ubuntu en dan kun je dus met apt-get allerlei kant en klaar spul downloaden. Dat werkt prima. Maar zogauw ik iets wil installeren wat niet op de repositories staat is er vaak alleen een source code van te downloaden. Nu ben ik best ervaren op computergebied en ook bereid om dingen te leren, maar het compilen en installeren en weet ik veel allemaal nog meer met die source bestanden dat lukt me 5 op de 10 keer gewoon niet. Aldoor weer errors waar ik niks van begrijp etc.

En als een standaard voor (x86) binaries echt technisch niet mogelijk is (zou niet weten waarom niet, maargoed) dan is er toch ook wel iets als een installer te maken voor source bestanden. Iet swaarmee dit proces automatisch wordt uitgevoerd zonder in de console bezig te moeten gaan?

Het probleem is echt niet dat die standaarden voor binaries er niet zijn (ELF, om maar wat te roepen) en er zijn ook zat programma's met installatie (Firefox bijvoorbeeld). Packagemanagement is er gewoon voor bedoeld om dit op te vangen. Zoveel verschillende Linux systemen zijn er WEL. Ik heb een heel andere configuratie dan jij (geen Ubuntu). We hebben ongetwijfeld veel verschillende versies van libraries. Nou maak ik een binary van mijn superheftige programma met library A versie Y. Die is al 3 weken oud en dat vind jij veel te oud en bleeding edge versie Z heb jij draaien. Maar daar zitten een paar compatibiliteitsissues in, er zijn wat calls veranderd! Shit, mijn programmatje zal niet werken bij jou... wat heb je nog aan die binary dan boven de source? Het zal in beide gevallen niet werken, met het verschil dat je het niet merkt bij het starten van het programma, maar het compilen ervan.
Ik heb dit laatst nog met aMule meegemaakt trouwens. Een minor versie hoger van, ik meen, wxGTK en heel het ding start niet. Vanwege deze opzet werkt het niet zoals bij Windows wel.

[ Voor 9% gewijzigd door Cyphax op 09-10-2005 00:20 ]

Saved by the buoyancy of citrus

zondag 9 oktober 2005 00:23

Acties:

Zwerver

Palomar schreef op zaterdag 08 oktober 2005 @ 23:58:
Nouja, zoveel verschillende platformen zijn er ook weer niet.

Minimaal 12

En het grootste gedeelte van de (beginnende) gebruikers heeft toch x86, dus daar kan iig wel een standaard voor worden gemaakt en dan kan de rest wel gaan aanklooien met source codes.
Ik erger me zelf ook telkens weer aan dit soort dingen bij Linux. Voor de gewone gebruiker wordt het allemaal zo onnodig moeilijk gehouden. Ik ben sinds kort redelijk intensief bezig met Ubuntu en dan kun je dus met apt-get allerlei kant en klaar spul downloaden. Dat werkt prima. Maar zogauw ik iets wil installeren wat niet op de repositories staat is er vaak alleen een source code van te downloaden. Nu ben ik best ervaren op computergebied en ook bereid om dingen te leren, maar het compilen en installeren en weet ik veel allemaal nog meer met die source bestanden dat lukt me 5 op de 10 keer gewoon niet. Aldoor weer errors waar ik niks van begrijp etc.

Zoeken op die error's op google lost anders negen van de tien keer het probleem op. Als jij een programma moet hebben onder Windows en dat is er niet, geef je dan ook Windows de schuld? Je moet blij zijn dat er voor de meest obscure dingen programma's zijn, dat je ze dan van source moet compilen, tja

En als een standaard voor (x86) binaries echt technisch niet mogelijk is (zou niet weten waarom niet, maargoed) dan is er toch ook wel iets als een installer te maken voor source bestanden. Iet swaarmee dit proces automatisch wordt uitgevoerd zonder in de console bezig te moeten gaan?

Heb jij enig idee wat je vraagt? Het configure proces loopt niet voor niks zo vaak mis. Er hangen nogal wat dependecies aan de meeste programma's, en i.t.t. Windows app's die vaak over de 20 mb zijn, zitten de libs niet per definitie bij de sourcecode van de app. Wat je eigenlijk vraagt is een packagemanager die sourcepackages compiled. Dat doet gentoo dus al en je wordt daar dus niet vrolijk van

Het idee is dus wel leuk, maar de uitvoering is (gezien de verschillende gcc versies, verschillende glibc versies e.d.) gewoon niet uitvoerbaar. Anders krijg je hetzelfde probleem wat je hebt gehad tussen 9x <> XP op Windows. Bepaalde programma's draaien gewoon niet meer op 9x en dat probleem heb je zelden op Linux, immers je kan recompilen.

Woonachtig Down Under. Ik negeer je insults niet, maar tegen de tijd dat ik ze lees zijn ze meestal niet relevant meer

zondag 9 oktober 2005 00:39

Acties:

zondag 9 oktober 2005 00:48

💩

Palomar schreef op zaterdag 08 oktober 2005 @ 23:58:
Nouja, zoveel verschillende platformen zijn er ook weer niet.

niet?

code:

1 2	marco@dbsrv:/usr/src/linux/arch$ ls -1 \| wc -l 23

Valt wel mee, inderdaad...

De 12 waar zwerver het over heeft is alleen maar waar debian op draait.

En het grootste gedeelte van de (beginnende) gebruikers heeft toch x86, dus daar kan iig wel een standaard voor worden gemaakt en dan kan de rest wel gaan aanklooien met source codes.

Nee, het hele punt was juist geen sources distribueren. Hoewel 't wel fijn is dat jij nu ook zegt, zij het op een andere manier, dat dat een slecht idee is.

Ik erger me zelf ook telkens weer aan dit soort dingen bij Linux. Voor de gewone gebruiker wordt het allemaal zo onnodig moeilijk gehouden. Ik ben sinds kort redelijk intensief bezig met Ubuntu en dan kun je dus met apt-get allerlei kant en klaar spul downloaden. Dat werkt prima. Maar zogauw ik iets wil installeren wat niet op de repositories staat is er vaak alleen een source code van te downloaden. Nu ben ik best ervaren op computergebied en ook bereid om dingen te leren, maar het compilen en installeren en weet ik veel allemaal nog meer met die source bestanden dat lukt me 5 op de 10 keer gewoon niet. Aldoor weer errors waar ik niks van begrijp etc.

Linux is niet gemaakt om op die manier gebruikt te worden. Daar zijn windows en osx voor gemaakt. Met uitzondering van OSX zijn alle unices gemaakt om gebruikt te worden door mensen die weten wat ze doen. Dat tegenwoordig alles 'gebruikersvriendelijk' en 'makkelijk' moet kunnen die unices niets aan doen.

En als een standaard voor (x86) binaries echt technisch niet mogelijk is (zou niet weten waarom niet, maargoed) dan is er toch ook wel iets als een installer te maken voor source bestanden. Iet swaarmee dit proces automatisch wordt uitgevoerd zonder in de console bezig te moeten gaan?

Nee. Sources hebben dependencies die een stuk moeilijker op te lossen zijn dan bij binaries. Bij binaries zou je alle libs nog static kunnen compilen. Maar om bij sources alles mee te leveren is niet altijd (lees: zelden) mogelijk.

All my posts are provided as-is. They come with NO WARRANTY at all.

Acties:

Cyphax

Moderator LNX

CyBeR schreef op zondag 09 oktober 2005 @ 00:39:
Linux is niet gemaakt om op die manier gebruikt te worden. Daar zijn windows en osx voor gemaakt. Met uitzondering van OSX zijn alle unices gemaakt om gebruikt te worden door mensen die weten wat ze doen. Dat tegenwoordig alles 'gebruikersvriendelijk' en 'makkelijk' moet kunnen die unices niets aan doen.

Dit is eigenlijk de bottom-line. Het moet allemaal op de Windows-manier. Dat daar gigantische nadelen aan zitten boeit gek genoeg weinig mensen maar. Dat is echt jammer.

Saved by the buoyancy of citrus

zondag 9 oktober 2005 01:17

Acties:

Borromini

Mislukt misantroop

Zwerver schreef op zondag 09 oktober 2005 @ 00:23:

Zoeken op die error's op google lost anders negen van de tien keer het probleem op. Als jij een programma moet hebben onder Windows en dat is er niet, geef je dan ook Windows de schuld? Je moet blij zijn dat er voor de meest obscure dingen programma's zijn, dat je ze dan van source moet compilen, tja

Ik vind een error zoals make: error [2] Bailing out anders erg cryptisch hoor... Dat kan vanalles betekenen als ik Google moet vertrouwen. Ik kan wel een beetje overweg met ./configure opties enzo, ik bouw eigen packages (checkinstall enz., voor Slackware

) maar als ik zo'n make error krijg dan houd ik het ook meestal wel voor gezien. Ik kan het natuurlijk ook posten ergens maar blijkbaar is het ontcijferen van die foutmeldingen niet voor iedereen weggelegd.

Got Leenucks? | Debian Bookworm x86_64 / ARM | OpenWrt: Empower your router | Blogje

zondag 9 oktober 2005 01:38

Acties:

engelbertus

het probleem zit er denk ik ook in dat de een gaarg met de nieuwste compiler werkt, en de ander op safe speelt. drivers gebruik kunnen maken van nieuwe features in X of de kernel, en dat je dan voor linux duizenden binaries gaat krijgen waardoor niemand meer kan zien welke hij nu nodig heet. ander probleem is.. hoe lever je dat allemaal mee?
dependency problemen ( zoals met .dll bestanden bij windows) kun je laten checken, maar als je dan een binarie instaleert die x 4.3 nodig heeft terwijl je met 6.8 werkt. tja. hoe fix je dat dan zonder det het een gore rotzooi op je systeem wordt en je klappers vol documentatie zou moeten aanleggen. zelf compileren is dan het devies, of het overlaten aan je packaemanagement systeem, die dus alleen voor bepaalde combinaties een oplossing geeft, en je waarschuwt op het moment dat je een nieuwere versie van iet snodig hebt voor het nieuwe pakketje, dat zonder problmen met andere aketten an worden geinstalleerd, of dat je zelf bijvoorbeeld een keus moet maken uit een (beperkte) keuze aan mogelijke install kandidaten. zoiets als met apt bij debian ( die overigens ook zelf kan compilen)

maw als je alleen binaries aangeleverd krijgt di toch dependencies hebben, dan heb ej zoveel problemen om op te lossen dat het niet meer "rendabel" is.

ook heb je nog de issue met open source software, waarbij gesloten software niet meegeleverd gaat wordn, omdat de distriutie daar natuurlijk tegen is. ( het pricipe van open source software ) zoek maar eens op warom debian bijvoorbeeld niet Realplayer 10 of gold mee levert.

en het voorbeeld van gaim.. de bepertje hoeveelheid paketen in binarie vorm ( of door jou genoemd downloads) worden ook of door iemand gemaakt die zich daar vrijwillig voor heeft opgegeven, of gemaakt door het ontwikkelteam, dat toch ook zelf zijn software zal moeten testen. dan is het bijna 1 druk op de knop om er een rpm of .deb of .exe installer van te bakken.
(omdat deze routine zich na elke release herhaalt kan deze bijna helemaal geaut0omatiseerd worden)
maar als je dan rekening moet houden met veranderende software die je /niet/ zelf onder je hoed hebt, dan wordt het lastig om up to date te blijven.

dn kan er beter gewerkt worden naar een situatie waarbij de wel beschikbare drivers voor bijv. windows, door linus worden gebruikt, dmv een extra laag. ( zoals bijv. ndiswrapper)

zondag 9 oktober 2005 01:45

Acties:

Zwerver

Borromini schreef op zondag 09 oktober 2005 @ 01:17:
[...]

Ik vind een error zoals make: error [2] Bailing out anders erg cryptisch hoor... Dat kan vanalles betekenen als ik Google moet vertrouwen. Ik kan wel een beetje overweg met ./configure opties enzo, ik bouw eigen packages (checkinstall enz., voor Slackware ) maar als ik zo'n make error krijg dan houd ik het ook meestal wel voor gezien. Ik kan het natuurlijk ook posten ergens maar blijkbaar is het ontcijferen van die foutmeldingen niet voor iedereen weggelegd.

Die error [2] is daarvoor al gedefinieerd. Kwestie van even een paar regels hoger kijken dus.

Woonachtig Down Under. Ik negeer je insults niet, maar tegen de tijd dat ik ze lees zijn ze meestal niet relevant meer

zondag 9 oktober 2005 02:36

Acties:

zondag 9 oktober 2005 12:33

💩

engelbertus schreef op zondag 09 oktober 2005 @ 01:38:
dn kan er beter gewerkt worden naar een situatie waarbij de wel beschikbare drivers voor bijv. windows, door linus worden gebruikt, dmv een extra laag. ( zoals bijv. ndiswrapper)

Dat is nog viezer dan binary-only drivers: de drivers van een ander platform gebruiken. Zeker niet iets wat ik op een productieserver wil zien gebeuren. Dat is gewoon vragen om problemen.

All my posts are provided as-is. They come with NO WARRANTY at all.

Acties:

irondog

alle dingen moeten onzin zijn

Waarom niet standaard binary drivers onder Linux?
Ik denk dat maar weinig mensen hier begrijpen waarom het niet wenselijk is om dat te hebben. Ja, het is dus gewoon niet wenselijk, het is dus niet een tekort-koming.

pierre-oord schreef op zaterdag 08 oktober 2005 @ 23:39:
Ik vroeg me toch eigenlijk af: Al die fabrikanten van drivers hebben altijd problemen met linux. Ze willen de techniek achter hun hardware (bijvoorbeeld videokaarten) niet bekend maken, en willen daarom geen open-source drivers leveren. Closed source kan dan wel, maar die modules verschillen steeds weer per kernel versie. En dan nog hopen dat het werkt...

Ja, en hoe kan dat? Gasten die closed source drivers proberen te maken voor linux, proberen hun bedrijfsgeheim te verpakken in een object file en schrijven een open-source loader voor hun progsel. Daarmee bereiken ze dit:
* ze beschermen hun source code voor hun apparaat
* ze blijven de GPL beter trouw
* ze stellen zeker dat insmod/modprobe altijd tevreden is bij het laden van de module (goede compilerversie/kernel versie).

Waarom kan er voor Linux niet gewoon 1 standaard voor drivers worden ontwikkeld, zodat fabrikanten drivers durven ontwikkelen en verspreiden in binary vorm?

Ja, daar heb je het woord, "standaard". Standaard betekent afspraken, standaard betekent dus compatibiliteit tussen versies en standaard betekent dat je niet zomaar je implementatie fouten kan laten vallen als een OS ontwikkelaar ineens ziet hoe het beter kan. Je zit dus aan je standaard vast, bah zegt Linus, wil ik niet.

Zie windows, al jaren geleden is besloten dat printerdrivers userspace drivers moeten zijn, toch ondersteunt windows nog steeds de oeroude methode van kernelspace drivers, waarom? Omdat het moet blijven werken, omdat er een standaard was. Voor USB is een soortgelijk iets gebeurd. Windows ondersteunt nog altijd drivers die gebruik maken van het brakke en achterhaalde subsyteem voor USB, dat al sinds jaar en dag vervangen is door een systeem dat superieur is aan het oude. Maar ja, die crappy oude drivers moeten blijven werken hè.

Om even een vergelijking te maken tussen de kernel-labs van Windows en de labs van Linux. Per verandering in de kernel (in Service Packs van Windows word je opgescheept met een nieuwe kernel onderdelen ja) worden tienduizenden tests gedaan met al dan niet gecertificeerde drivers van derde partijen. Linux daarentegen moet bij elke release een stabiele, werkende en vooral nette en leesbare source tree zijn. Als ze hier of daar een hookje veranderen van naam of qua implementatie, is dat het probleem van de maker/maintainer van de driver. De in de source aanwezige drivers zullen dus blijven werken omdat die meteen van hun flaws verlost worden en de API wordt met elke release in ieder geval nooit lelijker.

Wie je nu gaat beklagen als boosdoener voor de ietwat onhandige en onstabiele binary support in Linux, moet je zelf weten. Mijn wijsvinger is in ieder geval niet gericht naar linux.

[P5B deluxe] [Core2Duo 6300] [2 X 1GB DDR2] [GF FX7300] [320 GB WD] [Gentoo] [VISTA]

zondag 9 oktober 2005 12:56

Acties:

eamelink

Droptikkels

irondog schreef op zondag 09 oktober 2005 @ 12:33:
Als ze hier of daar een hookje veranderen van naam of qua implementatie, is dat het probleem van de maker/maintainer van de driver.

Dat is al een probleem. Dat je uberhaupt een 'maintainer' nodig hebt bij een driver. Vroeger werkte het toch? Waarom kan het niet blijven werken?

Wie je nu gaat beklagen als boosdoener voor de ietwat onhandige en onstabiele binary support in Linux, moet je zelf weten.

Ach, ik vind het al heel wat als een fabrikant de moeite neemt om een driver te schrijven voor linux voor zijn product. In veel gevallen zal het meer geld kosten dan opleveren.

Dan zóu het wel handig zijn als de kernelbakkers ervoor zorgen dat zo'n driver gemakkelijk te maken is en ook blijft werken. Nu is het dubbel onhandig. Je moet eerst een driver schrijven voor linux, en vervolgens moet je die dus inderdaad gaan 'maintainen'.

Lekker handig als je als driverprogrammeur werkt bij een bedrijf en er elke maand gewoon een nieuw product van de lopende band komt, waardoor je dus een steeds grotere hoeveelheid drivers moet gaan bijhouden.

Dan mogen de windowsdrivers misschien niet zo optimaal zijn als gemaintainde linux drivers, maar ze werken wél zoals je al zegt

.

Voor opensource drivers is het niet echt een probleem bij linux; altijd wel een gek te vinden die die driver nog nodig heeft en hem bijwerkt wanneer linus weer iets uithaalt. Maar bij closed source drivers voor linux kan dat niet

Mijn wijsvinger is in ieder geval niet gericht naar linux.

Ik neem het linux opzich ook niet kwalijk, maar vanuit de linux hoek wordt wel heel vaak met een beschuldigend vingertje naar de fabrikanten gewezen en dat lijkt me ook niet geheel terecht

zondag 9 oktober 2005 13:12

Acties:

Verwijderd

eamelink schreef op zondag 09 oktober 2005 @ 12:56:
[...]

Dat is al een probleem. Dat je uberhaupt een 'maintainer' nodig hebt bij een driver. Vroeger werkte het toch? Waarom kan het niet blijven werken?

Omdat jij zonodig moest upgraden naar een nieuwere versie?

zondag 9 oktober 2005 13:12

Acties:

Verwijderd

irondog schreef op zondag 09 oktober 2005 @ 12:33:Om even een vergelijking te maken tussen de kernel-labs van Windows en de labs van Linux. Per verandering in de kernel (in Service Packs van Windows word je opgescheept met een nieuwe kernel onderdelen ja) worden tienduizenden tests gedaan met al dan niet gecertificeerde drivers van derde partijen. Linux daarentegen moet bij elke release een stabiele, werkende en vooral nette en leesbare source tree zijn. Als ze hier of daar een hookje veranderen van naam of qua implementatie, is dat het probleem van de maker/maintainer van de driver. De in de source aanwezige drivers zullen dus blijven werken omdat die meteen van hun flaws verlost worden en de API wordt met elke release in ieder geval nooit lelijker.

Stabiele, werkende & vooral nette leesbare source? Werkend zeker, maar net, leesbaar & stabiel? Het voorbeeld van de ndiswrappers is al aangehaald. Linux heeft ontzettende problemen met VM gehad in stabiele releases, waarbij de VM werd omgegooid. Drivers voor PCI waren tijdenlang in verschillende architecturen als bijna-kopie aanwezig (in tegenstelling tot NetBSD, waar de PCI en IDE drivers veel meer cross-platform zijn). Dat wordt nu opgelost, maar Linux' prioriteit is nooit geweest om het geheel net & leesbaar te maken.

Als je zelf eens door de Linuxsource bladert, dan zie je ontzettend veel verschillende stijlen, soms staan er commentaren als 'als we dit niet doen, dan werkt het niet, maar wat het doet -- geen idee'.

Maar het probleem voor Linux en binaire driver is dat het een monolitische kernel is. Je kunt weliswaar wel modules laden, maar dat maakt het ontwerp niet minder monolitisch. Je kunt overal bij als kernel driver. Een micro-kernel zou allicht het probleem van veranderende inter-faces wat kunnen tegengaan, dan moet er nog wel voor elk platform gecompileerd worden. Doch wat dat betreft had Windows, toen het Alpha platform nog ondersteund werd, precies dezelfde problemen. Doch Windows ondersteunt nu alleen x86 (alhoewel ook voor NT en 98 etc. verschillende drivers werdne uitgebracht), dus het probleem is niet zo aanwezig. Doch ik heb genoeg mensen horen klagen toen 2000 uitkwam dat de driver voor hun geluidskaart niet meer werkte. Windows heeft dus eendere problemen, doch ze lopen minder in het oog daar de versies elkaar minder snel opvolgen en er maar één platform is.

zondag 9 oktober 2005 13:40

Acties:

irondog

alle dingen moeten onzin zijn

Ik neem het linux opzich ook niet kwalijk, maar vanuit de linux hoek wordt wel heel vaak met een beschuldigend vingertje naar de fabrikanten gewezen en dat lijkt me ook niet geheel terecht .

Jawel, niet mieppen! Kom op met die source !

(Ok, niet realistisch, maar je kunt van een open source kernel ook niet vragen om backward compatibility).

Verwijderd schreef op zondag 09 oktober 2005 @ 13:12:
[...]
Maar het probleem voor Linux en binaire driver is dat het een monolitische kernel is. Je kunt weliswaar wel modules laden, maar dat maakt het ontwerp niet minder monolitisch.

Jep, indien je een micro-kernel gebruikt en 80% van de dingen in userspace kunt doen en subsystemen via goed gedocumenteerde protocollen laat werken, ben je van een hoop geklooi af, maar niet alles. Maar ga nu niet beweren dat linux een microkernel had moeten zijn. In theorie zou de compatibiliteit en bruikbaarheid van drivers voor linux veel beter kunnen zijn, maar de hoge pieten willen dat gelukkig niet. Het heeft gewoon veel slechte kanten, die ik eerder al uitgediept heb.

[P5B deluxe] [Core2Duo 6300] [2 X 1GB DDR2] [GF FX7300] [320 GB WD] [Gentoo] [VISTA]

maandag 10 oktober 2005 00:28

Acties:

MSalters

CyBeR schreef op zondag 09 oktober 2005 @ 02:36:
[...]
Dat is nog viezer dan binary-only drivers: de drivers van een ander platform gebruiken. Zeker niet iets wat ik op een productieserver wil zien gebeuren. Dat is gewoon vragen om problemen.

Klopt - NDIS en Win32 PE zijn geen van beiden gemaakt om in deze rol gebruikt te worden. Linux zou in theorie een beter, neutraler formaat kunnen definieren. In feite run je dan alle binary drivers in een VM. Nou hebben VMs niet zo'n beste naam wat performance betreft, maar een driver gebruikt als het goed is toch al nauwelijks CPU. Van 1% naar 2% CPU valt best mee te leven. De uitzondering is uiteraard de graphics driver, maar dat is nog steeds geen probleem: je weet van te voren dat daar je bottleneck zit, dus daar kun je omheen designen. Bovendien weet je dat het x86 code is (vanwege MMX of SSE) dus portabiliteit naar PPC is sowieso dubieus. De enige rol van de VM is dus het marshallen met de overige kerneldelen (en dat alleen als die niet toevallig ook de nieuwe interfaces ondersteunen)

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein

maandag 10 oktober 2005 00:44

Acties:

MSalters

irondog schreef op zondag 09 oktober 2005 @ 12:33:
Ja, daar heb je het woord, "standaard". Standaard betekent afspraken, standaard betekent dus compatibiliteit tussen versies en standaard betekent dat je niet zomaar je implementatie fouten kan laten vallen als een OS ontwikkelaar ineens ziet hoe het beter kan. Je zit dus aan je standaard vast, bah zegt Linus, wil ik niet.

Nee, en dus zegt de hardware wereld massaal bah, Linux, zoek het zelf maar uit.

Microsoft mag dan wel zo z'n fouten hebben, maar het negeren van oude of nieuwe standaarden oude te dumpen is daar niet bij.

Zie windows, al jaren geleden is besloten dat printerdrivers userspace drivers moeten zijn, toch ondersteunt windows nog steeds de oeroude methode van kernelspace drivers, waarom? Omdat het moet blijven werken, omdat er een standaard was. Voor USB is een soortgelijk iets gebeurd. Windows ondersteunt nog altijd drivers die gebruik maken van het brakke en achterhaalde subsyteem voor USB, dat al sinds jaar en dag vervangen is door een systeem dat superieur is aan het oude. Maar ja, die crappy oude drivers moeten blijven werken hè.

Klopt - en daarom zijn er zoveel meer printerdrivers voor Windows. Dat die oude crappy dingen vaak alleen nog maar werken via wat vage hacks, matig performen, etcetera - boeien. De mensen die de drivers nog gebruiken zijn niet de mensen die daar heel erg mee zitten. "It Just Works" telt voor hun veel meer.

Om even een vergelijking te maken tussen de kernel-labs van Windows en de labs van Linux. Per verandering in de kernel (in Service Packs van Windows word je opgescheept met een nieuwe kernel onderdelen ja) worden tienduizenden tests gedaan met al dan niet gecertificeerde drivers van derde partijen.

Zo weinig maar? Ik dacht dat de test cycle 3 maanden was, op een hele stapel machines inclusief erg obscure hardware. Niet erg verschillend met Linux dus, alleen wat georganiseerder aangepakt. Het belangrijkste verschil is wel dat Microsoft bepaalt welke bugs er prioriteit hebben. In Linux is zelf fixen een optie.

Linux daarentegen moet bij elke release een stabiele, werkende en vooral nette en leesbare source tree zijn. Als ze hier of daar een hookje veranderen van naam of qua implementatie, is dat het probleem van de maker/maintainer van de driver. De in de source aanwezige drivers zullen dus blijven werken omdat die meteen van hun flaws verlost worden en de API wordt met elke release in ieder geval nooit lelijker.

Op zich is Microsoft iets beter in hun backwards compatibility in de API. Er is geen theoretische reden waarom een "fix" meteen oude code zou moeten breken. Er zijn in de MS API dan ook genoeg functies waarbij een van de argumenten impliciet de API versie is, de ...Ex varianten zijn gangbaar en met COM hebben ze het overdreven. De kernel is toegegeven een ander verhaal, maar ook daar gaat driver development georganiseerder in Windows. Linux zou gebaat zijn bij het equivalent van DDK releases (En Windows developers bij de source code van de HAL, maar da's een beete offtopic hier)

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein

maandag 10 oktober 2005 00:49

Acties:

maandag 10 oktober 2005 13:48

In de kernel source zelf staat btw ook een leuk stukje over de API: /usr/src/linux/Documentation/stable_api_nonsense.txt

"Man fears the darkness, and so he scrapes away at the edges of it with fire." - Rei Ayanami

Acties:

Verwijderd

Nee, en dus zegt de hardware wereld massaal bah, Linux, zoek het zelf maar uit.

Daar gaat het niet om, en dat is niet de reden waarom hardware fabrikanten geen drivers uitbrengen voor *nix.
De reden is dat ze er tegenop zitten om de drivers open source te maken (bedrijfs geheimen openbaar maken), als dat niet de reden is.
En dat er kosten aan zitten, drivers developers. Linux heeft een te kleine marktaandeel om de kosten te dekken van de developers/testers etc..

Microsoft mag dan wel zo z'n fouten hebben, maar het negeren van oude of nieuwe standaarden oude te dumpen is daar niet bij.

Het woord is vooruitgang, en niet blijven hannissen met oude standaarden.
En als je wat oude hardware hebt download je toch de oude source en compileer je die, niemand verplicht jou om het nieuwste van het nieuwste te draaien.

[ Voor 32% gewijzigd door Verwijderd op 10-10-2005 13:57 ]

maandag 10 oktober 2005 15:53

Acties:

maandag 10 oktober 2005 22:42

💩

Verwijderd schreef op maandag 10 oktober 2005 @ 13:48:
[...]

En dat er kosten aan zitten, drivers developers. Linux heeft een te kleine marktaandeel om de kosten te dekken van de developers/testers etc..

Ligt een beetje aan je markt. Voor een gadget of videokaart kun je stellen dat dat zo is, maar voor een hardware RAID kaart of crypto accelerator bijvoorbeeld niet. Die worden vaker gebruikt in unix(/linux) dozen dan in windows (consumenten)bakken.

All my posts are provided as-is. They come with NO WARRANTY at all.

Acties:

Verwijderd

Da Fox schreef op maandag 10 oktober 2005 @ 00:49:
In de kernel source zelf staat btw ook een leuk stukje over de API: /usr/src/linux/Documentation/stable_api_nonsense.txt

Ik snap niet dat iemand die tekst serieus neemt. Er worden allemaal idiote excuses opgenoemd die door LSB al lang worden opgelost. Uiteindelijk komt het er gewoon op neer dat ze niet durven, omdat ze erdoor in hun mogelijkheden beperkt zouden worden (bv. m.b.t. API wijzigingen e.d.), en alle projecten die niet in-kernel werken (bv. alle drivers die momenteel in ontwikkeling zijn, ATI/nvidia, etc. etc.) worden hierdoor enorm gedupeerd. Vooral externe 3rd party drivers hebben hier last van, omdat die nooit in-kernel zullen werken, en zij hebben hierdoor veel extra werk en kosten en zullen dus toekomstige linux-gerelateerde driver-projecten op een laag pitje houden.

Wat mij betreft zijn die core kernel mensen een stelletje enorme mietjes. GNOME biedt bv. al jaren developer API stabiliteit.

maandag 10 oktober 2005 23:29

Acties:

MSalters

Verwijderd schreef op maandag 10 oktober 2005 @ 13:48:
[...]
Daar gaat het niet om, en dat is niet de reden waarom hardware fabrikanten geen drivers uitbrengen voor *nix.De reden is dat ze er tegenop zitten om de drivers open source te maken (bedrijfs geheimen openbaar maken), als dat niet de reden is.

De meeste hardware is niet spannend. Jammer misschien van de illusie, maar alleen videokaarten hebben dat probleem in grote mate. De gemiddelde HP printer is zo ongeveer gratis; de enige reden dat hij niet goedkoper is is dat mensen dan een nieuwe kopen vanwege de inkt die bij de nieuwe zit.

En dat er kosten aan zitten, drivers developers. Linux heeft een te kleine marktaandeel om de kosten te dekken van de developers/testers etc..

Ja, dat is precies het punt. Als elke 3 weken de interface compleet kan veranderen en alles opnieuw mag, dan is dat duur. Da's niet erg voor Windows drivers, daar maken HW fabrikanten het wel weer goed op volume. Linux moet dus de lagere omzet per jaar compenseren met minder ABI wijzigingen, of het zonder fabrieksdrivers doen.

Het woord is vooruitgang, en niet blijven hannissen met oude standaarden.
En als je wat oude hardware hebt download je toch de oude source en compileer je die, niemand verplicht jou om het nieuwste van het nieuwste te draaien.

Security? 3rd party support? Thuis verplicht niemand me, nee.

Overigens, over standaarden gesproken: Microsoft is al een paar jaar om. C++/CLI, C#, de .NET CLR: ze gaan allemaal als standaard naar ISO SC22. Vrijwillig zelfs. Ook pure ISO C++ wordt omarmd. ISO SC22 is aan de andere kant ook bezig met Linux standaarden. Dat is echt een gevecht; de spelers daar zijn ongeveer net zo standard-minded als Microsoft anno 1996.

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein

dinsdag 11 oktober 2005 02:09

Acties:

daft_dutch

>.< >.< >.< >.<

blijkbaar ben je niet goed geinformeert over de debian common core alliance.
debian en een stel debian gebaseerde distros.
gaan samen 1 core van drivers libs en meer van dat soort dingen uitbrengen. dat men dcc compatable debs kan maken. deze is dan 100% compatible met alle dcc members.

>.< >.< >.< >.<

dinsdag 11 oktober 2005 20:23

Acties:

dinsdag 11 oktober 2005 21:49

Topicstarter

Aardig wat reply's. Wat jij zegt daft_dutch begrijp ik niet helemaal, zover ken ik "dcc" enzo niet.

Wat mij opvalt is dat een aantal mensen al noemen "We willen in Linux graag alle oude ondersteuningen dumpen als er nieuwe zijn". Dat zou niet moeten gebeuren, maar pas worden gedaan zoals bij windows, zodra het niet/nauwelijks meer wordt gebruikt. Als het niet voor crashes zorgt kan het toch fijn blijven zitten?

Drivers moeten gewoon gaan werken. Bijvoorbeeld een driver voor kernel 2.6, net zoals een driver voor Windows XP. Een driver voor windowsXP werkt onder de kale versie, SP1 en SP2. Dus voor linux moet het werken met 2.6.1, 2.6.2, enz.

Als mensen gewoon op een handige manier drivers kunnen installeren maakt dat een basisinstallatie voor Linux waarbij alles werkt alweer een stuk handiger, ook blijven er meer werkende drivers beschikbaar, en kun je gewoon upgraden naar een nieuwe kernel-versie met bugfixes, zie het maar als een windows-update, daarbij hoef je ook niet meteen nieuwe drivers te installeren.

Iedereen die nu weer komt met argumenten om het niet te doen: Op die manier zal Linux nooit een grote markt bereiken, dus kom dan ook niet met van die verhalen "Al die mensen zouden gewoon linux moeten draaien want het is veel sneller/stabieler etc etc" - Die mensen, including me, willen een systeem dat werkt. Als het afdrukken mij 1 seconde langer duurt hoor je mij niet klagen.

Bij windows kunnen verder DLL bestanden verder veel beter door elkaar gebruikt worden, afaik. Een programma kan een nieuwere nodig hebben (die die dan ook kan installeren) maar het oude programma zal nog wel werken, ik denk door het opgeven van de versie oid zoals iemand al noemde. Zo zouden libs in linux ook moeten werken, dan hoef je niet alles static te maken, al zou dat geen onoverkomelijk probleem zijn.

Als dit nou standaard wordt, en er voor de mensen die echt zo graag nettere, mooiere, schonere, 0.1% snellere source willen hebben, een apart systeem gemaakt wordt? Verscheidenheid bij Linux is volgens mij juist de zwakheid ervan, niemand durft op Linux te bouwen.

Als je software ontwikkelaar bent, moet je volgens mij heel veel moeite doen om zeker te weten dat jouw app op iedere i386 linux versie werkt, omdat al die libs en instellingen per distributie kunnen verschillen.

Ik zie Linux vooralsnog als leuk server systeem, maar voor de rest moeten bedrijven/overheid/scholen/particulieren fijn windows blijven draaien, willen ze een compleet, werkend, en vooral begrijpbaar besturingssysteem willen.

Ondernemer in tech (oud LOQED.com, nu UpToMore.com)

Acties:

Verwijderd

pierre-oord schreef op dinsdag 11 oktober 2005 @ 20:23:
Wat mij opvalt is dat een aantal mensen al noemen "We willen in Linux graag alle oude ondersteuningen dumpen als er nieuwe zijn". Dat zou niet moeten gebeuren, maar pas worden gedaan zoals bij windows, zodra het niet/nauwelijks meer wordt gebruikt. Als het niet voor crashes zorgt kan het toch fijn blijven zitten?

Maar hoe zit het dan zoals al eerder genoemd dat een bepaalde API security problemen heeft? Je moet toch echt die stable_api_nonsense.txt eens lezen

Als mensen gewoon op een handige manier drivers kunnen installeren maakt dat een basisinstallatie voor Linux waarbij alles werkt alweer een stuk handiger, ook blijven er meer werkende drivers beschikbaar, en kun je gewoon upgraden naar een nieuwe kernel-versie met bugfixes, zie het maar als een windows-update, daarbij hoef je ook niet meteen nieuwe drivers te installeren.

Ik hoop dat je nu niet zit te betogen om in Linux (en andere FLOSS OS'en) zo'n zelfde model als Windows te introduceren. Het driver model is een van de grootste ergernissen aan Windows! Moet je bijvoorbeeld eens proberen een oude wireless kaart te installeren (waar de f*ck vind ik drivers voor XP? waarom werkt het niet standaard? waarom crasht m'n systeem als ik eindelijk XP drivers gevonden heb voor de netwerkkaart... Hoe verwijder ik nu alle drivers en software gerelateerd aan wireless kaart X). In Linux (en BSD) werkt het ding gewoon uit de doos...

Iedereen die nu weer komt met argumenten om het niet te doen: Op die manier zal Linux nooit een grote markt bereiken, dus kom dan ook niet met van die verhalen "Al die mensen zouden gewoon linux moeten draaien want het is veel sneller/stabieler etc etc" - Die mensen, including me, willen een systeem dat werkt. Als het afdrukken mij 1 seconde langer duurt hoor je mij niet klagen.

Het systeem van Windows is juist niet doable. Het houdt innovatie tegen (ja echt waar!) en je blijft voor altijd met de oude lekke crap zitten...backwards compatibiliteit is mooi, maar niet ten koste van alles (en zeker niet stabiliteit / veiligheid). Als je een systeem wilt dat werkt neem je juist *geen* Windows omdat je echt een super expert moet zijn om het systeem netjes te krijgen (moderne drivers voor al je hardware), veilig, en ook nog eens werkbaar...dat de meeste mensen hier niet om geven leert de ervaring...het OS moet dus dwingen dat het GOED werkt, dan werkt die fancy webcam die je zojuist bij de Blokker gekocht hebt maar niet...

Bij windows kunnen verder DLL bestanden verder veel beter door elkaar gebruikt worden, afaik. Een programma kan een nieuwere nodig hebben (die die dan ook kan installeren) maar het oude programma zal nog wel werken, ik denk door het opgeven van de versie oid zoals iemand al noemde. Zo zouden libs in linux ook moeten werken, dan hoef je niet alles static te maken, al zou dat geen onoverkomelijk probleem zijn.

De meeste libraries zijn backwards compatible, zo niet zijn ze prima parallel te installeren (bijvoorbeeld de compat-* packages in Fedora). Denk hierbij aan libstdc++ van gcc3, gtk1 etc.

Als dit nou standaard wordt, en er voor de mensen die echt zo graag nettere, mooiere, schonere, 0.1% snellere source willen hebben, een apart systeem gemaakt wordt? Verscheidenheid bij Linux is volgens mij juist de zwakheid ervan, niemand durft op Linux te bouwen.

Is Linux niet een apart systeem?

Als je software ontwikkelaar bent, moet je volgens mij heel veel moeite doen om zeker te weten dat jouw app op iedere i386 linux versie werkt, omdat al die libs en instellingen per distributie kunnen verschillen.

Lever de broncode, dan heb je dat probleem niet. Wil je dat niet? Dan zul je met de consequenties moeten leven. Een bedrijf als VMware doet dat bijvoorbeeld op een redelijk goede manier... nVidia en ATI duidelijk niet.

Ik zie Linux vooralsnog als leuk server systeem, maar voor de rest moeten bedrijven/overheid/scholen/particulieren fijn windows blijven draaien, willen ze een compleet, werkend, en vooral begrijpbaar besturingssysteem willen.

Ik zie Linux als een leuk server en desktop systeem, niet alleen voor mij, maar ook voor m'n ouders. Ik hoef nu niet iedere week het systeem te verfrissen van allerlei spyware

Ze werken al sinds de release van FC1 ermee en nog nooit noemenswaardige problemen gehad.

dinsdag 11 oktober 2005 23:39

Acties:

woensdag 12 oktober 2005 01:40

Topicstarter

Verwijderd schreef op dinsdag 11 oktober 2005 @ 21:49:
[...]
Maar hoe zit het dan zoals al eerder genoemd dat een bepaalde API security problemen heeft? Je moet toch echt die stable_api_nonsense.txt eens lezen

Tuurlijk, als er een groot beveiligingsprobleem is kan zo'n functie eruit worden gehaald, óf beter beveiligd worden. Het gaat niet allemaal om beveiligingsproblemen...

Ik hoop dat je nu niet zit te betogen om in Linux (en andere FLOSS OS'en) zo'n zelfde model als Windows te introduceren. Het driver model is een van de grootste ergernissen aan Windows! Moet je bijvoorbeeld eens proberen een oude wireless kaart te installeren (waar de f*ck vind ik drivers voor XP? waarom werkt het niet standaard? waarom crasht m'n systeem als ik eindelijk XP drivers gevonden heb voor de netwerkkaart... Hoe verwijder ik nu alle drivers en software gerelateerd aan wireless kaart X). In Linux (en BSD) werkt het ding gewoon uit de doos...

Deels wel, deels niet. Dat het systeem crasht bij het laden van een driver vind ik slecht. Je noemt zelf een voorbeeld van een oude wireless kaart: Tsja, leuk, bij Linux kun je een driver vinden maar moet je zelf in C hem aanpassen om hem op je nieuwe kernel te laten werken, zoals al eerder genoemd... Dus ja, of daar nou veel verschil in zit? Lang niet alles bij linux werkt uit de doos, was het maar zo. Nieuwe hardware, daar doen de fabrikanten vanwege het opensource idee nu moeilijk over zoals al eerder genoemd, omdat ze hun ideeen niet vrij willen geven aan andere fabrikanten, geef ze eens ongelijk...
Op jouw vragen:
- Inderdaad, kwa foutlogging ontbreekt er een hoop in Windows, als Linux zich daar nou op richt

- Verwijderen drivers: Kan vaak heel handig in safemode, met het knopje verwijderen. Lukt dat niet, dan, misschien ietswat ingewikkeld maar dat lijkt me niet voor al die Linux professionals die met Vi kunnen werken: Zoek op bestanden met de inhoud van %productnaam%. Je komt een .inf bestand tegen, waarschijnlijk met de naam OEMblablabla.inf. Verwijderen, evenals de gelijknamige .vxd (of andere extentie, ik ben even niet zeker) uit de system32 directory. Voila, drivers verwijderd...

Ik denk dat drivers eigenlijk van de kernel gescheiden moeten zijn. (Drivers = alles wat apparatuur op de computer aanstuurd). Zo kun je zonder zorgen je kernel (met security fixes misschien?...) upgraden.
[/quote]

Het systeem van Windows is juist niet doable. Het houdt innovatie tegen (ja echt waar!) en je blijft voor altijd met de oude lekke crap zitten...backwards compatibiliteit is mooi, maar niet ten koste van alles (en zeker niet stabiliteit / veiligheid). Als je een systeem wilt dat werkt neem je juist *geen* Windows omdat je echt een super expert moet zijn om het systeem netjes te krijgen (moderne drivers voor al je hardware), veilig, en ook nog eens werkbaar...dat de meeste mensen hier niet om geven leert de ervaring...het OS moet dus dwingen dat het GOED werkt, dan werkt die fancy webcam die je zojuist bij de Blokker gekocht hebt maar niet...

- Het houdt innovatie tegen? Kun je daar een voorbeeld van noemen? Of bedoel je dat als je denkt: Mwa, ondersteuning van X is niet zo goed.... weet je wat, we slopen het eruit, en kijken wel of iemand in een van de volgende versies er weer wat leuks voor heeft ingestopt. Tsja, innovatie krijg je dan wel, maar of het wenselijk is...
Overigens ben ik van mening dat Windows een stabiel systeem is, en dan praat ik over XP. Tuurlijk, er zitten fouten in, maar deze neem ik nu voor lief. Veiligheid: Tsja, gebruikersaccounts standaard als administrator is inderdaad niet erg veilig, maar waarschijnlijk wil Microsoft z'n hotline vragen besparen van gebruikers die hun software niet kunnen installeren. Daarop zou je natuurlijk wel kunnen innoveren zoals langzaam komt: Vragen bij het openen van executables of je het wel vertrouwd, om een voorbeeld te noemen. Een forse melding bij de installatie van iets is al genoeg. Maar de meeste troep zoals spyware/adware komt toch binnen met die filesharing programma's, en die willen de mensen toch installeren. Niemand zit met adware, pas als de PC langzaam is is het wenselijk het eraf te halen.

De meeste libraries zijn backwards compatible, zo niet zijn ze prima parallel te installeren (bijvoorbeeld de compat-* packages in Fedora). Denk hierbij aan libstdc++ van gcc3, gtk1 etc.

Ok, iemand voor mij gaf aan dat er bij Windows vaak versienummers worden meegegeven als argument, ik nam daarbij aan dat bij Linux daardoor problemen zouden optreden door verschillende veries van libaries, wat dus schijnbaar niet zo is

Is Linux niet een apart systeem?

Ik vergleek Linux niet met Windows, maar ik vergleek de Linuxen met elkaar. Redhat, Suse, Debian, Slackware enz. Daar is nu eenmaal weinig aan te doen totdat de massa Linux gaat gebruiken, en waarschijnlijk een distributie kiest op kleur van de doos.... Door zoveel verscheidenheid is het lastiger standaard te maken, al is het maar voor de plaats van programma's aan te geven.

Lever de broncode, dan heb je dat probleem niet. Wil je dat niet? Dan zul je met de consequenties moeten leven. Een bedrijf als VMware doet dat bijvoorbeeld op een redelijk goede manier... nVidia en ATI duidelijk niet.

Daar mis je een klein stukje: Je zegt "dan zul je met de consequenties moeten leven" en je doelt in dit geval op de fabrikant. De fabrikant zit er niet zo mee als 0,005% van de mensen geen driver heeft, als ze die moeten schrijven (en bijhouden, want dan worden ze ook verantwoordelijk gehouden ook...) zijn ze veel meer kwijt. Uiteindelijk dus jammer voor de mensen zelf. Buiten het feit dat ze sowieso geen opensource willen schrijven om hun bedrijfsgeheimen geheim te houden...

Ik zie Linux als een leuk server en desktop systeem, niet alleen voor mij, maar ook voor m'n ouders. Ik hoef nu niet iedere week het systeem te verfrissen van allerlei spyware Ze werken al sinds de release van FC1 ermee en nog nooit noemenswaardige problemen gehad.

Over dat punt van je ouders: Ik heb ook ouders (nee, echt?

) en die zou ik niet met Linux kunnen opzadelen. Mijn moeder die enkel wat mailt, dat zou nog kunnen, na de uitleg hoe het werkt dan wel (en nadat ik heb uitgelegd waarom ik zo nodig dat zou moeten installeren...). M'n pa zou gek worden. Hij is gewend te werken met Windows, en zou niets kunnen terugvinden. Hij zou A: en E: kwijt zijn, niet begrijpen waar Internet Explorer heen is en zich afvragen of je root kunt bestellen of dat je computer dan moet worden schoongemaakt.

Ja, inderdaad, blabla ze zijn gewend te werken met Windows maar Linux is veel beter... misschien is het handiger eerst de interface te spiegelen en gebruikers te winnen. Als je daarna geleidelijk veranderingen doorvoert, zullen gebruikers eraan wennen. Buiten dat is het nog goed ook voor de fabrikanten van distributies, want die kunnen fijn nieuwe versies leveren met een grote stikker "Improved!" erop geplakt.

Het is dan alleen nog wachten op Realnetworks die een schikking treft met Suse omdat ze een gratis mediaplayer hebben toegevoegd en ze nu geen kans maken ook een mediaplayer te ontwikkelen voor Linux. (en de schikking zal wel 3x zo hoog zijn als met MS, aangezien er toch tenmninste 3 mediaplayers bij het pakket zitten. En 2 office pakketen. En 4 browsers. En 2 filemanagers. En whaaaaa.. zelfs 2 windows managers.... (om nog maar een puntje aan te halen, distromanagers moeten niet teveel bij hun distro stoppen, Linux op 6 CD's, je bent toch niet gek?..)

Vat mijn reactie niet op als persoonlijk commentaar hoor

'k had beetje betoogavond geloof ik

Ondernemer in tech (oud LOQED.com, nu UpToMore.com)

Acties:

Verwijderd

pierre-oord schreef op dinsdag 11 oktober 2005 @ 23:39:
Deels wel, deels niet. Dat het systeem crasht bij het laden van een driver vind ik slecht. Je noemt zelf een voorbeeld van een oude wireless kaart: Tsja, leuk, bij Linux kun je een driver vinden maar moet je zelf in C hem aanpassen om hem op je nieuwe kernel te laten werken, zoals al eerder genoemd... Dus ja, of daar nou veel verschil in zit? Lang niet alles bij linux werkt uit de doos, was het maar zo. Nieuwe hardware, daar doen de fabrikanten vanwege het opensource idee nu moeilijk over zoals al eerder genoemd, omdat ze hun ideeen niet vrij willen geven aan andere fabrikanten, geef ze eens ongelijk...

Het idee was meer dat als een driver eenmaal in Linux (in de kernel dus) zit blijft ie daar ook zitten en zal ie meegenomen worden en geupdate worden als er iets veranderd intern in de kernel. Dus m'n 16 bit ISA soundkaart van 10 jaar terug doet het ook nog prima in Linux terwijl in Windows sinds 2000 hij al niet meer werkt. Ander voorbeeld:

wd.c:v1.10 9/23/94 Donald Becker (becker@cesdis.gsfc.nasa.gov)

Zit nog steeds in 2.6.13-1.1526_FC4smp, je hoeft niet te proberen om deze netwerkkaart nog in Windows 2000 of hoger aan de praat te krijgen (doet niet meer aan ISA kaarten afaik). Dus dat zelf aanpassen zal wel meevallen

Op jouw vragen:
- Inderdaad, kwa foutlogging ontbreekt er een hoop in Windows, als Linux zich daar nou op richt

Ik weet niet precies waar dit over ging?

- Verwijderen drivers: Kan vaak heel handig in safemode, met het knopje verwijderen. Lukt dat niet, dan, misschien ietswat ingewikkeld maar dat lijkt me niet voor al die Linux professionals die met Vi kunnen werken: Zoek op bestanden met de inhoud van %productnaam%. Je komt een .inf bestand tegen, waarschijnlijk met de naam OEMblablabla.inf. Verwijderen, evenals de gelijknamige .vxd (of andere extentie, ik ben even niet zeker) uit de system32 directory. Voila, drivers verwijderd...

Net zo makkelijk / moeilijk dan. Verschil zijnde dat je bij Linux geen drivers hoeft te verwijderen omdat ze in conflict met elkaar raken of je 10 versies van een driver in system32 hebt staan.

Ik denk dat drivers eigenlijk van de kernel gescheiden moeten zijn. (Drivers = alles wat apparatuur op de computer aanstuurd). Zo kun je zonder zorgen je kernel (met security fixes misschien?...) upgraden.

Dat *is* al het geval, tenminste, ze worden wel samen geleverd. Als je dat doet, dus drivers los van het OS wat stop je dan wel bij het OS en wat niet? de drivers die OSS zijn stop je er standaard bij en de closed niet? hm...welke situatie hebben we nu ook weer...

- Het houdt innovatie tegen? Kun je daar een voorbeeld van noemen?

Bijvoorbeeld de verhuizing van 8K stack naar 4K stack (je kan je natuurlijk afvragen wat de innovatieve waarde hier van is

) maar de kernel devvers vonden dat een betere default waarde. Probleem was dat veel drivers braken. Die in kernel zaten waren zo gefixed, die van nVidia duurde echt MAANDEN...en zo zijn er ongetwijfeld nog vele meer voorbeelden te noemen.

Overigens ben ik van mening dat Windows een stabiel systeem is, en dan praat ik over XP. Tuurlijk, er zitten fouten in, maar deze neem ik nu voor lief.

Prima, een goed geconfigureerd Windows systeem kan best stabiel zijn.

Veiligheid: Tsja, gebruikersaccounts standaard als administrator is inderdaad niet erg veilig, maar waarschijnlijk wil Microsoft z'n hotline vragen besparen van gebruikers die hun software niet kunnen installeren.

90%? koopt z'n computer met Windows erop en belt dus sowieso niet naar MS maar naar de leverancier voor ondersteuning. Verder zijn de makers van software verkeerd bezig omdat software niet als gebruiker geinstalleerd kan worden (of tenminste gebruikt!) Er is zoveel waardeloze software in omloop voor Windows die je systeem slopen of je veiligheid compromitteren dat het gewoon niet meer veilig te houden is.

Daarop zou je natuurlijk wel kunnen innoveren zoals langzaam komt: Vragen bij het openen van executables of je het wel vertrouwd, om een voorbeeld te noemen. Een forse melding bij de installatie van iets is al genoeg. Maar de meeste troep zoals spyware/adware komt toch binnen met die filesharing programma's, en die willen de mensen toch installeren. Niemand zit met adware, pas als de PC langzaam is is het wenselijk het eraf te halen.

Dat is helemaal niet genoeg. Want er wordt toch doorgeklikt. Software hoor je niet vanaf 't Internet te installeren omdat als je niet weet wat je doet je in een klap je computer veranderd in een spamhost. Wat wel kan is dat software netjes in een repository staat waarbij de software gesigneerd is door de OS leverancier bijvoorbeeld. Dit is wat je ziet bij Linux distributies. Dit moet ook de enige manier zijn dat eindgebruikers zoals mijn ouders, jouw ouders en 90% van de computerende bevolking software kan installeren. Dan is er helemaal geen waarschuwing nodig waar toch direct op OK geklikt wordt. Klinkt dat onhaalbaar, misschien, maar het is denk ik een goede stap om computeren veilig te maken voor iedereen (onafhankelijk van 't OS).

Ik vergleek Linux niet met Windows, maar ik vergleek de Linuxen met elkaar. Redhat, Suse, Debian, Slackware enz. Daar is nu eenmaal weinig aan te doen totdat de massa Linux gaat gebruiken, en waarschijnlijk een distributie kiest op kleur van de doos.... Door zoveel verscheidenheid is het lastiger standaard te maken, al is het maar voor de plaats van programma's aan te geven.

Verschillende distributies en SOURCE-compatibiliteit zijn juist een goed ding. Dat is wat je nu ook ziet, wat boeit het dat Firefox van Fedora niet in Mandriva draait...juist, helemaal niks.

Daar mis je een klein stukje: Je zegt "dan zul je met de consequenties moeten leven" en je doelt in dit geval op de fabrikant. De fabrikant zit er niet zo mee als 0,005% van de mensen geen driver heeft, als ze die moeten schrijven (en bijhouden, want dan worden ze ook verantwoordelijk gehouden ook...) zijn ze veel meer kwijt. Uiteindelijk dus jammer voor de mensen zelf. Buiten het feit dat ze sowieso geen opensource willen schrijven om hun bedrijfsgeheimen geheim te houden...

Ik doel inderdaad op de fabrikant omdat ze dan erg veel moeite moeten doen om hun driver voor Linux (en andere OS'en) beschikbaar te maken. Als ze dat niet doen zullen ze op een bepaald moment klanten gaan mislopen. Linux op de desktop zie je steeds meer, dus ze zullen wel moeten.

Over dat punt van je ouders: Ik heb ook ouders (nee, echt? ) en die zou ik niet met Linux kunnen opzadelen. Mijn moeder die enkel wat mailt, dat zou nog kunnen, na de uitleg hoe het werkt dan wel (en nadat ik heb uitgelegd waarom ik zo nodig dat zou moeten installeren...). M'n pa zou gek worden. Hij is gewend te werken met Windows, en zou niets kunnen terugvinden. Hij zou A: en E: kwijt zijn, niet begrijpen waar Internet Explorer heen is en zich afvragen of je root kunt bestellen of dat je computer dan moet worden schoongemaakt.

Zou andersom net zo zijn, Linux -> Windows dus niet echt een argument

Ja, inderdaad, blabla ze zijn gewend te werken met Windows maar Linux is veel beter... misschien is het handiger eerst de interface te spiegelen en gebruikers te winnen. Als je daarna geleidelijk veranderingen doorvoert, zullen gebruikers eraan wennen. Buiten dat is het nog goed ook voor de fabrikanten van distributies, want die kunnen fijn nieuwe versies leveren met een grote stikker "Improved!" erop geplakt.

Ik denk dat je moet doen wat goed is (hoor mij nou

) en niet wat de overstap het makkelijkst maakt. Ik denk overigens niet dat de gemiddelde GNOME of KDE desktop nou zo veel beter is dan XP ofzo, maar 't gaat om 't idee. Eigen identiteit is helemaal niet verkeerd.

[..]
(om nog maar een puntje aan te halen, distromanagers moeten niet teveel bij hun distro stoppen, Linux op 6 CD's, je bent toch niet gek?..)

Ze moeten juist alles in hun distro stoppen, 1 CD basis installatie de rest via Internet (of een DVD voor de inbellers).

Vat mijn reactie niet op als persoonlijk commentaar hoor 'k had beetje betoogavond geloof ik

Als jij 't zelfde doet

woensdag 12 oktober 2005 18:35

Acties:

Verwijderd

Hmm interessante discussie.

Om even bij het allereerste punt te beginnen: binary drivers kan je met Linux met DKMS gebruiken.
Dus het kan al wel.

Waarom fabrikanten hun drivers niet open willen maken? Dat heeft niet zoveel te maken met hun bedrijfsgeheimen (je hoeft alleen de spec te geven, welke registers doen wat, hoe werkt de interface, helemaal niet: wat zit er precies in en hoe werkt het van binnen), maar meer met dat je aan de interface kunt zien of bepaalde gepatenteerde technieken (waarschijnlijk) gebruikt worden. Dus je maakt je eventueel kwetsbaar voor patentaanklachten. En ook dat je die patenten vrijgeeft als je je driver GPL maakt.

Klein voorbeeld: de pwc webcam driver, waarbij er vroeger de pwcx closed source module had.
Die pwcx driver bevat een decompressie algoritme waar Philips (maker van pwc - philips web cam - producten) het patent op heeft. Dit wordt in de hardware uitgevoerd, dus nog niet helemaal een software patent. Philips Semiconductors levert de bewuste cam chips aan diverse OEM bedrijven, op lang niet alle cams die met pwc werken staat Philips. Die bedrijven moeten aan Philips betalen voor het pakket: de chips plus de software. Als Philips die pwcx code onder de GPL vrijgeeft, kan zo'n klant gewoon zeggen: hey, ik hoef je software niet, ik neem wel de GPL software driver. Dus dat kost ze geld, en dus doen ze daar niet aan mee.
Ze moeten dus wel volhouden dat ze die info niet kunnen vrijgeven, anders zijn ze een bron van inkomsten kwijt - en leg dat maar aan de aandeelhouders uit. Daar kom je alleen maar mee weg als je elders ziet dat je meer verlies maakt als je de zaak niet vrijgeeft, en dat is niet duidelijk, dus niet bewezen.
(Als je je afvraagt hoe ik dit weet: iemand die bij Philips werkt en zich daarin interesseerde heeft het me uitgelegd.)
Luc Saillard heeft met reverse engineering de gewone pwc driver uitgebreid waardoor hij dezelfde functionaliteit als de pwcx driver had, maar dit is schijnbaar inmiddels door Alan Cox (of een ander) weer verwijderd omdat de technologie gepatenteerd is (door Philips).
(Wat weer inhoud dat ik weer moet gaan compilen... Mandriva 2006.)

Met binary drivers moet Linux vastgelegd worden, en dat is kwa ontwikkeling niet praktisch. Bovendien, dan hang je weer van de fabrikant af - wat je niet wilt. Kijk maar naar AMD64, hoe kwam het dat zodra er systemen op de markt kwamen linux die 64 bit prima kon gebruiken, en MSWin langer dan een jaar alleen de 32 bits versie had voor amd64?
Het is dus een heel groot pluspunt om in Linux de open source driver mentatiteit te hebben.
Stel je voor dat morgen een supercoole low power maar krachtige cpu voorgesteld wordt - dan hoef je alleen maar een compiler/de architectuur info te hebben en in de kortste keren heb je een werkend Linux systeem.

De enige fabrikanten die zich echt sterk verzetten zijn die van de grafische kaarten. Voor alle andere producten kan je zonder meer modellen vinden waarvoor open source drivers beschikbaar zijn. Printers (naja, neem gewoon een ps printer), scanners, webcams, tvkaarten, etcetc.
Stem met je portemonnee, koop bij voorkeur hardware met open source drivers en specs.

woensdag 12 oktober 2005 21:40

Acties:

Guru Evi

Wel, de vraag van de ts is eenvoudig te beantwoorden:

Hoe komt dat er geen standaard binary's zijn voor Windows. Die zijn er ook niet, als ik Windows programma's wil draaien op Alpha dan lukt het niet. Dat komt omdat binary's machinecode hebben die cpu-type specifiek zijn. De binary drivers voor Ati en Nvidia bestaan, andere binary drivers zijn er ook maar andere fabrikanten brengen ze niet/niet goed uit omdat ze met contracten vastzitten of omdat ze het niet rendabel vinden. Als zij gewoon een soort API uitgeven met een deel binary code in en uitleg hoe je bepaalde functies (vb. opengl functies) moet uitvoeren dan moet jij een programmeur maar een wrapper maken voor het desbetreffende besturingssysteem die de code van je app (vb. mplayer) -> platform (vb. X) -> driver (ati) -> kernel -> hardware vertaalt. Zo hoef je niet te weten als programmeur wat er gebeurt binnenin de driver om je beeld te vertalen naar instructies die naar je agp bus gestuurd worden

[ Voor 19% gewijzigd door Guru Evi op 12-10-2005 21:45 ]

Pandora FMS - Open Source Monitoring - pandorafms.org

donderdag 13 oktober 2005 15:19

Acties:

donderdag 13 oktober 2005 19:13

Topicstarter

@Guru Evi,

Het laatste zou het beste zijn, een soort gecompileerde code die niet cpu specifiek is. Maar wat windows-driver-makers doen is gewoon hun driver voor alle beschikbare versies compileren. Als ze dat voor Windows doen kunnen ze dat voor Linux ook best doen. Oké, je dekt dan misschien niet iedere architectuur, maar zo snel komen er ook weer geen nieuwe. En je Radeon 9800pro hoeft ook niet op een PDA met speciale CPU ofzo te werken

Ondernemer in tech (oud LOQED.com, nu UpToMore.com)

Acties:

donderdag 13 oktober 2005 22:14

Topicstarter

Mensen deze flash móet je kijken, hoort echt bij het topic, vooral het laatste stuk:
http://www.padlarv.nl/media/switchlinux5.swf

Ondernemer in tech (oud LOQED.com, nu UpToMore.com)

Acties:

Verwijderd

http://www.kernel.org/git...n/stable_api_nonsense.txt

Lees dit nu toch eerst maar eens hoor

donderdag 13 oktober 2005 22:19

Acties:

donderdag 13 oktober 2005 22:49

pierre-oord schreef op donderdag 13 oktober 2005 @ 15:19:
gecompileerde code die niet cpu specifiek is.

uhm... sorry maar hoe had je je dat voorgesteld? Een soort Java, maar dan voor drivers?

Daar zal je performance ook niet van omhoog gaan.

-addon:
Ik denk vind dat bedrijven zoals ATi hun drivers moeten opsplitsen (als ze dat al niet doen?) in 2 delen: 1 binary deel, per architecture, dat niets meer is dan een library van functies voor het aansturen van de video kaart (zodat hun 'geheimen' geheim blijven) en een open-source kernel module, die dan ook in de kernel zit. Deze module laad dan zelf de binary file in, en interfaced met de library, die weer met de grafische kaart communiceerd.
Ik weet niet of dit op deze manier kan (dat een kernel module zelf een plain binary file inlaad), maar het lijkt me op een goed plan. Ik heb het idee dat ik hier wel al eens van heb gehoord icm linux (wireless driver mss?)

[ Voor 55% gewijzigd door Da Fox op 13-10-2005 22:26 ]

"Man fears the darkness, and so he scrapes away at the edges of it with fire." - Rei Ayanami

Acties:

Verwijderd

Da Fox schreef op donderdag 13 oktober 2005 @ 22:19:
Ik denk vind dat bedrijven zoals ATi hun drivers moeten opsplitsen (als ze dat al niet doen?) in 2 delen: 1 binary deel, per architecture, dat niets meer is dan een library van functies voor het aansturen van de video kaart (zodat hun 'geheimen' geheim blijven) en een open-source kernel module, die dan ook in de kernel zit. Deze module laad dan zelf de binary file in, en interfaced met de library, die weer met de grafische kaart communiceerd.
Ik weet niet of dit op deze manier kan (dat een kernel module zelf een plain binary file inlaad), maar het lijkt me op een goed plan. Ik heb het idee dat ik hier wel al eens van heb gehoord icm linux (wireless driver mss?)

Dit is precies wat nVidia doet...en gaar dat 't is

[ Voor 11% gewijzigd door Verwijderd op 13-10-2005 22:49 ]

donderdag 13 oktober 2005 23:21

Acties:

Rukapul

Verwijderd schreef op maandag 10 oktober 2005 @ 22:42:
[...]

Ik snap niet dat iemand die tekst serieus neemt. Er worden allemaal idiote excuses opgenoemd die door LSB al lang worden opgelost. Uiteindelijk komt het er gewoon op neer dat ze niet durven, omdat ze erdoor in hun mogelijkheden beperkt zouden worden (bv. m.b.t. API wijzigingen e.d.), en alle projecten die niet in-kernel werken (bv. alle drivers die momenteel in ontwikkeling zijn, ATI/nvidia, etc. etc.) worden hierdoor enorm gedupeerd. Vooral externe 3rd party drivers hebben hier last van, omdat die nooit in-kernel zullen werken, en zij hebben hierdoor veel extra werk en kosten en zullen dus toekomstige linux-gerelateerde driver-projecten op een laag pitje houden.

Ikzelf hink op twee gedachten: van mij mogen de kerneldevelopers in hun tijd doen wat ze willen doen en weigeren API's stabiel te houden om wat voor reden dan ook. Aan de andere kant ben ik het helemaal met je eens dat toen ik het dat documentje las, dat het woord drogreden wel het eerste was bij me opkwam.

Ik heb een PVR met MythTV en (non-kernel) ivtv drivers (voor de grabkaarten) en voor X kun je voor het i386 platform zo een binary module/driver downloaden, maar voor de kernel drivers moet je de boel tegen de kernelheaders compileren. Dit weerhoudt een hoop niet-technische mensen om bijvoorbeeld test releases of nightly builds te testen.

vrijdag 14 oktober 2005 08:08

Acties:

vrijdag 14 oktober 2005 16:43

Rukapul schreef op donderdag 13 oktober 2005 @ 23:21:
[...]
Dit weerhoudt een hoop niet-technische mensen om bijvoorbeeld test releases of nightly builds te testen.

Dat is toch net goed? niet-technische mensen moeten sowieso niet met test releases of nightly builds werken. Daar komt toch niets goeds van: mensen gaan klagen dat feature X niet werkt, dat er gekke bugs optreden, dat het niet zo stabiel is als de vorige release etc. , en gaan lopen klagen op mailing lists en forums, zonder dat ze echt weten wat er nu eigenlijk mis is (dus slecht te helpen, omdat ze niet kunnen aangeven waar het probleem zit) en naar alle waarschijnlijkheid zullen ze ook geen bug reports ed doen, dus uiteindelijk leid het de developers alleen maar af.
Een goed voorbeeld hiervan is de NTFS (driver http://linux-ntfs.sourceforge.net/), daar staat:

What is happening?
The developers of NTFS have decided to stop actively develop this website and answering the same, general questions in the help forums. They will continue to fix bugs and develop the NTFS driver, but with fewer distractions. Any significant developments will be announced here.
Why?
Because they don't have the time. There are only three people working on the NTFS driver and they all have other commitments. NTFS is just a hobby for them. Helping beginners use the NTFS driver is a very rewarding, but it is not the best use of their limited free time.

"Man fears the darkness, and so he scrapes away at the edges of it with fire." - Rei Ayanami

Acties:

Verwijderd

Verwijderd schreef op donderdag 13 oktober 2005 @ 22:49:
Dit is precies wat nVidia doet...en gaar dat 't is

En bij elke API verandering in een nieuwe versie gaat 't alsnog kapot en duurt 't soms maanden voordat het weer werkt.

vrijdag 14 oktober 2005 17:58

Acties:

Verwijderd

Verwijderd schreef op vrijdag 14 oktober 2005 @ 16:43:
[...]

En bij elke API verandering in een nieuwe versie gaat 't alsnog kapot en duurt 't soms maanden voordat het weer werkt. .

Precies, die lui van nVidia zijn zo ontzettend sloom met updates van drivers dat je er praktisch niets aan hebt.

vrijdag 14 oktober 2005 19:07

Acties: