Moeten we de linux kernel nog serieus nemen?

maandag 9 juli 2007 15:03

>_<

Kijken naar de FreeBSD kernel (waar toch ook _zeker_ een hoop aan verandert is (eerst lag de focus op SMP, nu volgens mij weer op de network stack)) vind ik in ieder geval dat Linus en kompanen het een stuk minder professioneel aanpakken.

Het hele idee dat een nieuwe kernel "experimenteel" kan zijn vind ik vreemd. Imho is te lang wachten met het uitbrengen van een nieuwe release geen goed idee, maar het zomaar in de wereld gooien van een kernel, ervanuitgaande dat de mainstream deze pas over een half jaar/jaar in gebruik neemt, zodat er nog genoeg tijd is om real-life te debuggen (ala Microsoft) vind ik erg bizar.

Ook zou een _redelijk_ (keyword alert !) stabiele kernel-API (ala *BSD) de kernel ook geen kwaad doen denk ik

Kut ! Ik heb 1337 posts gemist

[ Voor 3% gewijzigd door Jungian op 09-07-2007 14:58 ]

0.0

Acties:

maandag 9 juli 2007 17:18

Moderator LNX

Jungian schreef op maandag 09 juli 2007 @ 14:55:
Kijken naar de FreeBSD kernel (waar toch ook _zeker_ een hoop aan verandert is (eerst lag de focus op SMP, nu volgens mij weer op de network stack)) vind ik in ieder geval dat Linus en kompanen het een stuk minder professioneel aanpakken.

Misschien gaan daardoor de ontwikkelingen wel sneller? Ik weet het niet hoor, ik ken de BSD-kernel(s) niet verder en weet dus ook niet wat ze ondersteunen, maar Linux is toch best een geavanceerd ding op zich.

Het hele idee dat een nieuwe kernel "experimenteel" kan zijn vind ik vreemd. Imho is te lang wachten met het uitbrengen van een nieuwe release geen goed idee, maar het zomaar in de wereld gooien van een kernel, ervanuitgaande dat de mainstream deze pas over een half jaar/jaar in gebruik neemt, zodat er nog genoeg tijd is om real-life te debuggen (ala Microsoft) vind ik erg bizar.

Ik gok dat dat komt doordat de kernel in ZO VEEL verschillende scenario's gebruikt kan worden dat dat onmogelijk te testen is door de ontwikkelaars. Je kunt dan weinig anders dan de kernel releasen als beta en dan mensen laten meetesten. Dat lijkt me een goede zaak.

Ook zou een _redelijk_ (keyword alert !) stabiele kernel-API (ala *BSD) de kernel ook geen kwaad doen denk ik

Euh, ja, hehe dat schijnt nog weleens te veranderen, maar aan de andere kant wil je misschien dat je kernel niet te lang blijft steken op een vroegere beslissing waardoor je niet verder kunt. Ik denk niet dat het zo is omdat ze maar wat aanprutsen.

Saved by the buoyancy of citrus

Acties:

Creepy

Tactical Espionage Splatterer

Keiichi schreef op maandag 09 juli 2007 @ 07:02:
Gisteren was er een nieuwe kernel versie gereleased, 2.6.22

Zoals gebruikelijk kijk ik even in de changelog en zie:

[...]

Kan de linux kernel op zo'n manier als deze nog wel serieus genomen? Ik krijg af en toe de indruk dat ze denken: 'Kan ons het wat schelen of er bugs inzitten, we releasen '

Dit soort geintjes maakt Linus al tijden, dus als je daardoor de Linux kernel niet serieus wilt nemen ga je gang. Wat mij betreft mis je gewoon de humor van Linus.

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney

maandag 9 juli 2007 17:34

Acties:

Renegade

Keiichi schreef op maandag 09 juli 2007 @ 08:51:
Ik vind het vrij jammer dat ik linux niet als een geschik server OS weg kan zetten. Zeker niet als je het gaat meten met FreeBSD, waarvan de kernel volgens mij meer rugged in elkaar zit

Ergens ken ik je gevoel wel degelijk. We werken hier momenteel met een kleine 10.000 linux servers en dat is een gevoel wat bij mij nog regelmatig te vinden is. Aan de andere kant is dat niet iets dat puur en alleen met de kernel van doen heeft, zaken als een fatsoenlijke multipathing ondersteuning is in veel distributies veel te laat geimplementeerd en nog steeds laat dit te wensen over. Het is ook maar net wat voor een keuze je maakt. Een van mijn idealen zou bijvoorbeeld zijn om een eigen instantie van ieder module te kunnen laden. Zo zou je voor HA systemen bij wijzigingen gewoon een instantie van een module kunnen reloaden en hoef je je systeem niet uit te zetten of ben je in een keer alle interfaces kwijt doordat je een module opnieuw moet laden. Dat zal er (vermoed ik) voorlopig niet in zitten, maar dat soort zaken zou ik juist bij een serversysteem wel verwachten.

HAI
CAN HAS STDIO?
VISIBLE "HAI WORLD!"
KTHXBYE
@BasRaayman op twitter

maandag 9 juli 2007 17:47

Acties:

maandag 9 juli 2007 18:31

Keiichi schreef op maandag 09 juli 2007 @ 08:51:
[...]

Ik gebruik al jaren Linux en ben niet zo snel van plan er vanaf te stappen. (ik ga er vanuit dat de windowskernel zowiezo rotter in elkaar zit)

Maar ik heb al enkele keren gehad dat ik soorte van hals-over-kop een kernel moest upgraden vanwege niet leuke bugs. Reiserfs-corruptie in versies t/m 2.6.8 bijvoorbeeld. En verder her en der nog wat kleinere dingen, maar ik kan me niet zo 123 herinneren wat precies

Ik vind het vrij jammer dat ik linux niet als een geschik server OS weg kan zetten

Waarom niet? Je geeft zelf al 2 hele belangrijke punten aan voor als je dat wel doet: nooit reiserfs gebruiken, en niet met alle geweld de laatste subsubrelease van de kernel willen gebruiken (er zijn ook genoeg mensen die niet freebsd X.0 installeren, maar wachten op .1 bijvoorbeeld).

Acties:

maandag 9 juli 2007 21:17

>_<

Cyphax schreef op maandag 09 juli 2007 @ 15:03:
Misschien gaan daardoor de ontwikkelingen wel sneller? Ik weet het niet hoor, ik ken de BSD-kernel(s) niet verder en weet dus ook niet wat ze ondersteunen, maar Linux is toch best een geavanceerd ding op zich.

