Write opinionated workarounds | Hacker News Reader

Write opinionated workarounds

daemonology.net

39 pointsepsylon12 comments

This is one of the big things that was taught at UC Davis undergrad program, at least in the past. In order to assure portability, students have access to many nix platforms (SGI, Arch Linux, Solaris, etc.) and their homedirs mount as you'd expected at login to any of the boxes in the pool. I think they have FreeBSD boxes now, but I could be wrong. (EDIT: nope, what a shame. The trio of BSDs.)

PS: I nearly got thrown out for running John The Ripper on everyone's password hashes, which were conveniently served up over NIS. I did inform a prof that his password was super, super insecure because I mailed it to him. :)) Then, I nearly got thrown out again for mirroring some Oracle DBMS docs because they were stupidly IP restricted, and I didn't want physically go to CSIF cluster. Finally graduated though, I think they were just glad to get rid of yours truly. :)

I've heard stories about a professor who wanted to teach his students to write portable code and announced that he would test their programs on one of <insert long list of UNIX systems> but he wasn't going to tell them which.

Does that sound familiar? It might be pure apocrypha.

Yup. In undergrad lower-division courses, we were explicitly informed of this and tradeoffs of proprietary toolchain features. And, most lectures / graders / readers followed through. They had a custom hand-in system on the student-side and then their own scripts to run batches of student builds wherever they chose. Some courses wanted Makefiles, others wanted things like "build.sh" and "run.sh".

BTW: The uni also claimed (unverified, could be an empty threat) a multi-institution (Berkeley, Stanford, MIT, etc.), code plagiarism detection system covering two decades of coursework. (Maybe MOSS.)

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.

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 :)

Reply on news.ycombinator.com