If the point of the exercise is to create a Totally Accurate Simulator for use by pilots in training, then it's probably something of an issue to make sure that, in Mr. Scott's words,
"You canna change the laws of physics!"
In contrast, for those that are using this for Personal Entertainment , it doesn't too much matter what planet you fly on, how much power the jet motors have, or the value of Avrogado's (sp?) Constant.
The notion that "cheating" has anything to do with this is fairly silly; compare with the simple fact that you are pretending to fly a plane with the big-time cheating features that:
You don't pay for fuel;
You don't pay capital costs on that F117;
If you crash, you don't die.
If it's just a game, then part of the fun can come in fiddling with the shape of the world. You've already "cheated" by the fact that it's a game...
Alternatively, if Anonymous Coward is treated as a real but "shared" user, the low level of karma would naturally pull it down to defaulting to a negative score.
This would discourage serious posters from using Anonymous Coward instead of their own.
Back on topic somewhat, the pricing and configuration of these "set top" boxes are quite similar to the Think NIC ones. There seems to be a "price point" around $325-$350.
By the way, a monitorless NIC is priced at $199, and while it includes no hard drive, it does have a CD-ROM, which certainly provides more space than a maybe-64MB flash card...
With that less-than-hugely-friendly beginning, it moves on to real points that are not nearly as unfriendly as that initial thesis. (Which I think is there to shock the gentle reader...)
The opinions do not remain any less strong; try out:
Eventually these maintainers, although they know they provide a powerful, complex tool, would believe that they need to convince lure more
users over and gain the approval of those who are too myopic of lazy to RTFM. These great maintainers would confer and agree that perhaps the users are right and it is time to develop an easier way to install. This is the point where I say "foo!"
The author then proceeds to suggest that "keeping Debian powerful" is Job #1, whilst "making Debian more friendly" is a task that others can worry about.
I tend to agree with this; the proper priority seems to me to be to keep building a powerful and useful (and evermore vastly increasing) loosely-but-sufficiently-tightly integrated set of packages.
Making installation easy isn't forcibly part of that.
I agree with the suggestion that it might be a good idea to have an unambiguously BETTER scheme that could include queueing up installation configuration information, so that you essentially configure as much as possible before getting to the Commit This Configuration To Your System Now point, at which point disks get partitioned, filesystems get mounted, packages get dropped into place, and the likes, rather than configuring it piecemeal, one step committed after another.
It's probably always fair to say that it's a Good Thing to have a partitioning of package sets (ala "Network Server" versus "X-Developer" versus "Desktop System" versus "Web Server"...) that perfectly agrees with whatever you, the user, wanted; as preferences are in the eye of the beholder, it's nearly impossible to get this perfect.
I'd LOVE to see a lot of the "other-than-packages-and-partitioning" configuration deployed via the install tools creating scripts that do the configuration, and which could be used to redo the configuration... My personal prejudices involve cfengine; I've set up enough cfengine scripts that any time I install Linux on a system I plan to hook up at home, the first thing I do after getting the system running is to install cfengine, do an NFS mount of my "standard" scripts, and then execute them to set up my favorite maze of NFS mounts, shell configuration, and network services. For a distribution to do this sort of thing would be pretty cool.
As you say, it was merely a press release, as opposed to a full-featured review.
And it's not as if Red Hat was the first distribution to offer configurable degrees of security at install time. I've already seen it with Mandrake and StormLinux, and that is merely two that I've done installs of in the not-so-distant past
As for the "sliminess," that's more or less a given when there starts to be tens or hundreds of millions of dollars flowing in from the Vulture Capitalists... Look forward to more...
A 1GB drive that fits into a PDA certainly costs, at this point in time. I don't want to mortgage my house to buy a PDA that could easily walk off on me...
Palm Computing has nearly "disposable" hardware; at least, I won't be crushed if a $150 M100 gets crushed...
Or is this merely something that the "spammeisters" are claiming to be true?
I can imagine such a situation occurring, but wouldn't expect it to persist.
Remember that as soon as such a scheme would start to appear viable, "your company" would be a nice, fat target for a class action suit by whatever class of folk the scheme has been ravaging.
An AS/400 system uses the PowerPC processor, as do recent MVS systems, but this does not mean you can run MacOS software on them.
These machines are likely to become quite interesting when you can put something like 64MB-128MB of storage on them, but it is not obvious that software that runs on the iPaq will necessarily run on the Yopy merely because both computers have the same CPU.
For instance, if the iPaq is doing graphics via X, and the Yopy is running something like the "embedded Qt" or "FLTK lite, sans X," the programs that will work on both will merely be the daemons, and not anything graphical.
Frankly, the fact that WinCE has been a "bloated" platform (certainly compared to PalmOS) is a WONDERFUL thing; that encourages having vast quantities of RAM/other storage, which is very nice if you want to put some semblance of a fullscale Unix onto it...
The "sue the consumers" business model doesn't work because consumers don't have the money to individually pursue such cases.
The only way "lawsuit-oriented" business works is if you plan to sue people that have millions of dollars that could actually pay you something.
Insurance companies are good targets; TI makes lots of its dollars charging companies for access to its patents; IBM's patent portfolio is useful against companies.
Wow. Yggdrasil is back, after a long hiatus of apparent inactivity.
By the way, if you look carefully at the DVD page, you'll see that there is actually a way to get the DVD "for free," assuming that either:
You are a longsuffering Plug'n'Pray subscriber who has been waiting for five years for the next release, or
You are the author of some of the software sitting on the DVD.
(Does anyone else remember the bad old days when, rather than the relatively modern thing of arguing about whether Slackware was about to set up horrendous and rapacious licensing, or the newbie thing of arguing over the same thing for Red Hat, that the flame wars were over the peculiar way Yggdrasil had created for pulling programs automagically off CD on demand so that you'd only have the stuff you actually used on your hard drive? Boy, there were flame wars back then...)
The "model" that you're suggesting is completely different from the one DC is using; their basic "raison d'etre" is to be completely "webbed out," using the device as a tie-in to collecting psychometric data.
I totally agree with you on the merits of alternative uses of the device.
I've got a PalmPilot and a keyboard interface from the folks that brought us the "Happy Hacker's" keyboard; I could use that as a portable bar code collector.
Velcro the components to my belt, and I could run around my apartment, barcoding all my books into a notepad, and then decode en masse to put together a library listing.
Note the use of the PalmPilot; the reader is a whopping lot more useful if there is some way of collecting a bunch of bar codes as you walk around.
The other piece of the puzzle is to be able to PRINT your own bar code stickers to attach to things. That then means that there is no "fixed" interpretation; you have to create your own framework in which to interpret the code.
As with putting a bar code on each CD you burn, so that you can do an inventory in ten minutes of 100 CDs...
There's lots and lots of cool stuff to do with this; hopefully we'll get past the idiocy of the present situation.
The contest is certainly one of "humans versus humans," with radio-controlled "devices."
There are several places where computer controls would be quite useful, all the same.
For instance, if there were sensors to indicate when that slashing blade should go down so that it would only happen when the Bot "saw" another Bot in range, that would make the attacks "more accurate."
As it stands, a whole lot of the contest comes out of how successfully the human can percieve
the precise orientations and relative locations of the "Bots." If your depth perception is crummy, then the battle will go badly.
There are other mechanisms to get to the same goal; having cameras at critical locations so that the human can see precisely what you're pointed at would "do the trick."
But the more complex the set of things that the Bot can do, the more useful it can be to automate control over some of those things.
Obviously it won't involve a vulnerable IDE disk drive; I'd expect such a system to use an embedded controller using rather rugged hardware. As it stands right now, if servo cabling gets cut, a Bot will be crippled, which is essentially no different.
I agree that part of me would be more impressed if the "Bots" were truly autonomous; it is not at all obvious that that would result in entertaining TV, unless we could go a few generations further to "Robots" where the designers were essentially devoted to programming entertaining strategies.
We answered that we didn't understand what intellectual property we had infringed, and that they would have seven days to answer us.
And then note that
For his part, Coupard was surprised to learn that Digital Convergence considered the matter resolved. After Digital Convergence's attorneys
failed to respond to Lineo's request for more information, Coupard put his CueCat device driver back on the web, along with Rothwell's program,
and others.
If the DC folk fail to respond to the not unreasonable expectation that they actually indicate what "intellectual property" is being infringed on, then it seems to be, as you say, "totally fair game" to continue tinkering.
After all, if they can't or won't document the nature of the infringement, is it infringing?
I'm not surprised that:
Digital Convergence was aghast. "If people
take over our cat and start using their own
databases, the world becomes cloudy," says
Mathews. "Our revenue model is being the
gate keeper between codes and their
destinations online."
It appears that they think that simply using the:Cue:Cat represents their "intellectual property," which seems pretty nonsensical.
The problem with these vastly powerful CPUs is that they continue to outrace the availability of suitable RAM, in terms of cost, speed, and quantity.
When Pentium Pros were nicely harnessed with 64MB of RAM, it probably makes sense for something 10 times as fast to be "properly appointed" with something like 640MB of RAM;
These things need huge amounts of cache to run efficiently;
Idiot vendors will probably sell them with 128MB of RAM because that's what's not too expensive this month;
Most of the CPU power is outright wasted when it's spending it's interrupt time assortedly waiting for an IDE drive, a WinModem, and such.
The killer hardware would be to have a bank of 16 "serial ATA" ports with an asynchronous drive on each port. Of course I2O would likely be better still, but that seems pretty vaprous, certainly for the consumer market...
If you've got something like a DBM file that you're going to be doing absolutely massive numbers of updates on, it would be a slick idea to store that file on a RAMdisk so that updates wouldn't get forced out to disk on a regular basis.
Obviously this will be vulnerable to failure, but for something that collects massive quantities of statistics, such as Ifile, it can be worthwhile.
With Ifile, an early edition stored stats in DBM files, and would do simply massive numbers of increments to entries. On disk, this meant that for a relatively small mail spool, the analysis would take hours.
... The real findings that a research project would represent answers to the question: What search engines ignore the robots.txt file? so that any "inclusions" represent either:
Search engines that don't respider very often, thus providing obsolete data, or
Search engines that ignore requests not to spider, and that thus are bad Internet "citizens."
... That this was a very successful "troll" for discussion on the part of both the research group as well as the operators of Slashdot.
After all, if there was no "crime" to complain about, and any "damage" was done by themselves to themselves, this never merited one story let alone two.
Since no lawyers were involved, it's not a case where "the lawyers won" (as is often seen in big, bloody trials); instead, it could be said that "the journalists won," as they got a bunch of blather out of no real story.
The main merit of SPARC Linux is that it means that it gives you something to run on some of the Hordes of SPARCs on eBay that are priced as low as a couple hundred bucks, but which likely don't come with a Solaris license.
Such machines won't be challenging the Distributed.Net "Keys-per-second" benchmarks, but if they allow you to put in place a web server on hardware actually designed for serving rather than the sort of absolute trash you'd get in IA-32 hardware for $100, that's certainly worth something.
I doubt many will be using SPARC Linux on a spanking new E10000 Enterprise Server; but watch out, since as Linux improves, while it may be less featureful than Solaris, the differences are likely diminishing over time.
Technical luddite that I am, I'm getting extra RAM for a Pentium Pro 200 box that I've got so that I can run SAP R/3 on it; I don't yet have anything Athlon or P-III-based. (I'm sort of waiting for SMP Athlon motherboards to come out, although not too seriously...)
Anyhoo, P-III is likely to have more relevance than Intel should be comfortable with because:
It's available today; P-IV isn't.
It is compatible with today's motherboards and cases; P-IV isn't.
That's rather important; you can't get systems based on a CPU until you can get all the necessary components.
The fact that StrongARM motherboards aren't readily-and-cheaply available is certainly a contributing factor to a lack of widespread use for "desktop-like" applications.
The fact that Athlon SMP motherboards aren't available (yet?) is THE CRUCIAL factor that results in there being a dearth of SMP Athlon systems.
And once P-IV is "released," there will be a time when it is still not usefully available due to the motherboards and cases not yet having gotten through distribution channels.
It is compatible with today's cooling technology... P-IV... may require a lot of your fans...
I'd have no trouble agreeing that qmail has a better security record than Sendmail.
The problem is, that's not the only plausible comparison to make. It's more or less like saying, Because Windows Crashes If You Look At It Funny, and Linux doesn't, therefore Linux must be SuperRobust Software.
Which may be a legitimate comparison at one level, but still doesn't mean that closer comparisons aren't more relevant. I'd think we'd learn more from comparing Linux to VMS, or Tandem, or *BSD.
And heading back to relevance, perhaps qmail hasn't gotten "hacked," but it seems to me that we could ask if Postfix has gotten hacked, and find that quite meaningful.
The problem with all of these units, whatever the vendor, is that you need to have $200 worth of "flash RAM" in order to be able to store a faintly useful amount of music.
I'd agree that the iPAQ is sufficiently "capacious" from a CPU, and possibly battery, perspective to cope well with MP3; it's still not got enough RAM to do the job well.
And that ignores any concerns of interoperability I might have; the PalmOS apps interoperate with PDA apps on Windows and Linux, whilst the same cannot be said of the iPAQ set of apps... Whether it matters to everyone, this does matter to me.
If I wanted to be a "conspiracy nut," I'd say that the folks that make stuff like CompactFlash RAM cards are striving hard to keep the prices high. (I don't want to start the rumor, but could believe it to be true...)
These units will be a whole lot more interesting, particularly for storage-hungry applications like MP3 playing, when you can get a 256MB "flash card" for $200, or they otherwise can have that kind of quantity of storage onboard.
On the one hand, it is interesting to note that Nokia's North American headquarters are in Irving, Texas, immediately next door to the local headquarters for Microsoft.
"Boy, that sure proves that it's a conspiracy!"
On the other hand, there is a considerable Linux presence at Nokia, between the fact that:
A sizable LUG meets monthly at that Nokia campus, and
There are quite a few "Linux folk" at Nokia.
Perhaps not "notable kernel hackers," but there certainly are a lot of engineers that use Linux...
It all goes together to imply that things are seldom as "black-and-white" as they may appear to be...
That "little license thingy" does not prevent Nokia from having a chat with Netscape Communications Corporation (or AOL) and making other arrangements.
Note the following bit of the Netscape Public License:
V.2. Other Products.
Netscape may include Covered Code in products other than the Netscape's Branded Code which are released by Netscape during the two (2) years following the release date of the Original Code, without such additional products becoming subject to the terms of this License, and may license such additional products on different terms from those contained in this License.
Note the phrase may license such additional products on different terms from those contained in this License.
The result is that NCC, as original "owner" of the code base, has arranged that they may license the code to other people on other bases.
Nokia could get the code under the MPL; that would indeed require that they contribute back changes in source code form. If they get the code under some other licensing arrangement, the MPL obviously doesn't apply to them.
In contrast, for those that are using this for Personal Entertainment , it doesn't too much matter what planet you fly on, how much power the jet motors have, or the value of Avrogado's (sp?) Constant.
The notion that "cheating" has anything to do with this is fairly silly; compare with the simple fact that you are pretending to fly a plane with the big-time cheating features that:
- You don't pay for fuel;
- You don't pay capital costs on that F117;
- If you crash, you don't die.
If it's just a game, then part of the fun can come in fiddling with the shape of the world. You've already "cheated" by the fact that it's a game...This would discourage serious posters from using Anonymous Coward instead of their own.
Back on topic somewhat, the pricing and configuration of these "set top" boxes are quite similar to the Think NIC ones. There seems to be a "price point" around $325-$350.
By the way, a monitorless NIC is priced at $199, and while it includes no hard drive, it does have a CD-ROM, which certainly provides more space than a maybe-64MB flash card...
With that less-than-hugely-friendly beginning, it moves on to real points that are not nearly as unfriendly as that initial thesis. (Which I think is there to shock the gentle reader...)
The opinions do not remain any less strong; try out:
The author then proceeds to suggest that "keeping Debian powerful" is Job #1, whilst "making Debian more friendly" is a task that others can worry about.
I tend to agree with this; the proper priority seems to me to be to keep building a powerful and useful (and evermore vastly increasing) loosely-but-sufficiently-tightly integrated set of packages.
Making installation easy isn't forcibly part of that.
I agree with the suggestion that it might be a good idea to have an unambiguously BETTER scheme that could include queueing up installation configuration information, so that you essentially configure as much as possible before getting to the Commit This Configuration To Your System Now point, at which point disks get partitioned, filesystems get mounted, packages get dropped into place, and the likes, rather than configuring it piecemeal, one step committed after another.
It's probably always fair to say that it's a Good Thing to have a partitioning of package sets (ala "Network Server" versus "X-Developer" versus "Desktop System" versus "Web Server" ...) that perfectly agrees with whatever you, the user, wanted; as preferences are in the eye of the beholder, it's nearly impossible to get this perfect.
I'd LOVE to see a lot of the "other-than-packages-and-partitioning" configuration deployed via the install tools creating scripts that do the configuration, and which could be used to redo the configuration... My personal prejudices involve cfengine; I've set up enough cfengine scripts that any time I install Linux on a system I plan to hook up at home, the first thing I do after getting the system running is to install cfengine, do an NFS mount of my "standard" scripts, and then execute them to set up my favorite maze of NFS mounts, shell configuration, and network services. For a distribution to do this sort of thing would be pretty cool.
And it's not as if Red Hat was the first distribution to offer configurable degrees of security at install time. I've already seen it with Mandrake and StormLinux, and that is merely two that I've done installs of in the not-so-distant past
As for the "sliminess," that's more or less a given when there starts to be tens or hundreds of millions of dollars flowing in from the Vulture Capitalists... Look forward to more...
Palm Computing has nearly "disposable" hardware; at least, I won't be crushed if a $150 M100 gets crushed...
Or is this merely something that the "spammeisters" are claiming to be true?
I can imagine such a situation occurring, but wouldn't expect it to persist.
Remember that as soon as such a scheme would start to appear viable, "your company" would be a nice, fat target for a class action suit by whatever class of folk the scheme has been ravaging.
Turnabout is quite fair play :-).
An AS/400 system uses the PowerPC processor, as do recent MVS systems, but this does not mean you can run MacOS software on them.
These machines are likely to become quite interesting when you can put something like 64MB-128MB of storage on them, but it is not obvious that software that runs on the iPaq will necessarily run on the Yopy merely because both computers have the same CPU.
For instance, if the iPaq is doing graphics via X, and the Yopy is running something like the "embedded Qt" or "FLTK lite, sans X," the programs that will work on both will merely be the daemons, and not anything graphical.
Frankly, the fact that WinCE has been a "bloated" platform (certainly compared to PalmOS) is a WONDERFUL thing; that encourages having vast quantities of RAM/other storage, which is very nice if you want to put some semblance of a fullscale Unix onto it...
The only way "lawsuit-oriented" business works is if you plan to sue people that have millions of dollars that could actually pay you something.
Insurance companies are good targets; TI makes lots of its dollars charging companies for access to its patents; IBM's patent portfolio is useful against companies.
None of this is good for dealing with consumers.
By the way, if you look carefully at the DVD page, you'll see that there is actually a way to get the DVD "for free," assuming that either:
(Does anyone else remember the bad old days when, rather than the relatively modern thing of arguing about whether Slackware was about to set up horrendous and rapacious licensing, or the newbie thing of arguing over the same thing for Red Hat, that the flame wars were over the peculiar way Yggdrasil had created for pulling programs automagically off CD on demand so that you'd only have the stuff you actually used on your hard drive? Boy, there were flame wars back then...)
I totally agree with you on the merits of alternative uses of the device.
I've got a PalmPilot and a keyboard interface from the folks that brought us the "Happy Hacker's" keyboard; I could use that as a portable bar code collector.
Velcro the components to my belt, and I could run around my apartment, barcoding all my books into a notepad, and then decode en masse to put together a library listing.
Note the use of the PalmPilot; the reader is a whopping lot more useful if there is some way of collecting a bunch of bar codes as you walk around.
The other piece of the puzzle is to be able to PRINT your own bar code stickers to attach to things. That then means that there is no "fixed" interpretation; you have to create your own framework in which to interpret the code.
As with putting a bar code on each CD you burn, so that you can do an inventory in ten minutes of 100 CDs...
There's lots and lots of cool stuff to do with this; hopefully we'll get past the idiocy of the present situation.
There are several places where computer controls would be quite useful, all the same.
For instance, if there were sensors to indicate when that slashing blade should go down so that it would only happen when the Bot "saw" another Bot in range, that would make the attacks "more accurate."
As it stands, a whole lot of the contest comes out of how successfully the human can percieve the precise orientations and relative locations of the "Bots." If your depth perception is crummy, then the battle will go badly.
There are other mechanisms to get to the same goal; having cameras at critical locations so that the human can see precisely what you're pointed at would "do the trick."
But the more complex the set of things that the Bot can do, the more useful it can be to automate control over some of those things.
Obviously it won't involve a vulnerable IDE disk drive; I'd expect such a system to use an embedded controller using rather rugged hardware. As it stands right now, if servo cabling gets cut, a Bot will be crippled, which is essentially no different.
I agree that part of me would be more impressed if the "Bots" were truly autonomous; it is not at all obvious that that would result in entertaining TV, unless we could go a few generations further to "Robots" where the designers were essentially devoted to programming entertaining strategies.
And then note that
If the DC folk fail to respond to the not unreasonable expectation that they actually indicate what "intellectual property" is being infringed on, then it seems to be, as you say, "totally fair game" to continue tinkering.
After all, if they can't or won't document the nature of the infringement, is it infringing?
I'm not surprised that:
It appears that they think that simply using the :Cue:Cat represents their "intellectual property," which seems pretty nonsensical.
The killer hardware would be to have a bank of 16 "serial ATA" ports with an asynchronous drive on each port. Of course I2O would likely be better still, but that seems pretty vaprous, certainly for the consumer market...
Oops, is that a spark???? BANG!
Oh, the humanity...
Obviously this will be vulnerable to failure, but for something that collects massive quantities of statistics, such as Ifile, it can be worthwhile.
With Ifile, an early edition stored stats in DBM files, and would do simply massive numbers of increments to entries. On disk, this meant that for a relatively small mail spool, the analysis would take hours.
The most notable places where RDF is presently used for real things (as opposed to "we'd like it to be used here vaporware") include:
The latter is exceedingly relevant, as it represents an encoding of metadata about Linux software packages in RDF form.
After all, if there was no "crime" to complain about, and any "damage" was done by themselves to themselves, this never merited one story let alone two.
Since no lawyers were involved, it's not a case where "the lawyers won" (as is often seen in big, bloody trials); instead, it could be said that "the journalists won," as they got a bunch of blather out of no real story.
Such machines won't be challenging the Distributed.Net "Keys-per-second" benchmarks, but if they allow you to put in place a web server on hardware actually designed for serving rather than the sort of absolute trash you'd get in IA-32 hardware for $100, that's certainly worth something.
I doubt many will be using SPARC Linux on a spanking new E10000 Enterprise Server; but watch out, since as Linux improves, while it may be less featureful than Solaris, the differences are likely diminishing over time.
Anyhoo, P-III is likely to have more relevance than Intel should be comfortable with because:
That's rather important; you can't get systems based on a CPU until you can get all the necessary components.
The fact that StrongARM motherboards aren't readily-and-cheaply available is certainly a contributing factor to a lack of widespread use for "desktop-like" applications.
The fact that Athlon SMP motherboards aren't available (yet?) is THE CRUCIAL factor that results in there being a dearth of SMP Athlon systems.
And once P-IV is "released," there will be a time when it is still not usefully available due to the motherboards and cases not yet having gotten through distribution channels.
The problem is, that's not the only plausible comparison to make. It's more or less like saying, Because Windows Crashes If You Look At It Funny, and Linux doesn't, therefore Linux must be SuperRobust Software.
Which may be a legitimate comparison at one level, but still doesn't mean that closer comparisons aren't more relevant. I'd think we'd learn more from comparing Linux to VMS, or Tandem, or *BSD.
And heading back to relevance, perhaps qmail hasn't gotten "hacked," but it seems to me that we could ask if Postfix has gotten hacked, and find that quite meaningful.
I'd almost believe it if I heard the claim that the athlete lost a whole leg to the process...
I'd agree that the iPAQ is sufficiently "capacious" from a CPU, and possibly battery, perspective to cope well with MP3; it's still not got enough RAM to do the job well.
And that ignores any concerns of interoperability I might have; the PalmOS apps interoperate with PDA apps on Windows and Linux, whilst the same cannot be said of the iPAQ set of apps... Whether it matters to everyone, this does matter to me.
If I wanted to be a "conspiracy nut," I'd say that the folks that make stuff like CompactFlash RAM cards are striving hard to keep the prices high. (I don't want to start the rumor, but could believe it to be true...)
These units will be a whole lot more interesting, particularly for storage-hungry applications like MP3 playing, when you can get a 256MB "flash card" for $200, or they otherwise can have that kind of quantity of storage onboard.
"Boy, that sure proves that it's a conspiracy!"
On the other hand, there is a considerable Linux presence at Nokia, between the fact that:
Perhaps not "notable kernel hackers," but there certainly are a lot of engineers that use Linux...
It all goes together to imply that things are seldom as "black-and-white" as they may appear to be...
Note the following bit of the Netscape Public License:
Note the phrase may license such additional products on different terms from those contained in this License.
The result is that NCC, as original "owner" of the code base, has arranged that they may license the code to other people on other bases.
Nokia could get the code under the MPL; that would indeed require that they contribute back changes in source code form. If they get the code under some other licensing arrangement, the MPL obviously doesn't apply to them.
This isn't a big deal for a += 1 , but certainly is for a more complex assignment like a[index].attribute += 1
Definitely a good thing...