smetj

Works for me!

I'm just another off-the-shelf engineer now

You're wrong there. You are capable of judging the outcome of the llm.

But I don't know what to think about the long-term.

Don't you think it all has taken long enough. When I look back at the beginning of my career and compare what we do now ... I cannot shake the feeling we're essentially still solving he same problems and we have accepted that as being normal. Complexity skyrocketed, (abstraction) layers got added but the needle didn't move exponentially together with that. I think the IT industry as a whole gets what it deserves, thinking that we would remain the maze masters of the mazes we create.

Maybe I should consider transforming my woodworking hobby into a profession...

I'm looking for 8 (affordable) oak panel doors with the exact same measurements as my current doors so I can replace them. That shouldn't be too hard to find you'd think right?

Ceci n'est pas une pipe.

I guess the people not complaining here are the ones who do not immediately upgrade production to latest non-security releases?

That looks great! Will give it a spin during my daily work. Thanks for making and sharing it.

Depends on what you are monitoring but let's assume an API endpoint. Collect and monitor the RED metrics with detailed dimensions in combination with blackbox monitoring simulating client transactions as realistic possible and alert only on those 2 types.

When that happens, fire off a battery of diagnostic checks which you have collected over time to pinpoint the cause.

What if the diagnostics checks don't reveal the issue? There is still value since you know these are not the reason so no time is wasted re-evaluating them. Where to get these diagnostic checks from? Well, what's the first thing responding engineers do? Open the CLI and troubleshoot. Those are your diagnostic checks. Collect, automate, capture the domain specific knowlegde and democratize it.

Some years ago I owned a Mercedes CLA which had Android auto controlled using the rotating joystick with push down to select. The experience was perfect. It was fast, could be handled without any distraction, never misbehaved and never detoriated over time. Now I drive a car with touchscreen ... it's bullshit but I guess it looks fancier.

I run Linux. If there's something I'm missing out because of that, then I accept it rather than going through this hell.

red tape, regulations, corruption, low pay, inflated prices, a gamed system. Although the topic is unrelated, I came across this the other day ... makes one think https://youtu.be/JTEJH-tKv9Q?t=910

Generally speaking, the value of these contributions was determined by "proof of work". Time and effort are precious to a human hence its a somewhat self-regulating system preventing huge amounts of low quality contributions being generated. This is now gone. Isn't that an interesting problem to fix?

Here's mine: https://smetj.net/

Beautiful! Nice work.

Be it as it may, its aesthetics are so distinct it isn't for everybody. Also a big part of the target audience expecting to buy an utility vehicle have cheaper, proven and more practical alternatives. I guess the fact its not road legal in the EU doesn't help either whilst other Tesla models are quite popular there.

Its not Github Actions' fault but the horrors people create in it, all under the pretense that automation is simply about wrapping a GitHub Action around something. Learn to create a script in Python or similar and put all logic there so you can execute it locally and can port it to the next CI system when a new CTO arrives.

Its simple. If you require specific software which only runs on Windows, then you cannot use Linux. If that's not the case, the Linux desktop these days is entirely capable of helping you achieve your goals.

Well ... IMO this is literally replacing (entry-level) engineers, but lets agree to disagree on that. Be it as it may ... task automation is also "a product" then not? 5 years ago, this wasn't possible. Now it is, so extrapolate that to the future ...

ps: If you can guarantee the Powerball lottery continues forever, I can give you a guaranteed winning combination.

At work, I was involved in a project where a large number of individual tasks defined as declarative code had to be translated into JS based equivalents. Due to the unpredictability of each task we would have to do this pretty much manually, one by one. I would estimate at minimum 2 months of grunt work for 4 entry level engineers. Thanks to coding agents and LLMs we were able to achieve this task in a week. Quality of the end result is top notch.

If that's not a product ... then I don't know what it is.

- What was the state of AI/LLMs 5 years ago compared to now? There was nothing.

- What is the current state of AI/LLMs? I can already achieve the above.

- What will that look like 5 years down the road?

I you haven't experienced first-hand a specific task before and after AI/LLMs, I think its indeed difficult to get insight into that last question. Keep in mind that progress is probably exponential, not linear.

it is happening, just not everywhere at the same time at once

This has not been my experience at all ... I run KDE + Fedora or Ubuntu on laptops for years as my daily driver doing professional work. Its an absolute joy to work with and stable. If there's a hickup then its because some unrelated process is consuming all memory or hogging all CPUs (Slack, Teams I'm looking at you) which would crash any desktop.

Somehow, somewhere there is a pleasant balance between DRY and non-DRY which is different for everybody. God forbid having a colleague who sees a thing repeating and slaps an abstraction over it at whatever cost because DRY!

Exactly! Linkportals and webrings ...

Perl became popular because there was not really an alternative on par with its capabilities and because it was bundled with every Linux distro. But then Python came along and picked up momentum and because of that, people realized Perl's syntax is actually not very intuitive to read and understand compared to Python.

What is the essence of the complaint here?

As said, that I often cannot relate the managed application's documentation to the Helm chart's interface?

Reason for it can vary ... poor Helm chart documentation, poor Helm chart design, Helm chart not in sync with application releases, ... The consequence is that I often need to grep through its templates and logic to figure out how to poke the chart's interface to achieve what I want. I don't think that's reasonable to say that's part of the end-user experience.

PS: I have no gripes with YAML

Came here to feel the temperature of the comments, and unsurprisingly, most folks seem to have plenty of gripes with Helm.

A Helm chart is often a poorly documented abstraction layer which often makes it impossible to relate back the managed application's original documentation to the Helm chart's "interface". The number of times I had to grep through the templates to figure out how to access a specific setting ...

Beyond stunning, worth its asking price imo.

Yes, I deliberately left that out for personal reasons. With a little sleuthing you should be able to figure out the brand.

Understood ... thanks for clarifying ... I'm genuinely intrigued. You're right that image is generated by a generative model, however my humble blog content .... I do write myself. "Don't judge a book by its cover!" ¯\_(ツ)_/¯

Could you elaborate please? Genuine question.

Shameless plug. My experience with emergency lane keeping systems in my car and reporting it to my dealership: https://www.smetj.net/its-for-your-own-safety.html

Kubernetes has all the capabilities to address the needs of pretty much every architecture/design out there. You only need one architecture/design for your particular use case. Nonetheless, you will have to cary all that weight with you, although you will never use it.