pepemon

Intel went open source today.

What does exactly this post add to what have been already described in the official documentation[1]?

[1] https://kubernetes.io/docs/tasks/access-application-cluster/...

8.8.8.8 is a caching resolver and it wasn't down. Do you understand how caching resolvers work?

How does KDE go around the absence of merge approvals in CE? I think that this is the vital functionality for large and complex projects like KDE.

Please show me where OP was talking about HiDPI and scaling.

I've got Dell XPS 9575 with 4k display and full Prime support via DRI_PRIME=1. This thing is a truly nice Linux experience, except some problems with HiDPI and external monitors.

It was discussed previously on HN that Zen platform engineering lead wasn't him.

> It's also the only model Ansible is reliable at.

Please elaborate more on your statement. I have folks within my team whose paycheck consists of their ability to write fully idempotent roles and playbooks. Well, even I can do this without any pain, but my expertise has shifted into Kubernetes in past years.

Why are you defining Ansible as some script engine? "Bash on steroids" is definitely Ansible anti-pattern.

Right, but the HCL syntax and overall Terraform paradigm is not.

Are you okay?

Have you worked with CoreOS? It's fully driven by systemd, no problems at all. You know, when something works, nobody talks about it. But when it fails for just one time...

Yeah, the same question about the fingerprint support. There are plenty of decent modern laptops with fine Linux support, except the fingerprint. Well, I'm typing this from my XPS 9575 under Fedora 31 with 5.5 kernel where everything works, except, well, the fingerprint.

And how can I run OCI-compliant image straight to the jail? Docker isn't just a namespaced runtime.

What do you like the most in the V8 internals?

Have a look at JetBrains Space.

Who are you?

Well, cgroups work like that. No overhead. Your systemd services are sliced under cgroups. Where have you seen the overhead?

How can Docker affect this if it doesn't add any overhead?

Well if you're uncomfortable with its priviged daemon, you can always switch to CRI-O with Red Hat tooling for it. But for all my years with Docker as the container runtime, all security related problems have occured within the backend code, not Docker, not Linux cgroups, not Linux itself.

Kubernetes is a nice choice for specific usecases (like, well, battle-tested container orchestrating & scheduling), but overhyping it with references like "Kubernetes is a data center operating system" is absolute mess, IMO. You can't put everything in Kubernetes.

And it's also applies to OpenStack which is more than alive. While its ecosystem consists of horde of different solutions, plain nova/neutron/cinder are matured and efficient solutions to roll your own private IaaS.

Yes, Ingress resources implicitly assume that you want to get HTTP(S) traffic into the cluster, but as for example, ingress-nginx is able to expose gRPC via additional annotations and generic L3 via related ConfigMap.

NodePort is a bad practice for a such case, you are right. You get additional unnecessary routing on CNI level between the cluster nodes just to get traffic into the Ingress controller pod, for example. The solution here is to use hostNetwork mode with the pool of workers solely dedicated to scheduling Ingress controllers. Traffic directly hits NGINX/Envoy/HAProxy/Traefik/whatever and gets into the cluster without additional intermediates. You need a load balancing solution for this pool of Ingress controllers, that's right, but as I said before, this setup gives you the flexibility to cook load balancing as you desire.

BTW, community NGINX Ingress controller is able to ingress L3 (TCP) traffic into the cluster.

> Generally on k8s, you'd use a LoadBalancer

Are you sure? All encountered k8s installations (including ones rolled from scratch by me) use Ingress controllers as the option for getting traffic into the cluster. Community NGINX Ingress controller is the de facto standard. One need to use LoadBalancer service type because of its managed origin (metallb is a different beast and I wouldn't recommend it, if you need to load balance traffic to your ingresses on on-premises infra, it's better to do it outside of k8s). Anyway, you lose all flexibility and observability of Ingress solutions with LoadBalancer service types if you use them directly as traffic routers to your backend.

You have signed up on HN just to defend your employer, right? Please tell us about yourself.

Kubernetes and Docker (if we're talking about Docker as CRI, most often this is implicitly assumed) are totally different things.

12 years have passed. Glad that you woke up.

You have the stable release of Fedora CoreOS now.

What product have RH killed after acquisition?

Podman is just a "control panel" for CRI-O.