Why The NSA Collecting Your Phone Records Is A Problem | Cato @ Liberty

Some stress that what is being collected is “just metadata”—a phrase I’m confident you’ll never see a computer scientist or data analyst use.

Yeah no I would just call it “data”.

Metadata is a fine concept when we are talking about the structure of data. It is meaningless jargon when we are talking about an ongoing, secret, general data transfer from private corporations to government.

Let’s say I follow you to work for a week and record your routes on a map. Am I a stalker recording your habits, or a harmless guy recording “just metadata” about your footsteps? I mean, I didn’t take a stencil of each footprint and reproduce the street scene in my underground lair. What’s the big deal?

Everybody knows I could follow you to work and record your route. What’s the difference if I actually do?

The data about the endpoints of communications — the identifiers, time stamps, and locations — just happens to be the most useful and practical data for the NSA to have collected whenever this started — another detail that is too secret for the funding public to know about.

But the trajectory that the agency is on, in particular their/our $2 billion investment in the Utah data center, suggests that an “upgrade” of this program to store the entirety of our communications is just a matter of time.

Unless?

[USA] [NSA] [surveillance]



1 note
“completeme is a python script to auto-complete filenames in a given directory, much like Github’s ‘t’ keyboard shortcut or Command-T in TextMate or SublimeText. When you’ve settled on the file you’d like to edit, press “Enter” to open it with whatever’s in your $EDITOR variable or press “Tab” to drop that filename at the end of your current command!”

— mattspitz/completeme · GitHub

[Hack and Tell] [Tools] [Shell]



1 note

implicit.ly: dispatch 0.10.1

implicitly-notes:

This release improves the behavior of Dispatch 0.10 when used within sbt interactive mode.

In sbt’s process

By default sbt runs its console, run, and test tasks in a JVM shared with sbt itself. Previous releases of Dispatch have, for your convenience, marked all background threads as…

This post was reblogged from implicit.ly.

Senistive touchpads and Ubuntu

Last fall Meetup furnished me with a ThinkPad X1 Carbon. I was excited about this model because, as much as I love the x201 I use at home, the X1 Carbon is an all-new machine that finally starts a new chapter in the legendary laptop’s design. As I said back then:

It’s unfortunate that Lenovo like most companies, when they hit on a winning hardware design (or buy one), will just tack on a few bells and whistles year after year instead of, you know, refining the design.

But no longer! Not only is the phone jack (!??!) gone, they’ve given up ethernet, VGA, and (I think… I’m not really an expert on this stuff…) the “PC Card” slot. There’s also no removable battery.

In other words they made a number of difficult tradeoffs, very much following in the footsteps of tradeoffs that Apple made years ago for the Air and for the same reasons: to innovate in design. But unlike most other companies following in the Air’s footsteps, Lenovo actually did innovate. Instead of yet another slippery metal or faux-metal case, the Carbon has grippy black plastic that looks distinguished and feels great.

Here are some X1 Carbons poorly composited with an enormous pencil.

Thinkpads X1 Carbon, giant pencil

Sensitive touchpads and Ubuntu

But this post’s title promises information about Ubuntu and I hope that googlers do indeed land here to find it. Because I had this laptop for 8 months before I spent a weekend day figuring out how to make the large super-sensitive touchpad work well with Ubuntu.

Under the default configuration it was just not possible for me to use tap-to-click, as I prefer, or even press-to-click. In both cases the cursor would jump right as the click registered. (i.e. the worst possible time.) So instead of clicking the coordinates I had painstakingly positioned the cursor above, I would be clicking some other dumb place and often as not miss the area defined for whatever action I was trying to take.

I just couldn’t use the big fancy touchpad much at all, and stuck with the trackpoint. What a shame.

Anyway, here’s my new config, the comments at the top tell you how to make it take effect. I keep the file under my home directory and softlink to where the system will read it. I’m pretty happy with this config. It’s not 100% perfect and I’ll probably be tweaking it until the day I die, but at least now I can use my touchpad without despair.

# softlink this file into:
# /usr/share/X11/xorg.conf.d

# and prevent the settings app from overwriting our settings:
# gsettings set org.gnome.settings-daemon.plugins.mouse active false


Section "InputClass"
    Identifier "nathan touchpad catchall"
    MatchIsTouchpad "on"
    MatchDevicePath "/dev/input/event*"
    Driver "synaptics"

    # three fingers for the middle button
    Option "TapButton3" "2"
    # drag lock
    Option "LockedDrags" "1"
    # accurate tap-to-click!
    Option "FingerLow" "50"
    Option "FingerHigh" "55"

    # prevents too many intentional clicks
    Option "PalmDetect" "0"

    # "natural" vertical and horizontal scrolling
    Option "VertTwoFingerScroll" "1"
    Option "VertScrollDelta" "-75"
    Option "HorizTwoFingerScroll" "1"
    Option "HorizScrollDelta" "-75"

    Option "MinSpeed" "1"
    Option "MaxSpeed" "1"

    Option "AccelerationProfile" "2"
    Option "ConstantDeceleration" "4"
