Older blog entries for opie (starting at number 2)

Argh!

Why why why does MacOSX not understand that mouse movement in the 21st century is split into 2 domains: speed and acceleration. They spent countless hours on freaking transparency, and not given thought to the damn mouse.

ARGH!

Alright, here's the idea I had.

Background: I work in a NOC that is, of course, 24x7x365. We handle all sorts of stuff.

We were tasked with building up a bunch of servers - Netra T1's - with Solaris 8, and a full-on AMP config (apache, mysql, perl). Well, the guy on the shift before me didn't finish. His ticket entry read something like "built apache and php but php isn't right and neither is apache". Riiight. All this stuff built from source, BTW.

So, anyway, I discovered 2 things: one, it was indeed all screwed up. Two, he has a habit of doing `make && make install && make distclean` because there was no trace of what he passed to `configure`. OK, great; not only do I not know what you're doing, I have no real clue how to not repeat the error.

Or: someone will build a package from source on machine foo, then copy the binary to machine bar. I then am told to log in to machine bar and update the app. Machine foo is always a private box for the engineers and developers, that I have no access to and will never get access to. Well, OK, what options were used? How was it built?

I complain about options a lot, because in my short time here I've learned, no one gets away with `./configure && make && make install`. You need 30 different options to get stuff working.

The Goals: 1. I want to save build and configuration info, in a sensible, automated way. 2. I always want to build from source, always, always. I do not want a binary in a package. Source, source, source. 3. It must be platform-independant, so I can use the same code - completely unaltered - on MacOSX, Linux (all platforms), BSD, and whatever else I can think of.

The Plan: OK, so first, you already have a record of configuration options: configure.status, created by configure. So part one is something like: Add a `make` target, notionall called 'save', that keeps this configuration info somewhere; again, I'm calling it /usr/local/reciepts/PACKAGE-NAME/ until I get a better idea or someone gives me one. Next: capture a list of installed files. This goes in the reciepts dir, too. Generate a stub script, that makes a makefile, with an 'uninstall' target. doing `make uninstall` in this dir removes all the files, natch. Lastly: a stub script that is used in place of configure, or to be exact, uses the saved config data to compile new packages and save configuration. I also *think* that I can use this for automated package builds, better than something like RPM.

The Issues: What if the package gets new options? Well, at least you know how you used to build it...

OK, so here I am.

I work 3rd (graveyard) shift in the NOC of a large-ish ASP. This company is associated with the banner-ad business, among other things. I won't say the name, and I think my first goal is to get an automated way to post that filters out the name of the company... In case I haven't mentioned it already, my opinions and statements are MINE and IN NO WAY relfect the company, its opinions, business practices, or anything else.

Whew.. enough disclaimer.

Anyway: I'm not a free software newbie, been using Linux and *BSD for about 5 years now, but so far my contributions have been minor. I have an idea for a project, one that is relatively new (AFAIK), so I'm going to start grinding on it, and see what happens. My next post will detail the plan.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!