Making Arc 3 play nicely with SELinux on Fedora 10

Arc 3 needs MzScheme 372 to run. Building it from the source i.e. plt-372-src-unix.tgz is desirable, especially when we want to install it on a few {32,64}-bit boxes. The fun begins with the standard flow:

./configure && make && make

Apparently, the MzScheme JIT mechanism, places the JIT’ed code on the heap and tries to execute from that. In “enforcing” mode, SELinux correctly scoffs about the idea. During the build, setroubleshoot browser says, “SELinux is preventing lt-mzschemecgc from changing the access protection of memory on the heap.” The message count quickly grows in thousands. Downgrading to Arc 2 is not an option, since MzScheme 352 seems to suffer from the same issue.

The way to silence the message is to set the allow_exec_heap boolean to 1. However, doing that enables the specific permission for all processes and users. Clearly, the attack surface increases.

Compiling with various combinations of –enable-llvm, enabling / disabling Bohem GC or Senora GC doesn’t help (–disable-cgcdefault, –disable-sgc etc.)

One might argue that QEMU could be used with acceleration turned on. But, it isn’t very useful if “grep vmx /proc/cpuinfo” produces nothing on our box. So, we have to make a tradeoff.

With $HOME/scheme/bin in PATH and $HOME/scheme/lib in LD_LIBRARY_PATH, here is what worked on my box:

$ cat ~/scheme/bin/arc
#!/bin/sh
cd ~/arc3
sudo /usr/local/sbin/enable-mzscheme
mzscheme -m -f as.scm
sudo /usr/local/sbin/disable-mzscheme
$ chmod +x ~/bin/arc

The {enable,disable}-mzscheme scripts are just one-liners, created by the root user:

# cat /usr/local/sbin/enable-mzscheme
#!/bin/sh
setsebool allow_execheap=1
# cat /usr/local/sbin/disable-mzscheme
#!/bin/sh
setsebool allow_execheap=0
# chmod +x /usr/local/sbin/{en,dis}able-mzscheme

The /etc/sudoers needs following entries, added using visudo as root, substituting your hostname(s) for “swan”, “eagle” and username for “joe” below:

Host_Alias BOXES = swan, eagle
User_Alias MZSCHEMERS = joe
Cmnd_Alias MZSCHEME = /usr/local/sbin/enable-mzscheme, /usr/local/sbin/disable-mzscheme
MZSCHEMERS BOXES = NOPASSWD: MZSCHEME

We can test whether the scripts and the sudo access are working, with getsebool:

$ sudo /usr/local/sbin/enable-mzscheme
$ getsebool allow_execheap
allow_execheap --> on
$ sudo /usr/local/sbin/disable-mzscheme
$ getsebool allow_execheap
allow_execheap --> off

With this, we are now ready to build and install plt-scheme:

$ tar zxf ~/Download/plt-372-src-unix.tgz
$ cd plt-372/src
$ ./configure --prefix=$HOME/scheme --enable-shared && make && make install

Installing Arc 3 is a breeze:

$ tar xf ~/Download/arc3.tar && cd arc3
$ time { echo '(+ 1 2 3) (quit)'|arc; }
arc> 6
arc>
real 0m1.594s
user 0m1.257s
sys 0m0.157s
$

Next, run arc again and do “(asv)” followed by “elinks http://localhost:8080″ to verify that the web server is working correctly. It should display the page that says, “It is alive.”

That’s all about it.

Book review: Hackers and Painters

Paul Graham’s book explores the similarities between the software and painting disciplines. This is a must-read for every talented programmer and budding technology entrepreneur. He cares about the craftsmanship of software a lot. The fact that his thoughts are distilled from his unique experience comes across in a jovial manner in the book.

Mr. Graham has impressive credentials. He is an entrepreneur turned into venture capitalist. Foremost, he is a hacker and understands the value of programming language in terms of gains in productivity. He finely blends his twin background in software and painting: a Ph.D. in Computer Science from Harvard with study of painting at Rhode Island School of Design and the Accademia di Belle Arti in Florence. The result is a compelling argument about exploratory programming culminated in the book. It leads the reader to Lisp in a rather gentle and rational way.

O’Reilly published the book on May 18th, 2004. I read the online copy available to the ACM members from Safari Books Online.

I must confess that I disagree with some of his arguments, primarily about Lisp and the exploratory nature of art. Type system is still an open question in language design. I find that the compiler can be a great friend to a programmer. A language should offer a fine balance of both: static and dynamic typing. Metaphorically, I want to be able to start a sculpture in clay, but it should be possible to convert portions of it in marble, the moment those portions have attained perfect beauty, while the rest is still in clay. Of course, the back transformation from marble to clay, should be equally possible.

The next is about his emphasis on web-based applications. It is hard to argue against. While web-centric computing is the preferred approach in current times, there is a place, though niche for desktop applications. Ultimately, developer’s tools are desktop applications, be it the browser itself, or the Eclipse environment, even Emacs! Sure, that is an example of niche and it seems to be shrinking all the time, but it does exist and is important.

Last is about great artists, who do not approach art in an exploaratory manner as book seems to suggest. An example will be appropriate here. Pt. Hrudaynath Mangeshkar is a celebrated composer in Maharashtra. Famous for his difficult musical compositions, he was once asked as to how he creates melody from a poem. The questioner, himself was a musician. He wanted to know which musical instrument the composer used for exploring the notes. Mr. Mangeshkar replied that he always composes the entire tune in his mind, from start to finish and only then would touch the harmonium as a means to explain it to the singers. His tunes, based on Hindusthani classical music, are simple, yet so difficult that the current generation of singers and musicians in Maharashtra takes pride in just attempting them.

With those grains of salt, I heartily recommend the book. It is well worth your time. Even the reviews published about it elsewhere are useful. You will often find gems hidden in them, flashing momentarily, where you least expect and that is a real boon.

Painless Fedora 10 installation with Windows XP SP3

I would like to share an interesting fact while installing Fedora 10 in the ardent hope that it would save someone 2-3 days and eliminate frustrations.

First, let’s see the machine that was to be setup. We are talking about a HCL Laptop with the following specifications:
1. ATI Radeon graphics card, 2GB system RAM, Intel T2080, 120GB HDD.
2. Windows XP SP1 OEM copy with SP3 applied, installed on /dev/sda1.
It was activated over internet using the “Activate Windows” menu in Start > All Programs > Accessories > System Tools.
3. Fedora 10 on rest of the partition with the default layout. The plan was to use ext4.
4. It goes without saying that MS-Windows should be installed and activated first, followed by Fedora 10. Grub was installed on MBR.

As soon as I installed Fedora 10, two problems were faced:
1. The system would freeze randomly after just 10-15 minutes of operation.
2. When trying to boot in MS-Windows, the Windows bootloader would flash blue screen and quickly reboot automatically.

The solutions are as follows:
1. For Fedora 10 random lockup problem, upgrade to the latest successful builds for RPMs kernel and ATI X-Windows drivers, available on kojipkgs,
rpm -Uvh http://kojipkgs.fedoraproject.org/packages/kernel/2.6.27.10/169.fc10/i686/kernel-2.6.27.10-169.fc10.i686.rpm
rpm -Uvh http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-ati/6.9.0/63.fc10/i386/xorg-x11-drv-ati-6.9.0-63.fc10.i386.rpm
2. For MS-Windows, the solution was simpler than I had imagined. While booting, press F2 when the HCL logo is displayed to land into BIOS Setup and choose “Load Setup Defaults” i.e. press F9.

Overall, the experience involved reformatting the hard disk half a dozen times, a significant number of Google searches, trial and error and sleepless nights. In the end, the solutions proved to be really simple,

Fedora 10 rocks! It was worth all the efforts.

Research problems in “The Art of Computer Programming”

The following is the list of research problems that appear in Donald E. Knuth’s seminal work, “The Art of Computer Programming.” I mention only the section and the problem numbers, since every serious software professional has a copy, easily accessible, over the bookshelf.

The format for each entry is “section (problem1:page#, problem2:page#,…)” The page numbers in Volume 1-3 correspond to Indian reprints of 1997-98 edition, copyrighted by Pearson Education, Inc. Volume 1 is 3e/8th, 2002; volume 2 is 3e/3rd, 2000 and volume 3 is 2e/4th, 2001. As you already know, Volume 4 is still under preparation. Some of its pre-fascicles can be downloaded from Dr. Knuth’s web site[1].

Volume 1: 1.2.1 (14:20), 2.5 (40:456).
Volume 2: Notes on the exercises (4:xi), 3.5 (17:50), 4.5.4 (16:413, 33:415, 47:417), 4.6.3 (42:485), 4.6.4 (12:516).
Volume 3: 5.3.2 (36:197), 5.3.4 (44:241).
Volume 4: Pre-fascicle 0a: 7 (15:37). Pre-fascicle 0b: None. Pre-fascicle 0c: None. Pre-fascicle 1a: None.

If someone knows correct solutions to either of these problems, then he should consider submitting it to a scientific journal for publication and inform Dr. Knuth.

Someday, I hope to read an entire book that describes such research problems, with only a paragraph or two devoted to each one. The marvel of such a book would be a treat unto itself.

Notes:
[1] http://www-cs-faculty.stanford.edu/~knuth/taocp.html