На конференции OpenWorld 2011 компания Oracle объявила о намерении (http://www.oracle.com/us/corporate/press/512668) в ноябре выпустить релиз Solaris 11 (http://www.oracle.com/us/products/servers-storage/solaris/so...), предварительная версия которого в настоящее время проходит (http://www.opennet.me/opennews/art.shtml?num=31767) финальное тестирование среди партнёров. Solaris 11 будет доступен для 64-разрядных x86-систем и серверов на базе процессоров SPARC серии M и T. Поддержка неактуального оборудования, 32-битного ядра и старых моделей процессоров SPARC, включая UltraSparc IV+, прекращена (http://www.opennet.me/opennews/art.shtml?num=31037).
Отдельно отмечается расширение поддержки средств виртуализации и облачных вычислений, улучшение реализации средств для создания хранилищ на базе ZFS, оптимизация для продуктов Oracle, Java-приложений и промышленного программного обеспечения от сторонних производителей. В состав включена поддержка новых средств для ...URL: http://www.oracle.com/us/corporate/press/512668
Новость: http://www.opennet.me/opennews/art.shtml?num=31945
>>осуществлен переход на новый APT-подобный пакетный менеджер,это давно надо было сделать
вообщем интересные новшества готовятся, жаль что оракл зарезал возможность использования в коммерческих целях без покупки лицензии ((
Стырыли наверно у nexenta :-)
> Стырыли наверно у nexenta :-)OpenIndiana появилась раньше и некстента на ее кодовой базе. Яйцо было раньше.
> OpenIndiana появилась раньше и некстента на ее кодовой базе. Яйцо было раньше.AFAIK nexenta базировалась на OpenSolaris. Indiana и illumos появились позже.
> это давно надо было сделатьЭто уже сделано три года как :) Ян Мердок постарался, см. http://www.opennet.me/opennews/art.shtml?num=15719
Просто готовая к продакшену версия зрела 5 лет (первые Solaris Express выходили в 2006). Вот и созрела, наконец.
Чем он лучше старого? Старый 10 лет не менялся и был совершенно приемлемым, даже на уровне рефлекторных навыков. Определенно, попался сексуально неудовлетворенный индус - линуксоид, которому все не так, если имеет ФАТАЛЬНЫЙ НЕДОСТАТОК.Кстати, читай лицензии внимательно. Использовать ты можешь сколько угодно. Без технической поддержки. Ни единого патча не получишь без нее. Вообще. Даже фирмвари. У Оракла не лицензия как плата за использование. А плата за ДОСТУП К ТЕХПОДДЕРЖКЕ. Если ты способен коммерчески эксплуатировать критическую систему вообще без патчей и саппорта - флаг в руки, барабан на шею и исошник софта с otn,oracle.com. Вперед и с песнями. Только я сильно сомневаюсь, что без патчей твой солярис хотя бы квартал проживет.
Лучше тем, что поддерживаются зависимости штатными способами, а на самописными скриптами, скачивающими .pkg-файлики и работающими абы-как. Возможностью поиска пакета по файлу в репозитории не установленных пакетов. Гарантиями установки и обновления без привлечения пользователя - вы же не будете отрицать, что это была одна из самых больших головных болей при использовании старого пакетного менеджера?
А сами .pkg файлики у IPS-а появились? Или это так и останется SVR4-only фичей? А то достаточно неудобно, что установить что-либо можно только по сети из репозитария и никак иначе.
Можно иметь локальный репозитарий, не проблема (и даже очень легко) - но там пакет будет в виде набора файликов, данные-метаданные раздельно, а не в едином pkg.
Что касается неудобно. Не слишком удобно, но решение совершенно стандартное. Вот посмотрите на линукс: есть rpm и есть yum - rpm умеет работать с файликами, но yum не особенно - localinstall есть, конечно, но для всего остального нужен репозиторий с метаданными. Если вы возьмете "просто" пачку rpm, то без специальных команд создания репозитория, выделения метаданных итд вы не сможете знать о зависимостях между этими пакетами, не сможете нормально искать в них и т.д. Но вы можете создать репозиторий, создадутся метаданные, подключить это к yum и все будет работать.С IPS ровно та же история, но т.к. разделения на rpm и yum нет - инструмент интегрирован - работать можно только с репозиторием, где доступны метаданные всех пакетов из него. А сеть тут не при чем, точно так же как и с yum, вы можете иметь репозиторий в локальном каталоге.
>Если вы возьмете "просто" пачку rpm, то без специальных команд создания репозитория, выделения метаданных итд вы не сможете знать о зависимостях между этими пакетами, не сможете нормально искать в них и т.д.Ой насмешили. А теперь почитайте man rpm, ключевые слова query options.
Вы читали, что я написал или так, только пишете?Я понимаю, что rpm может прочесть все rpm'ки и держать в памяти метаданные на одну операцию. Только голый rpm не сможет даже поставить файл, который по зависимостям нужен данному. А yum, который сможет, уже требует репозитория с явными метаданными, а не rpm россыпью.
чукча не читатель, чукча отосрать про оракли и солярис пришел
> Что касается неудобно. Не слишком удобно, но решение совершенно стандартное.Оно нестандартное. Стандартное - это разделение пакетных менеджеров высокого и низкого уровней: apt/dpkg, apt/rpm, yum/rpm, zypper/rpm и т.д. При этом очень удобно, что есть доступ как к пакетному менеджеру высокого уровня, так и пакетному менеджеру низкого уровня. Если всё скрыть за ПМ высокого уровня, как в Solaris'е, для ряда задач система будет очень тормозной и неудобной.
Это так, но, я думаю, у них были свои причины. Менеджер пакетов низкого уровня в солярисе уже был, и по-прежнему поддерживается - но навернуть на него сверху новые возможности не вышло, так как потребовалось, например, вносить определенные ограничения по выполнению скриптов, чтобы улучшить совместимость обновлений в новой системе; наверное, были и другие причины.Чтобы сделать "как у всех", в солярке пришлось бы иметь две работающих системы менеджера пакетов низкого уровня + одну верхнего, совместимого только с одной из нижних. Это, вообще говоря, неприятно и вводит в заблуждения. Сейчас системы пакетов достаточно различны и особого беспорядка между ними нет. В общем, я не хочу сказать что IPS в текущем виде - идеал, но логика в том, что он такой, какой есть прослеживается.
> Чем он лучше старого?Он сам разрешает зависимости. Хотя бы поэтому.
>Старый 10 лет не менялся и был совершенно
> приемлемым, даже на уровне рефлекторных навыков.Вот-вот, на уровне рефлекторных навыков. Надо еще и головой пользоваться.
> Определенно, попался сексуально неудовлетворенный
> индус - линуксоид, которому все не так, если имеет ФАТАЛЬНЫЙ НЕДОСТАТОК.Товарищ Войнов, Вы бы ознакомились с предметом, прежде, чем писать глупость
не у себя в блоге, а тут. Дело не в недостатке, а в элементарном удобстве работы,
и упрощении в обслуживании. Хотя Вы на уровне рефлекторных навыков уже наверное
привыкли делать руками то, что еще в конце 90-х делали пакетные менеджеры.> Если ты способен коммерчески эксплуатировать критическую систему
> вообще без патчей и саппорта - флаг в руки, барабан на
> шею и исошник софта с otn,oracle.com. Вперед и с песнями. Только
> я сильно сомневаюсь, что без патчей твой солярис хотя бы квартал
> проживет.А как же утверждения в блоге о том, что это лучшая система? Я правильно понял,
что Солярис без патчей нельзя эксплуатировать в продакшене? И Вы эту особенность
выставляете как достижение? Без патчей он проживет сколько надо, если не действовать
на уровне рефлекторных навыков.
хорошая новость, будем использовать.
> новый APT-подобный пакетный менеджерОни постеснялись называть пакеты DEBами? :))
В альтлинуксе apt, но при этом rpm, а не deb. Или не так?
> В альтлинуксе apt, но при этом rpm, а не deb. Или не
> так?Так, так. Но ты не отвлекай убунтоидов от их трепа - они не любят вещи, которые не укладываются в те концепции, что у них в системе :)
Пакетный менеджер ни разу не АПТ-подобный. То есть вообще, если у вас конечно х*й не подобен пальцу потому что похожи по форме и можно одно заменить другим в некоторых случаях.
А почему maven никто не интегрирует в систему в качестве инструмента сборки, тестирования, инсталляции и сопровождения ПО? Универсальный инструмент же, особенно там, где Java везде понатыкана.
> А почему maven никто не интегрирует в систему в качестве инструмента сборки,
> тестирования, инсталляции и сопровождения ПО? Универсальный инструмент же, особенно там,
> где Java везде понатыкана.Потому что в солярке с типичным серверным окружением от джавы ничего, кроме какого-то гуя для настройки dhcp ничего не зависит - ее вообще можно снести, кроме dhcp никто и не заметит разницы. Зачем нужен maven и куча лишней возни с джавой, если сейчас джавы по сути нигде в системе нет и она никаким боком не сдалась?
Как можно выпускать релиз?! Что за лол!