Discussion:
Windows 7 się aktualizuje.
(Wiadomość utworzona zbyt dawno temu. Odpowiedź niemożliwa.)
Sebastian Biały
2013-11-24 15:48:26 UTC
Permalink
1. Start, 8MBit, Win7. Komputer nie włączony od trzech lat, właśnie
przelutowalem chipset grafiki w laptopie i się odpalił.
2. Update, coś koło 50 poprawek. Restar.
3. Update, coś koło 10 poprawek. Restart.
4. Update, coś kolo 2 poprawek. Nie ma restartu.
5. Brak poprawek. Można pracować. Sprawdzam 30 minut później jest jedna.
6. Instaluje się, to service pack. Restart. Tym razem cieżki, coś trzeba
przez godzinę robić w trakcie restartu.
7. Update, 70 poprawek. Restart i robienie czegoś przez 20 minut.
8. Update, 3 poprawki, restart. Martwy. Pomaga przywrocenie sterownika
grafiki ktory był w restarcie.
9. Update. Została tylko jedna!
10. Można pracować. Upłyneło około 5 godzin z czego kilkadziesiąt razy
zerkałem czy już trzeba restartować i dlaczego pasek postepu od pół
godziny nie drgnie.
11. Dzień następny: z nienacka 7 poprawek. Restart.
12. Do dzisiaj cisza.

Pytanie brzmi następująco: w jaki sposób należy wyjaśnić takie a nie
inne działanie tego mechanizmu? Zaznaczam że jestem programista i nie
akceptuje wyjaśnień marketingowych zaczynających się od amejzing.

Liczę wydajnośc dysku i dałbym radę w 5 godzin niezliczoną ilośc razy go
przekopiować z prawa na lewo i z powrotem. Co robi Windows że nie daje
rady podmienić kilku(set) plików dll o rozmiarze może ze 2GB w roządnym
czasie i za jednym razem?
Smok Eustachy
2013-11-24 16:11:40 UTC
Permalink
W dniu 24.11.2013 16:48, Sebastian Biały pisze:
/..../
Post by Sebastian Biały
Pytanie brzmi następująco: w jaki sposób należy wyjaśnić takie a nie
inne działanie tego mechanizmu? Zaznaczam że jestem programista i nie
akceptuje wyjaśnień marketingowych zaczynających się od amejzing.
Ha ha ha to zrób sobie aktualizację z 8 do 8.1

Producenty Windows nie biorą pod uwagę takiego scenariusza. Jak już
robisz reinstal, czy coś, to znaczy ze jesteś prof.
No izmiany w rejestrze, itp: łatwiej, żeby się to robiło po kolei.
toslaw
2013-11-24 19:01:06 UTC
Permalink
Post by Sebastian Biały
Pytanie brzmi następująco: w jaki sposób należy wyjaśnić takie a nie
inne działanie tego mechanizmu? Zaznaczam że jestem programista i nie
akceptuje wyjaśnień marketingowych zaczynających się od amejzing.
Liczę wydajnośc dysku i dałbym radę w 5 godzin niezliczoną ilośc razy go
przekopiować z prawa na lewo i z powrotem. Co robi Windows że nie daje
rady podmienić kilku(set) plików dll o rozmiarze może ze 2GB w roządnym
czasie i za jednym razem?
Jeden zbiór poprawek zapewne zależy od innego zbioru, dlatego najpierw należy
zainstalować ten pierwszy, aby można było zainstalować drugi.

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. To wszystko dzieje się zapewne przy pomocy
interfejsów COM/WMI, których tworzenie instancji pociąga za sobą zapewne
tworzenie innych instancji obiektów pomocniczych. Pewnie nie wystarczy samo
skopiowanie pliku A do miejsca K, tylko trzeba to skopiowanie jakoś
zsynchronizować z systemem, dlatego może niektóre usługi muszą
zostać zatrzymane, niektóre semafory muszą zostać zajęte.

Aby sprawdzić to bardziej dokładnie, należałoby pewnie uruchomić jakiś monitor
(procmon, filemon) podczas instalacji jakiegoś update'a.

Tak tylko dodam od siebie, że głównym czynnikiem, który spowodował popchnięcie
mnie w celu przesiadki na inny system operacyjny był właśnie długi czas
oczekiwania na zainstalowanie głupiego programu z pakietu .MSI. Podejrzewam, że
instalowanie update'ów i MSI posiadają wiele wspólnych cech.
Sebastian Biały
2013-11-24 20:43:44 UTC
Permalink
Post by toslaw
Jeden zbiór poprawek zapewne zależy od innego zbioru, dlatego najpierw należy
zainstalować ten pierwszy, aby można było zainstalować drugi.
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.
Post by toslaw
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?

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

3) Co to jest sprawdzanie podpisu? To ta prosta czynnośc odpalana na
procesorze z prędkością koło 2GHz?
Post by toslaw
To wszystko dzieje się zapewne przy pomocy
interfejsów COM/WMI, których tworzenie instancji pociąga za sobą zapewne
tworzenie innych instancji obiektów pomocniczych. Pewnie nie wystarczy samo
skopiowanie pliku A do miejsca K, tylko trzeba to skopiowanie jakoś
zsynchronizować z systemem, dlatego może niektóre usługi muszą
zostać zatrzymane, niektóre semafory muszą zostać zajęte.
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.
Post by toslaw
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. 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.
Marek
2013-11-25 00:07:38 UTC
Permalink
On Sun, 24 Nov 2013 21:43:44 +0100, Sebastian
Post by Sebastian Biały
Ale mi nikt nie płaci za profiling. Ponadto idę o zakład że tak prostymi
narzędziami niewiele zdziałam. 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.
Myślę że taki update to skomplikowany (amajzing) proces rozwiązywania
problemów niestniejących w innych systemach, z którego na pawno są
dumni programisci MS. I na 100% jestem pewien, że samo kopiowanie
pliku z a do b to może promil aktywności tego zadania.
--
Marek
toslaw
2013-11-26 08:47:34 UTC
Permalink
Post by Sebastian Biały
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.
Post by Sebastian Biały
Post by toslaw
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.
Post by Sebastian Biały
2) Co to jest weryfikacja zależności? To to trywialne posortowanie
topologiczne czegośtam?
Plus weryfikacja, że faktycznie są zainstalowane? (+ I/O)
Post by Sebastian Biały
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.
Post by Sebastian Biały
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 ;)
Post by Sebastian Biały
Post by toslaw
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ć ;)
Post by Sebastian Biały
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ę ;)
Sebastian Biały
2013-11-26 19:33:41 UTC
Permalink
Post by toslaw
Post by Sebastian Biały
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ęć.
Czyli jakieś 0.1sek dla mojego dysku. Aaaa zapomniałem, głowica, pewno z
jakieś 30 sekund.
Post by toslaw
Plus inne
operacje I/O w tym samym czasie, i między każdym machnięciem system czeka i nie
odczytuje niczego.
Obawiam się że jak zerkniesz w trqakcje update na dysk i cpu to bywają
chwilę że nic się nie dzieje. To zapewne te mityczne "stawianie semaforów".
Post by toslaw
Post by Sebastian Biały
2) Co to jest weryfikacja zależności? To to trywialne posortowanie
topologiczne czegośtam?
Plus weryfikacja, że faktycznie są zainstalowane? (+ I/O)
To system jest taki tępy że nie wie co ma w systemie? Łomatko.
Post by toslaw
Post by Sebastian Biały
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.
Wiadomo. Jak sprawdzisz 50 razy to masz 50 razy lepiej sprawdzone niż
jeden raz, czyli jakieś 4900% większa pewność.
Post by toslaw
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.
Hmmm.... czekaj, chcesz mi powiedzieć że po 30 latach developingu
kernela nie da się nic podmienić w locie tylko trzeba stosować chwyty
rodem z Amigi (tam się patchowało wywołania biblioteczne)?
Post by toslaw
Kup więcej ramu ;)
Nie istnieje rozsądna ilość. Na maszynce obok z 8GB ram instalacja
Visuala wypierd... wszystko do swapa. Mimo że sama 8GB raczej nie ma.
Ten mechanizm pożera pamięć z powodów trudnych do ogarnięcia przeze mnie.
Post by toslaw
Post by Sebastian Biały
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 ;)
Naprawdę widzisz tylko taką alternatywę?
mk4
2013-12-06 23:59:50 UTC
Permalink
Post by Sebastian Biały
Wiadomo. Jak sprawdzisz 50 razy to masz 50 razy lepiej sprawdzone niż
jeden raz, czyli jakieś 4900% większa pewność.
Jesli rzeczywiscie jestes progrmaista i takie cos wysmazyles to ciezko
uznac, ze rzeczywiscie jestes. Wystarczy napisac nieco bardziej
skomplikowany soft (a najlepiej, zeby byl ladnie rozbity na komponenty)
i takie zjawisko jak kilkukrotne sprawdzanie czegos tam pojawia sie
samoistnie. Ale nie o tym chcialem.

