On Tue, Jun 15, 2010 at 7:33 PM, Steven Peck <[email protected]> wrote: > So as I have said. Pretty much every issue has not been patch > related. But having called MS we had help identifying the actual > cause of the issue.
That doesn't make Windows better at package management; it just means if you pay for Microsoft's help, they'll help you. I would hope so! :) > I guess your support experience has not been as good as mine. With > only one or two exceptions in years, every issue has been the result > of configuration or third party software, not an MS fix. We may have been talking about different things. I wasn't talking about MSFT helping with patch management issues only, but rather, in general. If I call about a "known issue", they just point to the requisite MSKB article and say the "behavior is by design" and won't be fixed. If you mean *just* patch management issues, okay. That's my fault for getting off-topic. Sorry. To get back on topic: "you can pay Microsoft for help investigating possible patch issues" != "Windows has good package management technology". > You consistently post this viewpoint. It has become expected. I believe you consistently post your viewpoint, too. :) I don't consider that a bad thing. If you didn't believe what you were saying, you wouldn't be worth listening to. :) >> (Plus, if you really want the company-to-blame thing, that's >> available for Linux, too. Novell or Red Hat or Canonical will happily >> take your money and let you blame them all you want.) > > You keep saying blame. If you pay Redhat you get the same time of > service you get from MS. A person will help you diagnose and > troubleshoot the issue. But you have to be using their stuff and they > will help you see if it was their fix / update or something specific > to your system / install. This is the exact same advantage of having > quality paid vendor support. Um. Isn't that what I was saying? That if you pay X for support, they'll help you with their stuff, regardless of whether X = Microsoft or X = Canonical? :) >> When I compare Linux and Windows, I often say that it's not that one >> *can't* do this or that on Windows, but that it costs more. Same >> thing here. More stuff in this area is built-in, and what's there is >> more sophisticated in functionality and is easier to maintain. All >> that adds up to lower costs. >> > No it doesn't. It only costs 'less' if you fail to value your time > and the time it has taken to acquire your expertise. And all the time I've spent acquiring knowledge on Microsoft products? Courses I've taken, manuals I've read, books I've bought and studied, support calls, paid consultants, lab environments? That did not have a cost? I have yet to find anything in the IT world that didn't require learning, planning, and integration effort. This is the same everywhere, Linux or Microsoft, payware or freeware or Open Source. Yah, any monkey can sit down with an install CD and click GUI buttons and get something that boots. That's true of Linux these days, too (for better or worse). That doesn't translate into a stable IT infrastructure on any platform. > The 'you can fix it yourself' part is a myth. Interesting. You say "you can fix it yourself" is a myth, while I say the commercial support angle is a myth. Perhaps we are both figments of our own imaginations? ;-) Understand that you don't need to be a software developer to fix simple issues. Anecdote: Roughly eight years ago, I was tasked with getting an ISDN link working with Linux. It turns out the provider was using a ridiculously long SPID, and the Linux ISDN stack was truncating it, causing things to fail. I understood almost nothing in the source code, but I understood enough to know what "#define MAX_SPID_LENGTH = 8" meant in the header, and to bump that number up. Compare that to, say, MAX_PATH on Windows. For whatever reason, it appears that will be 255 forever, and we're just stuck with it. > Cost comes from somewhere, paying a dev, learning it > yourself, the kindness of random strangers.... Absolutely. I just maintain that those costs are higher for Windows. >> To the best of my knowledge, with MSI, I can't do half of what I can >> do with RPM (see my other posts in this thread for examples). > > Our desktop guys have been packaging the adobe updates, the java > updates, the whatever weird in house custom app updates we have for > years now. I shall ask them what they use. For straight MS updates, > MS SCCM, select what you want and fire away. For distributing Microsoft updates, we have WSUS now. It sucks up a ton of RAM for even 100 PCs, it needs a SQL database server and a web application, it's full of cryptic stuff that isn't documented anywhere. On Linux, all you need is a file share. Again, costs. We also do things like custom MSI deployments for Java updates. But wasn't your argument that most people can't do that stuff, and those that can are expensive? Cost, again. Further: What about any of the several other things I talked about? How can you verify the integrity of every package on the system? How can you find out what package owns a given DLL? How can you make sure removing a package won't break dependencies in another package? These perhaps aren't what you consider "patch management", but the ability to do this kind of thing is a *huge* boon when you're trying to figure out why something isn't working or if a software update has gone wrong. (Which avoids having to pay someone else to help us.) -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
