Unfortunately the Novell/MS IP sharing deal doesn't extend past Novell and it's direct customers. So even if Miguel and the rest of the Mono team are covered, Debian, Ubuntu and Red Hat may still be found to violate MS patents if they distribute this (assuming Moonlight utilizes MS patents).
Re:This is a FAILURE of the OPEN SOURCE Community
on
Ubuntu Servers Hacked
·
· Score: 1
Well yeah, you can say it's a "bug" in the process. But that's not something a code review is going to help with, which was the AC's contention.
Ubuntu's packages are all signed, so unless you agreed to install unsigned packages (there should have been a warning telling you that was what you were doing), you should be fine. From my experience, if the package signature has a problem (package doesn't match the signature, meaning it's been modified) apt will refuse to install it, and bail out with an error message saying that signature verification failed. So you should be fine. It seems all the hackers were doing was using the servers at drones to attack someone else, probably didn't even need root access.
Re:This is a FAILURE of the OPEN SOURCE Community
on
Ubuntu Servers Hacked
·
· Score: 1
Who said it was a bug? It could be as easy as someone password sniffing on a remote network saw a user log in to the Ubuntu server's FTP service. Once they had a username and password, logging onto the box and running a spam/DoS script against other servers is easy. It's not a bug, it's just an insecure method of accessing a box. Kind of like putting a huge lock on your front door, then leaving the key under the mat.
Because of this, when you release your derived version of OpenOffice, with your own version of ODF, Sun's pledge won't apply to you, even for the parts that were covered under the work you derived from, because Sun did not participate in that versions development. And what I am saying is that Sun cannot sue you for patent infringement based solely on the parts of your fork that implement the ODF 1.2 or earlier specifications. Do you disagree?
Now, if 1.3 happens to be an extension to 1.2 or earlier, and it can be shown that the 1.3 is physically seperate from the 1.2 implementation that would be one thing, but you can't just say that the 1.2 functionality is still covered in a new version. Any patents needed to implement version 1.2 of the spec are covered by the patent agreement. This hold regardless of any other specification an application implements, be it ODF 1.3 or OOXML. Any over-lap in functionality between 1.2 and any other specification is irrelevant. OpenOffice.org implements many specifications, not all of which Sun has granted a patent pledge on, but implementing those doesn't invalidate Sun's grant over ODF 1.2 implementations, just like implementation of an ODF 1.3 specification won't invalidate Sun's grant over ODF 1.2 implementations.
Further, the reciprocity requirements mentioned are also GPL killers, since they add additional restrictions. The Open Invention Network is based on this principle, do you feel that GPL'd code can't use OIN patents for the same reason?
How about we take another example. Suppose someone decides to fork the specification and create their own version, forked from GPL'd code that deals with the "official" version. Sun's patent pledge doesn't cover them because they did not participate in the development of the forked version. That's a clear GPL no-no, which requires that any patents be licensed to anyone, and for those rights to be transferrable to derived works. Again, just because a fork implements additional functionality or specifications, doesn't invalidate the patent pledge given to the parts of the application that implements the ODF 1.2 specification. It is not unusual for a GPL'd work to include a patent grant over the code in that work, and naturally that grant doesn't cover any additions or changes made to that GPL'd work by third parties. Anyone can implement ODF 1.2 + their own extensions, and Sun's patent pledge will apply to the code needed to implement ODF 1.2, but not their extensions. This is in no way a GPL "no-no".
Let's break it down.
(1) Sun Irrevocably covenants that (2) Subject to the reciprocity requirements described below (3) it will not seek to enforce any of its enforceable U.S. or foreign patents against any implementation of the Open Document Format v1.0 Specification (4) or of any subsquent version thereof in which development Sun participates to the point of incurring an obligation
What this is clearly saying is that the 1.0 version is fixed in stone. It cannot be revoked (1), unless you don't reciprocate, in which case it can be revoked (2).
This sentance alone would indicate that only version 1.0 is covered. So version 1.1 or greater would not be covered by the pledge. Version 1.2 is due out this fall, and Sun has participated as much as ever, so it will be covered by the pledge.
Thus, they added the section (4) "or of any subsequent version thereof", but that is modified by the "in which development Sun participates". Meaning that if Sun doesn't participate, then the patent grant doesn't apply to that version. Any of it. By forcing the patent license to be tied to versions, they made certain that the patent grant applies to versions. Wrong, the patent grant will still apply to any code needed to implement the last version of the specification Sun participated in. If the new version contains parts of that last specification, those parts are still covered, it doesn't matter if they are also a part of a specification that Sun did not grant patent coverage on.
The pledge is applied to a version of the specification. if Sun doesn't participate in that version, the patent pledge will not apply. That's pretty easy to read. I thought so too, but then you keep implying that if ever a version is released that Sun doesn't participate in, then Sun will retroactively revoke (which is can't) its pledge for code used to implement all previous version.
Sun irrevocably covenants that, subject solely to the reciprocity requirement described below, it will not seek to enforce any of its enforceable U.S. or foreign patents against any implementation of the Open Document Format for Office Applications (OpenDocument) v1.0 Specification, or of any subsequent version thereof ("OpenDocument Implementation") in which development Sun participates to the point of incurring an obligation Now, if Sun drops out of OASIS, and then OASIS creates an ODF 1.3 specification, then only the parts of that specification that are not a part of the ODF 1.2 specification would be open to a lawsuit by Sun. Implementing ODF 1.2 functionality, and also 1.3 functionality, doesn't remove the patent pledge issued for the 1.2 implementation. So you are wrong, only new functionality or changed functionality in later versions where Sun does not participate would require a separate patent license or pledge.
Um, no, the pledge doesn't explicitly *remove* anything, it only explicitly *grants* the use of patents for a specific version of the specification, and any version thereof that Sun has participation in forming. Since the grant covers *any* patent needed to implement the specification, instead of naming specific patents covered by the pledge, this was Sun's way of limiting the number of patents they covered.
It should be worth noting, too, that only participation is required. Technically, a new version of the spec can be made that include items covered by other Sun patents not covered in the original spec, and those patents would be automatically covered by Sun's patent pledge, even if Sun themselves did not want those features in the new version of the spec, or even voted against their inclusion. I think making participation, rather that approval, the requirement shows Sun putting a lot of trust into the community.
Sun's patent pledge is limited to their participation because they don't want people to add anything that may infringe on patents _not_ covered by their initial pledge. So either they can steer new versions of the standard away from infringing those patents, or they can choose to add those patents to their pledge.
To fix your GPL analogy, releasing something under the GPL requires a perpetual patent license to only the code you released under the GPL. If someone else adds new code to that GPL'd work, and that new code infringes on a patent that the old code did not, your patent grant doesn't not automatically extend to that new code.
I download the updates directly from the site, every minor revision +
Oh, and I have it on 6 different machines that appear to come from one IP, 12 from another I think you cancel yourself out. Unless you are the sole user of > 18 different machines.
Yes, and Java can run anywhere you have a JVM. "write once, run anywhere" was a marketing phrase, certainly nobody believed it would run on any system anywhere without a VM. You can implement the JVM on virtually any hardware and any OS, just because a platform doesn't have a JVM for it yet doesn't mean a Java application you "write once" won't run there once they do have a JVM.
_Should_ never touch and _can_ never touch are two very different things. But, since you bring it up, I _can_ touch all of those things on my machine if I wanted to. Many Linux users, and especially admins, _do_ touch those things on a fairly regular basis to get the best performance possible out of their system.
But let's say for the sake of argument you are right, what media file you can play, when, where, and how, shouldn't be something an OS kernel should be limiting. An OS's kernel should not be in the business of policing copyright, should it?
It makes me wonder what Microsoft's security qualifications really are for a signed kernel level driver. I believe they use the Verisign security test: If the check clears the bank, the code is secure.
Malicious to whom? This systems seems designed more to prevent the installation of kernel-mode drivers that would allow the circumvention of things like DRM. I guess it could stop the installation of rootkits too, but there are other ways to stop them. It's funny (to me at least) that there are things that Windows can stop even an Administrator from doing on their own machine.
Perhaps AMD will use it as a way to tell people: You want to switch to Linux? Well, we sponsor Novells Build Service, so we are the best choice. Unless you want open source drivers. Or working drivers for that matter.
Well, one thing to consider is this -- how different are other OSes like Linux? First off, this is part of the reason binary driver use is discouraged. Secondly, this only seems to be a way around Vista's requirement of using signed drivers, something Linux doesn't even try for.
From the article (emphasis mine):
One product, WatchGuard's Linux AV tool, caught fewer than 6 percent of the viruses sent to it. Obviously WatchGuard only caught 4% (or maybe 0%), and they were just trying not to embarrass them too much, you insensitive clod.
It's besides the point, but I don't think we do. Systems thought to be non-functional in the past, such as the appendix, have long since been found to be otherwise. I'm a male, I have nipples, tell me what their function is. I also have a tail bone, why? I also have hairy arms and legs, but not enough hair to actually protect me from the elements, what good is that?
The point of Irreducible Complexity is to attempt to prove that there are systems which could not have had a function at an evolutionary step before some critical point, and therefore the existence of those systems are incompatible with the neodarwinian theory. While it is an exceedingly difficult thing to prove, it is at least strongly suggestive, and in my mind puts the burden of proof on the neodarwinists to offer evidence that such systems in fact evolve "blindly" rather than with some "end in view," so to speak. So Irreducibly Complexity puts forward a hypothesis, but no means to test if it is accurate or not, which happens to predict the exact same outcomes as Evolution theory predicts, then requires Evolution theory to disprove it, basically prove a negative? Gee, Its amazing that it's not taken seriously by the scientific community.
Ok, you're getting confused by the terms, so lets try this:
A quantity of water 'A' is exactly 1 liter at 20 degrees C.
The quantity of water 'A' is 'X' grams.
Now, if you heat 'A' up to 40 degrees C, it will still be 'X' grams If you cool 'A' to 10 degrees C, it will still be 'X' grams.
At 40 degrees C, 'A' will be more than 1 liter because water is less dense at higher temperature.
Now, density = mass / volume or, re-arranged, volume = mass / density.
So, since the mass of 'A' stays the same, when the density decreases, the volume increases. Going the opposite way, at 10 degrees C, the density of water increases, so the volume decreases.
Notice that in this example, we measured 'A' once, and used that same quantity of water throughout, that is why the mass/weight didn't change. In your thinking, you taking a different quantity of water at different temperatures, which is why the same volume had different mass/weight.
So, in conclusion, the mass of a quantity of water doesn't change with temperature, only it's volume changes with temperature. Did that help any?
Slashdot Mirror
Yes, but they never said that Silverlight won't also be a major cluster-fuck from a security view.
Unfortunately the Novell/MS IP sharing deal doesn't extend past Novell and it's direct customers. So even if Miguel and the rest of the Mono team are covered, Debian, Ubuntu and Red Hat may still be found to violate MS patents if they distribute this (assuming Moonlight utilizes MS patents).
Well yeah, you can say it's a "bug" in the process. But that's not something a code review is going to help with, which was the AC's contention.
Ubuntu's packages are all signed, so unless you agreed to install unsigned packages (there should have been a warning telling you that was what you were doing), you should be fine. From my experience, if the package signature has a problem (package doesn't match the signature, meaning it's been modified) apt will refuse to install it, and bail out with an error message saying that signature verification failed. So you should be fine. It seems all the hackers were doing was using the servers at drones to attack someone else, probably didn't even need root access.
Who said it was a bug? It could be as easy as someone password sniffing on a remote network saw a user log in to the Ubuntu server's FTP service. Once they had a username and password, logging onto the box and running a spam/DoS script against other servers is easy. It's not a bug, it's just an insecure method of accessing a box. Kind of like putting a huge lock on your front door, then leaving the key under the mat.
(1) Sun Irrevocably covenants that
(2) Subject to the reciprocity requirements described below
(3) it will not seek to enforce any of its enforceable U.S. or foreign patents against any implementation of the Open Document Format v1.0 Specification
(4) or of any subsquent version thereof in which development Sun participates to the point of incurring an obligation
What this is clearly saying is that the 1.0 version is fixed in stone. It cannot be revoked (1), unless you don't reciprocate, in which case it can be revoked (2).
This sentance alone would indicate that only version 1.0 is covered. So version 1.1 or greater would not be covered by the pledge. Version 1.2 is due out this fall, and Sun has participated as much as ever, so it will be covered by the pledge. Thus, they added the section (4) "or of any subsequent version thereof", but that is modified by the "in which development Sun participates". Meaning that if Sun doesn't participate, then the patent grant doesn't apply to that version. Any of it. By forcing the patent license to be tied to versions, they made certain that the patent grant applies to versions. Wrong, the patent grant will still apply to any code needed to implement the last version of the specification Sun participated in. If the new version contains parts of that last specification, those parts are still covered, it doesn't matter if they are also a part of a specification that Sun did not grant patent coverage on. The pledge is applied to a version of the specification. if Sun doesn't participate in that version, the patent pledge will not apply. That's pretty easy to read. I thought so too, but then you keep implying that if ever a version is released that Sun doesn't participate in, then Sun will retroactively revoke (which is can't) its pledge for code used to implement all previous version.
Um, no, the pledge doesn't explicitly *remove* anything, it only explicitly *grants* the use of patents for a specific version of the specification, and any version thereof that Sun has participation in forming. Since the grant covers *any* patent needed to implement the specification, instead of naming specific patents covered by the pledge, this was Sun's way of limiting the number of patents they covered.
It should be worth noting, too, that only participation is required. Technically, a new version of the spec can be made that include items covered by other Sun patents not covered in the original spec, and those patents would be automatically covered by Sun's patent pledge, even if Sun themselves did not want those features in the new version of the spec, or even voted against their inclusion. I think making participation, rather that approval, the requirement shows Sun putting a lot of trust into the community.
Sun's patent pledge is limited to their participation because they don't want people to add anything that may infringe on patents _not_ covered by their initial pledge. So either they can steer new versions of the standard away from infringing those patents, or they can choose to add those patents to their pledge.
To fix your GPL analogy, releasing something under the GPL requires a perpetual patent license to only the code you released under the GPL. If someone else adds new code to that GPL'd work, and that new code infringes on a patent that the old code did not, your patent grant doesn't not automatically extend to that new code.
Unless you don't have KDE installed.
I was wondering that myself, just about every distro I think comes with Firefox installed, are those being counted?
It's ok, I've installed it on multiple PC's from the same download, so I cancel you out.
I'd fire them.
Heck, that solution is even cross-platform!
Right, and that's true in any language, isn't it?
Hint: It's the programmer.
Yes, and Java can run anywhere you have a JVM. "write once, run anywhere" was a marketing phrase, certainly nobody believed it would run on any system anywhere without a VM. You can implement the JVM on virtually any hardware and any OS, just because a platform doesn't have a JVM for it yet doesn't mean a Java application you "write once" won't run there once they do have a JVM.
_Should_ never touch and _can_ never touch are two very different things. But, since you bring it up, I _can_ touch all of those things on my machine if I wanted to. Many Linux users, and especially admins, _do_ touch those things on a fairly regular basis to get the best performance possible out of their system.
But let's say for the sake of argument you are right, what media file you can play, when, where, and how, shouldn't be something an OS kernel should be limiting. An OS's kernel should not be in the business of policing copyright, should it?
Malicious to whom? This systems seems designed more to prevent the installation of kernel-mode drivers that would allow the circumvention of things like DRM. I guess it could stop the installation of rootkits too, but there are other ways to stop them. It's funny (to me at least) that there are things that Windows can stop even an Administrator from doing on their own machine.
Ok, you're getting confused by the terms, so lets try this:
A quantity of water 'A' is exactly 1 liter at 20 degrees C.
The quantity of water 'A' is 'X' grams.
Now, if you heat 'A' up to 40 degrees C, it will still be 'X' grams
If you cool 'A' to 10 degrees C, it will still be 'X' grams.
At 40 degrees C, 'A' will be more than 1 liter because water is less dense at higher temperature.
Now, density = mass / volume or, re-arranged, volume = mass / density.
So, since the mass of 'A' stays the same, when the density decreases, the volume increases.
Going the opposite way, at 10 degrees C, the density of water increases, so the volume decreases.
Notice that in this example, we measured 'A' once, and used that same quantity of water throughout, that is why the mass/weight didn't change. In your thinking, you taking a different quantity of water at different temperatures, which is why the same volume had different mass/weight.
So, in conclusion, the mass of a quantity of water doesn't change with temperature, only it's volume changes with temperature. Did that help any?