Hacker News new | ask | show | jobs
by lolc 3724 days ago
I tend to use slightly embarrassing terms for config options that enable workarounds. This motivates to deprecate these bugfeatures as soon as possible. Who would want to have 'fickle_timestamps' or 'fudged_routing'?

Interestingly I use a similar policy when selecting my passphrases. My passphrases are bad four-word poems about personal experiences. Thus I'm personally invested in protecting passphrases and keeping discipline even for "worthless" accounts. I wouldn't be comfortable about sharing even my old passphrases.

3 comments

Who would want to have 'fickle_timestamps' or 'fudged_routing'?

Not quite the same thing. What I have is more along the lines of work_around_BSD_make_bug, work_around_old_rhel_bug, work_around_docker_bug, and work_around_clang_bug.

I do like the policy of noisy workarounds. With workarounds for external flaws I tend to use neutral language though.
Fair enough. I wouldn't go down this route with something like POSIX_ME_HARDER, because that's a matter of "my design decision is better than your design decision"; but I don't feel that there's any need to be neutral when it comes to things like compilers emitting incorrect code.
I like this naming philosophy too. I once named a feature "VLAN splinters" to discourage people from using it; after all, who likes splinters? Unfortunately, people did use it and I'm only now getting to the point where I think it can be removed. I suspect that naming is, in the end, not very effective, but it still feels good.
I've taken to writing swears in personal project code comments or variable names instead of TODOs or hacky workarounds. It's easy to grep the codebase for them and I'm constantly just a little worried someone will pull me up on it.
Was it GNU df that had the POSIX_ME_HARDER configuration option to enable a particularly unwanted bit of POSIX-mandated functionality?
Yes, but they changed it to POSIXLY_CORRECT.
This is one of my favourite Stallman anecdotes of all time :)