Your statement would apply if these data center space nutters could certify that everything they launch will reach escape velocity.

For everything else, what goes up, must come down. Right back into our jurisdiction.

The military implications are obvious. Think Ukraine. If you suspect the enemy is trying to infiltrate on a dark night along several kilometers of frontline, you light up the scene while launching a bunch of low-cost FPV drones, and those infiltrators are about to have a bad day.

You *can* spot infiltrators in the dark with IR cameras, but it requires much more expensive drones and isn't usually as effective, hence the preference for night operations. Plus, there's IR camouflage, with varying degrees of success. But it usually makes you stand out like a sore thumb under illumination (you're basically wearing a tent).

This is a small prototype, not a full-scale mirror.

Also, ignoring that, pretending light brighter than the full moon is useless is... silly? For generating power, sure, but for illumination, it absolutely is not.

...that it's just New York City. Hopefully the idea will spread.

Laissez faire capitalism is great if everyone is honest. But in this reality there are a lot of incredibly dishonest people who will do anything for a buck. A modicum of base regulation is desirable to keep consumers from getting swindled at every turn. I applaud efforts like these.

We can't afford to let the success of big tech companies depend on the health of fragile meatbags. We need to get resilient, fault-tolerant AGI in there running the enterprise. Also, unlike meatbags, you don't need $100M stock payouts to convince an AGI to work as a corporate executive.

APFS supports compression, but it's the same compression techniques (deflate, LZVN, LZFSE) that HSF+ supports. And it seems to be a slightly higher-level approach to compression than ZFS uses, making it only mostly transparent compression. So newer techniques that ZFS leverages, like LZ4 or ZSTD, they're not an option. Compression is such a no-brainer with ZFS (particularly with how fast LZ4 and ZSTD can be) that more and more distros/operating systems are enabling it by default.

I think Apple should have converted to ZFS in the first place, APFS kind of feels like they decided to re-invent the wheel and missed out on some important stuff (like block checksums) in the process. I still think it's reasonable for them to drop HFS+ encryption support and tell people to convert the drives to APFS if they want to keep doing it, though.

What's stopping users from converting the drives from HFS+ encrypted to APFS encrypted? They have a process to do that in-place. People can keep using their existing drives, and can still have them encrypted.

Legacy systems aren't going to run macOS 28, since the last release to support Intel processors is macOS 26. This will only affect legacy archives, so, older external disks. Assuming they didn't use exFAT, but you didn't get native encryption in macOS with that either.

They've already dealt with this. If you read the fine print on these agreements, many or most of the recent ones say that the company has the option of rolling up any "substantially similar" arbitration cases into a single mass arbitration. (Which as usual, is decided by a person whose paycheck ultimately depends on the business of that same company.)

They're not removing encryption support, they have a modern filesystem that you can use with encryption. They're only dropping it from their deprecated 1990s-era filesystem. They're telling people to move to the modern filesystem if they want to use encrypted drives.

HFS+ was introduced with MacOS 8.1 in the late 90s. It doesn't even support dates past the year 2040. It makes sense for them to start phasing it out.

This is akin to altering the English alphabet such that quantity and shape of symbols in the alphabet is different before teaching students English

No, it's not. It's akin to having secret numbers (that correlate neither with the spelling or meaning of the word) associated with each word, and the only way you can learn the secret numbers is if e.g. someone says "The secret number for Strawberry is '3'."

There are no other "clues" available to the LLM. It cannot see the property in question (spelling). It is a hidden "magic number" for all effects and purposes.

as there are daily videos of people doing this exact shit?

Literally go to a non-tiny AI right now and try it. Your pick. Try all the major ones - ChatGPT, Claude, Gemini, Grok, your pick. Then share me a link to the failure case you're claiming you'll get. Don't worry, I'll wait.

(Note: tiny: the "Google Answers" AI is a truly minuscule model, the sort of thing you could run on a cellphone with ample capacity to spare, and is only representative of minuscule models)

how about the guy that put 3 AIs together and told them to count to 100?

Sounds like what you actually have a complaint about is the (non-AI) voice interface they're linked to, because that's what screwed them. That entire premise doesn't work at all if you remove it and just do the test in text. Again: try it yourself.

generally they fail at the balanced parenthesis problem

LLMs are way better than humans at ensuring that code parentheses are balanced, e.g. when writing code; LLM code is much more likely to compile / run on the first time than human code. There are literal parenthesis-counting circuits that emerge. That they're not perfect at it doesn't make them not be better than us at it. Humans tend to start to lose track after 3-4 levels of parentheses. LLMs have long since significantly outperformed us in nested grammatical tasks, so long as the level of training to the human and AI are at least remotely comparable.

Here is, internally, how models handle counting, despite not being able to see what they look at.

Also, your article is deeply dated, in terms of (A) models, (B) underlying articles, and (C) descriptions of how things work. Strange for something written in 2023; it reads like something written in 2020-2021. Just to give an example of what I mean, let's just grab a few paragraphs from the middle at random:

It operates in three basic stages. First, it takes the sequence of tokens that corresponds to the text so far, and finds an embedding (i.e. an array of numbers) that represents these. Then it operates on this embedding—in a “standard neural net way”, with values “rippling through” successive layers in a network—to produce a new embedding (i.e. a new array of numbers). It then takes the last part of this array and generates from it an array of about 50,000 values that turn into probabilities for different possible next tokens. (And, yes, it so happens that there are about the same number of tokens used as there are common words in English, though only about 3000 of the tokens are whole words, and the rest are fragments.)

A critical point is that every part of this pipeline is implemented by a neural network, whose weights are determined by end-to-end training of the network. In other words, in effect nothing except the overall architecture is “explicitly engineered”; everything is just “learned” from training data.

There are, however, plenty of details in the way the architecture is set up—reflecting all sorts of experience and neural net lore. And—even though this is definitely going into the weeds—I think it’s useful to talk about some of those details, not least to get a sense of just what goes into building something like ChatGPT.

First comes the embedding module. Here’s a schematic Wolfram Language representation for it for GPT-2:

The input is a vector of n tokens (represented as in the previous section by integers from 1 to about 50,000). Each of these tokens is converted (by a single-layer neural net) into an embedding vector (of length 768 for GPT-2 and 12,288 for ChatGPT’s GPT-3). Meanwhile, there’s a “secondary pathway” that takes the sequence of (integer) positions for the tokens, and from these integers creates another embedding vector. And finally the embedding vectors from the token value and the token position are added together—to produce the final sequence of embedding vectors from the embedding module.

Why does one just add the token-value and token-position embedding vectors together? I don’t think there’s any particular science to this. It’s just that various different things have been tried, and this is one that seems to work. And it’s part of the lore of neural nets that—in some sense—so long as the setup one has is “roughly right” it’s usually possible to home in on details just by doing sufficient training, without ever really needing to “understand at an engineering level” quite how the neural net has ended up configuring itself.

Unless this is awkwardly worded, it does not "find an embedding (i.e. an array of numbers) that represents [the input sequence of tokens]". Each token has its own embedding. And they don't need to be "found", they're just a lookup.

Values don't go “rippling through successive layers" in a LLM. The core of a LLM is dozens to hundreds of individual DNNs (feed-forward networks) separated by attention blocks and add+norm. He entirely writes this out of the picture (at this point - later he reinserts them but does so incorrectly), but they are utterly critical to a LLM's ability to function.

"A critical point is that every part of this pipeline is implemented by a neural network" - No, it isn't.

"nothing except the overall architecture is “explicitly engineered”; everything is just “learned” from training data" - No, it isn't. Creating your vocabulary for example is done with an algo like BPE or unigram. Not neural network based.

"Here’s a schematic Wolfram Language representation for it for GPT-2 .... 12,288 for ChatGPT's GPT-3" - I hope you understand how ancient these architectures are by now.

"Meanwhile, there’s a “secondary pathway” that takes the sequence of (integer) positions for the tokens..." - to the point that they don't even have RoPE yet.

"Why does one just add the token-value and token-position embedding vectors together? I don’t think there’s any particular science to this." - Uh, yes, there very much is. This isn't some sort of cargo-cult nonsense, it's a basic property of latent spaces. Information in a latent space (in most latent spaces) is encoded by directionality. You can merge multiple concepts into a latent space or adjust the properties of a given latent by summing them together, thus creating a vector that incorporates both directions.

Anyway, that's enough to show what I think of the quality of your reference, esp. in a modern setting. :P Moving on:

It's related to the clock problem

Multimodal input isn't as advanced as textual input, to be sure, but let's not pretend that the human brain isn't also readily tricked in various kinds of vision problems.

If you ask a neural network to recognize "A" then all As will be tokenized the same way

Sorry, that is, again, not how it works. Tokenization happens before the model ever touches the input. It's literally the first step. It has no say over how it's done. It can't say "tokenize this differently". Even the tokens themselves don't make it to the LLM; they only point to latent positions.