🚀 go-pugleaf

Maciek Zobniow wrote:
> Użytkownik Witek Świerzy napisał:

> Tzn. sa skoplikowane bo kosztuja kupe kasy? To jest wlasnie przyklad 
> chorego myslenia ktory czasem obserwuje. Przypomina mi sie tym razem 
> dobrze znana historia z Polski, wdrozenia systemu wspomagajacego 
> glosowanie (to byl duzy skandal jakies 3 lata temu). System mial pare 
> tysiacy koncowek z ktorych mialo nastapic przesylanie wynikow 
> glosowania. System, przygotowany przez firme Prokom, dal ciala (ponoc 
> nie wytrzymal obciazenia :D) i przy tej okazji okazalo sie ze w swej 
> "madrosci", do budowy systemu informatycy zastosowali same high endowe 
> komponenty w postaci paru mainframe z IBM-a z AIX-em, db2 etc. Nawet 
> klienta postanowili napisac "from scratch", mimo ze taki system oparty o 
> mysql, jave lub nawet php, z klientem opartym o przegladarke i 
> tunelowany po https kosztowalby ulamek wydanej sumy i bylby calkiem 
> niezle skalowalny i bespieczny.


akurat to jest przyklad na to, gdy wychodzi niekompetencja...
(w tym wypadku prokom po raz kolejny dowiodl, iz nie zatrudnia
ani jednego fachowca)...

zadnych "mainframe z IBM-a z AIX-em" tam nie bylo, gdyz
"mainframe z IBM" chodzi pod OS/390... byly dwa sredniej klasy
RS 6000, teraz to sie pSeries nazywa, a proble moim zdaniem
wywolany byl bledem w obsludze TCP/IP jaki byl w AIX 4.2.x
w "instalacji" z CD'ow, bez patch'y... wyglada na to, iz
"spece" z prokomu uzywaly maszyn tak jak dostaly z IBM...


a propos MySQL - uwazam to za zupelnie niezly RDBMS
ale 1000 zapytan na sekunde to po pierwsze, dla naprawde
duzych systemow jest niczym, natomiast dla MySQL zaczyna
zachaczac o granice wytrzymalosci...

z reszta i tak wiele zalezy od ilosci pamieci jaka system jest
w stanie zaalokowac dla procesu... tak a propos, ile linux moze?
4GB?

do tego dochodzi wydajnosc systemu dyskow itd itd...

P.

Użytkownik Pawel Z. napisał:
> Maciek Zobniow wrote:
> 
>> Użytkownik Witek Świerzy napisał:
> 
> 
>> Tzn. sa skoplikowane bo kosztuja kupe kasy? To jest wlasnie przyklad 
>> chorego myslenia ktory czasem obserwuje. Przypomina mi sie tym razem 
>> dobrze znana historia z Polski, wdrozenia systemu wspomagajacego 
>> glosowanie (to byl duzy skandal jakies 3 lata temu). System mial pare 
>> tysiacy koncowek z ktorych mialo nastapic przesylanie wynikow 
>> glosowania. System, przygotowany przez firme Prokom, dal ciala (ponoc 
>> nie wytrzymal obciazenia :D) i przy tej okazji okazalo sie ze w swej 
>> "madrosci", do budowy systemu informatycy zastosowali same high endowe 
>> komponenty w postaci paru mainframe z IBM-a z AIX-em, db2 etc. Nawet 
>> klienta postanowili napisac "from scratch", mimo ze taki system oparty 
>> o mysql, jave lub nawet php, z klientem opartym o przegladarke i 
>> tunelowany po https kosztowalby ulamek wydanej sumy i bylby calkiem 
>> niezle skalowalny i bespieczny.
> 
> 
> 
> akurat to jest przyklad na to, gdy wychodzi niekompetencja...
> (w tym wypadku prokom po raz kolejny dowiodl, iz nie zatrudnia
> ani jednego fachowca)...
> 
> zadnych "mainframe z IBM-a z AIX-em" tam nie bylo, gdyz
> "mainframe z IBM" chodzi pod OS/390... byly dwa sredniej klasy
> RS 6000, teraz to sie pSeries nazywa, a proble moim zdaniem
> wywolany byl bledem w obsludze TCP/IP jaki byl w AIX 4.2.x
> w "instalacji" z CD'ow, bez patch'y... wyglada na to, iz
> "spece" z prokomu uzywaly maszyn tak jak dostaly z IBM...

Ja wcale nie twierdze ze AIX nie potrafi obsluzyc tak sladowego 
obciazenia jaki moglo wygenerowac pare tysiecy komisji wyborczych. Ta 
historia miala byc raczej przykladem popularnej w Polsce gigantomani. Na 
muche wyciaga sie armate ktora kosztuje podatnikow majatek.

> 
> 
> a propos MySQL - uwazam to za zupelnie niezly RDBMS
> ale 1000 zapytan na sekunde to po pierwsze, dla naprawde
> duzych systemow jest niczym, natomiast dla MySQL zaczyna
> zachaczac o granice wytrzymalosci...

Jak juz pisalem wczesniej 1000 qs/s to w moim systemie srednia z paru 
miesiecy razem z nocami i weekendami. Podczas kampani znacznik ten mocno 
szybuje w gore. Oczywiscie instalacja klastra byla konieczna.

> 
> z reszta i tak wiele zalezy od ilosci pamieci jaka system jest
> w stanie zaalokowac dla procesu... tak a propos, ile linux moze?
> 4GB?

To zalezy. Na 32 bitowym systemie to z wiadomych powodow bedzie 4GB (lub 
nawet 3, nie pamietam teraz dobrze). Na x86_64 (przy zalozeniu ze proces 
jest rowniez skopilowany na x86_64) granica jest chyba 2TB.
W przypadku MySQL znaczenie ma raczej sama obecnosc pamieci w systemie 
niz mozliwosc jej alocowania przez process. Index cache i query cache 
nie powinny byc zbyt duze (z tych samych powodow co na Oracle), 
natomiast reszta pamieci, przynajmniej w przypadku linuxa, jest 
wykozystywana wtedy przez mechanizm cachowania  I/O w linuxie.

Pozdro
Maciek

Maciek Zobniow wrote:
> Użytkownik Pawel Z. napisał:
> 
>> Maciek Zobniow wrote:
>>
>>> Użytkownik Witek Świerzy napisał:
>>
>>
>>
>>> Tzn. sa skoplikowane bo kosztuja kupe kasy? To jest wlasnie przyklad 
>>> chorego myslenia ktory czasem obserwuje. Przypomina mi sie tym razem 
>>> dobrze znana historia z Polski, wdrozenia systemu wspomagajacego 
>>> glosowanie (to byl duzy skandal jakies 3 lata temu). System mial pare 
>>> tysiacy koncowek z ktorych mialo nastapic przesylanie wynikow 
>>> glosowania. System, przygotowany przez firme Prokom, dal ciala (ponoc 
>>> nie wytrzymal obciazenia :D) i przy tej okazji okazalo sie ze w swej 
>>> "madrosci", do budowy systemu informatycy zastosowali same high 
>>> endowe komponenty w postaci paru mainframe z IBM-a z AIX-em, db2 etc. 
>>> Nawet klienta postanowili napisac "from scratch", mimo ze taki system 
>>> oparty o mysql, jave lub nawet php, z klientem opartym o przegladarke 
>>> i tunelowany po https kosztowalby ulamek wydanej sumy i bylby calkiem 
>>> niezle skalowalny i bespieczny.
>>
>>
>>
>>
>> akurat to jest przyklad na to, gdy wychodzi niekompetencja...
>> (w tym wypadku prokom po raz kolejny dowiodl, iz nie zatrudnia
>> ani jednego fachowca)...
>>
>> zadnych "mainframe z IBM-a z AIX-em" tam nie bylo, gdyz
>> "mainframe z IBM" chodzi pod OS/390... byly dwa sredniej klasy
>> RS 6000, teraz to sie pSeries nazywa, a proble moim zdaniem
>> wywolany byl bledem w obsludze TCP/IP jaki byl w AIX 4.2.x
>> w "instalacji" z CD'ow, bez patch'y... wyglada na to, iz
>> "spece" z prokomu uzywaly maszyn tak jak dostaly z IBM...
> 
> 
> Ja wcale nie twierdze ze AIX nie potrafi obsluzyc tak sladowego 
> obciazenia jaki moglo wygenerowac pare tysiecy komisji wyborczych. Ta 
> historia miala byc raczej przykladem popularnej w Polsce gigantomani. Na 
> muche wyciaga sie armate ktora kosztuje podatnikow majatek.

to byl przyklad niekompetencji oraz korupcji...
a tych sytacjach, faktycznie chodzi o jak najwyzsze koszty...
z tego co pamietam, PKW zaplacila 47 mln, a sam sprzet
liczac bez zadnych rabatow, jak dla odbiorcy detalicznego
(serwery, desktopy, routery itd) wychodzil cos kolo 2-3 mln...

smiem twierdzic, iz czegokolwiek prokom by nie zastosowal
i tak nie dzialaloby...

> Jak juz pisalem wczesniej 1000 qs/s to w moim systemie srednia z paru 
> miesiecy razem z nocami i weekendami. Podczas kampani znacznik ten mocno 
> szybuje w gore. Oczywiscie instalacja klastra byla konieczna.

tyle, ze ten caly "klaster" w MySQL wymaga pomieszczenia calej
bazy w pamieci... wiec znow slabo...

>> z reszta i tak wiele zalezy od ilosci pamieci jaka system jest
>> w stanie zaalokowac dla procesu... tak a propos, ile linux moze?
>> 4GB?
> 
> 
> To zalezy. Na 32 bitowym systemie to z wiadomych powodow bedzie 4GB (lub 
> nawet 3, nie pamietam teraz dobrze). Na x86_64 (przy zalozeniu ze proces 
> jest rowniez skopilowany na x86_64) granica jest chyba 2TB.

chcialbym to zobaczyc... ms tez twierdzi, ze potrafo obsluzyc
64 procesory itd...

> W przypadku MySQL znaczenie ma raczej sama obecnosc pamieci w systemie 
> niz mozliwosc jej alocowania przez process. Index cache i query cache 
> nie powinny byc zbyt duze (z tych samych powodow co na Oracle), 

nie jestem administratorem baz danych, wiec nie bede sie wypowiadal,
ale jak widze co sie dzieje w systemach, ktorymi zajmuje sie
i o co zebrza wlasnie admini baz danych to jest pamiec, i pamiec na 
proces...

P.

Użytkownik Pawel Z. napisał:

> tyle, ze ten caly "klaster" w MySQL wymaga pomieszczenia calej
> bazy w pamieci... wiec znow slabo...

Masz na mysli ten standardowy klaster z MySQL AB. Istnieja rowniez inne 
mozliwosci. Ten o ktory pisalem jest zaimplementowany w warstwie 
aplikacji, przy wykozystaniu standardowej funkcjonalnosci replikacji.

> 
>>> z reszta i tak wiele zalezy od ilosci pamieci jaka system jest
>>> w stanie zaalokowac dla procesu... tak a propos, ile linux moze?
>>> 4GB?
>>
>>
>>
>> To zalezy. Na 32 bitowym systemie to z wiadomych powodow bedzie 4GB 
>> (lub nawet 3, nie pamietam teraz dobrze). Na x86_64 (przy zalozeniu ze 
>> proces jest rowniez skopilowany na x86_64) granica jest chyba 2TB.
> 
> 
> chcialbym to zobaczyc... ms tez twierdzi, ze potrafo obsluzyc
> 64 procesory itd...

Nie przesadzaj, gdzie mialby byc problem w przypadku systemu 64bitowego? 
Tu nie trzeba uzywac zadnych trickow zeby adresowac powyzej 4GB...

> 
>> W przypadku MySQL znaczenie ma raczej sama obecnosc pamieci w systemie 
>> niz mozliwosc jej alocowania przez process. Index cache i query cache 
>> nie powinny byc zbyt duze (z tych samych powodow co na Oracle), 
> 
> 
> nie jestem administratorem baz danych, wiec nie bede sie wypowiadal,
> ale jak widze co sie dzieje w systemach, ktorymi zajmuje sie
> i o co zebrza wlasnie admini baz danych to jest pamiec, i pamiec na 
> proces...

W przypadku Oracle ma to znaczenie. To wlasnie dlatego sa takie problemy 
  z Oracle na 32bitowych systemach z pamiecia powyzej 4GB. Pod linuxem 
trzeba wtedy ratowac sie /dev/shm, pod windows ponoc w ogole sie nie da...

Pozdro
Maciek

> 
> P.

Maciek Zobniow wrote:
> Użytkownik Pawel Z. napisał:
> 
>> tyle, ze ten caly "klaster" w MySQL wymaga pomieszczenia calej
>> bazy w pamieci... wiec znow slabo...
> 
> 
> Masz na mysli ten standardowy klaster z MySQL AB. Istnieja rowniez inne 
> mozliwosci. Ten o ktory pisalem jest zaimplementowany w warstwie 
> aplikacji, przy wykozystaniu standardowej funkcjonalnosci replikacji.
> 
>>
>>>> z reszta i tak wiele zalezy od ilosci pamieci jaka system jest
>>>> w stanie zaalokowac dla procesu... tak a propos, ile linux moze?
>>>> 4GB?
>>>
>>>
>>>
>>>
>>> To zalezy. Na 32 bitowym systemie to z wiadomych powodow bedzie 4GB 
>>> (lub nawet 3, nie pamietam teraz dobrze). Na x86_64 (przy zalozeniu 
>>> ze proces jest rowniez skopilowany na x86_64) granica jest chyba 2TB.
>>
>>
>>
>> chcialbym to zobaczyc... ms tez twierdzi, ze potrafo obsluzyc
>> 64 procesory itd...
> 
> 
> Nie przesadzaj, gdzie mialby byc problem w przypadku systemu 64bitowego? 
> Tu nie trzeba uzywac zadnych trickow zeby adresowac powyzej 4GB...

"powyzej 4GB", a 2 TB to dosc duzy rozrzut...
5GB to tez powyzej 4GB...

chodzi mi o sprawdzone rozwiazania, a nie teorie...

>>> W przypadku MySQL znaczenie ma raczej sama obecnosc pamieci w 
>>> systemie niz mozliwosc jej alocowania przez process. Index cache i 
>>> query cache nie powinny byc zbyt duze (z tych samych powodow co na 
>>> Oracle), 
>>
>>
>>
>> nie jestem administratorem baz danych, wiec nie bede sie wypowiadal,
>> ale jak widze co sie dzieje w systemach, ktorymi zajmuje sie
>> i o co zebrza wlasnie admini baz danych to jest pamiec, i pamiec na 
>> proces...
> 
> 
> W przypadku Oracle ma to znaczenie. To wlasnie dlatego sa takie problemy 
>  z Oracle na 32bitowych systemach z pamiecia powyzej 4GB. Pod linuxem 
> trzeba wtedy ratowac sie /dev/shm, pod windows ponoc w ogole sie nie da...

tyle, ze podstawowa sprawa jest, iz w powaznych zastosowaniach
nie uzywa sie platformy i386...

w ogole samo prownanie rozwiazan sprzetowych wiele mowi...
choc PC-serwery zaczynaja powoli posiadac wiekszoc powaznych
rowiazan, tyle ze ciekawe jak jest w tym wypadku z obsluga ze strony
systemu...

choc byc moze jestes tez zwolennikiem uzywania "podrasownych"
desktopow zamiast platform serwerowych...

Pozdrawiam
P.

Użytkownik Pawel Z. napisał:
> 
> 
> "powyzej 4GB", a 2 TB to dosc duzy rozrzut...
> 5GB to tez powyzej 4GB...

hehe...bo szyna 32bit i 64bit to duzy rozrzut nieprawdaz ;)?

> 
> tyle, ze podstawowa sprawa jest, iz w powaznych zastosowaniach
> nie uzywa sie platformy i386...

To definicja "powaznego zastosowania" czy platformy i386 ;P?

> 
> w ogole samo prownanie rozwiazan sprzetowych wiele mowi...
> choc PC-serwery zaczynaja powoli posiadac wiekszoc powaznych
> rowiazan, tyle ze ciekawe jak jest w tym wypadku z obsluga ze strony
> systemu...
> 
> choc byc moze jestes tez zwolennikiem uzywania "podrasownych"
> desktopow zamiast platform serwerowych...

Jak juz pisalem w dyskusji z Witkiem Swierzym, jestem zwolennikiem 
zarabiania kasy, zamiast pchania jej do kieszeni roznych korporacji w 
zamian za ich kombajny. Zgodze sie z toba ze zapewne instalacja na 
sparku z super redundant I/O subsystem and so on, etc. pewnie jest 
jakies 5% bardziej stabilna niz prawidlowo zlozony pecet. Ja jednak wole 
postawic 3 dobre pecety i polaczyc je HeardBeat-em i tez mam calkiem 
dobra, redundant installation, przy czym jej koszt siegnie pewnie jakies 
5% poprzedniej. Pamietaj ze najwieksza sila i przewaga w naszej pracy sa 
nasze mozgi, maszyny i ich software-y poki co sa strasznie durne, 
niezaleznie pod jakim brandem sa sprzedawane.

Pozdro
Maciek

Maciek Zobniow <maciekWywalTo@zobniow.net> wrote:
> Użytkownik Pawel Z. napisał:
> > 
> > 
> > "powyzej 4GB", a 2 TB to dosc duzy rozrzut...
> > 5GB to tez powyzej 4GB...
> hehe...bo szyna 32bit i 64bit to duzy rozrzut nieprawdaz ;)?
Tu nie o szynę chodzi. Poza tym procesory 32 bit raczej nie mają
szyny 32 bit, a procesory 64 bit - 64. ;)

Pozdrawiam,

			Krzysztof Oledzki

-- 
Krzysztof Olędzki
e-mail address:		ole(a-t)ans(d-o-t)pl
Registered User:	Linux - 189200, BSD - 51140
Nick Handles:		KO60-RIPE, KO60-6BONE, KO581 (Network Solutions)

Użytkownik Krzysztof Oledzki napisał:
> Maciek Zobniow <maciekWywalTo@zobniow.net> wrote:
> 
>>Użytkownik Pawel Z. napisał:
>>
>>>
>>>"powyzej 4GB", a 2 TB to dosc duzy rozrzut...
>>>5GB to tez powyzej 4GB...
>>
>>hehe...bo szyna 32bit i 64bit to duzy rozrzut nieprawdaz ;)?
> 
> Tu nie o szynę chodzi. Poza tym procesory 32 bit raczej nie mają
> szyny 32 bit, a procesory 64 bit - 64. ;)

Chdzi. Glownie o szyne adresowa. Oczywiscie masz racje ze nie ma ona 
dlugosci 64bit, ale nawet w opteronie jest wystarczajaco dluga zeby 
zaadresowac 2TB.

Pozdro
Maciek

Użytkownik Maciek Zobniow napisał:
> Użytkownik Krzysztof Oledzki napisał:
> 
>> Maciek Zobniow <maciekWywalTo@zobniow.net> wrote:
>>
>>> Użytkownik Pawel Z. napisał:
>>>
>>>>
>>>> "powyzej 4GB", a 2 TB to dosc duzy rozrzut...
>>>> 5GB to tez powyzej 4GB...
>>>
>>>
>>> hehe...bo szyna 32bit i 64bit to duzy rozrzut nieprawdaz ;)?
>>
>>
>> Tu nie o szynę chodzi. Poza tym procesory 32 bit raczej nie mają
>> szyny 32 bit, a procesory 64 bit - 64. ;)
> 
> 
> Chdzi. Glownie o szyne adresowa. Oczywiscie masz racje ze nie ma ona 
> dlugosci 64bit, ale nawet w opteronie jest wystarczajaco dluga zeby 
> zaadresowac 2TB.

Sorry. Wlasnie sprawdzilem ze Opteron moze zaadresowac 1TB. 40bit 
address space.

> Pozdro
> Maciek

Maciek Zobniow <maciekWywalTo@zobniow.net> wrote:
> Użytkownik Maciek Zobniow napisał:
> > Użytkownik Krzysztof Oledzki napisał:
> > 
> >> Maciek Zobniow <maciekWywalTo@zobniow.net> wrote:
> >>
> >>> Użytkownik Pawel Z. napisał:
> >>>
> >>>>
> >>>> "powyzej 4GB", a 2 TB to dosc duzy rozrzut...
> >>>> 5GB to tez powyzej 4GB...
> >>>
> >>>
> >>> hehe...bo szyna 32bit i 64bit to duzy rozrzut nieprawdaz ;)?
> >>
> >>
> >> Tu nie o szynę chodzi. Poza tym procesory 32 bit raczej nie mają
> >> szyny 32 bit, a procesory 64 bit - 64. ;)
> > 
> > 
> > Chdzi. Glownie o szyne adresowa. Oczywiscie masz racje ze nie ma ona 
> > dlugosci 64bit, ale nawet w opteronie jest wystarczajaco dluga zeby 
> > zaadresowac 2TB.
> 
> Sorry. Wlasnie sprawdzilem ze Opteron moze zaadresowac 1TB. 40bit 
> address space.

No to jeszcze niespodzianka, zwykły Pentium2/3/4/Athlon też nie
ma szyny 32bit. ;)

Pozdrawiam,

			Krzysztof Oledzki

