I feel like we're stretching the analogy pretty thin here.
100 karma · joined November 20, 2020
At the risk of stating the obvious: we need to measure every weird idea we try, and do our best to isolate the variables. Easier said than done. But we broke it, it's our problem now.
Talking about humility: an excess of humility leads to fatalism. Some is good, but not too much if you want anything to happen. We're talking about fixing the ecosystem of a planet, of course it's ambitious.
We have "aggravated the situation" (as you put it) beyond recovery. Doing nothing will now surely lead to an unacceptable outcome. We are going to have to fix it, or resign ourselves to a huge shrinking of the habitable region of the planet, with the hunger/famine/war that will accompany that.
Obviously we can always make things worse. But when doing nothing is unacceptable, we have to start taking risks.
My reasoning:
* people talk about going carbon neutral: great! But this isn't one problem, this is a thousand distinct problems. Our civilization is built on fossil fuels, and every manufacturing process, agricultural process, transportation process, etc, has to be re-invented to not be built on fossil fuels. Progress will never be as fast as we'd like on this front. We can and should push to get there (there is no good path but forward), but every new bit of news we hear out of Antarctica or Greenland should tell you that we need a longer runway.
* people talk about carbon sequestration: scaling up carbon sequestration is hard -- IMO, even with uncertainty, it feels a lot harder than blocking 1% of sunlight. There is a (semi)plausible technological path to the latter, at least. We will obviously have to keep exploring carbon sequestration in the hopes that a silver bullet emerges. But we can't count on nonexistent tech bailing us out. That's magical thinking, and one step above "thoughts and prayers". There has to be a plan in the mean time, and that plan needs to scale. We're probably going to need it.
* geoengineering with aerosols isn't just geo-engineering, it's essentially terraforming. That's a wing and a prayer, and at the scale we'd need to do it to have an impact we'd surely create some nasty unintentional consequences.
* Note: the above is an important risk calculation, because if you're ok with dumping a crapton of aerosols in the atmosphere -- as some people seem to be -- aren't we basically fine on climate already? Just do that indefinitely! Seems fine, right?
* if aerosol spam is not fine, your backup plan can only be something in space: you are here, at this pdf, at the solar sunshade. The sunshade has side effects, but they're much more palatable in my estimation -- the 1% of sunlight blocked will have the effect of making every day seem imperceptibly hazier (this was something I noticed during the 2017 solar eclipse at 50% of the sun being blocked -- seemed like a hazy day at that level of diminished sunlight. That was 50%. With the sunshade we're talking a 1% reduction to reduce the global temp by 2C.)
Anyway, just my 2c...
I did get a kick out of this from the OP: > Binary: Born from YouTube compression being absolutely brutal. RGB mode is very sensitive to compression as a change in even one point of one of the colors of one of the pixels dooms the file to corruption.
It's more than youtube compression -- video compression in general wreaks absolute havoc on our meticulously arranged (and sometimes colored) pixels. It's actually pretty fun/instructive to step through the transition between (what you want to be) two distinct frames when you're trying to (ab)use video for this sort of use case -- there are segments of the frames that get correlated and "flip" together first, resulting in in-between frames that are gibberish even with a modest amount of ECC in play.
That makes a lot of sense -- I have some more reading to do...
For example, you might currently be using a public/private keypair for 4096-bit RSA. That keypair (by definition) only works for the RSA key exchange algorithm. Likewise, an x22519 keypair is for the x25519 key exchange.
A sntrup761x25519 keypair will be its own thing. As an aside, a sntrup761x25519 public key will be two public keys glued together (one for each algorithm). [1] Likewise for the private key.
(one could reuse an existing x25519 keypair for the x25519 component of sntrup761x25519, but it seems like a bad idea)
[1] https://github.com/openssh/openssh-portable/blob/master/kexs...
We got a lot of mileage out of it (in a past life) before finally moving our job scheduling to a custom solution built on RQ. Celery caused more than a few headaches -- which is why we ditched it -- but its flexibility probably helped us scale up the service to begin with...
As a thought experiment, imagine how the modern web might've played out if KHTML was released under the MIT license instead of the LGPL?
Bearing in mind: Google has other ways of controlling the market (search, android, youtube, gmail, "switch to chrome" everywhere... don't call it anti-competitive...), but they've had to work much harder to exert control than they would've -- IMO -- if blink/webkit/khtml had a more "corporate friendly" license.
Maybe I'm off base with my reasoning, but I see it as being about friction. We can't stop the inhuman profit-seeking machine from doing what it does, but we do have some (underutilized) tools to slow it down.
Source: my phone blew up with 3+ emergency alerts starting at around 8. (here's a NWS tweet from 7:45 -- you can see what we were dealing with: https://twitter.com/NWSStLouis/status/1469483383994691586)
Things can get out of control quicker (15-20 minutes warning is usually as close as it gets), but I think it's definitely reasonable to suspect negligence in this instance. There are two possibilities, imo:
1. They had enough time to get people to shelter, and chose not to 2. The facility wasn't up to par
I'm not 100% sure I understand your example. Is it RDP server (remote) -> RDP client (local) -> cell phone?
4-color (standard): 7500 bytes
8-color: 8750 bytes
monochrome: 5000 bytes
Those numbers are with the standard, fairly high ECC setting (~20% of the image) that I settled on for video-based transfer. If we want to be more aggressive and use half the error correction:
4-color (standard): 8400 bytes
8-color: 9800 bytes
monochrome: 5600 bytes
The decoder has a lot of image processing work to do (intriguingly well-suited for the GPU), and also lots of popcnts. I've optimized it a fair bit, but there's probably some tricks I still need to learn. It turns out that mobile processors don't like heat very much, and blow out their cache much quicker than you'd hope. :)
In the long run, I think your intuition is correct. The hard physics of the camera constraints (exposure time, etc) will put a hard upper bound on FPS+fidelity, and thus bandwidth.
Transfers getting stuck like that usually is an indication that the decoder can't reliably find the 3+1 corner pattern. I might add a toggle to the decoder app that trades speed for more reliability.
That said, there are some failure modes that are harder to fix: I had a mysteriously slow transfer that was driving me nuts, until I noticed that my mouse cursor was on top of one of the corners.
But I can imagine a reverse (request?) channel being useful, if it had enough bandwidth for the desired application. :)
As /u/ggerganov notes elsewhere in this thread (with some expertise on the audio side -- I can't claim any), the bandwidth of any audio channel is probably going to be pretty bad.
edit: Notwithstanding how viable of an idea it might be, HTTP over audio+video would be pretty neat. :)
There are a number of loose ends that I'd like to look into down the road, and more flexibility for different use cases is on the list.
edit: I should mention: the main reason the decoder is a native Android app and not a WebAssembly app is that decoding performance is a throughput bottleneck. I wasn't too eager to pay the wasm tax, when I wasn't sure if even native performance would be good enough. As it happens, I now think decode performance is going to be ok -- but it's still a bit of a weak spot in the scheme.
That said... given the somewhat remarkable way fountain codes work, there's nothing stopping us from having a protocol that uses the audio and the video channels simultaneously for better throughput...
Though I think 720p is towards the low end of resolutions this'll work on -- the cimbar code itself is 1024x1024, and while there's some wiggle room (hamming distance between the symbols), in my experience it gets pretty iffy below 900x900.
Also... I should probably update the overlay to auto-hide when a file is selected -- it helps a lot to have the full color range.
You've seen QR codes, maybe Microsoft HCCB [0], maybe jabcode [1] – well, here's a prototype of something new for the pile. :)
I saw txqr [2] a while back and was impressed, but also curious about how much throughput was possible with animated bar codes. I may have gotten carried away in my research into the question.
cimbar is a single and multi-frame color barcode format using reed solomon (for now) and wirehair [3] for error correction. Files are encoded into an animated series of bar codes drawn to the display. Files are decoded by an Android app [4] with its camera pointed at the cimbar code. This works with all antennas off, e.g. in airplane mode, because it's only using the visual data channel.
I ported the encoder to wasm, because I could: https://cimbar.org
Sustained transfer speed is currently on the order of 800 kilobits/second. So it's not very practical for files larger than a couple of MB, unless you have a lot of free time. :)
[0] https://en.wikipedia.org/wiki/High_Capacity_Color_Barcode
[1] https://github.com/jabcode/jabcode
[2] https://github.com/divan/txqr