XML is mostly just a buzzword, used by middle-managers in meetings
Perhaps, but those meetings are about the fact that the department over there uses technology X and the department over here uses technology Y and the company saves $$$ if the two departments can actually talk because right now you pay people to do data entry twice and you pay more senior people to deal with the discrepancies.
These managers ask their tech people "How do we deal with this problem" and they hear "XML" and take that up the chain.
The bottom line is that in a company, system integration costs are the biggest expense in IT. XML decouples data from platforms and that makes integration easier and saves big bucks. So it becomes a buzzword because upper management needs buzzwords to describe things that enable.
I agree. JBoss is open source, and clearly the are pretty damn close to compliance. Even if Sun designed the test to expose every noncompliance JBoss has, the result will be good for JBoss. They'll do the tests, post the results, people will mob the incompatibilites, and then it will pass.
What I don't understand is why you need Sun to write the compatibility tests. Isn't it a fully documented standard? Why doesn't somebody just create an open source compatibility test?
Actually, this raises a good point. Why aren't rpm's distributed via P2P? Why don't blogs distribute stories this way?
The problem with P2P networks is that they are mostly used for piracy. This is not a property of the protocol but of the people who have chosen to use the protocol.
That the idea to use it as a platform to develope portable applications (using ECMAScript + XUL) is catching on slower than some people would expect.
I think there are two basic architecture issues that turn a lot of people off. The first is Javascript (ECMAscript). The only place this language has a foothold is in HTML. If the real goal is to have people write general applications, nobody uses javascript and so this meets a non-demand.
The second is the failure to separate concerns into layers very well. Presentation code in XML is heavily intermixed with behavior code written in javascript. A better model here is the one used by JSP custom tags. The behavior is encapsilated and isolated to another layer. XUL on the other hand really encourages you to intermix the two.
Here's my list. These are common criticisms, some (many) of which are addressed by improvements in 2.5, 3rd party patches, and things like Red Hat Advance Server. In fact, a good reference is the Oracle paper on this version of Linux.
1) Better SMP Scalability 2) Better Asynchronous IO support 3) Fully Preemptive Kernel 4) Better threading 5) Better Memory Managment (VM) 6) Better IO scheduling 7) 64-bit IO even on 32 bit architectures 8) Reduce or Eliminate "Bounce Buffering" 9) Fine grained locking of block devices 10) Support large memory pages 11) High Memory Page Table Entries 12) Better support for RAID controllers
I agree 100%. Kind of makes "RTFM" a bit ironic, no.
I'd like to see the major distros simply not support info and remove man pages that refer to it. Let people flood the email lists with stupid questions.
So now that I've spent some karma, let me propose something more constructive. Somebody should write a utility comparable to javadoc that creates the man pages from comments in the source code as part of the build process.
I didn't say OO was a niche player, I said people who think it is the right solution for all problems are niche players. I program in java all the time. I love ruby. Lots of good stuff is written in python and OO perl. OO is great for a wide range of programming tasks. Just not all tasks.
I really don't recall seeing a whole lot of the linux or freebsd kernels written in object oriented languages. Maybe I missed it. Perhaps you could post a message to the Linux kernal list saying "linux should be converted to C++" and see what kind of response you get.
Sorry this just won't cut it in most enterprise systems.
1) Doesn't scale. Most enterprise databases don't fit in RAM. Data volumes grow with the capacities of hard disks which outpace RAM. If your database fits in memory now and you use this architecture, what do you do when it grows larger than your RAM capacity? You fire the guy that proposed this and switch to an RDBMS.
2) Performance claims are BS. Good databases already serialize net changes to redo logs via a sort of binary diff of the data block. Redo logs are usually the limiting factor on transaction throughput, since they require IO to disk. Serializing the actual commands is more inefficient than using a data block diff. You simply cannot minimize the space any better than an RDBMS does, therefore you cannot minimize the IO for this serialization any better, and therefore you cannot do it faster without sacrificing ACIDity. If your performance is too good to be true, then you gave up an essentail feature of the RDBMS.
3) Consistancy. If there is only one object in memory for each record, then you'll be writing a tremendous amount of custom thread-safety code and even then, either A) writers block readers and readers block writers or B) read consistacny isn't guaranteed. Either is usually unacceptable. One alternative is to clone objects at every write (sounds slow and horribly inefficient). Of course, this too has to be serialized, or you don't have ACIDity. If you are serializing these, then you aren't really different than an RDBMS which uses rollback/undo, except you are wasting disk IO and are slower.
4) Reliability. A hardware failure, software hang/crash, or system administration mistake would force recovery from the last full backup. Replaying a full day's transactions could take hours. Sure you could be continually making a disk image, except for read consistancy issues like above. Its not clear what you do even for a daily backup. Are all sessions simply blocked during backup? Ouch.
Every few years object fanatics try to come up with some way to get rid of RDMBS's. The methods invariably rely on sacrificing some of the core capabilities of the RDBMS: data integrity, performance, consistency, ACID, reliability etc... These "innovations" are really only of interest to OO fanatics. In the real world, OO gets sacrificed way before RDBMS's do. This is not going to change.
OO is a tool that is good for writing maintainable code. It is not good for performance critical uses like OS's, device drivers, and real time systems. It is not good for data intensive systems. These things are not likely to change. If all you can accept is OO, then you are a niche player.
Re:The only once inside the GNOME-community
on
Has GNOME Become LAME?
·
· Score: 2, Interesting
How funny you are. The typo in your example "valuw2" really illustrates exactly why XML is a good thing.
You didn't include all the custom code that you have to write to validate that the numbers on the right side of the equals signs actually define valid settings for the variables. XML Schemas make this very easy.
Also, suppose I'm starting at your app and I wonder if I can use name2 = value2, valuw2 or do I need name2 = "value2, valuw2" or does it even make sense to give name2 a list? Or do I separate lists with ";" or maybe ":" like in the environment profile that you hold up as a model? Now I have to read your code. Don't pretend that you put this in the documentation, because you didn't mention the documentation when we were measuring "simpler syntax".
Of course, even on UNIX, nobody can agree on the exact syntax for the profile. Csh is different from bash is differnt from korn shell is different from blah, blah, blah. And nobody on non-unix platforms knows what the hell you are even talking about.
XML is THE standard for platform independent data. Bash script syntax is not.
Because it is the standard, and an open standard at that, you don't have to worry when you move your app to win32 or BeOS or Mac or Tru64 unix or fooOS about the availability of tools that can read and write the format.
OpenOffice.org is a registered trademark. I believe that MS has commited a trademark violation by conflating the valueable OpenOffice.org band name with its own crummy one. This letter is clearly likely to cause confusion and to intimidate users of OpenOffice.org software who fall prey to this confusion. It is also likely to dilute the OpenOffice.org trademark because potential users of this software may mistakenly beleive that its use is somehow an infringement on Microsoft's intellectual property.
OpenOffice.org should immediately send the BSA a cease and desist letter, and if necessary take legal action to stop this garbage.
The only Court that has considered this precise issue (whether mod chips violate anticircumvention copyright laws) is an Austrailian Court that adopted the position I am refering to in interpreting the Austrailian equivalent to the DMCA, which is extremely similar in wording.
The DMCA makes circuvention devices, which mod chips are, illegal.
Wrong and Wrong.
The DMCA does not make "circumvention devices" illegal. It makes circumvention devices that control access to copyrighted works without the authority of the copyright holder illegal, and only if the device "has only limited commercially significant purpose or use other than to circumvent a technological measure that effectively controls access to a work protected under this title".
A mod chip does not provide access to a copyrighted work at all. It might allow access to an already circumvented work, but only because it provides general purpose functionality. It certainly has very "significant purpose or use" other than accessing already circumvented works, namely creating a general purpose computing device that can, for example, run Linux on XBox.
Why on earth did this guy plead guilty? It seems to me he is accused of a non-crime, at least the way the web-site reads. He should appeal and the EFF should help him.
This is extremely revolting that the selling of mod chips would be viewed in and of itself as illegal. All you people out there who think the DMCA covers this are very confused. The DMCA violation occurs when you strip a client game program of its authentication key (and this is copyright infringement anyway). All this guy did was sell parts that turned the game console into a general purpose computer. This is NO different than selling general purpose computer parts.
Since when is changing a piece of hardware to enable it to work with additional 3rd party software copyright infringment? The DMCA regulates circumventing protection measures that control access to copyrighted works, not that prevent access to copyrighted works of others.
The DMCA does (legitimately) stop you from removing the authentication on the game. Copyright already stops you from copying it. Nobody has ever suggested that the DMCA forces you to ONLY access works of a specific copyright owner.
That's not a bad idea. I like the basic premise of creating a second, alternate email system that is more robust to the known problems. There are many ideas that could be experimented with.
I happen to know Dan Bernstein -- I went to graduate school with him. Nice guy, very sharp.
The existing email protocol already has this feature. Nowhere did I suggest banning the existing email system. The feautre I desire is that I be able to not allow such email from you or your children or Alan Ralsky. If I don't want to receive anonymous email, I am under no obligation to do so. If you don't like the fact that I don't want to contribute to your ability to send me anonymous email, then tough. I should have access to an email protocol that supports mandatory authentication whether Alan Ralsky or you like it or not.
I do agree that your children should not have access to the full featured internet. If you are giving them unsupervised access to the traditional email account, then you are derelict in you parenting duties, and I have no doubt they they have already looking at the porn that has no doubt arrived in their inbox because you insist on supporting the anonymous-enabled email system.
Slashdot Mirror
XML is mostly just a buzzword, used by middle-managers in meetings
Perhaps, but those meetings are about the fact that the department over there uses technology X and the department over here uses technology Y and the company saves $$$ if the two departments can actually talk because right now you pay people to do data entry twice and you pay more senior people to deal with the discrepancies.
These managers ask their tech people "How do we deal with this problem" and they hear "XML" and take that up the chain.
The bottom line is that in a company, system integration costs are the biggest expense in IT. XML decouples data from platforms and that makes integration easier and saves big bucks. So it becomes a buzzword because upper management needs buzzwords to describe things that enable.
I disagree. Do NOT get the ones where you can disable it. Get the ones that do not include it at all.
I agree. JBoss is open source, and clearly the are pretty damn close to compliance. Even if Sun designed the test to expose every noncompliance JBoss has, the result will be good for JBoss. They'll do the tests, post the results, people will mob the incompatibilites, and then it will pass.
What I don't understand is why you need Sun to write the compatibility tests. Isn't it a fully documented standard? Why doesn't somebody just create an open source compatibility test?
Actually, this raises a good point. Why aren't rpm's distributed via P2P? Why don't blogs distribute stories this way?
The problem with P2P networks is that they are mostly used for piracy. This is not a property of the protocol but of the people who have chosen to use the protocol.
Slap up a web page that uses python and XUL and I'll see how well my stock Mozilla browser handles it.
Hey, it was just being honest.
That the idea to use it as a platform to develope portable applications (using ECMAScript + XUL) is catching on slower than some people would expect.
I think there are two basic architecture issues that turn a lot of people off. The first is Javascript (ECMAscript). The only place this language has a foothold is in HTML. If the real goal is to have people write general applications, nobody uses javascript and so this meets a non-demand.
The second is the failure to separate concerns into layers very well. Presentation code in XML is heavily intermixed with behavior code written in javascript. A better model here is the one used by JSP custom tags. The behavior is encapsilated and isolated to another layer. XUL on the other hand really encourages you to intermix the two.
Moz on faster linux and windows machines, and Phoenix on slower linux and windows machines
Speaking of Phoenix, where is 0.6? According to the Phoenix Roadmap 0.6 was due in January and 0.7 was due in February.
Here's my list. These are common criticisms, some (many) of which are addressed by improvements in 2.5, 3rd party patches, and things like Red Hat Advance Server. In fact, a good reference is the Oracle paper on this version of Linux.
1) Better SMP Scalability
2) Better Asynchronous IO support
3) Fully Preemptive Kernel
4) Better threading
5) Better Memory Managment (VM)
6) Better IO scheduling
7) 64-bit IO even on 32 bit architectures
8) Reduce or Eliminate "Bounce Buffering"
9) Fine grained locking of block devices
10) Support large memory pages
11) High Memory Page Table Entries
12) Better support for RAID controllers
I agree 100%. Kind of makes "RTFM" a bit ironic, no.
I'd like to see the major distros simply not support info and remove man pages that refer to it. Let people flood the email lists with stupid questions.
So now that I've spent some karma, let me propose something more constructive. Somebody should write a utility comparable to javadoc that creates the man pages from comments in the source code as part of the build process.
So who owns all those moon rocks?
Well, no, but as part of the Homestead Act of 1826, a substantial part of the moon was set aside for use as an Indian Reservation.
I didn't say OO was a niche player, I said people who think it is the right solution for all problems are niche players. I program in java all the time. I love ruby. Lots of good stuff is written in python and OO perl. OO is great for a wide range of programming tasks. Just not all tasks.
I really don't recall seeing a whole lot of the linux or freebsd kernels written in object oriented languages. Maybe I missed it. Perhaps you could post a message to the Linux kernal list saying "linux should be converted to C++" and see what kind of response you get.
Sorry this just won't cut it in most enterprise systems.
1) Doesn't scale. Most enterprise databases don't fit in RAM. Data volumes grow with the capacities of hard disks which outpace RAM. If your database fits in memory now and you use this architecture, what do you do when it grows larger than your RAM capacity? You fire the guy that proposed this and switch to an RDBMS.
2) Performance claims are BS. Good databases already serialize net changes to redo logs via a sort of binary diff of the data block. Redo logs are usually the limiting factor on transaction throughput, since they require IO to disk. Serializing the actual commands is more inefficient than using a data block diff. You simply cannot minimize the space any better than an RDBMS does, therefore you cannot minimize the IO for this serialization any better, and therefore you cannot do it faster without sacrificing ACIDity. If your performance is too good to be true, then you gave up an essentail feature of the RDBMS.
3) Consistancy. If there is only one object in memory for each record, then you'll be writing a tremendous amount of custom thread-safety code and even then, either A) writers block readers and readers block writers or B) read consistacny isn't guaranteed. Either is usually unacceptable. One alternative is to clone objects at every write (sounds slow and horribly inefficient). Of course, this too has to be serialized, or you don't have ACIDity. If you are serializing these, then you aren't really different than an RDBMS which uses rollback/undo, except you are wasting disk IO and are slower.
4) Reliability. A hardware failure, software hang/crash, or system administration mistake would force recovery from the last full backup. Replaying a full day's transactions could take hours. Sure you could be continually making a disk image, except for read consistancy issues like above. Its not clear what you do even for a daily backup. Are all sessions simply blocked during backup? Ouch.
Every few years object fanatics try to come up with some way to get rid of RDMBS's. The methods invariably rely on sacrificing some of the core capabilities of the RDBMS: data integrity, performance, consistency, ACID, reliability etc... These "innovations" are really only of interest to OO fanatics. In the real world, OO gets sacrificed way before RDBMS's do. This is not going to change.
OO is a tool that is good for writing maintainable code. It is not good for performance critical uses like OS's, device drivers, and real time systems. It is not good for data intensive systems. These things are not likely to change. If all you can accept is OO, then you are a niche player.
How funny you are. The typo in your example "valuw2" really illustrates exactly why XML is a good thing.
You didn't include all the custom code that you have to write to validate that the numbers on the right side of the equals signs actually define valid settings for the variables. XML Schemas make this very easy.
Also, suppose I'm starting at your app and I wonder if I can use
name2 = value2, valuw2
or do I need
name2 = "value2, valuw2"
or does it even make sense to give name2 a list? Or do I separate lists with ";" or maybe ":" like in the environment profile that you hold up as a model? Now I have to read your code. Don't pretend that you put this in the documentation, because you didn't mention the documentation when we were measuring "simpler syntax".
Of course, even on UNIX, nobody can agree on the exact syntax for the profile. Csh is different from bash is differnt from korn shell is different from blah, blah, blah. And nobody on non-unix platforms knows what the hell you are even talking about.
XML is THE standard for platform independent data. Bash script syntax is not.
Because it is the standard, and an open standard at that, you don't have to worry when you move your app to win32 or BeOS or Mac or Tru64 unix or fooOS about the availability of tools that can read and write the format.
OpenOffice.org is a registered trademark. I believe that MS has commited a trademark violation by conflating the valueable OpenOffice.org band name with its own crummy one. This letter is clearly likely to cause confusion and to intimidate users of OpenOffice.org software who fall prey to this confusion. It is also likely to dilute the OpenOffice.org trademark because potential users of this software may mistakenly beleive that its use is somehow an infringement on Microsoft's intellectual property.
OpenOffice.org should immediately send the BSA a cease and desist letter, and if necessary take legal action to stop this garbage.
The only Court that has considered this precise issue (whether mod chips violate anticircumvention copyright laws) is an Austrailian Court that adopted the position I am refering to in interpreting the Austrailian equivalent to the DMCA, which is extremely similar in wording.
The DMCA makes circuvention devices, which mod chips are, illegal.
Wrong and Wrong.
The DMCA does not make "circumvention devices" illegal. It makes circumvention devices that control access to copyrighted works without the authority of the copyright holder illegal, and only if the device "has only limited commercially significant purpose or use other than to circumvent a technological measure that effectively controls access to a work protected under this title".
A mod chip does not provide access to a copyrighted work at all. It might allow access to an already circumvented work, but only because it provides general purpose functionality. It certainly has very "significant purpose or use" other than accessing already circumvented works, namely creating a general purpose computing device that can, for example, run Linux on XBox.
I'm surprised that France didn't ask for more proof that spam was a problem.
On the other hand, what happens if you ignore France and keep violating the law? Are you guaranteed they'll perpetually seek a "diplomatic solution"?
Why on earth did this guy plead guilty? It seems to me he is accused of a non-crime, at least the way the web-site reads. He should appeal and the EFF should help him.
This is extremely revolting that the selling of mod chips would be viewed in and of itself as illegal. All you people out there who think the DMCA covers this are very confused. The DMCA violation occurs when you strip a client game program of its authentication key (and this is copyright infringement anyway). All this guy did was sell parts that turned the game console into a general purpose computer. This is NO different than selling general purpose computer parts.
Since when is changing a piece of hardware to enable it to work with additional 3rd party software copyright infringment? The DMCA regulates circumventing protection measures that control access to copyrighted works, not that prevent access to copyrighted works of others.
The DMCA does (legitimately) stop you from removing the authentication on the game. Copyright already stops you from copying it. Nobody has ever suggested that the DMCA forces you to ONLY access works of a specific copyright owner.
Is anybody making an archive of all the bullshit patents?
That's not a bad idea. I like the basic premise of creating a second, alternate email system that is more robust to the known problems. There are many ideas that could be experimented with.
I happen to know Dan Bernstein -- I went to graduate school with him. Nice guy, very sharp.
The existing email protocol already has this feature. Nowhere did I suggest banning the existing email system. The feautre I desire is that I be able to not allow such email from you or your children or Alan Ralsky. If I don't want to receive anonymous email, I am under no obligation to do so. If you don't like the fact that I don't want to contribute to your ability to send me anonymous email, then tough. I should have access to an email protocol that supports mandatory authentication whether Alan Ralsky or you like it or not.
I do agree that your children should not have access to the full featured internet. If you are giving them unsupervised access to the traditional email account, then you are derelict in you parenting duties, and I have no doubt they they have already looking at the porn that has no doubt arrived in their inbox because you insist on supporting the anonymous-enabled email system.
Script are good for quick and dirty work, but when one come two years after do to maintenance, good plain old langage are perhaps best.
I'll take python over C in a maintainability contest any day. Pointers and memory management are notoriously hard to maintain.