No. The Chinese have already developed frontier models. And we would be fools to assume that's a permanent end to the list. North Korea has nuclear weapons. Iran has ballistic missiles and leading edge military drones. There is no fundamental reason why both countries shouldn't be able to train frontier AI models.

Trying to protect ourselves by putting restrictions on the technology would be like trying to hide from a tiger by wrapping a towel around our heads on the basis that if we can't see it then it can't see us. That trick only works on imaginary monsters, not real ones.

I haven't used Proton, but based on my experience with other cloud storage products and seeing other people's reports thereon, it looks to me like you are running into the problem that there are two different use cases for them with opposite requirements:

1. Local storage is cheap, I have lots of it. I want multiple copies of my data so that they will serve as backups. I want everything in the cloud to be copied locally. (I'm in this category.)

2. Local storage is cheap if you look at the price of external hard disks, but my phone or tablet only has a limited amount of it, and no way to upgrade without buying a whole new device, so it is scarce for me. I want nothing in the cloud to be copied locally, unless I am specifically using it on this device. (Sounds like you're in this category.)

Half the people think the first use case is the obvious one. Half the people think the second is the obvious one. And that includes developers, who will design the product accordingly without giving it much thought. So either half the users get a nasty surprise in the form of running out of disk space, or the other half risk an even nastier surprise in the form of data loss.

Obviously, computers pester us with too many questions these days, but I think this is one case where the software really does need to ask the user which behavior they want. Perhaps with a hint based on how much local disk space seems to be available.

Yes, I think that's what the paper is saying. The validation is the hard part, but the part that provides the value, because it's what makes the result actually useful.

Eh.

There are certainly things wrong with today's economy, starting with housing being treated as a financial asset, which encourages laws that create an artificial scarcity of it. I'm not saying there is nothing to complain about.

But the fact that not everyone is working purely to create necessities, that some of our economic output consists of luxuries? I don't really see that as a problem to be solved. If anything, I think it's a good sign. Let's not fall into the trap of just randomly complaining about everything.

The one way I know of for denormals to arise in real calculations is when you have a process that converges on zero. In which case, values will pass through the denormal range on the way from the normal range down to zero. And converting denormals to zero is obviously correct.

What other cases have you seen of denormals arising in real calculations?

If you compute a limit numerically, the decision that you have reached the limit must normally be taken long before there is any possibility of underflow, i.e. of generating denormals.

Typically you compute the difference between 2 adjacent terms of the convergent sequence and you decide that you have reached the limit when adding the difference to the current term to get the next does not change it (or when the relative error is smaller than some threshold). At this time the difference will still be many orders of magnitude greater than a denormal.

If the limit happens to be zero, then what you describe can happen. The programs where this can happen normally combine two different criteria to decide that the limit has been reached, i.e. that either the relative error is small enough, i.e. like I said that adding the difference to the previous term does not change it, or that the absolute error is small enough, i.e. that the difference is smaller than some threshold. The absolute error used as threshold is normally chosen based on what is physically meaningful in that problem, i.e. depending on what kind of physical quantity corresponds to the values of the terms of the convergent series.

An example of applications where the users must configure both relative errors and absolute errors, to be used as criteria of convergence, are the SPICE-like programs used to simulate electronic circuits, where the user must configure both a generally-applicable relative error, and absolute errors for different kinds of physical quantities, e.g. an absolute error for voltages and an absolute error for electric currents, which will be used, respectively, when a sequence of voltages converges towards zero or a sequence of currents converges towards zero, so that the absolute error criterion will be satisfied before the relative error criterion is satisfied.

In any case, in a correct program the attempt to find the limit should always stop before underflows become possible, so denormals should never be generated if the underflow exceptions are masked.

Denormals can appear in a lot of cases when almost equal values are subtracted, e.g. in the solution of many kinds of badly conditioned equations, but in most such cases there may exist alternative formulae that avoid underflows, i.e. the generation of denormals.

In general, when denormals appear, this signals bugs in the program, which must be investigated and fixed. The purpose of denormals is to allow the programmer to not fix the bugs, without causing catastrophic errors, like those that can happen when underflows generate null results, i.e. when "denormals are flushed to zero".

Careful programmers should nonetheless fix any bugs that generate denormals.

Ah! So let me paraphrase to make sure I understand. In your experience, the real use case of denormals is not that you want to compute with them. It's that they are a useful error signal, because they typically indicate that the equations are badly conditioned, which means the results cannot be trusted. So in that scenario, silently flushing them to zero is bad, but so is silently computing with them. What you really want is for denormals to raise an exception?

They are indeed a useful error signal, like also infinities or NaNs.

Moreover, they are much more benign than infinities or NaNs, which signal bugs that you most likely have to fix.

Denormals cause only very small errors, which may be acceptable in most applications. Therefore you may choose to ignore such bugs and not fix them, because a modified algorithm that avoids underflows may be significantly more complex than the original algorithm.

Configuring the non-standard option to flush denormals to zero is bad for two reasons. Not only it removes evidence that something bad has happened, but unlike with denormals, this can cause huge errors, even infinite errors.

When the operations are done according to the IEEE standard, every operation has a limit for the relative error and it is possible to do a numeric analysis of some computational algorithm and estimate the maximum errors that can affect its results.

When underflows generate neither exceptions nor denormals, all guarantees are removed and you can no longer predict anything about the final errors of an algorithm.

Because they believed only a small fraction of customers would care a lot about a better Basic interpreter, whereas the vast majority would care about price. As for giving things away for free, Commodore was already engaged in a cutthroat price war with Texas Instruments that almost sank the company. They could not afford to give anything else away for free.

I didn't know about that event. What did he say to get booed that time?

I looked into that, concluded the spoiler is Specter.

Basically, you have to have out of order/speculative execution if you ultimately want the best performance on general/integer workloads. And once you have that, timing information is going to leak from one process into another, and that timing information can be used to infer the contents of memory. As far as I can see, there is no way to block this in software. No substitute for the CPU knowing 'that page should not be accessible to this process, activate timing leak mitigation'.

OTOH, out of order/speculative execution only amounts to information disclosure. And general purpose OS's (without mandatory access control or multilevel security, which are of mere academic interest) were never designed to protect against that.

A far greater problem is that until very recently, practical memory safety required the use of inefficient GC. Even a largely memory-safe language like Rust actually requires runtime memory protection unless stack depth requirements can be fully determined at compile time (which they generally can't, especially if separately-provided program modules are involved).

Happy new year from Ireland!

Sure. If you feel the need to write "this is shitty code", fair enough, I'm fine with making allowances for that kind of language. But please leave it at that, instead of also insulting the people who wrote it. There are, unfortunately, plenty of ways for bad incentives to result in competent people creating bad products.