Ахтунг, вендотролль детектед!

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

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

Пруфлинк на того, кто отказался от старого (!) юниксового (!!!) мэйнфрейма в пользу вообще чего-нибудь. И вообще, на того, у кого это самый юниксовый мэйнфрейм стоял.

На мэйнфреймах, вообще-то, свои ОС. Не юниксы, но, возможно (на самых новых), с юниксовымии подсистемами. Так-то вот, г-н анонимный вендотролль.

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

>юниксовых мэйнфреймов
LOL!
Дитёнок не знает, что на мэунфрэймах совсем не юникс, но туда-же троллить.

BTW, продажи мжйнфрэймов растут на последние 5 -7 лет

c'mon, в mono нету 3-го silverlight, нету Linq to Entities, нету DSL расширений, нету sharepoint/biztalk на мэйнфреймах.

Ну то есть использовать mono как asp.net в качестве альтернативы php - можно, но никому не нужно, а делать на нем что-то enterprise - увы.

С другой стороны когда приходится интегрироваться с мэйнфреймом - сейчас это выглядит так:

1) Приложение на языке, названия которого никто уже не знает кладет файлик на файловую систему.

2) Файлик выкачивается по ftp на PC-server

3) Файлик обрабатывается и кладется в БД или публикуется в понятном для современных приложений виде.

Если на мэйнфреймах будет mono - может под mono сделают компиляторы с мертвых языков, старые приложения можно будет собрать на mono - и приделать те же TCP/IP или вебсервисы.

> очень слабо верится, что этого гогна столько много

Это имеется в виду, что 15% остальных установок linux'а на мэйнфреймах - Red Hat. Ничего иного.

> А вот в России единственная компания в моём городе, про которую слышал что она работает (или работала) с мэйнфреймами - это РЖД

Если город не Москва, то все может быть. Из официальных референсов еще центробанк. РЖД продолжает работать и очень счастливы. С их количеством транзакций, intel'у пришлось бы дополнительные заводы по производству своего говна открывать.

> А какой именно софт будет есть под С# который можно было бы увидить на мейнфремах. Алсо в России во всех банках опососах стоят не IBM z-serias а SUN E25k ну или где денег побольше M9000, такие дела.

ЦБ - маленький банк, что вы о нем не слышали?

> Это пенсионерия и ретроградство - в 80-х мэйнфреймы были популярны, вот на них и остались

Вам наверное кажется всё что не intel, все ретроградство :-) Почитайте об архитектуре z10 EC машинки и сформируйте объективное мнение, а не пользуйтесь стереотипами. Машинка с частотой проца в 4.4 GHz уже не подходит под определение ретроградства, а то, что она поддерживает в том числе и старый софт, принято считать плюсом, а не минусом. Люди, для которых компиляция и установка софта не конечная цель, а всего-лишь способ, прекрасно понимают зачем это нужно.

> возможно (на самых новых), с юниксовымии подсистемами

Да собственно и не на самых новых тоже, USS (UNIX System Services) был ещё на OS/390.

> Если город не Москва, то все может быть.

Город - не Москва. Т.е. количество возможных вакансий в городе для разработчика на mainframe около нуля.

>Ядро 2.6.27.29

в промышленном линуксе ядро трёхлетней давности

трёхлетней

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

Честно говоря работа на мэнфреймах серьёзно охладила первоначальные ожидания.

частотой проца в 4.4 GHz

Для некоторых задач мерянье гигигерцами ничего не даёт. Например, не так давно тестировал скорость вычислений (вещественки) на мэнфрейме (по слухам стоимостью более мегадоллара) и на x86 (ноут за пару килодолларов на Intel Core). В итоге вещественка на лаптопе работает существенно быстрее, чем на мэнфрейме. В качестве числодробилки мэнфрейм (без Cell) не пригоден. Надо было бы еще замерить в вещественке мэнфрейм против КПК на каком-нибудь arm с ускорителем вещественки ;-)

а то, что она поддерживает в том числе и старый софт, принято считать плюсом

