I sympathize with Albert's point here: we should be no more incompatible than we have to be... Just because we have to break some things, doesn't mean we have to break everything. - Jim
On Thu, 2007-11-08 at 10:42 -0500, Albert Cahalan wrote: > On 11/8/07, Ivan Krstić <[EMAIL PROTECTED]> wrote: > > On Nov 7, 2007, at 9:09 PM, Albert Cahalan wrote: > > > > Using standard directories is not scribbling all over > > > the filesystem! > > > This anti-compatibility attitude needs to stop. It's really > > > hurting OLPC, needlessly making the goals harder to > > > achieve. Breaking compatibility is something to be done > > > as a last resort, when no alterative will work. > > > > For better or for worse, compatibility has been broken, and on a > > level as fundamental as file access. If an application can't even > > access the user's files without being aware of the datastore, what > > good is it to pretend that providing small bits of backwards > > compatibility will make things substantially easier? > > One failure is no excuse to purposely fail in every way. > > Not every application even needs access to a user's files. > > The datastore has changed and apparantly will change. > Perhaps it can someday be less awkward to deal with. > > In any case, yes, it is extra work and ugly code. > You're affecting every porting effort; it must be easy > to make that decision when it's somebody else's > code base getting screwed with #ifdef everywhere. > > > For us, $SAR/tmp lives in RAM and is severely limited (maybe to as > > little as 1MB per application). $SAR/instance is used for transient > > per-instance disk-backed storage. Since it's a given that work needs > > to be done to port applications to Sugar, it's a _good_ thing that a > > programmer is also confronted with the decision as to which of these > > two temporary directories to use. Enabling a wrapper for /tmp would > > have us make that decision for them, and as fellow Python programmers > > know: explicit is better than implicit, and in the face of ambiguity, > > refuse the temptation to guess. > > This is nothing new. It's been standard on SunOS for ages. > The /tmp directory is in RAM, and /var/tmp is on disk. > You are not so special that you need to break everything. > AFAIK, this is even a common (normal?) setup on BSD. > > BTW, if you're going to keep calling it $SAR, then you'd > better make that the real name of the variable. > > > > The long-term goal should be to support solid sandboxing > > > of true all-over-the-filesystem software installs. This may > > > need a unionfs filesystem so that files can be put everywhere > > > without the dummy files needed for file-on-file bind mounts. > > > Imagine if you could install any RPM, knowing that it had > > > no way to corrupt your OS. > > > > That goal is not something I'm spending much time thinking about. The > > level of protection provided by Bitfrost is not something you can do > > without serious compatibility breaks with how things are done at > > present. > > If you don't solve it, people will just turn Bitfrost off. > _______________________________________________ > Security mailing list > [EMAIL PROTECTED] > http://lists.laptop.org/listinfo/security -- Jim Gettys One Laptop Per Child _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel