first off you don't need to uninstall mysql. You will only run into a problem if you use md5 encryption. in that case, back-up that db before you install mariadb and then restore it after. why is there a problem only here? ... I don't know. why change? first: who knows what oracle will do, look at the java license if you need an example. second reason, mariadb has a cooler prompt ;-) third: http://www.youtube.com/watch?v=LrDnuvHfBr4 <--that guy's a major putts.

Hmmm... I do use some MD5 in queries and did not run into any problems that I know of - do you have any more info about this?

FWIW - I have now been running MariaDB exclusively on my newest box since about Feb 4 (see earlier post) and to be honest I had not even thought that it wasn't MySQL in recent weeks! The change was painless and complete!

As for the cooler prompt - that is a cooler default prompt.

I have long run the same in MySQL, very useful! To set that yourself simply add to /etc/my.cnf...

astrogeek, unfortunately, no I don't have any more info! It could have been the fact that I didn't uninstall MySQL first. After installation of MariaDB I tried the login/registration form that uses md5 and when I got an "index not found" error (or something like that) on my session variable, I tried creating another user, which worked. I did a query on the table and everything seemed fine. So I jumped to the conclusion it was on the md5 field in the table. Dropped it and restored from a back-up and everything worked fine. So, it might not even have been an md5 issue, just my *assumption* of the problem.

Good news, I'm going to update another box of mine this weekend, so I'll transfer those same tables over and see if I can recreate the issue

Why would you think installing MariaDB over MySQL without removing it first would be a good idea let alone be error free? MariaDB is a drop-in replacement for MySQL, but that doesn't mean that it installs the same files.

Probable should have read the manual first, lol. But that's just me; break it, fix, repeat!

It was on a whim that I installed MariaDB. I *thought* MariaDB and MySQL were different Databases. Meaning I didn't realize at the time that MariaDB was a "drop-in replacement". I should have done some research first, but... one little table in a sandbox database, no big deal! I've got no complaints. Not even One.

As for not installing the same files. Mostly from what I can see, yeah they are 99% compatible. /mariadb-versus-mysql-compatibility/ I'm sure once MariaDB matures that will change.

Best of luck to you!

I voted yes, but only to ask the following:

1. Does MariaDB outperform MySQL in every way possible?

2. Does MariaDB have any incompatibilities in relation to MySQL created databases?

3. Is MySQL's license still 100% compatible with the current licenses used by Slackware?

In my Day Job(TM), we went from Oracle to PostgreSQL. MySqueel (as I call MySQL) did not provide the same functionality that OracleDB did.

MySQL is always going to suck compared to OracleDB. Why else would you upgrade?

If your questions are not entirely rhetorical, here are my own best attempts at answers:

1. "Every way possible" covers a lot of territiory! But my MariaDB instance has now taken over full time ownership of a couple of my own large DBs. One is a data warehouse with 5 core facts and 20 dimensions and about 20 million core fact rows. It is nominally well designed and always gave good performance with MySQL, but is subjectively faster with MariaDB for both ETL operations and complex queries (no real data to support that however). The other is a simple join of 3 tables with about 2 million rows (master file index of all my CD/DVDs for the past 20 years). Path queries are full text searches and typically took 5-10 seconds on the same box with MySQL, subjectively I would put them 10-20% faster on MariaDB - again, no data to back that up, but lots of client queries (i.e., direct access, no GUI).

2. I have not found any incompatibilities so far, but that was also my long term concern.

3. No idea... but it is now Oracle owned and that turned out to be enough for me ;-)

It looks like it will be replaced by MariaDB.
http://slackware.com/index.html

That's good.

I do run Slackware on several servers, and MySQL is needed for various applications like public library management, Moodle, CMSMadeSimple, SPIP, Wordpress, and a few others. So yes, it matters.

The point was that nothing in Slackware relies on a MySQL server and that anyone with such a requirement would evaluate the options available to them and make an informed decision. I happen to need a database server, and I make my decision based on my requirements not on what is packaged by default.

I think MySQL is included with Slackware to provide a so-called LAMP environment out of the box.

When I just need a LAMP server for running standard web applications like Cacti, phpBB, Wordpress or Joomla in an intranet environment, I will stick with what Slackware provides by default. I works well, and I'm sure it will work well with MariaDB, too.

Yes it is!

As it happens, I have been reinstalling a few of my boxen this week to bring everything that can handle it up to Slackware 14, and that has included switching them all to MariaDB in the process.

So it looks like everyone made up their minds about the same time - very much thanks to this thread it seems!

I was wondering if anybody knows:

1. Will MySQL still be maintained for older Slackware versions even after the next version of Slackware (which will be using MariaDB of course) is released, or will the older Slackware versions be patched with MariaDB (this might not be the most "stable" thing to do, but since it can supposedly work as a drop-in replacement, I am curious)?

2. Has the SlackBuild script and other files for MySQL (other than the tarball version of course) changed since 14.0 came out? Just so www.slackbuilds.org and other such related sites could have MySQL up for the newer versions of Slackware after 14.0.

Cheers.

This ignores the value PV+team (and beta-testers in the broader community) bring to the distribution, in testing the various packages with each other for bad interactions. From time to time, the changelog reflects a reversion of some package to a previous version, when a newer version of the package shows problems.

If I just pull something from github and compile it on my system, I'm not getting the benefit of all that QA testing. This might not be important for a desktop, which can be rebooted / reconfigured at a whim, but it's very important for a server which needs to keep running for years at a time (and it's servers which will be running a database like MySQL, MariaDB, PostgreSQL, etc).

This is the terrible secret of software: Touching code creates bugs.

Adding features creates new bugs.

Refactoring code creates new bugs.

Fixing bugs sometimes creates new bugs.

Using software helps reveal what these bugs are. The longer software is used, the more bugs become revealed, but some bugs are particular to versions of other software it uses (libraries, kernels, modules) or software which uses it.

When assessing software for suitability for production use, it is often better to use older software (whose bugs have been revealed) which has been used with the other software on your system (such as the stock slackware packages). If you know what these bugs are, you can decide if they are relevant to your use-case.

Using new software, or software which has not been tested with the other software on your system, means assuming risk that an heretofore unknown bug will impact your use-case.

When deploying servers in large numbers, risk accumulates explosively. A bug that "only" takes down a server about once every three years, will be bringing down a server every two or three hours in a 10,000-server datacenter (if you're lucky; if the bug triggers on a condition which applies to several servers at a time, you'll be woken at 2am with thousands of machines down at once).

So, whenever possible, use the packages that ship with your distribution, and if possible make it a risk-averse distribution like slackware or debian-stable.