On Tue, 28 Jul 2015 22:27:52 +0200, Sebastian
Biały<h...@p...onet.pl> wrote:
> Nie miała. Nazwyczajniej w świecie nie dawało się jej nowych tasków
bo
> by sie przekręciła. Twoje "wystarczająco" zakłada brak rozwoju. Tak
samo
> mysleli mistrzowie od Elixiru. Efektem dzisiaj mamy co najmniej
> idiotyczny system rozliczen międzybankowych gdzie przelewy nosi się
> chyba w wiadrach między komputerami sądząc po czasach.

W interesie banku wcale nie jest, żeby przelew szedł natychmiast.
Poza tym chcą mieć pewnie bufor czasowy na ewentualne kontrole.

Polska i tak ma dość szybkie przelewy w porównaniu z np. UK.

RW

do góry

On Wed, 29 Jul 2015 01:29:27 +0200, szemrany <s...@o...off>
wrote:
> I skąd przekonanie o braku potrzeby szybkiego przelewu u
Kowalskiego? Gdyby
> to była prawda nie istniałyby BlueCashe, Przelewy24, DotPaye,
PayPale,
> Transferuje, Payu, zPay, PayByNet, ePrzelerwy, YetiPay i pewnie
jeszcze
> jakieś. Zgodzisz się?

To nie są pełne ekwiwalenty przelewu międzybankowego. Inne ryzyko
kredytowe itp.

RW

do góry

On Wed, 29 Jul 2015 01:29:27 +0200, szemrany <s...@o...off>
wrote:
> A co stoi na przeszkodzie by to się odbywało online i za darmo?
Czemu musi
> trwać wieki lub kosztować? Są jakieś techniczne problemy z tym?

W bankowości na ogół jak coś działa inaczej niż się spodziewasz to
dlatego, że ktoś na tym zarabia (pieniądze w trakcie przelewu są
"niczyje" i można je komuś pożyczyć na trochę) albo regulacje
państwowe wymagają dodatkowych operacji.

RW

do góry

Dnia 28.07.2015 szemrany <s...@o...off> napisał/a:
> To z tego, że Odra miała fatalny współczynnik wydajności na wat oraz była
> trudna w konserwacji.

Jak ktoś ma swoje zakłady energetyczne, to się "watami" aż tak bardzo nie
przejmuje. Nie twierdzę, że TERAZ bym coś na Odrze wdrażał, ale zmieniać
dla samej zmiany to też bezsens (moim zdaniem oczywiście).

>> Są różne systemy rozliczeń międzybankowych, Elixir jest tylko jednym z
>> nich, jest powszechny i tani (zwykle bezpłatny) a szybkość działania jest
>> wystarczająca dla przeciętnego Kowalskiego (i tak są szybkie w porównaniu
>> do systemów "konsumenckich" w innych krajach), gdy potrzeba szybkiego
>> przelewu, to się robi SORBNET (w większości banków płatny) i pieniądze są
>> księgowane w kilka minut pomiędzy dwoma różnymi bankami.
>
> A co stoi na przeszkodzie by to się odbywało online i za darmo? Czemu musi
> trwać wieki lub kosztować? Są jakieś techniczne problemy z tym?
> I skąd przekonanie o braku potrzeby szybkiego przelewu u Kowalskiego? Gdyby
> to była prawda nie istniałyby BlueCashe, Przelewy24, DotPaye, PayPale,
> Transferuje, Payu, zPay, PayByNet, ePrzelerwy, YetiPay i pewnie jeszcze
> jakieś. Zgodzisz się?

Elixir powstał w czasach, kiedy internetów (zwłaszcza domowych) nie było,
był przystosowany do komunikacji protokołem X.25 (zwykłe modemy
telefoniczne i połączenie dial-up a nie stałe łącze) a także do
przenoszenia informacji off-line (na przykład na dyskietce) - w początkach
lat 90-tych (gdy powstawał) było to jak najbardziej słuszne założenie, bo
internet w takim rozumieniu jaki mamy dzisiaj, po prostu nie istniał w
świecie komercyjnym (istniał głównie w ośrodkach akademickich). Dlatego
wszystko jest oparte o system sesji a nie "live data". Patrząc na sprawę z
dzisiejszej perspektywy pewnie, że można było zrobić wiele rzeczy inaczej,
ale wiele spraw "wychodzi w praniu" a tu trzeba było zrobić system, który
zintegruje wszystkie większe polskie banki (które w pierwszej połowie lat
90-tych różnie wyglądały pod względem zinformatyzowania) i zrobi to "raz a
dobrze" (w kontekście tamtych czasów, gdzie nie było bankowości
internetowej).
A czemu system SORBNET ma kosztować? Bo jest znacznie kosztowniejszy w
utrzymaniu i ma znacznie większe wymagania od systemów które są w
poszczególnych bankach. To jak różnica między SMS-em a połączeniem
telefonicznym, w systemie Elixir banki robią zestawienie "off-line", potem
wysyłają "e-maila" do systemu centralnego, system centralny może sobie
kolejkować zadania, gdy już policzy salda i listy przelewów, to może to
odesłać ponownie do banku (w praktyce to bank sam odpytuje po kilku
godzinach) i bank przetwarza to też "w swoim tempie". Systemy bankowe mogą
działać na zasadzie "eksport do pliku/import z pliku", natomiast w
systemach RTGS po pierwsze system centralny musi być w stanie obsłużyć
szczytowe obciążenia na bieżąco (Elixir może sobie to kolejkować i
rozładować w czasie), a po drugie system bankowy musi być przystosowany do
księgowania "live" nawet podczas prac konserwacyjnych itp. (w systemie
Elixir można po prostu pobrać sesję w innym czasie).
Te wszystkie PayPale, Przelewy24 itp. przede wszystkim dają uniwersalne API
dla twórców sklepów internetowych bez potrzeby bezpośredniej obsługi na
przykład kart kredytowych, po prostu kupujesz usługę płatności i
przestajesz się interesować tym, że każdy klient ma konto w innym banku czy
używa innej karty płatniczej.

>>> Hardwareowa zbliżała się do granicy rozpadu krzemu na kwarki i
>>> wypadnięcia koralików z pamięci. Części zamienne w kilku muzeach były
>>> ale diabli wiedzą czy sprawne. 20 lat temu sam przyczyniłem sie do
>>> rozebrania, poprzez rozlutowanie na warsztatach szkolnych, jednej
>>> sztuki. Nie wiem czy bym chciał aby pracowała do dzisiaj - jakość
>>> montażu była tragiczna.
>>
>> Mimo wszystko pracowały kilkadziesiąt lat, obecny czas życia serwera to
>> kilka lat.
>
> Czemu nie jeździsz Fiatem 125p? Widuje je jeszcze na ulicach. Czemu nie
> używasz komórki wielkości bloczka? Czemu nie mieszkasz w lepiance?
> Argument, że komputer, synonim postępu i pędu technologicznego (sic!)
> pracował kilkadziesiąt lat jest ...antyargumentem.

Akurat co do samochodu, to nie trafiłeś, jeżdżę 20-letnim Mercedesem -
NIGDY nie stanął w drodze, zawsze bez problemu odpala zimą, a że nie ma
kupy plastiku i skai tylko skórę i metal - no cóż, dla mnie to nie wada,
jest duży i wygodny, a jak mi się kiedyś jakaś babka nową Yariską władowała
z tyłu, to ją odwieźli na lawecie a ja po prostu mogłem pojechać dalej,
tylko lakier był do poprawienia. Po co mam zmieniać ten samochód? Tylko
dlatego, że są nowsze modele? Co w ten sposób zyskam? O 1 litr mniejsze
zużycie paliwa na 100km? Gdybym kupił auto za 100_000PLN, to mi się ten
zakup "zwróci" w paliwie dopiero po przejechaniu pół miliona kilometrów, a
przy okazji nowe auta mają bardzo drogi serwis (jak z "tanimi" drukarkami,
kupujesz tanio, ale tonery/głowice drogie). Nie widzę ani jednego powodu
dla którego miałbym wymienić stare i sprawdzone auto na nowe.
Co do "antyargumentu" - jest na przykład taka firma Urban, która produkuje
maszyny przemysłowe (na przykład do stolarki budowlanej typu produkcja
drewnianych okien). Jaki jest sens wymiany komputerów sterujących tymi
maszynami co 2-3 lata? Maszyna pracuje powiedzmy 15-20 lat, to i komputer
sterujący też ma mieć żywotność 20 lat.
To że jakiś komputer pracował 20 lat nie jest antyargumentem, po prostu
pracował i już, to nic złego, że jakiś komputer steruje windami w jakimś
wieżowcu 20 lat i nikt go nie wymienia co rok na najnowszy model, to po
prostu racjonalne postępowanie.

>>> Bo jak pewnego dnia zejdzie operator na zawał to pociągi staną. Nie ma
>>> nikogo w zastępstwie. Koniec.
>>
>> I co to ma wspólnego z Odrą? Jeśli analogiczny system postawisz na chmurze
>> Amazona i wyszkolisz w jego obsłudze jednego operatora, to jak zejdzie, to
>> też "pociągi staną".
>
> Nie, wtedy znajdziesz 10 innych, bo chmura amazona to nowoczesna i
> popularna "technologia".

Miałem na myśli cały system a nie tylko os i hardware. Przykładowo napiszę
system do zarządzania pociągami, postawię to na wszem i wobez znanym
hardware, systemie operacyjnym itd. i zejdę na zawał, co z tego że znasz
się na hardware i os-ie, skoro moja aplikacja się wysypie i tylko ja wiem
jak to poskładać?

>>> Do pralek laduje się ARMy chodzące po kilkaset MHz. Nie dlatego że
>>> trzeba, tylko dlatego że ładowanie tam 8051 mija się z celem - ostatni
>>> programiści na ten badziew właśnie piszą testament.
>>
>> Te z którymi ja miałem do czynienia (Amica, Samsung, Siemens) nie miały
>> ARM-ów po kilkaset MHz tylko 8-bitowe kontrolery po kilkanaście MHz
>> (najczęściej FreeScale). Oczywiście są modele z "bajerami" typu wbudowany
>> tablet, ale mówię o typowych modelach.
>> 8051 to oczywiście zabytek i projektowanie NOWEGO systemu na czymś takim
>> jest bez sensu ale wiele już działających systemów będzie jeszcze działać
>> przez lata. Co do "ostatni programiści na ten badziew piszą właśnie
>> testament" - C to C, piny I/O to piny I/O, nie ma w tym jakiejś wielkiej
>> filozofii, jeśli ktoś jest obyty z mikrokontrolerami, to sobie poradzi bez
>> problemu. Nie trzeba do byle czego bawić się w stawianie kernela Linuxa na
>> ARM-ie, wbrew pozorom to nie upraszcza prostych projektów (typu pralka)
>> tylko je komplikuje.
>
> I jak myślisz, taniej jest zatrudnić developera C od układów 8 bit czy C na
> normalnym (nie okrojonym zasobowo) procesorze i z dostępem do bogatych
> bibliotek?

Na pewno do tego "zasobnego" wyjdzie drożej, bo do tego Linuxa trzeba
napisać drivery do kernela na konkretnego ARM-a, zbudować na tego ARM-a
minidystrybucję (aby ten "developer" mógł korzystać z "bogatych
bibliotek"), trzeba napisać system tak, aby radził sobie z natychmiastowym
brakiem zasilania ("bogate" systemy z mnóstwem bibliotek nie przepadają za
tym) itd. a to tylko proste firmware pralki. Stworzenie firmware na
8-bitowy prosty mikrokontroler (bez systemu operacyjnego) będzie znacznie
prostsze i tańsze (nawet totalni amatorzy, w tym dzieciaki z gimnazjum,
sobie z tym radzą pisząc soft na Arduino z 8-bitowymi AVR-ami, natomiast
ręka do góry kto napisał swój driver do Linuxa obsługujący nietypowy sprzęt
:D).

do góry

W dniu 2015-07-28 17:00, Budzik pisze:
>>> Wysłanie protokołów z komisji wyborczych (mało danych, stosunkowo
>>> mało zapytań) to jest jakieś poważne obciążenie?
>>> Hmm...
>>
>> 1) zależy jak to zaprojektowano
>
> No to trzeba dobrze zaprojektowac - sugerujesz ze wysyłano pliki bmp
> zamiast spakowanego tekstu?

Nie nie to co wysyłano, tylko jak zaprojektowano to wewnątrz- sorki,
robiłeś cos większego niż jakieś strony na mysql-u?

>> 2) tak - bo wszystko jak napisałem odbywa się w tym samym czasie-
>> większość komisji wysyła w tym samym czasie - masz takiego ddosa. I
>> tego nie przewidziano.
>
> Ale to i tak nie jest duzy ruch.
> Poza tym nie przesadzajmy ze w tym samym czasie - moze w ciagu 2-3 godzin
> ale to dla komputerów nie jest przeciez ten sam czas.

Chyba nie pracowałeś w komisji - ok 80-90% komisji będzie próbowało
połączyć się w tej samej godzinie. Mamy ok 3tys komisji (z tego co
pamiętam) wiec trzeba spodziewać się ok 2.5 tysiąca requestów, najpierw
prostsza rzecz, czyli identyfikacja i logowanie certyfikatem, później
przesłanie danych, ich walidacja i zapis do bazy - wszystkich razem oraz
zwrócenie informacji. Wszystko wygląda prosto i jest do zrobienia, ale
jak sobie policzysz czas na obsłużenie większości zapytań, to wiesz
czemu były problemy z połączeniem się. Źle zaprojektowano zapis danych -
przez co się rozjechały, a może zrobiono to właśnie jakiś geniusz użył
do tego mysql-a z transakcjami nie do końca dobrze działającymi. Albo w
ogóle o tym nie pomyślał. Albo zaprojektował to tak, że się
zakleszczyły? Z łączenia 2 systemów działających na tej samej bazie,
które musiały mieć jedną tabelę wspólna, a jednocześnie pracujące na
innych rodzajach transakcji pamiętam, że można było takie coś nawet
działające w laboratorium mieć, jednak, gdy testowaliśmy to w
rzeczywistości, okazało się, że wpływ miało też jakość połączenia, które
mogło dłużej jakiś zasób przetrzymać i nie nie musiały być wysyłane duże
dane. I przy dużo mniejszym obciążeniu niz w warunkach laboratoryjnych
system się wywalał.

>
>> I nie nie tylko jest potrzebna szybka obsługa zapytania, ale i problem
>> zachowania spójności - bo o ile - można przyciąć łącze i odrzucić
>> niektóre zapytania, to w tym wypadku geniusze nie zadbali o spójność
>> danych i te które zeszły częściowo zniszczyły cala resztę. Sorki, ale
>> ten kto to projektował nie miał pojęcia o bazach danych większego niż
>> proste strony www.
>>
> Ok, to wszystko kwestia złego oprogramowania.
> Ale wczesniej pisałes, ze tu była potrzebna baza do duzych obciazen.
> Wiec ponawiam pytanie: jakie duze obciazenia, skoro sam piszesz, ze
> problemem było złe oprogramowanie a nie brak wydajnosci bazy.

Jeśli źle zaprojektowano bazę, to właśnie nie wytrzymała obciążenia i
dodatkowo nie potrafiła sobie poradzić z sytuacją ekstremalną i dane
były niespójne.


--
Kaczus
http://kaczus.ppa.pl

do góry