A raczej o tym, ze rzeczywiscie aktualizacje dzialaja dlugo - niemniej
biorac pod uwage skale zjawiska i liczbe wersji systemu trzeba im oddac,
ze dzialaja dobrze.

A czemu dlugo? Po pierwsz zdaje sie (nie sprawdzalem kazdej aktualizacji
w kazdej konfiguracji) kazda aktualizacje mozna odinstalowac. A zeby to
dalo sie zrobic to dla kazdej trzeba gdzies zarchiwizowac pliku,
pozapiasywac pewinie konfiguracje itd. itp.
Pozniej w nwoszych systemach robi cos co sie nazywa "Restore point" -
robi to z tego co widzialem dla glowniejszych aktualizacji - ale jednak
dosc czesto. Ta operacja trwa wlasnie dosc dlugo. A robi to po to zeby
proces aktualizacji nie padl i w razie czego byl stanie odzyskac stabilnosc.

Wniosek z tego taki, ze te aktualizacje na Windowsie po prostu dzialaja
(i to juz od dosc dlugiego czasu - kilka lat na pewno) podczas gdy w tym
samym czasie (bylo to kolo roku 2009/2010) aktualizacja maszyny z
linuksem sprawila, ze polowa rzeczy po prostu przestala dzialac (a
zaktualizowalem tylko dlatego, ze juz mnie wkurzalo nagabywanie przez
ten aktualizator - z uporem maniaka ciagle przypominal i zachecal - no i
w koncu sie "zlamalem") - miedzy innymi jakies rzeczy, ktore sam
kompilowalem.
W tamtym czasie mozna bylo uznac ze cos takiego jak proces aktualizacji
systemu na linuksie nie istnial w ogole. Jak jest teraz to nie wiem -
niemniej ze wzgledu na takie a nie inne rozwiazanie pewnie niewiele lepiej.
W firmie czesc softu jest na linuksach i o ile dziala to dziala - ale
jak trzeba do jakiejs starszej wersji (a trzeba bo uzytkownik nie zgadza
sie na zmiane) dograc cos nowszego (co po ciaga za soba las zaleznosci
niczym puszcza amazonska) to sie dopiero zaczyna zabawa.

Zaraz wyskocza niektorzy "ze sie da". No dac to sie da - tylko po co ma
sie dawac jak mozna to zrobic w sposob cywylizowany i elegancki - a ze
wiecej czasu zajmie? Coz takie zycie. Faktem jest, ze na maszynie "z
epoki odpowiadajacej systemowi, ktory aktualizujemy" zwykle dzieje sie
to wystarczajaco szybko.

Przyznasz tez, ze wlaczenie systemu po 3 latach to jednak sytuacja
wyjatkowa i poswiecac np. stabilnosc calego systemu aktualizacji tylko
po to zeby dla tak sporadycznych przypadkow dzialaly one szybko byloby
kiepskim posunieciem biznesowym.

Ale kazdy patrzy ze swojej dziurki - jedni maja piekny widok po horyzont
a inni szara sciane budynku po niebo.
--
mk4
Sebastian Biały
2013-12-07 07:59:58 UTC
Permalink
Post by mk4
Post by Sebastian Biały
Wiadomo. Jak sprawdzisz 50 razy to masz 50 razy lepiej sprawdzone niż
jeden raz, czyli jakieś 4900% większa pewność.
Jesli rzeczywiscie jestes progrmaista i takie cos wysmazyles to ciezko
uznac, ze rzeczywiscie jestes.
:D Wiesz co to jest ironia?
Post by mk4
A czemu dlugo? Po pierwsz zdaje sie (nie sprawdzalem kazdej aktualizacji
w kazdej konfiguracji) kazda aktualizacje mozna odinstalowac.
Robisz to codziennie, prawda? Szczególnie jak wykryjesz slabośc
kryptograficzną w nowym sha1?
Post by mk4
A zeby to
dalo sie zrobic to dla kazdej trzeba gdzies zarchiwizowac pliku,
pozapiasywac pewinie konfiguracje itd. itp.
Straszne. Trzeba skopiować kilka plików obok. To jest wyzwanie dla
dzisiejszych dysków!
Post by mk4
Pozniej w nwoszych systemach robi cos co sie nazywa "Restore point" -
robi to z tego co widzialem dla glowniejszych aktualizacji - ale jednak
dosc czesto. Ta operacja trwa wlasnie dosc dlugo. A robi to po to zeby
proces aktualizacji nie padl i w razie czego byl stanie odzyskac stabilnosc.
A czemu trwa długo? Na zfs nie trwa długo.
Post by mk4
Wniosek z tego taki, ze te aktualizacje na Windowsie po prostu dzialaja
Odważne. Padły mi kilka razy niszcząc system. Fakt, aktulalizowałem nie
gołe przeglądarki facebooka tylko komputery na ktorych coś było.
Widocznie takie zastosowanie nie wchodzi w model biznesowy MS.
Post by mk4
(i to juz od dosc dlugiego czasu - kilka lat na pewno) podczas gdy w tym
samym czasie (bylo to kolo roku 2009/2010) aktualizacja maszyny z
linuksem sprawila, ze polowa rzeczy po prostu przestala dzialac (a
zaktualizowalem tylko dlatego, ze juz mnie wkurzalo nagabywanie przez
ten aktualizator - z uporem maniaka ciagle przypominal i zachecal - no i
w koncu sie "zlamalem") - miedzy innymi jakies rzeczy, ktore sam
kompilowalem.
Czy aby na pewno jestes pewny że warto porownywać *darmowy* system
pisany chaotycznie przez pryszczersów z systemem w który wpompowano
miliardy dolarów i zatrudnianio najlepszych z najlepszych? To taki
rodzaj wywieszenia białej flagi "no ale oni też zjebali panie kierowniku"?
Post by mk4
W tamtym czasie mozna bylo uznac ze cos takiego jak proces aktualizacji
systemu na linuksie nie istnial w ogole. Jak jest teraz to nie wiem -
niemniej ze wzgledu na takie a nie inne rozwiazanie pewnie niewiele lepiej.
Oczywiscie nie jest dobrze. Nic z tego nie wynika dla MS.
Post by mk4
W firmie czesc softu jest na linuksach
Co mnie obchodzi linux? Dlaczego mój Windows w sposób *bezwzględny* jest
gówniany?
Post by mk4
Ale kazdy patrzy ze swojej dziurki - jedni maja piekny widok po horyzont
a inni szara sciane budynku po niebo.
Zauważyłem taką prawidlowośc, że większość kiepskich cech Windowsa
niezykle łatwo jest wyjąsnić pokazując że linux jest do dupy.

