Comments 28
Time to fork.
Зачем? Я вон давно использую MariaDB, прозрачная замена MySQL, проблем нет.
Но тем не менее кодовая база MariaDB зависит от MySQL.
Раскрою свою позицию немного полней:
1. Oracle закрывает часть исходного кода
2. Продукт MySQL начинает нарушать GPL
3. Свободные диструбутивы (Debian, Ubuntu) отказываются от поддержки продукта в репозиториях
4. А так как без этого продукта никуда, нужно сделать форк последней GPL версии и заниматься дальшим развитием силами сообщества.
1. Oracle закрывает часть исходного кода
2. Продукт MySQL начинает нарушать GPL
3. Свободные диструбутивы (Debian, Ubuntu) отказываются от поддержки продукта в репозиториях
4. А так как без этого продукта никуда, нужно сделать форк последней GPL версии и заниматься дальшим развитием силами сообщества.
есть Percona
Я думаю, есть много каких форков, но что полностью соответствует GPL и пойдет в следующую убунту — вот в чем вопрос.
Причем Percona способна спокойно заткнуть за пояс оригинальный MySQL и вообще выбить Oracle нафиг из ниши. Как было с OpenOffice… ИМХО, конечно.
Имею в виду из ниши СУБД для веб. Не Enterprise, конечно.
Да, но Percona собирается из MySQL с накатыванием своих патчей, так что выводы тоже не утешительные
Вы несколько переоцениваете Перкону и недооцениваете Оракл и объем работ. Кроме того Перконе это совершенно не надо. У них другая ниша.
А что стало с OpenOffice? LibreOffice вышиб его с рынка?
Есть какая то статистика по этому поводу?
Есть какая то статистика по этому поводу?
Насколько мне известно, Oracle в этом случае умылись и отдали OpenOffice.org в Apache Foundation. Официальных причин я не знаю, но кажется очевидным, что при уходе ключевых разработчиков в форк-проект LibreOffice, Oracle просто решил не тягаться с ними и не вкладываться в проект, который не нацелен на приобретение прибыли. Что я расцениваю как вылет Oracle из этой ниши. Правда, они за нее и не особо уж держались. И я не знаю, что с оригинальным изначально проприетарным проектом StarOffice, жив ли, иль нет — без понятия.
Подождите, а где же нарушение GPL? Они только тесты закрыли, их просто нет в поставке исходников последней версии. Код как был, так и есть. Тесты вроде не относятся к исходному коду продукта, они только тестируют функционал и работоспособность, в заметке об этом сказано же.
Вы смешной, сообщество _уже_ не потянуло mysql. У него очень слабое developer community. Почему так — отдельный разговор, но от этого факта никуда не денешься — ни во времена «свободного» мускла, ни во времена Сана, ни сейчас поддерживать mysql кроме специально для этого нанятых разработчиков (в Оракле и МарияДБ) по большому счету некому.
Интересно, кстати, много ли патчей из коммьюнити приходит в МарияДБ и много ли берут (по сравнению с mysql)?
Интересно, кстати, много ли патчей из коммьюнити приходит в МарияДБ и много ли берут (по сравнению с mysql)?
Time to PostgreSQL
Вы смешной. А что делать с проектами, которые уже работают на майскуле?
Портировать? Ага, прям вот щас забили на разработку и будем портировать.
А все проблемы из за того, что после того как Оракл изговняла Джаву теперь взялись за переделки майскуля.
Эх. Где же ты, Sun, солнце наше?
Портировать? Ага, прям вот щас забили на разработку и будем портировать.
А все проблемы из за того, что после того как Оракл изговняла Джаву теперь взялись за переделки майскуля.
Эх. Где же ты, Sun, солнце наше?
Можете не портировать. Просто если (хотел поначалу написать «когда», но решил быть оптимистичнее) столкнетесь с продуктом без документации, комментариев в коде, тестов и т.п. обвязки (и дай бог, чтобы он не стал закрытым и платным) — будет гораздо меньше времени на изменения.
Так уж и изговняла?
Ничего не делать с проектами которые уже работают на мускуле. Зачем трогать то что уже работает?
Однако я не вижу особых преград в портировании рабочих проектов на Postgre. Рефакторинг нужен тогда когда рефакторинг участвует в решении очередной задачи. Может случится что фишки Postgre, ну например, позволят при усложнении запроса гарантирующего повышение нагрузки избежать этого. Плюсики в сторону Postgre накапливаются. И для некоторых чаша может переполнится.
В одном из моих проектов так исторически сложилось что девелопмент идет на MySQL, а выкатка в production на PostgreSQL. Проект не сложный, и фишек специальных не используется. Однако получается, что я с каждой выкаткой портирую проект на Postgre.
Возможно нет никакой ложки?
Однако я не вижу особых преград в портировании рабочих проектов на Postgre. Рефакторинг нужен тогда когда рефакторинг участвует в решении очередной задачи. Может случится что фишки Postgre, ну например, позволят при усложнении запроса гарантирующего повышение нагрузки избежать этого. Плюсики в сторону Postgre накапливаются. И для некоторых чаша может переполнится.
В одном из моих проектов так исторически сложилось что девелопмент идет на MySQL, а выкатка в production на PostgreSQL. Проект не сложный, и фишек специальных не используется. Однако получается, что я с каждой выкаткой портирую проект на Postgre.
Возможно нет никакой ложки?
В работе были преценденты, когда получалось выяснить как именно работает данная функциональность только после того, как находил по ней соответсвующий юнит-тест. Особенно это касается новых фич, которые при выпуске очень слабо документируются, но бывают крайне полезными.
Удар конечно не серьезный, но конечно же неприятный. Очень жаль. Не понимаю логику данного нововведения, а про дальнейшую обеспокоенность вообще молчу.
Ну что ж посмотрим как будет ситуация развиваться дальше.
Удар конечно не серьезный, но конечно же неприятный. Очень жаль. Не понимаю логику данного нововведения, а про дальнейшую обеспокоенность вообще молчу.
Ну что ж посмотрим как будет ситуация развиваться дальше.
А логика, мне кажется, в том, чтобы постепенно отдалить MySQL DB от Oracle DB и сделать ее базой для простеньких веб-проектов. Важные нововведения будут ожидаться годами, а вспомогательные скрипты\тесты будут спрятаны для усложнения адаптации базы под специфические и более сложные задачи, тем самым усложняя (удорожая) поиск спецов для этих задач.
Хотите больший функционал — берите Oracle DB, вот и прайсик вам.
Вместе с тем, вполне можно продолжать кричать о «мы вложим в MySQL сотни миллионов», «мы полностью открыты, вот вам исходники»…
Хотите больший функционал — берите Oracle DB, вот и прайсик вам.
Вместе с тем, вполне можно продолжать кричать о «мы вложим в MySQL сотни миллионов», «мы полностью открыты, вот вам исходники»…
Для части багов тесты — это эксплоиты. У некоторых корпораций есть политика не раскрывать эксплоиты на свои продукты, возможно тут та же ситуация.
Нет. Эта отмазка работает для некоторых тестов, но не для всех. Другая отмазка — «в тесте содержатся данные клиентов, которые мы не имеем права раскрывать». Но в 5.5.27 не было новых тестов вообще. Даже тестов к вполне безобидным багам, даже тестов, которые свободно лежали в открытую на bugs.mysql.com
Sign up to leave a comment.
Oracle закручивает гайки