ffk

A lot of the time once you get into multi-gig+ territory the answer isn't "make the kernel faster," it's "stop doing it in the kernel."

You end up pushing the hot path out to userland where you can actually scale across cores (DPDK/netmap/XDP style approaches), batch packets, and then DMA straight to and from the NIC. The kernel becomes more of a control plane than the data plane.

PF/ALTQ is very much in the traditional in-kernel, per-packet model, so it hits those limits sooner.

I think a more accurate version of this is: unit tests were not only per-method but also per functionality. This was often called BDD (Behavior Driven Development), e.g. Ruby's cucumber. Your intuition here is correct though.

Since the 90s, New Zealand laws have been written in clear, modern, accessible English. The end result is the broader population understands it more and can also reason about it while it’s up for debate before being passed.

I think the ambiguity in the first two amendments has to do more with the specific text rather than plain English itself being deficient.

Sometimes it’s done to fit into an existing tool/database that has a preexisting limit. Or when the hash is used only as a locator rather than for integrity.

Not a good practice imo but people are pragmatic.

Fun fact: docker started as bash, then moved to python before settling on golang.

Also, in a 2013 docker meetup, someone wrote a docker clone in bash.

People want to learn! Hopefully things like this help them.

I'm guessing the decision comes down to ease of use for people to participate in mirroring. My underestanding is IPFS tends to require more infrastructure, and still requires someone to pin the data.

Many bittorrent clients let you click a button to continue seeding the data over time.

On the first point, OPA is much older than OpenFGA. To really illustrate the point, OPA became a graduated project about a year before OpenFGA had their first code drop in the public GitHub repo. The OpenFGA people are aware of OPA and I'm sure they learned from the tradeoffs OPA made.

To the main point, what you described reflects the current trends of authorization. Define a data model, define data that adheres to that model, write declarative rules that consume that model, make a decision based on those rules.

Where things really start to differ is the kind of data that they bind against and how do you write rules. E.g. OPA is often used for either ABAC (Attribute) or RBAC (Roles) while OpenFGA is looking at ReBAC (Relationships). Each has their complexity tradeoffs, depending on the system being implemented. How easy or difficult a system makes these kinds of checks has a significant impact on how you write policies.

Hope this helps!

Good question! The term is more generic, introducing something to an existing system to begin a chain reaction.

There are some applications where the ability to vectorize the headers and operate on them with SIMD help. These types of apps tend to pin a full core to do only packet processing though. Also, syscall are expensive. A lot of work is going into making the APIs async while avoiding syscalls.

It depends on what you are trying to do though. I don’t think the kernel has an easy path to operating on a set of packet headers as a vector at this point. Not saying it can’t happen, but it’s an area where user space is already ahead.

For reference, there was a previous test that demonstrated 40gbps with ipsec between two pods on separate nodes in k8s where the encap/decap achieved 40gbps which was the line rate for the Intel NICs used.

Details were published here: https://medium.com/fd-io-vpp/getting-to-40g-encrypted-contai...

I do agree that io_uring will negate the need for DPDK for many use cases though, it will likely be a much simpler path and more secure path than DPDK.

Interestingly, the fastest CPU based network switches tend to do full kernel bypass. The kernel is generally slow compared to OVS and VPP, especially when they traverse over something like DPDK.

If you secure a loan for or lease a car, isn’t insurance mandatory for completion of the transaction? If so, how are most people still driving Kias off the lot if they can’t get insurance?

Ora are people getting insurance and finding their policies unrenewable?

It’s probably validated by a human before the message is deployed.

Agreed, one way to help mitigate this is to establish Layer 7 security controls, rather than implicitly trust the network. Tailscale shouldn't be the sole security control in any environment.

Thank you for mentioning this! I wrote docker save and load, and I’m happy to hear that it helped you!

Docker save (and presumably podman too) adds that metadata as a file in a tar. Each layer becomes a tar that is nested in the top level tar.

Another insane idea, invite Japanese teams to play. Many Japanese people love baseball!

Very cool!

Found a gap, Linux Foundation's FD.io's VPP (a high performance network virtual switch) has native wireguard support as well, all in userspace. Support here means you can do full kernel bypass from the app all the way down to the NIC card (e.g. via DPDK).

https://docs.fd.io/vpp/20.09/d5/d54/wireguard_plugin_doc.htm...

I'll open a PR on this later.

Something to consider, if you are IO constrained, compression may speed up reads because you shift some of the cost of IO to the CPU.

Ultimately, you'll need to measure this to know for sure, and those results will likely only be valid on a given hardware configuration.

OverlayFS also has a "copy_up" function, where the file is copied at the initial write. Once the copy is done, I'd expect write access to be fast. Again, you'll need to measure this.

The setup could probably look like:

container read/write -> OverlayFS([mutable fs as overlay] -> [squashfs layer as underlay] -> [squashfs layer as underlay])

Been a while since I looked. My understanding is many of these techniques such as SMPC are useful only when operations are linear (eg no exponents or tan functions) and on simple branches. Others like homomorphic encryption require operations on the whole data set.

I think the best best for some of these workflows will be differential privacy on large datasets with strict privacy budgets.

Still highly valuable, but make sure you understand the limitations and risks if you use these techniques.

Check out CBRS which is "licensed-by-rule." You should be able to use CBRS to deploy private 5G.

Unfortunately, I don't think this is going to be the outcome. We're more likely to end up with "Here is the list of filenames, subcomponents, and associated hashes" as opposed to requiring NixOS style environments. Vendors to the subcontractors will likely be required to provide the same list of filename/subcomponent/hashes, a far cry from repeatable builds.

It's not a joke, BGP servers used to authenticate each other with this in the late 90s. This was also before NAT was really a thing.

Why not just implement Single Packet Authorization (SPA)? The port only opens to that specific source on a recent cryptographically signed request with a timestamp. https://www.linuxjournal.com/article/9621

I believe grpc only uses the http2 frames, which are bidirectional. Double check this though.

If it's using firecracker, it's probably using KVM virtualization while ensuring that the memory the VM consumes is not pinned... that is, that the VM can be swapped out of memory. For reference, firecracker was created by AWS to run and secure AWS Lambda. The hypervisor is written in rust and uses seccomp to eliminate unnecessary system calls. They open sourced it a few years back.

What you gain is a stronger security boundary. Just FYI, since 2019, you can also do this in Kubernetes using Kata containers + containerd which will happily shim firecracker. The setup is not simple though.

https://github.com/kata-containers/documentation/wiki/Initia...

Overall, fly.io building infrastructure on this pattern and making it accessible is fantastic. Looking forward to seeing how this continues to evolve and am happy to see more infra build on top of firecracker. Very exciting!

Pair X-Plane with PilotEdge, and you've got something that can help you with your radio skills so that you can effectively communicate with ATC. So many pilots go without flight following (asking ATC to watch your path and notify you of things you should be aware of) simply because they are afraid of the radio.

Completely agree about stick/rudder skills though...

I think there is an inaccuracy in that comment. Double check this: wire guard encapsulates L3 IP packets, not L2 Ethernet frames. This means ARP is handled locally instead of being transmitted over the wire (or the need for an arp responder)

LEDs tend to give off a good range over the visible light spectrum. Incandescents tend to bias towards the higher end of the spectrum (towards red).

Agreed that some research can also help find a good light. There are plenty of "full spectrum" light solutions out there which may work for the original poster.

Compare Incandescents (A) vs LED (D) at https://www.researchgate.net/figure/Emission-spectra-of-diff...

They tried, but apparently the sale was blocked due to AI export control laws in China.