"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.
> 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?
> 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.
> 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.
>>> 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........
>>> 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.
>>> 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?
> 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.
> 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.
You clowns can't get WMI to work.
> Sometime when you've got a free moment, google up
> programmatic additions to the task schedule list.
No thanks. Been doing it for years.
> 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...........
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.
>
>>> 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.
>>>>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)
> That's not my problem.
>
>>> By the way, if I'm incompetent, why has my income doubled in the four
>>> years I've been with this employer?
>>
>>Not hard to get a pay rise when you are on 5000 per year.
>
> LMAO. I'm WELL above the state average, but do have fun with that. =))
>
Since your pay doubled?
>>> Why am I about to receive yet
>>> another promotion which will bring with it another 50% increase in
>>> pay?
>>>
>>>>> Ah well, as long as idiots keep specking Microsoft crap, I'll have a
>>>>> job.
>>>>
>>>>Until someone someone notices your inability to solve fairly basic
>>>>problems.......
>>>>
>>>>> Can't say that with Linux; those boxes are "fire and forget."
>>>>
>>>>Just the way you like them, huh? No thinking involved.
>>>
>>> My primary job purpose is to develop software,
>>
>>Which is probably the cause of your servers ****ing themselves every
few
>>days.
>
> Er, it's not the servers, moron, it's the terminals.
>
> How long have you been utilizing the english language as your primary
> mechanism for communication?
Quite a bit longer than you have been trying to be a programmer,
apparently.
--
Kwyj.
|
