Guess you need to recheck then. Quote from RMS: "My 22-year-old child, the Free Software Movement, occupies most of my life, leaving no room for more children, but I still have room to love a sweetheart." HTH.
You don't know what you are talking about. I hope you do realize that the FSF is one of the major enforcers of the GPL in court and in out-of-court negotiations! Therefore the FSF DOES help defend your rights if somebody is in violation of the license of your program!
Ever used ls, or cp, etc.? Yes, the base of your system is all developed and maintained by the GNU effort. Go ahead and bash RMS, but then at least be consequent and use *BSD!
Yeah, but the other side profits too, e.g. the art scene.
Now you could argue who profits more, Google or the other party, thereby evaluating how much and in which direction money should flow. But this is extremely difficult.
Itention to stay together and having a back-off plan are two completely different things! My intention to stay with a partner is not degraded by an exit strategy.
Many pundits such as the Federation of American Scientists recognize that in an individual match-up, the MiG-29 is potentially better than the F-15 Eagle or F-16 Falcon.
A robot is a device which acts automatically, on its own, maybe triggered by sensors.
So what's so new about these news? There have been automatic defense system which fire as soon as something comes in sight. Is this not a robot? Just because it doesn't look like the classic sci-fi robot does it make no less a robot.
Installing a program ad-hoc (which is what you obviously want to do) and a managed install from a repository are completely different philosophies.
Looking at my OS X box, most installs are ad hoc, i.e. you go to a webiste (e.g. mozilla.org), download the binary, and invoke the installer. This will install me a standalone, self-contained application. The advantage of this approach is its ease of initial use. Head to website, download, install. The downside is: dependencies (ok, first go to site A and download X, the go to site B and download Y, etc., until you've got all you need to run the application you initially wanted. Second, updates (but see below).
The repository approach (e.g. on my Debian boxes) is fundamentally different: you download software from one source. The dependencies are fetched automatically. The actual application is in a certain relationship to other installed packages. The advantages? Imagine you want to remove the app you installed. With the ad-hoc approach, you then still have its dependencies lying around. Or are they really still dependencies? Maybe they are now used by other programs in the meantime, and uninstalling will break them. This problem is dealt with in the repository approach, since the package management system knows exactly what packages are installed because you explicitely requested them, and what are only auxiliary packages, which are automatically removed when the last application which relied on them is removed.
A further point is updates. How do you update your ad-hoc installations? Well, most of the time, you browse around the web checking if a new version of one of your installed applications is available (apps like Firefox which have their own update mechanisms are the exception). Got N installed apps? Then you have to do N steps to update your system. With the repository approach, you simply tell the package management system to update, and it automatically installs all available newer packages. N packages, 1 step to update them all.
With the repository approach you are also guaranteed that the package fits into your system nicely, since the installation routines are tweaked to seamless integrate the application into your system. And you have somebody dedicated to do this tweaking who knows your system exactly. With ad-hoc installations you've got only one person, the application developer, who is responsible for installation. Imagine for example I wrote an application which is so portable that it may run on Unix as well as on Windows sytems. I could very well write a neat installer for Unix systems, at least for some of them. But I know shit about Windows. I could maybe provide a.bat or how they are called over there, but you can rest assured that it certainly won't play nicely with your system. With the repository approach OTOH, you have the package maintainer who modifies the installation routine in such a way that it plays nicely with your system, no matter if the developer of the application had the slightest idea about your system or not.
Furthermore, if you use a package management system from a distro like Debian, you not only have centralised installation, but also support. You have the package maintainers which you can contact if you experience bugs, and you have other central contact points like the mailinglists of that distro. With ad-hoc apps, you first have to roam the Internet to find support.
Also, with the repository approach, you get certain guarantees about stability, availability of packages in your preferred language, documentation, etc., which are described in an overall policy. Package maintainers are anxious to fulfill these requirements, and that's also the cause that it sometimes takes a little longer for a new version of an application to get into the repository, because the app may not be stable enough, or lack some other things which are prescribed by the policy, and so the package maintainers first have to add these missing bits in order to meet their
Well, then just leave these consumers alone. I mean, honestly, I use FL/OSS because it gives me want I want and need. But I simply do not care about people who don't. It is not my problem they are not using FL/OSS.
And it may be even better to keep the common consumer out of FL/OSS anyways, since I definitely do not want support requests on mailinglists from clueless Windows converts.
At my university (10'000+ students), more and more of the students facilities are switched to GNU/Linux (already more than half of it). We used to be a 40% Solaris/40% Windows/20% others shop, now we are a 60% GNU/Linux/20% Windows/5% Solaris/15% others (Mac, SGI, etc.) site.
Slashdot Mirror
But hey, since you are a well known troll around here, I'll stop argueing with you now.
Now you could argue who profits more, Google or the other party, thereby evaluating how much and in which direction money should flow. But this is extremely difficult.
From http://en.wikipedia.org/wiki/Mikoyan_MiG-29:
Russian fighters are indeed pretty good!So what's so new about these news? There have been automatic defense system which fire as soon as something comes in sight. Is this not a robot? Just because it doesn't look like the classic sci-fi robot does it make no less a robot.
Looking at my OS X box, most installs are ad hoc, i.e. you go to a webiste (e.g. mozilla.org), download the binary, and invoke the installer. This will install me a standalone, self-contained application. The advantage of this approach is its ease of initial use. Head to website, download, install. The downside is: dependencies (ok, first go to site A and download X, the go to site B and download Y, etc., until you've got all you need to run the application you initially wanted. Second, updates (but see below).
The repository approach (e.g. on my Debian boxes) is fundamentally different: you download software from one source. The dependencies are fetched automatically. The actual application is in a certain relationship to other installed packages. The advantages? Imagine you want to remove the app you installed. With the ad-hoc approach, you then still have its dependencies lying around. Or are they really still dependencies? Maybe they are now used by other programs in the meantime, and uninstalling will break them. This problem is dealt with in the repository approach, since the package management system knows exactly what packages are installed because you explicitely requested them, and what are only auxiliary packages, which are automatically removed when the last application which relied on them is removed.
A further point is updates. How do you update your ad-hoc installations? Well, most of the time, you browse around the web checking if a new version of one of your installed applications is available (apps like Firefox which have their own update mechanisms are the exception). Got N installed apps? Then you have to do N steps to update your system. With the repository approach, you simply tell the package management system to update, and it automatically installs all available newer packages. N packages, 1 step to update them all.
With the repository approach you are also guaranteed that the package fits into your system nicely, since the installation routines are tweaked to seamless integrate the application into your system. And you have somebody dedicated to do this tweaking who knows your system exactly. With ad-hoc installations you've got only one person, the application developer, who is responsible for installation. Imagine for example I wrote an application which is so portable that it may run on Unix as well as on Windows sytems. I could very well write a neat installer for Unix systems, at least for some of them. But I know shit about Windows. I could maybe provide a .bat or how they are called over there, but you can rest assured that it certainly won't play nicely with your system. With the repository approach OTOH, you have the package maintainer who modifies the installation routine in such a way that it plays nicely with your system, no matter if the developer of the application had the slightest idea about your system or not.
Furthermore, if you use a package management system from a distro like Debian, you not only have centralised installation, but also support. You have the package maintainers which you can contact if you experience bugs, and you have other central contact points like the mailinglists of that distro. With ad-hoc apps, you first have to roam the Internet to find support.
Also, with the repository approach, you get certain guarantees about stability, availability of packages in your preferred language, documentation, etc., which are described in an overall policy. Package maintainers are anxious to fulfill these requirements, and that's also the cause that it sometimes takes a little longer for a new version of an application to get into the repository, because the app may not be stable enough, or lack some other things which are prescribed by the policy, and so the package maintainers first have to add these missing bits in order to meet their
And it may be even better to keep the common consumer out of FL/OSS anyways, since I definitely do not want support requests on mailinglists from clueless Windows converts.
Sorry, sometimes I just have to rant.
But hey, this is Europe, no idea about the US.