"When choosing between two evils, I always like to try the one I've never tried before." (Mae West)
Well, this can be generalized to choosing between several evils. That would mean choosing WP for a lot of folks, I suppose... But what's scary is, choosing WP doesn't scare me any more.
So what is average/worst case access time for that tape cabinet? For BD, I don't know at all, but I guess for BD it is some tens of secs including disk change and spin-up. Perhaps much less with hardware optimized for this.
If that data needs to be accessed from web, then I think some tens of seconds maximum acceptable.
I don't know about your practical experience on server side Javascipt, but a lot of the comments like yours sound like you're thinking of client side Javascript, with parts embedded in a HTML page, and hacked together by a non-programmer designer.
Server side Javascript is nothing like that.
Or if it's the Javascript syntax you're allergic to, that's a solved problem (with Coffeescript or Typescript).
But G+ does not have my friends there, nor does it have an official app for my phone (and I'm not about to enter my Google credientals on some 3rd party app). I don't see it really taking off until Google stops using it as marketing ploy.
Of course they may also shut it down any time with a warning of a few months, even if it seems a remote possibility now...
You are needlesly introducing multiple reference frames. Here there's just on that is relevant: ours. If event happened 12 million light years away, it also by definition of speed of light happened 12 million years ago, when we see the light. When observing photons in vacuum, distance and time are same thing. "Now" would mean "here", and I don't feel the heat, so inverse square law must be in effect, which implies distance, which implies time.
You are trying to argue common sense against a tide that has been moving for decades. If you do it on the bare metal then you cant program it in Java or.net etc. My experience of using ATMs is that banks have pretty poor programmers - pretty poor interface programmers at least - they need things to be simple and easy.
You say the reason here yourself: availability of employees or contractors who can do what needs to be done. Or if it's not availability, then it's the ability tell one who can do it for you from one who'd like to learn it at your expense. It may be dull, but it is a real-world constraint, and common sense ignoring real constraints is not common sense.
I guess you could blame the teaching of management. A manager can't manage or decide something (such as hiring somebody with certain skillset), if they don't even know about it.
Thanks for the links. However, I bet the TCP/IP stack is not really a full implementation (I did not find the code so couldn't look at it). It's just a hack, a cool one but still a hack. If it was production-quality software package, it wouldn't be a project at a hacking site. The work going from a hack into a product you can sell to a bank is a long one. Also, parts availability is one thing, and adapting the software to a new HW like that can be rather more involved, and selecting the right components with availability of years into a future is a special skill too.
Another point, if it could be done cheaper that way, I bet it would have been done so in this free market economy. A startup might have appeared, offering that kind of solutions built on top of embedded HW, instead of an embedded PC with a PC OS. Going beyond ATMs (which probably have a bunch of entrenched suppliers and unfun regulations), are there any such products/companies?
JavaScript was the "hot" back-end technology about 4-5 years ago. At that time, most devs have concluded that it's not so hot after all.
FTFY
The real-world use of Javascript in backends 4-5 years ago was quite different from its use today. So any conclusion drawn "at that time" 4-5 years ago is not trustworthy today, and anybody clinging to that old conclusions is in the wrong field. You might still come to essentially same conclusion today, but it would have to be a conclusion from today's state of things, not state of things 4-5 years ago.
Actually, if you want to be accurate: no, it is not a simple calculation, due to the metric expansion of space and all...
I don't want to be accurate to that degree. There's no point. The expansion at 12 million light year scale is who knows how many orders of magnitude less than the accuracy of our best measurements of the distance.
Since no information can travel faster than light, for all intents and purposes and discussions of causality it is happening right now. Since we are just entering its light cone, anything outside of it is inaccessible to us - and always will be.
Well, if you argue that, you have to give up concept of distance, or concept of speed of light. From our frame of reference, light traveled certain distance at certain speed, and simple calculation will tell how long time it took.
Or to put it another way, when you receive reflection of light you sent to a mirror, neither sending nor reflecting happened when you received the reflection back. It is in fact possible to determine distance of mirror by knowing how long ago sending and reflecting happened.
So, what has taken the place of "hot" rising web backend tech from Javascript / node.js?
Also, I think node.js is the first really mature(ish) JavaScript web server, and first release was less than 5 years ago, and integration of package manager was later still, which I consider a requirement for "hotness" on anything which depends on extensibility through modules. So your timeframe of 4-5 years is off no matter how you look at it.
These days, Javascript is the hot backend technology, which is convenient when it's also the leading (and only future-proof) front end technology of its type (programming language).
Seriously, if you have not already, give node.js a spin if you do any Internet-related development work. And I don't mean anybody should necessarily start using it, just that it is something to know today.
Record cold? We didn't get snow until the middle of January, and there's still just like 10 cm of it here, and coldest it has been so far is -20 Celsius. Though I predict one or two usual cold spells will reach us from Siberia still, it'll not be very cold winter, unless indeed there will be climate chaos and we'll have winter shifted by a month or two. If there's a warm spell first and current snow melts, it might actually be pretty bad for wildlife, cold but not much snow... Let's hope not.
On the other hand, check out the record cold summer down under in Australia (see, they're down there, so higher temperature reading means it's colder).
In case it makes you feel less guilty, consider that those cows buy their existence with their milk (and meat as by-product by biological necessity). Would you rather put domesticated cows out of existence, make them nearly extinct? I doubt they would be replaced by wildlife on this world ruled by humans, either.
Lately I have been noticing that my FHD laptop screen is too narrow, especially when debugging, and often having 2 documents side-by-side is important (say, looking at diffs, or coding in spec details). I rarely feel any need to see vertically more. OTOH I find it very painful to work without proper mouse wheel for scrolling (a free-wheeling one found ay least in many Logitech models), this might explain something.
My point is, not everybody finds the 16:9 aspect ratio particularly bad. Lucky me, I guess.
I have not really worked on bare metal, unless you count MSDOS as such (and I guess you can, BIOS is not unlike a library, and raw IO was how things like audio were done).
But, I have just had the "pleasure" to work with an embedded device with a custom OS (if you want to call it that) for running single multi-threaded application. The company that built the OS is the global leader in that device segment. And this "OS" demonstrates why not using an actual OS is bad, if you do something as complex as networking or whatever. Most coders are not up to it. Most SW architects are not up to it. Most project managers have no clue what they should enforce in a project like that. Even if you do have the right people now, you may not have or find them in 2 years. And asking HR to find them, good luck with that.
I say, let either proven OS companies,or proven open source OS communities create the OS for you. Doing bare metal, it's better be tiny and trivial (no networking or encryption protocols etc), or you'd better have extreme requirements (spacecraft or such) and budget to match, or you're just asking for trouble sometime after next downsizing cycle.
Why does this matter? Surely the ATM machines are not in the public internet, or the regular internal network of the bank? Surely they are firewalled from each others too, so compromising one can't compromise the others?
They're embedded systems, in isolated environment. Once they work, why do they need OS support (other than updates to software when protocols and company logos change)? And if they do need OS support now, it'd be better to just change the network infrastructure so that they no longer need it.
The thing is, that touch screen is damn cheap. Replacing it with discrete components would be expensive. And a screen needs,a,computer to drive it.
And then,the whole thing about talking to server, it's,done over IP or similar complex network, and needs a computer. Cheapest and most scalable place to put that part in is right there in the ATM machine.
And software glitches have the nice property of staying fixed once fixed, and fixes being easy to distribute (at least if system is well designed). Once software works in a given environment, it will keep working, until there is a mechanical or electrical glitch... So it's natural to want to minimize mechanical and purely electrical parts.
I think it's been empirically proven in many places and time periods, that it is actually quite feasible to kill tens of millions of people by starvation without there being a mass uprising. It just takes some propaganda to keep people not noticing what is happening, enough time to make the starving people weaker slowly, and finally taking the necessary measures to force them to stay put in their designated death zone and deal with any minor violent protests swiftly and decisively.
Something about Google today makes me want to run to Microsoft's arms. At a time I even entertained the idea of working (well, seriously applying) for Google, when life situation would allow relocating. But something has gone sour, like milk. First there was just something in the taste, now it seems there are clumps in it already. Wave. Reader. Insistence of linking everything together in ways I am not comfortable with. This. Soon Scholar?
Who in their right mind is going to make any kind of investment (of time and effort) into any of Google's future stuff? Not me.
Java could have been fixed when they found out that their sandbox execution back in the early 2000's had so many holes that it made a sieve look like a glass. And by fix, I mean nuke it from orbit and rebuild it from the ground up instead of issuing bandage after bandage, on something they knew was already a mess.
Coulda Woulda Shoulda...
It's interesting how technical debt has interest, sometimes so high you can only keep doing the equivalent of "pressing more money" and see where that takes you (as if everybody didn't know).
What is telling is, JRE installer from Oracle keeps pushing ask.com toolbar (borderline malware) with underhanded tactics (check box checked by default, re-checked for updates, and hidden behind changing install directory from default). Business is business, sure, and I wouldn't want something this dirty anywhere near my business...
Java, one of the worst things to happen to computing, ever.
Nah, I doubt anything would be much better, if they were in position Java is now. If it were native code, anybody without the sources would be screwed, now only anybody with Java6 requirement and no sources to fix it is screwed (but they were the moment their software got tied to specific JRE6 version). If it were.net instead of Java, when do you think MS would get around to patching Linux versions? If it were some scripting language... ok, it couldn't be: duck typing is too fragile, performance is problem, no serious contenders for many (not most, but many) Java use cases.
In absence of Java, maybe something really better would exist now, but I very much doubt it. It's a paradoxical package deal.
You should ask yourself, why would Google want your business, when your use case is what it is, and when you have the requirements you have?
Perhaps you should pay them. Of course with your experience, you're not likely to, but you were not likely to before, either. Lost or badly handled sales opportunity for them, I suppose.
Well, the next step is obvious, we ban killing human combatants, and remove weapons from human combatants. Then it will be one robot army against another, and the remaining robots of the winning side will occupy the territory. Ideally the robots could support virtual weapons and an agreed protocol for negotiating hits, so that virtually destroyed robots would just power down and be later collected as prisoners of war. People could just go about their daily lives, while a robotic war would rage around them.
Slashdot Mirror
"When choosing between two evils, I always like to try the one I've never tried before." (Mae West)
Well, this can be generalized to choosing between several evils. That would mean choosing WP for a lot of folks, I suppose... But what's scary is, choosing WP doesn't scare me any more.
So what is average/worst case access time for that tape cabinet? For BD, I don't know at all, but I guess for BD it is some tens of secs including disk change and spin-up. Perhaps much less with hardware optimized for this.
If that data needs to be accessed from web, then I think some tens of seconds maximum acceptable.
I don't know about your practical experience on server side Javascipt, but a lot of the comments like yours sound like you're thinking of client side Javascript, with parts embedded in a HTML page, and hacked together by a non-programmer designer.
Server side Javascript is nothing like that.
Or if it's the Javascript syntax you're allergic to, that's a solved problem (with Coffeescript or Typescript).
But G+ does not have my friends there, nor does it have an official app for my phone (and I'm not about to enter my Google credientals on some 3rd party app). I don't see it really taking off until Google stops using it as marketing ploy.
Of course they may also shut it down any time with a warning of a few months, even if it seems a remote possibility now...
You are needlesly introducing multiple reference frames. Here there's just on that is relevant: ours. If event happened 12 million light years away, it also by definition of speed of light happened 12 million years ago, when we see the light. When observing photons in vacuum, distance and time are same thing. "Now" would mean "here", and I don't feel the heat, so inverse square law must be in effect, which implies distance, which implies time.
You are trying to argue common sense against a tide that has been moving for decades. If you do it on the bare metal then you cant program it in Java or .net etc. My experience of using ATMs is that banks have pretty poor programmers - pretty poor interface programmers at least - they need things to be simple and easy.
You say the reason here yourself: availability of employees or contractors who can do what needs to be done. Or if it's not availability, then it's the ability tell one who can do it for you from one who'd like to learn it at your expense. It may be dull, but it is a real-world constraint, and common sense ignoring real constraints is not common sense.
I guess you could blame the teaching of management. A manager can't manage or decide something (such as hiring somebody with certain skillset), if they don't even know about it.
Thanks for the links. However, I bet the TCP/IP stack is not really a full implementation (I did not find the code so couldn't look at it). It's just a hack, a cool one but still a hack. If it was production-quality software package, it wouldn't be a project at a hacking site. The work going from a hack into a product you can sell to a bank is a long one. Also, parts availability is one thing, and adapting the software to a new HW like that can be rather more involved, and selecting the right components with availability of years into a future is a special skill too.
Another point, if it could be done cheaper that way, I bet it would have been done so in this free market economy. A startup might have appeared, offering that kind of solutions built on top of embedded HW, instead of an embedded PC with a PC OS. Going beyond ATMs (which probably have a bunch of entrenched suppliers and unfun regulations), are there any such products/companies?
JavaScript was the "hot" back-end technology about 4-5 years ago. At that time, most devs have concluded that it's not so hot after all.
FTFY
The real-world use of Javascript in backends 4-5 years ago was quite different from its use today. So any conclusion drawn "at that time" 4-5 years ago is not trustworthy today, and anybody clinging to that old conclusions is in the wrong field. You might still come to essentially same conclusion today, but it would have to be a conclusion from today's state of things, not state of things 4-5 years ago.
Actually, if you want to be accurate: no, it is not a simple calculation, due to the metric expansion of space and all...
I don't want to be accurate to that degree. There's no point. The expansion at 12 million light year scale is who knows how many orders of magnitude less than the accuracy of our best measurements of the distance.
Since no information can travel faster than light, for all intents and purposes and discussions of causality it is happening right now. Since we are just entering its light cone, anything outside of it is inaccessible to us - and always will be.
Well, if you argue that, you have to give up concept of distance, or concept of speed of light. From our frame of reference, light traveled certain distance at certain speed, and simple calculation will tell how long time it took.
Or to put it another way, when you receive reflection of light you sent to a mirror, neither sending nor reflecting happened when you received the reflection back. It is in fact possible to determine distance of mirror by knowing how long ago sending and reflecting happened.
So, what has taken the place of "hot" rising web backend tech from Javascript / node.js?
Also, I think node.js is the first really mature(ish) JavaScript web server, and first release was less than 5 years ago, and integration of package manager was later still, which I consider a requirement for "hotness" on anything which depends on extensibility through modules. So your timeframe of 4-5 years is off no matter how you look at it.
These days, Javascript is the hot backend technology, which is convenient when it's also the leading (and only future-proof) front end technology of its type (programming language).
Seriously, if you have not already, give node.js a spin if you do any Internet-related development work. And I don't mean anybody should necessarily start using it, just that it is something to know today.
Record cold? We didn't get snow until the middle of January, and there's still just like 10 cm of it here, and coldest it has been so far is -20 Celsius. Though I predict one or two usual cold spells will reach us from Siberia still, it'll not be very cold winter, unless indeed there will be climate chaos and we'll have winter shifted by a month or two. If there's a warm spell first and current snow melts, it might actually be pretty bad for wildlife, cold but not much snow... Let's hope not.
On the other hand, check out the record cold summer down under in Australia (see, they're down there, so higher temperature reading means it's colder).
In case it makes you feel less guilty, consider that those cows buy their existence with their milk (and meat as by-product by biological necessity). Would you rather put domesticated cows out of existence, make them nearly extinct? I doubt they would be replaced by wildlife on this world ruled by humans, either.
Lately I have been noticing that my FHD laptop screen is too narrow, especially when debugging, and often having 2 documents side-by-side is important (say, looking at diffs, or coding in spec details). I rarely feel any need to see vertically more. OTOH I find it very painful to work without proper mouse wheel for scrolling (a free-wheeling one found ay least in many Logitech models), this might explain something.
My point is, not everybody finds the 16:9 aspect ratio particularly bad. Lucky me, I guess.
I have not really worked on bare metal, unless you count MSDOS as such (and I guess you can, BIOS is not unlike a library, and raw IO was how things like audio were done).
But, I have just had the "pleasure" to work with an embedded device with a custom OS (if you want to call it that) for running single multi-threaded application. The company that built the OS is the global leader in that device segment. And this "OS" demonstrates why not using an actual OS is bad, if you do something as complex as networking or whatever. Most coders are not up to it. Most SW architects are not up to it. Most project managers have no clue what they should enforce in a project like that. Even if you do have the right people now, you may not have or find them in 2 years. And asking HR to find them, good luck with that.
I say, let either proven OS companies,or proven open source OS communities create the OS for you. Doing bare metal, it's better be tiny and trivial (no networking or encryption protocols etc), or you'd better have extreme requirements (spacecraft or such) and budget to match, or you're just asking for trouble sometime after next downsizing cycle.
Why does this matter? Surely the ATM machines are not in the public internet, or the regular internal network of the bank? Surely they are firewalled from each others too, so compromising one can't compromise the others?
They're embedded systems, in isolated environment. Once they work, why do they need OS support (other than updates to software when protocols and company logos change)? And if they do need OS support now, it'd be better to just change the network infrastructure so that they no longer need it.
The thing is, that touch screen is damn cheap. Replacing it with discrete components would be expensive. And a screen needs,a,computer to drive it.
And then,the whole thing about talking to server, it's,done over IP or similar complex network, and needs a computer. Cheapest and most scalable place to put that part in is right there in the ATM machine.
And software glitches have the nice property of staying fixed once fixed, and fixes being easy to distribute (at least if system is well designed). Once software works in a given environment, it will keep working, until there is a mechanical or electrical glitch... So it's natural to want to minimize mechanical and purely electrical parts.
I think it's been empirically proven in many places and time periods, that it is actually quite feasible to kill tens of millions of people by starvation without there being a mass uprising. It just takes some propaganda to keep people not noticing what is happening, enough time to make the starving people weaker slowly, and finally taking the necessary measures to force them to stay put in their designated death zone and deal with any minor violent protests swiftly and decisively.
Something about Google today makes me want to run to Microsoft's arms. At a time I even entertained the idea of working (well, seriously applying) for Google, when life situation would allow relocating. But something has gone sour, like milk. First there was just something in the taste, now it seems there are clumps in it already. Wave. Reader. Insistence of linking everything together in ways I am not comfortable with. This. Soon Scholar?
Who in their right mind is going to make any kind of investment (of time and effort) into any of Google's future stuff? Not me.
Java could have been fixed when they found out that their sandbox execution back in the early 2000's had so many holes that it made a sieve look like a glass. And by fix, I mean nuke it from orbit and rebuild it from the ground up instead of issuing bandage after bandage, on something they knew was already a mess.
Coulda Woulda Shoulda...
It's interesting how technical debt has interest, sometimes so high you can only keep doing the equivalent of "pressing more money" and see where that takes you (as if everybody didn't know).
What is telling is, JRE installer from Oracle keeps pushing ask.com toolbar (borderline malware) with underhanded tactics (check box checked by default, re-checked for updates, and hidden behind changing install directory from default). Business is business, sure, and I wouldn't want something this dirty anywhere near my business...
Java, one of the worst things to happen to computing, ever.
Nah, I doubt anything would be much better, if they were in position Java is now. If it were native code, anybody without the sources would be screwed, now only anybody with Java6 requirement and no sources to fix it is screwed (but they were the moment their software got tied to specific JRE6 version). If it were .net instead of Java, when do you think MS would get around to patching Linux versions? If it were some scripting language... ok, it couldn't be: duck typing is too fragile, performance is problem, no serious contenders for many (not most, but many) Java use cases.
In absence of Java, maybe something really better would exist now, but I very much doubt it. It's a paradoxical package deal.
You should ask yourself, why would Google want your business, when your use case is what it is, and when you have the requirements you have?
Perhaps you should pay them. Of course with your experience, you're not likely to, but you were not likely to before, either. Lost or badly handled sales opportunity for them, I suppose.
Well, the next step is obvious, we ban killing human combatants, and remove weapons from human combatants. Then it will be one robot army against another, and the remaining robots of the winning side will occupy the territory. Ideally the robots could support virtual weapons and an agreed protocol for negotiating hits, so that virtually destroyed robots would just power down and be later collected as prisoners of war. People could just go about their daily lives, while a robotic war would rage around them.