Vlákno názorů k článku
HP vydal záplatu odstraňující keyloger z ovladačů zvukovky od jak jako? - mame v linuxu closed source ovladace ke zvukovce?...

Ale vždyť to píšou, že oprava je k dispozici a že ji vydají i přes Windows Update. HP to totiž dělá dávno, třeba dříve používaná aplikace Qlb (Quick Launch Buttons) se takto aktualizovala.

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.

Ale ja preci nerikam, ze jiny sfotware nema chybu, nebo neni vydana spatna verze - jde o to, ze mam tu moznost si udelat overlay se svou verzi. Celou dobu poukazuji na problem o svobode uzivatele nakladat se SW kterym pouziva a ty se porad tocis kolem nejakych bugu a spatnych oprav.

muzes si klidne aplikovat patch z upstreamu
Opravdu si myslíte, že v nějaké instituci, kde běh toho serveru ovlivňuje tisíce lidí (škola, úřad, továrna), si administrátor jen tak stáhne patch a přeloží si nové jádro (nebo jen nějakou „obyčejnou“ aplikaci)?

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.

je dulezite aby ta moznost tu byla
Mne čistě teoretické možnosti nezajímají. Navíc pokud řešíte čistě teoretické možnosti, žádný zdroják nepotřebujete – hexaeditory stále existují, takže možnost opravit tu chybu máte.

Není to tak úplně totéž. Ale od reality je to vzdálené přibližně stejně, jako že správce bude vyhodnocovat obsah patche.

I pokud by ten patch byl tak jednoduchý, že jenom vypíná potenciálně zranitelnou funkci, musel by umět posoudit, zda se ta funkce někde používá, a pokud ano, jaké bude mít její vypnutí dopady. To by musel dokonale znát celou aplikaci i její závislosti.

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.

Tam ale asi budou mít nějakou podporu. Když V stojí v kanceláři šéf, že to a to nejde a je nutné to spravit dnes, tak přítomnost patche pro upstream je rozdíl mezi prvním varováním a dalším časem do oficiální opravy v updatu balíčků o kterou se můžete zasadit.

6. trvají dlouho

Nad tímhle kroutím hlavou už dlouho. Jak je proboha možné, že stáhnout soubor a uložit ho na disk trvá takovou dobou a často prakticky imobilizuje počítač? To Windows při každé aktualizaci znova překládá jádro, nebo co?

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é.

Ž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 ;)

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ý.

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.

Já na KVM nejvíc oceňuju to, že jeho jaderné moduly jsou součástí normální distribuce, takže nikdy nenastane problém při aktualizaci jádra a navíc můžu zapnout nádherné module.sig_enforce.

To řeší chocolatey u většiny běžného softwaru.