![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
(no subject)
http://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, то теперь этой опции нет.
no subject
RHEL и Debian stable — вполне пригодные для бизнеса платформы, для которых тестирование даже минорных апдейтов почти всегда можно организовать (что большой бизнес нередко делает). Косяк с long long int, проявившийся в бизнес-логике — это один случай на миллион.
Oracle, само собой, is pure evil.
no subject
Тогда оно будет обновлено, чо. "тут критикал - мы сейчас будем обновлять препрод, валидируйте асап".
> для которых тестирование даже минорных апдейтов почти всегда можно организовать (что большой бизнес нередко делает)
в случае ASP - у тебя стопицот клиентов, у которых тристапицот приложений от быдлокодеров. Не можешь ты их регулярно тестировать.
При этом доступ клиента к его серверам ограничен а приложения работают с пониженными привилегиями. Системная часть, за которую ты действительно отвечаешь - несомненно, RHEL, саппорт и всё такое. Там всякие кластера, саны, разная хрень.
> Получается конструкция из спичек и клея, которая работает только при условии «громко не дышите»
Бггг, редхатское кластерное решение само по себе представляет такую конструкцию. Я его условно-готов разворачивать только при наличии оплаченного саппорта в редхате. А linux-ha не готов вообще.
> Косяк с long long int, проявившийся в бизнес-логике — это один случай на миллион.
А вот ещё один случай из редхата. Пресловутый rhcs - cman, rgmanager, блаблабла и snmpd-плагин для всего этого. Однажды после апгрейда - snmpd взял и сдох. Потому что cman притащил новый плагин, который оказался недолинкован и соответственно не загружался. О да, тикет в сапорте, через несколько часов новая версия пакета, всё починено все улыбаются. Но зачем.