1. Просто PG делает официальную версию под Z, поэтому в их код уже внесены нужные патчи.
2. Нет, не будут, потому что ARM поддерживается гораздо лучше в библиотеках.
Вы делаете громкие заявления, ничем их конкретно не подкрепляя.
Конкретно, речь про вот это заявление:
МФ самая универсальная платформа для выполнения любых серверных програм, написанных на любых языках и под любые ОС кроме Windows
Я в корне не соглашусь. И подтверждением послужит хотя бы количество серверов в датацентрах, работающих под Linux.
Насчет универсальности — и в чем она заключается? Ничего универсального вообще — одна специфика, так что вы даже предлагаете новичкам с ходу забыть все, чему их учили в ВУЗе.
А насчет, мол, можно запускать. Так z/os можно запускать в геркулесе на под линкусом. Тоже вариант, многие используют. Другое дело, как это будет работать. То же применимо к портированию на Z кода C, который изначально писался по Unix — это потеря производительности. По хорошему, быстро на МФ работают только «родные» приложения на Cobol, ассемблере и т.д., которые изначально заточены под эту архитектуру. Там где подразумевается posix все сразу становится очень кисло.
Во-первых, странная постановка вопроса. Типа «поезжайте в Киев и спросите!».
При чем тут это?
Во-вторых, интересно было бы послушать, в каком месте IBM говорил, что z для них важнее power. Сейчас IBM вообще не фокусируются на железе, а позиционируют себя как middleware и cloud provider.
Я надеюсь, вы не хотите снова посмешить меня заявлениями о том что МФ=Cloud?
IBM купили RH. И теперь продвигают их продукты. И, хотя, возможно, наверное, запускать OpenShift на МФ, мне трудно представить себе, кто будет покупать Z специально и исключительно для того, чтобы запускать там RHEL и OS. Для этих целей есть Power сервера, они изначально затачивались под Uniх.
Суперкомпьютеры — это Power. AI — Power. Так что вот это флагман.
А то что i превосходит z по архитектуре — это легко и предметно доказывается:
Объектная OS
Встроенная в ядро ос реляционная БД
Встроенная виртуальная машина
Современная универсальная платформа — Power
Ну, и, да, современный РПГ — это просто технологии высшей цивилизации по сравнению с Cobol и PL/I от Z. Но это чисто мое личное субъективное мнение.
Это называется «байки из склепа». Что-то когда-то 20 лет назад слышал, то ли в лабе, то ли возле нее…
Факт остается фактом: DB2 LUW была написана на C. За основу брался код для OS/2. О каком заимствовании кода с МФ может идти речь?
Хех, а я все живу в мире S/390, AS/400 и RS/6000 :-).
Но тут смысл в том, что сегодня Power — это общее железо для 3-х oc (если не считать разные версии Linux).
IBM перманентно хочет унифицировать вообще все железо, в том числе и для Z сфокусировавшись на Power. Пока c Z не получилось, но, я так думаю, попытки не оставят. Просто слишком дорого продолжать делать процессор для одной специфической машины. Думаю, в конце концов, сделают какой нибудь оптимизированный транслятор с z в Power или что нибудь в этом роде и таким образом разрешится.
«выбросите из головы все что узнали в университете и начнете с чистого листа»
Вот что вы молодежи советуете? Зачем им выбрасывать эти знания? Они совершенно применимы для 99,9% всех сайтов и новых разработок. Ради одной устаревшей платформы, которую даже в голову не придет использовать для каких-то новых продуктов и которую держат исключительно с целью, чтобы запускать написанный во времена динозавров код на языках, которые давно морально устарели?
Вот, вот, уже ближе к реальности ;-). Но, согласитесь, есть же разница между «не сложнее чем» и «даже не зная».
Что касается сложности, то это сильно зависит от приложения. Да, c Java и JS будет попроще.
Но вот с приложениями на C и CPP все может быть гораздо интереснее. Линукс под платформу — это одно. А вот куча зависимостей — это совсем другое. А собирать либы самому под очень специфическую архитектуру — это ой какое интересное занятие. И это еще до всяких контейнеров.
А дальше, когда изрядно помучившись, вы все соберете, и оно даже заработает, окажется, что скорость работы как на не самом свежем лаптопе :-). И вот тут начинаются настоящие танцы с бубном.
Да, сейчас глянул на докере действительно 7340 образов под Z. Для сравнения, на x86-64 — 4,182,380.
«При этом коллектив, сопровождающий приложения внутри докера, будет работать с привычными для них кросс-платформенными инструментами, возможно даже не зная того, что докер-инстанс работает как один из процессов внутри z/OS».
У меня закрадывается устойчивое подозрение, что вы никогда в жизни не создавали контейнер, признайтесь, а повторяете тексты из рекламы, не совсем понимая о чем речь ;-). Потому что как бы «подозревать» на какой платформе будет крутиться контейнер разработчик начинает еще на этапе его создания ;-).
«В современную версию z/OS портировано много опенсорсного ПО и ЯП (Java, Python, Perl и т.д.), даже докер-контейнеры (внутри которых линукс) можно внутри z/OS запускать.»
И смысл запускать докер контейнеры в специфической архитектуре на супердорогом железе, если это можно делать гораздо проще и сильно дешевле в Linux/AMD64/ARM/Power?
Какие однако новости здесь узнаешь.
DB2 для LUW сделали на основе C версии для OS/2, которая в свою очередь писалась с чистого листа в рамках программы SAA. Тогда же оформили в виде стандарта и перенесли на другие платформы DRDA. Который, к слову, никогда до этого на MФ не было, а существовал в виде DDM на S/38/36/400.
Не лучший настрой для проекта по миграции :-).
Таким проектом должны рулить полные энтузиазма и уверенности в своих способностях люди. А тут слышится крайний скепсис и недоверие к новым технологиям.
Ну и MФ — это, конечно, не облако. Расширяемость МФ ограничена конкретным физическим железом в вашем вц. А по времени добавление новой z системы в энвайромент — это месяцы (если не годы) от начала переговоров и оформления требований, закупки, поставки, тестирования и т.д.
«Я считаю большим плюсом менфреймов и z/OS то, что код, написанный и скомпилированный десятки лет назад можно исполнять на современных мейнфреймах и современном уровне ОС/ПО».
Это как бы половина истории, мед.
Однако, полуправда — это не правда, ведь так?
Код написанный и откомпилированный хх лет может и работает. Но написан он на древнем синтаксисе языков с использованием приемов и практик, которые сегодня не просто устарели — многие просто запрещены для использования в новых программах.
В результате, поддержка такого кода становится малоприятным и бесперспективным занятием. В том смысле, что навыки полученные на такой работе не получиться применить в чем то новом, потому что теперь подобные вещи делаются по-другому и, зачастую, гораздо проще. Рекомендовать такую работу молодым я бы не стал. Те кто ожидают пенсии — пусть занимаются. Все равно этот код по-хорошему надо переписывать.
Ну, и, конечно, гладко все миграции проходят только на бумаге и в рекламных проспектах. В реальности, можно просто побраузить список ошибок в RETAIN на эту тему чтобы увидеть что далеко не все так гладко.
Кроме того, надо посмотреть какими силами обеспечивается эта совместимость. А цена за это — жесткий вендор лок по всему начиная от железа и заканчивая компиляторами. Потому и очень ограниченный список софта. Если уж так сравнивать, то программы написанные под MS DOS можно запускать на Win10 :-).
Для того чтобы делать такие сравнения, надо быть экспертом не только в z, а как минимум не хуже в том, с чем сравниваете.
Все вышесказанное — это некий эмоциональный поток, где главный аргумент в качестве обоснования — «я считаю».
Это весьма смелое заявление. Поставим рядом z и i и сравним, кто кого сделает по удобству, надежности, архитектуре?
i — это по большому счету улучшенная и кардинально переработанная версия z. Ну, т.е. люди, которые делали s/38, танцевали от 370 — это очевидно. И потому заложили и виртуальную машину и объктность и рациональную БД в ось.
Это как сравнивать 3270 с 5250. Познакомившись со вторым, не захочется возвращаться на первый.
2. Нет, не будут, потому что ARM поддерживается гораздо лучше в библиотеках.
Конкретно, речь про вот это заявление:
Я в корне не соглашусь. И подтверждением послужит хотя бы количество серверов в датацентрах, работающих под Linux.
Насчет универсальности — и в чем она заключается? Ничего универсального вообще — одна специфика, так что вы даже предлагаете новичкам с ходу забыть все, чему их учили в ВУЗе.
А насчет, мол, можно запускать. Так z/os можно запускать в геркулесе на под линкусом. Тоже вариант, многие используют. Другое дело, как это будет работать. То же применимо к портированию на Z кода C, который изначально писался по Unix — это потеря производительности. По хорошему, быстро на МФ работают только «родные» приложения на Cobol, ассемблере и т.д., которые изначально заточены под эту архитектуру. Там где подразумевается posix все сразу становится очень кисло.
При чем тут это?
Во-вторых, интересно было бы послушать, в каком месте IBM говорил, что z для них важнее power. Сейчас IBM вообще не фокусируются на железе, а позиционируют себя как middleware и cloud provider.
Я надеюсь, вы не хотите снова посмешить меня заявлениями о том что МФ=Cloud?
IBM купили RH. И теперь продвигают их продукты. И, хотя, возможно, наверное, запускать OpenShift на МФ, мне трудно представить себе, кто будет покупать Z специально и исключительно для того, чтобы запускать там RHEL и OS. Для этих целей есть Power сервера, они изначально затачивались под Uniх.
Суперкомпьютеры — это Power. AI — Power. Так что вот это флагман.
А то что i превосходит z по архитектуре — это легко и предметно доказывается:
Ну, и, да, современный РПГ — это просто технологии высшей цивилизации по сравнению с Cobol и PL/I от Z. Но это чисто мое личное субъективное мнение.
Факт остается фактом: DB2 LUW была написана на C. За основу брался код для OS/2. О каком заимствовании кода с МФ может идти речь?
Но тут смысл в том, что сегодня Power — это общее железо для 3-х oc (если не считать разные версии Linux).
IBM перманентно хочет унифицировать вообще все железо, в том числе и для Z сфокусировавшись на Power. Пока c Z не получилось, но, я так думаю, попытки не оставят. Просто слишком дорого продолжать делать процессор для одной специфической машины. Думаю, в конце концов, сделают какой нибудь оптимизированный транслятор с z в Power или что нибудь в этом роде и таким образом разрешится.
Вот что вы молодежи советуете? Зачем им выбрасывать эти знания? Они совершенно применимы для 99,9% всех сайтов и новых разработок. Ради одной устаревшей платформы, которую даже в голову не придет использовать для каких-то новых продуктов и которую держат исключительно с целью, чтобы запускать написанный во времена динозавров код на языках, которые давно морально устарели?
Что касается сложности, то это сильно зависит от приложения. Да, c Java и JS будет попроще.
Но вот с приложениями на C и CPP все может быть гораздо интереснее. Линукс под платформу — это одно. А вот куча зависимостей — это совсем другое. А собирать либы самому под очень специфическую архитектуру — это ой какое интересное занятие. И это еще до всяких контейнеров.
А дальше, когда изрядно помучившись, вы все соберете, и оно даже заработает, окажется, что скорость работы как на не самом свежем лаптопе :-). И вот тут начинаются настоящие танцы с бубном.
Да, сейчас глянул на докере действительно 7340 образов под Z. Для сравнения, на x86-64 — 4,182,380.
У меня закрадывается устойчивое подозрение, что вы никогда в жизни не создавали контейнер, признайтесь, а повторяете тексты из рекламы, не совсем понимая о чем речь ;-). Потому что как бы «подозревать» на какой платформе будет крутиться контейнер разработчик начинает еще на этапе его создания ;-).
Покупать Z чтобы запускать на нем только контейнеры смысла нет.
То же относится к приложениям на Java, Python и т.д.
И смысл запускать докер контейнеры в специфической архитектуре на супердорогом железе, если это можно делать гораздо проще и сильно дешевле в Linux/AMD64/ARM/Power?
DB2 для LUW сделали на основе C версии для OS/2, которая в свою очередь писалась с чистого листа в рамках программы SAA. Тогда же оформили в виде стандарта и перенесли на другие платформы DRDA. Который, к слову, никогда до этого на MФ не было, а существовал в виде DDM на S/38/36/400.
Таким проектом должны рулить полные энтузиазма и уверенности в своих способностях люди. А тут слышится крайний скепсис и недоверие к новым технологиям.
Ну и MФ — это, конечно, не облако. Расширяемость МФ ограничена конкретным физическим железом в вашем вц. А по времени добавление новой z системы в энвайромент — это месяцы (если не годы) от начала переговоров и оформления требований, закупки, поставки, тестирования и т.д.
Это как бы половина истории, мед.
Однако, полуправда — это не правда, ведь так?
Код написанный и откомпилированный хх лет может и работает. Но написан он на древнем синтаксисе языков с использованием приемов и практик, которые сегодня не просто устарели — многие просто запрещены для использования в новых программах.
В результате, поддержка такого кода становится малоприятным и бесперспективным занятием. В том смысле, что навыки полученные на такой работе не получиться применить в чем то новом, потому что теперь подобные вещи делаются по-другому и, зачастую, гораздо проще. Рекомендовать такую работу молодым я бы не стал. Те кто ожидают пенсии — пусть занимаются. Все равно этот код по-хорошему надо переписывать.
Ну, и, конечно, гладко все миграции проходят только на бумаге и в рекламных проспектах. В реальности, можно просто побраузить список ошибок в RETAIN на эту тему чтобы увидеть что далеко не все так гладко.
Кроме того, надо посмотреть какими силами обеспечивается эта совместимость. А цена за это — жесткий вендор лок по всему начиная от железа и заканчивая компиляторами. Потому и очень ограниченный список софта. Если уж так сравнивать, то программы написанные под MS DOS можно запускать на Win10 :-).
Все вышесказанное — это некий эмоциональный поток, где главный аргумент в качестве обоснования — «я считаю».
i — это по большому счету улучшенная и кардинально переработанная версия z. Ну, т.е. люди, которые делали s/38, танцевали от 370 — это очевидно. И потому заложили и виртуальную машину и объктность и рациональную БД в ось.
Это как сравнивать 3270 с 5250. Познакомившись со вторым, не захочется возвращаться на первый.