One further point: for most of the Postgres shell utilities (psql, pg_dump, etc) the default behavior is to try to connect using a Postgres username that is the same as your Unix login name. It is easy enough to override this --- you can specify the Postgres username to use on the command line, or set a PGUSER environment variable, for example --- but the path of least resistance is for local users to use Postgres usernames that match their Unix username. I do not really see what's wrong with that default. What other default would you want?
> Recovery tools for example as well as multiple user support keep mysql more popular among ISP's.
Would you rather have a recovery tool, or would you rather not need it?
The reason there is no pgsql-fsck is that there are no known predictable failure modes, accordingly no cases that can be fixed by a non-AI-complete piece of software. We prefer to spend our development time on getting rid of bugs than on developing workarounds for bugs.
As for multiuser, I really have no idea what you're talking about there --- Postgres has no problem supporting multiple users. Can you enlighten me on what MySQL does better in that area?
> After over 1.5 million files it starts taking minutes to insert each new file row.
INSERT in itself is basically a constant-time operation. You've got some problem somewhere else, but with this amount of detail it's impossible to help you fix it. (If I had to guess with no data I'd guess about an unindexable foreign-key reference, but that guess is worth what you paid for it.) If you'd like more help please feel free to post details about your problem on the pgsql-performance mail list.
> I see mysql fixing its flaws long before postgresql fixes its bottlenecks.
I'm constantly amazed at the number of MySQL apologists who think that MySQL will catch up while the Postgres team sits on its collective butt. Check out the release history of the two projects over the past five years, and then tell me which one is moving faster.
I just had it done and am glad to offer a data dump.
The short answer is that I agree with the other respondents about knowing what you expect to gain and what the risks are. You didn't tell us anything about your current eyesight so it's impossible to offer very constructive advice. But do not go to the lowest bidder --- it's your eyes we're talking about, so go to the best, most experienced surgeon you can find. (One mark of a competent surgeon is that he/she will turn down prospective patients who look like bad risks. Ask what his rejection ratio is.)
My situation was that I was about -5.5 diopters in the left eye (bad but not blind), -1 in the right (just a bit nearsighted), and had been doing fine with regular glasses for many years. But I'm getting to the age where I need bifocals (ugh) and my initial attempt to adapt to them failed completely. The range of angles where I could see clearly at a particular distance was too different between left and right eyes. Contacts would probably have worked, but I have always had this thing about putting things in my eyes, so I didn't want to go that way.
I went to the best surgeon in town, and what he recommended was to operate on only the left eye (I'd not have wished to risk both eyes anyway --- I read the same horror stories on the net as the rest of you) and furthermore *not* to try to bring the left eye to perfect, but to shoot for -1 diopter to align it with the right eye. This made sense to me in terms of wanting bifocals to work, and also he was very candid about pointing out that in case a followup treatment was needed, it would be easier to adjust closer to plano than further away; the surgery can't put back cornea that you've zapped.
BTW, two very crucial measurements that your surgeon should take before accepting you are cornea thickness (too thin means no margin for removal of tissue) and nighttime pupil diameter. The current lasers can only zap a region 8mm across, which is about the average diameter of a dilated pupil. If yours is much wider then you are very likely to have nighttime vision problems after surgery, because the light coming in through the uncorrected outer area will create ghosting, haze, etc. My pupil is right about 8mm and in every other way I was a perfect candidate for surgery.
I'm now about five weeks out from the surgery and I'm a very happy camper. The left eye is corrected to very nearly match the right from distance down to about two feet; and its former astigmatism is just about gone. I do notice some loss of contrast at night, but it's not bad, and I'm not sure I could even tell if I didn't have an unoperated eye to compare to.
Bottom line: understand what you're after, and go to the best doc you can find. Good luck!
Sperm, hell. Worry about what will happen when the FCC comes after you. Interfering with your neighbor's TV reception is not only illegal, but may be one of the few cardinal sins left in the US of A. And an unshielded modern machine *will* put out RF interference, big-time.
> Rather than just port to PostgreSQL, they want to do
Real time parsing Oracle DDL and DML statements and converting them to the target database.
Indeed. If this had read "... parsing SQL99 DDL and DML statements and converting them..." then I would be willing to buy into it. As is, they've made it perfectly clear that they think Oracle defines the standard. I'm not interested in playing that game.
The gripe about lack of nested transactions is a fair cop, but when you define acceptability as "whatever Oracle thinks" then you are clearly not really interested in an open solution.
Nah, you miss the point entirely. Judges are trained to rule as narrowly as possible. West found a way to avoid ruling on anything interesting, and he did so. That's what he was supposed to do, and he did it. Only the Supremes are allowed to do otherwise;-)
FWIW, I have been receiving 1000-1500 copies of Klez *per day* for the last couple of weeks. Before that it had been running in the low dozens per day for a couple of months. Klez is certainly the most successful virus I've ever seen.
I finally gave up and shut down the info address that was getting all the load; I couldn't spare the bandwidth to download a couple hundred MB of malware every day. So that's at least one small service that's gone under because of Klez. I hope the loser who wrote it is proud.
I wouldn't be adverse to some reverse censorship. i.e. no chinsese IP's allowed in my network.
Personally, I get so much Chinese (and also Korean) spam --- and essentially zero legit mail from either country --- that I use a dnsbl service
that blocks those entire countries (http://www.five-ten-sg.com/blackhole.php).
However, I can't help feeling that I'm playing into the hands of the Chinese censors by doing this. It doesn't take very much imagination to guess that the Chinese government would be perfectly happy if most of the world blocked email from China --- and not much more to wonder if they tacitly encourage spamming to help the cause along. Who needs anything so crude as an overt block, if you can get other people to do it for you?
Not that I'm going to stop blocking China. There is too friggin' much spam coming out of there.
The fact is guys, it's hard to support 50 new employees on a brand new, growing marketplace.
Indeed, this was Great Bridge's mistake: they staffed up before they understood the size of the market. A smaller company could have been profitable.
All assembly? You've got to be kidding
on
MenuetOS Debuts
·
· Score: 1
And the most important and notable feature? The whole OS was written in 100%, pure 32-bit x86 assembly code!
Hello? Writing the whole of anything in assembler was obsolete when I was an undergrad, nigh thirty years ago. You write it in a high level language first, and perhaps then you recode a very few percent in assembler for speed. Over the vast mass of the code for any significant system, you cannot beat a decent HLL for readability, debuggability, modifiability, and speed. The HLL compiler writer has blown it badly if you can sustain the same level of tenseness for every routine as the compiler will exhibit every time. For well-studied languages such as C, there is just not any question that you will lose. (John Henry, meet the steam hammer.)
This does not even begin to address the issue of portability. Hint: 32-bit Intel is not the universe; you've lost the interest of this reader already with that restriction.
... in a case like this, where both companies are pretty much equal,
That's only correct if your idea of "unequal" is Microsoft against JoeBob's Software and Caddy Shack. Nusphere is Progress Corp is several orders of magnitude bigger than MySQL AB.
I don't know quite what caused the falling out here, but if push comes to shove in court, I predict that Nusphere wins. They can spend more on lawyers than MySQL AB will ever make.
Disclaimer: I'm a PostgreSQL developer. I could be amused at this spectacle, if I didn't think it was giving all open source a bad name.
how come they don't use [Postgres]?
MySQL has good mind-share among webmasters, no doubt about it. My two cents about why: it reflects where things stood several years ago, when people first started setting up database-backed websites. At that time, Postgres had just been thrown over the wall from Berkeley as being not quite the cutting-edge research they wanted to do anymore. The current crowd of developers picked it up and started to turn it into a robust, production-grade system --- something it is looking more like all the time. But back then, it was a research system: it wasn't especially portable, nor especially easy to install, nor especially bug-free. Many early webmasters looked at it and couldn't get past those problems, for which I can't blame them a lot. Meanwhile, MySQL was a brand new system; not real featureful, maybe, but they'd done their homework on making it easy to install and use. So it got adopted by a lot of people. Now Postgres has to play catchup in the mindshare department, even though the problems that originally drove people away from it are largely history.
RedHat's adoption of Postgres may do something to help in acquiring mindshare...
I'd like if someone could help clarify what is exactly happenning though. Great Bridge employs half the Postgres developers.
Half the core committee, please, not half of the whole community. (BTW, I'm one of the half, so take my comments accordingly.)
They claim to have a "commercially QA-tested" version of Postgres -- what exactly is this?
What it says. Great Bridge tries to make sure that releases it packages are solid. Some Postgres releases are, um, not so solid, despite the best efforts of the community. GB adds another layer of testing and double-checking.
Does anyone have any more information either on what Great Bridge's or Red Hat's versions of PosgreSQL have over the normal releases?
I can't speak for RedHat, but Great Bridge's policy is to ship recognized Postgres releases. GB offers a nifty graphical installer (also open source, but it's not in the standard Postgres distribution), and the CD carries a number of related tools, but there's nothing there you couldn't get off the net. What GB adds is knowing what you want and which releases you want of it.
Based on RedHat's past track record, I expect that they're going to do largely the same sort of things with Postgres as GB is doing: ship releases they believe are good, along with selected tools that complement it. This will be competition for Great Bridge, no doubt about it. But I'm not in fear of being on the street soon. As database specialists, GB should be able to continue to win customers over RedHat's generalism. Besides, RedHat choosing Postgres increases the credibility of the project all round, and should increase the size of the customer pool that we will all be splashing in. I'm optimistic that it's a win-win situation.
I don't believe that RedHat has any desire to fork the code --- have they forked Linux? gcc? gdb? a bunch of other stuff that they contribute work to? No, they'll contribute to the project and package releases, same as they do with those projects. I've already met with some of their developers who will be contributing, so I know this is real. This should be good all around.
However, feel free to flame their apparent intention to plaster their own name on an open-source project that's been around considerably longer than RedHat itself has. That bit sticks in my craw, too. I've got to suppose that that's the brainchild of some clue-free marketroid.
Come now. You think the Postgres community is going to lie down and do nothing while MySQL catches up? Postgres has been improving at a very substantial rate over the past couple of years. That's not going to stop --- in fact, with RedHat contributing a number of full-time developers, the rate of improvement should be even better in future. Catch us if you can.
Slashdot Mirror
One further point: for most of the Postgres shell utilities (psql, pg_dump, etc) the default behavior is to try to connect using a Postgres username that is the same as your Unix login name. It is easy enough to override this --- you can specify the Postgres username to use on the command line, or set a PGUSER environment variable, for example --- but the path of least resistance is for local users to use Postgres usernames that match their Unix username. I do not really see what's wrong with that default. What other default would you want?
> Recovery tools for example as well as multiple user support keep mysql more popular among ISP's.
Would you rather have a recovery tool, or would you rather not need it?
The reason there is no pgsql-fsck is that there are no known predictable failure modes, accordingly no cases that can be fixed by a non-AI-complete piece of software. We prefer to spend our development time on getting rid of bugs than on developing workarounds for bugs.
As for multiuser, I really have no idea what you're talking about there --- Postgres has no problem supporting multiple users. Can you enlighten me on what MySQL does better in that area?
> After over 1.5 million files it starts taking minutes to insert each new file row.
INSERT in itself is basically a constant-time operation. You've got some problem somewhere else, but with this amount of detail it's impossible to help you fix it. (If I had to guess with no data I'd guess about an unindexable foreign-key reference, but that guess is worth what you paid for it.) If you'd like more help please feel free to post details about your problem on the pgsql-performance mail list.
> I see mysql fixing its flaws long before postgresql fixes its bottlenecks.
I'm constantly amazed at the number of MySQL apologists who think that MySQL will catch up while the Postgres team sits on its collective butt. Check out the release history of the two projects over the past five years, and then tell me which one is moving faster.
I just had it done and am glad to offer a data dump.
The short answer is that I agree with the other respondents about knowing what you expect to gain and what the risks are. You didn't tell us anything about your current eyesight so it's impossible to offer very constructive advice. But do not go to the lowest bidder --- it's your eyes we're talking about, so go to the best, most experienced surgeon you can find. (One mark of a competent surgeon is that he/she will turn down prospective patients who look like bad risks. Ask what his rejection ratio is.)
My situation was that I was about -5.5 diopters in the left eye (bad but not blind), -1 in the right (just a bit nearsighted), and had been doing fine with regular glasses for many years. But I'm getting to the age where I need bifocals (ugh) and my initial attempt to adapt to them failed completely. The range of angles where I could see clearly at a particular distance was too different between left and right eyes. Contacts would probably have worked, but I have always had this thing about putting things in my eyes, so I didn't want to go that way.
I went to the best surgeon in town, and what he recommended was to operate on only the left eye (I'd not have wished to risk both eyes anyway --- I read the same horror stories on the net as the rest of you) and furthermore *not* to try to bring the left eye to perfect, but to shoot for -1 diopter to align it with the right eye. This made sense to me in terms of wanting bifocals to work, and also he was very candid about pointing out that in case a followup treatment was needed, it would be easier to adjust closer to plano than further away; the surgery can't put back cornea that you've zapped.
BTW, two very crucial measurements that your surgeon should take before accepting you are cornea thickness (too thin means no margin for removal of tissue) and nighttime pupil diameter. The current lasers can only zap a region 8mm across, which is about the average diameter of a dilated pupil. If yours is much wider then you are very likely to have nighttime vision problems after surgery, because the light coming in through the uncorrected outer area will create ghosting, haze, etc. My pupil is right about 8mm and in every other way I was a perfect candidate for surgery.
I'm now about five weeks out from the surgery and I'm a very happy camper. The left eye is corrected to very nearly match the right from distance down to about two feet; and its former astigmatism is just about gone. I do notice some loss of contrast at night, but it's not bad, and I'm not sure I could even tell if I didn't have an unoperated eye to compare to.
Bottom line: understand what you're after, and go to the best doc you can find. Good luck!
Sperm, hell. Worry about what will happen when the FCC comes after you. Interfering with your neighbor's TV reception is not only illegal, but may be one of the few cardinal sins left in the US of A. And an unshielded modern machine *will* put out RF interference, big-time.
"today's announced Postgres security issues" ?
All of those were known and fixed quite some time ago. Three out of the four you quote were fixed in PG 7.2.1, more than a year and a half old.
Better go find a fresher news feed, troll.
> Rather than just port to PostgreSQL, they want to do
..." then I would be willing to buy into it. As is, they've made it perfectly clear that they think Oracle defines the standard. I'm not interested in playing that game.
Real time parsing Oracle DDL and DML statements and converting them to the target database.
Indeed. If this had read "... parsing SQL99 DDL and DML statements and converting them
The gripe about lack of nested transactions is a fair cop, but when you define acceptability as "whatever Oracle thinks" then you are clearly not really interested in an open solution.
regards, tom lane
PostgreSQL core committee
Nah, you miss the point entirely. Judges are trained to rule as narrowly as possible. West found a way to avoid ruling on anything interesting, and he did so. That's what he was supposed to do, and he did it. Only the Supremes are allowed to do otherwise ;-)
FWIW, I have been receiving 1000-1500 copies of Klez *per day* for the last couple of weeks. Before that it had been running in the low dozens per day for a couple of months. Klez is certainly the most successful virus I've ever seen.
I finally gave up and shut down the info address that was getting all the load; I couldn't spare the bandwidth to download a couple hundred MB of malware every day. So that's at least one small service that's gone under because of Klez. I hope the loser who wrote it is proud.
Personally, I get so much Chinese (and also Korean) spam --- and essentially zero legit mail from either country --- that I use a dnsbl service that blocks those entire countries (http://www.five-ten-sg.com/blackhole.php).
However, I can't help feeling that I'm playing into the hands of the Chinese censors by doing this. It doesn't take very much imagination to guess that the Chinese government would be perfectly happy if most of the world blocked email from China --- and not much more to wonder if they tacitly encourage spamming to help the cause along. Who needs anything so crude as an overt block, if you can get other people to do it for you?
Not that I'm going to stop blocking China. There is too friggin' much spam coming out of there.
Indeed, this was Great Bridge's mistake: they staffed up before they understood the size of the market. A smaller company could have been profitable.
And the most important and notable feature? The whole OS was written in 100%, pure 32-bit x86 assembly code!
Hello? Writing the whole of anything in assembler was obsolete when I was an undergrad, nigh thirty years ago. You write it in a high level language first, and perhaps then you recode a very few percent in assembler for speed. Over the vast mass of the code for any significant system, you cannot beat a decent HLL for readability, debuggability, modifiability, and speed. The HLL compiler writer has blown it badly if you can sustain the same level of tenseness for every routine as the compiler will exhibit every time. For well-studied languages such as C, there is just not any question that you will lose. (John Henry, meet the steam hammer.)
This does not even begin to address the issue of portability. Hint: 32-bit Intel is not the universe; you've lost the interest of this reader already with that restriction.
That's only correct if your idea of "unequal" is Microsoft against JoeBob's Software and Caddy Shack. Nusphere is Progress Corp is several orders of magnitude bigger than MySQL AB.
I don't know quite what caused the falling out here, but if push comes to shove in court, I predict that Nusphere wins. They can spend more on lawyers than MySQL AB will ever make.
Disclaimer: I'm a PostgreSQL developer. I could be amused at this spectacle, if I didn't think it was giving all open source a bad name.
how come they don't use [Postgres]?
MySQL has good mind-share among webmasters, no doubt about it. My two cents about why: it reflects where things stood several years ago, when people first started setting up database-backed websites. At that time, Postgres had just been thrown over the wall from Berkeley as being not quite the cutting-edge research they wanted to do anymore. The current crowd of developers picked it up and started to turn it into a robust, production-grade system --- something it is looking more like all the time. But back then, it was a research system: it wasn't especially portable, nor especially easy to install, nor especially bug-free. Many early webmasters looked at it and couldn't get past those problems, for which I can't blame them a lot. Meanwhile, MySQL was a brand new system; not real featureful, maybe, but they'd done their homework on making it easy to install and use. So it got adopted by a lot of people. Now Postgres has to play catchup in the mindshare department, even though the problems that originally drove people away from it are largely history.
RedHat's adoption of Postgres may do something to help in acquiring mindshare...
I'd like if someone could help clarify what is exactly happenning though. Great Bridge employs half the Postgres developers.
Half the core committee, please, not half of the whole community. (BTW, I'm one of the half, so take my comments accordingly.)
They claim to have a "commercially QA-tested" version of Postgres -- what exactly is this?
What it says. Great Bridge tries to make sure that releases it packages are solid. Some Postgres releases are, um, not so solid, despite the best efforts of the community. GB adds another layer of testing and double-checking.
Does anyone have any more information either on what Great Bridge's or Red Hat's versions of PosgreSQL have over the normal releases?
I can't speak for RedHat, but Great Bridge's policy is to ship recognized Postgres releases. GB offers a nifty graphical installer (also open source, but it's not in the standard Postgres distribution), and the CD carries a number of related tools, but there's nothing there you couldn't get off the net. What GB adds is knowing what you want and which releases you want of it.
Based on RedHat's past track record, I expect that they're going to do largely the same sort of things with Postgres as GB is doing: ship releases they believe are good, along with selected tools that complement it. This will be competition for Great Bridge, no doubt about it. But I'm not in fear of being on the street soon. As database specialists, GB should be able to continue to win customers over RedHat's generalism. Besides, RedHat choosing Postgres increases the credibility of the project all round, and should increase the size of the customer pool that we will all be splashing in. I'm optimistic that it's a win-win situation.
I don't believe that RedHat has any desire to fork the code --- have they forked Linux? gcc? gdb? a bunch of other stuff that they contribute work to? No, they'll contribute to the project and package releases, same as they do with those projects. I've already met with some of their developers who will be contributing, so I know this is real. This should be good all around.
However, feel free to flame their apparent intention to plaster their own name on an open-source project that's been around considerably longer than RedHat itself has. That bit sticks in my craw, too. I've got to suppose that that's the brainchild of some clue-free marketroid.
Come now. You think the Postgres community is going to lie down and do nothing while MySQL catches up? Postgres has been improving at a very substantial rate over the past couple of years. That's not going to stop --- in fact, with RedHat contributing a number of full-time developers, the rate of improvement should be even better in future. Catch us if you can.