========================= Étoilé Technical Overview ========================= Étoilé System Presentation ========================== What We Want? ------------- Apart everything… :-) We already have: - Stability - Security - Performance But we would like also: - Flexibility that would allow - Transparent Distribution - Components Most of OSes widely distributed these days have ridiculous support for such evolutions. They basically don't do the deal (when you aren't considering only performance and stability at a lesser extent), that means they don't provide interesting abstractions to build a user environment… The two most important points: - no reflexivity - no unified domain/object space support or similar interaction model support (everything is a black box) Let's Write Yet Another OS -------------------------- Hmm… No. Writing OSes is a pain that involves a huge amount of problems: - hardware support (drivers etc.) - software support - stability - performance The World Has Been Linuxed -------------------------- Solutions: - Hurd or similar - Squeak Well, no… Let's start being realistic: - That's impossible to fix - What are the solutions? The world has been linuxed, we have to deal with this fact until the splashy comeback of Hurd & Smalltalk happens one day or never. We must investigate an intermediate approach. Very Rough System Classifications --------------------------------- - Virtual Machine (Squeak is THE example) - Monolithic system or kernel (that uses a two layers approach between kernel space and user space) - Composite or aggregated systems (that includes microkernels, exokernels, programming languages as kernel or system etc.) Return of the Black Box ----------------------- VM, Kernel and Interpreter, when run in a layered manner, result most of time in the same black box syndrom we encounter with other applications. The particularity of these systems is when you run one on top of another one, the hosted system is always running in a black box. Most of time, there is a one-to-one mapping between host system 'task' (taken in a very large sense) and the client system (relying on the capacity of the host system to directly or not present itself as virtual system). I say most of time because that wouldn't be true for recent JVM (at a lesser extent, we could have similar objections with dynamic language VM/Interpreters) To summarize in the shortest manner, we could state the host system is always acting like a virtual machine. Make a Wish ----------- Étoilé system should be quite different on this matter, because it is focused on a middle approach where Étoilé system should multiplexed with its host system, most of tasks when they are run are mapped to host system tasks and parts of Étoilé system components are mapped to host system primitives. Because Étoilé are components are provided in separate modules and relying on objects model, you can easily use inheritance to tune performance of a basic Étoilé system, by adding support for more host system primitives. Étoilé Middle Way ----------------- Eureka: Put a "virtual" microkernel on top of the host system. Microkernel looks to be what we want, but they are usually put under the main system (Linux on Mach or L4 are common examples) whether it is monolithic or not. By doing the reverse, we obtain most of microkernels benefits we need to build a really advanced desktop environment, without its main downsides performance and hardware support. A virtual microkernel would be a microkernel stripped down to the following facilities: - name service - messaging support - task/thread API Optionally we could include: - persistency support (though storage is delegated to the host system) Early Conclusion ---------------- If we build a light and relatively thin system layer which is easily portable to many OSes and circumvents their most drastic limitations, it is basically a win-win situation. A major problem will remain though: OS integration. That's one of the point Linux Desktop has failed to fix for many years, it's done yet, but it seems possible to achieve now (look at FreeDesktop and Ubuntu, Mandriva distributions for example, they are on this path). Diving in the Virtual System ---------------------------- In what sense Étoilé is a system? 1. Virtual Operating System Étoilé Virtual System is a very simple microkernel-like system oriented with high-level features in mind rather than low-level integration with hardware. It is written to be run on top of other kernels or systems, unlike usual microkernels (which are able to host monolithic kernels or systems as sandboxed servers). 2. Virtual Object System - Everything is an object (Spring philosophy) It is combined with a Virtual Object System (basically similar to Spring domains, VFS in Plan 9 and Hurd or SoFS in SOPE), it is powered by an object server ('name server' referencing, routing and returning only objects). Virtual Object System Inspiration --------------------------------- A bit of history: - UNIX -> Most of things are files (or mapped to) - Plan 9 -> Everything is really file a this time (finally)!… - Mach - Hurd - Vanguard -> Every servers is an object - Spring -> Everything is an object (or mapped to) Étoilé System Layers -------------------- - We take care of: - name server - system messaging (IPC) - daemons (start, restart, stop, monitor etc.) - persistent data semantic (FS) - host system interaction - We delegate to host system: - memory primitives - task/thread primitives - scheduling - memory allocation - drivers Why uses GNUstep and not… ? --------------------------- - Squeak (Smalltalk environment) - No solid framework to develop applications with a graphical UI - Probably one of the worst UI you can think of - No roadmap or vision (the development process looks messy) - Run in a complete black box (specially when you consider VM relationship to the OS) - Io (looks more promising than Smalltalk right now) - Io environment (desktop + server) - Flux (previously named Ion), Io AppKit inspired framework is still quite limited and not in a really good shape right now - API very unstable (though 1.0 release is approaching, things should improve) - No environment ecosystem with features like bundles, gpbs, gdomap etc. - Community smaller than GNUstep/Cocoa - Not matching Objective-C in term of facility with OS integration - No development environment (especially thinking about Gorm or Interface Builder) Note that Etoile was not created with the aim of "being a GNUstep desktop" but rather, after looking to underlying solutions to implement it, GNUstep looked like an obvious choice to start with. The decision to base Étoilé on top of GNUstep is a question of opportunity: GNUstep gives us excellent frameworks for dealing with graphical and non graphical components, as well as distributed objects. As such, Étoilé is for the moment mainly done in Objective-C, but we expect in the future to work on even higher level environment based on languages such as Io, Smalltalk, or Ruby. Ultimately they are really strong points in favor of Io: - Language itself - Pure OpenGL backend for graphics - Run on many platforms like Linux, Mac OS X, Windows etc. (yes, Flux included) - Moving forward quickly - Growing community Because of these points, Io will be supported and installed by default on Étoilé. Overriden GNUstep stuff (1) --------------------------- Deprecated API in Foundation - NSFileManager - NSPipe - NSFileHandle - Parts of DO - Services API Compatibility will be kept with these APIs, but GNUstep software relying won't be considered Étoilé native (and may not benefit from all Étoilé features and transparent integration with native programs). Migration path: - NSFileManager -> CoreObject or WorkspaceKit (more featured API for AppKit based applications) - NSPipe, NSFileHandle, DO -> CoreObject - Services API -> CoreObject and PickDropKit Here is a memento about DO classes: * NSDistantObject * NSDistantObjectRequest * NSDistributedLock * NSDistributedNotificationCenter * NSSocketPort * NSSocketPortNameServer * NSPort * NSPortCoder * NSPortMessage * NSPortNameServer * NSMessagePort * NSMessagePortNameServer Overriden GNUstep stuff (2) --------------------------- Possibly deprecated or rather reworked API in Foundation: - NSTask - NSThread Well, that's still to be considered. It would be to introduce a more object oriented feeling (less Unix influenced). Deprecated API in AppKit - NSWorkspace (not initially ?) - Few more to come like Pasteboard related stuff: - NSServicesRequests - NSInputServiceProvider - NSEditor - NSEditorRegistration - NSDraggingDestination - NSDraggingInfo - NSDraggingSource Migration path: - NSWorkspace -> WorkspaceKit - Pasteboard related API -> PickDropKit Examples of Eventual CoreObject Tuning -------------------------------------- To take two examples: - ObjectServer could be replaced at system init by HurdObjectServer (then Étoilé would use rather highly tuned Hurd name server for its own purpose) - InteractionDispatcher when Étoilé is run on DragonFlyBSD, could use DragonFlyBSD messaging primitives with an object InteractionIPIDispatcher Quick Birdview of CoreObject ---------------------------- CoreObject and its object server should provide two fundamental features: - host system and Étoilé system interaction through a merged representation (in term of domains) - distribution support (based on our beloved Objective-C DO) between - processes - hosts - languages At a later point may be: - orthogonal persistency in some cases Note: Read CoreObject Presentation to learn more about it. What's happen when Étoilé System starts up? ------------------------------------------- Here is the sequence… - Host system boots Then either manually or automatically: - Étoilé system server (aka etoile_system, init process taking care of daemons/servers à la launchd) is started Note 'root' privileges will be mandatory, at least initially. This process is similar to Darwin launchd (by being both a kernel-like init process and a daemonizer) Any other servers is now started by etoile_system itself. At this time, other Étoilé core servers are started in the following order: - Security Server (aka etoile_securityServer) - gdomap - gdnc - Object Server (aka etoile_objectServer) - talk (aka etoile_talk, tailored command line playing the role of the shell for the Object Server) gdomap will probably have to be integrated in etoile_objectServer for performance and code simplicity reason. When the user wants a GUI environment, few other servers are started: - Window Server (aka etoile_windowServer, which will be initially nothing more than an X11 launcher) - Azalea (X11 related WM, may evolve in future) - Étoilé Identity UI Server (aka etoile_identityUIServer, security helper in charge of the login window) - Étoile System UI Server (aka etoile_systemUIServer, helper providing various System UI panels not specific to a particular service/application) Next servers or services are now started with user privileges: - gpbs - Security UI Server (aka etoile_securityUIServer, helper that handles various System UI panels, specially authentication panel for AppKit processes when they need special authorizations without raising their privileges) - Shelf (aka etoile_shelf) - Menu Server (aka etoile_menuServer) - Workspace (aka Workspace or Openspace, playing the role of the User File/Object Manager) - User Session, surely ? - Project Session, probably ? Time to play now! TalkCenter shell ---------------- TalkCenter is nothing more than a shell directly interfaced with CoreObject and bundled with a set of tools to manipulate objects referenced by the objects server or within TalkCenter child processes. By default, it relies on Io language but would support in fact any languages registered in the object server (that suppose the corresponding CoreObject language bundle is installed on the system, such bundle would provide a bridge specific to one language) When you start Étoilé system without UI servers, the virtual system starts and supposing your are in a Unix shell, you are immediately offered TalkCenter prompt (the Étoilé shell). You won't quit this shell until you exit Étoilé system itself. That's in part why Étoilé is not a desktop environment but a user environment. It uses would scale from text console to full GUI support. That means TalkCenter application is mostly a GUI wrapper around 'talk' tool (as it is already the case with usual Unix and GUI-based terminal application).