Linux-kernel 2.6.39 vrijgegeven

Linus Torvalds heeft na een ontwikkelperiode van twee maanden Linux-kernelversie 2.6.39 vrijgegeven. Naast een eenvoudigere manier om firewalls te configureren zou de kernel betere ext4-prestaties bieden en bevat hij meer drivers.

In kernel 2.6.39 kunnen, via de commandline-tool ipset, de tabellen die nodig zijn voor het opzetten van firewalls eenvoudiger worden beheerd. Hierdoor zou het makkelijker moeten worden om tijdelijk aanvallers te blokkeren, terwijl de prestaties zouden verbeteren doordat de firewall-tabellen in het werkgeheugen worden opgeslagen. De nieuwe kernelcode bevat ook een vanuit Google aangedragen patch voor de tcp-stack. Door het 'initial receive window' te vergroten, zouden de netwerkprestaties tot 10 procent kunnen toenemen.

De kernelhackers hebben ook de nodige nieuwe drivers aan de kersverse kernelcode toegevoegd, waaronder drivers voor diverse wifi-chipsets van Ralink en Broadcom. Ook is er gesleuteld aan de code voor het btrfs-bestandssysteem, terwijl het inmiddels al veelgebruikte ext4-bestandssysteem ook enkele optimalisaties heeft gekregen in de vorm van de 'multiple page-io submissions'.

Kernel 2.6.39 kan voortaan overweg met usb 3.0-hubs, evenals met nieuwe grafische kaarten van AMD uit de Cayman-serie. Ook zou de driver voor de Intel GMA500-gpu beter functioneren. Bezitters van Samsung-notebooks zullen in bepaalde gevallen merken dat de functietoetsen weer functioneren. Inmiddels zijn de kernelontwikkelaars begonnen aan de bouw van Linux-kernel 2.6.40. Naar verwachting is deze kernel eind juli gereed.

Reacties (86)

[Alfredo]

Voor de volgende kernel (2.6.40) is men onder andere van plan de ARM-specifieke code op te kuisen. Daar zit momenteel nog een hoop functionaliteit in die elders gedupliceerd wordt.

[wankel]

Daar zit momenteel nog een hoop functionaliteit in die elders gedupliceerd wordt.

Niet zozeer die "elders" gedupliceerd wordt, maar die binnen de ARM-boom gedupliceerd wordt. De oorzaak is dat veel zaken voor specifieke ARM-families opnieuw uitgewerkt zijn, zonder afstemming tussen de ontwikkelaars voor de verschillende ARM-versies.

Zoals je zegt, is het doel om voor 2.6.40 daar wat structuur in te brengen en met méér functionaliteit toch een kleinere kernel op te leveren.

[mcmd]

Meer informatie over de Google patch: http://lwn.net/Articles/427104/:

The TCP slow start algorithm, initially developed by Van Jacobson, was one of the crucial protocol tweaks which made TCP/IP actually work on the Internet. Slow start works by limiting the amount of data which can be in flight over a new connection and ramping the transmission speed up slowly until the carrying capacity of the connection is found. In this way, TCP is able to adapt to the actual conditions on the net and avoid overloading routers with more data than can be accommodated. A key part of slow start is the initial congestion window, which puts an upper bound on how much data can be in flight at the very beginning of a conversation.

That window has been capped by RFC 3390 at four segments (just over 4KB) for the better part of a decade. In the meantime, connection speeds have increased and the amount of data sent over a given connection has grown despite the fact that connections live for shorter periods of time. As a result, many connections never ramp up to their full speed before they are closed, so the four-segment limit is now seen as a bottleneck which increases the latency of a typical connection considerably. That is one reason why contemporary browsers use many connections in parallel, despite the fact that the HTTP specification says that a maximum of two connections should be used.

Some developers at Google have been agitating for an increase in the initial congestion window for a while; in July 2010 they posted an IETF draft pushing for this change and describing the motivation behind it. Evidently Google has run some large-scale tests and found that, by increasing the initial congestion window, user-visible latencies can be reduced by 10% without creating congestion problems on the net. They thus recommend that the window be increased to 10 segments; the draft suggests that 16 might actually be a better value, but more testing is required.

David Miller has posted a patch increasing the window to 10; that patch has not been merged into the mainline, so one assumes it's meant for 2.6.39.

Interestingly, Google's tests worked with a number of operating systems, but not with Linux, which uses a relatively small initial receive window of 6KB. Most other systems, it seems, use 64KB instead. Without a receive window at least as large as the congestion window, a larger initial congestion window will have little effect. That problem will be fixed in 2.6.38, thanks to a patch from Nandita Dukkipati raising the initial receive window to 10 segments.

[RielN]

Als je hem even voor ons samengevat had in het NEderlands was het een Spotlighter geworden denk ik

[hiostu]

Nog steeds snap ik niet wat drivers in een kernel doen. Het dan toch niet zo zijn dat je voor nieuwe videokaart drivers een nieuwe kernel hoeft te compileren? Iemand die wat meer info hier over heeft?

[ChaoZero]

dat ligt eraan; Over het algemeen worden nieuwe 'drivers' toegevoegd als kernel-modules. Die worden in de kernel geladen, met dus als nadeel dat ze later geladen worden (dûh) dan kernelcode en dat kost tijd. Het kan dus allebei, maar vanuit compatibility-oogpunt worden modules vaak bij een nieuwe versie (zoals nu) toegevoegd aan de kernel. Denk hierbij niet aan alle printer-drivers en etc; de hardware die de basisfunctionaliteit verzorgt is natuurlijk belangrijker. Videokaarten, NIC's, modules voor schijftoegang, etc. etc.

optimale situatie qua snelheid: ALLEEN de gebruikte drivers in de kernel opnemen.
optimale situatie qua compatibility: alle drivers in de kernel opnemen.
Middenweg: Een kale kernel + jouw 'altijd-gebruikte' drivers compileren, en een shitload kernel modules (welke bij iedere hedendaagse distributie standaard bijgeleverd zijn) die later kunnen worden geladen; wanneer de hardware wordt aangesloten of gebruikt.

Het verschil met windows is dat *nix systemen ècht compatible proberen te zijn (behalve OSX ). Zoveel mogelijk drivers worden in de kernel opgenomen zodat 'DE Linux kernel' out-of-the-box werkt en na zelfs installatie nog verplaats kan worden naar een systeem met andere hardware. Probeer Windows eens zonder "sysprep /generalize" te verplaatsen naar een pc met een ander moederbord

[Reactie gewijzigd door ChaoZero op 24 juli 2024 08:33]

[dipje2]

Onderdelen ('drivers') van de kernel kunnen als losse module gemaakt worden en als onderdeel van de kernel. Het is dus niet zo dat een kernel opnieuw gecompiled hoeft te worden, het kan ook gewoon een nieuwe losse module zijn die dynamisch geladen en 'unloaded' kan worden.

En alhoewel het vanuit de opensource / GPL gedachte meestal als evil wordt gezien, kan je natuurlijk ook voor een bepaald platform een kant-en-klare binaire module aanleveren. Source is meestal gewoon handiger vanwege de berg aan verschillende systemen en linux-kernel versies in het veld.

Nu, een hoop van de opensource drivers voor linux zijn onderdeel geworden van de kernel. Of 'opgenomen in de kernelsource'. Dat wil niet zeggen dat ze dus bij een complete kernel compile horen, maar gewoon dat dat driver pakketje vanaf nu door het officiele linux-kernel team onderhouden en supported zal worden. Dat 'doen' drivers in een kernel, onderdeel zijn van . Zie het als de 'microsoft signed / approved drivers' maar dan de linux smaak .

Elke distributie zal een stijl hanteren van 'zoveel mogelijk in losse modules'. Daardaar kunnen ze individueel ge-upgrade worden en zo.

Maar in de embedded wereld is het af en toe verrekte handig om alles in 1 grote kernel te zetten wat je nodig hebt. Dan is het er gewoon en hoef je geen userspace tools en dingen meer te regelen om de modules te laden.

[humbug]

Designfout die lastig te corrigeren is. Toen Linux ontworpen werd was het idee van een "microkernel" al bekend maar het was simpeler om alles maar in de kernel te gooien. En daar plukken we nog steeds de wrange vruchten van.

[Cyphax]

Designfout die lastig te corrigeren is

Andrew, is that you?

Het is geen fout, het is een bewuste keuze geweest. Dit is een hele oude discussie: de monolith vs de microkernel. Linus en Tanenbaum hebben daar lang over gediscussieerd en Linus heeft toentertijd gewoon gekozen voor een monoliet, al is Linux in principe een hybride (je kunt immers je drivers als kernelmodules compilen als je wilt). Anyway, beide hebben voor- en nadelen. Linus koos voor performance. Aan de andere kant kan een driver die crasht wel je monoliet omleggen en dan krijg je dat je OS platgaat.

Anyway: volgens mij zijn alle drivers in veelgebruikte distro's als Ubuntu wel als module gecompiled over het algemeen. Die worden automatisch ingeladen door de hardware-detectie van het OS.

Het dan toch niet zo zijn dat je voor nieuwe videokaart drivers een nieuwe kernel hoeft te compileren?

In den beginne waren alle drivers ook gewoon volledig open en kreeg je die nieuwe versies bij een nieuwe kernelversie. Het is niet zoals bij Windows waar je de drivers los moet opzoeken en downloaden. Als je nu van kernel.org een vanilla kernel downloadt zitten daar de drivers ook gewoon bij.

[Reactie gewijzigd door Cyphax op 24 juli 2024 08:33]

[trogdor]

ha, een VU student :-)
Je kan RHEL 6.0 ook met 'basic-graphics' installeren, met als gevolg dat het opstart scherm er antiek lelijk uit ziet. De Nvidia driver wordt pas later geladen, vanaf dat moment is alles prima, maar het boot process wordt er wel erg retro van.

[Verwijderd]

Bij het gebruik van bepaalde systemen is het nodig dat de drivers in de kernel geplaatst zijn. Dit is bijvoorbeeld nodig bij een boot via een netwerk (pxe). Zonder deze drivers kan de nic vanuit Linux niet aangestuurd worden.

Overigens kunnen de meeste drivers ook geladen worden als module. Deze zitten dan niet direct in de kernel meegebakken.

[Verwijderd]

Is geen designfout. monolithische en microkernels hebben allebei voors en tegens. Er is geen 'goede' of 'foute' keuze.

[i-chat]

drivers heb je nodig om je hardware aan te sturen, PUNT.. dus waaom zou je ze niet in de kernel laden. de linux kernel is gewoon modulair opgebouwd en dat zou moeten betekenen dat je bepaalde drivers ook achterwege kunt laten bij het compilen ... dat er maar weinig distro's zijn die bij de installatie een hardwere specifieke kernel opbouwen is in principe toch niet de schuld van de kernel devs...

volgens mij is een driver in je kernel altijd sneller dan een lose module, met als nadeel dat een overbodig ingebakke driver natuurljik nutteloze ruimte en laadtijd kost...

kortom ik zie het probleem niet zo erg...

[hiostu]

kortom ik zie het probleem niet zo erg...

Dit zijn volgens mij juist de redenen waarom Linux niet snel aan zal slaan bij de gewone gebruikers. Zo blijft het altijd voor de techneuten.

[erikdenv]

Want?

Als je zelf de kernel compileert maak je een keuze of je drivers als module compileert of dat je deze in de kernel integreert.

Deze keuze hoeft alleen door de geeks/nerds/fanaten/liefhebbers gemaakt te worden.

