(no subject)
Sunday, 4 September 2011 15:26![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
gns_uahttp://www.linux.org.ru/news/java/6676994/
Оракл, возможно, "хороший" и имеет в виду усилия по консолидации платформы.
Объясню.
В модели, с которой я имел дело несколько лет, все эти ваши пакетные джавы, пэхапэшки, и проч. не рассматривались вообще. Клиент за свои приложения отвечает сам. При развёртывания, клиент запрашивает конкретные версии джав, пэхапэшек и рубей. JRE/JDK ставится с сайта, томкаты всякие etc ставятся компилированные, с сайта, в /opt. руби ставится через rvm, php по возможности собирается в /opt, апач по возможности собирается в /opt. Фреймворки либо приложение таскает в себе, либо ставятся опять же из тарбола в известное место.
Всё это в итоге составляет платформу, и обновлению платформа не подлежит. Никому не надо снова и снова заниматься тестированием и валидацией клиентских приложений и отлавливанием неочевидных багов. Тем более никому не надо чтобы через месяц после очередного апдейта ВНЕЗАПНО оказалось что у клиента приложение считает бабки неправильно, и уже насчитало на пару миллионов евро.
Клиент принимает и валидирует платформу с установленным приложением - И ВСЁ. Обновления компонентов делается либо по запросу клиента, либо, если сильно надо, клиенту предлагается апдейт и дальше опять-таки по его запросу. Даже редхатовские апдейты, строго сохраняющие версию и точечно бэкпортящие фиксы, неприемлемы. Потому что _вот_это_вот_ конкретное приложение редхат _не_ тестировал.
Когда-то я видел, как субминорный апдейт php принёс исправление ошибки в работе с long long int; это действительно была ошибка и она действительно была корректно исправлена; беда в том, что на ошибочный результат вычислений полагался код работы с google analytics - и он, соответственно, сломался. В апдейте апача могут немножечко изменить некоторые дефолты - и тщательно оттюненный под заданную нагрузку конфиг перестанет быть адекватным. И так далее.
Поэтому, ничего плохого для Биг Сириоуз Бизнес оракл не сделал. Что он сделал, так это заставил дистрибутивных мейнтейнеров пакетов с джава софтом - обеспечить корректную работу своего софта на openjdk. Если раньше можно было поставить в зависимости конкретно sun-java, то теперь этой опции нет.
Оракл, возможно, "хороший" и имеет в виду усилия по консолидации платформы.
Объясню.
В модели, с которой я имел дело несколько лет, все эти ваши пакетные джавы, пэхапэшки, и проч. не рассматривались вообще. Клиент за свои приложения отвечает сам. При развёртывания, клиент запрашивает конкретные версии джав, пэхапэшек и рубей. JRE/JDK ставится с сайта, томкаты всякие etc ставятся компилированные, с сайта, в /opt. руби ставится через rvm, php по возможности собирается в /opt, апач по возможности собирается в /opt. Фреймворки либо приложение таскает в себе, либо ставятся опять же из тарбола в известное место.
Всё это в итоге составляет платформу, и обновлению платформа не подлежит. Никому не надо снова и снова заниматься тестированием и валидацией клиентских приложений и отлавливанием неочевидных багов. Тем более никому не надо чтобы через месяц после очередного апдейта ВНЕЗАПНО оказалось что у клиента приложение считает бабки неправильно, и уже насчитало на пару миллионов евро.
Клиент принимает и валидирует платформу с установленным приложением - И ВСЁ. Обновления компонентов делается либо по запросу клиента, либо, если сильно надо, клиенту предлагается апдейт и дальше опять-таки по его запросу. Даже редхатовские апдейты, строго сохраняющие версию и точечно бэкпортящие фиксы, неприемлемы. Потому что _вот_это_вот_ конкретное приложение редхат _не_ тестировал.
Когда-то я видел, как субминорный апдейт php принёс исправление ошибки в работе с long long int; это действительно была ошибка и она действительно была корректно исправлена; беда в том, что на ошибочный результат вычислений полагался код работы с google analytics - и он, соответственно, сломался. В апдейте апача могут немножечко изменить некоторые дефолты - и тщательно оттюненный под заданную нагрузку конфиг перестанет быть адекватным. И так далее.
Поэтому, ничего плохого для Биг Сириоуз Бизнес оракл не сделал. Что он сделал, так это заставил дистрибутивных мейнтейнеров пакетов с джава софтом - обеспечить корректную работу своего софта на openjdk. Если раньше можно было поставить в зависимости конкретно sun-java, то теперь этой опции нет.
