Kind of the opposite. It takes more effort to make a filesystem case-insensitive. Binary comparison is the laziest approach. (Note that laziness is a virtue.)

I’m on the fence as to which is better. Putting backwards compatibility aside, there’s a perfectly good case to be made for case-insensitivity being more intuitive to the human user.

Apple got into a strange position when marrying Mac OS (case-insensitive) and NeXTSTEP (case-sensitive). It used to be possible to install OS X on case-sensitive HFS+ but it was never very well supported and I think they axed it somewhere down the road.

Geany is a nice GUI option. It’s a bit more capable but still lean.

It’s probably time for me to re-evaluate the host of coding editors out there. For the most part I just use good text editors. Though I do love Spyder, I only use it for a certain subset of tasks.

IPFS content IDs (CID) are a hash of the tree of chunks. Changes to chunk size can also change the hash!

I don’t understand why this is a deal-breaker. It seems like you could accomplish what you describe within IPFS simply by committing to a fixed chunk size. That’s valid within IPFS, right?

Is it important to use any specific hashing algorithm(s)? If not, then isn’t an IPFS CID (with a fixed, predetermined chunk size) a stable hash algorithm in and of itself?

DBAs think everything is a database.

I feel bad for this kid. That really is a bad warning dialog. Nowhere does it say it’s going to delete files. Anyone who thinks that’s good design needs a break.

Half the replies are basically “This should be obvious if your past five years of life experience is similar to mine, and if it isn’t then get fucked.” Just adding insult to injury.