Sun Eyes PostgreSQL

Da Massive writes "Sun is looking seriously into the database market - namely PostgreSQL. It says Oracle and IBM and even Microsoft licensing fees are way too expensive for the average punter. This from John Loiacono, executive vice president of software: "We're not going to OEM Microsoft but we are looking at PostgreSQL right now," he said, adding that over time the database will become integrated into the operating system."

Comments

I doubt it

[FortKnox]

It says Oracle and IBM and even Microsoft licensing fees are way too expensive for the average punter.

An NFL punter usually makes between $250k to $1M a year. They can handle most DB costs...

Re:I doubt it

[Anonymous Coward]

An NFL punter usually makes between $250k to $1M a year. They can handle most DB costs..

No, they can't. That is the problem...

Re:I doubt it

[stinerman]

Does anyone know the usage of the word "punter" in the article, though? I've heard the root word "punt" in several different ways in the last year or so when I had only heard it in the American Football context.

Re:I doubt it

[D'Sphitz]

Well they did say the average punter, not the average NFL punter. Even though NFL punters make a lot of money, all other punters (college, high school, little league) make nothing. There are hundreds of thousands of non-NFL punters vs. a couple hundred NFL punters at the most, so that would effectively bring the average very low, well below poverty levels.

Re:I doubt it

[iBod]

A 'punter' is common British slang for 'your average joe'.

Also used to mean a gambler or a prostitues client!

Re:I doubt it

[dtfinch]

The average football punter isn't in the NFL.

Re:I doubt it

[Dun Malg]

Does anyone know the usage of the word "punter" in the article, though?

It's a British-ism meaning about the same as "bloke", only it can apply to men or women. Tends to have shades of "lowest common denominator" to it, meaning something like "an ordinary slob off the street picked at random".

Re:I doubt it

[I confirm I'm not a]

It's a British-ism meaning about the same as "bloke", only it can apply to men or women.

I've mostly heard it used/used it myself to describe "customers", particularly gamblers. As in "I had a punt on that nag but lost my shirt". I believe politicians use it to describe their electorate, but I couldn't possibly comment.

Disclaimer: I've only heard the term used in Scotland; it's usage elsewhere in Britain may be more/less general.

Re:I doubt it

[bugmonkey]

"Punter" is slang for a gambler, sometimes used when talking about a customer.

Re:I doubt it

[gowen]

It's a British-ism meaning about the same as "bloke"

More usually, it means "someone who is in interested in buying something". It's most frequently used with respect to gamblers (particularly occasional horse-racing gamblers), since "having a punt" means "taking a gamble." It also means "people who frequent prostitutes", thus PunterNet, the leading online guide to "facilitate the exchange of information on prostitution in the UK"

Re:I doubt it

[Itchy Rich]

I've mostly heard it used/used it myself to describe "customers", particularly gamblers.

Exactly. It means customer, not 'bloke' or 'average joe'. Since it's a slang word you'll only hear it being used colloquially, usually in terms of gambling, market stalls, bars, clubs, brothels, etc.

Re:I doubt it

[Doctor Memory]

It's British for "Joe Six-Pack"

Re:I doubt it

[iabervon]

Punting costs £14-16 per hour, which is a lot less than a database. Of course, I've got no idea what you'd use a database for while poling a boat around the river Cam.

Re:I doubt it

[nelsonal]

In this context punter is a buyer with shades of uninformed buyer. The term comes from the race tracks where betters became known as punters, and has evolved to refer to more uninformed buyers of especially tech and financial products.

Re:I doubt it

[Alejo]

Dude , I have no idea.

Re:I doubt it

[Itchy Rich]

maybe these brits should go back to boiling every piece of food to death, instead of using stupid words on slashdot.

How are we supposed to know which words you understand? Are we psychic? Sure I know a few words like 'pants' that cause confusion, but to expect people to translate for you is just childish.

As for the food 'quip', how about four out of the top ten restaurants in the world being in Britain, compared to two in the USA.

Re:I doubt it

[Skjellifetti]

As for the food 'quip', how about four out of the top ten restaurants in the world being in Britain.

How many of 'em actually serve native British food?

Re:I doubt it

[david duncan scott]

Since you're unfamiliar with the term, you must be unfamiliar with The Register. The BOFH alone is worth the price of admission.

Re:I doubt it

[Anonymous Coward]

Isn't a prostitute's client called a "john" or "trick"?
I know some people get confused and call the "ho" the "trick", thanks to the ill informed rappers claiming that "biatches aint nothin but hos and tricks"

Re:I doubt it

[Anonymous Coward]

How many american resturants serve native American food? Hmmm? Thought so.

Re:I doubt it

[Itchy Rich]

How many american resturants serve native American food? Hmmm? Thought so.

Good point well made.

Re:I doubt it

[david.gilbert]

punter? what the hell? maybe these brits should go back to boiling every piece of food to death, instead of using stupid words on slashdot.

Yeah, over here we use words in funny ways. Speaking of which, perhaps you could explain the term "World Series" to me...

Re:I doubt it

[Rucker]

Hah. I don't know anything about British cuisine or restaurants, so I can't comment on them. However, I would like to point out that your "top ten restaurants in the world" list was compiled and published by a British magazine. I presume your intent in quoting this list was to dispell rumors that all food in Britain is bad, and not to prove that British restaurants are superior, so I'll forgive you. :)

Re:I doubt it

[tolan-b]

pray tell, what's native american food?

Re:I doubt it

[Rucker]

Obviously we're talking about cuisine originating from a country and not cuisine created by the original inhabitants of a country. I know that's silly to point out, but I'm afraid someone might make that mistake. Quite a few American restaurants serve American cuisine actually. In case you're wondering what American cuisine includes, there is a wikipedia article: http://en.wikipedia.org/wiki/American_cuisine.

Re:I doubt it

[BestNicksRTaken]

Well you Yankies are the ones who are SUPPOSED to be speaking English!

And as for the food - would you prefer we broiled it or BBQ'd it to death?

Re:I doubt it

[errxn]

It's this thing that some asshat named George Steinbrenner keeps trying to buy every year. Luckily, he fails more often than he succeeds.

Re:I doubt it

[Skjellifetti]

How many american resturants serve native American food? Hmmm? Thought so.

You likely thought wrong. There are many cooking styles developed in America (often derived from or blends of imported cuisines) and large numbers of chefs and restaurants who specialize in those styles. You obviously don't get the Food Network where you live.

Re:I doubt it

[fanfriggintastic]

That's 3 in America, actually. Two in NY, one in California.

Re:I doubt it

[mOdQuArK!]

And as for the food - would you prefer we broiled it or BBQ'd it to death?

Mmmmmm...carcinogens...

Re:I doubt it

[Donny Smith]

Riiight.

How do you explain the existence of Oracle, then?

Re:I doubt it

[cayenne8]

" That's 3 in America, actually. Two in NY, one in California."

I can only assume this list was made AFTER New Orleans was temporarily knocked out by the recent weather incident...

:-)

Hard to beat the food down here....AND can be had at a reasonable price. Can't wait till they all start opening again...YUM!!

Re:I doubt it

[budgenator]

I guess that's why we are two peoples seperated by a common language. Of course you'd think that after years of BOFH, Money Python and Benny Hill we'd get the hang of the language.

Re:I doubt it

[multipartmixed]

Warez.

Try pricing out oracle for a mid-high-end Sun system with eight CPUs.

You'll shit your pants.

Re:I doubt it

[jedidiah]

Sure they can. Even the clustered version of Oracle is actually relatively cheap if you don't need any big-db options like partitioning. Anyone that would be even remotely interested in postgres can get oracle for less than a grand. The features that drive up the price of Oracle don't exist in postgres.

Re:I doubt it

[jedidiah]

Most people here would shit their pants just pricing the V880 but itself.

Re:I doubt it

[Skjellifetti]

I'll have to offer an a retraction of my earlier comment. Coincidentally, the New York Times has an article on finding good native British food in London's restaurant scene.

Re:I doubt it

[Guy LeDouche]

Hell, I tend to shit my pants just for the hell of it. Too lazy to get up since there is always something obviously important to finish at the computer, such as this post. There goes another loaf.

Re:I doubt it

[burgess]

How about: don't you amerikans speak ENGLISH? Why don't you think up your own language if you don't like the one your parents/founding fools taught you?

Re:I doubt it

[StrawberryFrog]

Genrally it means "a paying customer", as in "give the punters what they want". It can mean a member of the public, as in "he's not on shop staff, so he must be a punter".

Originally it was betting slang - the people who bet money were the punters.

Re:I doubt it

[cygnus]

As for the food 'quip', how about four out of the top ten restaurants in the world being in Britain, compared to two in the USA.

five words for you: Emulsified High-Fat Offal Tube. :)

Re:I doubt it

[Phil06]

Douché

Re:I doubt it

[drsmithy]

Does anyone know the usage of the word "punter" in the article, though? I've heard the root word "punt" in several different ways in the last year or so when I had only heard it in the American Football context.

In English slang, "to take a punt" means "to take a bet (or chance)". So a "punter" is the person taking the chance. In the context of talking about buying stuff, it would identify the customer (since they're the one taking the chance).

That's the original meaning, anyway. It's often used just to indicate "the average Joe".

It's pretty common slang in the (native) English speaking world outside of the US, particularly amongst older people.

Re:I doubt it

[Curtman]

"How many american resturants serve native American food?"

That's because they killed most of the native Americans down south using biological warfare. Cross the border in to Canada, and you'll find plenty.

Re:I doubt it

[Shanep]

Hell, I tend to shit my pants just for the hell of it. Too lazy to get up since there is always something obviously important to finish at the computer, such as this post. There goes another loaf.

I have not gotten to that stage yet. I am at the "piss in a bottle next to my computer because online Battlefield 2 games don't give enough time between maps and I don't want to get switched to the other bloody side again because I was inactive for 5 seconds" stage.

Re:I doubt it

[Shanep]

Exactly. It means customer, not 'bloke' or 'average joe'.

In Australia, it is used to refer to gamblers and also the "average joe".

Re:I doubt it

[htd2]

The Fat Duck at Bray, which is according to the survey the worlds best eatery serves food which would defy being pidgeonholed into a national stereotype. Try snail porridge as an example.

Re:I doubt it

[The Matrix Has Me]

how about four out of the top ten restaurants in the world being in Britain, compared to two in the USA.

Well, obviously. They're needed more desperately in Britain.

Predictable

[AKAImBatman]

This really isn't a surprise. MySQL has both licensing problems, and feature problems in the competitive high-end markets. PostGreSQL has none of these issues, and can hold its own in a comparison with Oracle or SQL Server. These features led RedHat to PostgreSQL for their RedHat Database product, and I see little reason why they wouldn't attract Sun as well.

The only thing that slightly bothers me about their strategy is that Sun has been pushing their Java Systems hard. If they actually wanted to bolster that strategy, they'd have three major options for a Java Enterprise Database:

1. Cloudscape/Derby - This product makes the most sense from a technology and licensing perspective, but the fact that it was an IBM product (even though Cloudscape was originally a separate entity before being acquired) taints the software in such a way as to make Sun look bad if they used it.

2. Daffodil - This database is an excellent choice, but it would require the acquisition of another company, a move that the Sun shareholders might question. It would also bring quite a bit of flak in Sun's direction as Daffodil is an Indian company.

3. McKoi SQL - An excellent choice for a Java database, but lacks brand recognition. The feature levels and scalability of the database are still considerable questions. The GPL license also allows Sun less freedom to modify the database in comparison to the BSD license used by PostgreSQL.

As for the choice of Sunbird, I think it's simply a matter of "why not?" It's not like there's any particular leader in the market, and Sunbird plays nice with Firebird/Mozilla.

Re:Predictable

[uits]

None of those are even close to Postgresql in terms of features, speed, and extendability. Not to mention, none are BSD, and none have a large user base. It would be foolish to pick one just because it's java.

Re:Predictable

[MeauxToo]

1. Cloudscape/Derby - This product makes the most sense from a technology and licensing perspective, but the fact that it was an IBM product (even though Cloudscape was originally a separate entity before being acquired) taints the software in such a way as to make Sun look bad if they used it.

Derby is intended to be an embedded database, not a database server. Yes, they have a server mode, but can't hold a candle to MySQL, let alone, PostgreSQL.

3. McKoi SQL - An excellent choice for a Java database, but lacks brand recognition. The feature levels and scalability of the database are still considerable questions. The GPL license also allows Sun less freedom to modify the database in comparison to the BSD license used by PostgreSQL.

Since when can't you modify the source of a product with a BSD-based license? A BSD-based license is, in fact, far more liberal than the GPL because you can take the code, modify it, and close the source of the result. A perfect example is the Windows NT/XP TCP/IP stack -- stolen straight from BSD, and last I checked, Windows is not open source. In contrast to the GPL, where you have distribute any modifications you make and open-source any parts of your products that link to it. Hence, the description of the license as viral.

Speaking from experience, PostgreSQL is a grat product. Stable, reliable, and reasonably fast for medium to large scale, multi-user, distributed environments. The products listed above are all embedded databases intended for single user, micro environments. You are, in short, comparing apples to oranges.

Re:Predictable

[Doctor Memory]

I might also suggest Firebird, the open-source version of Borland's InterBase product. It's licensed under a variant of the Mozilla Public License called the "InterBase Public License", but it doesn't seem too onerous. It's still a young product, but it looks like a good base, and I'm sure with a little spit and polish from Sun it could be a decent system.

There's also PostgreSQL's estranged mother, CA Ingres, the commercial version of Stonebreaker's original University Ingres. This is a well-vetted commercial-grade DBMS, although under another odd-wad license (the "Computer Associates Trusted Open Source License v1.1", see here).

That said, I would prefer to see them choose PostgreSQL.

Re:Predictable

[AKAImBatman]

Since when can't you modify the source of a product with a BSD-based license?

If you could be so kind, could you clarify what you are referring to? I believe I said that "the GPL license allows Sun less freedom to modify the database in comparison to the BSD license used by PostgreSQL." I'm not certain where your vehemence is targetted.

Re:Predictable

[hey!]

PostGreSQL has none of these issues, and can hold its own in a comparison with Oracle or SQL Server.

Depends, you can't exactly put a product like a RDBMS on a single scale. But in general it makes some sense to compare Postgres to SQL Server, but very little sense to compare either of those products with Oracle; although the limited attention span of most "decision makers" means that in practice the marketing departments of MS and Oracle play that game.

Oracle really really wants people to use Oracle for everything, and in truth you can use it for a lot of day to day database tasks, in the way you could use an eighteen wheeler to take your kids to soccer practice. Oracle's not very standards compatible. There's a million ways it traps you into their product. There's endless ways to shoot yourself in the foot, and getting things back requires a kind of black sorcery. In short, Oracle really sucks, unless it's the only tool that can do the job; in which case it's wonderful. Oracle's built so you can perform heart surgery on the patient while he's running a marathon, for the kind of applications where serious money is lost every time the database hiccups; the kind of applications where you have a team of DBAs who are paid six figures and it's a bargain.

SQL Server, to my mind, is mediocre. It's the choice of the departments who believe thing are easier if everthing comes from one vendor, and it's good enough to keep them out of too much trouble much of the time. From a DBA's standpoint I'd guess it's very easy to administer up to the point it becomes useless; if you never get there, you're happy. From a app develper's standpoint, it's pretty dreadful, but these days the style is to put as much as you can in the app tier so that doesn't matter much as it used to.

Don't know much about Postgres in production environemnts. It seems clean and I like the fact you have a choice of stored procedure languages.

Re:Predictable

[hey hey hey]

There's also PostgreSQL's estranged mother

More like estranged cousin. The commercial version split off from the University version long before PostgresSQL.

Re:Predictable

[RAMMS EIN]

``It would be foolish to pick one just because it's java.''

That hasn't stopped people before. /me ducks

Re:Predictable

[DrSkwid]

I don't know *anything* about those other products, but it strikes me that Postgresql could without too much effort have Java as a stored procedure language.

Indeed, someone has already started it http://plj.codehaus.org/

Re:Predictable

[Anonymous Coward]

A perfect example is the Windows NT/XP TCP/IP stack -- stolen straight from BSD, and last I checked, Windows is not open source

So then you have access to the NT kernel source, know that the complete stack is nothing but BSD, your boss has reminded you that said kernel source is not open and yet you post on slashdot. Interesting...

Re:Predictable

[david duncan scott]

A perfect example is the Windows NT/XP TCP/IP stack -- stolen straight from BSD

Smile when you say that, pardner!

"Stolen?" No, used legitimately. In fact, as I recall, you used to be able to look at the WinNT ftp client and read the credits to UC Berkely, which aren't even required any more.

"Stolen" just undermines your point that the BSD license allows -- hell, encourages -- this sort of use.

Of course, I think you misread the post to which you were replying, because that poster agreed with you that the GPL includes restrictions absent from BSD.

I'd also check again with regard to XP. I think the Redmond boys may have rewritten that stack by now.

Re:Predictable

[Michalson]

Yes, they have a server mode, but can't hold a candle to MySQL

Please, I think we all appreciate input and honest criticisms good or bad, but there is no reason for you to go out your way to insult the nice folks behind Cloudscape/Derby with that kind of statement.

Re:Predictable

[Saanvik]

Yes, Oracle wants you to use their database product for all of your data. Nothing wrong with that, that's their business.

Regarding usefulness for small projects - 5 years ago I would have agreed with you. Now, though, Oracle is very easy to setup and maintain even for small installs, and yes, I think MySQL had something to do with that.

The traps they have, though, in my experience, aren't really related to standards so much as to areas where no real standards exist. For example, there is a standard SQL, but nearly everyone recognizes that it needs to be extended to do real work. Oracle extended it in their own way, and yes, you can get trapped if you take advantage of it.

I agree, though, that a more realistic comparison is SQL*Server and PostgreSQL. Both could be used for high-end database solutions, but you'd have to defend your decision to use them instead of using Oracle or DB2.

Re:Predictable

[buddha42]

These features led RedHat to PostgreSQL for their RedHat Database [redhat.com] product

FYI, RHDB is an almost completely abandoned project. The documentation you linked to was last updated in 2002. Redhat doesn't even use it in their own RHN proxy satellite server (they use oracle). Its also not mentioned on their "Solutions" page at all: http://www.redhat.com/solutions/

Re:Predictable

[petermgreen]

i think given the oracle comments he means its very easy for small projects but becomes useless once the system passes a certain scale.

Re:Predictable

[hey!]

what does this even mean?
"very easy to administer up to the point of being useless"?

In the same way a car with no steering wheel is very easy to drive up to the point of you having to make a turn. SQL Server's very easy to administer because it only gives you control over the most rudimentary aspects of the database physical design, e.g. creating B+ tree indexes, moving entire tables between databases etc. If this is the limit of the kind of adminsitration you do, then you really can't find an easier to manage product.

i'm no big fan of Microshaft, but it's the choice of people who want to quickly deploy a reasonably scalable RDBMS that has excellent administration tools and is not super expensive... i'm not sure where the conception came from that's "in your mind".


It comes from making feature to feature comparisons. First, let's be clear: excepting their horrible SQL implemntation, I never said SQL Server is bad -- just mediocre. Mediocre (but good enough), cheap, and easy to convince the boss to use constitute and excellent decision in many instances. Whether it is the best choice for you depends on your definition of "resaonably scalable". The admin tools are very polished I grant you. Within the scope of what they do they can be called "excellent". But as excellent as they may be, if you need to do something that the underlying platform cannot do, it doesn't matter. If don't it does.

Re:Predictable

[robertjw]

My experience with SQL Server is much different. I've used MySQL for several years for small projects. Recently had a client that had another developer create a database on SQL Server. I spent hours looking for documentation on simple things like backup and restore. Took me days to get the backup restored to the hosting account I setup. After everything was restored, couldn't get the stupid .Net app running. Had to get the original developer to make it work.

I have had little experience with SQL Server and .Net, so some of the problems I had were definitely my fault. OTOH, I can go to google and type in 'MySQL backup' and get hundreds of pages, scripts and information on backing up and restoring. I searched for hours trying to figure out how to restore a SQL Server backup and finally determined that I could only restore by installing one table at a time.

Re:Predictable

[Pfhreakaz0id]

what? Look, there are LEGITIMATE gripes against Microsoft's practices, but documentation simply isn't one of them. I'm assuming you have the sql client installed in your local machine? (why wouldn't you, but if not, fine, remote desktop to the server). Start -Programs -SQL Server - books online is your gateway too the entire set of sql server documentation. Locally, on your hard drive. on the index is "administering sql server", expand, there's a whole chapter on backing up and restoring databases. Incidentally, if you can't figure out it's under "administering.." you can go to index and type "backup" Or go to msdn.microsoft.com, search sql server 2000 backup (I took the liberty of assuming a version) and select the 2nd hit "http://msdn.microsoft.com/library/default.asp?url =/library/en-us/architec/8_ar_aa_9iw5.asp" for "backup and restore architecture".

For that matter, there is a TON of sql server articles/resources online. I see no qualitative results in the first few hits to a google search for "mysql backup" and "sql server 2000 backup"

FYI: I know from personal experience you don't have to restore a backup one table at a time. Backup and restore of entire database (or several databases) is a simple, point and click, follow the wizard set of dialog boxes. (although you can script it if you wish).

Re:Predictable

[glarvat]

It's been my experience that Oracle not only wants you to use their database for ALL your databasing tasks, but their products for all your tasks. Their database is quite good, IMO not appropriate for everything, but still good. I have no problems with their database. My problems are with their other products. The have certainly taken Microsoft's "embrace and extend" to "embrace, extend, and crapify." My direct experience with this were three products: their application server, their portal, and their IDE. I happily have not used any in the last 14 months, so they might have gotten better, but I doubt it. Their app server is an extension of Orion, though slower, less stable, out of date, and harder to configure. Same thing with their IDE, just substitute JBuilder for Orion. Though from what I've heard from my old collegues, their portal is actually making progress, it's still a pain in the arse. But management thinks, "It's got Oracle on the box, it must be good."

I really fear what's going to happen when the PeopleSoft merger is completed. I hope they don't crapify it too.

Re:Predictable

[robertjw]

Hmm... now you are taxing my memory. It's been a few months and I've tried to block the whole evil mess from my mind.

I know from personal experience you don't have to restore a backup one table at a time. Backup and restore of entire database (or several databases) is a simple, point and click, follow the wizard set of dialog boxes. (although you can script it if you wish). Correct me if I'm wrong, but this is if you are using the sql client. My hosting service would not allow a remote connection to the server from a client on my machine, thus negating the ability to use a point and click method, at least afaik. I had to use the hosting services interface, and it sucked. I'll admit, it was my fault for going with the cheapest host I could find, godaddy, but I never imagined I'd have the difficulties I did. I've never seen a MySQL interface that didn't allow a restoration of the backups and even if there was one you can generally telnet to the admin port and read the files in manually.

My gripe wasn't against Microsoft's documentation. I wouldn't say it's one of their strong points, it usually sucks to read, but they do generate a TON of it. If you can extract the actual information from the marketing speak it's usually there. As for the lack of qualitative results in a google search, the first two entries for "mysql backup" give instructions on backing up and restoring a database in plain english. There are almost twice as many google results as there are for "sql server 2000 backup", not that it really matters when you are talking about millions of entries.

My real complaint was that the whole thing was much more difficult than I had anticipated. I'm used to php and MySQL, if I get an error message I run a google search and get an answer. I've learned everything I know about those two products from websites and newsgroups. I've also used the cheapest hosts available and had great success. My one attempt at using SQL Server was a nightmare. If I had my own server running a local client and had control of everything I'm sure it would have been much easier, but with a remote hosting services restrictions it was a very unpleasant experience.

Re:Predictable

[Pfhreakaz0id]

yeah, it sounds like there "web client" sucks. If you have local acess to to the box (or remote), it's really no big deal.

I guess it's a mindset thing. I've had a LOT of trouble in the open source world of finding authoritative answers to questions. Google helps, but oftentimes I've found documents that were misleading, didn't apply to the versions they said it did, etc (I recall distintcly reading a Tomcat article that said it should apply to the version I was using, but in the end, didn't. The author just "assumed" it would. Wheras with Microsoft's stuff, at least it says what version it applies to...

Anyway, I think we can all agree that Oracle's documentation blows monkey balls :)

Re:Predictable

[aminorex]

> Oracle wants you to use their database product for all of your data.
> Nothing wrong with that, that's their business.

Nothing wrong with that from the vendor's viewpoint, but what about the
customer's viewpoint? There's plenty wrong with that. I'm trying to run
a business. I don't want to be chained to a stall and milked for cash until
I die, thank you very much.

Re:Predictable

[drew]

I'd also check again with regard to XP. I think the Redmond boys may have rewritten that stack by now.

Even in NT, they didn't use the BSD TCP/IP stack, despite the common misconception. The user programs (ftp, telnet, etc) borrowed heavily from BSD code, but the TCP/IP stack I am pretty certain came from elsewhere.

Re:Predictable

[ednopantz]

Microsoft's documentation. I wouldn't say it's one of their strong points, it usually sucks to read, but they do generate a TON of it. If you can extract the actual information from the marketing speak it's usually there.

You obviously haven't read much MSDN documentation or SQL Books Online. Whitepapers and such tend to be heavy on buzzwords because that is what they are for: 30,000 ft stuf: "What is Microsoft TLA and why is it the greatest thing since cheese."

SQL Books Online and the .NET MSDN documents are "just the facts." They take this stuff very seriously. If you have a gripe, email the page administrator. I have gotten replies same day after I pointed out problems with something. "What does this method do"-type documentation is something they are very, very good at.

Re:Predictable

[killjoe]

"First, let's be clear: excepting their horrible SQL implemntation, I never said SQL Server is bad -- just mediocre. Mediocre (but good enough), cheap, and easy to convince the boss to use constitute and excellent decision in many instances."

Actually it's not that cheap. Feature for feature oracle 10G costs the same as SQL server. Oracle has gone to great pains to make sure they have a equavalent to SQL server at the same price. Oracle does cost more when you get into the enterprise edition but that's because oracle enterprise edition has more features then SQL server enterprise edition. There is a mid level oracle that has all the same features of SQL server enterprise edition for the same price.

Finally oracle 10g is as easy if not easier to administer then SQL server.

Really there is no need to buy sql server unless you are religiously affliated with MS.

Re:Predictable

[jedidiah]

Microsoft is infact not very price competitive with Oracle. Oracle has the same kind of low pricepoint options that Microsoft has. Now while Microsoft does have some nicer tools bundled in, you are also forced to run windows.

Re:Predictable

[MeauxToo]

AKAIamBatman,

My bad. Misread. I apologize for firing that particular criticism without reading more carefully.

-MeauxToo

Re:Predictable

[david duncan scott]

You could be right. I once ran strings on the ftp.exe, but isolating the protocol stack and scanning it surpassed both my skill and interest level.

Re:Predictable

[AKAImBatman]

Apology accepted. No worries. :-)

Re:Predictable

[kurtdg]

Finally oracle 10g is as easy if not easier to administer then SQL server.

Make that 10g R2. The early 10g contained bugs that took the easiness away if you hit them -- like DB Console failing to start when your IP has changed or for whatever other reason. No luck trying to fallback to OEM because they moved some functionality to the DB Console exclusively. Back to the command line!

Re:Predictable

[bestguruever]

I definitely agree. steps to getting something new to work in Oracle:

1. read documentation to get a fuzzy idea of the concepts
2. search for articles in metalink to find out what you are actually supposed to do
3. do it and make note of all the errors
4. find workarounds for the errors
5. repeat 3&4 untill no more workarounds exist
6. file tar
7. ...
8. 
   
   yes, it has been a very frustrating week

Re:Predictable

[killjoe]

Personally I prefer the command line, a wisened on DBA once told me "emacs + CVS is the best database tool in the world".

Kids these days though, they can't live without the eye candy.

Re:Predictable

[jadavis]

but very little sense to compare either of those products with Oracle;

It makes a lot of sense, especially if you're deciding between Oracle and a cheaper alternative. Many people bought Oracle when it was the only DB that could get the job done for them, but PostgreSQL has come a long way since that time.

Absolutely anyone getting ready to make their next payment to Oracle should be comparing Oracle with PostgreSQL to make sure Oracle is really a wise investment.

Re:Predictable

[jadavis]

What you want is PLJava, which is released and functional code:

http://gborg.postgresql.org/project/pljava/projdis play.php

PLJ was more like a first try, and I don't think it's being maintained.

Re:Predictable

[ErikZ]

Why didn't you just go to the bookstore and get a book on SQL server?

Re:Predictable

[DrSkwid]

> What you want is PLJava

believe me, I don't =)

but some people probably will so thanks for mentioning it.

I just did a search for "postgresql java " and PLJ was the first one I found

Re:Predictable

[Pfhreakaz0id]

well, if it makes you feel any better, your post made my morning with a good, solid laugh.

