5 ms·

I am convinced that this is the right path for OS evolution. Perhaps not necessarily .NET based, but the future OSes simply have to borrow heavily from the best

I am convinced that this is the right path for OS evolution. Perhaps not necessarily .NET based, but the future OSes simply have to borrow heavily from the best of the current VM implementations: garbage collection, JIT compilation and rich standard library should all be provided by the OS (as opposed to in-process VM) and shared between all processes written in higher level languages. The separation of kernel/userland must also go away and process isolation should be done via code verification, another trick a modern (yet non existent) OS must borrow from sandboxing VMs.

uriel 17y ago
Heard of Inferno? http://code.google.com/p/inferno-os/ http://code.google.com/p/inferno-os/ Bell Labs as usual well over a decade ahead of their time...
- daeken 17y ago
  Inferno is very interesting. However, I tend to believe that having the entire kernel written in managed code is the way things need to go. By doing so, you reduce the attack surface to a tiny amount of code and make it easier to develop. That said, Inferno was way ahead of its time, and quite a few of the ideas in my system are based on ideas from it and Plan 9 itself; for example, the 'everything is an object' paradigm is really a natural extension of Plan 9's 'everything is a file' paradigm.
  - uriel 17y ago
    > for example, the 'everything is an object' paradigm is really a natural extension of Plan 9's 'everything is a file' paradigm. I used to think that way long ago, over time I realized that it is the inverse: 'everything is a file' is an extension and very powerful refinement of the 'everything is an object paradigm. What makes file based interfaces so powerful is that they provide an uniform and almost universal framework for representing any kind of resources. The constrains that this imposes are very useful both technically (eg for uniform caching, remote access, proxying, filtering, namespaces, ...) and as a way to narrowly focus the mind when designing interfaces.
    - daeken 17y ago
      I wasn't speaking in terms of actual relations (since files are a subclass of objects in my mind), but in terms of what inspired me. That said, I disagree that files are a more powerful refinement. So much of our code is spent converting to and from files, it's a curse more than a blessing. The only really powerful thing about files is that there are tools on our current systems to manipulate them, but I don't think that has to stay that way. Why can't we grep over a collection object from the command line like we do with a file now? Why can't we have good network-transparent objects (a key feature in Renraku)? The file paradigm in general is tired, in my opinion. Streams just aren't a good mapping for the way we handle data.
      - barrkel 17y ago
        Strongly disagree re streams; streams / data-flow oriented programming is extremely easy to parallelize, and isn't going away in the future for at least that reason. It's trivial today to write a bash script utilizing fork/join parallelism (& and wait, in bash) with streams and fifos for data transfer, and only a little care with ordering to guarantee no concurrency bugs. I do it all the time. Objects overemphasize a method-full interface. Files force one to use a single pair of methods, read and write, which are the fundamental units of message sending. Objects as implemented in languages like C# are a bastardization of message sending, where the optimization of the message call reduces its composability in the large. When your messages are small packets of data, abstracting over communicating processes gets a whole lot easier.
      - DougWebb 17y ago
        Perhaps the design should be "everything is a Resource" (ala REST) rather than "everything is an Object". The beneficial aspect of "everything is a File" is the uniform interface: you can read a file, write to a file, seek to a particular position in a file (sometimes), and that's about it. It seems limiting, but that's what allows the huge number of interoperable tools to be built. By going with "everything is an Object", there are no constraints on the interface. Every class of objects has it's own set of methods, and tools need to be designed for specific classes/interface rather than for "everything". Interoperability will be lost. Resources are like objects, but constrained to uniform interface: their methods are GET, PUT, POST, DELETE, OPTIONS, HEAD. That's all the methods you need to manipulate individual objects and collections of objects. Of course, you'll need uniform identifiers (URLs) for the objects, and a uniform representation (or a set of standard representations.) This will give you network-transparent resources, assuming you use globally unique URIs. It also turns the OS into a generic Web Service. I'm not sure what the implications are of that, but it seems like it might be interesting to explore.
barrkel 17y ago
Yes, so we can all have the sluggishness of Java on mobile devices, as opposed to the sprightly iPhone application style.
omouse 17y ago
* but the future OSes simply have to borrow heavily from the best of the current VM implementations: garbage collection, JIT compilation and rich standard library should all be provided by the OS (as opposed to in-process VM) and shared between all processes written in higher level languages.* Hey, that sounds familiar...OH FUCK! It's been done a long time ago! The Lisp Machines and the Smalltalk machines! It shouldn't take much convincing to see that this is a damn good path for an OS to down...

uriel 17y ago

Heard of Inferno? http://code.google.com/p/inferno-os/ http://code.google.com/p/inferno-os/ Bell Labs as usual well over a decade ahead of their time...

daeken 17y ago
Inferno is very interesting. However, I tend to believe that having the entire kernel written in managed code is the way things need to go. By doing so, you reduce the attack surface to a tiny amount of code and make it easier to develop. That said, Inferno was way ahead of its time, and quite a few of the ideas in my system are based on ideas from it and Plan 9 itself; for example, the 'everything is an object' paradigm is really a natural extension of Plan 9's 'everything is a file' paradigm.
- uriel 17y ago
  > for example, the 'everything is an object' paradigm is really a natural extension of Plan 9's 'everything is a file' paradigm. I used to think that way long ago, over time I realized that it is the inverse: 'everything is a file' is an extension and very powerful refinement of the 'everything is an object paradigm. What makes file based interfaces so powerful is that they provide an uniform and almost universal framework for representing any kind of resources. The constrains that this imposes are very useful both technically (eg for uniform caching, remote access, proxying, filtering, namespaces, ...) and as a way to narrowly focus the mind when designing interfaces.
  - daeken 17y ago
    I wasn't speaking in terms of actual relations (since files are a subclass of objects in my mind), but in terms of what inspired me. That said, I disagree that files are a more powerful refinement. So much of our code is spent converting to and from files, it's a curse more than a blessing. The only really powerful thing about files is that there are tools on our current systems to manipulate them, but I don't think that has to stay that way. Why can't we grep over a collection object from the command line like we do with a file now? Why can't we have good network-transparent objects (a key feature in Renraku)? The file paradigm in general is tired, in my opinion. Streams just aren't a good mapping for the way we handle data.
    - barrkel 17y ago
      Strongly disagree re streams; streams / data-flow oriented programming is extremely easy to parallelize, and isn't going away in the future for at least that reason. It's trivial today to write a bash script utilizing fork/join parallelism (& and wait, in bash) with streams and fifos for data transfer, and only a little care with ordering to guarantee no concurrency bugs. I do it all the time. Objects overemphasize a method-full interface. Files force one to use a single pair of methods, read and write, which are the fundamental units of message sending. Objects as implemented in languages like C# are a bastardization of message sending, where the optimization of the message call reduces its composability in the large. When your messages are small packets of data, abstracting over communicating processes gets a whole lot easier.
    - DougWebb 17y ago
      Perhaps the design should be "everything is a Resource" (ala REST) rather than "everything is an Object". The beneficial aspect of "everything is a File" is the uniform interface: you can read a file, write to a file, seek to a particular position in a file (sometimes), and that's about it. It seems limiting, but that's what allows the huge number of interoperable tools to be built. By going with "everything is an Object", there are no constraints on the interface. Every class of objects has it's own set of methods, and tools need to be designed for specific classes/interface rather than for "everything". Interoperability will be lost. Resources are like objects, but constrained to uniform interface: their methods are GET, PUT, POST, DELETE, OPTIONS, HEAD. That's all the methods you need to manipulate individual objects and collections of objects. Of course, you'll need uniform identifiers (URLs) for the objects, and a uniform representation (or a set of standard representations.) This will give you network-transparent resources, assuming you use globally unique URIs. It also turns the OS into a generic Web Service. I'm not sure what the implications are of that, but it seems like it might be interesting to explore.

barrkel 17y ago

Yes, so we can all have the sluggishness of Java on mobile devices, as opposed to the sprightly iPhone application style.

omouse 17y ago

* but the future OSes simply have to borrow heavily from the best of the current VM implementations: garbage collection, JIT compilation and rich standard library should all be provided by the OS (as opposed to in-process VM) and shared between all processes written in higher level languages.* Hey, that sounds familiar...OH FUCK! It's been done a long time ago! The Lisp Machines and the Smalltalk machines! It shouldn't take much convincing to see that this is a damn good path for an OS to down...