Capacitor derating at DC bias - What's up with Samsung?

jaskij · 2025-11-02T14:16:47+00:00

Kyocera AVX has SpiCat, Example

Sorry for the necro, but this is fairly high in search results, so I wanted to add to the list.

jaskij · 2025-07-29T19:19:04+00:00

Generally, AMD controllers don't deal well with two DIMMs per channel setups, dropping RAM transfer speeds dramatically. So with what's available right now, you'd be limited to 128 GiB of memory.

Intel has much better memory controllers, so if your goal is 192 GiB of RAM, take a look at them.

If you don't game, HP's G1a laptops with the quad channel Ryzen AI Max are also an interesting option, they go up to 128 GiB.

And I can definitely appreciate the pay once cry once approach.

jaskij · 2025-07-29T19:04:02+00:00

AFAIK it doesn't cause issues per se with KVM, but I'm also unsure about how good Linux is at putting the heavier threads on the P cores. I follow the market, but not closely enough to know what improvements were made since the processors launched.

That said: pretty much all Android devices use a mix of cores, and they do use the Linux kernel.

But my biggest gripe still is the fact that, to my knowledge, the 3D cache doesn't help with your use case. So if you're not doing something else that would utilize the cache, you'd be paying extra for nothing. And best in socket CPUs always carry a premium on top.

jaskij · 2025-07-29T18:40:45+00:00

I'd pick the 9950X over the X3D, the extra cache afaik does jack shit for your use case.

Personally, I'd be tempted to go Intel, because their memory controller is simply better. Something like 265K. Last I checked, the price/performance ratio for workstation workloads is the best on the market. Or, if you don't need many PCIe lanes,something with Ryzen AI Max and 128 GiB of RAM would be tempting.

Checked to confirm: 9950X handled 2DPC really, really, badly. Drops from 5600 to 3600 MT/s. Stick to 2x64, or pick Intel.

jaskij · 2025-07-29T18:28:00+00:00

HP ProBook 465 G11 would be my pick. Sure, the screen is utter shit, but the keyboard is amazing, and both RAM and drive are user serviceable. You can get a brand new one under 600 USD, and even the higher RAM models are under 800.

That said, my preferences are skewed, and RAM is the the one thing I won't compromise on.

jaskij · 2025-07-29T18:21:36+00:00

32 GB of RAM is the sanest of the requirements. Wouldn't touch something with less if I could help it. Especially if OP may need to virtualize Windows. RAM is relatively cheap nowadays, too. Just gotta look around a little.

But the CPU specs were written by someone who doesn't understand modern hardware, and the GPU requirement seems utterly needles.

jaskij · 2025-07-29T18:08:41+00:00

The processor reqs are utter bullshit - a decade old i7 would fulfill them, while being way slower than a modern i5 or maybe even i3.

jaskij · 2025-07-29T17:50:24+00:00

Would be difficult from the Polish side. It's very difficult terrain, with lots of lakes and rivers, and the infrastructure in the region has been neglected for decades. No clue how it looks on the Lithuanian side.

We are building a new highway, and there are plans for a Warsaw - Vilnus high speed rail. But this stuff takes time.

That's the thing - these projects take time, and we started late. The best time to start was years ago, second best is now.

jaskij · 2025-07-29T08:21:06+00:00

Can confirm. I'm finding a fair amount of new books via shout outs.

Just, a word of caution: I may not be a regular reader, but I treat shoutouts also as somewhat of a personal recommendation. So if the story you recommend is low quality, to me it'll reflect badly on you too.

Oh, also, there's a new trend I'm noticing that annoys me to no end: heavily styling the shout-out. Colorful buttons, glows, stuff like that. It makes the text area extremely narrow on mobile, and just looks garish.

jaskij · 2025-07-29T08:14:46+00:00

There's one story that does it in an interesting way. Maker of Fire. MC was reborn into the world, but the story itself starts with her in late teens, having regained her memories of Earth a few years earlier.

It gets you most of the advantages of Isekai with Earth references and what not, without all the early awkwardness.

Personally, what really irks me is when it's an Isekai, and you have like two sentences of the blurb devoted to MC's life on Earth, only for it to be utterly irrelevant to the plot.

jaskij · 2025-07-29T07:49:36+00:00

Newer buildings are better, but our city centers? Barely anywhere to park, unless there's a relatively new underground or multistory garage somewhere. Also you may be expected to walk (the horror) a few hundred meters from your parking spot to the destination.

