ptomato

... I realize I'm a monster, but aren't y'all already extensively using BPF for things? Sticking in a BPF egress filter on the VM that rewrites outbound DNS packets with .internal in the question to point at your DNS server seems like it would be lighter weight than just handling all queries recursively.

> we just had several trillion dollar stimulus bills that could've given every person in the country a million dollars

damn, didn't know covid killed 99% of the US population. rough.

I'm pretty sure it's explicitly intended solely as punishment for people who have javascript enabled.

if it's a model that supports Unleashed, you can also convert them to the Unleashed firmware without a contract.

Ruckus Unleashed is what you're looking for.

> it can see all the packets on the local network

I'm sure those packets (consisting entirely of OpenSSH) will be very useful to them

rsync.net's zfs as a service is really great for that, though a bit more expensive than b2 is.

Not having been previously familiar with fly's network setup, I gotta say I find it delightful; derived-prefix IPv6 + WG to give you basically static routing + ability to auth on IP is very elegant. I've actually been working on a toy stupid-simple clustering thing that does something similar, and I'm absolutely going to steal the userspace tcp stack over wireguard thing for API access.

I do find it odd how many people would apparently support Bezos or another random billionaire raising a private army and taking over 20-odd african countries with it (you know, the necessary prerequisite to _actually_ ending world hunger), but it takes all sorts I suppose.

not currently, though there's some people working on that.

https://github.com/firecracker-microvm/firecracker/issues/11...

ARM claims X1 has about 30% better integer perf than the A77; given how the A77 performs in Snapdragon 865, that would mean the M1 is only about 45% faster single core than the X1.

Graviton 2 single core performance afaict is about the same as the best Qualcomm has to offer currently (though obviously AWS is putting a lot more cores in a chip), and the M1 is about 1.8x-2x as fast as both of those (based on SPEC2017)

With about 1/4 of the single-core performance, per geekbench. (Only one xavier benchmarked, but considering even the highest-end non-Apple arm chips are a bit over 1/2 of the single those are probably realistic numbers).

If you have or are willing to create a gmail account, yes.

> that the autocomplete in Google will never autocomplete "kill all" with a particular group of people

except "men", which it does currently.

Yes, we absolutely should stop doing any business with both Saudi Arabia and China, both of which are brutal murderous totalitarian regimes.

Failing that, however, considering the two options for global social networks are precisely limited to

a) there are no global social networks b) there are global social networks but only ones that are directly controlled by the CCP

I'm pretty alright with a).

Yeah, I'm at 5120x1440 on a 49" ultrawide, and I'm not really interested in ever going back to a multi-monitor setup to get the same amount of real estate.

I found the thumb cluster borderline unusable on the Ergodox. The Keyboardio Model 01, which is my daily driver now, has a somewhat similar layout but excellent positioning on the thumb cluster and modifier button.

> vast majority of whom ... haven't actually been convicted of a crime

This is a straightforward lie.

Rereading that comment I do think I was being uncharitable and have removed it.

Reading the esbuild discussion at the time, it definitely read to me as "our language is definitely faster and if you're not getting the same performance you're holding it wrong", but looking at it now I can see how it wouldn't be intended that way.

Regardless, sorry; I think I was projecting some frustrations with the wider RESF on to you.

- (removed by author; was too aggressive)

> For various reasons, but nothing fundamental.

"Hardware vendors being unwilling to make the drivers they write open source" is a pretty fundamental reason.

Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? I don't think that realistically there's a third option. The open source community is not, for example, going to make their own high performance gpus.

If he's (reasonably!) not happy with Lenovo's build quality, he's absolutely not going to be happy with Clevo.

So that number includes (and is almost certainly dominated by) the cost of their office space.

yeah, blake3 multi-threaded is about 11 times faster for me than sha256 single-threaded.

Any individual build they're referencing there runs on a single vm (the cluster referenced there is the k8s cluster being built up and torn down on that vm to run e2e tests on). It looks like at the time they were using GCP standard-8 instances, which are 4 core/8 thread w/30GB of ram. It's hard to say exactly what the current build time is, as it looks like they do some build caching now; on my desktop a fully clean build of current kubernetes master (3.2 million loc) for linux/amd64 takes just under 2 minutes.

