Make rapidboot script a separate project

[matteotenca]

Hello,

since I am finding and fixing bugs and adding functions to the rapiddisk-on-boot script quite often, I believe moving it away from the main rapiddisk tree is an option. I would take care of it in a public repo on github.

For example, I am working on a new version, which is able to create an arbitrary number of rapiddisk volumes upon start (credits to @Augusto7743 for this idea), which fixes bugs, too.

Anyway I leave @pkoutoupis the last decision about this idea!

Regards

[pkoutoupis]

@matteotenca I want to give you a proper response here. I am currently resting with Covid. I will get back to you shortly.

[matteotenca]

Thanks, take care, I wish you to get well soon!

[pkoutoupis]

Thank you. I have been mostly asymptomatic. I just haven't been sleeping well.

[pkoutoupis]

@matteotenca I enjoy having the rapiddisk-on-boot scripts be part of the rapiddisk project. I am always happy to see your contributions (regardless of the amount) and welcome them. I sure hope that I have not made you feel otherwise. If so, please do tell me so that I can adjust my behavior. My only concerns with it are the fact that I am not readily able to answer user questions.

On the same note, I am looking forward to seeing the progress (if any) you made on the GUI piece, to eventually incorporate that into the greater project.

That being said, if you would prefer to branch off, I do not want to stop you. Outside of the Wiki and maybe a README not, I do not know how to redirect new users to the separate project.

[matteotenca]

Hi there,

I hope you got out of COVID nicely!

I am always happy to see your contributions (regardless of the amount) and welcome them. I sure hope that I have not made you feel otherwise. If so, please do tell me so that I can adjust my behavior.

You were always really kind to me and I could learn from you a lot of things (how to contribute to a project the right way, to say the least). Since rapiddisk is very stable and does not require many mid-term releases, my one and only concern is about bugs in my scripts that I can fix but that will remain there until next rapiddisk release. I did not find any critical ones up to now, but there is a bad one in the clean script (which is intended to delete all unmapped ramdisk upon boot under Ubuntu) that cause the script to try to remove all the ramdisks (luckily, mapped ones can't be deleted!).

Since the project is yours, and really great, I don't want that a bug in one of my scripts may end up casting a bad shadow. This is my one and only concern, to be honest; I don't feel the urge to branch off, at this time.

On the same note, I am looking forward to seeing the progress (if any) you made on the GUI piece, to eventually incorporate that into the greater project.

About this topic: my goal is to write a curses based CLI Python app, but I must admit that curses is quite complicated, both in Python and C (nearly the same syntax), at least to me. I need some time to study curses.

The PHP/HTML/Javascript approach is very easy, I did some experiments and I believe that the very simple web server provided by the php -S <address>:<port> command itself is enough. This is very nice since it makes possible to wrap all the needed files into a single arvhive, launch a script and go with the browser.

Beside this, I wrote a new version of rapiddisk-on-boot which can map any number of ramdisk on any number of devices during boot. This idea came from @Augusto7743. This new version works under Ubuntu only, at this time, but I believe it is possible to do the same under CentOS too.

I'll put on github a temp repo with a working PHP interface just for you to see. And I'll push a new branch with the new rapiddisk-on-boot asap, it works quite well but is still alpha.

Regards

[pkoutoupis]

I did get out of Covid, unscathed. I was mostly asymptomatic but testing positive. So, I was isolating from the family until I tested negative again (9 days). Thank you for checking. 😄

I understand the concern about the potential for introducing a bug with the scripts but we can always cut a minor release to address that. Although, maybe we need to think of "test" scripts to test various parts of that code and gain additional reassurance that certain portions are still good before being merged. Thoughts? (I typically keep the quick testing scripts in the test subdirectory of the root of the project.)

Anyway, I look forward to seeing the PHP interface when you get to the point in sharing. Question: is it relying on the REST API from the daemon or on the CLI management utility?

I also look forward to seeing the new rapiddisk-on-boot branch.

[Augusto7743]

About "rapiddisk-on-boot" thanks very much !
An good improvement for an superb software.