7 ms·

Nerves: buildroot linux and Erlang, with an Erlang "init"

193 points by kevlar1818 10y ago

emson 10y ago
Nerves looks like a really exciting project. IoT is only going to get bigger and as a result there are a number of problems to overcome. Things like how to do remote deployment and version handling to the devices. Also with Nerves you can write the device "client" code and backend server code all in the same language. Anyway checkout the Elixir Conference talk on Nerves: https://www.youtube.com/watch?v=118-g0ODfgg&feature=youtu.be https://www.youtube.com/watch?v=118-g0ODfgg&feature=youtu.be If anyone wants a 30% off coupon to an Elixir course, here you go: https://www.udemy.com/elixir-for-beginners/?couponCode=Save30%25 https://www.udemy.com/elixir-for-beginners/?couponCode=Save3...
- indatawetrust 10y ago
  alternative -> https://elixirschool.com/ https://elixirschool.com/
  - emson 10y ago
    Great course by the way +1
joezydeco 10y ago
Nerves is young, but already powers rock-solid shipping industrial products! Wow. Okay. Can you show us?
- kevlar1818 10y ago
  Check out Garth Hitchens' talk about 2:40 in: https://www.youtube.com/watch?v=poWoCWDLxRU https://www.youtube.com/watch?v=poWoCWDLxRU
  - di4na 10y ago
    To be complete, iirc it is that product that is in production. The elixirconf EU talk that is show above also talk about some production stuff. http://www.rosepointnav.com/commercial-radar-interface/ http://www.rosepointnav.com/commercial-radar-interface/
Cyph0n 10y ago
I think the term embedded systems is slightly abused in this context. From what I understand, Nerves essentially creates a minimal Linux firmware image that boots into your Elixir app. That is way too huge and bulky for most embedded systems i.e. microcontrollers and FPGAs. Furthermore, I don't think that the overhead of the firmware and VM can actually handle the level of realtime control required in the embedded space. Since Nerves seems to be targeting the IoT space, why not just say "Elixir for IoT"? Nonetheless, it looks like an awesome project. Elixir is a really interesting language running on a mature platform, and has come quite a long way in a very short amount of time. Edit: from the ElixirDaze talk [1], Gareth says that the image is around 18 MB in size. [1]: https://www.youtube.com/watch?v=poWoCWDLxRU&t=9m05s https://www.youtube.com/watch?v=poWoCWDLxRU&t=9m05s
- vvanders 10y ago
  Yeah, embedded to me is something in the PIC/AVR/Cortex M0|3 space. Still awesome and exciting stuff.
- joezydeco 10y ago
  I'm an old embedded dog and I struggle with this a lot recently. I get that an RPi or Beaglebone or any large SoC architecture qualifies as an embedded system in the sense of "this board is running a drone/driverless car/CNC machine/etc". But, at least to me, these are highly miniaturized desktop systems now. There's disk. There's advanced I/O (HDMI, LVDS, 802.11, Ethernet, SATA, PCIe!). There's a full operating system on there. You could put one inside a 1U case and pretend it's a server. Not that this is a bad thing. SoCs are awesome and I personally have a half-dozen projects cooking with iMX6s and other cool parts in this domain. But I think we need to find a way, especially in the IoT era, to quantify a small device node architecture versus a Linux-desktop-on-a-board. I already see Microsoft abusing this by putting Win10 on an RPi and calling it an IoT architecture.
  - di4na 10y ago
    As someone that has played in the embedded world too, i struggled with that last year. But let's be honest. Except if you have really strong constraint about power consumption and form factor, most of these small stuff are far easier to work with, perform probably better (because yes your software has bugs) and have so so so much better tooling. Because the embedded world has a big tooling problem. I still hope to have some Rust on lower level to push it into the XXIst century. And the nerves project is made by people that come from the embedded world. They completely know their limits and do not try to push it everywhere.
