The X.org foundation has released the 2nd release candidate of X11R6.9/X11R7; X11R6.9-RC2 is built in the traditional Monolithic style, where as X11R7 is based on the new Modular system. Testing is going to commence on both Monolithic and Modular source trees, here you can see what needs to be tested in this release.
Hi,
I hope that there are some new drivers for my ATI RadeOn 9100 onBoard card. Currently xinerama isn’t working with both the open source and the original ATI drivers. But maybe it is working with the new Xorg.
Greetings
Mike
Hint: xinerama isn’t support by ATI at all. They have there own basturd child that they try and use. The ATI drivers have never supported xinerama as far as I can remeber (Don’t quote me on that one, but I can’t ever remeber that kind of support)
This has nothing to do with X
Besides becoming modularised (which should payoff in subsequent releases), are there any noteworthy changes? After all, if there weren’t, why bother releasing a 6.9?
One thing I don’t understand is why there isn’t (last time I checked) an option of having an XML config file. I know there is a general back-lash against XML but it would be nice to be able to validate my config file (against a XSD or a DTD) and getting an indicator of what the problem is. This also applies to fstab, but I find the X.org files lend themselves even more so to XML since they are nested hiearchies. It’d make learning there syntax a lot easier and extracting information from them alot easier because you could extract it with XQueries.
If they changed options or deprecated old ones or even changed the syntax you could easily test which version it was written for by having several versions of XSDs/DTDs and then run the config file against them. X.org ina compatibilty mode. You could also auto-update the files with an XSLT (just cache the result and you won’t have it slowing subsequent starts).
XML processing doesn’t need to be heavy if you use SAX which I’m pretty sure would be good enough for the job at hand.
I know X.org is probably also used embedded… but for regular desktop use I think XML would solve more headaches than it would cause, if you keep the original config-parser in the tree as option (IFDEFs around each I’d guess) I don’t see why it should be included.
English is my native language but I’m tired and for some reason this post reads like shit… feel free to mock and point out conceptual and grammatical errors.
Edited 2005-11-12 19:05
Why XML? What’s the advantage over plain text? I can read and edit plain text without the use of tools other than a simple editor. And since any editing is usually done because something’s wrong and X won’t start, this seems more important to me.
Well, XML is plain text too. Sure, editing it by hand may be more cumbersome, but it’s not difficult and it’s certainly possible with any text editor.
The original poster did state some reasons why the use of XML might be useful, I suggest you read his post again
Edited 2005-11-12 19:31
I did read it, and it was all mumbo-jumbo to me. 😛
It’s no so much the editing, but so far any XML file I’ve seen doesn’t really lend itself for browsing quickly in a 24×80 character console.
htmltidy might be able to rectify that, i think.
As to the “mumbo jumbo”, if you managed to eff up a setting, the text version only says “no screens present” or something eloquent like that.
With an XML one, you can at least check it against the specification for the file type to see if it’s a syntax problem, or an actual misconfiguration issue. More often than not, it’s a syntax issue, at least in my experience.
I can read and edit plain text without the use of tools other than a simple editor.
It’s been a while since I’ve used emacs but I believe it will auto-indent your xml for you. Frankly I find it really difficult to make unreadable XML. Unless you choose bad names for the tags or don’t indent it seems pretty clear cut to me (or at least no worse than the plain-test file would be). And if your editor supports simple pretty-printing (16 colours will do) then it’s real easy to move around. I think even vim supports colours, doesn’t it?
The biggest benefit is that you know the rules of XML and then can edit confidently. For example I know tab is special in Makefiles and to a somewhat lesser degree in Python (you can use n-spaces instead)… but in fstab… I don’t know. The samples always put them in so I do too… but will it break without them? I don’t know. With XML that kind of guesswork is gone. So I guess you can say XML is more readable than plain-text since you know what is meaningful.
The most resistance will be from people who have already memorised the current layout and are comfortable with it.
PS- The only tool I usually use for XML is jEdit with the XML indent plug-in. If I’m developing a new XSLT I’ll use Altova XMLSpy Home (beer free) since it has an XSLT button saving me a trip to command-line.
And that’s exactly one of the reasons why I prefer plain over XML, no need for anything other than a very simple text editor.
And that’s exactly one of the reasons why I prefer plain over XML, no need for anything other than a very simple text editor.
And vim and emacs aren’t plain simple editors? Vi is part of POSIX IIRC, and Vim is almost always put in it’s place on any Linux distro. Nano will do in a fix, but you might have to ident by hand (though the sample would probably come nicely indented anyway so yours would probably be indented to start with).
It’s no so much the editing, but so far any XML file I’ve seen doesn’t really lend itself for browsing quickly in a 24×80 character console.
If your tab is set to anything less 8 then I doubt that something as simple as an X.Org conf file (I mean it doesn’t have an infinite amount of endlessly nested content unlike, say, an MathML file could) would ever wrap. Even if you ahve your tab set to 8 then even with 5 levels of nesting (I don’t really see going deeper than that) that means and indent of 32 characters… leaving 48 characters wide for your settings.
Well, call me n00b, but I don’t see wy XML would make it easier to create an editor for the x.org config as it is already divided with section headers.
That is the point… with XML you don’t need to create a new editor because there are already editors that do XML out there. If you convert some other config file (lets say /etc/sudoers ) to XML you know have now one editor(or only one editor plug-in) instead of two, only one config file validator instead of 2 (each one will still needs it’s own DTD/XSD obviously), only one syntax to learn. As you keep converting _suitable_ config files the benefits mount.
I did read it, and it was all mumbo-jumbo to me.
I suggest you head to http://www.w3schools.com/ and learn about XSLT and XSD (it’s under “Learn Schemas”). I can’t think of anyone in a computer related field that would not benefit from at least learning about XML and it’s related technologies.
Now, I’ve never gone about actually _doing_ something about this but since there seems to be _some_ sense of agreement here I might consider talking to the X.org ppl and if there is any support there taking it on as a summer project. Now if only there was an OSS XSD validator that’d help things immense since things @ XMLSoft.org seem to have stalled http://xmlsoft.org/news.html . (On second reading I’m not sure if the “not” is distributed to the “and worked on”).
Edited 2005-11-12 21:30
At first, I was quite sceptical with the usefulness of XML configuration files, but I must admit that you did a very good job in enlighting me…
XML parsing might not be that stressful on embedded systems. There is at least one *NIX system that uses XML for configuration (http://www.m0n0.ch/wall/). That said, I don’t know if it uses it even for fstab…
Are you kidding? Because right now it is virtually impossible to make a decent configuration tool that can robustly and confidently edit any and all xorg.conf files. Changing this to a mature and well supported information storage format like xml would change all this instantly. Very nice editors would start appearing immediately that could even setup my damn dual head nvidia stuff. Drivers could have associated schemas that would make this a dream.
You may like editing by hand and reading poorly formatted and incomplete documentation on how to manage your video card but this is a major pain in the ass for most people and is one of many niggling issues that still make linux difficult for the mainstream to swallow.
Well, call me n00b, but I don’t see wy XML would make it easier to create an editor for the x.org config as it is already divided with section headers.
I agree. XMLizing xorg.conf would add a needless layer of complexity for the vast majority of users. For most users it should be set-and-forget, and the most frequent issue users have is being unable to start X. I think editing a plain-text file in a console is less intimidating.
From a power-tweaker point-of-view I can see the utility of using an XML-based tool, but then power-tweakers are comfortable with text files anyways and xorg.conf settings generally aren’t changed on a frequent basis. I don’t see how standardizing on an XML format deals with the incongruities of how different proprietary drivers set their (sometimes undocumented) config options. That to me is the core problem.
Just my 2c, mind you.
Set and forget? Your logic has a loop in it. How should someone who is not a “power-tweaker” ever “set and forget” to begin with? What if I upgrade my video card? What if I want to use the nvidia driver instead of the OSS nv driver? What if I buy another or different monitor?
Yes xml’izing the config file would make editing by hand harder in some ways. However, it would make up for that 10 times over when 10 or 20 very nice config file editors sprang up in the first month after the config file was changed. Anyway, it is not that much harder to read than a normal file and certainly doesn’t introduce any more layers than what existed before. Now there is an easy *option* to build and use an editor but you don’t have to. The number of layers is the same.
With the current config format, setting simple stuff in a minimal config is a pain in the ass if you don’t know what you are doing. And any driver specific options, dual head configs, etc, are way beyond the reach of any intermediate or beginner user and even as someone who is pretty comfortable on the command line, I don’t want to go through that if I don’t have to.
If I have a given card, all the options of that card should be easily accessible and clearly defined. There is a backend/frontend distinction here that I think people aren’t getting. Make the backend simple and easy to interact with and easy to discover what your options are and then bolt on whatever front ends you like. Think CUPS for video cards. You like cups right?
n00b.
Do you think Ajax, for example, leverages xml so heavily for no reason? XML is highly suitable for programmatic parsing and editing. It is a standard. Arbitrary config files with fields that vary in requirements for every driver preclude with almost 100% finality the possability of ever making a general editor of xorg config files. Even editing by hand is much harder because you don’t know what fields are available or legal and in what combinations. All of this could be captured in xml schemas so that both text editing and editing via a config program would be 100% easier and more robust.
Edited 2005-11-12 21:52
Whoops, replied to my own post.
Edited 2005-11-12 20:37
There is lots of improvements and changes in the changelog and also EXA acceleration for popular drivers. It’s much more stable with xcompmgr as well(transparency and shadows) and the Modular system helps alot for people like NVIDIA.
While I’m not a huge fan of XML for configuration files, I have often wondered why the many disparate open source projects continually decide to reinvent the wheel and define their own descriptive structural format for configuration files. This is a general problem that I believe standards could solve.
Perhaps having a format similar to Apache’s config file (as opposed to strict XML) would be helpful to everybody (although XML does allow for programmatic parsing of any arbitrary config file). The strengths afforded by having a standard config file format for most applications would make administration infinitely easier, as one could use a generic configuration editor to safely modify any application’s configuration without the fear of a poor parse or a meaningless value. Xorg would, of course, benefit immensely from this, as would *nix usability.
On topic, I’m very excited to see what improvements lie in wait as Xorg’s modular system gains momentum. Hopefully this will lead to faster growth and more stability.
> Perhaps having a format similar to Apache’s config file (as opposed to strict XML) would be helpful to everybody
Funny that, read the ‘why I hate the Apache webserver’ presentation which has been made by one Apache top contributors, to summarize: Apache’s configuration suck.
Granted this is more about the way Apache use their configuration files than the configuration file syntax in itself (well it does say that it lacks if..else).
XML is even worse..
I’m wondering if some kind of Lisp-like variation wouldn’t make an acceptable configuration file?
S-expressions are much more readable than XML even though they have a similar ‘tree-like’ structure and are easy to parse too.
S-Expressions are NOT more readable, because it’s harder to pick out where things end, unless they’re properly formatted. Mind you, with auto-formatting this might be less of an issue, even so without bracket highlighting they’re less readable than matched tag pairs and in the end you’re adding a lot onto the editor just to get around this.
This is it?
No OpenGL back-end?
No beta composite/damage/etc?
No better building infrastructure? (though being dealt with in 7.0)
No better driver support?
This is it?
XML support?
This will help X.org compete with Vista and OSX?
From the 10,000 things that needs to be done in X.org (some/most are already being done), XML config files is number 9,999.
Oh… Use vim/gvim to edit your X.org file. It’ll validate them without having to use XML/DTD combo.
You are wrong. Sorry. Of course open GL, composite, damage, etc are important but making the damn system actually usable trumps those issues easily. Only driver support, which you mention, is as important in my opinion.
Anyone who has used linux and tried to change anything about their display setup has learned about xorg.conf the hard and painful way (and yes making changes is something that people do normally, every time they change their video card, monitor, mouse, etc).
Use vim? Are you f–king kidding? We’re not talking about how we can compete for the hearts of computer experts and enthusiasts. Linux has already won that battle for many. We are talkinga about, as you say, competing for the marketshare currently held by windows and mac. If you want these people, you cannot in the same post suggest that people edit using vim! Your post is f–king idiotic.
Edited 2005-11-13 02:41
Actually you’re dead wrong.
In an idea world, people will never be required to edit their xorg.conf, they’ll have tools to do it for them.
Ever looked at how Windows stores their desktop configuration in the registry? No, right? Because the right-click – properties does everything you need for you.
(Just for the record, NT stores its configuration in a large array of registry keys that make Xorg.conf look like a kid’s play…)
In short? Want to make X more accessible? Create a better auto-detection and configuration tools (Though all the existing tools are slowly getting there. *) Once you have such a utility, how Xorg stores its information is irrelevant to 99.9999997% of all users.
Gilboa
* At least on my last FC4 install, the Anaconda auto-detection did all the job; I never bothered to edit the Xorg.conf myself.
* At least on my last FC4 install, the Anaconda auto-detection did all the job; I never bothered to edit the Xorg.conf myself.
I can’t speak for them all, but this is the eventual goal in Ubuntu. A developer recently said on the forum that they would not support a GUI Xorg.conf tool because they would rather make it so that the Xserver is configured correctly on the first install.
The eventual goal is to make everything plug and play. You plug in a monitor or TV? Its detected and added automatically in a cloned setting. You get a new monitor? It is detected for the new resolution and driver. You get a new video card? The config script re-runs and sets up the card for you.
Of course, that setup kinda sucks for the middle of the road Windows Power User that wants her desktop to span across two monitors or wants to tweak the graphics for a few extra frames per second. But honestly it seems that the Linux Desktop would be foolish to aim for the Windows Power User seeing as how their demands are high but their tolerance for dealing with problems is low. “But Windows can do (insert non trivial task that requires drivers Linux doesn’t have here) and Windows can do (insert task that is illegal for any free OS to do in most countries like play Windows media files), so why can’t Linux?”
Basically on the desktop Linux has two viable targets. The super nerd that loves computers and wants many features and is willing to hack to get them, and the clueless user that thinks computers are magic and therefore is amazed if one can check his email and allow him to edit a few documents without “viruses” (because to a normal user thats the name for malware/spyware/etc.- look at the AOL commercials and how they fixate on the word virus). Of course the second user cannot set up the Linux box for themselves- but they can’t set up a Windows PC. Dell does that for them, just like a super nerd (or a Dell) should set up their Linux PC for them. Then its that nerd’s job to get Xorg working. Low end users do not buy video cards, they do not have two monitors. At most they want their video out on their laptop to clone when plugged in to give presentations. Their needs will be met before the needs of the Windows Power Users…..thats life in Linuxland.
That said the current system does suck. As a super nerd I hate the fact that my Xorg.conf is a treasured file because it took me SOOO long to get my xserver to do all the nerdy things I want (dual screen with desktop spanning and composite enabled so I can run xcompmgr). But I know part of that is because half of those cool things are done using commands specific to the Nvidia drivers. So its kinda Nvidia’s fault. Not to say that I dislike them for it (only with Nvidia can I get accerated xcompmgr on two screen), but only to point out the problems any GUI tool -even with a new sort of config files- would have.
“No OpenGL back-end?”
Some of the Open source drivers have EXA acceleration, believe me it’s MUCH better than current.
“No beta composite/damage/etc?”
Yes it has much better composite support and more stable.
“No better building infrastructure? (though being dealt with in 7.0)”
How hard is “make World” “make install”?
“No better driver support?”
See my first answer.
“No better building infrastructure? (though being dealt with in 7.0)”
How hard is “make World” “make install”?
You are kidding right?
Trying to configure the old X.org/XF86 build process was a nightmare.
Let alone the fact that you have to build 300,000 useless files, just because it was never modularized. (Or having to rebuild X from scratch just to enable DRI)
Gilboa
I agree with you point on XML. My take………
I think xml for config files is a good thing.
There is a program called BOINC. It runs seti@home and other mass computing projects. They use XML format for the config files and stats.
Now many websites and tools can download stats and monitor progress of the projects. Information can even be viewed on mobile phones.
The above is great but what has this got to do with X.org and *nix ?
Well if X uses XML and it works out OK. Then other apps and tool may follow. In time it could be one point that make *nix distro compatible with out restricting them.
There has been other intresting ideas that packege managers should use XML so they can talk to one another with Schemes and DTD is other stuff that I dont fully understand.
The best thing we can do is send reports back to the projects, make wish lists, code, test or support the projects in some way.
Edited 2005-11-13 00:01
NOOOOOOOOOOOOOOOOOOOO!!!
XML is good for some complex data structures, but X config files do not fit into that category.
XML is overated and overused. Seriously people, just stop and think before you create an XML document; especially for config files.
NOOOOOOOOOOOOOOOOOOOO!!!
XML is good for some complex data structures, but X config files do not fit into that category.
XML is overated and overused. Seriously people, just stop and think before you create an XML document; especially for config files.
I think the standard like XML and a schema is cool for X.org and *nix as a whole. Yast or even Firefox (If you want to run it is root) could change settings using a form. Than other stuff like Gnome and KDE alread use XML to some extent.
We can only hope for XR7.1 with XML in <-;
Anyone know of any Linux distros that let you try out the new X11 R7 ? The only one I know so far is Belenix, a solaris based distro which uses X11 R6.9
We shipped Mandriva 2006 with a pre-RC1 CVS snapshot of X 6.9 (in order to support recent Intel graphics chipsets). We’ll issue an update to 6.9 final when that comes out (next month is the schedule).
Gentoo has both X11 R7 and X11 R6.9 in the main portage tree.
Gentoo has 7.0 but not 6.9 and it wont be added.
You are indeed right about 6.9, I was getting it confused with 6.8.99.
Gentoo
You can test it with gentoo by unmasking the ebuilds for xorg-x11. The ebuilds are already included with portage as well as ebuilds for the seperate modules (these need to be unmasked too). Gentoo FTW!
For Fedora users and new testers as well, modular Xorg is available on CVS and will come on rawhide this week.
http://fedoraproject.org/wiki/Xorg/Modularization
Edited 2005-11-13 02:15
debia unstable + experimental
Nobody cares what the config file is written in. This is a technical detail that should be invisible to the average Linux user/installer.
What Linux needs is an excellent hardware detection system and a Utillity that will read your video hardware and automatically write a configuration file that works without any input from the user.
I personally don’t care if this file is plain text, xml or binary or assembly language. Let it just work.
A messy config file is still a mess even if the user doesn’t ever see it. Let’s tidy it up!
This is ridiculous, yes people do care, because people have to edit it, let’s live in the real world, rather than in one where everything just works, because that’s highly unlikely to happen, besides, detection doesn’t mean drivers or appropriate configuration.
This is what XML buys you.
-Easier editing, there is no ambiguity in what you’re changing. Each level and element you change is explicity identified. Yes there MIGHT be a bit more typing, boo hoo, a few more characters for clarity is worth it.
-Correctness, XML can be validated. Basically it allows you to test to see if the contains valid data. Imagine if you loaded up a driver for an nvidia 6800 video card. The XML file could be immediately update with fields relevant to the video card and any changes you make could be programatically validated — no more spelling mistakes and you could catch various conflicts or lack of information. All of a sudden the program can help debug your entries.
-Bloat reduction, rather than having to code this for every stupid tom dick and harry’s plain text format these things can be done in a generic way, imagine if every program on your system used XML for configuration, this means every program would lose all the bloat of their various configuration systems and we’d have just a few libraries instead.
-Administration would be dramatically easier. Programs such as YaST which have to parse and understand configuration files could handle user editing or YaST editing. Each configuration file, fstab, xorg.conf, apache, … the list goes on forever wouldn’t require it’s own parsing rules, reducing bloat, once again AND at the same time providing better interfaces to configuration of these programs.
-Patching configuration files happens a fair bit. The problem is that once you’ve edited a configuration file the patch will undoubtedly screw you over. In many cases XML can help programatically apply the patch to the configuration file such that things don’t blow up as much.
I fully support XML as a data transport format and in some cases document formats. XML+URI+DTD really helps when you need extensibillity to a format used beyond your contorol or when you need to merge formats from diffrent sources. In short it’s great for networking applications such as the web and web services.
As a UNIX configuration format I don’t see how it can be that good though.
Compare:
Section “InputDevice”
Identifier “Generic Keyboard”
Driver “kbd”
Option “CoreKeyboard”
Option “XkbRules” “xorg”
Option “XkbModel” “pc104”
Option “XkbLayout” “us”
EndSection
with
<section type=”InputDevice”>
<identifier>Generic Keyboard</identifier>
<driver>kbd</driver>
<option name=”CoreKeyboad” value=”true”/>
<option name=”XkbRules” value=”xorg”/>
<option name=”XkbModel” value=”pc104″/>
<option name=”XkbLayout” value=”us”/>
</section>
to my eyes the first version is more readble (with the color coding vim provides the contrast is even grater).
Now your bullets:
Correctness
Vim allready does a good job att alerting me about errors. But implementing an external validator wouldn’t be that hard, it’s a pretty straight forward syntax.
Bloat reduction
I see your point, an I agree with you. I don’t think XML is the sollution though. Compare reStructuredText to HTML. I think the same problem and sollution applies in this case. We need a generic, parsable, validating, documented configuration format, that is readable and workable in a plain text editor.
So basing standard on what we have now wouldn’t be that bad.
F.ex. comments delimied by # and n is nicer to, say, grep than <!– –> and friends.
Just as #!/some/prog can be used to point to a validator that should conform to some standard so that other tools can work with it.
Administration
Again, a standard whith how to get documentation, options, and validation would be good. It doesn’t have to be XML though.
Patching
This is a valid concern. When I mention #!/some/validator above I didn’t realize that this could actually be the sollution to this problem too. Instead of forcing every sforware project on the planet to use XML so that administration can be easier (which won’t happen by the way) one could implement the patching thing in the utillity that is responsible for parsing and validating the config file…
Ok this needs more thinking, I’ll just go to bed now.
In essens this #!/some/validator would provide the services an editor would need. Just as you can connect a program to an editor with a debugger…
I had to revert the spacing( ), the code is supposed to be better aligned
Edited 2005-11-13 03:51
Perhaps I am used to markup languages, but the XML mockup is more obvious to me. It would be even better with proper indent (but I understand that there are some limitation with OSNews; a code tag could be useful).
On correctness: the average Joe don’t use vim. There are chances that he won’t even know how to quit it. Reminds me of the first time I used it… Didn’t knew how it worked so I switched to another console and killed the process!
On bloat reduction: I see your point, but program X doesn’t have the same needs as program Y. For instance, program X might need sections, sub-sections, sub-subsections… in its configuration file while program Y don’t. Some options might accept more than one argument per line. Other might support none. Some option A might need a suboption B, option C might need some special characters… So you would probably need validation templates for program X and Y. Sounds like XSD/DTD to me.
On patching: you said that we couldn’t force software projects to use XML. You’re right, but the same thing could be said for your option. And if you’re adding patching/editing to a program that is doing parsing and validation, you end up with something that is quite similar to an XML parser…
In the end, the generic parser isn’t going to be much smaller than a XML parser. Faster? Maybe, since it would be focused to a specific task. But we already have a standard that works: do we need another one?
Edited some wording and typos
Edited 2005-11-13 05:38
You are really not getting it. Of course the user should not care at all how the backend works. The problem with xorg.conf is that the backend configuration stuff is so completely broken that it is impossible for the distros/hardware detection programs/3rd party xorg configurators/etc to work so users are *forced* to do exactly what you are saying they shouldn’t have to do which is edit these files by hand!
If you actually want things to be as simple and robust as you say then you should definitely be in support of an xml configuration file.
Just wanted to put my 0.02 dollars (euros) regarding the XML + xorg config file discussion.
I agree with the benefits regarding XML and config files in general. Even having XML xorg config file does have its benefits like mentioned in some previous posts. You’ll still be able to edit them by hand in an editor, or xml editor, and there could be a much better config app(s) for it.
However I see one major problem with XML xorg config file, that I think someone mentioned although didn’t fully expand on it. That is editing it in a command line based text editor such as vi, when you can’t get into X. This can happen on occasion, and having the file in XML format would make this task much harder and significantly more error prone (which is a very dangerous thing). I do admit that this is probably a rare occasion, and also depends on the distro, system & OS config, and the user. I have never needed to do this. But I know people who mess around with their Linux/Unix and configs, and had to do this.
I am not really neither for nor against XML for xorg file. Just wanted to state a potentially important issue in the discussion.
But yea, in context of all things X related, I think the file format (or changing it) is not a great priority considering the other things in the works.
Edited 2005-11-13 02:53
Everything has a downside I suppose. However in this case your example anyway is a pretty small downside. Anyway, why is editing in a console with vim any harder than anywhere else? Why is that harder than editing the existing xorg.conf? They seem about the same to me. Vim, even on the command line is a damn nice editor and understands xml format.
Debian Experimental had a beta of 6.9 (or 7, I forget) last time I checked. I imagine they might upgrade to the RC sometime.
Anyway, XML is nice not only for the ease with which it can be parsed, but as has already been mentioned, for the possibility of checking its validity with an automated tool. Now, the only way you can test if your syntax is acceptable is to (re)start X and see if it starts. If it were XML, you could check it beforehand (before restarting X or whatever) with xmllint or some checker that is more familiar with the actual variables used.
The problem of implementing XML is not as easy as saying it. If you want userland programs to read and write XML then really they need a library to help. If you want the core utilities config files like fstab to be in XML then the core utils will need to access that XML library as well, and that can be a problem unless the library is very small (small enough to be statically compiled into the binaries of files like mount, because mount reads fstab). The other solution is that each of those core utilities implements XML on it’s own which is an ugly solution.
Then you get the problem of users editing XML files in the text console. Unless this functionality is added to each editor you are going to annoy a lot of people.
You will also have to add or change several of the shell utilities to work with XML files. Many people use these to work on their text based configuration files.
You are going to run into problems everywhere.
From the X.Org Modular Developer Guide [1] : “After checking out the modular tree, you will also need to check out a monolithic tree”. Why would you need to check out a monolitic tree to build X.Org from a modular tree ? This very strange.
[1] http://wiki.x.org/wiki/ModularDevelopersGuide
Is this possible yet?
I think Linux would really benefit by the use of XML config files. Sure it makes editing files a little harder by hand but not that much, and the benefits outweigh any reason not too. GUI tools and such would be so much more accurate and powerful.
While I really like Linux the stigma about XML is pretty deep rooted for a lot of people. Look at gconf. There was this uproar that gnome was getting a registery, people still curse gnome for gconf. The result, however is a very easy (unlike the registry) XML file structure that works very well for a desktop enviorment (and is very easy to edit).
As the Linux desktop matures I believe that it’s simply going to happen one way or the other.
Edited 2005-11-13 07:42
Ever since the introduction of XML, the number of problems with software has increased by one in a lot of people’s eyes: this software doesn’t use XML.
The lack of overly powerful and dynamic GUI configuration tools for X are not because the format used for defining the configuration file isn’t specified in XML.
Please feel free to use libxf86config to write the world’s greatest graphical configuration program. I expect it to appear no later than the next time I check the comments section of this forum, because the only thing between you and writing this program has clearly been correctly reading and writing the configuration file into programmatic datastructures.
XML was designed as an data-interchage format. So that for example databases can export and import a commonly agreed format. XML was not intended to be the fileformat.
But when will we see exa support for the radeon 9700 cards?
But when will we see exa support for the radeon 9700 cards?
Yes the new version will have support. Will it accerate EXA? No, only the ATI cards that are 9250’s or weaker can do that. Blame ATI for only releasing specs up to that point- the drivers for all newer ATI cards have to be reverse engineered and its hard to do that and get decent performance.
IMHO there are a lot of reasons why XML config files are better than non-markup text files.
Saying that XML is overrated and overused is silly, IMHO. It fastly becomes the least common denominator, a place previously held by non-markup textfiles.
Xml was not designed as a data interchange format only (there was EDI for that before), but to be easily understandable/editable for machines and humans as well.
Config files fall exactely in this category of use: both human and machine should be able to read/write them.
The reason why Xml can become a pain to edit, view, process, etc. on the command line is that the tools such as vi, grep, awk, <your favorite cli-tool here> where not created with Xml structures in mind but with line based records.
Having the same standard command-line tool support for Xml as for non-markup text, editing, viewing and processing Xml-files would become just like non-markup text files, however with the additional benefits of Xml.
Since Xml is here to stay, it would be better to have things like vi for Xml, grep for Xml instead of creating the next config format, the next config format validator, the next config format processing library, etc. ..
Edited 2005-11-13 14:36
Please stop, it is not about the damn config file anymore. Xorg should be able to reconfigure itself each time I plug-in a new monitor, mouse, keyboard etc. Did you ever wonder why you can’t change display bit depth without restarting X?. I’m excited about exa and the speed of X development, thing are changing.
I think the odds of Linux getting decent support for plug’n’play are pretty small… perhaps only for one distro. Companies don’t want to open-source their drivers and they don’t want to support another platform especially as fractured as Linux. I think you’ll always need to have a config tool around.
Aslo even with a graphical config tool XML is still a bonus since you can validate your config before replacing it thus your editor won’t silently corrupt your config.
I do think that the X.org conf is restructuable to something more XMLish than it is now so that it would look better than the example John Nilsson posted… for example look at Makefile and translating that directly to XML would seem pointless… yet look at the sucess that Ant has had.
As much as I destest Vi/Vim there is an entire site (which I only skimmed to be honest) [ http://www.pinkjuice.com/howto/vimxml/ ] on using Vim as an XML editor.
And as for readbity I don’t see how XML could be any worse than this line (though I’ll admit it may ad a bit of character clutter) in my own config
Screen 0 “Screen0” 0 0
In XML each value is in a tag or a property, either way it is described. If you can look at that and tell me what any of those values refer to w/o previously being familiar with the file. I’m guessing “Screen0” is some sort of name. Still <screen name=”Screen0″> is way more readable IMHO. What those zeroes represent is quite beyond me.
You guys are ridiculously off-topic.
What if there was a `Safe X’ mode using the VESA driver at a moderate resolution with its own set of configurations so that a user could type in something along the lines of startxconfig and enter the VESA X where they could configure their main XML xorg.conf with a graphical tool, eliminating hand editing the xorg.conf file. Perhaps a curses-based configuration utility could also be available to eliminate hand configuration.
We should also remember that while an automatic configuration during the booting of the system is useful for getting a basic working X, the user needs to be able to easily choose whether to eg use the nv or NVidia drivers, or to set their preferred resolution.
I do think that this is an issue and one of the few areas that Windows clearly beats the pants of the *NIX desktop.