Anyone interested in a systemd alternative?
Before I get your hopes up, keep in mind there is a chance this could all become vaporware, but I'd like to extend my thoughts on my intent to write a very lightweight systemd alternative for Linux in C. I plan to depend on nothing other than libc, a Linux OS (until BSD support is added, which will be in the roadmap), and it's own shared "libshadowfax". (Shadowfax will be the name)
It will support multithreading, but processes will be able to be started linearly as well. My idea for configuration included /etc/shadowfax/ as the location, and .conf files for each stage of the boot sequence, such as preboot.conf and services.conf, and for service IDs, service-ids.conf. The services would share a common ASCII ID and share the same config files. Adding services from scratch would be possible with, for example, shadowfax additem service <ID> <Loading method> "<command>" "<command>" "<command>". It will not depend on udev or procfs or sysfs, and it will support emergency shutdown with a key binding, disabled by default. All configuration data will be copied to RAM upon execution for boot up, and reloaded and resaved upon editing from the program itself. Does anyone find such concepts intriguing? Ideas? Suggestions? |
why do you want to do that? is there any benefits?
|
I don't like the name. I got totally burned out on LOTR about a decade ago.
|
The big benefit is an efficient, lightweight, configurable, capable boot system that fits both full size and minimalist distributions like a glove. It's designed to use very little resources and put as much power in the hands of the administrator as possible without bloat, while also providing an efficient, multi-core/thread optimized boot system.
I am also considering the name "Lazarus". I want this because systemd is too big and becoming too integrated with the OS and various libraries, and the OS and other software too integrated and dependent on it. It is unsuitable for very minimalist sub-100MB distributions and has too many dependencies. I like many of it's features, but not the bloat that accompanies them. Thoughts? |
Quote:
Could you you explain the "less bloat" part a little more (how...?, less options? how is that "more powerful" for admins?). |
I plan to make my code concise and readable, with generic functions that are often more efficient than what is found in stdlib. The admin will be given sure and immediate control over the services and boot sequence of the system, to customize to his liking with little effort. On one front, all config files are to be universal and easily edited, with options well placed and obvious, and on another front, the executable "shadowfax" will contain options for full control over services and all the options specified in the config files. All configuration will be in a unified location with a unified format and will prove uniform across all UNIX platforms. It will support starting services and boot items as threads but will not mandate them to be done this way. It will leave efficiency and priority to the user. Services may specify how they would like to be started but can not object to modification. A file based interface will be used for shutdown messages to the primary "init" instance.
It's all going to be elegant, mostly because of it's simplicity. |
Does everyone give so little a crap? :^|
|
Quote:
That will change when, and not before, you release it. |
Quote:
|
|
Quote:
|
That will take more time, but I could probably push out a prototype with core functionality within two weeks. No promises.
|
Something has been accomplished!
I've completed threading support for services in libShadowFax, making it very easy to write a core boot system that uses ShadowFax's libraries. I've tested execution, it's effectively possible to boot a Linux system with ShadowFax, though MUCH more work must be done before it's called semi-stable. Just thought that might be nice.
https://github.com/Subsentient/shadowfax |
Status update
Dependency support is almost done. Threaded object support is complete, the code has just had it's memory footprint nearly erased, and the library is stable and valgrind reports no outstanding issues (besides BS that will NEVER actually execute that way by design), and once I have completed dependency support, I'll provide a test executable with statically linked libShadowFax that will be suitable for booting up, but not shutting down, since that chunk of code is yet to be implemented. A few "God objects" may be broken apart, but we'll see, since I see no serious performance issues with them. Soon a CLI interface and the FileBus (means of smaller ShadowFax executables such as poweroff to communicate in a cross platform way) will be written. The project is very much active with much additions and refinements coming in all the time. Stay tuned folks!
|
Quote:
|
All times are GMT -5. The time now is 04:54 AM. |