| 1.6, DmA (??), 13:38, 20/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>>и для Python 3.7:
круто, в Центос 7 только 3.6 версия. Раньше в Солярке было всё наидревнейшее из "гнутого"
| | |
| |
| |
| 3.18, пох. (?), 16:54, 20/11/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
ну, sun когда-то попросил $100 за все сразу.
К сожалению, за годы чек на куске туалетной бумаги куда-то продолбался, не смотря на попытки его сохранить для потомков. Это был самый дорогой кусок опенсорсия, купленный мной за деньги (я еще и отдельно на растаможку попал).
| | |
|
|
| 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 и не полагается. Впрочем, он и многого другого не умел, включая $(), $(()) и прочее.
| | |
| |
| |
| 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.
| | |
|
|
|
|
|
| |
| 2.28, Ordu (ok), 00:35, 21/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
 Это ненадолго:
> В состав включён пакет cbindgen 0.8.7 (генератор Си-биндингов на основе кода на языке Rust); | | |
|
| 1.31, Vkni (ok), 07:31, 21/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Интересно, зачем там Rust, если кодогенератор из llvm в SPARC 64-bit, в общем-то, в экспериментальной стадии?
| | |
|
