Re: Binary configuration files as panacea to whatever ails Linux(was: Re: the problem with LINUX)
Oron Peled wrote: So Allon presented one flaw in your assumptions and you came with a solution for this *specific* flaw... I don't have a solution. It was an example. I used words like e.g.. Did I say I had the scheme ready? Why are you trying to catch me on very specific _details_ instead of arguing about the idea/principles? My points are clear: 1. There is no standard config API in the Unix world 2. As a result, every application (or group of apps) implements a kind of the API itself, resulting in a huge duplication efforts. Very few have a decent one, most are primitive. Same is true for system-level apps, call them daemons/services/whatever 3. As a result, there is no well-defined scheme of storing system configuration data, resulting in a large number of redundant parameters which must be synced externally. There is no even a well-defined _place_ for storing the config data (/etc is full with non-config stuff and some config files are placed e.g. in /var) 4. As a result, there is no satisfactory (full functionality, same look-and-feel) configuration tools. The existing ones (YAST, Webmin,...) are essentially collections of independent modules When you code in C and the same few lines of code appear more than once, you extract it into a function. When the same #define is used more than in one module, you extract it into a header file to make sure the definition is consistent across the application. Does anybody disagree these make a good coding practice? But is it special to C? Is it special to programming? Of course, not. Why shouldn't the same principles be applied to the configuration issues? Yes, the life is not easy and sometimes you do have two almost-identical functions (e.g. for performance reasons). But these are exceptions. Do you honestly believe that Unix has reached its usability peak? If not, why should the config stuff be an exception? Yes, the life isn't simple and will never be. But it's not a reason to not try to make it simplER. Regards, Evgeny = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Binary configuration files as panacea to whatever ails Linux (was: Re: the problem with LINUX)
On Tue, 14 Jan 2003 11:18:13 +0200 Evgeny Stambulchik [EMAIL PROTECTED] wrote: Why are you trying to catch me on very specific _details_ instead of arguing about the idea/principles? I just tried to show that the real world creates unique problems that would destroy the single config mechanism concept. My points are clear: long stuff about principles omitted ... Completely agreed. There *are* too many variants of the same idea and, due to historical reasons, many inconsistencies. So while I don't believe we can have one config mechanism, I do accept your assertion that we don't need 100 different ones either. I simply offered a strategy that may work IMO. Namely, collect current working practices and galvanize them through well designed API's. BTW: anybody (not just you) know the answer to my (irrelevant) riddle? [why the reboot(8) command need to have a disasterous -n option] If no one answer, I'll have to publish the solution Oron Peled Voice/Fax: +972-4-8228492 [EMAIL PROTECTED] http://www.actcom.co.il/~oron Reality must take precedence over public relations, for Mother Nature cannot be fooled. -- R.P. Feynman = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Binary configuration files as panacea to whatever ails Linux(was: Re: the problem with LINUX)
Oron Peled wrote: I simply offered a strategy that may work IMO. Namely, collect current working practices and galvanize them through well designed API's. Actually, it doesn't seem to me an impossible task to find a common denominator (in the sense of API). Indeed, the three widely used types of configs: a) the list of key=value pairs (= may vary, e.g. : or just blank space) b) ini-style c) tree are just subsets of XML (a is level-0 and b is level-1 tree), so the only non-trivial things are configs requiring a kind of pre-processing (e.g. cpp for Xresources). BTW, if there are people who are _serious_ about this project, I suggest a physical meeting for an initial brainstorming (I'm rather pessimistic about mailing lists for this purpose). BTW: anybody (not just you) know the answer to my (irrelevant) riddle? [why the reboot(8) command need to have a disasterous -n option] If no one answer, I'll have to publish the solution [replied privately so not to spoil everybody else's findings ;-)] Regards, Evgeny = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Binary configuration files as panacea to whatever ails Linux (was: Re: the problem with LINUX)
On Mon, 13 Jan 2003 02:55:10 +0200 (IST) Tzafrir Cohen [EMAIL PROTECTED] wrote: The programs provided the API that was originally needed: |lpr Evgeny does have a point in that some applications need a lot more control than just submitting a job (e.g: display a list of printers, listing the characteristics of specific printer [paper type, etc.], locating the closest priner [LOC comes to mind...]) non of this type of config is easily accessible from the conventional print spoolers. Also: xml still doesn't allow me to easily: *font: fixed In this example it does. The correct way to implement this in XML is via an XPath/XQuery expression [which should be against the available fonts]. I completely agree though that syntactically the XML et-al are far worse than the elegant XResources syntax. This is because XML assumes a tree structure, and this wildcar below applies toall leaves wirt the name font. So you see: a tree schema doesn't always work... Agreed (although the previous example didn't demonstrated it). And I still don't l;ike the current gconf: it requires an extra daemon Worse! IIRC it's an extra daemon *per user* Also, replying to Evgeny: Having a standard and powerfull config mechanism is a GoodThing(tm) However, some config files in Unix/Linux are actually code (e.g: shell scripts, .emacs) which obviousely are more general than any config scheme you may come with. If the proposed config mechanism is very general, it would bloat simple applications and their authors (justfully) won't use it. I do accept your observation, that in *many cases* there was no good reason to invent yet another poorly engineered config mechanism. I would suggest though, that a more realistic goal should be to *minimize* the number of different config types. For example: - A linear key=value pairs (e.g: INI files) - Hierarchic config (e.g: static XML) - Dynamic config (e.g: Registry/gconf) - Inherited config (e.g: environment variables) - where do I fit Xresources? - ... others So we may try to converge to some best-of-breed API in each category. Some categories may even need alternative selection due do special constraints: - On small footprint systems you trade flexibility for footprint. - Some maintenance modes (e.g: single user) may force you to manual config, so you cannot depend on running config deamons (gconf, *SQL, etc.) So you may want both full-blown API and a minimal-API for the same category (similar to glibc and dietlibc). Oron Peled Voice/Fax: +972-4-8228492 [EMAIL PROTECTED] http://www.actcom.co.il/~oron Code Red, Blue or Green there all a symptom of a far more pervasive and insidious virus, it costs around $200. -anonymous = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Binary configuration files as panacea to whatever ails Linux (was: Re: the problem with LINUX)
On Mon, 13 Jan 2003, Evgeny Stambulchik wrote: The smart configurator can tell you if you have made an error in configuration, but it really does not allow any action: if any configuration requires some synchronization between two config keys, Never! There should never be a need to sync two different keys! Continuing the hostname example, it should be defined in a single place, e.g. local_machine-network_settings-hostname and all scripts/daemons/apps that need the value should access it instead of duplicating the data in their specific config sections! Can you imagine ServerRoot defined more than once (for the same virtual server) in the Apache config? Wouldn't it be a nonsense? But the same nonsense is defining server's hostname separately in sendmail's, httpd's, you name it configuration files. Wrong! My host has tens of different hostnames, also a host might have several IP addresses. Every application needs to know under which hostname it is working. For example, httpd will show a different page as different hostnames, and the mail daemon will serve different mailboxes for different domains. Alon -- This message was sent by Alon Altman ([EMAIL PROTECTED]) ICQ:1366540 The RIGHT way to contact me is by e-mail. I am otherwise nonexistent :) -- -=[ Random Fortune ]=- Very few profundities can be expressed in less than 80 characters. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Binary configuration files as panacea to whatever ails Linux (was: Re: the problem with LINUX)
Oron Peled wrote: And I still don't l;ike the current gconf: it requires an extra daemon Worse! IIRC it's an extra daemon *per user* So what? It's a reasonable solution for this kind of problem. In KDE, there is DCOPServer and a bunch of others running per user. ssh, when used properly (i.e. _easy_ access of several hosts with _strong_ authentication) requires the 'ssh-agent' daemon running per user. Why don't you rant on ssh implementation? Is it the word daemon that worries you? Yes, if it dies, bad things may happen. But same is true for e.g. xinit which is not a daemon. Why should it die in the first place if correctly implemented? Also, replying to Evgeny: Having a standard and powerfull config mechanism is a GoodThing(tm) However, some config files in Unix/Linux are actually code (e.g: shell scripts, .emacs) which obviousely are more general than any config scheme you may come with. The solution is to provide hooks for external interpreters. Just like server/client-side scripting is for HTML, I can imagine procedures executed either by the config daemon or the application itself. If the proposed config mechanism is very general, it would bloat simple applications and their authors (justfully) won't use it. Very general doesn't mean bloated. The extensions are proveded via plugins and should be never exposed directly to the client. There is JavaScript available for HTML, but if I'm scared to learn it doesn't mean I can't use static HTML. The fact that there are a hundred Apache modules available (including those of alpha and beta quality) doesn't mean I should be afraid using Apache. I just don't load unnecessary/unreliable stuff. I do accept your observation, that in *many cases* there was no good reason to invent yet another poorly engineered config mechanism. I would suggest though, that a more realistic goal should be to *minimize* the number of different config types. For example: - A linear key=value pairs (e.g: INI files) - Hierarchic config (e.g: static XML) - Dynamic config (e.g: Registry/gconf) - Inherited config (e.g: environment variables) - where do I fit Xresources? - ... others Of course, the limit of minimization of a natural number is 1 ;-). Seriously, it's not the number of configuration formats that worries me, but the fact that there is no well-defined API to deal with them at the basic OS level (i.e. no other dependencies than libc). This causes the present situtation when a given application implements a config API internally but don't export it and a GUI config tool author has to re-invent the wheel. But since re-inventing the wheel isn't an exiting task (especially as far as parsing a custom config format is concerned), he usually decides to either abandon the parsing at all (one-side mapping) resulting in any changes done either manually or by another tool silently lost or does implement it partially which works for (in the best cases) majority of the options but anything beyond that is either again lost or makes the tool crash/misbehave. So we may try to converge to some best-of-breed API in each category. Some categories may even need alternative selection due do special constraints: - On small footprint systems you trade flexibility for footprint. - Some maintenance modes (e.g: single user) may force you to manual config, so you cannot depend on running config deamons (gconf, *SQL, etc.) So you may want both full-blown API and a minimal-API for the same category (similar to glibc and dietlibc). Right. But notice that an application that compiles with dietlibc should compile/work nicely with the full-blown variant without even noticing. Regards, Evgeny = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Binary configuration files as panacea to whatever ails Linux (was: Re: the problem with LINUX)
Alon Altman wrote:
Never! There should never be a need to sync two different keys! Continuing
the hostname example, it should be defined in a single place, e.g.
local_machine-network_settings-hostname and all scripts/daemons/apps
that need the value should access it instead of duplicating the data in
their specific config sections! Can you imagine ServerRoot defined more
than once (for the same virtual server) in the Apache config? Wouldn't it
be a nonsense? But the same nonsense is defining server's hostname
separately in sendmail's, httpd's, you name it configuration files.
Wrong! My host has tens of different hostnames, also a host might have
several IP addresses. Every application needs to know under which hostname
it is working. For example, httpd will show a different page as different
hostnames, and the mail daemon will serve different mailboxes for different
domains.
OK, so the config should be more complicated. E.g.
local_machine-network_settings-virtual_hosts[]-hostname. And then apps
should refer (probably by id) to a relevant element(s) of the
virtual_hosts[] array. See how this is done in fwbuilder - which is a very
nice example of proper configuration interface. You define an object once
and then refer to it in several places (even for different firewalls), so
if e.g. the DMZ mail server for a reason changes its IP, you change it
only in the single place.
My point is simple: there should be NO redundant definitions of config
parameters relevant for a given object. This rises no objections when the
object is an application, but for some reason people start to get nervous
when talking about the OS as a whole (or probably even about a domain of
computers). When I do find /etc -exec grep `hostname -s` {} \; on our
workgroup server I get 8 counts, and that's without /var/named and
probably a couple of other places. Is it normal?
Regards,
Evgeny
=
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word unsubscribe in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
Re: Binary configuration files as panacea to whatever ails Linux (was: Re: the problem with LINUX)
On Mon, 13 Jan 2003 18:09:41 +0200 Evgeny Stambulchik [EMAIL PROTECTED] wrote: Wrong! My host has tens of different hostnames, also a host might have several IP addresses. Every application needs to know under which hostname OK, so the config should be more complicated. E.g. local_machine-network_settings-virtual_hosts[]-hostname. And then apps So Allon presented one flaw in your assumptions and you came with a solution for this *specific* flaw... My point is simple: there should be NO redundant definitions of config parameters relevant for a given object. The world *should* behave as you just described, but... This rises no objections when the object is an application, but for some reason people start to get nervous when talking about the OS as a whole Because an application has (hopefully) very specific domain and scope, while an OS doesn't. Anybody who administered systems in real life knows that many times the unthinkable is the only reasonable option. A short example to make myself clear: Unix/Linux has a '-n' option to reboot that prevent syncing the buffer cache before reboot. Obviously this option would corrupt the mounted disks. Why is such an option needed? (and we are talking way before journaling filesystems :-) The answer is very simple (left as an exercise) and illustrate how real life sometimes force us into less than optimal solutions. Applying a logicaly closed solution to systems management problems has failed time after time. I think one of the reasons Unix survived for 30 years is the avoidance from over-engineering -- there's too much diversity and too much complexity. So your earlier suggestion about minimizing the config types to 1 is naive in my view. What is *realistic* to achieve IMHO (and still not easy task) is to try and encapsulate the known best practices -- i.e: - use the existing solutions as blueprints for what works (and what doesn't) in real life. - Fold all semantically equivalent solutions into a canonical solution for this class of solutions. Oron Peled Voice/Fax: +972-4-8228492 [EMAIL PROTECTED] http://www.actcom.co.il/~oron Those who do not understand Unix are condemned to reinvent it, poorly. (H. Spencer) = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Binary configuration files as panacea to whatever ails Linux(was: Re: the problem with LINUX)
On Sun, 12 Jan 2003, Eli Marmor wrote: I didn't want to detail too much in the point of CONF files, because it was not my main point. But it caused some balagan, so please let me give an example of a format that is not proprietary, and on the other hand is not XML, and still is great for developing GUI's for: X Resources. Does it threat anybody? No?OK; Let's go on: I believe X-Resources is a text file that is editable by hand. Not that I like it much. There are several requirements that are critical for creating a good GUI. One of them is the ability to work against a working program, and not just a file. Because you can't just open the file, guess all the values of ifdefs, the default path (for includes), the directory that the opedning program is in during the open, etc. When you are working against a working program, you know its current run-time values of these resources. In addition, it allows you to affect its CURRENT behavior immediately, resulting in a WYSIWYG that is so important for GUI (think editres; don't think UIM/X). Affecting a program at run-time? I don't want to affect crond at run-time or inetd at run-time or even Apache at run-time. I want to configure them, and run them with the same configuration. If you want to create an Apache Module that will listen to requests and with some authentication be able to configure the entire Apache at run-time and change it in the configuration file be my guest. I am content with reloading or restarting Apache whenever I make a chage. Of course, you need a bidirectional mapping (i.e. not only from the disk representation to the in-memory representation, but also vice- versa); Otherwise, the changes can't be translated to rules of configuration files. You need clear definitions; Not definitions that may start anywhere in the line, withany number of leading/trailing spaces/tabs/etc. that you never know which are part of the value and which are not, with leveling that is based on semi-XML directives (/directory /), with ambiguous comments, with ifdefs that you never know if theleveling that is hidden by them is really hidden - or only the rules inside those levels, with too many ways to say yes (e.g. tRuE, oN, falling back to the default, etc.) and so on. There are many other formatting issues that ease or harden the ability to develop a good GUI. Granted. That why I suggested an abstraction. Something that will generate an Apache configuration. If you modify the abstraction using the abstraction-specific tools. If you modify the Apache configuration files directly, that may be lost after you use the abstraction again. No 1-1 mapping, rather a subset of functionality. Of course, Ira complained on iglu-web that Suse's YAST 2 did not take into account changes he made to the configuration files manually and kept running over them. The Mandrake system is less balantly leaky and actually reads stuff from there. If you want to supply a subset of functionality to a newbie user using an abstraction do so. But a power user would want the real and complete configuration scheme. From my impression, the configuration of IIS was much more limited in consideration to Apache's. I could not even get it to serve a certain directory on a different port with its GUI. That was a few years ago. The reason I wanted it was because I had a script that that was only supposed to be internally used by our team, and there was a web-site hosted on that server. X Resources, contrary to ASCII CONF files (like Apache's or NAMED), meets all these demands. Of course, it is not so friendly, but when you have a great GUI - who cares?It is still friendly enough for hackers like us. Will this migration happen? No way; People develop Open Source for their own fun. Or for their own use (for example, most of the core developers of Apache need it for their own sites). When there is a company (please don't force me to spell the name of Redmond's companies) behind the product, they have balls (sorry for the word...) and don't give a sh*t (sorry again) on their users, so they can replace formats whenever it is important for the evolution of their product. Of course, there are also negative cases, so please don't give examples that Microsoft (sorry) abused this process and replaced a good format by a bad format or broke the compatibility of a program that was used by 100 million users. But when the users developthe program, there are some things that they would never do. Some of these things are bad, but improving the format is sometimes good and needed. I don't understand if you consider the MS way or the UNIX way the better one. In any case, XML-based formats or Perl Nested Data-Structures give way to easy extensibility. (look at HTML for instance) But XML tends to be hard to maintain by hand. P.S. Many years ago, I developed a great GUI for X. You could take even a binary program, and change its screens,
Re[2]: Binary configuration files as panacea to whatever ails Linux (was: Re: the problem with LINUX)
Eli Marmor [EMAIL PROTECTED] wrote: X Resources. Does it threat anybody? No? OK; Let's go on: There are several requirements that are critical for creating a good GUI. One of them is the ability to work against a working program, and not just a file. Well, this has nothing to do with the configuration file format itself. It's a communication protocol provided by the X/editres API (libXmu). But it's indeed very important for a configuration _programming interface_. Unfortunately, the X people didn't realize that the pathetic lack of standard configuration API in the Unix world that had driven them to create the Xresources infrastructure from the scratch was worth extracting it into a separate, X-independent API library. Of course, you need a bidirectional mapping (i.e. not only from the disk representation to the in-memory representation, but also vice- versa); Otherwise, the changes can't be translated to rules of configuration files. Right, and the lack of these features (actually, the lack of decent API providing them) distracted many even pure-X apps from solely using it; instead, they load/store their configs from customly-formatted .rc files. You need clear definitions; Not definitions that may start anywhere in the line, with any number of leading/trailing spaces/tabs/etc. that you never know which are part of the value and which are not, with leveling that is based on semi-XML directives (/directory /), with ambiguous comments, with ifdefs that you never know if the leveling that is hidden by them is really hidden - or only the rules inside those levels, with too many ways to say yes (e.g. tRuE, oN, falling back to the default, etc.) and so on. There are many other formatting issues that ease or harden the ability to develop a good GUI. GUI is important, but it's nothing compared to the API. I don't care about the specific format of the configuration _storage_. Let it be a plain ASCII or XML file or any binary one (not a propriate, of course). Do you care about the data storage format when comparing e.g. MySQL vs. PgSQL? Of course, not. Does it worry someone that the data format is binary? Of course, not. Well, a data dump (to an ASCII file) utility is a must - for the backup purposes etc, but that's all. I need the well-defined API and its C implementation. Whatever complicated/non-trivial format is choosen, the efforts of parsing it are spent only once. From there on, everything is simple. The GUI config tool will use the API, too. C++/Perl/Python/etc bindings are trivial. Look at CUPS. Nobody (except those involved in its development) cares about the format/structure of the CUPS config files. They provided the API. Period. Then somebody wrote the Qt/CUPS widget, and now any Qt application (read - programmer) get the whole selection of printing options provided by CUPS with zero efforts spent. Compare the situation with lpr friends. There is no API for parsing (let alone changing) the rather primitive /etc/printcap file format. And then come sysv lp, lprng,... each with its own config files and each with NO C API! As a result - how many non-cups-bound applications can you count which provide the list of printers present? Very, very few and far between. Even overloaded monsters like Netscape dare not implementing it - taking into account the variety of existing printing systems. People develop Open Source for their own fun. Or for their own use Why, it's not Open Source related. It's a common Unix malady - the absense of a kind of a centralized patronage (like W3C is for Web) during its development. As a result - the lack of well-thought and -implemented APIs for everyday's tasks. Configuration is just one of many. When there is a company (please don't force me to spell the name of Redmond's companies) behind the product, they have balls (sorry for the word...) and don't give a sh*t (sorry again) on their users, so they can replace formats whenever it is important for the evolution of their product. The Company-Which-Is-Not-To-Be-Named did just what X programmers did - developed a configuration API. And so Gnome developers did, BTW, with their quite decent GConf API. The only difference is that Microsoft happened to be a force behind an _OS_, while Xconsortium worried only about X applications and Gnome people worried only about Gnome applications, so the configuration API provided by X is of no use to non-X apps and GConf, as nice as it is, is useless to non-Gnome developers, KDE people did something for KDE apps only etc. And there was/is no father to worry about Unix as a whole, inspite of rich commercial vendors. That's the sad fact. Hence the current situation with multiple duplication of efforts with no satisfactory results. Many years ago, I developed a great GUI for X. You could take even a binary program, and change its screens, widgets, add more dialogs/forms/screens, etc. Fully WYSIWYG, of course.
Re[2]: Binary configuration files as panacea to whatever ails Linux (was: Re: the problem with LINUX)
Shlomi Fish [EMAIL PROTECTED] wrote: Affecting a program at run-time? I don't want to affect crond at run-time or inetd at run-time or even Apache at run-time. I want to configure them, and run them with the same configuration. If you want to create an Apache Module that will listen to requests and with some authentication be able to configure the entire Apache at run-time and change it in the configuration file be my guest. Yes. And another one will do it for ssh. And yet others will do it for applications X, Y, and Z... duplicating the efforts. This is a short-sighted approach. I am content with reloading or restarting Apache whenever I make a chage. So some are content with restarting the whole computer (probably several times in row) just for installing an audio driver. Don't you see a parallel? What is OK for a home desktop is unacceptable for server. Reloading Apache serving static contents is no big deal, but if it's coupled with a DB machinery involving complicated lengthy transactions, this may be very serious. And how about restaring X server killing all your running apps just to alter the font path or bell volume? That why I suggested an abstraction. Something that will generate an Apache configuration. If you modify the abstraction using the abstraction-specific tools. If you modify the Apache configuration files directly, that may be lost after you use the abstraction again. Hence, this approach is wrong. Webmin, LinuxConf, YAST, DrakeConf, you name it. Huge duplication of efforts and _none_ of the above working properly. You need an API (abstraction) that will both generate AND parse the configuration. Moreover, the Apache itself MUST use this very API. And all other servers and applications. Throw in replication and remote access protocol and that will be the sysadmin's paradise... And no, I don't mind it sounds like Active Directory. Regards, Evgeny = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re[2]: Binary configuration files as panacea to whatever ails Linux (was: Re: the problem with LINUX)
On Sun, 12 Jan 2003, Evgeny Stambulchik wrote: Hence, this approach is wrong. Webmin, LinuxConf, YAST, DrakeConf, you name it. Huge duplication of efforts and _none_ of the above working properly. You need an API (abstraction) that will both generate AND parse the configuration. Moreover, the Apache itself MUST use this very API. And all other servers and applications. Throw in replication and remote access protocol and that will be the sysadmin's paradise... And no, I don't mind it sounds like Active Directory. 1. This means rewriting apache. Recall that apache is used not only on linux, but on hosts of other platforms. Some linux developers tend to be linux-centric, and ignore the fact that the same software needs to run on other platforms. 2. gnome (partially in 1.4, more so in 2.0) is a test to such a technology. Am I the only one who thinks a configuration daemon is bad? And anyway, I remind you that there is already a remote access protocol on linux that is quite powerful, and works very well. It also fits into the unix framework: rsh/ssh (not telnet: you cannot run commands remotely via telnet!) -- Tzafrir Cohen mailto:[EMAIL PROTECTED] http://www.technion.ac.il/~tzafrir = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Binary configuration files as panacea to whatever ails Linux (was: Re: the problem with LINUX)
On Sun, Jan 12, 2003, Evgeny Stambulchik wrote about Re[2]: Binary configuration files as panacea to whatever ails Linux (was: Re: the problem with LINUX): Of course, you need a bidirectional mapping (i.e. not only from the disk representation to the in-memory representation, but also vice- versa); Otherwise, the changes can't be translated to rules of configuration files. Right, and the lack of these features (actually, the lack of decent API providing them) distracted many even pure-X apps from solely using it; instead, they load/store their configs from customly-formatted .rc files. This is not the only problem with X resources... X resources provide a very specific model of configuration, with a very limited syntax. Looking at my ~/.ctwmrc (yes, ctwm is my window manager), ~/.emacs (900 lines of lisp :)), ~/.zshrc, etc., I can't imagine how any of those could be done using the X resources model. I mean, surely it could be done, like this: Zsh.zshrc.line1: Zsh.zshrc.line2: ... But this is obviously not what you suggest. I need the well-defined API and its C implementation. Whatever The Xt implementation of X resources was quite well-defined and powerful. There was a program called xresedit (or something like that... hmm, could it be that XFree86 dropped this??) to edit running applications' configuration on-the-fly (e.g., you could change the button colors on a running application ;)) Tcl/Tk has a much better (in my opinion) configuration paradigm. First, since Tcl is an interpreted language, configuration files could be written in that language and be very powerful (e.g., imagine your clock's color changing depending on the day of the week, and your background change according to the phase of the moon). If you wanted the config file to have a fixed structure so that a program could modify (not just read) it, you could have done it (just like XEmacs now does with the user options saved as Lisp). Then, Tcl/Tk had a send command (try 'man n send') in which you could execute Tcl expressions on another running applications. This could be used, for example, for configuring a running applications. I once had a program like that which let you change colors of widgets (and similar stuff) on running Tcl/Tk programs. Too bad Tcl/Tk didn't catch on, it was a very nice tool :( -- Nadav Har'El| Sunday, Jan 12 2003, 10 Shevat 5763 [EMAIL PROTECTED] |- Phone: +972-53-245868, ICQ 13349191 |Unlike Microsoft, a restaurant will not http://nadav.harel.org.il |ask me to pay for food with a bug in it! = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Binary configuration files as panacea to whatever ails Linux (was: Re: the problem with LINUX)
Tzafrir Cohen wrote:
Hence, this approach is wrong. Webmin, LinuxConf, YAST, DrakeConf, you name it.
Huge duplication of efforts and _none_ of the above working properly. You need
an API (abstraction) that will both generate AND parse the configuration.
Moreover, the Apache itself MUST use this very API. And all other servers and
applications. Throw in replication and remote access protocol and that will be
the sysadmin's paradise... And no, I don't mind it sounds like Active Directory.
1. This means rewriting apache.
No. It means either a) {if the Apache style of config is considered the
best} extracting the relevant part of Apache into an independent library
or b) designing the config API from scratch and throwing away the old
cruft (which isn't a major part of the Apache codebase anyway).
Recall that apache is used not only on
linux, but on hosts of other platforms. Some linux developers tend to be
linux-centric, and ignore the fact that the same software needs to run on
other platforms.
I wholeheartedly agree that for such a base API to catch on, it must be
highly portable.
2. gnome (partially in 1.4, more so in 2.0) is a test to such a
technology.
As I wrote earlier, I in general like the GConf ideas, but it's bound to
Gnome (well, it's supposed to be used kinda standalone, but since it
further depends on about dozen of libraries which you never find on
non-Gnomified systems... and of course, linking a daemon like crond to ten
libraries just to parse its config is definitely an overkill).
Am I the only one who thinks a configuration daemon is bad?
Why is it bad (if correctly implemented)? And why the daemon is a must?
Think about embeded SQL. The backend could be a daemon (e.g. PostgreSQL),
but could also be a plain file (see SQLite). Basically, you just swap the
header files. Ideally, there is a backend-neutral wrapper layer with many
plugins. Administrating a standalone desktop? Configure it to use local
files for the config data storage and don't worry about daemons. Just as
/etc/hosts vs. named. A more complicated schemes including local caching
etc are possible, too.
And anyway, I remind you that there is already a remote access protocol on
linux that is quite powerful, and works very well. It also fits into the
unix framework: rsh/ssh
Fantastic. Ever wondered why people invented HTTP? Of course, these were
Windows freaks who didn't know how to use telnet. The unix framework
would be to ssh to the web server and run the browser there. Right? And
IMAP is completely obsolete in the unix framework, too: ssh to the mail
server and open inbox in vi. If rsh/ssh is the ultimate answer to the
remote management, then vi is the ultimate configuration GUI. Not?
Regards,
Evgeny
=
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word unsubscribe in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
Re: Binary configuration files as panacea to whatever ails Linux(was: Re: the problem with LINUX)
Nadav Har'El wrote: Of course, you need a bidirectional mapping (i.e. not only from the disk representation to the in-memory representation, but also vice- versa); Otherwise, the changes can't be translated to rules of configuration files. Right, and the lack of these features (actually, the lack of decent API providing them) distracted many even pure-X apps from solely using it; instead, they load/store their configs from customly-formatted .rc files. This is not the only problem with X resources... Sure. But my point is that even such a limited config interface has never existed at the base level of Unix system. A limited tool is better than no tool at all. Just imagine how many thousands of hours of programming/debugging could be saved if in libc (or in a separate lib - like libm for math stuff) there existed a simplistic API for dealing with INI-style config files! INI config files would be completely adequate for a vast majority of existing apps, including those that don't presently provide a configuration mechanism at all (e.g. why should I worry about aliasing cp to cp -i, ls to ls -F --color=auto etc in each and every shell separately instead of setting it in a fileutils config file, once and for ever?!). I need the well-defined API and its C implementation. Whatever The Xt implementation of X resources was quite well-defined and powerful. Not really. Why then literally no app uses Xresources for _storing_ prefs? Netscape's preferences.js would fit nicely into the Xresources syntax, for example. Some other advanced X apps (e.g. Nedit) started using the Xresources for preferences but then switched to a custom load/store API _although the format remained the same_! But again, you missed my point. Whatever nice or powerful it is, it's bound to X. Would anybody in the sane mind want to link crond or named to X libs (and which wouldn't work without opening a $DISPLAY)? There was a program called xresedit (or something like that... hmm, could it be that XFree86 dropped this??) editres. BTW, it always had misc problems with Motif/Lesstif apps (which became very severe with Motif-2.1 API, so that OpenMotif folks started putting a modified version of (parts of?) libXmu inside libXm - which created a bunch of other problems, but that's a completely different story). Regards, Evgeny = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Binary configuration files as panacea to whatever ails Linux (was: Re: the problem with LINUX)
On Sun, 12 Jan 2003, Evgeny Stambulchik wrote:
Tzafrir Cohen wrote:
Hence, this approach is wrong. Webmin, LinuxConf, YAST, DrakeConf, you name it.
Huge duplication of efforts and _none_ of the above working properly. You need
an API (abstraction) that will both generate AND parse the configuration.
Moreover, the Apache itself MUST use this very API. And all other servers and
applications. Throw in replication and remote access protocol and that will be
the sysadmin's paradise... And no, I don't mind it sounds like Active Directory.
1. This means rewriting apache.
No. It means either a) {if the Apache style of config is considered the
best} extracting the relevant part of Apache into an independent library
or b) designing the config API from scratch and throwing away the old
cruft (which isn't a major part of the Apache codebase anyway).
Recall that apache is used not only on
linux, but on hosts of other platforms. Some linux developers tend to be
linux-centric, and ignore the fact that the same software needs to run on
other platforms.
I wholeheartedly agree that for such a base API to catch on, it must be
highly portable.
2. gnome (partially in 1.4, more so in 2.0) is a test to such a
technology.
As I wrote earlier, I in general like the GConf ideas, but it's bound to
Gnome (well, it's supposed to be used kinda standalone, but since it
further depends on about dozen of libraries which you never find on
non-Gnomified systems... and of course, linking a daemon like crond to ten
libraries just to parse its config is definitely an overkill).
Am I the only one who thinks a configuration daemon is bad?
Why is it bad (if correctly implemented)? And why the daemon is a must?
Think about embeded SQL. The backend could be a daemon (e.g. PostgreSQL),
but could also be a plain file (see SQLite). Basically, you just swap the
header files.
/me thinks: how can one binary work with all the different backends...
Ideally, there is a backend-neutral wrapper layer with many
plugins. Administrating a standalone desktop? Configure it to use local
files for the config data storage and don't worry about daemons. Just as
/etc/hosts vs. named. A more complicated schemes including local caching
etc are possible, too.
Anyway, one thing you should look at is libc's nss (name service switch),
which allows selection in run-time of the name-resolution method for each
of the services. But this is a read-only configuration.
And anyway, I remind you that there is already a remote access protocol on
linux that is quite powerful, and works very well. It also fits into the
unix framework: rsh/ssh
Fantastic. Ever wondered why people invented HTTP? Of course, these were
Windows freaks who didn't know how to use telnet. The unix framework
would be to ssh to the web server and run the browser there. Right?
Hey: I specifically excluded telnet!
Anyway, http is a simplified ftp, not a simplified rsh.
And
IMAP is completely obsolete in the unix framework, too: ssh to the mail
server and open inbox in vi.
I actually access my imap account via ssh to the mail server ('ssh
mailserver /path/to/imapd') ...
If rsh/ssh is the ultimate answer to the
remote management, then vi is the ultimate configuration GUI. Not?
You seem to confuse usage and administration in the above examples.
It is a powerful remote administration tool that you should not break.
There is one thing you should keep in mind: GUI can't be automated. An
API, as nice as it is, still takes some effort to automate. If you want
something done via cron: you need a shell command.
Another thing to keep in mind: current package management tools are built
around files. A file cannot be part of two packages. Config files fit very
nicely into this scheme: there is a clear definition who is responsible
for each config file. If more than one package should change a certain
config file, then the package providing this file must provide the
(command-line) API to edit this file safely.
This modularity is another thing that has to be maintained. One thing that
has to be done in any such configuration scheme is to define domains
whose are in the responsibility of certain packages.
Another point: you mentioned cups as a good example of a package with a
clear configuration API (though it seems to require a certain daemon
listening on a certain port, IIRC).
There is one difference between a general configuration scheme and a
specific configuration scheme: the designers of cups's config API were
aaware of the meaning of every action: they knew what print will do,
etc.
But if you design a generic config API, you simply don't have the right
actions or verbs in advance: It seems that what you want is an API
that will expose all the actions that can be performed on the config of a
service, rather than a low-level API to edit the config of the service.
--
Tzafrir Cohen
mailto:[EMAIL PROTECTED]
Re: Binary configuration files as panacea to whatever ails Linux (was: Re: the problem with LINUX)
On Sun, Jan 12, 2003 at 09:36:53PM +0200, Nadav Har'El wrote: There was a program called xresedit (or something like that... hmm, could it be that XFree86 dropped this??) to edit running applications' configuration on-the-fly (e.g., you could change the button colors on a running application ;)) Is the following what you are referring to? $ dpkg -S /usr/X11R6/bin/editres xbase-clients: /usr/X11R6/bin/editres $ $ man editres editres(1x) NAME editres - a dynamic resource editor for X Toolkit applications SYNOPSIS editres [ toolkitoption ... ] DESCRIPTION editres is a tool that allows users and application developers to view the full widget hierarchy of any X Toolkit application that speaks the -- Shaul Karl, [EMAIL PROTECTED] e t = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Binary configuration files as panacea to whatever ails Linux (was: Re: the problem with LINUX)
Tzafrir Cohen wrote:
Think about embeded SQL. The backend could be a daemon (e.g. PostgreSQL),
but could also be a plain file (see SQLite). Basically, you just swap the
header files.
/me thinks: how can one binary work with all the different backends...
man dlopen. Or read existing code. Since we talked about SQL, the first
thing that comes to my mind is UnixODBC (http://www.unixodbc.org/).
Ideally, there is a backend-neutral wrapper layer with many
plugins. Administrating a standalone desktop? Configure it to use local
files for the config data storage and don't worry about daemons. Just as
/etc/hosts vs. named. A more complicated schemes including local caching
etc are possible, too.
Anyway, one thing you should look at is libc's nss (name service switch),
which allows selection in run-time of the name-resolution method for each
of the services. But this is a read-only configuration.
Hmm, and in which way is it related to a generic configuration API? I used
the hosts/named example just to show how the same functionality can be
achieved both with and without a daemon - with applications not having a
slightest idea whether the NS answer comes from a remote server or /etc/hosts.
And anyway, I remind you that there is already a remote access protocol on
linux that is quite powerful, and works very well. It also fits into the
unix framework: rsh/ssh
Fantastic. Ever wondered why people invented HTTP? Of course, these were
Windows freaks who didn't know how to use telnet. The unix framework
would be to ssh to the web server and run the browser there. Right?
Hey: I specifically excluded telnet!
What's the principal difference here, for the heaven's sake?
Anyway, http is a simplified ftp, not a simplified rsh.
Exactly. So you answered yourself. When there is a remote data (HTML files
in the case of WWW) there are two ways for a user to access the data: 1)
login to the remote computer and run an application (web browser) there
and somehow display the application's interface back or 2) retrieve the
data to the local system and run the app locally (and send the modified
data back, if required, using the same protocol that was used for fetching
it). The second approach is called the client-server model. Shall I go
in depth proving that 2) is superior?
I actually access my imap account via ssh to the mail server ('ssh
mailserver /path/to/imapd') ...
No. What you're doing is tunneling the IMAP protocol via the ssh tty
session. Why you're doing so is quite beyond my understanding, though (a
firewall blocking the IMAP port? - but why not usual port forwarding that
ssh is so good at?). At the other end of the ssh pipe an IMAP-capable mail
reader is listening anyway.
If rsh/ssh is the ultimate answer to the
remote management, then vi is the ultimate configuration GUI. Not?
You seem to confuse usage and administration in the above examples.
No, it's you fail to realize that administration is a form of usage.
For a web browser application the data is HTML files. For a management
console, the data is config info.
It is a powerful remote administration tool that you should not break.
??
There is one thing you should keep in mind: GUI can't be automated.
Why did you jump at GUI? Whether I'm using Mozilla to browse the Net or
downloading a Mandrake ISO with wget the HTTP protocol comes handy. And
both Mozilla and wget could potentially use the same HTTP access API if
such a thing existed on all flavours of OS the two applications are
running. Same about IMAP: KMail (GUI) and fetchmail (GUI-less) both use it
instead of logging to the remote server via ssh. Same about config.
An API, as nice as it is, still takes some effort to automate.
Come on. The point is _unification_. If a device has ten screws, nobody
would deny it's more complex to deal with than a single one. But if each
of them is different in size/form... Yes, that's the current state of
affairs in the Unix world of configuration. A nice car with hundreds of
screws of different types. You have to learn how to use a few dozens of
different screwdrivers. For a few large polished screws you can buy an
electric screwdriver; however, 1) the electric tool, albeit fast, is very
rough and 2) once you started using the advanced tool, an attempt to
tighten one of the polished screws with a usual screwdriver risks the car
stop working. Imagined?
If you want something done via cron: you need a shell command.
Sorry, I lost you here completely. What did you try to say?
Another thing to keep in mind: current package management tools are built
around files. A file cannot be part of two packages. Config files fit very
nicely into this scheme: there is a clear definition who is responsible
for each config file.
The clear definition appears very dirty at a closer look. Ever tried
changing hostname of a multi-protocol server? The hostname pops up in a
dozen of different config files. Which package is
Binary configuration files as panacea to whatever ails Linux (was: Re: the problem with LINUX)
On Sat, 11 Jan 2003, Eli Marmor wrote: * Migration from the current ASCII CONF format to binary format or database-based format. There are zillion GUI's for Apache (just as an example), and none is good, because it's impossible to develop a GOOD GUI for an ASCII-based configuration file. I guess that everybody is going to laugh at the REGISTRY and other MS stuff, but handling ASCII CONFfiles, with VI/emacs, when you are a dummy, is impossible. (I know that many people don't agree with this point, but I don't want to start a new argument, although I have a lot of experience and knowledge in this field; The last line remains thesame: COMPATIBILITY). Why, yes of course, if you move to binary configuration files for your applications and make their format a trade secret and release obfuscated source files for the modules, which deal with the configuration files, then you in effect erect a tollgate and make it difficult for developers to develop competing configuration tools for your applications, and then you can make some money from configuration tools, time spent at installation, consulting fees, ad nauseaum... --- Omer I am sick of binary configuration files! WARNING TO SPAMMERS: see at http://www.zak.co.il/spamwarning.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Binary configuration files as panacea to whatever ails Linux (was: Re: the problem with LINUX)
Following Omer's response: Just to clarify, I've NEVER mentioned Proprietary format; XML is great (though you may inherit the problems of ASCII by writing a cheating schema). PostgreSQL/MySQL is good too (although it depends on a specific implementation of a database). And I was serious when I asked not to argue on this specific point; the last line of my entire message was clear, and if you don't agree with the specific point of binary/XML configuration format, just ignore it, and refer to the other points. I really don't want to start a new argument about this issue, and it is a minor point and a small part of my message. -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Binary configuration files as panacea to whatever ails Linux(was: Re: the problem with LINUX)
Hi, On Sat, 11 Jan 2003, Omer Zak wrote: Why, yes of course, if you move to binary configuration files for your applications and make their format a trade secret and release obfuscated source files for the modules, which deal with the configuration files, then you in effect erect a tollgate and make it difficult for developers to develop competing configuration tools for your applications, and then you can make some money from configuration tools, time spent at installation, consulting fees, ad nauseaum... So true, but we also have to beware of some types of text files... For example, I am a big proponent of XML files as a very small scale replacement for a database. It has all you need for a small scale DB. But the problem with XML files is that they exhibit the same parsing problems that text files have, along with shoddy readability, like binary files. That said, I probably should state that I personally prefer text files. And the author of the software should work a little on making the text file ordered reasonably. Amit -- Amit Margalit = Gee, Toto, I don't think we're in Kansas anymore. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Binary configuration files as panacea to whatever ails Linux (was: Re: the problem with LINUX)
I didn't want to detail too much in the point of CONF files, because it was not my main point. But it caused some balagan, so please let me give an example of a format that is not proprietary, and on the other hand is not XML, and still is great for developing GUI's for: X Resources. Does it threat anybody? No? OK; Let's go on: There are several requirements that are critical for creating a good GUI. One of them is the ability to work against a working program, and not just a file. Because you can't just open the file, guess all the values of ifdefs, the default path (for includes), the directory that the opedning program is in during the open, etc. When you are working against a working program, you know its current run-time values of these resources. In addition, it allows you to affect its CURRENT behavior immediately, resulting in a WYSIWYG that is so important for GUI (think editres; don't think UIM/X). Of course, you need a bidirectional mapping (i.e. not only from the disk representation to the in-memory representation, but also vice- versa); Otherwise, the changes can't be translated to rules of configuration files. You need clear definitions; Not definitions that may start anywhere in the line, with any number of leading/trailing spaces/tabs/etc. that you never know which are part of the value and which are not, with leveling that is based on semi-XML directives (/directory /), with ambiguous comments, with ifdefs that you never know if the leveling that is hidden by them is really hidden - or only the rules inside those levels, with too many ways to say yes (e.g. tRuE, oN, falling back to the default, etc.) and so on. There are many other formatting issues that ease or harden the ability to develop a good GUI. X Resources, contrary to ASCII CONF files (like Apache's or NAMED), meets all these demands. Of course, it is not so friendly, but when you have a great GUI - who cares? It is still friendly enough for hackers like us. Will this migration happen? No way; People develop Open Source for their own fun. Or for their own use (for example, most of the core developers of Apache need it for their own sites). When there is a company (please don't force me to spell the name of Redmond's companies) behind the product, they have balls (sorry for the word...) and don't give a sh*t (sorry again) on their users, so they can replace formats whenever it is important for the evolution of their product. Of course, there are also negative cases, so please don't give examples that Microsoft (sorry) abused this process and replaced a good format by a bad format or broke the compatibility of a program that was used by 100 million users. But when the users develop the program, there are some things that they would never do. Some of these things are bad, but improving the format is sometimes good and needed. P.S. Many years ago, I developed a great GUI for X. You could take even a binary program, and change its screens, widgets, add more dialogs/forms/screens, etc. Fully WYSIWYG, of course. I used it (among other uses) for localizing Netscape 3/4 (although there were no sources), which involved not only translation, but also new screens and forms (for example - to choose the default direction, the default user interface language, help of the Hebrew support, etc.). I used it also for developing callbacks (without writing one C line!) and applying BiDi values to specific widgets (e.g. Visual/Logical). I tried to do it for other CONF formats (e.g. Apache), but there was no chance. I don't care if the format is X Resources, or database-based, or (sorry!) registry, or even XML (though XML doesn't meet all the demands); I just want a format that its designers/definers thought about a front-end when they designed it, and not only on the flexibility of users who use VI to edit it by-hand or on backward compatibility issues. -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
