On 4/13/18, 3:22 PM, "Linux on 390 Port on behalf of Gibney, Dave" <[email protected] on behalf of [email protected]> wrote:
> I FIND THIS DISCUSSION TROUBLING. It will not likely ever affect me of my > installation, has we haven't (and unfortunately are not likely to) used > zLinux and Z/VM. The idea spawned from a lunchtime discussion about how to reduce the entry cost sticker shock for Linux on Z; the PHBs have been conditioned to think that Linux = minimal/zero cost, and when they see the price tag for $X thousand for a Linux distribution plus the cost of z/VM plus the cost of the hardware, it turns them off the platform (Quote: "if that's going to cost us > $50K to try to do the same thing that we can already do with a spare PC we're buying anyway for other purposes for nothing, why would we want to do that?" Wrong, but it passes as rational thinking in PHBworld). If you can spin the discussion as "start small, grow quickly without having to do purchase orders every 5 minutes" and/or "pay only for what you use while still getting the QoS and support you expect from the mainframe", they seem to like that framing more. From there it was a "how do we do this with the minimum amount of work, preferably none, by reusing something that already exists in a creative way" idea. > But, is the z/OS MIPS/MSU pricing model (IMO, one of the major drags on the > platform) really being extended into this arena. I agree it's not ideal, but it's one that most people with Z hardware already understand and that we don't have to argue about having different tools to look at usage for different OSes. It also has the advantage of neatly integrating with how IBM already thinks about some kinds of pricing, which makes it easier to sell to 3rd party vendors as "use something that already exists instead of inventing yet another unique weird gadget to do this". It also has the advantage of the whole picture in one place rather than chasing it down all over the place. My main concern with the tool Tim mentioned is how closely is it tied to the whole BigFix tool ecosystem? SCRT doesn't seem to require any external dependency stuff to work (other than a working Java interpreter), and a quick look at the docs appear to show that the other tool seems to bring in a whole bunch of other dependencies, some of which are priced. Is that the case? Sounds like general consensus is that it's not a great idea. It's worth having the discussion, though. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
