ohgr

I swear at the junior programmers less.

To be fair the guys I get are pretty good and actually learn. The model doesn't. I have to have the same arguments over and over again with the model. Then I have to retain what arguments I had last time. Then when they update the model it comes up with new stupid things I have to argue with it on.

Net loss for me. I have no idea how people are finding these things productive unless they really don't know or care what garbage comes out.

Well that's the hard bit I really want help with because it takes time.

I can do the rest myself because I'm not a dribbling moron.

Yep. My usual sort of conversation with an LLM is MUCH worse than a junior developer...

Write me a parser in R for nginx logs for kubernetes that loads a log file into a tibble.

Fucks sake not normal nginx logs. nginx-ingress.

Use tidyverse. Why are you using base R? No one does that any more.

Why the hell are you writing a regex? It doesn't handle square brackets and the format you're using is wrong. Use the function read_log instead.

No don't write a function called read_log. Use the one from readr you drunk ass piece of shit.

Ok now we're getting somewhere. Now label all the columns by the fields in original nginx format properly.

What the fuck? What have you done! Fuck you I'm going to just do it myself.

... 5 minutes later I did a better job ...

No idea. It’s their out of box microservices set up. I think the only thing we pumped up was the chunks cache to 30Gb.

Not much I agree with in this article. Seems to be based on little operational experience with the product, particular indicated by a couple of major mistakes and assumptions in the article (compacting does happen, didn't read the manual about deployment configurations clearly).

Loki has its idiosyncrasies but they are there for a good reason. Anyone who has sat there waiting hours for a Kibana or Splunk query to run to get some information out will know what I'd referring to. You don't dragnet your entire log stream unless your logs are terrible, which needs to be fixed, or you don't know when something happened, which needs fixing. I watch many people run queries that scan terabytes of data with gay abandon on a regular basis on older platforms and still never get what they need out.

The structured metadata distinction is important because when you do a query against that you are not using an index, just parsed out data. That means explicitly you're not filtering, you're scanning and that is expensive.

If you have a problem with finding things, then it's not the logging engine, it's the logs!

Kibana + ElasticSearch was a mess for us. Was glad to get rid of it. Cost a fortune to run and was time consuming. Loki conversely doesn’t even show up on our costs report (other than the S3 bucket) and requires very little if any maintenance!

Also out of box configuration sinks 1TB/hr quite happily in microservices mode.

We are more likely end up with moon nazis at this rate.

I imagine an Alexa customer would have a net loss financially from the model execution costs if they just sent garbage all day. Doesn’t even need to be clever.

Spend more time and money? Nope. It's on CloudFront + S3 at the moment.

I just shut my entire web site down after 27 years this year. All traffic was AI crawlers. Fuck it!

Well I’m certainly going to be reading it now.

It's terrible and always has been. As featured in Curb Your Enthusiasm (contains swearing so don't play it in the office loud): https://www.youtube.com/watch?v=kTefnhbg0Ig

Times come and go.

Never give any data to anyone based on their current policy, because as demonstrated here, it may change. And then you're fucked.

Word taught me how to spell back in the 90s.

It won't because I never invited one into my home because why the bloody hell would I want a listening device in my house in the first place?

So what you're saying is we need to blast some barges into space and land them on the moon so we have a flat surface for starship to land on?

This is why I drink water. And water with coffee in it.

The government or other parties will come and take your data wherever you are without a moment's notice. There is no defence against that.

The objective should be to make that as hard as possible by not putting it somewhere you make it easy for them to do so without your knowledge or without legal due process.

And that is NOT in some cloud.

We also still do it!

I’ve taken to just carrying a book with me and reading it instead.

It used to be the only way!

I travel a lot in the EU and the Internet is a total shambles. Blocked stuff everywhere. Right down to VPNs not even working.

Yes the office door stop as it was known as at our place. Top book though just faded in utility and no one had the heart to dispose of it because of the good memories.

I have to agree here. I do a lot of written work and thinking still. If I put my “lowest common denominator user” hat on, the iPad seemed like an obvious choice to throw all this at as it has a reasonable “paper” implementation. Cue buying an iPad Pro, Noteful and using the files app to replace reference books and physical notepads.

It just didn’t work. There are so many constraints and it’s not just the software but the fact it has only one screen. I need about 4-5 iPads to be equivalent and that’s not even remotely practical or possible.

This is notably not unique to the iPad. No tablet would be good for this work.

As for the generic computing stuff it’s not even good for consuming content - the screen is too shiny. If you add a keyboard case to it you might as well buy a MacBook Air.

This is how I use my Mac desktop with Rectangle https://rectangleapp.com

That and the apple touchpad to swipe three fingers left and right to switch desktops (and different machines as one desktop is remote desked into a windows box and another terminal+tmux session to a linux box).

None of those things feature in any problem I deal with on a daily basis, whatever language I use.

So for example today I dealt with a synchronization issue. This turned out to not be a code bug but a human misunderstanding of a protocol specification saga, which was not possible to code into a type system of any sort. The day before was a constraint network specification error. In both cases the code was entirely irrelevant to the problem.

Literally all I deal with are human problems.

My point is Rust doesn't help with these at all, however clever you get. It is no different to C, but C will give you a superset of vulnerabilities on top of that.

Fundamentally Rust solves no problems I have. Because the problems that matter are human ones. We are too obsessed with the microscopic problems of programming languages and type systems and not concentrating on making quality software which is far more than just "Rust makes all my problems go away" because it doesn't. It kills a small class of problems which aren't relevant to a lot of domains.

(incidentally the problems above are implemented in a subset of c++)

I suspect you probably don't understand it after that. You think you do.

I thought I understood calculus until I realised I didn't. And that took a bit thwack in the face really. I could use it but I didn't understand it.

Most bugs are way above that level of abstraction and thought.

I’d add that the Rust code and C code will probably have the same number of bugs. The C code will likely have some vulnerabilities on top of those.

Rust doesn’t magically make the vast majority of bugs go away. Most of bugs are entirely portable!

The best way to improve this is to just generate decent useful and actionable logs. Sifting through a trash heap is where the problem is. No magic will suddenly turn that trash into gold.

You have to do this at the inception of the software you’re building rather then strap it on the donkey when something breaks (the usual way).