17.5.2007 00:08
CIJOML | skóre: 58
| Praha
Rozbalit Rozbalit vše Re: Jaderné noviny - 25. 4. 2007
Portál AbcLinuxu, 5. května 2025 01:24
Aktuální verze jádra: 2.6.21-rc7. Citáty týdne: Ingo Molnar, Matt Ranon. Další týden debat o plánovačích. Souborové systémy: chunkfs a reiser4. Diskuze o suspend2 obnovena.
Aktuální předverze řady 2.6 je (k 25. 4. 2007) pořád 2.6.21-rc7; očekávané vydání 2.6.21 bylo odloženo. V hlavním git repozitáři se hromadí patche opravující regrese oproti předchozí verzi.
V minulém týdnu nevyšla žádná nová verze -mm.
Starší jádra: 2.6.16.49 vyšlo 23. dubna s několika opravami. Uživatelé řady 2.4 si mohou vybrat z 2.4.34.3 (22. dubna, opravy síťování), 2.4.34.4 (opravuje kompilační problém s 2.4.34.3) nebo 2.4.35-pre4 (22. dubna, různé opravy).
S jinými, heuristickými přístupy jsme vždycky narazili na problém vzniku "hyper-inflace" neekonomické virtuální měny, která mohla být určitými úlohami volně tištěna. V CFS je tato ekonomika přísná a jemná plus/mínus rovnováha je pevně spravována konzervativní a nezávislou centrální bankou.
-- Ingo Molnar zavádí do plánování fiskální kázeň.
V jádře se nám líbí, je tam hezky teplo a příjemně. Naproti tomu uživatelský prostor je chladné, temné a deštivé místo, kam se nám prostě nechce.
-- Matt Ranon
Minulý týden představil Ingo Molnar svůj "completely fair scheduler" a autor Staircase Deadline scheduleru Con Kolivas se trochu uraženě stáhl. Mezitím se však Con vrátil a představil několik nových revizí SD plánovače; diskutovalo se o něm ale málo. Vypadá to, že Conovým cílem je zvednout laťku tak, aby se nakonec do jádra dostal nejlepší možný plánovač, ať už to bude kterýkoliv - s tím je těžké nesouhlasit.
Většina diskuzí se točila kolem CFS plánovače. Několik testerů hlásilo dobré výsledky, ale jiní si všimli regresí. Tyto problémy se, podobně jako většina z posledních let, týkají X Window systému. Mluví se proto o možných řešeních.
Klasická odpověď na problémy s interaktivitou X je změna hodnoty nice [renice] X serveru. Ale mnohým takové řešení připadá spíše jako hack, takže se práce na plánovačích často zaměřuje na odstranění nutnosti spouštět X s vyšší prioritou. Con Kolivas takový cíl zpochybňuje:
Jedinou vadou na kráse Linuxu zůstává X. Pořád nedokážu pochopit, proč se všichni snaží najít stále složitější způsoby, jak se o X postarat, když jediné, co X schází, je více procesoru. Navíc jsou to většinou velmi dobré nápady na _extra_ funkce, které by se Linuxu v budoucnu mohly hodit, ale vezmeme-li v potaz absurdní jednoduchost "renicování" X, tak mi uniká, proč se lidé snaží tyto alternativy prosazovat.
CFS se i nadále snaží předejít renicování, takže je v tomto ohledu zajímavé, že v4 CFS ve skutečnosti X renicuje - automaticky. Konkrétně jde o to, že plánovač navyšuje úroveň priority všech procesů, které provádějí hardwarové I/O (což ukazují volání ioperm() nebo iopl(), vlákna blokového loop zařízení a pracovních vláken přiřazených k pracovním frontám). Když je X serveru automaticky zvýšena priorita (kvůli použití iopl()), mívá lepší reakce.
Zatímco vyšší priorita pro jaderná vlákna by podle Inga mohla z dlouhodobého hlediska dávat smysl, renicování X považuje za dočasný hack. Opravdové řešení problému se bude pravděpodobně skládat ze dvou přístupů: přenos procesorového kreditu mezi procesy a plánování podle skupin.
Při použití CFS plánovače si každý proces nahromadí určité množství procesorového času, který je mu "dlužen"; tento čas je získáván čekáním na procesor, zatímco ho používají jiné procesy. Takový mechanismus může zařídit základní spravedlnost, protože každý dostane téměř stejný podíl dostupného procesorového času. Jestli je takový výpočet opravdu spravedlivý, to záleží na tom, jak posuzujeme spravedlnost; pokud X server považujeme za úlohu, která odvádí práci i za další procesy, pak by bylo spravedlivé, kdyby mohl X server sdílet kredit nahromaděný těmi dalšími procesy. Linus by rád viděl řešení založené na takovém principu:
"Ideální" situace by byla, pokud by to fungovalo tak, že když jde proces spát, budou všechny jeho extra body předány procesu, který naposled probudil. Pro X by to znamenalo 100% pomíjivé body: dostane je, když klient pošle požadavek, ale zase je *ztratí*, jakmile pošle odpověď!
CFS v5 patch obsahuje první náznak podpory takového provozu. Ještě tam není automatické přenášení kreditu, ale přibylo nové systémové volání:
long sched_yield_to(pid_t pid);
Toto volání přenechá procesor, podobně jako sched_yield(), ale také zařídí, aby se přenechávající proces vzdal poloviny kreditu (pokud vůbec nějaký měl) ve prospěch procesu určeného pomocí pid. Takové systémové volání by mohlo být (například) X knihovnami využito k přímému předání kreditu X serveru. V současné době neexistuje způsob, jak by mohl X server vrátit nevyužitý kredit; Ingo v té souvislosti zmínil systémové volání sched_pay(). Není ani možné zaručit, že X server získaný kredit využije k práci pro proces, který kredit přenechal; klidně by ho mohl vyplácat na okenní efekty. Ale je to krok správným směrem.
Dalším krokem, ovšem pouze ve stadiu prototypu, je Ingův patch s ekonomií plánovače. Tento mechanismus jadernému kódu umožňuje vytvořit "pracovní účet" plánovače; procesy pak mohou provádět vklady a výběry:
void sched_pay(struct sched_account *account);
void sched_withdraw(struct sched_account *account);
V tuto chvíli jsou všechny vklady i výběry omezeny na pevný úsek procesorového času. Kód unix-domain soketů byl upraven tak, aby vytvořil jeden takový účet pro každý soket. Všechny nerootovské procesy (například X klienty) zapisující na soket také provedou vklad na účet; rootovské procesy (především X server) si při čtení zpráv z účtu vyberou. Je to vše jen proof of concept [důkaz proveditelnosti]; skutečná implementace by vyžadovala trochu sofistikovanější API. Ukazuje to však, že X klienty mohou (v případě nedostatku procesorového času) převést své CPU kredity na server.
Dalším diskutovaným návrhem je plánování podle uživatelů nebo skupin. Jde o spravedlivé rozdělení procesorového času mezi uživatele místo procesů. Pokud má jeden uživatel spuštěn proces textového editoru a druhý začne kompilovat jádro příkazem make -j 100, bude mít plánovač 101 procesů soupeřících o procesor. Současné férové plánovače procesor rovnoměrně rozdělí mezi všechny procesy, takže kompilace jádra vezme všechno pro sebe a textový editor si bude muset vystačit s méně než 1 procentem dostupného procesorového času. Vývojářům jádra by to možná nevadilo, ale bylo by snadné argumentovat tak, že správné rozdělení by omezilo kompilaci jádra na polovinu času, což by textovému editoru ponechalo tu druhou.
To je základem plánování podle uživatelů. Kromě jiného by to mohlo pomoci s interaktivitou X: protože X běží pod jiným uživatelem (obyčejně root), automaticky se dostává do jiné plánovací skupiny s vlastní férovým přídělem procesoru. Linus plánování podle skupin tvrdě prosazoval (vizte citát z minulého týdne). Ingo na to reagoval s tím, že na to pamatuje - jen se k tomu ještě nedostal:
Na regrese týkající se plánování podle skupin jsem vůbec nezapomněl - především proto, že už máme rychlý hack, který kontroluje, jestli by tyto regrese plánování podle skupin vyřešilo: renicování. Bylo to vyzkoušeno na obou případech CFS regresí, o kterých vím: Mikův problém s "vyhladověním" X a Willyho problém popsaný jako "vyhladovění kevents, když běží tisíce úloh scheddos". A v obou případech pomohlo renicování [které by mělo být korektně a automaticky implementováno jako plánování podle uid skupin]. Takže jsem si vůbec nedělal starosti - plánování podle skupin tyto regrese _pravděpodobně řeší_. Raději jsem se zaměřil na regrese, které byly méně zřejmé.
Jinými slovy, výše popisované automatické renicování není permanentní řešení; místo toho jde o proof of concept plánování podle skupin. Ingo pokračoval s tím, že je mnoho dalších důležitých faktorů, které ovlivňují, jestli bude interaktivní plánování dobře fungovat; konkrétně je potřeba nanosekundové počítání a striktní rozdělení procesorového času v případech, kdy je to nutné. Jakmile to bude vše hotovo, může se začít uvažovat o problému s plánováním podle skupin.
Vypadá to tedy, že na CFS plánovači ještě zbývá udělat dost práce. Mezitím si však Linus postěžoval, že toto úsilí teď možná není na místě:
Nehledě na to, že bych lidi spíše požádal, aby se trochu podívali na aktuální regrese, místo aby trávili všechen čas s něčím, co nebude ani začleněno před vydáním 2.6.21 - máme tady palčivější problémy. Prosím?
Dalo by se říci, že všechny věci určené pro začlenění do 2.6.22 by teď měly být dány do pořádku. Ale náhrada procesorového plánovače pravděpodobně potrvá trochu déle. Vzhledem k počtu otevřených otázek - a dávce sebedůvěry, která bude pro nahrazení plánovače vyžadována - se zdá nepravděpodobné pokoušet se o 2.6.22.
Jedním ze základních problémů vývojářů souborových systémů je fakt, že zatímco disky jsou stále větší a rychlejší, poměr zvětšování kapacity a zrychlování je ve prospěch velikosti. Výsledkem je, že čas potřebný na přečtení celého disku se prodlužuje. Nikoho nebaví čekat na dokončení kontroly souborového systému při rebootu, takže představa čím dál delších fsck prodlev není lákavá. Naneštěstí je to směr, kterým se věci ubírají. Žurnálovací souborové systémy se mohou fsck vyhnout, ale pouze v případech, kdy nedošlo k žádnému poškození souborového systému.
Protože kontroly souborových systémů jsou věc, se kterou se musíme naučit žít, stojí za to uvažovat o tom, jak je v době terabajtových disků zrychlit. Jeden dávno existující nápad na vylepšení situace byl nedávno představen: chunkfs, "fs fission for faster fsck" [rozdělení souborových systémů pro rychlejší fsck]. Hlavní myšlenkou je vzít souborový systém a rozdělit ho na několik nezávislých, z nichž každý si udržuje svůj clean/dirty [čistý/nečistý] stav. Pokud se něco pokazí, je nutné zkontrolovat pouze ty souborové (pod)systémy, které byly v době selhání aktivní.
Stejně jako mnohé experimentální souborové systémy, i chunkfs je postaven na ext2. Interně je to skupina samostatných ext2, které pro vyšší úrovně souborového systému vypadají jako jediný. Každý kus [chunk] může být kódem souborového systému nezávisle spravován, ale mimo souborový systém jednotlivé kusy vidět nejsou. Myšlenka je to poměrně jednoduchá, ale jako vždy je potřeba vyřešit několik nepříjemných problémů.
Jedním z nich je skutečnost, že čísla inod v nadřazeném chunkfs musí být unikátní. Každý kus si však udržuje vlastní seznam inod začínající na čísle jedna, takže v jednotlivých kusech jsou čísla inod používána opakovaně. Chunkfs to řeší vkládáním čísla kusu do horních osmi bitů každého čísla inody. Kvůli tomu je však v chunkfs možných pouze 256 kusů.
Ošemetnější problém nastává při zvětšení velikosti souboru. Souborový systém se pokusí alokovat další bloky v kusu, ve kterém byl soubor původně vytvořen. Pokud se však daný kus zaplní, musí se na to jinak; nebylo by dobré, kdyby souborový systém vrátil chybu "no space" [nedostatek místa], když je v dalších kusech místa dost. Řešením je vytvoření "navazovacích inod" [continuation inode]. Ty sledují alokaci bloků v různých kusech; vypadají jako obyčejné soubory, ale jsou součástí vyššího pole alokací bloků. "Skutečná" inoda daného souboru může mít ukazatele až na čtyři další navazovací inody v různých kusech; pokud jich je potřeba více, může každá navazovací inoda ukázat na další čtyři. Navazovací inody tedy mohou být zřetězeny, což umožňuje vytváření libovolně velkých souborů.
Kód je v poměrně raném stadiu; text připojený k patchům poznamenává, že jde o počáteční implementaci a předpokládáme hodně změn, než bude kód alespoň trochu rozumně použitelný. Pro ty, kdo by chtěli chunkfs vyzkoušet s nějakými kvalitně zálohovanými daty, je připravena sada nástrojů.
Reiser4 je pravděpodobně nejdelším příběhem v historii vývoje linuxových souborových systémů. Už v době, kdy Hans Reiser v červenci 2003 poprvé požádal o začlenění do jádra, byl souborový systém několik let vyvíjen. Od té doby uplynuly skoro čtyři roky a reiser4 pořád zůstává mimo hlavní jádro. Hans Reiser už do dění nezasahuje, jeho společnost (Namesys) má potíže a s reiser4 se na první pohled nic neděje.
V poslední době však bylo možno zaznamenat zvýšený zájem o tento souborový systém. Ukázalo se, že dva zaměstnanci Namesysu na reiser4 stále pracují (hlavně z nadšení). Do -mm stromu posílali patche a pomalu se dostávají na konec seznamu věcí, které bylo třeba opravit. Takže se možná dočkáme nové snahy o zařazení, možná už v 2.6.23. Andrew Morton však říká, že k tomu bude ještě pár věcí potřeba; především bude nutné zajistit novou kontrolu kódu reiser4.
Aby se to začalo hýbat, potřebovali bychom všeobecný tlak. Přimět lidi, aby začali kód kontrolovat a testovat, a říct distributorům, aby se nad ním vážně zamysleli atd. To bychom mohli zařídit - bylo by k tomu asi nutné, aby lidé z Namesys (a já) začali o začlenění nahlas mluvit.
Nebo bychom mohli všechen kód reiser4 přesunout do kernel/sched.c - zdá se, že to na lidi platí.
Dovolím si odhadnout, že masový přechod na reiser4 není moc pravděpodobný. Ale nové kolo diskuzí o začlenění vypadá na spadnutí. Na kódu se tolik pracovalo - a je v něm tolik zajímavých nápadů - že se lidem nechce ho jen tak nechat vyšumět. Možná, že už bude brzy na cestě na dlouho očekávané místečko v jádře.
Jedna z postranních debat při diskuzích o plánovači se zabývala tím, že CFS způsobil problémy v nezačleněném kódu suspend2 (uspání na disk [suspend-to-disk]). Ingo Molnar podle zpráv o chybách našel a opravil chybu v CFS a na oplátku poslal posouzení suspend2, ve kterém zmiňuje, že celý ten patch vypadá rozumně, a ptá se, jestli je v plánu dostat suspend2 do jádra.
Ingo asi nedával pozor, když se o tématu v minulosti mluvilo. Jeho otázka byla hudbou pro uši autora suspend2 Nigela Cunninghama, který rychle odpověděl dlouhým dokumentem s důvody, proč suspend2 začlenit. Kromě jiného podotýká, že implementace softwarového uspání pro uživatelský prostor (uswsusp) za suspend2 stále zaostává ve funkčnosti. Je pravda, že o uswsusp v poslední době nebylo moc slyšet; poslední verze vyšla minulý listopad. Distributoři to moc nevyužívají. Pavel Machek však do diskuze přesto zasáhl: No, aktuální uswsusp kód umí skoro všechno co suspend2, s 20 % (nebo tak nějak) jaderného kódu.
Pokud jste před rokem sledovali debatu doprovázející začlenění uswsusp, možná si pamatujete, že se při té příležitosti mluvilo o tom, které funkce mohou být přesunuty z jádra do uživatelského prostoru. Mnoho vývojářů si myslelo, že funkce suspend-to-disk je možná na špatné straně hranice. Po této debatě se výrazně snížil počet návrhů na odstraňování funkcí z jádra. Pořád je to však citlivá záležitost, což ukazuje tato Linusova reakce:
Celá ta představa, že "řádky jaderného kódu" jsou nějak jiné, je stupidní a zhovadilá _nemoc_, kterou šíří lidé prosazující mikrojádra, nebo ti, komu vymyli mozek.
Později dodal trochu klidněji:
Proto nevěřím na počítání řádků jádra. Osobně jsem na sto procent přesvědčen, že je lepší mít desetkrát více řádků v jádře, pokud by to znamenalo, že bychom mohli zapomenout na potíže s verzemi, špatná rozhraní pro uživatelský prostor atd.
Tato diskuze by měla držet na uzdě budoucí projekty na přesun jaderného kódu do uživatelského prostoru. I když jsou situace, ve kterých má takový přesun smysl, také existují případy, u nichž by přenesení funkcí do uživatelského prostoru věci jen ztížilo. Přesto bychom neměli očekávat, že by někdy v brzké době mohlo dojít k začlenění nedávno představeného patche Kcli, který se snaží o zjednodušení přesunu celých aplikací do jádra.
A co suspend2? Je možné, že by obnovená diskuze mohla dát podnět k začlenění této dlouho připravované funkce. Suspend2 má nemalou uživatelskou komunitu, která by zařazení do hlavního jádra uvítala. Moc se však o tom nediskutovalo. Důvodem by mohlo být i to, že v současné době má hodně systémů funkční podporu uspání do RAM, takže už o uspání na disk není takový zájem jako dříve.
17.5.2007 07:12
DjAARA | skóre: 32
| Praha|Náklo|Olomouc
Chtělo by to vývojový cyklus trošku prodloužit nebo aspoň dávat pravidelně opravdu stabilní a odladěné verze.Jednu takovou verzi jádra nám dali -- aktuálně ve verzi
17.5.2007 01:13
2.6.16.51.
Diky tomuto serialu postupne ztracim iluze o linuxovem jadre...Je třeba si uvědomit, že mnohé z popisovaných věcí jsou experimenty a návrhy, ze kterých se může vyklubat něco dost odlišného - nebo také nic.
pokud X server považujeme za úlohu, která odvádí práci i další procesy
Tady chybí předložka za nebo pro.
1) Win98 2) Win2k 3) Debian 4.0 4) Ubuntu 7.04 5) OpenSuSE 10.2 6) Mandriva 2007 One
Nejedna se jen o stary notebook. Linux ma ambice ziskat take trh s PDA. Nebylo jadro rady 2.6 navrhovano s ohledem na vestavene systemy. Nekde se stala chyba, ani po vice nez 10 letech vyvoje neni Linux tam kde byly W2k pred lety... Mozna proto ty diskuze o novem planovaci. Timto nepopiram, ze jsou oblasti, kde ma Linux proti Windows naskok.
Jeste jsem zapomel napsat, ze jsem pozadoval praci v grafickem rezimu. Pri praci v textove konzoli by zrejme plne vyhovel i Debian, pripadne i jine Linuxy.Jak jsem psal už předtím, kdybys vybral některé z méně náročných desktopových prostředí (IceWM, Xfce) nebo jen správce oken, byla by situace jiná. Zrovna nedávno jsem instaloval čerstvý Debian unstable na počítač s Duronem 600 MHz a 128 MB RAM - dal jsem tam Fluxbox a běhá to jak divé.
A musim se ptat, proc je soucasny Linux ve srovnani s Win2k tak pomaly?Ehm... jestli to nebude tím, že srovnáváš systémy, které mají mezi sebou sedm let odstup. Zkoušel jsi instalovat nějakou distribuci, která byla nová v roce 2000?
Linux ma ambice ziskat take trh s PDA.A také získává. Je k tomu ovšem potřeba jádro při kompilaci optimalizovat (přinejmenším volba
EMBEDDED, ale je toho více). Copak myslíš, že by standardní instalace Win2k něco dokázala na PDA?
Nekde se stala chyba, ani po vice nez 10 letech vyvoje neni Linux tam kde byly W2k pred lety...Chyba se stalo v tvé podivné logice. Win2k současným linuxovým distribucím samozřejmě nesahají ani po kotníky, ale těžko můžeš požadovat, aby tyto moderní distribuce běžely stejně svižně na starém hardwaru. Co by se asi stalo, kdyby ses pokusil na ten notebook nainstalovat Windows Vista?
1.
Win2k současným linuxovým distribucím samozřejmě nesahají ani po kotníkyNo, tohle zas tak samozřejmé není.
2. S Pentiem II to chce samozřejmě povypínat žrouty výkonu a baterie - takže jako Windows 2000 - žádná průhlednost, neukazovat obsah okna při tažení a zvětšování/zmenšování, vypnout okení animace. Pokud běží nějaké indexovací stroje jako je Beagle, určitě odinstalovat. Mě ty KDE nepřijdou pomalé. Ale jiní lidé mohou mít jiné vnímání. V případě openSUSE dát pozor, aby nebyla nainstalována "enterprise správa systému (nebo to bylo softwaru)" - ta je žravá až hamba a na notebook (a desktop v domácnosti) se nehodí. Jestli se vám tam rachtají procesy jménem metadata_parsing, zmd, update_status, máte enterprise správu naistalovanou - pryč s ní. Moje Pentium II má většinu času procesor vytížený na míň jak 10-15%, takže samozřejmě procesor brzdu nepředstavuje (kromě filmů). Brzdou je jen swaping/thrashing když dojde RAM. Ale tamten notebook ji měl 192MB, o půlku víc.
V případě openSUSE dát pozor, aby nebyla nainstalována "enterprise správa systému (nebo to bylo softwaru)" - ta je žravá až hamba a na notebook (a desktop v domácnosti) se nehodí. Jestli se vám tam rachtají procesy jménem metadata_parsing, zmd, update_status, máte enterprise správu naistalovanou - pryč s ní.
A pak také beagle a všechno, co s ním souvisí.
Ehm... jestli to nebude tím, že srovnáváš systémy, které mají mezi sebou sedm let odstup. Zkoušel jsi instalovat nějakou distribuci, která byla nová v roce 2000?To je prave smutne. Linux mel 7 let aby dozral, dohnal a predehnal. (kecal jsem kdyz jsem psal, ze W2k jsou podporovany vice nez 10 let, tak stare nejsou, zatim jen cca 7 let). Nekdy mam pocit, ze uz dohnal, ale jen v nekterych oblastech (a navic zacina z Windows prebirat vlastnosti, ktere jim byly vycitany, zastira se to za "priblizovani beznym uzivatelum"). MDK9.x byla distribuce z obdobi kolem roku 2000 anebo 2001, a ta bezela na notebooku leta a byl jsem s ni celkem spokojen. Ale vzala za sve s diskem. A ma cenu instalovat si na notebook distribuci, ktera uz nebyla leta updatovana?
Jak jsem psal už předtím, kdybys vybral některé z méně náročných desktopových prostředí (IceWM, Xfce) nebo jen správce oken, byla by situace jiná.Je pravda ze MDK9.2 bezel s IceWM, ktery byl vyrazne rychlejsi nez KDE, ktere bylo hlavnim podporovanym manazerem v MDK. V Ubuntu neni velky rozdil mezi rychlosti IceWM a GNOME, takze GNOME jsem zatim ponechal, protoze nabizi vice funkci a mam jej i na stolnim PC. XFCE se mi nelibi, zda se mi, ze je to porad nevyzraly produkt.
Co by se asi stalo, kdyby ses pokusil na ten notebook nainstalovat Windows Vista?Otazka je, proc by jsme mel chtit si na stary notebook nainstalovat Windows Vista. Nemam tu potrebu, ve W2k spustim vetsinu aplikaci ktere potrebuji, MS stale (zatim) vydava bezpecnostni updaty. Vetsinu novych aplikaci na W2k stale nainstaluji. W2k API je leta zafixovano, MS uvolnil updaty pridavajici nove funkce (IE6, .NET, atd). Nejpopularnejsi OpenSource aplikace vznikaji dnes jak pro Linux, tak pro Windows (treba projekt OpenCD, www.theopencd.org). A to je prave dulezity rozdil proti Linuxu na starem hw. Aplikace stale nejsou vyzrale, ani nejnovejsi verze nemaji casto 100% funkcnost. Je treba updatovat (proto vznika nova verze distribuce nejmene 1x rocne). Nove aplikace maji nove pozadavky na API a pozaduji nove knihovny. Je treba stale updatovat. Pouzivat system, pro ktery nevychazi bezpecnostni zaplaty je sebevrazedne (proto nelze doporucit pouzit Linux distribuci z roku 2000, nebude jiz podporovana, muze mit bezpecnostni problemy). Nutnost neustaleho updatovani vedly ke vzniku dokonalaych nastroju pro spravu Linux distribuci, treba APT (tady ma MS stale co dotahovat...). Podobny problem trapi treba i zakladatele Mandrake Linuxu, take musel vymenit notebook (uz 2x!), protoze uz na nich nove Linux distribuce nebehali... :-| http://www.indidea.org/gael/blog/?p=16 Uvidime, zda si Geal na tento problem vzpomene pri vyvoji sveho noveho Ulteo Linuxu. Pokud by jsem se mel vsadit, tak bych si vsadil na "nevzpomene si". Spise bude pokracovat ve spirale, kde na provoz "stejnych" aplikaci potrebujeme stale silnejsi hardware. Jeste mam nekde ve skrini stary notebook s P233 MMX, 96MB RAM a W98, ale ten jsem uz prakticky odepsal, ktera moderni distribuce na nem pobezi, navic pri rozliseni 800x600? MDK 9.2 se jeste s trochou trpelivosti pouzit dal, ale ktera moderni distribuce je dnes kompilovana pro 5x86? Snad jen Debian, mozna i FC. Takze co se starym notebookem? Mozna ze by z nej sel udelat WiFi sniffer...
A to je prave dulezity rozdil proti Linuxu na starem hw. Aplikace stale nejsou vyzrale, ani nejnovejsi verze nemaji casto 100% funkcnost. Je treba updatovat (proto vznika nova verze distribuce nejmene 1x rocne). Nove aplikace maji nove pozadavky na API a pozaduji nove knihovny. Je treba stale updatovat.
To, že to většina uživatelů Windows nedělá, ještě neznamená, že tam to potřeba není.
MDK9.x byla distribuce z obdobi kolem roku 2000 anebo 2001, a ta bezela na notebooku leta a byl jsem s ni celkem spokojen.Tak proč se ti nelíbí, že na tom Mandriva 2007 běží pomalu? Je snad pochopitelné, že nová distribuce počítá s novým hardwarem. Stejně jako s novým hardwarem počítají nové Windows. Prostě je nesmysl srovnávat na starém počítači rychlost Win2k a letošních distribucí. Chceš-li tvrdit, jak je ten Linux oproti Windows špatný, tak srovnávej nové verze distribucí s novými Windows na novém hardwaru.
Protože bys poznal, že je to nesmysl - stejně jako snaha o instalaci nové distribuce Linuxu. Proč bys měl na starý notebook instalovat zbrusu novou linuxovou distribuci, když pro takový hardware není určena? Je blbost si stěžovat, že nové distribuce běží na starém hardwaru pomaleji než W2k, které jsou sedm let staré.Co by se asi stalo, kdyby ses pokusil na ten notebook nainstalovat Windows Vista?Otazka je, proc by jsme mel chtit si na stary notebook nainstalovat Windows Vista.
17.5.2007 23:10
Pavel Dobeš | skóre: 21
| Praha
Ale problem je jinde. Proc Win2000 jsou stale podporovane a spusti se na nich i moderni programy (nektere jiz ne) a linuxova distribuce z roku 2000 je jiz bez podpory. Nebo tak alespon ten 'stesk' chapu ja. Tip: Ja bych tam dal nejakou soucasnou (rozumej s podporou) distribuci zamerenou na starsi stroje. Urcite neco takoveho se najde, ale nebude to niz z tech znamych 5 mainstream distribuci.MDK9.x byla distribuce z obdobi kolem roku 2000 anebo 2001, a ta bezela na notebooku leta a byl jsem s ni celkem spokojen.Tak proč se ti nelíbí, že na tom Mandriva 2007 běží pomalu? Je snad pochopitelné, že nová distribuce počítá s novým hardwarem. Stejně jako s novým hardwarem počítají nové Windows. Prostě je nesmysl srovnávat na starém počítači rychlost Win2k a letošních distribucí. Chceš-li tvrdit, jak je ten Linux oproti Windows špatný, tak srovnávej nové verze distribucí s novými Windows na novém hardwaru.
Toto je trefa. Na stejnem HW je velmi vyrazny rozdil v behu stejnych aplikaci bud pod W2k anebo moderni distribuci Linuxu. Stejne aplikace, stejny HW, jiny OS, lze to snadno porovnat. Moderni aplikace mohu stale provozovat pod W2k, protoze OS ma stabilni API, ale pokud chci provozovat stejnou aplikaci pod Linuxem, musim mit moderni distribuci, protoze API prosla znacnym vyvojem.Které jsou to ty linuxové aplikace, které vyžadují nějaké nové API?
zmena kernelu znamena take preklad vsech souvisejicich programu v uzivatelskem prostoru.Dej nějaký příklad
/usr/include/linux nemá být link na hlavičkové soubory od aktuálně běžícího jádra, ale na hlavičkové soubory, s nimiž byla překládána (g)libc.
Protože bys poznal, že je to nesmysl - stejně jako snaha o instalaci nové distribuce Linuxu. Proč bys měl na starý notebook instalovat zbrusu novou linuxovou distribuci, když pro takový hardware není určena? Je blbost si stěžovat, že nové distribuce běží na starém hardwaru pomaleji než W2k, které jsou sedm let staré.Omyl, se vší úctou. Operační systém by snad vzhledem k aplikacím měl používat menšinu prostředků (já vím, s RAM je to většinou ošemetnější). Rozhodně třeba CPU by měl využívat minimálně (wtfxgl?), to patří aplikacím, a i ty by s ním neměly plýtvat jako třeba pitomý Flash kvůli každé nechtěné reklamě. Takže když se ohlídá rozumná hodnota a spotřeba RAM, není důvod, proč by distribuce neměla běžet na starším hardwaru; není to moc dobrá distribuce, nezvládne-li to.
Takže když se ohlídá rozumná hodnota a spotřeba RAM, není důvod, proč by distribuce neměla běžet na starším hardwaru; není to moc dobrá distribuce, nezvládne-li to.Což je přesně to, co jsem psal už v první odpovědi - stačí v těch nových distribucích nevyužívat náročná grafická prostředí jako Gnome nebo KDE (místo toho třeba IceWM nebo dále zmiňovaný Fluxbox) a můžeš je klidně nasadit i na starším hardwaru.
(a navic zacina z Windows prebirat vlastnosti, ktere jim byly vycitany, zastira se to za "priblizovani beznym uzivatelum")Jo, tohle me cas od casu nastve.
To je prave dulezity rozdil proti Linuxu na starem hw. Aplikace stale nejsou vyzrale, ani nejnovejsi verze nemaji casto 100% funkcnost. Je treba updatovat (proto vznika nova verze distribuce nejmene 1x rocne)To asi nelze zevseobecnovat. Klicove programy, ktere pouzivam, se za poslednich 5 let v podstate nezmenily.
XFCE se mi nelibi, zda se mi, ze je to porad nevyzraly produkt.Jo, na XFCE na noťasu pozor - jejich battery applet je permanentně aktivní (kolem 6-10% cpu na P-II), což s výdrží moc nepomůže. Můj názor je, že XFCE toho neumí zas o tolik víc, než IceWM (no, funguje mu čeština); a na druhou stranu, za cenu dalších řekněme 15-20MB ram můžu mít KDE. Proč? Protože pak můžu docela dobře chodit konquerorem na internet a mít při tom otevřený ještě třeba editor, xmms, konqueror/krusader na lokální procházení a konzoli. A pořád se to s těma 128MB RAM utáhne, i když ne jako na nejnovějším stroji. O co ale jde, že s firefoxem bych si neškrtl - ten vyžaduje podle mých zkušeností nejmíň 60 MB. Zato konqueror paměť sdílí a notebook to díky němu utáhne. Toť jenom moje upozornění k zažitému "moudru", že KDE je nenažrané.
Otazka je, proc by jsme mel chtit si na stary notebook nainstalovat Windows Vista.Ale v případě Linuxu očividně máte potřebu instalovat nové verze. A Linuxu vyčítáte, že si nevystačí se starým HW. To je dvojí metr. Chováte se jako byste byl nad věcí, ale nejste. Jediné oč vám jde, je vyvolat flamewar a těžko říct, čím jste motivován. ad. výkon: Uživatelé chtějí barevnější, průhlednější, lesklejší prostředí, aplikace s množstvím funkcí a nechtějí čekat na stabilní verze, chtějí to mít teď hned. Většinou si ještě na tom počítači pustí SuperKarambu a k tomu pro jistotu ještě gkrellm (tu se pak rodí zoufalci, kteří se tu ptají jak přenést vytížení z ramky na swap aby ji na těch grafech neměli pořád tak plnou) a další blbinky. Pak pláčou jak je to všechno hrozně pomalé. Slyším tady ty nářky na krátký vývojový cyklus jádra, ale stejně by to skončilo tak, že by nedočkavci kompilovali aktuální verze z repozitářů a stěžovali si na dlouhý vývojový cyklus jádra. Jó není na světě ten, kdo by se zavděčil všem. PS: Já mám ve skříni 486 s 40 MiB RAM a 400 MiB diskem a přesto dělám užitečnější věci než abych přemýšlel jak ho využít. Některé věci mají prostě svou životnost. Jo, a měl jsem tam Linux. Jako poslední to byl DeLi Linux a to je i má rada ... Slackware nebo distribuce z něj vycházející. A doufám, že pak nebudete všude rozhlašovat jaký je to KDE šmejd, když jeho poslední verze "láguje" na osm let starém železe.
...ale stejně by to skončilo tak, že by nedočkavci kompilovali aktuální verze z repozitářů a stěžovali si na dlouhý vývojový cyklus jádra.Vzhledem k tomuhle:
$ lspci 00:00.0 Host bridge: ATI Technologies Inc Unknown device 7910 00:02.0 PCI bridge: ATI Technologies Inc Unknown device 7913jsem docela rád, že často vychází nové a vcelku stabilní verze jádra a že nemusím překládat nic, co má v názvu rc1...
18.5.2007 01:26
michich | skóre: 51
| blog: ohrivane_parky
ad. výkon: Uživatelé chtějí barevnější, průhlednější, lesklejší prostředí, aplikace s množstvím funkcí a nechtějí čekat na stabilní verze, chtějí to mít teď hned.A vyvojari delaji tu chybu, ze jim nereknou NE.
Ad 2. Nevím jak vy, ale já mám teprve rok 2007… :-) (a za ten rok 1999 bych taky ruku do ohně nedal)
Ad 5. Procesorem to nebude, spíš je otázka, zda máte dost paměti na to, co tam chcete spouštět. OpenSuSE 10.2 jsem měl i na 600 MHz Duronu a nebyl v tom zásadní problém.
Dobry postreh, tady jsem se dost osklive prepocital..Ad 2. Nevím jak vy, ale já mám teprve rok 2007… :-) (a za ten rok 1999 bych taky ruku do ohně nedal)
W2k byly podle Wikipedie vydany az v Unoru 2000. Ale stejne, ktera Linux distribuce ma tak dlouho podporu? Ubuntu 6.04 LTS bude podporovana 5 let. Bezne je podpora vyrazne kratsi, pokud nechcete zustat bez podpory, musite upgradovat na novou verzi (opravy bezpecnostnich problemu, nove verze aplikaci). Nektere serverove distribuce budou mit podporu delsi, ale ty se na notebook nehodi. Upgrade na novou verzi znamena casto vyssi naroky na hw. Nekdy i dalsi prekvapeni (zamena /dev/hdx za /dev/sdx v Ubuntu 7.04; drobna zmena s velkym dopadem na funkcnost mnoha utilit).
Nejzajimavejsi na teto zmene je, ze stejne Ubuntu na starem notebooku stale pouziva /dev/hda, ale na stolnim PC uz jen /dev/sda (hda), /dev/sdb (hdc), /dev/sdc (hdd), /dev/sdd (USB ctecka), atd.Jde totiz o to, ze v jadre jsou pro mnoho PATA radicu dva ruzne drivery - stare (pouzivajici /dev/hd*) a nove (vyuzivajici SCSI vrstvu a tedy /dev/sd*). Je na uzivateli, ktere si vybere (pri kompilaci kernelu :–) ). V Ubuntu zrejme voli defaultne nove drivery, pokud jsou, jinak stare. Jinak pro nove rozhrani sice nefunguji utility urcene pro IDE disky, ale zato funguji utility urcene pro SCSI disky.
22.5.2007 16:52
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
Taky jsem si naběh. A kdyby jen jednou :-|
Ale stejne, ktera Linux distribuce ma tak dlouho podporu?
Enterprise verze ano. Také byste si měl uvědomit, že podpora pro distribuci je řádově komplexnější služba než podpora pro Windows. Se samotnými Windows nepořídíte skoro nic, běžná linuxová distribuce vám poskytne prakticky vše, co je k běžné (a často i neběžné) práci potřeba. A to se nebavím o kvalitě a včasnosti updatů…
balicky se staticky linkovanymi aplikacemi. K tomu svet Linuxu mozna smeruje.Doufám, že ne.
18.5.2007 10:47
stativ | skóre: 54
| blog: SlaNé roury
Suspend do RAM není vypnutí, na rozdíl od hibernace na disk - s kteroužto už můžete disk klidně vyndat, vyměnit zaseknutý větrák... Co já vím.Není už v takovém případě jednodušší a bezpečnější ten počítač vypnout?
Dalsi pripad jsou servery, kterym sluzby nabihaji nekolik (desitek) minut. Cas jsou penize.No, predstava, ze nejaky monitorovaci tool zahlasi "ALERT, netoci se vetrak", zahibernuje stroj a patricny dostatecne vyskoleny brigadnik vybehne ke stroji, provede vymenu a zmackne tlacitko POWER, to vse s reakcni dobou mensi nez je timeout TCP spojeni, mi prijde usmevna. Jak ti pomuze uspora par minut na boot, kdyz budes radove hodinu cekat na on-site servis?
21.5.2007 22:44
vlk | skóre: 23
| blog: u_vlka
On totiž na linuxu je suspend to ram srovnatelně pomalý - protože část uspávání/restartování služeb, modulů atd je společná - samotné zapisování dat na disk trvá tak 4 sekundy.
Asi dost záleží na množství a zaplnění paměti. Nezkoušel jsem to měřit přesně, ale u mne to trvá o dost déle než 4 sekundy… (sice nemám notebook, ale to je celkem jedno)
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.