The TDI smells like the back of a McDonald's today. In other news, still trying to sort out the mystery crashes of the Notes 8 client.
A half-gallon of used vegetable oil from our deep-fryer has been sitting on the kitchen table for a week now. This morning, I finally put it in the TDI along with some conventional fuel, and drove to work. The exhaust smells noticeably different, sorta like fries that have been sitting for a while. At $6 or $7 a gallon, new vegetable oil isn't really cost-effective to burn as a motor fuel, but in situations like this, where I bought and used the oil for its more conventional uses and am then stuck with figuring out what to do with it, using the Volkswagen as a convenient disposal device makes all the sense in the world.
Most diesels can be modified to run 100% straight vegetable oil. Most people don't do it, however, since the viscosity of the waste vegetable oil (WVO) is way higher than diesel. The modification you end up making is to add some sort of fuel pre-heater so that WVO doesn't clog everything up. However, if you have a small amount of WVO, there's no harm in mixing up to a 20% blend into conventional diesel and dumping it in the tank. So, although it was only half a gallon, my kitchen drain thanks me for not dumping old fryer oil into it, and that guy I blasted with diesel exhaust who was moving so slow in the left lane of 340 this morning probably figures I was carrying a carload of McDonald's hash browns.
We're still trying to sort out the mystery problem that erupted with our Notes 8 clients at my day job.
To recap, after Them Systems Droids sent out a workstation update via the Microsoft Software Distribution Server sewer a week ago, all of our Notes 8 clients failed. You start them, Eclipse paints the workspace background, but before you ever get a login box, the thing explodes. Near as we can tell from the NSD, all that's running there is nlnotes.exe and nnotesws.dll.
But wait, there's more!
We found the following:
- The Notes 7 and the 8.5b1 clients are completely unaffected, regardless of when they were installed on the workstation (which tends to steer us away from changes in security profiles or file/folder permissions as the culprit
- If you log into a local account, rather than the domain login, everything works fine, even if the local account you use isn't necessarily a member of the local administrators group on the workstation (which tends to incriminate security and permissions again).
- Uninstalling and reinstalling the 8 client doesn't affect the problem at all
- Starting the 8 client without Eclipse (the "-sa" switch) causes the crash to happen faster, without drawing the workspace background
- Here's the weirdest thing of all: in attempting to diagnose what's going on, we downloaded and installed the Lotus Notes Diagnostic (LND) ver. 2.6 from the IBM/Lotus site. We installed it, and then started it and fed an NSD into it. It parsed it out, asked us for our Notes ID password so it could create a local NSF into which to store its analysis, and then it successfully started the Notes 8 client with absolutely no problem! What's more, you could then do anything you wanted in the 8 client, including starting the Admin or Designer. And exiting from the LND-created NSF didn't do anything bad. It was as if the LND could magically invoke the 8 client in some way that allowed it to start with full Eclipse but not crash.
We are completely puzzled.
There is no documentation on how LND invokes the client, but you'd have to assume it invokes it with a parameter specifying that the NSF it just created be the first database it opens up, since it goes straight there. Thus, there's a possibility that if we were to invoke the 8 client and specify some particular NSF, maybe it would start up OK. Thing is, I cannot figure out why this would work.
One other wrinkle: if you go to the shortcut for the Notes 8 client on Windows and go to where it says "start in," and remove the strange "/.." from the end of the path there, the Notes 8 client will start. It will not
, however, permit you to invoke the Admin or Designer clients! Those blow out with a CLFRJ0010E error, which normally (according to IBM) means that there's a double space in the path going to your Notes client. There ain't. What's more, this error is much more commonly seen on either Linux clients (this ain't) or clients that upgraded from ND7 (this didn't).
To say that this is puzzling is beyond the point. Of course, our systems people deny that anything they could possibly, possibly
have done could have changed the behavior of the system. However, no one has ever won against me when I have a legitimate Close'n'Play problem. What I have so far is, ND8 worked great on all machines for months, "they did something," and now it works like shit or not at all, but somehow "they didn't do anything."
In the past we have encountered many, many instances where they "altered the security profile" without bothering to document it, and months later, you get someone who'll say, "oh, yeah, that parameter was changed at Microsoft's recommendation." But they don't document it in realtime and of course never test it against the Notes client installations we have because although we have 70,000 people who depend on a Domino server for their job every day, "that Lotus Notes stuff isn't a supported application."
I don't give a shit if you
don't support it, at least don't do anything that screws it up for me
, you clowns.
We will continue to pick at this. Either that, or we'll just run the 8.5 beta client and forget we ever used the 8.0x client.