Let me set the stage. You have a system that supports dynamiclinking and dynamic code loading in general, with a low-levelinterface for this; for example, modern Unixes have dlopen() , dlsym() , and so on. You also have a language runtime that's entirely staticallylinked, and you want to have a program in this language environmentdynamically load some of its code at runtime, for example to implementsome sort of plugin system. One hypothetical approach to doing this isto directly

This all started with my entry that touched on packaging with Go . Go is attractive partly because itwhat you get at the end is a basically self-contained program with nodependencies (unlike in, say, interpreted languages). One part of thisis that Go static-links everything.

The major advantage of static linking is no runtime dependencies. Thedisadvantages of static linking are that updates to packages (in theGo sense, ie a component or a library) are more of a pain, that theaccumulated

In a comment on yesterday's entry ,Perry Lorier wrote in part:

[...] I know that I don't like userspace NFS servers, because lasttime I tinkered with one it went horribly horribly wrong. [...]

User-level NFS servers basically always explode; they are essentiallyintrinsically doomed unless they get very unusual support from thehost Unix system. The core problem is our old friend NFS filehandles , which are the only identification the NFSserver gets for what filesystem object the

In the process of writing up why we wound up using Linux for our iSCSItargets I wound up looking up the stateof iSCSI target implementations on FreeBSD. It looks like they have onebut it also seems to be a purely user-mode implementation (as a daemon),and when I realized that I discovered that I have an odd visceral biasagainst user-mode iSCSI targets and towards an in-kernel implementation.

I find this odd, partly because I don't know where this bias comes from.

I was recently asked in email why we chose Linux for our iSCSItargets and if it had to do with Linux's widevariety of hardware support. The answer is 'sort of', but there's astory here (which I'm going to simplify a bit).

To start with, our fileserver environment didn't appear out of nowhere;instead it's an evolution of an earlier fileserver environment, one thatwas built out of SPARC Solaris NFS servers talking to (mostly SATA)

Once upon a time, we wanted to buy an 'appliance' style machine . We did our research, made a choice, and put our choicethrough a bunch of qualification and testing in what we figured would beour production configuration. At the last minute we decided to try ourtest unit out in an odd configuration, one that we weren't planning torun in production, just to see how the overall system would look in thatsetup.

It exploded, by which I mean 'the appliance locked up

Because I'm interested in this sort of thing, I decided to generate somestatistics on 24 hours of Atom syndication feed requests for WanderingThoughts . Mostly I'm going to report the relatively raw numbers,although later I'll probably do detailed analysis of one aspect.

The big numbers:

• 2,671 HTTP requests, or one every 32 seconds if distributed evenly.

  (They seem to have been reasonably evenly distributed through theday, although there are some shifts between hours; the peak

As I covered in my entry on why stupid spamming is wasteful , I used to think that spam deliveries werebasically free (and so spammers shotgunned everything because, well,why not) and now I feel otherwise. This is not just a shift of my view;I actually feel that the situation itself changed. Which raises theobvious question of what changed to do this.

My tentative answer is that spamming became commercialized, andspecifically that it became a sophisticated business. As it did so,we saw it increasingly

In a comment on my entry on why DTrace doesn't attract people toSolaris that often , Brendan Gregg left a commentwhere he drew a distinction between two levels of using DTrace:

In terms of difficulty, using the DTrace providers is a little like:

• fbt provider: writing a simple kernel patch
• stable providers: writing a shell script

Sysadmins should be able to handle stable providers (eg, io, proc,sched, vminfo). They are documented - you don't need to reach forkernel code.