"Lemondott az Itaniumról a HP?"

Linux

Rendkívül meglepő kijelentéseket tett Scott Farrand, a HP x86-os szerverekért felelős alelnöke az internetnews.com kamerájának. Farrand elmondásában a HP üzleti kritikus szerverei már sem HP-UX rendszert, sem Itanium processzorokat nem tartalmaznak majd a jövőben, a korábbi generációkból megismert hardveres, firmware-szintű és szoftveres megoldások Red Hat Enterprise Linux platformon lesznek majd elérhetőek. [...] Farrand kijelentései szerint a HP-UX napjai meg lehetnek számlálva, a rendszert feltehetőleg nem portolja egészében x86-os platformra a HP, csupán az üzleti kritikus gépekben nélkülözhetetlen funkciók élnek túl az új platformon. A Project Odyssey keretében működő Dragon Hawk projekt célja a Red Hat Enterprise Linux (RHEL) alá portolni a HP Integrity platformon megszokott funkciókat.

A részletek itt.

( trey | 2012. 07. 10., k – 08:52 )

Ahol HP-UX-szal találkoztam, ott az elmúlt években kiszórták a 'csába az Itanium-ot a HP-UX-szal együtt, aztán Linuxot tettek helyére x86_64 alapokon töredéke áron. Szóval nagy meglepetés itt nincs.

--
trey @ gépház

Azért bankoknál és hasonló helyeken még tartja magát. Persze ott már az is világraszóló újdonság, ha maximum négy órán(és nem ms-on!) belül elmegy X számláról Y-ra a pénz. Persze szigorúan csak nyitva tartási időben, azon kívül lekapcsolják az amperzabáló fekete dobozokat. :)
--
zsebHUP-ot használok!

"Azért bankoknál és hasonló helyeken még tartja magát."

Bankoknál se... :)

"Persze ott már az is világraszóló újdonság, ha maximum négy órán(és nem ms-on!) belül elmegy X számláról Y-ra a pénz."

A néhány ms alatti átutalás évek óta működik, úgy hívják, hogy VIBER... :)

"Persze szigorúan csak nyitva tartási időben, azon kívül lekapcsolják az amperzabáló fekete dobozokat. :)"

Hátigen... az Ügyfélkapun is úgy találták ki okosék az e-tértivevényt, hogy (a feladástól számítva másodpercre pontosan!) 5 munkanap után kell visszafordítani a hivatali küldeményt... külön szívás leprogramozni egy 7/24-es rendszerben azt, hogy kezelje az ünnepnapokat, a csere-munkanapokat, és persze okosék csak pislogni tudtak arra a kérdésre, hogy ha a hivatal szombat éjjel küldi ki batch-ben az értesítéseit, akkor mikor jár le másodpercre pontosan az öt munkanap. :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

A VIBER-t (Valós Idejű Bruttó Elszámolásforgalmi Rendszer) az MNB működteti, míg a normál elszámolásforgalmat a GIRO bonyolítja le a Bankközi Klíring Rendszerrel. Az MNB VIBER-rel kapcsolatosan az alábbi költségeket követeli meg a tagoktól: http://www.mnb.hu/Root/Dokumentumtar/MNB/Penzforgalom/Penzforgalom_szol…

Az MNB 330 Ft-ot kér tételenként egy VIBER-tranzakcióért. Üzemidőn kívül 1000 Ft.

Meg fogsz lepődni, de nem. Olvasgass hitelintézeti törvényt meg PSZÁF előírásokat - nagyon sok mellékes és célszerűtlen marhaságot kell biztosítani ahhoz, hogy ilyen rendszert üzemeltethess.

Pl. kell 3 műszakba felvenni operátorokat, akik okosan nézik, hogy mit csinál a rendszer, ehhez kell ugye legalább 5 embert megfizetni, plusz az irodát, ahol vannak. Kell biztonsági rendszer, elektronikus beléptetőrendszerrel az 5 embernek. Kell egy főnök az 5 embernek.

Naponta legalább 4 jegyzőkönyvet kell kinyomtatni és lefűzni. A rendszer adatait naponta kétszer, két példányban szalagra kell írni úgy, hogy a szalagos egységekben csak mindig csak az aznapi szalag lehet, szalagcserélő robot nem játszik. Azaz kell valaki, aki tud szalagot cserélgetni. A szalagokat egymástól X km-re kell tárolni, jó drága páncélszekrényekben, 10 éves megőrzési idővel.

Kell legalább egy ember, aki a hpt-ből és a PSZÁF előírásokból a saját cégre vonatkozó testreszabott eljárásrendeket/szabályzatokat és hasonlókat előállítja, évenként felülvizsgálja és karbantartja.

A logokra időbélyegzési szolgáltatást kell vásárolnod a Netlock/Microsec páros valamelyikétől, havi 50e Ft.

És még folytathatnám a sort - végtelen sokminden kell egy ilyen rendszerhez, annak ellenére, hogy valószínűleg tökéletesen működőképes és biztonságos lenne a futása az itthoni PC-men is. Na jó, még egy PC kellene valahova máshova a redundancia miatt :-)

...a bankoktól.
Legutóbb, amikor néztem, a CIB 0.5%-ot de legalább 10.000 Ft (tízezer) max. 100 000 Ft jutalékot számolt fel, per viber tranzakció. Ugyanennyi Ersténél is.

"Üzemidőn kívül 1000 Ft."
Az OTP vibert csak banki munkanapon belül teljesít :-) (hivatalos álláspont szerint) Bár ők csak 0.2%-ot számolnak fel, de minimum 4-600Ft között.

Van egy kis profit rajta...

Főleg úgy, hogy még azzal sem indokolható a magas fix költség, hogy a banknak fix, forgalomfüggetlen csatlakozási díjat kellene fizetnie a VIBER-hez, ugyanis a VIBER-csatlakozás ingyenes (természetesen a technikai és egyéb feltételeknek meg kell felelni).

Egyedül azzal indokolható a magas fix költség, hogy kevésszámú tranzakció miatt kell fenntartaniuk a VIBER-infrastruktúrát. Viszont ez meg ugye hülyeség, hiszen pont azzal lehetne a tranzakciók számát növelni, hogy a költségeket csökkentik, mert akkor népszerű típus lehetne a VIBER-en keresztüli átutalás.

