Jehanne

Thought in progress

2019-01-06T00:00:00+00:00

2018 has gone and from my point of view, it has been a great year.

I’ve learned the hard way a lot of valuable lessons that broke some fundamental assumptions of mine, freeing me from several misconceptions and giving me a priviledged point of view upon important matters.

First I discovered, with much surprise after years of cynism, that Free Software and Open Source software are completely different things.

Everything started when I accidentally discovered that Harvey had completely removed my name from their codebase without removing my contributions.
This was a blatant violation of the GNU GPL (version 2) from a member of Software Freedom Conservancy.
And the commits that removed my name were all from a very experienced Google engineer.

Since I can’t sue both Google and SFC (they do no Evil, after all!), I had to surrender when they squashed some of my changes into large commits (that included work from several authors) during a huge git rebase that pretended to remove my work (but have left several of my contributions there).

The problem is very practical to me, since I reused my changes to the Harvey codebase in Jehanne, and I’m afraid that a Google’s lawyer could one day decide that I copied Harvey because of the changes I authored myself.

All this was a valuable revelation. It taught me that:

we can’t trust Google’s employees when they contribute to OSS.
we can’t trust SFC either, as Karen Sandler explicitly excluded such kind of issues when Harvey joined SFC.
we can’t trust GNU licenses, as it’s violated by SFC members without any issue.
talking about FOSS or FLOSS ultimately marginalize hackers.

Beyond Jehanne

Reflecting on Google, I realized that

their lobbying against AI regulation (or for permissive regulations, which is the same) is one of the most dangerous attack to worldwide freedom right now
they own Mozilla that don’t give a shit about people privacy or security

In fact the Russian Government is exploiting one of the attacks that I described to Mozilla and Chromium but the bug report is still “RESOLVED INVALID” because “this is the Web functioning as designed”

I mean: the Russian Governement building a database of security researcher and privacy aware people that could detect a JavaScript attack… is how Google (and thus Mozilla) want the Web to work.

The worse vulnerability here is people’s trust in IT.
Current IT is broken beyond repair.

The only mitigation is Culture

In 2018 I’ve spent a lot of my free time informing people about the risks of these attacks. As a consequence, I was banned by a couple of online communities, Lobste.rs and Tildes.net.

Much better feedbacks came from my talks about AI.

But ultimately, I realized that our only hope are kids and I started an course of Informatics for the elementary school of my eldest daughter.

I suggest you do to the same: don’t let your children to be used through software.
We need a generation of hackers that can break the world that bad people have built.

Yes but… what about Jehanne?

All these facts made me realize that existing copylefts cannot serve neither hackers’ curiosity nor people’s Freedom, so I studied Copyright regulations to mitigate the issues I saw with them. The result is the Hacking License that is going to replace AGPLv3 as my copyleft of choice.

Writing the Hacking License took roughly 6 months.
It’s designed to protect users from SaaS’s abuses by granting them the ultimate right to self-host the application they use. This right will be a great incentive to fair playing for SaaS providers using my File Protocol. Also, the Hacking License is designed to turn users to hackers: IMO, this is the only way Free Software can win against big corporations.

This is very practical and very important.
The Web is a half done, badly broken and insecure distributed operating system.
Using services as a software substitute will be the normal working mode with Jehanne: if people cannot trust the provider as they cannot trust Web site now there’s no way to make my project a reality.

The File Protocol

My few remaining free hours were spent into the design of the File Protocol (aka FP) and the study of its integration in Jehanne as a replacement of 9P2000.

At a first glance all you need to change to introduce an alternative file protocol in a Plan 9 kernel is devmnt (in Jehanne it was already renamed as dev9p) but after a deeper analysis, it turns out that I have to modify the Dev structure because FP doesn’t have a Walk equivalent.

Changing Dev has a huge impact on the whole kernel, and it’s just a part of the issue because I also want to move to a new mount table.

So ultimately, the Jehanne kernel is badly broken right now.

As a consequence you didn’t saw much work ongoing on Jehanne, and to be honest… I wouldn’t hold my breath.

The File Protocol is the reason Jehanne exists: I want to build the infrastructure that will let people hack a free and safe distributed system, so I have to carefully address both the technical and the legal issues to ensure it won’t end in a user-hostile hell like HTTP and browsers.

Because Jehanne is Free Software, not Open Source.

Simplicity awakes

2018-11-15T00:00:00+00:00

Preemptive multitasking is now more than 50 years old, initially introduced in PDP-6 Monitor and MULTICS in 1964. Instead of relying on processes to cooperatively release the CPU to the kernel, they registered timer interrupt handlers to move control back to kernel code.

Nevertheless, processes were still able to yield control of the CPU to the kernel during a time-slice by calling any system call.

System calls are often distinguished into blocking or non-blocking depending on the probability that the kernel will return the control to the calling process’ code before the next tick.

In real world, non-blocking syscalls might block the process and blocking syscalls might not block at all: it all depends on implementation details and on the state of the system at run-time.

Classical examples of blocking system calls are

sleep that should block for a certain number of seconds
wait that could block until a children process exit
read that would block until a chunk of data is available
write that would block on a pipe without enough space for the new data

CPU control and time

Sleep is a very interesting syscall because its whole point is just to yield the CPU for a while, so that other processes can use it. Its main use case is to poll for a certain resource to become available without subtracting computing power that could be used to produce such resource: it’s a tool for cooperative multitasking in a OS supporting preemptive multitasking.

Other blocking system calls (like wait, read and write) depend on external events to return control to the process. Soon programmers realized that an external event might never occur and designed ways to mitigate the risks.

Unix introduced signals and services like alarm and setitimer to give back control to the calling process on certain events or after a certain time.

Later, new syscalls like select, poll, kqueue or sigtimedwait were introduced with a timeout parameter from the very beginning.

Plan 9 from Bell Labs

Compared to the 400 system calls of Linux, Plan 9’s API is rather simpler but it still supports a bit of each time-control styles:

sleep suspends the calling process for a number of milliseconds specified by the argument.
alarm causes an alarm note to be sent to the invoking process after a number of milliseconds.
tsemacquire only waits for a number of milliseconds to acquire a semaphore.

By design, Plan 9 provides only a very limited support for non-blocking I/O (through alarm) and no support for I/O multiplexing:

if a program needs to wait for several resources, it usually calls rfork
if a program want to serve several concurrent clients, it usually expose a 9P2000 filesystem

Furthermore, with libthread, Plan 9 provides an implementation of Hoare’s Communicating Sequential Processes in which dedicated (preemptively scheduled) processes are used to issue any blocking system calls and several cooperatively-scheduled threads sharing memory in a single process are used to access global state.

The Curse of Frankenstein

The complex interactions between the different ways to handle timeouts in Unix (and, to a lesser extent, in Plan 9) are direct effects of its design philosophy.

As explained by Richard P. Gabriel in his famous essay, “Unix and C are the ultimate computer viruses”.

Worse is better, isn’t it?

Worse-is-Better is a model of software design and implementation which has the following characteristics (in approximately descending order of importance):

Simplicity
The design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
Correctness
The design should be correct in all observable aspects, but it is slightly better to be simple than correct.
Consistency
The design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either complexity or inconsistency in the implementation.
Completeness
The design must cover as many important situations as is practical. All reasonably expected cases should be covered.

Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

In a way the so called “New Jersey style” was a rush for a minimum viable product able to minimize the time-to-market and to gain the first mover advantage.

Quoting Gabriel

Both early Unix and C compilers had simple structures, are easy to port, require few machine resources to run, and provide about 50%-80% of what you want from an operating system and programming language.

[…]

It is important to remember that the initial virus has to be basically good. If so, the viral spread is assured as long as it is portable. Once the virus has spread, there will be pressure to improve it, possibly by increasing its functionality closer to 90%, but users have already been conditioned to accept worse than the right thing.

So far so good.

Early Unix, like Plan 9, didn’t aim at perfection, but at serving the majority of users’ need well enough.

But is “enough”, enough?

The Unix philosophy spread beyond Unix, and it became the common wisdom of software engineering so far.

For early Unix and Plan 9, enough is enough. Look at 9front to see a modern system that follows this philosophy consistently.

There is a catch, however.
Plan 9 (like early Unix), is a system evolving as a whole. This is particularly visible in the 9front repository. The whole system evolves together, all programs are modified consistently, answering to the ever changing needs of its users.

Plan 9 is one application of computers. An operating system split into several executables, but still one thing.

So in its asymptotic path toward completeness, all pieces progress together. When they provides 90% of required functionality, it really means 90%. Or 95%. Or 97%. Or 99%.

