On Wed, Jul 16, 2008 at 06:52:28PM -0400, Michael Stone wrote: > Do you require more justification?
Yes, qualified: not now, being the main qualification. Tell everyone to sod off and wait until update.2's out :). Wait til then unless you cannot, and in that case just declare something by fiat and tell people to wait a month or two. > Regards, > > Michael Martin PS - I read your cited wiki pages (even found myself tangentially included in one tiny circumstance) and I think most of the confusion/discussion is *not* about why the package manager / updating process needs to be done by olpc-specific code, but how the olpc-specific UI thereunto needs to be managed. I think you're scaring the pro-package managers away unnecessarily: your specific objections fall into two categories: 1) ones for which a credible, (olpc) implemented solution exists; and 2) ones lacking that (unrealized or unrealistic - 1 to 3 yrs out - goals). For Category 1) objections, existing package managers can be improved, as they're goals of a large portion of big package managers' users (yum's, at least :)). For Category 2) objections, unless you have a credible plan to implement such features, it seems unusual to justify the time spent re-implementing package managers' features with the reason they have some unimplemented features. To support this classification and its conclusion: > - Our users often can't make informed decisions about what software > they should be running. Category 2) You're saying that your average Windows/OSX/Ubunto/Fedora/Debian user does? Most of the time they either don't even recognize a software updater[1] or never, ever want to change *anything* once it's working (which of course everything shipped with an XO does/will ;)). I can stop right there, I think, to make this point: this is mainly a UI issue. > - Our users probably do not have root on their machines, yet still > need to perform package-management-like tasks. Category 1) (arguably, though how many people that want to do "package-management-like" tasks have succeeded without root? You've seen the "my activities are all gone, what do I do?" questions on IRC, which means people have gotten past using root :)). And aren't you contradicting yourself? Just previously you said "our users can't make informed decisions [about package-management-like tasks]" and now you're saying "[our users] need to perform package-management-like tasks", IIUC. > - In addition to accepting code hierarchically from upstream > providers, we want to share code fluidly between XOs. Category 2), but if it were 1), this seems less a package formnat/management issue and more a Journal/Shell UI one. > - We want the software we provide to support a higher standard of > security (defined in Bitfrost) than other systems strive to provide. Category 1) for "software we provide", even though I don't think package managers/formats need inherently get in the way of Bitfrost (their UI or assumptions about where package contest *go* might, but...that's UI or per-package assumptions, not package formats), no? Category 2) for "software we have made possible but others will provide". > - We must attempt to minimize bandwidth usage while moving bits > around and must tolerate long networking delays. Category 1). > - We cannot rely on any established public key infrastructure to > verify the identities of code providers or the authenticity of the > code they are providing. Category 1) > - We expect users will be constantly redistributing modified versions > of software that they downloaded to their systems. Category 2). You say that "our users often can't make informed decisions about what software [versions] they should be running", and yet you want them to be constantly redistributing modified versions? UI issue at worst. > - We expect that our user groups will, in general, NOT share common > languages with one another (or, necessarily, with us). Category 1) (and isn't this already the case for other package managers?) > - We expect that many users will be translating their own > - software. Category 1) > - We MAY NOT assume that users have global connectivity with which to > satisfy dependencies, verify claims about information, distribute > their work, etc. Kind of broad, but either it's a trivial, Category 1) problem (distribute an xo/rpm), or a hard one - satisfy dependencies of such an rpm/xo - which is Category 2). 1. Many people *that I observe daily* either a) have had "System Updater - iTunes updates ready" windows showing on their desktops for weeks (nice machine uptime, I know), or b) just click "Reboot later" every time MS Automatic Updates bothers them until they either disable it or give in and reboot.
pgp3vHxvrtqwV.pgp
Description: PGP signature
_______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
