> they still require a generator and high voltage battery.
They require two generators, but they also don't require a starter motor or an alternator. Meanwhile a non-plugin hybrid only needs around 2 kWh worth of battery, which has gotten so cheap you might prefer that to a clutch replacement.
Yeah, this thing is unusual. It resembles a consumer GPU but using normal DRAM with more channels, so then you get more RAM but less memory bandwidth than GDDR/HBM, which is the same thing Apple does. And the TDP is pretty attractive for what it is.
But what is that amount of SRAM for? It simultaneously seems like a lot, because SRAM is so expensive, but still not very much, because what can you fit in 0.5GB? Is there a specific workload that needs something that looks like this?
The Intel D270, Nvidia DGX Spark, and (somewhat) AMD Strix Halo also use the same approach, so it seems to be getting pretty common.
SRAM wise it doesn't seem too insane. About the same ratio of memory:SRAM as the 5090 (IIRC). Still more than I would have expected. I assume they found it helps process the current layer faster or something.
0.5 GB of SRAM is exactly what the Cuckatoo32 [1] Proof-of-Work scheme needs for optimal solving efficiency. Solutions are 42-cycles in random bipartite graphs of 2^32 edges on 2^32 + 2^32 nodes, which can be found by repeatedly removing edges that have only one adjacent edge. Tracking which nodes have incident edges takes 2^32 (completely randomly accessed) bits which is exactly 0.5GB. Another 0.5 GB is needed to track alive edges but those can be accessed serially for which DRAM suffices.
People who make fun of greater Seattle for freaking out over snow generally don't understand just how extreme the topography is out here, even downtown and on the highways. It's not Ohio or the Northeast with at most gently rolling hills. It's snow PLUS ridiculously steep terrain.
As someone that grew up in Pittsburgh and lived in the Seattle area for 5 years, Seattle's topography isn't that extreme, the drivers are just awful. My favorite example is this interstate exit: https://www.youtube.com/watch?v=Tij3SRs_5wg&list=PL_ZOHdoqrC...
To be fair, SF is the hilliest city and Seattle is #2 last I checked. But nobody in Seattle complaining about everyone else in Seattle is talking about people sliding into intersections downtown, they’re talking about the number of completely avoidable ditches and accidents in places that are inexcusable.
I lived in Seattle longer than I lived in the Midwest. I’m not talking about people spinning out on big hills, and I never got the impression other people were. It was seeing cars spun out on curves or gentle inclines that rated bagging on Seattleites for being dumb as a box of hammers on the road.
I’ve seen two cars on their roofs on an uphill in Seattle. How the fuck do you even DO that?
Tires are the big thing. The vast, vast majority of Seattlites aren't swapping out for a winter tires set in winter, and they aren't running a 3PMSF-rated all-season / four-season / all-weather tire, either.
The first time I went out of my way to research tires I was shocked how much braking distance typical tires lose at 50% wear. I would have expected 50% to be when things first start getting bad, not 25%.
These days I aim to replace my tires at about 50% wear and no later than 60%. New tires make you corner so well it almost feels like a slightly newer car.
It kinda feels like insurers should give you a discount for running good/great tires. It's such a safety benefit. The externality of crappy tires isn't captured in their sale price.
If it mattered enough to be commercially viable, they totally would be. Actuaries are ruthless.
Since this is not happening, we can infer that insurance companies believe the benefit to their risk profile is less than the cost to administer the program and issue discounts deep enough for customers to participate.
It seems counterintuitive that stopping distance is not that big a deal, but it must be true.
Certainly it would be cheaper for them to run a program where you take a photo of your tires every few months, vs. the program they all have where you plug a surveillance device into your car. So the true benefit from good tires must be far less than driving style.
Car insurance has long moved to trust but verify with repair shops. They let the shop assess the damage to your car, rather than sending their own adjusters. The adjusters they have are used to audit their repair shops and sanction or remove ones that are cheating.
The compensation to the shops is in the form of steering business to them from their agents when customers call and say they’ve been in a wreck.
They could do the same with tire centers. We offer a discount if you get tires from here or there. But I think the problem is that what those companies want to do is not change your rates except when you have a life event, get a new car, or have an accident. Tires would have your rates going up and down, unless they made a AAA type of deal with tire centers where you show your insurance and they give you a discount for the tires. Which perhaps could work.
I don’t know if it “certainly” would be cheaper for them to administer a program and maybe that’s why they don’t. It still takes manpower and maintenance teams to keep the program running and maybe that’s not worth enough dollars per year.
Also as we discovered from the Firestone/Ford debacle, a safe tire on one model of vehicle is not safe on another. So you have to do safety research on every vehicle and tire combo.
Hard to square this tire company "change them ASAP" marketing stuff with the tread depths that new performance tires (think like "street legal" race tires) come with.
Performance tires aren't going for economy. They come with less tread height because it has better behavior under side loads (turning). And less rolling resistance and marginally less weight.
I would counter that it depends on the kind of tires you are running and anyone selling tires in Cascadia that aren’t wet rated should be locked up for reckless endangerment.
Seattle isn’t that bad in wet pavement, unless it hasn’t rained. Which only happens about four to six times a year but that’s still enough that people should pay attention.
Even ultra high performance summer tires can tolerate wet. You have to deliberately choose to run slicks (or bald tires) to get something that can't handle rain.
That's assuming you were reading it without writing to it. There are three common cases when that isn't true.
The first is that you have a fixed buffer large enough for the maximum message size even though the typical ones aren't that big. You most often write 1% of the buffer and read it back, the other 99% is never accessed.
The second is that you always write the entire contents before reading it but the compiler may not be able to see that.
And the third is that you have a code path where that variable is simply not used.
You would then have the compiler emitting instructions to write zeros that are either overwritten before being read or are never read at all.
Moreover, zero initializing the data doesn't actually remove the bugs when that isn't the case. Consider the first case when you mess up. You have a fixed buffer used to store variable length messages. For the first message the buffer is now zeros instead of uninitialized, but for every subsequent message the remainder of the buffer still contains the remainder of the previous message and subjects you to information disclosure or data modification if you're reading back a different amount than was written in the associated call.
Now consider the second or third case. You unintentionally read from a variable before assigning to it. You get zeros instead of uninitialized memory, but if you weren't expecting zeros, well, the UID field is now 0.
If you are writing to it before reading from it then it's not uninitialised, and in 99% of cases the compiler can see that and will not set it to 0 at its declaration because that's a dead store.
The function maybe_fill_buffer() is an external library function that either fills the buffer and returns true or doesn't access it and returns false. Or maybe it unconditionally fills it, or unconditionally returns false without reading from it. The compiler can't see any of that though because it's in an external library. For all it knows that function is going to read from it instead of writing to it.
Notice that if it could actually figure it out 99% of the time then it could also emit a warning the 1% of the time that it can't and encourage you to make an explicit choice, which would have been a better option if that was actually the rate.
> the more features you add to the burner phone, the more it begins to look like the device you're leaving "safe" at home.
Wouldn't a sensible way to do this be to create an encrypted backup of your device on a VPS, then restore it to the "burner phone" once you're on the other side of the border, and wipe the device again before you come back?
The idea being that whenever you're at the border crossing, the device contains nothing, and the passphrase for the backup is in your head.
How does the customer service rep tell that a name with some Unicode gubbins is an attack rather than a customer from Juárez or 서울? Having a busy hand copy and paste the attacker-provided string into the system doesn't get you out of it.
Simple but less culturally sensitive solution: English is the linga franca so tell them to either romanize their company name or come up with a brand name using latin characters.
삼성전자 can be written as Samseong jeonja in latin characters and translated literally as Tristar Electronics but they do business as samsung.com
I think it's cool that we figured out a way to encode CJK and other foreign script into ASCII-only domain names but if there's a serious concern about opening yourself to domain spoofing because someone picked the wrong encoding, just use ASCII characters.
> Any stenographic system that you have the code for can be trivially defeated.
They're giving you an oracle regardless, which is almost as good. Take LLM output, make some modification, ask the detector if it's LLM output, repeat until you learn what kind of changes you have to make to defeat it.
Or don't even bother learning what to do, just make arbitrary changes until it says it's not, so when the person they're submitting to does the same check it says the same thing.
I assume this oracle will be behind 20 layers of anti-bot protection, CAPTCHAs and hardware attestation challenged. It will be incredibly painful to use. It won't stop the motivated attackers, but will make it too annoying for the average person.
They could (..and probably will..) store that version and then refuse the check if this attack is detected, i.e. the version is too close to a known LLM output.
Alternatively they could also just keep saying "yes" if it's close enough to a version that was close enough.. Although that would enable the attack to allow arbitrary text to be "proven" AI, by slowly morphing close-enough generated material to the desired text. But perhaps this is not a problem they are not concerned with.
To satisfy the letter of the law I expect it's enough to just provide the oracle, without any mitigations.
> But if you want to participate in the writing, debugging, and maintenance, it has to be in a language that a human can read.
I think the idea is that languages like Python and JavaScript make it easier for humans to write the initial implementation, whereas the "hard" languages from the perspective of creating the minimum viable product are the ones that make it easier for humans to maintain the code, and this has historically been a major trade off.
Whereas if you have the AI write the initial implementation...
They require two generators, but they also don't require a starter motor or an alternator. Meanwhile a non-plugin hybrid only needs around 2 kWh worth of battery, which has gotten so cheap you might prefer that to a clutch replacement.
reply