mad_vill

Oh wow. Being pretty new to meta and seeing the anthropic announcement I was thinking to myself “wow that sounds a lot like sapling”.

I guess that is the case.

Happy to see this trending, I probably share this in my company's slack once a month.

For all the other comments, parent is probably talking about forward proxies and to their point many forward/enterprise proxies have configurations which cause websockets to break and it is a pain to debug this if you have many enterprise customers.

There are many cases where users are behind a forward proxy for security/compliance reasons. Most applications need to support these types of users.

cluster-api in a nutshell

Same. Typically call it “hung” but maybe stating certmanager is on strike will get the point across better.

But sigh does it really get to the state of the kubernetes ecosystem. All these projects need to be operated, can’t just set it and forget it.

Curious if oxide is considering a 1-2U product.

Feel like there is a larger potential customer base there but it also seems like they would lose the edge they built by owning the full rack. (I.e. integrating with customer TORs and network fabric is a nightmare.)

“Automatic recovery”

That’s a joke.

I am really curious if part of the reason why oxide is leaning into racksize is that joyent has scared them from attempting a 1U/2U solution.

they did more than just CICD but I see your point.

I feel like the next generation of this type of company is smaller consultancies that have awesome developers that build customer tooling on the side. But the main revenue driver is consultancy.

Also it really feels like all the air has been let out of the docker/kubernetes/cloud-native balloon that was so popular in the late 2010s.

oh wow ... can't wait to waste a bunch of time trying to get this running in hyper-v.

Sounds more like a kubernetes problem than a dns problem.

I hate coredns. Everything running inside of a kubernetes cluster should just be querying the kubernetes endpoints api for these IPs directly and using the node dnsservers for external hosts.

Bingo. Design for incompetence. There are few codebases in this world that don't need incompetent people to contribute to them. (This is typically driven by business incentives)

If you get to work on one of those codebases ... good for you. The rest of us are just trying to gatekeep piles of shit from getting in while being pushed by management to open the flood gates.

iirc azure stack hci is only 1U and 2U configurations, not a full 32U rack.

If you want to get an HA k3s cluster going quickly on your cloud-provider of choice: https://github.com/cluster-api-provider-k3s/cluster-api-k3s

Well I notice that alias from the propolis repo :).

Thanks for the heads up. Will probably ditch this effort.

Really want to play around with some of the oxide stuffs but it’s hard with illumos not supporting nested virt.

It’s funny this article popped up. I have been trying to get the oxide vmm working on freebsd in my spare time.

Too bad I don’t know nearly enough about rust, bhyve, openbsd or illumos to ever come close to get this working.

Looks really cool!

well put. it was already a headache trying to unblock devs that went down terrible stack overflow copy/paste rabbit holes ... gpt4 only 10x that mess.

The verge is doing a great job approaching the new AI tools from a non-software engineer technically technically inclined knowledge worker POV.

makes sense ... karpathy is a pragmatic thinker. openai seems like a pragmatic company.

Can't wait to see want gets built.

The lack of detailed documentation for grpc is pretty crazy considering how many people seem to be using it.

So many hours wasted investigating fringe http2 characteristics causing odd bugs on the platform.

This is touching on something I have been thinking a lot about as I progress in my career.

The thing good and bad code have in common is the fact that it needs to updated. Either for bugs or changing business need.

So focusing on the operational side becomes much more important. Code is the trivial part. Creating systems that can be modified reliably is the hard part.

I rather have ownership over a "poorly" coded service with proper ci/cd, integration tests, monitoring, and a team that reasons about and follows strong operational processes, rather than some beautiful code in a vacuum.

What about companies that sell you on "If you come on, you will do it", and then you get there and it turns out you won't be doing "it" at all?

the issues I see with kubernetes ingress are more related to an ingress pod going down than the upstream.

I thought they shutdown their public api.

I would be pretty skeptical of anything that is owned by the devdiv division (github, dotnet, etc). It seems like they are still looking for ways to replace the revenue they lost from the classic VS model.

As for anything in the Azure org, I wouldn't be too worriedT They just want to wrap a managed service around an OSS project and call it "contributing to the community". It seems like there was some OSS innovation coming in from the deis acquisition, but years later all msft got from them was the helm dumpster fire, and I believe the founder just left to go to Digital Ocean.

The Kinvolk acquisition is interesting also, but I have a feeling that it will pan out the same way.

uw madison?

Who needs this when you have the broken "blame" in azure devops/repos?