On Thu, 30 Jul 2015 20:16:51 +0000 (UTC), Pit wrote:

> Gdzie oferują *za darmo*? Bo mi oferują tylko nielimitowane rozmowy przy
> stałej *opłacie* abonamentowej (a i tak regulamin wspomina o "normalnym
> użytkowaniu" :D). Te moje "bezpłatne" połączenia na komórki, stacjonarne,
> SMS-y, MMS-y, "darmowe" 2GB internetu w telefonie itp. kosztuje mnie 50PLN
> miesięcznie (a, bym zapomniał, wziąłem jeszcze dla mamy telefon "za 1PLN").
>
> 3PLN to rozmowy kosztowały jak operatorzy budowali infrastrukturę (sieć
> BTS-ów, pod które trzeba były wykupić/wynająć grunt, doprowadzić zasilanie,
> kupić same BTS-y, wybudować "maszty" itd.), jak pokrywanie kraju się
> skończyło (i skończyło spłacanie kredytów), to i ceny spadły (wstawienie
> karty do UMTS czy LTE do już istniejącego urządzenia jest znacznie tańsze,
> poza tym co innego kilkaset tysięcy aktywnych kart SIM w połowie lat
> 90-tych a co innego 40 milionów teraz - sam koszt utrzymania BTS-ów
> rozkłada się na więcej użytkowników).
>
> W każdym razie jeśli wierzysz, że dzwonisz za darmo, bo operator nie kasuje
> Cię za każdą minutę z osobna, to nie mam więcej pytań ;)

Dzwonię za darmo w tym sensie, że gdy nie dzwonię to nadajnik i tak stoi, i
tak czerpie energię, i tylko procesor zamiast przetwarzać moje konwersacje
mieli puste pętle w oczekiwaniu na robotę. Jak dzwonię to nie powoduję
większego zużycia miedzi w kablach czy krzemu w prockach. Trochę więcej
prądu idzie, ale nie ma to znaczenia istotnego.
W tym wszystkim transmisja głosu czy internet to tylko ficzer, który
docelowo ma zachęcać do skorzystania i dać szansę sprzedać komercyjną
usługę dodatkową. A to, że jeszcze się to aż tak bardzo nie rozwinęło to
tylko kwestia czasu. Ten model dobrze obrazuje np. Spotify, używasz? Możesz
sobie za darmo słuchać muzy, ale masz odcięte usługi premium, część ludzi
jednak chce premium i dopłacają utrzymując system. Z internetem i
telefonowaniem jest to trochę opóźnione, bo nie mają dobrych pomysłów jak
wykorzystać szerzej te możliwości, ale powoli się to zmienia.

>> Ale CO JEST KOSZTOWNIEJSZE? Naprawdę masz na myśli łącze sieciowe? Bo za
>> grzyba nie mogę wyobrazić sobie co może być droższego w połączeniu stałym
>> od połączenia 3 razy na dobę.
>>
>> ps. stałe połączenie pozwoliłoby na zmniejszenie ruchu i nie dopuszczałoby
>> do chwilowego obciążenia sieci, które występuje gdy się "pompuje" wszystko
>> naraz
>>
>
> To jest grupa o programowaniu, więc zakładam, że coś tam programujesz i na
> przykład systemy do zarządzania kodem pokroju Subversion czy Git znasz.
> Wyobraź sobie następującą analogię: pliki źródłowe to konta userów,
> programiści to banki, a serwer z repozytorium to KRI (czy NBP czy
> jakiekolwiek inne "centrum rozliczeń"). Przyjmijmy, że chodzi o Git-a.
> Dla "elixira" działa to tak, że zmieniasz sobie zawartość plików (stany
> kont), potem robisz commit (robisz zestawienie wszystkich stanów
> zmienionych kont, taki "point in time"), potem robisz push (wysyłasz zmiany
> do "serwera rozliczającego"), następnie inni robią pull (aby zobaczyć Twoje
> zmiany) jak i ty robisz pull (aby zobaczyć zmiany wprowadzone przez
> innych). Proste i nie wymaga wysokiej wydajności, bo push/pull w danej
> chwili robi jedna, bądź maksymalnie kilka osób jednocześnie (przy powiedzmy
> 100 osobach w zespole).
> A teraz wyobraź sobie, że masz zapewnić, aby każda zmiana dokonana przez
> każdego ze 100 członków zespołu była automatycznie dystrybuowana do
> wszystkich pozostałych (żadne commity, push/pull itd. tylko klikasz "save"

Dlaczego niby "każda zmiana dokonana przez każdego ze 100 członków zespołu
była automatycznie dystrybuowana do wszystkich pozostałych"? Skoro
"programiści to banki" to po cholerę bank X ma znać historię operacji
wszystkich pozostałych banków?

> w edytorze i wszyscy mają automatycznie widzieć zmianę), po pierwsze
> wszyscy muszą być praktycznie cały czas podłączeni do repo, a po drugie
> robiąc to na zasadzie "wpiszę do crontaba aby co minutę robił się
> automatycznie commit oraz push i pull" będzie wymagać znacznie większej
> wydajności serwera z repo. A to i tak w zasadzie "banalny" problem, bo w
> przypadku Git-a każdy ma u siebie praktycznie to samo (pełną kopię repo za
> wyjątkiem ostatnich zmian) więc większość rzeczy Git może zrobić po stronie
> klienta a na serwer wysyła tylko gotowe, już "przeliczone" dane, natomiast
> w przypadku systemów bankowych tak nie jest, każdy bank ma tylko dane
> dotyczące swoich kont i nie może sam przeprowadzić pełnego rozliczenia.
>
> Różnica w zapotrzebowaniu na moc obliczeniową jest spora.

W nietrafionej analogii...tak.

Teraz wyobraź sobie sytuacje rzeczywistą, że jest 100 banków i KIR. Każdy z
banków ma swój serwer REST oraz KIR ma swój serwer REST z bazą operacji
wszystkich banków. W banku numer 45 klient wykonuje przelew do banku 56.
Klika "Wykonaj". Serwer banku 45 wysyła requesta do serwera KIR i mówi mu:
"bank 45 rachunek AAA przelew do banku 56 rachunek BBB, kwota X". Serwer
KIRu zapisuje to do bazy prostym INSERTEM i wykonuje requesta do serwera
banku 56 o takiej samej treści jaką przed chwilą otrzymał. Bank 56 zapisuje
to do bazy i wykonuje requesta do serwera KIR: "OK, potwierdzam zapis".
Serwer KIR zapisuje w bazie, w rekordzie, który poprzednio zainsertował
status: "Potwierdzono" i wysyła requesta do serwera banku 45: "Wykonano".
Bank 45 zapisuje do bazy przy wykonanym przelewie: "Potwierdzono'. Koniec.
Liczby:
- cztery lekkie requesty RESTowe
- 3 inserty i 3 updaty w SQLu

To oczywiście pewne uproszczenie, ale tak to może działać.

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