The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Обновление Oracle Solaris 11.4 SRU15

20.11.2019 12:58

Опубликовано обновление операционной системы Solaris 11.4 SRU 15 (Support Repository Update), в котором предложена серия очередных исправлений и улучшений для ветки Solaris 11.4. Для установки предложенных в обновлении исправлений достаточно выполнить команду 'pkg update'.

В новом выпуске:

  • До версии 19.4 обновлён Oracle Explorer, инструментарий для построения детального профиля конфигурации и состояния системы;
  • Добавлены новые модули для Python 3.7: pybonjour и pygobject3;
  • В состав включён пакет cbindgen 0.8.7 (генератор Си-биндингов на основе кода на языке Rust);
  • В RAD (Remote Administration Daemon), интерфейс для удалённого администрирования, добавлена поддержка Python 3.7;
  • Авторизация при помощи zlogin ограничена доступом только с консоли;
  • Обновлены версии программ: net-snmp 5.8, ruby 2.5.5/2.6.3, GCC 9.2, cmake 3.15.2 и nmap 7.80;
  • Обновлены версии с устранением уязвимостей: memcached 1.5.17, GnuPG 2.2.16, libarchive 3.4.0, Node.js 8.16.1, Rust 1.35.0, Cargo-vendor 0.1.23, libgcrypt 1.8.5, lighttpd 1.4.54, xdg-utils 1.1.3, mutt 1.12.1, GDB 8.3.1, squid 4.8, Thunderbird 68.2.0, Firefox 68.2.0esr, sudo 1.8.28.
  • Применены патчи с устранением уязвимостей в libtiff, Ghostscript, python requests, GNU patch, libsoup, liblouis, evince, librsvg.


  1. Главная ссылка к новости (https://blogs.oracle.com/solar...)
  2. OpenNews: Доступны OpenIndiana 2019.10 и OmniOS CE r151032, продолжающие развитие OpenSolaris
  3. OpenNews: Обновление Oracle Solaris 11.4 SRU14
  4. OpenNews: Oracle будет поддерживать Java SE 8/11 до 2030 года, а Solaris 11 до 2031 года
  5. OpenNews: Релиз Solaris 11.4
Лицензия: CC-BY
Тип: Программы
Ключевые слова: solaris
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (37) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.6, DmA (??), 13:38, 20/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >>и для Python 3.7:

    круто, в Центос 7 только 3.6 версия. Раньше в Солярке было всё наидревнейшее из "гнутого"

     
     
  • 2.9, Аноним (9), 14:14, 20/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Python он сам по себе, к проекту GNU отношения не имеет.
     
     
  • 3.16, Аноним (16), 15:14, 20/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Он даже к GPL отношения не имеет https://docs.python.org/3/license.html
     
  • 2.25, anonim1 (?), 23:16, 20/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    и в 8-й тоже Python 3.6.8
     

  • 1.7, Аноним (7), 13:47, 20/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    SOLARIS - надёжно!!
     
     
  • 2.17, Аноним (17), 16:13, 20/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    По мильярду за строчку кода не попросят?
     
     
  • 3.18, пох. (?), 16:54, 20/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну, sun когда-то попросил $100 за все сразу.
    К сожалению, за годы чек на куске туалетной бумаги куда-то продолбался, не смотря на попытки его сохранить для потомков. Это был самый дорогой кусок опенсорсия, купленный мной за деньги (я еще и отдельно на растаможку попал).

     

  • 1.8, б.б. (?), 13:51, 20/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    месяц назад же было. чё у них обновления зачастили?
     
     
  • 2.10, Аноним (9), 14:16, 20/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Подозреваю, диарея
     
  • 2.11, Sluggard (ok), 14:17, 20/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Глянь новости по тегу. Месяц-два — это как обычно.
     
  • 2.12, Аноним (12), 14:17, 20/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    но апстримы коммитят каждый день
     

  • 1.13, Аноним (13), 14:24, 20/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Мне интересно, из потешающихся тут над соляркой ее хоть кто-то вживую на Sun'овском железе видел? Может даже использовал?
    Еще 12 лет назад там была куча фич, на которые иные и нынче надрачивают как на "революционные". ДБ!©
     
     
  • 2.14, пох. (?), 14:43, 20/11/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    видел, использовал. Пользы от нее было - ровно ноль.

    > Еще 12 лет назад там была куча фич, на которые иные и нынче надрачивают как на "революционные".

    большая часть этих фич работала только и исключительно на железе, ценой в неисчислимые миллиарды нефти. А такого вообще-то и без санов хватало. Кластер писюков из дерьма и палок обходился в сто раз дешевле и работал надежнее - потому что не требовал каждый раз дожидаться техподдержки, все можно было подпереть теми же палками и тем же дерьмом подмазать.
    А то, что работало на железе, сравнимом по цене с писюковым - проигрывало и по наличию удобных технических средств, и банально по эффективности. Как и само железо.

    Кого еще удивляет, что они оказались на помойке?

    Ну и да - перед началом работы установите-ка гигабайтик гнутого софта, а то то что лежит в /usr/bin - годится только чтоб выбросить. systemV, осенено благодатью AT&T, может еще лично Ритчи что-то тут трогал - код никто не шевелил тридцать лет, grep ломается об строку в 1024 символа (какая еще поддержка локалей, вы совсем тронулись?!).
    В /usr/ucb/bin лежало еще более винрарное мамонтовое уг - унаследованное от sunos.

    Надеюсь, сейчас-то они хотя бы выбросили всю эту древность в помойку, или по прежнему три bin, из которых можно пользоваться только содержимым local/bin, и то с осторожностью?

     
     
  • 3.19, анончик (?), 17:10, 20/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    вроде бы с 11 солярки всё это выкинули и /bin/sh теперь там нормальный ksh93, а не тот старый pre-posix артефакт, который даже 'export VAR=value' не умел.
     
     
  • 4.24, ананим.orig (?), 19:38, 20/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > ksh93

    а 93 - это актановое число?

    зыж
    все равно после покупки это даже не маргинальщина, а куда-то дальше.
    ззыж
    эт я так. поржать.
    да, если что - работал. солярку знаю хорошо.

     
     
  • 5.35, Sgt. Gram (?), 13:26, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > актановое число

    Прежде чем отправить очередную жалобу модератору, загляни всё-таки в учебник органической химии. Или хотя бы в орфографический словарь.

     
  • 4.34, Аноним (34), 13:24, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > не тот старый pre-posix артефакт, который даже 'export VAR=value' не умел.

    export VAR=value по POSIX и не полагается. Впрочем, он и многого другого не умел, включая $(), $(()) и прочее.

     
     
  • 5.36, анончик (?), 15:54, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > export VAR=value по POSIX и не полагается

    разве?
    https://www.unix.com/man-page/POSIX/1posix/export/

     
     
  • 6.38, Аноним (34), 19:20, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Хм, да, и правда что. Почему-то отложилось, что это не только в соляре не работало.
     
  • 3.30, Vkni (ok), 07:30, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > А то, что работало на железе, сравнимом по цене с писюковым - проигрывало и по наличию удобных технических средств, и банально по эффективности. Как и само железо.

    А написать то, что действительно требует машины с 128-ю потоками и полутерабайтом памяти, эффективно это самое используя, на языке C++ версии 03, будет стоить совершенно жутких усилий очень и очень квалифицированных людей. То есть, грубо говоря, невозможно.

    > Надеюсь, сейчас-то они хотя бы выбросили всю эту древность в помойку, или по прежнему три bin, из которых можно пользоваться только содержимым local/bin, и то с осторожностью?

    То же самое. Причём поддержку SPARC 32-bit откуда могли, оттуда выбросили к чёрту, а кодогенераторы SPARC 64-bit эти гении процессоростроения всегда старались держать при себе. :-)

    Хотя, казалось бы, разумный разработчик нишевого процессора будет выдавать доступ к своим машинам любому, кто пишет компилятор, да и вообще выделит микроотдел из пары человек на разработку кодогенераторов ко всему, чему можно.

     
  • 2.29, Vkni (ok), 07:00, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне интересно, из потешающихся тут над соляркой ее хоть кто-то вживую на Sun'овском железе видел?

    Вчера, а что? Проблема как разработчиков SPARC, так и разработчиков MIPS в том, что они не понимают, что сами по-себе их процессоры никому не нужны. И без поддержки кодогенераторов с разных языков - это просто груда камней с пляжа в довольно унылых железках.

    Какой смысл в замечательной Сановской Ниагаре с её 128-ю потоками и общей памятью, если единственные языки, способные нормально нагрузить это замечательное железо - Erlang, Haskell (GHC) и make? И при этом два из этих трёх не поддерживаются. А make поддерживается исключительно потому, что очень тяжело вообще без него обойтись.

    А то, что предлагает Sun/Oracle - это разработка на Java и старом C++, которые предполагают чудовищных требований к квалификации для создания массивно многопоточных программ с общей памятью. Это вам не Хаскельный пакет STM, который выучивается и применяется за час.

    Вот и получается, что машина есть, а используется как пачка четырёхядерных Ксеонов.

    -------------------
    Как обладатель Солярки дома могу ответственно заявить, что для десктопа оно не годидзе из-за совершенно серверного планировщика - не может нормально держать латентность при проигрывании видео MPlayer'ом.

     
     
  • 3.33, пох. (?), 10:00, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    дай угадаю - mplayer, естественно, целиком на процессоре (одном, поскольку плохо умеет параллелиться), никаких vaa в солярку даже x86 по сей день не завезли ? ;-)

    Он, если что, и на писюке в таком варианте не отличается особым темпераментом.

     
     
  • 4.42, Vkni (ok), 23:40, 23/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Он, если что, и на писюке в таком варианте не отличается особым темпераментом.

    Linux из-за лучшей заточенности под десктоп, гоняет остальные задачи на другом процессоре.

     
  • 3.37, exSun (ok), 16:19, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Ниагаре с её 128-ю потоками и общей памятью, если единственные языки, способные нормально нагрузить это замечательное железо - Erlang, Haskell (GHC) и make

    Ниагара отлично грузится кодом, написанным на Java, C и C++. ЧЯДНТ?

     
     
  • 4.41, Vkni (ok), 21:01, 23/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Ниагара отлично грузится кодом, написанным на Java, C и C++. ЧЯДНТ?

    Вы зачем-то грузите очень недешёвую машину, являющуюся единой точкой отказа, вместо того, чтобы использовать кластер дешёвых PC.

     
     
  • 5.43, exSun (ok), 14:49, 24/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ниагара отлично грузится кодом, написанным на Java, C и C++. ЧЯДНТ?
    > Вы зачем-то грузите очень недешёвую машину, являющуюся единой точкой отказа, вместо того,
    > чтобы использовать кластер дешёвых PC.

    Как быть с единой точкой, когда таких машин несколько? Несколько десятков?

    Какое отношение это всё имеет к Вашей реплике про Erlang и Haskell, и моему скромному на то возражению?

     
     
  • 6.44, Vkni (ok), 19:56, 24/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Несколько десятков?

    Значит задачу можно распилить на несколько сотен писюков. Или даже виртуалок.

     
  • 3.39, Аноним (39), 19:25, 23/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >А то, что предлагает Sun/Oracle - это разработка на Java и старом C++, которые предполагают чудовищных требований к квалификации для создания массивно многопоточных программ с общей памятью.

    Никаких шудовищных познаний там не надо. Достаточно самых стандартных знаний по разработке многопоточного софта по unix-like-и. Было однажды, скомпилировали самый обыкновенный Apache Traffic Server на спарковой соляре, оно просто взяло и заработало на всех ядрах из всех нескольких десятков под полной нагрузкой. А написан Apache TS самым стандартным образом.

     
     
  • 4.40, Vkni (ok), 21:00, 23/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Достаточно самых стандартных знаний по разработке многопоточного софта по unix-like-и.

    Это означает, что алгоритм совершенно легко обозрим, и, скорее всего, раскладывается на кластер дешёвых PC. И никакой качественной выгоды от огромной машины с общей памятью нет.

    То есть, это ну серия map-reduce максимум, а скорее просто один map-reduce.

     
     
  • 5.45, Аноним (45), 19:33, 25/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это уже другой вопрос. Выше поинт о том, что нет никакой проблемы нагрузить сановское многоголовое железо, для этого не нужно спец ЯП-ы и все прочие "спецы". Самое обыкновенное многопоточное ПО, написанное на любом ЯП, грузит это железо без проблем.
     
     
  • 6.46, Vkni (ok), 22:03, 25/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, мой "пойнт", в том, что дабы _осмысленно_ нагрузить это дорогое железо, нужны спец. ЯП и прочие "спецы". С помощью Java/C++, разумеется, можно нагрузить эти машины; но те программы, которые можно написать на этих языках, как правило, легко пилятся на кластер почти независимых машин. Это кластер будет значительно дешевле, сильно удобнее, и несколько надежнее, чем одна большая Niagara.

    То есть, речь о задачах, которые требуют таких монстров, о задачах, которые при распиливании на груду PC, не связанных общей памятью, сильно проседают в производительности.

    И вопрос именно этот - нет смысла покупать сложного дорогого монстра, если планируем нагружать его легко распиливаемой задачей. А нераспиливаемая задача требует значительно более серьезного контроля за изменяемым состоянием, чем может дать типичный высококвалифицированный разработчик на С++/Java.

     

  • 1.15, Аноним (15), 15:12, 20/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Последний оплот здравомыслия в мире никсов.
     
     
  • 2.28, Ordu (ok), 00:35, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это ненадолго:

    > В состав включён пакет cbindgen 0.8.7 (генератор Си-биндингов на основе кода на языке Rust);

     

  • 1.21, Аноним (21), 18:01, 20/11/2019 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • +1 +/
     
     
  • 2.22, Аноним (22), 18:29, 20/11/2019 Скрыто модератором
  • –1 +/
     
     
  • 3.23, Васька кот (?), 19:34, 20/11/2019 Скрыто модератором
  • +3 +/
     
  • 2.27, xm (ok), 00:18, 21/11/2019 Скрыто модератором
  • +/
     

     ....ответы скрыты модератором (3)

  • 1.31, Vkni (ok), 07:31, 21/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, зачем там Rust, если кодогенератор из llvm в SPARC 64-bit, в общем-то, в экспериментальной стадии?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру