Hozzászólások
[quote:e24614f540="pozsy"][quote:e24614f540="Beanie"]Kerneld annak a daemonnak a neve, ami szükség esetén betöltögeti a modulokat, én sokat nem foglalkoztam ezzel a témával, nézd meg a doksiját, hátha találsz valami hasznosat hozzá.
Ez nem igaz, siman a kernel hoz letre egy uj processzt, nem valami kerneld.
Bazz, nem azt mondtam, hogy új processzt hoz létre, hanem, hogy az egy olyan daemon, ami betölti a modulokat a modprobe/insmod parancsokkal, ahogyan Te tennéd, ha a daemon úgy találja, hogy szükséges lehet. Olvasd már el legalább figyelmesen, amit leírtam, meg keressél már rá a google-n mielőtt beszólsz. Küldjek neked kerneld howtot bazzeg? Itt van kinyomtatva.
- A hozzászóláshoz be kell jelentkezni
[quote:73555dd9e5="Beanie"]Küldjek neked kerneld howtot bazzeg? Itt van kinyomtatva.
de a 2.2.x szeria ota jott am ki meg linux
- A hozzászóláshoz be kell jelentkezni
mea culpa! az a cache dolog tényleg nagyon gáz volt, de a megszakításról szólva én nagyon erre emlékszem, de majd utánna nézek ( ismét ).
Egyébként most már azért is megcsinálom. Azóta megtudtam, hogy az rmmod-al kell kihajingálni ami nem kell. Majd megírom a scriptet aztán meglátjuk. Ha nem lesz gyorsabb akkor ez van. :)
- A hozzászóláshoz be kell jelentkezni
[quote:ce1f239e31="Beanie"][quote:ce1f239e31="pozsy"][quote:ce1f239e31="Beanie"]Kerneld annak a daemonnak a neve, ami szükség esetén betöltögeti a modulokat, én sokat nem foglalkoztam ezzel a témával, nézd meg a doksiját, hátha találsz valami hasznosat hozzá.
Ez nem igaz, siman a kernel hoz letre egy uj processzt, nem valami kerneld.
Bazz, nem azt mondtam, hogy új processzt hoz létre, hanem, hogy az egy olyan daemon, ami betölti a modulokat a modprobe/insmod parancsokkal, ahogyan Te tennéd, ha a daemon úgy találja, hogy szükséges lehet. Olvasd már el legalább figyelmesen, amit leírtam, meg keressél már rá a google-n mielőtt beszólsz. Küldjek neked kerneld howtot bazzeg? Itt van kinyomtatva.
Lassitsal, mert kisodrodsz a kanyarban. Tudom hogy mit mondtal, es nincs igazad.
Nezegesd ezt a filet kicsit: http://lxr.linux.no/source/kernel/kmod.c
Azt a doksit pedig add le valamelyik muzeumban, a 2.2-es kernelre mar nem ervenyes.
- A hozzászóláshoz be kell jelentkezni
[quote:6ce71a9e9a="snq-"][quote:6ce71a9e9a="Beanie"]Küldjek neked kerneld howtot bazzeg? Itt van kinyomtatva.
de a 2.2.x szeria ota jott am ki meg linux
Én úgy emlékeztem, hogy a 2.4-hez is volt, de lehet rosszul tudom, csak egy tanácsnak szántam, és nem is azért lettem ideges, mert vki mást mondott, hanem a stílus miatt. Aszondja "nem vmi kerneld", ebből látszik, hogy nem is hallott róla, rohadtul utána sem nézett, asse tudja mi az, de azért leugat.
- A hozzászóláshoz be kell jelentkezni
[quote:8ef72861b2="Beanie"]Én úgy emlékeztem, hogy a 2.4-hez is volt, de lehet rosszul tudom, csak egy tanácsnak szántam, és nem is azért lettem ideges, mert vki mást mondott, hanem a stílus miatt. Aszondja "nem vmi kerneld", ebből látszik, hogy nem is hallott róla, rohadtul utána sem nézett, asse tudja mi az, de azért leugat.
1. hulyeseget mondtal
2. a "nem vmi kerneld" alatt az ertendo, hogy se nem a kerneld, se semmilyen hasonlo daemonrol nincs szo.
3. Tudom mirol szo, az viszont mar vilagos hogy neked sajnos otleted sincs a modulbetoltodes mukodeserol. Inkabb ne probalj meg segiteni, mert csak artasz.
- A hozzászóláshoz be kell jelentkezni
[quote:8f91531eca="BikMak"]Egyébként most már azért is megcsinálom. Azóta megtudtam, hogy az rmmod-al kell kihajingálni ami nem kell. Majd megírom a scriptet aztán meglátjuk. Ha nem lesz gyorsabb akkor ez van. :)
Attol fuggetlenul, hogy ertelmetlennek tartom eme idotoltesedet, azt tudom mondani, hogy csinald! VISZONT: ha levonsz kovetkeztetest barmilyen sebessegvaltoztatast illetoen, azt ne ugy tedd, hogy "mintha gyorsabb lenne", hanem valami _preciz_, _pontosan merheto_ adatokra tamaszkodva.
- A hozzászóláshoz be kell jelentkezni
[quote:e36d608f8f="pozsy"][quote:e36d608f8f="_Polesz_"]Az UHU-t úgy rakják össze, hogy a lehető legjobb legyen, tehát te mint egyszerű földi júzer ne túrkáld a rendszert. Ha komoly kihívásra vágysz akkor debian, slack és a minimalista disztribek ezreiben lehet turkálni :)
Ha mégis UHU-t akarsz heggeszteni akkor jó ha felkészülsz akár egy újratelepítésre is, de sok hasznosat tanulhatsz is belőle.
Hajrá UHU, Linux és minden disztrib. Előre az ismeretlenbe és tovább :)
Az uhu semmivel sem piszkalhato kevesbe mint mas rendszerek.
Hidd el, hogy de! Ezért nem is UHU-zok, mert nincs meg a kihívás annyira jól össze van rakva az egész. Pont ez nem tetszett amúgy a debian-ban sem ;)
- A hozzászóláshoz be kell jelentkezni
[quote:dd4212d2cf="pozsy"][quote:dd4212d2cf="BikMak"]Egyébként most már azért is megcsinálom. Azóta megtudtam, hogy az rmmod-al kell kihajingálni ami nem kell. Majd megírom a scriptet aztán meglátjuk. Ha nem lesz gyorsabb akkor ez van. :)
Attol fuggetlenul, hogy ertelmetlennek tartom eme idotoltesedet, azt tudom mondani, hogy csinald! VISZONT: ha levonsz kovetkeztetest barmilyen sebessegvaltoztatast illetoen, azt ne ugy tedd, hogy "mintha gyorsabb lenne", hanem valami _preciz_, _pontosan merheto_ adatokra tamaszkodva.
Jah és értesítse az UHU fejlesztőket akik ezek után a kardjukba dőlnek :lol: bocs no flame :)
- A hozzászóláshoz be kell jelentkezni
Imho bugos driver okozhat eleg komoly lassulast, (pl a a csodalatos forcedeth) persze nem az swraid modulok fognak ilyet csinalni. Es mivel meg mindig jobb a bugos drivert hasznalni mint semmit, ezert sok valasztasi lehetoseg nincs :wink:
Valahol 2.6.7 kornyeken nekem freq scaling-al volt nyugom amitol teljesen csigasebessegure csokkent a laptopom, szoval nem feltetlenul kell leharapni a fejet ha esetleg ebben az iranyban keresgel.
- A hozzászóláshoz be kell jelentkezni
[quote:88fefc7acb="_Polesz_"][quote:88fefc7acb="pozsy"]Az uhu semmivel sem piszkalhato kevesbe mint mas rendszerek.
Hidd el, hogy de! Ezért nem is UHU-zok, mert nincs meg a kihívás annyira jól össze van rakva az egész. Pont ez nem tetszett amúgy a debian-ban sem ;)
Ettol "piszkalhato", azaz allitgathatsz benne ugyanugy barmit. Csak legfeljebb nem piszkalando, mert nincs miert, ennek orulok. Ezek szerint sok szabadidod lehet, hogy csak azert raksz fel egy masik rendszert mert az kevesbe van jol osszerakva :))
- A hozzászóláshoz be kell jelentkezni
P1 200mhz, 64MB RAM, 4.2GB HD
Nem egy mai gép, és csak egy hajszállal több, mint az UHU szükséges minimuma.
UHU 1.2 gdm-je alapból behúzza az uhulinux felhasználót egy blackbox alá.
Mindezt fergeteges gyorsasággal:
kb. ugyanolyan gyorsan, mint egy 3200+ -os athlonon a gnome alá.
Tanulság:
Ha spórolni akarsz az erőforrásokkal, mert régi a gép desktopnak (másként nincs értelme a spórolásnak), akkor ne a modulokat ritkítsd, hanem a démonokat
- A hozzászóláshoz be kell jelentkezni
[quote:43224b82c8="pozsy"]
1. hulyeseget mondtal
2. a "nem vmi kerneld" alatt az ertendo, hogy se nem a kerneld, se semmilyen hasonlo daemonrol nincs szo.
3. Tudom mirol szo, az viszont mar vilagos hogy neked sajnos otleted sincs a modulbetoltodes mukodeserol. Inkabb ne probalj meg segiteni, mert csak artasz.
Bocs, igazad van. Mostanában FreeBSD-t használok, a mostani helyzetét a Linuxnak annyira nem követem figyelemmel. Azt hittem még mindig van kerneld, de attól még közölhetted volna ezt velem úgy is, hogy megértsem mire gondolsz, akkor nem értettem volna félre azt amit a második pontban írtál. Részemről sorry, nem akartam vitát.
- A hozzászóláshoz be kell jelentkezni
[quote:9c68713393="pozsy"]
Azok sw raidhez valo modulok, de egyebkent tenyleg nem okoznak lassulast vagy ilyesmit.
Nem kozolte mien raidhez valok. Es raid modulnak hivhatja a adaptek raid scsi kartya moduljait is, vagy esetleg az alaplapjara raintegralt hpt372 moduljait is.
Egyebkent a lassulas sok mindentol eredhet. Pl neked ujabb kde, mig amoda regebbi kde. Vagy te KDE o pl E17... ugyonazok a programok? vagy van valamikonkret meresi eredmenyed? Pl openoffice betoltodesi ido? pl debiannal lehet egy prelinkeles eredmenye hogy gyorsabban bejon, mig te pl nem prelinkeltel, es meg ezer meg 1 lehetoseg.
- A hozzászóláshoz be kell jelentkezni
Hello!
Kérem a nagyon hozzáértő embereket ,hogy ha nem jót mondok ne kottázzanak le nagyon . Ha modulokat akarsz kiszedni szerintem akkor jársz el a legegyszerűbben (szerintem ) ,ha az UHU vezérlő pultjában a kernel modulok fülre kattintasz és ott ami nem kell csak simán kikapcsolod .
A másik módszer ami talán még hatékonyabb . Meg nézed mik azok a modulok amik a hardverek miatt biztosan kellenek . Azokat megjegyzed és megpróbálsz egy kernelt fordítani amibe fikszen belerakod nem modulként. A feleslegeseket meg a kernel konfignál simán kikapcsolod ,hogy a fordiításnál sehol ne legyenek .
A kernel gonddal meg én is szívtam anno . Azt a kernel forrást amit az UHU lemezén vagy ftp-n megtalaltam nekem sem sikerült soha a büdös életbe lefordítani valamiért. Ezért én meguntam és első lépésként egy 2.6.9 vanilla kernellel pröbálkoztam és elsőre sikerült megcsinálni . Persze how-to leírásokra igen sokat támaszkodtam és volt egy lelkes linux használó is aki a menuconfigot magyarította. Ezért örök hálám neki . Mai napig ezt a kernelt használom minden gond és probléma nélkül .
Remélem sikerül megoldani a problémád .
Azért ide írom a konfigomat ,hogy lássa mindenki nincs lehetetlen .
Asus TX-97E ,AMDK6-300MMX 256MB RAM 3,2 és 60GB WDD
Nem egy rakéta ,de nem kell órákat ülnöm mondjuk két program megnyitása között.
Csá!
- A hozzászóláshoz be kell jelentkezni
Mi ez a prelink? Érdekelne, bővebb információ róla. A jövő hétig nem kerülök közelebbi kapcsolatba az otthoni gépemmel, úgyhogy addig csak elméletben foglalkoztat a dolog:)
A gnome-ot régebben megpróbáltam gyorsítani, de annyira el tudják dugni a beállításokat hogy az szörnyű. Az ötödik olvashatatlan XML lap után feladtam.
A kernel forgtást nem igazán értem, akkor miért forgatja mindenki újra a kernelét? Én úgy tudtam azért hogy gyorsabb legyen.
- A hozzászóláshoz be kell jelentkezni
[quote:cfd9622959="BikMak"]Hi!
Megnéztem hogy milyen modulok töltődnek be, és megállapítottam hogy a fele tök fölösleges. Az rc.boot-ban kiszedtem a modulok egy részét, de még így is maradt egy rakadt. Hol tudom azt beállítani hogy mely modulok NE töltődjenek be?
Milyen rendszer ???
Ha debian confmodules....
Szerintem meg te ne irj messengert
- A hozzászóláshoz be kell jelentkezni
[quote:a608d8b669="Czo"][quote:a608d8b669="pozsy"]
Azok sw raidhez valo modulok, de egyebkent tenyleg nem okoznak lassulast vagy ilyesmit.
Nem kozolte mien raidhez valok. Es raid modulnak hivhatja a adaptek raid scsi kartya moduljait is, vagy esetleg az alaplapjara raintegralt hpt372 moduljait is.
En ugy sejtem a raid0..raid10 nevu modulokrol van szo jelen esetben, amik az sw raidhez valok.
[quote:a608d8b669="Czo"]Egyebkent a lassulas sok mindentol eredhet. Pl neked ujabb kde, mig amoda regebbi kde. Vagy te KDE o pl E17... ugyonazok a programok? vagy van valamikonkret meresi eredmenyed? Pl openoffice betoltodesi ido? pl debiannal lehet egy prelinkeles eredmenye hogy gyorsabban bejon, mig te pl nem prelinkeltel, es meg ezer meg 1 lehetoseg.
Persze hogy tengersok lehetoseg van, azert is kerdeztem mar, hogy megis mire gondol pontosan.
- A hozzászóláshoz be kell jelentkezni
[quote:eb37eb318a="pozsy"]Sajnos rosszul alltal a kerdeshez, de legalabb kerdeztel :) A hatterben futo daemonok sincsenek hatassal a programokra, ugyanis ha azokat nem hasznalod, akkor NULLA processzoridot fogyasztanak.
De memoriat lehett sporolni melle a lattszolagos 0 processor ido se nulla ... soot... Szoval ha valami felesleges azt ki lehett szedni mert okozhatt szagatast belassulast ... Pl a debian cron alap cuccai viccessen meg tudjak porgetni a rendszert...
[quote:eb37eb318a="pozsy"]
A kernelforditas megrosszabb otlet, nem fogsz tudni kimutatni merheto kulonbseget, viszont sokat lehet vele szivni.
Szerintem ez se igaz ha jol lovod be az ide t kernelbe az sokat szamit ...A pci lekezeles Direct be is sokat dob (ha a rendszer megeszi)... Szoval egy 20% ot tisztan lehett dobni
[quote:eb37eb318a="pozsy"]
Osszessegen azt tudom mondani, hogy a legvaloszinubb az, hogy az uhuban ujabb, es ezaltal jobban programok vannak, ezert lehet lassab. Vagy esetleg lassabb a vinyod, kevesebb a ramod. De ha irsz meg meresi adatokat, probalkozhatunk tovabb.
Szerintem javasoljunk neki 1 Gentoo t ha optimalizalni akar 1-2 het kemeny felkeszules utana 1-2 het szivas es menni fog ;)
De ha optimalizalt rendszert akarsz vagyez vagy BSD ...
- A hozzászóláshoz be kell jelentkezni
Azóta elkezdtem próbálgatni a hdparmot, hogy hátha azzal elérek valamit. De sata winyóm van, amit az Uhu sda-nak lát. Ez szép és jó, de emiatt a hdparm nem megy vele.
Próbáltam átlinkelni hda-nak, de persze nem ment :(
- A hozzászóláshoz be kell jelentkezni
Huhh!
Azért ne ugorjatok rögtön egymás torkának. Nem azért indítottam a témát!
Pozsy írta, hogy írjam le, hogy konkrétan mi a lassú, úgyhogy leírom.
Egyébként a 3x tényleg költői túlzás volt.
Nos a bootolás sebessége nem igazán érdekel, csak az hogy utánna hogy megy, és az egyébként is elég gyors. A probléma a programok betöltődésével, az mplayer fordítási idejével, meg ilyesmikkel van.
Konkrétan a Gnome, dúrván kétszer lassabban töltődik be, mint debian alatt ( ez nem költői túlzás volt ). Gyorsabb a Firefox is és hamarabb jön be a KDE. Eddig erre nem igen találtam más magyarázatot, mindhogy túl sok minden fut egyszerre, és a kernel túl sok mindennek ad megszakítást. A fölöslegesen futó daemonokat kilőttem, és nem lett sokkal gyorsabb maradtak a kernelmodulok. Persze lehet hogy alapvetően rosszul álltam hozzá a kérdéshez. Próbáltam kernelt forgatni is, mert azt mondták hogy segít , de uhu alatt eddig nem sikerült. ( Bent a munkahelyen debian alatt ez a művelet sikeres volt ).
Hát egyelőre ezt tudtam összeszedni.
- A hozzászóláshoz be kell jelentkezni
Az emlitett programok verzioja megegyezik debilanyon az uhus verzioval?
- A hozzászóláshoz be kell jelentkezni
Csak annyit tudok hogy az említett debian egy sid.
- A hozzászóláshoz be kell jelentkezni
[quote:8002b0b0c0="BikMak"]Nos a bootolás sebessége nem igazán érdekel, csak az hogy utánna hogy megy, és az egyébként is elég gyors. A probléma a programok betöltődésével, az mplayer fordítási idejével, meg ilyesmikkel van.
Konkret dolgokrol beszeljunk :)
A programok betoltesi ideje sokmindentol fugg, peldaul a vinyotol is. Amivel gyorsitani tudsz esetleg az a prelink. Rakd fel a "prelink" nevu csomagot, majd futtasd le (rootkent) a "prelink -a" parancsot. Jopar percig el fog tartani, kiir majd nehany warningot, de ne aggodj miatta.
Nem nagyon ertem, hogy miert izgatod magad egy mplayer forditasi sebessegen, mikor:
- ezt ugyse csinalja minden nap az ember
- ez szinte biztos hogy amiatt van, hogy az uhuban ujabb, es egyben sajnos lassabb(an fordito) gcc van mint a debianban (ez nem azt jelenti hogy a vegeredmeny kod lenne lassabb, epp ellenkezoleg!)
- az uhuban alapbol beepitve van "ccache", ha masodszor forditasz, akkor latni fogod hogy mennyivel gyorsabb lesz :)
[quote:8002b0b0c0="BikMak"]Konkrétan a Gnome, dúrván kétszer lassabban töltődik be, mint debian alatt ( ez nem költői túlzás volt ).
Ugyan arrol a gnome verziorol van szo? Mert ha nem, akkor bocs, de ez a gnome-on mulik.
[quote:8002b0b0c0="BikMak"]Gyorsabb a Firefox is és hamarabb jön be a KDE.
Marmint most az uhu vagy a debian a gyorsabb?
[quote:8002b0b0c0="BikMak"]Eddig erre nem igen találtam más magyarázatot, mindhogy túl sok minden fut egyszerre, és a kernel túl sok mindennek ad megszakítást. A fölöslegesen futó daemonokat kilőttem, és nem lett sokkal gyorsabb maradtak a kernelmodulok. Persze lehet hogy alapvetően rosszul álltam hozzá a kérdéshez. Próbáltam kernelt forgatni is, mert azt mondták hogy segít , de uhu alatt eddig nem sikerült. ( Bent a munkahelyen debian alatt ez a művelet sikeres volt ).
Sajnos rosszul alltal a kerdeshez, de legalabb kerdeztel :) A hatterben futo daemonok sincsenek hatassal a programokra, ugyanis ha azokat nem hasznalod, akkor NULLA processzoridot fogyasztanak.
A kernelforditas megrosszabb otlet, nem fogsz tudni kimutatni merheto kulonbseget, viszont sokat lehet vele szivni.
Osszessegen azt tudom mondani, hogy a legvaloszinubb az, hogy az uhuban ujabb, es ezaltal jobban programok vannak, ezert lehet lassab. Vagy esetleg lassabb a vinyod, kevesebb a ramod. De ha irsz meg meresi adatokat, probalkozhatunk tovabb.
- A hozzászóláshoz be kell jelentkezni
[quote:c557779727="Testa"]De memoriat lehett sporolni melle a lattszolagos 0 processor ido se nulla ... soot...
Memóriát, igen, néhány kilobyte-ot a gépedben lévő sokszáz megából, hajrá! Szerinted érezhető lesz az ebből adódó teljesítménynövekedés?
Prociidőt: ugyan elmesélnéd, hogy miért nem 0?
Pl a debian cron alap cuccai viccessen meg tudjak porgetni a rendszert...
UHU-ban alapból hetente egyszer fut le egy updatedb cron-ból, más semmi.
[quote:c557779727="Testa"]Szerintem ez se igaz ha jol lovod be az ide t kernelbe az sokat szamit ...A pci lekezeles Direct be is sokat dob (ha a rendszer megeszi)... Szoval egy 20% ot tisztan lehett dobni
Tényleg, neked már sikerült? Áruld el légyszi hogy hogyan csináltad, hadd okosodjunk mi is! :-)
A 20%-ot túlzásnak tartom, mondjuk 5%-ról meggyőzhető vagyok, de nem hűbelebalázs módjára, hanem komoly szaktudással a háttérben látok esélyt ilyen eredményekre.
- A hozzászóláshoz be kell jelentkezni
[quote:610a0e50c4="Testa"]Milyen rendszer ???
Segítek: a "Hungarian Unix Portal Forum Index -> UHU Linux" topicban vagy miarákban vagyunk...
- A hozzászóláshoz be kell jelentkezni
hi
[quote:a16b671d35="egmont"]
A 20%-ot túlzásnak tartom, mondjuk 5%-ról meggyőzhető vagyok, de nem hűbelebalázs módjára, hanem komoly szaktudással a háttérben látok esélyt ilyen eredményekre.
A járásközbeni teljesítmény nekem nem nőtt (ígyis-úgyis 1 és 0% között ugrál a cpu :)), de a boot (a grubtól a fluxbox betöltéséig) lemértem, pontosan felére csökkent a forgatott kernelemmel a debian alap moduláris 2.6.10-686-ához képest. (desktoppcnél (főleg laptopnál) ez sokat jelent) a bootsplash-sel már pár seccel tovább tart.
- A hozzászóláshoz be kell jelentkezni
[quote:cd02c42b21="_Polesz_"][quote:cd02c42b21="pozsy"][quote:cd02c42b21="BikMak"]Egyébként most már azért is megcsinálom. Azóta megtudtam, hogy az rmmod-al kell kihajingálni ami nem kell. Majd megírom a scriptet aztán meglátjuk. Ha nem lesz gyorsabb akkor ez van. :)
Attol fuggetlenul, hogy ertelmetlennek tartom eme idotoltesedet, azt tudom mondani, hogy csinald! VISZONT: ha levonsz kovetkeztetest barmilyen sebessegvaltoztatast illetoen, azt ne ugy tedd, hogy "mintha gyorsabb lenne", hanem valami _preciz_, _pontosan merheto_ adatokra tamaszkodva.
Jah és értesítse az UHU fejlesztőket akik ezek után a kardjukba dőlnek :lol: bocs no flame :)
:) Valószínüleg tényleg a kardjukba dőlnének attól a sok bénázástól amit itt csinálok, de közben sikeresen mélyülök el az Uhu lelkivilágában, és ennek biztos örülnek :)
Nos, tegnap raktam az rc.boot könyvtárba egy 22-others nevű scriptet, amibe rmmod <modul> parancs sűrű ismételgetésével szépen kiszedtem a felesleges modulokat. Reboot után tényleg nem tette be őket. Mintha egy kicsit gyorsabb lenne! :) Viccet félretéve semmi változás nem történt, de sikerült. :D Egyébként milyen program(ok)al tudok pontos, precíz mérést csinálni?
Ha modulokat akarsz kiszedni szerintem akkor jársz el a legegyszerűbben (szerintem ) ,ha az UHU vezérlő pultjában a kernel modulok fülre kattintasz és ott ami nem kell csak simán kikapcsolod .
Ezt már próbáltam, de a dolog csak a következő reboot-ig élt.
A kernelforgatás meg eddig Uhu alatt nem ment.
- A hozzászóláshoz be kell jelentkezni
[quote:c0e7c5fec3="egmont"][quote:c0e7c5fec3="Testa"]De memoriat lehett sporolni melle a lattszolagos 0 processor ido se nulla ... soot...
Memóriát, igen, néhány kilobyte-ot a gépedben lévő sokszáz megából, hajrá! Szerinted érezhető lesz az ebből adódó teljesítménynövekedés?
Prociidőt: ugyan elmesélnéd, hogy miért nem 0?
Nemmindegy hogy kapod a par k t...
plusz az L1 - L2 betoltesi ido.... na mindegy...
Gondold at...
[quote:c0e7c5fec3="egmont"]
Pl a debian cron alap cuccai viccessen meg tudjak porgetni a rendszert...
UHU-ban alapból hetente egyszer fut le egy updatedb cron-ból, más semmi.
Ritkan lattok UHU t en szemely szerint a csomag listaig jutottam ahol tobb anno meg sanshop csomagot lattam stabilkent feltuntetve innentol tovab nem erdekelt ... Azota mi van veluk nem tudom...
[quote:c0e7c5fec3="egmont"]
[quote:c0e7c5fec3="Testa"]Szerintem ez se igaz ha jol lovod be az ide t kernelbe az sokat szamit ...A pci lekezeles Direct be is sokat dob (ha a rendszer megeszi)... Szoval egy 20% ot tisztan lehett dobni
Tényleg, neked már sikerült? Áruld el légyszi hogy hogyan csináltad, hadd okosodjunk mi is! :-)
A 20%-ot túlzásnak tartom, mondjuk 5%-ról meggyőzhető vagyok, de nem hűbelebalázs módjára, hanem komoly szaktudással a háttérben látok esélyt ilyen eredményekre.
Haat nem mindegy hogy Generic ide vagy Intel ICH :P
Vagy I386 proci vagy p4 :P Nem mindegy hogy singel processor vagy Hyperthreading... Nem mindegy hogy lowmem vagy 1 gigabyte memo 4 gigabyte os high mem supportal... nem lenyegtelen a kernel microcode se de nem mindig gyorsit sot... kernel ati frame buffer vagy vesa ...
Na itt abba is hagytam mert meguntam ...
- A hozzászóláshoz be kell jelentkezni
De memoriat lehett sporolni melle a lattszolagos 0 processor ido se nulla ... soot... Szoval ha valami felesleges azt ki lehett szedni mert okozhatt szagatast belassulast ... Pl a debian cron alap cuccai viccessen meg tudjak porgetni a rendszert...
Tényleg nem 0. Az rendben hogy az adott processz nem csinál semmit, de a kernelnek időnként megszakítást kell adnia a processznek, igény nélkül is, hogy tudja mi a rák van vele, meg hogy esetleg akar e valamit csinálni. És ezt mind le kell kezelni, ami alapvetően nem sok idő, de minden modulban lévő dolog külön processz, és minden alkalmazás is legalább 1 processz, tehát az Uhuban alapállapotban is fut vagy 80 db.
1-2 K memória szintén sokat számit, abban az esetben ha a kernelről van szó, mert ő ha minden jól megy mindig a cache-ben van, ami nekem csak 256K, és nem mindegy, hogy mi fér még el mellette.
Na ezek miatt kezdtem el én modulokat kiszedegetni.
Más: Miért ne írjak messengert?
- A hozzászóláshoz be kell jelentkezni
Hi!
Megnéztem hogy milyen modulok töltődnek be, és megállapítottam hogy a fele tök fölösleges. Az rc.boot-ban kiszedtem a modulok egy részét, de még így is maradt egy rakadt. Hol tudom azt beállítani hogy mely modulok NE töltődjenek be?
- A hozzászóláshoz be kell jelentkezni
Ha letorlod tuti nem toltodik be. De ha betoltodik akkor azt valami kerte hogy toltodjon be... tuti hogy feleslegesek? Magatol ne mtoltoget be olyat amire nincs szukseg
- A hozzászóláshoz be kell jelentkezni
találtam egy modules.skip file-t és beleírtam a modulokat, amit nem akarok hogy betöltődjenek. De ugyanúgy bent vannak. csak azokra működik, amik a rc.boot/12-detect fileban vannak. Egy sikertelen kernelforgatás után arra jutottam, hogy a boot folyamat elején tölti be őket az initrd-ből. Nincs valami parancs, amivel ki lehet dobni egy module-t a kernelből? beraknék az rc.boot végére egy scriptet, ami kiszedi a feleslegeseket. ( kicsit barbár megoldás )
- A hozzászóláshoz be kell jelentkezni
[quote:69b32cffa0="BikMak"]Hi!
Megnéztem hogy milyen modulok töltődnek be, és megállapítottam hogy a fele tök fölösleges. Az rc.boot-ban kiszedtem a modulok egy részét, de még így is maradt egy rakadt. Hol tudom azt beállítani hogy mely modulok NE töltődjenek be?
Inkabb keress hasznosabb elfoglaltsagot az eletben, hidd el semmi ertelme ezzel foglalkoznod.
- A hozzászóláshoz be kell jelentkezni
[quote:7bf96651ff="pozsy"][quote:7bf96651ff="BikMak"]Hi!
Megnéztem hogy milyen modulok töltődnek be, és megállapítottam hogy a fele tök fölösleges. Az rc.boot-ban kiszedtem a modulok egy részét, de még így is maradt egy rakadt. Hol tudom azt beállítani hogy mely modulok NE töltődjenek be?
Inkabb keress hasznosabb elfoglaltsagot az eletben, hidd el semmi ertelme ezzel foglalkoznod.
hmm flamezzek?
Kicsit idegesít hogy a szomszéd debianja 3x gyorsabb mint az én linuxom.
Egyébként a gépem tudja a raid0-6-ot, és ezért a gép be is tölti a hozzá való modulokat ( vagy 10-et ), de egy winyóval nem sokat kezdek vele.
- A hozzászóláshoz be kell jelentkezni
A gyorsasagnak baromira sok koze van am a betoltott moduloknak. A raid moduljai meg valoszinuleg a raidkartyad driverei lesznek... Es mien mas folosleges modulokat talaltal eddig? A Raid vezerlot meg vedd ki, vagy szereld ki ha nem akarod a moduljait. Ha meg azon van a wincsid akkor ugye hasznalod azokat a modulokat, meg ha nincs is raidba kotve
- A hozzászóláshoz be kell jelentkezni
Jó, meghajlok a véleményed előtt, de akkor végképp nem értem, hogy a slackware meg a debian mért gyorsabb az uhu-nál (+fedoránál +suse-nél ).
- A hozzászóláshoz be kell jelentkezni
[quote:008661bf17="BikMak"]Jó, meghajlok a véleményed előtt, de akkor végképp nem értem, hogy a slackware meg a debian mért gyorsabb az uhu-nál (+fedoránál +suse-nél ).
Kerneld annak a daemonnak a neve, ami szükség esetén betöltögeti a modulokat, én sokat nem foglalkoztam ezzel a témával, nézd meg a doksiját, hátha találsz valami hasznosat hozzá.
- A hozzászóláshoz be kell jelentkezni
Megoldas 1: szepen bekattintgatod a "kernelmodulok" menupont alatt elojovo ablakos csodaban, hogy mit nem szertnel, hogy elinduljon
Megold 2: az elozo progi az /etc/modules... notload, valami ilyen eleg egyertelmu nevu fileban sorolja fel ezeket, ide kezzel is beirhatod.
(A raid modulok, a software raid moduljai, nem raidkartyahoz tartoznak, tehat tenyleg feleslegesek adott esetben ezek is pl)
- A hozzászóláshoz be kell jelentkezni
[quote:64d6a2d3a1="pozsy"]nkabb keress hasznosabb elfoglaltsagot az eletben, hidd el semmi ertelme ezzel foglalkoznod.
A nagy fészkes fenét nincs! Az egész linuxosdinak az a legnagyobb előnye a fröccsöntött cuccossal szemben, hogy esélyed van megismerni, hogy mi mit miért csinál a rendszeredben, illetve úri kedved szerint eljátszadozhatsz vele, kipróbálhatod a gondolataidat (aztán vagy összeszakad, vagy nem), de semmiképp sem az "ezt kapod, nesze, ne érdekeljen", azaz pontosan az, amit te írtál!
Szóval: modulok alapból háromféleképpen töltődhetnek be:
- te töltöd be kézzel (modprobe modulnév v. insmod modulnév), ez esetben ne írd be, és kész :)
- a rendszer indulásakor userspace automatizmus tölti be őket, ezt általában modutils-nak vagy module-init-tools-nak hívják, debian alatt a /etc/init.d-ben találhatóak. ezek valami config file-ból szedik, hogy mit kell tenniük, debian esetén ez a /etc/modules.conf, ezt lehet kézzel szerkesztgetni, van hozzá karakter-grafikus segédszutyok modconf néven, mind a modules.conf-nak, mind a modconf-nak van man-oldala is. ha valami innen töltődik be, akkor itt tudod kitiltani is.
- a kernel maga is képes igény esetén modulokat betölteni, ilyenkor ő indít implicite egy modprobe-ot, és húzatja be vele a modult, történik ez pl. akkor, ha valamit nfs-en keresztül akarsz mountolni, de az nfs támogatásod modulban van ÉS ha a kernelben engedélyezve van az automatikus modul-betöltés. ezt a kernel configjában CONFIG_KMOD néven találod meg, ill. a menuconfig-ben Loadable Module Support/ Kernel Module Loader címszó alatt. Ha ezt kitiltod, nem fog ilyet tenni.
Végül, de nem utolsósorban magukat a modulokat megtalálod a /lib/modules/(kernel verzió) könyvtárban, ha valamit letörölsz, természetszerűleg nem fogja tudni behúzni, ezt viszont nem javaslom. Ha mindenképpen ilyesmit akarsz csinálni, inkább nevezd át valami kamu névre, pl. kitiltva_hablagabla.o, hogy ha netán mégiscsak kellene, legyen honnan visszaállítani. Egyrészt törölni soha se késő, másrészt meg "Istenben bízunk, a többiről csinálunk mentést" :).
Ja, és igenis kutakodj nyugodtan a rendszeredben, soha ne add fel, nem mágia, és mindennel jobban fogsz tudni bánni, ha rájössz, hogy hogyan működik. A "varázslókat" meg hagyd meg azoknak, akiket a részletek nem érdekelnek :).
Üdv, és sok szerencsét!
- A hozzászóláshoz be kell jelentkezni
[quote:f09e8e4f46="Beanie"][quote:f09e8e4f46="BikMak"]Jó, meghajlok a véleményed előtt, de akkor végképp nem értem, hogy a slackware meg a debian mért gyorsabb az uhu-nál (+fedoránál +suse-nél ).
Kerneld annak a daemonnak a neve, ami szükség esetén betöltögeti a modulokat, én sokat nem foglalkoztam ezzel a témával, nézd meg a doksiját, hátha találsz valami hasznosat hozzá.
Azért mert UHU és ez nem bántásnak szántam és nem is flame-nek!
Az UHU célja, hogy egy olyan rendszert adjon a kezedbe ami szinte minden vason kifogástalanul megy. Ezért előfordulhat, hogy annyi modul/deamon töltődik be indításkor amire neked hullára nincs szükséged. A slack és a debian is a másik végletből közelít. Kell valami? Töltsd be a modulját. Mondjuk már itt is kezd jelen lenni a hotplug ezért szinte modulok tucatjai töltődnek feleslegesen. Sokszor tényleg úgy látszik, hogy káosz van, de ha éppen egy pendrive-t raksz be akkor nem kell varázsolnod semmit UHU alatt, míg slackware-nél ha minimalista vagy akkor jó ha tudod, hogy az USB milyen /dev alatt található.
Kb ennyi.
Az autós példáknál maradva. Mindketten kaptunk egy kocsit, de míg a tied tele van mindenféle extra cuccal amik a sebbeséget csökkentik addig én nyugodtan száguldozhatok. A gond csak ott van ha eltévedünk. Neked ott a felesleges GPS, nekem meg el kell menni szerezni egyet mielőtt tovább megyek :)
- A hozzászóláshoz be kell jelentkezni
gsimon: valami koze van a hotplugnak is hozza nem? ubuntu alatt ugy tudtam letiltani automatikus modulbetoltest, ha az /etc/hotplug/blacklist-be irtam.
- A hozzászóláshoz be kell jelentkezni
[quote:079a896652="gsimon"][quote:079a896652="pozsy"]nkabb keress hasznosabb elfoglaltsagot az eletben, hidd el semmi ertelme ezzel foglalkoznod.
A nagy fészkes fenét nincs! Az egész linuxosdinak az a legnagyobb előnye a fröccsöntött cuccossal szemben, hogy esélyed van megismerni, hogy mi mit miért csinál a rendszeredben, illetve úri kedved szerint eljátszadozhatsz vele, kipróbálhatod a gondolataidat (aztán vagy összeszakad, vagy nem), de semmiképp sem az "ezt kapod, nesze, ne érdekeljen", azaz pontosan az, amit te írtál!
...
Az UHU-t úgy rakják össze, hogy a lehető legjobb legyen, tehát te mint egyszerű földi júzer ne túrkáld a rendszert. Ha komoly kihívásra vágysz akkor debian, slack és a minimalista disztribek ezreiben lehet turkálni :)
Ha mégis UHU-t akarsz heggeszteni akkor jó ha felkészülsz akár egy újratelepítésre is, de sok hasznosat tanulhatsz is belőle.
Hajrá UHU, Linux és minden disztrib. Előre az ismeretlenbe és tovább :)
- A hozzászóláshoz be kell jelentkezni
[quote:fce0715fdc="maat"]hi
[quote:fce0715fdc="egmont"]
A 20%-ot túlzásnak tartom, mondjuk 5%-ról meggyőzhető vagyok, de nem hűbelebalázs módjára, hanem komoly szaktudással a háttérben látok esélyt ilyen eredményekre.
A járásközbeni teljesítmény nekem nem nőtt (ígyis-úgyis 1 és 0% között ugrál a cpu :)), de a boot (a grubtól a fluxbox betöltéséig) lemértem, pontosan felére csökkent a forgatott kernelemmel a debian alap moduláris 2.6.10-686-ához képest. (desktoppcnél (főleg laptopnál) ez sokat jelent) a bootsplash-sel már pár seccel tovább tart.
En mar mertem ilyesmit uhuban, a boot ido kb 2 masodperccel gyorsithato. Ez egyreszt elhanyagolhato, masreszt eleve nem errol szol ez a topic.
- A hozzászóláshoz be kell jelentkezni
Megnyugotam, már majdnem elhittem, hogy csak én akarok elfogadható sebességet kihozni a számítógépemből. Köszi a segítséget!
- A hozzászóláshoz be kell jelentkezni
[quote:b933f782aa="Testa"][quote:b933f782aa="egmont"][quote:b933f782aa="Testa"]De memoriat lehett sporolni melle a lattszolagos 0 processor ido se nulla ... soot...
Memóriát, igen, néhány kilobyte-ot a gépedben lévő sokszáz megából, hajrá! Szerinted érezhető lesz az ebből adódó teljesítménynövekedés?
Prociidőt: ugyan elmesélnéd, hogy miért nem 0?
Nemmindegy hogy kapod a par k t...
plusz az L1 - L2 betoltesi ido.... na mindegy... Gondold at...
Ugy latom sajnos csak vagdalkozol fogalmakkal... Par KILObyte memoria nem szamit SEMMIT tobbszaz MEGAbyte memoria mellett. Ennek tobb nagysagrendi kulonbseg mellett egyeb technikai okai is vannak. Ja, arrol nem is beszelve, hogy ha par kilobyte memoriat akarsz sporolni, akkor inkabb mondok neked tiz masik modszert amivel sokkal gyorsabban es ertelmesebben sporolhatsz legalabb ennyit.
Masreszt az L1-L2 cachenek total semmi koze mindehhez. Ez kb olyan mintha a monitorfelbontas fogalmat hoztad volna ide.
[quote:b933f782aa="Testa"]
[quote:b933f782aa="egmont"]
Pl a debian cron alap cuccai viccessen meg tudjak porgetni a rendszert...
UHU-ban alapból hetente egyszer fut le egy updatedb cron-ból, más semmi.
Ritkan lattok UHU t en szemely szerint a csomag listaig jutottam ahol tobb anno meg sanshop csomagot lattam stabilkent feltuntetve innentol tovab nem erdekelt ... Azota mi van veluk nem tudom...
[quote:b933f782aa="egmont"]
[quote:b933f782aa="Testa"]Szerintem ez se igaz ha jol lovod be az ide t kernelbe az sokat szamit ...A pci lekezeles Direct be is sokat dob (ha a rendszer megeszi)... Szoval egy 20% ot tisztan lehett dobni
Tényleg, neked már sikerült? Áruld el légyszi hogy hogyan csináltad, hadd okosodjunk mi is! :-)
A 20%-ot túlzásnak tartom, mondjuk 5%-ról meggyőzhető vagyok, de nem hűbelebalázs módjára, hanem komoly szaktudással a háttérben látok esélyt ilyen eredményekre.
Haat nem mindegy hogy Generic ide vagy Intel ICH :P
Nem mindegy, viszont ez megint abszolut nem idevago kerdes. Az az adott kernel, ami az uhu csomagba le van forditva, jol kezeli az ide-t. Ha pedig esetleg bizonyos vezerlo/drive kombinaciok eseten megsem, akkor attol hogy ujraforditod ugyanazt a forrast semmi nem lesz jobb, tehat nem fogod tudni "jol beloni", hiaba is kepzeled ezt.
[quote:b933f782aa="Testa"]Vagy I386 proci vagy p4 :P
Az uhu kernele 586-ra van forditva, es hajszal pontosan ugyanezt a bytekodot kapod ha p4-et allitasz be neki. Nem fogom ezt itt most megindokolni, mert nem eri meg hogy ennyit irjak, inkabb nezz utana neten, pl kezdd a fedora-devel archivumaval.
[quote:b933f782aa="Testa"]Nem mindegy hogy singel processor vagy Hyperthreading...
HT/SMP van az uhu kernelben alapbol. Rontani pedig nem ront a teljesitmenyen ha nem kell.
[quote:b933f782aa="Testa"]Nem mindegy hogy lowmem vagy 1 gigabyte memo 4 gigabyte os high mem supportal...
A lowmem ugyanaz mint az 1gb, a 4gb-hez kepest pedig nincs merheto kulonbseg.
[quote:b933f782aa="Testa"]nem lenyegtelen a kernel microcode se de nem mindig gyorsit sot...
Ez tisztan userspace kerdes, latom megint kepben vagy... Ja, es uhuban egyebkent ez is megvan alapbol.
[quote:b933f782aa="Testa"]Na itt abba is hagytam mert meguntam ...
Teged is nagyon kerlek hagyd abba a hulyeseget terjeszteset! Koszonom.
- A hozzászóláshoz be kell jelentkezni
[quote:a48a1396da="BikMak"]Megnyugotam, már majdnem elhittem, hogy csak én akarok elfogadható sebességet kihozni a számítógépemből. Köszi a segítséget!
Nem csak Te vagy így, sokan így vagyunk vele. Nem csak azért linuxozunk mert divat.
Jó turkálást és optimalizálást.
- A hozzászóláshoz be kell jelentkezni
[quote:5180510f43="BikMak"]
De memoriat lehett sporolni melle a lattszolagos 0 processor ido se nulla ... soot... Szoval ha valami felesleges azt ki lehett szedni mert okozhatt szagatast belassulast ... Pl a debian cron alap cuccai viccessen meg tudjak porgetni a rendszert...
Tényleg nem 0. Az rendben hogy az adott processz nem csinál semmit, de a kernelnek időnként megszakítást kell adnia a processznek, igény nélkül is, hogy tudja mi a rák van vele, meg hogy esetleg akar e valamit csinálni. És ezt mind le kell kezelni, ami alapvetően nem sok idő, de minden modulban lévő dolog külön processz, és minden alkalmazás is legalább 1 processz, tehát az Uhuban alapállapotban is fut vagy 80 db.
1-2 K memória szintén sokat számit, abban az esetben ha a kernelről van szó, mert ő ha minden jól megy mindig a cache-ben van, ami nekem csak 256K, és nem mindegy, hogy mi fér még el mellette.
Na ezek miatt kezdtem el én modulokat kiszedegetni.
Brrr.... Nezzuk sorban:
- A kernelnek _nem_ kell mindig megszakitast adni a processeknek, ahhoz hogy tudja elore hogy nincs semmi dolga az adott processnek, erre valo tobbek kozott a select() rendszerhivas, marpedig a programok, foleg a daemonok nagy resze ebben szokott varakozni.
- Itt a kernel modulokrol van szo, marpedig azok ettol teljesen maskepp mukodnek, azokra meginkabb teves lenne a fenti kijelentes
- Az UHUban alapallapotban egyik daemon se "veletlenul" fut, es a legtobbre altalaban igenis szukseged van. Ha pedig nincs, akkor igenis NULLA processzoridot fogyaszt, ajanlom figyelmedbe a ps programot, amelynek segitsegevel errol magad is meggyozodhetsz.
- A kernel egyaltalan nincs mindig a cacheben, mar csak azert is, mert tobb megabyteot foglal a memoriaba, ami meg a 2MB-os cachebe se fer bele.
- Amikor arrol van szo, hogy mennyi processzorido jut a userspace processzeknek, azaz mennyire gyors a rendszer, akkor csak rossz lenne ha a kernel poffeszkedne a procicacheben a tenyleges feladatokat vegzo processzekkel ellentetben.
Remelem kezded latni, hogy tok ertelmetlen emiatt tehat a kernel modulokkal foglalkoznod.
- A hozzászóláshoz be kell jelentkezni
[quote:dbd4cc5933="BikMak"]
hmm flamezzek?
Kicsit idegesít hogy a szomszéd debianja 3x gyorsabb mint az én linuxom.
Egyébként a gépem tudja a raid0-6-ot, és ezért a gép be is tölti a hozzá való modulokat ( vagy 10-et ), de egy winyóval nem sokat kezdek vele.
Igen, sejtettem hogy flame lesz belole. Probaljunk megis technikai szinten maradni:
- Hidd el, hogy azok a modulok amiket betoltve latsz, osszesen csak nehany KILObyte memoriat fogyasztanak el az egesz rendszeredbol, illetve betoltesuk a boot soran osszesen max 1 masodperc idot vesz el. Ezen kivul SEMMILYEN lassitast nem okoznak. Ha masert nem, azert hidd el nekem mindezt, mert en patyolgatom az uhu kernelet es a hozza kapcsolodo dolgokat.
- Az igazi problemad tehat az, hogy lassunak erzed a rendszered egy masikhoz kepest. Probaljunk inkabb erre magyarazatot es megoldast keresni. Azt allitod, hogy 3x gyorsabb a masik rendszer. Persze ez nyilvan egy koltoi tulzas, de kerlek inkabb ird le konkretan hogy mi a lassu, maris ki tudunk indulni valamibol.
- A hozzászóláshoz be kell jelentkezni
[quote:f7098d4236="Czo"]A gyorsasagnak baromira sok koze van am a betoltott moduloknak.
Valoban nincs koze.
[quote:f7098d4236="Czo"]A raid moduljai meg valoszinuleg a raidkartyad driverei lesznek...
Azok sw raidhez valo modulok, de egyebkent tenyleg nem okoznak lassulast vagy ilyesmit.
- A hozzászóláshoz be kell jelentkezni
[quote:c0651a3bef="Beanie"]Kerneld annak a daemonnak a neve, ami szükség esetén betöltögeti a modulokat, én sokat nem foglalkoztam ezzel a témával, nézd meg a doksiját, hátha találsz valami hasznosat hozzá.
Ez nem igaz, siman a kernel hoz letre egy uj processzt, nem valami kerneld.
- A hozzászóláshoz be kell jelentkezni
[quote:b3941c5cd3="gsimon"][quote:b3941c5cd3="pozsy"]nkabb keress hasznosabb elfoglaltsagot az eletben, hidd el semmi ertelme ezzel foglalkoznod.
A nagy fészkes fenét nincs! Az egész linuxosdinak az a legnagyobb előnye a fröccsöntött cuccossal szemben, hogy esélyed van megismerni, hogy mi mit miért csinál a rendszeredben, illetve úri kedved szerint eljátszadozhatsz vele, kipróbálhatod a gondolataidat (aztán vagy összeszakad, vagy nem), de semmiképp sem az "ezt kapod, nesze, ne érdekeljen", azaz pontosan az, amit te írtál!
Nincs ertelme hogy modulokkal foglalkozzon, mert a topicnyito illeto nem ezeknek a lelkivilagat szeretne megismerni, hanem egy gyorsabban mukodo rendszert szeretne, ahhoz pedig nem ezeken keresztul fog eljutni.
Aki valamit meg szeretne ismerni vagy tanulni, annak van ertelme ilyesmikkel foglalkoznia, de mar elore latszott hogy itt nem errol az esetrol van szo, ezert irtam amit.
- A hozzászóláshoz be kell jelentkezni
[quote:e2c018b3df="Skuzzy"]gsimon: valami koze van a hotplugnak is hozza nem? ubuntu alatt ugy tudtam letiltani automatikus modulbetoltest, ha az /etc/hotplug/blacklist-be irtam.
Modulok sokfelekeppen toltodhetnek be. Ha egy modul epp a hotplug rendszeren keresztul toltodik be, akkor legkonnyebb ott letiltani.
- A hozzászóláshoz be kell jelentkezni
[quote:3b2ebebd8f="_Polesz_"]Az UHU-t úgy rakják össze, hogy a lehető legjobb legyen, tehát te mint egyszerű földi júzer ne túrkáld a rendszert. Ha komoly kihívásra vágysz akkor debian, slack és a minimalista disztribek ezreiben lehet turkálni :)
Ha mégis UHU-t akarsz heggeszteni akkor jó ha felkészülsz akár egy újratelepítésre is, de sok hasznosat tanulhatsz is belőle.
Hajrá UHU, Linux és minden disztrib. Előre az ismeretlenbe és tovább :)
Az uhu semmivel sem piszkalhato kevesbe mint mas rendszerek.
- A hozzászóláshoz be kell jelentkezni