No więc oba sa do dupy. Teraz zastanów się dlaczego nie oczekuje że
Linux bedzie lepszy (już to pisałem).
Marek
2013-11-27 00:00:00 UTC
Permalink
Post by toslaw
Plus, istnieją też dodatkowe opcje update'owania aktualnie
używanych plików
Post by toslaw
systemowych o nazwie hot-patching. Polega to na modyfikowaniu
początków
Post by toslaw
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.
To jest jakiś absurd. Rozwiązanie, które od razu by design wymaga
restartu. 20 lat developingu i ciągle mają w tym MS jakas fixacje na
punkcie tych restartów. A unixach wystarczy aby proces upate'u zrobil
unlink lib.so a nastepnie cp newlib.so lib.so. Procesy uruchomione i
zlinkowane z lib.so (starą wersją) będą nadal działać ze starą lib
(unlink nie usunie fizycznie z dysku otwartej lib przez inny proces,
plik znika tylko z dirlist) a nowo ładowane procesy już będą
zlinkowane z nowa wersją lib.so. Stare procesy/usługi wystarczy
zrestartować aby skorzystały już z nowych funkcji lib.so.
I nie ma potrzeby restartowania systemu. Rozwiązanie proste i
genialne w swojej prostocie, bo wykorzystuje natywne mechanizmy
dostępu do fs.
--
Marek
Tomasz Sowa
2013-11-27 04:15:00 UTC
Permalink
Stare procesy/usługi wystarczy zrestartować aby skorzystały już z
nowych funkcji lib.so.
I nawet zadziałają jak się api biblioteki nie zmieni. A w normalnych
uniksach to biblioteka będzie linkiem symbolicznym do tej prawdziwej
biblioteki, na przykład:
/home/tomek$ ll /usr/lib/libbz2.*
-r--r--r-- 1 root wheel 80702 27 wrz 16:13 /usr/lib/libbz2.a
lrwxr-xr-x 1 root wheel 11 28 wrz 08:29 /usr/lib/libbz2.so@ ->
libbz2.so.4
-r--r--r-- 1 root wheel 71720 28 wrz 08:29 /usr/lib/libbz2.so.4

I podczas linkowania z libbz2.so połączy się tak naprawdę z libbz2.so.4
a po upgrejdzie systemu jeśli libbz się zmieni to zostanie przeniesione
do /usr/lib/compat (a to jest katalog dalej dostępny dla linkera
dynamicznego) i program korzystający z niej dalej działa normalnie. A
nowo kompilowane programy zlinkują się już z nową wersją biblioteki.
--
Tomek
toslaw
2013-11-27 05:13:40 UTC
Permalink
Post by Tomasz Sowa
Stare procesy/usługi wystarczy zrestartować aby skorzystały już z
nowych funkcji lib.so.
I nawet zadziałają jak się api biblioteki nie zmieni.
Łatwiej powiedzieć, niż zrobić. Na Linuxach praktycznie wymaga to rekompilacji
programu, ponieważ pilnowanie stabilności ABI jest trudne i poza kontrolą
autora programu. Na unixach sytuacja pewnie wygląda podobnie, bo to nie sposób
jest problematyczny, tylko implementacja organizacji procesu ;)

Z tego powodu dużo komercyjnego oprogramowania na Linuxach pakuje swoje własne
wersje bibliotek do swojej dystrybucji programu, omijając te systemowe, np.
VMware, Steam.
Post by Tomasz Sowa
A w normalnych uniksach to biblioteka będzie linkiem symbolicznym do tej
/home/tomek$ ll /usr/lib/libbz2.*
-r--r--r-- 1 root wheel 80702 27 wrz 16:13 /usr/lib/libbz2.a
libbz2.so.4
-r--r--r-- 1 root wheel 71720 28 wrz 08:29 /usr/lib/libbz2.so.4
I podczas linkowania z libbz2.so połączy się tak naprawdę z libbz2.so.4
a po upgrejdzie systemu jeśli libbz się zmieni to zostanie przeniesione
do /usr/lib/compat (a to jest katalog dalej dostępny dla linkera
dynamicznego) i program korzystający z niej dalej działa normalnie. A
nowo kompilowane programy zlinkują się już z nową wersją biblioteki.
Na jakich dystrybucjach istnieje /usr/lib/compat? Na BSD?

