Slashdot Mirror
MySQL Quietly Drops Support For Debian Linux [UPDATED]
volts writes "MySQL quietly deprecated support for most Linux distributions on October 16, when its 'MySQL Network' support plan was replaced by 'MySQL Enterprise.' MySQL now supports only two Linux distributions — Red Hat Enterprise Linux and SUSE Linux Enterprise Server. We learned of this when MySQL declined to sell us support for some new Debian-based servers. Our sales rep 'found out from engineering that the current Enterprise offering is no longer supported on Debian OS.' We were told that 'Generic Linux' in MySQL's list of supported platforms means 'generic versions of the implementations listed above'; not support for Linux in general." Update: 12/13 20:52 GMT by J : MySQL AB's Director of Architecture (and former Slash programmer) Brian Aker corrects an apparent miscommunication in a blog post: "we are just starting to roll out [Enterprise] binaries... We don't build binaries for Debian in part because the Debian community does a good job themselves... If you call MySQL and you have support we support you if you are running Debian (the same with Suse, RHEL, Fedora, Ubuntu and others)... someone in Sales was left with the wrong information"
Is it really a problem? If you worried about support wouldn't you be using a distro that also offers support contracts?
"I use a Mac because I'm just better than you are."
Clearly we need to get some tough mother forkin programmers on this...
MySQL (the database) still works with Debian, but MySQL (the support company) no longer sells support for Debian.
I guess it time to dig in and learn another tool to replace it.
Agile Artisans
Loudly drop support for MySQL. Here are two excellent alternatives:
PostgreSQL
Firebird
Still, Debian provides good MySQL packages. Use them instead. If you need support, I'm sure you could find someone to provide it for you.
"It ain't a war against drugs.it's a war against personal freedom" --Bill Hicks
I guess that's fair - my company migrated to supporting only "generic Red Hat Database", aka PostgreSQL.
Seriously, except in cases where you have no choice about database availability, I can't see a single reason to use MySQL these days. All of their cool features are owned by their competitors, and they're starting to pull desperate financing tricks like whittling away tech support and partnering with SCO. Are people still using it for new deployments, and if so, why?
Dewey, what part of this looks like authorities should be involved?
I can't say for sure whether it's the same level of support, but there's always Canonical for Ubuntu and Progeny for Debian support.
I Browse at +4 Flamebait
Open Source Sysadmin
They're more than happy to be a SCO/Canopy partner.
I know where I'll not be spending my IT budget next year.
It's true no man is an island, but if you take a bunch of dead guys and tie 'em together, they make a good raft.
I suppose you could do that, but unless you're planning on offering Enterprise support for your offering on a wide variety of platforms, you're not really gaining anything. MySQL will presumably still run on Debian, at least for now, but without the ability to buy support for it on that platform, you're not going to get approval to put it on that platform in any sort of business-critical environment.
Now, if you wanted to start a new company that offered Enterprise support for MySQL on Debian, you might have something there. I don't know that you would make any money, but at least you'd be offering something that isn't currently offered.
MySQL only lets me spoon it.
But Postgre lets me fork it all night long.
I see that a definite split of "Premium Linux" vs. "Unsupported Linux" is coming soon to a vendor near you. That doesn't mean that Linux will die, it's just going to smell funny (possibly like pee).
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
I see there's already a few comments that the code should be forked. The thing is, what is forking going to do for it? They are dropping support for Linux distros, but that's not saying it won't run on other distros, just that it's not supported. The only way a fork would do anything is if the forked version had it's own support as well.
While I don't currently have or need a support contract from MySQL, I wouldn't transition away from Debian within our machine room just for their sake. I can't say this is a mistake for them, as I don't know what sales numbers they see, but here's one potential customer that's gone as a result.
Why? Is there a problem with the code, or the license? You're free to start your own company and offer tech support and other services for MySQL, and there's always PostgreSQL. But if the MySQL coders are still doing good work, I see no reason to fork.
LOAD "SIG",8,1
I don't see this as a technical deficiency of the software. This is a business issue.
Do you have Debian and MySQL expertise? Find yourself someone business-savvy (hint: it's probably not you) and sell support for MySQL on Debian. Be your own boss (hint: make sure your business-savvy person isn't a PHB). I think MySQL AB has been pretty clear in the past that they are but a small (if central) part of the MySQL ecosystem, and they clearly want to focus on their high-margin customers. Might be a smart move, might not, but it sure opens the door to players who want to seize the other niches.
Simple Unexpected Concrete Credible Emotional Stories
The problem is support, not inoperability. The software still works, you just don't have anyone to call when it doesn't work the way you expected. Forking the project does not solve this problem. If a third party wanted to sell a customer support contract for it, they could do so without needing a fork. If MySQL started releasing later versions of the software without the source, then a fork would be needed to have a branch that could be supported by another company.
MySQL just said, 'We don't think that your business is profitable to us,' for whatever reason they might have. Well, I'm willing to bet that MySQL support for Debian in the enterprise setting is plenty profitable for some other people.
The only thing that really happened is that MySQL cleaved off a part of their business and gave it away for free to anyone who wants it. And I'll bet plenty of people do.
"Generic Linux"???
Isn't "Linux" "generic" almost by definition. The only differences between packages are choices and package manager and usually only a few homegrown eye candy pieces.
No really, I'm not trolling. I'm serious. I've used all sorts of different "distros", Redhat, SuSE, Debian, Slackware etc and I am able to quickly move between them because at the core of it, its all but the same. And I'm not a Linux expert by any stretch of the imagination, so if I can manage, why can't the big boys who do nothing but Linux?
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
> I don't know that you would make any money, but at least you'd be offering something that isn't currently offered.
I doubt it. And more important than my opinion, MySQL doubts it and has the sales figures to show it. Companies don't normally kill off profitable products and services, not even evil/stupid corporations.
Democrat delenda est
Why is this such a sore spot for so many people? Just because MySql no longer supports the flavor of the month distro of Linux, you all throw up your hands crying 'I never liked you anyway'.
The vast majority of mysql users will never buy a support contract, and those few who do, will probably be RedHat or Suse. (When was the last time a Debian user admitted he needed help for anything?)
Instead of having to support dozens of distros, Mysql is supporting the main two. It may be Open Source, but it's still a business.
D
The first, last, and only tech news site on the net
...or switch to the excellent Postgres which is more open and a more complete SQL implementation than MySQL anyway.
Expect to see more things like this happening as the IT landscape undergoes it's coming changes.
So now they just have to drop RedHat and SUSE and we are finally done? Great!
I've been getting kinda tired of the whole cult surrounding MySQL's substandard "RDBMS".
sic transit gloria mundi
Who is actually running MySQL Enterprise?
Chances are that if you need the support they offer, then you are not just running some little fan site using MySQL to store what avatar's people choose. Most likely if you have support for the db, chances are you probably have some sort of support contract in place for the OS as well and the rest of your critical infrastructure. You are probably already playing by their rules using certain OS releases, etc...
That would be my guess at least.
This looks liike an opportunity for Postgres to come out with some better documentation on installation and configuration of Postgres and attract some new users.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
SUSE and RedHat are also the only IBM supported distros. Is IBM going for MySQL, ala Oracle grabbing Innobase and Sleepycat?
-BA
Mmm fork MySQL? Why? There is nothing wrong with the code. You could try to fork the support and start a company specialized in MySQL support on Debian.....
:-) Anyone in? ;-)
I think there is a market for this. The only thing you need is a couple of good people. You/we(the community) could also create a company GPL style. Create a pool of people willing to devote there time on solving MySQL Debian support problems. Create a ticket like system and assign questions to people in the pool.
This way you can quickly create a non-profit company with little to non investments. The biggest "problem" is that you have to attract people willing to become part of you expert pool.
While writing this, it might even be a good challenge to start this..... I will think some more about this.
Regards,
Johan Louwers.
Regards, Johan Louwers.
I believe you forgot a few steps...
3. ????
4. Profit!!
Its an odd business plan, but it always seems to pan out in the end.
MySQL (the support company) no longer sells support for Debian.
It seems to me that this decision must be driven by sales or market research indicated there is no market for support contracts on Debian based systems. So, does this challenge the notion that OSS can work in a capitalist world when the real "product" is support?
Debian based distros are a significant chunck of the Linux market|mindshare. This decision essentially means the combination of Debian + MySQL is doomed in the business setting.
On the other hand, this does seem to show that there IS a market for support on RH based distros.
In fact, as I think about it, I think what this is really saying is that they want to support MySQL, NOT the underlying OS. Perhaps they have some data that shows that many of their support calls are really for the OS or other parts of the system. In making this decision, they don't rope themselves into having to support anything but MySQL. They can answer a non-relevant (to them) call with "oh, that's an OS issue - call your OS support provider." I'd say that's fair.
It also helps them when there is a problem with MySQL on a client system...THEY can call RH (or whomever) support to make sure everybody gets things 'right.' No, the more I think about it, the more I think this actually strengthens the "give away the software, sell support" model.
Computational Chemistry products and services.
MySQL has varying levels of support for different versions and architectures.
The linked support list was to the Enterprise version, but check out Cluster and MaxDB versions.
Oddly enough, they claim FS - full support for Debian 3.0 on the PowerPC architecture.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
The real problem?
"MySQL Quietly Drops Support..." ?
Ok - so what should they do? Place posters all around your city saying "WE DROP SUPPORT FOR DEBIAN USERS!!!"? Yeah - that would be a great marketing move. Get real - they don't want to go on with Debian support dept., then it's their choice. They're creating a place for a new company, that will do support for those who want it.
There are a lot of calls here to fork the code. I'm a bit wary of calls to fork a project by people who lack the reading comprehension to understand the project. These may not be the best people to direct a project :)
Just to clarify the crappy summary, MySQL are not saying that their software won't run on Debian or Ubuntu or whatever... It will still run on most OSs and distros, but if you are using Linux, MySQL AB will only sell you a support contract for MySQL if you are running on Dead Rat Enterprise Linux (RHEL) or Novhell (SLES?).
Get it? Got it? Good!
Do many mid-size to large (read shopping for juicy support contracts) enterprises use Debian?
SO, essentially they are giving you no Linux distros that are totally known for their freedom. Only Red Hat and SuSE for Linux flavors and Solaris, AIX and Windows for the others. Really dumb guys, but not really that much of a concern. Someone else can step up and support MySQL. No big deal in the long run I guess except it gives people less choice initially if their job requires them to have a support contract and believe me alot of companies require this as silly as it sounds. What I see happening is some other Linux company will step up and support MySQL as well as their OS.
Gorkman
The "who do you sue" line's as old as the hills and, largely speaking, irrelevant because you're never
going to get to first base unless it's a screw-up of epic proportions. Even then, it's more likely to
be a colossal waste of your time and merely an exercise of fattening your lawyer's wallet.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Wow, i am very happy about this!
:)
As a Database Programmer (and erstwhile DBA) i am saddened by the haphazard mySQL being called a database. For a while it didn't even support transactions. It's actually more of a storage system with a quai-SQL front end.
By dropping that facade from Debian people might be more inclined to use a real database such as PostgreSQL, which has been in the background for much too long.
For the quality that Debian stands for, from my PoV, this is a very good thing.
I would talk of progress here, but Progress is by far the absolute worst database system i have worked with.
Have you read my journal today?
But if the MySQL coders are still doing good work
What do you mean by still? It makes you sound like you are trying to claim MySQL was not a fucking toy database for girlymen.
Deleted
For example, when I was a kid a local pizza delivery chain started delivering breakfast pizzas. They made money hand over fist. But after a few months, the calculated that the additional cost of maintaining a third shift of workers and an expanded breakfast menu would bring in more money if put into opening additiona stores serving the traditional lunch, dinner, late night crowd with the normal pizzaria menu.
Most likely what is happening is that the MySQL corporation finds that if it spends the same number of dollars training a support tech, those dollars bring in more money if the tech is dedicated to Redhat and/or SuSE than if the tech is also trained on Debian. This doesn't mean that there is no market for Debian support. It means only that MySQL has a higher relative profit from supporting just two databases. The calculation may be different for another company that has a different resource pool. For example a company that already supports Debian Linux, may have a very low marginal cost for adding MySQL on Debian support and, consequently, have a far higher ROI for supporting MySQL on Debian.
It makes sense though when you think about it. How many companies are out there looking for a support contract for MySQL but aren't using RedHat, etc? Considering that supporting Debian could entail supporting several different specific flavors, it doesn't really seem like the revenue for it would be worth the complications.
Presumably if there's enough of a business for such support, somebody will come in and fill the gap. That's the beauty of open source, non? You can actually get support from somebody other than the originaly developer. If it was Microsoft refusing to support some old version of their software, you'd be up a creek.
This sig has been temporarily disconnected or is no longer in service
. . . without the ability to buy support from MySQL for it, that is. Third parties, system integrators, etc. will continue to support whatever their customers pay them for. So while this is a blow for Debian in big enterprise, let's face it, how many big enterprise environments were running straight Debian in the first place? Red Hat's king with SUSE buzzing around their ankles. This won't affect small to mid sized organizations with outside IT people.
Postgres is getting faster, too. With SQLite and Postgres, I find the obvious uses for MySQL to be shrinking and becoming more dubious.
Funny and true. Great reply.
LOAD "SIG",8,1
UBUNTU ! Why Hath Thou Foresaken Me ? Have I no creed ? Have I no substance ? Am I not a ...woman ?
It may not be an ACID compliant transactional DBMS. It certainly isn't a fully relational DBMS. But the definition of a database is pretty much a system for storing data which MySQL certainly qualifies as. And if we're going to start being pedantic, we also have to consider that none of the mainstream enterprise databases are truly relational. While they may have many relational features, none can consistently enforce proper relational behavior. In fact, any database that fully supports SQL cannot be a fully relational database. The only difference between Oracle, SQL Server, DB/2 and MySQL is one of extent, not of kind.
Besides the obvious Suse and Red Hat who's the third "premium" linux? I'd say Debian is not it, but Ubuntu sure has the resources to be #3.
Who do you think will be the top 3?
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
I've been using Mysql for many years, through several companies, small and large. Never once has mysql support ever been requested / needed -- it's rock solid. What does support conist of anyway, help with sql syntax?
I doubt most Debian users will care.
As opposed to.... what? Windows? VMS? Solaris? Your Mother?
I'm pretty sure that all operating systems, at some point, are hacked together by collections of individuals. How "craptastic" they are may have some variation, but I'd guess that, out of the hundreds of people who worked on Linux, some were "craptastic." Same for Windows. Same for VMS, the BSDs, etc.
I can't tell you if, by and large, the people who worked on any particular OS are "craptastic."
But you sure are!
Ba-ZING!
The other explanation would be that Debian has done something to seriously piss the MySQL people off (my speculation).
I *know* that they went this way with the Seamonkey crew. Here is a reproduced Newsgroup response from a Seamonkey developer on the subject of Debian and Iceape (the previous thread entry is in italics and the developers response is bold:
The "SeaMonkey" trademark is held by MoFo, but AIUI, they allow the Council to grant people the right to use it.
Well, MoFo applied for the trademarks, but doesn't hold them yet, as they've not yet been granted. They applied for them representing us though, and they will leave management of the trademark in the hands of the SeaMonkey Council.
But AIUI, Debian has moved past caring about using MoFo's trademarks.
And AFAICT from this thread, the level of bitterness on the SeaMonkey side seems even higher than in the Mozilla community in general.
That may very much be true, as they pre-judged us of being the same as MoCo and not even listening to what we wanted to say. Us being legally backend by MoFo was enough for them to not even really discuss this topic, i.e. not even asking what the terms for using the SeaMonkey trademarks would be.
And their choice of name for the clone they are shipping is an insult in my ears anyways, but that's just my personal opinion.
BTW, I really think their inconsistent treatment of trademarks is enough reason for not understanding them anyways. Their own trademarks are protected with one of the strictest possible policies (no use except explicitely granted by Debian) and then they accuse other of being too strict - and it seems some of their responsible people have not yet understood that trademarks and copyright are two completely different things legally.
Anyways, for me, that discussion is over and Debian itself is dead meat in this regard for me personally (note that ubuntu even departs from Debian's path for MoCo trademarks already).
Elsewhere in the thread, IceApe was described by the same person as a 'Crappy Clone'.
Mielipiteet omiani - Opinions personal, facts suspect.
>Companies don't normally kill off profitable products and services, not even evil/stupid corporations.
I'd have to disagree with that. I've watched three large companies for whom I've worked -- all Fortune 500 companies -- kill off profitable products and services that were not as profitable as they wanted. The company I'm working for right now sold off three business units because they didn't have a profit margin above 30%. We're only keeping the parts of the company that can beat 30%: if you don't, you're out the door. There are probably a lot of fields where companies can't afford to throw away marginal profit, but there are plenty of fields where it's not worth chasing chump change when there's a 50% profit margin to be hunted down and seized.
If that's the case, it's quite possible another, smaller and more agile, company could live very comfortably on the profits from this discard.
Nostalgia's not what it used to be.
I don't really blame them for focussing on enterprise level versions. It fits the "Do one thing, and do it well" philosophy. However, I also can't help feeling that they're shooting themselves in the foot.
When our name is on the back of your car, we're behind you all the way!
Debian has quietly lost all its users to Gentoo and Ubuntu.
I'm going back to flat text files.
j/k
Only in WoW...
Yes, I know, there goes my Karma.
Huzzah! Let me rephrase the question: "Besides the obvious Microsoft, who is the second or third premium Windows vendor"? There is no law or rule that says there must be three or even two premium Linux vendors used by the IT industry. In the end, Novell Linux will likely get more help from MS to be the number one leader. RedHat might die off or just become so irrelevant that it won't matter. Whatever the case, the last thing Microsoft really wants to see is a strong and unified Linux community. The way I see this playing out is that businesses begin to tepidly embrace Novell Linux which increases their market share. The developers who work on high profile projects (like Gnome, KDE, MySQL, etc...) are more and more driven by the business needs than the original "itch" that needed scratching. So there are some forks on major projects... However, the non-premium versions that come out of these forks have a lot of difficulty in attracting talented developers as they are mostly busy working on the premium versions that were part of the old guard Linux camp. There are good developers who would work on some of the forks, but not as many as there were previously. Therefore the forks are buggier, more prone to security holes, and in general don't work as well as the MS blessed versions from Novell.
This is part of Microsoft's campaign against what they term "hobbiests". I use Linux both at work and at home and although I find the term hobbiest insulting, that is what people would probably consider me. I find the uses that I apply Linux to at home to be quite serious. Calling a professional IT guy who uses Linux at home for day-to-day stuff a hobbiest is akin to calling an electrician or plumber who does work on his house an amateur. The fallout that I see is that potentially in another four or five years, I may find it very hard to use Linux at home unless I want to buy into the commercially blessed versions. And if I do buy into them, I'll have a second rate Linux that makes Windows look good. (You know that MS won't allow any MS blessed Linux to outperform or outdo Windows in certain key arenas) If I continue to try and use the non-premium Linux distros I'll probably find that support for new hardware and functionality is just as bad as it was in the early days because the developer mindshare will not be there. At least that's what I'd term a worst case scenario.
In reality it probably won't be THAT bad, but it will hurt. Even though the code is free/open for many of these projects, I've seen what a lack or very low count of talented developers can do to slow down or kill an otherwise decent project. We all have. It's likely that I'll be able to use non-premium Linux at home in the future, but not without even more headaches and hassles than I experience today. The premium versions will likely offer a better experience but always at the expense of being a step or two behind Windows (which is not the current situation). MS is likely doing this because they see that Linux has already surpassed Windows on many fronts. It's more clever maneuvering from MS. If only the FOSS world could think that way sometimes...
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
I think it fair to say that Debian is the second most popular Linux distribution for web servers surveyed by Netcraft. It's also probably fair to extrapolate this to mean that Debian is the second most popular Linux distribution among all web servers. But I think it it quite the unwarranted stretch to take that to mean that Debian is the second most popular Linux in any market segment. I have no reason to believe that use of Linux in the business desktop, development database, database server, or application server follow the same trends. They may very well follow the same trends, but until someone studies the question and offers a cogent analysis that question has to remain unanswered.
Not sure what the big deal is. The Linuxscape has always been a fragmented land-of-a-thousand-distros, and contrary to received wisdom, they're not all compatible.
Having just wasted a few days trying to get one bit of "Linux-compatible" software to work on another subtly different flavour Linux (thankyou RedHat for your borked gcc 2.96), I have some sympathy for saying "we only support flavour X".
Is there such a thing as one Linux distro to suit all users? Probably not. Could there maybe be 2 or 3 that would suit virtually all users? I think so. This move from MySQL seems like a step towards that.
well - interesting news. i have an existing support contract and they answered my support request today. having said that, i've never had a support issue with (the excellent) mysql support guys that was at all related to the OS.
fyi: if you run anything like a large site (we sustain 4000qps most of the day), i would highly recommend a support contract with them. it's very cheap for 24/7/365 access to the devs.
atleast it has decent support for transactions, key constraints, and procedural languages.
Mandriva is probably the next largest distro to offer an enterprise distribution with a long support cycle. I had heard that the next version will be based on Debian, though their current ones are not (Mandrake Corporate Server).
Ubuntu's dapper also has an enterprise worthy product lifetime. Isn't it something like 5 years of updates being offered? Quite impressive for a free download.
Seems a Debian based distro will indeed be #3 one way or another. However, it may continue to be a distant 3rd.
Solaris is probably where it is at as far as having another choice of open source UNIX with enterprise support.
While it wouldn't be suitable for something like slashdot with a lot of concurrent reads and writes, a lot of little things for which mysql is really overkill could use sqlite. It's built into php5.
Loose lips lose spit.
Why bother with RDBMSes at all?
;-)
Skip a generation and go with a good XML DBMS. Something like eXist perhaps?
Chaeron Corporation
...to join the list of supported distros. I hope it happens soon...
Regarding SCO: Here's what Marten Mickos said.
Take with as much or as little salt as you desire.
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
works on almost every Ubuntu system
Haha...that's the best one ever!
Boy that's for sure :(
:(
USB subsystem changes between SUSE 10.0 and 10.1 produced some spectacular driver failures. New elements inserted in the middle of USB data structs in a point upgrade of a "stable" kernel?!?!? What is stable about that?
The Linux development and distrribution process has a LOT to learn about system stability. Expecting EVERYONE to ALWAYS be 100% current and recompile EVERYTHING for EVERY distro and then NEVER updrade an installed kernel or libs again (you know to fix bugs or security holes?) without chancing having to rebuild the entire universe or suffer random breakages is completely and utterly wrong headed.
This may have been fine in the good old days of "install and forget". But these days with the need to be CONSTANTLY up on security patches, it's become quite a nightmare to maintain a linux box for any length of time without having to do a complete reinstall because of unresolvable incompatibility problems between the Kernel, libs and software. Doing it by hand is a major recipe for disaster, but even keeping up with a distro's precompiled sets of upgrades is a crap shoot and has resulted in serveral system failures.
Linux needs stability in a BAD way.
Contrary to popular belief, coding is not all free blow-jobs and beer. Those things cost MONEY!
But if you start out spooning and things heat up a bit, it can quickly turn into a good "sporking"!
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
Gentoo is a trap for the overly technically zealous...
Gentoo was created to keep them out of the "proper" distributions. They will spend the vast majority of their time compling and recompiling their software hoping for that mythical extra 1% of performance that they never get to take advantage of before the next time they recompile.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
Well the OS vendor could offer support for MySQL, if they don't already. Debian isn't a company so you couldn't get it there, but Canonical could offer support for MySQL on Ubuntu. They could charge more for the extra service.
I've used Progress for the last eleven years (started with 6.x, don't quite remember) and I just love the way it just keeps working. No need for a DBA to keep the database happy. And the 4GL, oh, the wonderful 4GL. It really doesn't get the credits it deserves.
That said, I'm available for freelance Progress work... ;-)
!ERR: Signature not found.
I got a feeling it's exactly the same every time Debian Legal and trademarks meet:
"We want to put trademarked software $foo in Debian"
DL: "Cool, we'll package it up and apply any patches we need"
"Umm, what patches?"
DL: "Well, whatever we feel like, security patches for example"
"You'll have to run them by us"
DL: "No, we won't or at least we won't accept that as a requirement. DFSG."
"Look we got to control our trademark, but what if we gave Debian a license"
DL: "No, it has to be free for everyone. DFSG."
"Look we can't let everyone do whatever they want, because then there'd be no trademark."
DL: "DFSG violation. We need to rip out everything about $foo and rename it $bar."
"..."
Of course, if they really followed through on that they'd miss a few things, like a kernel etc. but it seems that's how they'd *really* like it to be.
Live today, because you never know what tomorrow brings
That's the name of the distro, not Debian Linux.
Penny - plain text accounting
I'm game for that :-)
To be, or not to be: isn't that quite logical, Slashdot Beta?
Install RedHat on a spare machine / vmware.
Move your database to the temporary system.
Reproduce the problem.
Contact their support team.
Since when debugging things your going to be using the offline system anyway ?
MySQL is an Open Source project, correct? Yes.
that being said, is it the "Open Source" project which is only supporting these distributions?
The link takes us to a link for MySQL Enterprise. Since MySQL AB provides contract based service for MySQL, this is one way MySQL generates corporate cashflow which allows them to continue to work on MySQL.
Unfortunately, corporations have limited resources called humans who aren't always as zealous or passionate as people involved in an Open Source project. Therefore, they pick and choose which path to follow the money trail not their passion.
The concept of Open Source is not the same as the traditional monetary based business model.
Scientia et Potentia
LOLOLOLOL Funniest comment today.
I suppose you are an expert in database design and programming? Wanna start writing a cost based optimizer? How about an obfuscation toolkit? Or even better, write a new writer process that can perform writes to multiple database files based on requests over a network connection?
ROFLMAO!
If you mod me down, I *will* introduce you to my sister!
That reads something like: "We proudly support Redhat, Suse, and Scox."
It would reasonably assumed that they don't support anything else.
I have a better idea...why don't you go fork yourself!
(I couldn't resist!)
If you must!
First, by support the article refers to technical support contracts, not whether or not the software will actually run on Debian. And MySQL has decided that they will provide technical support only for a very limited subset of the popular Linux distros. As far is this issue is concerned, Debian is in the same boat as a lot of other distros and was not singled out for special treatment.
Second, the Mozilla trademark issue was at its core unavoidable. Debian has to be able to say to its derivative distros that everything in "main" is really free, Mozilla had copyrighted images that were NOT free, so Debian couldn't use them and Mozilla responded by saying they had to rename the browser. So they did, and the Mozilla-branded browser remains in "non-free" due to the copyrighted images. Everyone accusing Debian of hypocrisy on the trademark issue because they have an official logo is (to be blunt) wrong. Debian has an official logo (that they hardly ever use) to provide legal recourse to stop anyone else claiming to be Debian. It is otherwise of no use in the project and does nothing to prevent derivative distros from doing their own thing when they want to.
Incidentally, the Mozilla trademark dispute has caused me to reinvestigate my use of ALL software from Mozilla. I'm finding that KDE software is far more user-friendly and powerful than the Mozilla software across a number of applications. KMail can be made (rather easily) to store mail in ~/Mail in mbox format, its mail filters execute much faster, I can right-click -> "Create Filter" -> "Filter on From" in seconds, and in dozens of other ways it kicks mozilla-mail's ass. Likewise KNode, Konqueror, and Kontact.
The real question is what this will mean down the road. While the support contracts are soley for paying customers (who as it has been noted would probably be on supported enterprises anyway) that still directs the future of the DB.
The Mysql support staff are still a major force in the open-source aspects of the Database submitting bugs, patches, etc. If they cease doing Q&A on other distros then either the rest of the community will have to pick up testing their patches. Over tim I expect that this will, at least, bias the systems patchsets in favor of the "supported" distros.
The real issues won't show up today but 2 to 3 years down the road.
I personally do not agree with the 'Support Licensing Scheme' business model or services offered by these vendors trying to capitalize from the open source software development model.
However, some Managers do (generally those who talk more affectively than they manage IT), and most of those Managers will be using SuSE and/or Red Hat, as they would much rather pay some vendor for support, rather than face accountability issues when the ish hits the fan.
I had a similar debate w/ our CTO regarding the matter, and of coarse, he chose RHEL over Debian. Most of it came down to the issue of vendor support, whereas I felt that I am paid to be the support tech, so why pay them as well.
I guess the real question here should be: Why would a debian admin need to pay for support when he/she is (usually) experienced enough to find most of the answers on their own??
the only permanence in existence, is the impermanence of existence.
MySQL began supporting Unbreakable Linux.
Check out my lame java blog at www.javachopshop.com
Fork you.
Jesus was a compassionate social conservative who called individuals to sin no more.
I suspect that MySQL (the support company) took a look at the number of customers they had and compared that to the number of customers using various distributions, then made a business decision to offer support to the customers that made up the lion's share of their business. If they see that 90% of their customers use RHEL or Suse, then perhaps it simply cost them more money than it was worth to continue offering support for the small fraction of their (support) customers who run MySQL on Debian, Slackware, Gentoo, Ubuntu, etc.
IMHO, it isn't really a problem because, even though I've used MySQL personally and professionally for something like six years, I've *never* needed support on it. Let's face it, my Slack and Gentoo servers aren't "supported" either, nor is my Apache installation, my Postfix installation, my Bind installation, etc., etc., etc.--except by me, and so far, that's been good enough.
MCSE? No, sir...I don't do Windows. Yes, I am an idealist. What's your point?
I guess the REAL question is why would a business rely on one person to support their entire network? What would happen if you got into a car accident on the way to work tomorrow? The next admin may not be as knowledgable as you, are they suppose to start all over again with a different distro? One the new admin knows? By using a product with support included they are assuring that if anything happens to you they can still get the support they need. It's better to have a support contract and not need it than to need a support contract and not have it.
However, I really like 4GL for business logic. I really hate PL/SQL for that. I just finished a project building a large data warehouse in PL/SQL and that's something I'm never going to do ever again.
Next project will be Perl + Postgresql, quite look forward to that! ;-)
!ERR: Signature not found.
postgres recently came out with a new version and I don't think /. even covered it.
What gives?
evil is as evil does
Yes but it doesn't have what people REALLY want. Replication, clustering, failover, case insensitive where clauses.
If you want high availibility you have to cobble together slony and pgpool (which does not support multi master replication) neither of which is suitable for working over a WAN.
There is a reason why people choose MySql and that's because it delivers the features people really want first. Even the features are not 100% "correct" they are delivered "good enough" to get "real work" done.
Take case insesntive where clauses for example. For the last five years or so that I have been following the pg mailing lists there must have been hundreds of requests from people who want to switch over from mysql, ms-sql, oracle, informix, firebird etc for a case insensitive collation option. They just get ignored and told to change all their queries to use ILIKE or *~ or some other stupid non standard postgres only SQL. Oddly enough their primary excuse for not providing it is that it's not a SQL standard.
So if you using any kind of an ORM and you can not stomach asking your employees or web users to remember the exact capitalization of everything they have ever typed into your database then postgres is not an option.
Sorry.
evil is as evil does
Further, your post reveals an astonishing arrogance combined with a complete lack of comprehension. I'm just not certain whether it was a complete lack of comprehension of my earlier post or a complete lack of comprehension of what a database actually is. My guess is that it's the former.
A database is no more (and no less) than a container for the storage of data. MySQL is no less of a ``real'' database than latest and greatest from Oracle and IBM. The variation lies only in the features needed for a given application. You're basically arguing that supporting certain types of enterprise class features makes databases from the big vendors more of a database than other databases. That simply isn't true. That's like saying that a Cray supercomputer is more of a computer than my venerable old Palm Pilot. The truth is that both are equally computers but that they were engineered to meet entirely different sets of needs. They vary in complexity and capacity but they don't vary in their computerness. The same is true of MySQL and Oracle.
Yes, they did cover it.
--
Promoting critical thinking since 1994.
My company has a MySQL Network Platinum support contract on 2 Debian servers (which I guess is now called MySQL Enterprise). I contacted MySQL today, and they told me that they are NOT dropping support for Debian. All this means is that they do not have .deb packages MySQL Pro on Debian or Ubuntu -YET-. Their generic Linux tarballs will still install with no problem in Debian, and they will still continue to support users on the Debian/Ubuntu platform.
.deb packages for Debian AND Ubuntu.
.debs, until then you can simply use
But here's the best part...
He also indicated that MySQL is in the process of creating Pro
So not only is this article inaccurate, it's actually 180 degress opposite of accurate. They're not dropping support, they're increasing it.
Here it is straight from the MySQL reps email:
"It is not yet fully supported which simply means that we do not yet have official
enterprise binaries for this platform. We will continue to provide the same level
of support and we hope to have both Debian and Ubuntu packages in the near future.
I will let you know when we have enterprise
the 5.0.30-enterprise generic linux tarball package."
I tend to believe MySQL.
I know IBM and other vendors have clusters available for developers to do test ports.
Is there any sort of facility for mapping a project source tree to multiple distribution builds? Sort of a meta-ant for the different vendor packagings. If the efforts to standardize the Linux distributions was effective, the build and bundle should be the only real difference anymore. Especially if you were sticking to POSIX APIs for the core OS services.
DRM can be turned on it's head. Each developer in charge of an OSS project could use such a build cluster, maybe hosted or supported by various vendors or a .org. The build manager for the project would effectively sign the source and binaries, then the various distros would be responsible for integration test and rollout.
I do not fail; I succeed at finding out what does not work.
first, people say forking is good, then they complain that vendors won't support unlimited forks. YOu can't have it both ways.
Who do I contact at PostgreSQL there to buy their support? Oh. They don't sell it. You seem to have missed the point of this: it's about the developers of the database selling support with service level agreements and contractual service obligations for what they produce. PostgreSQL doesn't do that at all, for any platform. MySQL does.
Like PostgreSQL, MySQL also has third parties like Red hat who sell the server and also sell support for what they build. Those partners can escalate issues to the MySQL support team if they encounter a problem they can't deal with. All with contractual service levels and warranties for both what they deliver to their customers and what MySQL delivers to them.
Mailing lists are great. They aren't the same as MySQL having someone who knows the server around to answer the phone 24/7 to deal with an emergency, who has the phone numbers of anyone in the company who they need to contact to get a problem resolved.
> Except that Red Hat and Suse are not entirely open source.
Suse has had a spotty history, having several closed components for most of its history, becoming mostly Free after being bought by Novell and now with the Novell-Microsoft deal who the hell knows where they are going next.
RedHat on the other hand has always had a Free core distribution. In the past they have experimented with selling closed addons (Motif, Applixware, etc) and even had a couple of closed things in their boxed distros (a browser called Red Baron and a commercial X server) but long since dropped all that nonsense. No version of RHEL has any dependencies on closed source components. Paid media sets do include an "Extras" CD with the usual suspects (JDK, Flash, Acroread, etc) and there are a fair number of vendor supplied closed device drivers for RHEL, but nothing closed is required to install unless you have one of the pieces of hardware that require a driver, such as a SCSI controller.
There isn't anything with a RedHat copyright that isn't released under a license that passes the DFSG. They don't officially make binary packages for RHEL available but every SRPM is up on the mirrors and full installable binary rebuilds are available from a variety of 3rd parties. What more are they expected to do to avoid the "Microsoft of Linux" moniker?
Bitch about their engineering decisions, the quality of their support, etc vs other vendors. Reasonable people can disagree on any of those subjects, but the non-free rumors need to be put to pasture.
Democrat delenda est
I can feel my karma taking another bruising here, but what the hell.
Debian want to fork all and sundry, or at the very least create internal patchsets for pretty much everything they get their hands on, and then people don't understand why they don't get support from upstream vendors?
Said people might support their own applications, but they are under no obligation to support Debian's own non-standard, patched versions of their apps.
On a related note, I had my last negative compiling experience with Ubuntu the other night, and as a single individual at least am hereby boycotting Debian and its' derivatives entirely. The reasons are too numerous to count, but are both technical and political.
As a positive alternative, I advocate a rennaisance of Slackware. It's a clean, sane, non-fragmented distribution. It doesn't use any seriously concrete form of package management by default, meaning you're free to choose your own...and it also by extension doesn't use a particular, unholy form of perverted evil known as subpackaging. It also doesn't see Linux's heritage as a UNIX clone as something to be ashamed of, or a hindrance to the goal of creating a perfect imitation of Windows.
Going back to the parent topic, Slackware would also likely be great to use as a standard for vendors such as MySQL, *because* the Slack developers largely abstain from downstream patching, (at least AFAIK) and as mentioned are package management agnostic. Hence, it'd be a very easy distro to support.
If anyone here hasn't tried Slack themselves, I thoroughly suggest it. You can look forward to a level of transparency and reliability you'll scarcely find anywhere else. It's a form of Linux which isn't afraid of being itself, and that tragically is a very rare thing these days.
"Yes but it doesn't have what people REALLY want. Replication, clustering, failover, case insensitive where clauses."
Yes, yes, yes, and yes. I realize you are just trolling, but I will still point out the facts so that you don't breed new mysqltards.
There are a few replication options, that's trivial. Clustering and failover are provided by pgcluster. Case insensitive where clauses are provided by ilike, as you already know.
"There is a reason why people choose MySql and that's because it delivers the features people really want first. Even the features are not 100% "correct" they are delivered "good enough" to get "real work" done."
Most people I know who use mysql do so because they are using some shitty software that requires it, because they didn't know there were other free DBs, or because they are doing some high performance task where data safety doesn't matter, so they are using the fast myisam tables.
"Take case insesntive where clauses for example. For the last five years or so that I have been following the pg mailing lists there must have been hundreds of requests from people who want to switch over from mysql, ms-sql, oracle, informix, firebird etc for a case insensitive collation option. They just get ignored and told to change all their queries to use ILIKE or *~ or some other stupid non standard postgres only SQL. Oddly enough their primary excuse for not providing it is that it's not a SQL standard."
No, only from idiots who think "a" and "A" are the same thing. If you want to do a case insensitive comparison, use ilike or use upper() or lower() (depending on the circumstances).
"So if you using any kind of an ORM and you can not stomach asking your employees or web users to remember the exact capitalization of everything they have ever typed into your database then postgres is not an option."
Really? That's why thousands of people use it and have no problem at all with case insensitivity right? Being case sensitive is normal behaviour. If you want to check an email then do lower(email), this is basic stuff people learn in their first ever foray into SQL.
"There are a few replication options, that's trivial."
Really. First of all I would hardly call slony trivial. It's a bitch to set up. Secondly it does not support multi master replication. Finally it's not asyncronous and should not be used WANs.
"Clustering and failover are provided by pgcluster."
Pgcluster does not work over a WAN. Pgcluster is not a part of postgres it's a separate product.
"Case insensitive where clauses are provided by ilike, as you already know."
Ilike is not an SQL standard. If you have hundreds of queries already written then you have to rewrite every single one of them to use ilike. Ilike is slower then where x='y'. I don't know of any ORM on the market that uses ilike this means you can not use hibernate, activerecord, etc.
"No, only from idiots who think "a" and "A" are the same thing."
Unfortunately for postgres that's most human beings on the planet. That's why virtually every single database on the planet gives you the option of a case insensitive collation except postgres. Oracle, DB/2, MSSQL, Mysql, firebird, informix, all have that option. Postgres does not.
"If you want to do a case insensitive comparison, use ilike or use upper() or lower() (depending on the circumstance"
In other words stop using an ORM and write all all your queries by hand. If you are not using an ORM and are porting an app from mysql then rewrite every single query that has a where clause to use upper and lower.
"Really? That's why thousands of people use it and have no problem at all with case insensitivity right? "
Yes thousands use it. Alas millions use oracle, mysql, mssql, and db/2. As you may have noticed postgres is not the most popular database. There is a reason for that.
"If you want to check an email then do lower(email)"
Hey I have another idea. I could just use mysql, firebird, oracle, mssql, informix, db/2 instead then I would not have to rewrite all my queries.
I do have a question for you though...
How come the postgres developers feel fine about completely ignoring the hundreds of requests they have had for this feature? Every other database has it so why not just write a new collation? Is it really that hard?
I'll answer the question for you. No it's not that hard. The developers are arrogant pricks who feel fine about non standard SQL like ILIKE and *~ when it suits them but throw a knipshin about standards when somebody asks for a case insensitive collation.
People have been asking for this for years now, just google their mailing list. They just don't give a shit. If you want to know why people are choosing mysql instead of postgres there is the answer. Mysql is more responsive to their users, postgres developers don't give a shit. They do what they want not what their users want.
evil is as evil does
"Really. First of all I would hardly call slony trivial. It's a bitch to set up. Secondly it does not support multi master replication. Finally it's not asyncronous and should not be used WANs."
Hmm, I must just be so super awesome then since slony doesn't seem to be so hard to me. Replication is master->slave. That is the definition. Master-master is clustering, which is what pgcluster is for (shocking I know). And if you want async replication then use async replication (rserv). Why do you think a sync replication package not supporting async replication is a problem?
"Pgcluster does not work over a WAN. Pgcluster is not a part of postgres it's a separate product."
Oh of course, you are doing multi master clustering over a WAN using mysql. Just because mysql isn't up front about the limitations of the replication and clustering options, doesn't mean those limitations aren't there.
"Ilike is not an SQL standard. If you have hundreds of queries already written then you have to rewrite every single one of them to use ilike. Ilike is slower then where x='y'. I don't know of any ORM on the market that uses ilike this means you can not use hibernate, activerecord, etc."
Yeah, having to change your queries never happens with migrating between other DBs. Come on, at least try to make sense. If you cared about portability, you would be using upper() or lower() in the first place. Expecting postgresql to support the vendor specific hack you like instead of the vendor specific hack they already have is just dumb. I'm lucky enough not to have to touch java, but the folks at work had no problem with getting hibernate to co-operate for this. Activerecord may well be a problem given that it is a mysql mapping, not an SQL mapping, talk to DHH about his damage not postgresql devs. And why do you think ilike is slower than x='y' in a case insensitive DB? Here's a hint, that case insensitivity isn't put there by magic fairies, that's actually code that has to execute to do that for you. Hiding the upper() from you doesn't make it faster.
"Yes thousands use it. Alas millions use oracle, mysql, mssql, and db/2. As you may have noticed postgres is not the most popular database. There is a reason for that."
Its unlikely that millions of people actually care about what you are talking about. Thousands of postgresql users think you are wrong. It doesn't seem that many other DB users think you are right. In fact, google seems to support the idea that its mostly just you posting this same shit all over the web because you like to whine about not getting your way. I don't care that postgresql is not the most popular. It never will be and that's great. I can't think of any software I use that is the most popular other than apache, and I don't use it because of its popularity. Popular != good.
Yes, I know about those useful options, it's why I mentioned the third party support.
Do those selling PostgreSQL support have service level agreements with, and support backup and software indemnity from PostgreSQL?
Those are some of the things that distinguish the level of support MySQL can provide via third parties, which, so far as I know, isn't and never has been equalled by any support offering for PostgreSQL.
Then there's MySQL's own direct support available if you don't want a third party. How about the ability to phone up whoever they need in the team at home 24/7 if necessary, not just the odd one or two they may have hired?
I'm not suggesting that there's a lack of good support available for PostgreSQL, what I am doing is highlighting some of the differences that are of interest to those who have 24/7 needs for critical business systems. Not everyone needs this, but for those who do, it's available for MySQL and isn't available for PostgreSQL.
Store your data tree as nested tags in a flat file. This should help with searches and sorting.
(going for + funny, not -1 troll)
Crap. What did the new CSS do with the "Post anonymously" option??
Get forked!
Here's a copy of MySQL's official response to this story:
n terprise.html
-----
MySQL's Commitment to Debian
December 13, 2006
MySQL AB apologizes for any miscommunication that may have implied that the
MySQL database does not run on the popular Debian Linux operating system, or
that the company does not offer technical support for MySQL Enterprise
subscribers using Debian.
We have a strong commitment to Debian and other forms of Linux - for both
open source community developers and corporate enterprises.
The Debian Linux operating system is an active, growing and successful
platform for the MySQL database to run on.
Our company offers freely-available downloads of the MySQL Community Server
in source code and binary format at
http://dev.mysql.com/downloads/mysql/5.0.html for Debian and other flavors
of Linux -- including Red Hat Enterprise Linux, SUSE Linux Enterprise
Server, Fedora, Ubuntu, etc. -- as well as Microsoft Windows, Macintosh OSX,
Solaris, FreeBSD, HP-UX, IBM AIX and SCO OpenServer.
For paying customers, our company also offers 'MySQL Enterprise', a
comprehensive set of production-tested software, proactive monitoring tools,
and premium support services.
Since its official launch in October, we have delivered versions of the
MySQL Enterprise Server software for RHEL, SLES and a general-purpose
version that runs on other forms of Linux -- including Debian. Starting in
Q1 2007, we will also deliver regular software updates for the Debian and
Ubuntu platforms as well.
As in the past, MySQL AB continues to offer paid technical support for
customers running MySQL on Debian and other versions of Linux. This is
available as part of our MySQL Enterprise subscription service. A complete
list of MySQL Enterprise supported platforms is available here:
http://www.mysql.com/support/supportedplatforms/e
We will continue to monitor the popularity of other operating systems and
user requests when considering extending our platform support in the future.
Again, MySQL AB regrets any inconvenience this misunderstanding may have
caused.
-----
James Day, Support Engineer, MySQL AB
I've had apps hammering hard on MySQL since 2000. I've never seen any data corruption. Give an example or go home.
Just to be fair to the PostgreSQL support companies, it should be mentioned that the MySQL people don't own all of the code you use - Oracle owns two major pieces.
Your exactly right. At first, nothing really is changing. MySQL will continue to build binaries and Debian will continue to package them appropriately (albeit slowly) into stable release trees, and it looks like some new packages (and changes in meta packages) are in sight 'down the road'.
/.
.. move along ..
The same thing applies to Ubuntu, and every other Linux distribution that actively maintains its packages. Its up to the packagers (as always) to make things available.
Yum / aptitude / emerge (whatever) do not download packages from MySQL , they download packages from whatever you put in their list of sources.
Amazing what people will do just to get a story posted on
This is fud. The story here is that soon better packages will be available as package maintainers begin to include better things from MySQL.
This is FUD. Nothing more to see here, move along
No arguments there! =)
That's the cover-my-ass (to avoid accountability for my lack of management oversight) way to do it.
A) Managers should enforce strict oversight of documentation practices for network admins and software developers, which a lot of places don't do.
B) Developers and Administrators should document their work as they go, so that others can pick-up where they left off, which a lot don't do.
If these processes are already in place, which is usually the case at most structured IT shops, then there should be no reason why you have to rely on the support of some 3rd-Party vendor.
But I agree, it's not a perfect world, and sometimes it's good to cover your arsch! =)
the only permanence in existence, is the impermanence of existence.
"Oh of course, you are doing multi master clustering over a WAN using mysql."
I have done that for years. It's called ring replication look it up sometime. Now mysql also offers Mysql cluster which also works over a wan.
"Yeah, having to change your queries never happens with migrating between other DBs. Come on, at least try to make sense. "
If you are using an ORM then it should be a trivial exercize. Ooops no ORM uses ILIKE or *~ or UPPER() to do where clauses so if you are trying to migrate from mysql to postgres you better forget it. You have to get rid of your ORM and write all your queries by hand. So sorry, the developers of postgres don't really care about that.
"Expecting postgresql to support the vendor specific hack you like instead of the vendor specific hack they already have is just dumb."
But every vendor of databases supports case insensitive queries. Except postgres of course.
"And why do you think ilike is slower than x='y' in a case insensitive DB? "
Does ilike use indexes?
"It doesn't seem that many other DB users think you are right."
Then why do all of them give you the option of case insensitive collations?
" In fact, google seems to support the idea that its mostly just you posting this same shit all over the web because you like to whine about not getting your way."
Really. Over the last five years I am the only one asking for this feature? Google says that? Really?
"Popular != good."
Yes but unpopular != good either.
Here is a hint for you. I need feature X. Every database in the world has feature X except postgres. I guess I won't use postgres.
This topic was about why people use mysql when postgres is so much better. There is a reason for you. Postgres does not support feature X.
evil is as evil does
"So sorry, the developers of postgres don't really care about that."
No need to be sorry, lots of people don't care about that, at all, no really involved.
"But every vendor of databases supports case insensitive queries. Except postgres of course."
Postgres does impliment it, just not the way you want it to.
"Does ilike use indexes?"
Off the top of my head, I couldn't tell you. If not then use the portable upper() or lower() like you should have been doing all along.
"Then why do all of them give you the option of case insensitive collations?"
Users of other databases give you that option?
"Over the last five years I am the only one asking for this feature? Google says that? Really?"
No, google doesn't say that. And neither did I.
"Here is a hint for you. I need feature X. Every database in the world has feature X except postgres. I guess I won't use postgres."
Good for you.
"This topic was about why people use mysql when postgres is so much better. There is a reason for you. Postgres does not support feature X."
And as I said, you don't matter. I am sure this is a problem for you. I am sure your refusal to do things correctly is for a good reason. That doesn't mean its a problem for everyone else, or even a significant number of people. "I can't switch to postgres easily because I relied on non-standard vendor specific features" isn't very compelling. You already chose your database before you made the mess, so clearly the mess is not the reason you didn't choose postgres, its just a reason you haven't migrated to it. A good reason not to migrate I might add. And not a good reason to put bad "features" that shouldn't be there into postgres. Its not GNU software, they won't just add any and every feature anyone ever requests.
Well said. And this is the reason why I prefer Debian over any suse. DFSG.
So did I. I switched to Epiphany and find its bookmarking functionality much more flexible.
"No need to be sorry, lots of people don't care about that, at all, no really involved."
Then why does every other database support it?
"Postgres does impliment it, just not the way you want it to."
No postgres implements a workaround which is not an SQL standard and is not supported by any ORM.
"Off the top of my head, I couldn't tell you. If not then use the portable upper() or lower() like you should have been doing all along."
Because littering your code with SQL is a bad programming practice. Modern programming methods use an object relational layer. You may want to read about them sometime. Oh I will answer the question for you, ilike does not use indexes.
""I can't switch to postgres easily because I relied on non-standard vendor specific features" isn't very compelling. "
Except that I did no such thing, "where lastname = 'McNab'" is standard. "Where lastname *~ 'McNab'" is not. See the difference?
evil is as evil does
True. BDB is largely a non-event on the support side - it's extremely rare for us to get questions about it, since it's largely been replaced by InnoDB. Now it's being removed from the newest MySQL version.
For InnoDB, owned by Oracle, we have the service agreement and phone numbers. Though I know InnoDB so well that I haven't had any need to call Heikki about it. Another person in the support group has regular chats with him, discussing priorities and developments and such. Works well and the rumors of doom when Oracle bought them just haven't materialised: we retain an excellent working relationship.
"Then why does every other database support it?"
Vendor A impliments "feature" designed to lock in customers. Vendor B is forced to impliment it too. Postgresql isn't a company, there is no vendor, so they aren't under the presure to screw up their software.
"No postgres implements a workaround which is not an SQL standard and is not supported by any ORM."
Right, just not the workaround you like. If you want to be portable and SQL standard, then YOU MUST USE upper() or lower(). There is no other option. Just because you are relying on a vendor extension doesn't mean postgresql should impliment it for you. And I don't believe that any ORM sucks that hard, they ALL let you define your searches. If you want to search case insensitive, then do so.
"Because littering your code with SQL is a bad programming practice. Modern programming methods use an object relational layer. You may want to read about them sometime. Oh I will answer the question for you, ilike does not use indexes."
You don't need to litter your code with SQL. You already have to build a where clause. Any ORM will let you put upper() in there, or any other SQL. You can even configure them (hibernate at least) to specify what function upper() is if you really need to. And "modern programming methods" and ORM are miles apart. OO programming is very old, as is the bizzare fetish of trying to mash anything and everything into an OO layer for no reason.
"Except that I did no such thing, "where lastname = 'McNab'" is standard. "Where lastname *~ 'McNab'" is not. See the difference?"
You are ignoring your "be case insensitive" setting. "where lastname = 'McNab'" is standard. And as per the standard, will only return rows where lastname = 'McNab', not 'mcnab'. If you want case insensitivity, then use the also standard:
"where lower(lastname) = 'mcnab'". Duh.
Setting the database to return the wrong information to a standard query means its no longer standard. This should be pretty easy to understand.
As promised in my previous post I would give the idea some more thoughts. Forking MySQL Debian support might not be such a bad idea. MySQL is giving up support on Debian and thereby leaving open the possibilities for this to the community.
The opensource community has proven in the past that they are quite capable of handling things like this. I might even be an idea for a small startup (profit or non-profit) I will post some more info about my idea around this on in this discussion and on my weblog http://johanlouwers.blogspot.com/
Regards,
Johan Louwers.
Regards, Johan Louwers.
Before starting that business, see http://developers.slashdot.org/comments.pl?sid=211 584&cid=17233206 and note that MySQL is increasing its support for Debian, not decreasing it.
MySQL is removing the public downloads for version 4.0, so if you do want a business idea, providing those might work.
"Vendor A impliments "feature" designed to lock in customers. Vendor B is forced to impliment it too. Postgresql isn't a company, there is no vendor, so they aren't under the presure to screw up their software."
Explain why all the open source databases support this feature too then?
"There is no other option. "
Yes there is. It's called collations. It's a standard. Look into it sometime. In fact the SQL standard says you should be able to set collations on a per column basis which MSSQL and firebird support but postgres does not.
"Any ORM will let you put upper() in there, or any other SQL. "
Really? So when I am using activerecord and I call Person.find_by_last_name('mcnab') it puts UPPER in there for me?
"OO programming is very old, as is the bizzare fetish of trying to mash anything and everything into an OO layer for no reason."
Aaaah you are one of those people are you.
"Setting the database to return the wrong information to a standard query means its no longer standard. This should be pretty easy to understand."
You know this conversation reminds of so many I had with postgres users. I remember when postgres didn't support alter table and dickwads like you were saying "there is no need for alter table just use this workaround". I remember when posgtres didn't support outer joins (I do believe it was the last database in the world to support outer joins) and dickwads like you were saying "there is no need for outer joins just your this query instead".
No difference now "there is no need for case insensitive collations just use ilike, *~ or upper() instead". You are wrong. Eventually postgres will implement case insensitive collations or datatypes thereby upholding their long held tradition of being the last database in the world to implement a feature.
Last to implement alter table, last to implement outer joins, last to implement replication, last to implement clustering, last to implement failover, last to implement case insensitive collations. Due in large part to dickwads like you.
evil is as evil does
Just recently, support for Python's connection to MySQL, "MySQLdb", stopped working on Windows. See this discussion in the MySQLdb help forum on SourceForge.
Unlike Perl and PHP, the standard Python distribution doesn't support MySQL. There's a third-party add-on on SourceForge for that. It has one developer, and he's not interested in maintaining the Windows version. The Python 2.5 update apparently broke the Windows build.
Some help is being provided by a World of Warcraft guild, which has managed to build MySQLdb for Windows. But that hasn't been tested by anyone else.
Also, although the current MySQL understands Unicode, and the current Python understands Unicode, the MySQLdb module in the middle is reported to crash on Unicode.
I'd thought something as basic as a database connection for a language used primarily on web servers would be a solved problem, but for Python, it's not.
"Explain why all the open source databases support this feature too then?"
The ones with vendors and customers? How does being open source have any relevance?
"Yes there is. It's called collations. It's a standard. Look into it sometime. In fact the SQL standard says you should be able to set collations on a per column basis which MSSQL and firebird support but postgres does not."
Implimenting collations correctly is more involved than you are pretending. It will need to be flexible enough to support other datatypes besides text based ones. Again, all 2 people that care about this are free to use MSSQL. You are under the impression that because you are one of those 2 people, that there is a huge massive majority of people actively avoiding postgresql because of this. Its simply not the case. Easily THOUSANDS of times more people avoid postgresql because its not a PHB approved corporate supported database. Nobody cares about that "problem" either.
"Really? So when I am using activerecord and I call Person.find_by_last_name('mcnab') it puts UPPER in there for me?"
I sure as hell hope not. I know this is going to shock you, but even activerecord is flexible enough to let you define whatever searches you want, and sane enough not to produce incorrect results by default. If you will only ever search last name in a case insensitive manner, then define find_by_last_name to use upper() or lower(). One of the features people like in an ORM is the ability to let you make customizations like this in a single place instead of all over the place. You still have to tell it what to do, its not magic.
"Aaaah you are one of those people are you."
"those people"? You mean "those people" who use the right tools and techniques for the task? Yep. You mean "those people" who aren't stupid enough to think "littering your code with SQL" and using an ORM are the only possibilities? Yep. Do you normally make stuff up and then fall back on "those people" bullshit when called on it? Or did you mean to say "PHB approved industry standard practices" and "modern" was a typo? Or do you seriously think decade and a half old techniques are modern? Welcome to the 1990s, enjoy your stay.
"You know this conversation reminds of so many I had with postgres users. I remember when postgres didn't support alter table and dickwads like you were saying "there is no need for alter table just use this workaround". I remember when posgtres didn't support outer joins (I do believe it was the last database in the world to support outer joins) and dickwads like you were saying "there is no need for outer joins just your this query instead"."
No, dickwads like me were not using postgresql because it was a pain in the ass, exactly because of the lack of alter table and a few other annoying things that needed to be "worked around". Just because I don't think your fabricated problem is a real problem doesn't mean I think alter table is useless.
"Last to implement alter table, last to implement outer joins, last to implement replication, last to implement clustering, last to implement failover, last to implement case insensitive collations. Due in large part to dickwads like you."
No, due exclusively to the nature of open source projects. The developers impliment what the developers want. If you share their needs, lucky you, you can use their project. If you don't, then don't use it. Pretty simple huh? Rather amusing that you rag on postgresql for being "last to support" stuff though. If you wanted to use postgresql for real, this would not be an issue. You would either use upper() or lower() like you should, or you would install a case-insensitive data type. You just want to whine about postgresql. Feel free to do so, but its not going to suddenly make you important, and its not going to suddenly make postgresql developers do your bidding.
"Implimenting collations correctly is more involved than you are pretending."
Apparently it is very difficult for the postgres developers. No problem for oracle, firebird, mssql, db/2, mysql programmers though. Collations are so fucked up in postgres most languages don't sort properly. Go and search the postgres mailing list for all the complaints.
""those people"? You mean "those people" who use the right tools and techniques for the task? "
I mean those people who rant against OO programing and ORMs.
"If you wanted to use postgresql for real, this would not be an issue."
I will use postgres if and when it has the features it I need and want. So far whenever I have started a project postgres has not been good enough. It's still not good enough. So I use databases that have the features I want.
"You just want to whine about postgresql."
No I am trying to explain to the dickwad fanbois why people don't use postgres and choose mysql instead. Mysql has more features then postgres, features people want. Postgres has lots of features nobody really cares about like *~
evil is as evil does
"I mean those people who rant against OO programing and ORMs."
.1% of mysql users.
No, I simply pointed out that there is nothing modern about it. I personally don't use ORMs because if I wanted to work in an OO style I would use an object database instead of a relational database. Just because I have common sense doesn't mean I "rant against" OO programming (which I use all the time) or ORMs (which have their place). Do you really want attention so badly that you make up random nonsense to try and keep arguments going just so you have someone to talk to?
"I will use postgres if and when it has the features it I need and want."
Like I said, if you wanted to use postgresql you would. You are inventing the most trivial problem, which has several trival solutions. Clearly you don't want to use postgres, so don't.
"No I am trying to explain to the dickwad fanbois why people don't use postgres and choose mysql instead. Mysql has more features then postgres, features people want. Postgres has lots of features nobody really cares about like *~"
You are a megalomaniac. The universe does not revolve around you. Just because you invent excuses not to use postgres, that doesn't mean all the people choosing mysql are doing it for your invented reason. And just because someone disagrees with your opinion, doesn't make them dickwads or "fanbois". You can bitch about this for as long as you want, on as many websites as you want, and get laughed at by as many people as you want, but that will never make your bizzare self absorbed fantasy become reality. Most mysql users don't even know that postgresql doesn't have this, I doubt its affected the choice for even
"No, I simply pointed out that there is nothing modern about it. "
.1% of mysql users."
Well other then the fact virtually every program written today is written using objects there is nothing modern about it all. What a stupid thing to say. You really thought you were trying to say something profound with that?
"I personally don't use ORMs because if I wanted to work in an OO style I would use an object database instead of a relational database."
Ah you are one of those people too.
"Just because you invent excuses not to use postgres, that doesn't mean all the people choosing mysql are doing it for your invented reason."
No they are using for their own reasons. There are features they want the mysql has and postgres doesn't It's not just one feature, I pointed out several that postgres doesn't have, there are dozens more. There are lots of features people want and postgres doesn't offer them so they choose a different database. That's why postgres has such a tiny percentage of the database market. It lacks a lot of really important features people want.
"And just because someone disagrees with your opinion, doesn't make them dickwads or "fanbois"."
No it doesn't. It's how they disagree that makes them dickwads and fanbois. Remember when postgres didn't have alter table? Go back and read the posts about how dickwads (like you!) gave workarounds and pretended that the only people who wanted alter table were stupid and how they were a small minority etc. Those dickwads were making the exact same arguments you are. Those dickwads were wrong. Eventually even the stubborn postgres developers implemented alter table thereby making the dickwads the joke of history. Postgres will one day clean up their collation mess. They will one day implement a case insensitive collation thereby joining every other database in the world. That day you too will be a joke of history and this thread will one day be resurrected by some people looking for an example of how close minded dickwad-ish postgres users are.
"Most mysql users don't even know that postgresql doesn't have this, I doubt its affected the choice for even
Oh I keep forgetting. Mysql users are stupid, they are unable to compare features of databases. Postgres users are smart that's why they don't think outer joins are such a great idea.
evil is as evil does
"If these features are important to you (and the legions of others you refer to), then you and they can implement the features yourselves."
Adding asynchronous multi master replication is not a trivial task. I could understand your point if it a minor feature though. Even then it's easier to use something else then to hack postgres code. People who want those feature end up taking the path of least resistance which is to use mysql or firebird or oracle or whatever.
evil is as evil does