Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[W. Wayne Liauh]

One of my clients in Taiwan is doing Linux-based POS for China 
Petroleum.  This client is a very small company but China Petroleum is 
one of the Forbes 1000 companies in the world.  They have been doing 
that for about 2.5 years.  As I am told (actually they never tell me 
anything), things are going very well.


This client of ours also makes IDE thin-client cards with embedded Linux 
and flash to replace HD.


Based on the large number of posts, it is not difficult to detect that 
there are a lot of interests here in "thin-clients" and "POS systems".


Man, you don't need me to remind you:  This is our future.  I have been 
paying close attention to Linux since Red Hat 4.2, and I am fully 
convinced that timing couldn't have been better.  But the opportunity 
window could, and very likely will, pass by us.


I remember almost a score of years ago when I was working for Exxon in 
Houston, a University of Texas student came to our office trying to sell 
IBM clones that his company, "PC Limited", built (in his dorm) with 
components from Taiwan that are identical to what IBM uses.  At that 
time, it was unthinkable to buy a PC that was not built by IBM.  But his 
price/performance was simply too attractive.  One of my colleagues 
bought one for home use.  Eventually our department began purchasing his 
PCs, and he changed his company name to "Dell".   The rest is history.


Wouldn't it be great if we could repeat the history (somewhat) in Hawaii?!

Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[cpaul]

> huh?  The server software sends escape sequences to the terminal
> emulator to trigger printing.  Then the /local/ terminal emulator speaks
> to the /local/ printers.  why would port forwarding be necessary?

If I remember my CounterPoint crash course correctly...  CounterPoint has a 
spool file on the server that the remote clients print to.  

-- 
"The human brain is like an enormous fish - it is flat and slimy and has gills 
through which it can see." - Monty Python

GPG key: http://linefeed.org/~epsas/epsas.asc
(meow!): http://kuroneko.linefeed.org

Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[Ray Strode]

> > > SSH would be nice, but we would need to think of a way to secure the
> > > reverse (server to client) print connections too.
> > Port forward for lpd?
huh?  The server software sends escape sequences to the terminal
emulator to trigger printing.  Then the /local/ terminal emulator speaks
to the /local/ printers.  why would port forwarding be necessary?

--Ray

Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[Warren Togami]

On Fri, 2002-05-24 at 13:01, MonMotha wrote:
> 
> >>4) I know you will be needing SSH, and I assume OpenSSH most recent 
> >>unless you want otherwise.  The SSH needs to compile against uClibc.
> > 
> > 
> > SSH would be nice, but we would need to think of a way to secure the
> > reverse (server to client) print connections too.
> > 
> > 
> 
> Port forward for lpd?

That's the idea, but I have no clue how to do this for many cash
registers at the same time.

Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[MonMotha]

Warren Togami wrote:

On Fri, 2002-05-24 at 12:27, MonMotha wrote:

I looked through the description of your project, and I have a few 
questions, then I can get started building a floppy for you:


1) Do you want X11 or just a text console?  If X11, what video hardware 
will be on these (both monitor and video card)?



I am recommending text console only for the initial version.  Text
console would be easier to read and introduce less complications than
X11.  With X11 we would need to deal with stuff like video drivers,
monitor settings, fonts, and users accidentally minimizing the window
then blaming the computer thinking it is "broken".  (They currently do
that on the Win98 cash registers.)



Well, when you do decide to go X11, you could either use no window 
manager (if it's just one big window), or tell the WM to refuse to 
minimize that window if not remove the minimize command from the UI 
entirely (gotta love fvwm! :)




2) What kernel do you prefer?  2.0, 2.2, or 2.4.  Older kernels tend to 
be smaller, newer kernels support more nifty features.  I'm opposed to 
2.0 kernels, but will do either 2.2 or 2.4, whichever you prefer.



Either 2.2 or 2.4 would probably suffice.



Then I'll probably go with 2.4 since that's what I'm used to working with.



3) What kind of basic utils will you want?  I use busybox, so you can 
check out their site as to what is available, but I can also compile 
some stuff on my own (though space is limited of course) provided the 
app can be compiled against uClibc fairly easily.





We were thinking about using read-only IDE flash disks for these Linux
cash registers.  Far more reliable than floppies, and probably more
reliable than hard drives because there are no moving parts.  (Some of
the cash register locations had problems with overheatig.)  We can buy
sizes anywhere between 4MB-several GB so there is a lot of flexibility
in what we can do.  We need to figure out what size of smallest flash
disks we would need to buy without detracting from effectiveness.  The
flash disks should also leave some room to grow should we think of new
useful features to add to the system later. 
 



That would work fine, I just need to know a final size and if you want 
it compressed or not.


4) I know you will be needing SSH, and I assume OpenSSH most recent 
unless you want otherwise.  The SSH needs to compile against uClibc.



SSH would be nice, but we would need to think of a way to secure the
reverse (server to client) print connections too.




Port forward for lpd?


___
LUAU mailing list
[EMAIL PROTECTED]
http://videl.ics.hawaii.edu/mailman/listinfo/luau

Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[Warren Togami]

On Fri, 2002-05-24 at 12:27, MonMotha wrote:
> I looked through the description of your project, and I have a few 
> questions, then I can get started building a floppy for you:
> 
> 1) Do you want X11 or just a text console?  If X11, what video hardware 
> will be on these (both monitor and video card)?

I am recommending text console only for the initial version.  Text
console would be easier to read and introduce less complications than
X11.  With X11 we would need to deal with stuff like video drivers,
monitor settings, fonts, and users accidentally minimizing the window
then blaming the computer thinking it is "broken".  (They currently do
that on the Win98 cash registers.)

> 
> 2) What kernel do you prefer?  2.0, 2.2, or 2.4.  Older kernels tend to 
> be smaller, newer kernels support more nifty features.  I'm opposed to 
> 2.0 kernels, but will do either 2.2 or 2.4, whichever you prefer.

Either 2.2 or 2.4 would probably suffice.

> 3) What kind of basic utils will you want?  I use busybox, so you can 
> check out their site as to what is available, but I can also compile 
> some stuff on my own (though space is limited of course) provided the 
> app can be compiled against uClibc fairly easily.
>

We were thinking about using read-only IDE flash disks for these Linux
cash registers.  Far more reliable than floppies, and probably more
reliable than hard drives because there are no moving parts.  (Some of
the cash register locations had problems with overheatig.)  We can buy
sizes anywhere between 4MB-several GB so there is a lot of flexibility
in what we can do.  We need to figure out what size of smallest flash
disks we would need to buy without detracting from effectiveness.  The
flash disks should also leave some room to grow should we think of new
useful features to add to the system later. 
 
> 4) I know you will be needing SSH, and I assume OpenSSH most recent 
> unless you want otherwise.  The SSH needs to compile against uClibc.

SSH would be nice, but we would need to think of a way to secure the
reverse (server to client) print connections too.

Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[MonMotha]

I looked through the description of your project, and I have a few 
questions, then I can get started building a floppy for you:


1) Do you want X11 or just a text console?  If X11, what video hardware 
will be on these (both monitor and video card)?


2) What kernel do you prefer?  2.0, 2.2, or 2.4.  Older kernels tend to 
be smaller, newer kernels support more nifty features.  I'm opposed to 
2.0 kernels, but will do either 2.2 or 2.4, whichever you prefer.


3) What kind of basic utils will you want?  I use busybox, so you can 
check out their site as to what is available, but I can also compile 
some stuff on my own (though space is limited of course) provided the 
app can be compiled against uClibc fairly easily.


4) I know you will be needing SSH, and I assume OpenSSH most recent 
unless you want otherwise.  The SSH needs to compile against uClibc.


5) How will these systems be networked (need to know the exact network 
cards, or I can modularize it and write up a script to let you customize 
the disk)?  Will they be static IP, or dynamic?  via DHCP, BOOTP, RARP?


A normal compressed ramdisk is 4MB once decompressed off the floppy into 
ram, but obviously how much stuff can actually be fit onto it varies 
depending on the compression level achieved.  See my floppies I've 
already made for some hints as to how much space the bare minimum takes 
up at .  Obviously 
using a ramdisk uses up valuable system ram to hold the filesystem.


Another option is to skip the ramdisk completely and go with an NFS 
mounted root filesystem.  This has the advantages that you obviously 
have a lot more space as you don't have to cram everything onto the 
floppy and also allows the filesystem to be changed centrally without 
having to even reboot the machines, let alone update every single 
floppy.  However, it also requires a lot more network bandwidth as 
everything that touches the filesystem has to go over the network.  You 
also need to run NFS, which has been noted to have some security flaws 
(good ol' SUNRPC) in the past.


Yet another option is a hybrid; this is where initrd really shines.  I 
can have a tiny root filesystem load up off the floppy into an initrd, 
then load a root filesystem image into a larger ramdisk (size limited 
only by the amount of RAM in the machine really) by downloading it from 
the central server by, say, tftp before handing control off to this 
newly downloaded "real" root filesystem.  This method is really cool 
because it allows things like 20MB root filesystems (which you'd have 
trouble fitting on a floppy, even gzip compressed) without any of the 
overhead from running live via NFS.  The downsides are that is uses a 
lot of RAM (32MB MINIMUM for this) and that if you update the image on 
the server, the clients will need to be rebooted for the changes to take 
effect.


For an example of how initrd can be used, RedHat uses one to load up a 
minimum system to load kernel modules for bare minimum system hardware 
before actually booting the rest of the system.  This allows them to 
keep their kernels small and generic by modularizing almost everything 
and keeping the modules your system needs in an initrd image.


Depending on how much I need to do (X will take a while and I'll have 
major trouble fitting it on a floppy!), I might be able to get a basic 
working disk done in a day or so for you to start playing with.


--MonMotha

R. Scott Belford wrote:


On Thursday, May 23, 2002, at 08:27 PM, MonMotha wrote:

I actually have some of this hardware that I can use to test things on 
(a pole display on serial and a keyboard/barcode scanner wedge). 
However, I'm not really a UI programmer, but I can get the basic OS 
base down for you fairly quickly should you want me to.


--MonMotha



Many thanks for your offer.  My planned starting point is with your 
floppy.  For all I know at this point it will work fine.  When it 
doesn't, I'll start breaking down where I am and figuring it out.  It'll 
be fun.



scott

___
LUAU mailing list
[EMAIL PROTECTED]
http://videl.ics.hawaii.edu/mailman/listinfo/luau

Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[R. Scott Belford]

Ray, many thanks for this chewy chunk of knowledge.  Per Warren's request I
am going to re-post my overview in another, more specific thread, and I'll
respond there.

scott


- Original Message -
From: "Ray Strode" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 23, 2002 7:33 AM
Subject: Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers


> Hi Scott.
>
> > echo -ne "\\033\133\065\151"
> > cat $*
> > echo -ne "\\033\133\064\151"
> Okay, I looked these escape sequences up at vt100.net and they do
> exactly what you say they do.  The first one says, "terminal, please
..

Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[Ray Strode]

Hi Scott.

> echo -ne "\\033\133\065\151"
> cat $*
> echo -ne "\\033\133\064\151"
Okay, I looked these escape sequences up at vt100.net and they do
exactly what you say they do.  The first one says, "terminal, please
redirect everything I tell you to your printer instead of your screen"
and the last one says, "stop redirecting to the printer and go back to
directing to the screen".  I played around with xterm and .Xdefaults a
bit and got it to work.
The X resourses that are needed are:

xterm*printerCommand: lpr
xterm*printerAutoClose: true 

where lpr is the printing program.  Since these output devices are
basically just line printers we could probably construct our own custom
lpr program if needed.

  Are your linux register boxen going to be running X?  I checked
whatever version of the kernel source I have laying aroudn on my
hard-drive (console.c) and the kernel's console vt's don't appear to
support those particular escape sequences.  I don't think it would be
too terribly hard to add that feature to the kernel tho (it's all
grouped in a pretty easy to follow set of switch() statements). There
may already be a patch on the net somewhere, or it may already be in the
kernel in a non-obvious [for me] spot.  I'll do more investigating if
you like.

> In Counterpoint certain codes are defined for this type of pole display 
> that insert themselves in the lpt stream and send the right data to 
> the pole and the rest to the printer.  
Interesting.  What are those codes?  When I looked in the vt102 user
manual, I didn't see anything to support printer selection (probably
because real vt102's and the like only had at most one printer per
terminal).

