DragonFlyBSD's HAMMERFS does much of this - you can examine the version history of files and directories using hammer history and undo commands, and reference versions directly by appending @@ to filenames.

You can control how long history is preserved for and in what level of detail, as well as efficiently replicate it all across the network to remote filesystems (which can have their own, different rules). All this in addition to the more traditional named snapshots approach you're limited to with, e.g. ZFS.

https://www.dragonflybsd.org/d...

Their mobile client is open source: https://github.com/SpiderOak/S...

The desktop client is mostly unobfuscated Python bytecode and easily inspected, docstrings, symbol names and all, with a bytecode decompiler. Not good enough, but at least a bit more transparent than most.

Guess that has to be my main server, even though it's a few generations older than my desktop, it has more cores, more IO, more memory and more storage. It runs FreeBSD.

Case: SuperChassis 745TQ-R800B (pic)

Motherboard: Supermicro X8DTN+

CPUs: 2 x 6-core Xeon L5639 @ 2.13GHz

RAM: 144GB - 9 x 16GB DDR3-1333 ECC Reg

Primary Storage: 2 x SanDisk Extreme Pro 960GB, ZFS mirror.

Mass Storage: 6 x 5TB Toshiba MD04ACA5, ZFS 3 x mirror.

Disk controller: IBM M1015, seems one of the most favoured HBA's these days.

Keyboard: NTC KB-6153EA with clicky White Alps.

I play with search engines and stuff, the memory comes in handy and I got it for a great price.

Desktop is a 32GB ECC quad core Haswell Xeon mumble mumble running Windows 8.1, with a pair of 30" 1600p monitors and a 20" 1600x1200. Nice having space to put stuff. Also nice having memory that doesn't silently corrupt itself every few months, you crazy kids and your non-parity.

In case anyone missed it, if you're using one for OpenPGP key use you might be vulnerable to a pin bypass attack. Details on how to check are on that page.

If you have a vulnerable device, YubiCo will send you a free replacement upon request - just open a ticket with your serial and order numbers.

You want a strong key! Key stretching isn't just about making a physically longer key, it's about making a stronger one, such as by iterating your hash function a million times.

This is not in question. What is in question is why it's not exactly what you'd want out of a password hashing function - what difference does it make whether you're going to pass it to AES or to a comparison function?

... which you then need to, at a minimum, apply salting and key stretching to. Good work, you just rewrote most of PBKDF2, just without the peer review, sane defaults, and for most people, probably in a language where the function call overhead exceeds the cost of the hashing.

Hashes are not designed for password storage, that's the entire reason we're having this conversation in the first place. People use KDF's for password storage because that's what they're made for. Anyone who uses a plain old hash has to make a KDF out of it. How are they different?

Yes, I used "computationally complex" to mean "takes a lot of steps to complete". You and your "words mean stuff", stop evading the point.

Why is a KDF like PBKDF2, bcrypt or scrypt, a poorer option for password storage than rolling your own? Please use words which mean stuff.

How do you make an algorithm that's slow without being computationally complex? Writing it all in PHP doesn't count.

The algorithm has to be slow because it's a lot of work. Your implementation has to be fast to maximise the security benefit of using it in the first place.

What else do I want a hash function to return?

Pad your inputs and use constant time comparison functions, kids.

Er, not really? You want a well-optimized function to turn a password into a very big unpredictable number in a way that's computationally complex, and that's precisely what KDFs are made to do. The entire crux of your argument against such use seems to boil down to "but they sometimes let you specify how big a number you want", as if this added complexity and risk somehow massively outweighed that created by rolling your own slow crappy little alternative.

Maybe the Seagates are more sensitive to vibration, either from making more of it when you shove 45 into a cheap metal box, or by being less tolerant to it because they're pushed harder.

12.5TB, assuming the specified 1-in 10^14 bit uncorrectable-read-error rate specified for most consumer drives is accurate. I certainly don't see rates anywhere near that high with my consumer drives, but I could just be lucky.

Even foobar2000 has issues with seeking in MP3s. From the FAQ:

You need weird-ass buggy fb2k plugins, but are only missing format support in WMP? Do you play a lot of ancient tracker music or something?

If you find the fb2k interface so intimidating perhaps you'd be better off with its much simpler cousin, Boom. Not sure if it's got much support for particularly oddball media formats though.

Isolation. The same reason you want different apps to have their own processes instead of having the whole of userspace in one big blob. You can give processes reduced privileges to reduce the scope of exploits, hangs and crashes don't take down more than they have to, and leaks don't force you to restart the entire system to recover resources.

Plus it makes for simpler concurrency. Kind of handy when you've got a stop-the-world garbage collector if you can just split the world into many smaller independent units, each able to run at the same time and each with an order of magnitude less work to do and no synchronisation to worry about.

ASLR is a fuckload more effective when it has a reasonably sized address space to work with, and 2^32 is miles away from being reasonable. It's the difference between an attacker having to guess one of 8 locations and one of 8 billion. Plus, memory mapping things is awesome, and also a fuckload easier with a reasonably sized address space.

And hey, some of us actually use our browsers quite a lot. Mine's eating 5.5G right now. So many windows and tabs, and absolutely no fucking reason whatsoever why that should be considered even slightly unreasonable.

People spouting things like this is precisely why we have tens of millions of web apps using shitty password storage solutions that boil down to HASH(salt + password) and are thus borderline fucking useless. It's like asking if someone's home-grown encryption algorithm uses an IV - that might be an important part of it but it's kind of missing the point.

If you're using passwords for authentication in your app, use a recognised key derivation function. Use PBKDF2 or bcrypt and tune them to take at least 100ms to run. If you're extra paranoid, use scrypt and tune it to take 100ms and 16MB of memory. If you're doing anything else without having a well-received peer reviewed academic paper describing it, you might want to reconsider.