That's compiling for 10 os/arch combos, so ~3m per.

> already great native tools

This really is not the case. The closest thing is btrfs, which has a more limited feature set and a justified reputation for eating data; it's impossible to do a safe equivalent of e.g. a raidz2 pool with it

  Benchmark #1: cat b1
    Time (mean ± σ):      1.076 s ±  0.007 s    [User: 5.3 ms, System: 1069.4 ms]
    Range (min … max):    1.069 s …  1.093 s    10 runs
  Benchmark #2: sha256sum b1
    Time (mean ± σ):      6.583 s ±  0.064 s    [User: 5.440 s, System: 1.137 s]
    Range (min … max):    6.506 s …  6.695 s    10 runs
  Benchmark #3: sha1sum b1
    Time (mean ± σ):      6.322 s ±  0.086 s    [User: 5.212 s, System: 1.103 s]
    Range (min … max):    6.214 s …  6.484 s    10 runs
  Benchmark #4: b2sum b1
    Time (mean ± σ):     13.184 s ±  0.108 s    [User: 12.090 s, System: 1.080 s]
    Range (min … max):   13.087 s … 13.382 s    10 runs
  Benchmark #5: b3sum b1
    Time (mean ± σ):     577.0 ms ±   5.4 ms    [User: 12.276 s, System: 0.669 s]
    Range (min … max):   572.4 ms … 587.0 ms    10 runs
  Benchmark #6: md5sum b1
    Time (mean ± σ):     14.851 s ±  0.175 s    [User: 13.717 s, System: 1.117 s]
    Range (min … max):   14.495 s … 15.128 s    10 runs
    
  Summary
    'b3sum b1' ran
      1.86 ± 0.02 times faster than 'cat b1'
     10.96 ± 0.18 times faster than 'sha1sum b1'
     11.41 ± 0.15 times faster than 'sha256sum b1'
     22.85 ± 0.28 times faster than 'b2sum b1'
     25.74 ± 0.39 times faster than 'md5sum b1'

gotdang that's some solid performance. (here running against 10GiB of random bytes; machine has the Sha ASM extensions, which is why sha256/sha1 perform so well)

edit: actually not a straight algo comparison, as b3sum here is heavily benefiting from multi-threading; without that it looks more like this:

  Benchmark #1: cat b1
    Time (mean ± σ):      1.090 s ±  0.007 s    [User: 2.9 ms, System: 1084.8 ms]
    Range (min … max):    1.071 s …  1.096 s    10 runs
   
  Benchmark #2: sha256sum b1
    Time (mean ± σ):      6.480 s ±  0.097 s    [User: 5.359 s, System: 1.115 s]
    Range (min … max):    6.346 s …  6.587 s    10 runs
   
  Benchmark #3: sha1sum b1
    Time (mean ± σ):      6.120 s ±  0.090 s    [User: 5.027 s, System: 1.082 s]
    Range (min … max):    5.979 s …  6.233 s    10 runs
   
  Benchmark #4: b2sum b1
    Time (mean ± σ):     12.866 s ±  0.208 s    [User: 11.722 s, System: 1.133 s]
    Range (min … max):   12.549 s … 13.124 s    10 runs
   
  Benchmark #5: b3sum b1
    Time (mean ± σ):      5.813 s ±  0.079 s    [User: 4.606 s, System: 1.202 s]
    Range (min … max):    5.699 s …  5.933 s    10 runs
   
  Benchmark #6: md5sum b1
    Time (mean ± σ):     14.355 s ±  0.184 s    [User: 13.305 s, System: 1.039 s]
    Range (min … max):   14.119 s … 14.605 s    10 runs
   
  Summary
    'cat b1' ran
      5.33 ± 0.08 times faster than 'b3sum b1'
      5.62 ± 0.09 times faster than 'sha1sum b1'
      5.95 ± 0.10 times faster than 'sha256sum b1'
     11.81 ± 0.21 times faster than 'b2sum b1'
     13.17 ± 0.19 times faster than 'md5sum b1'

still beating the dedicated sha extensions, but not nearly as dramatically.

Ahh, fantastic; good to hear that that got somewhere