Linked by David Adams on Wed 14th Jul 2010 21:33 UTC, submitted by iseyler
OSNews, Generic OSes BareMetal is an open source 64-bit OS for x86-64 based computers. It is written in Assembly, and applications can be written in Assembly or C/C++. It's aimed at three target segments (High Performance Computing, Embedded Applications, and Education). It's also designed to be simple, and it's really small. Under 16Kb small. Version 0.4.8 was released recently, which includes updates to the C application library, updated documentation, and better support for SMP. It's good to see some innovation in the startup/hobbyist OS space. We wish them well!
Order by: Score:
Nifty
by Almafeta on Wed 14th Jul 2010 22:01 UTC
Almafeta
Member since:
2007-02-22

I don't think 'innovative' is the right word; that implies new and different, even at the expense of clarity or simplicity. This seems to be more basic and clean, the bare minimum bread and butter an OS needs. Not that it's a knock against the system; simplicity is good.

Poking around their SVN tree, it seems they're missing a few core functions. Well, I've been meaning to poke around with x86-64 assembly anyways...

Edited 2010-07-14 22:07 UTC

Reply Score: 4

v RE: Nifty
by siride on Thu 15th Jul 2010 15:57 UTC in reply to "Nifty"
RE[2]: Nifty
by siride on Thu 15th Jul 2010 16:40 UTC in reply to "RE: Nifty"
siride Member since:
2006-01-02

Wow, mods don't like the truth.

Reply Score: 1

RE[3]: Nifty
by tylerdurden on Thu 15th Jul 2010 18:20 UTC in reply to "RE[2]: Nifty"
tylerdurden Member since:
2009-03-17

Apparently "truth" does not mean what you think it means...

Reply Score: 2

RE[2]: Nifty
by Almafeta on Thu 15th Jul 2010 19:27 UTC in reply to "RE: Nifty"
Almafeta Member since:
2007-02-22

Agree. Nothing innovative about this. Just another underpowered hobby project with no useful goals. Not to say that writing an OS or similar project isn't fun, but it certainly isn't newsworthy.


You may be missing the point. It might not be newsworthy on Jon Q. Public's Random Tech Blog, but this is OSNews. This is what we come here for.

Reply Score: 5

RE[3]: Nifty
by siride on Thu 15th Jul 2010 19:29 UTC in reply to "RE[2]: Nifty"
siride Member since:
2006-01-02

I don't think it's even newsworthy here.

Reply Score: 1

RE[4]: Nifty
by echo.ranger on Thu 15th Jul 2010 20:06 UTC in reply to "RE[3]: Nifty"
echo.ranger Member since:
2007-01-17

I do. I can't remember the last time I saw news about a 64bit assembly-based OS.

Reply Score: 2

RE: Nifty
by vivainio on Thu 15th Jul 2010 18:21 UTC in reply to "Nifty"
vivainio Member since:
2008-12-26

Well, I've been meaning to poke around with x86-64 assembly anyways...


Don't you mean MOVe around?

(drumroll and apologies).

Reply Score: 3

Welcome home again, OSnews! :)
by ebasconp on Thu 15th Jul 2010 01:51 UTC
ebasconp
Member since:
2006-05-09

Welcome home again, OSnews! ;)

This kind of news are what we, your readers, were waiting for ;)

I know, these news are rare these days but I am happy that these research, hobby, alternative OSes still have a place (this place) where they can be introduced and divulged.

Reply Score: 15

v RE: Welcome home again, OSnews! :)
by sc3252 on Thu 15th Jul 2010 08:11 UTC in reply to "Welcome home again, OSnews! :)"
WereCatf Member since:
2006-02-15

I think Osnews is dead,

Hmm, I personally like OSNews. I've been a daily visitor for who knows how long now and I can't say I am disappointed in any way really. One thing I especially like about OSNews is that commenting really works well and there's often interesting discussions here whereas f.ex. Slashdot's comments area tends to be full of useless stuff and flamebaits.

But well, each to their own, I s'pose.

Reply Score: 4

Morgan Member since:
2005-06-29

If you really come here out of habit you'd know why news has been slow the past month: Thom Holwerda is on a sabbatical for school. David Adams is doing a great job in his absence but as most of the daily news came straight from Thom, there has naturally been a visible effect.