On Wednesday, July 29, 2015 at 7:37:32 AM UTC+2, Tomasz Kaczanowski wrote:
> W dniu 2015-07-28 17:00, Budzik pisze:
> >>> Wysłanie protokołów z komisji wyborczych (mało danych, stosunkowo
> >>> mało zapytań) to jest jakieś poważne obciążenie?
> >>> Hmm...
> >>
> >> 1) zależy jak to zaprojektowano
> >
> > No to trzeba dobrze zaprojektowac - sugerujesz ze wysyłano pliki bmp
> > zamiast spakowanego tekstu?
>
> Nie nie to co wysyłano, tylko jak zaprojektowano to wewnątrz- sorki,
> robiłeś cos większego niż jakieś strony na mysql-u?
>
> >> 2) tak - bo wszystko jak napisałem odbywa się w tym samym czasie-
> >> większość komisji wysyła w tym samym czasie - masz takiego ddosa. I
> >> tego nie przewidziano.
> >
> > Ale to i tak nie jest duzy ruch.
> > Poza tym nie przesadzajmy ze w tym samym czasie - moze w ciagu 2-3 godzin
> > ale to dla komputerów nie jest przeciez ten sam czas.
>
> Chyba nie pracowałeś w komisji - ok 80-90% komisji będzie próbowało
> połączyć się w tej samej godzinie. Mamy ok 3tys komisji (z tego co
> pamiętam) wiec trzeba spodziewać się ok 2.5 tysiąca requestów,
2500 to nie tak dużo.


> najpierw
> prostsza rzecz, czyli identyfikacja i logowanie certyfikatem, później
> przesłanie danych, ich walidacja i zapis do bazy - wszystkich razem oraz
> zwrócenie informacji. Wszystko wygląda prosto i jest do zrobienia, ale
> jak sobie policzysz czas na obsłużenie większości zapytań, to wiesz
> czemu były problemy z połączeniem się.
Dajmy 1s na obsłużenie zapytania. 2500tys to niecała godzina. Nie wygląda
to groźnie.


> Źle zaprojektowano zapis danych -
> przez co się rozjechały, a może zrobiono to właśnie jakiś geniusz użył
> do tego mysql-a z transakcjami nie do końca dobrze działającymi.
Eeee przesadzasz. Trudniejsze zadania wytrzymuje ten silnik.


> Albo w
> ogóle o tym nie pomyślał. Albo zaprojektował to tak, że się
> zakleszczyły?
> Z łączenia 2 systemów działających na tej samej bazie,
> które musiały mieć jedną tabelę wspólna, a jednocześnie pracujące na
> innych rodzajach transakcji pamiętam, że można było takie coś nawet
> działające w laboratorium mieć, jednak, gdy testowaliśmy to w
> rzeczywistości, okazało się, że wpływ miało też jakość połączenia, które
> mogło dłużej jakiś zasób przetrzymać i nie nie musiały być wysyłane duże
> dane. I przy dużo mniejszym obciążeniu niz w warunkach laboratoryjnych
> system się wywalał.

Nie wiem po co zgadywać. Poniższy schemat:
1) Połączenie, autoryzacja, autentykacja.
2) Przesył danych.
3) Brak obliczeń, brak normalizacji danych, etc.
4) Zapis danych w bazie.
5) Zamknięcie połączenia.
ten silnik powinien wytrzymać na takim ruchu.

Po prostu zrobili inaczej.

do góry

On Wednesday, July 29, 2015 at 7:37:32 AM UTC+2, Tomasz Kaczanowski wrote:
> Jeśli źle zaprojektowano bazę, to właśnie nie wytrzymała obciążenia i
> dodatkowo nie potrafiła sobie poradzić z sytuacją ekstremalną i dane
> były niespójne.
Ale po kiego tutaj jakoś szczególnie projektować? Nie było żadnej
ekstremalnej sytuacji.

do góry

W dniu 2015-07-29 o 09:42, M.M. pisze:
> On Wednesday, July 29, 2015 at 7:37:32 AM UTC+2, Tomasz Kaczanowski wrote:
>> Jeśli źle zaprojektowano bazę, to właśnie nie wytrzymała obciążenia i
>> dodatkowo nie potrafiła sobie poradzić z sytuacją ekstremalną i dane
>> były niespójne.
> Ale po kiego tutaj jakoś szczególnie projektować? Nie było żadnej
> ekstremalnej sytuacji.

