
To view parent comment, click here.
To read all comments associated with this story, please click here.
I agree to some extent but with a few exceptions.
Porting to Xbox means supporting one HW (as the HW is identical in each box). The HW (if not aiming for 360) is x86 right? So no difference here either...
And otherwise it's a question about someone adding something into the kernel/Xbox tree which really don't affect things at all if not compiled with the right flags right?
On the other, I do get your point with every line is critical and focus of the project etc. Still, I don't think this will affect those critical lines very much...
Maybe for you FreeBSD is an OS to toy around with, but for some of us it runs mission critical applications for corporate environments.
Oh please, drop the "I'm teh serious user" routine. Using "mission critical" in "corporate environment" to sound more convincing is like Ballmer using "innovation" all the time.
With this in mind you would not like the idea that extra code for (for my purposes) useless xbox might instabilize the entire thing.
This is just plain silly. Do you use pc98 boxes in your mission critical corporate environment? If not, why don't you demand removing support for it, since it is useless for your purposes... What about alpha or sparc? I can't believe that I'm arguing with you on this btw... When did FreeBSD's support for one arch or another slow down a release process? (hint - the kld support on ultrasparcs is on the todo list since I've been using FreeBSD) Or by the same logic, why not strip out bktr support? It means more lines, more bug possibilities, and it is obviously not useful in your corporate environment
Those resources could IMO be better spent.
Please, tell the guy to stop working on something he wants and likes to do - and work on things you deem useful.
My point is: the issue is blown out of proportions. Like others said - it won't affect the stability of your system (and bugs on xbox won't slow down releases, just like missing kld support with ultrasparcs didnt'). How many of the showstopper defects could be (taken the 6.x release cycle) traced back to supporting various archs? (I'm not talking about x86-64, which is obviously a very important platform). None. If anything, adding support for different archs (although the xbox is not that different) may expose bugs that would be difficult to find otherwise.
Ciao.
[Now I'll go back to toying while leaving you to your mission critical work in your corporate environment )))]
Member since:
2005-07-26
Maybe for you FreeBSD is an OS to toy around with, but for some of us it runs mission critical applications for corporate environments.
With this in mind you would not like the idea that extra code for (for my purposes) useless xbox might instabilize the entire thing. Every line of code is a potential bug.
The time spent on porting is not the time-waste i'm worried about. its time thats wasted during bug-hunts and such things which are the cullprit here.
It doesn't stop with just merging the code. You need support for it and what not. Those resources could IMO be better spent. And lets be honest. FreeBSD's stability has not made much fame since the introduction of 5.x