Project started to run Erlang on bare metal
In this technical retrospective (2013), @bandris shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Web 2.0 Genesis (2007–2013)
COMMUNITY SCORE ★ 52 points
TOTAL DISCUSSIONS 47 comments
Don't announce your project until you at least have something going. The empty repo at https://github.com/kerlnel/kerlnel ? That should at least have enough code in it to boot something, even if it's just a "hello world!" that doesn't have anything to do with Erlang. Getting a build system in place and developing some sort of contribution guidelines are also important.
There are major advantages to keeping your grand projects in stealth mode for a while. For one, it's good to wait until you have instructions for even the dumbest ADD teenager to compile and run the thing, or else you'll have to deal with a flood of endless terrible questions. For another, it doesn't exactly inspire confidence to come out and say, "Hey, we want to run Erlang on bare metal, we have README.md, please contribute!"
I fully acknowledge that the creators intended to wait longer and that bandris may have just come across an interesting looking Github repo, but even that proves a point: Your repo should be private until you have something to show. When Linus announced Linux, he already had code running in userspace, with bash and gcc ported!
Edit: I say this having been involved in projects that announced too soon. It's important to establish something concrete first.
Running erlang on bare metal has been a side project of my thesis for a while. I love erlang, and I also love getting close to the hardware, which is perhaps why the Ian Seyler's ReturnInfinity Baremetal-OS has drawn my attention and efforts over the past 8 months or so.
Over this time, my colleague Andrew has been tinkering also, and we seem to have a fair degree of overlap in our end goals, hence kERLnel came about.
It is great to see a lot of excellent discussion, both positive and negative. I think all open discussion is useful, even negative comments have a positive affect in their own way. Although I admit I am surprised that kERLnel was even mentioned here, particularly, as we haven't actually dropped any code publicly yet ;-)
There are other exokernel projects out there that may also be suitable also. In fact, not just exokernels, but also a number of {nano|pico|micro} kernels too, however, the idea of hand coded assembler kind of grabbed me completely for some reason.
For me, the project is not about whether X or faster than Y, or anything like that. It is about what I like doing myself and what I find interesting. I think its great for some many people to comment and have different views, particularly different views to myself - this makes the world a better place!
Cheers,
Darren
Okay, I understand developers can spend their time doing whatever they want. Nobody can (or even should) tell other people how they're going to spend their spare time.
But... wouldn't the effort be better spent improving the existing interpreter? The vague description makes it sound like they're trying to run Erlang without an OS "getting in the way". Looking at the language shootout benchmarks [1], it seems like there's still a lot of room for improvement before the OS would be slowing them down. Operating system services aren't causing Erlang to take 3-25x as long as the C code.
[1] http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=hipe&lang2=gcc
It's an exciting idea. Why should server software run on OS's designed to let you play Tetris or compose emails at the same time? It's not like you get all that for free. In theory, specialized apps have a lot to gain from running on more specialized platforms. There ought to be more experimentation in this area.
The name "Kerlnel" is going to be a problem, because it's so awkward to say out loud. You don't want your name to be difficult for people to say; you want them saying it. "Kerlnel" is a clever pun but that doesn't last beyond the first time you read it.
I prefer language agnosticism. Work being done by Nix-OS, a fork of Plan 9, is moving into similar spaces by merely offering you ways of getting direct access to CPU cores for HPC loads: http://code.google.com/p/nix-os/
It also has the benefit of having actually existing code right now.