I just started using e again yesterday after installing Sabayon. With the most recent version, it has become the most productive desktop environment I’ve every used with features like:

• automatic cursor center on new windows
• focusing of windows under cursor, allowing typing and clicking without raising
• coupled with transparency on unfocused windows

I also updated my performance tweaks for Sabayon, so it’s the best browsing experience, too, with right click link mapped to open foreground tab. So I got to experience e17 as it was released today after about 7 years of development.

This was about one and half years ago on another machine that I no longer use, but the insight just came to me. Many things just lined up and fell into place instantly. I had Sabayon installed on my Inspiron 1520 quad-booting with XP, 7, and Elive. Running the system update before installing LLVM Clang for comping Python to JavaScript, the system got broken. I ran a system update to upgrade all packages because I had been using 7.  Unfortunately, the it broke the package manager!

This should never happen, and I wasn’t able to find any threads on Google. So I gave up on Sabayon and got a desktop to run Xubuntu in a VM. I thought the package manager was too dumb, stuck doing an upgrade of itself.

As all Linux users know, once the package manager is broken, the system is bonked. Installing, upgrading, or removing any software must go through the package manager. The upgrade finished half-way, I was left with a console without X or a graphical window manager. Fortunately, I had many other OS’s to use on the machine. They’re still there today, and today I just read the Sabayon wiki on mixing portage and entropy.

…when mixing Portage and Entropy, never use Portage to update Portage. Sabayon uses a version of Portage that is hard masked in Portage. This means that you will actually be DOWNGRADING, not upgrading portage …

So the summer before this one, I simply downgraded the package manager, which caused it to stop working.

In modern browsers, g-zip compression is a standard feature. The typical compression ratio for a plain text file is 30%, reducing the download time of web content by 70% and making it load 2-3 times faster. In spite of the speed up, g-zip is an old algorithm based on LZ77. Since then, newer algorithms have been invented, with LZMA being the standard. On Linux, LZMA typically produces files half the size compared to g-zip. This tutorial will show you how to use an LZMA compressed file produced by the standard lzma command on Unix machines directly in a client side web application. The rest of the post assumes you have the JavaScript libraries for LZMA and binary AJAX set up.

First, Make a Compressed File

Next,  Read Binary Data

This is a pretty simple step, except the while loop counter may be unintuitive. getUint8 increments the file pointer, though it wasn’t documented in the API specification. I spent an hour or so comparing the output in hex. One of the problem was that

is the same as

in little Endian. You can try it in the decompressor, just replace the bytes in the hello world lzma on compression level 3. However, I figured out the problem as soon as I compared view.length and int_arr.length. They were multiples of 2! That always has significance in computing, in this case it meant I was reading every other byte. After correcting the while loop, I moved onto decoding the binary.

Third, Enjoy the Decoding

Yes, this is a rather boring thing to do while waiting, but do enjoy it.

Benefits

Using LZMA compression rather than g-zip, I was able to reduce a g-zipped file to 2/3 of its size, reducing the download time by 33%. The LZMA decompression algorithm could be improved to use an array to store results, joining them at the end, rather than appending to a string. It is not recommended to use this method unless you have large files. The libraries themselves take up about 50kb with g-zip. Furthermore, it is unsuitable for downloads where files are sent directly to the user, without being used by the application, since the user would have the decompression utilities.

Time to update Sabayon, after installing the wireless driver with a wired connection, about a week ago. Following the routine, entering several commands, letting them finish in a couple of hours. It’s been about 8 months since I last updated. Mostly because of the lack of a wired connection. I expected everything to go as expected, except it got stuck at

which means the package manager is broken. As the console suggested, “you’re in deep shit”. Normally, on any Linux system, if the package manager is done, the system cannot be repaired. If it happens in the middle of an upgrade, then those half upgraded libraries breaks the system. By circular cause and effect, a broken package manager is stuck in a loop.
However, Sabayon is redundant (hint). Entropy does the same thing as Portage. My plan at this point was to run

and continue with the upgrade…

Reiser3 was the first Linux filesystem with journaling and received mass adoption in the period of 2001-2006. Reiser4 is designed with lessons learned from the mistakes in Reiser3. It is still the fastest Linux filesystem.  That is without filesystem compression. Reiser4 has been around since 2001, but it has never been accepted into the Linux kernel. It is a testament to the failure of a free society to recognize greatness. The Linux kernel maintainers are still human.

Before Namesys

Reiser was about 12 years old in high school when he was accepted into Berkeley. He studied on and off, working at companies like IBM, before earning a degree at middle age. The development of Reiser3 and Reiser4 can be traced to his senior thesis, in which he studied the difference between computer science and empirical sciences. As a result, Reiser3 and Reiser4 were exceptionally fast filesystems, because ideas conventionally regarded in computer science as junk were given a second chance.

To start Namesys, Reiser went to Russia in 1993 and hired a team of programmers. Russia had just come out of a huge failure. To summarize the period:

The Russians are just taking into their hands the ashes of incompetent industry, collectivized farming, Stalinist paranoia, military machoism, the Gulags, Leninist madness…

They turned out to be the best programmers that money could buy, full of bright ideas.

Reiser3 (ReiserFS)

When I used Windows 95/98, I remember those colorful screens and the long wait. It turned out the OS was checking the filesystem, because it didn’t shut down properly. So is there a way to make it start faster and not loose any data? Reiser3 was the first Linux filesystem to implement journaling, one method to solve both problems. With Reiser3, data centers did not have to worry about loosing power, even just for 1 second.

Major Linux distributions all offer Reiser3. SourceForge was hosted using  it, and Novell made it their default filesystem. Since then, there has been a decline due to kernel locks used extensively, resulting in non-concurrent operation on multi core systems. However, there are patches, because Reiser3 users still haven’t switched.

Reiser3 development was funded by DARPA and Linspire. Another source of funding when it was included with the kernel was database implementations.

Reiser4

Reiser4 is a non-continuous increment of Reiser3. A Reiser3 filesystem cannot be converted to a Reiser4 one. This decision in itself reflects how continuous innovations are adopted quicker. For example, C/C++ are almost synonymous compared to C# and Objective-C. Switching to Reiser4 means compiling a kernel with it, formatting another partition large enough, and copying all the data.

However, the benefits of being non-continuous outweighs the costs. Reiser4 is designed to support an on-disk database, within the filesystem. This is implemented by using two separate layers, graphs for relationships, and trees for efficient searching. Reiser4 also implements extents, mapping a section of a disk to a file, which makes fragmentation non-existent.

Another feature is the plugin system, where a userland SQL interface can be placed. Kernel developers argued for moving it to VFS, while Reiser insists on keeping it as part of the filesystem. There are many other reasons why Reiser4 was not accepted into the kernel. The plugin system allows compression and encryption of the entire on-disk structure. LZO compression increases filesystem performance by two times, placing Reiser4 head and shoulders above the rest.

Whereas Reiser3 became the standard journaling filesystem,  Reiser4 had no special feature associated with it. Being the best filesystem at the time, Reiser4 was never included in the kernel. Compared with ext3, which still used an H-tree and had a double write penalty for journals, Reiser4 was better technology-wise. If Reiser3 was adopted for data-loss protection, then Reiser4 needed a similar reason. An interesting application for the graph layer is a Baynesian network. It would have high scalability and performance due to its on-disk structure, and could be sold as an out-of-box solution, like Google Search for Enterprise. Such a product would have applications in real-time business analytics, data warehousing, and as a component of a CRM system.

The End

Now as Reiser4 has been forgotten for 4 years, you may wonder how the story ended. Sadly, the story ends with a telltale heart, which I saw as a play and now in real life. Reiser must have liked Lord of the Rings a lot, since he used metaphors in his talks. It’s usually popular with Dungeons and Dragons players, or Linux fans. The terminal is another way of seeing the world.

I often get an unbootable Linux system and not remember which file I edited or whatever else I did. In this situation, I hit Alt-F2 to switch to the second console (the first one is used to output boot information). Then here’s what I do at the terminal

Unfortunately, that’s not what happened this time. Xorg had problems starting, and I couldn’t issue keyboard commands. Next, I booted into Windows to finish up my tasks. See, I made a shared NTFS partition that is mounted by every OS I boot. In Linux, I create a symlink in the home folder called Documents, somewhat like 7’s Documents library folder. Now on the weekend, I finally get a chance to see what’s up with the Debian system. A piece of wisdom (wit won’t really help) applies here,

Insanity: doing the same thing over and over again and expecting different results.
– Albert Einstein

I simply used the reparation kernel boot parameters and switched to a terminal using Alt+F2. Now I’m in the driver’s seat again.

