> It would also be faster if we referred to files by their inode numbers. But we have filenames, and I don't want to speak for everybody but I think people like them.
Actually, we do refer to files by their inode number, not by their name. The system uses the name to lookup the inode number, and then use the inode number.
Maybe I misunderstood you initially[1], but you weren't proposing to keep the numbers and use a lookup service for the name. AIUI, you proposed to replace the number with a name, no?
In which case, absolutely no one is proposing to replace inode numbers with names, so inode numbers/filenames as an example does not validate or lend support to your proposal for replacing port numbers with names.
[1] I'm on a personal quest to stop misunderstanding people in a way that reduces the strength of their argument. It's not going as well as I though it would, and I still do it sometimes.
Well, frankly I don't care how the ports are implemented, by numbers would be fine. As long as it means that from the user's point of view they are names. A config file like /etc/services is too simple because I create ports all the time, even from scripts, and I don't want to always become root to change the config; and other systems that want to connect to ports on my machine can't read /etc/services on my machine.
If you want to do a lookup translation and only use names on your local machine, it's only an hour of work or so to create a program that modifies the services file, and then make that program setuid root.
However it only works on your machine.
If you want to have it work on your local machine, DNS SRV records on your local network would work.
The proposal to use names and not numbers breaks down when you want the rest of the world to follow suit, because it's not technically possible within IP, only on top of IP.
> The proposal to use names and not numbers breaks down when you want the rest of the world to follow suit, because it's not technically possible within IP, only on top of IP.
> > The proposal to use names and not numbers breaks down when you want the rest of the world to follow suit, because it's not technically possible within IP, only on top of IP.
> This is exactly my point.
In which case, refer to my original response to your proposal - it's not practical to slow down every networking device in the world by a large factor.
It's like asking "why aren't we commuting at 1/3 the speed of light?": it's neither feasible nor practical.
Sure, it's possible, in that the physics involved make it possible, but not practical, because the limiting factor is not the physics involved.
Surely we can build some protocol on top of IP. I see people mention SRV records. These seem useful, however not very user-friendly at this point, so people don't use them.
DNS has SRV records. That is all you need, that is your solution, it exists. That they are not widely adopted in the manner you propose may be unfortunate, but completely upending protocols doesn't seem like a better or more realistically adopted solution either.
Actually, we do refer to files by their inode number, not by their name. The system uses the name to lookup the inode number, and then use the inode number.
Maybe I misunderstood you initially[1], but you weren't proposing to keep the numbers and use a lookup service for the name. AIUI, you proposed to replace the number with a name, no?
In which case, absolutely no one is proposing to replace inode numbers with names, so inode numbers/filenames as an example does not validate or lend support to your proposal for replacing port numbers with names.
[1] I'm on a personal quest to stop misunderstanding people in a way that reduces the strength of their argument. It's not going as well as I though it would, and I still do it sometimes.