Názory k článku Instalace a provoz Gentoo na AMD64

Zajimal by me zdrojak toho benchmarku, abych se mrknul proc nebeha v 64bit lepe nez 32bit...

Zdrojak procistim a dam k dispozici. Chtelo by to udelat dukladnou analyzu assemblerovskeho vystupu a identifikovat problemova mista. Urcite by pomohlo i srovnani s 64bit verzi Visual C++. Bohuzel nemam k diskpozici.

Slo o nalezeni trid nebo serazeni pole?

Serazeni pole. Popravde je tam ta nejprimitivnejsi verze bubblesortu; slo mi o snadny vypocet casove slozitosti a aby pomer operaci razeni (porovnani, prohozeni) a omacky okolo (kopirovani pole, vnejsi cyklus) byl co nejvetsi.

Pouzivam MDK 10.0 rc1 a mam pocit ze to nieje ono :). Skusal som uz instalovat gentoo a vyslodok nebol uspokojivy:

1) dostal som sa az po KDE, ale nemal som antialiasovane fonty a nevedel som sa zbavit xdm. Aj ked som v konfiguraku nastavil kdm, stale som mal xdm...

2) emerge system, niekde v polovicke nastala chyba pri kompilacii.

3) scripts/bootstrap-2.6.sh, podobne ako pri 2.

Stale som isiel zo stage1 a darilo sa menej a menej. Mozno IQ error... :). V prvom pripade kompilacia trvala cca 15hod.

ad 2) a 3)
- jen takový výstřel od boku ... memtest86 hlásí vše OK, procesor není přetaktovaný/nepadá atp. ?

Pred nejakym casem jsem cosi kdesi kopiloval ze zdrojaku. Padalo to na zahadne chyby a pokazde jinde. I zasel jsem za guruem pro radu a dozvedel jsem se, ze se netoci vetracek na procesoru. A opravdu netocil se. Po oprave vse zacalo fungovat jak melo. To same se mi prihodilo pozdeji jeste jednou.

Je to neotebook, acer aspire 1511lmi. Vobec som sa v nom nevrtal. Pri normalnom chode je teplota cca 35˚C pri kompilovani som sa dostal na 60˚C. Mdk10.0 tam frci bez problemu...

Kolik má tvoje máti teplotu je k ničemu, jestli jsi se někde vrtal taktéž a jestli jsi přesvědčený, že značkový notebook musí být vždy bez chyby, tak vítej v realitě. Dokud si to sám nezkontroluješ tak víš prd. Prostě nechej běžet memtest all tests přez noc a pak můžeš běžet reklamovat. Cokoliv jiného je blbost.

Co je to "přez"?

1) Dozajista problem mezi klavesnici a zidli.
2) To se mi stalo pri instalaci taky. Spustil jsem to znovu po castech a uz to slo. Holt vsechno neni dokonale.
3) Stimhle jsem problem nemel, je mozne ze byla chyba v portage, ale spis bych to videl na problem s pameti nebo procesorem
4) Kompilace 15 hodin je docela v pohode. Ja uz prokompiloval nekolik tydnu :-).

Tak tohle mi hrozilo, kdyz jsem zacal instalovat gentoo na AMD K6-2 (64MB RAM, 400Mhz). Nastesti jsem se po asi 4 dnech spamatoval a nainstaloval nejaky redhat 7.3 jinak bych to delal dotedka :o))))))
Ale od toho casu jsem si rekl, ze na vlastni stroj, ktery je nekolikrat rychlejsi uz kdyz tak jenom gentoo :o)

cože hrozilo?
provozuju na Gentoo router/lokální server - Pentium MMX na 233 MHz - vše kompilované, aktuální verze sw, a "doteďka" nicmoc nedělám: když stroj kompiluje, nemusím přece celou dobu zírat na terminál, kde je to spuštěné ... :-)
- zkus se vzpamatovat ještě jednou ;-)

p.s. a říká Ti něco distcc? (pravda, na onom routeru to radši nepoužívám - ještě má své mušky :-)

