On Thu, 27 Jan 2011, Michael Ryder wrote: > Understanding what the tool is *specifically* doing and knowing what the > took is *supposed* to be doing are completely different. The first implies > reverse-engineering of the application's code, the second implies knowledge > of your systems.
in the context of the initial post about this subject (smit on AIX), this is not same distinction that you are making. smit is a GUI (including smitty that did a 'GUI' on a text-only console, including telatype if needed) for doing various administrative tasks, adding users, configuring networks, adminstering storage. one of the wonderful features of smit is the 'show me' button. This didn't go into how smit worked, but it showed you what the cli command would be to execute what you have selected in the GUI, complete with all the appropriate options. you could literally cut-n-past this to the command line and it would achieve the same results as hitting the 'apply' button on the GUI. this is the level of 'under the covers' that I (and I believe most of the others who have commented) are talking about. not debugging the C/perl/whatever GUI code itself, but instead wanting to know what the GUI was trying to do so that if the tool doesn't work you can track down the problem yourself. more than once, smit didn't work, but by grabbing the command line that it was trying to execute, doing a man for the command, and reading what each option that was selected was trying to do, I was then able to create the command line to do what I needed to get done (plus also usually understand what option in the GUI I selected that made things not work) > Saying it's the responsibility of the vendors... I am talking about > situations where you have purchased the software tool, purchased "extended > support" and can now lean on the vendor to respond within the terms of their > SLA. And you always have to have a plan B in case the vendor can't deliver > on their promises. we are not talking about trying to do hexdumps of Oracle to figure out why it's not working, for things like that you do have to wait for Oracle (and for some, this is one of the reasons why people would want to run PostgreSQL instead as it would give them tools to not have to wait for the vendor) David Lang > Mike > > http://www.lostinthedetails.com > > On Jan 27, 2011 9:22 PM, <[email protected]> wrote: > > On Thu, 27 Jan 2011, Michael Ryder wrote: > >> Yes, Atom, that's exactly what I meant. >> >> And no, Robert, I wouldn't be sitting on my hands wait... > In order to script your way around the problem, you have to be willing to go > under the covers enough to understand what is happening so that you can > script to get it done. > > From your initial post it sounded like you were saying that you saw no > reason to understand what was actually happening, "that is the > responsibility of the vendors". If that was what you were saying, there > would be no possible way for you to script around the problem as you would > have no way (and no intention) of understanding what the tool was trying to > do. > > David Lang > > > >> In my experience, at least in the last 5 years, the Windows tools I use > are >> all stable, all wo... > > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss > This list provided by the League of Professional System Administrators > http://lopsa.org/ > _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
