MaraDNS VS stale

You could potentially host a dns server in docker (https://mpolinowski.github.io/docs/DevOps/Provisioning/2022-01-25--installing-bind9-docker/2022-01-25/) (https://4sysops.com/archives/configure-a-private-dns-server-in-docker/) or even on windows (https://maradns.samiam.org/) and point the system doing the lookups to use that server. Put in your own records, and then have it do forward lookups for anything else.

While you haven’t used egrep that much, I used it a whole lot, well over 20 times for the automated test setup I have for my open source project. I had to spend most of an hour this morning updating the code to no longer use egrep, and it was non-trivial to update. Here’s the amount of hassle breaking egrep has given me:

https://github.com/samboy/MaraDNS/commit/afc9d1800f3a641bdf1...

This is just one open source project. I’ve seen fgrep in use for well over 25 years and egrep apparently has been around for a very long time too. Just because it didn’t get enshrined in a Posix document—OK, according to Paul Eggert it was made obsolete by Posix in 1992, but apparently no one got the telegram and it’s been a part of Linux since the beginning and is also a part of busybox—doesn’t mean it’s something which should be removed.

I’m just glad I caught this thread and was able to “update” my code.

That is very true, and I do my utmost to avoid any kind of vendor lock in.

Testing is done in a Docker container, so the CI/CD pipeline is available in a Dockerfile and the scripts the Dockerfile imports in to the testing container. In my case: https://github.com/samboy/MaraDNS/tree/master/Docker-stuff

Bug reports and support requests are handled using Github, mainly because that’s what is widely used in the industry right now, but bugs actually fixed are usually described in Git commits, where the information can easily be mirrored.

I think it’s irresponsible to let bugs languish like this. The way I handle bug reports is to say “Hey, look, I just can’t fix this right now because I’m working full time and don’t know when I’ll be able to get around to fixing this without getting paid for my work.” E.g. https://github.com/samboy/MaraDNS/issues/84

I can see why a lot of people don’t do that: It’s a little rude, and there’s a small but significant chance it’ll become a flame war. I have only once had someone get rude in a ticket when I told them “That’s not a bug report, but a support issue”; I ended up deleting the ticket. GitHub also allows you to edit or delete other people’s comments in your tickets, as well as locking the conversation.

Since I write a Lua-parsed DNS server which works with IPv6, even when compiled for an ancient version of MINGW on Windows XP (which has IPv6 support but no built-in IPv6 parser), I had to write an IPv6 address parser.

No, I did not add dotted quad notation to the parser. No, you can not have more than four hex digits in a single quad; 00000000 becomes 0000:0000 with the parser. It supports “normal” stuff like ::, ::1, 2001:db8::1, and even non-normal stuff like “2001-0db8-1234-5678 0000-0000-0000-0005” (to be compatible with the really basic IPv6 parser I put in MaraDNS’s recursive resolver nearly two years ago), but none of the corner cases in the linked article.

The IPv6 test cases in the automated test for the parser are at: https://github.com/samboy/MaraDNS/blob/master/deadwood-githu...

Today while I was looking at a list of open pull requests I still had open on Github, I was surprised to see a pull request that had been opened 2 years ago that I did not recall authoring, so I clicked on the PR. Turns out, I did in fact write the pull request, and it went 2 years without so much as a comment, let alone a review from the project maintainers.

Stale Bot helps in closing down stale issues and pull requests that have been open for a long time and have seen no particular action, hence, cutting down on the accumulation of issues and pull requests on the project.

> Thesis: Stalebot -- in dutiful service of current human resource constraints -- feels like it unthinkingly prioritizes discard of past contributors' time resources, over the mobilization of new human resources.

https://github.com/probot/stale/pull/107#issuecomment-379021...

I've had a beef with Stale since early on. It's a very old-world view of solving the problem of open source capacity. A better tool would instead try to find and encourage new resources (new contributors), whereas stalebot drives them away, and so kinda cuts the project off at the knees

It save cognitive and emotional resources of current contributors (in the short-term view), but driving future contributors away (in the long-term).