Pagina asta o voi edita de cite ori schimb lucruri in tfm64. In primul rind pentru a le tine minte.

Sistem minimal 64 este gata . Booteaza , ajunge in prompt. In mare parte pachetele sint aceleasi din tfm-ul vechi cu o exceptie notabila: udev.

kernel 2.6.21.1 , glibc 2.5 , gcc 4.1.2 , perl 5.8.8 , udev 111

Acum urmeaza in primul rind sa adaug mc ( pentru ca merit ) si rpm-ul ca sa pot utiliza o parte din specurile din tfm3.1 ( modificind ce e necesar )

Pachete instalate ( extra base ):

• glib2
• mc
• beecrypt
• db
• expat
• openssl
• neon (are nevoie de downgrade )
• rpm ( fara patch-urile specifice tfm ) ( inca se compileaza )

Bon . Eroare . neon 0.26 nu e suportat direct de rpm 4.4.2 . Prin urmare am de ales: upgrade la rpm ( dar asta inseamna sa imi refac toata partea de autofetch ) sau downgrade la neon pina obtin un rpm functional.

Am sa incerc sa merg pe varianta 2. Probabil ca ma voi lovi de probleme la compilarea de apache si subversion ( am asa un feeling ) .

Continuam compilarea …. Stay tuned

• sqlite (il vrea rpm-ul )
• python ( ln -s python-2.4 pythonauto in usr/include)

Uitasem in /usr/local/lib o librarie veche de libbz2 . Mai mult bzip2 era compilat fara -fPIC ceea ce impiedica rpm-ul sa se compileze corect.

Dupa toate aceste lupte … Avem rpm functional ( fara pachurile de autofetch ). DAR .. se cheama ca sistemul este fuctional . Acuma urmeaza partea complicata . Trecerea incet incet a pachetelor TFM uzuale in noul tree si rezolvarea problemelor care apar.

Booteaza in vmware in 30 secunde.

Cam atit pentru dimineata asta.

06 – 06 – 2007

• sqlite depinde de: ncurses , readline , tcl (optional pentru docs)
• iar rpm-ul are niste faza apropo de x64 …. 3 patchuri pe ziua de azi … se cheama ca sint productiv. Problema cea mai mare a fost la flagurile de compilare.

Si apropo de flaguri de compilare . Petnru tfm64 flagurile default de compilare sint: “-mtune=k8 -m64 -O3 -pipe -fomit-frame-pointer -fPIC”

Benchmark 1:

compresarea unui ISO de 670065475 cu bzip2

La un bzip2 compilat cu -mtune=k8 -m64 -O2

root@tfm64: 2# time /bin/bzip2 6.2-RELEASE-i386-disc2.iso
real 4m27.183s
user 4m4.919s
sys 0m2.772s

Acelasi fisier compresat cu bzip2 ce a fost compilat cu: -mtune=k8 -m64 -O3 -pipe -fomit-frame-pointer -fPIC

root@tfm64: 2# time /usr/bin/bzip2 t1
real 4m23.154s
user 4m2.083s
sys 0m2.468s

Diferenta de 4 secunde doar din flagurile de compilare.

Ca termen de comparatie , desi e un pic fortat, tfm 3.1 pe un dual xeon acelasi benchmark a dat urmatoarele rezultate:

root@compile: /Tfm# time /usr/bin/bzip2 t1
real 9m51.190s
user 9m42.640s
sys 0m2.930s

Sistemul de instalare va trebui sa permita instalarea din retea . Ce inseamna asta: in retea se pune un server dhcp / bootp si serverul ce urmeaza a fi instalat va boota din retea. Sistemul de boot va trebui sa monteze nfs sistemul pe care exista rpm-urile de instalat dupa care instalarea va continua ca si cum ar instala de pe cdrom.

De ce e necesar ? In momentul in apare necesitatea de a instala multe servere repede in loc sa faci x cd-uri de instalare se pune un singur server si restul se instaleaza via network din el.

16-06:

Inca n-am terminat cu packetele de baza. O gramada de lucruri se schimba la trecerea 32/64 . Initial parea destul de simplu.

Au mai ramas: perl, udev-rules, kernel si de facut bootscripts-ul rpm. Cele mai grele. De ce ? Cu perl-ul am tot avut show-uri ( Ei da … nu-mi place perl-ul DELOC ). udev rules trebuie adaptat la noua versiune de udev. Kernelul. Aici e o parte complicata. Pentru ca trebuie gindit cum fac sa pastrez cit mai mult din structura de tfm32 … initrd …etc

Mai vedem. Intre timp am pus in heavy testing un mysql . Se comporta excelent so far. Zburda.