Dude, I've been writing code for 40 years. I've used so many different tools, stacks, libraries and APIs that at this point I don't remember any of them, and I haven't remembered them for years, and it doesn't matter at all. Sure, I have to look everything up, but that's fine, that doesn't matter. What matters is that I know when something looks wrong, or hard to maintain, or inefficient, or insecure, or... pick the axis. And I can dig in and find the problem. Anyone can tell if code works, that's easy. Understanding when and why it might break or otherwise impose additional costs, that's the real skill.

Which, as it happens, is exactly the skill you need to use an LLM effectively. Also the skill you need to understand legacy code, review colleagues' commits, etc., etc., etc. I used to say that the ability to read and understand code is an underrated skill, but an old friend corrected me at lunch a couple of weeks ago, saying that the ability to read and understand code is the most important software engineering skill, and always has been. Upon reflection, I agreed. And LLMs make this clearer than ever before.

I'm confused by all of these posters who've never heard of "the curve". I wonder if it's because they're all young'uns who went to school during an interval when progressive educators had decided to abandon it... with the inevitable grade inflation that was totally predicted.

When I was in college 40 years ago every class that had more than ~30 students in it was graded on the curve, and even some of the smaller ones (though in a smaller class it becomes statistically questionable). I used to love the groans when a buddy and I walked in the first day of class, because they knew we were going to "bend the curve". :D

Though in all seriousness, the whole point of using a curve is that in a sufficiently large class, it's statistically guaranteed (to very high probability) to be "unbendable". Inserting a couple of students at the top would mean that students who might be just above a cutoff might fall just below it, but it's not going to make a difference to many.

College isn't like tee-ball, where every player gets a participation trophy, and it shouldn't be. Especially not at elite schools. Part of the purpose of a university education is to act as a filter, and not just to filter out those who can't cut it at all, but to rank all of the students by performance, so graduate schools and potential employers can make use of that information.

Don't be so sure about the "shipped off". Google is heavily investing in on-device AI that runs in a trusted enclave (e.g. TrustZone on ARM). I left the company in August of last year but I doubt this has changed since it's been a major area of focus for quite some time.

I don't need 1000 miles. 600 (unencumbered) is definitely sufficient, and 500 might be okay. The thing is that I'll lose half to 2/3 of that range when towing my camp trailer, and that's not even considering that I'm typically towing it up into the mountains, gaining ~5000 vertical feet. I also need minimum 12k pounds of towing capacity and I'd like a little headroom, so call it 16k, and the bed payload has to be able to take at least 2000 pounds, because that's how much the trailer puts on the fifth-wheel hitch.

I'm anxiously awaiting an EV pickup that can do this. I'd love to have essentially unllimited electricity to buffer cloudy days (I have 1 kW of solar panels on the trailer and on sunny days they generate way more than enough, but consecutive cloudy days can leave be difficult).

3/4 ton and 1-ton gas and diesel pickups typically have oversized fuel tanks that provide about 600 miles of range, because that's what you actually need when you start hauling or towing significant loads. I don't think an EV pickup needs to have more range, but it needs to be comparable, and to be able to tow and haul comparable loads.

I'm not anti-EV by any means. I bought my first EV in 2011, and have had electric cars ever since. Trucks are a different sort of problem, though.

That's getting there, though I'd like to see some driving tests with a good-sized fifth wheel at highway speeds. The towing capacity is probably okay, though it provides very little headroom for when I'm towing both my camp trailer (~8k) and my boat (~3.5k), which I actually do several times each summer. But I think the payload capacity is too small to tow the trailer, which puts about 2000 points on the truck.

Agreed. My sedan has been electric for nearly a decade now, but I'm still driving a diesel pickup (1-ton, though a 3/4 ton would be sufficient) because EV pickup range is inadequate -- and I think it may be inadequate for a while. I need 250 miles of range when towing a trailer, which means I need ~500 -- maybe 600 -- miles of range without.

I'm not generally a fan of hybrids, but I think plug-in hybrids with large-ish batteries may be the sweet spot for a while with pickups. The Dodge Ramcharger is looking really good to me, though I'd like to see them make a 2500.

It is effective at reducing staff cheaply, but it has a huge downside, shared with most attrition-based schemes for reducing payroll: The best employees are also the ones who find it the easiest to leave. The worst employees are also the ones who will grit their teeth and hold on to the bitter end.

