üzenetek

hozzászólások


Bibby
(PH! addikt)

Az "overnight" egy időtáv, aminek semmi köze az MNB-hez. Bármely A szereplő fizethet overnight kamatot bármely B szereplőnek. :U


rednifegnar
(kvázi-tag)

sztem itt mar megint atestek a lo tulalodalara. 5sec, miert? miert nem 30, 10 vagy 1, vagy 0?
nem ezt kellett volna, siman megtartani az 1 orast ahogy eddig, csak kiterjeszteni; mukodjon mindig, ejjel nappal, hetvegen es ezt betartattatni, szamonkerni. ez nem lett volna nagy dolog a jelenlegi kornyezettel es mindenki jol jar, de nem, most 5sec es nem fog mukodni. majd jon a sumakolas, a halasztas a buntetessel fenyegetozes. dejavu navonline detto ugyanez, utolso napokig valtozo specko, azota is valtozasok, fenyegetes, ellenorzes. kozben egy csomoan nem tudtak/akartak teljesiteni, jott a sunnyogas, ugyse veszik eszre hogy meg nem ment be. mar a nav-nal se tudtak megmondani mi pontosan az hogy "azonnali bekuldes", akadozik minden , a bekuldott adatok fele nem jo semmire, erre most jon a kovetkezo verzios szopola (aztan majd a 2.0 amirol nem tudni mi lesz csak azt hogy meg nagyobb szopas).


Kopi31415
(PH! félisten)
Blog

A banknak nem kölcsön adom a pénzem, hanem kezelési költség fejében nála tárolom. Az nem a bank pénze.


D1Rect
(PH! félisten)
Blog

Az extraprofitot költsék inkább fejlesztésre, ne az ügyvezetők tömjék a zsebüket a kisembereken élősködve!


Doom
(fanatikus tag)

Ez olyan formában igaz, hogy nem az MNB-hez mint intézményhez kötődik. De ugyanúgy nem kötődik az átutaláshoz sem. Én mondtam egy példát ,hogy mihez kötődik.

[ Szerkesztve ]


Doom
(fanatikus tag)

Nem, a betét az a pénz, amit az elhelyezők kölcsönadtak a banknak. Nem fogod a befizetett kp-dat megtalálni a bank raktárában, de ha így lenne, akkor a bank nem használhatná, pedig megteszi. A bank nem kezelési költséget fizet a betétedre, hanem kamatot. Ha kezelési költséget fizetne, akkor az szerződésben fixált összeg lenne, nem függene a piaci viszonyoktól, mint ahogy a betét kamatai függenek.


bambano
(Jómunkásember)
Blog

"A bank nem kezelési költséget fizet a betétedre, hanem kamatot": értelmezésben kihívásokkal küszködők kedvéért a "kezelési költség fejében nála tárolom" megfogalmazás azt jelenti, hogy aki beteszi a pénzt a bankba, a tárolásért cserébe kezelési költséget fizet a bank részére.


Doom
(fanatikus tag)

Látom, nehezedre esik emberi módon megnyilvánulni. Ha a számlavezetési díjat értette alatta, akkor sincs igaza jogilag, mert nincs mögötte készpénz, amit tárolni kellene. Meg akkor mire fizeti a bank a kamatot?


Kopi31415
(PH! félisten)
Blog

Mi a különbség a papírpénz és az elektronikus között jogilag?
kamatot fizet utána? Meg tudod mutatni azt a kamatot? Pláne, hogy azt garantálja is? Nem, nem fizet kamatot.


kleinguru
(PH! addikt)

Köszönöm a részletes kifejtést, öröm volt olvasni:R

Kíváncsi vagyok a másik oldal véleményére is:K

Off offja: nagyon szeretem ezeket a beszélgetéseket, mert ezekből rengeteget lehet tanulni.


fzboxx
(tag)

Hogy itt miket írnak le néhányan?


UnA
(Korrektor)
Blog

Amiket gondolnak. ;)


ZeroCool
(újonc)

Ne haragudj nem akarlak megbántani, de nagyon sok butaságot írsz. Egy kicsit olvass még ennek utána. Olyan érzésem van, hogy soha nem hallottál még arról hogy Virtual Machine, és soha nem láttál egy nagyobb IT infrastruktúrát.

Első körben a konténerizációnak semmi köze az IG3/AZUR/IP projektekhez. Ez egy eszköz amit a megvalósítást segíti. Van olyan bank aki ezt használja, de legtöbben nem.

Általában egy nagyobb IT-val rendelkező helyeken nem az van amit írsz, hogy vesznek egy vasat, arra raknak linuxot és akkor telepítsünk rá valamit. Komoly szerverek vannak, amelyeken virtuális gépek futnak, saját operációs rendszerekkel, olyannal amire egy adott rendszernek szükséges van. Na már ezeken a virtuális gépeken saját ökoszisztémát kell kialakítani. Egy virtuális gép a rá telepített operációs rendszerrel már önmagában is egy szignifikáns mértékű erőforrást használ.
Nézzünk egy egyszerű példát. Van egy JAVA-s alkalmazás, ami 8-as verziót használ. Ennek kell még valamekkora storage és még mondjuk linuxon fut. Van egy másik .NET-es alkalmazásod amihez viszont windows oprendszer kell, több memória .... Mit tett eddig a jó üzemeltető? Csinált még egy VM-et. Ami a saját működéséhez is elvisz megint egy csomó erőforrást.

Na legfőképpen ezt a problémát oldja fel a konténerizáció. Nem kell "még egy VM". A konténerek a host operációs rendszer minden szolgáltatását igénybe tudják venni, és egy konténerben csak egy szolgáltatás vagyis alkalmazás fut. A konténernek minimális erőforrás igénye van önmagában, mivel a host operációs rendszer erőforrásait használja. Egy konténer önmagában egy egészet képes alkotni, minden környezeti beállítással ami nincs hatással sem a host operációs rendszerre, sem a többi konténerre. Egy konténert el tudsz készíteni úgy, hogy legyen benne 7-es JAVA, a másikat úgy, hogy legyen benne 8-as. Mind a kettőben egy másik alkalmazás fut. Mi történik ha a 8-as JAVA-t upgradelni akarják 11-re? Megteszik, és a többi konténerben futó alkalmazásra semmi hatása nincs. Érted már a lényeget?

Nem biztonságos? Megint csak írsz valamit, de fogalmad sincs milyen konfigárciós lehetőségek vannak.

Ezen túl egy elkészített Docker image immutábilis. Egyszóval ha a fejlesztők azt egyszer elkészítik, azt kiadják akkor abban teljesen biztosak lehetnek, hogy nem lesz konfigurációs probléma akkor amikor azt valaki elindítja, mert az fog elindulni amit ők kiadtak.

Írtál még az orkesztrációs eszközökről. Ezek nélkül is tökéletesen tud futni egy konténer. Mire jó? Hogyan oldod meg most azt, hogy ha egy alkalmazás szervered leáll? Vagy esetleg csak az alkalmazás benne? Most is mindenféle monitorozó eszközt használnak, hogy lássák ha egyáltalán gond van, és fix méretű klasztereket használnak a kiesésmentességre. Az orkesztrációs eszközök ebben segítenek. Ők maguktól el tudnak indítani, illetve leállítani konténereket bizonyos feltételek alapján. Ennek mentén a skálázódás és a kiesésmentesség sokkal jobban menedzselhető. Hirtelen ráugrik 100x annyi felhasználó az alkalmazásra mint 1 perccel azelőtt volt? Elindít még 4 példányt az alkalmazásból, és vígan kiszolgálja a megnövekedett terhelést. Majd amikor vége, akkor leállítja ezeket a példányokat, és máris nem használ el az alkalmazásod annyi erőforrást.
Egy másik nagyon hasznos szolgáltatás. Hogyan oldod meg a mostani rendszerekkel a kiesés mentes verzió frissítést? Nagyon nehezen, mindenféle loadbalancerek, és szerverek kézi konfigurációjával. Ezek az eszközök egy maguktól megoldják neked. Stabilan.

Amit még írtál, hogy milyen gyorsan lehet deployolni. Itt is a "nem hiszem". Nem érted a lényeget. Nem egy szövegszerkesztőt akarsz a linux alá feltelepíteni, hanem egy pl. egy banki üzleti alkalmazást. Ez pedig lényegesen gyorsabb mint az alkalmazásszerveres megoldás. Persze a szoftvert is jól kell tervezni.

Nem egyszerű? Nem is bonyolult, csak hát ez is egy olyan dolog amiről nem 3 youtube videót kell megnézni, hogy hogyan kell, hanem olvasni és tanulni.

Én azt mondanám, hogy mielőtt legközelebb kioktatod a fejlesztőket egy olyan technológiáról amiről halvány sejtelmed sincs, hogy milyen trógerek és semmirekellőek, azelőtt kicsit tájékozódj. Főleg, hogy több embert is teljesen tévútra terelsz ezzel.


kleinguru
(PH! addikt)

Abban mindenki egyet ért, hogy az eszközt kell választani a feladathoz és nem a technológiához a feladatot.

Azon bankok, aki nem ezt használják, ők miért nem?
Nincs megfelelő szakember gárdájuk, vagy az ő igényeiknek nem ez felelt meg a legjobban?

Ráadásul elég érdekes, hogy a legtöbben nem...

[ Szerkesztve ]


Tikakukac
(Jómunkásember)

