QENU: The Open Source Virtualizer
According to its home page, "QEMU is a generic and open source machine emulator and virtualizer."
I started playing with QEMU 695 days ago, and have made three posts about QEMU:
- QEMU: The Open Source Processor Emulator (648 days ago)
- QEMU: Just How Fast Is It? (577 days ago)
- QEMU: Gentoo Guest Performance (558 days ago)
Unlike treating it like many of the other technologies that I took a look and then forgot about, I kept on using it as an emulator to run some of my non-GNU/Linux software. The software I want to run were pretty old, so they run at a reasonable speed even in emulator mode (1/20 native speed). I wrote WQGHLT along the way, which you can find here under GPLv2.
To run QEMU in virtualizer mode would require a piece of software called the KQEMU host driver, which was not available in open source form at the time. So I did not experiment. Another option for QEMU acceleration is through the kvm feature of a recent Linux kernel. But that requires a CPU that has hardware support for virtualization, which my AMD64 does not have.
KQEMU version 1.3.0pre11 was released under the GPLv2 on February 6, 2007. And it turns out that it is possible to have a QEMU/KQEMU combination running (and the guest running at 76% native speed according to the dhry2 benchmark) under Debian 4.0 x86_64. However, as everything Debian, the complete information for getting this setup working is scattered around the internet, and I have to do some digging and carbon-dating.
The good news is that both QEMU and KQEMU are available in Debian 4.0 Etch (QEMU 0.8.2/KQEMU 1.3.0pre9) and unstable (QEMU 0.9.0 and/KQEMU 1.3.0pre11). The bad news is that the packaged combination does not work; I saw the kernel panic in the guest OS when I tried. The compromise is to use the KQEMU from Debian unstable repository and the source release from QEMU website.
My recipe follows.
Preperations
I outlined how I changed my APT settings in the Getting Sun Java 6 On Debian 4.0 With APT Pinning post that I made 26 days ago. I did not change any of the settings this time.
Installing KQEMU
There are numerous web pages that describes how to install a kernel module using the module-assistant (aka m-a) command. I adapted the instructions in this page:
[root@gao-2006]# feta install qemu-common/unstable [root@gao-2006]# feta install qemu-source/unstable [root@gao-2006]# m-a prepare [root@gao-2006]# m-a build kqemu-source [root@gao-2006]# m-a install kqemu-source [root@gao-2006]# modprobe kqemu [root@gao-2006]# echo kqemu >> /etc/modules
Note that I used the feta command to do the work of apt-get, as Jonathan excellently suggested 164 days ago.
I did not include the output from the above commands. Let me just say that the outputs are long, informative, upbeat, and colorful. When everything is done, I have a kqemu-modules-2.6.18-5-amd64 package built and installed, with the kqemu kernel module installed at /lib/modules/2.6.18-5-amd64/misc/kqemu.ko. A /dev/kqemu entry is created with the following characteristics:
crw-rw-rw- 1 root root 10, 62 2007-11-28 09:11 /dev/kqemu
The output of the "lsmod | grep kqemu" command indicates that the KQEMU kernal module is indeed loaded, but is not currently being used by any programs.
Downloading and compiling QEMU
I downloaded QEMU 0.9.0 source from the QEMU download page. It has the standard ./configure, make, make install installation sequence. The only peculiarity is that QEMU requires GCC 3.x and SDL library to build. This is easily fixed by installing the gcc-3.4 and libsdl-console-dev packages and their dependencies.
The configure process informs me that kqemu support is enabled.
The build process produces the following set of executables:
[root@gao /opt/qemu-0.9.0/bin]# ls
qemu qemu-img qemu-ppc qemu-system-mipsel
qemu-arm qemu-m68k qemu-sparc qemu-system-ppc
qemu-armeb qemu-mips qemu-system-arm qemu-system-sparc
qemu-i386 qemu-mipsel qemu-system-mips qemu-system-x86_64
I also needed to install the texlive package and its dependencies to make the documentation.
Running QEMU in virtualizer mode
On the x86_64 platform, the kqemu module can only be activated by the qemu-system-x86_64 program. There are two command line arguments for qemu-system-x86_64 that control its behavior:
- (no argument): Only user code is executed directly; kernel code is dynamically translated
- -kernel-kqemu: Both user code and kernel code are executed directly (full vertualization mode)
- -no-kqemu: Both user code and kernel code are dynamically translated
When qemu-system-x86_64 runs, "lsmod | grep kqemu" shows that the kqemu kernel module is indeed being used:
[root@gao-2006]# lsmod | grep kqemu kqemu 170120 1
Benchmarks
I rerun the benchmark program inside a Debian 4.0 i386 guest OS. And the result is captured in this screenshot:
A comparison with my earlier results shows that the result of 219.0 dhrystone for QEMU in full virtualization mode is 18.4 times the 11.9 dhrystone for QEMU in emulator mode. Note that these benchmarks were run on the same physical hardware.
The benchmark result ran in the host OS is 288.6 dhrystone.
JavaFX Script: The Book, The Blog, And The Weekly Puzzler
Things are happening in the JavaFX Script community, especially the JavaFX Script compiler community. Since my presentation on JavaFX Script at the St. Louis JUG 135 days ago, I have been somewhat more involved with the JavaFX Script community. In this post I'll mention a few items that I've made a contribution.
The Book
The list of requisite books post I made 171 days ago was of course a joke. What I didn't expect was when Jim Weaver, an Apress author, contacted me, after my JUG presentation, to be the technical reviewer for a new book on JavaFX Script.
Of course I'm very glad to have this opportunity to make a contribution. The book was published by Apress in October 2007. I'm probably not an unbiased reviewer, but I can state that Jim's book is probably the most approachable treatment of the subject. It is based on the current version of JavaFX Script interpreter. And the knowledge about the JavaFX Script interpreter should transfer very nicely to the JavaFX Script compiler paradigm.
Go ahead and buy this book from Apress or Amazon.
The Blog
After finishing the book, Jim launched James Weaver’s JavaFX Blog.
This blog is geared towards disseminating JavaFX Script knowledge in bite-sized articles and communicating the up-to-the-minute happenings of JavaFX Script development community. Here's a sampling of the posts on the blog:
Putting My CTO Hat On: In this post I want to share with you some things about JavaFX Script, leading up to our company's (LAT, Inc.) perspective and plans for using JavaFX Script.
Achieving Closure in Compiled JavaFX Script: One of the very useful (and cool) features of compiled JavaFX Script will be closures. In a nutshell, JavaFX Script closures provide the ability to define a function within another function with the inner function having access to the local variables of the outer function.
Go ahead and subscribe to James Weaver’s JavaFX Blog.
The Weekly Puzzler
One fun feature of Jim's JavaFX Script blog is its weekly puzzlers. This feature is partially inspired by the Friday Java Quiz on this blog, but comes at more regular intervals and you can win a copy of the JavaFX Script book.
Here are some of the past puzzlers:
James Weaver: By the way, the next JavaFX Puzzler is going to require writing a compiled JavaFX Script program. This JavaFX Puzzler will be posted at 18:00 GMT (1:00 pm EST) on Wednesday, November 28, 2007. That should give you plenty of time to download and build the compiler, as well as to learn from past and future posts in the Compiled JavaFX Script category. ;-)
Go ahead and get your javafxc ready for the puzzler.
I Took Away The RSS Icon
Eric Burke: Why do people still offer both RSS and Atom links???
More choices do not improve usability — they diminish it.
Pick one and drop the other. Your blog does not need both. I chose to remove RSS, by the way.
I have removed the RSS icon from this blog. Let me know if you want it back.
Google Flavored Java?
(Via Miguel de Icaza)
Stefano Mazzocchi: Today Google released the Android code and I took a serious look at its internals... and found the solution for the licensing problem. It's called Dalvik and it's the new name of Sun's worst nightmares.Dalvik is a virtual machine, just like Java's or .NET's.. but it's Google's own and they're making it open source without having to ask permission to anyone (well, for now, in the future expect a shit-load of IP-related lawsuits on this, especially since Sun and Microsoft signed a cross-IP licensing agreement on exactly such virtual machines technologies years ago... but don't forget IBM who has been writing emulation code for mainframes since the beginning of time).
But Android's programs are written in Java, using Java-oriented IDEs (it also comes with an Eclipse plugin)... it just doesn't compile the java code into java bytecode but (ops, Sun didn't see this one coming) into Dalvik bytecode.
So, Android uses the syntax of the Java platform (the Java "language", if you wish, which is enough to make java programmers feel at home and IDEs to support the editing smoothly) and the java SE class library but not the Java bytecode or the Java virtual machine to execute it on the phone (and, note, Android's implementation of the Java SE class library is, indeed, Apache Harmony's!)
I haven't looked inside Android, but I trust Stefano's description. And I believe we are seeing fruits of The Third Fork From Sun that I outlines 215 days ago.
[Update]: Wow. This thing (the emulator) works!
And it advertises itself as "Mozilla/5.0 (Linux; U; Android 0.5; en-us) AppleWebKit/522+ (KHTML, like Gecko) Safari/419.3"
Escaping The Browser: Mozilla Prism Loves Your Web Application
One of my complaints about web applications is that they all run in the same instance of the browser process. And consequently, they are all at the mercy of the worst behaving tab. I have reported in the past of web pages that keep on using 100% of the CPU and making the browser unresponsive. I have a suspicion that Adobe Flash is to blame for a majority of these situations, but I don't have concrete evidence such as a URL that I can point you to that will trigger the bad behavior. My only recourse is to kill the browser process and loose all my work in progress (blog entries that I'm composing, the web forms that I'm filling out, etc.)
Then I saw the announcement of Mozilla Prism, downloaded it, installed it, and started using it.
It's really easy to use. Starting the prism executable gives me a dialog box like this:
Clicking on the OK button will create the Desktop Icon or Start Menu item or Quick Launch Bar item as requested. From that point on, I can start the web page by double clicking on the Desktop Icon, just like any other Desktop application. Prism will start the web page in a dedicated process separate from the running Firefox browser, if any, where all of my other tabs are:
Now I can edit my blog entries without fear that some other random links I click will make me lose my work.
Here's some interesting statistics:
- The Prism instance that hosts my blog page takes up 20MB of memory on my WinXP Pro SP2 machine.
- The User-Agent string is "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110108 prism/0.8"
From about a day's worth usage, I already miss several features that I had learned to depend on:
- No tabbed-browsing
- No password cache
- No /searching
I'll keep this experiment going for a little while. I'll let you know if and when I hit a show stopper that would force me to abandon Prism.
JavaScript To Fragment, The End Of The Reign Of The Browsers
This doesn't sound good:
Brendan Eich: ... the proposed ECMAScript 4th edition (ES4) grammar is a bit more than twice as big as ES3's
... Pratap Lakshman (Microsoft): "We do not support or agree to the current ES4 proposal, either in whole or in part."
... The July 2006 meeting notes include a statement from Pratap that ES4 would be implemented in the next major IE release after IE7.
... Of course this all changed, starting early in 2007, officially only in March.
... But the cold hard fact, documented in that September face-to-face meeting note, is that the dissenting minority in TG1 rejects ES4 in whole and in part.
... Is it still possible for everyone to win? I have to say I'm not as positive as I used to be.
It appears that Microsoft and Yahoo! has thrown a roadblock onto the path of evolution of JavaScript.
Brandan is trying to keep a straight face and not to discuss the ulterior motives behind Microsoft's sudden change of hearts on the new JavaScript proposal. But as a commenter in the quoted blog entry points out, Microsoft is not interested in the enhancements offered in the new language proposal.
Yahoo!'s rejection is not as dark as Microsofts. Douglas Crockford, whom I assume is still with Yahoo!, made this comment:
Douglas Crockford: The name is exactly the point. A new language should have a new name. The deltas from ES3 to the proposed language are larger than ES3 itself. Claims of backward compatibility do not change the fact that there is more than enough new material in the proposal to make it a new language.
The lambda-geek in me is sympathetic to this position. After all, who wouldn't like the beauty of a clever little language off the beaten path and still useful in the real world.
However, as shown by GWT, JavaScript has become an assembler of the web. And it needs to grow up. Or it risk being overtaken by other languages.
My crystal ball is showing a fragmentation of the JavaScript language—ES4 in Mozilla and ES3.1 in IE8. And the cross-browser application development will happen in the intersection of the two, which is pretty much like the currently available JavaScript in Mozilla and IE7. The extra features simply won't be used.
Mean while, there's life outside the browser:
David Herron: ... Where I've gotten to is an idea that the Internet has been trapped in this prison-like shell we call a 'Web Browser'.
...I do see that the major Internet platform providers ... Mozilla, Microsoft, Adobe and Sun ... that we all seem to see this. That Rich Internet Applications do not need to be trapped within the web jail.
We are all working on application platforms which offer a way to build rich internet applications which run outside the web browser.
Folks, the browser platform is passé. The race for the next round of cross-platform (note: not cross-browser) internet applications (note: not web applications) has already started. And my prediction is that JavaFX Script will win.
The Wall Of Erasure
Eric Burke has fallen into a pattern while trying to use Java generics:
Eric Burke:
... I foolishly tried this:
... Oops. Won’t compile.
... Foiled by erasure!
Brian Gilstrap, who's also experimenting with generics, has coined a name for this phenomenon—The Wall Of Erasure.
In plain English: Every really cool idea involving Java generics will invariably lead to insurmountable difficulties the root cause of which is erasure.
Getting Sun Java 6 On Debian 4.0 With APT Pinning
All the noise about Leopard and Java6 last week made me thinking: Does my favorite operating systems include the JDK? And if so, which version?
The answer, of course, is that Windows does come with a JRE, but it's at version 1.1; and that Debian comes with a incomplete open source JRE that's roughly at version 1.4.
Debian 4.0, however, makes getting the higher versions of Java easy. Sun Java 5 is available in Debian 4.0's stable software repository, while Sun Java 6 is available in the Debian unstable software repository. Since neither are free software, they can only be found in the non-free section of the repositories.
Enabling the non-free section of the stable repository in very easy, as I documented here 136 days ago.
Enabling the unstable repository in Debian 4.0 is something that I don't want to do lightly, for I don't want to upgrade every package in my system to the bleeding edge, at least not yet. Jonathan mentioned "APT pinning" when I asked him about this at the time. And learning about APT pinning I did yesterday.
The three degrees of APT pinning
I have gone through three documents that I found on the Google about APT Pinning.
First there's the very clear Apt-Pinning for Beginners. It outlines exactly what to do to enable the testing and unstable repositories in Debian in such a way as to favor the stable repositories's contents.
But I have some unanswered questions, so I went to the Debian Wiki's AptPinning page. It provided a few more recipe's of doing APT pinning. I particularly like the "only if I say so" approach.
But I still have some unanswered questions, so I went to the authoritative source—the man page of apt_preferences(5). This man page is on my hard drive all along. And to read a printed out copy I issued the command
[weiqi@gao]$ man -Tps apt_preferences | lpr
This six-page document contains explanations of every detail of the things that I need to do.
The steps
Here's the steps I took to get Sun JDK 6 to my Debian GNU/Linux 4.0 system (the right way):
- Add a line to /etc/apt/sources.list:
# deb cdrom:[Debian GNU/Linux 4.0 r0 _Etch_ - Official amd64 DVD Binary-1 200704 07-12:15]/ etch contrib main deb cdrom:[Debian GNU/Linux 4.0 r0 _Etch_ - Official amd64 DVD Binary-1 20070407 -12:15]/ etch contrib main deb http://ftp.debian.org/debian/ etch main non-free deb-src http://ftp.debian.org/debian/ etch main non-free deb http://security.debian.org/ etch/updates main contrib non-free deb-src http://security.debian.org/ etch/updates main contrib non-free deb http://www.debian-multimedia.org etch main deb http://www.dipconsultants.com/debian etch main ### unstable ####### deb http://ftp.debian.org/debian/ unstable main non-free - Add a line to /etc/apt/apt.conf.d/70debconf:
// Pre-configure all packages with debconf before they are installed. // If you don't like it, comment it out. DPkg::Pre-Install-Pkgs {"/usr/sbin/dpkg-preconfigure --apt || true";}; APT::Cache-Limit "100000000"; - Created /etc/apt/preferences:
Package: * Pin: release a=stable Pin-Priority: 700 Package: * Pin: release a=unstable Pin-Priority: 600 - Run apt-get update
- Install the eight sun-java6-* packages
- sun-java6-bin
- sun-java6-demo
- sun-java6-doc
- sun-java6-fonts
- sun-java6-javadb
- sun-java6-jdk
- sun-java6-jre
- sun-java6-source
[root@gao]# feta install <package-name>s
Notice that the sun-java6-doc package requires that I download the JDK documentation from Sun's Java download site and put the zip file in /tmp.
BSOF Comes To The Mac
Oops!!!
Look, it's a Tiger; no, it's a Leopard; no, it's a paperweight, NO.....
I repeated the cycle many times just to be sure that I was really trapped in a loop. I was even able to verify that I was entering the password correctly because when I intentionally got it wrong, the dialog box did this cute little shake (I could almost hear it saying tsk, tsk..) and didn't cycle through the BSOF (that's "Frustration" rather than "Death") -10 for Apple.