On Wednesday, July 29, 2015 at 4:56:31 PM UTC+2, Pit wrote:
> Google nie musi dawać wyników bezbłędnych, i nie mam tu na myśli tego, że
> wyświetla "znalazłem 1000 wyników"
Tak na marginesie, jeszcze nigdy nie widziałem, aby google znalazło
więcej niż 1000 wyników. Oczywiscie wyświetla że znalazło setki milionów,
ale chodzi mi o ilość jaką można zobaczyć w wynikach. Nie umiem obsługiwać
googla, czy co?

do góry

Dnia 29.07.2015 M.M. <m...@g...com> napisał/a:
> Wszystkie etapy które Ty przytoczyłeś, można rozwiązać tak jak ja
> zaproponowałem. Na każdym etapie zadania można wrzucać do kolejki.
> Na każdym etapie jakiś demon może kolejne zadania z kolejki wyciągać.
> Na każdym etapie można system zapytać, czy jest już gotowa odpowiedź.
> Oczywiście takie rozwiązanie nie zadziała live. Ktoś wyśle dokument i
> będzie musiał kilka razy zapytać serwer czy jest odpowiedź. Może
> otrzymać odpowiedź, że przed jego zadaniem stoi w kolejce 300 innych
> zadań, więc pójdzie na kawę. Lepsze takie rozwiązanie, niż całkowity
> pad serwera, no chyba że ten pad nazywasz systemem live ;-)

Oczywiście zgadzam się, że dało się to zrobić lepiej, no i ostatecznym
sędzią jest rzeczywistość - system nie był dobrze zrobiony bo nie spełnił
zadania i trzeba było wrócić do liczenia "na piechotę". Niemniej jednak
uważam, że o ile jest to w miarę proste zadanie, to nie jest to zadanie
trywialne i jest kupa "haczyków" na których projekt może się wyłożyć (mimo,
że będzie działał prawidłowo podczas testów w małej skali). Moim zdaniem
podstawowym błędem był niedoczas - trzy miesiące na znalezienie zespołu (tu
był ponoć jednoosobowy - ile w tym prawdy, nie wiem), analizę zagadnienia,
zaprojektowanie, napisanie, przetestowanie, oddanie wersji testowej
klientowi, naniesienie poprawek, testowanie, wdrożenie, przeszkolenie ludzi
itd. to na prawdę nie jest dużo czasu (zwłaszcza dla mniej doświadczonego
zespołu).

>> wystarczyłby system
>> podobny do e-maili (gdzie serwer sobie ustawia kolejeczkę i w swoim tempie
>> wszystko przetwarza). To nie jest tak, że jak teraz wcisnę "SEND" to mogę
>> czekać godzinkę aż serwer przemieli,
> No ale zdaje się, że czekali dłużej niż godzinę i w końcu jakoś dali radę.
> Gdyby jeden demon odbierał i kolejkował, drugi wykonywał obliczenia, trzeci
> odpowiadał, to przynajmniej by nie doszło do rozwalenia danych i przynajmniej
> swoje dane by się udało wysłać. Jeśli jakiś algorytm obliczający się nie
> wyrabia, to w każde rozwiązanie będzie się muliło. Więc chociaż niech
> transfery przebiegają sprawnie.

Też jestem zdania, że można to było lepiej. Poza tym ponoć okazało się, że
w systemie była kupa wszelakiej maści dziur i niedociągnięć. Po prostu ktoś
do tego źle podszedł (albo nie umiał, albo zbagatelizował sprawę). Takie
coś jak wybory samorządowe, to bez problemu nawet mySQL by uciągnął bo w
przypadku wyborów "transakcyjność" jest zapewniana przez obieg dokumentów,
no a kolejkowanie tasków to ma chyba każdy współczesny serwer aplikacji
więc pomysł o którym piszesz jest do zrealizowania praktycznie "za darmo"
(i przy okazji unikamy zarzynania macierzy dysków wielodostępem, zresztą
dla takiej ilości danych jak wybory, to można zbudować macierz z ramdysku i
dysków fizycznych - odczyt danych "natychmiastowy").

>> bo taką ma kolejkę, wynik powinien być
>> zwrcony w rozsądnym czasie (maksymalnie kilka sekund). No i tych zapytań do
>> bazy jest znacznie więcej niż jednorazowe INSERT INTO a i obwodów jest
>> więcej niż ktoś tam wyżej podał.
> Ja też uważam że lepiej w ciągu kilku sekund niż w ciągu godziny. Ale
> zapewne i Ty się zgodzisz ze mną, że lepiej w ciągu godziny niż w ciągu 20 godzin
> plus pad serwera w punkcie krytycznym dla spójności danych.

No oczywiście lepiej w ciągu godziny niż wcale :D

do góry

On 2015-07-29 04:15, Pit wrote:
> Elixir powstał w czasach, kiedy internetów (zwłaszcza domowych) nie było,

Kernel NT też. Jakim cudem to teraz działa?

> był przystosowany do komunikacji protokołem X.25 (zwykłe modemy
> telefoniczne i połączenie dial-up a nie stałe łącze)

> A czemu system SORBNET ma kosztować? Bo jest znacznie kosztowniejszy w
> utrzymaniu

Komputery załozyły związki zawodowe?

> i ma znacznie większe wymagania od systemów

PayPale, BlueCashe wyrosly na "byle jakim hardware". Google, które
przetwarza o wiele więcej do dzisiaj stoi na chińskim gównie i "byle
czym, byle tanio". Oczywiście - ktoś może powiedzieć że systemy bankowe
powinny być pewne, ale to tylko bełkotanie prawniczo-ekonomiczne,
ostatni przyklad Plusbanku pokazuje że gówniani programiści i managerzy
znajdują się w każdej grupie zarobkowej w każdej dziedzinie.

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

Rozmawiamy o Odrach, pamiętasz? Rozmawiamy o 30 latach. Po tym czasie
sprzet elektroniczy ulega *degradacji* od lutów po krzem, szczegolnie że
budowano je w warunkach bezdewizowych.

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

Winda się nie zmienia. Przelewy bankowe się zmieniają. Od 10 lat co
najmniej jest potrzeba przelewów minutowych i darmowych aby pobudzić
rynek handlu bez pośredników. Ponieważ bankowe przygłupy na stanowiskach
managerów nie mają o tym pojęcia to lukę wypełniły firmy prywatne.

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

Czasy pisania ważnego dla bezpieczeństwa państwa softu w garażu mineły i
nikt tutaj nie mowi o systemie bez dokumentacji. Argument z dupy. Jesli
duperele bazodanową wielkie korpo chcą zrobić za 100mln to gwarantuje że
kilku łebskich kolesi z doświadczeniem zrobi to za 10mln 100x lepiej.
Tyle tylko że nie zrobią przekrętu i nie wejdą nad progiem.

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

Amica ma Arma (7-kę).

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

Nie, ponieważ w przypadku pralek o których tu mowa nikt nie chce pralki
projektowanej 20 lat temu. Tzn chce rownie solidnej, ale producent jej
nie wyprodukuje. Istnieje naprawdę niewiele produktów na rynku
konsumenckim ktore bez zmiany formy produkuje się przez lata.

> Na pewno do tego "zasobnego" wyjdzie drożej

Bzdura. 8051 to zamkniety świat, brak kompilatorów, brak języków innych
niż asm/c, archaiczna architektura podatna na błędy, sztuczki kruczki.

Przecięty arm7 nie rózni się niczym od czegokolwiek co znasz.

, bo do tego Linuxa trzeba

Nie trzeba. Było by miło mieć coś innego niż procesor nieuzasadnionych
kompromisów i w dodatku droższy.

> napisać drivery do kernela na konkretnego ARM-a, zbudować na tego ARM-a
> minidystrybucję (aby ten "developer" mógł korzystać z "bogatych
> bibliotek")

Bzdura. Nikt nie pakuje linuxa do pralki poza desperatami.

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

Ja. Przy czym co z tego? Linux to nie jest sustem do pralek. Choćby z
powodu potrzeby jakiegoś tam RT którego każdy duży OS nie zapewnia od ręki.

PS. Tak wiem że pewna firma z Gliwic ma osiągnięcia w konstrukcji
najszybszego 8051 na świecie. Przyznam że jak uzłyszałem to o mało sie
nie zaksztusiłem. Najszybszy rower ja świecie...

do góry

Użytkownik Tomasz Kaczanowski kaczus@dowyciecia_poczta.onet.pl ...

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

Rozumiem ze zgadzamy sie - problem nie jest w jakis wielkich wymaganiach, w
ogromnych potrzebach sprzetowych etc tylko w tym, ze prosta rzecz zle
napisano?

do góry

Użytkownik M.M. m...@g...com ...

>> >> 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)
>>
>> Tylko skoryguję, około 3tys. to było okręgów wyborczych, a obwodów
>> wyborczych (lokali wyborczych w których są komisje obwodowe) było
>> ponad 20 tysięcy.
>
> To stanowi 'lekką' różnicę. 20tys * 1s to już jest trochę więcej niż
> godzina. Obsłużenie w ciągu 0.1s nie zawsze jest możliwe, ale na 10
> komputerach powinno śmigać.

Ale co wy z tą jedna godziną?
Cały dzien sie nie mogli połączyc.
Czyli było 24 godziny gdzie nie działało...

do góry

Dnia 29.07.2015 Sebastian Biały <h...@p...onet.pl> napisał/a:
> On 2015-07-29 04:15, Pit wrote:
>> Elixir powstał w czasach, kiedy internetów (zwłaszcza domowych) nie było,
>
> Kernel NT też. Jakim cudem to teraz działa?

Takim, że to co teraz nazywa się "Kernel NT" ma z pierwotnym kernelem NT
tyle wspólnego, co demokracja socjalistyczna z demokracją - nazwę (i w
przypadku KernelaNT także nazwy funkcji w API).

>> był przystosowany do komunikacji protokołem X.25 (zwykłe modemy
>> telefoniczne i połączenie dial-up a nie stałe łącze)
>
>> A czemu system SORBNET ma kosztować? Bo jest znacznie kosztowniejszy w
>> utrzymaniu
>
> Komputery załozyły związki zawodowe?

Nie, potrzeba ich więcej.

>> i ma znacznie większe wymagania od systemów
>
> PayPale, BlueCashe wyrosly na "byle jakim hardware". Google, które
> przetwarza o wiele więcej do dzisiaj stoi na chińskim gównie i "byle
> czym, byle tanio". Oczywiście - ktoś może powiedzieć że systemy bankowe
> powinny być pewne, ale to tylko bełkotanie prawniczo-ekonomiczne,
> ostatni przyklad Plusbanku pokazuje że gówniani programiści i managerzy
> znajdują się w każdej grupie zarobkowej w każdej dziedzinie.

PayPale czy BlueCashe nie zajmują się transferami pieniędzy a jedynie
transferami zleceń na transfery, a to zupełnie coś innego (bez
infrastruktyry banków te serwisy by nie istniały).

