Jelenlegi hely
Slamd64 11.0
Üdv!
Ma végre rászántam magam, hogy a jól bevált slamd 10.2 után feltegyem a 11.0-ás verziót, az ezzek kapcsolatos tapasztalataimat osztom meg, hátha ettől valaki kedvet kap/visszariad :) az áttéréshez/től.
Szóval:
-A telepítés során semmi sem változott (nem vettem észre), a szokásos gyors módszerrel hamar felmegy a rendszer.
-A kernel, amit adnak hozzá a 2.6.16.29. A 2.6.16.-os szériával régebben is sok gondom volt, most sem volt ez másképp, hosszú vérverejtékes kernelfordítások sorozata után sem tudtam olyat készíteni, amivel az iptables tűzfalam hibaüzenet nélkül lefutott volna, úgyhogy ezek után az rm -R-rel átadtam az egész source könyvtárat az enyészetnek és elővettem a régi 2.6.17.9-est, ami a rég megszokott módon azt csinálta, amit szerettem volna.
-A rendszer tartalmaz (végre) 64 bites Firefox-ot és Thunderbird-öt, aminek nagyon örültem, azonban a Firefox-hoz nincs java, szóval ez megint egy hosszú küzdelem eredménye lesz. (Ha valakinek erre van megoldása, nagyra értékelném, ha közzétenné.)
-Itt szeretném felhívni a figyelmet, hogy aki (hasonlóan hozzám:) ) rutinból pakolgatja fel a számára szükséges csomagokat, nézzen kicsit körül, mert az említett két programhoz hasonlóan sok új csomag bekerült, így azokkal nem kell bajlódni többé.
Na megyek is és tesztelem tovább, ha valami izgalmasat találok, még folytatom a hozzászólást.
Remélem valamit ezzel is segítettem azoknak akik gondolkodnak a 11.0-ás verzión.
Üdvözlettel: Forr
- A hozzászóláshoz regisztráció és belépés szükséges
Re: Slamd64
Udv Forresty!
Sebessegben tapasztalsz kulonbseget? Eszrevehetoen gyorsabb mint a 32-es verzio?
(A nyaron raktam fel egy AMD64 bit-es gepre Fedora Core 5-ot, az pl. lassubb volt mint a 32 bit-es Slackware ugyanazon a gepen.)
udv.
kris *_^O^_*
Aurora
slackware 11.0 kernel 2.4.33.3
Lassabb a 64bit
Sziasztok
Én több helyen is azt olvastam, hogy nem érdemes minden programot 64bitre optimalizálva fordítani, hiszen a programok nagyrésze még a 32 bit hosszúságú változókat sem használja ki (2^32 = 4'294'967'296), így ha 64 bitre fordítod őket akkor legalább 32 darab 0-val is számolnia kell a processzornak feleslegesen...
Szvsz elég ha a kernel támogatja a 64bites procit, minden más 32 bites.
BaBo
----------------------------
Ez egy nedves kor
Nappal vér folyik, éjjel bor
Hobo Blues Band - Vadászat
.oOOo.oOOo.oOOo.oOOo.oOOo.
2.6.17.3 @ Slackware 11.0
Firefox + java + tapasztalatok
Sziasztok
Amikor a Slamd64-11.0 megjelent én egyböl felraktam, és neki áltam faragni a rendszert (kernel fordítás...stb). A Firefox-hoz, Seamonkey-hoz blackdown-java kell www.blackdown.org -> download -> mirror-select -> amit letöltöttem az a j2re-1.4.2-03-linux-amd64.bin -> "x" jog, futtat, telepít. Majd linkeltem a libjavaplugin_oji.so-t a böngészők plugins alkönyvtárába. Böngésző indít -> látszik a telepített bövitmény. A gond az volt, hogy amikor a böngésző az adott web-oldalt és vele együtt a java kisalkalmazást betöltötte akkor a böngésző crashelt firefox is, seamonkey is. Tesztnek jó a www.teletext.hu. A log fájl meg ott volt a felhasználó könyvtárában. Néha más egyéb alkalmazások is crasheltek, főleg a hang kezeléssel összefüggő progik (KMix, KsCD). A Konqueror viszont nem csinált ilyet az müködött rendessen java-val. Sajna a Konquerorba a többi plugint (flash, mplayer-plugin) nem tudtam müködésre bírni, így nem volt egy olyan 64bites böngésző amit teljes egészében tudtam volna használni. Ezek utána /dev/hda2 alól - ez nekem a 32bites Slackware helye - a /programs alkönyvtárat átmásoltam a /dev/hda1 alá, ebben van firefox, seamonkey, java, flash-plugin, mplayer-plugin szóval minden ami kell és így 32bites-ként müködött minden. Persze a kernelbe kellett a 32bit támogatása fixen, na és persze 32bites mplayer is. Sajna a 32bites mplayert nem tudtam megcsinálni Slamd64 alatt, nem futott le a configure hiába adtam meg a megfelelő opciókat, így aztán Slackware alatt checkinstallal csináltam belőle csomagot amit aztán telepítettem Slamd64 alá, és mivel az mplayer 32bites, így kellett neki minden olyan csomag amitöl az mplayer függ 32bites verzióban (faac, lame...stb) tizenvalahány csomagot kellet leszednem hozzá. Szóval nem volt egyszerü a dolog, ráadásul "visszafele" fejlesztettem a rendszert 64bit->32bit. Ami a sebességet illeti gyorsabb a Slamd64 a KDE-t 25%-kal kevesebb idő alatt tölti be mint a Slackware, más kérdés, hogy IceWM-et használok. A boot idő is kevesebb, más programok is gyorsabban indulnak...stb. A program crashek, valamint a "64-32 mix" miatt úgy döntöttem, hogy inkább maradok a 32bit mellett, mert az megy évek óta stabilan.
Egyébként érdekes, hogy a Slamd64-10.2 alatt lévő mozilla, illetve firefox ezzel a blackdown-java-val nem crashelt. A hang kezelés viszont ott is bajos volt, kellett hozzá egy frissebb verzió az arts-bol, az segitett a hang problémán.
Bye
Szia Kris!
Sajnos nem tudom, hogy gyorsabb-e a 64-bites, mint a 32-es, mert azóta linuzom, hogy megvettem a 64-bites architecturát és arra rögtön az slamd64 ment, szóval nem ismerem a 32-bites slakit.
Nem tudom, hogy a programok lassabbak-e vagy sem, de azért gondolom nem véletlen jelent meg a 64-bites változat. Ha lassabb, mint a 32-es, akkor semmi értelme.
Legalább is én nem látom értelmét.
Tanci!
Mplayer fronton tudok csak hozzászólni:
Én kizárólag Konzole-ból használom, ahhoz ez kiváló:
http://www.faleiros.eti.br/SlackBuild/mplayer.tar.bz2
én grafikus felület nélkül használom, nekem bevált és simán települ, fut, nincs vele hókuszpókusz.
64bit, 32bit
Udv Forresty!
irtad:
"...gondolom nem véletlen jelent meg a 64-bites változat. Ha lassabb, mint a 32-es, akkor semmi értelme.
Legalább is én nem látom értelmét."
Igy gondoltam en is, ezert is lepodtem meg nagyon amikor azt lattam, hogy a 2.6 GHz CPU AMD64 gepen a 64bit-es FC5 eszrevehetoen lassubb volt mint a 32 bit-es Slackware 10.2.
Persze ez ket kulonbozo rendszer, de azert azt vartam volna, hogy a 64 bit-es FC5 szinte "elrepul" majd a 32 bit-es rendszerhez kepest. Eppen forditva tortent.
Kivancsi lettem volna tehat egy Slackware "64-32" teszt-eredmenyre. Mindenesetre BaBoKa kozleseben lehet valami.
udv.
kris *_^O^_*
Aurora
slackware 11.0 kernel 2.4.33.3
Igaz
Valóban logikus amit Babooka ír, ugyanakkor érdemes megszívlelni Tanci erre vonatkozó sorait is, mivel neki mindkettő van, és Ő sebesség terén a 64-bit mellett teszi le a voksát.
Tanci!
Irigyellek, hogy Neked legalább crashel a flash. :) Én hiába telepítem, linkelem, meg sem nyikkan. Mintha nem csinálnék semmit.:(
Info
Sziasztok
Adott egy 64 bites architektúra. Ez azt jelenti, hogy a processzor, memória, perifériák...stb. között az adatátvitelre 64 "szál drót" áll rendelkezésre, és minden egyes eszköz ezt képes kezelni. A prociban van elegendő számú regiszter, cache, tranzisztor..stb, memória szintén....stb. amennyiben valaki egy ilyen gépre 32 bites OS-t telepít akkor az adatbuszon egy adott idöpillanatban csak 32 db. "dróton" lesz hasznos információ a másik 32 db. "dróton" csak 0 lesz és a rendszer mind a 64 bitet kezeli pl a proci egy órajel alatt mind a 64 "szál dróton" lévő adatot feldolgozza, függetlenül attol, hogy 0 vagy 1 az értéke, és ez a lényeg. Nézzünk egy egyszerü példát: adott egy ablakkezelő (KDE,IceWM..stb). Amikor ezt az ablakkezelőt elinditod akkor ennek a memóriába be kell kerülnie, ez tartalmazza a háttérképet, parancsikonokat a munkaasztalon..stb. A felbontástól függöen az egyes képpontok adatait (szín, kontraszt..stb) egyenként ki kell számolni, megjeleníteni. Amikor megcsinálta az ember az xorgconfig-ot akkor meg kellett adni többek között a színmélységet is, és ha itt te 256-ot adtál meg ami 2^8-on akkor egy képpont szín információja 8 "szál dróton" található meg, és ha a rendszer 64bites akkor egy egyidőben 8 képpont adatait lehet feldolgozni, mert 8x8 bit = 64 bit. Ezért gyorsabb egy optimalizált rendszer. Nem véletlen, hogy a grafikus kártyák között már kapható olyan amin a kártyán lévő Graphic Processor Unit és a kártyán lévő memória közötti adatbusz szélessége 256(!) bit, mert az órajelet nem lehet a végtelenségik növelni, a busz szélességet viszont aránylag könnyen, és ez által a sávszéllességet.
Összehasonlítás:
Minden egyes linux disztró másként épül fel, másként müködik. A Slamd64 azért jó, mert ez a Slackware egy nem hivatalos 64 bites portja. Ugyanazok a csomagok alkotják, rendszerindítás...stb. csak a programok 64 bitre optimalizáltak. Szóval csak így lehet összehasonlítani 32-64 bitet. Ugyanazon disztró 32 bites verzióját hasonlítani a 64 biteshez, van még néhány ilyen disztró.
Programok:
MPlayer: 64 bites rendszeren az MPlayert lehet fordítani 64 bites optimalizációval, csak így a wmv fájlokat nem fogja lejátszani (hang van, kép nincs), mert a wmv kodek csak 32 bites. Az elöző hozzászólásomban már egy kicsit kiveséztem a gondokat vele.
MPlayer-plugin: ua. javasolt a 32 bit.
Java: a blackdown-java elérhető 32 és 64 bites verzióban. A 32 bites gond nélkül használható - amennyiben mind a java, mind a böngésző 32 bites,a 64 bites csak a Konqueror-al ment, Firefox, Seamonkey crashelt a java betöltése után. Szóval ha 32 bitesként akarod futtatni ezeket, akkor 32 bites rendszer alatt kell a javat kicsomagolni, telepíteni a Firefoxot, Seamonkeyt megcsinálni a linkelést..stb. majd az egészet mindenestől átmásolni a Slamd64 alá. Nekem ez megvolt 32 biten a /programs/firefox.. /programs/seamonkey.. /programs/j2re-1.4.2-03..stb helyen. A böngészökböl az FSF féle verziókat használom nem a Slackware, Slamd64 csomagot.
Flash-Player: ebböl is csak 32 bites verzió létezik, igy javasolt a 32 bites böngésző használata, telepíteni is csak 32 bites környezetben lehet. Nekem ez szintén adott volt csak másolni kellett mindent.
Létezik egy nspligunwrapper nevü program 64 bites környezet alá. Ez lehetővé teszi a 32 bites pluginek (flash, mplayer-plugin) használatát 64 bites Firefox, Seamonkey alatt megcsináltam, müködött. Konqueror-t viszont nem támogatja.
A böngészők terén 64 biten így az a furcsa helyzet állt elő, hogy a Firefox, Seamonkey vitte a flash-t, mplayer-plugin-t, viszont crashelt a java-tol. A Konqueror meg vitte a java-t, viszont nem volt flash, + mplayer-plugin.
Szóval én ezek miatt használom a Slackware-t és nem a Slamd64-et. Késöbb, ha "kinövi a gyerek betegséget", lesz (?) mindenböl stabil 64-es verzió, majd akkor átállok.
Bye
Nem ertek hozza...
Nem ertek hozza, csak abbol epitkezem amit mashol olvasok...
Viszont valamin megakadt a szemem:
Amikor megcsinálta az ember az xorgconfig-ot akkor meg kellett adni többek között a színmélységet is, és ha itt te 256-ot adtál meg ami 2^8-on akkor egy képpont szín információja 8 "szál dróton" található meg, és ha a rendszer 64bites akkor egy egyidőben 8 képpont adatait lehet feldolgozni, mert 8x8 bit = 64 bit.
Ez nem csak akkor van ha a proci tud hyperthreading-et? Kulonben egyszerre csak 1 dolgot tud szamolni?
BaBo
----------------------------
Ez egy nedves kor
Nappal vér folyik, éjjel bor
Hobo Blues Band - Vadászat
.oOOo.oOOo.oOOo.oOOo.oOOo.
2.6.17.3 @ Slackware 11.0
Hyperthreading
Sziasztok
A Hyperthreading az Intel cég fejlesztése és lényegében azt teszi lehetővé, hogy a processzor feldolgozó magja az aktuálisan végrehajtás alatt álló művelet által éppen nem használt részegységei hasznosításával egyetlen egy utasítás helyett párhuzamosan akár több művelet feldolgozásával is foglalatoskodjon, így látszólag egy valóban többprocesszoros ill. -magos rendszer működését utánozva. A manapság kapható 64 bites procik AMD és Intel ezt egyaránt tudják. Ennek a hyperthreading rendszernek van egy külön órajele, az AMD honlapjáról én letöltöttem egy PDF filet ez részletessen tartalmazza az AMD procik ilyen jellegü adatait (órajelek, fogyasztások...stb). Az első 64 bites procik mind AMD mint Intel részröl ezt tudták-e vagy sem arról sajna nincs infom.
BaBoKa kérdésére a válasz igen ha a proci tudja a hyperthreadinget.
Bye
mplayer
Az mplayer nekem is minden gond nélkül lefordult, gui-val együtt, így van végre rendes médialejátszóm a 64-bites rendszeren. A plugins-csomagból valóban csak 32-bites van, de divx, xvid videókat, mpeg2-t, ac3-as hangot anélkül is játszik, real videoim meg nincsenek.. úgyhogy jó így is :)
Ellenben nem sikerült lefordítanom a dclibet, ami a valknut előfeltétele ( http://www.dcs.warwick.ac.uk/%7Ecsucda/tarballs/ ), sem pedig a LinuxDC++-t. Az előbbi olyan fura hibaüzenetet ad, hogy azt sem tudom, mit kezdjek vele, az utóbbival még szenvedek egy kicsit..
Igaz, dclibből és valknutból találtam x64 bináris csomagokat, ami működik is, csak az ugyebár régi. LinuxDC++ lenne jó, de azzal sem jutok előbbre :)
Ati driver
Sziasztok,
Sikerült valakinek Slamd64 11.0 alól beüzemelni a legújabb ATI drivert? Ha igen, akkor hogyan? :)
A telepítő viszonylag hamar feltette, amit szeretett volna, azonban utána az történt, hogy a 3d gyorsítás csak root user alól akart működni...
Root alatt:
root@molni-002:~# fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: RADEON X300/X550 Series Generic
OpenGL version string: 2.0.6065 (8.29.6)
root@molni-002:~#
Sima user alatt pedig:
szabolcs@molni-002:~$ fglrxinfo
libGL error: failed to open DRM: Operation not permitted
libGL error: reverting to (slow) indirect rendering
display: :0.0 screen: 0
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.2 (1.5 Mesa 6.4.1)
szabolcs@molni-002:~$
Keresgéltem más fórumon is, illetve google-ztam eleget, ami infót találtam, hogy egy DRI section-t kell felvenni xorg.conf-ba.. Hát, felvettem, de sajnos ugyanaz az eredmény.
Tudják. Nekem egy "első,
Tudják. Nekem egy "első, de lehet hogy második generációs" 754-es amd64 athlon64-es procim van, le nem cserélném semmi pénzért, mert a relatíve kevesebb cache miat (512kb)jobban tuningolható, így a memóriaműveéletek kivételével gyorsabb, mint a 939-es. (mondjuk ha nem húzom akkor viszont a 939 jobb).
Hát az én 939-esemben is
Hát az én 939-esemben is 512kb cache van. Ritka és drága az 1mb-os.