Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 122 reacties

Na een ontwikkelperiode van bijna 2,5 maand heeft Linus Torvalds kernel 2.6.35 vrijgegeven. De verse kernel ondersteunt meer energiebesparende features van Radeon-gpu's en kan overweg met h.264-decoding op recente chipsets van Intel.

In kernel 2.6.34 werden al enkele energiebesparende mogelijkheden van AMD's Radeon-gpu's ondersteund. In de laatste kernelversie zijn deze verder uitgebouwd, waaronder de introductie van vier profielen, en is de code verder geoptimaliseerd. Linux-kernel 2.6.35 kan ook overweg met de toekomstige Intel Ironlake-cpu's. In deze processor-serie is een gpu geïntegreerd.

De kernel biedt op Intels G45-chipset functies om h.264- en vc1-video's hardwarematig te decoderen. Ook wordt de memory self-refresh-functie gebruikt bij Ironlake-processors, wat een energiebesparing van 1W zou opleveren. Verder wordt de turbo-feature van enkele nieuwe AMD Phenom II hexacore-processors herkend en gebruikt.

De ontwikkelaars hebben tevens de ondersteuning voor het btrfs-bestandssysteem verder vergroot door direct i/o-support aan te bieden. Via deze techniek kunnen programma's het caching-mechanisme van de kernel omzeilen, iets wat onder andere door databases wordt gedaan. Daarnaast is het xfs-bestandssysteem verbeterd en heeft het een nog als experimenteel gekwalificeerde journaling-modus gekregen.

In de netwerkstack zijn receive packet steering en receive flow steering opgenomen, technieken die prestatiewinst zouden leveren bij multicore-processors. Ook wordt een aantal nieuwe wifi-chipsets van Atheros ondersteund en is een mechanisme ontwikkeld om geheugenfragmentatie tegen te gaan.

Nu kernel 2.6.35 definitief de stempel van goedkeuring heeft gekregen van Linus Torvalds, zijn de ontwikkelaars alvast begonnen aan de volgende versie. Naar verwachting zal het werk aan 2.6.36 ergens in oktober zijn afgerond.

Moderatie-faq Wijzig weergave

Reacties (122)

Voor iedereen die benieuwd is waar nu aan gewerkt wordt ;) het grootste nieuwtje voor 2.6.36 gaat de integratie van AppArmor worden: http://www.phoronix.com/s...?page=news_item&px=ODQ2Ng
Waarom zitten dat soort features in de kernel en niet in drivers? Zo krijg je op den duur toch een ongeloofelijk bloated kernel?
Waarom zitten dat soort features in de kernel en niet in drivers? Zo krijg je op den duur toch een ongeloofelijk bloated kernel?
Practisch alle drivers worden met de kernel meegeleverd - als losse modules!

Ze staan standaard in /lib/modules geinstalleerd. Dat is inweze niet anders als " C:\WINDOWS\Driver Cache\i386 ". Daar staan ook heel veel drivers al klaar. Je systeem laad alleen de drivers in die nodig zijn, dat alles wordt meegeleverd maakt het niet direct bloated.

De reden waarom alles wordt meegeleverd is heel simpel:
- support voor alle hardware out-of-the-box.
- er is geen extra "compatibiliteitslaag" nodig tussen de kernel (die steeds veranderd) en mogelijke 3rd party drivers (die nog op de oude interface zitten). Windows heeft dit wel, omdat de drivers los geïnstalleerd kunnen worden.
- bij een update van een subsysteem, of ingrijpende wijziging (zoals suspend) worden alle drivers direct bijgewerkt naar deze aanpassingen. Onderhoud aan je driver wordt dus door de kernel ontwikkelaars zelf gedaan!
- Dubbele code tussen drivers (bijvoorbeeld netwerkkaart drivers) wordt verhuist naar een centrale plek.

Ofwel, de kernel is er eerder minder bloated van!

[Reactie gewijzigd door YaPP op 2 augustus 2010 18:30]

Ik heb het spul nog niet bekeken, maar bij de meeste onderdelen in de kernel heb je de mogelijkheid het in de kernel te compilen, maar ook om het als losse module te compilen die je daarna met modprobe kunt laden.

(Zo heb ik een keer ext2 support als module gecompiled als projectje de kernel zo kaal mogelijk te krijgen, daarna volgde een groot D'OH! moment.)
Hehe bekende fout die je maar één keer maakt. Maar ik compileer m'n kernel ook altijd zelf (Gentoo) en als ik alleen maar aavnink wat ik nodig heb qua kernel opties hou ik een kernel over van 2 mb en geen modules, het is dus zo bloated als je het zelf maakt.

Maar zoals gezegd is dit niet voor iedereen weggelegd of niet iedereen heeft daar zin in en dan voldoet een standaard kernel meestal ook prima. Vaak kun je bij de linux installatie ook kiezen waarvoor je hem gaat gebruiken en op basis daarvan wordt een standaard kernel geselecteerd.
Ik ben geen Linux-expert, maar volgens mij omdat dat niet de taak van drivers is. De features zelf zitten in de kernel, de interfacing met de hardware doen drivers.

Bovendien kun je, als je je kernel te groot vindt, zelf een nieuwe compileren met daarin de features die je wilt, en andere features achterwege laten. En je kunt onderdelen als module compileren, zodat hij pas geladen wordt als hij nodig is.
De "linux kernel" bevat sowieso alle drivers.

Dit soort features en/of drivers kan je in de kernel aan en uit zetten, en vaak ook als losse module compileren. Als je hem uitzet wordt je kernel niet groter, als je hem als losse module compileert ook niet, dus alleen als hij standaard in de kernel geladen wordt, wordt de kernel zelf ook echt groter.
in linux heb je niet zozeer drivers, maar wel kernel modules. De kernel zelf is wel flink bloated, en er zijn genoeg discussies over te vinden, maar de memory footprint is dus niet zo erg omdat je toch alleen de modules voor jou systeem inlaad.
De linux kernel komt met een gigantische set drivers. Vanwege het samenspel tussen drivers en kernel wordt dit als 1 geheel ontwikkeld. Elke driver en elk subsystem in de kernel heeft een groepje ontwikkelaars.
Waarom zitten dat soort features in de kernel en niet in drivers? Zo krijg je op den duur toch een ongeloofelijk bloated kernel?
Een kernel module is een driver die in de meeste gevallen als losse module of met de kernel meegecompileerd kan worden. Meecompileren is handig voor bijv. file system drivers en devices die altijd in gebruik zijn zoals HD controllers en netwerk.

Die kernel modules/drivers zijn idd vaak te vinden voordat de volgende kernel versie beschikbaar is en kunnen dmv een patch aan de source code tree worden toegevoegd en sommige ook dmv 'hot-plugging' aan een kernel die al in gebruik is.
Bloated weet ik niet, maar wel een complete in ieder geval. Voordeel is dat veel dingen out of the box werken en dat je er weinig moeite voor hoeft te doen. Je kunt er voor kiezen om bepaalde dingen uit de kernel te halen als je er zelf een compileert, maar dat is niet voor iedereen makkelijk.
Ik gebruik nu zo'n 8 jaar een linux-smaak als hoofd-PC, met daarnaast voor sommige spelletjes windows, eerst 2000 en toen XP, en waar ik de linuxen, eerst Suse en nu Ubuntu, steeds gebruiksvriendelijker geworden vindt, zijn de daarna gekomen windows-versies steeds gebruiksonvriendelijker geworden; om een of andere reden houdt microsoft ervan om het instellen van bv. een netwerkkaart lekker moeilijk te maken (ik werk op een helpdesk en ken de gebruikersperikelen goed: mac-gebruikers hebben nooit gedisablede netwerkkaartjes, windowsgebruikers vaak, en linux-gebruikers bellen nooit voor een internet-verbinding die niet werkt, want daar hebben we het in dit voorbeeld over.

Als je zoals ik nauwelijks spelletjes speelt, en al helemaal geen moderne, is er alleen maar reden om windows te gebruiken als je aan een applicatie vastzit; zo weet ik vrij zeker dat Autocad niet onder Wine gebruikt wordt in de bouwwereld..............

Ik vindt het eigenlijk vrij opvallend dat het marktaandeel van Linux op de desktop niet veel groter is geworden de laatste jaren, waar Mac wel zijn aandeel flink vergroot heeft........
Volgens mij heeft plm. de helft van de windows-gebruikers meer aan Ubuntu dan aan Windows 7 :o

hansli
Ik vindt het eigenlijk vrij opvallend dat het marktaandeel van Linux op de desktop niet veel groter is geworden de laatste jaren, waar Mac wel zijn aandeel flink vergroot heeft...
Ik vind het niet raar. Hoewel ik geen Apple-fan ben, hebben ze een paar dingen duidelijk beter voor elkaar:

- Consistentie. De interface ziet er gewoon goed uit. Kun je de ene Mac bedienen, dan kun je dat ook met de andere. Probeer dat eens met Linux, als er bij ieder een andere desktop is geïnstalleerd.

- Je kunt in de winkel de laatste 10 jaar, in elk geval sinds OSX, willekeurig welk apparaat uit het rek trekken. CD-tje in je Mac gooien, installeren, en meestal werkt het. (Nou ja, zou moeten. Zie genoeg gevallen van niet, maar er zijn tenminste drivers.)

- Uniformiteit en duidelijkheid. Eén OS. Eén bedrijf, één aanspreekpunt. Niet 500 distro's en 786 fora met een ernstig versplinterde documentatie.

- Bekendheid. Marketing, reclame....

- De beschikbaarheid van bekende en veel gebruikte applicaties is gewoonweg groter. Langzaamaan begint men op de Mac zelfs te gamen, en dan niet één jaar later geporte oudere spellen, maar huidige titels. Er zijn bedrijven die spellen voor Linux uitbrengen, maar die spellen en bedrijven kun je op 1 hand tellen. Sommige ontwikkelaars hebben het zelfs geprobeerd en opgegeven vanwege de moeilijkheden, veroorzaakt door de diversiteit aan distro's (Bioware, met Neverwinter Nights 1).

- Als het moet kan ik nog even doorgaan....

[Reactie gewijzigd door Katsunami op 2 augustus 2010 23:30]

- Consistentie. De interface ziet er gewoon goed uit. Kun je de ene Mac bedienen, dan kun je dat ook met de andere. Probeer dat eens met Linux, als er bij ieder een andere desktop is geïnstalleerd.
Appels met peren. Het enige wat al die distributies bindt is hun kernel. Als je dus ernstige vergelijkingen wilt maken, moet je OS X niet alleen met OS X vergelijken, maar met alles waarmee het een basis deelt: BSD, Solaris, HPUX, AIX, TRU64 (allemaal UNIX). Benieuwd of je dan nog zoveel consistentie overhoudt.
Verder vind ik het vreemd dat je het voor gebruikers een last vindt dat desktops uiteenlopen, terwijl je impliceert dat ze die eerst zelf zo hebben ingesteld. Waarom zouden ze dat dan doen? Masochisme? Of zou dat nu juist een van de voordelen zijn?
- Uniformiteit en duidelijkheid. Eén OS. Eén bedrijf, één aanspreekpunt. Niet 500 distro's en 786 fora met een ernstig versplinterde documentatie.
Zie hierboven. Hoeveel commerciële partijen zijn er die Linux aanbieden? RedHat, Novell en Canonical en misschien Mandriva.

[Reactie gewijzigd door Pleroma op 3 augustus 2010 10:43]

Appels met peren. Het enige wat al die distributies bindt is hun kernel. Als je dus ernstige vergelijkingen wilt maken, moet je OS X niet alleen met OS X vergelijken, maar met alles waarmee het een basis deelt: BSD, Solaris, HPUX, AIX, TRU64 (allemaal UNIX). Benieuwd of je dan nog zoveel consistentie overhoudt.
Niet relevant. OSX is een systeem op zichzelf, want niemand gaat grote native OSX software draaien op systemen als BSD of Solaris. Misschien zijn er pakketten die voor zowel OSX als de andere Unixen bestaan, maar het is gewoon niet van toepassing, omdat OSX zijn "eigen" systeem is. Er is maar weinig verloop tussen OSX en de UNIXEN, terwijl er heel veel verloop is van distro naar distro onder Linux.
Verder vind ik het vreemd dat je het voor gebruikers een last vindt dat desktops uiteenlopen, terwijl je impliceert dat ze die eerst zelf zo hebben ingesteld. Waarom zouden ze dat dan doen? Masochisme? Of zou dat nu juist een van de voordelen zijn?
Voor de zeer gevorderde gebruiker is het een voordeel maar voor de starter is het één grote hel. Wat moet je kiezen? Gnome? KDE, iets anders? En dan heb ik het nog niet eens over keuzes binnen het systeem... ALSA, toch maar het oudere OSS, EXT2, 3, 4, of toch maar ReiserFS?

Ubuntu probeert een linux-voor-de-starters te zijn, maar dat proberen er wel meer. De community moet zich verenigen, en uiteindelijk zeggen:

*DIT* (toont een distro, volledig afgewerkt en al, van desktop tot en met keuzes binnen het systeem) is Linux. En dan niet 5 distributies die dat proberen, maar ook echt één (1) distributie waar de hele community achter staat. En dan kun je wel stellen: "Als je het wil, dan kun je later overstappen op een van de 5.000 andere distributies, of deze hier aanpassen. Echter, als je -deze- gebruikt, dan weet je altijd zeker dat al je hardware en software (consistent) werkt."

Als de Linux-community dit voor elkaar zou krijgen, dan gaat het werken, en dan ga ik zelf ook denken om over te stappen. Als ik nu zou overstappen van Windows naar eits anders, dan zou ik zonder nadenken voor FreeBSD kiezen, simpelweg omdat de BSD-wereld veel minder versplinterd is.
En helaas zijn dit maar een paar van de minder sterke punten
hoe lang duurt het doorgaans dat deze kernel via de apt-get bij mijn ubuntu update aankomt?

edit:
Thx voor de vele reacties! ;-)

[Reactie gewijzigd door FiVAL op 2 augustus 2010 15:10]

Een maandje of twee. Beter kun je een kernel van kernel.org halen (2.6.35 source of patch) en dan een custom kernel maken. Is niet zo moeilijk.
Is niet zo moeilijk.
Yeah right dat is echt heel erg subjectief. Het is echt niet zomaar makkelijk, je moet heel veel van je hardware weten bijvoorbeeld.

Met Genkernel wordt wel weer een stuk makkelijker, die compileert gewoon alles en rekent op hotpluggen voor de juist configuratie.
Helemaal niet, je kijkt naar je dmesg en typt 'lspci' in om vervolgens de juist hardware in een menu te selecteren. Je hebt eigenlijk totaal geen kennis van hardware nodig als je de output van 2 commando's weet te interpreteren.

Er zijn honderden howto's online te vinden die het je haarfijn stap voor stap uit leggen. Als je een lego doosje kan nabouwen aan de hand van een plaatje kun je ook een kernel compilen imho.

[Reactie gewijzigd door Sorcerer op 2 augustus 2010 15:11]

Voor iemand die zelf kernels compiled heeft sinds 1.2.13, met de 1000-vragen script (menuconfig bestond nog niet) is er toch wel ernstig veel bijgekomen tegenwoordig.
De opmerking dat het bijna triviaal is geworden klopt niet imho.

Alleen voor de echte tweaker zijn de mogelijkheden echt te doorgronden. (Ken uw hardware door en door, ken uw netwerk door en door ...)
Erger nog, de meeste handgebouwde kernels bieden eigenlijk geen voordelen boven de distributiekernels. Er gaan allerlei spookverhalen over dat voorgecompileerde kernels langzaam zouden zijn maar voor de meeste mensen gaat dat niet op.
De grootste winsten zijn te behalen bij het opstarten. Als je die paar seconde langer opstarten voor lief neemt dat is een distrokernel voor de meeste mensen meer dan goed genoeg.
Er is nog wel enige winst te halen maar die weegt niet op tegen de hoeveelheid werk die je moet doen om zo'n kernel te bakken. En als je niet precies weet wat voor hardware en features je wil gebruiken dan heeft het sowieso weinig zin. De kans dat je er netto op vooruit gaat is minimaal.
Als je vreemde hardware hebt of een speciale toepassing hebt liggen de zaken anders, maar voor normaal desktop & server gebruik voldoen de distrokernels prima.
Helemaal mee eens, ik heb al behoorlijk vreemde kernels gecompileerd ondertussen, maar als ik nu een willekeurige laptop krijg en ik moet er een kernel voor bouwen, dan ben ik daar al snel een uurtje mee bezig hoor.

Natuurlijk kan je gewoon heel de wereld mee compileren en alle gekke low-level opties laten voor wat ze zijn, maar dat is nou net niet het idee.
"Als je een lego doosje kan nabouwen aan de hand van een plaatje kun je ook een kernel compilen imho."

Oohh...dat zal ik vanavond meteen even testen met mijn neefje van 6 :+
make oldconfig herbouwt simpelweg de kernel op de manier zoals de vorige is gebouwd (waarschijnlijk degene die dus in je distributie zat). 99 van de 100 keer is dit wel genoeg, zonder ook maar iets van je hardware te weten.
Niet perse. Je kunt het nieuwe kernel alle settings van je oude kernel mee laten nemen he. En dat werkt gewoon goed.

Tuurlijk is het handig als je weet wat voor hardware je in je doos hebt zitten als je van tweaken houd. Wat ik probeer te zeggen is dat het voor een leek ook mogelijk is (op de makkelijke manier). Probeer dit maar eens:

cat /boot/config-`uname -r` voor een complete lijst kernel- en compileropties die je nodig hebt om een kernel te compileren. (bron: http://www.howtoforge.com/kernel_compilation_ubuntu_p2 )

@robin1979
Die kende ik nog niet, maar 't werkt wel als een trein! Dankje

[Reactie gewijzigd door sfranken op 3 augustus 2010 00:19]

De regel "ppa:kernel-ppa/ppa" toevoegen aan Systeem -> Beheer -> Softwarebronnen is voldoende hoor.. Al dat gepriegel met keys en zo ;)
Dan wil Ubuntu nog steeds een key hebben hoor... :+
dan doe je "apt-add-repository ppa:kernel-ppa/ppa" en dan gaat 't automagisch.
Nee hoor, dat gaat automatisch.
Geef er dan wel even bij aan dat dit dus unsupported is, voordat iemand z'n installatie sloopt omdat sommige zaken nog niet getest zijn. ;)
Gemiddeld een half jaartje. Ubuntu 10.04 maakt nu gebruik van 2.6.32 die uit december '09 komt.
Overigens is dat wel afhankelijk van welke repository's je enabled hebt.

@Sh4wn: vergeet niet dat 10.04 een LTS versie is die dus wel de nodige kernelupdates gaat meemaken :)

@tetraplan: dat zeg ik dan ook hierboven ;) afhankelijk van welke repository's je gebruikt.
Uitgaande van de reguliere repository's met niet al teveel unstable materiaal duurt het al snel een 3 maanden tot half jaartje hoor.

[Reactie gewijzigd door JapyDooge op 2 augustus 2010 15:02]

2.6.35 zit al in de kernel-ppa: https://launchpad.net/~kernel-ppa/+archive/ppa
Installeren op eigen risico.
Installeren op eigen risico.
Is dat niet met alle GPL software zo, tenzij je een speciaal support contract afsluit eromheen (indien mogelijk)? :?
Canonical support de standaard kernel, en die support vervalt als je er eentje uit een kernel ppa installeert. Dat bedoelde tetraplan ;)
Nee, GPL zegt daar niets over, GPL definieerd enkel wat er allemaal wel en niet mag met de code. Je kunt er dezelfde support op geven of laten als bij elke andere software, en net zoals bij alle andere software is de autheur niet vrij van aansprakelijkheid.
Is dat niet bij alle software zo? Of heb jij wel eens een schadevergoeding gekregen na een crash in Windows?
Het zou een goed idee zijn :+
@Sh4wn: vergeet niet dat 10.04 een LTS versie is die dus wel de nodige kernelupdates gaat meemaken
Kernel updates voor 2.6.32 ja, met wellicht wat backports uit latere versies. Volgens mij switched Ubuntu nooit van kernel versie tussen releases en blijven ze gewoon de originele versie patchen.
Meestal neemt Ubuntu de nieuwe kernel pas met de volgende release mee dus waarschijnlijk 10.10
Onzin (?) mijn Ubuntu 10.04 desktop zit al op zijn derde kernel :?
Dat zijn meestal minor (security) changes, van 2.6.32.een-beetje naar 2.6.32.een-beetje-meer.
Major changes, van 2.6.34 naar 2.6.35 worden meestal niet in een bestaande release geupdate, omdat de interface aangepast kan zijn, en security en useability updates ook op lagere kernels toegepast worden.

Het verschil tidden een kernel update en een kernel update is dus best groot :)
Nooit. Alleen bij een nieuwe release wordt de kernel in ubuntu geupdate, dus dat zal in oktober zijn met versie 10.10, welke deze kernel zal bevatten ;)
Ik bewonder de gedrevenheid van alle mensen die hier aan werken. Ik heb jarenlang Linux gebruikt en heb dus ook regelmatig nieuwe kernel updates voor mijn kiezen gekregen. Nooit heb ik enige verbetering gemerkt van zo'n update (bv in de vorm van performance of nieuwe features). De enige verbetering die ik ooit gemerkt heb was de update van kernel 2.2 naar kernel 2.4 (in 2001) toen er usb support kwam. Bij alle andere updates was de enige merkbare verandering een nieuwe entry in mijn grub/lilo menu als ik m'n computer startte.

Over het algemeen vind ik dat de ontwikkeling van Linux niet overeen komt met mijn prioriteiten/wensenlijst. Ik wil niet zo zeer verbeteringen aan de kernel, maar meer op applicatie gebied. Alle distributies gaan prat op het grote aantal packages in hun repositories (vaak meer dan 15000). In de praktijk gebruik ik echter hooguit een tiental applicaties. Daarvan wil ik dan wel dat ze heel goed werken. Te vaak stuit ik op programma's die onder Windows wel beschikbaar zijn of goed werken, en onder Linux niet.

Samenvatting van mijn relaas in cartoonvorm.
Denk dat je wel een beetje gelijk hebt. Hoewel er ontzettend hard gewerkt wordt, zit vele Linux distro's gevoelsmatig een beetje rond win98 se niveau. Op veel fronten mooie dingen, vooral eyecandy, maar desktop functionaliteit ligt gewoon nog wat achter tov Win7.

Op server niveau zijn de rollen omgedraaid. 40 jaar Unix inmiddels. _/-\o_
Hoewel er ontzettend hard gewerkt wordt, zit vele Linux distro's gevoelsmatig een beetje rond win98 se niveau.
In welk opzicht is dit windows 98 achtig? http://www.kde.org/worksp...shots/general-desktop.png :P

Misschien dat je een andere standaard Linux interface steeds bekijkt?

Op iedere Linux distro wordt dezelfde software gezet, dus distributies vergelijken voor verbeteringen aan de software heeft niet veel zin. ;)
Prachtig :), maar er wordt hier alleen maar over de interface gepraat, maar iedereen gaat voor bij aan de functionaliteit van de software zelf. Ik snap wel dat ik dan op teentjes trap, maar ja zo zij het..
Ok, maar welke functionaliteit mis je dan in Linux distributies?
- Kleurkalibratie voor monitoren.

- Een kernelinterface waarvoor een fabrikant gewoon drivers kan schrijven, zodat de driver er niet uit knalt bij de volgende kernelupdate. Dat is de reden waarom veel fabrikanten Linux drivers links laten liggen. Ondanks dat het beter wordt, is het toch nog vaak danig uitkijken met hardware die je koopt, vooral dingen als all-in-one printers.

- Een gemakkelijke mogelijkheid om softtware buiten een repository om te kunnen installeren. (Dubbelklikken, next, next, finish.) Dit geldt overigens ook voor drivers.

- Goede fonts. Hoewel lettertypen beter worden, moet je nog veel toeren uithalen zoals FreeType zelf compileren om hinting erin te krijgen, en dan moet je ook nog goede lettertypes hebben. De lettertypen in Windows en OSX zijn gewoon beter.

- Een standaard manier van werken. De ene distro update met apt, de andere rpm, yum, yast, rolling updates, weet ik wat al niet meer. Config files die in de ene distro zus werken, kunnen in een andere distro ergens anders staan, anders werken, of in het geheel niet bestaan.

- Voor veel applicaties op Windows zijn simpelweg geen (waardige) vervangers beschikbaar.

[Reactie gewijzigd door Katsunami op 2 augustus 2010 23:23]

- Kleurkalibratie voor monitoren.
- Een gemakkelijke mogelijkheid om softtware buiten een repository om te kunnen installeren.
- Goede fonts.
Geheel mee eens.
- Een kernelinterface waarvoor een fabrikant gewoon drivers kan schrijven
Gaat niet gebeuren. Dat is by design. Wat de kernel developers veel liever hebben, is dat je ze documentatie aanlevert, of je eigen code in de kernel krijgt.

Dat heeft een paar voordelen:
- De driver kan geschikt gemaakt worden voor de ~10 architecturen waar Linux op werkt.
- De dubbele code kan uit drivers, op een centrale plek in de kernel.
- Er hoeft geen ingewikkelde compatibility-laag uitgedacht te worden om dit idee waar te kunnen maken.
- De driver wordt veel langer bijgewerkt / onderhouden voor nieuwe versies.

Voor een fabrikant is iedere update immers verlies van winst, je hebt eenmalig bij de aanschaf van een apparaat inkomsten gekregen. Linux ondersteund meer apparaten out-of-the box, en was eerder met 64bit support omdat alle sourcecode van drivers beschikbaar is. Het onderhoud is geheel door de kernel ontwikkelaars gedaan.

Je mag er ook van uit gaan dat die-hard kernel ontwikkelaars beter in staat zijn drivers te maken dan een willekeurig bedrijf.
- Een standaard manier van werken. De ene distro update met apt, de andere rpm, yum, yast, rolling updates, weet ik wat al niet meer. Config files die in de ene distro zus werken, kunnen in een andere distro ergens anders staan, anders werken, of in het geheel niet bestaan.
Verschillende ideeen, verschillende distributies. Dat wordt wel meer gelijk, maar zal nooit helemaal hetzelfde worden. Sommige mensen willen een vast stabiel systeem, anderen willen voortdurend updates van componenten. Dat ga je niet hetzelfde krijgen. Alsof iedereen voor 1 politieke partij moet kiezen.

[Reactie gewijzigd door YaPP op 3 augustus 2010 00:04]

Uhm, config files staan altijd in /etc/. Dat is dus niet variabel (of je applicatie moet lak hebben aan de afspraken die gemaakt zijn). En de vele manieren van pakketbheer is inderdaad wat verwarrend, maar gelukkig kun je altijd vanaf source iets builden als het er niet is voor je packagemanager, toegegeven dat is niet voor een leek maar het werkt wel.
Een fatsoenlijk en robuust video platform voor conforming, encoding en met name editing is een van de eerste dingen die in mij op komt.
Final Cut Pro heeft voor mij nu de kroon maar al mijn hoop gaat uit naar de open sourcing van Lightworks.

Daar naast meer ondersteuning voor commerciele games. Hopelijk gaat dat veranderen als steam en de source engine word geport!
Welke van deze pakketten voldoen niet?
Allemaal en geloof me ik heb ze allemaal geprobeerd op projectmatige basis.
Alleen blender gebruik ik altijd maar dan voornamelijk voor de 3d mogelijkheden.
Daar zijn de meningen ook over verdeeld, qua eyecandy vind ik de meeste distro's achterlopen buiten de compiz effecten om, de standaard theme's zijn meestal niet echt om naar huis te schrijven hoewel dat ook hard aan het verbeteren is, qua functionaliteit zijn de linux distro's juist heer en meester ten op zichten van Windows door de fantastische terminal en de betere performance, misschien dat het nog niet opgaat voor de gemiddelde thuisgebruiker maar voor de geavanceerde gebruiker zijn de mogelijkheden eindeloos, iets wat je van Windows niet kan zeggen daar kan je hoogstens wat aanpassingen doen in de regedit en dan houd het op.
Vergeet die hele plasma zooi niet te vermelden bij een discussie over desktop functionaliteit. Geloof niet dat enig ander OS ze ver is (hoewel, je kunt windows ook optunen met KDE).
Daar heb je ook weer een punt :)
Denk dat je wel een beetje gelijk hebt. Hoewel er ontzettend hard gewerkt wordt, zit vele Linux distro's gevoelsmatig een beetje rond win98 se niveau. Op veel fronten mooie dingen, vooral eyecandy, maar desktop functionaliteit ligt gewoon nog wat achter tov Win7.
Er is voor Linux op sommige vlakken minder software beschikbaar, en niet alles wil draaien onder Wine, maar afgezien daarvan kan ik je mening niet delen. Alleen al het feit dat ik onder Linux meerdere, virtuele, bureaubladen kan hebben vind ik al een flinke bonus (en die optie bestaat al vele jaren). Daarbij komen dan nog de compositing effecten die wél nuttig zijn (wie heeft er ooit bedacht dat vensters 'wobbly' moeten zijn) en een aantal leuke opties voor het beheren van de vensters. Nee, ik zie niet hoe moderne Linux distros op dit vlak meer dan tien jaar achter zouden lopen op windows.
Qua bureaublad- en vensterbeheer en theming (=uiterlijk) lopen sommige open source OS-en ver voor op Windows. Jammer genoeg lopen ze wat betreft beschikbaarheid van goede desktopapplicaties ver achter. Dat is eigenlijk best jammer.
Linux is dan ook geen besturingssysteem, maar een kernel. :+
Wikipedia denkt daar anders over.
Maar in principe staan de applicaties wel los van Linux. Ik heb dan ook niet zo zeer problemen met Linux (als kernel en/of OS) maar meer met de applicaties die er (niet) voor beschikbaar zijn.
Daar hebben ze het eigenlijk over GNU/Linux. Linux is de kernel, GNU heeft er een heleboel tools voor gemaakt.
Het is niet de discussie die ik wil voeren, maar waar wordt GNU genoemd in deze zin?
Linux is the generic name for a UNIX like operating system that can be used on a wide range of devices from supercomputers to wristwatches.
Daar komt bij, de titel van dit topic is: "Linux-kernel 2.6.35 uitgebracht". Als Linux de kernel zou zijn, waarom heet het dan niet "Linux 2.6.35 uitgebracht"?

Ik denk dat er in de praktijk verschillende definities gebruikt worden door verschillende mensen. Maar ik wil de Linux/taalpuristen niet voor het hoofd stoten. Laat ik dan toevoegen dat ik in mijn bovenstaande posts met Linux het gehele besturingssysteem (inclusief kernel) + applicaties bedoelde. In mijn beleving wordt ook meestal gerept over de Linux-kernel als daadwerkelijk de kernel bedoeld wordt.

Uiteraard snap ik dat mensen die aan de Linux kernel werken niet over de applicaties gaan. Het punt is dat als ik een complete Linux distributie installeer, zoals Ubuntu of Suse, dat ik dan aan de applicatie kant vaak wat dingen mis.
De verwarring ontstaat over het gebruik van het woord Linux. Linux is tegenwoordig bijna synoniem voor een compleet besturingsystem terwijl het eigenlijk alleen maar de kernel is. Daarom willen de Linux/taalpuristen (zoals Richard Stallman) ook dat je het hebt over GNU/Linux om verwarring te voorkomen. (tenzij je natuurlijk geen GNU programma's gebruikt. :+ )
The GNU project is a mass collaboration of programmers who seek to create a completely free and open operating system that was similar to Unix but with completely original code. It was started in 1983 by Richard Stallman, and is responsible for many of the parts of most Linux variants. For this reason, Linux is often called GNU/Linux.
Misschien is het ook beter om te zeggen dat je ubuntu, Fedora of [distributienaam] gebruikt. Ik zeg zelf liever dat ik debian en Android gebruik dan alleen Linux.

[Reactie gewijzigd door dracozna op 2 augustus 2010 17:23]

Ach, je zou het dan ook net zo goed GNU/X.org/GNOME/Pidgin/Firefox/volledigeLijstMetAndereApplicaties/volledigeLijstMet3thPartyDrivers/volledigeLijstMetLibraries/Linux kunnen noemen, maar ja.. Dat gaat weer iets te ver.

Kernel updates merk je over het algemeen niet veel van, maar als er een nieuwe driver voor je sound card (2.6.32 intel hda drivers) komt, ben je wel degelijk blij met de geweldige geluidskwaliteit!
In de volksmond wordt idd met Linux vaak het gehele pakket bedoeld, media nemen dat simpelweg ook zo over. Technisch gezien is Linux dus alleen een kernel, vandaar de reactie van cumulus. ;)
Just vanwege dit soort dingen (GNU/Linux <-> Linux) en het toevoegen van een overdaad aan keuze (10 bestandssystemen ofzo...) zorgen ervoor dat Linux zo klein blijft op de desktop.

Wanneer pakt men zich eens samen, en ontwikkelt men 3 Linuxvarianten, gebaseerd op de grootste distro? Bijvoorbeeld, Debian als APT-distro, Red Hat / Suse als RPM-distro, en Gentoo / Arch als rolling distro. Binnen die 3 kun je dan deferentieren, bijvoorbeeld de APT-distro als "wat ouder maar ultra-stabiel en bewezen", de RPM-distro als "voor de nieuwere hardware", en de rolling distro voor "bleeding edge software".

Uiteraard moeten alle drie systemen aan het eind van de rit wel dezelfde applicaties kunnen draaien.

Het moet best kunnen, want in de BSD-wereld gaan, voor zover ik weet, OpenBSD, NetBSD en FreeBSD zo te werk. Verschillende filosofieën, maar wel uitwisselbare systemen. Ken je de ene BSD, dan ken je de andere. Bij Linux is dat lang niet altijd het geval.
Bij de diverse BSDs heb je ook genoeg diversiteit. Veel dingen komen overeen, maar in OpenBSD zitten bijvoorbeeld een heleboel dingen niet geimplementeerd die in FreeBSD en NetBSD wel zijn geimplementeerd.
Linux is dan ook geen besturingssysteem, maar een kernel. :+
In ieder geval is Linux niet de applicaties die op Linux daaien (waar slow whoop het over heeft).

Over de Lunix kernel klagen ivm apps is toch echt "barking up the wrong tree".
Ik wil niet zo zeer verbeteringen aan de kernel, maar meer op applicatie gebied.
Dan moet je niet gaan klagen bij de projectgroep die de kernel onderhoud :P

Voor de grafische schil moet je zijn bij:
- KDE: www.kde.org
- GNOME: www.gnome.org

Waarbij ik KDE veel frisser er uit vind zien dan GNOME. GNOME is wel simpeler, maar ook "saai".
Als ik dan bovenstaande screenshot zie ( http://www.kde.org/worksp...shots/general-desktop.png ) Ben ik blij dat ik Gnome gebruik, christus wat een drukte.

</offtopic>
Het komt dan niet in je op dat er juist zo veel mogelijk functies op één schermafdruk weergegeven worden?
Voor applicaties moet je dan ook niet bij de Kernel zijn, maar bij de grafische schillen zoals Gnome en KDE ;)
Moet je voor de apps niet gewoon bij de app bakkers zijn?
...en anders bij je favo IDE.
<offtopic> Wat nu als Linus komt te overlijden?
Hij is niet de enige die aan de Kernel werkt ;)
Maar zoals ik het begrijp wordt wel elke kernel modificatie bij hem ter goedkeuring gelegd. Zonder hem, geen toevoegingen etc etc. Heeft ie vast allemaal goed geregeld, daar niet van, maar waar staat dat dan?

Want eerlijk gezegd vind ik voor een 'open communitiy' <http://www.linuxmark.org/> hier niet echt duidelijk in. Al staat er op <http://en.wikipedia.org/wiki/Linux_Mark_Institute> weer iets meer bemoedigende info...
Ja en nee:
In de praktijk volgt iedereen de kernel die Linus publiceert maar dat hoeft helemaal niet.
Het is open-source software met GPLv2 license dus als je denkt dat je het beter kan kan je een eigen versie beginnen..

Ook technisch is dit een fluitje van een cent. De kernel wordt in GIT bijgehouden.
GIT is een gedistribueerde versioning tool waarbij iedere node gelijk is.
Er is dus eigenlijk helemaal geen centrale versie, ware het niet dat toevallig iedereen de kernel bij Linus vandaan haalt omdat die versie het beste blijkt te zijn.
Mocht je echter denken dat jou versie veel beter is (en Linus jouw patch niet merged) kan je dit gaan verkondigen en proberen om mensen/distro's jouw versie te laten gebruiken...
In de praktijk volgt iedereen de kernel die Linus publiceert maar dat hoeft helemaal niet.
Het is open-source software met GPLv2 license dus als je denkt dat je het beter kan kan je een eigen versie beginnen..
Komt nog bij dat praktisch elke distro een customized kernel gebruikt met eigen aanpassingen, backports, non-free kernel modules etc. Het is dus zeker niet zo dat de kernels die je bij Ubuntu, Suse, Fedora, whatever krijgt alleen maar code bevatten die door Linus Torvalds is goedgekeurd.

Ik geloof ook niet dat Torvalds elke regel kernel code zelf gaat zitten reviewen en goedkeuren, er zijn nog een heel aantal andere grote kernel-guru's die die status niet voor niks hebben gekregen, en die worden waarschijnlijk voldoende vertrouwd om wijzigingen in bepaalde subsystemen goed te keuren zodat Linus ze alleen nog maar hoeft te mergen in de mainline.
Zoals ik het uit sommige presentaties van youtube begrijp heeft hij 2-3 mensen die hij in zoverre vertrouwt dat hij de code van deze personen wel direct opneemt in de kernel, of code waar deze mensen naar hebben gekeken. De rest bekijkt hij echter wel persoonlijk om te zien of het wat is of niet.. tenminste dat is wat ik me nog kan herinneren van Linus Torvalds google talk GIT Presentatie

* Xthemes.us vind het een uiterst amusante presentatie ;) - Even iets heel anders dan Jobs/Gates.

edit:
Ah rond de 28 minuten word het uitgelegd ;) - Hij vertrouwd 5-10-15 mensen waar de code vandaan word gehaald, en die doen hetzelfde. En ik neem aan dat er sommige zijn die de code nog een keertje goed doorkijken ;)

[Reactie gewijzigd door Xthemes.us op 2 augustus 2010 16:58]

tja zo doe ik het in mijn teams ook. ik lees alle code die ingechekd wordt
Heb je zo'n klein team dan ? Of zijn ze gewoon langzaam :)
Maar zoals ik het begrijp wordt wel elke kernel modificatie bij hem ter goedkeuring gelegd. Zonder hem, geen toevoegingen etc etc.
Nee. Iedereen kan wijzigingen publiceren, en zelf de centrale rol vervullen.

Linus leest zelf niet alle regels code door. Hij heeft ook niet verstand van alle onderdelen van de kernel. Tussen rc1 en de final versie alleen al zijn er 2000! commits toegevoegd!! Onmogelijk dus om alles door te lezen.

Wat Linus doet is een een aantal "luitenanten" code laten controleren op hun vakgebied (bijvoorbeeld netwerk, USB of suspend). Zij hebben om hun beurt ook weer mensen die specifieke delen hebben doorlopen, en code ontvangen hebben. Bij minder ervaren ontwikkelaars hebben ze bijvoorbeeld met hun samengewerkt om goede code op te leveren. Die code sijpelt langzaam omhoog naar de centralere repositories.

Iedereen heeft een eigen GIT repository waarin je code kunt binnenhalen, en (als je toegang hebt) ook kan opsturen naar anderen. Wat de luitenanten aanleveren kan Linus weer in zijn GIT repository binnenhalen.

Iedereen zou die centrale rol kunnen spelen. Je zet een GIT repository op, en haalt de code binnen van anderen, en verkondigd jouw versie op het web. Echter vind iedereen dat Linus goed werk levert, en heeft hij defacto de leiding gekregen. Als Linus wat zegt, luisteren anderen. Niet omdat hij een dictator met macht is, maar omdat hij zinnige dingen zegt en doet.

Mocht Linus dat niet doen, zou iedereen ook bij een van de andere core-ontwikkelaars ook de code kunnen binnenhalen. Het systeem blijft gewoon doorlopen, met of zonder Linus.

Iemand die zo'n rol vervult noemen ze ook wel een Benevolent Dictator For Life

[Reactie gewijzigd door YaPP op 2 augustus 2010 16:59]

Een gebrek aan achtergrondkennis heeft nog nooit iemand tegen gehouden om een reactie op tweakers.net achter te laten. Begrijp me niet verkeerd, zo moet het ook zijn.

Als Linus alle individuele goedkeuringen zou doen, betekent dit dat hij 2 miljoen regels code per jaar controleert. Onmogelijk. Een dergelijke wurggreep zou bovendien totaal strijdig zijn met het concept dat hij voorstaat.

Hier dan wat achtergrondinfo: de grootste bijdragen komen van Red Hat, IBM, Intel, Novell, Oracle en SGI. Linus komt ws. niet eens voor in de top 20 van individuen die het meest bijdragen, noch in de top 10 van degenen die de meeste commits maken.

Met name wanneer er belangrijke besluiten genomen moeten worden, zal Linus naar de voorgrond geduwd worden. Ik geloof niet dat hij dit zelf nastreeft. Sterker nog, het zou me niets verbazen als hij het over een paar jaar gehad heeft met Linux en weer een nieuw project start.

De mensen die dat als ramp zien, snappen de geest niet waarin hij handelt.
Maar zoals ik het begrijp wordt wel elke kernel modificatie bij hem ter goedkeuring gelegd. Zonder hem, geen toevoegingen etc etc.
Je begrijpt het grondprincipe van de GPL denk ik nog niet helemaal.

Iedereen kan die sourcecode oppakken en ermee doen wat ie wil, dus niet alleen als Torvalds komt te overlijden, maar ook gewoon als je het er niet mee eens bent.
Er hoeft helemaal niets vastgelegd te zijn, iedereen staat het vrij het op zich te nemen.
dat is idd het mooie van linux maar ook het probleem.

Het mooie is dat het open is en iedereen er aan werken c.q het verbeteren kan.
Het slechte is dat er zo veel verschillende versies zijn met ieder hun eigen interpretatie en eigen werkwijze. Windows is Windows OSX = OSX maar linux is niet latijd linux
Nee. Linux is alleen de kernel en die heeft een stabiele API. Je programmeert, als normale devver, in userspace. Bijvoorbeeld met C++ tegen QT, C tegen Gnome of in Java ofzo. Je kunt je software van die je in 2000 maakte in Java gewoon draaien op deze kernel. Dit is dus precies net zoals Windows (en in mindere mate MacOSx dat pas sinds 2002 bestaat).
Dus: Windows is geen Windows (zie games die het alleen doen op Vista en hoger (DirectX 10)) en andere zaken die zorgen dat je software het niet doet. Dit probleem bestaat voor alle OSen maar alleen in de breedste zin van het woord indien je de userspace meeneemt.
Als je je dan ook nog realiseert dat je in Linux meerdere versies van shared-libraries kan hebben dan speelt het probleem zelfs veel minder dan in Windows (weet niet hoe het zit met MacOSx). In Windows kun je een DLL van een product slechts in 1 versie installeren. M.a.w. als je nieuwe en oude software wilt draaien die alletwee afhankelijk zijn van een shared library met verschillende versies lukt dit niet op Windows en wel op Linux. Dus eigenlijk had je moeten zeggen Linux=Linux en de rest is een gok :)

[Reactie gewijzigd door latka op 2 augustus 2010 22:54]

Naar mijn weten is de dll hell met winsxs in XP en met name Vista opgelost, maar dat terzijde.

Meer ontopic vraag ik me af waarom de hier genoemde zaken in de kernel moeten, bedoel de ondersteuning van een radeon is, zou je zeggen, toch een pure hardware aangelegenheid en dus voer voor normale drivers?
Alle drivers die enigszins onderhouden moeten worden worden met de kernel gebundeld. Tevens is er generieke VGA support in de kernel (KMS als ik het goed heb) zodat de kernel een aantal zaken voor alle drivers uit handen kan nemen.
Je kunt je driver dus los hebben, maar de enige API die gegarandeerd stabiel is is de userspace API en daar programmeer je niet tegenaan. Vergelijk dit met Windows heb je hetzelfde: een Windows 2000 driver doet het niet op Windows 7 (en zeker niet andersom): het is gewoon onwijs moeilijk om backwards compatible te zijn en als je dan het aantal drivers tegen het aantal user-applicaties uitzet mag duidelijk zijn dat backwards compatibiliteit voor drivers nauwelijks interresant is. Gevolg is wel dat out-of-kernel zijn van een driver veel werk meebrengt (patches up-to-date houden en testen of je driver niemand in de weg zit). Dit is ook direkt de reden dat je, zelfs al is er een out-of-kernel-driver je beter de in-kernel variant kunt hebben: geen leverancier die de moeite neemt zijn spullen echt goed te testen.
<offtopic>Dan gaat het project gewoon door want dan wordt het door andere overgenomen lijkt mij, meer open source.
vragen naar de bekende weg :P

<ontopic>

Ik vindt dit wel een aanzienlijke verbetering in de kernel.
Ik ben benieuwd wanneer deze kernel in nieuwe linux varianten zoals ubuntu toegepast gaat worden.
Met name de power saving features zijn interessant en ondersteuningen voor turbo modus spreken mij wel aan.

[Reactie gewijzigd door Mietex op 2 augustus 2010 15:02]

Ubuntu 10.10 die op 10 oktober 2010 uitkomt heeft deze 2.6.35 kernel aan boord.
Een heel goed antwoord hierop staat in het volgend artikel en de comments op lwn.net:
On the scalability of Linus: http://lwn.net/Articles/393694
I don't see either hit-by-a-bus or slow-decline scenarios as worrisome. There have been times when other people's trees have been used widely. I think we'd see one of those get bumped up, in a pretty seamless way. git makes this easy.

Linus's tree has maintained its position as "mainline" because everyone thinks of it as such. If it stopped moving in the right direction for whatever reason then people would start using another tree as mainline in a way similar to flocking behavior in birds. There would be no "choice" as a group -- all of a sudden you'd see most other people treating tree X as mainline, and so you would too.
Dan gaat het grote forken beginnen :Y)
Hoewel Linus de bezieler is, werken er talloze mensen aan de kernel. Veel zal het niet vertragen.
Er is maar een manier om daar achter te komen }> .
Misschien heeft ie iets achtergelaten in z'n testament.

Maar er zullen wel meer mensen zijn die ze de ontwikkeling van de kernel toevertrouwen. Kernel programmeurs van het eerste uur die worden ondersteund door de rest van de ontwikkelaars.
staat vast wel in zijn testament.
<offtopic>Zelfde vraag wat als Steve Jobs kom te overlijden...
Interessant... minstens 15% van de aandelen af en een naarstige zoektocht naar een opvolger, want hij lijkt me niet het type dat een kroonprins achterlaat.
Wat dacht je van binnen 8 jaar failliet zo als eerder al eens bijna gebeurde toen Steve iets anders ging doen...
Yeah man! XHTML proof! Sluit je tags! Geep up the good work!
Dat is mooi. Hoe zit het met ondersteuning voor Intel H57/55 chipset? Ik heb laatst een i5 661 server neergezet, maar h.264 decoding lijkt behoorlijk traag te gaan, terwijl dat in hardware zou moeten gebeuren. Vind ik toch erg jammer van linux op het moment. Vanwege dat puntje twijfel ik zelfs nog steeds om er toch een windows bak van te maken... zo zonde dat de hardware gewoon niks staat te doen.
H.264 decoding op een server? Wanneer zou je dat willen doen? Of zie ik nu een toepassingsgebied volledig over het hoofd?
Video's transcoden is een prima taak voor een server?
Als je een video site (zoals Youtube) hebt is dit een best logisch toepassingsgebied ;)
Ach, het is een hobby dlna/file/database server die in de huiskamer staat. Hij kan headless draaien, maar ik kan ook even een hdmi kabel in de tv prikken... als je tv niet alles ondersteunt via dlna zou het ook nog nuttig kunnen zijn om vloeiend video te transcoden.

Er stond specifiek G45 hier, daarom wist ik het niet zeker, maar in de kernel notes staat idd G45+.
Ik heb een servertje met mediatomb draaien dat realtime videotranscoding doet.
"en kan overweg met h.264-decoding op recente chipsets van Intel."

Lijkt me dus dat deze kernel goed uitkomt voor je ;)
Eindelijk goede powersaving support voor mijn laptop. _O_

Ik werd een beetje gek van het geloei omdat de videokaart zich warm zat te stoken. :+
Dan ben je niet de enigste. Sinds de overstap van Ubuntu 9.10 naar 10.04 werd mijn laptop iets warmer. De koelers draaiden niet eens, terwijl het kreng toch echt in de 75C+ was. Hopelijk is dat nu opgelost.
Het zijn dingen die allebei moeten gebeuren.

Nieuwe kernel features zijn vaak voor server omgevingen erg interessant en dat is niet verbazing wekkend.
Linux servers hebben een substantieel server marktaandeel en daar wordt door partijen geld en/of tijd aan besteed (denk aan Redhat, IBM, Novell, Google).

Mensen die zich inzetten voor de desktop (applicaties) hebben over het algemeen minder middelen en bovendien veel meer zaken om zich op te richten.
Een boel ontwikkelingen in de kernel zijn ook simpelweg om bij te blijven met de hardware ontwikkelingen, zodat ook de nieuwste hardware gewoonweg meteen out of de box wordt ondersteund. Dat is niet direct zichtbaar als je de nieuwe kernel op je bestaande PC installeert. Zodra je een nieuwe PC koopt merk je het echter wel. Dan merk je ineens dat die oude distributie met die oude kernel simpelweg niet opstart op je nieuwe PC maar die nieuwe distro met de nieuwe kernel wel.
Intel hw ondersteuning is goed nieuws omdat op deze manier een goed alternatief komt voor de ion doosjes die nu veelal gebruikt worden voor xbmc-linux(live).

Een i3 met ingebakken gpu (+toebehoren) is namelijk niet veel duurder dan een ion set maar natuurlijk wel aanzienlijk sneller :)

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True