EndSection

I hope this is helpful. I assume it is at least a step in the right direction for other laptops with big, sensitive touchpads.

For home use I’m getting antsy to replace my x201, as I am tiring of its tiny touchpad, paltry number of pixels, and general non-ultraness. Unless Lenovo makes a smaller version of the X1 Carbon I may have to jump ship for the Dell XPS 13 of all things. But something is telling me to wait a bit longer.

[Ubuntu] [ThinkPad] [Touchpad] [Trackpad] [Linux]



1 note

implicit.ly: dispatch 0.10.0

implicitly-notes:

scala.concurrent.Future

From this release forward Dispatch uses the standard Future interface that was introduced in Scala 2.10 and backported for Scala 2.9.3. This required some breaking changes in the API, but the migration is straightforward.

Imports

The shortest import is now this: 

import...

Sooooooooooo glad that’s done.

This post was reblogged from implicit.ly.



17 notes

Blake Matheny: Eliminating Duplicate Requests

mobocracy:

If you’re building a backend service and can avoid the problem of serving duplicate requests, that’s a good thing. A duplicate is defined in this case as: if two requests R1 and R2 both have a response r_1, they are duplicates. Eliminating duplicates avoids doing unnecessary additional work.

At…

This post was reblogged from Blake Matheny.



2 notes

Making Meetup: Measuring Scala 2.10

makingmeetup:

We upgraded from Scala 2.9.1-1 to 2.10.0 and it made some stuff faster.

Upper bound of response times

@softprops did the 2.10 upgrade in a branch a few weeks back with the minimal code changes it required. We were surprised at the time to see some improvements in our benchmarks. I was eager to see if those translated…

This post was reblogged from Making Meetup.

[Scala] [Performance] [2.10]



1 note
Here’s @avibryant engaging in some hand waving about approximate collections, #nescala day 1

Here’s @avibryant engaging in some hand waving about approximate collections, #nescala day 1



1 note

Drawing a Circle on a Map

mlcastle:

Here’s the code for how to draw a circle with a fixed radius on a map, using Google’s new Android Maps v2 API (assuming you are willing to live with the imprecision of doing calculations on a spherical Earth rather than the WGS84 ellipsoid):

Sphereist.

This post was reblogged from mlcastle.

[Android] [Java]



1 note

Participatory Conferencing

We’re less than a week from the Northeast Scala Symposium, and the few remaining RSVPs spots (out of three hundred this year) are dwindling.

The symposium was born as a gathering of the Scala meetups of New York, Boston, and Philadelphia. We simply took the planning and budgeting processes of our meetups and scaled them up. Which is to say, we didn’t do much planning or budgeting at all. We held the first nescala in one of our usual meetup space and we selected speakers with a voting process open to everyone who RSVP’d. This not only seemed fair, it saved us the task of trying to anticipate everyone else’s preferences.

This shooting-from-the-hip style of organizing has worked well for us organizers and, as far as I tell, for the attendees. Or rather, participants. Everyone at the gathering—not just the esteemed speakers—must contribute for it to be special. Otherwise we could all stay at home and watch the same dudes talking on youtube.

Each year nescala has grown in size more or less on its own. We haven’t made growth a priority, but it is gratifying and it’s got to be good for the Scala community that a regional conference is growing.

The greater the number of participants in nescala, the more people who have to be registered, fed, cleaned up after, and—well—taken care of. I would love it if we could do this as a group, but you have to remember that this is a conference by and for programmers. Nobody is going to cut short a conversation about the pros and cons of iteratees for something as mundane as disposing of paper plates with pizza crusts on them.

Meetup organizers excel at throwing away paper plates, but as the conference grows there just aren’t enough of us to keep up. So we’ve done the only rational thing and hired people to do this for us. And it works out: as the conference grows we get $50 from more people and we also get more offers of sponsorship.

But there is one side effect of growth I’m constantly on guard against: commoditization of the experience. The more paid staff there are helping make the day a success, the more people will confuse the organizers with paid staff. The more they will see a customer-service relationship where there is none. The less they will be active participants in the symposium, and the more they may taint the experience of others—including, if I may be selfish, the organizers.

We don’t make money off of nescala and have no reason to. For a living we write software, like you. For a hobby we bring people together, and the payback is in seeing others participate actively in the conference. Watching people help each other. It’s as simple as that.

See you on Friday.

[Scala] [nescala] [Conferences] [Programming]

Page 1 of 47

}