<karl <at> aspodata.se> writes:
> > > I found a workaround in the sys-fs/static-dev package. Interesting read :: bgo #107875 > > Let's be clear: static-dev is NOT a workaround. It is a full proper > > solution for the case when a dynamic device node solution is not > > desired. Well, I can think of embedded (linux) systems, a lock-down server and machine(s) loaded up with (NFV) Network Function Virtuals, as prime examples where a static dev is very useful; albeit a management pain if one is not careful. This is a very interesting topic for me. > > Of course it means you have to mknod every device you need yourself. But > > you know that going in right? > Yes (though I alreade have a /dev from before). For explicit clarity, you've got a "/dev" from using dev-manager on the system previously, and now you desire to switch to a static-dev? (Why ?) Or did you derive from scratch (or other means) a '/dev' for a specific need you are working on by design, historical example etc? I apologize in advance, but this thread intersects some critical new thinking on systems cluster formation. I have ran into a small group of extraordinary coders that are building a Hi Performance Cluster out of C, Rust and a minimized static-dev. So I am very curious as to your specific and detailed motives for this 'static-dev'. If a private note is warranted, feel encourage for that type of response. If this unbounded curiosity of mine is unwelcome, you have my deepest apologies. curiously, James
