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

[Fwd: Re: YaST2 for Debian (aka nYaST)]



It seems the chain error is going on :)
--- Begin Message ---
On сб, 2004-11-20 at 20:56, Carlos Garnacho wrote:
> Hi,
> 
> 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
> > ..
> 
> That's a quite easy example, but porting yast2 to debian will bring
> bigger headaches than that :)
Definitely :-))

> For putting some examples I could mention the network configuration or
> the services that run at start time (quite similar to sysV, but not
> equal), those also rely on their own tools that even don't let the users
> modify the config files by hand, which IMHO is bad.
That's right, but as I mentioned in the mail to C. Gatzemeier in the
mail list - that is because of totally different "view" of how should
things works between Debian and all commercial distributions - we can't
avoid this during porting every tool, specific for SuSe or Fedora or
Mandrake for instance..

> 
> > 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...
> 
> Sorry, I don't agree, as the GNOME System Tools maintainer, 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,
> bsd, filerc, rcng and gentoo init types, and the boot tool does the same
> with lilo, grub and yaboot).
Excuse me and sorry for misunderstanding, I just have feeling that I remember a mail in GNOME devel mail list, which 
describes why GNOME rejects to include GST in official distribution before time (I think in 2.5/2.6 or 2.3/2.4)... 
Probably I'm going wrong but I've feeling that the reason was some modules of GST which didn't work properly at 
all platforms. That's why I though like that...Furthermore there is only
basic modules (great implement I think - excellent work) because there
are serious differences between software availability in different
architectures (for example one of most wished graphical tool for the
masses - the firewall - how would be possible to implement for all
architectures that GNOME runs on?).  I agree of all that you mentioned,
about system administration, but we talk about much more modules (86 in
YaST) for much more purposes... Let me say that I'm not so involved in
GST and excuse me if I'm going totally wrong :-))) I hope you would
explain to us these things, because they are very interesting and GST
for me is the only one (not web based) real multiplatform configuration
tool for now :-))))

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


--- End Message ---

Reply to: