GeneralThis forum is for non-technical general discussion which can include both Linux and non-Linux topics. Have fun!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Fedora on servers, Debian on PPC Mac, custom source-built for desktops
Posts: 174
Rep:
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?
Distribution: Fedora on servers, Debian on PPC Mac, custom source-built for desktops
Posts: 174
Original Poster
Rep:
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.
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.
That's actually what Lennart Poettering said about systemd as well (he seems to be a nice person, did you contact him?).
Could you you explain the "less bloat" part a little more (how...?, less options? how is that "more powerful" for admins?).
Distribution: Fedora on servers, Debian on PPC Mac, custom source-built for desktops
Posts: 174
Original Poster
Rep:
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.
There are already several init systems out there (systemd, Upstart, SystemV, OpenRC, ...), so interest in another one will logically not be very high. This may change if you just go for it and come up with some working code for your concept.
With working code I actually meant: Show that your code is capable of booting a distro in the way you declare your project to work, so may be a live-CD with your init system.
Distribution: Fedora on servers, Debian on PPC Mac, custom source-built for desktops
Posts: 174
Original Poster
Rep:
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.
Distribution: Fedora on servers, Debian on PPC Mac, custom source-built for desktops
Posts: 174
Original Poster
Rep:
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!
(..) once I have completed dependency support, I'll provide a test executable with statically linked libShadowFax that will be suitable for booting up (..)
Interesting. Once you do I'll throw it on a vm just to see if it works.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.