So did I! :-)

This is not ripping anything out, though. This is allowing simultaneous development in both C and Rust, in order to evaluate the benefits of Rust over C in a real-world project. And, based on the progress so far, both Linus and Greg K-H are seeing benefits, or at the very least, wish for the evaluation to continue. It's a bit hard to argue against the people who are arguably doing the largest amount of work on the kernel, and see all the areas that are or could be affected by it.

And yes, in the future there may be incremental migration of functionality into Rust code vs C code. It's certainly not going to be soon, and I seriously doubt that it will be rushed. From everything I have seen, the only way it will happen is from the outside in. Code on the periphery will be implemented in Rust, talking to a C/Rust interface to core C code. Slowly, as C clients of the core C code are replaced with equivalent Rust code, that core C code can be migrated to Rust.

And a contemporary response to network providers wanting their "fair share": https://techcentral.co.za/andi...

Network providers in other countries are also attempting to get OTT providers to pay for "transit" across their networks to their own customers.

https://www.lightreading.com/b...

A general discussion about OTT providers in the context of carriers:

https://carritech.com/ott-tele...

And a brief discussion about paying for transit, and partitioning the internet:

https://bgp.tools/kb/partition...

It kind of feels like the answer is in the word itself - we're aiming to prevent the extreme views from propagating, while embracing the "moderate" view - one that considers arguments from more than one side, and draws their own conclusions.

I'm working on a WiFi Keyboard and Mouse interface, using a Cactus Micro v2 board. This has an atmega32u4, which appears to the PC as a keyboard and mouse, as well as an ESP8266 Wifi microcontroller, which connects to your home wifi and exposes a TCP service to accept K/M events. Connect to it using your phone/tablet, send keystrokes/mouse movements to your PC, view the results via an HDMI over Ethernet extender.

Still in progress, but sounds like it might address your problem.

Indeed, my solution would have involved something like a TP-Link WR703N, running OpenWRT, powered from a USB battery pack. (I'm assuming that each of the pumps is some distance from the next, and you don't want to have Ethernet cables running across the forecourt. The battery pack is optional, I guess you may also have power available at each pump). Configure each mini router with an appropriate IP address on the Ethernet port, and then do Source NAT from the Wifi to that IP address when talking to the pump. Configure the WiFi interface to connect to an AP that you set up centrally, that your laptop will also be connected to. This takes care of the issue of simultaneous connectivity to each pump.

As far as software goes, it sounds like a virtual machine for each is a requirement, so that they can run independently of each other. This *might* end up being the trickiest part, depending on how much configurability you have in the application that actually does the firmware updates.

* If you can specify the IP address of the destination pump in the update software, great, simply bridge or NAT each VM onto the Wifi network set up in step 1. Configure each VM to speak to the IP address of each 703N, and perform the update. Done.
* If each VM needs to have the corresponding IP to the pump's, things get a little trickier, and you may need to have another layer of NAT to get this to work. I suspect that you would run into issues with the number of private networks that your Virtualisation software supports, in this case.

Am I the only one wondering how they get a CA to sign the certificate? Seems like an interesting opportunity for someone within CloudFlare to get their own SSL certs signed, and MITM to their hearts content.

In this context, something like tor or a socks proxy would also qualify as spoofing ones IP address, and could throw an ICBM on the wrong track. Just saying.

Not strictly true. You can do it easily if you are on the path normally taken to get to the spoofed IP. For example, see Linux TProxy.

The main constraint preventing it in the general case is the difficulty of guessing the sequence numbers.

Ah, that would be 0.99p13, I know there was a gap there somewhere.

0.99p30, IIRC

Breathless excitement!

The achievements in the rest of this paper far outweigh the existence of a tablet built on this foundation.

They've created their own 64-bit processor! They've implemented a compiler for it! They've ported FreeBSD to it! That's some seriously impressive stuff!

But the leader has to be the laser cut tablet assembly. :-(

Noone has to intercept anything, or maintain a session. Just TCPdump the lot, and look at it later.

That is, unless they are trying to intercept SSL, which they COULD do, as a CA cert controlled by a Chinese company has been added to most browsers already.

A USB-serial adapter like the CA-42 (powered from the PC on the other end) would be perfect for that purpose. Check out all the OpenWRT or similar "serial console" articles.