At 08:29 PM 8/18/03 -0400, you wrote:
Seems like this is a lot more work than fixing things correctly. But you seem fairly interested in going to a lot of effort to have what I'd consider a fairly poorly designed solution.
Seems like we agree to disagree. :)
"Ask me the questions, bridge-keeper. I'm not afraid."*
I don't consider what I've done in poor design, or bad design, or whatever your opinion is. I consider what I've done to be a "patch" over inconsistent environments derived from working as an experienced systems programmer in the trenches. I like to keep my hands as far away as possible from sticky proprietary traps that companies lay open for you to get caught in. This allows me the opportunity to move freely when times change. Working at the level of process scripting is an acceptable practice in the industry. It allows the highest level of abstraction in case things change.
I'm not wearing a developers shoes, I'm a systems programmer for a large collection of networked machines. I'm not trying to create a software release for other sites to use. I'm offering solutions that others in the same situation may find useful.
We've used this system for well over a year now without a hitch. It's secure, reliable, easily modifiable. If I had to take what I've done in scripting, and migrate it to C or C++, it would be much more complex and harder to deal with in-house, and every time we needed to make a change we'd have to recompile, with library dependencies both at compile and run-time. If I want to pull "kinit" and "aklog" out and pop in MSKlog or GSSKlog no problem. If I want to change my logging, or deny the user logon, no problem. It's really a Swiss army knife approach.
I just don't think you "get it" because you probably don't wear the same shoes as I do. You are trying to create a software application for a specific problem. I'm trying to setup and manage the entire user process environment when they logon. And, it needs to be changeable at the drop of a hat.
I do value your opinion. I'm sorry if I seem to be such a jerk. I got a bit annoyed when I found out that the Sun Solaris kinit supported stdin, and I had a knee-jerk reaction. Some have already replied via personal email to my query on the OpenAFS list. They don't want to get caught up in the debate, and I understand. But they've been positive to my stance (unprovable of course because I'll refrain from divulging their names at their request out of professional courtesy).
"Please, please! This is supposed to be a happy occasion! Let's not bicker and argue about who killed who!"*
I don't want to get on your bad side. The kerb stuff from MIT is good. I've been an advocate many times. I have this sneaking suspicion that you've already committed to your changes to the Windows prompter code and you can't turn back even if you wanted to because of entrenched use. That's fine. What I've got works and if I keep having to add in a line with every new version of kinit, then no problem. We actually don't upgrade the client that much anyway. The 1.3.1 version is the first upgrade we've done since 1.2.4. I just thought it would be nice for those who may copy this system of mine to not have to modify kinit for stdin, that's all. I'm a competent system programmer. I'll get by just fine. I'll just end up whinning a bit. :(
Thanks for your support!
Rodney
* Monty Python's Holy Grail.
_______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
