In my “For A Parallel World” series I have, up to now, only dealt with practical problems related with actual parallel builds. Today, I wish to try something different writing about some good practises to follow when working with autotools.

Once again I want to repeat that no, I don’t think autotools are completely flawed, or that they are way too complex for normal people to use; I certainly don’t agree that CMake is “just superior” like some good programmer said recently (although I admit after some stuff I’ve seen I’d gladly take CMake over some custom-built makefiles). I do think that there are too many bad examples of autotools usage, I do think that autotools could very well use better documentation and better tutorials, and I do think that a lot of people have been misusing autotools to the point that you blame the tool for how it was used.

You certianly know what the problem I’m referring to right now is, about parallel builds and autoconf: the lengthy and serialised execution of autoconf checks. It’s a very boring part of a build, but it’s unfortunately necessary, usually. What is the problem there though? The problem is that a lot of packages execute more tests than are actually needed, which is going to bore you to death since you’re waiting for things to be checked that you’re not going to have any useful result from.

The causes of this are quite varied: legacy systems being supported, overzealousness of the developer writing with respect to missing headers or functions, autoscan-like tools, boilerplate checks coming from a bastardised build systems (like the one forced upon each KDE 3 package), and of course mis-knowledge of autoconf. In addition to this, libtool 1.5 was very bad and checked for C++ and Fortran compilers, features, linkers and so on even though they were not to be used; luckily 2.2 is now fixed, and upstream projects are slowly migrating to the new version that takes much less time to run.

I’m currently looking for a way to scan a source tree to identify possibly overzealous checks from configure, so that I can help reducing the pointless checks myself, but in the mean time I want to give some indications that might help people to write better autotools-based buildsystems for their projects, at least.

My first suggestion is to require a standard base: I’m not referring to stuff like the Linux Standard Base, I’m referring to requiring a standard base for the language; in the case of C, which is mostly what autotools are used for (okay there’s also C++ but that’s not a topic I want to deal with right now), you can ensure that ou have some stuff present by requiring a C99-compliant compiler. You’re going to cut out some compilers, but C99 nowadays is pretty well supported under any operating system I ever dealt with, and even under Linux you can choose between three C99 compilers: GCC, Sun Studio Express and the Intel C Compiler. As you can guess, as long as you use C99 features, the compatibility between these three compilers is also almost perfect (there are some implementation-dependent things that vary, but if you avoid those it’s quite good).

But the important part here is that, by requiring C99 explicitly, you’re requiring also that the standard headers that come with that, which you don’t need to check for: stuff like locale.h, stdio.h, stdbool.h, stdlib.h, ...; they have to be present for C99 to be supported. And even better, you can require POSIX.1-2001, and _XOPEN_SOURCE 600, so that you have a wide enough featureset you can rely upon. It’s very easy: -D_POSIX_C_SOURCE=200112 and -D_XOPEN_SOURCE=600, together with a C99-compatible compiler (like gcc -mstd=c99 or sunc99) and you can rely upon presence of functions like nanosleep() or gethostname(); you won’t have to check for them.

Now of course to support legacy systems you cannot relay on these standards, that are pretty new and not well supported, if at all, by older versions of compilers and operating systems that you might be interested in supporting. Well, guess what? A good way to deal with this is, rather than checking everything with autotools, and then dealing with all the issues one by one, is to assume things are available and give legacy operating system a chance to run this by having a library to supply the missing parts. Such a library can implement replacement or stubs for the missing functions, and headers; then the users of the legacy operating systems might just provide the library as extra to the project itself.

If you don’t like this approach, which in my opinion is quite nice and clear, you can rely fully on an external library instead, such as glib, to provide you some platform-independent support (like integer named types, byteswap macros, string functions). Again this reduces to requiring things to be available, rather than adapting (maybe too much) the software to the platforms it supports.

Sometimes, these approaches can be a bit an overkill though, since you might not have the need for the full C99, but you can accept C89 just fine, with a few touches; for this reason you might just assume that your functions are present, but they might not be using the exact name you expect (for instance there are a few functions that change name between POSIX and Windows), or you might be wanting to look at the function name for a known replacement function present in an extension library (that might as well be glib itself!).

In these cases you can well rely on the checks that come from autotools, but even then, I’d suggest you to be careful with what you write. One common problem for instance is overchecking headers. Let’s say you have to find at least one header that declares standard integer types (int64_t and similar); in general you can expect that one of inttypes.h, stdint.h or sys/types.h will be present and will have the definitions you need. The simplest test to find them is to use something like this:

dnl in configure.ac
AC_CHECK_HEADERS([inttypes.h stdint.h sys/types.h])

/* in a common header file */
#if defined(HAVE_INTTYPES_H)
# include <inttypes.h>
#elif defined(HAVE_STDINT_H)
# include <stdint.h>
#elif defined(HAVE_SYS_TYPES_H)
# include <sys/types.h>
#else
# error "Missing standard integer types"
#endif

While the code in the header is quite good, since only one of the found types is used, the example code in configure.ac is overchecking, since it’s checking all three of them, even if just the first hit is used. Indeed, if you check the output of a configure script using that, you’ll get this:

..snip..
checking for inttypes.h... (cached) yes
checking for stdint.h... (cached) yes
checking for sys/types.h... (cached) yes
..snip..

(the fact that the test is cached is because autoconf already checks for them, that’s overchecking in autoconf itself, and should probably be fixed).

Instead of the former code, a slightly different variant can be used:

AC_CHECK_HEADERS([inttypes.h stdint.h sys/types.h], [break;])

