RTAI/RtLinux

RTAI/RtLinux

[Erwin Rol]

[-- Attachment #1: Type: text/plain, Size: 3103 bytes --]

Normally I am not subscribed to the kernel list, but after a msg from
Karim that there was a "fight" going on about RTAI I read the archives
and decided that it was important enough to join the discussion.

Both Linus and Larry seem to be not very interested in hard-realtime
Linux additions, this is OK. I mean everybody has his interests and with
so many Linux users and developers you can't all focus on the same
thing.

But we (RTAI developers, which include Karim and myself) have decided to
focus on hard-realtime extensions to Linux. And it is than always very
motivating to hear nobody gives a f*ck about your work or problems,
because "hey, you don't have a business model that makes sense anyway"

For example, first there is said that there is no userspace
hard-realtime, than Karim corrects that, than there is said that a
userspace program that uses mlockall is actually a module: with other
words be quiet and go sit in the corner.
This seems the same as what happened with  FSMLabs, first they explain
why userspace hard-realtime is crap, and now they have implemented it
them self and explain how good it is. 

We have had several discussions with FSMLabs about userspace
hard-realtime and asked for comments on for example the following
situation.

-
When i write a RTAI module, that changes the sched_setparam in such a
way that SCHED_FIFO and SCHED_RR are now hardrealtime. Than a binary
program that runs on a computer with the RTAI kernel-module loaded
violates the patent, and on a computer that doesn't have it loaded it
doesn't violate the patent. 
-
needless to say we never even got a reply on questions like these. When
you have to believe FSMLabbs, you are not allowed to use non-GPL
software on a system that has a RTAI module loaded, according to Eben Mo

There was also asked about the possibility (and even some person on the
RTAI list started such a project) to have a *BSD version of RTAI, well
the answer is simply NO. since *BSD will not accept GPL kernel code, and
the RTLinux patent doesn't allow no GPL implementations there will be no
free *BSD with this type of hard-realtime. Of course you can buy the
FSMLab version, but than you can just as well buy a true RTOS, like
VxWorks.

Also apparently there is the idea that all RTAI developers want to
become rich by getting the patent out of the way and sell RTAI. I know
you all know this is simply not true, like most Linux hacker we spend a
large part of our free time to give the real-time community a usable
piece of software where they normally have to pay for. 
So please don't stamp us as some money sucking bastards that shouldn't
be allowed to use Linux in the first place.

I just hope the linux developers are smart enough to not accept the
RTLinux into the main kernel, cause someday someone might come up with
the idea to write something that allows to have userspace programs to be
hard-realtime, and than you have to stop allowing non GPL userspace
programs, like for example GLIB( which is LGPL). 

- Erwin Rol , RTAI Developer






[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: RTAI/RtLinux

[Erwin Rol]

[-- Attachment #1: Type: text/plain, Size: 3409 bytes --]

On Sat, 2002-05-25 at 11:05, Erwin Rol wrote:
> Normally I am not subscribed to the kernel list, but after a msg from
> Karim that there was a "fight" going on about RTAI I read the archives
> and decided that it was important enough to join the discussion.
> 
> Both Linus and Larry seem to be not very interested in hard-realtime
> Linux additions, this is OK. I mean everybody has his interests and with
> so many Linux users and developers you can't all focus on the same
> thing.
> 
> But we (RTAI developers, which include Karim and myself) have decided to
> focus on hard-realtime extensions to Linux. And it is than always very
> motivating to hear nobody gives a f*ck about your work or problems,
> because "hey, you don't have a business model that makes sense anyway"
> 
> For example, first there is said that there is no userspace
> hard-realtime, than Karim corrects that, than there is said that a
> userspace program that uses mlockall is actually a module: with other
> words be quiet and go sit in the corner.
> This seems the same as what happened with  FSMLabs, first they explain
> why userspace hard-realtime is crap, and now they have implemented it
> them self and explain how good it is. 
> 
> We have had several discussions with FSMLabs about userspace
> hard-realtime and asked for comments on for example the following
> situation.
> 
> -
> When i write a RTAI module, that changes the sched_setparam in such a
> way that SCHED_FIFO and SCHED_RR are now hardrealtime. Than a binary
> program that runs on a computer with the RTAI kernel-module loaded
> violates the patent, and on a computer that doesn't have it loaded it
> doesn't violate the patent. 
> -
> needless to say we never even got a reply on questions like these. When
> you have to believe FSMLabbs, you are not allowed to use non-GPL
> software on a system that has a RTAI module loaded, according to Eben Mo

Some how a small piece of the mail is missing here. 

... according to Eben Moglen this can't be correct. 

- Erwin


> 
> There was also asked about the possibility (and even some person on the
> RTAI list started such a project) to have a *BSD version of RTAI, well
> the answer is simply NO. since *BSD will not accept GPL kernel code, and
> the RTLinux patent doesn't allow no GPL implementations there will be no
> free *BSD with this type of hard-realtime. Of course you can buy the
> FSMLab version, but than you can just as well buy a true RTOS, like
> VxWorks.
> 
> Also apparently there is the idea that all RTAI developers want to
> become rich by getting the patent out of the way and sell RTAI. I know
> you all know this is simply not true, like most Linux hacker we spend a
> large part of our free time to give the real-time community a usable
> piece of software where they normally have to pay for. 
> So please don't stamp us as some money sucking bastards that shouldn't
> be allowed to use Linux in the first place.
> 
> I just hope the linux developers are smart enough to not accept the
> RTLinux into the main kernel, cause someday someone might come up with
> the idea to write something that allows to have userspace programs to be
> hard-realtime, and than you have to stop allowing non GPL userspace
> programs, like for example GLIB( which is LGPL). 
> 
> - Erwin Rol , RTAI Developer
> 
> 
> 
> 
> 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: RTAI/RtLinux

[Der Herr Hofrat]

> 
> > LGPL can be used as GPL. If you haven't even read the license do that
> > before the flamewar please.
> > 
> 
> I know this, the point is that when you use the LGPL to be used as the
> GPL it is not really LGPL anymore. A binary program using GLIBC depends
> on the fact that GLIBC allows that (because of its LGPL license). What i
> wanted to say is that "allowance" might be taken away by the patent
> license.

The basic problem is again that some people want to have the privileges of 
GPL without the responsibilities of GPL. That is a very old debate and I
don't think it is sensible to krank it through again. Do GPL work and
you can use the services of the comunity, do non-GPL and you need to 
get these services under other terms. I realy don't see whats so wrong
unfair and evil about this.

> It is like a patent on VM management, or some other kernel internal
> technique, does that mean that that patent is also has something to say
> about ppl that write programs for that OS ? The same with LXRT (the
> userspace part of RTAI), its implementation might fall under the patent,
> but does the program that uses the LXRT services also fall under the
> patent ? 

The question of derived work is realy exhaustively discused and there are
plenty of statements on this including statements by the FSF itselfe.
mere agregation of work does not put you under any copywrite restrictions,
derived work does - drawing this line is not easy and expecting anybody to
give you "the definitive guide on derived work" is a bit naiv.
You might want to scan the FSF statements on these issues...

hofrat

Re: RTAI/RtLinux

[Alan Cox]

On Sat, 2002-05-25 at 10:05, Erwin Rol wrote:
> I just hope the linux developers are smart enough to not accept the
> RTLinux into the main kernel, cause someday someone might come up with
> the idea to write something that allows to have userspace programs to be
> hard-realtime, and than you have to stop allowing non GPL userspace
> programs, like for example GLIB( which is LGPL). 

LGPL can be used as GPL. If you haven't even read the license do that
before the flamewar please.

The RtLinux patent seems to boil down to "If you are free software we
are free software, if you are proprietary we play in your space too,
please pay up". Its not something I'm totally happy with but I don't
really see how else Victor can phrase it.

Re: RTAI/RtLinux

[Erwin Rol]

[-- Attachment #1: Type: text/plain, Size: 2824 bytes --]

Hello Alan, and the others,

First of all my mail was not meant to be a flame, if it looked like that
I apologize for that.  

On Sat, 2002-05-25 at 15:30, Alan Cox wrote:
> On Sat, 2002-05-25 at 10:05, Erwin Rol wrote:
> > I just hope the linux developers are smart enough to not accept the
> > RTLinux into the main kernel, cause someday someone might come up with
> > the idea to write something that allows to have userspace programs to be
> > hard-realtime, and than you have to stop allowing non GPL userspace
> > programs, like for example GLIB( which is LGPL). 
> 
GLIB should have been GLIBC, but that doesn't really mather for the
discussion.

> LGPL can be used as GPL. If you haven't even read the license do that
> before the flamewar please.
> 

I know this, the point is that when you use the LGPL to be used as the
GPL it is not really LGPL anymore. A binary program using GLIBC depends
on the fact that GLIBC allows that (because of its LGPL license). What i
wanted to say is that "allowance" might be taken away by the patent
license.

> The RtLinux patent seems to boil down to "If you are free software we
> are free software, if you are proprietary we play in your space too,
> please pay up". Its not something I'm totally happy with but I don't
> really see how else Victor can phrase it.
> 

IANAL, so i would not know how to phrase it. Thats why I (and several
others) asked FSMLabs to explain some of it in more clear language, and
we gave some examples (like the one in my other mail) so FSMLabs could
say if those where compliant with their license or not. 

The big question still is where the patent "stops", and there ppl like
Eben Moglen and Victor Yodaiken have very different opinions. A lot of
other ppl try to explain how they see things, and of course those
explanations  also differ a lot, but that is just normal.  

It is like a patent on VM management, or some other kernel internal
technique, does that mean that that patent is also has something to say
about ppl that write programs for that OS ? The same with LXRT (the
userspace part of RTAI), its implementation might fall under the patent,
but does the program that uses the LXRT services also fall under the
patent ? Than the next question , the userspace<->kernel border is
nothing "magical" in respect to patent law, so for kernel modules the
same question is true; do they implement the patent (and hence should
they comply to the license) or do they just use the services the
patented part offers. 

I hope you can see that these are uncertainties that I (and other ppl
have) and would just liked the have cleared up without a lawsuit :-/
Even FSMLabs, and their users would provide from that, cause more ppl
can program more in a shorter time :-) 

- Erwin
 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: RTAI/RtLinux

[Erwin Rol]

[-- Attachment #1: Type: text/plain, Size: 3269 bytes --]

On Sat, 2002-05-25 at 15:21, Der Herr Hofrat wrote:
> > 
> > > LGPL can be used as GPL. If you haven't even read the license do that
> > > before the flamewar please.
> > > 
> > 
> > I know this, the point is that when you use the LGPL to be used as the
> > GPL it is not really LGPL anymore. A binary program using GLIBC depends
> > on the fact that GLIBC allows that (because of its LGPL license). What i
> > wanted to say is that "allowance" might be taken away by the patent
> > license.
> 
> The basic problem is again that some people want to have the privileges of 
> GPL without the responsibilities of GPL. That is a very old debate and I
> don't think it is sensible to krank it through again. Do GPL work and
> you can use the services of the comunity, do non-GPL and you need to 
> get these services under other terms. I realy don't see whats so wrong
> unfair and evil about this.

The "serice" in this cause is not sourcecode, or an other product, it is
an idea. I totally agree with you that when you want to derive from GPL
software you should comply with its license. This is not about deriving
software, this is about the use of an idea, which happens to be made
into a patent (by a patent office with a very questionable reputation,
also in this case as lots of ppl pointed out before).

> 
> > It is like a patent on VM management, or some other kernel internal
> > technique, does that mean that that patent is also has something to say
> > about ppl that write programs for that OS ? The same with LXRT (the
> > userspace part of RTAI), its implementation might fall under the patent,
> > but does the program that uses the LXRT services also fall under the
> > patent ? 
> 
> The question of derived work is realy exhaustively discused and there are
> plenty of statements on this including statements by the FSF itselfe.
> mere agregation of work does not put you under any copywrite restrictions,
> derived work does - drawing this line is not easy and expecting anybody to
> give you "the definitive guide on derived work" is a bit naiv.
> You might want to scan the FSF statements on these issues...

Those statements are mostly valid for copyright cases, where i derive a
piece of software from a other piece of software. These are very hard to
map to patent cases like this one is. Cause if this was about deriving
software, RTAI developers would have no problem with FSMLabs at all,
cause we write our own software or we comply to the license of the
software we use (keep in mind that RTAI was LGPL, and is now GPL, so
RTAI itself is in no way colliding with the GPL). It is about users of
RTAI that might want to keep their program non-GPL, and the question is,
are they allowed to. Since they are not deriving from RTAI (they just
use the services it offers) they are free to do so, when it would be a
simple copyright case, but FSMLabs thinks different on this point. So
thats what this is all about, where does the patent "stop" ? that
question was always pushed into the copyright corner, and never answered
correctly, apart by Eben Moglen, who apparently is not qualified enough
to say anything on this topic (when i have to believe some ppl). 

- Erwin


> 
> hofrat


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: RTAI/RtLinux

[Larry McVoy]

On Sat, May 25, 2002 at 11:05:32AM +0200, Erwin Rol wrote:
> Both Linus and Larry seem to be not very interested in hard-realtime
> Linux additions, this is OK. 

I'm interested in hard realtime.  I'm extremely uninterested in changes 
to the mainline source base in order to get them.  That's exactly why
I like the RT/Linux approach so much, it is the least invasive to the
kernel and - surprise - also has the best performance.

If people were to learn that real time and multi-user throughput are 
by definition mutually exclusive, I'd be a lot happier.  As it is,
we have the SGI/Montevista crowd cramming their stuff into the kernel
and each "little" thing makes the kernel a less pleasant place to be
and brings it one step closer to the point when it gets abandoned 
like ever other OS in the history of our field.

> Also apparently there is the idea that all RTAI developers want to
> become rich by getting the patent out of the way and sell RTAI. 

So the thing I have a problem with is that Victor says that all GPL
is fine.  You say you are all GPL.  So far, no problem.  Yet you keep
coming back and saying there is a problem, that Linux is going to
be out of the running as a real time platform because of the patent.
I don't get it, why should the patent prevent Linux from being used?
All it does is say "if you aren't making money, we aren't making money,
if you are making money, we want a cut".  That seems OK to me, in fact,
it seems more than OK.  It seems like someone who is trying to help
those who are helping others and charge those who are charging others.
That's smart, that's good.  It means that FSMlabs will be here 20 years
from now, still supporting this stuff, whereas all the "we'll survive
off of support" people will have long since gone under.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: RTAI/RtLinux

[Karim Yaghmour]

Larry McVoy wrote:
> > Also apparently there is the idea that all RTAI developers want to
> > become rich by getting the patent out of the way and sell RTAI.
> 
> So the thing I have a problem with is that Victor says that all GPL
> is fine.  You say you are all GPL.  So far, no problem.  Yet you keep
> coming back and saying there is a problem, that Linux is going to
> be out of the running as a real time platform because of the patent.
> I don't get it, why should the patent prevent Linux from being used?
> All it does is say "if you aren't making money, we aren't making money,
> if you are making money, we want a cut".

That's the whole point isn't it. If Linus had used a licensing model
(patent or copyright, I don't care) by which every Linux user would
have to pay him a royalty, we wouldn't be here today. The same stands
for real-time in Linux. As long as users have to pay one vendor every
time they use the technology, it will not lift off the ground and will
keep Linux stuck with it.

>  That seems OK to me, in fact,
> it seems more than OK.  It seems like someone who is trying to help
> those who are helping others and charge those who are charging others.
> That's smart, that's good.

This is an oversimplification. You should add that Victor wants to
be the only one who can help others. And in doing so, he is not helping
anyone but himself.

>  It means that FSMlabs will be here 20 years
> from now, still supporting this stuff, whereas all the "we'll survive
> off of support" people will have long since gone under.

I personnally think that FSMLabs will probably not live very long.
They base their entire business model on one very shallow patent.
The day the patent goes, so does FSMLabs.

It's not like this is IBM who has thousands of patents. This company
relies on a single shallow patent for its entire revenue stream.
Talk about playing Russian-roulette with a fully loaded gun.

Karim

===================================================
                 Karim Yaghmour
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

Re: RTAI/RtLinux

[Erwin Rol]

[-- Attachment #1: Type: text/plain, Size: 2593 bytes --]

On Sat, 2002-05-25 at 18:05, Larry McVoy wrote:
> On Sat, May 25, 2002 at 11:05:32AM +0200, Erwin Rol wrote:
> > Both Linus and Larry seem to be not very interested in hard-realtime
> > Linux additions, this is OK. 
> 
> I'm interested in hard realtime.  I'm extremely uninterested in changes 
> to the mainline source base in order to get them.  That's exactly why
> I like the RT/Linux approach so much, it is the least invasive to the
> kernel and - surprise - also has the best performance.
> 

If you take a look at RTAI's history you will see that RTAI has been
using a HAL and a very small kernel patch long before RTLinux started
using that.   


> If people were to learn that real time and multi-user throughput are 
> by definition mutually exclusive, I'd be a lot happier.  As it is,
> we have the SGI/Montevista crowd cramming their stuff into the kernel
> and each "little" thing makes the kernel a less pleasant place to be
> and brings it one step closer to the point when it gets abandoned 
> like ever other OS in the history of our field.
> 
> > Also apparently there is the idea that all RTAI developers want to
> > become rich by getting the patent out of the way and sell RTAI. 
> 
> So the thing I have a problem with is that Victor says that all GPL
> is fine.  You say you are all GPL.  So far, no problem.  Yet you keep
> coming back and saying there is a problem, that Linux is going to
> be out of the running as a real time platform because of the patent.
> I don't get it, why should the patent prevent Linux from being used?
> All it does is say "if you aren't making money, we aren't making money,
> if you are making money, we want a cut".  That seems OK to me, in fact,
> it seems more than OK.  It seems like someone who is trying to help
> those who are helping others and charge those who are charging others.
> That's smart, that's good.  It means that FSMlabs will be here 20 years
> from now, still supporting this stuff, whereas all the "we'll survive
> off of support" people will have long since gone under.

It is not so OK if you keep in mind that this "if you make money, we
want a part of it" is backed by a questionable patent. And if FSMLAbs
still will be there in 20 years is not something you or I can predict,
they might be bought by some large embedded firm tomorrow and the patent
with it, and as far as i understand the patent license this means it is
void when that happens.

- Erwin
 

> -- 
> ---
> Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: RTAI/RtLinux

[Randy.Dunlap]

On Sat, 25 May 2002, Larry McVoy wrote:

| On Sat, May 25, 2002 at 11:05:32AM +0200, Erwin Rol wrote:
| > Both Linus and Larry seem to be not very interested in hard-realtime
| > Linux additions, this is OK.
|
| I'm interested in hard realtime.  I'm extremely uninterested in changes
| to the mainline source base in order to get them.  That's exactly why
| I like the RT/Linux approach so much, it is the least invasive to the
| kernel and - surprise - also has the best performance.
|
| If people were to learn that real time and multi-user throughput are
| by definition mutually exclusive, I'd be a lot happier.  As it is,
| we have the SGI/Montevista crowd cramming their stuff into the kernel

In this example, SGI and MV are at opposite ends of the
spectrum, right?  High-end servers vs. embedded (and maybe RT).

I expect that most of the continued growth of Linux will be
in these 2 areas (servers and embedded) -- but we can't just
abondon the desktop/workstation space either.
Having 1 person say that Linux has problems in the embedded space
doesn't carry much weight with me, but having 2-3 other people
confirm it does start to concern me.

| and each "little" thing makes the kernel a less pleasant place to be
| and brings it one step closer to the point when it gets abandoned
| like ever other OS in the history of our field.

What I'd like to see/hear is a discussion about how to
accommodate all of these OS spaces (servers, workstations,
mobile, embedded) without making Linux ugly (or uglier in a
few cases).  Maybe a good topic for discussion in Canada...
in a hallway or a bar or a BOF.

Maybe the embedded/RT space is always maintained outside of
the kernel.org kernel tree; I don't know.
But certainly parts of the high-end server space want to be
included in the mainstream kernel.org tree.

Sorry about adding something non-legal to the discussion.
Not.

-- 
~Randy

Re: RTAI/RtLinux

[Eric Brunner-Williams in Portland Maine]

...
> I expect that most of the continued growth of Linux will be
> in these 2 areas (servers and embedded) -- but we can't just
> abondon the desktop/workstation space either.

Does any have clue on the Linux pick-up in schools
	- in Mexico?
	- in China?
	- in India?

Eric

Re: RTAI/RtLinux

[Wolfgang Denk]

In message <Pine.LNX.4.33L2.0205251019130.18051-100000@dragon.pdx.osdl.net>
Randy Dunlap wrote:
> 
> Having 1 person say that Linux has problems in the embedded space
> doesn't carry much weight with me, but having 2-3 other people
> confirm it does start to concern me.

OK, so let's add another confirmation - mine. Just $0.02, of course.

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
The best things in life are for a fee.

Re: RTAI/RtLinux

[Randy.Dunlap]

On Sat, 25 May 2002, Eric Brunner-Williams in Portland Maine wrote:

| > I expect that most of the continued growth of Linux will be
| > in these 2 areas (servers and embedded) -- but we can't just
| > abondon the desktop/workstation space either.

I didn't mean to suggest that we would abandon the desktop space.
If I did, sorry about that.

| Does any have clue on the Linux pick-up in schools
| 	- in Mexico?
| 	- in China?
| 	- in India?

Yes, some clue.
And even in Portland, Oregon, with school districts fighting
an M$ audit.  (old news, a few weeks old)

  http://www.k12ltsp.org

-- 
~Randy

Re: RTAI/RtLinux

[Kevin O'Connor]

On Sat, May 25, 2002 at 09:05:37AM -0700, Larry McVoy wrote:
> So the thing I have a problem with is that Victor says that all GPL
> is fine.  You say you are all GPL.  So far, no problem.  Yet you keep
> coming back and saying there is a problem, that Linux is going to
> be out of the running as a real time platform because of the patent.
> I don't get it, why should the patent prevent Linux from being used?

The problem is with a non-GPL userspace.

Using an analogy, consider what would occur if a company revealed it had a
patent on some key part of the Linux dcache - a patent free for all GPL
users, but requiring a license for any commercial code.  In theory this
isn't a problem, but what happens when that company starts demanding
licensing fees from application developers like Oracle, IBM, and even
BitKeeper Inc?  What if the patent holder was Rational Inc and they were
not eager to license the patent to some companies?  Finally consider what
would happen if there were a dozen (hundreds?) of patent owners demanding
royalties for a userspace application.

To be clear, I do not believe this is the case with RTAI.  Their userspace
appears to be distinctly different from Linux userspace.  But I hope you
can appreciate why this concept can be very disturbing.

-Kevin

-- 
 ------------------------------------------------------------------------
 | Kevin O'Connor                     "BTW, IMHO we need a FAQ for      |
 | kevin@koconnor.net                  'IMHO', 'FAQ', 'BTW', etc. !"    |
 ------------------------------------------------------------------------

Re: RTAI/RtLinux

[Alexander Viro]

On Sun, 26 May 2002, Kevin O'Connor wrote:

> Using an analogy, consider what would occur if a company revealed it had a
> patent on some key part of the Linux dcache - a patent free for all GPL
> users, but requiring a license for any commercial code.  In theory this
> isn't a problem

Oh, yes it is.  GPL and commercial DO NOT COVER EVERYTHING, damnit.
And I don't fscking care for Oracle, IBM, etc. - there are folks doing
stuff under other free licenses and I find casual dismissing them
from consideration disgusting at extreme.  Especially if you take care
to count the amounts of good ideas that came from, say it, CSRG folks
and from Oracle.  Good ideas we are using.  Shame...

Re: RTAI/RtLinux

[Larry McVoy]

On Sun, May 26, 2002 at 12:03:37AM -0400, Kevin O'Connor wrote:
> Using an analogy, consider what would occur if a company revealed it had a
> patent on some key part of the Linux dcache - a patent free for all GPL
> users, but requiring a license for any commercial code.  In theory this
> isn't a problem, but what happens when that company starts demanding
> licensing fees from application developers like Oracle, IBM, and even
> BitKeeper Inc?  What if the patent holder was Rational Inc and they were
> not eager to license the patent to some companies?  

If you think that we don't worry about this, you're wrong.  That's why we
write our own code here and don't depend on outside code, and it's also
why we are constantly spending time in the patent database.  We've made
changes to BK to avoid Rational patents.  Actually, that may not be true,
I just assumed that Rational had the merge alg they use patented but I
never actually found a patent for it.  No worries, we came up with a 
much nicer way to do it that I'm positive they do not have patented
because their system can't do it.

And that's what the RTAI guys or anyone else would have to do as well.
That's why real engineering is so expensive, it's not enough to just
build it, you have to build it in a way that hasn't been covered by
some patent.  The only real way I know to do that cheaply is to be
ahead of everyone else.  Otherwise you have to do your homework.  And 
at this point, it's virtually impossible to be ahead of everyone else,
too much ground has been covered.  So you watch the patent database,
you think about how other people solve the problems, you do what you
can.  It's not pleasant.  That's way they pay you to do it.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: RTAI/RtLinux

[Wolfgang Denk]

In message <a0.2767541f.2a239ebb@aol.com> Joachim Martillo wrote:
> 
> Did I say anything about limited resources?  In any case, I have been
> building and designing embedded and turnkey systems for 20 years.
> I would be extremely dubious of any design that passed by my
> desk that proposed the use of a general purpose multiuser,
> multiprocessing, time sliced, preemptive, multimode, virtual
> memory operating system for a digital video recorder.

So what do you recommend when  the  requirement  specification  lists
features as
- Web interface (interface to electronic program guide database)
- network interface (up- / download to normal PC over ethernet)
- IEEE1384 interface (for digital cameras)
- USB interface (for keyboard, printer)
...

Would you start from scratch, or buy component by component, or  just
use Linux?

> > Again, this is not quite  correct.  There  have  been  Real-Time  and
> > Embedded  Unix  systems  before  (LynxOS, to name one). And there are
> > other "common proprietary operating systems" that can be adapted  for
> > embedded needs (WinCE).
> 
> And is there anything that can be done with WinCE or the various
> RT/unix knock-off's that cannot be done better without?

Please let me keep my mouth shut about WinCE.

But yes, there are situations where "the various RT/unix knock-off's"
are the optimal solution (fastest time to market, lowest  cost,  most
features, highest reliability).

> Excuse me, but we are talking embedded systems.  At some
> point there will be copyrighted tradesecreted or patented programs
> in the system.

Maybe. As application. So what?  That  does  not  mean  that  the  OS
kernel, device drivers etc. may not be available under GPL.

> > The problems with Linux  in  Embedded  and  especially  in  Real-Time
> > Systems  are not technical ones. It is the political situation, where
> > the user is left in uncertainty about what he can legally do and what
> > not.
> 
> Easy enough to deal with.  One generates an appropriate real time
> embedded turnkey operating system customized for the embedded 
> turnkey application.  In my experience, it takes about 4-6 weeks
> without disk management and perhaps 8-12 with disk management.

I see. Yes, there are problems of that class. But that's not what I'm
talking about.

> And then one does not have to deal with multimegabytes of
> non-locally produced code that is just lying in wait to cause
> problems.

??? What are you talking about?

> You may need to learn more about doing business in the USA.

Definitely. I learn a lot each day.

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
If ignorance is bliss, why aren't there more happy people?

Re: RTAI/RtLinux

[Wolfgang Denk]

In message <57.c083d0f.2a237c49@aol.com> Joachim Martillo wrote:
> 
> Hardly seems surprising.  Linux is a general purpose multiuser
> moderate weight multiprocessing preemptive time sliced time 
> shared virtual memory operating system.  Embedded system
> developers generally need single purpose extremely lightweight
> limited process count nonpreemptive cooperative real memory
> operating systems.  

Joachim, your perception of "Embedded Systems" is  not  up  to  date.
There  is  a  lot  of devices which fall into this group that provide
resources you have been dreaming of for your workstation just 5 years
ago. For instance, your digital video recorder may have  a  200+  MHz
PowerPC  CPU,  tens  of  megabytes RAM and tens of gigabytes harddisk
space. Can you remember the configuration of your fastest workstation
from 10 or 5 years ago?

Yes, there are embedded systems with limited resources where Linux is
just overkill. And probably (by number of units sold)  these  devices
are the majority.

But there are also lots of embedded devices that not only provide the
resources for a more powerful OS  like  Linux,  but  also  demand  it
because  of  the  complexity of applications they are running. And if
you look at current trends you will find that  this  is  one  of  the
fastest growing parts on the market.

> There is not so much overlap between the two types of
> operating systems.  It is to the credit of the Linux design
> that with hacking Linux can generally be adapter to real
> time uses unlike some other common proprietary operating
> systems.

Again, this is not quite  correct.  There  have  been  Real-Time  and
Embedded  Unix  systems  before  (LynxOS, to name one). And there are
other "common proprietary operating systems" that can be adapted  for
embedded needs (WinCE).

The big advantages of Linux are in  defferent  areas  (free  sources,
excellent  support  of  all  modern technologies, not single-sourced,
...).


The problems with Linux  in  Embedded  and  especially  in  Real-Time
Systems  are not technical ones. It is the political situation, where
the user is left in uncertainty about what he can legally do and what
not.

And if you look at the (missing) answers to  all  specific  questions
about  this  you  can  see  that there is method to it. "Go and see a
lawyer" is all you get.

Hell, would you do busines with ANY company who tell  you  "ask  your
laywer"  when  you  ask  for explanations of the conditions of use of
their products?

THIS is the main problem of Linux in the real-time market.


But who knows, maybe VY will provide clear "yes" / "no" answers  this
time...

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Man did not weave the web of life; he  is  merely  a  strand  in  it.
Whatever he does to the web, he does to himself.     - Seattle [1854]