Prave dnes som zvacsoval disk vo vboxe, ktory pouzivam pre Windows 8, z 50 GB na 70 GB. Dalsie service packy sa nevedeli nainstalovat, kedze sa mu minulo miesto. A co mam nainstalovane? Len windows 8, MS Office a stado service packov. Data su na hostovi. Asi by som to mal vyhodit do kosa a zacat na zelenej luke s 8.1...
Ad M$ nenabizi zadny postup, jak zlikvidovat tu hruzu co je v winsxs - to bude asi mít nějaký důvod. WinSxS obsahuje originální verze komponent, které se pak hardlinkují kam je potřeba. Třeba notepad.exe v adresáři System32 je hardlinkovaný z WinSxS (a jednou v rámci WinSxS), většina ostatních souborů také. Když pak počítáte kolik vám Windows zabírají místa, počítáte díky hardlinkům soubory vícekrát.
WinSxS obsahuje i starší verze komponent, aby bylo možné odinstalovat patch a vrátit se ke starší verzi. Starší verze se dají odstranit pomocí Disk Cleanup wizardu puštěného na systémové soubory. Pak se samozřejmě nelze vrátit ke starším verzím komponent.
Drahý Jeronýmku, nevím co na tom disku máte, a je mi to i celkem jedno. Starší verze komponent se samozřejmě použije, pokud tu novou verzi odinstalujete. Zkuste si přes Add/Remove Programs zobrazit patche, a nějaký odinstalovat. Navíc máte v OS System Restore, který se umí vrátit k dřívějšímu stavu stroje (systémové soubory, konfiguraci, nainstalované aplikace, ale ne dokumenty). Tyhle věci na Linuxu neumíte, a proto žádnou historii instalací nepotřebujete.
A pokud na Windows podobné věci neumíte použít, můžete staré verze komponent Disk Cleanup wizardem puštěným na systémové soubory.
Zadny system restore nemam loliku, nevejde se na disk. Stejne jako se na nej nevejde swap, pripadne ta uspavaci hruza. na linuxu vazne nepotrebuju mit 158 verzi teze knihovny, protoze mi vsechny aplikace funguji s tou posledni.
Jen namatkou:
jakesi xact api ... 20x, x3d audio 6x, d3dx10 ...12x, d3dx9 ... 20x ... fakt uzasny.
Rozhodně se nic nepřekompilovává, jednak proto, že by se musely s každou aplikaci distribuovat zdrojové soubory jak aplikace tak všech použitých knihoven a jednak s každou verzí .NETu také SDK Windows. Každé .NET aplikaci stačí .NET runtime v příslušné verzi, pro kterou byla aplikace vytvořena.
Ad jestli během update jede v widích síť a je na ní firewall - během kterého update? Windows Update za běhu OS normálně stahuje aktualizace na pozadí, potřebuje k tomu síť, a firewall běží. Během bootu když běží síť a neběží ještě plný firewall, tak firewall pracuje s nějakou minimální sadou pravidel, než se dotáhne zbytek. Totéž se používá při hledání patchů během instalace OS.
Včera se mi instalovala hromada patchů. Nevím jak dlouho, protože to běželo na pozadí. Následný reboot s instalací zbývajících částí těch patchů trval okolo jedné minuty.
Ad přesně toho jsem se bál; "minimální sada pravidel" a funkční připojení do sítě - a čeho se na tom bojíte?
To bude spis tvym slepicim mozkem, kazdej jinej totiz pochopi, ze to nechal bezet jako jedinou aplikaci, protoze na to nehodlal cekat celej den. Nadto se na stroji kde to bezi stejne nic jinyho delat neda. Coz dokonce pochopil uz i tvuj chlebodarce, proto se 80% aktualizaci instaluje az pri vypnuti, coz sme tu probirali celkem nedavno, ale to si pri svy skleroze nemuzes pamatovat.
Jo, je uzasny kdyz cloveku padla, a ceka dalsi hodinu, nez se notes doaktualizuje ...
Ad spis tvym slepicim mozkem... pri svy skleroze... - opakuji: chovejte se slušně, tady nejste v ghettu. Ještě vám to nedošlo?
Ad to nechal bezet jako jedinou aplikaci, protoze na to nehodlal cekat celej den - další práce na stroji nemá na rychlost instalace aktualizací větší vliv. Pokud tedy tou další prací není aplikace požírající většinu paměti, CPU nebo diskového I/O.
Ad na stroji kde to bezi stejne nic jinyho delat neda - na tom vašem možná ne.
Ad proto se 80% aktualizaci instaluje az pri vypnuti - při rebootu se instalují ty věci, které nešlo instalovat za běhu OS, typicky z důvodu toho že aplikace běžela a nebylo možné ji aktualizovat. Jak jsem psal, včerejší reboot po aktualizacích u mě trval pod minutu, a je to zcela typický případ.
Nešlo o stav přihlášení, byly to takové ty tmavé obrazovky, co na tom běží procenta, tzn. při vypínání a při spouštění (tzn. s počítačem není možno cokoliv dělat). Běželo to fakt dlouho. Ty 4 restarty byly proto, že to neumí dohledat všechny opravy naráz, ale po každém restartu to našlo další.
No,aspon ja kdyz jsem jeste psal v .NET 2.0, tak binarky .NETu jsou v MSIL mezijazyku a ten se pote az na dane platforme (treba JITem) kompiluje, ale aby to nebrzdilo start, tak M$ v te dobe delal to, ze pri instalaci .NET binarky (nebo pri jejim prvnim spusteni na danem zarizeni) zkompiloval MSIL mezikod do strojoveho kodu daneho zarizeni a ulozil do GAC (global assembly cache)...jestli je to ted jinak, tak se omlouvam za mystifikaci :)
Kdyz instalujes patch do .NET frameworku, tak to trvá minutu, dvě.
Kdyz instalujes service pack, tak to trvá půl hodiny, max. hodinu (a to v případě, že máš fakt hodně pomalý počítač).
Tak to prosim Tě nevykládej nesmysly.
A znovu - pokud se instaluje nějaký update do .NETu, který vyžaduje aktualizaci native imagí (to je ta kompilace), tak tato kompilace NENÍ součástí instalace toho package. Tento "job" běží asynchronně až po instalaci a jejím uikončení.
Smankote, co me je do toho, cim byla ta kompilace vyvolana? Je uplne jedno, jestli se deje jako soucast instalace flastru na .Net nebo po te instalaci, me zajima, ze kazdy update .Netu je pricinou behu te kompilace a ze mi disk pul hodiny drnci a nemuzu pouzivat pocitac, protoze je pomaly, jak zdechlina. Tohle mozna nevadi na stroji s SSD, hafem pameti a silnym CPU. Na cemkoliv starsim je to o nervy. Nejake "neni soucasti instalace" a "bezi az po instalaci" je slovickareni.
Napr. o tom, ze ten .NET framework obsahuje viac zabudovanej funkcionality a kniznic ako JDK? Ze JDK je sice mensi, ale aj pomerne trivialne utilitky musis tahat z roznych org.apache a inych projektov? Javovy svet ma proste inu filozofiu - kazdu blbost vies riesit 3 roznymi sposobmi a knizncami, ktore si dotiahnes, v .NET to mas na tacke. Oba pristupy maju nieco do seba.