Great name for the project - share your thoughts and ideas.

[eleksir]

Seriously. Think about name of this init-like service. More fantasy|imagination won't hurt.

It can be infinit or rockit or something that can be easily pronounced and easily remebered.
There is tini project. And, yes, it a good name. Anyway, what i want to say that name of project should not be nailed tightly to the language it is written in. I uderstand that go, pardon, rust is the safest and coolest lang out there, but this fact should not limit us in naming of projects.

N.B.
This is not demand and i'm not instst on doing rename now or whenever, but i'd like to kow that this idea just taken in consideration as a good advice.

[jabedude]

@eleksir's comment is worded a bit rudely, but I think a more "catchy" name might be nice.

[eleksir]

Actually there is no rudeness in comment here. (You just missing N.B. addendum.)
It's like an avant-garde art - the word-form here is an attempt to grab for attention to mentioned idea about naming projects.

Name of a project is a part of its success when in open cometition. The name should influence your subconscious choice and attract you to use this particular project. The idea also is that it's nice to work on a project with a good name. Nice name motivates by itself.

Anyway i like the ideas behind this rustysd that's why i'm suggest this thought to consideration.

[KillingSpark]

I agree that a catchy name might help adoption but I am not sure this is what this project currently needs. There are some critical things left to solve before adoption by users:

1. How to do logging, both for rustysd itself and for the services started by it
2. How to handle the fork+exec in a clean way that allows for platform specific behavior (e.g. cgroups) without mostly rewriting runc/crun/railcar/...

Until this is done I am against 'rebranding' just to gain adoption since this is very much alpha-stage software. I am however open to leaving this issue open to collect cool names for this project if it gets to a point where adoptions would be a good thing to have. I am not the best at naming stuff so your (and anyone elses) input on that matter is very much appreciated.

[pwFoo]

Any progress with fork+exec? I used rustysd before the rewrite to manage crun containers with some problems (start / stop and reload units...)

I agree that a catchy name might help adoption but I am not sure this is what this project currently needs. There are some critical things left to solve before adoption by users:

1. How to do logging, both for rustysd itself and for the services started by it
2. How to handle the fork+exec in a clean way that allows for platform specific behavior (e.g. cgroups) without mostly rewriting runc/crun/railcar/...

[KillingSpark]

Not really. I have been distracted by writing my own dbus lib after being annoyed with the current state of affairs in the dbus ecosystem.

I have some ideas on how to restructure rustysd to do the fork+exec thing in a better way. It would be a lot of work and I'd like to finish the dbus lib before diving into rustysd development again.

[pwFoo]

I don't like dbus dependencies (because I try to run applications inside of an docker container... g). So I would like a simple solution / workaround instead of a dbus dependency.

[KillingSpark]

Well there already is an optional non-default dependency on dbus. This crate uses FFI to use the C libdbus. This was the only viable option at the time. My pure rust implementation of a dbus lib should replace that dependency in the future.

This dependency is strictly needed for systemd compatibility because it has a service type dbus which waits for a specific name to be grabbed (which I hate. systemd should have required these services to call sd_notify or at least make them write a small wrapper. But whatever, it's in there so I did my best to support it). I made it optional though so you don't need to worry :)

[michalfita]

Name suggestions:

• oxyinitd
• oxideinitd
• oxygend (in the end PID1 is like oxygen of the whole OS)

[KillingSpark]

What about a variation on the first suggestion oxinitd for better pronouncability?

[brlin-tw]

Hello, just found this fun issue and would like to suggest simply dropping the 's' at the back of the original name and just call it "rustyd"(pronounced "rusty-D")?

It's:

• easier to pronounce.
• has a similar ring to "systemd"'s pronunciation.
• not too far away from the original name.

I know that's not really important at the moment, just dumping out my two cents.

[KillingSpark]

I kind of like the idea but the suffix -d usually just means "daemon". I think the goal should be removing the rust part of the name :)