Yep, if an operation takes out the system then the mirrored system will also die. They are in total lockstep so there is no protection of the application. It does give you near instant protection should the hardware or the hypervisor fails, but not if your app or OS should fail.
Serious question time: Is it possible for anyone who is against Microsoft on this issue to have a serious conversation about this, and not resort to accusations of astroturfing?
This is a discussion between adults (hopefully) and if you're interested in it being a discussion then lets leave the astroturfing comments out of this.
In any case, reference implementations are for filling in areas where the spec is vague so people know how to implement it for compatibility.
But you're still confusing the reference implementation with the specification. If I can't make a reasonable stab at implementing it from the specification myself, then the specification is near to worthless. And clearly if the ODF 1.1 spec is that vague it is close to useless as a spec. Sure, using a reference implementation to see how a few minor things have been implemented is OK, but to see how something as fundamental as spreadsheet formulas are implemented just means the spec sucks. Like I say, ODF 1.2 should be better.
Until there is a complete standard there is nothing to interoperate with...there are only non-standard implementations. So Microsoft loses either way - either they comply with the standard such that it is and get dinged for not interoperating with OpenOffice, or they comply with OpenOffice and will get dinged for not guessing how OpenOffice does it correctly. It's a lose lose situation for Microsoft, and the only way to solve it is to have a complete & specific standard.
OpenOffice is NOT a reference implementation of ODF 1.1. OpenOffice implements features that are not even specified in ODF 1.1 (for example: formulas). It cannot be a reference implementation of something that simply does not exist. ODF 1.2 should hopefully address this, but they will need to improve the language in the spec to make it less vague. Specifications are supposed to be specific (funny that).
So what you're saying is Microsoft shouldn't follow the standard?
And further to that, are you suggesting that all it takes is to look at a few spreadsheets and reverse engineer them. How many would they have to look at to get all the scenarios? 100? 1000? 10,000? Somehow I don't think that's an option unless all you want to do is sums.
Because the format hasn't been finalised as a standard. How are you supposed to conform to a standard that isn't final? Once it's final, then you can conform, until then you can conform to what you think the standard might be.
If there is no definition in the spec, then a "reference implementation" cannot exist. The reference implementation follows on from the spec. Anything you do that isn't in the spec is called guesswork.
If you had to reverse engineer it from the OpenOffice implementation, myy guess is that Microsoft is rightly worried about code taint from it's developers reading open source code.
Second, they didn't comply with the letter of the spec, both failing to implement it properly and going out of their way to not implement features they already had working code for and ignoring both reference implementations.
That's the problem - the spec is too vague to be implemented properly. Because the spec doesn't spell things out in a specific way, it's impossible to implement in a consistent way - it's open to interpretation. The problem isn't Microsoft, the problem is the spec. ODF 1.2 should fix this.
Oooh, this is by far my favorite, that's why I saved it for last. If you're to the point where you're seriously considering disabling solitaire, this reveals a number of things about the organization:
1) The I.T. staff and/or managers are unapologetic control freaks and perhaps even proud of it. 2) You don't trust your employees to actually be productive on their own. 3) Your hiring standards are probably pretty low. 4) You have unrealistic expectations of employee efficiency. 5) Morale must really be in the toilet already. 6) It's solitaire for fuck's sake, possibly the most boring game ever devised. If your employees are playing it instead of whatever they should be doing, that means they have no motivation to work, which means management should be the ones to get their lunchtime games taken away, not the employees.
So what if it was an application that carried malware that you were blocking? Solitaire is a particularly silly example, but is representative of any application. It doesn't take much imagination to come up with an application that you might legitimately want to block. But you seem to be having such a good time, don't let me stop you...
Unfortunately few people in the *nix world seem to grasp that LDAP is just a protocol (that's the P bit of the acronym). It's just a standard way of accessing directories - which is what Active Directory is (as is OpenLDAP etc etc). LDAP means nothing as a reference to a directory - OpenLDAP might in your case. So what you meant to say was "directories (that are accessible via LDAP) have been around for years". Whether they do everything the particular implemention of Active Directory does is up for question - some may, some may not. It depends on implementation...
Ever wonder how all these other people can get it working, and you can't? Every thought it might not be the technology, it might be you? Just asking...
In Windows you need 1, one, uno, system image. Multiple user directories, and a DHCP server (plus Active Directory) and everything will work just like it is supposed to. Of course you need to change your way of thinking to accept this possibility.
You need one, that's right, one, system image that is either replicated and maintained on all the systems or is used to netboot the clients. The image contains all the companies approved and installed applications. This is a HUGE benefit to the IT department as they only have to test and deploy one image at a time. That is great 1990's thinking there. Times have changed, and smart Windows admins are changing with it. What we do now in the Windows world is a thin image (base OS, Antivirus, Office probably) that is deployed to the local hard disk, and then virtualise applications into their own separate environments, and deliver them dynamically based on the user group membership. This is a huge benefit to the IT department as they maintain an image that is stripped down, and they don't have to rebuild their image every time a patch for any one of the applications comes out. Applications just work, and the great news is that we don't worry about app to app conflicts, or whether an app will do something to the OS - they're all virtualised so they just can't. Realistically a "mega" image is more work, not less. I encourage my clients to get to a single thin image, and then apply applications dynamically on top.
Oh yeah, you want to deploy it with netboot (PXE)? Not a problem. We've been doing that for years as well.
If this is done right, all the configuration is in the user's home ditrectory, probably shared on the network, and the rest of the system is a standard image. That means any user can use any computer and have their system where they want it. You know that in Windows, the user part of the registry is stored as part of the users profile right? And you also know that there is such a thing as roaming profiles. Which combined together leads to three things: 1. All the configuration is in the users profile directory, which is better than being in their home directory cause it means it's not polluting their home directory 2. The configuration is shared on the network 3. The rest of the system is a standard image
How about that? Windows provides exactly the infrastructure you just talked about, and I don't even really care whether configuration is stored in the registry or in the filesystem (for example favourites are just.url files stored in the profile, and they roam as well).
So really, the crucial part of your comment is "If this is done right". Same on *nix & Windows. And it's not hard to do on Windows.
Us POW's as you affectionately call us have been doing lots of smart stuff for years. You *nix guys might be surprised what you can learn...
Microsoft has had something like this occur regularly enough
So when was the last time a bug this severe was found? I'm pretty sure it's well over a year, so it's not like this is "regular". All operating systems regularly have security holes, some are of course more severe. One's like this don't come along very often at all these days.
You're aware that LDAP is a protocol right (that's the P in LDAP), and that AD is more than just an implementation of a directory service access protocol? AD provides more than LDAP services (e.g. Group Policy etc etc), but uses LDAP to provide a standard API to talk to the AD services.
Sounds from the summary at least (hey, it's slashdot, I haven't read the article) that it's similar in some ways to the service profiling in Vista. The service profiling means that the dev looked at what the service needed to do to be able to run and gave it only those permissions, restricting the damage it could do if it were compromised. This seems to extend that to give the kernel the intelligence to baseline the services itself, and then restrict activity when the baseline activity changes.
you write the software once and can sell a billion copies with no overhead costs to you.
Well not quite. The overhead cost to you is the cost of developing the first copy. That may be quite significant, which is why commercial software companies want to recover the cost of that first copy in every copy they sell, regardless of the fact that the marginal cost of the software is close to zero.
Which bit of automated tool, and not aimed at replacing administrative expertise did you miss? Yeah, cause it's a tool it's looking for things that you tell it to look for, but the point is that once you start dealing with more than say 10 servers you're getting to the point where manually looking through the logs of every server doesn't scale. An automated tool can look for the common stuff, and let you know when it happens. Then when there are other problems (which could be picked up by other components of the tool - say a process not running, a file not existing in a directory, a file existing and having been there too long all sorts of other things) you can look through the logs manually if you need to. And then configure your monitoring system to pick up that the next time it happens - and across all your systems. eventually you build up a good body of knowledge that means the tool does the boring bits of your job for you - it detects when they are problems, you figure out the why (the bit that actually takes intelligence). I don't know about you, maybe you enjoy reading logs when you don't have to.
Well it's not aimed at replacing administrative expertise, it's aimed at replacing repetitive tasks that don't need to have an admin do them. Why waste your time grepping through logs if you can have your system do so and tell you when there's an issue? That way you use your expertise for what you need it for - and all those boring tasks get done automatically. I don't know about you, but I hate reading log files if I don't have to...in a GUI or at a command line.
Slashdot Mirror
Yep, if an operation takes out the system then the mirrored system will also die. They are in total lockstep so there is no protection of the application. It does give you near instant protection should the hardware or the hypervisor fails, but not if your app or OS should fail.
Serious question time: Is it possible for anyone who is against Microsoft on this issue to have a serious conversation about this, and not resort to accusations of astroturfing?
This is a discussion between adults (hopefully) and if you're interested in it being a discussion then lets leave the astroturfing comments out of this.
In any case, reference implementations are for filling in areas where the spec is vague so people know how to implement it for compatibility.
But you're still confusing the reference implementation with the specification. If I can't make a reasonable stab at implementing it from the specification myself, then the specification is near to worthless. And clearly if the ODF 1.1 spec is that vague it is close to useless as a spec. Sure, using a reference implementation to see how a few minor things have been implemented is OK, but to see how something as fundamental as spreadsheet formulas are implemented just means the spec sucks. Like I say, ODF 1.2 should be better.
Until there is a complete standard there is nothing to interoperate with...there are only non-standard implementations. So Microsoft loses either way - either they comply with the standard such that it is and get dinged for not interoperating with OpenOffice, or they comply with OpenOffice and will get dinged for not guessing how OpenOffice does it correctly. It's a lose lose situation for Microsoft, and the only way to solve it is to have a complete & specific standard.
I refer you to this comment because I'm too lazy to type something myself, and they've said it far better than I could: http://it.slashdot.org/comments.pl?sid=1239895&cid=28033047
What, you mean Netscape? Or Microsoft?
OpenOffice is NOT a reference implementation of ODF 1.1. OpenOffice implements features that are not even specified in ODF 1.1 (for example: formulas). It cannot be a reference implementation of something that simply does not exist. ODF 1.2 should hopefully address this, but they will need to improve the language in the spec to make it less vague. Specifications are supposed to be specific (funny that).
So what you're saying is Microsoft shouldn't follow the standard?
And further to that, are you suggesting that all it takes is to look at a few spreadsheets and reverse engineer them. How many would they have to look at to get all the scenarios? 100? 1000? 10,000? Somehow I don't think that's an option unless all you want to do is sums.
Best comment on this article. You've nailed it exactly.
Because the format hasn't been finalised as a standard. How are you supposed to conform to a standard that isn't final? Once it's final, then you can conform, until then you can conform to what you think the standard might be.
If there is no definition in the spec, then a "reference implementation" cannot exist. The reference implementation follows on from the spec. Anything you do that isn't in the spec is called guesswork.
If you had to reverse engineer it from the OpenOffice implementation, myy guess is that Microsoft is rightly worried about code taint from it's developers reading open source code.
Second, they didn't comply with the letter of the spec, both failing to implement it properly and going out of their way to not implement features they already had working code for and ignoring both reference implementations.
That's the problem - the spec is too vague to be implemented properly. Because the spec doesn't spell things out in a specific way, it's impossible to implement in a consistent way - it's open to interpretation. The problem isn't Microsoft, the problem is the spec. ODF 1.2 should fix this.
Oooh, this is by far my favorite, that's why I saved it for last. If you're to the point where you're seriously considering disabling solitaire, this reveals a number of things about the organization:
1) The I.T. staff and/or managers are unapologetic control freaks and perhaps even proud of it.
2) You don't trust your employees to actually be productive on their own.
3) Your hiring standards are probably pretty low.
4) You have unrealistic expectations of employee efficiency.
5) Morale must really be in the toilet already.
6) It's solitaire for fuck's sake, possibly the most boring game ever devised. If your employees are playing it instead of whatever they should be doing, that means they have no motivation to work, which means management should be the ones to get their lunchtime games taken away, not the employees.
So what if it was an application that carried malware that you were blocking? Solitaire is a particularly silly example, but is representative of any application. It doesn't take much imagination to come up with an application that you might legitimately want to block. But you seem to be having such a good time, don't let me stop you...
Unfortunately few people in the *nix world seem to grasp that LDAP is just a protocol (that's the P bit of the acronym). It's just a standard way of accessing directories - which is what Active Directory is (as is OpenLDAP etc etc). LDAP means nothing as a reference to a directory - OpenLDAP might in your case. So what you meant to say was "directories (that are accessible via LDAP) have been around for years". Whether they do everything the particular implemention of Active Directory does is up for question - some may, some may not. It depends on implementation...
Ever wonder how all these other people can get it working, and you can't? Every thought it might not be the technology, it might be you? Just asking...
In Windows you need 1, one, uno, system image. Multiple user directories, and a DHCP server (plus Active Directory) and everything will work just like it is supposed to. Of course you need to change your way of thinking to accept this possibility.
You need one, that's right, one, system image that is either replicated and maintained on all the systems or is used to netboot the clients. The image contains all the companies approved and installed applications. This is a HUGE benefit to the IT department as they only have to test and deploy one image at a time.
That is great 1990's thinking there. Times have changed, and smart Windows admins are changing with it. What we do now in the Windows world is a thin image (base OS, Antivirus, Office probably) that is deployed to the local hard disk, and then virtualise applications into their own separate environments, and deliver them dynamically based on the user group membership. This is a huge benefit to the IT department as they maintain an image that is stripped down, and they don't have to rebuild their image every time a patch for any one of the applications comes out. Applications just work, and the great news is that we don't worry about app to app conflicts, or whether an app will do something to the OS - they're all virtualised so they just can't. Realistically a "mega" image is more work, not less. I encourage my clients to get to a single thin image, and then apply applications dynamically on top.
Oh yeah, you want to deploy it with netboot (PXE)? Not a problem. We've been doing that for years as well.
If this is done right, all the configuration is in the user's home ditrectory, probably shared on the network, and the rest of the system is a standard image. That means any user can use any computer and have their system where they want it.
You know that in Windows, the user part of the registry is stored as part of the users profile right? And you also know that there is such a thing as roaming profiles. Which combined together leads to three things:
1. All the configuration is in the users profile directory, which is better than being in their home directory cause it means it's not polluting their home directory
2. The configuration is shared on the network
3. The rest of the system is a standard image
How about that? Windows provides exactly the infrastructure you just talked about, and I don't even really care whether configuration is stored in the registry or in the filesystem (for example favourites are just .url files stored in the profile, and they roam as well).
So really, the crucial part of your comment is "If this is done right". Same on *nix & Windows. And it's not hard to do on Windows.
Us POW's as you affectionately call us have been doing lots of smart stuff for years. You *nix guys might be surprised what you can learn...
Microsoft has had something like this occur regularly enough
So when was the last time a bug this severe was found? I'm pretty sure it's well over a year, so it's not like this is "regular". All operating systems regularly have security holes, some are of course more severe. One's like this don't come along very often at all these days.
You're aware that LDAP is a protocol right (that's the P in LDAP), and that AD is more than just an implementation of a directory service access protocol? AD provides more than LDAP services (e.g. Group Policy etc etc), but uses LDAP to provide a standard API to talk to the AD services.
Sounds from the summary at least (hey, it's slashdot, I haven't read the article) that it's similar in some ways to the service profiling in Vista. The service profiling means that the dev looked at what the service needed to do to be able to run and gave it only those permissions, restricting the damage it could do if it were compromised. This seems to extend that to give the kernel the intelligence to baseline the services itself, and then restrict activity when the baseline activity changes.
Well not quite. The overhead cost to you is the cost of developing the first copy. That may be quite significant, which is why commercial software companies want to recover the cost of that first copy in every copy they sell, regardless of the fact that the marginal cost of the software is close to zero.
Not any more: http://www.microsoft.com/systemcenter/mobile/default.mspx
So now making a document format a standard is anticompetitive? I'm confused. Wasn't it anticompetitive when the document format was closed?
Which bit of automated tool, and not aimed at replacing administrative expertise did you miss? Yeah, cause it's a tool it's looking for things that you tell it to look for, but the point is that once you start dealing with more than say 10 servers you're getting to the point where manually looking through the logs of every server doesn't scale. An automated tool can look for the common stuff, and let you know when it happens. Then when there are other problems (which could be picked up by other components of the tool - say a process not running, a file not existing in a directory, a file existing and having been there too long all sorts of other things) you can look through the logs manually if you need to. And then configure your monitoring system to pick up that the next time it happens - and across all your systems. eventually you build up a good body of knowledge that means the tool does the boring bits of your job for you - it detects when they are problems, you figure out the why (the bit that actually takes intelligence). I don't know about you, maybe you enjoy reading logs when you don't have to.
Well it's not aimed at replacing administrative expertise, it's aimed at replacing repetitive tasks that don't need to have an admin do them. Why waste your time grepping through logs if you can have your system do so and tell you when there's an issue? That way you use your expertise for what you need it for - and all those boring tasks get done automatically. I don't know about you, but I hate reading log files if I don't have to...in a GUI or at a command line.