Re: ARK/Arusha Core Competence

Steve Traugott asks:

> ... how you would characterize [ARK's] scope or
> coverage...

Jonathan's answer is an excellent one: "... I find it useful
to think of Arusha as more like a systems administration
programming language that just happens to borrow syntax from
XML, Python, and sh."

I.e. in its heart of hearts, the Arusha Project doesn't
address and doesn't want to address *any* of the issues that
you mention... directly.  (For example, it is an
embarrassment, really, that we've written much of a
multi-platform package manager, but that's only because
nothing else is there yet.)

In a perfect ARK world, people will put together solutions
with other specialized tools (including some or all of the
ones that you mention) and *express* them in ARK-speak.
Others will then be able to pick up and build on those
ARK-expressed solutions.

Our distinctive contributions are:

- We give a way to talk about *all* of the things involved
  in sysadmin, not just packages and hosts; so, for example,
  I checked in code yesterday to help manage purchase orders
  and support calls... (NB: profoundly incomplete :-)

- *Collaborative* sysadmin is our thing.  By setting up your
  teams and objects appropriately, it's fairly
  straightforward to do site-specific, or company-wide, or
  world-wide things.  An example of the last is the Sidai
  team's 'GNU' proto-package: it captures once-and-for-all
  the './configure && make all && make install' pattern that
  we all know and love.

- We are more policy-agnostic than most sysadmin things.
  The ARK machinery lets you do *hopeless* sysadmin, if you
  like :-)

- Our target audience is the 1-4 overworked-and-underpaid
  sysadmin shop, who simply do not have the resources to
  figure it all out for themselves.

That's the end of the "proper" answer; I'll add a few
comments on the matters you raise.  (I am now wearing my
Sidai team hat...)

> Which of the following problem domains do you see Arusha
> addressing more directly?
> 
> 	- third-party package builds and deployment,

We've reluctantly written stuff to do this; but only because
we weren't too happy (perhaps incorrectly) with stuff out
there, in a *multi-platform* context.  In particular, I
looked really hard at RPM and at Zoularis (a thing to make
Solaris do NetBSD packages).

It should be Really Quite Straightforward to write ARK
veneer on any such tool, and I'd love to see some of that.
If, for example, the www.openpackages.org stuff comes along
well, I'll drop our stuff in a heartbeat.  (But the
interface will still be: 'ark package reveal ALL'.)

> 	- operating system configuration, like cfengine

We have some code to do this in Sidai land; see the *-config
packages (instances in `glasli1' team, support code in
sidai).  Again, I'd love to see a good cfengine or PIKT (or
...?) solution expressed in ARK-speak.

> 	- operating system completion and maintenance, ...

Don't have much of such stuff sitting around (yet).  I've
always kinda thought that "the OS+system from the vendor"
would simply be another ARK package.  So, for example,
'ark package update vendor-os-and-system' would do what you
expect, appropriate to each site/host-type.

> 	- bare-disk, initial formatting and installation of an
> 	  operating system, ...

Have done nothing about this; am prepared to believe
Jonathan that this could be expressed ARK-ishly.

If you're making a list of categories, you might want to
add:

- System monitoring (are the services that are supposed to
   be up and running really up and running, and are they
   healthy and happy?)  Security monitoring, e.g., intrusion
   detection may be part of this, or a diff category...

- Performance analysis (where are the bottlenecks in our
   present system, and where [consequently] should we spend
   next year's capital budget?)

We have no story to tell on either of those (yet).

Steve, we appreciate your lurking on the list; thoughtful
questions like yours are helpful in steering a reasonable
course.

Will