But what if we split the system into independent components and assign them to different teams following the same philosophy?

This is what happened to mainstream operating systems.

With their widespread adoption, the variety of people needs couldn’t be served anymore by a single company. Thus good APIs and development tools provided a strategic advantage to build ecosystems of applications that, by running on a certain OS, would have expanded its market share.

Unix was particularly well suited for this kind of race for application developers.

However this process had a significant but overlooked drawback: the running operating system lose its unity, its coherence. The operating system became a collection of variegate software, developed by a variety of different teams, each with their own goals and taste and set of best practices.

More pieces, more cracks!

Take one application that works correctly 99% of times, and you will be fine 99% of times.

But what if you have 10 applications each working correctly 99% of times?

The probability that they work correctly together at each computer clock is (99%)^10. That is: their composition will do what you expect roughly 90% of times.

With such assumption, the probability of a system behaving correctly goes down pretty quickly approaching the formula

p(n) = (0.99)ⁿ

How many programs are you running right now? :-D

This is the curse of Frankenstein: more pieces, more cracks.

Simplex Sigillum Veri

Plan 9 from Bell Labs followed the New Jersey style from the very beginning and still does so in most if it’s incarnations.

But what about Jehanne, from Meucci’s laboratory?

Turns out the design of Jehanne doesn’t follow the New Jersey style. I have no rush. Yet Jehanne doesn’t follow the MIT/Stanford style either.

To follow Gabriel’s scheme, we could say that Jehanne is based upon

Simplicity
The design must be simple. Few simple, easy to learn and orthogonal abstractions should be able to describe any use case conceivable.
If the implementation is difficult, the design is not simple enough.
Correctness
The design should be correct in all observable aspects.
Incorrectness is not allowed.
Consistency
The design must not be inconsistent. Any inconsistency reveals a design problem: either a missing abstraction or abstractions that are not orthogonal enough.
Composability
Completeness should naturally emerge as a (desirable) side effect.
As such, it cannot be a goal: the design must cover as few important situations as practical and let the user compose the abstractions provided to build what he needs.

I call this set of principles simplex sigillum veri.

It’s deeply inspired by the works of other Italian hackers, such as Antonio Meucci, Pier Giorgio Perotto, Guglielmo Marconi, Renzo Piano and Leonardo da Vinci.

The Awake system call

Plan 9 supports 39 system calls (not counting obsolete ones). Since some system calls can be expressed in term of the others, in Jehanne I moved the duplicates in userspace.

The idea is that a smaller kernel surface makes it easier to get it right and simple in the long run.

During such clean up, I realized that sleep, alarm and tsemacquire were somehow “ugly”: I supposed that they were mixing orthogonal issues and looked for the missing abstraction they were hiding.

This is how the awake syscall was born:

long awake(long milliseconds);

Awake is the complement of sleep: it books a new time slice in the future. It’s a fundamental building block that can be used to implement other services in user space, like sleep, alarm and tsemacquire.

It interrupts a blocking syscall after a certain number of milliseconds. On failure it returns 0. On success it returns a negative long that can be used as an identifier to release the booked time slice.

On wakeup, no note or signal is sent to the process, the process’ error string left unchanged: the blocking syscall simply returns to the process with a ~0ULL result.

A process can register how many wakeups it want (within a global system cap) and each wake up will have a chance to interrupt a system call.

Wakeups are booked in two distinct group that do not interact: normal process execution and note handlers. Such groups are automatically reset respectively on exits and on noted.

In libc, two very simple functions wrap awake to enhance readability.

Awakened tells the calling process whether a certain wakeup already occurred. Forgivewkp tells the kernel to remove a certain wakeup.

With these primitives it’s trivial to move sleep and tsemaquire to libc.

In particular, tsemaquire shows pretty well the simple idiom of awake:

	/* book a time slice in the future */
	long wkup = awake(ms);
	while(blocking_syscall() == -1){
		if(jehanne_awakened(wkup)){
			/* handle syscall timed out */
		}
		/* the syscall has been otherwise interrupted, you can
		 * - try again
		 * - fail with an error
		 * - do whatever fit
		 */
	}
	/* the syscall completed, release the booked time slice... */
	jehanne_forgivewkp(wkup);

	/* ...and enjoy */

(the mindful reader will notice that alarm is still waiting to be moved to user space… the fact is that it’s too boring of a task!)

