bmurphy1976

It cheaper to create one-off products. Creating a sustainable business though? Charging money for the product or service? Actually getting enough income to thrive? I think that also just got a lot harder. Sure, you quit and you undermined BigCo with your open source release, but somebody with even less to lose will now undermine you.

I think that's so true and it was one of the keys to success of the project. I contributed the very first simplistic implementation of referencing linked containers by name. I never would have bothered if the project was written in C or C++ (I'm more than capable, I just don't enjoy torturing myself). Go made it MUCH easier for a fly-by-night contributor such as myself to join the party.

I don't think there's any robust method. I lurk HN, subscribe to security lists, run our code through scanning tools regularly. All options suck, all options have gaps, and all options mean you have to stay on the hamster wheel.

Boss is part of a company that's over 50 years old, has half a billion dollars in revenue and 3000 employees. The op is a small shop just trying to get started. They aren't even in the same galaxy.

The farther you go, the faster you need to go to get enough time dilation to make the trip worthwhile. The faster you go, the more the shielding matters. It still applies!

Sounds like a good candidate for shielding an inter-galactic colony ship.

Do you think Chinese manufactures can't clone the hardware? Do you think they can't provide a premium product/experience? They most certainly can and do.

Just be different. Just create a brand. Oh if only it were that easy!

I want more stuff like this. The era 20 years ago (e.g. Enlightenment) was way more fun than the bland monotonic design we have these days. If you like bland modern design, great, that should be an option as well, but we should still have good variety.

You need the right sized coin. A nickel works best. Anything else doesn't fit right and tears up the plastic or slips out.

I have a bunch of Aqara sensors and they stay connected most of the time, but if there's an extended power outage, usually about 1/3rd of them won't reconnect. It's annoying having to hunt them all down and reboot them. Sometimes the button won't work either and I have to fuss with the battery to get them situated.

I had issues with my garage fridge last year. Took a while to figure out, but there was a small box at the bottom that was occasionally keeping the door from closing completely. The Zigbee sensor was great tracking what happened when and helping me narrow down the cause.

Google isn't much better. I have them all over the house. Ask a question to the living room speaker, skips that, skips the one in the kitchen, answers from the one in the bathroom upstairs or one in the basement. Then you get a notification later asking "was this the right device?" which is doubly infuriating since responding to that never actually improves anything.

Yes, that's my point. Fridges don't need all this functionality built into them.

Is it really an Elephant in the Room situation? Are there upvoted ticket/issues or community threads asking for it? I don't really know, it's an honest question.

As somebody with a pretty extensive Home Assistant based home automation system AND kids, I've never once felt the need for this. I can certainly see the utility of it, but Home Assistant is already complicated enough. I'd prefer effort be spent improving the UX, simplifying the system, improving reliability and adding more (optional) integrations.

To be fair, the MCPs of 8 months ago are not the MCPs of today. You had to mess around with headers and .env files and local npm proxies and other bullshit only cli jockeys would tolerate. The MCPs of today are fully remote, stateless, oauth enabled, and integrated much more nicely into the the user experience. Click a button and it works.

I do agree, the "MCPs are dead" narrative was overblown, but there were legit reasons we weren't ready to go all in on them back then.

It's not just the screen. Microchips and sloppy firmware are everywhere.

My 2015 Jeep Cherokee had a freakout one day: the power steering stopped working mid-drive, on the highway. I was 50 minutes from my house, had to turn around and drive back home (an exhausting exercise given that modern cars are not built to function without power steering). I got to the dealer, parked in the lot, turned the car off, wait 30 seconds, turn it back on, everything worked fine.

That never happened again, but once is enough to put somebody in a dangerous-to-life situation.

It's not just the infotainment system we should be worrying about. Most modern cars are now distributed computer systems.

My idea of a smart fridge: a fridge with Zigbee Temp/Humidity sensor connected to my Home Assistant automation system that alerts me if things get out of whack.

My idea of a dumb fridge: a fridge that updates firmware, bricks itself, and lets all my food spoil.

Get a Unifi system. It's built in. Works great!

You have to start somewhere.

Interesting. Because I have a much harder time typing on my Pixel. In fact, I hate it. I wish I had a blackberry.

When I use iOS devices, it feels better but I don't use them enough to have used them in anger. Ok, well, yes they have made me angry but for other reasons than the keyboard hence why I'm on Android lol.

I've been running Hermes inside a remote docker container connected to Slack bound to a Codex account. It's actually pretty great, I prefer this approach for a lot of things. Because it's in a Docker container I have 100% control over the configuration. It may do some crazy stuff, but I know it's not going to start exfiltrating my AWS SSO tokens or SSH keys from my laptop.

I'm frequently listening to music or a video in the background. Join a zoom call early because I don't want to be late, instant AM radio. You can argue I shouldn't do this, I'll argue that it shouldn't matter and should just work. It's 2026, not 1926.

That's not true at all of the corporate world. If your team is mass producing slop and you don't have processes in place to get it under control, you've got a big problem on your hand.

If any engineer sent me a 20,000 line refactor I'd immediately reject it and tell them to go back and start making changes incrementally at minimum. More likely I'd force them to have a whole design discussion with the team to make sure that what they are doing even makes sense.

What happens if they push out slop that significantly increases your infrastructure costs? What happens if they push out slop that significantly increases the number of bugs or outages? What happens if they push out slop that has no observational metrics, dashboards, or tooling?

In every case you push back on the team and make them fix their shit. I don't care if they are using LLMs or not. They are responsible for their work being sufficient quality. If they aren't meeting those standards, then they need to step it up.

How do you handle them? I'm not facing this problem as the team I work with is very senior and have good taste and discipline. But I can imagine it will be a problem at some point, and I frequently have to personally tell Claude to rewrite it's vomit in English. That's probably step one for people submitting poorly written PRs, reject them until they are written clearly and concisely. And if they are too big, also rejecting them and telling them to go back to the drawing board and submit smaller more focused change. But I'm not int his position so I'm taking an educated guess.

Maybe. I don't have enough context, but maybe that's what he wanted to do? Whatever you may think about it, I'm pretty convinced Ozzy wanted to go out with a big concert. Nobody had to push him to do it.

~$4000 USD each on Amazon, $175 for the cable.

Maybe. It's been what I wished Java was since the beginning, personally.

I'm not sure I want another layer of indirection personally, and I'm guessing an updated Claude model will reign this in at some point. I have however created a skill I call "deslop" and I invoke it to clean up Claude output when it goes off the rails. Here's the skill if anybody is curious:

https://gist.github.com/bmurphy1976/47ad81a842ab4b1628ef5974...

A small preview:

    *Meta commentary.* Sentences about the document, the diagram, the reader, or the
    writing itself ("the split across this diagram is the whole point", "a reader who
    assumes X will be wrong", "as we'll see below"). Delete the frame and keep the fact
    it was wrapped around. If there is no fact underneath, delete the sentence.

This doesn't change the fact that those soft skills are necessary to use LLMs effectively. You need a mixture of hard and soft skills.

Engineers who have avoided learning the soft skills are going to have a harder time adjusting.

Tracing what it actually did. Who would have thought that's a good idea, instead of trying to obfuscate everything.