It really isn't.

Because those recovery mechanisms have created account access attack vectors.

This is true for YouTube Music and other things where there are contractual limits they have to abide by. But outside of that, there is no limit on the number of devices you can have logged into a Google account.

There are really good account security reasons for this.

No, you can also set up other factors. Configure Google Authenticator (or another TOTP app; they're all the same) or, even better, get a USB or bluetooth security key. You can also generate backup codes and store them in a safe place.

All of this comes down to the simple fact that account hijacking is a huge problem, for Google as well as for users, though mostly for users, and passwords suck.

I know it's more fun to be cynical and assume it's all just BigCorp being nefarious, but it's not true. I know people in the Google account security teams and they're pulling their hair out. What they really want to do is deprecate phone numbers, too, because they're actually not a good authentication factor. But users aren't willing to use TOTP or security keys and while passkeys are great, if you lose your device, you lost your passkey. The least common denominator authenticator that provides some measure of security is the phone number.

No one should be using RSA now, even ignoring QC. RSA is slow, unwieldy and error-prone. No one who knows what they're doing uses it except in very narrow niches where it has properties that EC doesn't. Every cryptographer and cryptographic security engineer I know (including me) treats the use of RSA in protocol designs as analogous to a "code smell", a strong one. If I see a protocol design that uses RSA, it's an immediate red flag that the designer very likely doesn't know what they're doing and has probably made a bunch of mistakes that compromise security. Unless, of course, the design explains in detail why they did the weird and risky thing. Competent people will know it's weird and risky and explain their rationale for using RSA in the first few paragraphs of the doc.

However, the EC-based things people should be using are also at risk to QCs, and everyone making hardware with a lifespan of more than a few years should be moving to PQC algorithms now. At minimum, you should make sure that your cryptography-dependent designs explicitly plan for how you will migrate to PQC (including on devices in the field, if relevant). You don't have to actually move now as long as you have a clear path for moving later. But if you're, say, shipping hardware with embedded firmware verification keys, you should probably make sure that it contains a SPHINCS+ key or something and some way to enable its use in the future, even if only to bootstrap the use of some more manageable PQC algorithm.

I see no evidence that it's true. It's almost always the case that competition pushes progress faster. The only real exceptions are when the competitors are able to keep core elements of their approach secret, which isn't the case here; both IBM and Google researchers are regularly publishing most of the details of what they're doing.

This is definitively, objectively, not true, at least with respect to code quality, performance and security. Where Linux shines is in support, both in terms of available device drivers and niche-specific features, and in terms of having the broadest base of experienced users and admins. If you need a kernel and OS that will run on nearly any platform, with nearly any devices, and for which you can easily hire people who already know it, Linux is your best option. It got that way not by being supremely excellent at anything but by being reliably good enough (barely) at almost everything.

But it's really not the best kernel. In fact, if you want to look at widely-used OS kernels, I'd say that both of the other alternatives (Darwin and ntoskrnl) are technically better in important ways, and that both are less buggy. I do security, so from my perspective that's the key measure, and both are definitely better than Linux, as are many of the *BSDs.

Note that I'm not knocking Linus. It's actually rather amazing that Linux works all the places and all the ways that it does, and it's a powerful testament to Linus' ability that he's still running his project, even now that it's critical to world technology stacks, including at the biggest tech companies. Being good enough at everything is hard, and that goal is probably fundamentally incompatible with being extremely high-quality, or maximally-performant in a particular niche, or highly secure, etc.

Why not? You're going to read and review the code just as thoroughly as if you'd written it yourself. The "while in production" phrase ominously sounds like you're taking some unusual risk, but you're not. It's no different than writing new code then taking it through the normal code review and QA processes to put it in production.

I picked apart your weak arguments. But, whatever.

Unless they're holding off because of IP concerns, that doesn't make any sense to me. If the tools work well enough to be worth using on personal projects, why not use it on paid work?

This is my point. Don't use it if it wastes time or produces bad results, use it when/where it saves time. One easy way to do this is to copy your source repository and tell the coding agent to go write test cases or implement a feature or whatever and keep working on it until the code builds and passes, and while it's working you do the work yourself. When it's done (it will almost certainly finish before you), git diff the result and decide whether to use what it did or what you've done 20% of. The time investment for this is negligible. Or, what I tend to do is to set the LLM working while I catch up on email, write design docs, attend meetings, etc.

Hype or lack thereof is irrelevant. If makes you more productive, use it. If it doesn't, figure out why not. If it's because you should be using it differently, do that. If it's because the tool just sucks try a different one, or ignore it for a few months until it gets better.

It is for me. Why wouldn't it be for you? If the LLM produces code that doesn't meet my rather picky standards, I tell the LLM to fix it, or I fix it. Either way, the code is going to be basically indistinguishable from what I'd write before I send it for review. I guess it's possible that the LLM could write better code than I would write, but it definitely can't be worse than what I would write, because I won't allow that.

I've been a professional software engineer for 35 years, and been involved in hiring for all but the first two, in several different companies from tiny startups to giant corps (IBM and now Google). Maybe computer engineering is different (I doubt it), but in all that time I've never seen or heard of a company that cared about GPA, because it's a really lousy predictor of ability. Sometimes recruiters use GPA as a screening tool when they have absolutely nothing else to go on, but that's the only use of GPA I've seen.

Companies mostly want to see if you can really do the job, and the best evidence is showing that you have done the job, i.e. you have real, professional experience as a software engineer. Failing that, they want to see evidence of you having built stuff, so a Github portfolio (or, before that, a Sourceforge portfolio). The best way to get said professional experience is to do an internship or two while you're still in school. Spend your summers working (and getting paid!), so that when you graduate you have that experience to point to.

Yes, absolutely, to the internship. Meh to the GPA.

That said, I'm not surprised it's gotten a little tougher. AI tools can't replace experienced SWEs yet, but under the supervision of an experienced SWE they definitely can do most of what interns and entry-level SWEs usually do.

I don't understand what this means. How do you "dabble" and what would it mean to "pivot"?

I use AI for stuff it does well, and don't use it for stuff it doesn't do well. Knowing which is which requires investing a little time, but not much.

Why should any of that matter? If using it makes you more productive, do it. If it doesn't, don't. This isn't like a new language where using it requires a significant commitment because you'll have to maintain it in the future. The code you write with AI should look basically the same as the code you'd write without it.

Also, it's questionable how many of the civilians were really civilians, given the Japanese "Ketsugo" plan, which organized all men 15-60 and all women 17-40 into combat units, trained millions of civilians, including children, to fight with bamboo spears, farm tools, explosives, molotov cocktails and other improvised weapons and had the slogan "100 million deaths with honor", meaning that they expected the entire population would fight to the death rather than surrender to invasion.

Would that actually have happened? No one knows. What is certain is that Allied knowledge of Operation Ketsugo caused war planners to increase their estimates of Allied casualties because they assumed they'd be fighting the entire population. Experience with Japanese soldiers who consistently fought to the death validated that the Japanese culture just might be capable of that.

That was an important part of the context in which the decision to drop the bombs was made.

The Japanese intention was to issue formal notice that they were terminating negotiations and that further talks were impossible, effectively announcing an end to peaceful relations and declaring war, about 30 minutes before the attack, but they screwed up. Delays in decoding and preparing the message resulted in it being delivered about an hour after the attack.

An interesting twist here is that the US had broken the Japanese diplomatic code and was reading all of the correspondence between Japan and its embassy. Roosevelt knew Japan was breaking off talks more than 13 hours before the attack, and even before the Japanese ambassador did. So the US knew an attack was coming, though they didn't know it would land on Pearl Harbor. The assumption was that Japan would begin by attacking US forces in Southeast Asia. The commander of Pearl Harbor and other Pacific forces should have been notified of the change in the diplomatic situation well before the attack began, but bad assumptions and bureaucracy delayed that notification. Had that notification been delivered, and taken seriously, the Pacific battleship fleet would have been at sea when the Japanese bombers arrived, able to maneuver and fight back effectively, and US air forces would have been on alert and able to get off the ground and fight back. It's even likely the Japanese fleet would have been located and attacked.

Of course, US internal failures in no way affect Japan's culpability for not providing timely notice. The Japanese certainly didn't know that the US was reading their mail.

Indeed. The Japanese Empire had to be dismantled. Could it have been done without nukes? Sure. But definitely at much higher cost in American lives, and probably Japanese lives as well. The Japanese planned to send hordes of spear-wielding civilians to attack invading US Marines. It's horrible that many civilians died in Hiroshima and Nagasaki, blown up and burned and irradiated. But the alternative was to kill many of them in firebombings, or to machinegun them on the beaches.

We'll never know exactly what might have happened if the bombs hadn't been dropped. But what happened after Nagasaki was that the fighting ended, paving the way for what has, as you mentioned, been a surprising and marvelous friendship.

Many people seem to autocorrect most of what Trump says, on the assumption that the leader of the free world couldn't possibly be as stupid as he appears to be. Unfortunately, his biggest talent is and always has been inflating his apparent intelligence and competence; what you see is more than what you get, not less.

(a << 16) + b.

What I typed to get that was "(a &lt;&lt; 16) + b".

This is the economist view, but it's really not true. Companies are made of people, and people make decisions for all sorts of reasons, almost none of them purely financial even when the justifications are argued in financial terms. In this particular case, Steve Jobs was a UX purist who made all sorts of decisions on the basis of his taste for elegance and simplicity, even when they didn't make much financial sense. Most of his worst ideas were stopped by the people around him -- often with financial arguments -- but many weren't.

The "homo economicus" model is useful, but don't confuse it with reality.

I was traveling last week and missed it, so this is cool.

I don't think it counts as a dupe unless the original is still on the first couple of pages.

The president is the boss of the executive branch, and he has to be able to give orders to them to tell them how to do their jobs. Of course, those orders should only be about how they're supposed to go about executing the law, as defined by Congress and the Constitution. The problem isn't the ability of the boss to give orders, that's as it must be, the problem is that Trump is giving orders that tell the executive branch to do things that that exceed and sometimes defy the laws defined by Congress and the Constitution.

When that happens, it's the responsibility of the other two branches to rein him in or remove him. The courts are mostly trying to do their job to rein him in but their ability is limited. The intention is that when the executive gets out of control, Congress should give him the boot. Instead, the GOP leadership in Congress is cheering him on.