At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat.
although there are people who can retrieve files even if you delete them from the recycle bin. the only way of really deleting something is to overwrite the same area on the disk with random patterns of ones and zeros.
on *nix you have the shred command which does that, but folks say that it is useless if you use a journaling file system like ext4. is that right?
The recycle bin on windows is just a folder. When you send things to recycle bin they are stored there and are not deleted at all, so they can be easily retrieved. When you empty the recycle bin, they are actually deleted. I believe similar systems are on *nix and ios. However, deleting a file merely removes the information that tells the operating system where to find the actual contents of the file - the contents are actually still there, and will remain there until the space they are in is needed for some other data. Shredder and programs like it actually over-write that data so it's no longer stored. Even then, previously stored data CAN usually still be retrieved, although it takes expensive hardware and skilled technicians. You need to save over data something like 30 times to make it impossible to retrieve.
A journaling system is basically a backup copy. There's nothing stopping someone who knows what they're doing from deleting the data from the journal as well as from the disk, although again you'd need software for that purpose.
My brother told me that currently the DOD requires 100 overwrites to consider a deletion secure. Journalled file systems keep the last however many writes they have room for in a separate area of the disk. I believe that these writes are made before the "disk write" is made. If a crash occurs during the "disk write", the write can be recreated from the journal. It saves having to run fsck, which can take hours on large file systems and restores confidence in the disk's date almost instantly on reboot. Deleting a file is basically like removing it's entry from the table of contents of a book. The pages are still there, but they're marked free, and the OS can't find it. Since the blocks are marked free, they're not overwritten until the filesystem decides to use those blocks again. If you have a disk editor, you'd probably have fun looking around.
If I want to completely 'zero' my storage, would something like 'dd if=/dev/zero of=/dev/sd*' work?
I believe it should, yes. Writes to a filesystem are not always done on the actual disk, they can be done on the disk cache and not written through to disk until later. This is a major aspect in improving disk IO. In journaled FSes, I believe the journal does stay written to the disk, so that if a disk cache flush gets interrupted for any reason, the journal has a coherent view of what was supposed to happen. Regardless, the journal is still on disk, and there's probably a good way to wipe files on journaled FSes as well. Note that completely "zeroing" your storage as above does delete everything from the OS's perspective, but data is still recoverable with the right tools/instruments.