Okay, but it doesn't make sense to arbitrarily group together some results and compare the probability of getting any 1 result in that group to getting 1 particular result outside of that group.
You could just as easily say "you should be suspicious if you flip a coin 200 times and get exactly 93 heads, because it's far more likely to get between 99 and 187 heads."
It's suspicious when it lands on something that people might be biased towards.
For example, you take the top five cards, and you get a royal flush of diamonds in ascending order. In theory, this sequence is no more or less probable than any other sequence being taken from a randomly shuffled deck. But given that this sequence has special significance to people, there's a very good reason to think that this indicates that the deck is not randomly shuffled.
In theory terms, you can't just look at the probability of getting this result from a fair coin (or deck or whatever). You have to look at that probability, and the probability that the coin (deck etc.) is biased, and that a biased coin would produce the outcome you got.
If you flip a coin that feels and appears perfectly ordinary and you get exactly 100 heads and 100 tails, you should still be pretty confident that it's unbiased. If you ask somebody else to flip a coin 200 times, and you can't actually see them, and you know they're lazy, and they come back and report exactly 100/100, that's a good indicator they didn't do the flips.
> It's suspicious when it lands on something that people might be biased towards.
Eh, this only makes sense if you're incorporating information about who set up the experiment in your statistical model. If you somehow knew that there's a 50% probability that you were given a fair coin and a 50% probability that you were given an unfair coin that lands on the opposite side of its previous flip 90% of the time, then yes, you could incorporate this sort of knowledge into your analysis of your single trial of 200 flips.
You can certainly do the frequentist analysis without any regard to the distribution of coins from which your coin was sampled. I’m not well studied on this stuff, but I believe the typical frequentist calculation would give the same results as the typical Bayesian analysis with a uniform prior distribution on “probability of each flip being heads.”
I guess it depends on exactly what kind of information you want. Frequentist analysis will give you the probability of getting an exact 100/100 split in a world where the coin was fair. That probability is about 0.056. Or you can go for p values and say that it's well within the 95% confidence interval, or whatever value. But that's not very useful on its own. What we typically want is some notion of the probability that the coin is fair. This is often confused with the probability of getting the result given a fair coin (e.g. 5% probability X would happen by chance, therefore 95% probability that the null hypothesis is false) but it's very different. In this context, the question people are interested in is "how likely is it that Fleming/Mendel p-hacked their results, given the suspicious perfection of those results?" Analogous to "how likely is it that the coin is fair, given the exact even 100/100 split we got?" And for that, you need some notion of what unfairness might look like and what the prior probability was of getting an unfair coin.
Even if you shoot only once, you still have a higher chance of hitting something slightly off the middle than the perfect 100/100. And this because that's one point-precise result (100/100) vs. a cumulated range of individually less-probable results, but more probable when taken as a whole.
> you still have a higher chance of hitting something slightly off the middle than the perfect 100/100
That's because "something slightly off the middle" is a large group of possible results. Of course you can assemble a group of possible results that has a higher likelihood than a single result (even the most likely single result!). But you could make the same argument for any single result, including one of the results in your "slightly off the middle" group. Did you get 97 heads? Well you'd have a higher likelihood of getting between 98 and 103 heads. In fact, for any result you get, it would have been more likely to get some other result! :D
> But you could make the same argument for any single result
Isn't that the point? The odds of getting the "most likely result" are lower than the odds of getting not the most likely result. Therefore, getting exactly 100/100 heads and tails would be unlikely!
But as I said, getting any one specific result is less likely than getting another other possible result. And the disparity in likelihoods is greater for any one specific result other than the 50% split.
I think the disagreement is about what that unlikeliness implies. "Aha! You got any result? Clearly you're lying!"... I'm not sure how far that gets you.
There's probably a dorm-quality insight there about the supreme unlikeliness of being, though: out of all the possible universes, this one, etc...
Try thinking of it this way: you're in highschool and your stats teacher gives you a homework assignment to flip a coin 200 times. You respect her and don't want to disappoint her, but at the same time the assignment is pointlessly tedious and you want to write down a fake result which will convince her you actually did it.
A slightly imperfect split is more likely to convince your teacher that you did the assignment. Intuitively this should be obvious.
> "Remember, if you flip a coin 200 times and it comes heads up exactly 100 times, the chances are the coin is actually unfair. You should expect to see something like 93 or 107 instead".
Inverting the statement makes it read something like this:
You are more likely to not get 100/100 than you are to get exactly 100/100
...which is exactly what I was saying. Nobody is arguing that there is a single value that might be more likely than 100/100. Rather, the argument is that a 100/100 result is suspiciously fair.
In statistics, various examples (e.g., coin flips) often stand in for other activities which might prove expensive or infeasible to make repeated tries of.
For "coin flips", read: human lives, financial investments, scientific observations, historical observations (how many distinct historical analogues are available to you), dating (see, e.g., "the secretary problem" or similar optimal stopping / search bounding problems).
With sufficiently low-numbered trial phenomena, statistics gets weird. A classic example would be the anthropic principle: how is it that the Universe is so perfectly suited for human beings, a life-form which can contemplate why the Universe it so perfectly suited for it? Well, if the Universe were not so suited ... we wouldn't be here to ponder that question. The US judge Richard Posner made a similar observation in his book "Catastrophe: Risk and Response" tackles the common objection to doomsday predictions that all have so far proved false. But then, of all the worlds in which a mass extinction event has wiped out all life prior to the emergence of a technologically-advanced species, there would be no (indegenous) witnesses to the fact. We are only here to ponder that question because utter annihilation did not occur. As Posner writes:
By definition, all but the last doomsday prediction is false. Yet it does not follow, as many seem to think, that all doomsday predictions must be false; what follow is only that all such predictions but one are false.
-Richard A. Posner, Catastrophe: Risk and Response, p. 13.
Barging in as a Linux guy interested to learn more about the BSDs, so please bear with me.
Something I love with systemd is how I can get very useful stats about a running process, e.g. uptime, cumulated disk & network IOs, current & peak mem usage, etc.
Also the process management (e.g. restart rules & dependency chain) is pretty nice as well.
Is that doable with RC (or other BSD-specific tooling) as well?
It's up to you to say check in your init script if you need to start another service before you.
In terms of uptime or IO and stuff, those metrics are already available. Be that via SNMP or other means. Say you start an nginx in systems, which network and disk usage does it report? Just the main process or all its forks? Same problem in RC.
But that is part of the point. Why in the ever-loving existence should an INIT system provide stats like disk usage? That is NOT what an init system is for.
If you need memory usage or IO usage or uptime, there are so many other tools already integrated into the system that the init system doesn't need to bother.
Init systems should only care about starting, stopping and restarting services. Period. The moment they do more than that, they failed at their core job.
This might came across stronger than meant to, but still holds true.
BSDs are about "keep it simple, keep it single purpose" to a "I can live with that degree". What you get though is outstanding documentation and every component is easily understandable. Prime examples are OpenBSD/FreeBSD PF. That firewall config is just easy to grok, easy to read up on and does 99.999% of what you ever need out of a firewall.
> which network and disk usage does it report? Just the main process or all its forks? Same problem in RC.
Well, the main process and its whole hierarchy, that's what you would expect of an init system monitoring its services, right? And what's nice with systemd is that I can get that from a simple `systemctl status my-service` – of course I could deploy a whole observability stack, but better if I can avoid it.
But there is no need to be defensive, it RC can that's nice, if it can't, then well, too bad.
> there are so many other tools already integrated into the system that the init system doesn't need to bother.
That's what I'd love to hear about, what are the equivalent in the BSDs world.
Best practice would be to pack the service into a jail and then use `ractl` to monitor I/O. Could also then monitor the VNET socket of the jail for network stats.
Or you just grab the PID and get it through that. A bit more manual, but composable.
Spin up a VM, may that be locally or a cloud VM, throw an OpenBSD or a FreeBSD. If you are into mail servers, static http etc then OpenBSD might be your jam. Or try FreeBSD and Jails. Jails are absolutely fantastic.
Ditch the LLMs (not insinuating that you use them, but just in case), try to use the Handbooks and the man pages.
If you ever feel the need that you have so many interdependent services that you need something more complex than RC, then you might have an actual architectural problem to be honest.
>If you ever feel the need that you have so many interdependent services that you need something more complex than RC, then you might have an actual architectural problem to be honest.
Not really familiar with TS, but what would be so weird with the typing? Wouldn't it be generic over `T -> U`, with T the type with snake_case fields and U the type with pascalCase fields?
Turns out in TypeScript you can model the conversion of the keys themselves from snake_case to pascalCase within the type system[0]. I assume they meant that this was the difficult part.
The issue is, as it stands, LLMs are going to become a commodity. Could that happen and OAI is still a valuable firm? Maybe. Do I personally think OpenAI has the product prowess to pull it off? Nah, I think they are overly-concentrated with technologists (same problem Google has). Apple is still king when it comes to figuring out the ideal form of the product the buyer desires.
Apple can take a future OSS model and produce the winning product. That truth would be very bitter for many to swallow. Cook maintaining good relations with China could be the thing that makes Apple topple everyone in the long-run.
> They also didn’t face the brunt of European colonialism.
But they faced the brunt of Chinese & Japanese colonialism, and a full-blown civil war after which their GDP per capita was in the same ballpark as Kenya's.
But the summed probability of the “not too far away results” is much higher, i.e. P([93, 107]\{100}) > P([100]).
So if you only shoot 100/100 with your coin, that's definitely weird.
reply