What about a meeting on IRC ?
- Erwin
Paolo Mantegazza wrote:
>
> Hi to Peter and you all,
>
> BTW Peter I can hear you is just that I'm moving around here for some
> meetings and could not answer before.
>
> I read all the mails sent up to now. I like the idea of the meeting but,
> as someone else, I have funding problems. But if there will be one,
> Vienna is a nice place not far away, I'll try to be there.
>
> However I'm lazy and I like someone's else idea of an e-meeting, which I
> assume is a long session of mails to the RTL mailing list.
>
> >From most of the mails I see that the crucial point is that many would
> like to see a rejoining of DIAPM_RTAI with NMT_RTL.
>
> That what I always wanted, if it was for me there would never had been a
> split. You all should remember that I posted the idea of a common effort
> about the RTHAL_RTAI basic layer to this list from the very beginning,
> but it was refused by Victor and company, and many others thought of it
> has a way of organizing some directories tree.
>
> Forgive me if I'll start the meeting now, but it is time to sum up a few
> points.
>
> 1) Why I made that proposal? Because I saw that 2.2.xx was naturally
> getting to the HAL concept, not exactly as I liked it but closely.
> Victor is right in telling that 2.3.xx is going even better, but there
> is still something lacking to make things easier. However the idea is
> likely to survive against future kernel releases.
>
> 2) Why did we decided to go by ourselves? Because we were in the hurry
> of proving that a certain system could be controlled with a $1000 DUAL
> 350 PII, in place of an about $100.000 dedicated system, and SMP RTL did
> not existed yet and we could not wait.
>
> 3) Thank to what said in 1) we thought that we could do it and in one
> month we proved that it worked. What we had available by that time was
> the proof that the idea worked and the first pieces of a HAL, our very
> tiny patch to the kernel, and RTAI, the module that could allow to do
> (almost) all you wanted without touching the kernel.
>
> 4) At that point we could stop and wait for RTL, but we decided to see
> what the idea was worth. What we, a single non specialist programmer and
> a couple of testers, did is now RTAI-0.6 and prove that the idea is
> sound, and as effective as any other approach at least. In fact take
> into account that if you look at RTL-betaxx patch and RTAI you see that
> they are very similar. It could not be different as both come from the
> very same family, i.e. RTL, and our variant to it, for 2.0.xx. It should
> be recalled that I pointed out a couple of bugs of RTL I verified in
> advance with RTAI. We still have hopes of RTL people helping us in
> finding bugs while cross checking with RTAI.
>
> 5) What does rejoin mean? For us the adoption of the HAL_RTAI idea in
> clear, with all the wheres and whys neatly explained to all of us, so
> that everybody can be confident in what is using. Open software should
> primarely be open knowledge.
> Why not a patch? Because it does not isolate problems. I think that
> Linux should never go real time natively but have a HAL that allows it
> to completly surrender to a real time application interface. We must not
> bother of the kernel, but with an RTAI module get in full control of
> both the kernel and the machine:
>
> !!! THESE ARE THE ONLY TWO THINGS THAT MUST BE IN COMMON !!!
>
> Clearly such an RTAI module should contain a lot of short and simple
> basic services and, being of vital importance, arbitrated by the
> community of users and developers appropriately. In this view I'm still
> hoping that someone else comes out with a better than ours RTAI.
>
> 6) That provided everybody can unleash is fantasy and use what exists
> already, add modules completely anew, by copying partly or in total,
> etc. etc... I think that on such a base many of you are of the kind
> "better do it by myself than look at the DOCs".
>
> 7) People that are going to make a choice should be aware that in the
> long run it will depend on what "GODFATHER LINUS TORVALDS" will decide
> in relation to the kernel. Should he go the way Victor suggests I have
> no doubt that RTL will be the winner, but RTAI will continue to live.
> Should he go the way I like, we all would be the winner and RTL will be
> out. For that take into account that Victor has claimed that Linus is in
> contact with him and is active at Linux meetings and conferences, while:
> I never got an answer to my mails to Linus; I do not want to sell RTAI;
> I will never spend a cent to go to any LINUX meetings, neither to push
> RTAI nor to know what's going on. I am enough with what truly opened I
> find on the network and of the contact through this and other lists.
> (BTW, the friends at NMT should be praised for keeping this list opened
> and unmoderated.)
>
> 8) RTAI is and will remain basically an in house effort based primarily
> on our in house needs, and on our amusement in developing it. As such it
> will be always freely available and we would like people to use it and
> help us in getting it better by discovering bugs and building new
> features around it, again provided that they will be available to
> everyone. Right now something happened in that sense as I got a, for me,
> nasty bug corrected by a user, some other users helped to fix a couple
> of significant bugs and someone else added a POSIX interface to RTAI. It
> is much more than we here expected but nothing was asked and nothing was
> promised, and the all stuff remains, updated and free, at
> http://www.aero.polimi.it/projects/rtai/.
>
> 9) If RTAI is going to be for a large base of committed users I like to
> be acknowledged as the originator and become a contributor from then on,
> and nothing else. In fact in such a case I'll hope that someone else,
> more profitable that we all here are in software development and
> maintenance, get the burden of keeping it up and alive.
>
> 10) Till I do not go to pension my primary goal is in the aerospace
> field and at the Dipartimento di Ingegneria Aerospaziale del Politecnico
> di Milano, not in computer science. This closes the loop because it
> brings us at were RTAI is mostly used for experimental researches in
> intelligent actively controlled structures, and aerospace systems in
> general. All that by using the almighty, and hated, PC always missing
> the old times when "DOS was more than enough, almost every thing was
> done in FORTRAN and assembler, and .... if it could not be done that
> way it could not be done at all".
>
> Ciao, Paolo.
> --- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
> ----
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/~rtlinux/
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
