Skip to content
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

Open
eleksir opened this issue Jul 27, 2020 · 9 comments
Open

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

eleksir opened this issue Jul 27, 2020 · 9 comments

Comments

@eleksir
Copy link

eleksir commented Jul 27, 2020

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
Copy link
Contributor

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

@eleksir
Copy link
Author

eleksir commented Jul 28, 2020

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
Copy link
Owner

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.

@eleksir eleksir changed the title Too much rust here - rename to crusted? Great name for the project - share your thoughts and ideas. Aug 3, 2020
@pwFoo
Copy link

pwFoo commented Jan 3, 2021

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
Copy link
Owner

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
Copy link

pwFoo commented Jan 3, 2021

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
Copy link
Owner

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
Copy link

Name suggestions:

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

@KillingSpark
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants