12 ms·

Olin – Defining a new operating primitive for event-driven services

106 points by ngaut 8y ago

totallysnowman 8y ago
Reminds me of Akka on JVM.
kuwze 8y ago
I wonder what the networking performance of WebAssembly code run server-side is.
cascom 8y ago
Have you run your name by the people at Olin Corp?
- stochastic_monk 8y ago
  As an aside, there’s an Olin Hall at Johns Hopkins.
  - pavlov 8y ago
    It’s a fairly common Swedish family name, AFAIK.
    - hagbarddenstore 8y ago
      No, it's not. Only 1642 people have Olin as their lastname.
      - pavlov 8y ago
        I’m apparently lucky to know several then.
  - honk 8y ago
    To further the aside, there are many Olin buildings on college campuses, all due to Franklin W. Olin (the founder of the Olin corporation). There is also now an entirely standalone Olin College, which is the biggest shared name with this project in my opinion.
- xena 8y ago
  Author of the post here, I wasn't aware of the name conflict. The name is a reference to a book. OLIN (the One Language Intelligent Network) was their global internet that was able to just run programs without having to have specialized hardware. The "one language" in this case would be WebAssembly.
  - cascom 8y ago
    Sorry - wasn’t trying come off as persnickety - but have seen large public companies be rather defensive/litigious around their brand/trademarks etc.
- cbrozefsky 8y ago
  Did they, Olin Corp, ask Olin Shivers before using that name?
