For those interested, I did a breakdown of the hashbang: https://blog.foletta.net/post/2021-04-19-what-the/

Op here, no AI generated code, I'm wondering what gives the impression that it is?

I use Rmarkdown, so the code that's presented is also the same code that 'generates' the data/tables/graphs (source: https://github.com/gregfoletta/articles.foletta.org/blob/pro...).

If you say there's no AI-generated code then I retract the original comment, nice work.

Very much an inspiration and resource when composing the post.

Author here; I think I understand where you might be coming from. I find functional nature of R combined with pipes incredibly powerful and elegant to work with.

OTOH in a pipeline, you're mutating/summarising/joining a data frame, and it's really difficult to look at it and keep track of what state the data is in. I try my best to write in a way that you understand the state of the data (hence the tables I spread throughout the post), but I do acknowledge it can be inscrutable.

A "pipe" is simply a composition of functions. Tidyverse adds a different syntax for doing function composition, using the pipe operator, which I don't particularly like. My general objection to Tidyverse is that it tries to reinvent everything but the end result is a language that is less practical and less transparent than standard R.

Can you rewrite some of those snippets in standard R w/o Tidyverse? Curious what it would look like

I didn't rewrite the whole thing. But here's the first part. It uses the `histogram` function from the lattice package.

    population_data <- data.frame(
        uniform = runif(10000, min = -20, max = 20),
        normal = rnorm(10000, mean = 0, sd = 4),
        binomial = rbinom(10000, size = 1, prob = .5),
        beta = rbeta(10000, shape1 = .9, shape2 = .5),
        exponential = rexp(10000, .4),
        chisquare = rchisq(10000, df = 2)
    )
    
    histogram(~ values|ind, stack(population_data),
              layout = c(6, 1),
              scales = list(x = list(relation="free")),
              breaks = NULL)
    
    take_random_sample_mean <- function(data, sample_size) {
        x <- sample(data, sample_size)
        c(mean = mean(x), sd = sqrt(var(x)))
    }
    
    sample_statistics <- replicate(20000, sapply(population_data, take_random_sample_mean, 60))
    
    sample_mean <- as.data.frame(t(sample_statistics["mean", , ]))
    sample_sd <- as.data.frame(t(sample_statistics["sd", , ]))
    
    histogram(sample_mean[["uniform"]])
    histogram(sample_mean[["binomial"]])
    
    histogram(~values|ind, stack(sample_mean), layout = c(6, 1),
              scales = list(x = list(relation="free")),
              breaks = NULL)

The following code essentially redoes what the code up to the first conf_interval block does there. Which one is more clear may be debatable but it's shorter by a factor of two and faster by a factor of ten (45 seconds vs 4 for me).

    sample_size <- 60
    sample_meansB <- lapply(population_dataB, function(x){
 t(apply(replicate(20000, sample(x, sample_size)), 2, function(x) c(sample_mean=mean(x), sample_sd=sd(x))))
    })
    lapply(sample_meansB, head) ## check first rows

    population_data_statsB <- lapply(population_dataB, function(x) c(population_mean=mean(x), 
             population_sd=sd(x), 
             n=length(x)))
    do.call(rbind, population_data_statsB) ## stats table

    cltB <- mapply(function(s, p) (s[,"sample_mean"]-p["population_mean"])/(p["population_sd"]/sqrt(sample_size)),
     sample_meansB, population_data_statsB)
    head(cltB) ## check first rows

    small_sample_size <- 6 
    repeated_samplesB <- lapply(population_dataB, function(x){
 t(apply(replicate(10000, sample(x, small_sample_size)), 2, function(x) c(sample_mean=mean(x), sample_sd=sd(x))))
    })

    conf_intervalsB <- lapply(repeated_samplesB, function(x){
 sapply(c(lower=0.025, upper=0.975), function(q){
     x[,"sample_mean"]+qnorm(q)*x[,"sample_sd"]/sqrt(small_sample_size)
 })})

    within_ci <- mapply(function(ci, p) (p["population_mean"]>ci[,"lower"]&p["population_mean"]<ci[,"upper"]),
   conf_intervalsB, population_data_statsB)
    apply(within_ci, 2, mean) ## coverage

One can do simple plots similar to the ones in that page as follows:

    par(mfrow=c(2,3), mex=0.8)
    for (d in colnames(population_dataB)) plot(density(population_dataB[,d], bw="SJ"), main=d, ylab="", xlab="", las=1, bty="n")
    for (d in colnames(cltB)) plot(density(cltB[,d], bw="SJ"), main=d, ylab="", xlab="", las=1, bty="n")
    for (d in colnames(cltB)) { qqnorm(cltB[,d], main=d, ylab="", xlab="", las=1, bty="n"); qqline(cltB[,d], col="red") }

