In reply comments at the bottom of TFA you see they are NOT talking about de-orbiting things this way, only making minute changes in orbit to avoid collisions.
Perhaps preventing collisions allows natural decay to remove debris faster than it accumulates, but other than that, their plan was not about de-orbit of debris.
It gets my blood pressure up a bit every time I read about "revealing" someone's SSN as having penetrated an inner sanctum. The password-secret treatment of that number needs to be dropped. It's time for legislation in the US that makes it invalid and indefensible in court to treat knowledge of an SSN as an authentication factor. Any organization that treats knowledge of the SSN as an authentication factor should be fully liable for the consequences of any fraud that results.
Note I'm talking about authentication, not identification. Nobody thinks Google shouldn't be able to identify the contestants, and an SSN is more unique than names. The problem only comes from the ability to use that number as a "password" to authenticate for access to things (like bank accounts). Treating the SSN as a "username" would not cause the problem; it's using it as an authenticating secret despite the fact that it's easily accessible that makes revealing it a terrible security lapse.
Knowing your SSN should be no more helpful to a fraudster than knowing your full name or hair color. It should be treated as information too readily available to be of any use for authentication. Reliance on that kind of information for authentication should be evidence of failure in due diligence, and lead to liability for that inappropriate reliance. If your bank lets someone take all the money out of your account just because they know your full name they should be liable. If they do just because they knew your SSN it should be treated the same way.
On re-reading the grandparent post, it seems even more likely it was just a typo of 'DC' for Damage Control. I say that because it wasn't referring to actual steam lines, but rather drains.
Some auxiliary steam lines might be zebra fittings and secured for General Quarters, but steam to primary mission systems like the catapults on a carrier would only be secured if actually damaged, not as a precaution. Most drains however are secured for condition zebra.
So it was more like "...steam lines, leading to condensation, requiring additional drains... and the additional DC valves to go with them."
'DZ' may be a broken reference to "Zebra Fittings", meaning valves that must be shut in every compartment when the ship goes to material condition Zebra (as for General Quarters or Battle Stations). Electrical systems are controlled at a central switchboard, but at every point where a steam line crosses a water-tight bulkhead, there will be additional valves that can be secured to isolate that space for damage control purposes. Those valves bring additional maintenance themselves.
The 'D' means that fitting would be secured for Darken Ship also, which would be odd for a steam valve. An external door would be marked 'DZ', or "Dog Zebra", because you would secure it for either condition Zebra or for Darken Ship.
Roger that. An AC posted the relevant part of the Contribution agreement above: "User hereby irrevocably and perpetually assigns, transfers, conveys and sets over to OISF, and OISF hereby accepts the assignment, transfer, conveyance and set over, User's entire worldwide and perpetual right, title and interest in and to the Materials including but not limited to all Intellectual Property Rights in the Materials. User will give OISF or its designee all assistance reasonably required to register, perfect, enforce and apply for and obtain in OISF's name patent, copyright, trademark and other Intellectual Property Rights in any and all jurisdictions"
I guess the remaining question is, does SNORT use the same smelly tactic?
"The Suricata Engine and the HTP Library are available to use under the GPLv2."
Followed on page 2 of same by this: "Membership in the OISF Consortium Group provides a non-gpl limited license for the Suricata IDS engine in return for ongoing support. There are multiple tiers available for consortium participation that simplify the varying levels of support and involvement possible for all types of interest. Contributions may range from man hours in development assistance, technology donations, hardware and infrastructure, to financial assistance."
I get that if the code is their copyright, they can dual license at will. But doesn't the above mean any contributions from either a community or "Membership" cannot themselves be GPL, since any code accepted will in turn be distributed "non-gpl" among the membership? Also, are there "multiple tiers" of "non-gpl limited license"?
Is there an obvious plan for the crawler failing half way up the cable? In this test you just set it down with the chopper, but what do you do half way to geosync orbit?
I guess a second crawler has to go up underneath the failed one, trigger some kind of mechanical release and carry its dead weight down.
Remember how that went down:
1. Utah judge agrees with Novell in Summary Judgements that SCOX did not get the copyrights, that they owe Novell money, and are guilty of conversion.
2. Novell tells the judge that SCOX is about to go bankrupt and that he should put the money in constructive trust.
3. SCOX successfully convinces the judge that they are NOT about to go bankrupt, and the judge says there is no need before the trial.
4. On the Friday before the trial was to start Monday, 17 September, 2007, SCOX declares bankruptcy in New Jersey, causing an automatic stay in Utah.
5. Novell asks the BK judge to lift the stay.
6. Today, the BK judge agreed.
7. Now the SCOX v. Novell case in Utah will go before that judge, who may not be happy with the way he was very publicly suckered and made to look foolish by SCOX's bankruptcy ploy.
Documenting, as the invevitable next step, every impractical wish list available (i.e. Flying Car, Regional Heliocopter Airports, internet connected toasters, space elevators, and hydrogen fuel cell cars): Popular Mechanics and Popular Science.
I'm really not that cynical, and I like the magazines, but reporting on likely, sensical new technology is not their forte (or mission).
The US Navy used to do networking over a Codenoll Passive Star network. The modified 10Base-FL NICs sent transmit pulses to passive hub, which optically coupled all the rcv/xmt ports together in what was essentially a fused glass blob. Codenoll calls it 10Base-FP.
The useful thing about it was being completely unpowered. The passive hub could stuffed into/behind anything where the fiber could reach it and there was no configuration, power, management, etc. Of course, those were also its weakness: no configuration, management, etc. A lot of these were installed in the early 90's, but I don't think the Navy uses them any more.
No, and I didn't mean to imply I got or was asked for anything personally.
I'm refering of course to the attempt to convince everyone to pay them $699 per workstation (costing me $2100 for a laptop and two workstations if I was silly enough to pay it), and I believe it was like $1299 or so per server, for using almost any version of Linux. They also attempt to claim that software "Methods and Concepts" somehow NOT embodied in code are yet still breaches of protectable IP they can sue over. They also claim Linux would not have become an enterprise-grade platform without stealing their IP to do it. They very publicly claimed to already have direct evidence, which they trumpeted for over a 2000% gain in their stock price, then went shy and retiring when asked to show that evidence in court. But I did not mean to list the sins of SCOX(E).
Back to my original point. Many of SCOX(E)'s claims have been ridiculed and called into question. Remember "astonishing lack of evidence" from Judge Kimball. But that's not the same, or as usefull for citing as precedence in the future, as the court flatly declaring those claims wrong. I was just musing that it might be a shame for the whole thing fall into the pit of bankruptcy court before the summary judgements and decisions from the bench give us some armor against SCOX(E)-II hoping to score big off other people's work.
If there are no useful decisions left to make that would be precluded by the collapse of SCOX(E), then, by all means, I look forward to pointing at the shuttered office building wrapped in crime scene tape in Lindon, Utah where SCO used to scheme, and laughing looong and hard! For extra gut-busting mirth, it would be cool to see Darl and Co. coming out of said building with a FED on each arm and their jacket hiding the cuffs.
Think Boise will represent them pro bono at the criminal procedings?:-)
"This motion will likely bankrupt SCO if granted."
Seeing SCOX(E) bankrupt after claiming I owe them thousands of dollars for running Linux-based OS's on a couple machines will be satisfying. But I wonder if it has a little tinge of missing the point, like convicting a murderous gangster for tax evasion? Are there any legal declarations we'd still like to see come out of these procedings, that might be short-circuited by pre-trial SCOX(E) death? Any of their claims that not surviving to the end of the leagal battle would prevent us from getting clear decisions from the court on? Like their attempt to use "Methods and Concepts" in strange places, and to go directly to extortion of end-users over unproven allegations of improper distribution, etc.
Yeah, pretty dumb... could have at least got 320/8 = x straight...
I'll just copy the data and let the smart people figure out how fast is should be going. If there are config issues to be solved by the smart ones though, it still seems to be inside the host (as opposed to HBA/FC) because the same performance holds for local disk-to-disk copy, no errors, just slower than maybe it should be.
Shuttin' up while I save up for a shiny new clue...:-)
We have a 30TB EMC CX-500 with Brocade 2Gb FC backbone. The bench moves blocks of a few hundred GB to a dozen servers or less. We have never come anywhere near %50 utilization on the FC.
The transfers run about 4-6hrs and I was looking for choke points to shorten the time. The data simply won't go to disk any faster on the U320 SCSI bus. We consistently measure 20MBps max to disk, which makes sense. U320 means 320Mbps/8 = 20MBps. So I get the same max numbers for local disk-to-disk that I get for SAN-to-disk, and the same results regardless of OS. If this rate could be maintained, six servers doing the transfer should just about saturate the backbone, but the overhead of file access and FS management mean the max is only maintained for a moment as a few particularly large files come across. With lots of smaller files being copied, the average rate goes down to 2MBps.
If these servers had to be optimized for SAN-to-Disk transfer rate, they would have to have multiple SCSI controllers and HBAs, paired up on seperate PCI busses, and the data would have to be optimized with fewer/larger files.
Of course, the 2.5TBps link is of interest to ISPs and regional carriers not server labs, but I thought I'd throw in what we've seen on the utilization of a 2Gbps FC link in a SAN setup.
PJ has said, many times, so as to be legaly liable for the accuracy of her statements, that she gets no support from any of the litigants in this mess. IBM flatly said it in a court document, very much legaly resposible for the accuracy of their statement. PJ is not getting any money from IBM.
She does, however, every once in a while, get a PayPal donation from me. She gets my support becuase she is so classy, honest, open, and well documented in her handling of... well, your sort...
This seems to me to be a reasonable change to the law: As long as the creator of the content owns the copyrights, they last 40 years. The balance belongs to the estate if the creator dies, to the end of the 40 years. However, upon transfer of the copyright to ANY other entity, the copyright lasts a maximum of 20 more years, or the end of the original 40 year period, whichever is shortest.
This would incentivize KEEPING copyright. You could maintain your control 20 years, then sell it Sony, who would get 20 years out of it. If you sell it to Sony after two years, then Sony still gets 20 years of benifit, and the copyright will end after 22 years.
Slashdot Mirror
In reply comments at the bottom of TFA you see they are NOT talking about de-orbiting things this way, only making minute changes in orbit to avoid collisions.
Perhaps preventing collisions allows natural decay to remove debris faster than it accumulates, but other than that, their plan was not about de-orbit of debris.
It gets my blood pressure up a bit every time I read about "revealing" someone's SSN as having penetrated an inner sanctum. The password-secret treatment of that number needs to be dropped. It's time for legislation in the US that makes it invalid and indefensible in court to treat knowledge of an SSN as an authentication factor. Any organization that treats knowledge of the SSN as an authentication factor should be fully liable for the consequences of any fraud that results.
Note I'm talking about authentication, not identification. Nobody thinks Google shouldn't be able to identify the contestants, and an SSN is more unique than names. The problem only comes from the ability to use that number as a "password" to authenticate for access to things (like bank accounts). Treating the SSN as a "username" would not cause the problem; it's using it as an authenticating secret despite the fact that it's easily accessible that makes revealing it a terrible security lapse.
Knowing your SSN should be no more helpful to a fraudster than knowing your full name or hair color. It should be treated as information too readily available to be of any use for authentication. Reliance on that kind of information for authentication should be evidence of failure in due diligence, and lead to liability for that inappropriate reliance. If your bank lets someone take all the money out of your account just because they know your full name they should be liable. If they do just because they knew your SSN it should be treated the same way.
On re-reading the grandparent post, it seems even more likely it was just a typo of 'DC' for Damage Control. I say that because it wasn't referring to actual steam lines, but rather drains.
Some auxiliary steam lines might be zebra fittings and secured for General Quarters, but steam to primary mission systems like the catapults on a carrier would only be secured if actually damaged, not as a precaution. Most drains however are secured for condition zebra.
So it was more like "...steam lines, leading to condensation, requiring additional drains... and the additional DC valves to go with them."
'DZ' may be a broken reference to "Zebra Fittings", meaning valves that must be shut in every compartment when the ship goes to material condition Zebra (as for General Quarters or Battle Stations). Electrical systems are controlled at a central switchboard, but at every point where a steam line crosses a water-tight bulkhead, there will be additional valves that can be secured to isolate that space for damage control purposes. Those valves bring additional maintenance themselves.
The 'D' means that fitting would be secured for Darken Ship also, which would be odd for a steam valve. An external door would be marked 'DZ', or "Dog Zebra", because you would secure it for either condition Zebra or for Darken Ship.
Roger that. An AC posted the relevant part of the Contribution agreement above:
"User hereby irrevocably and perpetually assigns, transfers, conveys and sets over to OISF, and OISF hereby accepts the assignment, transfer, conveyance and set over, User's entire worldwide and perpetual right, title and interest in and to the Materials including but not limited to all Intellectual Property Rights in the Materials. User will give OISF or its designee all assistance reasonably required to register, perfect, enforce and apply for and obtain in OISF's name patent, copyright, trademark and other Intellectual Property Rights in any and all jurisdictions"
I guess the remaining question is, does SNORT use the same smelly tactic?
From the OISF Download page:
"The Suricata Engine and the HTP Library are available to use under the GPLv2."
Followed on page 2 of same by this:
"Membership in the OISF Consortium Group provides a non-gpl limited license for the Suricata IDS engine in return for ongoing support. There are multiple tiers available for consortium participation that simplify the varying levels of support and involvement possible for all types of interest. Contributions may range from man hours in development assistance, technology donations, hardware and infrastructure, to financial assistance."
I get that if the code is their copyright, they can dual license at will. But doesn't the above mean any contributions from either a community or "Membership" cannot themselves be GPL, since any code accepted will in turn be distributed "non-gpl" among the membership? Also, are there "multiple tiers" of "non-gpl limited license"?
Now, to see how much explosives it takes to MAKE it fail!
This is my favorite part! :-)
Insurance fraud!
Is there an obvious plan for the crawler failing half way up the cable? In this test you just set it down with the chopper, but what do you do half way to geosync orbit?
I guess a second crawler has to go up underneath the failed one, trigger some kind of mechanical release and carry its dead weight down.
The bankruptcy judge in New Jersey has lifted the stay on SCOX's suit in Utah.
:-)
Remember how that went down:
1. Utah judge agrees with Novell in Summary Judgements that SCOX did not get the copyrights, that they owe Novell money, and are guilty of conversion.
2. Novell tells the judge that SCOX is about to go bankrupt and that he should put the money in constructive trust.
3. SCOX successfully convinces the judge that they are NOT about to go bankrupt, and the judge says there is no need before the trial.
4. On the Friday before the trial was to start Monday, 17 September, 2007, SCOX declares bankruptcy in New Jersey, causing an automatic stay in Utah.
5. Novell asks the BK judge to lift the stay.
6. Today, the BK judge agreed.
7. Now the SCOX v. Novell case in Utah will go before that judge, who may not be happy with the way he was very publicly suckered and made to look foolish by SCOX's bankruptcy ploy.
It will be interesting to watch... on Groklaw.
Documenting, as the invevitable next step, every impractical wish list available (i.e. Flying Car, Regional Heliocopter Airports, internet connected toasters, space elevators, and hydrogen fuel cell cars): Popular Mechanics and Popular Science.
I'm really not that cynical, and I like the magazines, but reporting on likely, sensical new technology is not their forte (or mission).
Who did the estimates of the billions lost by Google?
:-)
Wasn't the RCMP, was it?
Wow. Learn something new every day. Where do they keep it? :-P
"Nobody knew I was sunburned, drinking from a coconut and listening to howler monkeys as I replied to their e-mails."
Hey, you! Stop hanging around my cubicle!
Damn hippies!
The US Navy used to do networking over a Codenoll Passive Star network. The modified 10Base-FL NICs sent transmit pulses to passive hub, which optically coupled all the rcv/xmt ports together in what was essentially a fused glass blob. Codenoll calls it 10Base-FP.
The useful thing about it was being completely unpowered. The passive hub could stuffed into/behind anything where the fiber could reach it and there was no configuration, power, management, etc. Of course, those were also its weakness: no configuration, management, etc. A lot of these were installed in the early 90's, but I don't think the Navy uses them any more.
No, and I didn't mean to imply I got or was asked for anything personally.
:-)
I'm refering of course to the attempt to convince everyone to pay them $699 per workstation (costing me $2100 for a laptop and two workstations if I was silly enough to pay it), and I believe it was like $1299 or so per server, for using almost any version of Linux. They also attempt to claim that software "Methods and Concepts" somehow NOT embodied in code are yet still breaches of protectable IP they can sue over. They also claim Linux would not have become an enterprise-grade platform without stealing their IP to do it. They very publicly claimed to already have direct evidence, which they trumpeted for over a 2000% gain in their stock price, then went shy and retiring when asked to show that evidence in court. But I did not mean to list the sins of SCOX(E).
Back to my original point. Many of SCOX(E)'s claims have been ridiculed and called into question. Remember "astonishing lack of evidence" from Judge Kimball. But that's not the same, or as usefull for citing as precedence in the future, as the court flatly declaring those claims wrong. I was just musing that it might be a shame for the whole thing fall into the pit of bankruptcy court before the summary judgements and decisions from the bench give us some armor against SCOX(E)-II hoping to score big off other people's work.
If there are no useful decisions left to make that would be precluded by the collapse of SCOX(E), then, by all means, I look forward to pointing at the shuttered office building wrapped in crime scene tape in Lindon, Utah where SCO used to scheme, and laughing looong and hard! For extra gut-busting mirth, it would be cool to see Darl and Co. coming out of said building with a FED on each arm and their jacket hiding the cuffs.
Think Boise will represent them pro bono at the criminal procedings?
"This motion will likely bankrupt SCO if granted."
Seeing SCOX(E) bankrupt after claiming I owe them thousands of dollars for running Linux-based OS's on a couple machines will be satisfying. But I wonder if it has a little tinge of missing the point, like convicting a murderous gangster for tax evasion? Are there any legal declarations we'd still like to see come out of these procedings, that might be short-circuited by pre-trial SCOX(E) death? Any of their claims that not surviving to the end of the leagal battle would prevent us from getting clear decisions from the court on? Like their attempt to use "Methods and Concepts" in strange places, and to go directly to extortion of end-users over unproven allegations of improper distribution, etc.
"...so everyone would understand that the money to finance the EU should come from the benefits engendered by the EU"
Did the EU invent texting before or after Al Gore invented the internet?
"...alcohol-powered robots cannot be far."
Some of them work in the cubicle next to mine...
...as scientificaly demonstrated by Tom Hanks in Cast Away with an ice-skate blade and a rock!
That scene still gives me the heebie jeebies just remembering it!
Yeah, pretty dumb... could have at least got 320/8 = x straight...
:-)
I'll just copy the data and let the smart people figure out how fast is should be going. If there are config issues to be solved by the smart ones though, it still seems to be inside the host (as opposed to HBA/FC) because the same performance holds for local disk-to-disk copy, no errors, just slower than maybe it should be.
Shuttin' up while I save up for a shiny new clue...
Coffee what's that? :-)
We have a 30TB EMC CX-500 with Brocade 2Gb FC backbone. The bench moves blocks of a few hundred GB to a dozen servers or less. We have never come anywhere near %50 utilization on the FC.
The transfers run about 4-6hrs and I was looking for choke points to shorten the time. The data simply won't go to disk any faster on the U320 SCSI bus. We consistently measure 20MBps max to disk, which makes sense. U320 means 320Mbps/8 = 20MBps. So I get the same max numbers for local disk-to-disk that I get for SAN-to-disk, and the same results regardless of OS. If this rate could be maintained, six servers doing the transfer should just about saturate the backbone, but the overhead of file access and FS management mean the max is only maintained for a moment as a few particularly large files come across. With lots of smaller files being copied, the average rate goes down to 2MBps.
If these servers had to be optimized for SAN-to-Disk transfer rate, they would have to have multiple SCSI controllers and HBAs, paired up on seperate PCI busses, and the data would have to be optimized with fewer/larger files.
Of course, the 2.5TBps link is of interest to ISPs and regional carriers not server labs, but I thought I'd throw in what we've seen on the utilization of a 2Gbps FC link in a SAN setup.
PJ has said, many times, so as to be legaly liable for the accuracy of her statements, that she gets no support from any of the litigants in this mess. IBM flatly said it in a court document, very much legaly resposible for the accuracy of their statement. PJ is not getting any money from IBM.
She does, however, every once in a while, get a PayPal donation from me. She gets my support becuase she is so classy, honest, open, and well documented in her handling of... well, your sort...
This seems to me to be a reasonable change to the law: As long as the creator of the content owns the copyrights, they last 40 years. The balance belongs to the estate if the creator dies, to the end of the 40 years. However, upon transfer of the copyright to ANY other entity, the copyright lasts a maximum of 20 more years, or the end of the original 40 year period, whichever is shortest.
This would incentivize KEEPING copyright. You could maintain your control 20 years, then sell it Sony, who would get 20 years out of it. If you sell it to Sony after two years, then Sony still gets 20 years of benifit, and the copyright will end after 22 years.