kodama-lens

Nice, search does nothing - as always

In a world where code generation is cheap, why use untyped languages? Types add confidence, stricter interfaces, and most likely a better runtime performance.

Firecracker has more tooling, but setting ist up and managing it is also more complicated, at least for k8s workloads. Libkrun is so easy for k8s! Compile crun with Libkrun support, crate a symlink of crun with the name krun, done. Works like any normal pod. Firecracker with kata-containers is a lot more brittle and complicated. I've invested quite some time getting this running for a talk I'm working on

I think there is an Issue/PR right now to change this. See: https://github.com/containerd/containerd/issues/13307

Yeah, kind of. Lidl and Kaufland is owned by the Schwarz Group. They have been busy replicating the AWS orgin story. Their cloud is called StackIT. I've worked with them. Still some room to grow but a solid foundation. I like that competition is back on

I'm happy that there will be more tooling, but the reason for that (and the target audience) should not be ai agents. It should be a good experience for humans!

Tools should be tested and quality assured. Something that was utterly missing for cloudflare's unusable v5 terraform provider. Quality over quantity with a ux that has humans in mind!

I switched our entire container build setup to buildkit. No kaniko, no buildah, no dind. The great part is that you can split buildkitd and the buildctl.

Everything runs in its own docker runner. New buildkitd service for every job. Caching only via buildkit native cache export. Output format oci image compressed with zstd. Works pretty great so far, same or faster builds and we now create multi arch images. All on rootless runners by the way

It is a know problem. The strange part for me is that they fixed it in v1.35 with the FeatureGate AuthorizePodWebsocketUpgradeCreatePermission for pods but not for nodes which have a far greater attact vector. The author also references this:

> The same behavior was fixed elsewhere

It is a problem, but in order to exploit it you need a valid token and have public kubelet endpoints or need to compromise an service within the cluster that has the required RBAC permissions. So cluster admins can cat and check their RBAC

Thanks for the write up. It is indeed a simple and good solution for smaller workloads and as already pointed out it has some limitations. For devs the explicit configuration of that HTTP_PROXY is annoying, so the last time I did an egress proxy on OpenShift I wrote a small mutating webhook that injects that envs automatically in all pods. OpenShift does this already automatically but only for some system pods. Right now I explore Cilium's Egress-Gateway since this also handles none HTTP connections and is directly within the routing layer, but it has a learning curve

Great way to apply your gathered Kubernetes knowledge! But I find the pricing tough and I don't like to give 3rd party tools that level of access to my clusters. I know its early state but I see several problems: Right now it seems to be GH only, a lot of people are on selfhosted GitLab. Does it only support helm or also kustomize and raw extra manifests. What about GitOps?

I've build similar solution for clints, mostly only CI based. Often with Flux/ArgoCD support. The thing I found difficult was to show the diff of the rendered manifest also while applying the app. Since I'm not a fan of the rendered manifest pattern this often involved extra branches. Is this handled by the app?

Since customers carry out QA, the title is correct.

It has gotten way worse since the Ai rise. Before it was the "how to be a winner" mindset now everything gets posted. Mostly AI garneted slop with glitchy AI images that advertise just plain false information. No one corrects stuff and barley anyone actually clicks a link an a post - no one cares. Just mindless self fap,fap,fap, like TikTok but for "professional" and business people

Author here. I know the old way still works and I respect that. Given the history I ask myself how long will it work, since ist not the default anymore.

I tried podman for multiple times. Normal testing & sandox stuff just works and you really can do alias docker=podman. But ass soon as you add nertworking me broke for me. And for me it is really just a tool and I need my tools working. So I switched back.

Recently I did the GitLab Runner migration for a company and switched to rootless docker. Works perfectly, all devs did not notice all there runs now use rootless docker and buildkit for builds. All thanks to rootless kit. No podman problems, more secure and no workflow change needed

There are so many bad OAuth explanations and articles, this is NOT one of them! Thanks for writing it. Will recommend when I have to explain OAuth yet another time.

My only nit pick is that the separation between OAuth and OIDC could have used a little more love, other then hat great.

I don't think that WASM will replace containers. They will continue to move closer to each other but still have their advantages in different fields.

Right now I can run containers and WASM workloads in the same k8s clusters. I dont even have to think about it with runtimes like crun/youki or wasmedge. The OCI image format is the universal package format. It always has all its need and the tooling is broad and mature.

With containers I can basically put any app in any language in there and it just runs. WASM support is far from that, there is migration toil. Containers are and will be more flexible then WASM

In my last year of university (5 years ago) I took a networking seminar. Each student took a look at a different technology to utilize multiple links for internet data transfers.

Initially I was amazed by MPTCP and wondered why it had so little adoption. As I looked into the papers I slowly figured out why. With different links (WLAN, LAN, LTE) their real world characteristics are too different for efficient aggregation. It is the head of line blocking problem times ten.

It might be fine as a back up link, but there are other problems like the limit to TCP and middelboxes dropping unknowns packets. The challenges outnumber the benefits for consumers and in data centers there are other technologies to aggregate links that operate on a level below TCP.

It would fix a lot of the provider specific aspects of OAuth2, if the spec would be more strict on some claim (attribute) names on the jwt ID token. Some provide groups, some don't. Some call it roles or direct_groups. Some include prefered_username, some don't. Some include full name, some don't and don't get me started on name and first_name.

