🚀 go-pugleaf

Sebastian Biały <heby@poczta.onet.pl>:
>  Gdzie tu wynika niezbedność restartu? Albo zmiany a.dll -> a1.dll
>  ->a2.dll ->a_final.dll. Wydawało by się że firmę która nie wie na co
>  kase wydawać stać na to aby napisać inteligentny solver update ALBO mają
>  to tak spierd... że żadna kasa nie pomaga.

Wynika to z lockowania plików przez aktualnie uruchomione procesy? W windowsie
lockowanie plików wydaje się być częścią projektu systemu. Osobiście nie podoba
mi się to, ale może w ten sposób łatwiej jest im kontrolować środowisko.

> > Długi czas instalacji zapewne zależy od odczytywania metadanych istniejących
> > bibliotek, odczytywania metadanych nowych bibliotek, weryfikacji zależności,
> > sprawdzaniu podpisów cyfrowych.
>
>  Zastanówmy się.
>
>  1) Co to sa metadane biblitek? Masz na mysli te kilobajty danych np. z
>  numerkiem wersji ktore są w dll i które odczytuje się jednym machnięciem
>  talerza dysku?

Jeden plik, jedno machnięcie. Tysiąc plików, tysiąc machnięć. Plus inne
operacje I/O w tym samym czasie, i między każdym machnięciem system czeka i nie
odczytuje niczego.

>  2) Co to jest weryfikacja zależności? To to trywialne posortowanie
>  topologiczne czegośtam?

Plus weryfikacja, że faktycznie są zainstalowane? (+ I/O)

>  3) Co to jest sprawdzanie podpisu? To ta prosta czynnośc odpalana na
>  procesorze z prędkością koło 2GHz?

Sugeruję sprawdzenie, ile faktycznie czasu zajmuje sprawdzenie podpisu
cyfrowego i pomnożenie tej wartości razy tysiąc ;). Do tego, instalując wiele
update'ów, pewnie niektóre podpisy sprawdzane są po kilka razy, dla każdego
uruchomienia, każdego załadowania, etc.

Inna sprawa, że gdy istnieje podpis wykorzystujący istniejący CAT zainstalowany
w systemie, trzeba odnaleźć prawidłowy CAT. Nie jestem pewien jak bardzo proces
ten jest zoptymalizowany (jeśli w ogóle), ale dochodzi tutaj dodatkowe
obciążenie dysku w poszukiwaniu odpowiedniego CAT'a, opóźniające ewentualne
inne requesty.

Plus, istnieją też dodatkowe opcje update'owania aktualnie używanych plików
systemowych o nazwie hot-patching. Polega to na modyfikowaniu początków
eksportowanych funkcji przez biblioteki systemowe tak, aby skakały do nowych
wersji funkcji, omijając stare, do pierwszego restartu. Dopiero po restarcie
pliki są podmieniane, całkowicie usuwając stare wersje funkcji. W oczywisty
sposób to wymaga synchronizacji z resztą części w systemie, wpływając na
dodatkowe opóźnienie.

>  I tak Wysoki sądzie kilka razy! Nie potrafie pojąć jak mozna było spierd...
>  tak prosta czynnośc jak podmiana kilkuset plików. Nawet glupi Linux robi to
>  o rzędy wielkości szybciej. I oba pozwalaja na pracę w trakcie. no może z
>  dokładnością do tego że update windowsa wywala *wszystko* do swapu przez co
>  praca polega raczej na wpatrywaniu się w kontrolkę dysku.

Kup więcej ramu ;)

> > Aby sprawdzić to bardziej dokładnie, należałoby pewnie uruchomić jakiś
> > monitor (procmon, filemon) podczas instalacji jakiegoś update'a.
>
>  Ale mi nikt nie płaci za profiling. Ponadto idę o zakład że tak prostymi
>  narzędziami niewiele zdziałam.

Nikt korporacji nie płaci za zaspokojenie Twoich zaciekawień, więc musisz sam
się o to postarać ;)

> Po prostu po tych 5 godzinach wiem, że gdybym ja napisal tak gówniany updater
> do czegokolwiek to by mnie zwolnili a MS robi z tego ficzer. Szukam więc
> uzasadnienia co jest tak skomplikowanego w trywialnej czynności.

Gdybyś napisał udater tylko podmieniający pliki i już, wtedy miałbyś więcej
problemów na głowie niż czasu na jego rozwój ;)

Jednocześnie nie twierdzę, że ten proces mi się podoba, ani, że jest
maksymalnie wydajny. Z tego co zauważyłem jednak, update'y rzadko wywalają
windowsa (rzadziej, niż chciałbym to przyznać). W całej swojej "karierze"
zauważyłem tylko jeden przypadek, gdzie Windows zapętlił się między
instalowaniem, wyświetlaniem błędu, robieniem rollbacka, restartem i
instalowaniem ponownie, tylko po to, żeby wyświetlić błąd i próbować
rollbackować, przy czym system był postawiony na VMce. Z kolei wywalonych
update'ów na Linuchach widziałem masę ;)