Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux utils that you might not know

shiroyasha.io

Post reply on HN
Print view View original

131–140 of 159 posts

Re: Linux utils that you might not know

#131

Post by sherincall »

hprotagonist wrote: post #116

afaik, `shred` doesn't do anything useful on SSDs. Beneath the OS, there's intentional indeterminacy on sector access, so instructions to write over the same sectors multiple times with garbage aren't guaranteed to actually do that.

The reason shred writes "multiple times with garbage" is due to magnetic disks where even when overwritten, old bit values could still be extracted with advanced tools. This is not the case for SSDs, so a single pass of shred (either random or zero) is enough here. Multiple passes will just kill your SSD faster.

The problem with sector access still stands, so you're not sure it's actually overwritten. You should use sfill(1) in addition to shred. sdmem(1) also, if you don't want to physically power down your machine.

Re: Linux utils that you might not know

#132

Post by DanBC »

sherincall wrote: post #131
hprotagonist wrote: post #116

afaik, `shred` doesn't do anything useful on SSDs. Beneath the OS, there's intentional indeterminacy on sector access, so instructions to write over the same sectors multiple times with garbage aren't guaranteed to actually do that.

The reason shred writes "multiple times with garbage" is due to magnetic disks where even when overwritten, old bit values could still be extracted with advanced tools. This is not the case for SSDs, so a single pass of shred (either random or zero) is enough here. Multiple passes will just kill your SSD faster. The problem with sector access still stands, so you're not sure it's actually overwritten. You should use…

>The reason shred writes "multiple times with garbage" is due to magnetic disks where even when overwritten, old bit values could still be extracted with advanced tools.

People thought that you needed multiple overwrites for traditional drives but in reality that data was gone after a single overwrite of 0. There were no "advanced techniques" that could recover the data. Some specs suggested multiple passes, but this was because they were using precautionary principle.

> This is not the case for SSDs, so a single pass of shred (either random or zero) is enough here. Multiple passes will just kill your SSD faster.

SSDs do weird things with the data, so if your data is important enough you should destroy the drives. There's some data tucked away in odd places.

Re: Linux utils that you might not know

#133

Post by marcosdumay »

hprotagonist wrote: post #116

afaik, `shred` doesn't do anything useful on SSDs. Beneath the OS, there's intentional indeterminacy on sector access, so instructions to write over the same sectors multiple times with garbage aren't guaranteed to actually do that.

> afaik, `shred` doesn't do anything useful on SSDs

It does effectively shred your SSD. In that it will fail sooner and sooner the more you run that command.

SSDs have a sector erase command. I don't know how it's exposed on the CLI, but it exists and will effectively erase anything that was removed. Most of them will run it automatically on the background after you delete stuff, so it's normally just a matter of keeping it powered for a while.

Re: Linux utils that you might not know

#134

Post by marcosdumay »

DanBC wrote: post #132
sherincall wrote: post #131

Earlier quoted context omitted.

The reason shred writes "multiple times with garbage" is due to magnetic disks where even when overwritten, old bit values could still be extracted with advanced tools. This is not the case for SSDs, so a single pass of shred (either random or zero) is enough here. Multiple passes will just kill your SSD faster. The problem with sector access still stands, so you're not sure it's actually overwritten. You should use…

>The reason shred writes "multiple times with garbage" is due to magnetic disks where even when overwritten, old bit values could still be extracted with advanced tools. People thought that you needed multiple overwrites for traditional drives but in reality that data was gone after a single overwrite of 0. There were no "advanced techniques" that could recover the data. Some specs suggested multiple passes, but this…

Hum, no. Some time ago you needed multiple uncorrelated overwrites to hide your data. Then as HDDs shrank you strted needing less and less passes up to today that you just need to clear it once.

It's not about people thinking unrealistic things. The command was created for defending against a demonstrated attack.

Re: Linux utils that you might not know

#136

Post by godd2 »

falsedan wrote: post #69
kingosticks wrote: post #66

Earlier quoted context omitted.

I'd stick with pushd and popd every time, it's considerably more expressive.

> considerably more expressive is that an advantage? Do you have the time to explain this a bit more? I feel that new users need less expressiveness, to avoid decision overload, and keeping one automatic directory save point is easier to mentally manage than a stack of them. I do recommend using pushd/popd in shell scripts (always) and interactively (if you must), but I think 'cd -' should be the first thing you intr…

'cd -' only saves one previous directory, which is held in $OLDPWD. pushd can store an arbitrary history in its stack. And of course, $OLDPWD will change if you hop around after a cd, but the pushd/popd stack will persist.

Re: Linux utils that you might not know

#137

Post by j_s »

Tools like rdfind and rmlint breathed new life into my SSD by hardlinking duplicate files after video editing software helpfully duplicated huge videos on import.

https://rdfind.pauldreik.se/

https://github.com/sahib/rmlint

There are great GUI visualizers for disk space, like WizTree/Baobab; for the command line I've had success with ncdu.

https://dev.yorhel.nl/ncdu

Re: Linux utils that you might not know

#138

Post by godd2 »

sabujp wrote: post #35
barrkel wrote: post #33

Earlier quoted context omitted.

You got the same answer from factor and Wolfram alpha; where is the bug?

wa shows 76 prime factors, which is the not same as printing out a bunch of 2's and 5's

100000000000000000000000000000000000000

== 10 ^ 38

== (2 * 5) ^ 38

== 2 ^ 38 * 5 ^ 38

== 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5

Are 2 and 5 not prime?

Re: Linux utils that you might not know

#139

Post by vram22 »

dabber wrote: post #128
vram22 wrote: post #125

Earlier quoted context omitted.

Also works in vi mode (I think the default for bash is emacs mode - for editing commands, that is): Run: set -o vi once after you log in (for ksh / bash and compatible shells only, maybe, not sure about csh), or (better) put that line in your .bashrc or similar startup file, so it runs each time you log in. (I used to use "ksh -o vi" earlier, before I knew about "set -o vi" or before it existed, but in that case, it…

Awesome, thanks for the tip!

Welcome :)

Re: Linux utils that you might not know

#140

Post by falsedan »

godd2 wrote: post #136
falsedan wrote: post #69

Earlier quoted context omitted.

> considerably more expressive is that an advantage? Do you have the time to explain this a bit more? I feel that new users need less expressiveness, to avoid decision overload, and keeping one automatic directory save point is easier to mentally manage than a stack of them. I do recommend using pushd/popd in shell scripts (always) and interactively (if you must), but I think 'cd -' should be the first thing you intr…

'cd -' only saves one previous directory, which is held in $OLDPWD. pushd can store an arbitrary history in its stack. And of course, $OLDPWD will change if you hop around after a cd, but the pushd/popd stack will persist.

That's true, but I rather would have liked to hear how the expressiveness of pushd/popd was superior to cd - (especially with respect to a newcomer internalizing all the weird coreutils & bash things).
Post reply on HN