Тут мэнфреймы невероятно круты. В коде используется кусочки HLASM, написанные в 1972. Т.е. у товарищей совместимость не каких-то высокоуровневых абстракций, а системы команд с 1965-го года, когда не было никаких юниксов, С, микрософта, а код набирался на перфокартах.

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

Кстати, никто не знает случайно почему у меня компилятор С на z/OS в USS (z/OS XL C/C++ compiler) работает раз в 60 медленнее чем gcc на лэптопе под OpenSuSE?

> ынтерпрайз не тяготяеет к последним версиям

А какой смысл в новых ядрах в энтерпрайзе? Чтобы новая вэбкамера работала с мэйнфреймом? ;-)

> Например, не так давно тестировал скорость вычислений (вещественки) на мэнфрейме

Где это было (какая компания)? ;)

> RHEL вообзе на 2.6.18 сидит

Ядра RHEL имеют не много общего с ядрами ванильными. Red Hat давно пользуется политикой бэкпортирования, были размышления ее прикрывать, потому как напряжно это, но пока еще действует.

> Где это было (какая компания)?

Что-то мне лениво вспоминать NDA, касательно возможности оглашения результатов тестирования производительности, поэтому оставим компанию без названия. Ноутбук (Core2Duo) покупался в 2007-м, и сравнивался с z9. IBM выпустила z10 только через год (в 2008). Собственно ничего удивительного в том что ноутбук дешевле в тысячу раз (а работает с flop быстрее) я не вижу, учитывая что Intel Core умеет 4 flop за такт делать.

Собственно поэтому и спрашивал. Напомню Вам, что у z9 была частота 1.7ГГц, а у BC 1.4ГГц, так что говорить, что частота не имеет значения нельзя ;-)

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

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

> Напомню Вам, что у z9 была частота 1.7ГГц, а у BC 1.4ГГц, так что говорить, что частота не имеет значения нельзя.

Доступа к z10 нету, поэтому поиграться с ней не смогу, собственно современного топового ноута тоже нету. Не хочется, конечно, говорить не попробовав, но даже если в z10 сделали аппаратную вещественку со скоростью 1 flop за такт, то у интела частота пусть в полтора раза ниже, зато 4 flop. Т.е. всё равно ноут должен работать в разы быстрее.

Когда разрабатывалась новая машина, ставилась цель на нетрадиционных для мэйнфрейма задачах (это как раз те бенчмарки, которые Вы делаете) достичь увеличения производительности в два раза.

Если учесть, что большинство других платформ за это время (3 года между z9 и z10) ускорились в 4 раза, то платформа становится из года в год всё медленнее и медленнее (сравнивая с современными конкурентами). К тому же чтобы как-то соответствовать скорости интела в вещественке (где интел довольно силён) надо было ускоряться минимум раз в 10 (это на глаз, может и больше). А чтобы соответствовать flops/$ надо было ускоряться в 1000 раз.

Добавлено аппаратное ускорение вычислений с плавающей точкой.

Если я правильно помню рекламные проспекты z10, то они добавили аппаратные Decimal float point. Hexadecimal float point вроде традиционны для ibm и были с древшейших времен. Binary float point, которая вроде как и используется для типа double с C по умолчанию, вроде тоже аппаратная довольно давно. Т.е. если я использую Binary float point, а не Decimal float point, то от его аппаратной реализации в z10 ничего не улучшится.

так что делайте пожалуйста правильные бенчмарки.

Так на «правильных» бенчмарках мой МК-52 обгоняет любой вычислительный кластер: отсутствие задержки на включение (инициализация, самодиагностики), задержки на загрузку ОС, ... ;-) Я тестировал на той задаче которую мне нужно было решить. Забил несколько строчек на мэйнфрейме, еле дождался пока скомпилируется, запустил - и молчание. Перетащил на ноут, скомпилировал (менее секунды), запустил - результат появился мгновенно. У меня нет необходимости делать бенчмарки, а вот решать задачки иногда надо.

Когда-то давно (в 60-х вроде), мэйнфреймы проектировались под широкий спектр задач (видимо поэтому название первого - System 360). Сейчас видимо не следует использовать мэйнфреймы для счётных задач, для системы хранения, ... Как показывает опыт google для задач требующих высокой пропускной способности и вместе с тем надёжности мэйнфремы тоже не cost effective. Ведь как бы ни был надёжен мэйнфрейм если он один - то достаточно вывалится кабелю питания - и всё пропало. Три персоналки разнесённые по разным городам обеспечат в таком случае большую надёжность и от аварии на лэп на несколько суток (даже если у вас ups+электрогенератор, то у провайдера для поддержания всей инфраструктуры его как правило нет), от землетрясений, наводнений и прочих мелких радостей жизни ...

> Сейчас видимо не следует использовать мэйнфреймы для счётных задач, для системы хранения, ...

Ничего не понял. Я же сказал направление для размышлений - задачи, требующие одновременно вычислительной нагрузки с интенсивным вводом-выводом. Это связки app server + СУБД с большими объемами данных. Идеально конечно какой-нибудь CICS + db2 на z/OS, но не будем идеализировать мир и исходить из вариантов WebSphere App Server, db2 (в т.ч. LUW), Oracle DB.

Ведь как бы ни был надёжен мэйнфрейм если он один - то достаточно вывалится кабелю питания - и всё пропало.

В мэйнфрейме два кабеля питания, хотя это скоро уже будет даже в персоналках.

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

Самая большая проблема, что мы говорим о разных типах нагрузки. Я понимаю, что Вам ближе Ваша и вполне допускаю, что для этих задач мэйнфрейм не подходит. Если сможете разнести на три персоналки DB2/Oracle DB с WebSphere, при этом получите надежность как у мэйнфрейма и в течении трех лет это решение окажется не дороже, то Вы очень сильно меня удивите.

Факты: - Capacity on Backup (резервный мэйнфрейм стоит в разы дешевле) - x86 платформа не способна обрабатывать задачи с интенсивным вводом-выводом - Oracle Enterprise Edition, как и многий другой софт, лицензируется по ядрам. - Готовые решения по репликации.

Ах да, забыл спросить, как Вы скэйлить собираетесь свое решение. В случае db2 на z/OS есть sysplex, а у Вас? ;-)

Ну что же, веселиться - так по полной.

x86 платформа не способна обрабатывать задачи с интенсивным вводом-выводом

И правда не может. То-то всякие мелкие сервисы типа google поиск, yahoo, youtube используют x86. У них ведь и пользователей почти нет (гуглом ведь не больше десятка человек в день пользуется), и данные с дисков читать не надо (ведь с youtube ролики никто не смотрит).

Oracle Enterprise Edition, как и многий другой софт, лицензируется по ядрам

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

как Вы скэйлить собираетесь свое решение

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

Угу, вот я на какую компанию не посмотрю в России, мне то гугл, то яху мерещатся, не пойму на кого больше похожа. Сходите в любой банк и расскажите им про x86 и postgresql под их АБС, услышите много нового. Все самописы рано или поздно умирают в 90% случаев.

Ах да, видел я один гугл у нас в России, а точнее их филиал в славном городе Мытищи. Заходишь в кладовку, а там персоналки вдоль стены расставлены, заросшие паутиной и много-много витой пары. Я их спрашиваю - а консолидировать не хотите? Нееет, мы не знаем где что работает и боимся это трогать. Вот он гугль, яху и ютюб в одном лице! Вот он клауд-компьютинг, люди уже 3 года назад не особо заморачивались на тему где какое приложение работает. А всякие IBM, Cisco и Microsoft говорят, что это направление будущего! Врут! Это придумали давно здесь в России!!

Я конечно понимаю, что на linux.org.ru дело неблагодарное рассказывать об оракле, честно говоря я бы рад был, если бы postgresql ставили в банках и говорили «ну мы как яху хотим», но давайте жить в реальном мире и в качестве референсов ссылаться на другие банки, а не на IT-организации.

>Ядра RHEL имеют не много общего с ядрами ванильными. Red Hat давно пользуется политикой бэкпортирования, были размышления ее прикрывать, потому как напряжно это, но пока еще действует.

Знаем-с, но практика показывает, что бэкпортируют очень немного. например, usb wifi-адаптер наотрез отказался работать под CentOS (версия wifi-extensions в ядре оказалась на единицу меньше, чем требовалась).