> It is this pass through and local file configuration that I am 
> not certain about, yet, with a pure linux register.
Me neither.  If the sequence that specifies which output it's going to
comes after the print sequence then we can just have our lpr scan for
that sequence and choose accordingly.  If it happens before the print
sequence, then we'll probably have to patch xterm to support it.  If X
isn't an option at all, then we'll have to patch console.c in the
kernel.  

> I know it is doable, but I have not tried, period.
Yea I think we'll be able to get it to work.  Although, I'll admit that
I've never done anything like this before.

--Ray

Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[R. Scott Belford]

On Thursday, May 23, 2002, at 08:51 PM, Warren Togami wrote:

Please post the specifications of the current setup, so that we can
think of equivalent pieces with a pure Linux solution.


I wrote what I thought was a painfully specific description of the setup 
a few posts down.  The key word is thought,  Should I submit it as its 
own thread, or was it not really helpful enough?  I'll elaborate on as 
much as needed.


scott





___
LUAU mailing list
[EMAIL PROTECTED]
http://videl.ics.hawaii.edu/mailman/listinfo/luau

Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[Warren Togami]

On Thu, 2002-05-23 at 20:38, R. Scott Belford wrote:
> 
> On Thursday, May 23, 2002, at 08:27 PM, MonMotha wrote:
> 
> > I actually have some of this hardware that I can use to test things on 
> > (a pole display on serial and a keyboard/barcode scanner wedge). 
> > However, I'm not really a UI programmer, but I can get the basic OS 
> > base down for you fairly quickly should you want me to.
> >
> > --MonMotha
> 
> Many thanks for your offer.  My planned starting point is with your 
> floppy.  For all I know at this point it will work fine.  When it 
> doesn't, I'll start breaking down where I am and figuring it out.  It'll 
> be fun.
> 
> 
> scott

Please post the specifications of the current setup, so that we can
think of equivalent pieces with a pure Linux solution.

Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[R. Scott Belford]

On Thursday, May 23, 2002, at 08:27 PM, MonMotha wrote:

I actually have some of this hardware that I can use to test things on 
(a pole display on serial and a keyboard/barcode scanner wedge). 
However, I'm not really a UI programmer, but I can get the basic OS 
base down for you fairly quickly should you want me to.


--MonMotha


Many thanks for your offer.  My planned starting point is with your 
floppy.  For all I know at this point it will work fine.  When it 
doesn't, I'll start breaking down where I am and figuring it out.  It'll 
be fun.



scott

Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[MonMotha]

I actually have some of this hardware that I can use to test things on 
(a pole display on serial and a keyboard/barcode scanner wedge). 
However, I'm not really a UI programmer, but I can get the basic OS base 
down for you fairly quickly should you want me to.


--MonMotha

R. Scott Belford wrote:


On Thursday, May 23, 2002, at 06:19 PM, Warren Togami wrote:


On Thu, 2002-05-23 at 17:20, MonMotha wrote:


Yes, but SCO != Linux :)



