Search Results

Search found 10 results on 1 pages for 'jhs'.

Page 1/1 | 1 

  • How secure is a bluetooth keyboard against password sniffing?

    - by jhs
    In a situation where an admin will enter sensitive information into a keyboard (the root password), what is the risk that a bluetooth keyboard (ship by default with Mac systems these days) would put those passwords at risk? Another way of asking would be: what security and encryption protocols are used, if any, to establish a bluetooth connection between a keyboard and host system?

    Read the article

  • How secure is a bluetooth keyboard against password sniffing?

    - by jhs
    In a situation where an admin will enter sensitive information into a keyboard (the root password), what is the risk that a bluetooth keyboard (ship by default with Mac systems these days) would put those passwords at risk? Another way of asking would be: what security and encryption protocols are used, if any, to establish a bluetooth connection between a keyboard and host system? Edit: Final Summary All answers are excellent. I accepted that which links to the most directly applicable information however I also encourage you to read Nathan Adams's response and discussion about security trade-offs.

    Read the article

  • Best Role-Based Access Control (RBAC) database model

    - by jhs
    What is the best database schema to track role-based access controls for a web application? I am using Rails, but the RBAC plugin linked by Google looks unmaintained (only 300 commits to SVN; latest was almost a year ago). The concept is simple enough to implement from scratch, yet complex and important enough that it's worth getting right. So how do others architect and implement their RBAC model?

    Read the article

  • Can a CouchDB document update handler get an update conflict?

    - by jhs
    How likely is a revision conflict when using an update handler? Should I concern myself with conflict-handling code when writing a robust update function? As described in Document Update Handlers, CouchDB 0.10 and later allows on-demand server-side document modification. Update handlers can process non-JSON formats; but the other major features are these: An HTTP front-end to arbitrarily complex document modification code Similar code needn't be written for all possible clients—a DRY architecture Execution is faster and less likely to hit a revision conflict I am unclear about the third point. Executing locally, the update handler will run much faster and with lower latency. But in situations with high contention, that does not guarantee a successful update. Or does the update handler guarantee a successful update?

    Read the article

  • Temporary operation in a temporary directory in shell script

    - by jhs
    I need a fresh temporary directory to do some work in a shell script. When the work is done (or if I kill the job midway), I want the script to change back to the old working directory and wipe out the temporary one. In Ruby, it might look like this: require 'tmpdir' Dir.mktmpdir 'my_build' do |temp_dir| puts "Temporary workspace is #{temp_dir}" do_some_stuff(temp_dir) end puts "Temporary directory already deleted" What would be the best bang for the buck to do that in a Bash script? I want to trap

    Read the article

  • How do I change a Git remote HEAD to point to something besides "master"

    - by jhs
    Short version: How do I set a Git remote's HEAD ref to point to something besides "master"? My project has a policy not to use a "master" branch (all branches are to have meaningful names). Furthermore, the canonical master repository is only accessible via ssh://, with no shell access (like GitHub or Unfuddle). My problem is that the remote repository still has a HEAD reference to refs/heads/master, but I need it to point to a different branch. This is causing two problems: When cloning the repo, there this, warning: remote HEAD refers to nonexistent ref, unable to checkout. That's confusing and inconvenient. The web-based code browser depends on HEAD as a basis for browsing the tree. I need HEAD to point to a valid branch, then.

    Read the article

  • Any success using Apache Thrift on iPhone?

    - by jhs
    Has anybody done or seen a deployment of Apache Thrift in an iPhone app? I am wondering if is a reasonable solution for a high-volume, low(er)-latency network service for iPhones compared to HTTP. One noteworthy thing I found is a bug report about running Thrift on the iPhone, which seems to have been fixed. But that doesn't necessarily indicate that it's a done deal.

    Read the article

  • Best way to choose a random file from a directory in a shell script

    - by jhs
    What is the best way to choose a random file from a directory in a shell script? Here is my solution in Bash but I would be very interested for a more portable (non-GNU) version for use on Unix proper. dir='some/directory' file=`/bin/ls -1 "$dir" | sort --random-sort | head -1` path=`readlink --canonicalize "$dir/$file"` # Converts to full path echo "The randomly-selected file is: $path" Anybody have any other ideas? Edit: lhunath makes a good point about parsing ls. I guess it comes down to whether you want to be portable or not. If you have the GNU findutils and coreutils then you can do: find "$dir" -maxdepth 1 -mindepth 1 -type f -print0 \ | sort --zero-terminated --random-sort \ | sed 's/\d000.*//g/' Whew, that was fun! Also it matches my question better since I said "random file". Honsetly though, these days it's hard to imagine a Unix system deployed out there having GNU installed but not Perl 5.

    Read the article

  • What is the chance a CouchDB document update handler will get a revision conflict?

    - by jhs
    How likely is a revision conflict when using an update handler? Should I concern myself with conflict-handling code when writing a robust update function? As described in Document Update Handlers, CouchDB 0.10 and later allows on-demand server-side document modification. Update handlers can process non-JSON formats; but the other major features are these: An HTTP front-end to arbitrarily complex document modification code Similar code needn't be written for all possible clients—a DRY architecture Execution is faster and less likely to hit a revision conflict I am unclear about the third point. Executing locally, the update handler will run much faster and with lower latency. But in situations with high contention, that does not guarantee a successful update. Or does the update handler guarantee a successful update?

    Read the article

1