jacobsenscott

Classifying bugs as security bugs is just theater - and any company or organization that tries to classify bugs that way is immature and hasn't put any thought into it.

First of all "security" is undefined. Second, nearly every bug can be be exploited in a malicious way, but that way is usually not easy to find. So should every bug be classified as a security bug?

Or should only bugs where a person can think of a way on the spot during triage to exploit that bug as a security bug? In that case only a small subset of your "security" bugs are classified as such.

It is meaningless in all cases.

I haven't used htmx, but I've given turbo a fair shake. I've only worked on server side rendered apps for my whole career, and they are generally they way to go. But just like react, or anything else, you throw enough engineers at it and it becomes a mess. But also you'll only find a handful of engineers who understand it compared to react, so that makes it worse. I think the bottom line is creating web UI is just as unsolved today as it was 20+ years ago, and nobody can make any headway - it suggests the fundamentals are totally wrong - after all - this isn't what http and html were even built for.

Given sufficient time and money (20+ years, and billions (trillions?) of dollars - which is what we've thrown at web apps) you could build GUI apps using the IRC protocol, but it will never work well.

LLM generated code probably tips the scales toward using react though. You can have the bots churn through all that boiler plate, it won't be any worse than what human react devs write, and keep the bots away from your mission critical code because it isn't all munged together like in a SSR app.

AI can't pay taxes - but there's a fairly short list of names of people who should be paying taxes to offset the costs of AI.

Yeah - they don't work well at all. And work from home is definitely incompatible with roombas. Those things are loud and run for a long time. Both ours are in the storage room collecting dust.

Whenever I try and use a "state of the art" LLM to generate code it takes longer to get a worse result than if I just wrote the code myself from the start. That's the experience of every good dev I know. So that's my benchmark. AI benchmarks are BS marketing gimmicks designed to give the appearance of progress - there are tremendous perverse financial incentives.

This will never change because you can only use an LLM to generate code (or any other type of output) you already know how to produce and are expert at - because you can never trust the output.

> here's no other way to do it besides getting Claude to recreate it from a screenshot

And

> I'm an engineering manager

I can't tell if this is an intentional or unintentional satire of the current state of AI mandates from management.

Some guy smacks the kid with a light left hook at about 1:14.

The agent stuff is BS for the pointy hairs. This seems to address real problems I've had with PG though.

Well, my point is AI won't produce a better commit message than just reading the code. So either write a good commit message or don't write a message at all. AI just produces step by step descriptions that are easily gleaned by skimming the code. In your case it would say

* "Add perl to print the string anyone gan zea tne gode" (I'm impressed gemini got that close tbh)

A human would write:

"Wrote obfuscated perl to see if anyone actually reads the PRs. If they don't my next PR will include an obfuscated shell injection script."

Yeah - if these are better than your current commit messages, just don't write commit messages. Anyone can read the code.

Also don't use cron full stop. Build (or use an off the shelf) scheduler in your app that's more sophisticated, has access to data and client preferences, etc.

Largely mitigated by twist lock sockets.

Wayland works great for me. I use a rolling update distribution so everything is the latest version and I only use Firefox, a terminal, and emacs. Debian tends to be pretty far behind.

This won't work - npm.* npmjs.* npmjs-help.* npm-help.* node.* js.* npmpackage.*. The list is endless.

You can't protect against people clicking links in emails in this way. You might say `npmjs-help.ph` is a phishy domain, but npmjs.help is a phishy domain and people clicked it anyway.

This phishing email is full of red flags. Here are example red flags from that email:

- Update your 2FA credentials

What does that even mean? That's not something that can be updated - that's kind of the point of 2FA.

- It's been over 12 months since you last 2FA update

Again - meaningless nonsense. There's no such thing as a 2FA update. Maybe the recipient was thinking "password update" - but updating passwords regularly is also bad practice.

- "Kindly ask ..."

It would be very unusual to write like that in a formal security notification.

- "your credentials will be temporarily locked ..."

What does "temporarily locked" mean? That's not a thing. Also creating a sense of urgency is a classic phishing technique and a red flag.

- A link to change your credentials

A legit security email should never contains a link to change your credentials.

- It comes from a weird domain - .help

Any nonstandard domain is a red flag.

I don't use NPM, and if this actually looks like an email NPM would send, NPM has serious problems. However security ignorant companies do send emails like this. That's why the second layer of defense if you receive an email like this and think it might be real is to just log directly into (in this case) NPM and update your account settings without clicking links in the email.

NEVER EVER EVER click links in any kind of security alert email.

I don't blame the people who fell for this, but it is also concerning that there's such limited security awareness/training among people with publish access to such widely used packages.

Remember the pre package manager days was ossified, archaic, insecure installations because self managing dependencies is hard, and people didn't keep them up to date. You need to get your deps from somewhere, so in the pre-package manager days you still just downloaded it from somewhere - a vendor's web site, or sourceforge, or whatever, and probably didn't audit it, and hoped it was secure. It's still work to keep things up to date and audited, but less work at least.

I've only used circleci and github actions for this, but in both cases precompiled rubies are available. On circleci you run your tests on a ruby docker image with the right version of ruby installed. On Github Actions I use https://github.com/ruby/setup-ruby, which installs an compiled ruby in a second or two, and also properly caches your gems. I think if someone's CI environment is building ruby from source they are doing it wrong.

Uh, we've been doing data processing for nearly 80 years, and watching netflix for nearly 20 years. Suddenly we need to tile the earth with data centers, build power plants, burn all the fuels we can, and will "need to get to fusion" (per Sam) to run AGI. He also said "if we need to burn a little more gas to get there, that's fine". We'll never get to fusion or AGI, but we will destroy the earth to put a few more dollars in the pockets of the 0.01%.

You don't see the difference, or are you willfully ignorant?

I don't think you can. I also don't know why people care so much about it - I work full time with ruby and compiling a new version, which maybe takes 10 minutes, a couple times a year is no big deal.

Just using `bundle exec` should handle that - that's what bundler is for.

One thing I love about Ruby is it never devolved into ?VM hell like Python did. Yes, there are a bunch of ruby version managers, but there's only one bundler no matter how you get get ruby installed. I like some ideas here, but I'm also afraid this could be step one toward that python nightmare.

> catch bugs that even claude code misses on our Github PRs

Is that good? I assume it just catches a different 10% of the bugs.

You overestimate the vigilance of other professions. A Dr or Lawyer needs to screw up really badly, many times, before anything happens. They all go to the same country clubs.

I'm not joking. Malpractice happens all the time. You being incensed is not the deterrent you think it is.

Because the information people dump into their "ai therapist" is holy grail data for advertisers.

It's already happening, a lot. I don't think anyone is claiming an llm is a therapist, but people use chatgpt for therapy every day. As far as I know no LLM company is taking any steps to prevent this - but they could, and should be forced to. It must be a goldmine of personal information.

I can't imagine some therapists, especially remote only, aren't already just acting as a human interface to chatgtp as well.

What if all your code is already written to use a filesystem, and you want to change the backing store from nfs to object store? Or what if you want to abstract away the specific blob store?

It's unlikely my high school transcript exists anywhere. If it does it is in the basement of some government building in rural Wisconsin. So - 4.0 - straight A's, captain of the linux security team.

We've seen this story many times before. Remember UML and Rational Rose, waterfall, big up front design, low/no code services etc. In every case the premise is "pay a few 'big brains' to write the requirements in some 'higher level language' and tools/low skill and low pay engineers can automatically generate the code."

It turns out, to describe a system in enough detail to implement the system, you need to use a programming language. For the system to be performant and secure you need well educated high skill engineers. LLMs aren't going to change that.

Anyway, this is tacitly declaring LLM bankruptcy - the LLM can't understand what to do by reading the most precise specification, the code, so we're going to provide less specific instructions and it will do better?

Mindlessly coding is stuff like gluing together libraries, components, and services that do the actual work, building simple CRUD UIs, copying AWS configurations to terraform, etc.