The OpenNET Project / Index page

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

Компания Oracle представила проект Linux для SPARC

08.10.2015 23:31

Компания Oracle представила первый выпуск проекта Linux SPARC, в рамках которого проведена работа по адаптации Linux для современного оборудования SPARC. В качестве основы использовано ядро Linux 4.1 и пользовательское окружение на базе пакетов Oracle Linux 6 для архитектуры x86_64, которые расширены специфичными для SPARC оптимизациями.

Linux SPARC можно рассматривать как полноценную 64-разрядную операционную систему, которая может работать на 64-разрядных процессорах SPARC. Размер установочного образа 521 Мб. Поддерживается как установка на конечное оборудование, так и использование в виртуальных окружениях Oracle VM Server for SPARC. Из поддерживаемого оборудования отмечаются серверы на базе процессоров с архитектурой sun4v, такие как UltraSPARC T, SPARC T4, SPARC T5, SPARC M5 и Fujitsu SPARC64-X.

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

  1. Главная ссылка к новости (https://lists.debian.org/debia...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/43112-linux
Ключевые слова: linux, sparc
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (62) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 23:36, 08/10/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Вот это новость.
     
     
  • 2.2, Аноним (-), 23:38, 08/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Прочитал еще раз, это только sun4v. Беда, печаль.
     
     
  • 3.9, Ващенаглухо (ok), 09:08, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так старое сановское борохло оракл не хочит поддерживать даже в Solaris 11.
     
     
  • 4.10, ананим.orig (?), 09:29, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Что в конечном счёте сыграло против них же — кастомеры теперь предпочитают свалить вообще с этой (уже!) маргинальной платформы, чем вляпываться в неё ещё раз.

    Нда, а ведь сановские железки были очень качественными. Заводились и были почти(!) актуальными и через дцать лет...

     
     
  • 5.49, Фабрика Огрызков (?), 01:12, 10/10/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Заводились и были почти(!) актуальными и через дцать лет...

    И кому нах...й это надо?
    Установил сервер, настроил, софт затюнинговал - ...издуй, уволен!
    А так, геи-дезигнеры понакрутят фичек красивых, что аж 64-ядерный Хеон перегревается,
    опа у тебя опять есть работа - апгрейд всего парка серверов.


      

     
     
  • 6.55, count0krsk (ok), 18:16, 10/10/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так и есть. У нас в Красноярске интеграторы Линукс-систем нахухоль не нужны. Проводил исследование рынка, нашёл 4 фирмы. Одна - мои бывшие преподы с ФИПУ и их товарищи, 2я - конторка в закутке продуктовой базы, 3я закрылась, 4я - СофтЛайн, но там всеми фибрами отговаривают от Линукса и впаривают сами_знаете_что...
    А виндузятниковых больше 100, и у всех клиенты. Потому что то вирусня, то обновление кривое, то лицензирование, то апгрэйд под новый фотожоп. Заодно и роутер настроить который стоит 1500р, чтобы не тормозил.
    Печально это всё. С экранов говорящие головы рассуждают про инновации и импортозамещение, а у нас на 6м курсе в группе программистов нет ни 1го Линуксоида. Кроме меня. Кто водилой работает, кто в деревне "бизнес" делает, свиней разводит. Девушка одна сотики продаёт, ещё один торговым представителем.
     
     
  • 7.61, Классический анонимус (?), 13:25, 12/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А что инновационного в Линуксе? Как линуксоид с 10 летним опытом, живущий тоже в Красноярск, скажу, что тебе ещё не поздно чем-то более перспективным заняться.

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

     
  • 3.19, 123 (??), 12:44, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >Прочитал еще раз, это только sun4v. Беда, печаль.

    Чем читали если не секрет?

    >Из поддерживаемого оборудования отмечаются серверы на базе процессоров с архитектурой sun4v, такие как UltraSPARC T, SPARC T4, SPARC T5, SPARC M5 и Fujitsu SPARC64-X.
    >Fujitsu SPARC64-X

    http://www.fujitsu.com/global/products/computing/servers/unix/sparc-enterpris

    Или этот монстр для вас уже устарел?

     
     
  • 4.20, Аноним (-), 13:02, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Новое спаркожелезо мне лично не интересно и не нужно. А вот на такое:

    http://www.oracle.com/ru/products/servers-storage/servers/sparc-enterprise/m-

    я бы линукс поставить не отказался, а вот хрен ибо sun4u.

     
  • 4.50, jerk (?), 04:02, 10/10/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Или этот монстр для вас уже устарел?

    Нет - он умер не родившись. Никто не покупает спраки энимор.
    У меня Ынтерпрайз чеыре куска ___11___ лет в продакшене оттрубил, подставкой для оракала, но то другая эпоха, забыли, забили.

     
  • 4.53, Zulu (?), 17:49, 10/10/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    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

     

  • 1.3, Аноним (-), 23:39, 08/10/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Так что теперь есть смысл мигрировать Оракл БД из Солярис ОС без потери производительности?
     
     
  • 2.4, s_dog (??), 23:43, 08/10/2015 [^] [^^] [^^^] [ответить]  
  • +9 +/
    да, на AIX
     
     
  • 3.5, дуайт эйзенхауэр (?), 07:01, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +18 +/
    Пару пива этому энтерпрайзщику за мой счет.
     
     
  • 4.11, ананим.orig (?), 09:35, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Когда ынтырпрайзщику наливают даром, значит где-то в другом крупно кидают.
    Так что лучше налом. 10% хватит. :D
     
     
  • 5.13, Yuris (??), 10:47, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Почти стихи: даром - налом, кидают - хватают )))
     
     
  • 6.15, ананим.orig (?), 11:05, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Да если бы хватали, будильники на руках бы не считали.

    И ярды по комнатам квартиры не находили. А меньшими траншами :D

    Зыж
    "Не льстите себе, вы не от КГБ за бугор сбежали, а от ОБХСС". (Не помню кто)

     
  • 3.16, яя (?), 11:44, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    почему на AIX'то ? какие-то ограничения oracle на x86_64 ?
     
     
  • 4.35, www2 (ok), 21:02, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что любителям проприетарщины одного урока бывает недостаточно. Только когда AIX'а и HP-UX'а не станет, тогда начнут догадываться, что тут что-то не так.
     
     
  • 5.51, jerk (?), 04:05, 10/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Только когда AIX'а и HP-UX'а не станет, тогда начнут догадываться, что тут что-то не так.

    Ты из села Кукуево? Просто HP-UX _уже_ и нет вместе с титаником. Только голубые и держатся. Ну дык потому И :)

     

  • 1.6, Вареник (?), 08:28, 09/10/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Не понимаю, почему наши клепают ни с чем не совместимую систему команд Эльбрус, со своим сырым компиллятором, вместо того чтобы взять готовый стек SPARC: ОpenSparc T2, поддержку в ядре, поддержку в распространенных дистрибутивах, поддержку в Java, все протестированно вдоль и поперек.

    К чему этот мазохизм импортозамещения опенсорса?

     
     
  • 2.8, Аноним (-), 08:50, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Делают же МЦСТ R1000, только он слабый для гражданки относительно других конкурентов с архитектурой SPARC v9. Но для СПРН сойдет.
     
     
  • 3.14, Вареник (?), 10:55, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Делают же МЦСТ R1000, только он слабый для гражданки относительно других конкурентов
    > с архитектурой SPARC v9. Но для СПРН сойдет.

    На спарку можно найти много применений.

     
     
  • 4.52, jerk (?), 04:08, 10/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> с архитектурой SPARC v9. Но для СПРН сойдет.
    > На спарку можно найти много применений.

    А смысл выёживаться? Уже купили оба - и MIPS64 и ARM64, на которых есть _всё_, ну так и  напуркуа SPARC ?

     
  • 2.22, Аноним (-), 13:08, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Sparc T и производительность - две вещи несовместные. Пусть уж лучше эльбруса пилят.
     
     
  • 3.54, Zulu (?), 17:53, 10/10/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Sparc T и производительность - две вещи несовместные.

    Добро пожаловать в мир T4, T5, а скоро и T7.

     
  • 2.26, тоже Аноним (ok), 15:07, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Не понимаю, почему наши клепают ни с чем не совместимую систему команд Эльбрус

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

     
     
  • 3.60, Sen (?), 11:47, 12/10/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    такие рассуждения приводят к плачевным последствиям: Китайцы сели и разработали, хотя у всех он есть, а нам не выгодно, ведь китайцы уже сделали... В итоге у нас ничего своего и не будет... А ведь можно сделать и вытеснить и китайцев и остальных... Сначала будет тяжело, работа почти в минус, но результат будет колоссальный если покупатель поверит в нашу продукцию
     
  • 2.32, Michael Shigorin (ok), 19:09, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Не понимаю, почему наши клепают ни с чем не совместимую систему команд Эльбрус

    Очевидно, потому что задачи совместимости не стояло (как, впрочем, и не с чем было "совмещаться" тогда, насколько помню).

    > со своим сырым компиллятором

    Не совсем своим, увы.  А вот ощущения сырости у меня он не вызвал, но да, gcc он прикидывается стареньким.

    > вместо того чтобы взять готовый стек SPARC

    http://www.mcst.ru/r_1000

    > К чему этот мазохизм импортозамещения опенсорса?

    Вы более чем в состоянии поискать ответы на уже сформулированные (без эмоций) вопросы самостоятельно, правда? :)

     
  • 2.36, www2 (ok), 21:05, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В советские времена были свои компьютеры на уровне американских до памятного решения о копировании IBM System/360 в виде ряда ЕС. Что, этого урока недостаточно? Своё нужно делать, потому что копирующий всегда догоняет, а перегнать никогда не сможет.
     
  • 2.42, Anontttttttt (?), 23:30, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Потому, что бы ракета летела точно и хорошо ) и не должно быть совместимости ) что бы ни один американский гринго не догадался )Златоусте )
     

  • 1.7, Аноним (-), 08:45, 09/10/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Ахах, поздно пить боржоми, господа из Оракл, отгнил ваш спарк. Хотя лично я о нём сожалею.
     
     
  • 2.12, Вареник (?), 10:32, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Debian поддерживает SPARC v9, а чем их оракловое Кунг-Фу круче дебиановского - внятно не объяснили.
     
     
  • 3.17, яя (?), 11:46, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    debian дропнул sparc весной , потому что не нашлось суппортеров на архитектуру , см. https://lists.debian.org/debian-sparc/2015/07/msg00012.html
     

  • 1.18, IZh. (?), 12:18, 09/10/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Мельком видел одну железку -- вроде, sun4w архитектура. В центре системы находился некий коммутатор, позволяющий создавать хардварные партиции с электрической изоляцией. Можно было мощь сервера поделить на 1, 2 или 4 части, решив, сколько процессоров, жёстких дисков и сетевых карт достанется каждой партиции. К сожалению, линукс работал только на встроенном управляющем компе. А на основных процессорах запустить его не удалось. К тому же, всякие вкусности, типа получение операционкой на лету сообщения от BIOS'а о том, что сбойнул модуль памяти, чтобы занести его в чёрный список, поддерживались только соляркой.

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

    А, вообще, спарки круты именно детектированием ошибок везде -- в процессорах, в памяти и т.д. При этом, у них, как я понимаю, у одних из первых появилась горячая замена процессоров. Видел картинку, на которой схематично была изображена зона покрытия кристалла процессора -- области, ошибки в которых система может обнаруживать -- был покрыт почти весь процессор. Помню, на одной интеловской конференции лет пять назад они хвастались, что наконец-то (!) их топовый серверный процессор по уровню защищённости может сравниться с таким-то допотопным спарком. ;-) Как числодробилки, интел может и делает спарки по производительности, а, вот, в плане надёжности для mission critical задач, спарки -- одни из лучших на планете. И поддержка линукса позволит активнее их использовать.

     
     
  • 2.21, Аноним (-), 13:06, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Мельком видел одну железку

    Если бы вы видели их железки не мельком, вы бы имели несколько другое мнение.

     
     
  • 3.23, IZh. (?), 13:57, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Какое же?
     
  • 3.24, Аноним (-), 14:49, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    у меня SF880 пережил 5 поколений х86, да и сейчас пыхтит - 2 проца на днях вылетело, но он работает
     
     
  • 4.25, IZh. (?), 15:01, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, так и я о том, что они хороши. :-)
     
  • 4.34, Crazy Alex (ok), 19:59, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    По нынешним временам это прикольно, но совершенно излишне. Появились проблемы - выгнал виртуалки на соседнее железо, это заменил. С шансами - на более экономичное и вообще более выгодное.

    Разве что что-то совсем встроенное, но там, вроде спарки не применялись?

     
     
  • 5.37, www2 (ok), 21:17, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > По нынешним временам это прикольно, но совершенно излишне. Появились проблемы - выгнал
    > виртуалки на соседнее железо, это заменил. С шансами - на более
    > экономичное и вообще более выгодное.
    > Разве что что-то совсем встроенное, но там, вроде спарки не применялись?

    Одноразовое поколение выросло. Потреблятство изо всех щелей прёт.

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

     
     
  • 6.43, Аноним (-), 23:31, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Не мечи бисер, Паладины Локалхоста никогда не просекут, что такое 9 лет аптайма ... большой текст свёрнут, показать
     
     
  • 7.48, Crazy Alex (ok), 00:35, 10/10/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А что тут просекать - это значит, что железка потребила электроэнергии в разы больше, чем суммарная стоимость всего, на что её стоило бы заменить, любые процедуры на случай выхода из строя давно неактуальны, а когда с этой железкой что-то всё же случится - не будет ни доступа к комплектующим для замены, ни простых способов миграции на современное железо.
     
  • 6.46, Crazy Alex (ok), 00:20, 10/10/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Я, конечно,от дел админских отошел, но в тех же облаках это сколько лет как автоматизировано? Да про DevOps мне тут давеча рассказывали - какая, на фиг, толпа дармоедов? Или аварийные ситуации вы обнаруживаете посредством телепатии? А раз нет - то соответствующая логика может и без человека обойтись в большинстве случаев.

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

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

     
  • 5.38, Аноним (-), 21:27, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Угу. А перед тем, как понть, что виртуалки надо выгонять именно отсюда - побегать в тёмной комнате за отсутствующей там  чёрной кошкой, исключая подозрения на ошибки в софте.
     
     
  • 6.44, Аноним (-), 23:31, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Угу. А перед тем, как понть, что виртуалки надо выгонять именно отсюда
    > - побегать в тёмной комнате за отсутствующей там  чёрной кошкой,
    > исключая подозрения на ошибки в софте.

    Из виртуалок он видел только ВиртуалБокс на десктопе, кому ты это говоришь....

     
  • 6.47, Crazy Alex (ok), 00:27, 10/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Не неси чушь, а? У облачников (амазон тот же, хотя ещё NetFlix с их ChaosMonkey вспоминается) это сто лет, как отработано. Но да, софт на это должен быть заточен маленько. На круг - выгоднее, чем держать древние железки и админов, у которых секретные знания в голове, а не в репозитории со стандартными алгоритмами когда что делать. На том, в общем-то, облака и держатся.
     
  • 2.27, Сергей (??), 15:30, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
        Возможно для RISC машинок IBM в этом ничего нового. Пусть кто-нибудь скажет за голубых! :-)
     
     
  • 3.28, IZh. (?), 16:08, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Я скажу против. ;-)

    Возьмём, например, IBM Power 6 (с коим имел дело). У него есть один ЦПУ и 6 вычислительных недопроцессоров (SPU). Я не знаю, как это работает в AIX'е, а в Linux'е получается, что у этих SPU есть отдельная урезанная таблица системных вызовов. Ну, и как под это писать? :-)

    Идём далее. Инжинеры ИБМ решили, что инструкция всегда состоит из четырёх байтов, даже на 64-битной архитектуре для совместимости с 32-битной. В результате загрузка 64-битной команды в регистр состоит из пяти инструкций, так как из этих четырёх байтов два отводятся под код операции, а ещё два под операнд: загрузить два байта в младшую половину полуслова, загрузить два байта в старшую половину полуслова, услать младшую половину в старшую, загрузить ещё два байта, и ещё два байта. :-)

    Вызов функций -- это тоже что-то.
    Из-за того, что под операнд в инструкции всего два байта, то никакой call 12345678h, естественно, не прокатит. Поэтому мы заведём табличку структур: в каждом элементе будем держать адрес начала функции, флаги, и адрес таблички функций, которые вызываются из вызываемой функции. И будем вызывать функции по индексам в этой таблице. Соответственно, адрес этой таблицы всегда хранится в отдельном регистре, и при входе в вызываемую функцию загружается из структуры, чтобы вызываемая функция знала, где лежит её таблица. :-)
    (Отсюда, кстати, некоторая проблема, когда в одном юните более 32к или 64к функций -- в одну табличку уже не влезает. Если не путаю, эти таблички объединяются в одном юните в одну.)

     
     
  • 4.29, IZh. (?), 16:09, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Соответственно, когда у вас есть указатель на функцию, то он показывает не на код, а на эту самую структуру из трёх элементов.
     
     
  • 5.59, pavlinux (ok), 02:13, 12/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Соответственно, когда у вас есть указатель на функцию, то он показывает не
    > на код, а на эту самую структуру из трёх элементов.

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

     
  • 4.57, count0krsk (ok), 06:19, 11/10/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Идём далее. Инжинеры ИБМ решили, что инструкция всегда состоит из четырёх байтов,
    > даже на 64-битной архитектуре для совместимости с 32-битной. В результате загрузка
    > 64-битной команды в регистр состоит из пяти инструкций, так как из
    > этих четырёх байтов два отводятся под код операции, а ещё два
    > под операнд: загрузить два байта в младшую половину полуслова, загрузить два
    > байта в старшую половину полуслова, услать младшую половину в старшую, загрузить
    > ещё два байта, и ещё два байта. :-)

    Аный стыд! В 95 году это что ли было и с тех пор тащат?

     
  • 4.58, pavlinux (ok), 01:50, 12/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Возьмём, например, 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.    

     
  • 2.30, Аноним (-), 17:11, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    npar, lpar
     
     
  • 3.31, IZh. (?), 17:32, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > npar, lpar

    Да, npar -- это оно.

     
     
  • 4.33, Сергей (??), 19:22, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
         А касаемо аппаратного мониторинга состояния камня у IBM, и чтоб ОС об этом знала, все нормально? Как у конкурентов?
     
     
  • 5.39, IZh. (?), 22:48, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вообще, у ИБМ что-то да должно быть. Позиционируют же себя, как производителей мэйнфреймов. Другое дело, что часто кода там уже лет 30 никто не трогает, так как разработчики умерли или уволились -- работает, и ладно. ;-) А ещё придётся покупать лицензии на процессоры и на процессорное время. ;-) Нужно отчётик месячный сгенерировать -- так и быть, пару часиков потратим на всех ядрах. ;-)
     
  • 2.56, Аноним (-), 03:28, 11/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > При этом, у них, как я понимаю, у
    > одних из первых появилась горячая замена процессоров.

    Не-а, не у них. Вот отрывок из описания ОС 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."

    https://en.wikipedia.org/wiki/Multics

     

  • 1.40, IB (?), 22:56, 09/10/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Зачем?
    Illumos и OpenIndiana же
     
     
  • 2.41, IZh. (?), 22:58, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Так то только на x86_64?
    А что касается спарков, то апдейты кончились?
     
  • 2.45, Аноним (-), 23:32, 09/10/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Зачем?
    > Illumos и OpenIndiana же

    Ты видел, когда они последний раз обновлялись?

     

  • 1.62, vincentwine (?), 17:49, 16/01/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Установил, побаловался на машинке Enterprise T5220. В репозтариях старое г-вно вроде apache 2.2 и php 5.3. Такая же древняя MySQL.
    Работает без сбоев но надо ли ?
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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