🚀 go-pugleaf

W dniu 24.11.2013 16:48, Sebastian Biały pisze:
/..../
> 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.

Sebastian Biały <heby@poczta.onet.pl>:
>  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.

On 2013-11-24 20:01, toslaw wrote:
> 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.

> 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?

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

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

On Sun, 24 Nov 2013 21:43:44 +0100, Sebastian 
Biały<heby@poczta.onet.pl> wrote:
> 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 wrote:

>>  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!

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

> 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?

Sebastian Biały <heby@poczta.onet.pl> wrote:
> 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?

> 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

On Sun, 24 Nov 2013 16:48:26 +0100, Sebastian Biały wrote:
>  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

On 2013-11-25 19:56, Michal Tyrala wrote:
> 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...

On 2013-11-25 19:19, Piotr B. [pb2004] wrote:
> 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.

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

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

On Mon, 25 Nov 2013 20:08:40 +0100, Sebastian Biały wrote:
>  On 2013-11-25 19:56, Michal Tyrala wrote:
> > 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

On 2013-11-25 20:29, Michal Tyrala wrote:
>>   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ę.

> Wiesz czym stoją botnety?

20-30 lat developingu systemu operacyjnego i taki fail, że mamy kafelki 
i gówniany kernel wpuszczający bootnety?

> Bardzo dobrze, ze MS
> swojej trzódce wysyła takie cuda.

Jak by dobrze zrobił to by nie musiał.

> 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?

On Mon, 25 Nov 2013 20:37:06 +0100, Sebastian Biały wrote:
> > 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.

> > Bardzo dobrze, ze MS swojej trzódce wysyła takie cuda.
> 
>  Jak by dobrze zrobił to by nie musiał.

Gdyby babcia miala wąsy...

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

On 2013-11-25 20:50, Michal Tyrala wrote:
> 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.

W dniu 25.11.2013 20:50, Michal Tyrala pisze:
> On Mon, 25 Nov 2013 20:37:06 +0100, Sebastian Biały wrote:

> 
>  A ja nie mam
> czasu na wyglupy.
> 
? ale advocacy to z definicji trolowanie

-- 
paweł

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

Sebastian Biały <heby@poczta.onet.pl> wrote:
> On 2013-11-25 19:19, Piotr B. [pb2004] wrote:
>> 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ś.

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

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

> 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

Michal Tyrala <wiesiu@bdm.com.pl> wrote:
> On Sun, 24 Nov 2013 16:48:26 +0100, Sebastian Biały wrote:
>>  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

On 2013-11-26 09:47, toslaw wrote:
>>   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.

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

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

>>   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ść.

> 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)?

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

>> 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ę?

On 2013-11-26 12:59, Piotr B. [pb2004] wrote:
> Ty nie chcesz wyjaśnienia tylko chcesz ponarzekać.

Gdzie te czasy gdy na *tej* grupie mozna było sobie ponarzekać do woli?

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

> 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?

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

On Tue, 26 Nov 2013 08:47:34 +0000 (UTC), toslaw <sorry@nomail.4u.pl> 
wrote:
> 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.

-- 
Marek

On 2013.11.27 01:00, Marek wrote:

> 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

Marek <fake@fakeemail.com>:
>  On Tue, 26 Nov 2013 08:47:34 +0000 (UTC), toslaw <sorry@nomail.4u.pl>
>  wrote:
> > 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.

Tomasz Sowa <t.sowa@NOSPAM.ttmath.org>:
>  On 2013.11.27 01:00, Marek wrote:
>
> > 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.

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

Na jakich dystrybucjach istnieje /usr/lib/compat? Na BSD?

Raczej nie na Linuxach typu Arch ani na Fedora ;)

On Wed, 27 Nov 2013 04:59:45 +0000 (UTC), toslaw <sorry@nomail.4u.pl> 
wrote:
> 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

Marek <fake@fakeemail.com>:
>  On Wed, 27 Nov 2013 04:59:45 +0000 (UTC), toslaw <sorry@nomail.4u.pl>
>  wrote:

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

Dnia środa, 27 listopada 2013 05:59, toslaw napisał(a):

> 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     |
`------------------------^---------------------------------------'

Kajetan Staszkiewicz <vegetaBezSpamu@tuxpowered.net>:
>  Dnia środa, 27 listopada 2013 05:59, toslaw napisał(a):
>
> > 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).

Dnia środa, 27 listopada 2013 18:41, toslaw napisał(a):

> Kajetan Staszkiewicz <vegetaBezSpamu@tuxpowered.net>:
>>  Dnia środa, 27 listopada 2013 05:59, toslaw napisał(a):
>>
>> > 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.

> sugerowałoby trzymanie otwartego inode, zamiast uchwytu bazującego na
> nazwie pliku.

Czym niby ma być "uchwyt bazujący 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).

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     |
`------------------------^---------------------------------------'

Kajetan Staszkiewicz <vegetaBezSpamu@tuxpowered.net>:
>  Dnia środa, 27 listopada 2013 18:41, toslaw napisał(a):
>
> > Kajetan Staszkiewicz <vegetaBezSpamu@tuxpowered.net>:
> >>  Dnia środa, 27 listopada 2013 05:59, toslaw napisał(a):
> > 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 ;)

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

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

Sebastian Biały <heby@poczta.onet.pl> wrote:
> On 2013-11-26 12:59, Piotr B. [pb2004] wrote:
>> 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.

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

Marek <fake@fakeemail.com> wrote:
> On Tue, 26 Nov 2013 08:47:34 +0000 (UTC), toslaw <sorry@nomail.4u.pl> 
> wrote:
>> 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

On 2013-11-27 20:39, Piotr B. [pb2004] wrote:
>> 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...

>>> 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?

W dniu 27.11.2013 01:00, Marek pisze:
>/.../
> 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.

W dniu 27.11.2013 20:39, Piotr B. [pb2004] pisze:
/.../
> Większym zagrożeniem niż nieaktualny system jest nieaktualna Java, Flash
> lub Adobe Reader.
>
I co na to Windows Update?

On 2013.11.27 06:13, toslaw wrote:

>>  I nawet zadziałają jak się api biblioteki nie zmieni.
> 
> Łatwiej powiedzieć, niż zrobić.

Na BSD zrobili.

> Na jakich dystrybucjach istnieje /usr/lib/compat? Na BSD?

Właśnie na BSD.

> Raczej nie na Linuxach typu Arch ani na Fedora ;)

I dlatego często mają problemy przy aktualizacji.


-- 
Tomek

On 2013-11-26 20:33, Sebastian Biały wrote:
> On 2013-11-26 09:47, toslaw wrote:
> 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

On 2013-11-25 20:20, Sebastian Biały wrote:
> 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

On 2013-12-07 00:59, mk4 wrote:
>> 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?

> 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?

> 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!

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

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

> (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"?

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

> W firmie czesc softu jest na linuksach

Co mnie obchodzi linux? Dlaczego mój Windows w sposób *bezwzględny* jest 
gówniany?

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

On 2013-12-07 01:13, mk4 wrote:
> 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.

On Sat, 07 Dec 2013 01:13:34 +0100, mk4 <mk4@dev.nul> wrote:
> 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