Novell рассчитывает, что наличие коммерчески поддерживаемого Mono, позволит корпорациям перенести .Net приложения на мэйнфрэймы.

коммерчески поддерживаемого Mono, позволит корпорациям перенести .Net приложения

коммерчески поддерживаемого Mono, .Net приложения

facepalm.svg

Бесплатная JavaEE ликует в сторонке

Шо, «коммерчески поддерживаемого » с «бесплатной выкачкой» попутал ?

Ничего , по понедельникам и не такое еще бывает ))

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

Мидлеты очень популярны то сих пор. Правда, это не совсем десктоп. Точнее, совсем не десктоп.

Апплеты вполне себе возрождаются в виде JavaFX

Продолжаем веселиться.

Все самописы рано или поздно умирают

Рано или поздно умирает вообще всё. На счёт самописов - то всё уже украдено до нас (c). Зачем строить велосипеды, когда для гугловского MapReduce/BigTable есть, например, open source аналог Hadoop/HBase. Наверняка есть и другие аналоги.

ссылаться на другие банки, а не на IT-организации.

Ок, так и запишем: мэнфреймы/ораклы/db2 для тех, кого не устраивает размер откатов с commodity hardware + free soft и/или не могут осилить MapReduce, напильник для PostgreSQL, ...

> Угу, вот я на какую компанию не посмотрю в России, мне то гугл, то яху мерещатся, не пойму на кого больше похожа.

Прошу прощения, возможно я Вас просто не так понял. Вы хотите сказать, что в российские банки ставят mainfram'ы потому, что они «популяры»? Или выбор основан на каких-то технических преимуществах последних?

> Я конечно понимаю, что на linux.org.ru дело неблагодарное рассказывать об оракле ...

Вы много раз ссылаетесь на Oracle. Почему?

Компания IBM разрабатывает свою базу данных — DB2. И, IMHO, последняя имеет аппаратную поддержку на Z архитектуре.

Oracle работает лучше на mainfram'ах?

Какого размер должна быть база и какая должна быть нагрузка, чтобы Z оправдала свою цену?

> Вы много раз ссылаетесь на Oracle. Почему?

По трем причинам: 1) Она популярнее в России, чем DB2. 2) Она чаще встречается на Linux для System z (в моей практике) потому что Oracle DB не будет поддерживаться более на z/OS, начиная с 11-ой версии. А DB2 ставят чаще на z/OS, потому что там кодовая база заточена под мэйнфрейм по историческим причинам... А я все-таки специалист по Linux. 3) У меня больше практики с Oracle DB, поэтому мне этот продукт близок.

Компания IBM разрабатывает свою базу данных — DB2. И, IMHO, последняя имеет аппаратную поддержку на Z архитектуре.

Абсолютно верно. Более того, сам Эллисон сказал, что уважает DB2 на z/OS. Из уст конкурента это звучит как серьезный комплимент.

Какого размер должна быть база и какая должна быть нагрузка, чтобы Z оправдала свою цену?

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

> Вы хотите сказать, что в российские банки ставят mainfram'ы потому, что они «популяры»? Или выбор основан на каких-то технических преимуществах последних?

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

> Ок, так и запишем: мэнфреймы/ораклы/db2 для тех, кого не устраивает размер откатов с commodity hardware + free soft и/или не могут осилить MapReduce, напильник для PostgreSQL, ...

Вы еще не начальник? Когда Вы станете CIO, я надеюсь Вы вспомните этот спор и все же меня поймете. Если к этому времени что-то серьезно изменится, я буду только рад.

Примеры:

1) Вызывает Вас начальник и говорит, я видел, что у моего однокурсника, ныне руководителя одной немаленькой конторки есть программа, называется SAP. Хочу такую же! Что Вы ответите? Это проприетарное ужасное изделие, давайте мы поставим Вам нашу прекрасную OpenSource ERP?

2) Возьмем пример хуже, о котором все-таки как-то можно будет спорить. Нужно написать основное приложение для бизнес-задач. Пользователей тьма, интеграция с какими-то внешними системами ну и т.д. А отдел молодой: 3 серверных админа, 2 СУБДшника и 5 helpdesk-спецов. Вот приходите Вы обратно и начинаете думать: Даа.. А вон здорово как сделано это на западе на Postgresql, нужно напильником обработать и все будет нормально. А само приложение напишем на... На чем щас модно писать? На Haskel? На ROR или это уже вышло из моды? Ну неважно... Вот понимаете, что вот эти люди и так периодически по 14 часов в сутки работают, надо значит либо нанять какую-нибудь контору, которая все это напишет, либо нанять людей. Сколько надо нанять людей, чтобы они все это в обозримые сроки написали и оттестировали? Что с ними делать потом? Это стандартные вопросы, которые задаст любой руководитель. И главный вопрос - ГДЕ найти всех этих людей? Переманить за полторы цены? Много вообще таких людей? Эй, жители LOR'а, многие здесь из Вас владеют напильниками для PostgreSQL?! А программируют все хорошо на правильных языках?

А те откатчики, о которых Вы говорите, заплатят большие деньги тем конторам, которые пишут на всяких Явах и под DB2. И они с горем пополам, но напишут и будут поддерживать потом и будет все это гораздо дешевле и быстрее, чем напильником-то по postgresql.

Откройте свою компанию по разработке софта, пишите все под распределенный postgresql, продавайте поддержку на свои продукты и главное рассказывайте всем, что Вам заказчик поставил SLA 99.999% в год и Вы его выполняете. Тогда и сдохнут все или превратятся в заводы по производству intel'овых станций. IBM выкупит назад завод по производству дисков, потому что это будет выгоднее чем производить дорогие СХД. Microsoft начнет контрибутить код в PostgeSQL и скажут, что они всегда думали, что за Postgres будущее. Oracle закроет свою СУБД, откроет исходники OEBS и сделают поддержку Postgres. Красивое будущее, правда?

Патенты на технологии упреждающего чтения. Дисковые массивы с контроллерами на базе power6 процессоров. Отдельная ОС в разделе для того, чтобы организовать кластер. Зачем это все? Правильно, для откатчиков. Это все проклятые капиталисты придумали и откатчики их поддерживают. А на самом-то деле можно все дешево и просто!

Как же тут весело.

На чем щас модно писать? На Haskel?

Что же вас так на экзотику тянет. Если железо - то мэйнфрейм, если язык программирования - то хаскел.

ГДЕ найти всех этих людей? Переманить за полторы цены? Много вообще таких людей?

А вот специалисты по z/Arch у нас гроздьями на каждом дереве весят. Какого выпускника вуза ни возьми - он ни слова не слышал про Postgre/MySql, java/C++ зато умеет админить мэйнфрейм левой пяткой. А правой пяткой оптимизирует конфигурацию DB2. На поддержку x86 железа можно сажать любого школьника который имел любопытство заглядывать в домашний комп. А мэйнфрейм? К нам в село Гадюкино на голубом вертолете прилетит специалист ibm из Москвы скажет что сломался процессорный модуль и ждать второго голубого вертолёта с железом. Туда-сюда неделя-две. Или дойти за 10 минут до соседнего ларька и купить x86 процессор на замену.

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

Что-то мы чем дальше, тем больше отклоняемся от темы. Я постараюсь не комментировать все то, что совсем далеко, ладно? Про язык программирования я просто привел пример, чтобы Вы не сказали, что Ява - отстой. Как видите, это бесполезно, Вы все равно говорите отстой ;-)

А вот специалисты по z/Arch у нас гроздьями на каждом дереве весят.

В четырех ВУЗах нашей страны есть мэйнфреймы. Т.е. в большинстве из них учат, а в некоторых планируют учить работать на них. В одном из ВУЗов по историческим причинам целые группы специализируются именно на нем.

К нам в село Гадюкино на голубом вертолете прилетит специалист ibm из Москвы скажет что сломался процессорный модуль и ждать второго голубого вертолёта с железом. Туда-сюда неделя-две. Или дойти за 10 минут до соседнего ларька и купить x86 процессор на замену.

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

> Ява - отстой. Как видите, это бесполезно, Вы все равно говорите отстой

