Er, shell scripts targeting POSIX, that is. Not a custom _shell_ per se.
One of my trees from 2007 used some custom POSIX shell for that. I'm tempted to expand on that, but that's a rabbit-hole project and not necessarily an effective use of time.
Dear Webbonet: what are people's current favored alternatives in the “autotools but lighter and uncaring about porting to Tru64” space?
What I've been gravitating to for personal stuff most of the time when in language environments without their own canonical build tools has centered around GNU Make—and _specifically_ GNU Make, therefore being able to use all the extra features it comes with. But ./configure can still be useful for packaging, out-of-tree builds, etc.…
Today is a day for using a witness class of sorts in C++ to control access to lazy-initialized tables while being able to express the precondition of having initialized them as a constructor argument rather than calling the ensure-init function too many times and/or leaving the underlying arrays exposed.
The annoying part is that storing the object still requires a byte because C++ doesn't let you have an Actually Empty Object, but it still seems better than the alternatives.
I have also discovered `git commit --amend -C HEAD` for convenience.
What the heck is the situation with epmd and #SELinux support in #Fedora? From the looks of the ejabberd.te file, it handles the “Erlang programs normally autolaunch epmd as needed” by… what? Just incorporating it into their security domain? That can't be right, can it?
What's even more concerning is that /usr/lib/systemd/system/epmd.service _does_ exist, but the epmd running on my server is running as ejabberd_t.
Foo! The Fedora package for acme-tiny does not appear to support alternative ACME providers—only Let's Encrypt. That partially defeats the point of an open protocol, doesn't it?
More specifically, the /usr/libexec/acme-tiny/sign wrapper script which gets invoked by the timer unit does not have any provision for passing a --directory-url to acme-tiny itself. Hrmf.
The current counter that's sticking in my head is something like “explain it to me as though you were explaining it to ‹appropriate label for inexperienced people in the field›”. That feels heavy though, and it feels like it could result in having to pick through a lot of other information.
Something didactics-adjacent which came up via ruminating over something: How do you present a question to evaluate someone's handling of a situation when there's an element of the handling such that:
- Recognition that the situation makes this element necessary is an important thing you want to test.
- People who understand the situation well may not ever refer to the element naturally because it's too obvious to feel salient.
The one blocks off most obvious proactive handling of the other…
It's macaronic, but it has a nice alliteration. ‘Psychoclastic’ and ‘nooclastic’ don't quite feel right.
It looks like at least one push server does expose an OPTIONS response with CORS headers allowing POST from anywhere. So maybe that is the mechanism but it's not explicitly stated?
Okay, here's a question. When you use #WebPush per https://w3c.github.io/push-api/ and https://datatracker.ietf.org/doc/html/rfc8030… the application server receives the push target capability URI from the user agent, which is untrusted. How does the app server know that that's actually a push server rather than somewhere else the user agent is trying to get the app server to POST to for undesired reasons? I was hoping for something, say, vaguely CORS-like with a preflight OPTIONS or such… but I don't see that in RFC8030.
A well-intentioned hacker-type creature—by the old “drilling into the sky” definition, that is, not the later “criminal” definition. Austin, TX, USA.
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!