A London Stock Exchange elhalasztotta a Linux-ra váltást

Linux

Jó ideje ismert, hogy a London Stock Exchange (LSE) Linux-ra migrál. Nemrég megtartották az első főpróbát, amelyet azóta több is követett. Az éles átállás tegnap, azaz 2010. november 1-én lett volna.
Az LSE azonban elhalasztotta az átállást a Linux-alapú kereskedési rendszerre a harmadik, ügyfelekkel végzett hétvégi teszt után.

A rendszerátállás új időpontját november közepére csúsztatták. Pontos időpont jelenleg még nincs. A MilleniumIT névre hallgató, Linux-on futó rendszer a jelenlegi .Net alapú rendszert váltja majd le. Az LSE már megkezdte a váltás korábban, hiszen lassan egy hónapja Linux-on fut már a Turquoise névre hallgató szolgáltatása, amely egy nemrég kiadott sajtóhír szerint a világ leggyorsabb kereskedési platformja.

A források szerint a hétvégén tartott harmadik átállási főpróba nagyrészt sikeres volt. További teszteket vezettek be azután, hogy az LSE ügyfélkörébe tartozó kereskedési cégek közül néhány jelezte, hogy több időre van szüksége ahhoz, hogy letesztelje, mennyire tud a rendszere együttműködni az új platformmal.

Az átállás pontos időpontjáról a héten várható bejelentés.

A részletek itt.

( tomtyi | 2010. 11. 02., k – 12:44 )

"az LSE ügyfélkörébe tartozó kereskedési cégek közül néhány jelezte, hogy több időre van szüksége ahhoz, hogy letesztelje, mennyire tud a rendszere együttműködni az új platformmal.">gondolom, itt nem Schlaumäuse londoni unokatesója kavar. :DDD

________________________________________
"The vision of Christ that thou dost see
Is my vision’s greatest enemy."

( uid_15426 | 2010. 11. 02., k – 13:06 )

"nagyrészt sikeres volt"

Ezt egy penzintezetnel ugy hivjak, hogy nem volt sikeres. :)

----------------------
while (!sleep) sheep++;

( crypton | 2010. 11. 02., k – 13:18 )

Biztos sok ügyfél .Net -es kliense nem tud skálázódni a nagyságrendekkel kisebb válaszidőkhöz :) :)

eleg konnyen, eleg hozza egy
{
send();
recv();
}
es maris kesz a baj. Ki tudja, hogy a send() es a recv() kozotti pontosvesszonel mennyit ucsorog a gep?
Elobb kell a beolvasast inditani (elokesziteni) es utana az uzenetkuldest inditani.
A modern oprendszerekben altalaban van recv puffer, ez altalaban elegendo, hogy kisimitsa a send();recv() koztt eltelo lukat. Azoban ez csak altalaban, igy leterheltseg es teljesitmenyfuggo.
Kommunikacioban meg lehet oldani, hogy az uzenetkuldes stream oriented legyen, es a streamet figyelni kell, nem fogadas eseten ujrakuldessel (pl tcp). azonban ez nagyon lassuva teszi a dolgot. Egy kereskedesi rendszerben (ahol az elobb vasarlo van pozicioban) ez nem elfogadhato.

Mindegy, barhogy csurjuk, csavarjuk, a kommunikacio mindig teli van idozitesekkel, idozitesekre varakozassal, emiatt nem olyan egyszeru siman csak gyorsitani rajta.

bar varhatoan a teszt sikertelensege mogott nem ez allt, hanem az, hogy az ugyfelek az uj kereskedelmi platformos kliens gephez nem illesztettek megfeleloen a sajat rendszeruket.

A küldő rendszer ki kéne bírja ezt a "problémát".

IMHO minden interfészt úgy kell tervezni, hogy a másik oldalon totál balfaszok ülnek, és ki kell őket bírni.
Ha ez legalább az egyik oldalon megvalósul, akkor működik az interfész.
Ha egyik oldalon sem, akkor van a gáz.

--
Gábriel Ákos

( skynetpro | 2010. 11. 02., k – 18:00 )

na ugye, a técéó! kezdenek már rájönni! </sarcasm>

( asch v | 2010. 11. 02., k – 20:26 )

