Slashdot Mirror
How to Fix the Unix Configuration Nightmare
jacoplane writes: "There's an interesting article on freshmeat talking how sorting out some kind of standard for configuration could really help Unix systems could be more user friendly. The article points out that since Apple has managed to build a quite usable system on top of NetBSD, it should be doable to do the same for open-source interfaces."
I never thought I'd see "Linux" and "streamline" in the same sentence.
I'm making a unix from BSD, rewritting the kernel to an exokernel and replacing the GUI.
Does anyone have any suggestions?
- Kaos games and encryption systems developer
Uhrm... isn't OS X derived from FreeBSD? Or isn't this adressing OS X?
... HP, SUN and DEC tried that once and again and ...
failed everytime
I never thought I'd see "Linux" and "streamline" in the same sentence.
_________________
EBAY SAFETY TIPZ!
Let's copy what Apple did.
There are situations were I've wondered why they went off and created their own configuration file format just for that one application, but that's not too common. The problem with a universal format is that each application need to do different things. Typing ALL apps to one format would in many cases make configuration changes more difficult.
i.e. instead of changing one thing, you have to make the change for every interface/terminal/etc it is running on. Just an example mind you.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
These days, one can usually get away with the "./configure; make; make install; " routine and not need to worry so much. In any case, some of the charm of Linux does lie in your being able to tweak things. And Apple had the luxury of making one decision about software questions and implement them across all hardware.
CHARGE FOR YOUR WORK!!!
If there is good enough revenue people will get paid for doing boring stuff like unify config files.
Except for a few exceptions most open source software is useless, mainly because boring or time consuming stuff simple don't get done. This include good user interface design, documentation, in-depth testing (both beta testing and class unit-testing). Producing software is not just a matter of writing code.
Do you realize if Linux only had 50 types of hardwaree to choose from, it would be a dream to configure. Shit, even WINDOWS would be a dream to configure if they adhered to a HCL.
If you're not a Liberal in your 20's, then you have no heart.If you're still a Liberal in your 30's you have no brain.
I think if all linux distros' could agree on one set of configuration programs , like YaST and Sax on SuSE, then it could be the first time to biting into the Windows market.
Everyone who uses windows knows about the control panel , no matter how stupid they are. Why can't like have a similar system on all versions ?
Cruise TT
Just be picky about what friends it chooses!
I am into the copy and paste.
Have a look. webmin
The part that makes such a system really useful however, is a standard agreement of which information is stored and what it means. This is where the Windows Registry falls down. And Unix is even worse, because all it has is some common soft-of-agreed-upon shell variables, like $EDITOR etc.
Apple is able to do this better because they set the standards for the OS (even more than MS). The can have one central "registry" for something like default associations of MIME-types with particular applications and define an API so every application can use it and a user doesn't have to change his settings in his browser AND his mail client AND his ftp client, etc.
Given the diversity of the unix crowd, the latter seems difficult to me. Maybe they can include it as part of LSB for a start?
Idempotent operation: Like MS software, wether you run it once or often, that doesn't make it any better.
In the writer's outline section he has a few bullet-points that scream "XML!" (I'm paraphrasing here):
1. A core system to handle parsing, verification, etc. -- If app configs were based around XML, you could use any of a dozen XML parsers out there.
2. A configuration format description file. -- Hmmm, sounds like a DTD...
3. OS-neutral. -- XML was meant to be portable from the get-go.
The other items lined up pretty well with what XML is all about as well. Anyway, that said, I'm not so sure this'll ever happen since, from a developer's point of view, it's a lot simpler to slurp in a bunch of lines from a text file with fgets and chop it up into words than to have to somehow link in a third-party XML parser.
Is Ganymede a starting point for a complete centralized configuration tool?
Bush's education improvements were
I recall some discussion earlier on /. that talked about how OS X-on-NetBSD wasn't as clean as many thought. In fact, it turned out that the /etc was pretty much bare except for some file structure that was like a Windows registry (except for it was for Mac). Can someone verify this?
JavaBeans does everything that this article wants now. It suports introspection, special field editors... Then you can build general purpose editors for any type of user. Couple this with javaspaces, for storage. JavaBeans is a shipping technology, but JavaSpaces is still a bit dodgy last time I looked (6 months ago.) Sun have spent alot of time getting this right, there is no good reason te reinvent it.
I am the NUL and the DEL, the beginning and the end.
As it has been already said in a comment on [fm], the answer is GConf:
it has the ability of configuring apps and has the option of using a DB or XML as a backend.
Start porting!
Its based on NeXT. With a NetBSD compatablity layer.
autopr0n is like, down and stuff.
I was thinking this morning how I hadn't udpated my Apache server in a while, and wondering whether I should apt-get the latest version (Apache is kind of important for security, as it's the only open port on my system from the internet). However, I've done various tweaks to config files which would get overwritten if I accepted the Debian standard file, but I don't want to miss out on any new settings that could be important. I know I can do a diff, but that's effort I'd rather not have to go through.
This kind of situation is where a registry-like interface is useful; the install program just has to do a quick 'if-not-exist then add' to any new settings and leave the rest alone (or ask if you want an overwrite of all settings, with appropriate disclaimers).
This kind of thing is difficult to do in a flat file split into different sections (if there isn't a concept of sections, you can just tag the setting on), but trivial in a registry structure, especially when the tool (dpkg-upgrade/apt/rpm) has to handle all the different file formats. However, linux/Unix users would rebel en masse if the registry got inflicted on them (with damn good reason! I like being able to fix problems from single user mode using vi!), but some form of layer between the text file and settings may provide the best of both worlds (programmatic ease and editability). apt/dpkg/rpm could use the interface to add/modify settings without splatting your custom tweaks while still adding the new required settings.
Unfortunately, we're starting from a difficult point, with thousands of applications with many different requirements for their settings. Hopefully we can get some covergence over time.
Because there is only one captain on the ship, Apple. Good luck fixing it in the Linux world. The only way it might have a chance of working IMHO is if such a proposal gets included the Linux Standard Base. Here's a bold idea, why not copy the way Apple does it??? No need to reinvent the wheel...
-adnans
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
The complaints about Webmin is that it isn't perfect. It doesn't solve the desire for a universal config mechanism or encourage the editing of files directly. OK. It doesn't. Yet, it exists now and is a lifesaver when using multiple UNIXs. Anyone who wants to know what any Webmin module is doing probably also knows how to use find -cmin, ls -lart, or read the module itself since they tend to be in Perl.
When a universal config comes along, I'll use it and guess what -- it'll work with WebMin.
Webmin might not be the right thing, but it is good enough for a vast number of uses.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
"gconf" does exactly what the Freshmeat article describes: a unique way of storing configuration. Its frontend is abstracted from the backend which uses a hierarchy of small plain XML files per default but could also use a SQL database or a LDAP directory.
LDAP is nice on its own, too, with configuration being stored platform- and host-independently, as well as global, group-specific and user-specific settings. Netscape Roaming works this way.
Who hasn't though this? Unix/Linux config is a mess. Diffrent files in diffrent folders with diffrent formats. Sure it's all plain text, but who has time to learn diffretn config formats/languages for each program they want to use?
As for hard to do? I don't see why that would be the case. Just a little bit of XML and viola.
There are a lot of things in the Unix world that are hard or time consuming to do just because they can be. sendmail.cf. hello!?
autopr0n is like, down and stuff.
A brilliant article, and a subject which I have tried before (with little success) to broach with various OpenSource developers. Unfortunately the comments demonstrate the lack of understanding that is all too common in the free software world: an inability to distinguish between apis/formats and software implementations; and an unwillingness to move to a more user friendly system.
GConf and Webmin, for example, are not solutions that address the problem posed by the article. Other comments completely lose the plot: this is about a common configuration format which can use metadata to provide for configuring just about any application, it is not about creating an all-encompassing configuration that will give settings to all applications everywhere for all time.
Gconf is half of the solution at best. It provides a library (common abstraction) for accessing the data. But an application still has to have explicit knowledge of the data in order to act on it. A configuration framework describes this knowledge to allow any compliant application to act on it.
Sometimes an example is worth 1000 pictures (and hence about 1000000 words), so consider a simple packet filtering application with an ACCEPT list and a DENY list, which can listen on several interfaces.
Such an application would have a meta-data configuration file (say /etc/conf/meta/filter.cfg) which specifies:
section name=interface count=multiple type=ipv4 ; section name=accept count=multiple type=cidr ; section name=dent count=multiple type=cidr. Now any application can access the packet filter's meta-data file, and the real configuration file (say /etc/conf/filter.cfg), and understand the meaning, to a degree, of the configuration. The types "ipv4" and "cidr" will have to be primitives for the configuration framework.
Thus a general configuration application could present a tree which has three branches (interface, accept, deny), each of which displays a screen with a list. Appropriate entries can then be added, modified or removed, reconfiguring the packet filter without the configuration application having any prior knowledge of the filter's configuration or requirements.
With adequate forethough (for the categorisation and types required) such a system can be extremely powerful. A single configuration library can be used by the application, as well as GUI and CLI configuration clients. You could easily have a command in a script: config pktfltr add -section interfaces -value 1.2.3.4 .
A common library like this can also provide powerful features that a lot of applications lack, like local (user) settings which override global defaults. The library can maintain global, group and user configurations for each application, and getting/setting preferences will take the overlays into account.
Implementing such a system would also provide an ideal opportunity to introduce configuration versioning. CVS (for example, or arch, which includes directory versioning) could be used to maintain various versions of the configuration files in /etc/conf.
Arguments about diversity are largely moot. The data format is independant of the data in any well-written program. .INI files, Bind-style files, XML files and SAMBA files can all represent the same information, but they look different. Some are arguably more efficient in some situations. Even the feared Windows registry has the same functionality ... it just makes the (fatal) error of storing everything in a mostly inseparable datastore (sortof like an /etc/conf directory in which you can't treat the various files separately).
This is a suggestion which needs to be followed through, and supported by the community.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
"Ernest Prabhakar of Apple Computer informed attendees at the USENIX BSD Conference earlier this week that BSD (upon which Mac OS X is based) is now "three times more popular" than Linux on desktop computers."
http://www.osopinion.com/perl/story/16382.html
That link isn't particularly helpfull. I hope you don't expect me the dig around on that site for hours to find the answer.
Perhaps you could give me a more precice link.
The only thing I could find was: But good looks are only the beginning. At the foundation of Mac OS X lies an industrial-strength, UNIX-based core operating system--called Darwin--that delivers unprecedented stability and performance. Darwin provides Mac OS X with powerful, advanced features such as protected memory, preemptive multitasking, advanced memory management, and...
Etc. Didn't say anything about what it was 'based' on.
autopr0n is like, down and stuff.
Why fix it? It's good right where it is.
/like/ having daemons and programs having their own configuration file. I like having to be able to manually configure something and fix it myself, without having to fight with some meddling front-end. I like learning how configuration is done with each program. I like applying existing text editing and stream tools to work with configuration. This is the way it should be done, and this is why I like Unix far more than other OS's that aren't predominantly CLI-based.
I
Don't fix it. It's not broken. Things work great as they are now. It's not difficult if you want to learn how to do it. Your "Unix Configuration Nightmare" is actually an elegant symphony of applications, clients, daemons, sockets, and streams that is UNIX. Take it or leave it.
:)
And you know, when I was your age... wait, you get my point.
"[T]he single essential element on which all discoveries will be dependent is human freedom." -- Barry Goldwater
Unix is generally well documented so you shouldn't have any problems. The instructions for configuration files
are in the man5 subdirectory, and the system admin utilities are documented in the man8 subdirectory.
Sure, installing software is easy. Unpack and compile. We are talking about configuring software.
Like getting sendmail to rout and forward mail, apache to serve up web pages you want, BIND to bind names to IP address, etc.
These tasks arn't "hard" or anything, but they do require a lot of reading on the part of a Newbie. In the windows world (don't know much about OSX) Most of that stuff can be done via am intuitive GUI.
Flame me if you want, but I'd greatly prefer a system that didn't require me to learn diffrent config file formats for each service I want to have running... or deal with a hodgepoge of 'easy config' program hacks.
A simple, standard configuration system is definetly the way to go.
autopr0n is like, down and stuff.
Hardware, for the most part, can be automaticaly configured. In fact, I've never once had an issue with hardware configuration in linux (except for tonight, ironicaly. cdrecord can't find the burner I put back in the system, even though it worked before)
.INI files. geez.
The problem is software config once you've already got the machine setup. Programs generaly have diffrent formats for their configuration. even windows 3.1 was better then this with their
autopr0n is like, down and stuff.
Your post was a bit vague on the name of the actual product you are endorsing...
;^)
(I just counted the word 'Webmin' like 17 times in your post...)
Actually, I couldn't agree more.
A couple of weeks ago, my boss called me 2 hours before I was supposed to be at work to tell me that something needed to be fixed on the server. I literally rolled over, grabbed my laptop, logged in using the ssl option, fixed it and went back to sleep.
Now you might say that all I really needed was SSH and VI, but I hadn't had any coffee yet and Webmin just required a bit of clicking. It rarely screws up and doesn't mess with your config files.
I wrote a bit more on it on my web site a while back - scroll down about half way.
Cheers,
Jim in Tokyo
-- My Weblog.
I've been thinking about this for a while and definately think that there needs to be various elements to a Unix configuration system:
l
1) The concept of local and group configuration. There needs to be a Meta config file that specifies what individual users can and can't configure. So for instance, if a company wanted to allow users to configure their word processors however they wanted, exect that they couldn't make any changes to the dropdown menu of corporate document templates, that would be specified in the Meta file.
2) A configuration server. I see no reason why this couldn't work with http to deliver XML config files to individual workstations. The Meta files could reside on the server, the local files on the hard disc. You could imagine in this senario that in order to configure your machine all you would have to do is enter the appropriate URL and press go:
http://intranet.company.com/configs/standard.xm
Then you could have different configs for different types of staff, and supported and unsupported configs (from the point of view of IT support).
You could also perhaps have 'approved' config files for supported hardware.
Having this type of Meta config file also allow IT support to have a clear idea of all the hardware used.
I know that probably lots of people on Slashdot don't like the idea of IT support having control over the config of their machines, but big companies like it and if Linux is going to conquer the desktop then this is the type of tool that will help get it there.
In an interview of an IBM director, I asked why their then current OS had no GUI (when Windows was chipping at the userbase). Reply:
Mindsets change - at the speed at which glass flows
This is not a signature.
On that thread what the hell is /usr/etc used for, or /usr/local/etc? won't it make more sense to move /etc here instead?
Do we really need a central registry type file like the article proposes, surly isn't a front end enough, I can't understand what difference this would make. Having a central file which contain's everything like System.dat seem's to be a major security floor in windows since if you can crack that file you pretty much have root on the machine. Not being able to set different permissions for something like fstab or shadow would be pain. Although to be fair the article proposes it as a backup. If it ain't broke don't fix it.
Apart from these questions I think that this was a pretty good/fair article, although I thought that it was a bit unfair to compare linux to windows/OSX since they are completely different OS and something like creating a central config app might work to make linux less customisable IMHO. Most distro's tend to have app's along these lines anyway, what the hells wrong with DrakConf?.
Pianist : Some jerk whos taught themselves how to type in rhythm
You expect the open source community to use Java!? It's plain C all the way! (just look at Genome... hell, there are some guys (dotGNU IIRC) who want to implement .net in plain C!)
:P).
Ok, so that's not entirely true. Some OSS people like java (Freenet, Apache Jakarta). But I seriously doubt that anything Java based would ever make much inroads in the free Unix world. (Maybe Solaris could make some headway, though
And there's a few good reasons why it shouldn't. Java is a little top-heavy, and it's not platform-neutral, it's its own platform... and connecting it to other technology via the JNI is a pain in the ass. I tried JavaBeans once, on a windows box at work. It was a nightmare. I ended up using TCP/IP for interprocess communications. (then again, TCP/IP might not be a bad choice for a central config server, you could do things like remote config. hrm)
Anyway, I think XML plus some schemas might go a long way to doing what we want, without requiring everyone to link in a JVM.
autopr0n is like, down and stuff.
The people at Apple had it a bit easier than everyone else in the *nix world. The had only to support a limited range of hardware and configurations to support due to the fact that OS X run on mac's and only mac's. The diversity of hardware options in the "real world" of *nix such a configuration is way out there IMHO.
When talking about GNU/linux and the LSB we have a change to make it work, but is still far away.
I don't see it happening across aix, solaris, Tru64 and the other commercial unicies in my life time.
That my two cents
/Lehmann
They built in on top of FreeBSD, not NetBSD. Go to their website to verify the claim. Or did someone fall asleep at the News Verification Department yet AGAIN?!?!
Seems like someone is talking without knwledge about anything related with Linux.
If you count the number of crashes and problems of a Web Server Win 2k with IIS it's a shame compared to a Linux with Apache.
It also seems that you don't know anything about admin. Someone who's admining must be competent enough to solve the problems that happen. If you want a transparent system to admin and you don't know anything about how it works then you shouldn't be admining.
There's lots of cool stuff you can do with standardized configuration files, and dynamically generated GUIs are only one part of it. But developers are not going to change their file formats unless there's a real push for a specific format. Thus, to establish any format, you first have to develop lots of filters to support legacy software. As the FM author correctly points out, such a system would make software configuration under *x potentially much easier than under Windows.
Finally, to all the hackers who fear that this will take away their file-meddling options: If properly implemented, it won't -- and if it does, it will not get accepted as a standard, exactly because of stubborn people like you :-)
maybe the community should agree about common human interface or at least about a common configuration file interface so a kde/gnome/... app can be written using the data for providing an easy setup tool.
i think it would be a good addition to the linux standard base
"It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
I suppose that if you're that ugly, you would have to show the world your ass instead of your face...
BTW, goatse is dead...
I think he shat out his kidneys or something...
- Kaos games and encryption systems developer
The real issue is finding the configuration file; if you're using a distro you're not used to, then one often has to resort to using find. This is exactly what the Linux Standards Base was designed to avoid, and if all distros were to follow this model then I can't see that there is any real problem.
At the end of the day, we're not talking about things like setting background pictures in the window manager, we're talking about setting up mailservers, webservers and the like. If you're not cluefull enough to edit a text file then you're not cluefull enough to be put in charge of setting one of these servers up either.
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
Yes, I know this is a comment on freshmeat (I wrote it).. but it pains me to see so much incorrect/incomplete information here that people just believe for lack of experience with OS X.
/etc (which is a symlink to /private/etc):
/etc and puts it in a
/etc style formats
/System/
/Library/Preferences, Network-wide app prefs (only
/Network/Library/Preferences, and User app prefs go
/etc, as nothing there is meant
---
MacOS X's solution to this problem is a couple levels
deep. There are three (?!) systems for configuration:
(1)
It's still there, used for a few things. But not much.
More or less just stuff that runs before everything else,
or stuff that apple doesn't have much control over, like
Apache.
(2) Netinfo database:
basically takes a lot of stuff out of
"registry", this registry is accessible over a network
connection for remote administration and such. You
can also do some funky server/client stuff with this too.
There's a command line interface to it that lets you
read/change 'keys' and also dump out certain keys in
well known
(3) Property Lists (.plist):
This is the way that just about all configurable
information in MacOS X is stored. There are a couple
different kinds of plists that the Core Foundation
libraries understand, but the most prevalent of which is
the XMLified version, the others are either vestigal or
are used primarily for localization of strings. Every
application (well, bundled app) on the system has an
info.plist file that has application settings that the OS
reads from on app startup, but you can also put your
own tags in there. Applications also have the option of
putting their own tags in the Resources subdirectory in
their bundle, which is the preferred way. OS specific
preferences (requires admin privs) go in
Library/Preferences, System-wide app preferences go
in
applicable if you have OS X Server on the network) are
in
in ~/Library/Preferences.
The Core Foundation framework manages more or less
all of the work. They'll find the plist for you, let you
work with the data structures, and serialize/deserialize
it to plist format. It's really quite nice to use. Just
about all of the data structures in Core Foundation are
serializable, even the property list data structures, so
sometimes you'll see property lists with serialized
property lists inside them.
As far as unified configuration interfaces go, there
really isn't a need for any in Mac OS X.
You're on your own with
to be novice-tweaked anyways (In OS X).
There is a GUI NetInfo Manager and command line tools
to configure the stuff in that database (nothing a
novice needs to touch).
Configuring the plists is primarily done inside the
applications that you use (since it's so easy for the
developer to use Core Foundation to read/write
property lists), there are no separate configuration
programs, but there are command line tools for working
with plists. If you're using the developers kit, you get a
little (not very poweful and pretty inefficient) program
to edit plist files graphically, but otherwise you either
do it by hand with a text editor or the command line
tools and risk breaking things or let the apps take care
of it themself.
BTW, all of the Core Foundation stuff is available in two
flavors: C, and Objective C. The C libraries are pretty
straightforward and work in all situations, but if you're
writing an app using the Cocoa framework in Obj C, it's
way easier.. though there are a few little peculiarities
about the Obj C implementations. The bonus is that
you can use both at the same time, and Core
Foundation types / Cocoa instances are interchangable
by some voodoo that Apple did. If the Cocoa
implementation doesn't work right (As with serializing a
plist that has NSNumber Boolean types), you just use
the Core Foundation implementation and a typecast..
voila, one line of code changed and everything is
happy.
Dozens chime in with different tools approaches and ideas (XML, YAST, linuxconf, etc,etc,etc...)
Guys, that's not a unified approach as defined by the article...
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
There are also third party modules for things like netsaint, firewalls, etc.; the API is out there if you want to do your own as well.
I disable sigs...do you?
I once installed MS PWS and found that the configuration was web-based. I turned off a few checkboxes on the configuration page. Then, the configuration page never appeared again.
I love simple methods for configuration, like plain text.
Migx
... enough said
Could the Unix configuration be made easier? Obviously yes, but that isn't the same as needing to be easier. One of the exciting things about venturing outside of the "user friendly" world of MS is finding out what all of those dot files are for. I'm not a Unix know it all or anything but I know my way around it pretty damn good. I wonder if I'd know more or less about the OS if the install and config were as easy as MS products Some might be afraid to admit it but there is also a novelty to it.
I guess you can't argue that someone shouldn't make the configuration process easier.... I guess that while people like me get their experience from drudging through scripts and text files, people who just want the benefits of Unix can get straight to the point if I install it for them.
I'm selfish though, I hope it gets "harder". Lets weed some people out.
mach+FreeBSD
People keep trying to make out that Apple ripped the entire OS off one of the open source BSDs. Can't people accept that a lot of it is either NeXT derived or from Apple? A lot of it isn't, of course, but the other BSDs copy each other's code all the time. I'm sure the others will start copying Darwin as soon as Apple lifts its non-BSD license (if ever).
If you want more info check out the Darwin project page and the developer site.
This would be really nice for allowing configuration utilities to work on programs they've never even heard of. Imagine for a moment, that the developer of an application provides lots of useful information for each configuration option, such as the level of importance of an option, comments and descriptions, web links, the data type of the variables, etc. in a xml template file that comes with the application. The template could then be queried by whatever tool you're using and provided you have enough info linuxconf, web frontends, dialog apps, etc. could all build an interface by simply reading all those options from the template via some kind of library function.
Likewise, changes to the config could be passed through the library functions, get validated for correctness and then written to disk in whatever format you want. The level of functionality would be such that you could generate white space delimited files, xml configs, or whatever you want and because the template is descriptive enough, comments could be inserted/preserved for those editing with vi.
Now that I think about it, this really wouldn't a rewrite of existing applications, they could simply keep their existing formats and build the template file for other config utilities. Then, if at a later date they decide to drop their own config processing, they use the template driven library to do the processing work. That way backward compatibility could be maintained.
This does nothing to reduce the myriad different configs that you deal with when editing by hand, but it would give the authors a chance to move a more common format later on down the road. And I think it is more useful than trying to get everyone to switch to some unified format that appeases new users.
I have half a mind to try a limited version of this out for handling Apache virtual domains. And it's a lot more fun than hard-coding a parser into your frontend.
I LIKE the configuration nightmare... Keeps the LUSERS out of my way....
/. > dev/null &
luser: how do I install ms-word on my linux box?
bofh: rm -rf
Linux works very well for the people who think knowing their way around the bowels of the system is cool. But if you want usage of Linux to go beyond that minority, it must be far easier to configure (among other things).
I have had an NT4 system with a proxy-server (WinGate) mail-server (MDaemon), a news-server (DNews), a web-server(Xitami), and a firewall (ZoneAlarm). It didn't take long to find out how to configure those programs and get them to do what I wanted (hint: on-line help).
I have yet to get the same configuration running on a Linux-box. The reason? Between working and being together with my family, I don't have enough hours left to delve into Linux' arcane secrets.
Yes, I have a life and I intend to keep it that way. So until Linux matures to a level where I can use it instead of fighting it, it will not be my OS of choice.
My opinion? See above.
My (possible redundant) 2/100:
For every application we need two compilers/parsers: one from text to XML and one from XML to text. This way the programs can keep on using the old text config files (easy for programmers), and a nice config tool could modify the hiracical XML (easy for users).
I imagine that when the config tool is opened for some application the text config files are parsed with the text->XML parser, showed and modified via the config tool, and then parsed back into a text file.
The current system for starters isn't too bad - the configuration files for important system tools are typically well documented (in man pages if nowhere else), and aren't too hard to edit in a text editor. Certainly there is a problem with the use of automated GUI tools for system configuration, but I can't really see why GUI tools are so important.
Consistency though would be a nice thing, if only so that as more programs are used and require configuration, we don't all have to learn more and more ad hoc configuration schemes. There is the potential for the current system to get well out of hand. Consistency is nice from an aesthetic point of view - ad hocery is rarely pretty.
Tools such as linuxconf or webmin don't help the problem, they just obscure it. Often badly! (Don't get me started on linuxconf, ugh!)
The earlier suggestions of XML, or a recognised subset of XML, together with XML schema to describe the formats, seem ideal as far as file formats go:
- It's standard and well-documented.
- There are a large number of parsers that work with a useful large subset of XML, for many platforms and languages.
- In a pinch, it's not hard to write a quick and dirty and correct-enough parser from scratch on an ad hoc basis, to parse your own particular XML-based configuration files.
- It's human editable (or should be, if used wisely).
- It is rich enough to encompass all the text-format configuration files currently in common use (under the Linux-based operating systems I know of at least).
The big problem of course is inertia: changing configuration files is a big change! Personally, I think the cost though would be worth it in the long term.The important thing to me is that there is no API specified as mandatory. While a standard API for accessing and manipulating configuration data would be nice, requiring it to be used will not only make adoption of a standard config format slower and harder, but will also limit software developers to the tools for which the API has an implementation. I'd go for:
I also agree with the earlier comment promoting the use of ~/etc over dot-files. Makes good sense! Again, it's only inertia that will make such a change difficult. Though if other changes are going through ... in for a penny, in for a pound!
Lastly, whatever scheme is adopted, it seems to me essential that there be some flexibility in where the configuration files are located. Standard places are important, but there must also be some way to say to an application that their config data is in /usr/local/etc, or in /opt/package-name/etc, or wherever. This is necessary for sane package isolation and management, especially if not all software on a system is maintained by someone with superuser priveleges.
Name a piece of current (not ISA etc), statndard (not some home built/unknown vendor PCI card) PC harware, other than the motherboard or the processor and it will most likely work on Mac OS X. It may fall back on a generic type (missing some features) but it will most likely work. Macs support: PC133 RAM, ATA hard disks, PCI cards, AGP cards, VGA monitors, USB, IEEE 1394 (FireWire), etc. I think that would be more than 50 types of hardware. Don't confuse the fact that the iMacs are closed with other Mac hardware. The G4 Towers won awards for how easy they are to open up and upgrade. There's a large handle on the side of the case that you pull and that side of the computer lowers down with the motherboard attached to it, giving easy access to all components.
Could it be that Macs are easy to configure because Apple engineers are clever?
Note: I'm ignoring the fact that this article is about software not hardware configuration.
Check out some more myth debunking.
this is off the subject, but I noticed that the MAC OS X does not use the same perl program that you find in Linux. Does anyone know a way to fix this on the mac os x. -
Hmmm... this would never fly because if it ever came close to a reality someone would cliam a patent on it. Web-based would never work because it would have to be designed to avoid those pesky hyperlink licensing fees (ha ha) and the linux and BSDs couldn't afford that.
Congratulations. Now you understand how the real world works. Not everyone wants to be an administrator/computer geek/Linus. And why should they? Things like Webmin make it easy to configure a machine so the majority of users (so called unwashed masses - heh, the "masses" probably think the same thing about computer geeks) can get can back to what they were doing. Having a better set of config files is a fine idea, especially for sysadmins, but will the majority of regular users want to fiddle with that? No.
User applications can have all their information and binaries pertaining to the application in one resource folder. For example, all things related with a DVD player will be in one folder and not scattered across /etc, /usr/doc, /usr/bin /usr/share. you still have /etc, /sbin, /user/sbin for daemons and stuff.
The GUI will hide everything that's in the application's folder and represent it as an icon that you can click on (which will launch the reall binary that's nested inside the folder).
The CLI doesn't hide or fake anything. It shows you what the directory system really looks like.
Config files for applications are in XML format. You can edit them using a CLI tool (vi) or a GUI tool.
I think these features will help the common user. It doesn't take away from the fact that OS X is still UNIX and that haxors still get to use the CLI.
bah. start over
It took MacOS X for people to realize that this was a problem in UNIX? Please.
/etc/registry.conf. There is no reason it has to be binary.
The reason UNIX and UNIX applications are hard to configure, in most cases, is because Open Source programmers are lazy.
This is obviously a blatent generalization so I will explain.
The old adage is that an Open Source program gets written when a programmer has an "itch" they decide to scratch. The problem is that very few people are itched by configuration. You may write the best web server in the world (Apache!) but by time it comes to writing the configuration manager for it the volunteers start falling away.
It isn't very fun writing a bunch of dialogs, windows, buttons and such to make a nice configuration for a program. It's kinda like documentation (and we all know the state of docs for many UNIX programs).
I see examples of this every day. I have a Mac OS X using friend who sends me the URL of every new program he decides to use. It's incredible how many of them are UNIX ports with a beautiful configuration manager stuck on. Mac programmers hold themselves to a higher level of user experience and UNIX people need to get on the boat.
What's needed isn't a global, all dancing, all singing configuration system. What is needed is responsibility in programming.
P.S. Everyone always whines about the Windows registry because it's binary, you can't edit it blah, blah, blah... But the fact is: It works. The average user never cares to edit it because they config their programs from WITHIN their programs. If something is truly needed, do the Windows registry in text file format. Make it
You can hack out a CSS file that would describe to any XML enabled web browser how to display your file in a much more readable format and XPath lets you slice and dice an XML file however you want to. I've run across an XML enabled grep-like program too, though I've never actually had much need for it.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
We keep trying to help out newbies and possibly get the old PHB to take a second look at *NIX in general by making/writing applications and configuration frontends to make *NIX easier to use/configure. This is O.K. if this is your goal in doing so. If this is the goal, I think we are scaring off the PHBs of the world more with poorly written commentary, like the paragraph of this news article. If /. is supposed to be this pinnacle news site for nerds, and in doing so it basically (in the minds of PHBs) represents the "nerd population", then we need to _at least_ use correct grammar. I see this "bad english" used in at least 4 /. articles a day.
Quick example taken from the above docs:
<?xml version="1.0" encoding="UTF-8"?>t .dtd"><dict>
<!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyLis
<key>Year Of Birth</key>
<integer>1965</integer>
<key>Pets Names</key>
<array/>
<key>Picture</key>
<data>
PEKBpYGlmYFCPA==
</data>
<key>City of Birth</key>
<string>Springfield</string>
<key>Name</key>
<string>John Doe</string>
<key>Kids Names</key>
<array>
<string>John</string>
<string>Kyra</string>
</array>
</dict>
</plist>
Note: The <array/> tag is specifying an empty array.
Making *NIX systems easy to configure maintain, manage and etc will be the downfall of the IT industry, Green Skinned *NIX admins everywhere will revolt the people tring to bring *NIX to the masees.....
Alright so im joking...big suprise...
I think this would be a good thing all in all, IF they DONT MUCK with my existing configurations. There are many things that can be tweaked far beyond the iditot proof gui configuration tools on other OS, In windows you can resort to registry tweaking for some items, others you just cant do a damm thing about, its those thing Im afraid will be removed from my control.
Dummning down on the surface is fine, as long as they dont do it to the underlying configurations. I still cant figure out how the hell to edit (or find) the samba configuration file on OSX, Now granted its not my machine, and I dont really use BSD, so im not suprised. But does it even exist ??? A I am used to it on Solaris and Linux ?
Sig went tro...aahemmm.....fishing........
Folks, NetBSD advocate that I am, I must point out that Apple used FreeBSD. Or am I wrong about that? I always heard it was FreeBSD.
Actually it was a FreeBSD userland built on top of a Mach kernel. Somewhat similar to what GNU is attempting to do with Hurd. (In fact, there's been work to make the Mach kernels underlying both systems interchangeable. Hurd may run on PowerPC hardware sooner than you think.)
Secession is the right of all sentient beings.
I think the answer here is to have a standard interface that everyone will agree to use. This could be a very simple application that would be skinnable/themeable for any distro to add their own personal touch. But at the end of the day, the single standard app should use the same configurations on every platform.
The example, that I think should be followed is that of the Microsoft Management Console. The MMC lets developers provide 'snap-ins' that let you control their apps from within the same console you use to configure Windows itself. Anyone can write a snap-in to do anything you want. The snap-in doesn't dictate how you write your app, or how you store it's configuration info. But because the MMC is used by everyone runnning Win>=2K developers have a standard that is in their best interest to write for.
That's all Unix needs. Then the developers will write their own snap-ins, and you won't have so many different projects trying to build GUIs to configure so many applications that may change their configurations at any rev without notice.
about OS X and its .plist format, which is XML
Here is PropertyList.dtd:
-----------------
http://zephc.2y.net/PropertyList.dtd.txt
-----------------
and here is a small sample config file. The file name is 'com.apple.CocoaExamples.Sketch.plist' so you get an idea how the naming scheme (which is not enforced, just highly recommended) is like java namespace naming for custom libraries
-----------------
http://zephc.2y.net/plistexample.txt
-----------------
Now, linux people, get to work copying =]
Let me take this time to say that Aplle, with one fell swoop (with OS X) created a totally standardized, understandable way to configure any GUI application in a very complete way. You can store anything from the window coordinates (which while it sounds superfluous, its very nice to have a window you use a lot pop up in the SAME place every time) to, well, any other type of data you want to be persistent. Not just a few important data, but everything can be stored and reread in a totally consistant way.
Once the parser is ready, many developers and colaborators should start a porting projects. If the parser API is good, porting would be straigtforward.
Every program should have a configuration file in /etc/conf, and the format
for each parameter should be something like this:
<parameter>
</parameter>
Some notes:
I agree with almost everyone: this is something very important and useful to do. It should be an Open Source project!
No XML is not suited for this. XML is not a panacea. XML is for representing large amounts of structured data whose primary purpose is to be interpreted and transformed, and frequently eventually presented to some user. The semantic, syntactic, and performance overhead of XML is WAY too great.
Instead we just need a simple text-only configuration file format which has support for a hierarchy of values (this gets you pretty much what XML would give you). It would also be nice if the format was position-independent, so it could be streamable. A proposal was posted somewhere, but now I cannot find the link. The format could be as simple as:
toplevelkey=value
[tab]branchname1
[tab]branch-key1=value
[tab]branch-key2=value
[tab][tab]branchname2
[tab][tab]branch-key3=value
you get the idea. Please don't throw XML into the mix, it will not simplify things.
It's 10 PM. Do you know if you're un-American?
I think most of us agree that the conf system is getting out of hand. With the proliferation of distros, its only going to get worse.
A solution would be to first implement a generic "configuration" library. A small, efficient library with various language bindings. It should provide the coder simple functions to manipulate the conf file, sortof like "getopts".
Once the above library is implemented, encourage people to use it in any new projects that they are starting. At the same time, volunteers (ie you) can work on "porting" the existing packages over to using this new fangled library.
Over time, this approach should work.
There seem to be two threads here. One for consistency of configuration files, another for graphical configuration tools.
Some consistency might be nice, but in the end would probably be quite irrelevant. Imagine trying to come up with a unified syntax to incorprate Apache, Netnews, Sendmail, XFree, and Gnome. It would turn out to be a logical OR of all the configurations, and wouldn't save anything.
Read the docs, follow the instructions. Or is our society forgetting how to read? Oh yeah, we like things easy. Or what we *perceive* as easy. I argue that easy is different for everyone. For me, easy is being able to fix something with a few quick keystrokes in vi. I find navigating up and down many layers of menus and submenus quite burdensome and slow. But hey, you go tinker with GUIs and pull-down menus. While you're doing that, I'm finished and getting on with my life.
That said, I think the beauty of current system is that you have options. You can use Webmin or Linuxconf, and I can use a text editor.
What would be a real pain is having to reinstall the whole OS because a hard drive error during a power outage corrupted a single line of your X config, and without that, you can't get to your vaunted GUI to fix it. It would be a simple fix with a text editor.
Besides, pointing is impolite.
:wq
i would take a look at the menu system that was (is) used on novell servers. monitor.nlm, install.nlm/nwconfig.nlm, and inetcfg.nlm are the big ones, and most of the extra services have a menu system also.
as a novell trainer, i've found that once people understand what they are doing, using the menus are easy. sometimes in advanced features there is a 'where was it?' problem until they get used to the function.
the greatest thing about the novell menus are consistancy. the same key strokes, same actions, etc.
there are some *nixes that have menu systems (i've used sam on hpux) but none of them have the ease of use that the blue novell menus do.
eric
In fact a GUI is not too much different from a somewhat readable text configuration file (which is everything except maybe sendmail.cf). If things does not work, most of the time is spent figuring out "why it doesn't work", rather than spent in reading the configuration file format, which only a small part need to be actually read for tweaking.
Therefore I suggest the following:
1. The docs should contain something about "when things breaks, where to look at (and what to read)". When some gateway are not correctly configured, telling me where to tcpdump is more useful than giving me another GUI. Also, for each config option, try to give an example that shows the difference with and without the option, especially when the option is hard to understand.
2. Software should give better error messages. When a net admin get a cryptic "Invalid argument" (EINVAL) from route(8), how does he know whether he has mistyped the command, misunderstood its syntax, or added a route that the kernel didn't like for one of 10 different reasons?
3. Software should come with enough configuration files that should in most cases basically work. If a sys admin have to write a 30-line config file all by himself just to get "YetAnotherHTTPd" serve static pages to localhost, and add another 20 lines to make it serve CGI, he will probably try something else before getting YetAnotherHTTPd to work. What sysadmins should do is things like setting security by Copy'n'Paste'n'Uncomment, and performance tweaks.
Apple based OS X on Mach os (kernel mostly), and FreeBSD. FreeBSD goes back to bsd 4.4, not NetBSD.
All that and I don't use any of those...
"And we have seen and do testify that the Father sent the Son to be the Savior of the World"
1 John 4:14
Unfortunately, the infighting, politics and lack of discipline of distribution maintainers have made it nearly impossible. In spite of the fact that DJB is a bit strongly worded in his opinions , he is not far from the truth here. In the 20+ years I've been using various flavors of U*ix, I groan every time I have to use a different distribution because the developers could not be bothered with maintaining a globally consistent directory structure, and simple things like command line flags on common commands (e.g. the ps utility) are rendered inconsitent because two groups of developers think cannot deign to use flags consistent with the other group. It is a real disappointment and in my opinion holds U*ix back big time.
Yes, XML imposes overhead. But it also brings some real advantages. Look at the Apache configuration file, particularly 2.0.
I really really despise configuration files that are dependent on the number and type of whitespace in a line to determine how the data is parsed, particularly what syslog does.
If cut-n-paste (generally converting tabs to spaces, etc) breaks your configuration format, then your configuration format was broken the day it was designed.
I do not deploy Linux. Ever.
What nightmare? If your sys admins are worth their salaries, then you shouldn't be losing any sleep.
I think the article is referring to a heterogenous network with lots of history, where mediocre sys admins have come and gone and six different flavors of OS exist. This is not a problem with UNIX, it is a problem with your high staff turnover and patchwork network architecture!
Planned well and managed well, a UNIX network is very nice, and you don't need glitzy GUI tools to get you there.
Healthcare article at Kuro5hin
_What_ configuration nightmare?
There's a universal config tool for unix already.
It's called "vi", look into it.
There is always a simpler solution which is
incorrect. You make things as simple as possible, and no simpler.
Configuring unix and its millions of apps, or any other OS, is by its nature a pretty complex problem. There is simply no getting rid of most of this complexity. Deal with it and quit being a crybaby.
Besides, I'm an old dog and am very suspicions of new tricks. I'm still not used to xnetd config files vs. the old inetd config file.
What tends to heppen when somebody redesigns config files to make it easier to slap some crappy ill-conceived gui config tool interface on top of it is typically good for one class of users, but bad for another. Scalability tends to go out the window. All your scripts for managing 1000 servers quit working, but configuring 1 workstation can be done by an idiot with a mouse. (soln.: hire 1000 idiots.) Flexibility goes out the window. The author of the config tool didn't anticipate your gonzo setup. Gui tools and such are best when they are _optional_ and the old ways still work as they always did, and when the tool is smart enough not to freak out if somebody hand edits one of "its" files.
(He trolls, anonymously without actually reading the article
Cisco's configuration metaphor is the best thing out there, so far. It is possible to read one textfile and realize exactly what the router or switch is going to do! Also, this file makes it simple to replace failed hardware by loading the same file into alternate equipment.
:-)
.....
.......
All that is required is an interpreter that runs at boot-time or upon request, and syncs the real config files with the script. Just a small matter of programming.
A sample config file:
version 0.1
!
hostname ns
!
authentication local
authentication username root password 5
!
ip name-server 127.0.0.1
ip default-gateway 10.1.1.1
ip domain-name testnet.local
!
interface eth0
ip address 10.1.1.25 255.255.255.0
duplex full
speed 100
!
service dns
zone master testnet.local
start-of-authority ns.testbox.local
...
one, two, one two like a duck
There are are certain advantages to the current general way Unix software configuration files are handled. I'd hate to see these advantages lost in the name of making things 'easier' or 'more centralized'. Some of these advantages include:
Some of these strengths are also weaknesses- for example, having each programmer write his own configuration parser leads to many disparate security flaws as each author makes their own unique mistakes.
I've rescued a number of systems from otherwise-fatal low-level configuration errors by manuaully correcting the configration, either by mounting the drive on another system, or simply hex-editing the raw partition to replace the first character of the offending line with a '#'. I'd hate to lose this last-ditch rescue option.
I do not deploy Linux. Ever.
If it was cool enough for Apple, then maybe the rest of the world with see just how cool the world of the the Nix's is. UNIX/Linux is more than a Kernel, it is a reflection of all of you who have contributed. That is what makes the Nix's so fucking cool. Apple knew that.
For once Apple found someone cooler than itself and wanted to be part of it.
photosMy Photostream
Configuration information should be stored in a directory database such as LDAP. This will allow us to produce easy to use tools as well as permit central management of 1000's of boxes.
.conf file. The Windows registry on the other hand,is limited to a hand full of data types (String, Multi-String, DWORD, and binary stream).
Some people out there will jump to conculsion this would be like the windows registry. Wrong! LDAP is extensible, the Windows registry is not. With an extensible scheme its possible to mirror the exact type of parameters in a
If Linux is to grow into the corporate world it is going to need Directory Services. No If's, But's about it. If you have never used Directory Services, don't even try to bother to respond to this message, you don't have the first clue. I am tired of hearing stupid rebuttles from so called guru unix admin who think they know all, and see all NIS is a pathetic/earliet attempt a DS.
Just my € 2 cents worth...
Getting sendmail to route mail is the tricky part. Getting it to rout mail is absolutely cake. :-)
I have my own very ideas :) I believe that XML is good but very verbose; anyhow, the array of parsers and stuff would make working with it really simple... So it's a naught point that XML config files are hard to edit if an XML-editor becomes as standard as vi.
A good idea I saw on ATG-Dynamo (who uses both XML configs and plain text), is the idea of configurable config-layers, that is, that it checks in order different places for config (kinda like looking first in /etc then in ~/.foo, etc.), letting you choose which 'directories' are read *and* having plenty of flexibility to combine the different files (i.e., concatenate, replace, ...).
The only thing I can think of that is missing in that for a general config system would be the addition of 'final' configuration, i.e: when an attribute is finalized, no later layer of configuration can change it.
There was an intersting thread on the openbsd tech list about this issue.s d- tech/200111/msg00263.html
http://www.sigmasoft.com/~openbsd/archive/openb
What's advanced to one is trivial to another.
Many people here complain that unix is elitist, but at least it doesn't make assumptions about your level of expertise. There are many situations where a beginner needs to configure something that happens to be under 'advanced'. It's very discouraging to give the idea that you must be 1337 to use those options. Also it's impossible to split people simply into beginners and experts because an expert in one field is a beginner in another.
I guess it goes naturally in the whole of OSS and unix philosophy. If you need to fix something, there are guides to there even if the path proves difficult. In Windows things are decided for you, and if something is decided 'difficult' the system reminds you that it takes some black magic and you probably shouldn't do it.
So, whatever the silver bullet to config is, let there be an option to hack the files with emacs. Because computing is not black magic which should be hidden behind candy houses.
Escher was the first MC and Giger invented the HR department.
- Certain configuration file-formats we're kinda 'stuck' with. For these files, we just have to write the plug-in which can read, write, and parse them. We don't have to re-write the application to comply with The New Way. The app doesn't need to change, or even be aware of the configuration library.
- A configuration utility written to use the library would be able to configure all applications which have the appropriate plug-in installed. So if someone writes a nice pretty GUI X-based app, it can configure everything. If someone writes a curses-based text menu app, it can configure everything. A web-based configuration app could also configure everything. Some config-apps could be oriented for gurus, and some could be designed for newbies.
- Eventually, applications themselves could use the library to read in their own preferences. Bonus - it's a little easier to write applications now.
All that being said, I foresee some 'gotchas' -remember win 95 ...wait for it....
sysedit --- its not one big config file but it makes it all available without digging too much
any text editor....
Whaaaa, Stop your whinning and fix it.
Since when was OS X based on NetBSD? It's based on FreeBSD. I know that NetBSD can run on table lamps, but that doesn't automatically mean it's the OS used on the new iMac.
This is just like the dark days of the windows registry.
/etc/hosts entry using the NetInfo system is one example of what I mean.
Obscure syntax and things buried levels deep.
It takes 14 steps to add an
Wax on, wax off baby!
This is a non-trivial problem, and one I have some experience of (failing to deal) with.
My program is called "createusers". I wrote it because I wanted to make the following for 100s of new users in one go: user login, Apache home page, Samba account, PostgreSQL database, and MySQL database. I also did my best to make it extensible.
You can find my program here:
http://freshmeat.net/projects/createusers/
and here:
http://www.lfsp.org/
The fundamental problem I faced when writing createusers is there is no standard programmatically-accessible way of:
1) finding out what can be configured in each application
2) applying and undoing the changes.
Furthermore, I would like to make createusers programmatically-accessible. Unfortunately at present I cannot, because there is no standard way for me to let other programs know what facilities my program has, and no standard way for me to make them easily turn-off-and-on-able by other programs.
I received some add-on contributions to my program from other people. I noticed that their programs said "Have you enabled X in createusers.conf?", "Have you enabled Y in createusers.conf?", etc.
If I had standards-based turn-on-and-off-ability for my program, then my contributors' programs would have been able to do it for themselves. They would be able to easily check what things my program is set up to do; AND they would be equally able to change it.
This is a problem for people Much Smarter Than Me. If it is solved, then I promise to put the necessary bits in to my program so its setup can be easily, securely queried and changed by other programs.
Amen, XML is a solution but not necessarily one that is the best. Example... I had enough trouble with EJB's as it was going, I didn't need XML config files required for each server vendor to add to the headache.
You hit it dead on there. while you or I have no problem popping in and futzing with the configs by hand or killing processes, those pesky coworkers tend to be completely ignorant of such things.
nothing sells a free UN*X system to your management like this:
you: "we'd need to stretch our WinNT admins further and have them understand how this app works on this system; additionally we'll need 500 more server licenses for NT."
boss: "but that would cost more!"
you: "well, we do have this test environment set up, but it's running under FreeBSD (insert your OS of choice here)."
boss: "But isn't that hard to understand? what if you get hit by a bus?"
you: "well, before you say that, check out this nifty web interface to controlling the system. very nice and straightforward. very easy to use. the NT admins are ALREADY USING IT for other systems, too."
boss: "wow, that's pretty slick. and this is free?"
you: "yes, it's free, and we are ALREADY USING IT in the environment with no problems whatsoever. it also allows for authorized admins to remotely control the systems for 24/7 coverage! and what's more, FreeBSD (insert your OS here) is free, and we have to spend money only on server hardware."
boss: "well, looks like that's the best solution then. write up a proposal and go for it."
not that it always works like that, but sometimes it does, and that's a beautiful thing. plus, scripting your own needed code and adding it on as a webmin module is pretty easy, and can handle most anything you might need to do by hand, or via a script you're running from an ssh term. why bother? just *click*.
EOM
GCC is probably a good example - it compiles to metacode, then to actual machine code.
This "two-step" operation is what we should use - with that ANY config file could be used!
So you start with the original text-based config files, and thru a translation layer is converted into a format that this "Configurationator" can handle. Options are picked, and once done, it's uncompiled and saved in the original source format.
It wouldn't be terribly hard to create a metaformat that would allow for this - it would in essence be a modified regex definition!
-Ben
I have no problem with your religion until you decide it's reason to deprive others of the truth.
I have to say that the proposal discussed on freshmeat is far from acceptable by todays standards. There is nothing new in the approach and it will fail where so many other similar attempts have.
Instead, have a look at Reiser's future vision of a filing system http://www.reiserfs.org/whitepaper.html and imagine what a good set of filters could do.
For example, let a configuration file be stored in the filing system namespace in an appropriate tagged format. Now, whenever an application requests the file through a certain set of keys, the filter could dynamically format it, in say XML. But a normal user reading the file would probably prefer a text layout which could also be provided by a filter.
I think it's time to move on. We've been stomping on the same ground for far too long and it's not going anywhere. Reiser is definitly delivering some future directions.
The BIG problem with Linux/UNIX config programs is that they aren't stateless. Programs that try to keep their own versions of all the config files (ahem... linuxconf) get all freaked out if you go in and change a file by hand the manly way (with vi, not emacs). Webmin (I think) does not try to do this, so it appears to work better. If someone were to write a NON-STATE-KEEPING tool then it has a much better chance of working nicely.
-- I am. Therefore, I think!
What's a "code fag"?
dinner: it's what's for beer
Apple didn't use NetBSD, they use FreeBSD!
Common sense is not so common.
Thank you. You may now resume your pro-XML discussions.
wasn't it dennis ritchie who said:
"UNIX is simple. It just takes a genious to realize its simplicity."
UNIX, as it is, was meant for people who know what they're doing. bringing it to the masses is a task that wasn't meant to be done, although linux took a good shot at it by making a UNIX that's free for millions of other brainiacs.
OSX also took a good shot at it, and it's worked out famously well.
what makes them work so well?
they have a TARGET AUDIENCE, and a CONSOLIDATED EFFORT TO BRING THEM WHAT THEY WANT.
linux, UNIX, OSX, FreeBSD work they way they were designed, and applications et al already run on them. they don't NEED to be standardized further - they just need applications to keep sustaining the target audience. and in that effect, they're all winners.
i'm amazed that i survived - an airbag saved my life.
We should use actual Python code as the configuration file format. It's callable directly from C, and by extension, all other languages. It's nice and clean. It supports heirarchial inclusion of other configuration files. It has easily readable comments. In short, it's the perfect configuration file specification language.
This is aproximately 95% personal peev so it may suffer from -1 offtopic, but it's my 0.02$. Also understand that my knowledge of the X11R6 standard, and how Xfree86 functions at a low level, is quite limited.
I'd really like to see some sort of integration between Gnome/KDE user control interfaces (gnomecc, etc) and XFree86. Something that would let you configure the X server in place, without restarting your session. One of the things that's always bugged me when trying to get coworkers to checkout linux as a possible desktop is the fact that they have to configure their desktop separately from configuring the X server. Coming from the windows side, most people find it annoying to have to configure the display resolution/color depth separately from other properties of the desktop.
This would improve ease of configuration, and bring [insert free os here] closer to being a desktop os.
Now, I realize that this might be impossible to implement without breaking several other things, but I just wanted to throw the possibility out there.
For me one of the strongest points of unix is it's ease of configuration. Configs reside in almost one place, /etc, but still they don't make binary mess like windos registry. all configs are just text, written in some language, that is perfect for it's application.
If anyone thinks about writing dns zones in xml -- oh, please, stfu.
And... i type faster then move&click mouse and even faster than jumping through curses app with cursor keys.
Problems with configuration? What kind of a fucking Troll are you? READ THE FUCKING MANUAL!!!
Yes, and the discussion went to the next step and started talking about possible APIs. The parsing of XML (DOM and SAX -- DOM for in-memory data structure and SAX for streaming access) are well understood and, most important, already done with innumerable tools already written.
Wrong! Wrong! Wrong! You haven't read the spec and are obviously making assumptions based on what you've heard from others who haven't read the spec either. XML Schema allows not only the specification of integer, string, float, date, etc. values, but integer subsets (greater than and less than) and string patterns (through regular expressions). And RELAX-NG can use XML Schema's datatype support as well.
Do you have something that does validate IP addresses for example or were you just complaining about how one thing doesn't (even though it does) without showing anything that will solve the problem. If you say regular expressions, I must remind you that XML Schema supports regex matching of attributes and element data.
Could you please enumerate these non-compliance issues? An encoding issue? Bugs in DOM or SAX support? What? I wonder about the vitrol of your argument without any specifics. Especially since I been using both parser that you mention (and a few others) without any noticeable issues associated with the standard. Any problem were usual to do with parser extensions to the standard which are fairly simple to avoid.
You're right! That is a big issue. Unfortunately for your argument, it is not an issue with the leading parsers that you mentioned yourself: Xerces and MSXML. The default parser for Java (Crimson through JAXP), the default parser for Windows (MSXML), the default parser for Perl (XML::Parser I think...haven't used it yet) to name a few ALL handle entities. This is like saying that there are many web servers out there that don't support CGIs with the obvious intent of dissuading use of web servers.
I agree, but you're missing an important aspect here. INI files are usually one and at most two levels deep. They do not handle hierchical structures well at all! Let's look at a snippet from a default Apache configuration file.
What do we see? Hmmm... Because the key/value pair format doesn't allow hierarchy, they fell back to something that looks a bit...er...XML-like. And it isn't key=value, it's key[whitespace]value. Yet another issue: one file has the equal sign and others don't. I thought we were aiming for consistency? And what if the parameter is a message and that message has a newline character? A '\' at the end of each line? A '\n' where appropriate? These are problems that XML has solved.
And let's not forget Unicode support. We English speakers may have a hard-on for English, but can't you imagine a case where a program intended for a non-English speaking audience would want -- if not the names of the parameters themselves -- parameter values in alternate character sets than ISO-8859-1 (Latin1)? And before you rebut with UTF-8, do you want to write the UTF-8 translator? What about the other codesets? Are you strictly limiting to UTF-8? This is another area of XML parser that keep it simpler for the programmer. Transcoding is done for you and is most likely better implemented and supported than what you or I would come up with.
And when you have multiple "Files" definitions? Well, multiple blocks right? The "Order," "Deny," and "Satisfy" parameters are associated with the "Files" definition, yes? So why aren't you associating a group of "Files" definitions together? Because that would require further hierarchy? Would you end up with something like this?
Set up a relatively complex configuration where you have virtual hosts and those virtual hosts have behavior different from the default. What's that? You include them in tags by host? Tags that look somewhat like XML anyway you say? Imagine that!
And what about the comments? For some formats, the comment is the ';' character. For others it is the '#'. And none of which I am aware differentiate between implementation comments and actual directive comments. For example. the comment above describes the configuration directive so that any configuration editor could conceivably read in that info and display as help to the user (assuming that all comments were kept correctly before the directive and not after or on the same line). But what if you wanted to make comments about your specific installation. You are making comments so that others in your working group can see why you made certain changes to the config file, right? So how are they differentiated from the primary directive comments. This is the type of problem that XML namespaces are intended to solve -- a way of giving demarcation points to distinct pieces of (sometimes) unrelated data or simply the clean combination of multiple schemas so that your schema definition doe not bloat to immeasurable levels and different schemas can easily share with one another.
Something keeping back Linux/BSD/UNIX is the stubborn, 1337 coders who spent all day figuring out a config file that some joker on the net thought would be a keen config format but forgot to comment it. Let's face it, Apache is not the norm. Config parsers are a known problem with known solutions. Writing a config file parser is not the primary focus for most programmers out there. The config file is a necessary evil to them. Let's make it easier and just say, here's your DOM interface. It's well documented, works well for the limited dataset with which you a working (config files are usually less than 50K), will handle any configuration organizational type you want (hierarchical, flat, etc.) and will save you the time of writing a parser yourself.
Have a nice day.
- I don't need to go outside, my CRT tan'll do me just fine.
Instead of trying to make every unix program conform to some "ideal" configuration method like XML, I think that we should work with the current standard idiom (plain-text config files) with a unified interface. If we examine the config files we will see many regular types of configuration parameters (setting values, turning features on and off, composing lists, etc) that can be generically addressed through a GUI. We would simply need to write the formatting/parsing scripts to read and write the data from and to the configuration file(s). Let's not be clueless about being able to change many established program's configuration methods used on Unix programs now. IMHO, an acceptable solution would need to be (1) backward compatible, (2) portable, (3) accepting of new configurations, and (4) have easily editable I/O scripts. Just my 2c.
Backward compatibility hurts - it's a kind of getting just half of the work done.
:-)
This is off-topic, but funny how much effort did companies like Microsoft and Intel spend on backward compatibility just to find out that they make much more $$$ from backward incompatibility.
just my zero albani
As one previously stated Linux seems to have apps strewn all over the disk without specific rhyme or reason. If you need to find something on a windows system it's in program files, that simple. Linux should have one /etc/ /sbin /usr/sbin directory for applications and go with it. ie: /usr/src/bind /usr/src/apache /usr/src/galeon etc. and the config files should be placed in /etc/conf/named.cong or a directory off of /etc/conf such as /etc/config/srvr/samba.conf and so on and so fourth. And from there is't really just an issue of properly commenting the config file, the conf files do not even have to be to the same format. find one place to place them and call it progress.
But if the Linux community even't can't agree on common interoperability for business apps (like OLE) between two major desktops, a thing which is important to push linux on the desktop, nor any commong config file format (xml, unix config way, sendmail, etc...), how can they agree on a common config scheme?
The Caldera Open Administration System has many of the same goals, but it seems moribund these days. It was quite impressive: being able to configure a multitude of configuration files using a consistent user interface, whether text or graphically based. The "master" configuration file is always the original application's. It's too bad it didn't get more widely adopted. Ideally, each *nix application would ship with a COAS (or similar standardized) format metaconfiguration file that describes its native file format and would allow a high level configuration application to work. That would enable flashy, integrated *nix configuration like the other guys.
webmin is worse for your host's security than leaving unpatched, unupdated copies of sendmail, bind, and all the rpc services active. seriously, this is only a good program if your aim is to get r00ted.
Ximian Setup Tools has a beautiful Perl backend that spits out XML and that you can send XML into to make changes.... very nice.
-ryan
then why does every single 3rd party developer use the registry?
No-one's pointing a gun to their head.
They use it because its the best solution available (in windows)
Not to mention that both regedit and reg will allow you to turn the registry into a flat file and vice-versa.
Performance overhead for XML to great? The parameter parsing code gets run once, at startup, on a short file. Not withstanding the numerous XML parsing libraries out there, any programmer worth his salt ought to be able to write a quick and dirty XML parser with low overhead.
XML also give the advantage of being able to document the settings in a systematic manner that can be applied across a variety of config files. Your system doesn't seem to offer that. At least with s around, you have some inkling of the purpose of a given piece of data. I think such a product is a must, if ever *nix is going to make a strong play at being a viable desktop alternative.
Better yet, XML can easily be parsed into dialogs... it would be very nice to have a third party tool that could configure options for a variety of software packages in a easily understandable GUI design.
Finally, XML is an existing and widely accepted standard which is familiar to many users across diciplines. Those can be hard to come by. Might as well build on its strengths rather than try to invent a new standard fresh out of the blue.
-Bobby
SpyDock: Scientific Python in a Docker container
Please check this out.
It's the esmith configuration schema.
They have already solved this problem in a neat way.
War is necrophilia.
The X resource database is a great configuration database - it is perfect for user preferences - and you could even use the same file format for non-graphical programs, too.
.INI files...).
Irritatingly, both KDE and GNOME ignore the XRDB and go off and implement their own half-assed systems (in KDE's case, reminiscent of Win3.1
Motif, Tk and Xaw applications all honour XRDB configuration -which is great!
Want all applications to use a font?
*font: Arial
Want a certain application to use a font?
*Xterm*font: Courier
Want a certain button in a certain application to use a particular background colour (n.b. this is an immaginary one)
*moogybrowza*toolbar*backbutton*bgcolor: cyan
Fire up editres and play with Netscape 4 some time...
- yes, that's right, Xaw and Motif applications are dynamically "themeable", at run-time, have been for years! Qt and Gtk suck on this front compared to widget sets that use the XRDB.
It's a true database, not just a single-tree structure like xml, so it's pretty damn powerful - and is STILL human-editable text, yet
can easily be wrapped in a GUI.
It's a bit like the Windows Registry, but DONE RIGHT...
We will now hear from all the people who insist that "they have to do wierd thing X because it's (traditional) (k00l) (needed to support their 386 machine)". They're wrong. Someone needs to be a hardass and fix this thing.
it just isn't as nice as MacOS! here's my solution bag XWindows put in the MacOS UI... Customers = Happy..
Don't Try to Outweird me, I get stranger things than you with my breakfast cereal every morning
.I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .ha
My question is (reposted in the main thread for more exposure):
T RIVIAL FILES" ?
Why are all the SUPER important files in etc? I mean, take off the Unix cap and think about this for a second... does it make any sense for the most important configuration files to be stored in a directory that is Latin for "and the rest"? Shouldn't it be "System" or "Important Stuff" or "DONT_DELETE_UNDER_ANY_CIRCUMSTANCES_THESE_ARENT_
Normally I can let the "Linux/Unix" equivalencies go past without commenting. However in this case, the very discussion is about something that differs substantially between Linux and Unix. How???
1) DOCUMENTATION!!! All Unix implementations (Solaris, HPUX, AIX, etc. etc.) come with complete, comprehensive, current documentation. Linux documentation is unfortunately still a bad joke. This makes for enormous problems when configuring the system.
2) Built-in tools. Admitedly most of the Unix vendors can control their hardware which makes configuring it much easier, but consider Solaris/X86 (RIP) vs. the ugly mess of trying to get RedHat 7.x up and running. Actually, there are only a few things in RH that are particularly bad, such as XFree86. Of course, that's Someone Else's Program, so they're more or less stuck with how it works (badly!).
3) Consistency/standards. Unix works in a fairly consistent way. Applications don't always follow the same way. Example: How many applications that require a daemon started at boottime put a script directly into rc2.d instead of init.d? Or just start the daemon, ignoring start/stop flags? TOO many, that's for sure!
I could keep going, but this is already dangerously close to a 'what's wrong with Linux' rant, and I don't want to get into that just now. It's good, but it's not there yet and IT'S NOT UNIX!
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
This is an example of confusing style with substance, as well as losing the plot.
There is clearly a demand for a mega-fantastic configuration tool that works like "Swat" but hacks all the STANDARD config files in a Unix environment.
This does not mean we need to replace the standard formats with new NON-STANDARD standards.
We've upped our standards, so UP YOURS
Please, that's the bigest lie in all of this. The idea that what you are doing in Unix is "hard." It's not. Once you learn the config files, getting things set up takes just a few seconds. I can ad a new domain to my DNS server in just a minute or two (just copy a file and modify as needed). I can set up a new share in Samba's web-based config quickly and secure it via IP range or windows username (I would assume it would take just a copy/paste/modify in the config files as well).
I didn't have much trouble handling the apache config either for adding Tomcat on windows or scoop on linux either. (in the case of scoop, all I had to do was copy a pre-genererated text file into my apache conf file).
It's not hard, it just takes time to learn all these damn config formats.
A standard system for editing would go a long way to making things easier. People could spend time learning about how things really work rather then how lazy the author of the software was in writing their config parsers.
XML+some schemas for common things would really help. In the case of Scoop I mentioned, I wouldn't have even had to do the useless and idiotic step of copying data one from one file to another manualy... it could be done by Make via a standard XML parsing API, or perhaps a standard config library.
autopr0n is like, down and stuff.
I wanted to use Linux as a server, as it seemed to be the 'thing to do', as well as the fact that run all that cool server code that was only available for Linux, as well as get experience running a Linux box.
:P) scoop site.
:P), but it's just a lot less of a hassle to set those things up on windows.
Having a Linux box has allowed me to have a mail/DNS server with a very high uptime, as well as a (non-porn
I'm not saying it wasn't fun, but it's not something I want to go through all the time... that's why autopr0n.com uses tomcat on windows with an M$ access file rather then on Linux with Postgresql or MySQL or something. That would probably be a better solution (and eventually I'll migrate, or at least move up to a pirated copy of SQLServer
autopr0n is like, down and stuff.
If you go to sendmail.com you'll see they sell a 'pro' version with a nice GUI. I'm pretty sure they keep the text config complex for a reason :P
autopr0n is like, down and stuff.
http://www.yelm.freeserve.co.uk/libcfg/
XML is not the solution to the problem, XML is just a file format, many different file parsers would still be required for XML just as there are for other file formats.
No what's required is a simple to use *API* which performs the configuration management for you. Whether the configuration information is then stored in a colon separated file, XML file, DB database, SQL database or LDAP server is irrelevant, it can still be read, modified, saved by the application.
LibCFG uses flat text files by default but that's only because nobody's written LDAP, SQL, DBM sections for it.
Note, the license for the library is important. For a library like this to become useful, *everything* has to be able to use it, the most expensive commercial software must be able to include and use the code as well as GNU GPL based software.
Government of the people, by corporate executives, for corporate profits.
Actually, you wouldn't need two separate XML files. XML already has the capacity to 'describe' itself via DTDs, as well as XML schemas.
/> to <inetd:setport port="80" service="apache"> people could edit it in either form and have the changes roll back between the two. That way you could have a GUI for apache and inetd and make changes in either and automatically have it propagate all over the system, check for conflicts, etc.
Basically they let you write a description of what your XML document contains (indeed, you need those if you want to have a "valid" XML doc). A standard XML Schema could be developed for "Linux Config", and developers could derive from that any special config options they would need.
You could also use XLST to convert from "app space" where all the tags are descriptive to the domain of the problem (<TCPport port="80"
autopr0n is like, down and stuff.
type this at your command line for me real quick:
/etc/sendmail.cf | more
cat
You call that human readable? Hah!
Anyway, humans can read anything a computer can, with practice, including binary. It's just a question of how long it takes them to learn. XML does not take that much time.
autopr0n is like, down and stuff.
The GNOME project has one implemented already: it's called Gconf. It is like the windows registry in practice, but the configuration files are human-readable (XML). It's pluggable, it has a global config database, and a user-only database. It is easy to use and program for. It also has the ability to use any kind of database you want - while no changes to the application are needed. :)
The only problem most people see with it right now is the current default database that is being used - it's ugly. But there is another one in the works and (I think) will be the default database in GNOME 2.0. There's even one that uses mysql!
Really, what's the problem with using gconf globally? Imagine how easy it would be to configure things - it would be so much easier to write graphical frontends for these applications. LinuxConf would be rather simple to write and maintain! The advantages are innumerable!
People worry about a corrupted database, but each allplication is in it's own file, so if something happens, then it's for that ONE application. I've been using GConf for some time and I've never had a problem with it.
Go ahead and read about it on GNOME's webpage (www.gnome.org).
-Brandon
>Sure, installing software is easy. Unpack and compile. We are talking about configuring software
Well, duh, how about configuring software during compile/install? It seems to me that recompiling with changed parameters is one very common way of configuring software using Linux. And how fucking user friendly is that?
part of it is machine readablity. You can parse the second a lot easier if you already have an XML parser. That lets you do things like let installs of software modify the config of other things to include them (this would be great with Apache). As well as GUI things. How would a gui know to associate that comment with that option.
/> tags, thats' just bad/lazy XML. Probably more like this
Also, you probably wouldn't just use <option
<logon>
&<!- this options specifies a script to run for every user -->
<scriptForAllUsers file="U.bat">
</logon>
Then in your DTD or Shema you would define what it does. programicaly, so that the comment would show up in a GUI as well.
autopr0n is like, down and stuff.
Sure, you can use XML for config files.
/login
/# (indicates end of multiline comment)
/deeper_nest
/nest_me
But, you sort of lose the ability to edit them by hand. How about a nice format that is *simple* for the simple stuff, yet also scales up in complexity like XML? One that looks very close to traditional Unix config file formats, and is easy to parse using traditional Unix tools?
I suggest a format that declares attribute/value pairs like this:
maxusers = 5
prompt = "Enter password\n"
To make them part of a section (block), you could use this syntax:
login:
maxusers = 5
prompt = "Enter password\n"
You could use a # char for comments. You could have lists like this:
permissions = user, group, other
You could have lists within lists by using parentheses:
matrix = (4,6,7),
(3,2,1),
(4,2,1)
Although I anticipate that you wouldn't use this much. For comment blocks you could use:
#: (indicates start of multiline comment)
For strings with escaped chars (like \n), you'd surround the string with double quotes ("), for literal chars with no escaped chars, you'd use single quotes. For certain strings with no "weird" chars (esp. no spaces), you could omit the quote marks.
The beauty is that, if no nesting (sections) are used, the format is just like a traditional, highly readable Unix config file.
If you're forced to go XML because of your job, OK, but for the rest, I think this proposal has something going for it. I've got more details if someone asks.
--Mr. Ashley Jacobs
# Here it starts...
title = "Example"
nest_me:
someval = 9.67
deeper_nest:
greeting = "Try it!"
Those of you who are saying that FreeBSD runs only on the Intel platform, you are totally ignorant, and you should proceed to shut your mouth at this point. FreeBSD runs on Alpha, and has either single user or multi-user boots on Sparc, PPC, IA-64, etc.
The number of machine dependant lines in the 4.4BSD kernel is 39,634 out of 202,251 or about 19.5%. Once the hardware specific areas of a platform are abstracted, the rest of the system (for the most part) works properly. (*Broad generalization*)
As for the subject at hand, Darwin IS based on the Mach microkernel, with FreeBSD subsystems and libraries, and NetBSD userland. However, for those of you ignorant of the Mach microkernel, the short story is, it was partially based on 4.2BSD. So as much as ignorant Linux zealots want to try to make some kind of meaningless point that "Darwin is based on Mach not BSD.", from the perspective of the informed, that's the stupidest statement you could possibly make. No matter how you want to look at it, Darwin IS BSD. As several Apple representitives said at this year's BSDCon, there are currently FAR more deployed BSD boxes than Linux boxes. As for the FreeBSD vs NetBSD argument, you have to decide for yourself whether "based on" means "subsystems and libraries", or "userland utilities".
From apple.com:
"FreeBSD is one of the ongoing BSD development efforts and is our primary reference platform for current BSD kernel development."
"we try to keep Darwin as compatible as possible with FreeBSD (our BSD reference platform)"
"We already synchronize our code periodically with NetBSD for most of our user commands, and we will soon be doing the same with FreeBSD for our libraries."
Having used Windows/AIX/DigitalUnix/Linux I have a few opinions:
:-).
/var? Executables in /etc? Configs set up as scripts with commands in that get arguments twiddled by config tools?
Binary saved configs or databases or anything not as flat ascii files is Not An Option.
When they work they are wonderful. When you get a problem, you are FUBAR.
If you can't fix it with $EDITOR you are emptying a double-barreled at your feet.
SMIT is wonderful. Everyone should have access to a good management tool if they prefer to use that.
However, such a tool is just covering all the dirty innards with a pretty face. It shouldn't be _hard_ to do things by hand. Well, at least it should be logical
Configuration is a mess in Unix, and Linux even more so.
One thing is being able to fiddle with stuff yourself, an entirely different one is finding where the stuff is.
crontab in
-NorthWay
You ask if I want usage of Linux to expand beyond the minority of people who think knowing their way around their system is cool. My answer is, no. To help you understand why, let me introduce myself. My name is Mike, and I am a geek.
You say you have a life, and intend to keep it that way. I too have a life, and I choose to spend some of my free time tinkering with and occasionally contributing to open-source, free software projects. You are not required to respect or admire this lifestyle choice, any more than I am required to respect or admire yours.
But when you ask why free software is not made more user-friendly, try to consider my position. As a volunteer programmer and tester, I am going to work only on projects that appeal to me. As many have observed, writing GUI configuration tools and other such fluff is not appealing. It is tedious, repetetive, unrewarding work. I have very little to learn from implementing yet more button-and-checkbox slop; I have done quite enough of that in my everyday paying jobs.
If I am representative, geeks and consumers have very different needs, wants, goals, attitudes, and expectations. Therefore, if you want a geek to address the needs of consumers, you must give him or her some sort of external motivation.
I submit that for many open source programmers, there is no such motivation. In fact, the opposite is the case: I don't really want to encourage consumer-grade users to adopt my software. There is a communal reason for this, and a selfish one:
No doubt somebody will point out that the majority of open source development is done by paid professionals, not hobbyist geeks. In that case, the above arguments are even more relevant. A commercial developer working on Apache might be interested in improving performance, adding features, or removing bugs. A company relying on Apache is no doubt quite comfortable with the way it is configured. So again, writing a spiffy GUI configuration tool would only make it easier for less sophisticated competitors to retire their Xitami/Windows NT web server and adopt the more robust Apache. Would you spend your money doing this, or something that actually benefits your company--something like improving performance, adding features, or removing bugs?
I disagree. No two programs have the same set of configuration needs. Two web servers can have very different configuration options depending upon their focus. While I agree that DTDs are a pain in the ass (DTD entities == XML preprocessor == pain), using something like XML Schema or RELAX-NG would give all the necessary metadata a configuration manager would need. Far more so than some one size fits all or (only slightly better) five sizes fit all.
If the UI can see that you need parameters A, B, and C, there is sufficient description data for the parameter (relatively simple with judicious use of XML namespaces), and can tell that A is supposed to be an integer from 0-100, B is supposed to me a valid email address, and C is an enumerated list of possible values (all possible with existing XML technology -- no need to reinvent the wheel), you will have your UI while allowing a sufficient amount of individualism by the programmer.
And you don't need pre-defined schemas to make object mappings. There is previous work in this area already for the generation of object definitions from XML metadata. Of course this is of most use to the actual programs. The config manager needs to process the metadata in addition to the instance document (the config file).
Come to think of it, a schema document describing UI manager "hints" might not be such a bad idea. It wouldn't tell it what each config entails, but could provide info on how that is to be presented. Nice idea!
Re: LDAP. LDAP is an interface, nothing more. The LDAP spec says nothing about how the datastore should be implemented. In short, you could have your config data in any form you wanted and, as long as it was consistent and documented, publish the information through an LDAP-compliant gateway process.
** mouth waters at the possibilities **
- I don't need to go outside, my CRT tan'll do me just fine.
The core of our disagreement is that I would very much like to have an alternative to Microsoft OS'es wheras Mike couldn't care less (I suspect he doesn't use any MS products unless he has to :-).
With a BSEE and 20+ years professional programming experience I may not be a Joe AOL. But when it comes to Linux, I frequently find myself asking WITFM (Where Is The F**etc.. Manual). I have tried several times but have always ended up with a Linux PC that I can't use it for very much because I cannot get it configured.
I don't have the patience (or enough spare time) to get to the point where I can get a Linux PC to do what I want the way I can with a Windows PC. And although I do love tinkering with computers and programming, it is unfortunately not a pastime that is compatible with a family life. (insert "why_are_you_always_playing_with_that_computer.wav ")
My opinion? See above.
Advocates of auto-detection instead of manual configuration I'll deal with right now: Applications in certain problem domains require explicit human-supplied configuration data. This is unavoidable in any application that has to implement some choice of policy, especially security policy. There are some things you can't ever autodetect, so if you can't configure the application, then you need many different applications, each hard-wired for one possible desirable configuration. Certainly a lot of things that should be auto-detected are not, but auto-detection will not eliminate the configuration problem.
Windows and Mac are platforms controlled by a single vendor. That vendor has a _lot_ of influence over how applications are designed for that platform. When the vendor designs and implements the platform, the vendor will (intentionally or otherwise) reward applications with an architecture consistent with the vendor's design, and penalize those that don't. Applications tend to comply with the vendor architecture because the cost of non-compliance is greater than the cost of compliance.
Unix is not a platform controlled by a single vendor. Heck, it's not even a platform; it's a bunch of little standards that were chosen arbitrarily and stitched together. Linux, FreeBSD, SysV, BSD, Solaris, QNX, HP/UX, etc. are not Unix platforms--they are platforms compatible with Unix, implementing parts of the SUS, ANSI, and POSIX standards, with varying degrees of completeness and success. As such, there is no reward for making an application's architecture consistent with the OS vendor's design; contrariwise, there is a compelling reward for an OS vendor to make an OS architecture consistent with a desirable class of application.
The difference is critical for understanding the configuration file nightmares of both kinds of platform. Windows has a really awful configuration mechanism that nobody would ever use if they weren't compelled to; however, certain parts of Windows are only conveniently accessible via this configuration file format, easy (if not reliable) methods to access the format are provided to all developers and available on all end-user machines, and the configuration schema does not define a lot of policy to get in the way of extensions (need new schema? Add a new DLL!). The Mac has a different architecture and mechanism with the same consequences.
On the other hand, applications that run on Unix are, in whole or in part, designed for "other" systems. Applications that were designed and written exclusively on Unix-like platform X eventually get ported to some other Unix-like platform Y--those that don't tend to be eventually replaced by similar applications that do. When this happens, the resulting application is an alien on both platforms. The application must find everything it needs on each target platform, or it must bring with it those things that are missing from some target platforms. This means that the application will have translation or interpretation layers (all C apps have at least one translation layer in the C compiler) and replacements for missing functionality in the target platform.
Now for the delusions. New code written in a language with link-level compatibility with a free, small, fast, easy to use in code, portable, robust configuration mechanism library will have no problems. Note that the status quo is already as free, small, fast, easy to use in code, portable, and robust as it needs to be for applications that already use it, so alternatives which are not all of these do not merit discussion.
However, there are constraints imposed on this hypothetical library by legacy code:
- It would have to be already installed or available on all Unix-like systems with bindings to all Unix-like languages,
which rules out nearly everything invented after 1978. Otherwise, every application (and language!) must bring either a copy
of the library or their own code. Strangely enough, "open file," "read text line," and "lexically analyze this string" primitives
are implemented in nearly all Unix-like languages, and interactive text file editors are shipped on nearly all Unix-like systems...
- It would have to be as small and fast as fgets+scanf, or a lex+yacc parser, otherwise it will hurt performance or have
a large footprint, and people who care about performance or size won't use it. XML can't do this unless you drop the i18n and
character entity and encoding support--at which point it's not really XML any more.
- It will have to use small ASCII text files for persistent storage, otherwise you have to implement and force everyone
to use either your own editing mechanism (aka "a control panel DLL"), or you implement and force everyone
to use replacements for Unix filesystem-crawling tools which allow you to selectively access the data (aka "the registry and
regedit", or "replacements for cvs, vi, find and grep")--both of which violate the "once and only once" rule since these
facilities exist already in Unix and they are used for this purpose.
- It will have to be used directly by the actual applications--otherwise you violate the "once and only once" rule
by having either two configuration files and two applications (the real application, and a configuration application), or two
configuration file handling mechanisms in one application (for old-style and new-style config files).
It might be possible, given overwhelming demand, to convince maintainers of significant mature legacy code to adopt the new configuration mechanism, if the XML-based mechanism is more widely ported and better debugged than their own configuration-management code. Good luck, and be prepared to do the work yourself many, many times over until you either change their minds, or they leave the project and you're stuck maintaining the code by default.Note that other standardization initiatives, like FHS or the LSB, involve relatively superficial changes which application maintainers were probably willing to make anyway. The FHS and LSB ask application maintainers to change the parameters to a few system calls without affecting the architecture of any part of the application or the semantics of its operation. For example, the application may open()s a file, but after the FHS is implemented that file has a different name. Both names are constant strings, the file is still opened for reading, and it still has the same contents with the same syntax and semantics. A one-line change and a recompile brings the application into compliance, and in an emergency, a symlink will make the application work.
Other initiatives, such as DNS and PAM, are usually facilities that are not intrinsic to applications. Host name resolution or user access verification involve resources shared by many applications, and there is a real technical penalty for non-compliance.
Changing the way applications handle configuration is a large architectural change--you're asking people to replace open(), read(), close(), and some code which is intrinsic to the application with new functions that have different semantics, and may even have to be called at different times. Expect resistance.
The only hope of this ever happening in real life is for a Linux distributor to decide to implement it, and contribute the work to achieve it. Said vendor will have to hack and slash their way through hundreds if not thousands of packages to bring them into compliance. Once all of that is done, all the upstream package maintainers will have to integrate the changes--or all the other Linux vendors will have to repeat the hack-and-slash job.
-- I avoid spam by accepting only OpenPGP encrypted or signed email at this address. Clear-signed, RFC2015, heck, even
NeXTSTEP (NeXT Mach OS 1.x-3.x) was a proprietary, BSD 4.3-based unix running on top of a monolithic implementation of the Mach microkernel. OPENSTEP (NeXT Mach OS 4.x) was an API and a set of libraries conforming to that API, and an implementation of NeXTSTEP incorporating said API and librarie, as MaxVlast so eloquently stated. (Footnote: OPENSTEP also existed as a development environment for NT, and as a gui running on top of Solaris, which, alas, only ran on Sparc.)
Rhapsody (Apple Mach OS 5.x) was essentially OPENSTEP 4.2 with the platinum gui thrown on top of it. Same for Mac OS Server 1.x.
Mac OS X (Darwin 5.x) is where things change. Gone is DPS in favor of Quartz, which is roughly but not quite accurately DPDF. Gone is the platinum gui in favor of Aqua. A newer implementation of mach is used, although I believe they still use it as a monolithic kernel. The aging BSD subsystem has been replaced with a BSD4.4-based system that is primarily made up of FreeBSD and NetBSD bits.
So OS X is the spiritual descendant of the NeXT Mach OS. The BSD system it uses has been updated, and it has a new windowing system and gui. OS X is not OPENSTEP and it isn't FreeBSD, two of the misconceptions that I see someone posting on usenet or slashdot forums. It is GREAT however, and you should check it out if you haven't yet. The user experience crushes anything else available at this time.
This is where XML Namespaces comes in handy. For example, "someone" can create a namespace that contains the ipaddress schema definition, which can then be used in your app's XML configuration file:
<myapp>
<server>
<net:ipaddress>
<net:protocol>tcp</net:protocol>
<net:host>127.0.0.1</net:host>
<net:port>8877</net:port>
</net:ipaddress>
</server>
</myapp>