On Nov 8, 2007, at 10:42 AM, Albert Cahalan wrote: > One failure is no excuse to purposely fail in every way.
It's not a purposeful failure. We're imposing non-obvious changes on semantics due to restrictions in our environment, such as a strict limitation on the size of /tmp. I'd _much_ rather have my application break during porting when I try to write to /tmp, at which point I go and think about where it should be writing instead, than to have it explode in strange ways when further writes to /tmp start erroring out because the (small amount of) space has been exhausted. If I'm in the minority with this sentiment, I am open to revising the policy. > This is nothing new. It's been standard on SunOS for ages. > The /tmp directory is in RAM, and /var/tmp is on disk. A tiny size restriction is pretty new. > You are not so special that you need to break everything. I am a uniquely special snowflake of unique specialness. > If you don't solve it, people will just turn Bitfrost off. Bitfrost is not a general Linux distribution security mechanism. Sugar is not a general Linux desktop environment. These things are designed with different goals in mind, for a different purpose, and behave differently than the things you're used to. You can argue that our designs are wrong and the behaviors broken, but even that's for the most part orthogonal to the argument that the designs should be such that everything old continues to magically work. Backwards compatibility, quite simply, was not an OLPC design goal, and while I am happy to not deviate from old behavior superfluously, I also have an interest in doing the right thing for the new platform, especially when dealing with ambiguity. At the moment, I regard the /tmp situation as ambiguous and misleading. -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel