Judge Orenstein Rules

By now you will have heard that Federal Magistrate Judge James Orenstein of the Eastern District of New York has ruled in case parallel to the San Bernardino case involving the FBI and Apple. At issue in the San Bernardino case is whether the All Writs Act can be used to force Apple, against its will, to break into the iPhone 5C used by one of the shooters.

The New York case heard by Judge Orenstein is similar. In that case the government was seeking to force Apple—again under the All Writs Act—to assist them in breaking into an iPhone. This time the phone in question was an iPhone 5S running iOS 7. Because the OS was iOS 7, breaking into the phone was less burdensome then it would have been had it been running iOS 8. Nevertheless, Judge Orenstein refused to order Apple to assist the FBI.

What struck me was how closely Judge Orenstein’s decision tracked Apple’s response to the San Bernardino order that I wrote about last Sunday. Both argue that the All Writs Act does not apply in these cases because Congress considered the action the FBI is urging and rejected it and because it will, in fact, represent a significant burden on Apple.

Sarah Jeong over at Motherboard has an excellent summary of Judge Orenstein’s decsion and what it means for the San Bernardino case. You should definitely read Jeong’s piece but I urge you to also read Orenstein’s decision itself.

Note to journalists: If you’re feeling inclined to comment or report on the FBI vs. Apple controversy and you haven’t read Apple’s response to Judge Pym’s order and Judge Orenstein’s decision then remain silent because you’re not qualified to speak on the matter. You don’t have to understand the mathematics behind the crypto or even the technical details of what Apple is being asked to do but you do need to understand what the government is asking, why they’re asking for it—no, it’s not to recover data from the phone—and why complying would be a significant burden on Apple. You can discover all these things by reading Apple’s response and Judge Orenstein’s decision. Until you do, refrain from commenting on the case. I’m not a lawyer and I had no difficulty reading and understanding them; I’m sure you won’t either.

Posted in General | Tagged , | Leave a comment

Lisp Family Tree

Via Jean-Philippe Paradis, a nice chart of the relationships between various Lisps.

Posted in General | Tagged , | Leave a comment

Reading Mailing Lists

In my never ending quest to move every conceivable task into Emacs, I came across this Emacs Stack Exchange entry on reading mailing list archives with Emacs. That turns out to be pretty easy to do.

The trick is to use Gnus. Even if you use something else, like mu4e to read your email, you can fire up Gnus to read the mailing list archives. Here’s the TL;DR (although the SE article is pretty short).

First configure an nntp server in your init.el like so

(setq gnus-select-method '(nntp "ger.gmane.org"))

Specify whatever nntp server you use but if, like many, your ISP no longer offers news, you can use ger.gmane.org as I did above.

Then fire up Gnus with 【Meta+xgnus and type

B
nntp
news.gmane.org

At this point you should have a list of all the mailing lists on Gmane. If you’re interested in, say, the Emacs Development list, search for emacs.devel and select it. From there, you can select individual threads to read.

What I like about this solution is that Gnus is built in so you don’t need any setup other than specifying your nntp server. Even better, you don’t have to master Gnus, which is famously difficult. Just follow the steps above and navigate as you would expect.

Posted in General | Tagged | 1 Comment

A Tip for Mac/Emacs Users

Here’s a nice tip for Emacs users on OS X:

Posted in General | Tagged | Leave a comment

Apple Responds

Irreal readers are certainly aware of the latest drama playing out between the FBI and Apple. The FBI applied, ex parte, to a federal magistrate for an order compelling Apple to assist the FBI in breaking into an iPhone 5C used by one of the San Bernardino shooters. The magistrate granted the order and Apple promptly announced that it would appeal1.

It’s important that Apple prevail because despite the government’s disingenuous assurance that this is a one-time request dealing only with one phone, the point of the FBI’s request is to establish a precedent. Indeed, the government has several more cases lined up and ready to go as soon as the case is resolved. Nationwide, there are probably hundreds of cases where prosecutors want Apple to break into phones.

Apple’s public discussion of the case emphasized that complying would put the security of every iPhone user—something that Apple has worked very hard to secure—at risk. Irreal readers, I’m sure, will find that argument compelling but is it sufficient to quash the magistrate’s order?

We needn’t have worried. Apple has filed their motion to vacate the order and it seems to me—speaking as a non-lawyer—to be devastating to the government’s case. To me—again, speaking as a layman—Apple’s most persuasive argument was that the All Writs Act, which the government depends on to justify their action, does not apply in this case because

  1. the Congress already considered the matter and refused to act, and
  2. that complying does, in fact, represent a significant burden on Apple.

On the second point, Apple pointed out that after the initial effort2, once the precedent is set they will receive a flood of similar applications and that will require hiring additional full-time staff to deal with them. Furthermore, they can’t, as the Government suggests, simply destroy the break-in software after the data is recovered because they may be called in some future trial to testify on their methods and procedures and to produce the software as evidence.

Apple already has significant legal and engineering staff dedicated to dealing with government requests for data and they understand the need to document each step they take and to establish a chain of custody for any hardware they work on. They make a good case that complying with the order will result in a significant and ongoing burden.

There’s plenty more and you really should read Apple’s brief. It’s entertaining and instructive even if you aren’t a lawyer. If you don’t have time for the brief itself, The Intercept_ has an excellent summary of the important points it raises. The Intercept_ describes the brief as “a legal motion for the ages.”

Footnotes:

1

The press, of course, characterized this as Apple putting itself above the law but by refusing to roll over for the government and appealing, Apple is, in fact, following the law.

2

Apple estimates 10 engineers and related personnel for 2 to 4 weeks. That’s probably already more effort than the All Writs acts contemplated.

Posted in General | Tagged , | Leave a comment

Moving Files Asynchronously in Dired

Sometimes you want to copy a set of files from Dired in Emacs. If you have one or two files you can simply mark and copy them but if there are many files it can take some time for the copying and during that time Emacs is frozen.

The excellent abo-abo over at (or Emacs posted a nice bit of Elisp that arranges for the copying to be done asynchronously so that you can continue working while the copying takes place. The idea is that the code calls rsync asynchronously with async-shell-command and then switches to another window with the progress bar so that you can check the progress when you like while doing other things until the copy completes.

Since the copying uses rsync the code works nicely with remote copies too. If you often copy many files at a time, you should consider integrating the code into your workflow.

Posted in General | Tagged | Leave a comment

Science vs. Everything Else

Via Karl Voit we have sad commentary on the human condition.

Posted in General | Tagged | 1 Comment

Mickey on use-package

Mickey has a new post over at Mastering Emacs on John Wiegley’s excellent use-package package. For those who don’t know, use-package is a macro that organizes and simplifies package loading and configuration. It can also delay the loading of a package until it’s needed.

As usual, Mickey does an excellent job of covering the material so I’ll just send you over to Mastering Emacs to read his post. If you aren’t already using use-package, you really should read Mickey’s post and consider starting to use it. It really does make thing easier and neater.

Also, note the comment from Wiegley on how to simplify Mickey’s last example by leverage a new feature that he just pushed. You can get use-package from Melpa so it’s easy to load and keep current.

Really, you should be using it.

Posted in General | Tagged | Leave a comment

Lisp in Production

If you’re a Lisper, you’ve probably heard many times that it’s not practical to use Lisp in production. Despite the many counter examples (Viaweb, ITA, …) this myth—like the one about Lisp being slow—refuses to die. Vsevolod Dyomkin and Kevin McIntire over at the Grammarly blog are helping to put this myth to rest with a description of how Grammarly uses Lisp in production.

They discuss how they use SBCL in production and CCL for development. This illustrates one of the benefits of having differing Lisp implementations. SBCL has excellent run time performance while CCL has speedy compilation. By using both, Grammarly gets the best of both worlds.

The post is not a fluff piece pushing Lisp, though. They also discuss the problems they encountered and how they solved them. They describe a difficult bug (in the SBCL runtime) and how they used the TRACE facility to track it down.

Finally, they discuss how Slime provides a powerful IDE for developing in Lisp. It’s an enjoyable read if you like Lisp and wish you could use it more.

Posted in General | Tagged , , | Leave a comment

Some Ansi-Term Improvement

Brian Zwahr uses ansi-term in Emacs for his shell work but found that there were a few things about it that he didn’t like. Being Emacs, those things were pretty easy to fix and he posted about his fixes.

He begins with a bit of Elisp that kills the ansi-term buffer when the shell exits. This isn’t a huge thing but it is annoying to have the now useless buffer hanging around so this is a worthwhile change.

At the other end, he arranges for ansi-term to automatically use his preferred shell. That way he doesn’t have to specify it every time he starts an ansi-term.

Zwahr noticed that when he pasted something into the buffer with 【Ctrl+y】 the shell didn’t see it. Again, a bit of Elisp fixed that.

Finally, there were a couple of display issues, one involving the solarized color theme, that required tweaking.

I prefer eshell for most of my shell work and just call up iterm2 when I need to do something that eshell doesn’t handle well but if you like the ansi-term solution, you should definitely give Zwahr’s post a read. You may want to grab some of his fixes.

Posted in General | Tagged | Leave a comment