[Slackware 10] na kernel upgrade usb errors

[anoniem]

[quote:928a60914d="danieldk"]Waarom gebruiken mensen in hemelsnaam al 2.6.x? Het duurt wel weer tot .18 voordat dat stabiel is.[/quote:928a60914d] Nieuw = lekker :P De enige 2.6 die niet goed werkte was de 2.6.9 met ck-patch. Ik heb sinds het weekend 2.6.10-rc1, en kwam tot de ontdekking dat ACPI weer werkt op mijn P3 (bij de eerste kernels werd er gezeurd dat mijn ACPI-versie was verouderd) en binnenkort ga ik eens kijken of soft-suspend werkt. (je pc afsluiten, waarbij het geheugen wordt weggeschreven naar je swap-partitie, zodat je heel snel kunt booten en verder gaan waar je gebleven was).

[anoniem]

Hmm muis aan andere USB poorten helpt ook niet. ( hij zegt nu hetzelfde alleen nu op poort 3 ). Vanavond eens versie 2.6.7 proberen te bakken...

[anoniem]

[quote:d6ac034e9d="Bamboe"]""regression testing"? What's that? If it compiles, it is good, if it boots up it is perfect." - Linus Torvalds[/quote:d6ac034e9d] Ernstig.

[anoniem]

Inderdaad ernstig Daniel. Die gasten van het kernel-team zijn volgens mij helemaal de weg kwijt. En als klap op de vuurpijl willen ze eerdaags met twee kernels gaan werken :-? http://www.techworld.com/opsys/news/index.cfm?NewsID=2648&Page=1&pagePos=2

[anoniem]

Ik denk niet dat hij dat ernstig meende. De uitspraak is ook al erg oud (1998, zie ook http://www.ussg.iu.edu/hypermail/linux/kernel/9804.1/0149.html ) Ik dacht dat de kernel toch vrij grondig getest wordt voor er een nieuwe release gemaakt wordt, maar het zou inderdaad nog beter kunnen. Bedenk wel dat het volledig testen van een stuk software in principe onmogelijk is. Tests kunnen enkel aantonen dat er fouten in een stuk software zitten, maar niet dat er geen fouten meer zijn. En bij de kernel is dat nog eens extra moeilijk, o.a. omdat de werking van de kernel sterk afhangt van de hardware waarop hij draait.

[anoniem]

En wat de "forking" betreft: is dat niet de traditionele manier van de kernel te ontwikkelen? Ze hebben wel geprobeerd om de fork naar 2.7 zo lang mogelijk uit te stellen, onder het mom dat de -mm branch voor experimentele dingen dient en dat, wanneer die dingen gestabiliseerd zijn, ze vrij snel in de stabiele 2.6 kernel gemerged kunnen worden. Ik denk dat ze nu tot het inzicht beginnen te komen dat deze manier niet praktisch haalbaar is, want zoals de meesten wel merken is de 2.6 reeks nog niet echt aan het stabiliseren (zowel qua ontwikkeling als qua werking). Het nadeel van een fork is dat het langer duurt eer dat nieuwe drivers, features, ... in de stabiele kernel terecht komen, en er sowieso meer werk in backporting zal moeten gestoken worden om die features/drivers er toch in te krijgen. Maar ik blijf toch geloven dat dat de beste manier van werken is. Ook de BSD's worden op die manier ontwikkeld, niet?

[anoniem]

Inderdaad, volgens mij staat er in dat artikel niets anders dan dat Morton binnenkort graag de 2.7 development branch van start wil laten gaan. Als ik het mis heb hoor ik het graag, maar de nieuwsberichten van NedLinux.nl zijn ronduit belabberd (zeer slordig) de laatste tijd. Die uitspraak van Linus is ook heel bekend en dus al tamelijk oud, waarom er sprake is van een development team de weg kwijt zou zijn snap ik dan ook niet. Ook moet je een dergelijke uitspraak altijd in de context zien, wellicht is dit een jolig antwoord op een jolige vraag in een onserieus interview geweest. Ik kan me niet voorstellen dat dit Linus zijn serieuze mening is en ik denk niemand hier.

[anoniem]

[quote:fb125ea3f4="Bamboe"]Bedenk wel dat het volledig testen van een stuk software in principe onmogelijk is. Tests kunnen enkel aantonen dat er fouten in een stuk software zitten, maar niet dat er geen fouten meer zijn.[/quote:fb125ea3f4] True, maar je kunt wel in vrij grote mate testen. Je kunt stukken code testen met testsuites, die functies testen onder veel omstandigheden, en kijken of deze overeenkomen met de resultaten die het zou moeten geven. Op die manier worden ook veel libraries getest. [quote:fb125ea3f4]En bij de kernel is dat nog eens extra moeilijk, o.a. omdat de werking van de kernel sterk afhangt van de hardware waarop hij draait.[/quote:fb125ea3f4] Ja en nee. Voor de kernel als geheel geldt dat wel, maar de memory manager, scheduler, TCP/IP stack, etc. zijn goed hardwareonafhankelijk te testen. En zelfs die onderdelen hebben vaak nog problemen/bugs, of situaties waarin ze niet optimaal presteren...

[anoniem]

[quote:37c8b24026="Marcel de Reus"]Inderdaad, volgens mij staat er in dat artikel niets anders dan dat Morton binnenkort graag de 2.7 development branch van start wil laten gaan. Als ik het mis heb hoor ik het graag, maar de nieuwsberichten van NedLinux.nl zijn ronduit belabberd (zeer slordig) de laatste tijd.[/quote:37c8b24026] Ja, net als men ging claimen dat Microsoft bezig is op dit moment alle gangbare internetprotocollen zat te patenteren. Je kunt wel op drie vingers natellen dat Microsoft wel zou zien dat dat zinloos is. Maar in het NedLinux nieuws kan het wel. Er is helemaal geen fork in traditionele zin, maar de gewoonlijke procedure die (vrijwel?) altijd gevolgd wordt. [quote:37c8b24026]Die uitspraak van Linus is ook heel bekend en dus al tamelijk oud, waarom er sprake is van een development team de weg kwijt zou zijn snap ik dan ook niet.[/quote:37c8b24026] De uitspraak van Linus was duidelijk enigszins cynisch/sarcastisch. Voor zover het te denken geeft is het waarschijnlijk voornamelijk reflexief. Ik had achter m'n "Ernstig" een smiley moeten zetten, maar ik verwachtte dat iedereen wel de toon mee zou krijgen ;).

[anoniem]

[quote:dbf73aa71e="danieldk"][quote:dbf73aa71e="Bamboe"]Bedenk wel dat het volledig testen van een stuk software in principe onmogelijk is. Tests kunnen enkel aantonen dat er fouten in een stuk software zitten, maar niet dat er geen fouten meer zijn.[/quote:dbf73aa71e] True, maar je kunt wel in vrij grote mate testen. Je kunt stukken code testen met testsuites, die functies testen onder veel omstandigheden, en kijken of deze overeenkomen met de resultaten die het zou moeten geven. Op die manier worden ook veel libraries getest. [/quote:dbf73aa71e] Inderdaad, en ik vermoed dat ze met de kernel wel soortgelijke tests doen. [quote:dbf73aa71e] [quote:dbf73aa71e]En bij de kernel is dat nog eens extra moeilijk, o.a. omdat de werking van de kernel sterk afhangt van de hardware waarop hij draait.[/quote:dbf73aa71e] Ja en nee. Voor de kernel als geheel geldt dat wel, maar de memory manager, scheduler, TCP/IP stack, etc. zijn goed hardwareonafhankelijk te testen. En zelfs die onderdelen hebben vaak nog problemen/bugs, of situaties waarin ze niet optimaal presteren...[/quote:dbf73aa71e] Mmm, toch niet helemaal waar: de scheduler is sterk afhankelijk van de snelheid van de hardware componenten. Het kan bv. zijn dat een potentiele lockup zich nooit voordoet omdat toevallig de harde schijfcontroller net op tijd klaar is met een bepaalde operatie. (terwijl het theoretisch gezien zou kunnen vastlopen als de hd controller wat trager zou zijn)

[anoniem]

[quote:76c65d4b83="danieldk"] [quote:76c65d4b83]Die uitspraak van Linus is ook heel bekend en dus al tamelijk oud, waarom er sprake is van een development team de weg kwijt zou zijn snap ik dan ook niet.[/quote:76c65d4b83] De uitspraak van Linus was duidelijk enigszins cynisch/sarcastisch. Voor zover het te denken geeft is het waarschijnlijk voornamelijk reflexief. Ik had achter m'n "Ernstig" een smiley moeten zetten, maar ik verwachtte dat iedereen wel de toon mee zou krijgen ;).[/quote:76c65d4b83] Hmja, eigenlijk wel, ik nam het toch ook wel serieus (aangezien jij al wel eens afgeeft op de linux ontwikkeling, vooral in vergelijking met BSD's)

[anoniem]

Nou ja de ontwikkeling van de NedSlack cd mag je ook niet optimaal noemen :lol: p.s no offence daniel ;)

[anoniem]

[quote:6574e87e08="w.roosenburg"]Nou ja de ontwikkeling van de NedSlack cd mag je ook niet optimaal noemen :lol: [/quote:6574e87e08] Dat was in de goede oude tijd dat een groot deel van de bevolking nog geen vreetband had ;).

[anoniem]

[quote:a20c02c4cb="Bamboe"] Mmm, toch niet helemaal waar: de scheduler is sterk afhankelijk van de snelheid van de hardware componenten. Het kan bv. zijn dat een potentiele lockup zich nooit voordoet omdat toevallig de harde schijfcontroller net op tijd klaar is met een bepaalde operatie.[/quote:a20c02c4cb] Daarom test je bij verschillende (theoretische) procestijden en I/O blocking tijden. Ik zie niet hoe je daar hardware voor nodig hebt. Uiteindelijk komt veel neer op algoritmetesten.