optimalizáció?

Linux-kezdő

Sziasztok!

Először is: nem vagyok gyakorlott Linux-felhasználó & egy Core Duo (nem Core 2, x86_64 kilőve) CPUs laptoppal dolgozom (fizikus hallgató vagyok, bizony a numerikus szimulációknál jó szolgálatot tesz ez a kétmagos jószág).

Régebben volt dolgom Debiannal, szerettem a stabilitását (testing) és természetesen az apt-get-et. Ugyanakkor most, h újra Linuxot szeretnék a gépen látni, felvetődik a kérdés, h a Core Duo-t desktop használatra (ahol azért fontos a stabilitás, nem szeretném, ha diplomatéma írás közben feldobná a talpát a rendszer egy csomagfrissítés miatt + szeretem azért, ha az alkalmazások fürgén indulnak)
miért i386-ra optimalizált csomagokkal használjam...
(tudom, kernel, libc, stb. van i686-ra optimalizálva is, most olyanokra gondolok, mint pl Firefox (Iceweasel), TeXLive, Ooo, néhány FPS...)

1) Tud vki vmilyen kiterjedtebb benchmarkról (több programmal, gondosan mérve), h az optimalizáció mennyit hoz a konyhára?
(Volt ebből már pár flame topic itt a hup.hu-n, de ott is csak elvétve volt 1-2 objektív mérési eredmény, pl apache-ról, amit amúgy se használok)

2) Ami disztrókról még olvasgattam:
- GENTOO. A Portage-tree kellemesen be van népesítve. Ha kell, hajlandó vagyok szöszmötölni a géppel, de linux-kezdő létemre erősen kétséges, h nekem való-e! + ha vmi gebasz miatt gyorsan kell újrarakni a rendszert...
- ARCH, YOPER. Repo-méret? Szeretem, ha minden ami kell repóból elérhető... Fejlesztőtábor-méret? HowTo-k, ha vmi gebasz van?
- FRUGALWARE-t -bár i686- egyelőre hagyjuk.

PCLinuxOS-t kipróbáltam pár óra erejéig LiveCD-ről, addig semmi gondom nem volt vele, repo is szépen hízik. Stabilitás az említett felhasználásra? (A többi RPM alapú disztrót hagyjuk.)

Ti mit ajánlotok? Tapasztalatok?

  • 2770 megtekintés

( kamm | 2007. 06. 17., v – 11:55 )

arra tehetsz debian-amd64 -et is, azok a csomagok x86_64-re vannak forgatva, hasznaljak a +8 regisztert, a 64-bites kiterjeszteseket is, de olyan egetvero gyorsulast ne varj tole, bar a szamolasaidhoz lehet, hogy valamit hasznal, bar szerintem ott inkabb SSE2 tobbet szamit.

firefox-bol pedig nezd meg esetleg swiftfox-ot.

( MetaMorfoziS | 2007. 06. 17., v – 11:59 )

Annó pch-tól hallottam a "hardinfo" nevu progirol.
Probald ki, nekem az egyik tesztnel mindig 0-t irt, de a tobbi attol meg szerintem alaklmas lehet a tesztre.
De amúgy, kernelfordítással szokták teszelni, ugyan azt a configot leforgatod ittis ottis aztan nezed az időt. (Amit stopperrel is lehet, de ha `time akarmi` val indítod kicsit egyszerubb.)

En amugy kubuntu edgy-t futtatok most egy core duo gepen, a 32bites verziot, mert a 64bitessel csak a szopas volt (pl mplayer) de egy rakas cucc nem volt jo, vagy nem is volt vagy nem mukodott, ez persze nyugodtan foghato a benasagomra.

__________________________________________________________________
Dúdold ezt a dalt, és aki gyűlöl majd érte, az lesz a bosszú népe.

( Gabucino | 2007. 06. 17., v – 12:34 )

gentun tegnap sirtam be, admin ilyen verzioszam fetisiszta, es viccbol upgradelt mindent a linuzban, including apache (azota sincs SSL, eleinte userdir se volt, crond es smtpd is lehalt, neat)

Namost az volt a szanalmas, hogy apache2-hoz kulon php.ini-t rakott fel a rendszer, termeszetesen breakage-t okozva nehany szolgaltatasban.

kthxbye, talan me'g a debiannal is fosabb ez

