Kwyjibo wrote:
>
>"Murderous Speeding Drunken Distracted Driver (Hector Goldstein)"
><drunk_and_distracted@[EMAIL PROTECTED]
> wrote in message
>news:lisdo31i2rpket4c45nv0qp25d8vpimkcj@[EMAIL PROTECTED]
>> Kwyjibo wrote:
>>>
>>>"Murderous Speeding Drunken Distracted Driver (Hector Goldstein)"
>>><drunk_and_distracted@[EMAIL PROTECTED]
> wrote in message
>>>news:f9qdo3lhjm1n5gau1t7bgdmi37iflr240m@[EMAIL PROTECTED]
>>>> Kwyjibo wrote:
>>>>>
>>>>>"Murderous Speeding Drunken Distracted Driver (Hector Goldstein)"
>>>>><drunk_and_distracted@[EMAIL PROTECTED]
> wrote in message
>>>>>news:h6odo3d4gsin079gkpops3ojd9ggv7421r@[EMAIL PROTECTED]
>>>>>> clifto wrote:
>>>>>>>Murderous Speeding Drunken Distracted Driver (Hector Goldstein)
wrote:
>>>>>>>> Kwyjibo wrote:
>>>>>>>>>> Yup the lack of cryptic error messages went as soon as I
switched
>>>>>>>>>> to
>>>>>>>>>> Linux.
>>>>>>>>>
>>>>>>>>>Very true. Linux is a lot worse than Windows when it comes to
>>>>>>>>>cryptic
>>>>>>>>>error
>>>>>>>>>messages.
>>>>>>>>
>>>>>>>> That's only the case if you're incompetent.
>>>>>>>
>>>>>>>No, he's right. Windows exists to prevent you from seeing error
>>>>>>>messages,
>>>>>>>no matter what awful thing is happening to your system that might
be
>>>>>>>prevented if you saw an error message.
>>>>>>
>>>>>> That must explain we're seeing roughly a 15% failure in the Windows
>>>>>> Management Instrumentation interface in the 2500
>>>>>> Winblows eXtra CraPpy installs my team sup****ts.
>>>>>>
>>>>>
>>>>>Your team can't be doing a very good job if you can't diagnose a WMI
>>>>>problem
>>>>>when you have 375 examples to investigate.
>>>>
>>>> LMAO. My team's primary purpose is software development, and we've
got
>>>> higher priorities than dealing Microsoft's 15% failure rate.
>>>
>>>Ahh. So it's Microsoft's failure that you can't/won't investigate a
>>>problem.........
>>
>> I'm glad you're not on my team; you're a complete moron.
>>
>> I work for a company with roughly 35,000 employees.
>
>That explains your ability to keep your incompetence hidden.
Odd, the supervisors, clients, colleagues, professors, and other
associates who've seen my work over the years have offered quite the
opposite description of my skill sets. You, on the other hand, have
offered exactly 0 reasons to believe your opinion of me is worth
anything.
>> The instability of
>> those Windows boxes has a direct impact on those 35,000 employees. The
>> rebooting piece cured that, which resulted in a significant number of
>> calls to our overworked call center. The re****ting piece of that
>> project affects ONE person out of those 35,000 employees, namely, the
>> one that requested the rebooting piece in the first place. As we have
>> other issues that the particular business owner wants deployed, he
>> didn't want us to spend too much time on it. The next task I went to
>> reduced our call volume by 15%, which is FAR more im****tant than that
>> re****ting piece that only one person will see. Furthermore, the
>> business owner has other ways of getting the same information that the
>> WMI piece is supposed to re****t, it's just that it's not "automagical"
>> like we were shooting for.
>
>So why whinge about it then?
I merely re****ted an incident rate based on the failure of the WMI
subsystem over a reasonable quantity of installs; you're the one
that's been doing the whining (or whinge?) Too damned retarded to run
the spell checker on your Microsoft box there, whineyboi? LMAO.
>> While resolving this issue is on the list, it's at the very bottom (a
>> couple of tasks up from locating Jimmy Hoffa), and it appears the only
>> person who thinks it's an issue is you.
>
>You're the one who brought it up as absolute evidence that MS produces a
>**** OS. It's since turned out not to be the case - It's your own team's
>indifference that has caused you to jump to this conclusion.
There's a difference between being indifferent to a situation that has
a minor impact on one person, and realizing there are other more
pressing needs that have a direct influence on larger quantities of
employees and/or customers. The person who would receive the
information for the re****ting could get it through other mechanisms,
but he doesn't seem to feel it's im****tant enough to pursue, since the
im****tant numbers (sup****t center calls) have already dropped
significantly. He wants those numbers to continue dropping, so he
wants me on other tasks.
And if that's not enough, marketing is wanting me to get involved in
at least one, if not two customer facing projects.
>> Since you don't know the
>> cir***stances, your perspective is of no value.
>
>And since you are unwilling to investigate a problem, your use of that
>problem as proof that MS makes **** OS's is nonsensical.
Seems like you have difficulty with distingui****ng between "unwilling
to investigate the problem" and "having higher priority issues." That
you like making mountains out of molehills isn't my incompetence; it's
yours.
>>>> It's in
>>>> the task list, but toward the bottom.
>>>>
>>>>>> Those failures result in NO errors being returned, when there are
>>>>>> problems with the system. Interestingly enough, in researching the
>>>>>> problem to try to fix it, I see a number of solutions posted by
>>>>>> "microsoft guys" (some MVPs, others actual employees), yet in our
>>>>>> cases none of those solutions work.
>>>>>
>>>>>So you and your team are not capable of diagnosing a problem and
coming
>>>>>up
>>>>>with your own solution?
>>>>
>>>> We'll get it, when we have our other priorities taken care of. The
>>>> main piece, which is to reboot the terminals, works without issue;
>>>
>>>Apart from totally unneccessary downtime.........
>>
>> Uh, the downtime is gone, dumb ass. Been reading long?
>>
>
>Yeah? You can reboot a terminal with no downtime? That's a new one on
>me........
That "downtime" is negligible compared to what we used to face. The
reboot occurs at our convenience, at a time when there is the least
possibility of interfering with customer service. Before the reboot
piece, we'd have occasions where the terminals would freeze up,
sometimes while tendering credit card transactions. Controlling the
necessary reboot for the Doze boxes has a significant reduction on the
number of credit card mistendering issues that have to be resolved.
>>>> we
>>>> just provide re****ting with 15% inaccuracy. The business owner is
fine
>>>> with that, as he's got much higher things on his wish list, too. His
>>>> main concern was the stability of the terminals, which was cured by
>>>> the rebooting piece.
>>>
>>>That's *not* a cure. The fact that you consider it to be a 'cure' is
even
>>>more cause for concern over your abilities.
>>
>> The person who requested the rebooting component be deployed had other
>> tasks in addition to the rebooting task. The rebooting piece has been
>> out for eight months, and as of yet, he's never mentioned the
>> re****ting component. Of course, we've had plenty of discussions about
>> other things he'd like implemented, and he's extremely pleased with
>> what he's getting.
>>
>
>Which is all irrelevant to your claim that rebooting is a cure. It's not.
Depends on your metrics. I don't think it's a cure, either, but it's
all we've got to work with. It immediately addressed a need, and we've
got other needs that must be addressed before I can come back and deal
with this WMI piece. I want a handle on it for other reasons as well,
but I've got two major projects to get out before I'm going to have
the time to research these WMI failures to my satisfaction.
>>>> The re****ting piece is hardly "mission critical,"
>>>> unlike the basic operation of the point of service terminal itself.
>>>>
>>>>>> Freakin' useless, and if the decision would have been mine (I
wasn't
>>>>>> on the team at specification time) I would NOT have pushed that
>>>>>> flaming pile of garbage into our sites. One of the tasks I've had
to
>>>>>> perform was to write a service to make the terminals reboot
>>>>>> automatically at a given time each day, as they don't seem to be
able
>>>>>> to operate for more than 72 hours without breaking.
>>>>>
>>>>>Again - That just shows a lack of investigative and problem solving
>>>>>ability.
>>>>
>>>> No, it shows you don't have a clue as to what my task list is like.
>>>
>>>You had time to write a windows service to make the server reboot as a
>>>bandaid to a problem, but don't have time to investigate the cause?
>>
>> We've got an extremely large project list, and we have to affect
>> solutions to improve customer service. Automated rebooting of the
>> terminals on a daily basis allowed for a very quick and dirty band-aid
>> to reduce downtime.
>
>A band-aid huh? I thought you said you 'cured' the problem?
Yeah. The problem is that for some reason the POS terminals freeze up
after being in operation for around 72 hours. Unfortunately those
freezes are usually discovered while a customer is being serviced, and
sometimes when there are a line of customers. The "band-aid" of
rebooting the terminals in off-peak hours reduces help desk calls, and
expedites customer service.
>> Much easier to spend a couple of hours putting the
>> band-aid on than it is to spend any length of time researching the
>> issue, as most likely it's going to be an OS or application issue, and
>> most of the applications on these particular terminals are not our
>> apps, so we couldn't fix them if we were able to identify the problem.
>>
>>>Tw comments on that idiocy:
>>>1. Windows doesn't grind to a halt every 72 hours by itself. Look for
>>>****y
>>>applications (probably the ones you wrote) as the culprit.
>>
>> These particular terminals don't run our software; our software runs
>> on the server(s) at each site, and they aren't having problems. It's
>> the vendor's code on the terminals that are the problem.
>
>So you lied about it being a Windows/MS problem.
Actually, I don't know exactly where the problem is; I wasn't told to
find out where the problem was. I was told to stop the problem from
happening, and to do so using as little of my time as possible. In
that regard, I delivered on this project in spades.
>> As we don't
>> have the vendor's source, there isn't much we can do about fixing the
>> problem; we have to band aid it.
>>
>>>2. Anyone with half a brain would not write a 'windows service' to
>>>routinely
>>>reboot a server. Windows comes with a task scheduler and a 'shutdown'
>>>command as standard.
>>
>> How much do you know about the windows scheduling subsystem? Evidently
>> not much.
>
>Enough to know that the Win32_ScheduledJob object is quite easy to
interract
>with. It even has a 'create' method - funny about that. Oh - that's
right.
We discounted use of Win32_ScheduledJob when this was encountered from
MSDN:
"The problem we have here is that Windows actually has two different –
and, sadly, not fully-compatible – APIs (Application Programming
Interfaces) used to manage scheduled tasks."
>You clowns can't get WMI to work.
That's your assumption, not mine. It'll work, when I'm given the time
to research the issue. Unfortunately the only one who seems to think
it's of any significance isn't an associate of the company. Says far
more about you than anyone else.
>> Sometime when you've got a free moment, google up
>> programmatic additions to the task schedule list.
>
>No thanks. Been doing it for years.
Sorry for you. This is my first experience with WMI; I'm not impressed
in the least, but it's par for the course for Mickeysoft's offerings.
You've been doing this for years? What a bleak domain to work in.
Tasks I'm assigned are MUCH more varied than that.
>> Furthermore, as you
>> have no clue as to our environment (or anything else for that matter),
>> you're not aware of other restrictions we have.
>
>Ahh yes. The old 'other restrictions' defence...........
Lame.
>So which is it? It was too hard for you, or you're not allowed to? You
seem
>very indecisive as to why you couldn't just use the standard Windows
tools.
What part of "other priorities" is beyond your comprehension?
>>>> For that matter, it's evident you don't have a clue, period.
>>>
>>>I don't have a clue, but you were willing to waste your employers time
and
>>>money writing a windows service that's not required?
>>
>> I reiterate: For that matter, it's evident you don't have a clue,
>> period.
>
>From someone who can't programmatically interact with the Windows
Scheduler?
>ROFL.
Errant assumption; you're the one asserting that I can't interact with
the scheduler, but then you don't have enough information to
understand the situation.
>>>>>I'm surprised you would openly admit your incompetence in an open
forum
>>>>>such
>>>>>as usenet. If I was that piss-poor at my job I would keep it to
myself
>>>>>and
>>>>>probably be looking for emplyment elsewhere.
>>>>
>>>> Unlike you, I've not made that admission.
>>>
>>>You have. A number of times, Mr 'windows service'..........
>>
>> No, you're making errant assumptions, and projecting those failures
>> onto me.
>
>Not at all. I'm basing my perception of you on the information you have
>provided about your abilities. (they appear to be sadly lacking BTW)
Sorry about your perceptual issues, but those aren't my problems.
Those who've seen my work offer MUCH brighter evaluations. Since they
pay me well, and continue to provide nice raises and promotions,
you'll pardon me if I don't put any stock in your evaluation of the
situation.
--
Sarcasm is my sword
Apathy is my ****eld
|
