On Thu, 2006-08-31 at 17:12 -0400, Steve Barnhart wrote: > Well Ok I'd like to some people for their actual dissection of what > the problems were. I guess I don't work in production environments > (not that Fedora is even for that??) and didn't realize so many users > hatrid of YaST. I've always found it pretty simple to use but maybe > that's just me. At least reasoning was given..hopefully the team can > atleast add some more system-config-* programs or something. For a living I teach Linux classes and write courseware, my customers ask that I know and cover both RHEL/FC and SLES/SL. Because of this I've gotten very familiar SUSE and YaST over the last few years. I run production servers on RHEL, SLES, Debian, and Solaris for the experience. General problems with GUI admin tools like YaST, system-config-*, and others * Only has the ability to configure a subset of the total functionality ** Advanced config using the tool is often to manual edits in /etc/sysconfig/ files which then get parsed and generate the real config. If I have to do manual edits to get the config I want, why not edit the real config file? * Increased complexity * Doesn't play nicely with, or overwrites, manual edits (usually the case). ** Wants to "take over" * Usually doesn't read the real config for authoritative configuration, but instead has a separate location (xml files, or /etc/syconfig/, or other). Good things about those tools: * Can automate in syntax typo free fashion large configuration changes, or changes that touch many files. For example. Setting up PPP, switching NSS and PAM backends and configuring them, X configuration. Specific problems with YaST (and SUSE configuration in general): * Is heavily plagued with the "config file used to generate another config" file disease. For example, on SUSE 9.3 and higher don't make any edits to /etc/sysctl.conf as they will be overridden by /etc/sysconfig/sysctl which is a YaST style sysconfig file that, of course, doesn't even allow to you specify all possible sysctl keys. * In order to YaSTify certain services you end up with major departures from upstream config style. For example, on my SLES10 box under /etc/apache2 there are 35 .conf files (I only have two in the conf.d directory) as well as /etc/sysconfig/apache2. * Very limited scriptability. Pretty much all of YaST is only interactive. On RHEL/FC boxes a many/most of the system-config tools can be executed non-interactively with switches, for example. system-config-keyboard --noui us * Doesn't encourage the K.I.S.S. principle when adding new features, software to SUSE as it is easy to "just write a yast module" to manage it. * Over engineering. For example, by reading the SUSE bash bootup scripts I've learned amazing scripting techniques that I would have not thought possible with bash and friends. It is obvious the SUSE developer(s) is brilliant, too bad that knowledge is used to introduce complexity instead of remove it. Of course this is my personal opinion and I'm a fan of the simplest solutions for a given problem. * When exiting YaST it re-generates all config files under it's control versus just the one you were working on. * Mixed case commands and odd directories like /sbin/conf.d/. Specific problems with the RHEL/FC system-config tools: * Lack of consistency. Is it --noui, --text, --nox, or system-config-command-tui? * Not a integrated modular system (which would solve the consistency problem). * Limited coverage of system configuration compared to competitors Good things specifically about YaST / SUSE: * Fairly broad coverage of system configuration. * Some cool modules. I like the full featured "Certificate Authority Management" module. Another interesting feature is the /etc/permissions* files, although it can cause false hits with rpm verify. * Automatic curses and GUI/QT interfaces available "for free" to module developers. * Ability to tell it "hands off" certain parts of the system, for example: echo "MAIL_CREATE_CONFIG=no" > /etc/sysconfig/mail. The above list is not complete. Just some things that came to mind. In my opinion porting YaST would be a lot of effort and for what? Naturally the whole YaST system has lots of SUSE specifics (see /sbin/conf.d) and by the time you pull those out what is left? A skeleton of a management framework that supports curses and QT. Would that effort be better spent on an integrated modular multi-interface system that followed the Fedora development philosophies from the get go? Dax Kelson Guru Labs -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
