HN user
You wildcarded any traffic to github.com and thought, "eh, they probably check" and are wondering who is at fault? It's you.
You didn't think through the consequences, and you could learn a bit more about DNS.
Yeah, where are they getting the customers that want the big screen?
Are these people stupid? These product people have lost touch with reality. I'm driving, I want to focus on the road, not a 39 x 6" touch screen.
Yeah, /plan is the only way I can work with them now. Too much "helpful" crap I didn't ask for. Having nightmares of former coworkers who would want to refactor 80% of the code base for a 3 line change. AI doesn't subscribe to "if it ain't broke, don't fix it."
It's situational.
The blame on how the tool was used and whether this was negligence. If I hit someone with my car because I was looking at my phone, it's not the tools fault. If I hit someone because my brakes failed due to a manufacturing defect, sure blame the tool.
In this situation, the author didn't understand the API key they created. They also likely told the AI it could do a bunch of things (I have claude code ask me before doing anything except read/plan). So I'm sure he turned off some guardrails.
He expects an API to offer an "are you sure?" - it's an API.
He's blaming everyone but himself.
Give me a break. The problem is the Waymo that is blocking a lane sideways and is not pulling forward out of the way of the ambulance, a move that even the worst human drivers would likely know to do.
It does no good to pretend there aren't problems with self-driving cars or make excuses.
It's not about the other entities.
"Maybe, or maybe FL180 is a nice clean line for class A airspace. No need to bother transcontinental flights for a local issue."
Way more plauible
It was 16 years...
Huh? I'm no fan of Salesforce, but they bought Heroku in 2010. That's not "just letting it die."
Even blog post is generous. This is an ad.
You might want to harden that those outbound firewall rules as another step. Did the Umami container need the ability to initiate connections? If not, that would eliminate the ability to do the outbound scans.
Also could prevent something to exfiltrate sensitive data.
Probably, because researchers/vendors/maintainers aren't going to catch everything, but you have less exposure too.
Perhaps they don't have the funds to implement that feature.
Yes, that's likely much cheaper than loading up an aircraft carrier with a bunch of Mustangs and Silverados. They're still likely bound to some sort of lowest bidder for contracts. It's also likely to be more economical than having the person find their own transport and reimbursing them.
It's a pretty robust logistics system. The tour lengths are 2-3 years. If your job demanded that you relocate to another continent for 3 years I think we'd all expect some relocation assistance.
I was so happy to read that part of the statement. A refreshing bit of common sense.
That's the reader's fault then. I see the blog post as the counter to the insane resume-building over-engineered architecture you see at a lot of non-tech companies. Oh, you need a cache for our 25-user internal web application? Let's put an front a redis cluster with elastisearch using an LLM to publish cache invalidation with Kafka.
The author does acknowledge that in the "How it Should Be" section.
It took me a while to realize that there is no getting ahead. Something else is always waiting, so better for my health to prioritize and make those whose job it is to prioritize actually make the hard decisions they're paid to make.
Interesting. Makes sense for open source. In the workplace for those using common IDEs things like .vscode or .idea can definitely help with consistency or shared project setup. Each has docs which mention which files should or shouldn't be committed. Personally, I just use gitignore.io to generate the file based on my company's tooling and call it good enough.
Seems like a lot, especially after checking "disable telemetry"
There are pictures of them in the report.
Right...the GBU-57 having been placed into service in 2011 was surely created to destroy 65-year old bunker designs.
I am in no way qualified on this, but my assumption was that this comes from cultures that consider getting straight to business rude.
So while I do find it annoying, I also try to be polite back and I certainly won't be putting some "No Hello" link.
If it is a cultural thing and coming from a place of politeness, then I'll engage in a quick round of pleasantries. Once people are familiar, I've noticed this stops.
That’s not going to make the front page of HN though.
Sure, if you’re the 0.00001% that need that. It’s going to be over engineering for most cases. There are so many simpler and easier to support things that can be done before trying this sort of thing.
Following the example, why is all the data in one giant request? Is the DB query efficient? Is the DB sized correctly? How about some caching? All boring, but if rather support and train someone on boring stuff.
Not when "off the shelf" is the motto. They'd still have to outsource the development and at that point would be questioned why spending that much money when Telemessage sells the product.
Unfortunately, the financial structure doesn't really make it easy for custom DoD software.
From the Wired article, it may not have even been a mistake, depending on the version of Spring Boot.
"Spring Boot Actuator. “Up until version 1.5 (released in 2017), the /heapdump endpoint was configured as publicly exposed and accessible without authentication by default."
From the Wired article: "The archive server is programmed in Java and is built using Spring Boot, an open source framework for creating Java applications. Spring Boot includes a set of features called Actuator that helps developers monitor and debug their applications. One of these features is the heap dump endpoint,"
So the heapdumps being available is a Spring Boot feature so it does not appear to be malicious.
Could it have been something as simple as "hey, zoonn.us is violating Zoom's copyright, please block it" and then someone typos "zoom.us".
Two players used the bats. I'm not a Yankees fan, but all these articles are making it seem like the bats are the reason. That does not explain why the rest of the lineup went off. Perhaps poor pitching is the better explanation. Too much is being made of these bats.
Also, golf club technology basically does the same thing. Everything is about making a bigger sweet spot. Oversize drivers and irons didn't seem to ruin the game.