[Fedora-electronic-lab-list] Re: Embedded SIG

[Ralf Corsepius]

Chitlesh GOORAH wrote:
> On Mon, Feb 16, 2009 at 7:22 AM, Ralf Corsepius wrote:
>> The actual problems with embedded packages are elsewhere:
>> - Their target audience is comparatively small
>> => Little "end-user demand", little "developer interest".
> 
> Hello Ralf,
> 
> You are quite negative on this embedded solutions on fedora.

Well, I regret if it sounded this way, however what I wrote is based on 
personal experience, both as RTEMS upstream maintainer and as Fedora 
contributor.

Let me try to elaborate:

>> The actual problems with embedded packages are elsewhere:
>> - Their target audience is comparatively small
>> => Little "end-user demand", little "developer interest".

Fact is, our user-base is small and doesn't overlap much with Fedora's 
user-base.

It's just that most of the people who develop RTEMS (me being one of 
these) happen to use Fedora, while the community which is developing 
applications with RTEMS and contributed to RTEMS happens to use many OSes.

Adding to this, is the fact that professional embedded applications[1] 
tend to have very long life-/support-cycles and users using other tools 
which are not available on each host OS. All in all this leads to a 
tendency of RTEMS users to apply "caged and/or frozen" devel 
environments and them to be ultra-conservative OS-choice-wise.
=> RTEMS's user-base is not necessarily Fedora's user-base.

Now, some of you likely will want to point to CentOS. Yes, CentOS is 
quite suitable for users who have application in "long term/keep alive 
maintenance". Unfortunately CentOS is too outdated when it comes to 
upstream RTEMS development.

Here, instead of replacing packages from CentOS, our escape is to ship a 
caged development suite (installed to /opt/rtems-<version>) ourselves.

>> - Embedded packages tend to be huge.
>> => Mainstream users will accuse "Embedded stuff" to unnecessarily bloat Fedora.
The size of the Fedora RTEMS toolchain packages alone (not taking into 
account the other OSes we are supporting) are measured in GigaBytes.

I for one don't have much of a problem in adding this amount of packages 
to Fedora, but will the community be willing to accept this?
I would expect no, because related complaints already have popped up 
several times before.

>> - Embedded packages tend to be technically complex (e.g. cross-compilation) and to diverge from "native packaging" (e.g. shipping source code as contents)
>> => Fedora's review/maintenance infrastructure (reviews) and tools (esp: rpm) are not in a shape to make "getting such embedded packages into Fedora" easy. They often end-up in rejected, withdrawn submissions combined with endless discussions on details.
Well, there is nothing much to add. It's simply a fact.

Packaging cross-toolchains is complex due to it tripping over many 
pit-falls lurking inside of the "Fedora eco-systems", notably rpm.

>> - Due to the limited audience of "embedded products", the overhead/difficulties getting packages into Fedora implies and different objectives ("embedded vendor" vs. Fedora/RH), vendors of "embedded products" tend to provide packages of their own.
>> => Adding their packages to Fedora is of limited interest to them.
I once had submitted some rtems packages, but ... after they had been 
lingering around unattended in the review queue for many months (IIRC > 
1 years), I turned away and withdrew them.

... the sad thing about this: These had been the simple packages - The 
really complex ones had not even been submitted [2]

> FEL apps are mostly ASIC oriented and the target audience is even
> smaller than embedded. 
ASICs are not my domain, but I would not want to deny this thought.

> Nevertheless, FEL did attract a fair number of
> eyes. We currently have a good set of embedded solutions included on
> fedora (thanks embedded sig). I would rather wish little by little we
> shape that field for better design experience. I need your support on
> this :)

Welcome, I am willing to help.

Ralf

[1] RTEMS is e.g. being used in automotive, automation/control, flight 
and space applications.

[2] RTEMS is using newlib (The same libc cygwin uses as libc).
Last time I counted, newlib had consisted of files using 28 different 
licenses :-)