"Everything is a URL" is a win for browsers because everything with a URL can be linked to and bookmarked.

But it seems like for type safety, you wouldn't want different OS services with different API's to have the same type? If they aren't actually interchangeable, pretending they are with a common naming scheme is just a source of bugs.

I think e.g. a different protocol may give an idea of differently typed namespace. Imagine (not from real Redox:)

   block-device://sata/disk1/partition2
   ethernet://eth1
   usb://hid/keyboard1
   i2c://temperature/chassis1
   net://vpn1/node/somewhere/else

Well, that's a major imstake -- now I need to know what service I'm talking to, which means that I can't transparently replace my /dev/net with a userspace proxy. Unix half screwed this up, and they took the mistake and perfected it.

Redox is a microkernel. All drivers are run in userspace. I'm not clear on what your criticism is here.

You can replace anything transparently, the Redox kernel supports scheme namespacing.

So, for example, can I replace my network traffic with a file for testing, by binding a scheme to a file on disk?

To do that, you need to use a driver that translates between a file: and ip: (or ethernet:, tcp:/udp: or network:, allowing binding at different levels of the stack), because the protocols allow different operations. Said driver of course runs in userspace (because microkernel) and already exists. (Because it's absolutely needed for development.)

> driver that translates

That's something new... So, for the N-th device type in addition to the device driver I might need 2*(N-1) translating drivers!

Most of those would be meaningless, or require enough decisionmaking that the program between them cannot reasonably be called a driver. What kind of driver translates between audio and window system objects?

In any case, you only need 2N for translating both ways between file: and whatever: to get the same experience Unix does, and wherever that makes sense it is usually provided.

The win is of course that each of those protocols can be strongly typed and provide exactly all the operations that make sense for that protocol. Basically, think of all the things IOCTL does and give them their own names.

Ioctl was a horrible mistake, since it prevents configuring and introspecting devices with general interfaces and ad-hoc scripts.

This elevates the mistake, and polishes the worst of the early Unix conceptual fuckups.

Is there any advantage to be gained from that versus having file:// urls? With the latter, every file is also a url.

> Is there any advantage to be gained from that versus having file:// urls? With the latter, every file is also a url.

it can be used as a primitive typing layer

That sounds a lot more different from Unix than Linux, which is commonly described as Unix-like.

Assuming that "Unix-like" is a spectrum, why does Linux have to be the furthest point from Unix?

Well, Linux seems to be the Unix of today.