You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Set up and config is cumbersome and somewhat fragile by nature, and any complexity which can be eliminated with an appropriate solution probably should be.
Describe the solution you'd like
I think using Docker or some other container software could significantly ease the process of setting up the project by ensuring exact decencies are managed in a scripted capacity and user error is automated away — either when installing scratch, or for a reset and upgrade perspective.
I also think that consistently updating/upgrading will become a big issue for the longtail of users without something like this. I think a container could help be a piece of all future installs.
Hypothetically running the project on alternative hardware is also made easier this way.
I believe any performance hits and latency issues would be negligible, but I'm really not sure. It also probably varies depending on container setup.
Describe alternatives you've considered
I think this is an area worth attempting to address. I'm not totally sure containers are definitely the solution, but it seems like it would be.
As far as alternatives within containers and virtualizations, while Docker seems like a good choice if it is determined that it doesn't cause resource or latency issues because it's a highly-adopted standard. Podman, however, might be a better alternative for being generally more lightweight.
Maybe we need 100% native performance and this isn't a viable path, but maybe this gets a conversation going on UX for the install/upgrade process in general. 🙂
Additional context
I think the nature of this project's success is a cascading sequence of complexity reduction and efficiency gains which make it ever more viable for more people, and no one part of the solution is the whole thing — but this strikes me as a step in the journey which could be very valuable.
I imagine this will involve the need to really lock down customization steps for setup (i.e. ensuring all customization is variable and does not involve ad hoc modification (e.g. #40)
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Set up and config is cumbersome and somewhat fragile by nature, and any complexity which can be eliminated with an appropriate solution probably should be.
Describe the solution you'd like
I think using Docker or some other container software could significantly ease the process of setting up the project by ensuring exact decencies are managed in a scripted capacity and user error is automated away — either when installing scratch, or for a reset and upgrade perspective.
I also think that consistently updating/upgrading will become a big issue for the longtail of users without something like this. I think a container could help be a piece of all future installs.
Hypothetically running the project on alternative hardware is also made easier this way.
I believe any performance hits and latency issues would be negligible, but I'm really not sure. It also probably varies depending on container setup.
Describe alternatives you've considered
I think this is an area worth attempting to address. I'm not totally sure containers are definitely the solution, but it seems like it would be.
As far as alternatives within containers and virtualizations, while Docker seems like a good choice if it is determined that it doesn't cause resource or latency issues because it's a highly-adopted standard. Podman, however, might be a better alternative for being generally more lightweight.
Maybe we need 100% native performance and this isn't a viable path, but maybe this gets a conversation going on UX for the install/upgrade process in general. 🙂
Additional context
I think the nature of this project's success is a cascading sequence of complexity reduction and efficiency gains which make it ever more viable for more people, and no one part of the solution is the whole thing — but this strikes me as a step in the journey which could be very valuable.
I imagine this will involve the need to really lock down customization steps for setup (i.e. ensuring all customization is variable and does not involve ad hoc modification (e.g. #40)
The text was updated successfully, but these errors were encountered: