-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Great name for the project - share your thoughts and ideas. #44
Comments
@eleksir's comment is worded a bit rudely, but I think a more "catchy" name might be nice. |
Actually there is no rudeness in comment here. (You just missing N.B. addendum.) 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. |
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:
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. |
Any progress with fork+exec? I used rustysd before the rewrite to manage crun containers with some problems (start / stop and reload units...)
|
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. |
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. |
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 |
Name suggestions:
|
What about a variation on the first suggestion |
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.
The text was updated successfully, but these errors were encountered: