Oracle закручивает гайки

[crmMaster]

Time to fork.

[KawaiDesu]

Зачем? Я вон давно использую MariaDB, прозрачная замена MySQL, проблем нет.

[crmMaster]

Но тем не менее кодовая база MariaDB зависит от MySQL.

[crmMaster]

Раскрою свою позицию немного полней:
1. Oracle закрывает часть исходного кода
2. Продукт MySQL начинает нарушать GPL
3. Свободные диструбутивы (Debian, Ubuntu) отказываются от поддержки продукта в репозиториях
4. А так как без этого продукта никуда, нужно сделать форк последней GPL версии и заниматься дальшим развитием силами сообщества.

[shagguboy]

есть Percona

[crmMaster]

Я думаю, есть много каких форков, но что полностью соответствует GPL и пойдет в следующую убунту — вот в чем вопрос.

[dimitrymd]

Причем Percona способна спокойно заткнуть за пояс оригинальный MySQL и вообще выбить Oracle нафиг из ниши. Как было с OpenOffice… ИМХО, конечно.

[dimitrymd]

Имею в виду из ниши СУБД для веб. Не Enterprise, конечно.

[AotD]

Да, но Percona собирается из MySQL с накатыванием своих патчей, так что выводы тоже не утешительные

[eexo]

Вы несколько переоцениваете Перкону и недооцениваете Оракл и объем работ. Кроме того Перконе это совершенно не надо. У них другая ниша.

[Jodes]

А что стало с OpenOffice? LibreOffice вышиб его с рынка?
Есть какая то статистика по этому поводу?

[dimitrymd]

Насколько мне известно, Oracle в этом случае умылись и отдали OpenOffice.org в Apache Foundation. Официальных причин я не знаю, но кажется очевидным, что при уходе ключевых разработчиков в форк-проект LibreOffice, Oracle просто решил не тягаться с ними и не вкладываться в проект, который не нацелен на приобретение прибыли. Что я расцениваю как вылет Oracle из этой ниши. Правда, они за нее и не особо уж держались. И я не знаю, что с оригинальным изначально проприетарным проектом StarOffice, жив ли, иль нет — без понятия.

[KawaiDesu]

Подождите, а где же нарушение GPL? Они только тесты закрыли, их просто нет в поставке исходников последней версии. Код как был, так и есть. Тесты вроде не относятся к исходному коду продукта, они только тестируют функционал и работоспособность, в заметке об этом сказано же.

[Imposeren]

Тесты это по сути тоже исходный код и тоже под какой-то лицензией. Вполне возможно что в файлах тестов не упоминалась лицензия, но как правило лицензию пихают в начало каждого дажее бесполезного файла. Лично код mysql не смотрел, так-что не знаю

[eexo]

Вы смешной, сообщество _уже_ не потянуло mysql. У него очень слабое developer community. Почему так — отдельный разговор, но от этого факта никуда не денешься — ни во времена «свободного» мускла, ни во времена Сана, ни сейчас поддерживать mysql кроме специально для этого нанятых разработчиков (в Оракле и МарияДБ) по большому счету некому.
Интересно, кстати, много ли патчей из коммьюнити приходит в МарияДБ и много ли берут (по сравнению с mysql)?

[SDSWanderer]

Time to PostgreSQL

[Nurked]

Вы смешной. А что делать с проектами, которые уже работают на майскуле?

Портировать? Ага, прям вот щас забили на разработку и будем портировать.

А все проблемы из за того, что после того как Оракл изговняла Джаву теперь взялись за переделки майскуля.

Эх. Где же ты, Sun, солнце наше?

[heathen]

Можете не портировать. Просто если (хотел поначалу написать «когда», но решил быть оптимистичнее) столкнетесь с продуктом без документации, комментариев в коде, тестов и т.п. обвязки (и дай бог, чтобы он не стал закрытым и платным) — будет гораздо меньше времени на изменения.

[sedovmik]

Так уж и изговняла?

[Renius]

Ничего не делать с проектами которые уже работают на мускуле. Зачем трогать то что уже работает?

Однако я не вижу особых преград в портировании рабочих проектов на Postgre. Рефакторинг нужен тогда когда рефакторинг участвует в решении очередной задачи. Может случится что фишки Postgre, ну например, позволят при усложнении запроса гарантирующего повышение нагрузки избежать этого. Плюсики в сторону Postgre накапливаются. И для некоторых чаша может переполнится.

В одном из моих проектов так исторически сложилось что девелопмент идет на MySQL, а выкатка в production на PostgreSQL. Проект не сложный, и фишек специальных не используется. Однако получается, что я с каждой выкаткой портирую проект на Postgre.

Возможно нет никакой ложки?

[snevsky]

В работе были преценденты, когда получалось выяснить как именно работает данная функциональность только после того, как находил по ней соответсвующий юнит-тест. Особенно это касается новых фич, которые при выпуске очень слабо документируются, но бывают крайне полезными.
Удар конечно не серьезный, но конечно же неприятный. Очень жаль. Не понимаю логику данного нововведения, а про дальнейшую обеспокоенность вообще молчу.
Ну что ж посмотрим как будет ситуация развиваться дальше.

[mch]

А логика, мне кажется, в том, чтобы постепенно отдалить MySQL DB от Oracle DB и сделать ее базой для простеньких веб-проектов. Важные нововведения будут ожидаться годами, а вспомогательные скрипты\тесты будут спрятаны для усложнения адаптации базы под специфические и более сложные задачи, тем самым усложняя (удорожая) поиск спецов для этих задач.
Хотите больший функционал — берите Oracle DB, вот и прайсик вам.
Вместе с тем, вполне можно продолжать кричать о «мы вложим в MySQL сотни миллионов», «мы полностью открыты, вот вам исходники»…

[BlackFlyingCat]

+1

[svetasmirnova]

Советую сначала посмотреть на список нововведений в версии 5.6.

[davinchi]

Для части багов тесты — это эксплоиты. У некоторых корпораций есть политика не раскрывать эксплоиты на свои продукты, возможно тут та же ситуация.

[davinchi]

datacharmer.blogspot.jp/2012/08/is-oracle-really-killing-mysql.html

[petropavel]

Нет. Эта отмазка работает для некоторых тестов, но не для всех. Другая отмазка — «в тесте содержатся данные клиентов, которые мы не имеем права раскрывать». Но в 5.5.27 не было новых тестов вообще. Даже тестов к вполне безобидным багам, даже тестов, которые свободно лежали в открытую на bugs.mysql.com

[davinchi]

Разделять тесты на «эксплоиты» — «не эксплоиты» им, возможно, лень. Но я согласен — часть тестов можно сделать открытой.