nyilvánhogy ha valaki tapasztaltabb, akkor ismeri a csomagkezelőjének a szolgáltatásait - gondolokitt CONFIG_PROTECT CONFIG_PROTECT_MASK és társaira. talán van még rcs-t támogató konfig-updatelő is hozzá a kicsit szegényes etc-update helyett.

szóval szerintem ez a user_error kategória a fetisiszta kollegánál. namondjuk mondom pont most mikor gentoo rendszerem halt majdnem le egy remek glibc update után :)

--
hege

en volnek az az allitolagos fetisiszta. jelen esetben viszont nem volt mit CONFIG_PROTECT-elni, hisz kulon config file kerult fol. RCS helyett meg mar parszor meg1eztunk abban, h ha vki piszkalja a configot 1 szuz csomag eseten, akkor csinal 1 'cp /etc/configfile{,.orig}' backup-ot.

Gondolom nem kell megnevezni, h ki volt aki ezt nem tette meg, valamint 'rc-update add cron smtpd stb stb default' -ot se mondott miutan feltelepitette es beallitotta oket.. En nem lepodtem meg h az elso reboot utan a szolgaltatasok fele nem indult el defaultbol.

Tovabba nem fetisizmusbol kerult fol az apache2, de teny, h nem birtam ravenni a rendszert, h apache1 maradjon 'emerge world' utan. Csak epp en ezt annak tudom be, h a gep tobbi adminja (gabu, gyurix) csomo cuccot eroltetett fel mindenfele ad-hoc, one-time USE-flag es KEYWORD specifikaciokkal. A multi-adminsag bizony komplikaltabb es kello megegyezesek illetve azok betartasanak a hianyaban lehetnek komoly gubancok is.

Doksi persze nuku arrol, h a gep melyik user-e milyen szolgaltatasokat igenyel es milyen beallitasokkal.

Ilyen korulmenyek kozott probaltam kicsit atvenni a gep karbantartasat gabutol.

Ami az SSL-t illeti, az a kedvencem. Gabu beallitotta apache1 alatt, https-es webmail kedveert, amit kb csak
o meg a baratnoje hasznal. Apache2 alatt persze ugyanaz a konfig nem ment csak ugy bamban atmasolva, igy megigertem h kb 2heten belul majd megcsinalom, MERT gabu *nem hajlando* apache2 konfighoz nyulni, mondvan, h az szar. Amugy kb most telik le a 2 het..

Ha en fetisiszta vagyok akkor o meg mondjuk hisztispicsa? ;p

Amugy sztem nincs sok baj a Gentoo-val. Kb annyira lehet elrontani, mit egy biciklit, ha pl botot dugunk a kulloi koze.

:)

> valamint 'rc-update add cron smtpd stb stb default' -ot se mondott miutan feltelepitette es beallitotta oket

Ilyen is van? Minek? Akkor az initscript se induljon el addig, a'la FreeBSD. Ennyit a gentoo logikajarol.

> csomo cuccot eroltetett fel mindenfele ad-hoc, one-time USE-flag es KEYWORD specifikaciokkal

Szerintem meg ilyen nem volt, foleg hogy apache-hoz koze legyen (annal is inkabb mert gentooban defaultban broken+unfixable volt a squirrelmail is, tehat azt is tarballbol installaltam, meg a tobbi webmailert is). De ha ettol megdoglik, akkor ijb.

> probaltam kicsit atvenni a gep karbantartasat gabutol

Khm, a gep mindig is a tied volt. En gentoot at nem veszek, mert egy kaotikus logikatlan szemet.

SSL-t en nem hasznalom, mint ahogy a szervert se, de mondjuk az osszes levelezo user igen. De mar nem, mert nincs, breakelted.

> Khm, a gep mindig is a tied volt. En gentoot at nem veszek, mert egy kaotikus logikatlan szemet.

valoban a laci is telepitett/konfigolt dolgokat rajta, de alapvetoen te allitottad be, max mar elfelejtetted,
mint ahogy azt is h csomagbol raktal ra irc szervert vagy kezzel forditottal ra. egy biztos, en nem konfigoltam, mert kurvara nem ertem ra.

> SSL-t en nem hasznalom, mint ahogy a szervert se, de mondjuk az osszes levelezo user igen. De mar nem, mert nincs, breakelted.