Klidek. Tuhle sestavicku mam(i kdyz v trochu nadupanem vydani-1GB ram, SCSI hadr). Kompilace 3 dny vcetne Xek a Firefoxe. Vzhledem k tomu ze v praci mi bezi kompilace i tyden tak se to da vydrzet. Rozhodne kvuli tomu nemusim jit do binarniho distra(pri vzpomenuti na up2date se mi otevira kudla v kapse). Na server binarni distra dobry ale na domaci pocitac kde byva zvykem vymacknout maximum vykonu nejsou prilis vhodna.Ten rozdil je opravdu znat. Hlavne mplayer zkompilovan s -O3 potesi. Filmy prehrava bez problemu i bez hw akcelerace ve fullscreenu. Ve windows tentyz film je jak slideshow(5 obrazku za sekundu v okne).

1) zalezitost nastaveni USE flagu a/nebo xorg

2,3) Pokud to neni vadnym hardvare (oproti memtestu doporucuju prime95) tak forum.gentoo.org a vyhledat. 99% veci se uz to resilo.

chyby pri kompilaci nastavaji huste a neni to vzdy chyba ebuildu, hodne kompilaci rve ze chce flag -fPIC v CFLAGS (krome popsanych v clanku), to casto pomuze a pokud natvrdo instalujes ~amd64 nebo dokonce x86 ebuildy, da se ocekavat cokoliv, treba natlacit tam nejnovejsi k3b neslo bez rucniho opraveni zavislosti v portage

jakto ze Vam nefunguje dobre cnq? je to problem desky a jestli ano jake?

Pry je problem pri pouziti dvou oboustrannych modulu. Nejcastejsi pricina nefunkcnosti. Dobrotu nedelaji pametove moduly v 1 a 3 slotu. Pri pouziti jednoho slotu v druhem nebo tretim. Dale je temer nemozne rozchodit C'n'Q pri jinem nez defaultnim nasobici. To vsechno okorenime ruznymi typy desek, ruznymi BIOSy a pametovymi moduly a vznika neprilis chutny gulas ;-)

A v neposledni rade- C'n'Q vyrazne snizuje moznosti overclockingu coz ja jsem telem i dusi (pokud se jedna o muj domaci pocitac) takze jsem to popravde ani do hloubky prilis neresil...

Ak sa tento thread tyka aj acer aspire 15xx notebookov, mozno bude problemom aj nieco s ACPI tabulkou - tu je to pekne popisane: http://casteyde.christian.free.fr/laptop/LinuxOnAspire1511LMi.html

Pokud chcete rychle nasobeni(a pochopitelne i dalsi operace) velkych cisel na dnesnim 32bit procesoru tak pouzijete koprocesor bud primo nebo pres ruzne mmx/sse/3dnow. Velikost registru v koprocesoru je totiz jiz od 8087 80bitova(efektivne 64bit). A pri pristupu pres sse(jiz v p3!) jsou registry 128bitove.

souhlasim, ja kompilatoru pouziti rozsirenych instrukcnich sad nijak nebranil :)

Perfektni clanek, diky.

suhlasim , cital som jednym dychom . skvela forma , vysoka hodnota.

Taky se pripojuju. Fakt zajimave.

Take pripojuji sve diky za pekny clanek...konecne jsem se dozvedel neco o k8 (nemam uz cas cist spesl stranky o hw ;) a i jak je to s nim v nasazeni.

Tez, pripojuji se, fajn clanek, hodne informaci, zajimavych pro mne.

čistě náhodou nevíte někdo o nějakém pěkném přehledu procesorů, co se teď prodávají, kde by bylo vysvětleno, jak se liší Athlon64 od Opteronu, které verze Pentium IV jsou 64bit, jaké mají jednotlivé procesory parametry atd., a to všechno s vazbou na kódová jména, pod kterými se prodávají, a na desky/chipsety se kterými se dají provozovat?
mám v tom pěkný bordel :-( - Duron-like procesory se nám přejmenovaly na Sempron, nový Celeron určitě nenacpu do 5 let staré desky pro Celeron atd.

(případnou odpověď prosím i na kavol na email tečka cz)

http://www.geek.com/procspec/procspec.htm

jen tam nejsou jen ty soucasne prodavane, ale
vsechny :-)

Clanek musim, co se informacni hodnoty tyce, velmi pochvalit. Diky za nej. Na platformu AMD64 si jiz delsi dobu brousim zuby, a kdybych sehnal vhodny motherboard, tak uz ted nejaky ten Athlon64 urcite doma mam. V clanku jsem se vsak dozvedel tri pro mne dost neprijemne informace:

1) nForce funguje lepe nez VIA. nForce bych ale nerad. Mimochodem, neni to ten chipset, pro ktery je nutny i binarni driver sitovky (a buh vi ceho jeste)?
2) Pokud chci 3D akceleraci, znamena to, ze si musim poridit nVidii. ATI pouzivam od dob, kdy nVidia jeste ani neexistovala, a do zmeny se mi moc nechce.
3) Opravdu musim pouzit GRUB? Nechci GRUB, chci LILO!

ad 1) používám chipset via a chodí mi v pohodě i síťovka. podle testů, který jsem viděl, na chipsetu pod win nezáleží. je možné, že to na nForce pod linuxem běží rychlejc.

ad 2) pokud vim, pro ati zatim nejsou 64-bit. linuxový ovladače, ale prej se na tom pracuje.

ad 3) jestli chcete gentoo, tak prostě budete používat grub (proč ho nemáte rád?).

ps: super článek

S Gentoo se samozrejme da pouzivat i LILO. Ja osobne bych se GRUBu nedotkl ani dvoumetrovou tyci...

Pouziti LILa na !!AMD64!! je v Gentoo je mozne ale je to docela problematicke.

LILO funguje (alespon se nic podivneho nekonalo). Kompilovano z latest stable verze z homepage (Fedora 2 totiz nema build LILA pro AMD64).

LILO a GRUB jsou v teto chvili zcela rovnocene zavadece.

Kazdy ma sve vyhody i nevyhody, Pouzivam oba dva podle situace. le radsi mam GRUB. Umi natahnout system ze site a nemusi se porad instalovat.

Mas nejaky specialni duvod pro LILO, nebo jsi liny se podivat na konfiguraci GRUB-u a zkusit jej?

Jen konzervatismus sedmi let s LILO. Mam pocit, ze k zavedeni OS staci maly zavadec a nemusi k tomu byt potreba jiny maly OS (GRUB). :-)

mno, kdyz se nekdo preklepne v psani {grub|lilo}.conf a napise spatny jmeno image kernelu, prepise si jediny funkcni, nema po ruce bootovaci floppynu/cdcko, tak se ten grubovo shell celkem hodi :-)

Pokud je to dotaz na mne, tak ciste z nostalgie a lenosti. GRUB mi prijde zbytecne slozity.

1) Ne, existuje opensource forcedeth ovladac. Je jak ve 2.6, tak 2.4 jadre.

Me ten clanek moc informativni nepripada, jen zbezne se zminuje o ruznych vecech, pri instalaci cloveku asi nepomuze. Ani tam nejsou odkazy na kloudne testy (treba amd64 jednoznacne vede v rychlosti kompilace)

1. mam nForce na desktopu i notebooku a naprosto zadny problem
2. klidne pouzivej Ati dal a zemri v pokoji... Nvidii na linuxu povazuju za nejlepsi volbu, s 64bit zadnej problem a Twinview naprosto genialni
3. pouzivej jaky chces

No jo, ale hlavne nVidia kvuli ovladacim. Ati ma nekolik moc vydarenych karet, skoda tech problemu s ovladaci.

Takze pekne poporadku: suplovat gentoo handbook nehodlam, je to i v uvodniku. Snazil jsem se podchytit problemove body a tak verim, ze rade lidi to pomuze.

Odkazy na benchmarky jsem poskytl.

COZE? Amd vede v rychlosti kompilace? Oproti cemu? Oproti Athlonu XP- jiste ale to snad neni treba zminovat. Oproti P4 teda rozhodne nevede. Leda tak v pripade ze kompilator neumi vyuzit vice threadu (napr. Visual C). Vetsinu programu v Linuxu multithreadove kompilovat lze (zajisteno prepinacem make -j). A v tomto pripade dostane P4 s HT temer 20% "boost" a je oproti AMD64 se stejnym ratingem rychlejsi. Na vlastni kuzi vyzkouseno. To vse plati pro kompilaco na platforme i386. Preklad do 64bit binarky je jeste o neco pomalejsi.

ad rychlost kompilace: je to tak (32bit) dle testu na anandtech (merili bez threadu) http://anandtech.com/printarticle.aspx?i=2213

V dnesni dobe bych volbu ATI mozna chapal, ale od pocatku byla nvidia v 3D akceleraci(i kvalite) lepsi. Navic pro profesionalni vyuziti se ATI karty moc nehodi, uz prave kvuli tomu,ze ATI jsou amateri ve tvorbe ovladacu(ani po nekolika letech nedokazali opravit dementni chovani ovladacu).Mel jsem nekolik karet od nvidie a spravoval jsem dost pocitacu s ATI,navic mam ATI v notebooku. Absolutne nechapu nesmyslnou averzi nekterych lidi k nvidii.

Ahoj, super clanek, ale chybi mi jedna vec. Jak postupovat, kdyz uz Gentoo mam nainstalovane? Moje idealni predstava je, ze si nejdrive (jeste na AthlonXP) prekompiluju jadro s podporou noveho HW, emulaci 32bit atd. a po nabootovani na A64 bych udelal emerge system a world.

proc? kernel se mi na athlon-tbird/1200, 256MB RAM, s pustenejma Xkama a pri bezny praci kompiluje asi 20 minut, to ti prijde nejaka velika ztrata casu?

no, asi sme se trochu nepochopili....Jde mi o to, ze uz mamnainstalovany a podle sebe nakonfigurovany gentoo na AthlonXP a asi za mesic budu mit Athlon64. Takze budu muset instalovat nanovo(coz se mi vubec nechce) nebo pujde prekompilovat moje stavajici gentoo? To je muj problem a zatim jsem o tom zadny clanek nenasel.

Nebude potřeba to dělat nanovo. Kernel bude ale potřeba upravit (pokud ho nemáte zkompilovaný nějak hodně univerzálně) v každém případě, protože jiná deska a jiné periferie.

Podle mě by to mělo jít udělat tak, že se emergne jenom vše potřebné pro vytvoření 64bit kernelu + 32bit emulace a zkompiluje jádro pro 64bit. A po rebootu pojede jádro v 64bit režimu a zbytek v 32bit s tím, že při každém update systému se daný balík už bude kompilovat rovnou jako 64bit.

a proc ne radsi nanovo a ciste nez zabredavat do techhle sracek? kernel se na Athlon64 3400+ kompiluje asi dve minuty a emerge obycejnych balicku je tak rychly, ze nevidim rozdil proti instalaci binarnich baliku u jinych distribuci. emerge mplayer z prazdnyho systemu trvalo sice asi 2h, ale kompilovalo to naprosto vse vcetne Xek.

sezente si amd64 jadro (kompilovane gcc-amd64 samozrejme, bez crosscompileru to jadro bude porad 23bitove - takze idealne treba to z instalacniho CDcka pro gentoo-adm64), nabootujte, upravte make.profile a prestavte system.

Takhle jednoduche to nebude :-( Bylo by treba sachovat s umistenim knihoven atd.

Ja jsem si zase myslel, ze normalne ke slackware v jedne partition a i386 gentoo v druhe pridam jeste jedno AMD64 gentoo v treti partition ... a ze pobezim vsechny tri najednou (s pomoci chrootu) jako to delam ted se dvemi ... prekvapilo me, ze by se muselo pouzivat nejake linux32 ... a ze neni navod pro instalaci AMD64 crosskompilaci z i386 ...

skusil by som to tak, ze by som stiahol minimal gentooamd64 livecd,bootol, chrootol , zmenil symlink /etc/make.profile na /usr/posrtage/profiles/default-amd64..
editol flagy a USE v make.conf a potom emerge -eu world - samozrejme sa to "kousne" pri app ktore na amd64 neskompilujes(oof,lilo...)-tie bude potrebne preskocit ,ale inak by to nemal byt problem..a nakonec k tomu vsetkemu este doinstalovat lib na emul 32b+prekompilovat kernel

Mě by spíš zajímalo srovnání reálných věcí v reálném provozu na reálných procesorech. Ne jen ve 32/64 bitovem režimu na stejném procesoru pustit test tak "synteticky" že používá jen cache a příliš se tak neprojeví ani rychlý přístup do ram. Smysl má spíš porovnat tu amd64 vs x86 architekturu jako celek. Třeba například změřit čas kompilace jádra na athlonu xp 3000 a jádra se stejným .config na optimaliovaném 64 bit systému na amd64 3000. Jasné že to značení 3000 je trochu zavádějící a nejde o stejně výkonné procesory...

To je rozdíl v přístupu, ti co tomu nerozumí preferují komplexní benchmarky, protože jim z toho vypadne jedno číslo a to jsou ještě schopni pochopit. Jenže když vím, která část systému mě zajímá, tak si otestuji přesně tu část, co mě zajímá. Pokud chci testovat rychlost CPU, tak nebudu testovat paměti, jejich řadič, řadič disku, disk, fs, kontext switche os, kompilátor, ... a já nevím co ještě. Kdybych náhodou chtěl testovat celou architekturu, tak budu testovat celou architekturu, ale to už by bylo rychlejší si nějaké to číslo vycucat z prstu a vyšlo by to nastejno, protože do toho vstupuje tolik těžko odhadnutelných faktorů, že by autora vzápětí někdo "upozornil", že kdyby použil síťovku A místo B, tak by mu disk značky C fungoval o 0,023% rychleji než disk značky D. To je dnes nějaká móda, že když vím že potřebuju rychlé CPU, tak musím mít za každou cenu rychlé disky?

To je váš názor s kterým nesouhlasím a nemám zapotřebí vám ho ani vyvracet :-)

Mozna sem z tech "co tomu nerozumi" ale co by v takovem testu branilo pouziti stejne sitovky, disku, pameti, filesystem ? HW by mohl byt stejny v ramci kompatibility obou technologii. V takovem testu jde a relativni srovnani ne absolutni.

A říká vám něco citlivost testu? No tak ta jde úplně zbytečně do háje.

Souhlasim, ponevaz kdyz mam dilci vysledky jako rychlost CPU, rychlost pameti (move, read, write, random atd.), rychlost disku (read,write,random atd.), umim z toho vyvodit jak rychlej bude celkovy system, ktery me zajima. Celkove cislo me nezajima, je k nicemu, presne jak pises, klidne se muze vycucat z prstu.
Rekne mi treba neco vysledek testu pcbenchamark nebo jak se jmenuje ? Naprosto nic. Protoze dva pocitace, se cca stenym cislem muzou byt ve skutecnosti naprosto rozdilne prave kvuli tomu, ze to ma naprd sitovku :o)
Ovsem musim podotknout, ze nektere synteticke testy jako treba Sandra, merici kuprikladu rychlost pamati, jsou dost k nicemu. Meri nejake pofiderni cisla, zajimave jenom z technickeho hlediska, v reale naprosto nepouzitelne. Takze specialni testy ano, ale realisticke.

Nabidl jsem odkazy, kde takove benchmarky je mozno najit... nemam moznost sam je udelat.

Zrovinka porovnani rychlosti kompilace jadra by bylo velice zavadejicim testem... 64bit prekladac prekladajici do 64bit strojaku... 32bit prekladac preklada do 32bit strojaku... ted ty prekladace byly prelozeny s nejakymi volbami, nektere casti zrojaku jsou pro obe platformy rozdilene... jak tady zarucit srovnatelne podminky?

Ale kdepak , co brání nastavit vlajky tak aby se prekladalo uplne to stejne a aby binarni vysledek kompilace byl na obou architekturach stejny ? Na to přece není nic zavádějícího.

>...a aby binarni vysledek kompilace byl na obou architekturach stejny...

A to je jako prakticky test kompilovat na 64bit platforme 32bit binarku (nebo na 32bit platforme komilovat 64bit binarku to je jedno, pokud chcete stejny binarni vysledek tak budto na jedne nebo druhe platorme crosskompilaci pouzit musite)? To vetsinou teda nedelam. A kdyz tak 32bit verzi prekladace v chrootovanem prostredi. Navic by se preci jen jednalo o crosskompilaci coz by mohlo mit dopad na vykon.

Tak muzes treba dat na obou kompilovat pro Sparcy ..

Na beh 32bit aplikacii nepotrebujete 32bitove kniznice. 32bitove aplikacie bezia bez problemov aj zo 64bit kniznicami (aspon zatial som nenarazil na aplikaciu, ktora by s tym mala problem). Vyhodou je dokonca vyssi vykon, pokial sa vykonava kod z kniznice.

Java 5.0 uz ma oficialny release http://java.sun.com/j2se/1.5.0/download.jsp

Je dostupne JDK aj JRE vratane verzii pre AMD64.

Velky omil... 32bit binarka sa nezlinkuje so 64bit kniznicou... uz len preto, ze pointery 32bit binarok maju 32bit a 64bitovych 64bit... ako to xes adresovat??? Na problem si nenarazil, lebo mas aj 32bit kniznice, tzv. multilib... alebo staticke binarky. Takze take spresnenie.

/lib64 je linka na /lib v ktorej su 64bitove kniznice. Ak si nahram 32bitovu binarku a dam na nu ldd tak mi vypise kniznice z /lib. Ked dam strace tak ich aj linkuje. Vyskusajte si to.

#include <stdio.h>
int main(char * argv, int *argc) {
printf("Hello world!\n");
return(0);
}

sun-amd64 root # vim hello.c
sun-amd64 root # gcc hello.c
sun-amd64 root # ./a.out
Hello world!
sun-amd64 root # ldd ./a.out
libc.so.6 => /lib/libc.so.6 (0x0000003000200000)
/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000003000000000)
sun-amd64 root # file ./a.out
./a.out: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), not stripped
sun-amd64 root # gcc -m32 hello.c
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.2/./libgcc.a when searching for -lgcc
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.2/libgcc.a when searching for -lgcc
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.2/./libgcc.a when searching for -lgcc
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.2/libgcc.a when searching for -lgcc
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.2/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lgcc
collect2: ld returned 1 exit status

Linkovat 64bit inarku s 32bit knihovnou (a naopak) IMO na AMD64 nelze.

V dobe, kdy jsem clanek psal Java 5 jeste fakt nebyla released :) V gentoo je stale masked a pokud se nainstaluje natvrdo tak pak porad v clanku zminovany Eclipse budto nefunguje nebo funguje pomalu :(

Si myslim, ze nejenom na AMD64.

Jsou volby gcc opravdu optimalni? Kazdopadne vysledky nejsou moc povzbuzujici, alespon co se tyce srovnani gcc a MS-V.S.net. Vzdyt na co je vykonny procesor, kdyz z nej diky prekladaci nevyzdimete maximum.

Skoda take, ze autor neudelal i nejake testy s plovouci carkou.

ona se rychlost docela špatně porovnává. ve většině testů, co jsou na netu, se srovnává amd64 vs. pentium 4 v 32 bitovym režimu (windows). narazil jsem ale na test, kterej srovnával na amd64 3200 32-bit a 64-bit linux. na tej 64-ce byl lame encoder skoro o 40% rychlejší. kdyby byl zájem, zkusím to někde najít.

http://www.anandtech.com/linux/showdoc.aspx?i=2213

Tabulky standardně ukazují výsledky 32-bitových testů, ale když se nad ně najede myší, objeví se 64-bitové výsledky.

Jo je to vsechno prima ale po case se dost veci zlobi, receno slusne, mam klienta kterej ma 2 Server kazdy Dual AMD Opteron(tm) Processor 242, na obou bezi Gentoo64 pouzivaj to jako Terminal Server (14 X11 Terminalu), jedou gnome a vsechny mozny OpenSource Aplikace a taky VMWARE (vmware sice jede ale 64bitovej kernel mu nedovli pristup na 32usb..:( ) dale komercni programy s tim taky moc happy nejou VariCAD treba, dost nestabilni, rozchodit treba 3 graficke karty (at ATI ci NVIDIA ci S3 ci Trident.. ci cokoliv) je prakticky nemozne. Rychlost je super to kazdopadne klidne 6 lidi kazdej muze mit vmware + OO + firefox + Evolution, druha vec je stabilita Gnome plus Gnome-Session, Adobe Reader se nam nepodaril rozchodit ani v chrootu ani nikde.. Flash resim pres Firefox32, video+sounds nastesti nepotrebujou, ADM64 je zajimave reseni ale lepsi to mit doma na hrani ,nez u klienta :(

Jestli nekdo ma pozitivnejsi zkusenosti rad se neco priucim.

cerw

Nezda se mi tvrzeni, ze implicitne je podpora NX bitu vypnuta.
Podle me je to tak, ze implicitni hodnota parametru noexec je noforce. Pri teto konfiguraci je NX bit vyuzit u ELF binarek zkompilovanych s podporou PT_GNU_STACK. Da se to zjistit takto:
readelf -l /bin/ls
Ve vystupu hledejte header "STACK". Jestli ma nastaveny pouze bity RW a nema bit E, tak bude mit pri spusteni non-executable stack.
noexec=on slouzi k tomu, ze bude NX bit vynucen i u starych binarek bez PT_GNU_STACK.
Jestli se mylim, budu rad, kdyz mi nekdo vysvetlite, jak to teda je.

Prasata, neumijou kompilovat. Moje aplikace behaji v 64 bitovem rezimu o 20% lepe nez v 32bitovem.