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