Tool Hosts and Announcements was Re: BSD vs POSIX psignal

Joel Sherrill joel.sherrill at
Fri May 20 13:34:58 UTC 2011

On 05/20/2011 12:35 AM, Ralf Corsepius wrote:
> On 05/20/2011 07:19 AM, Chris Johns wrote:
>> On 20/05/11 1:13 PM, Ralf Corsepius wrote:
>>> All others will be facing occasional build
>>> errors, when things have changed incompatibly (Like in this case).
>> And how do they know a change in the tools in needed ?
> It's a rolling development branch ... breakages are to be expected.
>>>> That is how can I tell I need to perform an update ?
>>> No idea about what you are asking.
>> I do not use yum and so do not know anything has changed.
> Pardon, if this sounds rude, this is your decision and thus is your
> problem, you have to cope with. You might not like it, but it's
> impossible to support folks who have chosen to use closed source OSes.
> Plain and simple truth is: They are on their own.
Debian is closed source?  *BSD is closed source?  Those
folks are currently on their own.

Not to pick too much here but this isn't restricted to closed
source OSes.  We only support RPM based free OSes.  There
are users who would really like BSD ports and .deb packages.

Long term, it would be desirable for RPM to continue to be
the primary format and automated conversions to generate
the ports and .deb files.

We should be encouraging RTEMS use as a first priority.
Getting a user from VxWorks or ThreadX is a free software win
in and of itself.  Make them comfortable using RTEMS.
If they use RTEMS successfully, then there is a chance to
can get the user off a closed source OS. If that happens,
it's great.

But Debian and *BSD are just as valid a free OS choice as
Fedora/RHEL/Centos/SUSE.  Give them a rainbow of alternatives.
>> When something
>> breaks I have no idea what changed and why. Currently the only way I
>> know a change happens is via a commit to contrib/crossrpms.
> This is one way to getting to know about such changes. Another way is to
> wait until you are facing breakdowns.
Where's that conservative Ralf we saw on the EABI discussion?
>> I was just
>> asking if there is some other way to know.
> Are you asking for formal announcements?
How formal they need to be is a matter of choice.
I have hinted in the past at you writing short News items
and putting them on  It is very easy to do this.
A paragraph would have been more than sufficient in this
case I think.

For better or worse, making these types of announcements
is what lets the world at large know we are tracking the
latest versions of the GNU tools.  It speaks to the vibrancy
of that part of the project.

At this point, neither the project as a whole or you as
an individual are getting the credit and visibility deserved.

I don't know that every RPM bump needs an announcement
but version bumps, distro set changes, addition of target
architectures, and user noticeable bumps like this probably
should all be news items.
> In case of this upgrade, I even added hard configure checks to
> configure, which will kill your builds to abort if your toolchain is
> insufficient.
This is definitely important and appreciated.

I think Chris' point is more in the getting the word out.  We
are great technically but horrible at marketing.
> _______________________________________________
> rtems-vc mailing list
> rtems-vc at

Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

More information about the vc mailing list