[email protected] writes: > Standards in the real world can and have been changed. Maybe with more > real world reasons behind them, like safety. (Witness the NEC, for > example. One might argue that some of its rules that were changed were > changed from one somewhat arbitrary standard to another, but in the > interest of safety (well, and standardization).
Okay, yes, that's true -- my statement was too strong. It's not really true that you can *never* do this. Sometimes it's okay to break the world because there's some other, more compelling goal. Or the older standard was sufficiently broken that there's really no defense for keeping it (like the C gets library function). But that usually doesn't apply to namespacing standards, and particularly not to namespacing standards where there isn't a scarce resource in play. It's vaguely possible that we might successfully reclaim some of the now-unnecessary reserved parts of the IPv4 namespace (but also possible that we can't), since IPv4 is very space-constrained, so people have some motivations to try. But for file mount naming, it's hard to see a compelling reason to try to structure the file system under /mnt when previous standards defined it as unstructured. Yeah, it's maybe a bit wasteful and maybe a bit duplicative, but directories are cheap. It's hard to justify breaking any existing configuration when one can always standardize a new path with little real pain. With this sort of namespacing standard, sometimes things are deprecated, but it's quite rare to actually reclaim and repurpose them just because it's hard to find a reason for doing so that justifies the disruption. Note, for example, that gets was handled by effectively removing it from the standard, *not* by changing the function signature and semantics so that it would be secure. It's quite unlikely that any future standard would reintroduce a gets function; there's no point when one can always pick a new function name. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ fhs-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/fhs-discuss
