Thanks goodness for XML. Nobody is going to make me bend fingers again, trying to come out of balanced parentheses! And if you didn't know, there are lots of XML applications where human coding is implied. XHTML, DocBook, to name just a few. The handiness of tweaking up some machine-generated document is not bad, too.
You can choose terser names for elements. Overall, if you're concerned with size of your XML data, you have lost. Compress it if you must, or don't use at all. But don't suggest removing restrictions that were put there to guard exactly against "great" ideas like yours.
I'm pretty sure that the 24-bit cards don't support alpha blending in hardware. This means XRENDER ops must be done in software, making the bitdepth issue irrelevant.
To everyone moderating the parent as Informative and Insightful: lay your crack aside.
Graphics and CORBA are independent parts of the GNOME platform, that aren't necessarily used together. That, and other claims in the parent comment, are just rehashed old trolls. Move on.
As another Russian, I have to object: we do commit war crimes in Chechnya. "Disappearances" and pillage on the military's behalf didn't cease to this day. And no, we don't know what are we doing there, trying to reestablish order with one hand and making new enemies each day with the other one. Full understanding of consequences is yet to come, and it will be bitter.
While condemning the unjustified war on Iraq, let's not pretend we're on a moral high ground here. It was the Russian incompetent policy that empowered militants in Chechnya. The second Chechen war was not unprovoked or unnecessary, but we are to take the blame as much as the rebels, and our atrocity toll continues to increase.
You can ask the French (our present "allies") what did they get out of their past wars in Algiers, complete with civilian abuse, racism and all that shit we see in Chechnya now. No one will tell you it was honorable.
Funny, but I do think that sendmail, was it designed in these days, might well end up with configs in XML. It's so sweet for describing rules and painlessly extending them.
I am simply pointing out with an example that parsing XML is O(n^3) while diff is O(n).
Xmldiff is a bad example for parsing.
Just because you can't come up with an O(n) parser doesn't mean it's impossible. Look at the expat sources at some time, and read up on stack automata.
To summarize, all you have to do to properly modify a value in all possible cases (remember, you need to track nested blocks, there can be ugly things in comments, and other unforseen stuff) is to build a custom parser, use it to navigate the internal structure of the document and spit modified data back. For every other format in/etc, rinse, repeat.
With an XML-based file of similar complexity, you write a 10-liner XSL stylesheet. The rest of the work is already done for you.
That is, parsing XML is more than 5000 times SLOWER than the line-by-line comparison. It is inappropriate for most purposes simply because the resources required to parse any decent-sized XML file are prohibitive.
Thank you for this deep conclusion. You have just compared a highly optimized utility written in C with a Python script of dubious maturity. These utilities are doing different things, by the way, so they are not interchangeable. You did not provide any consideration of algorithms and optimizations used by both. You then presented the results as an all-out defeat of XML as a format. For anyone who accepted your, erm, logic, I have a bridge to sell.
Whereas with XML, the memory used increases as long as the file size does.
You probably ought to say "might increase".
(There are tricks which can reduce the memory use, but they usually come down to making assumptions about the formatting of the file, which can lead to skipping over malformed XML chunks)
Trick #1: impose a (configurable) limit on element depth. XML documents with nesting deeper than, say, 2048, have no reason to exist anyway, even if well-formed. Problem solved.
Generic XML parsers are memory intensive and can't be as fast as regular expressions. That's just computer science. Deal with it.
Memory use of an event-based XML parser is proportional to maximum depth of elements. While elements your documents don't nest to insane levels, you're on good terms with memory.
Next, maybe I'm ignorant CS-wise, but nobody has yet explained to me the benefits of using regular expressions on nested structures and not screwing up with the said nesting.
You're right, but the problem is that "deal with it" may equate to "don't use XML" in a lot of cases
What's the alternative? To roll your own half-assed format/parser, facing just the same problems or worse?
Add to that unified means for processing all those files. When I need to examine or modify my XML files programmatically, I often go no further than XSLT and off-the-shelf command line tools. Stylesheets taking 6-10 lines of actual code (neatly aligned and delineated at that) can deliver you from tedious and error-prone hack jobs using regular expressions and what have you. XSL transformations can be used for quick reporting, format upgrades, and even generation of XSL stylesheets themselves.
Now, try to whip up in 15 minutes a Perl script that modifies your favorite non-XML non-plain format (changing forwarders in the options section of named.conf is a good example that came to my mind recently) and see if you didn't screw up somewhere (remember, there can be nested blocks, comments, quoted strings resembling actual syntax and other joyful stuff). Simple? I hope you know your Perl well, my friends.
Tom's Hardware may have their own opinion, but I happened to read about Audigy vs. "something else", with actual measurements and all. Audigy scored kind of pale. However, if you're into sound mainly for games, it's insignificant, because Audigy is pretty good after all.
I mean ALSA is absurd: every time you upgrade your kernel, you recompile. [...] Get stuff working for average users, Linux audio devs.
Average users do apt-get upgrade kernel or something to that effect, at which point ALSA is upgraded automatically. That is, if their distribution is worth its storage space.
The initial bits of configuration are tougher, but the ALSA website provides sample configurations for all supported cards.
If this is the same MozillaQuest as once was on http://www.mozillaquest.com, it was originally run by a troll who thrived on badly written articles misinterpreting statistics from bugzilla.mozilla.org and submitting links to NewsForge, Slashdot and elsewhere. It's nice if they have grown since then.
Here the author makes the point that Gnome has never lived up to the promise of CORBA.
They never meant to. The goal was to come up with some way to call objects beyond process and, theoretically, machine boundaries. Their choice of the existing, efficient protocol that is IIOP shows them as reasonable and forward-thinking architects (notably, the KDE developers chosen the other, "better" way). But they never meant to implement the full CORBA spec, at times even choosing to develop their own, more lightweight and limited APIs than what the spec suggests.
Has anything ever lived up to that promise?
You probably need to look at some commercial ORB implementations.
XML is not, as you say yourself, an alternative to LISP, but XML with appropriate coherent extensions could well be.
I think there is no reason for such things. Even XSLT, the most "programmatic" XML spec I know, doesn't bind itself to a particular programming paradigm, it just describes what is to be done. This, actually, can be considered a strength. And, i guess, no living soul would want to program in XML.
XML is not a programming language - it was never intended to be computationally complete
Now repeat after me: XML is basically just a syntax. It was never intended to be computationally complete in the same way as marking up things with balanced parentheses is not computationally complete. Yet you can map your favorite programming language into an XML representation, and vice versa.
Anyone who studied LISP, or some other language capable of representing the popular data and programming paradigms (logic, procedural, declarative...) will be aware that common ways of representing such semantics have been known for decades. The fact that the practice of XML continues to ignore such basic prior art is an extraordinary indictment of the state of our industry today.
The fact that someone tries to come up with a standard that would be widely accepted shows our industry as a maturing one. Sorry, but Lisp doesn't cut it for the IT masses in general. It missed its chance back then. It's a generic language, with strong background in programming, and it doesn't have such an emphasis on validation of semantically-loaded subsets as XML applications had from the very beginning.
...would change size to adapt to the palm of the bearer..., erm, the user. The keys would be blank except when subjected to heat, then the glowing signs (Mordoric runes) would appear.
for some reason they decided to drop the XML format from the PIM
If this is really so, this means they lost me as a prospective customer. I don't want a Linux PDA to play the same old games with proprietary formats. At least, until SyncML synchronization is unavailable for C700, there is little reason for me to prefer it over Pocket PC. Heck, there are SyncML add-ons for Pocket PC already.
Slashdot Mirror
SWT is going to move forward too, don't you think?
Thanks goodness for XML. Nobody is going to make me bend fingers again, trying to come out of balanced parentheses! And if you didn't know, there are lots of XML applications where human coding is implied. XHTML, DocBook, to name just a few. The handiness of tweaking up some machine-generated document is not bad, too.
You can choose terser names for elements.
Overall, if you're concerned with size of your XML data, you have lost. Compress it if you must, or don't use at all. But don't suggest removing restrictions that were put there to guard exactly against "great" ideas like yours.
I'm pretty sure that the 24-bit cards don't support alpha blending in hardware. This means XRENDER ops must be done in software, making the bitdepth issue irrelevant.
To everyone moderating the parent as Informative and Insightful: lay your crack aside.
Graphics and CORBA are independent parts of the GNOME platform, that aren't necessarily used together.
That, and other claims in the parent comment, are just rehashed old trolls. Move on.
Don't you know already who will be the winners in this war? Certainly not the "freed" Iraqis. It's Haliburton, Qualcomm, and other US corporations.
As another Russian, I have to object: we do commit war crimes in Chechnya. "Disappearances" and pillage on the military's behalf didn't cease to this day. And no, we don't know what are we doing there, trying to reestablish order with one hand and making new enemies each day with the other one. Full understanding of consequences is yet to come, and it will be bitter.
While condemning the unjustified war on Iraq, let's not pretend we're on a moral high ground here. It was the Russian incompetent policy that empowered militants in Chechnya. The second Chechen war was not unprovoked or unnecessary, but we are to take the blame as much as the rebels, and our atrocity toll continues to increase.
You can ask the French (our present "allies") what did they get out of their past wars in Algiers, complete with civilian abuse, racism and all that shit we see in Chechnya now. No one will tell you it was honorable.
sendmail.mc isn't the line noise you think it is.
Funny, but I do think that sendmail, was it designed in these days, might well end up with configs in XML. It's so sweet for describing rules and painlessly extending them.
To summarize, all you have to do to properly modify a value in all possible cases (remember, you need to track nested blocks, there can be ugly things in comments, and other unforseen stuff) is to build a custom parser, use it to navigate the internal structure of the document and spit modified data back. For every other format in /etc, rinse, repeat.
With an XML-based file of similar complexity, you write a 10-liner XSL stylesheet. The rest of the work is already done for you.
But it would be nice to have an alternative syntax that describes what you are ACTUALLY looking for when you are parsing a document.
Ever read about XMLPull?
Cheers.
That is, parsing XML is more than 5000 times SLOWER than the line-by-line comparison. It is inappropriate for most purposes simply because the resources required to parse any decent-sized XML file are prohibitive.
Thank you for this deep conclusion. You have just compared a highly optimized utility written in C with a Python script of dubious maturity. These utilities are doing different things, by the way, so they are not interchangeable. You did not provide any consideration of algorithms and optimizations used by both. You then presented the results as an all-out defeat of XML as a format. For anyone who accepted your, erm, logic, I have a bridge to sell.
Whereas with XML, the memory used increases as long as the file size does.
You probably ought to say "might increase".
(There are tricks which can reduce the memory use, but they usually come down to making assumptions about the formatting of the file, which can lead to skipping over malformed XML chunks)
Trick #1: impose a (configurable) limit on element depth. XML documents with nesting deeper than, say, 2048, have no reason to exist anyway, even if well-formed. Problem solved.
Memory use of an event-based XML parser is proportional to maximum depth of elements. While elements your documents don't nest to insane levels, you're on good terms with memory.
Next, maybe I'm ignorant CS-wise, but nobody has yet explained to me the benefits of using regular expressions on nested structures and not screwing up with the said nesting.
What's the alternative? To roll your own half-assed format/parser, facing just the same problems or worse?
Add to that unified means for processing all those files. When I need to examine or modify my XML files programmatically, I often go no further than XSLT and off-the-shelf command line tools. Stylesheets taking 6-10 lines of actual code (neatly aligned and delineated at that) can deliver you from tedious and error-prone hack jobs using regular expressions and what have you. XSL transformations can be used for quick reporting, format upgrades, and even generation of XSL stylesheets themselves.
Now, try to whip up in 15 minutes a Perl script that modifies your favorite non-XML non-plain format (changing forwarders in the options section of named.conf is a good example that came to my mind recently) and see if you didn't screw up somewhere (remember, there can be nested blocks, comments, quoted strings resembling actual syntax and other joyful stuff). Simple? I hope you know your Perl well, my friends.
Tom's Hardware may have their own opinion, but I
happened to read about Audigy vs. "something else", with actual measurements and all.
Audigy scored kind of pale. However, if you're into sound mainly for games, it's insignificant, because Audigy is pretty good after all.
Average users do apt-get upgrade kernel or something to that effect, at which point ALSA is upgraded automatically. That is, if their distribution is worth its storage space.
The initial bits of configuration are tougher, but the ALSA website provides sample configurations for all supported cards.
If this is the same MozillaQuest as once was on http://www.mozillaquest.com, it was originally run by a troll who thrived on badly written articles misinterpreting statistics from bugzilla.mozilla.org and submitting links to NewsForge, Slashdot and elsewhere.
It's nice if they have grown since then.
Here the author makes the point that Gnome has never lived up to the promise of CORBA.
They never meant to. The goal was to come up with some way to call objects beyond process and, theoretically, machine boundaries. Their choice of the existing, efficient protocol that is IIOP shows them as reasonable and forward-thinking architects (notably, the KDE developers chosen the other, "better" way).
But they never meant to implement the full CORBA spec, at times even choosing to develop their own, more lightweight and limited APIs than what the spec suggests.
Has anything ever lived up to that promise?
You probably need to look at some commercial ORB implementations.
XML is not, as you say yourself, an alternative to LISP, but XML with appropriate coherent extensions could well be.
I think there is no reason for such things. Even XSLT, the most "programmatic" XML spec I know, doesn't bind itself to a particular programming paradigm, it just describes what is to be done. This, actually, can be considered a strength.
And, i guess, no living soul would want to program in XML.
But it's not a huge mental leap to go from "background color" to "no background color", especially under pressure from advertisers
It IS a huge mental leap to start deliberately confusing your users and eventually losing them. And when that happens, the advertisers leave you too.
XML is not a programming language - it was never intended to be computationally complete
Now repeat after me: XML is basically just a syntax. It was never intended to be computationally complete in the same way as marking up things with balanced parentheses is not computationally complete. Yet you can map your favorite programming language into an XML representation, and vice versa.
Anyone who studied LISP, or some other language capable of representing the popular data and programming paradigms (logic, procedural, declarative...) will be aware that common ways of representing such semantics have been known for decades. The fact that the practice of XML continues to ignore such basic prior art is an extraordinary indictment of the state of our industry today.
The fact that someone tries to come up with a standard that would be widely accepted shows our industry as a maturing one. Sorry, but Lisp doesn't cut it for the IT masses in general. It missed its chance back then. It's a generic language, with strong background in programming, and it doesn't have such an emphasis on validation of semantically-loaded subsets as XML applications had from the very beginning.
...would change size to adapt to the palm of the bearer..., erm, the user. The keys would be blank except when subjected to heat, then the glowing signs (Mordoric runes) would appear.
They likely mean bandwidth. It's impossible to modulate 1 terabit per second on a 2.4 GHz channel.
for some reason they decided to drop the XML format from the PIM
If this is really so, this means they lost me as a prospective customer. I don't want a Linux PDA to play the same old games with proprietary formats.
At least, until SyncML synchronization is unavailable for C700, there is little reason for me to prefer it over Pocket PC. Heck, there are SyncML add-ons for Pocket PC already.