Компания Oracle представила (https://lists.debian.org/debian-sparc/2015/10/msg00012.html) первый выпуск проекта Linux SPARC (https://oss.oracle.com/projects/linux-sparc/), в рамках которого проведена работа по адаптации Linux для современного оборудования SPARC. В качестве основы использовано ядро Linux 4.1 и пользовательское окружение на базе пакетов Oracle Linux 6 для архитектуры x86_64, которые расширены специфичными для SPARC оптимизациями.
Linux SPARC можно рассматривать как полноценную 64-разрядную операционную систему, которая может работать на 64-разрядных процессорах SPARC. Размер установочного образа (https://oss.oracle.com/linux-sparc/isos/) 521 Мб. Поддерживается как установка на конечное оборудование, так и использование в виртуальных окружениях Oracle VM Server for SPARC. Из поддерживаемого оборудования отмечаются серверы на базе процессоров с архитектурой sun4v, такие как UltraSPARC T, SPARC T4, SPARC T5, SPARC M5 и Fujitsu SPARC64-X.
Компания Oracle позиционирует Linux SPARC не как отдельно поддерживаемый продукт, а как эталонную платформу, рассчитывая, что созданные наработки будут интегрированы в развиваемые сообществом основные проекты, такие как ядро Linux.
URL: https://lists.debian.org/debian-sparc/2015/10/msg00012.html
Новость: http://www.opennet.dev/opennews/art.shtml?num=43112
Вот это новость.
Прочитал еще раз, это только sun4v. Беда, печаль.
Ну так старое сановское борохло оракл не хочит поддерживать даже в Solaris 11.
Что в конечном счёте сыграло против них же — кастомеры теперь предпочитают свалить вообще с этой (уже!) маргинальной платформы, чем вляпываться в неё ещё раз.Нда, а ведь сановские железки были очень качественными. Заводились и были почти(!) актуальными и через дцать лет...
> Заводились и были почти(!) актуальными и через дцать лет...И кому нах...й это надо?
Установил сервер, настроил, софт затюнинговал - ...издуй, уволен!
А так, геи-дезигнеры понакрутят фичек красивых, что аж 64-ядерный Хеон перегревается,
опа у тебя опять есть работа - апгрейд всего парка серверов.
Так и есть. У нас в Красноярске интеграторы Линукс-систем нахухоль не нужны. Проводил исследование рынка, нашёл 4 фирмы. Одна - мои бывшие преподы с ФИПУ и их товарищи, 2я - конторка в закутке продуктовой базы, 3я закрылась, 4я - СофтЛайн, но там всеми фибрами отговаривают от Линукса и впаривают сами_знаете_что...
А виндузятниковых больше 100, и у всех клиенты. Потому что то вирусня, то обновление кривое, то лицензирование, то апгрэйд под новый фотожоп. Заодно и роутер настроить который стоит 1500р, чтобы не тормозил.
Печально это всё. С экранов говорящие головы рассуждают про инновации и импортозамещение, а у нас на 6м курсе в группе программистов нет ни 1го Линуксоида. Кроме меня. Кто водилой работает, кто в деревне "бизнес" делает, свиней разводит. Девушка одна сотики продаёт, ещё один торговым представителем.
А что инновационного в Линуксе? Как линуксоид с 10 летним опытом, живущий тоже в Красноярск, скажу, что тебе ещё не поздно чем-то более перспективным заняться.А девушке, разводящей свиней респект. Фермером быть тяжелее, чем линуксоидом.
>Прочитал еще раз, это только sun4v. Беда, печаль.Чем читали если не секрет?
>Из поддерживаемого оборудования отмечаются серверы на базе процессоров с архитектурой sun4v, такие как UltraSPARC T, SPARC T4, SPARC T5, SPARC M5 и Fujitsu SPARC64-X.
>Fujitsu SPARC64-Xhttp://www.fujitsu.com/global/products/computing/servers/uni...
Или этот монстр для вас уже устарел?
Новое спаркожелезо мне лично не интересно и не нужно. А вот на такое:http://www.oracle.com/ru/products/servers-storage/servers/sp...
я бы линукс поставить не отказался, а вот хрен ибо sun4u.
>Или этот монстр для вас уже устарел?Нет - он умер не родившись. Никто не покупает спраки энимор.
У меня Ынтерпрайз чеыре куска ___11___ лет в продакшене оттрубил, подставкой для оракала, но то другая эпоха, забыли, забили.
Fujitsu SPARC64-X это sun4v. Он совершенно не устарел, не надо его путать с OPL-серией (M3000, M4000, M5000, M8000, M9000), которые были sun4u.Чтоб не быть голословным, первое
# prtdiag | grep System
System Configuration: Oracle Corporation sun4v SPARC M10-4Sи второе
# prtdiag | grep System
System Configuration: Oracle Corporation sun4u SPARC Enterprise M5000 Server
Так что теперь есть смысл мигрировать Оракл БД из Солярис ОС без потери производительности?
да, на AIX
Пару пива этому энтерпрайзщику за мой счет.
Когда ынтырпрайзщику наливают даром, значит где-то в другом крупно кидают.
Так что лучше налом. 10% хватит. :D
Почти стихи: даром - налом, кидают - хватают )))
Да если бы хватали, будильники на руках бы не считали.И ярды по комнатам квартиры не находили. А меньшими траншами :D
Зыж
"Не льстите себе, вы не от КГБ за бугор сбежали, а от ОБХСС". (Не помню кто)
почему на AIX'то ? какие-то ограничения oracle на x86_64 ?
Потому что любителям проприетарщины одного урока бывает недостаточно. Только когда AIX'а и HP-UX'а не станет, тогда начнут догадываться, что тут что-то не так.
> Только когда AIX'а и HP-UX'а не станет, тогда начнут догадываться, что тут что-то не так.Ты из села Кукуево? Просто HP-UX _уже_ и нет вместе с титаником. Только голубые и держатся. Ну дык потому И :)
Не понимаю, почему наши клепают ни с чем не совместимую систему команд Эльбрус, со своим сырым компиллятором, вместо того чтобы взять готовый стек SPARC: ОpenSparc T2, поддержку в ядре, поддержку в распространенных дистрибутивах, поддержку в Java, все протестированно вдоль и поперек.К чему этот мазохизм импортозамещения опенсорса?
Делают же МЦСТ R1000, только он слабый для гражданки относительно других конкурентов с архитектурой SPARC v9. Но для СПРН сойдет.
> Делают же МЦСТ R1000, только он слабый для гражданки относительно других конкурентов
> с архитектурой SPARC v9. Но для СПРН сойдет.На спарку можно найти много применений.
>> с архитектурой SPARC v9. Но для СПРН сойдет.
> На спарку можно найти много применений.А смысл выёживаться? Уже купили оба - и MIPS64 и ARM64, на которых есть _всё_, ну так и напуркуа SPARC ?
Sparc T и производительность - две вещи несовместные. Пусть уж лучше эльбруса пилят.
> Sparc T и производительность - две вещи несовместные.Добро пожаловать в мир T4, T5, а скоро и T7.
> Не понимаю, почему наши клепают ни с чем не совместимую систему команд ЭльбрусПотому что в обозримом будущем, даже в условиях кризиса, догнать китайцев по ценам шансов никаких. Поэтому разработка чего-то идеально совместимого будет очевидно бессмысленной тратой времени и денег - примерно так же, как работа над сугубо российским водопроводным краном, приводящая к тому же результату, что и покупка китайского, только с лишними затратами.
такие рассуждения приводят к плачевным последствиям: Китайцы сели и разработали, хотя у всех он есть, а нам не выгодно, ведь китайцы уже сделали... В итоге у нас ничего своего и не будет... А ведь можно сделать и вытеснить и китайцев и остальных... Сначала будет тяжело, работа почти в минус, но результат будет колоссальный если покупатель поверит в нашу продукцию
> Не понимаю, почему наши клепают ни с чем не совместимую систему команд ЭльбрусОчевидно, потому что задачи совместимости не стояло (как, впрочем, и не с чем было "совмещаться" тогда, насколько помню).
> со своим сырым компиллятором
Не совсем своим, увы. А вот ощущения сырости у меня он не вызвал, но да, gcc он прикидывается стареньким.
> вместо того чтобы взять готовый стек SPARC
> К чему этот мазохизм импортозамещения опенсорса?
Вы более чем в состоянии поискать ответы на уже сформулированные (без эмоций) вопросы самостоятельно, правда? :)
В советские времена были свои компьютеры на уровне американских до памятного решения о копировании IBM System/360 в виде ряда ЕС. Что, этого урока недостаточно? Своё нужно делать, потому что копирующий всегда догоняет, а перегнать никогда не сможет.
Потому, что бы ракета летела точно и хорошо ) и не должно быть совместимости ) что бы ни один американский гринго не догадался )Златоусте )
Ахах, поздно пить боржоми, господа из Оракл, отгнил ваш спарк. Хотя лично я о нём сожалею.
Debian поддерживает SPARC v9, а чем их оракловое Кунг-Фу круче дебиановского - внятно не объяснили.
debian дропнул sparc весной , потому что не нашлось суппортеров на архитектуру , см. https://lists.debian.org/debian-sparc/2015/07/msg00012.html
Мельком видел одну железку -- вроде, sun4w архитектура. В центре системы находился некий коммутатор, позволяющий создавать хардварные партиции с электрической изоляцией. Можно было мощь сервера поделить на 1, 2 или 4 части, решив, сколько процессоров, жёстких дисков и сетевых карт достанется каждой партиции. К сожалению, линукс работал только на встроенном управляющем компе. А на основных процессорах запустить его не удалось. К тому же, всякие вкусности, типа получение операционкой на лету сообщения от BIOS'а о том, что сбойнул модуль памяти, чтобы занести его в чёрный список, поддерживались только соляркой.У других производителей такой архитектуры пока не встречал.
В общем, я только за поддержку линукса везде и всюду.А, вообще, спарки круты именно детектированием ошибок везде -- в процессорах, в памяти и т.д. При этом, у них, как я понимаю, у одних из первых появилась горячая замена процессоров. Видел картинку, на которой схематично была изображена зона покрытия кристалла процессора -- области, ошибки в которых система может обнаруживать -- был покрыт почти весь процессор. Помню, на одной интеловской конференции лет пять назад они хвастались, что наконец-то (!) их топовый серверный процессор по уровню защищённости может сравниться с таким-то допотопным спарком. ;-) Как числодробилки, интел может и делает спарки по производительности, а, вот, в плане надёжности для mission critical задач, спарки -- одни из лучших на планете. И поддержка линукса позволит активнее их использовать.
> Мельком видел одну железкуЕсли бы вы видели их железки не мельком, вы бы имели несколько другое мнение.
Какое же?
у меня SF880 пережил 5 поколений х86, да и сейчас пыхтит - 2 проца на днях вылетело, но он работает
Ну, так и я о том, что они хороши. :-)
По нынешним временам это прикольно, но совершенно излишне. Появились проблемы - выгнал виртуалки на соседнее железо, это заменил. С шансами - на более экономичное и вообще более выгодное.Разве что что-то совсем встроенное, но там, вроде спарки не применялись?
> По нынешним временам это прикольно, но совершенно излишне. Появились проблемы - выгнал
> виртуалки на соседнее железо, это заменил. С шансами - на более
> экономичное и вообще более выгодное.
> Разве что что-то совсем встроенное, но там, вроде спарки не применялись?Одноразовое поколение выросло. Потреблятство изо всех щелей прёт.
Представьте себе несколько тысяч серверов. "Появились проблемы - выгнал виртуалки на другое железо" - это толпа дармоедов на поддержку всего этого говна нужна. Потому что аварийную ситуацию нужно вовремя обнаружить, вручную подать команду на миграцию, потом вручную же железо менять. А железка, работающая без сбоев хотя бы по аппаратной части десятилетия - это совсем другой уровень.
>> По нынешним временам это прикольно, но совершенно излишне. Появились проблемы - выгнал
>> виртуалки на соседнее железо, это заменил. С шансами - на более
>> экономичное и вообще более выгодное.
>> Разве что что-то совсем встроенное, но там, вроде спарки не применялись?
> Одноразовое поколение выросло. Потребляtство изо всех щелей прёт.
> Представьте себе несколько тысяч серверов. "Появились проблемы - выгнал виртуалки на другое
> железо" - это толпа дармоедов на поддержку всего этого гoвна нужна.
> Потому что аварийную ситуацию нужно вовремя обнаружить, вручную подать команду на
> миграцию, потом вручную же железо менять. А железка, работающая без сбоев
> хотя бы по аппаратной части десятилетия - это совсем другой уровень.Не мечи бисер, Паладины Локалхоста никогда не просекут, что такое 9 лет аптайма.
А что тут просекать - это значит, что железка потребила электроэнергии в разы больше, чем суммарная стоимость всего, на что её стоило бы заменить, любые процедуры на случай выхода из строя давно неактуальны, а когда с этой железкой что-то всё же случится - не будет ни доступа к комплектующим для замены, ни простых способов миграции на современное железо.
Я, конечно,от дел админских отошел, но в тех же облаках это сколько лет как автоматизировано? Да про DevOps мне тут давеча рассказывали - какая, на фиг, толпа дармоедов? Или аварийные ситуации вы обнаруживаете посредством телепатии? А раз нет - то соответствующая логика может и без человека обойтись в большинстве случаев.А железо - да, вручную менять. Спокойно и по расписанию - из ваших тысяч серверов вряд ли в день будет больше пары-тройки из строя выходить - так что необходимости в толпе не вижу. С вероятностью, кстати, менять надо ещё до износа, просто по причине появления более эффективного оборудования. Так же, как сейчас выгодно заменять абсолютно рабочие люминесцентные лампы (не говоря о лампах накаливания) на светодиоды - на электричестве отбивается за год.
Но это ж учитывать много факторов надо, "многоразовые" замшелые товарищи этого не умеют. им главное - чтобы не менялось ничего. Запустили паровой котёл - он и пыхтит, они и рады, угольку подкидывают, и плевать на хреновый КПД и копоть кругом.
Угу. А перед тем, как понть, что виртуалки надо выгонять именно отсюда - побегать в тёмной комнате за отсутствующей там чёрной кошкой, исключая подозрения на ошибки в софте.
> Угу. А перед тем, как понть, что виртуалки надо выгонять именно отсюда
> - побегать в тёмной комнате за отсутствующей там чёрной кошкой,
> исключая подозрения на ошибки в софте.Из виртуалок он видел только ВиртуалБокс на десктопе, кому ты это говоришь....
Не неси чушь, а? У облачников (амазон тот же, хотя ещё NetFlix с их ChaosMonkey вспоминается) это сто лет, как отработано. Но да, софт на это должен быть заточен маленько. На круг - выгоднее, чем держать древние железки и админов, у которых секретные знания в голове, а не в репозитории со стандартными алгоритмами когда что делать. На том, в общем-то, облака и держатся.
Возможно для RISC машинок IBM в этом ничего нового. Пусть кто-нибудь скажет за голубых! :-)
Я скажу против. ;-)Возьмём, например, IBM Power 6 (с коим имел дело). У него есть один ЦПУ и 6 вычислительных недопроцессоров (SPU). Я не знаю, как это работает в AIX'е, а в Linux'е получается, что у этих SPU есть отдельная урезанная таблица системных вызовов. Ну, и как под это писать? :-)
Идём далее. Инжинеры ИБМ решили, что инструкция всегда состоит из четырёх байтов, даже на 64-битной архитектуре для совместимости с 32-битной. В результате загрузка 64-битной команды в регистр состоит из пяти инструкций, так как из этих четырёх байтов два отводятся под код операции, а ещё два под операнд: загрузить два байта в младшую половину полуслова, загрузить два байта в старшую половину полуслова, услать младшую половину в старшую, загрузить ещё два байта, и ещё два байта. :-)
Вызов функций -- это тоже что-то.
Из-за того, что под операнд в инструкции всего два байта, то никакой call 12345678h, естественно, не прокатит. Поэтому мы заведём табличку структур: в каждом элементе будем держать адрес начала функции, флаги, и адрес таблички функций, которые вызываются из вызываемой функции. И будем вызывать функции по индексам в этой таблице. Соответственно, адрес этой таблицы всегда хранится в отдельном регистре, и при входе в вызываемую функцию загружается из структуры, чтобы вызываемая функция знала, где лежит её таблица. :-)
(Отсюда, кстати, некоторая проблема, когда в одном юните более 32к или 64к функций -- в одну табличку уже не влезает. Если не путаю, эти таблички объединяются в одном юните в одну.)
Соответственно, когда у вас есть указатель на функцию, то он показывает не на код, а на эту самую структуру из трёх элементов.
> Соответственно, когда у вас есть указатель на функцию, то он показывает не
> на код, а на эту самую структуру из трёх элементов.В общем ты тут бреда нагенерил, не совместимого с реальностью.
Размещение указателя и вызов функций совершенно по-иному формируется и осуществляется.
> Идём далее. Инжинеры ИБМ решили, что инструкция всегда состоит из четырёх байтов,
> даже на 64-битной архитектуре для совместимости с 32-битной. В результате загрузка
> 64-битной команды в регистр состоит из пяти инструкций, так как из
> этих четырёх байтов два отводятся под код операции, а ещё два
> под операнд: загрузить два байта в младшую половину полуслова, загрузить два
> байта в старшую половину полуслова, услать младшую половину в старшую, загрузить
> ещё два байта, и ещё два байта. :-)Аный стыд! В 95 году это что ли было и с тех пор тащат?
> Возьмём, например, IBM Power 6 (с коим имел дело).
> У него есть один ЦПУ и 6 вычислительных недопроцессоров (SPU).Power6 меньше 2-ядерного не было! Чипсеты умели объединять в 4-,8-процессорные системы,
по заказу делали 32-процессорные блейды, через подобие infiniband кучковались в 1024-процессорные.
А эти "недопроцессоры" - векторные, и операции, соответственно, тоже векторные. И глупо пытаться
там писать хелло ворлд.> что у этих SPU есть отдельная урезанная таблица системных вызовов. Ну, и как под это писать? :-)
Cell BE SDK.
> Идём далее. Инжинеры ИБМ решили, что инструкция всегда состоит из четырёх байтов
С разморозкой: Google: RISC
> Вызов функций -- это тоже что-то.
Может сначала начнёшь с Introduction to RISC Assembly Language Programming.
А потом уж будешь делать вид, что умнее инженеров IBM.
npar, lpar
> npar, lparДа, npar -- это оно.
А касаемо аппаратного мониторинга состояния камня у IBM, и чтоб ОС об этом знала, все нормально? Как у конкурентов?
Вообще, у ИБМ что-то да должно быть. Позиционируют же себя, как производителей мэйнфреймов. Другое дело, что часто кода там уже лет 30 никто не трогает, так как разработчики умерли или уволились -- работает, и ладно. ;-) А ещё придётся покупать лицензии на процессоры и на процессорное время. ;-) Нужно отчётик месячный сгенерировать -- так и быть, пару часиков потратим на всех ядрах. ;-)
> При этом, у них, как я понимаю, у
> одних из первых появилась горячая замена процессоров.Не-а, не у них. Вот отрывок из описания ОС Multics, появившейся ещё до Unix:
"At the MIT system, where most early software development was done, it was common practice to split the multiprocessor system into two separate systems during off-hours by incrementally removing enough components to form a second working system, leaving the rest still running the original logged-in users."
Зачем?
Illumos и OpenIndiana же
Так то только на x86_64?
А что касается спарков, то апдейты кончились?
> Зачем?
> Illumos и OpenIndiana жеТы видел, когда они последний раз обновлялись?
Установил, побаловался на машинке Enterprise T5220. В репозтариях старое г-вно вроде apache 2.2 и php 5.3. Такая же древняя MySQL.
Работает без сбоев но надо ли ?