Sun Buys MySQL
Krow alerted me that MySQL has been bought by Sun. Right now there is only a brief announcement but it discusses what the acquisition will mean for the core developers, community etc.
← Back to Stories (view on slashdot.org)
Will it blend?
Not that I distrust Sun's motives when it comes to free software. I mean they did a stellar job on OpenOffice.org, didn't they?
My blog
It would be interesting to see how this might stress their relationship with Oracle. So are we heading back to the days of a vertically integrated "stack"? I doubt it. More likely they will jettison the hardware business and concentrate on software.
Hopefully they will make PostgreSQL the default database engine and just add a MySQL legacy layer on top of it. Sun already has great PostgreSQL support, so it's not such a strange suggestion. Maybe that way MySQL will get ACID support this century.
mysql license is real mess, it can be interpreted in so many ways.
I have worked at a lot of big banks. Open Source has been slowly finding its way in, but it is incredibly difficult to deploy an open source database like MySQL or Postgres. The banks says they want safety and security - and you answer that your database isn't enterprise critical so why pay for Oracle? Management then says, ah well, how about MS SQL Server....
See my journal, I write things there
Wow, MySQL owned by a company that doesn't lie about the GPL! This is welcome news!
Short version - Oracle offered 19.23 or so, and BEA said yes this morning. Big impact on a lot of Java EE developers out there.
+++ UGUCAUCGUAUUUCU
I think it's long-term bye-bye LAMP, since Sun may "empower" MySQL with Java stored procedures, may obfuscate the documentation(like Oracle does), or remove the transactions altogether and replace them with soft ones (JTA),... or anything you can expect (if you've seen a Java programmer using 1% of databases' features..)
gtkaml.org
Maybe Sun will fire the idiots who said that RI, ACID, Triggers, and Stored Procedures aren't necessary for a real database. One can hope.
Sun is the 2000 version of Bell Labs.
Google just makes beta applications.
Regards,
Website Hosting
Hopefully they are starting to realize the real value in offering software virtually for free but charging for the support. You get a lot more regular paying customers if they can pay a very affordable annual cost for continued support vs paying some stupid high software cost up front. Many opportunities are missed because of the sticker shock for SMBs.
From the blog it looks like Sun is trying to own a complete web solution. The blog makes a big deal out of getting the 'M' in LAMP. I think they want to be known as the dot in .com again, the place to go for web solutions.
ESR was on the nail. You can't defeat open source by buying the company IF the product has enough people who care about it enough to maintain it, have the appropriate expertise and aren't employed by the company.
There are a lot of important open source projects for which at least one of the above requirements is not true.
This is why IT departments need some improvement. Most are made up of hardware people who have a few programmers as friends and by and large are reactive rather than proactive in the way they deal with growth. The worst are the massively corporate entities who assume that the way to deal with any issue is to micromanage everything. I'm not blaming the people in IT for this so much as the people who create and staff IT departments.
How do you deal with the growth of an application such that it no longer is able to serve the audience that it now has effectively? Well, if this were hardware, you'd replace it. And the same approach needs to be taken with software. But that takes people to understand the application, and others to do the time consuming work of migrating people and data over to the new application.
There's nothing wrong with using a spreadsheet to manage an address book to start with. As more people start to use the same source, however, IT departments need to be willing to (and CTO's willing to allow them to) recommend changes, including providing the resources to move the data to a more efficient, more effective, platform. As of right now though, most IT departments don't even have the appropriate people to do that.
You are not alone. This is not normal. None of this is normal.
the benefits are only there on the surface.
but what good are they if you are bound and 'forced' to work until 9pm each nite? or made to feel guilty if you DON'T stay for dinner and work a few hours after that.
all for the SAME PAY.
yes, its a slave life. you'll understand that when you get older (no insult intended; I didn't realize this until I hit over 40, myself.)
--
"It is now safe to switch off your computer."
Yeah, that Java thing never really took off...
Spoken like someone who doesn't work in IT. I get request the day stuff is suppose to start with the users IDEA of what should work. Not requirements or information and what needs to be done then I get weeks of little issues tiring to make this Square Peg fit into a round whole until I figure out what is going on and replace it with something that works. The problem is IT is the last step in the process not the 1st step and that will always cause issues. Sometime we just can't do what the user thinks is simple. Just this week I had a issue with someone deciding that email made a good real time alert system from an external customer. Problem email isn't real time and/or reliable. So every hick up in email is an issue. If IT was consult we could have either a)set the expection or b)developed sometime that was real time and reliable they could use.
Actually, from my experience as a programmer I'd much rather have someone come with a spreadsheet he worked with for a year, and very specific requirements such as "we want some people to be able to see these fields, some people to be able to edit these columns" and so... than to have someone with a vague notion of what he needs and then turning that into a relational database. Even if spreadsheets seem awful, a year's user experience with a fast prototyping tool (i.e. the spreadsheet) is priceless.
As a Slashdot discussion grows longer, the probability of an analogy involving cars approaches one.
PostgreSQL has 7 -core developers, one of those works at Sun.
While Sun didn't buy any of the PostgreSQL companies, they do provide support and developers - the same as the others.
I doubt their support of PostgreSQL will lessen any.
The two database communities are not comparable.
MySQL is run by a central company.
PostgreSQL is run by the community, with companies growing up around it offering additional features and support (of which Sun is one of them).
What will happen is MySQL, the company, is shut down?
This I don't know.
I do know what will happen if the companies around PostgreSQL go away?
Its happened before. - PostgreSQL continues.
If anything from my point of view this is better for MySQL.
It stops companies like Oracle from being able to control the only company that truly controls MySQL.
Exactly, nor does it support industry standard SQL elements. MySQL hops around like a hobbled horse, with the authors claiming a fourth leg isn't needed to be a true RDBMS... Utter crap.
Yup, I think SQLite is a great alternative against Access, however could someone suggest a good GUI for SQLite with similar properties as MS Access? I am not looking for a clone but a program in which my mom could make her simple databases without knowing SQL programming language. Access allows her to do that, but if I want to migrate to Linux there is no alternative. I know that the guys at KDE have some nice apps in developemnt, but I am looking for an application in the lines of "mature" sourceforge status.
Ubuntu is an African word meaning 'I can't configure Debian'
I agree about PostgreSQL being a better option for so many reasons (and this new Sun thing is just yet another on the list). The only thing PostgreSQL really needs is some kind of asynch multimaster replication. That's one place where you can get "forced" to use MySQL because Pg can't do what you need. MySQL's implementation of asynch multimaster replication sucks anyways, I'm sure the Pg community can do it better eventually.
Back to the topic at hand though, one way around the libmysqlclient GPL thing is to insulate yourself in a dynamic language where your code doesn't explicitly "link" with libmysqlclient. If you're using Perl (or any other similar language I would assume), DBD::mysql links to libmysqlclient.a, but your own Perl application can be whatever license you like and just "use DBI" (and DBD::mysql indirectly), which is not linking.
11*43+456^2
How is adding Java stored procedures a bad thing?
First, because it will make easier for developers to put more application logic in the database.
Second, because a native compiled stored procedure (native, that is, to the DBMS) would be faster
But mostly, because free hosting which maintains something based on Java it's like.. not there.
And you have to admit that free hosting w/ MySQL is one of the reasons LAMP developers are so many, and LAMP is successful
Sure you can use only CRUD operations and do everything in the middle or client tier but it's not always the most efficient.
Exactly my point. But moving the bytecode from the middle tier into the database makes no difference either.
gtkaml.org
Who needs meaningful filenames and directories when you have grep?
Actually, he has a point.
One of the best features, to my taste, of gmail is that I can quickly find an email with a specific content regardless of the subject. Same thing with files if they are full content indexed.
And that is the way that humans naturally work: "I know what I am looking for, I just don't know where I put it (nor I care where it was)". The folders and file names paradigm is an emulation of the paper archival model. Classes are tough on how to create a mantain one (bookeeping, library, secretaries).
You see, this "order" force us to keep to pieces of information in our head: What is it and where is it. And to use one to get the other.
Of course anyone can create a simple filing system, but it requires some level of self disipline to keep it.
And is not intuitive.
I know what I want... just fetch it!
Spoken like someone who's just entered high school.
The last people anyone wants to talk to about ad-hoc projects is IT. An employee has a need, they fill it with a reasonable tool. Per the GP post, the initial requirements were simple and the solution sufficient. No IT department needed. As the utility of the system increased, so did the requirements, and so must the solution space expand requiring IT assistance. IT should then be eager to help and congratulatory on the success of the solution to date.
It's impossible to divine the future requirements of any system, or even it's success. That's why we iterate.
OTOH, fast prototyping can just as easily cause a lot problems. By the time you reach the natural limits of the prototype, who pays to extract the data into a preservation format? Did anybody even ask before the "fast" prototype was slapped together whether the data being captured will ultimately require preservation in a properly thought through archival structure? And if so, was this conversion budgeted ahead of time, or does it just show up as a problem further down the road, and effectively bite a chunk out of the IT dept. budget that should have been allocated to a business activity?
I've always believed one of the golden rules of foresight is "whoever created the mess, fixes the mess". In any situation where this rule is violated (e.g. the person creating the mess doesn't have the skillset to fix the mess), maybe some careful up-front design trumps the retrospective knowledge benefits of a fast prototype.
Be realistic. The path MySQL is going down now would involve configuration and editing through countless sets of webservers, various inaptly layers ending on the word 'bean', 200 xml configuration files, a couple of extra layers of abstraction thrown in the API, just because they can, and only with an additional quad core PC with 16 Gigs of RAM you can only work with your one-core 64 Mb instance of MySql.
I started with C/S on Oracle too and I've noticed that. I think it's one reason I like PostgreSQL and find MySQL annoying. So why do people like MySQL? Is it familiar to people who started with SQL Server or something? Or just the first db they encountered when they picked up a LAMP book?
(Yes I am aware of the irony of doing the very thing I am criticizing but I will break my own rule just this once because this appears to be forgotten these days on Slashdot)
You've heard it said before I'm sure - IGNORE THE TROLLS! etc. etc.
While I find it amazing for how many purposes you can (mis-)use spreadsheeds, having spreadsheets mailed to me with information not including any calculating ruins my day. It's pseudo-structured information. Reminds me of the mails I get when people send me an 'oh-so-funny' picture -- in a msword document.
Idha khatabahum lijahiluna qalu salaman
Actually there is stil an immense use for Excel in data processing. As a mathematician, I find Excel excellent for very-short-term data analysis projects. If you need to put the data in a database... you can always dump the whole spreadsheet.
Excel generates graphs very quickly, has quite a powerful set of numerical analysis functions and just works.
Databases aren't the answer when you want fast results.
Couldn't stand the weather
We do: we have MS Access.
Its a fabulous low-end database GUI built on a fairly robust RDMS engine for low volume usages. Best thing is every Windows 2000\XP\2003+ machine has ODBC drivers built in (not sure about Vista). Easy to build your own little apps or more advanced VB/.NET interfaces if your inclined. Hell, I built a J2EE shared calendar and multi-media catalog using an Access database as a start and it has worked butifully for the last 5 years.
Not on the same level as PostGres or (arguably MySQL) or a commercial RDMS but a great step up from a spreadsheet. Been around about as long too.
We do not inherit the Earth from our parents. We borrow it from our children.
"Accessed more quickly"?
Maybe. But there are advantages to storing it in a SQL database:
It doesn't take much to be better off sticking your data into a SQL database even if your data isn't relational in nature, as long as the data relationships you do have are relatively straightforward.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
I found out a potential reason behind the 'funny picture in word document' thing the other day. I sent my dad (who works at a govt dept) an email with a picture attached, and he replied with 'all pictures get stripped out of our emails. the workaround is to put the picture in a word document' :)
So I blame Corp/Govt email policies - pictures are obviously just (potentially offensive) time wasters, but Word documents are business, and we all know how quickly workarounds like that spread in corporate offices - much like using spreadsheets for data storage! Ha! I related it back to the topic! Wait.. what was the topic again?..