More bad copyright news in this article from the Globe and Mail.
When reading a photo manipulation article in Linux Journal I found a reference to this monitor calibration link. The settings recommended on this site give my monitors a much more yellowish colour than they had previously. I’m not sure I like it but I figure they probably know better than I do.
Many computer users have fond memories of the old IBM keyboards that made the loud key click sound. Apparently, these people are still building them.
Richard Stallman the man behind the FSF and the GPL has written a short piece on why the term intellectual property should not be used. Personally, I think it shouldn’t be used just because when I see the acronym IP, I think network protocol, not intellectual property.
The blog spammers have found me. I woke up to lots of comment approval requests this morning. Fortunately, due to Bob’s incident I had already turned on the comment approval feature. Since there is a link on his site back here I figured there was a good chance they would hit me soon.
It’s disgusting how these people will take advantage of others for their own gain.
Has anyone else noticed how bad the search features of most websites are? When trying to find the two RCU links in my last blog entry I first attempted to find them using the search features on the Linux Journal website. None of the returned results were what I wanted. So after trying a few queries I turned to Google. I did a search with “site:linuxjournal.com” appended to the same search terms I had tried with the Linux Journal search engine. Right there on the first page were links to both articles I was looking for.
Why do sites even bother having their own search?
This still amazes me. A single Linux kernel image can be used for a 512 CPU machine. See SGI’s work here and the related SlashDot story. Sure you may have heard about Linux clusters with thousands of CPUs before. However, in most cases this was a cluster of machines with 1-4 processors each. The scalability requirements from the kernel side of things are very different when you are dealing with a few CPUs versus 512. You can find out more about the Altrix line at SGI‘s website.
Linux running the worlds fastest computer, wow!
What really fascinates me about this scalability work is the algorithms required. Making a system like this work efficiently isn’t about small optimizations it’s about having algorithms that can scale well.
One technique currently used in the Linux kernel is RCU. Linux journal has had couple of good articles on RCU which are available from their website.
The first release of the Linux QoS Library (LQL) which was on August 31st has been well received. LQL 0.5.0 has been downloaded about 150 times. I have received a few very nice emails from people ecstatic about it, including one even before I had completed sending the release announcements. The first LQL patch arrived in my inbox yesterday; though I haven’t had time to look at it yet.
The resumption of classes has meant I have not had as much time to work on LQL as I would like. However, I have been making slow progress on some new features.
Currently, I am adding statistics support to the QDiscs. This new API will return all of the information in struct tc_stats. The current implementation of this requires a few new classes.
-+ LQLStats ----+ LQLStatsQDisc ------+ LQLStatsQDiscHTB ------+ LQLStatsQDiscSFQ ------+ etc
The LQLQDisc class is getting a new method called lql_qdisc_get_stats() which each subclass will override to return their own LQLStatsQDisc object that contains methods specialized for the specific QDisc. So the expected usage is something like the following.
LQLStatsQDiscHTB *statsHTB = NULL;
statsHTB = lql_qdisc_htb_get_stats(LQL_QDISC(htb));
g_print("Bytes: %i\n", lql_stats_get_enqueued_bytes(LQL_STATS(statsHTB)));
g_print("Packets: %i\n", lql_stats_get_enqueued_packets(LQL_STATS(statsHTB)));
Once the QDisc statistics features are done I will begin on the classes.