what i'd like to see is containers used for Steam games with slow loading times (or having to launch another launcher), i'd like to be able to hibernate a game and resume at a later time.
[1] http://criu.org/
51–59 of 59 posts
what i'd like to see is containers used for Steam games with slow loading times (or having to launch another launcher), i'd like to be able to hibernate a game and resume at a later time.
[1] http://criu.org/
> Container hype is running high. Developers have flocked to the technology for more easily packaging applications and running them across various disparate environments. It's a hype that should die in a fire bigger than the one reserved for Adobe Flash. Many people will think they can just deploy a shitload of containers and be done... well, each and every single one of them has to be maintained, updated for securit…
> each and every single one of them has to be maintained, updated for security fixes... No, of course not. No single container should have a lifetime greater than a day or two. "Maintenance" is deploying the latest, integration- and end-to-end-tested version of the software, as part of a continuous build pipeline.
Earlier quoted context omitted.
Ha! I worked at [major tech company] and our Puppet runs took about 3 hours. Developing manifests was surreal - punch card era code/compile/test cycles. The worst and most frequent production outages were seemingly innocuous Puppet changes that made it through code review. Our puppet manifest was in the 10kloc range, most of them generated. Containerization is now letting individual teams manage app-specific configur…
If your Puppet runs take three hours and range into the thousands of lines, that's a disastrously poorly built Puppet environment. Blame your people, not your tools. (And I say this as no fan of Puppet; I'm a Chef user. Where I've never seen anything remotely that deranged, even in dysfunctional environments.)
Earlier quoted context omitted.
No matter the possible productivity gains, I won't use anything needing more than two hours just to get started (i.e. running a Hello World). well that certainly helps frame your posts. In this case docker has a webpage that you can play around with. Maybe 10 minutes to get the basic idea. I'm struggling to find out where your hostility comes from. It doesn't make your job disposable, which it sounds like where your…
This thread has been stormed by people who work in the sys admin space and either don't care to learn the technology, have used it unsuccessfully while it was young, or see it as harmful to their career.
> Container hype is running high. Developers have flocked to the technology for more easily packaging applications and running them across various disparate environments. It's a hype that should die in a fire bigger than the one reserved for Adobe Flash. Many people will think they can just deploy a shitload of containers and be done... well, each and every single one of them has to be maintained, updated for securit…
Earlier quoted context omitted.
This thread has been stormed by people who work in the sys admin space and either don't care to learn the technology, have used it unsuccessfully while it was young, or see it as harmful to their career.
HN tech hivemind is often both conservative and arrogant: node is an aberration, atom is a travesty, docker is for the lazy, front end frameworks are overused, etc etc.
Programming is young, but if you look at the history of more developed fields such as physics and mathematics, there is a very long history of extremely respected scientists out right rejecting new theories for being outlandish and ridiculous that we now accept as the bedrock of scientific theory.
The truth is, just as with physics and mathematics, in computer science new ideas do form, but older generations rarely adapt, and it's only with death of the old, and the growth of a new generation do ideas become accepted.
Earlier quoted context omitted.
> each and every single one of them has to be maintained, updated for security fixes... No, of course not. No single container should have a lifetime greater than a day or two. "Maintenance" is deploying the latest, integration- and end-to-end-tested version of the software, as part of a continuous build pipeline.
So you depend on every application company to update their containers for every library vulnerability that emerges that they embed? Good luck with that.
Earlier quoted context omitted.
> each and every single one of them has to be maintained, updated for security fixes... No, of course not. No single container should have a lifetime greater than a day or two. "Maintenance" is deploying the latest, integration- and end-to-end-tested version of the software, as part of a continuous build pipeline.
So your haproxy, nginx, ldap, dns, nagios, sftp, ELK, imap, etc... services don't live more than a day or two? Interesting.....
Earlier quoted context omitted.
I don't know much about CloudFoundry -- but with Kubernetes, are you saying that it's service discovery, access control, monitoring and insight analysis, credential management, version control and management are not addressed directly by Kubernetes, or perhaps, not mature yet? Just trying to get clarity on what you are saying here.
I can answer for CF. Service discovery, access control, monitoring, credentials and management are part of the core feature set -- because that's what distinguishes a platform from a single tool. Version control properly lives outside the runtime environment, in my opinion; though these days CF has Gitlab integration points.