Lehet, hogy a túl gyors tőzsdéhez skálázni kell az automatikus tőzsdeprogram alatti vasat, mert külöben a versenytárs lenyomja duplagyors válaszidővel. Olyan ez, mint a pingpong, az nyer, akinek jók a reflexei.

Valami nagyokos filozófus pedig feltalálja, hogy az elektronikus tőzsde meg már pláne etikátlan.

( agoston | 2010. 11. 03., sze – 05:04 )

hehe. Ez engem arra emlékeztet, amikor 15 éve JAVA-ban megpróbáltam telnet klienst írni. Persze a lehető leggyorsabban akartam megcsinálni, és nem foglalkoztam a pontos protokollal, csak a kérdés-válaszokat sorban megcsináltam. Mindezt az otthoni linuxon. Aztán nagyon meglepődtem, amikor a SUN-on az egész iszonyat módon nem ment, mert más volt a sorrend.
Szerintem itt is ez van, a sok okostojás összetákolt szoftverei hirtelen borultak egy nagyot...

( praetor | 2010. 11. 03., sze – 09:43 )

a rendszer termeszetesen mukodik, mint ahogy az elozo .net alapu rendszer is mukodott, csak kicsit lassucska volt. termeszetesen egyik rendszer sem tamaszt megkoteseket a kliens oldali szoftverrel szemben, nem lib-et adtak, hanem protokolt, a kedves juzer pedig azzal csatlakozott amivel szeretett. a kliensek altalaban hisztiznek minden ujdonsag miatt, most is errol van szo, nem kell tobbet belelatni.
amugy a 129us tavolrol sem a leggyorsabb, az OMX 90 alatt van (wire2wire).

gondolom idobe telik nekik visszavenni azokat a programozokat, akik fejlesztettek a sajat rendszeruket, csak a valsag miatt mondjuk lenyomhattak a letszamot :)
vagy csak elkeveredtek a meglevo rendszer doksijai, es ido kell, amig valaki ujra at nem latja es hozzaigazitja az ujhoz.

---
return NEVER;

Ubuntu 8.10
HP nx6110
http://java.tszebeni.hu

Maradjuk abban, hogy a fo piaci szereplok atlagosan ketszamjegyu szazaleknyi embert. Ha kicsit is belelatsz / olvastal ujsagot anno, akkor emlekezhetsz.


A spokesman for HSBC said: "There will be IT jobs affected. It is part of a broad review of the entire UK business unit, looking at three key areas of head-office personnel, financial services and commercial banking."

"The key objective is to reduce duplication and create efficiencies," the spokesman said.

The spokesman added that it is not possible to confirm exactly where the job cuts will fall until a consultation with staff has taken place.

Credit Suisse is also to cut 650 jobs in the UK, including IT staff, as a result of "market conditions".

"IT staff cuts top list of budget reduction plans"

"A majority of more than 1,000 enterprise IT decision makers in North America and Europe resorted to hiring freezes, staff reductions or pay and benefits decreases in an effort to lessen IT budgets and spend, Forrester Research reports."

----------------------
while (!sleep) sheep++;

IT staff != programozók. Különösen igaz ez bankok esetében, és a HSBC és Credit Suisse = bankok.

Őszintén mondom én is csak a legritkább esetben láttam programozót kirúgni. Talán csak régen az átkosban (de ott is csak inkább átszerveztek), itt a nagy kapitalizmusba egyetlen esetet se tudnék felidézni.

--
GPLv3-as hozzászólás.

Most komolyan, hadd legyek mar tekintelyelvu picit :
1) te dolgozol programozokkal / programozo vagy, hogy ennyire ralatsz?
2) a penzugyi szferaban dolgozol?

Ha barmelyik kerdesre 'nem' a valasz, akkor inkabb csak tippelgetsz (rosszul).

Irnek privatot, de nincs elerhetoseged. :)

----------------------
while (!sleep) sheep++;

koszonom kerdesed, programozo vagyok egy trading haznal. programozokat *senki* nem kuldott el (kivetel termeszetesen azon cegek akik csodbe mentek). IT staffot lehet vagni persze, kibaszni a winadminokat, meg SAP konzultansokat, mid-office fejlesztoket, ilyesmit. programozokat *senki* nem kuldott el.
de csak azert mert ezt csinalom egy jo ideje meg tevedhetek persze, tovabbra is varom a linket hogy ki kuldott el programozokat akik trading rendszeren dolgoztak.