To be fair, awake was originally designed to interrupt rendezvous only, to enable timeouts support for QLock, RWLock and Rendez in libc.

But from the very beginning it was clear that it could have been generalized and composed with other system calls, to provide other services.

With the advent of libposix, I used awake to implement support for POSIX non-blocking I/O, signals and sigset waiters.

Which in turn enabled the port of newlib and of MirBSD Korn Shell to Jehanne.

All this with more or less 600 lines of code.

Two kernel processes, a timer and a ringer, cooperate through a linked list of wakeups kept in order of expiration that is filled by the system calls. On each tick, if the first element of the registry is expired, the interrupt handler awake the timer, that prepare a collection of expired timers.

Then the ringer start a loop to interrupt the process properly.

These two different processes make it possible to keep processing new wakeups while the ringer is waiting for the process to be in an interruptible state.

Not all blocking system calls can be interrupted though. Create is a notable example of a blocking system call that has been excluded from the interruptible ones, to prevent a timeout to leave an orphan file behind.

Issues and future uses

Awake will be used to implement all timeouts of Jehanne’s system calls.

Even without libposix, it provides a simple mechanism to implement non-blocking I/O, if needed.

And it will be used to implement timeouts in multiplexing I/O too.

Unfortunately, as an interface to the kernel scheduler, awake doesn’t work with user space schedulers that keep control of their own tasks. Right now, this just means that qlockt, rlockt, wlockt and rsleept cannot work when linking libthread. In the long run, it might make slightly more difficult to port virtual machines and programming languages that provide their own scheduler in user space, like Go or Java.

The solution however is already outlined by libthread usage of a custom rendezvous: we will simply override the system call to give control to the desired scheduler.

Mksh on Jehanne

2018-04-16T00:00:00+00:00

A little history about MirBSD’s Korn Shell and Jehanne, kindly hosted by MirBSD.

Jehanne in 2017

2018-01-06T00:00:00+00:00

Another year is gone with Jehanne.

Here is a little report of what has been done (in no particular order):

everybody’s copyrights have been made explicit and hopefully correct
several bugs have been fixed (and probably more introduced)
kernel options management has been simplified
boot assembly has been rewritten
swap support have been removed
MCACHE support for mount has been removed
various improvements have been imported from 9front (MMU management, PCI, AHCI, interruptible locks…) and 9front’s pstree has been ported
the awake system call has been generalized to interrupt several blocking syscalls, even during note handling
tsemacquire has been moved to libc (in less than 15 lines)
no rendezvous can occur at the tag ~0
the names of the procedures provided by the native C library has been prefixed with “jehanne_”, to define a namespace that avoid collisions with other C libraries (so that new programs can use for example both a POSIX C library and the Jehanne’s libc)
the name space of a process you own can be cloned writing “clone” to its /proc/$pid/ns
LibPOSIX has been introduced
RedHat’s newlib has been ported to Jehanne on top of LibPOSIX
MirBSD Korn Shell has been ported to Jehanne on top of newlib

Some of these changes are more heretic than others, but all are designed to make the system simpler and more useful at the same time.

The generalization of awake allows the implementation in userspace of a wide range of features usually found in unix kernels.
For example, LibPOSIX can use it to provide non blocking I/O and to implement sigtimedwait.

The removal of swap and mount(MCACHE) simplifies the kernel and increases security.

MirBSD Korn Shell

Despite the various tests I wrote for newlib, I wanted a real world application to check the quality of LibPOSIX.

I choose mksh for two reasons:

it’s simple and powerful
it’s developed by a great hacker that actively helped me even to understand the weird semantics I had to implement

Thanks Thorsten!

If you want to give it a try, run in rio: vt sys/posixly mksh -l.

(to get rio on boot: cp /arch/rc/lib/startup/terminal /cfg/startup)

New year’s resolutions for 2018

Funny ones:

~~keep stealing from 9front~~ improve hardware support
add O_NONBLOCK support to LibPOSIX (and newlib) on top of the awake system call
draft the new file protocol that will replace both HTTP and 9P2000
move the existing 9P2000 server to this new protocol
create new file servers to read/write at least Linux Ext2 and NTFS with the new protocol

Duties:

write about the awake system call (as promised one year ago)
write ~~what I want to forget~~ about LibPOSIX
write or port a package manager
port GCC and friends on top of newlib/LibPOSIX
turn Jehanne in a self-hosted OS
write documentation and manual
add screenshots to the website
more tests

Under evaluation:

port pkgsrc
port discount
port musl
port ncurses
port vim
port OBNC (and replace Go with Wirth’s Oberon-07)
port… more Free Software

Boring task:

write the equivalent of lib9p for the new file protocol
write an alarm file server on top of the new file protocol and remove alarm from the kernel
fix bugs

Real promises:

more crazy ideas
break the build
sleep

Who guess what will be actually done?

Hacking

2017-01-20T00:00:00+00:00

I’ve just published the Hacking section of the manual.

Hacking Jehanne is simple and funny!

Give it a try!

A year with Jehanne

2017-01-06T00:00:00+00:00

One year ago today, an heretic approach to Plan 9’s legacy was born.

I wanted a simple, secure and distributed operating system for programmers.

Today Jehanne looks like this:

A lot of work has been done to turn Jehanne from a vision to a runnable starting point, but a little baby cannot be scary!

A pursuit of simplicity

The first goal of Jehanne is to be a simple operating system.

Defining simplicity is hard, but it is a prerequisite for security and usually seems obvious only in retrospect.

As a first step toward this goal I have removed or replaced most of code that Harvey inherited from the Berkeley distribution of Plan 9:

Jehanne derives its kernel from Charles Forsyth’s Plan9-9k instead of the Nix one imported in Harvey
it adopts the LP64 programming model (Plan 9 is LLP64 on x86_64)
many syscalls have been moved to user space or simply removed (and more will go)
the real-time scheduler has been removed
the compiler has been outsourced
most user space tools that are not required for a minimal OS has been removed (as they are going to be distributed as packages)

What remains has been modified in several ways and more drastic changes are coming. However, despite the changes and the removals, Jehanne still inherit most of its code from its noble ancestors.

Major thefts

First, all credit should go to Bell Labs for creating Plan 9 and authorizing the University of California to distribute the 4th version of Plan 9 as GPLv2. While the Jehanne’s kernel comes from a different source, obviously no Plan 9 derivative would exist without the original.

Second I have to thanks Charles Forsyth for his Plan9-9k that rescued me from the “complexities” of Nix and is licensed as GPLv2+. Porting it to GCC has been way easier than fixing Nix memory management (and believe me, I tried really hard!).

Then comes the Harvey’s team that actually let me play with a great project for a while and patiently guided me in the world of OS development. The build tools in Jehanne are evolutions of the Harvey’s original ones and also some userspace tools and a few assembly bits evolved from there.

And I should thanks the 9front developers (particularly Cinap Lenrek and Julius Schmidt) since my rule of thumb is “when in doubt, copy 9front”.
Yes, I know… I should have more doubts! :-D
Their impact on Jehanne is deeper than they might want to admit:

I ported 9front’s devshr, its usb stack, its awk and several other piece of code to Jehanne
I choosed hjfs as the default storage in Jehanne and used it to boot Jehanne on real hardware from usb
whenever I hit a bug in the original code from Plan 9, I check how it has been addressed in 9front

Finally thanks should go to Erik Quanstrom (9atom’s author) and to David du Colombier (9legacy’s maintainer) as they influenced this project in several ways. And obviously, to 9fans, who answer to my crazy questions with their usual humor and wisdom!

So… how did you wasted your time so far?

In 2016 I worked on several aspects of the project, fixing old bugs and adding tons of new ones. It would be impossible to describe each change or decision in a single post. Here you can just find an overview of the largest activities (that I can remember tonight :-D).

Don’t panic!

First I worked on development tools to minimize the cost for newcomers to try and start hacking with Jehanne.

On Debian GNU/Linux you can see Jehanne in action with very few commands:

sudo apt-get install git golang build-essential flex bison qemu-system
git clone https://github.com/JehanneOS/jehanne.git
cd jehanne
git submodule init                               # we have a lot of submodules
git submodule update --init --recursive --remote
./hacking/devshell.sh                            # start a shell with appropriate environment
./hacking/continuous-build.sh                    # to build everything
./hacking/runOver9P.sh                           # to start the system in QEMU
./hacking/drawterm.sh                            # in another shell, password: demodemo

The first build will take a while downloading and building the cross-compiling tool chain (GCC, binutils, autotools…), but the following ones will be matter of minutes (or even seconds if you build a single component).

Mess up the kernel

