[LinuxBIOS] Infamous __stack_chk_fail problem.

[Steve Isaacs]

On Mon, 2007-12-03 at 10:40 -0700, Jordan Crouse wrote:

> You don't have to worry - as you can infer from the e-mail address, I am
> keenly aware of the challenges that we have to face for commercial adoption.
> It is one of my primary goals to ensure that LinuxBIOS becomes and stays
> a viable option for commercial vendors.  
> 

I'm sorry, I didn't mean to imply you are not aware of the issues. I
just wanted to change the focus a bit. I did notice your e-mail address
and was tempted to use that as a case in point but chose not to. I have
a lot of respect for your employer.

> That said, you have to understand that LinuxBIOS and Linux and indeed
> all of open source will continue to constantly be a moving target.  
> Every day the open source environment presents us with a slightly different
> view of the world as it twists and turns and evolves.

Most products, open-source or not, are moving targets in the end.
Commercial products are continually repaired and enhanced to satisfy
customer requirements. But, for commercial viability, plateaus have to
be established and maintained.

> When I write code, I imagine that every open source project is a train,
> constantly rolling toward an unknown destination.  At every stop, new
> people are introduced to the project and get on board.  They may have
> heard about the project at a conference, or on a slashdot posting, or
> just stumbled across it on freshmeat.  However they got here, something
> compelled them to board the train.  Whats more, they are going to
> bring some sort of baggage with them - different distributions (or even
> operating systems), different languages, and different experiences.
> 
I like your analogy. It reflects how the company that pays my salary
decided to "board the train" as you put it. As a new passenger here I'll
have to defer to your experience. It is not my intent to derail the
ideals of an open source project.

> Our job is to make sure that every new person that boards the train is
> immediately satisfied; because their first perceptions of the code 
> are what determines if they stay or if they immediately get off the train.
> 
Please remember that it is --my-- job to satisfy customer requirements
on or before the deadline. These obviously are conflicting perspectives.
A solution everyone can enjoy requires time coupled with a willingness
to wander. This may not always be conducive to meeting a deadline which
requires focus and limited time. I'm hoping I can suggest a means to
mitigate both.

> This is why we (the project) doesn't want to start dictating terms like
> compiler versions and the like. 

I would never suggest dictating terms. If that were the case I would not
be a "passenger" now. I was simply trying to suggest a means for
reducing risk by increasing confidence through having repeatable
releases. Nothing more.

Steve

btw: the opinions I expressed here are my own.