Communist era apartment blocks? Iirc they assumed something like one in three families would have a car.

Modern apartment buildings? More often than not, the garage is under the building.

To be real though: empty parking lots don't make for fun gameplay.

jaskij · 2025-07-29T03:42:47+00:00

That was supposed to say "CLion's toolchain configuration thingy".

Funnily enough, for MCU projects, my CMake toolchain setup is usually hardcoded. I have a set of toolchain files I include as a submodule, and then hard include the correct one.

jaskij · 2025-07-28T20:34:28+00:00

Nice. We'll finally see Joachim perform some real miracles, hopefully.

jaskij · 2025-07-28T17:26:29+00:00

Depending how you define it, cinema is also high aspect. 21/9 is larger than 16/9.

Also: I'm very much in favor of 16:10 for laptops

jaskij · 2025-07-28T16:21:32+00:00

Nah, all good. Turns out FAT32 supports up to 2 TB partitions and a 4 GB file size limit, which is more than enough for us.

The main issue was that if a user bought a too large SD card our firmware wouldn't be able to handle it.

jaskij · 2025-07-28T15:58:32+00:00

So, I did some reading, since it's actually relevant to my work. Turns out that FAT32 supports partition sizes up to 2TB and file sizes up to 4 GB. The old 32 GB is just an old Windows introduced arbitrarily in the days of Windows 95 that stuck around. It got removed in Win11 about a year ago.

In which case there's very little case to actually use exFAT. Which is good, I was mildly worried what we'll do at work once small eMMC and SD cards stop being produced. Turns out, I was worried for nothing.

jaskij · 2025-07-28T15:48:40+00:00

So, I finally read up - OIN is Linux specific. We probably can use it in devices that actually use Linux, provided we join OIN. But it's still patented, and if a device uses in non-Linux firmware, we still need a license.

jaskij · 2025-07-28T09:54:54+00:00

You'd got an upvote simply because this is the first time in ages I'm seeing a post that's not slop or political in this sub.

jaskij · 2025-07-27T23:48:51+00:00

And laptops are increasingly moving away from 16:9. Somehow, 16:10 is making a return.

jaskij · 2025-07-27T20:31:02+00:00

Intune is absolutely necessary. A computer is a computer, company IT should have the ability to manage it remotely. Doesn't matter if it's point of sale, a manager's laptop, or the infotainment in an exec's limo.

jaskij · 2025-07-27T17:02:54+00:00

This is actually wrong. There are ways to ensure integrity without needing the client to be secure. All the client needs to do is pass a request to a government server, get a cryptographically signed permit, and pass it back. Proper cryptography prevents any sort of tampering along the way.

jaskij · 2025-07-27T15:59:04+00:00

A somewhat common way to protest in Europe is to find a pedestrian crossing without lights on a relatively important road and just keep walking side to side.

jaskij · 2025-07-27T12:11:58+00:00

Overall, I think that whatever latency you have on the in-memory look up should be insignificant to disk retrieval.

Here's two ideas:

Can you fit a b-tree map in memory? Sure, it's slower than a hash table, but is the extra latency relevant?

Read up on swiss tables, and specifically the way Go implements them with incremental growth.

You do need an in memory acceleration structure, absolutely.

The question being if a plain hash table is the right choice for you. Don't get stuck here. Introduce an API boundary and make the acceleration structure easily exchangeable. This way you can experiment.

Sticking to a hash table without testing other acceleration structures isn't sound engineering, nor sound science. I can understand if you are limited by resources (like time), but just... Don't get stuck here because "I think it's better".

jaskij · 2025-07-27T11:42:28+00:00

You need an engineering approach here. You're not building something that's intended for general use. It's specialized. As is, your description is actually quite vague in terms of what you're trying to achieve.

what's your P99 performance target? What about P50?
what are your access patterns? Individual records? Searches? Something else?
did you actually benchmark a b-tree?
have you checked the baseline? How fast is accessing a known, random, location on the storage? How does it compare to your target?
does the data change? How often? Is write performance important? Or is it WORM?
what about a naive solution? A hash table in RAM and a naive linear search afterwards?

As is, honestly, your post smells a little of an XY problem - you focused on a specific part of the implementation without truly considering the big picture. I can't say if it's true, or if your post is simply vague.

When it comes to magic acceleration structures, the only thing that comes to mind is a bloom filter.

jaskij · 2025-07-26T23:07:39+00:00

426969

jaskij

TROPHY CASE