| 1 |
James: |
| 2 |
> <karl <at> aspodata.se> writes: |
| 3 |
> > > > I found a workaround in the sys-fs/static-dev package. |
| 4 |
> |
| 5 |
> Interesting read :: bgo #107875 |
| 6 |
|
| 7 |
I'm new to gentoo, is there some special semantic to the "bgo #" ? |
| 8 |
|
| 9 |
> > > Let's be clear: static-dev is NOT a workaround. It is a full proper |
| 10 |
> > > solution for the case when a dynamic device node solution is not |
| 11 |
> > > desired. |
| 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 |
I have had no pain useing an old plain /dev. What's the pain ? |
| 18 |
|
| 19 |
> > > Of course it means you have to mknod every device you need yourself. But |
| 20 |
> > > you know that going in right? |
| 21 |
> |
| 22 |
> > Yes (though I alreade have a /dev from before). |
| 23 |
> |
| 24 |
> For explicit clarity, you've got a "/dev" from using dev-manager on the |
| 25 |
> system previously, and now you desire to switch to a static-dev? (Why ?) |
| 26 |
> Or did you derive from scratch (or other means) a '/dev' for a specific |
| 27 |
> need you are working on by design, historical example etc? |
| 28 |
|
| 29 |
No, I never used udev et al on my boxes, there has simply been no need. |
| 30 |
|
| 31 |
> I apologize in advance, but this thread intersects some critical new |
| 32 |
> thinking on systems cluster formation. I have ran into a small group of |
| 33 |
> extraordinary coders that are building a Hi Performance Cluster out of C, |
| 34 |
> Rust and a minimized static-dev. So I am very curious as to your specific |
| 35 |
> and detailed motives for this 'static-dev'. If a private note is warranted, |
| 36 |
> feel encourage for that type of response. If this unbounded curiosity of |
| 37 |
> mine is unwelcome, you have my deepest apologies. |
| 38 |
|
| 39 |
I never had any compelling reason to let some daemon with mess with |
| 40 |
/dev. And I have had a compelling reason to avoid it, when doing an |
| 41 |
"usual" stable dist-upgrade of Debian lenny to squeze (I think), Debian |
| 42 |
installed udev per default and everything just stopped working. And |
| 43 |
that darn thing wouldn't uninstall and /dev wouldn't unmount to get |
| 44 |
back my /dev-entries. So udev have only giving me pain and no gain. |
| 45 |
The only thing dynamic theese days are usb. Usb disks I can handle |
| 46 |
manually, usb kbd/mouse has always worked. I usually don't use more |
| 47 |
than one keyboard so I don't really need xkb, nor do I need something |
| 48 |
to autodetect keyboard layout, since I change it to something else |
| 49 |
anyhow. And udev woun't detect my serial mouse anyhow... so much for |
| 50 |
that. |
| 51 |
|
| 52 |
That said, if I would like to test some "dev-manager" (except myself) |
| 53 |
than I'd look into something that behaves nicely, like mdev (busybox) |
| 54 |
or vdev (https://github.com/jcnelson/vdev.git). |
| 55 |
|
| 56 |
Regards, |
| 57 |
/Karl Hammar |
| 58 |
|
| 59 |
----------------------------------------------------------------------- |
| 60 |
Aspö Data |
| 61 |
Lilla Aspö 148 |
| 62 |
S-742 94 Östhammar |
| 63 |
Sweden |
| 64 |
+46 173 140 57 |
Archives