akavel 8y ago
As for "everything is a file", IIUC Plan9 explored this area extensively, and the community of fans is still alive, so I believe good insights from real world experience could be gathered at this early design stage by talking with Plan9 people and maybe revieving their manuals. Especially asking them for feedback.
wemdyjreichert 8y ago
Looks like it could be a very good replacement (or addition) to node.
_wmd 8y ago
I admire experimentation, so below comments should preferably be considered constructive.. > I want the binary modules any user of Olin would upload today to be still working, untouched, in 5 years, assuming its dependencies outside of the module still work There are only 3 program formats that enjoyed anywhere like that kind of longevity - PE, Linux ELF, and Jar, all with significant money behind them. Of these, only PE has managed anything like ABI and dependency compatibility across more than 10 years, and that's because of explicitly obsessive compatibility concerns baked into the culture of the company behind it. The nearest best example to PE is Linux Intel ELF, where despite explicit efforts, and where glibc which nearly-almost-if-you-squint manages long term ABI stability, and the kernel which nearly-almost-if-you-squint manages long term compatibility with glibc, you can run a terminal program compiled at the start of the millennium if you boot with the right kernel command line options, so long as you also run it with an ancient buggy libc, and that program has no other system dependencies. Coming from Python land, I can say categorically that any attempt to maintain feverishly accurate compatibility for a rich set of interfaces across a community is almost a pointless effort, the options always degrade to running ancient buggy deps, or updated deps with broken interfaces. The Linux kernel barely manages it despite a strict policy, and they break it occasionally due to security concerns. Downstream community projects follow the whim of whoever is contributing code on that particular day, and their motivations are rarely if ever "compatibility". That is not to say a community effort couldn't manage >10 year compatibility, but that such concerns must be a foremost priority (rather than a cute goal) if there is even a dying chance of the attempt succeeding in the long term. It seems better that the inevitability of incompatibility is honestly accepted and designed for rather than hoping things will just work out. --- > The core idea is that everything is a file, to the point that the file descriptor and file handle array are the only real bits of persistent state for the process Again an admirable goal, but this is Stockholm syndrome in its purest form, and learning completely the wrong lessons from UNIX land. Files are a shit abstraction, but ignoring those, streams even moreso. Very few elements of a modern application even at the lowest tiers lend themselves well to being expressed as a serialized bytestream. The minimum primitive (and happy to share many references to support this) should be something like messages and ports. Streams can be expressed as messages, but the converse is not true without application-specific protocol scaffolding, of which there are a thousand examples on every modern UNIX system as a consequence of UNIX picking streams. --- > When a dagger process is opened, the following files are open: Sequentially numbered transparent handles are a mistake, as are predefined resources, they allow code to make incorrect assumptions that are difficult to manage over the life of a system. You say that glibc should be built on these APIs, yet one of the principal restrictions glibc suffers from is its inability to open long-lived file handles that might conflict with program assumptions -- assumptions often make implicitly without any conscious thought on the part of the programmer. Incremental numbering SUCKS. A few years back Linux even considered adding a brand new fd namespace just so glibc could safely open files, all because of predictable numbered handles with assumed semantics that did not exist. Try to learn from NT and elsewhere here -- the user receives an opaque word, no predefined words exist, and an interface is provided to grant access to any standard resources without introducing global state. --- > open, close, read, write, sync But I thought everything is a file.. why do we need these? Why can't we express these as files too? Due to incorrect lessons above, in a real world system this list will inevitably grow to multiple times its original size. What does sync mean on a socket? How do I eject a DVD drive? How does an application read the system time? By opening some "time://" and reading a serialized time representation? Good luck with nanosecond resolution when microseconds are already lost on scaffolding and maybe parsing some ASCII format timestamp, and so a "one time only" specialized time() call appears. 10 years later and you have hundreds of entries just like /usr/share/man/man2 on a typical UNIX, probably alongside something like ioctl(). But of course this time will be different --- > the open call (defined later), a file URL is specified instead of a file name. This allows for Dagger to natively offer programs using it quick access to common services like HTTP, logging or pretty much anything else. The open call prototype as defined is totally unusable for any kind of network application. There is no room for setting any kind of meaningful options outside a single bitfield, and so already if I wanted to make any kind of custom HTTP request, the supplied interface is useless and I must link a module with a real client built on top of the tcp:// handler. There seems to be no long term sense whatsoever in baking a handful of protocols into the "filesystem" interface, especially not with these APIs. --- > I’d like to add the following handlers in the future: I see they have thought of time:// already! By discarding one of the few remaining uniformities of the UNIX file API - the namespace it exports. It already looks like we're coping with a bad base abstraction by shoving everything we need into magic strings. What happens if I only read 2 bytes from time://? Do I get pieces of the last sampled timestamp because some internal buffering now exists, or do i get half the old timestamp half the new one, or do I continually get the first 2 bytes of unrelated timestamps, or perhaps we simply return an error because the buffer wasn't big enough? It's almost like even a timestamp doesn't really fit the stream-of-bytes file abstraction. --- Very happy to see all these new WebAssembly efforts, but this one's present design fails to learn any lesson from our past suffering.
Serow225 8y ago
Good luck and keep updating with progress! How does your goals mesh with the ideas behind Pony (ponylang.org)?
- Serow225 8y ago
  Also, I know you put the fact that the 'everything is a file' approach is an intended-to-fail spike in the post multiple times, but psychologically people are going to get stuck on it and bikeshed. Sometimes that's enough to kill interest in a project, despite how great the underlying intentions are. Humans ¯\_(ツ)_/¯
- xena 8y ago
  Probably in similar ways, however this is a different paradigm almost. Pony continues the same operating paradigm whereas I'm advocating for burning down society and basically starting over.
kardianos 8y ago
I think fuchsia has it correct: everything is an interface (not a file) that must be injected into the child process. https://fuchsia.googlesource.com/zircon/+/HEAD/docs/fidl/index.md https://fuchsia.googlesource.com/zircon/+/HEAD/docs/fidl/ind... But maybe I'm missing something critical here.
- ofrzeta 8y ago
  What's an "interface"? Obviously "file" is also just an abstraction but it has familiar semantics (read, write etc). From cursory reading it seems that an interface is just a specification for (remote) procedure calls. Also reminds me of microkernel IDLs https://www.gnu.org/software/hurd/idl.html https://www.gnu.org/software/hurd/idl.html
