[HN Gopher] New IBM LinuxONE 4 Express - Rack-mounted pre-config...
       ___________________________________________________________________
        
       New IBM LinuxONE 4 Express - Rack-mounted pre-configured Linux
       mainframe
        
       Author : rbanffy
       Score  : 67 points
       Date   : 2024-02-06 19:39 UTC (3 hours ago)
        
 (HTM) web link (newsroom.ibm.com)
 (TXT) w3m dump (newsroom.ibm.com)
        
       | gottorf wrote:
       | Yours for only $135k (starting)! Supposedly it's designed for
       | eight nines (99.999999%, or ~30 seconds of downtime a year) and a
       | MTBF in the decades. I'm curious if at that point, assuming it
       | lives up to it, if other factors outside of it, like DC power and
       | cooling availability or internet connectivity, won't also be
       | difficult to achieve.
        
         | neverartful wrote:
         | The $135k is just the hardware price for the base
         | configuration. I'm sure you're required to license several
         | software SKUs that are not cheap and that you have to pay
         | annually for maintenance.
        
         | Yasuraka wrote:
         | 30s a year is 6 nines, 8 would be 300ms
        
           | gottorf wrote:
           | I believe the ninety-nine before the decimal point counts as
           | two of the nines, but I'm sure different people word that
           | differently.
        
             | Yasuraka wrote:
             | Yes they count and were included
             | 
             | https://www.globalcallforwarding.com/wp-
             | content/uploads/2022...
        
         | jhallenworld wrote:
         | or, especially, software
         | 
         | It's a z-series mainframe and I don't doubt these reliability
         | numbers.
         | 
         | The world's financial system runs on these mainframes. An
         | undetected bit error at the federal reserve might cause IBM to
         | appear in the news, in a bad way, like Boeing..
         | 
         | It will not have the fastest single-threaded performance, but
         | that's not why you buy it.
         | 
         | The mainframe mindset: Of course each core is running at 100%
         | all the time... I paid a lot for it, so I want my money's
         | worth. z/OS is designed to make this feasible. Not sure how
         | well that works in Linux.. but it's where the market is.
        
           | bitwize wrote:
           | The LinuxONE line is, I believe, a series of Linux-only
           | mainframes; z/OS is not an option on them. They're IBM's
           | entry-level option for businesses who salivate at those
           | mainframe reliability numbers but don't have any
           | OS/360|OS/370|z/OS apps and don't want to pay for the support
           | on those systems.
        
             | jhallenworld wrote:
             | I think you're right it can't run the apps, but I see it's
             | running z/VM as the hypervisor.
        
               | coolkil wrote:
               | Only for Linux guests. It is also possible to run kvm
        
         | dalemhurley wrote:
         | So one month of AWS costs.
        
         | wmf wrote:
         | A single box of any type absolutely cannot deliver eight nines.
         | Maybe a sysplex running very limited software...
        
         | billforsternz wrote:
         | 30,000,000 (ish) seconds in a year, 99.999999% of that is ....
         | let me see, 99.999999% of 100,000,000 is 99,999,999 I suppose.
         | So downtime is what's left over, about 1 second every 3 years
         | or 300 milliseconds a year not 30s a year. I think.
        
       | cameron_b wrote:
       | "Compared IBM LinuxONE 4 Express Model consisting of a CPC drawer
       | and an I/O drawer to support network and external storage with 12
       | IFLs and 736 GB of memory in 1 frame, versus compared 3 x86
       | servers with two Xeon Sapphire Rapids Platinum 8444 processors
       | with 32 cores each (2ch/32c) with a total of 384 cores"
       | 
       | I'm not a math major, but that's a bit strange to me.
        
         | stonogo wrote:
         | That adds up to 192 cores, so they probably mean 384 threads.
        
       | bitwize wrote:
       | Lol @ the marketing gymnastics. "Hybrid cloud" and of course a
       | namedrop of AI.
       | 
       | What this is is a _mainframe_ , a solution with decades of proof
       | behind it in terms of reliability and I/O throughput. In other
       | words, the advantages of cloud without the cruft and BS. Maybe
       | that's what they mean by "hybrid cloud"?
       | 
       | I wish IBM would come out and say what they mean, but maybe they
       | wouldn't be IBM if they did.
        
         | thatoneguy wrote:
         | Isn't "hybrid cloud" mixing "on-prem" servers with remote
         | servers at a cloud provider?
        
           | bitwize wrote:
           | Usually, but a mainframe is an on-prem solution and can only
           | fill that part of a hybrid cloud strategy. I get the feeling
           | IBM thought they'd lose the CTO crowd if they didn't say
           | "cloud" every now and then.
        
             | subpixel wrote:
             | And good that they do, otherwise I would not get so much
             | evergreen enjoyment from the cloud-to-butt browser
             | extension I've had installed since forever.
        
       | neverartful wrote:
       | Would be curious to know how it compares in power consumption and
       | heat output; licensing cost of z/VM; is PR/SM (allows you to
       | create and configure LPARs) available? licensing cost?
        
         | coolkil wrote:
         | I worked on multiple LinuxOne systems. You can run z/vm and
         | pr/sm. it will also run kvm if you like.
         | 
         | Power consumption (of our box z13 based)is 3kwh regardless of
         | configuration (give or take) but also consider you need a lot
         | less san switches and networking switches to achieve the same
         | goal as a large rack of individual servers
        
       | abtinf wrote:
       | I previously led a significant chunk of developer evangelism at
       | IBM. Mainframes are unbelievably powerful, feature-full, and
       | cost-effective. You are almost certainly better off buying a low-
       | end mainframe than hiring a team of engineers to build yet
       | another not-great data replication/recovery/HA system. Imagine
       | being able to hire engineers to work on your core value add
       | instead of basic computer management problems IBM solved in the
       | 60s.
       | 
       | The reason you don't is because it is basically impossible to get
       | access to a mainframe you can play with and learn on. And IBM's
       | internal incentives and financial metrics ensure that can never
       | happen.
       | 
       | * My views are my own and not those of my former employer.
        
         | tines wrote:
         | What even is a mainframe, exactly?
        
           | abtinf wrote:
           | A modern mainframe is a system specialized in extremely high
           | transaction throughput at extremely low cost-per-transaction,
           | while guaranteeing data durability and computational
           | correctness.
        
             | tines wrote:
             | Sounds like a computer. Why would getting access to one to
             | play around encourage people to buy one? In other words, it
             | sounds like a quantitative difference rather than a
             | qualitative one.
        
               | jsight wrote:
               | True. I find it interesting how difficult that they find
               | it to put the benefits into words that don't sound like a
               | brochure.
               | 
               | Surely there should be some specifications behind this?
               | Benchmarks?
        
               | rbanffy wrote:
               | Anandtech ran a story when the z16's CPU was announced:
               | 
               | https://www.anandtech.com/show/16924/did-ibm-just-
               | preview-th...
        
               | zeroCalories wrote:
               | My understanding is that Z mainframes have a number of
               | unique features to support those use cases. Stuff like
               | hot swapping CPUs, and hundreds of IO coprocessors to
               | avoid the main cores from getting blocked. Don't think
               | they're just rebranded x86 machines, but not an expert.
        
           | dgacmu wrote:
           | The other definition you got isn't bad, but I think it misses
           | the point for this discussion: it is a rack or multi rack
           | scale computer with built-in and centrally managed features
           | for redundancy, failover, job allocation, scaling, etc.
           | 
           | As an example, in many main frames, you can configure them
           | with a spare set of CPUs, and if one of your CPUs fails, the
           | replacement is brought online automatically and
           | transparently, the code you write doesn't have to know about
           | anything related to the failure.
        
             | rbanffy wrote:
             | One neat thing is that the hot spares can be used during
             | boot to shorten the time to availability. Not sure LinuxONE
             | boxes are bought like that, but for the Z-series you can
             | buy the machine with more capacity than you pay for and pay
             | for it to be enabled at a later point.
        
           | zjaffee wrote:
           | It's essentially a very large single clocked machine.
        
           | beAbU wrote:
           | I see it as similar to an on prem mini AWS cloud, with
           | dedicated hardware for things like WAF, storage, compute,
           | networking, lambdas and databases.
           | 
           | I've heard it said a couple of times that working in cloud is
           | closer to working on a mainframe than most want to admit.
        
           | Keyframe wrote:
           | Dave Plummer recently did a tour:
           | https://www.youtube.com/watch?v=ouAG4vXFORc
           | 
           | It's definitely intriguing if it were.. I don't know,
           | available to tinker with?
        
         | jhallenworld wrote:
         | Well you can run Hercules, the emulator. But you will then
         | discover that the mainframe 3270 terminal user interface
         | experience is terrible. A funny thing is this: there is a
         | mainframe plug-in for Visual Studio Code. The idea is you do
         | your COBOL development in Code, and only the plugin actually
         | talks to the mainframe.
         | 
         | A decade ago there was an Eclipse version of this..
         | 
         | This guy is showing all three ways:
         | 
         | https://www.youtube.com/watch?v=_CYUYnKim7U
        
           | bitwize wrote:
           | This kind of thing goes back five decades, actually. One of
           | the earliest versions of Unix was PWB/Unix, for "Programmers'
           | Workbench". It was designed as a system for AT&T engineers to
           | author programs for the mainframe in a more sensible (for the
           | time) environment and included software to submit jobs to the
           | mainframe once the programs were written.
           | 
           | The idea of "Unix as your IDE" is a deep, deep cut into Unix
           | lore.
           | 
           | https://en.m.wikipedia.org/wiki/PWB/UNIX
        
           | ethbr1 wrote:
           | > _the mainframe 3270 terminal user interface experience is
           | terrible_
           | 
           | [... for new users]
           | 
           | For expert users? I'd pit it against any interface you want.
           | 
           | No-mouse + hands-on-keyboard + tab is hard to argue with.
           | 
           | Sadly, the number of people who remember when GUIs could be
           | driven from memory by keyboard-only has dwindled.
           | 
           | Watch a 10-year veteran insurance employee use a green
           | screen.
           | 
           | Or as a counter-example, try to tab through your modern app
           | du jour. (Modern developers often don't even bother to set
           | indexes correctly)
        
             | pmontra wrote:
             | Except when you must set tabindex="0" or "-1" or
             | Bootstrap's modals won't work. /grin
        
             | jl6 wrote:
             | > Watch a 10-year veteran insurance employee use a green
             | screen.
             | 
             | Yes! I knew an Insurance customer service op who self-
             | described as having no computer skills, but when I saw her
             | using Reflection it was like watching a speedcuber savant.
        
         | alfalfasprout wrote:
         | And that lack of access is exactly why there's such a minimal
         | ecosystem for open source tooling for mainframes.
        
           | fweimer wrote:
           | Open source software shouldn't be a problem. Pretty much
           | anything that has been ported to 64-bit big-endian also works
           | on s390x. The architecture is otherwise pretty non-
           | challenging: always 4K pages, strong memory model. Pre-built
           | binaries are a different matter, of course.
           | 
           | The problem with access is not access as such, but the fact
           | that the community hardware that you can access for free
           | tends to be heavily oversubscribed (or maybe connected to a
           | mismatched storage system).
        
           | rbanffy wrote:
           | That is something that concerns me, but much more on the Z
           | side than on the LinuxONE. On the Linux side, it's just a
           | very fast computer.
        
         | genmud wrote:
         | > Mainframes are unbelievably powerful, feature-full, and cost-
         | effective.
         | 
         | Maybe things have changed in the last 10 or 15 years, which is
         | the last time I had a legit mainframe at a day job, but back
         | then none of those things were true if you looked at it more
         | than 20 minutes.
         | 
         | I seem to remember nothing being included in the base
         | mainframe... when you started to add things like DR and data
         | duplication and virtualization, it became extremely expensive.
         | Like on the DB side, effing Oracle was much cheaper.
        
           | rbanffy wrote:
           | Software licensing is expensive on them, but the people to
           | keep your 99.999% uptime on your Kubernetes cluster aren't
           | cheap either.
           | 
           | And software licenses are one of the reasons why LinuxONE
           | machines exist - they don't run z/OS, so you don't pay those
           | licenses. You can even start a dozen VMs under an LPAR and
           | run your Kubernetes cluster as if it were running on more
           | common hardware that just never, ever fails. IIRC, you can
           | run a special version of z/VM to manage your Linux VMs if you
           | don't want to run Linux on the LPAR and use KVM for your VMs.
        
             | zeroCalories wrote:
             | Why bother using an LPAR if you're just gonna use
             | kubernetes anyway? Why not just use one fat machine?
        
               | rbanffy wrote:
               | LPAR isolation happens on a lower level than z/VM or KVM.
        
         | sonnyOrullivan wrote:
         | Sorry to say that your previous "evangelism" shows. It would be
         | very interesting to hear what "unbelievably powerful" means (as
         | in facts and numbers) compared to what a hyperscaler can
         | provide. E.g. SPEC for CPU, GFLOPs, Tensor-ops for inference,
         | latency and so on. Last I checked the consolidation story that
         | claimed factors of savings took underutilized ancient Intel
         | boxes as baseline.
         | 
         | "feature-full" is also quite a stretch when it comes to
         | software when most modern software needs to be ported or run in
         | a Linux LPAR.
         | 
         | In addition I'd question that not getting access easily is the
         | main reason for the lack of adoption. It might be part of the
         | problem but the other problem is that the thing is a niche
         | product and IBM doesn't seem to be utterly successful in either
         | explaining what the niche is nor how to extend it.
        
           | cbsmith wrote:
           | Last I checked, the Teliums had some pretty impressive
           | numbers for memory bandwidth even compared to NVidia.
        
             | wmf wrote:
             | It doesn't. Mainframe terminology is so obfuscated that
             | it's impossible to tell for sure but it sounds like less
             | memory bandwidth than Genoa.
        
               | rbanffy wrote:
               | They are tailored to the traditional mainframe workloads
               | (they do a lot of hardware/software co-design in their
               | mainframe lineup), so I wouldn't expect a mainframe
               | designed for the generic cloud hyperscale workloads.
               | 
               | In any case, I have played with their LinuxONE Community
               | Cloud service (running on the previous-gen z15) and it's
               | _very_ fast. The impression I get is that it doesn 't
               | need to wait for IO. There is a ton of very clever
               | engineering on those machines and the z16 is a
               | technological wonder.
               | 
               | https://www.anandtech.com/show/16924/did-ibm-just-
               | preview-th...
        
             | sonnyOrullivan wrote:
             | Telum is attached to the L2/L3 so it's that bandwidth as
             | long as the model fits into it. Afterwards you go to memory
             | and you really don't want to compare DDR4 modules with RAIM
             | against HBM3 or the likes that a current compute GPU uses.
             | Latency might be closer but you mentioned bandwidth.
        
               | rbanffy wrote:
               | IIRC, with 32 MB per core (8 per die - a Telum package
               | has two of them), one socket has 256MB of cache for 16
               | cores. L1 and L2 are in-core, but L3 is on-die unused L2
               | from other core and L4 is unused L3 on the other die.
               | 
               | I am not sure if that continues off-package, but if it
               | does, a drawer with 4 chips of 16 cores each will have 2
               | GB of off-chip cache and a full-sized Z with 5 drawers
               | would have 10 GB of off-drawer cache (at this level it's
               | probably not that much faster than same-drawer memory).
               | 
               | As for the RAIM, I think it's safe to assume it has a
               | very wide path (n-1 modules) to the sockets and that
               | aggregate bandwidth will not leave the 4 sockets starved
               | (even if latencies suffer because of the redundancy, but
               | you can replace a defective memory module with a running
               | computer without it having to pause.
        
           | bayindirh wrote:
           | Being able to spare a couple of cores as a new partition and
           | moving a partition to it to replace the memory and even the
           | processor of the faulty partition with zero downtime is
           | great.
           | 
           | Consider that partitions are completely isolated from each
           | other. Not some pesky soft isolation either, it's all done in
           | hardware. In practice, every partition in a mainframe is a
           | different logical yet isolated mainframe.
           | 
           | Mainframes are built for different kinds of workloads. They
           | are not cloud machines. They are batch machines with 6 or
           | more nines of uptime.
           | 
           | In my current job, a mainframe would be useless. However,
           | fore mission critical core services which needs predictable
           | latencies (bank transaction engines, central big databases
           | etc.) I'll take a mainframe all day, every day.
        
             | sonnyOrullivan wrote:
             | > Consider that partitions are completely isolated from
             | each other. Not some pesky soft isolation either, it's all
             | done in hardware. In practice, every partition in a
             | mainframe is a different logical yet isolated mainframe.
             | 
             | "Completely isolated in hardware" as in isolated by a
             | software hypervisor (PR/SM) that doesn't have a whole lot
             | of hardware support?
             | 
             | > Mainframes are built for different kinds of workloads.
             | They are not cloud machines. They are batch machines with 6
             | or more nines of uptime.
             | 
             | That's kind of the point. What exactly is the niche, i.e.
             | which new customer with exactly what software and latency
             | requirements would switch from their current system to a z?
             | IBM won't tell you apart from buzzword bingo.
        
               | fuzztester wrote:
               | >buzzword bingo
               | 
               | I'm guessing that many of the terms in this thread are
               | buzzwords for many of us reading it :), since relatively
               | few people work on mainframes.
               | 
               | I had not heard of the term buzzword bingo before, so I
               | googled it:
               | 
               | https://en.m.wikipedia.org/wiki/Buzzword_bingo
               | 
               | Interesting. It aligns with my corporate experience in a
               | few cases.
        
         | gtirloni wrote:
         | _> Mainframes are unbelievably powerful, feature-full, and
         | cost-effective._
         | 
         | I really doubt they are any more powerful than the best x86
         | rack servers. Their featurefulness is super dated. They are
         | definitely not cost effective (good luck buying it from IBM
         | without a huge contract).
         | 
         | I pity the company that gets into mainframes today. Does that
         | even exist?
         | 
         | It's a proprietary nightmare.
        
           | cbsmith wrote:
           | IBM's proprietary nightmares have, historically, often been
           | quite cost effective. AS/400 did eventually get too long in
           | the tooth, but it had an amazing run for decades where it was
           | extremely competitive for TCO.
        
             | rbanffy wrote:
             | AS/400 is alive and well. It's now called IBMi and runs on
             | POWER hardware.
        
           | coolkil wrote:
           | I also think most cloud providers are at least a vendor lock-
           | in and maybe a proprietary nightmare. This way you at least
           | got your own iron and ibm comes to fix parts when they break.
           | (Without disabling your system)
           | 
           | I do agree it is debatable whether it is beter than x86 most
           | of the time cost savings projected when using a LinuxOne it
           | is based on licensing. In the past oracle licenses where per
           | core and we did a project where 8 ifl's replaced 140 x86
           | cores
        
         | 656565656565 wrote:
         | this
        
         | Thaxll wrote:
         | Cost effective is a stretch, I'm going to take a dumb example
         | but the reliability of AWS step functions and S3 is good enough
         | for 99.99% of most use cases for a 1/100 of the price.
         | 
         | Mainframes are really powerful for some specific domain which
         | most people on HN don't work in.
         | 
         | Another take is that the most valuable company in the world (
         | tech one ) don't run their core businesses on mainframes.
        
         | wmf wrote:
         | _You are almost certainly better off buying a low-end mainframe
         | than hiring a team of engineers to build yet another not-great
         | data replication /recovery/HA system._
         | 
         | To be clear, this only applies to regular mainframes running
         | z/OS. LinuxONE machines, as the name implies, only run Linux
         | where you'll have all the usual devops/SRE responsibilities.
        
           | rbanffy wrote:
           | The machines are still incredibly reliable, much more than a
           | rack full of Dells.
        
         | madmulita wrote:
         | One huge problem is you then have to deal with IBM.
        
           | jsiepkes wrote:
           | ...and you can check-out, but you can never leave (aka vendor
           | lock-in).
        
             | rbanffy wrote:
             | LinuxONE is just one big Linux machine. There's very little
             | to lock you in.
        
       | shrubble wrote:
       | Note that IFL = cores that only run Linux and cannot run
       | mainframe OSes. The Telum CPU is 5Ghz and has some level of
       | builtin inferencing accordong to their specs.
       | 
       | However the emphasis is going to be on single system image... you
       | won't need to run/manage stuff, you just kick off VMs as if it is
       | a single huge ESXi host, as I read it.
        
       | ehutch79 wrote:
       | This feels like it's strictly a brochure for management types.
       | 
       | Maybe I'm missing some larger context as to why this is on the
       | front page.
        
       | renewiltord wrote:
       | Have lots of on-prem hardware. Zero mainframes. Looks like just a
       | computing device that has high uptime? Can see the value in that,
       | but I prefer building reliability on many less-reliable machines.
       | The incremental cost of failure is lower and unused load factor
       | is higher.
        
       | swozey wrote:
       | What exactly is considered when putting a dc together that jumps
       | you from knowing that instead of maybe a very large/massive
       | cluster of whatever 1024 core servers your project needs a
       | mainframe?
       | 
       | I've been in cluster infra for like 15 years and couldn't tell
       | you pretty much anything about mainframes other than a few names
       | of them and processors.
       | 
       | Is it some sort of determined raw performance metric, teraflops
       | of some processing work?
        
         | jl6 wrote:
         | The #1 reason by far for buying a mainframe is that you already
         | have mainframe-based applications that you need to keep
         | running.
         | 
         | I'm not sure what kind of orgs (if any) are buying mainframes
         | today as new customers, but I imagine it would have to be a use
         | case something like... a niche scaling challenge, or an
         | outsourcing arrangement where the relationship with IBM is not
         | just vendor lock-in but is some kind of partnership, or you
         | have specialist compliance requirements, or contractual service
         | level obligations, or you need to provide absolute guarantees
         | about the performance/availability/security of the whole stack
         | from hardware up. Some organizations will pay $$$$$$$ to have
         | one ass to kick rather than herd multiple vendors.
        
       | gtirloni wrote:
       | I thought it was weird IBM didn't mention quantum computing to
       | win the buzzword bingo, but it's at the end.
        
       | trackofalljades wrote:
       | What on earth does "cyber resilient" mean?
        
       | gary_0 wrote:
       | I think this is the result you'd get if Oxide Computer went
       | through IBM's digestive tract.
        
       | kjuulh wrote:
       | I've previously worked on mainframes (building business software,
       | and worked quite low level with crypto libraries on them), and
       | now do some of the same but for "cloud" based software instead.
       | 
       | Mainframes are such a weird subject to me, on one hand, the
       | results we got out of the mainframes were pretty amazing, but the
       | experience was painful, absolutely, painful. The tooling is some
       | of the worst you've ever seen, official tools feel like something
       | people dreamed up in winforms. I worked mostly with PL/1 which
       | was a great language, stuck in the 80s but great nonetheless, I
       | actually prefer it to C.
       | 
       | What killed it for me was the restrictions, you had to either
       | dynamically or statically link programs, but do it in the IBM
       | flavor and build system. Which made it extremely cumbersome to
       | do, so files were 20k SoC with a single entry (main) and function
       | calls, because creating files was a pain. Line limits of 72
       | characters, we even had to send in our programs to get syntax
       | checks because the IDEs weren't capable enough (this was in
       | 2018), now I could whip up something to emulate it in docker and
       | neovim, but the people that taught me had no idea there was
       | something better out there and neither did I. We had to release
       | once a week on saturday mornings because the execution model used
       | had to have downtime during the deployment.
       | 
       | Mainframes are cursed because of the lack of tooling, and the
       | restrictions. I think Mainframes and the execution mode it uses
       | could be useful in a bunch of other places, but IBMs business
       | model just continuously tightness the screws and scared people
       | away. It doesn't have wide spread appeal either, it is "Business
       | machines" after all.
       | 
       | It should be said that I worked in IBMs version of Serverless
       | (not what it was called but it was pretty much what it was),
       | mainframes support Linux, Java, etc, etc. But you give up a lot
       | of benefits and performance if you move off, of the native way of
       | doing things.
       | 
       | I'd also argue that with todays tooling and hardware you can get
       | comparable performance to a mainframe, the only reason that
       | mainframes are as performant, and was so dominant, is because of
       | the restrictions it places on the developer. You have to write
       | low level C, PL/1 or Cobol, so often by proxy your software is
       | just fast. Kind of like Rust or C++ is nearly always quite
       | performant out of the box. Most business software just don't need
       | that level of latency control and performance today.
        
         | vibepaaac21 wrote:
         | The fact that it sorta forces you to a lower level of
         | abstraction is actually a very interesting topic and something
         | I think about a lot in the context of how mainframes have
         | remained relevant.
         | 
         | If there were a way to restrict non-mainframe ecosystems in a
         | similar way, I think it could provide a lot of value.
         | Especially for large organizations where standardization and
         | prevention of IT churn is a serious problem. I just don't see
         | how you do that in an open platform, and so I don't really
         | think it's viable outside of the mainframe space (although it
         | certainly explains part of why a lot of orgs still choose
         | mainframes despite knowing all of inherent difficulties the
         | platform presents). It's a people problem not a technical one
         | at the end of the day.
         | 
         | I'll add that a lot of the tooling deficit has been resolved in
         | the mainframe space, but often in a way I'm not comfortable
         | with. It's normal these days for mainframe developers to not
         | use the old school ISPF development environments, but the thing
         | about the awful old tooling, is that it was brutally efficient.
         | Now you are likely to be giving up a significant amount of that
         | efficiency because you've replaced it with a bunch of JVMs
         | running web services.
         | 
         | There is in some sense an unavoidable tradeoff between modern
         | conveniences and efficiency that I don't think there are any
         | easy ways to get around. We can't have our cake and eat it too,
         | and you cannot have mainframe level performance without it just
         | being a bunch of COBOL and C.
         | 
         | This applies just as much to Linux servers as it does
         | mainframes. I'm not really even commenting about the
         | architecture. There are similar tradeoffs involved in how we
         | choose Linux distributions, although perhaps a little less
         | extreme.
        
       | azinman2 wrote:
       | "As businesses move their products and services online quickly,
       | oftentimes, they are left with a hybrid cloud environment created
       | by default, with siloed stacks that are not conducive to
       | alignment across businesses or the introduction of AI."
       | 
       | Word smithed to death corp speak.
        
       | 462436347 wrote:
       | The linked page doesn't once contain the word mainframe.
        
       ___________________________________________________________________
       (page generated 2024-02-06 23:00 UTC)