Wednesday, January 16, 2008

Sun buys MySQL

Ну что, сезон охоты за OSS базами данных открыт?
Sun покупает MySQL. Кто следующий на очереди: Firebird, PostgreSQL или SQLite?
http://www.sun.com/aboutsun/pr/2008-01/sunflash.20080116.1.xml

18 comments:

pnv82 said...

Интересно, а у кого, юридически, можно покупать Firebird?
Можно ли купить FF?

Alex Ott said...

хмммм, как мне кажется, postgresql достаточно сложно купить, за ним ведь нет единой компании.
мне кажется, что это как раз и стало поводом для покупки mysql - ведь сан обеспечивал поддержку постгресса на своих серверах, а что с ним будет дальше, уже становится непонятным

Dmitry Chestnykh said...

В SQLite покупать нечего, потому что код в public domain.

Alexey Kovyazin said...

Покупается бизнес на чем-то, и для этого "чего-то" не обязательно владеть правами на продукт.
Продолжая аналогию с опен-сорсом и воздухом - воздух купить нельзя, а отель в этом месте - вполне.
Другое дело, что выражение "купить Firebird" не корректно выглядит, хотя по сути бизнес есть бизнес, и если купить IBPhoenix и пару других вендоров, то это и будет покупка Firebird.

Yo! said...

Думаю их именно клиентская база интересовала - Google, Yahoo и прочие. если бы их интересовала сама субд, они могли бы сами разработать пропретарный движек к mysql, нарисовать человеческую репликацию, гуй, ROLAP и бодатся на рынке rdbms без покупки MYSQL AB.

Dmitry Kuzmenko said...

to Yo!: ну конечно, сейчас только ленивый не разрабатывает собственный движок СУБД. Так? :-)

Dmitry Kuzmenko said...

Кстати, Алексей, покупка еще раз подтверждает тезис о том, что большие продавцы железяк заинтересованы в поставке бесплатного ПО к этим самым железякам. Понятно что Сан предлагает расширить саппорт и т.п., но...

Alexey Kovyazin said...

Ну, в таком случае у производителей железа есть большой выбор :) Одно плохо - когда все ПО станет бесплатным дополнением к железу, то китайцы начнут обменивать железо на еду и бензин!
И вот тогда ИТ точно станет коммодити: в каждой квартире и конторе краны с водой, розетки и шланг, подключив которым к своему разьему (в районе затылка), услышишь: "Здраствуй, клиента! Китайские информационные технологии рады приветствовать вас. Нас зовут Ли Чан, Ли Чен и Ли Хан, мы ваши персональные менеджеры. Хотите играть тетриса или пасьянса?..."

Дмитрий Тимохов said...

Пусть только попробуют давить на мой любимый google! :)

Yo! said...

to Yo!: ну конечно, сейчас только ленивый не разрабатывает собственный движок СУБД. Так? :-)
--------

разработать свой движек для SUN было бы МИНИМУМ на 2 порядка дешевле. учитывая гиганский оборот mysql ab ($50M) доить бабло с бесплатного продукта тоже не планируется.

Dmitry Kuzmenko said...

истинный смысл пока сокрыт, не спорю.

кстати, про разработку движка - вспомнил Codegear BlackFish SQL, который недавно был объявлен. Выросло это из JDataStore и невышедшего NDataStore. Но разрабатывалось не быстро. Понятно что Borland не Sun, но тут же опыт нужен...

Yo! said...

когда у тебя гигабакс налом - можно смело начихать на чей-то там опыт. назначь премию в $10M каждому и уже ЗАВТРА Кодд востанет из магилы, чтоб навенуть тебе очередной революционный движек для mysql, а ты не парился с опытом.

Alexey Kovyazin said...

Вот только не надо о силе денег и вере в великих гуру :)
Если бы все было так просто и увеличение премий сокращало бы сроки разработки, то мы бы давно жили в идеальном ИТ-мире.
По ситуации: некоторое время назад MySQL купил Netfrastructure с Джимом Старки впридачу, который был призван сконцентрировать опыт Interbase, Netfrastructure и Vulcan (не слишком удачной модификации Firebird, созданной для нужд SAS) в мега-движке Falcon. Ссылка http://ibdeveloper.com/2006/02/18/jim-starkey-leaves-firebirdvulcan/
Прошло уже почти 2 года, и несмотря на технические наработки, опыт Джима и ресурсы MySQL Falcon еще телится, и все по прежнему упоминают InnoDB как наиболее серьезный движок.
Конечно, миллиард явная переплата только за техническую составляющую MySQL, но не стоит забывать о времени, которое надо затратить на создание действительно качественного движка базы данных.

Alexey Kovyazin said...

Ссылка из пред коммента обрезалась
http://ibdeveloper.com/2006/02/18/jim-starkey-leaves-firebirdvulcan/

Alexey Kovyazin said...

блин, она вообще режется :)
тогда так, ручная склейка
http://ibdeveloper.com/2006/02/18
/jim-starkey-leaves-firebirdvulcan/

Yo! said...

вчера читал я про Falcon, может я конечно что-то недопонимаю, но я не представляю где такое кроме веба потянет с короткими транзакциями. багофичу сборки мусора он поправил, но UNDO запихнул в кеш !? теперь длинные транзакции просто будут вымывать кеш своими версиями строк.

что касается "ресурсы MySQL", мне вообще не понятно как можно прокормить эти 400 человек с таким оборотом, не то что еще какие-то проэкты поднимать ...

Alexey Kovyazin said...

"Багофичу сборки мусора"? Провоцируете на войну версионники против блокировочников? :) Так поздно: баталии отгремели и блокировочники давно проиграли - вместе с появлением Yukon пал последний оплот. А то, что кое-где люди все еще мучаются с блокировкой таблиц и ролбэксегментами, так они за это получают повышенную зарплату и молоко за вредность. Еще пара релизов и мы увидим в Оракле и МССКЛ полноценную версионность, как в InterBase и Firebird.
Впрочем, смотреть на Falcon еще нечего - сначала Джим должен передать свое творение другим ресурсам, чтобы те его "испортили", и по прошествии лет 20 все будет совсем ясно.
Что касается прокорления 400 человек на 50 миллионов - так у них же в Швеции цены на жилье ниже, чем у нас. Да и кушают они не так много, как некоторые у нас.

Yo! said...

не, блокировочники тут непричем и роллбэк это из другой оперы. речь о том, что ФБ, в отличии от Innodb и Oracle имеющие UNDO, версии строк хранит в файлах данных, где они плодятся безразмерно и он вынужден ненужные версии приодически подчищать (сбор мусора). что в этом полноценого я не понял.
на счет скромных зарплат в Швейцарии смеялсо :)
повторю у MySQL AB возможности более, чем скромные, а вот SUN спустив всего 5% бюджета мог бы набрать команду ни в чем по опыту не уступающую прямым конкурентам. Но им нужны были жирные клиенты MySQL ...