Exactly.

You expect me to believe the thing that provided some income disparity relief for a large percentage of remote workers (same pay, lower costs from relocating) is at fault for others not having jobs? I've worked (remotely) with young people. They seem eager and capable, far more so than most other age demographics.

This is just companies finding excuses, looking to claw back more control.

It sounds like you don't understand how the court system works. The SCOTUS only hears cases which are brought before it, and then selectively.

Which cases specifically do you feel indicate corruption on the part of the SCOTUS? There are definitely some dissenting decisions which don't adhere to the US constitution, and there is definitely a long running theme in the courts of activist judges re-interpreting well defined language, and perhaps (probably) even a couple judges who are compromised, but I'm not aware of any evidence of corruption.

... you insensitive clod!

And it works just as good, if not better, than the fully up-to-date Office 365 on my work Mac.

Your error is on this line:

104,544,000 square feet / (5280 feet / mile) = 19,800 square miles

You need to square the denominator so that you're dividing by the number of square feet in a square mile. 104,544,000/5280^2 = 3.75

An acre is 1/640th of a square mile, so 2,400 acres/640 = 3.75 sq miles.

An acre is defined as the area of one chain by one furlong (66 by 660 feet), which is equal to 10 sq chains. There are 80 chains in a mile, or 6,400 sq chains, hence dividing by 640.

God, I love these old units. They make me feel so feudal!

Please, no. Often when writing code I need the API reference and only the API reference. I know what I want to do and how to do it, I just need a quick check of the exact order of arguments or exact symbol names. I don't need to try to sift that out of commentary. Likewise when I'm learning how to use the library I'm more interested in the overall view. I don't need to know the exact names of the options for a call, only what the options are for. I expect the code in the user's guide to be accurate, but I don't want the same things out of it that I want out of the API reference.

Except for the bit where it does that caching for a loop where each lookup only occurs once. Because everybody caches lookups, so that must be the right thing to do (it's the most likely thing to happen) in a case where the cache is never used. Riiiiight...

Something critical to note: intent is the most important thing to document when it comes to software. You can see what it does by reading the code, that's straightforward. What I need to know most, both when writing software and maintaining it later, is why it's doing that. What's it supposed to be doing? Why is it doing it in that way? What were the alternatives and why weren't they chosen? How is it supposed to be used by code that calls it? An LLM can't generate any of that just from the code.

This is why traditionally software libraries have had two separate pieces of documentation: an API reference that details every call and it's arguments and results, and a user's guide that lays out how and why to use the library.

Not much. Plutonium isn't like uranium, it's effectively safe for human contact outside its fissioned form. This has been pretty well documented.

This is a step forward which is a long time overdue. It should've happened 30 years ago, and we'd have averted having to depend on China for our electricity production (wind + solar) without the net-zero production problems those two 'sources' introduce.

This has been typical behavior for large companies when dealing with vulnerability reports for decades. Report one, they treat you as the problem. They'll try to ignore it, consider it "not exploitable", delay and deflect as long as they can get away with it, anything but address the vulnerability. And they'll never tell anyone the vulnerability exists. This only changes when they have no choice but to admit to the problem and fix it, usually when the vulnerability is being publicly exploited. They push "responsible disclosure" because it includes the reporter not making the vulnerability public until the company has a fix, which allows them to stall disclosure as long as they want.

It used to be enough to just include a reasonable deadline when reporting it, after which the reporter would make it public if the company hadn't taken some action on it. Then companies started threatening and then taking legal action against the reporter as soon as they reported the problem, playing the deadline up as "blackmail".

So, what do you do when faced with this? The only reasonable response is to skip the company entirely and make the details public immediately. You're going to be facing retaliation from the company either way, this way the public isn't vulnerable for an extended time. And yes you include details on how to exploit the vulnerability, ideally via working code, so researchers other than the company can confirm it's a real vulnerability that's actually exploitable without having to take your word for it. No, that doesn't give the bad guys anything because remember the working assumption for vulnerabilities: if a good guy has found it, the bad guys already know about it and are using it. Remember that when the company whines.

It's a concept called defense in depth, and perhaps also defensive programming. It's good practice. You do not want to hold things off at the gate exclusively, because that relies entirely on your gate defense. This shouldn't be a difficult concept to understand.

Yes, it's potentially more difficult to exploit, but if it's known, a clever exploit can still be fashioned to expose it. This is being seen increasingly with AI driven exploits. You don't need a kernel RCE to gain full system access - you need 3 or 4 small privilege escalation bugs (theoretical problems) in different packages that are commonly used.

You're viewing the waves for the ocean.

There's also been recent research that shows that plasma actuators or electrohydrodynamic (EHD) flow control effectively eliminate drag. I'm not sure why this specific TFA gained publication but the ionic charge did not.

https://link.springer.com/article/10.1007/s40430-026-06357-y

"the people who have to review code"

That doesn't exist as a meaningful or useful discipline anymore, except in niche development roles.

Sorry, no. Your code review isn't useful. It's probably not even thorough.

We're well into the "code review should be done by agents" phase of things.

You're thinking of supercavitation. While it's something used for underwater vessels such as torpedoes, is it the same principle for partially submerged hulls?
https://en.wikipedia.org/wiki/...

<blink>12:00</blink>