rich90usa · HackerTrans

I launched a high altitude balloon as part of a summer school program over a decade ago and we checked on edge cases. Off the shelf GPS are supposed to not work beyond a certain height 18,000 m and/or speed 515 m/s to be a barrier for use as a weapon. Some hardware treat that as AND; some treat that condition as OR. The term to look up is “CoCom Limits”.

rich90usa

3 anni fadiscuss

Nijiya Market in Japantown has at least plain seaweed Onigiri in far right of the fridge near the entrance for $2.79. Unfortunately it was the same price as ones with filling.

rich90usa

9 anni fadiscuss

> there was no depending on external services, which at the time put WebRTC out of the picture (all of the easy to use implementations required internet access to use existing signaling services)

See: https://github.com/cjb/serverless-webrtc

That's a good rough demo of how WebRTC connections can still be established with the ask/offers being conveyed out-of-band.

To make it a little more friendly for tablets (and to accomplish before messages expire) I'd think QR codes would be a reasonable way of passing the data without depending on an external service.

There could also be some extraneous information that can be stripped to save on the amount of data you pass between peers so that the QR code isn't excessively gross (see: https://webrtchacks.com/the-minimum-viable-sdp/)

rich90usa

10 anni fadiscuss

At least according to Wikipedia references, BitTorrent Inc's own client had mainline DHT support since version 4.2 (~2005). uTorrent seems to have added support for mainline DHT some time before the acquisition as well. There's a good torrentfreak post from the 10 year anniversary that covers the history pretty well: https://torrentfreak.com/bittorrents-dht-turns-10-years-old-...

I'm guessing that your "by default now" may actually be in regards to BitComet and the v0.60 client that upset some folk?

Besides the BEP44 implementation magila mentioned, BitTorrent Inc. also assists with the DHT by operating a public bootstrap server at router.[bittorrent|utorrent].com, and provides the source too: https://github.com/bittorrent/bootstrap-dht

rich90usa

11 anni fadiscuss

https://github.com/feross/bittorrent-dht

rich90usa

11 anni fadiscuss

One of the team members had an excellent answer to this question a few days ago in a Reddit IAmA: https://www.reddit.com/r/IAmA/comments/3bnjhe/hi_i_am_alan_s...

>We’re limited in other ways, weirdly. For example, LORRI, our high resolution imager, has an 8-inch (20cm) aperture. The diffraction limit (how much an 8” telescope can magnify) is 3.05 mircorad. which is just over half the size of single pixel 4.95 microrad. So if we swapped out the current sensor with a higher res one, we couldn’t do much better because of the laws of physics. A bigger telescope would solve that problem, but then it would make the spacecraft heavier, which require more fuel to send to Pluto AND a longer time to get there, because the spacecraft is more massive. We launched Pluto on the largest, most powerful rocket available at the time (the Atlas V, with extra boosters), so again we’re limited by physics: “At the time” doesn’t mean best ever. The Saturn V rocket, which sent astronauts to the moon, was actually more powerful.

>More megapixels also means more memory. For example, LORRI images are made up of a header and then the 1024x1024 array of numbers that make up our image and go from 0 to 65535 (216). There’s not really a way to make that info smaller if we went to 2048x2048. We could downlink a compressed version, but we want the full info eventually.

tl;dr

1. Between optical physics and balancing different costs to launch mass, it was the sound engineering choice.

2. Higher resolution would take even longer to retrieve the captured data.