- jacksmith21006 8y ago
  There is a number of things think Fuchsia or Zircon more specifically have correct. Couple of big ones is first using a micro kernel. We really need this at this point for granularity in a MP setting so cache will be hot. So a driver can be pinned to a processor so working with cache instead of going to memory. Then with the ability for a thread to sleep based on a montitor/MWAIT on a specific processor. This way you can basically create a pipeline that is super fast and uses memory to communicate. The other really smart thing was how drivers are using a Vdso and therefore mapped into all process address space. Then the obvious is using a memory capability approach which removes a lot of marshaling that usually has to happen by the kernel. There is going to be a lot of interesting ways to leverage Zircon.
Someone 8y ago
”Each Dagger module can only handle one data type. This is intentional. This forces users to make a separate handler for each type of data they want to handle.” Don’t count on that. What you’ll get instead is a handler that defines a data type containing some enum field that changes what the rest of the data type means, or, worse, a data type named “script” containing a command and its arguments. The latter could give you a separate DSL for every module without any guarantee of consistency between them (just as Unix doesn’t agree about how to control verbosity, how to specify an output file, etc) Also, think about how you’ll want to control modules. If you intend to shut them down, query their health, etc. using a handler, that doesn’t leave room for a handler that does the real work.
- adrianratnapala 8y ago
  > Also, think about how you’ll want to control modules. If you intend to shut them down, query their health, etc. One way around this (which might be useful even if there are multiple handlers per module) is to have explicit layers to the onion. That is, make the health checking stuff etc, belong to an outer layer that is different from where the application exposes it's API. The layers can still "grammar" (i.e. message protocol), but they are separate endpoints. I suspect (but do not know) that this lets the event protocol evolve more independently of the management framework. Which fits in with the OPs noble goal of keeping version 0 minimal. (In fact I think she wants to ignore what I called the "management framework" entirely).
  - xena 8y ago
    > That is, make the health checking stuff etc, belong to an outer layer that is different from where the application exposes it's API. Yep. Ideally people would write handlers to handle both the health checking and the downtime response, but that largely boils down to implementation details.

106 points by ngaut 8y ago

totallysnowman 8y ago

Reminds me of Akka on JVM.

kuwze 8y ago

I wonder what the networking performance of WebAssembly code run server-side is.

cascom 8y ago

Have you run your name by the people at Olin Corp?

stochastic_monk 8y ago
As an aside, there’s an Olin Hall at Johns Hopkins.
- pavlov 8y ago
  It’s a fairly common Swedish family name, AFAIK.
  - hagbarddenstore 8y ago
    No, it's not. Only 1642 people have Olin as their lastname.
    - pavlov 8y ago
      I’m apparently lucky to know several then.
- honk 8y ago
  To further the aside, there are many Olin buildings on college campuses, all due to Franklin W. Olin (the founder of the Olin corporation). There is also now an entirely standalone Olin College, which is the biggest shared name with this project in my opinion.
xena 8y ago
Author of the post here, I wasn't aware of the name conflict. The name is a reference to a book. OLIN (the One Language Intelligent Network) was their global internet that was able to just run programs without having to have specialized hardware. The "one language" in this case would be WebAssembly.
- cascom 8y ago
  Sorry - wasn’t trying come off as persnickety - but have seen large public companies be rather defensive/litigious around their brand/trademarks etc.
cbrozefsky 8y ago
Did they, Olin Corp, ask Olin Shivers before using that name?

akavel 8y ago

As for "everything is a file", IIUC Plan9 explored this area extensively, and the community of fans is still alive, so I believe good insights from real world experience could be gathered at this early design stage by talking with Plan9 people and maybe revieving their manuals. Especially asking them for feedback.

wemdyjreichert 8y ago

Looks like it could be a very good replacement (or addition) to node.

_wmd 8y ago