Because SCO was/is a x86 Unix, most SCO binaries run with little or no
modification on Linux when you have the right libraries and Unix
compatibility kernel modules installed.  Scott can post more about this.



Yeh, from what I have learned about this program called Counterpoint 
that runs on Linux is that it does so through a "hack" of sorts.  If you 
are using Redhat's 6.2, then you must insmod iBCS in your rc.local file 
to be sure that the program runs.  In Red Hat's 7.2 distro, you must


insmod abi -machdep
insmod abi -svr4
insmod abi -cxenix
insmod abi -sco
insmod abi -ibcs
insmod abi uw7
insmod binfmt_coff
insmod binfmt_xout

I really don't know what it is doing, but it allows one to execute the 
POS application once they ssh in from a remote client.  I think some 
dealers use Slackware, and I suppose it would run on Caldera's flavor of 
SCO.  I never got it to work with debian or mandrake.



Our registers access this application through a private network.  A 
"register" is simply a pc in this case.  They connect to the remote POS 
application, Counterpoint, with a windows based telnet client.  We use 
Vandyke's, www.vandyke.com , CRT program.  Each register has a keyboard 
and scanner for input.In to the keyboard port plug the keyboard and 
scanner.  They share this port with a wedge or y-adaptor.  Keyboards 
have a credit card reader which is hardware programmed.  The scanner is 
also hardware programmed.  The telnet program doesn't care where the 
data comes from it just takes it from the port.  The POS application 
doesn't care what OS is used to access it and trade data.


Also attached to the pc are a monitor and parallel receipt printer.  The 
pole display, that thing on a pole that displays the price, works in 
pass-through mode on the parallel port.  It can also be plugged in to a 
serial port.


So, there you are at the counter and you want to buy some gum.  The 
cashier positions the cursor in the customer screen, asks your zip code, 
and then uses the keyboard to enter a stream of data matching your 5 
numbers.  The cursor is now positioned in the item entry screen.  The 
gum is passed over the scanner where its barcode is read.  This stream 
of numbers travels through the network, is compared to an inventory 
file, and a stream of data returns displaying big read for .25 on the 
cashiers screen.  At the same time, the price of gum has appeared on the 
pole display.  She scrolls down to the payment entry area, selects 
credit card, and swipes your card.  That stream of data is read from 
your magnetic strip and is passed through the network to the POS 
application.  Counterpoint engages one of the server's many modems and 
dials our processor for approval.  The approval is displayed on the 
cashiers screen a few seconds later, and the magic begins.


On the server end, peripheral devices can be defined.  That pole display 
showing the gum, let's say it was a serial port pole.  On the server 
end, a remote printer is defined where the pole is located.  In our 
case, because our register pc's run windows, that pole display is known 
to windows as a generic text serial printer.  It is shared.  We setup 
this remote windows printer on the server, usually name the queue with 
that register's number, and when the application gets your gum data 
stream, it knows to print the price data to the user defined printer.  
In this case it is a remotely shared windows printer.  It can easily be 
any printer.


This, so far, may not be too hard to replicate on a thin-client linux 
register.  Something else happens, though.  CRT, the windows telnet 
program,  is set up to pass through printing to lpt1.  When the cashier 
got your approval for the gum, she finished the transaction by printing 
a receipt.  When she printed that receipt, the printer was not defined 
the same way as the pole.  The printer in this case is a device defined 
in Counterpoint called local.  Local is a file in the top level of the 
Counterpoint, with 777 permissions but root ownership and root group.  
In the file are the following magical lines


echo -ne "\\033\133\065\151"
cat $*
echo -ne "\\033\133\064\151"

So, this setup tells the telnet application to print to the local 
printer port, it appears.  That's how your receipt comes out.  Receipt 
printers, as opposed to some poles, are not defined print queues.  Some 
poles are also not defined queues.  I mentioned earlier that some poles 
are pass through.  They plug in to the parallel port with the receipt 
printer.  They too are defined

Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[R. Scott Belford]

