London Stock Exchange dumps Windows for Linux

No real time java used

In stock exchanges, no real time java is used. Instead you make sure that garbage collection is never triggered. You allocate lots of objects in the beginning and reuse them. Never create new nor dispose old.

India to repeat the mistakes committed by London Stock.

India to repeat the mistakes committed by London Stock Exchange.

India is going to issue id-card to all citizens (more than 1 billion) will require HPC, much more computing power & reliability than required by LSE. The platform that will be used is the same used for London Stock Exchange. LSE learned it the hard way and correcting the mistake by migrating to Linux.

This Indian project is given to to Infosys, effectively the project will be Microsoft + Infosys like LSE's Microsoft + Accenture.

Infosys Like Accenture uses only MS technology (non open standard)

Attributes of this Project should be:

HPC OS Platform :
Linux, Linux, Linux...

Application :
Custom designed application following all open standards (w3, HTML-5, ODF, .pdf, .png, .ogg ...). (no vendor lock in).
(all the source code will under control of India).

Hardware :
High performance cluster Hardware.

Vendors:
Any company(s) that is expert in the above deployments, Like IBM, SUN, Redhat, Oracle... etc.
(None of Microsoft proxies.)

If the India does not learn London Stock exchange example, this Indian project is Doomed to be a failure for its choice of platform.

Vinod Raghavan

I agree there are from time

I agree there are from time to time outages in various components, but as the systems are designed in a high available way, these outages have, or should have, no impact.
If they do have impact, which also happens, they can be resolved in a very short time.

With the Microsoft system, there were some single point of failures in the design, so it was not completely HA, and this is what happened earlier.
Because of the architecture, these SPOFs could not be resolved.

Sub millisecond delays are perfectly achievable, and is actually a requirement for brokers, as it is a huge disadvantage to have delays.

There is a reason why your 20Mb/s broadband connection at home is sometimes 100x cheaper than a "professional" 1Mb/s connection: delay.
Adding speed is very easy, removing delay isn't.

Offcourse, a Microsoft TCP stack, is quite notorious for introducing a huge delay. Other platforms, like Linux, can actually work much faster, i.e.: Real-time (Not the default kernel, but there are patches for a real-time kernel.)

Because Linux and all of its components are open-source, it means you actually DO have control of all stacks and memory management, not just "buying some time" as you say.

Further more, the system was actually implemented by Microsoft themselves, and even they couldn't get it to work as designed/required. So it would be very stupid NOT to move away from it.

I think you are a Microsoft fanboy with no real life experience and enjoy spreading FUD when other people have good reasons for avoiding Microsoft software.

Not sure where things got

Not sure where things got mixed up, but "buys you time" refers to the fact you can tweak anything you want without having to wait for MS to send you a patch. As for the other comments on SPOF, Microsoft TCP stack, who developed the system etc, that just shows your ignorance. If their design/code was flawed, that has nothing to do with the OS; the same outage would most likely have happened on any OS (a "life experienced" person such as yourself would know that the same code running active-active would probably crash at the same time on both sites depending on the nature of the bug or environment config.) Accenture designed, built, and implemented the system, not Microsoft. Whether the TCP/IP stack on Windows is or was notoriusly bad is irrelevant, as today you wouldn't use it for low latency apps anyway. In any case, for this type of system you can't beat linux in the back-end simply because you need to extract as much juice as possible from the hardware, and that implies complete control of the whole stack.