SOAP being an open and vendor-independent standard, this is a very predictable move by M$. I wonder, did M$ ever successfully implement support for an open standard?
This way of handling websites with expired or self-signed SSL certificates is bound to scare away a lot of inexperienced users, no matter how legitimate the website is.
And the ways used by other browsers will not scare people even if the site is illegitimate. Great security model!!
Could somebody enlighten me on why I need a license from Intel if I want to create an x86-compatible processor with my own design? I've always thought that you could only patent a particular implementation of an instruction, but not the instruction itself. Am I wrong? If I am, then isn't it a serious flaw in the patent system?
This was a laboratory demonstration only and the researchers say they need to bring up the efficiency.
There have been numerous such laboratory demonstrations on different ways to produce hydrogen easily. But the attempts to bring up efficiency are just what failed.
It is very much intuitive that human beings can't have free will unless the constituent particles themselves have free will. So, the formal proof of this is useful only for categorical and pedagogical purposes but not any practical purpose. The real question to be solved is whether human beings have any free will at all?
True interoperability comes only when all the parties involved respect open standards. And this is never possible with M$. If you are required to get a license/permission/assistance from M$ to achieve "interoperability", then that's not interoperability.
Setting aside the fact that your definition of "open standard" is nothing like any I can find out there:
2. The authority to specify updates, revisions and newer versions of the standard should be equally available to all implementors.
It is equally available. Suggest a revision, up-down vote of the ECMA folks in charge.
3. Implementors must not be needed to do anything with another implementor.
They're not. It's just easier to pick the brains of other implementors.
The OSI definition is far better, and ECMA 335 fits that bill.
My apologies for not being precise enough. I was not referring to the ECMA 335 specification. I was referring to MS.NET which is a superset of ECMA 335 with many MS-specific extensions.
The openness (or the lack of it) of MS.NET is more relevant than that of ECMA 335, because MS.NET is the de facto standard. What I mean is that most, if not all, developers who write.NET applications don't read the ECMA spec. Instead, they just visit MSDN and code for MS.NET. Ask any.NET developer in the IT market, the question - "How do you know the.NET spec? Through MSDN or through ECMA?", if you want to confirm.
FYI, Microsoft itself doesn't mention anywhere on its websites that "MS.NET is an implementation of ECMA 335 with the addition of MS-specific extensions". Instead it uses ambiguous words like "framework", "technology", etc.
Please be careful about what exactly you mean by using the word "technology". Are you referring to.NET or the specification it implements? Although MS.NET implements the ECMA specification correctly, it also introduces a number of MS.NET-specific extensions that are not part of the ECMA spec. Most, if not all, developers who write.NET applications don't read the ECMA spec. Instead, they just visit MSDN and code for MS.NET. Ask any.NET developer in the IT market, the question - "How do you know the.NET spec? Through MSDN or through ECMA?", if you want to confirm. This is bad for two reasons. Firstly, this code will be incompatible with other implementations of the spec unless those implementations are done with MS's help, like Mono. So, MS decides which implementations "work". Secondly, MS's documentation for MS.NET doesn't separate standard things from MS.NET-specific things. Worse still, developers are encouraged to use MS.NET-specific things without being told that they are MS.NET-specific.
So.NET may be solid, but only if all world uses MS.NET.
If Moonlight is working with MS to provide real inter-operability, I think that's a good thing.
Whether it's good or not is subjective, but this sort of "interoperability" doesn't make.NET an open standard.
For something to be an open standard, the following things are necessary:
1. The specification of the standard should be publicly available. There should not be any restrictions or agreements that have to be signed to get it.
2. The authority to specify updates, revisions and newer versions of the standard should be equally available to all implementors.
3. Implementors must not be needed to do anything with another implementor.
The very fact that M$'s help is necessary their development indicates that neither Mono nor Moonlight are open. If something is really open, an implementor must not have anything to do with another implementation.
Although the hardware-plus-software suite is Windows-specific, the hardware itself can be controlled by any OS (given the required documentation) to the same extent as Windows. So the hardware, and hence its documentation, is not inherently Windows-specific. But yeah, I do agree that it's theoretically _possible_ to write hardware documentation in a very Windows-specific way although I can't imagine anyone who would willingly do that.
A Winmodem is a hardware-plus-software suite for M$-windows whose modem-functionality is done in software and the hardware-part is just a ADC/DAC converter.
There is no such thing as OS-specific hardware documentation. The released documentation enables all interested OS-writers/driver-writers to write compatible software.
The rest of the patent is very general and unclear. But the claim no. 3 is specifically and clearly about a tree-view widget (not necessarily about file-management). Look at digikam, for example. As mentioned in that claim, I can select a directory from the tree-view widget in the left part of the software and the right part shows the photos in that directory.
I really was not looking for M$'s patents. I was searching for some filesystem concepts in google and came across this result. On checking it, I've found that it deserves to be posted on slashdot. And I really don't know about the alternative sites.
He believes that this move is based on a legitimate desire by Microsoft to foster collaborative development of Apache technologies that implement Microsoft standards.
If that's true, then we have a grave situation. M$ can make apache compatible with M$'s home-grown standards and then claim that the standards themselves are open standards. Since the percentage of IT people who mistake an open-source implementation as an open standard is almost 100%, M$ can even be very successful at this. Since the standards themselves are not open, all web servers, except Apache and M$-IIS, will soon die out. Finally M$ withdraws support for Apache and thus giving it a final blow. Now M$-IIS becomes the king. I know that I'm sounding like a conspiracy theorist. But we have seen enough instances of this Embrace-Extend-Extinguish policy.
Slashdot Mirror
SOAP being an open and vendor-independent standard, this is a very predictable move by M$. I wonder, did M$ ever successfully implement support for an open standard?
This way of handling websites with expired or self-signed SSL certificates is bound to scare away a lot of inexperienced users, no matter how legitimate the website is.
And the ways used by other browsers will not scare people even if the site is illegitimate. Great security model!!
It's busy trying to paint a picture that the whole problem is only with BIND, not with DNS protocol and in particular not with M$ DNS.
Could somebody enlighten me on why I need a license from Intel if I want to create an x86-compatible processor with my own design? I've always thought that you could only patent a particular implementation of an instruction, but not the instruction itself. Am I wrong? If I am, then isn't it a serious flaw in the patent system?
...then it can be thought as crossed alpha stage and entered beta stage.
This was a laboratory demonstration only and the researchers say they need to bring up the efficiency.
There have been numerous such laboratory demonstrations on different ways to produce hydrogen easily. But the attempts to bring up efficiency are just what failed.
It is very much intuitive that human beings can't have free will unless the constituent particles themselves have free will. So, the formal proof of this is useful only for categorical and pedagogical purposes but not any practical purpose. The real question to be solved is whether human beings have any free will at all?
to start stabbing pigs and eating meat
Humans didn't START eating meat. They always were.
instead of just plants
There was never a stage in human evolution which involved 100% herbivorous diet.
Humans at first only ate meat. Very soon, they started eating plants too. And much lately, some of them disliked meat and became vegetarians.
True interoperability comes only when all the parties involved respect open standards. And this is never possible with M$. If you are required to get a license/permission/assistance from M$ to achieve "interoperability", then that's not interoperability.
You can integrate any two OSs with minimal pain provided neither of them is made by M$.
Setting aside the fact that your definition of "open standard" is nothing like any I can find out there:
2. The authority to specify updates, revisions and newer versions of the standard should be equally available to all implementors.
It is equally available. Suggest a revision, up-down vote of the ECMA folks in charge.
3. Implementors must not be needed to do anything with another implementor.
They're not. It's just easier to pick the brains of other implementors.
The OSI definition is far better, and ECMA 335 fits that bill.
My apologies for not being precise enough. I was not referring to the ECMA 335 specification. I was referring to MS.NET which is a superset of ECMA 335 with many MS-specific extensions.
The openness (or the lack of it) of MS.NET is more relevant than that of ECMA 335, because MS.NET is the de facto standard. What I mean is that most, if not all, developers who write .NET applications don't read the ECMA spec. Instead, they just visit MSDN and code for MS.NET. Ask any .NET developer in the IT market, the question - "How do you know the .NET spec? Through MSDN or through ECMA?", if you want to confirm.
FYI, Microsoft itself doesn't mention anywhere on its websites that "MS.NET is an implementation of ECMA 335 with the addition of MS-specific extensions". Instead it uses ambiguous words like "framework", "technology", etc.
The real problem is that most people won't code for the ECMA spec or the Portable.NET spec. Instead, they code for MS.NET.
The technology is pretty solid.
Please be careful about what exactly you mean by using the word "technology". Are you referring to .NET or the specification it implements? Although MS .NET implements the ECMA specification correctly, it also introduces a number of MS.NET-specific extensions that are not part of the ECMA spec. Most, if not all, developers who write .NET applications don't read the ECMA spec. Instead, they just visit MSDN and code for MS .NET. Ask any .NET developer in the IT market, the question - "How do you know the .NET spec? Through MSDN or through ECMA?", if you want to confirm. This is bad for two reasons. Firstly, this code will be incompatible with other implementations of the spec unless those implementations are done with MS's help, like Mono. So, MS decides which implementations "work". Secondly, MS's documentation for MS.NET doesn't separate standard things from MS.NET-specific things. Worse still, developers are encouraged to use MS.NET-specific things without being told that they are MS.NET-specific.
So .NET may be solid, but only if all world uses MS.NET.
If Moonlight is working with MS to provide real inter-operability, I think that's a good thing.
Whether it's good or not is subjective, but this sort of "interoperability" doesn't make .NET an open standard.
1. The specification of the standard should be publicly available. There should not be any restrictions or agreements that have to be signed to get it.
2. The authority to specify updates, revisions and newer versions of the standard should be equally available to all implementors.
3. Implementors must not be needed to do anything with another implementor.
Mono and Moonlight clearly violate 2 and 3.
If M$ dictates the list of OSs which can have this "interoperability", who would want to be their slaves? Perhaps only people like you would.
The very fact that M$'s help is necessary their development indicates that neither Mono nor Moonlight are open. If something is really open, an implementor must not have anything to do with another implementation.
Although the hardware-plus-software suite is Windows-specific, the hardware itself can be controlled by any OS (given the required documentation) to the same extent as Windows. So the hardware, and hence its documentation, is not inherently Windows-specific. But yeah, I do agree that it's theoretically _possible_ to write hardware documentation in a very Windows-specific way although I can't imagine anyone who would willingly do that.
A Winmodem is a hardware-plus-software suite for M$-windows whose modem-functionality is done in software and the hardware-part is just a ADC/DAC converter.
There is no such thing as OS-specific hardware documentation. The released documentation enables all interested OS-writers/driver-writers to write compatible software.
Hmm... yes. I'm new to patent documents. And I made a mistake. But it's only a mistake out of ignorance on my part. I wasn't trolling deliberately.
The rest of the patent is very general and unclear. But the claim no. 3 is specifically and clearly about a tree-view widget (not necessarily about file-management). Look at digikam, for example. As mentioned in that claim, I can select a directory from the tree-view widget in the left part of the software and the right part shows the photos in that directory.
My guess is that the submitter owns the ad-infested site hosting the linked copy of the patent, because there's no other motivation for posting it.
This is shit! It happened to come first before all "other" ad-free sites when I was googling for an unrelated thing.
I really was not looking for M$'s patents. I was searching for some filesystem concepts in google and came across this result. On checking it, I've found that it deserves to be posted on slashdot. And I really don't know about the alternative sites.
He believes that this move is based on a legitimate desire by Microsoft to foster collaborative development of Apache technologies that implement Microsoft standards.
If that's true, then we have a grave situation. M$ can make apache compatible with M$'s home-grown standards and then claim that the standards themselves are open standards. Since the percentage of IT people who mistake an open-source implementation as an open standard is almost 100%, M$ can even be very successful at this. Since the standards themselves are not open, all web servers, except Apache and M$-IIS, will soon die out. Finally M$ withdraws support for Apache and thus giving it a final blow. Now M$-IIS becomes the king. I know that I'm sounding like a conspiracy theorist. But we have seen enough instances of this Embrace-Extend-Extinguish policy.
tested an old version of wine, or
tested CS in DirectX mode instead of OpenGL.