I admire experimentation, so below comments should preferably be considered constructive.. > I want the binary modules any user of Olin would upload today to be still working, untouched, in 5 years, assuming its dependencies outside of the module still work There are only 3 program formats that enjoyed anywhere like that kind of longevity - PE, Linux ELF, and Jar, all with significant money behind them. Of these, only PE has managed anything like ABI and dependency compatibility across more than 10 years, and that's because of explicitly obsessive compatibility concerns baked into the culture of the company behind it. The nearest best example to PE is Linux Intel ELF, where despite explicit efforts, and where glibc which nearly-almost-if-you-squint manages long term ABI stability, and the kernel which nearly-almost-if-you-squint manages long term compatibility with glibc, you can run a terminal program compiled at the start of the millennium if you boot with the right kernel command line options, so long as you also run it with an ancient buggy libc, and that program has no other system dependencies. Coming from Python land, I can say categorically that any attempt to maintain feverishly accurate compatibility for a rich set of interfaces across a community is almost a pointless effort, the options always degrade to running ancient buggy deps, or updated deps with broken interfaces. The Linux kernel barely manages it despite a strict policy, and they break it occasionally due to security concerns. Downstream community projects follow the whim of whoever is contributing code on that particular day, and their motivations are rarely if ever "compatibility". That is not to say a community effort couldn't manage >10 year compatibility, but that such concerns must be a foremost priority (rather than a cute goal) if there is even a dying chance of the attempt succeeding in the long term. It seems better that the inevitability of incompatibility is honestly accepted and designed for rather than hoping things will just work out. --- > The core idea is that everything is a file, to the point that the file descriptor and file handle array are the only real bits of persistent state for the process Again an admirable goal, but this is Stockholm syndrome in its purest form, and learning completely the wrong lessons from UNIX land. Files are a shit abstraction, but ignoring those, streams even moreso. Very few elements of a modern application even at the lowest tiers lend themselves well to being expressed as a serialized bytestream. The minimum primitive (and happy to share many references to support this) should be something like messages and ports. Streams can be expressed as messages, but the converse is not true without application-specific protocol scaffolding, of which there are a thousand examples on every modern UNIX system as a consequence of UNIX picking streams. --- > When a dagger process is opened, the following files are open: Sequentially numbered transparent handles are a mistake, as are predefined resources, they allow code to make incorrect assumptions that are difficult to manage over the life of a system. You say that glibc should be built on these APIs, yet one of the principal restrictions glibc suffers from is its inability to open long-lived file handles that might conflict with program assumptions -- assumptions often make implicitly without any conscious thought on the part of the programmer. Incremental numbering SUCKS. A few years back Linux even considered adding a brand new fd namespace just so glibc could safely open files, all because of predictable numbered handles with assumed semantics that did not exist. Try to learn from NT and elsewhere here -- the user receives an opaque word, no predefined words exist, and an interface is provided to grant access to any standard resources without introducing global state. --- > open, close, read, write, sync But I thought everything is a file.. why do we need these? Why can't we express these as files too? Due to incorrect lessons above, in a real world system this list will inevitably grow to multiple times its original size. What does sync mean on a socket? How do I eject a DVD drive? How does an application read the system time? By opening some "time://" and reading a serialized time representation? Good luck with nanosecond resolution when microseconds are already lost on scaffolding and maybe parsing some ASCII format timestamp, and so a "one time only" specialized time() call appears. 10 years later and you have hundreds of entries just like /usr/share/man/man2 on a typical UNIX, probably alongside something like ioctl(). But of course this time will be different --- > the open call (defined later), a file URL is specified instead of a file name. This allows for Dagger to natively offer programs using it quick access to common services like HTTP, logging or pretty much anything else. The open call prototype as defined is totally unusable for any kind of network application. There is no room for setting any kind of meaningful options outside a single bitfield, and so already if I wanted to make any kind of custom HTTP request, the supplied interface is useless and I must link a module with a real client built on top of the tcp:// handler. There seems to be no long term sense whatsoever in baking a handful of protocols into the "filesystem" interface, especially not with these APIs. --- > I’d like to add the following handlers in the future: I see they have thought of time:// already! By discarding one of the few remaining uniformities of the UNIX file API - the namespace it exports. It already looks like we're coping with a bad base abstraction by shoving everything we need into magic strings. What happens if I only read 2 bytes from time://? Do I get pieces of the last sampled timestamp because some internal buffering now exists, or do i get half the old timestamp half the new one, or do I continually get the first 2 bytes of unrelated timestamps, or perhaps we simply return an error because the buffer wasn't big enough? It's almost like even a timestamp doesn't really fit the stream-of-bytes file abstraction. --- Very happy to see all these new WebAssembly efforts, but this one's present design fails to learn any lesson from our past suffering.

