Re: [OT] Re: Smile and FruitMenu
Re: [OT] Re: Smile and FruitMenu
- Subject: Re: [OT] Re: Smile and FruitMenu
- From: "John C. Welch" <email@hidden>
- Date: Tue, 07 Dec 2004 20:02:13 -0600
On 12/07/2004 19:35, "Bill Cheeseman" <email@hidden> wrote:
> Not necessarily, for the reasons given above. Another way to look at it is
> that Unsanity is uncommonly imaginative and creative, and they have found
> ways to do things that the market obviously wants. The fact that there
> aren't many others around who use the same techniques doesn't mean that the
> techniques are wrong or inappropriate, but only that others haven't yet
> figured out how to use them to advantage. In the case of multithreading and
> AppleScript, the more obvious fault is in AppleScript's inability to handle
> multithreading robustly.
The problem I have with it is that APE negates any semblance of memory
protection. When you are trying to keep many machines running correctly, you
need to have them not poking random (read: Totally unpredictable) values
into other applications. It's a hardline attitude, but I'm a sysadmin, it's
what I'm paid for.
I really hate having to be draconian about configuration management, but I
also have to be able to troubleshoot without having to try and track down
which one of n hacks *could* be causing the problem or having to jog
configurations and reboot just to see if (random framework) is the issue.
For example, you have a problem that when three apps are running at the same
time, one crashes. (this happens). Now, add, oh, say, 3 haxies into that
mix. That's a day of troubleshooting. Easily. Especially when you know that
Unsanity's first through fifth answer has a 99% chance of being "Not our
fault, buh-bye".
I think that the old OS 9 theory of extensions needs to be more of a chant
for hack writers, and that they must assume all responsibility for any harm
their work causes. I know that when I started running MRTG on our core
switches and we had problems the same day with our network, the first action
taken was to shut down MRTG. Did I think that was the problem? No, but as
the odd man out in the network application situation, and the one doing the
most diddling with the switch, it was my job to ensure that my actions
weren't causing the problem in a previously stable network. (as it turns
out, it was another change that was causing the issue.)
Unsanity will always be the odd man out, and their canard of "we make for
better apps" may be great for the developer. But it's utter hell on
sysadmins, because we get all kinds of interactions that developers don't
see. Unfortunately, we have a TTL on a fix of about ten minutes before
people make with the yelling and the complaining, so we do the obvious.
Slash and burn the hacks. If the problem goes away, it's the hack's fault,
and the next step is to ban them. We then tell our peers, "If you see a, and
you have APE modules, burn them to the ground and sow salt on the soil" and
life will be good.
If Unsanity were to be more proactive with what their modules (at least the
ones they write) *do*, it would be a big help. Sysadmins are pretty techie
people, we aren't afraid of the grownup explanation. It would also make them
look a lot better if they came up with some troubleshooting tools for their
stuff, or a white paper or three on how to use Apple's tools for that. That
would help a *lot*. But their insistence that destabilizing machines is a
good thing wins them no points with my lot.
john
--
"Klingon multitasking systems do not support "time-sharing". When a
Klingon program wants to run, it challenges the scheduler in hand-to-hand
combat and owns the machine."
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden