Does anyone know if this halt is related to the recent switch over to the new Linux based platform? ( http://news.ycombinator.com/item?id=686116 )
I believe this is due to a glitch in the Application and not in Linux per se.
LSE Halts
21–30 of 72 posts
Re: LSE Halts
#22Earlier quoted context omitted.
Via mono. If that's true... that would be an interesting news for the project (not because of the bug itself of course...).
If the LSE were using F# we'd have heard a lot more about it already. For instance, from Microsoft.
Maybe not if they were using F# on mono. Their PR would have to work very hard to put this in a way that doesn't say "LSE is using our language on a foreign platform using a completely alternative implementation, which has nothing to do with us apart some ECMA specs - and they're still successful without MS involvement. Yes, we just confirmed that you can trust your highly critical .NET environment to the alternative versions of runtime."
Re: LSE Halts
#23The problem is that the LSE can't hire top tier talent. There are plenty of people who are experts in building hugely concurrent and fail-safe exchange software, and they pretty much all work for investment banks. The LSE can't afford to compete with $1000/day salaries so they end up hiring second-tier developers. And unfortunately second-tier developers are a lot lot worse than first-tier developers.
I don't think it's about talent, but more of a problem of proper planning and execution. It seems things had been rushed to meet the tight demands, causing the chaos.
When LSE acquired MilleniumIT, to redo the platform, they claimed to have developed world fastest trading platform[1] and had enough talent under their belt developing trading systems around the globe for last decade.
[1] http://www.wallstreetandtech.com/exchanges/showArticle.jhtml...
Re: LSE Halts
#24What if all these systems were open sourced? Including all the load tests.
At this size, some obfuscation might be good. If you find a bug and crash some browser, it's not a big deal. If you find some problem in LSE that can be triggered from outside, you're dealing with realworld $M transactions.
Also, unless you have a huge farm of servers it would be useless to you - and basically anyone really.
Re: LSE Halts
#25Earlier quoted context omitted.
If the LSE were using F# we'd have heard a lot more about it already. For instance, from Microsoft.
Maybe not if they were using F# on mono. Their PR would have to work very hard to put this in a way that doesn't say "LSE is using our language on a foreign platform using a completely alternative implementation, which has nothing to do with us apart some ECMA specs - and they're still successful without MS involvement. Yes, we just confirmed that you can trust your highly critical .NET environment to the alternative…
OK, I wouldn't expect an official press release like this from Microsoft head office.
But the team in Microsoft Research are (a) keen to promote their language (people like Don and Brian often help early adopters personally) and (b) supportive of Mono (they've always released a .zip file for Mono at the same time as their Windows installers).
Re: LSE Halts
#26Earlier quoted context omitted.
F# on linux?
Via mono. If that's true... that would be an interesting news for the project (not because of the bug itself of course...).
using a immature language (f#) over unproved software stack for an international multi billion dollar low latency transactions when there are dozens of proven highly stable functional alternatives that run well on a linux platform? I can hardly believe it
Re: LSE Halts
#27Where is the fail over? If ever a system needed 99.9999...
Failover in this scenario would require instant, 100% replication of a near-zero latency system.
I'm no expert, but I'm fairly sure having trades 'disappear' or any other loss of consistency would be worse than downtime in this case.
Re: LSE Halts
#28Earlier quoted context omitted.
Via mono. If that's true... that would be an interesting news for the project (not because of the bug itself of course...).
using a immature language (f#) over unproved software stack for an international multi billion dollar low latency transactions when there are dozens of proven highly stable functional alternatives that run well on a linux platform? I can hardly believe it
That's modern enterprise computing for you.
Re: LSE Halts
#29Earlier quoted context omitted.
If the LSE were using F# we'd have heard a lot more about it already. For instance, from Microsoft.
Maybe not if they were using F# on mono. Their PR would have to work very hard to put this in a way that doesn't say "LSE is using our language on a foreign platform using a completely alternative implementation, which has nothing to do with us apart some ECMA specs - and they're still successful without MS involvement. Yes, we just confirmed that you can trust your highly critical .NET environment to the alternative…
They have publicly stated that the system is written in C++ on Suse Linux.
http://www.computerworlduk.com/news/open-source/3260727/lond...
Re: LSE Halts
#30"And as a final note, solely for the seriously nerdy techies, there's been some talk about the failure being due to F# error." http://ftalphaville.ft.com/marketslive/
I still don't understand how they choose languages with garbage collection for systems that should be real time or similar.