It's harder and more costly (in the short term) to do targeted layoffs which allows the company to target low-performers, or those who are low performers relative to their cost. It's the better choice, though.

Lots of the top performers will.

Using a proper password hashing algorithm mostly addresses this concern... and standard cryptographic hashes like MD-5, SHA-1, SHA-256, etc. are not appropriate. They're designed to be as time and space-efficient as possible while still achieving their security goals. Password hashing functions (more precisely, password-based key derivation functions) are designed specifically to be time and space-hungry, efficient enough that you can execute them in half-second or so for user authentication, but slow enough that brute forcing even moderately-good passwords is intractible.

The best widely-available algorithm is Argon2id. The modern algorithms don't focus so much on requiring lots of CPU cycles because GPUs. Instead, they focus on requiring significant amounts of RAM, in ways that provably cannot be reduced. The most-recommended Argon2id configuration requires 2GB RAM. This makes it feasible for most servers to handle fairly easily, as long as they don't have to verify too many passwords in parallel, but it means that GPUs don't help the attacker, and it's also slow enough that while you can get some traction by using a large botnet, it's really not very much. If a PC requires 500ms per attempt, and you have a million-machine botnet, you can still only try 2M passwords per second. If user passwords have, say, 30 bits of entropy, your massive botnet can find one every five minutes on average. If they have 40 bits, your botnet can find a password every ~3 days, on average. That's not nothing, but if you have control of a million machines, you can definitely find better uses for them.

Of course, even better is to use passkeys or similar, but as a practical matter you probably have to have a password to fall back on.

Cite? I'm not a CPA but AFAIK, being a PDT has no direct tax implications, it just invokes brokerage/margin rules.

As I understand it (and I skimmed the law), 475(f) elections are entirely optional. The tricky thing is that you have to make the decision of whether you're going to elect to mark to market by April 15 (e.g. you have to decide by April 15, 2026 if you'll mark to market on December 31, 2026), and you generally cannot change that decision. So if you think it's going to be a bad year, it's a good idea to elect, because it removes the cap on loss deductions. If you expect to make a lot of wash sales and don't want to bother tracking them, that's another reason to elect.

But as far as I can tell, it's purely voluntary. Can you point to evidence to the contrary? Ideally in the law, but a reputable investor information site would be fine. I checked several (e.g. https://www.optionstaxguy.com/...) and they all describe it as a choice. One that is binding once made, but still a choice.

It's also possible to pair it with a large residential roof solar installation. I installed solar recently (just in time to grab the 30% credit) and my system routinely generates 3X what my home uses in the course of a day (I typically use about 40 kWh per day, and often generate 130+kWh per day). I've been thinking I'd really like to find something to suck up that extra power, because the monthly net billing plan I have means that once I've zeroed out my bill for the month, I get no benefit from additional production.

As deployment of renewables continue, this "problem" of what do do with excess capacity will increase and spread.

However, if power for the mini-datacenter is only intermittently available, the cost of the hardware effectively increases on a per-token (or per FLOP or however you want to measure the system's work) basis... and hardware cost is already going to be a tough problem for this kind of deployment. Even if it could count on 100% utilization, it will struggle to compete with large datacenters for exactly the reason we build large datacenters: Economies of scale. Enclosures (buildings), cooling, maintenance... all of the overheads fall with scale.

Intermittent utilization just makes that problem worse.

On balance, I'm skeptical that this makes sense, unless the cost of the hardware falls significantly. It seems like that's a baseline requirement for a lot of the alternative datacenter ideas, though: orbital datacenters, floating datacenters, etc.

Bartz v Anthropic is not a binding precedent. It could have been binding in the 9th circuit, but they settled before the appellate court could consider it. And, of course, it's always possible that the appellate could have reversed Alsup.

I think this question is still very much in undecided. It's trending against Meta's interests, but AFAIK isn't there yet.

Put the tinfoil hat down and step away...

There's really no irony here. TPMs serve a different purpose, that of ensuring that the software you're running isn't maliciously modified.

It's really no different from keeping the password database encryption key in RAM, or the capability which grants access to the database encryption key (however many layers of that you want to go down) which is what you have to do if you want to be able to use the passwords on-demand without an authentication step.

If Chrome has access to them without user authentication, then so does any attacker who can dump Chrome's RAM.