On 8/23/04

In August, 2004, I opened a GMail account after begging a lucky friend for an invite. I received an email titled: Gmail is different. Here's what you need to know.

This included the much discussed whopping 1GB of free storage that of course no one would ever sanely fill, no matter how insanely Google gave out free space. Then suddenly it was 2GB, and then one day Google added a crazy man counter to the GMail login page counting up the amount of available space.

Today, I noticed the following message at the bottom of my GMail account:
You are currently using 1094 MB (15%) of your 7142 MB.

I finally did the impossible!

(Now for breakfast at Milliways.)

In search of a good mailer

Dear Lazyweb,

in the 10 or so hours i have available for Fedora and Red Hat business a week, it seems i spend about five of them wrestling with Zimbra to go through mailing list traffic. I've noticed a bunch of personal emails have gotten lost in the stream. It's obvious i need a better tool to work with. I'm sure many of you have your own personal favorite email reader, which you would just love to rave about. I'm open for something new, provided it can do the following.

I need something that can filter and process email *fast*. Whether it has some magic code that enables it to do IMAP at lightening speed, or maintains a local cache and pushes updates to IMAP in the background, i don't care, so long as it is fast.

I need the ability to label emails with more than one label at a time. This is important for two reasons. One, i label things with Todo and Priority flags based on filters. Two, conversations can cross mailing lists, i want a single thread to have two labels.

Finally, i need the ability to view a discussion by thread, and not just as a series of single emails. Zimbra is really bad at this, and evolution is only marginally better. Unfortunately, either working with the Zimbra web client or the Zimbra connector for Evolution are both recipes for disaster.

As extra credit, any scriptability in Python is definitely worth some serious extra credit.

Any recommendations?

Is it a Browser? Is it an Operating System?

Lately, there's been alot of commotion over Google's latest blitz in the Browser Wars. In the past week, I've seen a million and one opinions ranging from 'oh, another browser, *yawn*', all the way to 'OMGZ, it's the Google OS arisen!'. It's all rather silly.

Let's look at what Google has done. Probably the most original thing in Chrome is that there are tabs where the title bar used to be. The person who can script them out and make them accessible through libwnck or some similar desktop environment based API will certainly get alot of kudos from me. Really, the concept does not belong to Google, but I believe the credit should go to Opera for first integrating the browser widgets with the tab. Another revolutionary concept is binding processes to either tabs or sites, or other process splitting criteria. Again, the credit goes elsewhere, to Microsoft, but thoroughness that Chrome uses is pretty remarkable. In fact many of the 'unique features' in Chrome have already been implemented elsewhere, in some fashion.

Well, what is it that catches the eye? Is it the super optimized Javascript runtime, that supposedly is only really an evolutionary step? Is it that they used Webkit, the poster child for non Linux Open Source cool stuff? I think I found what makes it so special. Google was smart and realized that profiling websites to improve performance is a badly needed developer feature. So they stuck the label 'process manager' on it, and snuck it in like some trojan horse, underneath all that glittery and shininess. Most of the 'Google OS' arguements i've heard are fixated on this one feature as either the mark of the beast of the signs of messianic times.

It's not really just the process manager that spells something different for Chrome. When you go through the list, there are *alot* of features. Each one is done 'differently'. Most importantly though, is how well they come together to form a single paradigm. The paradigm is simple. The user loads a website up, which runs in a bottle. That bottle can be moved around on the desktop in some basic ways, from window to window, or in a standalone window, manageable by the Desktop Environmen's own window manager. I'm presuming that in the future, Google intends to expose a few javascript APIs that will let the website customize the look of its bottle and provide clues to the Desktop Environment. Namely, the website can not use a toolbar, or use a custom toolbar. Perhaps the website can even come with a code layer that is like Mozilla's own chrome, used to do many tricks in Firefox. Or maybe, the website will expose information about what kind of window is being displayed, whether it's a long term window or a transient dialog box. It might even expose context information to Nepomuk about its purpose and its semantic connection to the rest of the world, along with some state token to reload it back to its previous state.

Actually, these are things that Adobe Air and Mozilla Prism aim to do as well. I saw an excellent talk at FOSDEM last February on Mozilla Prism, and it was clear to me that this is the direction the modern browser is going to take. Since Google's Chrome still just works on Plain Ol' HTML and Javascript, i'm hoping that Google is willing to collaborate with Mozilla and Adobe in using the same APIs for each of their respective products.

Chrome isn't an OS though. If it was, where is the Desktop Environment? Where is the kernel to run it all? Where is the hardware support? Where are the millions of man hours that go into releasing a top notch operating system? Too busy writing browsers apparently. Chrome is no more an OS than .Net or Python are OSes either. Chrome is a virtual machine / application container. Way back when, in 1995, there was a question on how to run code both on a client machine and a more powerful server. Way back in 1985 the same question existed. There are rather large sections of Tannenbaum's Principles of a Modern Operating system that go into RPC functions and function stubs. For those of you with long memories, you should all remember how Java was supposed to revolutionize the web, by making it more 'desktop application-like'. As a developer of web applications, i always struggle with the concept of how my code runs like a weird application in the server space, but just a bunch of documents in the client space. I really would like to see more tools that unify the design a bit more, and many of those kinds of tools are coming of age.

Google has been at the forefront of these design paradigms, with Google Gears as their showpiece. Having little personal experience with Google Gears itself, i can't really comment on how it works with Chrome. Just realizing though, how cleverly Google has wrapped an essentially document oriented display framework with a sophisticated programming language on top into a virtual machine system that can interact with the user's desktop in one smooth paradigm, and I can't call it anything but a Virtual Machine.

Random Musing

My brother is asking me about a portable way to take programs and music with him, and just ride piggy back on anyone's computer around. I figured the obvious answer is a persistent Fedora LiveUSB on a really large USB stick. But then I realized, he would be limited to only using i386 computers. The random musing for the day, what would it take to build packages and distros that are akin to "Universal Binaries" found in Mac OS X.

I realize the OS will definitely be bigger, without a doubt. There are also a few concerns, such as using different bootloaders for the various architectures, and then autodetecting the right kernel, and such. Is there a demand for such a thing?

My brother also mentioned he would like to be able to start up the OS image once in Wintendo, or some other OS, in cases where he can't restart the computer, or the computer can't boot up from USB. What would it take to include some virtualization platform in the livecd-to-disc tool that could work in Wintendo so all the user needs to do is run some program and get a popup window with their ever so useful persistent Fedora LiveUSB?

Avidemux is awesome.

The topic says it all. I took a random video of some new lighting toys I got for my room to show some friends, and the camera spit out a 300mb AVI that I knew would choke several people's intarweb trucks. A bit of googling, and I got the name avidemux which was fortunately in that repository which shall not be named. One yum query later, and I even see there's both a gtk and qt version.

I install the GTK version, poke my nose around a bit, tinker with a few features, and 10 minutes later, I've spit out a 40mb mkv encoded in h264 and mp3. The quality is great, and I needed to know only a few basics about video encoding. I'll have to pose the granny test on my family later, but for a power user, the program is excellent.

Avidemux

Xmonad 0.8 Released

Yup, that's right, after a long wait, the latest xmonad has been released. If you're looking for packages, skip to the bottom.

There probably is no real reason why it took so long to be released. Up until 0.7, xmonad was facing roughly a 1-2 month release cycle with alot of rapid and rabid development in between. The fundamental changes to xmonad 0.8 since 0.7 are minor, and fall chiefly in the refinement category. It seems that development to xmonad has become relatively stable. One of the reasons to push the release was that there was so little development on the core parts to begin with. So the decision was made, and the release went by really smoothly.

This does not mean that xmonad is starting to die out. There are two things that make xmonad radically different than many other window managers. First of all, xmonad is based on some fundamental mathematical principles and data structures common to the functional programming world. The original goal to produce a functional window manager (no pun intended, although feel free to interpret one in ;) ) has essentially taken a year to develop from start to finish. It also uses some highly testable development methods including unit tests exposed to QuickCheck, the haskell unit tester, that greatly increase stability. Stable, if slow, development of xmonad implies that after a year of public usage, all the boiler plate code around the window manager has been refined and tested by a large number of users into some elegant minimal code, and by minimal, i mean 1045 significant lines of code style minimal.

The second important component is the contrib library, which is really quite essential to development. It is another ~9000 SLOC with a number of components to make using xmonad far easier and more flexible. In the true functional style, they are just a bunch of user submitted functions that different users have found useful for others too. For example, it includes fancy advanced layouts, layout combinators, alternate syntaxes for window management and key commands, random tools for outputting important information to dzen, or other tools, and for interacting with other parts of the system. Not a single line of code is actually run unless the user uses it.

The config file itself is actually just a haskell program cleverly disguised as a config file. In this latest release, there is an add-on in contrib that will even convert other config file formats into a haskell file, compile it, and run it, all in the background. The only components that are included in the run time are the ones being used. Of course, as a user, you never need to work with compiling your own xmonad window manager; part of that 1000 lines of code is the boilerplate to automatically look for your ~/.xmonad/xmonad.hs, compile it, and load it up, without much trouble. You can even make changes, reload your WM, and that same boilerplate will just pass your session on to the newest version.

I've built some packages, which are available at my personal repo at:

http://ynemoy.fedorapeople.org/repo

If you are already using my packages and repo, you should automatically get updates through yum. These packages are currently for Fedora 9, i386 only, but if anyone submits some builds for other archs/platforms, i'll be glad to stick them in the repo.

On a side note, I'm having some trouble signing my packages. Anyone know how to make sure rpmsign is using the right gpg key to sign packages?

Finally done with Haskell things

After nearly 9 months, I am finally at the point I wanted to be regarding Haskell. Last January i wanted to submit packages for my favourite window manager to Fedora. I got blocked because of a lack of packaging guidelines and familiarity with Haskell or the Glasgow Haskell Compiler.

I'll admit the process went alot slower than I would have liked, but it was an incredible learning process. In working on the guidelines, I learnt alot about how to get involved in Fedora, how to work with the myriad of communities and committees and boards and groups involved. I got to meet all sorts of people in the Fedora world online and offline. I probably annoyed some people being a crazy upstart kid with all sorts of crazy ideas, but it seems to have turned out alright in the end. I also learnt many random technical facts about how GHC puts together code, and RPM in a display of shocking intimacy that would probably make even my most 'sexually progressive' friends blush. (And believe me, they make everyone else blush.) For someone who 'just wanted to learn how to make RPMs', it was a bit of an intense introduction.

If you're curious, I have several bugs that track the progress of things. I still have a bit of a confusing mess to sort out about handling libraries, but I think I'm a bit tired from all the heat. Anyone familiar with summers in Northern Europe can well understand the problems I'm having in 32 degree weather (Centigrade). (That's 90 degrees Fahrenheit.)

Without further ado:
Xmonad: https://bugzilla.redhat.com/show_bug.cgi?id=426753
Xmonad-contrib: https://bugzilla.redhat.com/show_bug.cgi?id=426754
ghc-x11: https://bugzilla.redhat.com/show_bug.cgi?id=426751
xmobar: https://bugzilla.redhat.com/show_bug.cgi?id=460974
macros for ghc and rpm: https://bugzilla.redhat.com/show_bug.cgi?id=460304