| 1.3, Аноним (-), 11:15, 04/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +13 +/– |
Я так понял MySQL скоро переползет на могильник Apache, чтобы OO скучно не было.
Не дай Боже этот финт повторится с VirtualBox...
| | |
| |
| 2.5, clown (?), 12:15, 04/02/2013 [^] [^^] [^^^] [ответить]
| –21 +/– |
OO куда живее, чем LO. А теперь, когда LO-шные клоуны своими руками похерили совместимость, воровать из OO решения, выдавая их за свои результаты, им будет гораздо сложнее.
| | |
| |
| 3.7, Аноним (-), 12:18, 04/02/2013 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> своими руками похерили совместимость
Совместимость чего с чем?
> воровать из OO решения
Это проблемы выбранной ими лицензии.
| | |
| 3.9, fi (ok), 12:29, 04/02/2013 [^] [^^] [^^^] [ответить]
| +4 +/– |
 > похерили совместимость
ага, костели выкинули :))))
последний 3.6 совсем супер - летает, удобен.
| | |
| 3.16, Xasd (ok), 13:52, 04/02/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > воровать из OO решения
это именно то самое деяние -- которым займутся проприетарщики, выпуская свой очередной
SuperMegaOffice Professionsl Edition 12.1 XT (cracked by 666xakerVasya666)
:-)
а вот LibreOffice -- это просто не надо. незачем потому что
| | |
| 3.25, Аноним (-), 22:06, 04/02/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> OO куда живее, чем LO.
Не заметно. У меня LO работает и каши не просит, в общем.
> А теперь, когда LO-шные клоуны
Лошный клоун - это вы про себя?
| | |
|
| 2.24, Аноним (-), 22:04, 04/02/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Я так понял MySQL скоро переползет на могильник Apache
У нее лицензия неправильная. Вот оракль и апачисты будут делить на 0 :)
> Не дай Боже этот финт повторится с VirtualBox...
А у нас KVM есть, нам пофигу.
| | |
| 2.29, Java coder (?), 02:38, 05/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
"Последний стабильный выпуск MariaDB 5.5 основан на кодовой базе MySQL 5.5 ... доступна ветка MariaDB 10, в которой выполняется работа по бэкпортированию изменений из экспериментальной ветки MySQL 5.6 ..."
Если он отправится на могильник, то откуда разработчики MariaDB будут бэкпортировать (слово то какое для простого слизывания кода) фичи?
| | |
|
| |
| 2.10, myhand (ok), 12:30, 04/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
 Ты таки хочешь сказать, что авторы MySQL в чем-то нарушили закон? Условия лицензии? Права на торговую марку?
Если бы MySQL продолжали развивать те загребущие руки, что его купили - он бы успешно конкурировал с форком.
| | |
| |
| |
| 4.14, Аноним (-), 13:27, 04/02/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Хочу сказать, что это не выгодно (покупать), вот и все.
Почему вы так решили?
| | |
| 4.17, myhand (ok), 14:03, 04/02/2013 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Хочу сказать, что это не выгодно (покупать), вот и все.
И сказал ты глупость.
Программный продукт, связанная с ним инфраструктура - не штабель кирпичей, к примеру. Кирпичи купил - и можешь на них радостно сидеть-свистеть. Захотел - сам дом из них построил. Захотел - продал через месяц/год/десять...
А программа, которую ты купил и на дальнейшее развитие которой забил - будет просто терять пользователей. И виноват в этом вовсе не Open Source, а только такой дурак как ты...
| | |
| 4.19, Аноним (-), 17:49, 04/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
Я не являюсь фанатом mysql, но объективности ради - это весьма востребованная система, и производитель на ней очень хорошо зарабатывал, так что Вы ошибаетесь. Проблема не в Open Source, а в дурном руководстве oracle. У sun этот самый mysql рос и плодоносил.
| | |
| |
| 5.21, myhand (ok), 20:49, 04/02/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> а в дурном руководстве oracle
Право, ничего дурного тут особо не видно. Oracle оно с самого начала нафиг нужно не было. Sun преобретался вовсе не из-за mysql, совсем нет.
Зачем развивать пускалку для собственной БД - понятно. А зачем развивать потенциальный конкурент этой БД?
| | |
| |
| 6.35, A. (?), 13:52, 05/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
Мне показалосьб, что MySQL в Oracle закрывал нишу простых и дешовых SQL баз (не путать с простейшими).
| | |
|
|
|
|
|
| 1.6, Аноним (-), 12:16, 04/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– |
Тоже мне мигранты.
Вот если бы они решили на PostgreSQL переехать - то была бы миграция.
| | |
| |
| 2.11, rshadow (ok), 13:03, 04/02/2013 [^] [^^] [^^^] [ответить]
| +4 +/– |
 На постгрис это ппц. Вообщем SQL у них похожий, но в мелочах настолько разный что хоть заново пиши...
| | |
| |
| 3.13, тфьу (?), 13:22, 04/02/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Вообщем SQL у них похожий, но в мелочах настолько разный что хоть заново пиши...
ANSI SQL, иначе сам виноват.
| | |
| |
| 4.15, Аноним (-), 13:30, 04/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> Вообщем SQL у них похожий, но в мелочах настолько разный что хоть заново пиши...
> ANSI SQL, иначе сам виноват.
ANSI SQL не стандартизирует индексы и такие критические вещи для web как блокировки.
| | |
| 4.20, Sinot (ok), 18:16, 04/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
 Это если пишешь систему подразумевающий выбор БД для использования. (Блог какой-нибудь)
А если такой надобности нет, почему бы не использовать фичи конкретной БД?
Аналогично писать проект Linux only и не использовать возможности доступные только для него.
| | |
| |
| 5.22, myhand (ok), 20:52, 04/02/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> А если такой надобности нет, почему бы не использовать фичи конкретной БД?
Потому, например, что "надобность" может возникнуть в будущем.
| | |
| |
| 6.27, Sinot (ok), 22:39, 04/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
Я понимаю, такие решения не могут быть универсальны для всех случаев. И каждый проект решает для себя сам что и как использовать. В том числе с перспективой на будущее.
Но ё мае, новые фичи вообще нельзя использовать что ли?
| | |
| 6.30, Crazy Alex (ok), 02:46, 05/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
 На практике - почти во всех случаях дешевле затачивать под конкретную базу. Если условия меняются так, что выбранная база не справляется, то затраты на адаптацию под что-то другое - мелочь в море других затрат. Собственно, если есть хоть какая-то внятная архитектура, то SQL довольно локализован. А если спагетти - то его рефакторинг с вероятностью даст эдак на порядок больше, чем переход на постгрес или ещё куда. Хотя в случае веба дешевле клепать костыли до последнего, тупо обкладываясь кэшами и кластерами.
| | |
| |
| 7.33, VoDA (ok), 11:06, 05/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
 > Хотя в случае веба дешевле клепать костыли до последнего, тупо обкладываясь кэшами и кластерами.
И не в вебе тоже ;)
По сути каждый раз есть выбор или вложить много и сделать качественное изменение кода или вложить мало и костылями решить локальные проблемы.
Вкладывать каждый раз по много и делать качественный рефакторинг получается слишком дорого на круг. А если постоянно экономить и костылить, то код очень быстро превратиться в лапшу, которую только выкинуть остается.
ИМХО золотая середина где то между этими подходами - раз в пол-года-год делается качественный рефакторинг, остальное время решаются локальные косяки.
| | |
|
|
|
|
|
|
| 1.18, VoDA (ok), 15:45, 04/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Минорное изменение.
Вот если бы они мигрировали инфраструктуру на единую распределенную СУБД типа ColumnFamily - вот это было бы и интереснее и полезнее. Особенно для распределенных проектов.
| | |
| |
| 2.31, Crazy Alex (ok), 02:48, 05/02/2013 [^] [^^] [^^^] [ответить]
| +/– | |
Видите ли, они заинтересованы прежде всего в результате - то есть живых и работающих веб-сайтах.
Проекты такого уровня даже постгрес переводить - заявка на суицид, что там говорить об экзотике...
| | |
| |
| 3.34, VoDA (ok), 11:10, 05/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Видите ли, они заинтересованы прежде всего в результате - то есть живых
> и работающих веб-сайтах.
Согласен - проще заменить на аналог, тем более совместимый по API, чем на другую систему хранения.
> Проекты такого уровня даже постгрес переводить - заявка на суицид, что там
> говорить об экзотике...
Это в краткосрочном периоде, а в долгосрочном наоборот. Сейчас у них система накостылена в виде несколько мастеров, куча слейвов, на мастера запись, со слейвов чтение. Различные разделы лежать в разных базах, на разных серверах. К этому зоопарку, конечно, привыкли, но админить его нужно. Переход на единую распределенную СУБД позволить сэкономить время админов. Плюс появятся новые возможности - тот же бэкап будет идти по всем данным википедии, а не только тому, что упало на конкретный слейв.
| | |
|
|
|
