So what you're saying is that Google has decided to fully claim reputation-ownership of the mail their users are sending. They're staking their reputation that their users don't generally spam. If it was a big enough problem you would blackhole all of gmail, right now you're upset because due to the large volume that gmail sends, any percentage of spam is a problem.
I don't mean to attack or defend anyone here, just curious.
I think the deal is just that anything that comes through gmail needs a more heuristics based filter, and you can't just blackhole on the particular client. As long as the percentage of bad e-mails coming through there is lower than the percentage of good e-mail then the reputation system is working...
That's a great point... We should make available a "time-locked" version of wikipedia. That jurors can browse and lookup information without risk of contamination for a particular case!
You've got options:
1. Get yourself cremated (or dumped into a volcano)
2. Make sure your body is dumped in a pig farm
3. Make sure your body is diced into pieces, and then dumped at sea
4a. Don't do anything noteworthy (preferably with the above)
4b. Do something so noteworthy that you are beloved. State that you must not be embalmed, make sure they plant some real plants above your grave, and make sure there's access for rainwater and natural light in the shrine that would be your tomb. This is a tricky balancing act as you need to be naturally exposed enough to decompose, but protected enough that your fanatic fans won't disinter you for totems (like they did for saints).
The relative statement in the article "age = 30 years" tells us less than "age = 30 years + 50million years travel time" -- effectively you need a second separate statement to get the same information.
I guess I just preferred the information about the distance to be more local to the information about the age. I had to search to know if there was a chance humans would ever see it. It seems like 50million light years is just so far that it's unlikely something recognizable as humans will ever get to this black hole.
That was how I visualized it. The age (relative to our frame) was not 30 years, the age was 30 years + our estimate as to the distance of the ex-star from us.
Why does *our frame* matter so? If we posit that it is in a galaxy 50 million light-years away, we can conceive of the frame of reference that contains both, no? We know it took 50 million + 30 years for the light beam and its information to reach us.
To me that's a pretty definitive age. Should I not think of things that way?
It was 30 years old, 50 million years ago. I guess the claim re: young black hole is more due to the age apparent in the images we're capturing now, then the actual age of the black hole.
Android CPUs are pretty slow. I bet that + the rest of the platform's immaturity is what's hanging them up. Sure *technically* you can write your code in c/c++ but you end up having to personally import every damn library from the STL up.
I think you're wrong. Station Wagon (SW) would equate to thousands of pigeon-carrying-capacities (PCC). When you're dealing with that datavolume, you end up with significant overhead at each end. Generating the packet burst, and tieing them to individual pigeons, and then sending them; Subsequently you need to accept the incoming PigeonPackets (PP) reorder them, and then read them back in. With SWs you can use much higher density drives, and they need much less processing to load into the SW. I imagine with a pigeon load in the thousands, you'll have a fairly significant attrition rate, and you won't know which packets go missing till you've received them. In fact arbitrary pigeons might just exhibit really high latency, and PETA might be unhappy if you try to implement strict TTLs on them. While a SW needs to follow road rules, those are infact just routing considerations, and as such help the network stay robust. With PPs you have to worry about tons of sources of packet loss. If your SW packet arrives, you can usually treat that as atomic success; (Ignoring the risk of highway robbery) and you have to worry less about your data integrity.
In conclusion if your data density is above 10 PCCs I'd say a SW would be a better bet.
Note: using a RAID scheme could allow for higher attrition rates.
Actually, that one we can blame on a timing / implementation glitch in the dynamic interface for commenting now. I clicked the preview button and for some reason the request was taking a long time to complete. I started to think I wanted to add something to the end of my comment. Right as I started to type it turned into the read-only preview bubble (with my original comment/sin/ 'A'). Apparently in spite of that, it still submitted my now edited text as the true comment, even though I still have the tab open and it clearly shows that my UI thinks that the "A" was not part of the comment.
But that's an important distinction. Some buyers might think the battery actually lasts 5 years... Not the optimistic numbers manufacturers always claim. By having a lease agreement that would add up to a new battery in 10 years is a functional guarantee. That's a hell of a lot of peace of mind.
Don't argue with a fool because people around you won't know who is which.
It's safer to cede the situation with some platitude like "we should agree to disagree" or simply walk away. Anyone who actually degrades your social status for that action should really not be part of your measuring group.
As an Engineer myself I find your comment irritating. Sure any organization that has lived for a respectable amount of time has a certain percentage of people continuously trying to cover their asses. The thing you missed is that NASA wasn't asking the Engineers "how long can it last?" They were telling the Engineers "it must last 90 days, weigh less than X, take up Y space, generate no more than Z interference, cost less than C...". Having a hard stop of lasting 90days and throwing engineers at the problem means they can't give any average age or expectation. Every expected fragile component was replicated in triplicate, time money and other constraints permitting. They had to demonstrate that any realistic scenario was covered from every angle. They literally had to account for unknown unknowns. Voyager just had a single bit flipped on the OS. The last I heard people think this could literally have been a cosmic ray. A particle moving close to the speed of light managed to hit a particular atom that generated enough energy to change the value in a tiny piece of the computer. --> AND they recovered from that!
I've got to give them credit. Just brushing away their work surviving for much longer than their minimum is not acknowledging their accomplishments appropriately. They had effectively one shot at performing the mission they designed for. Normally estimates for life are fuzzy things with ill defined edges. They polished and polished and got the lowerbound edge to be as sharp as possible. Necessarily that pushed out the definition of the *average* expected lifespan and death estimate. I'm glad I don't have the stress their job must entail, but I wish I could be so specific about the likelihood of death of my software.
Multi-licensing where the battleship version is very easy to get for $LARGE_NUM while the normal license is sold at most retailers for $SLIGHTLY_SMALLER_NUM
Depending on the design of the phone, you could engineer your blackberry to wipe itself if the phone gets turned off, or if the case gets open, etc. All of those are physical security devices that could be bypassed with sufficient time. This includes if they created a single all-in-one chip that was included everything except for power management in one tiny piece of silicon (not currently the blackberry design because it would be cost prohibitive)
Acknowledging that the above aren't really a factor, then take a suspect's blackberry. (Off, locked, but not wiped) Pop open the device and then cut the flash chip off the board, mount it in a reader, and duplicate that to more friendly media, now you don't have to worry that the data actually disappears on you. Next you solder on a proxy chip that lets you record the exact sequence that queries the flash chip for that particular phone. Finally you just need the normal distributed cracking hardware we know NSA has, and a sufficient amount of time, money, and motivation...
If you weren't a proper forensic lab and were working on a budget (spy style), you could limit yourself to buying/building that proxy chip interface. Then you make sure your proxy interface refuses to send any write commands to the flash chip. Now you can try as many passwords as you'd like. Next you just need to do an analysis of wear on the keyboard. Presumably the most used keys are going to be among the ones in the password. Feed those as inputs to your password generator/tester.
End result? I think you have a bit more confidence in your device than you really should.
Slashdot Mirror
So what you're saying is that Google has decided to fully claim reputation-ownership of the mail their users are sending. They're staking their reputation that their users don't generally spam. If it was a big enough problem you would blackhole all of gmail, right now you're upset because due to the large volume that gmail sends, any percentage of spam is a problem.
I don't mean to attack or defend anyone here, just curious.
I think the deal is just that anything that comes through gmail needs a more heuristics based filter, and you can't just blackhole on the particular client. As long as the percentage of bad e-mails coming through there is lower than the percentage of good e-mail then the reputation system is working...
How much spam actually is originating through gmail?
How does one prevent a spammer from spoofing these headers?
That's a great point... We should make available a "time-locked" version of wikipedia. That jurors can browse and lookup information without risk of contamination for a particular case!
You've got options: 1. Get yourself cremated (or dumped into a volcano) 2. Make sure your body is dumped in a pig farm 3. Make sure your body is diced into pieces, and then dumped at sea 4a. Don't do anything noteworthy (preferably with the above) 4b. Do something so noteworthy that you are beloved. State that you must not be embalmed, make sure they plant some real plants above your grave, and make sure there's access for rainwater and natural light in the shrine that would be your tomb. This is a tricky balancing act as you need to be naturally exposed enough to decompose, but protected enough that your fanatic fans won't disinter you for totems (like they did for saints).
The relative statement in the article "age = 30 years" tells us less than "age = 30 years + 50million years travel time" -- effectively you need a second separate statement to get the same information. I guess I just preferred the information about the distance to be more local to the information about the age. I had to search to know if there was a chance humans would ever see it. It seems like 50million light years is just so far that it's unlikely something recognizable as humans will ever get to this black hole.
That's still a statement relative to our frame.
That was how I visualized it. The age (relative to our frame) was not 30 years, the age was 30 years + our estimate as to the distance of the ex-star from us.
Why does *our frame* matter so? If we posit that it is in a galaxy 50 million light-years away, we can conceive of the frame of reference that contains both, no? We know it took 50 million + 30 years for the light beam and its information to reach us. To me that's a pretty definitive age. Should I not think of things that way?
It was 30 years old, 50 million years ago. I guess the claim re: young black hole is more due to the age apparent in the images we're capturing now, then the actual age of the black hole.
Cookies!!!!!!
Android CPUs are pretty slow. I bet that + the rest of the platform's immaturity is what's hanging them up. Sure *technically* you can write your code in c/c++ but you end up having to personally import every damn library from the STL up.
Trick question, without deviating from the Millenium Falcon's route, it would still be something less 12 parsecs.
Source:
Turns out it's roughly 0.1183 milliparsecs per millenia.
Can we have that in more standard units please? I myself prefer parsecs per millenia, kthx
I think you're wrong. Station Wagon (SW) would equate to thousands of pigeon-carrying-capacities (PCC). When you're dealing with that datavolume, you end up with significant overhead at each end. Generating the packet burst, and tieing them to individual pigeons, and then sending them; Subsequently you need to accept the incoming PigeonPackets (PP) reorder them, and then read them back in. With SWs you can use much higher density drives, and they need much less processing to load into the SW. I imagine with a pigeon load in the thousands, you'll have a fairly significant attrition rate, and you won't know which packets go missing till you've received them. In fact arbitrary pigeons might just exhibit really high latency, and PETA might be unhappy if you try to implement strict TTLs on them. While a SW needs to follow road rules, those are infact just routing considerations, and as such help the network stay robust. With PPs you have to worry about tons of sources of packet loss. If your SW packet arrives, you can usually treat that as atomic success; (Ignoring the risk of highway robbery) and you have to worry less about your data integrity.
In conclusion if your data density is above 10 PCCs I'd say a SW would be a better bet.
Note: using a RAID scheme could allow for higher attrition rates.
to be fair, Slashdot was wrong on the iPod, to my memory Slashdot was roughly evenly split w.r.t. the iPad
Actually, that one we can blame on a timing / implementation glitch in the dynamic interface for commenting now. I clicked the preview button and for some reason the request was taking a long time to complete. I started to think I wanted to add something to the end of my comment. Right as I started to type it turned into the read-only preview bubble (with my original comment /sin/ 'A'). Apparently in spite of that, it still submitted my now edited text as the true comment, even though I still have the tab open and it clearly shows that my UI thinks that the "A" was not part of the comment.
You need to hit the "Options" button below the reply box, and select "Plain Old Text" as your preferred posting mode.
See? This is on a newline. All I did was hit the enter (return) key on my keyboard. A
Which ID number is that? Social Security numbers are not guaranteed to be unique, and not everyone gets a passport.
But that's an important distinction. Some buyers might think the battery actually lasts 5 years... Not the optimistic numbers manufacturers always claim. By having a lease agreement that would add up to a new battery in 10 years is a functional guarantee. That's a hell of a lot of peace of mind.
Don't argue with a fool because people around you won't know who is which.
It's safer to cede the situation with some platitude like "we should agree to disagree" or simply walk away. Anyone who actually degrades your social status for that action should really not be part of your measuring group.
No worries. TGIF. Go for in-office kegerator.
As an Engineer myself I find your comment irritating. Sure any organization that has lived for a respectable amount of time has a certain percentage of people continuously trying to cover their asses. The thing you missed is that NASA wasn't asking the Engineers "how long can it last?" They were telling the Engineers "it must last 90 days, weigh less than X, take up Y space, generate no more than Z interference, cost less than C...". Having a hard stop of lasting 90days and throwing engineers at the problem means they can't give any average age or expectation. Every expected fragile component was replicated in triplicate, time money and other constraints permitting. They had to demonstrate that any realistic scenario was covered from every angle. They literally had to account for unknown unknowns. Voyager just had a single bit flipped on the OS. The last I heard people think this could literally have been a cosmic ray. A particle moving close to the speed of light managed to hit a particular atom that generated enough energy to change the value in a tiny piece of the computer. --> AND they recovered from that!
I've got to give them credit. Just brushing away their work surviving for much longer than their minimum is not acknowledging their accomplishments appropriately. They had effectively one shot at performing the mission they designed for. Normally estimates for life are fuzzy things with ill defined edges. They polished and polished and got the lowerbound edge to be as sharp as possible. Necessarily that pushed out the definition of the *average* expected lifespan and death estimate. I'm glad I don't have the stress their job must entail, but I wish I could be so specific about the likelihood of death of my software.
Multi-licensing where the battleship version is very easy to get for $LARGE_NUM while the normal license is sold at most retailers for $SLIGHTLY_SMALLER_NUM
Depending on the design of the phone, you could engineer your blackberry to wipe itself if the phone gets turned off, or if the case gets open, etc. All of those are physical security devices that could be bypassed with sufficient time. This includes if they created a single all-in-one chip that was included everything except for power management in one tiny piece of silicon (not currently the blackberry design because it would be cost prohibitive)
Acknowledging that the above aren't really a factor, then take a suspect's blackberry. (Off, locked, but not wiped)
Pop open the device and then cut the flash chip off the board, mount it in a reader, and duplicate that to more friendly media, now you don't have to worry that the data actually disappears on you. Next you solder on a proxy chip that lets you record the exact sequence that queries the flash chip for that particular phone. Finally you just need the normal distributed cracking hardware we know NSA has, and a sufficient amount of time, money, and motivation...
If you weren't a proper forensic lab and were working on a budget (spy style), you could limit yourself to buying/building that proxy chip interface. Then you make sure your proxy interface refuses to send any write commands to the flash chip. Now you can try as many passwords as you'd like. Next you just need to do an analysis of wear on the keyboard. Presumably the most used keys are going to be among the ones in the password. Feed those as inputs to your password generator/tester.
End result? I think you have a bit more confidence in your device than you really should.
Nono, see you missed the fact that they stripped the parameters from those calls. You're actually fsck-ing a different device.