Furthermore, requesting credit in a title is unreasonable. Linus himself said it best with, "Your midwife doesn't select the name of your babies." Could Linux have been built without GNU tools? Possible but unlikely. That does not, however, grant Mr. Stallman the right to name it.
Also, is this something that people really want in the browser? I mean, how many people use chat-specific protocols aside from IRC? I'm not really up on all of this stuff, so maybe there are like 20 often used chat protocols, but in my surfing, most people use already web-based solutions like java applets, constant-refreshes (annoying, IMHO), or forum based communication (ala slashdot or motley fool, etc.). I'm not sure if this is even a great idea.
I think this is entirely the point. People want to "live" in their web browser, because it provides a convenient, consistent interface to many forms of information. Because of this, they will use web-based chat clients, whether based on Java or annoying (and expensive) frequent refreshes, etc. Hence, it makes sense to integrate it into the browser cleanly rather than always using such clumsy interfaces. (However, it remains important to make it modular so people who aren't interested in the functionality don't get burdened with the overhead.)
Sure, 2.2.2 was listed as "stable", but common sense dictates that a shake-down period is likely to take place before it is really stable. Some bugs are subtle enough that it takes a lot of installations to bring them to light. However, many sites won't try to seriously use the new kernel versions until they are listed as "stable".
It's a chicken-and-egg problem; the kernel has to be listed as "stable" before many sites will risk it for heavy production use, and the more subtle bugs will evade detection until placed in heavy production use. Therefore, at some point, they just have to decide it's "good enough" and declare it a "stable" release, and fix whatever comes up.
Given that we don't even have a 2.3.x series yet, it should be fairly obvious that the early 2.2.x "stable" versions should still be taken with a grain of salt, for now. Yes, they're pretty stable and improving all the time. However, to expect them to be just as stable as 2.0.36, which has been in maintenance mode for years, is a bit unrealistic.
After 2.3.x kernels are rolling, and 2.2.x updates have stopped coming out for a few months, then the truly cautious sites will start to rely on 2.2.x kernels for mission-critical applications. The paranoid will stick with stable 2.0.x kernels and let the majority volunteer themselves as guinea pigs to debug the early 2.2.x kernels. (The less paranoid who can afford a small amount of instability are crucial to ironing out the little wrinkles to make a very stable kernel, as people have come to expect of Linux.)
That said, I think some mistakes were made in the 2.1.x -> 2.2.x transition. For example, major changes were introduced in the 2.2.0 "pre" series, which ought to have been strictly limited to fixing bugs. The changes to the VM system were a particular case in point here; a major overhaul of the VM system was applied in the 2.2.0 "pre" series, when it really belonged in an experimental kernel series.
The new VM code is significantly improved in general, but the bforget() bug slipped into the final 2.2.0 release and remained for several more releases until it was finally isolated and fixed. From the description of the bug and the comments in the Usenet News article attributed to Mindcraft, it seems quite clear that the Mindcraft people unknowingly crippled their Linux machine by using the 2.2.2 kernel with a serious performance bug that was yet undiscovered. No wonder the NT machine managed to win for once!
[...] We have Redhat 5.2 installed and compiled an SMP version of the 2.2.2 Linux kernel. [...] The problem: the server performs well, delivering in excess of 1300 HTTP GET requests per second. But then performance drops WAAAY off, like down to 70 connections per second. We're not swapping, the network isn't saturated (4 x 100Mbit nets), disks are hardly used, but the system is just crawling. If it were saturated then performance should level off, not drop like this. Neither vmstat nor top show anything unusual. No error messages in the web server. Its puzzling.
As pointed out by an astute poster elsewhere under this article, Linux 2.2.2 (which Mindcraft used) had a kernel bug in the buffer cache that would cause a significant loss of performance just as described above. Using a 2.2.x kernel was a little premature in this case, it seems. (Why didn't they also test 2.0.36?)
No doubt a repeat test with 2.2.5 and a proper Samba configuration would give more accurate results...
For example, one of the major recent changes to the kernel architecture was the migration from v2.0/early 2.1 with a single kernel lock to late 2.1/2.2 with multiple locks, to handle SMP better. I'm not a kernel internals expert by any stretch, but it seems like one of the major changes required for this was to make all the SCSI and Ethernet drivers aware of the various different types of kernel lock.
This could be viewed as a failing in the Linux driver interface. Ideally, the driver writer should not have to be concerned with changes to the kernel. Of course, this isn't so easy in practice. From a quick look at the HTML overview on the UDI website, one of the things that jumped out at me is that the UDI specification seems to shield driver writers from many details of OS implementation.
Take this change in kernel locking for SMP, for example. The UDI spec says that drivers don't deal with synchronization issues AT ALL. It uses a non-blocking execution model. The OS support for the UDI environment would have to deal with the change in kernel locking, but all UDI drivers would have continued to work without modification, at least in theory. Isn't this a valuable benefit for changing driver architectures?
I haven't read the actual UDI spec yet, but from the overview, it seems to be very well designed and thought out. It leaves a LOT of flexibility in the OS implementation, although it also appears to place a lot of the responsibility on the OS support code more than the driver. This seems reasonable to me; that code only has to be written once for each OS; if multitudes of drivers can be simplified and made more stable by putting more work into the OS support, isn't it prudent to do so?
One more thing: UDI drivers could be implemented in user space or kernel space; perhaps the Linux UDI implementation could be done in such a way as to provide protection of the system from a faulty driver? If a particular hardware vendor's driver keeps crashing, that vendor will get the blame, not Linux itself... Instead, Linux would get more credit than ever if the rest of the system can survive driver crashes. (Potentially, the kernel could even reinitialize crashed drivers automatically.)
You could release a UDI driver under GPL, but Windows or any other closed-source system could still use them, as long as their OS-side UDI support wasn't based on GPL code. If Microsoft implements UDI support for Windows based on the (public domain) UDI specification, that code is a derived work of that specification, not of the driver which is also derived from the same UDI specs.
Of course, if there is a special driver-specific interface that only exists on the GPL-covered driver, then an application or OS which uses those features would probably then be considered a derived work of the driver. Otherwise, you can't keep proprietary vendors from using your UDI drivers just by licensing them under the GPL. (They'd still have to distribute the source code of the UDI driver itself, of course, to comply with the GPL.)
Don't think a boycott of UDI would matter either; if a proprietary vendor supports UDI and wants to use your GPL-covered driver, they can always port your driver to the UDI interface. They'll have to release the sources to those changes, but they'd be free to use it for a proprietary system after that.
The genie is out of the bottle on this one. But I think it's a Good Thing (tm). After all, UDI driver compatibility is only guaranteed at the source level; some similar platforms may have binary compatibility, but Solaris/SPARC and Linux/x86 certainly won't be binary-compatible. This might actually encourage some vendors to release source to their UDI drivers for widest compatibility, when they might not have been inclined to release source code otherwise.
It is an inaccurate generalization to claim that all binary-only modules violate the GPL. Yes, the Linux kernel is licensed under the GPL. Yes, the implemention of OS support for UDI under Linux would be covered by the GPL. However, this does not mean that the GPL necessarily applies to UDI drivers.
Why is this? How can a binary driver be loaded into the GPL'd Linux kernel without violating the GPL? Simple. UDI drivers are not inherently derived from GPL-covered code. If the same UDI interface existed only under Linux, then implementing a driver to that interface would constitute a derived work, and subject that driver to the GPL's constraints.
Since UDI was developed independently and is being placed in the public domain, drivers written to the UDI interface are not subject to the GPL, even if you link them into the GPL-covered Linux kernel.
Legally, the key point is whether or not it constitutes a "derived work", not whether or not they are used together. The OS-side Linux UDI implementation would be a derived work of the UDI specification, but the UDI specification is not a derived work of Linux. A given UDI driver would be a derived work of the UDI specification as well, but not a derived work of Linux. Therefore, a binary-only UDI module running under Linux would not violate the GPL, even if you link that module statically into the kernel...
That said, if a particular UDI driver started out as a Linux kernel driver, then it would already be a derived work of Linux, therefore covered under the GPL. Of course, the author(s) could presumably change the license if the UDI version of the driver is no longer derived from the GPL-covered code. Third parties, however, could not relicense this way, even if the UDI version no longer contains any derived code.
Who said Microsoft would support UDI? They've got their own driver model.
Who says Microsoft needs to? Even if Microsoft refuses to support UDI, couldn't any third party use Microsoft's interface and create a driver that provides MicrosoftUDI translations to run UDI drivers under? This could be written once and used with many UDI drivers. (Obviously, direct OS support is always better, but it's not the only option here.)
There's a good chance that you've got the serial port speed set to 9600 baud talking to the modem, and that's the speed being reported by the CONNECT line. Make sure it's set to a higher speed, like 38400, 57600 or 115200. (Use the highest speed that actually works; modem compression may give you more than 28800 baud throughput.)
KDE is usefull and good, it could easily be made with GTK
If KDE could use GTK instead of QT "easily", why don't they? Then they wouldn't have to deal with the QT controversies. Somehow I doubt it's that simple.
So chill out, I was more annoyed about the bit on the PC Speaker driver. (there is a patch for it, but it has some issues with low-level timing which is why no one wanted to include it into the main source tree. But it worked just fine in 2.0, and probably still works. So unless you want to clean it up, either use the patch, or don't complain, no one with a soundcard really needs it anyhow.)
Is there some reason that patch couldn't be reworked into a sound module now? Then people would only have to deal with those timing issues if they choose to load the module. At least it would offer a least-common-denominator option for sound and help people with unsupported soundcards...
RMS accepts the QPL. I would guess there has never been a license besides GPL & LGPL that he really likes.
RMS likes the GPL, of course. I don't think he really likes the LGPL; it's a watered-down version of the GPL, which is what he really wants everyone to use. RMS probably considers the LGPL as a "necessary evil" that should be abolished in favor of the full GPL as soon as possible.
I seem to recall hearing (way back when) that RMS was very reluctant to release the LGPL, but eventually gave in and allowed it. (Notice that he always promotes the GPL over the LGPL.) No, I don't have a reference handy to substantiate that; it's just what I recall hearing or reading back when the LGPL was released.
I find it reprehensible that your company feels obliged to bully a small family owning the "veronica.org" domain name into giving up that name to your company. You already own "veronica.com" and don't even use it! More importantly, the trademark claim is meaningless. Trademarks only apply within a certain area, not across all of society.
If someone makes a comic character named "Veronica" that could be confused with yours, then pursue that for trademark infringement. Otherwise, don't flaunt your poor judgement and ignornance of trademark law by harassing people for any coincidental use of the name "Veronica" in a way that is clearly irrelevant to your comic character.
Any fool can see that your trademark claim to "veronica.org" is invalid. At best, this claim is gross negligence. At worst, it is fraudulent. Drop the issue, and hope that too many parents don't hear about this. Myself, I'm probably going to discourage my children from reading your comics as a result of this incident; I disapprove of any person or organization who acts in such a shoddy and shameful manner.
I seem to recall when CD's were first announced, it was said that within about 5 years (when the production costs dropped), that CD's would be available for $5 or less. The music industry conveniently forgot this promise when they realized that they could get away with continuing to charge $15 or more per CD, regardless of their actual costs.
And how much of that money actuall goes to the artist anyhow? Not much...
Oh, good. I was looking into this problem myself, but got tired and went home for a long weekend instead. (I'm building it on my desktop workstation at work, which is faster than my home machine.) I got as far as determining that the b_size (blocksize) parameter was set to 0, causing the error. The piece of code looked entirely new; I was tempted to comment it out.:-)
Does anyone know offhand what the fix was? Was it just an uninitialized data structure?
Slashdot Mirror
Also, I just found a wonderful quote in an article about the controversy which addresses this very well:
Also, is this something that people really want in the browser? I mean, how many people use chat-specific protocols aside from IRC? I'm not really up on all of this stuff, so maybe there are like 20 often used chat protocols, but in my surfing, most people use already web-based solutions like java applets, constant-refreshes (annoying, IMHO), or forum based communication (ala slashdot or motley fool, etc.). I'm not sure if this is even a great idea.
I think this is entirely the point. People want to "live" in their web browser, because it provides a convenient, consistent interface to many forms of information. Because of this, they will use web-based chat clients, whether based on Java or annoying (and expensive) frequent refreshes, etc. Hence, it makes sense to integrate it into the browser cleanly rather than always using such clumsy interfaces. (However, it remains important to make it modular so people who aren't interested in the functionality don't get burdened with the overhead.)
Sure, 2.2.2 was listed as "stable", but common sense dictates that a shake-down period is likely to take place before it is really stable. Some bugs are subtle enough that it takes a lot of installations to bring them to light. However, many sites won't try to seriously use the new kernel versions until they are listed as "stable".
It's a chicken-and-egg problem; the kernel has to be listed as "stable" before many sites will risk it for heavy production use, and the more subtle bugs will evade detection until placed in heavy production use. Therefore, at some point, they just have to decide it's "good enough" and declare it a "stable" release, and fix whatever comes up.
Given that we don't even have a 2.3.x series yet, it should be fairly obvious that the early 2.2.x "stable" versions should still be taken with a grain of salt, for now. Yes, they're pretty stable and improving all the time. However, to expect them to be just as stable as 2.0.36, which has been in maintenance mode for years, is a bit unrealistic.
After 2.3.x kernels are rolling, and 2.2.x updates have stopped coming out for a few months, then the truly cautious sites will start to rely on 2.2.x kernels for mission-critical applications. The paranoid will stick with stable 2.0.x kernels and let the majority volunteer themselves as guinea pigs to debug the early 2.2.x kernels. (The less paranoid who can afford a small amount of instability are crucial to ironing out the little wrinkles to make a very stable kernel, as people have come to expect of Linux.)
That said, I think some mistakes were made in the 2.1.x -> 2.2.x transition. For example, major changes were introduced in the 2.2.0 "pre" series, which ought to have been strictly limited to fixing bugs. The changes to the VM system were a particular case in point here; a major overhaul of the VM system was applied in the 2.2.0 "pre" series, when it really belonged in an experimental kernel series.
The new VM code is significantly improved in general, but the bforget() bug slipped into the final 2.2.0 release and remained for several more releases until it was finally isolated and fixed. From the description of the bug and the comments in the Usenet News article attributed to Mindcraft, it seems quite clear that the Mindcraft people unknowingly crippled their Linux machine by using the 2.2.2 kernel with a serious performance bug that was yet undiscovered. No wonder the NT machine managed to win for once!
[...]
We have Redhat 5.2 installed and compiled an SMP version of the 2.2.2 Linux kernel.
[...]
The problem: the server performs well, delivering in excess of 1300 HTTP GET requests per second. But then performance drops WAAAY off, like down to 70 connections per second. We're not swapping, the network isn't saturated (4 x 100Mbit nets), disks are hardly used, but the system is just crawling. If it were saturated then performance should level off, not drop like this. Neither vmstat nor top show anything unusual. No error messages in the web server. Its puzzling.
As pointed out by an astute poster elsewhere under this article, Linux 2.2.2 (which Mindcraft used) had a kernel bug in the buffer cache that would cause a significant loss of performance just as described above. Using a 2.2.x kernel was a little premature in this case, it seems. (Why didn't they also test 2.0.36?)
No doubt a repeat test with 2.2.5 and a proper Samba configuration would give more accurate results...
For example, one of the major recent changes to the kernel architecture was the migration from v2.0/early 2.1 with a single kernel lock to late 2.1/2.2 with multiple locks, to handle SMP better. I'm not a kernel internals expert by any stretch, but it seems like one of the major changes required for this was to make all the SCSI and Ethernet drivers aware of the various different types of kernel lock.
This could be viewed as a failing in the Linux driver interface. Ideally, the driver writer should not have to be concerned with changes to the kernel. Of course, this isn't so easy in practice. From a quick look at the HTML overview on the UDI website, one of the things that jumped out at me is that the UDI specification seems to shield driver writers from many details of OS implementation.
Take this change in kernel locking for SMP, for example. The UDI spec says that drivers don't deal with synchronization issues AT ALL. It uses a non-blocking execution model. The OS support for the UDI environment would have to deal with the change in kernel locking, but all UDI drivers would have continued to work without modification, at least in theory. Isn't this a valuable benefit for changing driver architectures?
I haven't read the actual UDI spec yet, but from the overview, it seems to be very well designed and thought out. It leaves a LOT of flexibility in the OS implementation, although it also appears to place a lot of the responsibility on the OS support code more than the driver. This seems reasonable to me; that code only has to be written once for each OS; if multitudes of drivers can be simplified and made more stable by putting more work into the OS support, isn't it prudent to do so?
One more thing: UDI drivers could be implemented in user space or kernel space; perhaps the Linux UDI implementation could be done in such a way as to provide protection of the system from a faulty driver? If a particular hardware vendor's driver keeps crashing, that vendor will get the blame, not Linux itself... Instead, Linux would get more credit than ever if the rest of the system can survive driver crashes. (Potentially, the kernel could even reinitialize crashed drivers automatically.)
Disclaimer: IANAL
You could release a UDI driver under GPL, but Windows or any other closed-source system could still use them, as long as their OS-side UDI support wasn't based on GPL code. If Microsoft implements UDI support for Windows based on the (public domain) UDI specification, that code is a derived work of that specification, not of the driver which is also derived from the same UDI specs.
Of course, if there is a special driver-specific interface that only exists on the GPL-covered driver, then an application or OS which uses those features would probably then be considered a derived work of the driver. Otherwise, you can't keep proprietary vendors from using your UDI drivers just by licensing them under the GPL. (They'd still have to distribute the source code of the UDI driver itself, of course, to comply with the GPL.)
Don't think a boycott of UDI would matter either; if a proprietary vendor supports UDI and wants to use your GPL-covered driver, they can always port your driver to the UDI interface. They'll have to release the sources to those changes, but they'd be free to use it for a proprietary system after that.
The genie is out of the bottle on this one. But I think it's a Good Thing (tm). After all, UDI driver compatibility is only guaranteed at the source level; some similar platforms may have binary compatibility, but Solaris/SPARC and Linux/x86 certainly won't be binary-compatible. This might actually encourage some vendors to release source to their UDI drivers for widest compatibility, when they might not have been inclined to release source code otherwise.
Disclaimer: IANAL (I Am Not A Lawyer.)
It is an inaccurate generalization to claim that all binary-only modules violate the GPL. Yes, the Linux kernel is licensed under the GPL. Yes, the implemention of OS support for UDI under Linux would be covered by the GPL. However, this does not mean that the GPL necessarily applies to UDI drivers.
Why is this? How can a binary driver be loaded into the GPL'd Linux kernel without violating the GPL? Simple. UDI drivers are not inherently derived from GPL-covered code. If the same UDI interface existed only under Linux, then implementing a driver to that interface would constitute a derived work, and subject that driver to the GPL's constraints.
Since UDI was developed independently and is being placed in the public domain, drivers written to the UDI interface are not subject to the GPL, even if you link them into the GPL-covered Linux kernel.
Legally, the key point is whether or not it constitutes a "derived work", not whether or not they are used together. The OS-side Linux UDI implementation would be a derived work of the UDI specification, but the UDI specification is not a derived work of Linux. A given UDI driver would be a derived work of the UDI specification as well, but not a derived work of Linux. Therefore, a binary-only UDI module running under Linux would not violate the GPL, even if you link that module statically into the kernel...
That said, if a particular UDI driver started out as a Linux kernel driver, then it would already be a derived work of Linux, therefore covered under the GPL. Of course, the author(s) could presumably change the license if the UDI version of the driver is no longer derived from the GPL-covered code. Third parties, however, could not relicense this way, even if the UDI version no longer contains any derived code.
Who said Microsoft would support UDI? They've got their own driver model.
Who says Microsoft needs to? Even if Microsoft refuses to support UDI, couldn't any third party use Microsoft's interface and create a driver that provides MicrosoftUDI translations to run UDI drivers under? This could be written once and used with many UDI drivers. (Obviously, direct OS support is always better, but it's not the only option here.)
There's a good chance that you've got the serial port speed set to 9600 baud talking to the modem, and that's the speed being reported by the CONNECT line. Make sure it's set to a higher speed, like 38400, 57600 or 115200. (Use the highest speed that actually works; modem compression may give you more than 28800 baud throughput.)
On most systems, that would be "/var/log/messages" rather than "/var/adm/messages". :-)
KDE is usefull and good, it could easily be made with GTK
If KDE could use GTK instead of QT "easily", why don't they? Then they wouldn't have to deal with the QT controversies. Somehow I doubt it's that simple.
So chill out, I was more annoyed about the bit on the PC Speaker driver. (there is a patch for it, but it has some issues with low-level timing which is why no one wanted to include it into the main source tree. But it worked just fine in 2.0, and probably still works. So unless you want to clean it up, either use the patch, or don't complain, no one with a soundcard really needs it anyhow.)
Is there some reason that patch couldn't be reworked into a sound module now? Then people would only have to deal with those timing issues if they choose to load the module. At least it would offer a least-common-denominator option for sound and help people with unsupported soundcards...
RMS accepts the QPL. I would guess there has never been a license besides GPL & LGPL that he really likes.
RMS likes the GPL, of course. I don't think he really likes the LGPL; it's a watered-down version of the GPL, which is what he really wants everyone to use. RMS probably considers the LGPL as a "necessary evil" that should be abolished in favor of the full GPL as soon as possible.
I seem to recall hearing (way back when) that RMS was very reluctant to release the LGPL, but eventually gave in and allowed it. (Notice that he always promotes the GPL over the LGPL.) No, I don't have a reference handy to substantiate that; it's just what I recall hearing or reading back when the LGPL was released.
Here's the story in their archives.
(Sorry about that last link; it was from a search and seems to have been a one-shot link.)
Here's the story in their archives.
To whom it may concern:
I find it reprehensible that your company feels obliged to bully a small family owning the "veronica.org" domain name into giving up that name to your company. You already own "veronica.com" and don't even use it! More importantly, the trademark claim is meaningless. Trademarks only apply within a certain area, not across all of society.
If someone makes a comic character named "Veronica" that could be confused with yours, then pursue that for trademark infringement. Otherwise, don't flaunt your poor judgement and ignornance of trademark law by harassing people for any coincidental use of the name "Veronica" in a way that is clearly irrelevant to your comic character.
Any fool can see that your trademark claim to "veronica.org" is invalid. At best, this claim is gross negligence. At worst, it is fraudulent. Drop the issue, and hope that too many parents don't hear about this. Myself, I'm probably going to discourage my children from reading your comics as a result of this incident; I disapprove of any person or organization who acts in such a shoddy and shameful manner.
I seem to recall when CD's were first announced, it was said that within about 5 years (when the production costs dropped), that CD's would be available for $5 or less. The music industry conveniently forgot this promise when they realized that they could get away with continuing to charge $15 or more per CD, regardless of their actual costs.
And how much of that money actuall goes to the artist anyhow? Not much...
Oh, good. I was looking into this problem myself, :-)
but got tired and went home for a long weekend instead. (I'm building it on my desktop workstation at work, which is faster than my home machine.) I got as far as determining that the b_size (blocksize) parameter was set to 0, causing the error. The piece of code looked entirely new; I was tempted to comment it out.
Does anyone know offhand what the fix was? Was it just an uninitialized data structure?