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.

Ad Hominem would be saying "well Musk is a gross weirdo with a breeding fetish and why would you want to agree with a gross weirdo like that?"

But showing that Musk is an unreliable source **because he has been unreliable in the past** isn't ad hominem at all. The argument isn't about tearing down Musk as a person as a proxy for tearing down his argument; it's about saying "look, Mr Musk, you're asking us to take you at your word that you're the victim of illegal actions by Apple but your word hasn't historically been worth a whole lot."

We could agree that IF what Musk is saying is true, Apple's behavior sounds sketchy, but if we can't agree that Musk is telling the truth (and right now the validity of his claim hangs on his own credibility) then we can't draw any conclusions about Apple's behavior.

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.

There are a lot of jobs posted out there in the computing sciences but there are also hundreds or even thousands of applicants to those jobs. I've got the seniority and the leadership pedigree but even for me, a job search right now amounts to throwing hundreds of resumes against the wall looking for a match. The reality is that, because of the enormous applicant volume -- qualified or not -- the odds of even a company getting back to you, even one that's a really great fit, are low and down to luck more often than not.

The biggest driver is speed of application. If you get your resume in within the first day or so of the position being opened there's at least a reasonable chance that someone will read it and get back to you.

That forces applicants to lean into a bulk application approach. You can't invest a bunch of time in any given application because you're unlikely to see a return on that investment and every moment you spend honing your resume is a moment other people are getting in the resume queue in front of you. And realistically, the hiring manager is going to get sick of reading resumes eventually; you just hope it's after he reads yours.

So yea, the market is terrible right now and the same things that are making it terrible are the things that people are using to cope with it being terrible. Because the moment it doesn't cost me anything to apply to a position with an AI crafted resume that makes sure to tick all of the boxes this company is likely looking for... well... why wouldn't I apply? Sure, there's only a 0.1% chance my application converts to an interview but I can take that gamble if it's two mouse-clicks to put my name in the hat.

This is WILDLY different from the experience of job hunting in CS back in the late 20-teens and early 20s. The combination of hiring pull-back, AI uncertainty, and applicant profusion has completely changed the game.

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".

The "are you 18" questions were such a cool idea and it's wild how they've aged.

OJ Simpson is

a. an R&B singer
b. under indictment
c. embarrassed by his first name (Olivia)
d. no one to fool with

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.