<

Kenneth Lundin

Head of the Erlang/OTP Team at Ericsson

Kenneth Lundin has been working with SW development since the late 70s. As a curiosity it can be mentioned that Kenneth was one of the pioneers in the use of C++ at Ericsson. He joined the Erlang/OTP project in it's early stages 1996 and has been working both with application components and the run-time system since then. Has been a technical leader and manager for the OTP team since 1998.

Past Activities

Kenneth Lundin / Lukas Larsson
Code BEAM V America
10 Mar 2021
10.20 - 11.00

Ask me anything about OTP

Short update from the OTP Team and then you will be able to ask them any question you like about their work.

Kenneth Lundin / Lukas Larsson
Code BEAM V Europe
19 May 2021
15.20 - 15.50

Ask me anything about OTP

Short update from the OTP Team and then you will be able to ask them any question you like about their work.

Kenneth Lundin
Code BEAM STO V
10 Sep 2020
13.55 - 14.10

An update from the OTP team

Kenneth will give updates on what the OTP team has done in the last few months, what are the projects they're working on, and what's going on on the research side.

Kenneth Lundin / Ingela Anderton Andin / Lukas Larsson
Code BEAM STO V
10 Sep 2020
16.45 - 17.25

Ask me anything about OTP Team

Open meeting with OTP Team. Unmute yourself and ask the guest any question about his work you like. 

Kenneth Lundin
Code BEAM V
29 May 2020
13.00 - 13.15

An update from the OTP team

Kenneth will give updates on what the OTP team has done in the last few months, what are the projects they're working on, and what's going on on the research side.

Hans Elias B. Josephsen / Maxim Kharchenko / Kresten Krab Thorup / Kenneth Lundin / Brian Cardarella
Code BEAM STO V
11 Sep 2020
16.55 - 17.40

Panel Discussion on Erlang Virtual Machines

Whilst the BEAM is the predominant virtual machine used in the Erlang Ecosystem, effort has been put into alternative implementations addressing alternative problems ranging from low powered embedded hardware, paravirtualized implementations, compilation to Web Assembly and ports which run on the JVM. In this panel discussion, we will meet the creators, maintainers and researchers of the BEAM, the LING Erlang on Xen VM, the Lumen WASM implementation and Erjang, running Erlang and Elixir on the JVM. The goal is to compare and contrast these implementations whilst understanding the aspirations, visions, challenges and achievements.   


 

Kenneth Lundin
Code BEAM Lite Virtual
03 Apr 2020
15.35 - 16.00

An update from the OTP team

Kenneth will give updates on what the OTP team has done in the last few months, what are the projects they're working on, and what's going on on the research side.

Kenneth Lundin
Code BEAM SF
06 Mar 2020
09.50 - 10.05

OTP Team update

Updates on what the OTP team has done in the last few months, what are the projects they're working on, and what's going on on the research side.

Kenneth Lundin
Code BEAM STO 2019
16 May 2019
10.00 - 10.15

OTP Team update

Kenneth will give updates on what the OTP team has done in the last few months, what are the projects they're working on, and what's going on on the research side.

Kenneth Lundin
Code BEAM STO 2018
01 Jun 2018
09.50 - 10.05

OTP team update

An update from the OTP team.

Kenneth Lundin
Code BEAM STO 2018
31 May 2018
12.25 - 12.50

Logger a new API for logging

The main goal with "logger" is to standardise an API for logging, allowing the application implementer to use this API without making any assumptions about the logging backend that will be used in the final system. That is, we want to remove the dependency, between applications and logging facility. The main goal is not to remove the need for good logging applications like Lager, but to lift the decision about logging from the low level application implementer to the high level system architect. This will also make it easier to combine applications from different providers - since the same API is always used. Thus, individual applications don't need a dependency to a logging backend such as Lager. That dependency is decided on system level instead.

We want a built-in logging feature which is "good" by default, but which can be customized and extended if needed.

The talk will tell you how it works and explain the design decisions.