Názory k článku
Linux se bude probouzet a usínat rychlejí
-
karel zeman (neregistrovaný)
Je to grafickými kartami. Problémy mám jenom s proprietárními ovladači. Intel a radeon se uspávají a probouzí spolehlivě nvidia nevím. Třeba v práci uspávám intel každý den a ještě se mi nestalo, že by se neprobudil.
Druhý důvod jsou distribuce s rolling updates, kde se rozbíjí čas od času všechno. S tím ale jejich uživatelé počítají.
-
Petr Ježek (neregistrovaný)
Já na Archu nemám dlouho žádný problém, natož ten s uspáváním/buzením. Stačí systemctl suspend/hybernate v oblogoutu, vlastní v LXDE, MATE a E18 fungují taktéž spolehlivě. Desktop na radeonu, thinkpad na intelu... Račte si laskavě pořádně nastavit kompy a neotírejte se o rolling distra.
-
sw (neregistrovaný)
Mno, tak já mám třeba taky Arch (už asi dva roky) a konkrétně po jednom update mi probouzení fungovat přestalo. Oprava se objevila asi za dva měsíce. Na Archu se tyhle věci dít můžou. Zatím mne naštěstí nepotkal žádný fatál a děje se to zřídka, ale tvářit se, že u rolling tohle nebezpečí nehrozí, je pokrytectví.
-
Tohle vam hrozi i u Ubuntu LTS. Za posledni roky jsem narazil na par problemu, ktere mizely a vracely se. Nejednalo se o zadnou tragedii, nicmene to neni to, co by melo. Vybavuji si napriklad ecryptfs, kdy puvodne v nejakem ubuntu 9.x pri uspani byl adresar Private odmontoval. Pak v naslednem LTS to nejdrive snad chodilo, pak se odmontovavat prestal, pak zase zacal. Ted momentalne se odmontovava. Podivnosti by se naslo vic. Nikde neni receno, ze nejaky update neposere neco zavazneho. Navic, konkretne s Ubuntu, to vypada tak, ze kdyz se neco updatem posere, vydrzi to tam az do dalsiho LTS. Xsane mi porad blbne, i kdyz chodilo bez problemu. V nejake jinem Ubuntu zase vesele prezivaly pluginy nespravne verze pro Claws Mail....
-
Lael Ophir (neregistrovaný)
Ono těch důvodů bude víc. Určitě jsou částí problému různé špinavé hacky, kterými je Linux prolezlý, a drivery zvlášť (vizte bricknutí notebooků Samsung, bricknutí síťovek Intel, bricknutí mechanik LG atd). A implementace ACPI také mají svoje problémy.
Řešení je jasné: důsledně testovat Linux na skutečném HW, a spolupráce s výrobci. Jenže na to první nejsou zdroje. To druhé je zase obtížné, protože uživatelů Linuxu je málo. A i kdyby výrobcům stála spolupráce za to, díky fragmentaci Linuxu na stovky dister neví s kým mluvit. Navíc díky překotnému vývoji stylem krok vpřed, dva kroky vzad je Linux vlastně neustálou nestabilizovanou beta verzí.
-
Prosim vas, dejte uz pokoj s tim Samsungem, LG a sitovkami Intel. Zejmena pak LG a Samsunh. Kdyby meli korektni implementaci, tak navzdory ponekud podivnemu chovani Linuxu by se nic nestalo.
Testovani na skuretecnem HW take neni tak uplne resenim. Tim je spise dodrzovani standardu vyrobci. Nedovedu si predstavit, jak by jadro Linuxu nabobtnalo, kdyby tam meli naimplementovat vselijake podivne hacky na kazdy model kazdeho prasackeho vyrobce. Na Widlich to casto chodi jen kvuli tomu, ze se tam instaluje nejaky bastl od vyrobce HW, ktery resi problemy v implementaci ACPI a kdovi ceho jeste. A resi je napriklad tak, ze se dusledne vyhyba nekterym operacim, ktere sice jsou ve standardu, ale vyrobce je implementoval tak, ze zpusobi problemy. Tak to treba bylo s nejakymi radici SCSI od Adaptecu, ale nejen temi. To, ze to ve Widlich chodi, neni proto, ze jsou tak skvele, ale proto, ze maji orginalni ovladace od vyrobce, kde je rada berlicek, ktere umozni predstirat, ze je vse v poradku a ktere obchazeji prasarny, o kterych se vyrobce radsi nikde nezminuje.
Jinak na rozdil od predrecniku jsem mel zatim vzdy kliku. Chodi mi suspend i hibernace na vsech strojich.
-
Lael Ophir (neregistrovaný)
V případě LG mechanika dělala to co měla dělat podle ATAPI specifikace pro mechaniky CD-ROM. Výrobce musí někam pověsit flash firmwaru, a ve specifikaci ATAPI to pochopitelně popsané není. Nevím jestli to dali na stejný interface jako CD-R operaci buffer flush ještě před uvedením CD-R mechanik, nebo až poté. Faktem je, že driver dělal co neměl. V případě Samsungu byla vina i na straně výrobce, ale to nijak neomlouvá chyby Linuxu. BTW to "poněkud divné chování Linuxu" je ve všech třech případech prostě špinavý hack, ve dvou z nich doprovázený závažnými bugy.
V oblasti HW těch standardů moc není. A kde jsou, tam jde pouze o doporučení, kterými se výrobce může a nemusí řídit. Navíc specifikace protokolů a chipů spoustu věcí nepopisují. Například protokoly prakticky u žádného zařízení nepopisují způsob updatu firmware, a výrobce ho musí nějak umět.
Jinak tomu "bastlu od výrobce" se říká driver :), a na rozdíl od generického naslepo psaného driveru je psaný se znalostí konkrétního zařízení, podporovaných operací, podpůrných obvodů, firmwaru, operací které umí navíc proti specifikaci nějakého čipu, se znalostí efektivity jednotlivých operací, časování atd. Generický driver střílí od boku to, co bylo napsané ve specifikaci předchozí generace nejspíš úplně jiného zařízení postaveného shodou okolností na stejném čipu, a vývojáři to zrovna doma zafungovalo. To se pak nedivte, že ty drivery stojí za starou bačkoru.Windows se důsledně vyhýbají operacím, které nepotřebují. Pokud operace kterou Windows nepoužívají způsobuje nějaké problémy, MS to jaksi nevadí. A protože MS necertifikuje například shodu se specifikací UEFI, ale bezproblémový běh s Windows, tak to výrobci neomlátí o hlavu.
Před kritizováním výrobců by to chtělo zamést si v kernelu - minimálně používat dokumentované interfaces a testovat na reálném HW.
-
Sten (neregistrovaný)
No a pak najdete takové ovladače, jako jsou ovladače ACPI pro Asus, který jednu dobu v DSDT používal BCD. Dnes to řeší velmi „standardně“ (zřejmě podle toho, že ten ovladač je MS certified): zkusí binární čísla, a když selže checksum, tak použije BCD. Jistě je to ale něco úplně jiného, než testování zařízení pomocí dokumentovaných rozhraní :-D
-
Lael Ophir (neregistrovaný)
Některá pole jsou v ACPI popsané jako "BCD or binary", což je dost síla. V DSDT by být neměla. Pokud měl ASUS takový bug (zdroj?), a chcete aby váš OS fungoval, tak se s tím prostě musíte poprat. Jinak to dopadne takhle:
http://i.stack.imgur.com/HZgpR.pngBTW samozřejmě to je něco jiného, než testování zařízení pomocí nedokumentovaných rozhraní.
-
Lael Ophir (neregistrovaný)
Bugcheck 0xA5 je ACPI_BIOS_ERROR, zbytek jsou parametry specifické pro daný bugcheck. Popis je na MSDN:
http://msdn.microsoft.com/en-us/library/windows/hardware/hh994433(v=vs.85).aspxNavíc můžete vytvářet dump nebo minidump, a ten pak analyzovat. Pokud se systém složí, po příštím bootu (ehm, pokud proběhne) vás vyzve k zaslání hlášení společnosti Microsoft. Pokud pro daný problém existuje řešení, je vám zobrazeno. Pokud ne, uchová se informace pro další analýzu. Když MS například zjistí, že uživatelům působí problém nějaký konkrétní driver, řeší to pak s výrobcem. Ve Win7 a výše se drží seznam hlášených problémů, a pokud se objeví řešení později, jste upozorněn.
Za mě je to řešené celkem pěkně.
-
Jinak tomu "bastlu od výrobce" se říká driver :), a na rozdíl od generického naslepo psaného driveru je psaný se znalostí konkrétního zařízení, podporovaných operací, podpůrných obvodů, firmwaru, operací které umí navíc proti specifikaci nějakého čipu, se znalostí efektivity jednotlivých operací, časování atd.
Ano, jak jsem rikal. Je to bastl, ktery obchazi hardwarove bugy a zpusobuje, ze se zarizeni z pohledu Widli chova, jako by dodrzovalo standardy, kterym ma odpovidat. Konkretne u ACPI nevidim duvod, proc by ve Widlich mel byt ovladac/bastl od vyrobce, kdyz ACPI je standard. Jenze on tam byt musi, protoze vyrobce je prase a kdyby mezi Widle a HW nebyla vlozena soustava berlicek, kterou vy nazyvate ovladac, tak by ACPI na Widlich nefungovalo lepe, nez na Linuxu.
Před kritizováním výrobců by to chtělo zamést si v kernelu - minimálně používat dokumentované interfaces a testovat na reálném HW.
Ne vsichni vyrobci neco verejne dokumentuji. Patrne se boji, ze by se jim lidi smali a nazvali je dobytky a bastliri.
-
Lael Ophir (neregistrovaný)
Vy asi čtete dost selektivně :). Psal jsem, že v oblasti HW neexistuje moc standardů, a většinou jde o doporučení. Pokud HW umí něco navíc proti specifikaci, není to bug. Pokud některé operace nepodporuje, nemusí to být bug. Pokud mají nějaké operace na různých HW různou rychlost, není to bug.
BTW jeden příklad: ve většině PC najdete interface I2C, na který je připojená spousta věcí, včetně chlazení. Na jedné straně máte nějaký I2C controller, který může být řešený prakticky jakkoliv. Neexistuje žádný standard, jen hromada chipů, které navíc můžete zapojit různými způsoby. Na to je pak pověšená nějaká zařízení - na každém systému jiná. Nemáte šanci vědět, jaká zařízení tam jsou, ani jak s nimi máte komunikovat. A i kdybyste věděl, že jedno z těch zařízení je konkrétní čip ovládající ventilátor pomocí 8-bitové hodnoty, pořád ještě nevíte, že výrobce používá řekněme jen 5 bitů, a hodnoty pod 4 způsobí zastavení ventilátoru. A na příští základní desce toho samého výrobce může být všechno jinak.
A jak se potom píše funkční generický driver? Vezmete si HW na vašem počítači, a budete předpokládat, že všude jinde je to udělané stejně. Když místo změny otáček ventilátoru sáhnete někam jinam, dost možná něco nabouráte, a pak budete nadávat, že se výrobce "nedrží standardu". Jenže žádný standard neexistuje.Specifikace ACPI má 950 stránek, vyžaduje implementaci AML byte code na straně OS, a dává výrobci spoustu volnosti. Při stovkách výrobců HW a tisících modelů mainboardů těžko můžete čekat, že si všechno sedne jak má. Jako perličku bych uvedl, že u některých polí nebylo až do ACPI verze 4.0a jasné, jestli mají být stringy null terminated.
-
Petr M (neregistrovaný)
1) I2C je standardní rozhraní, který si patentoval a standardizoval Philips. To, co po těchto dvou drátech běhá, je standard.
2) V PC se nepoužívá I2C, ale SMB - System Management Bus. Jsou tam nějaký drobný změny proti I2C, aby se vyhnuli výpalnýmu.
3) SMB Master je obvykle v chipsetu. Toho je kolik? Když budou v průměru dva čipsety pro každou rodinu CPU a pět rodin CPU na trhu, tak neříkejte, že se při troše snahy nepodaří odladit max. 10 variant železa, kde má navíc výrobce svoje odladěný reusable moduly a plácá je na čipy podle potřeby.
4) Periferky na SMB jsou +/- standard - minimálně 24C04 a jejich adresování na modulech RAMky (to je to nejdůležitější). Pak stačí mrknout na desku na ostatní brouky. Málo kdo si bude dělat vlastní čipy nebo programovat jednočip, když má věci jako MAX6652 nebo MAX1619. Stačí dohledat datasheety. Není to standard, ale je to dobře popsaný. Komunikace (adresy, hodnoty) se dá dobře nasniffovat na patici pro DIMM moduly.A kupodivu, ten brouk se i představí, např. posledně zmíněný MAX1669 má registr 0xFE = 0x4D (Maxim), 0xFF = 0x05. Když ho najdu na nějaké reálné adrese, vím, co do něho poslat. Jenom si vyzkoušet, ketrou teplotu že měří a kterým větrákem že točí.
Problém nastane jenom v případě, že se jim to zdá drahý a narvou tam nějaký jednočip (ATXmega, MSP430,..). Pak nastoupí hrubá síla pervers inženýringu...
-
Lael Ophir (neregistrovaný)
Jinými slovy existují jisté standardy, ale ty toho popisují málo, a pokud nemáte informace ke konkrétní základní desce, tak se jen dohadujete. To ještě odhlédnu od toho, že si s těmi větráky přes I2C/SMBus může povídat BIOS/ACPI, případně nějaký driver, takže v tom budete mít slušný chaos.
-
Petr M (neregistrovaný)
Ok, nějaký nestandarní chování... Řekněme, že máme PC takových pět let starý, s nějakým "systémem na doma" ve verzi 98. nějaký expert si hraje a zapíše na IO port (libovolnou adresu). Určitě nic nerozbije, když systém interně vyvolá výjimku, která povolí aplikaci od teď na furt zapisovat do železa... Jaj, co jsme se ve škole tímhle způsobem nahráli s COM, LPT a game portem přímo z formuláře v Delphi. A občas, vinou systému, něco sejmuli. Práce operačního systému je totiž mj. i to, aby odstínila železo za ono "standardní rozhraní" a aplikaci k tomu vůbec nepustila. Tohle chování W95/98 je jedna z největších prasáren, co jsem v životě viděl. A zneužívali to i výrobci železa, třeba garážový firmičky bez nějaké kontroly kvality SW s portfóliem dvou PCI karet - jedné s 32 neoddělenými TTL vstupy, druhé s 32 neoddělenými TTL výstupy a malou aplikací pod Win pro řízení. Prostě proto, že to šlo.
Btw. za ty mechaniky viním autory standardu - měli jasně definovat provozní režimy zařízení RUN, DIAG a UPDATE V UPDATE ať si výrobce dělá co chce a s čím chce, v DIAGu ponechat prostor pro proprietální, nedestruktivní testy, ale zbytek MUSÍ být přesně podle standardu a přes to nejede vlak. Nebo snad neexistuje rozhraní i na úrovni systému a periferie? Resp. nemůže být standardní? A generický ovladač OS nemůže tohle rozhraní prostě jenom zapouzdřit 1:1 bez dodatečné práce a obtěžování uživatelů instalací?
-
Lael Ophir (neregistrovaný)
Windows 9x byly takové jaké byly ze dvou důvodů: kvůli nižší HW náročnosti, a kvůli kompatibilitě s programy psanými pro DOS a starší verze Windows.
Pokud jsem si všiml, tak operace typu testů a flashování firmware nemají ve většině specifikací popis. On to totiž každý výrobce řeší jinak, takže není moc co standardizovat.
Generický ovladač může jen zapouzdřit "standardní" rozhraní. Problém je v tom, že HW je obrovská spousta, a různé modely mají svá specifika. Těžko můžete čekat, že výrobci budou vyrábět jen to, pro co existuje specifikace (mimochodem často mizerně napsaná), a budou se jí kompletně držet.
-
Petr M (neregistrovaný)
Kecy v kleci. Na ochranu se využívají protect módy procesoru, je to řešeno hardwarově na straně procesoru (ochrana přímo v x86 neumožňuje instrukce In a Out, pokud není v privilegovaným režimu). Ta ochrana byla aktivní i na W95/98, takže nárok na HW to nepředstavuje. Naopak, tady se ochrana aktivně obcházela.
Co se týká backward kompatibility, tak přece aplikace pro starší verze a pro DOS běhlay na podstatně slabším HW (268@16MHz vs 486SX6@66MHz) a při troše snahy by nebyl problém nastavit spouštění v sandboxu a přidělení periferky v nějakým .ini souboru nebo v registrech. Na výkonu staré aplikačky by se to ani nepoznalo.
Takže bezpečnostní kráter jak kráva, uměle vybagrovaný kvůli šlompáctví a zdechlosti zodpovědných jedinců...
-
Lael Ophir (neregistrovaný)
HW náročnost se týkala spíš podpory Unicode. Na 4MB RAM si nemůžete moc vyskakovat.
Se zpětnou kompatibilitou se mýlíte. Ono totiž nešlo zdaleka jen o aplikace. Win9x uměly používat například drivery psané pro DOS. Navíc pokud byste chtěl povolovat I/O pro každou aplikaci, byl by výsledek velmi podobný stavu, kdy povolíte všechno - jenom byste musel vytvořit definice minimálně pro desítky tisíc aplikací, což v praxi není realizovatelné.
-
Petr M (neregistrovaný)
Pokud vím, tek pod DOSem se nelezlo přímo na železo, ale většina z toho valila přes SW interrupt (klávesnice, myš,...) To ten "systém" musel emulovat tak jako tak. Přímo na železo toho lezlo minimum (proč by takový T602 lezl na COM2?), přestřelme to, dejme 1% aplikací. Nebylo by potřeba nastavovat to pro každou, prostě by default, aplikačka nesmí na železo a emuluje se BIOS + VGA. Pokud někam potřebuje, spustí se driver simulující železo a zeptá se, jestli povolit aplikaci X přístup k prostředku Y. Odpověď se uloží a je to. Při prvním spuštění je to 20s pro uživatele a jedno kliknutí. Rozhodně by to bylo víc user friendly, než když strčím flash disk do komplu s Win 7, vyskočí bublina s informací o novým HW, 10 minut hledá drivery, pak nahlásí chybu a po dvou dalších pokusech se konečně zeptá, jestli má udělat scan na dalších pět minut.
Chce to jenom mystet out of the XBOX :D
-
Myslim, ze tech aplikaci, co obchazely DOS a lezly po zeleze, bylo ponekud vic. Dosahovalo se tim zrychleni aplikaci a resily se tim asi i veci, ktere pres DOS sly resit blbe. Krome toho se pouzivala nezdokumentovanavolani DOSu. Delal to i MS, ktery mel dale tu vyhodu, ze ta nezdokumentovana volani mel zdokumentovana. Problem pak byl, ze ne vse chodilo na kazde verzi DOSu. A MS to pak delal v prvnich Widlich, cimz dosahoval vetsi rychlosti aplikaci, nez konkurence a snad kvuli tomu byly i nejake soudy.
BTW, pokud vim, byly i pripady pouzivani nezdokumentovanych instrukci CPU, coz pak chodilo jen na CPU nekterych vyrobcu. To uz ale bylo dost exoticke.
-
Lael Ophir (neregistrovaný)
T602 lezl na paralelní i sériové porty, protože se na ně dá připojit tiskárna. Představa "firewallu pro přístup na železo" je zajímavá, ale velmi špatná. Těžko to uděláte třeba u driverů psaných pro DOS, u full screen aplikací, a hlavně to uživatel nebude schopný používat. Ta GUI firewallů, s věčnými dotazy typu "aplikace abcde.exe chce přistoupit na adresu 11.22.33.44 port 5432, povolit/zakázat/povolit vždy?", jsou myslím dostatečně odstrašující ukázkou. Dalším problémem je to, že byste se u většiny aplikací musel ptát opakovaně, protože využívají typicky víc portů. Ve spoustě případů ovšem ty dodatečné porty použijí jen ve chvíli, kdy se něco stane (přijde událost A, pošlou něco na port XYZ). Jednak je to na zabití, a pak vám to může zásadně poškodit časování komunikace s periferií.
U driverů byl problém hlavně v tom, že pro řadu HW prostě nebyly. Třeba pro I/O karty, ale i pro některé mechaniky CD-ROM a síťové karty. Ještě v roce 1998 se našli výrobci, kteří s HW nedodávali drivery pro Windows :/
-
Ta GUI firewallů, s věčnými dotazy typu "aplikace abcde.exe chce přistoupit na adresu 11.22.33.44 port 5432, povolit/zakázat/povolit vždy?", jsou myslím dostatečně odstrašující ukázkou.
Tak tahle GUI se k firewallu davaji na OS, ktere jsou vecne zavirovane, protoze podobne otazky jsou jedinou cestou, jak uzivatele upozornit, ze je nekde problem, protoze aplikaci ft5742425.exe urcite neinstaloval. Je to ale k hovnu, rotoze vetsina uzivatelu zaskrtne "Remember choice" a odklepne Yes.
-
Lael Ophir (neregistrovaný)
Uživatel samozřejmě zaskrtne "Remember choice" a odklepne Yes. Hlášce totiž nerozumí. Navíc se ho systém ptá mnohokrát za den na tu samou věc, jen se liší pár údajů. Je to ukázka špatné usability.
To je jeden důvod, proč to nepomáhá. Další důvody:
- Pokud má malware oprávnění administrátora, může vypnout firewall, nebo vložit výjimku.
- Pokud má uživatel oprávnění vypnout firewall nebo vložit výjimku, může to udělat i malware běžící v kontextu uživatele.
- Není problém, aby malware komunikoval se sítí pomocí knihovny natažené v hostitelské aplikaci, která má přístup na inet. Například plugin browseru. Nakonec se ale dá browser skriptovat z externí aplikace, tak proč ztrácet čas psaním pluginu :) -
Uživatel samozřejmě zaskrtne "Remember choice" a odklepne Yes. Hlášce totiž nerozumí. Navíc se ho systém ptá mnohokrát za den na tu samou věc, jen se liší pár údajů. Je to ukázka špatné usability.
Ne, uzivatel je pako a nechce se mu neco cist a premyslet. A to i presto, ze mu to bylo vysvetleno a pritom bylo petkrat zdurazneno, jak je to dulezite. Uzivatel se pak divi, ze ho ISP ustrihl od netu, protoze pres nej lezlo tolik spamu, co se veslo na linku.
-
Lael Ophir (neregistrovaný)
Uživatel nezná jména executables, nezná doménová jména, nezná čísla portů, a netuší co kam smí nebo nesmí komunikovat (nehledě na to, že není problém vytvořit malware se jménem executable iexplore.exe nebo firefox.exe). Uživatelé jsou lidé, kteří se nechají nachytat na phishingové zprávy, protože po odkliknutí linku vidí v URL název své banky, a nepřijde jim divné, že je to nějaká fourth-level doména na čínském webu. Ne každý vystudoval informatiku a/nebo ovládá základy TCP/IP.
-
Uzivatel by mel jednou za cas pouzit hlavu. Jiz si davno mohl vsimnout, ze jmeno executable obvykle nejak souvisi se jmenem aplikace. Mohl si vsimnout, ze kdyz si pusti Firefox, firewall ho zada o akci pro Firefox. Pokud ho firewall zada o akci uprostred niceho, navic se jedna o executable hgk56754.exe, ml by znacne zpozornet. Pokud se malware jmenuje iexplore.exe, pricemz uzivatel pouziva Chrome, mel by znovu zpozornet. Pokud se malware jmenuje firefox.exe, pricemz uzivateli Firefox jiz pul hodiny bezi, mel by zpozornet znovu.
Ne vzdy lze prijit na to, co se deje, nicmene vetsina pripadu zatim asi odchytit jde. Jen to chce uzivatele, ktery mysli a neodklepne cokoliv, jen aby se rychleji dostal na dalsi porno obrazek.
-
Lael Ophir (neregistrovaný)
Na běžném počítači jsou tisíce executables (u mě je jich 6800), aktualizace a/nebo service packy se instalují nejméně každý měsíc. Navíc jsem už psal, že uživatel nezná jména executables; ani já nedovedu každý z těch 6800 kousků vždycky přiřadit k aplikaci. K tomu uživatel nerozumí IP adresám a portům. Proč myslíte, že ty firewally pro odchozí provoz skoro nikdo nepoužívá?
Jediným správným řešením je zabránit průniku malwaru použitím antiviru, instalací EMETu, a rozumným chováním uživatele. Pokud se uživatel neumí chovat rozumně, je potřeba mu zatrhnout všechno co nepotřebuje, případně použít Windows RT.
-
Z tech tisicu executables jich pouze nekolik ma duvod lez po Internetu. Pokud nepoznate IE, Firefox nebo Utlouk pote, co jste si je sam spustil a nejste schopen si vygooglovat tech nekolik dalsich zahadnych, ktere patri do systemu a z nichz vetsina stejne nema na Internetu co delat a kdyz se jim zakaze odchozi provoz, svet se nezbori, mel byste prejit na tuzku, papir a kulickove pocitadlo. Me, z nejakeho zahadneho duvodu, pouzivani ZoneAlarmu kdysi davno nejak nekladlo prilis nadmerne potize. Polovicce, ktera ma k ajtacce daleko, take ne. Ostatne je to volba uzivatele. Bud se chce o problematickych executables dozvedet, tak si nainstaluje lepsi firewall, nez ten defaultni z Widli nebo se dozvedet nic nechce, tak at se pak nedivi, ze mu "data zmizely" nebo neco.
-
Petr M (neregistrovaný)
Jenomže pod DOSem běžela jedna aplikace. Pokud ji zatáhnu někam, kde existuje multitasking a periferku si nárokuje "kde co", tak je jenom otázka času, kdy jedna aplikace zboří nastavení druhé, nebo se něco pošle nekorektně... Právě z tohoto důvodu MUSÍ být taková aplikace na pískovišti a nevrtat se přímo v železe. Co když se pokusí si přisvojit systémový časovač, protože vnitřně používá multitasking?
Praktcké realizace:
- Aplikace se dostane k instrukci IN nebo OUT
- Procesor hodí přeručení pro neprivilegovanou instrukci
- Přerušovací rutina obslouží I/O operaci, nebo v případě problému (zákaz, periferka obsazena) raděj zabije aplikaci, než nezabrání destrukci systému.
- Widle snad mají drivery a předpokládám, že když eperti z MS dokázali odělat dialog vlastností, kde je vidět přiřazení adres periferkám, tak by mohli umět napsat i něco, co místo "... na port 0xXXXX" napíše "... na periferii Y" a povolí rovnou celý rozsah adres periferky - je jasný, že když zapíšu baudrate do UARTu, asi budu potřebovat ještě datový registr a někdy třeba i handshake registr... Ale vždycky aplikace pracuje s celým portem. -
Lael Ophir (neregistrovaný)
Systémový časovač je virtualizovaný, stejně jako některá další zařízení. Těžko ale můžete virtualizovat zařízení, ke kterému nemáte driver. V době uvedení Windows 95 navíc nebyl zdaleka všechen HW plug&play, takže OS neměl úplnou představu, jaká zařízení v systému jsou, a jaké prostředky používají . A jak jsem už psal, pro spoustu HW byly drivery jen pro DOS.
Aby to bylo ještě zajímavější, Windows 3.x používaly kooperativní multitasking a běžely ve sdíleném adresním prostoru. To aplikaci dávalo možnost implementovat IPC přímým zápisem do paměti jiného procesu, vytvořit handle a předat ho jinému procesu atd. Ve Windows 95 to bylo vyřešeno tak, že se pro 16-bitové aplikace používal kooperativní multitasking, a context switch se provedl jen pokud 16-bitová aplikace volala systém (jako ve Win3.x). U aplikací pro DOS se používala nastavitelná heuristická detekce idle stavu, vizte screenshot.
http://doomworld.com/drsleep/dstep3.gifWndows 9x byly plné drsných kompromisů, ale zajistit tak širokou zpětnou kompatibilitu jiným způsobem prostě nešlo. MS počítal, že uživatele rychle převede na Windows řady NT. Bohužel zákazníkům Win9x vyhovovaly, řada výrobců ještě léta dodávala drivery jen pro DOS, a mainstreamoví uživatelé přešli na řadu NT až s Windows XP. Firmy samozřejmě často přešly už na Windows NT 4.0, tak jako tedy u nás. Podmínkou byla kompatibilita HW a SW s NT, plus větší množství paměti (která tehdy výrazně zlevnila, ale přesto byla dost drahá).
-
Lael Ophir (neregistrovaný)
BTW pro aplikace, které pod Win9x prostě nešly rozchodit, byla k dispozici option "Restart the computer in MS-DOS mode". Touto volbou jste mohl aplikaci pro DOS pustit exkluzivně, na lehce upraveném "kernelu" DOSu, a po jejím ukončení restovat zpátky do Windows. Samozřejmě to nebylo ideální, ale pro některé aplikace nebyla jiná cesta.
-
Petr M (neregistrovaný)
Virtualizovat jistě ne, ale dá se pustit na železo výhradně za podmínek, že
- je vymezený prostor, kam ta aplikace smí
- je zajištěno, že tam bude přistupovat sama (tj. nespustí se dvě instance programu,...)Takže "ovladač" volaný přerušením od neprivilegované instrukce koukne, jestli je adresa v povoleným rozsahu a jestli má mutex. Když jo, provede instrukci. Když ne, zabije natvrdo aplikaci. Sice je tam jedna mezivrstva v jádře s nějakou malou režií, ale zabespečení systému před pádem a konzistence dat v aplikaci vám za to nestojí?
Ale to přiznání, že nejsou ovladače do widlí pro všechno, je skoro tak krásný, jako to přiznání, že W95, W98 a W ME byly hnusnej bastl a atrapa systému...
-
Lael Ophir (neregistrovaný)
Ad je vymezený prostor, kam ta aplikace smí - jak tohle chcete zařídit, když pro zařízení nemáte drivery a v mnoha případech ani nevíte o jeho existenci?
Ad je zajištěno, že tam bude přistupovat sama - to saméAd nejsou ovladače do widlí pro všechno - jak jsem psal, ještě v roce 1998 se našli výrobci, kteří dodávali drivery jen pro DOS. Nic krásného na tom nevidím.
Ad W95, W98 a W ME byly hnusnej bastl a atrapa systému - Windows 9x byly SW, který měl uživatele Win3.x přivést k Windows řady NT, a zpětná kompatibilita vynutila řadu kompromisů. MS ten přechod ovšem zvládl výrazně lépe, než třeba Apple. -
Neni mi jasne, jak mely W95 privest lidi k rade NT. NT rady 3.x mely desny GUI zdedeny z Widli 3.x. NT rady 4 mely sice GUI stylu W95, ovsem v systemu byla spousta nedodelavek, ktere moc k prechodu nemotivovaly nebo ho kolikrat ani neumoznovaly. Chybejici podpora USB, pomala grafika a snad uplne chybejici DirectX, takze clovek mohl zapomenout na USB zarizeni, ktera tehdy uz zacinala prichazet do mody. A s tou grafikou clovek kolikrat mel problem prehrat film na stroji, kde ho W98 prehraly bez problemu, ponechame-li stranou nekolik padu systemu v prubehu filmu. K tomu tam byly dva nastroje na editaci registry, z nich jeden byl ve stylu W98, ale neumel nastavovat prava na klicich, druhy pak mel GUI z NT rady 3.x, umel sice vsechno, ale byl prakticky, jak hrabe do postele. V Control Panelu zase nebyl spravce zarizeni, stylu W9x, coz take moc prakticke nebylo. Moznosti opravy v nejblizsim SP MS nevyuzil, idem pro USB. Delalo to dojem, ze NT 4.0 MS honem nejak poslepoval dohromady, aby mu neco neujelo nebo co. Jedina vyhoda NT 4.0 byla v tom, ze padaly jen jednou za pul roku, nekdy az rok, coz pro uzivatele, zvykle kompletne preinstalovat stroj kazdy mesic az dva, nebyla dostatecna motivace. Na radu NT by uzivatele prevedla snaze nizsi cena, ktera ve srovnani s W9x byla dost natazena.
-
Lael Ophir (neregistrovaný)
Windows 95 poskytovaly prakticky stejné Win32 API jako Windows NT, a jednou z podmínek certifikace SW pro Windows 95 byl jeho běh i na řadě NT.
NT 4 neměly podporu USB, ale šlo doinstalovat podporu od výrobců HW. BTW první USB klíčenky přišly na trh až v roce 2000, kdy jste už mohl použít Windows 2000.
DirectX bylo podporované ve verzi 3.0a, a neoficiálně jste tam mohl nacpat i DX 5. Navíc v roce 1996 bylo minimum her i pro Windows 95, a většina z nich používala OpenGL (které v NT4 mělo podporu).
Device Manager v NT4 opravdu nebyl. Regedit byl převzatý z Windows 95, a neuměl permissions; regedt32 uměl permissions, ale měl GUI Windows NT 3.51.
Ad NT 4.0 MS honem nejak poslepoval dohromady - NT 4.0 vycházejí z NT 3.51, s GUI z Windows 95 a pár dalšími změnami (DirectX, přesun GDI do kernelu apod).Výhodou NT 4 byla samozřejmě stabilita a bezpečnost (mimochodem tehdy se mělo za to, že je výhodou i podpora více platforem, což se ukázalo jako naprostý nesmysl). Pokud firma používala aplikace kompatibilní s NT (tedy například kancelářské aplikace), a měla na slušný HW, byla to velmi dobrá volba.
-
Lael Ophir (neregistrovaný)
Zapomněl jsem na úžasné Unixové systémy. Mohl jste si pořídit server na Unixu, 10x dražší než na Windows, k tomu admina, DB admina, network admina... A samozřejmě existovaly (a asi ještě existují) i Unixové workstations. Dneska na nich nejspíš spustíte i OpenOffice - tehdy bohužel ne. Zato měly jiné vychytávky: u Sunu se monitory připojovaly přes zvláštní konektor, a jejich optické myši fungovaly jen na podložce od Sunu (myši byly laserové a používaly mousepad s natištěným rastrem).
Původně jsem četl jednoho admina na pět set PC, a pak jsem zjistil, že jste podstatně pesimističtější :). Většina českých firem jela dlouho na Win9x, a poměr adminů (a "aminů") a uživatelů měly minimálně o řád vyšší.
-
Petr M (neregistrovaný)
Naprosto jednoduše.
Existují privilegia pro procesy, jdou definovaný už na HW. Pokud nemá běžící kód povoleno použití instrukcí IN a OUT, jádro procesoru vyhodí výjimku a udělá se to v jejím ošetření. Ve statusu chyby procesoru se dá najít adresa instrukce, co to bylo za instrukci a kam lezla. Takže detekovat, že program někam sahá, není absolutně problém a běh programu to nezbrzdí (mimo "delší" instrukce IN a OUT).
V obsluze přerušení se dá definovat jeho obsluha podobně, jako u TRAPu pro volání systému. A tam už stačí mít nějakou hloupou tabulku - rozsah, momentálně přiřazená aplikace (reprezentace pomocí process ID).
A obsluha zajistí pomocí nějakýho procesu na pozadí následující akce:
- při prvním přístupu ověí ze známých ovladačů, jestli je pro ni ovladač (podle adres)
- u periferky bez ovladače při prvním přístupu nabídne povolení rozsahu
- u periferky s ovladačem se podívá, jestli ji někdo používá a když ne, tak si ji zabere pomocí mutexu
- pokud je už rozsah používaný, sestřelí volající aplikaci s odpovídajícím hlášením
- pokud je rozsah v tabulce volný, ověří, že tam aplikace smí (záznam v registrech, dotaz). Buďto ji zabije, nebo provede na úrovn ovladače požadovanou instrukci.
- po ukončení aplikace uvolní mutex a smaže z tabulky všechny její process id (stačí hook do zpráv aplikaci, aby poznal zavření)To je fakt tak složitý, že je to u M$ nerealizovatelný?
-
Lael Ophir (neregistrovaný)
OMG. Ještě jednou: v době Windows 95 spousta HW nebyla PnP, a na spoustu věcí nebyly drivery, takže Windows o existenci daného HW nevěděly - neměly seznam jeho I/O portů a bufferů. Detekovat kam program sahá jen není problém. Problém je, co s tou informací udělat, když nemáte driver, a nevíte co na tom portu visí (a nebo nevisí). Navíc aplikace nemusí běžet v jediném procesu, a s HW si může povídat víc procesů najednou. Navíc otázkám na povolení přístupu k HW nebude uživatel rozumět, tak jako nerozumí dotazům firewallu. Navíc u full screen aplikace budete těžko zobrazovat dotaz. Navíc to neřeší problém driverů psaných pro DOS. Je to past vedle pasti, (c) mechanik Luboš, a proto MS touhle cestou nešel. Nabídnul virtualizaci běžného HW, s tím že zbytek se nedal efektivně řešit, a aplikacím se proto přístup neblokoval.
Samozřejmě v NT to bylo (a je) jinak: aplikace psaná pro DOS nebo staré Windows buď použila virtualizovaný HW, nebo měla smůlu. To je samozřejmě jediný konzistentní přístup, ale nebudou vám fungovat drivery psané pro DOS, ani aplikace komunikující napřímo s HW.
-
patal (neregistrovaný)
Ohledne toho notebooku Samsung: "Given that the driver was written to Samsung's specifications, this is pretty obviously Samsung's fault", rika Matthew Garrett.
V pripade sitovek Intel slo o nepouzivani ladici podpory pri alokovani VM nebo nekontrolovani smysluplnosti odebirani trasovacich skoku. Byla to shoda okolnosti, ze tam byla namapovana EEPROM stiovky.
Mechaniky LG se bricknuly proto, ze standardizovany volitelny prikaz na flushnuti kese pochopily jako prikaz k updejtovani firmwaru.
Usilovnejsim testovanim by se na ty chyby prislo. Ale ve druhem pripade se netyka spoluprace s HW (ten to "jen" schytal), ve zbylych dvou to nebyla chyba Linuxu. Lidi (tj. laiky) vina nezajima, jak nejspise opravnene pripomenete, ale timto jsem vyvratil ty spinave hacky.
-
Lael Ophir (neregistrovaný)
Ad Samsung - mýlíte se. Někdo ze Samsungu kdysi řekl vývojáři, že se některé funkce realizují zápisem do paměti BIOSu. Výsledný driver se používal i pro modely, se kterými nebyl testovaný. Navíc se používal i při UEFI bootu, kde ta paměť BIOSu neexistovala, a zápisy končily výjimkou. Zbytek (bricknutí po přeplnění UEFI logu) už byl problém Samsungu. Chyby na straně Linuxu: použití nedokumentovaného interface, použití driveru na HW pro který není určený, použití interface BIOSu při UEFI bootu (tam byl navíc bug v implementaci funkce, která ověřuje, jestli proběhl boot přes UEFI).
Ad Intel - ftrace prováděl nebezpečnou techniku modifikace živého kódu. A protože se prováděla asynchronně, mohlo dojít k modifikaci paměti programu, který už neběžel. To bylo vyřešeno pojistkou ve formě ověřování, jestli se program už neukončil, která ale díky bugu nefungovala. Jako poslední záchrana tam bylo srovnání cílové paměťové lokace s instrukcemi skoku (tedy jestli se opravdu přepisuje, co se přepisovat má). Ovšem na paměti zařízení srovnávací operace nemají definovaný výsledek, takže ani to nezabralo. A špatný zápis shodou okolností skončil zápisem no NVRAM síťové karty. Samozřejmě ke špatným zápisům docházelo na spoustě systémů, ale shodou okolností se nestrefily do ničeho kritického. Chyby na straně Linuxu: nebezpečná technika a dva kritické bugy.
Ad CD-ROM mechaniky LG: driver testoval, jestli jde o CD-ROM nebo CD-R tak, že se pokusil o operaci zápisu. U mechanik CD-ROM taková operace není popsaná ve specifikaci, takže většina z nich vrátila chybu. Bohužel u CD-ROMů LG na tu samou operaci navěsili flash firmwaru, a ta prasácká detekce je brickla. Chyba na straně Linuxu: nekorektní detekce typu zařízení použitím operací, která pro cílová zařízení nemá ve specifikaci definované chování. Zapisovací mechanika se má detekovat přes ATAPI capability bites - ne tak, že zkusím nějaký příkaz který na spoustě cílového HW nemá definované chování, a budu čekat, co se asi tak stane.
Ve všech třech případech šlo o špinavé hacky, ve dvou byl použit nesprávný interface zařízení, ve dvou hrály roli zásadní bugy. Kdo ví, kolik toho v Linuxu ještě vyhnívá, a jen náhodou to nezpůsobilo zrovna bricknutí HW. Problémy s probouzením po sleep/hibernaci jistě budou mít v mnoha případech podobné příčiny (špatná inicializace HW, zápisy na špatná místa, používání nedokumentovaných interfaců).
-
Radim Luža (neregistrovaný)
No jo no... ale pokud se ne to podíváme očima jinýma, než nadšeného zastánce windows, tak by situace mohla vypadat třeba takto:
NTB samsung - výrobce nedodal driver, nedodal dokumentaci, zdroják, nedodal vlastně nic jen jakousi neoficiální poznámku o tom, jak to funguje a která se netýkala nového modelu, což ale také nikde nezmínil... ale jinak je v tom zcela nevinně;-)
Mechaniky LG - výrobce implementoval nedokumentovanou funkčnost, nedodal driver, dokumentaci, zdroják, ani tu poznámku.... a ne - korektní chování na nepodporovaný příkaz dle mého názoru není bricknout zařízení (analogie - pád prohlížeče při neznámém HTML tagu).
Ono je reálně tolik pravd, kolik je pohledů na věc. Nelze všem vnucovat ten jediný "politicky korektní".
-
Lael Ophir (neregistrovaný)
Ad NTB Samsung - výrobce dodal driver pro Windows. Nevíme jestli s ním vůbec někdo mluvil o driveru pro Linux, nebo o specifikaci. Driver asi nedodá, protože autoři Linuxu tvrdí, že kernelový modul musí být pod GPL, neexistuje kernelové ABI, a Linux je roztříštěný na stovky dister s novými verzemi co pár měsíců. Pro 99% uživatelů stačí napsat testovat drivery pro poslední verzi Windows, a ro zbývající jedno procento má stovky dister plus všechny ty z hlediska výrobce úchylné podmínky - co pak čekáte?
Ad mechaniky LG - výrobce *musí* implementovat funkce, které ATAPI nepopisuje, protože update firmwaru v té specifikaci prostě není. Driver není potřeba, protože je to standardní ATAPI CD-ROM. Utilita pro flash firmwaru byla nejspíš pro (Free)DOS. Ohledně dokumentace opět netušíme, jestli s nimi vůbec někdo mluvil.
Minimalistické řešení: vytvořit standardní testy HW (podobně jako je má Microsoft), například formou live distra, která po bootu prostě otestuje co může. Vytvořit centrálně spravovanou databázi modelů HW, výsledků testů a řešení. Řešením může být úprava kernelu/driveru, nebo nějaké nastavení, které by pak mělo být k dispozici na každém instalačním médiu, s možností online updatu, a automatickou aplikací toho řešení. A samozřejmě pokud chcete drivery od výrobců, tak je třeba vytvořit ABI, stabilizovat vývoj tak aby nové verze dister nevycházely co pár měsíců, vyjmout drivery z GPL a minimalizovat počet (podporovaných) dister. Vzhledem k počtu uživatelů Linuxu by se výrobcům možná také slušelo za drivery a podporu zaplatit.
Jak vidíte, tak řešení vázne na straně Linuxu. Nejsou zdroje na psaní driverů pro existující HW a jejich testování (kdyby uživatelé platili za distro Linuxu jen desetinu ceny Windows, hned by peníze byly). K tomu politika FSF a autorů jádra brání kooperaci s výrobci. Na co si pak stěžujete? Vždyť si ty problémy způsobují autoři Linuxu sami.
-
Petr M (neregistrovaný)
Pro komunikaci platí několik pravidel:
1. Pokud zpráva nesedí se specifikací, nedělám nic a vrátím chybu "UNSPECIFIED OPERATION".
2. Pokud potřebuju něco, co standard nepodporuje a musím si doplnit zprávu, MUSÍ protistrana explicitně potvrdit, že tuhle funkcionalitu požaduje. Jinak viz 1.Takže pto flashování to měli udělat tak, že po příkazu pro zápis je vrácen chyba, pokud do nějaké doby přijde specifikovaná zpráva s klíčem, přepne se do FLASH režimu.
Když to dělalo LG tak, že operaci potvrdili a neověřovali, jestli jde o cílenou akci, tak sice v Linuxu byla prasárna, ale destruktivní byl přístup LG. Není to zařízení, ketrý by bylo ve vzduchoprázdnu a profesní paranoia a pan Murphy velí k obezřetnosti.
-
Petr M (neregistrovaný)
Neříkám, že ten driver byl v pořádku, ale pokud je ve funkci, která má na starost komunikaci s jiným systémem, na posledním řádku return ERR_OK, tak je to na zastřelení. Funkce nesmí jako default vracet, že proběhla bez problémů a kontrolér nesmí provést akci, u které nemá jistotu, že ji provést má.
-
Lael Ophir (neregistrovaný)
Milý J, zkuste si všimnout několika věcí:
- Nazýváte mě tupcem. Kdyby vám snad nedocházelo, že takové věci do diskuse nepatří, tak si přečtěte pravidla pro diskutující pod polem, do kterého píšete příspěvek.
- Pokud vám někdo vyká, je dobrým zvykem mu také vykat.
- V diskusích opakovaně předvádíte těžkou neznalost problematiky, ke které se snažíte vyjadřovat.K tématu: většina HW nemá nepřepisovatelnou část flash memory. Zvyšuje to náklady a snižuje flexibilitu (pokud se v nepřepisovatelné části vyskytne chyba, nelze ji opravit). Navíc to uživateli nepomůže. Když mu například umře základní deska díky špatně flashnutému BIOSu, tak je mu úplně jedno, jakým způsobem ji pak support/servis rozchodí. Sám to nezvládne, a jeho HW je prostě odstavený.
Záložní firmware je naprosto výjimečná záležitost. Může mít smysl, ale opět to přináší náklady navíc, a k tomu uživatel musí vědět, jak záložní firmware aktivovat.
Firmám se prostě nechce zvyšovat náklady - a tedy ceny - kvůli hypotetickým situacím, které nakonec postihnou řekněme jednoho zákazníka ze sta tisíc, a to řešení se zvýšenými náklady by mu stejně moc nepomohlo (vizte výše). -
Tak napriklad krach pri flashi BIOSu moba nebo firmware ADSL modemu neni situace az tak zcela hypoteticka. Moznost recovery nabizeji jen nekteri vyrobci, budiz prokleti ti ostatni. Hlavne mobo, zejmena treba v notebooku, neni sestakova zalezitost a to, ze vyrobce usetril dolar tim, ze neda moznost recovery, me opravdu nezajima.
-
Lael Ophir (neregistrovaný)
Zrovna u mainboardu notebooku má ten flash minimum šancí neprojít. V instrukcích bývá psáno, že máte mít plnou baterii, takže vás netrápí výpadek proudu. Nesprávný firmware nezapíšete, protože to utilita ověřuje. Po flashi se provádí ověřovací čtení.
Samozřejmě pokud vám omylem ten firmware přepíše nějaký linuxový driver :), tak máte smůlu. A když vzácně mainboard má nějakou recovery option, tak to stejně nebývá nic pro uživatele:
http://support.lenovo.com/en_US/research/hints-or-tips/detail.page?&LegacyDocID=MIGR-45385 -
To, ze by se neco nemelo posrat neznamena, ze se to neposere. Muze neco zblbnout uzivatel, slapne mu na vypinac kocka.... Krome toho vyrobci se obvykle s recovery option neobtezuji ani u dospelych motherboardu do PC.
Pokud moznost recovery existuje, tak nevim, proc by nemela byt pro uzivatele. Zalezi na tom, jak blbe to ma vyrobce udelane. Treba u nejakeho moba jsem videl moznost vypalit bios na CD, vrazit ho do mechaniky, rebootovat a zmacknut magickou kombinaci klaves. Tohle bezne zvladaji i skauti z pomocne skoly.
-
Lael Ophir (neregistrovaný)
Pokud na displayi svítí velký nápis "DO NOT power off or reset system", a on systém vypne nebo resetuje, tak je to obdobou toho, když si uřízne prst kuchyňským nožem. Při některých věcech si člověk holt musí dávat pozor.
Linkoval jsem recovery BIOSu u nějakého HW od Lenova. Osmnáct kroků, včetně rozebrání počítače a přepnutí jumperu - to fakt není pro každého. V některých případech je to jednodušší, ale pořád ne dost jednoduché pro uživatele (sehnat klíčenku, na jiném stroji ji naformátovat na FAT32, stáhnout image BIOSu, rozbalit ho na klíčenku, provést nějaký magický hmat při startu počítače).
-
Kaacz (neregistrovaný)
Tady evidentně někdo nečetl Linusův komentář k čuňáckému ACPI výrobců periferií .. z kterého plyne, že každý výrobce to má zprasené po svém, ale protože si dodá vlastní drivery do Windows, tak to na OS úrovni eliminuje. Takže v případě, kdy výrobce periferie je prase a nedodá svůj driver, má Linux problém ..
L.O. více čtěte .. :) -
Karel (neregistrovaný)
Ale vždyť to je to, co Lael píše. Zařízení je všelijaké a musí se ohackovat. Výrobce sám (s využitím svých znalostí) dodá hack v podobě driveru pro MS Windows. Na Linux kašle. A tak to pro Linux hackuje nadšenec, který ale znalost HW nemá. Případně má a zvládne to, ale pak to jiný nadšenec vezme a spustí proti jinému HW, který ovšem vyžaduje hacky jiné.
Aneb špinavě se hackuje všude. MS Windows z toho vychází o chlup lépe jen proto, že pro ně to hackuje sám výrobce.
-
Dell Vostro 3300n
vid.LABEL, N-SERIES, SMALL
http://www.dell.com/support/my-support/sk/sk/skdhs1/product-support/servicetag/G1DY5N1/confign-series je bez Windows s Ubuntu, alebo FreeDOS=om, ci bez OS
http://en.wikipedia.org/wiki/Dell_n_SeriesBohuzial s Ubuntu u nas nie je predavny, hoci asi 700 m v Rakusku je, ale notas je sluzobny, takze sa musel kupovat v SR (verejna institucia) takze tam je Ubuntu 13.10-64bit- v dual boote s 32 bit-LTS-kom (Ziadny reinstal len updates a upgrades od 10.04LTS)
sleep 20,50s
wake up(do lock screen):13,28stakze 7x-15x zrychenie pomoze...
-
mattyy1hp (neregistrovaný)
Nechápu co se tady v roce 2014 řeší usínání/probouzení.
Mam HP Envy DV6 (Intel CPU + nVidia Optimus) notebook s Debianem Unstable. Probouzim a uspávam i několikrát denně. Bez jedinného problému, 100% funkčnost. Aby taky ne... Tyhle problémy jsem naposledy viděl na AMD grafikach před Catalystama 13.4. Od té doby jsem se nesetkal s notebookem (stolních PC kolem sebe moc nemam), kde by se Linux neprobudil.
-
zd.valek (neregistrovaný)
Mě nejvíce zaujalo to dlouhé í na konci a pak ještě víc, že si zatím nikdo nestěžoval ;-)
Jinak s uspáváním počítače už problém nemám. Probíhá rychle a spolehlivě od té doby do mám podporovanou AMD grafiku s otevřenýma ovladačema a nepoužívám WiFi.
Uspání na disk mi nefunguje asi proto, že nemám nastavené místo, kam by se uložil obsah RAM a protože to nepotřebuju, tak to ani neřeším. -
Som laik ale používam už dosť dlho distribúciu Opensuse, grafika Nvidia. Ovládače z Nvidie aj Noveau. Nejaký čas aj Tumbleweed - rolling upgrade. Súhlasím s tým, že problémy s uspávaním sa sporadicky vyskytujú. Posledne to bolo pri kerneli 3.11. Preto som sa vrátil k verzii 3.7. Kernel 3.14 na live CD sa zdá byť OK. Prečo to ale píšem - poradí mi niekto, ako nájsť hardvér, ktorý spôsobuje problémy? V logu je napríklad "corrupded RAM", ale čo s tým ďalej? V diskusiach to končí radou, že treba zapísať kernel bug a tam to zamrzne.
ČLÁNKY DO MAILU