Bijna alle distributies (Ubuntu, Fedora, Suse en dat soort spul) leveren zelf een kernel mee waarbij praktisch alle drivers als module gecompileerd zijn.
Essentiele drivers (aansturing van I/O, filesystemen, processorsupport) zitten in de kernel. Deze wordt zo klein mogelijk gehouden.

Dit is een prima systeem. Juist omdat de drivers bij de kernel horen is de Linux kernel inzetbaar op veel platformen.
Je kunt dezelfde source gebruiken op X86, PowerPC, mainframe, arm, mips, sparc enz. vaak op zowel 32 als 64 bit.
Dit in tegenstelling met Windows dat het met maar liefst een (1) platform moet doen (nou ja Itanium dan en heel vroeger de Alpha) .

Mijn Philips Webcam wordt al jaren door Linux ondersteund, sinds Vista is er geen Windowsdriver meer voor deze Webcam, een 64 bit driver voor XP_64 heb ik nooit gehad.
Microsoft verandert nog wel eens zijn drivermodel, als fabrikanten geen zin hebben om een nieuwe driver te bouwen heb je pech.

Ik vraag me dan ook af waarom drivers die bij de kernelsource zouden mogen horen van jou.


Edit: spelfouten

[Reactie gewijzigd door erikdenv op 24 juli 2024 08:33]

[Verwijderd]

Je kunt een driver ook buiten de kernel compileren, daar heb je alleen de kernel headers voor nodig, niet de implementatie.

De reden dat er zo veel drivers in Linux zitten is omdat je dan een werkend system kunt krijgen zonder (zoals bij windows) het internet moet afstruinen voor de juiste drivers.

Je kunt ook prima met een Linix 2.4 en 2.6 kernel een driver downloaded die gecompileerd is met een kernel die dezelfde API heeft. Dus wat dat betreft voldoende flexibiliteit met voldoende 'out of the box' werkende systemen.

[hiostu]

Is het dan goed om een kernel te leveren waar 1000en drivers inzitten voor alle apparaten die er ooit maar zijn gemaakt? Waarvan je er misschien 50 nodig hebt op een PC? Lijkt me juist de manier van Windows een stuk beter waarbij ze wel op de CD staan voor veel hardware en anders gedownload kunnen worden.

[Hiub]

geen idee hoeveel het er zijn, maar de linux-kernel neemt iig verwaarloosbaar weinig ruimte in beslag op een gemiddeld systeem, als je het vergelijkt met de rest van de software en data die erop staat. Daarbij zit maar een deel in de kernel, en worden delen die specifiek voor bepaalde hardware zijn vaak als module geladen.

ik ben juist blij dat windows ook steeds meer die kant op gaat, een verademing toen ik na de windows 7 installatie bijna niks meer zelf hoefde te downloaden en installeren (toch wel jammer als je dan alsnog zelf sommige moederbord drivers moet downloaden maar misschien is dat ooit ook niet meer nodig over een paar versies ofzo..)

[Verwijderd]

Onder linux worden bij de meeste distro's alle modules op schijf gezet en enkel die modules die nodig zijn worden geladen, de rest blijft gewoon idle op de schijven staan. En tenzij iemand zich echt druk maakt om die paar MB extra op z'n schijf zal er niemand zijn die daar last van heeft.

[borft]

dan ljikt windows me een beter geschikt systeem voor jou

Ik ben blij dat met een nieuwe kernel release al mijn hardware blijft werken. Het "jammer-joh-deze-printer-werkt-niet-op-win-7-maar-wel-op-xp" syndroom heb ik gelukkig nooit last van.

Als je je iets meer in de materie zou verdiepen dan zuo je weten adt nagenoeg alle kernel features als module gebuild kunnen worden. Modules kunnen na/of tijdens het booten (dmv init ramdisk) geladen worden als ze nodig zijn en zelfs achteraf weer geunload worden; zonder reboot!

[Xudonax]

Daarom leveren AMD en nVidia ook losse driverpackages voor hun kaarten. Hoe het bij Intel precies gaat weet ik niet.

[bouwfraude]

Intel drivers worden met de kernel meegeleverd, althans mijn laptop doet het zonder problemen.
Ik heb in het verleden aanmerkelijk meer problemen met Ati chipjes dan met Nvidia chipjes gehad en linux ondersteuning.
Bij iedere nieuwe kernel versie deed de Ati kaart het niet meer.

[ChaoZero]

Intel drivers worden met de kernel meegeleverd, althans mijn laptop doet het zonder problemen.

Dat zegt niets. Wanneer de stuurprogrammatuur als module is toegevoegd aan de door jouw geïnstalleerde distributie (dus NIET in de kernel!) werkt het ook out-of-the-box.

Bij iedere nieuwe kernel versie deed de Ati kaart het niet meer.

Dit komt doordat ATI voor iedere nieuwe 'major' versie opnieuw een binary moet maken.
Voor de kernel -> in combinatie met X11/andere_grafische_server versie.

Wanneer je een open-source module hebt zal deze blijven werken, of is makkelijk te compileren tegen de nieuw-geinstalleerde software

[Reactie gewijzigd door ChaoZero op 24 juli 2024 08:33]

[cyberstalker]

Dat is ook niet per se nodig. Als je liever gebruik maakt van kernel modules is dat uiteraard ook mogelijk. In dat geval kan de module gewoon geladen worden, zonder dat een kernel-hercompilatie of reboot nodig is.

[Winkey]

Nee dat hoeft inderdaad niet, kernel hercompileren bij nieuwe videodrivers. De meeste drivers die worden meegeleverd worden als module gecompileerd/bijgeleverd (bij distro's dan). Dan kan die module gebruikt worden wanneer de kernel dat stuk hardware ontdekt en daar de bij behorende module daarbij laden.

Het is wel zo dat bij proprietary drivers ook een module word gecompileerd, immers anders zouden die drivers ook opensource moeten zijn als ze in het kernel worden geïntegreerd.

[Verwijderd]

Vrijwel alle drivers zijn modules die runtime geladen kunnen worden. Je hoeft dus geen nieuwe kernel te compileren.

[gertjuhh]

Is er ook nog iets aan het stroomverbruik gedaan?
nieuws: 'Nieuwe Linux-kernels gebruiken meer energie'
Met het oog op een zuinige linux server zou dat een welkome aanvulling zijn geweest.

[mux]

Linux hoeft, in de juiste handen, helemaal niet meer energie te gebruiken. Een paar slimme tweakers in dit topic hebben dat al bewezen.

[blouweKip]

Dit betreft enkele regressies in de recent kernels die ervoor zorgen dat er ineens meer energie wordt gebruikt voor dezelfde handelingen.

powermanagement wordt ondanks de povere ondersteuning van fabrikanten inderdaad steeds beter.

[avdg-BE]

Naar mijn weten is de developmentstructuur zodanig goed, dat er bij zowat elke klacht dat duidelijk gereproduceerd kan worden er meteen over gediscussieerd wordt over de oorzaak ervan, dus hier maak ik geen zorgen. Het enige dat ik nog niet weet is dat er ook daadwerkelijk fixes inzitten die het probleem verhelpen.

[Verwijderd]

Nee, het is nog niet gefixt.

"the Linux kernel is still burning through power " - http://www.phoronix.com/s...?page=news_item&px=OTQ2MQ

[_JGC_]

Toen het ontdekt werd door Phoronix werd gezegd dat ze het bij Phoronix wel even automatisch zouden bisecten met hun test suite. Ik heb behalve "zuipt nog steeds stroom" nog geen enkel nieuwsbericht gezien over de oorzaak van het toegenomen stroomverbruik.

[Verwijderd]

Het enige wat mij opviel is dat de toename van stroomverbruik nagenoeg tegelijk kwam met de nieuwe groepsgebaseerde scheduler. Ik vraag me dan ook af of de stijging in verbruik niet gerelateerd kan worden aan een stijging in performance. (immers zou die aangepaste scheduler voor een hogere performance moeten zorgen omdat er efficienter tussen taken geswitched kan worden.)

[postbus51]

Voor een laptop zou idd een toename van 3 tot 4 Watt niet ideaal zijn maar voor een server met prik uit de muur
Maar goed energie-beheer met acpi 4.0 zou een verbetering terzijner tijd geven
Persoonlijk meet ik een toename met maarliefst 2 Watt , voor 220V te verwaarlozen
zelfs na 300 dagen zou dat 3600 Watt zijn

[Cobalt]

Voor een server maakt het meer uit dan voor een laptop. Servers staan 24 uur per dag 365 dagen in het jaar aan. In een datacenter hangt niet 1 server maar honderden/duizenden.

[i-chat]

true, maar wat kost een watt/uur - bijna niets, al is het in een dc natuurlijk wel iets anders dan thuis omdat je daar veel meer met koeling te maken krijgt... maar bij laptops kost zoiets je een uur niet werken, op een lading, dat is oa voor bedrijven aanzienlijk duurder dan een paar wat extra.

[Wilke]

Nou ja, bijna niets...een continu verbruik van 1 W (een watt/uur is een betekenisloze eenheid trouwens) kost ~2 euro/jaar, dus bij 4 Watt is dat 8 euro/jaar, en met 1000 servers (40 racks gevuld met 2U servers) 8000 euro/jaar plus waarschijnlijk minstens nog eens dat bedrag aan koelcapaciteit.

Dus ja, dat kan toch wel uitmaken.

[scsirob]

Als de marge op die diensten minder dan 1% is dan is een energietoename van 10% killing

[mkools24]

Dat maakt niks uit, stroomverbruik wordt gewoon 1-op-1 doorberekend aan de klant. Gaat die meer gebruiken zal hij ook meer moeten betalen.

[Dreamvoid]

Niet als de concurrentie op Windows/Mac/etc draait die veel lagere stroomkosten heeft omdat die wel hun power management op orde hebben.

[mkools24]

Ik kan me niet voorstellen dat er ook maar één Windows machine is die minder stroom verbruikt dan Linux, met al die overhead, GUI etc.

[Cobalt]

@mkools24, Out of the box is Windows in sommige gevallen zuiniger dan Linux out of the box. Zie ook blog Over kunst, cultuur en techniek: 10W i3 systeem - de treinreis

[Reactie gewijzigd door Cobalt op 24 juli 2024 08:33]

[Blokker_1999]

Enkele wat per server met vooral warmteontwikkeing betekend dus ook meer koeling. Vermmenigvuldig dat met de vele servers en je komt op een jaar uit op veel energie. Te meer als je gaat rekenen naar de honderdduizenden servers wereldwijd

[mkools24]

Vindt eens productieservers die op nieuwere kernels draaien waar dit probleem zich voordoet. Er wordt toch veelal CentOS of Redhat gebruikt en die lopen ik weet niet hoever achter, Mijn CentOS machine maakt bijv. nog gebruik van Kernel 2.6.19.

Mocht er functionaliteit uit een nieuwere kernel nodig zijn dan stript Redhat vaak alleen dat gedeelte en bakken ze dat weer in in bijv 2.6.19. Ik denk dus dat dit probleem een beetje opgeblazen wordt en ze hebben nog tijd zat om het te verhelpen.

[borft]

mwah, ik draai debian stable op productie servers, en daar kan je via backports prima 2.6.38 installeren. Standaard komt 2.6.32 mee. Ik zie geen goeie rede om een jaren oude kernel te gaan draaien op moderne hardware.

[Verwijderd]

Bijna niets??

Dan snap jij werkelijk niets van datacentra.
Stroomverbruik is de grootste kostenpost

[trogdor]

plus koeling, wat daar 1-op-1 aan te relateren is.

[Verwijderd]

Vaak neem je bij een rack een vaste hoeveelheid verbruik af, bv. 2 feeds van 10 of 16A. Je betaalt daarvoor, niet voor wat een individuele server verbruikt. Je rack is dan ook afgezekerd op die waardes. Op wat voor manier je dat verbruik invult is aan jezelf.

[mcmd]

Oei, de berekening moet ietwat anders gaan, een continue vermogen van 2W levert een energieverbruik op jaarbasis het volgende op:
2 (W) / 1000 (W -> KW) * 24 (h) * 365 (d) = 17.5 KWh (per jaar)

Op zich niet veel, maar vermenigvuldig dit maar met de hoeveelheid servers/systemen, en als het vermijdbaar is, waarom dan niet? Ik vind het wel goed dat erover nagedacht wordt en gekeken wordt hoe dit verder gereduceerd kan worden.

[ultra500]

Vergeet ook niet de extra koeling die moet werken omdat er meer warmte geproduceerd wordt. Als je dan uitgaat van 100 servers, kom je wel op een (relatief) grote kostenpost uit, die eigenlijk voorkomen kan worden.

[Ultraman]

Daar zijn nog geen fixes voor voor zover ik.
Ik hoop ook dat ze daar wat aan doen.

[cornedor]

Weer wat te doen . zit nu nog op de 2.6.32-5-686 die standart bij Debian wordt geleverd. Natuurlijk nog even wat performance winst uit proberen te halen door wat drivers uti te zetten

[Verwijderd]

werkt dat echt zo?

[Henk Poley]

Nee. Het boot hooguit iets sneller, want er zijn minder drivers om uit te testen of je daar hardware voor hebt. En in sommige zeldzame gevallen kan je een driver uitschakelen die je hardware weliswaar ondersteunt, maar waarvoor ook een andere betere driver voor is.

[cornedor]

Ik denk dat ik iets te veel drivers heb uitgezet boot nu helemaal niet meer.

[cornedor]

Vast wel, Hij wordt in iedergeval een stuk kleiner. http://goo.gl/xmTyb

[Kosh66]

Da's voor de 2.4-kernel, werkt in de 2.6-kernel toch op een aantal punten iets anders...

[Verwijderd]

Ik denk dat je meer performance winst haalt uit het tunen van je EXT[2|3|4] parameters (zoals noatime) en het beperken van het aantal services dat je boottime start (lelijke meuk als avahi en updated). Je kunt ook nog een beetje mierenneuken met het aantal TTY's dat geladen wordt.

[OrangeTux]

Erg jammer dat de energiebug niet iets gefixed. Mijn accu is nu in een uur leeg! Erg vervelend in een collegezaal met weinig stopcontacten.

[Hiub]

Die bug gaat maar om +/- 6% meer stroomverbruik, dus volgens mij kun je dan beter een nieuwe accu regelen

[Verwijderd]

Dat zou dan gaan om ~4 minuten levensduur...

[ChrissieOne]

Mooi, hopelijk kan ik mijn functietoetsen weer gebruiken inderdaad, die miste ik nogal in Linux...

[Verwijderd]

o_O weh? functietoetsen als in F1 t/m F12?

[Verwijderd]

FN backlight, volume etc... niet de F1 t/m F13

[afraca]

Hoewel je nog paar uurtjes moet wachten verschijnt zometeen ook de erg overzichtelijke kernel newbies changelog

[s.vanrossem]

Gentoo net geupdate naar deze kernel, alleen vanwege die ext4 vernieuwingen.

Verder niks nieuws voor mij specifieke hardware, maar dat is niet gek voor mijn oude bak

[hyriand]

Wellicht interessanter dan de functietoesten is dat de WiFi kill switch en de "silent" / "overclock" modi van diverse Samsung netbooks / subnotebooks (waaronder mijn eigen X125) nu zouden moeten werken. Ook de backlight brightness wordt beter aangestuurd.

(OT: Wel cool om mijn eigen code in de kernel te zien ).