Scythe:
„/bin/sleep 6m
/sbin/reboot”
idoztett leallitasra kicsit elegansabb a ‘shutdown’ hasznalata, lasd man;

„ami ujrainditja a gépet ott messze, ha nem áll fel a háló és nincs netkapcsolat (a hálókarival szoktak gondok adódni néha, ilyenkor meg pláne ki tudja…).”
van egy ronda scriptem adott netkapcsolat bevarasara, kicsit modositva jo lesz erre a celra;
30mpig probalgatja a ppp0 kapcsolatot jelenleg:

—Laszlo—:
„Lesz rá esély hogy valaha normális lesz ,vagy csak igérgetnek ?”
http://bhhdoa.org.au/pipermail/ck/2004-December/001936.html

„
> But if it’s the linking, GCC 4 will help quite a bit, I guess. But also
> KDE-init should solve the problem, and Konsole still starts slow, so we’re
> not there, yet…

Yep; as I said… gcc 36.0, glibc 12.0 and kde 6.0 should be fine.
„

ariszlo:
„Az i386-ra „optimalizált” (én úgy mondanám: pesszimalizált) disztrókkal én sem vagyok kibékülve.”
helyes, mivel gcc 3.2 ota nincs 386 support, ezert sid alatt mindenkepp nagyreszt 486ra optimalizalt csomik vannak 😉
a hivatalos kernel-image csomagok resze volt emiatt egy ideig egy 486emu patch, de nemreg dobtak, mert bugos volt;

xcut:
„vagy egy forrásalapú disztró is megoldás lehet…”
http://www.hup.hu/wiki/wiki.phtml?title=De…%C3%A1sb%C3%B3l
(az, hogy a csomagkeszitok elszurjak rulest nem a disztro hibaja; tulajdonkepp konnyen meghekkelheto lenne az apt, hogy ki#elodjenek a CFLAGS/CXXFLAGS reszek; ha 0nal (nulla, zero, stb) tobb erdeklodest mutatnek a temaban, akkor megcsinalnam; openbox, vim, snackamp, stb rulez)

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

jo, kezd alakulni;
legfeljebb elsore egy kisebb dolog lesz, mert en se csinaltam kulsosokkel (haverokat korbenoszogatni mas); persze aki nagyobb tapasztalattal rendelkezik es elvalana nyugdotan jelezzen 😉

akkor bp adott (sejtettem, de jobb megkerdezni), a helyen meg gondolkozzunk; olyan kene, ahol van vmi zene, meg azert lehet dumalni, es nem csillagaszati arak vannak;

ha killall nem jon, akkor meg nem lesz semmi;
ugyanez vonatkozik a tobbi „foemberre”; 1db nap az egesz honapbol, csak akarni kell;

gabaman jobban tudja, hogy mire lenne szukseg, ezert privi megy a fentebb emlitetteknek;

//off
azert publik is kiteszem:

hi!
a leendo lfhu wikivel foglalkozo topicban eddig ti jeleztetek, hogy vmilyen formaban tudtok segiteni a tema elomozditasaban;
ezuton kerunk mindenkit, hogy nezzen be a topicba / erdeklodjon gabamannal, hogy mik az aktualis feladatok es ha barmelyikben barmilyen segitseget tud nyujtani jelezzen vissza ott: http://www.linuxforum.hu/ipbmb/index.php?showtopic=11214
elore is kosz mindenkinek es ne feledjetek: keves embernek ez hatalmas munka lenne, de ha osszefogunk egy „netrengeto” dolgot fogunk osszehozni;
udv fellow