LinuxSA Mailing list archives

  From: Adam Smith <linuxsa@bugman.cx>
  To  : LinuxSA <linuxsa@linuxsa.org.au>
  Date: Tue, 1 Jul 2003 00:21:55 +0930

Re: (Clarification) Re: Some Proposals for a Linux of The Future (tm) :)

On Mon, Jun 30, 2003 at 11:18:13PM +0930, Damien Uern said:
> Hello,

Well Hi there!

> The separation of Administrator-modified configuration files and the default 
> files installed by the system makes sense to me. But having it in two totally 
> different locations doesn't, e.g. "/etc and /usr/local/etc". Forgetting about 
> Unix history for a moment and stepping outside of the box, if you were to 
> design the filestructure from scratch, where would you place these two 
> directories?

Because it's the history of Unix that has held it together as a scalable
operating system for so long.

And it makes logical sense to me.

/etc for your basic system config files that come with your operating
system,

/usr/local/etc for all the additional stuff you've added to the system that
doesn't come as part of the underlying model.  'man hier' and look up
/usr/local.

I agree that it can be sometimes confusing, for example:

/etc/named/named.conf
/usr/local/etc/dhcpd.conf

(Yes -- both services are fundamental to most networks, and while
named.conf is a file and a service included with a generic install,
dhcpd.conf is not, because it's installed, in freebsd's case, from the
ports.

> So here are my revised goals:
> 
> 1. Design a logical directory structure within the /etc directory.
>    - it must be fairly simple for somebody to look through that directory to 
> find something without resorting to "locate" or "find".

How?

Any sort of mixing together of basic configuration files and configs for
additional modules would take away the principles of the logical structure
that Unix has today.  The same principle exists right now for /bin and
/usr/local/bin.  Should we change that aswell?  /bin is for programs that
need to be run in multi or single user mode, and /usr/local/bin is used for
binaries for added on programs (because that's generally what your /usr
partition is for.)

It is only poor coding by some developers that make things inconsistent, or
a user's customized personal preference (for example, some users like to
store their applications in completely seperatated directories, including
all data, config files and libraries.)

> 2. Design a unified configuration file format.
>   - This format must be simple enough to be easily understood by somebody 
> without them having to refer to a manual

Some of what you say here is valid, because there are config files that set
options differently, eg:

-- from /etc/inetd.conf:
ftp     stream  tcp     nowait  root    /usr/libexec/ftpd       ftpd -l

-- from /etc/rc.conf:
defaultrouter="10.0.0.254"
hostname="host.domain.com"

-- from /usr/local/etc/wine.conf
;; Floppy Disk Drive
[Drive A]
"Path" = "/mnt/fd0"
"Type" = "floppy"
"Label" = "Floppy"
"Filesystem" = "win95"
"Serial" = "87654321"
"Device" = "/dev/fd0"

-- from /etc/named/named.conf

options {
        directory "/etc/namedb";
        pid-file "/var/run/named/pid";
	}

>   - All configuration files will have a common extension so they can easily be 
> seen as such (e.g: .conf).

There are a few exceptions to this, but you'll probably find that most
programs already use a .conf extension, and of those that aren't -- sloppy
programming, most likely.

> 3. Design a simple (probably xml-based) layout file that allows an application 
> to display (graphically) the configuration options for a program.

Most programs don't utilise a GUI interface because:

a) They don't run in a GUI environment
b) They have way too many options to display in a GUI
c) Their configuration files have extended attributes or macros which are
too difficult to display in a GUI
d) They are too short to display in a GUI
e) There's no point displaying them in a GUI because they are so straight
forward.

Are you proposing some sort of registry clone?

>   - The file format should be fairly easy to understand, but referring to a 
> manual in order to write one will be necessary (and possibly to read one and 
> understand it fully).

I suggest we use a text-based format for easy reading, easy parsing, and
easy portability from one platform or system to another.

>   - It should allow some interpretation by the GUI program so that all 
> configuration dialogs look consistent. The layout file shouldn't specify 
> things like "rectangle,200,200", but should just group configuration 
> variables and specify the type of value they take (like in a programming 
> language), amongst other things (such as a "display name", visibility, etc 
> etc). 

I like consistency as much as the next guy!

> I believe something like this could be done if it is managed in stages:
> 
> 1) Discourage hard-coding paths to configuration files so that configuration 
> files can be placed wherever the user pleases.

Above, you wanted a logical and consistent system that allowed us to not
have to use tools like find and locate.  Now you say you want us to be able
to put our configuration files anywhere we choose?

> Application accesses these files through a library "say libetc, or
> libconfig".

So that when we're on a slow link we have to use annoying tools that slow
us down.

> 3) Create layout file format and sample application that can parse the etc 
> tree and provide a GUI for config files that have an accompanying layout 
> file.

I think Microsoft have tried this a few times, and they got their Registry
Editor which is a most friendly application to get your head around, not to
mention navigate.

You may argue that once you get used to it, it's easy!  Sure, I know how to
find some things in there, but I still find Unix's structure a lot more
simplistic than a bloated and overly complicated GUI navigation tool.

Let's not forget they tried sysconf.exe aswell, which ended up just loading
several configuration files into editable windows (which seems logical to
me!)

Gnome2 have added a new registry-style configuration editor and I steer
clear of that wherever possible.

> 4) ???

???

> 5) Profit!! :)

!

> Somewhere in those stages the layout of the /etc directory and the format of 
> the configuration/layout files should be attempted to be made a standard 
> (LSB) so as to encourage people to follow it.
> 
> For all those that say "the current system is fine once you know it", I say 
> how does that make the current system the best possible? How can we make 
> progress if we stay stationary? (and if you say "if it aint broke don't fix 
> it", I'm going to scream :) It *IS* broke :)

Because it is scalable, and it makes logical sense.  Of all of the things you've
described, it seems that it's only the application developers who are
breaking the rules of where files should belong, and how they are laid out.
Maybe you should explain to them the importance of a logical file system?

I agree to some of what you have said, but certainly not all of it.

> 
> Cheers,

man hier!

Adam

-- 
LinuxSA WWW: http://www.linuxsa.org.au/ IRC: #linuxsa on irc.freenode.net
To unsubscribe from the LinuxSA list:
  mail linuxsa-request@linuxsa.org.au with "unsubscribe" as the subject