Personally I like the pace of things here now; it reminds me of the old days when Eugenia was at the helm. And, as much as I enjoy Thom's articles and sense of humor, it's been refreshing to see all the different points of view in recent submissions.

Reply Score: 2

fatjoe Member since:
2010-01-12

I have no problems with OSnews posting non-OS articles once in a while. I for one would rather read about interesting non-OS stuff than the latest boring release candidate from SUSE or Ubunthu.

I have found OSnews fair and balanced and intelligent while everyone else are selling their souls way too cheap for ad impressions and vendor cash (Eldar and the Engadget crew, I am looking at you).

So whether its about OS or something else, OSnews does a very good job and I am satisfied.

Edited 2010-07-15 18:40 UTC

Reply Score: 1

LLVM?
by Dasher42 on Thu 15th Jul 2010 03:29 UTC
Dasher42
Member since:
2007-04-05

Assembly for x86 may have a stable target, but it just isn't where that kind of tightness is needed. Use the assembly language for LLVM and you can target the architectures in mobile devices - or if you are on a desktop, more readily offload onto the GPU or other resources. Still, who cares? Sounds like these guys are having fun.

Reply Score: 2

Under 16Kb small?
by bousozoku on Thu 15th Jul 2010 03:54 UTC
bousozoku
Member since:
2006-01-23

It's under 2 KB? That is compact, like under 8-bit operating system compact.

Reply Score: 1

RE: Under 16Kb small?
by iseyler on Thu 15th Jul 2010 17:22 UTC in reply to "Under 16Kb small?"
iseyler Member since:
2008-11-15

The Kernel binary (which includes the kernel itself, the CLI, as well as all of the system calls) is 16KiB. In reality it is actually much smaller as the binary is padded out to 16KiB. The compiled binary without padding is 10576 bytes as of 0.4.8

- Ian Seyler @ Return Infinity

Edited 2010-07-15 17:23 UTC

Reply Score: 1

RE[2]: Under 16Kb small?
by Luposian on Fri 16th Jul 2010 02:53 UTC in reply to "RE: Under 16Kb small?"
Luposian Member since:
2005-07-27

The Kernel binary (which includes the kernel itself, the CLI, as well as all of the system calls) is 16KiB. In reality it is actually much smaller as the binary is padded out to 16KiB. The compiled binary without padding is 10576 bytes as of 0.4.8

- Ian Seyler @ Return Infinity


Reminds me of the days of the Atari ST (1986 and later), when the entire OS fit into 192Kbytes of ROM.

If you were to do a 64-bit BareMetal OS version of the Atari ST TOS/GEM, I wonder if you could STILL do it in that amount of space (or less)! I think it might well be VERY possible... and it would be on a 64-bit computer!

You think the Atari ST was fast for it's day? This type of system would blister the surface of the sun, it'd be so fast! :-D

Reply Score: 2

RE[3]: Under 16Kb small?
by Kochise on Fri 16th Jul 2010 08:28 UTC in reply to "RE[2]: Under 16Kb small?"
Kochise Member since:
2006-03-03

Good reading about fitting a complete OS, including GUI, in such a small amount of ROM :

http://www.dadhacker.com/blog/?p=995
http://www.dadhacker.com/blog/?p=1000

Kochise

Reply Score: 1

RE[4]: Under 16Kb small?
by vodoomoth on Sun 18th Jul 2010 21:36 UTC in reply to "RE[3]: Under 16Kb small?"
vodoomoth Member since:
2010-03-30

Thanks for the links. I'm not halfway through the first one yet but I'm loving it.

Reply Score: 1

RE[2]: Under 16Kb small?
by bousozoku on Fri 16th Jul 2010 14:55 UTC in reply to "RE: Under 16Kb small?"
bousozoku Member since:
2006-01-23

The Kernel binary (which includes the kernel itself, the CLI, as well as all of the system calls) is 16KiB. In reality it is actually much smaller as the binary is padded out to 16KiB. The compiled binary without padding is 10576 bytes as of 0.4.8

- Ian Seyler @ Return Infinity


That's 8 times bigger than what was written in the article, but I guess typographical errors have to scream to be heard.

Reply Score: 2

RE[2]: Under 16Kb small?
by AndrewZ on Mon 19th Jul 2010 15:21 UTC in reply to "RE: Under 16Kb small?"
AndrewZ Member since:
2005-11-15

I hereby give you permission to increase the OS size UP TO 1 MB. Anything above that and we will have to take a vote.

Reply Score: 2

FINALLY!!!
by Quake on Thu 15th Jul 2010 05:03 UTC
Quake
Member since:
2005-10-14

Finally! Some OS NEWS! I wish them good luck in their endeavours. And it's interesting to see some people still building OSes using assembly (Compact).

Edited 2010-07-15 05:04 UTC

Reply Score: 2

HPC software stack
by reflect on Thu 15th Jul 2010 06:28 UTC
reflect
Member since:
2007-07-10

So I guess this wouldn't be for any generic HPC clusters, but for when you have a specific application that you have the ability to either port or write from scratch, then.

Would be interesting to hear about implementations later on when they get a little more hw support (like network).

Wonder if MPI and InfiniBand and such things are on the map for the future?

Reply Score: 1

New kid on the block
by vasper on Thu 15th Jul 2010 06:48 UTC
vasper
Member since:
2005-07-22

It is always nice to see a new kid on the block. They are doing another menuetOS (http://www.menuetos.net/) hope they have at least the same success

Reply Score: 2

Message from the author
by iseyler on Thu 15th Jul 2010 07:53 UTC
iseyler
Member since:
2008-11-15

We still have a ways to go but we are getting to something that I think has a lot of promise.

Network support is currently the major thing that is lacking. We plan to have some limited support in v0.5.0 (most likely targeting the Realtek 8139 chipset or similar). BareMetal OS nodes will communicate via raw Ethernet frames. Once network access is complete we can use a real cluster of BareMetal OS machines.

Work on the C library needs to be done as well. Currently it is using custom calls for basic operations but we would like to include all of the ANSI C standard functions (printf, scanf, fopen, etc..).

Maybe in the future BareMetal OS could replace Linux on Pixar's Renderfarm ;)

Thanks,
- Ian Seyler @ Return Infinity

Reply Score: 7

RE: Message from the author
by kjmph on Thu 15th Jul 2010 12:33 UTC in reply to "Message from the author"
kjmph Member since:
2009-07-17

Hi, that's an interesting goal! To run RenderMan, it's mostly C bindings, and the shader language is all in software (REYES algo). That should eliminate huge parts of a full POSIX API. Plus, you wouldn't need proprietary HW drivers, right? You would definitely need networking working for the bytestreams. How are you handling the FS? Just hiding it behind the networking layer? I suppose you could, since the bytestream is god in RenderMan.

Very interesting goal. Good luck! What about more normal MPI/OpenMP type stuff?

Reply Score: 1

RE: Message from the author
by Shannara on Thu 15th Jul 2010 15:53 UTC in reply to "Message from the author"
Shannara Member since:
2005-07-06

Or replace the now dead SkyOS ;)

Reply Score: 1

RE: Message from the author
by TheGZeus on Thu 15th Jul 2010 19:15 UTC in reply to "Message from the author"
TheGZeus Member since:
2010-05-19

Get enough of C that Emacs can be ported to it.
Then any computer since the intro of AMD64 can run a very capable OS. It'll be far huger than the OS (probably take about 16mb, as there'd be no graphics support and a number of other functions stripped), but who cares?
I realise this is no small task, but it's a worthy task, I think.
Emacs is a very capable OS, if you think back to the days when computing was younger, and look at what it can do now. People just expect an OS to do so much more than what makes an OS. The core of Emacs adds a scripting language with regex, text processing, (if available) rudimentary graphics(which are being improved), tiling window management, rudimentary multitasking(you can run multiple processes, but one waits for the next to finish anything it's doing, like an old Mac)...
Seriously, with this and Emacs, I'd be at home. Integrate the compiler/debugger with it and you've got a full development environment.

It's a Herculean task, but it's not as insane as one might think. the C portion's relatively small, and once the lisp interpreter/byte-compiler are available, the rest is just not including features that BareMetal doesn't support(yet).

Reply Score: 1

RE[2]: Message from the author
by vivainio on Thu 15th Jul 2010 20:14 UTC in reply to "RE: Message from the author"
vivainio Member since:
2008-12-26


Emacs is a very capable OS, if you think back to the days when computing was younger, and look at what it can do now.


Right, emacs actually got anti-aliasing recently:

http://psung.blogspot.com/2008/03/emacs-in-ubuntu-hardy-now-has-ant...

At this pace, it's prone to become sentient soon.

Reply Score: 3

RE[3]: Message from the author
by TheGZeus on Fri 16th Jul 2010 05:11 UTC in reply to "RE[2]: Message from the author"
TheGZeus Member since:
2010-05-19


At this pace, it's prone to become sentient soon.

Heh. It's not very advanced when compared to the systems in which it runs (at least in the flashy parts), it is a pretty impressive achievement when you compare it to DOS or a BASIC prompt.

Reply Score: 1

RE: Message from the author
by ebasconp on Thu 15th Jul 2010 19:52 UTC in reply to "Message from the author"
ebasconp Member since:
2006-05-09

Catching stars with the feet on the ground!!!

That's the way you can make the world turn.

Congratulations! ;)

