Except that the way it is spelled, to me, would be "ee-oin", with a second choice of "Ee-oh-in". Your reading effectively ignores the E. I start from the left: I have no special soind for "eo", so I pronounce the e. That leaves me with "oin" as in coin, join. Then, realising it might be a funny furrin word, I will allow the option of "oh-in". But a totally silent leading E is not something I could deduce.
The assumption that there would be less money in OS development, while plausible, is not necessarily true. That assumes that the rate of development stays the same. But sometimes cutting prices can stimulate demand and increase total spend. The more the model allows people to co-operate and share their development, the more enhancements which are uneconomic for one company but economic for several will be produced - employing more OS developers, not fewer.
This would need a "features market", where you could put together clubs of potential funders, who will individually pay a developer a small amount that becomes collectively large.
On the other hand, what Canonical are focussing on, and what makes Ubuntu popular, is the user experience. They are doing all the tidying up of the installer and package handling so that the non-techie user doesn't get baffling (to them) messages about mismatched packages etc. In some ways, you should see them more as a packager than a developer. In which case it is hardly surprising that they contribute little to kernel development. The kernel, by and large, is the bit that you don't package.
Fission powered aircraft will never make sense. Hypothetically, fusion powered aircraft could be plausible - though not with any of the fusion technologies under development. A fusion system does not require a large mass of intensely radioactive, flammable material always to be present. At the moment is requires a containment vessel which is too heavy for aviation uses, but alternative concepts have been imagined.
Unless they collide, it takes two objects to capture something. If it falls in from free space and does not lose energy, it will fall out again just as easily. Hence the need for a "near collision": two large bodies (the start, and another passing nearby) can do almost anything to the orbits. One star on its own can do little.
Why settle for moving Mahomet when you can move the mountain? Flipping the enormously massive start is a much harder operation - by many orders of magnitude - than reversing the planet. Theangular momentum of the sum dwarfs that of most planets.
What TFA is suggesting that a second start did not collide, but passed nearby - a much more likely event, since "nearby" could amount to hundreds of solar diameters apart, making the "target" tens of thousands times larger. Any planet of either sun would then have been flung about like gravel under a dirt-track racer. This planet might well have been captured from the other star in this case.
The "dust cloud" theory only states that the majority of planets should rotate with their sun. There are a number of known mechanisms, some discusses in TFA, which can produce retrograde motion. We have several moons in the solar system showing retrograde motion. So this does absolutely nothing to disturb current theories of planet formation - you would have to find dozens of these to do that. It just appears that, in this case, one of several interesting events must have happened, and it might be worth looking for evidence of such an event. For example, if it were a near collision, it would be worth backtracking the paths of nearby stars to see if they were candidates for this decision.
This is not a "the current rules are broken" announcement, but a "hey, something interesting" announcement.
I have heard of several cases where both pilots fell asleep. However, they were in cruise, under autopilot control, and no crisis happened. The only reason they are known about is that one of the crew woke up, realised what had happened, and used the anonymous feedback system to report it. I think the system gets several such reports a year.
Interestingly, Boeing seem to have given up on the re-implementing. Apparently, they feel that with the formal specification languages they now have, they can ensure that the implementation matches the specification in an automated manner. The question now is, is the specification sensible. So rather than have two teams implementing the specification, they want twice as many people checking that the specification makes sense.
Well, the quoted statement is my opinion, rather than a law. If you are right, they are wrong, in my opinion. The reason originally given for the LGPL was the proliferation of C runtime libraries under different licenses: GPL, BSD, totally free. It was (correctly, in my opinion) viewed as a loss to the community at large to maintain multiple different libraries with the same intended functionality. As well as the duplication of effort, there is a risk that functionality will diverge, and some of the libraries will be regarded as inadequate because of feature drift in the others.
Of course, there are cases where what is more-or-less an App can be released as a Library to allow a configuring front end to be linked on. But I would see these as the exception rather than the rule.
Re:This isn't sensationalist, it's the truth
on
Leaving the GPL Behind
·
· Score: 3, Insightful
Which is what the LGPL is invented for. The licence for Apps is the GPL, the license for libraries is the LGPL. If you link with LGPL code, you just have to make the source of the library available - in the for you used it. So if you bugfix or enhance the library, you must offer forward the bugfixes - and it makes sense to submit them back, so the community gains. But the LGPL does not require you make public the whole source of your app.
As someone working in in the commercial environment, the LGPL is fine, and my company has published its own LGPL code. It requires a little care in keeping LGPL code separate from in-house code, but is no problem at link time.
The full GPL, however, is untouchable. I have no problem with that - it is designed to achieve a certain effect, at a certain cost. It achieves what it set out to do, and pays the cost that was know up front.
Illness, including other family members, supporting family members who do not have the discipline required, bad luck (a fire when uninsured), crime against you.
I grant you that a bad credit report might prompt further inquiry. But it should only be used as a symptom, and any job non-offer based on the underlying problem when determined.
I doubt strongly that we will develop sufficient transport to evacuate the earth's current population. But the population is currently scheduled to peak around 2100 and then start falling. *If* we can keep civilisation alive until this event occurs, I think is it a pretty good bet that we can taper our population down over the last few millennia so nobody gets left behind. Educated, well off people who know that their children have very good survival chances have been shown to be, on average, remarkably sensible about reproducing responsibly. (Though see current issue of The Economist for an article about how birthrates fall with wealth, but seem to be rising with super-wealth. But the super-wealthy will be the ones with the off-planet ticket).
Which is a measure of the low/relative/ importance of these documents. But when, as the UK government claims they become the one master ID document, that will no longer be acceptable. If you cannot make any credit card purchases or enter a moderately secure area without it, replacement will get a lot more important.
If IDs ever get into widespread use, there will be massive demand for them to be produced quickly. If, for example, you cannot get into a nightclub or buy alcohol without a card, party-types who lose their cards will put much pressure on the government to replace cards fast. if you need on for purchases over a relatively low level - as the Government predicts - the same will apply.
Basically, if it becomes the universal card to have, as the Government claims, then fast replacement is a political necessity. If they do not provide for that, then they are proven hypocrites.
I think unforgeable ID is up there with Perpetual Motion Machines on the list of impossible. Just as good (and expensive) engineering can make machines that will run for a long time. good (and expensive) engineering can make the cost of forgery high, This is the way money is protected from forgery: the cost of the machinery to make it is very high. This is no problem for the Mint, which amortizes it of millions of banknotes. But for criminals, it means the number of notes they have to circulate before getting their money back is very high, and risks leaving a trail back to them. Unfortunately, ID cards by their nature cannot be produced in a central, well guarded, press. The technology for creating them must be cheap enough to distribute to hundreds of local offices. Which means it is cheap enough for criminals to duplicate. Conversely, the value of one really well forged ID card is high, whereas the value of one forged banknote of value ordinary enough to pass around easily is not very great.
But I entirely agree with you (and TFA): the ID card system is a stalking horse to get a central database of the population in order to keep an eye on everybody. Freedom includes the freedom to err. If you wish, as the authorities seem to, to remove all possibility of error, you tautologously remove all freedom.
Apparently (i.e. I read on the net, so not very reliable), some shops have a policy of ID every Nth customer, regardless of appearance. Which got a 75-year-old irate when he was refused service because he wasn't carrying ID.
However, such settlement terms are really par for the course.
But they shouldn't be. The item was "not of merchantable quality" and should have been replaced or refunded, as normal business practice, without the customer needing to sign anything.
In selling computers, and in particular software, there often arise case where it is extremely debatable where the fault is: the software doesn't do what the customer wants, but it is far from obvious whether the seller ever said it would. In such cases, to avoid complex negotiations which might lead to expensive litigations, the seller may well make a goodwill refund which he thinks he doesn't need to, and in such cases it is reasonable to ask for some agreement that the buyer will not badmouth the seller, whose non-admission of liability is quite reasonable.
However, if fairly reported, this is not such a case. Any piece of consumer gear that bursts into flames unexpectedly is fundamentally flawed, and should be replaced without further ado. Apple is bringing practices valid in one field to a completely different field. When it sells iPods, it is a consumer goods seller, not a computer systems seller, and should behave accordingly.
Nothing like twisting the language to force a point. We have different words for "survival" and "intelligence" because they are different things. Redefining one to mean the other does not contribute to the discussion. It may be that Artificial Survival is a better goal for research than Artificial Intelligence - the point could be argued. But this semantic redefinition assumes that argument won, and claims victory in an Orwellian manner by redefining the language to state that victory has been won.
I think there are two separate things: rational dislike of Microsoft, and irrational hatred of Microsoft. Bot exist, and are distinct - and you will see both on/. I think that Torvalds, as the figurehead for Linux, hears more of the foaming irrational hatred than, perhaps, you do, and is responding to that. There are people who have suggested rejecting Microsoft's OSS contribution purely on the grounds that they are from Microsoft - that is the hatred side. The dislikers would accept any good quality, proprely licenced code - as Torvalds has done.
But actually, the manufacturer doesn't give a damn if you actually do use it for any or all of these purposes - provided the liability if it goes wrong doesn't rebound on them. By saying it is unsuitable, they have covered themselves when people use it in an application that might kill people. All the military would have to do is sign a piece of paper saying, in appropriate language "we are the military, we do dangerous things, we take reponsibility if those dangerous things kill the wrong people".
Windows is used on British Nuclear submarines - but not as part of the command and control system and certainly not the nuclear missile systems. Nuclear submarines have crews, and require stores control and admin systems for their food and other needs. These are standard Windows systems, but have nothing to do with the military side of the system.
Slashdot Mirror
Except that the way it is spelled, to me, would be "ee-oin", with a second choice of "Ee-oh-in". Your reading effectively ignores the E. I start from the left: I have no special soind for "eo", so I pronounce the e. That leaves me with "oin" as in coin, join. Then, realising it might be a funny furrin word, I will allow the option of "oh-in". But a totally silent leading E is not something I could deduce.
The assumption that there would be less money in OS development, while plausible, is not necessarily true. That assumes that the rate of development stays the same. But sometimes cutting prices can stimulate demand and increase total spend. The more the model allows people to co-operate and share their development, the more enhancements which are uneconomic for one company but economic for several will be produced - employing more OS developers, not fewer.
This would need a "features market", where you could put together clubs of potential funders, who will individually pay a developer a small amount that becomes collectively large.
Of course they are all single. We all know that geeks cannot attract the opposite sex (or the same one, for that matter).
Tongue in cheek, here. The number of new-baby announcements in this company comfortably exceeds the number of software releases.
On the other hand, what Canonical are focussing on, and what makes Ubuntu popular, is the user experience. They are doing all the tidying up of the installer and package handling so that the non-techie user doesn't get baffling (to them) messages about mismatched packages etc. In some ways, you should see them more as a packager than a developer. In which case it is hardly surprising that they contribute little to kernel development. The kernel, by and large, is the bit that you don't package.
Nuclear powered aircraft will never make sense.
Fission powered aircraft will never make sense. Hypothetically, fusion powered aircraft could be plausible - though not with any of the fusion technologies under development. A fusion system does not require a large mass of intensely radioactive, flammable material always to be present. At the moment is requires a containment vessel which is too heavy for aviation uses, but alternative concepts have been imagined.
Unless they collide, it takes two objects to capture something. If it falls in from free space and does not lose energy, it will fall out again just as easily. Hence the need for a "near collision": two large bodies (the start, and another passing nearby) can do almost anything to the orbits. One star on its own can do little.
Why settle for moving Mahomet when you can move the mountain? Flipping the enormously massive start is a much harder operation - by many orders of magnitude - than reversing the planet. Theangular momentum of the sum dwarfs that of most planets.
What TFA is suggesting that a second start did not collide, but passed nearby - a much more likely event, since "nearby" could amount to hundreds of solar diameters apart, making the "target" tens of thousands times larger. Any planet of either sun would then have been flung about like gravel under a dirt-track racer. This planet might well have been captured from the other star in this case.
The "dust cloud" theory only states that the majority of planets should rotate with their sun. There are a number of known mechanisms, some discusses in TFA, which can produce retrograde motion. We have several moons in the solar system showing retrograde motion. So this does absolutely nothing to disturb current theories of planet formation - you would have to find dozens of these to do that. It just appears that, in this case, one of several interesting events must have happened, and it might be worth looking for evidence of such an event. For example, if it were a near collision, it would be worth backtracking the paths of nearby stars to see if they were candidates for this decision.
This is not a "the current rules are broken" announcement, but a "hey, something interesting" announcement.
I have heard of several cases where both pilots fell asleep. However, they were in cruise, under autopilot control, and no crisis happened. The only reason they are known about is that one of the crew woke up, realised what had happened, and used the anonymous feedback system to report it. I think the system gets several such reports a year.
Interestingly, Boeing seem to have given up on the re-implementing. Apparently, they feel that with the formal specification languages they now have, they can ensure that the implementation matches the specification in an automated manner. The question now is, is the specification sensible. So rather than have two teams implementing the specification, they want twice as many people checking that the specification makes sense.
Well, the quoted statement is my opinion, rather than a law. If you are right, they are wrong, in my opinion. The reason originally given for the LGPL was the proliferation of C runtime libraries under different licenses: GPL, BSD, totally free. It was (correctly, in my opinion) viewed as a loss to the community at large to maintain multiple different libraries with the same intended functionality. As well as the duplication of effort, there is a risk that functionality will diverge, and some of the libraries will be regarded as inadequate because of feature drift in the others.
Of course, there are cases where what is more-or-less an App can be released as a Library to allow a configuring front end to be linked on. But I would see these as the exception rather than the rule.
Which is what the LGPL is invented for. The licence for Apps is the GPL, the license for libraries is the LGPL. If you link with LGPL code, you just have to make the source of the library available - in the for you used it. So if you bugfix or enhance the library, you must offer forward the bugfixes - and it makes sense to submit them back, so the community gains. But the LGPL does not require you make public the whole source of your app.
As someone working in in the commercial environment, the LGPL is fine, and my company has published its own LGPL code. It requires a little care in keeping LGPL code separate from in-house code, but is no problem at link time.
The full GPL, however, is untouchable. I have no problem with that - it is designed to achieve a certain effect, at a certain cost. It achieves what it set out to do, and pays the cost that was know up front.
Illness, including other family members, supporting family members who do not have the discipline required, bad luck (a fire when uninsured), crime against you.
I grant you that a bad credit report might prompt further inquiry. But it should only be used as a symptom, and any job non-offer based on the underlying problem when determined.
"Universal bereavement - an inspiring achievement" - Tom Lehrer, "We will all go together when we go"
I doubt strongly that we will develop sufficient transport to evacuate the earth's current population. But the population is currently scheduled to peak around 2100 and then start falling. *If* we can keep civilisation alive until this event occurs, I think is it a pretty good bet that we can taper our population down over the last few millennia so nobody gets left behind. Educated, well off people who know that their children have very good survival chances have been shown to be, on average, remarkably sensible about reproducing responsibly. (Though see current issue of The Economist for an article about how birthrates fall with wealth, but seem to be rising with super-wealth. But the super-wealthy will be the ones with the off-planet ticket).
Which is a measure of the low /relative/ importance of these documents. But when, as the UK government claims they become the one master ID document, that will no longer be acceptable. If you cannot make any credit card purchases or enter a moderately secure area without it, replacement will get a lot more important.
If IDs ever get into widespread use, there will be massive demand for them to be produced quickly. If, for example, you cannot get into a nightclub or buy alcohol without a card, party-types who lose their cards will put much pressure on the government to replace cards fast. if you need on for purchases over a relatively low level - as the Government predicts - the same will apply.
Basically, if it becomes the universal card to have, as the Government claims, then fast replacement is a political necessity. If they do not provide for that, then they are proven hypocrites.
I think unforgeable ID is up there with Perpetual Motion Machines on the list of impossible. Just as good (and expensive) engineering can make machines that will run for a long time. good (and expensive) engineering can make the cost of forgery high, This is the way money is protected from forgery: the cost of the machinery to make it is very high. This is no problem for the Mint, which amortizes it of millions of banknotes. But for criminals, it means the number of notes they have to circulate before getting their money back is very high, and risks leaving a trail back to them. Unfortunately, ID cards by their nature cannot be produced in a central, well guarded, press. The technology for creating them must be cheap enough to distribute to hundreds of local offices. Which means it is cheap enough for criminals to duplicate. Conversely, the value of one really well forged ID card is high, whereas the value of one forged banknote of value ordinary enough to pass around easily is not very great.
But I entirely agree with you (and TFA): the ID card system is a stalking horse to get a central database of the population in order to keep an eye on everybody. Freedom includes the freedom to err. If you wish, as the authorities seem to, to remove all possibility of error, you tautologously remove all freedom.
Apparently (i.e. I read on the net, so not very reliable), some shops have a policy of ID every Nth customer, regardless of appearance. Which got a 75-year-old irate when he was refused service because he wasn't carrying ID.
However, such settlement terms are really par for the course.
But they shouldn't be. The item was "not of merchantable quality" and should have been replaced or refunded, as normal business practice, without the customer needing to sign anything.
In selling computers, and in particular software, there often arise case where it is extremely debatable where the fault is: the software doesn't do what the customer wants, but it is far from obvious whether the seller ever said it would. In such cases, to avoid complex negotiations which might lead to expensive litigations, the seller may well make a goodwill refund which he thinks he doesn't need to, and in such cases it is reasonable to ask for some agreement that the buyer will not badmouth the seller, whose non-admission of liability is quite reasonable.
However, if fairly reported, this is not such a case. Any piece of consumer gear that bursts into flames unexpectedly is fundamentally flawed, and should be replaced without further ado. Apple is bringing practices valid in one field to a completely different field. When it sells iPods, it is a consumer goods seller, not a computer systems seller, and should behave accordingly.
Nothing like twisting the language to force a point. We have different words for "survival" and "intelligence" because they are different things. Redefining one to mean the other does not contribute to the discussion. It may be that Artificial Survival is a better goal for research than Artificial Intelligence - the point could be argued. But this semantic redefinition assumes that argument won, and claims victory in an Orwellian manner by redefining the language to state that victory has been won.
I think there are two separate things: rational dislike of Microsoft, and irrational hatred of Microsoft. Bot exist, and are distinct - and you will see both on /. I think that Torvalds, as the figurehead for Linux, hears more of the foaming irrational hatred than, perhaps, you do, and is responding to that. There are people who have suggested rejecting Microsoft's OSS contribution purely on the grounds that they are from Microsoft - that is the hatred side. The dislikers would accept any good quality, proprely licenced code - as Torvalds has done.
But actually, the manufacturer doesn't give a damn if you actually do use it for any or all of these purposes - provided the liability if it goes wrong doesn't rebound on them. By saying it is unsuitable, they have covered themselves when people use it in an application that might kill people. All the military would have to do is sign a piece of paper saying, in appropriate language "we are the military, we do dangerous things, we take reponsibility if those dangerous things kill the wrong people".
Windows is used on British Nuclear submarines - but not as part of the command and control system and certainly not the nuclear missile systems. Nuclear submarines have crews, and require stores control and admin systems for their food and other needs. These are standard Windows systems, but have nothing to do with the military side of the system.