hansvb

Recent comments

• Desktop *nix Users Find No Solution in OS X

  What is the difference between Linux and Windows? Answering this tells you what OSX is
  I will keep this short since this comparisment tends to...

  I think the principle difference between Windows and Linux is that Linux is designed with technical motives. Windows has been designed on comercial motives. One has a solid basis, the other has a glossy cover. Just follow the money stream and then tell me what OSX is and if you like it.

  I think Linux and Windows-XP are extreme opposites in this respect.

  Linux devellopers, please don't start copying the behavoure of Windows i don't need Linux in bullshit-mode, I don't want shiny buttons. I just want to get the job done without the need for sunglasses :o)

• A Solution to the Problem of Configuration in Linux

  importance of a standardised data structure
  
  Introduction

  This doc is a reply on http://freshmeat.net/articles/view/565/. Please note that i recognize and agree on the concerns that you have on the linux way of configuration.

  
  In short i would like to express the importance of a standardised data structure. Also i think it is very impotant to contantly remind program devellopers to avoid unneeded complexity.

  
  I hope you understand my point below and find it a positive contribution.

  General

  
  In my percetion a configuration consists of three things:
  - A data structue

  - and a user interface

  - A application interface

  The data structure
  The structure

  About the data structure: We've seen two way's of not doing things, the windows registry and the linux way. Why are these a screw-up? Because the lack of a standardised structure. If you have a standardised data structure then your'e halfway, and, it doesn't seem that hard to do. Also it is not really importand how you do it, as long as it is standardised everybody can find whatever they need.

  
  Let me explain this. First you design a structure. The data has to be seperated into levels. f.i.

  Root, Vendor, Application, Data Group, Data Item, Value.

  By defining all elements of the data structure, app designers don't need to "invent" or interpret standards for them selves.

  The implementation

  As soon as the data structure is clear you can start thinking about the implementation of the data structure. (Design and implementation are relativily independend). The data structure can be implemented using several techniques:

  - Structured Text (Linux conf, Windows ini)

  - XML

  - Database

  The internal structure should be standised as detailed as possible and have freely available access tools.

  
  The database implementation f.i. could be mysql, a lichtweight, reliable and fast database. Discourage the use of "a different kind of database for each app", this really sucks. Even if mysql is to big for you, it will not be to big if you add-up a few apps. Other databases may be just as good. Important is that all apps use the same one whenever possible.

  Mixing implementation techniques

  It is very well possible to mix these techniques, however, a few things must be kept in mind:

  - The data structure may not be violated

  - The mapping from one implementation method to another must be standardised (Documentend)

  - Mixing implementation methods may make things more complex.

  - If data exists on multiple locations there must be a standardised way to keep data consistant

  Examples

  An example: A vendor called "AVendor" creates a program called "XApp". He could choose to do the following:

  
  /etc/AVendor/XApp/XApp.conf

  /etc/AVendor/shared/X.conf

  /home/bob/.etc/AVendor/XApp/XApp.sav

  or

  /etc/AVendor/XApp.xml

  /etc/AVendor/shared.xml

  /home/bob/.etc/AVendor/XApp.xml

  
  Suppose a certain vendor has a complex suite of applications and wishes to use a database. Then you could get:

  
  /etc/AVendor.database

  /home/bob/.etc/AVendor/XApp.xml

  Vendor?

  Vendor is used to be able to group certain applications. Examples of vendors are:

  - redhat

  - linux (or system)

  - mandrake

  - gnu

  - myapps

  
  A pitfall in choosing a vendor name is that f.i. redhad would put every app of his distribution in /etc/redhat. If someone later on dowloads an app then it would go in /etc/gnu. So i think that the data location should be determined by the app writer and not changed by a certain distribution.

  
  Only proper standardisation and documentation can prevent misinterpretation of the data structure design.

  OS dependent data

  What to do with os dependent settings. It might be usefull to give guidelines for this. Maybe keep the data separate, use standardised notation and translation.

  
  The user interface

  The user interface is a complex topic. Normally i would not say that the userinterface should be a representation of the data structure. In this case i think we should try to let the two resemble as much a possible.

  
  The configuration file datastructure should be a logical one that is easily understood. Not just a bunch of names and values in random order. In fact, these files are a (simple) user interface, otherwise they would be binary.

  
  What has been said about the data structure is also valid for the user interface. It is not important how you implement it, it is important that the way of using it is standardised. So if you see the data files themselve as the simpelest user interface it is logical that all "higher" user interfaces sould have the same structure but are easyer to use.

  The API

  Ehh... I don't have anything to say about this so I won't.

  
  Comment on "A Solution to the Problem of Configuration in Linux"

  
  I note that you are clearly focussing on a certain app while my focus is more to standardising the data and way of working. This is an important difference. I think a good app to manage the settings is a good thing but then again you may be overtaken left and right by others such as linuxconf etc. I think it is more important right now to get the basis right. The app you have in mind could be serving as a test to see if the data structure is choosen right.

  
  Also you are focussing on the use of text based config files. This is not in conflict with what i write, I even think this is good whenever this solves the problem, but my view goes further. If someone decdes he needs xml or a database then you've lost him. My proposal encourages to keep following the standard and use the same logics whithin those techniques and makes sure everyone can access this data.

  
  The three tier architecure.

  I think it is good to keep this topic in mind but having a widely accepted, standardized data structure is the first thing to worry about.

  
  You directory structure is flatter than what i propose. I think my structure has an advantage towards commercial software vendors. I think these should also enbrace our proposals.

  Further, you directory structure uses "deamons". I have learned that unix has only files and processes. A deamon is nothing more than a proces running in the background. Many of them can be executed as a normal app. I would try to match closely to the Unix philosophy and not try to determine a border between programs and deamons like windows does. You might get burned if you do.

  
  Configuration locations are not fixed: Arrrrrrrggh.... Of course they should be. The app should be able to read from other locations but there is a standard location that all Linux distrubutions use. If you deviate from that you sould better have a clear reason for it.

  
  Forms, Wizards

  No, I don't agree, the Windows registry is a complete mess that has partially been deliberately been made unreadable. This database has been written with comercial motives. I repeat, this is a screwup because of the lack of clearity towards its users. Of course, remarks in files are a big advantage but you can do that in a database too (the forms you mention) so there is no real point in discussing the implementation technique other than complexity and performance.

  Wizards

  To me the main task of a wizzard is

  - To give comment on each option

  - To hide advanced options

  - To prevent entering unrealistic values

  - To prevent conflics

  Please evaluate each wizzard on these rules. After using a wizzard you should get a working situation.

  Metadata

  The data should be based on standards. Be ware of the microsoft effect. Every dummy is going to add metadata to his setup. Look at what they do with the registry, every stupid program that needs 5 lines of data to init has reg entries and needs to reboot.

  
  We have 5 lines of defence against complexity

  Rule 1: Keep everyting as simple as possible, but not simpeler. (That quote's not mine)

  Rule 2: Clear data structures

  Rule 3: Logical configuration

  Rule 4: Documentation

  Rule 5: Documentation (Also document the setup data)

  
  You have to have a real complex program to need to use metadata. Use it only when this kind of complexity is needed. Many things can be done with straight forward configuration and documentation.

  Access Control

  Access Control should be clear. The current linux system puts user accessable data in the home dir and system data in /etc. This is straightforward and simple.

  
  Doing access control within one configuration area or even in one file wil cause more complexity so avoid making it fancy. If you need to go away from the linux file access rights then you end up with a database solution with rule based access. This confilcs with "Everybody should be able to use it" There's no such thing with rule based access controll.

  The bottom line

  Yes, redo the linux config but start at the basis. Standardise the data, then go to the app layer. Keep in mind that the data usually lives longer than an app.

  
  Be ware of inviting complexity. People tend to use what you offer them. I think there should be a clear statement about avoiding unneeded complexity and a few samples of how to configure simple and less simple programs.

  
  Greetings, Hans van Buitenen