Szerintem itt másról van szó, inkább arról, hogy a Neptun csak bizonyos időközönként (értsd: naponta egyszer) kapja meg az előző beolvasás óta beérkezett átutalásokat. Ugyanis maguk az átutalások nem a Neptunba mennek (hiszen a Neptun nem pénzintézet), hanem a Magyar Államkincstárhoz. Az, hogy a MÁK naponta hányszor küldi a Neptunok felé az adatokat, az MÁK dolga, nem az SDA Kft-n múlik valószínűleg. A MÁK befogad VIBER-t, de a Neptun csak naponta kapja meg az utalásokat. Bár jó lenne, ha ezt legalább 4 órára módosítanák, hiszen még a lassú utalások is legfeljebb 4 óráig tartanak napközben.
Az baromság, hogy nem olvas fel VIBER-t (egyrészt a Neptunnak fogalma sincs arról, milyen tranzakcióval kapta meg a MÁK a pénzedet, a VIBER-átutalások is normál tranzakciók, csak más infrastruktúrán keresztül közlekednek, nem a GIRO BKR szolgálja ki azokat.

Hiaba adja at a tranzakcio datumat. Tegyuk fel, hogy te julius 11-en 18:00-kor vizsgaznal. A Neptun 12-en 8:00-kor megtudja, hogy jeee, volt itt egy VIBER atutalas tegnap 17:55-kor. Sokra nem mesz vele, mert a vizsga mar elmult.
A baj azzal van, hogy a Neptun nem azonnal ertesul az azonnali tranzakciokrol (sot a napkozbeni tranzakciokrol). Az, hogy mikor inditottak a tranzakciot, itt irrelevans, a lenyeg, hogy mikor ertesul rola a Neptun.

Mondom, hogy ez nem a Neptuntól függ, az SDA Kft.-nek ehhez nincs sok köze. Még HÖK-ös időszakomból tudom, hogy a Neptunhoz érkező utalásokat Excelben kapják meg az egyetemek a MÁK-tól (legalábbis Veszprémben így volt a tandíjakkal), és azt kézzel töltik be a Neptunba. Azaz nincs on-line, automatizált interfész a két rendszer között és tartok tőle, hogy nem az SDA Kft. miatt, hanem a MÁK miatt.

Teljesen komoly.

Miért, az milyen, hogy a Neptun tudomásom szerint nem tud autentikációs szolgáltató lenni? (bár infóim kb. 3 éevesek) Pedig milyen szép lenne, ha mondjuk az egyetemi weboldalra, meg sok minden más egyetemi helyre be tudnál lépni a Neptun-kódoddal.
Ezt a csodát lesd meg: https://wiki.aai.niif.hu/index.php?title=NeptunLdapSyncImpl

A MÁK-ra pont nem vonatkoznak az IG2 4 órás szabályai, ő az egyik kivétel, akinek nem kell ilyesmivel foglalkoznia. Meg pl. azok a hitelintézetek (helló takarékszövetkezetek), akik nem közvetlenül csatlakoznak a GIRO-hoz, hanem máson keresztül, na, rájuk is 6 órás szabály vonatkozik.

Abban a kivételes helyzetben vagyok, hogy sem a felhőket sem a banki szoftvereket nem ismerem. Így nyugodt szívvel kételkedem abban, hogy ez lehetetlen lenne.

Naívan abból indulok ki, hogy legyen egy alkalmazás, hozzá meg egy dedikált VM. Ha futtatni kell a progit, elindítom a VM-jét, ha befejezte, leáll a VM-je magától. Az egyszerűség kedvéért a VM-et nem mozgatom futás közben, csupán olyan HW-en indítom el, aminek elbírja a loadja. (Mondjuk van egy táblázatom a progik igényéről, tudom, épp mi fut rajta, így egy egyszerű összeadás a primitív erőforrásmanagementem alapja.) Ezen kívül van egy HW vezérlőm, ami 1 kivételével az összes nem használt HW-t leállítja.

Semmiképp sem optimális, de pofon egyszerű. Mi a gond vele?

A banki tranzakcióknál a következőkre kell figyelni: értéknapokra szólnak, az egyes értéknapokról naponta különféle iratokat kell kiállítani (elektornikusan). Addig, amíg ezek az iratkiállítások futnak, addig nem szabad befogadnia tranzakciót a rendszernek, hiszen azután újra kellene az értéknapra szóló iratokat kiállítani. Meg még jópár ilyen folyamat van, aminek előfeltétele, hogy amíg a folyamat fut, aközben nem szabad tranzakciónak befutnia. Így nem arról van szó, hogy nem tud skálázódni a rendszer (nagyobb hw-t most is lehetne venni), hanem arról, hogy biztosítani kell bizonyos folyamatokra azt, hogy race condition ne fordulhasson elő. És pont az, hogy nem lehet este átutalást végezni (vagyis lehet, de nem arra az értéknapra), azért van, hogy a race condition ne fordulhasson elő. Gondolj bele, itt nem lehet a rendszer működése nemdeterminisztikus a sok párhuzamos kapcsolat miatt. A rendszer állapotának minden pillanatban konzisztensnek kell lennie.

Egy elosztott Db például eventual consistencyvel rendelkezik, azaz kellően nagy változtatás nélküli idő eltelte után biztosított csak az, hogy minden node ugyanazt az adatot látja. Egy tranzakciónak viszont atomi műveletnek KELL lennie mindenki számára.

http://www.mnb.hu/Root/Dokumentumtar/MNB/Penzforgalom/penzforgalom-vele…

Itt van például, hogy naponta milyen műveleteket és mikor végez az MNB.

"A rendszer állapotának minden pillanatban konzisztensnek kell lennie."

Most naivaként megemlítem, hogy ezt RAC-tól kezdve mysql cluster-ig szinte minden tudja. Utána - szintén naivaként - megemlítem, hogy tudtommal az XA tranzakciókat tudtommal pont erre dolgozták ki. Majd megkérdezem, hogy ez miért van mégis ennyire elbonyolítva? (Ezután befejezem az elbeszélő E/3-at és a sörömet.)

"A banki tranzakcióknál a következőkre kell figyelni: értéknapokra szólnak, az egyes értéknapokról naponta különféle iratokat kell kiállítani (elektornikusan). Addig, amíg ezek az iratkiállítások futnak, addig nem szabad befogadnia tranzakciót a rendszernek, hiszen azután újra kellene az értéknapra szóló iratokat kiállítani."

Ezt nem tudom teljes mértékben követni. Ezek az "iratok" T+1 vagy T+2 nappal kerülnek ki a rendszerből, amikor az adott értéknapos tranzakciók már réges-rég lezárultak, de ettől függetlenül általában akármikor tudsz számlatörténetet lekérdezni.

"És pont az, hogy nem lehet este átutalást végezni (vagyis lehet, de nem arra az értéknapra), azért van, hogy a race condition ne fordulhasson elő."

Bocsánatot kívánok, de szinte az összes bank képes saját számlái között azonnali átutalásra bármikor, illetve VIBER-el bankok között is. A másik érdekesség, hogy bankközi átutalást elindítani bármikor tudsz, a saját számládon az átutalni kívánt összeg általában azonnal zárolásra kerül...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"ocsánatot kívánok, de szinte az összes bank képes saját számlái között azonnali átutalásra bármikor, illetve VIBER-el bankok között is. "
" a saját számládon az átutalni kívánt összeg általában azonnal zárolásra kerül"
A VIBER-tranzakciók eltérnek a normál banki tranzakcióktól, mivel nem visszavonhatók, véglegesek. Van arra példa, hogy szükséges lehet egy tranzakció visszavonása, és pont azért kerül zárolásra és nem elköltésre a pénzed, hogy visszavonhasd a tranzakciót. Ilyen lehet jogosulatlan netbank-hozzáférés esetén a netbanki hozzáférés letiltása és a tranzakciók visszavonása. Meg egyéb más eset is.

Magadnak mondasz ellent. Ha azonnal teljesül, akkor nem okoz race condition-t? Vagy nem zavarja az "iratkiállításokat"? :)

Azt sem értem tisztán, hogy mi a különbség az azonnal teljesülő zárolás és az azonnal teljesülő átutalások között technikai szinten...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Magadnak mondasz ellent. Ha azonnal teljesül, akkor nem okoz race condition-t? Vagy nem zavarja az "iratkiállításokat"? :)"
VIBER-t 8:00 és 18:00-ig fogad be az MNB, utána nincs lehetőség azonnali utalásra. A netes, 18:00 után igényelt VIBER-ek is csak másnap reggel 8-kor fognak teljesülni.
Elolvastad, hogy mit csinál az MNB meg a GIRO egy napon? Már linkeltem itt, hogy az MNB milyen elszámolási lépéseket csinál meg minden nap. Ezen lépések közül rengetegnek feltétele, hogy lezárt tranzakcióhalmazzal dolgozik.

"Azt sem értem tisztán, hogy mi a különbség az azonnal teljesülő zárolás és az azonnal teljesülő átutalások között technikai szinten..."
Zároláskor nem költheted el még egyszer ugyanazt a pénzt, de még nálad van, ezért is tudod visszavonni a tranzakciót (hiszen még nem teljesült). Az azonnali teljesüléskor pedig már a másik félnél van a pénzed.

"VIBER-t 8:00 és 18:00-ig fogad be az MNB, utána nincs lehetőség azonnali utalásra."

És?

"A netes, 18:00 után igényelt VIBER-ek is csak másnap reggel 8-kor fognak teljesülni."

És?

"Elolvastad, hogy mit csinál az MNB meg a GIRO egy napon?"

Nem. De tegnap dicsértek meg az IntraDay Giro projektben való részvétel okán.

"Már linkeltem itt, hogy az MNB milyen elszámolási lépéseket csinál meg minden nap. Ezen lépések közül rengetegnek feltétele, hogy lezárt tranzakcióhalmazzal dolgozik."

Ezt értem, de technikailag a lezárt tranzakció jelzése az egy mező egy adatbázisban.

"Zároláskor nem költheted el még egyszer ugyanazt a pénzt, de még nálad van, ezért is tudod visszavonni a tranzakciót (hiszen még nem teljesült). Az azonnali teljesüléskor pedig már a másik félnél van a pénzed."

Értéknapos átutalásnál például nem kerül zárolásra a pénzed... napközbeni átutalásnál se feltétlen kerül zárolásra a pénz...

Egyébként egyszerűen azt nem értem, hogy mit akarsz mondani, mert írtál mindenféle problémákról, keverve a technikai problémákat üzletpolitikai és egyéb dolgokkal... de nem állt össze egész képpé, hogy "jópár ilyen folyamat van, aminek előfeltétele, hogy amíg a folyamat fut, aközben nem szabad tranzakciónak befutnia", miközben "a VIBER-tranzakciók eltérnek a normál banki tranzakcióktól, mivel nem visszavonhatók, véglegesek", illetve "az azonnali teljesüléskor pedig már a másik félnél van a pénzed", ugyanakkor "ezen lépések közül rengetegnek feltétele, hogy lezárt tranzakcióhalmazzal dolgozik".

Most akkor van lehetőség tranzakciók befutására, amíg a "folyamatok futnak", vagy sem? :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Dehogy kapcsolják le őket. Olyankor nem átutalással foglalkoznak, hanem más, sokkal fontosabb dolgokkal, pl. klíringzárással, GIRO küldéssel/fogadással, kamatszámítással, tárgyieszköz-nyilvántartással (igen, ezt egy számlavezető rendszer csinálja) meg hasonlókkal.

Jó ez így :-p

( Exit | 2012. 07. 10., k – 09:18 )

Tehat az Oracle-nek megis igaza volt. Akkor meg minek a pereskedes? (Kivancsi vagyok attelefonaltak e Scottnak a ceg ugyvedei, hogy megkoszonjek neki ezt a konnyed nyilatkozatot.)

De ami szamomra erdekesebb, hogy 6 eve meg a Sun nyilt levelben ajanlotta, hogy olvasszak ossze a Solaris-t meg a HP-UX-et es fejlesszek kozosen, de persze a HP-nak az nem volt eleg jo ("almost laughable" volt a valasz). Pedig akkor is az volt a Sun egyik erve, hogy a kozos OS megkaphatna a Solarisbol tobbek kozott az x86/x64 szupportot, amit a Sun mar akkor a HP-UX problemajanak latott.
Nah persze akkor meg a HP konnyeden nevette ki a Sun-t, amikor az Oracle-lel dult a szerelem. Most aztan ket szek kozott a pad ala esett.

( mauzi v | 2012. 07. 10., k – 09:41 )

A világ már 10+ éve lemondott az Itaniumról. Valamikor a kilencvenes évek közepén hallottunk róla előszőr (akkor még Merced néven) - akkor felcsillant a szemünk, hogy esetleg az Alphák, Sparcok, MIPSek mellé az Intel is tojik valami frankót. Mire megérte azt, hogy Itaniumra átkeresztelték, már zsákutca volt.

( STP | 2012. 07. 10., k – 09:53 )

Hehe.
Azért elegáns fricska az "oralinuxnak".
.
Lassan már csak az AIX marad.
Only be one! :D :D

Jól, hogy a fene essen bele. Én, mint NEM laboros, nem rendszergazda, nem karbantartó csak annyit látok belőle, hogy butább grep van rajta, és nincs sudo.
Persze biztos van, aki örül neki, és boldogan használja, én nem látom egyelőre, miben jobb, mint egy vöröskalapos rendszer. (nyílván a támogatott vasakat nem ismerem, és nem is akarom ismerni)
----
India delenda est.

Mivel a Solaris UNIX, ezzel most nagyon mellélőttél. Aki UNIX szakértő, azaz pont annyit ismer, amennyit a SUS előír, az egy Solaris rendszerrel tökéletesen boldogul. De te valószínűleg azért tartod használhatatlannak/nehezen használhatónak a rendszert, mert olyan dolgokat ismersz, amelyek nem UNIX dolgok, csak UNIX-like dolgok, azokból is GNU projekt által bevezetett bővítések. De "GNU is Not UNIX" per definitionem.

