Re: [rtl] RTAI and RTLinux

[yodaiken@fsmlabs.com]

On Sun, Sep 10, 2000 at 07:18:40PM +0100, Stuart Hughes wrote:
> yodaiken@fsmlabs.com wrote:
> > 
> > On Sun, Sep 10, 2000 at 03:54:08PM +0100, Stuart Hughes wrote:
> > > That's a little unfair.  The fact is that you have received significant
> > > funding from Zentropix;
> > 
> > Really?  Did the check get lost in the mail? I did consult for Zentropix
> > at one time, but you know very well the circumstances under which that
> > ended.
> > 
> 
> Are you denying that you worked with us and were paid ??

I'd hardly call it significant.

> > >Paolo and Pierre have never received funding.
> > > Do you really that these people are lineo pupets ??? if so that really
> > > is insulting to them.
> > 
> > Don't put words in my mouth. I never called anyone a puppet.  I don't use
> > language like that.
> 
> But you say all posters have been receiving funding from Lineo.  This is

The fact is that all the posters who have sent in abusive posts are either
directly receiving money from Lineo or depend on Lineo funding of their
projects. 

> > > > You know me and Michael, you have used RTLinux
> > > > and worked with us before there was an RTAI, you have had many technical
> > > > discussions with me and I've seen some of the ideas I suggested to you
> > > > appear, without credit, in Lineo/RTAI announcements.
> > >
> > > Like what.
> > 
> > To pick one example: the Perl bindings. I remember quite clearly explaining this
> > idea to you in Virginia.
> > 
> 
> No, we demonstrated a Perl application that interfaced to RTlinux, the
> first time we met.  It seems to me that you have a very intermittent

Do you want me to dig up emails?

> > > >And yet, when, for
> > > > example, Karim sends in absolutely hateful posts, filled with material
> > > > that you know to be false, you have remained silent.
> > >
> > > I am not in control of Karim or anyone else.  He is free to speak for
> > > what he believes.  Is anything he has said untrue ??
> > 
> > Of course. And you know it.
> 
> What precisely I'd like to know.  

Well, to start:
 	What I mean by Microsoft-like
	way of innovating is the fact that Victor has taken a lot of ideas, that
	had been put forward by Paolo, and put them into RTL without __explicit__
	recognition of the source of inspiration.

> 
> 
> > 
> > > >In fact, you have
> > > > contributed to this absurd atmosphere yourself. You can't  even
> > > > disagree with our completely legit extensions to POSIX without asserting
> > > > that we are trying to deceive our users.
> > >
> > > This is incorrect.  What is not legit about the extensions is that they
> > > appear to users under the banner of POSIX, which is supposed to be a
> > > portable API.  My objection is that these extensions have no change of
> > > being portable as they are not supported elsewhere.
> > 
> > This is entirely nonsense. POSIX defines what are permissable and impermissable
> > extensions. If you don't like this feature of POSIX, complain to POSIX. If you
> > don't like use making use of this, complain about that. But when your complaints
> > go from technical to "you're trying to fool users" you cross a line.
> > 
> 
> That is not the point.  Of course _np is permissible, but how does that
> help in what is supposed to be a portable interface specification ???

As I've said many times, our goal is not portability, it is clarity and 
ease of use. That's why Linux has "writev" a non POSIX extensions, HP has
the X/OPen extensions ... 
We strive for portability wherever possible, but it's not the totality or
even the primary interest of POSIX.


> > > > My impression is that there is a concerted attempt to
> > > > to damage my professional reputation and I take this quite seriously.
> > > >
> > >
> > > I think you are doing that for yourself.  You insult Lineo at every
> > > opportunity, calling us sleazy etc.  Also you try to belittle the
> > 
> > What I called sleazy, and I stand by this, is the attempt by Lineo/Zentropix
> > to trademark "RTLinux" when you and I both know that I used RTLinux as a mark
> > while you guys were still suffering from Mach.
> 
> Not true, we dropped mach very early (at least 6 months before we met
> you).  Nobody is denying that you used RTLinux as your project name
> before we did ??  What happened as I have explained before (when you
> took it off list) is that while we were working with you we decided to
> make a CD and we all agreed that it would be a good idea to get a
> trademark.  We probably did you a favour educating you in the practice

Zentropix offered to help me with the paperwork needed to trademark RTLinux, just
prior to the end of our collaboration. When we parted ways I told Zentropix it would
be, of course, inappropriate for them to continue any work on the application.

It was never suggested or agreed that I would give Zentropix any ownership of
this mark, in fact quite the opposite.

> of business, as to my knowledge you had not even thought about tradmarks
> at that point.   What I object to is the term sleazy, this implies that
> we did something underhand, when you well know that we did it with your
> knowledge.

No. Zentropix  applied for a trademark without my knowledge or approval and
its trademark application mistated facts.

> > Create your own products, market it, sell the hell out of it.
> > I don't care. But trying to take the RTLinux trademark was sleazy. I'm glad
> > someone there finally had enough sense to withdraw the application.
> 
> Which says something about our integrity, hardly the act of a sleazy
> company.

After the application was rejected, you dropped the application.

