You only get that particular wizard if you know what codecs you are going to need before you need them. Otherwise Ubuntu will install the correct packages for you the first time you attempt to open a file that needs them, you don't even need to know the package name.
Customer gets WMV file from his kid. Customer double-clicks WMV file, or right-clicks and selects "Open with Movie Player" Ubuntu: This file requires additional codecs to play, would you like me to install them? Customer: Yes please (wait 1 minute) Ubuntu: All done, enjoy your movie! Customer happily watches their WMV.
The next day, Customer sends his Windows kid some awesome Theora file...
And what is the difference if it has users if it's sold? Coca Cola doesn't care if you pour their drinks down the toilet after you have paid for them. They simply care that you've paid for them.
Of course Coca Cola cares. People who drink their product are much more likely to buy more of their product than people who pour it down the toilet. This is even more important for Microsoft, because people who _use_ Windows are much more likely to but Office, Outlook, Exchange, SQL Server, and all the other products that Microsoft makes the bulk of their money from. Those people are also much more likely to buy the next version of Windows they put out, continuing the cycle. Someone who gets a Vista license with their new PC, but downgrades to XP, is far less likely to buy Office2007 than someone who keeps the Vista install. They're less likely to buy music from the Zune store that will only plan on Vista, so they are also less likely to buy a Zune.
So the point is, "sales" is good for PR, but "usage" is good for business.
Ah, thanks for the correction. You're right, this exploit is kind of trivial, since it requires the attacker already has complete access to a system. It just used BITS to bypass firewall restrictions.
It's kind of like saying that once a thief gets into a safe, it's easy for him to steal all your money.
Presumably even if you have Firefox whitelisted and a trojan uses it to download more malware, that malware can only be run with user permissions, not "System" permissions like BITS has. Therefore the amount of damage Firefox can do on a decently designed OS is limited to the damage a non-privileged user account can do, and no more.
Maybe, but being a Gnome user by choice, I don't see it as frightening as you do. However, someone running Gnome is much more likely to switch to KDE that someone running Windows, so you must admit it's still a better situation.
That's a consequence of library dependency, not the packaging system. Windows has the same problem, and it's less elegant solution created the famous DLL hell. The best solution is for library developers to maintain backwards compatibility as much as possible, and for application developers to not depend on new library features unless they are really necessary.
It would be nice of the language of the GPLv3 were phrased such that you are only dissallowed from distributing a work due to a patent license or similar agreement if that GPLv3 work requires such a license to be legally distributed. That way even if Microsoft makes a blanket patent license for all of Suse Linux, Novell could distribute GPLv3 software, even without the patent license extending to non-Novell customers, because the GPLv3 work itself does not require the license. That would protect Novell from the GPLv3, while still letting them hold Microsoft to the compatibility part of the agreement. Even better, the fact that they would be distributing GPLv3 software under the MS agreement, and MS allowing them to do so, would be an admission by both parties that the GPLv3 software contains no Microsoft IP. Otherwise, if Microsoft wants to claim that the GPLv3 software does contain their IP, they would have to tell Novell where it is, something they (like SCO) have not wanted to do. And if Microsoft is distributing copies of Novell, which I think they are, then would either have to legally disclaim any patented code or be themselves in violation of the GPLv3.
You can pass this suggestion on to whomever you're talking to at the FSF.
My favorite programming edit, JEdit, recenty started offering DEB packages. So when I put Ubuntu on a new computer, I downloaded the DEB directly from JEdit's website. No adding a repository, just a.deb file. I double click on it in nautilus, and it asks if I want to install it. I say "yes" and it tells me there are some dependencies not in the DEB package, but available in the Ubuntu repos, and asks if I want to download and install them too. Again, I say "yes", and it goes and does everything for me. When it's done, I've got JEdit installed, with menu items and everything. As far as I know, JEdit is maintaned by one guy, so this can't be all that difficult.
Ok, that makes more sense to me. I'll admit, I just assumed that the "covenant not to sue" specified specific products within the Suse distribution. I would be surprised if Microsoft would give Novell the IP equivalent of a blank check, allowing them to violate any Microsoft patents as long as it's packaged into Suse. But, I guess if their intent was to make Novell a pawn to kill off other distros, even at the expense of temporarily losing Windows licensees to Novell, it would make sense.
However, since Novell's official position is that there is nothing in Suse Linux that requires a patent license from Microsoft in the first place, and that it is only to make potential customers less worried about compatibility and possible legal action, then I suppose they could argue that it is not a violation of the GPLv3 at all. After all, the GPL specifically allows people to distribute GPL code with additional warranties and guarantees, why not with additional patent protection as well.
I think there was probably some expectation that they might install on these Dells Wine for those non-technical users who would assume that their windows programs will run on any Dell machine.
What happens if you are not included in a distribution (or just as badly, included but packaged wrong or out of date)? As there's a lot of confusion around what this means, it means you aren't apt-gettable by end users. Not in the repositories.
You offer the file for download directly from you. How do you do it in Windows?
That's OK if it's only one distro, but it quickly becomes annoying if it's several.
No it's not, there are about 4 packages you can make that will cover 99% of users: RPM, DEB, TGZ and source. Just configure your build script to make each one every time you build, it's a 1-time cost in effort for the author.
A package for Feisty isn't good enough. You need the last couple of versions as well, because not everybody upgrades at the same time. To do that you need a separate install of each version, and you need to build the package on each install, using multi-boots, or VMware, or chroots, or just relying on volunteers to fill in the gaps for you. So if there are 3 distros you want to support, each with 3 versions in the wild, that's 9 packages you need (therefore 9 independent OS installs).
Only if your program is written to require the latest and greatest versions of dependent libraries, otherwise if Feisty has a binary compatible version of your dependency, you don't need to create a new package. And your autopackage system will improve on this how? You can create a single package that works with multiple incompatible versions of dependent libraries?
Then you have to tell your users how to install it. Look at the complexity of the page you linked to. This is a light year away from "just download and install it yourself".
That is only because WineHQ offers a repository for easy updating. They could just offer the.deb file for you to "just download and install".
See, this is what I have problems with. It's the general design of the software distribution scheme that's bogus. It can never work reliably. It's like Microsoft announcing that Vista will only install software you got from Microsoft Download Center... nobody would accept that: it doesn't scale, MS aren't trusted to be impartial, etc. It wouldn't work for Microsoft, so why would it work for anybody else
Or, you can just download and install the RPM or DEB. Seriously, how can you not know this?
I warned that while people might find discrimination on the basis of license acceptable, and on the basis of manpower understandable, distros would at some point start discriminating against software for bad reasons. And then what do the authors of the affected software do?
Um, make a binary package of their software themselves, instead of relying on someone else to do the work for them?
They can't make their own repositories for every distro out there
You mean creating an RPM AND a DEB are too much work?
Oh wait, I see now. You created another packaging system that is incompatible with both DEB and RPM files, makes installing packages harder than RPM and DEB (4 steps as opposed to 2), doesn't integrate with the rest of the desktop environment, has no widespread support among software developers, and you're bitter than Ubuntu didn't see the value in it. Did I miss anything?
Um, WTF? If Windows doesn't include software I want, I download it and install in. For linux, it's probably in the distro's repository, so downloading and installing it is even easier. If it's not, then I'm back to where I am on Windows, download it and install it.
Now I doubt Ubuntu will setup a different repository for Dell installs, so Wine will likely be only an apt-get away. The announcement is just saying that Wine will not be in the default installation, for the logical reasons given.
But lets say you're right, and Ubuntu doesn't offer it for Dell installs, you just download it and install it yourself, it'll even handle downloading and installing any dependencies for you.
So the absolute worst case scenario here is that installing software in Ubuntu is as easy as installing software on Windows, but chances are it will be much much easier. Basically everything about your post was FUD, and not even intentional FUD, but ignorant FUD. From someone who claims to be a Linux developer (and a Wine developer too?), I can't fathom how you could not know this.
Java is no different here, if you write a Java program in Java 5, as long as you don't use any of the new features in Java 5, it can still be compiled by a Java 1.4 compiler.
What you are talking about is compiling it with Java 5, then trying to run it on Java 1.4. In that case, the Java 5 compiler generates a binary suitable for the Java 5 runtime, but not the Java 1.4 runtime. That is akin to compiling something against GTK 2.8, and complaining when it has problems linking to a GTK 2.4 library. There is a reason programs have dependencies on GTK 2.8 or higher you know.
Using Python as an example isn't a good comparison because it is compiled to the proper version of the interpreter each time it is run. You don't get version incompatibilities, you just get compilation errors. The same thing happens with Perl.
Maybe I will have to ask the FSF for clarification here, because you still haven't convinced me. In English "a" denotes a singular item not plural, so "a covered work" denotes a singular covered work, as opposed to "any covered works" which would denote a plurality of covered works.
Ok, read all three links, but still I think you're wrong.
The new GPL3 provision says that if you arrange to protect any party from patents regarding the software, that protection has to apply to everyone.
Again, that seems to only implicate code licensed under the GPLv3 that is covered by that patent protection. You don't have to give patent protection to all GPLv3 software, just the ones you claim contain your patent. So if Microsoft gives Novell patent protection on, using your example, MS Exchange protocols in Evolution, that doesn't mean they have to extend patent protection to the Linux kernel, or anything else not a part of or derived from Evolution. Now if Evolution were to change to the GPLv3 license, then either Microsoft would have to extend the patent protection to anyone using Evolution or a derivative thereof, or Novell could no longer distribute Evolution. Either way, it has no effect on Novell's ability to distribute any other code, GPLv3 or otherwise.
So if one of those other operating systems uses GPLv3 software and extends a covenent not to sue over portions of the GPLed software and that doesn't extend to all downstream users, whoever made the covenent or deal and whoever is a party to the deal cannot distribute GPLv3 covered works again (ever).
I still don't see that "all or nothing" clause. All it says is that you cannot distribute the specific GPLv3 work that is covered by a patent protection that does not extend downstream. You can still distribute GPLv3 work that needs to patent coverage, or who's patent coverage extends downstream.
Now the FAQ is actually more confusing (and I think misleading) than the actual license:
Second, in the fifth paragraph, the draft says that you are prohibited from distributing software under GPLv3 if you make an agreement like the Microsoft-Novell deal. This will prevent other distributors from trying to make other deals like it in the future.
This seems to back your argument that Novell would be prohibited from distributing ANY GPLv3 software, but that is not what the license says:
You may not convey a covered work if you are a party to an arrangement with a third party... under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants... a patent license in connection with copies of the covered work conveyed by you... or primarily for and in connection with specific products or compilations that contain the covered work, which license does not cover, prohibits the exercise of, or is conditioned on the non-exercise of any of the rights that are specifically granted to recipients of the covered work under this License
Now again I am not a lawyer, but basic English interpretation of this suggest that the first "a covered work" is meant to convey a single arbitrary work, and the following "the covered work"s are meant to refer back to that single arbitrary work. For what you are suggesting, with they would both have to be changed to read "any covered work".
To illustrate, if I told you" "You cannot eat a food if the food contains apples", that means if the food you have contains apples, you cannot eat it. It doesn't mean that if the food you have contains apples, that you cannot eat any food, regardless of apple content. Make sense?
Ok, I went back and read the 3rd draft. I still think you're reading it wrong:
You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work,
This clearly limits "a covered work" to only those in which you are a party to an agreement requiring royalties or patent licenses due to your activity in "the work". It clearly has no connection to either works not covered by the GPLv3, or GPLv3 works not covered by the royalties and patents.
But I think what you are specifically talking about is this:
(b) primarily for and in connection with specific products or compilations that contain the covered work, which license does not cover, prohibits the exercise of, or is conditioned on the non-exercise of any of the rights that are specifically granted to recipients of the covered work under this License
This means that if Novell pays Microsoft royalties for Suse, or if Suse requires a patent license from Microsoft, or if you must agree to limitations to the rights afforded by the GPLv3 license of an included program in order to obtain Suse, then Suse cannot contain GPLv3 licensed programs like the GNU tools. However, if the patent license is primarily for only a single work within the collection, like Mono, and it does not impose any limitations on the user to exercise their rights under the terms of the GPLv3 for other works in the collection, like GNU tools, then they are not in violation.
Under your interpretation, nobody would ever adopt GPLv3 programs, because then they could not be distributed under Mac OSX, Solaris, AIX, HP-UX, and any other operating system that contains patent-covered programs.
You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a patent license
Now I am not a lawyer, and if you are I will concede the point to you, but this reads to me as saying that you cannot distribute a GPLv3 program if that program requires royalties or a patent license. There isn't an all or nothing clause that would stop them from distribution any GPLv3 software, only what is covered by the patent. This only means that if Novell adds code to, say, Mono that requires a Microsoft patent license, then they cannot distribute Mono under GPLv3. However, they can still distribute the GNU tools under GPLv3, because those tools do not require the patent license.
Further, there is absolutely nothing in the GPLv3 that would require Linux to move to the new license, unless the Linux maintainers chose to include GPLv3 licensed code in the kernel. Distros using the GPLv2 kernel can still distribute GPLv3 software on top of it, why would you think otherwise? Also, the kernel maintainers don't require contributors grant them copyright on the code, so the maintainers cannot offer contributed code under a different license than they were granted, including the GPLv3 since Linus stripped the "or a later version" from the GPLv2 license he used. This means that for the Linux kernel to move to the GPLv3, they would need the consent of every contributor, which doesn't seem possible.
Making it stop throwing away type information (generics) would be very, very nice. This is imho one of the greatest current flaws in Java. I fear it will mean changing the JVM, though.
Which is exactly why Sun opted to make generics a compiler constraint, so that generified code would still run on older VMs. I agree though, that since Java 6 introduced changes to the bytecode, they could have included generic type information at that point.
Besides this, I could make a very, very long wishlist for Java. Though I suppose I'd just end up with C++, minus the old annoying baggage.
Isn't that an old saying? "Those who don't understand C are doomed to reinvent it"? Or maybe it was Lisp.
The term "linking" has actually caused a lot of confusion due to the difference between how Java links to libraries as opposed to C/C++. For C/C++, linking is much closer to a derivative work than in Java since (to my knowledge, I'm not a C programmer) when you "link" to a C/C++ library, you actually need the source code (or at least header files) from that library in order to compile your code, therefore including elements of that library's source in your final binary. In Java, you can "link" your code to a library's binary without including anything from it's source.
Because it is much easier for Sun to just release 90% of their code under the same license used by GNU Classpath, then let the classpath guys, or anyone else in the community, figure out what of that missing 10% can be filled in with Classpath code.
Slashdot Mirror
You only get that particular wizard if you know what codecs you are going to need before you need them. Otherwise Ubuntu will install the correct packages for you the first time you attempt to open a file that needs them, you don't even need to know the package name.
Heh, you must not use Ubuntu 7.04.
Here's how it would actually work...
Customer gets WMV file from his kid.
Customer double-clicks WMV file, or right-clicks and selects "Open with Movie Player"
Ubuntu: This file requires additional codecs to play, would you like me to install them?
Customer: Yes please
(wait 1 minute)
Ubuntu: All done, enjoy your movie!
Customer happily watches their WMV.
The next day, Customer sends his Windows kid some awesome Theora file...
So the point is, "sales" is good for PR, but "usage" is good for business.
Ah, thanks for the correction. You're right, this exploit is kind of trivial, since it requires the attacker already has complete access to a system. It just used BITS to bypass firewall restrictions.
It's kind of like saying that once a thief gets into a safe, it's easy for him to steal all your money.
Presumably even if you have Firefox whitelisted and a trojan uses it to download more malware, that malware can only be run with user permissions, not "System" permissions like BITS has. Therefore the amount of damage Firefox can do on a decently designed OS is limited to the damage a non-privileged user account can do, and no more.
Maybe, but being a Gnome user by choice, I don't see it as frightening as you do. However, someone running Gnome is much more likely to switch to KDE that someone running Windows, so you must admit it's still a better situation.
That's a consequence of library dependency, not the packaging system. Windows has the same problem, and it's less elegant solution created the famous DLL hell. The best solution is for library developers to maintain backwards compatibility as much as possible, and for application developers to not depend on new library features unless they are really necessary.
It would be nice of the language of the GPLv3 were phrased such that you are only dissallowed from distributing a work due to a patent license or similar agreement if that GPLv3 work requires such a license to be legally distributed. That way even if Microsoft makes a blanket patent license for all of Suse Linux, Novell could distribute GPLv3 software, even without the patent license extending to non-Novell customers, because the GPLv3 work itself does not require the license. That would protect Novell from the GPLv3, while still letting them hold Microsoft to the compatibility part of the agreement. Even better, the fact that they would be distributing GPLv3 software under the MS agreement, and MS allowing them to do so, would be an admission by both parties that the GPLv3 software contains no Microsoft IP. Otherwise, if Microsoft wants to claim that the GPLv3 software does contain their IP, they would have to tell Novell where it is, something they (like SCO) have not wanted to do. And if Microsoft is distributing copies of Novell, which I think they are, then would either have to legally disclaim any patented code or be themselves in violation of the GPLv3.
You can pass this suggestion on to whomever you're talking to at the FSF.
Here's a comparison: http://kitenet.net/~joey/pkg-comp/
Debian packages have several features that make them more useful, especially when it comes to dependencies.
My favorite programming edit, JEdit, recenty started offering DEB packages. So when I put Ubuntu on a new computer, I downloaded the DEB directly from JEdit's website. No adding a repository, just a .deb file. I double click on it in nautilus, and it asks if I want to install it. I say "yes" and it tells me there are some dependencies not in the DEB package, but available in the Ubuntu repos, and asks if I want to download and install them too. Again, I say "yes", and it goes and does everything for me. When it's done, I've got JEdit installed, with menu items and everything. As far as I know, JEdit is maintaned by one guy, so this can't be all that difficult.
Ok, that makes more sense to me. I'll admit, I just assumed that the "covenant not to sue" specified specific products within the Suse distribution. I would be surprised if Microsoft would give Novell the IP equivalent of a blank check, allowing them to violate any Microsoft patents as long as it's packaged into Suse. But, I guess if their intent was to make Novell a pawn to kill off other distros, even at the expense of temporarily losing Windows licensees to Novell, it would make sense.
However, since Novell's official position is that there is nothing in Suse Linux that requires a patent license from Microsoft in the first place, and that it is only to make potential customers less worried about compatibility and possible legal action, then I suppose they could argue that it is not a violation of the GPLv3 at all. After all, the GPL specifically allows people to distribute GPL code with additional warranties and guarantees, why not with additional patent protection as well.
I think there was probably some expectation that they might install on these Dells Wine for those non-technical users who would assume that their windows programs will run on any Dell machine.
Oh wait, I see now. You created another packaging system that is incompatible with both DEB and RPM files, makes installing packages harder than RPM and DEB (4 steps as opposed to 2), doesn't integrate with the rest of the desktop environment, has no widespread support among software developers, and you're bitter than Ubuntu didn't see the value in it. Did I miss anything?
Um, WTF? If Windows doesn't include software I want, I download it and install in. For linux, it's probably in the distro's repository, so downloading and installing it is even easier. If it's not, then I'm back to where I am on Windows, download it and install it.
Now I doubt Ubuntu will setup a different repository for Dell installs, so Wine will likely be only an apt-get away. The announcement is just saying that Wine will not be in the default installation, for the logical reasons given.
But lets say you're right, and Ubuntu doesn't offer it for Dell installs, you just download it and install it yourself, it'll even handle downloading and installing any dependencies for you.
So the absolute worst case scenario here is that installing software in Ubuntu is as easy as installing software on Windows, but chances are it will be much much easier. Basically everything about your post was FUD, and not even intentional FUD, but ignorant FUD. From someone who claims to be a Linux developer (and a Wine developer too?), I can't fathom how you could not know this.
Java is no different here, if you write a Java program in Java 5, as long as you don't use any of the new features in Java 5, it can still be compiled by a Java 1.4 compiler.
What you are talking about is compiling it with Java 5, then trying to run it on Java 1.4. In that case, the Java 5 compiler generates a binary suitable for the Java 5 runtime, but not the Java 1.4 runtime. That is akin to compiling something against GTK 2.8, and complaining when it has problems linking to a GTK 2.4 library. There is a reason programs have dependencies on GTK 2.8 or higher you know.
Using Python as an example isn't a good comparison because it is compiled to the proper version of the interpreter each time it is run. You don't get version incompatibilities, you just get compilation errors. The same thing happens with Perl.
Maybe I will have to ask the FSF for clarification here, because you still haven't convinced me. In English "a" denotes a singular item not plural, so "a covered work" denotes a singular covered work, as opposed to "any covered works" which would denote a plurality of covered works.
Now the FAQ is actually more confusing (and I think misleading) than the actual license:This seems to back your argument that Novell would be prohibited from distributing ANY GPLv3 software, but that is not what the license says:Now again I am not a lawyer, but basic English interpretation of this suggest that the first "a covered work" is meant to convey a single arbitrary work, and the following "the covered work"s are meant to refer back to that single arbitrary work. For what you are suggesting, with they would both have to be changed to read "any covered work".
To illustrate, if I told you" "You cannot eat a food if the food contains apples", that means if the food you have contains apples, you cannot eat it. It doesn't mean that if the food you have contains apples, that you cannot eat any food, regardless of apple content. Make sense?
Ok, I went back and read the 3rd draft. I still think you're reading it wrong:This clearly limits "a covered work" to only those in which you are a party to an agreement requiring royalties or patent licenses due to your activity in "the work". It clearly has no connection to either works not covered by the GPLv3, or GPLv3 works not covered by the royalties and patents.
But I think what you are specifically talking about is this:This means that if Novell pays Microsoft royalties for Suse, or if Suse requires a patent license from Microsoft, or if you must agree to limitations to the rights afforded by the GPLv3 license of an included program in order to obtain Suse, then Suse cannot contain GPLv3 licensed programs like the GNU tools. However, if the patent license is primarily for only a single work within the collection, like Mono, and it does not impose any limitations on the user to exercise their rights under the terms of the GPLv3 for other works in the collection, like GNU tools, then they are not in violation.
Under your interpretation, nobody would ever adopt GPLv3 programs, because then they could not be distributed under Mac OSX, Solaris, AIX, HP-UX, and any other operating system that contains patent-covered programs.
Further, there is absolutely nothing in the GPLv3 that would require Linux to move to the new license, unless the Linux maintainers chose to include GPLv3 licensed code in the kernel. Distros using the GPLv2 kernel can still distribute GPLv3 software on top of it, why would you think otherwise? Also, the kernel maintainers don't require contributors grant them copyright on the code, so the maintainers cannot offer contributed code under a different license than they were granted, including the GPLv3 since Linus stripped the "or a later version" from the GPLv2 license he used. This means that for the Linux kernel to move to the GPLv3, they would need the consent of every contributor, which doesn't seem possible.
The term "linking" has actually caused a lot of confusion due to the difference between how Java links to libraries as opposed to C/C++. For C/C++, linking is much closer to a derivative work than in Java since (to my knowledge, I'm not a C programmer) when you "link" to a C/C++ library, you actually need the source code (or at least header files) from that library in order to compile your code, therefore including elements of that library's source in your final binary. In Java, you can "link" your code to a library's binary without including anything from it's source.
Because it is much easier for Sun to just release 90% of their code under the same license used by GNU Classpath, then let the classpath guys, or anyone else in the community, figure out what of that missing 10% can be filled in with Classpath code.