451 karma · joined July 23, 2010
You might like the "iReal Pro" app for the replacement and transposition of jazz standards on your tablet. It's pretty great for that use case versus camera scans.
I was able to adapt the OP's shell script to generate a working Codabar image (after I figured out that my local library used "A" and "T" as beginning and end markers) that matched the physical card exactly, and there was enough useful metadata for me to piece together a working pass using that barcode as a store card's background image. I ended up using the Pass2U Wallet iOS app directly, rather than hacking around signing keys, but found the documented process helpful.
!!!! Backlinks
<<list-links "[all[current]listed[]!has[draft.of]!is[system]]">>[1] http://web.archive.org/web/20090918202746/http://tothink.com...
The paper mentions that it's measuring the worst-case scenario for the clean/smudge filter-style tools as it's much more likely that you only need to protect a few files and not the entire repository, but I didn't see how the second section actually reflected this more-realistic scenario. I'm not saying that encrypting the entire repository is bad, but the overhead of using filters to encrypt the entire repository is a documented/known limitation of the other tools...so it seems a little odd to gloss over that.
Side note, stuff like "This process is repeated a total of 10 iterations for an ample sample size to draw statistical conclusions." worries me, but that's another conversation.
Overall though, glad to see more research in this area, and it sounds like GV2 might be a decent solution for people looking to protect their data in certain scenarios.
[1] https://github.com/sshuttle/sshuttle
[2] https://groups.google.com/d/msg/sshuttle/jdTzJGjTDMg/IcQkCzb...
[1] http://projectmeshnet.org/ [2] http://hyperboria.net/ [3] https://github.com/cjdelisle/cjdns
With transcrypt, I do the encryption/decryption transparently once a repository has been configured by utilizing Git's clean/smudge filters, but it uses OpenSSL out of the box rather than GPG. A different workflow, and there are certainly pros and cons to both ways.
I disagree...I believe in its current state it is not catering to the general public, but it's basically alpha software with a small bootstrapped network. Long-term, the idea is to make things more user friendly and appeal to a wider audience, but it's inaccurate to say it will "never be workable". Recommending it to a highly-technical targeted audience like HN seems entirely appropriate.
* I run 4 cjdns nodes
$ git diff --check $(git hash-object -t tree /dev/null)
...although many projects frown upon whitespace-only commits since they screw with `git blame`. "hello world" print
...although, more realistically, you're probably interested in something like the gettings started section of the docs [1]. There are also some great short example posts on the planet feed [2] from various blogs.EDIT: I'll plug my own blog for this too, as I started writing a Beginning Factor series of posts a long time ago [3], but never got beyond a couple entries.
[1] http://docs.factorcode.org/content/article-handbook.html
[2] http://planet.factorcode.org/
[3] http://elasticdog.com/2008/11/beginning-factor-introduction/
# awk '/eth/ { print $1 }' <(ifconfig -a) | cut -d':' -f1 | uniq | while read interface; do echo -n "$interface "; ethtool -i $interface | grep driver; done
eth0 driver: e1000e
eth1 driver: e1000eNaming after the purpose of the box also gets messy if you're not strict about renaming when the machine is repurposed. And if you group by "theme groups" as the RFC suggests, you're still stuck renaming a machine if it's no longer one of your 7 dwarfs (database servers, or whatever). Should the name convey meaning at all, or just be a random label?
A developer I know doesn't see the problem with just having the full location (state, data center, rack, rack location), which I'm against, but we haven't been able to agree on a good middle ground approach that scales. Is location data in a name universally bad?