That's the same company that bundles much needed java security updates with the opt-out option of installing a weird browser toolbar and setting the homepage to a crappy service, right?
Seriously, I never cared about that company as long as it was just selling expensive (but supposedly feature rich?) software to the enterprise, but it seems the alternatives to Oracle's java and MySQL need some more support, market- and mindshare.
I personally stopped using MySQL quite a while ago as well. Java, on the other hand, got resurrected for me with Groovy first, then Clojure (and a passing interest in Scala).
Yeah, I know about openjdk. But they don't provide official binaries for all I know (and certainly not for Windows, linking back to the Oracle distribution).
It is still open and available for download at http://opensolaris.org. It just isn't being supported by Oracle anymore since they are focused on Oracle Linux.
No, the gate has been closed about two years ago. Solaris is not open source anymore. The illumos guys forked the last available version of the code and push it forward independently.
FreeBSD is doing a great job of catching up with Solaris innovations. I love those guys! And maybe we can ride for a few more years on Sun's largesse. But who will push things forward?
This test-case controversy was both discovered and ginned up by Monty and the MariaDB folks, who have much to gain by the rejection of Oracle's brand of MySQL and the promotion of MariaDB. While it may be part of some larger and sinister plan to "kill" open source MySQL as the article suggests, it seems more likely to me that it was simply a mistake, and one they'll walk back at some point.
If it is an anti-competitive move, it reminds me of the recent move by RedHat, who have started shipping their new kernels as one big source tarball, without patches, which undoubtedly pissed off both Oracle and the CentOS folks.
From what I've heard withholding test cases is actually official Oracle policy, unlike, for example, the lack of updates to the launchpad repository. There wasn't any deliberate attempt to without commit history from launchpad - they were just slow in updating it.
How do you explain removing access to the source repository then?
I can easily explain it, because it never happened. Access to the MySQL source repository on launchpad is available for anyone to browse. Oracle is occasionally lazy about updating it, but they've never removed access AFAIK.
Or the fact that the documentation is not free to redistribute?
The documentation has never been free to redistribute, it was that way under Monty, it was that way under Sun, and it remains that way under Oracle.
it does not matter to simple rhel rebuilds like centos or scientific linux. it is unfortunate for the linux stable kernel maintainers. that's for sure though.
it is very different from this case. that it's a simple mistake is not very probable. see the java sec update controversy a few days ago.
As mentioned in the comments see MariaDB (http://mariadb.org/), an open source fork of MySQL from before the Oracle acquisition. Like Hudson, MySQL will live on.
MariaDB ships with XtraDB, Percona's modified InnoDB engine. If you're planning on using InnoDB (which just about everyone is) the differences are pretty minor.
The big difference is that MariaDB comes with the Aria storage engine, which is a crash safe alternative to MyISAM.
If you're using mainly InnoDB and want more reliability / performance / less variance in execution time - go for Percona, that's what they're specialising in. Also you can use the company for support when needed.
For those who try to stay away from TC: "it appears that Oracle is making its revision tests and histories closed source" sums up the few paragraph link bait ... :)
I used to enjoy working with Oracle databases, but the horrible pricing and high need for dba maintenance was always discomforting. Switch for a while to MSSQL, but then the market for Windows apps disappeared. Have been using mySQL with very little sort of DB satisfaction. Now I don't know why anyone would not choose PostgreSQL for almost any project. Oracle is a bad apple, making money with methods aking to extortion.
Disclaimer: It's been a while since I tried to use SQLite for anything.
I've never really felt that it was actually easier to use than a client/server DBMS. I can imagine that it's good for some kinds of embedded applications, but for normal web applications I don't see any improvement in usability. Juggling files is not any easier than setting up a connection.
And there were always annoyances associated with the simplicity. All those "complex features" in a real DBMS turn out to be useful sooner than you think (and I don't mean "once in production" I mean while still in development). Even the simplest applications can usually benefit from good support for dates and times.
I think SQLite just drew the line in the wrong place for most applications (although it may serve a niche quite well). Oversimplification requires the developer to reinvent, which results in a much more complex system overall (or one that at least requires more work to develop and maintain). Key/value stores have similar problems for general-purpose application development.
1. With the PDO (or any ORM) setting up and "using" SQLite is as easy as any other database.
2. There are several really nice front-ends to SQlite, along with the phpmyadmin like app for SQlite. Like MySQL you'll never have to use the command line (for most operations).
3. SQLite is now included with just about every scripting language (except MS' langs - where it's just a matter of downloading the app and an ODBC driver).
4. "Because it requires no configuration and stores information in ordinary disk files, SQLite is a popular choice as the database to back small to medium-sized websites." - sqlite.com
Simple websites. Would I run this site on SQLite? Of course not. Any shopping site with a million users? No. But a personal blog? Yes. A company website used for marketing and information (and maybe a few Contact US pages)? Yes.
There are millions of sites where using MySQl is over-kill. But everyone uses it because, like PHP, it's always there.
5. SQlite uses SQL. Very few commands aren't available.. like you can't write to a View. But I think that's true in MySQl too. There's a small list on sqlite.com. It even has transactions.
Simply put, if you don't require writing to the db from multiple sources (and lets face it, 80% of the sites out there don't.); running your app or site on sqlite is fine.
"setting up and "using" SQLite is as easy as any other database"
That's exactly the problem. If it's easier, then maybe I'll use it. If it's just as easy, but does less, I have no reason to bother using it, for two reasons:
1. There is non-zero risk that I will need one of the other features.
2. Even if I don't, why would I want to spend time learning something if it isn't better (at something) than what I already know how to use?
I haven't seen any compelling reason to use SQLite outside of the mobile or embedded space.
It's not. I'm just pointing out that there are alternatives to MySQL. And for small sites/apps that don't require something like Postgres; that can be SQLite.
Frankly I miss the days when an easy to install and use database was available to the masses. Remember Paradox, dBase and Foxpro? Sure all those database where powerful (xBase, for example) and used to develop complex applications. But they were also used for simple applications.
I would love to see something equivalent to those online. Oh wait, there is; SQLite.
SQLite is not a real solution for anything needing to support more than one user at a time. It's fine for things like managing bookmarks within firefox, but not for a full relational database replacement. The write access is single threaded (at least last time I used it).
My experience with SQLite is that if you're using it as more than an object-store, you'll be disappointed by the limited subset of SQL it supports. And if you do just need an object store, Mongo is often a better fit and gives you flexible schema.
MS SQL Server is mainly used by corporations for corporations, so there is a market and good money for apps and expertise in those circles if you have the expertise in the MS stack.
For OSS projects that require a RDBMS, PostgreSQL is a good choice. I instinctively choose it over MySQL years ago and have been pleased.
>Now I don't know why anyone would not choose PostgreSQL for almost any project.
No offense but people who make statements like this clearly don't know much about the current state of databases. PostgreSQL is pretty bad in many areas compared to the newer databases e.g. ease of clustering and sharding, developer friendliness, JSON support, tool support etc.
It's great as a replacement for a typical RDBMS but if you're working on a new startup project I would see no reason to use it.
Not sure what you mean by lack of developer friendliness and what specific tools you find it lacking. Postgres is a great choice for new startups that need an RDBMS and like having schema for their data. There is built-in JSON support in upcoming 9.2 release and most JSON-to-schema mapping should be done in application anyway. Sharding is easy to do at application level; you would lose ability to do certain queries across shards but most solutions offering automatic sharding are designed specifically not to allow most types inter-shard querying and instead offer map-reduce.
Sorry but PostgreSQL's JSON support is a joke. It is nothing more than a VARCHAR that validates. You can't search or index across fields and the way you actually query the JSON is cumbersome at best.
Also all of your arguments are "push to the application layer". Well my point is that with most of the newer databases you don't have to reimplement the wheel.
If you need to store arbitrary JSON fields in the database and index them, then you indeed are better of with some NoSQL database. But I strongly disagree with the statement that all new startups deal with that kind of data organization. Many problems have good structure and can benefit from imposing structure (schema) upfront. In which case any JSON you get will parse in the application, map it to your data organization and store in a clean strict relational format, with all indexable fields extracted to separate columns. I do not store my logs in Postgres, but I do store my billing transactions in Postgres. There are many different types of data with different tradeoffs involved. For most, Postgres is a great choice.
Well some are better than others right. Riak/CouchDB are great when it comes to clustering/sharding. MongoDB has the best JSON support and is very friendly for developers. MySQL is proven, has the best tool support and most widely supported.
The fact is that just like one programming language doesn't satisfy all use cases. Neither does one database. So maybe PostgreSQL 'supporters' should stop trying to claim it is perfect for everyone.
It seems Oracle is on a trend to kill everything open source they've acquired from Sun. Java seems to be the only one left, and it would've happened already if they won the trial with Google, but I'm sure they'll do something equally dumb in the future to kill finally Java, too.
> It seems Oracle is on a trend to kill everything open source they've acquired from Sun.
Oracle is, above everything else, about monetization. If they can't make money out of it, they will either change it so they can make money out of it, or they'll kill it.
Sun was generally good at open-source (though not perfect by a long shot, OpenSolaris was not exactly a slam dunk and the CDDL was rather weird — and explicitly and expressedly made incompatible with the GPL), but they were rather bad at monetizing. Oracle's the exact opposite.
It also realizes that most of its monetization comes from professional services, and saw that 1) software subscription revenues were declining across the board, proprietary or Open Source, and 2) Open Source created (to IBM's lawyer's eyes) a possible threat to its patent holdings (a considerable revenue stream / business value themselves) which was best addressed by keeping core development outside the organization (Red Hat, Novell/Suse, Kernel.org, Apache.org).
Oracle's direction (as was Sun's somewhat schizoid approach to Free Software / Open Source before as noted by its supporting the Caldera/SCO Group attacks against Linux) are making it a non-credible source. Hence the forking of projects (Lumina, LibreOffice, OpenJDK, MariaDB, etc.) it had inherited.
Firebird seems stable and fast enough, what it does lack is good client libraries. We looked at different database solution when rewriting our current webshop and Firebird was something we looked at, but because we're a Python shop we dropped it. I'm not saying that the current Python driver doesn't work, it does, but it doesn't seem to be updated very infrequently and it's still seems more like an InterBase driver than a Firebird driver. We went the Postgresql route, and why really, why wouldn't you?
Don't get me wrong, it's a great database and I know a company that use nothing else and won't switch if you paid them, ( They are use .Net ).
Postgres is developing a lot quicker then Firebird. Also, management and replication solutions for Postgres are far more advanced. But what matters most (for me) is documentation. I can find everything I need to know right here:
I wrote an accounts receivable/payable app in Borland Delphi back in 2002. At the time Interbase was the easy choice. At that time, Interbase was transitioning to Firebird. I dropped it in as a replacement and it did its job fine. If you like MySQL, you'll miss auto incrementing Primary Key Columns that MySQL seems to have made so popular. It's not too hard to setup a trigger for sequence types, but it's not built in. (or it wasn't back then) All the tools for management were the Interbase tools. Most of my stuff is either MySQL these days or Postgres when I need good spatial support. I've messed with CouchDB a bit. I just don't see Firebird going anywhere for my needs.
Most people saying "Time to switch from MySQL" (probably) aren't paying for MySQL. From a business perspective, those people are a net loss anyway. Getting them to switch to something else may actually save Oracle a little money.
But they could happen in the future to work for a corporation that would like to pay, but as it stands they will never suggest using MySQL. Thus MySQL will slowly disappear from the youngs mindshare and Oracle will make no money at all on it.
MySQL AB also required copyright assignment for all contributions, which made it possible for MySQL AB, Sun and now Oracle to have full copyright over it. MySQL AB wasn't above throwing around GPL FUD to scare people into paying for a non-GPL license.
MariaDB is by Monty, creator of MySQL who previously sold-then-forked it. So there's no guarantee the same thing won't happen to it (quite the opposite really).
An honest question, why support the people who caused this situation in the first place? It really seems like supporting other groups would be more appropriate.
I cut a bunch of apps (and their large databases) over from MySQL to Postgres several years ago. It was tedious, but I've never had cause to regret it in any way.
When MySQL became Oracle I was very relieved to not have to think about the implications.
...and in the process opens the floodgates of possibilities for Drizzle, MariaDB, PostgreSQL, and everyone else. Oracle has already shown fairly conclusively it can do little else but mismanage its acquired Sun assets.
Unfortunately, that includes hardware too... A friend had 3 out of 13 Oracle servers die with random memory errors (persistent). Of course, if they had a 10K+ service contract they'd be happy to help.
In the enterprise hardware world, I don't know any vendor who will offer an answer other than "call your sales rep" to a customer who didn't buy a service contract.
It was a charity donation (by Oracle) of hardware and services, and the service contract wasn't part of the donation. The initial donation was laudable, but the hardware was weak. Needless to say, the 3 dead servers were not replaced.
Seriously, I never cared about that company as long as it was just selling expensive (but supposedly feature rich?) software to the enterprise, but it seems the alternatives to Oracle's java and MySQL need some more support, market- and mindshare.