-- 
Krzysztof Olędzki
e-mail address:		ole(a-t)ans(d-o-t)pl
Registered User:	Linux - 189200, BSD - 51140
Nick Handles:		KO60-RIPE, KO60-6BONE, KO581 (Network Solutions)

Użytkownik Krzysztof Oledzki napisał:
> Maciek Zobniow <maciekWywalTo@zobniow.net> wrote:
> 
>>Użytkownik Maciek Zobniow napisał:
>>
>>>Użytkownik Krzysztof Oledzki napisał:
>>>
>>>
>>>>Maciek Zobniow <maciekWywalTo@zobniow.net> wrote:
>>>>
>>>>
>>>>>Użytkownik Pawel Z. napisał:
>>>>>
>>>>>
>>>>>>"powyzej 4GB", a 2 TB to dosc duzy rozrzut...
>>>>>>5GB to tez powyzej 4GB...
>>>>>
>>>>>
>>>>>hehe...bo szyna 32bit i 64bit to duzy rozrzut nieprawdaz ;)?
>>>>
>>>>
>>>>Tu nie o szynę chodzi. Poza tym procesory 32 bit raczej nie mają
>>>>szyny 32 bit, a procesory 64 bit - 64. ;)
>>>
>>>
>>>Chdzi. Glownie o szyne adresowa. Oczywiscie masz racje ze nie ma ona 
>>>dlugosci 64bit, ale nawet w opteronie jest wystarczajaco dluga zeby 
>>>zaadresowac 2TB.
>>
>>Sorry. Wlasnie sprawdzilem ze Opteron moze zaadresowac 1TB. 40bit 
>>address space.
> 
> 
> No to jeszcze niespodzianka, zwykły Pentium2/3/4/Athlon też nie
> ma szyny 32bit. ;)

Wiem, to byl raczej skrot myslowy, poniewaz ww procesory adresuja 
adreasami 64/32 bitowymi i rejestry tez maja przystosowane do operacji 
na takich adresach.

Pozdro
Maciek

Stachu 'Dozzie' K. <dozzie@dynamit.im.pwr.wroc.pl.nospam> wrote:

> A co ma fsck do fdiska? Bo ja nie rozumiem.

Pozajączkowało mi się, przyznaję. Dałbym sobie głowę uciąć, że
tam było 'fsck'. No nieistotne. Cancelnę zaraz.

> ROTFL. Na oczy nie widziałeś fdiska z Linuksa.

Tak, tak. Zdecydowanie masz rację.
Tak czy siak - ciekawe jakiej funkcjonalności brakuje
Solarisowemu 'formatowi'?
Bo nie potrafi zakładać partycji ext2? Też mi zaleta, jeśli
korzystamy z Solarisa.

-- 
Przemysław Maciuszko

Corvin <corvin.dun_wytnij_@wp.pl> wrote:

> No śmieszny wiesz będąc przyzwyczajony do takiego potężnego narzędzia,
> jak linuxowy fdisk, to moje pierwsze spojrzenia na jego odpowiednik
> w Solaris 9 wywołały taką a nie inną reakcję: żałosne jak w windows.

Z ciekawości - czego Ci brakowało w formacie do poprawnego stworzenia
sliców i podziału dysku?

> To ma być wypowiedź na poziomie? 

A dlaczego nie? Więc? Kto Ci kazał tego używać?
Bo istnienie takich, czy innych kawałków software'u, które nie są
wymagane i istotne dla działania, a mają wspomagać zarządzanie -
jest faktem.

Nie ma natomiast obowiązku ich używania, a komentowanie możliwości
_systemu_ pisząc o tych narzędziach i ich 'ułomności', jest dla mnie
śmieszne.

> W linuxie też się da ;). a jak tam z firewallem z funkcjonalnością

Wiec po co przytaczasz argumentów RAID-ów i klastrów jako zaletę Linuxa?
Z ciekawości - znasz jakieś duże klastry HA postawione na Linuxach?

> netfilter + pom + htb ?

Nie wiem. Nie używam Solarisa jako firewalla ani routera.
Uważam że są lepsze systemy/narzędzia do tego służące.
Howgh.


-- 
Przemysław Maciuszko

Przemysław Maciuszko wrote:


> Tak, tak. Zdecydowanie masz rację.
> Tak czy siak - ciekawe jakiej funkcjonalności brakuje
> Solarisowemu 'formatowi'?
> Bo nie potrafi zakładać partycji ext2? Też mi zaleta, jeśli
> korzystamy z Solarisa.
> 

Ok widać, że Twoja wiedza dot. Linuxa jest mizerna. EOT. (to nie ma sensu)
-- 
pozdrawiam,
Corvin
http://forum.slackware.pl

Corvin <corvin.dun_wytnij_@wp.pl> wrote:

> Ok widać, że Twoja wiedza dot. Linuxa jest mizerna. EOT. (to nie ma sensu)

Może zamiast obrażać osoby z którymi dyskutujesz, podałbyś
w końcu czego Ci brakuje w Solarisowym formacie, do założenia sliców?


-- 
Przemysław Maciuszko

Corvin wrote:
> Przemysław Maciuszko wrote:
> 
> 
>>Corvin <corvin.dun_wytnij_@wp.pl> wrote:
>>
>>
>>>produktywność, wszystko tu się da zrobić: klastry, RAIDy. Wygoda pracy w
>>>porównaniu z Solaris jest bezporówania,np. fdisk jest dość żałosny ta
>>>konsola do administrowania też nie zrobiła na mnie najlepszego wrażenia.
>>
>>Solaris to głównie system serwerowy, więc jakby ciężko mówić o
>>'wygodzie pracy'. A komentarz nt. fdiska jest... śmieszny? :)
> 
> 
> No śmieszny wiesz będąc przyzwyczajony do takiego potężnego narzędzia,
> jak linuxowy fdisk, to moje pierwsze spojrzenia na jego odpowiednik
> w Solaris 9 wywołały taką a nie inną reakcję: żałosne jak w windows.

tak z ciekawosci, jakie to ambitne i czesto spotykane
zadania aministracyjne trzeba wykonywac przy pomocy tego
"potężnego narzędzia"?

Pozdrawiam
P.

Pawel Z. wrote:

>
> 
> tak z ciekawosci, jakie to ambitne i czesto spotykane
> zadania aministracyjne trzeba wykonywac przy pomocy tego
> "potężnego narzędzia"?
> 

zamiast dywagacji proponuje żebyście sobie zapuścili jakiegoś knoppixa i to
może być ciekawe doświadczenie ;)

-- 
pozdrawiam,
Corvin
http://forum.slackware.pl

Przemysław Maciuszko wrote:

> Corvin <corvin.dun_wytnij_@wp.pl> wrote:
> 
>> Ok widać, że Twoja wiedza dot. Linuxa jest mizerna. EOT. (to nie ma
>> sensu)
> 
> Może zamiast obrażać osoby z którymi dyskutujesz, podałbyś
> w końcu czego Ci brakuje w Solarisowym formacie, do założenia sliców?
> 
> 


to nie była obrazatylko stwierdzenie faktu, zobacz sobie knopixa
-- 
pozdrawiam,
Corvin
http://forum.slackware.pl

Corvin <corvin.dun_wytnij_@wp.pl> wrote:

> to nie była obrazatylko stwierdzenie faktu, zobacz sobie knopixa

Rozumiem, że masz problem z interpretacją pytań.
Trudno. Spróbuję jeszcze raz.
Czego Ci brakuje w Solarisowym formacie, w celu poprawnego założenia sliców
i/lub podzielenia dysku?



-- 
Przemysław Maciuszko

Przemysław Maciuszko wrote:

> Corvin <corvin.dun_wytnij_@wp.pl> wrote:
> 
>> to nie była obrazatylko stwierdzenie faktu, zobacz sobie knopixa
> 
> Rozumiem, że masz problem z interpretacją pytań.
> Trudno. Spróbuję jeszcze raz.
> Czego Ci brakuje w Solarisowym formacie, w celu poprawnego założenia
> sliców i/lub podzielenia dysku?
 
ale ja mówię o fdisku a nie formacie jeśli mamy być ściśli ;) 
też masz jakieś problemy ;) ??

- mała wygoda tego narzędzia niska wszechstronność i nadaje się tylko
do operacji na partcjach sunowskich i ogolnie niebezpiecznie tego używać jak
się nie daj Boże na dysku ma partycje innych systemów.

serio to kłótnia o nic tak to wygląda, że Ty nie znasz linuxa a się
wypowiadasz jaka to zabawka, to trochę nieteges, nie uważasz? Btw ja nie
uważam, że Solaris jest jakieś gorsze jako serwer baz danych. Niemniej jest
szereg zastosowań gdzie Linux bije Solaris na głowę.   

-- 
pozdrawiam,
Corvin
http://forum.slackware.pl

Corvin <corvin.dun_wytnij_@wp.pl> wrote:

> ale ja mówię o fdisku a nie formacie jeśli mamy być ściśli ;) 

Cytuję:
"to moje pierwsze spojrzenia na jego odpowiednik w Solaris 9"
Odpowiednikiem (funkcjonalnym) fdiska na Linuksie, jest polecenie 'format'.
Jak chcesz nam tutaj udowadniać jakąkolwiek wyższość, skoro jak widać
nie masz o tym pojęcia?

> - mała wygoda tego narzędzia niska wszechstronność i nadaje się tylko
> do operacji na partcjach sunowskich i ogolnie niebezpiecznie tego używać jak
> się nie daj Boże na dysku ma partycje innych systemów.

Mała wygoda? Niska wszechstronność? Po co ludziom na Solarisie możliwość
tworzenia partycji ext2? Czyli znowu wracamy do kwestii wodotrysków i innych
dupereli.
Niebezpiecznie używać? Rotfl. A fdiska pod Linuksem się nie boisz używać?

> serio to kłótnia o nic tak to wygląda, że Ty nie znasz linuxa a się

Powtórzę - rotfl. Wywróżyłeś to z fusów? Ech Ci fanatyca Linuksa...

> wypowiadasz jaka to zabawka, to trochę nieteges, nie uważasz? Btw ja nie

O. Zacytujesz?

> uważam, że Solaris jest jakieś gorsze jako serwer baz danych. Niemniej jest
> szereg zastosowań gdzie Linux bije Solaris na głowę.   

Bo może zakładać partycje ext2, ufs i inne, jednym narzędziem? :>

BTW: Ja nigdzie nie pisałem, że to czy tamto jest gorsze. To Ty zacząłeś
od udowadniania jaki to Solaris be, a Linux super-hiper.
Bo ma 'rozbudowanego' fdiska.


-- 
Przemysław Maciuszko

Witam powtornie.
> Mysle ze poprostu doswiadczamy pracy w innych srodowiskach. Wezmy taka 
> instalacje Oracle w banku o ktorej wspominales. Baza sluzy tam zapewne 
> do data warehousing-u, jest krytyczna ale w innym sensie niz ja to 
> rozumiem. Krytyczna poniewaz zawiera dane krytyczne dla funkcjonowania 
> banku, natomiast to ze czasem zdazy jej sie stanac na 2 godziny (no 
> przeciez support enginer musi jakos dojechac do klienta) nie jest jakas 
> wielka strata (tyle ze paru analitykow bedzie mialo 2 godziny ubawu 
> zamiast harowy).
Widzisz - nie. Systemy takie pracuja _glownie_ jako krytyczne systemy 
transakcyjne - musza byc praktycznie dostepne 7x24. Warehousing to inna 
sprawa. Nie znam banku operajacego swoje systemy _TRANSAKCYJNE_  o 
narzedzia OS. Bardzo czesto w takich sytuacja stawia sie rowniez systemy 
zapasowe przejmujace role podstawowych w przypadku awarii. Inna sprawa, 
ze do warehousingu OS rowniez niezbyt sie nadaje (nikle mozliwosci 
zrownoleglania operacji). Aczkolwiek zdarza sie, ze np. do warehousingu 
wykorzystuje sie oracle, glowne systemy transakcyjne pracuja na DB2 (lub 
an odwrot). No krotko mowiac np. bankowosc to raczej nie miejsce na OS.
>>> Jak juz pisalem, narzedzia trzeba dobierac do zastosowan. Podejrzewam 
>>> ze w bankach potrzebuja od bazy rozbudowanego silnika bussines 
>>> inteligence i duzo narzedzi na nim bazujacych (np. SAS czy systemy do 
>>> raportowania etc.).
>>
>>
No nie tylko - popatrz wyzej. Chodzi _glownie_ o sprawnosc i niezawodnosc.

> Mam nadzieje ze mnie dobrze zrozumiales: do systemu na spoko, gdzie 
> klientami jest parunastu pijacych kawe, leniwych analitykow ;).
> 
Nie - do systemu ktorego klientami sa setki lub tysiace operatorow 
"porozkladanych" na terenie calego kraju.
pozdrawiam
Witek Swierzy
wswier@sgh.waw.pl
PS
Serce rosnie jak dyskusja kwitnie ;-)

Maciej Zobniow <mzobniow-removeit@zobniow.net> wrote:

> rozumiem. Krytyczna poniewaz zawiera dane krytyczne dla funkcjonowania 
> banku, natomiast to ze czasem zdazy jej sie stanac na 2 godziny (no 
> przeciez support enginer musi jakos dojechac do klienta) nie jest jakas 
> wielka strata (tyle ze paru analitykow bedzie mialo 2 godziny ubawu 

Ty to chyba nie widziałeś nigdy z bliska systemów bankowych, prawda?

> zamiast harowy). Jesli nawet baza jest back-end-em systemu 
> online-banking, jej awaria rowniez nie jest krytyczna dla banku - 
> wystawia wtedy ladna witrynke ze przepraszaja i sie staraja a problemy 
> mina asap.

Rotfl. Tak tak. Skończ patrzeć przez pryzmat polskiej amatorszczyzny.
Zresztą z czym do ludzi - widać, że nie masz pojęcia o działaniu 
jakichkolwiek systemów bankowych, chociaż próbujesz się na ten temat
wypowiadać z fachowego punktu widzenia.

-- 
Przemysław Maciuszko

On 14.12.2005, Przemysław Maciuszko <sal@hell.pl> wrote:
> Maciej Zobniow <mzobniow-removeit@zobniow.net> wrote:
>
>> rozumiem. Krytyczna poniewaz zawiera dane krytyczne dla funkcjonowania 
>> banku, natomiast to ze czasem zdazy jej sie stanac na 2 godziny (no 
>> przeciez support enginer musi jakos dojechac do klienta) nie jest jakas 
>> wielka strata (tyle ze paru analitykow bedzie mialo 2 godziny ubawu 
>
> Ty to chyba nie widziałeś nigdy z bliska systemów bankowych, prawda?
>
>> zamiast harowy). Jesli nawet baza jest back-end-em systemu 
>> online-banking, jej awaria rowniez nie jest krytyczna dla banku - 
>> wystawia wtedy ladna witrynke ze przepraszaja i sie staraja a problemy 
>> mina asap.
>
> Rotfl. Tak tak. Skończ patrzeć przez pryzmat polskiej amatorszczyzny.
> Zresztą z czym do ludzi - widać, że nie masz pojęcia o działaniu 
> jakichkolwiek systemów bankowych, chociaż próbujesz się na ten temat
> wypowiadać z fachowego punktu widzenia.

To opowiedz coś bliżej, skoro wiesz lepiej, zamiast tylko wyśmiewać.
Ja na przykład nie miałem nigdy do czynienia z systemem bankowym
i bardzo chętnie poczytam.

-- 
Feel free to correct my English
Stanislaw Klekot

Przemysław Maciuszko wrote:
> Maciej Zobniow <mzobniow-removeit@zobniow.net> wrote:
> 
> 
>>rozumiem. Krytyczna poniewaz zawiera dane krytyczne dla funkcjonowania 
>>banku, natomiast to ze czasem zdazy jej sie stanac na 2 godziny (no 
>>przeciez support enginer musi jakos dojechac do klienta) nie jest jakas 
>>wielka strata (tyle ze paru analitykow bedzie mialo 2 godziny ubawu 
> 
> 
> Ty to chyba nie widziałeś nigdy z bliska systemów bankowych, prawda?
> 
> 
>>zamiast harowy). Jesli nawet baza jest back-end-em systemu 
>>online-banking, jej awaria rowniez nie jest krytyczna dla banku - 
>>wystawia wtedy ladna witrynke ze przepraszaja i sie staraja a problemy 
>>mina asap.
> 
> 
> Rotfl. Tak tak. Skończ patrzeć przez pryzmat polskiej amatorszczyzny.
> Zresztą z czym do ludzi - widać, że nie masz pojęcia o działaniu 
> jakichkolwiek systemów bankowych, chociaż próbujesz się na ten temat
> wypowiadać z fachowego punktu widzenia.
> 

No coz, musze przyznac ze faktycznie w bankach, jak narazie w mojej 
karierze, bezposrednio nie pracowalem. Spojrzmy jednak na dzialanie 
online-bankingu z poziomu usera. Kozystam z uslug jednego z najwiekszych 
bankow w Niemczech (zebys nie bredzil o "polskiej amatorszczyznie"): 
Commerzbank.  Mam u nich konto od okolo 4 lat. Nie chce sie na nich 
specjalnie skarzyc bo nie jest tak zle, jednak bywalo ze portal lezal 
przez dluzszy czas. Szczegolnie jak padnie czasem w sobote to juz nie ma 
szans zeby wstal do poniedzialku. Porownujac to do biznesu aplikacji 
webowej b2b...czasem budza mnie telefony o 4 nad ranem w niedziele (o 
ile wczesniej nie zrobi tego sms wczesnego ostrzegania), bo jakiemus 
klientowi nie chce dzialac. W przypadku asp, klienci zazwyczaj rozsiani 
sa po calym globie. Mamy np. klientow z Japoni, Chin, Dubaju etc.
Wracajac do "polskiej amatorszczezny". Rozumiem ze to wlasnie OS do niej 
zaliczasz? To ciekawe, ale to w Polsce zaobserwowalem najbardziej 
jaskrawe przypadki gigantomani. W Niemczach i w ogole na zachodzie EU, 
ludzie staraja sie bardziej oszczedzac i nie lapia sie tak latwo na 
marketingowe hasla.

Pozdro
Maciek

Witek Świerzy wrote:
> Witam powtornie.
> 
>> Mysle ze poprostu doswiadczamy pracy w innych srodowiskach. Wezmy taka 
>> instalacje Oracle w banku o ktorej wspominales. Baza sluzy tam zapewne 
>> do data warehousing-u, jest krytyczna ale w innym sensie niz ja to 
>> rozumiem. Krytyczna poniewaz zawiera dane krytyczne dla funkcjonowania 
>> banku, natomiast to ze czasem zdazy jej sie stanac na 2 godziny (no 
>> przeciez support enginer musi jakos dojechac do klienta) nie jest 
>> jakas wielka strata (tyle ze paru analitykow bedzie mialo 2 godziny 
>> ubawu zamiast harowy).
> 
> Widzisz - nie. Systemy takie pracuja _glownie_ jako krytyczne systemy 
> transakcyjne - musza byc praktycznie dostepne 7x24. Warehousing to inna 
> sprawa. Nie znam banku operajacego swoje systemy _TRANSAKCYJNE_  o 
> narzedzia OS. Bardzo czesto w takich sytuacja stawia sie rowniez systemy 
> zapasowe przejmujace role podstawowych w przypadku awarii. Inna sprawa, 
> ze do warehousingu OS rowniez niezbyt sie nadaje (nikle mozliwosci 
> zrownoleglania operacji). Aczkolwiek zdarza sie, ze np. do warehousingu 
> wykorzystuje sie oracle, glowne systemy transakcyjne pracuja na DB2 (lub 
> an odwrot). No krotko mowiac np. bankowosc to raczej nie miejsce na OS.

Jednak Mysql AB wymienia na swojej stronie paru klientow z kregu 
instytucji finansowych i bankow.  Jest tez jedna baza OS ktora wrecz od 
poczatku pozycjonuje sie w systemach klasy Enterprise: Ingres.
Sprawdzilem tez przed chwila netcraftem moj bank i okazalo sie ze i on 
nie jest "profesjonalny": wykozystuje Apache ;-O.


>>
> Nie - do systemu ktorego klientami sa setki lub tysiace operatorow 
> "porozkladanych" na terenie calego kraju.

Wiec przynajmniej po godzinach macie spoko ;).

> PS
> Serce rosnie jak dyskusja kwitnie ;-)

Czasem, niestety przeradza sie w haotyczna wymiane ciosow :/.

Pozdro
Maciek

Witek Świerzy <wswier@sgh.waw.pl> wrote:
>> Mam nadzieje ze mnie dobrze zrozumiales: do systemu na spoko, gdzie 
>> klientami jest parunastu pijacych kawe, leniwych analitykow ;).
> Nie - do systemu ktorego klientami sa setki lub tysiace operatorow 
> "porozkladanych" na terenie calego kraju.

Wydaje mi się, że to mniej więcej sedno problemu. Tam, gdzie inni
stawiają duże w ich mniemaniu bazy na mysql, tam Ty widzisz jakąś
mikrobazkę (która niemal równie dobrze może być na flatfile :>),
a przez "duża baza" masz na myśli ze dwa rzędy wielkości więcej.

p.

-- 
http://nerdquiz.sgh.waw.pl/ -- polska wersja quizu dla nerdów.
http://freedns.sgh.waw.pl/ -- bezpłatny serwis DNS.
http://42.pl/url/ -- skracacz URL-i.

Piotr KUCHARSKI wrote:
> Witek Świerzy <wswier@sgh.waw.pl> wrote:
> 
>>>Mam nadzieje ze mnie dobrze zrozumiales: do systemu na spoko, gdzie 
>>>klientami jest parunastu pijacych kawe, leniwych analitykow ;).
>>
>>Nie - do systemu ktorego klientami sa setki lub tysiace operatorow 
>>"porozkladanych" na terenie calego kraju.
> 
> 
> Wydaje mi się, że to mniej więcej sedno problemu. Tam, gdzie inni
> stawiają duże w ich mniemaniu bazy na mysql, tam Ty widzisz jakąś
> mikrobazkę (która niemal równie dobrze może być na flatfile :>),
> a przez "duża baza" masz na myśli ze dwa rzędy wielkości więcej.

Oczywiscie problem skali istnieje, ale dlatego na samym poczatku 
dyskusji podalem pare danych o mojej bazie. Pozatym mysle ze w tym 
konkretnym przypadku rozumujesz niewlasciwie poniewaz opierajac sie na 
komplementarnych danych z mojego systemu, do tych ktore skomentowales z 
postu Witka wychodzi ze ja mam w systemie 8107200 "operatorow", 
rozsianych po calym globie.

Pozdro
Maciek

Maciej Zobniow wrote:
> Piotr KUCHARSKI wrote:
> 
>> Witek Świerzy <wswier@sgh.waw.pl> wrote:
>>
>>>> Mam nadzieje ze mnie dobrze zrozumiales: do systemu na spoko, gdzie 
>>>> klientami jest parunastu pijacych kawe, leniwych analitykow ;).
>>>
>>>
>>> Nie - do systemu ktorego klientami sa setki lub tysiace operatorow 
>>> "porozkladanych" na terenie calego kraju.
>>
>>
>>
>> Wydaje mi się, że to mniej więcej sedno problemu. Tam, gdzie inni
>> stawiają duże w ich mniemaniu bazy na mysql, tam Ty widzisz jakąś
>> mikrobazkę (która niemal równie dobrze może być na flatfile :>),
>> a przez "duża baza" masz na myśli ze dwa rzędy wielkości więcej.
> 
> 
> Oczywiscie problem skali istnieje, ale dlatego na samym poczatku 
> dyskusji podalem pare danych o mojej bazie. Pozatym mysle ze w tym 
> konkretnym przypadku rozumujesz niewlasciwie poniewaz opierajac sie na 
> komplementarnych danych z mojego systemu, do tych ktore skomentowales z 
> postu Witka wychodzi ze ja mam w systemie 8107200 "operatorow", 
> rozsianych po calym globie.
> 
> Pozdro
> Maciek
Wydaje mi sie, ze Piotr ma duzo racji. Oprocz liczby sesji liczy sie 
jeszcze tempo przyrostu danych. Twoja baza, Macku, uzbierala tych danych 
(o ile sobie dobrze przypominam)  - ok 35 GB przez 4 lata 
funckjonowania, czyli ok. 9GB rocznie srednio liczac. Znam systemy 
przyrastajace o kilka rzedow wielkosci szybciej - jak sadze, OS by 
raczej tego nie uciagnal. Zreszta w moim poscie chcialem przede 
wszystkim uwypuklic koniecznosc pracy takich systemow 7x24. Wszak 
niemoznosc wykonania jakielkolwiek transakcji przynosi takiej instytucji 
latwo wyliczalne straty (srednia_kwota_przelewu * prowizja_banku). Wiec 
2-godzinny przestoj o ktorym wspominales poprzednio kosztuje calkiem 
spore pieniadze, a wiec jest nieakceptowalny. I wlasnie dlatego stosuje 
sie tam systemy _NIE_OS_. Dysponuja one naprawde szerszymi mozliwosciami 
uodpornienia sie na awarie od OS. Nie chcialbym wchodzic na tej liscie w 
szczegoly (temat baz danych jest tu troche OT, bylo nie bylo :-), ale 
proponuje Ci abys poczytal np. o mozliwosciach klastrowania Oracle, 
bazach standby, architekturze data guard itp. Wydaje sie, ze zaden 
system OS nie dysponuje takimi mozliwosciami. Tak wiec, gdybys 
przerzucil swoj system np. na oracle ( posluguje sie tutaj najczesciej 
tym przykladem z racji doswiadczen zawodowych) to moze rzadziej bylbys 
budzony o 4 am w niedziele. Inna sprawa to oczywiscie koszty - 
najpewniej taniej jest Cie obudzic o 4 (nie mowie, ze bezpieczniej - 
wszak dobry Polak, to Polak najedzony i wyspany ;-) rano niz wydac spora 
kwote pieniedzy na system komercyjny. Poza tym liczy sie rowniez 
bezpieczenstwo w sensie odpornosci na potencjalne wlamania - i tutaj tez 
wydaje sie, ze systemy komercyjne dysponuja wieksza liczba zabezpieczen 
od darmowych (pomijam tu rzecz oczywista jak dostep po https do web 
serwera - to sie rozumie samo przez sie, ale mowie juz o mechanizmach 
zaszytych w DBMS-ach - no ale znowu OT, wiec nie rozwijam tematu bez 
wyraznego zaproszenia :-).
pozdrawiam
Witek Swierzy
wswier@sgh.waw.pl

Maciej Zobniow wrote:
> Czasem, niestety przeradza sie w haotyczna wymiane ciosow :/.
> 
> Pozdro
> Maciek
No coz - szczerze powiedziawszy - zaczales ta dyskusje dosc radykalnymi 
stwierdzeniami, wiec co sie dziwisz :-) Na szczescie wszyscy uczestnicy 
"potykaja sie" jedynie wirtualnie ;-)
pozdrawiam
Witek Swierzy
wswier@sgh.waw.pl

Maciej Zobniow <mzobniow-removeit@zobniow.net> wrote:
>> Wydaje mi się, że to mniej więcej sedno problemu. Tam, gdzie inni
>> stawiają duże w ich mniemaniu bazy na mysql, tam Ty widzisz jakąś
>> mikrobazkę (która niemal równie dobrze może być na flatfile :>),
>> a przez "duża baza" masz na myśli ze dwa rzędy wielkości więcej.
> Oczywiscie problem skali istnieje, ale dlatego na samym poczatku 
> dyskusji podalem pare danych o mojej bazie.

...która dla Ciebie jest duża, ale do uciągnięcia przez MySQL i dobrze 
wam tak razem, ale która dla Witka jest maleństwem, którym on się zwykle
nie zajmuje.

W tym wypadku MySQL się u ciebie sprawdza świetnie. W innych, bardziej
wymagających rozwiązaniach nie będzie się sprawdzał -- tam wejdą wielcy
bracia typu Oracle czy DB2.

I dobrze. Dla każdego coś dobrego.

Dla większości zastosowań w internecie MySQL wygląda, że wystarcza (choć
od razu zastrzegam, że nie używam, jeśli nie muszę, bo wolę PostgreSQL).
Ale bardzo dobrze, że takie darmowe (i OS) DBMS-y istnieją: umożliwiają
istnienie wielu projektom bez inwestowania w komercyjne bazy. Ba! Przy
niewielkim nakładzie w sprzęt umożliwiają też istnienie niektórym ciut
większym i poważniejszym projektom.

Ale jestem pewien, że zawsze pozostaną obszary, w których niepodzielnie
będą królować rozwiązania pokroju Oracle'a.

I, tak naprawdę, nie ma się co sprzeczać -- wybór rozwiązania zależy od
zbyt wielu czynników, które trzeba by było dokładnie przeanalizować i na
tej podstawie podjąć jakąś dyskusję. I jestem całkiem przekonany, że
w konkretnych, ściśle określonych warunkach brzegowych profesjonalista 
preferujący MySQL przyzna rację profesjonaliście preferującemu Oracle'a
i vice versa. Jest też dość prawdopodobne, że w pewnym marginesie
zastosowań obaj będą przekonywać z równie silnymi argumentami do wyboru
preferowanego przez nich rozwiązania -- i obaj będą mieli rację.

> Pozatym mysle ze w tym konkretnym przypadku rozumujesz niewlasciwie

Niemożliwe, gdyż nie wnioskuję o konkretnym przypadku, a wysnuwam ogólne
przemyślenia.

I tak, lekko filozoficznie, kończę udział w tym wątku,

p.

-- 
http://nerdquiz.sgh.waw.pl/ -- polska wersja quizu dla nerdów.
http://freedns.sgh.waw.pl/ -- bezpłatny serwis DNS.
http://42.pl/url/ -- skracacz URL-i.

Dnia Wed, 14 Dec 2005 22:31:30 +0100, Witek Świerzy napisał(a):

> Widzisz - nie. Systemy takie pracuja _glownie_ jako krytyczne systemy 
> transakcyjne - musza byc praktycznie dostepne 7x24. Warehousing to inna 
> sprawa. Nie znam banku operajacego swoje systemy _TRANSAKCYJNE_  o 
> narzedzia OS. 

Widdzisz, ja znam jeden bank ktory ostatnio chce przesiasc z Oracla na
MySQL. Co prawada tylko w jednym malym produkcie, nie ogolnie, ale zawsze.
A w mojej dzialce (telekomunikacja) znam operatorow ktorzy uzywaja
PostgreSQL. Co wczesniej mnie jednak dziwilo (dzis juz nie) to w branzy
loterii itp to kroluje VMS z jakas tam RDBMS. (najczesciej Oracle)

> pozdrawiam
> Witek Swierzy
> wswier@sgh.waw.pl
> PS
> Serce rosnie jak dyskusja kwitnie ;-)

Dyskusja bylaby bardziej odpowiednia na pcoa ;-)

Grzechu

