I remember them from way back on Windows 98 and no one seems to care to hide them (?).

Once you get to that point, you can copy paste your issue into an LLM and get a fix close to the PR you would open, but so can the maintainers, so what's the point of opening a PR and adding more friction?

In fact discussing the issue is way more productive since it's just about the actual issue, root cause and tradeoffs without the debates on implementation details and nitpicks.

If you want to contribute major features, you need to befriend, discuss and agree with the maintainers, I don't think drive-by PRs ever worked for this.

It definitely doesn't inspire confidence in the project taking security seriously.

(Also the "write-up" is almost surely a "Claude-up", though it appears generated by someone external to the project).

The LLMs don't need to be perfect, they just need to be good enough so that the cost of fixing their code is lower than the communication overhead and the 'lost in translation' overhead from delegating tasks to mediocre engineers.

If the text is full of punchy three word phrases or nonsense GenAI images then that's an obvious sign. But so is if the other person has some revolutionary project with great results but they can't really explain why their solution works where presumably many failed in the past (or it's a word salad, or some lengthy writing that doesn't show any signs of getting you to an "aha, that's some great insight" moment).

A good sign is also if the author had something interesting going before 2022, and they didn't fall into the earliest low quality LLM waves. Unfortunately some genuinely talented people have started using LLMs to turbocharge their output while leaving some quality on the table nowadays, so I don't really know. I'm becoming a lot more sceptical of the Internet, to be honest.

Reading your comment, it looks like you work for a pretty nice company that takes those things seriously. I envy you!

My concern was that for companies unlike yours that don't have well established engineering practices, it _feels_ that with AI you can go much faster and in fact it's a great excuse to dismantle any remaining practices. But, in reality they either doing busywork or building the wrong thing. My guess is that those are going to learn that this is a bad idea in the future, when they already have a mess to deal with.

To put what I mean into perspective... if you browse OP's profile you can find absolutely gigantic PRs like https://github.com/leynos/weaver/pull/76. I can not review any PR like that in good faith, period.

On the other side perhaps your company, like most, does not know how to measure overengineering, cognitive complexity, lack of understanding, balancing speed/quality, morale, etc. but they surely suffer the effects of it.

I suspect that unless we get fully automated engineering / AGI soon, companies that value engineers with good taste will thrive, while those that double down into "ticket factory" mode will stagnate.

Many of those tools are overpowered unless you have a very complex project that many people depend on.

The AI tools will catch the most obvious issues, but will not help you with the most important aspects (e.g. whether you project is useful, or the UX is good).

In fact, having this complexity from the start may kneecap you (the "code is a liability" cliché).

You may be "shipping a lot of PRs" and "implementing solid engineering practices", but how do you know if that is getting closer to what you value?

How do you know that this is not actually slowing your down?

To start, it is based on a single machine check. It has little context, but if this was a common problem, I'd expect more data points.

The MC happened 8 hours after the freeze. It's not unusual that a hardware/kernel failure cascades to multiple subsystems so I'd be sceptical that the MC has a direct relationship to the root cause of the freeze.

(Part 13) Why does it quote an Engineering Change Notice rather than a consolidated spec?

(Part 11) LaneErrStatus=0xFFFFFFFF is 32 bits. As far as I know, PCIe x32 is very rare.

(Part 8.4) How is it surprising MMIO isn't included in memory dumps?

(Part 4) How is the definition of a MCE relevant here?

The "friction" is that Wayland developers don't want a sandboxed application with access to the Wayland socket to pwn your machine.

Trying to isolate applications within the same UNIX user is essentially unfixable since there's ptrace, LD_PRELOAD, /proc/$pid, .bashrc drop-ins, etc.

The author must know about all of this, as it's mentioned in the LD_PRELOAD note in the end. In my view, the model he proposes is security by obscurity (putting hurdles on top of a fundamentally insecure system).

In the long term, once the damage from vibecoding is better understood (for customer impact and team morale), there's an incentive to push them out, both from the leadership and the individuals side.

Knowing those patterns is very helpful as a way to think about design problems, as long as you have the common sense to realize applying the pattern "by the book" is often overkill and you can just take some ideas out of it.

That article conflates as "Pure engineering" both reducing a software system to a small set of cohesive concepts, and architecture astronauts, when those are polar opposites.

I think that this may eventually become better now that there isn't so much dumb money around (no ZIRP) and with AI assistants taking on some low-effort work (enabling companies to lay off incompetent engineers). But it will take many years for companies to adapt and the transition won't be pretty.

So, you want to avoid both being disliked, but also being liked - because this puts you in novel situations you fear lead to an even bigger failure down the road.

I don't think the fundamental dynamics change by seniority, just that after some level there may simply be a smaller pool.

From the interviewers perspective, it makes sense to reject a candidate if they see any possibility it could be a flop. A bad hire is going to frustrate the team and look bad to the company, missing the best candidate is just going to result in hiring their next best pick.

> As someone just starting out, the general feeling among my peers is that I must bend to the interviewer's whims, any resistance or pushback will get you rejected.

I guess this is very context dependent but I can also see "bending to the interviewer's whims" backfiring if they see you're just trying to flatter them. I could see some interviewers valuing that you can explain your point if it's framed in a way that shows you are both observant and easy to work with. If it's framed as a more aggressive kind of pushback, yes that's going to get you rejected.

But yeah, I can also see that if you're willing to take any offer at any company as a junior just to get your feet into the industry most interviewers may not be specially smart and resisting is likely to go wrong.

- Install as little software as possible, use websites if possible.

- Keep important stuff (especially cryptocurrency) on a separate device.

- If you are working on a project that pulls 100s of dependencies from a package registry, put that project on a VM or container.