Raczej nie na Linuxach typu Arch ani na Fedora ;)
Tomasz Sowa
2013-11-28 20:04:15 UTC
Permalink
Post by toslaw
Post by Tomasz Sowa
I nawet zadziałają jak się api biblioteki nie zmieni.
Łatwiej powiedzieć, niż zrobić.
Na BSD zrobili.
Post by toslaw
Na jakich dystrybucjach istnieje /usr/lib/compat? Na BSD?
Właśnie na BSD.
Post by toslaw
Raczej nie na Linuxach typu Arch ani na Fedora ;)
I dlatego często mają problemy przy aktualizacji.
--
Tomek
toslaw
2013-11-27 04:59:45 UTC
Permalink
Post by Marek
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.
To jest jakiś absurd. Rozwiązanie, które od razu by design wymaga
restartu. 20 lat developingu i ciągle mają w tym MS jakas fixacje na
punkcie tych restartów. A unixach wystarczy aby proces upate'u zrobil
unlink lib.so a nastepnie cp newlib.so lib.so. Procesy uruchomione i
zlinkowane z lib.so (starą wersją) będą nadal działać ze starą lib
(unlink nie usunie fizycznie z dysku otwartej lib przez inny proces,
plik znika tylko z dirlist) a nowo ładowane procesy już będą
zlinkowane z nowa wersją lib.so. Stare procesy/usługi wystarczy
zrestartować aby skorzystały już z nowych funkcji lib.so.
I nie ma potrzeby restartowania systemu. Rozwiązanie proste i
genialne w swojej prostocie, bo wykorzystuje natywne mechanizmy
dostępu do fs.
Chodzi chyba właśnie o to, aby wprowadzić nowe wersje funkcji BEZ konieczności
restartu? ;)

Z kolei restart jest spowodowany tym, że Windows "by design" lockuje pliki po
otwarciu. Nie wiem czym z kolei jest to spowodowane, ale być może tym, że pliki
wykonywalne PE w Windowsie posiadają dość popularną sekcję z zasobami, w
których znajdują się dane binarne wykorzystywane w programie, podzielone na
kategorie językowe. Program po uruchomieniu często doczytuje potrzebne
informacje z pliku wykonywalnego w miarę jego działania, a sam windows nie
ładuje tej sekcji do pamięci. Przy podmianie tego pliku na nową wersję, nie
byłoby możliwości załadowania/sprawdzenia starych zasobów. Może dlatego decyzja
została podjęta, aby uniemożliwić usuwanie/modyfikację pliku ;)

Z kolei w ELFach na UNIXach ewentualne zasoby kompilowane są w postaci
zmiennych bezpośrednio w programie, więc są teoretycznie częścią sekcji danych
kodu. Są ładowane od razu ze wszystkim do pamięci i na chwilę działania
programu plik wykonywalny jest zbędny, aż do czasu zamknięcia programu.
Marek
2013-11-27 08:34:06 UTC
Permalink
Post by toslaw
kodu. Są ładowane od razu ze wszystkim do pamięci i na chwilę działania
programu plik wykonywalny jest zbędny, aż do czasu zamknięcia programu.
Niekoniecznie, nie spotkałeś się z "text file busy" przy próbie
manipulacji pliku uruchomionej binarki? ;)
--
Marek
toslaw
2013-11-27 08:40:39 UTC
Permalink
Post by toslaw
kodu. Są ładowane od razu ze wszystkim do pamięci i na chwilę działania
programu plik wykonywalny jest zbędny, aż do czasu zamknięcia programu.
Niekoniecznie, nie spotkałeś się z "text file busy" przy próbie manipulacji
pliku uruchomionej binarki? ;)
Na Linuxie? Nie. Choć faktem jest, że nie mam w zwyczaju modyfikowania tutaj
uruchomionych binarek.

Zrobiłem jednak mały test kompilując program czekający na naciśnięcie enter'a.
Podczas jego działania wpisałem mu śmieci vim'em, zapisując plik. Vim nie
zgłosił przeciwu ;)

Na Windowsie mam to co krok dla różnych plików, wykonywalnych lub nie, co mnie
mocno irytuje.
Kajetan Staszkiewicz
2013-11-27 16:36:44 UTC
Permalink
Post by toslaw
Z kolei w ELFach na UNIXach ewentualne zasoby kompilowane są w postaci
zmiennych bezpośrednio w programie, więc są teoretycznie częścią sekcji
danych kodu. Są ładowane od razu ze wszystkim do pamięci i na chwilę
działania programu plik wykonywalny jest zbędny, aż do czasu zamknięcia
programu.
Windows-prawda, w Linuksie plik wykonywalny jest doczytywany po kawałku.
Cały jest mmapowany do pamięci, a każda brakująca strona generuje page-fault
i jest doczytywana w miarę potrzeb.
--
| pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS |
| Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net |
| Vegeta | www: http://vegeta.tuxpowered.net |
`------------------------^---------------------------------------'
toslaw
2013-11-27 17:41:55 UTC
Permalink
Post by Kajetan Staszkiewicz
Post by toslaw
Z kolei w ELFach na UNIXach ewentualne zasoby kompilowane są w postaci
zmiennych bezpośrednio w programie, więc są teoretycznie częścią sekcji
danych kodu. Są ładowane od razu ze wszystkim do pamięci i na chwilę
działania programu plik wykonywalny jest zbędny, aż do czasu zamknięcia
programu.
Windows-prawda, w Linuksie plik wykonywalny jest doczytywany po kawałku.
Cały jest mmapowany do pamięci, a każda brakująca strona generuje page-fault
i jest doczytywana w miarę potrzeb.
Mea culpa. Faktycznie wygląda na to, że i Linux uniemożliwia modyfikację
załadowanego programu. Co ciekawe, pozwala na jego usunięcie, co sugerowałoby
trzymanie otwartego inode, zamiast uchwytu bazującego na nazwie pliku.

Mój wcześniejszy eksperyment w postaci modyfikacji uruchomionego exeka vim'em
był bez sensu, ponieważ vim wydaje się usuwać plik i tworzyć nowy, przy użyciu
opcji ":w!" (można zauważyć inny inode po zapisie, przy uzyciu ls -i).
Kajetan Staszkiewicz
2013-11-27 18:07:28 UTC
Permalink
Post by toslaw
Post by Kajetan Staszkiewicz
Post by toslaw
Z kolei w ELFach na UNIXach ewentualne zasoby kompilowane są w postaci
zmiennych bezpośrednio w programie, więc są teoretycznie częścią sekcji
danych kodu. Są ładowane od razu ze wszystkim do pamięci i na chwilę
działania programu plik wykonywalny jest zbędny, aż do czasu zamknięcia
programu.
Windows-prawda, w Linuksie plik wykonywalny jest doczytywany po kawałku.
Cały jest mmapowany do pamięci, a każda brakująca strona generuje
page-fault i jest doczytywana w miarę potrzeb.
Mea culpa. Faktycznie wygląda na to, że i Linux uniemożliwia modyfikację
załadowanego programu. Co ciekawe, pozwala na jego usunięcie, co
Przyuważ, że funkcją "usuwającą" plik jest unlink, polecam lekturę jej
manuala.
Post by toslaw
sugerowałoby trzymanie otwartego inode, zamiast uchwytu bazującego na
nazwie pliku.
Czym niby ma być "uchwyt bazujący na nazwie pliku"?
Post by toslaw
Mój wcześniejszy eksperyment w postaci modyfikacji uruchomionego exeka
vim'em był bez sensu, ponieważ vim wydaje się usuwać plik i tworzyć nowy,
przy użyciu opcji ":w!" (można zauważyć inny inode po zapisie, przy uzyciu
ls -i).
Po pierwsze: sprawdź sobie, jak w języku polskim należy używać apostrofu. Po
drugie: tak, eksperyment był bez sensu, proces trzyma cały czas swój plik
wykonywalny otwarty, odsyłam jeszcze raz do man unlink.
--
| pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS |
| Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net |
| Vegeta | www: http://vegeta.tuxpowered.net |
`------------------------^---------------------------------------'
toslaw
2013-11-27 18:45:50 UTC
Permalink
Post by Kajetan Staszkiewicz
Post by toslaw
Mea culpa. Faktycznie wygląda na to, że i Linux uniemożliwia modyfikację
załadowanego programu. Co ciekawe, pozwala na jego usunięcie, co
Przyuważ, że funkcją "usuwającą" plik jest unlink, polecam lekturę jej
manuala.
Przyuważyłem, co sugerowała druga część tego zdania, którą zgrabnie zrzuciłeś
do kolejnego cytatu, aby móc tu wtrącić swoje świetliste objawienie ;)
Post by Kajetan Staszkiewicz
Post by toslaw
sugerowałoby trzymanie otwartego inode, zamiast uchwytu bazującego na
nazwie pliku.
Czym niby ma być "uchwyt bazujący na nazwie pliku"?
To samo, co znaczy to w windowsie. Czyli, pomijając fakt istnienia unikalnego
identyfikatora dla każdego pliku w postaci wpisu w tablicy Mft, windows i tak
wiąże uchwyt z nazwą pliku.
Post by Kajetan Staszkiewicz
Post by toslaw
Mój wcześniejszy eksperyment w postaci modyfikacji uruchomionego exeka
vim'em był bez sensu, ponieważ vim wydaje się usuwać plik i tworzyć nowy,
przy użyciu opcji ":w!" (można zauważyć inny inode po zapisie, przy uzyciu
ls -i).
Po pierwsze: sprawdź sobie, jak w języku polskim należy używać apostrofu. Po
drugie: tak, eksperyment był bez sensu, proces trzyma cały czas swój plik
wykonywalny otwarty, odsyłam jeszcze raz do man unlink.
Dziękuję ci za wytłumaczenie mi tego, co odkryłem chwilę wcześniej.
Piotr B. [pb2004]
2013-11-27 19:39:50 UTC
Permalink
Post by Marek
Post by toslaw
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.
To jest jakiś absurd. Rozwiązanie, które od razu by design wymaga
restartu. 20 lat developingu i ciągle mają w tym MS jakas fixacje na
punkcie tych restartów. A unixach wystarczy aby proces upate'u zrobil
unlink lib.so a nastepnie cp newlib.so lib.so. Procesy uruchomione i
zlinkowane z lib.so (starą wersją) będą nadal działać ze starą lib
(unlink nie usunie fizycznie z dysku otwartej lib przez inny proces,
plik znika tylko z dirlist) a nowo ładowane procesy już będą
zlinkowane z nowa wersją lib.so. Stare procesy/usługi wystarczy
zrestartować aby skorzystały już z nowych funkcji lib.so.
I nie ma potrzeby restartowania systemu. Rozwiązanie proste i
genialne w swojej prostocie, bo wykorzystuje natywne mechanizmy
dostępu do fs.
Pod Uniksami w przeciwieństwie do Windowsa nie ma po prostu działającego
mechanizmu file lockingu[1][2] więc nie było dotąd motywacji aby
realizować aktualizację prawidłowo. Jednak to się zmienia np. Fedora
idzie drogą Windowsa z Offline System Updates[3]. Inne dystrybucje także
są świadome problemów z takim działaniem aktualizacji. Debian od zawsze
upgrade dystrybucji zalecał robić nie spod środowiska graficznego.

1. http://0pointer.de/blog/projects/locking.html
2. http://0pointer.de/blog/projects/locking2
3. http://fedoraproject.org/wiki/Features/OfflineSystemUpdates
--
Piotr Borkowski
Smok Eustachy
2013-11-27 22:54:29 UTC
Permalink
Post by Marek
/.../
To jest jakiś absurd. Rozwiązanie, które od razu by design wymaga
restartu. 20 lat developingu i ciągle mają w tym MS jakas fixacje na
punkcie tych restartów. A unixach wystarczy aby proces upate'u zrobil
unlink lib.so a nastepnie cp newlib.so lib.so. Procesy uruchomione i
zlinkowane z lib.so (starą wersją) będą nadal działać ze starą lib
(unlink nie usunie fizycznie z dysku otwartej lib przez inny proces,
plik znika tylko z dirlist) a nowo ładowane procesy już będą zlinkowane
z nowa wersją lib.so. Stare procesy/usługi wystarczy zrestartować aby
skorzystały już z nowych funkcji lib.so.
I nie ma potrzeby restartowania systemu. Rozwiązanie proste i genialne w
swojej prostocie, bo wykorzystuje natywne mechanizmy dostępu do fs.
I się okazuje, że jakiś proces korzysta 5 lat ze starej, zabugowanej i
dziurawej lib.so.
Bo się wzięło i niezrestartowało.

