Re: YaST2 for Debian (aka nYaST)
On пт, 2004-11-19 at 11:54, Carlos Perello Marin wrote:
> On Fri, 2004-11-19 at 10:47 +0100, Rumen Krasstev wrote:
> > On чт, 2004-11-18 at 18:26, Carlos Perello Marin wrote:
> > > On Thu, 2004-11-18 at 16:35 +0200, Rumen Krasstev wrote:
> > >
> > > [...]
> > >
> > > > In this meaning I thing for this project a team of 3-4 people and 6-9
> > > > months probably will be enough...
> > >
> > > I think that with such resources you can give to GNOME System Tools and
> > > the setup-tools backends the needed work to cover missing parts and that
> > > will be available easily for any Linux distribution instead of just run
> > > yast2 in Debian. Also, don't think you will get people that knows how to
> > > improve Yast if they need to know about that complex system. If they
> > > should learn that language you were talking about, add some extra months
> > > to learn it...
> > I agree, but the real problem is only the compatibility between the distributions - as I mentioned the architecture of YaST is
> > very modular - so probably (i hope) the efforts should be direct only to
> > the .scr files (where is the configuration files/paths).. These files
> > are simple and every person who knows what this module make (for example
> > every admin knows what and where samba server does) can easily modify
> > them to make compatible - for example Yast do all Samba settings in file
> > /etc/sysconfig/samba and the file format is the same as the original
> > smb.conf (I think), so only redirecting /etc/sysconfig/samba to
> > /etc/samba/smb.conf will be enough :-))))) Of course there is files that
> > have no analog in Debian but I don't think it will be so hard to make
> > some simple scripts for transforming for example /etc/sysconfig/timezone
>
> I don't see it so easy, but I'm not going to do the work, so it's your
> decision :-)
I'm not sure that I know all potential obstacles that I'll must pass
through, that's why I agree with you - probably it's not so easy :-)))
>
> > ..
> > The language that I mentioned is very simple - so this wouldn't be a
> > problem to write new modules - the problem is to know how the particular
> > daemon or technology works - for example the module bluetooth - you
> > should know how the bluetooth stuff works and after that to make a nice
> > looking interface (via YaST) to it...
> > About the Gnome System Tools I don't agree - their major task is
> > multiplaforming - every system that can start Gnome should be compatible
> > with Gnome System Tools - that's why there is only few modules -
> > data/time, user management, networks... More modules could make
> > incompatibility in other architecture...
>
> Not really, GST does not have more modules because it has a small number
> of developers (sadly, only one "full" time and some extra contributors),
> if you develop a module that only works on Debian it will not be
> rejected from GST, it just will ask for someone else to port it to other
> platforms.
I see.. I just thought that there is some potential modules which is so complex and
would be not so easy to implement in GST (as far as I'm not so familiar with GST) because they
(modules) are specific to some platform/distribution/os for instance... I can't explain it clearly,
but when I saw the YaST code I understand one thing - they made a lot of compromises with the freedom
(and yet, YaST was closed source 7 years) and flexibility in match to reach their aims -
as much as possible modules for all kind of configuration and administration tasks -
for example Debian's new partman (partition manager in the sarge installer) is multiplaform,
because it was made from the begining with such requirement, but for me it's really hard to make
graphical partition manager for all architectures that run GNOME on (YaST is only for i386)...
So, there is much more examples why many modules are really hard to implement into GST - what about management of RAID and LVM for example?
> Also GST is not only the GNOME frontend the idea behind it are the
> backends so it could be ported to KDE, Curses or whatever the user
> wants, so it's as modular as Yast.
>
I understand this, but as I told to Carlos Garnacho, I thought about GST
as part of official GNOME distribution (it's my mistake, excuse me),
that's why I wrote such opinion before in the mail list..
Now I see that GST is really independent project, that is not necessary
to be "compliant at all cost" with GNOME. One more time excuse me :-/
Cheers
Rumen
---
Rumen Krasstev - Object Builder Software Bulgaria
Sofia, 113 Tzarigradsko Shose, phone: +359 2 974 33 16
web: http://www.obs.bg, email: rkrastev@obs.bg, icq: 35447386
###I'm using only free or/and open source software###
Share the freedom - "Free Software Association - Bulgaria" http://www.fsa-bg.org
---
Reply to: