public inbox for
 help / color / mirror / Atom feed
From: "Richard Rauch" <>
To: <>
Subject: Re: [ECOS] Re: is eCos dying?
Date: Tue, 06 Oct 2015 07:51:00 -0000	[thread overview]
Message-ID: <00d901d1000b$cadebbd0$609c3370$> (raw)


my opinion is quite differently:
You do not see a lot of activities in the eCos community because of politics
and commercial interests.

My company was very active in eCos projects (specially porting projects and
development toolchain) within several years.
Beside several application projects based on eCos we have made a couple of
portings to different processor platforms for microcontroller vendors
(Atmel, Xilinx) and OEMs.

We tried to commit all this ports to the community! Specially one of the
OEMs (Softing AG, Munich) was very active by himself in this commitment
activity as well.
But from eCos maintainer side there is no interest to overtake such ports.
This is just a guess, but in my opinion the reason for this is, that the
maintainers of public eCos are as well strongly commercial oriented. 
It seems, they will not put any port to official open source repository if
it could disturb commercial interests (eCosCentric/eCosPro...).

I will give just one example when we tried to make a port public:
further activities, if you search for in detail:
beside this there was email traffic as well with the maintainers, but
finally there was no success!

Additionally I need to say, that you will be thwarted, if you try to offer
commercial activities as well. If you are not absolutely carefully about
usage of eCos name and logo, you will get some letters from eCosCentric's

In consideration of our experiences I do not wonder, that the audience is
losing interest in eCos and is searching for alternatives.
We have already customers, who decided against eCos specially because the
fact, that there is dramatically decreasing activity in the community!


> Von: [mailto:ecos-discuss-
>] Im Auftrag von Grant Edwards
> Gesendet: Sonntag, 4. Oktober 2015 17:00
> An:
> Betreff: [ECOS] Re: is eCos dying?
> On 2015-10-04, Stanislav Meduna <> wrote:
> > On 03.10.2015 10:15, John Dallaway wrote:
> >
> > Hi Abhishek,
> >
> >>> Would it be worth to start learning on eCos or is it dying ?I have
> >>> seen enough activity in 2007 but now it is minimal this year.
> >>> Is it getting outdated?
> >
> >> eCos is not dying, but I would have to agree that there has been less
> >> activity on the mailing lists recently.
> >
> > Well the last commit in is 5
> > months old one-liner, followed by a 12 and 15 month old ones, so this
> > is not only on mailing lists. I'd say that while it is still a good OS
> > with clean and easy to use architecture, the open source version
> > basically died and there are parts hopelessly outdated (TCP/IP from
> > ~2000 if I remember correctly etc).
> >
> > I cannot comment on eCosPro, but then you are in a price segment where
> > there are more alternatives to explore.
> >
> >>> should i begin to work using eCos or should i look for other
> >
> > It depends on what your short and long-term plans are. Definitely also
> > take a look at FreeRTOS.
> I also am commenting strictly on the open-source version, not on
> I've been using eCos since the Cygnus days (around 1999 or so).  I've been
> pretty happy with it, but the open-source version is getting pretty stale.
> particularly worried about the ancient FreeBSD network stack -- but it
> seems to be working OK, knock on wood.
> I'm also concerned about what's going to happen when my customers
> starting actually using IPv6 in anger.
> Getting the two BSD networks stacks integrated into eCos was an impressive
> feat of engineering. But, a square peg in a round hole is still a square
peg in a
> round hole no matter how much you admire the craftsmanship of the shims.
> I've often wished I had a few spare weeks to experiment with LWIP.  I have
> the impression that it's a better fit for eCos and would be easier to keep
> current.
> If I were starting from scratch these days, I'd probably look first at
> other than eCos. I've never needed the full-up POSIX or uItron adaptation
> layers, so for my smaller projects I'd probably lean towards something a
> lighter-weight like uCos-II/III (not free) or XMK (which also seems to be
> languishing a bit).  FreeRTOS would also be at the top of my list of
> -- even though I find the web-site a bit off-putting.  I'd probably use
Linux for
> bigger, more complex projects that are "not quite as real-time" and could
> benefit from the Unix memory protection and process models.
> --
> Grant
> --
> Before posting, please read the FAQ:
> and search the list archive:

Before posting, please read the FAQ:
and search the list archive:

             reply	other threads:[~2015-10-06  7:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-06  7:51 Richard Rauch [this message]
2015-10-06 12:59 ` Mikhail Matusov
2015-10-07  9:59   ` AW: " Richard Rauch
2015-10-12 23:57 ` Jonathan Larmour
2015-10-13 12:31   ` David Fernandez
2015-10-14  0:57     ` Frank Pagliughi
2015-10-13 17:20   ` Grant Edwards
2015-10-13 19:38 ` Alex Schuilenburg
2015-10-14 23:05 ` Sergei Gavrikov
     [not found] <>
2015-10-03  8:15 ` John Dallaway
2015-10-04  8:30   ` Stanislav Meduna
2015-10-04 15:00     ` Grant Edwards

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='00d901d1000b$cadebbd0$609c3370$' \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).