P. S. If it weren't for the _Times_ supplying a good fraction of Slashdot's reportage, so-called, there wouldn't be terribly much interesting to read here.
On the contrary, most of the news is reported because the Times states what is already known to all here and it is a major news source for the general public.
Again, average users don't need to recompile the kernel. Concessions to their lack of technical expertise would be ineffective and unnecessary.
How do you know technical expertise is what is needed?
That wouldn't lower the barrier of entry for kernel hacking. Programming the kernel is hard and becoming more so as the system becomes more complex (with more granular locking, etc). The difficulty of running menuconfig is nothing compared to dealing with those issues.
Kernel hacking is intellectually stimulating and there is no point in putting off people with things like these which could be classified as grunt work at best.
Second, I'm happy with kernel hackers being an elite group. That's totally different than Linux users being an elite group, which I don't feel is true and am glad for. If kernel hackers were not an elite group, I believe code quality would suffer.
Fortunately, there is some sort of hierarchy that has been setup to handle just this. Most people don't submit patches to Linus directly. There is no need to eliteness. You can always start working up from the mailroom.
Don't know. You'd have to give more specifics...
I was talking about the patch files. I can only see the full tarball nowadays.
If you think reading slashdot gives you some special insight into the mind of the average linux user, you are woefully wrong. Just about every developer and manager at my company reads slashdot, but most of those people are not linux users.
You only have to look at the (classified) browser stats to prove this statement. And there are so many people who are publically pro MS (and state that they are MS employees no less).
What do you expect from someone who put a LISP interpreter into a text editor? "When in doubt, make it as general as possible" seems to be the motto...
You can still write code with magnets on the hard drive, if that suits you. But all (good) editors will tend to emacs in the limit.;-)
Disallowing an unworkable configuration doesn't seem unreasonable, though.
I suppose this is OK as long as there is some mechanism to override it for experienced users. Imagine if ESR had left after it was merged into the kernel. Can you imagine the nightmare?
Second, configuring a kernel will never be easy. You have to make a lot of decisions that require technical knowledge. Whether you do that in a text-based interface or a fancy graphical one doesn't matter very much. That doesn't mean a fancy graphical interface shouldn't be made, but it shouldn't be made for the reason of making it easier for mom to use Linux.
As someone said, the idea is to make it as easy as possible, but no easier. Currently, a lot of time is wasted with trivial stuff. Of course, you will have to think a lot about the network and filesystem options. However, there are lot of options that should be selected by default too.
The correct solution to make hardware configuration usable for the masses is not to make building a kernel easier but to make building a kernel unnecessary. The system has become more modular over time.
It is almost as important to lower the barrier of entry for kernel hacking, which is very important for Linux's vitality. And speaking of that, I haven't been able to get a decent patch since they implemented bitkeeper for the kernel. What's up with that?
What, you mean it takes too much of your time? Couldn't you just have cron run it with some kind of hands-off all-defaults detail level?
If automatic updates were officially supported, features needed for that would get more attention. Better error recovery and robustness would be welcomed by all users.
But wouldn't the people using the software within your company, internaly, be the users? In that case, does it not make sense to make the source code availible?
No--they are not considered users. When you develop the software as an employee of a particular company, the company is considered a single entity.
But it's always the individuals who say "we need a law" and thus initiate tyranny at the hands of the government. I don't fear individuals wishing to help me. I fear individuals wishing the government to help me.
I am sure the tyrants have their own creative ways of interpreting what individuals want. However, the Free software advocates are the last people you should fear in this regard.
One example: The GNU Manifesto advocates a tax on software to support Free Software development.
I don't ever recall such a stance.
Another example: the good intentions of advocates have caused Venezuela to announce that only the GPL will be used for government developed software, thus prohibiting Venezuelan contributions to Apache, XFree86, etc.
This law will apply only to new software development, ie, the new software written for Government use. As it is, quite a lot of software in a GNU/Linux system is not GPL (that is not to say they are irreplaceable).
I have to agree. I recognize that the people on the KOffice development team, for example, put a LOT of effort into the KOffice suite, but spit and polish do make a difference.
I think they should focus on features which will never make it to these proprietary apps. For example, I don't think IE will ever have popup killing. And proprietary apps usually are not as scriptable and don't play well with apps from other proprietary companies. Free software should play to its strengths.
So, if you deploy a working version of code to be used within your business, the fact that you are required to make the sourcecode availible is a bad thing? I thought the whole point of the GPL was to require that the sourcecode to any version of the software which you use be availible. So now I'm confused, is the GNU/GPL philosophy that code must be availible or that it must only be availible under special circumstances.
The aim of GPL is to protect the user. So if you are deploying within your organization, you are the user and you don't need to publish source. However, APSL will needlessly violate your privacy with their use within the organization clause. However, if youare selling/giving away the software, the recepients rights need to be protected.
This whole version n or later thing means that you essentially are trusting the FSF/GNU with guarding your rights as a developer. I mean, what if the next version of the GPL contains a clause that assigns all rights to covered software exclusively to RMS? In a very real way this embeds an asymmetry into the GPL, since one organization (and only one organization) publishes versions of the GPL.
The version n and later is not part of GPL. It is an option that you can use to protect your software in the future. You can always install software with the oldest version of GPL. The changes in the copyright and other laws and technologies require that GPL be updated constantly. Already, web services can utilize loop holes in the current version of GPL.
As long as you are still charging the batteries from the national grid you're just moving the point the fossil fuels are converted into energy way back up the line, to the power stations.
It would be simpler to upgrade the technology at the power station rather than ask people to switch each time something new comes up.
No, not at all. This is a very genuine concern. Personally, I think having a separate daemon to do this job is a very dumb idea. Existing, well tested tools like ssh and cron could do this, and the less new, untested code that runs on the network, the better for security.
It would be better to write code that will be as small as possible, which is written with the current security practices in mind. Most of the exploits which have plagued UN*X have been from old code like sendmail. That said, Ximian doesn't have the best security record. Their installation script consisted of running code downloaded over HTTP (!!) through a root shell.
Yesterday, I wrote a posting "First version of this story did *not* mention DMCA" that gives my reasons for believing that Apple did not use the DMCA. If OWC wants to change my mind, they can show me the letter from Apple legal that mentions the DMCA.
Apple has not denied that they didn't do this and they had ample time for a denial. I am sure the reporters from C|Net contacted them about this. Unless you can provide evidence that this is not so, I will go with the published version of the story.
OWC was stealing Apple's work, against Apple's license, in order to compete with Apple in the DVD drive market. Apple is the victim here.
This doesn't change the fact that Apple used the DMCA to clobber them. I don't see how this is any different from sending a bunch of thugs down to OWC to take care of them.
OS X includes such well loved open source and free software as GCC, Emacs, Apache, and Perl.
Apple includes Free software in their OS. However, their contribution is much smaller than you think. In the early days, their modified the gcc compiler for Objective C and didn't release the changes. The changes were only released after a lot of pressure from the FSF. Add to this the fact that all the FreeBSD developers who are now Apple employees have left FreeBSD for good really questions Apples intentions.
I would have a lot more freedom if you stopped worrying about mine and concentrated on your own. The only time I find my freedom diminishing is when some idiot decides I need help.
Don't confuse actions of the Government with that of the individuals. I am sure you understand the differences between GPL and UCITA. Which one do you prefer?
...if the so-called "community" would spend less time playing wannabe lawyers arguing about licensing minutiae and spend more time developing new applications for users. The users you need to attract have never heard of Richard Stallman, buy shrinkwrapped software (including Linux, if and when they do use it), and judge an OS by the quality and range of applications available to run on it.
People who don't learn from history are doomed to repeat it. If you saw the state of the software world when GPL was drawn up you would understand why it is the way it is. Even if you are doing this for fun and want to keep it informal, you will have to deal with these eventually. The problems don't go away just because you don't care about them. How would you defend yourself against some company like, say R*MBUS, which takes your code and patents everything in it and then sues you?
Endless iterations of the same traditional Unix toolset, tools for the server side, and attempts to mimic Office and the Windows interface, won't cut it. Be imaginative.
There are other programs out there and they are really creative. It so happens that the server side tools are the most popular. Just because they don't have multibillion dollar marketing budgets doesn't mean they don't exist.
When I've tried to explain Linux to people who make corporate buying decisions, their questions boil down to: Why buy a cheap knock-off when the real thing is available?
I am sorry you have to deal with such people. I am sure they are the ones running scared when the proprietary company they deal with has another licensing brainwave from stock market issues.
As I said in a post above, but I'll include it here incase you have any information, I've been over the APSL a few times already, and I don't see any place where it differs from the GPL in that respect, I don't see any requirements to notify Apple. Do you have any specific section links?
As has been mentioned before, if you deploy it within the company for your everyday operations, you will have to release the code under APSL, while you don't have to under the GPL.
I understand why they want to pick apart licenses, but not why they bother doing their complaining about old versions.
There is a lot of software released under old versions of the licenses. Unless of course they are GPL programs which declare themlselves under GPL version n or later.
Slashdot Mirror
P. S. If it weren't for the _Times_ supplying a good fraction of Slashdot's reportage, so-called, there wouldn't be terribly much interesting to read here.
On the contrary, most of the news is reported because the Times states what is already known to all here and it is a major news source for the general public.
Must be my local mirror then. Thanks for the info.
Again, average users don't need to recompile the kernel. Concessions to their lack of technical expertise would be ineffective and unnecessary.
How do you know technical expertise is what is needed?
That wouldn't lower the barrier of entry for kernel hacking. Programming the kernel is hard and becoming more so as the system becomes more complex (with more granular locking, etc). The difficulty of running menuconfig is nothing compared to dealing with those issues.
Kernel hacking is intellectually stimulating and there is no point in putting off people with things like these which could be classified as grunt work at best.
Second, I'm happy with kernel hackers being an elite group. That's totally different than Linux users being an elite group, which I don't feel is true and am glad for. If kernel hackers were not an elite group, I believe code quality would suffer.
Fortunately, there is some sort of hierarchy that has been setup to handle just this. Most people don't submit patches to Linus directly. There is no need to eliteness. You can always start working up from the mailroom.
Don't know. You'd have to give more specifics...
I was talking about the patch files. I can only see the full tarball nowadays.
If you think reading slashdot gives you some special insight into the mind of the average linux user, you are woefully wrong. Just about every developer and manager at my company reads slashdot, but most of those people are not linux users.
You only have to look at the (classified) browser stats to prove this statement. And there are so many people who are publically pro MS (and state that they are MS employees no less).
What do you expect from someone who put a LISP interpreter into a text editor? "When in doubt, make it as general as possible" seems to be the motto...
You can still write code with magnets on the hard drive, if that suits you. But all (good) editors will tend to emacs in the limit. ;-)
Disallowing an unworkable configuration doesn't seem unreasonable, though.
I suppose this is OK as long as there is some mechanism to override it for experienced users. Imagine if ESR had left after it was merged into the kernel. Can you imagine the nightmare?
GGI tried to do too much and it abstracted too far.
AFAIK, they had a lot of problem using the hardware acceleration in the video card.
ESR's configureator was massive overkill and it made life harder for developers.
Why would anyone object to a text based adventure game in the configuration system? Surely not the MS excel users. ;-)
Second, configuring a kernel will never be easy. You have to make a lot of decisions that require technical knowledge. Whether you do that in a text-based interface or a fancy graphical one doesn't matter very much. That doesn't mean a fancy graphical interface shouldn't be made, but it shouldn't be made for the reason of making it easier for mom to use Linux.
As someone said, the idea is to make it as easy as possible, but no easier. Currently, a lot of time is wasted with trivial stuff. Of course, you will have to think a lot about the network and filesystem options. However, there are lot of options that should be selected by default too.
The correct solution to make hardware configuration usable for the masses is not to make building a kernel easier but to make building a kernel unnecessary. The system has become more modular over time.
It is almost as important to lower the barrier of entry for kernel hacking, which is very important for Linux's vitality. And speaking of that, I haven't been able to get a decent patch since they implemented bitkeeper for the kernel. What's up with that?
What, you mean it takes too much of your time? Couldn't you just have cron run it with some kind of hands-off all-defaults detail level?
If automatic updates were officially supported, features needed for that would get more attention. Better error recovery and robustness would be welcomed by all users.
True, but if Java(tm) ever become popular, we may have to keep an eye on Sun, since they own and control it.
Java is quite popular. And since their customers are developers rather than end users, we can expect much better things.
If you've purchased the music, then you own the MS DRM-free original media. What's to stop you from listening?
The OP was referring to MS' automatic copy restriction technology. How would like to rip your entrie CD collection again?
When you are developing the software though, that would constitute RD which under the APSL is not required to release the source.
One would assume that software was developed to be used in house. In that case GPL gives more privacy and freedom compared to APSL.
But wouldn't the people using the software within your company, internaly, be the users? In that case, does it not make sense to make the source code availible?
No--they are not considered users. When you develop the software as an employee of a particular company, the company is considered a single entity.
Even GNU was meant to be a free replacement for Unix.
GNU stands for GNU is Not UN*X. Clearly, they are not looking to copy UN*X functionality.
But it's always the individuals who say "we need a law" and thus initiate tyranny at the hands of the government. I don't fear individuals wishing to help me. I fear individuals wishing the government to help me.
I am sure the tyrants have their own creative ways of interpreting what individuals want. However, the Free software advocates are the last people you should fear in this regard.
One example: The GNU Manifesto advocates a tax on software to support Free Software development.
I don't ever recall such a stance.
Another example: the good intentions of advocates have caused Venezuela to announce that only the GPL will be used for government developed software, thus prohibiting Venezuelan contributions to Apache, XFree86, etc.
This law will apply only to new software development, ie, the new software written for Government use. As it is, quite a lot of software in a GNU/Linux system is not GPL (that is not to say they are irreplaceable).
I have to agree. I recognize that the people on the KOffice development team, for example, put a LOT of effort into the KOffice suite, but spit and polish do make a difference.
I think they should focus on features which will never make it to these proprietary apps. For example, I don't think IE will ever have popup killing. And proprietary apps usually are not as scriptable and don't play well with apps from other proprietary companies. Free software should play to its strengths.
So, if you deploy a working version of code to be used within your business, the fact that you are required to make the sourcecode availible is a bad thing? I thought the whole point of the GPL was to require that the sourcecode to any version of the software which you use be availible. So now I'm confused, is the GNU/GPL philosophy that code must be availible or that it must only be availible under special circumstances.
The aim of GPL is to protect the user. So if you are deploying within your organization, you are the user and you don't need to publish source. However, APSL will needlessly violate your privacy with their use within the organization clause. However, if youare selling/giving away the software, the recepients rights need to be protected.
This whole version n or later thing means that you essentially are trusting the FSF/GNU with guarding your rights as a developer. I mean, what if the next version of the GPL contains a clause that assigns all rights to covered software exclusively to RMS? In a very real way this embeds an asymmetry into the GPL, since one organization (and only one organization) publishes versions of the GPL.
The version n and later is not part of GPL. It is an option that you can use to protect your software in the future. You can always install software with the oldest version of GPL. The changes in the copyright and other laws and technologies require that GPL be updated constantly. Already, web services can utilize loop holes in the current version of GPL.
As long as you are still charging the batteries from the national grid you're just moving the point the fossil fuels are converted into energy way back up the line, to the power stations.
It would be simpler to upgrade the technology at the power station rather than ask people to switch each time something new comes up.
No, not at all. This is a very genuine concern. Personally, I think having a separate daemon to do this job is a very dumb idea. Existing, well tested tools like ssh and cron could do this, and the less new, untested code that runs on the network, the better for security.
It would be better to write code that will be as small as possible, which is written with the current security practices in mind. Most of the exploits which have plagued UN*X have been from old code like sendmail. That said, Ximian doesn't have the best security record. Their installation script consisted of running code downloaded over HTTP (!!) through a root shell.
Yesterday, I wrote a posting "First version of this story did *not* mention DMCA" that gives my reasons for believing that Apple did not use the DMCA. If OWC wants to change my mind, they can show me the letter from Apple legal that mentions the DMCA.
Apple has not denied that they didn't do this and they had ample time for a denial. I am sure the reporters from C|Net contacted them about this. Unless you can provide evidence that this is not so, I will go with the published version of the story.
OWC was stealing Apple's work, against Apple's license, in order to compete with Apple in the DVD drive market. Apple is the victim here.
This doesn't change the fact that Apple used the DMCA to clobber them. I don't see how this is any different from sending a bunch of thugs down to OWC to take care of them.
OS X includes such well loved open source and free software as GCC, Emacs, Apache, and Perl.
Apple includes Free software in their OS. However, their contribution is much smaller than you think. In the early days, their modified the gcc compiler for Objective C and didn't release the changes. The changes were only released after a lot of pressure from the FSF. Add to this the fact that all the FreeBSD developers who are now Apple employees have left FreeBSD for good really questions Apples intentions.
I would have a lot more freedom if you stopped worrying about mine and concentrated on your own. The only time I find my freedom diminishing is when some idiot decides I need help.
Don't confuse actions of the Government with that of the individuals. I am sure you understand the differences between GPL and UCITA. Which one do you prefer?
People who don't learn from history are doomed to repeat it. If you saw the state of the software world when GPL was drawn up you would understand why it is the way it is. Even if you are doing this for fun and want to keep it informal, you will have to deal with these eventually. The problems don't go away just because you don't care about them. How would you defend yourself against some company like, say R*MBUS, which takes your code and patents everything in it and then sues you?
Endless iterations of the same traditional Unix toolset, tools for the server side, and attempts to mimic Office and the Windows interface, won't cut it. Be imaginative.
There are other programs out there and they are really creative. It so happens that the server side tools are the most popular. Just because they don't have multibillion dollar marketing budgets doesn't mean they don't exist.
When I've tried to explain Linux to people who make corporate buying decisions, their questions boil down to: Why buy a cheap knock-off when the real thing is available?
I am sorry you have to deal with such people. I am sure they are the ones running scared when the proprietary company they deal with has another licensing brainwave from stock market issues.
As I said in a post above, but I'll include it here incase you have any information, I've been over the APSL a few times already, and I don't see any place where it differs from the GPL in that respect, I don't see any requirements to notify Apple. Do you have any specific section links?
As has been mentioned before, if you deploy it within the company for your everyday operations, you will have to release the code under APSL, while you don't have to under the GPL.
I understand why they want to pick apart licenses, but not why they bother doing their complaining about old versions.
There is a lot of software released under old versions of the licenses. Unless of course they are GPL programs which declare themlselves under GPL version n or later.