deleted 10y ago
[deleted]
thenewwazoo 10y ago
I don't think I'd agree that Nerves is "firmware". Nerves is, at its root, buildroot linux and Erlang, with an Erlang "init". At least the last time I looked, the "hardware interface" was just file I/O operations in sysfs. Which is cool and all, but that's just a process in Linux userland reading and writing files. I spent quite some time trying to get tighter integration between a kernel module and the Erlang runtime. Because of the way Erlang works, one can't select(2)/poll(2) file descriptors in a useful way, which makes sysfs interrupt files less useful. I wrote a very simple Erlang node[0] to send messages when select/poll returns. It works okay, but the jitter is very high. Peer Strizinger wrote something called Grisp[1] which uses the POSIX interface to RTEMS[2] to run Erlang without a canonical OS. RTEMS is still ultimately an embedded kernel, but it keeps you much closer to the metal than Linux. Unfortunately, Peer hasn't/won't release his code despite my pleas. Most promisingly, there's Cloudozer's Erlang on Xen port to the Raspberry Pi[3]. This is a clean-sheet Erlang VM implementation that actually runs bare-metal (no POSIX!). The code is definitely experimental and I don't have the time to try to retarget it to my preferred platforms, but it's exciting anyway. It's definitely what I would call "firmware" in Erlang. Anyway, Nerves is cool, but it's (u-boot + Linux + epmd + BEAM). [0] https://github.com/thenewwazoo/erl_poc/blob/master/c_src/node.c https://github.com/thenewwazoo/erl_poc/blob/master/c_src/nod... [1] http://www.grisp.org http://www.grisp.org [2] http://www.rtems.org http://www.rtems.org [3] https://github.com/cloudozer/ling/tree/raspberry-pi https://github.com/cloudozer/ling/tree/raspberry-pi
- wyager 10y ago
  If you have many erlang actors waiting on IO, does the runtime automatically epoll all those file descriptors? Most things in Haskell work this way. If you wanted to get epoll behaviour without actually calling epoll yourself, you could spawn a ton of processes to wait on different sockets or whatever and then just have them write into an STM container when they receive anything. The thread receiving from x million different clients or whatever just keeps reading from the STM container. Of course, at large scale you would probably just use epoll directly and save on the few hundred bytes per thread overhead.
  - thenewwazoo 10y ago
deleted 10y ago
[deleted]

193 points by kevlar1818 10y ago

emson 10y ago

Nerves looks like a really exciting project. IoT is only going to get bigger and as a result there are a number of problems to overcome. Things like how to do remote deployment and version handling to the devices. Also with Nerves you can write the device "client" code and backend server code all in the same language. Anyway checkout the Elixir Conference talk on Nerves: https://www.youtube.com/watch?v=118-g0ODfgg&feature=youtu.be https://www.youtube.com/watch?v=118-g0ODfgg&feature=youtu.be If anyone wants a 30% off coupon to an Elixir course, here you go: https://www.udemy.com/elixir-for-beginners/?couponCode=Save30%25 https://www.udemy.com/elixir-for-beginners/?couponCode=Save3...

indatawetrust 10y ago
alternative -> https://elixirschool.com/ https://elixirschool.com/
- emson 10y ago
  Great course by the way +1

joezydeco 10y ago

Nerves is young, but already powers rock-solid shipping industrial products! Wow. Okay. Can you show us?

kevlar1818 10y ago
Check out Garth Hitchens' talk about 2:40 in: https://www.youtube.com/watch?v=poWoCWDLxRU https://www.youtube.com/watch?v=poWoCWDLxRU
- di4na 10y ago
  To be complete, iirc it is that product that is in production. The elixirconf EU talk that is show above also talk about some production stuff. http://www.rosepointnav.com/commercial-radar-interface/ http://www.rosepointnav.com/commercial-radar-interface/

Cyph0n 10y ago

I think the term embedded systems is slightly abused in this context. From what I understand, Nerves essentially creates a minimal Linux firmware image that boots into your Elixir app. That is way too huge and bulky for most embedded systems i.e. microcontrollers and FPGAs. Furthermore, I don't think that the overhead of the firmware and VM can actually handle the level of realtime control required in the embedded space. Since Nerves seems to be targeting the IoT space, why not just say "Elixir for IoT"? Nonetheless, it looks like an awesome project. Elixir is a really interesting language running on a mature platform, and has come quite a long way in a very short amount of time. Edit: from the ElixirDaze talk [1], Gareth says that the image is around 18 MB in size. [1]: https://www.youtube.com/watch?v=poWoCWDLxRU&t=9m05s https://www.youtube.com/watch?v=poWoCWDLxRU&t=9m05s