On Thursday, May 23, 2002, at 06:19 PM, Warren Togami wrote:


On Thu, 2002-05-23 at 17:20, MonMotha wrote:

Yes, but SCO != Linux :)



Because SCO was/is a x86 Unix, most SCO binaries run with little or no
modification on Linux when you have the right libraries and Unix
compatibility kernel modules installed.  Scott can post more about this.


Yeh, from what I have learned about this program called Counterpoint 
that runs on Linux is that it does so through a "hack" of sorts.  If you 
are using Redhat's 6.2, then you must insmod iBCS in your rc.local file 
to be sure that the program runs.  In Red Hat's 7.2 distro, you must


insmod abi -machdep
insmod abi -svr4
insmod abi -cxenix
insmod abi -sco
insmod abi -ibcs
insmod abi uw7
insmod binfmt_coff
insmod binfmt_xout

I really don't know what it is doing, but it allows one to execute the 
POS application once they ssh in from a remote client.  I think some 
dealers use Slackware, and I suppose it would run on Caldera's flavor of 
SCO.  I never got it to work with debian or mandrake.



Our registers access this application through a private network.  A 
"register" is simply a pc in this case.  They connect to the remote POS 
application, Counterpoint, with a windows based telnet client.  We use 
Vandyke's, www.vandyke.com , CRT program.  Each register has a keyboard 
and scanner for input.In to the keyboard port plug the keyboard and 
scanner.  They share this port with a wedge or y-adaptor.  Keyboards 
have a credit card reader which is hardware programmed.  The scanner is 
also hardware programmed.  The telnet program doesn't care where the 
data comes from it just takes it from the port.  The POS application 
doesn't care what OS is used to access it and trade data.


Also attached to the pc are a monitor and parallel receipt printer.  The 
pole display, that thing on a pole that displays the price, works in 
pass-through mode on the parallel port.  It can also be plugged in to a 
serial port.


So, there you are at the counter and you want to buy some gum.  The 
cashier positions the cursor in the customer screen, asks your zip code, 
and then uses the keyboard to enter a stream of data matching your 5 
numbers.  The cursor is now positioned in the item entry screen.  The 
gum is passed over the scanner where its barcode is read.  This stream 
of numbers travels through the network, is compared to an inventory 
file, and a stream of data returns displaying big read for .25 on the 
cashiers screen.  At the same time, the price of gum has appeared on the 
pole display.  She scrolls down to the payment entry area, selects 
credit card, and swipes your card.  That stream of data is read from 
your magnetic strip and is passed through the network to the POS 
application.  Counterpoint engages one of the server's many modems and 
dials our processor for approval.  The approval is displayed on the 
cashiers screen a few seconds later, and the magic begins.


On the server end, peripheral devices can be defined.  That pole display 
showing the gum, let's say it was a serial port pole.  On the server 
end, a remote printer is defined where the pole is located.  In our 
case, because our register pc's run windows, that pole display is known 
to windows as a generic text serial printer.  It is shared.  We setup 
this remote windows printer on the server, usually name the queue with 
that register's number, and when the application gets your gum data 
stream, it knows to print the price data to the user defined printer.  
In this case it is a remotely shared windows printer.  It can easily be 
any printer.


This, so far, may not be too hard to replicate on a thin-client linux 
register.  Something else happens, though.  CRT, the windows telnet 
program,  is set up to pass through printing to lpt1.  When the cashier 
got your approval for the gum, she finished the transaction by printing 
a receipt.  When she printed that receipt, the printer was not defined 
the same way as the pole.  The printer in this case is a device defined 
in Counterpoint called local.  Local is a file in the top level of the 
Counterpoint, with 777 permissions but root ownership and root group.  
In the file are the following magical lines


echo -ne "\\033\133\065\151"
cat $*
echo -ne "\\033\133\064\151"

