W dniu 2015-07-25 12:00, Budzik pisze:
> Użytkownik Tomasz Kaczanowski kaczus@dowyciecia_poczta.onet.pl ...
>
>>> Ten system (wybory) dało się zrobić za te "grosze". Wybrano tylko
>>> wyjątkowych ignorantów którzy wybrali jeszcze mniej kumatych wykonawców.
>>> Ale co może być skomplikowanego w wysłaniu kilku raportów i podpisaniu
>>> kluczem? Nie przesadzajmy, kumaty programista da radę to zrobić za kase
>>> mniejszą.
>>
>> hmmm 0.5 miliona? - sorki, ale za to na rok nie zatrudnisz nawet osób
>> gotowych dobrze to wykonać. Sorki - ale kumaty programista nie
>> zaproponuje do bazy z takim obciążeniem mysql-a - i proszę nie dawać mi
>> tu przykładu facebooka, bo tam użyty mysql nie ma zbyt wiele wspólnego
>> po za nazwą z tym co jest do zainstalowania.
>
> Wysłanie protokołów z komisji wyborczych (mało danych, stosunkowo mało
> zapytań) to jest jakieś poważne obciążenie?
> Hmm...

1) zależy jak to zaprojektowano
2) tak - bo wszystko jak napisałem odbywa się w tym samym czasie-
większość komisji wysyła w tym samym czasie - masz takiego ddosa. I tego
nie przewidziano.
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.

--
Kaczus
http://kaczus.ppa.pl

do góry

W dniu poniedziałek, 27 lipca 2015 19:47:47 UTC+2 użytkownik Sebastian Biały napisał:
> On 2015-07-27 08:30, Adam Klobukowski wrote:
> > Koszt aktualizacji systemu tej wielkości jest porównywalna z kosztem nowego
wdrożenia
>
> To jest niemożliwe albo oparte o systemy odlewane ze zbrojonego betonu.
> Przyznam że wiekszość jest odlewana skoro w dziesiątki mln idą dodatkowe
> ficzery lub niemożność ich dodania.

Możliwe, bo jest to proces niemal identyczny z wdrożeniem, a ponadto klient musi
sprawdzić czy jego rozwiązania dodatkowe będą poprawnie działały (i je zaktualizować,
jeśli nie)

> > Nikt tego nie będzie robił "bo wyszedł nowy MySQL, a stary jest już nie
wspierany".
>
> Efektem takiego podejścia jest "no tak, musimy działać na tym ostatnim
> co nam został S/360 bo tak". Czli koszta supportu lecą w kosmos, koszta
> hardware w inny wymiar a jako kierownika tego zabytku zatrudnia się
> nekromatę. Jesteś pewny że to jest "lepiej" na dłuższą metę?

To jest kwestia porównania kosztów do ryzyka. Po pewnym czasie zrobi sie update, ale
nie co wersję.

AdamK

do góry

On Friday, July 24, 2015 at 12:47:18 PM UTC+2, Sebastian Biały wrote:
> Dlatego pytam kogoś kto siedzi przy takim projekcie - co jest czarną dziurą?

Nie wiem co się dzieje w projektach o jakie pytasz. Wiem co się
dzieje w projektach małych, ale na tyle dużych, aby można pokusić
się o analogię.

O jaką analogię? Ano o taką: Koszty nie rosną liniowo względem
złożoności funkcjonalnej projektu! Ile błędnych założeń jest w
małych projektach, a ile w dużych? Ile razy i jak duże części
trzeba przeprojektować i przepisać w małym projekcie, a ile i jakie w
dużym. Ile linijek kodu na dobę pisze programista w małym projekcie a
ile w dużym z uwzględnieniem wersji? Mały projekt można wklepać samemu
od góry do dołu i sprzedać. Mały projekt często zadziała na grubych
komponentach. Zobacz taki 'drobiazg' funkcjonalny: Jeden projekt
zadziała na jednym komputerze, drugi musi się dobrze skalować na
dowolną ilość maszyn. Inny 'drobiazg': w małym projekcie
baza danych wytrzymuje obciążenie, w drugim nie wytrzymuje i
trzeba wklepać silnik bazodanowy samemu...

