awelkie

Sure, there are many possible generalizations, some of which are more intuitive than others. But it should be clear that n=3 is a specific case of this particular generalization, for which I think the intuition is clear, which should help illuminate why the n=3 case holds.

I think it can be explained just using intuition too.

Instead of 3 doors, imagine there are 1e9 doors. Then you choose one door (at random), and the host reveals all but one other door.

I think then it's clear why you would switch doors.

Are quantum computers useful for cryptanalysis in the case where you don't quite have the necessary number of qubits? Like let's say you want to factor an integer N, which would require n qubits, but you have a QC with only n/2 qubits. Could you use the QC to narrow down the search space and then finish with a classical computer, or is the QC completely useless in this case?

I appreciate what you're saying, but for devices with long lifetimes things may not be so clear. Consider a wifi device with a >15 year lifetime. Let's say such a device was built with SDR and FPGA, it conformed to 802.11b, and it used twice the power of an equivalent ASIC design. But 15 years later, this device was able to upgrade in software to 802.11ac, and so it was able to take advantage of spatial multiplexing and higher-order modulation to lower its power usage. So now this device uses twice as much power as an equivalent 802.11ac ASIC, but maybe it's more power efficient than that 802.11b ASIC from 15 years earlier.

I guess what I'm saying is that by allowing a device to upgrade in software to more power-efficient designs, you might claw back some of the efficiency lost by using an FPGA when you consider the entire product's lifetime.

Wow. I'm a few months into a PhD after having worked at a startup for a number of years, I just completed my first project, and just a few weeks ago my advisor had the "you need to stop thinking like you're building a product" talk with me. It's definitely tough to make that mindset change.

I believe rust's safety guarantees are enough to ensure the soundness of passing data to/from interrupt contexts and interrupt handler re-entrancy. See rtfm[0] for an example and a good explanation. I think DMA handling can be made safe by using the right abstractions, and then you'd just need to trust that any piece of code that accesses the memory uses the abstraction instead of accessing it directly.

Checking interrupt priorities sounds like an interesting problem. What is the state of the art in deadlock prevention? It would also be cool if you could tell the compiler "I need this interrupt handler to return in less than n clock cycles." I wonder if someone could write a rust compiler plugin to check that.

[0]: http://blog.japaric.io/fearless-concurrency/

What kinds of things would you want proven correct about your code's interrupt handling?

The spatial resolution depends on the bandwidth of your transmission. An infinite-bandwidth signal is a delta in time, and gives infinite precision. Any finite bandwidth impulse will be a sinc in time, with temporal width proportional to the inverse of the bandwidth. So a higher bandwidth impulse will be shorter in time, which would give better temporal resolution.

Typical radar works by sending and receiving a high-bandwidth impulse, which requires high-bandwidth transceivers. Let's say that transmission occupies frequencies between f0 and f1. SFCW radar works by sending a bunch of individual low-bandwidth transmissions between f0 and f1. So each transmission is small, but together they occupy the same f0 to f1 bandwidth. Assuming the environment didn't change in the time it took to send all of those low-bandwidth transmissions, you've effectively simulated a high-bandwidth impulse using a bunch of low-bandwidth impulses. So the spatial resolution will be the same.

Another potential issue is that ultrasound machines send out an impulse instead of a single frequency. So maybe the quartz crystal oscillators aren't good at producing a short high-bandwidth signal?

That being said, there's a type of radar system called "stepped frequency continuous wave" radar that uses a bunch of single frequency transmissions instead of an impulse transmission. The basic idea is that instead of using a high-bandwidth transceiver to send and receive the impulse, you can use a low-bandwidth transceiver to send and receive tones, and then hop this transceiver over the large bandwidth to get a high-resolution image (the tradeoff being that it takes longer to acquire an image). Since ultrasound is basically radar, I'd imagine this technique could be used for ultrasound too.

Of course it would. I'm saying easy p2p transfer may reduce the usage of Dropbox, not obsolete it.

It seems to me that there are disadvantages to widespread IPv6 adoption for some big companies. For example, storage providers like Dropbox or Google Drive would take a hit if I were able to send files via a direct connection to a friend's computer, which is possible with IPv6. Right now, the best way to send large files is to upload them somewhere and then send a link (dynamic DNS is also possible, but certainly not as easy to set up as simply being granted a globally routable IP address). Another example is for ISPs or anyone who sells static IP addresses (e.g. AWS); IPv6 means severely decreasing the scarsity of a resource that they own and profit from, which I'm sure they wouldn't like.

To generalize, I think IPv6 represents more freedom for end-users in the form of better p2p services, but I think it also represents a loss in profit for some large companies. These companies play a roll in the IPv6 rollout, so maybe it's not surprising that the rollout has been slower than expected.

There is some discussion on that here: https://github.com/rust-embedded/rfcs/issues/23