>No Michael, it's not a bug. It's a design limitation. All designs have >them. Our design will too. Agreed. I came to this realization earlier. My mistake (this doesn't seem to be my day to be right). >I'm quite weary of people using the word "bug" to describe any >consequence they don't like. It waters down the meaning to the point >that it's no longer useful. A true bug is when the software fails to >meets the expectations for the environment it was intended for. You know - I got into a knock down, drag out arguement in my younger days with someone who made a bug list (20+) about software that I wrote, where there were no real bugs, but customer requested enhancements. Mea culpa. I should know better. >The main reason I dislike people using the term "bug" so generally is >that it puts an unspoken pressure on programmers to figure out all >future contingencies that will occur with their software. That is >absolutely impossible to do. The desire to try, however, wastes a lot >of time and generally produces code bloat. Right on. >Jeez, we haven't even hit this design limitation yet (how many users >have 1 gig+ RAM at the moment?) and it's already called a bug. Don't >get me wrong, this memory limitation is a problem and it will start >affecting users in the next year or two. It does need to be addressed >in the design of OpenBeOS. Agreed. >The real lesson here is that every design decision made has >consequences. Document those decisions! Inevitably, one of more of them >will turn out to prove limiting and will have to be re-engineered.