ffk

One pattern I like to use is to write my documents using markdown which can be compiled into pdf via latex with a template of my choosing. It is also capable of compiling to other formats which may be more accessible such as plain text, html and docx.

https://pandoc.org/

[edit to add link to pandoc]

I've seen a few streams of people who are like this, and they seem to do ok. One of the pidgin devs migrated their mercurial repos from bitbucket to their own self-hosted environment, live, on stream.

I think the personality of the person has a lot more to do about whether they keep the attention of their viewers. The ones who seem to get things done seem to speak out their internal dialog.

I was unclear in my comment. I was describing a before and after set of solutions. The former allows for server side decryption. The latter approach would prevent server side decryption.

It looks like what they have now is openssh like. Client 1 sends data to the server encrypted. Server decrypts. Server reencrypts and sends to client 2.

This describes how to communicate in such a way where the client 1 and 2 can communicate with the server in the data path and The server being unable to see the contents of the message.

The hard part is key management between clients in a secure way.

Right now would be a fantastic time for these ISPs to start installing Open Connect Appliances. It'll keep most Netflix traffic off of the backbone.

https://openconnect.netflix.com/en/appliances/

I'm sure we'll laugh about most things we are currently using and gasp when we need to revisit them in legacy systems. :)

I don't believe I suggested getting rid of the MAC address altogether. Ethernet isn't going away anytime soon.

The suggestion is simply this: Don't embed your MAC address into your IPv6 address because it's a unique identifier that can deanonymize you even if you shift networks.

This runs Amazon lambda, so presumably well enough?

This is enabled by disabling anything that depends on pinned kernel memory.

You get a VM with user space networking and a one button keyboard. This allows the kernel too aggressively swap out unused resources and ultimately increase the total concurrency supported.

This is more comparable to runc.

Firecracker can be used in kubernetes through containerd+kata containers integration. (Containerd from docker is a key tech behind both docker and K8s, kata containers from Intel enables containerd to run vms)

I don't think the experience is great yet, but it's on the way.

Not all networks are private. Also, many IPv6 addresses contain the MAC address which would effectively deanonymize you over the internet.

Most IPv6 packets are encapsulated in Ethernet frames which use MAC addresses. What may change is the vendor specific MAC address could be replaced with a MAC address generated by a cryptographic hash to preserve privacy.

MACs can be spoofed. There are entire companies which begin their sales pitch with "So, I can poison the ARP cache to take over your DNS in your Kubernetes Cluster" due to the NET_RAW capability required to respond to ICMP (ping). :)

You'll want to use a crypto based identity if you want to ensure spoofing isn't occurring. Even then, you can still be DOSed by a malicious actor. Tools like eBPF may be able to help here by filtering out source MAC addresses that don't match the source interface's hwaddr.

edit: Sorry, I didn't read this comment properly. In ZeroTier I can believe that they cannot be spoofed across the VPN due to relying on a cryptographic hash. :)

In most scenarios, you want to avoid L2 tunnels to reduce complexity and/or performance issues.

The chain of thought typically goes like this:

* Remote networks are connected via L2 tunnel.

* ARP requests are broadcasted over L2 tunnel to all connected networks, introducing scalability issues

* Proxy ARP is introduced to cache ARP responses

* Proxy ARP may become out of date or not scale as the L2 domain grows.

* BGP is introduced to keep track of and broadcast all topology changes

* How do you mitigate issues caused if Proxy ARP fails?

Most of these issues go away if you use IP tunnels instead of Ethernet because IP was designed to be routable.

For your point on security... Whitelisting MAC addresses doesn't provide security. These are trivial to spoof. Same with IP. Please start relying on cryptographic primitives to establish workload identity instead. I highly suggest looking at SPIFFE to get started here.

If you must send L2 over the VPN, please go use a L2 EVPN which is designed to handle the complexity and provide fault tolerance. There are numerous SDNs out there you can use to implement this including Tungsten Fabric and OpenDaylight. No need to complicate Wireguard to support EVPN.

[edited to improve formatting of bullets and clarity of wording]

Wouldn't it be nice if preserving your privacy simply meant not wearing your QR code?

The example before shows the author typing Prin with autocompletion. Maybe that was the original intent? I think that context is lost though and it would be better to just highlight the entire thing as you suggest.

