> But exactly what does the 18k files cost it? Similarly, we could drop > ldconfig runs in %post and just have all of the symlinks created on each > boot, but that doesn't strike me as a good idea either. It's a useful > optimization to have them laid down by the install because then you > never have to create new device nodes. Which can be a lot of device > nodes per device. Changes to device naming is simple -- just make what > gets used for the creation the same as what gets used in the dev > package's spec file. Nice and simple to do with current infrastructure. I think we will have to provide more flexibility here. I personally also like to populate /dev at install time and then don't worry about scanning devices on each boot and I personally still don't use devices I attach at runtime to my systems. I think I would also disable udev on startup for my machines the same way I disable kudzu now and some other scripts on bootup I don't need. I still think this is useful to other people. udev has been tested against pam, selinux and provides this greater flexibility. The comments here have been right. E.g. there is no reason the list of devices within the udev database should not be synchronized against our static makedev package and many other changes probably also make sense. In my opinion this means further integration of udev is needed, not keeping it away. Incrementally adding to udev is way better than trying to come up with a new way to solve the same things. > > Plus we can't get away from the fact that /dev really is a dynamic > > system. Even if we ignore hotplug, we are modifying the permissions > > on it for the console user stuff. As such writing these changes to > > disk across reboots is wrong. > > I disagree. We'll just agree to disagree here. And I think people are right if they want to have machines running without udev, but also see that for other setups it will be needed. I'd argue that way more testing is needed until we know for sure that a tmpfs on bootup is working fine, but I don't see a reason to stop further development in that direction and thus further integration of udev. > Yes, but does that mean that we should add more overly configurable bits > when something far simpler would suffice? Couldn't you add to udev to make it simpler again? > Except that with what udev currently allows, you can't do so with one C > program... because everyone wants a different way to do it. It's gonna be needed in the future. (Blinking, colored, flashing devices and my daughter will love them... ;-) > Existence doesn't necessarily make something the best solution to a > problem. In cases with significant architectural impact on the system, > it's far better to take a little bit longer and get a better technical > solution than to throw in something just because it's there. I'll just > point to the file choose in gtk as an example here :-) You have valid points. udev is still under more active development and I hope some of the concerns are picked up and resolved in newer releases. gtk is also not dying due to revamped additions of a file chooser, even if many apps might suffer from the first version of it or have written their own implementation of it. greetings, Florian La Roche