Nincs megfelelő szakember gárdájuk

Laktárs dolgozott be banknál, annál a szép zöldnél. Őt idézve: annak is örülj, hogy egyáltalán megvan a pénzed :B Ebből azt vontam le, hogy minden faja. Minden más ismerős, barát, régi egyetemi csoporttárs aki ilyen helyekre ment mind arról számolnak be, hogy maximálisan kompetens mindenki és 110%-ot nyújtanak. Dehogy. :D


ZeroCool
(újonc)

Jó a kérdés. Ezekhez a technológiákhoz értő szakemberek is kevesen vannak még ma Magyarországon szerintem (arányosan). Ez egy viszonylag új technológia és szemlélet. Ezen túl ezeknek a cégeknek van egy kialakult infrastruktúrájuk, és ehhez szervezetük. Ezen technológiák bevezetéséhez egy más szemléletre és infrastruktúrára is szükség van, amire váltani azért egy hosszabb folyamat. Főleg úgy, hogy közben a már meglévő üzletileg kritikus alkalmazásokat is fent kell tartani addig amíg esetlegesen azok is nem állnak át.
Maga konténerizáció hozza magával a DevOps szemlélet kialakítását is.

Ugyan soknak tűnik az az idő ami az Instant Payment kialakítására rendelkezésre állt, de ha belegondolsz, hogy szinte az összes rendszert módosítani kell emiatt, és ezzel együtt még esetleg egy új technológiát is be kell vezetni, máris nem tűnik olyan soknak ez az idő, ha biztonságosra és stabilra akarják megcsinálni.

[ Szerkesztve ]


kleinguru
(PH! addikt)

Érthető a válasz, el is tudom fogadni, nyilván az idő faktor is csak relatív lehet (már ha a mennyiségét becsüljük: sok, kevés, elég).

Ha valakinek van tapasztalata, akkor mesélhetne ennek kapcsán a tesztelésről is, hogy mennyire veszik komolyan, mennyire automatizált és mennyire tartják erőforrás pazarlásnak a dolgot.

A számlavezető bankom mobil alkalmazásán kb 1 éve az látszott, hogy felhasználói szemléletű tesztelő soha nem látta, mert ha igen, akkor garantált nem megy ki úgy az app, mára ez picit javult, de még mindig katasztrófa. Aztán volt kollégám ehhez a bankhoz került és mesélt olyat, hogy a tesztelő ugyan jelezte a problémákat, de a menedzsert egyáltalán nem érdekelte.


Doom
(fanatikus tag)

Van különbség. A papírpénzt a jegybank (MNB) bocsátja ki, közvetlenül befolyásolja a mennyiségét és garantálja (szabályozza) az értékét a monetáris politikáján keresztül.
Az elektronikus pénzt a kereskedelmi bankok teremtik, a jegybank közvetetten befolyásolja a mennyiségét a kötelező tartalékrátával. Nem garantálja viszont az értékét, mert ez a kereskedelmi bankod felé való követelés (a bank szempontjából tartozás), mint korábban írtam. A kereskedelmi bankod megígéri neked, hogy kp-ban odaadja a számlád egyenlegéig azt a mennyiséget, amennyit kérsz. De addig ő használja, ahogy a törvény megengedi neki. Mintha a barátodnak kölcsönadnál - akkor vele szemben lenne követelésed.
Ez egyébként jól látszik a bank könyvvitelében is. Ha tanultál számvitelt, akkor talán mond valamit az, hogy te a bankbetétedet az aktívák között (eszköz oldalon) tartod nyilván, míg a bank a passzívák között (forrás oldalon). Utóbbi oldalon te a kapott hitelt tartod nyilván.
Ha a bankod csődbe megy, a jegybank nem fizeti ki neked kp-ban a pénzed (pontosabban az OBA helytáll egy bizonyos összegig, amennyiben van benne elég pénz, de ezt is a piaci szereplők töltik fel), tehát szélsőséges esetben elveszítheted a betétedet. Ahhoz, hogy a kp-dat kvázi "elveszítsd" (azaz az értéke elvesszen), az országnak kell csődbe menni, nem egy banknak.
Nehezen hiszem, hogy nem kapsz kamatot a betétedre. Minden betét esetén meg van határozva a kamatláb, ami alapján havonta növekszik a számlaegyenleged. Az persze más kérdés, hogy most olyan alacsonyak a kamatok, hogy szemmel alig látható, de attól még fizet a bank. Talán valamikor majd megint látni lehet szabad szemmel is.


Vektast
(tag)

Fasza kis iromány lett! :) Köszi! :C


UnA
(Korrektor)
Blog

De miért? Mert ilyen a kapitalizmus: a tulajdonosok általában csak kivenni akarnak belőle, stratégiai és hosszútávú gondolkodás minimális.

üzenetek