cpitman

#2 isn't surprising. A ton of shops only patch on a quarterly basis, and even then they only consistently patch the OS. Only when there is a vendor (like my employer, Red Hat) sending out notices that there is a critical vulnerability do people move any faster.

Which is twice as bad for application dependencies. These don't even have quarterly patch cycles. Dependencies may be updated when a new release is deployed, which may be a couple times a year or never. One of my favorite questions for clients is "who is responsible for patching applications with no development team anymore?"

This is an underappreciated benefit of CICD. An automated process lets you get a central group to take ownership of third party libraries and their security, and then let them trigger all applications to rebuild and release. Especially with containers, this is essential.

What does that lead to? Contempt of court?

I don't know of any. I don't consult for the mainframe systems themselves. Usually I get pulled in when the client realizes that their last mainframe developers are years away from retirement, and they cannot find any new mainframe developers to hire. That starts a mad dash to migrate/replace the mainframe solution without disrupting the entire business. Despite the existing codebase, these projects are very difficult because noone knows how they work anymore.

At one of my clients they had one mainframe developer left that knew their systems. She had already tried to retire, but they got her to agree to stay on for 5 years in return for bags filled with money. That meant they had 5 years to rewrite on a platform they could actually hire people for. 5 years to replace a system with decades of history.

I also consult for Fortune 500 companies on a regular basis, and most of them still have core business processes running on mainframe code bases well older than 10 years. No one is doing major greenfield development on mainframes, but they still exist all over the place.

Has this ever happened? There are plenty of companies that are not software companies releasing open source software.

Yep, every time I hear people get excited about live migration of containers I have to give them a sideways look. If you are running only one instance, than availability must not have mattered that much to you.

Remember that OpenShift.io is just one (newer) way to work with OpenShift, currently focused on deploying to the hosted OpenShift Online.

But if you are looking at doing self-hosted Kubernetes, you really should give OpenShift a look. It does a lot to give sane defaults for things like ingress and building containers, while simplifying the deployment story.

For just getting started and kicking the tires, you can use minishift to spin up a local VM with everything installed and configured: https://www.openshift.org/minishift/

Disclaimer: I also work for Red Hat. We're everywhere :-)

This! In the same vein, believing that "this time" the team will work faster because of lessons learned. Refusing to accept that historical performance really is the true performance of the team. Failing to account for the previous project completing almost on schedule only because of major overtime. Etc etc.

On my first project I learned that every time a PM said the word "hope" (as in "I hope we can meet this deadline") that we were screwed. It was said a lot.