do góry

On Friday, July 24, 2015 at 11:15:54 PM UTC+2, grapeli23 wrote:
> Dnia 24.07.2015 Pit <n...@s...lonestar.org> napisał/a:
> >
> > Skoro Wikipedia daje radę na mySQL-u to czemu nie baza danych z kartami
> > pacjentów?
>
> Taki niepozorny serwis jak YouTube również w znaczący sposób korzysta z
> MySQL.
>
> https://github.com/youtube/vitess

Nie rozumiem, co was dziwi, że wiki albo youtube daje radę na mysqlu?
Ile trzeba dostępów do dysku, aby podać stronę na wiki? 20 dostępów?
Ile trwa jeden dostęp, 5ms? Jeden słaby komputer obsłuży 10 zapytań
na sekundę w wiki. A jeśli dane są buforowane w ram, to obsłuży
z 1-10tys.

do góry

On Friday, July 24, 2015 at 11:15:54 PM UTC+2, grapeli23 wrote:
> Dnia 24.07.2015 Pit <n...@s...lonestar.org> napisał/a:
> >
> > Skoro Wikipedia daje radę na mySQL-u to czemu nie baza danych z kartami
> > pacjentów?
>
> Taki niepozorny serwis jak YouTube również w znaczący sposób korzysta z
> MySQL.
>
> https://github.com/youtube/vitess

No i jeszcze jedno pytanie: czy przyczyną dużej wydajności wiki, youtube i
innych 'protych' serwisów, na pewno jest mysql?

Cytat z wiki:
https://pl.wikipedia.org/wiki/Memcached
"
Projekt jest używany przez kilka dużych, znanych serwisów, takich jak: Wikipedia[3],
YouTube[4],Facebook[5][6], Twitter[7], Reddit[8], The New York Times[9],
Nasza-Klasa[10][11], Grono.net[12][13].
"

do góry

On Tue, 28 Jul 2015 07:54:46 +0200, Tomasz Kaczanowski wrote:

>> Taki niepozorny serwis jak YouTube również w znaczący sposób korzysta z
>> MySQL.
>>
>> https://github.com/youtube/vitess
>>
>
> Wiem, że w końcu
> pojawiły się triggery, funkcje składowane itd, ale wszystko to ciągle
> działa ułomnie.

I wymaga uprawnień admina (np. triggery), dlatego na hostingach typu
home.pl nie można używać fundamentalnych ficzerów bazy danych. Super po
prostu.

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

do góry

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

>>>> Ten system (wybory) dało się zrobić za te "grosze". Wybrano tylko
>>>> wyjątkowych ignorantów którzy wybrali jeszcze mniej kumatych
>>>> wykonawców. Ale co może być skomplikowanego w wysłaniu kilku
>>>> raportów i podpisaniu kluczem? Nie przesadzajmy, kumaty programista
>>>> da radę to zrobić za kase mniejszą.
>>>
>>> hmmm 0.5 miliona? - sorki, ale za to na rok nie zatrudnisz nawet
>>> osób gotowych dobrze to wykonać. Sorki - ale kumaty programista nie
>>> zaproponuje do bazy z takim obciążeniem mysql-a - i proszę nie dawać
>>> mi tu przykładu facebooka, bo tam użyty mysql nie ma zbyt wiele
>>> wspólnego po za nazwą z tym co jest do zainstalowania.
>>
>> Wysłanie protokołów z komisji wyborczych (mało danych, stosunkowo
>> mało zapytań) to jest jakieś poważne obciążenie?
>> Hmm...
>
> 1) zależy jak to zaprojektowano

No to trzeba dobrze zaprojektowac - sugerujesz ze wysyłano pliki bmp
zamiast spakowanego tekstu?

> 2) tak - bo wszystko jak napisałem odbywa się w tym samym czasie-
> większość komisji wysyła w tym samym czasie - masz takiego ddosa. I
> tego nie przewidziano.

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.

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

