Kernel 2.6.x draadje

[a casema user]

2.6.15 is uit !
Changelog
Patch vanaf 2.6.14
Patch vanaf 2.6.14-rc3

[richardt]

Voor degenen die een pvr-150 kaart draaien met de ivtv sources en gebruik willen maken van de 2.6.15 kernel: De ondersteunde audio en video modules (saa*, tuner, cx25840 etc) zitten tegenwoordig in de mainstream 2.6.15 kernel (ben overgestapt van 2.6.13 naar .15, weet niet of dat bij 2.6.14 ook al zo was...?).

Jammer genoeg worden deze modules niet meer automatisch meegebouwd als je video4linux aan hebt staan. Oplossingen zijn bijvoorbeeld
1) meeconfiguren van bijvoorbeeld BT848 support...
2) aanpassen van drivers/media/video/Makefile

ivtv, versie 0.4.1 werkt goed met deze kernel.

[Wirf]

a casema user schreef op dinsdag 03 januari 2006 @ 12:11:
2.6.15 is uit !
[..]
Patch vanaf 2.6.14-rc3

Je linkt naar patch-2.4.32-rc3-final.bz2 weet je zeker dat dit klopt?

Kan iemand me ook vertellen hoe ik van 2.6.14.5 naar 2.6.15 moet? of moet ik dan eerst alle incrementele patches reversen? (zodat je op 2.6.14 komt?)

[Creepy]

De patch naar 2.6.15 is vanaf 2.6.14. Je zult dus de stable pachtes inderdaad moeten reversen.

[BoAC]

Waarom niet gewoon de complete kernel ophalen?
* BoAC kan en niet vinden op kernel.org

Eindelijk support voor DMA voor de ide-controller van via: vt8251

[Wirf]

BoAC schreef op woensdag 04 januari 2006 @ 11:24:
Waarom niet gewoon de complete kernel ophalen?

Omdate de complete kernel overhalen nogal groot is (35 MB ofzo) t.o.v. een patch van 5-6 MB. Verder is de compile sneller als je alleen patcht, dan worden alleen de veranderde bestanden opnieuw gecompiled.

* BoAC kan en niet vinden op kernel.org

Heb je al op de FTP server zelf gekeken? ftp://ftp.nl.kernel.org/pub/linux/kernel/v2.6/

[MikeN]

Iemand enig idee hoe het gaat met 2.6.15 en distro's die niet helemaal up-to-date zijn en dus een udev versie hebben die wat achter loopt?

quote: http://wiki.kernelnewbies.org/LinuxChanges

Driver Core: add the ability for class_device structures to be nested: Allows struct class_device to be nested, so that another struct class_device can be the parent of a new one, instead of only having the struct class be the parent (commit) and add uevent sysfs attribute to re-emit device hotplug events (commit). Also, introduce struct platform_driver (allows the platform device driver methods to be passed a platform_device structure instead of instead of a plain device structure, and therefore requiring casting in every platform driver) (commit). Due to some of those changes, only udev versions 071 or higher will be able to run in 2.6.15.

[Borromini]

I had net nog gelezen dat iemand udev 064 gebruikte en zonder problemen met kernel 2.6.15 werkte... Misschien dat het varieert van geval tot geval?

[MikeN]

Ik lees verschillende verhalen op internet. Bij de 1 wil het hele systeem niet meer booten, de ander heeft nergens last van en weer een ander heeft alleen problemen bij custom udev rules. Maar ik wil even zeker weten hoe de vork in de steel zit, en kan tot nu toe eigenlijk niet vinden hoe het nou écht zit.

[irondog]

Gewoon udev upgraden anders is de werking van udev naar de klote en de werking van je systeem misschien ook. Is toch niet zo moeilijk of wel?

[Zwerver]

irondog schreef op maandag 09 januari 2006 @ 10:05:
Gewoon udev upgraden anders is de werking van udev naar de klote en de werking van je systeem misschien ook. Is toch niet zo moeilijk of wel?

Bewijs daarvan heb je neem ik aan voor je neus liggen? Of flame je altijd voor de lol mensen af

[irondog]

Zwerver schreef op maandag 09 januari 2006 @ 11:26:
Bewijs daarvan heb je neem ik aan voor je neus liggen?

Ik heb hier geen systeem dat hulpeloos kapot gaat zonder udev. Dus nee. Dat udev op sommige systemen geen kritieke rol speelt wil nog niet zeggen dat je combo 2.6.15 + udev 0.61 goed functioneert.

Ik geloof sowieso niet dat hier echt veel mensen zitten die een (half-)kapotte udev van een volledig werkende kunnen onderscheiden.

Of flame je altijd voor de lol mensen af

Er wordt gewoon een of andere roddel geponeert en de rest mag uitzoeken of dat echt waar is.
Verder mijn excuses voor mijn lompigheid. Bij sommige distro's zal het updaten van udev misschien iets lastiger zijn dan bij de andere.

De mensen achter de kernel/udev zeggen gewoon dat je udev >=0.71 moet gebruiken. De geplaatste quote komt rechtstreeks van de ontwerpers af. Dus op kritieke systemen met een oude udev moet je zeker niet klakkeloos gaan updaten naar 2.6.15
Mijn tip: upgrade naar 2.6.15, dan ook naar udev>= 0.71.

[Borromini]

Of upgrade gewoon niet... Tenzij je 2.6.15 echt nodig hebt.

[MikeN]

"Gewoon udev upgraden" is misschien leuk voor thuissysteempjes, maar dan kan ik net zogoed Debian unstable draaien ofzo. Het is overigens geen roddel maar gewoon iets wat meerdere malen naar voren gekomen is op diverse mailinglists, ook van kernel maintainers zelf. Er is ook een hele discussie geweest (of die wordt nu nog gevoerd) over de noodzakelijkheid van compatibiliteit van de verschillende kernels met dezelfde userspace apps.

Uiteraard is niet upgraden ook een optie, echter komen er regelmatig fixes in de kernel voor die ik _wel_ wil hebben en die niet zo 1,2,3 te backporten zijn. Op dit moment is dat nog niet het geval, maar wie garandeerd me dat dat het komende half jaar/jaar zo zal blijven. Tegen die tijd wil ik graag weten of dat upgraden enigzins gaat lukken of dat ik beter kan kijken naar distro's zonder udev of manieren om udev te strippen. Hotplug support is verder niet nodig, maar dingen als het aanmaken van de device nodes bij boot moet wel werken natuurlijk.

[slager]

De ontwikkeling gaat verder, de eerste releasecandidate voor 2.6.16 is er, 2.6.16-rc1:
Changelog
Patch vanaf 2.6.15

Verder is er ook een nieuwe versie van de stabiele release, 2.6.15.1:
Changelog
Patch vanaf 2.6.15

[a casema user]

2.6.15.2
Changelog
Patch vanaf 2.6.15.1
Patch vanaf 2.6.15

[a casema user]

2.6.16-rc2
Changelog
Patch vanaf 2.6.15
Patch vanaf 2.6.16-rc1

[Olaf van der Spek]

Zijn er eigenlijk nog 'grote' plannen voor de kernel?

[webfreakz.nl]

Geen idee, maar er is ook geen roadmap te vinden voor de kernel?

En even een vraag tussendoor; moet de kernel nou weer herschreven worden voor versie 3.x.x? Dit was toch ook gedaan voor 2.x.x?

[BoAC]

OlafvdSpek schreef op vrijdag 03 februari 2006 @ 14:34:
Zijn er eigenlijk nog 'grote' plannen voor de kernel?

Waar ik eigenlijk nog op wacht is een aantal features in libata (sata):
cmq (sata2), via 8251 ondersteuning, hotplug voor sata

[DeMoN]

BoAC schreef op vrijdag 03 februari 2006 @ 15:34:
[...]

wacht

Help dan mee

[Olaf van der Spek]

BoAC schreef op vrijdag 03 februari 2006 @ 15:34:
Waar ik eigenlijk nog op wacht is een aantal features in libata (sata):
cmq (sata2), via 8251 ondersteuning, hotplug voor sata

CMQ?
NCQ?
Maar dat zijn geen echt grote plannen.

[BoAC]

DeMoN schreef op vrijdag 03 februari 2006 @ 15:44:
[...]
Help dan mee

Het probleem is dat ik geen hardware tot mijn beschikking (vrij) heb die ik daarvoor kan gebruiken

OlafvdSpek schreef op vrijdag 03 februari 2006 @ 15:56:
[...]

CMQ?
NCQ?

Die bedoelde ik ja

Maar dat zijn geen echt grote plannen.

Hm, dat vraag ik me af
http://linux.yyz.us/sata/sata-status.html#ahci

[Olaf van der Spek]

BoAC schreef op vrijdag 03 februari 2006 @ 16:42:
Hm, dat vraag ik me af
http://linux.yyz.us/sata/sata-status.html#ahci

Het is veel werk, maar het zijn geen grote veranderingen in bijvoorbeeld de architectuur.

[BoAC]

2.6.15.3
Changelog
Patch vanaf 2.6.15.2
Patch vanaf 2.6.15

[psyBSD]

Ligt het aan mij of krijgt de ontwikkeling van de 2.6 kernel weer een beetje vorm?

Ik bedoel, het lijkt alsof de releases zichzelf steeds sneller opvolgen.

[Creepy]

Valt opzich wel mee. Er lopen nu alleen twee releases naast elkaar: de stable (2.6.x.x) en de echte nieuwe versie (2.6.x).

[psyBSD]

Dan kom ik toch uit op een minor release per week.
Dat hadden we vroeger toch niet?

[psyBSD]

dubbel-post

[ Voor 90% gewijzigd door psyBSD op 07-02-2006 11:52 ]

[Creepy]

Die stable versie was er eerst niet nee. En sinds de aangepaste manier van development gaan ook de echte releases wat sneller dan hiervoor.

Maar als je bijv. de kernel van je linux distrinutie draaide had je in feite al een vervanging voor de stable versie nu (o.a. suse, redhat en debian brachten al updates van bestaande kernel versies). Dus opzich is er niet zo heel veel veranderd.

[BoAC]

2.6.15.4
Changelog
Patch vanaf 2.6.15.3
Patch vanaf 2.6.15

en

2.6.16-rc3
Changelog
Patch vanaf 2.6.15
Patch vanaf 2.6.16-rc2

[BoAC]

2.6.16-rc4
Changelog
Patch vanaf 2.6.15
Patch vanaf 2.6.16-rc3

[Brent]

Even een pure n00b vraag van iemand die Ubuntu draait maar verder geen kaas van de kernel gegeten heeft: zullen we over een tijdje 2.7.0 stable draaien? Vroegah was het toch zo dat 2.even is stable en 2.oneven unstable/test? Nu lijkt alles binnen de 2.6.x branch te gebeuren, is dat een nieuwe manier? Hoe zit dat precies?

Nog een leuke RSS voor de fanaten:
http://kernel.org/kdist/rss.xml

[zeroxcool]

Breepee schreef op zaterdag 18 februari 2006 @ 16:03:
Even een pure n00b vraag van iemand die Ubuntu draait maar verder geen kaas van de kernel gegeten heeft: zullen we over een tijdje 2.7.0 stable draaien? Vroegah was het toch zo dat 2.even is stable en 2.oneven unstable/test? Nu lijkt alles binnen de 2.6.x branch te gebeuren, is dat een nieuwe manier? Hoe zit dat precies?

Dat verhaal van (0|1|2).even = stable en (0|1|2).oneven = unstable klopt. Mocht er straks bijvoorbeeld een geheel nieuwe techniek verschijnen of men wil de kernel naar C++ porten of weet-ik-veel-wat voor _grote_ ombouw dan zal men weer aan de 2.7 branche beginnen om daarna met een stable 2.8 reeks te komen. De ontwikkeling van 2.6 is dus veelal in 2.5 gebeurd...

[ Voor 3% gewijzigd door zeroxcool op 18-02-2006 16:20 ]

[Brent]

ZeRoXcOoL schreef op zaterdag 18 februari 2006 @ 16:19:
[...]

Dat verhaal van (0|1|2).even = stable en (0|1|2).oneven = unstable klopt. Mocht er straks bijvoorbeeld een geheel nieuwe techniek verschijnen of men wil de kernel naar C++ porten of weet-ik-veel-wat voor _grote_ ombouw dan zal men weer aan de 2.7 branche beginnen om daarna met een stable 2.8 reeks te komen.

Is er dan zo weinig nieuws/leuks dat 2.7.0 nog niet is aangebroken? De x.x.x.x releases en de RC's zijn er toch ook een beetje gekomen omdat er weldegelijk een beetje 'gespeeld' binnen .6 wordt?

[Verwijderd]

ZeRoXcOoL schreef op zaterdag 18 februari 2006 @ 16:19:
[...]

Dat verhaal van (0|1|2).even = stable en (0|1|2).oneven = unstable klopt. Mocht er straks bijvoorbeeld een geheel nieuwe techniek verschijnen of men wil de kernel naar C++ porten of weet-ik-veel-wat voor _grote_ ombouw dan zal men weer aan de 2.7 branche beginnen om daarna met een stable 2.8 reeks te komen. De ontwikkeling van 2.6 is dus veelal in 2.5 gebeurd...

De linux kernel in C++ herschrijven?
Ik denk dat Linus nog eerder met Bill Gates zal samenwerken

[webfreakz.nl]

ZeRoXcOoL schreef op zaterdag 18 februari 2006 @ 16:19:
[...]

Dat verhaal van (0|1|2).even = stable en (0|1|2).oneven = unstable klopt. Mocht er straks bijvoorbeeld een geheel nieuwe techniek verschijnen of men wil de kernel naar C++ porten of weet-ik-veel-wat voor _grote_ ombouw dan zal men weer aan de 2.7 branche beginnen om daarna met een stable 2.8 reeks te komen. De ontwikkeling van 2.6 is dus veelal in 2.5 gebeurd...

Als die grote change er niet komt zitten we dus misschien straks met 2.6.88 ?

[deepbass909]

En mocht dat gebeuren zal de kernel ook niet meer 2.* zijn, maar eerder 3.*
Maar de oneven kernels zijn altijd een testbed voor de volgende even kernel, waarin bepaalde grote veranderingen getest worden. En die nieuwe versies gaan vaak gepaard met grote vernieuwingen bij hardware. 2.6 kwam rond de tijd dat de p4 en AMD64 op de markt kwamen. Het zal nog wel een jaartje ofzo gaan duren voor er weer wat groots gebeurt met de hardware, dus ook met de linux kernel.

[zeroxcool]

Verwijderd schreef op zaterdag 18 februari 2006 @ 17:32:
De linux kernel in C++ herschrijven?
Ik denk dat Linus nog eerder met Bill Gates zal samenwerken

Wat ik daarmee wil zeggen is dat bij grote ombouwen er dus een nieuwe branche wordt aangeboord...

[Verwijderd]

Verwijderd schreef op zaterdag 18 februari 2006 @ 17:32:
[...]
De linux kernel in C++ herschrijven?
Ik denk dat Linus nog eerder met Bill Gates zal samenwerken

Het is in P&W ook al eens ter sprake gekomen, maar vanwaar eigenlijk die ongelooflijk diepgewortelde HAAT tegen C++?

C++ is een open standaard, vrij te gebruiken, geen vervelende licentie perikelen of wat dan ook? Microsoft daarentegen staat voor zo'n beetje alles waar Linux tegen is: gesloten, commercieel, niet vrij, etc. Toch zou Linus dus eerder met Bill samenwerken dan iets in C++ te doen. Dat impliceert dus dat de haat tegen C++ nog velen malen groter is dan de haat tegen Microsoft.

Wat is dan zo inherent evil aan C++?

Binnen de Linux wereld gebruikt eigenlijk alleen KDE (Qt) C++, maar het hele KDE wordt door sommigen dan ook alweer als evil, of op z'n minst als problematisch kwa mogelijk licentie perikkelen gezien.

[webfreakz.nl]

Verwijderd schreef op woensdag 22 februari 2006 @ 20:42:
[...]

Wat is dan zo inherent evil aan C++?

Binnen de Linux wereld gebruikt eigenlijk alleen KDE (Qt) C++, maar het hele KDE wordt door sommigen dan ook alweer als evil, of op z'n minst als problematisch kwa mogelijk licentie perikkelen gezien.

Vaag inderdaad aangezien Linus ook het gebruik van KDE aanbeveelt boven het gebruik van GNOME (anderen DE daargelaten)

[blouweKip]

Vaag inderdaad aangezien Linus ook het gebruik van KDE aanbeveelt boven het gebruik van GNOME

Volgens mij was linus meer tegen de mentaliteit van bepaalde gnome developers imho (dus niet direct pro-kde)

[Olaf van der Spek]

Verwijderd schreef op woensdag 22 februari 2006 @ 20:42:
Het is in P&W ook al eens ter sprake gekomen, maar vanwaar eigenlijk die ongelooflijk diepgewortelde HAAT tegen C++?

Volgens mij is het een geval van premature optimization.

[Verwijderd]

Qt en licentieproblemen is i.i.g. verleden tijd. Zie voor de C++-haat http://www.tux.org/lkml/#s15-3. Daar staat ook weer zo'n leuke rant van Linus (uit 2004):

In fact, in Linux we did try C++ once already, back in 1992.
It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.
The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed:
* the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels.
* any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
* you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.
In general, I'd say that anybody who designs his kernel modules for C++ is either
(a) looking for problems
(b) a C++ bigot that can't see what he is writing is really just C anyway
(c) was given an assignment in CS class to do so.
Feel free to make up (d).

[ Voor 83% gewijzigd door Verwijderd op 22-02-2006 23:08 ]

[Olaf van der Spek]

Verwijderd schreef op woensdag 22 februari 2006 @ 23:03:
Qt en licentieproblemen is i.i.g. verleden tijd. Zie voor de C++-haat http://www.tux.org/lkml/#s15-3. Daar staat ook weer zo'n leuke rant van Linus (uit 2004):

[...]

Dat gaat (vooral) over de kernel en voor de kernel vind ik het wel logisch.

[Verwijderd]

Das inderdaad de post (alsmede anderen) waar ik ook op kwam. C) lijkt me een beetje een steek naar Tanenbaum toe btw.

Nu kan ik op zekere hoogte voor een kernel mischien hier nog wel in meekomen, alhoewel je zou zeggen dat juist ook voor een kernel organisatie ook belangrijk is. Nu kun je in C inderdaad C++ emuleren door bijvoorbeeld structs als objecten te zien waarin je VTable's namaakt door eigen arrays met functie pointers etc (C++ to C compilers werken ook zo ongeveer).

Het verklaart echter niet waarom toch zeker een grote 50% van de Linux software ook C++ banned. Is dit het blinde volgen van De Grote Leider (tm), of is er meer?

[moto-moi]

Verwijderd schreef op donderdag 23 februari 2006 @ 00:21:
Het verklaart echter niet waarom toch zeker een grote 50% van de Linux software ook C++ banned. Is dit het blinde volgen van De Grote Leider (tm), of is er meer?

Ik denk dat er gewoon te weinig mensen zijn die OO goed toe kunnen passen

[terabyte]

Verwijderd schreef op donderdag 23 februari 2006 @ 00:21:
Het verklaart echter niet waarom toch zeker een grote 50% van de Linux software ook C++ banned. Is dit het blinde volgen van De Grote Leider (tm), of is er meer?

Wat bedoel je met Linux software? Software gescheven voor de kernel (modules)? Lijkt me logisch dat dat ook in C is.

Verder snap ik je stelling niet en ik weet ook niet hoe je aan die 50% komt.

[Verwijderd]

Enkele C++-projecten van Freshmeat:
http://freshmeat.net/projects/openoffice/
http://freshmeat.net/projects/kde/
http://freshmeat.net/projects/mozilla/
http://freshmeat.net/projects/qt/
http://freshmeat.net/projects/fluxbox/
http://freshmeat.net/projects/icewm/
http://freshmeat.net/projects/celestia/
http://freshmeat.net/projects/wxwidgets/
Dat zijn toch niet de minste projecten.

edit:
enkrypt: Dit ging over dat wilde 50%-getal van pure, blinde HAAT dat hierboven geroepen werd

[ Voor 13% gewijzigd door Verwijderd op 23-02-2006 11:54 ]

[Verwijderd]

C is veel beter geschikt voor low-level development (zoals device drivers en de linux kernel) dan C++.
C is een erg strakke compacte taal, met veel controle over low-level hardware aspecten, en het is ook geen toeval dat de hele UNIX geschiedenis geworteld is in de ontwikkeling van C als programmeertaal.
Dat je hier een resem aan software opnoemt die in C++ geschreven zijn heeft op zich niet veel te betekenen, aangezien Openoffice en de linux kernel weinig overeenkomsten hebben

[zeroxcool]

Verwijderd schreef op donderdag 23 februari 2006 @ 10:39:
C is veel beter geschikt voor low-level development (zoals device drivers en de linux kernel) dan C++.
C is een erg strakke compacte taal, met veel controle over low-level hardware aspecten, en het is ook geen toeval dat de hele UNIX geschiedenis geworteld is in de ontwikkeling van C als programmeertaal.
Dat je hier een resem aan software opnoemt die in C++ geschreven zijn heeft op zich niet veel te betekenen, aangezien Openoffice en de linux kernel weinig overeenkomsten hebben

Ik bind me er niet op vast maar is het niet zo dat de NT-kernel (gebruikt in WXP + W2K) geheel in C++ was geschreven?

[Verwijderd]

Tsja, zo zie je maar wat voor prul het geworden is

[Olaf van der Spek]

Verwijderd schreef op donderdag 23 februari 2006 @ 10:39:
C is veel beter geschikt voor low-level development (zoals device drivers en de linux kernel) dan C++.

Eh, C-style code kun je ook prima in C++ schrijven, maar dat wordt helaas niet gedaan. Het nadeel is dat allerlei compile-time checks die C++ eist dan niet gedaan worden.

[a casema user]

2.6.16-rc5
Changelog
Patch vanaf 2.6.15
Patch vanaf 2.6.16-rc4

[psyBSD]

Verwijderd schreef op donderdag 23 februari 2006 @ 10:39:
C is veel beter geschikt voor low-level development (zoals device drivers en de linux kernel) dan C++.
C is een erg strakke compacte taal, met veel controle over low-level hardware aspecten, en het is ook geen toeval dat de hele UNIX geschiedenis geworteld is in de ontwikkeling van C als programmeertaal.
Dat je hier een resem aan software opnoemt die in C++ geschreven zijn heeft op zich niet veel te betekenen, aangezien Openoffice en de linux kernel weinig overeenkomsten hebben

En je moet niet vergeten dat de linux kernel over het algemeen wordt gecompiled met een gcc-compiler (Gnu Compiler Collection), en het gcc-team staat er over het algemeen wel om bekend om de c++ compiler stuk te releasen.

[Verwijderd]

Verwijderd schreef op donderdag 23 februari 2006 @ 14:02:
Tsja, zo zie je maar wat voor prul het geworden is

Ik zie de smiley staan, maar toch even voor de volledigheid. De NT kernel zelf is absoluut zo slecht nog niet. Dat er wat rare beslissingen genomen zijn mbt de userland erom heen en sommige modules erin doet weinig af aan het feit dat de kernel zelf een redelijk strak design heeft (google eens naar Dave Cutler).

[BoAC]

2.6.15.5
Changelog
Patch vanaf 2.6.15.4
Patch vanaf 2.6.15

[BoAC]

2.6.15.6
Changelog
Patch vanaf 2.6.15.5
Patch vanaf 2.6.15

_{Date: 2006-03-05 19:07 UTC}

[BoAC]

2.6.16-rc6
Changelog
Patch vanaf 2.6.15
Patch vanaf 2.6.16-rc5

_{Date: 2006-03-12 00:09 UTC}

[Ultraman]

[PATCH] 3c509: bus registration fix

- Don't call eisa_driver_unregister() if eisa_driver_register() failed.

- Properly propagate error values.

Wat leuk om te zien dat een dermate oude driver module voor een erg oud kaartje toch nog een patch krijgt
Laat ik de 3c509 nou net gebruiken in een antiek systeempje hier. Even kijken of die zijn heeft om weer anderhalf uur lang een kernel te bakken

[Olaf van der Spek]

cybersteef schreef op dinsdag 14 maart 2006 @ 18:20:
[...]

Wat leuk om te zien dat een dermate oude driver module voor een erg oud kaartje toch nog een patch krijgt
Laat ik de 3c509 nou net gebruiken in een antiek systeempje hier. Even kijken of die zijn heeft om weer anderhalf uur lang een kernel te bakken

Heeft dat systeem een EISA bus dan?

[MTWZZ]

