[KLUG Programming] Pthreads problem

[Adam Williams]

> >>I don't have bad things to say about /proc,....
> >I don't have anything against /proc either; it works, and probably the
> >best abstraction of low level gunk I've seen.
> Yeah, unless you want to talk about programming languages.

Right, for that there is C# (partly in jest, partly not).

> >My only gripe would be thats its a filesystem - i'd prefer something more
> >directory-ish and network aware.
> Yah, that's 'cuz you're a directory/network kinda guy. 

Right, that I am.

> The first reflex of 
> anyone with real UNIX instrincts is to make everything a stream, and they
> did! I guess they pass! :)

I suspect, this is a hold over from the one-big-system-time-sharing
mindset.  Not that it is a bad model, just I think a bit-dated given the
the-network-is-the-computer times we live in.

<RANT>Personally I've grown to just dislike file-system/file-sharing
solutions in general; and always think of them as the LAST resort to
solving a problem.  Filesystems, particularly lots of ones spread all
over, are just to hard to manage.  An entry in a database, even if
exported as a WebDAV volume, is better;  a DSA, or a shared mail folder;
or some kind of project forum.  Given "file space" with no enforced
versioning, entity relationships, etc... users (and alot of developers)
will just make a mess.  And user invented filenames?  Don't get me
started.</RANT>

> >>So the second reason is that sysctl, like setkernel, normalizes syntax, and as
> >>a result makes stuff easier to maintain. I can replace it easily. I can also 
> >>use it to protect the system from someone placing dumb values into some 
> >>pretty sensitive places, by making setkernel a bit less trivial.
> >Exactly.  Replacability is good.  You could even give attributes more
> >meaningful names than fs.file-max or (many worse potential examples). 
> >But that would really be something a distrobution maintainer should look
> >into.
> Actually, I thought about it at several points, since a gaggle of folk were
> writing scripts that had to work across about 4 UNIX variants. The eventual
> outcome was that it just wans't worth our time to write our own completely
> working abstraction layer to set a bunch of different parms on Linux, HPUX,
> Solaris, and AIX, but we came up with something a lot more portable than 
> what is offered by any of the above, more easily documented and changed, 
> and (in the setkernel case) a bit more robust than I showed in my previous
> posting.

If you want a completely portable tuning system Tivoli will sell you
one?  Sit down before they show you the price tag. :)

> One some platforms, the setkernel script is empty, since other scripts do the
> work there. We ut in a comment to that effect, so future script readers are 
> not puzzled by this seemingly useless script.

Comments good.