 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
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
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
> Everything's trivial if you aren't the one writing the code.
Well, that's true enough.
>> 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.
More specifically, given that Windows should never, ever, under any
circumstances, be running on a single-function device like this, why are
all the device drivers being written for Windows?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Orchid XP v8 wrote:
> More specifically, given that Windows should never, ever, under any
> circumstances, be running on a single-function device like this, why are
> all the device drivers being written for Windows?
What would you run instead?
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
>> More specifically, given that Windows should never, ever, under any
>> circumstances, be running on a single-function device like this, why
>> are all the device drivers being written for Windows?
>
> What would you run instead?
How about just writing the few dozen lines of C is actually takes to
prod a few bits in the framebuffer, write some stuff on the screen, talk
to the card reader a bit, and make the dispenser chuck out some money?
OK, you're right, it probably *is* faster to take some code that
somebody else already wrote. But I still think grabbing the relevant
parts of (say) the Linux kernel is going to be quicker and easier than
porting the entire Windows OS (most of which you don't need) to a new
platform and trying to make it work...
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
> I met someone who didn't know how to turn on a cell phone just a couple
> years ago.
I'm pretty sure my grandmother wouldn't have a clue how to turn on my phone.
Also my gf's grandparents have never used an ATM.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Invisible wrote:
> porting the entire Windows OS (most of which you don't need) to a new
> platform and trying to make it work...
It's not a new platform. It's just a normal x86 computer.
--
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 10/29/2010 8:43 AM, Darren New wrote:
> Invisible wrote:
>> porting the entire Windows OS (most of which you don't need) to a new
>> platform and trying to make it work...
>
> It's not a new platform. It's just a normal x86 computer.
>
In this specific case, probably true, but then you have "phones" and
other things running this OS too.. Gosh, my phone has 2GB memory. Gee,
what apps do you have on it? Hmm, not much, I only have 200MB free, the
rest is Windows. lol
Ok, ok, its not *that* bad, but still.. ;)
--
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
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Patrick Elliott wrote:
> In this specific case, probably true, but then you have "phones" and
> other things running this OS too..
No you don't. The OS in the phones is not the normal Windows OS, any more
than your Droid phone is running Ubuntu.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|
 |