I specifically remember working on a Control Data Corp CDC3200 (circa 1970) which was nothing but a 3300 with delay lines installed to slow it down. Simply removing a specific card (secret) did the upgrade.
Fast enough unless you need to work a major portion of your day using one. Then you find out there are significant and meaningful differences in speed that affect your ability to get things done.
Fast enough for someone who checks in once a day to look at email is easy.
Its odd how both the summary above and the linked article sort of over look the fact that Chrome just blew the doors off of every other browser and the compared the production version to the latest and greatest of the others.
Chrome really deserves top billing, but the story is about the who is going to come in dead last.
Realistically, its the remotest of possibilities that the Taliban could attack one of these aircraft unless their Iranian friends wanted them to.
Even the ancient Sa-5 Gammon missiles that Iran has in quantity are capable of reaching that altitude, and portable enough to transport across a porous border.
Highly unlikely I admit, but then 5 years with one of these aircraft peeking over their borders 24/7 might just goad Iran into such a "loan".
There is some Slant Range Radar imagery from 86km away taken from Global Hawk on page 50 of this document. The actual maximum range of the full sensor package is still classified, but that image of Lake Success Dam had more than enough resolution to show major troop movements.
Exactly so. (Although Iraq took longer than two weeks in spite of the fact that we had been overflying the country for years. US aircraft were getting shot at well after the time the announcement of air superiority was declared).
But again, this brings us to speculation of what might be the main use of these things.
Com and surveillance. For 5 years? I suspect even the Taliban would have found a way to sneak a missile in over the course of 5 years for something up there 24/7 flying semi predictable patterns of slow flight. (And how could it be anything other than slow since its probably going to be relying on solar power for most of that 5 years).
These seem more likely to be used for domestic surveillance or perhaps Sea surveillance than any thing else. Drug interdiction. Border monitoring. Radar control.
Currently in the US fleet only F15 F22 and F35 have announced service ceilings in excess of 60,000ft. (Some f15s can achieve 98,000ft (ballisticly).
The experimental Russian P-1, Sukhoi and Su 27, and perhaps a few others could operate up there.
But there is otherwise nothing up that high on a routine basis.
50,000 feet is easily within reach of missiles. So other than areas where there is already full air dominance, I would not expect to see these in combat situations. As a communications and surveillance platform it holds a lot of promise.
Thus, the deduplication algorithms use various techniques to determine how similar two files are before deciding to try to express one in terms of the other.
But I understood de-duplication to be not concerned with files at all. Simply blocks of data on the device.
As such my might de-duplicate the boiler plate out of a couple hundred thousand word documents scattered across many different directories.
Is that not the case? Are they not yet that sophisticated?
Although there is nothing to say compression of data might not also happen. I don't believe compression and de-duplication are mutually exclusive.
This is actually a good argument for de-duplication to run on the device. It can surf thru files more or less at leisure looking for duplicate blocks all over the file system, without tying up the server's bus/controller.
That could be done independent of File System compression, which generally, as you pointed out, works best on large blocks of repetitive bytes within a single file.
But De-duplication does that and goes one step further.
Multiple copies of the same block of data (either entire files or portions of files) that match even if stored in separate directories can be replaced by a pointer to a single copy of that file or block.
How many times would, say, the boilerplate at the bottom of a lawyer/doctor/accountant's file systems appear verbatim in every single document filed in every single directory?
A proper system might allow you to have just one of these.
Well in the end, does not the filesystem running on the device end up controlling the actual reads and writes regardless of whether the file is shared across the network or across the world?
My take is that there is not much to justify the claim that this should be in the filesystem vs the hardware. If you don't want to de-duplicate some data (for what ever reason) then you don't put it on that type of storage.
But it seems to me that a hardware approach is a perfectly reasonable layer to do this. It eliminates several potential points of failure, (FS version changes, FS bugs, memory failures, bus failures, end user fiddling, etc).
Its OS insensitive, and when you replace the server OS or hardware the search for drivers is eliminated. Obsolescence is defined by when the NAS fails to meet your needs, not by when the developer moves on to something new, or the company declines to release new drivers for the next version of your OS.
As long as I can get out exactly the same data I put in, why would I want to do this at the FS layer? Why would I care, as long as it was reliable?
I'm aware there are traps, such as having to make minor unique changes in thousands of files, forcing the system to un-de-duplicate many megabytes of data, potentially over-flowing the available storage. But that's equally possible in an FS based solution as a hardware based one.
I know exactly how a one time pad works. EXACTLY. Stop asking the question.
Brute force attacks yield mountains of garbage, and a few nuggets of highly probable deciphers, of which usually only one makes language and contextual sense.
Even one time pads are susceptible to brute force attacks.
The only way you can make the assertion that they are not is to assume the original message was simply random characters, with no obvious language.
If the original was normal human readable text it becomes immediately obvious when your brute force succeeds and a subsequent dictionary comparison of each word yields a hit.
Exactly. It has only ONE image, the last one. Not a history of images. Open your map tap the Locate icon when at home or any other common place, and problem solved.
Besides, everyone who watches TV knows you use a untraceable "burner" phone, right?
Follow the link to the Original Article over on The Register , where you will find a rather lucid explanation, far better than the summary above can provide.
Short answer:
The old method of building their search database was essentially a Batch Job, Run it, wait, wait, wait a long time, swap results into production servers.
The new method is continuous updates into a gigantic database spread over their entire network,
This is why things show up in Google days, sometimes weeks ahead of the other search engines. The other guys are still trying to clone Google's old method.
Slashdot Mirror
When was that?
I specifically remember working on a Control Data Corp CDC3200 (circa 1970) which was nothing but a 3300 with delay lines installed to slow it down. Simply removing a specific card (secret) did the upgrade.
Quote:
"It's interesting to hear the government making a commitment like this."
Commitment?
You mean pointless gesture more harmful to their own people than anything else?
Or, since no one can fish, they will move away from low lying Kiribat and there will be fewer people to be swamped by rising sea levels.
Daft.
Your own definition is internally inconsistent.
You seem to stumble on the definition of "every".
End result: world full of coroners and shootists. This can't end well.
Well reasoned.
One minor point: No part of this practice is consistent capitalism.
Capitalism requires free markets. If the allegations are true, these companies worked directly to destroy the free market.
The right to sell one's own labor in the market place is the most fundamental and essential market of all.
Destroying markets to gain monopoly advantage is not part of capitalism.
Fast enough unless you need to work a major portion of your day using one. Then you find out there are significant and meaningful differences in speed that affect your ability to get things done.
Fast enough for someone who checks in once a day to look at email is easy.
Me too.
Its odd how both the summary above and the linked article sort of over look the fact that Chrome just blew the doors off of every other browser and the compared the production version to the latest and greatest of the others.
Chrome really deserves top billing, but the story is about the who is going to come in dead last.
Yawn.
Realistically, its the remotest of possibilities that the Taliban could attack one of these aircraft unless their Iranian friends wanted them to.
Even the ancient Sa-5 Gammon missiles that Iran has in quantity are capable of reaching that altitude, and portable enough to transport across a porous border.
Highly unlikely I admit, but then 5 years with one of these aircraft peeking over their borders 24/7 might just goad Iran into such a "loan".
There is some Slant Range Radar imagery from 86km away taken from Global Hawk on page 50 of this document. The actual maximum range of the full sensor package is still classified, but that image of Lake Success Dam had more than enough resolution to show major troop movements.
Exactly so. (Although Iraq took longer than two weeks in spite of the fact that we had been overflying the country for years. US aircraft were getting shot at well after the time the announcement of air superiority was declared).
But again, this brings us to speculation of what might be the main use of these things.
Com and surveillance. For 5 years? I suspect even the Taliban would have found a way to sneak a missile in over the course of 5 years for something up there 24/7 flying semi predictable patterns of slow flight. (And how could it be anything other than slow since its probably going to be relying on solar power for most of that 5 years).
These seem more likely to be used for domestic surveillance or perhaps Sea surveillance than any thing else. Drug interdiction. Border monitoring. Radar control.
5 years is forever.
At 60,000ft it's just military traffic.
And damned little of that.
Currently in the US fleet only F15 F22 and F35 have announced service ceilings in excess of 60,000ft. (Some f15s can achieve 98,000ft (ballisticly).
The experimental Russian P-1, Sukhoi and Su 27, and perhaps a few others could operate up there.
But there is otherwise nothing up that high on a routine basis.
50,000 feet is easily within reach of missiles. So other than areas where there is already full air dominance, I would not expect to see these in combat situations. As a communications and surveillance platform it holds a lot of promise.
Swooosh!
40% of advertising revenue implies revenue for clicks on in-app adds will be down substantially. Apple is going to start milking the App Developers.
30% Subscription revenue says they are planning to continue to milk the subscription content sellers.
It sounds to me like apple has decided its easier to fleece the flock of developers than actually charge the end user for what their services cost.
Boy, I wonder why Google hasn't thought about that.....
I thought the rails were grounded anyway? Except for the third one.
Thus, the deduplication algorithms use various techniques to determine how similar two files are before deciding to try to express one in terms of the other.
But I understood de-duplication to be not concerned with files at all. Simply blocks of data on the device.
As such my might de-duplicate the boiler plate out of a couple hundred thousand word documents scattered across many different directories.
Is that not the case? Are they not yet that sophisticated?
Although there is nothing to say compression of data might not also happen. I don't believe compression and de-duplication are mutually exclusive.
This is actually a good argument for de-duplication to run on the device. It can surf thru files more or less at leisure looking for duplicate blocks all over the file system, without tying up the server's bus/controller.
That could be done independent of File System compression, which generally, as you pointed out, works best on large blocks of repetitive bytes within a single file.
True, compression does a lot of this.
But De-duplication does that and goes one step further.
Multiple copies of the same block of data (either entire files or portions of files) that match even if stored in separate directories can be replaced by a pointer to a single copy of that file or block.
How many times would, say, the boilerplate at the bottom of a lawyer/doctor/accountant's file systems appear verbatim in every single document filed in every single directory?
A proper system might allow you to have just one of these.
Well in the end, does not the filesystem running on the device end up controlling the actual reads and writes regardless of whether the file is shared across the network or across the world?
My take is that there is not much to justify the claim that this should be in the filesystem vs the hardware. If you don't want to de-duplicate some data (for what ever reason) then you don't put it on that type of storage.
But it seems to me that a hardware approach is a perfectly reasonable layer to do this. It eliminates several potential points of failure, (FS version changes, FS bugs, memory failures, bus failures, end user fiddling, etc).
Its OS insensitive, and when you replace the server OS or hardware the search for drivers is eliminated. Obsolescence is defined by when the NAS fails to meet your needs, not by when the developer moves on to something new, or the company declines to release new drivers for the next version of your OS.
As long as I can get out exactly the same data I put in, why would I want to do this at the FS layer? Why would I care, as long as it was reliable?
I'm aware there are traps, such as having to make minor unique changes in thousands of files, forcing the system to un-de-duplicate many megabytes of data, potentially over-flowing the available storage. But that's equally possible in an FS based solution as a hardware based one.
I know exactly how a one time pad works. EXACTLY. Stop asking the question.
Brute force attacks yield mountains of garbage, and a few nuggets of highly probable deciphers, of which usually only one makes language and contextual sense.
Would any message of the same length make sense?
Any possible message is far from any reasonable message. A random sting of characters is not the sort of thing people encrypt.
Try to put this in real world terms here, and stop being such a pendant.
Any message being possible only makes sense when you define "and message" to include total nonsense strings of text.
You can use the 5th grade test to see if your brute force attack worked.
Had the output to a 5th grader, and if can read it out loud your brute force worked.
If I handed you two messages:
1) The account numbers to the secret Swiss Bank account are 3432376482 and 367282345. Please do not access the accounts more than once a month.
--and ;werj ;kljr;qijaof; ;ileurie;oir;iw;; ;lekjeri ;wkrie9jg; ;'keroje;kj ;wljejrei ioj;akjie;titj ww';ler;lj e;kerjw
2) aljkhwerh;lkjerja;ke
Which one of those would your 5th grader choose?
Even one time pads are susceptible to brute force attacks.
The only way you can make the assertion that they are not is to assume the original message was simply random characters, with no obvious language.
If the original was normal human readable text it becomes immediately obvious when your brute force succeeds and a subsequent dictionary comparison of each word yields a hit.
Exactly. It has only ONE image, the last one.
Not a history of images. Open your map tap the Locate icon when at home or any other common place, and problem solved.
Besides, everyone who watches TV knows you use a untraceable "burner" phone, right?
Sun Glasses....
Yeaaaaaaaahhhh!
Follow the link to the Original Article over on The Register , where you will find a rather lucid explanation, far better than the summary above can provide.
Short answer:
The old method of building their search database was essentially a Batch Job, Run it, wait, wait, wait a long time, swap results into production servers.
The new method is continuous updates into a gigantic database spread over their entire network,
This is why things show up in Google days, sometimes weeks ahead of the other search engines. The other guys are still trying to clone Google's old method.