On Friday 04 February 2005 08:45 pm, Sven K�hler wrote: > I feel like this is a slap in Jeff's face, since i thought > that UML will be developed as the first choice in virtualizations > techniques.
Yup, just like the inclusion of reiserfs in the kernel is a slap in the face to ext3. Obviously they did it just to be insulting, didn't you read Linus's "I'm a bastard" speech? > So what is it all about? When should somebody chose Xen, and when should > somebody chose UML? and how will UML and Xen compete? You know, ever since the release of the BSD source code in 1992 totally derailed that "Linux" project people were playing with back then, this kind of question has become vitally important. The release of any remotely similar project obviously can immediately halt all development of established projects that developers have sunk years of effort into, and they immediately start porting over things like the COW mounts and hostfs and honeypot procfs, and rewrite all the existing tutorials and retrain everybody overnight to work on the new as yet untested thingy that hasn't been particularly debugged yet. Especially in a case like this, where Xen actually competes with VMWare rather than UML. Obviously, UML is doomed. What with Xen requiring a modified host kernel to provide its virtualization environment whereas UML uses the process abstraction to virtualize it: I mean, who's going to use _processes_ in five years, will future kernels even bother to support them? Sure, UML not only runs on an unmodified Linux kernel (even running a 2.6 UML on a 2.2 host kernel), and even an effort underway to get it running on windows (who knows why, but a MacOS X host can only be a matter of time), but that just means maybe it can scrape on some tiny niches once it's driven off Linux by this new "Adeos" thing... Er, I mean "Plex86"... Um... "Xen", that's it. And obviously its original use as a Linux development tool letting you do things like create a filesystem driver and mount an instance of it without destablizing your host kernel, or run bits of the kernel under normal userspace debugging tools... Well, we're well rid of that, aren't we? And being to swap kernel memory to backing store just like a regular application, that was obviously a bad idea from day one... Why was the question interesting again? Rob ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