cybersteef schreef op dinsdag 14 maart 2006 @ 18:20:
[...]

Wat leuk om te zien dat een dermate oude driver module voor een erg oud kaartje toch nog een patch krijgt
Laat ik de 3c509 nou net gebruiken in een antiek systeempje hier. Even kijken of die zijn heeft om weer anderhalf uur lang een kernel te bakken

3c509 FTW! idd best geinig om te zien dat zulke ouwe meuk toch nog aandacht krijgt

[a casema user]

2.6.16
Changelog
Patch vanaf 2.6.15
Patch vanaf 2.6.16-rc6

[webfreakz.nl]

@ A casema user:

Installeer/gebruik jij ook al die kernels?

[Ultraman]

* Ultraman gaat 2.6.16 even binnenslepen en compileren op een oud testbakje
Heeft toch een nieuwe kernel nodig en dan heb ik gelijk die patch voor de 3c509.
Ben benieuwd hoe lang de compilatie gaat duren...

[Olaf van der Spek]

webfreakz.nl schreef op maandag 20 maart 2006 @ 12:50:
Installeer/gebruik jij ook al die kernels?

Ik run Debian Testing en Unstable en dan kom je regelmatig nieuwe kernels tegen.

[a casema user]

webfreakz.nl schreef op maandag 20 maart 2006 @ 12:50:
@ A casema user:

Installeer/gebruik jij ook al die kernels?

yup, vind het altijd wel leuk om ermee te spelen.

[Verwijderd]

OlafvdSpek schreef op maandag 20 maart 2006 @ 22:58:
[...]

Ik run Debian Testing en Unstable en dan kom je regelmatig nieuwe kernels tegen.

Ik draai Debian Testing, maar -zo- vaak kom je nou ook weer niet nieuwe kernels tegen. Recent kwam wel 2.6.15 binnen (bij mij een paar keer zelfs als identieke versie), maar de voorgaande was 2.6.12. Vergeleken met Debian Stable is het relatief natuurlijk wel vaak, want daar komt gewoon -geen- nieuwe kernel versie voor tussen de major releases.

Even op gevoel komt bij Debian Testing zo elke 4 maanden een kernel update.

[Olaf van der Spek]

Verwijderd schreef op woensdag 22 maart 2006 @ 19:51:
Ik draai Debian Testing, maar -zo- vaak kom je nou ook weer niet nieuwe kernels tegen. Recent kwam wel 2.6.15 binnen (bij mij een paar keer zelfs als identieke versie), maar de voorgaande was 2.6.12. Vergeleken met Debian Stable is het relatief natuurlijk wel vaak, want daar komt gewoon -geen- nieuwe kernel versie voor tussen de major releases.

Even op gevoel komt bij Debian Testing zo elke 4 maanden een kernel update.

Klopt, maar dat komt vooral door issues als de ramdisk generators en udev.
In unstable is 2.6.16 nu al beschikbaar.

[Verwijderd]

OlafvdSpek schreef op woensdag 22 maart 2006 @ 20:13:
[...]
Klopt, maar dat komt vooral door issues als de ramdisk generators en udev.
In unstable is 2.6.16 nu al beschikbaar.

Zal best. Unstable is leuk om in een VM of aparte bak erbij te draaien en even te spieken wat er binnenkort allemaal naar je desktop gaat komen. Laatst nog was gnome bijvoorbeeld nog totaal broken in unstable, dat is dus niet iets wat je ook maar voor prive 'computeren' (mail, surfen etc) wil draaien

[Justin_Time]

Verwijderd schreef op woensdag 22 maart 2006 @ 21:41:
[...]


Zal best. Unstable is leuk om in een VM of aparte bak erbij te draaien en even te spieken wat er binnenkort allemaal naar je desktop gaat komen. Laatst nog was gnome bijvoorbeeld nog totaal broken in unstable, dat is dus niet iets wat je ook maar voor prive 'computeren' (mail, surfen etc) wil draaien

Nouja daar ben ik het niet mee eens.

Ik draai testing al een aardige tijd op mijn normale werkpc en dat gaat prima. Natuurlijk moet je de updates goed in de gaten houden en wil het gebroken zijn dan ga je terug en hou je die pakketten on hold totdat het probleem is opgelost... Maar wanneer er veel pakketten gebroken zijn dan is dat in mijn ervaring vrij snel weer gefixed.

[Verwijderd]

Justin_Time schreef op donderdag 23 maart 2006 @ 15:58:
[...]

Nouja daar ben ik het niet mee eens.

Ik draai testing al een aardige tijd op mijn normale werkpc en dat gaat prima.

Uhm, lees je nu verkeerd of maak je hierboven een typo?

Ik had het over UNSTABLE

Zelf draai ik ook testing als mijn normale config voor mijn werk PC (development). De 'huiskamer' PC (surfen en emailen) is een Windows bak. Ik vind de stabiliteit van testing ongeveer gelijk aan Windows grofweg. Ondanks de naam zie ik testing als het 'gewone' OS voor de werk of prive desktop. Stable is (IMHO) alleen nodig voor servers, en unstable voor als je zelf Linux software developped en wilt testen.

[Justin_Time]

Sorry voor mijn typo maar ik had het over unstable... de naam zegt meer onheil dan dat er daadwerkelijk is.

[Verwijderd]

Ik draai nu iets meer dan 5 jaar Unstable, en ik heb in totaal 3x meegemaakt dat er echt iets totaal kapot was, en zelfs toen was het na een bezoekje aan het #debian kanaal op freenode op 3 minuutjes opgelost.
Sommige packages draai ik uit Experimental, en zelfs daar heb ik zeer zelden problemen mee...
En dan ook nog even vermelden dat ik een volledig 64bit userland heb, icm een athlon64.

[ Voor 31% gewijzigd door Verwijderd op 24-03-2006 16:27 ]

[Verwijderd]

Ik draai zelfs Debian unstable op m'n server... Ben ik nu 'n slecht mens? Echte problemen heb ik er nog niet mee gehad. En als er eens 'n pakket kapot is, is 't in de meeste gevallen geen kritiek pakket (behalve dan laatst vim.. brr). Meestal is 't dus gewoon 'n dag wachten en dan is 't weer gefixt.

[Olaf van der Spek]

Verwijderd schreef op zaterdag 25 maart 2006 @ 01:38:
Meestal is 't dus gewoon 'n dag wachten en dan is 't weer gefixt.

Wat voor server is het dan?
Een server (of desktop) die een dag 'down' is kan ik echt niet gebruiken.

[Verwijderd]

Als er in Unstable ergens iets mis gaat (wat zelden gebeurt) kan je gewoon ff langs het irc kanaal gaan voor hulp.
Daar hebben ze mij steeds binnen 2 minuten van mijn probleem kunnen afhelpen.
Dus een hele dag wachten is zeker niet nodig hoor.

[Sendy]

Als je niet snel/vaak update (bijvoorbeeld pas wanneer je iets leest in Debian Weekly News.) Dan download je soms nog wel een foutje, maar dan is er vrijwel altijd al een bug report op de Debian Bug Tracker.

Maar als je dit soort (milde) gezeik niet wil, dan moet je natuurlijk gewoon geen Debian Unstable draaien.

[Jelmer]

2.6.15.7
Changelog
Patch vanaf 2.6.15.6
Patch vanaf 2.6.15

[Ultraman]

Jelmer schreef op dinsdag 28 maart 2006 @ 22:38:
2.6.15.7
Changelog
Patch vanaf 2.6.15.6
Patch vanaf 2.6.15

2.6.16 is er al een tijdje
Is er een reden om dan 2.6.15.7 te gaan doen?

[Olaf van der Spek]

cybersteef schreef op dinsdag 28 maart 2006 @ 23:18:
[...]

2.6.16 is er al een tijdje
Is er een reden om dan 2.6.15.7 te gaan doen?

Ja. Er zijn toch ook nog 2.4 releases terwijl 2.6 er al is?

[webfreakz.nl]

Das wel een heel groot verschil dan wat Cybersteef bedoelde

[ Voor 3% gewijzigd door webfreakz.nl op 29-03-2006 14:17 ]

[Ultraman]

OlafvdSpek schreef op dinsdag 28 maart 2006 @ 23:51:
[...]
Ja. Er zijn toch ook nog 2.4 releases terwijl 2.6 er al is?

Maar dan praat je ook echt over een wezenlijk verschil.
Is het serieus nuttig om 2.6.15.7 te gebruiken als 2.6.16 gewoon normaal beschikbaar is?
Ik heb verder geen changelogs door zitten nemen maar ik mag aannemen dat 2.6.16 dezelfde wijzigigen/fixes/features bevat als 2.6.15.7. Toch?

[webfreakz.nl]

Denk het niet, aangezien het niet logisch is dat 2.6.16 ooit nog aangepast wordt? Het is die uitgave en die zal over 100 jaar nogsteeds hetzelfde zijn? Uiteraard 2.6.16.x wél maar je snapt wat ik bedoel

[ Voor 24% gewijzigd door webfreakz.nl op 29-03-2006 14:23 ]

[Olaf van der Spek]

cybersteef schreef op woensdag 29 maart 2006 @ 14:21:
Maar dan praat je ook echt over een wezenlijk verschil.
Is het serieus nuttig om 2.6.15.7 te gebruiken als 2.6.16 gewoon normaal beschikbaar is?
Ik heb verder geen changelogs door zitten nemen maar ik mag aannemen dat 2.6.16 dezelfde wijzigigen/fixes/features bevat als 2.6.15.7. Toch?

Dat lijkt me niet.
Nadat 2.6.15 gereleased is worden er geen features meer aan toegevoegd (gok ik). Daar heb je dus 2.6.16 voor nodig. Er worden echter nog wel (kritieke) bugs gefixed.
Voor gebruikers die niet het risico willen lopen op extra bugs door die nieuwe features is dus 2.6.15.

[Ultraman]

Hmm ja het puntje van Olaf kan ik helemaal volgen

[Wirf]