Co do Google i "chińskiego gówna" - w jakim celu wykładają setki milionów
dolców na własne nowoczesne elektrownie ze źródeł odnawialnych? Nie byłoby
taniej kupić "chińskie gówno"? No i Google może bazować na heurystykach
(jak Ci jakieś wyszukiwanie nie zwróci tego co chcesz, to możesz poprawić
kryteria, jak zwróci coś za dużo, to po prostu nie klikniesz w link lub
zawęzisz kryteria, jak gdzieś jakiś e-mail nie dojdzie albo wpadnie w SPAM
to też tragedii nie ma), bank nie może sobie pozwolić na "zaginięcie
przelewu" i odpowiedź "ma Pan mniej więcej X PLN na koncie".

>> 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?
>
> Rozmawiamy o Odrach, pamiętasz? Rozmawiamy o 30 latach. Po tym czasie
> sprzet elektroniczy ulega *degradacji* od lutów po krzem, szczegolnie że
> budowano je w warunkach bezdewizowych.

Część ulega degradacji a część nie ulega, wszystko jest kwestią warunków
pracy i jakości wykonania. Dopóki działa niech działa, jak przestanie
działać, to się wymieni w kilka godzin na nowszy sprzęt - nie wiem gdzie w
tym widzisz problem.

>> 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.
>
> Winda się nie zmienia. Przelewy bankowe się zmieniają. Od 10 lat co
> najmniej jest potrzeba przelewów minutowych i darmowych aby pobudzić
> rynek handlu bez pośredników. Ponieważ bankowe przygłupy na stanowiskach
> managerów nie mają o tym pojęcia to lukę wypełniły firmy prywatne.

Sam jesteś chyba przygłupem, bo nie masz pojęcia o czym piszesz. Systemy
RTGS (rozliczenia "live" między bankami, gdzie przelew idzie maksymalnie w
kilka minut) funkcjonują w Polsce od 15-stu lat (dostępne dla klientów
banków, bo dla samych banków to zostały wdrożone nieco wcześniej). Niestety
spięcie SORBNETU z systemem TARGET2 (międzynarodowe przelewy "live" w euro)
spowodowało problemy wydajnościowe SORBNETU, więc NBP zwiększył prowizję od
transakcji SORBNETU jednocześnie zmneijszając ją od transakcji Elixirowych
aby "rozładować" (aby klienci wybierali SORBNET tylko gdy jest to
konieczne), było to w okolicach 2011 roku. W 2013 roku stary SORBNET został
zastąpiony systemem SORBNET2, który "rozładował" ruch. Dla Twojej
wiadomości, to obecnie większość przelewów Elixir jest "tunelowanych"
wewnątrz SORBNET2 (tylko Elixiry nie lecą "live" w momencie gdy je
wyklikasz na stronie banku, ale są wysyłane w paczkach 2-3 razy dziennie,
bo tak jest dla banku ZNACZNIE taniej). Niestety ale w Polsce mamy takie
prawo, że jak ja wysyłam kasę z banku X na Twoje konto w banku Y, to bank X
nie może bezpośrednio przekazać kasy bankowi Y, tylko musi to zrobić za
pośrednictwem odpowiednich instytucji (Krajowej Izby Rozliczeniowej lub
NBP), bo wszelkie dane o wpływach/wypływach kasy z banków i ogólny stan
"rachunku banku" musi być na bieżąco dostępny dla Komisji Nadzoru
Finansowego.

>> 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ć?
>
> Czasy pisania ważnego dla bezpieczeństwa państwa softu w garażu mineły i
> nikt tutaj nie mowi o systemie bez dokumentacji. Argument z dupy.

Patrz system obsługujący wybory samorządowe w 2014 roku :D

> Jesli
> duperele bazodanową wielkie korpo chcą zrobić za 100mln to gwarantuje że
> kilku łebskich kolesi z doświadczeniem zrobi to za 10mln 100x lepiej.
> Tyle tylko że nie zrobią przekrętu i nie wejdą nad progiem.

Jest duża różnica między stworzeniem systemu a utrzymaniem go przez lata.

>>>> 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.
>
> Amica ma Arma (7-kę).

Moja ma MC9S08AC32 (8-bitowy FreeScale), choć kupiona jakieś 5-lat temu.

>>>> 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.
>
> Nie, ponieważ w przypadku pralek o których tu mowa nikt nie chce pralki
> projektowanej 20 lat temu. Tzn chce rownie solidnej, ale producent jej
> nie wyprodukuje. Istnieje naprawdę niewiele produktów na rynku
> konsumenckim ktore bez zmiany formy produkuje się przez lata.

Toteż ja nie mówię o tym, żeby teraz Odry produkować, ale jaki jest sens
wymieniać coś, co działa, na coś, co działa tak samo?

>> Na pewno do tego "zasobnego" wyjdzie drożej
>
> Bzdura. 8051 to zamkniety świat, brak kompilatorów, brak języków innych
> niż asm/c, archaiczna architektura podatna na błędy, sztuczki kruczki.

A kto powiedział, że na 8051? Pisałeś o 8-bitowym procesorze a nie
konkretnie o 8051. Gwarantuję, że znajdziesz więcej (i taniej) programistów
na 8-bitowe AVR-y niż na 32-bitowe ARM-y. Poza tym na 8051 nie brakuje ani
kompilatorów ani języków programowania, chociażby GCC wspiera 8051, więc
masz C, C++, Fortran we wszystkich edycjach oraz Adę. Dla "lamerów" jest
bardzo dobry BASIC BasComu. Czego trzeba więcej na małe systemy? Przecież
tam kod to maksymalnie kilka czy kilkanaście tysięcy linijek, bo więcej do
ROM/EPROM/FLASH nie wejdzie.

