Nope, it was the original sequence in which Han shot first, missed, and the laser bolt richocheted off the wall behind Greedo, then richocheted off the wall behind Han, and then blasted poor Greedo in the face.
As OS X users finally get the power to unintentionally resize their terminal emulator windows when trying to select text that goes right up to the margin, just as other UN*X users have had for ages.:-)
This does not actually happen on OS X... But now I'm curious... how on earth does that happen on other UN*Xs?
Really? God help us if they merge the iOS7 interface into MacOS. Frankly I feel they have lost direction with the passing of Jobs. They do really stupid things now, like emulate the look, and behavior, of Android.
Agreed 100%. iOS 7 looks like the Mille Bornes card game.
Look folks its REALLY simple, the PC and laptop are vertical non touch screen high res systems and the phone and tablet are.....wait for it....horizontal touch screen oriented low res systems.
Just replying to point out that you have this backwards.
PCs and laptops have horizontal (e.g., landscape orientation) displays, and the phone and tablet... well, the tablet can be either way, but the phone is primarily a vertical (e.g., portrait orientation) display.
If you move a de-duped block to defragment file X, then the same block referenced by file Y is now not in order.
That's fine. Seriously, when do you ever have a block in common between two files that are not identical copies of the whole file? Certainly not in the middle of a giant file. By nature, giant files (music, video) are compressed and essentially random. Maybe as the very last block in a file, or in a very small file, in which case out-of-order is a non-issue.
If it is in memory cache the whole concept is moot anyhow - whether it is fragmented on disk or not is irrelevant.
The hash mapping between block ID and disk location should be kept in memory. The actual data doesn't need to be.
Given that with de-dup, we are dealing with BLOCKS and not complete files, what order do you propose they are sorted in? Or are you talking about just "Defragmenting" by consolidating them all at the start of the disk, which would make more sense?
First, sorted in order of first known occurrence in a file. Then, consolodated at the start of the disk (if the data is largely static). Defragmenting free space is more important often than defragmenting files.
No no no no no. No.
When you want to read the actual data pointed to by the lookup table, the disk head goes to the location where the data is now, not where it was originally. Where it was originally is never stored — and never needs to be. All block IDs are looked up and converted to disk locations on-the-fly at read time, using an in-memory-cache that is mutexed to prevent corruption during background operations. And moves can be done in the background without delaying foreground tasks by copying first and then updating the table pointers.
ZFS can have up to 18,446,744,073,709,551,616 snapshots, and if you change the location of a block of data, you need to update it's block pointer in all of those snapshots, assuming each one points to it.
That's an incredibly naive implementation then. It would be far superior to store the ID of the block, rather than the location of the block. Then you look the location up in a table, given the ID. Then blocks can move around as needed, as a background process, without harming any data structures. This is exactly how virtual memory paging tables work. Why can't disks do this?
That said, defragmentation is intrinsically incompatible with deduplication, as it is not possible to have multiple files that all refer to some of same blocks all being contiguous on disk.
Nonsense.
You don't store the address or location of a block, you store the ID of the block's unique data. When/if you need to know the location of the block, you look it up an ID-to-address table. There's absolutely nothing intrinsically incompatible between defragmentation and deduplication.
Agreed 100%. Also — and this is most important for me — the iPad has a way higher resolution (in terms of pixels per inch density) than my laptop screen has. The iPad is simply gorgeous for reading things. (iPad 3 and iPad 4)
iPad Mini is a very foolish choice. It's only 768x1024. Should be a retina iPad instead, which is 1536x2048.
The 1536x2048 resolution of the iPad 3/4 is miles better than the 768x1024 resolution of the old iPad and the iPad Mini. Frankly, 768x1024 is insufficient for reading anything but pure text like novels. You need 1536x2048 for technical material or anything serious at all.
Slashdot Mirror
...Tee hee hee hee hee
Yeah, you know, just like in the garbage compactor scene.
Well, if you did it on purpose as a joke, and that joke wooshed over my head, then ... ok, my bad ... if the joke was obvious and I am just stupid.
Jeebus. Well, evidently the GGP was not smoking crack after all. Cool. I stand corrected, and offer apologies.
But now you know the correct words to use.
Nope, it was the original sequence in which Han shot first, missed, and the laser bolt richocheted off the wall behind Greedo, then richocheted off the wall behind Han, and then blasted poor Greedo in the face.
This does not actually happen on OS X... But now I'm curious... how on earth does that happen on other UN*Xs?
Until this is en masse , they are still afraid of you!
FTFY.
Interesting... See #18 here:
https://geonames.usgs.gov/domestic/faqs.htm
Are you smoking crack? Show me even one 50" 4K TV for under $1000. I think you mean 50" 1080p TV for under $1000.
Are you kidding?? Nimoy was amazing. Still amazing in those.
640k strands out to be enough for anybody.
Agreed 100%.
iOS 7 looks like the Mille Bornes card game.
Just replying to point out that you have this backwards.
... well, the tablet can be either way, but the phone is primarily a vertical (e.g., portrait orientation) display.
PCs and laptops have horizontal (e.g., landscape orientation) displays, and the phone and tablet
Why didn't you say so before? ;)
CHM??? chm is a piece of utter garbage by Microsoft, intended as Compiled HTML Help.
HTML5, on the other hand, is actually rather decent.
That's fine. Seriously, when do you ever have a block in common between two files that are not identical copies of the whole file? Certainly not in the middle of a giant file. By nature, giant files (music, video) are compressed and essentially random. Maybe as the very last block in a file, or in a very small file, in which case out-of-order is a non-issue.
The hash mapping between block ID and disk location should be kept in memory. The actual data doesn't need to be.
First, sorted in order of first known occurrence in a file. Then, consolodated at the start of the disk (if the data is largely static). Defragmenting free space is more important often than defragmenting files.
No no no no no. No.
When you want to read the actual data pointed to by the lookup table, the disk head goes to the location where the data is now, not where it was originally. Where it was originally is never stored — and never needs to be. All block IDs are looked up and converted to disk locations on-the-fly at read time, using an in-memory-cache that is mutexed to prevent corruption during background operations. And moves can be done in the background without delaying foreground tasks by copying first and then updating the table pointers.
That's an incredibly naive implementation then. It would be far superior to store the ID of the block, rather than the location of the block. Then you look the location up in a table, given the ID. Then blocks can move around as needed, as a background process, without harming any data structures. This is exactly how virtual memory paging tables work. Why can't disks do this?
Nonsense.
You don't store the address or location of a block, you store the ID of the block's unique data. When/if you need to know the location of the block, you look it up an ID-to-address table. There's absolutely nothing intrinsically incompatible between defragmentation and deduplication.
Agreed 100%. Also — and this is most important for me — the iPad has a way higher resolution (in terms of pixels per inch density) than my laptop screen has. The iPad is simply gorgeous for reading things. (iPad 3 and iPad 4)
iPad Mini is a very foolish choice. It's only 768x1024. Should be a retina iPad instead, which is 1536x2048.
The 1536x2048 resolution of the iPad 3/4 is miles better than the 768x1024 resolution of the old iPad and the iPad Mini. Frankly, 768x1024 is insufficient for reading anything but pure text like novels. You need 1536x2048 for technical material or anything serious at all.
I immediately thought of Daniel Ocean when I read TFS.
$ perl -e 'printf "%.3f DeLoreans\n", 5.1e12 / 1.21e9'
4214.876 DeLoreans
Welcome to the future. All of your morals are belong to us!