De ontwikkelingen zullen ongetwijfeld sneller gaan, maar met welke prijs ? De Linux-kernel heeft bijvoorbeeld redelijk vaak te maken met regressies. Software suspend (of het nu to disk of to RAM is) binnen de normale kernel (zonder suspend2-patches) is tragisch. Een compleet gestripte Linux-kernel doet er langer over om z'n routine af te werken dan bijvoorbeeld de GENERIC kernel bij FreeBSD. En zo kan ik nog wat minder ideale dingen opnoemen

.

Hardwareondersteuning (en dan doel ik vooral op wireless internet) is dan weer _wel_ beter dan in *BSD. Linux is ook populairder bij fabrikanten en bedrijven. ALSA vind ik ook iets beter dan de versie van OSS die FreeBSD heeft (totaal niet te vergelijken met de brakke Linux-variant hiervan

).

Elke manier van ontwikkelen heeft z'n voordelen en z'n nadelen. Ik zie liever zelf een kernel die _lang_ getest is, met een zooitje veranderingen, die uitgegeven wordt _na_ langdurige getest te hebben, dan het model wat Linus voor ogen heeft : (redelijk) snel kernel eruit stampen, met per kernel een paar verbeteringen en gigantische hoeveelheden refactoring.

Dat ik niet FreeBSD gebruik atm ligt vooral aan het package management wat me niet aanstaat (ports = $_/-\o_$ , al die kuttooltjes om je packages te managen =

). NetBSD en OpenBSD zijn oude meuk en daar begin ik niet aan op m'n desktop

Ik wacht dus ook in spanning af of Debian GNU/NetBSD, Debian GNU/FreeBSD en Debian/Hurd wat worden.

Ik gok dat dat komt doordat de kernel in ZO VEEL verschillende scenario's gebruikt kan worden dat dat onmogelijk te testen is door de ontwikkelaars. Je kunt dan weinig anders dan de kernel releasen als beta en dan mensen laten meetesten. Dat lijkt me een goede zaak.

Zoals ik hierboven al aangaf vind ik het prettig dat een kernel pas een release krijgt als hij daadwerkelijk klaar en getest is (maar wie ben ik

).

Euh, ja, hehe dat schijnt nog weleens te veranderen, maar aan de andere kant wil je misschien dat je kernel niet te lang blijft steken op een vroegere beslissing waardoor je niet verder kunt.

Nee zeker niet, een beslising genomen in het verleden mag zeker geen effect hebben op de huidige kernel, maar ik begrijp prima dat fabrikanten/devs het hinderlijk vinden als er constant (zoals de laatste tijd) een aanzienklijk deel van de kernel op de schop gaat

blaataaps schreef op maandag 09 juli 2007 @ 17:47:
<knip>nooit reiserfs gebruiken,<knip>

Ik gebruik vrijwel uitsluitend ReiserFS, vanwege de performance en efficiëntie ervan. Ook de journal playback zie ik liever dan een brakke fsck die 10 minuten in beslag neemt

Je moet ook niet vergeten dat er redelijk veel distro's waren die het vroeger als default FS hadden (waarbij er sommige zijn afgehaakt nadat Hans R. in de gevangenis terecht kwam en dat hel en verdoemenis zou betekenen). Zolang je geen oudere kernel gebruikt of een ReiserFS sparse file op een ReiserFS-partitie zet gaat er weinig niets mis (raakt het hoofdvolume corrupt, dan neemt ie de sparse file mee in het fixen -> erg lollig eindresultaat). Dit laatste is gefixed in Reiser4 trouwens

[ Voor 12% gewijzigd door Jungian op 09-07-2007 18:44 ]

0.0

Acties:

Confusion

Fallen from grace

Renegade schreef op maandag 09 juli 2007 @ 17:34:
[..]

Gevallen waarin van multipathing of HA sprake is, zijn natuurlijk maar een klein deel van de gevallen waar een server OS voor ingezet wordt en dan nog zijn er talloze 'traditionele' alternatieven om het gebrek aan ondersteuning op te vangen. Ik betwijfel of herlaadbare modules, by design, er ooit gaan komen.

Wie trösten wir uns, die Mörder aller Mörder?

maandag 9 juli 2007 21:21

Acties:

Verwijderd

In de 0.1 kernel staat ook dat soort onzin (een quote, dit doe ik uit mijn hoofd voor de detailisten):

This is good code, thorvalds fucked it up

Dit ging om de vsprintf() functie in de kernel.

Dus ja het is wel eens lekker om niet serieus te hoeven zijn

maandag 9 juli 2007 21:28

Acties:

maandag 9 juli 2007 22:36

Moderator LNX

Jungian schreef op maandag 09 juli 2007 @ 18:31:
Zoals ik hierboven al aangaf vind ik het prettig dat een kernel pas een release krijgt als hij daadwerkelijk klaar en getest is (maar wie ben ik ).

Je bedoelt een final? De hele releasecycle van Linux is nou gebaseerd op beta-achtige releases, met een final als ie daar klaar voor is, dat vind ik wel een nette manier van werken.

Het is in ieder geval goed te doen als je alleen maar stable kernels wilt, terwijl als je liever wat meer nieuwe features ofzo wilt testen, dat ook gewoon kan.

Nee zeker niet, een beslising genomen in het verleden mag zeker geen effect hebben op de huidige kernel, maar ik begrijp prima dat fabrikanten/devs het hinderlijk vinden als er constant (zoals de laatste tijd) een aanzienklijk deel van de kernel op de schop gaat

Ja en dat kan een heel nadelig effect hebben, namelijk dat hardwarefabrikanten liever geen Linuxdrivers onderhouden. Ik hoop dat wanneer het gebruik van Linux blijft groeien en hardwarefabrikanten liever wel drivers ontwikkelen, een beetje druk wordt uitgeoefend op de kernelontwikkelaars om dat in ieder geval goed te regelen.

Ik gebruik vrijwel uitsluitend ReiserFS, vanwege de performance en efficiëntie ervan. Ook de journal playback zie ik liever dan een brakke fsck die 10 minuten in beslag neemt Je moet ook niet vergeten dat er redelijk veel distro's waren die het vroeger als default FS hadden (waarbij er sommige zijn afgehaakt nadat Hans R. in de gevangenis terecht kwam en dat hel en verdoemenis zou betekenen). Zolang je geen oudere kernel gebruikt of een ReiserFS sparse file op een ReiserFS-partitie zet gaat er weinig niets mis (raakt het hoofdvolume corrupt, dan neemt ie de sparse file mee in het fixen -> erg lollig eindresultaat). Dit laatste is gefixed in Reiser4 trouwens

offtopic:
* Cyphax heeft ook eigenlijk alleen maar goede ervaringen met ReiserFS. Het heeft me ook nog nooit in de steek gelaten. Hopelijk gaat de ontwikkeling aan Reiser4 straks toch door, ook al moet dat misschien zonder Hans.

Saved by the buoyancy of citrus

Acties:

deadinspace

The what goes where now?

Het is sinds een jaar ofzo semi-officieel zo dat vanilla kernels niet meer bedoeld zijn voor eindgebruikers, maar dat het iets is waar distribution vendors verder op kunnen bouwen.

Cyphax schreef op maandag 09 juli 2007 @ 21:28:
Ja en dat kan een heel nadelig effect hebben, namelijk dat hardwarefabrikanten liever geen Linuxdrivers onderhouden.

Hardwarefabrikanten die hun hardware supported willen zien moeten gewoon specificaties geven, zodat hun spullen fatsoenlijk en zonder gezeik out of the box kunnen werken.

Ik hoop dat wanneer het gebruik van Linux blijft groeien en hardwarefabrikanten liever wel drivers ontwikkelen, een beetje druk wordt uitgeoefend op de kernelontwikkelaars om dat in ieder geval goed te regelen.

Ze zijn er keihard tegen, en ik zie dat voorlopig niet veranderen (gelukkig, naar mijn mening). Zoek ook maar eens op 'stable api nonsense' voor de redenering erachter.

maandag 9 juli 2007 23:28

Acties:

dinsdag 10 juli 2007 00:45

Moderator LNX

deadinspace schreef op maandag 09 juli 2007 @ 22:36:
Hardwarefabrikanten die hun hardware supported willen zien moeten gewoon specificaties geven, zodat hun spullen fatsoenlijk en zonder gezeik out of the box kunnen werken.

Dat kunnen ze niet allemaal, niet volledig. Maar sommige fabrikanten (zoals RALink) zijn zo open en anderen doen het aardig met gesloten drivers (nvidia), en dat vind ik ook best. Als er maar fatsoenlijke drivers komen.

Ze zijn er keihard tegen, en ik zie dat voorlopig niet veranderen (gelukkig, naar mijn mening). Zoek ook maar eens op 'stable api nonsense' voor de redenering erachter.

Ze zijn keihard tegen een niet teveel veranderende kernel-API?
Het heeft voor- en nadelen. Voorlopig lijkt voor de meeste hardware toch wel een driver te zijn dus het lijkt niet fout uit te pakken, hopelijk blijft het goedgaan.
Toch zou het fijn zijn als ze ook denken aan de fabrikanten. Je kunt wel een perfecte kernel willen uitbrengen maar als dat resulteert in fabrikanten die er begrijpelijk hun neus voor ophalen (ik bedoel, bij elke release van een nieuwe kernel moet misschien de driver weer aangepast worden, dat kost een hoop tijd) is het de moeite misschien wel niet.
Maar dat lijkt dus nogal mee te vallen vooralsnog.

Saved by the buoyancy of citrus

Acties:

dinsdag 10 juli 2007 10:09

>_<

deadinspace schreef op maandag 09 juli 2007 @ 22:36:
Ze zijn er keihard tegen, en ik zie dat voorlopig niet veranderen (gelukkig, naar mijn mening). Zoek ook maar eens op 'stable api nonsense' voor de redenering erachter.

offtopic:
Ik kijk om de zoveel tijd even op een paar mailinglist en wat me eigenlijk het meeste opvalt is dat Linus over het algemeen een megalomane aars is (

). Meer dan eens loopt een discussie waar hij in verzeilt raakt uit in een flamefest (erg jammer imho).