HTTP-n keresztul hasznalja minden mas user, ami tovabbra is megy. miert kell nyilvanvaloan hamis allitasokat tenni, nem ertem. az enemy territory szerver nem szamit hasznalatnak? amig volt hely, azaz jopar honapig, addig ott lakott, nem?

( Csigaa | 2007. 06. 17., v – 12:39 )

A "néhány FPS" hacsak nem valami quakemotorra gányolt 0.001alpha opensource, akkor i386 marad, mert így adják ki gyárilag (hogy lehetőleg minden disztroval kompatibilis maradjon)

( lacika v | 2007. 06. 17., v – 12:39 )

Ha van időd és türelmed, akkor ismerkedj meg a Gentoo -val. Én is most paszíroztam fel egy Core Duo -s laptopra és jóval fürgébb a rendszer. Stabilitásából nem vesztett a Debianhoz képest. Jól dokuentált disztribúció.
Ha meg belőttél egy működő rendszert, bootolj be a Live CD -jével és készíts egy "file system snapshootot", azaz, csatold fel a partíciókat pl. a /mnt alá és szépen tar & bzip2 párossal mentsd le. Ha összeomlik a rendszer, akkor Live CD beboot, partíció formáz, felcsatol és a tar.bz2 -ből visszaállít. Ez így elég gyors eljárás.

___________________________________________________________________
Lógnak a pálmafán a kókuszok .... :)
http://laszlo.co.hu/

De csak ha sok időd van. :)

Gentoo nagyon jól dokumentált, mind a hivatalos doksi, mind a wiki nagyon részletes, én a legkisebb hülye problémára is találtam megoldást.

Viszont jóval lassabb fordítani egy programot, mint .deb-ből telepíteni, és elég gyakran kell reszelgetni is (ha új dolgot telepítesz).

Cserébe gyors, és rengeteget tanulsz. Ha kicsit is érdekel a Linux és/vagy szereted az érzést, hogy te csináltál meg valamit, akkor szeretni fogod a Gentoo-t.
Ha csak azt akarod, hogy minden pöccre működjön, akkor valószínűleg nem.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Az elejen biztos reszelgetni kell meg rendesen, amig az ember kiismeri a lelkivilagat. Azonban ha esszel es odafigyelessel nyulsz a rendszerhez, akkor nem igen kell reszelgetni. Na meg nem kell verzioszam fuggonek lenned, igy ha "csak" a biztonsagi javitasokat rakod fel nagyokat nem szivhatsz vele (altalaban, de volt kivetel).
___________________________________________________________________
Lógnak a pálmafán a kókuszok .... :)
http://laszlo.co.hu/

Az első fele ++;
A Gentoo tényleg gyors. Van benne lehetőség prelink-re, amivel az alkalmazások indítási ideje csökken, illetve a lehető legtöbbet hozza ki a vasadból. Nem csak a CFLAGS/CXXFLAGS miatt, hanem az USE flagek is dobnak a sebességen (nem tölt be az alkalmazás feleslegesen olyan dolgokat, amiket sohasem használsz).
Vélemény a CFLAGS-ról: átlagban néhány százalékot nyersz vele, de vannak bizonyos alkalmazások (pl. amíg normális fejlesztőgárda volt az mplayer mögött, addig az is oda tartozott), amiknél durva a különbség. A KDE is gyors (-fvisibility-inlines-hidden megdobja a sebességét), gyorsabb, mint Debian alatt; főleg a betöltődésnél érezhető (még prelink nélkül is). A nem grafikus és nem KDE alkalmazások esetén elenyésző a sebességnövekedés. A matematikai programok is gyorsabbak (ha sse-vel számoltatod, és nem 387-tel).
Tény az is, hogy egy normális CFLAGS-ot beállítani, ami az egész rendszeren globálisan jó (tehát stabil marad, de ahhoz mérten mindenből kihozza, amit lehet), inkább már az életmű kategóriába tartozik. Az is tény, hogy hiába jó a GCC, meg optimalizál, ha rossz az algoritmus, akkor nem ér sokat.

---------
WARNING: Linux requires you to type! After rebooted to Windows, you can safely unplug your keyboard.
szerény blogom -- új címen!

( lacika v | 2007. 06. 17., v – 13:00 )

Régen egy unixbench programot használtam a hardver tesztelésére. Kicsit régi, de lehet hogy még érdemes megnézned. Egy jó benchmarkra én is "vevő" lennék.

___________________________________________________________________
Lógnak a pálmafán a kókuszok .... :)
http://laszlo.co.hu/

( asch v | 2007. 06. 17., v – 14:50 )

nem hinném, hogy böngészéshez számít, hogy mire van optimalizálva a kód. Az a tapasztalatom, hogy a memória mennyisége az egyik legmeghatározóbb a felhasználói élmény kapcsán.
Egy 800MHz-s ma már őskövület gépen is jól lehet netezni, ha van benne memória mondjuk 1G már általában untig elég.
A szimulációknál pedig elég magát a szimulációt végző kódot optimalizálni, azt a kerneltől meg egyéb oprendszer komponensektől fügetlenül is lehet (meg gondolom szokták is).
Szóval szerintem ne törődj ezzel a kérdéssel, felesleges. Persze ha direkt érdekel a téma az más. Akkor viszont csinálj méréseket és oszdd meg velünk is ;-).

( gaborgabor | 2007. 06. 17., v – 15:27 )

ubuntu. ha kde-t akarsz, akkor kubuntu. pont.

Én is ezen az állásponton vagyok. Kubuntu Feisty enyhén szólva nem győzött meg stabilitás (bug-mentesség) tekintetében.
Kérdeztem már másik topicban, h Kubuntu (avagy kubuntu-desktop) helyett alternate install + kde-core telepítés esetén stabilabb kde-t kapok-e. Valaki ott épp kipróbálta, de azt mondta így is voltak problémái. Neked?

En voltam az aki kiprobalta ... sot most is kde-core van az ubuntumon. A kopetevel voltak problemak de azt meg gnome alatt telepitettem es ott sem ment rendesen (kde crash gnome alatt - eleg vicces ) na de miota leszedtem az svn kopete-t es leforditottam tokeletes. Azota hozzaraktam koffice-t amarok ot superkaramba-t. Hurboltem a gepem rendesen egy hibas hdd-n (ki kene mar csereljem) es 2 nap alatt egy error sem volt -ami a kde-t illeti -. Meg vagyok vele elegedve. Sot sokkal gyorsabb mint a kubuntu desktop. (firefoxal is 144 mega ram indulaskor 1 karamba theme vel). Ami tetszett hogy azt pakoltam bele ami nekem kellett. mondhatom most mar keszen is van (ma forditottam rajta pidgin-t es azt hiszem tobb mindent nem fogok bele rakni). Ugy erzem unalmas lessz othon hogy nem lessz mivel foglalkozzak a gepen. Hogy egyertelmu legyek ... ajanlom mindenkinek az ubuntu + kde-core install-t. Gondolkoztam azon is hogy ubuntu server + kde-core. szerintem akarmeik megoldas jo es igy sem downloadoltam tobbet mint egy cd (amiben benne vannak az update csomagok + gnome csomagok + kde csomagok + automatix csomagok - vagyis a /var/cahche/apt/archives merete) Nem szamoltam de kb 150 - 200 mega download volt igy belove a kde-core.

--
The worst or stupidest ideas are always the most popular.

( cornail | 2007. 06. 17., v – 19:29 )

Egyébként ubuntu mire optimalizál?
Mert distrowatch-on ugyanúgy i386 van, mint debian-nál. (Ez debian-os felfogásban mostanában (sarge óta) 486-os prockóra való optimalizációt jelent).

https://answers.launchpad.net/ubuntu/+question/6804

Azt mondja, h a kernel + több komponensből van úgyis i686-os, az egyéb csomagoknál meg nem lassabb észrevehetően pl full i686-ra optimalizált Gentoo-nál (persze megint nuku benchmark).

Debianra ugyanígy van i686-os kernel, stb. Ezek szerint, ha kigyepálok mindenféle szerver funkciót a Debianból, kb ugyanott tartok "fürgeségben", mint Ubuntuval? Erről mi a tapasztalat?

(Sajnos tesztelni nem tok ilyen tekintetben mostanság, mert az alkalmas laptopom épp a szervízben henyél)

szerintem, a rendszer az repobol (akarhogyan "optimalizalva"), amivel szamolsz (mar amennyire hasznalsz kulso libe-eket), azt helyben forgatva!

Monny'uk - legalabbis monte-carlonal - szoktak mondani, hogy az eredmeny gyengen architekturafuggo ...
En ennek meg soha nem neztem utana, de ha erdekel, akkor irjal batran a BABAR kiserlet barmely szamitogepes-mokusanak (ok hiresztelik ...)
... szoval ezzel is erdemes ovatosnak lenni, de numerikus csomagoknal szerintem nem nagyon szok lenni porblema ... (ha van, az gaz ...)

k.

benchmark: http://lbs.sourceforge.net/

"kigyepálok mindenféle szerver funkciót"

Inkább szerverfunkciók nélkül telepítsd.

Lényeges gyorsaságkülönbség Ubuntu és Debian között nincs, érzésre szerintem a Debian kicsit gyorsabb. Viszont ha tényleg gyors disztrót akarsz, akkor szerintem Slackware háza táján nézz körül. Lassan öt éve használok Slacky-t a desktop/tároló gépemen ,a core duos laptopomon (ezen) tesztelési okokból egy hekkelt Etch van, de szervíz előtt slacky 11 volt és több tizedmásodperccel gyorsabb volt rajta, illetve a Zenwalk még KDE-vel is verte a debian gnome-ját, pedig az etch nagyon sokat javult a sarge-hoz képest gyorsaságban is. Ilyen szempontból a Vectort érdemes lenne még megnézned, mert az is elég gyors.

Persze a repositorys elvárásodnak a Slacky egymagában nem felel meg, ahhoz pkgsrc-t kell beheggeszteni. Viszont a Zen és a Vector egészen tűrhető repoval bír, ráadásul ezek 3an 80%-ban csomagkompatibilisek egymással.

Ami garantált, hogy egy-egy security-fix (csomagupdate) után tuti nem száll el egyik sem, bár ezt az Etch sem teszi, ilyesmi csak a testingnél és az unstable-nél fenyeget.

Gentoo-hoz pedig: Don't fix something that's not broken, akkor ott sem lehet baj.

UI.:Optimalizálási szempontból pedig érdemes megtanulnod kernelt forgatni a gépedre, ha felmerül benned a tettvágy, akkor privátban megkereshetsz, és segítek, ha kell.

___________________________________________________
Debian 4.0 - linux-2.6.21.1-cfs-v15-smp - KDE 3.5.7

Kösz, lehet még keresni foglak ez ügyben privátban :)
Debian Testing-nél is fenyeget a breakage (h ilyen magyaros legyek :$)? (Vannak tapasztalataid erről?) Mert elvben az írják, h a testinget igyekszenek konzisztensen tartani (egy éve nyomtam akkor még testing etch-et egy régi laptopon pár hónapig, azalatt nem volt gond). A repok viszonylagos frissessége miatt szemezgetek a lenny-vel...

Kb háromnegyed éve használok etchet, és nem volt vele baj testing korában sem, csak azért írtam, hogy fenyeget, mert ott nincs kizárva egy-egy csúnya libraty-brakeage, ami viszont etch-nél egyenesen lehetetlen.

Anno, mikor sarge még testing volt, azt is kipróbáltam, és kb a második héten egy frissítés után elszállt valami library-hell-el, bár az is benne van, hogy akkor még tapasztalatlanabb voltam.

A lennyből csak a 3.5.7-es kde-t vettem átt a minap, ami ~300 lib frissítését és ~10 új lib telepítését eredményezte, és meglepő módon semmi probléma nem lépett fel sem előtte, sem utána, szóval látszik, hogy dolgoztak rajta a debiannál.

A lenny tényleg vonzó a naprakész repo miatt, viszont ez a stabilitás rovására megy (értsd: kicsit bugos). De ott is az a helyzet, mint a Gentoo-nál, ha nem romlott el, ne javítsd, szóval ésszel kell frissíteni, akkor meghálálja.

Sajnos amennyire sokat fejlődött a Debian, annyira meghízott, és számomra felettébb idegesítő, hogy minden ezer+1 libre van szétvagdosva, csak azért, hogy azt mondhassák, hogy nekik van a legtöbb csomagjuk a repoban (vagy nem azért, de akkor meg semmi értelme), ezen kívül slacky-hez képest nagyon lassú, és ez egyre jobban zavar.

Szóval vizsgaidőszak után valószínűleg valamikor megválok tőle a Slackware 12-ért cserébe.

üdv.
___________________________________________________
Debian 4.0 - linux-2.6.21.5-smp - KDE 3.5.7

minden ezer+1 libre van szétvagdosva, csak azért, hogy azt mondhassák, hogy nekik van a legtöbb csomagjuk a repoban (vagy nem azért, de akkor meg semmi értelme)
Nem azért van és van értelme.

Pl. a foo csomagot lehet MySQL támogatással fordítani. Ha anélkül fordítanák és neked kell a MySQL támogatás, akkor magadnak kellene fordítanod. igy meg ahogy van, ha nem lenne feldarabolva, akkor fel kellene tenned a komplett MySQL szervert, amikor elég libmysqlclient0 is. Tehát nem kell annyi szemetet felpakolnod, meg nem is kell magadnak fordítani.

( gsimon | 2007. 06. 18., h – 09:05 )

Ahogy eddig tapasztaltam, számottevő gyorsulást nem érdemes a kód-optimalizálástól várni, egyrészt azért, mert ez eleve csak konstans szorzó erejéig gyorsíthatja a műveleteket, másrészt meg a gcc-től (igaz, ez még a 2.95 környékén volt) láttam már -O3 mellett is olyan kódgenerálást, hogy ha azt embertől látom assembly feladat megoldásaként, akkor visszaadom átdolgozásra :(.
Igazság szerint a kutya amúgy ott van elásva, hogy mostanság nem engedheti meg magának az ember, hogy normálisan, mindent végiggondolva programozzon, csak arra van idő, hogy az előregyártott panelekből (glib, stl és társaik) összemókoljon valamit (mint az óvodás a legóból), ami többé-kevésbé azt csinálja, ami a feladat szerint szükséges. Köszönhető ez egyrészt annak, hogy az egyedi megoldásokat a fejlesztőjükön kívül más elég nehezen veszi át, tartja karban, illetve a munka megkezdésekor messze nincs letisztázva maga a feladat sem, így az adatszerkezet óhatatlanul is trehány lesz, fölösleges rátartásokkal és rosszul megválasztott megoldásokkal teli, aztán mire kiderül, hogy merre is van arccal előre, addigra már késő elgondolkozni, mert több heti/hónapi fejlesztést már senki sem fog újraíratni csak azért, hogy szebb és jobb legyen, ha a már meglévő gány is fut, mondván "majd vesz alá nagyobb vasat a luser".
Tehát amíg a jelen technológia végképp be nem fullad valahol az ötezer Kvikvalatin magos, 123 hablahertzes ADSFBus architektúrájú, hélium-II hűtésű wintel prociknál (amik még mindig a 8086-kompatibilis szegmens-offszet módban bootolnak...), addig az egy példányban futó célprogramok íróin kívül senki sem fog rendes programokat írni.
Nagyon nem tetszik ez az egész, de addig kár a gőzért, sík fölösleges vadászni a ciklusokat, amíg egy nyamvadt könyvtári függvény meghívásakor huszonhétszer fut le egy string copy-konstruktora, pufferből-pufferen át-pufferbe másolgatva az adatot, elzabálva a procit a tényleges munka elől.

Ui.: igen, útálom a hétfőt :).

Egyetértek!

Iszonyú ez a kódgyártás, ami a tényleges vastól egyre messzebb található rétegeken történik.

Érdemes lenne megnézni, hogy egy szép hízott java alkalmazás szerveren ha meg akarsz nyitni egy text fájlt, mi minden történik, mire az első karaktert megkapod.

Sajnos bármennyire tudjuk, hogy milyen szemét az eredmény, az idő szorítása, és a termelékenység hajszolása közben muszáj paneleket és absztrakciós rétegeket használni.

OFF: Innen akaratlanul is eszembe jutott, h a hardver-világban is mintha egyre nagyobb lenne a gányolás... A '98-as Toshiba Satellite notebookomban 7 évig jó volt a cd-rom (TEAC), pedig időnként nyúztam rendesen (iszonyú karcos lemez másfél napig tartó grabbelése, miközben fel-le pörgette a motort feszt... hát igen, nem voltam teljesen normális...), ezt kicseréltem tavaly és azóta is vígan szaladgál a maga kis öreges tempójában. A tavaly beszerzett Tecrámnak a dvd-írója 3/4 év alatt beadta a kulcsot (Matshita), pedig hetente ha 1x írtam vele egy dvd-t... Persze ez lehet szerencsétlen véletlen is, de előtte randiztam egy Asus A6Tc-vel, na annak a példánynak is egy hulladék volt a TSST dvd-rw-je, meg a wifi-je is...

Szubjektív... Eddig csak debian alapú disztrókkal randiztam (hipnotizált a spirál), slackware-alapúval nem. Még szubjektívabb: vhogy a nagyobb disztribúciókban jobban bízom, több ember, kisebb az esélye, h ha vki kulcsember(ek) dobbant(anak), elhasal az egész projekt... Persze ezzel is lehet vitatkozni... (most ilyen filozófiai kérdéseken viszont inkább ne vitatkozzunk :) )

A slackware alap a frugalware -ra mostanaban nem nagyon igaz mar.

Amugy nem vitazok, de pl egy nagyobb team/distro eseteben 1000x nagyobb az eselye annak hogy pl egy adott bugreportodat magasrol szarjak le, vagy valami keresedet. Kisebb team eseteben viszont lehet hogy hamarabb kapsz valaszt / segitseget, stb. Bar ez team fuggo dolog, de altalaban frugalware develek segitokeszek a usereknel + figyelnek a visszajelzesekre es a requestekre. Olyan csaladias! :D (hahah)

Ja, nem flame :)

Udv
-krix-

annak is nagyobb az eselye, hogy elbreakelnek valamit, mert keves az olyan ember, aki atlatja az egeszet

es egy kissebb, de elkotelezett es hozzaerto csapat igenis (de persze nem feltetlenul) tud nagyon komoly produktiv munkat vegezni. lasd az openbsd, hogyan ontja a drivereket, ahhoz kepest, hogy nem egy tomeghiszteria a project

--
Those who do not understand Unix are condemned to reinvent it, poorly

( Coornail | 2007. 06. 19., k – 00:37 )

[off]Nemtudom megkaptad-e a levelem amit kuldtem. Leirtam benne hogy szeretnem ha nevet valtoztatnal, elvegre egy forumon ez eleg zazvaro.[/off]

( flimo | 2007. 06. 19., k – 07:48 )

Én is fizikushallgató vagyok, és abszolút kezdőként sikerült feltenni a Gentoot, egy próbát megér.

( hud | 2007. 06. 19., k – 09:06 )

Debian lenny-t használok fluxbox-szal, és kerülöm a kde-s programokat (így marad a Gaim, gnome-commander). 4 éves laptop, és egész gyors a rendszer.

Kérdés (talán kicsit témába vág, bár nem disztroválasztás): a gépembe 512 MB ram van. Kikapcsoljam-e a swap-et? Néha ír rá pár megát, amit utána vissza is kell olvasnia. Jóideje kikapcsolva használom, de gyorsabb így? Sose telik meg a memória, most 118 MB-ot használ (plusz gyorsítótár).

Kikapcsolhatod, ha nem telik meg.

/etc/sysctl.conf
vm.swappiness=

cat /proc/sys/vm/swappiness
echo 10 >/proc/sys/vm/swappiness
Ezt az értéket állíthatod, nagyobb értéknél intenzívebben használja a swappet. 0-100 között vehet fel értéket. (Én többnyire a magas értéket szoktam javasolni, de te, ha jól értem alacsonyabb értéket szeretnél)

Kikapcsolás hátránya lehet, hogy olyan dolgok sem lapozodnak ki amit gyakorlatilag nem használ a rendszer, így a helyébe nem kerül gyorsító tár.

Kösz, kipróbáltam swappiness=10-zel. Normál felhasználás alatt hozzá sem nyúl a swaphez, ha meg mégis, akkor ott van.

Viszont lehet, hogy visszatérek a letiltáshoz. Régi noti, lassú winyó. Ha elszáll egy progi, és végtelen sok memóriát akar lefoglalni (néha előfordul), akkor áttér swapre, és több perc, mire kilövöm.

( emberk | 2007. 06. 20., sze – 09:30 )

Ha Debreceni vagy szívesen segítek. Én is fizikus vagyok csak már végeztem. Ugyanezt nyomtam végig én is nekem gentoom-lett hosszas küzdelem után (volt olyan programom ami 6 napig futott szóval egyáltalán nem volt miondegy az az 5-10% sebeségnövekledés mert az -1 nap az összes melóban.) utána volt slamd64-em is, de nekem az nagyon bugos volt. Írj mailt ha érdekel az emberk#KUKUC#tvnetwork#PÖTTY#hu-ra,