Een goede kernel draaien.

[_eXistenZ_]

Mijn vraag is niet al te moeilijk: Hoe draai ik een goede kernel in elkaar, die:

- Totaal gestript is van alle onnodige zooi
- Hardware ondersteuning heeft voor mijn pc
- Ondersteuning heeft voor andere dingen, denk aan samba ofzo.

en dan ben ik vooral benieuwd naar de werkwijze waarop ik dit kan bewerkstelligen.

Nu heb ik het gevoel dat ik veelste veel dingen aan laat staan in de kernel, en soms dingen niet aan heb staan die wel zouden moeten (USB support krijg ik niet aan de gang op mijn laptop, als ik support for small systems -> hutpluggable devices aanvink, krijg ik een compile error bij de modules)

[MTWZZ]

Kijk eens in de The Linux Kernel HOWTO.
Is al wat ouder maar je moet er wel mee vooruit kunnen.

[ Voor 21% gewijzigd door MTWZZ op 09-02-2007 12:04 ]

[Boudewijn]

ik kwak er alles uit (1 voor 1 ) wat ik niet wil en de rest laat ik erin zitten.
nooit errors, wat voor error kreeg jij dan?

[To_Tall]

Boudewijn schreef op vrijdag 09 februari 2007 @ 12:24:
ik kwak er alles uit (1 voor 1 ) wat ik niet wil en de rest laat ik erin zitten.
nooit errors, wat voor error kreeg jij dan?

Gentoo is echt alles modulair.
je bent echter alleen 2 volle dagen bezig met compilen. dan nog niet te spreken over het afconfigureren. echter na het installeren kan je een tarball draaien van je systeem en volgende keer stuk sneller in elkaar flansen!!

[MrBarBarian]

To_Tall schreef op vrijdag 09 februari 2007 @ 12:26:
Gentoo is echt alles modulair.

Euh... vertel... De Gentoo kernel is hetzelfde als die van een willekeurige andere distributie.. Dus wat is het modulaire deel dat specifiek voor Gentoo is?

[CyBeR]

Mja, een kernel waar 'alles uit is gestript' is op zich niet significant sneller hoor. Wel een beetje maar of je dat nu direct gaat merken..

Anyway 't is gewoon trial and error. De config opties 'for small systems' heb je niet nodig btw, da's voor embedded systemen.

[Ivo]

Boudewijn schreef op vrijdag 09 februari 2007 @ 12:24:
ik kwak er alles uit (1 voor 1 ) wat ik niet wil en de rest laat ik erin zitten.
nooit errors, wat voor error kreeg jij dan?

Zo doe ik het ook altijd (al doet Debian dat tegenwoordig voor mij). Alles wat je denk dat overbodig is eruit smijten en als iets niet werkt, dan zoek je op wat dat specifieke pakket nodig heeft. Meestal is dat wel te vinden in de installatie-handleidingen van diverse pakketten. Kernels bakken is geen donkere magie, probeer het gewoon nog een keer en mocht iets specifieks niet werken dan horen we het hier wel.

[Verwijderd]

MrBarBarian schreef op vrijdag 09 februari 2007 @ 12:31:
[...]

Euh... vertel... De Gentoo kernel is hetzelfde als die van een willekeurige andere distributie..

Nee, dat is niet waar. Gentoo patched de vanillakernel (tot gentoo-sources) wel degelijk met een aantal extra's zoals de vesa-tng framebuffer. Wel is het zo dat Gentoo tegenwoordig zo min mogelijk patched om niet teveel af te gaan wijken van standaard kernel. Maar wil je een andere kernelvorm is dat ook heel goed mogelijk (Vanilla, Andrew Morton, Con Kolivas, Hardened, etc. etc.)

Verder is het zaak precies te weten welke hardware je hebt. En dan gaat het vooral om chipsets op je moederbord en ingestoken PCI kaarten. Op deze manier kun je al een hele hoop dingen uitvinken als je een kernelconfig samenstelt.

[Wormaap]

Ivo schreef op vrijdag 09 februari 2007 @ 12:35:
[...]

Zo doe ik het ook altijd (al doet Debian dat tegenwoordig voor mij). Alles wat je denk dat overbodig is eruit smijten en als iets niet werkt, dan zoek je op wat dat specifieke pakket nodig heeft. Meestal is dat wel te vinden in de installatie-handleidingen van diverse pakketten. Kernels bakken is geen donkere magie, probeer het gewoon nog een keer en mocht iets specifieks niet werken dan horen we het hier wel.

Eensch. Veel mensen zijn veel te bang met hun kernel. Als het allemaal misgaat, steek je'n LiveCD in je bak en fix je vanuit daar wat je verkloot hebt

[CyBeR]

Dat lijkt me nog overdreven. Je moet alleen altijd zorgen dat je je oude kernel nog kunt booten door 'm een menu-item te geven in je boot loader.

[Verwijderd]

Het voordeel van zoveel mogelijk uit je kernel slopen is misschien niet dat het veel sneller wordt, maar wel dat ie sneller te compilen is. Al laadt jeje modules uiteindelijk niet, ze moeten wel gecompiled worde en dat kost gewoon tijd. Ik heb ook altijd een compacte kernel en een standaard kernel voor het geval dat ik wat te enthousiast ben met strippen, dat werkt gewoon fijn en makkelijk.

[CyBeR]

Mwah, zolang een kernel compilen korter duurt dan even pissen en een nieuw glaasje drinken halen maak ik me over compiletijd niet echt zorgen

[smokalot]

op welke manier gaat het compilen van een eigen kernel je helpen kwa snelheid dan?