2. Z Firefoxem to działa średnio.
Raffaello
2013-11-25 07:12:14 UTC
Permalink
Post by toslaw
Post by Sebastian Biały
Pytanie brzmi następująco: w jaki sposób należy wyjaśnić takie a nie
inne działanie tego mechanizmu? Zaznaczam że jestem programista i nie
akceptuje wyjaśnień marketingowych zaczynających się od amejzing.
Liczę wydajnośc dysku i dałbym radę w 5 godzin niezliczoną ilośc razy go
przekopiować z prawa na lewo i z powrotem. Co robi Windows że nie daje
rady podmienić kilku(set) plików dll o rozmiarze może ze 2GB w roządnym
czasie i za jednym razem?
Jeden zbiór poprawek zapewne zależy od innego zbioru, dlatego najpierw
należy zainstalować ten pierwszy, aby można było zainstalować drugi.
A nie można od razu zainstalować najnowszego softu?
To co napisałeś brzmi tak:
- trzeba zainstalować StarOffice 1.0
- potem OpenOffice 1.0
- Potem OO 2.0
- 3.0
Na koniec zainstalować LibreOffice 4.2 i działa.
Bezsensu!
Post by toslaw
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.
No patrz - a u mnie na Gentoo emerge -upDN world to tylko kilka minut...?
I też sprawdza zależności między tysiącem pakietów czy jakoś tak. I to
napisanych przez różne "firmy".
Post by toslaw
To wszystko dzieje się zapewne przy pomocy
interfejsów COM/WMI, których tworzenie instancji pociąga za sobą zapewne
tworzenie innych instancji obiektów pomocniczych. Pewnie nie wystarczy samo
skopiowanie pliku A do miejsca K, tylko trzeba to skopiowanie jakoś
zsynchronizować z systemem, dlatego może niektóre usługi muszą
zostać zatrzymane, niektóre semafory muszą zostać zajęte.
Ale to nie są pliki po 10 GB, tylko po kilka MB maksymalnie. Współczesy dysk
twardy jak takie coś łyka to po sekundzie zapomina, że coś takiego zrobił!
Nawet jeśli tych plików masz 1.000 - to i tak zmieścisz czas ich
skopiowania/przeniesienia w 10-15 minutach. Jeśli do tego dodasz czas na
podmianę informacji w jakimś pliku o tych plikach - kolejne kilka sekund.
Ale skąd 5 godzin? I PO CO! instalować kolejne wersje bibliotek, skoro można
od razu pobrać najnowsze?
Piotr B. [pb2004]
2013-11-25 18:19:50 UTC
Permalink
Post by Sebastian Biały
1. Start, 8MBit, Win7. Komputer nie włączony od trzech lat, właśnie
przelutowalem chipset grafiki w laptopie i się odpalił.
2. Update, coś koło 50 poprawek. Restar.
3. Update, coś koło 10 poprawek. Restart.
4. Update, coś kolo 2 poprawek. Nie ma restartu.
5. Brak poprawek. Można pracować. Sprawdzam 30 minut później jest jedna.
6. Instaluje się, to service pack. Restart. Tym razem cieżki, coś trzeba
przez godzinę robić w trakcie restartu.
7. Update, 70 poprawek. Restart i robienie czegoś przez 20 minut.
8. Update, 3 poprawki, restart. Martwy. Pomaga przywrocenie sterownika
grafiki ktory był w restarcie.
9. Update. Została tylko jedna!
10. Można pracować. Upłyneło około 5 godzin z czego kilkadziesiąt razy
zerkałem czy już trzeba restartować i dlaczego pasek postepu od pół
godziny nie drgnie.
11. Dzień następny: z nienacka 7 poprawek. Restart.
12. Do dzisiaj cisza.
Pytanie brzmi następująco: w jaki sposób należy wyjaśnić takie a nie
inne działanie tego mechanizmu? Zaznaczam że jestem programista i nie
akceptuje wyjaśnień marketingowych zaczynających się od amejzing.
Co tu wyjaśniać? Ten mechanizm nie został zaprojektowany do takiego
scenariusza użycia. Poprawki powinny pobrać się w tle i instalować
automatycznie zgodnie z harmonogramem, priorytetem i wymagając jak
najmniej pobierania(poprawki delta). Dlatego pewnie najpierw było te 50
poprawek najważniejszych łatających luki bezpieczeństwa. Później kolejne
mniej ważne itd. Ręcznie tylko jest wymuszone pominięcie harmonogramu
wyszukania, pobrania i instalacji. To co znajdzie klient WU
zależy od kryteriów na serwerach Windows Update. Miałeś jakiś konkretny
powód aby to wszystko robić ręcznie?
Post by Sebastian Biały
Liczę wydajnośc dysku i dałbym radę w 5 godzin niezliczoną ilośc razy go
przekopiować z prawa na lewo i z powrotem. Co robi Windows że nie daje
rady podmienić kilku(set) plików dll o rozmiarze może ze 2GB w roządnym
czasie i za jednym razem?
Ten proces kopiowania oczywiście byłby odporny na zaniki napięcia,
obsługujący atomowe transakcje na poziomie pliku lub grupy plików oraz
rejestru, snapshot cow na poziomie blokowym, pełny rollback?
--
Piotr Borkowski
Sebastian Biały
2013-11-25 19:20:11 UTC
Permalink
Post by Piotr B. [pb2004]
Co tu wyjaśniać? Ten mechanizm nie został zaprojektowany do takiego
scenariusza użycia. Poprawki powinny pobrać się w tle i instalować
automatycznie zgodnie z harmonogramem, priorytetem i wymagając jak
najmniej pobierania(poprawki delta). Dlatego pewnie najpierw było te 50
poprawek najważniejszych łatających luki bezpieczeństwa. Później kolejne
mniej ważne itd.
Stop. Dlaczego nie sa pobierane jednoczesnie? Tylko na raty szeregowo?
Ja chcę znać wyjaśnienie *merytoryczne* ze wskazaniem na programistyczne
a nie tumanistyczne/marketingowe z odwoływaniem się do poziomu
inteligencji przeciętnej sekretarki.
Post by Piotr B. [pb2004]
Miałeś jakiś konkretny
powód aby to wszystko robić ręcznie?
Ja tego nie robilem ręcznie. Podczas instalacji nie da się pracować.
User wyrzucany jest do swapa. Ręczne kopanie Win w d... pozwolilo mi
wyrobić się *tylko* w 5h.
Post by Piotr B. [pb2004]
Ten proces kopiowania oczywiście byłby odporny na zaniki napięcia,
obsługujący atomowe transakcje na poziomie pliku lub grupy plików oraz
rejestru, snapshot cow na poziomie blokowym, pełny rollback?
I to wszystko niezbedne jest po co skoro i tak mi nie wstalo po jednym z
update i wymagało "wiedzy hackerskiej"?

Przesadzasz, to tylko gówniany system operacyjny z zerową ilością
oprogramowania, za to z 30GB śmiecia nie wiadomo do czego do ogladania
facebooka. Atomowe transakcje? Miesiąć temu ten tępy Update z Visty
(inny złom) stwierdził że nie można kontynuować bo otwarte jest Update
po czym "nieznany błąd" i bez grzebania po rejestrze byłbym ugotowany bo
już się nie odpalił (dobrze że pryszczersi na sieci wieldzieli co
zmienić). Jak to możliwe ze 20 lat później dalej mamy kanał? Czy budowa
OSów w ogóle notuje jakiś postęp poza coraz to bardziej bezużytecznymi
shellami graficznymi? Co MS robił przez 20 lat?

