[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [olpc-software] Package manager stuff



On Tue, 2006-03-14 at 17:06 -0500, Alan Cox wrote:
> Ah but the existing applications don't know that. So if you watch one directory
> in the file manager and you edit the underlying view what occurs. 

You're right! Darned facts :) I don't know, what does occur? 

I'd expect the change to be reflected up, so if I'm watching a directory
that is a composite of A and B, and a file is added in A then the watch
says "new file!". And if a file with the same name is then added to B,
nothing happens, because the file in A overrides it and so nothing has
changed view-wise.

> Then there is
> the whole problem of union mounts of an underlying changing network file
> store, which raises horrible questions about semantics and which the FUSE
> work just armwaves.

Hmm, what kind of questions? I'd expect the semantics of file watches on
unions to be something like "if I can compare two snapshots of a
directory and see the difference then there was a change, otherwise
there wasn't". So it would work the same as a naive polling based
implementation would. Why is that affected by network vs something else?

> Must be a different planet to the one I live in. 

Well, most problems I get asked to fix with Windows boxes these days are
spyware/malware related. I don't remember the last time something broke
because an installer downgraded a shared library. That's partly because
modern installers (newer InstallShields, NSIS, etc) are careful not to
do that, and partly because the core libraries MS distribute are pretty
much stagnant (and get new names when they are changed).

> That rules out libjpeg, 

not if accessed via gdk-pixbuf

> openssl

yes. gnutls is a workable replacement. As many apps will need adapting
anyway this is OK.

> python

100% Pure Python programs perhaps not. Mixes of Python/C apps
unfortunately yes. But Python has quite terrible memory usage so might
be ruled out on those grounds anyhow.

> perl,

perl 5 is static/stagnant enough that I doubt it'd cause problems, but I
am by no means a Perl guru. If/when Perl6 finally does arrive it would
be a new platform component and by the time the OLPC platform gets
revised, hopefully Flash storage would have got cheaper and it's OK to
add some new stuff.

> the kernel

Outside of the syscall interface the kernel isn't a platform and has
never pretended to be, and even then things that userspace apps use
like /proc have somewhat vague compatibility rules. So this doesn't
change anything. 

Like it says on the wiki page, something can be used as part of the
system but not be a part of the platform.

> It also ignores the fact it will occur by
> accident even with testing tools, and that that ABI/API is only half the
> problem, apps break because of assumptions about internal behaviour that
> is inevitably observable in things like callback order, or by doing invalid
> things that "used to work".

Agreed, and I've debugged many such programs myself. It's tough, but
it's also doable, and whilst you will never get it perfect it still
beats throwing our hands in the air and saying "screw this platform
thing! it's hard!". Unknown compatibility breaks aren't fixed by package
management anyway, you still have to know they've occurred to rename the
package/make it parallel installable.

thanks -mike


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]