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”.
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.
> 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)
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/)
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
>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.
It has been integrated with Travis CI and GitHub pull requests so that non-passing diffs are appended as a comment to the pull request by a bot account.
If there's an intended diff, a pull request can also automatically be submitted against the original pull request which, on merge, updates the "gold master" images and allows the original pull request to pass.
It doesn't look like ipfs has human friendly named pointers yet either? At least that's what I gather from their documentation:
http://ipfs.io/docs/commands/#ipfs-name
In answer to your question: bookmarks have been a long standing solution to remembering names. I absolutely understand that it's not the most ideal solution - but hopefully acceptable for a beta.
Unfortunately, the linked to TechCrunch article doesn't do much to explain how the browser works. One of the original-source blog posts does a (slightly) better job of explaining how things work - or at least points you in the direction:
http://blog.bittorrent.com/2015/04/10/project-maelstrom-deve...
The hashes directly represent the infohash for the created torrent website.
> I can audit it if I want to. Closed Source strips me of that option.
Closed source does not strip you of the ability to audit.
In the case of BitTorrent Sync you can use Wireshark to inspect the network traffic yourself. BitTorrent even goes so far as to purposefully use plaintext for the usage statistics it reports back so that someone could cross-verify with Wireshark.
Besides Wireshark there's all sorts of tools for instrumenting, debugging, or decompiling Sync that would also fall within the realm of auditing.
As other commenters have noted, it is not exactly trivial to verify that a binary for some open source software was produced by the same open source code you audited. This leaves you with having to compile from source everything – which seems only an order of magnitude or so less annoying than Wireshark-ing or IDA-ing everything.
Perhaps a better approach to handling the security concerns of open vs. closed source software would be to take a more active approach to locking down what we run. Lets operate with the working assumption that whatever we run is hostile instead of having blind trust in open source.
Lets use firewalls, containerization, selinux, etc. to essentially configure whitelists for what we allow of the software we run.
For someone that doesn't trust BitTorrent Sync because it's not open source consider locking it down. Use a firewall to only allow connections to known peers, isolate it from other processes, and restrict filesystem access. Trade some usability for security.
The kinds of things y'all are concerned about with BitTorrent Sync are the same things we should be just as concerned about for what we just apt-get'd; closed source vs. open source doesn't make a lick of difference in that respect.
Exactly. As a little more paranoid motorcycle rider I'd welcome being able to pull over and check my watch - instead of having to pull over, take off my gloves, unzip my jacket, and check my smartphone.
BitTorrent Sync has functionality for generating "encrypted secrets" using the developer API. It is possible to deliver a secret key to a peer which only allows for that peer to access encrypted versions of the folder content.
I suspect that you have specified a password in your BitTorrent Sync configuration file. Settings set in the configuration file will override settings set through the WebUI (after restart). Consider specifying your password either in the configuration file or using the WebUI, but not both.
I would think that there could be some application of how genome sequencing is done? From what I understand chains of DNA are cut by restriction enzymes and these random chains are assembled together by some clever algorithms?