OptaPlanner is an open source constraint satisfaction solver (https://www.optaplanner.org/). Here is an explanation of how it can be used to solve the Vehicle Routing Problem, closely related to TSP: https://www.optaplanner.org/learn/useCases/vehicleRoutingPro...

Last I checked, IRCv3 had also given up standardizing the server-to-server protocol.

As someone who has written an IRC server implementation, there is no standard protocol. There is an RFC, but no one implements it. Instead, each server uses its own mix of poorly documented pseudo-standards.

Three pieces of feedback:

1. The tutorial is really long. It would be better if it was broken up by campaigns that use what you've learned so far. I just got to the fire mage section, and am starting to lose interest.

2. This really drove home how much sound matters. Even just some background music and simple attack sound effects would go a long way to make the game more immersive.

3. The other player's turn happens so fast that I don't get a sense of what happened on it.

That Space Shuttle was reusable, and it still had catastrophic failures.

I think you are jumping to conclusions here, OpenShift.io is committing to a git repository. I'm guessing you'll still be able to clone this repo locally and use your own tools.

Another good technique is to pair metrics. Find a second metric for each metric you care about that you expect to see negatively impacted if you overfit for the first metric. For example, you might pair user growth rates with per user acquisition cost.

Both of these are easy to fix. Configure etcd with peer certificates for clustering and a cert for client-server connections (https://coreos.com/etcd/docs/latest/v2/security.html). If you need encryption at rest, encrypt the filesystem.

If setting up a secure cluster is daunting, then use a distribution that handles it for you. OpenShift (https://www.openshift.org/) is built on kubernetes, and it's install is secure by default.

Disclaimer: I work for Red Hat, and spend lots of time on OpenShift consulting.

Higher resolution and higher refresh rates are still needed for VR. VR requires both a relatively high refresh rate (90Hz) and pretty high resolutions (current generation devices are 2160x1200). I believe that uses most of the bandwidth of HDMI 1.3, I'm not sure if any headsets use HDMI 2.0 yet.

And if you've tried VR, we're still at the point where pixels are obvious and higher densities would be an improvement. The usual comment I get when friends try my Vive is that it looks like an N64.

I actually did this a while ago. I wanted to try out creating a docker base image from scratch so created one for RHEL 4 and then launched it as a container on RHEL 7. I didn't do too much with it other then prove out that I could run processes in it, but as far as I could tell it was functional. And the weird looks I got from people when I told them about it were great!

Disclaimer: I work for Red Hat.

It depends on what the customer has already. We (Red Hat) support installing OpenShift anywhere that RHEL x86-64 is supported, whether that is bare metal, vms, private/public cloud, etc. For example, our hosted "Heroku like" OpenShift Online is on AWS (https://www.openshift.com/devpreview/).

OpenStack (IaaS) != OpenShift (PaaS)

Getting up and running with OpenShift is pretty easy. You can either use the all in one Vagrant VM[1] or you can download the CLI[2] and run `oc cluster up`[3] to install the docker container version.

Either one doesn't give you an "HA" install (probably want a cluster for that). I regularly deliver OpenShift installs, and in most enterprise environments an HA install takes 3-4 weeks, most of which is communicating to all the silos (networking, storage, security, virtualization, etc) what the requirements are.

Disclaimer: I work for Red Hat.

1: https://www.openshift.org/vm/ 2: https://github.com/openshift/origin/releases 3: https://github.com/openshift/origin/blob/master/docs/cluster...

I've worked in transit. This is not only feasible, it is how it is done.

I'm no tax expert, but couldn't these losses be offset by Tax Loss Harvesting? It doesn't wipe them out, but does reduce the loss by approximately your top tax bracket.

Take a look at the open source project Keycloak (http://www.keycloak.org/), it does exactly that and takes very little time to setup. The easy way is pretty much:

  1. Run the docker container (https://hub.docker.com/r/jboss/keycloak/)
  2. Login to the web console
  3. Create a "Realm"
  4. Go to "User Federation" and add a "LDAP" provider
  5. Go to "Clients" and configure keycloak to handle OpenID/SAML for your app

Disclaimer: I work for Red Hat, and Keycloak is one of our projects. If you want support, we recently released it as RH SSO.

Are you installing docker out of the CentOS repositories, or from Docker Inc's repository? The CentOS version is based on the work Red Hat does to backport patches and create more production ready versions of Docker, so that might be why you are having a better experience.

We've already released a PaaS built ontop of Kubernetes at Red Hat, with the upstream named OpenShift Origin and the supported version named OpenShift Container Platform (https://www.openshift.com/container-platform/).

Our developers contribute a ton of work to the Kubernetes project, and pretty much everything that works on Kubernetes will also work on OpenShift. We do have some security settings by default that are more restrictive (like no containers running as root) but that can be easily modified to be more permissive.

Which release is going to be production ready, and which features are production ready in each release? If Docker Inc documented which features are production ready, I'd have more sympathy for that point of view.

What we've had to do at Red Hat is always stay a couple releases behind (we're shipping 1.10+patches right now) and backport all the fixes from upstream releases to make it stable (ie production ready). Docker keeps shipping new versions, with fixes for old issues but then a whole new set of issues added in.

Do municipalities collect and release any data on how people move around the area? For example, start and end points, with usual times for leaving or arriving. A large enough sampling of something like this seems important for planning, and I assume the real planners have it.

The usual idea is (1) to encourage stronger separation between the actual business logic and any boilerplate that surrounds it and (2) to write business logic in a way more accessible to non-developers.

A rete-based rules engine is more than just a sequence of if-then statements, they allow for any rule to assert new facts that then cause other rules to trigger/retrigger. This also lets you gradually introduce new facts and have the results updated.

Business rules systems and logic programming are definitely similar. Most business rules are based on "Forward Chaining" (https://en.wikipedia.org/wiki/Forward_chaining), basically using what we know to satisfy the left hand side condition and then using the right hand side to assert new facts. Logic programming is usually based on "Backward Chaining" (https://en.wikipedia.org/wiki/Backward_chaining), where the system attempts to work backwards from a goal to what facts are needed to satisfy the goal.

John Oliver had a great segment on Civil Forfeiture a couple years ago: https://www.youtube.com/watch?v=3kEpZWGgJks