---

Hej

Så er den gal igen! Jeg har kastet mig over FreeBSD igen og har
installeret det på min gamle bærbar computer. Fra den dokumentation jeg
lavede til mit forrige FreeBSD forsøg, har jeg bygget en custom kerne,
for at fjerne ting jeg ikke bruger fra denne.

Spørgsmålet er nu - hvormeget vinder man overhovedet ved at lave en ny
kerne? Det kommer selvfølgelig an på hvad man laver, men hvis man som
mig ikke ved særligmeget om det og bare udkommentere nogle linier i
kerne konfigurations filen - er det så spild af tid det jeg laver?

--
Anders Lund - anders@andersonline.dk
Take back the web - www.mozilla.org/firefox

---

Anders Lund <anders@andersonline.dk> writes:

> Spørgsmålet er nu - hvormeget vinder man overhovedet ved at lave en ny
> kerne? Det kommer selvfølgelig an på hvad man laver, men hvis man som
> mig ikke ved særligmeget om det og bare udkommentere nogle linier i
> kerne konfigurations filen - er det så spild af tid det jeg laver?

Mit gæt er at du vinder mest i form af at du bliver klogere, og mindre
i form af at dit operativsystem bliver hurtigere.

--
Jacob - www.bunk.cc
The more you complain, the longer God lets you live.

---

Jacob Bunk Nielsen wrote:

> Mit gæt er at du vinder mest i form af at du bliver klogere, og mindre
> i form af at dit operativsystem bliver hurtigere.

Det var også hvad jeg tænkte... eller, jeg tænkte ikke så meget på at
jeg kunne lære noget..

--
Anders Lund - anders@andersonline.dk
Take back the web - www.mozilla.org/firefox

---

On 2005-01-03, Anders Lund <anders@andersonline.dk> wrote:
> Spørgsmålet er nu - hvormeget vinder man overhovedet ved at lave en ny
> kerne? Det kommer selvfølgelig an på hvad man laver, men hvis man som
> mig ikke ved særligmeget om det og bare udkommentere nogle linier i
> kerne konfigurations filen - er det så spild af tid det jeg laver?

Om det er spild af tid, afhaenger nok mest af, hvad du vil opnaa.

Har din maskine meget lidt hukommelse, kan det maaske give nogle flere,
da kernen ikke vil optage hukommelse til e.g. ubrugte drivere. Det vil
formentlig hoejst vaere i stoerrelsesordenen af 2-3MB, i hvert fald ikke
noget der betyder ret meget.

Hvis du regner med at opnaa en hurtigere maskine, saa glem alt om det.
Overvej kort, hvor meget tid din maskine koerer i henholdsvis user og
kernel mode. Det er simpelthen saa lidt tid, saa du vil formentlig ikke
kunne maale nogen reel forskel, hvis du optimerer din kerne med e.g. 2%
i hastighed. Det er for lidt forbedring af for lille et stykke tid, og
du risikerer bare at opleve et mindre stabilt system, fordi din
oversaetter er fuld af fejl i optimeringskoden.

Jeg har vist naevnt det her tidligere, men det er simpelthen saa godt,
at jeg vil goere det igen:

   http://www.funroll-loops.org/

Til sidst mindes jeg, at standardkernen vist ikke rummer al
funktionalitet og vist heller ikke er tunet til haard belastning.

Hvis du gerne vil laere noget, kan du maaske laere noget om, hvordan
kernen detekterer enheder under boot og lidt andet om kernel internals.

Jeg ville nok hellere bruge min tid paa at saette mig ind i forskellene
paa FreeBSD og Linux paa end user-niveau -- det er immervaek det, du
kommer til at arbejde mest med. Brug tid paa at identificere svagheder
og styrker[1], saa du bedre kan vaelge det rette system til opgaven i
fremtiden.

Der er nogle nye, fede firewalls at lege med (pf!) blandt andet, og
ports-systemet boer du ogsaa tage et kig paa.

Mvh. Michael.

[1] Da jeg skiftede til BSD, gik der meget tid med at indse, at der er
forskel paa at vaere anderledes og vaere daarligere.
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)

---

Michael Knudsen wrote:
> Hvis du regner med at opnaa en hurtigere maskine, saa glem alt om det.
> Overvej kort, hvor meget tid din maskine koerer i henholdsvis user og
> kernel mode. Det er simpelthen saa lidt tid, saa du vil formentlig ikke
> kunne maale nogen reel forskel, hvis du optimerer din kerne med e.g. 2%
> i hastighed. Det er for lidt forbedring af for lille et stykke tid, og
> du risikerer bare at opleve et mindre stabilt system, fordi din
> oversaetter er fuld af fejl i optimeringskoden.

IMHO må man _aldrig_ pille ved de optimerings (-O options) settings, som er sat per default
til compilerens opsæt i sys source distro'en. Man kan ikke sige noget om, hvad
det kan have af effekter på en kernel / Kernel modules. Med mindre man da er virkelig low level
kernel hacker. Worst case kan man eks. få lavet drivers, der korrupter data osv.

Det man kan vinde er, efter min mening, at man ikke skal bruge mem på at have ubrugte drivers
loaded statisk i kernel. Eks. er der i FreeBSD masser af NIC's og SCSI drivers man let kan
fjerne, da man sjælden har så mange forskellige netkort og sikkert heller ikke SCSI i en alm PC.
De ligger alligevel til brug som kernel objects, skulle man få brug for dem senere. Så kan man bruger
loader setup'et til at loade dem ved startup.

mvh

Nikolaj

---

Nikolaj Hansen <barnabasdkSPAM@yahoo.dk> wrote:

> IMHO m? man _aldrig_ pille ved de optimerings (-O options) settings, som er sat per default
> til compilerens ops?t i sys source distro'en. Man kan ikke sige noget om, hvad
> det kan have af effekter p? en kernel / Kernel modules. Med mindre man da er virkelig low level
> kernel hacker. Worst case kan man eks. f? lavet drivers, der korrupter data osv.

Det er nu ikke fordi det er saadan at optimeringsflag per default
smadrer dit system, men naermere fordi at GCC-oversaetteren sutter naar
det gaelder om at vaere en stabil oversaetter hvor optimeringerne altid
gaelder. Paa i386 er det ikke saa slemt som paa andre eksotiske
arkitekturer.

> Det man kan vinde er, efter min mening, at man ikke skal bruge mem p? at have ubrugte drivers
> loaded statisk i kernel. Eks. er der i FreeBSD masser af NIC's og SCSI drivers man let kan
> fjerne, da man sj?lden har s? mange forskellige netkort og sikkert heller ikke SCSI i en alm PC.
> De ligger alligevel til brug som kernel objects, skulle man f? brug for dem senere. S? kan man bruger
> loader setup'et til at loade dem ved startup.

Det er rigtigt, men det betyder naeppe noget for et moderne system.
Tag eksempeltvist min kerne paa 7.3 mb:

mushroom$ dc -e '3 k 7.3 640 / p'
..011

Saa ved at skaere den til det halve kan jeg vinde... lad os se:

mushroom$ dc -e '3 k 7.2 2 / 640 / p'
..005

Ah, jeg kan vinde en 0.6 procent mere hukommelse. Det er naeppe vigtigt
i sidste ende. Hvis et program rammer graensen, saa er det ikke det,
der vil vaere den faldende faktor.

--
jlouis

---

Jesper Louis Andersen wrote:
> Det er rigtigt, men det betyder naeppe noget for et moderne system.
> Tag eksempeltvist min kerne paa 7.3 mb:

Jeg tror jeg lader kernen være lidt endnu og leger med at få sat Xorg
med Gnome op i stedet. Nu løb jeg dog ind i en anden mur - at harddisken
kun er på 4 GB og med et minimalt installeret sytstem, med source og
ports, og make install clean i gnome2 mappen i ports, bliver harddisken
fyldt ud.... måske jeg skulle få købt mig en ny bærbar?

Hvad kan anbefales som ikke kræver den står kerne-tekniker at få til at
spille sammen med FreeBSD? :D

--
Anders Lund - anders@andersonline.dk
Take back the web - www.mozilla.org/firefox

---

Anders Lund wrote:
> Jesper Louis Andersen wrote:
>
>> Det er rigtigt, men det betyder naeppe noget for et moderne system.
>> Tag eksempeltvist min kerne paa 7.3 mb:
>
>
> Jeg tror jeg lader kernen være lidt endnu og leger med at få sat Xorg
> med Gnome op i stedet. Nu løb jeg dog ind i en anden mur - at harddisken
> kun er på 4 GB og med et minimalt installeret sytstem, med source og
> ports, og make install clean i gnome2 mappen i ports, bliver harddisken
> fyldt ud.... måske jeg skulle få købt mig en ny bærbar?
>
> Hvad kan anbefales som ikke kræver den står kerne-tekniker at få til at
> spille sammen med FreeBSD? :D
>

Du kan bygge de enkelte elemeter af Xorg / XFree86 for sig i stedet for at køre
det "meta" projekt, der sørger for at bygge alle komponenterne.

Det er lidt mere teknisk, og du skal gøre det i den rigtige rækkefølge. Men til
gengæld kan du lave en clean for hvert sub projekt efter install.

Dog tror jeg ikke der er nogen garanti for, at en 4 giga disk alligevel kan klare det. Jeg ved ikke
hvad mininum ledig diskplads er for et build til XOrg.

Alternativt kan du compile projekterne på en anden maskine og overføre de binære filer direkte.
Det kræver self. at du har en nogenlunde lignende config hw mæssigt på den. men så kan du næsten
lige så godt hente de binære pakker med en pkg_add -r Xfree86 og derefter en pkg_add -r kde.

mvh

Nikolaj Hansen

---

Nikolaj Hansen wrote:
> Du kan bygge de enkelte elemeter af Xorg / XFree86 for sig i stedet for
> at køre
> det "meta" projekt, der sørger for at bygge alle komponenterne.

Det er også det jeg overvejer.

> Alternativt kan du compile projekterne på en anden maskine og overføre
> de binære filer direkte.
> Det kræver self. at du har en nogenlunde lignende config hw mæssigt på

Og jeg har slet ikke nogen maskiner som ligner denne.

> den. men så kan du næsten
> lige så godt hente de binære pakker med en pkg_add -r Xfree86 og
> derefter en pkg_add -r kde.

Det har jeg også gjort, men så får jeg ikke den nyeste version.

--
Anders Lund - anders@andersonline.dk
Take back the web - www.mozilla.org/firefox

---

Jesper Louis Andersen wrote:

> Ah, jeg kan vinde en 0.6 procent mere hukommelse. Det er naeppe vigtigt
> i sidste ende. Hvis et program rammer graensen, saa er det ikke det,
> der vil vaere den faldende faktor.
>

Nej, jeg er enig.

Det er mere princippet bag statisk linkning af drivers ind i kernen jeg opponerer imod
Det er noget lettere at lave en update til en driver hvis den _ikke_ er fedtet ind i kernel.

Jeg synes FreeBSD distroen skulle pille så meget ud af kernen af de drivers de kan, og så begynde
at bruge de standard *.ko moduler, der alligevel bliver bygget. Alternativt kunne man så lave et
build step til kun at compile drivers.

I det tilfælde ville man kunne lave en:

$make builddrivers
$make install drivers
$kldunload /boot/kernel/foo.ko
$kldload /boot/kernel/bar.ko
$osv....

Man burde kunne teste mange ting, uden at genstarte.

mvh

Nikolaj Hansen

---

On 2005-01-05, Nikolaj Hansen <barnabasdkSPAM@yahoo.dk> wrote:
> Det er mere princippet bag statisk linkning af drivers ind i kernen
> jeg opponerer imod
> Det er noget lettere at lave en update til en driver hvis den _ikke_
> er fedtet ind i kernel.

Jeg er generelt imod at aabne op for, at der kan loades arbitraer kode ind
i kernel kontekst. Det kan goere det totalt umuligt at opdage, at nogen
er brudt ind i maskinen, hvis dette skulle ske.

Jo, det giver bedre mulighed for opdatering uden reboot, men jeg har
endnu ikke vaeret ude for at skulle opdatere en driver. Paa BSD er der
ikke tradition for at tage nye drivere med, foer de er erklaeret
stabile. Du vil formentligt oftere se fejl i e.g. netvaerkskode eller
lignende, der kan angribes, og dette er vist kun sjaeldent loadet som
kernemoduler.

Det er i oevrigt de faerreste steder, at en maskine tager skade af et
reboot. I mange tilfaelde har filsystemerne godt af det fsck, der typisk
bliver foretaget under boot. (Jeg er godt klar over, at ikke alle
filsystemer har brug for dette.)

Mvh. Michael.

(PS. Gider du ikke lige fikse din newsreader, saa den ombryder linierne
ved 72-76 tegn? Pf. tak.)
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)

---

Michael Knudsen wrote:

> Jeg er generelt imod at aabne op for, at der kan loades arbitraer kode ind
> i kernel kontekst. Det kan goere det totalt umuligt at opdage, at nogen
> er brudt ind i maskinen, hvis dette skulle ske.

Hvis det skal være muligt, skal vedkommende, der placerer denne kode være
root priviligeret på maskinen for at gøre det. Så har man et helt andet
problem allerede. Desuden kunne dette styres ved at signere drivers
elektronisk som det gøres på andre platforme.

> Det er i oevrigt de faerreste steder, at en maskine tager skade af et
> reboot. I mange tilfaelde har filsystemerne godt af det fsck, der typisk
> bliver foretaget under boot. (Jeg er godt klar over, at ikke alle
> filsystemer har brug for dette.)

Jeg mener da kun at fsck køres hvis et filsystem er markeret "dirty". Dvs.
at det ikke blev lukket ned i en syncronized tilstand? Dvs. ved en pæn
reboot køres det ikke.

mvh

Nikolaj Hansen

---

Nikolaj Hansen <barnabasdkSPAM@yahoo.dk> wrote:

> Hvis det skal v?re muligt, skal vedkommende, der placerer denne kode v?re
> root priviligeret p? maskinen for at g?re det. S? har man et helt andet
> problem allerede. Desuden kunne dette styres ved at signere drivers
> elektronisk som det g?res p? andre platforme.

Well, der er en stor forskel. Det er meget lettere at ''patche'' et
system hvis du har et komplet framework til kernen der lader dig loade
ting og sager ind i kernel context. Hvis du ikke har det, og ikke kan
skrive til /dev/kmem, saa bliver det pludseligt svaert uden et reboot.

Securelevel i BSD'erne goer dog LKM-vejen umulig ogsaa, selv om man
koerer med LKM'er.

Jeg tror mest man holder sig fra LKM'er grundet tradition.


--
jlouis

---

Jesper Louis Andersen wrote:
> Jeg tror mest man holder sig fra LKM'er grundet tradition.

Ja, det er også min opfattelse.

Andre *NIX'er bruger det jo i rå mængder.

mvh

Nikolaj Hansen

---

Nikolaj Hansen <barnabasdkSPAM@yahoo.dk> wrote:
> Jesper Louis Andersen wrote:
>> Jeg tror mest man holder sig fra LKM'er grundet tradition.
>
> Ja, det er ogsaa min opfattelse.
>
> Andre *NIX'er bruger det jo i raa m?ngder.

Kommercielle produkter kan ikke undgaa det, hvis de vil acceptere 3.-
parts drivere.

--
jlouis

---

On 2005-01-06, Nikolaj Hansen <barnabasdkSPAM@yahoo.dk> wrote:
>> i kernel kontekst. Det kan goere det totalt umuligt at opdage, at nogen
>> er brudt ind i maskinen, hvis dette skulle ske.
>
> Hvis det skal være muligt, skal vedkommende, der placerer denne kode være
> root priviligeret på maskinen for at gøre det. Så har man et helt andet
> problem allerede. Desuden kunne dette styres ved at signere drivers
> elektronisk som det gøres på andre platforme.

Ja, selvfoelgelig har man et problem, men det var ikke min pointe. Jeg ved
ikke, om du oversaa det med vilje, men laes lige min sidste saetning fra
forrige indlaeg igen. Budskabet var ganske enkelt:

   Angriberen kan skjule for dig, at du har et problem.

> Jeg mener da kun at fsck køres hvis et filsystem er markeret "dirty". Dvs.
> at det ikke blev lukket ned i en syncronized tilstand? Dvs. ved en pæn
> reboot køres det ikke.

Jeg er ikke helt sikker, men jeg mindes, at der kan foregaa noget reclaim
af inodes eller noget. Jeg husker ikke lige detaljerne, og jeg blander
muligvis noget sammen.
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)