When Open Source advocates realize this, they'll start developing software the community needs, not just themselves.
You have a basic misunderstanding of how open source works. People write open source software to get their own work done and they share it with others in hopes of getting improvements back.
There is no incentive for anybody to write software for some nebulous other "community" nor do most people have some master plan to replace all commercial software. If there is no open source equivalent of some piece of commercial software, that simply means the commercial market must be serving its users well enough. In that case, by all means, please do stick with the commercial software.
While there may be some "zealots" who want "to bring Linux to market", you'd be foolish to rely on them for your computing needs. In real life, when it comes to open source, either you roll up your sleeves or you pay BillG; whining and hoping that others will do your work for you for free is pointless.
So? What does that have to do with whether Quicktime was new technology or not?
Video compression had been worked on for years by that point. People were already talking about object-based video compression. The 68020 was being used in desktop workstations running UNIX.
Both then and now, Apple put a nice face on existing technology.
There was no "flaming" in the message you were responding to. It is people like you that think any message that criticises something dear to their heart is a "flame" or a "troll" that make Slashdot such an unpleasant place sometimes.
If you disagree with an opinion in a reasonably politely worded message, respond with a good technical argument. Don't throw out random accusations or moderate down messages you merely disagree with.
Also, don't point people at a few hundred pages of documentation--it's counterproductive. If proponents of a tool are incapable of producing a concise statement of why their tool is better than other tools, people are entitled to assume that it isn't worth looking into it further. The burden of proof is on the shoulders of people who want mindshare, not on the shoulders of people who want to use existing tools.
(As for Ruby, it seems like a reasonable language with a nicer C interface than Python. Enough to switch? I don't know.)
The volume charges should be set that 98% of the customers see no change, or a slight decrease, in their bill (including a large volume included in the base rate). It's just to formalize a policy that de-facto already exists: if you are in the top 2% or so, even today, they may just force you to accept a business account.
And if you are worried that you might exceed your volume accidentally, ISPs might send you IM notification when you approach your limit, as well as give you real-time access to your accounting info.
If they take it back opened, you can copy it to your PC via analog, convert it to MP3, share it with all your friends, and return it for a full refund. What a brilliant move on the part of the music industry.
I agree with the sentiment. However, Compaq may not pay a per-device charge. In any case, the hardware is nice and (parts of) Compaq have been working really hard to support Linux on these devices, so the company is at least somewhat supportive of Linux.
iPaqs have been running Linux for several years and are quite popular.
There are not tons and tons of small-screen Linux apps to be ported to the Sharp.
There are tons of X11 apps with X11 display logic that can be usefully ported to X11 handhelds with only small modifications to the UI.
One of the biggest problems normal users have with X11 are all the differing toolkits.
I have never seen any evidence for that, and repeating that claim endlessly doesn't make it true. In fact, I suspect most people couldn't tell a well-written Qt application from a well-written Gtk+ application. Furthermore, even on Windows or MacOS, developers use many different toolkits, yet users don't seem to notice.
Not to mention that X is a hog, both in bandwidth and in memory and disk space requirements.
A 200MHz iPaq or Sharp has about 10x the speed and memory of desktop workstations on which X11 was used traditionally. X11's performance, disk space requirements, and memory requirements are as good as most "embedded" toolkits. The reason why X11 uses a lot of memory on your Linux box is because it can and because it is deliberately configured that way, not because there is anything intrinsic about X11 that requires a lot of resources.
And don't tell me about "low bandwidth X" and Tiny X - they all serve to illustrate that X is fundamentally broken, and certainly isn't for handhelds.
The X11 protocol was designed for Ethernet and works very efficiently on Ethernet, better than any of the alternatives. LBX was designed to adapt X11 for low bandwidth, high latency connections and works as well as anything over those. I don't know what TinyX is supposed to be for, but you don't need it for a 200MHz handheld. you don't even need it for a 66MHz handheld with 8M of RAM.
The people who are screaming for X on a handheld need to come out and live in the Real World.
I think the people who keep badmouthing X11 should get a clue.
Here in the USA, the most technologically advanced society in the world, it's difficult if not impossible to get *any* high speed service outside a major metropolitan area.
I'm not sure whether the first part of your sentence is an attempt at irony or reflects an actual belief. In the US, you can get the most high-tech gadgets if you are willing to pay for it and put in the effort. But US society on average is pretty low-tech and relies on pretty outmoded technology, in just about every area of life. In part that's because Americans can get away with it (if energy is cheap and homes are large, for example, you can live with inefficient and bulky appliances), in part it's because the government is reluctant to set high-tech standards.
The US free-market approach doesn't work for communications networks: the average and short-term market forces determine what you can get at any price. If your cable provider only wants to sell you MSN-tied-in asymmetric marketing-driven pseudo-Internet-access because that's what 95% of the US population is satisfied with, then that's the only thing you are going to get at any reasonable price.
Land-based phone systems in European countries are technically excellent. Of course, European phone systems do charge by the minute. I don't see that as a disadvantage, however. Flat pricing models in the US cause all sorts of problems for phone companies and ISPs and they should never have been introduced. Flat pricing only makes sense if the cost of itemized billing is higher than the cost imposed even by heavy users of the system. Otherwise, light and average users subsidize heavy users.
The US, too, has a good wired phone network. But it was created by a large, deliberate monopoly that could design in some coherence. High speed Internet access and cell phone systems in the US, however, "SUCK", to use your words. That's not because the US got it first, but because market forces cause companies to rush to market with multiple incompatible systems prematurely.
There was some period of time when routing tables were a problem. And, in a sense, it still is: there are lots of tiny networks (including huge numbers of two-address networks for DSL); if all of them got class C addresses, we'd probably run out of space.
But another reason is that there is no incentive for changing the status quo. Letting the routers handle large tables means more work and more downtime and for what? Increased competition and less customer loyalty. It's not surprising that the people who could open it up don't have much interest in doing so. And I wouldn't expect that to change with IPv6.
OK, here is what consumers want: fast downloads and web pages. That means a fast pipe. And if people pay a premium for service, they want that bandwidth and latency guaranteed (within reason).
But if a fast pipe is open all the time, the math doesn't work out for access providers, since a few people can saturate the whole backbone connection.
The solution? Charge by volume. Have a peak and an off-peak tariff. Works for electricity.
Well the problem is that you don't really pay for that amount of bandwidth. They are banking on the fact that most people won't max out the connection all the time, so you're paying for a certain maximum amount of bandwidth.
Actually, the real problem is that access providers don't guarantee any amount of bandwidth or any kind of reliability, while their advertising and sales department sell hype. They don't even provide information about much bandwidth and how many users they actually have. Blaming the consumer for this seems rather twisted to me.
If everyone does max out their bandwidth all the time, then they'd be forced to actually charge you for the full bandwidth - likely it'd be significantly more than you currently pay.
That's a bogus argument. Access providers know full well what kind of bandwidth per customer they can support and how oversubscribed they are. If that information looked good to consumers, you can bet they would share it. The logical conclusion is that because access providers are not making this information public, customers must be overpaying, not underpaying.
TrollTech has been very supportive of KDE's development since the beginning, and has bent over backwards to please Free Software advocates by GPLing their main, high-quality product.
TrollTech didn't do this out of charity, they did it to popularize a toolkit that otherwise wouldn't have had a chance in the market: at the time Qt came out, there were already several established commercial toolkits out there, with better tool support and much better documentation. The only gimmick Qt had was the QPL, and the adoption by KDE the popularized it.
I hope they don't do this. If they do, they will just discourage companies from GPLing their products.
The GPL is a two-way street. TrollTech has profited handsomely from the adoption of Qt by the open source community. If they didn't like the deal, they didn't have to take it--they were under no obligation to put Qt under the GPL. I hope any other company will take notice and think carefully about putting software under the GPL.
Trolltech's whole angle has been to make money on the windows ports of their Qt library,
TrollTech's angle has been to make money from commercial developers on any platform. I suspect that TrollTech actually gets more revenue from UNIX, but they have to answer that.
TrollTech's angle has also been to popularize an otherwise commercially irrelevant toolkit by getting lots of students open source developers to spend time learning it, evangelizing for it at their employers, and contribute suggestions for improvements.
...too be getting X10 pop-under ads. Otherwise, they would know that they could order this stuff for under $100 over the web (blond babe not included).
Well, a kernel and GUI that is written from the ground up in C++ could be heaven or it could be hell. Properly used, C++ can help a lot with data abstraction and safety with no loss of efficiency, but poorly used, it can make things a lot worse than plain C and give you performance problems in addition. On multi-programmer problems, C++ seems to turn into hell rather than heaven more often than not.
Altogether, I wonder whether AtheOS is sufficiently different from Linux/X11 to attract much interest. If kernel, driver, and application development for it were orders of magnitude easier, I could see switching. But given that it seems to be built using fairly traditional software technologies, why would it be all that much better?
Time will tell, but I won't be an early adopter of this one...
I did read the whole patent before posting. The authors mention alpha blending, but they mischaracterize it. Go back to the textbook reference I gave before flaming.
The fact remains that these people tried to patent what was already a standard textbook technique at the time. Whether they deliberately mischaracterized and ignored prior art, or whether they were simply ignorant you will have to decide for yourself.
Unfortunately, the article referenced does not seem to give any details for why people think this isn't "relevant"; there is no analysis of the claims.
Apple itself identified the patent as relevant to SVG and at some point asked for non-discriminatory royalty payments. They apparently have backed off from those requirements by now, but Apple still hasn't dedicated the patent to the public domain, leaving some legal uncertainty hanging over open source projects.
If the Apple patent were valid, I think it could be a problem and might have to be overturned. In that sense, it is "relevant", and it makes a lot of sense to collect prior art.
It's also relevant in a different sense: it tells us about what Apple is up to, what their attitude is towards free and open source software, and the intellectual and research standards at the company.
Perhaps they didn't realize it was a linear system. Many cryptosystems are broken when someone figures out "but your incredibly complex system is really mostly just doing X", for some well-known mathematical construct "X". Real cryptographers have made similar mistakes in the dim past, although in 2001, it is perhaps a little late for repeating this particular one.
I recommend reading SQL for Smarties, which explains at great lengths how to implement hierarchical data structures in SQL. You'll see that it's not trivial to do well. And you'll learn something. If you ever actually deliver a high-performance commercial application based on a relational database, it will come in handy, I promise.
The relationship property of two nodes in a tree IS [a relation].
Indeed it is. However, something like the "parent(x,y)" relation satisfies particular properties that the relational model has no support for enforcing. Furthermore, algorithms over trees are intrinsically recursive and usually require a recursive exploration of such a relation; you cannot express that with a bounded number of relational queries--it requires iterating queries together with transactioning across those queries, procedural code that falls outside the relational model and that, incidentally, is also very slow when implemented on top of standard relational databases.
The complexity for any representation is of the same Big-O order, regardless of the database type.
In real-world applications, constants matter, a lot in fact, so even if the algorithms weren't just the same big-O, but the same big-Omega, there would still be an issue. Second, the issue is not a clear-cut as you seem to think: depending on the specific relational database model one adopts, you may end up paying extra logarithmic or even linear factors in the size of the database.
The article clearly says that the information is being destroyed:
Some librarians asked if they could simply pull the CD from shelves and put it in a secure place, but federal officials told them it had to be destroyed.
You also wrote:
I argue it never should have been so carelessly deployed in the first place. The hype and the rush to make information available on the web could have been more carefully evaluated, especially by the holders of the plans. Not just plans to dams and waterways, either. Now it's deployment-readiness is being re-evaluated. I doubt it's much more than that.
I can't think of information that would be of more public interest than whether my community is at risk from a poorly built chemical plant, from an ill-placed dam, or whether a watershed or water supply is at risk from logging or contamination.
Your view is the traditional "security through obscurity". It doesn't work: it only puts people at risk from accidents and exploitation. Vulnerabilities need to be corrected, not hidden, no matter how inconvenient that may be for industry or the government. A smart terrorist has lots of time on his hands and doesn't need the library to figure this stuff out for one target; the people who need that information are environmentalists and citizens, who cannot devote their whole lives to this stuff but still want to protect and create livable and safe communities everywhere.
Many of the books on the shelves at libraries are probably much more "dangerous" than those government reports. Standard textbooks and research papers contain information about how to create dangerous chemicals and organisms, how to protect yourself during laboratory work, and how such dangerous chemicals and organisms can be dispersed. Of course, those textbooks don't talk about terrorism or warfare, they talk about agriculture, organic chemistry, and molecular biology.
At the end of this path is a society in which a few, carefully screened individuals have all the knowledge and the rest of the population lives in ignorance. In fact, throughout history, we have had societies like that. The "knowledge elite", of course, derives lots of power and wealth from their knowledge and soon dispenses with the need to consider input from the masses, who don't know what's going on anyway.
It is up to us in a democratic society to decide how far we want to go down that path. At least we still have the choice for now--once we are too far down that path, democracy inevitably disappears, since you can't make informed political decisions if you don't have information.
everything looks like a nail. The relational model is pretty good for its original purpose: allowing non-specialists quick access to large amounts of statistical and business data (sales records, etc.) via an easy-to-learn query language. But for many other applications, it has proven to be completely insufficient.
Indeed, that's the very touchstone that distinguishes relational databases from something like DBM and its many descendants.
The alternative to relational databases is not "DBM", it is object oriented, tree structured, logical, and other kinds of database models. Those are just as well defined as relational databases.
And *that* is important because it assures the desiger and user that every possible operation is well-defined and (hopefully) correctly implemented. The exact syntax for a "join" may differ, and a specific implementation may be flawed, but everyone agrees to a common baseline.
Relational databases provide a common baseline for a primitive set of relational operations. Real-world implementations of those models have been augmented by zillions of operations that weren't part of the original relational model and that often don't even fit into the relational model. And without those extra operations, relational databases would not be useful in practice.
For now, AFAIK, there is none other than that you get when you map a hierarchial database into relational tables and use exactly those relational properties.
Are you kidding? It is a major pain trying to express hierarchical data in a relational database model: the relations that describe hierarchical data and the operations that you might want to execute often require complex, multiple, inefficient queries and updates, and the relational model provides few tools to ensure that the corresponding relations remain consistent.
The semantics of tree structures are trivial to define. People do it in programming language classes all the time. And it is trivial to formulate a database model corresponding to it. In fact, if you have an object-oriented database that respects language semantics, you get hierarchical databases automatically when you define an abstract tree datatype.
Still, so-called "relational" databases will continue to dominate the market for a long time to come. That's not because the relational model is particularly well-suited to a lot of applications. In part, that's because "relational databases" are not purely relational anymore: they generally include numerous facilities for object-oriented and hierarchical databases, under a "relational veneer". They even include the old "navigational" database systems, combined with the widespread use of stored procedures that do whatever they want whenever they want it on the database server.
In different words, traditionally relational databases will provide increasingly better support for hierarchical and object-oriented data, but they will continue to also support the relational model, as well as relational access to these other data types. And newly developed databases with other kinds of data models will provide an SQL or other relational frontend to their content. And marketing will continue to include "something-relational" in all the advertising because otherwise the old database hands won't buy it.
Slashdot Mirror
You have a basic misunderstanding of how open source works. People write open source software to get their own work done and they share it with others in hopes of getting improvements back.
There is no incentive for anybody to write software for some nebulous other "community" nor do most people have some master plan to replace all commercial software. If there is no open source equivalent of some piece of commercial software, that simply means the commercial market must be serving its users well enough. In that case, by all means, please do stick with the commercial software.
While there may be some "zealots" who want "to bring Linux to market", you'd be foolish to rely on them for your computing needs. In real life, when it comes to open source, either you roll up your sleeves or you pay BillG; whining and hoping that others will do your work for you for free is pointless.
Video compression had been worked on for years by that point. People were already talking about object-based video compression. The 68020 was being used in desktop workstations running UNIX.
Both then and now, Apple put a nice face on existing technology.
If you disagree with an opinion in a reasonably politely worded message, respond with a good technical argument. Don't throw out random accusations or moderate down messages you merely disagree with.
Also, don't point people at a few hundred pages of documentation--it's counterproductive. If proponents of a tool are incapable of producing a concise statement of why their tool is better than other tools, people are entitled to assume that it isn't worth looking into it further. The burden of proof is on the shoulders of people who want mindshare, not on the shoulders of people who want to use existing tools.
(As for Ruby, it seems like a reasonable language with a nicer C interface than Python. Enough to switch? I don't know.)
And if you are worried that you might exceed your volume accidentally, ISPs might send you IM notification when you approach your limit, as well as give you real-time access to your accounting info.
If they take it back opened, you can copy it to your PC via analog, convert it to MP3, share it with all your friends, and return it for a full refund. What a brilliant move on the part of the music industry.
I agree with the sentiment. However, Compaq may not pay a per-device charge. In any case, the hardware is nice and (parts of) Compaq have been working really hard to support Linux on these devices, so the company is at least somewhat supportive of Linux.
iPaqs have been running Linux for several years and are quite popular.
There are not tons and tons of small-screen Linux apps to be ported to the Sharp.
There are tons of X11 apps with X11 display logic that can be usefully ported to X11 handhelds with only small modifications to the UI.
One of the biggest problems normal users have with X11 are all the differing toolkits.
I have never seen any evidence for that, and repeating that claim endlessly doesn't make it true. In fact, I suspect most people couldn't tell a well-written Qt application from a well-written Gtk+ application. Furthermore, even on Windows or MacOS, developers use many different toolkits, yet users don't seem to notice.
A 200MHz iPaq or Sharp has about 10x the speed and memory of desktop workstations on which X11 was used traditionally. X11's performance, disk space requirements, and memory requirements are as good as most "embedded" toolkits. The reason why X11 uses a lot of memory on your Linux box is because it can and because it is deliberately configured that way, not because there is anything intrinsic about X11 that requires a lot of resources.
And don't tell me about "low bandwidth X" and Tiny X - they all serve to illustrate that X is fundamentally broken, and certainly isn't for handhelds.
The X11 protocol was designed for Ethernet and works very efficiently on Ethernet, better than any of the alternatives. LBX was designed to adapt X11 for low bandwidth, high latency connections and works as well as anything over those. I don't know what TinyX is supposed to be for, but you don't need it for a 200MHz handheld. you don't even need it for a 66MHz handheld with 8M of RAM.
The people who are screaming for X on a handheld need to come out and live in the Real World.
I think the people who keep badmouthing X11 should get a clue.
I believe Yopy dropped "W" and switched to X11.
I'm not sure whether the first part of your sentence is an attempt at irony or reflects an actual belief. In the US, you can get the most high-tech gadgets if you are willing to pay for it and put in the effort. But US society on average is pretty low-tech and relies on pretty outmoded technology, in just about every area of life. In part that's because Americans can get away with it (if energy is cheap and homes are large, for example, you can live with inefficient and bulky appliances), in part it's because the government is reluctant to set high-tech standards.
The US free-market approach doesn't work for communications networks: the average and short-term market forces determine what you can get at any price. If your cable provider only wants to sell you MSN-tied-in asymmetric marketing-driven pseudo-Internet-access because that's what 95% of the US population is satisfied with, then that's the only thing you are going to get at any reasonable price.
The US, too, has a good wired phone network. But it was created by a large, deliberate monopoly that could design in some coherence. High speed Internet access and cell phone systems in the US, however, "SUCK", to use your words. That's not because the US got it first, but because market forces cause companies to rush to market with multiple incompatible systems prematurely.
But another reason is that there is no incentive for changing the status quo. Letting the routers handle large tables means more work and more downtime and for what? Increased competition and less customer loyalty. It's not surprising that the people who could open it up don't have much interest in doing so. And I wouldn't expect that to change with IPv6.
But if a fast pipe is open all the time, the math doesn't work out for access providers, since a few people can saturate the whole backbone connection.
The solution? Charge by volume. Have a peak and an off-peak tariff. Works for electricity.
Actually, the real problem is that access providers don't guarantee any amount of bandwidth or any kind of reliability, while their advertising and sales department sell hype. They don't even provide information about much bandwidth and how many users they actually have. Blaming the consumer for this seems rather twisted to me.
If everyone does max out their bandwidth all the time, then they'd be forced to actually charge you for the full bandwidth - likely it'd be significantly more than you currently pay.
That's a bogus argument. Access providers know full well what kind of bandwidth per customer they can support and how oversubscribed they are. If that information looked good to consumers, you can bet they would share it. The logical conclusion is that because access providers are not making this information public, customers must be overpaying, not underpaying.
TrollTech didn't do this out of charity, they did it to popularize a toolkit that otherwise wouldn't have had a chance in the market: at the time Qt came out, there were already several established commercial toolkits out there, with better tool support and much better documentation. The only gimmick Qt had was the QPL, and the adoption by KDE the popularized it.
I hope they don't do this. If they do, they will just discourage companies from GPLing their products.
The GPL is a two-way street. TrollTech has profited handsomely from the adoption of Qt by the open source community. If they didn't like the deal, they didn't have to take it--they were under no obligation to put Qt under the GPL. I hope any other company will take notice and think carefully about putting software under the GPL.
TrollTech's angle has been to make money from commercial developers on any platform. I suspect that TrollTech actually gets more revenue from UNIX, but they have to answer that.
TrollTech's angle has also been to popularize an otherwise commercially irrelevant toolkit by getting lots of students open source developers to spend time learning it, evangelizing for it at their employers, and contribute suggestions for improvements.
...too be getting X10 pop-under ads. Otherwise, they would know that they could order this stuff for under $100 over the web (blond babe not included).
Altogether, I wonder whether AtheOS is sufficiently different from Linux/X11 to attract much interest. If kernel, driver, and application development for it were orders of magnitude easier, I could see switching. But given that it seems to be built using fairly traditional software technologies, why would it be all that much better?
Time will tell, but I won't be an early adopter of this one...
The fact remains that these people tried to patent what was already a standard textbook technique at the time. Whether they deliberately mischaracterized and ignored prior art, or whether they were simply ignorant you will have to decide for yourself.
Apple itself identified the patent as relevant to SVG and at some point asked for non-discriminatory royalty payments. They apparently have backed off from those requirements by now, but Apple still hasn't dedicated the patent to the public domain, leaving some legal uncertainty hanging over open source projects.
If the Apple patent were valid, I think it could be a problem and might have to be overturned. In that sense, it is "relevant", and it makes a lot of sense to collect prior art.
It's also relevant in a different sense: it tells us about what Apple is up to, what their attitude is towards free and open source software, and the intellectual and research standards at the company.
Perhaps they didn't realize it was a linear system. Many cryptosystems are broken when someone figures out "but your incredibly complex system is really mostly just doing X", for some well-known mathematical construct "X". Real cryptographers have made similar mistakes in the dim past, although in 2001, it is perhaps a little late for repeating this particular one.
The relationship property of two nodes in a tree IS [a relation].
Indeed it is. However, something like the "parent(x,y)" relation satisfies particular properties that the relational model has no support for enforcing. Furthermore, algorithms over trees are intrinsically recursive and usually require a recursive exploration of such a relation; you cannot express that with a bounded number of relational queries--it requires iterating queries together with transactioning across those queries, procedural code that falls outside the relational model and that, incidentally, is also very slow when implemented on top of standard relational databases.
The complexity for any representation is of the same Big-O order, regardless of the database type.
In real-world applications, constants matter, a lot in fact, so even if the algorithms weren't just the same big-O, but the same big-Omega, there would still be an issue. Second, the issue is not a clear-cut as you seem to think: depending on the specific relational database model one adopts, you may end up paying extra logarithmic or even linear factors in the size of the database.
You also wrote:
I argue it never should have been so carelessly deployed in the first place. The hype and the rush to make information available on the web could have been more carefully evaluated, especially by the holders of the plans. Not just plans to dams and waterways, either. Now it's deployment-readiness is being re-evaluated. I doubt it's much more than that.
I can't think of information that would be of more public interest than whether my community is at risk from a poorly built chemical plant, from an ill-placed dam, or whether a watershed or water supply is at risk from logging or contamination.
Your view is the traditional "security through obscurity". It doesn't work: it only puts people at risk from accidents and exploitation. Vulnerabilities need to be corrected, not hidden, no matter how inconvenient that may be for industry or the government. A smart terrorist has lots of time on his hands and doesn't need the library to figure this stuff out for one target; the people who need that information are environmentalists and citizens, who cannot devote their whole lives to this stuff but still want to protect and create livable and safe communities everywhere.
At the end of this path is a society in which a few, carefully screened individuals have all the knowledge and the rest of the population lives in ignorance. In fact, throughout history, we have had societies like that. The "knowledge elite", of course, derives lots of power and wealth from their knowledge and soon dispenses with the need to consider input from the masses, who don't know what's going on anyway.
It is up to us in a democratic society to decide how far we want to go down that path. At least we still have the choice for now--once we are too far down that path, democracy inevitably disappears, since you can't make informed political decisions if you don't have information.
Indeed, that's the very touchstone that distinguishes relational databases from something like DBM and its many descendants.
The alternative to relational databases is not "DBM", it is object oriented, tree structured, logical, and other kinds of database models. Those are just as well defined as relational databases.
And *that* is important because it assures the desiger and user that every possible operation is well-defined and (hopefully) correctly implemented. The exact syntax for a "join" may differ, and a specific implementation may be flawed, but everyone agrees to a common baseline.
Relational databases provide a common baseline for a primitive set of relational operations. Real-world implementations of those models have been augmented by zillions of operations that weren't part of the original relational model and that often don't even fit into the relational model. And without those extra operations, relational databases would not be useful in practice.
For now, AFAIK, there is none other than that you get when you map a hierarchial database into relational tables and use exactly those relational properties.
Are you kidding? It is a major pain trying to express hierarchical data in a relational database model: the relations that describe hierarchical data and the operations that you might want to execute often require complex, multiple, inefficient queries and updates, and the relational model provides few tools to ensure that the corresponding relations remain consistent.
The semantics of tree structures are trivial to define. People do it in programming language classes all the time. And it is trivial to formulate a database model corresponding to it. In fact, if you have an object-oriented database that respects language semantics, you get hierarchical databases automatically when you define an abstract tree datatype.
Still, so-called "relational" databases will continue to dominate the market for a long time to come. That's not because the relational model is particularly well-suited to a lot of applications. In part, that's because "relational databases" are not purely relational anymore: they generally include numerous facilities for object-oriented and hierarchical databases, under a "relational veneer". They even include the old "navigational" database systems, combined with the widespread use of stored procedures that do whatever they want whenever they want it on the database server.
In different words, traditionally relational databases will provide increasingly better support for hierarchical and object-oriented data, but they will continue to also support the relational model, as well as relational access to these other data types. And newly developed databases with other kinds of data models will provide an SQL or other relational frontend to their content. And marketing will continue to include "something-relational" in all the advertising because otherwise the old database hands won't buy it.