The options you need are enabled by default, but, due to the fact that CONFIG_INPUT in 2.4 is a bit obscure, but in 2.6 those options depend on CONFIG_INPUT, people coming from 2.4 and using "make oldconfig" will find that they've turned them off without realizing. Unfortunately, there's no way to tell the configuration system that an option has increased in importance between kernel versions.
It's a matter of packaging. People are generally willing to install a new thingy if they think it will improve their computer experience. In order to defeat IE in the browser war, it is necessary to provide people with something they can get installed using a single interactive act. People are willing to install a plug-in from some random site they've never heard of, but they won't install Mozilla, simply because Mozilla doesn't appear to be a plug-in. Nobody wants to Switch Browsers, but they'd be perfectly happy if the next time they start their browser, it's different and better (although they may be confused if they don't have to reboot).
If someone were to package Mozilla as a single download and automatic install, such that it would be preconfigured to be similar to IE but better and set itself as the default, labelled the link "upgrade your browser", and listed it separately as a plug-in to block pop-ups, a plug-in to stop crashes, and a plug-in to make pages look nicer, lots of people would "upgrade". They probably wouldn't realize they weren't using IE, but that just dilutes MicroSoft's trademark.
What good are anti-piracy lawyers without much sympathy for people who created copyrighted works all day? Or, less tongue-in-check, what are the DoJ's plans for protecting content-producing individuals against multi-nationals and industry organizations that might want to profit from those works without compensating the individuals?
Two armed guards is obscurity, because they don't work too well if the attacker knows them.
The barbed wire fence is a different concept, in that it serves to cut off access by some routes entirely. Of course, it can't block all access, since you probably intend authorized people to get through. So it mainly comes down to knowing where the gate is and how to open it.
But all security boils down to information (or equipment encoding information) which identifies authorized parties, with a extra bit in blocking routes you don't intend to be used at all; authorization information has to be kept obscure, which means that it must be hard to acquire and it must be hard to probe the system for it.
Hmm... I suspect that every executive of an RIAA company has personally violated my copyright. I suspect that all of the German legislators have, too. Perhaps you suspect something similar...
Of course, some RIAA companies have been convicted of massive copyright violation in the past (on song lyrics, for which they failed to pay royalties to the owners), so it wouldn't be too surprising if they actually had copyright violations sufficient to put them away for life.
Actually, security through obscurity is the only kind of security there is. However, anything you send to every American anywhere, over possibly insecure overseas networks, is not, by definition, obscure. Things which are obscure are my private keys, my passwords, and software I have deployed only on trusted machines with restricted access to the files containing the software. Windows, and widely distributed Windows software, is merely confusing.
Be sure to check whether Dean will need your vote (in the general election). If not, voting third party gives the candidates a better idea of your views, and shows you care more about the issues than you do about voting for the winner.
I've never voted for a major party presidental candidate, but my electoral votes have always gone to the major party candidate I thought was best. I suspect that Dean's platform is in part a response to the evidence that the left-wing voters have been unhappy with the Democrat platforms, and have been voting third party. If left-leaning voters vote Dem even when it's not necessary, the Dems will be only stay slightly left of the Republicans, and significantly right of their actual voters.
Actually, naming it "2.6-rc1" will be sufficient to get the distros to test it, which is a substantial ammount of testing. On the other hand, it's not nearly ready for even this; getting tons of bug reports isn't helpful when you already know about a lot of important bugs.
And bugs don't actually get fixed more effectively when people are complaining and pressuring the maintainer; remember that it was mid teens in the 2.4 series where the version that was totally broken got released. 2.4.1 was actually reasonably good, and, up to about 10, there are a number of reasonable kernels which work fine under most workloads.
Those are milliseconds, not microseconds. 50 seconds to package, 15 minutes to get it picked up, 83 hours (a typo, I hope) to get it to the depot.
Of course, the "packet loss 100%" line is clearly wrong, since traceroute only gives you times when packets arrive back. We've got at least one package which made it to the depot and back to the sender, one the sender swiped back from the UPS guy, and one the clerk wrapped up and then immediately unwrapped.
The reason we're not getting any response beyond that is probably that the other end ignores TTL at the mailroom, and probably has transmission disabled. Either that, or the UPS guy has caught on, and rejected the package labelled "Recipient: have this package returned to sender".
If you turn off the ringer on your phone and hold the receiver, and somebody calls you, it doesn't give you a shock. If you do they same thing with a Vaio, it does.
The issue is not that your phone line can give you a shock, it's that your laptop case can become connected to it through the jack.
Generally, phone equipment tries to avoid putting the ring voltage anywhere you can touch it easily (note that your standard connector has recessed contacts).
You'll probably never see $25 hard drives, because there's a substantial cost to the parts of the hard drive that aren't storage. Regardless of the storage capacity of the platters and the precision of the heads, you'll always have a motor spinning the disks really fast and evenly, which costs money. This means that mid-range disks are more cost-effective than either high-end or low-end disks. Prices are really like $20 + $1/GB (until you get to the capacity limits), so you're not going to see less than ~$40 hard drives, where you're paying about as much for storage as you are for overhead.
Similarly, there's a cost to producing DIMMs which is unrelated to the size and speed, in addition to costs for making it large and fast.
On the other hand, low power and small physical size are reasonable features, which is why, if you want a 1 GB hard drive, it'll burn a milliwatt/MB and be 6 cubic centimeters, and cost $300. You can trade off speed and capacity for efficiency and size, but not cost.
Personally, what I'd like to see would be a desktop computer with laptop components. If the power fails, it'll play DVDs for two hours before suspending itself cleanly.
Of course it's legal. If it weren't legal, then there wouldn't be any privacy concerns for this sort of tracking technology: you could just get whoever used it on you arrested. What is troubling is the things which are legal but could nonetheless harm people.
There are two reasons that stores don't track people now: it would piss people off, and they would stop buying things; and it's impractical to follow a useful number of people around. Both of those issues are largely addressed by an unobtrusive tagging technology like RFID. On the other hand, RFID still generates sufficient bad press that stores are unwilling to use it in ways that could be seen as preparing to track customers. But people have to actually generate this opposition to being tracked, because impracticality won't be a barrier for long, and there is substantial risk to being tracked.
Personally, I think that RFID should be used like the current EAS stuff (the tags that set off the alarm if they aren't deactivated). Set up the registers to deactivate the tag when it's scanned, and the only active RFID tags your customers get from your store are ones on stolen items (unless the cashier fails to deactivate the tag, and the alarm isn't on).
As far as the cost to the customer, this should allow the stores computers to track merchandise significantly better, so that the register can follow the transaction; you can take the item out of the store only if you've paid for it, and, if you've paid for it, the tag must be deactivated. Currently, this relies heavily on employees doing things right: identifying the item correctly, identifying the right quantity of items, deactivating the tag successfully, and so forth; accordingly, employee error is a large source of loss to stores and inconvenience to customers.
The issue is that every Zellers Cheroke jacket looks pretty much the same, but jackets with RFID tags in them will be totally unique. So they can notice that the same jacket is buying a variety of different products on different occasions, or usually just tries things on, or so forth.
Obviously, just by looking at the branding, they can't tell the difference between different people who happen to wear the same thing on different occasions.
David Boies has only signed on to prove that IBM violated the terms of some private contract between SCO and IBM. SCO continuing to publish Linux after claiming infringement has no bearing at all on this question. SCO's claims, aside from this one issue, are merely press releases and personal comments intended to make SCO stock worth more; this doesn't require a legitimate legal defense for their actions, or even a legitimate justification of their claims.
Linux will certainly be unaffected by the outcome of the SCO v. IBM suit, because it is not a party to the suit. SCO would have a number of problems bringing an IP-related lawsuit against someone over Linux, which is what would be required to have any effect legally on Linux; they don't seem to own any IP of significance, they've licensed any IP they do have to everyone, and they've refused to identify any IP they might own.
I think that people's confusion actually comes from dumbing down marketting material. If the only things you get are the jargon-filled technical specifications (assuming you get them at all) and vague claims, you don't get any information that's actually useful if you don't know the jargon. So you end up misunderstanding the jargon, because you're forced to use it if you want to have any idea what the thing does.
The need is for some simple sufficiently general terms. Processor speed isn't a useful concept to end users, because the speed they'll see is related to a number of other things. Horsepower is a benchmark of overall performance; it relates to the ability to turn the wheels. Processor speed is more like engine displacement; sure, increasing it increases horsepower, but not in a really direct way. It would be much more sensible to end users to give benchmark results.
File formats aren't really that important to end users. Calling things MP3s isn't terribly useful; what's important is that they're audio files. People have the tendancy to make overly-specific terms generic if they lack a common generic, which is why we're likely to have people whose MP3 collections will eventually include WMA files, Vorbis files, and WAV files. (Ogg is actually particularly bad here, because an "Ogg" file could do at least 3 different things; "I'm trying to play this Ogg file on my car stereo, and it's not doing anything." "That's because it's only video." "How can I tell?")
The parts ought to be referred to in general terms. The big black/beige box is the "box". The thing you look at is the screen. The box has "drives" for various things in the front, and "ports" for various things in the back. For some things, the "ports" are inside the box (IDE, PCI, and such). There are a bunch of types of ports; the only thing you need to know about these are that the thing you're plugging in has to match what you're plugging it into (don't bother learning what "USB" stands for; it may be worth knowing that USB is flat, thin, and about half an inch, and has a symbol like a sideways cactus, as opposed to the inch-long trapezoid with the 10101). For that matter, you should know that speakers and mice are green, keyboards are purple, microphones are red, and nothing you're likely to want is blue.
It's actually a common problem in design that designers try to make complicated things simple for end users, but fail to understand end users and end up with something where all of the information necessary to know what you're doing has been "simplified" out, leaving a device which has few controls, but makes no sense. Office phones have had this problem for a while; they originally had buttons for the various features. This was thought to be too complicated, so they changed it to a single button which does everything when you perform a series of strange rituals.
For the memory vs. disk space question, I'd say that it's like a CD changer vs. a CD rack. If you have a 6 CD changer, you can put in 6 CDs at the same time; if you have a 20 CD rack, you can keep 20 CDs in it. If you have a 3 CD changer and a 20 CD rack, and you want to listen to songs off of 5 CDs shuffled together, you're going to have to do a lot of moving CDs around, and it's going to be a pain.
I doubt Quake 2 is actually very informative about the actual process of firing a machine gun. But it may have taught you a lot about staying out of sight while moving around, and about exploring unknown terrain.
It's been done several times for initialization, but it would be interesting to do it for driver API calls. The issue is that the driver manufacturers are going to do some rendering prepasses in the driver before sending stuff to the graphics card, and they want to hide the details of the algorithms they're using in the driver. If people don't want to run code with kernel permissions without source, a virtual machine with sandbox is ideal; of course, performance is also critical here, which makes it a very hard thing to design.
So there's actually code owned by SCO, stolen, and placed in the Linux kernel with SCO copyright disclaimers? Or is SCO claiming that they own somebody else's copyright disclaimers?
Looking at a development codebase is, in fact, the entire point of the exercise, according to the article. They wanted to determine whether Open Source is effective at fixing bugs, or effctive at not generating them in the first place, in response to questions about the previous study they did in which they found that Open Source production code was remarkably free of bugs. As it turns out, everybody's code is initially of approximately equal quality, but Open Source code gets substantially better over time, while proprietary software doesn't improve as much.
It's amazing how many people have managed to figure out what the article says without reading it.
But Linksys didn't have to release anything particularly proprietary, and didn't. They only had to release the code which was already public (or, rather, they had to acknowledge it), and any changes they made to that code. They wrote their own drivers and scripts, and didn't release those.
Of course, if they'd changed any of the GPL code, they'd have to release their changes. But Linux already makes a perfectly good router without any modifications, if you provide drivers for the hardware.
The issue is that much hardware was originally designed to have access, through drivers, to the CPU, such that the API that developers see is easy to understand, and so that the hardware manufacturer doesn't have to put all of their technology in chips on their hardware.
They have proprietary (and licensed) technology in the form of software which they can't release; this isn't fundamentally different from having chip designs they can't or won't release, except that it is tied to a particular operating system.
The solution, probably, is to move to less functionality in the driver and more in the chipset, so that no proprietary technology remains in the driver, and the driver simply passes all the API calls off to the hardware.
On the other hand, it would be interesting for somebody to write an API for proprietary drivers, such that they can run on a virtual machine on any platform. (This is actually not all that different from some aspects of ACPI, in that you end up running a bit of code sent from the hardware); then manufacturers could provide a driver which works on different platforms, is coded to a standard, and the system would be protected against bugs in the drivers (except for them locking the system bus or such).
First of all, there are going to be a lot of kernels which start 2.6 before 2.6.0, due to the whole stabilization process. Secondly, I think that distros will have a more substantial role in testing the kernels than they have in the past, relative to individual users, so the big stress tests will come when IBM, Red Hat, and Oracle pick up 2.6-pre1 to test; in the past, the big stress tests came when 2.4.0 got a lot of end users to start testing. Third, Andrew Morton is intending to be a release engineer, which Linus has done badly in the past (that not being what his style is good for), which will mean that 2.6.0 will be carefully tested, unlike previous.0 versions.
Of course, this is due to evolution is the process of releasing stable series kernels, not evolution in the kernel code itself; through the middle of 2.5, everything got broken, and has now mostly been fixed.
That's why there's going to be a substantial 2.6-pre series, and why Andrew Morton is going to be the one to release 2.6.0. The goal is for 2.6.0 to be a production release, which means that 2.6.0 can't be the first 2.6 kernel. Fortunately, kernel versioning supports the creation of 2.6 kernels which are before 2.6.0, and Linus understands that his skills are not in release management.
The real step needed for stability is testing by a wide variety of people. This should actually be easier to get than in the past, since a much larger portion of the front-line testing these days is done by the various distributions, who are not getting into the "enterprise software" business, where they have to do substantial research on whether the software works on different systems before releasing it. And distributions are generally a lot closer to the development process than random individual users are, so they can be more easily convinced to start testing a stable series in advance of the.0 release. Furthermore, there's a lot more testing and verification infrastructure these days than in the past, from the Stanford checker (which catches a lot of unsafe usages in obscure drivers without having the hardware necessary to actually run them) to various test labs.
There's actually quite a bit more effort put into making sure that end users get a stable kernel these days than in the past, as more business software companies promote Linux more heavily. IBM will make sure that they know at all times the status of 2.6 kernels with respect to any bugs that can be triggered on any of the hardware IBM ships, and they'll make sure that Linus and Andrew know whether a kernel is suitable for 2.6.0, at least from IBM's perspective.
The real question is whether Linus will manage to hold off starting the 2.7 series until 2.6.0 is released. (Personally, I doubt it; I bet Linus will want to release 2.6.0 before Andrew is willing to, and I bet Linus will decide that the current version may not be good enough for production, but it is good enough to start further development, and Andrew will agree that people who want to work on 2.7 aren't going to do anything more useful for the remaining 2.6 problems at that point)
Slashdot Mirror
The options you need are enabled by default, but, due to the fact that CONFIG_INPUT in 2.4 is a bit obscure, but in 2.6 those options depend on CONFIG_INPUT, people coming from 2.4 and using "make oldconfig" will find that they've turned them off without realizing. Unfortunately, there's no way to tell the configuration system that an option has increased in importance between kernel versions.
It's a matter of packaging. People are generally willing to install a new thingy if they think it will improve their computer experience. In order to defeat IE in the browser war, it is necessary to provide people with something they can get installed using a single interactive act. People are willing to install a plug-in from some random site they've never heard of, but they won't install Mozilla, simply because Mozilla doesn't appear to be a plug-in. Nobody wants to Switch Browsers, but they'd be perfectly happy if the next time they start their browser, it's different and better (although they may be confused if they don't have to reboot).
If someone were to package Mozilla as a single download and automatic install, such that it would be preconfigured to be similar to IE but better and set itself as the default, labelled the link "upgrade your browser", and listed it separately as a plug-in to block pop-ups, a plug-in to stop crashes, and a plug-in to make pages look nicer, lots of people would "upgrade". They probably wouldn't realize they weren't using IE, but that just dilutes MicroSoft's trademark.
What good are anti-piracy lawyers without much sympathy for people who created copyrighted works all day? Or, less tongue-in-check, what are the DoJ's plans for protecting content-producing individuals against multi-nationals and industry organizations that might want to profit from those works without compensating the individuals?
Two armed guards is obscurity, because they don't work too well if the attacker knows them.
The barbed wire fence is a different concept, in that it serves to cut off access by some routes entirely. Of course, it can't block all access, since you probably intend authorized people to get through. So it mainly comes down to knowing where the gate is and how to open it.
But all security boils down to information (or equipment encoding information) which identifies authorized parties, with a extra bit in blocking routes you don't intend to be used at all; authorization information has to be kept obscure, which means that it must be hard to acquire and it must be hard to probe the system for it.
Hmm... I suspect that every executive of an RIAA company has personally violated my copyright. I suspect that all of the German legislators have, too. Perhaps you suspect something similar...
Of course, some RIAA companies have been convicted of massive copyright violation in the past (on song lyrics, for which they failed to pay royalties to the owners), so it wouldn't be too surprising if they actually had copyright violations sufficient to put them away for life.
Actually, security through obscurity is the only kind of security there is. However, anything you send to every American anywhere, over possibly insecure overseas networks, is not, by definition, obscure. Things which are obscure are my private keys, my passwords, and software I have deployed only on trusted machines with restricted access to the files containing the software. Windows, and widely distributed Windows software, is merely confusing.
Be sure to check whether Dean will need your vote (in the general election). If not, voting third party gives the candidates a better idea of your views, and shows you care more about the issues than you do about voting for the winner.
I've never voted for a major party presidental candidate, but my electoral votes have always gone to the major party candidate I thought was best. I suspect that Dean's platform is in part a response to the evidence that the left-wing voters have been unhappy with the Democrat platforms, and have been voting third party. If left-leaning voters vote Dem even when it's not necessary, the Dems will be only stay slightly left of the Republicans, and significantly right of their actual voters.
You're a month out of date; it went into 2.4.22-pre2.
Actually, naming it "2.6-rc1" will be sufficient to get the distros to test it, which is a substantial ammount of testing. On the other hand, it's not nearly ready for even this; getting tons of bug reports isn't helpful when you already know about a lot of important bugs.
And bugs don't actually get fixed more effectively when people are complaining and pressuring the maintainer; remember that it was mid teens in the 2.4 series where the version that was totally broken got released. 2.4.1 was actually reasonably good, and, up to about 10, there are a number of reasonable kernels which work fine under most workloads.
Those are milliseconds, not microseconds. 50 seconds to package, 15 minutes to get it picked up, 83 hours (a typo, I hope) to get it to the depot.
Of course, the "packet loss 100%" line is clearly wrong, since traceroute only gives you times when packets arrive back. We've got at least one package which made it to the depot and back to the sender, one the sender swiped back from the UPS guy, and one the clerk wrapped up and then immediately unwrapped.
The reason we're not getting any response beyond that is probably that the other end ignores TTL at the mailroom, and probably has transmission disabled. Either that, or the UPS guy has caught on, and rejected the package labelled "Recipient: have this package returned to sender".
If you turn off the ringer on your phone and hold the receiver, and somebody calls you, it doesn't give you a shock. If you do they same thing with a Vaio, it does.
The issue is not that your phone line can give you a shock, it's that your laptop case can become connected to it through the jack.
Generally, phone equipment tries to avoid putting the ring voltage anywhere you can touch it easily (note that your standard connector has recessed contacts).
You'll probably never see $25 hard drives, because there's a substantial cost to the parts of the hard drive that aren't storage. Regardless of the storage capacity of the platters and the precision of the heads, you'll always have a motor spinning the disks really fast and evenly, which costs money. This means that mid-range disks are more cost-effective than either high-end or low-end disks. Prices are really like $20 + $1/GB (until you get to the capacity limits), so you're not going to see less than ~$40 hard drives, where you're paying about as much for storage as you are for overhead.
Similarly, there's a cost to producing DIMMs which is unrelated to the size and speed, in addition to costs for making it large and fast.
On the other hand, low power and small physical size are reasonable features, which is why, if you want a 1 GB hard drive, it'll burn a milliwatt/MB and be 6 cubic centimeters, and cost $300. You can trade off speed and capacity for efficiency and size, but not cost.
Personally, what I'd like to see would be a desktop computer with laptop components. If the power fails, it'll play DVDs for two hours before suspending itself cleanly.
Of course it's legal. If it weren't legal, then there wouldn't be any privacy concerns for this sort of tracking technology: you could just get whoever used it on you arrested. What is troubling is the things which are legal but could nonetheless harm people.
There are two reasons that stores don't track people now: it would piss people off, and they would stop buying things; and it's impractical to follow a useful number of people around. Both of those issues are largely addressed by an unobtrusive tagging technology like RFID. On the other hand, RFID still generates sufficient bad press that stores are unwilling to use it in ways that could be seen as preparing to track customers. But people have to actually generate this opposition to being tracked, because impracticality won't be a barrier for long, and there is substantial risk to being tracked.
Personally, I think that RFID should be used like the current EAS stuff (the tags that set off the alarm if they aren't deactivated). Set up the registers to deactivate the tag when it's scanned, and the only active RFID tags your customers get from your store are ones on stolen items (unless the cashier fails to deactivate the tag, and the alarm isn't on).
As far as the cost to the customer, this should allow the stores computers to track merchandise significantly better, so that the register can follow the transaction; you can take the item out of the store only if you've paid for it, and, if you've paid for it, the tag must be deactivated. Currently, this relies heavily on employees doing things right: identifying the item correctly, identifying the right quantity of items, deactivating the tag successfully, and so forth; accordingly, employee error is a large source of loss to stores and inconvenience to customers.
The issue is that every Zellers Cheroke jacket looks pretty much the same, but jackets with RFID tags in them will be totally unique. So they can notice that the same jacket is buying a variety of different products on different occasions, or usually just tries things on, or so forth.
Obviously, just by looking at the branding, they can't tell the difference between different people who happen to wear the same thing on different occasions.
David Boies has only signed on to prove that IBM violated the terms of some private contract between SCO and IBM. SCO continuing to publish Linux after claiming infringement has no bearing at all on this question. SCO's claims, aside from this one issue, are merely press releases and personal comments intended to make SCO stock worth more; this doesn't require a legitimate legal defense for their actions, or even a legitimate justification of their claims.
Linux will certainly be unaffected by the outcome of the SCO v. IBM suit, because it is not a party to the suit. SCO would have a number of problems bringing an IP-related lawsuit against someone over Linux, which is what would be required to have any effect legally on Linux; they don't seem to own any IP of significance, they've licensed any IP they do have to everyone, and they've refused to identify any IP they might own.
I think that people's confusion actually comes from dumbing down marketting material. If the only things you get are the jargon-filled technical specifications (assuming you get them at all) and vague claims, you don't get any information that's actually useful if you don't know the jargon. So you end up misunderstanding the jargon, because you're forced to use it if you want to have any idea what the thing does.
The need is for some simple sufficiently general terms. Processor speed isn't a useful concept to end users, because the speed they'll see is related to a number of other things. Horsepower is a benchmark of overall performance; it relates to the ability to turn the wheels. Processor speed is more like engine displacement; sure, increasing it increases horsepower, but not in a really direct way. It would be much more sensible to end users to give benchmark results.
File formats aren't really that important to end users. Calling things MP3s isn't terribly useful; what's important is that they're audio files. People have the tendancy to make overly-specific terms generic if they lack a common generic, which is why we're likely to have people whose MP3 collections will eventually include WMA files, Vorbis files, and WAV files. (Ogg is actually particularly bad here, because an "Ogg" file could do at least 3 different things; "I'm trying to play this Ogg file on my car stereo, and it's not doing anything." "That's because it's only video." "How can I tell?")
The parts ought to be referred to in general terms. The big black/beige box is the "box". The thing you look at is the screen. The box has "drives" for various things in the front, and "ports" for various things in the back. For some things, the "ports" are inside the box (IDE, PCI, and such). There are a bunch of types of ports; the only thing you need to know about these are that the thing you're plugging in has to match what you're plugging it into (don't bother learning what "USB" stands for; it may be worth knowing that USB is flat, thin, and about half an inch, and has a symbol like a sideways cactus, as opposed to the inch-long trapezoid with the 10101). For that matter, you should know that speakers and mice are green, keyboards are purple, microphones are red, and nothing you're likely to want is blue.
It's actually a common problem in design that designers try to make complicated things simple for end users, but fail to understand end users and end up with something where all of the information necessary to know what you're doing has been "simplified" out, leaving a device which has few controls, but makes no sense. Office phones have had this problem for a while; they originally had buttons for the various features. This was thought to be too complicated, so they changed it to a single button which does everything when you perform a series of strange rituals.
For the memory vs. disk space question, I'd say that it's like a CD changer vs. a CD rack. If you have a 6 CD changer, you can put in 6 CDs at the same time; if you have a 20 CD rack, you can keep 20 CDs in it. If you have a 3 CD changer and a 20 CD rack, and you want to listen to songs off of 5 CDs shuffled together, you're going to have to do a lot of moving CDs around, and it's going to be a pain.
I doubt Quake 2 is actually very informative about the actual process of firing a machine gun. But it may have taught you a lot about staying out of sight while moving around, and about exploring unknown terrain.
If they weren't using it, they probably wouldn't care so much.
It's been done several times for initialization, but it would be interesting to do it for driver API calls. The issue is that the driver manufacturers are going to do some rendering prepasses in the driver before sending stuff to the graphics card, and they want to hide the details of the algorithms they're using in the driver. If people don't want to run code with kernel permissions without source, a virtual machine with sandbox is ideal; of course, performance is also critical here, which makes it a very hard thing to design.
So there's actually code owned by SCO, stolen, and placed in the Linux kernel with SCO copyright disclaimers? Or is SCO claiming that they own somebody else's copyright disclaimers?
Looking at a development codebase is, in fact, the entire point of the exercise, according to the article. They wanted to determine whether Open Source is effective at fixing bugs, or effctive at not generating them in the first place, in response to questions about the previous study they did in which they found that Open Source production code was remarkably free of bugs. As it turns out, everybody's code is initially of approximately equal quality, but Open Source code gets substantially better over time, while proprietary software doesn't improve as much.
It's amazing how many people have managed to figure out what the article says without reading it.
But Linksys didn't have to release anything particularly proprietary, and didn't. They only had to release the code which was already public (or, rather, they had to acknowledge it), and any changes they made to that code. They wrote their own drivers and scripts, and didn't release those.
Of course, if they'd changed any of the GPL code, they'd have to release their changes. But Linux already makes a perfectly good router without any modifications, if you provide drivers for the hardware.
The issue is that much hardware was originally designed to have access, through drivers, to the CPU, such that the API that developers see is easy to understand, and so that the hardware manufacturer doesn't have to put all of their technology in chips on their hardware.
They have proprietary (and licensed) technology in the form of software which they can't release; this isn't fundamentally different from having chip designs they can't or won't release, except that it is tied to a particular operating system.
The solution, probably, is to move to less functionality in the driver and more in the chipset, so that no proprietary technology remains in the driver, and the driver simply passes all the API calls off to the hardware.
On the other hand, it would be interesting for somebody to write an API for proprietary drivers, such that they can run on a virtual machine on any platform. (This is actually not all that different from some aspects of ACPI, in that you end up running a bit of code sent from the hardware); then manufacturers could provide a driver which works on different platforms, is coded to a standard, and the system would be protected against bugs in the drivers (except for them locking the system bus or such).
First of all, there are going to be a lot of kernels which start 2.6 before 2.6.0, due to the whole stabilization process. Secondly, I think that distros will have a more substantial role in testing the kernels than they have in the past, relative to individual users, so the big stress tests will come when IBM, Red Hat, and Oracle pick up 2.6-pre1 to test; in the past, the big stress tests came when 2.4.0 got a lot of end users to start testing. Third, Andrew Morton is intending to be a release engineer, which Linus has done badly in the past (that not being what his style is good for), which will mean that 2.6.0 will be carefully tested, unlike previous .0 versions.
Of course, this is due to evolution is the process of releasing stable series kernels, not evolution in the kernel code itself; through the middle of 2.5, everything got broken, and has now mostly been fixed.
That's why there's going to be a substantial 2.6-pre series, and why Andrew Morton is going to be the one to release 2.6.0. The goal is for 2.6.0 to be a production release, which means that 2.6.0 can't be the first 2.6 kernel. Fortunately, kernel versioning supports the creation of 2.6 kernels which are before 2.6.0, and Linus understands that his skills are not in release management.
.0 release. Furthermore, there's a lot more testing and verification infrastructure these days than in the past, from the Stanford checker (which catches a lot of unsafe usages in obscure drivers without having the hardware necessary to actually run them) to various test labs.
The real step needed for stability is testing by a wide variety of people. This should actually be easier to get than in the past, since a much larger portion of the front-line testing these days is done by the various distributions, who are not getting into the "enterprise software" business, where they have to do substantial research on whether the software works on different systems before releasing it. And distributions are generally a lot closer to the development process than random individual users are, so they can be more easily convinced to start testing a stable series in advance of the
There's actually quite a bit more effort put into making sure that end users get a stable kernel these days than in the past, as more business software companies promote Linux more heavily. IBM will make sure that they know at all times the status of 2.6 kernels with respect to any bugs that can be triggered on any of the hardware IBM ships, and they'll make sure that Linus and Andrew know whether a kernel is suitable for 2.6.0, at least from IBM's perspective.
The real question is whether Linus will manage to hold off starting the 2.7 series until 2.6.0 is released. (Personally, I doubt it; I bet Linus will want to release 2.6.0 before Andrew is willing to, and I bet Linus will decide that the current version may not be good enough for production, but it is good enough to start further development, and Andrew will agree that people who want to work on 2.7 aren't going to do anything more useful for the remaining 2.6 problems at that point)