One of the most challenging aspect of Jehanne’s development so far has being cleaning up and modernize the kernel code (and a lot of work is still to be done!).

Now, I know that Plan 9 has been written by programmers that are way better than me, but hey! Jehanne has to be heretic!

To my untrained eye, the Plan 9 design is great, but the actual implementation sucks in several places. And that’s fine: Plan 9 is a research operating system! Indeed you can find in Jehanne warnings like “needs a massive rewrite” that were inherited from the Bell Lab’s code and that will stay untouched for a while.

But to me, the main issue is that the various components are tightly coupled. Very tightly coupled. Since we are going to port several useful unix tools to Jehanne, decoupling will be a leitmotif of its development.

A first example was _tos (top of stack) that coupled the kernel, the profiling machinery and libc. In Jehanne all this is gone: when we will have a profiler, it will be served as a filesystem.

A more subtle example is how Plan 9’s system API is coupled with 9P: for example open()’s mode constants (OREAD, OWRITE…) are the same in libc.h and in the protocol.
To allow new protocols to be integrated in Jehanne as deeply as 9P, I moved all 9P related defines from libc.h to 9P2000.h, I defined new constants (NP_OREAD, NP_OWRITE…) and changed the values in libc.h. It has been a nightmare, but now I will be able to experiment with new protocols way easier. Finally I renamed devmnt as dev9p to clarify that 9P2000 will be only one among the protocols supported.

To enhance their encapsulation, I rewrote the modules related to the userspace memory. After that, debugging memory-related issues with gdb turned way easier. Several other areas require similar efforts but they have lower priority.

Finally I removed the real-time scheduler. It was not that bad, but frankly when I need a real time OS I use QNX, and its presence was actually imposing an higher complexity to other areas of the system (for example devproc and semaphores).

Shrink its surface

An obvious requirement of an operating system striving for simplicity is to have a minimum number of orthogonal system calls, so that the user space tools and the kernel can evolve independently.

As previously stated, I moved to libc several syscalls (and more are going to be moved in the near future). Some of them are implemented with files from classic devices (eg dup or nsec). For others, like chdir, brk and pipe, a new device called devself has been introduced. Some syscalls have changed their semantics or their behaviour, like open, create and rendezvous. Others have been simply removed, as sleep, stat, wstat and sysr1. The most fortunate one, alarm, is waiting to be turned to a file server from day one, but stay untouched in kernel because of lack of time.

This is still a work in progress and I’m not sure about what will be the final number of syscalls in the system (or even their signatures). Fortunately it doesn’t matter: what I want is a clean and simple system API, free from backward compatibility issues but still able to support modern software.

Indeed I even added a new system call, awake, that deserves a separate post as an iconic example of how a well designed API can both simplify and empower the system.

Poison traditions

One of the first and most heretic decision I made has been to rethink the default namespace organization (aka filesystem hierarchy standard in Linux’s parlance).

Now, I know that with bind and mount you can shape your namespace as you like. I know, Plan 9 is not Unix!

But think of /bin: when UNIX was born most programs were binaries, but now? We have plenty of scripts there! Thus, in Jehanne, all programs are in /cmd.

There is no technical reason for this change, but why should we stick to obsolete names and conventions when we can change them for the better? When you realize this, many other changes arise. The default namespace should minimize name collision to ease navigation. It should be coherent and intuitive.

Again, the current shape of the default namespace shows just a first exploration in the solution’s space, it could change in the future, but I wanted to break it so that we can make it better.

What now?

Now we have a starting point. Small and full of bugs, but it runs on real hardware.

What Jehanne is going to become is up to us.

We don’t need it: Linux, BSDs and Windows are out there and we can use them for ~~fun and~~ profit.

Nevertheless I want it.

I want a system designed for this century.
A clean, coherent and secure operating system.
A system for which I don’t need browsers to host apps.

It might well be just a daydream, but my nightly journey continues.

Jehanne Operating System

2016-01-06T00:00:00+00:00

Jehanne is a new distributed operating system designed for programmers.
The core values that lead the development are simplicity and security.

Jehanne is a fork of Harvey (which in turn is a fork of Plan 9 from Bell Labs merged with Nix’s kernel sources) but diverges from the design and conventions of its ancestors whenever they are at odds with its goals.

For this reason the project is named after the famous French heretic Joan of Arc.

Sources

Jehanne is free software. Sources are available on github.