With this, the checks will stop at the first header that has been found. It might not sound much of a difference but if you pile them up, well it’s the usual point, little drops make a sea. This gets particularly useful when packages rename their include files, or they decide they want to move from just the basename to packagename/basename approach (think FFmpeg you can test for the new one, and if that doesn’t hit, check the old one, but avoid checking twice if the new one hit already.

The same approach can be used with AC_CHECK_FUNCS so that you only check for the first function of a series of possible replacements, and go with that one.

But the most important thing is to make sure that all the checks you run during configure are actually useful and used. It’s not uncommon for software to check for a series of headers or functions to define the HAVE macros, but never use the macro themselves. It’s tremendously unfortunate and it should be avoided at all costs, you should always check your software for that, especially when you make changes that might make checks pointless.

Do you maintain an autotools-based software? Then please take a look at your configure.ac and make sure you’re not running pointless checks, all the users will be happy if you can reduce their build time!

Leave a comment

• Squid kerberos authentication and ldap authorization in Active Directory « Klaubert’s Blog

  How to setup squid to use kerberos and ldap to authenticate to active directory

  tags: klaubert, kerberos, squid, authentication, ldap, activedirectory

Leave a comment

If you have been following packages additions you may have noticed the addition of a couple of packages some weeks ago:

• dev-tex/pdftex
• dev-tex/mplib
• app-admin/eselect-mpost
• app-admin/eselect-pdftex

While our TeX distributions already ship them (pdftex and mpost), the first two are standalone packages and the last two are eselect modules to easily switch and use them.
With the bump to TeX Live 2008 I’ve made it possible to switch between different versions instead of being bound to what has been shipped with the release. This means that they will get bumped more frequently than they used to.

For the pdftex case, it is currently the same version that comes with TeX Live 2008 with the difference that the standalone version is patched to use poppler instead of its bundled xpdf library. I’ve prefered to leave the xpdf library as default for TeX Live because that is what upstream is using but some people asked for it to use poppler instead and a lot of other distributions (debian, fedora and their derivatives) are using it as the only way. That will probably make it easier to get improvements and security fixes on that side. If you wish to try it, install pdftex and eselect-pdftex and use “eselect pdftex” to set the standalone package as your default pdftex!

As for mplib, it is a reworked and rewritten version of the good old metapost. It can be used as a library (as luatex does) but you can also switch your default mpost interpreter to be it via the eselect-mpost package. Upstream says it is a work in progress but so far I have not seen any problem with it.

By the way, I have unmasked TeX Live 2008 today so that means ~arch users will upgrade to this release and can try these alternatives out of the box.

      

Leave a comment

his being my third patch to fix some mythvideo nags, I’m actually starting to get comfortable going in there and trying to find this stuff. It’s still incredibly difficult to try and figure this out, since there’s little documentation and I vaguely understand C++, but it’s fun to attempt and cool to succeed.

This patch fixes an annoying problem I’ve had for a long time — it’s a royal pain setting a cover file for a video. A cover file would be the actual image that shows up in the gallery view for a media file. Without one, you just see a blank little icon which is pretty boring.

Folders are really simple — you just add folder.jpg (or .gif or .png) to the directory, and it will show that. Individual files are a bit tricker. If you were just using the interface, you’d have to first go into the Video Manager to let Myth scan the directory of files, create an entry in the database, then go find the file, edit the entry, and set the coverfile manually.

I originally wrote a script to do that part for me. I would just create a JPEG image for each media file, usually with the same filename, but a different extension, and code in a check to see if both exist, update the videometadata table. All the time, I kept thinking though, it would be so much simpler if Myth would just check to see if the file existed like the folders, and display it. That’s exactly what this patch does.

I pretty much just copied the same code from the part where it looks for the folder icon, and did the same thing. If, for example, you have movie.avi, just create movie.avi.jpg (or .gif, or .png) as the coverfile and you’re done.

Actually, you do have to put the file in the database first, since it still checks to see if there is any metadata for it at all. That is extremely simple, though, either by script or UI navigation. The UI will just add new ones quietly, and you can quickly exit out. The patch will still use your coverfile in the videometadata table too, if there isn’t a similar filename that it can find, so you can apply this and it won’t break your existing setup.

As usual, the ebuild is in my overlay. This one is mythvideo-0.20.2_p15087-r3.ebuild. I’m going to eventually document these a bit better and file bugs with upstream. I know I’m using an “old” version to patch it onto, but the reality is that SVN hasn’t changed at all since that revision, so even the latest version bump is the same code.

I also spent the weekend working out a number of small kinks in my system and setup. I drafted up a new “wishlist” that I have of stuff I’d like to eventually get fixed, and it’s getting smaller all the time. Right on.

As far as mythvideo patches, though, I only have one last small annoyance that, while it doesn’t really bother me, does kind of throw me for a bit of a loop so I’d like to see if I can fix it. The bug is that folder names and file names are sorted differently. I can’t remember which is which off the top of my head, but one of them will ignore prepositions like “The”, and “A” on the front of titles and sort by the second words. So “The A-Team” would show up near the top of the list. Maybe it does that on both file and folder. Anyway, I don’t like it. It’s a bit confusing. I tried looking for where it does that, but I haven’t had much luck yet.

Leave a comment

My church’s general conference (a huge weekend of meetings where all our church leaders are gathered and speak to the entire worldwide congregation) was this weekend, and it was pretty good.  I started off really strong, looking forward to it a lot, but lost some steam as I usually do — it’s hard for me to sit through long meetings.  I guess two hours isn’t that long, but hey,  I find it hard to sit through 7 minute cartoons.

Two (of the five) sessions were really memorable for me.  The first one, when President Monson got up and spoke, he mentioned that there were going to be five new temples built.  One of them was in Cordoba, in Argentina.  I was so excited when I heard that.  I served my mission in Argentina (99-01), in Patagonia (Neuquen mission), and while Cordoba isn’t that close to us, it’s really awesome to learn that the country is going to get it’s second temple, after the one in Buenos Aires.  I’d love to fly down there for the dedication.

It got me thinking about my mission, though, and the people I worked with, and how the Lord really looks after even the least of us.  There is so much poverty and sadness in the areas I served, but the saints try hard to live the gospel.

I imagine the temple is going to be one of the smaller ones, and it reminded me of this small city in my first area.  My first city was Esquel in the province of Chubut.  Near us, there was a really tiny town called Trevelin which couldn’t have had more than a couple thousand people.  I remember walking down this long stretch of barren road, where buildings were dotted across the landscape, sometimes half a mile apart or so, and out in the middle of nowhere, was a little LDS chapel.  The Church only had a small branch in Trevelin, but I don’t think I’ve ever seen a smaller, prouder little building that they had.  Generally speaking, the Church doesn’t build a building unless the membership is either strong or large, and they are paying their tithes, so it really stood as a monument in mind to the faith of these very few members in that little town.  I really wish I had a picture of it, I remember it so vividly.

I do have a picture of us going to the falls there once, which the city was actually famous for.  I don’t have a scanner at home, so it’ll have to wait for now.  I do have a picture of me in my first area, though.  This was actually taken the day I was transferring from Esquel to an even smaller town, 25 de Mayo in La Pampa.

Notice the heavy coat.  It was freaking cold, there.  I remember wearing about five layers of clothes and still feeling like my bones were turned to ice.

Anyway, the rest of conference was good.  I’ve caught about half of every session so far, and I’ll catch up watching the rest during the week.  I did actually make it to the General Priesthood session on Saturday night, which was really good.  In fact, this is the first time in like four years that I actually made it to a church to watch the thing, since something always seems to happen every year, like I’ll get sick, or fall asleep or whatever.  I went with my friend Scott though, and it was great.

There was this one guy who got up, I can’t remember his name, that delivered this really powerful direct talk.  It was just awesome.  He talked about how the way to cast out Satan in our lives is the same things that worked to cast him out of Heaven in the premortal life.  Ah, the memory is fading, and the talks aren’t online yet or I’d quote him directly.  I remember there were three things, and one of them was the bearing of testimony.  Ah, I’m blanking.  Ah well, the archives will eventually be here.

Leave a comment

Recently there were some News that Lenovo does not like Linux any more. This was supported by comments like this at Lenovoblogs (by a Lenovo engineer):

»Again, what’s the incentive for us to start providing all of this intellectual property for free to the Linux community? You may say it drives support for Linux on ThinkPads and people would buy more ThinkPads as a result. I think that’s a dubious assertion at best.«
(the subject was driver support for switchable graphics on modern thinkpads and brings up some common urban legends about linux and driver support)

Sadly, I experienced one more place where Lenovo seems to shift away from a Linux friendly viewpoint: I tried to return the windows license of my new Thinkpad with a pre-made form by Lenovo itself (I got this from someone else by eMail, not from Lenovo directly). In the net, you can find tons of reports that it was easy for people to get money back for their windows licenses by Lenovo.

Though what I got was this:
»Leider können wir Ihrem Wunsch nach Rückerstattung der Kosten für das auf Ihrem Lenovo Produkt vorinstallierte Microsoft-Betriebssystem nicht entsprechen, da das Betriebssystem aus unserer Sicht einen integralen Bestandteil des jeweiligen Lenovo Produkts darstellt.«
(rough translation: We won't refund your windows-license, because we think it's an integral part of the product)

I find it hard to understand why Lenovo makes this shift. When running around on linux conferences in recent months, the number of thinkpads is hughe. While many other vendors shift to a much more free software friendly behaviour (think of AMD/ATI), Lenovo seems to go the different direction. It's especially strange because Lenovo is probably one of the few vendors that has a notable market share in the linux community.

By the way, I welcome any hints how I should continue with the windows refunding. I'd prefer not to capitulate yet (like I did with my last laptop by Samsung), and I assume the law is clearly on my side.

Update: As some of you asked, here is the form by Lenovo, though you'll probably just get the same reply I got.

Probably interesting, here you can find all EULAs from Microsoft. They are quite clear on the subject and say that you MUST return the windows license to the vendor if you don't agree to the EULA.

In the meantime, I wrote several messages about the issue to various people and instutitions. The FSFE is also working on the subject.

Leave a comment

As some of you may have noticed KDE-4.1.2 was released on October 3rd after a 2 day delay for some ABI breakage and despite the news in contrary, no Gentoo is not dying, the ebuilds for this release hit the tree before the tarballs were made available by KDE.

Why are the ebuilds still masked? When will they move to ~arch? The mask was put in place to prevent issues while the ebuilds were committed (it took more than 6 hours) and while the tarballs weren't made public. The p. mask is still in place because we're trying to solve a few final issues regarding the integration of kde-3.5 and kde-4.1 and while we get some docs ready to help install kde-4.1. We plan to take it out of p. mask ASAP - I was hoping for this weekend, but it wasn't possible.

So KDE is getting back on track in Gentoo, hey KDE-4.1.2 got to the tree before GNOME-2.24 and we'll start reviewing the bugs that have been piling up. As always, any help is most welcome, so if you're interested read how to help and don't forget to check the KDE HT page.

Everyone wishing to use KDE-4.1 should read the KDE-4.1 Guide.

Leave a comment

I’ve been spending part of the weekend working out small annoyances in my myth setup, trying to get it inching closer to my “perfect” setup.  I’m actually really close now, minor stuff is all that’s left.

Here’s a few things I want to remember as a point of reference, that took me a bit of research to figure out:

Printing options in MPlayer:

mplayer -list-options <command line arguments>

mplayer -input cmdlist <slave mode commands>

mplayer -input keylist <events>

Mapping Page Up and Page Down with my remote in MythTV:

begin
prog = mythtv
button = ch+
repeat = 3
config = PgUp
end

begin
prog = mythtv
button = ch-
repeat = 3
config = PgDown
end

Finally, I hit some snag with MPlayer and VobSubs (subtitles that originally come with DVDs).  I’ve got some movies in Matroska format, and with recent (SVN r27719) revisions, it will forcibly display the subtitles on playback, and I have no idea why.  I swear I remember reading something about this on the mailing list a while ago, but I haven’t had much luck finding anything.  Best option so far, go back to an earlier revision (r25993).  Not ideal, but it works.  Every sub, force and vobsub option I’ve tried does nothing.  I’m not passing anything by default like -slang or -sid to mplayer.

Another thing I’ve been working on (I’m really bored) is finding posters for the cover images in my movies folder.  Which got me looking at UK quad posters.  If you haven’t ever seen the posters from across the pond, they are so much better than our American counterparts.  They are a horizontal landscape, which allows for, in my opinion, a much more dramatic picture.  Check out this Star Wars one, for example.

It just looks so much better, in my opinion.  I gotta get some movie posters up on my wall (only two so far: Tron and The Adventures of Milo in the Phantom Tollbooth), and I’d love to hunt down some quads.  The old school Disney ones look even awesomer.

Speaking of cover images for Myth, I have a new patch I cranked out last night, which has an interesting story to it.  I’ll post details later, though.  I’m not in the mood for details right now.  I’m more about hunting down stupid bugs that don’t require too much brain power.

Leave a comment

You might or might not remember of gitarella, on old project of mine to write a replacement for gitweb. Some of the reasons why I started the project (like gitweb URLs being not so friendly and other things) are probably no more relevant since gitweb improved a lot. Gitarella on the other hand I didn’t work on for such a long time that now is almost certainly not working, since it’s using deprecated git commands and so on.

For a while I thought to just give up on Gitarella in favour of cgit, that is written in C and so it has to be much faster, but I didn’t look into much more because gitweb at the time was suiting my need well enough. Since lately I’ve been working on quite a lot of different projects with some simple patches or series of patches, many of which are available on git repositories which I can just republish with my patches applied as a branch, my git repositories started looking tremendously heavy for the simple gitweb.

One thing that really I can’t understand is how is it possible for gitweb not to generate any kind of cache for the pages. This is quite a mistake in my opinion; while admittedly it’s impossible to properly cache the index page, for instance, and that requires a lot of queries, the commit description pages, the patch pages and so on can easily be cached up, as they cannot really be changed (you can use the SHA1 id as index for those pages).

If I remember correctly what I was told a longish time ago, cgit does cache pages on disk, which would make it an ideal candidate, if it wasn’t that it doesn’t execute git commands at all but rather links in libgit.a; feel free to check your dev-util/git install, there is no libgit.a, that is not an officially-supported way to interface to GIT. As you can guess, I don’t like it.

So I guess I might resume my work on Gitarella, especially considering now lighttpd supports scgi, it makes it quite interesting.

Leave a comment

Testing testing testing. We test our models, our controllers, and the integration between them. But how often do we pay attention to helpers? Not very often, if the test coverage of my current project's helpers is any indicator.

There are a few tools out there for testing your controllers. There's a plugin called helper_test. ZenTest also provides Test::Rails::HelperTestCase.

There's an even better way, and it's included with Rails itself since at least 2.1: ActionView::TestCase. The name might be misleading, but it's intended for testing view helpers. It also is a kind of underdocumented.

You can skip ahead to the summary if you want the dirty details.

Your very first helper test

The Rails test layout doesn't have an obvious place to put helper tests. I'll take a cue from helper_test, and say to put them in test/unit/helpers. That way, they will be run by rake test:units.

The skeleton test

Let's start out with testing ApplicationController, in test/unit/helper/application_helper_test.rb:

require File.dirname(__FILE__) + '/../../test_helper'
require 'action_view/test_case'
class ApplicationHelperTest  ActionView::TestCase
  def test_nothing
    assert true
  end
end

Some notes:

• We do a typical require of test/test_helper.rb
• I'm requiring 'action_view/test_case', because without it, we see an error like uninitialized constant ActionView::TestCase (NameError). I feel like ActiveSupport should find this automatically, but it isn't. You can also toss this in test/test_helper.rb.
• Inherit ActionView::TestCase
• Placeholder test

What to test

I want to add a helper for displaying a navigation tab. It will just go to index of a controller you specify. The link should have the 'current' class if you're rendering from controller you are making a tab for.

Based on that, we have two contexts to test:

• Making a tab for the current controller
• Making a tab for another controller

Test it first

You'd always be using the helper from a specific controller, so we'll have a parent context of being in a controller, like EventsController.

Now that we have some context, and some specifications, let's translate this into a Shoulda's terminology.

context "creating a tab for 'events'" do
  setup do
    @tab = tab_for('events')
  end

  should "list item with a link to events with 'current' class" do
    assert_dom_equal '<li><a href="/events" class="current">Events</a></li>', @tab
  end
end

context "creating a tab for 'projects'" do
  setup do
    @tab = tab_for('projects')
  end

  should "list item with a link to projects without 'current' class" do
    assert_dom_equal '<li><a href="/projects">Projects</a></li>', @tab
  end
end

The parent context doesn't do anything yet, because we don't know any implementation details about how it's going to determine the current controller. assert_dom_equal, as the name implies, checks that the DOM of the given strings are equivalent. Presumably, this takes care of whitespace, casing, etc.

Let's run it the first time... RED, because we don't have any implementation.

First pass at implementing it

Let's try a first implementation:

module ApplicationHelper
  def tab_for(name)
    url = send("#{name.downcase}_path")
    content_tag :li do
      link_to(name.capitalize, url)
    end
  end
end

Briefly put:

• We're generate a url. This presumes that the there's a path defined like events_path, as if by map.resource :events.
• Make a <li>
  • Make a link to the URL we just generated

Let's see how this fares... some GREEN, but still RED. Creating a tab for another controller passes, but creating a tab for the current controller fails. That's because we never determine if we're on on the current controller. How are we going to do that? Here's some fun facts towards enlightenment:

• Helpers are included in the view.
• The view exposes controller, which is the rendering controller
• ActionController::Base exposes controller_name, which has a stringified name of the controller, ie 'events' for EventsController.

I want to check the value of controller.controller_name. We can stub controller to return an actual EventsController using mocha:

context "When on the events controller" do
  setup do
    self.stubs(:controller).returns(EventsController.new)
  end
  # ...
end

And... we have the same failures. No wonder, because we didn't change the implementation. Now to give it another try:

def tab_for(name)
  url = send("#{name.downcase}_path")
  content_tag :li do
    attributes = {}
    attributes[:class] = 'current' if controller.controller_name == name
    link_to(name.capitalize, url, attributes)
  end
end

Wait for it, wait for it... GREEN!

Summary

I believe that wraps things up. Let's just do a quick recap:

• Stash tests in test/unit/helpers
• Name your tests like your helper, ie ApplicationHelperTest for ApplicationHelper
• Inherit from ActionView::TestCase
• require 'action_view/test_helper' somewhere, probably in test/test_helper.rb
• Your helper will be included into your test, so you can just use its methods
• If you need to touch stuff that would normally be included in the view, stub it out
• Use assert_dom_equals to test the output. Alternative, you might use assert_equal or assert_match

Gotchas

Testing helpers this way is not quite bullet proof though. While coding this up, I encountered a few tough errors that spit out a stack trace because of a nil value somewhere down in the Rails stack. For, I tried using url_for instead of using the named routes, and ActionView::TestCase didn't take too kindly to that.

I'm finally back on the net, after not having any internet access at my new apartment in Zürich after I moved there.
I now started my bachelor studies at the ETH Zürich, of course in Computer Science, though there's a little bit too much maths right now for me to be really excited about it, future semesters will be better I hope.
So I'll try to get back to a few Gentoo things in the near future, now that I also finally fixed up my main dev system (which had its disk die just before I moved)...
Still this blog entry's main focus is to tell you the name of a package I discovered today:

app-misc/tmux

After reinstalling this system I, as always before, emerged screen to take care of my detached terminal needs, I always had the problem with backspace not working correctly from the desktop, which I was never able to fix correctly, but it was bearable. This time it seems something else went wrong too, and inside my screen sessions it didn't source .bashrc or .bash_profile (which sources .bashrc), even if the shell was correctly set to a bash login shell...
So, while perusing Gentoo Wiki's Screen TIPs to see if anyone had seen something like this, at the end of that page I came across the mention of tmux, a "simple, modern, BSD-licensed alternative to GNU Screen".
Seeing that it only depended on ncurses (which is usually installed everywhere), and was only like 100kb of source, I installed it and tried it out. I have to say I'm impressed, this little tool does everything I did with screen too (mainly just having multiple, detached terminals and resuming them, which is probably no "advanced screen usage", but what most people will likely need), backspace works without any fiddling, the Bash stuff is correctly sourced, and the few commands are easy to adapt to, here a little overview:

tmux

CTRL-b d

tmux a

Leave a comment

As I’ve written before, I’ve been working on FFmpeg to make it build with the Sun Studio Express compiler, under Linux and then under Solaris. Most sincerely, while supporting multiple (free) operating systems, even niche Unixes (like Lennart likes to call them) is one of the things I spend a lot of time on, I have little reason to support multiple compilers. FFmpeg on the other hand tends to support compilers like the Intel C Compiler (probably because it sometimes produces better code than the GNU compiler, especially when coming to MMX/SSE code—on the other hand it lacks some basic optimisation), so I decided to make sure I don’t create regressions when I do my magic.

Right now I have five different compile trees for FFmpeg: three for Linux (GCC 4.3, ICC, Sun Studio Express), two for Solaris (GCC 4.2 and Sun Studio Express). Unfortunately the only two trees to build entirely correctly are GCC and ICC under Linux. GCC under Solaris still needs fixes that are not available upstream yet, while Sun Studio Express has some problem with libdl under Linux (but I think the same applies to Solaris), and explodes entirely under Solaris.

While ICC still gives me some problems, Sun Studio is giving me the worst headache since I started this task.

While Sun seems to strive to reach GCC compatibility, there are quite a few bugs in their compiler, like -shared not really being the same as -G (although the help output states so). Up to now the most funny bug (or at least absurd idiotic behaviour) has been the way the compiler handles libdl under Linux. If a program uses the dlopen() function, sunc99 decides it’s better to silently link it to libdl, so that the build succeeds (while both icc and gcc fail since there is an undefined symbol), but if you’re building a shared object (a library) that also uses the function, that is not linked against libdl. It remembered me of FreeBSD’s handling of -pthread (it links the threading library in executables but not in shared objects), and I guess it is done for the same reason (multiple implementation, maybe in the past). Unfortunately since it’s done this way, the configure will detect dlopen() not requiring any library, but then later on libavformat will fail the build (if vhook or any of the external-library-loading codecs are enabled).

I thus reported those two problems to Sun, although there are a few more that, touching some grey areas (in particular C99 inline functions), I’m not sure to treat as Sun bugs or what. This includes for instance the fact that static (C99) inline functions are emitted in object files even if not used (with their undefined symbols following them, causing quite a bit of a problem for linking).

The only thing for which I find non-GCC compilers useful is to take a look to their warnings. While GCC is getting better at them, there are quite a few that are missing; both Sun Studio and ICC are much more strict with what they accept, and raise lots of warnings for things that GCC simply ignores (at least by default). For instance, ICC throws a lot of warnings about mixing enumerated types (enum@s) with other types (enumerated or integers), which gets quite interesting in some cases -- in theory, I think the compiler should be able to optimise variables if they know they can only assume a reduce range of values. Also, both Sun Studio, ICC, Borland and Microsoft compilers warn when there is unreachable code in sources; recently I discovered that GCC, while supporting that warning, disables it by default both with -Wall@ and -Wextra to avoid false positives with debug code.

Unfortunately, not even with the combined three of them I’m getting the warning I was used to on Borland’s compiler. It would be very nice if Codegear decided to release an Unix-style compiler for Linux (their command-line bcc for Windows does have a syntax that autotools don’t accept, one would have to write a wrapper to get those to work). They already released free as in beer compilers for Windows, it would be a nice addition to have a compiler based upon Borland’s experience under Linux, even if it was proprietary.

On the other hand, I wonder if Sun will ever open the sources of Sun Studio; they have been opening so many things that it wouldn’t be so impossible for them to open their compiler too. Even if they decided to go with CDDL (which would make it incompatible with GCC license), it could be a good way to learn more things about the way they build their code (and it might be especially useful for UltraSPARC). I guess we’ll have to wait and see about that.

It’s also quite sad that there isn’t any alternative open source compiler focusing, for instance, toward issuing warnings rather than optimising stuff away (although it’s true that most warnings do come out of optimisation scans).

Leave a comment

Most of the users in ~arch will probably have noticed a new major version of dosfstools, 3.0.0. More information about of this release can be found on Daniel’s blog.

A very good question now would be asking why would I be blogging about this, considering I’m not the maintainer of dosfstools, I didn’t bump it, nor I have any bug open about it. The reason is actually simple: I have a masochistic interest in renewing code for old, important utilities. This is probably the reason why I started unieject in the first place: the old eject utility for FreeBSD was just bitrotting.

So once I had the opportunity to clone Daniel’s repository, I decided to start hacking a bit at it in the free time I took out of lscube hacking. The first step was, quite obviously, replacing the build system with autotools, which was already in Daniel’s plans. The straight replacement was quite easy and quick, although I guess there might be need for more fine-tuning in the future. The nice thing about autotools is of course that you can check for most of the extensions you might want to use in your code, be them compiler extensions or operating system extensions, but it’s also quite a mess when you have to check for each and every feature, function, include file, and so on.

My solution to reduce the amount of feature testing needed is to use modern standards, starting from C99, that ensures you of the presence of certain includes, features, and so on. This includes some boolean support (stdbool.h), the offsetof macro, standard integer types and so on so forth. So the next step was to push C99 support on autoconf, and make sure the code still builds with C99 features turned on (this usually encounters problems with the inline functions support).

The rest of the changes have been my usual checklist for software: cowstats and missingstatic, various warnings, and so on. But I then branched off again to try a different thing: using glib for dosfstools; there are a few things where glib can be useful for such a software: byte swapping macros (that are almost certainly faster with glib, since it supports assembler byte swapping macros under many platforms, included ARM if I remember correctly, which, being big endian, is a place where dosfstools would be using byte swapping a lot), command-line options parsing (which right now are quite messed up), lists, ...

The move to glib is not yet convincing, it’s still a low-level system utility set that we’re talking about, and glib is not exactly a system library, yet. It might be especially a problem for uClibc-based systems, which would be bad and would drive the experiment to a cliff, but git makes branching for testing quite pleasant so it’s no problem, I guess.

For those interested to take a look to the modified code, it’s available, as usual on my git repository .

Leave a comment

First, thanks to everyone who wrote in on that last entry, and thanks also to Robin and Tony for some specific kernel/hardware ideas.

My workstation continues to lockup not-so-randomly, with the majority of freezes occurring while gaming.

I remembered that I undervolted my CPU a respectable amount a long time ago, so I upped the voltage just a little bit, to 1.175V, thinking that maybe it was undervolted a bit too far, and the issue took a long time to manifest. No change. Can't say I noticed any difference.

Next I thought I'd upgrade to the latest hardmasked nvidia-drivers. No change. Then Marius suggested using the nv driver to see if that fixed things, but the problem there is that a good amount of freezes occur while I'm doing something with 3D graphics, which nv can't do. So that wouldn't tell me much. Also, the graphical corruptions occur at boot and prevent the display of grub.conf, so I figured the X drivers may not be related to the issue.

To test this, Robin suggested that I remove framebuffer support from my kernel entirely. It made the issues worse! Now I seem to be on the right track. Previously, with the framebuffer enabled, the Grub screen doesn't display, but as soon as the kernel loads uvesafb and my initrd early in the boot process, the screen clears up and returns to normal. The fbsplash theme displayed just fine.

With framebuffer disabled, the severe corruption continues all the way up until init enters runlevel 3, as you can see in the following pictures I snapped with my cell phone.

Early in the boot process, just after grub loads the kernel

More mangled text

A clear screen once runlevel 3 begins

Tony figures the graphics card memory is bad, and based on what I see, I'm inclined to agree. I already figured it was probably time to replace the graphics card, so now I'm shopping around.

I've always liked my nVidia chips over the years, and this one has served me well. Still, now that the ATI RadeonHD 4670 is out, I'm strongly considering getting one. I like that it offers better performance than my 7600GT for about $80, which is half of what I paid for the nVidia card two years ago. It can handle UT2004 and any current games, assuming they run on Linux. I only have a 19" monitor, so I don't need to spend a lot of money to find a powerful card at extremely high resolutions.

Plus, the ATI card has basic support from both xf86-video-ati and xf86-video-radeonhd, though neither driver seems to be capable of 3D acceleration. I'd stick with the binary fglrx driver for the time being. The only thing I'm not sure about is whether or not the new & improved Catalyst Control Center Linux Edition (AMDCCCLE, phew!) actually supports fan adjustment, or if the temperatures can be queried and reported in a panel applet. I've been spoiled rotten by my passively cooled 7600GT, so I want to keep control over the fan noise. If there were passive 4670s on the market, I'd get one, but that hasn't happened yet. Maybe in the future, once I'm ready to use the FOSS driver, there will only be one. Right now I couldn't choose between the two; I'm hoping they merge on down the road. Too confusing; this consumer wants less choice.

Y'know, I used to be fairly avid nVidia Linux fan, simply because for so long ATI's support was a joke. It took them forever to come up with a hardware counter to nVidia's SLI tech, and then another ~3 years before the Linux support for it rolled around, and that's just the beginning of their disregard for Linux. But 2007 marked a turnaround, so now I'm actually rather impressed with the amount of work they've done for open-source drivers. They've really been making progress.

nVidia still shows no signs of opening up their stuff, aside from the largely-unnoticed-and-irrelevant CUDA initiative. But for years, their stuff just worked, as much as a binary driver can be expected to, especially compared to fglrx. Maybe old age has mellowed me a bit, as I'm feeling pragmatic enough to think that purchasing a card from the Red Team would be smarter than buying another Green card. I mean, sure, nVidia usually just works for me, but I know they don't plan on doing much featurewise; they've already killed off hardware video playback accel, and they haven't announced anything special for Linux or put out any kind of roadmap. ATI has, with things like UVD2, Xvmc and many other features they intend to bring to Linux in the various drivers. They want users to actually use their hardware features. What a concept! nVidia, you listening? And for reasonable card prices, too.

I mean, nothing nVidia has at the $80 mark comes close to the performance of the 4670. I could immediately put it to use with fglrx in UT2004 and Xfwm4's light window compositing, while at the same time look forward to open-source acceleration in the months to come.

That seems like a win all around, but I'll need to do some more research. Hopefully I fix these hardware issues with just a new graphics card. I'd hate to end up purchasing a whole 'nother machine before the problems disappear.

Leave a comment

I’ve written more than once in the past weeks about my messing with OpenSolaris, but I haven’t explained very well why I’m doing that, and what exactly is that I’m doing.

So the first thing I have to say is that since I started getting involved in lscube I focused on getting the buildsystem in shape so that it could be more easily built, especially with out-of-tree builds, which is what I usually do since I might have to try the build with multiple compilers (say hi to the Intel C Compiler and Sun Studio Express). But since then, I only tested it under Linux, which is quite a limitation.

While FreeBSD is reducing tremendously the gap it had against GNU/Linux (here it’s in full, since I intend Linux and glibc together), OpenSolaris has quite a few differences from it, which makes it an ideal candidate to check for possible GNUisms creeping into the codebase. Having the Sun Studio compiler available too makes it also much simpler to test with non-GCC compilers.

Since the OpenSolaris package manager sucks, I installed Gentoo Prefix, and moved all the tools I needed, included GCC and binutils, in that. This made it much easier to deal with installing the needed libraries and tools for the projects, although some needed some tweaking too. Unfortunately there seems to be a bug with GNU ld from binutils, but I’ll have to check if it’s present also in the default binutils version or if it’s just Gentoo patching something wrong.

While using OpenSolaris I think I launched quite a few nasty Etruscan curses toward some Sun developers for some debatable choices, the first being, as I’ve already extensively written about, the package manager. But there has been quite a few other issues with libraries and include files, and the compiler itself.

Since feng requires FFmpeg to build, I’ve also spent quite a lot of time trying to get FFmpeg to build on OpenSolaris, first with GCC, then with Sun Studio, then again with GCC and a workaround with PIC: the bug I noted above with binutils is that GNU ld doesn’t seem to be able to create a shared object out of object not compiled with PIC, so it requires -fPIC to be forced on for them to build, otherwise the undefined symbols for some functions, like htonl() become absolute symbols with value 0 which cause obvious linking errors.

Since I’ve been using OpenSolaris from a VirtualBox virtual machine (which is quite slow even though I’m using it without Gnome, using SSH to have a login, and jumping inside the Gentoo prefix installation right away), I ended up trying to first build FFmpeg with the Sun Studio compiler taken from Donnie’s overlay under Linux, with Yamato building with 16 parallel processes. The problem here is that the Sun Studio compiler is quite a moving target, to the point that a Sun employee, Roman Shaposhnik , suggested me on ffmpeg-devel to try Sun Studio Express (which is, after all, what OpenSolaris has too), that should be more similar to GCC than the old Sun Studio 10 was. This is why dev-lang/sunstudioexpress is in portage, if you didn’t guess it earlier.

Unfortunately even with the latest version of Sun Studio compiler, building FFmpeg has been quite some trouble. I ended up fighting quite a bit with the configure script and not limited to that, but luckily, now most of the patches I have written have been sent to ffmpeg-devel (and some of them accepted, others I’ll have to rewrite or improve depending on what the FFmpeg developers think about them). The amount of work needed just to get one dependency to work is probably draining up the advantage I had in using Gentoo Prefix for those dependencies that work out of the box with OpenSolaris.

(I’ll probably write about the FFmpeg changes more extensively as they deserve a blog entry on their own , and actually the drafts for the blog entries I have to write starts to pile up just as much as the entries in my TODO list.)

While using OpenSolaris I also started understanding why many people hate Solaris this much; a lot of command spit out errors that don’t let you know at all what the real problem is (for instance if I try to mount a nfs filesystem with a simple mount nfs://yamato.local/var/portage /imports/portage, I get an error telling me that the nfs path is invalid; on the other hand, the actual error here is that I need to add -o vers=2 to request NFSv2 (why it doesn’t seem to work with v3 is something I didn’t want to investigate just yet). Also, the OpenSolaris version I’m using, albeit it’s described as “Developer Edition”, lacks a lot of man pages for the library functions (although I admit that most of those which are present are very clear).

In addition to the porting I’ve written about, I’ve also taken the time to extend the testsuite of my ruby-elf, so that Solaris ELF files are better supported; it is interesting to note that the elf.h file from OpenSolaris contain quite more definitions about that, I haven’t yet looked at the man pages to see if Sun provide any description about the Sun-specific sections, for which I’d also like to add further parsers classes. It has been interesting since neither the GNU nor the Sun linkers set the ELF ABI property to values different from SysV (even though both Linux and Sun/Solaris have an ABI value defined in the standard), and GNU and Sun Sections have some overlapping values (like the sections used for symbol versioning: glibc and Solaris have different ways to handle those, but the section type ID used for both is the same; the only way to discern between the two is the section name).

At the end, to resolve the problem, I modified ruby-elf not to load the sections at once, but just on request, so that by the time most sections are loaded, the string table containing the sections’ names is available. This allows to know the name of the section, and thus discern the extended sections by name rather than ABI. Regression tests have been added so that the sections are loaded properly for different elf types too. Unfortunately I haven’t been able to produce a static executable on Solaris with neither the Sun Studio compiler nor GCC, so the only tests for the Solaris ELF executables are for dynamic executables. Nonetheless, the testsuite for ruby-elf (which is the only part of it to take up space: out of 3.0MB of space occupied by ruby-elf, 2.8MB are for the tests) reached 72 different tests and 500 assertions!

Leave a comment

Kimi Raikkonen, Ferrari. And the Sharkfin..., originally uploaded by fox2mike.

The first even night race in Formula1. Wow. A part of history now and I'm glad I could be at the race in person :)

It was great fun walking the track with teemus on thursday and then Friday, Saturday and Sunday just flew by with loads of F1 and loads more of Zouk.

This was my second F1 race and if I was asked to pick between Sepang and Marina Bay, I think the latter wins hands down. Cheaper food, cheaper merchandise, lovely atmosphere, amazing music, giant screens that were actually viewable to name some. I think the very fact that the race happens in the middle of a city is a win. In Sepang, there was nothing to do after the race, but head back into the city...which wasn't all that much fun in retrospect ;)

I'm sure the organizers will iron out the kinks for the next edition and it will be even more fun overall.

Way to go Singapore, you've given F1 a truly wonderful twist in the tale.

Last set of pics, Raceday - http://flickr.com/photos/fox2mike/sets/72157607704772359/

X-posted to f1

Leave a comment

Robert:

I just read the license agreement for the Android SDK 1.0 release 1.  It’s definitely not open, by any definition of open I can come up with.

1. I can only use it to develop for Android.  At the moment, I don’t have an Android device, and therefore couldn’t care less about Android.  I do have an n810, and would love to play with it there.

2. I ” may not copy (except for backup purposes), modify, adapt, redistribute, decompile, reverse engineer, disassemble, or create derivative works of the SDK or any part of the SDK”.  This means no porting Android to another device, or modifying it in any way.

3.  I “may not load any part of the SDK onto a mobile handset or any other hardware device except a personal computer”.  This is the oddest restriction of all.  I can’t use it to develop software for an android phone?  At any rate, no porting for me.

Okay, none of this applies to open source licensed components.  Lets see what I can actually use:

1. The kernel (woo hoo!  I can get the kernel elsewhere)

2. webkit.  I have this on my laptop already.

3. An android emulator.  That’s something, I guess.

4. An eclipse plugin.  I don’t use eclipse.

Until enough of Android is release open source to be useful, you can hardly claim that Android is “open”.  I’m still holding out hope.  I honestly hope that Android is released.  But until it is, I can’t in good conscience get an Android phone.

What I would really like to see is a port of Android (or at least it’s UI) to the Nokia internet tablets.  Too bad that’s not possible.

Leave a comment

If you like IDEA and use Struts 2 you can be happy to know that 8.0 release comes with a new Struts 2 plugin. There is a small tutorial on how to use it but it has some errors.
First the Action class should extend ActionSupport hand have proper setter methods:

package hello;
import com.opensymphony.xwork2.ActionSupport;
public class HelloWorld extends ActionSupport {
    private String username;
    private String message;
    public String getMessage(){
        return message;
    }
    public String execute(){
        message = "Hello, " + username + ".";
        return SUCCESS;
    }
    public String getUsername() {
        return username;
    }
    public void setUsername(String username) {
        this.username = username;
    }
}

Second the JSP file can have a proper action:

< %@ page contentType="text/html;charset=UTF-8" language="java" %>
< %@ taglib prefix="s" uri="/struts-tags" %>
<html>
  <head><title>Simple jsp page</title></head>
  <body>
		Struts 2 Message: <s :property value="message" default="Guest." />
		<s :form method="GET" action="HelloWorld">
			Enter your name:<s :textfield name="username" />
			<s :submit value="Submit" />
		</s>
  </body>
</html>

And finally struts.xml can have the Action declared without the ugly unRESTFUL .action:

< ?xml version="1.0" encoding="UTF-8"?>
 
< !DOCTYPE struts PUBLIC
  "-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"
  "http://struts.apache.org/dtds/struts-2.0.dtd">
 
<struts>
    <package name="/" extends="struts-default">
		<action name="HelloWorld" class="hello.HelloWorld">
			<result name="success">/index.jsp</result>
		</action>
	</package>
</struts>

I really like IDEA when it comes to Java codding, and I can live with the quirks of the Struts 2 support. But one thing that makes me steam is the fact that I have to un-deploy and deploy the application for each change I make. That steals me hours every week.

Leave a comment

A Luca wrote, since I came home from the hospital I’ve been working quite a bit on LScube, in particular working on porting feng to use glib, which is a very interesting thing considering that it also allowed to reduce the dependencies (no more need for libgcrypt for instance, which was a problem to me since it didn’t use pkg-config and I find that a bit medieval nowadays).

One other thing that feng lacked was support for running as a daemon; as git-daemon shown recently, having proper support is much better than faking it through start-stop-daemon.

A proper support for running as a Unix daemon mean quite a few different things: proper logging to either stdout/stderr (when not running as daemon) or syslog (when running as daemon); pid file generation (a file, usually in /var/run, where the process ID of the running daemon is written); proper check for forking (so that the user is told if the daemon failed to start; check for if the daemon is running already if trying to execute it again on the same pid file (multiple instances, where allowed, should use multiple pid files); privilege dropping (you don’t want your daemons to run with root privileges, although the ones who provide network service might need those privileges at once to open privileged ports (below the 1024 boundary).

Implementing all these things can easily be a boring task considering that is almost the same for each daemon you might be writing (feng is not the only daemon in lscube). Luckily, someone already thought about this and started working on a solution: Lennart’s libdaemon, which he used for the Avahi daemon.

But as it happens, although libdaemon 0.12 (which is not even the latest version) already provides enough of the basics needed for feng, there are a few things that would require further wrapping around in the code of feng itself. This includes verbosity handling (you might not want to have information output on stdout/stderr; while with syslog you can easily configure your logging to reduce the output, on stdout/stderr you either implement verbosity or you get everything that is logged through the daemon_log() function), and privileges dropping.

The nice thing of working with good maintainers, though, is that they are open to suggestions and extensions, so thanks to Lennart availability, I started implementing those parts that I was lacking. Hopefully in a not-so-long time, there will be a new libdaemon release, which feng will use, that will provide all the needed functionalities.

I really like this approach since it allows to do the things right once and for all, upstream, without having to reinvent the wheel every time, especially considering that it’s not rare that, trying to reinvent the wheel, you get it octarine octagonal rather than round.

For those who would like to take a look at the work in progress of my extensions, you can find them on my git repository together with some autotools fixes and some patches for OpenSolaris compatibility.

Leave a comment

If you follow my delicious you might have noticed some recently tagged content about Ruby and Gtk+. As you might guess, I’m going to resume working with Ruby and in particular I’m going to write a graphical application using Ruby-Gtk2.

The problem I’mt rying to solve is related to the downtime I had the problem is that I cannot stay logged in in SSH with top open at any time of the day in my vserver to make sure everything is alright, and thus I ended up having some trouble because a script possibly went haywire (I’m not sure whether it went haywire before or after the move of the vserver to new hardware).

Since using Nagios is a bit of an overkill, considering I have to monitor a single box and I don’t want to keep looking at something (included my email), I’ve decided that the solution is writing a desktop application that will monitor the status of the box and notify me right away that something is not going as it should. Now of course this is a very nice target but a difficult one to achieve, to start with “how the heck do you get the data out of the box?”.

Luckily, for my High School final exam I presented a software that already was a stake to the solution, ATMOSphere (yes I know the site is lame and the project is well dead), which was a software to monitor and configure my router, a D-Link DSL-500 (Generation I) that used as operating system ATMOS (by GlobespanVirata I still have the printer in-depth manuals for the complex CLI interface it had, both serial and telnet protocol based); together with the CLI protocol for setting up basic parameters, I used the SNMP to read most parameters out of it. This is the reason why you might find my name related to a library called libksnmp; that library was a KDE-like interface to the net-snmp library (which was at least at the time a mess to develop with), which I used not only for ATMOSphere, but also for KNetStat to access remote interfaces (like the one of my router); since then I haven’t worked with SNMP at all, albeit I’m sure my current router also supports it.

Despite being called (Anything but—) Simple Network Management Protocol I’d expect SNMP to be much more often used for querying rather than actually manage, especially considering the bad excuse of an authentication system that was included in the first two versions (not like the one included in version 3 is much better). Also it’s almost certainly a misnomer since the OID approach is probably one of the worst one I’ve seen in my life for a protocol. But beside this, the software is very well present (net-snmp) and nowadays there is a decent client library too, in Ruby, which makes it possible to write monitoring software relatively quickly.

My idea was to just write up something that sits in my desktop tray, querying on a given interval the server for its status, the nice thing here would be being able notify me as soon as there’s a problem, by both putting a big red icon in my tray and by showing up a message through libnotify to tell me what the problem is. This would allow me to know immediately if something went haywire. The problem is: how do you define “there’s a problem”? This is the part I’m trying to solve right now.

While SNMP specifications allows to set errors, so you could just tell snmpd when to report there’s an error, so that it was not the agent but the server to know when to report problems, which is very nice since you just need to configure it on the server and even if you change workstation you’ll have the same parameters; unfortunately this has limited scope: on most routers or SoHo network equipment you won’t find much configuration for SNMP, the D-Link ones, albeit supporting SNMP quite well, didn’t advertise it on the manual nor had configuration options on the wepages, the 3Com I have now has some configuration for SNMP traps and has support for writing through SNMP (luckily, disabled by default); I guess I’ll have to add support for writing at least some parameters so I could set up devices like these (that supports writing to SNMP to set up the alarms). But for those who also lack writing support, I suppose the only way would be to add some support for client-side rules that tells the agent when to issue a warning. I guess that might be a further extension.

Right now I’m a bit at a stop because the version of Ruby-Gtk2 in portage does not support GtkBuilder, which makes writing the interface quite a bit of an issue, but once the new version will be in, I’ll certainly be working on something to apply there. In the mean time, I’m open to suggestions as to other monitoring applications that might save me from writing my own, or in ideas on how I could approach the problems that will present themselves. I think at least I’ll be adding some drop-down widget like the one for the worldclock in Gnome (where the timezones are shown) with graphs of the interface in/out bandwidth use (which would be nice so I could resume monitoring my router too).

Okay for now I suppose I’ll stop here, I’ll wait for the dependencies I’ll need to be in Portage, so maybe someone will find me something better to do and a software that does what I look for.

Leave a comment

At last I got a bit of time away from work and is now sitting in the train¹ enroute to CPH for Open Source Days 2008. This is the first year that I attend both days of the conference and I must say that I'm looking forward to many of the presentations. Currently I'm planning to attend Martin Parm speaking about large scale installations with Gentoo, Nigel Kersten about Puppet, good old PHK about Best Practives, Mads Toftum about Grumpy Sysadms, and Andreas Ericsson about Nagios. This year I think I might skip Ralf and Pattrick's talk about Amavisd-new in favor of the Vyatta talk. Though I'm not sure, I do like amavisd-new... so many choices.

Anyways I'm looking forward to getting out of the dusty office and get some new inspiration...

¹ Again DSB managed to mess up almost everything. Delayed departure, missing wagon, missing seats, so much for DSB 1'...

Leave a comment

Oh, how the hardware hates me. My poor Gentoo development box and primary desktop workstation has been suffering a long string of random lockups lately.

It's not heat. CPU temps are anywhere from 26C to 42C depending on load. GPU between 48C and 62C depending on load. Hard disks are steady at about 30C. All well below anything approaching a danger zone.

I figure it ain't my power supply. I have a quality Seasonic SII-380W that's given me two years of sterling service. My system doesn't come close to exceeding its capacity.

I tend to get more frequent lockups when doing 3D-intensive stuff, such as playing UT2004. That's when I get the most lockups. However, they also happen when I'm just doing desktop work or have a browser open. I normally run Xfce with the compositor enabled, so at first I suspected it was unstable. Turning it off made no difference to the frequency of lockups. Scratch that.

Today I cleaned out the machine, getting rid of a fair amount of dust. I had to remove the graphics card to get at its cooling fins, and ever since reinstalling it and rebooting, there are minor graphical glitches covering the screen at bootup, at least until the initrd is loaded. Everything's fine once fbsplash and X kick in. Maybe I shoulda wiped off the PCIe contacts or something?

About the only thing I can do to check the graphics issue is upgrade my drivers, which I'm doing now. I'll go with the latest 177 version. nVidia has listed several stability fixes that may help.

I checked my logs -- there aren't any messages that give me immediate clues. No kernel panics or graphics errors or anything useful in dmesg. Except possibly one thing: in every case of a lockup, immediately before and during it there's a stream of bad/invalid packets running in and out of my NIC.

I'm only noticing this because I have my iptables rules setup to notify me anything that doesn't fit all the chains I've established. I'm wondering if my NIC is on the fritz; perhaps the hardware is getting confused, and it's doing something to . . . something else.

Coincidentally, my router has been quite screwy lately; I usually have to powercycle it in order to connect; it just stops working overnight when my computer's off. And even during the day, it tends to go down while I'm in the middle of doing something. My router's weird, and I have weird stuff in my NIC logs. Could they be related?

The only test I can do right now is start using my other NIC; my motherboard comes with two, each with a separate controller. And I have a few spare ethernet cables, though in my experience they aren't as fragile/problem-prone as SATA cables. May as well swap those too.

To sum up, if the easy software fixes or NIC swaps don't work, I'm going to have to throw hardware at the problem until I get a solution. I could spend $30 (new NIC or router), $140 (graphics card), or even $400 for a new motherboard and CPU.

I hate troubleshooting hardware. It gets expensive real fast.

Leave a comment

Atul recently posted an update on why FOSS.IN/08 is going to be a lot different than previous incarnations. This has already caused a bit of a stir in the both the Indian and International FOSS communities, just going to chip in with a few thoughts.

The goal of the conference seems to be encouraging Indians to create innovative pieces of free and open source software, rather than just contributing tiny bits by doing jobs “no one else wants to do”; read packaging for distros and localization. First off, that is just downright insulting to everyone who has being helping out in those areas so far - undoing months of evangelism in just one sentence. I understand that FOSS.IN isn’t about evangelism and philosophy, but I think it is a bit much to actively undo work that others have been doing. FOSS.IN is India’s largest conference on free and open source software that fair amount of people look upto - a statement like that from the team runs the risk of pushing potential localizers away - harming the FOSS ecosystem rather than helping it. I am sure that’s not the intention of the team, but “low-hanging fruit” is a poor choice of words at best. It’s fine to change the focus of the conference, but it’s possible to have done that without labeling other aspects of FOSS that you don’t want your conference to be about.

The second thing that puzzles me is the choice of putting the “spotlight on Indian contributors”. Given the goal of encouraging more Indians to make significant contributions to FOSS, I don’t see how eliminating international speakers helps. FOSS.IN, being hosted in Bangalore, is going to attract only Indians as delegates, why does it matter if the speakers are Indian or not? I am sure delegates at the conference care more about what the speaker is talking about rather that his/her nationality. In fact, nationality isn’t even relevant to FOSS in any manner. If the number of talks by Indians was seriously low last year, I don’t forsee much change this year either - simply because there are more contributors who are not Indian - a “problem” that FOSS.IN wants to “fix”; but again, how does selecting fewer talks help achieve that? Also, if there are going to be fewer foriegners at the event, why bother organizing “light Indian entertainment”?

Lastly, I see FOSS.IN is drastically narrowing down on its target audience. In fact, I think there is nobody who falls under the category of the ideal participant in FOSS.IN/08. The conference is not for the “newbies”, it’s not for those who wish to help with localization, but rather for those who already possess the technical skills to contribute “significantly” to FOSS. Now, if they bothered to register for FOSS.IN as a delegate, they obviously kn