So, this setup tells the telnet application to print to the local 
printer port, it appears.  That's how your receipt comes out.  Receipt 
printers, as opposed to some poles, are not defined print queues.  Some 
poles are also not defined queues.  I mentioned earlier that some poles 
are pass through.  They plug in to the parallel port with the receipt 
printer.  They too are defined as "local"  In Counterpoint certain codes 
are defined for this type of pole display that insert themselves in the 
lpt stream and send the right data to the pole and the rest to the 
printer.  It is this pass through and local file configuration that I am 
not certain about, yet, with a pure linux reg

Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[MonMotha]

Yeah, I played with ibcs a while back, never had much use for it though 
as I didn't have any commercial UNIX software.


Interesting that SCO OpenUnix can run linux binaries faster than linux 
(says something about linux here).  Also interesting that linux's 
networking is faster than SCO (says something different about linux).


Also remember that IBM has an option to run linux on some of it's z 
series mainframes.  Apparently Linux can handle the smaller of the big 
iron fairly effectively if you feed it to the OS in smaller bites. 
Hopefully it will only be a matter of time until the scalabilty of linux 
is improved.  One thing holding it back in the past was that your 
average OSS hacker doesn't have access to anything even close to "big 
iron" like an IBM z series to test stuff on, and consequentially linux's 
performance tended to not get much better (and indeed sometimes get 
slower as I recall from an article posted on /.) past 4-8 processors. 
Fortunately, now IBM is supporting Linux in cooperation with linux 
vendors so hopefully IBM will contribute some patches to make linux run 
better on big iron hardware (since of course IBM has access to IBM 
hardware :)


--MonMotha

Warren Togami wrote:

On Thu, 2002-05-23 at 17:20, MonMotha wrote:


Yes, but SCO != Linux :)




Because SCO was/is a x86 Unix, most SCO binaries run with little or no
modification on Linux when you have the right libraries and Unix
compatibility kernel modules installed.  Scott can post more about this.

SCO has since been bought by Caldera.  The latest version of SCO was
renamed Caldera OpenUnix for higher end servers, while Caldera OpenLinux
is for lower end servers and workstations.  They made significant
improvements to the SCO system allowing it to run Linux binaries
natively.  They are now marketing OpenUnix is a drop-in replacement
upgrade for when you need to scale your system higher than what
OpenLinux allows.

A few months ago I read a review of OpenUnix running normal Linux
software like StarOffice.  The reviewer said that Linux compiled
binaries ran noticeably faster on OpenUnix than Linux itself, although
networking stuff seemed slower because the TCP/IP layer of SCO's kernel
was less efficient than Linux.

Kinda interesting how Caldera has their own dual Unix/Linux solution to
have options for higher and lower end customers.  This essentially
mirrors Sun's Solaris for high end and Linux for low end market stance,
and IBM's mainframe AIX for high end, and Intel based Linux for low
end.  Caldera however doesn't have the premium prices of proprietary
hardware that Sun and IBM have, so they seem to be in severe financial
trouble compared to those competitors.


___
LUAU mailing list
[EMAIL PROTECTED]
http://videl.ics.hawaii.edu/mailman/listinfo/luau

Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[Warren Togami]

On Thu, 2002-05-23 at 17:20, MonMotha wrote:
> Yes, but SCO != Linux :)
> 

Because SCO was/is a x86 Unix, most SCO binaries run with little or no
modification on Linux when you have the right libraries and Unix
compatibility kernel modules installed.  Scott can post more about this.

SCO has since been bought by Caldera.  The latest version of SCO was
renamed Caldera OpenUnix for higher end servers, while Caldera OpenLinux
is for lower end servers and workstations.  They made significant
improvements to the SCO system allowing it to run Linux binaries
natively.  They are now marketing OpenUnix is a drop-in replacement
upgrade for when you need to scale your system higher than what
OpenLinux allows.

A few months ago I read a review of OpenUnix running normal Linux
software like StarOffice.  The reviewer said that Linux compiled
binaries ran noticeably faster on OpenUnix than Linux itself, although
networking stuff seemed slower because the TCP/IP layer of SCO's kernel
was less efficient than Linux.

Kinda interesting how Caldera has their own dual Unix/Linux solution to
have options for higher and lower end customers.  This essentially
mirrors Sun's Solaris for high end and Linux for low end market stance,
and IBM's mainframe AIX for high end, and Intel based Linux for low
end.  Caldera however doesn't have the premium prices of proprietary
hardware that Sun and IBM have, so they seem to be in severe financial
trouble compared to those competitors.

Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[Warren Togami]

On Thu, 2002-05-23 at 17:15, Brian Chee wrote:
> By the waythis isn't a first.NCR has had SCO Unix based TFTP boot
> registers for at least 10 years nowI helped set them up at shirokiya
> some time back
> 
> /brian chee
> 

Dean & Scott,

Could you folks write-up how your RH Linux server and telnet clients are
currently connected, perhaps with diagrams showing which direction the
samba print shares go and the which devices the pass-thru printing
controls?  Then the whole list can discuss ways of transitioning your
existing Win98 telnet clients to Linux + SSH.

Brian,

Do you remember what the server side of that SCO based cash register
system was called?  The POS system currently being used by Pricebusters
is an SCO application running in Red Hat Linux with the Unix
compatibility kernel modules.  Perhaps your experience with that or
similar systems may help us in figuring out how to make a complete
conversion from Win98 to Linux on the client side.

Thanks,
Warren Togami
[EMAIL PROTECTED]

Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[MonMotha]

Yes, but SCO != Linux :)

--MonMotha

Brian Chee wrote:

By the waythis isn't a first.NCR has had SCO Unix based TFTP boot
registers for at least 10 years nowI helped set them up at shirokiya
some time back

/brian chee

University of Hawaii ICS Dept
Advanced Network Computing Lab
1680 East West Road, POST rm 311
Honolulu, HI  96822
808-956-5797 voice, 808-956-5175 fax

- Original Message -
From: "Warren Togami" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 23, 2002 7:58 PM
Subject: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers




Sherwin-Williams Co. plans to convert its computers and cash registers
in more than 2,500 stores to Linux.  IBM was hired to make the
conversion.

Scott, lets get working on a prototype Linux register for Pricebusters
soon?  (First please finish the Acorp motherboard review.)




http://story.news.yahoo.com/news?tmpl=story&ncid=581&e=5&cid=581&u=/nm/20020
523/tc_nm/tech_ibm_sherwinwilliams_dc_1





___
LUAU mailing list
[EMAIL PROTECTED]
http://videl.ics.hawaii.edu/mailman/listinfo/luau



___
LUAU mailing list
[EMAIL PROTECTED]
http://videl.ics.hawaii.edu/mailman/listinfo/luau

Re: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[Brian Chee]

By the waythis isn't a first.NCR has had SCO Unix based TFTP boot
registers for at least 10 years nowI helped set them up at shirokiya
some time back

/brian chee

University of Hawaii ICS Dept
Advanced Network Computing Lab
1680 East West Road, POST rm 311
Honolulu, HI  96822
808-956-5797 voice, 808-956-5175 fax

- Original Message -
From: "Warren Togami" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 23, 2002 7:58 PM
Subject: [luau] NEWS: Sherwin-Williams to use Linux Cash Registers


> Sherwin-Williams Co. plans to convert its computers and cash registers
> in more than 2,500 stores to Linux.  IBM was hired to make the
> conversion.
>
> Scott, lets get working on a prototype Linux register for Pricebusters
> soon?  (First please finish the Acorp motherboard review.)
>
>
http://story.news.yahoo.com/news?tmpl=story&ncid=581&e=5&cid=581&u=/nm/20020
523/tc_nm/tech_ibm_sherwinwilliams_dc_1
>
>
>
>
> ___
> LUAU mailing list
> [EMAIL PROTECTED]
> http://videl.ics.hawaii.edu/mailman/listinfo/luau