 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On 10/27/2010 8:55 AM, Jim Henderson wrote:
> On Tue, 26 Oct 2010 16:19:29 -0700, Patrick Elliott wrote:
>
>> Support? Oh, you mean, "Turn it off, wait 30 seconds, and turn it on
>> again. Unless the web service the kiosk is "actually" running from is
>> down, this should fix it (well, at least for a few days...)"
>
> It's always a little more involved than that when it comes to a kiosk.
> Sure, fixing the kiosk is easy, fixing the kiosk in the context of a
> larger infrastructure is more involved.
>
> I think it's fair/safe to say that ATMs are not stand-alone devices, but
> rather that they're connected into a network and thus "support" involves
> more than just "turn it off, turn it on" if the problem is device support
> or network support.
>
> Jim
Probably true, for some of that stuff. My own experience with
kiosk/kiosk like things has been bloody Windows XP running "cash
registers" and IE running "info" kiosks. The problem is almost
invariably standard Windows. Device is too stupid to realize something
is wrong, there is no simple reset for it, the software is buggy enough
something *will* go wrong, not just might, and the only way "solution"
given is to hope once a year that they patch the problem, or cold start
the damn things.
--
void main () {
If Schrödingers_cat is alive or version > 98 {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On 26-10-2010 21:45, Orchid XP v8 wrote:
>> I used to be a part-time bank teller when I was in university and I have
>> had to help people figure them out.
>>
>> Granted, they were older people who were not accustomed to technology
>> and were afraid the machine would steal their money.
>
> Hmm, I may have missed a step: How about a telephone? It's not a
> computer, but it sort of talks to one. How many people can't work a
> telephone?
>
> (Working an iPhone is another matter, of course...)
obligatory quote:
"I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out how
to use my telephone." Bjarne Stroustrup
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On 27/10/2010 5:15 PM, Darren New wrote:
>> When did you meet my wife?
>>
>
> Well, to be fair, the guy had been living on a tropical island for 15
> years, so it wasn't really surprising. (Actually, it was surprising,
> since he had said he'd lived with his wife in Australia for a while. It
> took me some time to realize it must have been before the invention of
> cell phones.)
My wife is a Luddite. ask her about HiFi and she will tech you under the
table but computers... I've been trying to teach her about "copy and
paste" for more than ten years. (What is the emocion for "my head hurts"?)
--
Best Regards,
Stephen
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On 10/27/2010 5:52 AM, Francois Labreque wrote:
>> On 26/10/2010 07:56 PM, nemesis wrote:
>>
>>> BTW, at least in Brazil a large percentage of ATM machines are Linux
>>> underneath.
>>> How about that for ease of use? ;)
>>
>> Wikipedia asserts that many newer ATMs run Windows - which would be
>> extremely disturbing if true...
>>
>
> Older ones used to run OS/2 2.1. The newer ones mostly run Windows 2000
> or XP. In some cases, you can even see the Thinkpad inside when they are
> being refilled with money.
>
> I've seen one reboot and execute a bunch of .BATs to upgrade stuff while
> trying to get money for a cab at Prague's airport. Very scary!
>
I don't know.. DOS might actually be "more" reliable than some of these
newer OSes, which where never intended for single purpose machines,
without multitasking needs.
--
void main () {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On 27/10/2010 05:12 PM, Darren New wrote:
> Invisible wrote:
>> writing a few dozen lines of assembly to
>> function as a device driver would be pretty trivial...
>
> And you would be right, were we living in a universe where people
> building hardware spent *their* money so you could spend less of *your*
> money.
I'm not sure I follow...
By not using exorbitantly-priced MS products, they can sell their device
significantly more cheaply. You would think that would be a fairly
compelling market advantage.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Invisible wrote:
> On 27/10/2010 05:12 PM, Darren New wrote:
>> Invisible wrote:
>>> writing a few dozen lines of assembly to
>>> function as a device driver would be pretty trivial...
>>
>> And you would be right, were we living in a universe where people
>> building hardware spent *their* money so you could spend less of *your*
>> money.
>
> I'm not sure I follow...
>
> By not using exorbitantly-priced MS products, they can sell their device
> significantly more cheaply. You would think that would be a fairly
> compelling market advantage.
No. The guys making the coin changer, etc, having to support *both* Windows
and Linux costs more than supporting just Windows. I imagine if someone came
to them and said "We'll buy 50,000 of these if you provide a Linux driver"
then they would have done so. But those 2 dozen lines of assembly, along
with all the other stuff that goes with it (like maintenance, sales,
marketing, tech documentation, recompiling it for each kernel as necessary,
etc etc) costs money and apparently wasn't worth doing.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
>>>> writing a few dozen lines of assembly to
>>>> function as a device driver would be pretty trivial...
>>>
>>> And you would be right, were we living in a universe where people
>>> building hardware spent *their* money so you could spend less of *your*
>>> money.
>>
>> I'm not sure I follow...
>>
>> By not using exorbitantly-priced MS products, they can sell their
>> device significantly more cheaply. You would think that would be a
>> fairly compelling market advantage.
>
> No. The guys making the coin changer, etc, having to support *both*
> Windows and Linux costs more than supporting just Windows. I imagine if
> someone came to them and said "We'll buy 50,000 of these if you provide
> a Linux driver" then they would have done so. But those 2 dozen lines of
> assembly, along with all the other stuff that goes with it (like
> maintenance, sales, marketing, tech documentation, recompiling it for
> each kernel as necessary, etc etc) costs money and apparently wasn't
> worth doing.
Oh, right.
I was thinking more along the lines of "if the device you want to use
doesn't have Linux drivers, just write some".
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Orchid XP v8 wrote:
> I was thinking more along the lines of "if the device you want to use
> doesn't have Linux drivers, just write some".
And indeed you could do that, if doing so would cost less than just buying
Windows for your machine. Remember that there might be 3 or 4 devices that
only have Windows drivers: bill taker, coin changer, receipt printer,
touchscreen, etc.
You, as a manager, can say "Is it worth $75/machine to try to reverse
engineer these devices in a way that
1) they work reliably
2) they don't spit money randomly back to the user
3) it keeps working even when the manufacturer changes something,
4) and get it working by the time we need it?"
Tell me, if I handed you a piece of hardware with no documentation other
than how to invoke the Windows device drivers, how long would it take you to
reverse-engineer the Linux driver for it the first time? How long after the
manufacturer changes something and updates the Windows driver before you
know something is broken in your Linux driver?
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On 28/10/2010 07:22 PM, Darren New wrote:
> Orchid XP v8 wrote:
>> I was thinking more along the lines of "if the device you want to use
>> doesn't have Linux drivers, just write some".
>
> And indeed you could do that, if doing so would cost less than just
> buying Windows for your machine. Remember that there might be 3 or 4
> devices that only have Windows drivers: bill taker, coin changer,
> receipt printer, touchscreen, etc.
>
> You, as a manager, can say "Is it worth $75/machine to try to reverse
> engineer these devices in a way that
>
> 1) they work reliably
> 2) they don't spit money randomly back to the user
> 3) it keeps working even when the manufacturer changes something,
> 4) and get it working by the time we need it?"
>
> Tell me, if I handed you a piece of hardware with no documentation other
> than how to invoke the Windows device drivers, how long would it take
> you to reverse-engineer the Linux driver for it the first time? How long
> after the manufacturer changes something and updates the Windows driver
> before you know something is broken in your Linux driver?
Well, you'd think that the code to operate something as trivial as a
coin counter would be very simple. But sure, I take your point.
I guess the real question is "why are people manufacturing devices that
will only ever be used as part of an embedded system writing drivers for
it that won't work as part of an embedded system?"
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Orchid XP v8 wrote:
> Well, you'd think that the code to operate something as trivial as a
> coin counter would be very simple. But sure, I take your point.
Well, no. There's interrupts, sensors saying how many coins are there, to
signal when it's out of coins or has been filled incorrectly, timing delays
for releasing various coins, dealing with power going out and coming back on
while the mechanism is operating, etc.
Everything's trivial if you aren't the one writing the code.
> I guess the real question is "why are people manufacturing devices that
> will only ever be used as part of an embedded system writing drivers for
> it that won't work as part of an embedded system?"
Except it *is* a driver working as part of an embedded system, obviously.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|
 |