.deb,.rpm : package knows what other stuff needs to be installed for it to work. .tgz : package doesn't know anything.
.tgz archives are often just installed by untaring them. This can make it a nightmare to de-install something. (You can't just remove every file which gets installed. If you untar A.tgz and B.tgz, both containing/lib/foo.so, and then delete all the files which were contained in A.tgz, then you'll delete/lib/foo.so and B will stop working). However, this is not a deficiency of the *package*, just the install method. If you install a tgz archive using dpkg (via alien) then you don't have this problem.
If two packages both contain files called/lib/foo.so but the two files are not identical, this causes problems. A centralised repository, like a [debian/redhat] mirror, can ensure that this doesn't happen. Free software can live in repositories, and be tailored to ensure conflicts don't happen. You can't do this with proprietory software; if you install two proprietory packages from different locations, there's no way to guarantee they won't have any conflicting files, except doing away with shared libraries altogether.
I don't know much about rpm. But in Debian you can get a list of available packages and highlight items on this list and the system will install them automatically.
There's a few issues with this list. It is very long (thousands of packages) and has lots of stuff like libtiff which would only be installed because another package needed them. A newbie doesn't need to see these libraries, just the "actual programs". But all in all, it's easier to install a Debian package than a Windows program that uses InstallShield (as other people have pointed out).
This will remove all files associated with foo, including config files. It won't remove data files you've created; this is good. (Imagine if uninstalling Word removed all your Word documents!)
WARNING TO NEWBIES: You probably DON'T want to do this. Instead do "dpkg -r foo".
Debian (.deb) packages contain more than just files and a list of dependencies. For one thing, the menus in your window managers are updated automatically. On a more general level, some packages have scripts which run when they are installed. E.g. the glibc 2.1 package checks if you are upgrading from glibc 2.0 and if so it restarts the services on your machine which may be affected. I imagine rpm can do things like this, too.
Besides, there are more incompatibilities between different distros than just package formats. Configuration files often need to be kept in different places, particularly init scripts. The Linux Standard Base may help in future, but for now the differences are there.
I'm not saying that GNU Stow couldn't be part of a Grand Unified Solution, just that there's more to modern package management than archive formats.
Legally, the only person who can be responsible for a fault in something you bought is the vendor. You don't have a contract with anybody else. This is a good thing. If there is a kernel problem, Red Hat should have warned their customers thaht this is a possibility. Otherwise they should accept the consequences for misleading you into thinking Red Hat is reliable.
This "flaw" is the same flaw if I buy some poisoned Coke from the newsagents. Was it the newsagent's fault? Or Coke's?
Legally, I can only sue the newsagent. But then the newsagent can sue Coke, so it kind of works out.
I think that's fine for the download or Cheapbytes version. However I think a company should be broadly responsible for what they sell. If there are errors in Red Hat which cause major problems to a customer, I think the customer has a right to a refund, at least.
It's different for a $2 CD. Neither the vendor nor the authors should be responsible for any errors in this.
It has been known not to for several years in a row. Of course Red Hat makes consistent losses right now, but Apple probably did this at the start, too.
The other way such a body could help is by giving advice about things to do *before* litigation starts. They could teach the free software community how to protect itself, how to avoid blunders which make litigation more likely.
Perhaps somebody could put together a legal howto. How to keep your copyright enforceable. How to react to threatening letters. And if it comes to it, how to defend yourself in court. Sure, reading a howto is no substitute for years of legal training, but it's better than nothing.
a) Red Hat's worth as much as Apple. But you're right, this is a problem. b) Good - common law is often ambiguous. c) The US constitution is full of ideology. d) Commercial software licenses are more widely abused. e) How is this relevant? f) I don't understand what this means.
Litigation may seem to be an insurmountable problem. So did writing a free Unix clone.
> OSS is a bit too close to communism for the comfort of most old-school capitalists.
Yes. It's easy to paint this form of "sharing" as communism. Particularly if you forget that copyright is a government-granted monopoly. The market for OSS is a much more free market than the market for closed-source software. But many people associate capitalism with corporatism and government favours for large businesses, which is not free market economics.
Well I think you're right that this needs actual *lawyers* looking to be any use. But if any lawyers do put in some time then it can't but help. If there's a few lawyers from different parts of the world they may be able to forge strategies which will work in courtrooms in different juristictions.
Besides, it's not as if there's a multi-million dollar pool with which to hire expensive lawyers. The EFF will be stretched to its limits. If this is the only help some Doe gets in his case, then it could make a big difference.
I'm interested... what do you think of typical proprietory EULAs? (e.g. "You may only use this software on the computer it came with", "By accepting this EULA you agree that this program may not work at all and it's all your problem", etc)
No. People are free to choose whether to listen to RMS or not. In a communist country, people don't have the freedom to ignore the government. Anyway dictatorship != communism.
Brett's anecdote must date back to at least 1983. Wage data probably wasn't on the MIT computer in those days. Do you have evidence that RMS or the FSF believe, or have ever believed, that people's bank info should be publically available?
I certainly wouldn't store stuff on my work PC which was meant to be secret. (Confidential files, e.g. bank details, on the central server are a different matter)
Do you have any evidence which shows that RMS hase *ever* opposed the use of strong crypto *by the general public*? (As opposed to his colleagues keeping secrets from each other)
I believe the government should not grant everlasting monopolies to software companies. I don't believe that the state should have a monopoly on the creation and distribution of wealth, or that the state should have a monopoly on rights at the expense of the individual, or that income should be equally distributed.
You shouldn't relate the two concepts just because they both seem alien to you; they are almost entirely unconnected.
I can't comment on the validity of your claims, so I shall presume they're accurate. But FSF accounts have passwords, and the current license terms for Emacs don't prevent anyone from using it who agrees to the license terms, including MIT, Microsoft and Saddam Hussein. The GNU project has developed the GNU Privacy Guard, which assists untappable communication. So whatever the background was to the situation you describe, RMS and the FSF clearly uphold the right privacy today.
Your comment about books and music is just plain wrong. RMS has said he finds it acceptable for authors/composers to prohibit large-scale redistribution of their novels/music, provided people are free to give copies to a few friends. His view on software manuals is that they should be free, including the freedom to commercially redistribute.
It's very easy. Let me spell it out. 1) Anyone has the *right* to share anything they have. (Equivalently, nobody can restrict you from sharing what you have).
2) No-one has the *obligation* to share anything they have. (Therefore *if* you share your stuff, you can't stop the people you share it with from sharing it some more).
Slashdot Mirror
The biggest difference in the actual *packages*:
.rpm : package knows what other stuff needs to be installed for it to work.
/lib/foo.so, and then delete all the files which were contained in A.tgz, then you'll delete /lib/foo.so and B will stop working).
/lib/foo.so but the two files are not identical, this causes problems. A centralised repository, like a [debian/redhat] mirror, can ensure that this doesn't happen. Free software can live in repositories, and be tailored to ensure conflicts don't happen. You can't do this with proprietory software; if you install two proprietory packages from different locations, there's no way to guarantee they won't have any conflicting files, except doing away with shared libraries altogether.
.deb,
.tgz : package doesn't know anything.
.tgz archives are often just installed by untaring them. This can make it a nightmare to de-install something. (You can't just remove every file which gets installed. If you untar A.tgz and B.tgz, both containing
However, this is not a deficiency of the *package*, just the install method. If you install a tgz archive using dpkg (via alien) then you don't have this problem.
If two packages both contain files called
I don't know much about rpm. But in Debian you can get a list of available packages and highlight items on this list and the system will install them automatically.
There's a few issues with this list. It is very long (thousands of packages) and has lots of stuff like libtiff which would only be installed because another package needed them. A newbie doesn't need to see these libraries, just the "actual programs". But all in all, it's easier to install a Debian package than a Windows program that uses InstallShield (as other people have pointed out).
I think you mean ~/.
dpkg --purge foo
This will remove all files associated with foo, including config files. It won't remove data files you've created; this is good. (Imagine if uninstalling Word removed all your Word documents!)
WARNING TO NEWBIES: You probably DON'T want to do this. Instead do "dpkg -r foo".
Debian (.deb) packages contain more than just files and a list of dependencies. For one thing, the menus in your window managers are updated automatically. On a more general level, some packages have scripts which run when they are installed. E.g. the glibc 2.1 package checks if you are upgrading from glibc 2.0 and if so it restarts the services on your machine which may be affected. I imagine rpm can do things like this, too.
Besides, there are more incompatibilities between different distros than just package formats. Configuration files often need to be kept in different places, particularly init scripts. The Linux Standard Base may help in future, but for now the differences are there.
I'm not saying that GNU Stow couldn't be part of a Grand Unified Solution, just that there's more to modern package management than archive formats.
Legally, the only person who can be responsible for a fault in something you bought is the vendor. You don't have a contract with anybody else. This is a good thing. If there is a kernel problem, Red Hat should have warned their customers thaht this is a possibility. Otherwise they should accept the consequences for misleading you into thinking Red Hat is reliable.
This "flaw" is the same flaw if I buy some poisoned Coke from the newsagents. Was it the newsagent's fault? Or Coke's?
Legally, I can only sue the newsagent. But then the newsagent can sue Coke, so it kind of works out.
I think that's fine for the download or Cheapbytes version. However I think a company should be broadly responsible for what they sell. If there are errors in Red Hat which cause major problems to a customer, I think the customer has a right to a refund, at least.
It's different for a $2 CD. Neither the vendor nor the authors should be responsible for any errors in this.
> Apple makes a profit.
It has been known not to for several years in a row. Of course Red Hat makes consistent losses right now, but Apple probably did this at the start, too.
The other way such a body could help is by giving advice about things to do *before* litigation starts. They could teach the free software community how to protect itself, how to avoid blunders which make litigation more likely.
Perhaps somebody could put together a legal howto. How to keep your copyright enforceable. How to react to threatening letters. And if it comes to it, how to defend yourself in court. Sure, reading a howto is no substitute for years of legal training, but it's better than nothing.
a) Red Hat's worth as much as Apple. But you're right, this is a problem.
b) Good - common law is often ambiguous.
c) The US constitution is full of ideology.
d) Commercial software licenses are more widely abused.
e) How is this relevant?
f) I don't understand what this means.
Litigation may seem to be an insurmountable problem. So did writing a free Unix clone.
> OSS is a bit too close to communism for the comfort of most old-school capitalists.
Yes. It's easy to paint this form of "sharing" as communism. Particularly if you forget that copyright is a government-granted monopoly. The market for OSS is a much more free market than the market for closed-source software. But many people associate capitalism with corporatism and government favours for large businesses, which is not free market economics.
Well I think you're right that this needs actual *lawyers* looking to be any use. But if any lawyers do put in some time then it can't but help. If there's a few lawyers from different parts of the world they may be able to forge strategies which will work in courtrooms in different juristictions.
Besides, it's not as if there's a multi-million dollar pool with which to hire expensive lawyers. The EFF will be stretched to its limits. If this is the only help some Doe gets in his case, then it could make a big difference.
Cool - we agree on something. Let's hope UCITA fails. (And this damn encryption thing we have looming in the UK...)
I'm interested ... what do you think of typical proprietory EULAs?
(e.g. "You may only use this software on the computer it came with", "By accepting this EULA you agree that this program may not work at all and it's all your problem", etc)
Give a specific example of RMS, or the FSF, advocating mandatory publication of bank details.
No. People are free to choose whether to listen to RMS or not. In a communist country, people don't have the freedom to ignore the government. Anyway dictatorship != communism.
Brett's anecdote must date back to at least 1983. Wage data probably wasn't on the MIT computer in those days. Do you have evidence that RMS or the FSF believe, or have ever believed, that people's bank info should be publically available?
Do you advocate a legal system which bans "copyleft"? Or do you think people have the right to license their work as they choose?
I certainly wouldn't store stuff on my work PC which was meant to be secret. (Confidential files, e.g. bank details, on the central server are a different matter)
One of RMS's main objections to the APSL was that it didn't let you keep your modifications private.
Which link shows that the FSF opposes the right to privacy?
Do you have any evidence which shows that RMS hase *ever* opposed the use of strong crypto *by the general public*? (As opposed to his colleagues keeping secrets from each other)
1) I was stating (my understanding of) the position of RMS and the FSF, not my own.
2) you have still completely failed to grasp the point. Nobody expects you to give anything away. I don't know where you've got this idea from.
I believe the government should not grant everlasting monopolies to software companies. I don't believe that the state should have a monopoly on the creation and distribution of wealth, or that the state should have a monopoly on rights at the expense of the individual, or that income should be equally distributed.
You shouldn't relate the two concepts just because they both seem alien to you; they are almost entirely unconnected.
I can't comment on the validity of your claims, so I shall presume they're accurate. But FSF accounts have passwords, and the current license terms for Emacs don't prevent anyone from using it who agrees to the license terms, including MIT, Microsoft and Saddam Hussein. The GNU project has developed the GNU Privacy Guard, which assists untappable communication. So whatever the background was to the situation you describe, RMS and the FSF clearly uphold the right privacy today.
Your comment about books and music is just plain wrong. RMS has said he finds it acceptable for authors/composers to prohibit large-scale redistribution of their novels/music, provided people are free to give copies to a few friends. His view on software manuals is that they should be free, including the freedom to commercially redistribute.
It's very easy. Let me spell it out.
1) Anyone has the *right* to share anything they have.
(Equivalently, nobody can restrict you from sharing what you have).
2) No-one has the *obligation* to share anything they have.
(Therefore *if* you share your stuff, you can't stop the people you share it with from sharing it some more).