KillingSpark / rustysd

A service manager that is able to run "traditional" systemd services, written in rust
MIT License
500 stars 15 forks source link

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

Open eleksir opened 4 years ago

eleksir commented 4 years ago

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 commented 4 years ago

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

eleksir commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 1 year ago

Name suggestions:

KillingSpark commented 1 year ago

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