Re: YaST GPL'ed

On Thursday 25 March 2004 21:07, Kévin 'ervin' Ottens wrote:
> Le mercredi 24 Mars 2004 08:57, Simon Edwards a écrit :
> > For the love of god, pull a 
> > script style language of the shelf; we have plenty of them in OSS-land, 
and
> > use it.
> Since YAST is an old project now... I'm convinced that they didn't find 
> something suitable at that time. ;-)

Yes, but we are talking about Yast *2*. =)

> Maybe we should take carefully a look at the exact goal of this language... 
> it's strange that someone develop something like this from scratch as you 
> pointed out. There's two reasons here :
> 1) we've missed something subtil,
> 2) they have done this wrong just for fun ;-)

If the language was based on something that wasn't so common as C, then maybe 
I might suspect that they had a really different (and good) solution to their 
problems.

Another FYI, look inside the code of the Debian menu system. You know, the 
meta-menus system that takes little menu files, chews on them and spits out 
menus for KDE, Gnome, fvwm etc. Guess what. Instead of just using a script 
language and saying to everyone else "Hey, if you want extend this to support 
your XYZ desktop, crack the source open and subclass Foobar", people like to 
make up their own mini-language. Why?! So people won't get offended with 
their choice of language?

> > > I have a strict frontend-backend architecture. The backend can run as a
> > > XMLRPC-daemon so that remote control and different frontends (even in
> > > other languages and toolkits) are possible.
> > I think that is probably overkill, but anyway...
> I disagree completely from this point. I've looked at both tools... From the 
> UI point of view I prefer yours (with a big plus since it uses kcm). But, 
> from the architecture point of view I clearly prefer Henning's one (even if 
> it's a little rough and slow... it can improve IMHO).

I'm not convinced that it is so important. At least for a version 1.0 it is 
better to keep things simple and concentrate on making a good set of tools 
that work on one machine first. Choose your tools wel and use good software 
engineering and then extending it for remote/RPC stuff later shouldn't be 
such a big deal.

Now, what would you want to do remotely?

* Users and Groups? nope, => you would set up LDAP and kerberos instead.

* Network settings? nope, => DHCP, and if DHCP won't handle it then you 
probably can't do it remotely anyway.

* Backups? nope, => network file server.

* Date and time? nope, NTP.

Remember, Webmin is already here and working, and it platform agnostic.

I'm not saying the you wouldn't want to do stuff remotely, just that it would 
be a good idea to write down some "use cases" of the idea.

> For now, I don't have a clear opinion to the path to follow (YAST or your 
> tools). But, it would be a very good thing to avoid duplication of effort 
and 
> merge your approach and Henning's one... in this case we can have the best 
of 
> both worlds.

It should become clearer once we write down what tools we want and what we 
already have.

For some good news. I've been playing with the redhat tools and have had some 
success with getting them to work on Mandrake. There seems to be a fair bit 
of overlap functionality-wise with stuff already in kcontrol. Stuff like 
keyboard, date and time etc. It looks like I can plunder a fair amount of 
backend code and such. I'm also kind of wondering how important being able to 
tweak your hardware settings are these days; I'm running Mandrake 10 here and 
I don't remember seeing much about hardware during installation. It Just 
Worked.

cheers,

-- 
Simon Edwards             | Guarddog Firewall
[email protected]       | http://www.simonzone.com/software/
Nijmegen, The Netherlands | "ZooTV? You made the right choice."