On 19/01/2016 18:51, k...@aspodata.se wrote: > James: >> <karl <at> aspodata.se> writes: >>>>> I found a workaround in the sys-fs/static-dev package. >> >> Interesting read :: bgo #107875 > > I'm new to gentoo, is there some special semantic to the "bgo #" ? > >>>> 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. > > I have had no pain useing an old plain /dev. What's the pain ?
take a machine running a desktop. Plug in a usb printer. Where's your node? That's the whole point of a dynamic dev manager, it responds to devices changes that occur on normal modern machines and does TheRightThing(tm) - currently defined as whatever the dev-manager config tells it to do. I'm having a hard time thinking what kind of machine you have in this day and age that can do mail and also does not need a dynamic device maanger. Please enlighten us, or are you perhaps using MAKEDEV? > >>>> 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? > > No, I never used udev et al on my boxes, there has simply been no need. > >> 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. > > I never had any compelling reason to let some daemon with mess with > /dev. And I have had a compelling reason to avoid it, when doing an > "usual" stable dist-upgrade of Debian lenny to squeze (I think), Debian > installed udev per default and everything just stopped working. And > that darn thing wouldn't uninstall and /dev wouldn't unmount to get > back my /dev-entries. So udev have only giving me pain and no gain. > The only thing dynamic theese days are usb. Usb disks I can handle > manually, usb kbd/mouse has always worked. I usually don't use more > than one keyboard so I don't really need xkb, nor do I need something > to autodetect keyboard layout, since I change it to something else > anyhow. And udev woun't detect my serial mouse anyhow... so much for > that. > > That said, if I would like to test some "dev-manager" (except myself) > than I'd look into something that behaves nicely, like mdev (busybox) > or vdev (https://github.com/jcnelson/vdev.git). Sounds like you made one mistake once and that has now become the world for you. Almost no-one else here has reported dynamic dev managers make "everything just stop working". What you will hear is lots of whinging about udev - actually it's whinging about udev's maintainers cleverly disguised as whinging about the software - but as a class of software they all get the job done and do it well. -- Alan McKinnon alan.mckin...@gmail.com
