Skip to content
Linux Research

Linux Research

Where EmbeddedOS meets Linux: shared tooling, comparisons, and the cases where Linux is the right answer.

Nothing published yet

What will appear here

Nothing filed under this area yet. Comparative work against Linux is planned but not published, and publishing a comparison before the measurements exist would be the wrong order.

What has been published

About Linux Research

What this page is for

This page is where the Foundation will publish its comparative and related research on Linux, from the perspective of a real-time operating system project. That may sound like an odd thing to study: the EmbeddedOS platform is not Linux, does not claim to be Linux, and is not competing with Linux in the spaces where Linux is strong. The point of studying it is to understand exactly where those spaces begin and end.

Nothing is filed here yet. Comparative work against Linux is planned but not published, and that is deliberate: publishing a comparison before the measurements exist would be the wrong order, and we are not going to do it.

Why a real-time OS project studies Linux

The embedded world is not divided into projects that use Linux and projects that do not; it is full of engineers who move between the two every day, of toolchains that speak to both, and of hardware where the device tree, the driver knowledge and the debug tooling were built around the Linux ecosystem. Understanding Linux is practical: it tells us where the Foundation can reuse existing knowledge — device trees, protocol implementations, hardware bring-up experience — and where the platform has to go its own way.

Equally important is knowing where Linux is the right answer. A general-purpose operating system with virtual memory, a full network stack and a huge driver base is the correct choice for a large class of embedded products. The Foundation's position is straightforward: if your problem is served well by Linux, use Linux. Our research programme exists to investigate the problems the commercial market under-serves — determinism, auditability, behaviour under tight resource constraints — and that work is sharper when it is measured against the real alternative rather than a straw man.

What comparative work will cover

When comparative work is published here, it will cover the dimensions that matter to the platform's users: scheduling latency under load, memory footprint of the running system, and determinism of behaviour — worst-case timing, not just average. These will be measured on stated hardware, with the configuration and method described in full, so that anyone can reproduce the numbers or dispute them.

What will not appear here is asserted comparison: claims about Linux that are not backed by measurements taken under the same conditions. If a claim cannot be checked, it will not be published. That rule applies in both directions — the platform's own numbers get the same treatment.

The honesty principle

The ordering matters. Measurements come first, then the comparison, then the publication. This is not caution for its own sake; it is because a comparison published without measurements is marketing, and marketing dressed up as research poisons the well for everyone. Engineers who have been burned by a vendor benchmark stop trusting all benchmarks, including the honest ones.

This page will stay empty until the measurements exist. An empty page is more honest than a filled one built on assertions, and the empty state is the point: it signals that we have not done the work yet, rather than pretending we have.

Related existing work

Two nearby categories already carry related work. The Benchmarks page publishes measurement results from the platform's own test runs, with the methods described, and the Technical Reports category documents subsystem designs that future comparisons will draw on. When Linux comparison work begins, it will build on both: the benchmark harness and the published subsystem write-ups.

Readers looking for the Foundation's current published research should look at the Publications and Technical Reports pages, which are where finished work appears.

Proposing a comparison topic

If you have a comparison you would like to see made — a specific latency question, a footprint question on particular hardware, a determinism claim you want tested — the Foundation is interested in hearing it. Well-posed comparison questions from people building real systems are exactly the ones worth measuring.

Write to contact@embeddedos.org with the question, the hardware it applies to, and why the answer matters for your use case. Not every proposal will be taken on, but every proposal will be read, and the ones that get taken on will be measured before they are published.