The number of times I’ve had to defend someone else’s customers let alone my own is exhausting.

And that dynamic is only allowed within close circles.

I’ve found once “the decision” is made, the bigger the subsequent meeting, protests are often swept under the rug.

On most occasions the worst part is that folks intentionally withhold information to get their way. And thats real hard to compete against without making an ass out of yourself, or losing the trust of others.

This is why core principals matter so much.

I dont want a different system handling edits reviews and merges.

I just want CD to send my docs from git to a system that can properly host / give me the Doc-related features I need.

If you are guessing at the data anyway, what's the difference?

Why set up an entire speculative execution engine / runtime snapshot rollback framework when it sounds like adding heuristic decision caching would solve this problem?

I set up a wireguard server on a publicly accessible VPS.

The neat part about using "lscr.io/linuxserver/wireguard:latest"

is that it allows my to codify the number of clients I need. This includes both endpoints and source devices.

The second thing I did, was separate out the "networking" bits from the "userspace" bits, meaning it doesn't matter what port the service is running on. The client can hit it.

Taking that one step further, I just combined the above with haproxy and set my application ports there. This means I can hit haproxy on "someport" inside the VPN and it'll forward to whatever service I've got configured on that "client" that haproxy can see on it's LAN.

Works great, currently running a simple web page off the whole thing, where you connect to VPS and it tunnels the actual HTTP connection into kubernetes in my house.

I was thinking about writing this all up one day, but there's some cleanup to be done. Oh well.

This isn’t exclusive to technology, but I see this all the time at my large organization. As a grump, I have to pick which shitstorm to care about and spend my time chipping away at, which ends up being really draining.

To help with this, we began focusing a team of great folks with shared values, leaning in on modern operations/SRE best practices.

We started to have some real success with SDLC for our operations workflows.

That’s when management changed our teams direction. Good times.

For the second point, ok this makes a little bit more sense, I've heard of Codespaces or OpenShift Dev Spaces but I guess I still question the value of additional complexity on top of the container (a simple dockerfile in my mind) your vscode instance's terminal is running in.

Thanks for the info.

Can I just ask, what value does this spec provide that a simple docker image containing the necessary tools does not already provide?

Why do we need another layer on top? What am I missing?

Sometimes, functions may call other functions in the same code file.

This required that functions be declared before they are referenced so C knew it existed.

You can also see this on lines 84-92.

“template”

multiline string values back into valid yaml for proper indenting.

Works great, the issue is explaining to anybody why it was necessary, they understand it works but plead for a better way.

It’s one of those clever solutions that seems overcomplicated until you try to replace it and realize it’s actually quite elegant.

I did something similar with Kubernetes, work has some OSE clusters that will generate DNS for you, it works great and the devs love using it. It’s a little bespoke but its simple and gets a lot of attention.

Plus since the namespaces preexist the workloads, we spin them up for the entire branch lifetime (times out after n days). Makes everyones jobs a lot easier.

Anything that helps shift lifecycle requirements and testing left has huge impact on DX.

I’ve been working on the same thing for a few months now.

Not only is it more customizable / less complicated than helm / other solutions, but GNU gettext is almost 30?! years old at this point, and environment variables are probably realistically double that age. They aint going anywhere anytime soon.

Plus I feel that more complex logic removes value from the configs we are building, and so am not interested in many other tools.

If the door is not closed and you shift into drive, you also get a very loud annoying beep and visuals.

Not only that, the brakes engage and the car LOCKS ITSELF IN PARK AND DOES NOT LET YOU DRIVE EVEN THOUGH THE SHIFTER IS IN ‘D’!!!

I pray the door sensor doesnt fail while driving on the highway, or theres never a situation that arises where the car needs to be driven regardless of the door being open.

On top of that, the door locks /trunk locks act very strange while the engine is running /driver door is open. Still dont have that figured out.

I’ve suggested that we don’t purchase another VW.

Contrast this with the contract* K8 tries to sell you, which is "describe the intent and we'll figure it out for you" and you'll realize the cloud providers bunged up this whole thing.

That's not to say K8 is perfect, but if you think for even a second that wiring up resources outside your kubernetes cluster will be lower-friction, kubernetes is falling short of it's goals.

Basically, build a computer from literal spare ICs. Every video is nearly a chapter out of a CE / EE encyclopedia. Worth every second watching.

https://eater.net/

For low traffic stuff, might seem OK, but no redundancy for a service that users pay for seems irresponsible, however Gitea might just be for them to track internal stuff, so maybe a little less so.

This is not one of those times. I agree there's a chance there are better word choices or feedback for some commands, but overall once you 'learn the language' it really is a lean, mean, well designed piece of software.

Folks that complain about the UI/UX don't realize it wasn't designed for less technical folks. It was designed for the folks who needed it.

It's success must at least partially prove that the UI/UX is not 1/10. Any real engineer will tell you, there are times where they wish they could do something better but the requirements and constraints left them making tough decisions, and that doesn't mean they aren't proud of their work.

It's success is also partially due to the fact that it is lean and mean, which allows it to be applicable to nearly all software projects of any flavor. So I don't understand why folks argue it could have been done better. If it was 'better', in my view it wouldn't have been successful. The success was driven by it's succinct design and Linus' take it or leave it attitude.

Technically accurate studio monitors don't sound as pleasing to the ear as good well tuned speakers. But they are exceptional at the job they were designed for. This is like that.

But in the general case I find that if commits are not themselves concise and simple changes, they often should be broken up so that the moving pieces can be better tracked when looking back at the history.

In my view, the reason Docker has all the hype is because I can look at a Dockerfile, and know what's up. In seconds. Sometimes in milliseconds.

It's a user experience thing. Yes, Nix is better for 'technical people that spent the time learning the tool', but Dockerfiles rely almost entirely on existing System knowledge.

Yes, Nix is 'better', but the fact is Docker is 'good enough' and also 'stupid simple' to get started.

Also Docker-Compose, I don't know why people hate on YAML. But it takes that same KISS attitude to build complex systems that can also be used as sanity checks for migrating to things like kubernetes.

Being able to spin up a complex full stack app with one command and a compose file that doesn't take any brain cells to read is worth it's weight in gold.

This is like the 'general case tool' vs 'DSL' debate. If it's easy to use, people will use it.