RT/embedded OS use poll

Greetings,

I am examining a case for a new RT/embedded OS in today's situation. I
would like to get a simple YES/NO answer from embedded developers.

Suppose that you are starting a new project. You are considering to
use embedded Linux and you offered an RT/embedded OS by a vendor John
Doe Inc. The RTOS is proposed in complete source code, uses GNU
toolchain to build and development license is free. Production license
cost is negligible for your purpose and support costs the same as
support from embedded Linux vendors. In other words, John Doe's offer
comes even to embedded Linux with regard to source code, development
and license costs.

Let's also suppose that John Doe's RTOS offers come even with Linux in
ready code availability (John Doe Inc. ported to its OS open-source
libraries that you need).

Now you have to consider pros and cons of the new RTOS option compared
to Linux (we assume that you know Linux pros and cons pretty well).

Pros:

* Smaller footprint, better configurability
* More system resources left free
* Better performance of OS kernel and services
* Real-time responsiveness
* Simpler build and maintenance
* Simpler programming

Cons:

* Worse support (supported only by John Doe Inc. and its distributors,
no match to Linux community)
* Established bad reputation of dedicated RT/embedded OSes

The question is: would you give a try for John Doe's RT/embedded OS?

Thanks,
Daniel

In message <ea6af706-c355-457b-ac76-727186955caf@v17g2000vbo.googlegroup
s.com>, Stargazer <stargazer3p14@gmail.com> writes
>Greetings,
>
>I am examining a case for a new RT/embedded OS in today's situation. I
>would like to get a simple YES/NO answer from embedded developers.
>
>Suppose that you are starting a new project. You are considering to
>use embedded Linux and you offered an RT/embedded OS by a vendor John
>Doe Inc. The RTOS is proposed in complete source code, uses GNU
>toolchain to build and development license is free. Production license
>cost is negligible for your purpose and support costs the same as
>support from embedded Linux vendors. In other words, John Doe's offer
>comes even to embedded Linux with regard to source code, development
>and license costs.
>
>Let's also suppose that John Doe's RTOS offers come even with Linux in
>ready code availability (John Doe Inc. ported to its OS open-source
>libraries that you need).
>
>Now you have to consider pros and cons of the new RTOS option compared
>to Linux (we assume that you know Linux pros and cons pretty well).
>
>Pros:
>
>* Smaller footprint, better configurability
>* More system resources left free
>* Better performance of OS kernel and services
>* Real-time responsiveness
>* Simpler build and maintenance
>* Simpler programming
>
>Cons:
>
>* Worse support (supported only by John Doe Inc. and its distributors,
>no match to Linux community)

This is FUD RTOS support for the commercial RTOS I know if is much
better than for Linux.

Incidentally last time I looked on the list of Linux distributions over
half were "obsolete/unsupported"

>* Established bad reputation of dedicated RT/embedded OSes

CRAP. Otherwise people would not be paying good money for commercial
RTOS.

>The question is: would you give a try for John Doe's RT/embedded OS?

Well as you said it has a whole load of pro's the con's you mention are
FOSS FUD and don't hold water.

However.... you need to compere John Doe's RTOS against other RTOS that
are available. Also you have no said what the target hardware is or what
the application domain is.

There are no simple Yes/No answers.



-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris H wrote:
> In message <ea6af706-c355-457b-ac76-727186955caf@v17g2000vbo.googlegroup
> s.com>, Stargazer <stargazer3p14@gmail.com> writes

>>Cons:
>>
>>* Worse support (supported only by John Doe Inc. and its distributors,
>>no match to Linux community)
> 
> This is FUD RTOS support for the commercial RTOS I know if is much
> better than for Linux.

We haven't met John Doe Inc. yet.  I think that's the OP's point.

	Mel.

On Dec 20, 8:08=A0am, Stargazer <stargazer3...@gmail.com> wrote:

> The question is: would you give a try for John Doe's RT/embedded OS?

Ignoring the usual rabid foamings that FOSS kicks off in this NG, your
question cannot be answered because the answer depends on many other
things:

a) have I already a hardware platform (implication: have I already
allowed for the system footprint of Linux and therefore don't care if
JDOS would save some footprint)? is there already a Linux BSP for it?
is there a John Doe BSP or must I develop it from scratch?
b) is there third-party IP I need to integrate? have the third parties
already supported Linux? Is there any hope in hell they will ever give
a damn about John Doe OS? Note this has nothing to do with your
comment "we ported libraries". This might be proprietary software that
you cannot access.
c) will John Doe be around in 2 years? 5? 20? We have hardware
platforms still in use that are almost 22 years old, running the
original software stack.
d) does my hardware/software toolchain vendor have explicit support
for John Doe OS? There's a bit more to it than just gcc.
e) how hard will it be for me to move JDOS project on HW platform #1
to HW platform #2?

Particularly your answer to c) would determine how likely it is I
would pick it up.

Stargazer wrote:
> Pros:
> 
> * Smaller footprint, better configurability
> * More system resources left free
> * Better performance of OS kernel and services
> * Real-time responsiveness

This all gives a nice "it depends".

This will be valid for an RTOS built from the ground up to be an RTOS,
and if you're using it as an RTOS and nothing more. But nowadays you
probably want a GUI, a network interface, a USB port, etc.

For example, if the RTOS comes with a NetBSD network/filesystem stack,
and you want to use it, it will obviously not use less resources than
real NetBSD. (Which was enough reason for me to make my own filesystem
stack at half the size and thrice the important features, but that's
another story.)

> * Simpler build and maintenance
> * Simpler programming

Depends on where you get your developers from. There are probably many
more people who can program in a POSIX environment than people who know
the John Doe API.

> Cons:
> 
> * Worse support (supported only by John Doe Inc. and its distributors,
> no match to Linux community)
> * Established bad reputation of dedicated RT/embedded OSes

Again "it depends".

Linux has the big problem that it's a very diverse project. There will
be drivers, libraries, etc. which run on thousands of computers 24/7.
And there will be code originating in a student project, running on an
obscure platform (maybe the one you're planning to use?). A coworker
occasionally talks about his nightmares with one such network driver:
probably the student passed his seminar at the moment ping worked, case
closed, next student please. So nobody notices that this driver leaks
memory for each packet received.

And you have the same problem with a commercial RTOS. Support quality
will always vary. Support for core components will typically be
magnitudes better than for more obscure "add-on" components which have
three users world-wide, which are there just for a new bullet point in
the glossy brochures.

The problem is: you don't see from the code which kind it is. So you
have to dive into its internals anyway.

> The question is: would you give a try for John Doe's RT/embedded OS?

Yes.


  Stefan

Stargazer wrote:


> I am examining a case for a new RT/embedded OS in today's situation. I
> would like to get a simple YES/NO answer from embedded developers.
> 
> Suppose that you are starting a new project. You are considering to
> use embedded Linux and you offered an RT/embedded OS by a vendor John
> Doe Inc.

It doesn't matter.
Whichever way you take, you will have to do everything yourself.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On 20/12/10 15:41, larwe wrote:
> On Dec 20, 8:08 am, Stargazer<stargazer3...@gmail.com>  wrote:
>
>> The question is: would you give a try for John Doe's RT/embedded OS?
>
> Ignoring the usual rabid foamings that FOSS kicks off in this NG, your
> question cannot be answered because the answer depends on many other
> things:
>
> a) have I already a hardware platform (implication: have I already
> allowed for the system footprint of Linux and therefore don't care if
> JDOS would save some footprint)? is there already a Linux BSP for it?
> is there a John Doe BSP or must I develop it from scratch?
> b) is there third-party IP I need to integrate? have the third parties
> already supported Linux? Is there any hope in hell they will ever give
> a damn about John Doe OS? Note this has nothing to do with your
> comment "we ported libraries". This might be proprietary software that
> you cannot access.
> c) will John Doe be around in 2 years? 5? 20? We have hardware
> platforms still in use that are almost 22 years old, running the
> original software stack.
> d) does my hardware/software toolchain vendor have explicit support
> for John Doe OS? There's a bit more to it than just gcc.
> e) how hard will it be for me to move JDOS project on HW platform #1
> to HW platform #2?
>
> Particularly your answer to c) would determine how likely it is I
> would pick it up.

There is also the point that this "John Doe OS" is a small-footprint 
RTOS, while Linux is a large-footprint general-purpose OS with wildly 
varying real-time functionality (depending on the distribution, 
configuration, platform and add-ons).  In other words, they are totally 
different systems for totally different applications.

Either the OP has no idea what he is talking about, or he is trolling in 
some way.

In message <ienog2$ksh$1@speranza.aioe.org>, Mel <mwilson@the-wire.com>
writes
>Chris H wrote:
>> In message <ea6af706-c355-457b-ac76-727186955caf@v17g2000vbo.googlegroup
>> s.com>, Stargazer <stargazer3p14@gmail.com> writes
>
>>>Cons:
>>>
>>>* Worse support (supported only by John Doe Inc. and its distributors,
>>>no match to Linux community)
>>
>> This is FUD RTOS support for the commercial RTOS I know if is much
>> better than for Linux.
>
>We haven't met John Doe Inc. yet.  I think that's the OP's point.

True but that does not mean it will be "no match to Linux community"
-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In message <jISdne_0BdsFGJLQnZ2dnUVZ8j-dnZ2d@lyse.net>, David Brown
<david.brown@removethis.hesbynett.no> writes
>On 20/12/10 15:41, larwe wrote:
>> On Dec 20, 8:08 am, Stargazer<stargazer3...@gmail.com>  wrote:
>>
>>> The question is: would you give a try for John Doe's RT/embedded OS?
>>
>> Ignoring the usual rabid foamings that FOSS kicks off in this NG, your
>> question cannot be answered because the answer depends on many other
>> things:
>>
>> a) have I already a hardware platform (implication: have I already
>> allowed for the system footprint of Linux and therefore don't care if
>> JDOS would save some footprint)? is there already a Linux BSP for it?
>> is there a John Doe BSP or must I develop it from scratch?
>> b) is there third-party IP I need to integrate? have the third parties
>> already supported Linux? Is there any hope in hell they will ever give
>> a damn about John Doe OS? Note this has nothing to do with your
>> comment "we ported libraries". This might be proprietary software that
>> you cannot access.
>> c) will John Doe be around in 2 years? 5? 20? We have hardware
>> platforms still in use that are almost 22 years old, running the
>> original software stack.
>> d) does my hardware/software toolchain vendor have explicit support
>> for John Doe OS? There's a bit more to it than just gcc.
>> e) how hard will it be for me to move JDOS project on HW platform #1
>> to HW platform #2?
>>
>> Particularly your answer to c) would determine how likely it is I
>> would pick it up.
>
>There is also the point that this "John Doe OS" is a small-footprint
>RTOS, while Linux is a large-footprint general-purpose OS with wildly
>varying real-time functionality (depending on the distribution,
>configuration, platform and add-ons).  In other words, they are totally
>different systems for totally different applications.

Yes I would have thought that Linux would have been head to head with
Embedded Win XP not an RTOS.

That said if you have a lot of Linux experience and use it for other
things  there are RT Linux about but it is hardly small for print.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In message <5f50c89a-47c3-4eea-8f85-aeec0258e2e2@j32g2000prh.googlegroup
s.com>, larwe <zwsdotcom@gmail.com> writes
>c) will John Doe be around in 2 years? 5? 20? We have hardware
>platforms still in use that are almost 22 years old, running the
>original software stack.

>Particularly your answer to c) would determine how likely it is I
>would pick it up.


This is important.  However it is not as obvious as it seems

Last time this came up and some one mentioned obsolete commercial SW
within an hour it transpired all of the list of half a dozen  commercial
systems that had been obsolete for 5-10 years could easily be supplied.

Ironically a few weeks later some one actually needed an obsolete
Franklin 8051 compiler from 14 years ago. IT was supplied in 4 days.

On the other hand, last time I looked of the 450+ named distributions on
the linux org site half were obsolete/unsupported.

Open Source does not always mean a long or easy supply route and
commercial does not always mean that the item will disappear even if the
company producing it does. All of the commercial RTOS I know are
supplied in source form anyway.

I know about 10 years ago a company did try and drop an RTOS (to move
the users to another one it had) but as the customers had the source
they mainly carried on, and AFAIK still do to this day.



-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/