> > > progress that has been made technically in RTAI by dismissing it as
> > > trivial (e.g Dynamic memory: I could do that in half an hour).
> > 
> > Dynamic memory _is_ the work of a half hour in RTLinux: I showed the code for
> > doing it. Anyone who has seen the RTLinux printk function could figure out how
> > to call any linux function. Much of the technical disagreement between RTAI RTLinux
> > is on whether adding easy to add features is good or bad.  You are free to make
> > the argument that having all those extra features in RTAI is good, but please
> > don't try to argue that simple changes are deep technical advances. There is
> > only one major technical novelty in RTLinux and that is the basic method. The rest
> > is incremental although we do have some surprises in store.
> 
> Typical, nobody is claiming any world changing breakthroughs in the
> dynamic memory management, but as usual you choose to belittle the work
> of others.  How does this help ?? the code you posted is not anything
> like the same level of sophistication as that which has been offered by
> the dyn_mem package.  At least have the curtesy to acknowledge that it
> is a reasonable piece of work, but you just don't agree with it
> philosophically, that way nobody has to feel wounded.

Did I argue otherwise?  I don't follow the RTAI code, but I have the highest
respect for Steve's work, I've said mainly good things about LXRT,  in general,
In fact, I have stated and continue to state that Pierre's LXRT forced us to think about
user mode RT much more deeply and sooner than we would have otherwise. I like our solution
better and I think that LXRT from your explanations will not be easily portable,
but despite the fact that the only mail I ever got from Pierre was quite
unpleasant, I don't believe I've ever said anything derrogatory about Pierre or LXRT. 

I don't comment on RTAI code because I've never looked at it -- I looked at 2 files
about two days ago for a minute or two -- that hardly qualifies me to comment on the
code. What I do comment on is  design principles.  And here we disagree.

> > > BTW:  I think this new advocacy list is just an attempt to hide facts
> > > from the wider RTL users.  I think they have a right to listen to the
> > > information and make their own decisions.
> > 
> > Facts? "Facts" like "RTLinux is a dead end"? These are not "facts", they are
> 
> I agree that was unfair, but you need to take it up with Karim not me. 

So this following Pierre's nasty letter and Paolo's "jokes" gets to be too
much.

> Personally I think RTL has improved a lot over the last 6 months and
> I've never belittled your work.

Non fact:
	> I understand the reason for these non-portable extensions, but they
	> unique features to RTLinux that lock-in users under the mask of
	> perceived portability.
Alternate wording:
	> I understand the reason for these non-portable extensions, but they
          have unique features and are not portable.
          POSIX implies portability.
or something.


> > appropriate material for an advocacy list.  If you are not
> > capable of making technical arguments without insults, "humorous" or not, then
> > I don't need to see your posts on rtl.org.
> > The new advocacy list is an attempt to enforce what simple good manners and
> > business ethics should have given automatically . We have been perfectly happy to allow RTAI posts
> > on the list, technical arguments, factual statements. What we are no longer
> > happy to allow is non-technical nonsense or attack posts.
> 
> Who decides ?? I guess you are the judge and jury.

Nicholas is the judge. Do you have an alternative suggestion? Clearly the current
situation is untenable and is driving away users and filling the list with 
crap. And it puts me in a unpleasant situation of either letting attacks on
my integrity go unanswered or fanning the flames.


> > 
> > > 1) extensive use of _np posix extensions which have no chance of being
> > > portable
> > 
> > Please Stuart. This is a silly argument on many grounds.
> >        1. Every POSIX system has non portable extensions. Linux included. Some of the
> >           non-portable RTL extensions are in the X/OPEN extensions to threads which
> >           are widely used.
> 
> The question is what percentage.  In RTL they make up a significant
> proportion and so porting to another system would be very tough.

Not tough, impossible. Other systems don't support our programming model. However,
pthreads programs that don't use our extensions will be portable. To me it's obvious
that if you use a RTLinux specific feature, you won't be portable.


> 
> 
> >        2. RTAI has a variant of the V1 RTLinux API that is totally
> >           nonportable even to RTLinux.  So, obviously, portability is not
> >           a religious principle for you.
> 
> Not true, it is very similar, and porting between the two is simple.  I
> agree that it could be useful to make them make completely the same. 
> You are right that portability is not a religious issue for me, but
> remember the intrinsic RTLinux and RTAI API's never made any claims of
> portability.  This meant that somebody could make a clear choice whether
> or not they wanted to use them, understanding this limitation.  With the
> RTLinux 'POSIX' API, they are let to the belief that it should be
> portable and will find out after committing time and resources that
> infact the system is no more portable than the original RTL/RTAI API's.

We try to be as clear as possible that we provide a POSIX API and conform to
the POSIX spec, but offer features that are unique to RTLinux. If you see anywhere
that needs to have this explained more clearly, please point it out.

> >        3. RTLinux is not Chorus. Having a RT operating system send information to a
> >           resident subthread that is a general purpose OS is something that cannot be
> >           portable between Chorus and RTLinux. Therefore,  any RTL API must either
> >           give up this functionality or be non-portable.
> 
> That's okay, but it seems misleading to call what you have 'POSIX like',
> why not just say that it is composed of some POSIX comformant API's and
> some native ?? At least this makes it clear to those who are not that
> knowlegeable about POSIX.  I guess that we just have to agree to differ.

Again, where our docs are not clear, please tell us.

> 
> 
> >         4. We are engaged in the POSIX standards process and will try to get our
> >            extensions in upcoming standards.
> 
> That's good news, I hope that you get it in.



-- 
---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com