Co do podatności na błędy, "sztuczki kruczki" itp. - nie znam dokłądnie
architektury 8051, bo nigdy nic poważniejszego niż "miganie diodą" na tym
nie pisałem, ale inne architektury 8-bitowe takie jak PIC firmy Microchips
czy AVR firmy Atmel są bardzo tanie, proste i wydajne. W prostych
zastosowaniach ARM-y jak na razie nie mają z nimi jakichkolwiek szans (ze
względu na pobór zasilania, rozmiary, prostotę architektury, prostotę
aplikacji i cenę).

>
> Przecięty arm7 nie rózni się niczym od czegokolwiek co znasz.
>

Po pierwsze skąd możesz wiedzieć co znam? :D Po drugie różni się i to
bardzo od najbardziej znanej przez większość programistów architektury (mam
na myśli Intel i rodzinę x86). Tak się składa, że programowałem dużo
RISC-ów (zarówno tych w architekturze Harwardzkiej jak i von Neumana) i jak
najbardziej wolę programować ARM niż 8051, no ale świat małych
mikrokontrolerów to nie tylko (a nawet nie przede wszystkim!) 8051, więc
nie wiem czemu się akurat tego modelu uczepiłeś? To jest trochę tak, jakbyś
chcąc "udupić" stare auta widział tylko Trabanty i Syrenki, a nie widział
Pontiaców czy Lincolnów.

> , bo do tego Linuxa trzeba
>
> Nie trzeba. Było by miło mieć coś innego niż procesor nieuzasadnionych
> kompromisów i w dodatku droższy.

Drogi? Skoro się uparłeś na tego 8051 (tak jakby innych mikrokontrolerów
nie było :D), to taki w sam raz do pralki (24MHz to stanowczo za dużo, ale
nie znalazłem wolniejszego :D) w wykonaniu Atmela kosztuje 2,5PLN i nie
potrzebuje do swojego działania dosłownie nic (nawet kwarcu zegarowego), po
prostu podłączasz zasilanie, przekaźniki, czujniki i używasz. A cenę
podałem dla detalicznego odbiorcy już z uwzględnieniem marż sklepów itd.,
branie bezpośrednio od producenta to "grosze". Jeśli jako producent
zamierzam sprzedać powiedzmy 10 tysięcy pralek z danym modułem sterującym
(będą różne modele, ale firmware praktycznie to samo), to różnica pomiędzy
ARM-em za 2,5$ a AVR-em za 0,5$ daje 20 tysięcy dolców, do tego dojdzie
koszt reszty układu aplikacyjnego (którego AVR praktycznie nie wymaga) i...
zakładając że przedsiębiorca chce się podzielić pół na pół z programistami,
dostaje raptem kilkanaście tysięcy dolarów ekstra na stworzenie firmware -
programista 8-bitowych tanich i prostych procesorów zarobi w tym przypadku
więcej niż programista ARM-ów. No i nie można mówić o jakichkolwiek
kompromisach, procek ma wszystko co trzeba (a że się nie da napisać skryptu
w bash-u czy Pythonie, tylko trzeba w C napisać - no cóż, dla mnie to nie
wada, wręcz odwrotnie, jestem niezależny od błędów interpretera więc mogę
zagwarantować większą niezawodność).

>> napisać drivery do kernela na konkretnego ARM-a, zbudować na tego ARM-a
>> minidystrybucję (aby ten "developer" mógł korzystać z "bogatych
>> bibliotek")
>
> Bzdura. Nikt nie pakuje linuxa do pralki poza desperatami.
>

Byś się zdziwił gdzie jakie technologie siedzą :D Wiesz na przykład, że w
karcie SIM (takiej z telefonii komórkowej) jest nie tylko pamięć ale i
mikroprocesor na którym chodzi wirtualna maszyna Javy i kupa appletów, a to
co widzi czytnik to wynik działania "emulatora karty SIM" (nie ma
bezpośredniego dostepu do zawartości pamięci karty)?
Systemy operacyjne są teraz pakowane w wielu miejscach, bo są bardzo tanie
(koszt gotowego procesora wraz z RAM, pamięcią FLASH itd. na której chodzi
OS pokroju Linuxa to teraz koszt rzędu jednego dolara - to nic w porównaniu
z kosztem pralki).

>> 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).
>
> Ja. Przy czym co z tego? Linux to nie jest sustem do pralek. Choćby z
> powodu potrzeby jakiegoś tam RT którego każdy duży OS nie zapewnia od ręki.

W pralce nie musi być RT, bo czas reakcji na bodziec nie musi być rzędu
kilku cykli zegarowych. To że grzałka się wyłączy sekundę później niż
przyjdzie info z czujnika temperatury wody, to jest detal.

> PS. Tak wiem że pewna firma z Gliwic ma osiągnięcia w konstrukcji
> najszybszego 8051 na świecie. Przyznam że jak uzłyszałem to o mało sie
> nie zaksztusiłem. Najszybszy rower ja świecie...

Przecież w automatyce przemysłowej BARDZO RZADKO chodzi o szybkość
obliczeń, bo i tak nawet najprostsze komputery są tysiące razy szybsze od
możliwości mechanicznych urządzeń którymi sterują. Poza tym nie wiem czemu
się uczepiłeś tego 8051, czy to jedyny 8-bitowy system jaki znasz?

do góry

