All true, but it's worth pointing out that if the Starship lander succeeds it will enable us to do a lot more, a lot faster. The whole "15 refueling flights for every moon trip" seems kind of crazy on its face, but if you look at the costs (assuming Starship works and become fully reusable), it makes the total cost per kilogram delivered to the surface of the moon insanely low and enables comparatively massive payloads to be delivered.

Big risk, big (potential) reward. Running both the Starship and Blue Moon projects in parallel is probably a good risk mitigation strategy, but if Starship succeeds completely, Blue Origin's lander will be a relic. Of course, it's also possible that Starship will just fail, or that it will succeed but be difficult to man-rate, in which case it may become the delivery service for lunar cargos, while people fly on Blue Moon.

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.

Basically, violence in the Middle East started on a significant scale with the collapse of the ecosystem. Natural climate shifts in the area reduced food available and regions that were inhabitable. This resulted in massive population migrations (the Sea People, the Babylonians, etc). As natural resources were depleted and became highly centralised, violence became worse. The collapse of the tin market resulted in Dark Ages for many cultures in the region, where societies imploded catastrophically.

As wealth increased, corruption increased. We know all about a copper merchant in Babylonian times, but it was unusual enough that he wrote a long and rambling letter in cuneiform about it. These sorts of complaints weren't common but increased. Corruption requires chaos, and chaos generates conflict. So this relationship should not be surprising. It's not that corruption causes violence, but corruption and violence have the same cause and are tightly coupled.

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.

Fair, though my data -- and Play purchases -- were my bigger concern when they first started talking about just ending legacy GSuite.

You must have signed up to change over before they backed off. They announced that everyone would have to switch and pay, but I waited because I didn't think it would stick, and it didn't. I have about 25 users on mine, so paying wasn't really feasible.

I searched for it and found it. I can't check now; I left Google last year.

That's fake news, actually. A very widespread misunderstanding, but incorrect regardless.

What Google actually did was move "Don't be Evil" from the introduction of the code of conduct to the summary at the end.

It's a widespread but inaccurate belief that Google kills everything. If you look closer, there's a distinct pattern to what they kill and what they keep, and it's mostly based on adoption. If a Google service -- free or paid -- has 100M+ monthly active users, it won't be killed. That number is a guideline, not a hard requirement. If it appears that a service is on track to attain that sort of "Google-scale" user base, and it has some monetization mechanism (usually a place to put ads), then it will survive.

Paid services are a little different. Google is much more reluctant to kill any service that people are paying money for. That's not to say they won't do it, but they're less likely to, and if they do they'll bend over backwards trying to make it right. Stadia is a good example. Stadia didn't get enough adoption to be worth Google's time/effort, so they killed it... but they refunded every penny of what the users had spent on hardware, monthly subscription fees, game purchase fees, etc. I still have (and use) the rather nice Stadia controllers I got for free. I'd rather have kept the service, but I definitely don't feel like I was ripped off.

There's no free option for new signups. Lots of us who set this up still have the legacy free G-Suite accounts. I'm not sure what triggers the "you might be using this for a business" check. My family is still using mine and Google isn't telling me we're a business.

The biggest problem with it, frankly, is that Workspace accounts have lots of restrictions that regular gmail accounts don't have. There's lots and lots of stuff that just doesn't work, and the list is growing year by year. This isn't specific to the legacy accounts, though, it's all Workspace accounts, because Workspace is intended for business use. I've had to migrate various things to a personal gmail account, even though I'd really rather keep it all on my primary account (which is a legacy G-Suite/free Workspace account).

The "upgrade path" thegarbz mentioned is mostly that you can convert your legacy G-Suite account to a regular Gmail account, porting all of your data, Google Play Store purchases, etc., over to it. That won't have a custom domain, but if you want to keep your custom email address you can use one of many services (probably not free, but quite cheap) to forward.

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.