Yep, however, CS3 was the version I was referring to..it is now more than 1 year old, and people are want to use the latest, there are lot's of goodies.
Also, it feels smoother than it's predecessor.
...installation and all...then the year of the Linux desktop would be here, for sure.
I can't believe why that isn't the almost singular purpose of that project. It would make a huge difference since PS has no real alternative on Linux. At least one almost similar the to what users are used to. All other business applications, like word and others, has corresponding. Yeah, sure, maybe there aren't many CAD applications either, but engineers aren't the ones that need the super-easy transitions. And CAD-users are somewhat fever, at least afaik...
I know I am not first one to say this, I just feel that it needs to be said again.
I'd say: Quit your crappy ISP! I they have oversold you network that badly you don't get what you are paying for. It has nothing at all to do with capping but all to do with network management.
To an ISP of that caliber, capping would only allow them to lower their standards even further. Why? Since you are accepting the situation as it is now, you will probably also would with it capped. They would just make up another excuse.
Last time I checked, Mozilla Corporation is a for-profit company.
Quote wikipedia: "The Mozilla Corporation reinvests some or all of its profits back into the Mozilla projects.[2] The Mozilla Corporation's stated aim is to work towards the Mozilla Foundation's public benefit to "promote choice and innovation on the Internet."
Just like Microsoft, right? Except it isn't: "The Mozilla Corporation was established on August 3, 2005 to handle the revenue-related operations of the Mozilla Foundation. As a non-profit, the Mozilla Foundation is limited in terms of the types and amounts of revenue. The Mozilla Corporation, as a taxable organization (essentially, a commercial operation), does not have to comply with such strict rules. Upon its creation, the Mozilla Corporation took over several areas from the Mozilla Foundation, including coordination and integration of the development of Firefox and Thunderbird (by the global free software community) and the management of relationships with businesses.
With the creation of the Mozilla Corporation, the rest of the Mozilla Foundation narrowed its focus to concentrate on the Mozilla project's governance and policy issues. In November 2005, with the release of Mozilla Firefox 1.5, the Mozilla Corporation's website at mozilla.com was unveiled as the new home of the Firefox and Thunderbird products online.
In 2006 the Mozilla Corporation generated 66.8 million dollars in revenue and 19.8 million in expenses, with 85% of that revenue coming from Google for "assigning [Google] as the browser's default search engine, and for click-throughs on ads placed on the ensuing search results pages."[4]"
This was posted on the 3rd. On the highly unlikely event that it was you that posted that bug, maybe you should give them more than 3 days to do something about it before bashing them on/.? Also, I would categorize this as a low priority bug(OMFG? Pressing a button AN EXTRA COUPLE OF TIMES? You still alive?), so don't hold your breath. It is also in the 1.8 branch..
You know one thing I find annoying? Users that find bugs and never tell you about them.
Wow. Why aren't we in the US trying to do this? We used to be so worried about the Communists beating us. But now it's like we don't even care. Where's the fire?
"Now wait a minnit there, skeeter. Don't forget we got'em humvees and a mile is way longer than a kilometer."
2. Since you have neither read the article or posted anything worth reading, I'd say that your post, or should I call it noise, is a perfect example of why we should.
No, but the voices reassure me and tell me not to listen to you.
Since I used to work with 4D(http://www.4d.com/), the *easily* most insane development language/toolkit ever made, MY voices reassures me that it's OK not to.
* My god, you seem to be pissed off in general, or you deliberately misunderstood all points I tried to make. * The RFC is only applicable to small systems. Obviously. * Yep, DNS is technically a database, I know this since I am not a total moron. But that was not my point either. Most NOC-servers does not use DNS, but a specific database, to store system specific data, mostly for security, TTL, and availability/redundancy reasons(not all eggs in the same basket). * A file server is a server that serves files, this might or might not include an FTP server. I wasn't pretending to come up with a perfect standard. I said rough, remember? * In larger systems, you seldom, if ever, change the role of a server(during it's 3 year life span).
Especially with all the virtualisation going on, it is much easier to simply create a new one. But I would rename it, if that happened.
1 & 2. The limitations of theme-based naming schemes does not stem from the number of available names, but the fact that it is impossible to read any information from the name of a server called "FIDO". Hence, all new employees need to learn lots of wierd names. 3. No, numbers would not be OK, since you usually work with maybe 5-6 servers at a time. Once you figure it out, using ERDBDEV02 is waay better than constantly having to remember new variants of DODO, FIDO or SAURON.
Imagine this: A user calls, "my system says 'an error with the BILBO-server prevent the application from starting.'. What do I do?". Now say you have hundreds of servers...well, yeah, you could have the BILBO server name in some support database, but since that is obviously not working right now due to some(maybe related) DNS issue, you don't know what it is. A good point is that BILBO is easier to spell over the phone than LSWIN03, but that point has nothing on the fact that you immediately know that it is logon server 3 that is failing.
That's just how it works for me. Or worked. I am not a sysadmin anymore, even though I do handle some servers for development purposes.
I have never seen a slashdot thread with as many serious, and disparate, replies before. And the RFC(1178) that someone pointed at was, at it's best, unhelpful.
If there was a standard(Something for OpenISO, perhaps?) that everybody used, it would be great. Then we would all only need to learn one standard. Which, I think, would feel more acceptable to most. And no, this is not about "freedom", it's about being pissed of twice a day because some bastard named a server after his old girlfriends dog.
Server names could also then be created automatically, using easy-to use GUI tools for the faint of heart, and also "decode" in the same way, making some level of rough categorization possible(i.e. "list all file servers"). You might argue that that kind of data should be stored in a database, and not in a server name. Then I ask you, why do server names exist at all, if not to define the server for it's users? Why not only use IP then? Regarding the location of the server, however, I don't think that should be in the server name(i'd rather put that in the subdomain). I mean, a mail server running Linux will continue to do so even if it is moved to a new location.
And yeah, were I work we use abbreviations, which results in names like SRVAPPDEVVM03 (the VM-part, denoting a virtual machine, feels a bit unecessary nowadays, though). I wouldn't say I am particularly pleased with our way, but there is only so much time left to think about things, it seems. Using abbreviations are a complete necessity though.
But I have also been naming stuff after LOTR-caracters, Cartoon characters and whatever, too. That stopped working way back, when we passed the 20-server mark, though.
Also, the customers aren't prepared to cough up what it takes to make the applications secure. Some say this is a myth. I'd say that is not. I have only met a few that even ask questions about application security. We always try to sell security measures as a part of the solution. It is nearly impossible to make the customers understand without sounding paranoid and losing credibility.
And yes, I work a lot with banks and other similar entities which are supposed to have really high levels of security. In some areas(that would be those where the government agencies are breathing down their necks), they are really good and and have enormously bureaucratic(verging on PIA) ways to handle that security. But in almost ALL other areas of their application jungle, they aren't the least better, or even worse, than Joe's accounting down at the corner.
To end on a positive note, I did read a tender invite(i like it that way) for a new thing just the other day that explicitly excluded "office-like" products from being used in the solution. Not that we neither would, or even could do that anyway, but maybe they are getting it, after all. However, this is the first time i have ever seen this.
I believe it's a well-known fact that the current mod system allows users to only have mod points or a clue.;-) So they can have both then?:-) To those of you(the majority) that didn't realize that both generations of parent post were jokes, the GP's syntax should have been:
"I believe it's a well-known fact that the current mod system allows users to only have mod points XOR a clue.".
I don't, so please, with sugar on top, enlighten me. What the difference between two completely different expressions? Because I think rigor can be applied to requirements as well. I must be an ass.
That sounds like a severe case of nostalgia to me.
I don't think that these systems were made in a much more rigorous way than mission-critical systems are made today. Modern systems have so many more things they are expected to be able to perform, and are, in general, simply way more complex and way more layered.
Rather, the legacy systems were designed for very specific use cases and are, as a consequence, used in very specific ways. I mean, the banks I have worked with are probably among some of the most technologically backwards organizations I ever encountered. Their systems are also usually used in a totally isolated environment, and this have been done in exactly the same way forever. So security updates are an issue either. Since these system also haven't been developed further for a very long time, there has been no addition of code with potential bugs in it.
BUT, and this I would like to emphasize a bit, "legacy" systems typically aren't bug free at all. Typically people have to employ numerous workarounds to deal with them. Many of these workarounds has then, over time, become the "truth".
Just one small example of a typical legacy system bug: One summer, a long time ago, I was working at a company using a huge mainframe running a really old system. I had a huge bug; If one of the warehouse workers, in any of their warehouses(distributed all over the country) entered an invalid article number, that session got into a endless loop and consumed almost all of the systems resources. We are talking hundreds of people over a wide area that could not carry out their work. Now, it wasn't easy to even enter an invalid code, the system did *almost* not allow it. However, codes read though a bar code reader could be invalid, and it that code could also be accidentally edited, circumventing any checks.
I have friends that have told me many a similar story over the years, so I am totally convinced that I am not the only one and this is not the only huge, critical AND buggy legacy system out there. To the best of my knowledge and experience, most systems used for banking are positively riddled with old bugs and oversights.
If you had actually bothered to check the link Well, i actually had, and whether they sign an NDA or not is not important, the driver itself will be open source and hopefully well commented, which is almost as good as having the documentation. Then, of course, it is a matter of trust, NDA or not.
That's fine, but it doesn't make drivers magically appear out of thin air. They still have to be written. This is not a trivial task, especially when the specifications are not available. Yep, this is a problem. You are obviously right about that, since that's why we are having this discussion. However, the problem will not be solved by bashing the manufacturers, but instead by trying to figure out why they don't take an offer that seems like money in the bank. They would not take this stand without reasons to do it. And many of them are real-world and non-negotiable reasons, not just something they have to change their mind about.
But to find those reasons the community must try and see the problem from the manufacturers view, and realize that hardware development project has huge costs and dangers that are not the same as those in a commercial software development project. This makes hardware development a fundamentally different business from software development and requires a different mindset.
Adding to that, there are many academic types in FOSS that has never really worked much even in commercial *software* projects, where the rules and what one needs to take into consideration is different from the black- and white thinking of the academic world.
These points was not meant to apply to the software(which was to be written by a OSS developer, remember?), but to general detailed information regarding the hardware. You can deduce lot's of things about it through there and making a good hardware interface is hard and a competitive edge, if well executed.
And as such, I believe they are perfectly valid. An NDA is almost pointless since the driver itself, being open source and hopefully well commented, will reveal all the information needed. No one will need to ask it's developer. Also, it is likely that there will have to be many developers involved, which has to share information.
And with regards to no 7, it is my personal experience that most peoples' first impression of the OSS community as a bunch of over-idealistic leftie nerds.
First impressions last. And if the first impression isn't "business opportunity", it will last even longer.
Wrong. If your hardware manufacturer doesn't release decent drivers for Linux, the manufacturer sucks*. Wrong. It doesn't matter the least who *actually* sucks. If the stupid straight-out-of-win32-n00b user thinks it sucks, it sucks. Regardless. The average user doesn't care. And you know what? He shouldn't have to either. I am promoting Linux usage on all areas, but every time I read something like this, I feel strangely out of breath. This kind of attitude is the exact reason why it has taken SO DAMN LONG for Linux to become a viable desktop solution.
When you are done giving thanks, complain to your hardware manufacturer, who does make money from the deal, and does have the full specifications - AND for reasons unknown, have turned down the offer of OSS developers writing the drivers for them, for free. The reasons are hardly unknown: 1. They are (rightfully) afraid that their competitors will steal their ideas. If they supply a binary driver this is not as likely but since the Linux(i.e. the OSS) world is demanding the source, they feel it isn't worth it, since.... 2....the cost of organizing and legally protecting the stuff the release is high... 3....the cost of actually deciding what should be released is high.. 4. They, in their turn, are licensing other companies things, and to release their source they must convince them as well.. 5. Other companies use their technology through licenses, and does not want it to be released since THEIR competitors could use it. 6. Other agreements, for example with Microsoft, prevents them to. 7. It takes some time for some to understand that Open Source does not have to be communism. When RMS is on, it sounds a lot like it, you know.
This is just what i thought of from the top of my head, there are probably lots of other reasons. Many better than these, probably. It annoys the hell out of me that people doesn't understand this, and the more the manufacturers hear people whine like this, the more amateurish the Linux world appears.
The second these companies owners feel that the financial return of entering the Linux world outperforms the risks(did I hear something about "people in parents basements"?) they will come. So instead of badmouthing them, try to understand how they work and ease them in.
BTW, didn't mean to dismiss stored procedures totally(they still have some uses, however, the performance gained is just not very significant anymore and sometimes even a loss), was just thinking about when using them in ways that has to include the rest of the cluster.. Sorry 'bout that.
Slashdot Mirror
Yep, however, CS3 was the version I was referring to..it is now more than 1 year old, and people are want to use the latest, there are lot's of goodies. Also, it feels smoother than it's predecessor.
...installation and all...then the year of the Linux desktop would be here, for sure.
I can't believe why that isn't the almost singular purpose of that project. It would make a huge difference since PS has no real alternative on Linux. At least one almost similar the to what users are used to. All other business applications, like word and others, has corresponding.
Yeah, sure, maybe there aren't many CAD applications either, but engineers aren't the ones that need the super-easy transitions. And CAD-users are somewhat fever, at least afaik...
I know I am not first one to say this, I just feel that it needs to be said again.
I say bring on the caps!
I'd say: Quit your crappy ISP!
I they have oversold you network that badly you don't get what you are paying for.
It has nothing at all to do with capping but all to do with network management.
To an ISP of that caliber, capping would only allow them to lower their standards even further.
Why? Since you are accepting the situation as it is now, you will probably also would with it capped.
They would just make up another excuse.
Mod parent up! (I can't because i posted).
Last time I checked, Mozilla Corporation is a for-profit company.
Quote wikipedia:
"The Mozilla Corporation reinvests some or all of its profits back into the Mozilla projects.[2] The Mozilla Corporation's stated aim is to work towards the Mozilla Foundation's public benefit to "promote choice and innovation on the Internet."
Just like Microsoft, right?
Except it isn't:
"The Mozilla Corporation was established on August 3, 2005 to handle the revenue-related operations of the Mozilla Foundation. As a non-profit, the Mozilla Foundation is limited in terms of the types and amounts of revenue. The Mozilla Corporation, as a taxable organization (essentially, a commercial operation), does not have to comply with such strict rules. Upon its creation, the Mozilla Corporation took over several areas from the Mozilla Foundation, including coordination and integration of the development of Firefox and Thunderbird (by the global free software community) and the management of relationships with businesses.
With the creation of the Mozilla Corporation, the rest of the Mozilla Foundation narrowed its focus to concentrate on the Mozilla project's governance and policy issues. In November 2005, with the release of Mozilla Firefox 1.5, the Mozilla Corporation's website at mozilla.com was unveiled as the new home of the Firefox and Thunderbird products online.
In 2006 the Mozilla Corporation generated 66.8 million dollars in revenue and 19.8 million in expenses, with 85% of that revenue coming from Google for "assigning [Google] as the browser's default search engine, and for click-throughs on ads placed on the ensuing search results pages."[4]"
Because no more than one person could possibly be experiencing the same bug
Yep. Quite likely.
And besides being an excuse to not report bugs, it would also be an excuse to bash them on forums? Right?
This is really starting to get annoying.
I suppose you filed a bug report a few weeks ago and no one has done anything about it?
Don't bother to check, I am quite sure you didn't:
https://bugzilla.mozilla.org/show_bug.cgi?id=453452
This was posted on the 3rd. On the highly unlikely event that it was you that posted that bug, maybe you should give them more than 3 days to do something about it before bashing them on /.?
Also, I would categorize this as a low priority bug(OMFG? Pressing a button AN EXTRA COUPLE OF TIMES? You still alive?), so don't hold your breath.
It is also in the 1.8 branch..
You know one thing I find annoying?
Users that find bugs and never tell you about them.
Wow. Why aren't we in the US trying to do this? We used to be so worried about the Communists beating us. But now it's like we don't even care. Where's the fire?
"Now wait a minnit there, skeeter. Don't forget we got'em humvees and a mile is way longer than a kilometer."
I'll bite.
#1] What the fuck is NewsTrust?
1. A website. Sorry, you have to RTFA this time.
#2] Why the fuck should we care?
2. Since you have neither read the article or posted anything worth reading, I'd say that your post, or should I call it noise, is a perfect example of why we should.
You're welcome.
No, but the voices reassure me and tell me not to listen to you.
Since I used to work with 4D(http://www.4d.com/), the *easily* most insane development language/toolkit ever made, MY voices reassures me that it's OK not to.
I suffered no brain damage examining the code.
So you say...
The code looks to me like COBOL 85 and looks suspiciously like it might even be Wang VS COBOL 85.
I'd say it's because the damage was already done...and those dreams never really go away either, do they? :-)
Shouldn't they click "Launch"? Just pointing the thing isn't going to help them.
Yeah, I don't get it either.
I'd go even further and say that it would be bad for them.
I give up, you win.
* My god, you seem to be pissed off in general, or you deliberately misunderstood all points I tried to make.
* The RFC is only applicable to small systems. Obviously.
* Yep, DNS is technically a database, I know this since I am not a total moron. But that was not my point either. Most NOC-servers does not use DNS, but a specific database, to store system specific data, mostly for security, TTL, and availability/redundancy reasons(not all eggs in the same basket).
* A file server is a server that serves files, this might or might not include an FTP server. I wasn't pretending to come up with a perfect standard. I said rough, remember?
* In larger systems, you seldom, if ever, change the role of a server(during it's 3 year life span).
Especially with all the virtualisation going on, it is much easier to simply create a new one. But I would rename it, if that happened.
1 & 2. The limitations of theme-based naming schemes does not stem from the number of available names, but the fact that it is impossible to read any information from the name of a server called "FIDO". Hence, all new employees need to learn lots of wierd names.
3. No, numbers would not be OK, since you usually work with maybe 5-6 servers at a time. Once you figure it out, using ERDBDEV02 is waay better than constantly having to remember new variants of DODO, FIDO or SAURON.
Imagine this: A user calls, "my system says 'an error with the BILBO-server prevent the application from starting.'. What do I do?".
Now say you have hundreds of servers...well, yeah, you could have the BILBO server name in some support database, but since that is obviously not working right now due to some(maybe related) DNS issue, you don't know what it is. A good point is that BILBO is easier to spell over the phone than LSWIN03, but that point has nothing on the fact that you immediately know that it is logon server 3 that is failing.
That's just how it works for me. Or worked. I am not a sysadmin anymore, even though I do handle some servers for development purposes.
I have never seen a slashdot thread with as many serious, and disparate, replies before.
And the RFC(1178) that someone pointed at was, at it's best, unhelpful.
If there was a standard(Something for OpenISO, perhaps?) that everybody used, it would be great.
Then we would all only need to learn one standard. Which, I think, would feel more acceptable to most. And no, this is not about "freedom", it's about being pissed of twice a day because some bastard named a server after his old girlfriends dog.
Server names could also then be created automatically, using easy-to use GUI tools for the faint of heart, and also "decode" in the same way, making some level of rough categorization possible(i.e. "list all file servers").
You might argue that that kind of data should be stored in a database, and not in a server name. Then I ask you, why do server names exist at all, if not to define the server for it's users? Why not only use IP then?
Regarding the location of the server, however, I don't think that should be in the server name(i'd rather put that in the subdomain). I mean, a mail server running Linux will continue to do so even if it is moved to a new location.
And yeah, were I work we use abbreviations, which results in names like SRVAPPDEVVM03 (the VM-part, denoting a virtual machine, feels a bit unecessary nowadays, though). I wouldn't say I am particularly pleased with our way, but there is only so much time left to think about things, it seems. Using abbreviations are a complete necessity though.
But I have also been naming stuff after LOTR-caracters, Cartoon characters and whatever, too. That stopped working way back, when we passed the 20-server mark, though.
I agree totally.
Also, the customers aren't prepared to cough up what it takes to make the applications secure.
Some say this is a myth. I'd say that is not.
I have only met a few that even ask questions about application security.
We always try to sell security measures as a part of the solution. It is nearly impossible to make the customers understand without sounding paranoid and losing credibility.
And yes, I work a lot with banks and other similar entities which are supposed to have really high levels of security.
In some areas(that would be those where the government agencies are breathing down their necks), they are really good and and have enormously bureaucratic(verging on PIA) ways to handle that security.
But in almost ALL other areas of their application jungle, they aren't the least better, or even worse, than Joe's accounting down at the corner.
To end on a positive note, I did read a tender invite(i like it that way) for a new thing just the other day that explicitly excluded "office-like" products from being used in the solution.
Not that we neither would, or even could do that anyway, but maybe they are getting it, after all.
However, this is the first time i have ever seen this.
"I believe it's a well-known fact that the current mod system allows users to only have mod points XOR a clue.".
I am aware of that.
The grandparent was talking about rigor in general.
This applies to the ones writing the specifications as well.
I don't, so please, with sugar on top, enlighten me.
What the difference between two completely different expressions?
Because I think rigor can be applied to requirements as well.
I must be an ass.
That sounds like a severe case of nostalgia to me.
:-)
I don't think that these systems were made in a much more rigorous way than mission-critical systems are made today. Modern systems have so many more things they are expected to be able to perform, and are, in general, simply way more complex and way more layered.
Rather, the legacy systems were designed for very specific use cases and are, as a consequence, used in very specific ways. I mean, the banks I have worked with are probably among some of the most technologically backwards organizations I ever encountered.
Their systems are also usually used in a totally isolated environment, and this have been done in exactly the same way forever. So security updates are an issue either.
Since these system also haven't been developed further for a very long time, there has been no addition of code with potential bugs in it.
BUT, and this I would like to emphasize a bit, "legacy" systems typically aren't bug free at all.
Typically people have to employ numerous workarounds to deal with them. Many of these workarounds has then, over time, become the "truth".
Just one small example of a typical legacy system bug:
One summer, a long time ago, I was working at a company using a huge mainframe running a really old system.
I had a huge bug; If one of the warehouse workers, in any of their warehouses(distributed all over the country) entered an invalid article number, that session got into a endless loop and consumed almost all of the systems resources. We are talking hundreds of people over a wide area that could not carry out their work.
Now, it wasn't easy to even enter an invalid code, the system did *almost* not allow it.
However, codes read though a bar code reader could be invalid, and it that code could also be accidentally edited, circumventing any checks.
I have friends that have told me many a similar story over the years, so I am totally convinced that I am not the only one and this is not the only huge, critical AND buggy legacy system out there.
To the best of my knowledge and experience, most systems used for banking are positively riddled with old bugs and oversights.
Then, most systems are, of course
Is that image in actual size or what?
162*169?
Very strange indeed.
If you had actually bothered to check the link Well, i actually had, and whether they sign an NDA or not is not important, the driver itself will be open source and hopefully well commented, which is almost as good as having the documentation. Then, of course, it is a matter of trust, NDA or not. That's fine, but it doesn't make drivers magically appear out of thin air. They still have to be written. This is not a trivial task, especially when the specifications are not available. Yep, this is a problem. You are obviously right about that, since that's why we are having this discussion.
However, the problem will not be solved by bashing the manufacturers, but instead by trying to figure out why they don't take an offer that seems like money in the bank.
They would not take this stand without reasons to do it. And many of them are real-world and non-negotiable reasons, not just something they have to change their mind about.
But to find those reasons the community must try and see the problem from the manufacturers view, and realize that hardware development project has huge costs and dangers that are not the same as those in a commercial software development project. This makes hardware development a fundamentally different business from software development and requires a different mindset.
Adding to that, there are many academic types in FOSS that has never really worked much even in commercial *software* projects, where the rules and what one needs to take into consideration is different from the black- and white thinking of the academic world.
I disagree. Obviously :-)
These points was not meant to apply to the software(which was to be written by a OSS developer, remember?), but to general detailed information regarding the hardware. You can deduce lot's of things about it through there and making a good hardware interface is hard and a competitive edge, if well executed.
And as such, I believe they are perfectly valid.
An NDA is almost pointless since the driver itself, being open source and hopefully well commented, will reveal all the information needed. No one will need to ask it's developer. Also, it is likely that there will have to be many developers involved, which has to share information.
And with regards to no 7, it is my personal experience that most peoples' first impression of the OSS community as a bunch of over-idealistic leftie nerds.
First impressions last. And if the first impression isn't "business opportunity", it will last even longer.
If the stupid straight-out-of-win32-n00b user thinks it sucks, it sucks. Regardless.
The average user doesn't care. And you know what? He shouldn't have to either.
I am promoting Linux usage on all areas, but every time I read something like this, I feel strangely out of breath.
This kind of attitude is the exact reason why it has taken SO DAMN LONG for Linux to become a viable desktop solution. When you are done giving thanks, complain to your hardware manufacturer, who does make money from the deal, and does have the full specifications - AND for reasons unknown, have turned down the offer of OSS developers writing the drivers for them, for free
1. They are (rightfully) afraid that their competitors will steal their ideas. If they supply a binary driver this is not as likely but since the Linux(i.e. the OSS) world is demanding the source, they feel it isn't worth it, since....
2.
3.
4. They, in their turn, are licensing other companies things, and to release their source they must convince them as well..
5. Other companies use their technology through licenses, and does not want it to be released since THEIR competitors could use it.
6. Other agreements, for example with Microsoft, prevents them to.
7. It takes some time for some to understand that Open Source does not have to be communism. When RMS is on, it sounds a lot like it, you know.
This is just what i thought of from the top of my head, there are probably lots of other reasons. Many better than these, probably.
It annoys the hell out of me that people doesn't understand this, and the more the manufacturers hear people whine like this, the more amateurish the Linux world appears.
The second these companies owners feel that the financial return of entering the Linux world outperforms the risks(did I hear something about "people in parents basements"?) they will come.
So instead of badmouthing them, try to understand how they work and ease them in.
BTW, didn't mean to dismiss stored procedures totally(they still have some uses, however, the performance gained is just not very significant anymore and sometimes even a loss), was just thinking about when using them in ways that has to include the rest of the cluster.. Sorry 'bout that.