Dnia 30.07.2015 szemrany <s...@o...off> napisał/a:
> 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.

Nie odwracaj kota ogonem. Napisałeś wcześniej (tylko wyciąłeś w tym poście):

|No i będą oferować za darmo, tak jak już oferują rozmowy telefoniczne, gdy
|kiedyś chcieli 2 czy 3 zł za każdą rozpoczętą minutę. Jeszcze chwila.

Pisałeś o *oferowaniu* połączeń za darmo a nie o tym, że koszt utrzymania
BTS-a jest praktycznie stały (niezależnie od tego czy ktoś dzwoni czy nie).
No ale trzymając się Twojej "nowszej wersji": w praktyce nie jest tak jak
piszesz, jeśli z danego BTS-a korzysta ktoś powiedzmy raz dziennie, to
można go pozostawić z kartą obsługującą 4 kanały i mieć święty spokój, ale
jak taki BTS stoi w centrum handlowym, to musi "uciągnąć" co najmniej
kilkadziesiąt równoległych połączeń, więc tych kart z transceiverami trzeba
mu nieco włożyć (albo zastosować znacznie droższy szerokopasmowy SDR/DDS).
Duży ruch *zwiększa* koszt systemu, bo trzeba zapewnić warunki aby go
obsłużyć, a jak tego ruchu w danej chwili nie ma to koszt nie spada - ok,
nie spada, ale to nie to samo, co "koszt jest niezależny od generowanego
ruchu" (bo jest zależny od przepustowości jaką zapewniasz a nie od tego czy
ktoś w danej chwili z tego korzysta czy nie).
Na darmowe połączenia nie masz co liczyć, bo infrastruktura kosztuje nawet
jak nikt nie dzwoni, więc operatorzy muszą zgarnąć kasę na jej utrzymanie
(a że mogą nie rozliczać za minuty, tylko brać stałą kasę za samą
możliwość zadzwonienia to zupełnie inna sprawa, to nie jest "oferowanie
rozmów telefonicznych za darmo").

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

Nie ważne, tak czy siak nie jest "za darmo" bo utrzymanie infrastruktury
kosztuje i w dodatku zapewnienie powiedzmy 10 równoczesnych rozmów z danego
BTS-a jest tańsze niż zapewnienie 100 równoczesnych rozmów. Mówimy o
normalnym GSM, bo w UMTS sprawa jest nieco inna, tam jest stosowany
mechanizm rozpraszania widma i stałej przepustowości, która jest "dzielona"
na poszczególnych użytkowników, czym więcej użytkowników BTS-a, tym każdemu
przypada mniejszy transfer a więc i mniejszy bitrate kodeka mowy itd., no
ale zgoda, w UMTS jest duży "zapas pasma" na rozmowy jeśli akurat nikt nie
"zarzyna" pasma dostępem do internetu, jeszcze szersze jest LTE, ale za to
ma tak tragicznie mały zasięg, że o pokryciu obszarów z małą gęstością
zaludnienia nie ma co marzyć (potrzebne byłyby gęsto umieszczone BTS-y, a
te są drogie i stawianie BTS-a aby korzystało z niego tylko kilku
użytkowników jest nieopłacalne, z drugiej strony nikt nie będzie chodził z
antenami kierunkowymi aby móc zadzwonić gdy znajduje się 5km od
najbliższego BTS-a :D)

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

Nadal to nie jest za darmo, a że nie Ty za to płacisz, tylko inni (na
przykład użytkownicy premium, albo muzycy chcący się wypromować czy
reklamodawcy) to tylko pozór "darmowości". Wyszukiwarka Google też jest "za
darmo"... dla Ciebie i dla mnie, ale ktoś za jej istnienie płaci i za ten
milion serwerów, które dają potencjalną możliwość obsłużenia milionów
zapytań jednocześnie, a jak się wszyscy na świecie umówią i zrobią "dzień
bez Google", to zgoda, róznica będzie tylko w mniejszym zużyciu prądu.

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

Już kilkanaście lat temu byłem jednym z testerów pomysłu operatora (jeszcze
wtedy Ery), że jak nie chcesz płacić za połączenie, to możesz dodać
specjalny kod przed numerem docelowym korespondenta i wtedy po zestawieniu
połączenia była 15 sekundowa reklama i potem 15-sekundowa reklama co trzy
minuty. Owszem dla mnie połączenie było "za darmo", bo płacił reklamodawca.
A że koszt minuty połączenia zarówno wtedy jak i teraz nie był kwotą o jaką
*wzrasta* koszt działania sieci przy danym połączeniu, tylko był ryczałtowo
przeliczony jako koszt stały utrzymania całej sieci + koszt zmienny
(znacznie mniejszy) zestawiania połączeń i podzielony przez średnią ilość
minut wydzwanianą przez wszystkich abonentów (no i oczywiście marzę sobie
doliczyli :D) - owszem, tak jest.

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

Przecież napisałem, o różnicach - nie ogarniasz więceju niż jednego zdania
na raz?

>> Różnica w zapotrzebowaniu na moc obliczeniową jest spora.
>
> W nietrafionej analogii...tak.

W trafionej, tylko jej nie rozumiesz.

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

Cytując Ciebie "w nietrafionym uproszczeniu... tak". Myślisz, że w takich
systemach najbardziej czasochłonne są inserty do bazy? Same cyfrowe podpisy
do tych requestów oraz ich weryfikowanie zajmuje znacznie więcej niż insert
do bazy, no ale pewnie i tak wiesz lepiej...
Czy się nie da? Oczywiście że się da, w końcu Elixirem biega około 2
miliardy transakcji rocznie, czyli nic nadzwyczajnego, niecałe 7 milionów
transakcji dziennie uwzględniając tylko dni robocze, gdyby chodziło o samo
"insert into" to byłby to detal.

Skoro się nabijasz, że w NBP (obsługującym SORBNET2) mają Odry, S/360 czy
Bosman-8, to nie, w zeszłym roku mieli sprzęt klasy Delle PowerEdge R510 i
R710 oraz IBM-y x3650 i x3950 i w samym zeszłym roku dokupili co najmniej
31 serwerów (po dwa procki 8-10 rdzeniowe każdy) - wiem, bo kumpel handluje
sprzętem i startował w przetargu zarówno na nowe serwery jak i na
serwisowanie już istniejących. Owszem, SPARC T5 (8 wątków na rdzeń co daje
128 wątków na procesor) to to nie jest, ale "insert into" na mySQL-u
powinno uciągnąć, tylko byś musiał kilka godzin w weekend poświęcić i soft
napisać (to przecież banalne, trzy requesty na krzyż i gotowe, skrypt w
perlu czy pythonie trzaśniesz i będzie :D).

Z mojej strony EOT. Uznajmy że Ty masz rację (a ja święty spokój) i
odwołuję wszystkie argumenty jakich użyłem w tym wątku.