Re: One-Stop Debian Box Config Tool: Call for Collaborators!
On Fri, Sep 13, 2013 at 5:36 PM, Jarrod O'Flaherty <jofsama@yahoo.com> wrote:
>
> Greetings All!
>
> This is a call to Debian programmers who would be interested in spending a
> couple hours
> a month
Pipe dreams.
> working with me on developing a "One-Stop Debian Box Config Tool" --
Possibly doable for a limited subset of "common" configurations for
some specific set of uses. Several such configuration tools for
computers to be used in a school lab. (And none of them do more than
get you started sort of reasonably well.)
> a tool intended to
> become the central and all-encompassing place to go to configure any and
> every aspect of your
> Debian system.
Pipe dreams.
> CONCEPT OUTLINE
> =================
>
> The tool will (subject to the approval of the collaborators ;) :
>
> 1. Drastically reduce the need to:
> a) Google every time you want to tweak feature X of package Y.
Ergo, the wikis.
> b) Post to message boards when Googling fails to deliver the goods.
So where do you go when the tool fails to produce?
> 2. Provide users with an (ever-growing!) common repository of step-by-step
> "recipes" by which
> they can tweak / fix / customize / build / repair / upgrade their
> systems.
Ergo, the wikis.
> 3. Present each step of a recipe in the form of a regular shell command, so
> it can be
> easily checked, easily modified, and -- most importantly! -- easily
> applied.
What? No GUI?
Okay, points for this one. Sort of. But we are still looking at the wikis.
> 4. Eliminate the need to copy and paste said shell commands by providing a
> special terminal
> window as part of the interface.
With the script sitting in the window waiting to be tweaked and/or run? Cool.
Has BBEdit opened their source code, or are you using EMACS? Or has
someone gone to the trouble of writing a new implementation of the
editor-as-shell function?
> 5. Reduce or altogether eliminate the need to edit the shell commands by
> intelligently substituting
> installation-specific pathnames, module names, version numbers, etc.
> into the commands
> as appropriate.
Wow. Not just editor-as-shell, but templates, and a knowledge base
that figures out what to put where in the templates.
Such a beast would put sysadmins OUT OF WORK!!! DO YOU UNDERSTAND THAT?
:-)
But the size of the database means, yes, it sounds like you are trying
to write a dynamic interface to the wikis, while you are at it.
> 6. Allow you to search the recipes using a goal-based syntax similar to the
> following:
> PATTERN) "I want to: VERB + OBJECT [ + to + VALUE ]"
> EXAMPLE) "I want to: change the default GTK font size to 18pt"
>
>
> 7. Facilitate the sending of feedback to report successes and failures using
> a given
> recipe, automatically collecting and attaching to it relevant information on
> the system setup
> as well as any (error) messages that were output during the process.
>
>
> 8. Play The Imperial March every time you report using a recipe
> successfully.
> (Hmmmm. Then again, there could be some licensing problems there.)
>
>
> All frivolity aside, let's start talking about how to automate the system
> configuration and
> administration process the same way the rest of the *NIX world is automated!
Well, how about we start trying to make the wikis more accessible, and
more up to date, first?
> HOW TO GET INVOLVED
>
> ====================
>
> Those interested should email me ( jofsama@yahoo.com ) with their:
>
> * Name
> * Languages Spoken/Written
> * Timezone of Residence
>
> * Linux Background and Proficiency
> * Linux Flavors Used
> * Programming Experience
>
> * Ways You Would Like to Help
>
> Anyone and everyone who enjoys using Linux is welcome to join.
>
> And if you would like to participate but are unsure as to how to do so, let
> me suggest
> that collaborators can, initially at least, be of greatest assistance in:
>
> * Setting up a project homepage.
> * Setting up a mailing list or equivalent by which collaborators can
> communicate.
> * Helping to flesh out the project scope and requirements.
> * Drafting up a design document and work plan.
> * Creating a document & code repository on Github or similar.
>
> Come and join me in collaborating on a tool that's going to be the biggest
> revolution in
> Linux-box interaction since .inputrc got "history-search-backward"!
>
> Look forward to hearing from you!
>
> Yours Sincerely,
> Jarrod O'Flaherty.
>
Not really wanting to be a wet blanket, but your goals are way too
big. (And you aren't the first to suggest the idea, so you can look at
the successes and failures of past efforts to get some idea of why
you're going to get a lot of resistance on this idea.)
I do keep thinking it would be nice to have the wikis more up-to-date
and more complete and more accessible. If I have time, I think I'll go
support those first. Hope you don't mind.
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart.
Reply to: