optimizace jadra

[Peter Ronai]

On Tue, 2002-12-10 at 12:10, Milan Kerslager wrote:
> Pokud se podivam do archivu, doporucuji nenimrat se v jadre (pokud nemam
> dostatecny duvod a vedomosti) alespon 2 nebo dokonce 3 roky. Ani pred
> tim jsem to nedoporucoval a myslim, ze ani nikdo z "rozumnych".
> 

iste
avsak teraz je to skor v rovine nerobte to, staci vam kernel ktory
niekto za vas spravil
byvalo - skuste uvidite, ale dajte pozor

> Mnozstvi prace, ktere vlozi do jadra distributor je nepomerne vetsi, nez
> akce Ferdy Brabence, ktery vezme tarball a napise make. Nemluvim uz o QA
> (tj. o vysledne kvalite a jeji kontrole).
> 

iste a preto ma zmysel urobit povedzme vlastnu binarku postupom ako to
robili oni ale povedzme vyhodit nepotrebne a prihodit potrebne (napr
winmodem, exoticky webcam ci xfs) a v neposlednej rade ak ste raz vedel
a robite to zcasu na cas tak nezabudnete ako sa to robi
iste je ze dana binarka dodana zo systemom (distrom) je ta oskusana
pokial nerobite jadro prvy raz v zivote zo src.rpm spravite s istym
usilim upravene jadro ktore vam vyhovuje s porovnatelnou stabilitou pre
vas system

> > ak potom ale priberiete nativny preklad vacsej casti distra sitej na
> > lokalny stroj tak mozete s najvacsou pravdepodobnostou ocakavat citelny
> > rozdiel a tak bezny OS pre jana je najlahsi na pouzitie ale pomaly a
> > zeruci vase systemove prostriedky tak akoby ten vas 1.7 GHz s RH 8.0 bol
> > na urovni tej optimizovanej 350 MHz RH 6.2 ked sa nam este do takych
> > veci chcelo a robili sme to
> 
> Tohle je dost nefer tvrzeni. Jednak v 6.2 nebude existovat SW vybaveni,
> ktere je defaultne v 8.0. 

to je fakt
je rovnako nefer tvrdit ze BFU ktoremu by ten ktory soft nechybal by si
ten isty soft na rh8 vypol lebo ho nepotrebuje


> Jednak mnozstvi bezpecnostnich problemu, ktere
> si vytvorite bude nezanedbatelne a take budete muset ozelet dalsi veci
> (napr. velke soubory, rychle ATA, UDMA, atd). Pokud porovnam mnozstvi
> prace, kterou budete muset vynalozit s cenou noveho HW, budete to tezko
> pred sefem obhajovat.

su firmy kde este dnes bezi redhat 6.2 koli platformovej kompatibilite a
jadro je 2.2
aj vsetky nove instalacie na produkcne systemy robia cez kikstart z
cdcka s updated packagmi (viem lebo som to cd robil)
na tom bezi ten kopec softu ktory nie je mozne previest na novsie verzie
a z niektorymi problemami potom musia zit, ine opatchuju
zapatchovat 6.2jku netrva ovela dlhsie ako 7.2jku, okrem toho podpora na
nu stale trva (aj ked uz asi nie dlho)
chapem vase argumenty a beriem ich, je to momentalne ale skor o sliepke
a vajci


> Jenze dnes si nehrajeme na vojaky, ale (obvykle) se snazime udrzet v
> chodu (nebo vyvinout) radove slozitejsi systemy. A jadro je prostredek a
> ne smysl prace admina.
> 

iste
na druhu stranu nielen admin pouziva OS - to ad1
ad2 - nie kazdy system je mission critical
ad3 - pre mna nie je argument chodi to tak sa na to nesahaj

anyway - povodna myslienka bola niekde v zmysle:

POKIAL CHCE KOMPILOVAT JADRO TAK NECH TO ROBI staci ked vie ze to a to
moze pokaslat alebo mu moze nejst ale to a to sa moze naucit a moze mu
to byt napomocne (lebo admin sa moze stretnut s proprietarnimy modulmi
dodanymi v zdrojakoch s tym ze navod je mlhavy a kompilacii treba
rozumiet - nielen na linuxe)
ak sa nas nieco spyta (ale to sa opakujem) odpoved typu radsej to
nerobte nie je velmi napomocna

ale to sa zas schyluje k flame a to som nechcel
ono na vsetko bude iste protiargument a nazorov bude kolko citatelov


dz


________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________