Re: YaST GPL'ed

Simon Edwards <[email protected]>
Newsgroups gmane.comp.kde.debian
Message-ID <[email protected]>
Hi,

[Warning: rambling prose ahead.]

On Tue, 23 Mar 2004 11:29 pm, Henning Schröder wrote:
> > I've been working on some admin tools and will take a good look at YAST 
when 
> > it is made available. (I need to see if my efforts were just made 
> > obsolete. :-] )
> Yast was always available in source. But the code is not very useful. It
> uses its own interpreted C++/C-like language, it is very SuSE specific and 
it
> would take a lot of time and hard work to port everything to Debian. 

Well, I grabbed the source and I thought I would have a go at compiling it on 
Mandrake. Maybe I'm just a "learn the hard way" kind of guy. First impression 
"man there are a lot of packages!", immediately followed by "look at the 
dependancies on that thing". So after choosing a reasonable starting package, 
I hacked the spec file a bit and tried to build it. Needs something called 
sgmltools, Mandrake don't ship it. It appears to be published under a bunch 
of licenses of which I couldn't immediately see if they were GPL compatible 
or what. Anyway, I built that one too. Then needed something called 
liby2util, which also comes from SuSE and is under SuSE's license. It was 
trying to compile it... blah blah... to get to the point, it is a nightmare 
to compile, and I still haven't done it. I'll have a play with Yast on Fab's 
laptop next week.

I had a look at the source, and yes the rumours are true, then invented thier 
own mini-language. If you feel like you have to create your own programming 
language just to create what is basically a utility program, you should stop 
and think that maybe that is (god's|universe's|life's) way telling you that 
you are doing something wrong. For the love of god, pull a script style 
language of the shelf; we have plenty of them in OSS-land, and use it.

> > As far as admin tools and Debian are concerned, I think we need to 
catalogue 
> > what tools, config stuff, and utils we want/need, plus what we have 
> > available; identify where the holes are.
> Using several existing tools has a few disadvantages. In my opinion every
> tool should have the same look and behave the same. Code should be shared 
too.
> Here is my list of tools, which are essential:
>  * network (ethernet, dsl, isdn, modem)
>  * users
>  * date/time
>  * language/keyboard
>  * system services
>  * cron-jobs
>  * package management
> Later on tools for server apps should be added (Samba, Apache, Squid, Exim,
> DHCP, NIS, LDAP).

We real list can go up on the website, once it is organised a bit more.

> > There is also a good chance that YAST will become the de facto standard 
set of 
> > config tools for KDE based distributions, or that config-developers might 
> > unite behind YAST and work together on it instead of on other fragmented 
> > efforts. I guess we have to wait and see a bit.
> Hmm, I don't hope^H^H^H^H think so that Yast will become any accepted 
standard.
> RedHat's and Mandrake's tools are GPL for a long time now and nearly nobody
> from the free software community tried to adapt them.

Yes, but Mandrake's tools suck, I don't know about Redhat's (but theirs are 
GTK+ based I thought?)

> You might want to look at some current screenshots of my system tools:
>       http://home.cco-ev.de/~henning/gallery/

Are they are available for download anywhere?

> 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...

gotta run, day job calls.

cheers,

-- 
Simon Edwards             | Guarddog Firewall
[email protected]       | http://www.simonzone.com/software/
Nijmegen, The Netherlands | "ZooTV? You made the right choice."
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.