They should just go straight to Android - nice touchscreen drivers, 3G, that Dalvik thing - what more is needed apart from a few device drivers to spit the money out?
Bankers and ATM manufacturers ain't morons. They aren't using Windows XP out of ignorance. ATM's have been widely deployed in the US since about 1980 and it's the last version of Windows that runs old 16 bit code directly.
It is not as if banks have an aversion to Linux. What they are averse to is risk. Reimplementation requires testing for a level of robustness well to the north of MtGox. Multi-touch pinch to zoom doesn't matter- ATM's require physical buttons for handicap accessibility [by law in the US].
Disrupting banks isn't about ATM's. It's about new financial structures.
Moron is perhaps a harsh word but it's been known to the public when Microsoft will stop supporting Windows XP. They had years to prepare. And they are multi billion dollar corporations. How can they have dropped the ball with this?
Please show me the comparative risk analysis of sticking with XP after support ends versus rewriting an existing code base across fleets of machines that not only spit cash but are also hardwired into the electronic transfer systems.
I''ll stipulate that coming across as a brogrammer friendly workplace doesn't count.
I don't know, I'm just thinking of possible reasons. Same as in the good old NHS in the UK [1] and especially the comment at [2].
[1] http://www.theregister.co.uk/2014/03/20/doh_microsoft_nhs_on...
[2] http://forums.theregister.co.uk/forum/1/2014/03/20/doh_micro...
and
http://forums.theregister.co.uk/forum/2/2014/03/20/doh_micro...
Every single manager did a quick analysis, worked out that the upgrade would cost "Holy shit, how much of my budget?", and punted down the road in the hope that someone else would have to eat the cost.
And, Microsoft will probably extend support (for a big chunk of money) after the big companies scream enough.
If I would be into POS systems still they would be Android anyway. Makes all the sense in the world.
I'm an android fan.. But, I just don't see it for something like ATMs.
ATMs need physical buttons for disabled users, so the whole touchscreen thing is a no go. They need experienced, stood the test of time, companies to provide support over the 10-15 year lifetime. They need reliable and auditable source code, so the less code, the better. In other words, they need something that's not android.
The Linux kernel makes a lot of sense given these requirements, paired with a bare minimal userspace and graphics stack, they can likely make good on their existing hardware until it either ceases up or simply can't support new standards like Chip+PIN.
Does this mean it requires someone on site to boot the machine? I could see that might not be an issue for ATMs, as they are usually located near banks. It might be an issue for remote locations, though.
But you can actually just leave the entire sector write only, even on boot. This is what most embedded Linux systems do - the entire rootfs is read only, /tmp and the like are on a ramdisk, and only a small writable partition remains for things like logs. In fact, Linksys routers didn't even have a writable filesystem - they stored all their settings on a separate EEPROM.
Or use a turn-key switch. First put it into II, wait for the boot sequence to complete, switch back to I. Yes, that does require someone to be on site but that tends to happen anyway when someone restarts the ATM in the first place. If you want to update the software remotely, you could download it into ramdisk and run it from there. For the base system, you'll want something robust so it's more or less guaranteed to get to the point where you can manage it remotely. And you could verify the downloaded application bits against a locally installed root certificate.
The old MS-Windows-based ATMs may be rebooted daily, but let's face it, that's just because Windows. When the base system has to be updated for some reason, a service technician will have to physically replace the storage device for it. If that happens very often, they're either doing it wrong or I'd recommend against such a setup. But perhaps the vendor can charge for the service, in which case /care ;)
Or they could turn the key into II every last Monday of the month for example (the ATM would go into maintenance mode) at a certain time and let the big maintenance server do its work overnight, avoiding the situation altogether at the cost of a slightly greater risk that the machine becomes defective.
In any case, a tiny embedded OS would be perfect for the job.
[edit: I suppose things might be a little (but only a little wrt drivers) worse than I thought, given eg:
It does have some quirks when trying to use it with software designed for swiping in mind and a keyboard and mouse, but that's probably not going to be an issue here.
I say Android could be a good choice, and it will also give them a migration path from X86 should they later on want to.
Linux the kernel, I would say, to avoid ambiguity. And second, I'm not sure what you refer to when you say "extremely secure" but even Linux had its share of issues recently (GnuTLS library).
For offline equipments, not sure how likely they would be patched, though.
I agree that free software seems to be very much responsive to disclosed issues though, and while many vendors (perhaps especially Microsoft) have gotten a lot better lately, the image remains (rightly or not) that closed source companies move (too) slow when it comes to patching security issues.
(Part of that is quality control, patching one bug tends to introduce/expose more)