But the phone book did not list one's political affiliation.

Maybe, but the problem is that the electronics have to run at those temperatures and not have solder joints start popping, or other fun failures.

As far as I know, it is just real-time. And it didn't even slow down at the flashing red light. So either it recognized that someone was waving it on or it didn't see the flashing light at all.

I *think* that number actually is counting them, though it's hard to be certain. I'm pretty sure servers are outnumbered by PCs by a large margin.

Cameras and LIDAR. I am not a self-driving car engineer, but from what I understand, it seems likely that it is possible to detect water with even just cameras, at least under the right circumstances, and with cameras plus LIDAR under a lot more circumstances. But doing so would require proper training data; it's not like there's a "Ooh, that's water" recognizer built into the hardware or whatever.

More to the point, they would have to train it how to recognize that some particular sensor return pattern (e.g. zero LIDAR reflections off the ground) is a problem, and do so in a way that doesn't over-correct for flooded potholes, an inch of water in the street, etc. Presumably, detecting water is the easy part; detecting the depth of water is the hard part unless you know exactly how high the curbs are.

I'm a little spooked when I see Tesla FSD beta demos where the car plows right on ahead through slightly flooded streets as though there's nothing there. It makes me wonder whether it saw it and ignored it or just didn't see it. It's the same feeling I got this morning when someone was signaling me to go ahead at a flashing red light and FSD beta (12.6.4) went right on ahead. I wonder if it somehow saw the hand gestures, or if it just didn't see the flashing red light at all.

That's what makes all this stuff fun.

Any hardware or device driver engineer will tell you that every hardware problem, once shipped, is a software problem. :-) (Translation: Hardware bugs, once the hardware is in the wild, have to be fixed with a software workaround.)

Nothing in self-driving cars is a quick fix other than geo-blocking something. You have to train a visual or LIDAR recognition model to recognize the problem situation and then train the path finding model to flag it as a bad path. How hard that is for this particular case, I have no idea. And there's probably other stuff beyond that; I'm not an expert in this area.

Yeah, there's not enough crack in the world for that to make sense. The cost-to-orbit is well documented. Artemis 2: $4.1 billion for a launch that can lift 95 tons to LEO. SuperHeavy/Starship: $90 million for a launch that can lift 150 tons to LEO. Ignoring minor details (e.g. that nobody is willing to expend a SuperHeavy to do trans-lunar injection), the reality of the matter is that the cost per ton to orbit for NASA rockets is 72x what it is expected to cost for SpaceX rockets.

And that's consistent with Falcon Heavy costs, too, so you can't hide behind "Yeah, but SuperHeavy and Starship don't work yet", because unless your payload is huge, SpaceX is still almost two orders of magnitude cheaper.

That never made much sense to me. The power requirements and cooling requirements for a data center in the vacuum of space would be completely infeasible.

The most any commercial satellite has ever dissipated, as far as I know, is only low-double-digit kilowatts worth of heat. Three high-end NVIDIA AI cards per satellite would basically fully max out a typical satellite's heat dissipation, without factoring in any of the heat produced from communication hardware, energy storage, solar heating, or heat dissipation from the computer that's powering those GPUs.

A large data center would likely include one or more clusters of 100,000 GPUs, not three. A typical communications satellite is on the order of 220 square meters. Do the math, and you get 7,333,260 square meters, or 7.3 square km. This translates to a radius of .76 km, or a diameter of 1.52 km. Sure, it might not be not as dense as a meteor of that diameter, but it would still be really, really bad to deorbit something that size. I would not be surprised if the resulting dust cloud causes crop failures for years on a scale that would wipe out a sizable percentage of human life.

If, by data center, you just mean an edge cache like Cloudflare or Akamai, then it might be slightly more feasible, but even that is pushing the limits of my suspension of disbelief.

Why would you take macOS out? It's a full UNIX environment, complete with a command line.

Agreed.

What made Linux the most widely used and successful OS was Android. But Linux and *BSD have fairly similar numbers of installations. You have 2.5 billion Apple devices (mac, iOS, etc.) versus 4 billion Android devices, you have more iOT devices on Linux, but a LOT more commercial routers and switches and other hardware on *BSD. It's really hard to calculate, but the numbers are probably within +/- 20% of being the same.

The problem is, none of those devices really qualify as Linux in any meaningful sense. Sure, they run the kernel, but that's about it. The user-space tools that GPL had such a big influence on are not there at all. Take all the iOT devices and Android devices and Chromebooks out of the picture, and Linux ends up actually being less popular than *BSD (because of macOS).

So whether Linux is or is not the most widely used OS depends on how you measure it.

I don't see any real evidence for what you're saying. Linux succeeded more because it had better support for PC graphics hardware early on, and the *BSDs didn't get a chance to really catch up. And the AT&T-Berkeley lawsuit stalled BSD development and adoption during the early 90s as well. And the *BSDs were fragmented into multiple camps (386BSD forked into FreeBSD and NetBSD, and then NetBSD further forked into OpenBSD), while the only forking on the Linux side was over distros. The lack of a strong, central leader likely made a far bigger difference than anything else.

All of these things led to Linux having more people working on it early on, and ultimately, the group with the most developers wins. Maybe GPL got them slightly more developers, or maybe it didn't. There's really no way to know. But my guess is that for every extra developer who joined because of the GPL, there were two corporate developers who didn't join because of the GPL, so I highly doubt you are correct in your assessment.

At best, GPL made it harder (but not impossible) for hardware developers to ship closed-source drivers, which made it easier to keep supporting old hardware, which probably resulted in a slight increase in the thickness of the long tail of the user base. Whether this is a meaningful benefit or not is unclear, because it also comes with the extra overhead of continuing to support that long tail. :-)

No, statutory damages are per work. The minimum is $200 if the violator could show reasonable cause to have believed that the infringement was fair use, and the maximum is $150,000 in cases of willful infringement. The nominal range is $750 to $30,000.

To receive more than that requires showing actual damages. What this means is that even if there are a hundred GPLed projects whose licenses are being violated, short of proving willful infringement, apart from in injunction against further violations, the most they would likely get without showing actual damages is $3 million dollars, which is a slap on the wrist. And it's unclear how to show actual damages for something that you give away for free.

You *might* be able to make the claim that each new product line is a new infringement, but that's about the limit to what is realistic.

If you get proprietary software and then make a derivative work, you have violated copyright. It isn't just proprietary. It can't legally exist.

People use that term for licenses that meet a specific criterion — that using code under the license compels authoring other code under that license.

GPL and AGPL are viral, because when you use code under that license in larger projects, unless all integration occurs through a non-code interface (e.g. pipes), the larger project must be licensed under GPL or AGPL. In effect, code written under those licenses infects other code that you might want to link with them.

And it's even a problem in the open source world. There are open source licenses out there that are incompatible with GPL, such that you can't legally release a binary that combines the two. This is why, for example, unless something has changed recently, you cannot distribute a precompiled version of ffmpeg with all of the options turned on, because doing so with GPL bits turned on forces FFMPEG to be distributed as a whole under the GPL, and other open source components have non-reverse-engineering clauses that preclude their release under the GPL, which makes the resulting binary undistributable. Effectively, the GPL kills the patient at that point.

LGPL is not viral, because as long as you release any changes that you made to the LGPL code itself, you can link it with closed-source software. The same is true for *BSD and MIT and Apache licenses. These licenses don't infect unrelated code merely because of using the public APIs in those open source projects.

And I get that you don't think this is a problem, because you've drunk the whole Free Software Kool-Aid, but there's a reason I've been saying for more than two decades that using GPL for libraries is bad. Making it impossible to use a library in closed-source software does not harm closed-source software vendors, contrary to the FSF's beliefs. Rather, it causes those companies to cast aside the GPLed software and rewrite it.

And this is what almost always happens. If you write a library under GPL, someone will eventually need that library for a closed-source project, they will see the license, and decide to write a replacement. And after a while, it will become better than the GPL library that it replaced, because there will be a large number of people getting paid to do work on it, rather than it being someone's hobby project.

For an extreme example, we have only to look at compilers. For years, the FSF touted GCC as the crown jewel of GPL-licensed software. But a combination of being slow to upstream patches from commercial companies and an unwillingness to allow for integration of the core parser bits under a more permissive license eventually drove Apple to write their own compiler (clang) under a more permissive license. And now, clang-llvm outperforms GCC significantly, so much so that the latter is a legacy compiler outside of the Linux world, and is starting to gain real traction even in the Linux world.

Viral licenses really don't work. In theory, if it's a tool or application, GPL works great. It keeps people from creating a private fork, and keeps development out in the open. But it's also not meaningfully better than LGPL, though, because nobody links against an app. And the downside is that if somebody later comes up with an interesting use case for part of the app, but doesn't want to make that be open source for whatever reason, one of three things happens: they convince the original GPL code developers to relicense it (which is remarkably hard except for largely-single-contributor code), they rewrite it from scratch under a different license, or the idea dies as infeasible. See also GCC.

So I would argue that even for applications, it makes a lot of sense to use LGPL for everything except for the user interface code. License anything that could even potentially be used as a library under LGPL to maximize the potential for reuse while still keeping changes out in the open.

But I digress.

They still have those? I would have thought that everything was sent electronically by now, and nobody hand-entered anything except for bank tellers and other people who are dealing face-to-face with customers.

Then again, I remember how hard it was to do an international wire transfer a few months back, and how my bank faxed paperwork back and forth to their back office, so I guess that's plausible.

The unfortunate thing, though, is that for the most part, any use of AI to do that stuff is a mistake, because you should be shifting the burden of data entry (and thus the burden of correctness) to the customer by doing everything electronically to the maximum extent possible. The fact that banks use paper forms in the first place is the flaw, and replacing the person who types the contents of the form with AI is just replacing one error-prone, bank-at-fault process with another, when they should be shifting the liability for error to the customer. This also has the advantage of reducing the likelihood of error, because the customer had to fill all that info in on the form in the first place, so you have one opportunity for error instead of two. This also has the advantage of usually making it easier for the customer, because the customer doesn't have to do stuff in person. And so on.

Show me this software that you consider usable enough to replace more than about 5% of what a software engineer does.