@pndc yes. To be clear that was an extrapolation of my argument to not fix known issues; I don’t feel it should be done!

@pndc I wouldn’t describe a vulnerability as a back door unless it was not well known or deliberately obscured. I do feel the plain text nature of telnetd is a fault, yes, but I appreciate others may not. There are other decision decisions I also feel are faults (e.g. accepting the client’s ENV). Also, it’s de-facto unmaintained.

Reasons `less` is a reasonable default man pager: scrolling up and down, and quitting, are reasonably intuitive and discoverable for beginners. Beginners benefit the most from being able to read man pages.

I’d love it if the default could also handle jumping to (and back from) a cross-referenced manual. (Neo)vim does this, but IMHO would be a bad default for other reasons.

Does fixing security faults in telnetd simply encourage people to use it? IOW, would deliberately _not_ fixing them be a better strategy? I suppose that argument could extend to: would it be good to _introduce_ security bugs to telnet, overtly?

@werdahias I’ll have to take a look. At the moment I use nvim which is better than a simple pager but I feel needs more

Julia’s excellent vlog about man pages (https://social.jvns.ca/@b0rk/116093529820975727) reminded me I was thinking about Debian’s policy of “every tool should have a man page”, and how often that isn’t true.

I’d like to see the default man viewer have some more quality of life features, especially for newer folks

@vaurora eating lunch at a resort hotel with my youngest daughter. About half way through a week vacation. Unclear if it was a good idea taking my eldest, who is in autistic burnout. Some good moments, some bad.

I really like HTF which uses a pre-processor to discover your test functions (you must name them e.g. `test_foo`) but it is an approach with serious limitations. Tasty (the framework Pandoc uses) has a companion library `tasty-th` (or similar) which does discovery using template Haskell, which seems like a good approach. I might try it during dev; I’m not sure pandoc would accept another dependency for a new reader.

It’s also strange to me that the pandoc testing strategy is entirely around the top-level function you export from a reader. No unit tests of any utility functions, which is an approach I prefer. I also prefer in-module tests (so you can test stuff you don’t export). My tastes may not align with the zeitgeist.

I’d kinda like to separate out the parsec bits from the pandoc bits so I can ignore the latter whilst I iterate on the former. But it’s not entirely possible because the parser needs to emit parsec types. I might be able to avoid the pandoc monad wrapper at least. Maybe more

Currently playing whack a mole with parsec combinators. Fix one parser bug, re-break another!

@thomasfuchs @RnDanger that *is* a fantastic one. Can easily run rock-box; replacement bits readily available, mod kits for solid stage storage too.

Booted old laptop... Firefox *everywhere else* reverts to default theme

Idle thought: if you are a software maintainer who objects to GitHub, and you used sha256 hashes for your git repos, then those repos cannot be pushed to GitHub.

I’ll probably ring fence some time to further explore the ethical issues with them (that’s pretty much all I’ve done so far) but not the whole day

I might dedicate friday’s “day of learning” to finally catch up on some of this LLM craze, specifically developer tooling. I’m very behind. Any recommendations on specific things to look at? Thanks!

Urgh I so much prefer the lightweight approach of test functions in HTF to any of the popular frameworks. If I’ve got to build an elaborate tree structure it’s such a pain in the ass. `prop_myfunc x = …` right there next to `myfunc` is so much better imho #haskell

This looks like my kind of university society

https://cercle-informatique.be/

@mjr @kinnison the thought crossed my mind, but on balance of probabilities, perhaps not. Unless anyone else has gone public wondering about transactions