131–140 of 163 posts
Earlier quoted context omitted.
https://www.cnet.com/news/windows-may-crash-after-49-7-days/ Windows has improved since then, but it's still a very brave person that would have a single business-critical Windows machine without a few scheduled maintenance and reboot periods every year.
That bug is from 2002. Do you really think it's a solid reason to not host business-critical things on Windows in 2018?
Earlier quoted context omitted.
Channel I/O was something I wanted on all my desktops and servers. It helps mainframes get their high utilization ratio and throughput: https://en.m.wikipedia.org/wiki/Channel_I/O
How does this map to the current state of commodity computing? For example, it seems we already achieved that with disks, once embedded controllers attached to DMA-capabled HBAs became the norm. A similar thing seems to have happened with NICs, as well as the ability to offload higher-level protocol processing (another mainframe-like feature).
Earlier quoted context omitted.
Clouds reinvent mainframes. They're still cheaper, run more FOSS, and have more talent available. They're a better form of lockin than mainframes.
> They're still cheaper Are they, though? Commodity hardware certainly is, but it's not as if cloud providers are charging a small margin on top of that. They're charging a multiple, potentially as large as 10x. Combined with the parent's proposed need of multi-cloud, that could turn what might otherwise be a few hundred $k of commodity servers into a few $M of cloud costs, which I understand is the OOM the cost of a…
With IaaS typical reliability issue is that whole location/datacenter/AZ goes down, with your own infrastructure the typical issue is that the colo-facility/datacenter goes down, which would be essentially identical save the fact that with IaaS there is significantly larger probability that the reason for going down is some byzantine failure of orchestration automation, which in the self-hosted case either isn't there or is under your control.
One fact of running your own infrastructure is that you should plan for hardware failures, but not stress about it too much, because even entry-level enterprise-grade hardware just does not break (and if it does you will get signs that it is going to break well in advance).
Ok, maybe this is a silly question, but I am a millennial.... Question: what is a mainframe and why would I want one? In my mind I think of it as a big, but inelastic, compute resource. If that's true, why wouldn't I want to use something horizontally scalable instead?
You own one because your company or agency bought one in 1970, and it is cheaper to run it than to redo everything. You may need one for certain new workloads if you’re a defense contractor.
As an employee, you’re a pure operational cost center. You have skills that few employers care about, and vendors/contractors are churning out cheap replacements for you.
Earlier quoted context omitted.
Try this: Ok, maybe this is a silly question, but I am {...}.... Question: what is a house and why would I want one? In my mind I think of it as a big, but inelastic, tent. If that's true, why wouldn't I want to just get multiple tents instead? A mainframe is the kind of computer you can buy and set up, turn on, and run for two decades (or more, if you like) non-stop. It doesn't need reboots, it most often doesn't ev…
Except when they do go down it can be a catastrophic business interrupting event. Which is why the cloud model of assume everything is going to break and all your hardware is disposable works much better (IMO).
You could almost think of a mainframe as a cloud in a box, and if one isn’t realiable enough, you can always run two or more.
Earlier quoted context omitted.
Here's my favorite: https://support.microsoft.com/en-us/help/2553549/all-the-tcp... article about it: https://blog.ctm-it.com/it-support/blogs/matt-cannon/2013/49... edit: If you want to be especially cynical, you can note that this wasn't discovered for a while because everyone running Windows reboots it regularly because of its notorious instability issues (the bug was found in 2013 and dates back to at least Vista…
> because everyone running Windows reboots it regularly because of its notorious instability issues I reboot monthly because getting owned by 0 days sucks, and at this point in life, every platform (except for OpenBSD) is having new exploits found against it at a rather fair rate. Same reason my phone gets rebooted once a month. Aside from that, I have had uptime on Windows boxes in excess of 6 months. Laptops on the…
Windows laptops.
My MacBook has been up 56 days 14:06 hours.
Earlier quoted context omitted.
How does this map to the current state of commodity computing? For example, it seems we already achieved that with disks, once embedded controllers attached to DMA-capabled HBAs became the norm. A similar thing seems to have happened with NICs, as well as the ability to offload higher-level protocol processing (another mainframe-like feature).
The Channel I/O worked on many devices and the OS. Far as cost, using AWS might not be cheap but I was thinking redundant VM's or dedi's with cost-effective hosts. That doesnt cost hundreds of thousands to millions a year.
Initially, you mentioned high utilization ratio and throughput. I think the former is a red herring [1], but I'm curious about the latter. I've certainly witnessed poorer I/O throughput under virtualization, but on bare metal, throughput doesn't seem to be limited (beyond the capabilities of the bus).
[1] e.g. it doesn't matter if CPU is pegged but I/O channels are at 10% if the workload is CPU-bound and CPUs are the expensive part to scale. Or substitute memory for CPU.
Fine. I want to learn how to maintain/write software for a mainframe. How do I start? Can I get access to one? Can I build up something I can learn on? What is the best path for doing this? How would I usefully gain enough experience to get into this? I have linux, python, c, but unsurprisingly can’t afford 30 million (or whatever) on a mainframe. I know about Hercules, but I’d only be able to run Linux. Is that righ…
Rent cloud access http://www.timeshare400.com/
Hercules http://www.hercules-390.org/
Debian s390x is linux that seems to be supported.
Earlier quoted context omitted.
> They're still cheaper Are they, though? Commodity hardware certainly is, but it's not as if cloud providers are charging a small margin on top of that. They're charging a multiple, potentially as large as 10x. Combined with the parent's proposed need of multi-cloud, that could turn what might otherwise be a few hundred $k of commodity servers into a few $M of cloud costs, which I understand is the OOM the cost of a…
Problem with IaaS clouds is that it is strictly less reliable than having your own infrastructure. With IaaS typical reliability issue is that whole location/datacenter/AZ goes down, with your own infrastructure the typical issue is that the colo-facility/datacenter goes down, which would be essentially identical save the fact that with IaaS there is significantly larger probability that the reason for going down is…
That said..
> Problem with IaaS clouds is that it is strictly less reliable than having your own infrastructure.
Although I'm a fan of running ones own hardware, I'm not sure I could make this claim. However, since I'd like to, do you have public data to back it up?
> orchestration automation, which in the self-hosted case either isn't there or is under your control.
I'm not sure how that would be different. Although a provider like AWS has portions of the automation toolchain not under your control, it's not obvious they're any more likely to fail (even due to some bizarre interoperability bug) than, say, BMC firmware, which is also not under your (full) control.
> One fact of running your own infrastructure is that you should plan for hardware failures, but not stress about it too much, because even entry-level enterprise-grade hardware just does not break (and if it does you will get signs that it is going to break well in advance).
This is something that I routinely have to point out to cloud proponents when they complain about having to "worry" about hardware failing: modern, commodity server hardware just doesn't fail often enough for it to be a significant consideration. Usually, it's just selection bias in that they remember every "nightmare" scenario from their past where hardware failed (possibly even as long as 20 years ago) but don't account for the overwhelming majority of times when it didn't.
Of course, there are notable exceptions, such as high-density "blade" or half-U servers, which often suffer from thermal design failures, but I argue that those are a departure from commodity, even if they appear identical if one squints.
Most importantly, though, it's not as if an IaaS cloud provider can somehow magically shield you from the consequences of such a failure: your VM will still go down. Sure, they have an arbitrarily large supply of spares to replace it, but you only ever need exactly 1 of those spares, and N+1 redundancy when self-hosted is very easy, if implemented merely as warm spares.
Earlier quoted context omitted.
I'm not sure if your argument supports your conclusion: 1) You mentioned layoffs, but you didn't mention how long it took those people to find new jobs. 2) For those who couldn't find new jobs, how many of them avoided interviews or job offers because they were unwilling to relocate? 3) How transferable are "mainframe" skills to other "mainframe" installations? (As a non-mainframe-programmer, I have no idea how much…
FWIW, a couple of years back I had a gentleman who was a 30 year mainframe programmer in a Rails & Postgres class that I taught. He learned both, was humble enough to take an internship for a Rails job at over 50 and then turned it into full employment. Anecdotal, but I found it interesting to watch the portability of experience.