Annyira buta, hogy szinte minden jó, ami használhatóvá tette a linux-ot onnan jött, pl.: PAM, meg még egy jó pár dolog. :)
Én RedHat support-ból élek, de egyetértek az előttem/utánam szólóval aki első szerelemről beszélt. :)

Lehet, hogy öreg a csaj, de nem fogaz az tuti. :D

A ggrep(/usr/sfw/ggrep) GNU grep, es mindent tud, amit a linuxos. Ha ismerned az RBAC-ot, nem hianyozna a sudo. Persze egyszerubb fikazni, mint tanulni. Mellesleg a solaris 11-ben benne van mindketto, meg egy csomo mas erdekesseg, de gondolom azt is ugyanolyan melyrehatoan ismered, mint az elodjeit.

Toni

1. Semmiféle ggrep nincs ezen a Solarison. Nem pucolták le róla, alap installban úgy tűnik nem szerepel.
2. Fogalmam sincs mi az az RBAC, és lásd lent.

Mint említettem, nem vagyok karbantartója vagy bármilyen szinten adminisztrátora a masinának, ellenben a szupport szegényes rá, és linuxos előzményekkel bizony baromi kényelmetlen ez a "buta-linux". Nem tervezem megtanulni, mert minden megy, aminek mennie kell, és nem érdeklődöm a Unix-karbantartás iránt.
Szóval nem kell ez a sértett admin hiszti, leírtam, hogy mi a nyűgöm a dologgal, mi okozott nekem személyes ellenérzéseket, és még azt is leírtam mellé, hogy abszolút szubjektív és komolytalan a dolog.

Solaris 11-et meg ugyan minek ismerném, amikor nem azt használjuk környezetnek. Ez is tipikusan olyan támadás, hogy magadból indulsz ki, hogy mindenkit érdekelnek ezek a dolgok. Nem, engem nem érdekel a Solaris, a 11-es meg főleg nem, amikor azt nem is használjuk.
----
India delenda est.

De, ez hiszti, ugyanis nem történt semmi olyasmi, amit te mondasz:

"Én, mint NEM laboros, nem rendszergazda, nem karbantartó csak annyit látok belőle, hogy butább grep van rajta, és nincs sudo."

Ahhoz, hogy ex-catedra jelenthessek ki valamit, legalábbis szakértőnek kéne beállítanom magam, amit nyílvánvalóan nem teszek, és ráadásul nem azt állítom, hogy ez vagy az igaz, hanem hogy ÉN szubjektíven azt látom, hogy.

Abszolút szubjektív kis nyűgök ezek, ha az én "szakterületem" szídná így valaki, lehet engem is zavarna, én ezt teljességgel megértem.
Elnézést is kérek, itt.
----
India delenda est.

GNU grep ezer éve van már a 10-esen is, ha arra van szükséged. sudót meg nem muszáj használni, ott vannak a profilok, amivel ugyanez a funkció elérhető, beépített és sokkal finomabban adagolhatóak a jogok.

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

Teljesen irreleváns, és vitatkozni is felesleges róla, főleg ebben a stílusban, de ami "nincs 10-esen", azt ott találod bármelyik tetszőleges Solaris 10 global zone-ban, amit "Entire Distribution"-ként telepítettél gyári telepítőről. Más kérdés, hogy az alapértelmezett $PATH nem fogja tartalmazni.

# what /usr/sfw/bin/ggrep
/usr/sfw/bin/ggrep:
SunOS 5.10 SunOS Development May 2004
--
/etc/lib/lu/plugins/lupi_bebasic

( xian v | 2012. 07. 10., k – 19:44 )

http://arstechnica.com/information-technology/2012/07/hp-says-itanium-h…

Farrand left out a part of HP's Project Odyssey briefing notes to that effect: "Project Odyssey includes continued investment in our established mission-critical portfolio of Integrity, NonStop, HP-UX, OpenVMS as well as our investments in building future mission-critical x86 platforms.

azaz kihagyta, hogy az Odyssey projekt folytatja a HP-UX fejlesztését.

( lgb | 2012. 07. 16., h – 15:27 )

Reggeli olvasasi uzemmodomban igy dekodoltam: "Lemondott az Itaniumrol a HUP?"