Хех, а я все живу в мире 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. Познакомившись со вторым, не захочется возвращаться на первый.
Кто нибудь поясните плз, в чем заключается оптимизация конкретно под байкал?
Я по наивности полагал, что если софт уже оптимизирован под конкретные ядра АРМ, то как бы все должно сразу работать более менее неплохо.
Ха-ха-ха. Меня уволили? Ну да. И еще и зуб на ibm имею…
Сколько нового о себе родном порой узнаешь от незнакомых людей на хабре.
Ну и да, какой я спец, по сравнению с вами :-).
Ладно, я вижу с кем имею дело. Переход на личности, неимоверный ЧСВ и ноль технических деталей. Удачи в пугании «молодежи» неимоверной крутизной изделий от ibm. Только вряд ли преуспеете. Больше шансов с непрофессионалами: чиновниками, менеджерами… А в открытой технической дискуссии вы просто бессильны и смешны. Когда вам приводят линки на конкретные кейсы успешных миграций самых сложных систем, ответить вам нечем, кроме каких-то мифических историй с минимумом деталей. Так что складывается полное понимание, что дело там было в некомпетентности конкретных исполнителей, а не в мифической незаменимости мэйнфреймов.
Даже жалко вас, немного.
Вообщем, на пенсию, пора вам на пенсию ;-).
Ох, я эти рассказы слушаю с иронией :-).
Чтобы вести разговор предметно, надо представить детали: в какую архитектуру мигрировали, каким образом, какой тип приложения, какая нагрузка, тогда можно будет разговаривать.
Ой, уверяю вас, уж я то точно не обижаюсь :-). Я иронизирую.
Ну и, конечно, процесс миграции с МФ идет повсеместно, а не только в РФ. Так это объективный процесс, а не «политика».
Как специалист, отдавший «зеленым экранам», как мы шутим, пол жизни, в том числе непосредственно в ibm, я этот процесс поддерживаю и считаю прогрессивным. Будущее за открытыми технологиями и стандартами, потому что они дают гибкость и возможность выбора, что хорошо для бизнеса и рынка.
Да, жалко немного людей, которые 30 лет делали одно и то же и настолько закостенели в своих привычках, что переход на что-то другое для них сложен а нередко и невозможен. Но, с другой стороны, я видел и нежелание учиться и смотреть что происходит вокруг у многих. Слишком удобно было думать, что вот это, полученное когда-то знание будет кормить всегда и можно не развиваться в профессии. Так что и не особо жалко. Пора, друзья, или начать учиться новому или идти на пенсию.
Но тут смысл в том, что сегодня 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. Познакомившись со вторым, не захочется возвращаться на первый.
Я по наивности полагал, что если софт уже оптимизирован под конкретные ядра АРМ, то как бы все должно сразу работать более менее неплохо.
Чем M1 не пример? Он не «домашний»? Он не «арм»?
Сколько нового о себе родном порой узнаешь от незнакомых людей на хабре.
Ну и да, какой я спец, по сравнению с вами :-).
Ладно, я вижу с кем имею дело. Переход на личности, неимоверный ЧСВ и ноль технических деталей. Удачи в пугании «молодежи» неимоверной крутизной изделий от ibm. Только вряд ли преуспеете. Больше шансов с непрофессионалами: чиновниками, менеджерами… А в открытой технической дискуссии вы просто бессильны и смешны. Когда вам приводят линки на конкретные кейсы успешных миграций самых сложных систем, ответить вам нечем, кроме каких-то мифических историй с минимумом деталей. Так что складывается полное понимание, что дело там было в некомпетентности конкретных исполнителей, а не в мифической незаменимости мэйнфреймов.
Даже жалко вас, немного.
Вообщем, на пенсию, пора вам на пенсию ;-).
Чтобы вести разговор предметно, надо представить детали: в какую архитектуру мигрировали, каким образом, какой тип приложения, какая нагрузка, тогда можно будет разговаривать.
Ну и, конечно, процесс миграции с МФ идет повсеместно, а не только в РФ. Так это объективный процесс, а не «политика».
Как специалист, отдавший «зеленым экранам», как мы шутим, пол жизни, в том числе непосредственно в ibm, я этот процесс поддерживаю и считаю прогрессивным. Будущее за открытыми технологиями и стандартами, потому что они дают гибкость и возможность выбора, что хорошо для бизнеса и рынка.
Да, жалко немного людей, которые 30 лет делали одно и то же и настолько закостенели в своих привычках, что переход на что-то другое для них сложен а нередко и невозможен. Но, с другой стороны, я видел и нежелание учиться и смотреть что происходит вокруг у многих. Слишком удобно было думать, что вот это, полученное когда-то знание будет кормить всегда и можно не развиваться в профессии. Так что и не особо жалко. Пора, друзья, или начать учиться новому или идти на пенсию.