cybersteef schreef op woensdag 29 maart 2006 @ 23:54:
Hmm ja het puntje van Olaf kan ik helemaal volgen

Hij heeft wel gelijk, het nut van 2.6.15.7 is dat er geen nieuwe "experimentele" dingen aan toegevoegd worden die nog niet zoveel getest zijn.

(al is alles wat in de mailline kernel komt al behoorlijk goed getest in bijvoorbeeld -mm kernels)

[Verwijderd]

OlafvdSpek schreef op zaterdag 25 maart 2006 @ 08:49:
[...]

Wat voor server is het dan?
Een server (of desktop) die een dag 'down' is kan ik echt niet gebruiken.

Geen hippe bedrijfsserver ofzo, gewoon 'n bakje thuis. Een dag down wil ik ook niet, maar dat gebeurt ook niet (vaker door mijn ingevingen om eraan te prutsen dan door unstable). Het is hooguit een pakket dat niet wil installeren/upgraden omdat er iets met de dependencies niet goed zit. Zo had ik 'n paar dagen geleden problemen met python (dat met apt-get -f install te fixen was) en wat eerder met vim (tijdelijk gefixt door de testingversie te installeren).

[_JGC_]

OlafvdSpek schreef op woensdag 29 maart 2006 @ 14:36:
[...]

Dat lijkt me niet.
Nadat 2.6.15 gereleased is worden er geen features meer aan toegevoegd (gok ik). Daar heb je dus 2.6.16 voor nodig. Er worden echter nog wel (kritieke) bugs gefixed.
Voor gebruikers die niet het risico willen lopen op extra bugs door die nieuwe features is dus 2.6.15.

Probleem met 2.6.15 is dat er enorm veel regressies in performance in zaten tov 2.6.14. Dit hebben ze in 2.6.16 opgelost met een heleboel vernieuwingen, dus sowieso snap ik het nut niet van 2.6.15 op dit moment. Vaak komt er nog 1 pointrelease en gaan ze daarna gewoon verder met de volgende versie.
Nadeel van 2.6.16 is dat ze inmiddels weer de hele seriele driver stack omver hebben gegooid door allerlei structs weg te gooien en te vervangen met GPL-only functies, waarbij niet-GPL modemdrivers helemaal buitenspel worden gezet (intel 536 en 537 modems gaan niet werken zonder de kernel te patchen of de intel drivers te re-licensen naar GPL).

[Verwijderd]

2.6.16.4
Patch
Changelog

[Wirf]

_JGC_ schreef op donderdag 30 maart 2006 @ 13:10:
[...]


Probleem met 2.6.15 is dat er enorm veel regressies in performance in zaten tov 2.6.14. Dit hebben ze in 2.6.16 opgelost met een heleboel vernieuwingen, dus sowieso snap ik het nut niet van 2.6.15 op dit moment.

Ik heb nu een eindelijk een kernel die een beetje werkt zoals ik die wil hebben. Maar daarvoor heb ik aardig wat out-of-kernel patches en modules voor moeten opzoeken, apply-en en sommige ook nog moeten aanpassen. Daarom blijf ik een poos op 2.6.15.4

Bijvoorbeeld de ivtv module die ik gebruik voor mijn tvkaart, daar zijn ze mee bezig om die in de mainline kernel te krijgen, erg mooi natuurlijk, maar voordat het zover ik heb je voor elke nieuwe versie van de kernel ook een nieuwe versie van ivtv tools nodig.

Ik wacht dus nog even voordat het wat rustiger wordt op dat gebied.


Maar ik ben wel benieuwd, wat zijn sommige van de performance regressies en verbeteringen in 2.6.15 en 2.6.16?

[Sendy]

2.6.16.5
Patch
Changelog

Dat waren toch een hoop kernels in de laatste paar dagen Hopelijk applied Xen 3.0.2 nog tegen deze nieuwste kernel.

[Borromini]

Nog altijd geen patch voor de hda-intel module blijkbaar .

[Verwijderd]

Borromini schreef op vrijdag 14 april 2006 @ 12:56:
Nog altijd geen patch voor de hda-intel module blijkbaar .

Toevallig dat je dat zegt, want ik merk zonet dat mijn geluid op de laptop niet meer werkt... (kernel 2.6.16-ck5).
Is dit een bug in 2.6.16?

[_JGC_]

grote kans dat je wat aan deze patch hebt:
http://cvs.archlinux.org/...ent&only_with_tag=CURRENT

[Borromini]

Bedankt . Ga ik vanavond es proberen

[Wirf]

Kleine update:

2.6.16.6
changelog
patch

2.6.16.7
changelog
patch

2.6.16.8
changelog
patch

2.6.16.9
changelog
patch

[Verwijderd]

Wat zijn nou eigenlijk een beetje de grote komende veranderingen die op stapel staan voor de 2.6 kernel? M.a.w. waar kijkt iedereen hier het meeste naar uit?

[Sendy]

Xen!!! En ik ben zeer verheugd met de recente Marvel Yukon drivers

[Razr]

.

[ Voor 100% gewijzigd door Razr op 21-04-2006 19:16 ]