[skissane]

Is anybody trying to lift that limitation? It seems like an obvious target for kernel devs to tackle.

If Linux and *BSD did it (especially if they adopted a mutually compatible implementation), the POSIX standardisation team (Austin Group) would likely be interested in adding it to POSIX, and Windows/macOS/AIX/etc will likely follow their example sooner or later.

[searealist]

Linux has an extension that allows an arbitrary string that is not tied to the filesystem. This makes it easier to stay within the limit or you can crypto hash an arbitrarily long string down to 108 chars.

[cpuguy83]

This can be pretty dangerous because it is basically the same as using a TCP socket on localhost (assuming you are speaking of abstract sockets).

[skissane]

Even though you lose the filesystem-based security, you can still use SO_PEERCRED or getpeereid and validate the caller's UID is what you expect, something which Linux doesn't support on localhost TCP sockets. Requiring the client's UID (and maybe GID too) to be the same as your own is a sane default for services intended for per-user usage.

[searealist]

Yeah, abstract sockets, good points about security.