Paul Boddie wrote: >> implement the lowest common denominator of all OS resource managements to >> be platform independent, which is a strong requirement, IMO. > > I think I understand what you intend to say here: that some kind of > Python sandbox relying on operating system facilities can only depend > on facilities implemented in all of the most interesting operating > systems (which I once referred to as "the big three", accompanied by > howls of protest/derision
Oberon, Plan 9 and AmigaOS...? ;-) > ). Yet just as people like to say that > choosing a language is all about "choosing the right tool for the job", > shouldn't the choice of operating system be significant as well? Yes, it should. But it isn't most times, I think. Often you have the situation to run a certain app e.g. on a OS that you can't simply exchange to your needs, for example the game server you mentioned, if this should run on an external host which is not maintained by you. Personally I would always prefer an OS independent solution, because it makes you more flexible. Some OS may be a good choice at a given time, but after you app has grown up, you may come to the decision to change the OS for some reason, but can't because you app depends on some of its specific features. Especially for apps written in a scripting language I would try to avoid that. > If > you're running a "Try Python" Web site, as some people were doing a few > months ago, isn't it important to choose the right operating system as > part of the right complete environment, instead of having the > theoretical possibility of running it on something like RISC OS, yet > having someone take your site down within seconds anyway? I don't know > whether it's the same people who like to promote "how well Python plays > with everything else" who also demand totally cross-platform solutions > ("if it doesn't work on Windows, we won't do it"), but if so, I'd be > interested in how they manage to reconcile these views. I'm afraid, we can't have a perfect world... But as I stated in another posting before, I think it is possible, to get a secure execution environment in a platform independent manner. The Tcl people did it and since I made myself already very unpopular at c.l.tcl by requesting some of Pythons goods for Tcl, I can do the same here by requesting some of Tcls good inventions for Python... ;-) > The emergence of virtualisation as a commodity technology would suggest > that sandboxing language runtimes isn't as fashionable as it was ten > years ago. Virtual environments are a good choice for some of the tasks that were done with sandboxes in the past. But I'm afraid, that they are too huge for many problems. Imagine running an instance of a virtual machine on a mobile phone, or needing to execute some hundreds of them in parallel on a game server (or CGI) which itself runs on a virtual host at your webhoster, and of course none of them should be able to kill it's neighbours, so all of them need their own VM... phiu, that would need a really big iron. So the the idea of VMs _is_ a good one for certain situations, but the need for secure execution environments inside an interpreter remains. Regards Stephan -- http://mail.python.org/mailman/listinfo/python-list