
Hi, Note first as a caveat that I've had three hours' sleep in the last 36. That said, I'm not the only person who thinks this is a good, and practical, idea. Requiring GHC as a dependency is a real drag on evangelizing xmonad, and for adoption. The payout, of course, is having the full power of Haskell in our configurations. But GHC is a very, very heavy dependency for someone who doesn't already have it, and it raises the bar to running xmonad. This led to the creation of PlainConfig, but while that removes the cost of GHC, it also sacrifices the benefit of powerful configuration. The new idea would allow users to keep all the benefits of Haskell config files without the cost of having GHC themselves. We would present a web interface where a user can paste in their xmonad.hs (or maybe Browse... upload?), probably select release vs. darcs version, and then submit the form. The get back a download link to a compiled, standalone xmonad-i386-linux, the complete executable. There are a couple of hurdles for this approach to work. 1. We need a donated machine with sufficient computing power and bandwidth. 2. xmonad-i386-linux files tend to be around 3.5-4MB. If this began to see a decent bit of use, that could take a bite out of the upload bandwidth for the donated machine. 3. The mod+q semantics: what does it do when there's no ~/.xmonad/xmonad.hs, but there is a ~/.xmonad/xmonad-i386-linux? Hopefully that keybinding should be harmless for someone without an xmonad.hs, and it would just treat mod+q as a no-op. On the user end, they would require libX11 and various other libraries, but not X11-1.4.2, mtl, the RTS, nor any other Haskell bits. Anyone with a X11 system (and an x86 architecture) should be able to run these binaries. Some form of captcha would be necessary to prevent spamming the form and crippling the box. Since it's only compiling and not executing the config files, it shouldn't require any lambdabot-like sandboxing. I'm willing to set up this system, and my family has a server machine that could be used as a testbed, but it isn't beefy or reliable enough to be used long-term. Braden Shepherdson shepheb