
Nerves: buildroot linux and Erlang, with an Erlang "init" - kevlar1818
http://nerves-project.org/
======
thenewwazoo
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/nod...](https://github.com/thenewwazoo/erl_poc/blob/master/c_src/node.c)

[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)

~~~
dang
> _I don 't think I'd agree that Nerves is "firmware". Nerves is, at its root,
> buildroot linux and Erlang, with an Erlang "init"._

Ok, we'll use that as a provisional title, since people here have been
objecting to all the previous titles. If anyone can suggest a better (i.e.
more accurate and neutral) one, we'll change it again. (Normally it isn't so
hard to look at a project page and find a suitable description, but I couldn't
do that here—this one is surprisingly on the other side of the breathless
marketing divide. Et tu, Erlang?)

~~~
gleb
The web page's original title is perfectly good. The new one is like an early
investor is seeing AirBnb early on and saying "Oh, it's just like VRBO but
with higher fees." True but not helpful, and not likely to result in a correct
investment decision.

    
    
      * it's Elixir not Erlang
      * to the people who would use the project, it is "firmware"
    

Nerves is really cool. And the cool part is that it's becoming possible to do
what firmware programmers used to, but using higher level more productive
languages/OS.

------
Cyph0n
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)

~~~
joezydeco
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
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.

~~~
Cyph0n
Not only power consumption, but also for realtime applications, like those
used in industrial and automotive control systems.

In such scenarios, the overhead and unpredictability of the OS scheduler is
unacceptable. When you want to say isolate a fault _exactly_ 100us after it
takes place, you can't have the OS executing that task at some different delay
in a nondeterministic fashion.

~~~
di4na
well in that case you enter a completely different world. Hard RealTime system
are not really only "embedded". They also exists for bigger things.

It is just a really different set of way to think. And a really hard one i may
add.

~~~
jacobush
Hard realtime can also be with seconds latency, to further complicate things.

------
emson
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=Save3...](https://www.udemy.com/elixir-for-
beginners/?couponCode=Save30%25)

~~~
indatawetrust
alternative -> [https://elixirschool.com/](https://elixirschool.com/)

~~~
emson
Great course by the way +1

------
joezydeco
_Nerves is young, but already powers rock-solid shipping industrial products!_

Wow. Okay. Can you show us?

~~~
kevlar1818
Check out Garth Hitchens' talk about 2:40 in:
[https://www.youtube.com/watch?v=poWoCWDLxRU](https://www.youtube.com/watch?v=poWoCWDLxRU)

~~~
di4na
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/)

