When will EROS be available?
Experience suggests that I should not answer this question with a date, as all of my previous dates have been wrong.
EROS is the heart of my doctoral thesis. The plan from the beginning has been to release the system when the measurements necessary for my dissertation were finished, or shortly thereafter.
Pragmatically, there will be a delay of several weeks from that point. I want to do some code cleanup (removing vestigial code that is ifdef'd out and will never work again) and make sure that all of the test cases run prior to releasing the code base. There will also need to be documentation enhancements. Since the document web can be updated daily, these can probably wait until after the code base is made available.
``So,'' you ask, ``how far away is the measurement from happening? I want to try this thing!''
Here are the work items that need to be completed:
A TCP/IP stack needs to be ported to EROS. This is well underway, but it is revealing bugs in some of the supporting code that take a while to locate and repair.
The TCP/IP stack is by far the largest chunk of code that anyone has attempted to port so far. The good news is that the bugs I am finding will make subsequent efforts much easier to deal with.
A web server needs to be ported. This will take some effort, but hopefully not as much as the TCP/IP stack.
That web server needs to be benchmarked, and the systematic behavior of EROS underneath it needs to be measured.
I have reasonable confidence that the dissertation will be written over this summer (1998).
Where can I obtain the source code?
Short answer: wait for the release.
Regrettably, there have already been a few examples of people hearing of a good idea in EROS and adapting it into other systems without crediting the source. While I'm glad that this has happened, I'm not at all happy about the lack of credit. In a few cases, it has made my job much harder because I am now competing against my own work.
There are a small number of people who have read-only access to the source tree, and two or three who are actively working on some of the EROS components. Jonathan Adams (Cal-Tech), in particular, has been extremely helpful over the past year.
Heartfelt thanks to Robin Lee Powell for reminding me to update this section!
EROS is available under the GNU General Public License (GPL) and the GNU Lesser General Public License (LGPL). A detailed description of the licensing terms may be found on the Distribution Terms page. Extensive discussion of (L)GPL license and what it means may be found at the Free Software Foundation web site.
Because EROS is a component-based system, it does not rely as heavily on linking as conventional systems. Given this, applying the ``work based on the program rule of GPL is not always easy to understand. The terms page gives some guidelines for when a newly introduced component must be distributed under GPL. The rules are a work in progress. The current set has two purposes:
They try to preserve the ``freely available'' character of the EROS system by preventing modifications that would render critical portions of the system proprietary.
They try to protect the security of the system by requiring that security-critical components be made public.
Earlier releases of EROS were made available under more restrictive licenses. Now that this is a thing of the past, I can admit the real reason for it: EROS wasn't ready for other people to play yet.
Successful open source efforts seem to follow a couple of rules. One of these rules is that they begin with some critical mass of cohesive software that serves as a template that a community can react on. In the course of building the original EROS system, it became clear that another major round of work on the kernel would be required. Since getting my dissertation done was also a priority, I crafted a license that would allow people to start getting a sense of the system without creating a large user base that would require care and feeding.
We also had concerns about security and provenance management, which is the next topic.
Concerns About Open Source
Open source raises a concern in the context of secure systems: how can a recipient have confidence that they have received a trustworthy system?
In the context of secure systems, the great strength of open source is also its greatest weakness: anyone can modify the code. In order for a non-technical user to safely use such a system, they need to have some assurance that what they receive is secure.
For engineers, ``assurance'' is an uncomfortable word. While assurance processes help produce better systems, assurance is not really about whether a system is correct; it is about whether a customer can have confidence that a system is correct. An oft-quoted open source mantra: ``read the source,'' is not helpful to typical users. Most users lack the necessary expertise to productively read source code. But even if they could, there is a more subtle problem: which source?
Because the customer cannot read the source, the problem of confidence must be broken down into two pieces:
Somebody needs to choose a set of sources, read them (or more broadly, apply appropriate assurance processes), and package them for redistribution. This assurance activity is a service provided to the end customer. It may or may not be backed by a guarantee, and the guarantee may or may not have financial ``compensation'' (a.k.a. insurance) associated with it.
Both the customer and the provider need a way to agree that the system the customer received is in fact the system that the provider assured.
It took a while to figure out how to ensure all of this in an open source model. In the end, the key proved to be simple: branding. We will be fairly aggressive about protecting whatever name the system is ultimately assured under. Actually, we will need to use separate brands: one for the system and the second for the assured version. The official release will also be digitally signed or one-way hashed so that users can verify its authenticity.
Others, of course, can independently assure versions of the system under their own brands.
What if I want to join the EROS team?
At this point, we could probably make good use of two or three more people to work on various projects. If you are interested in joining the EROS developer group, and you are in the Silicon Valley area, I'ld be very happy to talk with you. What we need at this point are people who are knowledgeable in C and C++ and have experience doing low-level debugging.
Why Silicon Valley only? Experience in teaching about this system at Penn shows that coming up to speed on the EROS code base can be accomplished in several weeks provided that face-to-face conversations (with a whiteboard) are possible. At the moment, my primary attention has to go to finishing the dissertation, which means that I don't have time to work with a broader group for a few more months.