Phasor Burn

Cobalts have got to be the flakiest little boxes I have ever seen. Good thing they’re not made any more. Lack of reliable support or information of any kind, and general instability when under heavy load are all contributing to a very bad taste in the back of my mouth right about now. They look like they may have been the cats ass circa 1999 or 2000, but this is the new millenium now.

If you are a small ISP using Cobalt’s for hosting customer domains, I would recommend building a more robust web + email infrastructure than a teetering pile of discontinued cobalts. If you’re not serious about providing a particular service, then don’t provide it at all.

I understand wanting to be a one stop shop for the small mom and pop businesses out there, but they more than anyone else have next to zero clue about the reliability of email, web servers, or the internet in general, and will wail big buckets of crocadile tears when their email breaks.

If you’re not up to the level of thinking about writing RFC’s or whitepapers on how to build scalable web and email infrastructure (and very few people are, to tell the truth, myself included) then perhaps you ought to look at a place like Canada Web Hosting.

If you’re going to offload a perceived business-critical business service to some outside party, you’d most likely be willing to pay a bit of coin for something that is reliable, has responsive support, etc. If you can’t provide this level of service to your customers, why not white label it? They’ll never know.

White labeling means the service provider will brand their offerings with your company identity, answer a support phone number and email box as if they were in your employ, and so forth. The customer needn’t know anything other than you have this armada of clustered machines that never go down and a support line that is always answered by knowledgable staff.

Interestingly useful tip of the moment :

Unique password generator bookmarklet

I stumbled upon a well written set of pages describing “OS X”

It’s written from the perspective of a past systems administrator, current systems engineer (who apparently is working at Sun on Solaris kernel stuff) and has some good details on what exactly OS X’s history is, what is’ made up of, how stuff is put together and so forth.

The conclusion also has a well thought out discussion on why it’s a good client platform, compared to Linux which just doesn’t cut it yet for pure end-user desktop use in anything other than a heavily managed big-momma-corp-it-department kind of way.

Well, isn’t this special.

Working with a bit of code for a postfix policy filter that was originally written on Linux. Works fine there. On the other hand, I am having a bit of trouble getting it to work properly on Solaris.

Run it in full debug mode, non-daemon, spewing to my tty to look at all the gorey details in depth. Hmm, seems fine… run it in daemon mode, at any level of debug and … it’s misbehaving. Weird.

Track it down to this bit of (pseudo code)

while lines in config file
read line and parse it
if foo setting found, do whatever foo setting means.
end-while

No problem, right?

Well, one of the foo settings is daemon mode. When that setting is found, the daemonize call was made which dutifully goes off, forks a few times, closes all file descriptors, etc… and when code returns to the loop… we continue processing that config file right?

Yes! That’s correct! On Linux, of whatever flavour the original author is using, this works.

Not on Solaris. Solaris scrubs the file descriptors clean. Can’t reference anything with them.

I guess somewhere in the bowels of that version of linux, it just marks the fd pointer as not being used anymore but leaves a valid pointer in it, pointing to a chunk of file system buffer in ram and …. for the very short time after the forking and fd closing frenzy, the code can manage to grovel thru the rest of the config file which fits into one disk buffer anyways, being small.

Bonk! Bad programmer! No cookie for you!

And you! Kernel programmer! Come back, no sneaking off now. I want to have a word with you . . .

I hate code that’s written specifically on and for Linux when it could quite easily target any posix compliant system. What’s with the reliance on libs that rely on other libs that only compile clean on Linux?

Yes, shared libraries are there to make coding applications easier. But when the applications themselves or the libraries they depend upon, are not written to plain old posix least common denominator standards . . . you get a mess that only works on the original platform.

Makes it a bitch to get some stuff working on Solaris (or AIX, the other main surviving true UNIX these days) without installing eighteen-petabytes of gnu tool chain and miscellaneous other stuff, only to have the occasional application or library still fail to compile clean. Even with a heathly bit of whacking the code with vi to slap it into a shape more resembling sanity.

Yes, Solaris and AIX have weird bits themselves, but come on…. write to the posix standard, and I’ll concede to using the gnu compiler suite and glibc, no more than that.

Almost makes me want to go be a goat herder.