4 Jan
2022
4 Jan
'22
4:57 a.m.
Theodore Ts'o wrote:
Well, take a look at the ip-route man page. The BSD
route command
assumes fundamentally there is a single routing table that you can
update. In Linux, there are multiple routing tables --- to support
NAT, VRF (virtual routing and forwarding), etc.
Non-exhaustive research (didn't look at NetBSD, OpenBSD or Dragonfly):
Looks like the FreeBSD route got the -fib argument in November 2012,
the setfib command (execute a command with an alternate routing table)
appeared in 2008.
Looks like the ip command appeared in Linux 2.2 (end of 1999), so it
doesn't look like there was a lead to follow.
Now don't get me wrong, I have no lost love for the BSD route command,
it almost always takes me at least four tries; one for a syntax error,
one to add a bad route, and another to remove the bad route!
BUT, as someone who has been using BSD based systems since 4.2, it's
hard not to feel like GNU and Linux folks have evidenced a pride that
they're better than Un*x (I remember at a Usenix (Boston in '94?)
overhearing a VA Linux employee boasting how their goal was to beat
out commercial Un*x vendors. Too bad they weren't aiming at the
Windows desktop...) and missed the boat on "Unix philosophy", but I'm
well aware that what I remember with fondness as simpler times was
contemporaneously viewed by others as "beginning to smell really bad".
Finally, I'm new here, but I can't help feeling that both complaining
and boasting about Linux aren't within the realm of "Unix Heritage"?
But discussion of lessons learned by Bell Research post 7th Edition,
are of greater interest to me.
Keeping ".." working is certainly a major pain in the a**, and I can
understand wanting to throw it in the ditch, but I came from the DEC
36-bit world (TOPS-10/20 and ITS) which didn't present a single,
uniform file name space (full paths started with "DEVICE:", and
different device handlers could treat the following name space
differently), and I've never been convinced that the Unix single
namespace hasn't brought just as much pain as benefit.
ITS in particular had device handlers that were dynamically loaded
into another process and commuinicated thru a special device handler
handler (the JOB device) that translated system calls to messages.
Listing the directory of a spooled print device would show the queue,
and there was also network file access to other ITS machines).
The DEC systems had system and user defined "logical devices", which I
do remember fondly as causing less pain than symlinks. ITS may have
had both symlink and logical device-like things...