Edited 2010-07-15 19:53 UTC

Reply Score: 2

RE: Message from the author
by boushkash on Sat 17th Jul 2010 16:38 UTC in reply to "Message from the author"
boushkash Member since:
2010-07-14

please don't bother with the ansi C functions such as printf and the rest of that stuff. keep the fresh new calls and make this a modern project not burdened by the ancient crap.

i think a great feature would be to make this project based on UTF-32/UCS-4 unicode.

good luck and thanks for sharing this wonderful work.

Reply Score: 1

RE[2]: Message from the author
by ebasconp on Sun 18th Jul 2010 04:41 UTC in reply to "RE: Message from the author"
ebasconp Member since:
2006-05-09

please don't bother with the ansi C functions such as printf and the rest of that stuff. keep the fresh new calls and make this a modern project not burdened by the ancient crap.


What are you saying man?

ANSI C functions are the base of everything... everything ends doing a "malloc", a "free" or a "memmov"...

Because you live in the virtual machine on top of virtual machines era, creating a lot of garbage that needs to be garbage collected, living in a world full of framework and classes, it does not mean that all the "ancient crap" is still feeding such virtual world.

Reply Score: 2

RE[3]: Message from the author
by boushkash on Mon 19th Jul 2010 14:02 UTC in reply to "RE[2]: Message from the author"
boushkash Member since:
2010-07-14

of course u need to have calls to allocate and free memory or do string manipulation but it can be implemented in a different way other than the old runtime-library way. for example, i have written countless programs for WinNT using the native ntdll.dll API for all these functions and i can tell u that it makes a whole lot more sense than the runtime-library. another example is qnx.

C!=RTL

all i am saying is that being bound by these rules such as runtime-library being a must will render your OS a replica of the old ones.

even the names of the RTL functions make zero sense.

good luck with your efforts.

Reply Score: 1

Comment by bloodline
by bloodline on Thu 15th Jul 2010 11:18 UTC
bloodline
Member since:
2008-07-28

I like OSNews too... No complaints from me.

On topic... Any chance of an Obj-C runtime? ;)

Reply Score: 1

RE: Comment by bloodline
by iseyler on Thu 15th Jul 2010 20:39 UTC in reply to "Comment by bloodline"
iseyler Member since:
2008-11-15

We haven't tested C++ or Objective-C yet, but I see no reason why it wouldn't work. For compiling C applications we support GCC and LLVM/Clang.

- Ian Seyler @ Return Infinity

Reply Score: 1

RE: Comment by bloodline
by vivainio on Fri 16th Jul 2010 05:23 UTC in reply to "Comment by bloodline"
vivainio Member since:
2008-12-26


On topic... Any chance of an Obj-C runtime? ;)


Why on earth would one need to support objc on a system like this?

C, C++ and a minimal scripting environment (elua?) would seem to make more sense.

Reply Score: 2

RE[2]: Comment by bloodline
by dylansmrjones on Sat 17th Jul 2010 01:54 UTC in reply to "RE: Comment by bloodline"
dylansmrjones Member since:
2005-10-02

Objective C makes at least as much sense as C++.

A possible reason to support objc would be to write (or port) applications in Objective C. That's all the need you need.

Reply Score: 2

RE[3]: Comment by bloodline
by vivainio on Sat 17th Jul 2010 04:34 UTC in reply to "RE[2]: Comment by bloodline"
vivainio Member since:
2008-12-26

Objective C makes at least as much sense as C++.

A possible reason to support objc would be to write (or port) applications in Objective C. That's all the need you need.


There just isn't any objective c code worth porting, whereas there is a ton of worthwhile c++ code around.

Reply Score: 2

RE[4]: Comment by bloodline
by dylansmrjones on Sat 17th Jul 2010 06:39 UTC in reply to "RE[3]: Comment by bloodline"
dylansmrjones Member since:
2005-10-02

I beg to differ.

Reply Score: 2

RE[5]: Comment by bloodline
by vivainio on Sat 17th Jul 2010 07:08 UTC in reply to "RE[4]: Comment by bloodline"
vivainio Member since:
2008-12-26

I beg to differ.


So you know of some portworthy softare written in objc? Is this gnustep or some iFart application?

Reply Score: 2

Why x86 assembly?
by rom508 on Thu 15th Jul 2010 12:56 UTC
rom508
Member since:
2007-04-20

I know from personal experience (SPARC v9) that assembly programming can be cool, but it has severe limitations:

1. Not suitable for large and complex programs. Every hobby project starts small, so coding everything in assembly may seem like a good idea, but in several years time when the codebase grows and you start adding many more features, it will become difficult to make big changes/additions.

2. Not portable. You wouldn't be able to port it to a different architecture. I know x86 architecture has lived for many years, but sooner or later it will be superseded by something else. Even advances in the same architecture 32-bit x86 to 64-bit x86 require big changes to assembly code.

I'm pretty sure you all know these things, I just don't understand why commit everything to one specific architecture. Operating systems can grow to be very complex and the hardware changes/evolves pretty quickly.

Reply Score: 1

RE: Why x86 assembly?
by tylerdurden on Thu 15th Jul 2010 18:34 UTC in reply to "Why x86 assembly?"
tylerdurden Member since:
2009-03-17

It is their project, so they can do whatever they want. If the goal is embedded or high performance applications, it makes sense to make the OS as simple and bare as possible.

Furthermore any of those "insights" you related are common wisdom items which can be derived without having written a single line of assembly code. Also, if you have programmed in assembly you should know that a lot of code such as interrupt servicing is very architecture-specific so it is not really that portable (regardless of whether you write it in a high level language or not). So writing an OS in C, for example, does not make it automatically portable.

Lastly, betting on X86-64 is a very safe bet, as we can make a clear case that such architecture, unlike SPARC, is not going away anytime soon.

Reply Score: 3

RE: Why x86 assembly?
by iseyler on Thu 15th Jul 2010 20:36 UTC in reply to "Why x86 assembly?"
iseyler Member since:
2008-11-15

BareMetal OS will always be lean and mean. Allowing it to get "large and complex" would defeat our goals. The OS provides just the basics (keyboard input, screen output, disk (and eventually Ethernet) access). BareMetal OS will never replace the OS on your desktop/notebook because that is not what it is being designed for. We want something that gets out of the way when an application is running.

As for portability we don't think the x86 architecture will be replaced any time soon. Also the great thing about x86 is that it is everywhere. While high-level compilers do a good job at compiling code we prefer being in full control of what opcodes the CPU is executing (and in what order). Does GCC or LLVM/Clang optimize for "branchless" code if it can?

- Ian Seyler @ Return Infinity

Reply Score: 1

RE[2]: Why x86 assembly?
by Valhalla on Fri 16th Jul 2010 13:37 UTC in reply to "RE: Why x86 assembly?"
Valhalla Member since:
2006-01-24


As for portability we don't think the x86 architecture will be replaced any time soon. Also the great thing about x86 is that it is everywhere.

And good to see you going for the x86-64 cpu generation. Those extra registers must sure be handy.

While high-level compilers do a good job at compiling code we prefer being in full control of what opcodes the CPU is executing (and in what order).

Heh, I can certainly understand the preference of 'full control' since it's also part of my own nature. That said, compiler optimization has matured alot these past years and although they will never offer the same level of control (and likely not the same level of optimization as that of an assembly guru) I personally find it 'close enough' for the majority of cases. Newer optimization techniques like PGO (profile guided optimization) offers you branch prediction, efficient instruction cache usage, function reordering, loop unrolling etc in an automated way. Again, a great assembly programmer can beat this I'm sure, but it will require a great level of skill and more time. Please don't think I'm putting your efforts down, I admire your willingness and skill to write an os in pure assembly and having programmed alot in x86 assembly during my time I find it very inspirational. Today, most of the places I see assembly code is in BIOS'es, really low level OS stuff and special optimizations such as video encoding/decoding. Seeing it applied on a whole OS project is very impressive.


