> Most of the incoming light is being focused on a plane that the sensor isn't on. Indeed at 1200mm it has an equivalent f-number of 555 requiring some insanely bright lighting and long exposure time to get a good image.
I'm don't think that's why the lens has such a high f-number at large focal lengths. Rather, it's simply because they only manufactured a very small (1.8mm diameter) lens. Given the exotic shape and manufacturing of the lens I'm not surprised it's so small, and I suspect scaling this to larger lenses would be a very serious barrier to practicality. It's also not clear why they chose that particular focal range, so there may be some other issues I didn't notice. But on the whole this is very interesting work!
The fundamental observation (not caring about the phase of light at the focal plane) that makes this work is more interesting to me tbh. The authors' previous work uses a similar technique to produce a thin, single element apochromatic lens -- something that normally takes 3 thick lenses and expensive glass formulations.
Perhaps in terms of gates, but LUTs represent a much larger fraction of resources on an FPGA than the block RAMs. In other words, if you wanted to pack a lot of these onto an FPGA you'd run out of LUTs before block RAM.
I'm too lazy to look up numbers for the Kintex-7 part in question, but I'm almost certain you're wrong on this. A block RAM is a big chunk of die, and there are comparatively few of them to go around. A LUT is a tiny object (comparable in computation power to 10-50 dedicated transistors) and there are hundreds of thousands of them on the FPGA.
I'm willing to bet lots that 4/n_block_ram > 308/n_lut.
Yeah, I went and looked up. The details are hairy, becuase Xilinx. But a KC7K410T part, which is roughly their mid-range offering has 63550 slices, where IIRC a slice has two LUTs (pay no attention to their "logic cells" number -- that's a normalized thing scaled so as to be linear with the old 4-input LUT design from long ago) and 28620kbit of block RAMs, where each block is 36kbit.
So that design uses 308/(2*63550) =~ 0.2% of the logic resources on the FPGA, but 4/(28620/36) = 0.5% of the RAM.
Not nearly as imbalanced as it sounded to me originally, but still: the LUT numbers are spun by more than a factor of two. The design is more closely equivalent to "640 LUTs". Which interestingly is very comparable to the equivalent transistor count on the original part from Intel.
Block RAMs are 2-port. You can up it to 4 ports by doubling their clock rate, if the rest is merely crawling on 100mhz. Yet, each core would eat up one port for reading its microcode every clock cycle, so you can only have up to 4 cores for each group of 4 brams with stored microcode.
No need to get clever about it, or rather it's already been done. ;-) Except for the reseeding bit, getrandom() does that for you by default: blocks if /dev/urandom hasn't been seeded yet. At least according to the man page.
We do use LibreOffice to render previews of Office documents for viewing in a browser, and have permitted external resource loading to make those previews as accurate as possible. While this could theoretically be used for DDoS, we haven’t seen any such behavior. However, just to be extra cautious we’ve temporarily disabled external resource loading while we explore alternatives.
As one part of your solution, I recommend restricting the machines that can make outbound requests to a certain pool, and then limit that pool's total bandwidth, throwing an alarm whenever the limit is hit.
It may be that you are big enough that even the limited bandwidth you need for normal operations is enough to take out smaller hosts, so you'd need to measure and monitor to see how well this works.
Could Dropbox perhaps let me disable this feature? I almost never use the web interface so I wouldn't miss it and I prefer that my documents are not opened after being synched.
I'm don't think that's why the lens has such a high f-number at large focal lengths. Rather, it's simply because they only manufactured a very small (1.8mm diameter) lens. Given the exotic shape and manufacturing of the lens I'm not surprised it's so small, and I suspect scaling this to larger lenses would be a very serious barrier to practicality. It's also not clear why they chose that particular focal range, so there may be some other issues I didn't notice. But on the whole this is very interesting work!
The fundamental observation (not caring about the phase of light at the focal plane) that makes this work is more interesting to me tbh. The authors' previous work uses a similar technique to produce a thin, single element apochromatic lens -- something that normally takes 3 thick lenses and expensive glass formulations.