I could see a use for both - using Lustre as a shared SAN for their flame/smoke/etc suites and using pNFS for workstation/render-node shared storage. at least that's how i've deployed things in the past.
i could see this replacing isilon (which is built on freebsd) for the later use-case :)
NVMe supports SR-IOV much in the same way that NICs do - which i suspect is how AWS is delivering "physical" NICs to VMs currently. So its a pretty safe bet that this is how NVMe devices are being delivered to guest Vm's.
thus spoke the manual nvme(4):
"The nvme driver creates controller device nodes in the format /dev/nvmeX and namespace device nodes in the format /dev/nvmeXnsY."
it's been a while since i've had access to nvme gear but it "just worked" at the time - although my use case was for a a daemon that accessed the block device directly to do its own horrible things to it.
"The Design and Implementation of the FreeBSD Operating System" not only does a great job at covering how the UFS filesystem is implemented, but also does a great job at explaining how and Unix systems are implemented. I highly recommend this book to anyone with an interest in Unix internals.
Is that book similar in structure to the book "The Design of the Unix Operating System" by Maurice Bach? (or is it Design and Implementation of ... don't remember - had read it some years ago).
As another commenter mentions SCTP can be encapsulated if needed. SCTP is actually in pretty wide use in online gaming, and has been since at least 2007...
That's a great counterpoint, too. Both essays seem right. I think the solution is a hybrid... something in the middle as usual. I think an exploration into hybrid models that build on both traits is the best route. I'm eyeballing Rust as an example as it has a team doing Cathedral model with guidance and ecosystem from Bazaars. I see good and bad in it that come from aspects of both. Very interesting.
Not really. The strlcat function is safer because it always NUL terminates the destination buffer, and therefore makes bugs in user code less likely. The flaw here is just an implementation defect.
Also note that SIZE_MAX is an unreasonable input, one would even say it violates preconditions.
No, passing SIZE_MAX does not violate any precondition of strncat(), because preconditions are fixed properties chosen in advance, not something you add retrospectively when you feel like it.
The C standard does not place any upper bound on the value of strncat()'s size argument, so an strncat implementation has to work as described for all large values of the argument. It's a bug of the implementation if it doesn't, not a violated precondition.
(Reasoning about C programs has been my day job for several years. Contrary to what many think, it is possible, it only needs that the rules be set in advance and respected.)
> Also note that SIZE_MAX is an unreasonable input, one would even say it violates preconditions.
Annex K adds rsize_t, RSIZE_MAX, and friends, which restrict inputs to reasonable values. Unfortunately, it doesn't retcon the old functions like strncpy, and worse, no one actually implements it.
A very early version. Among other differences the functions don't care about RSIZE_MAX (even though newer VS versions define and use rsize_t). However the Windows SDK contains <strsafe.h> which does limit the length of strings (STRSAFE_MAX_CCH).
