[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a comment [COAS]



Nick Mathewson wrote:
> 
> So let's take a look at COAS and Linuxconf themselves, and see if
> either of them looks as though it may turn out to be what we want.
> I'm currently impressed my Linuxconf's current versatility, but much
> happier with COAS's clean API and archetecture.
> 
> Let's evaluate these tools on their own merits, and not on the
> perceived motivations of their developers. :)

I've been on the Linuxconf mailing list for about a year.  About 6
months ago, I think, Jack posted a notice that he and COAS were working
together in some mannor, I don't remember the details, and basically
Linuxconf was going to take the place of COAS.  Evidently they felt that
Linuxconf had enough of a head start that it would be smarter to work
with Jack on integration than to start from scratch.

I'll post a message to Jack and ask him if this went TU or if it's still
the plan.

As a side note.  If COAS and Linuxconf have decided to remain seperate,
we should tip the scales more toward the end-user than the programmer. 
I realise it may benefit the end-user in the end if it's easier to
program modules, but unless it's a huge difference I would vote for the
versatility over the API in the interest of the project goal.

Linuxconf has already become a somewhat heavily used tool by sysadmins
and ISP's around the world.

His biggest problem is that he doesn't like Debian.  He won't come out
and say it as such, but he thinks sysv is outdated and a rediculous way
to handle runlevels as opposed to Linuxconf's aproach.  And Debian
wouldn't put Linuxconf in officially so he wasn't going to break his
back to make it 100% compatable.  He loves Red Hat though.

Maybe if we aproach him he'll be willing to work with us on
compatability issues and such.  

Should I ask, or would an admin leader rather handle that?

-- 
L8R,

Rick Jones
rickya@siservices.net
===
SEUL-Leaders list, seul-leaders-request@seul.org
===