I immediately ran that command, as I remembered a message about it last time I used apt-get. Apparently, Entrance, e17’s login manager, couldn’t start without some configuration files removed by apt-get purge. The autoremove command does dependency checking for programs that are not used in the tree anymore. It also uninstalls them, so they are no longer loaded via symlink by the login manager.

That was it. Problems in Linux are often as quick and easy to fix as it was created.

Recent comparisons of browsers focus on JavaScript speed. There are many ways to measure browser performance, including image load time, reloading from cache, start time, and css rendering speed. While Opera was in the lead a few years ago, it has been branded as the fastest browser again.

You should notice the ad on the left for Chrome. So which one is the fastest? I ran the tests on Linux and Windows.

Benchmark Method

There’s nothing special about using JavaScript to detect when onload is fired by the browser, as long as the browser follows the convention that it is fired after the page is loaded. This used to be an issue I noted to the point of just using Firefox and ignoring other browsers. According to this article, it was fixed 2 years ago. So I took the benchmark from the site and ran it. Not surprisingly, Firefox came out highest on the score. Actually, that’s a negative score. Ideally, the page takes no time to load.

Linux

Google Chrome for Linux is different from the one for Windows, as the benchmark would load the first site for the first time, but could not time it nor reload it. Opera got stuck on MySpace once and kept adding more elements to the page, possibly due to an ad that is not usually loaded locally. I ran these tests on Sabayon Linux with kernel 2.6.30 (I expect 2.6.33 to be faster, since it has been patched with Con Koliva’s kernel enhancements). An interesting note here, not seen in other parts of the result set, is that Arora took longer to load pages on the first time, but was faster on all subsequent reloads. The total score for Arora comes second to Opera. On another note, Firefox with the same extensions, ran faster on Linux than Windows.

Windows

Not surprisingly, the winners on Windows were 32 bit browsers. Aside from the small speed increase due to smaller pointer sizes in 32 bit applications, I think Opera and Chrome are faster browsers, as they advertise. A surprising result is that 64 bit IE ran faster than 64 bit Firefox. I noticed that a while ago, but decided to stick with Firefox because it has add-ons. Iron is a stripped down version of Chrome compiled from source. It should be slightly faster, with the slimmer binary and no personal tracking features. I ran this on Windows 7 Pro 64 bit Version 6.1 (Build 7600).

Conclusion

Opera beat all other browsers, just with its default settings. A little more tuning of redraw rate and memory use could improve the score. I expect the real results when browsing to deviate. Chrome and Firefox has DNS prefetching, Firefox and Opera have pipelining. To improve that DNS fetch speed in Opera, you can set your system to use OpenDNS to resolve domain names.

After the Benchmark (you should decide which browser to use)

I measured the memory use!

It looks Chrome and IE were designed for really cheap laptops. (They can’t run on old computers with Windows 2000.)

I started using Sabayon back in 2007 as it was more fun than Windows XP. I decided on it after trying out many other Linux distributions with Live CDs downloaded and burned at school. Gentoo was the fastest Linux distribution, and Sabayon made it easy to install. At that time, it had automatic graphics card configuration to enable Compiz-Fusion. Compiz-Fusion is like the glassy windows you see in Vista, plus many other effects (the most famous being wobbly windws). I suppose that was the reason so many people tried Sabayon at the time. Unfortunately, on the laptop where I installed Sabayon, the graphics card was not capable of these effects (but I did get lightweight transparent windows, highly useful on a small screen). Anyways, here’s what the wallpaper looked like:

At that time, Sabayon (since it was just a way to install Gentoo) was for power users. The dark red and fossilized penguin footprint certainly leaves the rest of the pack behind. I was able to build a system on an Inspiron 1000 that would load the next web page as soon as I clicked on the link. The Reiser file system did the trick for caches, and compile time optimizations made better use of the Pentium 4 CPU.

Later in 2008, I got my own laptop and dual-booted XP with Sabayon 3.4. It’s hard to say which OS I liked better. Linux had trouble with wireless and crashed whenever I launched a program that used OpenGL. Windows came with all the right drivers, except I can’t do anything besides work and play there. I ended up playing a game called NetHack and spending a lot of wasted effort on an English presentation on Marcus Aurelius’s Meditations. I think I simply used Windows more because I liked the desktop colors:

Sabayon had too many splashes of red here and there, but all that changed with the next release.

This was my first glimpse of the future of Sabayon. It (I mean he) was (all) about dreams (besides a surprise for me). I remember this quite well. It was when Sabayon became a binary distribution instead of just a Gentoo box that came with the box (not exactly out of the box as the wireless required ndiswrapper). Let me emphasize that point again. I got a system I couldn’t boot as soon as I tried hibernate.  Thus, the dreams burned to the ground. So I went back to Windows again, this time with Vista. When I had the chance, I made my computer quad boot with XP, Vista, Sabayon, and Kubuntu. All of them had special characteristics and capabilities. Vista was the only one that could suspend and wake with even cpu frequency scaling on both cores. Kubuntu was the only one that supported a full KDE 4 desktop. Now days, KDE 4 is available for all 4 of them. In the February of 2009, I tried Sabayon 4:

partly hoping those CPU frequency scaling bugs were fixed. However, Dr. Scheme had poorly written C code that required custom compile options. I got my work done in Windows. From May until December I used Windows 7 RC. It was where I was able to do everything in an easy and quick way. Most importantly, I was ahead of the technology curve with the elegant UI (now KDE users are beginning to copy it). I installed Sabayon 5.1 again over the past Christmas break:

This one definitely deserved a version bump as the developers switched from -Os to -O2. -O2 is generally faster, but -Os is always smaller, in terms of compiled programs. This was great, as my CPU fan was used a lot less. I rarely hear it now after a few tweaks. Moreover, this is the first time I used Linux continuously over a month for over a year. Congratulations to Sabayon! More details about each release for those who want to compare what truly matters to a user with what Sabayon has provided through its history:

Sabayon Linux 3.3 x86/x86-64: Press Release

Sabayon Linux x86/x86-64 3.4: Stable Release

Sabayon Linux x86/x86-64 3.5: Stable Release

Sabayon Linux x86/x86-64 4 Revision 1 Rolling Release

Sabayon Linux 5.1-r1 GNOME and KDE: Stable release

I made a post on Sabayon forums summarizing performace tweaks:

http://forum.sabayon.org/viewtopic.php?f=57&t=19762&p=112208&sid=112bbd1996b44132eb064c48c3a460e8#p112208

Update: Now it is in the Sabayon Wiki.

How to make Sabayon run faster

I first noticed a font rendering problem when viewing some web pages in Firefox. There were two cases. The first case was easy to solve. The second case was specific to Firefox, and the fact that many people posted complaints online only made it harder to pinpoint the cause.
Let’s start with the easy one:

1. Go to Tools -> Preferences -> Content
2. Under Fonts & Colors, find Advanced
3. Uncheck Allow pages to choose their own fonts
4. Set fixed fonts:

• Proportional: Sans Serif
• Serif: DejaVu Serif
• Sans-Serif: DejaVu Sans
• Monospace: Luxi Mono
• Minimum font size: 10

DejaVu should come by default with your Linux distribution, as it is an open source font project. Making the above changes will force sites like lifehacker that use Windows fonts to use Linux fonts. For more information, see Help for the Options window.

The second case was harder. I will go through the most common misconceptions first.
Mozilla does acknowledge there is a font problem on Unix platforms, and they have many solutions that did not fix the problem for me. At one point in the article, they suggested the problem was caused by a missing –enable-xft flag. For my system with fontconfig, the article declared, “xft labeled builds should produce clearly better results”. Now, I went about looking for builds with this flag, but it turns out this was a fallacy, too. My fontconfig file clearly affected font rendering on Firefox, as my test script showed. I was able to control the level of hinting at different pixels.
Ubuntu users also noticed this quirk with Firefox, although their fixes did not work for me. One user reported success with changing a Mac OS X setting on Linux. Another suggested a tweak “for advanced ligatures and smarter kerning”, not something I’ve heard of as far as font smoothing goes.
So enough with the fallacies, time to read articles posted by knowledgeable people (again). I mentioned in an earlier article what got me into this font business was a post I read back a while ago on Gentoo Linux. I still have its first edition in my email archives. So what was the problem, and how did I solve it? Firefox used the Cairo backend for rendering graphics. This was good as far as pretty vector graphics went. However, it turns out that Cairo is a poor choice for font rendering, as it needs to be patched to render bitmaps correctly for LCDs. Fixing the problem is easy on Gentoo:

1. vim /etc/portage/package.use
2. insert “x11-libs/cairo cleartype”
3. emerge cairo

The next time I used Firefox, I noticed the discolored edges around fonts were gone! No more eye sore reading web pages!