Version 5 (modified by vnevoa, 9 years ago) (diff)

removed spam links, and formated last sentences.


The whole purpose of creating a new Operating System is to be different from the others. There are many ways to achieve this, but RunningBear is there to try out new concepts. One at a time, it is hoped each difference will turn out as an improvement. The main tasks as seen today follow:


History and backward compatibility are essential. However, in the context of mobile, hackable devices, many concepts inherited from decades of software development are simply superfluous. One of the first aims of RunningBear is to drop support of whatever is not necessary for actual operation. Some of the essential components will also be re-designed, or totally replaced to better suit embedded needs.

A non-exhaustive list of items to re-think or drop altogether reads:

  • filesystem hierarchy
  • virtual consoles
  • terminal emulation
  • the standard C API


First, a design requirement of RunningBear is to provide mobile services. This brings its lot of constraints, from hardware capabilities to user interaction. Finding the best compromise is a priority of RunningBear.

Moreover, with the ever growing pool of hackable devices out there, the best software support may not be found in the same code base. Another requirement of RunningBear is therefore to run equally regardless of the underlying hardware abstraction layer, like the kernel.


Complexity creates insecurity. It is hoped that a cleaner design, and smaller code base will already help with the security of the implementation of the system.

Additionally, RunningBear wants to provide a new solution for a seamless, yet safe way to access resources remotely. They may be private, but belonging to different persons or entities, and possibly with granular permissions. Managing them should no longer be as perilous a process as too often seen today.

Hackable devices are a new step towards secure computing: by knowing better the hardware, software should be easier to write, and implementations easier to assess.


Because being friendly does not mean asking only stupid questions, the system needs to adapt to any crowd. User interaction needs to be consistent with each and every application running. Essential dialogs and settings must be presented first, with the possibility to dig further. This should not assume a given skill level or role, as some developers are only beginning, while some users may have specific needs as well.

This is also not an easy task, but developing and influencing the system should also be accessible to just about anyone. From the build system to the development framework, tasks must be kept simple and equally documented.


It's not just about presenting concepts or ideas. RunningBear is there to deliver. It needs to run, and integrate with existing solutions as well. It needs to bear support to just about any user or system. It will be there. "When you have to kill a man it costs nothing to be polite."

-- Winston Churchill, on formal declarations of war