Oh man. WMI is evil! How do you get it through firewalls? The amount of configuration just to get it working is really quite silly. Hint to Microsoft - next time you setup a distributed monitoring tool that needs to go over firewalls, don't use DCOM.
Then again, this is the company that decided that a good idea would be to add binary blobs into their Exchange RPC mail protocol, which is what, by default, MAPI is using. This leads to articles on troubleshooting like this one. Ugh. And yet, MAPI is often seen as more secure that IMAP. Sorry, I digress. WMI is evil, that's all you need to know. Just use SNMP.
An IP address DOES identify a computer- but not the way the judge thinks. My IP address identifies my router, which in turn owns 5 to 6 computers. With the wireless open, it could refer to the whole neighborhood, for all I know/care. They need to revise, an IP address identifies a NETWORK, but not neccessarily conclusively any particular computer.
Only if you are using NAT. Then it identifies the piece of equipment that is doing the network address translation - but of course at that point if you can find the IP address that it is translating to then you've identified the network end point. Of course, that's quite unlikely to occur, so the judge's point essentially remains the same.
I know! This anonymous clan of slack-jawed troglodytes has cost me the game, and yet if I were to have them killed, I would be the one to go to jail. That's gamocracy for you.
I'm a bit confused as to why it's Microsoft getting knocked on the head here. Sure, SQL Server 2000 might not be the best choice, but how are we to know what actually caused the issues? You could write poorly written code anywhere, and outages could well be caused by hardware failure and poor failover planning. To blame it all on the.NET framework seems a bit odd to me, without knowing what was causing all the problems.
Of course, I'm not a big fan of SQL Server databases for huge mission-critical applications (multi-version consistency in TempDB version stores, anyone?).
I know! And those colour screens just wouldn't work under specific conditions determined by the manufacturer, they made you wait for 5 minutes while it gave you an important public announcement, and there were at least a dozen variations that were incompatible with each other. Oh wait. There weren't, silly me.
Not only will you not feel anxious, but you'll have your genes removed from the global gene pool, which I for one am thankful for. A win-win situation really!
Saying that Amazon and Google stifle innovation because they sit as an intermediary between creators and audiences is a bit like saying the Roman Catholic church stifles religion because a priest sits between the Creator and his followers.
It really depends on the type of service desk you work at. If you are in a service desk that cares about metrics like time taken on a call, then get out. Now. If you are on a service desk that values root cause analysis and real problem resolution, then stick around and try to get promoted up levels. Most of these service desks have a lot of high value components that are important enough that they'll appreciate you figuring out the actual problem and advising or implementing solutions that prevent further issues in the future.
I work on a service desk for a multi-national corporation supporting one of their software products. However, this software interacts with a lot of cool technologies that make life interesting - directory services, databases, packet analysis, network discovery, etc. There are enough components to the product itself that problems reported can be very interesting to troubleshoot, and I've learned a lot on the job. It also gives me the opportunity to read up on technologies I've never heard of before, or that I'm interested in. I'm fairly certain I'm seen as a reasonably valuable member of the team, so I get a lot of job satisfaction from what I do.
The rule of thumb, IMO, is that if you aren't learning anything new, then you're stagnating and it's probably time to get out of the job.
But before you do, listen in the above poster so you can learn the lingo.
Until you can optimize the ROI of a value added function by providing excellence in service provisioning within the ITIL framework, you really haven't lived.
I've yet to hear about an 18-year-old European who is capable of diagnosing her/himself. I'm pretty impressed with what this girl did and the system that made it possibe.
The system that made it possible was the microscope, which was invented in The Netherlands. The Netherlends is located in Northwestern Europe. It's also, somewhat ironically, the country you use to justify your largely narrow-minded comments. Just so you know.
Slashdot Mirror
Oh man. WMI is evil! How do you get it through firewalls? The amount of configuration just to get it working is really quite silly. Hint to Microsoft - next time you setup a distributed monitoring tool that needs to go over firewalls, don't use DCOM.
Then again, this is the company that decided that a good idea would be to add binary blobs into their Exchange RPC mail protocol, which is what, by default, MAPI is using. This leads to articles on troubleshooting like this one. Ugh. And yet, MAPI is often seen as more secure that IMAP. Sorry, I digress. WMI is evil, that's all you need to know. Just use SNMP.
Only if you are using NAT. Then it identifies the piece of equipment that is doing the network address translation - but of course at that point if you can find the IP address that it is translating to then you've identified the network end point. Of course, that's quite unlikely to occur, so the judge's point essentially remains the same.
I'm curious if anyone's used EMC's Smarts Service Assurance Manager (SAM)? Or nLayers' (also owned by EMC) Application Discovery Manager (ADM)?
I know! This anonymous clan of slack-jawed troglodytes has cost me the game, and yet if I were to have them killed, I would be the one to go to jail. That's gamocracy for you.
I'm a bit confused as to why it's Microsoft getting knocked on the head here. Sure, SQL Server 2000 might not be the best choice, but how are we to know what actually caused the issues? You could write poorly written code anywhere, and outages could well be caused by hardware failure and poor failover planning. To blame it all on the .NET framework seems a bit odd to me, without knowing what was causing all the problems.
Of course, I'm not a big fan of SQL Server databases for huge mission-critical applications (multi-version consistency in TempDB version stores, anyone?).
I know! And those colour screens just wouldn't work under specific conditions determined by the manufacturer, they made you wait for 5 minutes while it gave you an important public announcement, and there were at least a dozen variations that were incompatible with each other. Oh wait. There weren't, silly me.
Actually, my gain. I don't need anything Blu-Ray offers, so I don't have to fork over a fair amount of money to get "quality" I don't need.
If you want to complain about a War on Quality, then perhaps you should be focussing on the artificial deficiencies built into Blu-Ray?
Pink Panther, Pink Panther 2, Marley and Me, the 1952 version of the Day the Earth Stood Still. All movies I have no intention of watching. Lucky me!
Did I mention that I don't own a Blu-Ray player? Nor will I ever, because I Just Don't Give A Crap about that much "quality".
My password is all asterisks, you insensitive clod!
Not only will you not feel anxious, but you'll have your genes removed from the global gene pool, which I for one am thankful for. A win-win situation really!
I know, ridiculous. That's what the woman is for.
Indeed you can not. I guess you'll all ever know.
Saying that Amazon and Google stifle innovation because they sit as an intermediary between creators and audiences is a bit like saying the Roman Catholic church stifles religion because a priest sits between the Creator and his followers.
It really depends on the type of service desk you work at. If you are in a service desk that cares about metrics like time taken on a call, then get out. Now. If you are on a service desk that values root cause analysis and real problem resolution, then stick around and try to get promoted up levels. Most of these service desks have a lot of high value components that are important enough that they'll appreciate you figuring out the actual problem and advising or implementing solutions that prevent further issues in the future.
I work on a service desk for a multi-national corporation supporting one of their software products. However, this software interacts with a lot of cool technologies that make life interesting - directory services, databases, packet analysis, network discovery, etc. There are enough components to the product itself that problems reported can be very interesting to troubleshoot, and I've learned a lot on the job. It also gives me the opportunity to read up on technologies I've never heard of before, or that I'm interested in. I'm fairly certain I'm seen as a reasonably valuable member of the team, so I get a lot of job satisfaction from what I do.
The rule of thumb, IMO, is that if you aren't learning anything new, then you're stagnating and it's probably time to get out of the job.
But before you do, listen in the above poster so you can learn the lingo.
Until you can optimize the ROI of a value added function by providing excellence in service provisioning within the ITIL framework, you really haven't lived.
As an Australian looking at this with an outside perspective, it seems to me that they managed to piss off most of the population of the U.S.
That's got to be a new low. :-)
At least it tries to given an answer on the swallow question.
And if you agree to disagree?
The system that made it possible was the microscope, which was invented in The Netherlands. The Netherlends is located in Northwestern Europe. It's also, somewhat ironically, the country you use to justify your largely narrow-minded comments. Just so you know.
Plenty of good games for Linux. Not really the kernel's domain though, dufus.
I know :-) I both strengthened your point and explained the issue to maz2331, who seems to have missed the point entirely.
Uh... you just got modded as informative. Genius.
Can I run MS Office?
Yes.
Can I have a webcam conversation?
Yes.
Can I play games?
Yes.
Or he could buy commodity hardware and install a VM.
Eric Allman might well agree.