What are people using to edit entries - because while markdown is fine, a lot of the time I want to be able to drag in screenshots, snippets of other documents like rfcs and so on. So it ends up being easier to make those notes for myself rather than push them into anything publishable.
The problem is that they react to lights from the opposing vehicle, but they are going to hit your eyes before they detect your lights.
That's with simple high beam assist. The matrix ones you refer to actually have another feature which makes things even worse; they progressively dip the light in parts, but combined with the first effect this means that you have a few seconds of being blinded before all of their component leds have been dipped.
Not to mention that they are only reacting to something directly in front of them for the most part -- meaning you can be blinded on curves, or when turn around and looking at them off axis (say as they wait to turn into a road).
I doubt this hypothesis, because duckdb written in c++ should be able to tolerate memory failure, while this written in rust has to deal with rusts memory allocation failures are panic's behavior.
That is to say that if the issue is duckdb running out of memory, it is most likely because the rust implementation is using memory more efficiently for whatever query is crashing duckdb, rather than graceful handling of memory allocation failure.
Where it is possible in c++ to gracefully handle memory allocation failure, it is not really a thing in rust I'm not even sure whether it is possible to catch_unwind it.
I say this as a rust person who doesn't fancy c++ in the slightest...
You cannot use the rust standard library in environments where arbitrary allocations may fail but neither can you use the STL. The difference is the rust standard library doesn't pretend that it has some reasonable way to deal with allocation failure. std::bad_alloc is mainly a parlor trick used to manufacture the idea that copy and move fallibility are reasonable things.
I wouldn't wager a nickel on someone's life if it depended on embedded STL usage.
I’ve never seen anyone try to catch allocation failures in C++ code and in many cases doing so correctly is very difficult, not least of which is that writing exception-safe code is the exception, not the rule.
Hmm, is that desirable? If someone's going around sending SIGTERM to random processes they might also send SIGKILL, and there's no way Nitro can propagate SIGKILL to processes it starts.
It does, because SIGTERM is traditionally understood as the trigger for a shutdown. Docker - for instance - will send a SIGTERM to pid 1 when a container is stopped - which goes back to a previous comment here about using a real init as pid 1 if the thing in your container forks: https://news.ycombinator.com/item?id=44990092
Interesting! I didn't know that—I thought that when you told sysvinit to change its runlevel you normally used some slightly richer interface than signals.
runsvdir receiving TERM should only happen when stage 2 is triggered to end.
Once that happens, the individual runsv processes are still supervising their individual tasks and can be requested to stop through their respective control sockets. It's how standard stage 3 is implemented.
reply