vvanders 10y ago
Yeah, embedded to me is something in the PIC/AVR/Cortex M0|3 space. Still awesome and exciting stuff.
joezydeco 10y ago
I'm an old embedded dog and I struggle with this a lot recently. I get that an RPi or Beaglebone or any large SoC architecture qualifies as an embedded system in the sense of "this board is running a drone/driverless car/CNC machine/etc". But, at least to me, these are highly miniaturized desktop systems now. There's disk. There's advanced I/O (HDMI, LVDS, 802.11, Ethernet, SATA, PCIe!). There's a full operating system on there. You could put one inside a 1U case and pretend it's a server. Not that this is a bad thing. SoCs are awesome and I personally have a half-dozen projects cooking with iMX6s and other cool parts in this domain. But I think we need to find a way, especially in the IoT era, to quantify a small device node architecture versus a Linux-desktop-on-a-board. I already see Microsoft abusing this by putting Win10 on an RPi and calling it an IoT architecture.
- di4na 10y ago
  As someone that has played in the embedded world too, i struggled with that last year. But let's be honest. Except if you have really strong constraint about power consumption and form factor, most of these small stuff are far easier to work with, perform probably better (because yes your software has bugs) and have so so so much better tooling. Because the embedded world has a big tooling problem. I still hope to have some Rust on lower level to push it into the XXIst century. And the nerves project is made by people that come from the embedded world. They completely know their limits and do not try to push it everywhere.

deleted 10y ago

[deleted]

thenewwazoo 10y ago

I don't think I'd agree that Nerves is "firmware". Nerves is, at its root, buildroot linux and Erlang, with an Erlang "init". At least the last time I looked, the "hardware interface" was just file I/O operations in sysfs. Which is cool and all, but that's just a process in Linux userland reading and writing files. I spent quite some time trying to get tighter integration between a kernel module and the Erlang runtime. Because of the way Erlang works, one can't select(2)/poll(2) file descriptors in a useful way, which makes sysfs interrupt files less useful. I wrote a very simple Erlang node[0] to send messages when select/poll returns. It works okay, but the jitter is very high. Peer Strizinger wrote something called Grisp[1] which uses the POSIX interface to RTEMS[2] to run Erlang without a canonical OS. RTEMS is still ultimately an embedded kernel, but it keeps you much closer to the metal than Linux. Unfortunately, Peer hasn't/won't release his code despite my pleas. Most promisingly, there's Cloudozer's Erlang on Xen port to the Raspberry Pi[3]. This is a clean-sheet Erlang VM implementation that actually runs bare-metal (no POSIX!). The code is definitely experimental and I don't have the time to try to retarget it to my preferred platforms, but it's exciting anyway. It's definitely what I would call "firmware" in Erlang. Anyway, Nerves is cool, but it's (u-boot + Linux + epmd + BEAM). [0] https://github.com/thenewwazoo/erl_poc/blob/master/c_src/node.c https://github.com/thenewwazoo/erl_poc/blob/master/c_src/nod... [1] http://www.grisp.org http://www.grisp.org [2] http://www.rtems.org http://www.rtems.org [3] https://github.com/cloudozer/ling/tree/raspberry-pi https://github.com/cloudozer/ling/tree/raspberry-pi

wyager 10y ago
If you have many erlang actors waiting on IO, does the runtime automatically epoll all those file descriptors? Most things in Haskell work this way. If you wanted to get epoll behaviour without actually calling epoll yourself, you could spawn a ton of processes to wait on different sockets or whatever and then just have them write into an STM container when they receive anything. The thread receiving from x million different clients or whatever just keeps reading from the STM container. Of course, at large scale you would probably just use epoll directly and save on the few hundred bytes per thread overhead.
- thenewwazoo 10y ago

deleted 10y ago

[deleted]