Ну не говорил я такого, я наоборот говорил что задачу можно решать на любом mainstream языке (и java в их числе), проблема с архитектурой приложения оказывается при отладке и поддержке важнее, чем война Java vs C++ vs ... Кстати я приводил в пример проекты Hadoop/HBase - это java.

В четырех ВУЗах нашей страны есть мэйнфреймы.

А список можно? Среди моих знакомых - мэйнфреймы в вузе не изучал никто. Т.е. может они и есть, но если их скажем 100 человек в год на страну - это по сравнению с многими тысячами it специалистов которых учили на x86 - это почти ничего. Или они все в столицах сидят, и потому я их не вижу. Во-вторых самообразование. Можно из пары домашних персоналок собрать кластер и вовсю учиться параллельной обработке данных. Если не требуется кластер - то вообще можно учиться на любом домашнем компьютере.

Я не знаю случаев, когда мэйнфрейм простаивал из-за аппаратных проблем.

У нас было, и насколько помню - несколько раз простои были из-за аппаратных проблем, решать которые вызывали ibm. Точно причины не помню - я не администрирую, мне важен факт, что мэйнфрейм работает и можно на нём что-то делать, или не работает и нужно ждать пока починят.

> А список можно?

МГТУ им. Баумана, МГЛУ, РГУ Губкина, МИИТ.

Т.е. может они и есть, но если их скажем 100 человек в год на страну - это по сравнению с многими тысячами it специалистов которых учили на x86 - это почти ничего.

С одной стороны я с Вами согласен. С другой стороны, во-первых у нас нету тысяч it специалистов. Точнее формально они есть, но вот как на собеседование не позовешь, так такую чушь несут, что аж страшно становится. Задаешь какой-нибудь ну совсем простой вопрос: «в компьютере есть кэш и оперативка. Кэш быстрее оперативки? Почему не сделать очень большой кэш и не отменить оперативку?» И начинают тупить, начинаются сумасшедшие идеи о том, что они занимаются разными задачами, о том, что так нельзя по каким-то архитектурным особенностям. Какую чушь только не услышишь.

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

В-третьих, ну я сам родился не в серверной рядом с мэйнфреймом. У меня N лет работы с Linux на x86/x86_64/ia64 в разных ролях. Ничего, за два месяца чтения книжек я освоил z/VM и мог достаточно уверенно администрировать машину - ставить Linux'ы, клонировать, настраивать.

> МГТУ им. Баумана, МГЛУ, РГУ Губкина, МИИТ.

Как и думал - столица. А сколько стоит выпускник столичного вуза, если тащить его в регион по сравнению со средними зарплатами в регионе?

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

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

Можете закидать меня помидорами, но ответ вроде вполне верный, не развёрнутый, но верный. Кэш - это микроархитектурное решение. В архитектуре его нет. На некоторых персоналках середины 90-х кэш был в виде отдельной платы, втыкавшейся в материнку. Его можно было вытащить - и компьютер включится, программы будут работать как и прежде (но медленнее). Т.е. при выдергивание кэша из компьютера архитектура не поменялась. А вот если выдернуть оперативную память - комп не включится. Кэш есть невидимая заначка - поэтому нельзя им заменить что-то видимое. Сейчас, когда размер кэшэй по 6-12 мегабайт и многие задачи влезают в кэш, есть некоторые проблемы в их запихивании учитывая отсутствие адресуемости кэша и ограниченный way (я всё про x86).

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

Возможно вы хотели спросить почему бы не делать оперативную память (которую обычно делают на DRAM), из того типа памяти, из которой обычно делают процессорный кэш (SRAM). Но это лишь говорит, что собеседумый оказался умнее того кто проводил собеседование о ответил в точности на тот вопрос который был задан.

Почему не сделать очень большой кэш и не отменить оперативку?

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

Не тратьте время, придираясь к моим словам, просто посмотрите еще раз два простых примера, которые я привел, когда покупаются мэйнфреймы и согласитесь, что есть технические задачи, которые не могут быть заменены набором персоналок. Или дискуссия на тему где взять специалистов под эти задачи автоматически означает, что Вы все-таки признали мою правоту? ;-)

p.s. с наступившим Вас кстати :)

С Наступившим!