Yes, Eddon actually has some bearing here because I think its the better way to handle things.
Eddon’s design is that it is capable of being implemented in multiple tiers. The first being a simple virtual machine programming language like perl or python. The second puts it more in line with an application server like Zope or maybe Android’s Zygote in that it loads virtual machine code into a centralized server and maintains permissions to the resources it controls while allowing for easier IPC between the programs under its control … while also providing directory services and a lot of shared code! Things will start up fast since most of the libraries are already loaded and linked. The third tier is a full object oriented desktop environment along the lines of Smalltalk’s world (but implemented as classes in a file system, not a “world” file).
Does the second tier sound a little like systemd? Well, its close. In this situation though, we leverage some really great technologies that Eddon bring to the table. First, as a hybrid language, it can be used to script service startup. Simple class inheritance lets us more or less configure the most common services without writing any code. In fact, the “configuration file” would actually be eddon code disguised as a declarative file, but really 100% controllable with all the flexibility of a start-up script available to you, only without having to run a bunch of external programs. The Unix “do one thing and do it well philosophy” migrates from the process to the class.
Eddon already have process control when it starts up an activity or new project. It has all the little “hooks” all tied in, as well notification of completion, exit notification, and the ability to bring it down again safely. And this doesn’t even get into the change management capabilities, class version control, or data manipulation API used to broadcast data changes (powerful enough for simulating digital circuits, but also useful for MVC).
Next, we have Eddon’s inheritently parallel, event-driven nature. C wasn’t designed for this. Eddon was. And we have a maximum thread pool to prevent system thrashing, plus priority levels for free. Sockets and other IO are pretty simple in Eddon, and the permission system can be applied to devices and other “session management” tasks. Of course, it would be trivial to have Eddon run a shell script for existing services, but rewriting the script in Eddon makes it simpler, easier to debug, and faster. You can implement inetd, or even write a udev and/or dbus replacement in Eddon which would allow the use to run Eddon scripts when an event fires, all stored in one place, and with JIT support.
Device management becomes almost trivial, as does session management. The kernel tells us about devices and when they are plugged, we run an event to name it and decide who owns it based on log-in/session information, and we can manage the permissions using our permission management features, and fire off code appropriately. The control file is simple, made up of Eddon object descriptions similar to a JSON file, but you have access to a full programming language with Smalltalk flexibility, Lisp functionality, Java’s organizational and namespace abilities, and Python’s simplicity (and C’s speed!). We could parse systemd’s files, too.
Worse than systemd? Well, I don’t want to break compatibility with existing systems, just allow more options. Second, you get to write Eddon program code to control your start-up code which is much easier to write than bash or C, easier to debug, and it’s designed for parallelism. C ISN’T! In other words, I want to empower the Admin, not take it away.
At tier 3, console messages written from a “wall” command or system shutdown are automatically placed into your notification area … without any separate demons getting in the way. It becomes an Eddon based system. Eddon gets the message (likely WROTE the message) and sends it to each controlling terminal which become, not Unix devices, but Eddon objects that are much more powerful. Everything that systemd wants to do, but with an incredibly powerful scripting system behind it designed for event-driven parallel multiprocessing from the ground up.
It is my intention that when Eddon gets ready for tier-2 client/server, multi-user release, I will be adding to it udev, dbus, and gconf capability, and probably jack & pulseaudio as well (integrated together into one system with both APIs available running with a real-time activity), but all implemented cleanly as Eddon classes that emit events you can tie your own code to, persistence through the system’s database (gconf), etc. And at that point, we’ll already have GTK for graphics.
Coming Soon To A Linux Near You! Just all vapor-ware for right now, but it will get there!