Mailing List Archive

On 03/23/11 05:46, Kfir Lavi wrote:

> I'm trying to migrate a big company to Gentoo.
> This company have a contract with Wind River for support and use.
> I don't have any experience with Wind River, so I would be happy to
> hear your experience with it, and what it's pros and cons.

> Regards,
> Kfir

All by yourself? That's a LARGE statement.

Wind River is the 600 lb Gorilla in the commercial
RTOS space. Everything from proprietary, to BSDish to embedded
Linux, state machines...... you name it they sell
(and mostly) support it.


Large companies use Wind River, because of many reasons,
but it is a "one stop shop" and Business managers
like that. Wind River can write (and often do) the
entire code for products or products lines, fast and
efficient. However, their "Achilles heal" is
they are EXPENSIVE to partner with; most often retaining
the intellectual property rights to all of the codes they
develop or sell.

Their business model is the "lock-in" and often, after years
of a relationship with a company, the victim (um, I mean customer)
finds out that WR is licensing the code to a competitor.....
Bad ju-ju, but legal and happens all the time.


So you are talking about helping a company take the "long road" to
freedom and profitability, via embedded Linux (Gentoo specifically).

Depending on the complexity of the of their codes, number of products,
etc, etc, you can easily be successful. However, be realistic. Pick
off the "low hanging fruit"; i.e. simple products to re-write the code
or new product offerings. WR will often get companies in a "tangled"
mess by the choices of processors, SOC, video chips etc etc where
NDAs and no published specifications make WR the only choice, or a
complete (hardware and software) redesign.

My advice:
Work smart, build a team (open source) that gradually assimilates
new products and the other easy "knock-off" and take your time.
Walking into a large company and pitching "kick WR out" is difficult
in many circumstances. Most of all, remember that in this company their
are managers that drink and eat and "sup" with WR and they have built
a career on a partnership with WR. They'll stab you in the back and
you'll never see it coming.

Also remember companies want to make a profit. So their management will
need "some sort of angle" as to what they have unique about their
product so other cannot just copy the code and sell it. When you
maintain proprietary source code, that is the lock for a company,
combined with patents. When you pitch open source solutions, you
and the company manager, must figure out a "unique" hook so as to
protect that company's investment and profit potential of the product
that is now open sources. YMMV.



Caveat Emptor!

But it is entirely doable depending on the "TEAM" you build as the
leader of this venture.

GOOD LUCK!
James

On Wed, Mar 23, 2011 at 3:49 PM, wireless <wireless@tampabay.rr.com> wrote:

> On 03/23/11 05:46, Kfir Lavi wrote:
>
> > I'm trying to migrate a big company to Gentoo.
> > This company have a contract with Wind River for support and use.
> > I don't have any experience with Wind River, so I would be happy to
> > hear your experience with it, and what it's pros and cons.
>
> > Regards,
> > Kfir
>
> All by yourself? That's a LARGE statement.
>
> Wind River is the 600 lb Gorilla in the commercial
> RTOS space. Everything from proprietary, to BSDish to embedded
> Linux, state machines...... you name it they sell
> (and mostly) support it.
>
>
> Large companies use Wind River, because of many reasons,
> but it is a "one stop shop" and Business managers
> like that. Wind River can write (and often do) the
> entire code for products or products lines, fast and
> efficient. However, their "Achilles heal" is
> they are EXPENSIVE to partner with; most often retaining
> the intellectual property rights to all of the codes they
> develop or sell.
>
> Their business model is the "lock-in" and often, after years
> of a relationship with a company, the victim (um, I mean customer)
> finds out that WR is licensing the code to a competitor.....
> Bad ju-ju, but legal and happens all the time.
>
>
> So you are talking about helping a company take the "long road" to
> freedom and profitability, via embedded Linux (Gentoo specifically).
>
> Depending on the complexity of the of their codes, number of products,
> etc, etc, you can easily be successful. However, be realistic. Pick
> off the "low hanging fruit"; i.e. simple products to re-write the code
> or new product offerings. WR will often get companies in a "tangled"
> mess by the choices of processors, SOC, video chips etc etc where
> NDAs and no published specifications make WR the only choice, or a
> complete (hardware and software) redesign.
>
> My advice:
> Work smart, build a team (open source) that gradually assimilates
> new products and the other easy "knock-off" and take your time.
> Walking into a large company and pitching "kick WR out" is difficult
> in many circumstances. Most of all, remember that in this company their
> are managers that drink and eat and "sup" with WR and they have built
> a career on a partnership with WR. They'll stab you in the back and
> you'll never see it coming.
>
> Also remember companies want to make a profit. So their management will
> need "some sort of angle" as to what they have unique about their
> product so other cannot just copy the code and sell it. When you
> maintain proprietary source code, that is the lock for a company,
> combined with patents. When you pitch open source solutions, you
> and the company manager, must figure out a "unique" hook so as to
> protect that company's investment and profit potential of the product
> that is now open sources. YMMV.
>
>
>
> Caveat Emptor!
>
> But it is entirely doable depending on the "TEAM" you build as the
> leader of this venture.
>
> GOOD LUCK!
> James
>
> Wow James thanks a lot for your insight.
It seems that WR is a giant BSP house, which is good for really preliminary
explorations of new hardware. I can see their benefit for an organization
that
don't really know what is Linux.
The company I work with have a lot of projects. Most of them relay on a
known
and debugged hardware. I'm not intending to change all of their working way,

but for a start I'm trying to push Gentoo in the project I'm working on, and
if it
does happen, it will propagate to other similar projects.
One important point you made is that WR keeps their intellectual property
rights
for helping you. I didn't know this.

Do you happen to know if they let you compile your project from source, or
they
give you binaries? How many packages I can expect them to support in their
tree?

Thanks for your answers,
Kfir

On 23/03/2011 14:54, Kfir Lavi wrote:
> Wow James thanks a lot for your insight.
> It seems that WR is a giant BSP house, which is good for really preliminary
> explorations of new hardware. I can see their benefit for an
> organization that
> don't really know what is Linux.
> The company I work with have a lot of projects. Most of them relay on a
> known
> and debugged hardware. I'm not intending to change all of their working
> way,
> but for a start I'm trying to push Gentoo in the project I'm working on,

I think the most important question for you is the "best tools for the
job". I can't answer that, but just some advocacy for gentoo as an
embedded tool, look back at the thread "Some good words for Gentoo
Embedded"?

I'm only building a small x86 board and I haven't mastered Catalyst so
I'm building my root using what is popularly known as "Tiny Gentoo".
However, the construction is incredibly simple and roughly my build is a
script which wraps something like:

ROOT=/builds/my-build emerge baselayout uclibc busybox openresolv\
dhcpcd dropbear your_other_stuff

And pretty much that's it, you have a working, bootable, build. Give or
take fixing a bunch of bugs in ebuilds which aren't tested on your
architecture, this means you now have the entire portage library at your
disposal for building your embedded system, and that's likely worth a lot?

I think you end up deviating from standard portage quite a bit for
embedded and surely lots of folks here have great experience that we
don't seem to share much? But I find for example I need a lot of
customised /etc/ scripts, or tweaks to init.d files, etc. It's tricky
to decide if these should be overlays added at the end, or to patch the
ebuild to install them pre-customised. I use a bit of a blend and
recently I have started trying to use /etc/portage/patches/cat/pkg
(badly documented) as a way to hook into ebuilds without having to patch
every version, forever, and lightly tweak the install.


I think "tools" are very personal and you can make a case for the tools
which fit your needs. However, I guess the point here is only that
Gentoo is a very nice tool for embedded and may meet the requirements of
many folks have, but who otherwise pass it over for more well known
alternatives.

Good luck and if you do use Gentoo, please share something on what you
learn?

Ed W

On Thu, Mar 24, 2011 at 3:13 PM, Ed W <lists@wildgooses.com> wrote:
> On 23/03/2011 14:54, Kfir Lavi wrote:
>> Wow James thanks a lot for your insight.
>> It seems that WR is a giant BSP house, which is good for really preliminary
>> explorations of new hardware. I can see their benefit for an
>> organization that
>> don't really know what is Linux.
>> The company I work with have a lot of projects. Most of them relay on a
>> known
>> and debugged hardware. I'm not intending to change all of their working
>> way,
>> but for a start I'm trying to push Gentoo in the project I'm working on,
>
> I think the most important question for you is the "best tools for the
> job".  I can't answer that, but just some advocacy for gentoo as an
> embedded tool, look back at the thread "Some good words for Gentoo
> Embedded"?
>
> I'm only building a small x86 board and I haven't mastered Catalyst so
> I'm building my root using what is popularly known as "Tiny Gentoo".
> However, the construction is incredibly simple and roughly my build is a
> script which wraps something like:
>
> ROOT=/builds/my-build emerge baselayout uclibc busybox openresolv\
>  dhcpcd dropbear your_other_stuff
>
> And pretty much that's it, you have a working, bootable, build.  Give or
> take fixing a bunch of bugs in ebuilds which aren't tested on your
> architecture, this means you now have the entire portage library at your
> disposal for building your embedded system, and that's likely worth a lot?
>
> I think you end up deviating from standard portage quite a bit for
> embedded and surely lots of folks here have great experience that we
> don't seem to share much?  But I find for example I need a lot of
> customised /etc/ scripts, or tweaks to init.d files, etc.  It's tricky
> to decide if these should be overlays added at the end, or to patch the
> ebuild to install them pre-customised.  I use a bit of a blend and
> recently I have started trying to use /etc/portage/patches/cat/pkg
> (badly documented) as a way to hook into ebuilds without having to patch
> every version, forever, and lightly tweak the install.
>
>
> I think "tools" are very personal and you can make a case for the tools
> which fit your needs.  However, I guess the point here is only that
> Gentoo is a very nice tool for embedded and may meet the requirements of
> many folks have, but who otherwise pass it over for more well known
> alternatives.
>
> Good luck and if you do use Gentoo, please share something on what you
> learn?
>
> Ed W
>
>

Oh,
I find it very hard to share or document what I'm doing. I really want
to do it,
and my gentoo blog really needs some new content, but I just don't have time.
I'm working everyday until 22:00 and my 7months son also needs me, so I really
try to be everywhere.
I'm pushing Gentoo, because it can be tailored automatically for a lot
of projects.
From small devices to a cluster. The initial go is very hard with
steep curve, but
what I aim for is the ease of use and replication when problem strike or when
moving to new project.
As for Catalyst, I'll try to post my conclusion about this tool for our use.

I'll try to document more what I'm doing.
Regards,
Kfir

On 24/03/2011 14:33, Kfir Lavi wrote:
> As for Catalyst, I'll try to post my conclusion about this tool for our use.

If you want a proper build tool then obviously consider Catalyst, but
also take a peek at the Funtoo build tool? I have never used it, but
there are some interesting claims on the Funtoo blogs that suggest it
might work nicely for some uses?

Good luck

Ed W

Hi

Am 24.03.2011 14:13, schrieb Ed W:
> I use a bit of a blend and recently I have started trying to use
> /etc/portage/patches/cat/pkg (badly documented) as a way to hook into
> ebuilds without having to patch every version, forever, and lightly
> tweak the install.

what type of patches belongs there? are this patches to the ebuild
itself or patches which get applied in ${S} automatically (like
epatch_user).
So if you already have experience with it and you say it's badly
documented, can you share your experience?

Cheers

On 25/03/2011 09:01, Martin Gysel wrote:
> Hi
>
> Am 24.03.2011 14:13, schrieb Ed W:
>> I use a bit of a blend and recently I have started trying to use
>> /etc/portage/patches/cat/pkg (badly documented) as a way to hook into
>> ebuilds without having to patch every version, forever, and lightly
>> tweak the install.
>
> what type of patches belongs there? are this patches to the ebuild
> itself or patches which get applied in ${S} automatically (like
> epatch_user).
> So if you already have experience with it and you say it's badly
> documented, can you share your experience?

Well, you can only use /patches/ for certain well behaved ebuilds that
run certain ebuild functions (forgotten the specifics, check the docs?).
So this limits it's usefulness generally

Additionally you can do something somewhat similar using pre_/post_
hooks in portage/env/...

Both methods feel a bit clumsy to me, and I think they should mainly be
used for patches/fixes which you expect to apply on a long term basis
and don't expect to evolve particularly on a version to version basis.
eg patches to default configs/scripts or patches to relatively stable
chunks of code that upstream is unlikely to change

I think for bug fixes or stuff which is expected to change imminently,
or stuff which is specific to a code version then it's much neater to
use a modified ebuild in some local portage tree

The big negative on the /env/ and /patches/ method is that they aren't
self documenting, unlike a local portage tree which is shown explicitly
in the output of emerge. I think this is the big dictator which guides
when it's appropriate to be used?


I also use a file overlay tree as the final step of my build process.
This leaves a big separation between the files and the packages they
came from. Also if it's a small change from a default config then it's
not self documenting (consider that upstream makes a large change - how
to patch that change in our overlay). Hence I prefer to use patches
where possible, keeps it closer to the package, and keeps it self
documenting. The overlay is most useful therefore for large config
deviations (usually specific to the final environment)


Good luck

Ed W