I mean, for the main simulation I would do it like this:

    set.seed(10)
    n <- 10000; samp_size <- 60
    df <- data.frame(
        uniform = runif(n, min = -20, max = 20),
        normal = rnorm(n, mean = 0, sd = 4),
        binomial = rbinom(n, size = 1, prob = .5),
        beta = rbeta(n, shape1 = .9, shape2 = .5),
        exponential = rexp(n, .4),
        chisquare = rchisq(n, df = 2)
    )
    
    sf <- function(df,samp_size){
        sdf <- df[sample.int(nrow(df),samp_size),]
        colMeans(sdf)
    }
    
    sim <- t(replicate(20000,sf(df,samp_size)))

I am old, so I do not like tidyverse either -- I can concede it is of personal preference though. (Personally do not agree with the lattice vs ggplot comment for example.)

Oh god, it wasn’t ASDM for the ASA was it? Always one Java update away from not being able to manage your firewalls

The direct peering to the router is likely going to have a bad time, but route advertisement interval I mention in the article is going to coalesce all of those updates together. Downstream peers would only see the one update every 30 seconds (or so).

That’s only true if they can be coalesced. Even with RPKI an intermediate transit router can path length flap 100,000 routes every 30 second interval.

Depending on the RA interval alone is negligence and if you encountered a small ISP that isn’t dampening your updates directly, their peering session is at risk with any of the major transit providers.

Route dampening guardrails were super common 7 years ago and there isn’t any technological development that fixes what they did so I highly doubt they fell out of favor.

Yup, unless that component has been disabled (which is quite rare) or the other side is bird, a bgpd that doesn't buffer anything !

See my adjacent comment to yours. I would like to see why you think dampening is out of favor. Interval batching is not an equivalent protection. If you were playing BGP battleships you were likely playing at a rate where a single prefix was not updating more than once per minute.

That wouldn’t land in the dampening levels that were normally configured that encountered with all of the transit providers.

First off, the HTTP HTTP 301s to the HTTPS site, so HTTPS is still the likely trigger.

Second, I see that whatever client he's using is specifying a very old TLS 1.0. If its not MTU (which others have mentioned), then my guess would be a firewall with a policy specifying a minimum TLS version, and dropping this connection on the floor.

Certainly weird that wireshark shows TLSv1 while curl shows TLSv1.3. That shouldn't happen unless something interfered with the Client Hello. (or the wireshark version is outdated)

Ran into this myself about 10 days ago.

If a TLS handshake is aborted partway through, Wireshark will label it “TLSv1”. It actually retroactively labels the 1.0 TLS packets as 1.3 after a successful TLS 1.3 handshake finishes.

This makes sense because a TLSv1.3 handshake actually starts as 1.0 and then upgrades to 1.3 only with IIRC the Server Hello response to the ClientHello.

The following links document this behavior, in case you or your organization’s security team is nervous TLSv1 is actually being used:

https://superuser.com/a/1618420

https://ask.wireshark.org/question/24276/how-does-wireshark-...

https://gitlab.com/wireshark/wireshark/-/issues/16114

Oh, indeed, that's quite surprising. A TLSv1.3 Client Hello always contains the supported_versions extension, which should allow wireshark to label it correctly, regardless of whether or not the handshake actually finishes. Though, tbf, it does say TLSv1 and not TLSv1.0. I wonder how it would look had TLSv1.3 been named TLSv2.0 after all...

edit: Ah, that GitLab link lead me to https://gitlab.com/wireshark/wireshark/-/issues/19515 which is a recent discussion around this topic and https://gitlab.com/wireshark/wireshark/-/merge_requests/1377... already dealt with it :)

I tried to do something similar: https://articles.foletta.org/post/git-under-the-hood/

Strength with empathy

Short answer is: it doesn't. When designing networks you will try to reduce the scope of layer 2 broadcast domains.

Right - the old rule of thumb used to be an Ethernet collision domain should have a maximum of five segments, with four repeaters, and three populated mixing segments (i.e. buses like 10BASE5 or 10BASE2), the other two segments being link segments (i.e. point-to-point like 10BASE-T or 10BASE-FL).

I think the idea was that anything more than this was likely to lead to long enough round-trip times between devices at the far ends of the Ethernet that the CSMA/CD algorithm couldn't be guaranteed to work.