do góry

On 2015-07-27 23:14, Pit wrote:
>> To jest niemożliwe albo oparte o systemy odlewane ze zbrojonego betonu.
> Koszt zapoznania się z nieznanym systemem, zrozumienia jego funkcjonowania
> itp. może przekroczyć koszty napisania odpowiednika od zera.

Wynika to z faktu że podstawowa metoda refaktoringu softu rzadowego to
poczekanie aż umrą/wyemigrują wszyscy ktorzy się tym zajmowali a
nastepnie przez 10 lat pisanie nastepnego identycznego w warunkach "rany
boskie na kiedy będzie?".

> Mimo że masz
> źródła, to i tak to jest praktycznie reverse engineering (jeśli nie masz do
> tego dobrej dokumentacji).

Wystarczyło by zatrudnić kilku ludzi do matience i uzupełniania
ficzerami w sposób ciągły. Wyszło by taniej niż pisanie od nowa. Ba,
mogło by się okazać że pisanie od nowa bylo by zbędne. Z jakiejś
przyczyny jednak polityco oczekują "raz a dobrze" co kończy się jak
cepik i okolice.

> Bo "ficzer" to nie zawsze jest banalna sprawa, nawet jeśli system jest
> bardzo elastycznie zaprojektowany. Często to jest coś w rodzaju "dołóżcie
> możliwość tankowania diesla benzyną".

Dzień jak codzień w scrumach. Teamy scrumowe czasem robią duże projekty
(na kilkadziesiąt lat rozwoju i utrzymania).

> Nie dalej jak rok temu została wyłączona ostatnia Odra pracująca na kolei
> (nie pamiętam już gdzie). Skoro coś działa bezawaryjnie i wystarczająco dobrze,

Twoje wystaczająco dobrze to typowy dziadowski kompromis. Efketem tego
"wystarczająco dobrze" jest system rezerwacji na kolei który pisany
przez idotę nie zakładał że mozna w nazwisku podać # co powoduje
niemożnośc kontroli bilteów w całym składzie jeśli jeden pasażer
zatroluje takim znakiem w rezerwacji elektronicznej. Witamy w świecie
"wystarczająco dobrze".

http://tinyurl.com/ndsn67q

Podobno naprawili. Bo wszystko da się naprawić.

Ostatnio poleciała głowa jakiegoś szefa informatyki na tej smiejszej
instytucji rownież z powodu "działa to nie ruszać". I przestało.

> Skoro Odra miała wystarczającą wydajność obliczeniową

Nie miała. Nazwyczajniej w świecie nie dawało się jej nowych tasków bo
by sie przekręciła. Twoje "wystarczająco" zakłada brak rozwoju. Tak samo
mysleli mistrzowie od Elixiru. Efektem dzisiaj mamy co najmniej
idiotyczny system rozliczen międzybankowych gdzie przelewy nosi się
chyba w wiadrach między komputerami sądząc po czasach.

> , pojemność pamięci,

Nie miała. Stosowano sztuczki pozwalające na zmieszczenie się w tym co
było. Czyli programowanie przez workaroundy i ograniczanie specyfikacji.

> wygodę obsługi

Żartujesz prawda?

> i bezawaryjność

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.

> (a przez tyle lat pracy wyeliminowano z
> systemu praktycznie wszystkie błędy), to po co to zmieniać na coś nowego?

Bo jak pewnego dnia zejdzie operator na zawał to pociągi staną. Nie ma
nikogo w zastępstwie. Koniec.

> dokładnie taki sam sens jak ładowanie 8-rdzeniowego Intela do sterowania
> pralką automatyczną?

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.

>> PS. Tak wiem że systemy obrony/ataku nuklearnego w USA obsługuje się
>> dyskietkami 8" i nie zamierzają tego zmienić.
>
> Bez przesady, są stosowane dyski wymienne, bo do dysku wyjętego nie można
> się włamać, a przy okazji są pozabezpieczane przed EMP, pożarem, zalaniem
> itp. (są odporniejsze niż czarne skrzynki w samolotach).

Nie. To zwykłe floppy 8":

http://tinyurl.com/n8slnut

do góry

Dnia 28.07.2015 Sebastian Biały <h...@p...onet.pl> napisał/a:
> Twoje wystaczająco dobrze to typowy dziadowski kompromis. Efketem tego
> "wystarczająco dobrze" jest system rezerwacji na kolei który pisany
> przez idotę nie zakładał że mozna w nazwisku podać # co powoduje
> niemożnośc kontroli bilteów w całym składzie jeśli jeden pasażer
> zatroluje takim znakiem w rezerwacji elektronicznej. Witamy w świecie
> "wystarczająco dobrze".

Nie, na tej Odrze nie chodziły systemy rezerwacji InterCity :D

>> Skoro Odra miała wystarczającą wydajność obliczeniową
>
> Nie miała. Nazwyczajniej w świecie nie dawało się jej nowych tasków bo
> by sie przekręciła. Twoje "wystarczająco" zakłada brak rozwoju.

Owszem, Odry zajmowały się optymalizacją składów towarowych, stacje
rozrządowe mają swoją ograniczoną pojemność i przepustowość. Co z tego że
zwykły pecet przeliczy milion wagonów na minutę skoro stacja obsługuje
maksymalnie kilkaset na dobę?

> Tak samo
> mysleli mistrzowie od Elixiru. Efektem dzisiaj mamy co najmniej
> idiotyczny system rozliczen międzybankowych gdzie przelewy nosi się
> chyba w wiadrach między komputerami sądząc po czasach.

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.

>> , pojemność pamięci,
>
> Nie miała. Stosowano sztuczki pozwalające na zmieszczenie się w tym co
> było. Czyli programowanie przez workaroundy i ograniczanie specyfikacji.

Pierwsze słyszę :D

>> wygodę obsługi
>
> Żartujesz prawda?

Nie, nie żartuję, pracownicy obsługujący system uważali go sa prosty i
pragmatyczny (bez zbędnych bajerów).

>> i bezawaryjność
>
> 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.

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

>> dokładnie taki sam sens jak ładowanie 8-rdzeniowego Intela do sterowania
>> pralką automatyczną?
>
> 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.

>>> PS. Tak wiem że systemy obrony/ataku nuklearnego w USA obsługuje się
>>> dyskietkami 8" i nie zamierzają tego zmienić.
>>
>> Bez przesady, są stosowane dyski wymienne, bo do dysku wyjętego nie można
>> się włamać, a przy okazji są pozabezpieczane przed EMP, pożarem, zalaniem
>> itp. (są odporniejsze niż czarne skrzynki w samolotach).
>
> Nie. To zwykłe floppy 8":
>
> http://tinyurl.com/n8slnut

No w rakietach z lat 70-tych ubiegłego wieku owszem tak, ale zostało ich
już tylko około 500 sztuk.

do góry

On Tue, 28 Jul 2015 21:11:03 +0000 (UTC), Pit wrote:

>> Nie miała. Nazwyczajniej w świecie nie dawało się jej nowych tasków bo
>> by sie przekręciła. Twoje "wystarczająco" zakłada brak rozwoju.

> Owszem, Odry zajmowały się optymalizacją składów towarowych, stacje
> rozrządowe mają swoją ograniczoną pojemność i przepustowość. Co z tego że
> zwykły pecet przeliczy milion wagonów na minutę skoro stacja obsługuje
> maksymalnie kilkaset na dobę?

To z tego, że Odra miała fatalny współczynnik wydajności na wat oraz była
trudna w konserwacji.

>> Tak samo
>> mysleli mistrzowie od Elixiru. Efektem dzisiaj mamy co najmniej
>> idiotyczny system rozliczen międzybankowych gdzie przelewy nosi się
>> chyba w wiadrach między komputerami sądząc po czasach.
>
> 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ę?

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

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

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

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

do góry