-
Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.
atman.pl!.POSTED!not-for-mail
From: Pit <n...@s...lonestar.org>
Newsgroups: pl.comp.programming
Subject: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
Date: Wed, 29 Jul 2015 17:50:13 +0000 (UTC)
Organization: ATMAN - ATM S.A.
Lines: 226
Message-ID: <s...@n...lan>
References: <mosvh7$bpl$1@node1.news.atman.pl> <s...@j...net>
<mot3b3$fmd$1@node1.news.atman.pl>
<55b2141b$0$2206$65785112@news.neostrada.pl>
<s...@n...lan> <mou9rd$ha3$1@dont-email.me>
<9...@g...com>
<mp2s2s$be7$1@node1.news.atman.pl>
<6...@g...com>
<mp5qs2$e63$1@node1.news.atman.pl> <s...@n...lan>
<mp8okc$8sf$1@node2.news.atman.pl> <s...@n...lan>
<1nijznlm13r83.12ovwfiylx2wx$.dlg@40tude.net>
<s...@n...lan> <mpasjc$ki6$1@node1.news.atman.pl>
NNTP-Posting-Host: user-46-113-99-5.play-internet.pl
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: node1.news.atman.pl 1438192213 28563 46.113.99.5 (29 Jul 2015 17:50:13 GMT)
X-Complaints-To: u...@a...pl
NNTP-Posting-Date: Wed, 29 Jul 2015 17:50:13 +0000 (UTC)
User-Agent: slrn/1.0.1 (Linux)
Xref: news-archive.icm.edu.pl pl.comp.programming:207959
[ ukryj nagłówki ]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?
Następne wpisy z tego wątku
- 29.07.15 19:57 Pit
- 29.07.15 21:00 Budzik
- 29.07.15 21:07 Sebastian Biały
- 29.07.15 21:22 Pit
- 30.07.15 01:32 Pit
- 30.07.15 13:33 Roman W
- 30.07.15 13:37 Roman W
- 30.07.15 15:58 szemrany
- 30.07.15 16:01 Roman W
- 30.07.15 16:28 szemrany
- 30.07.15 17:25 Pit
- 30.07.15 18:00 Budzik
- 30.07.15 18:26 Pit
- 30.07.15 20:31 szemrany
- 30.07.15 20:40 szemrany
Najnowsze wątki z tej grupy
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
Najnowsze wątki
- 2024-12-20 Obrońcy
- 2024-12-20 Obrońcy
- 2024-12-20 Obrońcy
- 2024-12-20 Gdańsk => Inżynier bezpieczeństwa aplikacji <=
- 2024-12-20 czyste powietrze
- 2024-12-20 Katowice => Analyst in the Trade Development department (experience wi
- 2024-12-20 Opole => Inżynier Serwisu Sprzętu Medycznego <=
- 2024-12-20 Katowice => Regionalny Kierownik Sprzedaży (OZE) <=
- 2024-12-20 Rzeszów => International Freight Forwarder <=
- 2024-12-20 Katowice => Key Account Manager (ERP) <=
- 2024-12-20 Ekstradycja
- 2024-12-20 Mikroskop 3D
- 2024-12-20 Warszawa => Spedytor Międzynarodowy <=
- 2024-12-20 Warszawa => Analityk w dziale Trade Development (doświadczenie z Powe
- 2024-12-20 Warszawa => Full Stack .Net Engineer <=