optimaliseren voor jouw processor kan een paar procent uitmaken, maar daarvoor kun je bij de meeste distro's een pakket installeren (kernel-i686, kernel-k7, enz).

Het compileren van precies de drivers voor jouw hardware, statisch in de kernel ipv als modules kost je wat flexibiliteit, en levert je bij het booten hooguit een paar seconden winst op. als het eenmaal draait maakt het volgens mij helemaal niets uit.

Compileren van alleen de modules die je nodig hebt kan je bij het booten ook een paar seconden schelen, maar ook daar geldt dat als het eenmaal draait het helemaal niets meer uitmaakt. Waarom zou de aanwezigheid van een paar extra bestandjes je pc trager maken? t is windows niet!

ga er gerust mee spelen als je er meer over wilt weten enzo hoor, maar doe t niet voor de snelheidswinst.

[McKaamos]

_eXistenZ_ schreef op vrijdag 09 februari 2007 @ 11:21:
Mijn vraag is niet al te moeilijk: Hoe draai ik een goede kernel in elkaar, die:

- Totaal gestript is van alle onnodige zooi
- Hardware ondersteuning heeft voor mijn pc
- Ondersteuning heeft voor andere dingen, denk aan samba ofzo.

en dan ben ik vooral benieuwd naar de werkwijze waarop ik dit kan bewerkstelligen.

Nu heb ik het gevoel dat ik veelste veel dingen aan laat staan in de kernel, en soms dingen niet aan heb staan die wel zouden moeten (USB support krijg ik niet aan de gang op mijn laptop, als ik support for small systems -> hutpluggable devices aanvink, krijg ik een compile error bij de modules)

kernel sources downloaden (nieuwste stable versie is 2.6.19.2)
tar -zxvf'en in /usr/src
dan cd /usr/src/linux-2.6.19.2
"make clean"

Als je al een 2.6 kernel hebt, kan je de oude .config van je vorige kernel naar de map met sources van de nieuwe kernel kopieren.
Dan doe je ff "make oldconfig"
if not, dan niet

"make menuconfig" en dan ga je de menu's aflopen en kijken welke onderdelen je nodig hebt.
Er zit een helpfunctie bij, dus uitleg staat er gewoon bij.

Daarna sluit je dat menu af en als gevraagd wordt om de config op te slaan doe je "yes".
dan typ je "make" en dan is het wachten geblazen.

Zodra de compile klaar is kopieer je de bzImage file uit de zojuist verschenen /usr/src/linux-2.6.19.2/arch/i386/boot map naar /boot.

Mocht je Lilo gebruiken als bootloader, dan pas je /etc/lilo.conf even aan met vi ofzo.
gewoon de laatste entry even overtypen en dan de nieuwe bzImage als imagefile opgeven.
Ff saven en dan "lilo" als commando typen, en dan rebooten.
Dan krijg je bij boot de optie om je nieuwe kernel te booten.
Alshet niet werkt, oude kernel weer booten en weer terug naar "make menuconfig" (geen "make clean" vantevoren! scheelt tijd!) en doorloop je de opvolgende stappen.

[dion_b]

smokalot schreef op vrijdag 09 februari 2007 @ 13:56:
op welke manier gaat het compilen van een eigen kernel je helpen kwa snelheid dan?

Het zelf compileren heeft wel meer voordelen dan alleen die paar seconden bij boot hoor

- generic x86 uitzetten scheelt beetje, SMP aan danwel uitzetten en indien aan de het max CPU aantal goed instellen scheelt aardig op de scheduler
- bij CPUs met kleine L2 cache (Celeron, Sempron) loont het om met -Os te compilen, maar bij grotere L2 cache is -O2 sneller. Door zelf te compileren
- als je toch niet aan dev doet heb je alle debug output niet nodig, dat uitzetten scheelt ook aardig (omgekeerd als je wel gaat devven wil je soms een stuk meer info dan per default aanwezig is)

En zo zijn er wel nog meer dingen te verzinnen...

optimaliseren voor jouw processor kan een paar procent uitmaken, maar daarvoor kun je bij de meeste distro's een pakket installeren (kernel-i686, kernel-k7, enz).

Kan,

Het compileren van precies de drivers voor jouw hardware, statisch in de kernel ipv als modules kost je wat flexibiliteit, en levert je bij het booten hooguit een paar seconden winst op. als het eenmaal draait maakt het volgens mij helemaal niets uit.

Nee, maar vooral in boottijden valt enorm wat te winnen. Ik heb bij Debian de bootsnelheid meer dan gehalveerd door een eigen kernel erin te zetten met static drivers, geen modules en geen idiote ramdisk. Voor een server maakt dit natuurlijk geen zak uit, maar als je een desktopsysteem hebt die alleen aangaat als het nodig is, kan het meer dan een minuut schelen als je niet een bliksemsnelle HDD hebt

Compileren van alleen de modules die je nodig hebt kan je bij het booten ook een paar seconden schelen, maar ook daar geldt dat als het eenmaal draait het helemaal niets meer uitmaakt. Waarom zou de aanwezigheid van een paar extra bestandjes je pc trager maken? t is windows niet!

Nee, maar waarom zou je een paar loze bestanden überhaupt aanwezig willen hebben als je ze niet nodig hebt? t is windows niet!

ga er gerust mee spelen als je er meer over wilt weten enzo hoor, maar doe t niet voor de snelheidswinst.

Voor snelheid na boot zal het alleen in specifieke situaties echt merkbaar iets schelen. Maar wat betreft bootsnelheid nodig ik je uit om het eens te meten. Daar valt enorm veel te winnen.

Wat wel zo is, is dat je je systeem een stuk beter gaat begrijpen als je zelf de kernel compileert en zelf de gevolgen van je keuzes nagaat. Dat leerzame is IMHO belangrijkste reden om zelf die kernel te compileren (het verkorten van boottijden en lozen van ramdisks komt op een goede tweede plaats).


Enige vereiste ervoor is dat je hardwarematig je PC kent. Welke chips zitten erin? Welke Linux drivers gebruiken die? Is zo'n driver in de kernel beschikbaar of zul je het los moeten compileren (nVidia met 3D...)?

Dat is de eerste keer even wat uitzoekwerk, daarna gaat het echter makkelijk

[Confusion]

_eXistenZ_ schreef op vrijdag 09 februari 2007 @ 11:21:
Mijn vraag is niet al te moeilijk: Hoe draai ik een goede kernel in elkaar, die:

- Totaal gestript is van alle onnodige zooi
- Hardware ondersteuning heeft voor mijn pc
- Ondersteuning heeft voor andere dingen, denk aan samba ofzo.

en dan ben ik vooral benieuwd naar de werkwijze waarop ik dit kan bewerkstelligen.

Nu heb ik het gevoel dat ik veelste veel dingen aan laat staan in de kernel, en soms dingen niet aan heb staan die wel zouden moeten (USB support krijg ik niet aan de gang op mijn laptop, als ik support for small systems -> hutpluggable devices aanvink, krijg ik een compile error bij de modules)

Wat is je doel? Want als gebruiksgemak je doel is, dan zou ik het lekker laten zitten en vooral een stock kernel van je distro installeren. Het neemt meer schijfruimte in en is trager (iemand cijfers over post-boot snelheidsverschillen?), maar kost helemaal geen moeite.

[McKaamos]

cijfers? hell das makkelijk aan te voelen.
Ik heb van de week nog een kerneltje in elkaar geprakt voor m'n Proliant 1600.
Draai er slackware op, en geen enkele default kernel van SW11 doet aan SMP.
Dus sowieso een must voor mij om een kernel te compilen.
Maargoed, het verschil van de Huge26.s kernel tov een zelf gecompilede 2.6.19.2 kernel (totaal gestript en voorzien van SMP functies) is echt een halvering van de boot tijd, als het niet meer is.

[elTigro]

dion_b schreef op vrijdag 09 februari 2007 @ 15:27:
[...]
Voor een server maakt dit natuurlijk geen zak uit, maar als je een desktopsysteem hebt die alleen aangaat als het nodig is, kan het meer dan een minuut schelen als je niet een bliksemsnelle HDD hebt

Nou ja... Ik vind het toch wel fijn dat als een server down gaat, hij zo snel mogelijk weer op komt.
Je homedisk server bijvoorbeeld wil je (=ik) weer gauw op

[_eXistenZ_]

Confusion schreef op vrijdag 09 februari 2007 @ 17:12:
[...]

Wat is je doel? Want als gebruiksgemak je doel is, dan zou ik het lekker laten zitten en vooral een stock kernel van je distro installeren. Het neemt meer schijfruimte in en is trager (iemand cijfers over post-boot snelheidsverschillen?), maar kost helemaal geen moeite.

Ik draai Gentoo dus gebruiksgemak is niet echt mijn doel Dan nam ik Ubuntu of SuSE
Mijn doel is een zo clean mogelijke install op mijn hd, zonder overtollige meuk.
Bovendien leer ik zo goed een kernel te configgen, wat altijd handig is.

[Verwijderd]

Confusion schreef op vrijdag 09 februari 2007 @ 17:12:
[...]

Wat is je doel? Want als gebruiksgemak je doel is, dan zou ik het lekker laten zitten en vooral een stock kernel van je distro installeren. Het neemt meer schijfruimte in en is trager (iemand cijfers over post-boot snelheidsverschillen?), maar kost helemaal geen moeite.

Ik geloof dat dat meer schijfruimte toch wel aardig gecompenseerd wordt doordat je nu de hele source mist, die is ook niet klein.

[Ultraman]

Gewoon lekker knutselen. Overbodige troep er uit slopen is gewoon wat je wilt doen. Het spaart wat seconden boottijd en pietsie geheugen. Hoe vaker je een kernel compileert des te minder "bang" wordt je er voor. Ik zit nu na te denken met welk IRL "leerproces" ik het zou kunnen vergelijken, maar ik blijf bij sex uitkomen Of dat nou komt door het late uur of omdat het gewoon zo is laat ik ff in het midden. Maar de eerste keer gaat meestal wat moeizaam of het lukt niet of het lukt aardig . En opgegeven moment heb je het door en weer daarna ga je nieuwe dingen proberen en daarna ga je zelfs experimenteren.
Ik ben nu bezig met een Gentoo installatie op mijn eigen box, ik post dit dan ook vanuit Links @ console wat nog best goed werkt moet ik zeggen, nu aanbeland bij het aanmaken van make.conf. En ik weet nu al dat straks portage geupdate wilt worden en misschien ook wel de toolchain ga opkalefanteren voordat ik het kerneltje doe. Maar als je Gentoo gebruikt, pak gewoon lekker gentoo-sources of vanilla-sources. Die zijn hartstikke goed voor je.

[jelly]

Ik heb een nieuwe kernel gecompiled en wil die apart booten ( ik wil dat ik de oude ook nog kan gebruiken voor als er iets fout is aan de nieuwe kernel die ik heb geconfigurereed) als ik dan het commando :

Zodra de compile klaar is kopieer je de bzImage file uit de zojuist verschenen /usr/src/linux-2.6.19.2/arch/i386/boot map naar /boot.

Kan ik dan nog de oude kernel gebruiken als ik dit doe ?(ik heb gewoon de nieuwe kernel in /usr/src untar, compiled etc. )

ben nog een beetje een linuxnoob en bang dat ik me systeem kapot maak:P

[Verwijderd]

wat ik zelf nog altijd de beste HOWTO vind is de readme die bij de sourcecode zit. staat precies elke stap in beschreven.

om de kernel te installeeren doe je: make install
als je module-support gebruik doe je ook: make modules-install

de kernel zal dan naast je huidige kernel worden ge-installeerd onder /boot. als je grub als bootloader gebruikt kun je in /boot/grub/menu.lst kijken wat je huidige opties zijn bij het booten. je kunt een bijna oneindig aantal kernels installeren dus probeer wat uit. je kunt door de bestandsnaam van je kernel te verandern de verschillende compiles uit me kaar houden.

en vergeet niet eerst: make mrproper
te doen voordat je opnieuw compiled om je oude troep op te ruimen.

en uitpakken in /usr/src is bad-practice. gewoon uitpakken in je home directory en je hoeft alleen root te zijn om de kernel te installeeren niet om hem te compilen.

[ Voor 10% gewijzigd door Verwijderd op 10-02-2007 10:52 ]

[CyBeR]

uitpakken in /usr/src is niks 'bad practice' aan. De kernel headers worden wel degelijk daar verwacht namelijk.

[analog_]

CyBeR schreef op zaterdag 10 februari 2007 @ 10:59:
uitpakken in /usr/src is niks 'bad practice' aan. De kernel headers worden wel degelijk daar verwacht namelijk.

Denk aan bv. vmware die wat moduletjes wilt bakken of Ati drivers.

[Confusion]

Stiekem ben ik nu weer geinteresseerd geraakt . Ik ga zo eens te kijken of een zelf geknutselde kernel inderdaad zoveel sneller is .

[DiedX]

Ik denk dat het iets uitmaakt, maar niet veel. Drastische veranderingen krijg je wel met die speciale (alpha) scheduler-patches. (love patches etc)

[_eXistenZ_]

cybersteef schreef op zaterdag 10 februari 2007 @ 02:45:
Gewoon lekker knutselen. Overbodige troep er uit slopen is gewoon wat je wilt doen. Het spaart wat seconden boottijd en pietsie geheugen. Hoe vaker je een kernel compileert des te minder "bang" wordt je er voor. Ik zit nu na te denken met welk IRL "leerproces" ik het zou kunnen vergelijken, maar ik blijf bij sex uitkomen Of dat nou komt door het late uur of omdat het gewoon zo is laat ik ff in het midden. Maar de eerste keer gaat meestal wat moeizaam of het lukt niet of het lukt aardig . En opgegeven moment heb je het door en weer daarna ga je nieuwe dingen proberen en daarna ga je zelfs experimenteren.
Ik ben nu bezig met een Gentoo installatie op mijn eigen box, ik post dit dan ook vanuit Links @ console wat nog best goed werkt moet ik zeggen, nu aanbeland bij het aanmaken van make.conf. En ik weet nu al dat straks portage geupdate wilt worden en misschien ook wel de toolchain ga opkalefanteren voordat ik het kerneltje doe. Maar als je Gentoo gebruikt, pak gewoon lekker gentoo-sources of vanilla-sources. Die zijn hartstikke goed voor je.

Tis seks, met kaa-es

Iig, de eerste keer werkte men usb wel, nu niet meer
(Geen vergelijkingen trekken met bovengenoemde reallife proces )

Het probleem is niet drivers ofzo selecten, maar sommige dingen bij bijv. de CPU die je kan kiezen.
Daar staan kreten waar ik nog nooit van gehoord heb...

[ Voor 5% gewijzigd door _eXistenZ_ op 10-02-2007 13:49 ]

[Verwijderd]

Eigen kernel configureren:
minder code, minder bugs, minder debug stuff, minder mogelijke veiligheidslekken, meer performance, lager geheugengebruik.

[McKaamos]

jelly schreef op zaterdag 10 februari 2007 @ 10:32:
Ik heb een nieuwe kernel gecompiled en wil die apart booten ( ik wil dat ik de oude ook nog kan gebruiken voor als er iets fout is aan de nieuwe kernel die ik heb geconfigurereed) als ik dan het commando :

[...]

Kan ik dan nog de oude kernel gebruiken als ik dit doe ?(ik heb gewoon de nieuwe kernel in /usr/src untar, compiled etc. )

ben nog een beetje een linuxnoob en bang dat ik me systeem kapot maak:P

De image van je oude kernel heet als et goed is vmlinuz.
bzImage is al een andere naam. Desnoods rename je em nog ff naar iets herkenbaars door "mv bzImage mijnimagenaam" te doen
Als je in lilo.conf gewoon het bestaande blokje onderaan overtypt (het stukje waarin o.a. "image = /boot/vmlinuz" staat. uiteraard in het overgetikte stukje "image = /boot/mijnimagenaam" doen ) krijg je in de lilo boot order gewoon een 2de kernel te zien die je zelf moet kiezen.
Mocht er geen timeout opgegeven zijn, dan zet je bovenin lilo.conf nog ff de timeout op 50 (das 5 seconden) zodat je het bootmenu te zien krijgt.
Dat zorgt dat je dus 5 seconden hebt om op een pijltje naar beneden te drukken en zo je nieuwe kernel te kiezen.
Uiteraard na elke lilo.conf aanpassing ff "lilo" intikken zodat de config ververst wordt.

Als het niet werkt, dan reboot je de machine gewoon en kies je de oude kernel bij het booten en probeer je een nieuwe kernel te bakken. (die je dan weer in lilo zet)

edit:
add me anders ff op MSN, dan kan ik je er mayb wel doorheen loodsen

[ Voor 19% gewijzigd door McKaamos op 10-02-2007 14:26 ]

[Jungian]

Is dit niet een beetje nutteloos topic, aangezien het gewoon beschreven staat in het Gentoo Handbook ?

Die walkthroughs die hierboven staan met kernels halen van kernel.org en untarren en weet ik veel hoeveel nutteloze/overbodige zaken kun je dus skippen. Als je buiten Portage gaat werken maak je je hetzelf alleen maar moeilijker. Als je persé de vanilla-kernel (standaard-kernel) wilt gebruiken emerge je vanilla-sources (maar dat staat daar ook al in).

[_eXistenZ_]

Dan zit ik dus met een kernel die niet tot het bot gestript is

Iig et komt er gewoon opneer dat ik moet proberen, steeds 1 of 2 dingen uitzetten, recompilen, draait de boel nog goed? --> Mooi weer 2 dingen uitzetten, enzovoort.

[Jungian]

_eXistenZ_ schreef op zaterdag 10 februari 2007 @ 14:41:
Dan zit ik dus met een kernel die niet tot het bot gestript is

Iig et komt er gewoon opneer dat ik moet proberen, steeds 1 of 2 dingen uitzetten, recompilen, draait de boel nog goed? --> Mooi weer 2 dingen uitzetten, enzovoort.

Tot het bot strippen is gewoon opties uitzetten en kijken of het nog werk allemaal inderdaad Je kunt bijvoorbeeld ook troep als parallele poort-drivers eruit gooien.

[Ultraman]

Vergeet ook niet de Help stukjes te lezen als een optie je helemaal niets zegt, staat vaak nuttige info in. Ook kun je op internet informatie proberen in te winnen over zo'n optie.

[vanaalten]

Inderdaad, die help-functie is wel zo handig. Vaak redelijk abracadabra info met dan daarachter 'if you're unsure, select N'.

Vanmiddag een 2.6.20 kernel gecompileerd, redelijk gestripped en het duurt nu nog maar een half uur i.p.v. tweeeneenhalf uur om te compileren!

Geen prestatie verbeteringen gemerkt, maar toch leuk om gedaan te hebben.

[Jungian]

vanaalten schreef op zaterdag 10 februari 2007 @ 18:41:
Inderdaad, die help-functie is wel zo handig. Vaak redelijk abracadabra info met dan daarachter 'if you're unsure, select N'.

Vanmiddag een 2.6.20 kernel gecompileerd, redelijk gestripped en het duurt nu nog maar een half uur i.p.v. tweeeneenhalf uur om te compileren!

Geen prestatie verbeteringen gemerkt, maar toch leuk om gedaan te hebben.

Een kernel compilen duurt hier 8 minuten (op niet al te magistrale hardware)
Op m'n 733 MHz Pentium 3 duurt het wel een half uur, maar ik ga er vanuit dat je al wat nieuwers hebt staan inmiddels.

[ Voor 9% gewijzigd door Jungian op 10-02-2007 19:13 ]

[Dutchmega]

Echter, de vraag is.. Wat kan er allemaal uit?

Van hardware is het niet moeilijk.. de rest wel

[ Voor 35% gewijzigd door Dutchmega op 10-02-2007 19:24 ]

[MTWZZ]

Kernels compilen doe je voor het tweaken van je systeem en we zijn nu eenmaal tweakers dus wat boeit de reden?

Even serieus: Ik compile zelf m'n kernels aangezien ik alleen maar het spul aan wil hebben wat er ook echt in de machine zit. En natuurlijk tweaken, andere scheduler, timing settingkje hier optimalisatie daar.
Ik heb op m'n ubuntu server (waar standaard dus een kernel met een pre-emptive scheduler op draait) nu een custom kernel met een goeie scheduler en een strakke timing en het scheelt erg veel in performance.

[McKaamos]

Jungian schreef op zaterdag 10 februari 2007 @ 19:09:
[...]

Een kernel compilen duurt hier 8 minuten (op niet al te magistrale hardware)
Op m'n 733 MHz Pentium 3 duurt het wel een half uur, maar ik ga er vanuit dat je al wat nieuwers hebt staan inmiddels.

Eerste keer compilen van een gloednieuwe kernel duurt altijd lang, zeker als je er veel dingen in stopt.
Mijn Dual P3-550 bak doet er ook behoorlijk lang over, maar zodra er een kernel is en je gaat aanpasingen doen, dan zijn die aanpassingen binnen no-time klaar.

[Jungian]

McKaamos schreef op zaterdag 10 februari 2007 @ 22:03:
[...]

Eerste keer compilen van een gloednieuwe kernel duurt altijd lang, zeker als je er veel dingen in stopt.
Mijn Dual P3-550 bak doet er ook behoorlijk lang over, maar zodra er een kernel is en je gaat aanpasingen doen, dan zijn die aanpassingen binnen no-time klaar.

Ik heb al meer kernels gecompiled dan er bejaarden zijn in Nederland, dus dat hoef je mij niet te vertellen 8 minuten en een half uur zijn mijn tijden voor de eerste kernelcompilatie (op respectievelijk mijn laptop en mijn Pentium 3). En dit zijn nog niet eens übergestripte kernels.

Als je echt iets zoekt wat 2+ uur duurt om te compilen moet je maar eens OpenOffice compilen En voor de ECHTE sadomasochist is er ook nog KDE

[ Voor 16% gewijzigd door Jungian op 10-02-2007 22:44 ]

[Verwijderd]

CyBeR schreef op zaterdag 10 februari 2007 @ 10:59:
uitpakken in /usr/src is niks 'bad practice' aan. De kernel headers worden wel degelijk daar verwacht namelijk.

dat is juist het probleem. in /usr/src worden de kernel-headers verwacht van je op dat moment draaiende kernel. niet de source van je laatste compileerde kernel. het wordt door de kernel-ontwikkelaars zelf als 'bad-practice' beschouwt. je moet gewoon in je home directory compile.

@Jungian
ik kan nergens uit opmakken dat de topicstarten gentoo draait. en zoals al eerder vermeld patch gentoo de kernel sources. niet dat dit meteen een wereld van verschil maakt maar ik zou toch niet zomaar de gentoo source's gaan gebruiken voor een fedora installatie. dan pak ik liever de sources van kernel.org.

alhoewel ik zelf nooit kde heb gecompiled kan ik je vertellen dat php4 als static module in apache1.3x ook echt een hele tour is. zo'n 5+ uur.

kernel compile duurt bij mij ongeveer een half-uur. ik begin altijd liever met een schone lei (make mrproper) en de oude config die ik dan weer iets aanpas en opnieuw compile. de 2.6 serie's zijn wel stukken groter in verhouding met de 2.2-serie die ik een paarjaar geleden op mijn AMDk6-3 compilde.

[CyBeR]

Verwijderd schreef op zaterdag 10 februari 2007 @ 23:19:
[...]

alhoewel ik zelf nooit kde heb gecompiled kan ik je vertellen dat php4 als static module in apache1.3x ook echt een hele tour is. zo'n 5+ uur.

Wat heb jij in godesnaam voor'n slome hardware dan? Want dat deed m'n 180MHz PPC 604e nog sneller en op m'n huidige servers (met apache2 dan) is dat binnen 5 minuten klaar

[McKaamos]

Verwijderd schreef op zaterdag 10 februari 2007 @ 23:19:
[...]


dat is juist het probleem. in /usr/src worden de kernel-headers verwacht van je op dat moment draaiende kernel. niet de source van je laatste compileerde kernel. het wordt door de kernel-ontwikkelaars zelf als 'bad-practice' beschouwt. je moet gewoon in je home directory compile.

@Jungian
ik kan nergens uit opmakken dat de topicstarten gentoo draait. en zoals al eerder vermeld patch gentoo de kernel sources. niet dat dit meteen een wereld van verschil maakt maar ik zou toch niet zomaar de gentoo source's gaan gebruiken voor een fedora installatie. dan pak ik liever de sources van kernel.org.

alhoewel ik zelf nooit kde heb gecompiled kan ik je vertellen dat php4 als static module in apache1.3x ook echt een hele tour is. zo'n 5+ uur.

kernel compile duurt bij mij ongeveer een half-uur. ik begin altijd liever met een schone lei (make mrproper) en de oude config die ik dan weer iets aanpas en opnieuw compile. de 2.6 serie's zijn wel stukken groter in verhouding met de 2.2-serie die ik een paarjaar geleden op mijn AMDk6-3 compilde.

@ in /usr/src untarren: Daarom doe je ook een "make kernel_headers" erbij zodat de headers er ook staan. Staan ze meteen op de goede plek.

[Jungian]

Verwijderd schreef op zaterdag 10 februari 2007 @ 23:19:
@Jungian
ik kan nergens uit opmakken dat de topicstarten gentoo draait.

_eXistenZ_ schreef op vrijdag 09 februari 2007 @ 19:44:
Ik draai Gentoo dus gebruiksgemak is niet echt mijn doel Dan nam ik Ubuntu of SuSE
Mijn doel is een zo clean mogelijke install op mijn hd, zonder overtollige meuk.
Bovendien leer ik zo goed een kernel te configgen, wat altijd handig is.

Lezen, het blijft een vak apart

[Verwijderd]

CyBeR schreef op zaterdag 10 februari 2007 @ 23:27:
[...]


Wat heb jij in godesnaam voor'n slome hardware dan? Want dat deed m'n 180MHz PPC 604e nog sneller en op m'n huidige servers (met apache2 dan) is dat binnen 5 minuten klaar

het compile zelf duurt niet zo lang. maar feitelijk smelt je de php+plus alle extensie en apache+alle modules tot een groote executable. en dat is veel werk en wordt standaard ook afgeraden maar ik vond het wel een leerzame ervaring. de performance winst was echter iets van 15%, toch best aardig.

@McKaamos
en daarom moet je niet de hele source-tarball in /usr/src uit pakken maar in je home directory. anders wordt het een zooitje.

@Jungian
sorry, iets te snel overheen gelezen

[smokalot]

$ ls /usr/src/
linux                   linux-2.6.18-gentoo-r3  linux-2.6.18-gentoo-r6
linux-2.6.16.26-xen-r1  linux-2.6.18-gentoo-r4  linux-2.6.19-gentoo-r5
linux-2.6.18-gentoo     linux-2.6.18-gentoo-r5  rpm

waarbij linux een symlink is naar de nu draaiende kernel. Voor mij overzichtelijk en voor mn packagemanager overzichtelijk, prima zo toch?

[vanaalten]

Jungian schreef op zaterdag 10 februari 2007 @ 19:09:
[...]

Een kernel compilen duurt hier 8 minuten (op niet al te magistrale hardware)
Op m'n 733 MHz Pentium 3 duurt het wel een half uur, maar ik ga er vanuit dat je al wat nieuwers hebt staan inmiddels.

Nieuwer wel, maar niet veel sneller: Via Epia M10000 mini-ITX bord. Een 1GHz processor en ik geloof dat 'ie qua snelheid op Pentium-3 niveau zit.

[Jungian]

@smokalot
Ik zou ook niet begrijpen waarom je het anders zou willen doen Met de USE-flag symlink symlinkt Portage ook meteen je kernel bij het emergen, dus dat hoef je dan ook al niet meer te doen Meesterlijk toch dat Portage.

* Jungian vraagt zich nog steeds af waarom niet alle distro's Portage gebruiken, heb je ook meteen geen gekut meer met de 194.000 verschillende package-formaten.

[ Voor 3% gewijzigd door Jungian op 11-02-2007 01:39 ]

[Wormaap]

AFAIK doet Portage geen dingen als 'alleen security updates' enzo.
Voor'n serverpark schijnt't daardoor wat minder praktisch te zijn.
Paludis kan dat dan weer allemaal wel, en schijnt daardoor echt super te zijn. Als het nou nog zou samenwerken met Portage zou ik't wel gaan gebruiken, maar bijhouden met welke package manager of ik iets heb geïnstalleerd vind ik dan weer'n beetje raar

[Zwerver]

smokalot schreef op zondag 11 februari 2007 @ 01:17:

$ ls /usr/src/
linux                   linux-2.6.18-gentoo-r3  linux-2.6.18-gentoo-r6
linux-2.6.16.26-xen-r1  linux-2.6.18-gentoo-r4  linux-2.6.19-gentoo-r5
linux-2.6.18-gentoo     linux-2.6.18-gentoo-r5  rpm

waarbij linux een symlink is naar de nu draaiende kernel. Voor mij overzichtelijk en voor mn packagemanager overzichtelijk, prima zo toch?

Dat is dus i.d.d. ook de manier die ik kies. Dat de kernel-devvers het ineens als bad practice zijn gaan beschouwen betekend niet dat het zo is

[Jungian]

Wormaap schreef op zondag 11 februari 2007 @ 02:02:
AFAIK doet Portage geen dingen als 'alleen security updates' enzo.
Voor'n serverpark schijnt't daardoor wat minder praktisch te zijn.
Paludis kan dat dan weer allemaal wel, en schijnt daardoor echt super te zijn. Als het nou nog zou samenwerken met Portage zou ik't wel gaan gebruiken, maar bijhouden met welke package manager of ik iets heb geïnstalleerd vind ik dan weer'n beetje raar

Op Paludis kun je nog niet bouwen atm (ik zou er mijn package management niet aan toe vertrouwen), desalniettemin is het zeker een erg mooie feature. Een feature die dpkg/apt en rpm overigens ook missen. Geen enkele reden om die nog in leven te houden dus

[Zwerver]

Jungian schreef op zondag 11 februari 2007 @ 02:15:
[...]

Op Paludis kun je nog niet bouwen atm (ik zou er mijn package management niet aan toe vertrouwen), desalniettemin is het zeker een erg mooie feature. Een feature die dpkg/apt en rpm overigens ook missen. Geen enkele reden om die nog in leven te houden dus

Owh? Dan ken jij apt niet heel goed, let op:

uit /etc/apt/sources.list

deb http://security.debian.org/ stable/updates main

Dan krijg je dus alleen maar security-updates.... Dat is toch wat je bedoelde

[Borromini]

Wormaap schreef op vrijdag 09 februari 2007 @ 12:51:
[...]

Eensch. Veel mensen zijn veel te bang met hun kernel. Als het allemaal misgaat, steek je'n LiveCD in je bak en fix je vanuit daar wat je verkloot hebt

Of je zorgt er gewoon voor dat je je werkende kernel laat staan (als je die hebt) en boot die toch gewoon .

DiedX schreef op zaterdag 10 februari 2007 @ 12:09:
Ik denk dat het iets uitmaakt, maar niet veel. Drastische veranderingen krijg je wel met die speciale (alpha) scheduler-patches. (love patches etc)

Con Kolivas .

En dan is er ook nog de 'beyond' patchset, maar die heb ik zelf nog niet geprobeerd.

[ Voor 32% gewijzigd door Borromini op 11-02-2007 02:29 ]

[Jungian]

Zwerver schreef op zondag 11 februari 2007 @ 02:26:
[...]


Owh? Dan ken jij apt niet heel goed

pssst... toch wel

Dan krijg je dus alleen maar security-updates.... Dat is toch wat je bedoelde

Ik hoop eigenlijk dat Wormaap bedoelt dat je minder crap heeft te downloaden (hele packages dus), maar een deel ervan. Zo niet, dan zie ik het niet als een must-have, aangezien je net zoals bij Debian Stable praktisch in slaap valt van de hoeveelheid packages die je kunt updaten steeds (wat je kunt zien als een positief punt natuurlijk).

Hé Jungian wat lul je dan slap dat Paludis niet stable is, als je erg geen gedegen onderzoek naar hebt gedaan ?
- Ik zie wel een berichten langsvliegen op het Gentoo Forum, waar je niet blij van word.

[CyBeR]

Jungian schreef op zondag 11 februari 2007 @ 02:35:
[...]
aangezien je net zoals bij Debian Stable praktisch in slaap valt van de hoeveelheid packages die je kunt updaten steeds (wat je kunt zien als een positief punt natuurlijk).

Ja, 't heet niet voor jan lul 'stable' he

[Jungian]

CyBeR schreef op zondag 11 februari 2007 @ 02:37:
Ja, 't heet niet voor jan lul 'stable' he

Stable staat jammer genoeg voor maximale veiligheid, met oudere bizar oude versies van programma's (bij Debian stammend uit de Middeleeuwen). Ik zou liever nieuwere versies (= meer features) zien. Debian Testing, alleen dan met patch-garantie

[ Voor 3% gewijzigd door Jungian op 11-02-2007 02:46 ]

[Zwerver]

Jungian schreef op zondag 11 februari 2007 @ 02:41:
[...]

Stable staat jammer genoeg voor maximale veiligheid, met oudere versies van programma's (bij Debian stammend uit de Middeleeuwen). Ik zou liever nieuwere versies (= meer features) zien. Debian Testing, alleen dan met patch-garantie

Goh, de laatste keer dat ik keek had testing gewoon security-updates? Daarbij is het nou niet bepaald middeleeuws bij Debian, helemaal als je weet wat je doet niet

[Jungian]

Zwerver schreef op zondag 11 februari 2007 @ 02:46:
[...]


Goh, de laatste keer dat ik keek had testing gewoon security-updates? Daarbij is het nou niet bepaald middeleeuws bij Debian, helemaal als je weet wat je doet niet

Goh, Stable is de enige tree die meteen security updates ontvangt. Bij SID en Testing is het meestal de vraag wanneer je ze ontvangt. Dat is mijn punt. Testing met ogenblikkelijke security updates zou briljant zijn voor een non-productie server En zie ik je nu beweren dat de huidige Stable tree geen antieke packages bevat

Nog even wat Debian quotes erbij, voordat je me niet gelooft :

Testing :

Please note that security updates for "testing" distribution are not managed by the security team. Hence, "testing" does not get security updates in a timely manner. For more information please see the Security Team's FAQ.

SID :

Please note that security updates for "unstable" distribution are not managed by the security team. Hence, "unstable" does not get security updates in a timely manner. For more information please see the Security Team's FAQ.

@ hieronder

Dan zul je je toch meer moeten verdiepen in Debian denk ik zo

[ Voor 40% gewijzigd door Jungian op 11-02-2007 02:53 ]

[CyBeR]

Stable staat niet voor veiligheid, stable staat voor 'stabiel'. Als in: "crasht niet, of iig zo min mogelijk".

[ Voor 27% gewijzigd door CyBeR op 11-02-2007 02:52 ]

[Zwerver]

Zeg, nu moet je ophouden hoor:

Security support for testing

The Debian testing security team is pleased to announce the beginning of
full security support for Debian's testing distribution.

We also invite you to add the following lines to your
/etc/apt/sources.list file, and run "apt-get update && apt-get upgrade"
to make the security updates available.

deb http://secure-testing.deb...tingetch/security-updates main contrib non-free
deb-src http://secure-testing.deb...tingetch/security-updates main contrib non-free

Je mag dan zo overtuigd zijn van je eigen kennis, maar op debian-gebied mag je nog wel wat bijlezen

[Jungian]

Zwerver schreef op zondag 11 februari 2007 @ 02:54:
Zeg, nu moet je ophouden hoor:

[...]

Je mag dan zo overtuigd zijn van je eigen kennis, maar op debian-gebied mag je nog wel wat bijlezen

Mogen ze wel eens de rest van hun pagina's bij gaan houden
Ik heb geen directe link met de Debian-satelliet, en ik heb die zooi die ik hierboven post netjes ge-copy-paste van hun site.

http://www.debian.org/releases/testing/
http://www.debian.org/releases/unstable/

De FAQ ook nog eens :

Q: How is security handled for testing and unstable?

A: The short answer is: it's not. Testing and unstable are rapidly moving targets and the security team does not have the resources needed to properly support those. If you want to have a secure (and stable) server you are strongly encouraged to stay with stable. However, work is in progress to change this, with the formation of a testing security team which has begun work to offer security support for testing, and to some extent, for unstable.

@hieronder

Ik hoef me helemaal niet in hoeven schrijven bij crappy mailinglists of ze bij te houden (hoi 1996 ). Dat soort info moet bijgehouden worden. Er zijn genoeg vrijwilligers bij Debian actief om dat te doen (of heb je daar ook al een smoesje voor verzonnen ?).

[ Voor 51% gewijzigd door Jungian op 11-02-2007 03:06 ]

[Zwerver]

Jungian schreef op zondag 11 februari 2007 @ 02:55:
[...]

Mogen ze wel eens de rest van hun pagina's bij gaan houden
Ik heb geen directe link met de Debian-satelliet, en ik heb die zooi die ik hierboven post netjes ge-copy-paste van hun site.

http://www.debian.org/releases/testing/
http://www.debian.org/releases/unstable/

Je zou natuurlijk ook gewoon de mailinglists bij kunnen houden.

[Puch-Maxi]

Offtopic: Volgensmij moeten we maar gauw gaan slapen, en ophouden met flamen

[icyx]

Jongens, be happy

Serieus, Linux is all about choice, remember? Iedereen kan apt gebruiken als die wil. Iedereen kan portage gebruiken als die wil en iedereen kan paludis gebruiken als die dat wil (waar ik me btw maar eens in moet verdiepen, ik had er nog nooit van gehoord )