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