I still use Oracle a little, but at my last job (a U.S. gov't agency). It was all Oracle -- Database, app server (yuck), workflow, persistence framework for java, etc. Man, I recognize those steps all too well. There docs are horrible. I don't think it's malicious, but I don't see how a company that derives significant revenue from selling consulting services making it's own products work would have much interest in writing clear documentation (or making there product easy to use, for that matter).

I never forget getting several java samples from a lenghty, fairly well written white paper that WOULDN'T COMPILE! Not classpath errors, but syntax ones. That's brutal. Also, there web site looks like something someone threw together in 1998 with FrontPage.

Don't get me wrong, Oracle is a GREAT database, however.

Re:Predictable

[jadavis]

PostgreSQL is trying to centralize things at pgfoundry.org so these things should be a little easier to find.

Unfortunately, projects like pljava are still on gborg, which is an older system that they're moving away from.

integrating into the OS

[jbellis]

I'm not sure what they have in mind here, but if that's the direction they're going it's clear why they wouldn't go with MySQL (technical shortcomings aside). PostgreSQL's BSD license makes it much more attractive for Sun, whose CDDL license is incompatible with the GPL, IIANM.

Re:integrating into the OS

[AKAImBatman]

it's clear why they wouldn't go with MySQL (technical shortcomings aside).

Actually, I'd say that the technical shortcomings have a LOT to do with it. PostgreSQL can be placed head to head with Oracle and still pretty darn appealing. MySQL really don't have that capacity (yet), and is hampered by its non-ANSI comaptible design and SQL variant. So I'm not certain that the decision was made entirely on licensing alone. After all, Sun does support the GNOME project as well, and that is solidly under the GPL.

Re:integrating into the OS

[jhines]

If they add it into the install process, they could have an all in one solution with db, web, web, and other services in one install pass.

Combined with in a blade or other server format, SUN should be able to unit that smokes the others on TCO basis, and can be advertised at a fixed dollar price, w/o additional license fees.

Re:integrating into the OS

[morgan_greywolf]

After all, Sun does support the GNOME project as well, and that is solidly under the GPL.

Actually most of the GNOME is licensed under the LGPL.

Re:integrating into the OS

[Decaff]

No... the BSD license allows Sun to fork it, release it under Yet-Another-Open-Source-License, and then claim it as their own open source project.

So if someone else does this, it is an avantage of open source, but if Sun does this....

Re:integrating into the OS

[Decaff]

No, dumbass. Read the fucking post:

release it under Yet-Another-Open-Source-License,

Exactly. That what the BSD license allows.... so what is wrong with doing it? I assume the rants are only because it is Sun...

Re:integrating into the OS

[Decaff]

It's just not going in, is it? YET-ANOTHER-OPEN-SOURCE-LICENSE... as if there aren't enough already -- and Sun is a prime offender in this regard.

What seems to be missing from your understanding is that it is not 'YET-ANOTHER-OPEN-SOURCE-LICENSE'. Sun's license is well established and approved by the Open Source Initiative. So much for 'yet another'!

Sun have been contributing open source for years.

Jeez. Sun zealots are even dumber than Apple crazies.

The dumb zealotry is when established (not 'yet another') official open source licences are actually disapproved of!

And again, if the BSD license allows this, who cares? You don't have to use the forked product if your zealotry prevents you.

Re:integrating into the OS

[jedidiah]

Not if you're a production DBA. Postgres still lacks robustness and maturity when it comes to redundancy and recovery. Some features are either quasi-supported by third parties or are now just entering the product via beta. Postgres is on par with Oracle from about 10 years ago.

Re:integrating into the OS

[AKAImBatman]

Not if you're a production DBA.

Depends on what you're doing. I've seen a lot of production environments work fine with PostgreSQL. It can't hold a candle to Oracle on really big and powerful databases, but for a lot of the small-to-medium-business applications being deployed today it's more than enough.

Some features are either quasi-supported by third parties or are now just entering the product via beta.

Actually, the 8.0 series has been out for awhile, and gained many of the professional features you're probably thinking of.

Postgres is on par with Oracle from about 10 years ago.

It is REALLY hard to be current with Oracle. That's why only Oracle can do it at the moment. PostgreSQL is probably next in line. :-)

Re:integrating into the OS

[Decaff]

"Sun's license"? Which one of the many purportedly "open source" licenses that Sun plays with would that be then? Let's assume it's the CDDL: well established... hardly. Yet another MPL variant that does nothing that half-dozen pre-existing licenses already do, and introduced especially to create Sun's own little walled garden of Solaris code. "Yet another" -- fucking too right.

CDDL does mean well established. It means reviewed, accepted and approved by the Open Source Initiative. Who's opinion about the validity of the license do I accept - theirs or yours? As you post anonymously, I can't tell who you are, so I prefer to accept theirs.

Anyone who thinks that Solaris code is a "walled garden" has no understanding of open source. Anyone who thinks that Solaris code is "little" has no understanding of operating systems!

And again, as a Sun zealot it's hardly surprising that you fail to understand what license proliferation means. If the best you can do is fall back on making an argument that is not being disputed "BSD allows forking" -- then it just shows what an intellectually bankrupt little advocate you really are.

I'm not that little :)

However, what I do understand is the term 'proliferation' - it means an increase. Releasing code under CDDL - an existing OSI approved license - is NOT proliferation.

I am not an advocate for Sun - I have had to deal with enough crap code and operating systems from them in the past! What I am an advocate for is realism and a sensible attitude. Ranting against Sun just because they haven't seen the 'true Linux religion' and released everything they have ever written under GPL is absurd, and shows a naive lack of understanding of the complex history of code and patents involved.

And (yet again...) if the BSD license allows forking - what IS the problem? As I said before - no one is forcing you to use any forked code.

Let the PostgreSql vs MySQL Debate Commence

[kannibal_klown]

I have a feeling we'll see a couple of instances of MySQL vs PostgreSql flamewars starting in this story.

Personally, I think you just go with whatever floats your boat. I like how PostgreSQL is closer to the SQL standards Oracle uses, as it makes things easier for me where I work. However, MySQL is a goliath when you take in popularity, marketting, and even UI polish.

In any case... Let's get ready to rumblllllllllle.

Re:Let the PostgreSql vs MySQL Debate Commence

[mysqlrocks]

I have a feeling we'll see a couple of instances of MySQL vs PostgreSql flamewars starting in this story.

Anybody can guess where I stand in this debate (hint: look at my slashdot username).

Re:Let the PostgreSql vs MySQL Debate Commence

[darylb]

On top of being closer to the standards Oracle uses, IIRC, PostgreSQL uses a transaction model that is essentially identical to Oracle's, even though it's implemented differently. In spite of the hype around database independence, the reality is that the differences in transactional behavior radically affect the ability to port from one database to another. The fact that PostgreSQL's native stored proc language already looks a lot like Oracle's PL/SQL, with an effort to make PostgreSQL run PL/SQL unmodified in the works elsewhere, is another big plus.

Re:Let the PostgreSql vs MySQL Debate Commence

[Overly Critical Guy]

My username is pissed you got up this morning!

Re:Let the PostgreSql vs MySQL Debate Commence

[DrSkwid]

you spelt sucks wrong

Re:Let the PostgreSql vs MySQL Debate Commence

[GuyWithLag]

Looks like you havent' used the cli tools of the two DBs. Please, do have a look....

Re:Let the PostgreSql vs MySQL Debate Commence

[mysqlrocks]

you spelt sucks wrong

LOL, I think we know where you stand in the flame war, don't we?

Re:Let the PostgreSql vs MySQL Debate Commence

[stoolpigeon]

It's interesting that you can't just mention one product without the other coming up. I'm dealing with this when I talk to my 4 and 5 year old daughters. If I tell one that they did good, the other is upset that I didn't tell them they did good too.
 
Apparently this community has a sizeable population of people who never progressed beyond this kind of thinking.

Re:Let the PostgreSql vs MySQL Debate Commence

[kannibal_klown]

I was referring to the GUI tools.

MySQL has some very polished UI tools, as to say the graphical interface is polished (I can't say it isn't buggy).

For newbiews and PHB's, seeing this is full of "ooohs" and "aaahs".

Re:Let the PostgreSql vs MySQL Debate Commence

[DrSkwid]

hehe yep, nailed firmly to the post

though I noticed recently you had write ahead logging, welcome to the 21st C

=)

Once again, BSD == good

[tcopeland]

Sun gets to use repackage PostgreSQL however they like, more people will be using PostgreSQL and finding bugs and adding features and writing utilities, more books will be sold, more consulting opportunities - everyone wins.

I've had people contribute code to PMD and say they were only contributing it because they felt the BSD license avoided any possible obligations on their part. And the products that are based on PMD? Just means more books sold. Good times!

Re:Once again, BSD == good

[bluelip]

BSD==Good only if you don't mind those that benefit from your work not having to contribute back to the communal pool.

BSD == Catching all the fish in the pond and not having to share w/ anyone
GPL == Catching all of the fish, but replenishing the pond w/ the offspring.

Not a ttally accurate analogy, but you get the point. GPL perpetuates the code pool, but BSD _can_ cause it to stagnate.

End users and developers will still contribute. A few corporations do so voluntarily, but w/ the GPL they'd have to.

Sungres

[totallygeek]

Sun Microsystems and PostgreSQL...good for Sun, good for the elephant database. I second the motion.

Question

[stoolpigeon]

If they take postgres and roll it into the OS- that means the work they do after that wont be coming back to the postgres community? I assume that is the likely course, or am I mistaken?
 
I like the BSD license, and I understand what the ramifications of it are. And I'm not trying to start a debate over whether this is a 'good' thing or not. Just hoping someone here more knowledgable will give some insight on how this is likely to go.

Re:Question

[meringuoid]

If they take postgres and roll it into the OS- that means the work they do after that wont be coming back to the postgres community? I assume that is the likely course, or am I mistaken?

Well, they don't have to give anything back, if postgres is BSD-license. But in practice, they probably will. Not everything, but quite a bit. It's in their interests to give back to the community a lot of the changes they've made, so that the work done on the free version doesn't unnecessarily duplicate the proprietary version, and so that the next release of postgres doesn't force Sun to rewrite half their modifications. Basically, if Sun want to take advantage of progress made by the community on postgres, then they'll be giving back some of their own. They don't want to diverge too far.

Re:Question

[stoolpigeon]

I guess what I wonder is-- if you make it a part of the OS aren't you basically forking it? Unless the ties to the os are not to the database engine itself.
 
I think the postgres development community is strong enough that it doesn't matter. So I'm not worried about it, I just am curious about the implications of that one aspect.

Re:Question

[Savage-Rabbit]

Well, they don't have to give anything back, if postgres is BSD-license. But in practice, they probably will. Not everything, but quite a bit. It's in their interests to give back to the community a lot of the changes they've made, so that the work done on the free version doesn't unnecessarily duplicate the proprietary version, and so that the next release of postgres doesn't force Sun to rewrite half their modifications. Basically, if Sun want to take advantage of progress made by the community on postgres, then they'll be giving back some of their own. They don't want to diverge too far.

I agree, even if Sun only contributes to making the Open Source version of Postgres more stable than it is now it will have been worth it. Let's just hope that if this collaboration ever materializes it won't run into the same headaches as Apple/Safari did with the KDE-team/KHTML. Assuming they are even interested in cooperating with a big, evil corporation Postgres developers may find them selves recieving what they consider 'dirty' code from Sun, having to sign non-disclosure agreements and other things that are anathema to many of them. There are many cultural incompatabilities between corportations and Open Source purists and there is no guarantee they can be overcome.

Re:Question

[tfb]

Well, if the OS they roll it into is Solaris, then it probably will be coming back, since Solaris is open source (well, all the bits they can open source without violating license agreements they've signed are or will be).

PostgreSQL?? What's that?

[Draco_es]

Oh, you mean Red Hat Database Server, aren't you? ;-) Seriously, it can be a great contender for SQL Server if it gets(more) vendor support.

Java Enterprise System isn't all in Java...

[MosesJones]

Sun's Java Enterprise System is about programming in Java rather than the tools in Java. The technology of the product isn't hugely important its the fact that the API and development is in Java. Databases are clearly easy with Java as JDBC makes the actual choice a pure commodity. So what Sun want is a solid database, for free, that rounds out their platform effort and means that in one download and license a client can "get started"... which often means it is all they use.

Re:Java Enterprise System isn't all in Java...

[AKAImBatman]

Sun's Java Enterprise System is about programming in Java rather than the tools in Java. The technology of the product isn't hugely important its the fact that the API and development is in Java.

Agreed. The only point I'm making is that having a Java infrastructure assists Sun in marketing the JES technology stack. If the entire thing is Java, and obtains a reputation for performance, reliability, and security, then it only makes Sun's Java strategy look better. With "native" components, critics are able to find openings to attack even a successful Java stack on the grounds that "it isn't really Java". (Which has always been a stupid argument, but a popular one nonetheless.)

PostgreSQL vs Mysql

[Daveznet]

IMHO PostgreSQL would be a much better fit, Mysql might work for smaller applications, but it has a lot of problems when it comes to handling enterprise environments. The latest stable version Mysql lacks many of the features that a standard RDBMS should have (Sub queries, stored procedures, views). On the other hand Mysql does have a larger user base because of its ease of use. Again PostgreSQL would be the better fit for Sun, but Mysql does have its applications.

Maybe they'll bundle a toolbar?

[MadChicken]

"the database will become integrated into the operating system."

I wonder if he means a database-oriented filesystem? There's no real reason to stop there... system and application configuration data in a database would be great.

As much as I love PostgreSQL, I think it might be kinda heavy for that kind of implementation.

Re:Maybe they'll bundle a toolbar?

[Forbman]

I wonder if he means a database-oriented filesystem? There's no real reason to stop there... system and application configuration data in a database would be great.

Yeah. Like Windows' Registry?

Re:Maybe they'll bundle a toolbar?

[bperkins]

I wonder if he means a database-oriented filesystem? There's no real reason to stop there... system and application configuration data in a database would be great.


I don't know about whether DB oriented filesystems would be useful.
However, as it is on most Linux systems, it seems like there are 27 different programs, all with their own poorly implemented db. It would be nice to have one DB to take care of everything, at least in theory.

On my machine I have slocate, apt-rpm, rpm and gconf, just off the top of my head.

Re:Maybe they'll bundle a toolbar?

[nsayer]

Yeah. Like Windows' Registry?

It's not a bad concept. I personally like the OS X method better, since it (at least in theory) better compartmentalizes individual applications, but when you get down to it what sucks about the Registry has more to do with the fact that it's on Windows than the concept itself.

Re:Maybe they'll bundle a toolbar?

[MadChicken]

Yes, only more so.

The registry is a strange beast. The hugest problem with it is corruptability. Another problem is finding anything within that mess.

So, if we had an ACID-compliant registry in a queriable DB would it really be that bad?

Re:Maybe they'll bundle a toolbar?

[afidel]

Oooh, you just gave me an idea. If the filesystem is a DB, and configuration files are in the DB, then have a presentation layer. Expose the configuration as a text or xml file, showing only the current version. If you blow something up you go into an advanced tool and roll the transaction back and your configuration goes back to the way it was. It's the best of both worlds, the simplicity and accessibility of text/xml configration files and the robustness of database stored configuration information!

Re:Maybe they'll bundle a toolbar?

[MadChicken]

Slowly the big OSes are moving to a DB-oriented filesystem in one way or another anyway. Google Desktop and Spotlight on the Mac are already indexing the file store, and in some cases creating virtual folders (a SQL view, basically). I haven't heard much about WinFS.

We really need metadata, and there are also differing implementations (or nonimplementations) in filesystems for that now.

So what we have now is a fairly simple data store with other DB features tacked on after the fact.

It only takes a bit of extra thought to extend the idea to include stored procedures and triggers... there's a lot of potential to it.

Re:Maybe they'll bundle a toolbar?

[slashname3]

What I want to understand is what do they mean by integrating the database into the operating system? Like you suggest, are they going to build a relational database of a systems file systems and the files in it?

I hope they are not going to use a database to store system configuration data. We all know how well that worked out for the Windows registry. If they do go this route it could spell the end for Solaris. Which is a real shame as Solaris 10 has a lot of good things to offer.

Why do they keep trying to over complicate things? Keep it simple and easy to fix, don't hide things in a database that work perfectly well in a text configuration file dedicated to a particular service/application.

Re:PostgreSQL vs MySQL

[El_Muerte_TDS]

SQL92:
    PostgreSQL > MySQL; but MySQL is improving it's feature set
SQL3:
    PostgreSQL > MySQL; PostgreSQL has a few SQL3 features
Speed:
    PostgreSQL ~= MySQL; sometimes faster, sometimes not
Database\table\row\... Size:
    PostgreSQL > MySQL; PostgreSQL has less size restrictions, or at least, the limits are much larger than those of MySQL
Stored Procedures:
    PostgreSQL > MySQL; MySQL not yet, but in 5 they have SQL:2003 like stored procedures; PostgreSQL has SQL, C, pgSQL, Tcl, Perl, Python and roll-your-own and a few not bundled with PostgreSQL
Installation\maintenance:
    MySQL > PostgreSQL; MySQL is easier to set up
OS Support:
    PostgreSQL ~= MySQL; postgres came a long way, e.g. there's now a stable Windows version.

Re:PostgreSQL vs MySQL

[Cmdr-Absurd]

Yes. They have been compared.
A quite legnthly comparison can be found here.
SQL92 compliant is a relative term.

Re:Too late.

[AKAImBatman]

What the hell? Since when did Pervasive give up on its B-Trieve engine? (aka Pervasive 2000) They had a damn good database going there, and an excellent track record as THE choice for converted mainframe databases. What does PostgreSQL bring to the table that they don't already have?

If everyone has to re-write the fix ...

[khasim]

Sun gets to use repackage PostgreSQL however they like, more people will be using PostgreSQL and finding bugs and adding features and writing utilities, more books will be sold, more consulting opportunities - everyone wins.

Nope. While it is true that more people can use the code and fix bugs ... there is nothing saying that those bug fixes must be released to the general public.

So if Sun fixes a bug, they don't have to release that fix to anyone.

So the bug will still exist in the base.

This is what leads to "fragmentation". Over time, the bug fixes and enhancements that are NOT released back to the base mean that the two versions (the base system and Sun's version) drift further and further apart until they become incompatible.

Software houses love the BSD-style licenses because it allows them to do that.

The GPL is useful in that it prevents such from happening. All bug fixes and such are released back to the base.

In the end, which is "better" depends upon your goals. Sun's goals are not the same as Linus'.

Re:If everyone has to re-write the fix ...

[putko]

Most BSD-license loving programmers have the (somewhat egotistical) attitude of "I'm releasing this because I hope it gets used." They tend to want the fixes out there.

This is in keeping with the fact that BSD folks toil away on code for which they can't expect to charge any money.

Re:If everyone has to re-write the fix ...

[Overly Critical Guy]

Replace "fragmentation" with "free market." If people don't like the version that doesn't release its fixes as source, they can start their own version, and if it's superior, it wins out. Or if it's not as good as the closed yet superior version, the closed one wins out. And of course, you can choose whichever floats your boat no matter what.

That's the freedom RMS and company don't want you to have.

Besides, it's not like fragmentation isn't a hugely rampant problem in the GPL-based world. Unusually, there's much more of it than in the BSD world.

Re:If everyone has to re-write the fix ...

[mrchaotica]

Most BSD-license loving programmers have the (somewhat egotistical) attitude of "I'm releasing this because I hope it gets used." They tend to want the fixes out there.

What does that have to do with anything? The "BSD-license loving programmers" aren't the ones deciding whether to release the fixes or not; Sun is the one deciding that. Without the GPL to force it to release the fixes (if and only if it distributes the fixed program to begin with), it's quite likely that it won't do so, because its shareholders won't let it give up a competitive advantage.

If the programmers tend to want the fixes out there, then they want the GPL.

Re:If everyone has to re-write the fix ...

[TheRaven64]

So if Sun fixes a bug, they don't have to release that fix to anyone.

True, on the surface. However, if they don't then the next time someone modifies that bit of code, then they will have to re-merge their changes. If someone else fixes the bug in a different way, they have to do code review on both implementations and then decide what they want to keep.

There is a reason people like Apple contribute to BSD projects - it's cheaper to get your patches merged upstream than to maintain a fork.

Re:If everyone has to re-write the fix ...

[Skjellifetti]

Besides, it's not like fragmentation isn't a hugely rampant problem in the GPL-based world. Unusually, there's much more of it than in the BSD world.

Not to be overly critical, but maybe you should provide some real proof before making such claims.

Re:If everyone has to re-write the fix ...

[putko]

My point is that without being forced to by any license, people normally contribute their work for free.

E.g. I fix a bug in NetBSD. I'm quite likely to contribute the fix back, if only so I can avoid work when I get a new release. Most BSD people are perfectly happy to share fixes. So it happens anyway.

The GPL also doesn't require one to distribute fixes. E.g. I've fixed bugs in GPL code, and not been required by the license to give them to anyone -- I didn't distribute my program.

There are licenses that require that if you fix something, you give others the fix, even if you don't distribute the code.

Perhaps that's the sort of license you really want. That's neither GPL or BSD though.

Re:If everyone has to re-write the fix ...

[njcoder]

"Nope. While it is true that more people can use the code and fix bugs ... there is nothing saying that those bug fixes must be released to the general public."

Ask people what type of envioronment they would like to be part of, one where they are forced to do something or one where they have to choose giving back and participating in. I think you'll find that people are more fulfilled when they feel they do things of their own volition.

While this may cause some problems with people that want to take more than they give, I feel it gives the people that do contribute a better experience. It also allows commercial entities to participate more freely. MS might not have contributed anything back to the BSD TCP/IP stack (or maybe they did not sure just using as an example) but the bragging rights and validation of the quality of work still helps.

Re:If everyone has to re-write the fix ...

[njcoder]

"Without the GPL to force it to release the fixes (if and only if it distributes the fixed program to begin with), it's quite likely that it won't do so, because its shareholders won't let it give up a competitive advantage."

Yeah, and that explains why Sun hasn't released anything as open source or contributed anything to open source software. Dumbass :)

Re:If everyone has to re-write the fix ...

[GCP]

So if Sun fixes a bug, they don't have to release that fix to anyone.
So the bug will still exist in the base.

You may be right, but I doubt it. If Sun were a small company selling a database-backed app to a proprietary niche who didn't know and didn't care what the database was, this could be true.

But Sun has bigger strategic interests. If they want to sell a service based on PG, it is in their best interest to make PG's reputation as good as possible without any confusing "issues" regarding PG's reputation. Imagine them trying to sell against Oracle with the explanation, "well, our version of PG has some bug fixes that may not be in other versions of PG," leaving the buyers to wonder what bug fixes the OTHER versions may have that Sun's doesn't have, while Oracle is simply selling "there is only ONE Oracle--The Real Thing--the One Everyone Uses."

Also Sun has a thing about competing with Microsoft. They'd rather take revenue away from Microsoft and have it themselves, but they'd settle for simply taking revenue away from MS with nobody getting it. MS positions SQLServer as easier to use and lower cost. Sun could fight back with "our service-based PG is even easier to use and if lowest cost is what you want, just use PG without our service for free. Either way it's better than the deal from MS, so why use Microsoft?" In other words, Sun will either get the business or nobody will, but either way they'll hurt MS. But if only their in-house fork of PG has the bug fixes, that strategy goes nowhere. They can't very well recommend the public version as an alternative to MS or Oracle. If it's so good, why did Sun have to fix it, etc.

Re:If everyone has to re-write the fix ...

[killjoe]

Actually in the case apple is hasn't worked out quite like you say. Apple development of safari for example tends to be faster then the OS project. Also apple has different goals for their browser. Even though apple has happily contributed code it's become very hard if not impossible to merge those changes back.

Re:PostgreSQL vs MySQL

[rindeee]

> PostgreSQL ~= MySQL; postgres came a long way, e.g. there's now a stable Windows version

Yes indeed, now if only there were a stable Windows platfrom on which to run it. ;)

This is more realistic

[Nuttles1]

Unlike all the articles about linux and it's rise as an OS, Open Source databases do not have the same major difficulty. With an OS, every user that uses the computer has to know how to use the system. Conversely, with a database, most, if not all users will not care what database they are using. For example, for my job, I write and maintain a windows application that supports 3 different database back ends. Our clients can care less what database they are using. Only IT and whoever is in charge of the cash will probably care what database is running. In my experiance, IT will not really care what they use because DB issues don't usually take up the bulk of their time. As for whoever is shelling out the money, well that is a toss up, but the trend that I see is that more companies are opting for less expensive DB options.

Again, open source DBs have a chance because not every user works with them directly. Also, the interface, SQL, is a much more standardized interface than with an OS. As a programmmer, writing queries to DB A is pretty darnd exactly like writing queries for DB B. So, I think that their will be much better competition in the database world as in the OS world.

Re:This is more realistic

[Nuttles1]

OK, MOST 'good' IT departments won't care much if they have to learn a new DB. I realize that some IT departments could be resistant to change, but every now and then I run into IT guys who assimilate new stuff at a greater efficiency rate than the Borg. I don't really count the lazy or incompotant in my views or assessments as those people shouldn't be in IT. Saying that, a lot of IT departments are stretched to the limit on things they have to do. In this case, learning a new DB may be reason to gripe.

Re:This is more realistic

[Nuttles1]

I must say that I work in IT and *do* care a lot what database is used, especially for mission critical applications. Learning a new database is not that much of an issue, but when it comes to backup and nice features like the ability a point in time recovery or a flashback databases do differ and the time for restoring from a failure can differ a lot.

The time for IT to voice concerns about a particular DB is when the decision is being made. It is ITs responsibility to get the right information to the people who make decisions. If your boss picks DB A because it is cheaper than DB B, but DB B has nicer recovery features, then when the DB goes done everyone knows that they are going to have a longer wait. Since in my experiance management tends to forget these things have some kind of documentation on the strengths and weaknesses of each DB and why you choose the DB you are using.

The other half of the article - Sunbird

[dtfinch]

I wonder if it would create any confusion if Sun started marketing Mozilla's Sunbird. It'd be nice to seem some fresh development on that project though.

Firebird anyone?

[MatD]

Anyone know why they wouldn't use http://firebird.sourceforge.net/> ? I've used interbase in the past and I thought it was pretty damn good.

Re:Sun? PostgreSQL?

[markandrew]

acquire? who said anything about anyone acquiring anything?

just because sun are looking at postgresql doesn't mean they're going to buy it... (is there even anything to 'buy' where postgresql is concerned?)

Re:PostgreSQL vs MySQL

[El_Muerte_TDS]

> Installation\maintenance:
> MySQL > PostgreSQL; MySQL is easier to set up

PS, this doesn't hold up on Debian systems:

apt-get install mysql-server
  vs
apt-get install postgresql

the latter is less typing.

Fragmenting might be in their best interests.

[khasim]

Way back at the beginning of the *nix wars, there wasn't any incentive not to share the improvements and such of each version ... but they still fragmented.

The same situation exists here. Sun is not legally bound to release any improvements back to the base, but can legally use any improvements that others provide to the base.

It's in their interests to give back to the community a lot of the changes they've made, so that the work done on the free version doesn't unnecessarily duplicate the proprietary version, and so that the next release of postgres doesn't force Sun to rewrite half their modifications.

That is what fragmentation is. One vendor chooses one path while a different chooses a different path.

Over time, the minor changes and improvements pile on until the two versions are not inter-changable anymore.

Yet each individual change/improvement/fix is insignificant and does not break compatibility.

We've seen this before and it happens again and again. It's always in the company's best interest to support the code base and the community ... yet it always fragments.

Re:Fragmenting might be in their best interests.

[chris_mahan]

That's because companies will not actively help their competition. The other thing is that they could couple it with some third-party software they have rights to use but not release, in which case they could not release these changes to the community. It's a shame really. I'd rather they did a fork up front than pretend to play along. It's still better fr the mindshare of PostgreSQL. Altough, didn't anyone see that coming when Sun announced in the spring that the database was the piece missing from their offering?

Re:Sun? PostgreSQL?

[bernywork]

I do find it interesting that Telstra is a Sun software customer

Telstra are also a big Microsoft customer and also a big Linux user. They use IBM GSA extensively too. What's your point?

I know one guy who worked on an implementation of part of the Telstra Mobile billing system for IBM GSA as Telstra found out that they weren't cathing the milliseconds to seconds in cell switch time and therefore billing users for it.

This just like the comment in the article is just padding. It doesn't really add anything to the post.

IBM has DB2, Microsoft has Microsoft SQL Server, Sun has.... Oracle? No....

I doubt very highly that Sun would buy PostgreSQL Inc, they would partner with them and do some code development of PostgreSQL to get it to the level where it can definately compete head on with Oracle (Although Oracle do have a lot of other software that at present Sun doesn't have) and MS SQL and DB2. The thing they would be best off doing (And probably will do) would be to go out and hire key developers of PostgreSQL to try to prioritize more the requirements that they are after.

How do they compare?

[RAMMS EIN]

I wonder how the databases compare these days. Someone I know is working with an MS SQL Server database that's too slow to be usable, and I'm wondering whether I should suggest they go with PostgreSQL instead. How does PostgreSQL cope on Windows these days? Do you still need to VACUUM your databases? Has MySQL grown up yet (i.e. implemented the features it has been missing, compared to standard SQL)? How does Oracle's performance compare to the rest?

Re:How do they compare?

[thirt]

All I can recommend is perform as much benchmarking as possible before you pull the trigger. We picked Postgres over MS SQL Server (Strictly due to License cost) to upsize our current Access Database backend. Had we performed some basic benchmarking, we would have found that PostGres was terribly slower then MS SQL Server. Running the same basic query against our main table took PostGres over 2 minutes. MS SQL Server took 3 seconds. We found out the hard way that the Windows port of Postgres has some issues. We installed the Linux version and the performance is much better, now it only takes 10 seconds. Still slower then MS SQL server from our perspective. But that's why you need to install it and perform some benchmarking. Do not rely on others, including me, to tell you which is better. Not that Slashdot users are bias or anything...perish the thought.

Re:How do they compare?

[kpharmer]

> Someone I know is working with an MS SQL Server database that's too slow to be usable

Not true, sql server is a fine database. Its problems have more to do with being excessively gui-driven, expensive compared to OS dbms, and owned by microsoft than anything about the speed.

> and I'm wondering whether I should suggest they go with PostgreSQL instead

not having benchmarked them, i would guess that sql server would be faster on the same hardware.

> Do you still need to VACUUM your databases?

I think an automated vaccuum has been created. But it was never a real issue in my opinion anyway - basically the existance of vacuum enables postgresql to speed deletions and updates - since some table maintenance can be performed asynchronously. So, cron (or task schedule) the thing to run nightly and you're fine.

> Has MySQL grown up yet (i.e. implemented the features it has been missing, compared to standard SQL)?

Not yet, but it's getting there. 5.0 should be a big improvement, but it still has a long way to go - not necessarily implementing the essential feature set, but now making those implementations robust.

> How does Oracle's performance compare to the rest?

Depends on what you need to do: have a small database, or a medium-sized database that's purely transactional? The open source databases can do the job. But if you've got a large database, or want to do some analytics (like show simple trends of data) then oracle/db2/informix are your friend. These commercial databases can easily be 40x the speed of postgresql or mysql on the same hardware for analytical queries.

Re:How do they compare?

[poot_rootbeer]

Running the same basic query against our main table took PostGres over 2 minutes.

Jesus! I've been working with PG for five years and I've never been able to conceive of a query that took two minutes to run. I have to wonder:
1. just how 'basic' is this query of yours?
2. how many rows in your table?
3. what level is your database design normalized to? (what is a 'main table' anyway?)
4. do you have appropriate indexes, etc. to optimize common queries?

But that's why you need to install it and perform some benchmarking. Do not rely on others, including me, to tell you which is better.

Oh, absolutely. Benchmarking yields very few universal truths.

Re:How do they compare?

[grassy_knoll]

I'd suggest you first determine why the MS SQL database is running slow. Sometimes a few simple DBCC commands can really help.

If it's something more than that, knowing where the slow dows are really helps.

I implemented partitioning on one of my Oracle servers, and it improved performance dramatically... but that was because the application required multiple passes over a very large table. If the slow downs were ( for instance ) locking problems then partitioning would have hindered more than it helped.

Re:How do they compare?

[thirt]

So you don't agree the windows port has issues? The same database query that took 2 minutes now takes 10 seconds. That was the point I was trying to make. So don't assume we didn't cover the basics. A 10 second query is not un-heard of.

Re:How do they compare?

[edwdig]

not having benchmarked them, i would guess that sql server would be faster on the same hardware.

From my testing, SQL Server would do simple queries like "select distinct a from b" far faster than Postgres would. If you don't use things like distinct or aggregate functions, Postgres will usually perform at worst a factor of 2 slower. When you got to complicated queries (around the point where you start considering using views to simplify things, or if you perform heavy calculations in the WHERE clause), Postgres would become much faster than SQL Server. I've seen queries that take hours in SQL Server take under a minute in Postgres. The only difference in the boxes being the SQL Server box having 1GB RAM vs 512 MB for Postgres.

Also, generally speaking, if you include the same table in your FROM clause multiple times, or both in your main query and in a subquery, SQL Server will usually crawl through your query. Postgres doesn't seem to care if you use the sample table multiple times in a query.

Re:How do they compare?

[quantum bit]

Postgres will also fare much better in situations where you have a lot of concurrent reads and writes. Last I checked MSSQL was still using row locks for concurrent access -- so doing lots of writes will absolutely kill your read performance. PostgreSQL and Oracle use row versioning which doesn't suffer from the same problem,

Re:How do they compare?

[Slime-dogg]

not having benchmarked them, i would guess that sql server would be faster on the same hardware.

rofl.

Not having voted, or watched television, I would guess that Hilary Clinton won the last election.

Re:How do they compare?

[kpharmer]

> not having benchmarked them, i would guess that sql server would be faster on the same hardware.
> rofl.
> Not having voted, or watched television, I would guess that Hilary Clinton won the last election.

and not having benchmarked a corvette vs a festiva I'd still bet on the corvette in the 1/4 mile.

you could play it safe, and assume they are both equal until you've spent a few days or even weeks exhaustively testing them. but at the end of the day, this is only a smart move if you know nothing about automobiles, just climbed out from under a rock, or whatever.

Smart path for Sun

[cpu_fusion]

Using Postgresql as a database makes a lot of sense for Sun. Its BSD license makes it easier to use licensing terms that fit Sun's needs, it's desiged for transaction-heavy applications, and it has a solid codebase with a growing community.
      True, it is not written in Java, but neither is Solaris. Sun uses Java pragmatically, as everyone should, and since there are JDBC drivers for Postgresql, it really doesn't need the database written in Java.
      I think it's a smart move, and this news combined with the Google collaboration is giving me hope that Sun's management has suddenly woke up and smelled the coff... er I mean java.

Re:Smart path for Sun

[managedcode]

True, it is not written in Java, but neither is Solaris. Imagine Morgan Stanley running on an OS and Database written in Java :)

So?

[joib]

I've had people contribute code to PMD and say they were only contributing it because they felt the BSD license avoided any possible obligations on their part.


Just like there's plenty of people who only contribute to GPL projects since they don't want "evil corporations" stealing their code.

You can find fanatics driven by ideology rather than common sense in both camps. That's hardly something to cheer about.

Re:PostgreSQL vs MySQL

[StrawberryFrog]

MySQL > PostgreSQL; MySQL is easier to set up

I don't think this is much of an issue, I recently installed postgreSQL on my Windows XP machine in order to try it out. The installation was 100% simple and painless.

Re:MSDE is free!

[Overly Critical Guy]

Uh, sure, Sun is going to integrate MSDE into their operating system.

Incidentally, Microsoft SQL Server holds the honor of being the host for the fastest distributed Internet worm.

Re:PostgreSQL vs MySQL

[AKAImBatman]

the latter is less typing.

Uh, yeah. I think he was referring to the configuration steps after that to get the server running. I personally find PostgreSQL easier (just edit the security configuration files and initialize a database, whereas MySQL makes you jump through hoops inside the master database), but from a zero to executing perspective MySQL is up faster than PostgreSQL.

Derby

[ievans]

Sun already has several engineers working on Derby through Apache. Sun bundles Derby with Glassfish (the newly open-sourced Java EE 5 app server), which also integrates Derby into the app server for the EJB timer service, and bundles it with the Java Enterprise System stack. Sun is actively promoting Derby as a development database. There was a story about it here on Slashdot not too long ago.

Sun used to bundle Cloudscape before IBM bought Informix, and subsequently switched to Pointbase. For App Server 9/Glassfish, they pulled Pointbase and replaced it with Derby.

punter == mark

[HermanAB]

American slang for 'punter' is 'mark'. A gambler, but more specifically, a loser.

Re:punter == mark

[theshowmecanuck]

A mark is someone targeted for a drive by shooting or some such violence.

Maybe this is a new slang meaning people are putting to 'mark'. But for far longer, and in much wider usage, it is a person who is being targetted to be separated from their money by a grifter or hustler etc. See definition 13.

Re:PostgreSQL vs Mysql

[kpharmer]

> Have you conducted tests yourself or are you merely repeating fanboi retoric?
> I've used both views and subqueries with MySQL recently. stored procedures are
> listed for V5.

Views are listed as a new feature in 5 - which is just a development release. So, yes - the original poster was correct on that account.

MySQL picked up sqlqueries in V4.1, though I haven't checked to see how well they implemented them: ie, can you:
    - select (select max(date) from a)
    - select blah from table (select blah,blah,blah from a,b where...)
    - select blah from a where a.blah in (select blah from b)
    - select blah from a where a.blah in (select blah from b where b.foo = a.foo)
And can it perform these subselects without tanking performance? Especially given their poor quality optimizer and notorious performance problems with queries of 5+ tables...

So, given the massive gulf between just doing something and doing it well, and mysql's history of shooting for the bare minimum the actual usefulness of their stored procedures, views, and subqueries will take time to determine.

Re:PostgreSQL vs MySQL

[JohanV]

Installation\maintenance: MySQL > PostgreSQL; MySQL is easier to set up

You might want to check out this lengthy review of the installation of PostgreSQL, MySQL and Oracle on Windows that has a winner that may be a bit surprising to those that have not been keeping tabs on what has been happening recently.

Re:PostgreSQL vs Mysql

[bigtrike]

Can you use transactions, referential integrity, and fulltext indexing on the same table yet?

Integrated database is new ???

[Anonymous Coward]

Over time ??? Since 1978 on the IBM S/38 ( aka, AS/400, aka iSeries, aka i5 ) the database ( db2/400 ) has been integrated into the operating system.

Re:Integrated database is new ???

[Duhavid]

Small nit, the S/38 and the AS/400 are not the same. Very similiar, but different.

Re:PostgreSQL vs Mysql

[shmlco]

Probably should check your facts. mySQL 4.1, the current production version, has had subqueries for some time now. Version 5, which is now at release candidate stage, has SPs and views.

What happened to Clustra?

[teneighty]

Sun gained an excellent database when they acquired Clustra. What happened to it and why are they now talking about Postgres? Are they really that intent on pissing away that investment?

Re:What happened to Clustra?

[rleyton]

I agree - I can't believe Sun are quite that stupid, but I've been wrong on that score before, and they do have a reputation for buying and burying things.

If you'll excuse the shameless link, I've written up my thoughts in more detail here, and in the last /. post on the "SunDB" matter back in Feb, a bit of agreement was to be found on the Clustra theory. My disclaimer is, I suppose, that I've worked with and used Clustra, and live in hope Sun will see the sense of their purchase.

Re:What happened to Clustra?

[htd2]

I think you will find that Clustra is alive as part of Sun's J2EE App server, it provides state replication which allows for N+1 clustered nodes running the app server.

Re:What happened to Clustra?

[zzyp]

Clustra has been renamed to HADB, and they are working on it. Search Sun's India jobs section, and you will see a ton of jobs are for HADB.

Re:BTrieve???

[AKAImBatman]

Odd, you're the first I've heard to complain about it. Interesting.

One thing that's always been nice about Pervasive, though, is that tech managers usually have a warm-fuzzy feeling about it, since many of them used Novell back in the day. It's often quite easy to get to get approval for it, especially when the tech manager was otherwise trying to cram something else down your throat. :-)

Is it just me?

[zappepcs]

From TFA "over time the database will become integrated into the operating system."

When MS integrates Access into Windows, they will have NO customers left... IMHO

Re:Is it just me?

[cnettel]

The Jet engine has been included in Windows for I don't know how long, so I am not sure what your point is.

Hmmm. I'd honestly have thought...

[jd]

...Ingres would have been a better choice - it has the kind of commercial backing that their customers seem to like, has been released as Open Source -and- is supposed to out-perform PostgreSQL on enterprise-level platforms.

Alternatively, have a database-independent wrapper and sell any of the popular Open Source databases according to customer needs. That leaves the door wide open to transparent, painless upgrades (always a good money-spinner) AND winning more hearts amongst those developing a phobia of lock-in to specific vendors.

Re:Hmmm. I'd honestly have thought...

[AKAImBatman]

Alternatively, have a database-independent wrapper and sell any of the popular Open Source databases according to customer needs.

That's basically what JDBC already is. I'm reasonably certain that Sun's "integration" of PostgreSQL merely means "bundling". There's nothing stopping users from loading up a new DB and its JDBC driver in place of the bundled database. :-)

Re:Hmmm. I'd honestly have thought...

[jadavis]

have a database-independent wrapper...

That only works if you want nothing more than the lowest common denominator from your database. Some people expect their database to do more than simple storage/retrieval.

Re:MSDE is free!

[TheRaven64]

Incidentally, Microsoft SQL Server holds the honor of being the host for the fastest distributed Internet worm.

See? It does scale. How many other databases can handle that many transactions per second?

License comparison

[5n3ak3rp1mp]

Slightly OT- Is there a good resource online to compare the different open-source licenses available (GPL, BSD, etc.)? I'm googling a lot of FAQ's about each license in particular but I can't seem to find a comparison. I do know that the GPL ensures that derivative works will stay free, but other than that I feel pretty license-clueless.

Re:PostgreSQL vs MySQL

[puppetluva]

Integrated Replication
MySQL > Postgres; Postgres has a sister product called Slony I that is hard to set up and only offers master-slave replication. In my opinion, this has been the main downside to postgres for a long time.

Hmmm.

[hey!]

The article seems a bit heavy on posturing and light on details, almost like it's there to get the message across: fear Microsoft because it competes with its customers.

Otherwise, it seems a bit curious to me, because it juxtaposes two things that don't seem to go together in my mind: High end database management and penny pinching. Prices for Oracle on low end hardware (x86 servers) are not high at all, certainly not high enough warrant any concern at all in any project that doesn't get staff and DBA time free. Once you pay for a couple of professional staff the Oracle license fees are not worth worrying about, if they are even a bit more productive. Prices for Oracle on big iron are shocking to people whose idea of a big software procurement is a couple of dozen boxes of MS Office, but in those environments they are likewise not out of place.

Oracle's licensing model is incredibly byzantine. It takes days of study to get your brain around it. Once you do, what's obvious is that it is a reflection of the company itself: it's a complex machine designed to squeeze every last marginal dollar out of the customer. But -- the reason it works is that the prics are very carefully calibrated so you don't really save any money by going to the competitor. For example, if you just grab the biggest license you can on the x86 platform to make your life simpler, you will pay dearly. But if you are selective and understand the model resaonably well, Oracle is about the same or perhaps even cheaper than SQL Server on equivalent machines. Of course if you don't know what you're doing you'll be accidentally sending Oracle beaucoup bucks, like CA did a few years ago. I assume midrange and high end licensing for Oracle are the same: they maximize Oracle's revenue for the specific capabilities you license from them, and it behooves you to choose wisely.

Of course, no pricing model works for everyone. Perhaps there are people on high end hardware who just need something that is very fast and very reliable, not highly configurably fast and as reliable as human ingenuity can make it. Which leads me to a conclusion:

Talking about Postgres in the context of Oracle and DB2 is probably just posturing. It would be years, if ever, before Postgres gets the kind of features that make Oracle a must have for many high end applications. So I'm guessing this is really aimed at delaying the encroachment x86/Windows/SQL Server on the midrange, by giving a big vendor seal of approval to Postgres, which is plenty good for the kinds of apps you run on SQL Server, and quite a bit better if the hardware is better.

Re:Hmmm.

[oGMo]

It would be years, if ever, before Postgres gets the kind of features that make Oracle a must have for many high end applications.

Actually that's not remotely true. We're not talking about MySQL here. PostgreSQL is quickly gaining all the "high-end" features of Oracle: tablespaces, failover, replication, etc. In some cases, they aren't yet as fine-grained as Oracle. In other cases, they're superior. PostgreSQL is quickly coming into its own.

On top of this, it's a lot less painful to work with, and the SQL featureset is far nicer. After having worked with them both on a daily basis, the only reason I'd willingly use Oracle is if I was working with terabytes of data and had lots and lots of money to throw at Oracle to make it work and support it. Which I don't. Like Sun is saying, this is unjustified for most people.

Re:Hmmm.

[hey!]

Actually that's not remotely true.

Remotely true? It depends. High end is a logarithmic scale isn't it? And it's a moving target. I'd say the very idea of "High End" is only vaguely useful. If you need the fine grained control of the physical database Oracle gives you, then PG isn't high end enough. And it doesn't matter if a particular feature exists if it doesn't exist in the form you need it to. On the other hand, if PG does what you need, then you're better off without the cruft.

On top of this, it's a lot less painful to work with, and the SQL featureset is far nicer.

Agreed. As a developer I like PG better.

After having worked with them both on a daily basis, the only reason I'd willingly use Oracle is if I was working with terabytes of data and had lots and lots of money to throw at Oracle to make it work and support it

Which is my point, although it is probably not raw data volume, so much as having substantial data volume and having to manage it in a particular way. For example, I recently met some DBAs for a company that sells GIS data for a great deal of the world -- most of the developed world in any case. Maintaining this data is more complex than you can possibly imagine, unless you've actually seen it being done. On some of their tables, storing, maintianing and updating a single spatial index could be a bigger job than 99% of the complete database applications there are, and that's not even necessarily the main challgenge. Even talking about a single country, or state/province, it's managing the work flow, the locking, the publishing, the versioning of the data that means Postgres' spatial database capabilities aren't even remotely close to what they need.

PG's GIS capabilities are about 90% of the way there for me but I'm a different story.

I don't want to blow too much street cred here, so let me say: I thing Postgres is great and getting better. I find dealing with the Oracle way of doing things like giving myself a deliberate paper cut. I despise Oracle as a company and think Ellison's a vile and pompous blowhard who's probably compensating for anxiety over a shortcoming in some department or other. But I mean that in a nice way.

But, I think the "Postgres Rocks" or the "SQL Server Sucks" way of looking at things is more entertaining than enlightening. SQL Server may be the right choice for a project. The reasons may be political or marketing rather than technical, but so be it. We don't live in a world where the ultimate success of a project is completely isolated from these factors.

I happen to dislike a lot of the same things about Oracle you apparently do. But my technical likes and dislikes aren't of overriding importance, and my political likes and dislikes don't matter at all unless they rise the level of right and wrong. When I point out that Oracle has certain features that PG lacks and will continue to lack for a long time, I'm not saying Oracle is the One True Database and PG is Just a Toy, or that Postgres Isn't Ready for the Enterprise (whatever that means). I'm just saying people pay a lot of money on high end iron for things Oracle can do, that by in large products like PG aren't even close to yet, not because they are stupid (some of them may be).

Re:Hmmm.

[drew]

Talking about Postgres in the context of Oracle and DB2 is probably just posturing. It would be years, if ever, before Postgres gets the kind of features that make Oracle a must have for many high end applications.

For true high end applications this may be true, but for what >90% of Oracle customers actually need, they could switch to PostgreSQL without sacrificing speed, features, or flexibilty, and they could do it while saving not only on Oracle licensing fees but also on the six figure salary Oracle DBA's typically command.

Re:Hmmm.

[kpharmer]

> Actually that's not remotely true. We're not talking about MySQL here.
> PostgreSQL is quickly gaining all the "high-end" features of Oracle:
> tablespaces, failover, replication, etc. In some cases, they aren't yet as
> fine-grained as Oracle. In other cases, they're superior. PostgreSQL is quickly
> coming into its own.

Hmmm, as much as I like postgresql I don't see it that way:

1. replication? it's most often used as a clunky way of implementing failover - yuck. In my large data architectures, replication is almost never used: it's almost always the worst solution to some problem.

2. tablespaces? yep, they're good things to have. that's fine - i think oracle and db2 have supported them for around twenty years, so it's hardly high-end technology tho.

3. failover? ok, this is critical - but there are also many different forms & flavors. I'm not familiar with what postgresql has so I won't comment - other than to say it needs to be rock-solid.

ok, how about a few more:

4. memory management: a high-end database should give you a ton of control over how memory is handled - especially when you plan to buy tons of it. Here the big databases allow you to assign different amounts of memory to different buffer pools, which are then assigned to different tablespaces. These bufferpools (caches) are how to easily ensure that hits against some tables or indexes occur 99% of the time from memory, and others 50% because they're so much larger. I'm pretty sure that neither postgresql or mysql can do this.

5. process management: in db2 your application writes to a buffer pool, an asychronous agent picks up that change and writes it to a log file, another asynchronous agent picks it up and writes it to the table. This heavily-asychronous behavior (and yes, with memory & processor tuning available for each agent type) allows you to maximize write-throughput. Postgresql and mysql are still in the slower sychronous world.

6. parallelism: in mysql and postgresql all queries are single-threaded. In db2 and oracle a large query will actually split itself up into multiple sub-queries to maximize throughput for multiple cpus and storage arrays. This provides db2 & oracle with linear performance improvements up to 4-8 cpus. In othe words, large queries that perform table scans can take advantage of SMP hardware for the commercial products - and cut down your query time by 75% on a 4-way compared to mysql and postgresql.

7. partitioning: btree indexes only work for very selective queries - like when you want 1% or less of the data of a table. But for many queries you need to crunch 5,10,or 15% of the data. That's where range partitioning comes in: you just scan the data you absolutely need to. So, while db2 or oracle are scanning 10% of the data - postgresql or mysql still have to scan 100% of the data. That would result in a 10x increase in speed over postgresql or mysql.

that's just off the top of my head - given a little time this list would double.

Postgresql is a fine tool, and it has all the technology that db2 or oracle had 12-15 years ago. And that's a cool achievement, and qualifies it do a ton of cool projects. Plus, with time it will catch up. But it still has a *long* way to go.

Re:Hmmm.

[Decibel]

PostgreSQL is fine until you hit territory where it's not.

Given recent development history, it's going to be years before PostgreSQL has anything close to parallel query execution. And years more before it has clustering. And years more before it has the grid features that 10g has.

Of course with growing commercial interest that could all change very quickly. Linux used to be a toy compared to unixes, but millions (if not billions) of dollars worth of development from places like IBM completely changed that. But Oracle is the 800 pound gorilla of databases because they solved a lot of very hard problems. And I suspect they still have patents on a lot of that stuff, which could stand in the way of PostgreSQL and others.

Re:Hmmm.

[Cyno]

Theory is good and all, but benchmarks will provide a much nicer comparison.

Microsoft has been saying for years how much better their technology is, but the stats show a completely different perspective.

So, yeah, I'd like to see a thorough comparison of DB2, Oracle, MySQL and PostgreSQL, and MSSQL if you must.

Re:Hmmm.

[kpharmer]

> Theory is good and all, but benchmarks will provide a much nicer comparison.
> Microsoft has been saying for years how much better their technology is,
> but the stats show a completely different perspective.
> So, yeah, I'd like to see a thorough comparison of DB2, Oracle, MySQL and
> PostgreSQL, and MSSQL if you must.

Well, you could take a look at www.tpc.org - to see how the vendors have configured their databases in various situations, how fast the results were, and how much the config cost. Last I looked SQL Server is very competitive at the low end of data volumes & transaction rates for price.

Postgresql and mysql aren't there yet, but i'm sure they will be before too long. In the meanwhile, without stats, if you understand the technology it isn't that difficult to figure out basic performance issues.

Without stats, but with an understanding of how these products partition data - it is still fairly staight-forward to get a basic idea of what kind of performance to expect.

For example, it's easy to see why MSSQL can be competitive at 100 gbytes, but completely falls behind beyond that. And of course, you'd expect the same from mysql and postgresql. Beyond 100 gbytes db2, oracle, and informix are roughly comparable. beyond about 5 terabytes db2 takes the lead. This is all driven by database partitioning and parallelism: you really don't need to benchmark them to anticipate these results.

Re:Hmmm.

[nconway]

Here the big databases allow you to assign different amounts of memory to different buffer pools, which are then assigned to different tablespaces.

Yeah, Postgres doesn't currently support this. IMHO it isn't that useful -- the performance improvement I'd expect would be pretty small (for one thing, all Postgres buffering is done in addition to the kernel's buffering, so the net impact will be smaller). It also adds a significant administrative burden -- you need to configure which objects go in which pools, as well as how large each pool is.

5. process management: in db2 your application writes to a buffer pool, an asychronous agent picks up that change and writes it to a log file, another asynchronous agent picks it up and writes it to the table. This heavily-asychronous behavior (and yes, with memory & processor tuning available for each agent type) allows you to maximize write-throughput. Postgresql and mysql are still in the slower sychronous world.

DB2 may well be better than Postgres here, but your explanation above doesn't make a lot of sense. In Postgres, a committing transaction only needs to wait for the WAL record describing the transaction to be flushed to disk (multiple transactions that commit concurrently can be flushed via a single fsync(2)). That is the only I/O that needs to be done synchronously -- the rest can be done async (notably, this includes the table I/O itself -- the modified buffers are just marked dirty in memory and are subsequently flushed to disk). Note that a backend may also need to wait for dirty pages to be flushed from the buffer pool if it is trying to replace a dirty page with a clean one, but (a) those flushes are done via write(2), so there is not necessarily a disk flush involved (b) the background writer in 8.0+ is intended to resolve this by ensuring that most of the work of flushing dirty pages is not done by a normal backend.

6. parallelism: in mysql and postgresql all queries are single-threaded. In db2 and oracle a large query will actually split itself up into multiple sub-queries to maximize throughput for multiple cpus and storage arrays. This provides db2 & oracle with linear performance improvements up to 4-8 cpus. In othe words, large queries that perform table scans can take advantage of SMP hardware for the commercial products - and cut down your query time by 75% on a 4-way compared to mysql and postgresql.

... assuming your table scan is CPU-bound, which is almost certainly not the case. In practice, intra-query parallelism is useful for two scenarios that I can think of: creating large indexes, and OLAP workloads in which you are running a small number of concurrent queries, each of which is extremely expensive. In more normal OLTP circumstances, the number of concurrent clients far exceeds the number of CPUs in the box, so you don't need to parallelize within each query. Still, I agree this would be useful to have in some circumstances, although it's a bit difficult to see how to implement it reasonably.

7. partitioning: btree indexes only work for very selective queries - like when you want 1% or less of the data of a table. But for many queries you need to crunch 5,10,or 15% of the data. That's where range partitioning comes in: you just scan the data you absolutely need to.

PostgreSQL 8.1 (currently in beta) includes "constraint exclusion", which is essentially a primitive form of table partitioning (using inheritence and check constraints, you divide the data into tables with distinct check constraints; the optimizer has been improved to recognize when a child table can be omitted from the query plan by looking at the check constraints involved).

Re:Hmmm.

[kpharmer]

> Yeah, Postgres doesn't currently support this. IMHO it isn't that useful --
> the performance improvement I'd expect would be pretty small (for one thing,
> all Postgres buffering is done in addition to the kernel's buffering, so the
> net impact will be smaller). It also adds a significant administrative burden
> -- you need to configure which objects go in which pools, as well as how large
> each pool is.

this can be extremely useful - when you've got a very busy transactional database - the key to good performance is getting that high buffer hit ratio. You'll often have a few very large tables that are too big to cache - with a variety of small tables as well. Using this approach allows you to easily ensure that the larger tables don't force the smaller ones out of the cache. And it isn't much overhead - since (in db2) you'd typically only create a few buffer pools for these few different table types. Then assign at the tablespace level anyway.

> ... assuming your table scan is CPU-bound, which is almost certainly not the
> case. In practice, intra-query parallelism is useful for two scenarios that I
> can think of: creating large indexes, and OLAP workloads in which you are
> running a small number of concurrent queries, each of which is extremely
> expensive. In more normal OLTP circumstances, the number of concurrent clients
> far exceeds the number of CPUs in the box, so you don't need to parallelize
> within each query. Still, I agree this would be useful to have in some
> circumstances, although it's a bit difficult to see how to implement it
> reasonably.

I've found that with db2 (8.2) on a well-balanced system it results in a linear performance improvement up to 4 cpus (and maybe beyond, haven't tested). This is most useful in olap applications, but even in normal OLTP apps you've got the occasional tablescans, massive backups, index creations, etc to deal with.

> PostgreSQL 8.1 (currently in beta) includes "constraint exclusion", which is
> essentially a primitive form of table partitioning (using inheritence and
> check constraints, you divide the data into tables with distinct check
> constraints; the optimizer has been improved to recognize when a child table
> can be omitted from the query plan by looking at the check constraints
> involved).

That's cool. In db2 these are called 'informational constraints' - and can be used to support writable union-all views for this type of range partitioning. This is a pretty cheap method of range partitioning (can get a little messy with a thousand daily partitions, etc), but if it works well there's nothing wrong with it.

Re:Hmmm.

[hey!]

For true high end applications this may be true, but for what >90% of Oracle customers actually need, they could switch to PostgreSQL

Yes, you said it a lot more succintly than I did. People ought to try harder to make better choices.

There's an idea that standardizing on a single tool makes things easier. While there is some truth in this, you don't tell a carpenter that he has to make do within nothing but a saw.

Re:PostgreSQL vs MySQL

[archen]

Yeah, that's definatly a distro problem. If you compile from source (or use a package) then there isn't much of a difference. Sure you may need to read the manual for Postgres to get started, but only an idiot would use MySQL without understanding many of the gocha's involved - thus requiring you to read the manual as well.

PostgreSQL vs MSSQL vs Oracle

[WebCowboy]

...is probably the most fair comparison.

Don't know much about Postgres in production environemnts. It seems clean and I like the fact you have a choice of stored procedure languages.

I have had experience with both in production environments, and I've come to the conclusion that PostgreSQL is clearly a step above MSSQL in terms of features and scalability. It is much better than MSSQL with concurrency and managing contention (MSSQL's locking strategy is quite brain dead). There is much more flexibility and power to create user functions and stored procs in PGSQL--you can do things like make user-defined AGGREGATE functions and data types in addition to having a choice of languages (none of that is possible with MSSQL). I find that all things being equal PostgreSQL is probably faster as well (largely an assumption becasue the PostgreSQL systems I've worked with are running on considerably less powerful hardware than the MSSQL systems I am doing). A lot of people comment about the ease of administration of MSSQL but I find that PGSQL really isn't that hard to manage even if you don't use GUI tools.

Oracle is certainly one step above PGSQL in power--but of course that comes with a very hefty price tag. That price isn't just in licensing either--Oracle takes more time to administer and you also pay by losing flexibility, since enterprise systems based on Oracle better do things the "Oracle way" or you are inviting trouble (just like with Microsoft products, Oracle really pushes its single-vendor solutions).

I have not played with Yukon/MSSQL 2005 yet, though I've heard a fair bit about it. From what I've heard it closes the gap a fair bit and comes much closer to PGSQL in terms of features and performance--it is supposed to handle locking/contention better and its has embraced .NET--meaning that you can write stored procs and functions in any .NET language. So, they are probably a pretty close match except in a couple of areas--PGSQL is free (libre and gratis), and PGSQL is not platform dependent. I think that the fact MSSQL only works on Windows is a major drawback when all its competitors offer products that run on Windows, Linux and various UNIX derivatives. Various "facts" notwithstanding I still think that Windows servers are a greater administrative burden and more difficult to secure than other alternatives--perhaps the next server version after 2003 will have addressed that.

Re:PostgreSQL vs MSSQL vs Oracle

[killjoe]

Why do people always forget about ingres, firebird and other great open source databases when this topic comes along. Isn't there anybody who can step in tell us their experience with those?

By the way over the years I have been convinced that MSSQL developers follow postgresql development pretty close. They slowly seem to be adding all features postgres has to sql server. I bet they are even using a bunch of the same code.

Re:PostgreSQL vs MSSQL vs Oracle

[kpharmer]

> I've come to the conclusion that PostgreSQL is clearly a step above MSSQL in terms of features and scalability

that might be true of v7.3 - when using postgresql 7.1 it was clearly not as easy to work with as MSSQL 2000. A perfect example was stored procedures - where you couldn't return a result list in postgresql, and the python stored procedure language required so many ticks and escapes it was impossible to use.

Regarding oracle, it used to be so much worse than it is today. For small databases it really doesn't take much time at all IF you are familiar with the product. If not, then you need to hit the books for a little bit. And the price isn't hefty at all - it can be cheaper than your redhat license for small databases. The much larger databases is where the cost is really at, but postgresql doesn't compete there anyway. In the middle ground - that's where you've got decisions to make - and the cost could go either direction, depending on how you architect the solution & negotiate.

Regarding yukon - the informal benchmarks i've seen indicate that it isn't going to provide anything for performance. Another major drawback with SQLServer is the entire gui orientation: it's great for demos and development databases, but if you've ever had to migrate code (such as for DTS) from test to production by recreating then you know what i'm talking about.

I'd also consider db2 & informix: together have a huge chunk of the market and are gradually merging together. The licensing is about 1/2 that of oracle, with about 98% of the functionality. Plus they'll handle more data. On the downside there are considerably fewer admin tools for db2 than oracle, and fewer talented developers or dbas as well. Ah, and perhaps the biggest issue: there's no Larry Ellison involved. :-)

Re:PostgreSQL vs MSSQL vs Oracle

[jadavis]

that might be true of v7.3 - when using postgresql 7.1 it was clearly not as easy to work with as MSSQL 2000.

7.3?! That was two versions ago, PostgreSQL is on 8.0 right now. In fact, 8.1 is in beta and almost released.

And 7.1 is even less relevent to this discussion.

Re:PostgreSQL vs MSSQL vs Oracle

[kpharmer]

> And 7.1 is even less relevent to this discussion.

Nope: as of this spring there were still rediculous issues with python quoting and newlines.

This will hopefully be fixed - since using python as a stored procedure language within postgresql is hard to beat.

Re:PostgreSQL vs MSSQL vs Oracle

[abulafia]

Oracle is certainly one step above PGSQL in power--but of course that comes with a very hefty price tag. That price isn't just in licensing either--Oracle takes more time to administer and you also pay by losing flexibility, since enterprise systems based on Oracle better do things the "Oracle way" or you are inviting trouble (just like with Microsoft products, Oracle really pushes its single-vendor solutions).

This can't be emphasized this enough.

We develop for/administer both, and it costs Oracle clients probably an order of magnitude more to run Oracle than PG. The environments and apps are different, so it really is hard to compare, but on average, admin and goofy workarounds for Oracle involve adding a zero to the consultant budget, in my experience. As the consultant in question, I must admit that it makes up for the hassle, but...

If you need Oracle, well, you need Oracle. But Postgres is more than enough for 90% of the cases where folks deploy Oracle, in my experience. And it is so much nicer to work with... psql vs. sqlplus, anyone?

Sure, Toad is great, but for $1K/desktop. And it seems like once you give someone Toad, they become incapable of solving problems in sqlplus, which, face it, you're going to have to do. I know this was happening to me for a while, until I noticed it - seems like it leeches one's memory of the contorted v$ and dba_blah joins one needs on occasion, and then you're stuck.

Re:PostgreSQL vs MSSQL vs Oracle

[cd_smith]

I bet they [MS] are even using a bunch of the same code [as PostgreSQL].

That is very, very doubtful. Databases start out by making a fundamental choice in terms of how to handle transactional integrity in concurrent requests. PostgreSQL makes a somewhat radically different choice than do most other database systems out there (including SQL Server). As a result, pretty much any significant feature (anything that's really about functionality and not user interface) is going to be very difficult to port from PostgreSQL to SQL Server. That isn't to say that algorithms don't cross-apply, of course, but the code itself is sure to be rewritten from scratch.

Re:PostgreSQL vs MSSQL vs Oracle

[quantum bit]

PostgreSQL makes a somewhat radically different choice than do most other database systems out there (including SQL Server).

Except, of course, for Oracle (I assume you're referring to MVCC).

Re:PostgreSQL vs MSSQL vs Oracle

[Anonymous Coward]

And Firebird. And lots of object databases. MVCC isn't all that exotic.

Re:PostgreSQL vs MSSQL vs Oracle

[killjoe]

At a minimum they are using postgresql like the desktop group uses apple as a source of features to implement. The fact that they could look at the code without risking infection of SQL server means they are most likely looking at code too.

You may be right though, they might not be able to lift code from one project to another.

Re:PostgreSQL vs MSSQL vs Oracle

[quantum bit]

MVCC isn't all that exotic.

Exactly. I don't think "radically different" really applies.

Re:PostgreSQL vs MSSQL vs Oracle

[jadavis]

The newline issue that I think you're referring to was more an issue with Python than PostgreSQL. It seems that python was not properly interpreting the newline sequence when a chunk of code was written using one newline sequence and interpreted on a machine using a different newline sequence.

Notice I said chunk. Files work fine when moved between platforms. However, when calling the libraries to interpret embedded code (like PostgreSQL or anything that embeds python), python behaved a little strangely.

I like python, I use python, but to me the whole whitespace issue DOES cause problems. Take a look at ruby or perl, which can also be used in PostgreSQL, but behave better (in my opinion) as embedded languages. The ruby PL might be somewhat new or in development, but it's worth checking out.

Re:PostgreSQL vs MSSQL vs Oracle

[cd_smith]

Okay, I understand how what I said might have been confusing. To clarify:

• PostgreSQL uses MVCC; SQL Server does not
• MVCC is "radically different" from a non-MVCC DBMS
• Most DBMSs don't use MVCC (though a substantial number do)

I did not mean to imply that PostgreSQL is the only MVCC database out there. Sorry if anyone read that into what I wrote. I only meant to point out that it's very difficult to copy core code from PostgreSQL to SQL Server, as someone implied might be happening.

Re:PostgreSQL vs MSSQL vs Oracle

[davegaramond]

PostgreSQL is indeed one of the later player in MVCC. Oracle had been doing MVCC for longer, and Interbase/Firebird for much much longer than that. In fact IB creator is said to be the inventor of MVCC, though the concept of logging/append-only has probably been around for even longer.

However, SQL Server is even a later player. Later than PostgreSQL and MySQL+InnoDB. SQL Server is only MVCC since Yukon, I believe.

Re:PostgreSQL vs MSSQL vs Oracle

[simmiethemonk]

One thing that (last time I checked) was missing from pgsql which I find really useful is decent support for doing distributed & heterogenous queries: i.e. join tables in different databases, or join tables on different servers, or even join tables on different vendors. SQL Server will let you do all this, e.g. join a SQL server table against an Oracle table. And it supports any OLEDB data source (at least theoretically -- in practice quite a few don't work very well...) This is a great feature which I wish PostgreSQL would support... its probably the biggest reason for me to stick with MSSQL. MSSQL will also let you do distributed transactions, although I wish its transactional support was better (things I'd really like to see include: snapshot isolation (coming in 2005), nested transactions, nested distributed transactions, savepoints for distributed transaction, more control over distributed transactions from SQL...)

not to put to fine a point on it

[SubtleNuance]

According to Wikipedia's Punter entry, "In colloquial British English, a term that is analgous to a customer of a business. This usage has its roots as a derogatory reference to amateur horse-racing gamblers, but is now neutrally applied as a collective term for customers of any business."

So, it means "customer" -- something more than just "dude" (bloke).

Google should release a database

[djaxl]

combined with the Google collaboration

I know Google has their hardware search appliance, but wouldn't people jump at the chance to use/purchase/deploy a Google database? gSQL anyone?

Re:Google should release a database

[Dan Farina]

I am not so sure. As my database professor said "anything can be fast if you aren't general."

Google probably has a custom or hacked up DBMS that does what they need to do quickly, and if your needs are the same as theirs, then that's perfect...but I doubt we'll be seeing a general purpose DBMS out of them anytime soon.

Re:PostgreSQL vs Mysql

[fitten]

Although most sites I've worked at ban them to keep their product flexible for moving between DB applications.

Until you realize that each RDBMS has a different dialect of SQL and may require entirely different SQL code for optimization or syntactical reasons. You have to put the different SQL somewhere... whether you put it into your code (RDBMS specific query classes that are in-effect stored procedure libraries in application code form) or into stored procedures (your application opens up a new ODBC class at the start depending on configuration and chugs along), it has to be done somewhere. Stored procedures can sometimes be a performance gain over embedded SQL, as well.

I've done it both ways a number of times and neither one is *always* the solution. Sometimes one is better than the other. Unless you are also targeting MySQL in which you must embed your queries even if that's not the best way... and is especially a pain if you've already developed using stored procedures. For an application relying on a DB, you may tend to architect it so that the least-common-denominator is well taken care of so that you can move it around easy. If MySQL is in your list to support, well, that is your least-common-denominator as far as stored procedures are concerned.

Finally! Now if only...

[jitterysquid]

If only the companies that produce the crappy middleware I'm obligated to run would deign to bless it for use with their product. Everything I've installed lately has demanded the 10 ton pig that is Oracle even though they don't use any fancy features.

OS Integration is a great idea

[Thai-Pan]

As a developer who works on databases a lot, I still find it very arcane when I do have to get right down and dirty and work on files again. It seems very primitive in a world of SELECTs and INNER JOINs.

I personally think every OS should ship with some sort of a light db engine equipped to handle databases stored in files. Imagine if you could write a simple application that opened databases just like you would with a db server, only using a file instead. When it comes time to scale it to a larger application, switch one line and connect it to a server instead. Or have your application configurable so that the user can either store it in a file or on a remote server simply by changing the server info from "c:\database.db" to "server:1234".

Re:OS Integration is a great idea

[Anonymous Coward]

You should try coding on the AS/400 then. Absolutely everything is a database object -- there is no concept of a file. Each "file" is actually a database table. So your source code "files" are db tables. You get a timestamp for each line (as one line of code is one record in the table). You can tell exactly which lines changed when.

But, you "open" a table like a file in C -- fopen. You run a select against it like table. You get a set of lines (rows) back. You can iterate though them, then fclose.

Of course, it's AS/400 specific.

Re:OS Integration is a great idea

[geophile]

I personally think every OS should ship with some sort of a light db engine equipped to handle databases stored in files.

Yes, this makes sense. However, as someone who has spent a lot of time with Oracle and Postgres, I can say that neither one fits the bill. Oracle is just too huge and complex. Postgres is too quirky. It is very, very easy to get into serious performance problems with Postgres due to vacuuming (or lack thereof). If you have a table that is updated frequently, it has to be vacuumed frequently. If it's a big table, that can be trouble and you may need to redesign part of your application. None of this is insurmountable, but for something to be included with the OS, I think a lower degree of maintenance is necessary.

I think the best lightweight database of the sort being discussed is
(was?) Watcom SQL.

Re:OS Integration is a great idea

[cdwiegand]

Thank goodness for SQLite, then. Just add the dll (or dependancy for linux-folks) to your package and voila. This also assumes you're using some DB-abstraction layer, such as PDO, ADO, ADO.Net, etc...

Re:OS Integration is a great idea

[multipartmixed]

What kind of DB do you want?

Berkely DB and variants (GNU DB) have been shipping with everything for about as long as I can remember.

Now, if you want an SQL RDBMS, that's a different story...

Re:OS Integration is a great idea

[rdean400]

This sort of thing works very, very well for IBM's i5/OS (formerly OS/400). It's interesting to see vendors, almost 30 years after the System/38, finally embrace the concept of an OS-integrated relational database.

It's also interesting to see the amount of hype .Net's L'INQ facility is generating, because that sort of thing's been one of the main productivity features of RPG.

Re:OS Integration is a great idea

[quantum bit]

I really, really wanted to like SQLite. But I just can't get past the complete lack of column type checking. I know it's intentional because they want it to be "simple", but building a robust app starts at the foundation. If you can't trust the database to give you coherent data, you can pretty much forget about doing anything important with it.

The big difference...

[emil]

PostgreSQL uses a transaction model that is essentially identical to Oracle's, even though it's implemented differently.

The big difference appears to me to be the storage of undo information. Oracle records row changes in a special location (either a newer "undo" tablespace or the older "rollback segments").

Postgres (AFAIK) actually marks the row as deleted, then writes a new copy of the row with the modifications, so the undo information is integrated into the associated table(space), much as the older dBase products did. These old copies of rows allow database "time travel" to see previous versions of the data (this feature was added to Oracle 9 as "flashback query"). One advantage of Oracle's implementation is that the undo/rollback will mostly clean itself up, while Postgres tables must be periodically "vacuumed" to remove the old rows.

It is interesting to see Oracle add a few innovations that first seemed to appear in Postgres. The most notible of these enhancements was SQL support for regular expressions.

Re:The big difference...

[TheLink]

The big difference is with Postgresql you can rollback "drop table" and similar stuff.

AFAIK you can't do that sort of stuff with Oracle. I'd be interested if they've changed things since.

Yeah, ....

[WindBourne]

a number of the American punters are also gamblers or hooker clients.

Not true.

[emil]

As a programmmer, writing queries to DB A is pretty darnd exactly like writing queries for DB B.

Not true. Modern databases have wildly different architectures, and highly tuned code on one platform will bring another to its knees.

Some features won't port - Oracle has long-supported DECODE, which locks in much SQL to Oracle. Or how about synthetic keys, implemented in Sybase/SQL Server with an "IDENTITY" column, or in Oracle with a "SEQUENCE?" This is basic functionality which must be recoded in a db port. And we will leave trigger syntax right out - there was never a standard for it.

Some databases support locks on only a whole page, while some allow locking individual rows (but even in Oracle, if your INITTRANS and MAXTRANS are not appropriate and/or the block is full, your table will behave as if only page locks are available).

Many databases have an in-memory table for row-locks; when the table gets full, lock-promotion occurs. Oracle has no in-memory table, and there is never a lock promotion (but there is lock escalation).

Mostly apples and oranges.

Re:Not true.

[Nuttles1]

Yes, DBs have differences. I think the difference for the company I work for is that the windows app and server apps that access the database was designed from the ground up with the expectation that the database was variable. This means everything has to be kept to the lowest common denominator. Saying this, we also have built in optimizations based on particular databases for several different reasons. These optimizations and database specific stuff is kept to a minimum. It can be done. Is there trade offs. You bet there is. Could we build a application significantly faster if we focused on one DB. You bet we could. But in reality, the benifits don't justify it. For instance, if a client wants Database A and we developed only for Database B. We can't bid on the contract. Unacceptable. We can't use triggers and that makes things more difficult at times. We also had to implement our own locking mechanism because one of the databases we support is very very old. But again, the benifit of being able to point to several DBs and it being transparent to the user is immense.

Also, your comment seems to me like you are taken a position of a technology zeolot. This technology is better, or this technology we got to have. Technology is there to solve problems not create them.

Re:Not true.

[emil]

Also, your comment seems to me like you are taken a position of a technology zeolot. This technology is better, or this technology we got to have. Technology is there to solve problems not create them.

Zealot? No, hard experience. For example, take "SELECT * FROM TAB WHERE X IS NULL" - this is something that all databases will do, but will kill you in Oracle, since for the most part NULLs will never be indexed and will force a full table scan (nulls are recorded in bitmap and composite indexes). You do this in any volume with your app and it's dead.

And there are a LOT of applications that absolutely, positively, cannot live without triggers.

You must have a huge list of forbidden database procedures in your entry-SQL92 lexicon. But yes, you probably have the ability to run under Postgres and MySQL, which would be a tremendous benefit (letting you do to the DB vendor what Oracle has done to commercial UNIX). It comes at a cost, though.

Re:Not true.

[Nuttles1]

I haven't come accross your "IS NULL" problem with oracle so I can't comment on that. As to this comment, And there are a LOT of applications that absolutely, positively, cannot live without triggers., I would have to say that there is a threshold to where a company will choose to use triggers as opposed to being DB independent. Programming can overcome the lack of triggers, whether that is the way a company wants to go is again a question of the benifits of having them and living without them. Absolutes in the negative are usually not a good thing. People who say it can't be done are usually interrupted by the people doing it.

Re:Not true.

[emil]

People who say it can't be done are usually interrupted by the people doing it.

Someone who tries to do everything does nothing well. You lack basic knowledge of the SQL dialects, so you are unaware of the pitfalls. Your success is probably due to blind luck.

Consider this example... try it in SQL Server. Oracle will not enforce a UNIQUE constraint on a NULL, while SQL Server will.

SQL create table test (x int unique);

Table created.

SQL insert into test values (null);

1 row created.

SQL insert into test values (null);

1 row created.

SQL insert into test values (null);

1 row created.

SQL insert into test values (1);

1 row created.

SQL insert into test values (1);
insert into test values (1)
*
ERROR at line 1:
ORA-00001: unique constraint (SYS_C0023760) violated

Re:Not true.

[Nuttles1]

This is in response to the parent post, it is quite long so please refer back to it. I think it is funny that you think that I lack 'basic' knowledge of SQL. Also, I find it amusing that you think my success is due to blind luck. If your example is the best you can come up with in refuting my assertion that using different DB back ends can be transparent to the user then I would have to say you failed miserably. The specific example you gave me had to do with Oracle not enforcing a unique constraint. We do not depend on the DB for uniques on the system I work on although all of them support uniqueness in one way or another. Also, all the fields that absolutely need to be unique, absolutely need data in them. This is the way databases are made at the company I work for. Maybe your company needs some different IT 'expertese'.

Again, people who say it can't be done are usually interrupted by the people doing it.

Re:Not true.

[emil]

If your example is the best you can come up with in refuting my assertion that using different DB back ends can be transparent to the user then I would have to say you failed miserably.

Oh really? Let's have a little test, shall we?

SQL Server's "BEGIN TRANSACTION" is critical, but it can be ignored in Oracle. This is a key difference in the behavior of the servers. Why? What is the penalty of using it incorrectly?

What is Oracle's equivalent of SQL Server's "Clustered" index? How does this relate to the primary key? When can using such a cluster diminish performance?

Where are temporary tables a good idea, and where are they not so good?

If you issue DDL, what will this do to an open transaction?

You modified one of your queries by using a function on an indexed column in the WHERE clause. Performance has suddenly tanked. Why?

Understanding the above is the bare minimum in building a cross-platform, scalable system (at least between the Sybase derivatives and Oracle). Developers who ignore their DBAs build unscalable junk.

Re:PostgreSQL vs MySQL

[Trailer Trash]

Installation\maintenance: MySQL > PostgreSQL; MySQL is easier to set up

This myth kept me away from postgres for a couple of years, since I knew how to set up mysql and didn't have time to learn something new. The fact is, as I found out easily, postgres is every bit as easy to set up as mysql, just different. And after it's ready, well, there's no comparison.

It's now rh-postgresql-server

[Ayanami Rei]

Re:MSDE is free!

[Just Some Guy]

Microsoft offers free

...as in beer, which makes it pretty much useless for many projects - such as a competitor integrating it into their OS.

Re:PostgreSQL vs MySQL

[egoots]

OS Support: PostgreSQL ~= MySQL; postgres came a long way, e.g. there's now a stable Windows version.

I just wish they would figure out a way to get a fully functioning Unicode version for Windows. It sounds like they threw the baby out with the bath water. See their FAQ for their detailed description: http://pginstaller.projects.postgresql.org/faq/FAQ _windows.html#2.6

I think the FAQ needs clarification. They say "Unicode is not properly supported on Windows, and therefore cannot be used.". My impression is that the reality is more like, "PostgreSQL uses UTF-8, and this encoding is not fully supported on Windows the way they would like. Windows (NT, 2000, XP, 2003) does support UTF-16 natively."

Re:PostgreSQL vs MySQL

[allanw]

Yeah, except to use mysql's multi-master replication you have to keep your whole dataset in RAM.

Re:PostgreSQL vs MySQL

[photon317]

The biggest one that has made a difference in my life lately:

Table Partitioning:
PostgreSQL > MySQL; Mainline PostgreSQL has table partitioning as of 8.1-beta, by leveraging inheritance (Postgres is an Object-Relational Database).

Queries on the aggregate of the partitions are directed at the parent table, and optimized to only look into appropriate sub-table by checking CHECK constraints of the sub-table against the query WHERE clause.

Basically, you do it like this (contrived, but related to how I'm using them at the moment):

MyBigFatTable stores timestamped data from a bunch of a machines at regular intervals, keying off of the machine id and the timestamp of the data:

CREATE TABLE MyBigFatTable (
    machineid INTEGER REFERENCES machines(machineid),
    stamp TIMESTAMP,
    data_x FLOAT,
    data_y FLOAT,
    [... lots more data fields ...],
    PRIMARY KEY (machineid, stamp)
);

Your problem is, the table size grows and grows and grows unbounded, and database operations continue to get slower and slower (inserts, updates, and selects) as the table grows. You have a policy to expire the data after a month which limits the maximum growth, but this in turn requires lots of deletes happening all the time, which again hurts performance.

The inheritance-based partitioning solution is to leave that table definition as it is, and also define:

CREATE TABLE MyBigFatTable-2005-10-05 (
    PRIMARY KEY (machineid, stamp),
    FOREIGN KEY (machineid) REFERENCES machines(machineid),
    CHECK ( stamp >= '2005-10-05 00:00' AND stamp '2005-10-06 00:00')
) INHERITS MyBigFatTable;

As you can see, the column definitions are inherited, but you must re-specify the PK/FK stuff. The added check clause says that only data from Oct 10, 2005 is valid in this subtable.

You set up a maintenance script to create your new time-based tables ahead of time (say once a day create tables for the next day), and you do your data INSERTs into the specific subtable (you know the timestamp of the data you're inserting, so you can generate the appropriate table name from that (MyBigFatTable-2005-10-05).

You run your SELECTs against the original MyBigFatTable just as you did before. It automatically includes any rows from its child tables. Further, if your SELECT's WHERE-clause was constraining a query to a specific time-range, only those children of MyBigFatTable whose CHECK constraint indicates they could possibly have relevant data are checked.

And as for the problem of expiring data and the delete traffic you had before? You simply drop the old child tables with "DROP TABLE" from a maintenance script when they're a month old - no DELETEs neccesary.

System/38 had an integrated database

[RonVNX]

Indeed. The System/38 had this, and was way ahead of its time. I had one pretty much to myself in 1983-84.

Groupware

[Doc Ruby]

"If you don't talk Outlook, you're in trouble."

Open-Xchange is already a MS-Exchange drop-in replacement. But it "talks Outlook" with a proprietary MAPI driver you need to install in Outlook to connect to the OX server. Which costs money per license (the rest of OX is F/OSS). If Sun released such an Outlook plugin, for free, publishing its source, which translated the Outlook MAPI protocols to standard, open protocols (like IMAP/WebDAV/iCal), they could crank open the entire industry sector. Sun's groupware, OX, other players could offer a landscape that leverages Microsoft's early market building with their limited Exchange product into better group communications for everyone.

Why not Java DBMSes...

[Christopher B. Brown]

Seeing as how Sun implements their OSes in C/C++, and also implements Java in C/C++, it makes perfect sense to "bolster" the strategy by having the data store implemented in C, as is the case with PostgreSQL.

The natural thing for them to contribute which would be self-serving would be in the area of JDBC support, where improvements to the interface to data storage represent something they would be especially well placed to provide. It would also make sense to contribute to one or the other of the projects that allow implementing stored procedures in Java...

There is nothing about a DBMS being implemented in Java that ought to make it particularly attractive to Sun, particularly when they would have grave reservations surrounding licensing arrangements.

Stolen! Oh noes!

[loqi]

A perfect example is the Windows NT/XP TCP/IP stack -- stolen straight from BSD

How many times do we have to go over this? Non-copyright-infringement is not theft.

Re:Stolen! Oh noes!

[Arcane_Rhino]

How many times do we have to go over this? Non-copyright-infringement is not theft.

True. In fact, non-copyright infringement isn't a crime at all. One can not infringe the copyright of anyone they wish.

lol. For some reason I found this particularly humorous. Thanks.

MSSQL + ...Python?

[loqi]

and its has embraced .NET--meaning that you can write stored procs and functions in any .NET language

Someone please tell me that this doesn't make Microsoft the first DB vendor to make it easy to extend database functionality in Python?

Re:MSSQL + ...Python?

[jadavis]

Ok, I'll tell you.

PostgreSQL has shipped with python as a stored procedure language since... well, a couple years back anyway. It was available in v7.2 I know.

PostgreSQL is *very* extensible.

Re:MSSQL + ...Python?

[loqi]

Awesome. Awesome to the max.

Looking seriously huh

[TarrySingh]

There is a reason why Oracle is Oracle, IBM IBM, MSSQL MSSQL. PostgreSQL is ok too but I doubt it if that will help them get their flat revenues back on target. I have a strong feeling that MySQL will soon be bought by Oracle and then they'll come up with a very very cheap Oracle liter version. But good luck to Sun tho.

MSDN

[kurtdg]

"What does this method do"-type documentation is something they are very, very good at.

I have used both MSDN (admittedly only for VBA) and the JDK docs, and the JDK docs are vastly superior. MSDN tends to only document the common cases, and ignore corner cases and limitations.

Doesn't make sense to me..

[fforw]

The transfer of copyright usually happens to prevent a fragmentation of copyright holders inside a GPLed project. You usually agree to it because of your work being little compared to the whole. The question whether you can continue to use your committed code under a different license or not is irrelevant because you couldn't use the larger part of GPLed code under a different license in any case.

Re:Doesn't make sense to me..

[jrumney]

The question is irrelevant if your contributions are minor patches to existing code. But if you write a completely new major feature, you're likely to end up with a substantial chunk of code that you could reuse. The FSF's copyright assignments give you back a non-exclusive license to use your own contributions how you please, so you don't lose anything by donating code. If you are working on other GPLed software where you are required to assign your copyright to some other organization or individual, you might want to ask them to put the same clause in their assignments.

hmm

[paulpas]

All your [data]base are belong to us.

John Cleese...

[schon]

.. when asked what the difference between the US and UK, responded with three points:

1. We speak English and you don't.
   
2. When you visit our head of state, you only have to get down on one knee.
3. When we hold the world championship for a sport, we invite teams from other countries.

Re:PostgreSQL vs MySQL

[The OPTiCIAN]

There's more to it than that. There's also setting up default users, permissions, configuring to get the security settings you need to use the database (pg_hba.conf), and probably other things too.

Re:PostgreSQL vs MySQL

[jadavis]

That's a good feature, and it will help many users.

However, I caution that constaint exclusion (CE) is a first step toward table partitioning. Those who assume that they can seamlessly split tables may encounter difficulty.

Re:PostgreSQL vs MySQL

[Qzukk]

Actually, something close could be achieved in 7.4 (and earlier versions probably, I'm not sure where they began allowing partial indexes) where one could CREATE INDEX bigfattable200510 ON bigfattable(stamp) WHERE stamp>='2005-10-1 00:00' AND stamp'2005-11-1 00:00'; which would create an index covering only those dates.

You'd still have to delete the records (and indexes) yourself though.

Re:PostgreSQL vs MySQL

[egoots]

It's fixed in the upcoming 8.1 version, now in beta.

Are you sure?

I didnt see it in the release notes... but I did see reference to a fix being held for 8.2. See: http://momjian.postgresql.org/cgi-bin/pgpatches_ho ld

I hope it is not deferred until 8.2... sigh.

No more than in any other computing environment

[jd]

You can always have a wrapper that builds more complex operations out of simpler atomic operations. In consequence, your wrapper could be aimed at the most advanced feature set you want to represent, whether any database can support them directly or not, and then compile those into the instructions required at the database level.

This is why Java and C++ are more flexible than the Pentium IV instruction set, why the StrongARM (which is RISC and has no FPU) can run floating-point software, why a RISC processor is actually faster than a CISC processor for the bulk of operations, despite needing the translation layer...

No, having a "smart" wrapper would not limit you to the common denominator. It would limit you only to the superset that can be defined by combinations of the atomic operations available at any given time. So long as the databases are roughly Turing-complete, then you have no effective limits at all.

Re:No more than in any other computing environment

[jadavis]

But that is restricting yourself to the lowest common denominator. You need to program the functionality required for your application when the functionality already exists in another more suitable product.

You could say the same thing about filesystems: "Not everyone has a database, so we'll just program to use the filesystem and reinvent any functionality we need at that level.".

Worse yet, you're talking about reprogramming functionality for each subpar database you need to include in your list of supported databases.

As for your Java analogy, I think it's more accurate to say that doing what you're suggesting is like reimplementing the JVM before you start work on your project.

Re:No more than in any other computing environment

[jd]

Let's start with a high-level wrapper that is both Turing-complete and has an API that is both complete and correct according to the specifications of what you would ever likely want to do. The Turing-complete bit will get mentioned often, and it IS necessary, as it is the only way you can guarantee all components being interchangable.

Say module X has enough instructions to be Turing-complete, and module Y also has enough instructions to be Turing-complete, but the instructions in X and Y are not 1:1. There is no "common denominator". There is nothing common there at all. You can still write a wrapper that can abstract out such details, with a high-level front-end that can convert the high-level instructions into those required by X or Y. The wrapper would need to be "compiled" for the new architecture, to take advantage of the new features, but once it had learned the best way to do things, you'd get the full benefit of it. This is how the maths package ATLAS works, for example. Many optimized crypto libraries do the same thing - looking for what can be utilized and how best to utilize it.

As hardware/software evolves, you might get some new device Z, that is Turing-complete but sports many, many new functions. The API for the wrapper need not be changed, as ALL of those functions can be expressed with the API. Some may be expressable directly - there's a 1:1 relationship - and others may require a bit of extra processing. But all of them will be supported.

The user can throw in device Z and all software that would have used X will now use Z totally transparently. They will have no direct awareness of the change. The API and ABI have remained the same, so what the program sees will remain the same. Some behaviour may change - for example, let's say you use a timer with nanosecond support, but X only measures time in microseconds. The nanosecond portion of the time structure will remain zero. Let's say Z has nanosecond support, and uses that data. If your software doesn't look at the nanosecond entry, that won't change anything. In programs where nanoseconds are used if present, though, those programs would have additional information they could take advantage of.

An abstraction layer for 2D graphics might be based on GKS, where the virtual screen width and height are real numbers between 0 and 1. It is now completely irrelevent as to whether you are using a vector-based or pixel-based screen, or what the resolution/size of that screen is. It is also irrelevent as to whether you want the full screen to be displayed, operate on a panned window (Virtual OpenLook) or work on multiple anchored desktops (KDE). The output doesn't even have to be graphical, so you're not even limited to a physical display!

"But not everything will be able to handle all the possibilities of such an abstraction layer!" Well, yes they can. Maybe not directly, but they can. The Linux Kernel Mapper (which someone needs to update!) could be used to produce a gigantic map of the kernel, which would then be split onto multiple physical pages for printing. It was not limited to the lowest common denominator of what a printer can do (and who wants to use a Sinclair printer anyway?) but rather produced the data first and then post-processed it to what the hardware could support.

In other words, overdriving the wrappers is a time-honored technique used by many of the most successful products out there. It forces hardware forwards, as the hardware is "encumbered" by what people want the hardware for, rather than the API of some competing device from ten years ago. THIS is how to write things successfully. the "ideal" API should be able to perform identical operations whether you are using the latest research machine from MIT or the oldest physical hardware that can take a program of the required size, but where you lose NOT A SINGLE ONE of the advantages, capabilities or features of the newer hardware in the process.

The advantgae of recompiling the backend engine

Re:No more than in any other computing environment

[jadavis]

I understand what you're saying. Any turing complete system can do anything if you're willing to write a large enough layer on top of it to support the API you want.

When you already have a cross platform product which already implements many of the features you need at a high level, let's say "PostgreSQL" for example, why reimplement and API on top of it? It's just extra work, and extra bugs.

There are good reasons to do that sometimes, which you mention. When the layer below is not available on all the necessary platforms, for instance. I'm just saying it's not the answer to everything. Extra layers of abstractions have varying degrees of benefit, and varying degrees of cost. Benefits can come in the form of code reuse, reduced developer time, and fewer bugs. Costs can come in the form of code duplication, increased developer time, and more bugs. Often as you add one marginal level of abstraction, the marginal benefit goes down and the marginal cost goes up.

My main point is this: there is some threshold at which you decide that you have enough generalized abstractions already, and you need to use them to get your specific task done.

Re:Sun? PostgreSQL?

[bernywork]

I wasn't under that impression, and I hope the readers of my comment weren't either. Thanks for the point though.

I was reading up on PostgreSQL.com site before my previous post, and the PostgreSQL organisation doesn't exactly seem that big. It was just that the grandparent poster referred to the purchase of PostgreSQL and I took his / her point to mean PostgreSQL Inc.

I understand and it was mentioned in another post that apparently (I haven't checked this one) PostgreSQL is under a BSD license. If this is correct, then it would be impossible for PostgreSQL Inc to own the project or the code.

It could be that Sun is eyeing off one of the other companies that writes for / supports PostgreSQL, only time will tell on that one, but it could be cheaper and easier to set up another dept and just hire developers. (That's what I would do anyway, but that's with no homework)

Database Server Feature Comparisons Chart

[jawahar]

You may want to check the comparison chart
http://dev.mysql.com/tech-resources/features.html

you don't know what you're talking about

[jbellis]

8.0 introduced "dollar quoting" for people like you who can't figure out that '' is how you escape a quote within SQL single quotes ...and that was released in January.

SUN and Postgre

[hal1947]

he said, adding that over time the database will become integrated into the operating system." Finally catching up with Pick OS (development language and database integrated in OS) developed by Dick Pick gone now some 11 years. search on pick os or dick pick for some very interesting history on databases.

Nasty British Food

[L.Bob.Rife]

Yes.. your British based magazine likes wierd British food. The number one restaurant in the world (according to them) serves:

delicacies such as snail porridge, mussels in popcorn sauce, and bacon and egg ice cream.

I have serious doubts about the judgement of anybody who chooses that as the best food in the world.

Re:Integrated DB?

[setantae]

SQLite is already used in Solaris 10 as the repository for the new smf(5) framework.

Sure, it's not a "real" RDBMS but it shows that Sun believe that there are applications for databases within the OS sphere.

Integrated into the OS?

[Cinquero]

Isn't it already integrated into the OS??? Can't I already run MySQL and Postgres on a regular desktop Linux system? The only thing that is lacking is a common desktop database interface that makes all independent of the actual database backend and lets desktop apps connect to the database. But, "unfortunately," there is already Berkeley DB which already does a pretty good job at providing database functionality for desktop apps. So what? Could someone give me a clue as to why we need a giant DB running on each dumb desktop? Why should it make sense to integrate a DB with the file system or with the OS -- whatever the latter means? Hasn't Linux not proven already that a modular structure like we have today is the best and most accepted solution and will probably ever be?

Scratching my head and wondering what this fuss is all about... ????