PS. Zlituje się nad opowiescią ile restartów notowało zainstalowanie
Visuala 2005 na XP. Zapewnie wymieniało kernel i sterowniki zasilacza...
Piotr B. [pb2004]
2013-11-26 11:59:49 UTC
Permalink
Post by Sebastian Biały
Post by Piotr B. [pb2004]
Co tu wyjaśniać? Ten mechanizm nie został zaprojektowany do takiego
scenariusza użycia. Poprawki powinny pobrać się w tle i instalować
automatycznie zgodnie z harmonogramem, priorytetem i wymagając jak
najmniej pobierania(poprawki delta). Dlatego pewnie najpierw było te 50
poprawek najważniejszych łatających luki bezpieczeństwa. Później kolejne
mniej ważne itd.
Stop. Dlaczego nie sa pobierane jednoczesnie? Tylko na raty szeregowo?
Ja chcę znać wyjaśnienie *merytoryczne* ze wskazaniem na programistyczne
a nie tumanistyczne/marketingowe z odwoływaniem się do poziomu
inteligencji przeciętnej sekretarki.
Ty nie chcesz wyjaśnienia tylko chcesz ponarzekać. Dobrze wiesz że nikt
kto projektował działanie WU nie czyta tej grupy. Zaś prawdopodobne
wyjaśnienia już otrzymałeś.
Post by Sebastian Biały
Post by Piotr B. [pb2004]
Miałeś jakiś konkretny
powód aby to wszystko robić ręcznie?
Ja tego nie robilem ręcznie. Podczas instalacji nie da się pracować.
User wyrzucany jest do swapa. Ręczne kopanie Win w d... pozwolilo mi
wyrobić się *tylko* w 5h.
Non sequitur. Instalacja na W7 według domyślnego harmonogramu startuje o
ztcp 2 lub 3 w nocy ewentualnie w idle time jeśli nie odbyła się zgodnie
z harmonogramem.
Post by Sebastian Biały
Post by Piotr B. [pb2004]
Ten proces kopiowania oczywiście byłby odporny na zaniki napięcia,
obsługujący atomowe transakcje na poziomie pliku lub grupy plików oraz
rejestru, snapshot cow na poziomie blokowym, pełny rollback?
I to wszystko niezbedne jest po co skoro i tak mi nie wstalo po jednym z
update i wymagało "wiedzy hackerskiej"?
Ani ja ani ty nie znamy statystyk Microsoftu o niepowodzeniach
instalacji poprawek. Bez powodu 8 lat temu nie wprowadzali
tranzakcyjności.
Post by Sebastian Biały
Przesadzasz, to tylko gówniany system operacyjny z zerową ilością
oprogramowania, za to z 30GB śmiecia nie wiadomo do czego do ogladania
facebooka. Atomowe transakcje? Miesiąć temu ten tępy Update z Visty
(inny złom) stwierdził że nie można kontynuować bo otwarte jest Update
po czym "nieznany błąd" i bez grzebania po rejestrze byłbym ugotowany bo
już się nie odpalił (dobrze że pryszczersi na sieci wieldzieli co
zmienić).
Co przesadzam? Napisałem Ci tylko jak jest zaprojektowany. Co do błędów
to one są w implementacji. Servicing stack praktycznie przed każdym SP
jest aktualizowany. Na Viście był aktualizowany nawet częściej.
--
Piotr Borkowski
Sebastian Biały
2013-11-26 19:41:00 UTC
Permalink
Post by Piotr B. [pb2004]
Ty nie chcesz wyjaśnienia tylko chcesz ponarzekać.
Gdzie te czasy gdy na *tej* grupie mozna było sobie ponarzekać do woli?
Post by Piotr B. [pb2004]
kto projektował działanie WU nie czyta tej grupy. Zaś prawdopodobne
wyjaśnienia już otrzymałeś.
Nie tłumaczy ono 30 lat straconych i miliardów dolarów które na wylocie
mają mniej więcej ten sam burdel co linux. No może tylko z kafelkami.
Post by Piotr B. [pb2004]
Non sequitur. Instalacja na W7 według domyślnego harmonogramu startuje o
ztcp 2 lub 3 w nocy ewentualnie w idle time jeśli nie odbyła się zgodnie
z harmonogramem.
Mam sobie czekać z update aż się łaskawie sam zainstaluje? A te
wszystkie straszne wirusy, boonety i pedofile razem z nsa?
Post by Piotr B. [pb2004]
Bez powodu 8 lat temu nie wprowadzali
tranzakcyjności.
Która to polega na wyświetleniu napisu "Nie wylaczaj komputera bo jak
wyłaczysz to się popsuje.... 0%... 1 z 129"

MS zredefiniowal transakcje nie po raz pierwszy ciekawskim polecam
lekturę Symbol Servera.
Piotr B. [pb2004]
2013-11-27 19:39:49 UTC
Permalink
Post by Sebastian Biały
Post by Piotr B. [pb2004]
Non sequitur. Instalacja na W7 według domyślnego harmonogramu startuje o
ztcp 2 lub 3 w nocy ewentualnie w idle time jeśli nie odbyła się zgodnie
z harmonogramem.
Mam sobie czekać z update aż się łaskawie sam zainstaluje? A te
wszystkie straszne wirusy, boonety i pedofile razem z nsa?
Większym zagrożeniem niż nieaktualny system jest nieaktualna Java, Flash
lub Adobe Reader.
Post by Sebastian Biały
Post by Piotr B. [pb2004]
Bez powodu 8 lat temu nie wprowadzali
tranzakcyjności.
Która to polega na wyświetleniu napisu "Nie wylaczaj komputera bo jak
wyłaczysz to się popsuje.... 0%... 1 z 129"
Może się popsuć, a nie się popsuje.
--
Piotr Borkowski
Sebastian Biały
2013-11-27 19:53:06 UTC
Permalink
Post by Piotr B. [pb2004]
Post by Sebastian Biały
Mam sobie czekać z update aż się łaskawie sam zainstaluje? A te
wszystkie straszne wirusy, boonety i pedofile razem z nsa?
Większym zagrożeniem niż nieaktualny system jest nieaktualna Java, Flash
lub Adobe Reader.
Lub kernel który powoduje przerzucenie odpowiedzialności za stabilność
systemu na producentów 3-rd party...
Post by Piotr B. [pb2004]
Post by Sebastian Biały
Post by Piotr B. [pb2004]
Bez powodu 8 lat temu nie wprowadzali
tranzakcyjności.
Która to polega na wyświetleniu napisu "Nie wylaczaj komputera bo jak
wyłaczysz to się popsuje.... 0%... 1 z 129"
Może się popsuć, a nie się popsuje.
No właśnie o tym piszę: MS ma własne pojecie transakcji. To taka
transakcja co może zadziałać ale nie musi.

PS. Win8 własnie przed chwilą też wypisał "Nie wyłączaj...". Oni w ogóle
zatrudniają jakiś programistów/projektantów czy też wszystkich zwolnili
i kodu źrodłowego kernela nie ma?
Smok Eustachy
2013-11-27 22:57:43 UTC
Permalink
W dniu 27.11.2013 20:39, Piotr B. [pb2004] pisze:
/.../
Post by Piotr B. [pb2004]
Większym zagrożeniem niż nieaktualny system jest nieaktualna Java, Flash
lub Adobe Reader.
I co na to Windows Update?
mk4
2013-12-07 00:13:34 UTC
Permalink
Post by Sebastian Biały
Ja tego nie robilem ręcznie. Podczas instalacji nie da się pracować.
User wyrzucany jest do swapa. Ręczne kopanie Win w d... pozwolilo mi
wyrobić się *tylko* w 5h.
Cos koloryzujesz. Moze masz kiepski komputer to ci muli. Sam mam stary
bo juz 4 lata - ale juz i wtedy mial jakies 24GB ram i bez problemu da
sie pracowac jak aktualizuje.

Natomiast na laptopie to rzeczywiscie potrafi mocno spowolnic - no ale
to ledwie 4GB pamieci i dysk naprawde tam sie poci znaczaco. Po prostu
lapek jest duzo slabszy od nawet takiej - juz badz co badz leciwej
stacjonarki.

