As far as I can see, they wished to add a prefix to URL’s to make it easier to access certain… modules. What I fail to see is the reason for doing so. They already use the filesystem to specify what goes where, what is the use of adding a URL abstraction to it? Now they’d have to write code to handle name collisions and arguments. Sure, it’s not much work, but feels like a duplication of the likely to be included filesystem+filename and passing arguments to functions/executables/etc.
I don’t see it as fundamentally different from what Linux does with procfs and sysfs, except that it’s choosing URLs as the least-common-denominator abstraction, rather than files. I’m not clear, but it’s possible this is also meant to replace device nodes.
This is at best a small but nice refactoring. It really has become clear that when things that really aren’t filesystems pretend to be, it makes life difficult for backup/restore tools, and for anything else that needs to deal with actual files in bulk. It isn’t hard for those tools to code around it, but the ways filesystems can be mounted are open-ended, so the workaround is really to push that responsibility on the user, except for tools that assume everyone is on the most popular configuration and distribution. It’s a small thing, but it’s good to fix when designing something new.
I’m not thrilled, though, at the use of a new protocol name for every new namespace it needs. Protocol names are being allocated by a lot of parties already, for things like mobile deep linking (Wikipedia); accidental collisions seem like they’ll be fairly rare, but it’s easy to imagine security holes caused by deliberate collisions.
It would be much better to use a single protocol name - perhaps kernel: or os: - and make the namespace be the first path component. The correct way to do this while not messing up the structure of URLs would be, to use the example from your link, kernel:///port_io/60. There are three slashes because if the component after the first two slashes is included, it’s really supposed to be a hostname or IP address; not that there aren’t nonstandard URL schemes violating this already, but if the idea were to ignore the existing standard, why use the URL syntax at all?
In general, of course, hardware devices exist in a tree, especially for USB, so using the path structure does make sense and I don’t think having support for paths in the dispatch logic is bloat; it’s needed.
Anyway, I think the approximate motivation is to refactor things that have been handled through the filesystem to-date. Whether the replacement is any better will have to be seen with time.
My familiarity with java has faded, but one problem with such schemes is they often default to http, but what happens is a string like “banana” flows into the URI() constructor. Now, instead of opening a file named “banana” on the local computer, it’s making network requests to some random server. So you prepend “file://” to everything, but now you sometimes get “file://file://”. Sigh.
Making sockets and files behave similarly is probably the right level of abstraction. Making resource names and file names the same is going too far. There are network filesystems that put resources “over there” in your filesystem namespace, if that’s what you want, and they mostly support filesystem like semantics. Trying to ram all of the internet into a “transparent” abstraction, however, is a very leaky abstraction.
I run into such bugs in software I use at least once a year.
Even when the software is correct, the user experience can be rough. I have filesystems littered with files named “tedu@server” because I forgot the trailing colon when running scp. Not an easy problem to solve, and I don’t think scp is doing the wrong thing, but just an example of the subtleties.
(You alluded to security above; browser exploits abusing chrome:// URLs are also made possible by the same “let’s reuse this convenient construct” mentality.)
Thanks. That makes a lot of sense to me. In my fantasy world, Java would have an expressive type system such that you couldn’t pass in “banana” without having declared somewhere that it’s a filename… whereas “file://banana” would have had to be declared as a URI, so you’d always know whether you’d prepended or not. Unexpected polymorphism is the cause of a lot of problems.
Sockets really support a subset of what files do; in particular, you can’t rewind or seek them. But I agree that it works pretty well. But yes, it’s the filesystem where the analogy breaks down. Network filesystems not only don’t match the performance characteristics naive programs are expecting; many of them can’t handle locking semantics, or do so less robustly. Some good example code that does the best it can with this can be found in the SQLite implementation. It’s a large amount of work.
“Yay” for the chrome:// example. I wasn’t familiar with it; thank you.
Well, if all you’re doing is handing around open file streams, the banana thing wouldn’t be so much of a problem.
I’m actually a huge fan of filesystems that try to unify remote and local resources–in principle. Unfortunately, the only one that really did things correctly (including the tricky business about authn and authz) was 9P and friends.
I think that URIs do too much in combining protocol, authentication, host, and resource. A segmented approach might’ve been a good idea.
Cool, I’m sure this is a wonderful idea, but one thing that must always be kept in mind when taking advantage of new software that old software will almost always have an advantage with: unknown unknowns. By this I’m referring to the experiences that the C version of the UNIX operating system has been through: major flaws, enhancements, and security patches that the Rust written equivalent operating system will not directly encounter, potentially until mass adoption occurs, or rigorous, yet extensive testing.
Surely, that’s an argument for doing new things to find out what the problems with them are? I mean, it applies to every piece of software ever written.
Yep, and so I feel that people might be less inclined to adopting this OS knowing both the new OS itself and the language in which it’s written in have unknown unknowns. There’s sort of a double risk taking here.
It’s unfortunate though, because people are so comfortable with their legacy software that they don’t want to use their time and resource to find out if there are potentially more powerful solutions after taking the time to eliminate these unknown unknowns.
More accurately, the beginnings of such an OS.
I find the idea of Everything is a URL to be… intriguing.
As far as I can see, they wished to add a prefix to URL’s to make it easier to access certain… modules. What I fail to see is the reason for doing so. They already use the filesystem to specify what goes where, what is the use of adding a URL abstraction to it? Now they’d have to write code to handle name collisions and arguments. Sure, it’s not much work, but feels like a duplication of the likely to be included filesystem+filename and passing arguments to functions/executables/etc.
I don’t see it as fundamentally different from what Linux does with procfs and sysfs, except that it’s choosing URLs as the least-common-denominator abstraction, rather than files. I’m not clear, but it’s possible this is also meant to replace device nodes.
This is at best a small but nice refactoring. It really has become clear that when things that really aren’t filesystems pretend to be, it makes life difficult for backup/restore tools, and for anything else that needs to deal with actual files in bulk. It isn’t hard for those tools to code around it, but the ways filesystems can be mounted are open-ended, so the workaround is really to push that responsibility on the user, except for tools that assume everyone is on the most popular configuration and distribution. It’s a small thing, but it’s good to fix when designing something new.
I’m not thrilled, though, at the use of a new protocol name for every new namespace it needs. Protocol names are being allocated by a lot of parties already, for things like mobile deep linking (Wikipedia); accidental collisions seem like they’ll be fairly rare, but it’s easy to imagine security holes caused by deliberate collisions.
It would be much better to use a single protocol name - perhaps
kernel:oros:- and make the namespace be the first path component. The correct way to do this while not messing up the structure of URLs would be, to use the example from your link,kernel:///port_io/60. There are three slashes because if the component after the first two slashes is included, it’s really supposed to be a hostname or IP address; not that there aren’t nonstandard URL schemes violating this already, but if the idea were to ignore the existing standard, why use the URL syntax at all?In general, of course, hardware devices exist in a tree, especially for USB, so using the path structure does make sense and I don’t think having support for paths in the dispatch logic is bloat; it’s needed.
Anyway, I think the approximate motivation is to refactor things that have been handled through the filesystem to-date. Whether the replacement is any better will have to be seen with time.
This is given me flashbacks to the Java everything-is-a-URI school of thought.
A write-up of the specific inconveniences there would certainly be interesting.
My familiarity with java has faded, but one problem with such schemes is they often default to http, but what happens is a string like “banana” flows into the URI() constructor. Now, instead of opening a file named “banana” on the local computer, it’s making network requests to some random server. So you prepend “file://” to everything, but now you sometimes get “file://file://”. Sigh.
Making sockets and files behave similarly is probably the right level of abstraction. Making resource names and file names the same is going too far. There are network filesystems that put resources “over there” in your filesystem namespace, if that’s what you want, and they mostly support filesystem like semantics. Trying to ram all of the internet into a “transparent” abstraction, however, is a very leaky abstraction.
I run into such bugs in software I use at least once a year.
Even when the software is correct, the user experience can be rough. I have filesystems littered with files named “tedu@server” because I forgot the trailing colon when running scp. Not an easy problem to solve, and I don’t think scp is doing the wrong thing, but just an example of the subtleties.
(You alluded to security above; browser exploits abusing chrome:// URLs are also made possible by the same “let’s reuse this convenient construct” mentality.)
I’m glad I’m not the only one. Yeesh.
Thanks. That makes a lot of sense to me. In my fantasy world, Java would have an expressive type system such that you couldn’t pass in “banana” without having declared somewhere that it’s a filename… whereas “file://banana” would have had to be declared as a URI, so you’d always know whether you’d prepended or not. Unexpected polymorphism is the cause of a lot of problems.
Sockets really support a subset of what files do; in particular, you can’t rewind or seek them. But I agree that it works pretty well. But yes, it’s the filesystem where the analogy breaks down. Network filesystems not only don’t match the performance characteristics naive programs are expecting; many of them can’t handle locking semantics, or do so less robustly. Some good example code that does the best it can with this can be found in the SQLite implementation. It’s a large amount of work.
“Yay” for the
chrome://example. I wasn’t familiar with it; thank you.If you really want to know how Java does it, read the docs. For both URIs and URLs, because they’re different.
http://download.java.net/jdk7/archive/b123/docs/api/java/net/URI.html#URI%28java.lang.String%29
http://download.java.net/jdk7/archive/b123/docs/api/java/net/URL.html#URL%28java.lang.String%29
They kind of describe what’s going on, but eventually just punt and say “go read RFC 2396” which foists a lot of complexity off onto the developer.
Thanks. I haven’t done Java recently enough to know where to look for that.
Well, if all you’re doing is handing around open file streams, the banana thing wouldn’t be so much of a problem.
I’m actually a huge fan of filesystems that try to unify remote and local resources–in principle. Unfortunately, the only one that really did things correctly (including the tricky business about authn and authz) was 9P and friends.
I think that URIs do too much in combining protocol, authentication, host, and resource. A segmented approach might’ve been a good idea.
Cool, I’m sure this is a wonderful idea, but one thing that must always be kept in mind when taking advantage of new software that old software will almost always have an advantage with: unknown unknowns. By this I’m referring to the experiences that the C version of the UNIX operating system has been through: major flaws, enhancements, and security patches that the Rust written equivalent operating system will not directly encounter, potentially until mass adoption occurs, or rigorous, yet extensive testing.
Surely, that’s an argument for doing new things to find out what the problems with them are? I mean, it applies to every piece of software ever written.
Yep, and so I feel that people might be less inclined to adopting this OS knowing both the new OS itself and the language in which it’s written in have unknown unknowns. There’s sort of a double risk taking here.
It’s unfortunate though, because people are so comfortable with their legacy software that they don’t want to use their time and resource to find out if there are potentially more powerful solutions after taking the time to eliminate these unknown unknowns.