Peter Robinson wrote: >> In an LTSP environment, no sysadmin is going to choose a policy that >> allows users to install packages, even trusted packages, to the root >> system, or otherwise make any sort of modification that cannot be >> trivially and reliably wiped clean. PolicyKit will work fine, in that it >> will happily enforce the policy, which is "no installation allowed". > > In an LTSP environment surely you'd want it all centrally managed by > an admin
That's probably what the admin wants, but it's not at all what I want. This is an education project. Our educational philosophy says that we can best help kids to learn by providing them a sandbox in which they can safely use these computational power tools however they want. That includes exploring the now hundreds, and eventually thousands, of available activities, installing them, and tinkering with them. Locked-down, admin-controlled desktops for education are already available. We don't need to build another one. > so each device/server doesn't end up with 50 copies of > different versions of the same activity installed. It would be a > support nightmare, take up massive amounts of extra resources that it > need not do so and no doubt other issues that I haven't thought of > like issues with collaboration etc. These are serious challenges, but I think we need to solve them, not avoid them. That means content-addressed storage systems for minimizing redundancy of similar activities. It means reducing memory usage, maybe using PyBank [1]. It means dynamically installing activities during collaboration to ensure compatibility. All of these things have been part of our roadmap for years. Eventually, we will get there. --Ben [1] http://blog.tomeuvizoso.net/2009/05/reducing-sugars-memory-usage.html
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