Witek Świerzy schrieb:
> Maciej Zobniow wrote:
> 
>> Piotr KUCHARSKI wrote:
>>
>>> Witek Świerzy <wswier@sgh.waw.pl> wrote:
>>>
>>>>> Mam nadzieje ze mnie dobrze zrozumiales: do systemu na spoko, gdzie 
>>>>> klientami jest parunastu pijacych kawe, leniwych analitykow ;).
>>>>
>>>>
>>>>
>>>> Nie - do systemu ktorego klientami sa setki lub tysiace operatorow 
>>>> "porozkladanych" na terenie calego kraju.
>>>
>>>
>>>
>>>
>>> Wydaje mi się, że to mniej więcej sedno problemu. Tam, gdzie inni
>>> stawiają duże w ich mniemaniu bazy na mysql, tam Ty widzisz jakąś
>>> mikrobazkę (która niemal równie dobrze może być na flatfile :>),
>>> a przez "duża baza" masz na myśli ze dwa rzędy wielkości więcej.
>>
>>
>>
>> Oczywiscie problem skali istnieje, ale dlatego na samym poczatku 
>> dyskusji podalem pare danych o mojej bazie. Pozatym mysle ze w tym 
>> konkretnym przypadku rozumujesz niewlasciwie poniewaz opierajac sie na 
>> komplementarnych danych z mojego systemu, do tych ktore skomentowales 
>> z postu Witka wychodzi ze ja mam w systemie 8107200 "operatorow", 
>> rozsianych po calym globie.
>>
>> Pozdro
>> Maciek
> 
> Wydaje mi sie, ze Piotr ma duzo racji. Oprocz liczby sesji liczy sie 
> jeszcze tempo przyrostu danych. Twoja baza, Macku, uzbierala tych danych 
> (o ile sobie dobrze przypominam)  - ok 35 GB przez 4 lata 
> funckjonowania, czyli ok. 9GB rocznie srednio liczac. Znam systemy 
> przyrastajace o kilka rzedow wielkosci szybciej - jak sadze, OS by 
> raczej tego nie uciagnal. Zreszta w moim poscie chcialem przede 
> wszystkim uwypuklic koniecznosc pracy takich systemow 7x24. Wszak 
> niemoznosc wykonania jakielkolwiek transakcji przynosi takiej instytucji 
> latwo wyliczalne straty (srednia_kwota_przelewu * prowizja_banku). Wiec 
> 2-godzinny przestoj o ktorym wspominales poprzednio kosztuje calkiem 
> spore pieniadze, a wiec jest nieakceptowalny. I wlasnie dlatego stosuje 
> sie tam systemy _NIE_OS_. Dysponuja one naprawde szerszymi mozliwosciami 
> uodpornienia sie na awarie od OS. Nie chcialbym wchodzic na tej liscie w 
> szczegoly (temat baz danych jest tu troche OT, bylo nie bylo :-), ale 
> proponuje Ci abys poczytal np. o mozliwosciach klastrowania Oracle, 
> bazach standby, architekturze data guard itp. Wydaje sie, ze zaden 
> system OS nie dysponuje takimi mozliwosciami. Tak wiec, gdybys 
> przerzucil swoj system np. na oracle ( posluguje sie tutaj najczesciej 
> tym przykladem z racji doswiadczen zawodowych) to moze rzadziej bylbys 
> budzony o 4 am w niedziele. Inna sprawa to oczywiscie koszty - 
> najpewniej taniej jest Cie obudzic o 4 (nie mowie, ze bezpieczniej - 
> wszak dobry Polak, to Polak najedzony i wyspany ;-) rano niz wydac spora 
> kwote pieniedzy na system komercyjny. Poza tym liczy sie rowniez 
> bezpieczenstwo w sensie odpornosci na potencjalne wlamania - i tutaj tez 
> wydaje sie, ze systemy komercyjne dysponuja wieksza liczba zabezpieczen 
> od darmowych (pomijam tu rzecz oczywista jak dostep po https do web 
> serwera - to sie rozumie samo przez sie, ale mowie juz o mechanizmach 
> zaszytych w DBMS-ach - no ale znowu OT, wiec nie rozwijam tematu bez 
> wyraznego zaproszenia :-).

W tym momencie cisnie sie na usta pytanie: skoro wszystkie banki stosuja 
te "wielkie, profesjonalne rozwiazania", to dlaczego co jakis czas na 
stronach co najmniej kilku bankow (w Polsce i w Niemczech) widze "w dniu 
takim a takim, w godzinach (nocnych) takich a takich bedzie przerwa w 
dzialaniu systemu transakcyjnego Banku XYZ".

Rozumiem, ze banki masowo zaczely stosowac MySQL, czy z tymi 
komercyjnymi systemami nie jest tak rozowo jak piszesz?


-- 
Tomek

Grzegorz Rumatowski <grzechu@noname.com> wrote:
> > Serce rosnie jak dyskusja kwitnie ;-)
> Dyskusja bylaby bardziej odpowiednia na pcoa ;-)
Byłaby, ale chociaż pl.comp.os.unix zostało rozruszane. ;)
Poza tym, dzięki temu, udało się uniknąć efektu ponuraka.

Pozdrawiam,

			Krzysztof Oledzki

-- 
Krzysztof Olędzki
e-mail address:		ole(a-t)ans(d-o-t)pl
Registered User:	Linux - 189200, BSD - 51140
Nick Handles:		KO60-RIPE, KO60-6BONE, KO581 (Network Solutions)

Maciej Zobniow <mzobniow-removeit@zobniow.net> wrote:

> online-bankingu z poziomu usera. Kozystam z uslug jednego z najwiekszych 
> bankow w Niemczech (zebys nie bredzil o "polskiej amatorszczyznie"): 

Bredzil? Nie. Ja nie bredze.

> Commerzbank.  Mam u nich konto od okolo 4 lat. Nie chce sie na nich 
> specjalnie skarzyc bo nie jest tak zle, jednak bywalo ze portal lezal 
> przez dluzszy czas. Szczegolnie jak padnie czasem w sobote to juz nie ma 
> szans zeby wstal do poniedzialku. Porownujac to do biznesu aplikacji 

Wiec jest to taka sama amatorszczyzna jak w niektorych polskich bankach.

> Wracajac do "polskiej amatorszczezny". Rozumiem ze to wlasnie OS do niej 
> zaliczasz? To ciekawe, ale to w Polsce zaobserwowalem najbardziej 

Nie. Nic nie zrozumiales. Pisales o bankach. O problemach z dostepem
do ich bankowosci internetowej. To jest 'polska amatorszczyzna'. Czytaj 
uwazniej, bo sie chyba juz gubisz.

-- 
Przemysław Maciuszko

Użytkownik Piotr KUCHARSKI napisał:
> Maciej Zobniow <mzobniow-removeit@zobniow.net> wrote:
> 
>>>Wydaje mi się, że to mniej więcej sedno problemu. Tam, gdzie inni
>>>stawiają duże w ich mniemaniu bazy na mysql, tam Ty widzisz jakąś
>>>mikrobazkę (która niemal równie dobrze może być na flatfile :>),
>>>a przez "duża baza" masz na myśli ze dwa rzędy wielkości więcej.
>>
>>Oczywiscie problem skali istnieje, ale dlatego na samym poczatku 
>>dyskusji podalem pare danych o mojej bazie.
> 
> 
> ...która dla Ciebie jest duża, ale do uciągnięcia przez MySQL i dobrze 
> wam tak razem, ale która dla Witka jest maleństwem, którym on się zwykle
> nie zajmuje.
> 
> W tym wypadku MySQL się u ciebie sprawdza świetnie. W innych, bardziej
> wymagających rozwiązaniach nie będzie się sprawdzał -- tam wejdą wielcy
> bracia typu Oracle czy DB2.
> 
> I dobrze. Dla każdego coś dobrego.
> 
> Dla większości zastosowań w internecie MySQL wygląda, że wystarcza (choć
> od razu zastrzegam, że nie używam, jeśli nie muszę, bo wolę PostgreSQL).
> Ale bardzo dobrze, że takie darmowe (i OS) DBMS-y istnieją: umożliwiają
> istnienie wielu projektom bez inwestowania w komercyjne bazy. Ba! Przy
> niewielkim nakładzie w sprzęt umożliwiają też istnienie niektórym ciut
> większym i poważniejszym projektom.
> 
> Ale jestem pewien, że zawsze pozostaną obszary, w których niepodzielnie
> będą królować rozwiązania pokroju Oracle'a.
> 
> I, tak naprawdę, nie ma się co sprzeczać -- wybór rozwiązania zależy od
> zbyt wielu czynników, które trzeba by było dokładnie przeanalizować i na
> tej podstawie podjąć jakąś dyskusję. I jestem całkiem przekonany, że
> w konkretnych, ściśle określonych warunkach brzegowych profesjonalista 
> preferujący MySQL przyzna rację profesjonaliście preferującemu Oracle'a
> i vice versa. Jest też dość prawdopodobne, że w pewnym marginesie
> zastosowań obaj będą przekonywać z równie silnymi argumentami do wyboru
> preferowanego przez nich rozwiązania -- i obaj będą mieli rację.
> 
> 
>>Pozatym mysle ze w tym konkretnym przypadku rozumujesz niewlasciwie
> 
> 
> Niemożliwe, gdyż nie wnioskuję o konkretnym przypadku, a wysnuwam ogólne
> przemyślenia.
> 
> I tak, lekko filozoficznie, kończę udział w tym wątku,

Zaznacze tylko na koniec ze jakbys zadal sobie trud i przeczytal pare 
poprzednich postow w tym watku, zauwazylbys zapewne, ze ja caly czas 
bronie pogladu ktory byles uprzejmy tu wylozyc.

Pozdro
Maciek

Stachu 'Dozzie' K. <dozzie@dynamit.im.pwr.wroc.pl.nospam> wrote:

> Ja na przykład nie miałem nigdy do czynienia z systemem bankowym
> i bardzo chętnie poczytam.

Ale nie zauwazylem, zebys tutaj pisal jak to w banku wyglada.
Wszystko oczywiscie zalezy od banku. I od systemow. Sa systemy, ktore sa
zabezpieczone na kilka sposobow (klaster, systemy BCP), sa takie ktore nie
maja zadnego zabezpieczenia.
Nawet jednak jesli jest to jakas hurtownia danych w duzym banku - jej
dostepnosc 24/7 jest wymagana w 95% przypadkow.
I nie moze miec miejsca sytuacja w ktorej cos jest niedostepne 2 dni.
Chyba, ze jest to system developerski, ale te np. nie maja z reguly zadnych
zabezpieczen i nie sa z reguly nawet backupowane.
Co wiecej - support ma gradacje i rzecz pt. "dzwonienie do Pana admina na 
dyzurze telefonicznym", to dopiero Level 3.
Awaria musi byc naprawde powazna (albo problem), aby lokalny admin bedacy na
dyzurze musial 'wstawac o 4 nad ranem'.
Kolejna sprawa - srodowisko jest bardzo kompleksowe.
Sa bazy postawione np. na DB2, jest Oracle, jest Sybase.
Wlasnie - ciekawostka. Na zachodzie Sybase sie bardzo dobrze trzyma. W Polsce
prawie go nie widac.
Oczywiscie - zdarzaja sie wpadki nawet duzym bankom. Kiedy np. traderzy nie
moga pracowac, a kazda minuta, to strata rzedu kilku milionow dolarow.


-- 
Przemysław Maciuszko

Użytkownik Przemysław Maciuszko napisał:
> Maciej Zobniow <mzobniow-removeit@zobniow.net> wrote:
> 
> 
>>online-bankingu z poziomu usera. Kozystam z uslug jednego z najwiekszych 
>>bankow w Niemczech (zebys nie bredzil o "polskiej amatorszczyznie"): 
> 
> 
> Bredzil? Nie. Ja nie bredze.
> 
> 
>>Commerzbank.  Mam u nich konto od okolo 4 lat. Nie chce sie na nich 
>>specjalnie skarzyc bo nie jest tak zle, jednak bywalo ze portal lezal 
>>przez dluzszy czas. Szczegolnie jak padnie czasem w sobote to juz nie ma 
>>szans zeby wstal do poniedzialku. Porownujac to do biznesu aplikacji 
> 
> 
> Wiec jest to taka sama amatorszczyzna jak w niektorych polskich bankach.

To dosc ryzykowne stwierdzenie. Commerzbank to jeden z najwiekszych 
Niemickich bankow, pozatym koledzy ktorzy maja konta w innych 
niemieckich bamkach (DB, Dresden Bank, Sparkasse) narzekaja znacznie 
czesciej.

> Nie. Nic nie zrozumiales. Pisales o bankach. O problemach z dostepem
> do ich bankowosci internetowej. To jest 'polska amatorszczyzna'. Czytaj 
> uwazniej, bo sie chyba juz gubisz.
>

Ustalilismy juz ze w Niemczech i Polsce w bankach pracuja sami amatorzy. 
W ktorym kraju wiec twoim zdaniem mozna liczyc na profesjonalna obsluge?

Pozdro
Maciek

Użytkownik Przemysław Maciuszko napisał:
> Stachu 'Dozzie' K. <dozzie@dynamit.im.pwr.wroc.pl.nospam> wrote:
> 
> 
>>Ja na przykład nie miałem nigdy do czynienia z systemem bankowym
>>i bardzo chętnie poczytam.
> 
> 
> Ale nie zauwazylem, zebys tutaj pisal jak to w banku wyglada.
> Wszystko oczywiscie zalezy od banku. I od systemow. Sa systemy, ktore sa
> zabezpieczone na kilka sposobow (klaster, systemy BCP), sa takie ktore nie
> maja zadnego zabezpieczenia.

Uwazasz ze w asp zabespieczamy systemy tylmko na jeden sposob? ;)

> Nawet jednak jesli jest to jakas hurtownia danych w duzym banku - jej
> dostepnosc 24/7 jest wymagana w 95% przypadkow.

Wszystkie systemy komputerowe sa stawiane po to zeby chodzily 
bezawaryjnie. Bezawaryjnosc niektorych z nich jest jednak bardziej 
krytyczna od innych.

> Co wiecej - support ma gradacje i rzecz pt. "dzwonienie do Pana admina na 
> dyzurze telefonicznym", to dopiero Level 3.

To tez nie jest cos charakterystycznego dla banku. Z reguly tylko liczba 
leveli sie zmienia w zaleznosci od wielkosci organizacji.

Pozdro
Maciek

Użytkownik Witek Świerzy napisał:
> Maciej Zobniow wrote:
> 
>> Piotr KUCHARSKI wrote:
>>
>>> Witek Świerzy <wswier@sgh.waw.pl> wrote:
>>>
>>>>> Mam nadzieje ze mnie dobrze zrozumiales: do systemu na spoko, gdzie 
>>>>> klientami jest parunastu pijacych kawe, leniwych analitykow ;).
>>>>
>>>>
>>>>
>>>> Nie - do systemu ktorego klientami sa setki lub tysiace operatorow 
>>>> "porozkladanych" na terenie calego kraju.
>>>
>>>
>>>
>>>
>>> Wydaje mi się, że to mniej więcej sedno problemu. Tam, gdzie inni
>>> stawiają duże w ich mniemaniu bazy na mysql, tam Ty widzisz jakąś
>>> mikrobazkę (która niemal równie dobrze może być na flatfile :>),
>>> a przez "duża baza" masz na myśli ze dwa rzędy wielkości więcej.
>>
>>
>>
>> Oczywiscie problem skali istnieje, ale dlatego na samym poczatku 
>> dyskusji podalem pare danych o mojej bazie. Pozatym mysle ze w tym 
>> konkretnym przypadku rozumujesz niewlasciwie poniewaz opierajac sie na 
>> komplementarnych danych z mojego systemu, do tych ktore skomentowales 
>> z postu Witka wychodzi ze ja mam w systemie 8107200 "operatorow", 
>> rozsianych po calym globie.
>>
>> Pozdro
>> Maciek
> 
> Wydaje mi sie, ze Piotr ma duzo racji. Oprocz liczby sesji liczy sie 
> jeszcze tempo przyrostu danych. Twoja baza, Macku, uzbierala tych danych 
> (o ile sobie dobrze przypominam)  - ok 35 GB przez 4 lata 
> funckjonowania, czyli ok. 9GB rocznie srednio liczac.

Blednie zalozyles ze rosla rownomiernie w czasie. Przyrost ten jest 
narazie raczej zblizony do wykladniczego. Np. od czasu rozpoczecia tej 
dyskusji baza przyrosla o ...2GB (da sie odczuc przedswiateczna 
goraczke). Jedno gigabajtowy bin-log replikacji (mysql loguje tam 
wszystkie zmieniajace dane queries: insert, update, delete etc.) 
zapelnia sie czasem w ciagu jednego dnia. Rok temu w styczniu miala 
jakies 9GB (kupilem wtedy dwa dual opterony+12GB ram do klastra bazy i 
bylem zadowolony ze wszystkie tabele pomieszcza sie w cache i jeszcze 
zostanie wystarczajaco duzo miejsca na query i index cache).

  Znam systemy
> przyrastajace o kilka rzedow wielkosci szybciej - jak sadze, OS by 
> raczej tego nie uciagnal.

hehe...wciaz powtarzasz te przesady. Naprawde wierzysz ze to kwestia 
licencji?

  Zreszta w moim poscie chcialem przede
> wszystkim uwypuklic koniecznosc pracy takich systemow 7x24. Wszak 
> niemoznosc wykonania jakielkolwiek transakcji przynosi takiej instytucji 
> latwo wyliczalne straty (srednia_kwota_przelewu * prowizja_banku). Wiec 
> 2-godzinny przestoj o ktorym wspominales poprzednio kosztuje calkiem 
> spore pieniadze, a wiec jest nieakceptowalny. I wlasnie dlatego stosuje 
> sie tam systemy _NIE_OS_. 

Powtorze sie: "nieakceptowalny" znaczy czasem cos zupelnie innego dla 
roznych przypadkowi. W przypadku b2b nieakceptowalny problem moze 
doprowadzic do tego ze jakis klient nam "podziekuje", co jak sie 
domyslasz moze byc bardzo bolesne jesli tych klientow masz powiedzmy 50 
a nie 500k. W tym segmencie niestety,  klienci sa o niebo bardziej 
wymagajacy niz zwykli konsumenci

Dysponuja one naprawde szerszymi mozliwosciami
> uodpornienia sie na awarie od OS. Nie chcialbym wchodzic na tej liscie w 
> szczegoly (temat baz danych jest tu troche OT, bylo nie bylo :-), ale 
> proponuje Ci abys poczytal np. o mozliwosciach klastrowania Oracle, 
> bazach standby, architekturze data guard itp. Wydaje sie, ze zaden 
> system OS nie dysponuje takimi mozliwosciami. Tak wiec, gdybys 
> przerzucil swoj system np. na oracle ( posluguje sie tutaj najczesciej 
> tym przykladem z racji doswiadczen zawodowych) to moze rzadziej bylbys 
> budzony o 4 am w niedziele. 

Moj system jest dobrze zabespieczony na roznego typu sytuacje, problemy, 
jak to zwykle bywa, najczesciej powoduje tzw. czynnik ludzki.

Inna sprawa to oczywiscie koszty -
> najpewniej taniej jest Cie obudzic o 4 (nie mowie, ze bezpieczniej - 
> wszak dobry Polak, to Polak najedzony i wyspany ;-) rano niz wydac spora 
> kwote pieniedzy na system komercyjny. 

I co by to dalo? Myslisz ze klienci byliby mniej wcurwieni jesli by im 
sie powiedzialo ze to Oracle padl, a support enginer jest w drodze? 
Niestety zaden "wujek z kosmosu" nie pomoze, jesli problem bedzie tkwil 
gdzies gleboko w systemie. Wrecz przciwnie, z wlasnego doswiadczenia 
wiem ze wezwanie support enginera do systemow typu asp zazwyczaj 
poteguje klopoty. Dzieje sie tak dlatego ze zazwyczaj ich pierwszym 
zadaniem jest restart. Niestety o ile w windows ta metoda czasem pomaga, 
na Unixie czesto jeszcze bardziej szkodzi.

Poza tym liczy sie rowniez
> bezpieczenstwo w sensie odpornosci na potencjalne wlamania - i tutaj tez 
> wydaje sie, ze systemy komercyjne dysponuja wieksza liczba zabezpieczen 
> od darmowych (pomijam tu rzecz oczywista jak dostep po https do web 
> serwera - to sie rozumie samo przez sie, ale mowie juz o mechanizmach 
> zaszytych w DBMS-ach - no ale znowu OT, wiec nie rozwijam tematu bez 
> wyraznego zaproszenia :-).

Raczej sie mylisz. Akurat moim zdaniem otwarte systemy sa zazwyczaj 
bespieczniejsze. Dzieje sie tak chocby dlatego ze dysponujac zrodlami 
mozesz zawsze przekompilowac dany komponent (kernel, apache i jego 
moduly i inne otwarte na swiat servisy sa zazwyczaj rutynowo 
kompiliowane ze zrodel w systemach produkcyjnych), wywalajac lub dodajac 
potrzebne moduly. Program wynikowy, jest wtedy unikalny i raczej 
niekoniecznie beda na niego dzialaly exploity spreparowane dla 
defaultowych kompilacji.
W kazdym razie, w przypadku DBMS trzeba sie postarac raczej o 
zapewnienie zewnetrznych mechanizmow ochrony, krotko mowiac nalezy baze 
odciac od jakiegokolwiek, bezposredniego zewnetrznego dostepu.

Pozdro
Maciek

Maciek Zobniow <maciekWywalTo@zobniow.net> wrote:

> Uwazasz ze w asp zabespieczamy systemy tylmko na jeden sposob? ;)

Bylbys laskaw czytac uwaznie?

> Wszystkie systemy komputerowe sa stawiane po to zeby chodzily 
> bezawaryjnie. Bezawaryjnosc niektorych z nich jest jednak bardziej 
> krytyczna od innych.

W banku wiekszosc systemow produkcyjnych jest krytyczna. W przeciwienstwie
do gloszonych tutaj przez Ciebie pogladow pt. "lezy 2 dni i wszystko gra".

> To tez nie jest cos charakterystycznego dla banku. Z reguly tylko liczba 
> leveli sie zmienia w zaleznosci od wielkosci organizacji.

Tak. Z tego co pisales wnioskuje, te Ty jestes Level 0.
Niestety po raz kolejny mam wrazenie, czytajac ten watek, tze ludzie pisza
jedno, a Ty komentujac - cos zupelnie innego.

-- 
Przemysław Maciuszko

Maciek Zobniow <maciekWywalTo@zobniow.net> wrote:

> To dosc ryzykowne stwierdzenie. Commerzbank to jeden z najwiekszych 

Ale prawdziwe. 

> Niemickich bankow, pozatym koledzy ktorzy maja konta w innych 
> niemieckich bamkach (DB, Dresden Bank, Sparkasse) narzekaja znacznie 
> czesciej.

Wspolczuje Wam w takim razie jakosci dzialania bankowosci internetowej w 
niemieckich bankach.

> Ustalilismy juz ze w Niemczech i Polsce w bankach pracuja sami amatorzy. 

A teraz lekcja z polskiego. Amatorszczyzna jako efekt widoczny dla klienta,
nie oznacza ze gdzies pracuja amatorzy.
Nie wiem - Ty masz jakies problemy z rozumieniem slow, czy specjalnie 
wszystko tak przekcrecasz?

> W ktorym kraju wiec twoim zdaniem mozna liczyc na profesjonalna obsluge?

W niektorych bankach w Polsce, nie zdarzylo mi sie miec 2-dniowych przerw w 
dzialaniu internetowego dostepu do rachunku.
Po porade w tym temacie zapraszam na grupe pl.biznes.banki

-- 
Przemysław Maciuszko

Użytkownik Przemysław Maciuszko napisał:
> Maciek Zobniow <maciekWywalTo@zobniow.net> wrote:
> 
> 
>>Uwazasz ze w asp zabespieczamy systemy tylmko na jeden sposob? ;)
> 
> 
> Bylbys laskaw czytac uwaznie?
> 
> 
>>Wszystkie systemy komputerowe sa stawiane po to zeby chodzily 
>>bezawaryjnie. Bezawaryjnosc niektorych z nich jest jednak bardziej 
>>krytyczna od innych.
> 
> 
> W banku wiekszosc systemow produkcyjnych jest krytyczna. W przeciwienstwie
> do gloszonych tutaj przez Ciebie pogladow pt. "lezy 2 dni i wszystko gra".

To sa fakty zaobserwowane od strony usera. Przykro mi ze nie pasuja do 
twojego idealu.

> 
> 
>>To tez nie jest cos charakterystycznego dla banku. Z reguly tylko liczba 
>>leveli sie zmienia w zaleznosci od wielkosci organizacji.
> 
> 
> Tak. Z tego co pisales wnioskuje, te Ty jestes Level 0.
> Niestety po raz kolejny mam wrazenie, czytajac ten watek, tze ludzie pisza
> jedno, a Ty komentujac - cos zupelnie innego.

Ciekawe skad tak wywnioskowales? Moj team jest oczywiscie on last line 
support (mamy je niestety w firmie tylko 2). Mysle ze podstawowa roznica 
pomiedzy biznesem asp a bankiem jest taka ze system komputerowy w banku 
jest czyms co tylko wspomaga procesy biznesowe. W asp te procesy sa w 
calosci zaimplementowane w systemie IT, cos jak agregacja i kompozycja w 
uml.

Pozdro
Maciek

Corvin wrote:
> Pawel Z. wrote:
> 
> 
>>
>>tak z ciekawosci, jakie to ambitne i czesto spotykane
>>zadania aministracyjne trzeba wykonywac przy pomocy tego
>>"potężnego narzędzia"?
>>
> 
> 
> zamiast dywagacji proponuje żebyście sobie zapuścili jakiegoś knoppixa i to
> może być ciekawe doświadczenie ;)

i? czemu to ma dowiesc?

chcialby raczej uzyskac odpowiedz na moje pytanie dotyczace zadan,
do ktorych potrzeby jest "zaawansowny" fdisk...

P.

Maciek Zobniow wrote:
>> Wiec jest to taka sama amatorszczyzna jak w niektorych polskich bankach.
> 
> 
> To dosc ryzykowne stwierdzenie. Commerzbank to jeden z najwiekszych 
> Niemickich bankow, pozatym koledzy ktorzy maja konta w innych 
> niemieckich bamkach (DB, Dresden Bank, Sparkasse) narzekaja znacznie 
> czesciej.

coz.. pozwole sobie na wycieczke sociologiczna...
uwzgledniwszy socializm (tak tak) jaki panuje w Niemczech,
stosuneki obywatel - instytucje, nie jest to nic dziwnego...

w UK takie cos byloby nie do pomyslenia... choc przyznac
musze, ze rozwiazania stosowane przez tutejsze banki sa
troche "do tylu" w porownaniu z tymi lepszymi spotykanymi
w Polsce... w ogole e-banking nie jest zbyt popularny...

ale sytuacja, by jakakolwiek usluga oferowana przez bank
byla niedostepna... no way... ;-)


P.

Przemysław Maciuszko wrote:
> Stachu 'Dozzie' K. <dozzie@dynamit.im.pwr.wroc.pl.nospam> wrote:
> 
> 
>>Ja na przykład nie miałem nigdy do czynienia z systemem bankowym
>>i bardzo chętnie poczytam.
> 
> 
> Ale nie zauwazylem, zebys tutaj pisal jak to w banku wyglada.
> Wszystko oczywiscie zalezy od banku. I od systemow. Sa systemy, ktore sa
> zabezpieczone na kilka sposobow (klaster, systemy BCP), sa takie ktore nie
> maja zadnego zabezpieczenia.
> Nawet jednak jesli jest to jakas hurtownia danych w duzym banku - jej
> dostepnosc 24/7 jest wymagana w 95% przypadkow.
> I nie moze miec miejsca sytuacja w ktorej cos jest niedostepne 2 dni.
> Chyba, ze jest to system developerski, ale te np. nie maja z reguly zadnych
> zabezpieczen i nie sa z reguly nawet backupowane.

tak sie sklada, iz obecnie pracuje w firmie zajmujacej sie utrzymywaniem
backupowych systemow w "bezpiecznym miejscu"... naszymi klientami sa
glownie duze firmy z sekrora finasowego z UK... wiekszosc z nich
ma "u nas" rowniez wazniejsze systemy developerskie...

P.

Użytkownik Pawel Z. napisał:
> Maciek Zobniow wrote:
> 
>>> Wiec jest to taka sama amatorszczyzna jak w niektorych polskich bankach.
>>
>>
>>
>> To dosc ryzykowne stwierdzenie. Commerzbank to jeden z najwiekszych 
>> Niemickich bankow, pozatym koledzy ktorzy maja konta w innych 
>> niemieckich bamkach (DB, Dresden Bank, Sparkasse) narzekaja znacznie 
>> czesciej.
> 
> 
> coz.. pozwole sobie na wycieczke sociologiczna...
> uwzgledniwszy socializm (tak tak) jaki panuje w Niemczech,
> stosuneki obywatel - instytucje, nie jest to nic dziwnego...

Tu niestety trzeba ci przyznac racje.

> 
> w UK takie cos byloby nie do pomyslenia... choc przyznac
> musze, ze rozwiazania stosowane przez tutejsze banki sa
> troche "do tylu" w porownaniu z tymi lepszymi spotykanymi
> w Polsce... w ogole e-banking nie jest zbyt popularny...

To akurat troche mnie zaskakuje, bo slyszalem cos zupelnie odwrotnego. 
Jeden kolega namawial mnie nawet kiedys do przeniesienia mojej 
freelancerskiej firmy do UK. Podobno wszystkie formalnosci mozna 
zalatwic przez internet nie ruszajac sie  z Deutschland. Za pare funtow 
mozna zalozyc firme Ltd (u Niemcow zeby zalozyc GmbH trzeba miec 25k 
wkladu). A moze tylko banki pozostaly w tyle za wszystkimi (penie 
dlatego ze nie maja OS ;))?

Pozdro
Maciek

W dniu Thu, 15 Dec 2005 09:23:46 +0000 (UTC), osoba określana zwykle jako
Przemysław Maciuszko pozwoliła sobie popełnić co następuje:
>Wlasnie - ciekawostka. Na zachodzie Sybase sie bardzo dobrze trzyma. W Polsce
>prawie go nie widac.

Weź mnie nie denerwuj ;-/
(BTW, dlaczego deweloperzy tych wspaniałych enterprise-level baz danych nie
mogą zaimplementować (a przynajmniej nie mogli; nie wiem jak jest w
chwili obecnej) tak prostej funkcjonalności jak "SELECT [...] LIMIT
fafnaście"???

-- 
  Kruk@ -\                   | Wiesz  to takie moje zboczenie zawodowe, jak
          }-> epsilon.eu.org | widzę kwiaty to patrzę gdzie jest trumna
http:// -/                   | 
                             | 

Mariusz Kruk <Mariusz.Kruk@epsilon.eu.org> wrote:
> (BTW, dlaczego deweloperzy tych wspaniałych enterprise-level baz danych nie
> mogą zaimplementować (a przynajmniej nie mogli; nie wiem jak jest w
> chwili obecnej) tak prostej funkcjonalności jak "SELECT [...] LIMIT
> fafnaście"???

Bo standard SQL nic nie wspomina o LIMIT, tylko o ROW_NUMBER() OVER,
ewentualnie o kursorach.

p.

-- 
http://nerdquiz.sgh.waw.pl/ -- polska wersja quizu dla nerdów.
http://freedns.sgh.waw.pl/ -- bezpłatny serwis DNS.
http://42.pl/url/ -- skracacz URL-i.

W dniu 15 Dec 2005 19:50:36 GMT, osoba określana zwykle jako
Piotr KUCHARSKI pozwoliła sobie popełnić co następuje:
>> (BTW, dlaczego deweloperzy tych wspaniałych enterprise-level baz danych nie
>> mogą zaimplementować (a przynajmniej nie mogli; nie wiem jak jest w
>> chwili obecnej) tak prostej funkcjonalności jak "SELECT [...] LIMIT
>> fafnaście"???
>Bo standard SQL nic nie wspomina o LIMIT, tylko o ROW_NUMBER() OVER,
>ewentualnie o kursorach.

Owszem. Co nie zmienia faktu, że jest to mocno wygodne w pewnych
sytuacjach.

-- 
d'`'`'`'`'`'`'`'`'`'`'`'`'Yb BUTT.COM IS NOT MY E-MAIL ADDRESS(Bart Simp-
`b  Kruk@epsilon.eu.org   d' son on chalkboard in episode 5F19)
d' http://epsilon.eu.org/ Yb 
`b,-,.,-,.,-,.,-,.,-,.,-,.d'