If you implement OIDC you must certainly provide a configurable mapping system for source claim name to your internel representation of a user object.

At my old company we used to git pull and do make install on the prod server.

Now I have to file an exceptions for a found buffer overflow vulnerability in libfdisk1 identified in my miminal container image running in a locked down, read only container context. Because ITSac has processes for it.

When I was finishing university I bought into the framework-based web-development hype. I thought that "enterprise" web-development has to be done this way. So I got some experience by migrating my homepage to a static VUE.JS version. Binding view and state by passing the variables name as a sting felt off, extending the build env seemed unnecessary complex and everything was slow and has to be done a certain way. But since everyone is using this, this must be right I thought.

I got over this view and just finished the new version of my page. Raw HTML with some static-site-generator templating. The HTML size went down 90%, the JS usage went down 97% and build time is now 2s instead of 20s. The user experience is better and i get 30% more hits since the new version.

The web could be so nice of we used less of it.

I can confirm this. All Google container registries, including the official k8s repos are unaccessible via some hetzner ipv4 domains.

There is a GitHub issue that also covers the problem and it states you should report thos IPS to their support. I did but support says they can't do anything until the ip region list is updated.

IPv6 as a workaround is also difficult because some of the image I need are on GitHub and they are still not ipv6 accessible

> Ansible, if I'm not mistaken, requires python3 installed on remote hosts.

It is not a requirement. There is the raw module that just sends commands over ssh . But if you want to do anything beyond basic most people use raw just to install python so they can use other modules which require python.

While I don't agree with quite some assumptions and comparisons the author makes I tend to agree that microservices are often not the right answer for your problem.

They can be great when:

* You need just one function that is not directly related to your core application logic and might be needed by other service. Great usecase for a microservice or lambda

* You need to separate statefull and stateless components

* Have async workflows

* Scaling to infinity and beyond

But most don't application problems don't have these requirements for it's core logic. Microservices have a huge cost. Code and dependency dublication, complex deployments, latency, harder debugging and tracing and the cognitive load is much higher.

A lot of read blogs and new form netflix and google and want to do the same. The management of my current project is asking for microservices because it is the new hot sh*t, so teams are doing it just like SAFe and AI - even when it does not help to solve the problem.

> Certainly my utility websites (e.g. electric/gas) are a lot more functional and a lot less user hostile, because...those companies would really like it if you paid your bill on time, so at least that workflow is pretty polished.

Your utility websites are customer facing and everything that the user can't do themselves will result in a phone call or a ticket wich will directly drive up cost.

In enterprise it is the opposite. Whatever the costumer cant do themselves requires a ticket. Any ticket or fast ticket response requires support wich increases revenue.

I just had a meeting with someone from IBM last week about API Connect, they admit that their docs suck and are wrong in places. It is typical enterprise software, slow and cumbersome, just as reported by OP.

You mean everyone that runs a Crossplane cluster? Already happening

Naming things is hard and I don't mind if you cant tell what a software/service does by it's name but I don't like that there so little separation between the names:

> I just deployed the Grafana Oparator, oops I ment Grafana Agent Operator

Hopefully it gets better with Alloy

In advance: I like the Grafana, Prometheus, Mimir Loki stack BUT:

I have difficulties understanding their product lineup and roadmap. Everything is named Grafana something. Grafana the company, Grafana the monitoring Frontend, Grafana Agent, Grafana Agent Flow, Grafana Agent Operator, Grafana Operator. It is easy to mix things up especially if you talk to someone who is not in the Grafana world.

They also seem to change their mind quiet fast on how users are supposed to send metrics/logs. First there was the loki, prometheus clients, then Grafana Agent Operator, then Grafana Agent Flow mode and now they announced alloy at kubecon, immediately deprecating other solutions. All of wich do more or less the same - as far as I know.

These iterations are too fast for companies to develop trust in their solution. Even in private test clusters I have trouble catching up. And I have to confess the the new alloy solution did not make a good first impression. I dont't know why it replaces the Agent Flow mode and even worse, instead of sticking to k8s standards it uses its own custom configuration language that does not seem to have any advantages.

I hope they figure something out that works for base tasks and improve that solution over time instead of doing something new every year.

Is there anything that makes spin stand out?

From what I've read, it seems much more complicated then it has to be. I've been running crun with wasmtime enabled since about 1 year in my private test clusters. No shim, no operator, no runtime class manager. I just have to set one extra annotation to the pod.

Only problem is that most k8s distros ship with runc. So there is no out of the box experiance yet, but it is a super efficient setup. Your approach seems more managed/enterprise ready, but also a more complicated. I don't want to be rude, I just want to get what additional value I would get from this since there a so many small differences in the WASM runtime world and I'm not super familiar with most of them

Authentik has completely messed up their implementation of the oauth client credentials grant. It is not fixable without breaking changes and does not work with many tools using the cc grant.

After seeing this they were completely off the table for me.

https://github.com/goauthentik/authentik/issues/6139

Okay, let's think this a little further:

I now have the possibility to open PRs and comment on them for a repo that is hosted on another instance. I still have to deal with user permission. Just because others can interact with my GitLab instance and repos I don't necessary want them to see everything. So user permissions is still a thing.

It would just have the time of creating an external user on my instance (or paying premium for them). Buth this could also be archived via OIDC logins of specific allowed accounts.

Am I missing the advantages here?