Serow225 8y ago

Good luck and keep updating with progress! How does your goals mesh with the ideas behind Pony (ponylang.org)?

Serow225 8y ago
Also, I know you put the fact that the 'everything is a file' approach is an intended-to-fail spike in the post multiple times, but psychologically people are going to get stuck on it and bikeshed. Sometimes that's enough to kill interest in a project, despite how great the underlying intentions are. Humans ¯\_(ツ)_/¯
xena 8y ago
Probably in similar ways, however this is a different paradigm almost. Pony continues the same operating paradigm whereas I'm advocating for burning down society and basically starting over.

kardianos 8y ago

I think fuchsia has it correct: everything is an interface (not a file) that must be injected into the child process. https://fuchsia.googlesource.com/zircon/+/HEAD/docs/fidl/index.md https://fuchsia.googlesource.com/zircon/+/HEAD/docs/fidl/ind... But maybe I'm missing something critical here.

ofrzeta 8y ago
What's an "interface"? Obviously "file" is also just an abstraction but it has familiar semantics (read, write etc). From cursory reading it seems that an interface is just a specification for (remote) procedure calls. Also reminds me of microkernel IDLs https://www.gnu.org/software/hurd/idl.html https://www.gnu.org/software/hurd/idl.html
jacksmith21006 8y ago
There is a number of things think Fuchsia or Zircon more specifically have correct. Couple of big ones is first using a micro kernel. We really need this at this point for granularity in a MP setting so cache will be hot. So a driver can be pinned to a processor so working with cache instead of going to memory. Then with the ability for a thread to sleep based on a montitor/MWAIT on a specific processor. This way you can basically create a pipeline that is super fast and uses memory to communicate. The other really smart thing was how drivers are using a Vdso and therefore mapped into all process address space. Then the obvious is using a memory capability approach which removes a lot of marshaling that usually has to happen by the kernel. There is going to be a lot of interesting ways to leverage Zircon.

Someone 8y ago

”Each Dagger module can only handle one data type. This is intentional. This forces users to make a separate handler for each type of data they want to handle.” Don’t count on that. What you’ll get instead is a handler that defines a data type containing some enum field that changes what the rest of the data type means, or, worse, a data type named “script” containing a command and its arguments. The latter could give you a separate DSL for every module without any guarantee of consistency between them (just as Unix doesn’t agree about how to control verbosity, how to specify an output file, etc) Also, think about how you’ll want to control modules. If you intend to shut them down, query their health, etc. using a handler, that doesn’t leave room for a handler that does the real work.

adrianratnapala 8y ago
> Also, think about how you’ll want to control modules. If you intend to shut them down, query their health, etc. One way around this (which might be useful even if there are multiple handlers per module) is to have explicit layers to the onion. That is, make the health checking stuff etc, belong to an outer layer that is different from where the application exposes it's API. The layers can still "grammar" (i.e. message protocol), but they are separate endpoints. I suspect (but do not know) that this lets the event protocol evolve more independently of the management framework. Which fits in with the OPs noble goal of keeping version 0 minimal. (In fact I think she wants to ignore what I called the "management framework" entirely).
- xena 8y ago
  > That is, make the health checking stuff etc, belong to an outer layer that is different from where the application exposes it's API. Yep. Ideally people would write handlers to handle both the health checking and the downtime response, but that largely boils down to implementation details.