> On Tue, 2010-06-08 at 13:03 -0700, Scott Rotondo > wrote: > > Several people have pointed out that the harm from > removing these > > commands isn't that great because > > > > (a) recent scripts tend not to use this mechanism > to figure out the type > > of platform, and > > > > (b) older scripts will still work (with error > messages) because a > > missing command evaluates to false. > > > > But what about the other side of the cost-benefit > equation? What's the > > upside from removing a handful of tiny files? I'm > afraid I don't see it. > > Its there: > > a) people might decide that these are good tools for > portability checks > (they aren't!) > > b) people might complain that other processor types > are not included, > but we've already said that no new cpu types are > getting added > > c) therefore, should folks doing new ports create > them for arm, s390, > etc.? I hope not! > > d) every bit costs something. to compile, to link, > to deliver. Just in > the listing of /usr/bin. Anything which serves no > useful function > should IMO be removed. (Individually, these costs > are minuscule, but > taken collectively over the entire life of a > distribution, across > everyone who ever looks at them, has to compile, > build or install them, > and across multiple such "trivially useless" > projects, the costs can be > much larger.) > > -- Garrett
In general, this might be true. But in case of these, they're all hard links (total of 29 on snv_97, at least) to a single executable, which just compares the basename of its argv[0] with uname -p, uname -m, uname -c, and some hardcoded constants. It doesn't need to be changed in any way to add or delete names; only links need to be added (or if there were any appreciable benefit, deleted). This is not something that's going to get more broken over time, except in the sense of a smaller percentage of truth values (eventually zero) returning true on any platform existing outside of museums, collectors, and emulators. Granted that it's a stupid command. Granted even that adding more links to it might be counterproductive; and that others (googling shows me HP in particular) have also deprecated the command (although the man page of theirs I found was dated 2002; I have no idea if they or others have weeded out old processor names since then). The common intent seems at the least not to _add_ any more names to it, but to encourage the use of uname or getconf directly instead. Nevertheless, if there are _any_ scripts that use it, unless you get rid of all 29 (or however many) links to it, I don't see any incremental gain by removing some of them. -- This message posted from opensolaris.org _______________________________________________ opensolaris-arc mailing list [email protected]
