Jak článek čtu, zdá se mi nadpis trošku zavádějící. Problém s jádrem 3.0 a 3.1 má pouze jedna konkrétní platforma, která prostě nefunguje dobře. Na výběr je potom buďto nestabilní systém nebo vysoká spotřeba. Není to tedy celé spíš vina Intelu? Podle mých zkušeností s kvalitou jejich ovladačů to je dost pravděpodobné.
Mne 5 rokov stary tablet Fujitsu drzi 2 hodiny, gentoo stable .39 kernel.
Ono to je skor tym ze v Ubuntu si to user nedokaze nastavit, kym vo widlach to ma zvycaune nastavene vyrobcom. Navyse linux v defaulte drzi teplotu na nejakeu konst. teplote, kym widle su tiche a ked hori, zrazu chvilu otrasne hucia kym sa neochladia.
Staci si precitat pover management guide vaseho distra a dostanete sa na lepsie levely, bezny user sa radseu stazuje alebo meni distro 2x tyzdenne (distro turizmus, zvacsa deti to zvyknu robit).
Svizne winxp na starom notase? mozna bez aktualizacii a nacisto preinstaluvavane, ale cokat minutu kym to nastartuje nemienim (niektory ludia tolko cakaje aj v linuxe, ale to je tiez o tum ze BFU ma root prava).
Takze ako AMD-ckar sa nemam coho bat? Aspon tak mi to zo zatial zverejnenych sprav vychadza.
http://www.intelinsideidiotoutside.com/images/intel_inside_idiot_outside1.jpg
alebo je to
http://cf.juggle-images.com/matte/white/280x280/idiot-inside-logo-primary.jpg
?
kW/h jsou jednotkou narustu vykonu/prikonu v case. Pro pouziti na poli Linuxu by se ale lepe hodila jednotka W/verze, ktera vyjadruje, o kolik vzrostla spotreba na verzi jadra. Z tohoto duvodu presli na nove cislovani, ktere snadneji umoznuje urcit inkrement verze jadra pro vypocet narustu prikonu.
P.S.: Vyvojari jadra jiz jednaji s hlavnimi dodavateli pocitacu s Linuxem a zadaji, aby vodni chlazeni bylo jejich standardni vybavou. Na noteboocich pak bude alespon nalepka s varovanim, ze notebook lze s Linuxem pouzivat pouze v lednicce ci jine mistnosti klimatizovane na 10°C a mene nebo za polarnim kruhem.
Je to tak. Sam jsem si tim prosel. Windows -> Linux a ted uz rok a pul pouzivam Mac OS X. Musim rict, ze na Linuxu me opravdu postupne odradila ta neustala potreba udrzby. A to jsem Linux pouzival temer 6 nebo 7 let. Pravda, asi polovinu te doby jako druhy system jenom pro vypocty a simulace.
Mac ma taky svoje mouchy, ale prijde mi to jako dobry kompromis mezi systemem s minimalni udrzbou a OS zalozenym na Unixu. Takze mam native verzi MS Office, kterou bohuzel potrebuju a zaroven terminal s bashem...
Je to skoda ze je Linux porad tak narocny na udrzbu, jinak by byl fajn.
Ano toto je typický vývoj - Win (škola atp.) -> nespokojenost -> Linux -> nespokojenost (chci, aby to fungovalo a ne abych si s tím musel pořád hrát, na hraní mám potomky, auto, motorku...) -> Mac OS X (ale popravdě, s tím taky moc spokojenej nejsem - MacPorts se mlátí s HomeBrew, ale některý věci jsou dosuptné jen v jednom resp. druhém zdroji, skryté finty jako defaultně boot do 32b kernelu "pro jistotu", o kterých větěina Mac userů rozhodně netuší, absence nativní podpory FS jako EXTx, NTFS a pod. a s tím související nízká míra (nebo aspoň komplikace jako nutnost použití 32bit jádra) přenositelnosti dat na USB discích mezi platformami)... Mám trochu strach, že řešením bude něco jako "zpátky na stromy", ale v méně radikálním způsobem, nebo přechod na "HTTP based technologie", kde od OS nebudeme chtít nic než bezpečnost, stabilitu, rychlost, úsportnost a ze služeb pouze WEB klienta s Javou, flashem, video/audio kodeky, a to bude vše.
Muj vývoj je podobný. Zůstal jsem ale ve fázi Win7-Pro+Cygwin. Zatím spokojenost. Vývojové věci mi běží ve virtuálech, takže to málo, co nejede v Cygwin mám tam.
A je to rychlé! Zkuste editovat v OpenOffice Impressu komplexní prezentaci.
To co jsem dělal dřív za vyvinutí velkého úsilí, teď mám za pár minut hotové. Ano, jsou to mnohdy typické kancelářské úkony. Ale i když potřebuju něco víc, mám bash, awk, perl, sed, python, cokoliv z Cygwin. Jádro Linuxu vybootěné opravdu nepotřebuju, to mojí práci samo osobě neurychlí.
Před touto změnou jsem byl deset let (skoro) výhradně na Unixech (Linux, OpenBSD, FreeBSD) a pobaveně jsem sledoval tápající uživatele MS produktů. Mezitím se to ale MS naučil a Win7 jsou dobrý a rychlý desktop systém. Linux se ale spíše na desktopu zhoršuje... mrzí mě to a to dost. Ale, taková je realita.
Doslova už mě drtí samodestruktivní snaha zásadně měnit Linuxí desktop každým vývojovým cyklem. Tohle prostě už nechci řešit. Nejsem proti zábavě a změnám, ale musí to být spolehlivé a konzistentní. Debakl s KDE 4 teď korunuje Canonical s Unity. A na ohýbání Lubuntu nemám čas.
Spotřeba je jen třešínkou na dortíku. Někdo tady hlásil, že se to týká "jen" Sandy Bridge. JEN? To je přece drtivá většina nových notebooků. Takže JEN není na místě.
KDE jsem dlouho nezkoušel. To proto, že nemám čas si s tím pořád hrát. Zkoušel jsem naposledy 4.1. Možná to byl skutečně rok 2008.
Navíc, byl to jen příklad, jak se vývojový tým vykašle na svou současnou uživatelskou základnu a pošle je do háje. Pro jejich dobro, že.
Ale to jste se chytil opravdu na nepodstatnou část toho, co jsem chtěl mým příspěvkem sdělit.
Zachrani, jen co bude dokoncena 128 bitova architektura a budou k dispozici 64 jadrove spotrebitelske mikroprocesory, pametove moduly o kapacite 1TB a nova opticka sbernice, pracujici rychlosti svetla. To ovsem bude minimalni konfigurace. Opravdu rychle (az 2x rychlejsi, nez ZX Spectrum) budou Windows 9 az na kvantovych pocitacich.
Nejvtipnější na tom je, že kdyby se to stalo, tak to přežije celý dnešní linuxový ekosystém, a protilinuxoví fanatici zpláčou nad vejdělkem.
Každá komponenta je nahraditelná.
Nicméně si nemyslím, že by se v nejbližší době linux nahrazoval něčím novým, a to z důvodu, že jádro samotné je docela velké. Spíš si myslím, že se bude pokračovat jako dosud, tedy vylepšováním, zahazováním a znovuprogramováním jen některých částí.
Jojo, za našich mladých let... I tráva byla zelenější ;-)
Naříkání na jádro ještě pochopím, i když takový nadpis to celkem zveličuje. Ale třeba Gnome 3 a Unity (mimochodem, není až tak špatné) nemusíte používat (Gnome 2 forknuto). I systemd a pusleaudio nevím, o co jde. (Možná to je i tím, že mám OpenRC.)
ale kde na to brat cas :)
hrabat se v supliku a hledat "vydlicky" votviraky a nakonec zjistit, ze konzervu stejne vydlickou nevotevru, tedy mozna, ale to me driv prejde hlad.
Toliko mala metafora.
V posledni dobe je instalace / udrzba a provoz Linuxu cim dal tim vetsi "prdel" a zrout casu.
Trava uz zelenejsi nebude a na desktop uz s Linuxem prdim :) Proste za tech 11 let skromneho uzivani Linuxu se situace ne a ne zmenit k lepsimu...
Zaplat panbuh, ze na serverech nejake GUI a podobne sracicky resit nemusim.
To zalezi na tom, cemu rikate "k lepsimu". Velke mnozstvi distribuci se snazi byt co nejjednodussi. Sprava systemu je pritom vetsinou velmi jednoducha a rychla. Zalezi tedy na uhlu pohledu.
Ja osobne si myslim ze se Linux za 11 let dostal docela daleko, ackoliv nepopiram ze nektere veci, jako napriklad PulseAudio, jsou skutecne neco strasneho.
Takze pulseaudio je strasne ? A to proc pak? Dva dny sem se sr*l s Alsou ale nedokazal sem ji prinutit aby po nakem nahodnem casovem intervale neprestala fungovat. Po tomhle krasnem zazitku s uzasnou alsou sem velmi rychle prehodnotil svuj postoj k tomu smrdutému pulse. Pak stacilo alsu smaznout, nahodit pulse, k tomu pavucontrol, napsat pulseaudio --start a konec, vsechno funguje tak jak ma. Za par minut. Ne jak alsa co nedokaze ani pouzivat reprak kterej neni pri startu systemu zapnutej, ktera si casto zmysli ze neobnovi nastavene hodnoty (pritom vsechny kroky k tomu aby se to nedelo mate), ktera se tvari ze funguje/nefunguje...
Takze tyhle zvasty z roku 0 si nechte.
PulseAudio je super protoze proste funguje.. ale to je asi ve filozofii bezneho linuxaka neco neakceptovatelneho ze.
"Zarážející především je, že nikdo neřeší starší problémy, které už byly objeveny a vysvětleny, a přesto jsou stále součástí nových vydání. "
Autore, kdybys vyvynul naprosto minimalni usili, tak bys zjistil ze chyba neni v jadre, ale u vyrobcu HW - nebot maji spatne implementovanou podporu vsemoznych setricich rezimu a neumi spravne (dle normy) systemu oznamit jejich podporu. No a jelikoz defaultni zapnuti vedlo k padum na systemech, ktery to neumej, tak je default off a zapne se to jen na systemech, ktery podporu korektne oznami.
Dtto novy problem v rade 3.x - vylucne problem ovladacu, nikoli kernelu.
1. Zdaleka není jasné, jestli je to problém výrobce HW. 2. Dřívější verze jádra měly nižší spotřebu, takže tomu autoři kódu asi moc nepomohli.
Navíc se domnívám, že se začíná projevovat vývoj jádra připomínající extrémní programování, stejně jako jeho nevhodný návrh. Údržba se stává čím dál složitější, problémy se kumulují, opravy se nestíhají, testování chybí nebo je odfláknuté.
1. Je to dost jasné přinejmenším u naprosté většiny těchto problémů. Na hardware dodržujícím alespoň ACPI se tento problém neprojevuje.
2. Dřívější verze jádra měly problémy na HW, který v ACPI správně hlásil, že dané stavy nepodporuje. Současné verze tuhle jasnou chybu na straně jádra opravily (mimochodem daný HW podle mých informací ve Windows právě kvůli této chybě nefunguje), ale tím se tyto stavy přestaly používat na HW, který hlásí, že dané stavy nepodporuje, i když je podporuje (chyba je tedy tentokrát na straně HW).
To mluvíte o Windows, že? :)
1. Minimálně u některých těch problémů není jasné jejich pozadí. Prostě je jen zjištěno, že verze X měla nižší spotřebu, a verze Y ji má vyšší.
2. HW je jaký je. Systém A dovede na tom HW běžet X hodin, systém B běží X/2 hodiny. Řekl bych, že to má vliv na rozhodování zákazníka, ale moc tomu nevěřím. Je to velký opruz pro všechny uživatele Linuxu. HW změnit nemůžete. SW ano.
Ne, to mluvím o Linuxu.
Ale autor jadra nemuze tusit ze HW neco umi, kdyz mu hlasi ze to neumi, pripadne kdyz mu ohlasi chujoviny. To by leda musel identifikovat kazdy konkretni kus HW a prikladat par GB databazi ve ktery se bude zjistovat, co ze to vlastne tenhle kram umi nebo neumi. Vubec nemluve o tom, ze (velmi casto) nelze SW odlisit ruzne revize tehoz HW, pricemz rozdil ve funkcionalite muze byt zcela zasadni.
A i blb jako ses ty by moh zaguglit a zjistil by, ze kernel se testuje na spouste HW nez je zarazen do distribuci.
"identifikovat kazdy konkretni kus HW a prikladat par GB databazi ve ktery se bude zjistovat, co ze to vlastne tenhle kram umi nebo neumi" - trochu neuměle napsané, ale takhle nějak vypadají drivery :). Akorát ve Windows na to stačí jednotky GB.
Nicméně i prudce elegantní génius vašeho ražení by mohl zjistit, že to testování je naproto nedostatečné.
Tesi mne, ze soudruzi s Redmondu maji vse o tolik lepe testovane. Presvedcil jsem se o tom pred par hodinami, kdyz jsem nekomu flashoval Mio A701 z holandstiny na anglictinu. Nainstaloval jsem z Microsoftu cerstvy Active Sync a po preflashovani jsem zjistil, ze nemam konektivitu na Internet. Jo, staci akorat pustit regedit a dodelat tam jeden DWORD, na ktery soudruzi zapomneli. Great user experience. Better and better with each version of Windoze. Uz vidim typickeho BFU, jako ta zenska, ktere jsem to flashoval, jak tohle resi.
Jestli tam je zaskrtavatko si uz nepamatuji a jsem ted v Linuxu. Nicmene budte klidny, menu jsem si cele prolezl a je tam stara bela, z nej to nerozchodite. Nebo je to zaskrtavatko dobre utajene a objevi se pouze po stisku magicke kombinace Ctrl-Alt-Shift-PrtSc-B-F-U. Musite zasahovat v registry. Vy uz asi nemate W XP, takze se vas problemy posledniho Active Sync pro XP netykaji. Nicmene se tykaji jeste spousty uzivatelu a MS tam s klidem nechava download s chybou.
Neni uplne snadne rozpoznat HW. Treba ted mam na stole dve externi zvukove karty pro USB. Obe se v Linuxu hlasi uplne stejne (lsusb -v), jako "0d8c:0102 C-Media CM106 like", ale pritom jsou to jine krabicky; jedna je 5+1 a ma dve tlacitka na ovladani hlasitosti, druha je 7+1 OPTICAL a nema zadne tlaciko, ale ma SPDIF-IN a SPDIF-OUT konektory. Skutecne, v Linuxu nepoznam rozdil. Ve Windows obe zvladne stejny driver; SPDIF se ve Windows aktivuje v options (to znamena, ze ani Windows nedokazi detekovat zda konektory pro optiku jsou pritomny). Ze driver funguje lepe v WinXP asi zduraznovat nemusim (ve WinXP je mozna i virtual 5+1, SW emulace prostorovych reporoduktoru v klasice stere konfiguraci, kde se detailne nastavuje prostorove rozmisteni reproduktoru a posluchace); v Linuxu funguje jen zaklad, jen stereo konfigurace...
Nektery HW lze snadno rozpoznat, u jineho se pod stejnym ID muze ukryvat nekolik ruznych konfiguraci.
Kdyz uz jsem nakousl ten CM106 like HW, tak obe krabicky zrejme obsahuji chip C-Media CM6206, ktery je velmi flexibilni a umi az 8 CH DAC a 2 CH ADC a user GPIO (pro tlacitka pro prepinani konfiguraci, ovladani hlasitosti, mute, atd).
Technicke detaily chipu a obrazky moznych (doporucenych?) konfiguraci.
http://www.cmedia.com.tw/ProductsDetail.aspx?C1Serno=2&C2Serno=2&C3Serno=4&PSerno=23
USB zvukovky obvykle dodržují standard usb audio, kterým zařízení sděluje své parametry, počty kanálů, podporované formáty atd. Tlačítka na hlasitost jsou implementované jako další usb zařízení - HID, posílá to standardní klávesy vol+, vol-. GUI distribuce to běžně mají namapované na regulaci hlasitosti.
Více kanálů - zřejmě používáš pulseaudio a to asi defaultně nabízí stereo zařízení. Kdyby ses podíval do alsy, určitě bude uvádět u počtu kanálů daného zařízení správné číslo. Mám taky jednoduchou 5.1 USB zvukovku a hlavní zařízení (hw:X.0) má automaticky 6 kanálů.
Tvoje konkrétní viz http://mailman.alsa-project.org/pipermail/alsa-devel/2008-June/008324.html
SPDIF-in/ext - to bude jeden z těch "čudlíků" v lsusb, jenom se neví, který. Cituji alsu - je to nezdokumentované:
/*
* C-Media CM6206 is based on CM106 with two additional
* registers that are not documented in the data sheet.
* Values here are chosen based on sniffing USB traffic
* under Windows.
*/
Takže by se to asi muselo vyzjistit. V jednom z commitů změnou jednoho z těch registrů vypínají de-emphasis, takže to tam někde asi bude.
Horší jsou PCI zařízení, která mají stejná vendor i device ID. Tam žádná další identifikace funkcí není. Existují i takové zvukovky, jednu takovou mám doma. Tam nepomůže nic jiného, než snad parametr modulu.
Samozřejmě ve win se nainstaluje ovladač přímo od výrobce a OK. Kdyby se použil ten od té druhé, ovladač to akceptuje (je stejný identifikátor), ale chodit to nebude úplně stejně. Jenže v linuxu to díky uživatelsky příjemné autodetekci ovladačů logicky nezafunguje. Přitom by stačilo, kdyby výrobce nebyl čuně a použil jiné PCI ID.
"Je to velký opruz pro všechny uživatele Linuxu."
Existuje alespoň jeden uživatel Linuxu, pro kterého to není velký opruz.
"HW změnit nemůžete. SW ano."
Ale můžu. Pokud si koupím křáp, který nedodržuje standardy, radši ho prodám někomu, kdo na něm bude spokojeně provozovat Windows, a koupím si něco, na čem budu spokojeně provozovat Linux, než abych se páral na oknech s pomalým Cygwinem apod. a stejně nedosáhl svého komfortu.
Bohuzel ale neexistuje zadna centralni databaze, kde by se clovek docetl, jakemu HW se vyhnou a jaky celkem chodi (zcela bezchybny asi neexistuje). Clovek se lecos docte na forech, ale tam treba nic neni o novem HW a je nutno pockat, az si to par nestastniku odskace a napisi o tom. A vyrobci sami se k tomu radsi nepriznavaji, alespon jsem jeste nikdy na nicem nevidel nalepku od vyrobce: "Bacha, blby HW".
To si pletete dvě věci.
Jedna věc je MS specifikace (například Designed for Windows 7) sestavená spolu s výrobci HW, která popisuje, co musí počítač umět. MS má navíc certifikační testy, které dlouhou dobu různě trápí HW a drivery. Když se produkt shoduje se specifikací a projde testy, dostane tu nálepku.
Druhá věc je webová site, na které uživatelé sdílí svoje zkušenosti s konkrétním HW. Franta tam napíše "jo, ta tiskárna mi funguje", a Jarda napíše "jo, ten notebook funguje, jen jsem musel udělat to a to". Bohužel Franta ani Jarda nejsou testeři, a zkusili naprosté minimum funkcí, a i to zpravidla jen na jedné verzi jednoho distra. Výsledek? Vyberete si podle takové site WiFi kartu s dobrými referencemi (v mém případě to byl Atheros). Doma zjistíte, že autentizace WPA-PSK nefunguje, AdHoc mode a jiné "advanced" features nefungují, počítač vždy na chvíli vytuhne při připojování k WiFi, a občas ztuhne úplně. Pak strávíte spoustu hodin zkoušením a kompilací devel verze madwifi, abyste nakonec horko těžko rozchodil alespoň ty úplně nejnutnější věci. Kdo z uživatelů Linuxu nemá takovou zkušenost?
No moc casu na analyzu tech linku jsem nemel a jiz z letmeho pohledu jsem tusil, ze to neni to prave orechove. Ty linky jsou "only users experience", takze z tohoto uhlu - souhlas. To vite komunita je komunita, je prave takova, protoze ji buduji jedinci (nekdy je to hold boj s vetrnymi mlyny).
No, vite, ono to u Widli take neni takova slava. Spousta HW certifikovana neni a clovek leckdy je rad, ze sezene neco, co se aspon podoba tomu, co byc chtel. A spousta veci chodi za cenu, ze v driveru je povypinana polovina funkci, takovyhle zabugovany HW je na howno a vyrobci jsou zlocinci. Na Linux pak nekdo napise driver podle jejich specifikaci, ve kterych se nepriznaji, co zmrsili a muselo se vypnout, aby to na Widlich jelo a pak se to hazi na triku Linuxu.
Kvalitní HW naopak certifikovaný bývá. Pokud výrobce necertifikuje, často to bývá proto, že by jeho HW neměl šanci testy projít. Čechům samozřejmě záleží na prvním místě na ceně (viz i oblíbené špekáčky vyrobené ze soji, sádla, kůží a glutamátu), takže často kupují mizerný HW.
Zajímavý je váš popis problému: "na Linux pak nekdo napise driver podle jejich specifikaci, ve kterych se nepriznaji, co zmrsili a muselo se vypnout, aby to na Widlich jelo a pak se to hazi na triku Linuxu". Popisujete totiž problém generických driverů. Drivery se běžně nepíšou na základě dokumentace čipu, ale dokumentace konkrétního zařízení. Ten samý čip může být v různých zařízeních použit různým způsobem, některé části nevyužity, něco použito specificky, jiná věc přidána. Když to přirovnáme k tiskárně, tak nestačí vědět, že umí PCL5. Potřebujete vědět jestli je barevná, jaké má zásobníky, podavače, a řadu dalších věcí (třeba že má vestavenou sešívačku). Příkladem z reálného světa je SANE. Spousta zařízení se statusem "good" produkuje zubaté obrázky, má silně rozhozenou gamu, nejdou některá rozlišení atd.
Podle vás je to zabugovaný HW a zločin výrobců. Podle mě jsou to "specifika" driverů pro Linux, kdy vývojář v řadě případů neví nic o konkrétním zařízení, pro které driver píše (a ani to zařízení osobně nemá).
Nemluvim o psani driveru psanych podle dokumentace k cipu, ale o psani driveru podle dokumentace zarizeni. A pokud vim, problemy byly i s SCSI radici od Adaptecu, kde by clovek cekal trochu kvalitu. Problemy byly dvojiho druhu. 1, v driverech pro Widle byly obchazeny nektere funkce, ktere zpusobovaly potize. To v dokumentaci nebylo a bylo to zjisteno az rozebranim driveru pro Widle. 2, Linux, protoze porad nekde nespi, zatizil HW do takove miry, ze tento spadl. Na Widlich s tim problemy nebyly, protoze Widle jsou line a nedokazi sypat data takovou rychlosti, ktera by problem vyvolala.
Madwifi drivery jsou silenost. Teoreticky umi veci, ktere by bylo pekne mit i na jinych kartach, treba se z nich da udelat acces point, coz obvykle jinde nejde. Otazka ale je, jak dlouho to pobezi, nez vznikne kernel panic. To jste si pekne blbe vybral. Kupte si nejakou blbou wifiny z ebaye s chipem Zydas ZD1211. Stoji par supu a celkem dobre funguji. Maji slusnou citlivost a existuji i s antenkou. TP-Link take nejake dela, i s antenkou.
Ale to by jste si nemohl koupit temer nic, protoze 90% HW ma nalepku "Designed for Windows". Zbylych 10% ma nalepku "Designed for MacOS", pripadne obe nalepky.
Pokud kupujete HW pro Linux, kupte to nejlevnejsi, pripadne nejaky stary HW na srotaku. Rozdil mezi noname HW a znackovym HW byva zpravidla jen v kvalite dodavanych ovladacu a proc by jste si mel priplacet za neco co nepotrebujete (podobne jako PC s Windows anebo bez OS). U stareho HW je zase vyssi sance, ze driver uz bude v Linuxu.
Porad cekam, kdy se konecne uz objevi HW s nalepku "designed for Ubuntu"... ;-)
OK, fair enough :)
Bylo to myšleno tak, že vlastnosti konkrétního HW nezměníte, protože je to HW. Naopak vlastnosti SW lze změnit. V případě open source dokonce dost snadno. A že to jde udělat lépe dokládají i starší verze kernelu.
V oblasti PC neexistují žádné závazné standardy. Existuje jen řada nezávazných doporučení produkovaných sdruženími firem. Seriózní výrobci platformy, jako je MS, provádějí rozsáhlé testy vlastností HW. Svět Linuxu je bohužel světem chaosu, extrémního programování (aka bordelu), chybějícího testování, nedostatku zdrojů atd.
<quote>A že to jde udělat lépe dokládají i starší verze kernelu.</quote>
Tak ještě jednou, třeba ti to tentokrát dojde: se starší verzí jádra byla sice nižší spotřeba, ale za cenu pádů/tuhnutí celýho systému. Procento postižených bylo zřejmě o dost menší, ale přesto to není chování, který by mělo v jádře zůstat. To by mohl pochopit snad i takovej odborník na seriózní výrobce a testování jako jseš ty.
Neříká nic o příčíně? Pokud vím, tak Phoronixem identifikovanej patch, kvůli kterýmu vzrostla spotřeba, řešil tyhle tuhnutí a pády systému. Já chápu, že se ti skvěle hodí do krámu tohle neuznat (protože pak ti oba případy dokazují, že vývojáři jádra jsou idioti a jádro se netestuje), ale pak nemá tahle diskuse už vůbec žádnej smysl.
Pokud správně čtu, tak Michael Larabel identifikoval jen dva problémy (jeden s ASPM a druhý s ovladačem i915). V obou případech pouze označil patche, které způsobují nárůst spotřeby. Oba patche řešily pády a tuhnutí systému tím, že za jistých okolností zakázaly část power managementu. Příčinu vlastních pádů a tuhnutí na systému bez těch patchů Larabel neřešil, a komplexní opravu (tedy funkční power management a zároveň netuhnutí systému, což zjevně je možné) neumí nabídnout. Navíc sám psal, že jím popsané problémy nevysvětlují *celý* nárůst spotřeby.
Nakonec čtvrtý odstavec článku říká: "Nejenže se na opravě chyb nepracuje, ale další přibývají a dostávají se k uživatelům společně s novými verzemi jader."
Když jsme u testování: pokud máte HW otestovaný, můžete na základě identifikace stroje provést konfigurační kroky. Například i915.i915_enable_rc6=1 může být výchozí, ale pokud je známo, že daný model HW s i915 způsobuje tuhnutí, můžete parametr nastavit na nulu. Pak stačí sestavit databázi modelů HW, známých bugů, a vytvořit utilitu, která přepíše konfiguraci vašeho stroje tak, aby měl co nejnižší spotřebu a zároveň netuhnul. Samozřejmě by bylo daleko praktičtější napsat kód tak, aby taková DB nemusela existovat. Podle všeho to ale není vždy možné, a DB HW se nakonec nevyhnete (ve Windows to řeší drivery).
Shrnuto: jsou cesty, jak problém řešit. Jenže nejsou zdroje, případně není zájem.
Jak jsem už psal, v oblasti HW neexistují závazné standardy. Právě ty specifikace "Designed for Windows" a jejich certifikace jsou dobrovolnou standardizací.
Je ale roztomilé, že když na Linuxu něco nejde, může za to někdo jiný. Když něco jde ve starším jádru a nejde v novějším, také za to může někdo jiný, i když příčina ještě není známá.
Nálepky asi nejsou, ale certifikace ano. Bohužel výrobci dister Linuxu testují málo HW, testy jsou nejspíš povrchní, výsledky se vztahují jen na jednu verzi jednoho distra, a ještě se člověk dočte perličky typu "Standard images of Ubuntu may not work at all on the system or may not work well".
http://www.ubuntu.com/certification/
Závazné standardy neexistují prakticky vůbec a stejně jste určitě rád, když doma máte standardní elektrické zásuvky (a ne německé, které jsou velmi podobné, ale ne plně kompatibilní) a na webu je většinou standardní HTML (a ne zmršenina od IE nebo Netscape), ne? A když někdo něco dodá jako-standardní, ale ve skutečnosti nestandardní (třeba zmiňovaný Asus a ACPI), asi byste ho hnal. Bohužel, u HW si to výrobci troufají velmi často a reklamace je dost problematická; nakonec asi peníze dostanete zpět, ale od koho kupovat, abyste měl jistotu, že to bude tak, jak výrobce napíše?
No tak zrovna v oblasti elektrických spotřebičů je předpisů dlouhá řada, a na webu je naopak obrovská spousta nevalidních stránek.
Výrobci HW vyrábějí jak vyrábějí. Těžko s tím dělat něco jiného, než nějak certifikovat, že HW má deklarované funkce. O tom je certifikace Designed for Windows. MS samozřejmě testuje jen to, co je pro něj relevantní. Canonical zase testuje co je relevantní pro něj (plus testuje málo).
Co vím, tak výrobci to nemerší naschvál, ale kvůli své neschopnosti. Udělají to tak, že to jakž takž funguje ve Windows, a když to nefunguje, tak dodají vlastní proprietární ovladač, který to opraví (viz notebooky Asus a jejich občasná náhrada binárních čísel v DSDT za BCD). Anebo to prostě nefunguje ani ve Windows a oficiální workaround je vypnout a zapnout (opět viz některé notebooky od Asusu).
Ja čo som sa dočítal, tak na Widlách je ACPI rozbité roky a výrobcovia HW to ladia štýlom Widle idú predávame. Linux sa drží štandardov a preto to niekedy nefunguje dobre. Asus je kapitola sama o sebe a verím že pre Widle bastlia nejaké drajvre, aby opravili svoje chyby, čo pre Linux určite nerobia. Na Ábičku vyšiel pekný článok ako na úsporu energie cez User Space.
Celkovo článok je mätúci, pretože sa píše o zvýšení výkonu, ktorý samozrejme nieje perpetuum mobile a musí sa to prejaviť na spotrebe, poďalšie ide len o jeden HW a čo ma úplne naštvalo, že o AMD tam nieje ani riadok.
Nadpis je úplne mätúci, pretože ide o chybu s čípmi Sandy Bridge a nie Linux celkovo, takýto bulvár sem nepatrí.
Tak já nevím, ale mě se tenhle neduh neprojevuje zatím nikde. Na jednom desktopu, kvůli zmršenému BIOSu nejde uspání do paměti (nefungovalo řádně ani na W) a na jednom notebooku nefungovala hibernace, což opravil update jádra.
Bohužel na nějaké zlepšení se asi spoléhat nedá, protože na straně jedné je standard ACPI a na straně druhé je zmršený power managment ve W7 a co jsem viděl W8, tak tam je to dodrbané úplně.
Takže buď budou výrobci dodržovat ACPI nebo budou BIOS/EFI uzpůsobovat dodrbanému OS Windows. Linux by musel mít tak 20-30% podílu aby s tím výrobci něco dělali, stejně jako ty ohnuté standardy pěkně zatopily IE6 a 7, když se začal rozšiřovat FF
Vypada to ze ano - nerobil som sice nijake specialne testy, ale po prejdeni na 3.0 kernel mi nejako chyba hodina vydrze na baterku. Popravde v klude to moze byt sposobene i vysokymi teplotami momentalne - takze vetracin na procesori sa toci o cosi vyse.
Este absolutne hodnoty - predtym bola vydrz cca 8 hodin momentalne sa dostavam okolo 6:45 az 7. Nieje to zle - je to furt podstatne vyse ako v MS systeme (ten ma mozno dobre ovladace ale GB ram mu je zalostne malo).
Isty prepad tam momentalne je, uvidim ked skoncia tropicke horka.
pouzivam debian na sandy bridge s inegrovanou grafikou a asi takhle:
stable 2.6.32 moc stare jadro, vic veci nefunguje korektne, hlavne sit, nepouzivam. vyvojari do nej backportuji novsi hardware, uvidime v 6.0.3. vydrz na baterku nemelo cenu zjistovat.
backport 2.6.38, uz to jakz takz funguje, ale hlavne stabilita X-ek po uspani do pameti a na disk rozhodla, ze to neni to prave orechove. vydrz na baterku nemelo cenu zjistovat
poprve jsem zacal pouzivat testing:
2.6.39 vse funguje skoro jak ma, jen obcas pri pripojenem externim monitoru to nedaji x-ka pri probuzeni. vydrz na baterku cca 6h.
3.0, po rebootnuti sel pri nic nedelani s vetracku teplejsi vzduch. porovnanim aktualne neuplne nabite baterky:
3.0 3,5h vs 2.6.39 5,5h > jasny propad jak svina.
z testingu jadro 2.6.39 zmizelo do backportu a protoze jsem jeste nemel natahane balicky na vlastni kompilaci, tak jsem se vratil ke stable s repozitari backport a testing.
pro srovnani pri baterce na 95%, w7 vydrzi pri nic nedelani s vypnutou wifi cca 9,5h. pri brouzdani a zapnute wifi cca 8h, takze 6h s 2.6.39 jde, ale dalsi propad uz ne.
pri nejake prilezitosti, az budu mit na kompu i 3.0 jadro zkusim ten parametr pro grafiku. uspavani sbernice, ten prvni problem se u mne neprojevuje a pocitac bezi korektne. defakto jsem nejaky takovy clanek cekal. ale ze dalsim vynikem bude grafika ne. kor kdyz si ji vetsina lidi porizuje, aby energii setrila, kdyz 3d nepotrebuji.
už asi idem s krížkom po funuse, ale Intel® Core™ i5-2520M Processor nie je štvorjadrový procesor,
takže celý článok je taký ...
http://ark.intel.com/products/52229?wapkw=2520m