There was also the Z/VLIRP to smooth things along.

On the other hand, poetry rhymes, and one could similarly draw a line from now-increasing interest rates to the tech layoffs, forced RTO (to help improve on some spreadsheet the property value they want to leverage) and general corporate-IT sector malaise.

Where we land remains to be seen.

(I still kinda want to get one tho.)

PCIe6 is a much larger change than 'just bump up the transfer rate', the encoding changed too (on top of the new code length, it's no longer NRZ,) so everyone needed to design and validate both the new encoding block, negotiation, etc etc.

That said, I'm guessing PCIe7 will be a 'smoother' transition from PCIE6, i.e. we might see 7.0 products in 2027. That will theoretically get you ~240GB/sec, on an x16 link, or hypothetically a little less than the hypothetical max of a current Strix Halo. (I'm guessing however, that PCIe protocol overhead will make the difference larger.)

LPCAMM2/SOCAMM2 exist, heck I think Framework is using LPCAMM2 in one of their new laptops.

Heck, I'm willing to bet that a lot of manufacturers would rather go that route than soldered in, if for no other reason than the relative cost of warranty work between the two.

However, people probably need to stop being obsessed with ultrathin laptops for that to happen.

In fact about half of my career has been dealing with 'domain knowledge at least present enough to get the ticket/epic closed but leads to a lot of tech debt'.

i.e. a good portion of my jobs have involved a lot of a good amount of:

- Review PRs with a fine tooth comb because despite domain knowledge, people are human and can either don't know any better, make mistakes, or willingly refuse to integrate feedback, or worst refuse to double check what the coding agent wrote for them.

- 'refactor this thing because it was technically correct but written so poorly that it leads to timeouts and/or a Manager/DBA is screaming' [0]

> We always joke that we'd rather hire a senior fund accountants and teach them to program if we could, only problem is there just aren't any of these folks around. Teaching an engineer to understand the minutia of fund accounting well enough to build software for these firms is tough.

A truly good software engineer is able and willing to learn the domain, but there has to be a way for them to learn. I say that because I've been at shops where various levels did that (i.e. sometimes the company itself, sometimes the team, sometimes colleagues) and I've been at shops where everything is lip service and at best you can only glean from what's in the JIRAs and what you can glean from what people outside of IT say in meetings you are in.

> After spending the last 5 years building software for venture capital and private equity, this blog post really resonates with me. Writing code is by and far the _easiest_ part of my job; understanding the financial engineering and nuance behind what my company's customers need from us the tough part.

I think a big paradigm shift especially in the past 5 years has been that most companies are expecting folks to work to the bone, and it winds up being counterproductive because it prevents anyone from being able to have the important conversations.

Culture is a huge factor in this, I've worked at shops where at the very least you could easily have a side conversation or a meeting, and shops where you might as well sign a change.org petition to request time to talk about it properly.

Still, you are right at the crux; Requirements matter more than code at the end of the day. I've been at shops where a person's definition of 'Correct' meant a feature got delayed despite all requirements being met, because they didn't like they way it was written after they were gone the whole time it got implemented and the rest of the team approved all design decisions.

[0] - Next thing you know you learn about a 'batch process' has %numberOfRecord%*10 inserts, possibly with additional fetches given a poorly designed data model to where it is doing SQL upserts in the most wrong way (i.e. doing a get from the DB and then adding a record to be inserted if not present.) and they keep doing more and more questionable things to 'improve performance' rather than rethinking the data layer's query pattern. Seen it more than once in my career.

What kind of tire shops should I look for? Smaller ones or specialty ones?

Where it can get slightly hairy is that to do it well, you need to have a LOT of seams between layers.

> but the idea of providing tests and types without implementation is a pretty interesting one.

I feel like in my head, you need to have -some- baseline/example implementation; e.x. Akka/Pekko/Akka.NET have Plugin specs for Persistence but there's still a Memory-only implementation of Persistence as a reference/baseline; after all you need to make sure the spec is possible at all.

People make a fairly-complex open source thing. Due to the complexity for certain environments/cases, the author(s) have a commercial support option.

Consumers from bigorg use it, and wind up opening issues wanting free help for their niche use case, no they don't want to get a support contract, but this subset of the user base causes a lot of churn dealing with communication, politely closing such issues (after all, you want to just be polite about support options, not drive them away!)...

And sometimes, it becomes easier to just flip the license.

In the .NET ecosystem, it's come up frequently. There's the cases where I get it; PDF is hell (iTextSharp), Imaging is hell (ImageSharp), Auth is hell (IdentityServer).

But then there's the cases where I just shrug my shoulders (MediatR has plenty of alternatives) or get happy it gives me permission to gleefully get rid of a poorly used lib (AutoMapper).

I will say you did give me a fun idea however; you could in theory set up a kiosk system where scanning renewal notice + license[0] and get some sort of OBD2 plug-in device, that could record the mileage+vin+other data (to harden against faking attacks[1]) and then you take it back to the kiosk to confirm mileage.

IDK, probably not the best way to do it but maybe there's a good way to handle this sort of scenario.

[0] - In case you abscond with the dispensed device for some reason...

[1] - But this is possibly where it falls apart...

On a lot (really most) of 4WD/AWD drive vehicles, but especially those with 'full-time' (cries in Subaru), if you need to replace one tire 20k miles in (i.e. due to a road hazard etc) you then have to replace the entire set to avoid damaging the drivetrain.

I suppose in theory you could try to 'trust' shops to properly pro-rate such scenarios, however I'm skeptical that it could be implemented in a trustworthy way without being more trouble than it's worth.

By that I mean, if you're driving an EV (or hybrid, to a large extent) properly you are going to be relying on regen braking by default, and if the EV is smart enough, it's going to do at least some limiting of power delivery to minimize wheel skip/etc on even aggressive acceleration.

As anecdata, my Hybrid weighs about 20% more than my first car, yet I've gotten more miles out of my tires than I did on that old Saturn. [0]

Said hybrid weighs close to a Model 3.

[0] - The Subaru doesn't have good data here, because it has the worst luck for killing a tire mid-life with a sidewall puncture/damage and then requires replacing all 4 anyway.

Well, FWIW the air pumps still can -help- with unburnt fuel...

It's not as good as a Cat for emissions but it's better than nothing, so they actually started being used before Cats; they just are used different now.

I don't think that's a binary. I've seen plenty of cases where due to mob culture/etc where 'speaking the truth' despite it being well reasoned ethically/morally, might get you considered an asshole by the group in question. Of course there is a grey line for where the overton window is for such discussions, and a good person would communicate such in a thoughtful manner rather than in an intentionally abrasive fashion.

Otherwise your point is spot on.

I agree, except I worry it's a bigger concern than we realize.

I still remember what CableCard (and the hoops needed for HW manufacturers to get certified) did to the DIY DVR Market...

Cause if not, it would be hilarious to do that to a clapped out van...

IMO if this would have come out a year or so earlier, I feel like it would have been more like 750$ due to DRAM pricing and thus more compelling... [0]

[0] Yes It's likely that companies had secured DRAM contracts before the launch but I am also willing to bet that they also priced the card's launch price with at least some padding for increases in mind...

I think what's semi-unfortunate is all the swings and misses, especially the cases where it wasn't necessarily a bad idea but Intel gives up too soon;

- Massively parallel simple-ish x86 cores a-la Xeon Phi; okay maybe not the best idea on the surface but I feel like nowadays the opportunities could be more forthcoming with how to reuse parts of that tech (And maybe they do but are just quiet about it... i.e. GPU acceleration)

- Optane. I think the tech would have been cheaper if they made terms for licensing easier, but maybe I'm missing part of the equation...

- This thing where they keep half assing the GPU strategy; Imagine if B70 launched last year alongside the B60 and B50, before DRAM prices went sideways. Or if they didn't take so long to release a >16GB GPU in the first place; that would have built a lot of interest, but instead they finally release a 32GB GPU alongside more bad news for the overall roadmap. The whole situation instead becomes a jarring rollercoaster that makes everyone worry that Intel is gonna kill the project the way everything but CPUs gets killed lately.