Microsoft eOpen Site Down For Nearly a Week 133
mauriceh writes "Since Monday Dec. 7, the Microsoft eOpen license website has been mostly 'Down for Maintenance.' When we do not see this message, we still do not see most of the normal functionality. As this is Microsoft's main channel for managing and installing licenses for products such as Server, and for open license products for business, this makes the company effectively 'closed for business!' Attempts to connect to https://eopen.microsoft.com/ are redirected (after a bad certificate warning) to https://www.microsoft.com/licensing/servicecenter/sitemaintenance.html. For those who wish to activate Microsoft Business Solutions software need to obtain Software Registration keys, and these also can not be obtained, as the site http://www.microsoft.com/BusinessSolutions/MBSRegistration does not resolve; instead one gets a Microsoft Search page. Telephone calls to their support numbers for the licensing program yield either busy signals, or a message saying one should 'call back later.'"
Re:Time for some free software zealotry... (Score:5, Insightful)
Proprietary software is not the problem. Proprietary software whose functionality requires a given service to be infallible is the problem.
Re:Time for some free software zealotry... (Score:1, Insightful)
In this case, yes. But a 100% open service whose functionality required a given (open) server to work wouldn't be affected: just change the server and you're back.
Re:global conspiracy (Score:4, Insightful)
Hardware distribution is an entirely different and far more complicated matter, you need sufficient manufacturing capacity, combined with sufficient supply of the source components... Any of these failing will cause significant delays, a single tiny part being in short supply can scupper your entire production run.
Software on the other hand, once you have one copy distributing more is trivial.
Re:Time for some free software zealotry... (Score:5, Insightful)
I meant that the problem is not caused by the fact that the software is proprietary. Yes, if it were open, it'd be easier to fix, but the original problem of failing services would still exist.
Take these failures as a warning! (Score:2, Insightful)
Greetings and Salutations.
This is the last of a number of massive infrastructure failures in the past few months. The issues with Gmail, T-Mobile, SwissDisk, etc and this should be a warning that the computing infrastructure is becoming baroquely fragile. Fragility and unreliability in the basic tools necessary to keep a business running are hard to deal with in good economic times. With the current, VERY stressed situation, it could easily cause marginal businesses to go toes up, throwing many more people out of work, and having a ripple effect that pushes hundreds of other support businesses closer to the edge.
I would suggest that, instead of the creeping featuritis that has been so popular with software for the past decade that the focus should change towards making the foundations more secure, and, less likely to fail. Among other things, this WOULD require stopping this insane focus on having software "phone home" all the time, and, fail if it is unable to contact the appropriate servers. Another big step would be to focus back on quality of software rather than flashy features. There really should be no reason today for a piece of software to be exploited by a simple buffer overflow. The principles of excellent programming have been known and studied for 50 or more years now, and, should be fairly well understood. You MIGHT have heard of this fellow by the name of Knuth...he has said a thoughtful thing or two on the subject, and, it might well be worth reading some of his writings.
More later
Dave Mundt
Re:Time for some free software zealotry... (Score:3, Insightful)
No, because I'd expect the server to have some sort of data storage, which could still get corrupted. Perhaps a major flaw was discovered in the server software itself. The problem is obviously something big, that simply looking elsewhere won't fix.
Re:Maybe it was running Vista... (Score:5, Insightful)
Re:Time for some free software zealotry... (Score:3, Insightful)
In this case, yes. But a 100% open service whose functionality required a given (open) server to work wouldn't be affected: just change the server and you're back.
Depends on the nature of the service. If it involves large amounts of data and wasn't already set up to replicate the data to a backup system, bringing things back up (whether or not you've got the source code) might be very difficult simply because people don't just want the service itself, but they also want the state embodied by the service. After all, if you had a NAS box with lots of data on it, you wouldn't be able to bring the service provided by it back up just by plugging a new NAS box in. You'd still need to copy the files across, and if the old NAS is down and you've not been backing up properly, you're in trouble. The OS on the NAS boxes (or on the client systems) doesn't matter at all for that fundamental truth.
Services aren't software. Open source software can still form a closed ecosystem (a lot of Linux desktops feel rather that way) and an open ecosystem need not use any OSS. Of course, best of all is when there is an open ecosystem (so people can use anything they want) and OSS is full part of that ecosystem; the open software acts as an insurance against people trying to close things off, and sets a baseline that the closed providers have to do better than.
Re:nitpick (Score:2, Insightful)
Separating like bad velcro (Score:5, Insightful)
The new one not working is a separate issue.
This is madness. You can't say "Oh well they were always going to shut down on this date" without an implied "the new server will be active". It's not separate in any way, the old server going down and the new server coming up were linked events, the new server being a precondition for the old to vanish.
Unless you were saying it makes any kind of sense to adhere to deadlines and damn the customers?
M$ Business as Usual (Score:2, Insightful)