There are Open-Source-based systems for Aunt Tilly coming about. Firefox is a good example. But that's not the major driver of Open Source development. Use within business is.
The first reason is that spectrum regulation for VHF and higher frequencies is not, in general, carried out on a global basis. Part of this is historical, and part that governments and their people want more versatility than global spectrum allocation would offer. Regulation for the convenience of manufacturers isn't a good idea, because they can handle the economies of scale in a whole nation's worth of customers. Regulation for the sake of roving devices and their users is a good idea.
The second reason is that a nation's own manufacturers lobby for their system. All of the D-AMPS 800 MHz base stations now seem to have gone to GSM because they can get more voice channels out of a single cell. Not because of the tiny minority of their users who roam internationally.
But the question remains, how much actual source code alteration is going on by people outside of the dedicated development teams (meaning the users of the software, not the source code contributors)?
Well, I currently have a major investment bank requesting at least a quarter Million US dollars worth of work on Open Source tools, to make them better service their own needs. They have performed some of the work themselves, and are looking to contract some out. This stuff isn't unusual.
He did not produce his own distribution variant. He was working in rare or dead languages and religious symbology, and needed to input and reproduce those symbols. The MS system at the time wasn't versatile enough. I'm not sure that Windows fonts and keyboard maps would handle the problem today.
It's a fine story and no problem with your submitting it. But it starts the economic explanation with The source code may be free, but there is gold in software support, training and publishing. I'd like to get people to stop thinking about it as a vendor-driven phenomenon. There will still be money for Open Source development without vendor participation.
Never mind that I work for a company that does support (Sourcelabs), I do training, and I'm a publisher (Bruce Perens' Open Source Series):-)
Isn't a compiler essentially the ultimate tool of control?
Yes, if you want to sustain all of the cost and risk of development all by yourself. One of the main points of Open Source is that you can distribute that cost and risk among many parties.
Is "control" a euphemism for "incomplete"?
We have lots of finished software. And the world has square holes and round pegs. The people who finished that software never dreamed of a square hole.
As an example, I once met a Divinity Ph.D. who was using the Debian Linux distribution as a research tool. You can be darned sure that we had not planned on a divinity-friendly system when we made that release.
Sure, software can have scripting features that make it customizable. We used to believe that we could make "software ICs" using object-oriented programming and connect software stacks together as black boxes. But object-oriented programming did not achieve the level of reuse that people thought it would, because we never design the object for all possible needs. So, we need Open Source so that people can get at the pieces that need changing.
One of our main differentiators is control. Rather than sell 1/4 inch holes, we're selling the ability to drill the size of hole you want, and not be limited to the drill sizes they have at the store.
I do not believe that businesses with a product that is related to Open Source will be, or are, the main driver of Open Source software development. The companies that use Open Source software to get a job done, and that have a product that has nothing to do with Open Source, are the most important ones. If you trace the money that pays for software to its source, those folks are it - software vendors just work for them. All of those companies devote some money to writing non-differentiating, cost-center software. They can distribute the cost and risk of such development by using Open Source for all enabling, non-differentiating technology. I've written a paper that goes into this. You can read it here.
Then there are the problems with GPL that as far as I know nobody is interested in solving--like the fact that it's possible to take GPLed software and make it effectively proprietary, by locking it to proprietary hardware or data files.
There was actually a planning meeting around GPL, DRM, and other issues at a NY Linuxworld conference at least two years ago. At that meeting, I suggested license language regarding the right to modify the programming in an embedded device. The idea was accepted at that time, but I have no idea whether anyone else involved with the project has held on to the thread for all that time.
If there is one person I would trust with the best interests of software freedom, it would be RMS
Yes. The only problem with that is that he's done a piss-poor job regarding the GFDL. There is an anti-DRM provision so vague that it doesn't allow you to store GFDL documents on systems with login security and file permissions. If you look into that, you find that RMS actually doesn't approve of login security, so that might even be deliberate. That's the license that applies to the entire Wikipedia, and those folks don't yet realize how messed up the license is.
The most galling aspect has been RMS total unwillingness to come to the table with the Debian developers who wanted to work that out.
Eben says Richard knows that GPL 3 is more important than GFDL, and that he'll behave.
FSF intends to retire GPL 2 - which means not recommending it for new work. FSF also has, for much software, a transition path from GPL 2 to GPL 3, because of the line criticized elsewhere in this thread. And FSF recognizes real problems in the license that must be addressed. Also, FSF has deprecated LGPL in favor of GPL-with-exception, reducing the number of licenses one need deal with. So, IMO they are handling the combinatorial problem more responsibly than others.
To what extent will code licensed under V2 be compatible with code licensed under V3 and so on?
It is a goal for GPL 3 that it be compatible with GPL 2. But I'm not sure how this can be achieved while fixing some of the problems also on the goal list. Time will tell.
You are confusing democracy and free markets vs controlled markets. In a free market, someone else would sell Ice Cream for 15 cents, and you'd buy from him. In a controlled market, the price would be set at a level that would allow the ice cream maker to make a living. The ice cream maker is incented to increase efficiency in order to increase his margin. In the free market system, the market responds to that by lowering prices if all vendors can use the same efficiencies. In the controlled market system, the same may or may not happen.
Now, tell me which system you live in. In many cases, what we think is free market really isn't.
That line does indicate a lot of trust that the FSF won't screw you over. This trust is probably warranted. The one wild-card is RMS, and I simply don't see RMS screwing this up - he knows how much it means.
The text of the GPL is constrained to be the same everywhere, so that we don't get a million GPL flavors that aren't compatible with each other and increase the combinatorial problem, as happened with the Mozilla licenses. There must be more than a dozen Mozilla license variants now. They breed like tribbles, and are just as annoying.
Well, aroung 1998 Eric wrote a big list of business methods for Open Source in the Cathedral and the Bazaar. History has proven most of them to be not all that effective. However, Open Source gets paid for and will continue to be paid for. How? Read the paper I linked to.
I was assuming that Solaris will remain primarily as a server OS
One of the things we are learning from Linux is that "Server OS" may not be a valid concept. As I explained in another post, ports increase reliability because they hit bugs that aren't being exercised frequently enough on the platforms you already support. Running the same OS in a phone and a supercomputer does that job even better.
There's some warning in one of them about PCI possibly screwing up, with an email address to send bug reports to. Hardly fills you with confidence.
Solaris will see more of that on x86 if they are going to support all of the hoary old hardware out there. You can't have it all in one test lab. But I think we are also seeing a different definition of "stable" because of the rolling-release state of Linux 2.6. If that note is a month old, it means one thing. If it's half a year old and there have been point releases on that kernel version, it is closer to the definition of "stable" you are used to. You pick how risky you want to be.
When something new (like wireless) comes out, you need the latest kernel version in order to get something usable
Or, you need to get the driver from your distribution. The kernel team is not the only option and perhaps not the best if it's stability you crave. You can also get the driver from your vendor for an existing kernel, but I don't believe this is a good long-term practice.
Maybe I didn't explain that properly. The biggest weakness with Linux is that in order to install 3rd-party drivers, or to install patches from newer kernels in order to use new drivers, a C compiler is required.
Oh, that makes much more sense. Again, this is something your distribution might help with. Whether or not you use a C compiler might be a matter of how long you want to wait. But given that binary drivers create a long-term support nightmare, I don't think that making them easier would improve Linux. I was around when we first put Linux on an Itanium motherboard. There were very few video cards we could get to work. But anything that had driver source came right up.
There is lots of Windows hardware that will never get another driver update, because the vendor has perished or gone on to other things. Having the driver source means I won't have to deal with that hassle again.
Why? Did you expect that we'd not want to admit that you can't make money by selling Free Software? You can't. It's not a profit center. If you want to understand how its economics work. Look here.
The only architecture that Solaris could need to be ported to would be POWER. Other architectures such as ARM wouldn't really be necessary.
You should get out of the machine room sometime. It's a big world out there:-)
Windows backwards-compatibility is actually quite good, so I don't know where that came from. Why did you bring Windows into this anyway?
Because Windows does not have POSIX. If you need backward-compatibility in kernels, you shouldn't be calling stuff outside of POSIX.
There have been multiple security holes in 2.6. If you haven't rebooted then they have remained unpatched.
Debian's 2.6 kernel is enough revs back that only a few updates have been necessary.
These kernels are labelled as 'stable', yet still have problems.
This is because we let the users decide how stable they want to be. They have more or less stable choices, and they or the distribution they run finds one that works for them.
And a due to the nature of Linux, you either have to get the latest kernel to get the latest drivers for your hardware, or use a patch.
Hm. Maybe if I spent a lot of time at the computer store I'd have more driver issues. I'm not seeing them. Even for the HDTV reciever cards. You're only going to hit them if you have some brand-new device.
The fact that a C compiler is usually involved in all of this is quite inexcusable in what is supposed to be a kernel that can compete with industrial-strength UNIX.
This is poorly stated, as Solaris would of course use a C compiler. I used Sun's compilers at Pixar. There was lots of code Sun's C compiler could not handle efficiently or correctly, and no doubt Solaris was coded around the C compiler's deficiencies. But you are complaining that there have been changes in the compiler. We like having development in the compiler, and we know what compiler versions are rock-solid and what ones are on the bleeding edge. I don't see this as a problem.
You'll get zero argument from me, as far as the laptop/desktop/embedded stuff. Solaris has never been well-suited (or even an option) for those tasks, and I don't see it catching up to Linux in the near future, either.
Why not? Nobody thought it could be done. But it brings Linux a unique advantage. Systems programmers know that ports generally improve quality because they point out cases and uses the code didn't handle correctly. This is even more true when you try to develop a kernel that can handle a supercomputer and is efficient enough to run in a phone. The code that does that goes through pretty severe scrutiny - with the folks who don't want or need your feature demanding that it be modular, clean, and that it take nothing from the effectiveness of Linux on their platform. This is a kind of discipline that no kernel team has attempted until now.
"Serever" features will go in, but not in the form you are used to them. We recently got yet another kernel-to-userspace copy path submitted for security logging. The other kernel developers said enough!, and the people who want that interface are going over all of the dozen ways that we copy data from the kernel to user space and will end up merging them into one clean fast interface. That is how Linux development goes. Big machine features are being put in by cleaning up such features as bus hotplugging, and in a way that helps power management for PDAs. It takes a wider view than many systems programmers - or their managers - bring to the job.
Bruce
Re:Bruce Perens confims it ... Solaris is DYING
on
Debian GNU/Solaris
·
· Score: 1
Once again it appears "Bruce Perens" has a DSFG-approved license to get away with blatent trolling.
Explain why most of the RedHat and IBM enhancements to Linux have not made it into the Linux kernel?
The kernel team has extremely high standards. Code-for-pay to meet immediate goals generally does not meet them. Look into their interactions with any number of projects and you will see that what eventually gets into the kernel is extremely modular and easy for other people than its original developers to support. But it is not easy for most people to write that sort of code. However, every bit of that stuff written at Sun would get into Solaris.
Moreover, most companies just keep their additions to Linux in-house and proprietary.
These too would not meet the standards of the kernel team.
You hacked the open source BSD NYIT kernel in the 80's so you know it takes a lot more than source code to integrate these things into the kernel.
Well, BSD was much better at the time than Unix 32V, but it did not meet the standards that FreeBSD sets now. Nor Linux. I also hacked System V, SGI/MIPS and Sun kernels at Pixar. The quality did not meet that which Linux manifests today.
Oddly enough, Bruce, the BSD and Apache communities are full of "little guy" developers who do not feel they are being treated unfairly.
Yes, and I am happy that they are comfortable that way. But for the most part I won't be put a "gift" license on the code I pay for - that goes under a "share and share alike" license. If someone else pays me to do the code, I will be happy to place it under a "gift" license. I have recently done some Rails security work under BSD licensing, sponsored by Sourcelabs.
Slashdot Mirror
Bruce
The second reason is that a nation's own manufacturers lobby for their system. All of the D-AMPS 800 MHz base stations now seem to have gone to GSM because they can get more voice channels out of a single cell. Not because of the tiny minority of their users who roam internationally.
Bruce
Well, I currently have a major investment bank requesting at least a quarter Million US dollars worth of work on Open Source tools, to make them better service their own needs. They have performed some of the work themselves, and are looking to contract some out. This stuff isn't unusual.
Bruce
Bruce
Never mind that I work for a company that does support (Sourcelabs), I do training, and I'm a publisher (Bruce Perens' Open Source Series) :-)
Bruce
Yes, if you want to sustain all of the cost and risk of development all by yourself. One of the main points of Open Source is that you can distribute that cost and risk among many parties.
Is "control" a euphemism for "incomplete"?
We have lots of finished software. And the world has square holes and round pegs. The people who finished that software never dreamed of a square hole.
As an example, I once met a Divinity Ph.D. who was using the Debian Linux distribution as a research tool. You can be darned sure that we had not planned on a divinity-friendly system when we made that release.
Sure, software can have scripting features that make it customizable. We used to believe that we could make "software ICs" using object-oriented programming and connect software stacks together as black boxes. But object-oriented programming did not achieve the level of reuse that people thought it would, because we never design the object for all possible needs. So, we need Open Source so that people can get at the pieces that need changing.
Bruce
Bruce
Bruce
There was actually a planning meeting around GPL, DRM, and other issues at a NY Linuxworld conference at least two years ago. At that meeting, I suggested license language regarding the right to modify the programming in an embedded device. The idea was accepted at that time, but I have no idea whether anyone else involved with the project has held on to the thread for all that time.
Bruce
Yes. The only problem with that is that he's done a piss-poor job regarding the GFDL. There is an anti-DRM provision so vague that it doesn't allow you to store GFDL documents on systems with login security and file permissions. If you look into that, you find that RMS actually doesn't approve of login security, so that might even be deliberate. That's the license that applies to the entire Wikipedia, and those folks don't yet realize how messed up the license is.
The most galling aspect has been RMS total unwillingness to come to the table with the Debian developers who wanted to work that out.
Eben says Richard knows that GPL 3 is more important than GFDL, and that he'll behave.
Bruce
To what extent will code licensed under V2 be compatible with code licensed under V3 and so on?
It is a goal for GPL 3 that it be compatible with GPL 2. But I'm not sure how this can be achieved while fixing some of the problems also on the goal list. Time will tell.
Bruce
Now, tell me which system you live in. In many cases, what we think is free market really isn't.
Bruce
Bruce
Bruce
Yes, contracts can be copyrighted. And in addition, you don't get to change the license that someone else has put on their own work.
Bruce
Bruce
One of the things we are learning from Linux is that "Server OS" may not be a valid concept. As I explained in another post, ports increase reliability because they hit bugs that aren't being exercised frequently enough on the platforms you already support. Running the same OS in a phone and a supercomputer does that job even better.
There's some warning in one of them about PCI possibly screwing up, with an email address to send bug reports to. Hardly fills you with confidence.
Solaris will see more of that on x86 if they are going to support all of the hoary old hardware out there. You can't have it all in one test lab. But I think we are also seeing a different definition of "stable" because of the rolling-release state of Linux 2.6. If that note is a month old, it means one thing. If it's half a year old and there have been point releases on that kernel version, it is closer to the definition of "stable" you are used to. You pick how risky you want to be.
When something new (like wireless) comes out, you need the latest kernel version in order to get something usable
Or, you need to get the driver from your distribution. The kernel team is not the only option and perhaps not the best if it's stability you crave. You can also get the driver from your vendor for an existing kernel, but I don't believe this is a good long-term practice.
Maybe I didn't explain that properly. The biggest weakness with Linux is that in order to install 3rd-party drivers, or to install patches from newer kernels in order to use new drivers, a C compiler is required.
Oh, that makes much more sense. Again, this is something your distribution might help with. Whether or not you use a C compiler might be a matter of how long you want to wait. But given that binary drivers create a long-term support nightmare, I don't think that making them easier would improve Linux. I was around when we first put Linux on an Itanium motherboard. There were very few video cards we could get to work. But anything that had driver source came right up.
There is lots of Windows hardware that will never get another driver update, because the vendor has perished or gone on to other things. Having the driver source means I won't have to deal with that hassle again.
Bruce
Bruce
You should get out of the machine room sometime. It's a big world out there :-)
Windows backwards-compatibility is actually quite good, so I don't know where that came from. Why did you bring Windows into this anyway?
Because Windows does not have POSIX. If you need backward-compatibility in kernels, you shouldn't be calling stuff outside of POSIX.
There have been multiple security holes in 2.6. If you haven't rebooted then they have remained unpatched.
Debian's 2.6 kernel is enough revs back that only a few updates have been necessary.
These kernels are labelled as 'stable', yet still have problems.
This is because we let the users decide how stable they want to be. They have more or less stable choices, and they or the distribution they run finds one that works for them.
And a due to the nature of Linux, you either have to get the latest kernel to get the latest drivers for your hardware, or use a patch.
Hm. Maybe if I spent a lot of time at the computer store I'd have more driver issues. I'm not seeing them. Even for the HDTV reciever cards. You're only going to hit them if you have some brand-new device.
The fact that a C compiler is usually involved in all of this is quite inexcusable in what is supposed to be a kernel that can compete with industrial-strength UNIX.
This is poorly stated, as Solaris would of course use a C compiler. I used Sun's compilers at Pixar. There was lots of code Sun's C compiler could not handle efficiently or correctly, and no doubt Solaris was coded around the C compiler's deficiencies. But you are complaining that there have been changes in the compiler. We like having development in the compiler, and we know what compiler versions are rock-solid and what ones are on the bleeding edge. I don't see this as a problem.
Bruce
Why not? Nobody thought it could be done. But it brings Linux a unique advantage. Systems programmers know that ports generally improve quality because they point out cases and uses the code didn't handle correctly. This is even more true when you try to develop a kernel that can handle a supercomputer and is efficient enough to run in a phone. The code that does that goes through pretty severe scrutiny - with the folks who don't want or need your feature demanding that it be modular, clean, and that it take nothing from the effectiveness of Linux on their platform. This is a kind of discipline that no kernel team has attempted until now.
"Serever" features will go in, but not in the form you are used to them. We recently got yet another kernel-to-userspace copy path submitted for security logging. The other kernel developers said enough!, and the people who want that interface are going over all of the dozen ways that we copy data from the kernel to user space and will end up merging them into one clean fast interface. That is how Linux development goes. Big machine features are being put in by cleaning up such features as bus hotplugging, and in a way that helps power management for PDAs. It takes a wider view than many systems programmers - or their managers - bring to the job.
Bruce
A license to kill too, AC!
Who's that at your door? AAAAAArgh!
Bruce
The kernel team has extremely high standards. Code-for-pay to meet immediate goals generally does not meet them. Look into their interactions with any number of projects and you will see that what eventually gets into the kernel is extremely modular and easy for other people than its original developers to support. But it is not easy for most people to write that sort of code. However, every bit of that stuff written at Sun would get into Solaris.
Moreover, most companies just keep their additions to Linux in-house and proprietary.
These too would not meet the standards of the kernel team.
You hacked the open source BSD NYIT kernel in the 80's so you know it takes a lot more than source code to integrate these things into the kernel.
Well, BSD was much better at the time than Unix 32V, but it did not meet the standards that FreeBSD sets now. Nor Linux. I also hacked System V, SGI/MIPS and Sun kernels at Pixar. The quality did not meet that which Linux manifests today.
Bruce
Yes, and I am happy that they are comfortable that way. But for the most part I won't be put a "gift" license on the code I pay for - that goes under a "share and share alike" license. If someone else pays me to do the code, I will be happy to place it under a "gift" license. I have recently done some Rails security work under BSD licensing, sponsored by Sourcelabs.
Bruce