Опубликовано обновление операционной системы (Support Repository Update), в котором предложена серия очередных исправлений и улучшений для ветки Solaris 11.4. Для установки предложенных в обновлении исправлений достаточно выполнить команду 'pkg update'...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=51901
>>и для Python 3.7:круто, в Центос 7 только 3.6 версия. Раньше в Солярке было всё наидревнейшее из "гнутого"
Python он сам по себе, к проекту GNU отношения не имеет.
Он даже к GPL отношения не имеет https://docs.python.org/3/license.html
и в 8-й тоже Python 3.6.8
SOLARIS - надёжно!!
По мильярду за строчку кода не попросят?
ну, sun когда-то попросил $100 за все сразу.
К сожалению, за годы чек на куске туалетной бумаги куда-то продолбался, не смотря на попытки его сохранить для потомков. Это был самый дорогой кусок опенсорсия, купленный мной за деньги (я еще и отдельно на растаможку попал).
месяц назад же было. чё у них обновления зачастили?
Подозреваю, диарея
Глянь новости по тегу. Месяц-два — это как обычно.
но апстримы коммитят каждый день
Мне интересно, из потешающихся тут над соляркой ее хоть кто-то вживую на Sun'овском железе видел? Может даже использовал?
Еще 12 лет назад там была куча фич, на которые иные и нынче надрачивают как на "революционные". ДБ!©
видел, использовал. Пользы от нее было - ровно ноль.> Еще 12 лет назад там была куча фич, на которые иные и нынче надрачивают как на "революционные".
большая часть этих фич работала только и исключительно на железе, ценой в неисчислимые миллиарды нефти. А такого вообще-то и без санов хватало. Кластер писюков из дерьма и палок обходился в сто раз дешевле и работал надежнее - потому что не требовал каждый раз дожидаться техподдержки, все можно было подпереть теми же палками и тем же дерьмом подмазать.
А то, что работало на железе, сравнимом по цене с писюковым - проигрывало и по наличию удобных технических средств, и банально по эффективности. Как и само железо.Кого еще удивляет, что они оказались на помойке?
Ну и да - перед началом работы установите-ка гигабайтик гнутого софта, а то то что лежит в /usr/bin - годится только чтоб выбросить. systemV, осенено благодатью AT&T, может еще лично Ритчи что-то тут трогал - код никто не шевелил тридцать лет, grep ломается об строку в 1024 символа (какая еще поддержка локалей, вы совсем тронулись?!).
В /usr/ucb/bin лежало еще более винрарное мамонтовое уг - унаследованное от sunos.Надеюсь, сейчас-то они хотя бы выбросили всю эту древность в помойку, или по прежнему три bin, из которых можно пользоваться только содержимым local/bin, и то с осторожностью?
вроде бы с 11 солярки всё это выкинули и /bin/sh теперь там нормальный ksh93, а не тот старый pre-posix артефакт, который даже `export VAR=value` не умел.
> ksh93а 93 - это актановое число?
зыж
все равно после покупки это даже не маргинальщина, а куда-то дальше.
ззыж
эт я так. поржать.
да, если что - работал. солярку знаю хорошо.
> актановое числоПрежде чем отправить очередную жалобу модератору, загляни всё-таки в учебник органической химии. Или хотя бы в орфографический словарь.
> не тот старый pre-posix артефакт, который даже `export VAR=value` не умел.export VAR=value по POSIX и не полагается. Впрочем, он и многого другого не умел, включая $(), $(()) и прочее.
> export VAR=value по POSIX и не полагается
Хм, да, и правда что. Почему-то отложилось, что это не только в соляре не работало.
> А то, что работало на железе, сравнимом по цене с писюковым - проигрывало и по наличию удобных технических средств, и банально по эффективности. Как и само железо.А написать то, что действительно требует машины с 128-ю потоками и полутерабайтом памяти, эффективно это самое используя, на языке C++ версии 03, будет стоить совершенно жутких усилий очень и очень квалифицированных людей. То есть, грубо говоря, невозможно.
> Надеюсь, сейчас-то они хотя бы выбросили всю эту древность в помойку, или по прежнему три bin, из которых можно пользоваться только содержимым local/bin, и то с осторожностью?
То же самое. Причём поддержку SPARC 32-bit откуда могли, оттуда выбросили к чёрту, а кодогенераторы SPARC 64-bit эти гении процессоростроения всегда старались держать при себе. :-)
Хотя, казалось бы, разумный разработчик нишевого процессора будет выдавать доступ к своим машинам любому, кто пишет компилятор, да и вообще выделит микроотдел из пары человек на разработку кодогенераторов ко всему, чему можно.
> Мне интересно, из потешающихся тут над соляркой ее хоть кто-то вживую на Sun'овском железе видел?Вчера, а что? Проблема как разработчиков SPARC, так и разработчиков MIPS в том, что они не понимают, что сами по-себе их процессоры никому не нужны. И без поддержки кодогенераторов с разных языков - это просто груда камней с пляжа в довольно унылых железках.
Какой смысл в замечательной Сановской Ниагаре с её 128-ю потоками и общей памятью, если единственные языки, способные нормально нагрузить это замечательное железо - Erlang, Haskell (GHC) и make? И при этом два из этих трёх не поддерживаются. А make поддерживается исключительно потому, что очень тяжело вообще без него обойтись.
А то, что предлагает Sun/Oracle - это разработка на Java и старом C++, которые предполагают чудовищных требований к квалификации для создания массивно многопоточных программ с общей памятью. Это вам не Хаскельный пакет STM, который выучивается и применяется за час.
Вот и получается, что машина есть, а используется как пачка четырёхядерных Ксеонов.
-------------------
Как обладатель Солярки дома могу ответственно заявить, что для десктопа оно не годидзе из-за совершенно серверного планировщика - не может нормально держать латентность при проигрывании видео MPlayer'ом.
дай угадаю - mplayer, естественно, целиком на процессоре (одном, поскольку плохо умеет параллелиться), никаких vaa в солярку даже x86 по сей день не завезли ? ;-)Он, если что, и на писюке в таком варианте не отличается особым темпераментом.
> Он, если что, и на писюке в таком варианте не отличается особым темпераментом.Linux из-за лучшей заточенности под десктоп, гоняет остальные задачи на другом процессоре.
> Ниагаре с её 128-ю потоками и общей памятью, если единственные языки, способные нормально нагрузить это замечательное железо - Erlang, Haskell (GHC) и makeНиагара отлично грузится кодом, написанным на Java, C и C++. ЧЯДНТ?
> Ниагара отлично грузится кодом, написанным на Java, C и C++. ЧЯДНТ?Вы зачем-то грузите очень недешёвую машину, являющуюся единой точкой отказа, вместо того, чтобы использовать кластер дешёвых PC.
>> Ниагара отлично грузится кодом, написанным на Java, C и C++. ЧЯДНТ?
> Вы зачем-то грузите очень недешёвую машину, являющуюся единой точкой отказа, вместо того,
> чтобы использовать кластер дешёвых PC.Как быть с единой точкой, когда таких машин несколько? Несколько десятков?
Какое отношение это всё имеет к Вашей реплике про Erlang и Haskell, и моему скромному на то возражению?
> Несколько десятков?Значит задачу можно распилить на несколько сотен писюков. Или даже виртуалок.
>А то, что предлагает Sun/Oracle - это разработка на Java и старом C++, которые предполагают чудовищных требований к квалификации для создания массивно многопоточных программ с общей памятью.Никаких шудовищных познаний там не надо. Достаточно самых стандартных знаний по разработке многопоточного софта по unix-like-и. Было однажды, скомпилировали самый обыкновенный Apache Traffic Server на спарковой соляре, оно просто взяло и заработало на всех ядрах из всех нескольких десятков под полной нагрузкой. А написан Apache TS самым стандартным образом.
> Достаточно самых стандартных знаний по разработке многопоточного софта по unix-like-и.Это означает, что алгоритм совершенно легко обозрим, и, скорее всего, раскладывается на кластер дешёвых PC. И никакой качественной выгоды от огромной машины с общей памятью нет.
То есть, это ну серия map-reduce максимум, а скорее просто один map-reduce.
Это уже другой вопрос. Выше поинт о том, что нет никакой проблемы нагрузить сановское многоголовое железо, для этого не нужно спец ЯП-ы и все прочие "спецы". Самое обыкновенное многопоточное ПО, написанное на любом ЯП, грузит это железо без проблем.
Нет, мой "пойнт", в том, что дабы _осмысленно_ нагрузить это дорогое железо, нужны спец. ЯП и прочие "спецы". С помощью Java/C++, разумеется, можно нагрузить эти машины; но те программы, которые можно написать на этих языках, как правило, легко пилятся на кластер почти независимых машин. Это кластер будет значительно дешевле, сильно удобнее, и несколько надежнее, чем одна большая Niagara.То есть, речь о задачах, которые требуют таких монстров, о задачах, которые при распиливании на груду PC, не связанных общей памятью, сильно проседают в производительности.
И вопрос именно этот - нет смысла покупать сложного дорогого монстра, если планируем нагружать его легко распиливаемой задачей. А нераспиливаемая задача требует значительно более серьезного контроля за изменяемым состоянием, чем может дать типичный высококвалифицированный разработчик на С++/Java.
Последний оплот здравомыслия в мире никсов.
Это ненадолго:> В состав включён пакет cbindgen 0.8.7 (генератор Си-биндингов на основе кода на языке Rust);
Соляра просто лучшая. Лaпче не понять.
А ты обоснуй! Или мир-дверь-мяч? Конкретику давай.
да они сами не знают чем Солярис лучше, лишь бы ляпнуть
- Армяне лучше чем грузины.
- Чем лучше?!
- Чем грузины...
Интересно, зачем там Rust, если кодогенератор из llvm в SPARC 64-bit, в общем-то, в экспериментальной стадии?