UK's CASH POINTS to MISS Windows XP withdrawal date Tens of thousands of ATMs will be running Windows XP long after Microsoft’s deadline to abandon the operating system ahead of a potential hacker storm. Just a third of the UK’s 60,000 ATMs will be upgraded from Windows XP before the end of this year, according to the biggest supplier of those machines - NCR. But it will be 8 …
"Most customers are looking at this with some reluctance because they don’t appreciate being driven to a decision by Microsoft. They want to work to their own dates."
Maybe they should have thought of that before deciding that it was good idea to use XP as the base for their cash machines.
Maybe they should have thought of that before deciding that it was good idea to use XP as the base for their cash machines.
A while back most were running OS/2.
Worth a read that article if only for the amusing gems:
"Already there have been four incidents in which Windows viruses have disrupted networks of cash machines running the Microsoft operating system.
But banking experts say the danger is being overplayed and that the risks of infection and disruption are small."
and
"But IBM will end support for OS/2 in 2006 which is forcing banks to look for alternatives."
"Maybe they should have thought of that before deciding that it was good idea to use XP as the base for their cash machines."
Well, what other choice was there? OS X? That'd only accept cards from AppleBank and take a 30% cut of any withdrawals.
Linux? Even worse. Can you imagine all those people trying to use a command line to do their business?
> withdraw 100
Error: You have insufficient funds
> sudo withdraw 100
OK
The only choice was, and remains, Windows for ANY device that has to be used by the non-techy general public.
Based on the number of people that seem capable of operating phones based on the Linux kernel, I'd say the tailored user interface obviates any concerns about the ability of the man on the street to use the bash/csh/X11/etc/whatever stack usually associated with 'Linux'.
That being said, I suspect Windows was chosen because it comes with good security support most of the time with the cessation of support having been hand waved away. The Linux guys are very good at updating the kernel but then who's responsible for pushing that to the machines? And the XP support period has beaten any of the commercial Linuxes by quite a stretch.
To be honest, the OS X quote and Linux jokes were quite funny, but when I read;
>>The only choice was, and remains, Windows for ANY device that has to be used by the non-techy general public.
I realised that you were not joking, just look at the number of Android phones out there and you can see that this is untrue. Open sources and command-lines are available, but you don't have to use them, it's a bit like the gay marriage argument, you can support it without actually having to marry someone of the same sex.
On the other hand, you have exactly the same problems with Linux, for example. How many of the distributions available in 2002 are still getting support today? You'd have to update and test much more regularly with Linux than with XP, 12 years without having to move on...
If they had started using Windows 7 based machines to replace the XP machines back in 2009, then this wouldn't be such a problem and the banks have known since 2010 that they would have to replace the XP machines by now, so if they haven't had a plan in place to replace Windows XP with Windows 7 (or another platform) when repairing or replacing existing terminals (and 100% for new locations), then they only have themselves to blame.
But of course, these machines don't need to be internet connected, they should be running on a separate intranet from everything else, so there shouldn't be a problem, unless somebody hacks the machines locally or can somehow attach to that network segment. Of course the banks are following best practices in security, aren't they?
I was working for a "large bank of Scotland" in 2009 and I'm pretty sure that I say Windows 7 running in our ATM test labs. I didn't deal directly with ATMs, but I worked directly with the guys that did. That said, I know that the problem they had updating from NT4 was mainly down to spec - most of them only had 64 megs of RAM, so couldn't really run XP or later.
Debian and Suse might run on the same hardware, but each release is only supported for a couple of years, which either means they would have been running without security updates for the best part of a decade or the banks would have to retest and roll out complete new versions of the system every few years, that would probably cost more, in terms of manpower, than buying a Windows license every decade or so.
That's not true at all.
SUSE offers SUSE Linux Enterprise (Server,Desktop,POS,SAP, etc) with 7 years of support. If you pay extra, it can be supported for up to 10 years. There's even a stripped-down version of SLE for Point-of-Sale machines. See http://www.suse.com/sles
On the free side of things, most LTS/Stable releases should get at least 3 years of security updates.
Check your facts first.
Maybe they should have thought of that before deciding that it was good idea to use XP as the base for their cash machines.
Actually, it was cheaper up-front. Any idiot can install Windows and whip something up in VB6.
And there are plenty of idiots in this world. 90% of PC owners, by the looks of it.
According to Microsoft's own Product Support Lifecycle pages, XP Embedded continues on Extended Support until the first Patch Tuesday in 2016:
http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=windows+xp&Filter=FilterNO
Everything else (Home, Media Centre, Tablet, Pro, x64 etc) goes EOL next month.
My thoughts exactly. Surely a device with restricted functionality and a very basic UI shouldn't be running a desktop OS, or even something like XP Embedded. I'd have though something like an ARM microcontroller coded directly in C be up to the job? It'd be far less vulnerable to attack and probably cheaper too.
ATMs do far more under the hood than you think. The UI isn't minimal, it has to be fairly rich these days because it has to comply with the DDA. There are touchscreens, custom printing, cash counting hardware, card readers, hardware encryption modules, sound cards (well, chips), network stacks, loads of stuff. All this stuff has to support remote control and remote update, it's well out of the realm of C coded microcontrollers.
@AC
Not exactly true.
I just finished coding an embedded system with a graphical screen including touchscreen, a full web interface with IP stack, all kinds of special motor control hardware, a full command line interface via USB virtual comm port, and a FAT file system for the SD card. All of this runs on an 8-bit microcontroller with 32KB RAM at 32MHz and fits into about 100K of flash. No OS. All hand coded (a lot of it in assembler).
Those of us "old guys" that grew up coding on 8-bit computers can build real system with very little hardware behind it. These days it seems coders think they need 2GB of RAM and a 3GHz dual core with a full OS to print "hello world"!
An ATM machine could certainly be built with a thin embedded Linux on an ARM processor. Personally I would consider that overkill, but the cost of that kind of platform is so low now, why not?
Those of us "old guys" that grew up coding on 8-bit computers can build real system with very little hardware behind it.
True (and I doff my hat to you for that) but how long does it take you? It's a serious question and I'm not at all trying to denigrate you but I suspect the reason you are in the minority is because your 'modern day' compatriot could build the same thing in less time. It'd need more hardware and resources but that's rarely a problem - they've usually caught up before you've finished the project. Not only in time spent coding but the time required to acquire the required knowledge is an expense. These days the costs tend to be in the wetware/software rather than hardware so for most businesses hand crafted code is just too expensive.
On the plus side of course this all means you probably get paid more than most of us :)
@AndrueC
I built this system, working on it part time, in about two weeks. Debugging took another three days. My day job is not embedded programming, this was just a side job. The argument that real code takes too long is just complete BS.
I do Windows development for my day job (and no, the pay isn't that great). I have several friends the are .Net programmers, and I doubt they would write a similar piece of code for Windows that much faster.
My first computer was an Ohio Scientific C1P. It had a 1MHz 6502 and 4K of RAM. I learned to program on this system. These days, new developers learn on Pentium class PCs with gigs of RAM and multicore processors. Younger developers just give me a blank stare when I tell them about my first computer. I still have it, bye the way! I was so excited when I upgraded to an Atari 800. I didn't know what I would do with all of that power!
Bruce
ATMs do far more under the hood than you think
I read the OP as meaning something more like a Raspberry Pi than (say) an Arduino. I happened to think the same thing myself when reading the article. Let's go through your complaints ...
UI isn't minimal
So what? You can build a UI in X or on the console. Button presses can be registered directly through GPIO or perhaps that part of the system can communicate over USB (pretending to be a keyboard)
touchscreens
A bit tricky, but I've seen Pis with attached touchscreens.
custom printing
No different from "printing". Hardly difficult.
cash counting hardware, card readers
Which are no doubt separate modules. Pi has several options for communicating with them (USB, SPI, I²C or a bit-banged GPIO interface).
hardware encryption modules
I don't know where these come in, so I can't comment except to say that if they're external devices then the same interface options are available as for cash counting/dispensing and card reader modules.
sound cards (well, chips)
Pi has on-board sound capabilities.
network stacks
Built-in, as is the ethernet port on Model Bs.
has to support remote control and remote update
Last I checked, Pis can run sshd.
it's well out of the realm of C coded microcontrollers.
I suppose it's where you draw the line. Maybe (only maybe) it's more than an Arduino can handle, but I'm sure a Pi is more than enough. I do see some problems with it, but I don't think any of them are insurmountable. For example:
* SD card failure
* not very tamper-resistant (service engineer could swap out SD card or entire Pi easily)
* may need custom circuits (or something like a Gertduino:) to offload some hardware-related tasks (eg, provide an I²C interface for an exotic crypto chip)
Hell, at the price point, you could afford to have several Pi (at least 3) systems all connected internally in a network in the box and build a fault-tolerant, self-checking system. Even accounting for custom hardware, it should totally be possible to build this thing for peanuts compared to the XP boxes. I'd be a lot more confident in the security of the thing, too,
How do I plug my hardware crypto cards into a rPI, or any other microcontroller come to that?
How do I run a properly secure filesystem on a microcontroller?
How does an rPI (of which I am a big fan) even start to run at the speed required?
Why would I program up a whole load of microcontrollers, or use linux on microcontrollers when I already have the OS and drivers available for Windows (and yes, Linux too, should my bespoke app have been coded for that) on the existing hardware and have the benefit of knowing that all those bits of the software stack will work and I don't have to employ OS/microcontroller specialists in my banking business.
Just following up on this because I think all your questions are valid.
How do I plug my hardware crypto cards into a rPI, or any other microcontroller come to that?
If it's supplied on a PCI card, then you're probably screwed. I simply don't know what sort of crypto hardware goes into these things. It begs the question, though, of what algorithms the thing is implementing, and whether it's based on open standards or whether it's just provided as a black box by some supplier on a "trust us, it's secure" basis. I think it's been shown time and time again that security through obscurity doesn't work, so if you can't get your supplier to give details of the encryption that's implemented or provide a board that can work over I2C or something else that the Pi/microcontroller can handle then there is something seriously wrong and the question of whether the ATM is built around a PC architecture or not is probably the least of your worries.
How do I run a properly secure filesystem on a microcontroller?
For read-only stuff, microcontrollers can be inherently secure as stuff is stored in ROM. On ARM platforms, there is a thing called TrustZone, that's intended to harden the boot process and make the machine more secure from tampering or running unauthorised code/OS. The Pi doesn't make use of this, as far as I know. It can, however, use the standard Linux crypto modules to provide for transparent encryption of all the filesystems it uses. I'm not too sure how useful this will be in an ATM, say, as opposed to a laptop or desktop PC. For the latter, for the security to be effective, you need a user to enter a password at boot time to access the disk. You obviously can't do that in an ATM that's intended to run unattended. I'm sure there's some way to make this work (such as the service engineer typing in the password after every boot, or some sort of challenge-response protocol done between the ATM and the bank's network where the Pi has to prove that the SD card hasn't been tampered with before getting the token required to securely boot off it---something like that). In any event, I'm not sure how vital boot security is on the machine when a service engineer can probably find ways to subvert it anyway. As for secure storage of logs, you can use the standard encrypted filesystem modules or use public key crypto to store sensitive details (so that the Pi can write the log data, but not read it back).
How does an rPI (of which I am a big fan) even start to run at the speed required?
Sure, why not? I mean, an ATM is basically like a kiosk or vending machine. It only has to handle one transaction at a time, and the UI stuff is pretty simple. Even if you want a complicated, flashy UI, have a look at what the Pi can do with xbmc. It's pretty impressive (and xbmc is a bit of a dog, so you could build something that's even more responsive).
The only (non-user) interface problem that the Pi might have is that it's not real-time, so it's not very suited for communicating with hardware that requires a low-level, bit-banged interface. So that's why I suggested you might need to offload this to a microcontroller or daughter board. (Microcontrollers have features that let you do this a lot easier, by triggering interrupts when interface lines change state, plus they're inherently real-time since they don't run a preemptive OS).
Why would I program up a whole load of microcontrollers, or use linux on microcontrollers when I already have the OS and drivers available for Windows (and yes, Linux too, should my bespoke app have been coded for that) on the existing hardware and have the benefit of knowing that all those bits of the software stack will work and I don't have to employ OS/microcontroller specialists in my banking business.
If you were talking with your banking friends, I don't doubt that this argument would go down quite well, even though I think it's erroneous (for reasons I'll get to anon, anon). This is a tech site. We're encouraged (and encourage others) to think about how things work "under the hood". The fact that you seem to be opposed to this (and don't seem to be giving any technical reasons why the XP solution is "better") is probably why you've been getting so many downvotes.
But anyway, I see two main problems with your argument for sticking with the status quo. First, there's the software side. Granted, if your app is making calls to a proprietary device driver, and you go and change the underlying hardware, then you will need to make changes. But (two big "buts"): (a) your software should already have been written in such a way as to separate business logic from hardware details, so to make it work on the new platform, you should only need to rewrite your interface library, and (b) If you're not writing portable code, then you're doing something terribly wrong, so I assume that porting the business logic won't be a significant problem. I'm assuming that the way you interface the ATM with the outside world is done via text-based command consoles (or similar, like SNMP), so all your external management software should continue to work. If you've got a dependency on something like using Windows RDP to manage the machines, then again, I think you're doing something seriously wrong. (plus: ATMs catching windows malware? wtf?)
Second, on the hardware front, I wonder if your complaint about needing microcontroller specialists is a bit of a red herring? By that I mean, do you actually even have the in-house competence to build and/or tinker with the PC/XP-based architectures that are in the current ATMs? I'm sure that building ATMs is a pretty lucrative business for those engaged in the market, and I also suspect that they simply provide black boxes and the banks have to take it on trust that the internals really work the way they say they do. I may be wrong on that, but even if you do have internal hardware expertise (not just developers that can code to the supplier's APIs) then I don't see how using open, off-the-shelf components (like Pis and Arduinos) is in any way inferior to the PC-like/XP platform.
Since it is a niche market, of course there will be a need for some bespoke (thought not necessarily proprietary) modules, such as for the card reader, though I'm sure there are enough applications for this that there are COTS hardware modules available. In fact, with the exception of your hardware crypto module (which I strongly feel should be based on open, rather than secret, protocols anyway), I don't see why the whole platform shouldn't be based on open, freely-available components. So if you do feel like you need hardware expertise, building the custom boards to connect all of these together should be child's play to any half-way decent electronic engineer. That's why I think that your comments about needing hardware expertise is probably a red herring.
Sorry for the length of the post. I hope my comments were useful :)
Who the fuck are they joking with ?
Do they really think we're going to believe that those ATMs haven't already paid for themselves a hundred times over ?
An ATM is one less bank teller to employ, is open 24/7, in all weather, all year 'round, especially when the bank tellers are not available. If banks had to employ an actual person for that, it would cost them a lot more.
That investment got its return the year after its installation.
Not a valid excuse. An habitual one, to be sure, since banks are always whining about costly their operation is, but once again the bonuses of top management tell the true story : they're rolling in dough and don't know what to do with it.
They do know what they won't do with it though : use it wisely.
I came here grinning evilly and planning a series of targetted sploits against XP boxes that could get me free money and ended up upvoting your post instead.
I shall now either mend my ways or wait until the good sense drains away, the project mangler is on my back again and the evil seeps back in.
I think you're missing the point - I happen to work for a financial institution - and happen to know that we never even break even on our atm's - don't forget that the 40,000 is only the purchase price - it doesn't include the costs of servicing an maintaining the atms. The cost of having a money service company coming out every day to add money, check deposits, process deposits etc all adds up. That doesn't include the back end "switch" and network charges. The atm's need to be connected to an industry standard "switch" and associated networks - otherwise it's nothing but a big computer - and those are in most cases third party systems and have their own share of costs.
The only reason we even put them in is the convenience of our clients - so that they can do banking after hours....
And something that the article also fails to mention is the exorbitant cost that NCR is charging for the upgrades. If the atm can be upgraded (and not all models can) it costs $5000 to upgrade if the main core doesn't need to be replaced. If they need to replace the main core the cost doubles (though why it should double when a decent pc is only 500-600 is beyond me) to $10,000. When you compare this by the number of atm's out there, the costs are huge....add in the costs for the switch providers to certify with the latest version of the software, migrate all the custom screens etc over to the new version and the costs rise even higher....
Having said all of that, it's always bothered me that all atm manufacturers decided to go with windows to as their chosen OS - I have yet to find a single atm manufacturer that provides a full service atm that doesn't run on some flavour of windows....
Joe User
Of course, they don't factor this in. Their calculation only includes costs and profits. Had they ever heard of opportunity costs and hence factoring in risk as well, they propably wouldn't have arrived in the deep shit where they landed.
My account is ATM/internet only. If I walk into a branch ( having driven there because they closed my local one) they won't talk to me. So the ATMs are definitely saving the cost of over the counter services:Otherwise they wouldn't have these ATM only accounts.
"No, it's so you actually have any customers."
Actually, in our case most of our members seem to prefer a live experience. We are actually expanding our teller line in several locations as contrary to popular belief people seem to enjoy talking with people rather than using a machine if at all possible....I know it's a strange concept in this age where young people don't even seem to know what a phone is much less how to actually call a friend....
Whatever it is we're doing, we seem to be doing it right as we're seeing a huge uptake on our services and phenomenal growth as people realize we're not one of the big banks with some unknown shareholders reaping the profits but a credit union that actually shares it's profits back with it's members....
The cost of the machines ought to be written off as an operating cost, possibly against the marketing budget. Since they are an essential service that any high street bank must run, the cost of running them is automatically covered by the profit made from the customers, many of whom wouldn't look twice at a bank that didn't have them. If the personal banking arm profits, then the machines have done their bit.
They pay for themselves by allowing the bank to continue to have customers, so calculating the pay-back by comparing material outlay to time saved by human tellers and such is immaterial.
'Course, I'm not naive, I know anyone in any kind of management position would look at me like I was insane, but there you go.
I'm guessing banks chose Windows because of their choice of running OS/2 on earlier ATMs. WinNT is after all a breakaway "pirated" OS/2 so it's possible that Windows would be able to run most of the OS/2 software without a problem. Also, at least until Win2000, NT had an OS/2 subsystem and that might help as well.
Me? I would've probably gone down a hardened Linux route, or simply gone down an even safer route with QNX.
OK, we can all agree that banks are rolling in dough, especially with all that top heavy QE.
So instead of complaining about Automated Teller Machine suppliers being bloody awful, why not
a) Use your absolutely enormous and all-consuming leverage to tell them you need the product to run on a free, secure, slim OS.. or..
b) Finance a startup that creates the Automated Teller Machine you desire. Heaven knows there are enough people that could use a job about now.
Oh come on! The retail banks do nothing for the "convenience of their customers". ATMs are a dirt cheap alternative to tellers and would never have been installed in the first place if it here had not been a bomb proof financial case.
Banking is essentially a very simple business, and current accounts are the simplest bit of all (finding vast fields in the west of Ireland which you can value at the same as Canary Wharf or lower Manhattan is a skill only idiots in Scottish banks mastered).
Annual cost of teller in bank, salary, pension, benefits, training, desk, building, heating, lighting other overheads, maybe 100,000gbp, cost or ATM electricity, gbp 200, maintenance, Gbp500, depreciation, let's be really generous, 5000.
Yeah, it's all about "customer convenience"
"The only reason we even put them in is the convenience of our clients - so that they can do banking after hours...."
The only reason we even put them in is so we can lay off more front-desk staff and incorporate the money that would have been used for their salary into our executive bonuses fund...
FTFY
If you work in banking, you have singularly failed to understand it.
You are providing that service to people who are giving your bank a callable loan at well-below the market interest rates that larger enterprises and financial institutions themselves would expect.
"The PCI DSS states operating systems must be protected against known vulnerabilities using vendors’ latest security patches."
Big Banker 1: "But the vendor is no longer producing security patches. Therefore we remain compliant indefinitely."
Big Banker 2: "Great thinking! Large bonuses all round!!"
That was exactly my thought when it comes to the updates. Technically they are compliant.
Also:
* It's not as if Windows XP will suddenly become more vulnerable than it is now.
* These systems run a modularised version of Windows XP with as much of the crud as is possible uninstalled or, in the worst cases, disabled. I have configured and deployed Windows XP like this as it is rock solid and the number of vectors for external attack is minimal. For example, you're vulnerable on the fundamental IP networking stack and your own application listening on this.
* These systems are individually firewalled to control the incoming and outgoing routes of data.
As for why XP? Because of the ease of development and the advantages a "mature" OS brings when it comes to the level and depth of device drivers. While a more restrictive OS would generally provide more security, given that there could be dozens of printer variants to support, dozens of card readers, dozens of screens and so on, separating the application and the device through the OS is the right way to go.
Windows was never intended as an industrial OS (ATM's would probably qualify as industrial, harsh environment, long service life etc)
There are other OS's out there with better security, support and licensing options, and I don't just mean the various flavours of Linux.
But companies like NCR go for windows because there are lots of Dev's out there with windows experience, and the inbuilt UI cuts down on some of the development time. Plus they can now charge their customers for brand spanking new ATM's rather than just upgrading the old ones.
Its the banks own fault for not specifying a more suitable OS and feature roadmap for these devices.. no sympathy at all.. just annoyance that the cost will be passed on to joe bloggs public yet again.
The really stupid part is that those skills are equally valid on Windows Embedded, the unit price for the OS is lower, the maintenance overhead is lower and the support term is longer by at least two years.
But no... a chance to save a quick buck on the original hardware trumps all.
"Windows was never intended as an industrial OS"
Windows CE and Windows XP Embedded would tend to indicate that you don't have a clue what you are taking about...
"But companies like NCR go for windows because there are lots of Dev's out there "
No, they go for the lowest TCO. Money is what matters at the end of the day.
"There are other OS's out there with better security, support and licensing options, and I don't just mean the various flavours of Linux."
Good, because commercial / enterprise Linux is generally worse on all counts there.
This post has been deleted by its author
Basically, because the first thing that happens in a bank is that they remove the software from the ATM and put their own ATM build onto it. Really, all the banks are interested in is the drivers. The banks mainly use Windows because of the excellent remote management offered which isn't/or wasn't until recently available for Linux. The other issue is that the cost of an OS licence like XP is vanishingly small in comparison to the ongoing support costs of the hardware, beit form a technical support point of view, a physical support pov or the day to day feeding and watering of the machines.
Re: SCCM + SCOM
Yes, SCCM + SCOM were really good products compared to similar Unix offerings, particularly given what MS included for the price. As many companies began to use these tools to manage their growing Windows desktop estate, many objected to effectively rolling out a similar system - but with a bigger ticket price, just for the Unix servers, even if it was technically superior.
I suspect that for many companies now, if they were to go non-MS on the desktop they would continue to use SCCM + SCOM ...
"The banks mainly use Windows because of the excellent remote management offered which isn't/or wasn't until recently available for Linux."
You're joking, aren't you? All UNIX derivatives, including Linux, have had "remote management" capabilities for a decade before even DOS existed! And it's also why most banks actually use AIX, Solaris, Linux in their server stacks instead of Windows. Even AD is basically a pirated implementation of LDAP and Kerberos5. And before that we had NIS and NFS. What the Windows world was barely achieving in the late 90's/early 00's was already standard in the UNIX world!
All UNIX derivatives, including Linux, have had "remote management" capabilities for a decade before even DOS existed!
Point of order:
Linux didn't exist until a decade AFTER the first release of DOS. DOS was 1981, Linux didn't exist until 1991.
You're also getting a little overzealous with the word "pirated" there. As far as I can tell, Microsoft has always complied with the BSD license, and even if they were not, they had a fully paid license of SysV for Xenix.
Linux didn't exist until a decade AFTER the first release of DOS. DOS was 1981, Linux didn't exist until 1991.
So I assume you didn't read the full statement you yourself quoted:
All UNIX derivatives, including Linux, have had "remote management" capabilities for a decade before even DOS existed!
UNIX is the one that has had remote management since its inception, which dates back to 1970 (probably earlier). Linux got it since it was born due to being a UNIX derivative as well. Windows had to have the remote management stuff added later, and even then it had to be changed at least once from the proprietary thing they had on NT4 and earlier to the LDAP/Kerberos5 thingy they made in Win2000.
UNIX is the one that has had remote management since its inception, which dates back to 1970 (probably earlier). Linux got it since it was born due to being a UNIX derivative as well. Windows had to have the remote management stuff added later, and even then it had to be changed at least once from the proprietary thing they had on NT4 and earlier to the LDAP/Kerberos5 thingy they made in Win2000.
That is rewriting history to a certain extent. The earliest Unix systems were strictly host based. Your only remote capability of any kind would have been by hooking a modem to a tty - hardly a feature of the operating system. The first Unix to include networking support was 4.2BSD in 1983 and it took to the late eighties to propagate around the various workstation/server variants. Xenix, which is where the volume was back then, got it in 1987 and even then it was an optional extra with additional licensing fees. That continued until the OS was phased out completely in the mid 90s.
Yes, I did read the full statement, It clearly says that Linux had remote management when Linus Tovalds was 2 years old. I may have known what you meant, but I did use the pedantic grammar nazi icon.
Linux got it since it was born due to being a UNIX derivative as well.
Wow, there is so much wrong with this statement.
1) Linux is not a UNIX derivative. It is an original work. This was settled in SCO v. IBM (et al.)
2) You can't have had something since before you existed. I didn't have brown eyes before I was conceived just because my parents did.
"Linux got it since it was born due to being a UNIX derivative as well."
Wow, there is so much wrong with this statement.
1) Linux is not a UNIX derivative. It is an original work. This was settled in SCO v. IBM (et al.)
1. If the term "UNIX-like" was used, would that have validated the point, or would you find another straw man to attack?
2. The design of Linux derived from UNIX
3. Denis Ritchie described it as a UNIX derivative
4. Linux is de-facto UNIX.
2) You can't have had something since before you existed. I didn't have brown eyes before I was conceived just because my parents did.
Linux has remote management, because the design was based on UNIX - which had remote management.
"All UNIX derivatives, including Linux, have had "remote management" capabilities for a decade before even DOS existed!"
Sorry to disappoint you, but rlogin et al doesn't count for much when you have 10,000 plus Unix boxes to remotely administer. Yes there were and are fantastic proprietary enterprise management systems for Unix - I know I used to sell one in the late 80's and early 90's as part and parcel of all large Unix deployments I designed. No many use Microsoft products because of the GUI and bundled toolset and ease of recruiting skilled people, remember one of the big reasons against DB/2 on Windows was it's lack of a GUI admin tools and wizards, the fact it was probably a superior DBMS to SQL-Server wasn't even a consideration for many customers.
ummm - hate to break it to you but that is most definitely not the case.
The ATM manufacturer provides the ATM with the base OS and a certain version of core atm software that interfaces with the various devices. The banks then connect to that base config using their own software (the "switch") and load their configuration, states, screens and relative functionality on top of that....
Whatever version of ATM software that comes with the base unit is industry standard and has passed various certifications in order to be useable. The banks then have to certify their driver application (otherwise known in the industry as the switch) to actually interface with the base os and ATM software and then to load their custom states and screens and final software on top of that. The final software (along with the states and screens and "switch" ) must also pass certification and validation using industry standards....
"= more profit in the long term as they don't need to include a Windows XP licence in with the cost of the machine"
Because it generally costs less to run Windows. Easier to manage, easier to integrate with, fewer security patches to evaluate / deploy than a Linux distribution, no need to employ a team to write / compile the OS, long support lifetime, etc. etc.
I'd be more worried about this bit:
Physical attack is an option: NCR’s newest self-service ATMs have a USB slot for engineers, but NCR reckons this is an encrypted slot that’s hard to access.
'Hard to access'. So that's OK then. Except that 'hard to access' hasn't really been defined.
http://www.bbc.co.uk/news/technology-25550512
If the need to drill holes is the same thing as 'difficult' in their minds then we're all screwed...
> Maybe it's an upside down one.
Wouldn't work - everyone knows that to plug in a USB plug you have to rotate it twice through 180 degrees to get it to go in. Mounting the socket upside down would just reduce the rotations by one.
What it needs is to be mounted at 90 degrees.
The "encrypted USB slot" is actually a normal USB slot. The difference is that in order to reach core diagnostics you need to have a specially encrypted usb key that the software check against - if it sees that there's a valid encrypted usb technician key in the slot, then and ONLY then will it enable access to certain core functionality and diagnostics.
Now truthfully, if you've got physical access to the machine in order to plug in this key, this security option is mainly a moot point as you can always break the default config....
Under normal circumstances, people do not see any of the windows boot screens etc as that's all blocked in the hardware. There are ways around this but it's not something that most people or techs know....
Many appliances were driven by Windows XP, and an ATM is just another kind of appliance. I'd bet NCR would love the banks to buy shiny new ones, but then how would they manage the production spike. It really does make sense to only replace these devices when they break, as they are in the main on closed networks.
It's also not very environmentally friendly to dump vast numbers of perfectly serviceable machines, just because they can't run Windows XP.
Be careful on this. MS likes to fuck with you.
https://www.microsoft.com/windowsembedded/en-us/product-lifecycles.aspx
XP Pro for Embedded System (Which is what these devices are using, we have to deal with this also) is only supported through April 8 2014, with its distribution being longer. Windows Embedded Toolkits and Runtimes are all supported through 2016.
If they are not connected to Internet and Users are not installing applications why does it matter?
Loads of stuff even running DOS, Win 3.11, Ancient pre 2000 Linux, OS/2, Win98, NT4.0, Win2K etc simply running. Nothing is ever updated or installed, nor is it networked.
If we are talking manager's and Office PCs on Internet it's more of a story, but even then may have no issues depending on configuration.
"Just look at cash point machines, for instance. Queues of people standing around waiting to have their fingerprints read, their retinas scanned, bits of skin scraped from the nape of the neck and undergoing instant (or nearly instant – a good six or seven seconds in tedious reality) genetic analysis, then having to answer trick questions about members of their family they didn't even remember they had, and about their recorded preferences for tablecloth colours. And that was just to get a bit of spare cash for the weekend."
Banks don't have customers or clients; they have prisoners. When I started work 42 years ago, you were paid cash weekly in a brown envelope with no need for a bank account. I know of quite a few friends who have landed a job, and been 'let go' two weeks later because they could not get a bank account due to all the document action and references required, so they could actually be paid for hard graft. My personal account gives me nothing, no overdraft, no interest, zilch. I get paid, take my money out and that is it. So 'financial institution assistants', please stop moaning about necessary costs that will obviously affect your bonus...
The banks are some of the biggest, if not the biggest, MS I.T. spenders around. I do recall in the past a bank I worked for had a special not made public support arrangement with M.S. over certain legacy systems. I suspect they must have something similar in the pipeline. As big spending customers they have too much leverage for M.S. to piss them off.
A text mode screen is illegal under the disability discrimination act. Also, OS/2 is not as secure as (certainly by modern standards) you seem to think is was. I very much doubt that you'd be able to install OS/2 on modern hardware, there have been many fundamental changes to the PC's architecture since OS/2 was released.
HSBC upgraded the cashpoint in my local branch last year. The new generation machine also seems to run on XP according to its display after a crash one day quite recently, but this "better than ever before"super whizzy machine lacks one basic banking function that the old one had. The ability to pay in some cash out of hours. When I mentioned this to the branch they seemed unable to grasp the fact that this was a problem.
The biggest laugh was when the hapless teen behind the counter told me that registering with telephone or internet banking should see me able to carry out all the normal banking functions - she was however stuck for an answer when I asked how the hell one paid in cash over the interwebs - and commented that even the smallest denomination note wouldn't fit through the mic aperture in my smartphone.
What a bunch of bankers!
To leave an ATM running software that will have exploits released? All it takes is one to have been nicked at some point and the right team and you've got a year or so to hack ATMs the land over.
And the crims have known when this date was going to happen for a long time.
Never really give ATM's much thought besides the usual look for dodgy face plates / skimmers and only ones on the side of the bank protected by a camera.
After having my memory refreshed about OS/2 running on these things I never thought for a moment that anyone in their right mind would use XP for something that needed to run 24/7.
So for all the MS bashing above, I'll say this.. 99.9% of the time I go to use an ATM it's working , no error messages and the best technology is the stuff you don't notice, so for that , well done NCR and Microsoft.. Who would have thought...
I have no bias as to what OS they use, just as long as I can get my beer tokens on the way to the pub.
..... if I ever suffer the unfortunate event of some toerag emptying my bank account. Bank says I let them see my pin, I now have the C&P terminals do not encrypt my pin as it is entered as well as unsupported OS cash machines.
Can anyone confirm if Barclays is one of the institutions with XP cash machines? It's likely as their secured mail service has just told one of my users that IE 11 is unsupported and suggested IE6 or Firefox 1.5 until I enabled compatibility.
But the main reason for the banks not upgrading is simple, there isn't a bonus in it for anyone.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
