5 ms·

A big issue I have with this "middleware as operating system" approach is that it invites, somewhat perversely in my opinion, throwing out your existing tools a

by magpi3 12y ago

A big issue I have with this "middleware as operating system" approach is that it invites, somewhat perversely in my opinion, throwing out your existing tools and replacing them with very, very, very similar ones that are better fits your new the middleware's paradigms. The whole "never have to leave Smalltalk", "never have to leave Emacs" etc. mentality means that everything has to be rewritten in your new middleware of choice... just so that you never have to leave it.

moonchrome 12y ago
Except the OS has a huge amount of overhead. The whole reason why the "event driven IO", callback mess, etc. is a thing is because of the costs of native OS threads. If you don't need the things OS provides (like process isolation when running a single process server) then you're paying a heavy cost. The thing about IT is that it has evolved over decades and as the layers were added to the stack on top of each other so many legacy design decisions are now rooted deep in to the stack - if you can blow away the whole thing and start from scratch you can get huge benefits for free. For example ZFS did the same thing with filesystems and they got many things for free just out of reexamining the initial assumptions that lead to the modern filesystems and re-evaluating them in a modern context. Getting rid of the OS is likely impractical for most things but it can probably net you big wins in specific scenarios.
- CHY872 12y ago
  I agree, but only up to a point. Of course, it'll help you loads in specific scenarios, but in many more you'll be able to get what you want by simply hacking around the parts of the operating system that gives you those issues in the first place. As one example, I remember one person describing to me how some of the banks had set their computers to give their user mode programs the ability to perform I/O directly by adding the appropriate memory locations of the network ports to their virtual memory. It destroys the protection, but massively improves performance. Most modern operating systems can in general be tuned or hacked to essentially get out of your way whenever you don't need them. You'd have to have a very specific use case to justify the creation of a whole operating system specifically to run your language - and an amazing business case. Importantly, in the actual real life use cases they're not talking about providing an operating system for actual hardware that has better performance (there'd be so much expense on application support) - they're talking about providing an operating system that targets a VM model. This is a major thing - it shows (to me at least) that they're using the OS model for the purposes of additional security as opposed to anything else (especially since it's Galois who have done lots of it).
- taeric 12y ago
  This is borderline crazy, though. The OS can have a lot of overhead, true. More likely, asking your computer to do a ton of different things is the actual overhead that is killing you. That is, not only is "getting rid of the OS" likely impractical, you are likely to see vast improvements by simply reducing the amount of tasks a given computer is being asked to do. The gains from eliminating the OS, specifically, probably pale to the gains from just not doing as many varied things in the first place.
  - moonchrome 12y ago
    It's not just about misusing the features - the person writing the OS made a bunch of trade offs in both design and implementation, and while those trade-offs might be the best for the scenario where they were made in (and they don't even have to be) it might not fit your scenario, sometimes you can get huge and easy (well the pain will come from remaking the parts of the stack you needed) gains if you can go down the stack and replace those wrong assumptions.
- charliesome 12y ago
  > The whole reason why the "event driven IO", callback mess, etc. is a thing is because of the costs of native OS threads. Nope. The whole reason why event driven IO is so popular is because of all the FUD that has been spread about the 'costs' of native threads. Native threads are cheap as hell on modern systems. Programming in an event driven style may be more natural for some problems, but for the vast majority of cases, native threads and blocking I/O is superior.
  - m0th87 12y ago
    Then how do you explain the fall of apache, and rise of nginx?
    - charliesome 12y ago
      Pop culture?
      - read 12y ago
        No, better design. "A-patch-y" was a collection of patches.
        charliesome 12y ago
        Like most open source software, no? Apache 2.4 is a pretty solid web server. So is nginx. They both have their ups and downs, but unless you have highly specialised needs, either will do the job.
        dllthomas 12y ago
        Like most software, period, past a certain age (and possibly even unqualified).

by magpi3 12y ago

moonchrome 12y ago

Except the OS has a huge amount of overhead. The whole reason why the "event driven IO", callback mess, etc. is a thing is because of the costs of native OS threads. If you don't need the things OS provides (like process isolation when running a single process server) then you're paying a heavy cost. The thing about IT is that it has evolved over decades and as the layers were added to the stack on top of each other so many legacy design decisions are now rooted deep in to the stack - if you can blow away the whole thing and start from scratch you can get huge benefits for free. For example ZFS did the same thing with filesystems and they got many things for free just out of reexamining the initial assumptions that lead to the modern filesystems and re-evaluating them in a modern context. Getting rid of the OS is likely impractical for most things but it can probably net you big wins in specific scenarios.

CHY872 12y ago
I agree, but only up to a point. Of course, it'll help you loads in specific scenarios, but in many more you'll be able to get what you want by simply hacking around the parts of the operating system that gives you those issues in the first place. As one example, I remember one person describing to me how some of the banks had set their computers to give their user mode programs the ability to perform I/O directly by adding the appropriate memory locations of the network ports to their virtual memory. It destroys the protection, but massively improves performance. Most modern operating systems can in general be tuned or hacked to essentially get out of your way whenever you don't need them. You'd have to have a very specific use case to justify the creation of a whole operating system specifically to run your language - and an amazing business case. Importantly, in the actual real life use cases they're not talking about providing an operating system for actual hardware that has better performance (there'd be so much expense on application support) - they're talking about providing an operating system that targets a VM model. This is a major thing - it shows (to me at least) that they're using the OS model for the purposes of additional security as opposed to anything else (especially since it's Galois who have done lots of it).
taeric 12y ago
This is borderline crazy, though. The OS can have a lot of overhead, true. More likely, asking your computer to do a ton of different things is the actual overhead that is killing you. That is, not only is "getting rid of the OS" likely impractical, you are likely to see vast improvements by simply reducing the amount of tasks a given computer is being asked to do. The gains from eliminating the OS, specifically, probably pale to the gains from just not doing as many varied things in the first place.
- moonchrome 12y ago
  It's not just about misusing the features - the person writing the OS made a bunch of trade offs in both design and implementation, and while those trade-offs might be the best for the scenario where they were made in (and they don't even have to be) it might not fit your scenario, sometimes you can get huge and easy (well the pain will come from remaking the parts of the stack you needed) gains if you can go down the stack and replace those wrong assumptions.
charliesome 12y ago
> The whole reason why the "event driven IO", callback mess, etc. is a thing is because of the costs of native OS threads. Nope. The whole reason why event driven IO is so popular is because of all the FUD that has been spread about the 'costs' of native threads. Native threads are cheap as hell on modern systems. Programming in an event driven style may be more natural for some problems, but for the vast majority of cases, native threads and blocking I/O is superior.
- m0th87 12y ago
  Then how do you explain the fall of apache, and rise of nginx?
  - charliesome 12y ago
    Pop culture?
    - read 12y ago
      No, better design. "A-patch-y" was a collection of patches.
      - charliesome 12y ago
        Like most open source software, no? Apache 2.4 is a pretty solid web server. So is nginx. They both have their ups and downs, but unless you have highly specialised needs, either will do the job.
        dllthomas 12y ago
        Like most software, period, past a certain age (and possibly even unqualified).