Tak ,,pomyśleli", nie zaprojektowali i mieliśmy ,,ekstremalną sytuację"...

do góry

On 2015-07-28, szemrany <s...@o...off> wrote:
>> Są różne systemy rozliczeń międzybankowych, Elixir jest tylko jednym z
>> nich, jest powszechny i tani (zwykle bezpłatny) a szybkość działania jest
>> wystarczająca dla przeciętnego Kowalskiego (i tak są szybkie w porównaniu
>> do systemów "konsumenckich" w innych krajach), gdy potrzeba szybkiego
>> przelewu, to się robi SORBNET (w większości banków płatny) i pieniądze są
>> księgowane w kilka minut pomiędzy dwoma różnymi bankami.
>
> A co stoi na przeszkodzie by to się odbywało online i za darmo? Czemu musi
> trwać wieki lub kosztować? Są jakieś techniczne problemy z tym?
> I skąd przekonanie o braku potrzeby szybkiego przelewu u Kowalskiego? Gdyby
> to była prawda nie istniałyby BlueCashe, Przelewy24, DotPaye, PayPale,
> Transferuje, Payu, zPay, PayByNet, ePrzelerwy, YetiPay i pewnie jeszcze
> jakieś. Zgodzisz się?

Ja się nie zgodzę. Pieniądze z tych usług "płatności ekspresowych" nadal
idzie dwa-trzy dni. To nie o szybkość przelewu chodzi, tylko
o automatyzację księgowania wpłaty i natychmiastowe potwierdzenie
zlecenia przelewu.

--
Secunia non olet.
Stanislaw Klekot

do góry

On Wed, 29 Jul 2015 08:03:30 +0000 (UTC), Stachu 'Dozzie' K. wrote:

> On 2015-07-28, szemrany <s...@o...off> wrote:
>>> Są różne systemy rozliczeń międzybankowych, Elixir jest tylko jednym z
>>> nich, jest powszechny i tani (zwykle bezpłatny) a szybkość działania jest
>>> wystarczająca dla przeciętnego Kowalskiego (i tak są szybkie w porównaniu
>>> do systemów "konsumenckich" w innych krajach), gdy potrzeba szybkiego
>>> przelewu, to się robi SORBNET (w większości banków płatny) i pieniądze są
>>> księgowane w kilka minut pomiędzy dwoma różnymi bankami.
>>
>> A co stoi na przeszkodzie by to się odbywało online i za darmo? Czemu musi
>> trwać wieki lub kosztować? Są jakieś techniczne problemy z tym?
>> I skąd przekonanie o braku potrzeby szybkiego przelewu u Kowalskiego? Gdyby
>> to była prawda nie istniałyby BlueCashe, Przelewy24, DotPaye, PayPale,
>> Transferuje, Payu, zPay, PayByNet, ePrzelerwy, YetiPay i pewnie jeszcze
>> jakieś. Zgodzisz się?
>
> Ja się nie zgodzę. Pieniądze z tych usług "płatności ekspresowych" nadal
> idzie dwa-trzy dni. To nie o szybkość przelewu chodzi, tylko
> o automatyzację księgowania wpłaty i natychmiastowe potwierdzenie
> zlecenia przelewu.

Możesz się nie zgadzać, ale:
a) pieniądz idzie natychmiast, bo każdy z tych pośredników ma rachunki we
wszystkich obsługiwanych bankach i klient robiąc przelew z np. ING na PKO
robi de facto do ichniego ING, a oni ze swojego PKO do odbiorcy docelowego
- online.

b) kompletnie mnie czy Kowalskiego jako klienta nie obchodzi mechanizm
działania tylko efekt, robię przelew i po 15 sekundach jest u odbiorcy na
koncie. Koniec tematu. Wszyscy zadowoleni.

--
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

do góry