On Thursday, January 08, 2015 10:46:14 PM I wrote: > [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.
Fair response! I do agree that it is often not easy to do, and yes, there is not much benefit (vs. cost) to do it for namespacing issues. _______________________________________________ fhs-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/fhs-discuss
