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.
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.
Glad I'm not the only one who immediately balked at the name. I just spent like the last two minutes repeating it in a trance to see if it would become any easier to say. Nope, sounds like I'm trying to say "kernel" while balancing a grape on the back of my tongue. It's a physically uncomfortable word to say, which is an impressive linguistic construction!
As far as I can tell, it's a vague concept, and two "authors" who haven't authored anything asking people to help without really explaining any of the goals? Help with what, exactly?
I fully support making more languages embeddable, but this project doesn't seem to be real. I hope there's more to it than what's listed on their site right now!
Wouldn't it be more feasible to make the Erlang VM run on Baremetal OS[1], and contribute to it? Thousands of hours will be spent on kernel development and hardware issues for what is mostly duplicated effort.
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!
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.
That repo is extremely out of date. The lsub.org guys (http://lsub.org/ls/nix.html) decided they'd prefer to roll their own "code review" system, and the nix-os repo was essentially abandoned. Apparently they've recently decided to stop using their own code review thing, and just make changes directly in their local tree while taking emailed diffs from everyone else, so there's that.
Edit: oh, and Erik Quanstrom has started shipping the Nix kernel with his own set of patches in the 9atom distribution, if you can handle the hour+ download time for his ISO. There are some other nice improvements in 9atom, too.
Not to be confused with "NixOS", no dash, a Linux distro based on the Nix package manager. Sheesh, how many annoying names can we get into one thread? http://nixos.org/nixos/
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.
We are completely surrounded by embedded devices, and their numbers are growing exponentially. Everything has a computer in it. You might be shocked to know the power that's in some of these devices... your cable box might be a quad-core 1.2GHz ARM.
Currently, your common options for embedded software are:
* bare-metal with C, C++, or ASM
* load a full OS (i.e. Linux) and run an interpreter to get access to higher-level languages
There are a lot of domains where the problem being solved doesn't require particularly high hardware resources, but requires quite advanced software design. Implementing something like a modern Blu-Ray player's UI and high-bandwidth/low-latency AV in C is rough. You spend a LOT up front on software development costs, and pay more in the maintenance phase. Alternatively, you can save on development and maintenance by running an OS and using high-level languages and existing libraries... but then your board price per unit skyrockets because of the extra processing power, RAM, and flash that you need to support the OS and interpreters.
Access to a modern programming language at a "bare-metal" environment is the holy grain for embedded. It would change the world.
Unfortunately, it has always been practically impossible. And likely still is.
Erlang is as much of a platform as it is a (pretty peculiar) language and its functionality does overlaps with the operating system, for example thread management (and in Erlang you tend to have thousands of threads as far as I understand) and things like being able to boot up Erlang on ten computers and have them behave like one big Erlang instance. In other words, considering what Erlang does, it seems plausible this is a very reasonable thing to try, I don't think this has to do with "operating system services" in the windowish sense of the word "service", it's more about conflicting approaches to same problems between the OS and Erlang.
It would be interesting to see benchmarks to indicate if such a project would give a useful gain in performance, compared to say, just running Erlang on its own, via of the many available OS kernels.
I have been following this project, and it makes so much more sense to me.
As another poster mentioned, going all the way down to the bare metal does not make sense to me.
Or maybe I have lived through too many hardware upfrades to not want to worry about whether the APP will run if we upgrade the RAID controller or something.
I was just going to post the Wikipedia link (http://en.wikipedia.org/wiki/Exokernel), but Mirage looks pretty cool. I've liked the idea of an exokernel since I heard of them. Thanks.
[+] [-] jff|13 years ago|reply
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.
[+] [-] gruseom|13 years ago|reply
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.
[+] [-] newobj|13 years ago|reply
[+] [-] halvsjur|13 years ago|reply
Guess there could be some gains, but a lot? Enough to bother with?
What about hardware support?
[+] [-] pi18n|13 years ago|reply
[+] [-] tzs|13 years ago|reply
It sounds pretty good out loud if you say it while doing a Stephen Hawking impression.
[+] [-] dllthomas|13 years ago|reply
[+] [-] TheAmazingIdiot|13 years ago|reply
[deleted]
[+] [-] mrmekon|13 years ago|reply
I fully support making more languages embeddable, but this project doesn't seem to be real. I hope there's more to it than what's listed on their site right now!
[+] [-] ricardobeat|13 years ago|reply
[1] http://www.returninfinity.com/baremetal.html
[+] [-] darrenmackay|13 years ago|reply
Cheers,
Darren
[+] [-] darrenmackay|13 years ago|reply
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
[+] [-] neverm0re|13 years ago|reply
It also has the benefit of having actually existing code right now.
[+] [-] jff|13 years ago|reply
Edit: oh, and Erik Quanstrom has started shipping the Nix kernel with his own set of patches in the 9atom distribution, if you can handle the hour+ download time for his ISO. There are some other nice improvements in 9atom, too.
[+] [-] andrewflnr|13 years ago|reply
[+] [-] jlarocco|13 years ago|reply
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?te...
[+] [-] mrmekon|13 years ago|reply
Currently, your common options for embedded software are:
* bare-metal with C, C++, or ASM
* load a full OS (i.e. Linux) and run an interpreter to get access to higher-level languages
There are a lot of domains where the problem being solved doesn't require particularly high hardware resources, but requires quite advanced software design. Implementing something like a modern Blu-Ray player's UI and high-bandwidth/low-latency AV in C is rough. You spend a LOT up front on software development costs, and pay more in the maintenance phase. Alternatively, you can save on development and maintenance by running an OS and using high-level languages and existing libraries... but then your board price per unit skyrockets because of the extra processing power, RAM, and flash that you need to support the OS and interpreters.
Access to a modern programming language at a "bare-metal" environment is the holy grain for embedded. It would change the world.
Unfortunately, it has always been practically impossible. And likely still is.
[+] [-] stiff|13 years ago|reply
[+] [-] rdtsc|13 years ago|reply
Room for improvement to do what? Compute n-body simulations. Permutations, or searching a FASTA file, spectral norm? You can't be serious.
The only one of consequence maybe the thread ring Erlang comes 3rd then after Go and Haskell.
[+] [-] quasque|13 years ago|reply
[+] [-] thirsteh|13 years ago|reply
[+] [-] tapiwa|13 years ago|reply
As another poster mentioned, going all the way down to the bare metal does not make sense to me.
Or maybe I have lived through too many hardware upfrades to not want to worry about whether the APP will run if we upgrade the RAID controller or something.
[+] [-] abraininavat|13 years ago|reply
EDIT: To add some context, would it be like http://www.openmirage.org/ ?
[+] [-] wmf|13 years ago|reply
[+] [-] andrewflnr|13 years ago|reply
[+] [-] SparrowOS|13 years ago|reply
[deleted]