A co vám opensource pomůže, když někdo omylem v nějaké distribuci někde v hlavičkovém souboru něco nastaví, co povede k zapnutí nějakého debug modu podpůrné aplikace (u HP to nebylo v ovladači, ale v prográmku, který mj. monitoruje některé "multimediální" klávesy a podle toho něco nastavuje). Stejně se na to přijde podobným způsobem, možná odstranění bude rychlejší, ale ani za to bych nedal ruku do ohně.
Sankta simplicitas!
Skutečně to někdo v populární distribuci, řekněme Ubuntu, sám zkontroluje nebo dokonce opraví? Kdepak, až když se na to náhodou přijde, tak to určitě Ubuntu opraví a dá do aktualizací (to ostatně má HP na noteboocích taky, že se aktualizují jejich věci, i BIOS to kontroluje) a pak záleží na tom, jak kdo aktualizuje.
Ale tady nepomůže ani to, že to HP dá do Windows Update, protože spousty "inteligentů" na fórech radí, že je třeba vypnout aktualizace Windows.
Ještě se někdo diví, že ve Windows 10 nejde aktualizace zakázat, ale jen odložit?
za předpokladu, že HP se aktualizace přes Windows a ne svým vlastním mechanismem.
Ubuntu (či obecně open source) je v tomhle mnohem průhlednější a flexibilnější. Už i taková maličkost, že je možné veřejně zjistit, kdo danou chybu udělal a lépe to příště kontrolovat. HP je blackbox a člověk se na ně musí spolehnout, což pro někoho není špatně, mně to nevyhovuje.
Ale tady nepomůže ani to, že to HP dá do Windows Update, protože spousty "inteligentů" na fórech radí, že je třeba vypnout aktualizace Windows.
Ano, to je opravdu šokézní v situaci, kdy např. hotfix pro Windows Server zlikviduje DNS server, nebo kdy jiný hotfix způsobí, že přihlášení na server přes RDP trvá přes půl hodiny.
Reagujes hezky, ale zbytecne. Resi se situace, ze vime o chybe a opravujeme ji, kde samozrejme to velke distribuce zaradi velmi rychle - a pokud ne muzes si klidne aplikovat patch z upstreamu. Jak muzu vedet, ze HP ve svem ovladaci opravi jen tuhle vec a nezmeni mi chovani v necem jinem? A co kdyz ho zmeni, jak si backportuju patch? Zalezi jak moc clovek ma rad svou svobodu.
A hlavně ty distribuce distribuují patch, který opravuje tuto jednu chybu, ne kumulativní rozbitý krám, který krom dané chyby "opravuje" ještě 20 dalších a protože ona "oprava" rozmrdá např. výše zmíněné DNS, tak je zcela nepoužitelná a díra holt zůstane, jak byla.
Zdravíme mamrdy do Redmondu.
Možná zbytečně, ale po tom zmíněném updatu se nespustil dns.exe tomu, kdo měl v kořeni (@ v terminologii bindu) jméno, které je CNAME (a to si musel někdo iniciativně vyrobit ručně, v normálně vytvořené zóně je jméno A záznamu). A taky změna CNAME na A to spravila.
Bind takovou konfiguraci taky neskousne, chyba byla když tak v tom, že před tím takovou věc šlo nadefinovat.
Možná by neškodilo trochu uměřenosti ve vyjadřování. A podívat se, o co vlastně šlo.
To zalezi - vetsinou samozrejme ne, ale je dulezite aby ta moznost tu byla. A ze sve praxe vim i spouste produkcnich nasazeni s monkey patchnutyma jarkama od IBM WebSphere a take to nikdo neresil, protoze se potrebovala novejsi verze a zaroven odstranit zmena. Coz mi prijde jako mnohem vetsi zverstvo a i ta banka to pro svuj kriticky system velmi rada nasadila.
Editovat nějakou binárku na úrovni ASM a přeložit ji znovu s opraveným kódem není tak úplně totéž, nemyslíte? Předpokládal bych, že kompetentní správce si zkontroluje obsah příslušného patche, vyhodnotí pro a proti, patch vyzkouší na nějakém testovacím stroji a následně jej nasadí - to je ale možné jen v případě, že tu možnost aplikovat patch ručně má.
Je to trochu problém popisu práce. Někde je administrátor ten Jouda že sklepa, co sice tak nějak ví, ale plánovat a zadávat musí jiní. Potom máte administrátory, kteří jsou dobře proškolení, mají na to náročné zkoušky atd. ale čekají na zadání a plán. Máte taky administrátory, kteří mají schopnosti, znalosti a plán, co a jak bude kdy potřeba udělat. Máte taky administrátory, kteří jsou spíše inženýři. Ví do určitého detailů, jak co funguje, sledují vývoj v oblasti, mají schopnosti nová řešení adaptovat a stávající udržovat a to vše zorganizovat.
USENIX má nějaké definice, ale jinak mi není žádná vyloženě ustálená známá. Každopádně administrátor nemusí být žádný tupec, který obíhá problémy a čeká na zadání. Může být i ten vývojář na té úrovni, že důležitá je spolehlivost a dostupnost služby před další funkcionalitou.
Ale tady nepomůže ani to, že to HP dá do Windows Update, protože spousty "inteligentů" na fórech radí, že je třeba vypnout aktualizace Windows.
Ještě se někdo diví, že ve Windows 10 nejde aktualizace zakázat, ale jen odložit?
Mi je divné, že se někdo diví těm radám, když aktualizace od MS běžně:
1. něco rozbijí
2. něco vypnou
3. něco zablokují
4. něco přenastaví
5. nainstalují starší verzi software nebo ovladače, která nemá očekávanou kvalitu jako ten, co tam byl před aktualizací
6. trvají dlouho
7. systém aktualizací se rozbíjí a je třeba jej ručně patchovat či opravovat s úspěšností rovnající se šanci výhry ve Sportce
8. aktualizuje se i to co bylo už jednou odmítnuto
9. spouštějí se samovolně i když se to uživateli zrovna nehodí
10. instaluje se v dalším průchodu to, co bylo zrovna aktualizováno
11. vyžírají prostředky, když je potřeba výkon na něco jiného až tak, že i silný stroj je nepoužitelný
12. prodlužují vypnutí, start či restart počítače na neúměrně dlouhou dobu, takže PC nejde používat
13. restartují PC i když uživatel nechce, protože na něm potřebuje dělat něco jiného
Zapomněl jsem na něco?
BTW. nic z toho na Linuxu neexistuje a pokud se něco z toho občas objeví, je to pověstná výjimka z pravidla. Pohled na údiv uživatelů převedených z Windows na Linux z toho, že aktualizace si můžou pustit kdy chtějí, nemusí po jejich aplikaci restartovat, můžou během aktualizací PC užívat, aniž by poznali, že se systém aktualizuje, že se zaktualizují i všechny nainstalované aplikace atd. je k nezaplacení ;-)
Zapomněl jsem na něco?
Jo, zapomněls na nejnovější hit - aktualizace zablokují jakékoliv další aktualizace, protože jedna vylízaná škeble v Redmondu rozhodla, že plán zdlaždocoidnění a prošmírování je třeba splnit stůj co stůj, a další vymazanej dement zbastlil kód, co neumí detekovat správně procesor.
O měsíc a půl později je samozřejmě nevyřešeno, takže jediné řešení je opatchovat si knihovnu.
xxxxx (neregistrovaný) ---.142.broadband5.iol.cz 18.5.2017
Nedělá při tom "bod obnovení"?
tim to rozodne neni, tak brutalni pomalost prubehu WindowsUpdate je i kdyz mas "vytvareni bodu obnoveni" kompletne pro vsechny oddily vsech disku vypnute...
pri te fazi hledani to mozna dementne/zbytecne dela kontrolni soucty vseho v %SystemRoot%, nejspis nekolikrat, pak to porovnava s necim co asi generuje WindowsUpdate server...
i to samotne faze stahovani pak trva strasne dlouho na to ze jde o trapnejch par desitek/stovek MB...
a faze instalace je take zbytecne/brutalne komplikoana/dlouha, kdy za tu dobu bys naklonoval celej disk na jinej :) (samozrejme nepocitam ty situace kdy se kompiluje .NET, to je teprve porod :)
takze jednoducha odpoved na to proc WindowsUpdate trva tak dlouho neni, pokud se nespokojime s tim ze "je to proste kompletne dementne navrzene" :)
Aha, už chápu a celkem souhlasím.
Ten čas před tím je šílený (asi to bude nejen SystemRoot, ale i %ProgramFiles% protože arm mají IE a common knihovny).. Neřku když je užit novější MS update (i všeho kolem), ne jen WinUpdate.
To stahování, pak, už nebývá tak dlouho, pokud je to v nestandardní doby. Jinak asi nestíhají. Což JE jejich chyba že tam mají úzké hrdlo v jejich download serverech. Ostatně také už udělali stahování i z koncových klientů, jaké je běžné pro hry, což se zase spoustě lidí nelíbí ...
Zpomalení jednotlivých instalací, to bych se nedivil. Dělají asi rollback zálohu (bod obnovení je ještě něco jiného, pro emergency boot). A musí pro každou instalaci zvlášť (tím že tam mají i 3dr party ... tak musí být obecnější) - když se nepovede, vrací zpět stav pro každou jednu instalaci (i s ohledem na ty instalace budoucí), ne jako celek, mám odzkoušeno.
Krom té úvodní kontroly SysRoot/ProgramFiles (fakt mi přijde hodně pomalá) si nejsem jist, zda bych dokázal udělat něco jinak, lépe, rychleji. Obzvláště když některé soubory jsou lockované a jediná možnost je přepsat je při rebootu (po timeout že neuvolní ani po chvíli). A při chybě musím počítat s unwrap nějaké prostřední sub-instalace bez porušení záloh ostatních právě běžících instalací /i těch co probíhají/. Instalací rozkouskovaných na běžnou a reboot část, bez toho, abych rebootoval pro každou instalaci zvlášť.
tim to rozodne neni, tak brutalni pomalost prubehu WindowsUpdate je i kdyz mas "vytvareni bodu obnoveni" kompletne pro vsechny oddily vsech disku vypnute...
Vypnuté to mít můžeš, ale tohle je Windows, takže by mě nepřekvapilo, kdyby ten bod obnovení někdy prostě vytvářel sám od sebe, i kdybys to měl stokrát vypnuté.
Plus navíc, pokud se záplatuje dotnet, tak tuším musí znovu vše překládat. Ne sice zrovna jádro, ale každou nainstalovanou .net aplikaci. To vždy trvá století.
A pokud se stahuje i pravidelná antivirová ochrana, tak to prolézá celý disk a kontroluje každý soubor dle hash.
Dříve šlo vybrat, že dotnet plus antivir člověk vynechá (či nechá na jindy). Pak to býval fofr. Teď už to tuším nejde.
Že algoritmus vyhleádávní aktualizací na starších Windows (XP-7) není dobře navržený, myslím i přiznali. Prostě při jeho navrhování (2001 a dříve) nepočítali s tím, že těch aktualizací bude tolik, takže si mysleli, že i vyšší časová složitost nebude problém.
Na WIndows 7 mi pomáhalo při vyhledávání aktualizací službu WIndows Update tvrdě ukončit. Po opětovném spuštění obvykle nějaké aktualizace našla velmi brzy. SIce ne všechny, ale dost tím snížila prostor pro hledání závislostí mezi dalšími aktualizacemi, čímž se čas hledání zkrátil.
Na Windows 8/8.1 (zejména 8.1) jsem již nějakou extra dobu na hledání aktualizací nepozoroval. A nemyslím, že antivirus při každé své aktualizaci prohledává celý disk (ledaže by to byla žhavá novinka nejnovějších updatů Windows 10), protože tyto updaty (zejména definic) procházejí rychle.
COZE? :-D tech aktualizaci maji par desitek az maximalne stovek, co je to proti par tisicum az desetitisicum balicku ktere kontroluje pri aktualizaci GNU/Linux kteremu to trva 10-100x kratsi dobu ;)
a dalsi vec, pri navrhu 2001 pocitali s CPU Pentium SingleCore, pomale 512MB-2GB RAM, HDD na PATA, dnesni SSD na SATA2/3, CPU Intel Core, 4-32GB nasobne rychlejsi RAM... ze by to nemelo zvladat levou zadni za par minut vyledani/stazeni/intalaci ? ;)
COZE? :-D tech aktualizaci maji par desitek az maximalne stovek, co je to proti par tisicum az desetitisicum balicku ktere kontroluje pri aktualizaci GNU/Linux kteremu to trva 10-100x kratsi dobu ;)
Tak pokud je jejich algoritmus O(exp(n)) a n se počítá v minutách, tak i těch pár desítek úplně stačí ;)
Nejspíš dementní algoritmus na hledání aktualizací nebo tak. Někdy nám počítače s Windows 7 hledají aktualizace celou noc a prostě to nezrychlíte. Taky mám zkušenost, že hledání aktualizací i po manuálním spuštění funguje až další den. Možná souhra s DHCP, DNS, WSUS co já vím.
Možná by stálo za to bootovat do KVM VM s Windows. USB a GPU by se protáhlo dovnitř a byl by klid. Něco jako distribuované VDI.
Osobně používám Windows jedině v KVM. Hlavně proto, že si můžu dělat snapshoty a kdykoli se mi zasekne aktualizace nebo Windows přestane fungovat z nějakého jiného důvodu, stačí jedním kliknutím obnovit snapshot a jede se dál. Používám VIRTIO a QXL ovladače od Red Hatu, protahovat USB ani GPU jsem nezkoušel protože v praxi mám Wokna v podstatě jenom kvůli Wordu, takže to není potřeba.
Na tom s tím algoritmem možná něco bude. Třeba prochází celý adresář na aktualizačním serveru, stahuje všechny balíky jeden po druhém, každý z nich rozbalí, zkontroluje, jestli to je ten, co hledá, a když náhodou ne, tak ho smaže a stáhne další... Microsoft je toho schopný.
KVM se snapshotem ti pul predloni az vloni nepomohlo... Microsoft v prubehu akce "W10 nas3rem pod natlakem" nekolikrat zmrvil WindowsUpdate server side pro Windows 7 a pokazde byl potreba najit rucne vhodne KB ktere to (do dalsiho mesice) opravilo... obnoveni mesic stareho snapshotu kde WindowsUpdate fungoval nepomohlo, protoze byl proste umele vyvolavanej problem na strane Microsoftich serveru...
souhrne info se da najit treba tu: http://wu.krelay.de/en/ , kdyz se clovek procvaka nekolikrat odkazem mesic zpet, mesic zpet...
Tak samozřejmě že mě snapshot nezachrání tam, kde to MS schválně kur*í, ale na běžné problémy se mi to osvědčilo. Taky je to k nezaplacení tam, kde v dobré víře stáhnu a instaluju nějakou utilitu, kterou zrovna potřebuju, nemám chuť ani čas všechno pozorné pročítat a výsledek je, že kromě té utility mi to tam nacpe různé toolbary a další srágory.
tak rozhodne, KVM misto dualbootu je jasna volba, pokud teda nekdo neni gam(bl)er a nema na zprovozneni pci passthrough :)
ne pro osobni potreby, ale jinde prave take KVM pro vice WIndows vyuzivam a snapshotuju a po predcasem prechodu z VirtualBoxu je to mnohem pohodlnejsi, krome lepsiho pocitu, snadneho skriptovani treba to ze kdyz mi bezi 5 virtualu tak si zavru jejich okna a nevypnu tim virtual :)
Jo, že neaktualizují SW třetích stran, takže co je platný aktualizovaný OS, když na tom běží tři roky nezáplatovaná appka? A co je platný, že se appka dotazuje na server na svou novou verzi, když by
a) mimo update nepotřebovala chodit na web - bezpečnostní díra
b) aktualizace je na dobrovolnosti uživatele a když mu v systrayi vyskočí pět aktualizací, každá otevře web, uživatel musí stáhnout instalátor, spustit jej, potvrdit, projít průvodce a odškrtnout bloatware, restartovat kvůli každé kravině,..., tak si 3x rozmyslí, jestli bude pracovat, nebo zabije den updatováním
c) u staženýho intalátoru není žádný podpis a nic, co by ověřilo, že tam někdo nepřibalil nějaký dáreček
d) u plno aplikací ho to ani neupozorní, že je nová verze, a aby si těch 20 aplikací hlídal sám.