It’s not bad to take a breather and collect yourself either to review how the project can and could proceed. Honestly, Runit-for-LFS is likewise in long-term maintenance mode as honestly, I've gone back to Slackware and began using OpenRC.
I think eventually init and supervision will have a well timed meeting with init scripts having internal supervision mechanisms using things like s6 within OpenRC scripts, sysvinit scripts, and bsdinit scripts rather than the stages, but that’s just my idea. While I feel Runit-for-LFS has reached somewhat it’s limitation barriers, I know eventually it could get resparked back to life. You’ve done great Avery. Take a well deserved break, collect yourself, then when you’re ready, return refreshed and maybe then we can see about how to look into problems that need addressing. -Jim Sent from Outlook Mail<http://go.microsoft.com/fwlink/?LinkId=550987> for Windows 10 phone From: Avery Payne Sent: Saturday, November 21, 2015 1:36 PM To: [email protected] Subject: [announce] supervision-scripts to be retired Since I began what amounts to my first open source project - ever - I have learned a lot in the process, met several interesting characters, and hopefully provided some insights to a few others as well. To everyone over the last year and half that have put up with me, thank you for giving me an ad-hoc education, being patient with my silly and often inane questions, and tolerating some of my goofy responses. When I started supervision-scripts, I had a vision of a set of ./run files that could be used with many different supervisors, in different environments. It was, at the time, an admitted reactive approach to dealing with unpleasant actions in the Linux community. I have since changed my view and approach to this. Along the way, I also found that there were issues that would prevent both the completion and use of the current scripts on other distributions. One of those problems was the use of different user account names; different distributions use their own namings and none of them easily align with their peers in any fashion. Another problem was the use of daemons that required "settings after installation", which I do not have a current provision for. To make matters worse, much has happened in my personal life that has obstructed me from continuing work on the current version of supervision-scripts. I have given some thought to this, and between the current lack of time and the constructive criticism received from various parties, I will be unable to continue adding new definitions as I had planned. The existing arrangement I came up with, using indirection and program renaming, is viable for installations that use a supervisor only. At first I thought I could incorporate it into system or state management, but I now see that will not be possible - yet another design flaw that prevents me from reaching the project's goals. The other issue is the embedded user accounts used by various daemons, which currently are all Debian-mapped, making the project still intimately tied to Debian when I do not want it to be so. Despite all of those limitations, it has been easy for me to create new definitions quickly, and use them for my own purposes at home. In the sense that this shows a proof-of-concept, it validates some of my assumptions about making portable ./run files. So, the current project is entering "maintenance". By this I mean that I may occasionally add new definitions to the project but overall, there will be no further code changes, and no changes to the structure of how it works. The documentation will be adjusted to reflect this, along with the current design flaws. Once the documentation is complete, the project will "retire", rarely updating. I still believe that process supervision has a future; that for that future to become a reality, there needs to be an easy way for distributions, packagers, and end-user to incorporate supervision into existing arrangements; and that the current, easiest method for doing so is to have pre-written definitions that can be quickly installed and used. I am not fully admitting defeat in this process. This specific battle was lost, but this isn't over. As time goes on, I will take what little spare time I have left and put it towards a new design. The design will be fully implemented "on paper" first, and I will ask for peer review in the vain hope that more experienced eyes besides my own will be able to discern problems on paper before they solidify in code. This new design will incorporate what I have learned from supervision-scripts, but it will take an entirely different approach, one that I hope achieves the original objective of a portable set of ./run files for supervision. Until then, I will stay in the background, content to observe.
