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.

Depends on what you mean by AI. If you mean specialized trained models that do very specific things (e.g. optimizing just-in-time component purchases or using computer vision to make robots work more effectively, making stock picks, spotting tumors on scans, and optimizing ad spend to get the best results), then yes. If you mean LLMs, I think you missed the mark with your list (except maybe ad creation; that's plausible).

LLMs are great for automating trivial work as long as there's no high financial cost for mistakes. Chat bots to help you search for products on a website better are a great example. Or LLMs to help you write the skeleton for new code or help you write unit tests (as long as you check the results). Or LLMs to help you look for bugs in code or review code before submission. Or LLMs to help you create prototypes of new software while deciding what approach you want to take. Or LLMs to quickly create artwork for fun, where you don't care if there are extra fingers.

LLMs are not great when there is high risk. Chat bots for airline customer service are a great example. Turning LLMs loose writing code without a competent programmer looking over its shoulder is another good example.

In between are the use cases where it functions adequately, but may not save much time, because the overhead of reviewing its work adequately is a sizable percentage of the time required to do the work by hand. Writing real-world production code is a great example.

Presumably it will get better over time. But whether it will ever reach a level of trust where we can turn it loose to write code and not carefully scrutinize that work, I couldn't say. Right now, there's too much risk of it saying that tests pass when they actually haven't been run, or worse, when the AI has decided to delete the tests so that they won't fail. There's too much risk of gaslighting across the board. There's too much risk of AI subtly misinterpreting prompts in extremely creative ways to give you results that look like they are correct but are actually wrong. And so on.

I'm going to assume for the moment that the C-suite at Meta are not complete and utter morons. So from this, we can conclude that Meta is firing people not because they actually believe AI will do their jobs, but rather because they don't have enough revenue to pay for their AI hardware costs, and they're hoping that they can get away with counting on their near-monopoly on social media to let them safely unstaff large parts of Facebook, Instagram, and other services in the short term so that they can build their data centers.

And while that might be true (because the DOJ let Facebook get way, way too big), that's a stock price disaster waiting to happen. It's risking throwing away the whole company to spend more money on Facebook's LLM technology, which might still never be good enough for them to actually make money at it. It made sense to do that work up to a point, because they could benefit from it internally for things like abuse detection. But trying to productize it without adequate rounds of funding is a mistake. If they truly think their tech is up to snuff, they should spin it off into a separate subsidiary and do rounds of financing to pay for the cost, with separate stock offerings.

Except it's not a concerning issue. Hantavirus doesn't spread well from human to human except when in close quarters (e.g. cruise ships). When you do the math based on the number of people on the ship, the likely R_0 would be *way* less than one out in the real world. So realistically, if they had evacuated the cruise ship after the first case, most of the people who got sick wouldn't have gotten sick, and you'd have at most maybe one or two cases in people who weren't on the ship, and that's about the realistic limit to its spread.

I don't remember the exact numbers I came up with, but it was something laughable like an R_0 of 0.15 or something.

It's a human interest story, because folks felt for the people trapped on that ship, but it was not a meaningful public health threat given the numbers involved.

It of course works to some extent. It doesn't work to an extent that it can replace a meaningful part of engineer time, though it can certainly be used for rapid prototyping and other special cases.

Most of engineers' time isn't spent writing code. It is spent reviewing code and understanding the code. When a person writes code, they are doing this while they write the code. When AI writes the code, that time is spent on the back end while reviewing the code. This is actually more mentally intensive than writing the code to begin with, because you're having to concentrate much more continuously. This means it takes longer, on average, and you're much more likely to make mistakes and miss critical errors during the review process, because you're trying to shove all of that mental effort into a much smaller amount of time. So you save a lot of time up front, and you pay back nearly all of that time at the end.

Until such time as AI can write perfect code that doesn't require human review, the review process will continue to be the bottleneck, and I'm not seeing any evidence that AI is approaching that point.

AI is great for creating demos that you're going to throw away and rewrite a dozen times. Teams that are playing with ideas for new features can potentially generate a lot more prototypes quickly by using AI. But they're saving time precisely because it's throwaway code. As soon as you're trying to use it for production code, the savings evaporate. Or at least this is what I have seen pretty consistently.

This is not to say that AI is useless for coding. When used as a glorified autocomplete engine, it can save you from a lot of tedious busywork. When used for code review, it at least has the potential to catch interesting bugs before they make it into production. And so on. But the notion that this will suddenly allow for cutting a large percentage of programmers is utterly naïve. Given their previous cuts, they've already exceeded the expected payoff from AI. So blaming this on AI savings isn't realistic.

So the real question is whether they'll be able to get their AI tech up to the quality and scalability level where they can survive on only that revenue before their social media platform craters from inadequate resourcing.

It's the dream of sociopathic greedy billionaires everywhere. Too bad for them that it's a pipe dream.

Here's the harsh reality: AI doesn't work. You can spend days cajoling AI into doing something correctly and spend days reviewing the bad code over and over until it gets it right or you can spend days writing the code. On average, the time savings are minimal, and the cost in terms of code understanding is enormous, resulting in less and less maintainable code over time until you eventually end up having to throw the whole thing away and rewrite it from scratch at an enormous cost.

Mind you, Meta was probably at the point where their whole code base needed to be thrown away and rewritten from scratch at least five years ago, given the level of bugginess that I've seen, so maybe AI lets them extend the long tail of badly written code a bit longer before they completely implode, but that's hardly a position for other execs to aspire to.

They won't. They'll have a bumpy few months followed by mass attrition from the complete destruction of employee morale, followed by panic when they realize that they don't have enough remaining employees to keep the lights on adequately, followed by even bigger panic when they realize qualified candidates aren't even bothering to apply for their open positions.

Nobody wants to work for a dying shell of a company that laid off a third of their workers over only a couple of years. As a company, if you're not innovating and growing, you're dying. Meta is dying. Their AI is basically worst-in-class at this point, and everything else is getting shoved aside to make more money for that latest boondoggle, because their execs don't know how to recognize a sunk cost fallacy.

It would take a literal miracle to save Meta from the death spiral that this will cause. If I owned Meta stock, I'd be selling in a hurry right now, or at least selling covered calls to buy protective puts to limit my losses. Stick a fork in it. They're done.

They drag them to school, but at that point, there's a record, and if it keeps happening, it becomes a legal problem for the parents, who have a responsibility for making sure their kids go to school.

To a school that is under-funded in part because kids aren't meeting the minimum attendance for the school to get paid.

All of those things are the responsibility of their parents. Those are adult problems for adults to solve. Kids can't realistically solve them, and can't reasonably be expected to solve them. And as soon as you let kids try to solve them, you're reinforcing the cycle of poverty by preventing them from getting the education that would enable to them to break that cycle. I'm not saying it's fair or good, just that preventing such things is better than the alternative, where we have child labor who grow up to be adults who earn minimum wage or worse.

Chronic illness is rare, and at some point, you try to figure out a way to get the kid tutoring.

I see what you did there.

If half your kids are chronically sick, there's something wrong with your school — environmental issues like mold, social issues like bullying, or senioritis like Bueller.