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: the problem with LINUX
On Sat, 2003-01-11 at 09:32, shlomo solomon wrote:
I'm afraid this is going to start a **war** and that's not my intention, but I
really feel I've got to get this off my chest.
Firstly, let me say that I've been using LINUX on and off for 6 years and that
it's been my only OS since deleting OS/2 (zl) 3 years ago. So I'm a
committed LINUX user. And I have no intention of using anything else -
although my wife and kids all use Windows - and of course that makes me the
primary sysop for their machines :-(.
My problem is that LINUX (as much as it's progressed over the years) is still
much too hard to install, set up, and use. As things stand now, it's not
really a viable alternative for John Q. User. As opposed to other OSs (that
will remain nameless), there's still too much tweaking required. And for a
non-technical user, it's just impossible.
Shlomo, what you say must be true, at least in your own view. It also
must be important to you, since you have written to all of us about it.
If so, why don't you attampt to remedy those thins which you find are
bothering you? after all this IS what Free Software is about - not you
(or anyone else) getting somefor no pay, but your own (and everyone
else) ability to fix what they dim broken.
Linux is not the best OS in the world and it will never be, simply
because the world keeps changing. But contrary to other non free OS YOU
can adapt it so that it will fit your needs better. it's a unique
ability and a very powerfull one.
And yes, there are people that don't find this compelling. In truth, i
don't find them interesting all that much. We like to help people who
help themselves and obviously you are such a person since you solved
your problems). Other people - they can pay {Insert name of commercial
support company here} to solve their problems...
Gilad.
=
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
Re: the problem with LINUX
On Sat, 11 Jan 2003, shlomo solomon wrote: My problem is that LINUX (as much as it's progressed over the years) is still much too hard to install, set up, and use. As things stand now, it's not really a viable alternative for John Q. User. As opposed to other OSs (that will remain nameless), there's still too much tweaking required. And for a non-technical user, it's just impossible. The real problem was seriously mis-identified. It is now actually easier to install Linux than MS-Windows. When I was forced to upgrade my PC's motherboard from one hosting a 300MHz processor to one hosting a 1.7GHz processor, Windows 95 died (there is some obscure driver in the Hebrew version of Windows 95, which fails when the processor's clock frequency goes beyond 1GHz; and a fix is available only for OSR2 - unavailable for the Hebrew edition) and Windows 2000 was in serious trouble. Linux 2.0.36 (very old by today's standards) booted on the new motherboard without problems. When was the last time anyone bought PC and MS-Windows and installed and configured by himself all the stuff? The computer shops sell you computers with your taste of MS-Windows preinstalled, configured and tested. If you run into problems, they support you under warranty. And they fight all the problems so that your experience is as seamless as possible. On the other hand, with Linux, you have to install it yourself - almost no one sells a PC with preinstalled Linux. You have to turn to friends and IGLU for support, rather than rely upon warranty. You have to fight your own battles rather than have the shop personnel fight for you. And... you know what? Your Linux battles are easier than the shop's MS-Windows wars. But since you don't see the shop's backroom, you are comparing your Linux battles with the experience of an MS-Windows user. --- Omer 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: the problem with LINUX
Quoting shlomo solomon, from the post of Sat, 11 Jan: My problem is that LINUX (as much as it's progressed over the years) is still much too hard to install, set up, and use. As things stand now, it's not really a viable alternative for John Q. User. As opposed to other OSs (that will remain nameless), there's still too much tweaking required. And for a non-technical user, it's just impossible. Barging through an open door. what's your point? We all know it's the current state, we all kvetch about it, some of us have time to do something about it but lack the knowledge or interest. It's your free choice to run it, it's you right to document procedures to fix the problems you encountered, and it's your right to send fixes and suggestions to the appropriate vendors, authors and packagers. -- My own worse critic Ira Abramov http://ira.abramov.org/email/ This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal. msg24815/pgp0.pgp Description: PGP signature
Re: the problem with LINUX
Two remarks: On Sat, 11 Jan 2003, shlomo solomon wrote: [snip ] I won't go into the details here, but those who have read my posts over the past couple of months know that I had problems with USB printer support, iptables, file permissions, etc. And most recently, I haven't been able to use my FlyVideo2000 card. Although all the problems (except the FlyVideo2000 card) are solved, it all required too much effort. Just one note: I don't remember what were your other problems, but the iptables problem was caused by the fact that you weren't satisfied with the built-in firewall of the distro, and wanted to use your own (and the ipchains service got in the way). This is not a problem I expect the mythical Joe User to have. As someone wrote to the list recently (sorry, don't remember who - and this is not an exact quote): I want the computer to do useful work - tweaking is only a means to that end and not the purpose of having the computer. So how can we expect the non-technical user to even consider LINUX? I consider myself a technical user - but I've given up on the TV problem, so what does that say? I know it's **sexy** to talk about self compiled kernels, etc. And, in fact, on MDK 8.1 (and previously) I did compile my own for various reasons. But, should I really have to compile a kernel just to watch TV? Maybe. If that what it takes. But in that case rebuilding the kernel should not be difficult. It should involve less magic. I see nothing wrong with aunt tilly being forced to compile a kernel. Heck: don't you find it weird that you have to download a 4MB or 8MB so-called driver that installs a bunch of programs that are totally unnecessary for the function of the real driver? Maybe there could be a half-compiled tree that fits the binary distro and kernel image, and you'll only need to build the kernel module itself? And, more importantly, what about my next door neighbour, who doesn't even know what the word compile means? How does he get to watch TV? Basically, all this keeps LINUX as an OS for **experts**. If rebuilding a kernel is to become a necessaty for configuration, then it should be wrapped with a simple interface. Debian already has something close to that. As I said, I don't intend to start a war - I am a committed LINUX user - but it really shouldn't be so hard. -- 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: the problem with LINUX
On Sat, 11 Jan 2003 19:32:21 +0200 shlomo solomon [EMAIL PROTECTED] wrote: although my wife and kids all use Windows - and of course that makes me the primary sysop for their machines :-(. Why? Isn't Windows so easy that anyone can handle it You see, as someone else already pointed out, no John Doe is actually installing and configuring their own Windows machine -- someone else do it for them either for a fee (the computer store, the technician, their ISP over the phone) or for other reasons (a family member, a neighbour, a coworker who is a computer expert). What is changing in the Linux world is: - Distributions are getting better at install/configure - More and more people are available to help others with Linux issues (I'm sure you can now help your friends or neighbours with *some* of their common problems). - Hardware vendors are (really slowly) beginning to pay attention as Linux becomes more widespread (e.g: you start to see advertisements [even in Israel] that refers to Linux compatibility). Cheer up, Oron Peled Voice/Fax: +972-4-8228492 [EMAIL PROTECTED] http://www.actcom.co.il/~oron Linux: If you're not careful, you might actually learn something. -- Allen Wong = 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]
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: the problem with LINUX
Quoth shlomo solomon: I'm afraid this is going to start a **war** and that's not my intention, but I really feel I've got to get this off my chest. War is good - drives the economy ;-). See if we shan't have one soon. My problem is that LINUX (as much as it's progressed over the years) is still much too hard to install, set up, and use. As things stand now, it's not really a viable alternative for John Q. User. As opposed to other OSs (that will remain nameless), there's still too much tweaking required. And for a non-technical user, it's just impossible. Good. That is the idea. Fuck JQU, (s)he is not worth the effort, anyway. The sooner we get back to the old priesthood computing model, the better. all required too much effort. As someone wrote to the list recently (sorry, don't remember who - and this is not an exact quote): I want the computer to do useful work - tweaking is only a means to that end and not the purpose of having the computer. You want to _USE_ the computer. You are not part of the priesthood - get out of my terminal room post-haste. Computers are not the means - they are the ends. Serve the computer, friend citizen, the computer is your friend. get to watch TV? Basically, all this keeps LINUX as an OS for **experts**. Yes. Experts. Us. All seventeen of us, give or take. As I said, I don't intend to start a war - I am a committed LINUX user - but it really shouldn't be so hard. It should not be so hard. It should be MILES harder. Go away - you're a troll. M -- ---OFCNL This is MY list. This list belongs to ME! I will flame anyone I want. Official Flamer/Cabal NON-Leader [EMAIL PROTECTED] = 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: the problem with LINUX
Warning: the following text is long. Request: ease don't reply without reading till the end. There may be mistakes or things that you may want to argue with, but the whole picture is the important thing, and not the (example:) exact number of Linux/Windows users. I agree with Shlomo, but also with one of its responders (was it Omer?). There is a severe friendliness problem with Linux, but it is not RECOGNIZED correctly. Friendliness is rhymed with marketting, so everybody went to marketting experts, and asked them what whould be done. And those experts, Nebechs, who have never heard about kernel drivers, answered automatically: Don't you have a desktop environment management? Bad!. So now we have too many KDE/GNOME/etc., and no problem has been resolved. Then they said: Your graphics looks ugly! And you need better icons!. So now the graphics of Linux is better than Windows, but no problem has been resolved. Then they said: Your best word processor is a text editor 20-years old ? VERY BAD!. So now we have SEVERAL word processors, but no problem has been resolved. And I can continue and pass a mistake after mistake, but I think the point was understood. IF the real experts (i.e. technical experts) were asked, I believe their answers would be different (well, Linus had the same answers, but only because everybody told him: Listen to the marketting experts, they know what they say!). Now let's go to the real problem that makes Linux non-friendly (well, it's actually friendly, but a little selective with who its friends are...): Shlomo mentioned FlyVideo 2000 problems, and USB printer support. In addition, almost any Linux installation faces hardware devices that are not supported, or devices that are not detected. Linux users are forced to use very specific and expensive devices (e.g. modems) because many of the devices are not supported by Linux. Some people are not so dummy, and can google for solutions/workarounds. But how can you google in the middle of an installation, when you reach a problem, you don't have a second (working) PC, and you don't want to lose all the installation? (i.e. to cancel it just to google in your second partition and then reboot again and start the installation from the beginning). Some users receive DOC attachments, and can't view them. Or can import them to one of the Linux word processors, but don't see them correctly (usually they even don't know that the document was not viewed correctly, because they don't have a clue about how it was seen by its original author). Some users can't use their Linux mailer/scheduler, because it doesn't inter-operate perfectly with the organizations Exchange server (unless they pay money and purchase the commercial add-on of Evolution). Linux should not be blamed for these problems. For example, the hardware compatibility problems are caused just because there are 100 Windows users per any Linux user (or 50 per 1. The exact number is not important). Now imagine you are a hardware vendor. During the RD, you reach the testing phase. The chance that your new hardware will work in the first time you put it into a computer with Windows, is 0%. So you find the problem, fix it, and try again. After 10 or 20 itterrations, everything works correctly. Sometimes you also need to supply a device driver, so you develop a Windows driver. Usually, that loop of itterrations, or that device drivers, are not done with Linux. Because there are so many Windows users and so little Linux users, and that doesn't pay. It's like the bank site that was discussed here recently. Who is to blame? The vendor should not be blamed, because it is not economical for him to develop everything for Linux too. The Linux developers should not be blamed, because the better support of Windows is not thanks to the efforts of Microsoft, but an automatic result of its wide distribution. Only those marketting experts that claimed that better icons will solve the problem, should be blamed. They should not express any opinion without knowing kernel internals etc. So what can be done now? Focus ALL the efforts to improve the compatibility issues: * kernel, device drivers, etc. I think that the most important events for the friendliness of Linux in the recent years, were the launch of Linux 2.2, and the launch of Linux 2.4. And hardware is not the only compatibility issue related to the kernel: I think that the fact that NTFS is still only read-supported and not write-supported is severe. And there are many other examples. * Better filters, from and *TO* Windows applications (for example, PERFECT filters for WORD, Excel, PPT, etc.). And support for MS protocols and formats (e.g. better emulation of Outlook in mail apps, so an organizational Exchange server can be used better by Linux users). * Migration from the current ASCII CONF format to binary format or database-based format. There are zillion GUI's for Apache (just as an
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 CONF files, 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 the same:
COMPATIBILITY).
Some XML-based format may be a resonable comppormise between
machine-parsable and human-edible. Maybe. One big config file is
always a source of troubles.
Actually, we already have some examples of programs with relatively
complex configs (mozilla, KDE), and a very common debugging procedure is
'please {delete|rename} the ~/.{kde|mozilla} directory.
I have a feeling that one big registry will make things even worse.
What happens when those configs are lost?
(dont tell me anything about automatic backups. We all know that this is
something that is bound to fail sooner or later, as in windows 98)
--
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)
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: the problem with LINUX
Title: the problem with LINUX Yeah, linux is a crappy piece of software. What isn't? But at least, it was all written by kind sirs who awed nothing to you. Anyway, Windows is no better. Even Windows needs the touch of a techman for it to run smoothly and not crappily. Things, all things, should be made idiot-proof. Technicals oughta be as simple as possible, without compromising on workness. One thing that should not be compromised is lazyness. We ought not encourage people to needlessly and inefficiently work. Entries in mailing-lists should also be simple. Constructedof simple and short sentences, structured simply, carrying a simple message. -äåãòä î÷åøéú- îàú: shlomo solomon [mailto:[EMAIL PROTECTED]] ðùìç: ù 1/11/2003 19:32 àì: IGLU IGLU òåú÷ ìéãéòä: ðåùà: the problem with LINUX I'm afraid this is going to start a **war** and that's not my intention, but Ireally feel I've got to get this off my chest.Firstly, let me say that I've been using LINUX on and off for 6 years and thatit's been my only OS since deleting OS/2 (z"l) 3 years ago. So I'm acommitted LINUX user. And I have no intention of using anything else -although my wife and kids all use Windows - and of course that makes me theprimary sysop for their machines :-(.My problem is that LINUX (as much as it's progressed over the years) is stillmuch too hard to install, set up, and use. As things stand now, it's notreally a viable alternative for John Q. User. As opposed to other OSs (thatwill remain nameless), there's still too much tweaking required. And for anon-technical user, it's just impossible.If I just consider my own setup since upgrading to Mandrake 9.0 (I've usedMandrake since 7.0), the solutions to most of the problems I had, were beyondwhat the average user could have handled. Sure, IGLU was very helpful, whichis again proof that if you GOOGLE around and RTFM before asking questions,the list members are usually very good about helping. But, why should thishelp be needed? I won't go into the details here, but those who have read myposts over the past couple of months know that I had problems with USBprinter support, iptables, file permissions, etc. And most recently, Ihaven't been able to use my FlyVideo2000 card. Although all the problems(except the FlyVideo2000 card) are solved, it all required too much effort.As someone wrote to the list recently (sorry, don't remember who - and thisis not an exact quote): I want the computer to do useful work - tweaking isonly a means to that end and not the purpose of having the computer.So how can we expect the non-technical user to even consider LINUX? I considermyself a technical user - but I've given up on the TV problem, so what doesthat say? I know it's **sexy** to talk about self compiled kernels, etc. And,in fact, on MDK 8.1 (and previously) I did compile my own for variousreasons. But, should I really have to compile a kernel just to watch TV? And,more importantly, what about my next door neighbour, who doesn't even knowwhat the word compile means? How does he get to watch TV? Basically, all thiskeeps LINUX as an OS for **experts**.As I said, I don't intend to start a war - I am a committed LINUX user - butit really shouldn't be so hard.--Shlomo Solomonhttp://come.to/shlomo.solomonSent by KMail (KDE 3.0.3) on LINUX Mandrake 9.0==To unsubscribe, send mail to [EMAIL PROTECTED] withthe word "unsubscribe" in the message body, e.g., run the commandecho unsubscribe | mail [EMAIL PROTECTED] Hotmail.co.il - Powered by IBM eServer
Re: the problem with LINUX
On Saturday 11 January 2003 21:28, Tzafrir Cohen wrote: And re-install all of your programs. And hopefully you have your config saved. Talking about re-installation of Windows here, not Linux. What you mention is mystrious behaviours, not hardware installations. Proper usage of packages mean that you have less problems with packages. In this particular case, I suspect hardware problems. A journaling file system reduces the chance of file corruption and thus gives you a more stable system. But anyway, if you get in a habit of re-installations (bad!) make sure to create a kick-start configuration o shorten its time (Mandrake, and probably other distros as well, offer to do this in the end of the installation) Once more, this particular problem was with Windows. - [snip] Basically, all this keeps LINUX as an OS for **experts**. IMHO, what is required to bring Linux out of the expert OS niche, is : - Vendor-supplied hardware drivers , no matter if binary or not, or at the very least open specifications. And please stop telling me all this nonsense about And what if vendor decides to stop supporting those drivers? And what if the hardware is rare and those who have it, can't write code? And why should we the users wait several years till the drivers are there? I personally prefer working hardware and then all these freedom principles, but YMMV. Anybody here with ADSL modems that are not supported under win98? At least if you happen to have recent Windows, you haven't to wait several years for Linux community to reverse-engineer the driver. What about the (pctel?) binary-only winmodem drivers that required you to move back to a sepecific, obsolete, and insecure kernel just to be connected to the internet? (I usually want to make sure I have a fixed kernel when I connect to the internet) Vote with your purse - don't purchase such modem, if the vendor doesn't have a driver for your particular distribution ( or for your particular version of Windows). Or purchase it and wait several years for the driver to be reverse-engineered ( this may never happen ). Do you know how many people had to compile their kernel just because of those binary-only drivers? Blame kernel developers for that - the kernel has NO INTERFACE to accept binary third-party drivers. In my book, it's a serious obstacle. IMHO, hardware vendor support for Linux is necessary for Linux to become mainstream desktop system. There are three ways for a hardware vendor to provide such support- either the vendor publishes the specs or it writes a binary driver or it writes an open-source driver. In the first case, the hardware would be supported in any Linux kernel, but you as a user have to face a good bit of delay till the driver be actually written. But - a lot of hardware vendors just wouldn't accept this way due to trade secret / legal /etc issues. And but - if the hardware is rare, there may be as well that noone in the Linux community have any interest in writing the driver, even with the specs there in the open. The second way would me much more acceptable to hardware vendors, but it is not so acceptable for the users. There may be a midway - part of the driver is binary, and part is provided in source and may be easily recompiled to match any kernel. NVidia comes to mind as an example. The third way may face the same obstacle as the first way - trade secrets / legal issues. - Sensible defaults. You shouldn't dig around a ton of configuration files just to get something simple to work. You may tweak it later, but it should work out of the box. This is getting better, but it isn't there yet. IMHO it's quite there. Care to give an example? XFree86 configuration. Change a monitor from 17 to some old 14 ( say your monitor is broken) and risk just damaging the 14 one or X failing to start. Or change a mouse from PS\2 one to USB one. The values are hardcoded into the configuration file leaving no way for autodetection. Stupidity at its best, pure and simple. - There should be BOTH GUI configuration tools AND CLI configuration tools. Right. There should be a way to automate everything. This is very important, and something many people forget. If the only proper way for me to add a user is through the vendor's users management interface (because this interface does some bookeeping and other things besides adduser) then the vendor should provide a command-line tool with equivalent power to the GUI tool. Or a GUI tool with equivalent power to the CLI tool. I've tried to stress GUI. I use Mandrake too. While overall it is a very good distro, part of their Drak* tools are actually exactly what I've described - half-baked underdeveloped POS, Example, please? DrakConnect. sorry for being brutal. It's actually a lot easier to comprehend and tune configuration files by hand then to use these tools. Let's formulate it like the following : for anything
Re: the problem with LINUX
On Sat, 11 Jan 2003, Shoshannah Forbes wrote: * Dependency hell. Nothing like running a RPM (when you are not connected to any network) to get dependency errors about missing files. Or when you are using another machine (with a fast internet connection) to download RPM's and burn them on a CD- many times you have no way to know what dependent RPM's you need to download, so you can actually install the application on the other machine. apt I know tools like apt that help, but they are no good for computers with no internet connection, and are horrible over dial up. apt-get --recon --download-only install package Will print what you need to download the files required to install package. This gives you a nice list of URLs to go and fetch. I hope they improve. (ROX desktop http://rox.sourceforge.net/ addresses this issue with application packages similar to what can be found in mac OSX) Nice, but totally misses the point. Dependencies are here to solve a problem (I've just installed the program foo and it dosn't work can you run it from the terminal? terminal? yuck. well, OK. double-click on terminal icon, p-r-o-g-r-a-m-enter. I see something about failing to load a library). But RPM does not attempt to resolve dependencies. This is a GoodThing: rpm should not be aware of the extra complexity in the existance of a repository (more than one? an up2date server?) of packages and how exactly to decide which of them to install. That is what apt, urpmi and up2date are for. * Unless you work with the CLI (and even then sometimes) the file system is really cryptic. The file system is always very cryptic. On every system. Where did that RPM install the application? rpmq ? kpackage? rpmdrake? Any information that is available in a command line program can be made avilable to some GUI. In this case such GUIs exist. Where are my drivers? Where is the application I see an alias to in the kicker/ launcher/ whatever? The answer is not obvious and takes a lot of digging to find out. drivers are not programs, and need not have menu items. Debian has had a good menuing system for quite a while. This system was later adopted by Mandrake. If a package wants to add itself to the menus, it only needs to create one file and run the menu-updating procedures. This will add it to any programs menu in the system. However it seems that this system is not going to take over: gnome and kde folks decided to have a standard of their own, and it has currently been adopted by (at least) RedHat: http://www.freedesktop.org/standards/menu/draft/menu-spec/menu-spec.html Those files are in an XML format. So you can't easily rem-out lines there with your favorite text editor. * Not good enough defaults in many applications, combined with too many configuration options. I have seen how this happens: the developers can't agree about some design issue, so they end up saying let's just make this a pref. * In general, too many things *have* to be configured, and configuring takes a lot of time. Yes, it is fun to tweak here and there, but I use my machine to get other things done, not to tweak all day. Then configure debconf not to ask you that many questions. * Too much of the UI is legacy UI, which was originally used in another system to overcome a system limitation, and copied as is into linux, although linux does not have the original limitation at all, and could have used much better UI. This also leads to cluttered, confusing and unusable UI's. (see http://mpt.phrasewise.com/stories/storyReader$374 Just a comment: I read the article, and don't consider those examples good ones. The worst one is the suggestion to have recently-used lists contain inodes instead of files-names (inode numbers wil be invalidated after the next save ;-) ). -- 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)
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: the problem with LINUX
On Sunday, Jan 12, 2003, at 01:03 Asia/Jerusalem, Alex Chudnovsky wrote: And but - if the hardware is rare, there may be as well that noone in the Linux community have any interest in writing the driver, even with the specs there in the open. Tell me about it :-( That is exactly the case with the DVD Decoder card on my 4 tear old laptop. The best I got was a post by a developer back in 1991 saying that since there aren't enough people with this card for them to write the driver: http://www.au.linuxvideo.org/lists/livid-dev/2001-February/ msg00222.html Sigh. Mandrake 9 actually identified what it is (LuxSonor LS242), but I don't have anything who knows how to run or use 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: the problem with LINUX
On Sun, 12 Jan 2003, Alex Chudnovsky wrote: On Saturday 11 January 2003 21:28, Tzafrir Cohen wrote: And re-install all of your programs. And hopefully you have your config saved. Talking about re-installation of Windows here, not Linux. Me too. What about all of your configuration there? Or do you give it up in advance? If so: an equivalent (and faster) linux solution would be a kick-start installation... Basically, all this keeps LINUX as an OS for **experts**. IMHO, what is required to bring Linux out of the expert OS niche, is : - Vendor-supplied hardware drivers , no matter if binary or not, or at the very least open specifications. And please stop telling me all this nonsense about And what if vendor decides to stop supporting those drivers? And what if the hardware is rare and those who have it, can't write code? And why should we the users wait several years till the drivers are there? I personally prefer working hardware and then all these freedom principles, but YMMV. Anybody here with ADSL modems that are not supported under win98? At least if you happen to have recent Windows, you haven't to wait several years for Linux community to reverse-engineer the driver. What is the market share of those unsupported OSs? FYI, linux 2.0 is still maintained. What about the (pctel?) binary-only winmodem drivers that required you to move back to a sepecific, obsolete, and insecure kernel just to be connected to the internet? (I usually want to make sure I have a fixed kernel when I connect to the internet) Vote with your purse - don't purchase such modem, if the vendor doesn't have a driver for your particular distribution ( or for your particular version of Windows). Or purchase it and wait several years for the driver to be reverse-engineered ( this may never happen ). The particilar cas I'm talking about is one in which the original vendor no longer existed. Do you know how many people had to compile their kernel just because of those binary-only drivers? Blame kernel developers for that - the kernel has NO INTERFACE to accept binary third-party drivers. I don't want to blame them for producing a better kernel. I don't want to blame them for breaking unnecessary legacy cruft to remove some of the existing bloat. In my book, it's a serious obstacle. IMHO, hardware vendor support for Linux is necessary for Linux to become mainstream desktop system. There are three ways for a hardware vendor to provide such support- either the vendor publishes the specs or it writes a binary driver or it writes an open-source driver. In the first case, the hardware would be supported in any Linux kernel, but you as a user have to face a good bit of delay till the driver be actually written. Unless the venor actually writes the driver. Recall that it is the vendor interested in selling hardware, just as much (or even more than) you interested in buying it. This mean also that this vendor is the only one wit the full source to your kernel (and thus the only one in a good position to give you support) - Sensible defaults. You shouldn't dig around a ton of configuration files just to get something simple to work. You may tweak it later, but it should work out of the box. This is getting better, but it isn't there yet. IMHO it's quite there. Care to give an example? XFree86 configuration. Change a monitor from 17 to some old 14 ( say your monitor is broken) and risk just damaging the 14 one or X failing to start. Or change a mouse from PS\2 one to USB one. The values are hardcoded into the configuration file leaving no way for autodetection. Stupidity at its best, pure and simple. What about your distro's X config tools? Last time I tried, Mandrake's DrakeX was useful enough. It is also run at install time. I use Mandrake too. While overall it is a very good distro, part of their Drak* tools are actually exactly what I've described - half-baked underdeveloped POS, Example, please? DrakConnect. sorry for being brutal. It's actually a lot easier to comprehend and tune configuration files by hand then to use these tools. Let's formulate it like the following : for anything that goes inside a distro, if it includes a configuration file, there must be some GUI tool to configure it. And this GUI tool should be INTEGRATED with another configuration tools. Mandrake's tools (almost all) run both in X and in full-screen terminal mode. All of them are availble from the main control panel and from the menus. And you still have KDE control center, GNOME control center and Mandrake control center, with overlapping functions. OK, there are tools in the Cooker enabling embedding drak* tools into the KDE control center. The lapping functionalities are (IMHO) because the kde and gnome control-centers should have nothing to do with system-administration. A GUI tool should not be
Re: the problem with LINUX
Hi On Sun, 12 Jan 2003, Shoshannah Forbes wrote: On Sunday, Jan 12, 2003, at 01:19 Asia/Jerusalem, Tzafrir Cohen wrote: I know tools like apt that help, but they are no good for computers with no internet connection, and are horrible over dial up. apt-get --recon --download-only install package Will print what you need to download the files required to install package. This gives you a nice list of URLs to go and fetch. Ah, but the other computer is not running linux (it is not my machine). On the computer that needs to download I hope they improve. (ROX desktop http://rox.sourceforge.net/ addresses this issue with application packages similar to what can be found in mac OSX) Nice, but totally misses the point. Dependencies are here to solve a problem (I've just installed the program foo and it dosn't work can you run it from the terminal? terminal? yuck. well, OK. double-click on terminal icon, p-r-o-g-r-a-m-enter. I see something about failing to load a library). How do they solve that problem? Application bundles have are the needed resources with them- in what looks like the user like a single file. You won't have that problem in the first place. I know- I have used this system myself (on osx). And it makes install and uninstall a snap- to install: just copy the file to wherever you want it to be. Want to run the application? Double click that single file . Want to uninstall? delete it, and if you want you can also delete it's preferences file from ~/Library/Prefrences This way, things are easy to understand: you always manipulate one object, what is going on stays clear, even for the humblest user. This is one of the things that makes Mac OS so friendly. Why not copy? Easy to understand, but messy. The whole point of the linux FSH (File System Hirarchy) standard is that the packaging system is good enough to keep track of files. Therefore there is no problem with cluttering /usr/bin and /usr/lib : you can easily tell to which package a file from there belongs. This is very useful what you think of backups: On a proper system you need not backup /usr . You only need to backup /var and /etc . With packages you'll also need to backup $packs_root/pack1/var, $packs_root/pack2/data and $packs_root/pack3/user\ config But RPM does not attempt to resolve dependencies. This is a GoodThing: rpm should not be aware of the extra complexity in the existance of a repository (more than one? an up2date server?) of packages and how exactly to decide which of them to install. In theory- you are correct. in practice, this doesn't work, especially for the novice user- RPMs just fail due to dependency problems way to often. Think again about my Grandmother- she does download applications from the internet. Do you really thing she would be able to download and install a program on linux? Without someone holding her hand? Again: this problem is caused because people use rpm directly. Where did that RPM install the application? rpmq ? kpackage? rpmdrake? Any information that is available in a command line program can be made avilable to some GUI. In this case such GUIs exist. And how is my Grandmother (who uses a computer) supposed to know this? And why do I need yet _another_ tool to find this out, and not from the WM/OS itself? The above was information about RPM packages. Your grandmother naturally need not bother about rpms, so the question should be how do I run this program why ir 'rpm -ql package | grep bin/' important here? answered in the next item. Debian has had a good menuing system for quite a while. This system was later adopted by Mandrake. If a package wants to add itself to the menus, it only needs to create one file and run the menu-updating procedures. This will add it to any programs menu in the system. But how I, as a user, can tell from the menu where the application really is on my hard disk? a. Why is that important? b. look at the KDE shortcut? /usr/lib/menu/whatever ? KDE has a menu editor, IIRC -- 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: the problem with LINUX
Hi :-) On Sunday, Jan 12, 2003, at 02:10 Asia/Jerusalem, Tzafrir Cohen wrote: On Sun, 12 Jan 2003, Shoshannah Forbes wrote: On Sunday, Jan 12, 2003, at 01:19 Asia/Jerusalem, Tzafrir Cohen wrote: I know tools like apt that help, but they are no good for computers with no internet connection, and are horrible over dial up. apt-get --recon --download-only install package Will print what you need to download the files required to install package. This gives you a nice list of URLs to go and fetch. Ah, but the other computer is not running linux (it is not my machine). On the computer that needs to download You lost me here. The linux machine has no internet connection. The non-linux machine will do all the downloading and burn a CD to be used on the linux. How can one know which files to download? Easy to understand, but messy. Isn't scattering files all over the place messy? Dunno. Sounds like trouble to me. The whole point of the linux FSH (File System Hirarchy) standard is that the packaging system is good enough to keep track of files. Notice- the file system. Not the end user. Therefore there is no problem with cluttering /usr/bin and /usr/lib : you can easily tell to which package a file from there belongs How? (for the middle ground user, not the super power user). In theory- you are correct. in practice, this doesn't work, especially for the novice user- RPMs just fail due to dependency problems way to often. snip Again: this problem is caused because people use rpm directly. * I guess I missed some basic stuff. Then what are RPMs for? * I don't think that my Grandmother would be able to use graphical wrappers for APT- they are still too complex. No to mention that many applications do not appear in a repository. The above was information about RPM packages. Your grandmother naturally need not bother about rpms, so the question should be how do I run this program I know my mother wants to know where the application she installed is. She has asked me to show her how to find out (in Windows). But how I, as a user, can tell from the menu where the application really is on my hard disk? a. Why is that important? Why not? Maybe it makes me feel better? b. look at the KDE shortcut? /usr/lib/menu/whatever ? * I am not using KDE (and who says she will?) * Why the user needs to go to a completely different place to find information about the object? BTW, I admit that I still don't understand the logic that decides what to put in the user home directory and what to put in /usr/lib * Again, linux has no middle ground between know nothing, don't care and super power user. -- The News, Uncensored http://www.tellinglies.org/news/ = 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: the problem with LINUX
On Sat, 11 Jan 2003, Eli Marmor wrote: Focus ALL the efforts to improve the compatibility issues: * kernel, device drivers, etc. I thinkthat the most important events for the friendliness of Linux in the recent years, were the launch of Linux 2.2, and the launch of Linux 2.4. And hardware is not the only compatibility issue related to the kernel: I think that the fact that NTFS is still only read-supported and not write-supported is severe. And there are many other examples. I think Mandrake - latest versions is much better than what I previously encounters. It detects and configures correctly all the hardware available on the machine on several installation I head or experienced. Furthermore, this is the i386 we are talking about. Like Moshe Zadka said it is a collection of incompatible hardware components from different vendors. Expecting it to work 100% of the time. * Better filters, from and *TO* Windows applications (for example, PERFECT filters for WORD, Excel, PPT, etc.). And support for MS protocols and formats (e.g. better emulation of Outlook in mail apps, so an organizational Exchange server can be used better by Linux users). Agreed. Let me switch back. This is always a good idea. * 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 CONF files, 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 the same: COMPATIBILITY). Over my dead body! Config files stay ASCII, so they can be edited by hand. If you want to write an abstraction layer above Apache's configuration that will be less capabale than what Apache provides - fine - do that. Most users who'll use it won't edit the Apache configuration by hand anyways. Those who do will soon be told that it will be hard for them to switch back. I want to keep the configuration files as ASCII because that way the terminal is the computer and I can ssh into it and do everything I can do with the most sophisticated X/KDE environment. This is the UNIX way of doing things and regardless of how much new power users (Aunt Tillie will never play with the configuration or install anything) are frustrated by it, we must keep it this way. Zillions of development hours were wasted on wrong issues, such as KDE/GNOME (although we all enjoy them); Now is the time to start working on the real problems, before it's too late! Relax, Eli - it's never going to be too late. Linus has so many bigot users who use it because it is a superior system technically and won't trade it for anything else. I encountered someone who used Linux to test Infiniband (network devices of 2-3 GBits) cards and used g++/gcc, Emacs, CVS and other tools and did not know a thing about ./configure;make;make install or RPMs. Whether we conquer the home computer market now, later or never makes little difference, as Linux is already widely used and NT sucks in comparison to it in much more ways that Linux does relative to it. Children will have little problem using Linux instead of Windows. And they will find editing obscure ascii files fascinating. Microsoft spreads a lot of FUD regarding the supposed superiority of Windows. But this FUD is becoming less effective on the general public who see even not-too-intelligent users use Linux for quite some time. It all depends what are you doing with Linux. I once upgraded half of my Mandrake system by compiling the SRPMs. I'll doubt someone else who is not a hard-core developer like me will need a newer package. And I believe Microsoft wishes to switch to Linux where they have a well defined POSIX, LSB, X and KDE or GNOME standard that has been around for users, and they can build nice user-land applications over it, and get rid of the over-engineered, over-complicated, under-understood, 50 million LOCs and growing and pretty much dysfunctional operating system known as NT. They can translate everything (consultants, certification programs, services) to Linux, contribute about 5 developers in each one of its layers for good measure (who'll develop open-source GPL/LGPL/BSD code) and then have a nice stable interface that they can use for years, and compile on every other UNIX or Linux version as well. I'm not saying Windows is not superior to Linux in some respects. But as a general rule programming for Linux is much less frustrating that with the Win32 API, MFC, VB, COM or all the other Microsoft APIs, some of which Microsoft can distribute for Linux as well. Once the Linux market is large enough, we are going to see MS products for Linux, and
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]
