"Driver fault in reactor 2632 - Ignore, Restart, Evacuate"

Looking forward to a bright future...

I still use H.323 and with a GNU Gatekeeper. I like the independence from all these one-vendor systems.

Now nobody listens to non-corona news anyway.

The limitation of .org to non-profits has been removed ages ago. Anyone can officially register a .org.

Not fresh, but all P2P and OpenSource and by open ITU spec.
https://www.gnugk.org/

Playing with an almost usable Linux. I think it was about 1993 and called Slackware. I prefer fully working Linux nowadays.

Which "technology" do they use to leave the voice mail ? I'm pretty sure we can block that in our phones.

Hi!

MySQL "materializes" a view, but yes it does not have "Materialized Views".

For some views you can do a simple substitution, but not in all cases (for instance, SELECT * FROM A GROUP BY()). In that case you need the end result before you can execute the query.

I had little to do with the VIEW implementation, so I can't really say much about how it was designed. I am not crazy about how it works either.

Cheers,
      -Brian

Hi!

I am not sure about the Windows version, but I know the Unix version is still process based. In my opinion, one of the principle advantages in this is that they can use functions which can leak/die/etc and not have to worry about it taking out the server. This is what allowed Apache to handle so many unstable languages/modules.

The problem with Views in MySQL is that they frequently materialized, aka in many queries the database chooses to generate a full table of the data and do the JOIN (and in some queries there is no way to get around that). Many other databases have had views for longer and can avoid materialization in a lot of cases.

Currently I haven't brought VIEWs back in at a user level. The closest thing we have in Drizzle we use table functions for our data dictionary (aka... information_schema) and we do not materialize there. MySQL does materialization when you look at those tables.

My goal is to bring back VIEW, but for the first generation of them avoid queries which would cause/require materialization.

Cheers,
      -Brian

Hi!

Drizzle is transactional by default.

Bad data? We don't insert it, we toss an error (and if we don't in some cases, it is a bug).

We purposely went after the issues in the MySQL gotchas list when we began (http://sql-info.de/mysql/).

Our DDL? Soon will be transactional. Our data dictionary is federated out to engines, so unlike MySQL in our system the engine owns the definition so you can't end up in a situation where the engine is off from the definition.

I wouldn't make the assumption that because we have a similar ancestor that we are the same at all. It would be like assuming Postgres and Ingres are the same (which they are most certainly not).

When I first started doing the rewrite I considered Postgres (and spoke to a number of the developers of it at the time). In the first year I went back and forth in my head on that decision. There would have been a lot of things that would have made PG a better starting point. By the time we reached 5.1 the MySQL codebase was junk. Postgres would have made for a good decision but there were three drawbacks.

1) Postgres is C and not C++. I find that I can write code in C++ nowadays much faster then I can in C (and it comes out just as fast, the C++ "is slow" is an archaic view).

2) Postgres is not designed to use threads. I prefer to work with threads over processes (and there is a lot of good and bad with both concepts).

3) Sun wouldn't have paid for it ;)

I wouldn't consider SQLite. It is neither type safe, not concurrent. It is a great database, but it doesn't solve any of my needs. I did think about Firebird for a bit, but while I know the MySQL and Postgres codebase, I don't know the Firebird code at all.

Cheers,
      -Brian

Hi!

"When it comes to Drizzle, you require the code to be under BSD; In practice this is a contributor agreement too."

We don't require contributions to be made under the BSD license, we do ask that new modules are, but that is all. From day one we have never mingled GPL and BSD headers in files. Derived work has always been derived work. We never have had as a goal for Drizzle to be embedded so copyright assignment is not required. Ask Kristian for the IRC conversation I once had with him on this topic where I explained my reasons for this (or... I'll just blog most of them up again: http://krow.livejournal.com/684329.html).

Richard's statements imply that a protocol is somehow wrapped up in licensing. In the US this is just not true (someone in another comment pointed out the Lotus Notes legal case where the FSF argued this itself ). Richard says all sort of things, but it doesn't make an ounce of them all true.

Bradley Kuhn has pointed out that while the FSF has done copyright assignment, it has promised to never assign its rights for commercial purposes. It also doesn't require sign over of all rights to a given body of code. It just asks for enough so that it can be a legal partner in the defense of the GPL should something come to court. That is very different in nature, to the code assignment that occurs when someone is assigning code to a commercial entity.

Cheers,
      -Brian

Hi!

You should easily be able to find blog posts, comments, etc... from me over the years telling people exactly how far the GPL reached (this was an ongoing issue between me and others in MySQL for years, and is well known within the MySQL community).

The acquisition by Oracle, or even Sun, is not what matters. What matters is the state of the community, etc where this belief is still perpetuated. I found at SCALE that this was a topic that was still being discussed, and that there was a lot of confusion around it.

Which is why I blogged about it :)

I would also not go as far as saying all of the MySQL principals (or even the senior executives for that matter). Sit down sometime with David and I believe you might find a different answer.

Cheers,
      -Brian