Posts tagged ‘efficiency’


Create an HTML version of man pages

There is a program designed for the purpose of creating an HTML version of a manual page (man page). This program is called man2html. However, man2html does not create a table of contents in the resulting HTML, which would be very useful for long man pages. But we can actually accomplish that with the man utility itself, believe it or not!

The man utility gives us the ability to view a man page in a browser, with the man page formatted into HTML (with table of contents). This is done using the following command:

man -Hbrowser page

where “browser” is the browser you wish to use, for example “firefox” or “google-chrome” (these need to be in your PATH), and where “page” is the man page you wish to read, for example “bash” or “emacs”.

Unfortunately, the HTML file created for this purpose is a temporary file which is deleted! So if you close the tab or window of the browser, or even refresh the page, you will get an error telling you the HTML file cannot be found anymore! To get around this, we trick the man utility into using the cat utility as the browser. We then let cat redirect its output of the HTML file to a permanent file, like so:

man -Hcat bash > bash.html

After that, we can view the file in a browser:

google-chrome bash.html



Ubuntu 9.10 boot time


I decided to finally clock the boot time on my installation of Ubuntu 9.10 (Karmic Koala). Total time from the GRUB menu to a fully loaded desktop is 31.5 seconds, including the time it took for me to choose my name and type in my password as fast as I could. Time from GRUB menu until login screen was about… I’m not too sure, but around 15-20 seconds.

Not bad! I would be interesting to hear others’ boot time!


Unnecessary database updating

I have a really old laptop that I put Ubuntu on. It used to have Xubuntu on it but even though Xfce is faster than GNOME, I like GNOME better.

There is a problem with a fresh install of Ubuntu however (and all other editions I assume), where there’s heavy unnecessary HDD activity, and the top utility reveals mlocate to be the perpetrator.

To disable mlocate running automatically, I just changed the permissions of /etc/cron.daily/mlocate to 644, by running:

$ sudo chmod -x /etc/cron.daily/mlocate

Problem solved, and no more seemingly random slowdowns by heavy activity on the HDD, which is slow as it is!

Also, turning off automatic checking of updates helps a lot too. It’s a great relief not to be interrupted in your… “work”, let’s call it, by heavy HDD activity, so it’s better to perform updates and package listing updates manually when it suits me.


Project Euler

I’ve become an active member of Project Euler (PE) again. Project Euler ( is a collection of (around 300 or so) mathematical and programmatical problems. I’m not sure when I started the first time, but it’s been a couple of years, I think. Now I’m back again with a bit more knowledge and feeling a bit more comfortable with programming, several programming and math courses later.

When I first joined, I was mostly only comfortable with Java as my programming language of choice, but I’m very interested in learning to program comfortably in C for a few reasons:

  • It is the traditional language in Unix/Linux applications.
  • I like GNU/Linux and Free and Open-Source Software.
  • It is a lot faster than Java… but still has very similar syntax!
  • I like handling pointers for some reason. I feel like I’m much more in contact with the data as I have full control of everything. It’s just so gratifying to get Segmentation Fault after Segmentation Fault and then, after some debugging and messing around with my pointers, finally getting the sought output from the program.

I don’t believe it’s mandatory to join Project Euler to take part in the problems, but I recommend you sign up for an account, because if you do:

  • you can provide answers to the problems and Project Euler will keep track of the problems you’ve solved.
  • you may participate in the forum thread for a particular problem upon solving it, allowing you to discuss your solution with fellow members. (It’s incredible to find solutions written in the J and K programming languages, which afford extremely concise programming.) Note that only relatively recent forum threads are open to new posts, but all threads are open to read (upon solving the corresponding problem, as I already mentioned).

Project Euler is a very fine tool to learn a programming language. If you’re not a programmer by profession and you don’t really have any software needs that aren’t fulfilled, Project Euler provides you with a great environment to experiment with a programming language’s syntax and libraries with problems and tasks to solve and complete.

My goal right now is to solve as many problems as I can using only the standard libraries in the GNU Library (glibc), namely stdlib, stdio and occasionally string (so far I’ve used string only for the strlen function, which I felt was unnecessary to write myself). It’s going pretty well, and it’s kind of fun to have to figure out solutions on your own instead of relying on already-written functions to do the job for you.

Some of the problems at PE can be solved only with the help of pen and paper, but most of them require up to thousands of iterations to find the solution and isn’t feasible without some computational aid. However, according to the site’s FAQ section, which they call “About”, all the problems are designed in a way that a well-constructed algorithm should take no more than 1 minute to output the solution to the problem. I’m very proud of C. Most problems finish in milliseconds, even on the super-slow laptop I use sometimes.



Once again I came across the term Endianness. I’ve never really cared enough or felt I had the general knowledge of the field to understand what endianness really means, but today I finally felt differently. Endianness has an article on Wikipedia and I decided I would read some of it and finally get an understanding of what the term means.

Endianness basically has to do with what comes first. Take the number 128 as an example. The “1” has the most significant meaning because it is the highest number, or the number with the greatest value because of its position. The same goes for any numbering notation that is positional of any base. Take the binary number 00100100 for example (the ASCII code for “$” and Bender’s apartment number). The first 0 represents 0 * 128, the second one 0 * 64, then the first 1 represents 1 * 32, and so on. As you can see, the farther we go to the right, the smaller the value of the position. This is called a big-endian order, that is, the information with the most significance comes first. Then there is little-endian order which would quite simply just make the number 128 be read as 821, but still have the same value.

Big-endian and little-endian order can be something that is important to deal with when writing a computer program, especially for applications that communicate over a network and run on different architectures. This is discussed in the Wikipedia article. You can however have a lot of luck, for example with our dollar sign: 00100100 is a palindrome which means it’s written the same if we write it backwards. Most words and numbers are not palindromes.

Now we get to the practical part of endianness in regular writing and reading on a piece of paper. Say you’re reading an article on astronomy and it gives you some astronomical number that has tonnes of digits, and the writer doesn’t use prefixes or scientific notation because let’s say it’s a popular-science magazine and the target readers aren’t used to either of them.

Say the article talks about a distance in space of 819273987123781233 km. That’s fun to read. If you would be reading the article to one of your friends, you’d likely take a few seconds to first determine how big that number actually is (millions/billions/trillions/etc.), and then start to slowly traverse the big number. Now, we’ve since long invented something called the thousands separator, which would transform the huge number into something slightly more readable, but not by much: 819,273,987,123,781,233. The problem is that we don’t see big numbers like this often enough to “see” how big it is immediately. If we see the number “100,000” or even “100000” we might be able to determine its true size much faster, because those numbers are much more common. But not this one.

The number is spoken as: “eight-hundred and nineteen quadrillion two-hundred and seventy-three trillion nine-hundred and eighty-seven billion one-hundred and twenty-three million seven-hundred and eighty-one thousand two-hundred and thirty-three”. Not only does it take long to say, but even longer to form the phrase in your head when you only have the digits to start with. What would seemingly make things easier would be to move over to a little-endian notation where the smallest number comes first, such that we would have 332,187,321,789,372,918 but it would at the same time represent the same value as before. However, this would force us to say “three, thirty, two-hundred, one thousand, eighty thousand, seven-hundred thousand, three million” and so on. Even if it is easier to start reading and saying the number much quicker, this is still as inefficient as the old way, or worse, since we have to say “thousand” and “million” and “billion” as so on for each digit that we come to.

This is where I propose the adoption of a more peculiar style of what I call little-endian thousands-separated notation, which is based on the fact that we like to group things by the thousands, and multiples and exponentiations of one thousand, in our numbering system. The basic idea is to either say the first 332 as “two-hundred and thirty-three” and keep a pure little-endian literal notation, or the even more peculiar, but most likely underestimated, notation that looks like this: 233,781,123,987,273,819, which you would read as “two-hundred and thirty-three seven-hundred and eighty-one thousand one-hundred and twenty-three million nine-hundred and eighty-seven billion two-hundred and seventy-three trillion eight-hundred and nineteen quadrillion”. This way, we can compress not only the way we actually think the huge number in our head but also the way we say it. We can also benefit from being able to start reading and saying the number right away without having to scan more than 3 digits at a time, which would come more and more naturally as this notation becomes more widely adopted. As an added bonus, saying really huge numbers could add excitement, because as it is now, we say the highest number first, thereby ruining the surprise of just how big the number really is.