I don't think that's necessarily true for non-developer users. What if
your global zone ran the desktop, you're browsing the web, download a
cool program or interesting content file. Wouldn't it be convenient if
an agent in that global zone found an appropriate (and secure)
zone/container/vm to run that content within? It might not be foolproof
with the current state of MIME types and ELF headers, but I don't see
any reason why OpenSolaris couldn't hide most application environment
requirements from the user. Of course developers will always try to
unearth these details:
Browser running in global "Classic Solaris zone"
- Java VM (Yes the VFS MIME handler should be able to find a Main() in a
Jar and just run it.
- Punk Solaris Zone for those applications which prefer to live in a
GNU-like environment.
- Linux zone(s) for applications hard-coded to specific Linux
kernel/libc version.
- XEN for things which require a native OS (e.g. MS Windows, OSX)
Obviously some of these application runners would require a download,
install and license, but if the framework existed, a solution would at
least be possible. One other issue is the UI, it's unlikely that
Windows, Linux and Solaris apps would have similar UIs.
MC wrote:
You can't do that with zones as they stand now. There's a whole list of
things you can't do in a non-global zone. So you'd have to pick one
environment for the global zone (which can do everything you want), and
then one for another zone (which can't do a number of things).
The topic under discussion is giving the user two experiences to choose from.
Only one experience would ever be used at a time, so if zones were used to do
this, non-global zones wouldn't even factor in. You'd just let users choose
between two global zones. (whether or not the plumbing is there to easily
allow that is another question :))
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
