rich90usa

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)

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/)

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

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

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.

A coworker has has a small tool for accomplishing this: https://github.com/LesterTheTester/dfrnt

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.

Quoting Kos's reply:

The hashes cannot be used to obtain access to the folder; it is just a way to discover the IP addresses of devices with the same folder.

It would seem that consideration was put in to defending against collision attacks.

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.

There are simple reagent test kits that are reasonably accurate and affordable.

One workaround is to detach the other sessions when you connect.

tmux a -d

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?

Certainly. I remember learning early on that RAID != backup, and an easy conceptualization of Sync is RAID 1 at the file/folder level.

I'd recommend that someone using Sync for backup purposes take snapshots of they're syncing for backup purposes.

The "encryption secret" was implemented in version 1.2 of BitTorrent Sync: http://www.bittorrent.com/sync/developers/api - but for now you'll need an API key to generate them.

Alternatively, you could roll your own solution on top of Sync by encrypting your files on your own and creating a Sync folder of the encrypted files.

I highly suspect that is the case. On-demand (picking specific songs) has significantly higher royalties than radio. turntable.fm's model of picking a bunch of songs to be played but playing them with a batch of other user's requests was an interesting way around that.

In this case, however, I don't see the reason for skipping the currently playing song. I'm assuming that they've already had to pay for the current play so they might as well let it play out before skipping to the cheaper rotation.

The mnemonic that I've ran across that has been helpful for this is feigning a horrible German accent and saying "eXtract Ze File!"

I think it may be something like the inverse of bitcoin days destroyed. See: https://en.bitcoin.it/wiki/Bitcoin_Days_Destroyed

See http://www.bittorrent.com/sync/technology under "Peer Discovery"

@tkkayali - I'm not sure what it showed for you when you did it, but this is what I see.

http://screencast.com/t/nFNH23ECCYw

I intended the monad allusion to be a joke: it seems to be a running gag that people don't understand monads, and I was playing on that as a segue to people not understanding bitcoin.

I can't duplicate? I've tested across all my devices with three different ISP's and it still loads fine. I'm also making use of Cloudflare so the site being down would seem unlikely?

As another commentator replied, it's something that we have to deal with. I can't speak for sure, but I think what we're running in to here is too many elements on the page. I'm sure I'm glossing over the finer details, but I'd expect whatever bugfix is made will address that.

Thanks for the bug report! This particular problem is actually decently high in the bugtracker so I'd think we'd have something within the next few bugfix releases.

I'm going to guess that you were using your computer at the time. If you're using a desktop browser you're going to be directed to the site which relies on flash. If you're in a Webkit browser you can use html5.grooveshark.com and get the html5 experience on your desktop.

On a handheld device, we automatically direct you to the html5 site when you visit grooveshark.com

You may want to consider clearing your cache and cookies and reloading grooveshark.com on your device. The main features of this release are large screen (tablet) support and the ability to login to access your collection.

Try clearing your cache/cookies. Going to grooveshark.com directly on your mobile device should just work. Otherwise, you may want to try html5.grooveshark.com