Docker was not written in Java. It was shell scripts, python, then go. Dotcloud was primarily a python shop.

Perhaps you are thinking of a different project?

Oh on multi arch support. This was purely about keeping focus and reducing the original scope. I shared the same concerns and brought up this exact topic with Solomon. A change here meant changes in docker hub and other key places including devops which would further burden an already stretched team.

I should review the comment a bit more carefully sometimes.

Sorry for the slow response, just got off an airplane. These were not after the fact. Instead, we knew these were the potential benefits and we moved over. I personally wasn't happy about having to run a daemon to get a container, but we saw the benefits far outweighed the downside for the approach. The other approach on the table was for docker (pre client/server split) to continue requiring sudo. I don't recall anyone suggesting an alternative approach though.

There were a few reasons for this. The original golang version of docker required root, full stop. There was no difference between the client and server.

The first reason was to reduce privileges of the client interface. This would provide the possibility to reduce privileges and restrict what unprivileged could do later on. The communication over the socket is just http, which allows for remote management of docker containers.

A second reason was to build a strong contact between the client and server. The client became syntactic sugar for the rest calls, which helped stabilize docker. This would ultimately lead to enabling osx and win support via a VM on the host.

Another major goal was to enable the docker in docker use case which helped significantly when developing on docker itself.

Source: I was there. :)

For me, the exciting part of 5G is the connection density.

The estimated density for a 4G network is: 4,000 devices / km^2.

The estimated density for a 5G network is: 1,000,000 devices / km^2.

The density means we can scale up machine <-> machine interactions significantly, rather than focus on human <-> machine interactions that we have today.

This is one of the reasons things like Federated Kubernetes is being worked on. Stick a CDN in front and your compute can be migrated from cloud to cloud. You still need to do a lot of thinking about data though.

Fun fact, tcpdump is one of the BPF killer apps.

eBPF extends the BPF with a more modern architecture (e.g. 64 bit support) and being generalized so that it can support things like more fine grained security control in seccomp which limit what commands a userspace app can call.

Xdpcap seems like a logical progression of this path.

My understanding is all frequencies interfere with all other frequencies. When averaged, the total power is probably not affected, but the power at any given point at a small enough time interval should be noticeable.

But then, I'm not an antenna designer, I may have something fundamentally wrong in my understanding. :)

The main thing I got from the MIT article is this:

"This system relies on an array of antennas that emit radio waves of slightly different frequencies. As the radio waves travel, they overlap and combine in different ways."

This is known as constructive interference, pretty nifty to see it used in this context. The range has been increased from 10 cm to 1 meter since the paper I co-authored on this subject. Impressive!

These kinds of applications have also been a long time coming. With IoT devices and NFC readers looming around the corner, I think it is likely that we will see some pretty innovative medical inventions. Likewise, as mentioned by NKosmatos, we need to take the security aspect very seriously. Some of these NFC devices are programmable, and should defend against attacks that could lead to events such as withholding life-saving medicine or misreporting biometrics.

For reference, check out this paper I co-authored:

Suitability of NFC for Medical Device Communication and Power Delivery (2007)

https://ieeexplore.ieee.org/document/4454171/

And if you're interested in an early paper about RFID-delivered viruses, check out this by Tanenbaum et al.:

http://www.rfidvirus.org/papers/percom.06.pdf

Nice project, definitely a very important effort.

Also, I recall hearing about how some people or villages opt in to deforestation because they are offered a significant amount of money which can be used to feed their kids and provide an education which may help their communities eventually escape the poverty trap. Do you know anything about this, and if true, do you know of any groups trying to help?

You are correct, docker images don't generally contain kernels (and if they do, they don't load them).

A more apt comparison would be vs alpine standard which is 109 MB and contains a kernel.

Thanks for reproducing the experiment. :) I sent a message to tianon asking him if he remembers what the original numbers were. He told me long ago, I think it was around 1000. This was well before the go shim or dockerd existed.

I'll have to ask tianon to see what he says. I don't remember the number.

The smallest useful container I know of is 129B. It was created to test how many containers docker can spin up while reducing the overhead of what was in the container itself.

tianon/sleeping-beauty latest 2e8193709fa7 6 months ago 129B

https://github.com/tianon/dockerfiles/tree/master/sleeping-b...