Does GCC or LLVM/Clang optimize for "branchless" code if it can?

Yes, GCC will transform conditional jumps into branchless equivalents wherever applicable, and I'm certain the same is true for LLVM although I'm too lazy to look it up (hey, it's summer).

Reply Score: 2

RE[2]: Why x86 assembly?
by DeepThought on Sat 17th Jul 2010 05:07 UTC in reply to "RE: Why x86 assembly?"
DeepThought Member since:
2010-07-17

BareMetal OS will always be lean and mean.
- Ian Seyler @ Return Infinity


But at least multi-threading should be added. Or did I oversee it in the sources ?

Actually, IMHO, something that calls itself an OS today needs to support multitasking and or multi-threading.

Anyway, good to see there are more freaks around doing pure assembly :-)

Reply Score: 1

RE[3]: Why x86 assembly?
by iseyler on Sun 18th Jul 2010 08:19 UTC in reply to "RE[2]: Why x86 assembly?"
iseyler Member since:
2008-11-15

Multi-threading is supported but not in the way that other Operating Systems use it.

BareMetal OS uses a Process Queue. An application can throw as many "work loads" as it wants into the Process Queue and any available CPU Cores will begin to work on them.

There is a presentation on the topic here:
http://vimeo.com/13423853">BareMetal

Reply Score: 1

RE[2]: Why x86 assembly?
by f0dder on Sat 17th Jul 2010 13:13 UTC in reply to "RE: Why x86 assembly?"
f0dder Member since:
2009-08-05

While high-level compilers do a good job at compiling code we prefer being in full control of what opcodes the CPU is executing (and in what order).
Good luck controlling the order instructions are executed in... how many years has it been since out-of-order execution was introduced to CPUs? ;)

(yeah, I'm nit-picking).

Reply Score: 1

RE[3]: Why x86 assembly?
by DeepThought on Sat 17th Jul 2010 16:59 UTC in reply to "RE[2]: Why x86 assembly?"
DeepThought Member since:
2010-07-17

Good luck controlling the order instructions are executed in... how many years has it been since out-of-order execution was introduced to CPUs? ;)

out-of-order execution is no problem for assembler programming. Why should it be ? There are always synchronization points like return from subroutine or memory barriers. Only if you need to be sure some code has been executed before another is started, you have to insert such sync-point by yourself.

Reply Score: 1

Use it in VM's
by Bodger on Thu 15th Jul 2010 15:44 UTC
Bodger
Member since:
2007-03-22

I could see this or other low footprint OS's used for specialty applications deployed on VM's. Use many VM's, each one with a different application.

Reply Score: 1

RE: Use it in VM's
by Flatland_Spider on Fri 16th Jul 2010 13:11 UTC in reply to "Use it in VM's"
Flatland_Spider Member since:
2006-09-01

That's a project someone needs to take up. Lately, I've been wondering why I need the rest of the junk when I only what to run BIND in a VM.

Reply Score: 1

Nice
by happe on Fri 16th Jul 2010 11:48 UTC
happe
Member since:
2009-06-09

This really is a step in the right direction for HPC. The overhead of memory management doesn't really make sense for a node that is dedicated to one application. If it dies, the job manager can just reset the node!

I'm wondering if it will be a problem that applications have full control. they can push a lot of pakages to the network, which could be damaging for the rest of the system.

A solution might be to use LLVM byte code, or similar, for applications. Then verify that they only use the network through a controlled interface. The job manager could do this and perform the final compilation.

Reply Score: 1

OSNews about the OS and what happens on it
by pcunite on Fri 16th Jul 2010 15:00 UTC
pcunite
Member since:
2008-08-26

I like OSNews because they talk about applications and generally everything that affects an OS, be it local or remote.

Reply Score: 1

Hmm
by Wodenhelm on Fri 16th Jul 2010 20:00 UTC
Wodenhelm
Member since:
2010-07-16

BareMetal + WINE = ???

Reply Score: 1

Add secure systems?
by ThunderBug on Fri 16th Jul 2010 23:30 UTC
ThunderBug
Member since:
2006-03-05

The site suggests BareMetal targets HPC, embedded systems, and education. To that list I suggest adding secure systems.

Reply Score: 1

Eh
by Wodenhelm on Sun 18th Jul 2010 14:48 UTC
Wodenhelm
Member since:
2010-07-16

Too bloated.

Reply Score: 1