Besides it is:
- fully programmable and extensible with Python scripts
- has out of the box alerting
- support for capture files
- highly customizable regarding transporting events to output sinks
One thing to note about railcar is that it completely lacks the network stack, but it will probably be my "starting point" if someday I decide to evolve `rabbitc` into something "more serious".
Sure, there is definitely a lot of possible improvements for the code examples, like avoiding `clone` on a heap allocated strings, etc. I had some really odd issues when passing a statically allocated strings to the `libc` functions (the function's arguments from the previous calls ended up concatenated in the later function's invocations, just use `strace` to observe that behavior).
I probably could wrap in the `unsafe` block just the invocations to the system calls. I'm learning Rust and I wanted to give the post some freshness. There are already a plethora of examples in C.
That's a bizarre argument; the post is about writing an abstraction over another interface, and it's clearly meant to be extended. The abstraction can be written in a safer language than C. Seems like there's an obvious upside.
The large unsafe call inside pivot_root is much larger than it needs to be. It only needs to encompass the mount() call in that function. It's a pretty trivial change to have it only wrap the if. (Though it could wrap less, but that would either look uglier or need a variable binding the result, which honestly wouldn't be that bad either.)
With Rust you can at least have some certainty of where problems could happen. It gets boxed inside unsafe and affords extra scrutiny. You don't have to worry much about everything else surrounding you code.
Disclaimer: only went through basic tutorials and I don't program in Rust daily.
