Re: [Fwd: Re: YaST2 for Debian (aka nYaST)]
- To: email@example.com
- Subject: Re: [Fwd: Re: YaST2 for Debian (aka nYaST)]
- From: Carlos Garnacho <firstname.lastname@example.org>
- Date: Wed, 24 Nov 2004 01:58:43 +0100
- Message-id: <1101257923.3331.53.camel@filemon>
- In-reply-to: <1101252535.3331.5.camel@filemon>
- References: <1101252535.3331.5.camel@filemon>
On Wed, 2004-11-24 at 00:28 +0100, Carlos Garnacho wrote:
> It seems the chain error is going on :)
> email message attachment, "Forwarded message - Re: YaST2 for Debian
> (aka nYaST)"
> On Wed, 2004-11-24 at 00:28 +0100, Carlos Garnacho wrote:
> > Hi Carlos,
> > Am Saturday 20 November 2004 19:56 schrieb Carlos Garnacho:
> > > the worst
> > > obstacle I find for doing new modules is the lack of time/manpower, as
> > > for doing the tools portable, almost every UNIX has the same concepts in
> > > system administration, and the GST can do a good job abstracting such
> > > concepts (for example: the services tool configures successfully sysV,
> > See... the workload and maintanablilty plays quite a role here ;-)
> > Abstracting those concepts directly in the code apparently works nice due to
> > the frontend/backends separation.
> > Now, if the backends could also abstract out the syntax (inheritanble parsers)
> > and semantic (config description files) it could be much easier to extend and
> > maintain the config tools.
Yes, It could be easier but also much less intuitive and user-friendly,
user-friendlyness also has a really important role if we're trying to
make a competing desktop based in Debian, and I think that the users
will thank us if we make a bigger effort than showing self-generated
GUIs with the almost raw configuration inside.
Excuse me if I'm wrong
> > Granted it requires also work to implement such an abstraction, though at
> > least a prototype seems to be there.
> > I think we already talked about that in a thread about GST using Config4GNU
> > concepts though, right? :)
> > Cheers,
> > Christian