There may have been less pushback if this had been expressed up front. But also, what is it ? Is it to "test the architecture applied to nats" or is it to be a fully fledged NATs replacement (as per the impression given by table at the bottom of the website) - which becomes much harder if AI has significantly re-written the authors original code (and commented it badly).
Fair point. And as what it is, not a nats replacement, certainly dont have the time to maintain that this way, a test/tech demo/fun side project that yielded super interesting results is probably the answer. As usual I'm probably way too enthusiast when I see some nice results like that and the goal here was to talk about that, but it shifted super fast. So yes Claude rewrote lots of parts, and that's what I love about it. Testing an idea happens in way less time than before, and I find that super cool.
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.
https://news.ycombinator.com/item?id=46452907 https://news.ycombinator.com/item?id=46452841
There may have been less pushback if this had been expressed up front. But also, what is it ? Is it to "test the architecture applied to nats" or is it to be a fully fledged NATs replacement (as per the impression given by table at the bottom of the website) - which becomes much harder if AI has significantly re-written the authors original code (and commented it badly).
The website being AI coded I can take or leave.
reply