Justin Robbs wrote:

>>
>> Well my immediate thought is that you may be wise to research
> your
>> intended platform a little more throughly. Any of the Linux
> distros
>> will include all the features you require. The source is
> readily
>> available, and free, as well as any patches and drivers; so you
> can
>> recompile a custom kernel to your liking at any time. Thus,
> there's no
>> version of Linux with "best driver support", since any version
> can be
>> rebuilt or customised to your needs.
>
> By driver support, which distro are companies providing drivers
> for. For example, we recently had to change to a new version of
> IBM's touch screens. The drivers for the new version had drivers
> for windows, mac, and redhat I believe (we ended up using a
> different vendor for our touch screens). Are the drivers
> "generally" portable across different flavors? Obviously, no one
> can answer for sure, but I am just looking for general
> experiences.

Generally so - it's the kernel flavours that you'll find most worrying.
Each commercial vendor likes to tweak their kernel ever so slightly for
competitive advantage - but they include the source for those tweaks with
their kernels in the usual places.

And the most change is between major kernel point releases. This is why
Linus and co would prefer that companies bite the bullet and release the
source code for device drivers. That way they could get their device
drivers uptodate a lot quicker.

I've had some experience - not a very pleasant experience - with a
closed-source driver for a winmodem and a short, sharp hack to bring it
from 2.2 to 2.4 status. The only time Linux wouldn't boot.
>
>>A new driver appears, you simply
>> compile it in.

Best to set your kernel compile options to "module" for any device drivers
you are likely to be updating on the fly like this. Otherwise you'll have
to take your system down to do a kernel recompile.

And no, you don't have to worry about paying
> ludicrous
>> licencing fees, no matter what a certain dying UNIX vendor may
> say ;-)
>
> So if I buy redhat or SuSe, what am I paying for? Is it worth
> paying for a big name version or can I just get a freeware
> version and live with that? What are the pros and cons of each?

I can't really talk about "buying" RedHat or Su.S.E., because I've generally
bought downloaded cdroms from friends. But I assume by "buying" RedHat you
mean getting a support contract? That's a matter for discussion with the
relevant vendor.

For "freeware" versions, the most popular one is Debian. That has a very
wide informal support structure, on the same lines as this newsgroup you're
happily using right now. I can't say much about Slackware, because the
last Slackware I used was 2.8, and that was from 1995. I havent' used
Slackware since.
>
>> I think you'll find Linux' hardware support far better, and
> more
>> stable than SCO UNIX, which has fallen so far behind it's hard
> to take
>> it seriously.
>>
>> For vendor support, I'd suggest Redhat or SuSE (IBM use SuSE);
>> although it depends upon your in-house expertise. Oracle use RH
> on
>> their in-house systems, the German govt are going with SuSE.
>
> I have one other question. There is talk that we could sell our
> POS system to other companies, are there any issues with the GPL
> here? Our whole system is written in house, obviously we
> couldn't sell the operating system or any GPL'd drivers, but what
> about software that uses those drivers or runs on a GPL'd OS?
> Sorry for my ignorance, I have just never delved into these
> issues before.

For a start, the general GNU C libraries - included by default with Linux -
are covered by the Lesser General Public License (LGPL), which allows you
to link them to proprietary software. Thus you don't have to disclose any
source when you sell your proprietary software thus linked. And
application and utility software that runs on a GPLed OS, like Linux, isn't
considered to become an indivisable part of the OS, so its status hasn't
changed in any respect - it is still your code. The GPL only applies to
code that is considered to form a single work with the original code, and
if your code is an application, meaning that you separate its functioning
from the underlying OS, the GPL smiles and waves in a friendly manner and
has nothing more to say.

If on the other hand, you decided to include vast chunks of the GPLed Linux
source code in your POS, that would be a totally different scenario, and
you'd have to talk to the relevant source code developers, lawyers, etc.
And _that_'s messy!
>
> Justin

IANAL - these are just observations I've picked up along the way.

Wesley Parish
--
First the wife, tone of awe. So much a condition. Kent in the labs, fast
forward. "So how was the worthlessful businessman?" But they hadn't
stopped meat for year ago, that arose hotel facade slowly moved apper.
- Don't let emacs meta-x dissociatedpress write your speeches!