PS. Czasem nawet aktualizuje dwa systemy jednoczesnie - bo zwyklem
pracowac w wirtualce a nie na hoscie wiec czesto i tu i tu sa te same
aktualizacje wiec puszcza na obu - i o zgrozo - tez daje sie bez
wiekszych problemow pracowac.
--
mk4
Sebastian Biały
2013-12-07 08:01:33 UTC
Permalink
Post by mk4
Natomiast na laptopie to rzeczywiscie potrafi mocno spowolnic - no ale
to ledwie 4GB pamieci
3 lata. 4GB pamięci. Tani laptop. Coś tu się nie zgadza.
Roman W
2013-12-07 11:26:10 UTC
Permalink
Post by mk4
Cos koloryzujesz. Moze masz kiepski komputer to ci muli. Sam mam stary
bo juz 4 lata - ale juz i wtedy mial jakies 24GB ram i bez problemu da
sie pracowac jak aktualizuje.
Niedawno instalowałem od zera Windows 7 na komputerze z Core Duo
E6600 i 4GB RAM. Ściągał wszystkie aktualizacja od 2011 roku. W tle.
Zero mulenia, mozna było spokojnie pracować. Parę restartow i tyle.

RW

Michal Tyrala
2013-11-25 18:56:50 UTC
Permalink
Post by Sebastian Biały
Liczę wydajnośc dysku i dałbym radę w 5 godzin niezliczoną ilośc razy go
przekopiować z prawa na lewo i z powrotem. Co robi Windows że nie daje
rady podmienić kilku(set) plików dll o rozmiarze może ze 2GB w roządnym
czasie i za jednym razem?
A ile z tych aktualizacji to byly ,,narzędzie do usuwania złośliwego
oprogramowania'' (wychodzą okresowo)? Bo toto miele dyskiem jak
regularny antywirus i jak ma co przegladac, to trwaaaaaaa...
--
Michał

wiesiu jest spamtrapem. ja jestem kbns
Sebastian Biały
2013-11-25 19:08:40 UTC
Permalink
Post by Michal Tyrala
A ile z tych aktualizacji to byly ,,narzędzie do usuwania złośliwego
oprogramowania'' (wychodzą okresowo)? Bo toto miele dyskiem jak
regularny antywirus i jak ma co przegladac, to trwaaaaaaa...
Zabawne. System developowany od jakiś +- 20 lat musi mieć jakies
apliakcje do usuwania złośliwego oprogramowania? Znaczy że nie
rozwiązano tego na poziomie kernela i uprawnień? Hmm...
Michal Tyrala
2013-11-25 19:29:43 UTC
Permalink
Post by Sebastian Biały
Post by Michal Tyrala
A ile z tych aktualizacji to byly ,,narzędzie do usuwania złośliwego
oprogramowania'' (wychodzą okresowo)? Bo toto miele dyskiem jak
regularny antywirus i jak ma co przegladac, to trwaaaaaaa...
Zabawne. System developowany od jakiś +- 20 lat musi mieć jakies
apliakcje do usuwania złośliwego oprogramowania?
Urodziles się wczoraj? Wiesz czym stoją botnety? Bardzo dobrze, ze MS
swojej trzódce wysyła takie cuda.

Ale rozumiem, ze niespecjalnie wiesz, czy i ile tego bylo przez te cala
zabawe?
--
Michał

wiesiu jest spamtrapem. ja jestem kbns
Sebastian Biały
2013-11-25 19:37:06 UTC
Permalink
Post by Michal Tyrala
Post by Sebastian Biały
Zabawne. System developowany od jakiś +- 20 lat musi mieć jakies
apliakcje do usuwania złośliwego oprogramowania?
Urodziles się wczoraj?
Nie, tylko troluje. Staram się nieco ożywić tą martwa grupę.
Post by Michal Tyrala
Wiesz czym stoją botnety?
20-30 lat developingu systemu operacyjnego i taki fail, że mamy kafelki
i gówniany kernel wpuszczający bootnety?
Post by Michal Tyrala
Bardzo dobrze, ze MS
swojej trzódce wysyła takie cuda.
Jak by dobrze zrobił to by nie musiał.
Post by Michal Tyrala
Ale rozumiem, ze niespecjalnie wiesz, czy i ile tego bylo przez te cala
zabawe?
Ja nic nie wiem. Tylko klikałem "zainstaluj aktualizacje". I straciłem
kilka szarych komórek próbując zgadną co robi komputer który nie dotyka
IO i nie używa CPU a jednak coś teoretycznie robił. Może liczył na GPU?
Michal Tyrala
2013-11-25 19:50:11 UTC
Permalink
Post by Sebastian Biały
Post by Michal Tyrala
Wiesz czym stoją botnety?
20-30 lat developingu systemu operacyjnego i taki fail, że mamy kafelki
i gówniany kernel wpuszczający bootnety?
Dosc spory kawalek rynku = useria, ktora niekoniecznie wie co robi.
Post by Sebastian Biały
Post by Michal Tyrala
Bardzo dobrze, ze MS swojej trzódce wysyła takie cuda.
Jak by dobrze zrobił to by nie musiał.
Gdyby babcia miala wąsy...
Post by Sebastian Biały
Post by Michal Tyrala
Ale rozumiem, ze niespecjalnie wiesz, czy i ile tego bylo przez te
cala zabawe?
Ja nic nie wiem. Tylko klikałem "zainstaluj aktualizacje".
O, już o tym pisalem wyzej :)

EOT, bo niby chciales tropu, a tak naprawde potrollowac. A ja nie mam
czasu na wyglupy.
--
Michał

wiesiu jest spamtrapem. ja jestem kbns
Sebastian Biały
2013-11-25 20:14:48 UTC
Permalink
Post by Michal Tyrala
EOT, bo niby chciales tropu, a tak naprawde potrollowac.
Jedno drugiemu nie przeszkadza. Dalej chce wiedzieć jaki powód
merytoryczny pozbawił mnie komputera na 5h.
pawel
2013-11-25 21:53:18 UTC
Permalink
Post by Michal Tyrala
A ja nie mam
czasu na wyglupy.
? ale advocacy to z definicji trolowanie
--
paweł
Piotr B. [pb2004]
2013-11-26 11:59:50 UTC
Permalink
Post by Michal Tyrala
Post by Sebastian Biały
Liczę wydajnośc dysku i dałbym radę w 5 godzin niezliczoną ilośc razy go
przekopiować z prawa na lewo i z powrotem. Co robi Windows że nie daje
rady podmienić kilku(set) plików dll o rozmiarze może ze 2GB w roządnym
czasie i za jednym razem?
A ile z tych aktualizacji to byly ,,narzędzie do usuwania złośliwego
oprogramowania'' (wychodzą okresowo)? Bo toto miele dyskiem jak
regularny antywirus i jak ma co przegladac, to trwaaaaaaa...
Jedna. To jest aktualizacja przyrostowa podobnie jak aktualicja IE.
--
Piotr Borkowski
Loading...