The predictable cost, you mean, making business planning way easier? And you usually have two, because sometimes kernels do panic or whatever.

People will have to come up with something else besides "le acronym from le computer makes my domain sound le computery, even though there is no cognizable relationship to I/O whatsoever", I guess. (Just kidding, it'll be around forever)

No it isn't, their strategy is great at increasing the rate at which they select those deadly "bad hires". There's just an insane amount of risk in doing these sorts of tech interview things; code up a quick monte carlo simulation to convince yourself if you like. It's just that the risk doesn't fall on the improperly aligned humans conducting the interview, it's offloaded onto the company.

Exactly, you could just as easily hire a bad candidate because they got lucky, and this happens all the time.

I think all the listed reasons are good reasons to delete tests. I like to keep the test suite running in a single-digit number of seconds. (Sometimes a test you really need takes a while, and you can skip it by default and enable it on the CI test runner or whatever.)

Another one I really agree with is "What if your tests are written so that a one line code change means updating 150 tests?". If you update a test, basically, ever, it's probably a bad test and is better off not existing than being like that. It's meant to distinguish main code with errors from main code without errors; if it must be updated in tandem with main code, it's just a detector that anything changed, which is counterproductive. Of course you're changing things, that's why you fenced them with tests.

Yeah. I would say, do get a better CPU, but do also research a bit deeper and really get a better CPU. Threadrippers are borderline workstation, too, though, esp. the pro SKUs.

Threadrippers are workstation processors and support ECC, Epycs are servers and the 9950X is HEDT (high end desktop).

Standard Ryzen chips also support ECC (minus the monolithic G models).

I run 2x48GB ECC with my 9800x3d.

Yes, but it's not tested or certified.

It's certainly less untrustworthy than running non-ECC anything.

Perhaps, but computer makers talk about "(engineering) workstations", they mean powerful machines that are meant to run professional apps like CATIA, and are certified by the makers of said software. If you're Airbus, you are not going to take chances running mission-critical design software on anything less. AMD's product for that market niche is Threadripper or EPYC, and Intel's is Xeon-W.

No. The form doesn't translate, and English-language haiku is a different form inspired by the Japanese form. Kireji as such are one of the elements that don't translate, though you can of course attempt a poetic structure inspired by kireji.

I think GPT-5's backlash was the beginning of the end of the hype bubble, but there's a lot of air to let out of it, as with any hype bubble. We'll see it for quite some time yet.

So all this arose because you didn't read the docs and note that get_disk_info/1 immediately fetches the data when called? The every-30-minutes-by-default checks are for generating "disk usage is high" event conditions.

Thanks, that was not clear to me from skimming the docs.

However, this NIF also returns more fields than the disksup function.

There's really not more that's useful to say than the relevant section (4.4) of Joe Armstrong's thesis says:

>How does our philosophy of handling errors fit in with coding practices? What kind of code must the programmer write when they find an error? The philosophy is let some other process fix the error, but what does this mean for their code? The answer is let it crash. By this I mean that in the event of an error, then the program should just crash. But what is an error? For programming purpose we can say that:

>• exceptions occur when the run-time system does not know what to do.

>• errors occur when the programmer doesn’t know what to do.

>If an exception is generated by the run-time system, but the programmer had foreseen this and knows what to do to correct the condition that caused the exception, then this is not an error. For example, opening a file which does not exist might cause an exception, but the programmer might decide that this is not an error. They therefore write code which traps this exception and takes the necessary corrective action.

>Errors occur when the programmer does not know what to do. Programmers are supposed to follow specifications, but often the specification does not say what to do and therefore the programmer does not know what to do.

>[...]

>The defensive code detracts from the pure case and confuses the reader—the diagnostic is often no better than the diagnostic which the compiler supplies automatically.

Note that this "program" is a process. For a process doing work, encountering something it can't handle is an error per the above definitions, and the process should just die, since there's nothing better for it to do; for a supervisor process supervising such processes-doing-work, "my child process exited" is an exception at worst, and usually not even an exception since the standard library supervisor code already handles that.