[hlandau]

Personally, Redox's use of URLs seemed like really bad design to me. It doesn't get simpler than the Unix path syntax.

Having a scheme:// makes sense for URLs because you don't otherwise have any contextual information indicating how to access a resource. But this isn't the case for something like a virtual filesystem, where the total set of filesystems mounted under it - and their types - are all known to the system. There's no need for disk://foo when you can just have /dev/disk/foo.

[mpweiher]

That's true when the namespace covers objects that are very similar to access, ideally identical.

If that's not the case, I have found the scheme to be helpful to indicate what's going on.

[hlandau]

On *nix, you can always figure out what type of filesystem is mounted at a given prefix by typing `mount`.

What the use of schemes does is make things needlessly inflexible, and embeds a dependency on the name of a filesystem provider inside consumers of that filesystem. It's akin to a Unix where filesystems can only be mounted in top-level directories /mnt, but not /mnt/foo, etc.; I don't see the appeal.

[yjftsjthsd-h]

I prefer to use `df -T /path/to/mount`, personally.

[vageli]

> I prefer to use `df -T /path/to/mount`, personally.

Why?

[yjftsjthsd-h]

Lets me specify a single file system; I don't think `mount` does that (unless I'm blind; possible).

[vageli]

Mount lets you do this as well.

mount -t type device destination_dir

Unless I am missing something in your use case.

[mpweiher]

> schemes make things needlessly inflexible

Not so. See file: :-)