Skip to content

Archives

Links for 2013-08-27

  • Using set cover algorithm to optimize query latency for a large scale distributed graph | LinkedIn Engineering

    how LI solved a tricky graph-database-query latency problem with a set-cover algorithm

    (tags: linkedin algorithms coding distributed-systems graph databases querying set-cover set replication)

  • How might the feds have snooped on Lavabit?

    “I have been told that they cannot change your fundamental business practices,” said Callas, who unlike Levison was able to say SilentCircle has received no NSLs or court orders of any kind. “I presume that would mean things like getting SSL keys because that would mean they could impersonate your servers. That would be like setting up a store front that says your business name and putting [government agents] in your company uniforms.” Similarly, he added: “They cannot make changes to existing operating systems. They can’t make you change source code.” To which [Lavabit’s] Levison replied: “That was always my understanding, too. That’s why this is so important. Like [Callas] at SilentCircle said, the assumption has been that the government can’t force us to change our business practices like that and compromise that information. Like I said, I don’t hold those beliefs anymore.”

    (tags: ars-technica security privacy nsls ssl silentcircle jon-callas crypto)

  • Lock-Based vs Lock-Free Concurrent Algorithms

    An excellent post from Martin Thompson showing a new JSR166 concurrency primitive, StampedLock, compared against a number of alternatives in a simple microbenchmark. The most interesting thing for me is how much the lock-free, AtomicReference.compareAndSet()-based approach blows away all the lock-based approaches — even in the 1-reader-1-writer case. Its code is extremely simple, too: https://github.com/mjpt777/rw-concurrency/blob/master/src/LockFreeSpaceship.java

    (tags: concurrency java threads lock-free locking compare-and-set cas atomic jsr166 microbenchmarks performance)

  • Juniper Adds Puppet support

    This is super-cool. ‘Network engineering no longer should be mundane tasks like conf, set interfaces fe-0/0/0 unit o family inet address 10.1.1.1/24. How does mindless CLI work translate to efficiently spent time ? What if you need to change 300 devices? What if you are writing it by hand? An error-prone waste of time. Juniper today announced Puppet support for their 12.2R3,5 JUNOS code. This is compatible with EX4200, EX4550, and QFX3500 switches. These are top end switches, but this start is directly aimed at their DC and enterprise devices. Initially, the manifest interactions offered are interface, layer 2 interface, vlan, port aggregation groups, and device names.’ Based on what I saw in the Network Automation team in Amazon, this is an amazing leap forward; it’d instantly render obsolete a bunch of horrific SSH-CLI automation cruft.

    (tags: ssh cli automation networking networks puppet ops juniper cisco)

  • awscli

    The future of the AWS command line tools is awscli, a single, unified, consistent command line tool that works with almost all of the AWS services. Here is a quick list of the services that awscli currently supports: Auto Scaling, CloudFormation, CloudSearch, CloudWatch, Data Pipeline, Direct Connect, DynamoDB, EC2, ElastiCache, Elastic Beanstalk, Elastic Transcoder, ELB, EMR, Identity and Access Management, Import/Export, OpsWorks, RDS, Redshift, Route 53, S3, SES, SNS, SQS, Storage Gateway, Security Token Service, Support API, SWF, VPC. Support for the following appears to be planned: CloudFront, Glacier, SimpleDB. The awscli software is being actively developed as an open source project on Github, with a lot of support from Amazon. You’ll note that the biggest contributors to awscli are Amazon employees with Mitch Garnaat leading. Mitch is also the author of boto, the amazing Python library for AWS.

    (tags: aws awscli cli tools command-line ec2 s3 amazon api)

Comments closed