Dnia 29.07.2015 Budzik <b...@p...o.n.e.t.pl.nie.spam.oj> napisał/a:
> Użytkownik M.M. m...@g...com ...
>
>>> >> 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)
>>>
>>> Tylko skoryguję, około 3tys. to było okręgów wyborczych, a obwodów
>>> wyborczych (lokali wyborczych w których są komisje obwodowe) było
>>> ponad 20 tysięcy.
>>
>> To stanowi 'lekką' różnicę. 20tys * 1s to już jest trochę więcej niż
>> godzina. Obsłużenie w ciągu 0.1s nie zawsze jest możliwe, ale na 10
>> komputerach powinno śmigać.
>
> Ale co wy z tą jedna godziną?
> Cały dzien sie nie mogli połączyc.
> Czyli było 24 godziny gdzie nie działało...

No ale przez te 24 godziny to nie było tak, że ktoś spróbował raz, nie
wyszło i odpuścił na 24 godziny, tylko większość próbowała cały czas (i
wielokrotnie) "dobić się" do systemu zwiększając tylko jego obciążenie
(zmniejszając tym samym szansę na to, że wszystko pójdzie gładko). System
nie miał kolejkowania a kilkuset sesji równolegle nie był w stanie
uciągnąć i poległ.

do góry

Użytkownik Pit n...@s...lonestar.org ...

>>>> >> 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)
>>>>
>>>> Tylko skoryguję, około 3tys. to było okręgów wyborczych, a obwodów
>>>> wyborczych (lokali wyborczych w których są komisje obwodowe) było
>>>> ponad 20 tysięcy.
>>>
>>> To stanowi 'lekką' różnicę. 20tys * 1s to już jest trochę więcej niż
>>> godzina. Obsłużenie w ciągu 0.1s nie zawsze jest możliwe, ale na 10
>>> komputerach powinno śmigać.
>>
>> Ale co wy z tą jedna godziną?
>> Cały dzien sie nie mogli połączyc.
>> Czyli było 24 godziny gdzie nie działało...
>
> No ale przez te 24 godziny to nie było tak, że ktoś spróbował raz, nie
> wyszło i odpuścił na 24 godziny, tylko większość próbowała cały czas (i
> wielokrotnie) "dobić się" do systemu zwiększając tylko jego obciążenie
> (zmniejszając tym samym szansę na to, że wszystko pójdzie gładko). System
> nie miał kolejkowania a kilkuset sesji równolegle nie był w stanie
> uciągnąć i poległ.

Ale ja nie pisze jak było tylko ze wymagania nie były jakies wielkie i nie
był potrzebny jakis mega hiper system.
Potrzebny był za to w miare prosty system, ale dobrze napisany.

do góry

On 2015-07-29 19:50, Pit wrote:
> Dnia 29.07.2015 Sebastian Biały <h...@p...onet.pl> napisał/a:
>> On 2015-07-29 04:15, Pit wrote:
>>> Elixir powstał w czasach, kiedy internetów (zwłaszcza domowych) nie było,
>> Kernel NT też. Jakim cudem to teraz działa?
> Takim, że to co teraz nazywa się "Kernel NT" ma z pierwotnym kernelem NT
> tyle wspólnego, co demokracja socjalistyczna z demokracją - nazwę (i w
> przypadku KernelaNT także nazwy funkcji w API).

Bo przeprowadzany był *CIĄGŁY* refaktoring. W przeciwieństwie do
debilizmów za 100mln.

>>> był przystosowany do komunikacji protokołem X.25 (zwykłe modemy
>>> telefoniczne i połączenie dial-up a nie stałe łącze)
>>> A czemu system SORBNET ma kosztować? Bo jest znacznie kosztowniejszy w
>>> utrzymaniu
>> Komputery załozyły związki zawodowe?
> Nie, potrzeba ich więcej.

Do przerobienia pi x dzwi kilku mln przelewów dziennie? Z tym się wyrobi
pierwszy lepszy komputer do oglądania redtube w ilosci kilkunastu sztuk.

> PayPale czy BlueCashe nie zajmują się transferami pieniędzy a jedynie
> transferami zleceń na transfery

A-ha, czyli Elixir zajmue się transferowaniem *pieniędzy*, czyli w
miejsce dyskietki 8" pracownik banku wkłada plik banknotow i one
wychodza w drugim banku, tak? Nie? To czym się różnią?

, a to zupełnie coś innego

Staram sie pojąć co jest innego w przekazaniu wirtualnych pieniędzy
metodą A od przekazania wirtualnych pieniędzy metodą B.

> Co do Google i "chińskiego gówna" - w jakim celu wykładają setki milionów
> dolców na własne nowoczesne elektrownie ze źródeł odnawialnych?

Fanaberie. Gdybyś miał miliardy do wydania to kupowanie setki Porsche
jakoś nie brzmi specjalnie ekscytująco.

> Nie byłoby
> taniej kupić "chińskie gówno"?

Kupowanie chińskiego gówna w milionach sztuk jest znacznie tańsze niż
kupowanie solidnych amerykańskich serwerowni wytrzymujących 25 lat i
zderzenie z samolotem a po 10 latach są do wyrzucenia z racji
wyprzedzenia ich mocy obliczeniowej przez smartforna. Ktoś to policzył.

> bank nie może sobie pozwolić na "zaginięcie
> przelewu" i odpowiedź "ma Pan mniej więcej X PLN na koncie".

Że co? Moja karta wyświetla czasem na terminalu "zła kwota". Pojechałem
do banku zapytac które są dobre, może te podzielne przez 17 albo może
plindromiczne. Odpowiedź dostałem "od teraz powinno dzialać". Wychodzę,
idę do Żabki, nie działa. Banki w szczególności mogą sobie pozwolić na
powiedzenie dowolnej bzdury bo stoi za nimi całe stado wściekłych
prawników jak zaczniesz podskakiwać. Mam gdzieś wyciąg z konta gdzie w
nocy dokonywano tajemniczych przelewow (zapewne na lokaty pracownikow).
Nikomu nie spadł włos z głowy "problem nie powinien się już pojawiać".
Banki od wielu lat nie mają nic wspólnego z profesjonalizmem ani
wiarygodnością. Bank może pozwolić sobie na wszystko "ciemni ludzie to
kupią".

>> Rozmawiamy o Odrach, pamiętasz? Rozmawiamy o 30 latach. Po tym czasie
>> sprzet elektroniczy ulega *degradacji* od lutów po krzem, szczegolnie że
>> budowano je w warunkach bezdewizowych.

> Część ulega degradacji a część nie ulega, wszystko jest kwestią warunków
> pracy i jakości wykonania. Dopóki działa niech działa, jak przestanie
> działać, to się wymieni w kilka godzin na nowszy sprzęt - nie wiem gdzie w
> tym widzisz problem.

W kilka godzin wymienić pamięć kawalek Odry na działający. To masz
wyobraźnię. Widzialeś ostatnio dostawcę częsci do Odry? Ludzie którzy
wiedzą *co* się popsuło lub mający wiedze jak to zdiagnozować sa już
tylko napisem na nagrobku.

>> Winda się nie zmienia. Przelewy bankowe się zmieniają. Od 10 lat co
>> najmniej jest potrzeba przelewów minutowych i darmowych aby pobudzić
>> rynek handlu bez pośredników. Ponieważ bankowe przygłupy na stanowiskach
>> managerów nie mają o tym pojęcia to lukę wypełniły firmy prywatne.

> Sam jesteś chyba przygłupem, bo nie masz pojęcia o czym piszesz. Systemy
> RTGS (rozliczenia "live" między bankami, gdzie przelew idzie maksymalnie w
> kilka minut) funkcjonują w Polsce od 15-stu lat (dostępne dla klientów
> banków, bo dla samych banków to zostały wdrożone nieco wcześniej).

Nie działają bo są płatne. Na tej samej zasadzie "działa" służba zdrowia
która w rzeczywistości *nie* dziala bo wielu osób nie stać na leczenie.

> Niestety
> spięcie SORBNETU z systemem TARGET2 (międzynarodowe przelewy "live" w euro)
> spowodowało problemy wydajnościowe SORBNETU

Odra czy może PDP-7? A nie, czekaj, może Bosman 8 ?

> , więc NBP zwiększył prowizję od
> transakcji SORBNETU jednocześnie zmneijszając ją od transakcji Elixirowych
> aby "rozładować" (aby klienci wybierali SORBNET tylko gdy jest to
> konieczne)

No i proszę, przygłup wymyslil rozwiązanie techniczne. I nagle Twoja
Odra z kolei miesci się w specyfikacji w 2012. Magia. Zupełnie jak w tym
dowcipie jak zmniejszyć liczbę otyłych amerykanów. Zwiększyć normę!

>, było to w okolicach 2011 roku. W 2013 roku stary SORBNET został
> zastąpiony systemem SORBNET2, który "rozładował" ruch. Dla Twojej
> wiadomości, to obecnie większość przelewów Elixir jest "tunelowanych"
> wewnątrz SORBNET2 (tylko Elixiry nie lecą "live" w momencie gdy je
> wyklikasz na stronie banku, ale są wysyłane w paczkach 2-3 razy dziennie,
> bo tak jest dla banku ZNACZNIE taniej).

W sensie że banki płacą za kurierów z dyskietkami że wysłanie 100MB
jednorazowo jest tańsze niż w kilkuset paczkach? A, to rozumiem. Że te
dyskietki. Bo inaczej nie mogę pojąc jak wysyłanie 100MB w dowolnej
konfiguracji może być w ogóle kosztowne.

> Niestety ale w Polsce mamy takie
> prawo, że jak ja wysyłam kasę z banku X na Twoje konto w banku Y, to bank X
> nie może bezpośrednio przekazać kasy bankowi Y, tylko musi to zrobić za
> pośrednictwem odpowiednich instytucji (Krajowej Izby Rozliczeniowej lub
> NBP)

Żadna z form od natychmiastowych przelewów tego nie robi. Dziwne. Gdzie
Macierewicz?

>, bo wszelkie dane o wpływach/wypływach kasy z banków i ogólny stan
> "rachunku banku" musi być na bieżąco dostępny dla Komisji Nadzoru
> Finansowego.

Mając natychmiastowe przelewy były nawet bardziej na bieżąco dostepny.

>> Czasy pisania ważnego dla bezpieczeństwa państwa softu w garażu mineły i
>> nikt tutaj nie mowi o systemie bez dokumentacji. Argument z dupy.
> Patrz system obsługujący wybory samorządowe w 2014 roku :D

System pisany przez ignorantów. Kryterium była cena. IMHO za tą kasę
dało by radę zrobić *coś* działającego.

> Jest duża różnica między stworzeniem systemu a utrzymaniem go przez lata.

Tak. Mniej więcej taka że utrzymując system krytyczny dla funkcjonowania
państwa w sposób ciągły masz szansę pozbierać się szybciej przy dużych
zmianach niż pisząc nastepny nowy.

>> Nie, ponieważ w przypadku pralek o których tu mowa nikt nie chce pralki
>> projektowanej 20 lat temu. Tzn chce rownie solidnej, ale producent jej
>> nie wyprodukuje. Istnieje naprawdę niewiele produktów na rynku
>> konsumenckim ktore bez zmiany formy produkuje się przez lata.
> Toteż ja nie mówię o tym, żeby teraz Odry produkować, ale jaki jest sens
> wymieniać coś, co działa, na coś, co działa tak samo?

Pralki mają:
a) więcej czujników (drgania, waga, jakość wody itd)
b) silniki zasilane falownikami
c) więcej funkcjonalności typu "program prania majtek w kolorze zielonym"

Napisanie tego na 8051 jest możliwe. Tylko że nie ma to sensu.
Ekonomicznego też. Obecnie Cortex M0 kupisz taniej niż wiele 8-bitowców.
Narzędzi dobrej jakości jest nieporównywalnie więcej. Na 8051 jest jeden
developer (z długą broda) na województwo i Keil udajacy C.

>> Bzdura. 8051 to zamkniety świat, brak kompilatorów, brak języków innych
>> niż asm/c, archaiczna architektura podatna na błędy, sztuczki kruczki.
> A kto powiedział, że na 8051? Pisałeś o 8-bitowym procesorze a nie
> konkretnie o 8051.

Pisalem prześmiewczo o 8051 bo to ten sam czas co Odra.

> Gwarantuję, że znajdziesz więcej (i taniej) programistów
> na 8-bitowe AVR-y niż na 32-bitowe ARM-y.

Nie, ponieważ *OBA* (avr, arm) mają kompilator gcc a to sprowadza
programistow obu do wspólnego mianownika. Czyli programista AVR
przechodzi na ARM prawie bezboleśnie.

> Poza tym na 8051 nie brakuje ani
> kompilatorów

Pokaż jeden działający, przetestowany i uzywany na produkcji C++.

> ani języków programowania

C i ASM. Nie ma innych bo nawet jesli są to musisz udaś się na
wykopaliska na cmentarz albo zatrunić tego jednego developera bedącego
jednoczesnie autorem tego cuda.

>, chociażby GCC wspiera 8051

Rozumiem że jesteś gotow ten nieoficjalny, popsuty port wsadzać od razu
na produkcję?

>, więc
> masz C, C++

Mam prawie C (Keil), nie mam C++.

>, Fortran

W tym nie piszą nawet zombie.

> we wszystkich edycjach oraz Adę.

W Adzie jest tylko moda pisac. Programistę mającego w ogole pojęcie o
Adzie najszybciej można znaleźć wśród elektroników (z powodu klonu VHDL)
ale oni znowu kumaci softwareowo nie są za bardzo. Ogolnie: nie ma
programistów Ady. Albo inaczej: nie za kasę którą płacą programistom
embedded do pralek.

> Czego trzeba więcej na małe systemy?

Działającego produkcyjnie kompilatora. Wypocinom prof-of-concept z sf
nie dam wiary. C++ dla AVR rodził się i rodzi nadal mimo upływu czasu.

> Co do podatności na błędy, "sztuczki kruczki" itp. - nie znam dokłądnie
> architektury 8051, bo nigdy nic poważniejszego niż "miganie diodą" na tym
> nie pisałem, ale inne architektury 8-bitowe takie jak PIC firmy Microchips
> czy AVR firmy Atmel są bardzo tanie, proste i wydajne. W prostych
> zastosowaniach ARM-y jak na razie nie mają z nimi jakichkolwiek szans (ze
> względu na pobór zasilania, rozmiary, prostotę architektury, prostotę
> aplikacji i cenę).

Cortex M0 kupisz w cenie AVRa, zazwyczaj ma znacznie więcej ram/rom,
peryferia lepszej jakości, platformę na którą istnieją sprawdzone
kompilatory. AVRy są podatne na zakłucenia elektrowhatever i produkowane
przez jedną firmę. ARM przez kilka. Oba znam na wylot.

>> Przecięty arm7 nie rózni się niczym od czegokolwiek co znasz.
> Po pierwsze skąd możesz wiedzieć co znam? :D Po drugie różni się i to
> bardzo od najbardziej znanej przez większość programistów architektury (mam
> na myśli Intel i rodzinę x86).

Nikt nie pisze w asm poza wstawkami, pisze się w C/C++. Ponadto
współczesny x86 to tylko podrasowany 8080 (no dobra, ale wszycy wiemy o
co chodzi) i całe szczęscie to badziewie nie występuje w embedded poza
szumem.

> Tak się składa, że programowałem dużo
> RISC-ów (zarówno tych w architekturze Harwardzkiej jak i von Neumana) i jak
> najbardziej wolę programować ARM niż 8051, no ale świat małych
> mikrokontrolerów to nie tylko (a nawet nie przede wszystkim!) 8051, więc
> nie wiem czemu się akurat tego modelu uczepiłeś?

Uczepiłem aby pokazać ci idiotyzm hasła "lepsze jest wrogiem dobrego"
ktore slyszę tutaj bardzo często choć nie wprost.

Problem w tym że to zazwyczaj tłumaczy się na normalny: "dobre jest
wrogiem gównianego" i to jest widoczne w wielu systemach o dużej skali.
Od Elixiru poczynając a na Cepiku kończąc a o Odrę sie potykając.

> To jest trochę tak, jakbyś
> chcąc "udupić" stare auta widział tylko Trabanty i Syrenki, a nie widział
> Pontiaców czy Lincolnów.

8051 to jeden z nagroszych procesorów dla programisty w historii, może
się z nim tylko równać rodzina x86 bo tą już się kopie w mule. Jest
popularny tylko dlatego że jest popularny. Wszystko jest w nim do dupy.
Od assemblera przez hardware po narzędzia.

>> Nie trzeba. Było by miło mieć coś innego niż procesor nieuzasadnionych
>> kompromisów i w dodatku droższy.

> Drogi? Skoro się uparłeś na tego 8051 (tak jakby innych mikrokontrolerów
> nie było :D), to taki w sam raz do pralki (24MHz to stanowczo za dużo, ale
> nie znalazłem wolniejszego :D) w wykonaniu Atmela kosztuje 2,5PLN

Nie będzie miał istotnych ficzerów co oznacza że zaoszczędzisz na kostce
ale wstawisz 3x więcej innych kostek. Pierwsza z brzegu potrzeba:
wbudowany driver lcd.

> i nie
> potrzebuje do swojego działania dosłownie nic (nawet kwarcu zegarowego)

90% mikrokontrolerów tak ma.

> to różnica pomiędzy
> ARM-em za 2,5$ a AVR-em za 0,5$ daje 20 tysięcy dolców

Zapominasz o róznicy w kosztach implementacji, płytek, dodatkowych
elementów dodających brakujące ficzery itd.

Dam ci przyklad: mam miernik mocy PECA w ktorym jakiś kretyn zrobil caly
interfejs usera na *DWÓCH* przyciskach. Znajomy, automatyk, bardzo sobie
chwali, bo co może być latwiejszego w użyciu niż 2 przyciski? To nic że
konfigurwanie trwa 2h, jest za to *łatwo*.

Taki własnie jest 8051. Jest łatwy pozornie.

> zakładając że przedsiębiorca chce się podzielić pół na pół z programistami,
> dostaje raptem kilkanaście tysięcy dolarów ekstra na stworzenie firmware -

Programista 8051 jest obecnie droższy niż avr. Znam to z procesu
rekrutacyjnego w firmie kolegi z zeszłego roku.

> Byś się zdziwił gdzie jakie technologie siedzą :D Wiesz na przykład, że w
> karcie SIM (takiej z telefonii komórkowej) jest nie tylko pamięć ale i
> mikroprocesor na którym chodzi wirtualna maszyna Javy i kupa appletów

Thank You Captain Obvious.

> Systemy operacyjne są teraz pakowane w wielu miejscach, bo są bardzo tanie
> (koszt gotowego procesora wraz z RAM, pamięcią FLASH itd. na której chodzi
> OS pokroju Linuxa to teraz koszt rzędu jednego dolara - to nic w porównaniu
> z kosztem pralki).

Linuxa nie pakuje się tam z powodu zagadnień RT, czasu startu jądra i
znacznego wzrostu kosztow (arm7 już nie wystarczy).

> W pralce nie musi być RT

Obecnie w pralkach sa falowniki a systemy analizy drgań bębna wymagają
kawałka dsp. Moja tego nie ma, ale kilka w zasięgu cenowym 3-4kzł już by
sie znalazło.

>, bo czas reakcji na bodziec nie musi być rzędu
> kilku cykli zegarowych.

Przeciętny OS z gatunku tych do oglądania porno nie zapewnia nawet setek
tysięcy.

>> PS. Tak wiem że pewna firma z Gliwic ma osiągnięcia w konstrukcji
>> najszybszego 8051 na świecie. Przyznam że jak uzłyszałem to o mało sie
>> nie zaksztusiłem. Najszybszy rower ja świecie...

> Przecież w automatyce przemysłowej BARDZO RZADKO chodzi o szybkość
> obliczeń

Zapewne dlatego zrobili *najszybszy* rower na świecie.

> Poza tym nie wiem czemu
> się uczepiłeś tego 8051, czy to jedyny 8-bitowy system jaki znasz?

Znam ich od groma i *DLATEGO* się go uczepilem bo przypomina tą Twoja
kolejową Odrę. Analogia wręcz idealna zarówno pod względem czasu,
możliwości jak i dostępu do doświadczonych programistów.

do góry

Dnia 29.07.2015 Budzik <b...@p...o.n.e.t.pl.nie.spam.oj> napisał/a:
> Użytkownik Pit n...@s...lonestar.org ...
>
>>>>> >> 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)
>>>>>
>>>>> Tylko skoryguję, około 3tys. to było okręgów wyborczych, a obwodów
>>>>> wyborczych (lokali wyborczych w których są komisje obwodowe) było
>>>>> ponad 20 tysięcy.
>>>>
>>>> To stanowi 'lekką' różnicę. 20tys * 1s to już jest trochę więcej niż
>>>> godzina. Obsłużenie w ciągu 0.1s nie zawsze jest możliwe, ale na 10
>>>> komputerach powinno śmigać.
>>>
>>> Ale co wy z tą jedna godziną?
>>> Cały dzien sie nie mogli połączyc.
>>> Czyli było 24 godziny gdzie nie działało...
>>
>> No ale przez te 24 godziny to nie było tak, że ktoś spróbował raz, nie
>> wyszło i odpuścił na 24 godziny, tylko większość próbowała cały czas (i
>> wielokrotnie) "dobić się" do systemu zwiększając tylko jego obciążenie
>> (zmniejszając tym samym szansę na to, że wszystko pójdzie gładko). System
>> nie miał kolejkowania a kilkuset sesji równolegle nie był w stanie
>> uciągnąć i poległ.
>
> Ale ja nie pisze jak było tylko ze wymagania nie były jakies wielkie i nie
> był potrzebny jakis mega hiper system.
> Potrzebny był za to w miare prosty system, ale dobrze napisany.

Oczywiście że nie potrzeba jakiegoś mega hiper systemu, może nawet w tym co
było wystarczyło mądrze serwer (dać mniej równoległych sesji, przez co
byłyby "załatwione" szybciej i bez rozsypywania się integralności danych ze
względu na wyskakujące timeouty czy "out of memory").

do góry