« You have nice hands, Dave | Main | The only question that remains is "which of them do I fire?" »

Go to hell, Costas

This is an awesome post from Jack of the Ogg/Vorbis project:
(Think: Willy Wonka)

Um Pah Lum Pah, Du Pi Dee Doo,
Proprietary formats will make a slave of you.
Um Pah Lum Pah, Du Pi Dee Dee,
Best to be wise and not use M P 3.

What do you get when you make an M P 3?
Besides artifacts and patent royalties?
It's not to late to open your mind.
Use Ogg Vorbis Don't
Fall
Be
Hind.

Don't you pay those
Ger-er-mans.

You could live in
Happiness too! Like
the
Ogg
Vor
Bis
Programmers
Do!


I took some friends to the airport today where they're leaving for a vacation. I took a very sub-optimal route home, though -- I really need to learn the roads around here better. Doh!


Rich Murphy made some groovy points about my last journal entry about having multiple "modules" for system services (including booting) in LAM. His main point was that we should just use dynamically loadable modules and avoid what I was talking about. If I don't post something about this, I'm sure that Darrell will say the same thing. :-)

Here's part of his e-mail:

Let me make a suggestion. Get to know and love dlopen() (or equivalents on other platforms... Solaris = dlopen(), linux = dlopen(), IRIX, AIX, etc., I have no idea). Basically, you make this part of the code modular by loading a shared object. Each shared object has a function, like lam_boot_module_init(), and maybe a lam_boot_module_finish(). Then, you set up a handle into your lam boot module's functions, say you want each module to implement a generic open_remote_node() and close_remote_node() function. You have a structure like:

[code snipped for brevity]

The module loader uses dlopen(), and can be driven from some init script. Then you can use dlsym() to find your lam_boot_module_init function. Call it and get the handle to everything else you care about. Then you're done.

Also, you can require that other modules dynamically load the libraries they need...

The best part is you don't have to rebuild lam every time, you don't have to futz with finding unique names every time, and your interface is perfectly well defined.

You probably want static linking in liblam.a, but why???

His last question is exactly right -- I do want static linking. I have three main reasons why:

  1. When using dynamic libraries/objects, the user inevitably gets
    burned by a) using a wrong/old version -- I'm reminded of DLL
    russian roulette in windoze -- b) paths changing and therefore
    having to set LD_LIBRARY_PATH (or some equivalent), or c)
    doing a new installation of LAM can fuck currently-running MPI
    programs (e.g., MPI programs that run for weeks).

  2. Difference of dynamic linker functions on different OS's; creates
    headaches for us with [potentially] lots of #if kinds of
    statements. Ick.

  3. Creating .so's on different architectures is, at best, a
    nightmare. Libtool only partly solves the problem. Hence, we
    make shared libraries an option, not a requirement. Portability, portability, portability! Unix != Unix.

My end goals are:

  1. Maximum portability and reliability with minimum effort. If I can have configure write out a single .c file instead of changing my whole paradigm (using dlopen(), adding environment variables to potentially specify alternate locations / version numbers of shared libraries, build shared objects, etc. -- that's a large effort.

  2. Minimum change for the user to fuck it up, particularly after the
    installation (see #1, above) -- put it this way: we got a
    question on the LAM list the other day from a user asking how to
    set $PATH. Do I really want to explain the nuances of shared
    libraries to these kinds of users? No.

    Consider the target audience for MPI: scientists and
    engineers. NOT necessarily computer science folks. People who
    still write in fortran. Why? Because it's simple and it works.
    They can chunk in their formulas in really shitty coding styles
    and rely on the compiler to spit our nice optimized code for
    them. They just want it to work -- they don't care how.

    This guy asking about $PATH is a typical example of that.
    So while we privately laugh at him, we'd be pretty hard pressed
    to explain the basics of how a particle beam accelerator works,
    and/or how to make adjustments to it. So one can see his
    viewpoint, at least.

    Granted, we'll probably never have to use a particle beam
    accelerator, but you get my point. :-)

    MPI is just a tool. And it should be darn easy to use the
    run-time environment that is required to run it. And by "darn
    easy", I mean adding one entry to your $PATH, if any. If
    you're very adventurous, you can also add something to your
    $MANPATH. More than that, and the users' eyes glaze over, we
    get bombarded with questions on the mailing list, and users think
    "this LAM is a piece of crap -- why do I have do do all of this
    just to run a job?" They might be damn good technical reasons to
    do the 20 different things to your environment before running a
    LAM job, but no "normal users" will do them. It's almost a PR
    issue. Know your audience. Target them. Make things easier for
    them so that they can concentrate on their real work, not the
    intricacies of how MPI/LAM/whatever works.

    Software needs to suck less, and unfortunately I can't make
    LAM not suck less if I use C++ or shared libraries. Yet. :-(

There were some other interesting side issues in that e-mail conversation, but that's the gist of it.


I'm getting to the end of Stranger in a Strange Land. It's actually getting disappointing. :-(

It started off well as typically SciFi with a human that had grown up with Martians and was returned to Earth. But towards the end of the book, it's just degenerated into discussions about sex and whatnot that seem somewhat frivolous. I understand the point that Heinlein is trying to make, but (IMHO) it could well have been made without descending into semi-porno.

But that's just my opinion...


Watched October Sky with Tracy last night. A good warm-fuzzy flick, with elements of "engineers rule!". I give it 15 minutes.

I also watched End of Days with Arnold Schwartezzenaggerama in it. I thought it was a good movie -- I've always enjoyed christian-end-of-the-world / mysticism movies. However, I can see how it didn't do spectacularly well in the theaters 'cause Arnold portrays quite a different kind of character that his fans know and love. Even though he wins in the end, he's portrayed as a weak ex-cop. Plus he has no witty one-liner puns that he's famous for.

But I enjoyed it, and it had some really great special effects. 20 minutes.


If you're ever in an argument and you start losing, and perhaps realizing that your position is less than correct, you can abruptly win the argument by saying, "Yeah, that's just what Hitler said!".

Most everyone will recoil in horror at the thought of being compared to Hitler. Hence, by invoking a known abhorrent image that probably has absolutely nothing to do with the conversation, you win.

It works the other way, too. If you're arguing with a Neo-Nazi, just say, "Yeah, that's just what Jesus said!" The end result will be the same.


The Myrinet struggle goes on. I find bugs, I fix them. I got it to a point where all the tests that should pass on the Hydra did, and then took it out to LBL. There I found a few endian issues, and a minor seg fault in connect_all().

Now I've got some insidious problems in COMM_SPAWN that I think are actually symptoms of something else. <sigh>

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

About

This page contains a single entry from the blog posted on June 30, 2001 3:15 AM.

The previous post in this blog was You have nice hands, Dave.

The next post in this blog is The only question that remains is "which of them do I fire?".

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.34