It's obvious that the FTC knows that cell phones don't cause problems, otherwise there would be a required upgrade for all airplanes
On that basis it's obvious that they know that eg. kapton wiring doesn't cause problems otherwise there would be a required replacement program.
Guess what ?
- it _does_ cause crashes - it is not used on most new aircraft because of its safety record - but there is no requirement to replace it on old aircraft
Why ? - because it is unfeasibly expensive.
Using a mobile on a plane will not automatically cause a crash, but there is a real risk that it might. Same applies to using a gun or a knife - in the history of flight hundresds of thousands of guns and knives will have been used on planes without incident. Doesn't matter - there is a risk, which they are acting to reduce, so you eat your meal with bendy plastic and you don't use your phone.
By the way if _you_ read the article you would know that the effect was found with the transmitter 30cm from the instrument or its wiring harness. Instrument wiring is all over planes. Literally miles of it. There WILL be wiring within 30cm of your seat and/or overhead locker.
Actually since you ask, I don't think they did have anything to do with it. No one has ever actually confirmed that the fight got to the cockpit - they've still refused to release the tapes.
Debris field is the most suspicious for me. Somehow those fighting civilians and terrorists managed to blow an engine off the wing in mid air. Me, I can't see the mechanism for that. Short range IR guided AA missile on the other hand - yep I can see "blow the engine off the wing" as the result there.
Mobiles transmit regularly to register with a base station so they can receive calls. They do this more often when they lose contact with base station and need to search for another one, eg. when they are moving.
Unfortunately in this case the overflow is in the hardware in the wiring. To fix it you need to rip the machine down to bare metal and replace every component with a cricuit board with a new one.
Cheaper to buy a new machine.
Pity you have a few hundred of them and they cost $100M a pop... but never mind, sure the user will pay for it.
Yeah but that's a new aircraft being designed now.
Aircraft in design now will be starting flying in 5 years (eg. A380 commenced 2000 in service target 2006.
So assuming your aircraft is brand new you could be confident that any consumer electronics over five years old would be safe. Not that helpful really. How many cellphones do you have that are > 5yrs old ?
(De)merits of kapton aside - just becuse the military ban something doesn't make it bad/good on commercial aircraft. eg. I think many military aircraft fly with inerted (inert gas in airspace) fuel tanks, but on the other hand they flew with fly-by-wire long before it was allowed in commercial.
If you've got numbers on relative safety records of military vs. commercial aircraft it would be interesting - but I think you'll find the military have the worse record.
Mind you, the military also have chutes/ejector seats, which commercial won't even give you in first!
Because the airlines can test and certify the particular equipment they are installing / permitting.
Quote:
âoeOur technical teams have worked diligently to demonstrate that wireless applications comply with rigorous aviation standards..."
They could also test and certify cellphones - but they won't because a) they know from existing results that the tests would fail and b) the telco industry doesn't want cellphones on thousands of feet up anyway because the cell system can't cope with it either.
Interference is most likely being picked up by the wiring not by the actual instruments. Installing a new wiring loom in an aircraft is not trivial (I'm not even sure it's _possible_).
Then they have to re-certify for flight since they just changed all the wiring (you want to make sure it's safe right ?). Then they have to do it all again a few months later when the next wireless gadget "standard" comes out ?
Nope - as discussed many times before they were in different orbit without anywhere near enough fuel to get to ISS.
There are a lot of other things they might have been able to do though. Stuff I've read included dumping excess weight/cargo, changing reentry profiles to reduce left wing heating, spacewalk inspect/repair, unmanned resupply rocket, shuttle rescue mission - all _possible_, but maybe not practical. Reaching ISS was not possible.
SCO have said on occaisions that it is not just the kernel code that is at issue. In GNU terms the system is Linux Kernal + GNU, so it must therefore be that there are issues with the GNU bit of GNU/Linux.
RMS has clearly noticed this and responded by saying that the GNU bit is safe because the FSF have copyright assignments from contributors and their employers.
Teeny weeny flaw there - if IBMer put code into GNU who will the FSF have copyright assignment from ? - yep, IBM. If SCO is right and it wasn't IBM's code to assign then all RMS has is toilet paper.
$companyYYY are alleging that $personBad working for $CompanyXXX contributed code they got from $companyYYY, and they are suing $companyXXX for it and warning you that you could be next.
Exactly how do your signed statements from $companyXXX help against $companyYYY ???
[ all they do is demonstrate that you acted in good faith - but proving the code was distributed to you claiming to be under the GPL would do that anyway ]
The scope is (explicitly as well as implicitly) limited to redistribution (actually modification also), GPL v2 clause 0:
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted
Linking can be derivation, depending on how it's done. A work which includes (significant) bits of the original is derived - a statically linked executable includes bits of the linked libraries. Dynamic linking to shared libraries might be derivation - inclusion of headers and inlines might be enough. True dynamic linking (late binding, runtime interface discovery etc.) IMO cannot be derivation since no part of the library is in the exe - in fact the exe can easily be linked to a library which wasn't written at the time the exe was created, hence the exe cannot possibly be a derived work of that library.
This sort of stuff has been discussed a lot for a long time so it's not really a question of if word "got out" - more like it just hasn't been tested in court anywhere.
On the GPLv3, I don't think the problem can be fixed even if it was turned into a EULA, I think the desired allowed / not-allowed cases are impossible to clearly distinguish across the range of current (let alone future) development/target environments.
Yep - MS does not give a blanket redistribution licence for windows libraries - and therefore you are NOT ALLOWED to redistribute them. Moreover recent versions of windows will actively prevent system libraries being installed by applications - (only allowed by OS service pack / hotfix installs).
MS does give redistribution licence for a lot of stuff - but not everything, eg. not that long ago if your app used features of the new comctl32.dll the only way to legally ship it was to ship IE (which installed it), as comctl32.dll was not redistributable any other way. Yes you could pull the dll out of system32 and put it in your install, yes it (sometimes) worked, but it was NOT legal to ship.
Note that NONE of this gives MS any rights over your code by the act of linking to theirs - they only have rights over their code. The SAME applies to the GPL - the readline authors don't have any rights over your code just becuase you link to it. HOWEVER, in either case IF you want to distribute someone elses code, THEN you have to follow terms agreed with them.
Also, if you link to two libraries with conflicting terms (like eg. MS saying you may not ship source code, and GPL saying you must) then you can't legally ship. That applies to any two licences - GPL or not is irrelevant - if they conflict they conflict.
NB: all the above is assuming distributing a statically-linked executable, which clearly constitutes distributing the linked components.
Once we get into dynamic linking, or indeed the GPL's system libraries exception, then it gets a whole lot more complicated - and in fact I also think that the FSF position in those areas doesn't hold up. The GPL was written for static linked (all there was then) C programs on early commercial unix, and in that context it works ok - start trying to stretch it over the full range of current development languages/environments etc. and it quickly looks pretty thin IMO. GPL v3 is supposed to address all this - and funnily enough it seems to be taking them an awfully long time to write...
If I want to distribute a windows program linked to an MS library I have to have a licence from MS which permits me to distibute the library and/or a program linked to the library. Same goes for any library you don't own, on any system.
Note that the GPL does however contain an exception for linking to system libraries that come with the operating system. That is how you can GPL Emacs for Windows* (or Solaris or AIX or...).
*Note that ironically the history of Emacs for Windows wrt. GPL is in fact rather interesting - the system libraries exception gets tricky when there aren't any libraries with the system but only with separate, proprietary, compilers. See eg. these threads.
Re:This is old news
on
Nanotechnology
·
· Score: 3, Funny
Windows 2000 also introduces a significant change in the overall role of the registry. It's no longer the preferred place to store an application's configuration data. Storing large chunks of data in the registry can take up a lot of room, especially on shared computers. Applications now must use special system folders to save user settings, application data, and temporary files.
Not that MS giving up on it seems to have stopped people saying that Linux needs a registry for application configuration data.
Application configuration files on Windows are now supposed to be (real, not angle-bracket-free) XML, just google for "application configuration files" - not hard to find really.
I'm sure Al Qaida would love to develop nanobots that proceed to liquefy any person who has Anglo-Saxon genes, but scanning-tunneling electron microscopes and other equipment cost money, dude.
a) Bin Laden was never short of a few (hundred) million, and I doubt the US has got hold of all his assets even now.
b) They would want to "liquefy" by religion, which isn't genetic - the Taleban had the death penalty for converting to christianity (how do you convert your genes ?).
Slashdot Mirror
It's obvious that the FTC knows that cell phones don't cause problems, otherwise there would be a required upgrade for all airplanes
On that basis it's obvious that they know that eg. kapton wiring doesn't cause problems otherwise there would be a required replacement program.
Guess what ?
- it _does_ cause crashes
- it is not used on most new aircraft because of its safety record
- but there is no requirement to replace it on old aircraft
Why ? - because it is unfeasibly expensive.
Using a mobile on a plane will not automatically cause a crash, but there is a real risk that it might. Same applies to using a gun or a knife - in the history of flight hundresds of thousands of guns and knives will have been used on planes without incident. Doesn't matter - there is a risk, which they are acting to reduce, so you eat your meal with bendy plastic and you don't use your phone.
By the way if _you_ read the article you would know that the effect was found with the transmitter 30cm from the instrument or its wiring harness. Instrument wiring is all over planes. Literally miles of it. There WILL be wiring within 30cm of your seat and/or overhead locker.
Tank inerting has been proposed for civil after twa800, based on it being what the military do to reduce that risk.
eg. google for: twa 800 inert gas fuel tank
I'm well aware of the differences between military and civil flying - which is what I was pointing out in my post.
And yes I do know transports don't have ejector seats. "quite rare" or not, there are some a/c I'm not getting in, and the V22 is one...
Actually since you ask, I don't think they did have anything to do with it. No one has ever actually confirmed that the fight got to the cockpit - they've still refused to release the tapes.
Plenty of other theories though - see here for instance.
Debris field is the most suspicious for me. Somehow those fighting civilians and terrorists managed to blow an engine off the wing in mid air. Me, I can't see the mechanism for that. Short range IR guided AA missile on the other hand - yep I can see "blow the engine off the wing" as the result there.
Mobiles transmit regularly to register with a base station so they can receive calls. They do this more often when they lose contact with base station and need to search for another one, eg. when they are moving.
Unfortunately in this case the overflow is in the hardware in the wiring. To fix it you need to rip the machine down to bare metal and replace every component with a cricuit board with a new one.
Cheaper to buy a new machine.
Pity you have a few hundred of them and they cost $100M a pop... but never mind, sure the user will pay for it.
Yeah but that's a new aircraft being designed now.
Aircraft in design now will be starting flying in 5 years (eg. A380 commenced 2000 in service target 2006.
So assuming your aircraft is brand new you could be confident that any consumer electronics over five years old would be safe. Not that helpful really. How many cellphones do you have that are > 5yrs old ?
(De)merits of kapton aside - just becuse the military ban something doesn't make it bad/good on commercial aircraft. eg. I think many military aircraft fly with inerted (inert gas in airspace) fuel tanks, but on the other hand they flew with fly-by-wire long before it was allowed in commercial.
If you've got numbers on relative safety records of military vs. commercial aircraft it would be interesting - but I think you'll find the military have the worse record.
Mind you, the military also have chutes/ejector seats, which commercial won't even give you in first!
That would be the one which flew into the ground shortly after for as yet unknown reasons, right ?
Because the airlines can test and certify the particular equipment they are installing / permitting.
..."
Quote:
âoeOur technical teams have worked diligently to demonstrate that wireless applications comply with rigorous aviation standards
They could also test and certify cellphones - but they won't because a) they know from existing results that the tests would fail and b) the telco industry doesn't want cellphones on thousands of feet up anyway because the cell system can't cope with it either.
Interference is most likely being picked up by the wiring not by the actual instruments. Installing a new wiring loom in an aircraft is not trivial (I'm not even sure it's _possible_).
Then they have to re-certify for flight since they just changed all the wiring (you want to make sure it's safe right ?). Then they have to do it all again a few months later when the next wireless gadget "standard" comes out ?
that would mean the wind blows in towards the building from all sides !? - that's well wierd wind.
... does^H^H^H^H can ...
- (s)he can also check your post before you hit submit... [coding alone]
If XP is the answer, you didn't understand the question
With XP it doesn't matter because your pair-programming buddy on your shoulder does can understand the question while you code.
Nope - as discussed many times before they were in different orbit without anywhere near enough fuel to get to ISS.
There are a lot of other things they might have been able to do though. Stuff I've read included dumping excess weight/cargo, changing reentry profiles to reduce left wing heating, spacewalk inspect/repair, unmanned resupply rocket, shuttle rescue mission - all _possible_, but maybe not practical. Reaching ISS was not possible.
SCO have said on occaisions that it is not just the kernel code that is at issue. In GNU terms the system is Linux Kernal + GNU, so it must therefore be that there are issues with the GNU bit of GNU/Linux.
RMS has clearly noticed this and responded by saying that the GNU bit is safe because the FSF have copyright assignments from contributors and their employers.
Teeny weeny flaw there - if IBMer put code into GNU who will the FSF have copyright assignment from ? - yep, IBM. If SCO is right and it wasn't IBM's code to assign then all RMS has is toilet paper.
yeah but so does sco (and anyone who employs a lawyer) - no ?
... I'll sue you!
(punchline of old joke):
God:
Satan: Oh yeah, and where are _you_ going to find a _lawyer_ ?
$companyYYY are alleging that $personBad working for $CompanyXXX contributed code they got from $companyYYY, and they are suing $companyXXX for it and warning you that you could be next.
Exactly how do your signed statements from $companyXXX help against $companyYYY ???
[ all they do is demonstrate that you acted in good faith - but proving the code was distributed to you claiming to be under the GPL would do that anyway ]
"If, as a consequence of [stuff] conditions are imposed on you that contradict [the GPL] [...then]"
ummm what conditions have been imposed on SCO ?
Linking can be derivation, depending on how it's done. A work which includes (significant) bits of the original is derived - a statically linked executable includes bits of the linked libraries. Dynamic linking to shared libraries might be derivation - inclusion of headers and inlines might be enough. True dynamic linking (late binding, runtime interface discovery etc.) IMO cannot be derivation since no part of the library is in the exe - in fact the exe can easily be linked to a library which wasn't written at the time the exe was created, hence the exe cannot possibly be a derived work of that library.
This sort of stuff has been discussed a lot for a long time so it's not really a question of if word "got out" - more like it just hasn't been tested in court anywhere.
On the GPLv3, I don't think the problem can be fixed even if it was turned into a EULA, I think the desired allowed / not-allowed cases are impossible to clearly distinguish across the range of current (let alone future) development/target environments.
Yep - MS does not give a blanket redistribution licence for windows libraries - and therefore you are NOT ALLOWED to redistribute them. Moreover recent versions of windows will actively prevent system libraries being installed by applications - (only allowed by OS service pack / hotfix installs).
MS does give redistribution licence for a lot of stuff - but not everything, eg. not that long ago if your app used features of the new comctl32.dll the only way to legally ship it was to ship IE (which installed it), as comctl32.dll was not redistributable any other way. Yes you could pull the dll out of system32 and put it in your install, yes it (sometimes) worked, but it was NOT legal to ship.
Note that NONE of this gives MS any rights over your code by the act of linking to theirs - they only have rights over their code. The SAME applies to the GPL - the readline authors don't have any rights over your code just becuase you link to it. HOWEVER, in either case IF you want to distribute someone elses code, THEN you have to follow terms agreed with them.
Also, if you link to two libraries with conflicting terms (like eg. MS saying you may not ship source code, and GPL saying you must) then you can't legally ship. That applies to any two licences - GPL or not is irrelevant - if they conflict they conflict.
NB: all the above is assuming distributing a statically-linked executable, which clearly constitutes distributing the linked components.
Once we get into dynamic linking, or indeed the GPL's system libraries exception, then it gets a whole lot more complicated - and in fact I also think that the FSF position in those areas doesn't hold up. The GPL was written for static linked (all there was then) C programs on early commercial unix, and in that context it works ok - start trying to stretch it over the full range of current development languages/environments etc. and it quickly looks pretty thin IMO. GPL v3 is supposed to address all this - and funnily enough it seems to be taking them an awfully long time to write...
The logic is not flawed - it is in fact correct.
If I want to distribute a windows program linked to an MS library I have to have a licence from MS which permits me to distibute the library and/or a program linked to the library. Same goes for any library you don't own, on any system.
Note that the GPL does however contain an exception for linking to system libraries that come with the operating system. That is how you can GPL Emacs for Windows* (or Solaris or AIX or...).
*Note that ironically the history of Emacs for Windows wrt. GPL is in fact rather interesting - the system libraries exception gets tricky when there aren't any libraries with the system but only with separate, proprietary, compilers. See eg. these threads.
yeah but wtf kind of bot was a "Shazbot" ?
Page viewing != reading.
Page viewing == lots (google slashdot effect)
Reading == yeah probably somewhere around 26
Now the question is which most correlates with dumb consumers who click ads...
from MS article from 1999 here.
Not that MS giving up on it seems to have stopped people saying that Linux needs a registry for application configuration data.
Application configuration files on Windows are now supposed to be (real, not angle-bracket-free) XML, just google for "application configuration files" - not hard to find really.
I'm sure Al Qaida would love to develop nanobots that proceed to liquefy any person who has Anglo-Saxon genes, but scanning-tunneling electron microscopes and other equipment cost money, dude.
a) Bin Laden was never short of a few (hundred) million, and I doubt the US has got hold of all his assets even now.
b) They would want to "liquefy" by religion, which isn't genetic - the Taleban had the death penalty for converting to christianity (how do you convert your genes ?).