Hun argumenten zijn hartstikke mooi, maar daar heeft een hardwarefabrikant weinig aan (NDA's zijn uitermate lollig namelijk en bieden geen ruimte voor een open source driver), voor zelfstandige devs is het uitermate hinderlijk, aangezien ze _nergens_ vanuit kunnen gaan en functies binnen de kernel zomaar herschreven worden tussen de verschillende kernelversies (= onnodig (veel) werk).

Cyphax schreef op maandag 09 juli 2007 @ 23:28:
Dat kunnen ze niet allemaal, niet volledig. Maar sommige fabrikanten (zoals RALink) zijn zo open en anderen doen het aardig met gesloten drivers (nvidia), en dat vind ik ook best. Als er maar fatsoenlijke drivers komen.

++
Op andere platformen heb je als consument ook te maken met closed source drivers. Daar hoor je nooit iemand zeiken om een open source driver, simpelweg omdat de closed source driver werkt (en de gemiddelde gebruiker het verstand van een oliebol heeft). Het kan mij aan m'n reet roesten of alle bitjes nu gezegend worden door de paus en daarna handmatig door priesters in assembly ingeramt worden, een stel geeks (al dan niet betaald) een open source driver maakt, of dat ik mezelf moet overleveren aan "de satanisten van deze tijd": de hardwarefabrikanten die een prima closed source driver schrijven.

0.0

Acties:

Arnout

De 2.6.21 kernel scheen nogal slecht gevallen te zijn, ivm met de flinke wijzigingen. Is deze beter wat dat betreft?

[ Voor 16% gewijzigd door Arnout op 10-07-2007 10:14 ]

dinsdag 10 juli 2007 10:20

Acties:

Michael

Als ik naar de release notes van de 2.6.22 kernel kijk dan zie ik een nieuwe slab allocator, wireless stack en firewire stack. Alle 3 niet bepaald onbelangrijke dingen, en om die dan in een point release te vervangen van een 'zogenaamde' stable kernel, vind ik niet bepaald serieus overkomen.

dinsdag 10 juli 2007 11:46

Acties:

Verwijderd

Ik zit wat te neuzen in de 22 specs en ik lag ik een deuk.

Serieus nemen, waarom zou ik alles serieus moeten nemen.

Quote:

Crashing soon a kernel near you

The features are tested in the -mm tree, but be warned, it can crash your machine, eat your data (unlikely but not impossible) or kidnap your family (just because it has never happened it doesn't mean you're safe):

[ Voor 4% gewijzigd door Verwijderd op 11-07-2007 12:50 ]

dinsdag 10 juli 2007 12:31

Acties:

GX

Nee.

Michael schreef op dinsdag 10 juli 2007 @ 10:20:
Als ik naar de release notes van de 2.6.22 kernel kijk dan zie ik een nieuwe slab allocator, wireless stack en firewire stack. Alle 3 niet bepaald onbelangrijke dingen, en om die dan in een point release te vervangen van een 'zogenaamde' stable kernel, vind ik niet bepaald serieus overkomen.

Oeioei, het is een stable, of as-close-as-it-gets.

Wat me persoonlijk weer een hel lijkt zijn de grote wijzigingen in de wireless stacks, die nu vanuit een bedrijf komen die het eventjes doneert, terwijl ik me kan herinneren niet zo heel lang geleden nog m'n ipw2200 drivers zonder vreemd ieee-scripts kon gaan gebruiken.

Ik wacht even af hoe de ipw2200 zich gedraagt onder deze kernel en daarna waag ik het er maar 'ns op. Gelukkig moet eerst .21 nog stable worden in Gentoo

dinsdag 10 juli 2007 12:53

Acties:

Renegade

Confusion schreef op maandag 09 juli 2007 @ 21:17:
Gevallen waarin van multipathing of HA sprake is, zijn natuurlijk maar een klein deel van de gevallen waar een server OS voor ingezet wordt en dan nog zijn er talloze 'traditionele' alternatieven om het gebrek aan ondersteuning op te vangen. Ik betwijfel of herlaadbare modules, by design, er ooit gaan komen.

Nou ja, dat is maar net afhankelijk van hoe je zoiets defineert. Ik ken zelf redelijk wat mensen die als sysadmin werken en bijvoorbeeld mpio gebruiken met behulp van twee raid adapters. Werkt ideaal en redelijk simpel op te zetten. Toegegeven, vaak zit daar niet noodzakelijk een hot-swappable raid controller in maar het idee van redundante paden naar je devices is natuurlijk op van alles en nog wat toe te passen.

En ik ben het met je eens, ook ik zelf denk dat herlaadbare modules er ooit in gaan komen, maar het zou een uitkomst zijn in een aantal situaties waar ik op zich graag linux in zou willen zetten maar het gewoonweg geen alternatief is.

HAI
CAN HAS STDIO?
VISIBLE "HAI WORLD!"
KTHXBYE
@BasRaayman op twitter

dinsdag 10 juli 2007 12:56

Acties:

Keiichi

Topicstarter

Michael schreef op dinsdag 10 juli 2007 @ 10:20:
Als ik naar de release notes van de 2.6.22 kernel kijk dan zie ik een nieuwe slab allocator, wireless stack en firewire stack. Alle 3 niet bepaald onbelangrijke dingen, en om die dan in een point release te vervangen van een 'zogenaamde' stable kernel, vind ik niet bepaald serieus overkomen.

En dan zul je zien dat commercial vendors die zelf hun linux drivers maken, weer een hoop wijzigingen door moeten voeren.

De vmware drivers raken met elke kernel versie ook incompatible. (Gelukkig is er dan iemand die any-to-any patches ervoor uitbrengt) Maar echt bevorderlijk lijkt het me niet als er structueel dingen in de kernel wijzigen.

Solar @ Dongen: http://solar.searchy.net/ - Penpal International: http://ppi.searchy.net/

dinsdag 10 juli 2007 13:21

Acties:

dinsdag 10 juli 2007 14:21

Michael schreef op dinsdag 10 juli 2007 @ 10:20:
Alle 3 niet bepaald onbelangrijke dingen, en om die dan in een point release te vervangen van een 'zogenaamde' stable kernel, vind ik niet bepaald serieus overkomen.

Sinds 2.6 is dat onderscheid tussen 2.oneven en 2.even er tot nader order niet meer. Dingen die vroeger in 2.oneven gebeurden gaan nu in -mm (oid). Zie ook wat deadinspace hierover zegt:

deadinspace schreef op maandag 09 juli 2007 @ 22:36:
Het is sinds een jaar ofzo semi-officieel zo dat vanilla kernels niet meer bedoeld zijn voor eindgebruikers, maar dat het iets is waar distribution vendors verder op kunnen bouwen.

Of met andere woorden: de 2.6.XX.X onderhouden. Die kernels zijn te vergelijken met wat vroeger 'stable' heette. En dat is ook een reden dat Slackware zo lang op 2.4 default is blijven hangen, zij shippen namelijk vanilla.

[ Voor 11% gewijzigd door Jesse op 10-07-2007 13:24 ]

Acties:

dinsdag 10 juli 2007 14:27

>_<

Jesse schreef op dinsdag 10 juli 2007 @ 13:21:
Of met andere woorden: de 2.6.XX.X onderhouden. Die kernels zijn te vergelijken met wat vroeger 'stable' heette.

Een stel kernel-patches vergelijken met een stable slaat op een tang op een varken. Een even getal zou net als vroegâh een stable kernel moeten zijn en niet iets waar maar wat op losgepatched _moet_ worden, omdat het anders geen stable is

Heeft er ook iemand ook meer één idee waarom suspend2 niet opgenomen wordt in de kernel ? Is het omdat de kernel-devs zich (weer eens) superieur voelen en niet hun verlies willen nemen, of zit er iets heel intelligents achter ?

0.0

Acties:

dinsdag 10 juli 2007 14:37

Jungian schreef op dinsdag 10 juli 2007 @ 14:21:
[...]

Een stel kernel-patches vergelijken met een stable slaat op een tang op een varken. Een even getal zou net als vroegâh een stable kernel moeten zijn

Dus als op een gegeven moment dat development-model niet meer werkt omdat niemand de oneven versies test en niemand bugreports stuurt, moet men als een dinosaurus aan dat model blijven vasthangen omdat "een even getal moet stable zijn!"?

Acties:

DataGhost

iPL dev

Ik vraag me af hoeveel mensen hier nu daadwerkelijk de humor van inzien (of ik sla zelf de plank volledig mis), ik zie namelijk iedereen beginnen/doorgaan over experimentele code, bugs, fouten, kwaliteit...

Het eerste wat mij in ieder geval opvalt is "6.22" in de version string en dan krijg ik gelijk flashbacks naar een concurrerend product van een bepaald groot bedrijf

Ik krijg dan ook het gevoel dat hij daarop doelt

dinsdag 10 juli 2007 14:43

Acties:

dinsdag 10 juli 2007 14:52

>_<

blaataaps schreef op dinsdag 10 juli 2007 @ 14:27:
[...]
Dus als op een gegeven moment dat development-model niet meer werkt omdat niemand de oneven versies test en niemand bugreports stuurt, moet men als een dinosaurus aan dat model blijven vasthangen omdat "een even getal moet stable zijn!"?

De kernel wordt weinig getest denk je ?

De Git server maakt _echt_ overuren

En ook al _zou_ de kernel weinig getest worden, is het dan slim om hem gewoon "over de muur heen te gooien" en ervanuit te gaan dat de distro-devs "het wel even fixen" ?

0.0

Acties:

dinsdag 10 juli 2007 14:52

Jungian schreef op dinsdag 10 juli 2007 @ 14:43:
[...]

De kernel wordt weinig getest denk je ? De Git server maakt _echt_ overuren

Nee dat denk ik niet, en die smiley snap ik ook niet helemaal. Misschien moet je even nadenken en http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering lezen voor je in lachen uitbarst. Een van de redenen is dat de oneven versies gewoon te weinig gebruikt werden.

En ook al _zou_ de kernel weinig getest worden, is het dan slim om hem gewoon "over de muur heen te gooien" en ervanuit te gaan dat de distro-devs "het wel even fixen" ?

Zoals deadinspace al zei, de afgelopen tijd is het ontwikkelproces nogal veranderd, en hebben de distrobouwers een taak gekregen (dan wel zelf op zich genomen, veel distro's patchen al heel lang). En waarom zou dat niet slim zijn? Als op manier A de shit niet meer gefixt wordt, is het tijd om over te stappen op manier B die wel werkt.
Het zelf de latest en greatest vanilla kernelsource downloaden van kernel.org en zelf compilen werkt nu minder goed dan "vroegah", maar dat het anders is betekent niet dat het slechter is.

[ Voor 3% gewijzigd door blaataaps op 10-07-2007 14:53 ]

Acties:

dinsdag 10 juli 2007 15:08

Jungian schreef op dinsdag 10 juli 2007 @ 14:43:
[...]

De kernel wordt weinig getest denk je ?

2.5 anyone? Waarom duurde het zo lang voordat 2.6 er kwam? En waarom duurde het zo lang voordat die behoorlijk geadopteerd werd?

De Git server maakt _echt_ overuren

En ook al _zou_ de kernel weinig getest worden, is het dan slim om hem gewoon "over de muur heen te gooien" en ervanuit te gaan dat de distro-devs "het wel even fixen" ?

Dat is wat overdreven bout uitgedrukt. Sinds 2.6 zijn ze gewoon overgestapt naar een ontwikkelscenario wat meer geleidelijk gaat. Ontwikkelingen gaan in -mm e.d. en als ze daar voldoende goed worden bevonden gaan ze naar 2.6.XX. Dat betekend een veel sneller traject van ontwikkelen naar de markt dan vroeger, en voor die foutjes die nu meer dan vroeger in de stable kernel zaten, zijn er de 2.6.XX.X kernels, zodat een distrobouwer toch op een bepaald moment een kernel in een distro kan stoppen die wel onderhouden word maar waarin niet om de haverklap grote dingen worden gewijzigd.

Acties:

dinsdag 10 juli 2007 15:22

>_<

blaataaps schreef op dinsdag 10 juli 2007 @ 14:52:
Nee dat denk ik niet, en die smiley snap ik ook niet helemaal. Misschien moet je even nadenken en http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering lezen voor je in lachen uitbarst. Een van de redenen is dat de oneven versies gewoon te weinig gebruikt werden.

De oneven kernelversies zijn niet eens persé meer nodig, maar het principe achter de even kernels zou wel moeten blijven staan : trek je een kernel van het net af, dan zou je ervanuit moeten kunnen gaan dat deze _perfect_ zonder patches of andere meuk kan draaien. De Git-server worden echt belachelijk vaak gebruikt, dus mogelijkheden genoeg tot testen _voor_ het uitbrengen van de kernel.

Zoals deadinspace al zei, de afgelopen tijd is het ontwikkelproces nogal veranderd, en hebben de distrobouwers een taak gekregen (dan wel zelf op zich genomen, veel distro's patchen al heel lang).

Vrijwel allemaal (allemaal ? ik ken er geen één die _niet_ patched meer tegenwoordig) gooien ze wel een patchset over de kernel heen. Geeft dat niet iets aan vind je ? Zou het wellicht niet slim zijn om een groot deel van die patches in de kernel op te nemen (ervanuitgaande dat bedrijven als Red Hat en distro's als Debian en Ubuntu niet achterlijk zijn) ?

En waarom zou dat niet slim zijn? Als op manier A de shit niet meer gefixt wordt, is het tijd om over te stappen op manier B die wel werkt.

Doe het goed of doe het niet. Om dezelfde reden als dat er een googleplex aan distro's zijn nu : iedereen fixed het anders, of denkt dat ze het beter kunnen. Verspilling van tijd en verspilling van mankracht.

Het zelf de latest en greatest vanilla kernelsource downloaden van kernel.org en zelf compilen werkt nu minder goed dan "vroegah", maar dat het anders is betekent niet dat het slechter is.

Vroeger (en dan is vroeger niet eens zo heel lang terug) kon je ervanuit gaan dat het gewoon werkte (it just works). Tegenwoordig verschijnen er _steeds meer_ patchsets, om (1) ontbrekende functionaliteit toe te voegen (mm en vrienden) of (2) het verbeteren van onderdelen van de kernel (bijv. suspend2). Of je dat iets goed vind moet je zelf je mening over vormen natuurlijk

0.0

Acties:

dinsdag 10 juli 2007 15:25

Jungian schreef op dinsdag 10 juli 2007 @ 15:08:
[...]
Vrijwel allemaal (allemaal ? ik ken er geen één die _niet_ patched meer tegenwoordig) gooien ze wel een patchset over de kernel heen. Geeft dat niet iets aan vind je ? Zou het wellicht niet slim zijn om een groot deel van die patches in de kernel op te nemen (ervanuitgaande dat bedrijven als Red Hat en distro's als Debian en Ubuntu niet achterlijk zijn) ?

Slackware.
De grote distro's patchen ook heel veel upstream en onderhouden daarnaast voor langere duur een kernel in een versie van een distro die zij gereleased hebben.

[...]
Vroeger (en dan is vroeger niet eens zo heel lang terug) kon je ervanuit gaan dat het gewoon werkte (it just works). Tegenwoordig verschijnen er _steeds meer_ patchsets, om (1) ontbrekende functionaliteit toe te voegen (mm en vrienden) of (2) het verbeteren van onderdelen van de kernel (bijv. suspend2). Of je dat iets goed vind moet je zelf je mening over vormen natuurlijk

Al die dingen (dan bedoel ik -mm en consorten) die niet standaard in de kernel zitten, zitten met name niet in de vanilla kernel omdat ze niet voldoende stabiel zijn.
Een 'patch' duidt in die gevallen niet zozeer op een pleister/bugsquasing maar domweg op een stuk code wat vervangen is door een stuk nieuwere code.

[ Voor 5% gewijzigd door Jesse op 10-07-2007 15:23 ]

Acties:

dinsdag 10 juli 2007 15:26

Jungian schreef op dinsdag 10 juli 2007 @ 15:08:
[...]

De oneven kernelversies zijn niet eens persé meer nodig, maar het principe achter de even kernels zou wel moeten blijven staan : trek je een kernel van het net af, dan zou je ervanuit moeten kunnen gaan dat deze _perfect_ zonder patches of andere meuk kan draaien.

Waarom moet dat? Als je een bepaalde versie downloadt zal die wel gewoon werken, maar er was blijkbaar noodzaak het ontwikkelproces wat te veranderen omdat het oude niet meer werkte

De Git-server worden echt belachelijk vaak gebruikt, dus mogelijkheden genoeg tot testen _voor_ het uitbrengen van de kernel.

Dat er genoeg mogelijkheden zijn betekent niet dat genoeg mensen het ook testen, en dat je zo op die Git-server hamert snap ik niet zo.

[...]

Vrijwel allemaal (allemaal ? ik ken er geen één die _niet_ patched meer tegenwoordig) gooien ze wel een patchset over de kernel heen.

Slackware doet volgens mij nog vanilla, maar dat weet ik niet zeker

Geeft dat niet iets aan vind je ? Zou het wellicht niet slim zijn om een groot deel van die patches in de kernel op te nemen (ervanuitgaande dat bedrijven als Red Hat en distro's als Debian en Ubuntu niet achterlijk zijn) ?

Ik neem aan dat een deel van het werk dat door de distro-maintainers gedaan wordt gewoon in de kernel komt.

Doe het goed of doe het niet.

Wat doen ze niet goed dan? Volgens mij gaat het prima, 1x in de zoveel tijd komt er een nieuwe kernel, en een tijdje later zit die in de meeste nieuwe versies van de distributies. Dat jij het niet eens bent met het ontwikkelmodel, taakverdeling of versienummering doet daar niet zoveel aan af.

Om dezelfde reden als dat er een googleplex aan distro's zijn nu : iedereen fixed het anders, of denkt dat ze het beter kunnen. Verspilling van tijd en verspilling van mankracht.

Je bent dus tegen diversiteit, en iedereen moet precies hetzelfde gebruiken, bij voorkeur jouw distro of choice? Dat mensen dingen verschillend op lossen is niet per definitie verspilling.

Vroeger (en dan is vroeger niet eens zo heel lang terug) kon je ervanuit gaan dat het gewoon werkte (it just works).

Tegenwoordig gebruik ik een standaardkernel van mijn distributie en "it just works"

Tegenwoordig verschijnen er _steeds meer_ patchsets, om (1) ontbrekende functionaliteit toe te voegen (mm en vrienden) of (2) het verbeteren van onderdelen van de kernel (bijv. suspend2). Of je dat iets goed vind moet je zelf je mening over vormen natuurlijk

Vroeger moest ik altijd als ik debian of een andere distro installeerde allerlei toeren uithalen en kernels compilen om hele gewone dingen werkend te krijgen. Tegenwoordig installeer ik een distributie, en bijna alles werkt gewoon. Ik ben blij (en velen om mij heen met mij) dat ik niks meer van kernel.org hoef te downloaden en zelf klooien met het compilen van kernels.

Acties:

Falcon

DevOps/Q.A. Engineer

Hoe groot (in aantal MB's) is de kernel nu eigenlijk van Linux? /tussendoorvraagmodus

"We never grow up. We just learn how to act in public" - "Dyslexie is a bitch"

dinsdag 10 juli 2007 15:28

Acties:

dinsdag 10 juli 2007 15:30

Falcon schreef op dinsdag 10 juli 2007 @ 15:26:
Hoe groot (in aantal MB's) is de kernel nu eigenlijk van Linux? /tussendoorvraagmodus

Zie http://kernel.org/pub/linux/kernel/v2.6/

code:

1	linux-2.6.22.tar.bz2 08-Jul-2007 23:48 43M

Zal uitgepakt nog wel wat meer wezen.

[ Voor 5% gewijzigd door Jesse op 10-07-2007 15:29 ]

Acties:

dinsdag 10 juli 2007 15:47

>_<

Jesse schreef op dinsdag 10 juli 2007 @ 15:22:
Slackware.

Ik had eigenlijk weinig anders kunnen verwachten van de anti-bloat

Al die dingen (dan bedoel ik -mm en consorten) die niet standaard in de kernel zitten, zitten met name niet in de vanilla kernel omdat ze niet voldoende stabiel zijn.
Een 'patch' duidt in die gevallen niet zozeer op een pleister/bugsquasing maar domweg op een stuk code wat vervangen is door een stuk nieuwere code.

Ik weet precies wat die patchsets doen, aangezien ik ze zelf ook gebruik en zolang ze m'n ReiserFS-partities niet laten ontploffen vind ik het prima

Maar ik ben hopelijk niet de enige die het ook maar een klein beetje vreemd vind dat er zoveel patchsets die allemaal zoveel verschillende dingen willen veranderen ? Het mooie van Linux (en alle andere open source software) is dat je er dingen aan kunt veranderen, maar de hoeveelheid patchsets die bijvoorbeeld een alternatieve scheduler aanbieden rijzen de pan uit. En één van de beste patchsets op dat gebied (ck) is eigenlijk nooit een optie geweest om opgenomen te worden in de mainstream kernel, terwijl het toch echt een mooi stuk programmeren was

blaataaps schreef op dinsdag 10 juli 2007 @ 15:25:
Dat er genoeg mogelijkheden zijn betekent niet dat genoeg mensen het ook testen, en dat je zo op die Git-server hamert snap ik niet zo.

Een hele sloot bugfixes komt binnen dankzij de mensen die de Git-releases gebruiken. De Git-server zou (imho) dus eigenlijk nog een iets prominentere rol in moeten nemen om alles ideaal te laten verlopen.

Het idee van een Debian stable release (of FreeBSD kernel) dus : lever het pas af als je praktisch zeker weet dat er nog weinig fouten inzitten. De Git server zou hier dus een grote rol in kunnen spelen.

Je bent dus tegen diversiteit, en iedereen moet precies hetzelfde gebruiken, bij voorkeur jouw distro of choice? Dat mensen dingen verschillend op lossen is niet per definitie verspilling.

offtopic:
Ik heb geen distro of choice meer, aangezien alle distro's wel een zwak punt hebben (maar dat even terzijde).

Vergelijk het met rupsbanden en standaard ronde autobanden : je kunt wel eigenzinnig zijn en je Porsche modden om rupsbanden te kunnen gebruiken, maar je zou ook de standaard ronde autobanden kunnen nemen. Oftewel : als iets efficiënt kan worden opgelost _zou_ het ook zo opgelost moeten worden imho, maar blijkbaar kiezen er veel mensen liever voor chaos.

Vroeger moest ik altijd als ik debian of een andere distro installeerde allerlei toeren uithalen en kernels compilen om hele gewone dingen werkend te krijgen.

Zoals ? En hebben we het hier over een 2.x kernel ?
* Jungian zou nog steeds een keer tijd willen vrijmaken om een 1.x kernel te testen

[ Voor 40% gewijzigd door Jungian op 10-07-2007 15:55 ]

0.0

Acties:

Verwijderd

Ieder bedrijf heeft zijn eigen filosofie over wat ze met een kernel willen bereiken. Dan is het wel handig dat je een basis kernel als vanilla hebt waar alleen de broodnodige dingen in aangepast worden.

Ik heb in een interview op TLLTS met een Novell medewerker gehoord dat de kernel van OpenSuSE iets van 500 patches heeft. De SLED kernel meer dan 2000. Dan wil ik wel eens weten hoeveel RedHat er wel niet heeft aangezien dat volledig Enterprise gebaseert is.

En trouwens, keuze is toch fijn? Mijn systeem zal heus niet crashen met alleen een vanilla-kernel. Wil ik iets meer om te testen dan pak ik een MM, CK of een van de kernels die op de gentoo-forums rondslingeren. Open Source is all about choice.

dinsdag 10 juli 2007 16:08

Acties:

dinsdag 10 juli 2007 16:09

Verwijderd schreef op dinsdag 10 juli 2007 @ 15:47:
*knip*
aangezien dat volledig Enterprise gebaseert is.
*knip*

Wat is dat nou weer voor iets

[ Voor 3% gewijzigd door Jesse op 10-07-2007 16:08 ]

Acties:

Verwijderd

Jesse schreef op dinsdag 10 juli 2007 @ 16:08:
[...]

Wat is dat nou weer voor iets

Voor servers in bedrijven. Niet de starship Enterprise

dinsdag 10 juli 2007 16:15

Acties:

dinsdag 10 juli 2007 16:52

Verwijderd schreef op dinsdag 10 juli 2007 @ 16:09:
[...]

Voor servers in bedrijven. Niet de starship Enterprise

offtopic:
Ehe. Wat is wat dat betreft het verschil met SLES? Hoe kan iets enterprise _gebaseerd_ zijn? En hoezo zouden er meer patches nodig zijn als het _enterprise gebaseerd_ is?

[ Voor 12% gewijzigd door Jesse op 10-07-2007 16:16 ]

Acties:

Verwijderd

Ik draai al aardig lang zelf gebakken kernels (oftewel vanilla). Ik moet zeggen dat sommige aanpassingen inderdaad niet heel erg fijn soms zijn. Met name de veranderingen zijn soms iets wat extreem. Laatst nog, upgrade kernel 2.6.19 naar 2.6.20 en toen had de netfilter team maar even gekozen om hun modules allemaal te hernoemen!

Grrrr

Dus kwam er ineens achter dat ik dus kernel opnieuw weer mocht compilen, want mijn iptables werkte totaal niet meer. Zo zijn er nog wel meerdere voorbeelden op te noemen, zoals ineens een beschadigde ext3 partitie ineens, na 5 dagen uptime pas. Dus dat soort problemen zijn moeilijk te achterhalen.

Echter moet ik wel zeggen dat ik zwaar respect heb voor de mensen die allemaal aan de kernel werken. Als je namelijk eens in de code duikt, en de mailing lijsten eens in de gaten houd, dan zie je wel dat het gelukkig heel actief is, en dat bij grote fouten het super snel word opgelost.

Oftewel, blij ben ik wel met de nieuwe release, alleen wacht ik altijd op de nieuwste release, en draai ik de ena laatste. Dus nu is dat 2.6.21.6. Deze werkt prima, onlangs de vele veranderingen.

Oftewel, ik neem de kernel zeer serieus, aangezien ik ook wel eens een debug naar ze stuur bij grote problemen, en dat word vrijwel zelfde dag, als volgende dag dan al opgelost

.

Noem mij eens een community die zo snel ook is (en dan os based).

dinsdag 10 juli 2007 19:13

Acties:

deadinspace

The what goes where now?

Cyphax schreef op maandag 09 juli 2007 @ 23:28:
Ze zijn keihard tegen een niet teveel veranderende kernel-API?

Ze zijn keihard tegen het vastleggen van een interne API, omdat ze een niet optimale API per direct willen kunnen veranderen zonder de oude nog te supporten. Een interne ABI (wat eigenlijk nodig zou zijn voor closed source drivers) is nog erger (en om praktische redenen nog vervelender).

Voorlopig lijkt voor de meeste hardware toch wel een driver te zijn dus het lijkt niet fout uit te pakken

Ja, en weet je waarom dat is? Omdat die mensen staan op open source drivers in de mainline kernel. Niet omdat het "toevallig wel goed gegaan is".

Toch zou het fijn zijn als ze ook denken aan de fabrikanten.

Ze denken ook aan de fabrikanten... Die fabrikanten hoeven niet eens een driver te schrijven, het enige wat ze hoeven te doen is kenbaar maken hoe hun hardware aangestuurd moet worden.

Jungian schreef op dinsdag 10 juli 2007 @ 00:45:
[ot]Ik kijk om de zoveel tijd even op een paar mailinglist en wat me eigenlijk het meeste opvalt is dat Linus over het algemeen een megalomane aars is ().

Linus kan knap bot uit de hoek komen ja

Maar voorzover ik gezien heb oordeelt hij voornamelijk op technische criteria, waarin de geschiedenis heeft laten zien dat hij het vaak bij het rechte eind heeft. En als hij zich vergist, dan kan hij dat ook toegeven. De botheid moet je gewoon niet teveel op letten

Hun argumenten zijn hartstikke mooi, maar daar heeft een hardwarefabrikant weinig aan (NDA's zijn uitermate lollig namelijk en bieden geen ruimte voor een open source driver)

Ik heb van de fabrikanten die de chips ontwerpen (en dus doorgaans niet door NDA's gebonden zijn) nog nooit een goede reden gezien om geen specs vrij te geven.

Als een hardwarefabrikant een chip gebruikt waarvan ze de specs onder NDA krijgen, dan is dat inderdaad vervelend. Ikzelf heb er overigens weinig boodschap aan; willen ze mijn klandizie, dan kiezen ze maar een andere chip.

Maar de fabrikanten die deze chips ontwerpen en maken hebben over het algemeen geen fatsoenlijke reden om die specs niet vrij te geven. Ze willen dat hun chips gebruikt worden... Vertel dan ook hoe.

Op andere platformen heb je als consument ook te maken met closed source drivers. Daar hoor je nooit iemand zeiken om een open source driver, simpelweg omdat de closed source driver werkt

Grapje zeker?

Wat dan van al die hardware waar voor Windows Vista een nieuwe driver nodig is en de fabrikant te lam is om die te maken? Dat geldt voorlopig nog voor een aardige hoeveelheid printers bijvoorbeeld. Voor de meeste apparaten zal het uiteindelijk wel goed komen, maar als de fabrikant besluit dat een apparaat te oud is om nog drivers voor te updaten, dan heb je pech. Of zie Creative, die $9.99 vragen voor de Vista drivers van sommige van hun geluidskaarten...

Binary drivers werken ook alleen maar voor het OS en het platform waarvoor ze gemaakt zijn. Een Windows driver? Sja, jammer voor Mac OS X, GNU/Linux en FreeBSD gebruikers. Een Linux/x86 driver? Pech voor FreeBSD en Linux/ppc. Als er specs zijn, dan kunnen gebruikers van die OSsen tenminste zelf een driver proberen te maken.

En zelfs al is er een driver, dan nog werken die vaak niet bijster goed. ATi bijvoorbeeld stond jarenlang bekend om zijn brakke drivers, en de meeste crashes onder Windows worden verweten aan driverproblemen.

Michael schreef op dinsdag 10 juli 2007 @ 10:20:
Als ik naar de release notes van de 2.6.22 kernel kijk dan zie ik een nieuwe slab allocator, wireless stack en firewire stack. Alle 3 niet bepaald onbelangrijke dingen, en om die dan in een point release te vervangen van een 'zogenaamde' stable kernel, vind ik niet bepaald serieus overkomen.

Ja, maar blijkbaar zijn die dingen nodig (of bieden ze iig genoeg voordeel), en dus moeten ze er toch ooit in. En het oude model van 2.oneven is development en 2.even is productie werkte niet goed meer. Er kwamen veel te veel veranderingen in 2.oneven, waardoor het testen te lang duurde, waardoor er weer meer veranderingen werden opgenomen, etc.

Dus wat dan te doen?

Jungian schreef op dinsdag 10 juli 2007 @ 15:08:
Vrijwel allemaal (allemaal ? ik ken er geen één die _niet_ patched meer tegenwoordig) gooien ze wel een patchset over de kernel heen. Geeft dat niet iets aan vind je ? Zou het wellicht niet slim zijn om een groot deel van die patches in de kernel op te nemen?

Distributies pushen die patches ook upstream naar de kernel. Sommigen komen er dan in, sommigen (om verscheidene redenen) niet. Degene die opgenomen worden hoeven volgende keer niet gepatcht te worden, de anderen (voorlopig) nog wel. En uiteraard zijn er bij een nieuwe kernel weer nieuwe dingen te patchen.

Vroeger (en dan is vroeger niet eens zo heel lang terug) kon je ervanuit gaan dat het gewoon werkte (it just works).

Maar vroeger waren de distro kernels niet zo top, en was het dus hip je eigen kernel te compilen. Tegenwoordig zijn de distro kernels uitstekend en voldoen deze vrijwel altijd. Tijden veranderen.

Tegenwoordig verschijnen er _steeds meer_ patchsets, om (1) ontbrekende functionaliteit toe te voegen (mm en vrienden)

-mm is niet om functionaliteit toe te voegen, -mm is om nieuwe functionaliteit te testen.

Falcon schreef op dinsdag 10 juli 2007 @ 15:26:
Hoe groot (in aantal MB's) is de kernel nu eigenlijk van Linux? /tussendoorvraagmodus

Zoals Jesse al antwoordde is 2.6.22 ongeveer 43 MB compressed source. Uncompressed source is iets van 251 MB.

Maar ik weet niet of je de grootte van de sources wilde weten, of de grootte van de executables? Op mijn systeem (Debian stock kernel, 2.6.18) is de kernel zelf 1.3 MB, en alle modules bij elkaar (waarvan maar een klein deel geladen is) 43 MB.

Ik snap overigens prima dat het model van development tree waar alle ontwikkeling gebeurt / production tree waar weinig veranderingen plaatsvinden aantrekkelijk klinkt, en dat het een fijn idee is dat je zelf een kernel.org kernel kan downloaden en compilen voor je systeem en dat dan alles werkt.

Maar de realiteit is gewoon dat dit model niet geschikt is voor het enorme tempo aan veranderingen waaraan de Linux kernel tegenwoordig onderhevig is.

dinsdag 10 juli 2007 19:35

Acties:

dinsdag 10 juli 2007 19:57

>_<

deadinspace schreef op dinsdag 10 juli 2007 @ 19:13:
Grapje zeker?

(let op ! cliché !) Nee, niet echt

Wat dan van al die hardware waar voor Windows Vista een nieuwe driver nodig is en de fabrikant te lam is om die te maken?<knip>

Daar hadden wij het volgens mij helemaal niet over

. Als er een closed source driver die _wel_ goed werkt, heb ik geen behoefte aan een open source driver. Doneren aan Nouveau vind ik dan ook waanzin, aangezien de closed source Nvidia-driver het prima doet. Een open source driver voor Nvidia-kaarten op het Windows-platform hoef ik ook niet eens 2 seconden over na te denken.

Mocht Nvidia besluiten mijn kaart niet meer te ondersteunen, dan koop ik de goedkoopste variant van de nieuwste serie en kan ik weer _jaren_ vooruit.

En zelfs al is er een driver, dan nog werken die vaak niet bijster goed. ATi bijvoorbeeld stond jarenlang bekend om zijn brakke drivers, en de meeste crashes onder Windows worden verweten aan driverproblemen.

Ik heb anders weinig problemen gehad met mijn Nvidia-kaarten op Linux, FreeBSD en Windows. Totaal niet te vergelijken met Ati, die consistent op elk platform meuk aflevert.

* Jungian sluit zich aan bij Cyphax (hieronder)

[ Voor 51% gewijzigd door Jungian op 10-07-2007 20:15 . Reden: tweakerdetweak ]

0.0

Acties: