Hétvégi linuxfelhasználó vagyok, ne húzzátok fel magatokat.
Nem vagyok kibékülve azzal amennyi idõ alatt a linux elindít egy (akármelyik) alkalmazást.
Több féle kaliberû gépen hasonlítottam össze a programok indulási idejét és az a személyes tapasztalatom, hogy linux alatt akár a win98-hoz képest is észrevehetõen lassan indulnak a programok. /vagy csak én vagyok a béna.
Túl sok idõ még egy 2,4 ghz-s laptopon is amíg a konqueror, kmail stb elindul, hogy a mozilláról, thunderbidrõl ne is beszéljek.
A munkahelyemen egy 600 mhz-s gépre raktam slackware 10-et hallván, hogy csucsszupergyors. Valóban gyorsan feláll a rendszer, gyorsan gurulnak elõ a menük. De amíg egy program bejön….
Nem akartam senkit/semmit bántani csak abban reménykedem , hogy valaki majd elmondja hogy én voltam a béna, és hogy hogyan kell ezt kezelni.
[align=right][snapback]105820[/snapback][/align]

M$-ben van egyféle környezet és azt betölti az elején. Onnantól pedig már nem kell betölteni. Itt van egy valag környezet amit ha mást használsz mindig tölteni kell. Pl én gnome-ot használok ,de ha valamelyik kde-s okosságot töltöm be akkor még a kde-nek a környezetét is tölteni kell. Ami idõ és plusz egy valag memória. Egyébként tényleg lassabban töltödnek a programok mint m$ alatt.

hasznalj mas alternativakat.
kde helyet: xfce, *box (open, flux, black), enlightenment, icewm, windowmaker
kmail helyett: evolution, sylpheed
konqueror helyett: firefox vagy opera

ha ezekhez tartod magad, akkor joval gyorsabb lesz minden. torekedj arra, hogy k* cuccokat _ne_ hasznalj, helyette inkabb gtk-s dolgokat.
[align=right][snapback]105829[/snapback][/align]

Hát ilen gmplayer, xchat, xmms.. – hát ezeket gtk torzszüleménynek tudom csak becézni.

Alan_Breck:
„Hétvégi linuxfelhasználó vagyok, ne húzzátok fel magatokat.
Nem vagyok kibékülve azzal amennyi idõ alatt a linux elindít egy (akármelyik) alkalmazást.
Több féle kaliberû gépen hasonlítottam össze a programok indulási idejét és az a személyes tapasztalatom, hogy linux alatt akár a win98-hoz képest is észrevehetõen lassan indulnak a programok. /vagy csak én vagyok a béna.
Túl sok idõ még egy 2,4 ghz-s laptopon is amíg a konqueror, kmail stb elindul, hogy a mozilláról, thunderbidrõl ne is beszéljek.
A munkahelyemen egy 600 mhz-s gépre raktam slackware 10-et hallván, hogy csucsszupergyors. Valóban gyorsan feláll a rendszer, gyorsan gurulnak elõ a menük. De amíg egy program bejön….
Nem akartam senkit/semmit bántani csak abban reménykedem , hogy valaki majd elmondja hogy én voltam a béna, és hogy hogyan kell ezt kezelni.”
errol nemreg volt egy hosszu es erdekes thread a -ck levlistan (http://bhhdoa.org.au/mailman/listinfo/ck – december, „2.6.7 backport request”, „static firefox” es „optimalization during idle” nagyreszt);
roviden es velosen arrol van szo, hogy jelenleg linux alatt a dinamikus linkeles megoldasa finoman szolva hagy maga utan kivanni valot; konkretan mindig ujra megkeresi a memoriaban libraryk helyet es linkeles elott vegigszalad az osszes exportalando szimbolumon; es ez sok idot emeszt fel; nos, ez a resz windows alatt kicsit jobban van megoldva, ezert indulnak gyorsabban a progik;
megoldasok:
1. vim, links, mutt, … – magarul minel kisebb eroforrasigenyu progik – 😉
2. tisztan statikus programok… – erteo modon a dinamikus linkels hibait mellozik cserebe tobb helyet es memoriat foglalanak – minden fontos library valtaskor mindent ujra kell forditani;
3. prelink – elore meghatarozott helyen legynek a libraryk betoltve, igy nem kell kersgelni – ez csalas es kulonben sem kompatibilis a paxszal;
4. preload – rendszerinditas elejen mar betoltodjon minden nepszeru library – erre mondjak, hogy „ugly hack”;
5. a 4-es gccben lesz mar lehetoseg az exportalando szimbolumok korenek szukitesere, ami jelentos javulast fog hozni; majd, egyszer; 2005 nyarara igerik;

http://gcc.gnu.org/gcc-4.0/changes.html:

The -fvisibility option has been added which allows the default ELF visibility of all symbols to be set per compilation and the new #pragma GCC visibility preprocessor command allows the setting of default ELF visibility for a region of code. Using -fvisibility=hidden especially in combination with the new -fvisibility-inlines-hidden can yield substantial improvements in output binary quality including avoiding PLT indirection overheads, reduction of the exported symbol count by up to 60% (with resultant improvements to link and load times), better scope for the optimizer to improve code and up to a 20% reduction in binary size. Using these options correctly yields a binary with a similar symbol count to a Windows DLL.
Perhaps more importantly, this new feature finally allows (with careful planning) complete avoidance of symbol clashes when manually loading shared objects with RTLD_GLOBAL, thus finally solving problems many projects such as python were forced to use RTLD_LOCAL for (with its resulting issues for C++ correctness). You can find more information about using these options at http://www.nedprod.com/programs/gccvisibility.html

Nálam is lassabban indulnak, egészen kicsivel csak, de jóval gyorsabban futnak.

vagy egy forrásalapú disztró is megoldás lehet…