Hacker Newsnew | past | comments | ask | show | jobs | submit | more asynchronous's commentslogin

To be fair, the supply chain angle was probably the main point of the attack- it’s a psychological flex in the highest order, you can’t even trust your equipment anymore.


That's generally what sets terrorism apart from "regular" crime. Of course, if you're a civilian anywhere near one of these pager-bombs when were triggered it's going to have the same effect.


The blast radius of trust is much larger though. If we don't have a reliable way of stopping similar attacks in the future then it's pretty bad for everyone, not only for Hezbollah.


That's pretty much certain: First the pagers, then after they have a chance to switch devices the walkie talkies were detonated the same way.


I wonder if we should come up with a term for an attack whose goal is to sow fear and distrust rather than accomplish a concrete military objective.


Most of the comments here seem to be suffering from amnesia as to why Tesla is even opening their charging network- remember, the Feds literally begged them to and paid them money to do so.

As a Tesla owner, I see this as a straight up loss in nearly every category. I never have used a third party charger, so even if those chargers move to the NACS standard it won’t improve my life in any way.

I’ve already had to deal with Rivian or Ford owners taking up several stalls at the Superchargers (because they weren’t designed to fit correctly, and Rivian drivers are incompetent) and taking over twice as long to charge as Teslas are able to.


You have it backwards- it hadn’t made sense from the invention of the internet until 2020. I point to “teleworking” being a legitimate thing even before the internet was mainstream as evidence that the traditional office is a relic from the 40s and 50s typewriter factories.


My dad has been working from home since the 1980s. He worked for AT&T, selling telepresence products. He told his boss "how can we expect our customers to believe in these products if we don't?" And they let him work from home forever


Hilarious to watch Zoom return to office in the last two years.


It’s a dumb question simply because we know most North Korean cyber agents are working abroad- they literally live in China or somewhere else and setup infrastructure elsewhere to remote into.


GPT-4o got a whole lot closer to realism though- I’d say we’re better than Skyrim’s pre recorded speech system at this point.


Maybe I’m not seeing it but would be nice to have some metrics in this study to point to- maybe a control game which changes a fundamental part of the concentration mechanic.


Tesla is amazingly good at software development practices. It’s the new Fords that are bricking themselves via updates, not Teslas.


That's not the impression I've gotten from Tesla's software. From the flash wear issue to the numerous vehicle opening issues, to the entire mess of their UDS implementation, there's quite a lot to complain about compared to a hypothetical "best practices" manufacturer, as opposed to the dumpster fire software of other OEMs.


Was it Chris Lattner or Francois Chollet that joined Tesla, set up their CI pipeline, and politely left?


I don't know anything about their practices, but once bumped into this Reddit post by someone claiming to be ex-Tesla and describing exceptionally bad practices. There's no way to verify the claims, they could as well be total misinformation. But I found the link to that Reddit post:

https://old.reddit.com/r/EnoughMuskSpam/comments/99sbwa/form...


It's easy to complain since they're the only manufacturer who opens up your car as an API


None of the issues I mentioned where discovered via API. The flash wear issue was discovered by bricked cars. Security researchers are pretty good at publishing about remote unlock mechanisms for all manufacturers, though Tesla's bounty program has helped. The UDS implementation issues are non user facing and were discovered by reverse engineering. Ford, as an interesting point of comparison, published a competent (if incomplete) open source UDS server.


I wanted to say thank you, searching for that phrase[1] produced a ton of fascinating reading, including https://mpese.com/publication/uds_fuzzing/SAE_UDS_Paper.pdf "Comparing Open-Source UDS Implementations Through Fuzz Testing" from Apr 2024 which itself linked to a lot of GH repos of the tools they used

I didn't find the Ford one specifically, but I also didn't go surfing through the many pages of results

1: https://duckduckgo.com/?q=open+source+UDS+server&ia=web


I can think of several enterprise brands that are also all three of those.


I'm sure I don't trust them either.


I’d say Ubiquiti is still the best pro-sumer for home networking. They’re expensive, but they really do have a quality and ease of integration/setup/use that just isn’t matched, even when you get to enterprise level (go setup a Cisco without your CCNA and then come tell me about how great it is).


The main reason why consumer wireless APs fail is inadequate power supplies. Ubiquiti gear is solid in this respect.


I have to agree with this to a point. I went with Mikrotik a while ago, which delivers great bang for the buck but oh my god the UX is terrible. Not helped that I don't want to spend more time learning it fully (it would be more cost effective to trash it and buy something else).

TP-Link and omeda is probably an alternative, but after spending time trying to figure out what they offer and what their alternatives are for my needs I just give up with their confusing model numbers and half hearted explainations.

The problem I really have with Ubiquiti is when I look at their offerings and what I need I am immediately put into their Enterprise offerings and I am running 48 ports.


Using Rust for markdown parsing seems like the epitome of driving a racecar to the grocery store- I’m curious if you have any metrics as to how much build time was reduced with that over using something like Node. I’d guess it’s <10ms.


We saw nearly the same reduction in build times (~80-90%) as quoted in the official RsPress documentation. Keep in mind, we're using MDX, not just plain Markdown.

Source: https://rspress.dev/guide/start/introduction#build-performan...


There can be more of a difference than you might expect. In static site generators, Eleventy is about as fast as you can get in the JavaScript world, and is still 2-3x the time for Hugo in Go [1]. A couple orders of magnitude more than <10ms in this test which is predominantly markdown parsing.

Anecdotally, for large or extra large sites, the build performance gap between even Eleventy and Hugo can be quite large. And the gap from either of those to the newer JavaScript tools like Next.js is enormous.

1: https://www.11ty.dev/docs/performance/#build-performance


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: